Spring Working Group X. Xu Internet-Draft J. You Intended status: Standards Track Huawei Expires: December 24, 2014 H. Shah Ciena L. Contreras Telefonica I+D June 22, 2014 PCE-based SFC Architecture in SR Networks draft-xu-spring-pce-based-sfc-arch-01 Abstract Service Function Chaining (SFC) provides a flexible way to construct services. When applying a particular service function chain to the traffic, the traffic needs to be steered through an ordered set of service functions in the network. This ordered set of service functions in the network, referred to as a Service Function Path (SFP), is an instantiation of the service function chain in the network. Segment Routing (SR) technique can be leveraged to steer the traffic through the SFP in SR networks. This document describes a PCE-based SFC architecture in which the PCE is used to compute a service function path (i.e., instantiate a service function chain) in SR networks. 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." Xu, et al. Expires December 24, 2014 [Page 1] Internet-Draft PCE-based SFC Arch June 2014 This Internet-Draft will expire on December 24, 2014. 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 (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. PCE-based SFC Architecture in SR Networks . . . . . . . . . . 4 3.1. PCC Requests SFP . . . . . . . . . . . . . . . . . . . . 6 3.2. PCC Requests SR-specific SFP . . . . . . . . . . . . . . 6 3.3. PCEP Extensions Discussion . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 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 Service Function Chaining provides a flexible way to construct services. When applying a particular service function chain to the traffic classified by the SFC classifier, the traffic needs to be steered through an ordered set of service functions in the network. This ordered set service functions in the network, referred to as a Service Function Path (SFP), is an instantiation of the service function chain in the network. For example, as shown in Figure 1, a SFP corresponding to the SFC of {SF1, SF3} can be expressed as {Service Node 1, SF1, Service Node 2, SF3}. Xu, et al. Expires December 24, 2014 [Page 2] Internet-Draft PCE-based SFC Arch June 2014 +-------------------------------------------------+ | SR Netowrks | | +-----+ +-----+ | | | SF1 | | SF2 | | | +--+--+ +--+--+ | | | | | | ^ | | | | (2)| +---+ +---+ | | +--+ | | | | | | | +--------------+ | | V | | |+-----+ | | +----------+ (1) +---+-+----+ (3) || SF3 | | | --> |SFC |----> | Service |---->|+-----+ |----> ----+Classifier+------+ Node 1 +-----+Service Node 2+-------- +----------+ +----------+ +--------------+ | | | | | | | +-------------------------------------------------+ Figure 1: Service Function Chaining in SR Network Segment Routing (SR) [I-D.filsfils-spring-segment-routing] technique leverages the source routing and tunneling paradigms, which can be used to steer traffic through an ordered set of routers. SR can be applied to both MPLS data plane [I-D.gredler-spring-mpls], [I-D.filsfils-spring-segment-routing-mpls] and IPv6 data plane [I-D.previdi-6man-segment-routing-header]. [I-D.sivabalan-pce-segment-routing] specifies extensions to the Path Computation Element Protocol (PCEP) [RFC5440] that allow a stateful PCE to compute and instantiate an SR path. [I-D.xu-spring-sfc-use-case] describes a use case for SPRING where the SR mechanism is leveraged to realize the service path layer functionality of the SFC. This document describes an architecture for PCEP in which a stateful PCE is used to compute an SFP in SR networks. 2. Terminology This section contains definitions for terms used frequently throughout this document. However, many additional definitions can be found in [I-D.quinn-sfc-arch]. Service Function (SF): A function that is responsible for specific treatment of received packets. Xu, et al. Expires December 24, 2014 [Page 3] Internet-Draft PCE-based SFC Arch June 2014 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 Node (SN): Physical or virtual element that hosts one or more service functions and has one or more network locators associated with it for reachability and service delivery. SF Identifier (SF ID): A unique identifier that represents a service function within an SFC-enabled domain. 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 a SFC ingress node. Service Function Path (SFP): The instantiation of an SFC in the network. Specifically, it is an ordered list of service node locators and SF IDs. Compact SFP: An ordered list of service node locators. SR: Segment Routing. SR Header: an MPLS label stack or an IPv6 address list. SID: Segment Identifier. Service Function SID : A locally unique SID indicating a particular service function on a service node. SR-specific SFP: An ordered list of node SIDs (representing service nodes) and Service Function SIDs. Compact SR-specific SFP: An ordered list of node SIDs (representing service nodes). PCC: Path Computation Client. PCE: Path Computation Element. PCEP: Path Computation Element Protocol. 3. PCE-based SFC Architecture in SR Networks When a packet enters an SFC-enabled domain, the SFC classifier classifies the packet for service function chaining according to the local policy rules, and then attaches an SFC header Xu, et al. Expires December 24, 2014 [Page 4] Internet-Draft PCE-based SFC Arch June 2014 [I-D.quinn-sfc-nsh] to the packet which should include the SFP information. As in this document SR technique is leveraged to steer the packet through the SFP, the SFC classifier therefore needs to attach a segment list which represents the SFP to the packet. [RFC5440] describes PCEP for communication between a Path Computation Client (PCC) and a Path Control Element (PCE). In this document, the PCE is responsible for computing the SFP or the SR-specific SFP, while the SFC classifier constructs the SR header according to the path computation result returned from the PCE (as shown in Figure 2). +---------+ | | +---------> PCE | | | | | +---------+ | | | | | +---------------------------------------------------+ | | SR Netowrks | | | | | | ------------- | +--V--------+ ///// \\\\\ | | +-----+| // +-----+ +-----+ \\ | | | PCC || | | SF1 | | SF2 | | | ----> |SFC +-----+| | +-----+ +-----+ | -----> ------+Classifier +------ +-----+ ---------------- +-----------+ | | SF3 | - | | \\ +-----+ // | | \\\\\ ///// | | ------------- | +---------------------------------------------------+ Figure 2: PCE-based SFC Architecture in SR Networks Two methods will be discussed depending on the requested path type from the PCC: (1) The PCC requests an SFP. (2) The PCC requests an SR-specific SFP. In the first case, the SFC classifier needs to transform the SFP information to the SR-specific SFP information and then attach an SR header containing the SR-specific SFP information to the packets. For the second case, the SFC classifier can directly attach an SR Xu, et al. Expires December 24, 2014 [Page 5] Internet-Draft PCE-based SFC Arch June 2014 header containing the SR-specific SFP information to the packets. The detailed will be discussed in the following sub-sections. 3.1. PCC Requests SFP The PCE is responsible for computing the SFP based on the network information, SF information, service requirements, etc. How PCE computes the SFP is out of scope of this document. The SFC classifier is responsible to transform the SFP to the SR-specific SFP. The detailed procedures are described below: Step 1: The SFC classifier acting as a PCC sends a PCReq message to the PCE to request an SFP or a compact SFP. Two new setup types of the PATH-SETUP-TYPE TLV must be carried, indicating that an SFP or a compact SFP needs to be setup. The PCReq message also needs to carry an ordered set of SF Identifiers which indicates the SFC. Step 2: The PCE sends a response to the PCC, carrying an SFP or a compact SFP. Step 3: If the PCE returns an SFP, the SFC classifier transforms the SFP information into the SR-specific SFP information. If the PCE returns a compact SFP, the SFC classifier needs to insert the corresponding SF identifier after each service node and then transform it into the SR-specific SFP information . Step 4: Upon receiving the packets, the SFC classifier classifies them for service function chain according to classification rules. Packets are then attacheded with an SR header containing the corresponding SR-specific SFP information. 3.2. PCC Requests SR-specific SFP The PCE is responsible to compute the SR-specific SFP based on the network information, SF information, service requirements, etc. How PCE computes the SR-specific SFP is out of scope of this document. The SFC classifier is responsible to attach an SR header containing the SR-specific SFP information to the selected packets. The detailed procedures are described below: Step 1: The SFC classifier sends a PCReq message to the PCE to request an SR-specific SFP. A new setup type of the PATH-SETUP- TYPE TLV must be carried, indicating that an SR-specific SFP needs to be setup. The PCC also needs to carry an ordered set of SF identifiers. Xu, et al. Expires December 24, 2014 [Page 6] Internet-Draft PCE-based SFC Arch June 2014 Step 2: The PCE sends a response to the PCC, carrying an SR- specific SFP. Step 3: Upon receiving the packets, the SFC classifier classifies them for service chaining according to classification rules. Packets are then attched with an SR header containning the corresponding SR-specific SFP information. 3.3. PCEP Extensions Discussion The possible PCEP extensions for supporting the two methods proposed in this document will be specified in a separate document. 4. IANA Considerations TBD. 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. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. 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-03 (work in progress), June 2014. Xu, et al. Expires December 24, 2014 [Page 7] Internet-Draft PCE-based SFC Arch June 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-02 (work in progress), June 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. [I-D.previdi-6man-segment-routing-header] Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 Segment Routing Header (SRH)", draft-previdi-6man-segment- routing-header-01 (work in progress), June 2014. [I-D.quinn-sfc-arch] Quinn, P. and J. Halpern, "Service Function Chaining (SFC) Architecture", draft-quinn-sfc-arch-05 (work in progress), May 2014. [I-D.quinn-sfc-nsh] Quinn, P., Guichard, J., Fernando, R., Surendra, S., Smith, M., Yadav, N., Agarwal, P., Manur, R., Chauhan, A., Elzur, U., McConnell, B., and C. Wright, "Network Service Header", draft-quinn-sfc-nsh-02 (work in progress), February 2014. [I-D.sivabalan-pce-segment-routing] Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and R. Raszuk, "PCEP Extensions for Segment Routing", draft- sivabalan-pce-segment-routing-02 (work in progress), October 2013. [I-D.xu-spring-sfc-use-case] Xu, X., Li, Z., and H. Shah, "Service Function Chaining Use Case for SPRING", draft-xu-spring-sfc-use-case-01 (work in progress), June 2014. Authors' Addresses Xiaohu Xu Huawei Email: xuxiaohu@huawei.com Xu, et al. Expires December 24, 2014 [Page 8] Internet-Draft PCE-based SFC Arch June 2014 Jianjie You Huawei 101 Software Avenue, Yuhuatai District Nanjing, 210012 China Email: youjianjie@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 December 24, 2014 [Page 9]