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]