idnits 2.17.1 draft-leedhody-teas-pcep-ls-02.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 == Line 313 has weird spacing: '... ii ii/...' -- The document date (March 13, 2016) is 2959 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5307' is mentioned on line 113, but not defined == Missing Reference: 'Stateful-PCE' is mentioned on line 695, but not defined == Missing Reference: 'PCE-initiated' is mentioned on line 137, but not defined == Unused Reference: 'RFC5250' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'JMS' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'PCE-Initiated' is defined on line 700, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Y. Lee (Editor) 2 Dhruv Dhody (Editor) 3 Internet Draft Huawei 4 Intended Status: Informational 5 Expires: September 2016 Daniele Ceccarelli 6 Ericsson 8 March 13, 2016 10 Architecture and Requirement for Distribution of Link-State and TE 11 Information via PCEP. 13 draft-leedhody-teas-pcep-ls-02 15 Abstract 17 In order to compute and provide optimal paths, Path Computation 18 Elements (PCEs) require an accurate and timely Traffic Engineering 19 Database (TED). Traditionally this Link State and TE information has 20 been obtained from a link state routing protocol (supporting traffic 21 engineering extensions). 23 This document provides possible architectural alternatives for link- 24 state and TE information distribution and their potential impacts on 25 PCE, network nodes, routing protocols etc. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with 30 the provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on September 13, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction...................................................3 68 2. Applicability..................................................4 69 3. Architecture Options...........................................6 70 3.1. Option 1.1: All Nodes Send Local Link-State and TE Info to 71 all PCEs......................................................10 72 3.2. Option 1.2: Each Node Sends Local Link-State and TE Info to 73 one PCE.......................................................10 74 3.3. Option 2.1: Designated Node(s) Send Local and Remote Link- 75 State and TE Info to all PCEs.................................11 76 3.4. Key Architectural Issues.................................13 77 3.4.1. Nodes Finding PCEs..................................13 78 3.4.2. Node TE Information Update Procedures...............13 79 3.4.3. PCE Link-state (and TE) Resource Information 80 Maintenance Procedures.....................................14 81 4. Requirements for PCEP extension...............................14 82 5. New Functions to distribute link-state and TE via PCEP........14 83 6. Security Considerations.......................................15 84 7. IANA Considerations...........................................15 85 8. References....................................................15 86 8.1. Normative References.....................................15 87 8.2. Informative References...................................16 88 Author's Addresses...............................................17 90 1. Introduction 92 In Multiprotocol Label Switching (MPLS) and Generalized MPLS 93 (GMPLS), a Traffic Engineering Database (TED) is used in computing 94 paths for connection oriented packet services and for circuits. The 95 TED contains all relevant information that a Path Computation 96 Element (PCE) needs to perform its computations. It is important 97 that the TED should be complete and accurate anytime so that the PCE 98 can perform path computations. 100 In MPLS and GMPLS networks, Interior Gateway routing Protocols 101 (IGPs) have been used to create and maintain a copy of the TED at 102 each node. One of the benefits of the PCE architecture [RFC4655] is 103 the use of computationally more sophisticated path computation 104 algorithms and the realization that these may need enhanced 105 processing power not necessarily available at each node 106 participating in an IGP. 108 Section 4.3 of [RFC4655] describes the potential load of the TED on 109 a network node and proposes an architecture where the TED is 110 maintained by the PCE rather than the network nodes. However it does 111 not describe how a PCE would obtain the information needed to 112 populate its TED. PCE may construct its TED by participating in the 113 IGP ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] 114 for GMPLS). An alternative is offered by [BGP-LS]. 116 [RFC7399] touches upon this issue: "It has also been proposed that 117 the PCE Communication Protocol (PCEP) [RFC5440] could be extended to 118 serve as an information collection protocol to supply information 119 from network devices to a PCE. The logic is that the network devices 120 may already speak PCEP and so the protocol could easily be used to 121 report details about the resources and state in the network, 122 including the LSP state discussed in Sections 14 and 15." 124 [Stateful-PCE] describes a set of extensions to PCEP to provide 125 stateful control. A stateful PCE has access to not only the 126 information carried by the network's Interior Gateway Protocol 127 (IGP), but also the set of active paths and their reserved resources 128 for its computations. PCC can delegate the rights to modify the LSP 129 parameters to an Active Stateful PCE. This requires PCE to quickly 130 be updated on any changes in the Topology and TEDB, so that PCE can 131 meet the need for updating LSPs effectively and in a timely manner. 133 The fastest way for a PCE to be updated on TED changes is via a 134 direct interface with each network node and with incremental update 135 from each network node. 137 [PCE-initiated] describes the setup, maintenance and teardown of 138 PCE-initiated LSPs under the stateful PCE model, without the need 139 for local configuration on the PCC, thus allowing for a dynamic 140 network that is centrally controlled and deployed. This model 141 requires timely topology and TED update at the PCE. 143 This document proposes alternative architecture approaches for 144 learning and maintaining the Link State (and TE) information 145 directly on a PCE from network nodes as an alternative to IGPs and 146 BGP transport and investigate the impact from the PCE, routing 147 protocol, and network node perspectives. 149 2. Applicability 151 Recent development of a stateful PCE Model changes the PCE operation 152 from path computation alone to include the support of PCE-initiated 153 LSPs. With a stateful PCE model, it is also noted that LSP-DB is 154 maintained by the PCE. For LSP state synchronization of stateful 155 PCEs in GMPLS networks, the LSP attributes, such as its bandwidth, 156 associated route as well as protection information etc, should be 157 updated by PCCs to PCE LSP database (LSP-DB) [S-PCE-GMPLS]. To 158 support all these recent changes in a stateful PCE model, a direct 159 PCE interface to each PCC has to be supported. Relevant TE resource 160 and sate information can also be transported from each node to PCE 161 using this PCC-PCE interface via PCEP. Any resource changes in the 162 node and links can also be quickly updated to PCE using this 163 interface. Convergence time of IGP in GMPLS networks may not be 164 quick enough to support on-line dynamic connectivity required for 165 some applications. 167 New application areas for GMPLS and PCE in optical transport 168 networks include Wavelength Switched Optical Networking (WSON) and 169 Optical Transport Networks (OTN). WSON scenarios can be divided into 170 routing wavelength assignment (RWA) problems where a PCE requires 171 detailed information about switching node asymmetries and wavelength 172 constraints as well as detailed up to date information on wavelength 173 usage per link [RFC6163]. As more data is anticipated to be made 174 available to PCE with addition of OTN and Flex-grid and possible 175 with some optical impairment data even with the minimum set 176 specified in [G.680], the total amount of data requires 177 significantly more information to be held in the TED than is 178 required for other traffic engineered networks. Related to this 179 issue published by [HWANG] indicated that long convergence time and 180 large number of LSAs flooded in the network might cause scalability 181 problems in OSPF-TE and impose limitations on OSPF-TE applications. 183 There are two main applicability of this alternative proposed by 184 this draft: 186 o Where there is a need for a faster incremental link-state and TE 187 resource and state population and convergence at the stateful PCE. 189 . Where there is no IGP or BGP-LS running in the network nodes. 191 . Where there is IGP or BGP-LS running but with a need for a 192 faster incremental link-state (and TE) resource and state 193 population and convergence at the PCE. 195 . A PCE may receive partial Link-state (and TE) resource 196 and state information (say basic TE) from IGP-TE and 197 other information (optical and impairment) from PCEP. 199 . A PCE may receive full Link-state (and TE) resource and 200 state information from both IGP-TE and PCEP. 202 o Where there is no IGP or BGP-LS running at the PCE to learn Link- 203 state (and TE) resource and state information. 205 A PCC may further choose to send only local TE resource and state 206 information or both local and remote learned TE resource and state 207 information. How a PCE manages the TE resource and state information 208 is implementation specific and thus out of scope of this document. 210 This is also applicable for transporting (abstract) Link-State and 211 TE information from child PCE to a Parent PCE in H-PCE [RFC6805]; as 212 well as for Physical Network Controller (PNC) to Multi-Domain 213 Service Coordinator (MDSC) in Abstraction and Control of TE Networks 214 (ACTN) [ACTN]. 216 This draft does not advocate that the alternative methods specified 217 in this draft should completely replace the IGP-TE as the method of 218 creating the TED. The split between the data to be distributed via 219 an IGP-TE and the information conveyed via one of the alternatives 220 in this document depends on the nature of the network situation. One 221 could potentially choose to have some traffic engineering 222 information distributed via an IGP-TE while other more specialized 223 traffic information is only conveyed to the PCEs via an alternative 224 interface discussed here. 226 In addition, the methods specified in this draft is only relevant to 227 a set of architecture options where routing decisions are wholly or 228 partially made in the PCE. On the other hand, the networks that do 229 not support IGP-TE/BGP-LS, the method proposed by this draft may be 230 very relevant. 232 3. Architecture Options 234 (1) There are two general architectural alternatives based on how 235 nodes get their local link-state (and TE) resource information to 236 the PCEs: 238 (1.1) All Nodes send local link-state (and TE) resource 239 information to all PCEs; 241 (1.2) All Nodes send local link-state (and TE) resource 242 information to a designated PCE and have the PCEs share this 243 information with each other. 245 (2) Further, a designated node (PCC) can share both local and remote 246 link-state (and TE) information to the PCEs, the remote information 247 might be learned at the node via IGP: 249 (2.1) Designated Node(s) send local and remote link-state (and TE) 250 resource information to all PCEs; 252 An important functionality that needs to be addressed in each of 253 these approaches is how a new PCE gets initialized in a reasonably 254 timely fashion. 256 Figures 1-2 show examples of two options for nodes to share local TE 257 resource information with multiple PCEs. As in the IGP case we 258 assume that switching nodes know their local properties and state 259 including the state of all their local links. In these figures the 260 data plane links are shown with the character "o"; Link-state and TE 261 resource information flow from nodes to PCE by the characters "|", 262 "-", "/", or "\"; and PCE to PCE link-state and TE information, if 263 any, by the character "i". 265 ---- ---- 266 // \\ // \\ 267 / \ / \ 268 | PCE \ | PCE | 269 | |\ / | 270 | X \ / \ / 271 |\\ // \ \ / /|\ /X 272 | --+-\ \ \ /// | -+-- \ 273 | | \\ \ \\ // | | \ 274 | | \\ \ // | | \ 275 | | \\ \ / | | \ 276 | | \ \\ \// | | \ 277 | | \ \\ /\/ | | \ 278 | | \ /X\/\ | | \ 279 | | \ / /\ \ | | \ 280 | | X/ / \\\ | | \ 281 | | / \ / \\ | | \ 282 | | // \ / \\| | \ 283 | | / X \\\ | \ 284 | | // /\ |\\\\| \ 285 | +----+-/-+ / \ |+-\-|----+ \ 286 | | | / \ || | \ 287 | | N1 ooooooooooooooooooo N2 oo \ 288 | | ooooooooooooooooooo ooo \ 289 | | | / \ | | |ooo \ 290 | +---oo---+/ \ | +------\-+ ooo \ 291 | ooo / \ | \ ooo \ 292 | ooo / \ | \ ooo \ 293 | oo / * \ | \ ooo \ 294 | oo / \ | \ ooo \ 295 | ooo / \ | \\ ooo \ 296 | oo / * \ \ ooo \ 297 | ooo / \ \ ooo \ 298 | oo / |\ \ ooo\ 299 ++--oo-/-+ |\ * \+---oo-\-+ 300 | | | \ \ | 301 | oooo | \ oooo Nn | 302 | N3 ooooooooo +-+---\--+ ooooooooo | 303 | | ooooooooo | | oooooooooo | | 304 +--------+ oooooooo N4 oooooooo +--------+ 305 oooo oooo 306 | | 307 +--------+ 308 Figure 1 . Nodes send local Link-state and TE information directly 309 to all PCEs 311 iiiiiiiiiiiiiiiiii 312 iiiiii ---- iii iiiii ---- 313 ii ii// \\i iiiiiiii/ \\ 314 ii / \ / \ 315 i | PCE1 | | PCE2 | 316 i | | | |ii 317 i \ / X / ii 318 i \\ // // \\ // ii 319 i -//- / --+- i 320 i // // | i 321 i +-----/--+ +----/---+ | i 322 i | | | | | i 323 i | N1 ooooooooooooooooooooooooo N2 oooo | i 324 i | ooooooooooooooooooooooooo oooo | i 325 i | | | | oo | i 326 i +---oo---+ +--------+ oo | i 327 i oo oo | i 328 i oo oo | i 329 i oo * oo | i 330 i oo oo | i 331 i oo oo | i 332 i oo * oo | i 333 i oo oo | i 334 i +---oo---+ * +---oo-+-+ i 335 i | | | | i 336 i | oooo oooo Nn | i 337 i | N3 oooooooo +--------+ ooooooooo | i 338 ii | | oooooo | | ooooooooooo | | ii 339 i +---\----+ oooooooo N4 ooooooooo +--------+ i 340 i \ ooooo oooo i 341 ii \ | | i 342 i \\ +--------+ ii 343 ii \ --- i 344 ii \ ---- --- i 345 ii \// \-- i 346 ii / \ ii 347 ii | PCE3 | iiii 348 iiiii| | iiiii 349 \ / iii 350 \\ // iiiiiiiii iii 351 ---- iiiiiiiiiiiiiiiiiii 353 Figure 2 . Nodes send local Link-state and TE information to one PCE 354 and have the PCEs share TED information 356 ---- ---- 357 / \ / \ 358 / \ / \ 359 | PCE \ | PCE | 360 | --+ | 361 \ / / \ / 362 \ / / \ / 363 +-++ / ---- 364 | / 365 | / 366 | / 367 | / 368 | / 369 | / 370 | / 371 | / 372 | / 373 | / 374 | / 375 | / 376 +----+-/-+ +--------+ 377 | + | | 378 | N1 ooooooooooooooooooo N2 oo 379 | ooooooooooooooooooo ooo 380 | + | |ooo 381 +--+oo+--+ +--------+ ooo 382 ooo ooo 383 ooo ooo 384 oo ooo 385 oo ooo 386 ooo ooo 387 oo oo 388 ooo ooo 389 oo ooo 390 +---oo---+ +---oo---+ 391 | | | | 392 | oo oooo Nn | 393 | N3 ooooooooo +--------+ ooooooooo | 394 | | ooooooooo | | oooooooooo | | 395 +--------+ oooooooo N4 oooooooo +--------+ 396 oooo oooo 397 | | 398 +--------+ 400 Figure 3. Designated Node sends local and remote Link-state and TE 401 information directly to all PCEs 403 3.1. Option 1.1: All Nodes Send Local Link-State and TE Info to all 404 PCEs 406 Architectural alternative 1 shown in Figure 1 illustrates nodes 407 sending their local link-state (and TE) resource information to all 408 PCEs within their domain. As the number of PCEs grows we may have 409 scalability concerns. In particular, each node needs to keep track 410 of which PCE it has sent information to and update that information 411 periodically. However, if we are only talking about 2-3 PCEs, then 412 we do not have this scalability concern. 414 If a new PCE is added to the domain all nodes must send all its 415 local link-state and TE resource information to that PCE rather than 416 just sending status updates. 418 3.2. Option 1.2: Each Node Sends Local Link-State and TE Info to one 419 PCE 421 In this architectural alternative, shown in Figure 2, each node 422 would be associated with one PCE. This implies that each PCE will 423 only have partial link-state (and TE) resource information directly 424 from the nodes. It would be the responsibility of a node to get its 425 local information to its associated PCE, then the PCEs within a 426 domain would then need to share the partial link-state (and 427 TE)resource information they learned from their associated nodes 428 with each other so that they can create and maintain the complete 429 link-state (and TE)resource information. 431 To allow for this sharing of information PCEs would need to peer 432 with each other. PCE discovery extensions [RFC4674] could be used to 433 allow PCEs to find other PCEs. If a new PCE is added to the domain 434 it would need to peer with at least one other PCE and then PCE 435 synchronization mechanism could then be used to initialize the new 436 PCEs link-state (and TE)resource information. 438 A number of approaches can be used to ensure control plane 439 resilience in this architecture. (1) Each node can be configured 440 with a primary and a secondary PCE to send its information to; In 441 case of failure of communications with the primary PCE the node 442 would send its information to a secondary PCE (warm standby). (2) 443 Each node could be configured to send its information to two 444 different PCEs (hot standby). 446 3.3. Option 2.1: Designated Node(s) Send Local and Remote Link-State 447 and TE Info to all PCEs 449 In this architectural alternative, shown in Figure 3, illustrates 450 designated node(s) sending their local and remote link-state (and 451 TE) resource information to all PCEs within their domain. Designated 452 Node may learn remote information via IGP or BGP-LS. More than one 453 designated node may be used to ensure control plane resilience in 454 this architecture. 456 3.4. Hierarchy of PCE 458 Incase of H-PCE [RFC6805], a parent PCE can utilize the mechanism 459 described in this document to prepare the domain topology map by 460 transporting inter-domain link information from child PCE to Parent 461 PCE. 463 !!!!!!!!!!!!!! 464 ! Parent PCE ! 465 !!!!!!!!!!!!!! 466 / | | \ 467 / | | \ 468 / | | \ 469 / | | \ 470 / | \ \ 471 / | \ | 472 / | \ \ 473 / | | \ 474 / | | \ 475 / +----|------+ | \ 476 / | ~~|~~~ | | \ 477 / | ~PCE2~ | | \ 478 / | ~~~~~~ | | \ 479 / | Domain 2 | | \ 480 | | | | +-----\----+ 481 | +-----------+ | | ~~~~\~ | 482 / | | ~PCE4~ | 483 +---/------+ | | ~~~~~~ | 484 | /~~~~~ | | | Domain 4 | 485 | ~PCE1~ | | | | 486 | ~~~~~~ | | +----------+ 487 | Domain 1 | | 488 | | +-------|---+ 489 +----------+ | ~~~~~| | 490 | ~PCE3~ | 491 | ~~~~~~ | 492 | Domain 3 | 493 | | 494 +-----------+ 496 Figure 4. Child PCE sends some Link-state and TE information to 497 Parent PCE 499 Further abstracted topology information can be transported from PNC 500 to MDSC in ACTN [ACTN] using this technique described in this 501 document. 503 3.5. Key Architectural Issues 505 3.5.1. Nodes Finding PCEs 507 In all cases, nodes need to send TE information directly to PCEs. 508 Path Computation Clients (PCCs) and network nodes participating in 509 an IGP (with or without TE extensions) have a mechanism to discover 510 a PCE and its capabilities. [RFC4674] outlines the general 511 requirements for this mechanism and extensions have been defined to 512 provide information so that PCCs can obtain key details about 513 available PCEs in OSPF [RFC5088] and in IS-IS [RFC5089]. 515 After finding candidate PCEs, a node would need to see which if any 516 of the PCEs actually want to receive TE information directly from 517 this node. 519 3.5.2. Node TE Information Update Procedures 521 First a node must establish an association between itself and a PCE 522 that will be maintaining a link-state and TE information. It is the 523 responsibility of the node to share link-state (and TE) information. 524 This includes local information, e.g., links and node properties or 525 remote information learned from neighbors. General and technology 526 specific information models would specify the content of this 527 information while the specific protocols would determine the format. 528 Note that data plane neighbor information would be passed to the PCE 529 embedded in TE link information. 531 There will be cases where the node would have to send to the PCE 532 only a subset of TE link information depending on the path 533 computation option. For instance, if the node is responsible for 534 routing while the PCE is responsible for wavelength assignment for 535 the route, the node would only need to send the PCE the WSON link 536 usage information. This path computation option is referred to as 537 separate Fouting (R) and Wavelength Assignment (WA) option in 538 [RFC7449]. 540 3.5.3. PCE Link-state (and TE) Resource Information Maintenance 541 Procedures 543 The PCE is responsible for creating and maintaining the link-state 544 (and TE) resource information that it will use. Key functions 545 include: 547 1. Establishing and authenticating communications between the PCE 548 and sources of link-state (and TE) resource information. 550 2. Timely updates of the link-state (and TE) resource with 551 information received from nodes, peers or other entities. 553 3. Verifying the validity of link-state (and TE) resource 554 information, i.e., ensure that the network information obtained 555 from nodes or elsewhere is relatively timely, or not stale. By 556 analogy with similar functionality provided by IGPs this can be 557 done via a process where discrete "chunks" of TE resource 558 information are "aged" and discard when expired. This combined 559 with nodes periodically resending their local TE resource 560 information leads to a timely update of TE resource 561 information. 563 4. Requirements for PCEP extension 565 The key requirements associated with link-state (and TE) 566 distribution are identified for PCEP and listed in [PCEP-LS]. 568 These new functions required in PCEP to support distribution of 569 link-state (and TE) information are described in [PCEP-LS]. 571 5. New Functions to distribute link-state and TE via PCEP 573 Several new functions are required in PCEP to support distribution 574 of link-state and TE information. The new functions are: 576 o Capability advertisement: Advertise capability for link-state and 577 TE information distribution 579 o Link-State and TE synchronization: Ability to synchronize the 580 Link-state and TE information after session initialization. 582 o Link-State and TE Report (C-E): a PCC sends a LS and TE report to 583 a PCE whenever the Link-State and TE information changes. 585 These are listed in some detail in [PCEP-LS]. 587 6. Security Considerations 589 This draft discusses an alternative technique for PCEs to build and 590 maintain a link-state and traffic engineering database. In this 591 approach network nodes would directly send traffic engineering 592 information to a PCE. It may be desirable to protect such 593 information from disclosure to unauthorized parties in addition it 594 may be desirable to protect such communications from interference 595 (modification) since they can be critical to the operation of the 596 network. In particular, this information is the same or similar to 597 that which would be disseminated via a link state routing protocol 598 with traffic engineering extensions. 600 7. IANA Considerations 602 This version of this document does not introduce any items for IANA 603 to consider. 605 8. References 607 8.1. Normative References 609 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 610 Computation Element (PCE)-Based Architecture", RFC 4655, 611 August 2006. 613 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 614 Element (PCE) Discovery", RFC 4674, October 2006. 616 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 617 Zhang, "OSPF Protocol Extensions for Path Computation 618 Element (PCE) Discovery", RFC 5088, January 2008. 620 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 621 Zhang, "IS-IS Protocol Extensions for Path Computation 622 Element (PCE) Discovery", RFC 5089, January 2008. 624 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 625 OSPF Opaque LSA Option", RFC 5250, July 2008. 627 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 628 Engineering", RFC 5305, October 2008. 630 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 631 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 632 March 2009. 634 8.2. Informative References 636 [JMS] Java Message Service, Version 1.1, April 2002, Sun 637 Microsystems. 639 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 640 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 641 September 2003. 643 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions 644 in Support of Generalized Multi-Protocol Label Switching 645 (GMPLS)", RFC 4203, October 2005. 647 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 648 Element (PCE)-Based Architecture", RFC 4655, August 2006. 650 [BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and 651 S.Ray, "North-Bound Distribution of Link-State and TE 652 information using BGP", draft-ietf-idr-ls-distribution, 653 work in progress. 655 [S-PCE-GMPLS] X. Zhang, et. al, "Path Computation Element (PCE) 656 Protocol Extensions for Stateful PCE Usage in GMPLS- 657 controlled Networks", draft-ietf-pce-pcep-stateful-pce- 658 gmpls, work in progress. 660 [RFC7399] A. Farrel and D. king, "Unanswered Questions in the Path 661 Computation Element Architecture", RFC 7399, October 2015. 663 [RFC7449] Y. Lee, G. Bernstein, "Path Computation Element 664 Communication Protocol (PCEP) Requirements for Wavelength 665 Switched Optical Network (WSON) Routing and Wavelength 666 Assignment", RFC 7449, February 2015. 668 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 669 Reflection: An Alternative to Full Mesh Internal BGP 670 (IBGP)", RFC 4456, April 2006. 672 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 673 and PCE Control of Wavelength Switched Optical Networks", 674 RFC 6163, 676 [HWANG] S. Hwang, et al, "An Experimental Analysis on OSPF-TE 677 Convergence Time", Proc. SPIE 7137, Network Architectures, 678 Management, and Applications, November 19, 2008. 680 [G.680] ITU-T Recommendation G.680, Physical transfer functions of 681 optical network elements, July 2007. 683 [ACTN] Y. Lee, D. Dhody, S. Belotti, K. Pithewan, and D. Ceccarelli, 684 "Requirements for Abstraction and Control of TE Networks", 685 draft-ietf-teas-actn-requirements, work in progress, 686 October 1, 2015. 688 [RFC6805] A. Farrel and D. King, "The Application of the Path 689 Computation Element Architecture to the Determination of a 690 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 691 2012. 693 [PCEP-LS] D. Dhody, Y. Lee and D. Ceccarelli "PCEP Extension for 694 Distribution of Link-State and TE Information.", work in 695 progress, September 21, 2015[Stateful-PCE] Crabbe, E., 696 Minei, I., Medved, J., and R. Varga, "PCEP Extensions for 697 Stateful PCE", draft-ietf-pce-stateful-pce, work in 698 progress. 700 [PCE-Initiated] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, 701 "PCEP Extensions for PCE-initiated LSP Setup in a Stateful 702 PCE Model", draft-ietf-pce-pce-initiated-lsp, work in 703 progress. 705 Author's Addresses 707 Young Lee (Editor) 708 Huawei Technologies 709 5340 Legacy Drive, Building 3 710 Plano, TX 75023, USA 712 Email: leeyoung@huawei.com 713 Dhruv Dhody (Editor) 714 Huawei Technologies 715 Divyashree Technopark, Whitefield 716 Bangalore, Karnataka 560037 717 India 719 EMail: dhruv.ietf@gmail.com 721 Daniele Ceccarelli 722 Ericsson 723 Torshamnsgatan,48 724 Stockholm 725 Sweden 727 EMail: daniele.ceccarelli@ericsson.com 729 Haomian Zheng 730 Huawei Technologies Co., Ltd. 731 F3-1-B R&D Center, Huawei Base, 732 Bantian, Longgang District 733 Shenzhen 518129 P.R.China 735 Email: zhenghaomian@huawei.com 737 Xian Zhang 738 Huawei Technologies Co., Ltd. 739 F3-1-B R&D Center, Huawei Base, 740 Bantian, Longgang District 741 Shenzhen 518129 P.R.China 743 Email: zhangxian@huawei.com