PCE Working Group Xian Zhang Internet Draft Haomian Zheng Category: Standards track Huawei Technologies Oscar Gonzales de Dios Victor Lopez Telefonica I+D Expires: July 6, 2015 July 6, 2015 Extensions to Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation draft-zhang-pce-resource-sharing-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 6, 2016. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang et al Expires January 2016 [Page 1] draft-zhang-pce-resource-sharing-04.txt July 2015 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. 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]. Abstract Resource sharing in a network means two or more Label Switched Paths (LSPs) use common piece(s) of resource along their paths. This can help save network resource and useful in scenarios such as LSP recovery or when two LSPs do not need to be active at the same time. A Path Computation Element (PCE) is a centralized entity, responsible for path computation. Given this feature and its access to the network resource information and possibly active LSPs information, it can be used to support resource-sharing-based path computation with better efficiency. This document extends the Path Computation Element Protocol (PCEP) in order to support resource sharing-based path computation. Table of Contents 1. Introduction and Motivation.................................. 3 2. Motivation .................................................. 4 2.1. Single PCE Use Case..................................... 4 2.2. Multiple PCEs Use Case.................................. 6 3. Extensions to PCEP .......................................... 8 3.1. Resource Sharing Object................................. 8 3.2. Processing Rules........................................ 9 3.3. Carrying RSO in a PCEP Message......................... 10 4. Security Considerations..................................... 11 5. IANA Considerations ........................................ 12 5.1. New Object Type........................................ 12 6. References ................................................. 12 6.1. Normative References................................... 12 Zhang et al Expires January 2016 [Page 2] draft-zhang-pce-resource-sharing-04.txt July 2015 6.2. Informative References................................. 13 7. Authors' Addresses ......................................... 13 1. Introduction and Motivation A Path Computation Element (PCE) provides an alternative way for providing path computation function, and it is especially useful in the scenarios where complex constraints and/or a demanding amount of computation resource are required [RFC4655]. The development of PCE standardization has evolved from stateless to stateful. A stateful PCE has access to the LSP database information of the network(s) it serves as a computation engine [Stateful-PCE]. Unless specified, this document assumes a PCE mentioned is a stateful PCE (either passive or active). Resource sharing denotes that two or more Label Switched Paths (LSPs) share common piece(s) of resource, (such as a common time slot of a link in an Optical Transport Network (OTN)). This is usually useful in the scenario where only one LSP is active and the benefit herein is to save network resources. A simple example of this is dynamically calculating a LSP for an existing LSP undergoing a link failure. Note that the resource sharing can be worked out using a statelss PCE, but the mechanism may be complex and is out the scope of this draft. This document considers the following requirement: new LSP may request for resource sharing with one or multiple existing LSPs. In a single domain, this is a common requirement in the recovery cases especially in order to increase traffic resilience against failure while reducing the amount of network resource used for recovery purpose [RFC4428]. The current protocol supporting the communication between a PCE and a Path Computation Client (PCC), i.e. PCE Protocol (PCEP), allows for re-optimization of an existing LSP [RFC5440]. This is achieved by setting R bit in the Request Parameter (RP) object, together with some additional information if applicable, in the Path Computation Request (PCReq) message sent from a PCC to the PCE. To support this type of resource sharing, a PCC needs to ask a PCE to compute a new path with the constraints of sharing resource with one or multiple existing LSPs. It is worth noting the 'resource sharing' in this draft not only means one LSP re-using the same link(s) of another LSP, but also the same slice of bandwidth. This may occur when an LSP is required for re-routing, or online re-optimization. Current PCEP specifications do not provide such function. More specifically, Zhang et al Expires January 2016 [Page 3] draft-zhang-pce-resource-sharing-04.txt July 2015 this draft describes the resource sharing issue during the procedure when a new LSP is required to replace an existing LSP. There are a few objects which indicate the resource sharing/disjoint relationships during path computation, such as Resource Sharing for ASSOCIATION in [RFC4873]. However, this object cannot be effectively used by PCE (not included in PCEP), which means the sharing preference may not be considered for path computation. As mentioned in [stateful-PCE], the PLSP-ID is unique during a PCEP session between PCC and PCE. Such identification is helpful in supporting the above resource sharing requirement for standardization of stateful PCEs. With a unique identifier, the configuration of PCCs is greatly simplified. Instead of determining all the resources to be shared, the PCC could request resource sharing directly from PCE. The resource sharing can also be required in an inter-layer PCEP session. This is similar to the previous requirement. However, it is more complex and therefore deserves a more detailed explanation here. In a multi-layer network, Label Switched Paths (LSPs) in a lower layer are used to carry higher-layer LSPs across the lower-layer network [RFC5623]. Therefore, the resource sharing constraints in the higher layer might actually relate to the resource sharing in the lower layer. Thus, it is useful to consider how this can be achieved and whether additional extensions are needed using the models defined in [RFC5623]. In the next sections, use cases are provided to show what information needs to be exchanged to fulfill these requirements. This memo then provides extensions to PCEP to enable this function. 2. Motivation 2.1. Single PCE Use Case Figure 1 shows a single domain network with a stateful PCE. Assume a working LSP (N1-N2-N3) exists in the network, when there is failure on the link N2-N3, it is desired to set up a restoration path for this working LSP. Suppose N1 serves as the PCC and sends a request to the stateful PCE for such an LSP. Before sending the request, N1 may need to check what policy should be applied for the path re- computation. For example, it might value resource sharing and prefer to share as much resource with the working LSP as possible and specify this policy in the PCReq message. If resources are shared between the old and new LSPs, there will be some 'interruption' when Zhang et al Expires January 2016 [Page 4] draft-zhang-pce-resource-sharing-04.txt July 2015 the traffic is switched from the old LSP to the new LSP. Here the resources to be shared among LSPs can be expressing using node, link or SRLG information. On the other hand, in some scenarios there are different policies, for example the LSP should be restored without any interruption with best effort. An example can be found in Fig. 1 without failure on N2-N3 link, instead, an online re-optimization is needed for the working LSP (N1-N2-N3) from the stateful PCE. In such cases, the best choice is to set up a backup LSP for the working LSP with totally separate routing (for example N1-N5-N4-N3), and move the traffic to that backup LSP. After that the working LSP can be torn down, which will not result in any interruption during the optimization procedure. This can actually be implemented with existing PCEP mechanism. However, if there is no such separate path, existing PCEP will reply error. A secondary option for this case is to set up an LSP and complete such re-optimization with resource sharing, even if some interruption introduced. Given the resource from the LSP to be interrupted, there may be some solutions instead of Path Compute error due to the lack of resource. A simple illustration is provided below: +--------------+ | | | Stateful PCE | | | +--------------+ +------+ +------+ +------+ | N1 +----------+ N2 +-----X----+ N3 | +--+---+ +---+--+ +---+--+ | | | | +---------+ | | | | | +------+ +------+ | +-----+ N5 +----------+ N4 +-----+ +------+ +------+ Figure 1: A Single Domain Example Available recovery paths computed by the stateful PCE: LSP1: N1-N2-N4-N3 Zhang et al Expires January 2016 [Page 5] draft-zhang-pce-resource-sharing-04.txt July 2015 LSP2: N1-N5-N4-N3 If resource sharing is preferred, the stateful PCE will reply with LSP1 information. Instead, if PCC prefer to have less interruption, PCE will reply with LSP2 information. Another piece of information that needs to be conveyed to the PCE is the information about the working path LSP. Note this simple use case assumes end-to-end recovery. But in order to be applicable to use cases such as shared mesh protection purpose, where the head-end or tail-end nodes may be different, this information is necessary in the message exchange between PCCs and PCEs, so that the stateful PCE knows which LSP the path computation request wants to share the resource. Besides, parameter changes during the resource sharing computation also need to be considered. For example, the bandwidth of the request LSP may be different with the existing LSP, while resource sharing is still preferred by the PCC. PCE should consider the sharing request together with the policy and available resource(s) in the network. Details can be found in Section 3.3. 2.2. Multiple PCEs Use Case Figure 2 shows a two-layer network example, with each layer managed by a PCE. As Discussed in Section 3 of [RFC5623], there are three models for inter-layer path computation. They are single PCE computation, multiple PCE with inter-PCE communication and multiple PCE without inter-PCE communication, respectively. For the single PCE computation, the process would be similar to that of the use case in Section 2.1. Thus, this model is not discussed further. An inter-layer path computation example is shown in Fig. 2, assume a LSP (LSP1: H2-H3) has been established already, visible as H2-H3 from view of higher-layer PCE and H2-L1-L2-H3 from the global view (or from the view of lower-layer PCE). A new request comes at H2 to establish a new LSP (LSP2: from H2 to H5), given the constraint it can share resource with LSP1. This requirement is possible if only one of the LSPs needs to be active and resource sharing is the target. If multiple PCE with inter-PCE communication model is employed, the path computation request sent by H2 to higher-layer PCE will be forwarded to lower-layer PCE since there is no resource readily available in the higher layer. So it leaves the lower-layer PCE to compute a path in the lower layer in order to support the higher layer request. In this case, lower-layer PCE is required to compute Zhang et al Expires January 2016 [Page 6] draft-zhang-pce-resource-sharing-04.txt July 2015 a path between H2 and H5 under the constraint that it can share the resource with that of the LSP1. At this moment the lower-layer PCE has the knowledge on the explicit routing that LSP1 go through (H2- L1-L2-H3). So when lower-layer PCE computes the path for LSP2, it can consider the resource used by LSP1 as available with higher priority. For example, lower-layer PCE may choose H2-L1-L2-L4-H5 as the computation result. On the other hand, if the path computation policy is to have a separate path with LSP1, the lower-layer PCE may choose H2-L1-L3-L4-H5. ----- .................................| LSR | .: | H5 | .: /----- .: / | ----- -----.: ----- -----/ | | LSR |--| LSR |.......................| LSR |--| LSR | / | H1 | | H2 | | H3 | | H4 | / ----- -----\ /----- ----- / \ / / \ / / \ / / \ / / \----- -----/ / | LSR |-| LSR | / | L1 | | L2 | / ----- -----\ / | \ / | \ / | \ / ----- \-----/ | LSR |-----------| LSR | | L3 | | L4 | ----- ----- Figure 2: A Two-layer Network Example During this procedure higher-layer PCE can only use LSP1 information (such as its five-tuple LSP information) as the information, an issue to solve is how lower-layer PCE can resolve this information to the actual resource usage in its own layer, i.e. lower layer. This could be solved by edge LSR L1 reporting this higher-lower layer LSP correlation to the lower-layer PCE as part of the LSP information during the LSP state synchronization process. If needed, it can be later updated when there is a change in this information. Alternatively, the lower-layer PCE can get this information from Zhang et al Expires January 2016 [Page 7] draft-zhang-pce-resource-sharing-04.txt July 2015 other sources, such as network management system, where this information should be stored. If multiple PCE without inter-PCE communication model is employed, the path computation request in the lower layer will be initiated the border LSR node, i.e., L1. The process would be similar to that of the previous scenario. A point worth noting is that the border LSR node may be able to resolve the higher layer LSP information itself, such as mapping it to the corresponding LSP in the lower layer, in this way lower-layer PCE does not need to perform this function. Otherwise, the mapping method mentioned above can still be used. 3. Extensions to PCEP This section provides PCEP extensions. Currently the text focuses only on passive stateful PCE and corresponding PCReq. But if active stateful PCE delegation is used, we would like to convey the same information via RSO in PCRpt. In the passive stateful PCE architecture, a PCC is allowed to specify resource sharing when sending a PCReq message. It also details the processing rule and error codes needed. 3.1. Resource Sharing Object The PCEP Resource Sharing Object (RSO) is optional. It MAY be carried within a PCReq message from the network element (or other PCCs) so as to indicate the desired resource sharing requirements to be applied by the stateful PCE during path computation. The RSO object format is compliant with the PCEP object format defined in [RFC5440]. The format of the RSO object body is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSO Flags |R|D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Optional TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: RSO Object Format The RSO Object-Class is TBA. Zhang et al Expires January 2016 [Page 8] draft-zhang-pce-resource-sharing-04.txt July 2015 The RSO Object-type is 1. RSO flags (16 bits): the objective of the resource sharing. Currently, the following objectives are defined: D (1 bit): sharing as little as possible. R (1 bit): sharing as much as possible It is possible that multiple computation results satisfy the request. Among these results, D set to 1 will select the most separate one, while R set to 1 will select the one sharing most resources. Both D and R set to 0 don't specify any constraint and will result in a random selection among these results. The combination of D=1 and R=1 is not allowed. Reserved (2 bytes): This field MUST be set to zero on transmission and MUST be ignored on receipt. Optional TLVs may be needed to indicate the LSP(s) with which the resource is shared. If multiple LSPs are required, the PCE may need to consider different sharing policies, which may result in a different computing result. The selection policy among multiple computation result is out of the scope of this draft. The LSP Info TLV, include the IPv4-LSP-IDENTIFIERS TLV and IPv6-LSP IDENTIFIERS TLV, are defined in the same way as in [stateful-pce]. 3.2. Processing Rules To request a path allowing sharing resource with one or multiple existing LSPs, a PCC includes a RSO object in the PCReq message. On receipt of a PCReq message with a RSO object, a stateful PCE MUST proceed as follows: - If the RSO object is unknown/unsupported, the PCE will follow procedures defined in [RFC5440]. That is, the PCE sends a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 1 or 2 (unknown / unsupported object class / object type), and the related path computation request is discarded. - If TLV(s) present in the RSO object are unknown/unsupported and the P bit is set, the PCE MUST send a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 4 (Unrecognized/Unsupported parameter), and the related path computation request MUST be discarded as defined in [RFC5440]. Zhang et al Expires January 2016 [Page 9] draft-zhang-pce-resource-sharing-04.txt July 2015 - If the resource sharing information is extracted correctly, the PCE MUST apply the requested resource sharing requirement. The procedure of setting R and/or D bit follows the rules defined in Section 3.1. The RSO flags may be locally configured on the requesting nodes via external entities, such as a network management system or the entity that impose the resource sharing requirement. It is worth noting that the RSO can be used together with other path indication objects like IRO/XRO. The difference is, the use of RSO is to setup an alternative path, instead a new path. It is also dependent on the knowledge of PCC, e.g., if the PCC have a full knowledge of the path information and have strong preference on the route, it may send the PCReq with IRO message to specify the route. On the other hand, if the PCC does not know how the path should go but just want to set up a new LSP to replace the old one, it may use the RSO instead of IRO. 3.3. Carrying RSO in a PCEP Message The RSO is applied to an individual path computation request and the format of the PCReq message is updated as follows: ::= [] where: ::= [] [] [] ::= [] ::= Zhang et al Expires January 2016 [Page 10] draft-zhang-pce-resource-sharing-04.txt July 2015 [] [] [] [] [[]] [] [] [] and where: ::= [] 4. Security Considerations Security of PCEP is discussed in [RFC5440] and [RFC6952]. The extensions in this document do not change the fundamentals of security for PCEP. However, the introduction of the RSO provides a vector that may be used to probe for information from a network. For example, a PCC that wants to discover the path of an LSP with which it is not involved, can issue a PCReq with an RSO and may be able to get back quite a lot of information about the path of the LSP through issuing multiple such requests for different endpoints and analyzing the received results. To protect against this, a PCE should be configured with access and authorization controls such that only authorized PCCs (for example, those within the network) can make computation requests, only specifically authorized PCCs can make requests using the RSO, and resource sharing requests relating to specific LSPs are further limited to a select few PCCs. How such access controls and authorization is managed is outside the scope of this document, but it will at the least include Access Control Lists. Furthermore, a PCC must be aware that setting up an LSP that share resources with another LSP may be a way of attacking the other LSP, for example by depriving it of the resources it needs to operate correctly. Thus it is important that, both in PCEP and the Zhang et al Expires January 2016 [Page 11] draft-zhang-pce-resource-sharing-04.txt July 2015 associated signaling protocols, only authorized resource sharing is allowed. 5. IANA Considerations 5.1. New Object Type IANA manages the PCEP Objects code point registry (see [RFC5440]). This is maintained as the "PCEP Objects" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. This document defines a new PCEP object, the RSO object, to be carried in PCReq messages. IANA is requested to make the following allocation in the ''PCEP Objects'' sub-registry: Object Name Object Name Reference Class Type ------------------------------------------------------------ TBA RSO Resource Sharing [this document] 5.2 RSO flags field IANA is requested to create and maintain a new sub-registry named ''RSO flags''. The following flags are defined in this document: Bit Flag name Description Reference 0 D sharing as little as possible [this document] 1 R sharing as much as possible [this document] 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. Zhang et al Expires January 2016 [Page 12] draft-zhang-pce-resource-sharing-04.txt July 2015 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [Stateful-PCE] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce- stateful-pce-11 (work in progress), April 2015. [RFC4873] L. Berger, I. Bryskin, D. Papadimitriou, A. Farrel, ''GMPLS Segment Recovery'', RFC4873, May 2007. 6.2. Informative References [RFC4428] Papadimitriou, D., Mannie., E., ''Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)'', RFC4428, March 2006. [RFC5623] Oki., E., Takeda, T., Le Roux, JL., Farrel, A., ''Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering'', RFC5623, September 2009. [RFC6952] Jethanandani, M., Patel, K., Zheng, L., ''Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide'', RFC6952, May 2013. 7. Authors' Addresses Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Oscar Gonzalez de Dios Telefonica I+D Don Ramon de la Cruz 82-84 Madrid 28045 Zhang et al Expires January 2016 [Page 13] draft-zhang-pce-resource-sharing-04.txt July 2015 Spain EMail: ogondio@tid.es Victor Lopez Telefonica I+D Don Ramon de la Cruz 82-84 Madrid 28045 Spain EMail: vlopez@tid.es Contributor's Address : Dhruv Dhody Huawei Technologies Email: dhruv.dhody@huawei.com Igor Bryskin ADVA Optical Email: IBryskin@advaoptical.com Zhang et al Expires January 2016 [Page 14]