idnits 2.17.1 draft-lee-pce-transporting-te-data-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 67 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 440 has weird spacing: '... ii ii/...' -- The document date (October 24, 2014) is 3472 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3630' is mentioned on line 103, but not defined == Missing Reference: 'RFC5305' is mentioned on line 103, but not defined == Missing Reference: 'RFC4203' is mentioned on line 103, but not defined == Missing Reference: 'RFC5307' is mentioned on line 103, but not defined == Missing Reference: 'Reference' is mentioned on line 140, but not defined == Missing Reference: 'G.680' is mentioned on line 141, but not defined == Missing Reference: 'WSON-Info' is mentioned on line 643, but not defined == Outdated reference: A later version (-06) exists of draft-bernstein-wson-impairment-info-02 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Y. Lee 2 Internet Draft Huawei 3 Intended Status: Informational 4 H. Zheng 5 Huawei 7 October 24, 2014 8 Expires: January 2015 10 PCE in Support of Transporting Traffic Engineering Data 12 draft-lee-pce-transporting-te-data-01.txt 14 Abstract 16 In order to compute and provide optimal paths, Path Computation 17 Elements (PCEs) require an accurate and timely Traffic Engineering 18 Database (TED). Traditionally this TED has been obtained from a link 19 state routing protocol supporting traffic engineering extensions. 20 This document discusses possible alternatives and enhancements to 21 the existing approach to TED creation. This document gives 22 architectural alternatives for these alternatives and their 23 potential impacts on network nodes, routing protocols, and PCEP. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress. 40 This Internet-Draft will expire on April 24, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction...................................................2 59 1.1. TED Creation and Maintenance via IGP-TEs..................5 60 2. Alternative TED Creation & Maintenance for a PCE...............6 61 2.1. Architecture Options......................................8 62 2.1.1. Nodes Send TE Info to all PCEs......................12 63 2.1.2. Nodes Send TE Info via an Intermediate System.......12 64 2.1.3. Nodes Send TE Info to At Least One PCE..............13 65 2.2. Nodes Finding PCEs.......................................13 66 2.3. Node TE Information Update Procedures....................14 67 2.4. PCE TED Maintenance Procedures...........................14 68 3. Standardization and Protocol Considerations...................15 69 3.1. Architecture Specific Standardization Aspects............16 70 4. Security Considerations.......................................16 71 5. IANA Considerations...........................................17 72 6. Conclusions...................................................17 73 7. Acknowledgments...............................................17 74 8. References....................................................17 75 8.1. Normative References.....................................17 76 8.2. Informative References...................................18 77 Author's Addresses...............................................19 78 Disclaimer of Validity...........................................20 80 1. Introduction 82 In Multiprotocol Label Switching (MPLS) and Generalized MPLS 83 (GMPLS), a Traffic Engineering Database (TED) is used in computing 84 paths for connection oriented packet services and for circuits. The 85 TED contains all relevant information that a Path Computation 86 Element (PCE) needs to perform its computations. It is important 87 that the TED should be complete and accurate anytime so that the PCE 88 can perform path computations. 90 In MPLS and GMPLS networks, Interior Gateway routing Protocols 91 (IGPs) have been used to create and maintain a copy of the TED at 92 each node. One of the benefits of the PCE architecture [RFC4655] is 93 the use of computationally more sophisticated path computation 94 algorithms and the realization that these may need enhanced 95 processing power not necessarily available at each node 96 participating in an IGP. 98 Section 4.3 of [RFC4655] describes the potential load of the TED on 99 a network node and proposes an architecture where the TED is 100 maintained by the PCE rather than the network nodes. However it did 101 not describe how a PCE would obtain the information needed to 102 populate its TED. PCE may construct its TED by participating in the 103 IGP ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] 104 for GMPLS). An alternative is offered by BGP-LS [I-D.ietf-idr-ls- 105 distribution]. 107 In this document we propose approaches for creating and maintaining 108 the TED directly on a PCE as an alternative to IGPs and BGP 109 transport and investigate on the impact from the PCE, routing 110 protocol, and node perspective. 112 There are two main applicability of this alternative proposed by 113 this draft: 115 o Where there is no IGP-TE or BGP-LS running at the PCE to learn 116 TED. 118 o Where there is IGP-TE or BGP-LS running but with a need for a 119 faster TED population and convergence at the PCE. 121 * A PCE may receive partial information (say basic TE) from IGP- 122 TE and other information (optical and impairment) from PCEP. 124 * A PCE may receive full information from both IGP-TE and PCEP. 126 A PCC may further choose to send only local TE information or both 127 local and remote learned TED information. How a PCE manages the TED 128 information is implementation specific and thus out of scope of this 129 document. PCEP extensions to support this idea is pursued in a 130 separate draft [PCEP-TE]. 132 New application areas for GMPLS and PCE in optical transport 133 networks include Wavelength Switched Optical Networking (WSON) and 134 Optical Transport Networks (OTN). WSON scenarios can be divided into 135 routing wavelength assignment (RWA) problems where a PCE requires 136 detailed information about switching node asymmetries and wavelength 137 constraints as well as detailed up to date information on wavelength 138 usage per link [WSON-Frame]. As more data is anticipated to be made 139 available to PCE with addition of OTN [Reference] and Flex-grid 140 [Reference] and possible with some optical impairment data [WSON- 141 IMP-Info] even with the minimum set specified in [G.680], the total 142 amount of data requires significantly more information to be held in 143 the TED than is required for other traffic engineered networks. 144 Related to this issue published by [HWANG] indicated that long 145 convergence time and large number of LSAs flooded in the network 146 might cause scalability problems in OSPF-TE and impose limitations 147 on OSPF-TE applications. 149 In some circumstances such additional information could "bog down" 150 the routing protocols on the nodes from a data processing, a 151 storage, or communications perspective. In environments where PCEs 152 are external to the nodes running the routing protocol, and where 153 the information in the TED is not used by the switching nodes it 154 makes sense to investigate alternative methods to create and 155 maintain the TED at its place of use, i.e., the PCE. 157 Recent development of a stateful PCE Model [PCE-Initiated] changes 158 the PCE operation from path computation alone to include the support 159 of PCE-initiated LSPs. With a stateful PCE model, it is also noted 160 that LSP-DB is maintained by the PCE. For LSP state synchronization 161 of stateful PCEs in GMPLS networks, the LSP attributes, such as its 162 bandwidth, associated route as well as protection information etc, 163 should be updated by PCCs to PCE LSP database (LSP-DB) [S-PCE-GMPLS]. 164 To support all these recent changes in a stateful PCE model, a 165 direct PCE interface to each PCC has to be supported. Relevant TED 166 information can also be transported from each node to PCE using this 167 PCC-PCE interface. Any resource changes in the node and links can 168 also be quickly updated to PCE using this interface. Convergence 169 time of IGP in GMPLS networks may not be quick enough to support on- 170 line dynamic connectivity required for some applications. 172 This draft does not advocate that the alternative methods specified 173 in this draft should completely replace the IGP-TE as the method of 174 creating the TED. The split between the data to be distributed via 175 an IGP and the information conveyed via one of the alternatives in 176 this document depends on the nature of the network situation. One 177 could potentially choose to have some traffic engineering 178 information distributed via an IGP while other more specialized 179 traffic information is only conveyed to the PCEs via an alternative 180 interface discussed here. In addition, the methods specified in this 181 draft is only relevant to a set of architecture options where 182 routing decisions are wholly or partially made in the PCE. 184 However, the networks that do not support IGP-TE/BGP-LS, the method 185 proposed by this draft may be very relevant. 187 1.1. TED Creation and Maintenance via IGP-TEs 189 Routing protocols, in particular, IGP-TEs such as Open Shortest Path 190 First (OSPF) and Intermediate system to intermediate system (IS-IS), 191 take on a number of roles with respect to the control and data 192 planes for IP, MPLS, and GMPLS. In all three technology families 193 the underlying control plane communications technology is IP and 194 hence all utilize the IGPs ability to control and run the IP data 195 plane. 197 For the IP layer, the IGP directly establishes data plane 198 connectivity. In the MPLS and GMPLS cases separate signaling 199 protocols are used to directly control the data plane connectivity 200 and in these cases the prime purpose of the routing protocol is to 201 furnish network topology and resource status information used by 202 path computation algorithms on the nodes or PCEs. Hence in the IP 203 case the IGP is directly service impacting, while in the MPLS/GMPLS 204 case it is only indirectly service impacting. 206 The IP layer information and the MPLS/GMPLS data plane layer 207 information may be kept by the IGPs in two different information 208 stores. These are referred to as databases but are not necessarily 209 relational databases. In OSPF the information directly related to 210 IP connectivity (and hence the control communications plane for all 211 three technologies) and non-IP advertisements are kept in the link 212 state database (LSDB), while information related to traffic 213 engineering used by MPLS and GMPLS is kept in a (conceptually) 214 separate TED which can be considered a subset of the LSDB. This TED 215 information is distributed in a different data structure (Opaque LSA 216 [RFC5250]). When we talk about adding additional technology-specific 217 GMPLS information used for path computation we are only talking 218 about adding to the TED and not the IP portion of the LSDB. 220 There are three main functions performed by an IGP: (a) hello 221 protocol, (b) database synchronization (with neighbors), (c) 222 database updates. 224 Data Plane | Hello Protocol | Database Sync 225 Technologies | | & Updates 226 -------------------------------------------------------------- 227 IP | Establish Control & Data | LSDB 228 | Plane Adjacencies | 229 -------------------------------------------------------------- 230 MPLS | Establish Control & Data | LSDB & TED 231 | Plane Adjacencies | 232 -------------------------------------------------------------- 233 GMPLS | Establish Control Plane | LSDB & TED 234 | Adjacencies (only) | 235 -------------------------------------------------------------- 237 Table 1 Main Functions of an IGP for various technologies 239 The procedures for maintaining LSDBs and TEDs in IGP-TEs have been 240 very successful and well proven over time. These consist of: 242 1. Ageing the individual pieces of information in the TED 243 (including discarding them when the information gets too old) 244 to remove stale information from the TED. 246 2. Originator of the information being required to periodically 247 resend TED information to prevent it from being discarded. 249 3. Originator of the information sending updates of information as 250 needed, but subject to limits on how many/often these can be 251 sent to keep the TED up-to-date, but to avoid swamping the 252 network. 254 4. Reliable method for getting this information to other peers 255 (flooding) to ensure that the information is delivered to all 256 participants. 258 5. An efficient database synchronization mechanism for sharing 259 info with a newly established peer. 261 2. Alternative TED Creation & Maintenance for a PCE 263 Given that nodes, by their position and role in the network, have 264 accurate traffic engineering information concerning their local link 265 ends and switching properties, it seems natural that, if other nodes 266 in the network cannot make use of this information or do not want 267 it, the information should only be conveyed to interested PCEs. In 268 such case the flooding of TE information to all nodes may not be 269 very efficient in terms of memory, CPU, bandwidth, etc. 271 In addition, one could potentially choose to have some traffic 272 engineering information distributed via an IGP-TE protocol while 273 other more specialized traffic information is only conveyed to the 274 PCEs. For example, it makes sense to distribute "static" (rarely 275 modified) and sizable data (e.g., NE switching asymmetry structure) 276 via methods other than IGP-TE while more frequently changed data via 277 IGP-TE. This could significantly decrease the IGP-TE information and 278 its footprint on all nodes. 280 The benefits of such an approach include: 282 o Node: reduced storage demands (doesn't keep the entire TED) 284 o Node: reduced processing demands for TED updates and 285 synchronization 287 o Control Plane: reduced overall communication demands since the 288 TED is not being updated and maintained on all nodes in the 289 network. 291 o PCE: More timely TED updates are possible. 293 o Information distribution constraints, such as seen in [Imp-Frame] 294 can be met. 296 To quantify the previous advantages requires a bit more detail on 297 how such an approach could actually be accomplished. The key pieces 298 needed to implement such an approach include: 300 o Multiple PCEs must be supported for robustness and load sharing. 302 o Nodes must be able to find a PCE to which to send their traffic 303 engineering information. 305 o Nodes must have procedures and a mechanism (protocols) with which 306 to communicate their TE information to a PCE. PCEs must have 307 procedures and a mechanism (protocols) with which to receive this 308 TE information from nodes. 310 o Efficient mechanisms must exist in the multi-PCE case to ensure 311 all PCEs have the same TED. 313 The advantages of using an alternative to IGP-TE comes at the cost 314 of: 316 o Additional protocols to be configured and secured. Recall that we 317 still must have an IP IGP for control plane communications. 319 o Any new protocols/implementations for alternative TED creation 320 still must support many IGP-TE like features such as removal of 321 stale information, reliable delivery of updates to all 322 participants, recovery after reboots/crashes/upgrades, etc. It 323 should also work along with IGP-TE/BGP-LS TED mechanism with some 324 information in the TED received from existing mechanisms. 326 o Mechanisms to discover PCEs that are capable and willing to 327 accept direct TED updates. 329 2.1. Architecture Options 331 There are three general architectural alternatives based on how 332 nodes get their local TED information to the PCEs: (1) Nodes send 333 local information to all PCEs; (2) Nodes send local information to 334 an intermediate server that will send to all PCEs; (3) Nodes send 335 local information to at least one PCE and have the PCEs share this 336 information with each other. An important functionality that needs 337 to be addressed in each of these approaches is how a new PCE gets 338 initialized in a reasonably timely fashion. 340 Figures 1-3 show examples of three options for nodes to share local 341 TED information with multiple PCEs. As in the IGP case we assume 342 that switching nodes know their local properties and state including 343 the state of all their local links. In these figures the data plane 344 links are shown with the character "o"; TE information flow from 345 nodes to PCE by the characters "|", "-", "/", or "\"; and PCE to PCE 346 TE information, if any, by the character "i". 348 ---- ---- 349 // \\ // \\ 350 / \ / \ 351 | PCE \ | PCE | 352 | |\ / | 353 | X \ / \ / 354 |\\ // \ \ / /|\ /X 355 | --+-\ \ \ /// | -+-- \ 356 | | \\ \ \\ // | | \ 357 | | \\ \ // | | \ 358 | | \\ \ / | | \ 359 | | \ \\ \// | | \ 360 | | \ \\ /\/ | | \ 361 | | \ /X\/\ | | \ 362 | | \ / /\ \ | | \ 363 | | X/ / \\\ | | \ 364 | | / \ / \\ | | \ 365 | | // \ / \\| | \ 366 | | / X \\\ | \ 367 | | // /\ |\\\\| \ 368 | +----+-/-+ / \ |+-\-|----+ \ 369 | | | / \ || | \ 370 | | N1 ooooooooooooooooooo N2 oo \ 371 | | ooooooooooooooooooo ooo \ 372 | | | / \ | | |ooo \ 373 | +---oo---+/ \ | +------\-+ ooo \ 374 | ooo / \ | \ ooo \ 375 | ooo / \ | \ ooo \ 376 | oo / * \ | \ ooo \ 377 | oo / \ | \ ooo \ 378 | ooo / \ | \\ ooo \ 379 | oo / * \ \ ooo \ 380 | ooo / \ \ ooo \ 381 | oo / |\ \ ooo\ 382 ++--oo-/-+ |\ * \+---oo-\-+ 383 | | | \ \ | 384 | oooo | \ oooo Nn | 385 | N3 ooooooooo +-+---\--+ ooooooooo | 386 | | ooooooooo | | oooooooooo | | 387 +--------+ oooooooo N4 oooooooo +--------+ 388 oooo oooo 389 | | 390 +--------+ 391 Figure 1 . Nodes send local TE information directly to all PCEs 392 ---- ---- ---- 393 // \\ // \\ // \\ 394 / \ / \ / \ 395 | PCE | | PCE | | PCE | 396 | | | | | | 397 \ -- \ / \ / 398 \\ // -- \\ // --\\ // 399 ---- --- /--- ---- ---- 400 -- / ---- 401 --- / --- 402 -- --/- ---- 403 --/ \\ ---- 404 / -- 405 | Pub/ | 406 -+ Sub | 407 --- X --- 408 -- / \\ // ---- 409 +--- / -+--\ ----+ 410 +-----+--+ / | \ +--+-----+ 411 | | / | \\ | | 412 | N1 ooooooooooooooooooooooooo N2 oooo 413 | ooooooooooooooooooooooooo oooo 414 | | / | \\ | | oo 415 +---oo---+ / | \+--------+ oo 416 oo / | \ oo 417 oo / | \ oo 418 oo / | \\ oo 419 oo / | \ oo 420 oo / * | \ oo 421 oo / | \ oo 422 oo / | \\ oo 423 oo / *| \ oo 424 oo / | \ oo 425 oo / | \\ oo 426 +---oo-/-+ | * \+---oo---+ 427 | | | \ | 428 | oooo | oooo Nn | 429 | N3 oooooooo +---+----+ ooooooooo | 430 | | oooooo | | ooooooooooo | | 431 +--------+ oooooooo N4 ooooooooo +--------+ 432 ooooo oooo 433 | | 434 +--------+ 436 Figure 2 . Nodes send local TE information to PCEs via an 437 intermediary (publish/subscribe)server 438 iiiiiiiiiiiiiiiiii 439 iiiiii ---- iii iiiii ---- 440 ii ii// \\i iiiiiiii/ \\ 441 ii / \ / \ 442 i | PCE1 | | PCE2 | 443 i | | | |ii 444 i \ / X / ii 445 i \\ // // \\ // ii 446 i -//- / --+- i 447 i // // | i 448 i +-----/--+ +----/---+ | i 449 i | | | | | i 450 i | N1 ooooooooooooooooooooooooo N2 oooo | i 451 i | ooooooooooooooooooooooooo oooo | i 452 i | | | | oo | i 453 i +---oo---+ +--------+ oo | i 454 i oo oo | i 455 i oo oo | i 456 i oo * oo | i 457 i oo oo | i 458 i oo oo | i 459 i oo * oo | i 460 i oo oo | i 461 i +---oo---+ * +---oo-+-+ i 462 i | | | | i 463 i | oooo oooo Nn | i 464 i | N3 oooooooo +--------+ ooooooooo | i 465 ii | | oooooo | | ooooooooooo | | ii 466 i +---\----+ oooooooo N4 ooooooooo +--------+ i 467 i \ ooooo oooo i 468 ii \ | | i 469 i \\ +--------+ ii 470 ii \ --- i 471 ii \ ---- --- i 472 ii \// \-- i 473 ii / \ ii 474 ii | PCE3 | iiii 475 iiiii| | iiiii 476 \ / iii 477 \\ // iiiiiiiii iii 478 ---- iiiiiiiiiiiiiiiiiii 480 Figure 3 . Nodes send local TE information to at least one PCE and 481 have the PCEs share TED information 483 2.1.1. Nodes Send TE Info to all PCEs 485 Architectural alternative 1 shown in Figure 1, illustrates nodes 486 sending their local TE information to all PCEs within their domain. 487 As the number of PCEs grows we have scalability concerns. However, 488 if we are only talking about 2-3 PCEs, then we do not have this 489 scalability concern. In particular each node needs to keep track of 490 which PCE it has sent information to and update that information 491 periodically. 493 If a new PCE is added to the domain the node must send all its local 494 TED information to that PCE rather than just sending status updates. 496 2.1.2. Nodes Send TE Info via an Intermediate System 498 Architecture alternative 2 is shown in Figure 2. This architecture 499 reduces the burden on switching nodes by having the nodes send TE 500 information to an intermediate system. This general approach is 501 typically described in the software literature as a 502 publish/subscribe paradigm. Here the nodes send their local TED 503 information to an intermediate entity whose job is to insure that 504 all PCEs receive this information. The nodes in this case being the 505 publishers of the information and the PCEs the subscribers of the 506 information. Publish/subscribe functionality can be found in general 507 messaging oriented middleware such as the Java Messaging Service 508 [JMS] and many others. A routing specific example of this approach 509 is seen in BGP route reflectors [RFC4456]. 511 Note that the publish/subscribe entity can be collocated with a PCE. 512 This would then looks like a master/slave type system architecture. 514 If a new PCE is added then the intermediate server will need to work 515 with this new PCE to initialize its TED. Hence the publish/subscribe 516 entity will need to also keep a copy of the entire TED and for 517 reliability purposes a redundant server would be required. The 518 publish/subscribe entity itself can be a PCE. 520 Architecture alternative 2 could be useful when there are a number 521 of PCEs in the network and as such there is the scaling issue with 522 each of the NEs talking to all the PCEs. The advantage of this 523 alternative would diminish when we are dealing only with only a few 524 PCEs. 526 2.1.3. Nodes Send TE Info to At Least One PCE 528 In this architectural alternative, shown in Figure 3, each node 529 would be associated with at least one PCE. This implies that each 530 PCE will only have partial TED information directly from the nodes. 531 It would be the responsibility of a node to get its local TED 532 information to its associated PCE, then the PCEs within a domain 533 would then need to share the partial TED information they learned 534 from their associated nodes with each other so that they can create 535 and maintain the complete TED. As we have seen in section 1.1. this 536 is very similar to part of the functionality provided by a link 537 state protocol, but in this case the protocol would be used between 538 PCEs so that they can share the information they have obtained from 539 their associated switching nodes (rather than from attached links as 540 in a regular link state protocol). To allow for this sharing of 541 information PCEs would need to peer with each other. PCE discovery 542 extensions [RFC4674] could be used to allow PCEs to find other PCEs. 543 If a new PCE is added to the domain it would need to peer with at 544 least one other PCE and then link state protocol procedures for TED 545 synchronization could then be used to initialize the new PCEs TED. 547 A number of approaches can be used to ensure control plane 548 resilience in this architecture. (1) Each node can be configured 549 with a primary and a secondary PCE to send its information to; In 550 case of failure of communications with the primary PCE the node 551 would send its information to a secondary PCE (warm standby). (2) 552 Each node could be configured to send its information to two 553 different PCEs (hot standby). 555 2.2. Nodes Finding PCEs 557 In cases 1 and 3 nodes need to send TE information directly to PCEs. 558 Path Computation Clients (PCCs) and network nodes participating in 559 an IGP (with or without TE extensions) have a mechanism to discover 560 a PCE and its capabilities. [RFC4674] outlines the general 561 requirements for this mechanism and extensions have been defined to 562 provide information so that PCCs can obtain key details about 563 available PCEs in OSPF [RFC5088] and in IS-IS [RFC5089]. 565 After finding candidate PCEs, a node would need to see which if any 566 of the PCEs actually want to receive TE information directly from 567 this node. 569 In architectural alternative 2 (publish/subscribe) the location of 570 intermediate system would either need to be configured or PCE 571 discovery could be extended so that a when a node asks a PCE if it 572 wants to hear TE info the PCE points it to the intermediate 573 publish/subscribe system. 575 2.3. Node TE Information Update Procedures 577 First a node must establish an association between itself and a PCE 578 or intermediate system that will be maintaining a TED. It is the 579 responsibility of the node to share TE information concerning its 580 local environment, e.g., links and node properties. General and 581 technology specific information models would specify the content of 582 this information while the specific protocols would determine the 583 format. Note that a node would not be sending to the PCE information 584 it might be passed from neighbor nodes. Note that data plane 585 neighbor information would be passed to the PCE embedded in TE link 586 information. 588 There will be cases where the node would have to send to the PCE 589 only a subset of TE link information depending on the path 590 computation option. For instance, if the node is responsible for 591 routing while the PCE is responsible for wavelength assignment for 592 the route, the node would only need to send the PCE the WSON link 593 usage information. This path computation option is referred to as 594 separate Fouting (R) and Wavelength Assignment (WA) option in [PCE- 595 WSON]. 597 2.4. PCE TED Maintenance Procedures 599 The PCE is responsible for creating and maintaining the TED that it 600 will use. Key functions include: 602 1. Establishing and authenticating communications between the PCE 603 and sources of TED information. 605 2. Timely updates of the TED with information received from nodes, 606 peers or other entities. 608 3. Verifying the validity of information in the TED,i.e., ensure 609 that the network information obtained from nodes or elsewhere 610 is relatively timely, or not stale. By analogy with similar 611 functionality provided by IGPs this can be done via a process 612 where discrete "chunks" of TED information are "aged" and 613 discard when expired. This combined with nodes periodically 614 resending their local TE information leads to a timely TED. 616 3. Standardization and Protocol Considerations 618 In the previous section we examined a number of architectural 619 alternatives for TED creation and maintenance between PCE(s) and the 620 network. Here we examine aspects of these alternatives that could be 621 suitable for standardization. First there are a number of functions 622 which are independent of the particular architectural alternatives, 623 these include: 625 o An information model for the TED 627 o Basic PCE TED creation and maintenance procedures 629 o Information packaging for use in TED creation, maintenance and 630 exchange 632 o NE to PCE (or Pub/Sub) communication of TED information --- 633 interface and protocol (e.g. PCEP) 635 o NEs discovering PCE (or Pub/Sub) for TED creation and maintenance 636 purposes 638 By the "information model" for the TED we mean the raw information 639 that a path computation algorithm would work with somewhat 640 independent of how it might be packaged for TED maintenance and 641 creation. Initial efforts along these lines have started at CCAMP 642 for wavelength switched optical networks for non-impairment RWA 643 [WSON-Info] and impairment aware RWA [WSON-IMP-Info]. 645 Given a TED information model if we can agree on basic PCE TED 646 creation and maintenance procedures we can then come up with a 647 standardized way to package the information for use in such 648 procedures. The analogy here is with an IGPs database maintenance 649 procedures such as aging and the packaging of link state information 650 information into LSA (link state advertisements). LSAs form the 651 basic chunks of an IGP's database. OSPF LSAs include an age field to 652 assist in the ageing procedure and also has an advertising router 653 field that aids in redistribution decisions, i.e., flooding. However 654 the detailed TE information is encoded in LSAs via type length value 655 (TLV) structures and it is this information that is used in path 656 computation. 658 From there we could standardize the interface between a NE and a PCE 659 for communication of TE information. This interface includes NE and 660 PCE behaviors as well as a communications protocol. 662 Finally for the common behaviors we need a way for the NEs to find 663 the PCEs or an intermediate publish/subscribe system to which they 664 will send their TE information. As was previously pointed out this 665 could be based on small enhancements to existing PCE discovery 666 mechanisms. 668 3.1. Architecture Specific Standardization Aspects 670 Case 1: NEs send to all PCEs 672 This case has commonalities with both cases 2 and 3 and does not 673 appear to have unique standardization aspects. As pointed out in 674 section 2.1. We do need to consider when a new PCE comes online. 676 Case 2: Publish/Subscribe Server 678 In this case we would need to additionally standardize 680 1. how a new PCE coming online synchronizes with the 681 publish/subscribe server 683 1. how PCEs and publish subscribe server communicate 685 2. Redundancy for publish subscribe server 687 Case 3: PCE to PCE sharing TE information learned from NEs 689 Here we would need the following additional mechanisms standardized: 691 1. The PCE to PCE interface and protocol 693 2. The method for PCEs to discover PCEs for the purpose of TE 694 information sharing 696 3. PCE to PCE association for information sharing, in particular 697 sharing update information. 699 4. Security Considerations 701 This draft discusses an alternative technique for PCEs to build and 702 maintain a traffic engineering database. In this approach network 703 nodes would directly send traffic engineering information to a PCE. 704 It may be desirable to protect such information from disclosure to 705 unauthorized parties in addition it may be desirable to protect such 706 communications from interference (modification) since they can be 707 critical to the operation of the network. In particular, this 708 information is the same or similar to that which would be 709 disseminated via a link state routing protocol with traffic 710 engineering extensions. 712 5. IANA Considerations 714 This version of this document does not introduce any items for IANA 715 to consider. 717 6. Conclusions 719 This document introduced several alternative architectures for PCEs 720 to create and maintain a traffic engineering database (TED) via 721 information directly or indirectly received from network elements 722 and identified common aspects of these approaches. The TED is a 723 critical piece of the overall PCE architecture since without it path 724 computations cannot proceed. Though not explicitly out of scope the 725 PCE working group does not have a work item or study item devoted to 726 TED creation and maintenance. Such a work item can lead to enhanced 727 interoperability and simplicity of PCE implementations. This 728 document identified several common areas within these alternatives 729 that could be standardized. In addition, the alternative approaches 730 to TED creation and maintenance discussed here offloads both the 731 network nodes and routing protocols from either some or all TED 732 creation and maintenance duties at the same time it does not add 733 significant new processing to a PCE that has already been 734 participating in IGP based TED creation and maintenance. 736 7. Acknowledgments 738 We would like to thank Adrian Farrel for his useful comments and 739 suggestions. 741 8. References 743 8.1. Normative References 745 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 746 Computation Element (PCE)-Based Architecture", RFC 4655, 747 August 2006. 749 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 750 Element (PCE) Discovery", RFC 4674, October 2006. 752 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 753 Zhang, "OSPF Protocol Extensions for Path Computation 754 Element (PCE) Discovery", RFC 5088, January 2008. 756 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 757 Zhang, "IS-IS Protocol Extensions for Path Computation 758 Element (PCE) Discovery", RFC 5089, January 2008. 760 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 761 OSPF Opaque LSA Option", RFC 5250, July 2008. 763 8.2. Informative References 765 [JMS] Java Message Service, Version 1.1, April 2002, Sun 766 Microsystems. 768 [PCE-Initiated] E. Crabbe, et. al., "PCEP Extensions for PCE- 769 initiated LSP Setup in a Stateful PCE Model", draft-ietf- 770 pce-pce-initiated-lsp, work in progress. 772 [S-PCE-GMPLS] X. Zhang, et. al, "Path Computation Element (PCE) 773 Protocol Extensions for Stateful PCE Usage in GMPLS- 774 controlled Networks", draft-ietf-pce-pcep-stateful-pce- 775 gmpls, work in progress. 777 [PCE-WSON] Y. Lee, G. Bernstein, "PCEP Requirements for the 778 support of Wavelength Switched Optical Networks (WSON)", 779 work in progress, draft-lee-pce-wson-routing-wavelength- 780 05.txt, February 2009. 782 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 783 Reflection: An Alternative to Full Mesh Internal BGP 784 (IBGP)", RFC 4456, April 2006. 786 [Imp-Frame] G. Bernstein, Y. Lee, D. Li, A Framework for the Control 787 and Measurement of Wavelength Switched Optical Networks 788 (WSON) with Impairments, Work in Progress, October 2008. 790 [WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for 791 GMPLS and PCE Control of Wavelength Switched Optical 792 Networks", work in progress: draft-ietf-ccamp-wavelength- 793 switched-framework. 795 [PCEP-TE] D. Dhody, Y. Lee, "PCEP Extension for Transporting TE 796 Data", work in progress: draft-dhodylee-pce-pcep-te-data- 797 extn. 799 [WSON-IMP-Info] Y. Lee, G. Bernstein, "Information Model for 800 Impaired Optical Path Validation", work in progress: 801 draft-bernstein-wson-impairment-info-02.txt, March 2009. 803 [HWANG] S. Hwang, et al, "An Experimental Analysis on OSPF-TE 804 Convergence Time", Proc. SPIE 7137, Network Architectures, 805 Management, and Applications, November 19, 2008. 807 Author's Addresses 809 Young Lee 810 Huawei Technologies 811 5340 Legacy Drive, Building 3 812 Plano, TX 75023, USA 814 Phone: (469) 277-5838 815 Email: leeyoung@huawei.com 817 Haomian Zheng 818 Huawei Technologies Co., Ltd. 819 F3-1-B R&D Center, Huawei Base, 820 Bantian, Longgang District 821 Shenzhen 518129 P.R.China 823 Phone: +86-755-28979835 824 Email: zhenghaomian@huawei.com 826 Contributor's Addresses 828 Dhruv Dhody 829 Huawei Technologies 830 Leela Palace 831 Bangalore, Karnataka 560008 832 India 834 EMail: dhruv.ietf@gmail.com 836 Xian Zhang 837 Huawei Technologies Co., Ltd. 838 F3-1-B R&D Center, Huawei Base, 839 Bantian, Longgang District 840 Shenzhen 518129 P.R.China 842 Phone: +86-755-28979835 843 Email: zhangxian@huawei.com 845 Disclaimer of Validity 847 All IETF Documents and the information contained therein are 848 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 849 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 850 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 851 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 852 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 853 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 854 FOR A PARTICULAR PURPOSE. 856 Acknowledgment 858 Funding for the RFC Editor function is currently provided by the 859 Internet Society.