Internet DRAFT - draft-li-mpls-global-label-usecases
draft-li-mpls-global-label-usecases
Network Working Group Z. Li
Internet-Draft Q. Zhao
Intended status: Informational Huawei Technologies
Expires: April 19, 2016 T. Yang
China Mobile
R. Raszuk
Individual
L. Fang
Microsoft
October 17, 2015
Usecases of MPLS Global Label
draft-li-mpls-global-label-usecases-03
Abstract
As the MPLS technologies develop, MPLS label is not only used with
the local meaning which is always be understood by the upstream node
and the downstream node, but also used with the global meaning which
can be understood by all nodes or part of nodes in the network. The
document defines the latter as the global label and proposes the
possible use cases of global label. In these usecases MPLS global
label can be used for location identification, VPN identification,
segment routing, etc.
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 April 19, 2016.
Li, et al. Expires April 19, 2016 [Page 1]
Internet-Draft Usecases of MPLS Global Label October 2015
Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Location Identification . . . . . . . . . . . . . . . . . 3
3.2. VPN Identification . . . . . . . . . . . . . . . . . . . 4
3.2.1. Flow Label of VPN LSP . . . . . . . . . . . . . . . . 4
3.2.2. Aggregate MVPN/VPLS over Single P-Tunnel . . . . . . 5
3.3. Segment Routing . . . . . . . . . . . . . . . . . . . . . 5
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
In the traditional MPLS architecture, MPLS label is always
distributed from the downstream node to the upstream node by LDP,
RSVP-TE and MP-BGP. These label mappings always have the local
meaning which can only be understood by the upstream node and the
downstream node. As the MPLS technologies develop, there proposes
possible usecases in which MPLS label mapping can be advertised to
all nodes or part of nodes in the network. That is, the meaning of
the label mapping will be understood by all nodes or part of nodes in
the network other than the local upstream node and downstream node.
This document defines such type of MPLS label as global label as the
opposite of local label.
Li, et al. Expires April 19, 2016 [Page 2]
Internet-Draft Usecases of MPLS Global Label October 2015
In the MPLS world there are another pair of label related concepts:
per-platform label space [RFC3031]and context-specific label
space[RFC5331]. According to [RFC3031] MPLS local label can be
allocated from per-platform label space and per-interface label space
(in [RFC5331], per-interface label space is generalized as one type
of context-specific label space). MPLS global label can also be
allocated from per-platform label space or context-specific label
space.
The document proposes the possible usecases of MPLS global label. In
these usecases MPLS global label can be used for location
identification, VPN identification, segment routing, etc.
2. Terminology
CE: Customer Edge
MP2P: Multi-Point to Point
MP2MP: Multi-point to Multi-point
MVPN: Multicast VPN
P2MP: Point to Multi-Point
P2P: Point to Point
PE: Provider Edge
3. Use Cases
3.1. Location Identification
[I-D.bryant-mpls-flow-ident] and
[I-D.bryant-mpls-synonymous-flow-labels] propose the challenge of the
measurement of packet loss for the multi-point to point LSP. In this
case the same label is normally used by multiple ingress or upstream
LSRs for specific prefixes and hence source identification is not
possible by inspection of the top label by the egress LSRs. Thus
[I-D.bryant-mpls-synonymous-flow-labels] proposes the synonymous flow
label to be used to introduce some source specific information
encapsulated in the packet to identify packet batches from a specific
source.
MPLS LDP LSP is one type of multi-point to point LSP. As the network
convergence develops, MPLS LDP network needs to interwork with MPLS
TE/MPLS-TP network and unified MPLS OAM becomes the realistic
requirement. In this usecase, MPLS global label can be allocated for
Li, et al. Expires April 19, 2016 [Page 3]
Internet-Draft Usecases of MPLS Global Label October 2015
each network node and advertised in the network. When implement the
measurement of packet loss for LDP LSP, such MPLS global label can be
used as the flow label to identify the source node of the LDP LSP.
When the destination receives the packets it can differentiate flows
from specific source node based on the advertised global label
binding information for network nodes. In this usecase, MPLS global
label is used as the unique identification of source nodes in the
network and may save the complex flow label negotiation process
between the source node and the destination node.
3.2. VPN Identification
MPLS global label can be allocated for VPN and advertised in the
network. In this usecase, MPLS global label is used as the unique
identification of VPN in the network and can be used for multiple
purposes.
3.2.1. Flow Label of VPN LSP
BGP VPN LSP is another type of multi-point to point LSP which faces
the challenge of the measurement of packet loss proposed by
[I-D.bryant-mpls-flow-ident] and
[I-D.bryant-mpls-synonymous-flow-labels]. In this usecase, the flow
label should be introduced to identfication of the source VPN. There
are two possible ways to use global label as the flow label:
Option 1: The global label is allocated for the same VPN on all PE
nodes and advertised in the network. And global labels can be
allocated for PE nodes and advertised in the network. Then the flow
label should be the source PE label + the VPN label shown in the
figure 1.
+-----------------+
| |
+-----------------+ \ | Source PE |
| | -------\ | Global Label |
| Flow Label | -------/ +-----------------+
| | / | |
+-----------------+ | VPN |
| Label |
+-----------------+
Figure 1: Flow Label using Two Layers of Global Label
Option 2: The global label is allocated directly for source VPN
(ideentified by the pair of { Source PE, VPN }) and advertised in the
network. We call such label as Source VPN label. The flow label
should be the source VPN label shown in the figure 2.
Li, et al. Expires April 19, 2016 [Page 4]
Internet-Draft Usecases of MPLS Global Label October 2015
+-----------------+ \ +-----------------+
| | -------\ | |
| Flow Label | -------/ | Source VPN |
| | / | Global Label |
+-----------------+ +-----------------+
Figure 2: Flow Label using One Layer of Global Label
No matter option 1 or option 2 is adopted, when the destination
receives the packets it can differentiate flows from specific source
VPN based on the advertised global label binding information.
3.2.2. Aggregate MVPN/VPLS over Single P-Tunnel
In BGP-base Multicast VPN ( [RFC6513]) and VPLS Multicast(
[RFC7117]), in order to implement aggregating multiple MVPN/VPLS
Instances on a single P-Tunnel (i.e. sharing one P2MP LSP) , context-
specific label is introduced to identify the MVPN/VPLS instance and
the label binding is allocated by the root PE and advertised to the
leaf PEs. In this usecase the context-specific label is one type of
global label to uniquely identify the MVPN/VPLS instance in the
network.
The context-specific label can solve the issue of aggregating
multiple MVPNs or VPLS instances over a single P2MP LSP. But if the
MP2MP LSP is adopted for aggregating multiple MVPN/VPLS instances the
solution does not work since there are multiple root PEs which may
allocate the same context-specific label for different MVPN/VPLS
instances. In order to solve the issue the global label can be
allocated to the same MVPN/VPLS instance on all PEs and advertised in
the network. Then the global label will become the unique
identification of VPN instance in the network. When aggregating
multiple MVPNs or VPLS instances over one MP2MP LSP, the
corresponding MPLS global label binding with the MVPN/VPLS instance
can be encapsulated by the root PE. Then the leaf PEs can determine
the MVPN or VPLS instance the received packets belong to based on the
advertised global label binding information for MVPN/VPLS instances.
The solution can provide the unified solution for aggregating
multiple MVPN/VPLS instances over P2MP LSP and MP2MP LSP. And the
solution can save the complex control plane and forwarding plane
process of context-specific label.
3.3. Segment Routing
Segment Routing [I-D.ietf-spring-segment-routing] is introduced to
leverage the source routing paradigm for traffic engineering, fast
re-route, etc. A node can steer a packet through an ordered list of
segments. A segment can represent any instruction, topological or
Li, et al. Expires April 19, 2016 [Page 5]
Internet-Draft Usecases of MPLS Global Label October 2015
service-based. Segment Routing can be directly applied to the MPLS
architecture with no change on the forwarding plane in which a
segment can be encoded as an MPLS label and an ordered list of
segments can be encoded as a stack of labels.
Segment Routing [I-D.ietf-spring-segment-routing] introduces some
segments such as node segment, adjacency segment, etc. SR Global
Block (SRGB) is also introduced for allocation of segment. In the
MPLS architecture, SRGB is the set of local labels reserved for
global segments. When the global segment index is advertised, it can
be transited to MPLS label based on the SRGB. According to
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-isis-segment-routing-extensions] MPLS global label binding
information can also be directly advertised in the network. For
example, in the section 2.1 of
[I-D.ietf-ospf-segment-routing-extensions], when the Length field of
SID/Label Sub-TLV is set as 3, it will represent the label which can
be flooded in the whole network. By this method MPLS global label
can be directly allocated for specific node or adjacency, etc. and
advertised in the network. The solution can save the complex process
of SRGB advertisement and transition from the global Segment ID to
MPLS label.
4. Discussion
In the MPLS world, we can adopt the dichotomy to divide it into per-
platform label space and context-specific label space.
MPLS World
+-----------------+-----------------+
| | |
| Per-Platform | Context-Specific|
| Label Space | Label Space |
| | |
+-----------------+-----------------+
When we adopt another dichotomy to divide the MPLS world into local
label and global label, we may face more challenges.
Li, et al. Expires April 19, 2016 [Page 6]
Internet-Draft Usecases of MPLS Global Label October 2015
MPLS World
Local Label vs. Global Label
+------------------------------+--------------------------------------+
| | Special Purpose Label (RFC 7274) |
| |--------------------------------------+
| | MPLS Upstream Label Assignment |
| | /Context-Specific Label Space |
| | (RFC 5331) |
| |--------------------------------------+
| LDP (RFC 5036) | Entropy Label (RFC 6790) |
| RSVP-TE (RFC 3209) | Flow Label (RFC 6391) |
| BGP LSP (RFC 3107) |--------------------------------------+
| L3VPN (RFC 4364) | BGP-base VPLS (RFC 4761) |
| LDP-based L2VPN (RFC 4762) | Segment Routing |
| EVPN (RFC 7432) | (draft-ietf-spring-segment-routing) |
| +--------------------------------------+
| | Domain-Wide Label |
| | (Usecases: Synonymous Label/ |
| | Segment Routing, etc.) |
+---------------------------------------------------------------------+
Figure 3: Division of MPLS World Using Local Label and Global Label
In the figure 3, we can easily understand the local label using for
LDP, RSVP-TE, label BGP, L3VPN, LDP-based L2VPN, EVPN,etc. But for
the opposite of these applications there may be many usecases which
are different from each other, but share the common characteristic
that the label meaning can be understood by all network nodes or part
of network nodes instead of only the local downstream nodes and
upstream nodes for which in this document such lable is defined as
global label :
-- For special purpose labels, their meaning can be understood by all
nodes in the MPLS network. Should they belong to global label?
-- For MPLS upstream label assignment in context-specific label
space, all downstream nodes can understand the meaning of the label
allocated by the upstream node binding for specific MVPN/VPLS
instance. We can see the root PE as one type to central controlled
node to allocate label to all leaf nodes. And thinking about the
uniqueness of the context determine by the shared P-tunnel, these
labels in fact are also unique in the network. Should they belong to
global label?
-- For entropy label and flow label, the label is calculated by the
ingress node based on specific hash algorithms which is totally
different from the local label distributed in the MPLS control plane.
Li, et al. Expires April 19, 2016 [Page 7]
Internet-Draft Usecases of MPLS Global Label October 2015
And all nodes along the path will parse the label and according to
the uniform meaning to use the label for ECMP. But the label values
can be duplicate since they are calculated by different ingress
nodes. Should they belong to global label?
-- For BGP-based VPLS and Segment Routing, they can adopt the local
label block. But they introduce the global ID and transit them into
the local label. Especially for segment routing, when all nodes in
the network adopts the same SRGB, the global segment ID is easily
transited to a unique global label value in the network. Should they
belong to global label?
-- This document proposes some usecases to directly allocate the
unique label value and advise the label binding in the network.
Should they be directly called as global label or Domain-Wide label
as one type of global label?
Since above applications which are different from the traditional
MPLS local label, can we define all of them as global label or define
some of them as global label and bring some use cases to the local
label field? Or maybe such dichotomy using local label and global
label does not exist.
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
TBD.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[I-D.bryant-mpls-flow-ident]
Bryant, S., Pignataro, C., Chen, M., Li, Z., and G.
Mirsky, "MPLS Flow Identification", draft-bryant-mpls-
flow-ident-02 (work in progress), September 2015.
Li, et al. Expires April 19, 2016 [Page 8]
Internet-Draft Usecases of MPLS Global Label October 2015
[I-D.bryant-mpls-synonymous-flow-labels]
Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen,
M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft-
bryant-mpls-synonymous-flow-labels-01 (work in progress),
July 2015.
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment-
routing-extensions-05 (work in progress), June 2015.
[I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-05 (work in progress), June 2015.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and r. rjs@rob.sh, "Segment Routing Architecture", draft-
ietf-spring-segment-routing-06 (work in progress), October
2015.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<http://www.rfc-editor.org/info/rfc3107>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<http://www.rfc-editor.org/info/rfc4761>.
Li, et al. Expires April 19, 2016 [Page 9]
Internet-Draft Usecases of MPLS Global Label October 2015
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<http://www.rfc-editor.org/info/rfc4762>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<http://www.rfc-editor.org/info/rfc5331>.
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
Regan, J., and S. Amante, "Flow-Aware Transport of
Pseudowires over an MPLS Packet Switched Network",
RFC 6391, DOI 10.17487/RFC6391, November 2011,
<http://www.rfc-editor.org/info/rfc6391>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<http://www.rfc-editor.org/info/rfc6790>.
[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
C. Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014,
<http://www.rfc-editor.org/info/rfc7117>.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special-Purpose MPLS Labels", RFC 7274,
DOI 10.17487/RFC7274, June 2014,
<http://www.rfc-editor.org/info/rfc7274>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <http://www.rfc-editor.org/info/rfc7432>.
Li, et al. Expires April 19, 2016 [Page 10]
Internet-Draft Usecases of MPLS Global Label October 2015
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
Tianle Yang
China Mobile
32, Xuanwumenxi Ave.
Beijing 01719
China
Email: yangtianle@chinamobile.com
Robert Raszuk
Individual
Email: robert@raszuk.net
Luyuan Fang
Microsoft
5600 148th Ave NE
Redmond, WA 98052
USA
Email: lufang@microsoft.com
Li, et al. Expires April 19, 2016 [Page 11]
