Internet DRAFT - draft-you-mpls-spring-sfc-oam

draft-you-mpls-spring-sfc-oam







Mpls Working Group                                                J. You
Internet-Draft                                                     X. Xu
Intended status: Standards Track                                  Huawei
Expires: July 15, 2015                                  January 11, 2015


         Service Function Chaining OAM in MPLS-SPRING Networks
                    draft-you-mpls-spring-sfc-oam-01

Abstract

   To perform Service Function Chaining (SFC) in networks where both
   MPLS and SPRING (Source Packet Routing in Networking) are enabled, it
   is required to be able to detect Service Function (SF) connectivity
   and availability.  This document proposes a simple mechanism for SF
   connectivity and availability detection by using the MPLS echo
   request and reply messages as defined in [RFC4379].

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 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 15, 2015.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



You & Xu                  Expires July 15, 2015                 [Page 1]

Internet-Draft           SFC OAM in MPLS-SPRING             January 2015


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  SFC OAM in MPLS-SPRING-based SFC  . . . . . . . . . . . . . .   4
     3.1.  SF FEC Sub-TLV  . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Return Codes  . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  MPLS Echo Messages  . . . . . . . . . . . . . . . . . . .   5
     3.4.  Packet Format of Echo Request . . . . . . . . . . . . . .   6
     3.5.  Packet Format of Echo Reply . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Return Codes  . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  SF FEC Sub-TLV  . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   A service function chain [I-D.ietf-sfc-architecture] as shown in
   Figure 1, is defined as a set of abstract Service Functions (SF) and
   ordering constraints that must be applied to those packets and/or
   frames being selected as a result of classification.  A service
   function chain can be instantiated as a Service Function Path (SFP)
   in the network by determining which Service Function Forwarders (SFF)
   and which SFs are to be visited.  MPLS-SPRING (Source Packet Routing
   in Networking) [I-D.ietf-spring-segment-routing-mpls] which is an
   MPLS-based source routing paradigm, can be leveraged to realize the
   service path layer functionality of the Service Function Chaining
   (SFC) (i.e, steering traffic through a particular SFP) in MPLS-SPRING
   networks by using an MPLS label stack to represent a given SFP
   [I-D.xu-sfc-using-mpls-spring].








You & Xu                  Expires July 15, 2015                 [Page 2]

Internet-Draft           SFC OAM in MPLS-SPRING             January 2015


               +-------------------------------------------------+
               |                                 SPRING Networks |
               |         +-----+   +-----+                       |
               |         | SF1 |   | SF2 |                       |
               |         +--+--+   +--+--+                       |
               |            |         |                          |
               |         ^  |         |                          |
               |      (2)|  +---+ +---+                          |
               |         +--+   | |                              |
               |            |   | |          +--------------+    |
               |            V   | |          |+-----+       |    |
          +----------+ (1)  +---+-+----+ (3) || SF3 |       |    |
      --> |SFC       |----> |  SFF 1   |---->|+-----+       |---->
      ----+Classifier+------+          +-----+     SFF 2    +--------
          +----------+      +----------+     +--------------+    |
               |                                                 |
               |                                                 |
               |                                                 |
               +-------------------------------------------------+


                Figure 1: Service Function Chaining in SPRING Network

   SF connectivity and availability detection is one of the important
   requirements for deploying SFC.  This document describes a simple
   mechanism for detecting SF connectivity and availability in MPLS-
   SPRING networks by leveraging the MPLS data plane failure detection
   mechanism as defined in [RFC4379].  Accordingly, This document
   proposes some extensions to the MPLS "echo request" and "echo reply"
   messages as defined in [RFC4379].

2.  Terminology

   This section contains definitions of term frequently used throughout
   this document.  Please note that these are not the original
   definitions; they were all defined in other documents
   [I-D.ietf-sfc-architecture] and [I-D.xu-sfc-using-mpls-spring]; they
   are included here to make reading the document easier.  Further
   useful terminology can be found in these documents as well as in
   [RFC4379].

      Service Function Chain (SFC): A service function chain defines an
      ordered set of service functions that must be applied to packets
      and/or frames selected as a result of classification.

      Service Function Path (SFP): The SFP provides a level of
      indirection between the fully abstract notion of service chain as
      a sequence of abstract service functions to be delivered, and the



You & Xu                  Expires July 15, 2015                 [Page 3]

Internet-Draft           SFC OAM in MPLS-SPRING             January 2015


      fully specified notion of exactly which SFF/SFs the packet will
      visit when it actually traverses the network.

      Service Function (SF): A function that is responsible for specific
      treatment of received packets.

      Service Function Forwarder (SFF): A service function forwarder is
      responsible for delivering traffic received from the network to
      one or more connected service functions according to information
      carried in the SFC encapsulation, as well as handling traffic
      coming back from the SF.

      SFC Classifier: An entity that classifies packets for service
      function chaining according to classification rules.  Packets are
      then marked with the corresponding SFC header.  SFC classifier is
      embedded in an SFC ingress node.

      SF Identifier (SF ID): A unique identifier that represents a
      service function within an SFC-enabled domain.

      SID: Segment Identifier.

      Service Function SID (SF SID): A locally unique SID indicating a
      particular service function on an SFF.

3.  SFC OAM in MPLS-SPRING-based SFC

   In the MPLS-SPRING-based SFC case, a given SF within an SFC-enabled
   domain is represented by a unique identifier (i.e., SF ID).  To
   detect the connectivity and availability of a given SF, an MPLS echo
   request carrying the corresponding FEC to that SF, referred to as SF
   FEC as defined in Section 3.1, will be sent.

3.1.  SF FEC Sub-TLV

   When an SF SID (in the MPLS label format) is encoded in an MPLS label
   stack, the corresponding SF FEC as shown below SHOULD be inserted
   into the target FEC stack accordingly.  The format of SF FEC is
   defined as below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Type = TBD1            |          Length = 4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             SF ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




You & Xu                  Expires July 15, 2015                 [Page 4]

Internet-Draft           SFC OAM in MPLS-SPRING             January 2015


      Type (TBD1): to be assigned by IANA

      Length: indicates the length of the value field (4 octets)

      SF ID: Service Function Identifier

3.2.  Return Codes

   The Return Code is set to zero by the sender.  The receiver can set
   it to TBD2 (i.e.  Service Unavailable) if the tested SF is
   unavailable.

                      Value            Meaning
                     -------       -------------------
                       TBD2        Service Unavailable

3.3.  MPLS Echo Messages

   To perform SF connectivity/availability detection for a given SF in
   the MPLS-SPRING-based SFC scenario, the SFC classifier would generate
   an MPLS echo request that carries the SF FEC corresponding to that
   SF.  The MPLS echo request could also be generated from a special
   node other than the classifier.  In that case, the echo packet SHOULD
   be further imposed with an MPLS label corresponding to the SFC
   classifier according to the mechanism as defined in
   [I-D.geib-spring-oam-usecase].

   The SFC classifier can send an MPLS echo request with the type of the
   Target FEC set to SF FEC.  Alternatively, the SFC classifier can send
   a Target FEC Stack with two FECs with the first being SF FEC and the
   second being Prefix Node SID FEC
   [I-D.kumarkini-mpls-spring-lsp-ping].  In both cases, the MPLS echo
   request SHOULD have a label stack corresponding to the SF FEC being
   tested and the Prefix Node SID FEC of the SFF to which the tested SF
   is attached.  In addition, the MPLS echo request packet could be
   imposed with additional MPLS labels corresponding to one or more
   additional SFFs according to the mechanism as defined in
   [I-D.geib-spring-oam-usecase].  In this way, the MPLS echo request
   packet will traverse one or more additional SFFs before reaching the
   SFF to which the tested SF is attached.  As a result, the MPLS echo
   request packet can be ensured to travel through the same ordered set
   of SFFs as the given SFP to which the tested SF belongs, although the
   previous SFs ahead of the tested SFs along the SFP are not traversed
   at all.

   Upon receiving an MPLS echo request, the destination SFF would
   processe it accordingly.  Specifically, the SFF would check whether
   the locally allocated MPLS label for the tested SF identified by the



You & Xu                  Expires July 15, 2015                 [Page 5]

Internet-Draft           SFC OAM in MPLS-SPRING             January 2015


   SF FEC is identical to the SF SID in the label stack of the MPLS echo
   request.  If not, the SFF SHOULD return an MPLS Echo reply that
   carries information about the tested SF availability and one of the
   Return Codes as defined in [RFC4379] to indicate the particular
   error.  In the case where the tested SF is externally attached to the
   SFF, the SFF SHOULD further verify the connectivity between itself
   and the tested SF as well as the availability of the tested SF.  How
   to verify the connectivity and availability is outside the scope of
   this document.  If the connectivity between the SFF and the tested SF
   is down or the tested SF is unavailable (e.g.  overloaded), the SFF
   SHOULD return an echo reply with the corresponding Return Code of
   TBD2 (i.e., Service Unavailable) (See section 3.2) to indicate that
   the tested SF is unavailable.

   The target FEC Stack TLV from the echo request MAY be copied to the
   echo reply.  On receipt of the corresponding echo reply, the SFC
   classifier SHOULD parse the packet for connectivity/availability
   check or fault isolation.  For instance, to check the connectivity of
   a given SFP (e.g., SFF1->SF1->SFF2->SF3) within the SFC domain as
   shown in Figure 1, two OAM packets need to be sent from the
   classifier: the first is used for the connectivity check of SF1 and
   therefore it is appended with an SR header of {SID(SFF1), SID(SF1)};
   the second is used for the connectivity check for SF3 and therefore
   it is appended with an SR header of {SID(SFF1), SID(SFF2), SID(SF3)}.
   In this way, it doesn't require any SF along the SFP to process the
   OAM packets.  As such, this connectivity check approach is applicable
   in the scenario where legacy SFs exist.

   To prevent the echo request packet from being forwarded by the SFF
   farther to the attached SF being tested, the TTL of the innermost
   label (i.e., the label corresponding to the SF FEC) MUST be set to 1,
   just as what has been done for the echo request for an L2 VPN
   endpoint or a pseudowire as stated in [RFC4379].

3.4.  Packet Format of Echo Request

   An MPLS echo request is an IPv4 or IPv6 UDP packet.  The packet
   format is defined in [RFC4379].  The echo request is extended to
   carry the SF FEC sub-TLV.

3.5.  Packet Format of Echo Reply

   An MPLS echo reply is an IPv4 or IPv6 UDP packet.  The packet format
   is defined in [RFC4379].  The echo reply is extended to carry the SF
   FEC sub-TLV.  The Return Code MUST be set to TBD2 (i.e., "Service
   Unavailable") if the tested SF is unavailable.





You & Xu                  Expires July 15, 2015                 [Page 6]

Internet-Draft           SFC OAM in MPLS-SPRING             January 2015


4.  IANA Considerations

4.1.  Return Codes

   IANA is requested to allocate the first free code point from the
   standards action segment of the "Return Codes" sub-registry in a new
   Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
   Ping Parameters registry.

   Return Codes defined in this document are listed in the following:

                      Value            Meaning
                     -------       -------------------
                       TBD2        Service Unavailable

4.2.  SF FEC Sub-TLV

   TLVs and sub-TLVs defined in this document are the following:

               Sub-Type        Length           Value Field
               ---------      ---------        -------------
                 TBD1             4                SF ID

5.  Security considerations

   This document neither introduce additional security risk nor provide
   any additional security feature besides those which have been
   described in [RFC4379].

6.  Acknowledgement

   The authors would like to thank Loa Andersson and Mach Chen for their
   valuable reviews of this document.

7.  References

7.1.  Normative References

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

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.







You & Xu                  Expires July 15, 2015                 [Page 7]

Internet-Draft           SFC OAM in MPLS-SPRING             January 2015


7.2.  Informative References

   [I-D.geib-spring-oam-usecase]
              Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
              case for a scalable and topology aware MPLS data plane
              monitoring system", draft-geib-spring-oam-usecase-03 (work
              in progress), October 2014.

   [I-D.ietf-sfc-architecture]
              Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", draft-ietf-sfc-architecture-03 (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-00 (work in progress), December
              2014.

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

   [I-D.kumarkini-mpls-spring-lsp-ping]
              Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,
              S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
              Ping/Trace for Segment Routing Networks Using MPLS
              Dataplane", draft-kumarkini-mpls-spring-lsp-ping-02 (work
              in progress), October 2014.

   [I-D.xu-sfc-using-mpls-spring]
              Xu, X., Li, Z., Shah, H., and L. Contreras, "Service
              Function Chaining Using MPLS-SPRING", draft-xu-sfc-using-
              mpls-spring-01 (work in progress), October 2014.

Authors' Addresses

   Jianjie You
   Huawei
   101 Software Avenue, Yuhuatai District
   Nanjing,  210012
   China

   Email: youjianjie@huawei.com



You & Xu                  Expires July 15, 2015                 [Page 8]

Internet-Draft           SFC OAM in MPLS-SPRING             January 2015


   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com















































You & Xu                  Expires July 15, 2015                 [Page 9]