[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/