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

Versions: 00 01 02

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]


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