idnits 2.17.1 draft-dhodylee-pce-pcep-ls-04.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD3' is mentioned on line 503, but not defined == Missing Reference: 'TBD5' is mentioned on line 577, but not defined == Missing Reference: 'TBD6' is mentioned on line 607, but not defined == Missing Reference: 'This I-D' is mentioned on line 1291, but not defined == Unused Reference: 'RFC7810' is defined on line 1475, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) -- Obsolete informational reference (is this intentional?): RFC 6822 (Obsoleted by RFC 8202) == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-14 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-05 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-09 == Outdated reference: A later version (-01) exists of draft-kondreddy-pce-pcep-ls-sync-optimizations-00 == Outdated reference: A later version (-03) exists of draft-leedhody-teas-pcep-ls-02 == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-00 == Outdated reference: A later version (-09) exists of draft-ietf-teas-actn-requirements-03 == Outdated reference: A later version (-08) exists of draft-leedhody-pce-vn-association-00 Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Y. Lee 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 8, 2017 D. Ceccarelli 6 Ericsson 7 July 7, 2016 9 PCEP Extension for Distribution of Link-State and TE Information. 10 draft-dhodylee-pce-pcep-ls-04 12 Abstract 14 In order to compute and provide optimal paths, Path Computation 15 Elements (PCEs) require an accurate and timely Traffic Engineering 16 Database (TED). Traditionally this TED has been obtained from a link 17 state (LS) routing protocol supporting traffic engineering 18 extensions. 20 This document extends the Path Computation Element Communication 21 Protocol (PCEP) with Link-State and TE Information. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 8, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Requirements for PCEP extension . . . . . . . . . . . . . . . 6 62 5. New Functions to distribute link-state (and TE) via PCEP . . 7 63 6. Overview of Extension to PCEP . . . . . . . . . . . . . . . . 7 64 6.1. New Messages . . . . . . . . . . . . . . . . . . . . . . 7 65 6.2. Capability Advertisement . . . . . . . . . . . . . . . . 7 66 6.3. Initial Link-State (and TE) Synchronization . . . . . . . 8 67 6.3.1. Optimizations for LS Synchronization . . . . . . . . 10 68 6.4. LS Report . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. LS Report Message . . . . . . . . . . . . . . . . . . . . 11 72 8.2. The PCErr Message . . . . . . . . . . . . . . . . . . . . 12 73 9. Objects and TLV . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Open Object . . . . . . . . . . . . . . . . . . . . . . . 13 75 9.1.1. LS Capability TLV . . . . . . . . . . . . . . . . . . 13 76 9.2. LS Object . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.2.1. Routing Universe TLV . . . . . . . . . . . . . . . . 15 78 9.2.2. Route Distinguisher TLV . . . . . . . . . . . . . . . 16 79 9.2.3. Virtual Network TLV . . . . . . . . . . . . . . . . . 16 80 9.2.4. Local Node Descriptors TLV . . . . . . . . . . . . . 17 81 9.2.5. Remote Node Descriptors TLV . . . . . . . . . . . . . 17 82 9.2.6. Node Descriptors Sub-TLVs . . . . . . . . . . . . . . 18 83 9.2.7. Multi-Topology ID TLV . . . . . . . . . . . . . . . . 19 84 9.2.8. Link Descriptors TLV . . . . . . . . . . . . . . . . 19 85 9.2.9. Prefix Descriptors TLV . . . . . . . . . . . . . . . 20 86 9.2.10. PCEP-LS Attributes . . . . . . . . . . . . . . . . . 21 87 9.2.10.1. Node Attributes TLV . . . . . . . . . . . . . . 21 88 9.2.10.2. Link Attributes TLV . . . . . . . . . . . . . . 22 89 9.2.10.3. Prefix Attributes TLV . . . . . . . . . . . . . 24 90 9.2.11. Removal of an Attribute . . . . . . . . . . . . . . . 25 91 10. Other Considerations . . . . . . . . . . . . . . . . . . . . 25 92 10.1. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 25 93 11. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 25 94 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 13. Manageability Considerations . . . . . . . . . . . . . . . . 25 96 13.1. Control of Function and Policy . . . . . . . . . . . . . 25 97 13.2. Information and Data Models . . . . . . . . . . . . . . 26 98 13.3. Liveness Detection and Monitoring . . . . . . . . . . . 26 99 13.4. Verify Correct Operations . . . . . . . . . . . . . . . 26 100 13.5. Requirements On Other Protocols . . . . . . . . . . . . 26 101 13.6. Impact On Network Operations . . . . . . . . . . . . . . 26 102 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 103 14.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . 26 104 14.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 26 105 14.3. LS Object . . . . . . . . . . . . . . . . . . . . . . . 27 106 14.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 27 107 14.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28 108 14.6. PCEP-LS Sub-TLV Type Indicators . . . . . . . . . . . . 28 109 15. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 31 110 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 111 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 112 17.1. Normative References . . . . . . . . . . . . . . . . . . 32 113 17.2. Informative References . . . . . . . . . . . . . . . . . 32 114 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 35 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 117 1. Introduction 119 In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS), 120 a Traffic Engineering Database (TED) is used in computing paths for 121 connection oriented packet services and for circuits. The TED 122 contains all relevant information that a Path Computation Element 123 (PCE) needs to perform its computations. It is important that the 124 TED be complete and accurate each time, the PCE performs a path 125 computation. 127 In MPLS and GMPLS, interior gateway routing protocols (IGPs) have 128 been used to create and maintain a copy of the TED at each node 129 running the IGP. One of the benefits of the PCE architecture 130 [RFC4655] is the use of computationally more sophisticated path 131 computation algorithms and the realization that these may need 132 enhanced processing power not necessarily available at each node 133 participating in an IGP. 135 Section 4.3 of [RFC4655] describes the potential load of the TED on a 136 network node and proposes an architecture where the TED is maintained 137 by the PCE rather than the network nodes. However, it does not 138 describe how a PCE would obtain the information needed to populate 139 its TED. PCE may construct its TED by participating in the IGP 140 ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for 141 GMPLS). An alternative is offered by BGP-LS [RFC7752] . 143 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 144 provide stateful control. A stateful PCE has access to not only the 145 information carried by the network's Interior Gateway Protocol (IGP), 146 but also the set of active paths and their reserved resources for its 147 computations. PCC can delegate the rights to modify the LSP 148 parameters to an Active Stateful PCE. This requires PCE to quickly 149 be updated on any changes in the Topology and TEDB, so that PCE can 150 meet the need for updating LSPs effectively and in a timely manner. 151 The fastest way for a PCE to be updated on TED changes is via a 152 direct interface with each network node and with incremental update 153 from each network node with only the attribute that is modified. 155 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and 156 teardown of PCE-initiated LSPs under the stateful PCE model, without 157 the need for local configuration on the PCC, thus allowing for a 158 dynamic network that is centrally controlled and deployed. This 159 model requires timely topology and TED update at the PCE. 161 [I-D.leedhody-teas-pcep-ls] proposes some other approaches for 162 learning and maintaining the Link-State and TE information directly 163 on a PCE as an alternative to IGPs and BGP flooding and investigate 164 the impact from the PCE, routing protocol, and node perspectives. 166 [RFC5440] describes the specifications for the Path Computation 167 Element Communication Protocol (PCEP). PCEP specifies the 168 communication between a Path Computation Client (PCC) and a Path 169 Computation Element (PCE), or between two PCEs based on the PCE 170 architecture [RFC4655]. 172 This document describes a mechanism by which Link State and TE 173 information can be collected from networks and shared with PCE using 174 the PCEP itself. This is achieved using a new PCEP message format. 175 The mechanism is applicable to physical and virtual links as well as 176 further subjected to various policies. 178 A network node maintains one or more databases for storing link-state 179 and TE information about nodes and links in any given area. Link 180 attributes stored in these databases include: local/remote IP 181 addresses, local/ remote interface identifiers, link metric and TE 182 metric, link bandwidth, reservable bandwidth, per CoS class 183 reservation state, preemption and Shared Risk Link Groups (SRLG). 184 The node's PCEP process can retrieve topology from these databases 185 and distribute it to a PCE, either directly or via another PCEP 186 Speaker, using the encoding specified in this document. 188 Further [RFC6805] describes Hierarchical-PCE architecture, where a 189 parent PCE maintains a domain topology map. The child PCE MAY 190 transport (abstract) Link-State and TE information from child PCE to 191 a Parent PCE using the mechanism described in this document. 193 [I-D.ietf-pce-stateful-pce] describe LSP state synchronization 194 between PCCs and PCEs in case of stateful PCE. This document does 195 not make any change to the LSP state synchronization process. The 196 mechanism described in this document are on top of the existing LSP 197 state synchronization. 199 1.1. Requirements Language 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in [RFC2119]. 205 2. Terminology 207 The terminology is as per [RFC4655] and [RFC5440]. 209 3. Applicability 211 As per [I-D.leedhody-teas-pcep-ls], the mechanism specified in this 212 draft is applicable to: 214 o Where there is no IGP or BGP-LS running in the network. 216 o Where there is no IGP or BGP-LS running at the PCE to learn link- 217 state and TE information. 219 o Where there is IGP or BGP-LS running but with a need for a faster 220 TE and link-state population and convergence at the PCE. 222 * A PCE may receive partial information (say basic TE, link- 223 state) from IGP and other information (optical and impairment) 224 from PCEP. 226 * A PCE may receive an incremental update (as opposed to the 227 entire information of the node/link). 229 * A PCE may receive full information from both existing mechanism 230 (IGP or BGP) and PCEP. 232 o Where there is a need for transporting (abstract) Link-State and 233 TE information from child PCE to a Parent PCE in H-PCE [RFC6805]; 234 as well as for Physical Network Controller (PNC) to Multi-Domain 235 Service Coordinator (MDSC) in Abstraction and Control of TE 236 Networks (ACTN) [I-D.ietf-teas-actn-framework]. 238 A PCC may further choose to send only local information or both local 239 and remote learned information. 241 How a PCE manages the link-state (and TE) information is 242 implementation specific and thus out of scope of this document. 244 The prefix information in PCEP-LS can also help in determining the 245 domain of the endpoints in H-PCE (and ACTN). Section 4.5 of 246 [RFC6805] describe various mechanism and procedures that might be 247 used, PCEP-LS provides a simple mechanism to exchange this 248 information. 250 4. Requirements for PCEP extension 252 Following key requirements associated with link-state (and TE) 253 distribution are identified for PCEP: 255 1. The PCEP speaker supporting this draft MUST be a mechanism to 256 advertise the Link-State (and TE) distribution capability. 258 2. PCC supporting this draft MUST have the capability to report the 259 link-state (and TE) information to the PCE. This includes self 260 originated information and remote information learned via routing 261 protocols. PCC MUST be capable to do the initial bulk sync at 262 the time of session initialization as well as changes after. 264 3. A PCE MAY learn link-state (and TE) from PCEP as well as from 265 existing mechanism like IGP/BGP-LS. PCEP extension MUST have a 266 mechanism to link the information learned via other means. There 267 MUST NOT be any changes to the existing link-state (and TE) 268 population mechanism via IGP/BGP-LS. PCEP extension SHOULD keep 269 the properties in a protocol (IGP or BGP-LS) neutral way, such 270 that an implementation may not need to know about any OSPF or IS- 271 IS or BGP protocol specifics. 273 4. It SHOULD be possible to encode only the changes in link-state 274 (and TE) properties (after the initial sync) in PCEP messages. 276 5. The same mechanism should be used for both MPLS TE as well as 277 GMPLS, optical and impairment aware properties. 279 6. The same mechanism should be used for PCE to PCE Link-state (and 280 TE) synchronization. 282 7. The extension in this draft SHOULD be extensible to support 283 various architecture options listed in 284 [I-D.leedhody-teas-pcep-ls]. 286 5. New Functions to distribute link-state (and TE) via PCEP 288 Several new functions are required in PCEP to support distribution of 289 link-state (and TE) information. A function can be initiated either 290 from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). 291 The new functions are: 293 o Capability advertisement (E-C,C-E): both the PCC and the PCE must 294 announce during PCEP session establishment that they support PCEP 295 extensions for distribution of link-state (and TE) information 296 defined in this document. 298 o Link-State (and TE) synchronization (C-E): after the session 299 between the PCC and a PCE is initialized, the PCE must learn Link- 300 State (and TE) information before it can perform path 301 computations. In case of stateful PCE it is RECOMENDED that this 302 operation be done before LSP state synchronization. 304 o Link-State (and TE) Report (C-E): a PCC sends a LS (and TE) report 305 to a PCE whenever the Link-State and TE information changes. 307 6. Overview of Extension to PCEP 309 6.1. New Messages 311 In this document, we define a new PCEP messages called LS Report 312 (LSRpt), a PCEP message sent by a PCC to a PCE to report link-state 313 (and TE) information. Each LS Report in a LSRpt message can contain 314 the node or link properties. An unique PCEP specific LS identifier 315 (LS-ID) is also carried in the message to identify a node or link and 316 that remains constant for the lifetime of a PCEP session. This 317 identifier on its own is sufficient when no IGP or BGP-LS running in 318 the network for PCE to learn link-state (and TE) information. Incase 319 PCE learns some information from PCEP and some from the existing 320 mechanism, the PCC SHOULD include the mapping of IGP or BGP-LS 321 identifier to map the information populated via PCEP with IGP/BGP-LS. 322 See Section 8.1 for details. 324 6.2. Capability Advertisement 326 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 327 advertise their support of LS (and TE) distribution via PCEP 328 extensions. A PCEP Speaker includes the "LS Capability" TLV, 329 described in Section 9.1.1, in the OPEN Object to advertise its 330 support for PCEP-LS extensions. The presence of the LS Capability 331 TLV in PCC's OPEN Object indicates that the PCC is willing to send LS 332 Reports whenever local link-state (and TE) information changes. The 333 presence of the LS Capability TLV in PCE's OPEN message indicates 334 that the PCE is interested in receiving LS Reports whenever local 335 link-state (and TE) information changes. 337 The PCEP protocol extensions for LS (and TE) distribution MUST NOT be 338 used if one or both PCEP Speakers have not included the LS Capability 339 TLV in their respective OPEN message. If the PCE that supports the 340 extensions of this draft but did not advertise this capability, then 341 upon receipt of a LSRpt message from the PCC, it SHOULD generate a 342 PCErr with error-type 19 (Invalid Operation), error-value TBD1 343 (Attempted LS Report if LS capability was not advertised) and it will 344 terminate the PCEP session. 346 The LS reports sent by PCC MAY carry the remote link-state (and TE) 347 information learned via existing means like IGP and BGP-LS only if 348 both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV 349 to 'Remote Allowed (R Flag = 1)'. If this is not the case and LS 350 reports carry remote link-state (and TE) information, then a PCErr 351 with error-type 19 (Invalid Operation) and error-value TBD1 352 (Attempted LS Report if LS remote capability was not advertised) and 353 it will terminate the PCEP session. 355 6.3. Initial Link-State (and TE) Synchronization 357 The purpose of LS Synchronization is to provide a checkpoint-in- time 358 state replica of a PCC's link-state (and TE) data base in a PCE. 359 State Synchronization is performed immediately after the 360 Initialization phase (see [RFC5440]]). In case of stateful PCE 361 ([I-D.ietf-pce-stateful-pce]) it is RECOMENDED that the LS 362 synchronization should be done before LSP state synchronization. 364 During LS Synchronization, a PCC first takes a snapshot of the state 365 of its database, then sends the snapshot to a PCE in a sequence of LS 366 Reports. Each LS Report sent during LS Synchronization has the SYNC 367 Flag in the LS Object set to 1. The end of synchronization marker is 368 a LSRpt message with the SYNC Flag set to 0 for an LS Object with LS- 369 ID equal to the reserved value 0. If the PCC has no link-state to 370 synchronize, it will only send the end of synchronization marker. 372 Either the PCE or the PCC MAY terminate the session using the PCEP 373 session termination procedures during the synchronization phase. If 374 the session is terminated, the PCE MUST clean up state it received 375 from this PCC. The session re-establishment MUST be re-attempted per 376 the procedures defined in [RFC5440], including use of a back-off 377 timer. 379 If the PCC encounters a problem which prevents it from completing the 380 LS synchronization, it MUST send a PCErr message with error-type TBD2 381 (LS Synchronization Error) and error-value 2 (indicating an internal 382 PCC error) to the PCE and terminate the session. 384 The PCE does not send positive acknowledgements for properly received 385 LS synchronization messages. It MUST respond with a PCErr message 386 with error-type TBD2 (LS Synchronization Error) and error-value 1 387 (indicating an error in processing the LSRpt) if it encounters a 388 problem with the LS Report it received from the PCC and it MUST 389 terminate the session. 391 The LS reports can carry local as well as remote link-state (and TE) 392 information depending on the R flag in LS capability TLV. 394 The successful LS Synchronization sequences is shown in Figure 1. 396 +-+-+ +-+-+ 397 |PCC| |PCE| 398 +-+-+ +-+-+ 399 | | 400 |-----LSRpt, SYNC=1----->| (Sync start) 401 | | 402 |-----LSRpt, SYNC=1----->| 403 | . | 404 | . | 405 | . | 406 |-----LSRpt, SYNC=1----->| 407 | . | 408 | . | 409 | . | 410 | | 411 |-----LSRpt, SYNC=0----->| (End of sync marker 412 | | LS Report 413 | | for LS-ID=0) 414 | | (Sync done) 416 Figure 1: Successful LS synchronization 418 The sequence where the PCE fails during the LS Synchronization phase 419 is shown in Figure 2. 421 +-+-+ +-+-+ 422 |PCC| |PCE| 423 +-+-+ +-+-+ 424 | | 425 |-----LSRpt, SYNC=1----->| 426 | | 427 |-----LSRpt, SYNC=1----->| 428 | . | 429 | . | 430 | . | 431 |-----LSRpt, SYNC=1----->| 432 | | 433 |---LSRpt,SYNC=1 | 434 | \ ,-PCErr---| 435 | \ / | 436 | \/ | 437 | /\ | 438 | / `-------->| (Ignored) 439 |<--------` | 441 Figure 2: Failed LS synchronization (PCE failure) 443 The sequence where the PCC fails during the LS Synchronization phase 444 is shown in Figure 3. 446 +-+-+ +-+-+ 447 |PCC| |PCE| 448 +-+-+ +-+-+ 449 | | 450 |-----LSRpt, SYNC=1----->| 451 | | 452 |-----LSRpt, SYNC=1----->| 453 | . | 454 | . | 455 | . | 456 |-------- PCErr--------->| 457 | | 459 Figure 3: Failed LS synchronization (PCC failure) 461 6.3.1. Optimizations for LS Synchronization 463 These optimizations are described in 464 [I-D.kondreddy-pce-pcep-ls-sync-optimizations]. 466 6.4. LS Report 468 The PCC MUST report any changes in the link-state (and TE) 469 information to the PCE by sending a LS Report carried on a LSRpt 470 message to the PCE. Each node and Link would be uniquely identified 471 by a PCEP LS identifier (LS-ID). The LS reports may carry local as 472 well as remote link-state (and TE) information depending on the R 473 flag in LS capability TLV. In case R flag is set, It MAY also 474 include the mapping of IGP or BGP-LS identifier to map the 475 information populated via PCEP with IGP/BGP-LS. 477 More details about LSRpt message are in Section 8.1. 479 7. Transport 481 A permanent PCEP session MUST be established between a PCE and PCC 482 supporting link-state (and TE) distribution via PCEP. In the case of 483 session failure, session re-establishment MUST be re-attempted per 484 the procedures defined in [RFC5440]. 486 8. PCEP Messages 488 As defined in [RFC5440], a PCEP message consists of a common header 489 followed by a variable-length body made of a set of objects that can 490 be either mandatory or optional. An object is said to be mandatory 491 in a PCEP message when the object must be included for the message to 492 be considered valid. For each PCEP message type, a set of rules is 493 defined that specify the set of objects that the message can carry. 494 An implementation MUST form the PCEP messages using the object 495 ordering specified in this document. 497 8.1. LS Report Message 499 A PCEP LS Report message (also referred to as LSRpt message) is a 500 PCEP message sent by a PCC to a PCE to report the link-state (and TE) 501 information. A LSRpt message can carry more than one LS Reports. 502 The Message-Type field of the PCEP common header for the LSRpt 503 message is set to [TBD3]. 505 The format of the LSRpt message is as follows: 507 ::= 508 509 Where: 511 ::= [] 512 The LS object is a mandatory object which carries LS information of a 513 node or a link. Each LS object has an unique LS-ID as described in 514 Section 9.2. If the LS object is missing, the receiving PCE MUST 515 send a PCErr message with Error-type=6 (Mandatory Object missing) and 516 Error-value=[TBD4] (LS object missing). 518 A PCE may choose to implement a limit on the LS information a single 519 PCC can populate. If a LSRpt is received that causes the PCE to 520 exceed this limit, it MUST send a PCErr message with error-type 19 521 (invalid operation) and error-value 4 (indicating resource limit 522 exceeded) in response to the LSRpt message triggering this condition 523 and SHOULD terminate the session. 525 8.2. The PCErr Message 527 If a PCEP speaker has advertised the LS capability on the PCEP 528 session, the PCErr message MAY include the LS object. If the error 529 reported is the result of an LS report, then the LS-ID number MUST be 530 the one from the LSRpt that triggered the error. 532 The format of a PCErr message from [RFC5440] is extended as follows: 534 The format of the PCErr message is as follows: 536 ::= 537 ( [] ) | 538 [] 540 ::=[] 542 ::=[ | ] 543 545 ::=[] 547 ::=[] 549 ::=[] 551 9. Objects and TLV 553 The PCEP objects defined in this document are compliant with the PCEP 554 object format defined in [RFC5440]. The P flag and the I flag of the 555 PCEP objects defined in this document MUST always be set to 0 on 556 transmission and MUST be ignored on receipt since these flags are 557 exclusively related to path computation requests. 559 9.1. Open Object 561 This document defines a new optional TLV for use in the OPEN Object. 563 9.1.1. LS Capability TLV 565 The LS-CAPABILITY TLV is an optional TLV for use in the OPEN Object 566 for link-state (and TE) distribution via PCEP capability 567 advertisement. Its format is shown in the following figure: 569 0 1 2 3 570 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type=[TBD5] | Length=4 | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Flags |R| 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 The type of the TLV is [TBD5] and it has a fixed length of 4 octets. 579 The value comprises a single field - Flags (32 bits): 581 o R (remote - 1 bit): if set to 1 by a PCC, the R Flag indicates 582 that the PCC allows reporting of remote LS information learned via 583 other means like IGP and BGP-LS; if set to 1 by a PCE, the R Flag 584 indicates that the PCE is capable of receiving remote LS 585 information (from the PCC point of view). The R Flag must be 586 advertised by both a PCC and a PCE for LSRpt messages to report 587 remote as well as local LS information on a PCEP session. The 588 TLVs related to IGP/BGP-LS identifier MUST be encoded when both 589 PCEP speakers have the R Flag set. 591 Unassigned bits are considered reserved. They MUST be set to 0 on 592 transmission and MUST be ignored on receipt. 594 Advertisement of the LS capability implies support of local link- 595 state (and TE) distribution, as well as the objects, TLVs and 596 procedures defined in this document. 598 9.2. LS Object 600 The LS (link-state) object MUST be carried within LSRpt messages and 601 MAY be carried within PCErr messages. The LS object contains a set 602 of fields used to specify the target node or link. It also contains 603 a flag indicating to a PCE that the LS synchronization is in 604 progress. The TLVs used with the LS object correlate with the IGP/ 605 BGP-LS encodings. 607 LS Object-Class is [TBD6]. 609 Four Object-Type values are defined for the LS object so far: 611 o LS Node: LS Object-Type is 1. 613 o LS Link: LS Object-Type is 2. 615 o LS IPv4 Topology Prefix: LS Object-Type is 3. 617 o LS IPv6 Topology Prefix: LS Object-Type is 4. 619 The format of all types of LS object is as follows: 621 0 1 2 3 622 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Protocol-ID | Flag |R|S| 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | LS-ID | 627 | | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 // TLVs // 630 | | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Protocol-ID (8-bit): The field provide the source information. 634 Incase PCC only provides local information (R flag is not set), it 635 MUST use Protocol-ID as Direct. The following values are defined 636 (same as [RFC7752]): 638 +-------------+----------------------------------+ 639 | Protocol-ID | Source protocol | 640 +-------------+----------------------------------+ 641 | 1 | IS-IS Level 1 | 642 | 2 | IS-IS Level 2 | 643 | 3 | OSPFv2 | 644 | 4 | Direct | 645 | 5 | Static configuration | 646 | 6 | OSPFv3 | 647 | 7 | BGP-LS | 648 +-------------+----------------------------------+ 650 Flags (24-bit): 652 o S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSRpt sent 653 from a PCC during LS Synchronization. The S Flag MUST be set to 0 654 in other LSRpt messages sent from the PCC. 656 o R (Remove - 1 bit): On LSRpt messages the R Flag indicates that 657 the node/link/prefix has been removed from the PCC and the PCE 658 SHOULD remove from its database. Upon receiving an LS Report with 659 the R Flag set to 1, the PCE SHOULD remove all state for the 660 node/link/prefix identified by the LS Identifiers from its 661 database. 663 LS-ID(64-bit): A PCEP-specific identifier for the node or link or 664 prefix information. A PCC creates an unique LS-ID for each 665 node/link/prefix that is constant for the lifetime of a PCEP session. 666 The PCC will advertise the same LS-ID on all PCEP sessions it 667 maintains at a given times. All subsequent PCEP messages then 668 address the node/link/prefix by the LS-ID. The values of 0 and 669 0xFFFFFFFFFFFFFFFF are reserved. 671 Unassigned bits are considered reserved. They MUST be set to 0 on 672 transmission and MUST be ignored on receipt. 674 TLVs that may be included in the LS Object are described in the 675 following sections. 677 9.2.1. Routing Universe TLV 679 In case of remote link-state (and TE) population when existing IGP/ 680 BGP-LS are also used, OSPF and IS-IS may run multiple routing 681 protocol instances over the same link as described in [RFC7752]. See 682 [RFC6822] and [RFC6549] for more information. These instances define 683 independent "routing universes". The 64-Bit 'Identifier' field is 684 used to identify the "routing universe" where the LS object belongs. 685 The LS objects representing IGP objects (nodes or links or prefix) 686 from the same routing universe MUST have the same 'Identifier' value; 687 LS objects with different 'Identifier' values MUST be considered to 688 be from different routing universes. 690 The format of the optional ROUTING-UNIVERSE TLV is shown in the 691 following figure: 693 0 1 2 3 694 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Type=[TBD7] | Length=8 | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Identifier | 699 | | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Below table lists the 'Identifier' values that are defined as well- 703 known in this draft (same as [RFC7752]). 705 +------------+-----------------------------------+ 706 | Identifier | Routing Universe | 707 +------------+-----------------------------------+ 708 | 0 | Default Layer 3 Routing topology | 709 | 1-31 | Reserved | 710 +------------+-----------------------------------+ 712 If this TLV is not present the default value 0 is assumed. 714 9.2.2. Route Distinguisher TLV 716 Tho allow identification of VPN link, node and prefix information in 717 PCEP-LS, a Route Distinguisher (RD) [RFC4364] is used. The LS 718 objects from the same VPN MUST have the same RD; LS objects with 719 different RD values MUST be considered to be from different VPNs. 721 The format of the optional ROUTE-DISTINGUISHER TLV is shown in the 722 following figure: 724 0 1 2 3 725 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Type=[TBD15] | Length=8 | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Route Distinguisher | 730 | | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 The format of RD is as per [RFC4364]. 735 9.2.3. Virtual Network TLV 737 To realize ACTN, the MDSC needs to build an multi-domain topology. 738 This topology is best served, if this is an abstracted view of the 739 underlying network resources of each domain. It is also important to 740 provide a customer view of network slice for each customer. There is 741 a need to control the level of abstraction based on the deployment 742 scenario and business relationship between the controllers. 744 Virtual service coordination function in ACTN incorporates customer 745 service-related knowledge into the virtual network operations in 746 order to seamlessly operate virtual networks while meeting customer's 747 service requirements. [I-D.ietf-teas-actn-requirements] describes 748 various VN operations initiated by a customer/application. In this 749 context, there is a need for associating the abstracted link state 750 and TE topology with a VN "construct" to facilitate VN operations in 751 PCE architecture. 753 VIRTUAL-NETWORK-TLV as per [I-D.leedhody-pce-vn-association] can be 754 included in LS object to identify the link, node and prefix 755 information belongs to a particular VN. 757 9.2.4. Local Node Descriptors TLV 759 As described in [RFC7752], each link is anchored by a pair of Router- 760 IDs that are used by the underlying IGP, namely, 48 Bit ISO System-ID 761 for IS-IS and 32 bit Router-ID for OSPFv2 and OSPFv3. Incase of 762 additional auxiliary Router-IDs used for TE, these MUST also be 763 included in the link attribute TLV (see Section 9.2.10.2). 765 It is desirable that the Router-ID assignments inside the Node 766 Descriptor are globally unique. Some considerations for globally 767 unique Node/Link/Prefix identifiers are described in [RFC7752]. 769 The Local Node Descriptors TLV contains Node Descriptors for the node 770 anchoring the local end of the link. This TLV MUST be included in 771 the LS Report when during a given PCEP session a node/link/prefix is 772 first reported to a PCE. A PCC sends to a PCE the first LS Report 773 either during State Synchronization, or when a new node/link/prefix 774 is learned at the PCC. The value contains one or more Node 775 Descriptor Sub-TLVs, which allows specification of a flexible key for 776 any given node/link/prefix information such that global uniqueness of 777 the node/link/prefix is ensured. 779 This TLV is applicable for all LS Object-Type. 781 0 1 2 3 782 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Type=[TBD8] | Length | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | | 787 // Node Descriptor Sub-TLVs (variable) // 788 | | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 The value contains one or more Node Descriptor Sub-TLVs defined in 792 Section 9.2.6. 794 9.2.5. Remote Node Descriptors TLV 796 The Remote Node Descriptors contains Node Descriptors for the node 797 anchoring the remote end of the link. This TLV MUST be included in 798 the LS Report when during a given PCEP session a link is first 799 reported to a PCE. A PCC sends to a PCE the first LS Report either 800 during State Synchronization, or when a new link is learned at the 801 PCC. The length of this TLV is variable. The value contains one or 802 more Node Descriptor Sub-TLVs defined in Section 9.2.6. 804 This TLV is applicable for LS Link Object-Type. 806 0 1 2 3 807 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Type=[TBD9] | Length | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | | 812 // Node Descriptor Sub-TLVs (variable) // 813 | | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 9.2.6. Node Descriptors Sub-TLVs 818 The Node Descriptor Sub-TLV type Type and lengths are listed in the 819 following table: 821 +--------------------+-------------------+----------+ 822 | Sub-TLV | Description | Length | 823 +--------------------+-------------------+----------+ 824 | 0 | Reserved | - | 825 | 1 | Autonomous System | 4 | 826 | 2 | BGP-LS Identifier | 4 | 827 | 3 | OSPF Area-ID | 4 | 828 | 4 | IGP Router-ID | Variable | 829 | 5 | Multi-Topology-ID | Variable | 830 +--------------------+-------------------+----------+ 832 The sub-TLV values in Node Descriptor TLVs are defined as follows 833 (similar to [RFC7752]): 835 o Autonomous System: opaque value (32 Bit AS Number) 837 o BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 838 ASN, uniquely identifies the BGP-LS domain as described in 839 [RFC7752]. This sub-TLV is present only if the node implements 840 BGP-LS and the ID is set by the operator. 842 o OSPF Area ID: It is used to identify the 32 Bit area to which the 843 LS object belongs. Area Identifier allows the different LS 844 objects of the same node to be discriminated. 846 o IGP Router ID: opaque value. Usage is described in [RFC7752] for 847 IGP Router ID. In case only local information is transported and 848 PCE learns link-state (and TE) information only from PCEP, it 849 contain the unique local TE IPv4 or IPv6 router ID. 851 o Multi-Topology-ID: Usage is described in [RFC7752] for MT-ID. 853 o There can be at most one instance of each sub-TLV type present in 854 any Node Descriptor. 856 9.2.7. Multi-Topology ID TLV 858 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 859 Multi-Topology IDs for a link, node or prefix. The semantics of the 860 IS-IS MT-ID are defined in Section 7.2 of [RFC5120]. The MT-ID TLV 861 MAY be present in a Link Descriptor, a Prefix Descriptor, or in the 862 attribute of a node (Node Attributes TLV) in LS object. 864 The format and handling of the MT-ID TLV is as defined in [RFC7752]. 866 In a Link or Prefix Descriptor, only a single MT-ID TLV containing 867 the MT-ID of the topology where the link or the prefix is reachable 868 is allowed. In case one wants to advertise multiple topologies for a 869 given Link Descriptor or Prefix Descriptor, multiple reports need to 870 be generated where each LS object contains an unique MT-ID. In the 871 attribute of a node (Node Attributes TLV) in LS object, one MT-ID TLV 872 containing the array of MT-IDs of all topologies where the node is 873 reachable is allowed. 875 9.2.8. Link Descriptors TLV 877 The Link Descriptors TLV contains Link Descriptors for each link. 878 This TLV MUST be included in the LS Report when during a given PCEP 879 session a link is first reported to a PCE. A PCC sends to a PCE the 880 first LS Report either during State Synchronization, or when a new 881 link is learned at the PCC. The length of this TLV is variable. The 882 value contains one or more Link Descriptor Sub-TLVs. 884 The 'Link descriptor' TLVs uniquely identify a link among multiple 885 parallel links between a pair of anchor routers similar to [RFC7752]. 887 This TLV is applicable for LS Link Object-Type. 889 0 1 2 3 890 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Type=[TBD10] | Length | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | | 895 // Link Descriptor Sub-TLVs (variable) // 896 | | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 The Link Descriptor Sub-TLV type and lengths are listed in the 900 following table: 902 +-----------+---------------------+---------------+-----------------+ 903 | Sub-TLV | Description | IS-IS TLV | Value defined | 904 | | | /Sub-TLV | in: | 905 +-----------+---------------------+---------------+-----------------+ 906 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 907 | | Identifiers | | | 908 | 7 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 909 | | address | | | 910 | 8 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 911 | | address | | | 912 | 9 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 913 | | address | | | 914 | 10 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 915 | | address | | | 916 | 5 | Multi-Topology | - | [RFC7752]/ | 917 | | identifier | | 3.2.1.5 | 918 +-----------+---------------------+---------------+-----------------+ 920 The format and semantics of the 'value' fields in most 'Link 921 Descriptor' sub-TLVs correspond to the format and semantics of value 922 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 923 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 924 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 925 carry data sourced either by IS-IS or OSPF or direct. 927 The information about a link present in the LSA/LSP originated by the 928 local node of the link determines the set of sub-TLVs in the Link 929 Descriptor of the link as described in [RFC7752]. 931 9.2.9. Prefix Descriptors TLV 933 The Prefix Descriptors TLV contains Prefix Descriptors uniquely 934 identify an IPv4 or IPv6 Prefix originated by a Node. This TLV MUST 935 be included in the LS Report when during a given PCEP session a 936 prefix is first reported to a PCE. A PCC sends to a PCE the first LS 937 Report either during State Synchronization, or when a new prefix is 938 learned at the PCC. The length of this TLV is variable. 940 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 941 IPv6. 943 0 1 2 3 944 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Type=[TBD11] | Length | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | | 949 // Prefix Descriptor Sub-TLVs (variable) // 950 | | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 The value contains one or more Prefix Descriptor Sub-TLVs defined 954 below - 956 +--------------+-----------------------+----------+-----------------+ 957 | TLV Code | Description | Length | Value defined | 958 | Point | | | in: | 959 +--------------+-----------------------+----------+-----------------+ 960 | 5 | Multi-Topology | variable | [RFC7752] | 961 | | Identifier | | /3.2.1.5 | 962 | 11 | OSPF Route Type | 1 | [RFC7752] | 963 | | | | /3.2.3.1 | 964 | 12 | IP Reachability | variable | [RFC7752] | 965 | | Information | | /3.2.3.2 | 966 +--------------+-----------------------+----------+-----------------+ 968 9.2.10. PCEP-LS Attributes 970 9.2.10.1. Node Attributes TLV 972 This is an optional attribute that is used to carry node attributes. 973 This TLV is applicable for LS Node Object-Type. 975 0 1 2 3 976 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Type=[TBD12] | Length | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | | 981 // Node Attributes Sub-TLVs (variable) // 982 | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 The Node Attributes Sub-TLV type and lengths are listed in the 986 following table: 988 +--------------+-----------------------+----------+-----------------+ 989 | Sub TLV | Description | Length | Value defined | 990 | | | | in: | 991 +--------------+-----------------------+----------+-----------------+ 992 | 5 | Multi-Topology | variable | [RFC7752] | 993 | | Identifier | | /3.2.1.5 | 994 | 13 | Node Flag Bits | 1 | [RFC7752] | 995 | | | | /3.3.1.1 | 996 | 14 | Opaque Node | variable | [RFC7752] | 997 | | Properties | | /3.3.1.5 | 998 | 15 | Node Name | variable | [RFC7752] | 999 | | | | /3.3.1.3 | 1000 | 16 | IS-IS Area Identifier | variable | [RFC7752] | 1001 | | | | /3.3.1.2 | 1002 | 17 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 1003 | | Local Node | | | 1004 | 18 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 1005 | | Local Node | | | 1006 +--------------+-----------------------+----------+-----------------+ 1008 9.2.10.2. Link Attributes TLV 1010 This TLV is applicable for LS Link Object-Type. The format and 1011 semantics of the 'value' fields in some 'Link Attribute' sub-TLVs 1012 correspond to the format and semantics of value fields in IS-IS 1013 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307] 1014 and [RFC7752]. Although the encodings for 'Link Attribute' TLVs were 1015 originally defined for IS-IS, the TLVs can carry data sourced either 1016 by IS-IS or OSPF or direct. 1018 0 1 2 3 1019 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Type=[TBD13] | Length | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | | 1024 // Link Attributes Sub-TLVs (variable) // 1025 | | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 The following 'Link Attribute' sub-TLVs are valid : 1030 +-----------+---------------------+--------------+------------------+ 1031 | Sub-TLV | Description | IS-IS TLV | Defined in: | 1032 | | | /Sub-TLV | | 1033 | | | BGP-LS TLV | | 1034 +-----------+---------------------+--------------+------------------+ 1035 | 17 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1036 | | Local Node | | | 1037 | 18 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1038 | | Local Node | | | 1039 | 19 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1040 | | Remote Node | | | 1041 | 20 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1042 | | Remote Node | | | 1043 | 21 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1044 | | Identifiers | | | 1045 | 22 | Administrative | 22/3 | [RFC5305]/3.1 | 1046 | | group (color) | | | 1047 | 23 | Maximum link | 22/9 | [RFC5305]/3.3 | 1048 | | bandwidth | | | 1049 | 24 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1050 | | link bandwidth | | | 1051 | 25 | Unreserved | 22/11 | [RFC5305]/3.6 | 1052 | | bandwidth | | | 1053 | 26 | TE Default Metric | 22/18 | [RFC7752] | 1054 | | | | /3.3.2.3 | 1055 | 27 | Link Protection | 22/20 | [RFC5307]/1.2 | 1056 | | Type | | | 1057 | 28 | MPLS Protocol Mask | 1094 | [RFC7752] | 1058 | | | | /3.3.2.2 | 1059 | 29 | IGP Metric | 1095 | [RFC7752] | 1060 | | | | /3.3.2.4 | 1061 | 30 | Shared Risk Link | 1096 | [RFC7752] | 1062 | | Group | | /3.3.2.5 | 1063 | 31 | Opaque link | 1097 | [RFC7752] | 1064 | | attributes | | /3.3.2.6 | 1065 | 32 | Link Name attribute | 1098 | [RFC7752] | 1066 | | | | /3.3.2.7 | 1067 | 33 | Unidirectional | 22/33 | [RFC7810]/4.1 | 1068 | | Link Delay | | | 1069 | 34 | Min/Max | 22/34 | [RFC7810]/4.2 | 1070 | | Unidirectional Link | | | 1071 | | Delay | | | 1072 | 35 | Unidirectional | 22/35 | [RFC7810]/4.3 | 1073 | | Delay Variation | | | 1074 | 36 | Unidirectional | 22/36 | [RFC7810]/4.4 | 1075 | | Link Loss | | | 1076 | 37 | Unidirectional | 22/37 | [RFC7810]/4.5 | 1077 | | Residual Bandwidth | | | 1078 | 38 | Unidirectional | 22/38 | [RFC7810]/4.6 | 1079 | | Available Bandwidth | | | 1080 | 39 | Unidirectional | 22/39 | [RFC7810]/4.7 | 1081 | | Bandwidth | | | 1082 | | Utilization | | | 1083 | 40 | Extended Admin | 22/14 | [RFC7308]/2.1 | 1084 | | Group (EAG) | | | 1085 +-----------+---------------------+--------------+------------------+ 1087 9.2.10.3. Prefix Attributes TLV 1089 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 1090 IPv6. Prefixes are learned from the IGP (IS-IS or OSPF) or BGP 1091 topology with a set of IGP attributes (such as metric, route tags, 1092 etc.). This section describes the different attributes related to 1093 the IPv4/IPv6 prefixes. Prefix Attributes TLVs SHOULD be encoded in 1094 the LS Prefix Object. 1096 0 1 2 3 1097 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Type=[TBD14] | Length | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | | 1102 // Prefix Attributes Sub-TLVs (variable) // 1103 | | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 The following 'Prefix Attribute' sub-TLVs are valid : 1108 +-----------+---------------------+--------------+------------------+ 1109 | Sub-TLV | Description | BGP-LS TLV | Defined in: | 1110 +-----------+---------------------+--------------+------------------+ 1111 | 41 | IGP Flags | 1152 | [RFC7752] | 1112 | | | | /3.3.3.1 | 1113 | 42 | Route Tag | 1153 | [RFC7752] | 1114 | | | | /3.3.3.2 | 1115 | 43 | Extended Tag | 1154 | [RFC7752] | 1116 | | | | /3.3.3.3 | 1117 | 44 | Prefix Metric | 1155 | [RFC7752] | 1118 | | | | /3.3.3.4 | 1119 | 45 | OSPF Forwarding | 1156 | [RFC7752] | 1120 | | Address | | /3.3.3.5 | 1121 | 46 | Opaque Prefix | 1157 | [RFC7752] | 1122 | | Attribute | | /3.3.3.6 | 1123 +-----------+---------------------+--------------+------------------+ 1125 9.2.11. Removal of an Attribute 1127 One of a key objective of PCEP-LS is to encode and carry only the 1128 impacted attributes of a Node, a Link or a Prefix. To accommodate 1129 this requirement, incase of a removal of an attribute, the sub-TLV 1130 MUST be included with no 'value' field and length=0 to indicate that 1131 the attribute is removed. On receiving a sub-TLV with zero length, 1132 the receiver removes the attribute from the database. 1134 10. Other Considerations 1136 10.1. Inter-AS Links 1138 The main source of LS (and TE) information is the IGP, which is not 1139 active on inter-AS links. In some cases, the IGP may have 1140 information of inter-AS links ([RFC5392], [RFC5316]). In other 1141 cases, an implementation SHOULD provide a means to inject inter-AS 1142 links into PCEP. The exact mechanism used to provision the inter-AS 1143 links is outside the scope of this document. 1145 11. Processing Rules 1147 12. Security Considerations 1149 This document extends PCEP for LS (and TE) distribution including a 1150 new LSRpt message with new object and TLVs. Procedures and protocol 1151 extensions defined in this document do not effect the overall PCEP 1152 security model. See [RFC5440], [I-D.ietf-pce-pceps]. Tampering with 1153 the LSRpt message may have an effect on path computations at PCE. It 1154 also provides adversaries an opportunity to eavesdrop and learn 1155 sensitive information and plan sophisticated attacks on the network 1156 infrastructure. The PCE implementation SHOULD provide mechanisms to 1157 prevent strains created by network flaps and amount of LS (and TE) 1158 information. Thus it is suggested that any mechanism used for 1159 securing the transmission of other PCEP message be applied here as 1160 well. As a general precaution, it is RECOMMENDED that these PCEP 1161 extensions only be activated on authenticated and encrypted sessions 1162 belonging to the same administrative authority. 1164 13. Manageability Considerations 1166 13.1. Control of Function and Policy 1168 TBD. 1170 13.2. Information and Data Models 1172 TBD. 1174 13.3. Liveness Detection and Monitoring 1176 TBD. 1178 13.4. Verify Correct Operations 1180 TBD. 1182 13.5. Requirements On Other Protocols 1184 TBD. 1186 13.6. Impact On Network Operations 1188 TBD. 1190 14. IANA Considerations 1192 This document requests IANA actions to allocate code points for the 1193 protocol elements defined in this document. 1195 14.1. PCEP Messages 1197 IANA created a registry for PCEP messages. Each PCEP message has a 1198 message type value. This document defines a new PCEP message value. 1200 Value Meaning Reference 1201 TBD3 LSRpt [This I-D] 1203 14.2. PCEP Objects 1205 This document defines the following new PCEP Object-classes and 1206 Object-values: 1208 Object-Class Value Name Reference 1209 TBD6 LS Object [This I-D] 1210 Object-Type=1 1211 (LS Node) 1212 Object-Type=2 1213 (LS Link) 1214 Object-Type=3 1215 (LS IPv4 Prefix) 1216 Object-Type=4 1217 (LS IPv6 Prefix) 1219 14.3. LS Object 1221 This document requests that a new sub-registry, named "LS Object 1222 Protocol-ID Field", is created within the "Path Computation Element 1223 Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP 1224 object. New values are to be assigned by Standards Action [RFC5226]. 1226 Value Meaning Reference 1227 1 IS-IS Level 1 [This I-D] 1228 2 IS-IS Level 2 [This I-D] 1229 3 OSPFv2 [This I-D] 1230 4 Direct [This I-D] 1231 5 Static configuration [This I-D] 1232 6 OSPFv3 [This I-D] 1233 7 BGP-LS [This I-D] 1235 Further, this document also requests that a new sub-registry, named 1236 "LS Object Flag Field", is created within the "Path Computation 1237 Element Protocol (PCEP) Numbers" registry to manage the Flag field of 1238 the LSP object.New values are to be assigned by Standards Action 1239 [RFC5226]. Each bit should be tracked with the following qualities: 1241 o Bit number (counting from bit 0 as the most significant bit) 1243 o Capability description 1245 o Defining RFC 1247 The following values are defined in this document: 1249 Bit Description Reference 1250 0-21 Unassigned 1251 22 R (Remove bit) [This I-D] 1252 23 S (Sync bit) [This I-D] 1254 14.4. PCEP-Error Object 1256 IANA is requested to make the following allocation in the "PCEP-ERROR 1257 Object Error Types and Values" registry. 1259 Error-Type Meaning Reference 1260 6 Mandatory Object missing [RFC5440] 1261 Error-Value=TBD4 [This I-D] 1262 (LS object missing) 1264 19 Invalid Operation [I-D.ietf-pce-stateful-pce] 1265 Error-Value=TBD1 [This I-D] 1266 (Attempted LS Report if LS 1267 remote capability was not 1268 advertised) 1270 TBD2 LS Synchronization Error [This I-D] 1271 Error-Value=1 1272 (An error in processing the 1273 LSRpt) 1274 Error-Value=2 1275 (An internal PCC error) 1277 14.5. PCEP TLV Type Indicators 1279 This document defines the following new PCEP TLVs. 1281 Value Meaning Reference 1282 TBD5 LS-CAPABILITY TLV [This I-D] 1283 TBD7 ROUTING-UNIVERSE TLV [This I-D] 1284 TBD15 ROUTE-DISTINGUISHER TLV [This I-D] 1285 TBD8 Local Node Descriptors TLV [This I-D] 1286 TBD9 Remote Node Descriptors TLV [This I-D] 1287 TBD10 Link Descriptors TLV [This I-D] 1288 TBD11 Prefix Descriptors TLV [This I-D] 1289 TBD12 Node Attributes TLV [This I-D] 1290 TBD13 Link Attributes TLV [This I-D] 1291 TBD14 Prefix Attributes TLV [This I-D] 1293 14.6. PCEP-LS Sub-TLV Type Indicators 1295 This document specifies the PCEP-LS Sub-TLVs. IANA is requested to 1296 create an "PCEP-LS Sub-TLV Types" sub-registry in the "PCEP TLV Type 1297 Indicators" for the sub-TLVs carried in the PCEP-LS TLV (Local and 1298 Remote Node Descriptors TLV, Link Descriptors TLV, Prefix Descriptors 1299 TLV, Node Attributes TLV, Link Attributes TLV and Prefix Attributes 1300 TLV. This document defines the following types: 1302 +-----------+---------------------+---------------+-----------------+ 1303 | Sub-TLV | Description | Ref | Value defined | 1304 | | | Sub-TLV | in: | 1305 +-----------+---------------------+---------------+-----------------+ 1306 | 1 | Autonomous System | 512 | [RFC7752] | 1307 | | | | /3.2.1.4 | 1308 | 2 | BGP-LS Identifier | 513 | [RFC7752] | 1309 | | | | /3.2.1.4 | 1310 | 3 | OSPF Area-ID | 514 | [RFC7752] | 1311 | | | | /3.2.1.4 | 1312 | 4 | IGP Router-ID | 515 | [RFC7752] | 1313 | | | | /3.2.1.4 | 1314 | 5 | Multi-Topology-ID | 263 | [RFC7752] | 1315 | | | | /3.2.1.5 | 1316 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1317 | | Identifiers | | | 1318 | 7 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1319 | | address | | | 1320 | 8 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1321 | | address | | | 1322 | 9 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1323 | | address | | | 1324 | 10 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1325 | | address | | | 1326 | 11 | OSPF Route Type | 264 | [RFC7752] | 1327 | | | | /3.2.3.1 | 1328 | 12 | IP Reachability | 265 | [RFC7752] | 1329 | | Information | | /3.2.3.2 | 1330 | 13 | Node Flag Bits | 1024 | [RFC7752] | 1331 | | | | /3.3.1.1 | 1332 | 14 | Opaque Node | 1025 | [RFC7752] | 1333 | | Properties | | /3.3.1.5 | 1334 | 15 | Node Name | 1026 | [RFC7752] | 1335 | | | | /3.3.1.3 | 1336 | 16 | IS-IS Area | 1027 | [RFC7752] | 1337 | | Identifier | | /3.3.1.2 | 1338 | 17 | IPv4 Router-ID of | 134/-- | [RFC5305]/4.3 | 1339 | | Local Node | | | 1340 | 18 | IPv6 Router-ID of | 140/-- | [RFC6119]/4.1 | 1341 | | Local Node | | | 1342 | 19 | IPv4 Router-ID of | 134/-- | [RFC5305]/4.3 | 1343 | | Remote Node | | | 1344 | 20 | IPv6 Router-ID of | 140/-- | [RFC6119]/4.1 | 1345 | | Remote Node | | | 1346 | 21 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1347 | | Identifiers | | | 1348 | 22 | Administrative | 22/3 | [RFC5305]/3.1 | 1349 | | group (color) | | | 1350 | 23 | Maximum link | 22/9 | [RFC5305]/3.3 | 1351 | | bandwidth | | | 1352 | 24 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1353 | | link bandwidth | | | 1354 | 25 | Unreserved | 22/11 | [RFC5305]/3.6 | 1355 | | bandwidth | | | 1356 | 26 | TE Default Metric | 22/18 | [RFC7752] | 1357 | | | | /3.3.2.3 | 1358 | 27 | Link Protection | 22/20 | [RFC5307]/1.2 | 1359 | | Type | | | 1360 | 28 | MPLS Protocol Mask | 1094 | [RFC7752] | 1361 | | | | /3.3.2.2 | 1362 | 29 | IGP Metric | 1095 | [RFC7752] | 1363 | | | | /3.3.2.4 | 1364 | 30 | Shared Risk Link | 1096 | [RFC7752] | 1365 | | Group | | /3.3.2.5 | 1366 | 31 | Opaque link | 1097 | [RFC7752] | 1367 | | attributes | | /3.3.2.6 | 1368 | 32 | Link Name attribute | 1098 | [RFC7752] | 1369 | | | | /3.3.2.7 | 1370 | 33 | Unidirectional | 22/33 | [RFC7810]/4.1 | 1371 | | Link Delay | | | 1372 | 34 | Min/Max | 22/34 | [RFC7810]/4.2 | 1373 | | Unidirectional Link | | | 1374 | | Delay | | | 1375 | 35 | Unidirectional | 22/35 | [RFC7810]/4.3 | 1376 | | Delay Variation | | | 1377 | 36 | Unidirectional | 22/36 | [RFC7810]/4.4 | 1378 | | Link Loss | | | 1379 | 37 | Unidirectional | 22/37 | [RFC7810]/4.5 | 1380 | | Residual Bandwidth | | | 1381 | 38 | Unidirectional | 22/38 | [RFC7810]/4.6 | 1382 | | Available Bandwidth | | | 1383 | 39 | Unidirectional | 22/39 | [RFC7810]/4.7 | 1384 | | Bandwidth | | | 1385 | | Utilization | | | 1386 | 40 | Extended Admin | 22/14 | [RFC7308]/2.1 | 1387 | | Group (EAG) | | | 1388 | 41 | IGP Flags | 1152 | [RFC7752] | 1389 | | | | /3.3.3.1 | 1390 | 42 | Route Tag | 1153 | [RFC7752] | 1391 | | | | /3.3.3.2 | 1392 | 43 | Extended Tag | 1154 | [RFC7752] | 1393 | | | | /3.3.3.3 | 1394 | 44 | Prefix Metric | 1155 | [RFC7752] | 1395 | | | | /3.3.3.4 | 1396 | 45 | OSPF Forwarding | 1156 | [RFC7752] | 1397 | | Address | | /3.3.3.5 | 1398 | 46 | Opaque Prefix | 1157 | [RFC7752] | 1399 | | Attribute | | /3.3.3.6 | 1400 +-----------+---------------------+---------------+-----------------+ 1402 New values are to be assigned by Standards Action [RFC5226]. 1404 15. TLV/Sub-TLV Code Points Summary 1406 This section contains the global table of all TLVs/Sub-TLVs in LS 1407 object defined in this document. 1409 +-----------+---------------------+---------------+-----------------+ 1410 | TLV | Description | Ref TLV | Value defined | 1411 | | | | in: | 1412 +-----------+---------------------+---------------+-----------------+ 1413 | TBD7 | Routing Universe | -- | Sec 9.2.1 | 1414 | TBD15 | Route | -- | Sec 9.2.2 | 1415 | | Distinguisher | | | 1416 | * | Virtual Network | -- | [leedhody-pce- | 1417 | | | | vn-association] | 1418 | TBD8 | Local Node | 256 | [RFC7752] | 1419 | | Descriptors | | /3.2.1.2 | 1420 | TBD9 | Remote Node | 257 | [RFC7752] | 1421 | | Descriptors | | /3.2.1.3 | 1422 | TBD10 | Link Descriptors | -- | Sec 9.2.8 | 1423 | TBD11 | Prefix Descriptors | -- | Sec 9.2.9 | 1424 | TBD12 | Node Attributes | -- | Sec 9.2.10.1 | 1425 | TBD13 | Link Attributes | -- | Sec 9.2.10.2 | 1426 | TBD14 | Prefix Attributes | -- | Sec 9.2.10.3 | 1427 +-----------+---------------------+---------------+-----------------+ 1429 * this TLV is defined in a different PCEP document 1431 TLV Table 1433 Refer Section 14.6 for the table of Sub-TLVs. 1435 16. Acknowledgments 1437 This document borrows some of the structure and text from the 1438 [RFC7752]. 1440 Thanks to Eric Wu, Venugopal Kondreddy, Mahendra Singh Negi, 1441 Avantika, and Zhengbin Li for the reviews. 1443 17. References 1444 17.1. Normative References 1446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1447 Requirement Levels", BCP 14, RFC 2119, 1448 DOI 10.17487/RFC2119, March 1997, 1449 . 1451 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1452 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1453 2008, . 1455 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1456 in Support of Generalized Multi-Protocol Label Switching 1457 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1458 . 1460 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1461 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1462 DOI 10.17487/RFC5440, March 2009, 1463 . 1465 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1466 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 1467 February 2011, . 1469 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1470 S. Ray, "North-Bound Distribution of Link-State and 1471 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1472 DOI 10.17487/RFC7752, March 2016, 1473 . 1475 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1476 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1477 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1478 . 1480 17.2. Informative References 1482 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1483 (TE) Extensions to OSPF Version 2", RFC 3630, 1484 DOI 10.17487/RFC3630, September 2003, 1485 . 1487 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1488 Support of Generalized Multi-Protocol Label Switching 1489 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1490 . 1492 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1493 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1494 2006, . 1496 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1497 Element (PCE)-Based Architecture", RFC 4655, 1498 DOI 10.17487/RFC4655, August 2006, 1499 . 1501 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1502 Topology (MT) Routing in Intermediate System to 1503 Intermediate Systems (IS-ISs)", RFC 5120, 1504 DOI 10.17487/RFC5120, February 2008, 1505 . 1507 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1508 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1509 DOI 10.17487/RFC5226, May 2008, 1510 . 1512 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1513 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1514 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1515 December 2008, . 1517 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1518 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1519 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 1520 January 2009, . 1522 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1523 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1524 March 2012, . 1526 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1527 Path Computation Element Architecture to the Determination 1528 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1529 DOI 10.17487/RFC6805, November 2012, 1530 . 1532 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 1533 Ward, "IS-IS Multi-Instance", RFC 6822, 1534 DOI 10.17487/RFC6822, December 2012, 1535 . 1537 [I-D.ietf-pce-stateful-pce] 1538 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1539 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1540 pce-14 (work in progress), March 2016. 1542 [I-D.ietf-pce-pce-initiated-lsp] 1543 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1544 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1545 Model", draft-ietf-pce-pce-initiated-lsp-05 (work in 1546 progress), October 2015. 1548 [I-D.ietf-pce-pceps] 1549 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1550 Transport for PCEP", draft-ietf-pce-pceps-09 (work in 1551 progress), March 2016. 1553 [I-D.kondreddy-pce-pcep-ls-sync-optimizations] 1554 Kondreddy, V. and M. Negi, "Optimizations of PCEP Link- 1555 State(LS) Synchronization Procedures", draft-kondreddy- 1556 pce-pcep-ls-sync-optimizations-00 (work in progress), 1557 October 2015. 1559 [I-D.leedhody-teas-pcep-ls] 1560 Lee, Y., Dhody, D., and D. Ceccarelli, "Architecture and 1561 Requirement for Distribution of Link-State and TE 1562 Information via PCEP.", draft-leedhody-teas-pcep-ls-02 1563 (work in progress), March 2016. 1565 [I-D.ietf-teas-actn-framework] 1566 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 1567 Control of Traffic Engineered Networks", draft-ietf-teas- 1568 actn-framework-00 (work in progress), July 2016. 1570 [I-D.ietf-teas-actn-requirements] 1571 Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D. 1572 Ceccarelli, "Requirements for Abstraction and Control of 1573 TE Networks", draft-ietf-teas-actn-requirements-03 (work 1574 in progress), July 2016. 1576 [I-D.leedhody-pce-vn-association] 1577 Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions 1578 for Establishing Relationships Between Sets of LSPs and 1579 Virtual Networks", draft-leedhody-pce-vn-association-00 1580 (work in progress), February 2016. 1582 Appendix A. Contributor Addresses 1584 Udayasree Palle 1585 Huawei Technologies 1586 Divyashree Techno Park, Whitefield 1587 Bangalore, Karnataka 560066 1588 India 1590 EMail: udayasree.palle@huawei.com 1592 Sergio Belotti 1593 Alcatel-Lucent 1594 Italy 1596 EMail: sergio.belotti@alcatel-lucent.com 1598 Veerendranatha Reddy Vallem 1599 Huawei Technologies 1600 Divyashree Techno Park, Whitefield 1601 Bangalore, Karnataka 560066 1602 India 1604 Email: veerendranatharv@huawei.com 1606 Authors' Addresses 1608 Dhruv Dhody 1609 Huawei Technologies 1610 Divyashree Techno Park, Whitefield 1611 Bangalore, Karnataka 560066 1612 India 1614 EMail: dhruv.ietf@gmail.com 1616 Young Lee 1617 Huawei Technologies 1618 5340 Legacy Drive, Building 3 1619 Plano, TX 75023 1620 USA 1622 EMail: leeyoung@huawei.com 1623 Daniele Ceccarelli 1624 Ericsson 1625 Torshamnsgatan,48 1626 Stockholm 1627 Sweden 1629 EMail: daniele.ceccarelli@ericsson.com