Internet DRAFT - draft-jin-nvo3-virb-centralized
draft-jin-nvo3-virb-centralized
Network Working Group L. Jin
Internet-Draft ZTE
Intended status: Standards Track B. Khasnabish
Expires: June 16, 2013 ZTE USA, Inc.
December 13, 2012
Virtualized Integrated Routing & Bridging
with centralized control plane
draft-jin-nvo3-virb-centralized-00.txt
Abstract
The network in datacenter is required to provide a tenant network,
which should be virtualized, and be able to provide L2 switching or
L3 routing capability. A combined L2&L3 solution could provide great
scalability for both Layer2 and Layer3 switching. In this document,
we propose to apply centralized server to be the control plane of the
combined L2&L3 solution, to provide better scalability for the
control plane. The combined L2&L3 solution in this draft is named
Virtualized Integrated Routing&Bridging (shorted as VIRB).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 16, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Jin, et al. Expires June 16, 2013 [Page 1]
Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3
1.2. General terminology . . . . . . . . . . . . . . . . . . . 4
2. VIRB model on NVE . . . . . . . . . . . . . . . . . . . . . . 4
3. VIRB Dataplane Format . . . . . . . . . . . . . . . . . . . . 5
4. Control Plane with Centralized Server . . . . . . . . . . . . 5
4.1. Layer2 information distribution . . . . . . . . . . . . . 6
4.2. Layer3 information distribution . . . . . . . . . . . . . 7
4.3. Gateway selection for L2VNI . . . . . . . . . . . . . . . 7
4.4. Designated Virtual Routing Instance Selection for
Multicast . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Interoperating with MPLS Layer3/2 VPN . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Jin, et al. Expires June 16, 2013 [Page 2]
Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012
1. Introduction
The network in datacenter is required to provide a tenant network,
which should be virtualized, and be able to provide L2 switching or
L3 routing capability.
Within one tenant, there is case the customer requires on bridge
domain, and there is also case that the customer requires multiple
bridge domains separated by customer VLAN.
Then the virtualized network or tenant network provided by NVO3
should have at least following capability:
1. Provide traffic segregation between different virtualized
network.
2. Provide multiple bridge domains within one tenant by customer
VLAN.
3. Provide Layer2 traffic segregation between different bridge
domain within one tenant.
4. Provide Layer3 routing between different bridge domain within one
tenant.
5. Provide seamless interconnection between the virtualized network
and already defined L2VPN, e.g, BGP/LDP-based VPLS, E-VPN.
6. Provide seamless interconnection between the virtualized network
and already defined L3VPN, e.g, BGP MPLS VPN.
[I-D.sajassi-l2vpn-evpn-ipvpn-interop] proposes an E-VPN based
combined L2&L3 solution, named IRB, to address the shortcomings of
L2-only as well as L3-only solutions, and provide optimum forwarding
for both inter and intra subnet switching.
In this document, we propose to apply centralized server to be the
control plane of the combined L2&L3 solution. The combined L2&L3
solution in this draft is named Virtualized Integrated Routing&
Bridging (shorted as VIRB).
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
Jin, et al. Expires June 16, 2013 [Page 3]
Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
1.2. General terminology
The terminology defined in [I-D.ietf-nvo3-framework] is used
throughout this document. Terminology specific to this memo is
defined here and is introduced as needed in later sections.
VIRB: Virtualized Integrated Routing and Bridging
2. VIRB model on NVE
VIRB will provide both virtualized Routing and Bridging in one
virtual instance, and the dataplane behavior is similar with a Layer3
switch box or IRB(Integrated Routing and Bridging). The functional
model of VIRB will be like below:
|
| Tunnel Overlay
+------------------------------|----------------------------+
| +------------------------+----------------------+ |
| | Overlay Modual | |
| +-.-------------.---------------.-------------.-+ |
| /--|-------------|--\ /--|-------------|--\ |
| | | +---------+ | | | | +---------+ | | |
| | | | Routing | | | | | | Routing | | | |
| | | +-.-----.-+ | | | | +-.-----.-+ | | |
| | | | | | | | | | | | | |
| | +-----+ +-----+ | | +-----+ +-----+ | |
| | | BD | | BD | | | | BD | | BD | | |
| | +-----+ +-----+ | | +-----+ +-----+ | |
| | |VIRB Instance| | | |VIRB Instance| | |
| \--|-------------|--/ \--|-------------|--/ |
+-------|-------------|---------------|-------------|-------+
| VAPs | | VAPs |
---------+-------------+---------------+-------------+---------
| | | |
Tenant Systems Tenant Systems
Figure 1
One tenant will include a Layer2 instance and Layer3 instance. The
Layer2 instance will include multiple bridge domain. The virtual
routing module is responsible for IP forwarding for VIRB instance,
Jin, et al. Expires June 16, 2013 [Page 4]
Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012
while virtual bridge module is responsible for MAC based forwarding
within one VLAN. One VIRB instance could contain only one virtual
routing module and multiple virtual bridges, each of which is
separated by VLAN. Both the virtual routing and virtual bridge has
interface to the overlay module. Each virtual bridge module has a
virtual interface to virtual routing module, and every IP subnet is
associated with this virtual interface. Within every tenant, the
virtual bridge and corresponding bridge domain is uniquely identified
by VLAN ID, while different tenants could have duplicated VLAN ID to
identify the bridge domain.
When a frame received by an ingress NVE from tenant system, it needs
to be parsed in order to identify which VIRB instance it belongs to.
The parsing function can examine various fields in the data frame
(e.g., Service Delimiting VLAN-ID) and/or associated interface/port
the frame came from. Once the VIRB instance is identified, the
customer VLAN-ID+MAC should be used to do Layer2 forwarding. If the
customer VLAN-ID does not exist, a default VLAN-ID configured locally
could be used instead.
The frame with destination MAC address owned by virtual routing
instance should be subjected to do Layer 3 forwarding by virtual
routing module.
3. VIRB Dataplane Format
The general format of the VIRB protocol layering model is same as the
format defined for L2VNI and L3VNI in
[I-D.bl-nvo3-dataplane-requirements]. One VIRB instances include a
Layer2 instance and a Layer3 instance. In order to be fully
compatible with existing MPLS Layer3/2 VPN, this document suggests
using MPLS label as both the L2/L3 encapsulation indicator and VNID.
Different bridge domains within one tenant are identified by the VLAN
ID, while the Layer2 and Layer3 instance is identified by the MPLS
label. Other format of VNID for VIRB will be studied in furture
version
4. Control Plane with Centralized Server
Due to the requirement described in
[I-D.kreeger-nvo3-overlay-cp]section 4, it is high cost for every NVE
to accommodate the whole forwarding table, including MAC forwarding
table for virtual bridge module and IP forwarding table for virtual
routing module.
We propose to use centralized server to control the MAC forwarding
Jin, et al. Expires June 16, 2013 [Page 5]
Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012
table and IP forwarding table. The framework would be shown in
following figure.
This document only specifies the interaction specification between
NVE and centralized server. How the centralized server is organized
or implemented is out of the scope of this draft.
Every NVE will learn the local VAP, VM/Host MAC address, VLAN and IP
address, by e.g, snooping ARP packets, or by Server-NVE protocol, or
by getting information from virtualization software if NVE resides on
hypervisor. And then NVE SHOULD send the learned MAC, VLAN, IP
address and VNI to the centralized server. The centralized server
SHOULD generate the Layer2 MAC information, and Layer3 IP
information. And these information would be advertised to other NVE
and centralized servers. The signaling session between NVE and
centralized server could be OpenFlow or XMPP which has already been
supported on Linux package, and would specified in future version of
this draft.
4.1. Layer2 information distribution
Each bridge domain within one tenant is identified by the VLAN unique
within tenant, and the Layer2 MAC forwarding information should
include at least the following:
1. VM/Host MAC address
2. VLAN ID
3. MPLS label for Layer2
4. VIRB ID for control plane
5. NVE Address
The Layer2 MAC information SHOULD be distributed by centralized
server to other NVE or other centralized server. The NVE receiving
the Layer2 MAC information should import this information only to the
bridge domain with same VLAN ID and VIRB ID. The MAC forwarding
table generated by the centralized server would be following:
1. Forwarding entry for Packet to local VAP: <Incoming:
Destination_MAC+VLAN, outgoing: local VAP on NVE>
2. Forwarding entry for Packet to remote NVE: <Incoming:
Destination_MAC+VLAN, outgoing: overlay tunnel identified by remote
NVE address>
Jin, et al. Expires June 16, 2013 [Page 6]
Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012
4.2. Layer3 information distribution
Before generating the Layer3 IP information, the IP address SHOULD be
summarized within one VLAN one tenant if possible for each NVE. The
Layer3 IP information should include at least the following:
1. IP Prefix (summarized from VM/Host IP address)
2. MPLS label for Layer 3
3. VIRB ID for control plane
4. NVE Address
5. Node Priority
The node priority is used for gateway selection for unicast traffic
and designated virtual routing instance selection for multicast
traffic, see details in section 4.3 and 4.4. Note that the IP prefix
on virtual interface between virtual routing and bridge instance
should not be advertised.
The Layer3 IP information SHOULD be distributed by centralized server
to other NVE or other centralized server. The NVE receiving the
Layer3 IP information should import this information only to the
virtual routing instance with same VIRB ID. The IP routing table
generated by the centralized server would be following:
1. Forwarding entry for Packet to bridge domain: <Incoming:
destination_IP prefix, outgoing: local virtual bridge interface>
2. Forwarding entry for Packet to remote NVE: <Incoming:
destination_IP prefix, outgoing: overlay tunnel identified by remote
NVE address>
Note that, the VIRB ID for control plane in Layer2 and Layer3
information MUST be the same, and this value is only used for control
plane to identify each VIRB instance.
4.3. Gateway selection for L2VNI
In the virtual network with both VIRB instance and L2-only Virtual
Network Instance (short for L2VNI), the NVE in L2VNI should find the
best virtual routing instance as a gateway. The centralized server
has all the IP address information of the VM/Host attached to VIRB or
L2VNI, then the gateway selection for L2VNI should consider the
following factors:
Jin, et al. Expires June 16, 2013 [Page 7]
Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012
1. IP address summarization: virtual routing instance which has the
maximum capability to summarize the IP address from L2VNI should be
selected as the gateway.
2. Processing load: the virtual routing instance on the NVE which
has lower processing load should be selected as the gateway.
Different bridge domain could have different gateway, so as to
achieve load balance.
3. Path cost: the virtual routing instance nearest to the L2VNI
should be selected as the gateway.
4. Priority: the virtual routing instance with high priority should
be selected as the gateway.
The specific gateway selection mechanism is a local policy on the
centralized server, and is not specified in this draft.
4.4. Designated Virtual Routing Instance Selection for Multicast
The multicast traffic within one bridge domain should be distributed
through the Layer2 overlay. Then there should be a designated
virtual routing instance to be selected from the routing instances
within one bridge domain. The selection of designated virtual
routing instance should be performed by centralized server in
following steps:
1. Discover the virtual routing instance within the same bridge
domain, by checking if these virtual routing instances have been
attached with same VLAN.
2. Discover the virtual routing instance where its attached local
bridge domain is requested to join the same multicast group.
3. Select the designated virtual routing instance which is nearest
to multicast source. Note that the assumption here is the
centralized server has the cost information among the NVEs.
4. Select the designated virtual routing instance by the priority
and NVE address.
The centralized server could apply pull or push or combined pull and
push to send the forwarding table to each NVE. This depends on the
NVE forwarding memory capability.
Jin, et al. Expires June 16, 2013 [Page 8]
Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012
5. Interoperating with MPLS Layer3/2 VPN
The seamless interoperability with MPLS Layer3/2 VPN has been
described in [I-D.sajassi-l2vpn-evpn-ipvpn-interop] section 2. In
this section, we will only describe the specific behavior of
centralized server for the seamless interoperability.
The signaling session between centralized server and MPLS Layer3/2
VPN PE MUST be MP-BGP session, and the centralized server SHOULD
support the signaling function of MPLS Layer3/2 VPN.
The centralized server SHOULD learn the L3VPN IP forwarding
information through MP-BGP session. The routing information received
from L3VPN PE will also be advertised to each VIRB instance, and then
corresponding IP routing entry will be generated on virtual routing
module.
The centralized server SHOULD learn the Layer2 MAC forwarding
information from L2VPN through MP-BGP session. And the Layer2 MAC
forwarding information received should be imported to a bridge
domain, and which is assigned by a locally designated VLAN. The MAC
information from L2VPN PE will be also advertised to each VIRB
instance, and imported to the corresponding bridge domain.
6. Security Considerations
Will be added in future.
7. IANA Considerations
Will be added in future.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.bl-nvo3-dataplane-requirements]
Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L.,
and B. Khasnabish, "NVO3 Data Plane Requirements",
draft-bl-nvo3-dataplane-requirements-03 (work in
Jin, et al. Expires June 16, 2013 [Page 9]
Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012
progress), November 2012.
[I-D.ietf-nvo3-framework]
Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for DC Network Virtualization",
draft-ietf-nvo3-framework-01 (work in progress),
October 2012.
[I-D.kreeger-nvo3-overlay-cp]
Kreeger, L., Dutt, D., Narten, T., and M. Sridharan,
"Network Virtualization Overlay Control Protocol
Requirements", draft-kreeger-nvo3-overlay-cp-02 (work in
progress), October 2012.
[I-D.sajassi-l2vpn-evpn-ipvpn-interop]
Sajassi, A., Salam, S., Patel, K., Bitar, N., and A.
Isaac, "E-VPN Seamless Interoperability with IP-VPN",
draft-sajassi-l2vpn-evpn-ipvpn-interop-01 (work in
progress), October 2012.
Authors' Addresses
Lizhong Jin
ZTE
889, Bibo Road
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn, lizho.jin@gmail.com
Bhumip Khasnabish
ZTE USA, Inc.
55 Madison Avenue, Suite 160
Morristown, NJ 07960 USA
Email: bhumip.khasnabish@zteusa.com, vumip1@gmail.com
Jin, et al. Expires June 16, 2013 [Page 10]
