PCE Working Group Xiaoping Zheng Internet-Draft Nan Hua Intended status: Standards Track Wangyang Liu Expires: October 27, 2016 Yinqiu Jia Yanlong Li Bingkun Zhou Tsinghua University Guoying Zhang China Academy of Telecom. Research April 27, 2016 Cooperative Stateful Path Computation Element (PCE) for Inter-Domain Inter-Vendor PCE-initiated LSP Setup draft-zheng-pce-stateful-pce-inter-domain-lsp-03.txt Abstract A stateful Path Computation Element (PCE) maintains the information of Label Switched Path (LSP) and resource availability within a domain. Multiple stateful PCEs are able to provide traffic engineering inter-domain LSPs through cooperating with each other. This document introduces the applicability of cooperative stateful PCE for establishing inter-domain inter-vendor LSPs which are initiated by PCE. 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." Zheng, et al. Expires October 27, 2016 [Page 1] Internet-Draft Cooperative Stateful PCE April 2016 This Internet-Draft will expire on October 27, 2016. 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 ................................................. 3 3. Overview of the Stateful PCE ................................ 3 4. Multiple Stateful PCEs Deployment and Operation ............. 4 4.1. Traffic Engineering Database ........................... 5 4.2. Cooperative Inter-domain Path Computation .............. 5 4.3. Cooperative Inter-domain LSP Setup ..................... 6 4.4. Vendor-specific Message Conversion ..................... 6 5. Applicability of Cooperative Stateful PCE ................... 6 5.1. TED initialization ..................................... 6 5.2. PCE-initiated LSP Setup ................................ 7 5.2.1. Inter-domain Inter-vendor LSP Setup Request ....... 7 5.2.2. Inter-domain Path Computation ..................... 7 5.2.3. Inter-domain Path Segmentation .................... 8 5.2.4. Intra-domain LSP Setup Procedure .................. 8 5.2.5. Inter-domain Inter-vendor LSP Setup Response ...... 9 5.3. TED Synchronization .................................... 9 6. Security Considerations .................................... 10 7. IANA Considerations ........................................ 10 8. Acknowledgments ............................................ 10 9. References ................................................. 10 9.1. Normative References .................................. 10 9.2. Informative References ................................ 11 10. Authors' Addresses ........................................ 11 Zheng, et al. Expires October 27, 2016 [Page 2] Internet-Draft Cooperative Stateful PCE April 2016 1. Introduction This document describes the setup procedure of PCE-initiated inter- domain inter-vendor LSPs under the cooperative stateful PCE model, which is distributed controlled and deployed. 2. Terminology This document uses the following terms defined in [RFC5440]: PCE. This document uses the following terms defined in [RFC4655]: TED. This document uses the following terms defined in [I-D.ietf-pce- stateful-pce-09]: Stateful PCE. This document uses the following terms defined in [I-D.ietf-pce-pce- initiated-lsp-02]: PCE-initiated LSP. The following terms are defined in this document: Source-PCE: PCE that covers the source node of LSP request. Destination-PCE: PCE that covers the destination node of LSP request. Upstream-PCE: The previous PCE that along the reversed direction of domain sequence. Downstream-PCE: The next PCE that along the positive direction of domain sequence. 3. Overview of the Stateful PCE [RFC4655] defines a stateful PCE to be one in which the PCE maintains "strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network." Stateful pce [I-D.ietf-pce-stateful-pce-09] specifies a set of extensions to PCEP to enable stateful control of TE LSPs between and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect LSP state synchronization between PCCs and PCEs, delegation of control of LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions and focuses on a model where LSPs are configured on the PCC and control over them is delegated to the PCE. Zheng, et al. Expires October 27, 2016 [Page 3] Internet-Draft Cooperative Stateful PCE April 2016 4. Multiple Stateful PCEs Deployment and Operation Multiple stateful PCEs can be deployed in a distributed way, shown in Figure 1. Each domain contains a single stateful PCE, which is responsible for maintaining intra-domain resource information and controlling intra-domain LSP setup. All the PCEs are mesh-connected and they may communicate with each other in a Virtual Local Area Network (VLAN). The transport devices located in different domains may be supplied by various vendors and probably own private configuration parameters, such as IP address, port attribute, signaling protocol, etc. Therefore, each domain is equipped with a dedicated Interface Adapter (IA), which can convert different vendor-specific messages into unified interface messages. Network Management System (NMS) is a centralized management entity, which is aware of entire network resources and connected with all the PCEs. NMS can initiate inter-domain LSP setup request that will be sent to the source-PCE. The inter-domain path is computed by a set of distributed PCEs that collaborate during path computation. The source PCE initiates inter- domain inter-vendor LSP setup, which is completed through cooperation between multiple PCEs. Zheng, et al. Expires October 27, 2016 [Page 4] Internet-Draft Cooperative Stateful PCE April 2016 +-------+ +----------------+ NMS +------------------+ | +----+--+ | | | | +----+---+ | +----+---+ | | | | | | PCE #1 +----------------------------------+ PCE #3 | | | | | | +----+---+ +----+---+ +----+---+ | | | | | | | +------------+ PCE #2 +------------+ | | | | | | +----+---+ | | | | +---+---+ +---+---+ +---+---+ | IA #1 | | IA #2 | | IA #3 | +---+---+ +---+---+ +---+---+ | | | | | | +-------+--------+ +-------+--------+ +-------+--------+ | | | | | | | Domain #1 | | Domain #2 | | Domain #3 | | (Vendor A) +----+ (Vendor B) +----+ (Vendor C) | | | | | | | +----------------+ +----------------+ +----------------+ Figure 1 Cooperative PCEs Deployment 4.1. Traffic Engineering Database Each PCE may collect local topology and TE information from transport plane. Besides, in order to complete inter-domain path computation, each PCE may collect all the inter-domain links and domains information from a specific management entity, such as Network Management System (NMS), which has the global visibility of network. 4.2. Cooperative Inter-domain Path Computation When source-PCE receives an inter-domain path computation request from NMS, the source-PCE will first determine an optimal domain sequence and then cooperate with other PCEs to compute an optimal inter-domain path based on the required constraints. Considering the TED information asynchronization and inter-domain resource changing during the cooperative computation procedure, each PCE in the selected domain sequence may determine a new optimal domain sequence based on the required constraints. The source-PCE will generate the full set of strict hops from source node to destination node. Zheng, et al. Expires October 27, 2016 [Page 5] Internet-Draft Cooperative Stateful PCE April 2016 4.3. Cooperative Inter-domain LSP Setup After inter-domain path computation, source-PCE splits the inter- domain path into multiple independent sub-paths according to the domain ID of each node. Then, the source-PCE simultaneously sends all the sub-paths to the relevant PCEs. Each PCE is responsible for its corresponding intra-domain LSP setup. The source-PCE asynchronously receives the intra-domain LSP setup response from all the relevant PCEs. If all the intra-domain LSPs are successfully established and there are sufficient resources in the relevant inter-domain links, the inter-domain inter-vendor LSP is successfully established. Otherwise, the inter-domain inter-vendor LSP fails to be established. 4.4. Vendor-specific Message Conversion In order to eliminate the differences in vendor-specific message formats of various vendors' domains, each domain is equipped with a dedicated Interface Adapter (IA), which can convert different vendor- specific messages into unified interface messages. 5. Applicability of Cooperative Stateful PCE 5.1. TED initialization The Traffic Engineering Database (TED) of PCE includes intra-domain information and inter-domain information, shown in Figure 2. In the process of TED initialization, every PCE sends TED request to the corresponding transport plane, which contains physical nodes and physical links. Every PCE receives TED response from the transport plane and stores the intra-domain resource information into its TED. Meanwhile, every PCE sends TED request to Network Management System (NMS), which is responsible for maintaining inter-domain links and all the PCEs in the entire network. Every PCE receives TED response from NMS and generates a global domain topology for subsequent inter- domain path computation. The domain topology stored in every PCE should be the same. Zheng, et al. Expires October 27, 2016 [Page 6] Internet-Draft Cooperative Stateful PCE April 2016 Intra-domain TED Inter-domain TED +------------> +---------+ <------------+ +------------+----+ PCE +---+------------+ | +---------+ | +---+--+ | | IA | | +---+--+ | | | | | +--------+--------+ +-----+----+ | Transport Plane | | NMS | +-----------------+ +----------+ Figure 2 TED Initialization Procedure 5.2. PCE-initiated LSP Setup 5.2.1. Inter-domain Inter-vendor LSP Setup Request The inter-domain inter-vendor LSP setup request is initiated through NMS. The request contains source node information (IP address, interface ID, timeslot), destination node information (IP address, interface ID, timeslot), required bandwidth, granularity type, protection type, and domain sequence. The request is sent to source- PCE. 5.2.2. Inter-domain Path Computation +-------------------+ | Domain Topology | | #1----#2----#3 | | | +------X------------+ X X +-----X----+ Request +--------------+ Request +-------------+ | PCE #1 | |--------> | PCE #2 | +--------> | PCE #3 | | (Source) +------------+(Intermediate)+------------+(Destination)| | | <--------+ | | <--------| | | +----------+ Response +--------------+ Response +-------------+ Figure 3 Inter-domain Path Computation Procedure In the inter-domain path computation procedure (shown in Figure 3), source-PCE computes an optimal domain sequence according to global domain topology. The domain sequence is an ordered list which contains domain IDs from source-domain to destination-domain. Zheng, et al. Expires October 27, 2016 [Page 7] Internet-Draft Cooperative Stateful PCE April 2016 Source-PCE forwards the path computation request to downstream-PCE according to the domain sequence. The downstream-PCE keeps on forwarding the path computation request to its downstream-PCE until the request is arrived at destination-PCE. Considering both the constraint requirements of request and local TED information, destination-PCE computes many candidate paths from local ingress border nodes to destination node. The path computation response (including the candidate paths) are sent to upstream-PCE according to the reversed domain sequence. If the upstream-PCE finds resource in any inter-domain link of the selected domain sequence is fully used, the upstream-PCE may determine a new optimal domain sequence including all the downstream-PCEs, based on the current TED information. The upstream-PCE generates an integrated topology including local physical topology, inter-domain links and the candidate paths derived from the downstream-PCE. The upstream-PCE computes many candidate paths from local ingress border nodes to destination node in the new integrated topology. The path computation response (including the candidate paths) and new domain sequence (if changed) are sent to its upstream-PCE. The above process is repeated until the path computation response is sent to source-PCE. Finally, the source PCE selects an optimal inter-domain path. 5.2.3. Inter-domain Path Segmentation The source-PCE splits the inter-domain path into multiple independent sub-paths according to domain ID. Different sub-path belongs to different domain. 5.2.4. Intra-domain LSP Setup Procedure In Figure 4, the source-PCE simultaneously sends all the sub-paths to the relevant PCEs. Each PCE is responsible for its corresponding intra-domain LSP setup. In the intra-domain LSP setup procedure, PCE sends intra-domain LSP setup request to local Interface Adapter (IA). IA converts the LSP setup request into vendor-specific message and then sends the message to transport plane. IA receives LSP setup response from transport plane and converts it into a unified message. PCE receives intra-domain LSP setup response from IA and the intra- domain LSP setup procedure is finished. Zheng, et al. Expires October 27, 2016 [Page 8] Internet-Draft Cooperative Stateful PCE April 2016 Response +--------> +-------+ +--+--------+----+ NMS +------------------+ | +----+--+ | | | | +----+---+ Request | +----+---+ | | +--------> | | | | PCE #1 +----------------------------------+ PCE #3 | | | <--------+ | | | +----+---+ Response | +----+---+ | | Request +----+---+ | | +^ | | +--------> | | | | +^ || | +------------+ PCE #2 +------------+ | || || | <--------+ | | | || v+ | Response +----+---+ +^ | v+ | | || | +---+---+ +---+---+ || +---+---+ | IA #1 | | IA #2 | v+ | IA #3 | +---+---+ +---+---+ +---+---+ | | | +-------+--------+ +-------+--------+ +-------+--------+ | | | | | | | Domain #1 | | Domain #2 | | Domain #3 | | (Vendor A) +----+ (Vendor B) +----+ (Vendor C) | | | | | | | +----------------+ +----------------+ +----------------+ Figure 4 Inter-domain Inter-vendor LSP Setup Procedure 5.2.5. Inter-domain Inter-vendor LSP Setup Response The source-PCE asynchronously receives the intra-domain LSP setup response from all the relevant PCEs. If all the intra-domain LSPs are successfully established and there are sufficient resources in the relevant inter-domain links, the inter-domain inter-vendor LSP is successfully established. Otherwise, the inter-domain inter-vendor LSP fails to be established. 5.3. TED Synchronization In order to avoid resource conflicts, the TED stored in every PCE must be updated in time. Once an inter-domain inter-vendor LSP is successfully established, the modification of network resources must be announced to all the relevant PCEs. TED synchronization process includes intra-domain TED synchronization process and inter-domain TED synchronization process. PCEs that are Zheng, et al. Expires October 27, 2016 [Page 9] Internet-Draft Cooperative Stateful PCE April 2016 involved to the inter-domain LSP should synchronize their intra- domain resources with underlying transport plane. And every PCE should synchronize inter-domain links to ensure that its global domain topology is identical to other PCEs. In the process of intra-domain TED synchronization, source-PCE sends intra-domain links synchronization requests to the relevant PCEs. Each relevant PCE synchronizes intra-domain links information with underlying transport plane through message conversion by local Interface Adapter (IA). In the process of inter-domain TED synchronization, source-PCE sends inter-domain links synchronization requests to all the PCEs. Every PCE should modifies the information of inter-domain links and updates its global domain topology for subsequent inter-domain path computation. 6. Security Considerations PCEP security is defined [RFC5440]. Any multi-domain operation necessarily involves the exchange of information across domain boundaries. This does represent a significant security and confidentiality risk. PCEP allows individual PCEs to maintain confidentiality of their domain path information using path-keys [RFC5520]. For further considerations of the security issues related to inter- domain path computation, see [RFC5376]. 7. IANA Considerations This document makes no requests for IANA action. 8. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 9. References 9.1. Normative References [I-D.ietf-pce-stateful-pce-09] E. Crabbe, I. Minei, J. Medved, and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful-pce- 09 (work in progress), June 2014. Zheng, et al. Expires October 27, 2016 [Page 10] Internet-Draft Cooperative Stateful PCE April 2016 [I-D.ietf-pce-pce-initiated-lsp-02] E. Crabbe, I. Minei, S. Sivabalan, and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp-02 (work in progress), October 2014. 9.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC5376] Bitar, N., et al., "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008. [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 10. Authors' Addresses Xiaoping Zheng Tsinghua University Beijing 100084 P.R.China Email: xpzheng@tsinghua.edu.cn Zheng, et al. Expires October 27, 2016 [Page 11] Internet-Draft Cooperative Stateful PCE November 2015 Nan Hua Tsinghua University Beijing 100084 P.R.China Email: huan@mail.tsinghua.edu.cn Wangyang Liu Tsinghua University Beijing 100084 P.R.China Email: liuwy06@mails.tsinghua.edu.cn Yinqiu Jia Tsinghua University Beijing 100084 P.R.China Email: jiayq13@mails.tsinghua.edu.cn Yanlong Li Tsinghua University Beijing 100084 P.R.China Email: li-yl14@mails.tsinghua.edu.cn Bingkun Zhou Tsinghua University Beijing 100084 P.R.China Email: zbk-dee@tsinghua.edu.cn Guoying Zhang Research Institute of Telecommunications Transmission (RITT), China Academy of Telecom. Research (CATR), MIIT Beijing 100084 P.R.China Email: zhangguoying@ritt.cn Zheng, et al. Expires May 2, 2016 [Page 12]