idnits 2.17.1 draft-dhodylee-pce-pcep-ls-07.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 25 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2017) is 2605 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 513, but not defined == Missing Reference: 'TBD5' is mentioned on line 593, but not defined == Missing Reference: 'TBD6' is mentioned on line 623, but not defined == Missing Reference: 'This I-D' is mentioned on line 1289, but not defined == Unused Reference: 'RFC7810' is defined on line 1474, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 1500, 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-18 == 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-11 == Outdated reference: A later version (-01) exists of draft-kondreddy-pce-pcep-ls-sync-optimizations-00 == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-04 == Outdated reference: A later version (-09) exists of draft-ietf-teas-actn-requirements-04 == Outdated reference: A later version (-08) exists of draft-leedhody-pce-vn-association-01 == Outdated reference: A later version (-02) exists of draft-dhody-pce-applicability-actn-01 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: September 2, 2017 D. Ceccarelli 6 Ericsson 7 March 1, 2017 9 PCEP Extension for Distribution of Link-State and TE Information. 10 draft-dhodylee-pce-pcep-ls-07 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 September 2, 2017. 40 Copyright Notice 42 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . 8 66 6.3. Initial Link-State (and TE) Synchronization . . . . . . . 8 67 6.3.1. Optimizations for LS Synchronization . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . 13 74 9.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 13 75 9.2. Open Object . . . . . . . . . . . . . . . . . . . . . . . 13 76 9.2.1. LS Capability TLV . . . . . . . . . . . . . . . . . . 13 77 9.3. LS Object . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9.3.1. Routing Universe TLV . . . . . . . . . . . . . . . . 15 79 9.3.2. Route Distinguisher TLV . . . . . . . . . . . . . . . 16 80 9.3.3. Virtual Network TLV . . . . . . . . . . . . . . . . . 17 81 9.3.4. Local Node Descriptors TLV . . . . . . . . . . . . . 17 82 9.3.5. Remote Node Descriptors TLV . . . . . . . . . . . . . 18 83 9.3.6. Node Descriptors Sub-TLVs . . . . . . . . . . . . . . 19 84 9.3.7. Link Descriptors TLV . . . . . . . . . . . . . . . . 19 85 9.3.8. Prefix Descriptors TLV . . . . . . . . . . . . . . . 20 86 9.3.9. PCEP-LS Attributes . . . . . . . . . . . . . . . . . 21 87 9.3.9.1. Node Attributes TLV . . . . . . . . . . . . . . . 21 88 9.3.9.2. Link Attributes TLV . . . . . . . . . . . . . . . 22 89 9.3.9.3. Prefix Attributes TLV . . . . . . . . . . . . . . 24 90 9.3.10. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 32 112 17.1. Normative References . . . . . . . . . . . . . . . . . . 32 113 17.2. Informative References . . . . . . . . . . . . . . . . . 32 114 Appendix A. Relevant OSPF TLV and sub-TLV . . . . . . . . . . . 36 115 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 37 116 B.1. All Nodes . . . . . . . . . . . . . . . . . . . . . . . . 37 117 B.2. Designated Node . . . . . . . . . . . . . . . . . . . . . 38 118 B.3. Between PCEs . . . . . . . . . . . . . . . . . . . . . . 38 119 Appendix C. Contributor Addresses . . . . . . . . . . . . . . . 40 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 122 1. Introduction 124 In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS), 125 a Traffic Engineering Database (TED) is used in computing paths for 126 connection oriented packet services and for circuits. The TED 127 contains all relevant information that a Path Computation Element 128 (PCE) needs to perform its computations. It is important that the 129 TED be complete and accurate each time, the PCE performs a path 130 computation. 132 In MPLS and GMPLS, interior gateway routing protocols (IGPs) have 133 been used to create and maintain a copy of the TED at each node 134 running the IGP. One of the benefits of the PCE architecture 135 [RFC4655] is the use of computationally more sophisticated path 136 computation algorithms and the realization that these may need 137 enhanced processing power not necessarily available at each node 138 participating in an IGP. 140 Section 4.3 of [RFC4655] describes the potential load of the TED on a 141 network node and proposes an architecture where the TED is maintained 142 by the PCE rather than the network nodes. However, it does not 143 describe how a PCE would obtain the information needed to populate 144 its TED. PCE may construct its TED by participating in the IGP 145 ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for 146 GMPLS). An alternative is offered by BGP-LS [RFC7752] . 148 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 149 provide stateful control. A stateful PCE has access to not only the 150 information carried by the network's Interior Gateway Protocol (IGP), 151 but also the set of active paths and their reserved resources for its 152 computations. PCC can delegate the rights to modify the LSP 153 parameters to an Active Stateful PCE. This requires PCE to quickly 154 be updated on any changes in the Topology and TEDB, so that PCE can 155 meet the need for updating LSPs effectively and in a timely manner. 156 The fastest way for a PCE to be updated on TED changes is via a 157 direct interface with each network node and with incremental update 158 from each network node with only the attribute that is modified. 160 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and 161 teardown of PCE-initiated LSPs under the stateful PCE model, without 162 the need for local configuration on the PCC, thus allowing for a 163 dynamic network that is centrally controlled and deployed. This 164 model requires timely topology and TED update at the PCE. 166 [I-D.leedhody-teas-pcep-ls] proposes some other approaches for 167 learning and maintaining the Link-State and TE information directly 168 on a PCE as an alternative to IGPs and BGP flooding and investigate 169 the impact from the PCE, routing protocol, and node perspectives. 171 [RFC5440] describes the specifications for the Path Computation 172 Element Communication Protocol (PCEP). PCEP specifies the 173 communication between a Path Computation Client (PCC) and a Path 174 Computation Element (PCE), or between two PCEs based on the PCE 175 architecture [RFC4655]. 177 This document describes a mechanism by which Link State and TE 178 information can be collected from networks and shared with PCE using 179 the PCEP itself. This is achieved using a new PCEP message format. 180 The mechanism is applicable to physical and virtual links as well as 181 further subjected to various policies. 183 A network node maintains one or more databases for storing link-state 184 and TE information about nodes and links in any given area. Link 185 attributes stored in these databases include: local/remote IP 186 addresses, local/ remote interface identifiers, link metric and TE 187 metric, link bandwidth, reservable bandwidth, per CoS class 188 reservation state, preemption and Shared Risk Link Groups (SRLG). 189 The node's PCEP process can retrieve topology from these databases 190 and distribute it to a PCE, either directly or via another PCEP 191 Speaker, using the encoding specified in this document. 193 Further [RFC6805] describes Hierarchical-PCE architecture, where a 194 parent PCE maintains a domain topology map. To build this domain 195 topology map, the child PCE can carry the border nodes and inter- 196 domain link information to the parent PCE using the mechanism 197 described in this document. Further as described in 198 [I-D.dhody-pce-applicability-actn], the child PCE can also transport 199 abstract Link-State and TE information from child PCE to a Parent PCE 200 using the mechanism described in this document to build an abstract 201 topology at the parent PCE. 203 [I-D.ietf-pce-stateful-pce] describe LSP state synchronization 204 between PCCs and PCEs in case of stateful PCE. This document does 205 not make any change to the LSP state synchronization process. The 206 mechanism described in this document are on top of the existing LSP 207 state synchronization. 209 1.1. Requirements Language 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 2. Terminology 217 The terminology is as per [RFC4655] and [RFC5440]. 219 3. Applicability 221 As per [I-D.leedhody-teas-pcep-ls], the mechanism specified in this 222 draft is applicable to: 224 o Where there is no IGP or BGP-LS running in the network. 226 o Where there is no IGP or BGP-LS running at the PCE to learn link- 227 state and TE information. 229 o Where there is IGP or BGP-LS running but with a need for a faster 230 TE and link-state population and convergence at the PCE. 232 * A PCE may receive partial information (say basic TE, link- 233 state) from IGP and other information (optical and impairment) 234 from PCEP. 236 * A PCE may receive an incremental update (as opposed to the 237 entire information of the node/link). 239 * A PCE may receive full information from both existing mechanism 240 (IGP or BGP) and PCEP. 242 o Where there is a need for transporting (abstract) Link-State and 243 TE information from child PCE to a Parent PCE in H-PCE [RFC6805]; 244 as well as for Physical Network Controller (PNC) to Multi-Domain 245 Service Coordinator (MDSC) in Abstraction and Control of TE 246 Networks (ACTN) [I-D.ietf-teas-actn-framework]. 248 A PCC may further choose to send only local information or both local 249 and remote learned information. 251 How a PCE manages the link-state (and TE) information is 252 implementation specific and thus out of scope of this document. 254 The prefix information in PCEP-LS can also help in determining the 255 domain of the endpoints in H-PCE (and ACTN). Section 4.5 of 256 [RFC6805] describe various mechanism and procedures that might be 257 used, PCEP-LS provides a simple mechanism to exchange this 258 information. 260 4. Requirements for PCEP extension 262 Following key requirements associated with link-state (and TE) 263 distribution are identified for PCEP: 265 1. The PCEP speaker supporting this draft MUST be a mechanism to 266 advertise the Link-State (and TE) distribution capability. 268 2. PCC supporting this draft MUST have the capability to report the 269 link-state (and TE) information to the PCE. This includes self 270 originated information and remote information learned via routing 271 protocols. PCC MUST be capable to do the initial bulk sync at 272 the time of session initialization as well as changes after. 274 3. A PCE MAY learn link-state (and TE) from PCEP as well as from 275 existing mechanism like IGP/BGP-LS. PCEP extension MUST have a 276 mechanism to link the information learned via other means. There 277 MUST NOT be any changes to the existing link-state (and TE) 278 population mechanism via IGP/BGP-LS. PCEP extension SHOULD keep 279 the properties in a protocol (IGP or BGP-LS) neutral way, such 280 that an implementation may not need to know about any OSPF or IS- 281 IS or BGP protocol specifics. 283 4. It SHOULD be possible to encode only the changes in link-state 284 (and TE) properties (after the initial sync) in PCEP messages. 286 5. The same mechanism should be used for both MPLS TE as well as 287 GMPLS, optical and impairment aware properties. 289 6. The same mechanism should be used for PCE to PCE Link-state (and 290 TE) synchronization. 292 7. The extension in this draft SHOULD be extensible to support 293 various architecture options listed in 294 [I-D.leedhody-teas-pcep-ls]. 296 5. New Functions to distribute link-state (and TE) via PCEP 298 Several new functions are required in PCEP to support distribution of 299 link-state (and TE) information. A function can be initiated either 300 from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). 301 The new functions are: 303 o Capability advertisement (E-C,C-E): both the PCC and the PCE must 304 announce during PCEP session establishment that they support PCEP 305 extensions for distribution of link-state (and TE) information 306 defined in this document. 308 o Link-State (and TE) synchronization (C-E): after the session 309 between the PCC and a PCE is initialized, the PCE must learn Link- 310 State (and TE) information before it can perform path 311 computations. In case of stateful PCE it is RECOMENDED that this 312 operation be done before LSP state synchronization. 314 o Link-State (and TE) Report (C-E): a PCC sends a LS (and TE) report 315 to a PCE whenever the Link-State and TE information changes. 317 6. Overview of Extension to PCEP 319 6.1. New Messages 321 In this document, we define a new PCEP messages called LS Report 322 (LSRpt), a PCEP message sent by a PCC to a PCE to report link-state 323 (and TE) information. Each LS Report in a LSRpt message can contain 324 the node or link properties. An unique PCEP specific LS identifier 325 (LS-ID) is also carried in the message to identify a node or link and 326 that remains constant for the lifetime of a PCEP session. This 327 identifier on its own is sufficient when no IGP or BGP-LS running in 328 the network for PCE to learn link-state (and TE) information. Incase 329 PCE learns some information from PCEP and some from the existing 330 mechanism, the PCC SHOULD include the mapping of IGP or BGP-LS 331 identifier to map the information populated via PCEP with IGP/BGP-LS. 332 See Section 8.1 for details. 334 6.2. Capability Advertisement 336 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 337 advertise their support of LS (and TE) distribution via PCEP 338 extensions. A PCEP Speaker includes the "LS Capability" TLV, 339 described in Section 9.2.1, in the OPEN Object to advertise its 340 support for PCEP-LS extensions. The presence of the LS Capability 341 TLV in PCC's OPEN Object indicates that the PCC is willing to send LS 342 Reports whenever local link-state (and TE) information changes. The 343 presence of the LS Capability TLV in PCE's OPEN message indicates 344 that the PCE is interested in receiving LS Reports whenever local 345 link-state (and TE) information changes. 347 The PCEP protocol extensions for LS (and TE) distribution MUST NOT be 348 used if one or both PCEP Speakers have not included the LS Capability 349 TLV in their respective OPEN message. If the PCE that supports the 350 extensions of this draft but did not advertise this capability, then 351 upon receipt of a LSRpt message from the PCC, it SHOULD generate a 352 PCErr with error-type 19 (Invalid Operation), error-value TBD1 353 (Attempted LS Report if LS capability was not advertised) and it will 354 terminate the PCEP session. 356 The LS reports sent by PCC MAY carry the remote link-state (and TE) 357 information learned via existing means like IGP and BGP-LS only if 358 both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV 359 to 'Remote Allowed (R Flag = 1)'. If this is not the case and LS 360 reports carry remote link-state (and TE) information, then a PCErr 361 with error-type 19 (Invalid Operation) and error-value TBD1 362 (Attempted LS Report if LS remote capability was not advertised) and 363 it will terminate the PCEP session. 365 6.3. Initial Link-State (and TE) Synchronization 367 The purpose of LS Synchronization is to provide a checkpoint-in- time 368 state replica of a PCC's link-state (and TE) data base in a PCE. 369 State Synchronization is performed immediately after the 370 Initialization phase (see [RFC5440]]). In case of stateful PCE 371 ([I-D.ietf-pce-stateful-pce]) it is RECOMENDED that the LS 372 synchronization should be done before LSP state synchronization. 374 During LS Synchronization, a PCC first takes a snapshot of the state 375 of its database, then sends the snapshot to a PCE in a sequence of LS 376 Reports. Each LS Report sent during LS Synchronization has the SYNC 377 Flag in the LS Object set to 1. The end of synchronization marker is 378 a LSRpt message with the SYNC Flag set to 0 for an LS Object with LS- 379 ID equal to the reserved value 0. If the PCC has no link-state to 380 synchronize, it will only send the end of synchronization marker. 382 Either the PCE or the PCC MAY terminate the session using the PCEP 383 session termination procedures during the synchronization phase. If 384 the session is terminated, the PCE MUST clean up state it received 385 from this PCC. The session re-establishment MUST be re-attempted per 386 the procedures defined in [RFC5440], including use of a back-off 387 timer. 389 If the PCC encounters a problem which prevents it from completing the 390 LS synchronization, it MUST send a PCErr message with error-type TBD2 391 (LS Synchronization Error) and error-value 2 (indicating an internal 392 PCC error) to the PCE and terminate the session. 394 The PCE does not send positive acknowledgements for properly received 395 LS synchronization messages. It MUST respond with a PCErr message 396 with error-type TBD2 (LS Synchronization Error) and error-value 1 397 (indicating an error in processing the LSRpt) if it encounters a 398 problem with the LS Report it received from the PCC and it MUST 399 terminate the session. 401 The LS reports can carry local as well as remote link-state (and TE) 402 information depending on the R flag in LS capability TLV. 404 The successful LS Synchronization sequences is shown in Figure 1. 406 +-+-+ +-+-+ 407 |PCC| |PCE| 408 +-+-+ +-+-+ 409 | | 410 |-----LSRpt, SYNC=1----->| (Sync start) 411 | | 412 |-----LSRpt, SYNC=1----->| 413 | . | 414 | . | 415 | . | 416 |-----LSRpt, SYNC=1----->| 417 | . | 418 | . | 419 | . | 420 | | 421 |-----LSRpt, SYNC=0----->| (End of sync marker 422 | | LS Report 423 | | for LS-ID=0) 424 | | (Sync done) 426 Figure 1: Successful LS synchronization 428 The sequence where the PCE fails during the LS Synchronization phase 429 is shown in Figure 2. 431 +-+-+ +-+-+ 432 |PCC| |PCE| 433 +-+-+ +-+-+ 434 | | 435 |-----LSRpt, SYNC=1----->| 436 | | 437 |-----LSRpt, SYNC=1----->| 438 | . | 439 | . | 440 | . | 441 |-----LSRpt, SYNC=1----->| 442 | | 443 |---LSRpt,SYNC=1 | 444 | \ ,-PCErr---| 445 | \ / | 446 | \/ | 447 | /\ | 448 | / `-------->| (Ignored) 449 |<--------` | 451 Figure 2: Failed LS synchronization (PCE failure) 453 The sequence where the PCC fails during the LS Synchronization phase 454 is shown in Figure 3. 456 +-+-+ +-+-+ 457 |PCC| |PCE| 458 +-+-+ +-+-+ 459 | | 460 |-----LSRpt, SYNC=1----->| 461 | | 462 |-----LSRpt, SYNC=1----->| 463 | . | 464 | . | 465 | . | 466 |-------- PCErr--------->| 467 | | 469 Figure 3: Failed LS synchronization (PCC failure) 471 6.3.1. Optimizations for LS Synchronization 473 These optimizations are described in 474 [I-D.kondreddy-pce-pcep-ls-sync-optimizations]. 476 6.4. LS Report 478 The PCC MUST report any changes in the link-state (and TE) 479 information to the PCE by sending a LS Report carried on a LSRpt 480 message to the PCE. Each node and Link would be uniquely identified 481 by a PCEP LS identifier (LS-ID). The LS reports may carry local as 482 well as remote link-state (and TE) information depending on the R 483 flag in LS capability TLV. In case R flag is set, It MAY also 484 include the mapping of IGP or BGP-LS identifier to map the 485 information populated via PCEP with IGP/BGP-LS. 487 More details about LSRpt message are in Section 8.1. 489 7. Transport 491 A permanent PCEP session MUST be established between a PCE and PCC 492 supporting link-state (and TE) distribution via PCEP. In the case of 493 session failure, session re-establishment MUST be re-attempted per 494 the procedures defined in [RFC5440]. 496 8. PCEP Messages 498 As defined in [RFC5440], a PCEP message consists of a common header 499 followed by a variable-length body made of a set of objects that can 500 be either mandatory or optional. An object is said to be mandatory 501 in a PCEP message when the object must be included for the message to 502 be considered valid. For each PCEP message type, a set of rules is 503 defined that specify the set of objects that the message can carry. 504 An implementation MUST form the PCEP messages using the object 505 ordering specified in this document. 507 8.1. LS Report Message 509 A PCEP LS Report message (also referred to as LSRpt message) is a 510 PCEP message sent by a PCC to a PCE to report the link-state (and TE) 511 information. A LSRpt message can carry more than one LS Reports. 512 The Message-Type field of the PCEP common header for the LSRpt 513 message is set to [TBD3]. 515 The format of the LSRpt message is as follows: 517 ::= 518 519 Where: 521 ::= [] 523 The LS object is a mandatory object which carries LS information of a 524 node or a link. Each LS object has an unique LS-ID as described in 525 Section 9.3. If the LS object is missing, the receiving PCE MUST 526 send a PCErr message with Error-type=6 (Mandatory Object missing) and 527 Error-value=[TBD4] (LS object missing). 529 A PCE may choose to implement a limit on the LS information a single 530 PCC can populate. If a LSRpt is received that causes the PCE to 531 exceed this limit, it MUST send a PCErr message with error-type 19 532 (invalid operation) and error-value 4 (indicating resource limit 533 exceeded) in response to the LSRpt message triggering this condition 534 and SHOULD terminate the session. 536 8.2. The PCErr Message 538 If a PCEP speaker has advertised the LS capability on the PCEP 539 session, the PCErr message MAY include the LS object. If the error 540 reported is the result of an LS report, then the LS-ID number MUST be 541 the one from the LSRpt that triggered the error. 543 The format of a PCErr message from [RFC5440] is extended as follows: 545 The format of the PCErr message is as follows: 547 ::= 548 ( [] ) | 549 [] 551 ::=[] 553 ::=[ | ] 554 556 ::=[] 558 ::=[] 560 ::=[] 562 9. Objects and TLV 564 The PCEP objects defined in this document are compliant with the PCEP 565 object format defined in [RFC5440]. The P flag and the I flag of the 566 PCEP objects defined in this document MUST always be set to 0 on 567 transmission and MUST be ignored on receipt since these flags are 568 exclusively related to path computation requests. 570 9.1. TLV Format 572 The TLV and the sub-TLV format (and padding) in this document, is as 573 per section 7.1 of [RFC5440]. 575 9.2. Open Object 577 This document defines a new optional TLV for use in the OPEN Object. 579 9.2.1. LS Capability TLV 581 The LS-CAPABILITY TLV is an optional TLV for use in the OPEN Object 582 for link-state (and TE) distribution via PCEP capability 583 advertisement. Its format is shown in the following figure: 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Type=[TBD5] | Length=4 | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Flags |R| 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 The type of the TLV is [TBD5] and it has a fixed length of 4 octets. 595 The value comprises a single field - Flags (32 bits): 597 o R (remote - 1 bit): if set to 1 by a PCC, the R Flag indicates 598 that the PCC allows reporting of remote LS information learned via 599 other means like IGP and BGP-LS; if set to 1 by a PCE, the R Flag 600 indicates that the PCE is capable of receiving remote LS 601 information (from the PCC point of view). The R Flag must be 602 advertised by both a PCC and a PCE for LSRpt messages to report 603 remote as well as local LS information on a PCEP session. The 604 TLVs related to IGP/BGP-LS identifier MUST be encoded when both 605 PCEP speakers have the R Flag set. 607 Unassigned bits are considered reserved. They MUST be set to 0 on 608 transmission and MUST be ignored on receipt. 610 Advertisement of the LS capability implies support of local link- 611 state (and TE) distribution, as well as the objects, TLVs and 612 procedures defined in this document. 614 9.3. LS Object 616 The LS (link-state) object MUST be carried within LSRpt messages and 617 MAY be carried within PCErr messages. The LS object contains a set 618 of fields used to specify the target node or link. It also contains 619 a flag indicating to a PCE that the LS synchronization is in 620 progress. The TLVs used with the LS object correlate with the IGP/ 621 BGP-LS encodings. 623 LS Object-Class is [TBD6]. 625 Four Object-Type values are defined for the LS object so far: 627 o LS Node: LS Object-Type is 1. 629 o LS Link: LS Object-Type is 2. 631 o LS IPv4 Topology Prefix: LS Object-Type is 3. 633 o LS IPv6 Topology Prefix: LS Object-Type is 4. 635 The format of all types of LS object is as follows: 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Protocol-ID | Flag |R|S| 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | LS-ID | 643 | | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 // TLVs // 646 | | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Protocol-ID (8-bit): The field provide the source information. The 650 protocol could be an IGP, BGP-LS or an abstraction algorithm. Incase 651 PCC only provides local information of the PCC, it MUST use Protocol- 652 ID as Direct. The following values are defined (some of them are 653 same as [RFC7752]): 655 +-------------+----------------------------------+ 656 | Protocol-ID | Source protocol | 657 +-------------+----------------------------------+ 658 | 1 | IS-IS Level 1 | 659 | 2 | IS-IS Level 2 | 660 | 3 | OSPFv2 | 661 | 4 | Direct | 662 | 5 | Static configuration | 663 | 6 | OSPFv3 | 664 | 7 | BGP-LS | 665 | 8 | PCEP-LS | 666 | 9 | Abstraction | 667 | 10 | Unspecified | 668 +-------------+----------------------------------+ 670 Flags (24-bit): 672 o S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSRpt sent 673 from a PCC during LS Synchronization. The S Flag MUST be set to 0 674 in other LSRpt messages sent from the PCC. 676 o R (Remove - 1 bit): On LSRpt messages the R Flag indicates that 677 the node/link/prefix has been removed from the PCC and the PCE 678 SHOULD remove from its database. Upon receiving an LS Report with 679 the R Flag set to 1, the PCE SHOULD remove all state for the 680 node/link/prefix identified by the LS Identifiers from its 681 database. 683 LS-ID(64-bit): A PCEP-specific identifier for the node or link or 684 prefix information. A PCC creates an unique LS-ID for each 685 node/link/prefix that is constant for the lifetime of a PCEP session. 686 The PCC will advertise the same LS-ID on all PCEP sessions it 687 maintains at a given times. All subsequent PCEP messages then 688 address the node/link/prefix by the LS-ID. The values of 0 and 689 0xFFFFFFFFFFFFFFFF are reserved. 691 Unassigned bits are considered reserved. They MUST be set to 0 on 692 transmission and MUST be ignored on receipt. 694 TLVs that may be included in the LS Object are described in the 695 following sections. 697 9.3.1. Routing Universe TLV 699 In case of remote link-state (and TE) population when existing IGP/ 700 BGP-LS are also used, OSPF and IS-IS may run multiple routing 701 protocol instances over the same link as described in [RFC7752]. See 702 [RFC6822] and [RFC6549] for more information. These instances define 703 independent "routing universes". The 64-Bit 'Identifier' field is 704 used to identify the "routing universe" where the LS object belongs. 705 The LS objects representing IGP objects (nodes or links or prefix) 706 from the same routing universe MUST have the same 'Identifier' value; 707 LS objects with different 'Identifier' values MUST be considered to 708 be from different routing universes. 710 The format of the optional ROUTING-UNIVERSE TLV is shown in the 711 following figure: 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Type=[TBD7] | Length=8 | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Identifier | 719 | | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 Below table lists the 'Identifier' values that are defined as well- 723 known in this draft (same as [RFC7752]). 725 +------------+-----------------------------------+ 726 | Identifier | Routing Universe | 727 +------------+-----------------------------------+ 728 | 0 | Default Layer 3 Routing topology | 729 | 1-31 | Reserved | 730 +------------+-----------------------------------+ 732 If this TLV is not present the default value 0 is assumed. 734 9.3.2. Route Distinguisher TLV 736 To allow identification of VPN link, node and prefix information in 737 PCEP-LS, a Route Distinguisher (RD) [RFC4364] is used. The LS 738 objects from the same VPN MUST have the same RD; LS objects with 739 different RD values MUST be considered to be from different VPNs. 741 The format of the optional ROUTE-DISTINGUISHER TLV is shown in the 742 following figure: 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Type=[TBD15] | Length=8 | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Route Distinguisher | 750 | | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 The format of RD is as per [RFC4364]. 755 9.3.3. Virtual Network TLV 757 To realize ACTN, the MDSC needs to build an multi-domain topology. 758 This topology is best served, if this is an abstracted view of the 759 underlying network resources of each domain. It is also important to 760 provide a customer view of network slice for each customer. There is 761 a need to control the level of abstraction based on the deployment 762 scenario and business relationship between the controllers. 764 Virtual service coordination function in ACTN incorporates customer 765 service-related knowledge into the virtual network operations in 766 order to seamlessly operate virtual networks while meeting customer's 767 service requirements. [I-D.ietf-teas-actn-requirements] describes 768 various VN operations initiated by a customer/application. In this 769 context, there is a need for associating the abstracted link state 770 and TE topology with a VN "construct" to facilitate VN operations in 771 PCE architecture. 773 VIRTUAL-NETWORK-TLV as per [I-D.leedhody-pce-vn-association] can be 774 included in LS object to identify the link, node and prefix 775 information belongs to a particular VN. 777 9.3.4. Local Node Descriptors TLV 779 As described in [RFC7752], each link is anchored by a pair of Router- 780 IDs that are used by the underlying IGP, namely, 48 Bit ISO System-ID 781 for IS-IS and 32 bit Router-ID for OSPFv2 and OSPFv3. Incase of 782 additional auxiliary Router-IDs used for TE, these MUST also be 783 included in the link attribute TLV (see Section 9.3.9.2). 785 It is desirable that the Router-ID assignments inside the Node 786 Descriptor are globally unique. Some considerations for globally 787 unique Node/Link/Prefix identifiers are described in [RFC7752]. 789 The Local Node Descriptors TLV contains Node Descriptors for the node 790 anchoring the local end of the link. This TLV MUST be included in 791 the LS Report when during a given PCEP session a node/link/prefix is 792 first reported to a PCE. A PCC sends to a PCE the first LS Report 793 either during State Synchronization, or when a new node/link/prefix 794 is learned at the PCC. The value contains one or more Node 795 Descriptor Sub-TLVs, which allows specification of a flexible key for 796 any given node/link/prefix information such that global uniqueness of 797 the node/link/prefix is ensured. 799 This TLV is applicable for all LS Object-Type. 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Type=[TBD8] | Length | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | | 807 // Node Descriptor Sub-TLVs (variable) // 808 | | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 The value contains one or more Node Descriptor Sub-TLVs defined in 812 Section 9.3.6. 814 9.3.5. Remote Node Descriptors TLV 816 The Remote Node Descriptors contains Node Descriptors for the node 817 anchoring the remote end of the link. This TLV MUST be included in 818 the LS Report when during a given PCEP session a link is first 819 reported to a PCE. A PCC sends to a PCE the first LS Report either 820 during State Synchronization, or when a new link is learned at the 821 PCC. The length of this TLV is variable. The value contains one or 822 more Node Descriptor Sub-TLVs defined in Section 9.3.6. 824 This TLV is applicable for LS Link Object-Type. 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Type=[TBD9] | Length | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | | 832 // Node Descriptor Sub-TLVs (variable) // 833 | | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 9.3.6. Node Descriptors Sub-TLVs 838 The Node Descriptor Sub-TLV type Type and lengths are listed in the 839 following table: 841 +----------+-------------------+----------+----------------+ 842 | Sub-TLV | Description | Length |Value defined in| 843 +----------+-------------------+----------+----------------+ 844 | 0 | Reserved | - | - | 845 | 1 | Autonomous System | 4 | [RFC7752] | 846 | 2 | BGP-LS Identifier | 4 | / section | 847 | 3 | OSPF Area-ID | 4 | 3.2.1.4 | 848 | 4 | Router-ID | Variable | | 849 +----------+-------------------+----------+----------------+ 851 The sub-TLV values in Node Descriptor TLVs are defined as follows 852 (similar to [RFC7752]): 854 o Autonomous System: opaque value (32 Bit AS Number) 856 o BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 857 ASN, uniquely identifies the BGP-LS domain as described in 858 [RFC7752]. This sub-TLV is present only if the node implements 859 BGP-LS and the ID is set by the operator. 861 o OSPF Area ID: It is used to identify the 32 Bit area to which the 862 LS object belongs. Area Identifier allows the different LS 863 objects of the same node to be discriminated. 865 o Router ID: opaque value. Usage is described in [RFC7752] as IGP 866 Router ID. In case this is not learned from IGP, it SHOULD 867 contain the unique router ID, such as TE router ID. 869 9.3.7. Link Descriptors TLV 871 The Link Descriptors TLV contains Link Descriptors for each link. 872 This TLV MUST be included in the LS Report when during a given PCEP 873 session a link is first reported to a PCE. A PCC sends to a PCE the 874 first LS Report either during State Synchronization, or when a new 875 link is learned at the PCC. The length of this TLV is variable. The 876 value contains one or more Link Descriptor Sub-TLVs. 878 The 'Link descriptor' TLVs uniquely identify a link among multiple 879 parallel links between a pair of anchor routers similar to [RFC7752]. 881 This TLV is applicable for LS Link Object-Type. 883 0 1 2 3 884 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 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Type=[TBD10] | Length | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | | 889 // Link Descriptor Sub-TLVs (variable) // 890 | | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 The Link Descriptor Sub-TLV type and lengths are listed in the 894 following table: 896 +-----------+---------------------+---------------+-----------------+ 897 | Sub-TLV | Description | IS-IS TLV | Value defined | 898 | | | /Sub-TLV | in: | 899 +-----------+---------------------+---------------+-----------------+ 900 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 901 | | Identifiers | | | 902 | 7 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 903 | | address | | | 904 | 8 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 905 | | address | | | 906 | 9 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 907 | | address | | | 908 | 10 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 909 | | address | | | 910 | 5 | Multi-Topology | - | [RFC7752]/ | 911 | | identifier | | 3.2.1.5 | 912 +-----------+---------------------+---------------+-----------------+ 914 The format and semantics of the 'value' fields in most 'Link 915 Descriptor' sub-TLVs correspond to the format and semantics of value 916 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 917 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 918 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 919 carry data sourced either by IS-IS or OSPF or direct. 921 The information about a link present in the LSA/LSP originated by the 922 local node of the link determines the set of sub-TLVs in the Link 923 Descriptor of the link as described in [RFC7752]. 925 9.3.8. Prefix Descriptors TLV 927 The Prefix Descriptors TLV contains Prefix Descriptors uniquely 928 identify an IPv4 or IPv6 Prefix originated by a Node. This TLV MUST 929 be included in the LS Report when during a given PCEP session a 930 prefix is first reported to a PCE. A PCC sends to a PCE the first LS 931 Report either during State Synchronization, or when a new prefix is 932 learned at the PCC. The length of this TLV is variable. 934 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 935 IPv6. 937 0 1 2 3 938 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 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Type=[TBD11] | Length | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | | 943 // Prefix Descriptor Sub-TLVs (variable) // 944 | | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 The value contains one or more Prefix Descriptor Sub-TLVs defined 948 below - 950 +--------------+-----------------------+----------+-----------------+ 951 | TLV Code | Description | Length | Value defined | 952 | Point | | | in: | 953 +--------------+-----------------------+----------+-----------------+ 954 | 5 | Multi-Topology | variable | [RFC7752] | 955 | | Identifier | | /3.2.1.5 | 956 | 11 | OSPF Route Type | 1 | [RFC7752] | 957 | | | | /3.2.3.1 | 958 | 12 | IP Reachability | variable | [RFC7752] | 959 | | Information | | /3.2.3.2 | 960 +--------------+-----------------------+----------+-----------------+ 962 9.3.9. PCEP-LS Attributes 964 9.3.9.1. Node Attributes TLV 966 This is an optional attribute that is used to carry node attributes. 967 This TLV is applicable for LS Node Object-Type. 969 0 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Type=[TBD12] | Length | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | | 975 // Node Attributes Sub-TLVs (variable) // 976 | | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 The Node Attributes Sub-TLV type and lengths are listed in the 980 following table: 982 +--------------+-----------------------+----------+-----------------+ 983 | Sub TLV | Description | Length | Value defined | 984 | | | | in: | 985 +--------------+-----------------------+----------+-----------------+ 986 | 5 | Multi-Topology | variable | [RFC7752] | 987 | | Identifier | | /3.2.1.5 | 988 | 13 | Node Flag Bits | 1 | [RFC7752] | 989 | | | | /3.3.1.1 | 990 | 14 | Opaque Node | variable | [RFC7752] | 991 | | Properties | | /3.3.1.5 | 992 | 15 | Node Name | variable | [RFC7752] | 993 | | | | /3.3.1.3 | 994 | 16 | IS-IS Area Identifier | variable | [RFC7752] | 995 | | | | /3.3.1.2 | 996 | 17 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 997 | | Local Node | | | 998 | 18 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 999 | | Local Node | | | 1000 +--------------+-----------------------+----------+-----------------+ 1002 9.3.9.2. Link Attributes TLV 1004 This TLV is applicable for LS Link Object-Type. The format and 1005 semantics of the 'value' fields in some 'Link Attribute' sub-TLVs 1006 correspond to the format and semantics of value fields in IS-IS 1007 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307] 1008 and [RFC7752]. Although the encodings for 'Link Attribute' TLVs were 1009 originally defined for IS-IS, the TLVs can carry data sourced either 1010 by IS-IS or OSPF or direct. 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Type=[TBD13] | Length | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | | 1018 // Link Attributes Sub-TLVs (variable) // 1019 | | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 The following 'Link Attribute' sub-TLVs are valid : 1024 +-----------+---------------------+--------------+------------------+ 1025 | Sub-TLV | Description | IS-IS TLV | Defined in: | 1026 | | | /Sub-TLV | | 1027 | | | BGP-LS TLV | | 1028 +-----------+---------------------+--------------+------------------+ 1029 | 17 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1030 | | Local Node | | | 1031 | 18 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1032 | | Local Node | | | 1033 | 19 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1034 | | Remote Node | | | 1035 | 20 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1036 | | Remote Node | | | 1037 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1038 | | Identifiers | | | 1039 | 22 | Administrative | 22/3 | [RFC5305]/3.1 | 1040 | | group (color) | | | 1041 | 23 | Maximum link | 22/9 | [RFC5305]/3.3 | 1042 | | bandwidth | | | 1043 | 24 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1044 | | link bandwidth | | | 1045 | 25 | Unreserved | 22/11 | [RFC5305]/3.6 | 1046 | | bandwidth | | | 1047 | 26 | TE Default Metric | 22/18 | [RFC7752] | 1048 | | | | /3.3.2.3 | 1049 | 27 | Link Protection | 22/20 | [RFC5307]/1.2 | 1050 | | Type | | | 1051 | 28 | MPLS Protocol Mask | 1094 | [RFC7752] | 1052 | | | | /3.3.2.2 | 1053 | 29 | IGP Metric | 1095 | [RFC7752] | 1054 | | | | /3.3.2.4 | 1055 | 30 | Shared Risk Link | 1096 | [RFC7752] | 1056 | | Group | | /3.3.2.5 | 1057 | 31 | Opaque link | 1097 | [RFC7752] | 1058 | | attributes | | /3.3.2.6 | 1059 | 32 | Link Name attribute | 1098 | [RFC7752] | 1060 | | | | /3.3.2.7 | 1061 | 33 | Unidirectional | 22/33 | [RFC7810]/4.1 | 1062 | | Link Delay | | | 1063 | 34 | Min/Max | 22/34 | [RFC7810]/4.2 | 1064 | | Unidirectional Link | | | 1065 | | Delay | | | 1066 | 35 | Unidirectional | 22/35 | [RFC7810]/4.3 | 1067 | | Delay Variation | | | 1068 | 36 | Unidirectional | 22/36 | [RFC7810]/4.4 | 1069 | | Link Loss | | | 1070 | 37 | Unidirectional | 22/37 | [RFC7810]/4.5 | 1071 | | Residual Bandwidth | | | 1072 | 38 | Unidirectional | 22/38 | [RFC7810]/4.6 | 1073 | | Available Bandwidth | | | 1074 | 39 | Unidirectional | 22/39 | [RFC7810]/4.7 | 1075 | | Bandwidth | | | 1076 | | Utilization | | | 1077 | 40 | Extended Admin | 22/14 | [RFC7308]/2.1 | 1078 | | Group (EAG) | | | 1079 +-----------+---------------------+--------------+------------------+ 1081 9.3.9.3. Prefix Attributes TLV 1083 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 1084 IPv6. Prefixes are learned from the IGP (IS-IS or OSPF) or BGP 1085 topology with a set of IGP attributes (such as metric, route tags, 1086 etc.). This section describes the different attributes related to 1087 the IPv4/IPv6 prefixes. Prefix Attributes TLVs SHOULD be encoded in 1088 the LS Prefix Object. 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Type=[TBD14] | Length | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | | 1096 // Prefix Attributes Sub-TLVs (variable) // 1097 | | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 The following 'Prefix Attribute' sub-TLVs are valid : 1102 +-----------+---------------------+--------------+------------------+ 1103 | Sub-TLV | Description | BGP-LS TLV | Defined in: | 1104 +-----------+---------------------+--------------+------------------+ 1105 | 41 | IGP Flags | 1152 | [RFC7752] | 1106 | | | | /3.3.3.1 | 1107 | 42 | Route Tag | 1153 | [RFC7752] | 1108 | | | | /3.3.3.2 | 1109 | 43 | Extended Tag | 1154 | [RFC7752] | 1110 | | | | /3.3.3.3 | 1111 | 44 | Prefix Metric | 1155 | [RFC7752] | 1112 | | | | /3.3.3.4 | 1113 | 45 | OSPF Forwarding | 1156 | [RFC7752] | 1114 | | Address | | /3.3.3.5 | 1115 | 46 | Opaque Prefix | 1157 | [RFC7752] | 1116 | | Attribute | | /3.3.3.6 | 1117 +-----------+---------------------+--------------+------------------+ 1119 9.3.10. Removal of an Attribute 1121 One of a key objective of PCEP-LS is to encode and carry only the 1122 impacted attributes of a Node, a Link or a Prefix. To accommodate 1123 this requirement, incase of a removal of an attribute, the sub-TLV 1124 MUST be included with no 'value' field and length=0 to indicate that 1125 the attribute is removed. On receiving a sub-TLV with zero length, 1126 the receiver removes the attribute from the database. 1128 10. Other Considerations 1130 10.1. Inter-AS Links 1132 The main source of LS (and TE) information is the IGP, which is not 1133 active on inter-AS links. In some cases, the IGP may have 1134 information of inter-AS links ([RFC5392], [RFC5316]). In other 1135 cases, an implementation SHOULD provide a means to inject inter-AS 1136 links into PCEP. The exact mechanism used to provision the inter-AS 1137 links is outside the scope of this document. 1139 11. Processing Rules 1141 12. Security Considerations 1143 This document extends PCEP for LS (and TE) distribution including a 1144 new LSRpt message with new object and TLVs. Procedures and protocol 1145 extensions defined in this document do not effect the overall PCEP 1146 security model. See [RFC5440], [I-D.ietf-pce-pceps]. Tampering with 1147 the LSRpt message may have an effect on path computations at PCE. It 1148 also provides adversaries an opportunity to eavesdrop and learn 1149 sensitive information and plan sophisticated attacks on the network 1150 infrastructure. The PCE implementation SHOULD provide mechanisms to 1151 prevent strains created by network flaps and amount of LS (and TE) 1152 information. Thus it is suggested that any mechanism used for 1153 securing the transmission of other PCEP message be applied here as 1154 well. As a general precaution, it is RECOMMENDED that these PCEP 1155 extensions only be activated on authenticated and encrypted sessions 1156 belonging to the same administrative authority. 1158 13. Manageability Considerations 1160 13.1. Control of Function and Policy 1162 TBD. 1164 13.2. Information and Data Models 1166 TBD. 1168 13.3. Liveness Detection and Monitoring 1170 TBD. 1172 13.4. Verify Correct Operations 1174 TBD. 1176 13.5. Requirements On Other Protocols 1178 TBD. 1180 13.6. Impact On Network Operations 1182 TBD. 1184 14. IANA Considerations 1186 This document requests IANA actions to allocate code points for the 1187 protocol elements defined in this document. 1189 14.1. PCEP Messages 1191 IANA created a registry for PCEP messages. Each PCEP message has a 1192 message type value. This document defines a new PCEP message value. 1194 Value Meaning Reference 1195 TBD3 LSRpt [This I-D] 1197 14.2. PCEP Objects 1199 This document defines the following new PCEP Object-classes and 1200 Object-values: 1202 Object-Class Value Name Reference 1203 TBD6 LS Object [This I-D] 1204 Object-Type=1 1205 (LS Node) 1206 Object-Type=2 1207 (LS Link) 1208 Object-Type=3 1209 (LS IPv4 Prefix) 1210 Object-Type=4 1211 (LS IPv6 Prefix) 1213 14.3. LS Object 1215 This document requests that a new sub-registry, named "LS Object 1216 Protocol-ID Field", is created within the "Path Computation Element 1217 Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP 1218 object. New values are to be assigned by Standards Action [RFC5226]. 1220 Value Meaning Reference 1221 0 Reserved [This I-D] 1222 1 IS-IS Level 1 [This I-D] 1223 2 IS-IS Level 2 [This I-D] 1224 3 OSPFv2 [This I-D] 1225 4 Direct [This I-D] 1226 5 Static configuration [This I-D] 1227 6 OSPFv3 [This I-D] 1228 7 BGP-LS [This I-D] 1229 8 PCEP-LS [This I-D] 1230 9 Abstraction [This I-D] 1231 10 Unspecified [This I-D] 1233 Further, this document also requests that a new sub-registry, named 1234 "LS Object Flag Field", is created within the "Path Computation 1235 Element Protocol (PCEP) Numbers" registry to manage the Flag field of 1236 the LSP object.New values are to be assigned by Standards Action 1237 [RFC5226]. Each bit should be tracked with the following qualities: 1239 o Bit number (counting from bit 0 as the most significant bit) 1241 o Capability description 1243 o Defining RFC 1245 The following values are defined in this document: 1247 Bit Description Reference 1248 0-21 Unassigned 1249 22 R (Remove bit) [This I-D] 1250 23 S (Sync bit) [This I-D] 1252 14.4. PCEP-Error Object 1254 IANA is requested to make the following allocation in the "PCEP-ERROR 1255 Object Error Types and Values" registry. 1257 Error-Type Meaning Reference 1258 6 Mandatory Object missing [RFC5440] 1259 Error-Value=TBD4 [This I-D] 1260 (LS object missing) 1262 19 Invalid Operation [I-D.ietf-pce-stateful-pce] 1263 Error-Value=TBD1 [This I-D] 1264 (Attempted LS Report if LS 1265 remote capability was not 1266 advertised) 1268 TBD2 LS Synchronization Error [This I-D] 1269 Error-Value=1 1270 (An error in processing the 1271 LSRpt) 1272 Error-Value=2 1273 (An internal PCC error) 1275 14.5. PCEP TLV Type Indicators 1277 This document defines the following new PCEP TLVs. 1279 Value Meaning Reference 1280 TBD5 LS-CAPABILITY TLV [This I-D] 1281 TBD7 ROUTING-UNIVERSE TLV [This I-D] 1282 TBD15 ROUTE-DISTINGUISHER TLV [This I-D] 1283 TBD8 Local Node Descriptors TLV [This I-D] 1284 TBD9 Remote Node Descriptors TLV [This I-D] 1285 TBD10 Link Descriptors TLV [This I-D] 1286 TBD11 Prefix Descriptors TLV [This I-D] 1287 TBD12 Node Attributes TLV [This I-D] 1288 TBD13 Link Attributes TLV [This I-D] 1289 TBD14 Prefix Attributes TLV [This I-D] 1291 14.6. PCEP-LS Sub-TLV Type Indicators 1293 This document specifies the PCEP-LS Sub-TLVs. IANA is requested to 1294 create an "PCEP-LS Sub-TLV Types" sub-registry in the "PCEP TLV Type 1295 Indicators" for the sub-TLVs carried in the PCEP-LS TLV (Local and 1296 Remote Node Descriptors TLV, Link Descriptors TLV, Prefix Descriptors 1297 TLV, Node Attributes TLV, Link Attributes TLV and Prefix Attributes 1298 TLV. This document defines the following types: 1300 +-----------+---------------------+---------------+-----------------+ 1301 | Sub-TLV | Description | Ref | Value defined | 1302 | | | Sub-TLV | in: | 1303 +-----------+---------------------+---------------+-----------------+ 1304 | 1 | Autonomous System | 512 | [RFC7752] | 1305 | | | | /3.2.1.4 | 1306 | 2 | BGP-LS Identifier | 513 | [RFC7752] | 1307 | | | | /3.2.1.4 | 1308 | 3 | OSPF Area-ID | 514 | [RFC7752] | 1309 | | | | /3.2.1.4 | 1310 | 4 | Router-ID | 515 | [RFC7752] | 1311 | | | | /3.2.1.4 | 1312 | 5 | Multi-Topology-ID | 263 | [RFC7752] | 1313 | | | | /3.2.1.5 | 1314 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1315 | | Identifiers | | | 1316 | 7 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1317 | | address | | | 1318 | 8 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1319 | | address | | | 1320 | 9 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1321 | | address | | | 1322 | 10 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1323 | | address | | | 1324 | 11 | OSPF Route Type | 264 | [RFC7752] | 1325 | | | | /3.2.3.1 | 1326 | 12 | IP Reachability | 265 | [RFC7752] | 1327 | | Information | | /3.2.3.2 | 1328 | 13 | Node Flag Bits | 1024 | [RFC7752] | 1329 | | | | /3.3.1.1 | 1330 | 14 | Opaque Node | 1025 | [RFC7752] | 1331 | | Properties | | /3.3.1.5 | 1332 | 15 | Node Name | 1026 | [RFC7752] | 1333 | | | | /3.3.1.3 | 1334 | 16 | IS-IS Area | 1027 | [RFC7752] | 1335 | | Identifier | | /3.3.1.2 | 1336 | 17 | IPv4 Router-ID of | 134/-- | [RFC5305]/4.3 | 1337 | | Local Node | | | 1338 | 18 | IPv6 Router-ID of | 140/-- | [RFC6119]/4.1 | 1339 | | Local Node | | | 1340 | 19 | IPv4 Router-ID of | 134/-- | [RFC5305]/4.3 | 1341 | | Remote Node | | | 1342 | 20 | IPv6 Router-ID of | 140/-- | [RFC6119]/4.1 | 1343 | | Remote Node | | | 1344 | 22 | Administrative | 22/3 | [RFC5305]/3.1 | 1345 | | group (color) | | | 1346 | 23 | Maximum link | 22/9 | [RFC5305]/3.3 | 1347 | | bandwidth | | | 1348 | 24 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1349 | | link bandwidth | | | 1350 | 25 | Unreserved | 22/11 | [RFC5305]/3.6 | 1351 | | bandwidth | | | 1352 | 26 | TE Default Metric | 22/18 | [RFC7752] | 1353 | | | | /3.3.2.3 | 1354 | 27 | Link Protection | 22/20 | [RFC5307]/1.2 | 1355 | | Type | | | 1356 | 28 | MPLS Protocol Mask | 1094 | [RFC7752] | 1357 | | | | /3.3.2.2 | 1358 | 29 | IGP Metric | 1095 | [RFC7752] | 1359 | | | | /3.3.2.4 | 1360 | 30 | Shared Risk Link | 1096 | [RFC7752] | 1361 | | Group | | /3.3.2.5 | 1362 | 31 | Opaque link | 1097 | [RFC7752] | 1363 | | attributes | | /3.3.2.6 | 1364 | 32 | Link Name attribute | 1098 | [RFC7752] | 1365 | | | | /3.3.2.7 | 1366 | 33 | Unidirectional | 22/33 | [RFC7810]/4.1 | 1367 | | Link Delay | | | 1368 | 34 | Min/Max | 22/34 | [RFC7810]/4.2 | 1369 | | Unidirectional Link | | | 1370 | | Delay | | | 1371 | 35 | Unidirectional | 22/35 | [RFC7810]/4.3 | 1372 | | Delay Variation | | | 1373 | 36 | Unidirectional | 22/36 | [RFC7810]/4.4 | 1374 | | Link Loss | | | 1375 | 37 | Unidirectional | 22/37 | [RFC7810]/4.5 | 1376 | | Residual Bandwidth | | | 1377 | 38 | Unidirectional | 22/38 | [RFC7810]/4.6 | 1378 | | Available Bandwidth | | | 1379 | 39 | Unidirectional | 22/39 | [RFC7810]/4.7 | 1380 | | Bandwidth | | | 1381 | | Utilization | | | 1382 | 40 | Extended Admin | 22/14 | [RFC7308]/2.1 | 1383 | | Group (EAG) | | | 1384 | 41 | IGP Flags | 1152 | [RFC7752] | 1385 | | | | /3.3.3.1 | 1386 | 42 | Route Tag | 1153 | [RFC7752] | 1387 | | | | /3.3.3.2 | 1388 | 43 | Extended Tag | 1154 | [RFC7752] | 1389 | | | | /3.3.3.3 | 1390 | 44 | Prefix Metric | 1155 | [RFC7752] | 1391 | | | | /3.3.3.4 | 1392 | 45 | OSPF Forwarding | 1156 | [RFC7752] | 1393 | | Address | | /3.3.3.5 | 1394 | 46 | Opaque Prefix | 1157 | [RFC7752] | 1395 | | Attribute | | /3.3.3.6 | 1396 +-----------+---------------------+---------------+-----------------+ 1397 New values are to be assigned by Standards Action [RFC5226]. 1399 15. TLV/Sub-TLV Code Points Summary 1401 This section contains the global table of all TLVs/Sub-TLVs in LS 1402 object defined in this document. 1404 +-----------+---------------------+---------------+-----------------+ 1405 | TLV | Description | Ref TLV | Value defined | 1406 | | | | in: | 1407 +-----------+---------------------+---------------+-----------------+ 1408 | TBD7 | Routing Universe | -- | Sec 9.2.1 | 1409 | TBD15 | Route | -- | Sec 9.2.2 | 1410 | | Distinguisher | | | 1411 | * | Virtual Network | -- | [leedhody-pce- | 1412 | | | | vn-association] | 1413 | TBD8 | Local Node | 256 | [RFC7752] | 1414 | | Descriptors | | /3.2.1.2 | 1415 | TBD9 | Remote Node | 257 | [RFC7752] | 1416 | | Descriptors | | /3.2.1.3 | 1417 | TBD10 | Link Descriptors | -- | Sec 9.2.8 | 1418 | TBD11 | Prefix Descriptors | -- | Sec 9.2.9 | 1419 | TBD12 | Node Attributes | -- | Sec 9.2.10.1 | 1420 | TBD13 | Link Attributes | -- | Sec 9.2.10.2 | 1421 | TBD14 | Prefix Attributes | -- | Sec 9.2.10.3 | 1422 +-----------+---------------------+---------------+-----------------+ 1424 * this TLV is defined in a different PCEP document 1426 TLV Table 1428 Refer Section 14.6 for the table of Sub-TLVs. 1430 16. Acknowledgments 1432 This document borrows some of the structure and text from the 1433 [RFC7752]. 1435 Thanks to Eric Wu, Venugopal Kondreddy, Mahendra Singh Negi, 1436 Avantika, and Zhengbin Li for the reviews. 1438 Thanks to Ramon Casellas for his comments and suggestions based on 1439 his implementation expierence. 1441 17. References 1443 17.1. Normative References 1445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1446 Requirement Levels", BCP 14, RFC 2119, 1447 DOI 10.17487/RFC2119, March 1997, 1448 . 1450 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1451 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1452 2008, . 1454 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1455 in Support of Generalized Multi-Protocol Label Switching 1456 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1457 . 1459 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1460 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1461 DOI 10.17487/RFC5440, March 2009, 1462 . 1464 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1465 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 1466 February 2011, . 1468 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1469 S. Ray, "North-Bound Distribution of Link-State and 1470 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1471 DOI 10.17487/RFC7752, March 2016, 1472 . 1474 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1475 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1476 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1477 . 1479 17.2. Informative References 1481 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1482 (TE) Extensions to OSPF Version 2", RFC 3630, 1483 DOI 10.17487/RFC3630, September 2003, 1484 . 1486 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1487 Support of Generalized Multi-Protocol Label Switching 1488 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1489 . 1491 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1492 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1493 2006, . 1495 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1496 Element (PCE)-Based Architecture", RFC 4655, 1497 DOI 10.17487/RFC4655, August 2006, 1498 . 1500 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1501 Topology (MT) Routing in Intermediate System to 1502 Intermediate Systems (IS-ISs)", RFC 5120, 1503 DOI 10.17487/RFC5120, February 2008, 1504 . 1506 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1507 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1508 DOI 10.17487/RFC5226, May 2008, 1509 . 1511 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1512 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1513 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1514 December 2008, . 1516 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1517 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1518 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 1519 January 2009, . 1521 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1522 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1523 March 2012, . 1525 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1526 Path Computation Element Architecture to the Determination 1527 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1528 DOI 10.17487/RFC6805, November 2012, 1529 . 1531 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 1532 Ward, "IS-IS Multi-Instance", RFC 6822, 1533 DOI 10.17487/RFC6822, December 2012, 1534 . 1536 [I-D.ietf-pce-stateful-pce] 1537 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1538 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1539 pce-18 (work in progress), December 2016. 1541 [I-D.ietf-pce-pce-initiated-lsp] 1542 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1543 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1544 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 1545 progress), July 2016. 1547 [I-D.ietf-pce-pceps] 1548 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1549 Transport for PCEP", draft-ietf-pce-pceps-11 (work in 1550 progress), January 2017. 1552 [I-D.kondreddy-pce-pcep-ls-sync-optimizations] 1553 Kondreddy, V. and M. Negi, "Optimizations of PCEP Link- 1554 State(LS) Synchronization Procedures", draft-kondreddy- 1555 pce-pcep-ls-sync-optimizations-00 (work in progress), 1556 October 2015. 1558 [I-D.leedhody-teas-pcep-ls] 1559 Lee, Y., Dhody, D., and D. Ceccarelli, "Architecture and 1560 Requirement for Distribution of Link-State and TE 1561 Information via PCEP.", draft-leedhody-teas-pcep-ls-03 1562 (work in progress), September 2016. 1564 [I-D.ietf-teas-actn-framework] 1565 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 1566 Control of Traffic Engineered Networks", draft-ietf-teas- 1567 actn-framework-04 (work in progress), February 2017. 1569 [I-D.ietf-teas-actn-requirements] 1570 Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D. 1571 Ceccarelli, "Requirements for Abstraction and Control of 1572 TE Networks", draft-ietf-teas-actn-requirements-04 (work 1573 in progress), January 2017. 1575 [I-D.leedhody-pce-vn-association] 1576 Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP 1577 Extensions for Establishing Relationships Between Sets of 1578 LSPs and Virtual Networks", draft-leedhody-pce-vn- 1579 association-01 (work in progress), October 2016. 1581 [I-D.dhody-pce-applicability-actn] 1582 Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 1583 Path Computation Element (PCE) for Abstraction and Control 1584 of TE Networks (ACTN)", draft-dhody-pce-applicability- 1585 actn-01 (work in progress), October 2016. 1587 Appendix A. Relevant OSPF TLV and sub-TLV 1589 This section list the relevant TLVs and sub-TLVs defined for OSPF. 1591 +-----------+---------------------+---------------+-----------------+ 1592 | Sub-TLV | Description | OSPF-TE | Value defined | 1593 | | | Sub-TLV | in: | 1594 +-----------+---------------------+---------------+-----------------+ 1595 | 6 | Link Local/Remote | 11 | [RFC4203]/1.1 | 1596 | | Identifiers | | | 1597 | 7 | IPv4 interface | 3 | [RFC3630]/2.5.3 | 1598 | | address | | | 1599 | 8 | IPv4 neighbor | 4 | [RFC3630]/2.5.4 | 1600 | | address | | | 1601 | 9 | IPv6 interface | 19 | [RFC5329]/4.3 | 1602 | | address | | | 1603 | 10 | IPv6 neighbor | 20 | [RFC5329]/4.4 | 1604 | | address | | | 1605 | 17 | IPv4 Router-ID of | 1 | [RFC3630]/2.4.1 | 1606 | | Local Node | | | 1607 | 18 | IPv6 Router-ID of | 3 | [RFC5329]/3 | 1608 | | Local Node | | | 1609 | 19 | IPv4 Router-ID of | 1 | [RFC3630]/2.4.1 | 1610 | | Remote Node | | | 1611 | 20 | IPv6 Router-ID of | 3 | [RFC5329]/3 | 1612 | | Remote Node | | | 1613 | 22 | Administrative | 9 | [RFC3630]/2.5.9 | 1614 | | group (color) | | | 1615 | 23 | Maximum link | 6 | [RFC3630]/2.5.6 | 1616 | | bandwidth | | | 1617 | 24 | Max. reservable | 7 | [RFC3630]/2.5.7 | 1618 | | link bandwidth | | | 1619 | 25 | Unreserved | 8 | [RFC3630]/2.5.8 | 1620 | | bandwidth | | | 1621 | 27 | Link Protection | 14 | [RFC4203]/1.2 | 1622 | | Type | | | 1623 | 30 | Shared Risk Link | 16 | [RFC4203]/1.3 | 1624 | | Group | | | 1625 | 33 | Unidirectional | 27 | [RFC7471]/4.1 | 1626 | | Link Delay | | | 1627 | 34 | Min/Max | 28 | [RFC7471]/4.2 | 1628 | | Unidirectional Link | | | 1629 | | Delay | | | 1630 | 35 | Unidirectional | 29 | [RFC7471]/4.3 | 1631 | | Delay Variation | | | 1632 | 36 | Unidirectional | 30 | [RFC7471]/4.4 | 1633 | | Link Loss | | | 1634 | 37 | Unidirectional | 31 | [RFC7471]/4.5 | 1635 | | Residual Bandwidth | | | 1636 | 38 | Unidirectional | 32 | [RFC7471]/4.6 | 1637 | | Available Bandwidth | | | 1638 | 39 | Unidirectional | 33 | [RFC7471]/4.7 | 1639 | | Bandwidth | | | 1640 | | Utilization | | | 1641 | 40 | Extended Admin | 26 | [RFC7308]/2.1 | 1642 | | Group (EAG) | | | 1643 +-----------+---------------------+---------------+-----------------+ 1645 Appendix B. Examples 1647 These examples are for illustration purposes only to show how the new 1648 PCEP-LS message could be encoded. They are not meant to be an 1649 exhaustive list of all possible use cases and combinations. 1651 B.1. All Nodes 1653 Each node (PCC) in the network chooses to provide its own local node 1654 and link information, and in this way PCE can build the full link 1655 state and TE information. 1657 +--------------------+ +--------------------+ 1658 | | | | 1659 | RTA |10.1.1.1 | RTB | 1660 | 1.1.1.1 |--------------------| 2.2.2.2 | 1661 | Area 0 | 10.1.1.2| Area 0 | 1662 | | | | 1663 +--------------------+ +--------------------+ 1664 RTA 1665 --- 1666 LS Node 1667 TLV - Local Node Descriptors 1668 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1669 Sub-TLV - 4: Router-ID: 1.1.1.1 1670 TLV - Node Attributes TLV 1671 Sub-TLV(s) 1673 LS Link 1674 TLV - Local Node Descriptors 1675 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1676 Sub-TLV - 4: Router-ID: 1.1.1.1 1677 TLV - Remote Node Descriptors 1678 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1679 Sub-TLV - 4: Router-ID: 2.2.2.2 1680 TLV - Link Descriptors 1681 Sub-TLV - 7: IPv4 interface: 10.1.1.1 1682 Sub-TLV - 8: IPv4 neighbor: 10.1.1.2 1683 TLV - Link Attributes TLV 1684 Sub-TLV(s) 1686 RTB 1687 --- 1688 LS Node 1689 TLV - Local Node Descriptors 1690 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1691 Sub-TLV - 4: Router-ID: 2.2.2.2 1692 TLV - Node Attributes TLV 1693 Sub-TLV(s) 1695 LS Link 1696 TLV - Local Node Descriptors 1697 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1698 Sub-TLV - 4: Router-ID: 2.2.2.2 1699 TLV - Remote Node Descriptors 1700 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1701 Sub-TLV - 4: Router-ID: 1.1.1.1 1702 TLV - Link Descriptors 1703 Sub-TLV - 7: IPv4 interface: 10.1.1.2 1704 Sub-TLV - 8: IPv4 neighbor: 10.1.1.1 1705 TLV - Link Attributes TLV 1706 Sub-TLV(s) 1708 B.2. Designated Node 1710 A designated node(s) in the network will provide its own local node 1711 as well as all learned remote information, and in this way PCE can 1712 build the full link state and TE information. 1714 As described in Appendix B.1, the same LS Node and Link objects will 1715 be generated with a differance that it would be a designated router 1716 say RTA that generate all this information. 1718 B.3. Between PCEs 1720 As per Hierarchical-PCE [RFC6805], Parent PCE builds an abstract 1721 domain topology map with each domain as an abstract node and inter- 1722 domain links as an abstract link. Each child PCE may provide this 1723 information to the parent PCE. Considering the example in figure 1 1724 of [RFC6805], following LS object will be generated: 1726 PCE1 1727 ---- 1728 LS Node 1729 TLV - Local Node Descriptors 1730 Sub-TLV - 1: Autonomous System: 100 (Domain 1) 1731 Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract) 1733 LS Link 1734 TLV - Local Node Descriptors 1735 Sub-TLV - 1: Autonomous System: 100 1736 Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract) 1737 TLV - Remote Node Descriptors 1738 Sub-TLV - 1: Autonomous System: 200 (Domain 2) 1739 Sub-TLV - 4: Router-ID: 22.22.22.22 (abstract) 1740 TLV - Link Descriptors 1741 Sub-TLV - 7: IPv4 interface: 11.1.1.1 1742 Sub-TLV - 8: IPv4 neighbor: 11.1.1.2 1743 TLV - Link Attributes TLV 1744 Sub-TLV(s) 1746 LS Link 1747 TLV - Local Node Descriptors 1748 Sub-TLV - 1: Autonomous System: 100 1749 Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract) 1750 TLV - Remote Node Descriptors 1751 Sub-TLV - 1: Autonomous System: 200 1752 Sub-TLV - 4: Router-ID: 22.22.22.22 (abstract) 1753 TLV - Link Descriptors 1754 Sub-TLV - 7: IPv4 interface: 12.1.1.1 1755 Sub-TLV - 8: IPv4 neighbor: 12.1.1.2 1756 TLV - Link Attributes TLV 1757 Sub-TLV(s) 1759 LS Link 1760 TLV - Local Node Descriptors 1761 Sub-TLV - 1: Autonomous System: 100 1762 Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract) 1763 TLV - Remote Node Descriptors 1764 Sub-TLV - 1: Autonomous System: 400 (Domain 4) 1765 Sub-TLV - 4: Router-ID: 44.44.44.44 (abstract) 1766 TLV - Link Descriptors 1767 Sub-TLV - 7: IPv4 interface: 13.1.1.1 1768 Sub-TLV - 8: IPv4 neighbor: 13.1.1.2 1769 TLV - Link Attributes TLV 1770 Sub-TLV(s) 1772 * similar information will be generated by other PCE 1773 to help form the abstract domain topology. 1775 Further the exact border nodes and abstract internal path between the 1776 border nodes may also be transported to the Parent PCE to enable ACTN 1777 as described in [I-D.dhody-pce-applicability-actn] using the similar 1778 LS node and link objects encodings. 1780 Appendix C. Contributor Addresses 1782 Udayasree Palle 1783 Huawei Technologies 1784 Divyashree Techno Park, Whitefield 1785 Bangalore, Karnataka 560066 1786 India 1788 EMail: udayasree.palle@huawei.com 1790 Sergio Belotti 1791 Alcatel-Lucent 1792 Italy 1794 EMail: sergio.belotti@alcatel-lucent.com 1796 Veerendranatha Reddy Vallem 1797 Huawei Technologies 1798 Divyashree Techno Park, Whitefield 1799 Bangalore, Karnataka 560066 1800 India 1802 Email: veerendranatharv@huawei.com 1804 Authors' Addresses 1806 Dhruv Dhody 1807 Huawei Technologies 1808 Divyashree Techno Park, Whitefield 1809 Bangalore, Karnataka 560066 1810 India 1812 EMail: dhruv.ietf@gmail.com 1814 Young Lee 1815 Huawei Technologies 1816 5340 Legacy Drive, Building 3 1817 Plano, TX 75023 1818 USA 1820 EMail: leeyoung@huawei.com 1821 Daniele Ceccarelli 1822 Ericsson 1823 Torshamnsgatan,48 1824 Stockholm 1825 Sweden 1827 EMail: daniele.ceccarelli@ericsson.com