Network Working Group Z. Li Internet-Draft Q. Zhao Intended status: Informational X. Chen Expires: January 4, 2015 Huawei Technologies T. Yang China Mobile R. Raszuk Individual July 3, 2014 A Framework of MPLS Global Label draft-li-mpls-global-label-framework-02 Abstract The document defines the framework of MPLS global label including the label allocation method for MPLS global label, the representation of MPLS global label and the process of control plane and data plane for MPLS global label. 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 4, 2015. Li, et al. Expires January 4, 2015 [Page 1] Internet-Draft A Framework of MPLS Global Label July 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. MPLS Global Label Allocation Methods . . . . . . . . . . . . 3 3.1. Special-Purpose MPLS Label . . . . . . . . . . . . . . . 3 3.2. Domain Wide Labels . . . . . . . . . . . . . . . . . . . 3 3.2.1. Label Allocation Methods . . . . . . . . . . . . . . 4 4. Representation of MPLS Global Label . . . . . . . . . . . . . 4 4.1. Per-platform Label Space . . . . . . . . . . . . . . . . 4 4.2. Context-Specific Label Space . . . . . . . . . . . . . . 5 5. Control Plane for MPLS Global Label . . . . . . . . . . . . . 5 5.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 5.2. In-Band Global Label Allocation . . . . . . . . . . . . . 7 5.2.1. Label Allocation in Per-Platform MPLS Label Space . . 7 5.2.2. Label Allocation in Context-Specific Label Space . . 9 5.3. Label Mapping Distribution . . . . . . . . . . . . . . . 9 5.4. Inter-Domain Label Negotiation . . . . . . . . . . . . . 9 5.5. Protocol Extensions Requirement . . . . . . . . . . . . . 10 5.5.1. IGP Protocol Extensions . . . . . . . . . . . . . . . 10 5.5.2. BGP Protocol Extensions . . . . . . . . . . . . . . . 10 5.5.3. PECP Protocol Extensions . . . . . . . . . . . . . . 10 6. Data Plane of MPLS Global Label . . . . . . . . . . . . . . . 11 6.1. Global Label in Per-Platform Label Space . . . . . . . . 11 6.2. Global Label in Context-Specific Label Space . . . . . . 11 6.3. Global Process of Inner Global Label . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Li, et al. Expires January 4, 2015 [Page 2] Internet-Draft A Framework of MPLS Global Label July 2014 1. Introduction [I-D.li-mpls-global-label-usecases] proposes possible usecases of MPLS global label. MPLS global label can be used for identification of the location, the service and the network in different application scenarios. Serveral MPLS global label allocation mechanisms has been proposed in [RFC5331], [I-D.raszuk-mpls-domain-wide-labels], etc.. This document is to define the framework for MPLS global label based on the existing work and more emerging applications. The framework includes the label allocation method for MPLS global label, the representation of MPLS global label and the process of control plane and data plane for MPLS global label. 2. Terminology FEC: Forward Equivalence Class MVPN: Multicast VPN PCE: Path Computation Element SRGB: Global Segment Routing Block 3. MPLS Global Label Allocation Methods MPLS global label is the label which meaning can be understood by all nodes or part of nodes in the network. These nodes can be nodes in one domain or nodes spanning multiple domains. 3.1. Special-Purpose MPLS Label Special-purpose MPLS label defined in [RFC7274] is a type of special global label. These labels have specific well-known meaning which can be understood and processed accordingly by all MPLS nodes in the network. These labels are allocated and retired by IANA. How to allocate and retire these labels is specified in [RFC7274]. 3.2. Domain Wide Labels Besides the special-purpose labels which have the global meaning and are defined by the IANA, it is necessary to provide dynamic allocation mechanisms to allocate global labels to satisfy requirements of emerging possible applications ([I-D.li-mpls-global-label-usecases] ). Such global labels may be not possible to be understood by all network nodes like the special- purpose label. That is, these labels may be only understood by all Li, et al. Expires January 4, 2015 [Page 3] Internet-Draft A Framework of MPLS Global Label July 2014 nodes or part of nodes in one domain or multiple domains. This type of global label can also be called as Domain Wide Label. The scope of domains for Domain Wide Label is service-specific or management- specific which is out of scope of this document. Note: In the following sections of this document, the global label always means Domain Wide Label. That is, the global label and the Domain Wide Label have the same meaning. 3.2.1. Label Allocation Methods There are two types of label allocation methods for Domain Wide Labels: out-of-band label allocation and in-band label allocation. Out-of-band label allocation means that the global labels are planned and designated manually for special usage. The typical scenario is Segment Routing. When MPLS is applied for Segment Routing, the global labels allocated for node segments is based on the reserved SRGB and the designated unique Segment ID. In essence the global uniqueness of these label is guaranteed by manual planning. So this method can be seen as the out-of-band label allocation. In-band label allocation means that the global labels are requested and allocated dynamically through control protocols in the domains. The typical example is the upstream MPLS label assignment defined in [RFC5331]. The method has been adopted in BGP-based MVPN ([RFC6514]) in which the root PE allocates labels to represent MVPN instances and advertise the label binding to leaf PEs for the scenario that multiple MVPNs shares one P-multicast tree. Choice of the two methods is related with scalability of the possible applications. If the scale of the application is limited, the out- of-band method is enough. Otherwise, the in-band method must be taken into account. 4. Representation of MPLS Global Label 4.1. Per-platform Label Space The labels in the per-platform label space can be used for Domain Wide label. The advantage of this method is that the existing MPLS forward plane which is used for widely deployed applications based on the per-platform label can be reused well to support global labels. The challenge for the method is that the existing MPLS protocols such as LDP, BGP and RSVP-TE are always allocate local labels from the space which may cause the confliction with the global label allocation. This confliction could be prevented through division of Li, et al. Expires January 4, 2015 [Page 4] Internet-Draft A Framework of MPLS Global Label July 2014 the per-platform space into multiple segments used for local label and global label respectively. 4.2. Context-Specific Label Space The concept of Context-Specific Label Space is defined in [RFC5331]. The labels in Context-Specific label space can also be used for Domain Wide label. The Context-Specific label space is isolated from the per-platform label space and the confliction issue of label allocation can be avoided naturally. The challenge for the method is the possible complexity of both control plane and forward plane introduced by multiple label spaces management. If the Context-Specific label space is used for global labels, it is necessary to determine the Context Identifier for the label space. There are two methods as follows: -- Service-specific Context Identifier: The Context Identifier is determined by the service. For example, in [RFC6514], the Tunnel- Specific label space is introduced in which the P-Tunnel Identifier becomes the Context Identifier for the label space. -- MPLS Global Label Indicator: It is to define a well-known Context- Specific label space for global label. The label space is indicated by the MPLS Global Label Indicator which can be seen as a well-known Context Identifier. In the forwarding plane, the MPLS Global Label Indicator is a special-purpose label to indicate that next label in the MPLS label stack of each transported packet is Domain Wide Labels. The value of the special-purpose label needs to be allocated by IANA according to [RFC7274]. 5. Control Plane for MPLS Global Label 5.1. Architecture Li, et al. Expires January 4, 2015 [Page 5] Internet-Draft A Framework of MPLS Global Label July 2014 +-------------------------------+ +-------------------------------+ | Network Domain 1 | | Network Domain 2 | | +----------+ | | +----------+ | | | | | | | | | | | Central |---------BGP/PCEP--------| Central | | | |Controller| | | |Controller| | | | | | | | | | | +----------+ | | +----------+ | | / \ | | / \ | | / \ | | / \ | | BGP/IGP/PCEP BGP/IGP/PCEP | | BGP/IGP/PCEP BGP/IGP/PCEP | | / \ | | / \ | | / \ | | / \ | | +--------+ +--------+ | | +--------+ +--------+ | | | | | | | | | | | | | | | CLIENT | ..IGP.. | CLIENT | | | | CLIENT | ..IGP.. | CLIENT | | | | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | | | | | | | | | | | | | | | +--------+ +--------+ | | +--------+ +--------+ | | | | | +-------------------------------+ +-------------------------------+ Figure 1: Architecture of In-band Domain-Wide Label Allocation MPLS global label should be allocated centrally to guarantee all nodes can understand the same meaning for a specific global label. It is natural to adopt the central control architecture for the in- band label allocation. In the architecture the central controller is responsible for allocating the global labels and advertising to the client nodes in the network. When client nodes receives the label binding, it will install the corresponding forwarding entry for the global label. The applications based on global labels are different: they may need advertise global label to all nodes of a domain, edge nodes of a domain or part of nodes of a domain. IGP extensions, BGP extensions and PCEP extensions are appropriate for these applications respectively. In addition, the global label may be negotiated across multiple domains, it will adopt BGP extensions and PCEP extensions. Central Control of global labels is the logical functionality which can be deployed in the independent server or in the network device. For example, the upstream label assignment for BGP-based MVPN is done by the root node of MVPN which can be seen as the central controller for the global label. Li, et al. Expires January 4, 2015 [Page 6] Internet-Draft A Framework of MPLS Global Label July 2014 5.2. In-Band Global Label Allocation 5.2.1. Label Allocation in Per-Platform MPLS Label Space +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ | Client | | Client | | Central | | Node n | | Node 1 | | Controller | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ | ...... | | | |--- Report Label Capability -->| | | | | ---------- Report Label Capability --------->| | | | Calculate Shared | | | Global Label Range | |<-- Notify Global Label Range ---| | | | | <---------- Notify Global Label Range --------| | | | | | | | | | | | | | |--- Global Label Request -->| Allocate the Global | | (FEC) | Label for FEC | | | | | | | |<---- Distribute Label Binding ----| | | | | <---------- Distribute Label Binding ------| | | | | | | Figure 2: Procedures of Global Label Allocation Procedures of global label allocation from per-platform label space is shown in the Figure 2. There are two import phases for these procedures: Shared MPLS global label range calculation and MPLS global label allocation. 5.2.1.1. Shared MPLS Global Label Range Calculation 1. Clients nodes should report MPLS label capability to the central controller. 2. The central controller collects MPLS label capability of all nodes. Then it can calculate the shared MPLS global label range for all nodes. Li, et al. Expires January 4, 2015 [Page 7] Internet-Draft A Framework of MPLS Global Label July 2014 3. The central controller should notify the shared global label range to all client nodes. Report of label capability and notification of shared MPLS global range can be done by IGP, BGP or PECP extensions. 5.2.1.2. Label Allocation There are two methods for the global label allocation: On-demand label allocation and Unsolicited label allocation. 1. On-demand allocation This method is that the global label allocation is done by the central controller based on the label requirement from client nodes. The procedures of on-demand allocation are as follows: 1) The client node should send the global label request for specific usage to the central controller. FEC(Forward Equivalence Class) should be incorporated in the MPLS global label request message. 2) When the central controllers receives the MPLS global label request, it should allocate the label from the shared MPLS global label range of all nodes. 3) The central controller distributes the MPLS global label mapping message to all client nodes. Thus the MPLS global label for specific usage can be understood by all client nodes. 4) The client nodes receive the MPLS global label mapping message and install the corresponding MPLS forwarding entry for the global label. Label request and distribution of label mapping which are used in on- demand allocation can be done by BGP extensions or PCEP extensions. 2. Unsolicited allocation This method is that the central controller directly allocates the global label without receiving the label request. The procedures of unsolicited allocation are as follows: 1) Discovery of service: this can be implemented by configuration or auto discovery which is service-specific and out of scope of this document. 2) The central controller allocates the global label from the global label space for the service. Li, et al. Expires January 4, 2015 [Page 8] Internet-Draft A Framework of MPLS Global Label July 2014 3) The central controller distributes the MPLS global label mapping message to all client nodes. Thus the MPLS global label for specific usage can be understood by all related client nodes. 4) The client nodes receive the MPLS global label mapping message and install the corresponding MPLS forwarding entry for the global label. Distribution of label mapping which is used in unsolicited allocation can be done by IGP extensions, BGP extensions or PCEP extensions. 5.2.2. Label Allocation in Context-Specific Label Space As mentioned in previous section, there can be two types of Context- Specific label space for global label allocation. For the Context- Specific label space identified by service-specific context identifier, the label allocation procedures are service-specific and these procedures are out of scope of this document. For the Context- Specific label space identified by MPLS Global Label Indicator, since the label space is well-known, it is necessary to calculate the share global label range like the global allocation in the per-platform label space. Except this, other procedures for global label allocation are similar as the global label allocation in per-platform label space. 5.3. Label Mapping Distribution After allocating the global label by the central controller, the label mapping must be distributed to all involved nodes of the specific global-label-based service. If the central controller connects to all involved nodes, the label mapping can be directly advertised to these nodes. But if the central controller only connects part of the involved nodes, it not only needs to distribute the label mapping to the connected client nodes, but also the label mapping should be distributed to other client nodes by the clients nodes which receive the label mapping from the central controller. The distribution of label mapping among client nodes can be implemented by IGP extensions. 5.4. Inter-Domain Label Negotiation If the global label for the service needs to be allocated across multiple domains, PCEP extensions or BGP extensions can be introduced for label negotiation across multiple domains. Li, et al. Expires January 4, 2015 [Page 9] Internet-Draft A Framework of MPLS Global Label July 2014 5.5. Protocol Extensions Requirement 5.5.1. IGP Protocol Extensions REQ 01. Report Label Capability from client nodes to the central controller. REQ 02. Notify the shared global label range from the central controller to client nodes. REQ 03: Distribute label mapping from the central controller to client node. REQ 04: Distribute label mapping among client nodes. 5.5.2. BGP Protocol Extensions REQ 11. Report Label Capability from client nodes to the central controller. REQ 12. Notify the shared global label range from the central controller to client nodes. REQ 13: Send global label request from client nodes to the central controller. REQ 14: Distribute label mapping from the central controller to client node. REQ 15: Inter-domain global label negotiation 5.5.3. PECP Protocol Extensions REQ 21. Report Label Capability from client nodes to the central controller. REQ 22. Notify the shared global label range from the central controller to client nodes. REQ 23: Send global label request from client nodes to the central controller. REQ 24: Distribute label mapping from the central controller to client node. REQ 25: Inter-domain global label negotiation Li, et al. Expires January 4, 2015 [Page 10] Internet-Draft A Framework of MPLS Global Label July 2014 6. Data Plane of MPLS Global Label 6.1. Global Label in Per-Platform Label Space For global label allocated from the per-platform label space, the existing MPLS forwarding mechanism can be reused without modification. 6.2. Global Label in Context-Specific Label Space For a global label allocated within the Context-Specific label space, it is necessary to maintain multiple MPLS label forwarding table in the forwarding plane. When forwarding packets with global label encapsulation, it must decapsulate the label for the Context Identifier firstly to determine the MPLS label forwarding table of the corresponding Context-Specific label space. Then it will decapsulate the next label and search the corresponding MPLS forwarding entry in the Context-Specific label space. The encapsulation of the global label from the Context-Specific label space is shown as follows: +----------------+----------------+ | Global Label | Global Label | | Indicator | | +----------------+----------------+ 6.3. Global Process of Inner Global Label Because the label forwarding entry for the global label can be created in multiple nodes in the network, there may be one application scenario for which the global label is located in the middle of the label stack of the transported packet and should be processed by all possible node. For example, the Entropy Label for ECMP can be encapsulated multiple times following multiple node segments in Segment Routing. This method may cause the depth of the label stack of the packet is too deep to process. In order to solve this issue, the global label can be introduced to represent the same process of all possible nodes. Thus the depth of the label stack can be reduced. This method can be imlemented by introducing a special- purpose label which is named as Global Process Indicator (GPI). When the Global Process Indicator is encapsulated in the packet, it indicates that the next global label SHOULD be process by each node along the path. The encapsulation of the global label allocated from the per-platform label space which needs to be globally processed is as follows: Li, et al. Expires January 4, 2015 [Page 11] Internet-Draft A Framework of MPLS Global Label July 2014 +----------------+----------------+ | Global Process | Global Label | | Indicator | | +----------------+----------------+ The encapsulation of the global label allocated from the Context- Specific label space indicated by MPLS Global Label Indicator which needs to be globally processed is as follows: +----------------+----------------+----------------+ | Global Process | Global Label | Global Label | | Indicator | Indicator | | +----------------+----------------+----------------+ 7. IANA Considerations Following two special-purpose labels defined in this document needs to be allocated by IANA: -- Global Label Indicator -- Global Process Indicator 8. Security Considerations TBD. 9. References 9.1. Normative References [I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., and T. Yang, "Usecases of MPLS Global Label", draft-li-mpls-global-label-usecases-01 (work in progress), February 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, June 2014. Li, et al. Expires January 4, 2015 [Page 12] Internet-Draft A Framework of MPLS Global Label July 2014 9.2. Informative References [I-D.raszuk-mpls-domain-wide-labels] Raszuk, R., "MPLS Domain Wide Labels", draft-raszuk-mpls- domain-wide-labels-01 (work in progress), January 2014. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 US Email: quintin.zhao@huawei.com Xia Chen Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jescia.chenxia@huawei.com Tianle Yang China Mobile 32, Xuanwumenxi Ave. Beijing 01719 China Email: yangtianle@chinamobile.com Li, et al. Expires January 4, 2015 [Page 13] Internet-Draft A Framework of MPLS Global Label July 2014 Robert Raszuk Individual Email: robert@raszuk.net Li, et al. Expires January 4, 2015 [Page 14]