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

Versions: 00 01 02

Network Working Group                                              Z. Li
Internet-Draft                                                   Q. Zhao
Intended status: Informational                       Huawei Technologies
Expires: January 12, 2014                                        T. Yang
                                                            China Mobile
                                                           July 11, 2013


                    A Framework of MPLS Global Label
                draft-li-mpls-global-label-framework-00

Abstract

   The document defines the framework of MPLS global label including:
   representation of MPLS global label, process of control plane for
   MPLS global label, and process of 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 12, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Li, et al.              Expires January 12, 2014                [Page 1]


Internet-Draft      A Framework of MPLS Global Label           July 2013


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Representation of MPLS Global Label . . . . . . . . . . . . .   3
     3.1.  Option A  -- Traditional MPLS Label . . . . . . . . . . .   3
     3.2.  Option B -- Expansions of MPLS Label  . . . . . . . . . .   4
   4.  Control Plane . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.1.  Shared MPLS Global Label Range Calculation  . . . . .   4
       4.1.2.  MPLS Global Label Allocation  . . . . . . . . . . . .   5
       4.1.3.  MPLS Global Label Withdraw  . . . . . . . . . . . . .   5
       4.1.4.  Error Process . . . . . . . . . . . . . . . . . . . .   6
       4.1.5.  Redundancy  . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  BGP-Based Control Plane . . . . . . . . . . . . . . . . .   6
     4.3.  IGP-Based Control Plane . . . . . . . . . . . . . . . . .   7
     4.4.  PCE-Based Control Plane . . . . . . . . . . . . . . . . .   8
   5.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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.  The new solutions based on MPLS global label can gain
   advantage over the existing solutions to facilitate service
   provisions.

   This document defines the framework for MPLS global label.  The
   framework includes the representation of MPLS global label, the
   process of control plane and data plane for MPLS global label.









Li, et al.              Expires January 12, 2014                [Page 2]


Internet-Draft      A Framework of MPLS Global Label           July 2013


2.  Terminology

   BDR: Backup Designated Router

   DR: Designated Router

   FEC: Forward Equivalence Class

   MVPN: Multicast VPN

   NBMA: Non-broadcast multi-access

   PCE: Path Computation Element

   PCC: Path Computation Client

   RR: Route Reflector

3.  Representation of MPLS Global Label

3.1.  Option A -- Traditional MPLS Label

   Current MPLS label uses 20 bits to represent the label range from 0
   to 2^20 - 1.  Since the existing MPLS label forwarding mechanism has
   been widely deployed, it is difficult to adopt following possible
   ways to represent MPLS global label:

   1.  Specific label in the existing label range to represent MPLS
   global label.  Since a specific MPLS global label should be
   understood by all nodes for the same meaning, it is hard for all
   nodes to allocate a specific label value for the same usage.  For
   example, a specific label value may be allocated for MPLS global
   label while the same label value may be allocated for MPLS LDP for
   MPLS local label.  Thus, the inconsistency for the specific label
   value will happen.

   2.  Reserve a segment of existing MPLS label range for MPLS global
   label and the MPLS global label is allocated concentratedly.  This is
   also hard to implement owing to following reasons:

   1) The label capability of network nodes are different.  It is hard
   to get a shared label segment of all nodes for the usage of MPLS
   global label.

   2) Even if the label capability of all network nodes can be collected
   and the shared label segment can be calculated, once new nodes are
   introduced into the network, the shared label segment reserved for
   MPLS global label maybe has to calculate again according to the new



Li, et al.              Expires January 12, 2014                [Page 3]


Internet-Draft      A Framework of MPLS Global Label           July 2013


   label capability introduced.  The worst case is that the new shared
   label segment can not be available and it will do harm to the
   existing deployed services based on MPLS global label.

3.2.  Option B -- Expansions of MPLS Label

   It is a reasonable way to define a new label range or segment for
   MPLS global label which is independent from the existing MPLS label
   range.  [I-D.li-mpls-mega-label] defines the label stacking mechanism
   to expand the MPLS label range.  The mechanism can be used to define
   a new label range for MPLS global label.

   The MPLS global label can be represented as the following figure.
   The global label value is achieved by adding the actual base label
   value indicated by the base label and the remainder label value.

   0                                     32                                   64
   +-------------------+----+-+---------+-------------------+----+-+---------+
   |    Base    Label  | TC |S|   TTL   |  Remainder Label  | TC |S|   TTL   |
   +-------------------+----+-+---------+-------------------+----+-+---------+

                 Figure 1 Representation of MPLS Global Label


   [I-D.li-mpls-mega-label] specifies that the base label can be any
   value range from 0 to 2^20 -1 (excluding the special labels which
   have been reserved).  But for MPLS global label, it is better to
   define a new special label which is in the range from 0 to 15.  Thus
   all nodes can understand it for the same meaning.  Otherwise, if a
   label value in the range from 16 to 2^20 -1 is used for the base
   label of the global label, it is necessary to get all network nodes
   to reserve the specific label value.  It has the same issues as those
   described in Section 3.1 such as difficulty in reservation,
   recalculation when new nodes are introduced, etc.

4.  Control Plane

4.1.  Overview

   MPLS global label should be allocated concentratedly to guarantee all
   nodes can understand the same meaning for a specific global label.
   It should adopt a server/client model in the control plane for MPLS
   global label allocation.  The procedures for the global label are
   described as follows.

4.1.1.  Shared MPLS Global Label Range Calculation





Li, et al.              Expires January 12, 2014                [Page 4]


Internet-Draft      A Framework of MPLS Global Label           July 2013


   1.  Clients nodes should report MPLS global label capability to the
   centralized controller.  Since the label range for MPLS global label
   is newly defined, it is MANDATORY for each client node to support a
   least range of labels for the usage of MPLS global label.  This is to
   guarantee that a shared global label segment can be derived for all
   nodes.

   2.  The centralized controller collects MPLS global label capability
   and MPLS global label range of all nodes.  Then it can calculate the
   shared MPLS global label range for all nodes.

   3.  The centralized controller should notify the shared global label
   range to all client nodes.

4.1.2.  MPLS Global Label Allocation

   1.  The client node should send the global label request for specific
   usage to the centralized controller.  FEC(Forward Equivalence Class)
   should be incorporated in the MPLS global label request message.

   2.  When the centralized controllers receives the MPLS global label
   request, it should allocate the label from the shared MPLS global
   label segment of all nodes.

   3.  The centralized controller sends 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 node receives the MPLS global label mapping message
   and installs the corresponding MPLS forwarding entry for the global
   label.

4.1.2.1.  Process of Duplicate MPLS Global Label Request

   Since MPLS global label is used for specific usage globally, it is
   possible that multiple MPLS global label requests for the same usage
   are sent by different client nodes to the centralized controller.
   The controller needs to count the MPLS global label requests for the
   same usage.  It can send multiple global label mapping messages to
   respond these requests.  It can also send only one copy of the global
   label mapping message to all nodes in order to reduce the unnecessary
   protocol operation.  If the controller sends multiple copies of the
   global label mapping message to respond each label request, client
   nodes need to ignore the subsequent messages.

4.1.3.  MPLS Global Label Withdraw

   TBD.



Li, et al.              Expires January 12, 2014                [Page 5]


Internet-Draft      A Framework of MPLS Global Label           July 2013


4.1.4.  Error Process

   TBD.

4.1.5.  Redundancy

   Since MPLS global label is allocated concentratedly, it is important
   to guarantee the high availability of the centralized controller.
   Redundant backup needs to be introduced for the high availability.
   The backup centralized controller needs to learn global label
   requests sent by client nodes and corresponding label mapping sent by
   the primary centralized controller.  The backup centralized
   controller will not send any global label mapping to client nodes
   until failure happens for the primary centralized controller.

   The primary role and the backup role of the centralized controllers
   can be specified administratively.  They can also be elected
   dynamically based on auto-discovery of these controllers.

   The failure detection mechanism also needs to be introduced between
   the primary controller and the backup controller.  It can be the
   keepalive-like mechanism, the fast detection mechanism like BFD, or
   mixing use of both mechanisms.

4.2.  BGP-Based Control Plane

                            +---------------+
                            |   IP/MPLS     |
                            |   Network     |
          +----+     +----+ |               | +----+     +----+
          | CE1|-----|    | |               | |    |-----| CE2|
          +----+\    | PE1|\|    +---- +    |/| PE3|     +----+
                 \   +----+ \____|     |    / +----+
                  \              | RR+ |___/|
                   \ +----+ /----|     |    |
                    \|    |/|    +-----+    |
                     | PE2| |               |
                     +----+ |               |
                            +---------------+

                 Figure 2: BGP-based Control Plane


   Many types of services such as VPLS[RFC4761], Multicast VPN[RFC6514]
   and E-VPN[I-D.ietf-l2vpn-evpn] are based on MP-BGP.  If new solutions
   based on MPLS global label are introduced for such services, the
   architecture shown in the figure 2 can be applied.




Li, et al.              Expires January 12, 2014                [Page 6]


Internet-Draft      A Framework of MPLS Global Label           July 2013


   In the BGP-based control plane, Route Reflector (RR) of BGP
   [RFC4456]can act as the role of the centralized controller.  We call
   this type of RR as RR+. For VPLS, Multicast VPN and E-VPN services,
   auto-discovery mechanisms based on MP-BGP are introduced.  So the RR+
   can learn the necessary membership information through these A-D
   routes.  RR+ can also learn the MPLS label capability information
   through necessary MP-BGP extensions.  When MPLS global label is
   necessary, the BGP client on the PE node can send label request to
   RR+ and the label mapping for the allocated MPLS global label will be
   advertised to all PEs.  Thus all PEs can learn the binding between
   the service and the MPLS global and the forwarding entry for the MPLS
   global label can be installed accordingly.

4.3.  IGP-Based Control Plane

   +------------------------------+    +------------------------------+
   |          IGP AREA 1          |    |          IGP AREA 2          |
   |          +--------+          |    |          +--------+          |
   |          |        |          |    |          |        |          |
   |          |  DR+   |--------------------------|  DR+   |          |
   |          |        |          |    |          |        |          |
   |          |        |          |    |          |        |          |
   |          +--------+          |    |          +--------+          |
   |         /          \         |    |         /          \         |
   |        /            \        |    |        /            \        |
   |       /              \       |    |       /              \       |
   | +--------+        +--------+ |    | +--------+        +--------+ |
   | | NODE 1 |        | NODE n | |    | | NODE 1 |        | NODE n | |
   | |        | ...... |        | |    | |        | ...... |        | |
   | |  IGP   |        |  IGP   | |    | |  IGP   |        |  IGP   | |
   | | CLIENT |        | CLIENT | |    | | CLIENT |        | CLIENT | |
   | +--------+        +--------+ |    | +--------+        +--------+ |
   |                              |    |                              |
   +------------------------------+    +------------------------------+

                 Figure 3: IGP-based Control Plane


   If the internal nodes of the network support MPLS global label, IGP-
   based control plane can be introduced.  IGP has ever introduced the
   DR(Designated Router) and BDR(Backup Designated Router) concepts for
   broadcast and NBMA network([RFC2328]).  The Designated Router is
   elected in the broadcast or NBMA network to act as a centralized
   control point to advertise adjacencies among DR and DR others.  In
   the IGP-base control plane for MPLS global label, we can adopt the DR
   concept which can act as the centralized controller for the MPLS
   global label.  We called this type of DR ad DR+. The DR+ can collect
   the MPLS global label capability of all client nodes.  If MPLS global



Li, et al.              Expires January 12, 2014                [Page 7]


Internet-Draft      A Framework of MPLS Global Label           July 2013


   label is necessary for specific usage, the MPLS global label will be
   allocated by the DR+ and the corresponding label mapping can be
   advertised to all network nodes through IGP extensions.  Thus all
   network nodes in the IGP area can learn the label binding between the
   specific usage and the MPLS global label and the forwarding entry for
   the MPLS global label can be installed accordingly.

   MPLS global label binding information should be always advertised in
   a specific IGP area.  There may be multiple IGP areas and nodes in
   other IGP areas may be necessary to learn the MPLS global label
   information.  There are two possible solutions:

   1.  The global label information can be advertised by IGP to span
   multiple areas.  It is like leaking the information from the native
   area to other areas.

   2.  There can exist direct connections between IGP DR+. The MPLS
   global label information can be advertised from the native IGP DR+ to
   the other IGP DR+ using possible protocol extensions other than
   IGP(e.g. PCEP extensions or BGP extensions).  The other IGP DR+ can
   learn the MPLS global label information and advertise it in its own
   area through IGP extensions.

4.4.  PCE-Based Control Plane

   +------------------------------+    +------------------------------+
   |         PCE DOMAIN 1         |    |         PCE DOMAIN 2         |
   |          +--------+          |    |          +--------+          |
   |          |        |          |    |          |        |          |
   |          |  PCE   |--------------------------|  PCE   |          |
   |          | Server |          |    |          | Server |          |
   |          |        |          |    |          |        |          |
   |          +--------+          |    |          +--------+          |
   |         /          \         |    |         /          \         |
   |        /            \        |    |        /            \        |
   |       /              \       |    |       /              \       |
   | +--------+        +--------+ |    | +--------+        +--------+ |
   | | NODE 1 |        | NODE n | |    | | NODE 1 |        | NODE n | |
   | |        | ...... |        | |    | |        | ...... |        | |
   | |  PCC   |        |  PCC   | |    | |  PCC   |        |  PCC   | |
   | |        |        |        | |    | |        |        |        | |
   | +--------+        +--------+ |    | +--------+        +--------+ |
   |                              |    |                              |
   +------------------------------+    +------------------------------+

                   Figure 4: PCE-based Control Plane





Li, et al.              Expires January 12, 2014                [Page 8]


Internet-Draft      A Framework of MPLS Global Label           July 2013


   PCE[RFC4655] is another choice to implement the control plane for
   MPLS global label.  The PCE servers can act as the role of the
   centralized controller and the PCC can act the role of the client for
   process of MPLS global label.  PCE servers can collect the MPLS
   global label capability of all nodes through PCEP extensions.  If
   MPLS global label is necessary for specific usage, the label request
   can be sent from PCC to PCE server.  MPLS global label will be
   allocated by the PCE server and the corresponding label mapping will
   be advertised to all network nodes through PCEP extensions.  Thus all
   network nodes in the domain can learn the label binding between the
   specific usage and the MPLS global label and the forwarding entry for
   the MPLS global label can be installed accordingly.

   If MPLS global label information needs to be advertised in different
   domain, it can be advertised from the native PCE server to other PCE
   servers through PECP extensions.  Then other PCE servers can
   advertise the MPLS global information to PCC through PCEP in its own
   domain.

5.  Data Plane

   According to Section 3, MPLS global label can be represented by label
   stacking.  When encapsulate MPLS global label, the remainder label
   for the MPLS global label should be encapsulated firstly.  Then the
   base label for the MPLS global label should be encapsulated in a row.
   The TTL, COS and S values should be the same in the base label
   encapsulation and the remainder label encapsulation.

   When receive the packet with MPLS global label encapsulation, the
   base label should be decapsulated firstly.  The actual base label
   value indicated by the base label will be derived.  Then the
   remainder label should be decapsulated.  The actual MPLS global label
   value can be acquired by adding the actual base label value and the
   remainder label value.  The TTL, COS and S value in the base label
   encapsulation and the remainder label encapsulation for the MPLS
   global label should be the same.  If there exists inconsistency, the
   TTL, COS and S value in the remainder label encapsulation should be
   adopted for MPLS forwarding.

   Since MPLS global label can be used for different usages, the process
   of the data plane may be related with the specific usage of the MPLS
   global label.  These processes are out of scope of this document and
   should be defined combining with the specific usage.

6.  IANA Considerations

   This document makes no request of IANA.




Li, et al.              Expires January 12, 2014                [Page 9]


Internet-Draft      A Framework of MPLS Global Label           July 2013


7.  Security Considerations

   TBD.

8.  Normative References

   [I-D.ietf-l2vpn-evpn]
              Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F.,
              Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN",
              draft-ietf-l2vpn-evpn-03 (work in progress), February
              2013.

   [I-D.li-mpls-global-label-usecases]
              Li, Z., Zhao, Q., and T. Yang, "Usecases of MPLS Global
              Label", draft-li-mpls-global-label-usecases-00 (work in
              progress), July 2013.

   [I-D.li-mpls-mega-label]
              Li, Z. and L. Zheng, "Mega Label - Expansion of MPLS Label
              Range", draft-li-mpls-mega-label-00 (work in progress),
              July 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, April 2006.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC4761]  Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
              (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
              4761, January 2007.

   [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








Li, et al.              Expires January 12, 2014               [Page 10]


Internet-Draft      A Framework of MPLS Global Label           July 2013


   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


























Li, et al.              Expires January 12, 2014               [Page 11]


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