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