Internet DRAFT - draft-xuclad-spring-sr-service-chaining

draft-xuclad-spring-sr-service-chaining







SPRING                                                      F. Clad, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                              X. Xu, Ed.
Expires: September 6, 2018                                       Alibaba
                                                             C. Filsfils
                                                     Cisco Systems, Inc.
                                                              D. Bernier
                                                             Bell Canada
                                                                   C. Li
                                                                  Huawei
                                                             B. Decraene
                                                                  Orange
                                                                   S. Ma
                                                                 Juniper
                                                           C. Yadlapalli
                                                                    AT&T
                                                           W. Henderickx
                                                                   Nokia
                                                              S. Salsano
                                        Universita di Roma "Tor Vergata"
                                                           March 5, 2018


                  Segment Routing for Service Chaining
               draft-xuclad-spring-sr-service-chaining-01

Abstract

   This document defines data plane functionality required to implement
   service segments and achieve service chaining in SR-enabled MPLS and
   IP networks, as described in the Segment Routing architecture.

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 https://datatracker.ietf.org/drafts/current/.




Clad, et al.            Expires September 6, 2018               [Page 1]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   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 6, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://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 . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Classification and steering . . . . . . . . . . . . . . . . .   5
   4.  Service Functions . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  SR-aware SFs  . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  SR-unaware SFs  . . . . . . . . . . . . . . . . . . . . .   6
   5.  Service function chaining . . . . . . . . . . . . . . . . . .   7
     5.1.  SR-MPLS data plane  . . . . . . . . . . . . . . . . . . .   8
       5.1.1.  Encoding SFP Information by an MPLS Label Stack . . .   8
       5.1.2.  Encoding SFC Information by an MPLS Label Stack . . .  11
     5.2.  SRv6 data plane . . . . . . . . . . . . . . . . . . . . .  14
       5.2.1.  Encoding SFP Information by an SRv6 SRH . . . . . . .  14
       5.2.2.  Encoding SFC Information by an IPv6 SRH . . . . . . .  16
   6.  SR proxy behaviors  . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  Static SR proxy . . . . . . . . . . . . . . . . . . . . .  20
       6.1.1.  SR-MPLS pseudocode  . . . . . . . . . . . . . . . . .  21
       6.1.2.  SRv6 pseudocode . . . . . . . . . . . . . . . . . . .  22
     6.2.  Dynamic SR proxy  . . . . . . . . . . . . . . . . . . . .  25
       6.2.1.  SR-MPLS pseudocode  . . . . . . . . . . . . . . . . .  25
       6.2.2.  SRv6 pseudocode . . . . . . . . . . . . . . . . . . .  26
     6.3.  Shared memory SR proxy  . . . . . . . . . . . . . . . . .  26
     6.4.  Masquerading SR proxy . . . . . . . . . . . . . . . . . .  27
       6.4.1.  SRv6 masquerading proxy pseudocode  . . . . . . . . .  28
       6.4.2.  Variant 1: Destination NAT  . . . . . . . . . . . . .  28



Clad, et al.            Expires September 6, 2018               [Page 2]

Internet-Draft    Segment Routing for Service Chaining        March 2018


       6.4.3.  Variant 2: Caching  . . . . . . . . . . . . . . . . .  29
   7.  Metadata  . . . . . . . . . . . . . . . . . . . . . . . . . .  29
     7.1.  MPLS data plane . . . . . . . . . . . . . . . . . . . . .  29
     7.2.  IPv6 data plane . . . . . . . . . . . . . . . . . . . . .  29
       7.2.1.  SRH TLV objects . . . . . . . . . . . . . . . . . . .  29
       7.2.2.  SRH tag . . . . . . . . . . . . . . . . . . . . . . .  30
   8.  Implementation status . . . . . . . . . . . . . . . . . . . .  30
   9.  Related works . . . . . . . . . . . . . . . . . . . . . . . .  31
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  31
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  32
   13. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  32
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  32
     14.2.  Informative References . . . . . . . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34

1.  Introduction

   Segment Routing (SR) is an architecture based on the source routing
   paradigm that seeks the right balance between distributed
   intelligence and centralized programmability.  SR can be used with an
   MPLS or an IPv6 data plane to steer packets through an ordered list
   of instructions, called segments.  These segments may encode simple
   routing instructions for forwarding packets along a specific network
   path, or rich behaviors to support use-cases such as Service Function
   Chaining (SFC).

   In the context of SFC, each Service Function (SF), running either on
   a physical appliance or in a virtual environment, is associated with
   a segment, which can then be used in a segment list to steer packets
   through the SF.  Such service segments may be combined together in a
   segment list to achieve SFC, but also with other types of segments as
   defined in [I-D.ietf-spring-segment-routing].  SR thus provides a
   fully integrated solution for SFC, overlay and underlay optimization.
   Furthermore, the IPv6 dataplane natively supports metadata
   transportation as part of the SR information attached to the packets.

   This document describes how SR enables SFC in a simple and scalable
   manner, from the segment association to the SF up to the traffic
   classification and steering into the service chain.  Several SR proxy
   behaviors are also defined to support SR SFC through legacy, SR-
   unaware, SFs in various circumstances.

   The definition of an SR Policy and the steering of traffic into an SR
   Policy is outside the scope of this document.  These aspects are
   covered in [I-D.filsfils-spring-segment-routing-policy].




Clad, et al.            Expires September 6, 2018               [Page 3]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   The definition of control plane components, such as service segment
   discovery, is outside the scope of this data plane document.  BGP
   extensions to support SR-based SFC are proposed in
   [I-D.dawra-idr-bgp-sr-service-chaining].

   Familiarity with the following IETF documents is assumed:

   o  Segment Routing Architecture [I-D.ietf-spring-segment-routing]

   o  Segment Routing with MPLS data plane
      [I-D.ietf-spring-segment-routing-mpls]

   o  Segment Routing Traffic Engineering Policy
      [I-D.filsfils-spring-segment-routing-policy]

   o  Segment Routing Header [I-D.ietf-6man-segment-routing-header]

   o  SRv6 Network Programming
      [I-D.filsfils-spring-srv6-network-programming]

   o  SR-MPLS over IP [I-D.xu-mpls-sr-over-ip]

   o  Service Function Chaining Architecture [RFC7665]

2.  Terminology

   This document leverages the terminology introduced in
   [I-D.ietf-spring-segment-routing],
   [I-D.filsfils-spring-segment-routing-policy] and [RFC7665].  It also
   introduces the following new terminology.

   SR-aware SF: Service Function fully capable of processing SR traffic

   SR-unaware SF: Service Function unable to process SR traffic or
   behaving incorrectly for such traffic

   SR proxy: Proxy handling the SR processing on behalf of an SR-unaware
   SF

   Service Segment: Segment associated with an SF, either directly or
   via an SR proxy

   SR SFC policy: SR policy, as defined in
   [I-D.filsfils-spring-segment-routing-policy], that includes at least
   one Service Segment.  An SR SFC policy may also contain other types
   of segments, such as VPN or TE segments.





Clad, et al.            Expires September 6, 2018               [Page 4]

Internet-Draft    Segment Routing for Service Chaining        March 2018


3.  Classification and steering

   Classification and steering mechanisms are defined in section 8 of
   [I-D.filsfils-spring-segment-routing-policy] and are independent from
   the purpose of the SR policy.  From a headend perspective, there is
   no difference whether a policy contains IGP, BGP, peering, VPN and
   service segments, or any combination of these.

   As documented in the above reference, traffic is classified when
   entering an SR domain.  The SR policy head-end may, depending on its
   capabilities, classify the packets on a per-destination basis, via
   simple FIB entries, or apply more complex policy routing rules
   requiring to look deeper into the packet.  These rules are expected
   to support basic policy routing such as 5-tuple matching.  In
   addition, the IPv6 SRH tag field defined in
   [I-D.ietf-6man-segment-routing-header] can be used to identify and
   classify packets sharing the same set of properties.  Classified
   traffic is then steered into the appropriate SR policy, which is
   associated with a weighted set of segment lists.

   SR traffic can be re-classified by an SR endpoint along the original
   SR policy (e.g., DPI service) or a transit node intercepting the
   traffic.  This node is the head-end of a new SR policy that is
   imposed onto the packet, either as a stack of MPLS labels or as an
   IPv6 and SRH encapsulation.

4.  Service Functions

   A Service Function (SF) may be a physical appliance running on
   dedicated hardware, a virtualized service inside an isolated
   environment such as a VM, container or namespace, or any process
   running on a compute element.  An SF may also comprise multiple sub-
   components running in different processes or containers.  Unless
   otherwise stated, this document does not make any assumption on the
   type or execution environment of an SF.

   SR enables SFC by assigning a segment identifier, or SID, to each SF
   and sequencing these service SIDs in a segment list.  A service SID
   may be of local significance or directly reachable from anywhere in
   the routing domain.  The latter is realized with SR-MPLS by assigning
   a SID from the global label block
   ([I-D.ietf-spring-segment-routing-mpls]), or with SRv6 by advertising
   the SID locator in the routing protocol
   ([I-D.filsfils-spring-srv6-network-programming]).  It is up to the
   network operator to define the scope and reachability of each service
   SID.  This decision can be based on various considerations such as
   infrastructure dynamicity, available control plane or orchestration
   system capabilities.



Clad, et al.            Expires September 6, 2018               [Page 5]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   This document categorizes SFs in two types, depending on whether they
   are able to behave properly in the presence of SR information or not.
   These are respectively named SR-aware and SR-unaware SFs.  An SR-
   aware SF can process the SR information in the packets it receives.
   This means being able to identify the active segment as a local
   instruction and move forward in the segment list, but also that the
   SF own behavior is not hindered due to the presence of SR
   information.  For example, an SR-aware firewall filtering SRv6
   traffic based on its final destination must retrieve that information
   from the last entry in the SRH rather than the Destination Address
   field of the IPv6 header.  Any SF that does not meet these criteria
   is considered as SR-unaware.

4.1.  SR-aware SFs

   An SR-aware SF is associated with a locally instantiated service
   segment, which is used to steer traffic through it.

   If the SF is configured to intercept all the packets passing through
   the appliance, the underlying routing system only has to implement a
   default SR endpoint behavior (SR-MPLS node segment or SRv6 End
   function), and the corresponding SID will be used to steer traffic
   through the SF.

   If the SF requires the packets to be directed to a specific virtual
   interface, networking queue or process, a dedicated SR behavior may
   be required to steer the packets to the appropriate location.  The
   definition of such SF-specific functions is out of the scope of this
   document.

   An SRv6-aware SF may also retrieve, store or modify information in
   the SRH TLVs.

4.2.  SR-unaware SFs

   An SR-unaware SF is not able to process the SR information in the
   traffic that it receives.  It may either drop the traffic or take
   erroneous decisions due to the unrecognized routing information.  In
   order to include such SFs in an SR SC policy, it is thus required to
   remove the SR information as well as any other encapsulation header
   before the SF receives the packet, or to alter it in such a way that
   the SF can correctly process the packet.

   In this document, we define the concept of an SR proxy as an entity,
   separate from the SF, that performs these modifications and handle
   the SR processing on behalf of an SF.  The SR proxy can run as a
   separate process on the SF appliance, on a virtual switch or router




Clad, et al.            Expires September 6, 2018               [Page 6]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   on the compute node or on a remote host.  In this document, we only
   assume that the proxy is connected to the SF via a layer-2 link.

   An SR-unaware SF is associated with a service segment instantiated on
   the SR proxy, which is used to steer traffic through the SF.
   Section 6 describes several SR proxy behaviors to handle the
   encapsulation headers and SR information under various circumstances.

5.  Service function chaining

   When applying a particular Service Function Chain (SFC) [RFC7665] to
   the traffic selected by a service classifier, the traffic need to be
   steered through an ordered set of Service Functions (SF) in the
   network.  This ordered set of SFs in the network indicates the
   Service Function Path (SFP) associated with the above SFC.  In order
   to steer the selected traffic through the required ordered list of
   SFs, the service classifier needs to attach information to the packet
   specifying exactly which Service Function Forwarders (SFFs) and which
   SFs are to be visited by traffic, the SFC, or the partially specified
   SFP which is in between the former two extremes.

   The SR source routing mechanisms can be used to steer traffic through
   an ordered set of devices (i.e., an explicit path) and instruct those
   nodes to execute specific operations on the packet.

   This section describes how to leverage SR to realize a transport-
   independent service function chaining by encoding the service
   function path information or service function chain information as an
   MPLS label stack or an IPv6 SRH.

         +-----------------------------------------------------+
         |                     SR network                      |
         |            +---------+       +---------+            |
         |            |   SF1   |       |   SF2   |            |
         |            +----+----+       +----+----+            |
         |               ^ | |(3)          ^ | |(6)            |
         |       (1)  (2)| | V     (4)  (5)| | V     (7)       |
    +----+-----+ ---> +----+----+ ----> +----+----+ --->  +----+-----+
    |    A     +------+  SFF1   +-------+  SFF2   +-------+    B     |
    | Head-end |      |         |       |         |       | Tail-end |
    +----------+      +---------+       +---------+       +----+-----+
         |                                                     |
         +-----------------------------------------------------+

            Figure 1: Service Function Chaining in SR networks

   As shown in Figure 1, SFF1 and SFF2 are two SR-capable nodes.  They
   are also SFFs, each with one SF attached.  In addition, they have



Clad, et al.            Expires September 6, 2018               [Page 7]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   allocated and advertised segments for their locally attached SFs.
   For example, SFF1 allocates and advertises a SID (i.e., S(SF1)) for
   SF1 while SFF2 allocates and advertises a SID (i.e., S(SF2)) for SF2.
   These SIDs, which are used to indicate SFs, are referred to as
   service segments, while the SFFs are identified by either node or
   adjacency segments depending on how strictly the network path needs
   to be specified.  In this example, we assume that the traffic is
   steered to both SFFs using their node segments S(SFF1) and S(SFF2),
   respectively.

   Now assume that a given traffic flow is steered in an SR policy
   instantiated on node A with an endpoint B, hereafter referred to as
   the SR policy head-end and tail-end respectively, and associated with
   particular SFC requirements (i.e., SF1-> SF2).  From an SR policy
   perspective, SFC is only a particular case of traffic engineering
   where the SR path includes service functions.  An SR-SFC policy
   inherits all the properties of SR-TE policies as defined in
   [I-D.filsfils-spring-segment-routing-policy].  Section 5.1 and
   Section 5.2 describe approaches of leveraging the SR-MPLS and SRv6
   mechanisms to realize stateless service function chaining.  The
   complete SFP and SFC information is encoded within an MPLS label
   stack or an IPv6 SRH carried by the packets, so that no per-chain
   state is required at the intermediate hops.  Since the encoding of
   the partially specified SFP is just a simple combination of the
   encoding of the SFP and the encoding of the SFC, this document would
   not describe how to encode the partially specified SFP anymore.

5.1.  SR-MPLS data plane

5.1.1.  Encoding SFP Information by an MPLS Label Stack





















Clad, et al.            Expires September 6, 2018               [Page 8]

Internet-Draft    Segment Routing for Service Chaining        March 2018


         +-----------------------------------------------------+
         |                   SR-MPLS network                   |
         |            +---------+       +---------+            |
         |            |   SF1   |       |   SF2   |            |
         |            +----+----+       +----+----+            |
         |  +---------+    |                 |    +---------+  |
         |  | S(SFF2) |    |                 |    | S(T)    |  |
         |  +---------+    |                 |    +---------+  |
         |  | S(SF2)  |    |                 |    |Inner pkt|  |
         |  +---------+    |                 |    +---------+  |
         |  | S(T)    |    |                 |                 |
         |  +---------+    |               ^ | |               |
         |  |Inner pkt| ^  | |             | | |               |
         |  +---------+ |  | |          (5)| | |(6)            |
         |           (2)|  | |(3)          | | V               |
         |       (1)    |  | V     (4)       |      (7)        |
    +----+-----+ ---> +----+----+ ----> +----+----+ --->  +----+-----+
    | Head-end +------+  SFF1   +-------+  SFF2   +-------+ Tail-end |
    +----------+      +---------+       +---------+       +----+-----+
         |    +---------+      +---------+        +---------+  |
         |    | S(SFF1) |      | S(SFF2) |        | S(T)    |  |
         |    +---------+      +---------+        +---------+  |
         |    | S(SF1)  |      | S(SF2)  |        |Inner pkt|  |
         |    +---------+      +---------+        +---------+  |
         |    | S(SFF2) |      | S(T)    |                     |
         |    +---------+      +---------+                     |
         |    | S(SF2)  |      |Inner pkt|                     |
         |    +---------+      +---------+                     |
         |    | S(T)    |                                      |
         |    +---------+                                      |
         |    |Inner pkt|                                      |
         |    +---------+                                      |
         +-----------------------------------------------------+

                  Figure 2: Packet walk in MPLS underlay

   As shown in Figure 2, the head-end, acting as a service classifier,
   determines that the selected packet needs to travel through an SFC
   (SF1->SF2) and steers this packet into the appropriate SR policy as
   described in [I-D.filsfils-spring-segment-routing-policy].  As a
   result, the packet is encapsulated with an MPLS label stack
   containing the segment list <SFF1, SF1, SFF2, SF2, T>.  This segment
   list encodes in a stateless manner the SFP corresponding to the above
   SFC as an MPLS label stack where each service segment is a local MPLS
   label allocated from SFFs' label spaces.  To some extent, the MPLS
   label stack here could be looked as a specific implementation of the
   SFC encapsulation used for containing the SFP information [RFC7665],
   which does not require the SFF to maintain per-chain state.



Clad, et al.            Expires September 6, 2018               [Page 9]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   When the encapsulated packet arrives at SFF1, SFF1 knows how to send
   the packet to SF1 based on the top label (i.e., S(SF1)) of the
   received MPLS packet.  We first consider the case where SF1 is an SR-
   aware SF, i.e., it understands how to process a packet with a pre-
   pended SR-MPLS label stack.  In this case the packet would be sent to
   SF1 by SFF1 with the label stack S(SFF2)->S(SF2).  SF1 would perform
   the required service function on the received MPLS packet where the
   payload type is determined using the first nibble of the MPLS
   payload.  After the MPLS packet is returned from SF1, SFF1 would send
   it to SFF2 according to the top label (i.e., S(SFF2)).

   If SF1 is an SR-unaware SF, i.e. one that is unable to process the
   MPLS label stack, the remaining MPLS label stack (i.e.,
   S(SFF2)->S(SF2)) MUST be stripped from the packet before sending the
   packet to SF1.  When the packet is returned from SF1, SFF1 would re-
   impose the MPLS label stack which had been previously stripped and
   then send the packet to SFF2 according to the current top label
   (i.e., S(SFF2)).  Proxy mechanisms to support SR-unaware SFs are
   proposed in section 6 of this document.

   When the encapsulated packet arrives at SFF2, SFF2 would perform the
   similar action to that described above.

   By leveraging the SR-MPLS data plane, [I-D.xu-mpls-sr-over-ip]
   describes a source routing instruction which works across both IPv4
   and IPv6 underlays in addition to the MPLS underlay.  As shown in
   Figure 3, if there is no MPLS LSP towards the next node segment
   (i.e., the next SFF identified by the current top label), the
   corresponding IP-based tunnel for MPLS (e.g., MPLS-in-IP/GRE tunnel
   [RFC4023], MPLS-in-UDP tunnel [RFC7510] or MPLS-in-L2TPv3 tunnel
   [RFC4817]) would be used.




















Clad, et al.            Expires September 6, 2018              [Page 10]

Internet-Draft    Segment Routing for Service Chaining        March 2018


         +-----------------------------------------------------+
         |                      IP network                     |
         |            +---------+       +---------+            |
         |            |   SF1   |       |   SF2   |            |
         |            +----+----+       +----+----+            |
         |  +---------+    |                 |    +---------+  |
         |  | S(SFF2) |    |                 |    | S(T)    |  |
         |  +---------+    |                 |    +---------+  |
         |  | S(SF2)  |    |                 |    |Inner pkt|  |
         |  +---------+    |                 |    +---------+  |
         |  | S(T)    |    |                 |                 |
         |  +---------+    |               ^ | |               |
         |  |Inner pkt| ^  | |             | | |               |
         |  +---------+ |  | |          (5)| | |(6)            |
         |           (2)|  | |(3)          | | V               |
         |       (1)    |  | V     (4)       |      (7)        |
    +----+-----+ ---> +----+----+ ----> +----+----+ --->  +----+-----+
    | Head-end +------+  SFF1   +-------+  SFF2   +-------+ Tail-end |
    +----------+      +---------+       +---------+       +----+-----+
         |    +---------+      +---------+                     |
         |    |IP Tunnel|      |IP Tunnel|        +---------+  |
         |    |to SFF1  |      | to SFF2 |        | S(T)    |  |
         |    +---------+      +---------+        +---------+  |
         |    | S(SF1)  |      | S(SF2)  |        |Inner pkt|  |
         |    +---------+      +---------+        +---------+  |
         |    | S(SFF2) |      | S(T)    |                     |
         |    +---------+      +---------+                     |
         |    | S(SF2)  |      |Inner pkt|                     |
         |    +---------+      +---------+                     |
         |    | S(T)    |                                      |
         |    +---------+                                      |
         |    |Inner pkt|                                      |
         |    +---------+                                      |
         +-----------------------------------------------------+

                   Figure 3: Packet walk in IP underlay

   Since the transport (i.e., the underlay) could be IPv4, IPv6 or even
   MPLS networks, the above approach of encoding the SFP information by
   an MPLS label stack is fully transport-independent which is one of
   the major requirements for the SFC encapsulation [RFC7665].

5.1.2.  Encoding SFC Information by an MPLS Label Stack

   The head-end, acting as a service classifier, determines that the
   selected packet needs to travel through an SFC (SF1->SF2) and steers
   this packet into the appropriate SR policy as described in
   [I-D.filsfils-spring-segment-routing-policy].  This results in the



Clad, et al.            Expires September 6, 2018              [Page 11]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   packet being encapsulated with an MPLS label stack containing the
   segment list <SF1, SF2, T>, which encodes that SFC.  Those SF labels
   MUST be domain-wide unique MPLS labels.  Since it is known to the
   service classifier that SFF1 is attached with an instance of SF1, the
   service classifier would therefore send the MPLS encapsulated packet
   through either an MPLS LSP tunnel or an IP-based tunnel towards SFF1
   (as shown in Figure 4 and Figure 5 respectively).  When the MPLS
   encapsulated packet arrives at SFF1, SFF1 would know which SF should
   be performed according to the current top label (i.e., S(SF1)).
   Similarly, SFF1 would send the packet returned from SF1 to SFF2
   through either an MPLS LSP tunnel or an IP-based tunnel towards SFF2
   since it's known to SFF1 that SFF2 is attached with an instance of
   SF2.  When the encapsulated packet arrives at SFF2, SFF2 would do the
   similar action as what has been done by SFF1.  Since the transport
   (i.e., the underlay) could be IPv4, IPv6 or even MPLS networks, the
   above approach of encoding the SFC information by an MPLS label stack
   is fully transport-independent which is one of the major requirements
   for the SFC encapsulation [RFC7665].

































Clad, et al.            Expires September 6, 2018              [Page 12]

Internet-Draft    Segment Routing for Service Chaining        March 2018


         +-----------------------------------------------------+
         |                    MPLS Network                     |
         |            +---------+       +---------+            |
         |            |   SF1   |       |   SF2   |            |
         |            +----+----+       +----+----+            |
         |  +---------+    |                 |    +---------+  |
         |  | S(SF2)  |    |                 |    | S(T)    |  |
         |  +---------+    |                 |    +---------+  |
         |  | S(T)    |    |                 |    |Inner pkt|  |
         |  +---------+    |               ^ | |  +---------+  |
         |  |Inner pkt| ^  | |             | | |               |
         |  +---------+ |  | |          (5)| | |(6)            |
         |           (2)|  | |(3)          | | V               |
         |       (1)    |  | V     (4)       |      (7)        |
    +----+-----+ ---> +----+----+ ----> +----+----+ --->  +----+-----+
    | Head-end +------+  SFF1   +-------+  SFF2   +-------+ Tail-end |
    +----------+      +---------+       +---------+       +----+-----+
         |    +---------+      +---------+        +---------+  |
         |    | S(SFF1) |      | S(SFF2) |        | S(T)    |  |
         |    +---------+      +---------+        +---------+  |
         |    | S(SF1)  |      | S(SF2)  |        |Inner pkt|  |
         |    +---------+      +---------+        +---------+  |
         |    | S(SF2)  |      | S(T)    |                     |
         |    +---------+      +---------+                     |
         |    | S(T)    |      |Inner pkt|                     |
         |    +---------+      +---------+                     |
         |    |Inner pkt|                                      |
         |    +---------+                                      |
         +-----------------------------------------------------+

                  Figure 4: Packet walk in MPLS underlay




















Clad, et al.            Expires September 6, 2018              [Page 13]

Internet-Draft    Segment Routing for Service Chaining        March 2018


         +-----------------------------------------------------+
         |                      IP Network                     |
         |            +---------+       +---------+            |
         |            |   SF1   |       |   SF2   |            |
         |            +----+----+       +----+----+            |
         |  +---------+    |                 |    +---------+  |
         |  | S(SF2)  |    |                 |    | S(T)    |  |
         |  +---------+    |                 |    +---------+  |
         |  | S(T)    |    |                 |    |Inner pkt|  |
         |  +---------+    |               ^ | |  +---------+  |
         |  |Inner pkt| ^  | |             | | |               |
         |  +---------+ |  | |          (5)| | |(6)            |
         |           (2)|  | |(3)          | | V               |
         |       (1)    |  | V     (4)       |      (7)        |
    +----+-----+ ---> +----+----+ ----> +----+----+ --->  +----+-----+
    | Head-end +------+  SFF1   +-------+  SFF2   +-------+ Tail-end |
    +----------+      +---------+       +---------+       +----+-----+
         |    +---------+      +---------+                     |
         |    |IP Tunnel|      |IP Tunnel|        +---------+  |
         |    |to SFF1  |      | to SFF2 |        | S(T)    |  |
         |    +---------+      +---------+        +---------+  |
         |    | S(SF1)  |      | S(SF2)  |        |Inner pkt|  |
         |    +---------+      +---------+        +---------+  |
         |    | S(SF2)  |      | S(T)    |                     |
         |    +---------+      +---------+                     |
         |    | S(T)    |      |Inner pkt|                     |
         |    +---------+      +---------+                     |
         |    |Inner pkt|                                      |
         |    +---------+                                      |
         +-----------------------------------------------------+

                   Figure 5: Packet walk in IP underlay

5.2.  SRv6 data plane

5.2.1.  Encoding SFP Information by an SRv6 SRH















Clad, et al.            Expires September 6, 2018              [Page 14]

Internet-Draft    Segment Routing for Service Chaining        March 2018


          +----------------------------------------------------+
          |                    SRv6 network                    |
          |            +---------+       +---------+           |
          |            |   SF1   |       |   SF2   |           |
          |            +----+----+       +----+----+           |
          |              ^  | |(3)          ^ | |(6)           |
          |       (1) (2)|  | V     (4)  (5)| | V    (7)       |
     +----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+
     | Head-end +------+  SFF1   +-------+  SFF2   +------+ Tail-end |
     +----------+      +---------+       +---------+      +----+-----+
          |    +---------+      +---------+      +---------+   |
          |    |IP6 (H,  |      |IP6 (H,  |      |IP6 (H,T)|   |
          |    |    SFF1)|      |    SFF2)|      +---------+   |
          |    +---------+      +---------+      |SRH (T,  |   |
          |    |SRH (T,  |      |SRH (T,  |      |SFF2:SF2,|   |
          |    |SFF2:SF2,|      |SFF2:SF2,|      |SFF1:SF1;|   |
          |    |SFF1:SF1;|      |SFF1:SF1;|      |SL=0)    |   |
          |    |SL=2)    |      |SL=1)    |      +---------+   |
          |    +---------+      +---------+      |Inner pkt|   |
          |    |Inner pkt|      |Inner pkt|      +---------+   |
          |    +---------+      +---------+                    |
          +----------------------------------------------------+

                   Figure 6: Packet walk in SRv6 network

   As shown in Figure 6, the head-end, acting as a service classifier,
   determines that the selected packet needs to travel through an SFC
   (SF1->SF2) and steers this packet into the appropriate SR policy as
   described in [I-D.filsfils-spring-segment-routing-policy].  As a
   result, the packet is encapsulated with an IPv6 header and an SRH
   containing the segment list <SFF1:SF1, SFF2:SF2, T>.  The
   intermediate segments in this list leverage the SRv6 locator-function
   concept introduced in [I-D.filsfils-spring-srv6-network-programming]
   to encode both the SFF and the SF in a single IPv6 SID.  The traffic
   is steered via regular IPv6 forwarding up to the SFF represented in
   the locator part of the SID and then passed to the SF identified by
   the SID function.  This SRH thus indicates in a stateless manner the
   SFP corresponding to the above SFC.  To some extent, the SRH here
   could be looked as a specific implementation of the SFC encapsulation
   used for containing the SFP information [RFC7665], which does not
   require the SFF to maintain per-chain state.

   When the encapsulated packet arrives at SFF1, SFF1 knows how to send
   the packet to the SF based on the active segment.  We first consider
   the case where SF1 is an SR-aware SF, i.e., it understands how to
   process an IPv6 encapsulated packet with an SRH.  In this case the
   packet is sent to SF1 by SFF1 with the IP and SR headers
   (H,SFF2:SF2)(T,SFF2:SF2,SFF1:SF1;SL=1).  SF1 performs the required



Clad, et al.            Expires September 6, 2018              [Page 15]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   service function on the received packet, where the payload is
   determined based on the Next Header field value of last extension
   header and/or the active segment.  After the packet is returned from
   SF1, SFF1 simply forwards it to SFF2 according to the IPv6
   destination address.

   If SF1 is an SR-unaware SF, i.e. one that is unable to process IPv6
   encapsulated packets with an SRH, the encapsulation headers (i.e.,
   outer IPv6 with any extension header) MUST be stripped from the
   packet before it is sent to SF1.  When the packet is returned from
   SF1, SFF1 would re-encapsulate the packet with the IPv6 and SR
   headers that had been previously stripped and then send the packet to
   SFF2 according to the IPv6 destination address.  Proxy mechanisms to
   support SR-unaware SFs are proposed in section 6 of this document.

   When the encapsulated packet arrives at SFF2, SFF2 would perform the
   similar action to that described above.

5.2.2.  Encoding SFC Information by an IPv6 SRH

   The head-end, acting as a service classifier, determines that the
   selected packet needs to travel through an SFC (SF1->SF2) and steers
   this packet into the appropriate SR policy.  This results in the
   packet being encapsulated with an IPv6 header and an SRH containing
   the segment list <A1:SF1, A2:SF2, T>.  In this case, the locator
   parts A1 and A2 of the intermediate service segments are anycast
   prefixes advertised by several SFFs attached to SF1 and SF2,
   respectively.  The policy head-end may thus let the traffic be
   steered to the closest instance of each SF or add intermediate
   segments to select a particular SF instance.  Furthermore, since it
   is known to the head-end that SFF1 is attached to an instance of SF1,
   the encapsulated packet may be sent to SFF1 through an MPLS LSP or an
   IP-based tunnel.  Similar tunneling can then be performed between
   SFF1 and SFF1, and between SFF2 and the tail-end, as illustrated on
   Figure 7.  Since the transport (i.e., the underlay) could be IPv4,
   IPv6 or even MPLS, the above approach of encoding the SFC information
   by an IPv6 SRH is fully transport-independent which is one of the
   major requirements for the SFC encapsulation [RFC7665].













Clad, et al.            Expires September 6, 2018              [Page 16]

Internet-Draft    Segment Routing for Service Chaining        March 2018


          +----------------------------------------------------+
          |                   Underlay network                 |
          |            +---------+       +---------+           |
          |            |   SF1   |       |   SF2   |           |
          |            +----+----+       +----+----+           |
          |              ^  | |(3)          ^ | |(6)           |
          |       (1) (2)|  | V     (4)  (5)| | V    (7)       |
     +----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+
     | Head-end +------+  SFF1   +-------+  SFF2   +------+ Tail-end |
     +----------+      +---------+       +---------+      +----+-----+
          |    +---------+      +---------+      +---------+   |
          |    |Tunnel to|      |Tunnel to|      |Tunnel to|   |
          |    |SFF1     |      |SFF2     |      |T        |   |
          |    +---------+      +---------+      +---------+   |
          |    |IP6 (H,  |      |IP6 (H,  |      |IP6 (H,T)|   |
          |    |     SF1)|      |    SFF2)|      +---------+   |
          |    +---------+      +---------+      |SRH (T,  |   |
          |    |SRH (T,  |      |SRH (T,  |      |SF2, SF1;|   |
          |    |SF2, SF1;|      |SF2, SF1;|      |SL=0)    |   |
          |    |SL=2)    |      |SL=1)    |      +---------+   |
          |    +---------+      +---------+      |Inner pkt|   |
          |    |Inner pkt|      |Inner pkt|      +---------+   |
          |    +---------+      +---------+                    |
          +----------------------------------------------------+

                 Figure 7: Packet walk in underlay network

6.  SR proxy behaviors

   This section describes several SR proxy behaviors designed to enable
   SR SFC through SR-unaware SFs.  A system implementing one of these
   functions may handle the SR processing on behalf of an SR-unaware SF
   and allows the SF to properly process the traffic that is steered
   through it.

   An SF may be located at any hop in an SR policy, including the last
   segment.  However, the SR proxy behaviors defined in this section are
   dedicated to supporting SR-unaware SFs at intermediate hops in the
   segment list.  In case an SR-unaware SF is at the last segment, it is
   sufficient to ensure that the SR information is ignored (IPv6 routing
   extension header with Segments Left equal to 0) or removed before the
   packet reaches the SF (MPLS PHP, SRv6 End.D or PSP).

   As illustrated on Figure 8, the generic behavior of an SR proxy has
   two parts.  The first part is in charge of passing traffic from the
   network to the SF.  It intercepts the SR traffic destined for the SF
   via a locally instantiated service segment, modifies it in such a way
   that it appears as non-SR traffic to the SF, then sends it out on a



Clad, et al.            Expires September 6, 2018              [Page 17]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   given interface, IFACE-OUT, connected to the SF.  The second part
   receives the traffic coming back from the SF on IFACE-IN, restores
   the SR information and forwards it according to the next segment in
   the list.  IFACE-OUT and IFACE-IN are respectively the proxy
   interface used for sending traffic to the SF and the proxy interface
   that receives the traffic coming back from the SF.  These can be
   physical interfaces or sub-interfaces (VLANs) and, unless otherwise
   stated, IFACE-OUT and IFACE-IN can represent the same interface.

                      +----------------------------+
                      |                            |
                      |      Service Function      |
                      |                            |
                      +----------------------------+
                               ^  Non SR   |
                               |  traffic  |
                               |           v
                         +-----------+----------+
                      +--| IFACE OUT | IFACE IN |--+
           SR traffic |  +-----------+----------+  | SR traffic
           ---------->|          SR proxy          |---------->
                      |                            |
                      +----------------------------+

                        Figure 8: Generic SR proxy

   In the next subsections, the following SR proxy mechanisms are
   defined:

   o  Static proxy

   o  Dynamic proxy

   o  Shared-memory proxy

   o  Masquerading proxy

   Each mechanism has its own characteristics and constraints, which are
   summarized in the below table.  It is up to the operator to select
   the best one based on the proxy node capabilities, the SF behavior
   and the traffic type.  It is also possible to use different proxy
   mechanisms within the same service chain.









Clad, et al.            Expires September 6, 2018              [Page 18]

Internet-Draft    Segment Routing for Service Chaining        March 2018


                                             +-----+-----+-----+-----+
                                             |     |     |     |  M  |
                                             |     |     |  S  |  a  |
                                             |     |     |  h  |  s  |
                                             |     |     |  a  |  q  |
                                             |     |     |  r  |  u  |
                                             |     |  D  |  e  |  e  |
                                             |  S  |  y  |  d  |  r  |
                                             |  t  |  n  |     |  a  |
                                             |  a  |  a  |  m  |  d  |
                                             |  t  |  m  |  e  |  i  |
                                             |  i  |  i  |  m  |  n  |
                                             |  c  |  c  |  .  |  g  |
     +---------------------------------------+-----+-----+-----+-----+
     |                |       SR-MPLS        |  Y  |  Y  |  Y  |  -  |
     |                |                      |     |     |     |     |
     |   SR flavors   |    SRv6 insertion    |  P  |  P  |  P  |  Y  |
     |                |                      |     |     |     |     |
     |                |  SRv6 encapsulation  |  Y  |  Y  |  Y  |  -  |
     +----------------+----------------------+-----+-----+-----+-----+
     |                |       Ethernet       |  Y  |  Y  |  Y  |  -  |
     |                |                      |     |     |     |     |
     |  Inner header  |         IPv4         |  Y  |  Y  |  Y  |  -  |
     |                |                      |     |     |     |     |
     |                |         IPv6         |  Y  |  Y  |  Y  |  -  |
     +----------------+----------------------+-----+-----+-----+-----+
     |     Chain agnostic configuration      |  N  |  N  |  Y  |  Y  |
     +---------------------------------------+-----+-----+-----+-----+
     |     Transparent to chain changes      |  N  |  Y  |  Y  |  Y  |
     +----------------+----------------------+-----+-----+-----+-----+
     |                |   DA modification    |  Y  |  Y  |  Y  | NAT |
     |                |                      |     |     |     |     |
     |                | Payload modification |  Y  |  Y  |  Y  |  Y  |
     |                |                      |     |     |     |     |
     |   SF support   |  Packet generation   |  Y  |  Y  |cache|cache|
     |                |                      |     |     |     |     |
     |                |   Packet deletion    |  Y  |  Y  |  Y  |  Y  |
     |                |                      |     |     |     |     |
     |                |  Transport endpoint  |  Y  |  Y  |cache|cache|
     +----------------+----------------------+-----+-----+-----+-----+

                        Figure 9: SR proxy summary

   Note: The use of a shared memory proxy requires both the SF and the
   proxy to be running on the same node.






Clad, et al.            Expires September 6, 2018              [Page 19]

Internet-Draft    Segment Routing for Service Chaining        March 2018


6.1.  Static SR proxy

   The static proxy is an SR endpoint behavior for processing SR-MPLS or
   SRv6 encapsulated traffic on behalf of an SR-unaware SF.  This proxy
   thus receives SR traffic that is formed of an MPLS label stack or an
   IPv6 header on top of an inner packet, which can be Ethernet, IPv4 or
   IPv6.

   A static SR proxy segment is associated with the following mandatory
   parameters:

   o  INNER-TYPE: Inner packet type

   o  S-ADDR: Ethernet or IP address of the SF (only for inner type IPv4
      and IPv6)

   o  IFACE-OUT: Local interface for sending traffic towards the SF

   o  IFACE-IN: Local interface receiving the traffic coming back from
      the SF

   o  CACHE: SR information to be attached on the traffic coming back
      from the SF, including at least

      *  CACHE.SA: IPv6 source address (SRv6 only)

      *  CACHE.LIST: Segment list expressed as MPLS labels or IPv6
         address

   A static SR proxy segment is thus defined for a specific SF, inner
   packet type and cached SR information.  It is also bound to a pair of
   directed interfaces on the proxy.  These may be both directions of a
   single interface, or opposite directions of two different interfaces.
   The latter is recommended in case the SF is to be used as part of a
   bi-directional SR SC policy.  If the proxy and the SF both support
   802.1Q, IFACE-OUT and IFACE-IN can also represent sub-interfaces.

   The first part of this behavior is triggered when the proxy node
   receives a packet whose active segment matches a segment associated
   with the static proxy behavior.  It removes the SR information from
   the packet then sends it on a specific interface towards the
   associated SF.  This SR information corresponds to the full label
   stack for SR-MPLS or to the encapsulation IPv6 header with any
   attached extension header in the case of SRv6.

   The second part is an inbound policy attached to the proxy interface
   receiving the traffic returning from the SF, IFACE-IN.  This policy
   attaches to the incoming traffic the cached SR information associated



Clad, et al.            Expires September 6, 2018              [Page 20]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   with the SR proxy segment.  If the proxy segment uses the SR-MPLS
   data plane, CACHE contains a stack of labels to be pushed on top the
   packets.  With the SRv6 data plane, CACHE is defined as a source
   address, an active segment and an optional SRH (tag, segments left,
   segment list and metadata).  The proxy encapsulates the packets with
   an IPv6 header that has the source address, the active segment as
   destination address and the SRH as a routing extension header.  After
   the SR information has been attached, the packets are forwarded
   according to the active segment, which is represented by the top MPLS
   label or the IPv6 Destination Address.

   In this scenario, there are no restrictions on the operations that
   can be performed by the SF on the stream of packets.  It may operate
   at all protocol layers, terminate transport layer connections,
   generate new packets and initiate transport layer connections.  This
   behavior may also be used to integrate an IPv4-only SF into an SRv6
   policy.  However, a static SR proxy segment can be used in only one
   service chain at a time.  As opposed to most other segment types, a
   static SR proxy segment is bound to a unique list of segments, which
   represents a directed SR SC policy.  This is due to the cached SR
   information being defined in the segment configuration.  This
   limitation only prevents multiple segment lists from using the same
   static SR proxy segment at the same time, but a single segment list
   can be shared by any number of traffic flows.  Besides, since the
   returning traffic from the SF is re-classified based on the incoming
   interface, an interface can be used as receiving interface (IFACE-IN)
   only for a single SR proxy segment at a time.  In the case of a bi-
   directional SR SC policy, a different SR proxy segment and receiving
   interface are required for the return direction.

6.1.1.  SR-MPLS pseudocode

6.1.1.1.  Static proxy for inner type Ethernet

   Upon receiving an MPLS packet with top label L, where L is an MPLS L2
   static proxy segment, a node N does:

   1.   IF payload type is Ethernet THEN
   2.       Pop all labels
   3.       Forward the exposed frame on IFACE-OUT
   4.   ELSE
   5.       Drop the packet

   Upon receiving on IFACE-IN an Ethernet frame with a destination
   address different than the interface address, a node N does:

   1.   Push labels in CACHE on top of the frame Ethernet header
   2.   Lookup the top label and proceed accordingly



Clad, et al.            Expires September 6, 2018              [Page 21]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   The receiving interface must be configured in promiscuous mode in
   order to accept those Ethernet frames.

6.1.1.2.  Static proxy for inner type IPv4

   Upon receiving an MPLS packet with top label L, where L is an MPLS
   IPv4 static proxy segment, a node N does:

   1.   IF payload type is IPv4 THEN
   2.       Pop all labels
   3.       Forward the exposed packet on IFACE-OUT towards S-ADDR
   4.   ELSE
   5.       Drop the packet

   Upon receiving a non link-local IPv4 packet on IFACE-IN, a node N
   does:

   1.   Decrement TTL and update checksum
   2.   Push labels in CACHE on top of the packet IPv4 header
   3.   Lookup the top label and proceed accordingly

6.1.1.3.  Static proxy for inner type IPv6

   Upon receiving an MPLS packet with top label L, where L is an MPLS
   IPv6 static proxy segment, a node N does:

   1.   IF payload type is IPv6 THEN
   2.       Pop all labels
   3.       Forward the exposed packet on IFACE-OUT towards S-ADDR
   4.   ELSE
   5.       Drop the packet

   Upon receiving a non link-local IPv6 packet on IFACE-IN, a node N
   does:

   1.   Decrement Hop Limit
   2.   Push labels in CACHE on top of the packet IPv6 header
   3.   Lookup the top label and proceed accordingly

6.1.2.  SRv6 pseudocode

6.1.2.1.  Static proxy for inner type Ethernet

   Upon receiving an IPv6 packet destined for S, where S is an IPv6
   static proxy segment for Ethernet traffic, a node N does:






Clad, et al.            Expires September 6, 2018              [Page 22]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   1.   IF ENH == 59 THEN                                        ;; Ref1
   2.       Remove the (outer) IPv6 header and its extension headers
   3.       Forward the exposed frame on IFACE-OUT
   4.   ELSE
   5.       Drop the packet

   Ref1: 59 refers to "no next header" as defined by IANA allocation for
   Internet Protocol Numbers.

   Upon receiving on IFACE-IN an Ethernet frame with a destination
   address different than the interface address, a node N does:

   1.   Retrieve CACHE entry matching IFACE-IN and traffic type
   2.   Push SRH with CACHE.LIST on top of the Ethernet header   ;; Ref2
   3.   Push IPv6 header with
          SA = CACHE.SA
          DA = CACHE.LIST[0]                                     ;; Ref3
          Next Header = 43                                       ;; Ref4
   4.   Set outer payload length and flow label
   5.   Lookup outer DA in appropriate table and proceed accordingly

   Ref2: Unless otherwise specified, the segments in CACHE.LIST should
   be encoded in reversed order, Segment Left and Last Entry values
   should be set of the length of CACHE.LIST minus 1, and Next Header
   should be set to 59.

   Ref3: CACHE.LIST[0] represents the first IPv6 SID in CACHE.LIST.

   Ref4: If CACHE.LIST contains a single entry, the SRH can be omitted
   and the Next Header value must be set to 59.

   The receiving interface must be configured in promiscuous mode in
   order to accept those Ethernet frames.

6.1.2.2.  Static proxy for inner type IPv4

   Upon receiving an IPv6 packet destined for S, where S is an IPv6
   static proxy segment for IPv4 traffic, a node N does:

   1.   IF ENH == 4 THEN                                         ;; Ref1
   2.       Remove the (outer) IPv6 header and its extension headers
   3.       Forward the exposed packet on IFACE-OUT towards S-ADDR
   4.   ELSE
   5.       Drop the packet

   Ref1: 4 refers to IPv4 encapsulation as defined by IANA allocation
   for Internet Protocol Numbers.




Clad, et al.            Expires September 6, 2018              [Page 23]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   Upon receiving a non link-local IPv4 packet on IFACE-IN, a node N
   does:

   1.   Decrement TTL and update checksum
   2.   IF CACHE.SRH THEN                                        ;; Ref2
   3.       Push CACHE.SRH on top of the existing IPv4 header
   4.       Set NH value of the pushed SRH to 4
   5.   Push outer IPv6 header with SA, DA and traffic class from CACHE
   6.   Set outer payload length and flow label
   7.   Set NH value to 43 if an SRH was added, or 4 otherwise
   8.   Lookup outer DA in appropriate table and proceed accordingly

   Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the
   static SR proxy segment associated with IFACE-IN.

6.1.2.3.  Static proxy for inner type IPv6

   Upon receiving an IPv6 packet destined for S, where S is an IPv6
   static proxy segment for IPv6 traffic, a node N does:

   1.   IF ENH == 41 THEN                                        ;; Ref1
   2.       Remove the (outer) IPv6 header and its extension headers
   3.       Forward the exposed packet on IFACE-OUT towards S-ADDR
   4.   ELSE
   5.       Drop the packet

   Ref1: 41 refers to IPv6 encapsulation as defined by IANA allocation
   for Internet Protocol Numbers.

   Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N
   does:

   1.   Decrement Hop Limit
   2.   IF CACHE.SRH THEN                                        ;; Ref2
   3.       Push CACHE.SRH on top of the existing IPv6 header
   4.       Set NH value of the pushed SRH to 41
   5.   Push outer IPv6 header with SA, DA and traffic class from CACHE
   6.   Set outer payload length and flow label
   7.   Set NH value to 43 if an SRH was added, or 41 otherwise
   8.   Lookup outer DA in appropriate table and proceed accordingly

   Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the
   static SR proxy segment associated with IFACE-IN.








Clad, et al.            Expires September 6, 2018              [Page 24]

Internet-Draft    Segment Routing for Service Chaining        March 2018


6.2.  Dynamic SR proxy

   The dynamic proxy is an improvement over the static proxy that
   dynamically learns the SR information before removing it from the
   incoming traffic.  The same information can then be re-attached to
   the traffic returning from the SF.  As opposed to the static SR
   proxy, no CACHE information needs to be configured.  Instead, the
   dynamic SR proxy relies on a local caching mechanism on the node
   instantiating this segment.  Therefore, a dynamic proxy segment
   cannot be the last segment in an SR SC policy.  As mentioned at the
   beginning of Section 6, a different SR behavior should be used if the
   SF is meant to be the final destination of an SR SC policy.

   Upon receiving a packet whose active segment matches a dynamic SR
   proxy function, the proxy node pops the top MPLS label or applies the
   SRv6 End behavior, then compares the updated SR information with the
   cache entry for the current segment.  If the cache is empty or
   different, it is updated with the new SR information.  The SR
   information is then removed and the inner packet is sent towards the
   SF.

   The cache entry is not mapped to any particular packet, but instead
   to an SR SC policy identified by the receiving interface (IFACE-IN).
   Any non-link-local IP packet or non-local Ethernet frame received on
   that interface will be re-encapsulated with the cached headers as
   described in Section 6.1.  The SF may thus drop, modify or generate
   new packets without affecting the proxy.

6.2.1.  SR-MPLS pseudocode

   The dynamic proxy SR-MPLS pseudocode is obtained by inserting the
   following instructions between lines 1 and 2 of the static SR-MPLS
   pseudocode.

   1.   IF top label S bit is 0 THEN
   2.       Pop top label
   3.       IF C(IFACE-IN) different from remaining labels THEN  ;; Ref1
   4.           Copy all remaining labels into C(IFACE-IN)       ;; Ref2
   5.   ELSE
   6.       Drop the packet

   Ref1: A TTL margin can be configured for the top label stack entry to
   prevent constant cache updates when multiple equal-cost paths with
   different hop counts are used towards the SR proxy node.  In that
   case, a TTL difference smaller than the configured margin should not
   trigger a cache update (provided that the labels are the same).





Clad, et al.            Expires September 6, 2018              [Page 25]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   Ref2: C(IFACE-IN) represents the cache entry associated to the
   dynamic SR proxy segment.  It is identified with IFACE-IN in order to
   efficiently retrieve the right SR information when a packet arrives
   on this interface.

   In addition, the inbound policy should check that C(IFACE-IN) has
   been defined before attempting to restore the MPLS label stack, and
   drop the packet otherwise.

6.2.2.  SRv6 pseudocode

   The dynamic proxy SRv6 pseudocode is obtained by inserting the
   following instructions between lines 1 and 2 of the static proxy SRv6
   pseudocode.

   1.   IF NH=SRH & SL > 0 THEN
   2.       Decrement SL and update the IPv6 DA with SRH[SL]
   3.       IF C(IFACE-IN) different from IPv6 encaps THEN       ;; Ref1
   4.           Copy the IPv6 encaps into C(IFACE-IN)            ;; Ref2
   5.   ELSE
   6.       Drop the packet

   Ref1: "IPv6 encaps" represents the IPv6 header and any attached
   extension header.

   Ref2: C(IFACE-IN) represents the cache entry associated to the
   dynamic SR proxy segment.  It is identified with IFACE-IN in order to
   efficiently retrieve the right SR information when a packet arrives
   on this interface.

   In addition, the inbound policy should check that C(IFACE-IN) has
   been defined before attempting to restore the IPv6 encapsulation, and
   drop the packet otherwise.

6.3.  Shared memory SR proxy

   The shared memory proxy is an SR endpoint behavior for processing SR-
   MPLS or SRv6 encapsulated traffic on behalf of an SR-unaware SF.
   This proxy behavior leverages a shared-memory interface with the SF
   in order to hide the SR information from an SR-unaware SF while
   keeping it attached to the packet.  We assume in this case that the
   proxy and the SF are running on the same compute node.  A typical
   scenario is an SR-capable vrouter running on a container host and
   forwarding traffic to virtual SFs isolated within their respective
   container.

   More details will be added in a future revision of this document.




Clad, et al.            Expires September 6, 2018              [Page 26]

Internet-Draft    Segment Routing for Service Chaining        March 2018


6.4.  Masquerading SR proxy

   The masquerading proxy is an SR endpoint behavior for processing SRv6
   traffic on behalf of an SR-unaware SF.  This proxy thus receives SR
   traffic that is formed of an IPv6 header and an SRH on top of an
   inner payload.  The masquerading behavior is independent from the
   inner payload type.  Hence, the inner payload can be of any type but
   it is usually expected to be a transport layer packet, such as TCP or
   UDP.

   A masquerading SR proxy segment is associated with the following
   mandatory parameters:

   o  S-ADDR: Ethernet or IPv6 address of the SF

   o  IFACE-OUT: Local interface for sending traffic towards the SF

   o  IFACE-IN: Local interface receiving the traffic coming back from
      the SF

   A masquerading SR proxy segment is thus defined for a specific SF and
   bound to a pair of directed interfaces or sub-interfaces on the
   proxy.  As opposed to the static and dynamic SR proxies, a
   masquerading segment can be present at the same time in any number of
   SR SC policies and the same interfaces can be bound to multiple
   masquerading proxy segments.  The only restriction is that a
   masquerading proxy segment cannot be the last segment in an SR SC
   policy.

   The first part of the masquerading behavior is triggered when the
   proxy node receives an IPv6 packet whose Destination Address matches
   a masquerading proxy segment.  The proxy inspects the IPv6 extension
   headers and substitutes the Destination Address with the last segment
   in the SRH attached to the IPv6 header, which represents the final
   destination of the IPv6 packet.  The packet is then sent out towards
   the SF.

   The SF receives an IPv6 packet whose source and destination addresses
   are respectively the original source and final destination.  It does
   not attempt to inspect the SRH, as RFC8200 specifies that routing
   extension headers are not examined or processed by transit nodes.
   Instead, the SF simply forwards the packet based on its current
   Destination Address.  In this scenario, we assume that the SF can
   only inspect, drop or perform limited changes to the packets.  For
   example, Intrusion Detection Systems, Deep Packet Inspectors and non-
   NAT Firewalls are among the SFs that can be supported by a
   masquerading SR proxy.  Variants of the masquerading behavior are




Clad, et al.            Expires September 6, 2018              [Page 27]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   defined in Section 6.4.2 and Section 6.4.3 to support a wider range
   of SFs.

   The second part of the masquerading behavior, also called de-
   masquerading, is an inbound policy attached to the proxy interface
   receiving the traffic returning from the SF, IFACE-IN.  This policy
   inspects the incoming traffic and triggers a regular SRv6 endpoint
   processing (End) on any IPv6 packet that contains an SRH.  This
   processing occurs before any lookup on the packet Destination Address
   is performed and it is sufficient to restore the right active segment
   as the Destination Address of the IPv6 packet.

6.4.1.  SRv6 masquerading proxy pseudocode

   Masquerading: Upon receiving a packet destined for S, where S is an
   IPv6 masquerading proxy segment, a node N processes it as follows.

   1.   IF NH=SRH & SL > 0 THEN
   2.       Update the IPv6 DA with SRH[0]
   3.       Forward the packet on IFACE-OUT
   4.   ELSE
   5.       Drop the packet

   De-masquerading: Upon receiving a non-link-local IPv6 packet on
   IFACE-IN, a node N processes it as follows.

   1.   IF NH=SRH & SL > 0 THEN
   2.       Decrement SL
   3.       Update the IPv6 DA with SRH[SL]                      ;; Ref1
   4.       Lookup DA in appropriate table and proceed accordingly

   Ref2: This pseudocode can be augmented to support the Penultimate
   Segment Popping (PSP) endpoint flavor.  The exact pseudocode
   modification are provided in
   [I-D.filsfils-spring-srv6-network-programming].

6.4.2.  Variant 1: Destination NAT

   SFs modifying the destination address in the packets they process,
   such as NATs, can be supported by a masquerading proxy with the
   following modification to the de-masquerading pseudocode.

   De-masquerading - NAT: Upon receiving a non-link-local IPv6 packet on
   IFACE-IN, a node N processes it as follows.







Clad, et al.            Expires September 6, 2018              [Page 28]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   1.   IF NH=SRH & SL > 0 THEN
   2.       Update SRH[0] with the IPv6 DA
   3.       Decrement SL
   4.       Update the IPv6 DA with SRH[SL]
   5.       Lookup DA in appropriate table and proceed accordingly

6.4.3.  Variant 2: Caching

   SFs generating packets or acting as endpoints for transport
   connections can be supported by adding a dynamic caching mechanism
   similar to the one described in Section 6.2.

   More details will be added in a future revision of this document.

7.  Metadata

7.1.  MPLS data plane

   Since the MPLS encapsulation has no explicit protocol identifier
   field to indicate the protocol type of the MPLS payload, how to
   indicate the presence of metadata (i.e., the NSH which is only used
   as a metadata containner) in an MPLS packet is a potential issue to
   be addressed.  One possible way to address the above issue is: SFFs
   allocate two different labels for a given SF, one indicates the
   presence of NSH while the other indicates the absence of NSH.  This
   approach has no change to the current MPLS architecture but it would
   require more than one label binding for a given SF.  Another possible
   way is to introduce a protocol identifier field within the MPLS
   packet as described in [I-D.xu-mpls-payload-protocol-identifier].

   More details about how to contain metadata within an MPLS packet
   would be considered in the future version of this draft.

7.2.  IPv6 data plane

7.2.1.  SRH TLV objects

   The IPv6 SRH TLV objects are designed to carry all sorts of metadata.
   In particular, [I-D.ietf-6man-segment-routing-header] defines the NSH
   carrier TLV as a container for NSH metadata.

   TLV objects can be imposed by the ingress edge router that steers the
   traffic into the SR SC policy.

   An SR-aware SF may impose, modify or remove any TLV object attached
   to the first SRH, either by directly modifying the packet headers or
   via a control channel between the SF and its forwarding plane.




Clad, et al.            Expires September 6, 2018              [Page 29]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   An SR-aware SF that re-classifies the traffic and steers it into a
   new SR SC policy (e.g.  DPI) may attach any TLV object to the new
   SRH.

   Metadata imposition and handling will be further discussed in a
   future version of this document.

7.2.2.  SRH tag

   The SRH tag identifies a packet as part of a group or class of
   packets [I-D.ietf-6man-segment-routing-header].

   In an SFC context, this field can be used to encode basic metadata in
   the SRH.

8.  Implementation status

   The static SR proxy is available for SR-MPLS and SRv6 on various
   Cisco hardware and software platforms.  Furthermore, the following
   proxies are available on open-source software.

                                           +-------------+-------------+
                                           |     VPP     |    Linux    |
   +---+-----------------------------------+-------------+-------------+
   | M |           Static proxy            |  Available  | In progress |
   | P |                                   |             |             |
   | L |           Dynamic proxy           | In progress | In progress |
   | S |                                   |             |             |
   |   |        Shared memory proxy        | In progress | In progress |
   +---+-----------------------------------+-------------+-------------+
   |   |           Static proxy            |  Available  | In progress |
   |   |                                   |             |             |
   |   |Dynamic proxy - Inner type Ethernet| In progress | In progress |
   |   |                                   |             |             |
   |   |  Dynamic proxy - Inner type IPv4  |  Available  |  Available  |
   | S |                                   |             |             |
   | R |  Dynamic proxy - Inner type IPv6  |  Available  |  Available  |
   | v |                                   |             |             |
   | 6 |        Shared memory proxy        | In progress | In progress |
   |   |                                   |             |             |
   |   |        Masquerading proxy         |  Available  |  Available  |
   |   |                                   |             |             |
   |   | Masquerading proxy - NAT variant  | In progress | In progress |
   |   |                                   |             |             |
   |   |Masquerading proxy - Cache variant | In progress | In progress |
   +---+-----------------------------------+-------------+-------------+

                  Open-source implementation status table



Clad, et al.            Expires September 6, 2018              [Page 30]

Internet-Draft    Segment Routing for Service Chaining        March 2018


9.  Related works

   The Segment Routing solution addresses a wide problem that covers
   both topological and service chaining policies.  The topological and
   service instructions can be either deployed in isolation or in
   combination.  SR has thus a wider applicability than the architecture
   defined in [RFC7665].  Furthermore, the inherent property of SR is a
   stateless network fabric.  In SR, there is no state within the fabric
   to recognize a flow and associate it with a policy.  State is only
   present at the ingress edge of the SR domain, where the policy is
   encoded into the packets.  This is completely different from other
   proposals such as [RFC8300] and the MPLS label swapping mechanism
   described in [I-D.farrel-mpls-sfc], which rely on state configured at
   every hop of the service chain.

10.  IANA Considerations

   This I-D requests the IANA to allocate, within the "SRv6 Endpoint
   Types" sub-registry belonging to the top-level "Segment-routing with
   IPv6 dataplane (SRv6) Parameters" registry, the following
   allocations:

   +-------------+-----+-----------------------------------+-----------+
   | Value/Range | Hex |         Endpoint function         | Reference |
   +-------------+-----+-----------------------------------+-----------+
   | TBA         | TBA |     End.AN - SR-aware function    | [This.ID] |
   |             |     |              (native)             |           |
   | TBA         | TBA |       End.AS - Static proxy       | [This.ID] |
   | TBA         | TBA |       End.AD - Dynamic proxy      | [This.ID] |
   | TBA         | TBA |    End.AM - Masquerading proxy    | [This.ID] |
   +-------------+-----+-----------------------------------+-----------+

                     Table 1: SRv6 SFC Endpoint Types

11.  Security Considerations

   The security requirements and mechanisms described in
   [I-D.ietf-spring-segment-routing] and
   [I-D.ietf-6man-segment-routing-header] also apply to this document.

   Furthermore, it is fundamental to the SFC design that the classifier
   is a trusted resource which determines the processing that the packet
   will be subject to, including for example the firewall.  Where an SF
   is not SR-aware the packet may exist as an IP packet, however this is
   an intrinsic part of the SFC design which needs to define how a
   packet is protected in that environment.  Where a tunnel is used to
   link two non-MPLS domains, the tunnel design needs to specify how it
   is secured.



Clad, et al.            Expires September 6, 2018              [Page 31]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   Thus the security vulnerabilities are addressed in the underlying
   technologies used by this design, which itself does not introduce any
   new security vulnerabilities.

12.  Acknowledgements

   The authors would like to thank Loa Andersson, Andrew G.  Malis,
   Adrian Farrel, Alexander Vainshtein and Joel M.  Halpern for their
   valuable comments and suggestions on the document.

13.  Contributors

   P.  Camarillo (Cisco), B.  Peirens (Proximus), D.  Steinberg
   (Steinberg Consulting), A.  AbdelSalam (Gran Sasso Science
   Institute), G.  Dawra (Cisco), S.  Bryant (Huawei), H.  Assarpour
   (Broadcom), H.  Shah (Ciena), L.  Contreras (Telefonica I+D), J.
   Tantsura (Individual), M.  Vigoureux (Nokia) and J.  Bhattacharya
   (Cisco) substantially contributed to the content of this document.

14.  References

14.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,
              <https://www.rfc-editor.org/info/rfc2119>.

14.2.  Informative References

   [I-D.dawra-idr-bgp-sr-service-chaining]
              Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d.,
              Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F.,
              and K. Talaulikar, "BGP Control Plane Extensions for
              Segment Routing based Service Chaining", draft-dawra-idr-
              bgp-sr-service-chaining-02 (work in progress), January
              2018.

   [I-D.farrel-mpls-sfc]
              Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
              Forwarding Plane for Service Function Chaining", draft-
              farrel-mpls-sfc-04 (work in progress), March 2018.









Clad, et al.            Expires September 6, 2018              [Page 32]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   [I-D.filsfils-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad,
              F., Talaulikar, K., Ali, Z., Hegde, S.,
              daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
              b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
              Litkowski, S., and P. Mattes, "Segment Routing Policy for
              Traffic Engineering", draft-filsfils-spring-segment-
              routing-policy-05 (work in progress), February 2018.

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
              Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
              Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
              Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
              Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
              Camarillo, "SRv6 Network Programming", draft-filsfils-
              spring-srv6-network-programming-03 (work in progress),
              December 2017.

   [I-D.ietf-6man-segment-routing-header]
              Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
              Field, B., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
              Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
              D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
              Header (SRH)", draft-ietf-6man-segment-routing-header-08
              (work in progress), January 2018.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

   [I-D.ietf-spring-segment-routing-mpls]
              Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing with MPLS
              data plane", draft-ietf-spring-segment-routing-mpls-12
              (work in progress), February 2018.

   [I-D.xu-mpls-payload-protocol-identifier]
              Xu, X., Assarpour, H., and S. Ma, "MPLS Payload Protocol
              Identifier", draft-xu-mpls-payload-protocol-identifier-04
              (work in progress), January 2018.






Clad, et al.            Expires September 6, 2018              [Page 33]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   [I-D.xu-mpls-sr-over-ip]
              Xu, X., Bryant, S., Farrel, A., Bashandy, A., Henderickx,
              W., and Z. Li, "SR-MPLS over IP", draft-xu-mpls-sr-over-
              ip-00 (work in progress), February 2018.

   [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, Ed.,
              "Encapsulating MPLS in IP or Generic Routing Encapsulation
              (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
              <https://www.rfc-editor.org/info/rfc4023>.

   [RFC4817]  Townsley, M., Pignataro, C., Wainner, S., Seely, T., and
              J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
              Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March
              2007, <https://www.rfc-editor.org/info/rfc4817>.

   [RFC7510]  Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
              "Encapsulating MPLS in UDP", RFC 7510,
              DOI 10.17487/RFC7510, April 2015,
              <https://www.rfc-editor.org/info/rfc7510>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

Authors' Addresses

   Francois Clad (editor)
   Cisco Systems, Inc.
   France

   Email: fclad@cisco.com


   Xiaohu Xu (editor)
   Alibaba

   Email: xiaohu.xxh@alibaba-inc.com








Clad, et al.            Expires September 6, 2018              [Page 34]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   Clarence Filsfils
   Cisco Systems, Inc.
   Belgium

   Email: cf@cisco.com


   Daniel Bernier
   Bell Canada
   Canada

   Email: daniel.bernier@bell.ca


   Cheng Li
   Huawei

   Email: chengli13@huawei.com


   Bruno Decraene
   Orange
   France

   Email: bruno.decraene@orange.com


   Shaowen Ma
   Juniper

   Email: mashaowen@gmail.com


   Chaitanya Yadlapalli
   AT&T
   USA

   Email: cy098d@att.com


   Wim Henderickx
   Nokia
   Belgium

   Email: wim.henderickx@nokia.com






Clad, et al.            Expires September 6, 2018              [Page 35]

Internet-Draft    Segment Routing for Service Chaining        March 2018


   Stefano Salsano
   Universita di Roma "Tor Vergata"
   Italy

   Email: stefano.salsano@uniroma2.it














































Clad, et al.            Expires September 6, 2018              [Page 36]