PCE Working Group Victor Lopez Internet Draft Oscar Gonzalez de Dios Intended status: Informational Telefonica I+D/GCTO Expires: September 20, 2016 Zafar Ali Cisco Systems Xian Zhangxian Haomian Zheng Huawei March 21, 2016 Use cases for remote-initiated LSPs via Path Computation Element Communication Protocol (PCEP) draft-lopez-pce-use-cases-initiated-pce-01.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 September 20, 2016. Copyright Notice Copyright (c) 2016 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. Expires September 2016 [Page 1] Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt 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 Thanks to the extensions defined in [I-D. draft-ietf-pce-pce- initiated-lsp] and [I-D.draft-ietf-pce-remote-initiated-gmpls-lsp], it is possible to initiate LSP Setup in a Stateful PCE Model for MPLS and GMPLS scenarios. This document complements previous documents by providing an explanation of the use cases to use such PCEP extensions. This document presents single layer and multi-layer use cases, where not only the PCE is involved, but also other modules defined in IETF, such as Virtual Network Topology Manager and Provisioning Manager. 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. Single-layer provisioning from active stateful PCE . 3 3. Bandwidth-on-demand for multi-layer networks ....... 4 3.1. Higher-layer signaling trigger ................. 5 3.2. NMS-VNTM cooperation model (separated flavor) .. 6 4. Provisioning manager in Application Based Network Operations (ABNO) ..................................... 8 5. Security Considerations ............................ 8 6. References ......................................... 8 6.1. Normative References ........................... 8 Expires September 2016 [Page 2] Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt 6.2. Informative References ......................... 9 1. Introduction The Path Computation Element communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform route computations in response to Path Computation Clients (PCCs) requests. PCEP extensions for PCE-initiated LSP setup in a stateful PCE model draft [I-D. draft-ietf-pce- stateful-pce] describes a set of extensions to PCEP to enable active control of MPLS-TE and GMPLS tunnels. [I-D. draft-crabbe-pce-pce-initiated-lsp] describes the setup and teardown of PCE-initiated 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, this specification is focused on MPLS networks, and does not cover the GMPLS networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies). 2. Single-layer provisioning from active stateful PCE Figure 1 presents a network with MPLS control plane, where a PCE intends to create a LSP from R1 to R2. The PCE sends a PCInitiate message to the source router, which can then use control plane to set up such a connection. [Please see pdf version] Figure 1. Single-layer provisioning from active stateful PCE in a MPLS domain. Similarly, Figure 2 shows a single-layer topology with optical nodes with a GMPLS control plane. In this scenario, the active PCE can dynamically instantiate or delete L0 services between client interfaces. The reason to create this connections can be a new network configuration or a re-optimization process. Expires September 2016 [Page 3] Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt [Please see pdf version] Figure 2. Single-layer provisioning from active stateful PCE in a GMPLS domain. PCEs in this scenario can obtain the resources information via control plane collecting LSAs messages or via Border Gateway Protocol - Link State (BGP-LS). The request contains, at least two interfaces, so PCE computes the path and sends a message to the optical equipment with ERO path information. 3. Bandwidth-on-demand for multi-layer networks This use case assumes there is a multi-layer network composed by routers and optical equipments. 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 Network Management System (NMS) (with or without human intervention). 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 connected to the optical nodes, 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. Expires September 2016 [Page 4] Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt According to [RFC5623], there are four options inter-layer path control models: (1) PCE-VNTM cooperation, (2) Higher-layer signaling trigger, (3) NMS-VNTM cooperation model (integrated flavor) and (4) NMS-VNTM cooperation model (separated flavor). In all scenarios there is a certain moment when entities are using an interface to request for path provisioning. In this document we have selected two use cases in a scenario with routers and optical equipments to obtain the requirements for this draft, but it is applicable to all options listed above. 3.1. Higher-layer signaling trigger Figure 3 depicts a multi-layer network scenario similar to the presented in section 4.2.2. [RFC5623], with the difference that PCE is an active stateful PCE [I-D. draft-ietf-pce-stateful- pce]. [Please see pdf version] Figure 3. Use case higher-layer signaling trigger. In this example, O1, O2 and O3 are optical nodes that are connected with router nodes R1, R2 and R3, respectively. The network is designed such that the interface between R1-O1, R2-O2 and R3-O3 are setup to provide bandwidth-on-demand via the optical network. The example assumes that an active stateful PCE is used for setting and tearing down bandwidth-on-demand connectivity. Although the simple use-case assumes a single PCE server (PCE1), the proposed technique is generalized to cover multiple co- operating PCE case. Similarly, although the use case assumes PCE1 only has knowledge of the L3 topology, the proposed technique is generalized to cover multi-layer PCE case. The PCE server (PCE1) is assumed to be receiving L3 topology data. It is also assumed that PCE learns L0 (optical) addresses Expires September 2016 [Page 5] Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt associated with bandwidth-on-demand interfaces R1-O1, R2-O2 and R3-O3. These addresses are referred by OTE-IP-R1 (optical TE link R1-O1 address at R1), OTE-IP-R2 (optical TE link R2-O2 address at R2) and OTE-IP-R3 (optical TE link R3-O3 address at R3), respectively. How PCE learns the optical addresses associated with the bandwidth-on-demand interfaces is beyond the scope of this document. How knowledge of the bandwidth-on-demand interfaces is utilized by the PCE is exemplified in the following. Suppose an application requests 8 Gbps from R1 to R2 (recall all interfaces in Figure 1 are assumed to be 10G). PCE1 satisfies this by establishing a tunnel using R1-R4-R2 path. PCEP initiated LSP using techniques specified in [I-D. draft-crabbe-pce-pce- initiated-lsp] can be used to establish a PSC tunnel using the R1-R4-R2 path. Now assume another application requests 7 Gbps service between R1 and R2. This request cannot be satisfied without establishing a GMPLS tunnel via optical network using bandwidth-on-demand interfaces. In this case, PCE1 initiates a GMPLS tunnel using R1-O1-O2-R2 path (this is referred as GMPLS tunnel1 in the following). As mentioned earlier, the GMPLS tunnel created on-the-fly to satisfy bandwidth demand of L3 applications cannot be pre- provisioned in IP network, as bandwidth-on-demand interfaces and spare bandwidth in the optical network are shared. 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 (tunnel IP address at R2). 3.2. NMS-VNTM cooperation model (separated flavor) Figure 4 depicts NMS-VNTM cooperation model. This is the separated flavor, because NMS and VNTM are not in the same location. A new L3 path is requested from NMS, because there is an automated process in the NMS or after human intervention. NMS Expires September 2016 [Page 6] Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt does not have information about all network information, so it consults L3 PCE. For shake of simplicity L3-PCE is used, but any other multi-layer cooperating PCE model is applicable. In case that there is enough resource in the L3 network, the L3-PCE returns a L3 only path. On the other hand, if there is a lack of resources at the L3 layer, the response does not have any path or may contain a multilayer path with L3 and L0 (optical) information in case of a ML-PCE. In case of there is not a path in L3; NMS sends a message to the VNTM to create a GMPLS LSP in the lower layer. When the VNTM receives this message, based on the local policies, accepts the suggestion and sends a similar message to the router, which can create the lower layer LSP via UNI signaling in the routers, like in use case in section 2.3.1. Similarly, VNTM may talk with L0-PCE to set-up the path in the optical domain (section 2.2). This second option looks more complex, because it requires VNTM configuring inter-layer TE- links. Requirements for the message from VNTM to the router are the same than in the previous use case (section 2.3.1). Regarding NMS to VNTM message, the requirements here depends on who has all the information. Three different addresses are required in this use case: (1) L3, (2) L0 and (3) inter-layer addressing. In case there is a non-cooperating L3-PCE, information about inter- layer connections have to be stored (or discovered) by VNTM. If there is a ML-PCE and this information is obtained from the network, the message would be the same as the ones in section Expires September 2016 [Page 7] Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt [Please see pdf version] Figure 4. Use case NMS-VNTM cooperation model 4. Provisioning manager in Application Based Network Operations (ABNO) The Provisioning Manager is the unit in charge of configuring the network elements in the ABNO architecture [I-D. draft- farrkingel-pce-abno-architecture]. This module receives a request from the ABNO controller or the active PCE and it can configure the resources through the data plane or by triggering a set of actions to the control plane. Therefore, the provisioning manager can require to translate from PCEP to OF, CLI or Netconf depending on the protocols supported by the nodes. [Please see pdf version] Figure 5. Provisioning the End-to-End LSP 5. Security Considerations To be added in future revision of this document. 6. References 6.1. Normative References [I-D. draft-ietf-pce-stateful-pce] E. Crabbe, I. Minei, J. Medved, R. Varga "PCEP Extensions for Stateful PCE", work in progress. Expires September 2016 [Page 8] Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt [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-ietf-pce-remote-initiated-gmpls-lsp] Z. Ali, S. Sivabalan, C. Filsfils, R. Varga, V. Lopez, O. Gonzalez de Dios, "Path Computation Element Communication Protocol (PCEP) Extensions for remote- initiated GMPLS LSP Setup", draft-ietf-pce-remote- initiated-gmpls-lsp, wrok in progress. [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009. [I-D. draft-farrkingel-pce-abno-architecture] D. King, A. Farrel "A PCE-based Architecture for Application-based Network Operations", work in progress. 6.2. Informative References Authors' Addresses Victor Lopez Telefonica I+D Email: vlopez@tid.es Oscar Gonzalez de Dios Telefonica I+D Email: ogondio@tid.es Zafar Ali Cisco Systems Email: zali@cisco.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Expires September 2016 [Page 9]