Internet DRAFT - draft-li-mpls-mega-label
draft-li-mpls-mega-label
Network Working Group Z. Li
Internet-Draft L. Zheng
Intended status: Standards Track Huawei Technologies
Expires: January 09, 2014 July 08, 2013
Mega Label - Expansion of MPLS Label Range
draft-li-mpls-mega-label-00
Abstract
This document describes the requirement scenarios for expansion of
MPLS label range. This document also introduce a framework for
expansion of MPLS label range-"Mega Label" and the corresponding
protocol extensions. This document will update RFC 3032, 5036, 3209
and 3107 if approved.
Requirements 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].
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 09, 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
Li & Zheng Expires January 09, 2014 [Page 1]
Internet-Draft MPLS Mega Label July 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirement Scenarios . . . . . . . . . . . . . . . . . . . . 3
3.1. LDP Multi-Topology for MRT FRR . . . . . . . . . . . . . 3
3.2. Label Allocation in VPN . . . . . . . . . . . . . . . . . 3
3.3. Virtual Network Instance . . . . . . . . . . . . . . . . 3
4. Framework of Mega Label . . . . . . . . . . . . . . . . . . . 4
4.1. Label Stack for Expansion of Label Range . . . . . . . . 4
4.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5
5.1. MPLS LDP . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. MPLS RSVP-TE . . . . . . . . . . . . . . . . . . . . . . 5
5.3. MP-BGP . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
MPLS technology is widely used, but its limited label space which is
restricted by the 20bits encoding prevents the MPLS technology from
many applications.
This document describe application scenarios that will generate
requirements on expansion of MPLS label range. This document also
introduce a framework for expansion of MPLS label range - the concept
"Mega Label", and the corresponding protocol extensions. This
document will update RFC 3032, 5036, 3209 and 3107 if approved.
Li & Zheng Expires January 09, 2014 [Page 2]
Internet-Draft MPLS Mega Label July 2013
2. Terminology
LDP MT: LDP Multi-Topology
MRT: Maximally Redundant Trees
3. Requirement Scenarios
3.1. LDP Multi-Topology for MRT FRR
In MRT(Maximally Redundant Trees) FRR
scenario([I-D.ietf-rtgwg-mrt-frr-architecture]), when enabling the
whole network FRR by incremental deployment of LDP MT in the pure IP
network([I-D.li-rtgwg-ldp-mt-mrt-frr]), since the number of internet
route is around 500,000, when MPLS labels are allocated in the
default topology, blue and red multi-topology simultaneously, the
required labels for allocation will reach at least 1.5million. It
exceeds the existing MPLS label range dramatically.
3.2. Label Allocation in VPN
In some L3VPN([RFC4364]) deployment, the number of private route
already reaches the scale of several ten thousands. The label
allocation per Instance method may save the labels to some extent,
but it could not be used in some deployment owing to the
impossibility of specific flow identification caused by label
sharing. Then The label allocation per prefix method maybe have to
be used instead and it leads to the required label amount exceeding
the existing MPLS label range.
E-VPN([I-D.ietf-l2vpn-evpn]) works in a similar way as L3VPN as to
label allocation, but the MAC route could not be aggregated like IP
route. This will result in an even worse bottleneck regarding label
range for deployment of E-VPN.
3.3. Virtual Network Instance
In NVO3 Scenario([I-D.ietf-nvo3-overlay-problem-statement]), such
solutions as VXLAN are introduced to meet the multi-tenant
requirement. It extends the number of virtual network instances to
24bits, i.e. 2^24. Accordingly, the 2^20 label range of MPLS is not
enough to support the possible virtual network instances.
Li & Zheng Expires January 09, 2014 [Page 3]
Internet-Draft MPLS Mega Label July 2013
4. Framework of Mega Label
4.1. Label Stack for Expansion of Label Range
With Mega Label, the label space is extended by stacking MPLS labels
as defined in [RFC3032] . As shown in Figure 1, Mega Label consists
of Base Label and Remainder Label. The outer layer label for the
Mega Label is called as "Base Label", its unit is M (2^20). The
inner layer label for the Mega Label is called "Remainder Label".
There could be multiple Base Labels but only one Remainder Label for
one Mega Label. If there are multiple Base Labels which represent
the label value N*1M and the value of Remainder Label is K, then the
value of the Mega Label is N*1M + K. M is used as unit of Base Label
in this document for acquiring larger label range.
0 32 64
+-------------------+-----+-+---------+~+-------------------+-----+-+---------+
| Base Label | TC |S| TTL | | Remainder Label | TC |S| TTL |
+-------------------+-----+-+---------+~+-------------------+-----+-+---------+
Figure 1: Encapsulation of Mega Label
Base Label could be indicated by the MPLS special labels. For
example, special label 5 could be used to indicate the actual base
label value 1M. There are only 16 special labels and the label value
0/1/2/3/7/11/13/14 has already been allocated. Dynamic labels which
range is from 16 to 2^20-1 could also be used to indicate a Base
Label to solve the above possible limitation proposed by the special
label. When a dynamic label is used to indicated a Base Label, it
SHOULD be reserved by the downstream LSR for the special usage and no
longer be allocated for normal label forwarding.
4.2. Data Plane
When a LSR receives a MPLS packet carrying a Base Label, it SHOULD
NOT forward the packet based on this label. Lower layer of label(s)
need to be decapsulated and until the Remainder Label is reached.
The LSR SHOULD calculate the value of the Mega label based on the
actual label value indicated by Base Label(s) and the value of
Remainder Label, and then lookup its forwarding table and forward the
packet accordingly. The value of EXP/TTL/S field in the Base Label
should be consistent with same fields of the lower layer remainder
layer. In case of the inconsistency, the value of the EXP/TTL field
in the Remainder Label takes precedence.
4.3. Control Plane
Li & Zheng Expires January 09, 2014 [Page 4]
Internet-Draft MPLS Mega Label July 2013
MPLS label distribution protocols include LDP, RSVP-TE and MP-BGP
etc. These protocols need to be extended to enabling Mega label
allocation for one FEC, including Base Label and Remainder Label.
5. Protocol Extensions
5.1. MPLS LDP
The encoding of the LDP Mega Label TLV is as follows, the Mega Label
TLV type is to be allocated by IANA. There could be multiple Base
Labels and only one Remainder Label in one Mega Label TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Mega Label (TBA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label 2 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label n (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remainder Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. LDP Mega Label TLV
5.2. MPLS RSVP-TE
The encoding of the RSVP-TE Mega Label Object including the common
object header is as follows, the C_Type is to be allocated by IANA.
There could be multiple Base Labels and only one Remainder Label in
one Mega Label Object.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type(TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label 2 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li & Zheng Expires January 09, 2014 [Page 5]
Internet-Draft MPLS Mega Label July 2013
| Base Label n (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remainder Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. RSVP-TE Mega Label Object
5.3. MP-BGP
The encoding of the MP-BGP Mega Label NLRI is as follows, the label
field carries multiple Base Label and only one Remainder Label. Each
label is encoded as 3 octets, where the high-order 20 bits contain
the label value and the low order bit contains "Bottom of Stack" (as
defined in [RFC3032]). The "Bottom of Stack" is cleared for the
first and following labels which means it is a Base Label, and the
"Bottom of Stack" is set for the last label which means it is a
Remainder Label.
+---------------------------+
| Length (1 octet) |
+---------------------------+
|Base Label 1(3 octets) |
+---------------------------+
|Base Label 2(3 octets)(O) |
+---------------------------+
.............................
+---------------------------+
|Base Label n(3 octets)(O) |
+---------------------------+
|Remainder Label (3 octets) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
Figure 4. MP-BGP Mega Label NLRI
6. IANA Considerations
The IANA is requested to assign a new TLV from the "TLV Type Name
Space " registry.
Value Meaning Reference
----- -------------- ---------
TBA Mega Label TLV this document (sect 4.1)
The IANA is requested to assign a new C-Type from the "Class Type "
registry.
Li & Zheng Expires January 09, 2014 [Page 6]
Internet-Draft MPLS Mega Label July 2013
Value Meaning Reference
----- ------------------ ---------
TBA RSVP-TE Mega Label this document (sect 4.2)
7. Security Considerations
TBD
8. Acknowledgements
The authors would like to thank Loa Andersson for his valuable
comments and suggestions on this draft.
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.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
9.2. Informative References
[I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F.,
Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN",
draft-ietf-l2vpn-evpn-03 (work in progress), February
2013.
[I-D.ietf-nvo3-overlay-problem-statement]
Li & Zheng Expires January 09, 2014 [Page 7]
Internet-Draft MPLS Mega Label July 2013
Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L.,
and M. Napierala, "Problem Statement: Overlays for Network
Virtualization", draft-ietf-nvo3-overlay-problem-
statement-03 (work in progress), May 2013.
[I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura,
J., Konstantynowicz, M., White, R., and M. Shand, "An
Architecture for IP/LDP Fast-Reroute Using Maximally
Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-02
(work in progress), February 2013.
[I-D.li-rtgwg-ldp-mt-mrt-frr]
Li, Z., Chou, T., Zhao, Q., and T. Yang, "Applicability of
LDP Multi-Topology for Unicast Fast-reroute Using
Maximally Redundant Trees", draft-li-rtgwg-ldp-mt-mrt-
frr-02 (work in progress), April 2013.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Lianshu Zheng
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: vero.zheng@huawei.com
Li & Zheng Expires January 09, 2014 [Page 8]
