Internet DRAFT - draft-mpls-big-label-ucase-req
draft-mpls-big-label-ucase-req
MPLS Working Group Richard.Li
Internet-Draft Katherine.Zhao
Intended status: Proposed Standard Robin.Li
Expires: April 20, 2014 Huawei Technologies
October 20, 2013
MPLS Big Label Usecases and Requirements
draft-mpls-big-label-ucase-req-00.txt
Abstract
This document describes usecases and requirements for MPLS big label.
The MPLS label format and encoding method have been specified in [RFC
3032], the label value is represented by 20-bit space and support up
to 1 million of instances. This proven technology has been widely
deployed and worked fine for years. However in certain network
deployment scenarios of recent years, the 20-bit MPLS label space is
no longer sufficient to support the widespread adoption of network
virtualization technologies. In what follows we will describe each of
the usecase respectively
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 January 01, 2014.
Copyright Notice
Copyright (c) 2013 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
Li, et al. Expires April 20, 2014 [Page 1]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirement Language . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Big Label Usecase for VPN . . . . . . . . . . . . . . . . . . 4
2.1. MPLS Based L3VPN with VXLAN . . . . . . . . . . . . . . . 4
2.2. MPLS Based L3VPN with NVGRE . . . . . . . . . . . . . . . 6
2.3. MPLS Based L2VPN . . . . . . . . . . . . . . . . . . . . . 7
3. Usecase of MRT MT and FRR . . . . . . . . . . . . . . . . . . 8
4. Usecase of Segment Routing . . . . . . . . . . . . . . . . . . 9
5. NVO3 Usecase . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Big Label Requirements . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
MPLS label format and encoding method have been specified in [RFC
3032] for more than 10 years. The MPLS label value is represented by
20-bit space that can support up to 1 million of instances. This
proven technology has been widely deployed and worked fine for years.
However in the recent years the widespread adoption of network
virtualization especially SDN technologies are being designed and
deployed in data center networks, which have culminated in a new set
Li, et al. Expires April 20, 2014 [Page 2]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
of requirements to the label space, a physical network can be used to
support up to 16 millions of instances of virtualized overlaid
networks. When the MPLS/IP L2/L3 VPN reference model is extended to
interconnect multiple customer sites and data centers, the 20-bit
space for MPLS label value is not readily to address the demanding of
new usecases and requirements.
There a few drafts have proposed the methods to expand the MPLS label
space and the methods to encoding the packet. Typical drafts are
following three:
1. Encoding of Big Labels in MPLS Label Stacks [1]
2. Mega Label - Expansion of MPLS Label Range in [2]
3. MPLS Context-Specific Label Space [3]
However before we move onto discussions about how to expand the label
space, a question for the usecases and requirements needs to be
answered. Another usecases of big label could come from MRT MT FRR
(Maximally Redundant Trees Multi-topology Fast Reroute) and Segment
Routing applications. In what follows we will describe each of use
case in L3VPN, L2VPN, MRT MT FRR and Segment Routing etc areas, and
the according requirements
1.1. Requirement Language
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].
1.2. Terminology
The following terms are used in this document:
VXLAN - Virtual eXtensible Local Area Network
NVGRE - Network Virtualization using Generic Routing Encapsulation
NVO3 - Network Virtualization Over layer 3
MPLS - Multiprotocol Label Switching
VPN - Virtual private network
PE - Provider Edge
CE - Customer Edge
VRF - Virtual Routing and Forwarding
NVE - Network Virtualization Edge
VTEP - VXLAN Tunnel End Point
VNI - VXLAN Network Identifier (VXLAN)
VSID -Virtual Subnet ID (NVGRE)
VNID - Virtual Network ID (NVO3)
VLAN - Virtual Local Area Network
Li, et al. Expires April 20, 2014 [Page 3]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
2. Big Label Usecase for VPN
VPN technology allows customer to connect geographically diverse
sites and data centers across core networks with ensured performance
and security. There are many methods designed for VPN connectivity,
this document will discuss usecases of the MPLS/IP based VPNs. In the
MPLS/IP VPN reference model, at each site there are one or more
Customer Edge (CE) devices, each of which is attached to one or more
Provider Edge (PE) routers via some sort of attachment circuit such
as PPP, Ethernet/VLAN, etc.
When the MPLS IP VPNs reference model is extended to connect to a
virtual network, the CE devices and PE devices on the data center
site can be physically the same device: it will be both the PE device
with respect to the VPN model and the NVE device with respect to the
network virtualization. With different network protocol used in the
data center, for example VXLAN and NVGRE as well as NVO3, the
encoding method of each protocol is different but they all use 24-bit
space to represent the virtual network instances, which bring up a
new requirement for MPLS to support 24-bit label space.
A question comes out: why we need to use one-to-one mapping between a
MPLS label and virtual network id? It is true that some label
sharing method was used to aggregate multiple VNIs into a single MPLS
label, which saves the number of MPLS labels and avoid an one-to-one
mapping between a MPLS label and virtual network id. However one-to-
many mapping always involves extra algorithm like hashing/lookups etc
therefor adds overhead to packet encapsulation that impacts the
performance. Moreover, some deployment uses specific flow
identification that does not allow the label sharing/aggregation. To
ensure efficient traffic distribution in virtual network, there is a
clear need to expand MPLS label space from 20-bits to 24-bits or 32-
bits for gaining better performance and higher network scalability.
Following sections will describe the usecases of L3VPN and L2VPN
respectively.
2.1. MPLS Based L3VPN with VXLAN
The Figure 1 shows a topology where customer sites are connected to a
data center via L3VPN over a MPLS core network; the VXLAN protocol of
[I-D.mahalingam-dutt-dcops-vxlan] is used for network overlay
virtualiztion in the data center. The customer site is connected to
MPLS core via CE and PE devices; while the data center is connected
to MPLS core via a new device with combined functions of PE and VTEP
(VXLAN Tunnel End Point), which is marked as PE-VTEP device in Figure
1. When a network device in CE site wants to send packets to a VM in
the data center, the PE-VTEP device works like a gateway, the VPN
header will carrier VXLAN header information accordingly.
Li, et al. Expires April 20, 2014 [Page 4]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
....................... ..................
. . . .
CE1-| +-------+ +-------+ VXLAN .
|-----| PE | MPLS |PE-VTEP| Network .
CE2-| +-------+ Network +-------+ in .
. . . DataCenter .
Customer . . . .
Sites ....................... ..................
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| LSP label | | Outer label |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| L3 VPN Label | | VXLAN Header |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| dest VM IP | | Inner Label |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
Packet format out of Packet format out of
PE to MPLS network PE-VTEP to VXLAN network
Figure 1. Interconnecting Customer Sites with VXLAN in DC
The PE and PE-VTEP devices on the MPLS core perform the following
functions:
VPN PE functions:
It uses BGP to distribute VPN routes; maintains VRFs; uses MPLS to
receive and forward packets from and to the MPLS network.
VXLAN VTEP functions:
It originates and terminates VXLAN tunnels; runs all the necessary
protocols to build and tear down the VXLAN tunnels; maintains the
VXLAN tunnel forwarding states including the MAC table;
L3VPN-VXLAN interworking functions:
It maintains the mapping information between L3VPN label and VXLAN
VNI. This mapping information is used to receive packets from the
MPLS network and forward them to the VXLAN network, and receive
packets from the VXLAN network and forward them to the MPLS
network
Because VXLAN uses 24-bits for 16 million number of VNIs, accordingly
the existing 2^20 MPLS labels cannot provide one-to-one mapping for
the possible virtual network instances. In order to provide one-one
mapping between VPN labels and VNIs that can ensure efficient packet
encapsulation and distribution of traffic across MPLS core that
interconnects the customer sites with VXLAN networks, we need to
Li, et al. Expires April 20, 2014 [Page 5]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
expand the MPLS label space from 20-bits to at least 24-bits to
support 16 million of label values. Thus in this is the usecase we
need big label.
2.2. MPLS Based L3VPN with NVGRE
NVGRE is another protocol designed to support the multi-tenant and
massive number of virtual network instances in data center networks.
NVGRE uses GRE as a method to tunnel L2 packets across MPLS/IP
network, and a 24-bit segment identifier in the form of a VSID
(virtual subnet ID), which allows LAN segments to scale to 16 million
in each data center. NVGRE allows each LAN segment to be extended
across MPLS/IP core network.
NVGRE is similar to VXLAN architecturally. The Figure 2 shows a
topology where customer sites are connected to a data center via
L3VPN over a MPLS core network; the NVGRE protocol is used for
network overlay virtualiztion in the data center. The customer site
is connected to MPLS core via CE and PE devices; while the data
center is connected to MPLS core via a new device with combined
functions of PE and NVE (virtual network edge), which is marked as
PE-NVE device in the Figure. When a network device in CE site wants
to send packets to a VM in the data center, the PE-NVE device works
like a gateway that maps the VPN header and NVGRE header
accordingly.
....................... ..................
. . . .
CE1-| +-------+ +-------+ NVGRE .
|-----| PE | MPLS |PE-NVE | Network .
CE2-| +-------+ Network +-------+ in .
. . . DataCenter .
Customer . . . .
Sites ....................... ..................
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| LSP label | | Outer label |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| L3 VPN Label | |NVGRE Header(VSID) |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| dest VM IP | | Inner Label |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
Packet format out of Packet format out of
PE to MPLS network PE-VTEP to NVGRE network
Figure 2. Interconnecting Customer Sites with NVGRE in DC
The Provider Edge device PE and PE-NVE device will perform the
Li, et al. Expires April 20, 2014 [Page 6]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
following functions:
VPN PE functions:
It uses BGP to distribute VPN routes; maintains VRFs; uses MPLS to
receive and forward packets from and to the MPLS network.
NVGRE Endpoint functions:
It originates and terminates NVGRE packets; maintains the NVGRE
Virtual Subnet Identifier (VSID) for NVGRE
L3VPN-NVGRE Interworking Functions:
It maintains the mapping information between L3VPN label and NVGRE
Virtual Subnet Identifier (VSID). This mapping information is
used to receive packets from the MPLS network and forward them to
the NVGRE virtual network, and receive packets from the NVGRE
virtual network and forward them to the MPLS network
Because NVGRE uses 24-bits for 16 million number of VSIDs,
accordingly we need to expand the MPLS label space from 20-bits to
24-bits. This way PE-VNE can ensure efficient distribution of traffic
across MPLS core. This is the use case we need big label too.
2.3. MPLS Based L2VPN
In some situation, a L2 network must be extended beyond the single
data center, for example when the application and framework developed
for a campus has to be shared by multiple geographic areas, spread
over multiple data centers and cross long distances. Typically some
customer wants server-to-server communication between a primary and
backup data centers cross a MPLS core network. To ensure high speed
service, secure connectivity, high availability, application mobility
and cost-effective requirements, L2 VPN is a good solution to meet
all of the demands.
Generally the service provider's customers require a range of VLANs
to handle multiple applications in case of L2VPN. VLAN Identifier
(VID) uses a 12-bit field specifying the VLAN to which the frame
belongs, it allows up to 4,096 VLAN intances. For this range, the
current 20-bit MPLS label space is enough. However along with the
increasing number of VLANs and VMs in data center, some technology
such as E-VPN and Q-in-Q have been proposed to support large-scale
L2VPNs with resiliency.
A good example is illustrated at Figure 3 that gives a topology of
data center LAN extension using L2VPN over MPLS core network. In this
usecase data center uses IEEE 802.1Q-in-Q VLAN Tag Termination for
intranet. Q-in-Q added another layer of VLAN tag (called "metro tag"
or "PE-VLAN") to serve the purpose of VLAN space expansion. In such a
Li, et al. Expires April 20, 2014 [Page 7]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
way, a data center could support 4096 * 4096 allowing 16 million of
VLAN IDs; therefor the 20-bit MPLS label space is no longer
sufficient to provide a one-to-one mapping between the double tagged
VLAN IDs and a MPLS label. The one-to-one mapping can be done by
expand the MPLS label space to 24-bits as it is shown at Figure 3.
.................. .................... ..................
. . . . . .
. Q-in-Q VLAN +-------+ +-------+ Q-in-Q VLAN .
. in |PE-VLAN| MPLS |PE-VLAN| in .
. DataCenter +-------+ Network +-------+ Data Center .
. . . . . .
.................. .................... ..................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Outer VLAN ID |Inner VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| inner label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet format out of PE-VLAN
towards MPLS network
Figure 3. L2VPN Data Center (Q-in-Q) cross MPLS core
In Figure 3, double tagged VLAN IDs occupy 24-bit label space, it
provided a usecase and requirement for MPLS big label.
3. Usecase of MRT MT and FRR
In some deployment of Fast Reroute protection, the global label
allocation(GLA) is used to represent a LSP for fast switchover. In
the event of a link failure, traffic on an LSP is rerouted to the
next-hop using a pre-configured backup LSP identified by a global
MPLS label. With GLA, Protected LSP and backup LSP can be setup
through same interface, any MPLS frame received will be switched
based on its global label regardless its incoming interface. Together
with make-before-break method it can achieve the fast traffic
recovery.
When the same FRR mechanism is applied to MRT MT (Maximally Redundant
Trees Multi-topology) scenario, the 20-bit MPLS label space will not
be sufficient. For example, assume that there are three topologies
Li, et al. Expires April 20, 2014 [Page 8]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
configured in a MPLS core network, each topology is colored to yellow
(default), red and blue respectively. When enabling the whole network
FRR by incremental deployment of LDP MT in the IP network, the MPLS
label has to be globally unique in order to achieve fast reroute.
Since the number of Internet route is around 500,000 based on some
statistics, when MPLS labels are allocated in the yellow (default),
blue and red multi-topology respectively and simultaneously, the
required labels for allocation will reach 3 times 500,000 at least
1.5million, thus it exceeds the existing 20-bit MPLS label range of 1
million labels.
This kind of use cases impose a requirement to the MPLS big label.
4. Usecase of Segment Routing
Segment Routing is another example of the use cases that may
potentially require MPLS big label. The Segment identification SID
uses 32-bit space(draft-filsfils-rtgwg-segment-routing-00), it is
used either for a topological instruction or a service instruction.
An instruction associated with a global segment is recognized and
executed by any SR-capable node in the domain.
Because MPLS label space has only 20-bits, the right-most bits of the
segment are encoded as a label. This implies that the SID values are
allocated within a reduced 20-bit space out of the 32-bit SID space,
the maximum number of segments in a routing domain is limited to 1
million not as SR was designed for 4 Billion with 32-bit SID space.
It is a reasonable question if it will eventually hits the
scalability issue once the size of the network increases to a certain
degree. As soon as the number of segments exceed 1 million in a
network domain, for example a SDN domain, the 20-bit MPLS label space
will need to be expanded from 20-bit to bigger number such as 24-bits
or 32-bits.
5. NVO3 Usecase
NVO3 is an on-going effort to standardize solutions to data center
virtualizaiton with the goal of providing viable data encapsulation
and protocols across a scaling range of a few thousand VMs to several
million VMs running on greater than one hundred thousand physical
servers. NVO3 considers approaches to multi-tenancy that reside at
the network layer rather than using traditional isolation mechanisms
that rely on the underlying layer 2 technology (e.g. VLANs).
Based on NVO3 framework and problem statement, NVO3 will deliver 16
million virtual networks in a physical data center. As described for
L3 and L2 VPN use cases, we will need to solve the problem of
associating MPLS labels to NVO3 VNIDs, thus it implies another
Li, et al. Expires April 20, 2014 [Page 9]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
potential use case for MPLS big label.
6. Big Label Requirements
When design MPLS big label applied to the use cases described in this
document, following requirements should be considered.
1. An extension to the MPLS label format of RFC 3032 should be
specified for big label
2. Big label label needs 24-bit space with 16 million of labels to
support interworking with VXLAN/NVGRE/NVO3; The same requirement
is applicable for L2VPN in case of using Q-in-Q
3. Big label needs 32-bit space with 1 billion of labels in order
to support the number of SIDs specified by Segment Routing
4. PE device in MPLS core network must advertise its big label
process capability to other devices in the same routing domain
5. Every PE device must enable big label capability in order to
distribute traffic using big label in the same routing domain. A
mechanism needs to be specified if allowing some explicit nodes
not to use big label in this routing domain.
6. PE devices must be capable to support expanded number of
virtual interfaces and forwarding entries etc that could reach 16
million or 1 billion in the worst case.
7.Big label framework needs to be backward compatible. The network
device supporting big label must too have capability to process
regular 20-bit label.
8. The big label should work with the existing MPLS hardware
architecture
7. IANA Considerations
The requirements on IANA are specified in other related documents
[I-D.draft-renwei-mpls-big-label] and [I-D.draft-renwei-mpls-bgp-
big- label], which request a reserved label to represent Big Label
Indicator and BGP capabilities for big labels.
8. Security Considerations
This draft does not add any additional security implications to
the BGP/MPLS IP VPNs. All existing authentication and security
Li, et al. Expires April 20, 2014 [Page 10]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
mechanisms for MPLS still apply.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
1999.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
9.2. Informative References
[1] R.Li and M.Li,"Encoding of Big Labels in MPLS Label Stacks",
[draft-renwei-mpls-big-label-00] June, 2013
[2] Z.Li and L.Zheng,
"Mega Label - Expansion of MPLS Label Range"
[draft-li-mpls-mega-label-00] July, 2013
[3] R. Aggarwal,Y. Rekhter and E. Rosen,
"MPLS Upstream Label Assignment and Context-Specific Label Space"
[RFC5331] August, 2008
[4] R.Li, K.Zhao and W.Wu,
"The Use of Big Labels for BGP/MPLS IP VPN",
[draft-renwei-l3vpn-big-label-00] June, 2013
[I-D.mahalingam-dutt-dcops-vxlan]
Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A
Framework for Overlaying Virtualized Layer 2 Networks over
Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-03
(work in progress), February 2013.
[I-D.sridharan-virtualization-nvgre]
Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang,
Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P.,
and C. Tumuluri, "NVGRE: Network Virtualization using
Generic Routing Encapsulation", draft-sridharan-
virtualization-nvgre-02 (work in progress), February 2013.
Li, et al. Expires April 20, 2014 [Page 11]
Internet-Draft MPLS Big Label Usecases and Requirements October 2013
Authors' Addresses
Renwei Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: renwei.li@huawei.com
Katherine Zhao
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: katherine.zhao@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Li, et al. Expires April 20, 2014 [Page 12]
