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

Versions: 00

Network Working Group                                              Z. Li
Internet-Draft                                              I. Milojevic
Intended status: Informational                                 Z. Zhuang
Expires: April 19, 2016                              Huawei Technologies
                                                        October 17, 2015


                     Segment Path Programming (SPP)
              draft-li-spring-segment-path-programming-00

Abstract

   Segment Routing for unicast traffic has been proposed to cope with
   the usecases in traffic engineering, fast re-reroute, service chain,
   etc.  The document generalizes more use cases based on segment and
   proposes the concept of Segment Path Programming.  In the field of
   Segment Path Programming: 1.  The Segment used in the programmed
   segment path is not only used in the forwarding plane, but also used
   in the control plane. 2.  The programmed segment path is not only
   used in the transport layer, but also used in the service layer.
   Accordingly this document proposes use cases, architecture and
   protocol extension requirements for the Segment Path Programming
   (SPP).

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       Segment Path Programming (SPP)         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.  Redefinition of Segment . . . . . . . . . . . . . . . . . . .   3
     3.1.  Application of Segment in Control Plane and Forwarding
           Plane . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Application of Segment in Reachability and Service
           Process . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Definition of Segment Path Programming Path . . . . . . . . .   6
   5.  Usecases of Segment Path Programming  . . . . . . . . . . . .   7
     5.1.  Flexible Service Process Combination  . . . . . . . . . .   7
     5.2.  Node Segment for Synonymous Flow Label  . . . . . . . . .   8
     5.3.  Steering Traffic without Mapping Segment to Label . . . .   8
     5.4.  Centralized Mapping Service to Tunnels  . . . . . . . . .   9
   6.  Framework of Service-Oriented MPLS Path Programming . . . . .  11
     6.1.  Central Control for MPLS Path Programming . . . . . . . .  11
     6.2.  Protocol Extensions Requirements  . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Segment Routing [I-D.ietf-spring-segment-routing] for unicast traffic
   has been proposed to cope with the usecases in traffic engineering,
   fast re-reroute, service chain, etc.  The document generalizes more
   use cases based on segment and proposes the concept of Segment Path
   Programming.  In the field of Segment Path Programming: 1.  The
   Segment used in the programmed segment path is not only used in the



Li, et al.               Expires April 19, 2016                 [Page 2]


Internet-Draft       Segment Path Programming (SPP)         October 2015


   forwarding plane, but also used in the control plane.  2.  The
   programmed segment path is not only used in the transport layer, but
   also used in the service layer.  Accordingly this document proposes
   use cases, architecture and protocol extension requirements for the
   Segment Path Programming (SPP).

2.  Terminology

   BGP: Border Gateway Protocol

   L2VPN: Layer 2 VPN

   L3VPN: Layer 3 VPN

   SPP: Segment Path Programming

   SR-path: Segment Routing Path

   SRGB: SR Global Block

3.  Redefinition of Segment

3.1.  Application of Segment in Control Plane and Forwarding Plane

   In the existing segment routing, the segment will be applied to the
   MPLS forwarding plane directly.  In the MPLS architecture, the global
   segment such as node segment will be mapped to MPLS label since SRGB
   will be defined as the set of local labels reserved for global
   segments and the local segment will be a local label outside the
   SRGB.

   In fact, the segment can be only used in the control plane instead of
   mapping to the forwarding plane.  In the usecase, the segment is just
   an indicator for specific process which can be used for the
   application of Segment Path Programming.

   For example, node segment in the Segment Routing mapped in the
   control plane and forwarding plane in the MPLS architecture is shown
   in the following figure.












Li, et al.               Expires April 19, 2016                 [Page 3]


Internet-Draft       Segment Path Programming (SPP)         October 2015


   Control Plane:
   +---------+              +------------+
   | Segment |              |            |
   |         |      =       |   Label    |
   |   ID    |              |            |
   +---------+              +------------+


   Forwarding Plane:
   +--------+------------+      +------------+-------------------------+
   |        | Forwarding |      | Forwarding | Forwarding Information  |
   | Label  |            | -->  |            |        to               |
   |        |   Index    |      |   Index    |   Specified Node        |
   +--------+------------+      +------------+-------------------------+


             Figure 1: Node Segment in Segment Routing

   In the Segment Path Programming, the node segment can be enhanced to
   support following mapping in the control plane and forwarding plane
   even in the MPLS architecture.

   Control Plane:
     +---------+              +------------+
     | Segment |              | Forwarding |
     |         |      -->     |            |
     |   ID    |              |   Index    |
     +---------+              +------------+


   Forwarding Plane:
                              +------------+-------------------------+
                              | Forwarding | Forwarding Information  |
                              |            |        to               |
                              |   Index    |   Specified Node        |
                              +------------+-------------------------+

       Figure 2: Enhanced Node Segment in Segment Path Programming

   In this mapping, the Segment ID can map to the forwarding entry to
   specific node.  But it is only an indicator in the control plane
   which can be used for possible applications.  When receive the
   mapping information between the application and the Segment ID, the
   network node will install additional forwarding entry as follows
   which map the application information to the forwarding information
   specified by the segment ID.





Li, et al.               Expires April 19, 2016                 [Page 4]


Internet-Draft       Segment Path Programming (SPP)         October 2015


 Control Plane:

   Mapping Information
 +--------+------------+
 |  App   |  Segment   |
 |        |            |
 |  Info  |     ID     |
 +--------+------------+


 Forwarding Plane:
 +----------+------------+      +------------+-------------------------+
 |          | Forwarding |      | Forwarding | Forwarding Information  |
 | App Info |            | -->  |            |        to               |
 |          |   Index    |      |   Index    |   Specified Node        |
 +----------+------------+      +------------+-------------------------+
     Figure 3: Mapping App to Segment in Segment Path Programming

   The application information in the forwarding entry should be derived
   from the packet received by the network nodes such as the destination
   IP/MAC address, the source IP/MAC address, the port number, the
   protocol number, etc.  It can also be the MPLS label.

   In order to support the enhanced segment in the Segment Programming
   Path, whether to map the Segment to MPLS label can be determined by
   the local policy of the network node.  Protocol extensions can also
   be introduced to specify if the Segment maps to the MPLS label when
   advertised the information of SRGBs or all kinds of Segments.

3.2.  Application of Segment in Reachability and Service Process

   In the existing Segment Routing, in the MPLS architecture the segment
   will be mapped to the label which is always the indicator of
   reachability to the specific node, the specific agency, etc.  More
   types of Segments which indicates the reachability can be introduced
   according to existing MPLS forwarding plane.  Since these segments
   represent reachability in the network, they can be used for traffic
   steering.  These segments includes:

   -- Node Segment

   -- Agency Segment

   -- AS (Autonomous System) Segment

   -- Anycast Segment

   -- Multicast Segment



Li, et al.               Expires April 19, 2016                 [Page 5]


Internet-Draft       Segment Path Programming (SPP)         October 2015


   -- Tunnel Segment

   -- VPN Segment

   -- etc.

   As the development of Segment Routing, the service segment is
   introduced to represent the specific service process.  It can be used
   for some new application scenarios such qw the Service Function Chain
   (SFC).  For the service process in the traditional IP/MPLS fowarding
   plane, it can also be indicated by different types of segments.  This
   provides the possibility to flexibly combine these segment to set up
   a Segment Path to represent a series of service process in the
   network on the specific flow instead of only steering traffic.  These
   Segments can represent different service process in the forwarding
   plane as follows:

   -- OAM Segment

   -- ECMP (Equal Cost Multi-Path) Segment

   -- QoS Segment

   -- Bandwidth-Guarantee Segment

   -- Security Segment

   -- Multi-Topology Segment

   -- etc.

4.  Definition of Segment Path Programming Path

   Owing to more types of segments and flexible application of segment
   in the control plane and the forwarding plane, there will be powerful
   capability to combine these segments which can be used to steering
   traffic or provide flexible service process to satisfy different
   service requirement for specific flows in the network.  We call such
   combination of segments as Segment Path and the flexible combining of
   segments as Segment Path Programming.

   Segment Routing ([I-D.ietf-spring-segment-routing]) is a typical
   example of Segment Path Programming.  There can be multiple layers
   for Segment Path Programming which are shown in the following figure:







Li, et al.               Expires April 19, 2016                 [Page 6]


Internet-Draft       Segment Path Programming (SPP)         October 2015


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

             Service-oriented Segment Path Programming
                             (SoSPP)
     o--------o--------- Service Layer------------o--------o

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


             Transport-oriented Segment Path Programming
                          (Segment Routing)
              o-------o--------o---------o-------o  Transport Layer

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


          Figure 4: Multiple Layers of Segment Path Programming

   Now the segment routing is to provide the source packet routing in
   the transport layer or the link layer for traffic steering . We can
   call such type of source packet routing as Transport-Oriented Segment
   Path Programming.  There can be more application scenarios which need
   the segment path to respresent the service processes in the service
   layer or network layer.  We call these types of source packet routing
   as Service-Oriented Segment Path Programming.

5.  Usecases of Segment Path Programming

5.1.  Flexible Service Process Combination

   The following figure shows the usecase of Segment Path Programming to
   combine service segments according to the service requirements on the
   traffic which can be specified by the traditional BGP VPN prefix.
   The combination of these service segments represent the required
   ECMP, QoS and OAM process.












Li, et al.               Expires April 19, 2016                 [Page 7]


Internet-Draft       Segment Path Programming (SPP)         October 2015


   Traditional Label Binding for VPN Prefix:
   +----------+----------+
   |   VPN    |VPN Prefix|
   |  Prefix  |   Label  |
   +----------+----------+

   Additional Segment Path Information:
   +----------+----------+----------+
   |   ECMP   |    QoS   |   OAM    |
   |  Segment |  Segment |  Segment |
   +----------+----------+----------+

   If the network node maps the corresponding segment to MPLS label, the
   forwarding entry can be as follows:

+----------+     +----------+----------+----------+----------+
|VPN Prefix|     |  Entropy |    QoS   |    OAM   |VPN Prefix|      Transport Tunnel
|          | --> |   Label  |   Label  |   Label  |   Label  | --->  determined by
+----------+     +----------+----------+----------+----------+        BGP Nexthop

5.2.  Node Segment for Synonymous Flow Label

   Synonymous flow label has been proposed by
   [I-D.bryant-mpls-synonymous-flow-labels] to solve the issue of the
   measurement of packet loss for multipoint-to-point LSP.  Node segment
   advertised in the Segment Routing can be used as the flow label.  In
   the scenario of performance measurement the flow label can only be
   interpreted by network node to identify the source of the flow other
   than set up the MPLS forwarding entry for the node segment in the
   scenario of segment routing.  So when advertise the node segment
   information on the usage of the node segment can also be carried or
   the local policy can be introduced to determine the application of
   the node segment.  Then the segment path can be set up based on such
   node segment for the purpose of performance measurement.

5.3.  Steering Traffic without Mapping Segment to Label

   The following figure shows the usecase of Segment Path Programming to
   steer traffic which can be specified by the traditional BGP prefix.












Li, et al.               Expires April 19, 2016                 [Page 8]


Internet-Draft       Segment Path Programming (SPP)         October 2015


   Traditional BGP Prefix:
   +----------+
   |   BGP    |
   |  Prefix  |
   +----------+


   Additional Segment Path Information:
   +----------+----------+
   |  Agency  |   Node   |
   |  Segment |  Segment |
   +----------+----------+

   If these segments are not applied in the MPLS forwarding plane, the
   Segment Path will be explained as steering traffic specified by the
   BGP prefix to reach specific node (determined by the Node Segment)
   through specific local link (determined by the Agency Segment).  The
   corresponding fowarding entry will be as follows:

+----------+------------+      +------------+---------------+--------------------+
|    BGP   | Forwarding |      | Forwarding |   Next Hop    | Outgoing Interface |
|          |            | -->  |            | determined by |    determine by    |
|   Prefix |   Index    |      |   Index    |  Node Segment |    Link Segment    |
+----------+------------+      +------------+---------------+--------------------+

5.4.  Centralized Mapping Service to Tunnels

   In the transport layers, there can be multiple tunnels with different
   constraints to one specific destination.  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 setup can be triggered by 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.

   The method to implement mapping service to tunnels can directly
   introduce the tunnel attribute to specify the tunnel proposed by
   [I-D.li-idr-mpls-path-programming].  [I-D.li-spring-tunnel-segment]
   proposes one new type of segment, Tunnel Segment, which can provide
   an alternative way to implement mapping service to tunnels.  In the
   following figure, the central controller can trigger to set up the
   MPLS TE tunnels through PCE-initiated LSP and allocate Segment ID for
   the tunnel in the Node-1.



Li, et al.               Expires April 19, 2016                 [Page 9]


Internet-Draft       Segment Path Programming (SPP)         October 2015


      +------------+
      |  Central   |
      | Controller |
      +------------+
         ^ Tunnel Binding
         | SID (Z)
         |          .-----.
         |         (       )
         V     .--(         )--.
   +-------+  (                 )  +-------+
   |       |_(  IP/MPLS Network  )_|       |
   |Node-1 | ( ================> ) |Node-2 |
   +-------+  (MPLS TE/IP Tunnel)  +-------+
               '--(         )--'
                   (       )
                    '-----'

   Figure 5: Using Tunnel Segment for Mapping Service to Tunnel

   Without applying the segment to MPLS label the Node-1 can set up the
   following mapping for the tunnel segment:

   Control Plane:
     +---------+              +------------+
     | Segment |              | Forwarding |
     |         |      -->     |            |
     |   ID    |              |   Index    |
     +---------+              +------------+


   Forwarding Plane:
                              +------------+-----------------------+
                              | Forwarding |    Tunnel Forwarding  |
                              |            |                       |
                              |   Index    |      Information      |
                              +------------+-----------------------+

       Figure 6: Enhanced Node Segment in Segment Path Programming

   Then the central controller can advertise following Segment Path
   information for the flow which can be specified by the traditional
   BGP prefix.









Li, et al.               Expires April 19, 2016                [Page 10]


Internet-Draft       Segment Path Programming (SPP)         October 2015


   Traditional BGP Prefix:
   +----------+
   |   BGP    |
   |  Prefix  |
   +----------+


   Additional Segment Path Information:
   +----------+
   |  Tunnel  |
   |  Segment |
   +----------+

   Then the following forwarding entry can be set up for the specified
   BGP prefix to steer traffic to specific tunnel in the Noed-1.

   +----------+------------+      +------------+----------------------+
   |    BGP   | Forwarding |      | Forwarding |   Tunnel Forwarding  |
   |          |            | -->  |            |                      |
   |   Prefix |   Index    |      |   Index    |     Information      |
   +----------+------------+      +------------+----------------------+

6.  Framework of Service-Oriented MPLS Path Programming

6.1.  Central Control for MPLS Path Programming

   Central control plays an important role in Segment Path Programming
   shown in the figure 7.  There are two important functionalities for
   the central controller:

   1.  Central controlled Segment allocation/collection: Segment can be
   allocated centrally for specific usage.  Or central controller can
   collect the segment binding information from the network nodes.
   BGP/PCEP/IGP extensions can be introduced to distribute or collect
   the segment binding information.

   2.  Central controlled Segment Path Programming: Central controller
   can calculate path in a global network view and implement the Segment
   Path Programming based on the collected information of segments to
   satisfy different requirements of service flows.  BGP/PCEP extensions
   can be introduced to download the Segment Path for the Service/
   Network layer or Transport/Link layer.









Li, et al.               Expires April 19, 2016                [Page 11]


Internet-Draft       Segment Path Programming (SPP)         October 2015


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

   Figure 7: Central Control for Segment Path Programming

6.2.  Protocol Extensions Requirements

   REQ 01: BGP/PCEP/IGP extensions should be introduced to distribute
   Segment binding for specific usage from the central controller to
   other client nodes.

   REQ 02: BGP/PCEP/IGP extensions should be introduced to collect
   Segment binding for specific usage from the client nodes to the
   central controller.

   REQ 03: BGP extensions should be introduced to download Segment
   (stack) for Segment Path of the service/network layer.

   REQ 04: PCE extensions should be introduced to download Segment
   (stack) for Segment Path of the transport layer.

   REQ 05: Protocol extensions should be introduced to specify the
   application of SRGB or Segment which means if the segment is applied
   to MPLS forwarding plane.

7.  IANA Considerations

   This document makes no request of IANA.






Li, et al.               Expires April 19, 2016                [Page 12]


Internet-Draft       Segment Path Programming (SPP)         October 2015


8.  Security Considerations

   TBD.

9.  References

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

9.2.  Informative References

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

   [I-D.li-idr-mpls-path-programming]
              Li, Z., "BGP Extensions for Service-Oriented MPLS Path
              Programming (MPP)", draft-li-idr-mpls-path-programming-01
              (work in progress), March 2015.

   [I-D.li-spring-tunnel-segment]
              Li, Z. and N. Wu, "Tunnel Segment in Segment Routing",
              draft-li-spring-tunnel-segment-00 (work in progress),
              September 2015.

Authors' Addresses







Li, et al.               Expires April 19, 2016                [Page 13]


Internet-Draft       Segment Path Programming (SPP)         October 2015


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

   Email: lizhenbin@huawei.com


   Igor Milojevic
   Huawei Technologies
   Poland-Warsaw-TULIPAN HOUSE, UL. DOMANI EWSKA 50, 02-672
   Warsaw
   Poland

   Email: Igor.Milojevic@huawei.com


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

   Email: zhuangshunwan@huawei.com


























Li, et al.               Expires April 19, 2016                [Page 14]


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