PCE Working Group Zafar Ali Internet Draft Siva Sivabalan Intended status: Standard Track Clarence Filsfils Expires: April 20, 2014 Cisco Systems Robert Varga Pantheon Technologies Victor Lopez Oscar Gonzalez de Dios Telefonica I+D Xian Zhang Huawei October 21, 2013 Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated LSP Usage draft-ali-pce-remote-initiated-lsp-usage-00.txt 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 20, 2014. Copyright Notice Copyright (c) 2013 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 Expires January 2014 [Page 1] Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract When active stateful PCE is used for managing PCE-initiated LSP, PCC may not be aware of the intended usage of the LSP (e.g., in a multi-layer network). PCEP Extensions for PCE-initiated MPLS and GMPLS LSP Setup specifications do not address this requirement. This draft addresses the requirement to specify on how PCC should use the remote initiated LSPs. Conventions used in this document 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction ..................................................3 2. Use Cases .....................................................3 2.1. Bandwidth-on-demand .......................................3 3. Remote Initiated LSP Usage Requirement ........................5 4. PCEP extension for PCEP Initiated LSP Usage Specification .....5 4.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Initiate Message ....5 4.2. Communicating LSP usage to Egress node ....................7 5. Security Considerations .......................................7 6. IANA Considerations ...........................................7 6.1. END-POINT Object ..........................................7 7. Acknowledgments ...............................................7 8. References ....................................................7 8.1. Normative References ......................................8 8.2. Informative References ....................................8 Expires January 2014 [Page 2] Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 1. Introduction [I-D. draft-crabbe-pce-pce-initiated-lsp] and [I-D. draft-ali- pce-remote-initiated-gmpls-lsp] describe the setup and teardown of PCE-initiated MPLS and GMPLS LSPs under the active stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed. However, when an active stateful PCE is used for managing remote-initiated MPLS or GMPLS LSP, the PCC may not be aware of the intended usage of the remote-initiated LSP. For example, the PCC may not know the target IGP instance in which the remote-initiated LSP is to be used. These requirements are outlined in Section 3. This draft addresses the requirement to specify on how PCC should use the PCEP initiated LSPs. This is achieved by using LSP_TUNNEL_INTERFACE_ID Object defined in [RFC6107] in PCEP, as detailed in Section 4. PCEP extensions specified in this document are equally applicable to PCEP initiated MPLS as well as GMPLS LSPs. 2. Use Cases 2.1. Bandwidth-on-demand This use case assumes there is a multi-layer network composed by routers and optical equipment. In this scenario, there is an entity, which decides it needs extra bandwidth between two routers. This certain moment a GMPLS LSP connecting both routers via the optical network can be established on-the-fly. This entity can be a router, an active stateful PCE or even the NMS (with or without human intervention). Expires January 2014 [Page 3] Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt [See PDF version of the document for Figures] Figure 1. Bandwidth on demand use case It is important to note that the bandwidth-on-demand interfaces and spare bandwidth in the optical network could be shared to cover many under capacity scenarios in the L3 network. For example, in this use-case, if we assume all interfaces are 10G and there is 10G of spare bandwidth available in the optical network, the spare bandwidth in the optical network can be used to connect any router, depending on bandwidth demand of the router network. For example, if there are three routers, it is not known a priori if the demand will make bandwidth-on-demand interface at R1 to be connected to bandwidth-on-demand interface at R2 or R3. For this reason, bandwidth-on-demand interfaces cannot be pre-provisioned with the IP services that are expected to carry. Furthermore, in this example, as active stateful PCE is used for managing PCE-initiated LSP, PCC may not be aware of the intended usage of the PCE-initiated LSP. Specifically, when the PCE1 initiated GMPLS tunnel1, PCC does not know the IGP instance whose demand leads to establishment of the GMPLS tunnel1 and hence does not know the IGP instance in which the GMPLS tunnel1 needs to be advertised. Similarly, the PCC does not know IP address that should be assigned to the GMPLS tunnel1. In the above example, this IP address is labeled as TUN-IP-R1 (tunnel IP address at R1). The PCC also does not know if the tunnel needs to be advertised as forwarding and/ or routing adjacency and/or to be locally used by the target IGP instance. Similarly, egress node for GMPLS signaling (R2 node in this example) may not know the intended usage of the tunnel (tunnel1 in this example). For example, the R2 node does not know IP address that should be assigned to the GMPLS tunnel1. In the above example, this IP address is labeled as TUN-IP-R2 Expires January 2014 [Page 4] Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt (tunnel IP address at R2). Section 4 of this draft addresses the requirement to specify on how PCC and egress node for signaling should use the remote initiated LSPs. 3. Remote Initiated LSP Usage Requirement The requirement to specify usage of the LSP to the PCC includes but not limited to specification of the following information. - The target IGP instance for the Remote-initiated LSP needs to be specified. - In the target IGP instance, should the PCE-initiated LSP be advertised as a forwarding adjacency and/ or routing adjacency and/ or to be used locally by the PCC? - Should the as Remote-initiated LSP be advertised an IPv4 FA/ RA, IPv6 FA/ RA or as unnumbered FA/ RA. - If Remote-initiated LSP is to be advertised an IPv4 FA/ RA, IPv6 FA/ RA, what is the local and remote IP address is to be used for the advertisement. 4. PCEP extension for PCEP Initiated LSP Usage Specification The requirement to specify on how PCC should use the PCEP initiated LSPs in outlined in Section 2. This subsection specifies PCEP extension used to satisfy this requirement. 4.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Initiate Message [RFC6107] defines LSP_TUNNEL_INTERFACE_ID Object for communicating usage of the forwarding or routing adjacency from the ingress node to the egress node. This document extends the LSP Initiate (PCInitiate) Message to include LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107]. Object class and type for the LSP_TUNNEL_INTERFACE_ID object are as follows: Object Name: LSP_TUNNEL_INTERFACE_ID Object-Class Value: TBA by Iana (suggested value: 40) Object-type: 1 The contents of this object are identical in encoding to the contents of the RSVP-TE LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107] and [RFC3477]. The following TLVs of RSVP-TE LSP_TUNNEL_INTERFACE_ID object are acceptable in this object. The PCEP LSP_TUNNEL_INTERFACE_ID object's TLV types correspond to RSVP-TE LSP_TUNNEL_INTERFACE_ID object's TLV types. Please Expires January 2014 [Page 5] Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt note that use of TLV type 1 defined in [RFC3477] is not specified by this document. TLV TLV Type Description Reference -- ------------------------------------------------- ---------- 2 IPv4 interface identifier with target IGP instance [RFC6107] 3 IPv6 interface identifier with target IGP instance [RFC6107] 4 Unnumbered interface with target IGP instance [RFC6107] The meanings of the fields of PCEP LSP_TUNNEL_INTERFACE_ID object are identical to those defined for the RSVP-TE LSP_TUNNEL_INTERFACE_ID object. Similarly, meanings of the fields of PCEP LSP_TUNNEL_INTERFACE_ID object's supported TLV are identical to those defined for the corresponding RSVP-TE LSP_TUNNEL_INTERFACE_ID object's TLVs. The following fields have slightly different usage. - IPv4 Interface Address field in IPv4 interface identifier with target IGP instance TLV: This field indicates the local IPv4 address to be assigned to the tunnel at the PCC (ingress node for RSVP-TE signaling). In the example use case of Section 2, IP address TUN-IP-R1 (tunnel IP address at R1) is carried in this field (if TUN-IP-R1 is a v4 address). - IPv6 Interface Address field in IPv4 interface identifier with target IGP instance TLV: This field indicates the local IPv6 address to be assigned to the tunnel at the PCC (ingress node for RSVP-TE signaling). - LSR's Router ID field in Unnumbered interface with target IGP instance: The PCC SHOULD use the LSR's Router ID in Unnumbered interface with target IGP instance in advertising the LSP being initiated by the PCE. - Interface ID (32 bits) field in unnumbered interface with target IGP instance: All bits of this field MUST be set to 0 by the PCE server and MUST be ignored by PCC. PCC SHOULD allocate an Interface ID that fulfills Interface ID requirements specified in [RFC3477]. When the Ingress PCC receives an LPS Request Message with LSP_TUNNEL_INTERFACE_ID TLV, it uses the information contained in the TLV to drive the IGP instance, treatment of the LSP being initiated in the target IGP instance (e.g., FA, RA or local usage), the local IPv4 or IPv6 address or router-id for unnumbered case to be used for advertisement of the LSP being instantiated. Expires January 2014 [Page 6] Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 4.2. Communicating LSP usage to Egress node PCE does not need to send LSP Initiate message to egress node to communicate LSP usage information. Instead PCC (Ingres signaling node) uses RSVP-TE signaling mechanism specified in [RFC6107] to send the LSP usage to Egress node. Specifically, when the Ingress PCC receives an LPS Request Message with LSP_TUNNEL_INTERFACE_ID TLV, it SHOULD add LSP_TUNNEL_INTERFACE_ID object in RSVP TE Path message. For this purpose, it is RECOMMENDED that the ingress PCC use content of the LSP_TUNNEL_INTERFACE_ID TLV in LSP Initiate Message in PCEP to drive LSP_TUNNEL_INTERFACE_ID object in RSVP-TE. This document does not modify usage of LSP_TUNNEL_INTERFACE_ID Object in RSVP-TE signaling as specified in [RFC6107]. The egress node uses information contained in the LSP_TUNNEL_INTERFACE_ID object in RSVP-TE Path message to drive the IGP instance, treatment of the LSP being initiated in the target IGP instance (e.g., FA, RA or local usage), the local IPv4 or IPv6 address or router-id for unnumbered case to be used for advertisement of the LSP being instantiated. 5. Security Considerations To be added in future revision of this document. 6. IANA Considerations 6.1. END-POINT Object This document extends the LSP Initiate Message to include LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107]. Object class and type for the LSP_TUNNEL_INTERFACE_ID object are as follows: Name Class value Type ---- ----------- ---- LSP_TUNNEL_INTERFACE_ID TBA by Iana (Suggested:40) 1 7. Acknowledgments The authors would like to thank George Swallow and Jan Medved for their comments. 8. References Expires January 2014 [Page 7] Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt 8.1. Normative References [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [I-D. draft-crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., Varga, R., "PCEP Extensions for PCE- initiated LSP Setup in a Stateful PCE Model", draft- crabbe-pce-pce-initiated-lsp, work in progress. [I-D. draft-ali-pce-remote-initiated-gmpls-lsp] Z. Ali, S. Sivabalan, C. Filsfils, R. Varga, V. Lopez, O. Dios, X. Zhang, " Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup", draft-ali-pce-remote-initiated-gmpls-lsp, work in progress. 8.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Zafar Ali Cisco Systems Email: zali@cisco.com Siva Sivabalan Cisco Systems Email: msiva@cisco.com Clarence Filsfils Cisco Systems Email: cfilsfil@cisco.com Robert Varga Pantheon Technologies Victor Lopez Telefonica I+D Email: vlopez@tid.es Oscar Gonzalez de Dios Expires January 2014 [Page 8] Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt Telefonica I+D Email: ogondio@tid.es Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Expires January 2014 [Page 9]