Internet DRAFT - draft-li-spring-mpls-path-programming

draft-li-spring-mpls-path-programming






Network Working Group                                              Z. Li
Internet-Draft                                                 Z. Zhuang
Intended status: Informational                       Huawei Technologies
Expires: September 9, 2015                                 March 8, 2015


Use Cases and Framework of Service-Oriented MPLS Path Programming (MPP)
                draft-li-spring-mpls-path-programming-01

Abstract

   Source Packet Routing in Networking (SPRING) architecture for unicast
   traffic has been proposed to cope with the use cases in traffic
   engineering, fast re-reroute, service chain, etc.  It can leverage
   existing MPLS dataplane without any modification.  In fact, the label
   stack capability in MPLS would have been utilized well to implement
   flexible path programming to satisfy all kinds of requirements of
   service bearing.  But in the distributed environment, the flexible
   programming capability is difficult to implement and always confined
   to reachability.  As the introducing of central control in the
   network, the flexible MPLS programming capability becomes possible
   owing to two factors: 1.  It becomes easier to allocate label for
   more purposes than reachability; 2.  It is easy to calculate the MPLS
   path in a global network view.  Moreover, the MPLS path programming
   capability can be utilized to satisfy more requirements of service
   bearing in the service layer which is defined as service-oriented
   MPLS path programming.  This document defines the concept of MPLS
   path programming, then proposes use cases, architecture and protocol
   extension requirements in the service layer for the architecture of
   Source Packet Routing in Networking (SPRING).

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/.





Li & Zhuang             Expires September 9, 2015               [Page 1]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


   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 September 9, 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Programming Capability of MPLS Path . . . . . . . . . . . . .   4
     3.1.  History Review  . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Gap Analysis of Segment Routing . . . . . . . . . . . . .   5
   4.  Use Cases of Service-Oriented MPLS Path Programming . . . . .   6
     4.1.  Use Cases for Unicast Service . . . . . . . . . . . . . .   6
       4.1.1.  Basic Reachability  . . . . . . . . . . . . . . . . .   6
       4.1.2.  VPN Identification  . . . . . . . . . . . . . . . . .   6
       4.1.3.  ECMP( Equal Cost Multi-Path)  . . . . . . . . . . . .   6
       4.1.4.  Service OAM . . . . . . . . . . . . . . . . . . . . .   7
       4.1.5.  Traffic Steering  . . . . . . . . . . . . . . . . . .   7
     4.2.  Use Cases of Multicast Service  . . . . . . . . . . . . .   7
       4.2.1.  Basic Reachability  . . . . . . . . . . . . . . . . .   8
       4.2.2.  MVPN Identification . . . . . . . . . . . . . . . . .   8
       4.2.3.  Source Identification . . . . . . . . . . . . . . . .   8
     4.3.  Use Cases of MPLS Virtual Network . . . . . . . . . . . .   8
     4.4.  Use cases of More Label Combinations  . . . . . . . . . .   9
     4.5.  Use cases for Centralized Mapping of Service to Tunnels .   9
   5.  Framework of Service-Oriented MPLS Path Programming . . . . .  10
     5.1.  Central Control for MPLS Path Programming . . . . . . . .  10
     5.2.  BGP-based MPLS Segment Distribution . . . . . . . . . . .  11
     5.3.  MPLS Service Path Programming . . . . . . . . . . . . . .  11
       5.3.1.  Label Combination and Download of MPLS Path . . . . .  11



Li & Zhuang             Expires September 9, 2015               [Page 2]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


       5.3.2.  Mapping of Service Path to Service Path . . . . . . .  12
     5.4.  Compatibility . . . . . . . . . . . . . . . . . . . . . .  12
     5.5.  Protocol Extensions Requirements  . . . . . . . . . . . .  12
       5.5.1.  BGP . . . . . . . . . . . . . . . . . . . . . . . . .  12
       5.5.2.  I2RS  . . . . . . . . . . . . . . . . . . . . . . . .  13
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Source Packet Routing in Networking (SPRING) architecture for unicast
   traffic has been proposed to cope with the use cases in traffic
   engineering, fast re-reroute, service chain, etc.  It can leverage
   existing MPLS dataplane without any modification.  In fact, the label
   stack capability in MPLS would have been utilized well to implement
   flexible path programming to satisfy all kinds of requirements of
   service bearing.  But in the distributed environment, the flexible
   programming capability is difficult to implement and always confined
   to reachability.  As the introducing of central control in the
   network, the flexible MPLS programming capability becomes possible
   owing to two factors: 1.  It becomes easier to allocate label for
   more purposes than reachability; 2.  It is easy to calculate the MPLS
   path in a global network view.  Moreover, the MPLS path programming
   capability can be utilized to satisfy more requirements of service
   bearing in the service layer which is defined as service-oriented
   MPLS path programming.  This document defines the concept of MPLS
   path programming, then proposes use cases, architecture and protocol
   extension requirements in the service layer for the architecture of
   Source Packet Routing in Networking (SPRING).

2.  Terminology

   BGP: Border Gateway Protocol

   BUM: Broadcast, Unknown unicast and Multicast

   EVPN: Ethernet VPN

   FRR: Fast Re-Route

   L2VPN: Layer 2 VPN

   L3VPN: Layer 3 VPN




Li & Zhuang             Expires September 9, 2015               [Page 3]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


   MPP: MPLS Path Programming

   MVPN: Multicast VPN

   RR: Route Reflector

   SDN: Software-Defined Network

   SR-path: Segment Routing Path

3.  Programming Capability of MPLS Path

   MPLS path is composed by label stacks.  Since in the label stack the
   labels in different layers can represent different meaning and the
   depth of the label stack can be unlimited in theory, it is possible
   can make up all kinks of MPLS paths based on the combination of
   labels.  If we look on the combination of MPLS labels as programming,
   it is can be seen that the MPLS path has high programming capability.

3.1.  History Review

   The solutions based on MPLS label stack have been widely deployed.
   For example, in the scenario of Options C inter-AS VPN ([RFC4364]),
   we assume that LDP over TE is used as the transport tunnel and the TE
   tunnel starts at the ingress PE, following label stack can be
   composed by the ingress PE for MPLS path to bear VPN service:

   +----------+---------+---------+---------+
   |VPN Prefix|   BGP   |   LDP   | RSVP-TE |
   |   Label  |  Label  |  Label  |  Label  |
   +----------+---------+---------+---------+

   If facility FRR ([RFC4090]) is deployed for the MPLS TE tunnel, once
   the failure happens, additional label will be pushed for the label
   stack which is shown as follows:

   +----------+---------+---------+---------+------------+
   |VPN Prefix|   BGP   |   LDP   | RSVP-TE | BYPASS FRR |
   |   Label  |  Label  |  Label  |  Label  |    Label   |
   +----------+---------+---------+---------+------------+

   The combination of labels in the above label stack is not simpler
   than the existing segment routing solution which composes the segment
   routing path through combination of segments.  In fact, this is also
   a use case of source packet routing.  But the combination is not as
   flexible as the segment routing since the combination of labels is
   always to cope with the reachability issue with limited capability in
   the distributed environment as follows:



Li & Zhuang             Expires September 9, 2015               [Page 4]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


   1.  Each label in the label stack is always binded with the
       reachability to a specific prefix.  That is, the purpose of the
       label binding is limited.

   2.  It is difficult to implement flexible path calculation based on
       policy or constraints.  For example, MPLS TE proposes rich set of
       traffic engineering attributes for transport.  But it needs
       complex configurations in each ingress node in an unscalable way.
       That is, the path calculation and composition capability is
       limited.

   As more concepts on MPLS label are proposed such as entropy label,
   source label, segment routing, etc., the purpose of label binding
   expands and the combination of labels can become more flexible.  MPLS
   path programming capability becomes more realistic to satisfy more
   application scenarios.

3.2.  Gap Analysis of Segment Routing

   Segment Routing ([I-D.filsfils-spring-segment-routing]) is a typical
   example of MPLS path programming.  The segment based on MPLS label is
   to represent nodes or agencies in the network.  Through the collected
   information of network segments and path calculation based on the
   service requirement in the central controller, there will be flexible
   segment routing paths for the usage of traffic engineering.  The SR-
   path can be advertised to the ingress node through PCE extensions.
   ([I-D.sivabalan-pce-segment-routing]).

   Segment routing can implement source packet routing with high
   flexibility.  On the other hand, there are multiple layers for MPLS
   path to bear services which is shown in the following figure:

            +---+                               +---+
    +--+    |   |    +---+    +---+    +---+    |   |    +--+
    |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE|
    +--+    |   |    +---+    +---+    +---+    |   |    +--+
            +---+                               +---+

     o--------o--------- Service Layer------------o--------o

              o--------- Network Layer -----------o

              o-------o--------o---------o-------o  Transport Layer

     o-----o   o-----o  o-----o  o-----o  o-----o   o-----o Link Layer


            Figure 1: Multiple Layers of Service Bearing



Li & Zhuang             Expires September 9, 2015               [Page 5]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


   Now the segment routing is to provide the source packet routing in
   the transport layer.  We can call this type of source packet routing
   as Transport-Oriented MPLS path programming.  There will be more
   application scenarios which needs the source packet routing in the
   service layer and network layer.  We call these types of source
   packet routing as Service-Oriented MPLS path programming.

4.  Use Cases of Service-Oriented MPLS Path Programming

4.1.  Use Cases for Unicast Service

4.1.1.  Basic Reachability

   The basic reachability for VPN service is to allocate label to
   specific prefix including IP address or MAC address.  MPLS path is as
   follows (using L3VPN as the example):

   +----------+
   |VPN Prefix| ---> Transport
   |   Label  |        Tunnel
   +----------+

4.1.2.  VPN Identification

   There are several use cases which need to indentify the VPN the
   packet belongs to in the forwarding plane such as the egress PE node
   protection for VPN ([I-D.zhang-l3vpn-label-sharing]).  MPLS Path can
   be as follows:

   +----------+----------+
   |VPN Prefix|    VPN   | ---> Transport
   |   Label  |   Label  |        Tunnel
   +----------+----------+

4.1.3.  ECMP( Equal Cost Multi-Path)

   In order to satisfy ECMP to take full advantage of link bandwidth in
   the network, the entropy label ([RFC6790]) can be encapsulated.  MPLS
   path can be as follows:

   +----------+----------+----------+
   |  Entropy |VPN Prefix|    VPN   | ---> Transport
   |   Label  |   Label  |   Label  |        Tunnel
   +----------+----------+----------+







Li & Zhuang             Expires September 9, 2015               [Page 6]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


4.1.4.  Service OAM

   OAM is an important requirement for the service.  The performance
   metrics should be measured against the Service Level Agreement(SLA)
   for the user.  Now there are relatively complete and mature OAM
   mechanism for the point-to-point service.  But for LDP LSP, owing to
   the MP2P model it is difficult to identify the flow from a specific
   PE based on the label.  Source label has been proposed as a possible
   solution([I-D.chen-mpls-source-label]).  When the source label is
   applied, MPLS path can be as follows:

   +----------+----------+----------+----------+
   |  Entropy |VPN Prefix|    VPN   |  Source  | ---> Transport
   |   Label  |   Label  |   Label  |   Label  |        Tunnel
   +----------+----------+----------+----------+

4.1.5.  Traffic Steering

   Service traffic may span multiple ASes.  It is an important use case
   to steer traffic at ASBR in an AS to specific ASBR in neighboring AS.
   There are possible solutions for this type of traffic steering:

   1.  Traffic Steering based on Transport Tunnel

   This method looks on the segment between two ASBRs as the extension
   of the transport tunnel in an AS.  It can steer the traffic through
   the specific path to the neighboring AS.

   2.  Traffic Steering in Service/Network Layer

   This method is to directly encapsulate the service flow with the
   steering label in the ingress PE before it enters into the transport
   tunnel.  [I-D.filsfils-spring-segment-routing-central-epe]
   illustrates the application of Segment Routing to solve the Egress
   Peer Engineering (EPE) requirement.  When this method is applied, the
   MPLS path can be as follows:

 +----------+----------+----------+----------+----------+
 |  Entropy | Steering |VPN Prefix|    VPN   |  Source  | ---> Transport
 |   Label  |   Label  |   Label  |   Label  |   Label  |        Tunnel
 +----------+----------+----------+----------+----------+

4.2.  Use Cases of Multicast Service








Li & Zhuang             Expires September 9, 2015               [Page 7]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


4.2.1.  Basic Reachability

   When MPLS multicast tunnel is applied for the multicast service in
   BGP-based MVPN, VPLS or EVPN, the basic MPLS path can be as follows:

   +-----------+
   | Multicast |--->     Transport
   |  Payload  |     Multicast Tunnel
   +-----------+

4.2.2.  MVPN Identification

   When multiple MVPNs shares the MPLS multicast tunnel, it is necessary
   to encapsulate the label to identify specific MVPN([RFC6514]).  The
   MPLS path can be as follows:

   +-----------+----------+
   | Multicast |   MVPN   | --->     Transport
   |  Payload  |   Label  |      Multicast Tunnel
   +-----------+----------+

4.2.3.  Source Identification

   In order to implement the split horizon or C-MAC learning in the
   fowarding plane when MPLS multicast is to bear BUM traffic in L2VPN,
   it is necessary to introduce the label to identify the source of the
   BUM traffic([I-D.li-l2vpn-segment-evpn]).  The MPLS path is as
   follows:

   +-----------+----------+----------+
   | Multicast |   EVPN   |  Source  | --->     Transport
   |  Payload  |   Label  |   Label  |      Multicast Tunnel
   +-----------+----------+----------+

4.3.  Use Cases of MPLS Virtual Network

   The framework of MPLS virtual network has been proposed in
   [I-D.li-mpls-network-virtualization-framework].  When the unicast
   service or the multicast service enters into the transport tunnel, it
   may take different MPLS virtual network identified by the MPLS label
   for the purpose of QoS routing, security or virtual operations.  The
   MPLS path is as follows:

   +-------------+      +-----------------+
   |   Service   | ---> | Virtual Network | ---> Transport
   | Label Stack |      |      Label      |       Tunnel
   +-------------+      +-----------------+




Li & Zhuang             Expires September 9, 2015               [Page 8]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


4.4.  Use cases of More Label Combinations

   Service-oriented MPLS path programming can make full use of flexible
   combination of MPLS labels to satisfy different requirements for the
   service flow.  Based on the above proposed use cases, MPLS path can
   be composed adopting part or whole labels for these use cases based
   on the service requirement.  Besides this, more flexible MPLS label
   combination may be provided:

   1.  Hierarchical process or multiple repeated process: The label for
   the same usage can exist in different layers.  Or the process
   identified by the label can exist in multiple nodes along the path.
   Then the labels for the same usage can be encapsulated several times
   in the label stack.  The encapsulation can be as follows (using
   SERVICE LABEL to identify the label for the same service process in
   different layers):

   +----------+----------+----------+----------+----------+----------+
   | SERVICE  |VPN Prefix| SERVICE  |    VPN   | SERVICE  |  Tunnel  |
   |  LABEL   |   Label  |  LABEL   |   Label  |  LABEL   |   Label  |
   +----------+----------+----------+----------+----------+----------+

   2.  Special-purpose label indicator: Since the label in the service-
   oriented MPLS programming is for special-purpose process, it may need
   a special purpose label to indicate the usage of the label followed
   the special-purpose labels.  For example, the ELI( Entropy Label
   Indicator) is introduced for the entropy label.  This may introduce
   more labels for the combination.

   This document is not to define all possible use cases for the
   service-oriented path programming.  The new use cases can be defined
   in the future independent document.

4.5.  Use cases for Centralized Mapping of Service to Tunnels

   In the transport layers, there can be multiple tunnels to one
   specific destination which satisfy different constraints.  In the
   traditional way, the tunnel is set up by the distributed forwarding
   nodes.  As the PCE-initiated LSP setup
   [I-D.ietf-pce-pce-initiated-lsp]is introduced, the tunnel can be
   setup in the central controlled way.  In order to satisfy the
   different service requirements, it is necessary to provide the
   capability to flexibly map the service to different tunnels.  Since
   the central control point has enough information based on the whole
   network view, it can be an effective way to map the service to the
   tunnel by the central point and advertise the mapping information to
   the end-points of the service to guide the mapping in the forwarding
   node.



Li & Zhuang             Expires September 9, 2015               [Page 9]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


5.  Framework of Service-Oriented MPLS Path Programming

5.1.  Central Control for MPLS Path Programming

   Central control plays an important role in MPLS path programming.  It
   can extend the MPLS path programming capability easily.  There are
   two important functionalities for the central control:

   1.  Central controlled MPLS label allocation: Label can be allocated
   centrally for special usage other than reachability.  These labels
   can be used to compose MPLS path.  We call it as MPLS Segment.

   2.  Central controlled MPLS path programming: Central controller can
   calculate path in a global network view and implement the MPLS path
   programming based on the collected information of MPLS segments to
   satisfy different requirements of services.

                  +-------------------+
                  |       Central     |
                  |     Controller    |
       |----------|(Path Calculation  |--------|
       |          | /Path Programming)|        |
       |          +-------------------+        |
       |            /      |       \           |
   MPLS Path       /    Segment     \       MPLS Path
       |          /    Allocation    \         |
       |     Segment       |         Segment   |
       |    Allocation     |        Allocation |
       |       /           |            \      |
       |      /            |             \     |
    +--------+         +--------+         +--------+
    | CLIENT |         | CLIENT |         | CLIENT |
    |        | ......  |        | ......  |        |
    |  (PE)  |         |  (P)   |         |  (PE)  |
    |        |         |        |         |        |
    +--------+         +--------+         +--------+

   Figure 2 Central Control for MPLS Path Programming

   There are two types of MPLS path: Transport-Oriented MPLS Path and
   Service-Oriented MPLS Path.  For the transport-oriented MPLS path,
   segment routing is the typical solution: MPLS segment distribution is
   done by IGP extensions ([I-D.ietf-isis-segment-routing-extensions])
   and [I-D.ietf-ospf-segment-routing-extensions]); the programmed MPLS
   path can be downloaded through PCEP extensions from PCE to
   PCC([I-D.sivabalan-pce-segment-routing]).  For the service-oriented
   MPLS path programming, it not only includes composing the MPLS path
   in the service and network layer, but also includes determining the



Li & Zhuang             Expires September 9, 2015              [Page 10]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


   mapping of the service path to the transport path.  Since the process
   corresponding to the label in the service label stack is always
   located at the PE nodes, BGP extensions can be introduced for
   service-oriented path programming.

5.2.  BGP-based MPLS Segment Distribution

   1.  Label Allocation

   There are two types of label used for MPLS segments:

   1) Local Label: The service process is done locally.  The label can
   be allocated by the local PE which provides the process.

   2) Global Label: The service process is common in multiple PEs.  This
   means the label has global meaning.  The label allocation can be done
   by the central controller.  The global label work can refer to
   [I-D.li-mpls-global-label-framework].

   2.  Label Mapping Distribution

   BGP extensions can be used to distribution label mapping.  Regarding
   to the above two types of label allocation, the process is as
   follows:

   1) Local Label Mapping: BGP can directly distribute the label mapping
   from the local PE to peer PEs.  The local PE can also only distribute
   the label mapping to central controller.  Then the central controller
   re-distribute the label mapping to other PEs.  In this method, the
   central controller plays the role of traditional RR.

   2) Global Label Mapping: The label mapping for the service can be
   directly distributed by the central controller to multiple PEs.  It
   can be done by BGP extensions.

5.3.  MPLS Service Path Programming

5.3.1.  Label Combination and Download of MPLS Path

   According to the service requirements, the central controller can
   combine MPLS segments flexibly.  Then it can download the service
   label combination for specific prefix related with the service.  The
   BGP extensions can be reused to download the programmed MPLS path.








Li & Zhuang             Expires September 9, 2015              [Page 11]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


5.3.2.  Mapping of Service Path to Service Path

   Since the transport path is also to satisfy the service bearing the
   requirement, it can reuse the existing MPLS tunnel technology or it
   can also be programmed according to traffic engineering requirements
   of service.  Then there needs to be implements the mapping of the
   service path to the transport path.  There are two ways to implement
   the mapping:

   1.  BGP Extensions: Through the community attribute of BGP, the
   identifier of the transport path can be carrier when distribute label
   stack for a specific prefix.

   2.  I2RS Extensions: I2RS can be used to download route policy to the
   client node.  Based on the policy, the client node can implement the
   required mapping.

5.4.  Compatibility

   When the MPLS path programming is done the central controller and
   downloaded through BGP extensions to the Client node, the path SHOULD
   has higher priority than the path calculated on the Client node's
   own.

5.5.  Protocol Extensions Requirements

5.5.1.  BGP

   REQ 01: BGP extensions SHOULD be introduced to distribute local label
   mapping for specific process to the central controller and other
   client nodes.

   REQ 02: BGP extensions SHOULD be introduced to distribute global
   label mapping for specific process from the central controller to the
   client nodes .

   REQ 03: BGP extensions SHOULD be introduced to download label stack
   for service-oriented MPLS path.

   REQ 04: BGP extensions SHOULD be introduced to carry the identifier
   of the transport MPLS path with service MPLS path to implement the
   mapping.

   REQ 05: BGP extensions SHOULD be introduced to specify the end-points
   to accept the prefix advertised by the central controller.






Li & Zhuang             Expires September 9, 2015              [Page 12]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


   REQ 06: BGP extensions SHOULD be introduced to specify the priority
   for the prefix with attributes of MPLS path programming advertised by
   the central controller.

   REQ 07: When route selection is done in the client node, the path
   advertised by the central controller SHOULD has higher priority than
   the path calculated on the client's own.

5.5.2.  I2RS

   REQ 11: I2RS clients SHOULD provide interface to I2RS agent to
   download policy to implement the mapping of the service path to the
   transport path.

6.  IANA Considerations

   This document makes no request of IANA.

7.  Security Considerations

   TBD.

8.  References

8.1.  Normative References

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

8.2.  Informative References

   [I-D.chen-mpls-source-label]
              Chen, M., Xu, X., Li, Z., Fang, L., and G. Mirsky,
              "MultiProtocol Label Switching (MPLS) Source Label",
              draft-chen-mpls-source-label-06 (work in progress),
              October 2014.

   [I-D.filsfils-spring-segment-routing]
              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
              Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
              "Segment Routing Architecture", draft-filsfils-spring-
              segment-routing-04 (work in progress), July 2014.








Li & Zhuang             Expires September 9, 2015              [Page 13]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


   [I-D.filsfils-spring-segment-routing-central-epe]
              Filsfils, C., Previdi, S., Patel, K., Aries, E.,
              shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment
              Routing Centralized Egress Peer Engineering", draft-
              filsfils-spring-segment-routing-central-epe-03 (work in
              progress), January 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-03 (work in progress), October 2014.

   [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-04 (work in progress), February 2015.

   [I-D.ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-ietf-pce-pce-initiated-lsp-03 (work in
              progress), March 2015.

   [I-D.li-l2vpn-segment-evpn]
              Li, Z., Yong, L., and J. Zhang, "Segment-Based
              EVPN(S-EVPN)", draft-li-l2vpn-segment-evpn-01 (work in
              progress), February 2014.

   [I-D.li-mpls-global-label-framework]
              Li, Z., Zhao, Q., Chen, X., Yang, T., and R. Raszuk, "A
              Framework of MPLS Global Label", draft-li-mpls-global-
              label-framework-02 (work in progress), July 2014.

   [I-D.li-mpls-global-label-usecases]
              Li, Z., Zhao, Q., Yang, T., and R. Raszuk, "Use Cases of
              MPLS Global Label", draft-li-mpls-global-label-usecases-02
              (work in progress), July 2014.

   [I-D.li-mpls-network-virtualization-framework]
              Li, Z. and M. Li, "Framework of Network Virtualization
              Based on MPLS Global Label", draft-li-mpls-network-
              virtualization-framework-00 (work in progress), October
              2013.






Li & Zhuang             Expires September 9, 2015              [Page 14]

Internet-Draft   Service-Oriented MPLS Path Programming       March 2015


   [I-D.sivabalan-pce-segment-routing]
              Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
              Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions
              for Segment Routing", draft-sivabalan-pce-segment-
              routing-03 (work in progress), July 2014.

   [I-D.zhang-l3vpn-label-sharing]
              Zhang, M., Zhou, P., and R. White, "Label Sharing for Fast
              PE Protection", draft-zhang-l3vpn-label-sharing-02 (work
              in progress), June 2014.

   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
              2005.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [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.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, November 2012.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Shunwan Zhuang
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhuangshunwan@huawei.com







Li & Zhuang             Expires September 9, 2015              [Page 15]