Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Xiaohu Xu , Zhenbin Li , Himanshu C. Shah , Luis M. Contreras
Last updated 2014-09-25
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-xu-sfc-using-mpls-spring-00
Network Working Group                                              X. Xu
Internet-Draft                                                     Z. Li
Intended status: Informational                                    Huawei
Expires: March 29, 2015                                          H. Shah
                                                                   Ciena
                                                            L. Contreras
                                                          Telefonica I+D
                                                      September 25, 2014

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

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 March 29, 2015.

Copyright Notice

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

Xu, et al.               Expires March 29, 2015                 [Page 1]
Internet-Draft                                            September 2014

   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 . . . . .   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 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 SPF 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
   plane [I-D.gredler-spring-mpls]

Xu, et al.               Expires March 29, 2015                 [Page 2]
Internet-Draft                                            September 2014

   [I-D.filsfils-spring-segment-routing-mpls] and IPv6 data plane.  This
   document only describes how to leverage the MPLS-based source routing
   mechanisms to realize the service path layer functionality of the
   service function chaining.  How to leverage the IPv6-based source
   routing mechanism will be discried in a separate document.
   Furthermore, how to carry metadata within MPLS packet would be
   described in a separate document as well.

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.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 Forwarder (SFF) nodes
   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 addition, assume node
   SIDs for SFF1 and SFF2 are SID(SFF1) and SID(SFF2) respectively.  To

Xu, et al.               Expires March 29, 2015                 [Page 3]
Internet-Draft                                            September 2014

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

3.1.  Encoding SFP Information by an MPLS Label Stack

   Since the selected packet needs to travel through an SFC {SF1, SF2},
   the service classifier would attach a segment list {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)).  Before sending the packet to SF1, the
   remaining MPLS label stack (i.e., a segment list {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) ).  When the encapsulated
   packet arrives at SFF2, SFF2 would do the similar action as what has
   been done by SFF1.  Provided that there was no MPLS LSP tunnel
   towards the next node segment (i.e., the next SFF node 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]) towards the next node
   segment could be used instead.  For more details about this special
   usage, please refer to [I-D.xu-spring-islands-connection-over-ip].
   This approach of encoding the SFP information by an MPLS label stack
   is transport independent since the transport (i.e., the underlay)
   protocol could be IPv4, IPv6 or even MPLS.  In other words, it fully
   meets the requirement of transport independence for the SFC
   encapsulation as mentioned in [I-D.ietf-sfc-architecture].

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 {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 encapsulated packet
   through either an MPLS LSP tunnel or an IP-based tunnel towards SFF1.

Xu, et al.               Expires March 29, 2015                 [Page 4]
Internet-Draft                                            September 2014

   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)).  Before sending the packet to SF1, the remaining MPLS label
   stack (i.e., a segment list {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.
   This approach of encoding the SFC information by an MPLS label stack
   is transport independent since the transport (i.e., the underlay)
   protocol could be IPv4, IPv6 or even MPLS.  In other words, it fully
   meets the requirement of transport independence for the SFC
   encapsulation as mentioned in [I-D.ietf-sfc-architecture].

4.  Acknowledgements

   The authors would like to thank Loa Andersson and Andrew G.  Malis
   for their valuable comments and suggestions on the draft.

5.  IANA Considerations

   TBD.

6.  Security Considerations

   TBD

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-03 (work in progress), August
              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.

Xu, et al.               Expires March 29, 2015                 [Page 5]
Internet-Draft                                            September 2014

   [I-D.xu-spring-islands-connection-over-ip]
              Xu, X., Raszuk, R., Chunduri, U., and V. Lopezalvarez,
              "Connecting MPLS-SPRING Islands over IP Networks", draft-
              xu-spring-islands-connection-over-ip-02 (work in
              progress), August 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-04 (work in progress), July 2014.

   [I-D.ietf-mpls-in-udp]
              Xu, X., Sheth, N., Yong, L., Pignataro, C., and F.
              Yongbing, "Encapsulating MPLS in UDP", draft-ietf-mpls-in-
              udp-05 (work in progress), January 2014.

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

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

   [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

Xu, et al.               Expires March 29, 2015                 [Page 6]
Internet-Draft                                            September 2014

   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 March 29, 2015                 [Page 7]