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]