Pce Working Group X. Xu Internet-Draft J. You Intended status: Standards Track Huawei Expires: April 30, 2015 S. Sivabalan Cisco Systems H. Shah Ciena L. Contreras Telefonica I+D October 27, 2014 PCEP Extensions for SFC in SPRING Networks draft-xu-pce-sr-sfc-02 Abstract [I-D.xu-spring-pce-based-sfc-arch] describes a PCE-based SFC architecture in which the PCE is used to compute service function paths in SPRING networks. Based on the above architecture, this document describes extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and instantiate service function paths in SPRING networks. The extensions specified in this document are applicable to both the stateless PCE model and the stateful PCE model. 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 April 30, 2015. Xu, et al. Expires April 30, 2015 [Page 1] Internet-Draft PCEP Extensions for SPRING-based SFC October 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of PCEP Extensions for SFC in SR Networks . . . . . 5 4. PCEP Message Extensions for SR-based SFC . . . . . . . . . . 5 4.1. PCReq Message . . . . . . . . . . . . . . . . . . . . . . 5 4.2. PCRep Message . . . . . . . . . . . . . . . . . . . . . . 5 4.3. PCUpd Message . . . . . . . . . . . . . . . . . . . . . . 6 4.4. PCRpt Message . . . . . . . . . . . . . . . . . . . . . . 6 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. SR-SFC PCE Capability TLV . . . . . . . . . . . . . . 7 5.2. RP/SRP Object . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Include Route Object . . . . . . . . . . . . . . . . . . 8 5.4. SR-SFC-ERO Object . . . . . . . . . . . . . . . . . . . . 8 5.4.1. SR-SFC-ERO Subobject . . . . . . . . . . . . . . . . 9 5.4.2. NSI Associated with SID . . . . . . . . . . . . . . . 10 5.4.3. SR-SFC-ERO Processing . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 11 6.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 11 6.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 11 6.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 11 6.5. New IRO Sub-object Type . . . . . . . . . . . . . . . . . 11 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Xu, et al. Expires April 30, 2015 [Page 2] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 1. Introduction Service Function Chaining [I-D.ietf-sfc-architecture] provides a flexible way to construct services. When applying a particular Service Function Chain (SFC) to the traffic classified by the Classifier, the traffic needs to be steered through an ordered set of Service Functions (SF) in the network. This ordered set of SFs in the network, referred to as a Service Function Path (SFP), is an instantiation of the SFC in the network. For example, as shown in Figure 1, an SFP corresponding to the SFC of {SF1, SF3} can be expressed as {SFF1, SF1, SFF2, SF3}. +-------+ +--+ PCE | | +-------+ | | | | +-------------------------------------------------+ | | SR Netowrks | | | +-----+ +-----+ | | | | SF1 | | SF2 | | | | +--+--+ +--+--+ | | | | | | | | ^ | | | | | (2)| +---+ +---+ | | | +--+ | | | ++---------+ | | | +--------------+ | | +----+| V | | | +-----+ | | | |PCC || (1) +---+-+----+ (3) | | SF3 | | | --> |SFC +----+|----> | SFF1 |---->| +-----+ |----> ----+Classifier+------+ +-----+ SFF2 +-------- +----------+ +----------+ +--------------+ | | | +-------------------------------------------------+ Figure 1: PCE-based Service Function Chaining in SR Network [I-D.xu-spring-pce-based-sfc-arch] describes a PCE-based SFC architecture in which the PCE is used to compute an SFP (i.e., instantiate a service function chain) in SPRING networks (a.k.a., Segment Routing networks or SR networks in short). This document describes extensions to the PCEP on basis of that architecture. The extensions specified in this document are applicable to both the stateless PCE model defined in [RFC5440] and the stateful PCE model defined in [I-D.ietf-pce-stateful-pce]. Xu, et al. Expires April 30, 2015 [Page 3] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 2. Terminology This section contains definitions for terms used frequently throughout this document. However, many additional definitions can be found in [RFC5440], [I-D.sivabalan-pce-segment-routing] and [I-D.xu-spring-pce-based-sfc-arch]. PCC: Path Computation Client PCE: Path Computation Element PCEP: Path Computation Element Protocol ERO: Explicit Route Object Service Function Chain (SFC): A service function chain defines a set of abstract service functions and ordering constraints that must be applied to packets and/or frames selected as a result of classification. SF Identifier (SF ID): A unique identifier that represents a service function within an SFC-enabled domain. 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. 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. Specifically, it is an ordered list of SFFs and SF IDs. Compact SFP: An ordered list of SFFs. SID: Segment Identifier Service Function SID : A locally unique SID indicating a particular service function on an SFF. SR: Segment Routing SR-specific SFP: An ordered list of node SIDs (representing SFFs) and Service Function SIDs. Xu, et al. Expires April 30, 2015 [Page 4] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 Compact SR-specific SFP: An ordered list of node SIDs (representing SFFs). 3. Overview of PCEP Extensions for SFC in SR Networks As discussed in [I-D.xu-spring-pce-based-sfc-arch], the PCC provides an ordered list of SF IDs to the PCE and indicates to the PCE that what type SFs and paths are requested (e.g., an SFP, or a compact SFP, or an SR-specific SFP, or a compact SR-specific SFP) through the path computation request message, and then the PCE responds with a corresponding path through the path computation response message. This specification is applicable to both stateful and stateless PCEs. 4. PCEP Message Extensions for SR-based SFC 4.1. PCReq Message This document does not specify any changes to the PCReq message format. This document requires the PATH-SETUP-TYPE TLV [I-D.sivabalan-pce-lsp-setup-type] to be carried in the RP Object in order for a PCC to request a particular type of path. Four new Path Setup Types need to be defined for SR-based SFC, or SR-SFC in short (Section 5.2). This document also requires the Include Route Object (IRO) to be carried in the PCReq message in order for a PCC to specify SFC. A new IRO sub-object type needs to be defined for SF (Section 5.3). 4.2. PCRep Message This document defines the format of the PCRep message carrying an SFP. The message is sent by a PCE to a PCC in response to a previously received PCReq message, where the PCC requested an SFP. The format of the SFC-specific PCRep message is as follows: Xu, et al. Expires April 30, 2015 [Page 5] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 ::= Where: ::=[] ::= [] [] Where: ::=[] The RP and NO-PATH Objects are defined in [RFC5440]. The object contains the SFP and is defined in Section 5.4. 4.3. PCUpd Message This document defines the format of the PCUpd message carrying an SFP update. The message is sent forwardly by a PCE to a PCC to update an previously computed SFP. The format of the PCUpd message is as follows: ::= Where: ::=[] ::= Where: ::=[] 4.4. PCRpt Message PCPRpt message sent from a PCC to PCE as a respond to a PCUpd message or in an unsolicited manner (e.g., during state synchronization). The format of the PCUpd message is as follows: Xu, et al. Expires April 30, 2015 [Page 6] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 ::= Where: ::=[] ::=[] Where: ::=[] 5. Object Formats 5.1. OPEN Object This document defines a new optional TLV for use in the OPEN Object. 5.1.1. SR-SFC PCE Capability TLV The SR-SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN Object to negotiate SR-SFC capability on the PCEP session. The format of the SR-SFC-PCE-CAPABILITY TLV is shown in the following Figure 2: 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=TBD | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags | MSD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SR-SFC-PCE-CAPABILITY TLV format The code point for the TLV type is to be defined by IANA. The TLV length is 4 octets. The 32-bit value is formatted as follows. The "Maximum SID Depth" (1 octet) field (MSD) specifies the maximum number of SIDs that a PCC is capable of imposing on a packet. The "Flags" (1 octet) and "Reserved" (2 octets) fields are currently unused, and MUST be set to zero and ignored on receipt. Xu, et al. Expires April 30, 2015 [Page 7] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 5.1.1.1. Negotiating SR-SFC Capability The SR-SFC capability TLV is contained in the OPEN object. By including the TLV in the OPEN message to a PCE, a PCC indicates its support for SFPs. By including the TLV in the OPEN message to a PCC, a PCE indicates that it is capable of computing SFPs. 5.2. RP/SRP Object In order to setup an SFP, the RP or SRP object MUST carry a PATH- SETUP-TYPE TLV specified in [I-D.sivabalan-pce-lsp-setup-type]. This document defines four new Path Setup Types (PST) for SR-SFC as follows: PST = 2: The path is an SFP. PST = 3: The path is a compact SFP. PST = 4: The path is an SR-specific SFP. PST = 5: The path is a compact SR-specific SFP. 5.3. Include Route Object The IRO (Include Route Object) MUST be carried within PCReq messages to indicate a particular SFC. Furthermore, the IRO MAY be carried in PCRep messages. When carried within a PCRep message with the NO-PATH object, the IRO indicates the set of service functions that cause the PCE to fail to find a path. This document defines a new sub-object type for the SR-SFC as follows: Type Sub-object 5 Service Function ID 5.4. SR-SFC-ERO Object Generally speaking, an SR-SFC-ERO object consists of one or more ERO subobjects described in the following sub-sections to represent a particular type of service function path. In the ERO subobject, each SID is associated with an identifier that represents either a service node or a service function. This identifier is referred to as the 'Node or Service Identifier' (NSI). As described later, an NSI can be represented in various formats (e.g., IPv4 address, IPv6 address, SF identifier, etc). Specifically, in the SFP case, the NSI of every ERO subobject contained in the SR-SFC-ERO object represents a service Xu, et al. Expires April 30, 2015 [Page 8] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 node or a service function while the SID of each ERO subobject is set to null. In the compact SFP case, the NSI of every ERO subobject contained in the SR-SFC-ERO object only represents an SFF meanwhile the SID of every ERO subobject is set to null. In the SR-specific SFP, the NSI of every ERO subobject contained in the SR-SFC-ERO object represents an SFF or a service function while the SID of every ERO subject MUST NOT be null. In the compact SR-specific SFP, the NSI of every ERO subobject contained in the SR-SFC-ERO object represents an SFF meanwhile the SID of every ERO subobject MUST NOT be null. 5.4.1. SR-SFC-ERO Subobject An SR-SFC-ERO subobject (as shown in Figure 3) consists of a 32-bit header followed by the SID and the NSI associated with the SID. The SID is a 32-bit or 128 bit number. The size of the NSI depends on its respective type, as described in the following sub-sections. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | NSIT | Flags |P|F|S|C|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SID (variable:4 or 16 octets) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NSI (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: SR-SFC-ERO Subobject Format The fields in the ERO Subobject are as follows: 'L' Flag: indicates whether the subobject represents a loose-hop in the explicit route [RFC3209]. If this flag is unset, a PCC MUST not overwrite the SID value present in the SR-SFC-ERO subobject. Otherwise, a PCC MAY expand or replace one or more SID value(s) in the received SR-SFC-ERO based on its local policy. Type: is the type of the SR-SFC-ERO Subobject. This document defines the SR-SFC-ERO Subobject type. A new code point will be requested for the SR-SFC-ERO Subobject from IANA. Length: contains the total length of the subobject in octets, including the L, Type and Length fields. Length MUST be at least 4, and MUST be a multiple of 4. NSI Type (NSIT): indicates the type of NSI associated with the SID. The NSI-Type values are described later in this document. Xu, et al. Expires April 30, 2015 [Page 9] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 Flags: is used to carry any additional information pertaining to SID. Currently, the following flag bits are defined: M: When this bit is set, the SID value represents an MPLS label stack entry as specified in [RFC5462], where only the label value is specified by the PCE. Other fields (TC, S, and TTL) fields MUST be considered invalid, and PCC MUST set these fields according to its local policy and MPLS forwarding rules. C: When this bit as well as the M bit are set, then the SID value represents an MPLS label stack entry as specified in [RFC5462], where all the entry's fields (Label, TC, S, and TTL) are specified by the PCE. However, a PCC MAY choose to override TC, S, and TTL values according its local policy and MPLS forwarding rules. S: When this bit is set, the SID value in the subobject body is null. In this case, the PCC is responsible for choosing the SID value, e.g., by looking up its Traffic Engineering Database (TED) using node/service identifier in the subobject body. F: When this bit is set, the NSI value in the subobject body is null. P: When this bit is set, the SID value represents an IPv6 address. SID: is the 4-octect or 16-octect Segment Identifier NSI: contains the NSI associated with the SID. Depending on the value of NSIT, the NSI can have different format as described in the following sub-section. 5.4.2. NSI Associated with SID This document defines the following NSIs: 'IPv4 Node ID': is specified as an IPv4 address. In this case, NSIT and Length are 1 and 12 respectively. 'IPv6 Node ID': is specified as an IPv6 address. In this case, NSIT and Length are 2 and 24 respectively. 'Service Function ID': is specified as an SF ID. In this case, NSIT and Length are TBD. Xu, et al. Expires April 30, 2015 [Page 10] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 5.4.3. SR-SFC-ERO Processing TBD. 6. IANA Considerations 6.1. PCEP Objects IANA is requested to allocate an ERO subobject type (recommended value= 6) for the SR-SFC-ERO subobject. 6.2. PCEP-Error Object TBD. 6.3. PCEP TLV Type Indicators This document defines the following new PCEP TLVs: Value Meaning Reference 27 SR-SFC-PCE-CAPABILITY This document 6.4. New Path Setup Type This document defines a new setup type for the PATH-SETUP-TYPE TLV as follows: Value Description Reference 2 The path is an SFP. This document 3 The path is a compact SFP. This document 4 The path is an SR-specific SFP. This document 5 The path is a compact SR-specific SFP. This document 6.5. New IRO Sub-object Type This document defines a new IRO sub-object type for the SFC as follows: Type Sub-object 5 Service Function ID Xu, et al. Expires April 30, 2015 [Page 11] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 7. Security considerations This document does not introduce any new security considerations. 8. Acknowledgement TBD. 9. References 9.1. Normative References [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful- pce-09 (work in progress), June 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009. 9.2. Informative References [I-D.sivabalan-pce-lsp-setup-type] Sivabalan, S., Medved, J., Minei, I., Crabbe, E., and R. Varga, "Conveying path setup type in PCEP messages", draft-sivabalan-pce-lsp-setup-type-02 (work in progress), June 2014. Xu, et al. Expires April 30, 2015 [Page 12] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 [I-D.sivabalan-pce-segment-routing] Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions for Segment Routing", draft-sivabalan-pce-segment- routing-03 (work in progress), July 2014. [I-D.xu-spring-pce-based-sfc-arch] Xu, X., You, J., Shah, H., and L. Contreras, "PCE-based SFC Architecture in SR Networks", draft-xu-spring-pce- based-sfc-arch-01 (work in progress), June 2014. Authors' Addresses Xiaohu Xu Huawei Email: xuxiaohu@huawei.com Jianjie You Huawei 101 Software Avenue, Yuhuatai District Nanjing, 210012 China Email: youjianjie@huawei.com Siva Sivabalan Cisco Systems 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: msiva@cisco.com Himanshu Shah Ciena 3939 North First Street San Jose, CA 95134 USA Email: hshah@ciena.com Xu, et al. Expires April 30, 2015 [Page 13] Internet-Draft PCEP Extensions for SPRING-based SFC October 2014 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 April 30, 2015 [Page 14]