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

Versions: 00 01 02 03 04 05 06

Network Working Group                                              X. Xu
Internet-Draft                                                     Z. Li
Intended status: Informational                                    Huawei
Expires: September 4, 2015                                       H. Shah
                                                                   Ciena
                                                            L. Contreras
                                                          Telefonica I+D
                                                           March 3, 2015


              Service Function Chaining Using MPLS-SPRING
                   draft-xu-sfc-using-mpls-spring-02

Abstract

   Source Packet Routing in Networking (SPRING) WG specifies a special
   source routing mechanism.  Such source routing mechanism can be
   leveraged to realize the service path layer functionality of the
   service function chaining (i.e, steering traffic through a particular
   service function path) by encoding the service function path or the
   service function chain information as the explicit path information.
   This document describes how to leverage the MPLS-based source routing
   mechanism as developed by the SPRING WG to realize the service path
   layer functionality of the service function chaining.

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 September 4, 2015.

Copyright Notice

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





Xu, et al.              Expires September 4, 2015               [Page 1]


Internet-Draft                                                March 2015


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Solution Description  . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Encoding SFP Information by an MPLS Label Stack . . . . .   4
     3.2.  Encoding SFC Information by an MPLS Label Stack . . . . .   5
     3.3.  How to Contain Metadata within an MPLS Packet . . . . . .   6
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   When applying a particular Service Function Chain (SFC)
   [I-D.ietf-sfc-architecture] 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.  To steer the selected traffic through an ordered list
   of SFs in the network, the traffic need to be attached by the service
   classifier with the information about the SFP (i.e., 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.  Source Packet Routing in
   Networking (SPRING) WG specifies a special source routing mechanism
   which can be used to steer traffic through an ordered set of routers
   (i.e., an explicit path).  Such source routing mechanism can be
   leveraged to realize the service path layer functionality of the SFC
   (i.e., steering traffic through a particular SFP) by encoding the
   SFP, the SFC or the partially specified SFP information as the
   explicit path information contained in packets.  The source routing
   mechanism specified by the SPRING WG can be applied to the MPLS data



Xu, et al.              Expires September 4, 2015               [Page 2]


Internet-Draft                                                March 2015


   plane [I-D.ietf-spring-segment-routing-mpls].  This document
   describes how to leverage the MPLS-based source routing mechanisms to
   realize the service path layer functionality of the service function
   chaining.  Note that this approach is aligned with the Transport
   Derived SFF mode as described in Section 4.3.1 of
   [I-D.ietf-sfc-architecture].

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.ietf-spring-segment-routing] and [I-D.ietf-sfc-architecture].

3.  Solution Description

           +----------------------------------------------- ----+
           |                  SPRING Netowrks                   |
           |            +---------+       +---------+           |
           |            |   SF1   |       |   SF2   |           |
           |            +----+----+       +----+----+           |
           |                 |                 |                |
           |       (1)       |      (2)        |      (3)       |
      +----+-----+ ---> +----+----+ ----> +----+----+ --->  +---+---+
      |Classifier+------+  SFF1   +-------+  SFF2   +-------+   D   |
      +----------+      +---------+       +---------+       +---+---+
           |                                                    |
           +----------------------------------------------------+
            Figure 1: Service Function Chaining in SPRING Networks

   As shown in Figure 1, assume SFF1 and SFF2 are two MPLS-SPRING-
   capable nodes.  They are also Service Function Forwarders (SFF) to
   which two SFs (i.e., SF1 and SF2) are attached respectively.  In
   addition, they have allocated and advertised Segment IDs (SID) for
   their locally attached SFs.  In the MPLS-SPRING context, SIDs are
   intercepted as MPLS labels.  For example, SFF1 allocates and
   advertises an SID (i.e., SID(SF1)) for SF1 while SFF2 allocates and
   advertises an SID ( i.e., SID(SF2)) for SF2.  These SIDs which are
   used to indicate SFs are referred to as SF SIDs.  To encode the SFP
   information by an MPLS label stack, those SF SIDs as mentioned above
   would be interpreted as local MPLS labels.  In contrast, to encode
   the SFC information by an MPLS label stack, those SF SIDs MUST be
   interpreted as domain-wide unique MPLS labels, which means a big
   difference from the current usage of the MPLS labels.  The reason why



Xu, et al.              Expires September 4, 2015               [Page 3]


Internet-Draft                                                March 2015


   local MPLS labels are not applicable is that all of the labels in the
   stack would have to be swapped by the current SFF before forwarding
   the packet to the next SFF if local labels are used.  In addition,
   assume node SIDs for SFF1 and SFF2 are SID(SFF1) and SID(SFF2)
   respectively.  To simplify the illustration in this document, those
   node SIDs would be interpreted as domain-wide unique MPLS labels as
   well.  Now assume a given traffic flow destined for destination D is
   selected by the service classifier to go through a particular SFC
   (i.e., SF1-> SF2) before reaching its final destination D.
   Section 3.1 and 3.2 describe approaches of leveraging the MPLS- based
   source routing mechanisms to realize the service path functionality
   of the service function chaining (i.e., by encoding the SFP
   information within an MPLS label stack or by encoding the SFC
   information within an MPLS label stack) respectively.  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.

3.1.  Encoding SFP Information by an MPLS Label Stack

   Since the selected packet needs to travel through an SFC (i.e.,
   SF1->SF2), the service classifier would attach a segment list of
   (i.e., SID(SFF1)->SID(SF1)->SID(SFF2)-> SID(SF2)) which indicates the
   corresponding SFP to the packet.  This segment list is actually
   represented by a MPLS label stack.  When the encapsulated packet
   arrives at SFF1, SFF1 would know which SF should be performed
   according to the current top label (i.e., SID (SF1)) of the received
   MPLS packet.  Before sending the packet to SF1, the whole MPLS label
   stack (i.e., SID(SFF2)->SID(SF2)) MUST be stripped.  After receiving
   the packet returned from SF1, SFF1 would reimpose the MPLS label
   stack which had been stripped before to the packet and then send it
   to SFF2 according to the current top label (i.e., SID (SFF2) ).  Note
   that popping and reimposing a label stack means a difference from the
   current MPLS forwarding behavior.  Details of the above special MPLS
   forwarding behavior would be discribed in a later version of this
   document.  When the encapsulated packet arrives at SFF2, SFF2 would
   do the similar action as what has been done by SFF1.  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 [I-D.ietf-sfc-architecture].

   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 (e.g., MPLS-in-IP/GRE tunnel [RFC4023], MPLS-in-L2TPv3 tunnel
   [RFC4817] or MPLS-in-UDP tunnel [I-D.ietf-mpls-in-udp]) could be used
   instead (For more details about this special usage, please refer to
   [I-D.xu-spring-islands-connection-over-ip]).  Since the transport
   (i.e., the underlay) could be IPv4, IPv6 or even MPLS networks, the



Xu, et al.              Expires September 4, 2015               [Page 4]


Internet-Draft                                                March 2015


   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 [I-D.ietf-sfc-architecture].

   In addition, the service classifier could further impose metadata on
   the MPLS packet through the Network Service Header (NSH)
   [I-D.quinn-sfc-nsh] (As for how to contain the NSH within a MPLS
   packet, please see Section 3.3).  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 a value indicating the total number of SFs within the
   service function path.  The service index SHOULD be decreased by one
   on each SF or SF-proxy on behalf of the corresponding legacy SF.
   When the service index become zero, the NSH MUST be removed from the
   packet by the SF or SF-proxy on behalf of the corresponding legacy
   SF.

3.2.  Encoding SFC Information by an MPLS Label Stack

   Since the selected packet needs to travel through an SFC (i.e.,
   SF1->SF2), the service classifier would attach a segment list (i.e.,
   SID(SF1)->SID(SF2)) which indicates that SFC to the packet.  This
   segment list is actually represented by a MPLS label stack.  Since
   it's 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.  When the MPLS encapsulated packet arrives at
   SFF1, SFF1 would know which SF should be performed according to the
   current top label (i.e., SID (SF1)).  Before sending the packet to
   SF1, the whole MPLS label stack (i.e., SID(SF2)}) MUST be stripped.
   Upon receiving the packet returned from SF1, SFF1 would re-impose the
   MPLS label stack which had been stripped before to the packet, and
   then send it 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
   [I-D.ietf-sfc-architecture].

   In addition, the service classifier could further impose metadata on
   the MPLS packet through the Network Service Header (NSH)
   [I-D.quinn-sfc-nsh].  The procedures of imposing, consumming and
   stripping the NSH is the same as that being mentioned in Section 3.1.




Xu, et al.              Expires September 4, 2015               [Page 5]


Internet-Draft                                                March 2015


3.3.  How to Contain Metadata within an MPLS Packet

   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 MPLS packets is a potential issue.
   There are two possible ways to address the above issue: 1) SFFs
   allocate two different labels for a given SF, one indicates the
   presence of NSH while the other indicates the absence of NSH; 2) Add
   an protocol identifier field at the bottom of the MPLS label stack to
   indicate the presence or absence of the NSH (For more details about
   the protocol identifier field in the MPLS packet, see
   [I-D.xu-mpls-payload-protocol-identifier] ).  The former approach has
   no change to the current MPLS architecture but it would require more
   than one label binding for a given SF.  The latter approach only
   requires a single label binding for a given SF but it would require a
   little change to the current MPLS architecture.  Which approach would
   be chosen depends on the rough consensus of the IETF community.

4.  Acknowledgements

   The authors would like to thank Loa Andersson and Andrew G.  Malis
   for their valuable comments and suggestions on the draft.  The
   authors would like to thank Adrian Farrel, Stewart Bryant, Carlos
   Pignataro, Huub van Helvoort, Alexander Vainshtein, Joel M.  Halpern,
   Loa Andersson and Andrew G.  Malis for their valuable comments and
   suggestions on how to indicate the presence of metadata within an
   MPLS packet.

5.  IANA Considerations

   TBD.

6.  Security Considerations

   TBD

7.  References

7.1.  Normative References

   [I-D.ietf-sfc-architecture]
              Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", draft-ietf-sfc-architecture-05 (work
              in progress), February 2015.






Xu, et al.              Expires September 4, 2015               [Page 6]


Internet-Draft                                                March 2015


   [I-D.ietf-spring-segment-routing-mpls]
              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
              Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
              and E. Crabbe, "Segment Routing with MPLS data plane",
              draft-ietf-spring-segment-routing-mpls-00 (work in
              progress), December 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.ietf-mpls-in-udp]
              Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
              "Encapsulating MPLS in UDP", draft-ietf-mpls-in-udp-11
              (work in progress), January 2015.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
              Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
              and E. Crabbe, "Segment Routing Architecture", draft-ietf-
              spring-segment-routing-01 (work in progress), February
              2015.

   [I-D.quinn-sfc-nsh]
              Quinn, P., Guichard, J., Surendra, S., Smith, M.,
              Henderickx, W., Nadeau, T., Agarwal, P., Manur, R.,
              Chauhan, A., Halpern, J., Majee, S., Elzur, U., Melman,
              D., Garg, P., McConnell, B., Wright, C., and K. Kevin,
              "Network Service Header", draft-quinn-sfc-nsh-07 (work in
              progress), February 2015.

   [I-D.xu-mpls-payload-protocol-identifier]
              Xu, X. and M. Chen, "MPLS Payload Protocol Identifier",
              draft-xu-mpls-payload-protocol-identifier-00 (work in
              progress), September 2013.

   [I-D.xu-spring-islands-connection-over-ip]
              Xu, X., Raszuk, R., Chunduri, U., and L. Contreras,
              "Connecting MPLS-SPRING Islands over IP Networks", draft-
              xu-spring-islands-connection-over-ip-04 (work in
              progress), March 2015.

   [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
              MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
              4023, March 2005.





Xu, et al.              Expires September 4, 2015               [Page 7]


Internet-Draft                                                March 2015


   [RFC4817]  Townsley, M., Pignataro, C., Wainner, S., Seely, T., and
              J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
              Protocol Version 3", RFC 4817, March 2007.

Authors' Addresses

   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com


   Zhenbin Li
   Huawei

   Email: lizhenbin@huawei.com


   Himanshu Shah
   Ciena

   Email: hshah@ciena.com


   Luis M. Contreras
   Telefonica I+D
   Ronda de la Comunicacion, s/n
   Sur-3 building, 3rd floor
   Madrid,  28050
   Spain

   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://people.tid.es/LuisM.Contreras/


















Xu, et al.              Expires September 4, 2015               [Page 8]


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