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

Versions: 00 01 02

Network Working Group                                              X. Xu
Internet-Draft                                                     Z. Li
Intended status: Informational                                    Huawei
Expires: December 20, 2014                                       H. Shah
                                                                   Ciena
                                                           June 18, 2014


             Service Function Chaining Use Case for SPRING
                    draft-xu-spring-sfc-use-case-01

Abstract

   This document describes a particular use case for SPRING where the
   Segment Routing mechanism is leveraged to realize the service path
   layer functionality of the Service Function Chaining (i.e, steering
   traffic through the service function path).

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 December 20, 2014.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Xu, et al.              Expires December 20, 2014               [Page 1]


Internet-Draft           SFC Use Case for SPRING               June 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  SFC Use Case  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  SFC in MPLS-SR Case . . . . . . . . . . . . . . . . . . .   3
     3.2.  SFC in IPv6-SR Case . . . . . . . . . . . . . . . . . . .   4
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   When applying a particular Service Function Chaining (SFC)
   [I-D.quinn-sfc-arch] to the traffic selected by the service
   classifier, the traffic need to be steered through an ordered set of
   service nodes in the network.  This ordered set of service nodes
   indicates the service function path which is actually the
   instantiation of the above SFC in the network.  Furthermore,
   additional information about the traffic (a.k.a. metadata) which is
   helpful for enabling value-added services may need to be carried
   across those service nodes within the SFC instantiation.  As
   mentioned in [I-D.rijsman-sfc-metadata-considerations] "...it is
   important to make a distinction between fields which are used at the
   service path layer to identify the Service Path Segment, and
   additional fields which carry metadata which is imposed and
   interpreted at the service function layer.  Combining both types of
   fields into a single header should probably be avoided from a
   layering point of view. "

   Segment Routing (SR) [I-D.filsfils-spring-segment-routing] is a
   source routing paradigm which can be used to steer traffic through an
   ordered set of routers.  SR can be applied to the MPLS data plane
   [I-D.gredler-spring-mpls]
   [I-D.filsfils-spring-segment-routing-mpls]and the IPv6 data plane
   [I-D.previdi-6man-segment-routing-header].

   This document describes a particular use case for SPRING where the SR
   mechanism is leveraged to realize the service path layer




Xu, et al.              Expires December 20, 2014               [Page 2]


Internet-Draft           SFC Use Case for SPRING               June 2014


   functionality of the SFC (i.e, steering traffic through the service
   function path).

1.1.  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].

2.  Terminology

   This memo makes use of the terms defined in
   [I-D.filsfils-spring-segment-routing] and [I-D.quinn-sfc-arch].

3.  SFC Use Case

           +----------------------------------------------- ----+
           |                    SR Netowrks                     |
           |            +---------+       +---------+           |
           |            | +-----+ |       | +-----+ |           |
           |       (1)  | | SF1 | |  (2)  | | SF2 | | (3)       |
      +----+-----+ ---> | +-----+ | ----> | +-----+ | --->  +---+---+
      |Classifier+------+   SN1   +-------+   SN2   +-------+   D   |
      +----------+      +---------+       +---------+       +---+---+
           |                                                    |
           +----------------------------------------------------+
            Figure 1: Service Function Chaining in SR Networks

   As shown in Figure 1, assume SN1 and SN2 are two SR-capable nodes
   meanwhile they are service nodes which offer service function SF1 and
   SF2 respectively.  In addition, they have allocated and advertised
   segment IDs (SID) for the service functions they are offering.  For
   example, SN1 allocates and advertises an SID, i.e., SID(SF1) for
   service function SF1 while SN2 allocates and advertises an SID, i.e.,
   SID(SF2) for service function SF2.  These SIDs which are used to
   indicate service functions are referred to as Service Function SIDs.
   In addition, assume the node SIDs for SN1 and SN2 are SID(SN1) and
   SID(SN2) respectively.

   How to steer a packet through a service fucntion path in both MPLS-SR
   and IPv6-SR cases is illustrated in the following two sub-sections
   respectively.

3.1.  SFC in MPLS-SR Case

   In the MPLS-SR case, those service function SIDs as mentioned above
   would be interpreted as local MPLS labels.  Meanwhile, to simplify




Xu, et al.              Expires December 20, 2014               [Page 3]


Internet-Draft           SFC Use Case for SPRING               June 2014


   the illustrationIn in this document, those node SIDs as mentioned
   above would be interpreted as MPLS global labels.

   Now assume a given packet destined for destination D is required to
   go through a service function chain {SF1, SF2} before reaching its
   final destination D.  The service classifier therefore would attach a
   segment list {SID(SN1), SID(SF1), SID(SN2), SID(SF2)} to the packet.
   This segment list is actually represented by a MPLS label stack.  In
   addition, the service classifier could optionally impose metadata on
   the packet through the Network Service Header (NSH)
   [I-D.quinn-sfc-nsh].  Here the Service Path field wihin the NSH would
   not be used for the path selection purpose anymore and therefore it
   MUST be set to a particular value to indicate such particular usage.
   In addition, the service index value within the NSH is set to 2 since
   there are two service nodes within the service function path.  How to
   impose the NSH on a MPLS packet is outside the scope of this
   document.  When the encapsulated packet arrives at SN1, SN1 would
   know which service function should be performed according to SID
   (SF1).  If a NSH is carried in that packet, SN1 could further consume
   the metadata contained in the NSH and meanwhile decrease the service
   index value within the NSH by one.  When the encapsualted packet
   arrives at SN2, SN2 would do the similar action as what has been done
   by SN1.  Furthermore, since SN2 is the last service node within the
   service function path, SN2 MUST strip the NSH (if it has been
   imposed) before sending the packet to D.

3.2.  SFC in IPv6-SR Case

   In the IPv6-SR case, those service function SIDs as mentioned above
   would be interpreted as IPv6 link-local addresses while those node
   SIDs as mentioned above would be interpreted as IPv6 global unicast
   addresses.

   Now assume a given IPv6 packet destined for destination D is required
   to go through a service function chain {SF1, SF2} before reaching its
   final destination D.  The service classifier therefore would attach a
   SR header containing a segment list {SID(SF1),
   SID(SN2),SID(SF2),SID(D)} to the IPv6 packet.  This segment list is
   actually represented by an ordered list of IPv6 addresses.  The IPv6
   destination address is filled with SID(SN1).  In addition, the
   service classifier could optionally impose metadata on the above IPv6
   packet through the NSH and meanwhile carry the original IPv6 source
   address in the Original Source Address field of the packet.  When the
   above IPv6 packet arrives at SN1, SN1 would know which service
   function should be performed according to SID (SF1).  If a NSH is
   carried in that packet, SN1 could further consume the metadata
   contained in the NSH and meanwhile decrease the service index value
   within the NSH by one.  When the packet arrives at SN2, SN2 would do



Xu, et al.              Expires December 20, 2014               [Page 4]


Internet-Draft           SFC Use Case for SPRING               June 2014


   the similar action as what has been done by SN1.  Furthermore, since
   SN2 is the second last node in the segment list, SN2 should strip the
   SR header and meanwhile fill in the IPv6 source address with the
   Original Source Address (if available) before sending the packet
   towards D.  Besides, since SN2 is the last service node within the
   service path, SN2 MUST strip the NSH (if it has been imposed) before
   sending the packet to D.

4.  Acknowledgements

   TBD.

5.  IANA Considerations

   TBD.

6.  Security Considerations

   This document does not introduce any new security risk.

7.  References

7.1.  Normative References

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

   [I-D.gredler-spring-mpls]
              Gredler, H., Rekhter, Y., Jalil, L., Kini, S., and X. Xu,
              "Supporting Source/Explicitly Routed Tunnels via Stacked
              LSPs", draft-gredler-spring-mpls-06 (work in progress),
              May 2014.

   [I-D.previdi-6man-segment-routing-header]
              Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6
              Segment Routing Header (SRH)", draft-previdi-6man-segment-
              routing-header-01 (work in progress), June 2014.

   [I-D.quinn-sfc-arch]
              Quinn, P. and J. Halpern, "Service Function Chaining (SFC)
              Architecture", draft-quinn-sfc-arch-05 (work in progress),
              May 2014.




Xu, et al.              Expires December 20, 2014               [Page 5]


Internet-Draft           SFC Use Case for SPRING               June 2014


   [I-D.quinn-sfc-nsh]
              Quinn, P., Guichard, J., Fernando, R., Surendra, S.,
              Smith, M., Yadav, N., Agarwal, P., Manur, R., Chauhan, A.,
              Elzur, U., McConnell, B., and C. Wright, "Network Service
              Header", draft-quinn-sfc-nsh-02 (work in progress),
              February 2014.

   [I-D.rijsman-sfc-metadata-considerations]
              Rijsman, B. and J. Moisand, "Metadata Considerations",
              draft-rijsman-sfc-metadata-considerations-00 (work in
              progress), February 2014.

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

7.2.  Informative References

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

Authors' Addresses

   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com


   Zhenbin Li
   Huawei

   Email: lizhenbin@huawei.com


   Himanshu Shah
   Ciena

   Email: hshah@ciena.com









Xu, et al.              Expires December 20, 2014               [Page 6]


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