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]