idnits 2.17.1 draft-dhodylee-pce-pcep-ls-05.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 5 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 (August 30, 2016) is 2796 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 509, but not defined == Missing Reference: 'TBD5' is mentioned on line 583, but not defined == Missing Reference: 'TBD6' is mentioned on line 613, but not defined == Missing Reference: 'This I-D' is mentioned on line 1275, but not defined == Unused Reference: 'RFC7810' is defined on line 1457, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 1483, 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-15 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-10 == 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 == Outdated reference: A later version (-02) exists of draft-dhody-pce-applicability-actn-00 Summary: 2 errors (**), 0 flaws (~~), 17 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: March 3, 2017 D. Ceccarelli 6 Ericsson 7 August 30, 2016 9 PCEP Extension for Distribution of Link-State and TE Information. 10 draft-dhodylee-pce-pcep-ls-05 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 March 3, 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 . . . . . . . . . . . . . 18 82 9.2.6. Node Descriptors Sub-TLVs . . . . . . . . . . . . . . 18 83 9.2.7. Link Descriptors TLV . . . . . . . . . . . . . . . . 19 84 9.2.8. Prefix Descriptors TLV . . . . . . . . . . . . . . . 20 85 9.2.9. PCEP-LS Attributes . . . . . . . . . . . . . . . . . 21 86 9.2.9.1. Node Attributes TLV . . . . . . . . . . . . . . . 21 87 9.2.9.2. Link Attributes TLV . . . . . . . . . . . . . . . 22 88 9.2.9.3. Prefix Attributes TLV . . . . . . . . . . . . . . 24 89 9.2.10. Removal of an Attribute . . . . . . . . . . . . . . . 25 90 10. Other Considerations . . . . . . . . . . . . . . . . . . . . 25 91 10.1. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 25 92 11. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 25 93 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 94 13. Manageability Considerations . . . . . . . . . . . . . . . . 25 95 13.1. Control of Function and Policy . . . . . . . . . . . . . 25 96 13.2. Information and Data Models . . . . . . . . . . . . . . 26 97 13.3. Liveness Detection and Monitoring . . . . . . . . . . . 26 98 13.4. Verify Correct Operations . . . . . . . . . . . . . . . 26 99 13.5. Requirements On Other Protocols . . . . . . . . . . . . 26 100 13.6. Impact On Network Operations . . . . . . . . . . . . . . 26 101 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 102 14.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . 26 103 14.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 26 104 14.3. LS Object . . . . . . . . . . . . . . . . . . . . . . . 27 105 14.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 27 106 14.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28 107 14.6. PCEP-LS Sub-TLV Type Indicators . . . . . . . . . . . . 28 108 15. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 31 109 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 110 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 111 17.1. Normative References . . . . . . . . . . . . . . . . . . 31 112 17.2. Informative References . . . . . . . . . . . . . . . . . 32 113 Appendix A. Relevant OSPF TLV and sub-TLV . . . . . . . . . . . 36 114 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 37 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 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. To build this domain 190 topology map, the child PCE MAY carry the border nodes and inter- 191 domain link information to the parent PCE using the mechanism 192 described in this document. Further as described in 194 [I-D.dhody-pce-applicability-actn], the child PCE MAY also transport 195 abstract Link-State and TE information from child PCE to a Parent PCE 196 using the mechanism described in this document to build an abstract 197 topology at the parent PCE. 199 [I-D.ietf-pce-stateful-pce] describe LSP state synchronization 200 between PCCs and PCEs in case of stateful PCE. This document does 201 not make any change to the LSP state synchronization process. The 202 mechanism described in this document are on top of the existing LSP 203 state synchronization. 205 1.1. Requirements Language 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [RFC2119]. 211 2. Terminology 213 The terminology is as per [RFC4655] and [RFC5440]. 215 3. Applicability 217 As per [I-D.leedhody-teas-pcep-ls], the mechanism specified in this 218 draft is applicable to: 220 o Where there is no IGP or BGP-LS running in the network. 222 o Where there is no IGP or BGP-LS running at the PCE to learn link- 223 state and TE information. 225 o Where there is IGP or BGP-LS running but with a need for a faster 226 TE and link-state population and convergence at the PCE. 228 * A PCE may receive partial information (say basic TE, link- 229 state) from IGP and other information (optical and impairment) 230 from PCEP. 232 * A PCE may receive an incremental update (as opposed to the 233 entire information of the node/link). 235 * A PCE may receive full information from both existing mechanism 236 (IGP or BGP) and PCEP. 238 o Where there is a need for transporting (abstract) Link-State and 239 TE information from child PCE to a Parent PCE in H-PCE [RFC6805]; 240 as well as for Physical Network Controller (PNC) to Multi-Domain 241 Service Coordinator (MDSC) in Abstraction and Control of TE 242 Networks (ACTN) [I-D.ietf-teas-actn-framework]. 244 A PCC may further choose to send only local information or both local 245 and remote learned information. 247 How a PCE manages the link-state (and TE) information is 248 implementation specific and thus out of scope of this document. 250 The prefix information in PCEP-LS can also help in determining the 251 domain of the endpoints in H-PCE (and ACTN). Section 4.5 of 252 [RFC6805] describe various mechanism and procedures that might be 253 used, PCEP-LS provides a simple mechanism to exchange this 254 information. 256 4. Requirements for PCEP extension 258 Following key requirements associated with link-state (and TE) 259 distribution are identified for PCEP: 261 1. The PCEP speaker supporting this draft MUST be a mechanism to 262 advertise the Link-State (and TE) distribution capability. 264 2. PCC supporting this draft MUST have the capability to report the 265 link-state (and TE) information to the PCE. This includes self 266 originated information and remote information learned via routing 267 protocols. PCC MUST be capable to do the initial bulk sync at 268 the time of session initialization as well as changes after. 270 3. A PCE MAY learn link-state (and TE) from PCEP as well as from 271 existing mechanism like IGP/BGP-LS. PCEP extension MUST have a 272 mechanism to link the information learned via other means. There 273 MUST NOT be any changes to the existing link-state (and TE) 274 population mechanism via IGP/BGP-LS. PCEP extension SHOULD keep 275 the properties in a protocol (IGP or BGP-LS) neutral way, such 276 that an implementation may not need to know about any OSPF or IS- 277 IS or BGP protocol specifics. 279 4. It SHOULD be possible to encode only the changes in link-state 280 (and TE) properties (after the initial sync) in PCEP messages. 282 5. The same mechanism should be used for both MPLS TE as well as 283 GMPLS, optical and impairment aware properties. 285 6. The same mechanism should be used for PCE to PCE Link-state (and 286 TE) synchronization. 288 7. The extension in this draft SHOULD be extensible to support 289 various architecture options listed in 290 [I-D.leedhody-teas-pcep-ls]. 292 5. New Functions to distribute link-state (and TE) via PCEP 294 Several new functions are required in PCEP to support distribution of 295 link-state (and TE) information. A function can be initiated either 296 from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). 297 The new functions are: 299 o Capability advertisement (E-C,C-E): both the PCC and the PCE must 300 announce during PCEP session establishment that they support PCEP 301 extensions for distribution of link-state (and TE) information 302 defined in this document. 304 o Link-State (and TE) synchronization (C-E): after the session 305 between the PCC and a PCE is initialized, the PCE must learn Link- 306 State (and TE) information before it can perform path 307 computations. In case of stateful PCE it is RECOMENDED that this 308 operation be done before LSP state synchronization. 310 o Link-State (and TE) Report (C-E): a PCC sends a LS (and TE) report 311 to a PCE whenever the Link-State and TE information changes. 313 6. Overview of Extension to PCEP 315 6.1. New Messages 317 In this document, we define a new PCEP messages called LS Report 318 (LSRpt), a PCEP message sent by a PCC to a PCE to report link-state 319 (and TE) information. Each LS Report in a LSRpt message can contain 320 the node or link properties. An unique PCEP specific LS identifier 321 (LS-ID) is also carried in the message to identify a node or link and 322 that remains constant for the lifetime of a PCEP session. This 323 identifier on its own is sufficient when no IGP or BGP-LS running in 324 the network for PCE to learn link-state (and TE) information. Incase 325 PCE learns some information from PCEP and some from the existing 326 mechanism, the PCC SHOULD include the mapping of IGP or BGP-LS 327 identifier to map the information populated via PCEP with IGP/BGP-LS. 328 See Section 8.1 for details. 330 6.2. Capability Advertisement 332 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 333 advertise their support of LS (and TE) distribution via PCEP 334 extensions. A PCEP Speaker includes the "LS Capability" TLV, 335 described in Section 9.1.1, in the OPEN Object to advertise its 336 support for PCEP-LS extensions. The presence of the LS Capability 337 TLV in PCC's OPEN Object indicates that the PCC is willing to send LS 338 Reports whenever local link-state (and TE) information changes. The 339 presence of the LS Capability TLV in PCE's OPEN message indicates 340 that the PCE is interested in receiving LS Reports whenever local 341 link-state (and TE) information changes. 343 The PCEP protocol extensions for LS (and TE) distribution MUST NOT be 344 used if one or both PCEP Speakers have not included the LS Capability 345 TLV in their respective OPEN message. If the PCE that supports the 346 extensions of this draft but did not advertise this capability, then 347 upon receipt of a LSRpt message from the PCC, it SHOULD generate a 348 PCErr with error-type 19 (Invalid Operation), error-value TBD1 349 (Attempted LS Report if LS capability was not advertised) and it will 350 terminate the PCEP session. 352 The LS reports sent by PCC MAY carry the remote link-state (and TE) 353 information learned via existing means like IGP and BGP-LS only if 354 both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV 355 to 'Remote Allowed (R Flag = 1)'. If this is not the case and LS 356 reports carry remote link-state (and TE) information, then a PCErr 357 with error-type 19 (Invalid Operation) and error-value TBD1 358 (Attempted LS Report if LS remote capability was not advertised) and 359 it will terminate the PCEP session. 361 6.3. Initial Link-State (and TE) Synchronization 363 The purpose of LS Synchronization is to provide a checkpoint-in- time 364 state replica of a PCC's link-state (and TE) data base in a PCE. 365 State Synchronization is performed immediately after the 366 Initialization phase (see [RFC5440]]). In case of stateful PCE 367 ([I-D.ietf-pce-stateful-pce]) it is RECOMENDED that the LS 368 synchronization should be done before LSP state synchronization. 370 During LS Synchronization, a PCC first takes a snapshot of the state 371 of its database, then sends the snapshot to a PCE in a sequence of LS 372 Reports. Each LS Report sent during LS Synchronization has the SYNC 373 Flag in the LS Object set to 1. The end of synchronization marker is 374 a LSRpt message with the SYNC Flag set to 0 for an LS Object with LS- 375 ID equal to the reserved value 0. If the PCC has no link-state to 376 synchronize, it will only send the end of synchronization marker. 378 Either the PCE or the PCC MAY terminate the session using the PCEP 379 session termination procedures during the synchronization phase. If 380 the session is terminated, the PCE MUST clean up state it received 381 from this PCC. The session re-establishment MUST be re-attempted per 382 the procedures defined in [RFC5440], including use of a back-off 383 timer. 385 If the PCC encounters a problem which prevents it from completing the 386 LS synchronization, it MUST send a PCErr message with error-type TBD2 387 (LS Synchronization Error) and error-value 2 (indicating an internal 388 PCC error) to the PCE and terminate the session. 390 The PCE does not send positive acknowledgements for properly received 391 LS synchronization messages. It MUST respond with a PCErr message 392 with error-type TBD2 (LS Synchronization Error) and error-value 1 393 (indicating an error in processing the LSRpt) if it encounters a 394 problem with the LS Report it received from the PCC and it MUST 395 terminate the session. 397 The LS reports can carry local as well as remote link-state (and TE) 398 information depending on the R flag in LS capability TLV. 400 The successful LS Synchronization sequences is shown in Figure 1. 402 +-+-+ +-+-+ 403 |PCC| |PCE| 404 +-+-+ +-+-+ 405 | | 406 |-----LSRpt, SYNC=1----->| (Sync start) 407 | | 408 |-----LSRpt, SYNC=1----->| 409 | . | 410 | . | 411 | . | 412 |-----LSRpt, SYNC=1----->| 413 | . | 414 | . | 415 | . | 416 | | 417 |-----LSRpt, SYNC=0----->| (End of sync marker 418 | | LS Report 419 | | for LS-ID=0) 420 | | (Sync done) 422 Figure 1: Successful LS synchronization 424 The sequence where the PCE fails during the LS Synchronization phase 425 is shown in Figure 2. 427 +-+-+ +-+-+ 428 |PCC| |PCE| 429 +-+-+ +-+-+ 430 | | 431 |-----LSRpt, SYNC=1----->| 432 | | 433 |-----LSRpt, SYNC=1----->| 434 | . | 435 | . | 436 | . | 437 |-----LSRpt, SYNC=1----->| 438 | | 439 |---LSRpt,SYNC=1 | 440 | \ ,-PCErr---| 441 | \ / | 442 | \/ | 443 | /\ | 444 | / `-------->| (Ignored) 445 |<--------` | 447 Figure 2: Failed LS synchronization (PCE failure) 449 The sequence where the PCC fails during the LS Synchronization phase 450 is shown in Figure 3. 452 +-+-+ +-+-+ 453 |PCC| |PCE| 454 +-+-+ +-+-+ 455 | | 456 |-----LSRpt, SYNC=1----->| 457 | | 458 |-----LSRpt, SYNC=1----->| 459 | . | 460 | . | 461 | . | 462 |-------- PCErr--------->| 463 | | 465 Figure 3: Failed LS synchronization (PCC failure) 467 6.3.1. Optimizations for LS Synchronization 469 These optimizations are described in 470 [I-D.kondreddy-pce-pcep-ls-sync-optimizations]. 472 6.4. LS Report 474 The PCC MUST report any changes in the link-state (and TE) 475 information to the PCE by sending a LS Report carried on a LSRpt 476 message to the PCE. Each node and Link would be uniquely identified 477 by a PCEP LS identifier (LS-ID). The LS reports may carry local as 478 well as remote link-state (and TE) information depending on the R 479 flag in LS capability TLV. In case R flag is set, It MAY also 480 include the mapping of IGP or BGP-LS identifier to map the 481 information populated via PCEP with IGP/BGP-LS. 483 More details about LSRpt message are in Section 8.1. 485 7. Transport 487 A permanent PCEP session MUST be established between a PCE and PCC 488 supporting link-state (and TE) distribution via PCEP. In the case of 489 session failure, session re-establishment MUST be re-attempted per 490 the procedures defined in [RFC5440]. 492 8. PCEP Messages 494 As defined in [RFC5440], a PCEP message consists of a common header 495 followed by a variable-length body made of a set of objects that can 496 be either mandatory or optional. An object is said to be mandatory 497 in a PCEP message when the object must be included for the message to 498 be considered valid. For each PCEP message type, a set of rules is 499 defined that specify the set of objects that the message can carry. 500 An implementation MUST form the PCEP messages using the object 501 ordering specified in this document. 503 8.1. LS Report Message 505 A PCEP LS Report message (also referred to as LSRpt message) is a 506 PCEP message sent by a PCC to a PCE to report the link-state (and TE) 507 information. A LSRpt message can carry more than one LS Reports. 508 The Message-Type field of the PCEP common header for the LSRpt 509 message is set to [TBD3]. 511 The format of the LSRpt message is as follows: 513 ::= 514 515 Where: 517 ::= [] 518 The LS object is a mandatory object which carries LS information of a 519 node or a link. Each LS object has an unique LS-ID as described in 520 Section 9.2. If the LS object is missing, the receiving PCE MUST 521 send a PCErr message with Error-type=6 (Mandatory Object missing) and 522 Error-value=[TBD4] (LS object missing). 524 A PCE may choose to implement a limit on the LS information a single 525 PCC can populate. If a LSRpt is received that causes the PCE to 526 exceed this limit, it MUST send a PCErr message with error-type 19 527 (invalid operation) and error-value 4 (indicating resource limit 528 exceeded) in response to the LSRpt message triggering this condition 529 and SHOULD terminate the session. 531 8.2. The PCErr Message 533 If a PCEP speaker has advertised the LS capability on the PCEP 534 session, the PCErr message MAY include the LS object. If the error 535 reported is the result of an LS report, then the LS-ID number MUST be 536 the one from the LSRpt that triggered the error. 538 The format of a PCErr message from [RFC5440] is extended as follows: 540 The format of the PCErr message is as follows: 542 ::= 543 ( [] ) | 544 [] 546 ::=[] 548 ::=[ | ] 549 551 ::=[] 553 ::=[] 555 ::=[] 557 9. Objects and TLV 559 The PCEP objects defined in this document are compliant with the PCEP 560 object format defined in [RFC5440]. The P flag and the I flag of the 561 PCEP objects defined in this document MUST always be set to 0 on 562 transmission and MUST be ignored on receipt since these flags are 563 exclusively related to path computation requests. 565 9.1. Open Object 567 This document defines a new optional TLV for use in the OPEN Object. 569 9.1.1. LS Capability TLV 571 The LS-CAPABILITY TLV is an optional TLV for use in the OPEN Object 572 for link-state (and TE) distribution via PCEP capability 573 advertisement. Its format is shown in the following figure: 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type=[TBD5] | Length=4 | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Flags |R| 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 The type of the TLV is [TBD5] and it has a fixed length of 4 octets. 585 The value comprises a single field - Flags (32 bits): 587 o R (remote - 1 bit): if set to 1 by a PCC, the R Flag indicates 588 that the PCC allows reporting of remote LS information learned via 589 other means like IGP and BGP-LS; if set to 1 by a PCE, the R Flag 590 indicates that the PCE is capable of receiving remote LS 591 information (from the PCC point of view). The R Flag must be 592 advertised by both a PCC and a PCE for LSRpt messages to report 593 remote as well as local LS information on a PCEP session. The 594 TLVs related to IGP/BGP-LS identifier MUST be encoded when both 595 PCEP speakers have the R Flag set. 597 Unassigned bits are considered reserved. They MUST be set to 0 on 598 transmission and MUST be ignored on receipt. 600 Advertisement of the LS capability implies support of local link- 601 state (and TE) distribution, as well as the objects, TLVs and 602 procedures defined in this document. 604 9.2. LS Object 606 The LS (link-state) object MUST be carried within LSRpt messages and 607 MAY be carried within PCErr messages. The LS object contains a set 608 of fields used to specify the target node or link. It also contains 609 a flag indicating to a PCE that the LS synchronization is in 610 progress. The TLVs used with the LS object correlate with the IGP/ 611 BGP-LS encodings. 613 LS Object-Class is [TBD6]. 615 Four Object-Type values are defined for the LS object so far: 617 o LS Node: LS Object-Type is 1. 619 o LS Link: LS Object-Type is 2. 621 o LS IPv4 Topology Prefix: LS Object-Type is 3. 623 o LS IPv6 Topology Prefix: LS Object-Type is 4. 625 The format of all types of LS object is as follows: 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Protocol-ID | Flag |R|S| 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | LS-ID | 633 | | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 // TLVs // 636 | | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 Protocol-ID (8-bit): The field provide the source information. The 640 protocol could be an IGP, BGP-LS or an abstraction algorithm. Incase 641 PCC only provides local information of the PCC, it MUST use Protocol- 642 ID as Direct. The following values are defined (some of them are 643 same as [RFC7752]): 645 +-------------+----------------------------------+ 646 | Protocol-ID | Source protocol | 647 +-------------+----------------------------------+ 648 | 1 | IS-IS Level 1 | 649 | 2 | IS-IS Level 2 | 650 | 3 | OSPFv2 | 651 | 4 | Direct | 652 | 5 | Static configuration | 653 | 6 | OSPFv3 | 654 | 7 | BGP-LS | 655 | 8 | Abstraction | 656 +-------------+----------------------------------+ 658 Flags (24-bit): 660 o S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSRpt sent 661 from a PCC during LS Synchronization. The S Flag MUST be set to 0 662 in other LSRpt messages sent from the PCC. 664 o R (Remove - 1 bit): On LSRpt messages the R Flag indicates that 665 the node/link/prefix has been removed from the PCC and the PCE 666 SHOULD remove from its database. Upon receiving an LS Report with 667 the R Flag set to 1, the PCE SHOULD remove all state for the 668 node/link/prefix identified by the LS Identifiers from its 669 database. 671 LS-ID(64-bit): A PCEP-specific identifier for the node or link or 672 prefix information. A PCC creates an unique LS-ID for each 673 node/link/prefix that is constant for the lifetime of a PCEP session. 674 The PCC will advertise the same LS-ID on all PCEP sessions it 675 maintains at a given times. All subsequent PCEP messages then 676 address the node/link/prefix by the LS-ID. The values of 0 and 677 0xFFFFFFFFFFFFFFFF are reserved. 679 Unassigned bits are considered reserved. They MUST be set to 0 on 680 transmission and MUST be ignored on receipt. 682 TLVs that may be included in the LS Object are described in the 683 following sections. 685 9.2.1. Routing Universe TLV 687 In case of remote link-state (and TE) population when existing IGP/ 688 BGP-LS are also used, OSPF and IS-IS may run multiple routing 689 protocol instances over the same link as described in [RFC7752]. See 690 [RFC6822] and [RFC6549] for more information. These instances define 691 independent "routing universes". The 64-Bit 'Identifier' field is 692 used to identify the "routing universe" where the LS object belongs. 693 The LS objects representing IGP objects (nodes or links or prefix) 694 from the same routing universe MUST have the same 'Identifier' value; 695 LS objects with different 'Identifier' values MUST be considered to 696 be from different routing universes. 698 The format of the optional ROUTING-UNIVERSE TLV is shown in the 699 following figure: 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Type=[TBD7] | Length=8 | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Identifier | 707 | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Below table lists the 'Identifier' values that are defined as well- 711 known in this draft (same as [RFC7752]). 713 +------------+-----------------------------------+ 714 | Identifier | Routing Universe | 715 +------------+-----------------------------------+ 716 | 0 | Default Layer 3 Routing topology | 717 | 1-31 | Reserved | 718 +------------+-----------------------------------+ 720 If this TLV is not present the default value 0 is assumed. 722 9.2.2. Route Distinguisher TLV 724 Tho allow identification of VPN link, node and prefix information in 725 PCEP-LS, a Route Distinguisher (RD) [RFC4364] is used. The LS 726 objects from the same VPN MUST have the same RD; LS objects with 727 different RD values MUST be considered to be from different VPNs. 729 The format of the optional ROUTE-DISTINGUISHER TLV is shown in the 730 following figure: 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Type=[TBD15] | Length=8 | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Route Distinguisher | 738 | | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 The format of RD is as per [RFC4364]. 743 9.2.3. Virtual Network TLV 745 To realize ACTN, the MDSC needs to build an multi-domain topology. 746 This topology is best served, if this is an abstracted view of the 747 underlying network resources of each domain. It is also important to 748 provide a customer view of network slice for each customer. There is 749 a need to control the level of abstraction based on the deployment 750 scenario and business relationship between the controllers. 752 Virtual service coordination function in ACTN incorporates customer 753 service-related knowledge into the virtual network operations in 754 order to seamlessly operate virtual networks while meeting customer's 755 service requirements. [I-D.ietf-teas-actn-requirements] describes 756 various VN operations initiated by a customer/application. In this 757 context, there is a need for associating the abstracted link state 758 and TE topology with a VN "construct" to facilitate VN operations in 759 PCE architecture. 761 VIRTUAL-NETWORK-TLV as per [I-D.leedhody-pce-vn-association] can be 762 included in LS object to identify the link, node and prefix 763 information belongs to a particular VN. 765 9.2.4. Local Node Descriptors TLV 767 As described in [RFC7752], each link is anchored by a pair of Router- 768 IDs that are used by the underlying IGP, namely, 48 Bit ISO System-ID 769 for IS-IS and 32 bit Router-ID for OSPFv2 and OSPFv3. Incase of 770 additional auxiliary Router-IDs used for TE, these MUST also be 771 included in the link attribute TLV (see Section 9.2.9.2). 773 It is desirable that the Router-ID assignments inside the Node 774 Descriptor are globally unique. Some considerations for globally 775 unique Node/Link/Prefix identifiers are described in [RFC7752]. 777 The Local Node Descriptors TLV contains Node Descriptors for the node 778 anchoring the local end of the link. This TLV MUST be included in 779 the LS Report when during a given PCEP session a node/link/prefix is 780 first reported to a PCE. A PCC sends to a PCE the first LS Report 781 either during State Synchronization, or when a new node/link/prefix 782 is learned at the PCC. The value contains one or more Node 783 Descriptor Sub-TLVs, which allows specification of a flexible key for 784 any given node/link/prefix information such that global uniqueness of 785 the node/link/prefix is ensured. 787 This TLV is applicable for all LS Object-Type. 789 0 1 2 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Type=[TBD8] | Length | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | | 795 // Node Descriptor Sub-TLVs (variable) // 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 The value contains one or more Node Descriptor Sub-TLVs defined in 800 Section 9.2.6. 802 9.2.5. Remote Node Descriptors TLV 804 The Remote Node Descriptors contains Node Descriptors for the node 805 anchoring the remote end of the link. This TLV MUST be included in 806 the LS Report when during a given PCEP session a link is first 807 reported to a PCE. A PCC sends to a PCE the first LS Report either 808 during State Synchronization, or when a new link is learned at the 809 PCC. The length of this TLV is variable. The value contains one or 810 more Node Descriptor Sub-TLVs defined in Section 9.2.6. 812 This TLV is applicable for LS Link Object-Type. 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Type=[TBD9] | Length | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | | 820 // Node Descriptor Sub-TLVs (variable) // 821 | | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 9.2.6. Node Descriptors Sub-TLVs 826 The Node Descriptor Sub-TLV type Type and lengths are listed in the 827 following table: 829 +----------+-------------------+----------+----------------+ 830 | Sub-TLV | Description | Length |Value defined in| 831 +----------+-------------------+----------+----------------+ 832 | 0 | Reserved | - | - | 833 | 1 | Autonomous System | 4 | [RFC7752] | 834 | 2 | BGP-LS Identifier | 4 | / section | 835 | 3 | OSPF Area-ID | 4 | 3.2.1.4 | 836 | 4 | IGP Router-ID | Variable | | 837 +----------+-------------------+----------+----------------+ 839 The sub-TLV values in Node Descriptor TLVs are defined as follows 840 (similar to [RFC7752]): 842 o Autonomous System: opaque value (32 Bit AS Number) 844 o BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 845 ASN, uniquely identifies the BGP-LS domain as described in 846 [RFC7752]. This sub-TLV is present only if the node implements 847 BGP-LS and the ID is set by the operator. 849 o OSPF Area ID: It is used to identify the 32 Bit area to which the 850 LS object belongs. Area Identifier allows the different LS 851 objects of the same node to be discriminated. 853 o IGP Router ID: opaque value. Usage is described in [RFC7752] for 854 IGP Router ID. In case only local information is transported and 855 PCE learns link-state (and TE) information only from PCEP, it 856 contain the unique local TE IPv4 or IPv6 router ID. 858 9.2.7. Link Descriptors TLV 860 The Link Descriptors TLV contains Link Descriptors for each link. 861 This TLV MUST be included in the LS Report when during a given PCEP 862 session a link is first reported to a PCE. A PCC sends to a PCE the 863 first LS Report either during State Synchronization, or when a new 864 link is learned at the PCC. The length of this TLV is variable. The 865 value contains one or more Link Descriptor Sub-TLVs. 867 The 'Link descriptor' TLVs uniquely identify a link among multiple 868 parallel links between a pair of anchor routers similar to [RFC7752]. 870 This TLV is applicable for LS Link Object-Type. 872 0 1 2 3 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Type=[TBD10] | Length | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | | 878 // Link Descriptor Sub-TLVs (variable) // 879 | | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 The Link Descriptor Sub-TLV type and lengths are listed in the 883 following table: 885 +-----------+---------------------+---------------+-----------------+ 886 | Sub-TLV | Description | IS-IS TLV | Value defined | 887 | | | /Sub-TLV | in: | 888 +-----------+---------------------+---------------+-----------------+ 889 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 890 | | Identifiers | | | 891 | 7 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 892 | | address | | | 893 | 8 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 894 | | address | | | 895 | 9 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 896 | | address | | | 897 | 10 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 898 | | address | | | 899 | 5 | Multi-Topology | - | [RFC7752]/ | 900 | | identifier | | 3.2.1.5 | 901 +-----------+---------------------+---------------+-----------------+ 903 The format and semantics of the 'value' fields in most 'Link 904 Descriptor' sub-TLVs correspond to the format and semantics of value 905 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 906 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 907 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 908 carry data sourced either by IS-IS or OSPF or direct. 910 The information about a link present in the LSA/LSP originated by the 911 local node of the link determines the set of sub-TLVs in the Link 912 Descriptor of the link as described in [RFC7752]. 914 9.2.8. Prefix Descriptors TLV 916 The Prefix Descriptors TLV contains Prefix Descriptors uniquely 917 identify an IPv4 or IPv6 Prefix originated by a Node. This TLV MUST 918 be included in the LS Report when during a given PCEP session a 919 prefix is first reported to a PCE. A PCC sends to a PCE the first LS 920 Report either during State Synchronization, or when a new prefix is 921 learned at the PCC. The length of this TLV is variable. 923 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 924 IPv6. 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Type=[TBD11] | Length | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | | 932 // Prefix Descriptor Sub-TLVs (variable) // 933 | | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 The value contains one or more Prefix Descriptor Sub-TLVs defined 937 below - 939 +--------------+-----------------------+----------+-----------------+ 940 | TLV Code | Description | Length | Value defined | 941 | Point | | | in: | 942 +--------------+-----------------------+----------+-----------------+ 943 | 5 | Multi-Topology | variable | [RFC7752] | 944 | | Identifier | | /3.2.1.5 | 945 | 11 | OSPF Route Type | 1 | [RFC7752] | 946 | | | | /3.2.3.1 | 947 | 12 | IP Reachability | variable | [RFC7752] | 948 | | Information | | /3.2.3.2 | 949 +--------------+-----------------------+----------+-----------------+ 951 9.2.9. PCEP-LS Attributes 953 9.2.9.1. Node Attributes TLV 955 This is an optional attribute that is used to carry node attributes. 956 This TLV is applicable for LS Node Object-Type. 958 0 1 2 3 959 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 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Type=[TBD12] | Length | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | | 964 // Node Attributes Sub-TLVs (variable) // 965 | | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 The Node Attributes Sub-TLV type and lengths are listed in the 969 following table: 971 +--------------+-----------------------+----------+-----------------+ 972 | Sub TLV | Description | Length | Value defined | 973 | | | | in: | 974 +--------------+-----------------------+----------+-----------------+ 975 | 5 | Multi-Topology | variable | [RFC7752] | 976 | | Identifier | | /3.2.1.5 | 977 | 13 | Node Flag Bits | 1 | [RFC7752] | 978 | | | | /3.3.1.1 | 979 | 14 | Opaque Node | variable | [RFC7752] | 980 | | Properties | | /3.3.1.5 | 981 | 15 | Node Name | variable | [RFC7752] | 982 | | | | /3.3.1.3 | 983 | 16 | IS-IS Area Identifier | variable | [RFC7752] | 984 | | | | /3.3.1.2 | 985 | 17 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 986 | | Local Node | | | 987 | 18 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 988 | | Local Node | | | 989 +--------------+-----------------------+----------+-----------------+ 991 9.2.9.2. Link Attributes TLV 993 This TLV is applicable for LS Link Object-Type. The format and 994 semantics of the 'value' fields in some 'Link Attribute' sub-TLVs 995 correspond to the format and semantics of value fields in IS-IS 996 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307] 997 and [RFC7752]. Although the encodings for 'Link Attribute' TLVs were 998 originally defined for IS-IS, the TLVs can carry data sourced either 999 by IS-IS or OSPF or direct. 1001 0 1 2 3 1002 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 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Type=[TBD13] | Length | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | | 1007 // Link Attributes Sub-TLVs (variable) // 1008 | | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 The following 'Link Attribute' sub-TLVs are valid : 1013 +-----------+---------------------+--------------+------------------+ 1014 | Sub-TLV | Description | IS-IS TLV | Defined in: | 1015 | | | /Sub-TLV | | 1016 | | | BGP-LS TLV | | 1017 +-----------+---------------------+--------------+------------------+ 1018 | 17 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1019 | | Local Node | | | 1020 | 18 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1021 | | Local Node | | | 1022 | 19 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1023 | | Remote Node | | | 1024 | 20 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1025 | | Remote Node | | | 1026 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1027 | | Identifiers | | | 1028 | 22 | Administrative | 22/3 | [RFC5305]/3.1 | 1029 | | group (color) | | | 1030 | 23 | Maximum link | 22/9 | [RFC5305]/3.3 | 1031 | | bandwidth | | | 1032 | 24 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1033 | | link bandwidth | | | 1034 | 25 | Unreserved | 22/11 | [RFC5305]/3.6 | 1035 | | bandwidth | | | 1036 | 26 | TE Default Metric | 22/18 | [RFC7752] | 1037 | | | | /3.3.2.3 | 1038 | 27 | Link Protection | 22/20 | [RFC5307]/1.2 | 1039 | | Type | | | 1040 | 28 | MPLS Protocol Mask | 1094 | [RFC7752] | 1041 | | | | /3.3.2.2 | 1042 | 29 | IGP Metric | 1095 | [RFC7752] | 1043 | | | | /3.3.2.4 | 1044 | 30 | Shared Risk Link | 1096 | [RFC7752] | 1045 | | Group | | /3.3.2.5 | 1046 | 31 | Opaque link | 1097 | [RFC7752] | 1047 | | attributes | | /3.3.2.6 | 1048 | 32 | Link Name attribute | 1098 | [RFC7752] | 1049 | | | | /3.3.2.7 | 1050 | 33 | Unidirectional | 22/33 | [RFC7810]/4.1 | 1051 | | Link Delay | | | 1052 | 34 | Min/Max | 22/34 | [RFC7810]/4.2 | 1053 | | Unidirectional Link | | | 1054 | | Delay | | | 1055 | 35 | Unidirectional | 22/35 | [RFC7810]/4.3 | 1056 | | Delay Variation | | | 1057 | 36 | Unidirectional | 22/36 | [RFC7810]/4.4 | 1058 | | Link Loss | | | 1059 | 37 | Unidirectional | 22/37 | [RFC7810]/4.5 | 1060 | | Residual Bandwidth | | | 1061 | 38 | Unidirectional | 22/38 | [RFC7810]/4.6 | 1062 | | Available Bandwidth | | | 1063 | 39 | Unidirectional | 22/39 | [RFC7810]/4.7 | 1064 | | Bandwidth | | | 1065 | | Utilization | | | 1066 | 40 | Extended Admin | 22/14 | [RFC7308]/2.1 | 1067 | | Group (EAG) | | | 1068 +-----------+---------------------+--------------+------------------+ 1070 9.2.9.3. Prefix Attributes TLV 1072 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 1073 IPv6. Prefixes are learned from the IGP (IS-IS or OSPF) or BGP 1074 topology with a set of IGP attributes (such as metric, route tags, 1075 etc.). This section describes the different attributes related to 1076 the IPv4/IPv6 prefixes. Prefix Attributes TLVs SHOULD be encoded in 1077 the LS Prefix Object. 1079 0 1 2 3 1080 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 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Type=[TBD14] | Length | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | | 1085 // Prefix Attributes Sub-TLVs (variable) // 1086 | | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 The following 'Prefix Attribute' sub-TLVs are valid : 1091 +-----------+---------------------+--------------+------------------+ 1092 | Sub-TLV | Description | BGP-LS TLV | Defined in: | 1093 +-----------+---------------------+--------------+------------------+ 1094 | 41 | IGP Flags | 1152 | [RFC7752] | 1095 | | | | /3.3.3.1 | 1096 | 42 | Route Tag | 1153 | [RFC7752] | 1097 | | | | /3.3.3.2 | 1098 | 43 | Extended Tag | 1154 | [RFC7752] | 1099 | | | | /3.3.3.3 | 1100 | 44 | Prefix Metric | 1155 | [RFC7752] | 1101 | | | | /3.3.3.4 | 1102 | 45 | OSPF Forwarding | 1156 | [RFC7752] | 1103 | | Address | | /3.3.3.5 | 1104 | 46 | Opaque Prefix | 1157 | [RFC7752] | 1105 | | Attribute | | /3.3.3.6 | 1106 +-----------+---------------------+--------------+------------------+ 1108 9.2.10. Removal of an Attribute 1110 One of a key objective of PCEP-LS is to encode and carry only the 1111 impacted attributes of a Node, a Link or a Prefix. To accommodate 1112 this requirement, incase of a removal of an attribute, the sub-TLV 1113 MUST be included with no 'value' field and length=0 to indicate that 1114 the attribute is removed. On receiving a sub-TLV with zero length, 1115 the receiver removes the attribute from the database. 1117 10. Other Considerations 1119 10.1. Inter-AS Links 1121 The main source of LS (and TE) information is the IGP, which is not 1122 active on inter-AS links. In some cases, the IGP may have 1123 information of inter-AS links ([RFC5392], [RFC5316]). In other 1124 cases, an implementation SHOULD provide a means to inject inter-AS 1125 links into PCEP. The exact mechanism used to provision the inter-AS 1126 links is outside the scope of this document. 1128 11. Processing Rules 1130 12. Security Considerations 1132 This document extends PCEP for LS (and TE) distribution including a 1133 new LSRpt message with new object and TLVs. Procedures and protocol 1134 extensions defined in this document do not effect the overall PCEP 1135 security model. See [RFC5440], [I-D.ietf-pce-pceps]. Tampering with 1136 the LSRpt message may have an effect on path computations at PCE. It 1137 also provides adversaries an opportunity to eavesdrop and learn 1138 sensitive information and plan sophisticated attacks on the network 1139 infrastructure. The PCE implementation SHOULD provide mechanisms to 1140 prevent strains created by network flaps and amount of LS (and TE) 1141 information. Thus it is suggested that any mechanism used for 1142 securing the transmission of other PCEP message be applied here as 1143 well. As a general precaution, it is RECOMMENDED that these PCEP 1144 extensions only be activated on authenticated and encrypted sessions 1145 belonging to the same administrative authority. 1147 13. Manageability Considerations 1149 13.1. Control of Function and Policy 1151 TBD. 1153 13.2. Information and Data Models 1155 TBD. 1157 13.3. Liveness Detection and Monitoring 1159 TBD. 1161 13.4. Verify Correct Operations 1163 TBD. 1165 13.5. Requirements On Other Protocols 1167 TBD. 1169 13.6. Impact On Network Operations 1171 TBD. 1173 14. IANA Considerations 1175 This document requests IANA actions to allocate code points for the 1176 protocol elements defined in this document. 1178 14.1. PCEP Messages 1180 IANA created a registry for PCEP messages. Each PCEP message has a 1181 message type value. This document defines a new PCEP message value. 1183 Value Meaning Reference 1184 TBD3 LSRpt [This I-D] 1186 14.2. PCEP Objects 1188 This document defines the following new PCEP Object-classes and 1189 Object-values: 1191 Object-Class Value Name Reference 1192 TBD6 LS Object [This I-D] 1193 Object-Type=1 1194 (LS Node) 1195 Object-Type=2 1196 (LS Link) 1197 Object-Type=3 1198 (LS IPv4 Prefix) 1199 Object-Type=4 1200 (LS IPv6 Prefix) 1202 14.3. LS Object 1204 This document requests that a new sub-registry, named "LS Object 1205 Protocol-ID Field", is created within the "Path Computation Element 1206 Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP 1207 object. New values are to be assigned by Standards Action [RFC5226]. 1209 Value Meaning Reference 1210 1 IS-IS Level 1 [This I-D] 1211 2 IS-IS Level 2 [This I-D] 1212 3 OSPFv2 [This I-D] 1213 4 Direct [This I-D] 1214 5 Static configuration [This I-D] 1215 6 OSPFv3 [This I-D] 1216 7 BGP-LS [This I-D] 1217 8 Abstraction [This I-D] 1219 Further, this document also requests that a new sub-registry, named 1220 "LS Object Flag Field", is created within the "Path Computation 1221 Element Protocol (PCEP) Numbers" registry to manage the Flag field of 1222 the LSP object.New values are to be assigned by Standards Action 1223 [RFC5226]. Each bit should be tracked with the following qualities: 1225 o Bit number (counting from bit 0 as the most significant bit) 1227 o Capability description 1229 o Defining RFC 1231 The following values are defined in this document: 1233 Bit Description Reference 1234 0-21 Unassigned 1235 22 R (Remove bit) [This I-D] 1236 23 S (Sync bit) [This I-D] 1238 14.4. PCEP-Error Object 1240 IANA is requested to make the following allocation in the "PCEP-ERROR 1241 Object Error Types and Values" registry. 1243 Error-Type Meaning Reference 1244 6 Mandatory Object missing [RFC5440] 1245 Error-Value=TBD4 [This I-D] 1246 (LS object missing) 1248 19 Invalid Operation [I-D.ietf-pce-stateful-pce] 1249 Error-Value=TBD1 [This I-D] 1250 (Attempted LS Report if LS 1251 remote capability was not 1252 advertised) 1254 TBD2 LS Synchronization Error [This I-D] 1255 Error-Value=1 1256 (An error in processing the 1257 LSRpt) 1258 Error-Value=2 1259 (An internal PCC error) 1261 14.5. PCEP TLV Type Indicators 1263 This document defines the following new PCEP TLVs. 1265 Value Meaning Reference 1266 TBD5 LS-CAPABILITY TLV [This I-D] 1267 TBD7 ROUTING-UNIVERSE TLV [This I-D] 1268 TBD15 ROUTE-DISTINGUISHER TLV [This I-D] 1269 TBD8 Local Node Descriptors TLV [This I-D] 1270 TBD9 Remote Node Descriptors TLV [This I-D] 1271 TBD10 Link Descriptors TLV [This I-D] 1272 TBD11 Prefix Descriptors TLV [This I-D] 1273 TBD12 Node Attributes TLV [This I-D] 1274 TBD13 Link Attributes TLV [This I-D] 1275 TBD14 Prefix Attributes TLV [This I-D] 1277 14.6. PCEP-LS Sub-TLV Type Indicators 1279 This document specifies the PCEP-LS Sub-TLVs. IANA is requested to 1280 create an "PCEP-LS Sub-TLV Types" sub-registry in the "PCEP TLV Type 1281 Indicators" for the sub-TLVs carried in the PCEP-LS TLV (Local and 1282 Remote Node Descriptors TLV, Link Descriptors TLV, Prefix Descriptors 1283 TLV, Node Attributes TLV, Link Attributes TLV and Prefix Attributes 1284 TLV. This document defines the following types: 1286 +-----------+---------------------+---------------+-----------------+ 1287 | Sub-TLV | Description | Ref | Value defined | 1288 | | | Sub-TLV | in: | 1289 +-----------+---------------------+---------------+-----------------+ 1290 | 1 | Autonomous System | 512 | [RFC7752] | 1291 | | | | /3.2.1.4 | 1292 | 2 | BGP-LS Identifier | 513 | [RFC7752] | 1293 | | | | /3.2.1.4 | 1294 | 3 | OSPF Area-ID | 514 | [RFC7752] | 1295 | | | | /3.2.1.4 | 1296 | 4 | IGP Router-ID | 515 | [RFC7752] | 1297 | | | | /3.2.1.4 | 1298 | 5 | Multi-Topology-ID | 263 | [RFC7752] | 1299 | | | | /3.2.1.5 | 1300 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1301 | | Identifiers | | | 1302 | 7 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1303 | | address | | | 1304 | 8 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1305 | | address | | | 1306 | 9 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1307 | | address | | | 1308 | 10 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1309 | | address | | | 1310 | 11 | OSPF Route Type | 264 | [RFC7752] | 1311 | | | | /3.2.3.1 | 1312 | 12 | IP Reachability | 265 | [RFC7752] | 1313 | | Information | | /3.2.3.2 | 1314 | 13 | Node Flag Bits | 1024 | [RFC7752] | 1315 | | | | /3.3.1.1 | 1316 | 14 | Opaque Node | 1025 | [RFC7752] | 1317 | | Properties | | /3.3.1.5 | 1318 | 15 | Node Name | 1026 | [RFC7752] | 1319 | | | | /3.3.1.3 | 1320 | 16 | IS-IS Area | 1027 | [RFC7752] | 1321 | | Identifier | | /3.3.1.2 | 1322 | 17 | IPv4 Router-ID of | 134/-- | [RFC5305]/4.3 | 1323 | | Local Node | | | 1324 | 18 | IPv6 Router-ID of | 140/-- | [RFC6119]/4.1 | 1325 | | Local Node | | | 1326 | 19 | IPv4 Router-ID of | 134/-- | [RFC5305]/4.3 | 1327 | | Remote Node | | | 1328 | 20 | IPv6 Router-ID of | 140/-- | [RFC6119]/4.1 | 1329 | | Remote Node | | | 1330 | 22 | Administrative | 22/3 | [RFC5305]/3.1 | 1331 | | group (color) | | | 1332 | 23 | Maximum link | 22/9 | [RFC5305]/3.3 | 1333 | | bandwidth | | | 1334 | 24 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1335 | | link bandwidth | | | 1336 | 25 | Unreserved | 22/11 | [RFC5305]/3.6 | 1337 | | bandwidth | | | 1338 | 26 | TE Default Metric | 22/18 | [RFC7752] | 1339 | | | | /3.3.2.3 | 1340 | 27 | Link Protection | 22/20 | [RFC5307]/1.2 | 1341 | | Type | | | 1342 | 28 | MPLS Protocol Mask | 1094 | [RFC7752] | 1343 | | | | /3.3.2.2 | 1344 | 29 | IGP Metric | 1095 | [RFC7752] | 1345 | | | | /3.3.2.4 | 1346 | 30 | Shared Risk Link | 1096 | [RFC7752] | 1347 | | Group | | /3.3.2.5 | 1348 | 31 | Opaque link | 1097 | [RFC7752] | 1349 | | attributes | | /3.3.2.6 | 1350 | 32 | Link Name attribute | 1098 | [RFC7752] | 1351 | | | | /3.3.2.7 | 1352 | 33 | Unidirectional | 22/33 | [RFC7810]/4.1 | 1353 | | Link Delay | | | 1354 | 34 | Min/Max | 22/34 | [RFC7810]/4.2 | 1355 | | Unidirectional Link | | | 1356 | | Delay | | | 1357 | 35 | Unidirectional | 22/35 | [RFC7810]/4.3 | 1358 | | Delay Variation | | | 1359 | 36 | Unidirectional | 22/36 | [RFC7810]/4.4 | 1360 | | Link Loss | | | 1361 | 37 | Unidirectional | 22/37 | [RFC7810]/4.5 | 1362 | | Residual Bandwidth | | | 1363 | 38 | Unidirectional | 22/38 | [RFC7810]/4.6 | 1364 | | Available Bandwidth | | | 1365 | 39 | Unidirectional | 22/39 | [RFC7810]/4.7 | 1366 | | Bandwidth | | | 1367 | | Utilization | | | 1368 | 40 | Extended Admin | 22/14 | [RFC7308]/2.1 | 1369 | | Group (EAG) | | | 1370 | 41 | IGP Flags | 1152 | [RFC7752] | 1371 | | | | /3.3.3.1 | 1372 | 42 | Route Tag | 1153 | [RFC7752] | 1373 | | | | /3.3.3.2 | 1374 | 43 | Extended Tag | 1154 | [RFC7752] | 1375 | | | | /3.3.3.3 | 1376 | 44 | Prefix Metric | 1155 | [RFC7752] | 1377 | | | | /3.3.3.4 | 1378 | 45 | OSPF Forwarding | 1156 | [RFC7752] | 1379 | | Address | | /3.3.3.5 | 1380 | 46 | Opaque Prefix | 1157 | [RFC7752] | 1381 | | Attribute | | /3.3.3.6 | 1382 +-----------+---------------------+---------------+-----------------+ 1383 New values are to be assigned by Standards Action [RFC5226]. 1385 15. TLV/Sub-TLV Code Points Summary 1387 This section contains the global table of all TLVs/Sub-TLVs in LS 1388 object defined in this document. 1390 +-----------+---------------------+---------------+-----------------+ 1391 | TLV | Description | Ref TLV | Value defined | 1392 | | | | in: | 1393 +-----------+---------------------+---------------+-----------------+ 1394 | TBD7 | Routing Universe | -- | Sec 9.2.1 | 1395 | TBD15 | Route | -- | Sec 9.2.2 | 1396 | | Distinguisher | | | 1397 | * | Virtual Network | -- | [leedhody-pce- | 1398 | | | | vn-association] | 1399 | TBD8 | Local Node | 256 | [RFC7752] | 1400 | | Descriptors | | /3.2.1.2 | 1401 | TBD9 | Remote Node | 257 | [RFC7752] | 1402 | | Descriptors | | /3.2.1.3 | 1403 | TBD10 | Link Descriptors | -- | Sec 9.2.8 | 1404 | TBD11 | Prefix Descriptors | -- | Sec 9.2.9 | 1405 | TBD12 | Node Attributes | -- | Sec 9.2.10.1 | 1406 | TBD13 | Link Attributes | -- | Sec 9.2.10.2 | 1407 | TBD14 | Prefix Attributes | -- | Sec 9.2.10.3 | 1408 +-----------+---------------------+---------------+-----------------+ 1410 * this TLV is defined in a different PCEP document 1412 TLV Table 1414 Refer Section 14.6 for the table of Sub-TLVs. 1416 16. Acknowledgments 1418 This document borrows some of the structure and text from the 1419 [RFC7752]. 1421 Thanks to Eric Wu, Venugopal Kondreddy, Mahendra Singh Negi, 1422 Avantika, and Zhengbin Li for the reviews. 1424 17. References 1426 17.1. Normative References 1428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1429 Requirement Levels", BCP 14, RFC 2119, 1430 DOI 10.17487/RFC2119, March 1997, 1431 . 1433 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1434 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1435 2008, . 1437 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1438 in Support of Generalized Multi-Protocol Label Switching 1439 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1440 . 1442 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1443 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1444 DOI 10.17487/RFC5440, March 2009, 1445 . 1447 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1448 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 1449 February 2011, . 1451 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1452 S. Ray, "North-Bound Distribution of Link-State and 1453 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1454 DOI 10.17487/RFC7752, March 2016, 1455 . 1457 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1458 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1459 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1460 . 1462 17.2. Informative References 1464 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1465 (TE) Extensions to OSPF Version 2", RFC 3630, 1466 DOI 10.17487/RFC3630, September 2003, 1467 . 1469 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1470 Support of Generalized Multi-Protocol Label Switching 1471 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1472 . 1474 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1475 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1476 2006, . 1478 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1479 Element (PCE)-Based Architecture", RFC 4655, 1480 DOI 10.17487/RFC4655, August 2006, 1481 . 1483 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1484 Topology (MT) Routing in Intermediate System to 1485 Intermediate Systems (IS-ISs)", RFC 5120, 1486 DOI 10.17487/RFC5120, February 2008, 1487 . 1489 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1490 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1491 DOI 10.17487/RFC5226, May 2008, 1492 . 1494 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1495 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1496 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1497 December 2008, . 1499 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1500 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1501 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 1502 January 2009, . 1504 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1505 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1506 March 2012, . 1508 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1509 Path Computation Element Architecture to the Determination 1510 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1511 DOI 10.17487/RFC6805, November 2012, 1512 . 1514 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 1515 Ward, "IS-IS Multi-Instance", RFC 6822, 1516 DOI 10.17487/RFC6822, December 2012, 1517 . 1519 [I-D.ietf-pce-stateful-pce] 1520 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1521 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1522 pce-15 (work in progress), July 2016. 1524 [I-D.ietf-pce-pce-initiated-lsp] 1525 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1526 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1527 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 1528 progress), July 2016. 1530 [I-D.ietf-pce-pceps] 1531 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1532 Transport for PCEP", draft-ietf-pce-pceps-10 (work in 1533 progress), July 2016. 1535 [I-D.kondreddy-pce-pcep-ls-sync-optimizations] 1536 Kondreddy, V. and M. Negi, "Optimizations of PCEP Link- 1537 State(LS) Synchronization Procedures", draft-kondreddy- 1538 pce-pcep-ls-sync-optimizations-00 (work in progress), 1539 October 2015. 1541 [I-D.leedhody-teas-pcep-ls] 1542 Lee, Y., Dhody, D., and D. Ceccarelli, "Architecture and 1543 Requirement for Distribution of Link-State and TE 1544 Information via PCEP.", draft-leedhody-teas-pcep-ls-02 1545 (work in progress), March 2016. 1547 [I-D.ietf-teas-actn-framework] 1548 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 1549 Control of Traffic Engineered Networks", draft-ietf-teas- 1550 actn-framework-00 (work in progress), July 2016. 1552 [I-D.ietf-teas-actn-requirements] 1553 Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D. 1554 Ceccarelli, "Requirements for Abstraction and Control of 1555 TE Networks", draft-ietf-teas-actn-requirements-03 (work 1556 in progress), July 2016. 1558 [I-D.leedhody-pce-vn-association] 1559 Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions 1560 for Establishing Relationships Between Sets of LSPs and 1561 Virtual Networks", draft-leedhody-pce-vn-association-00 1562 (work in progress), February 2016. 1564 [I-D.dhody-pce-applicability-actn] 1565 Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 1566 Path Computation Element (PCE) for Abstraction and Control 1567 of TE Networks (ACTN)", draft-dhody-pce-applicability- 1568 actn-00 (work in progress), July 2016. 1570 Appendix A. Relevant OSPF TLV and sub-TLV 1572 This section list the relevant TLVs and sub-TLVs defined for OSPF. 1574 +-----------+---------------------+---------------+-----------------+ 1575 | Sub-TLV | Description | OSPF-TE | Value defined | 1576 | | | Sub-TLV | in: | 1577 +-----------+---------------------+---------------+-----------------+ 1578 | 6 | Link Local/Remote | 11 | [RFC4203]/1.1 | 1579 | | Identifiers | | | 1580 | 7 | IPv4 interface | 3 | [RFC3630]/2.5.3 | 1581 | | address | | | 1582 | 8 | IPv4 neighbor | 4 | [RFC3630]/2.5.4 | 1583 | | address | | | 1584 | 9 | IPv6 interface | 19 | [RFC5329]/4.3 | 1585 | | address | | | 1586 | 10 | IPv6 neighbor | 20 | [RFC5329]/4.4 | 1587 | | address | | | 1588 | 17 | IPv4 Router-ID of | 1 | [RFC3630]/2.4.1 | 1589 | | Local Node | | | 1590 | 18 | IPv6 Router-ID of | 3 | [RFC5329]/3 | 1591 | | Local Node | | | 1592 | 19 | IPv4 Router-ID of | 1 | [RFC3630]/2.4.1 | 1593 | | Remote Node | | | 1594 | 20 | IPv6 Router-ID of | 3 | [RFC5329]/3 | 1595 | | Remote Node | | | 1596 | 22 | Administrative | 9 | [RFC3630]/2.5.9 | 1597 | | group (color) | | | 1598 | 23 | Maximum link | 6 | [RFC3630]/2.5.6 | 1599 | | bandwidth | | | 1600 | 24 | Max. reservable | 7 | [RFC3630]/2.5.7 | 1601 | | link bandwidth | | | 1602 | 25 | Unreserved | 8 | [RFC3630]/2.5.8 | 1603 | | bandwidth | | | 1604 | 27 | Link Protection | 14 | [RFC4203]/1.2 | 1605 | | Type | | | 1606 | 30 | Shared Risk Link | 16 | [RFC4203]/1.3 | 1607 | | Group | | | 1608 | 33 | Unidirectional | 27 | [RFC7471]/4.1 | 1609 | | Link Delay | | | 1610 | 34 | Min/Max | 28 | [RFC7471]/4.2 | 1611 | | Unidirectional Link | | | 1612 | | Delay | | | 1613 | 35 | Unidirectional | 29 | [RFC7471]/4.3 | 1614 | | Delay Variation | | | 1615 | 36 | Unidirectional | 30 | [RFC7471]/4.4 | 1616 | | Link Loss | | | 1617 | 37 | Unidirectional | 31 | [RFC7471]/4.5 | 1618 | | Residual Bandwidth | | | 1619 | 38 | Unidirectional | 32 | [RFC7471]/4.6 | 1620 | | Available Bandwidth | | | 1621 | 39 | Unidirectional | 33 | [RFC7471]/4.7 | 1622 | | Bandwidth | | | 1623 | | Utilization | | | 1624 | 40 | Extended Admin | 26 | [RFC7308]/2.1 | 1625 | | Group (EAG) | | | 1626 +-----------+---------------------+---------------+-----------------+ 1628 Appendix B. Contributor Addresses 1630 Udayasree Palle 1631 Huawei Technologies 1632 Divyashree Techno Park, Whitefield 1633 Bangalore, Karnataka 560066 1634 India 1636 EMail: udayasree.palle@huawei.com 1638 Sergio Belotti 1639 Alcatel-Lucent 1640 Italy 1642 EMail: sergio.belotti@alcatel-lucent.com 1644 Veerendranatha Reddy Vallem 1645 Huawei Technologies 1646 Divyashree Techno Park, Whitefield 1647 Bangalore, Karnataka 560066 1648 India 1650 Email: veerendranatharv@huawei.com 1652 Authors' Addresses 1654 Dhruv Dhody 1655 Huawei Technologies 1656 Divyashree Techno Park, Whitefield 1657 Bangalore, Karnataka 560066 1658 India 1660 EMail: dhruv.ietf@gmail.com 1661 Young Lee 1662 Huawei Technologies 1663 5340 Legacy Drive, Building 3 1664 Plano, TX 75023 1665 USA 1667 EMail: leeyoung@huawei.com 1669 Daniele Ceccarelli 1670 Ericsson 1671 Torshamnsgatan,48 1672 Stockholm 1673 Sweden 1675 EMail: daniele.ceccarelli@ericsson.com