idnits 2.17.1 draft-ietf-pce-stateful-pce-inter-domain-lsp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 27, 2014) is 3466 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-pce-pce-initiated-lsp-02' is defined on line 426, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-09 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Xiaoping Zheng 3 Internet-Draft Nan Hua 4 Intended status: Standards Track Wangyang Liu 5 Expires: April 27, 2015 Bingkun Zhou 6 Tsinghua University 7 Guoying Zhang 8 China Academy of Telecom. Research 9 October 27, 2014 11 Cooperative Stateful Path Computation Element (PCE) 12 for Inter-Domain Inter-Vendor PCE-initiated LSP Setup 13 draft-ietf-pce-stateful-pce-inter-domain-lsp-00.txt 15 Abstract 17 A stateful Path Computation Element (PCE) maintains the information 18 of Label Switched Path (LSP) and resource availability within a 19 domain, so multiple stateful PCEs are able to provide traffic 20 engineering inter-domain routing through cooperating with each other. 21 This document introduces the applicability of cooperative stateful 22 PCE for establishing inter-domain inter-vendor LSP which is initiated 23 by PCE. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 27, 2015. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Overview of the Stateful PCE . . . . . . . . . . . . . . . . 3 68 4. Multiple Stateful PCEs Deployment and Operation . . . . . . 4 69 4.1. Traffic Engineering Database . . . . . . . . . . . . . . 5 70 4.2. Cooperative Inter-domain Path Computation . .. . . . . . 5 71 4.3. Cooperative Inter-domain LSP Setup . . . . . . . . . . . 6 72 4.4. Vendor-specific Message Conversion . . . . . . . . . . . 6 73 5. Applicability of Cooperative Stateful PCE . . . . . . . . . 6 74 5.1. TED initialization . . . . . . . . . . . . . . . . . . . 6 75 5.2. PCE-initiated LSP Setup . . . . . . . . . . . . . . . . . 7 76 5.2.1. Inter-domain Inter-vendor LSP Setup Request . . . . . 7 77 5.2.2. Inter-domain Path Computation . . . . . . . . . . . . 7 78 5.2.3. Inter-domain Path Segmentation . . . . . . . . . . . 8 79 5.2.4. Intra-domain LSP Setup Procedure . . . . . .. . . . . 8 80 5.2.5. Inter-domain Inter-vendor LSP Setup Response . . . . 9 81 5.3. TED Synchronization . . . . . . . . . . . . . . . . . . . 9 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 9.2. Informative References . . . . . . . . . . . . . . . . . 11 88 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 This document describes the setup of PCE-initiated inter-domain 93 inter-vendor LSPs under the cooperative stateful PCE model, which is 94 distributed controlled and deployed. 96 2. Terminology 98 This document uses the following terms defined in [RFC5440]: PCE. 100 This document uses the following terms defined in [RFC4655]: TED. 102 This document uses the following terms defined in [I-D.ietf-pce- 103 stateful-pce-09]: Stateful PCE. 105 This document uses the following terms defined in [I-D.ietf-pce-pce- 106 initiated-lsp-02]: PCE-initiated LSP. 108 The following terms are defined in this document: 110 Source-PCE: PCE that covers the source node of LSP request. 112 Destination-PCE: PCE that covers the destination node of LSP request. 114 Upstream-PCE: The previous PCE that along the reversed direction of 115 domain sequence. 117 Downstream-PCE: The next PCE that along the positive direction of 118 domain sequence. 120 3. Overview of the Stateful PCE 122 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 123 "strict synchronization between the PCE and not only the network 124 states (in term of topology and resource information), but also the 125 set of computed paths and reserved resources in use in the network." 127 Stateful pce [I-D.ietf-pce-stateful-pce-09] specifies a set of 128 extensions to PCEP to enable stateful control of TE LSPs between and 129 across PCEP sessions in compliance with [RFC4657]. It includes 130 mechanisms to effect LSP state synchronization between PCCs and PCEs, 131 delegation of control of LSPs to PCEs, and PCE control of timing and 132 sequence of path computations within and across PCEP sessions and 133 focuses on a model where LSPs are configured on the PCC and control 134 over them is delegated to the PCE. 136 4. Multiple Stateful PCEs Deployment and Operation 138 Multiple stateful PCEs can be deployed in a distributed architecture, 139 shown in Figure 1. Each domain contains a single stateful PCE, which 140 is responsible for maintaining intra-domain resource information and 141 controlling intra-domain LSP setup. All the PCEs are mesh-connected 142 and they may communicate with each other in a Virtual Local Area 143 Network (VLAN). 145 The transport devices located in different domains may be supplied by 146 various vendors and probably own private configuration parameters, 147 such as IP address, port attribute, signaling protocol, etc. 148 Therefore, each domain is equipped with a dedicated Interface Adapter 149 (IA), which can convert different vendor-specific messages into 150 unified interface messages. 152 Network Management System (NMS) is a centralized management entity, 153 which is aware of entire network resources and connected with all the 154 PCEs. NMS can initiate inter-domain LSP setup request that will be 155 sent to the source-PCE. 157 The inter-domain path is computed by a set of distributed PCEs that 158 collaborate during path computation. The source PCE initiates inter- 159 domain inter-vendor LSP setup, which is completed through cooperation 160 between multiple PCEs. 162 +-------+ 163 +----------------+ NMS +------------------+ 164 | +----+--+ | 165 | | | 166 +----+---+ | +----+---+ 167 | | | | | 168 | PCE #1 +----------------------------------+ PCE #3 | 169 | | | | | 170 +----+---+ +----+---+ +----+---+ 171 | | | | | | 172 | +------------+ PCE #2 +------------+ | 173 | | | | 174 | +----+---+ | 175 | | | 176 +---+---+ +---+---+ +---+---+ 177 | IA #1 | | IA #2 | | IA #3 | 178 +---+---+ +---+---+ +---+---+ 179 | | | 180 | | | 181 +-------+--------+ +-------+--------+ +-------+--------+ 182 | | | | | | 183 | Domain #1 | | Domain #2 | | Domain #3 | 184 | (Vendor A) +----+ (Vendor B) +----+ (Vendor C) | 185 | | | | | | 186 +----------------+ +----------------+ +----------------+ 188 Figure 1 Cooperative PCEs Deployment 190 4.1. Traffic Engineering Database 192 Each PCE may collect local topology and TE information from transport 193 plane. Besides, in order to complete inter-domain path computation, 194 each PCE may collect all the inter-domain links and domains 195 information from a specific management entity, such as Network 196 Management System (NMS), which has the global visibility of network. 198 4.2. Cooperative Inter-domain Path Computation 200 When source-PCE receives an inter-domain path computation request 201 from NMS, the source-PCE will first determine an optimal domain 202 sequence and then cooperate with other PCEs to compute an optimal 203 inter-domain path based on the required constraints. The source-PCE 204 will generate the full set of strict hops from source node to 205 destination node. 207 4.3. Cooperative Inter-domain LSP Setup 209 After inter-domain path computation, source-PCE splits the inter- 210 domain path into multiple independent sub-paths according to domain 211 ID. Then, the source-PCE simultaneously sends all the sub-paths to 212 the relevant PCEs. Each PCE is responsible for its corresponding 213 intra-domain LSP setup. 215 The source-PCE asynchronously receives the intra-domain LSP setup 216 response from all the relevant PCEs. If all the intra-domain LSPs are 217 successfully established and there are sufficient resources in the 218 relevant inter-domain links, the inter-domain inter-vendor LSP is 219 successfully established. Otherwise, the inter-domain inter-vendor 220 LSP fails to be established. 222 4.4. Vendor-specific Message Conversion 224 In order to eliminate the differences in vendor-specific message 225 formats of various vendors' domains, each domain is equipped with a 226 dedicated Interface Adapter (IA), which can convert different vendor- 227 specific messages into unified interface messages. 229 5. Applicability of Cooperative Stateful PCE 231 5.1. TED initialization 233 The Traffic Engineering Database (TED) of PCE includes intra-domain 234 information and inter-domain information, shown in Figure 2. 236 In the process of TED initialization, every PCE sends TED request to 237 the corresponding transport plane, which contains physical nodes and 238 physical links. Every PCE receives TED response from the transport 239 plane and stores the intra-domain resource information into its TED. 241 Meanwhile, every PCE sends TED request to Network Management System 242 (NMS), which is responsible for maintaining inter-domain links and 243 all the PCEs in the entire network. Every PCE receives TED response 244 from NMS and generates a global domain topology for subsequent inter- 245 domain path computation. The domain topology stored in every PCE 246 should be the same. 248 Intra-domain TED Inter-domain TED 249 +------------> +---------+ <------------+ 250 +------------+----+ PCE +---+------------+ 251 | +---------+ | 252 +---+--+ | 253 | IA | | 254 +---+--+ | 255 | | 256 | | 257 +--------+--------+ +-----+----+ 258 | Transport Plane | | NMS | 259 +-----------------+ +----------+ 261 Figure 2 TED Initialization Procedure 263 5.2. PCE-initiated LSP Setup 265 5.2.1. Inter-domain Inter-vendor LSP Setup Request 267 The inter-domain inter-vendor LSP setup request is initiated through 268 NMS. The request contains source node information (IP address, 269 interface ID, timeslot), destination node information (IP address, 270 interface ID, timeslot), required bandwidth, granularity type, 271 protection type, and domain sequence. The request is sent to source- 272 PCE. 274 5.2.2. Inter-domain Path Computation 276 +-------------------+ 277 | Domain Topology | 278 | #1----#2----#3 | 279 | | 280 +------X------------+ 281 X 282 X 283 +-----X----+ Request +--------------+ Request +-------------+ 284 | PCE #1 | |--------> | PCE #2 | +--------> | PCE #3 | 285 | (Source) +------------+(Intermediate)+------------+(Destination)| 286 | | <--------+ | | <--------| | | 287 +----------+ Response +--------------+ Response +-------------+ 289 Figure 3 Inter-domain Path Computation Procedure 291 In the inter-domain path computation procedure (shown in Figure 3), 292 source-PCE computes an optimal domain sequence according to global 293 domain topology. The domain sequence is an ordered list which 294 contains domain IDs from source-domain to destination-domain. 296 Source-PCE forwards the path computation request to downstream-PCE 297 according to the domain sequence. The downstream-PCE keeps on 298 forwarding the path computation request to its downstream-PCE until 299 the request is arrived at destination-PCE. 301 Considering both the constraint requirements of request and local TED 302 information, destination-PCE computes many candidate paths from local 303 ingress border nodes to destination node. The path computation 304 response (including the candidate paths) are sent to upstream-PCE 305 according to the reversed domain sequence. The upstream-PCE generates 306 an integrated topology including local physical topology, inter- 307 domain links and the candidate paths derived from the downstream-PCE. 308 The upstream-PCE computes many candidate paths from local ingress 309 border nodes to destination node in the new integrated topology. The 310 path computation response (including the candidate paths) are sent to 311 its upstream-PCE. The above process is recursive until the path 312 computation response is arrived at source-PCE. Finally, the source 313 PCE selects an optimal inter-domain path. 315 5.2.3. Inter-domain Path Segmentation 317 The source-PCE splits the inter-domain path into multiple independent 318 sub-paths according to domain ID. Different sub-path belongs to 319 different domain. 321 5.2.4. Intra-domain LSP Setup Procedure 323 In Figure 4, the source-PCE simultaneously sends all the sub-paths to 324 the relevant PCEs. Each PCE is responsible for its corresponding 325 intra-domain LSP setup. In the intra-domain LSP setup procedure, PCE 326 sends intra-domain LSP setup request to local Interface Adapter (IA). 327 IA converts the LSP setup request into vendor-specific message and 328 then sends the message to transport plane. IA receives LSP setup 329 response from transport plane and converts it into a unified message. 330 PCE receives intra-domain LSP setup response from IA and the intra- 331 domain LSP setup procedure is finished. 333 Response 334 +--------> +-------+ 335 +--+--------+----+ NMS +------------------+ 336 | +----+--+ | 337 | | | 338 +----+---+ Request | +----+---+ 339 | | +--------> | | | 340 | PCE #1 +----------------------------------+ PCE #3 | 341 | | <--------+ | | | 342 +----+---+ Response | +----+---+ 343 | | Request +----+---+ | | ? 344 +^ | | +--------> | | | | +^ 345 || | +------------+ PCE #2 +------------+ | || 346 || | <--------+ | | | || 347 v+ | Response +----+---+ +^ | v+ 348 | | || | 349 +---+---+ +---+---+ || +---+---+ 350 | IA #1 | | IA #2 | v+ | IA #3 | 351 +---+---+ +---+---+ +---+---+ 352 | | | 353 +-------+--------+ +-------+--------+ +-------+--------+ 354 | | | | | | 355 | Domain #1 | | Domain #2 | | Domain #3 | 356 | (Vendor A) +----+ (Vendor B) +----+ (Vendor C) | 357 | | | | | | 358 +----------------+ +----------------+ +----------------+ 360 Figure 4 Inter-domain Inter-vendor LSP Setup Procedure 362 5.2.5. Inter-domain Inter-vendor LSP Setup Response 364 The source-PCE asynchronously receives the intra-domain LSP setup 365 response from all the relevant PCEs. If all the intra-domain LSPs are 366 successfully established and there are sufficient resources in the 367 relevant inter-domain links, the inter-domain inter-vendor LSP is 368 successfully established. Otherwise, the inter-domain inter-vendor 369 LSP fails to be established. 371 5.3. TED Synchronization 373 In order to avoid resource conflicts, the TED stored in every PCE 374 must be updated in time. Once an inter-domain inter-vendor LSP is 375 successfully established, the modification of network resources must 376 be announced to all the relevant PCEs. 378 TED synchronization process includes intra-domain TED synchronization 379 process and inter-domain TED synchronization process. PCEs that are 380 involved to the inter-domain LSP should synchronize their intra- 381 domain resources with underlying transport plane. And every PCE 382 should synchronize inter-domain links to ensure that its global 383 domain topology is identical to other PCEs. 385 In the process of intra-domain TED synchronization, source-PCE sends 386 intra-domain links synchronization requests to the relevant PCEs. 387 Each relevant PCE synchronizes intra-domain links information with 388 underlying transport plane through message conversion by local 389 Interface Adapter (IA). 391 In the process of inter-domain TED synchronization, source-PCE sends 392 inter-domain links synchronization requests to all the PCEs. Every 393 PCE should modifies the information of inter-domain links and updates 394 its global domain topology for subsequent inter-domain path 395 computation. 397 6. Security Considerations 399 PCEP security is defined [RFC5440]. Any multi-domain operation 400 necessarily involves the exchange of information across domain 401 boundaries. This does represent a significant security and 402 confidentiality risk. PCEP allows individual PCEs to maintain 403 confidentiality of their domain path information using path-keys 404 [RFC5520]. 406 For further considerations of the security issues related to inter- 407 domain path computation, see [RFC5376]. 409 7. IANA Considerations 411 This document makes no requests for IANA action. 413 8. Acknowledgements 415 This document was prepared using 2-Word-v2.0.template.dot. 417 9. References 419 9.1. Normative References 421 [I-D.ietf-pce-stateful-pce-09] 422 E. Crabbe, I. Minei, J. Medved, and R. Varga, "PCEP 423 Extensions for Stateful PCE", draft-ietf-pce-stateful-pce- 424 09 (work in progress), June 2014. 426 [I-D.ietf-pce-pce-initiated-lsp-02] 427 E. Crabbe, I. Minei, S. Sivabalan, and R. Varga, "PCEP 428 Extensions for PCE-initiated LSP Setup in a Stateful PCE 429 Model", draft-ietf-pce-pce-initiated-lsp-02 (work in 430 progress), October 2014. 432 9.2. Informative References 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 438 Element (PCE)-Based Architecture", RFC 4655, August 2006. 440 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 441 Communication Protocol Generic Requirements", RFC 4657, 442 September 2006. 444 [RFC5376] Bitar, N., et al., "Inter-AS Requirements for the Path 445 Computation Element Communication Protocol (PCECP)", RFC 446 5376, November 2008. 448 [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, A., 449 Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path 450 Computation Element (PCE) Communication Protocol (PCEP)", 451 RFC 5440, March 2009. 453 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving 454 Topology Confidentiality in Inter-Domain Path Computation 455 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 457 10. Authors' Addresses 459 Xiaoping Zheng 460 Tsinghua University 461 Beijing 100084 462 P.R.China 464 Email: xpzheng@tsinghua.edu.cn 465 Nan Hua 466 Tsinghua University 467 Beijing 100084 468 P.R.China 470 Email: huan@mail.tsinghua.edu.cn 472 Wangyang Liu 473 Tsinghua University 474 Beijing 100084 475 P.R.China 477 Email: liuwy06@mails.tsinghua.edu.cn 479 Bingkun Zhou 480 Tsinghua University 481 Beijing 100084 482 P.R.China 484 Email: zbk-dee@tsinghua.edu.cn 486 Guoying Zhang 487 Research Institute of Telecommunications Transmission (RITT), 488 China Academy of Telecom. Research (CATR), MIIT 489 Beijing 100084 490 P.R.China 492 Email: zhangguoying@ritt.cn