Mpls Working Group J. You Internet-Draft X. Xu Intended status: Standards Track Huawei Expires: June 5, 2015 December 2, 2014 Service Function Chaining OAM in MPLS-SPRING Networks draft-you-mpls-spring-sfc-oam-00 Abstract This document describes a simple and efficient mechanism for detecting service function connectivity and availability in Multi- Protocol Label Switching (MPLS) - SPRING networks. This document proposes some new information that needs to be carried in an MPLS "echo request" and "echo reply" for the purposes of SF connectivity and availability detection. 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 June 5, 2015. 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 You & Xu Expires June 5, 2015 [Page 1] Internet-Draft SFC OAM in MPLS-SPRING December 2014 (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 . . . . . . . . . . . . . . . . . . . 4 3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Service Function FEC . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 6 4.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 6 4.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction A Service Function Chain (SFC) [I-D.ietf-sfc-architecture] as shown in Figure 1 defines a set of abstract Service Functions (SF) and ordering constraints that must be applied to packets and/or frames selected as a result of classification. The SFC as a sequence of abstract service functions to be delivered can be instantiated as a Service Function Path (SFP). Some SFPs may be fully specified, selecting exactly which SFF (Service Function Forwarder) and which SF are to be visited by packets using that SFP. MPLS-SPRING technique [I-D.filsfils-spring-segment-routing] can be leveraged to steer the traffic through an SFP in MPLS-SPRING networks. You & Xu Expires June 5, 2015 [Page 2] Internet-Draft SFC OAM in MPLS-SPRING December 2014 +-------------------------------------------------+ | SPRING Netowrks | | +-----+ +-----+ | | | SF1 | | SF2 | | | +--+--+ +--+--+ | | | | | | ^ | | | | (2)| +---+ +---+ | | +--+ | | | | | | | +--------------+ | | V | | |+-----+ | | +----------+ (1) +---+-+----+ (3) || SF3 | | | --> |SFC |----> | SFF 1 |---->|+-----+ |----> ----+Classifier+------+ +-----+ SFF 2 +-------- +----------+ +----------+ +--------------+ | | | | | | | +-------------------------------------------------+ Figure 1: Service Function Chaining in SPRING Network This document describes a simple and efficient mechanism that can be used to detect service function connectivity and availability in MPLS-SPRING ([I-D.filsfils-spring-segment-routing-mpls]) networks where the MPLS label stack is used to represent a given SFP ([I-D.xu-sfc-using-mpls-spring]). This document proposes some new information that needs to be carried in an MPLS "echo request" and "echo reply" which are defined in [RFC4379], for the purposes of SF connectivity and availability detection. 2. Terminology This section contains definitions for terms used frequently throughout this document. However, many additional definitions can be found in [RFC4379], [I-D.ietf-sfc-architecture] and [I-D.xu-sfc-using-mpls-spring]. 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 fully specified notion of exactly which SFF/SFs the packet will visit when it actually traverses the network. You & Xu Expires June 5, 2015 [Page 3] Internet-Draft SFC OAM in MPLS-SPRING December 2014 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 In the MPLS-SPRING-based SFC approach, service function SIDs are implemented as locally significant MPLS labels while node SIDs of SFF are implemented as either globally or locally significant MPLS labels. Thus the SFP can be represented by an MPLS label stack. [RFC4379] describes a mechanism to detect data plane failures in MPLS LSPs. While in the MPLS-SPRING-based SFC case, the SF is represented by a unique identifier (i.e., SF ID) within an SFC-enabled domain. Therefore, a new target FEC element referred to as the Service Function FEC needs to be defined as follows: Sub-Type Length Value Field -------- ------ ------------- 17 4 SF ID 3.1. Return Codes The Return Code is set to zero by the sender. The receiver can set it to 14 (i.e. Service Unavailable) if the SF is unavailable. Value Meaning ----- ------- 14 Service Unavailable You & Xu Expires June 5, 2015 [Page 4] Internet-Draft SFC OAM in MPLS-SPRING December 2014 3.2. Service Function FEC When an SF SID (in the MPLS label format) is encoded in a label stack, the corresponding Service Function FEC as shown below should be inserted into the FEC stack accordingly. The value consists of a 4-octet SF ID; the format is given 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 = 17 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3. MPLS Echo Messages In the MPLS-SPRING-based SFC scenario, the SFC classifier or PMS (Path Monitoring System) generates an MPLS echo request that carries information about the SF whose connectivity/availability needs to be verified. The SFC classifier or PMS can send an MPLS echo request with a Target FEC Stack with a single FEC of type 17 (i.e., SF FEC). Alternatively, the SFC classifier or PMS can send a Target FEC Stack with two FECs, the first of type SF and the second of type Prefix Node Segment ID ([I-D.kumarkini-mpls-spring-lsp-ping]). In either case, the MPLS echo request would have a label stack of corresponding to the SF FEC being tested and the Prefix Node SID FEC of the SN to which the tested SF is attached. In addition, the above MPLS encapsulated MPLS echo request packets could be imposed further with one or more MPLS labels which are corresponding to one or more specified SFF ([I-D.geib-spring-oam-usecase]). In this way, the MPLS echo request packet would have to traverse one or more specified SFFs before reaching the final SFF to which the tested SF is attached. In other words, 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 SFs ahead of the tested SFs are not traversed at all. The destination SN that receives the MPLS echo request then processes it including egress FEC validation. Specifically, the SN would check whether the locally allocated MPLS label for the service function identified by the SF ID (i.e. SF FEC) is identical to the SF SID in the label stack, if not, the SN 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 You & Xu Expires June 5, 2015 [Page 5] Internet-Draft SFC OAM in MPLS-SPRING December 2014 SN, the SN SHOULD further verify the connectivity availability to the tested SF besides SF availability checking. How to verify connectivity and availability is outside the scope of this document. If the connectivity is down between the SN and the tested SF or the tested SF is unavailable (e.g. overloaded), the SN SHOULD return an MPLS Echo reply with the corresponding Return Code of 14 (section 3.1) to indicate that the SF is unavailable. The SF FEC Stack TLV from the echo request MAY be copied to the reply. On receipt of an MPLS echo reply, the SFC classifier or PMS should parse the packet for connectivity/availability check or fault isolation. 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 Stack 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 Stack TLV. The Return Code must be set to "Service Unavailable" if the SF is unavailable. 4. IANA Considerations 4.1. Return Codes Return Codes defined in this document are listed in the following: Value Meaning ----- ------- 14 Service Unavailable 4.2. TLVs TLVs and sub-TLVs defined in this document are the following: Type Sub-Type Value Field -------- --------- ------------- 1 Target FEC Stack 17 SF ID You & Xu Expires June 5, 2015 [Page 6] Internet-Draft SFC OAM in MPLS-SPRING December 2014 5. Security considerations This document does not introduce any new security considerations. 6. Acknowledgement TBD. 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. 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.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.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-02 (work in progress), September 2014. You & Xu Expires June 5, 2015 [Page 7] Internet-Draft SFC OAM in MPLS-SPRING 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 Xiaohu Xu Huawei Email: xuxiaohu@huawei.com You & Xu Expires June 5, 2015 [Page 8]