Internet DRAFT - draft-lzl-mpls-ucase-n-20bit-label-limitation
draft-lzl-mpls-ucase-n-20bit-label-limitation
MPLS Working Group Richard Li
Internet-Draft Katherine Zhao
Intended status: Informational Robin Li
Expires: December 25,2015 Huawei Technologies
June 25,2014
MPLS Deployments and Use Cases That Cannot be Solved
By Using 20-bit Label
draft-lzl-mpls-ucase-n-20bit-label-limitation-00
Abstract
The MPLS label format and encoding method are specified in
[RFC3032], the label value is represented using the 20-bit space and
supports up to 1 million of instances. As exponential Internet growth
continues there are specific network deployment scenarios where a
clear need to represent more than one million entities is required.
This document describes the MPLS deployment scenarios, use
cases, and requirements, where the current 20-bit label will no
longer be sufficient.
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 [Date].
Copyright Notice
Copyright (c) 2014 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
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 . . . . . . . . . . . . . . . . . . . . . . . . .
1.1. Requirement Language . . . . . . . . . . . . . . . . . . .
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . .
2. VPN Use Cases . . . . . . . . . . . . . . . . . . . . . . . .
2.1. L3VPN with VXLAN and NVGRE Use Cases . . . . . . . . . . .
2.1.1 The Argument for >1 Million Identifiers . . . . . . . .
2.2. MPLS Based L2VPN . . . . . . . . . . . . . . . . . . . . .
3. Usecase of MRT MT and FRR . . . . . . . . . . . . . . . . . .
4. NVO3 Use Case . . . . . . . . . . . . . . . . . . . . . . . .
5. General Requirements . . . . . . . . . . . . . . . . . . . . .
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .
7. Security Considerations . . . . . . . . . . . . . . . . . . .
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1. Normative References . . . . . . . . . . . . . . . . . . .
8.2. Informative References . . . . . . . . . . . . . . . . . .
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .
1. Introduction
MPLS label format and encoding method have been specified in
[RFC3032] 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 as well as SDN technologies are
being designed and deployed in data center and cloud networks,
which have culminated in a new set of requirements to use a MPLS
label to represent more than one million of instances.
This document sets out to identify the deployment scenarios and use
cases that require more than 2^20 identifiers in the same MPLS
label space, and therefore cannot be supported by the existing
20-bit label.
1.1. Terminology
The following terms are used in this document:
CE - Customer Edge
DC - Data Center
MPLS - Multi protocol Label Switching
NVE - Network Virtualization Edge
NVGRE - Network Virtualization using Generic Routing Encapsulation
NVO3 - Network Virtualization Over layer 3
PE - Provider Edge
VLAN - Virtual Local Area Network
VNI - VXLAN Network Identifier (VXLAN)
VNID - Virtual Network ID (NVO3)
VPN - Virtual private network
VRF - Virtual Routing and Forwarding
VSID -Virtual Subnet ID (NVGRE)
VTEP - VXLAN Tunnel End Point
VXLAN - Virtual eXtensible Local Area Network
2. VPN Use Cases
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, the following
sub-sections will discuss use cases of BGP MPLS/IP based L3 and L2
VPN respectively.
2.1 L3VPN with VXLAN and NVGRE Use Cases
In the BGP MPLS based 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 Ethernet/VLAN, etc. When the VPN reference model is
extended to connect virtual networks, the CE and PE devices on the
data center site can be physically combined into a same device,which
performs the PE function with respect to the VPN model and the
Network Virtual Entity function of data center. With different
network protocol used in the data center such as VXLAN or NVGRE, the
encoding method of each protocol is different but both use 24-bit
space to represent up to 16 million virtual network instances.
Figure 1 shows a sample topology where customer sites are connected
to a data center via L3VPN over a MPLS core network. Customer sites
are L3 networks; the VXLAN protocol [I-D.mahalingam-dutt-dcops-vxlan]
is used in data center. Between the data center and MPLS core is a
new device with combined functions of PE and VTEP (VXLAN Tunnel End
Point), which is named as PE-VTEP in Figure 1. When a network entity
at CE site wants to send packets to a VM in the data center, the PE-
VTEP device works like a gateway, the L3 VPN id can be carried over
via a MPLS label cross the core network. When packets get into the
data center, a VPN id can be mapped into a VNI (virtual network
identifier) of VxLAN network, this way customer L3 networks are
connected to data center via L3 VPN cross core while the traffic
remains private within the VPN.
....................... ..................
. . . .
CE1-| +-------+ +-------+ VXLAN .
CE2-|-----| PE | MPLS |PE-VTEP| Network .
CE3-| +-------+ Network +-------+ in .
Customer . . . DataCenter .
L3 Networks . . . .
....................... ..................
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Payload | | Payload | | Payload |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| IP | | dest VM IP | | VM IP |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| L3VPN(VNI)Label | | VXLAN Header |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| LSP Label | | UDP/IP |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
<--------------->|<-------------------->|<---------------->
Original Packet Packet format between Packet format
in Customer site PE and PE-VTEP in data center
L3 network in MPLS core 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 inter-working 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
VXLAN uses a 24-bit segment identifier in the form of a VNI (virtual
network identifier) in data center. It resolved the issue caused by
4096 limitation of VLAN (IEEE802.Q) that do not provide enough
segments for scalable cloud deployment.
NVGRE is another use case similar to VXLAN architecturally. 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). NVGRE allows LAN segments to scale to 16 million in each data
center; each LAN segment can be extended across MPLS/IP core
network.
Figure 2 shows a topology similar to Figure 1 except that the VXLAN
is replaced by NVGRE within the data center; and PE-VTEP is replaced
by PE-NVE that works like a gateway mapping VPN header and NVGRE
header accordingly.
....................... ..................
. . . .
CE1-| +-------+ +-------+ NVGRE .
|-----| PE | MPLS |PE-NVE | Network .
CE2-| +-------+ Network +-------+ in .
. . . DataCenter .
Customer . . . .
Sites ....................... ..................
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Payload | | Payload | | UDP (IP) |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| IP | | dest VM IP | |NVGRE Hdr(VSID)|
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| VPN(VSID)Label| | IP |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| LSP Label |
+-+-+-+-+-+-+-+-+
<--------------->|<------------------------>|<--------------->
IP Packet Packet format out of Packet format out
in L3 Network PE to MPLS network of PE-VTEP to
NVGRE network
Figure 2. Interconnecting Customer Sites with NVGRE in DC
Based on these scaling considerations outlined previously for VXLAN
and NVGRE use cases, the current 20-bit MPLS label space
limitation, supporting up to 1 million virtual network segments,
will not be sufficient for future DC-based MPLS deployments and
use cases.
2.1.1 The Argument for >1 Million Identifiers
VMs need to be on the same VN to communicate each other in order
to ensure the information privacy and traffic isolation from
outside of the VN. In the old time a virtual network may be shared
by an enterprise or a large group of the people, the number of VNIs
were just in the order of hundreds or thousands while a data center
held only several tens of thousands servers, back then the VLAN
technology (support 4096 segments) was sufficiently used for many
years.
However, along with the new technology such as cloud, mobile Internet
and Internet of Things became mature and reality, the world is in the
midst of a dramatic transformation to Internet enabled devices, the
data center scale has gone up explosively. Based on
StorageServers.com, Microsoft built its own data center with 500,000
sq ft in 2006 and held about 100,000 servers today. Based on
Forbes.com, the world largest data center will reach 6.3million sq ft
(completion in 2016, Langfang, China) increasing nearly 12 times
(6.3million sq ft/500,000 sq ft). It is safe to assume that the data
center can hold 6 times more, e.g. 600,000 servers in 2016. Assume
each server holds 16 VMs and uses 2 VNIs in average conservatively,
and then the largest data center could need 12 million VNIs (600,000
servers *2 VNIs) after year 2016, many other data center will also
need more than 1 million VNIs based on this trend. The current 20-bit
label cannot support it therefore we need a solution to meet the
demand.
Another question is why we need to use one-to-one mapping between a
VPN label and virtual network id VNI? It is true that some label
sharing method can be used to aggregate multiple VNP IDs into a
single MPLS label, and then decode it by PE-VTEP and map to
corresponding VNIs in the data center. This kind of methods use one-
to-many mapping to save the number of MPLS labels thus no need to
expand 20-bits label space. However one-to-many aggregation always
involve extra algorithm like hashing/lookups etc, which adds overhead
to packet encapsulation and then impacts the traffic performance.
Moreover, some deployment uses specific flow identification that does
not allow the label sharing/aggregation. To ensure efficient traffic
distribution and packet encapsulation in virtual network, there is a
clear advantage to use one-to-one mapping for gaining better
performance and higher network scalability.
2.2. Use Case of L2 EVPN over MPLS
BGP MPLS based EVPN (Ethernet VPN) introduces a new model for
delivery of Ethernet services,which extends L2 connectivity for all
connected customer sites and data centers. EVPN was driven by
marketing requirements such as MAC address scalability; Load
balancing and all-active redundancy; optimal forwarding and fast
convergence and so on. IETF draft [draft-ietf-l2vpn-evpn-07]
specified BGP MPLS based Ethernet VPN protocol.
Figure 3 illustrates a sample use case of EVPN deployment. As with
L3 VPNs, a L2 EVPN network is comprised of customer edge (CE) devices
(host, router, or switch) connected to provider edge (PE) devices.
The difference is that EVPN forwarding is based on destination MAC
address other than IP address in L3 VPN architecture.
.......................
. .
CE1-| +-------+ +------+ |-CE3
|-----| PE | | PE |-----|-CE4
CE2-| +-------+ +------+ |-CE5
. MPLS Network .
Customer . . Customer
Sites ....................... Sites
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| Ethernet | | Ethernet | | Ethernet |
| Frame | | Frame | | Frame |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| EVPN Label(EVI) |
+-+-+-+-+-+-+-+-+-+
| LSP Label |
+-+-+-+-+-+-+-+-+-+
<-------------------->|<-------------------->|<------------------->
Original Packet Packet format Packet format
in Customer site between PE's in Customer site
L2 network in MPLS core L2 Network
Figure 3. L2 networks via BGP/MPLS based L2 EVPN
EVPN protocol specified ESI to identify an Ethernet segment, there
could be one to many VLANs within a segment. ESI is a ten octets
integer while VID (VLAN ID) is a 12-bit filed. Therefore EVPN
allows very large number of EVPNs been deployed over a service
provider's MPLS network, each providing network connectivity to
customers while ensuring the traffic sharing remains private within
a VPN.
When an ingress PE floods multi-destination traffic, an EVI (EVPN
identifier, see Figure 3 above) label is mapped to ESI, VID and
destination MAC address at the customers L2 network. In case a
customer site has more than 1 million connected network devices
/VMs, each need an EVPN ID, then the current MPLS 20-bit label
cannot support this demand.
3. Use Case 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 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 additional requirement to the MPLS
big label.
4. NVO3 Use Case
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 similar to VXLAN
and NVGRE. 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
will be a potential use case for MPLS big label.
5. General Requirements
When design MPLS big label applied to the use cases described in
this document, following requirements should also be considered.
1. An extension to the MPLS label format of [RFC3032] should be
specified for big label
2. Big label label needs 24-bit space with 16 million of labels to
support inter-working 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
6. IANA Considerations
This document makes no requests for IANA actions.
7. Security Considerations
This draft does not add any additional security implications to
the BGP/MPLS IP VPNs. All existing authentication and security
mechanisms for MPLS still apply.
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.
[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.
8.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
[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.
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
