idnits 2.17.1 draft-dhodylee-pce-pcep-ls-06.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 (September 13, 2016) is 2782 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 512, but not defined == Missing Reference: 'TBD5' is mentioned on line 587, but not defined == Missing Reference: 'TBD6' is mentioned on line 617, but not defined == Missing Reference: 'This I-D' is mentioned on line 1279, but not defined == Unused Reference: 'RFC7810' is defined on line 1461, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 1487, 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-16 == 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 (~~), 18 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 17, 2017 D. Ceccarelli 6 Ericsson 7 September 13, 2016 9 PCEP Extension for Distribution of Link-State and TE Information. 10 draft-dhodylee-pce-pcep-ls-06 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 17, 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 . . . . . . . . . . . . . . . . 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. Open Object . . . . . . . . . . . . . . . . . . . . . . . 13 75 9.1.1. LS Capability TLV . . . . . . . . . . . . . . . . . . 13 76 9.2. LS Object . . . . . . . . . . . . . . . . . . . . . . . . 14 77 9.2.1. Routing Universe TLV . . . . . . . . . . . . . . . . 15 78 9.2.2. Route Distinguisher TLV . . . . . . . . . . . . . . . 16 79 9.2.3. Virtual Network TLV . . . . . . . . . . . . . . . . . 17 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. Examples . . . . . . . . . . . . . . . . . . . . . . 37 115 B.1. All Nodes . . . . . . . . . . . . . . . . . . . . . . . . 37 116 B.2. Designated Node . . . . . . . . . . . . . . . . . . . . . 38 117 B.3. Between PCEs . . . . . . . . . . . . . . . . . . . . . . 38 118 Appendix C. Contributor Addresses . . . . . . . . . . . . . . . 40 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 121 1. Introduction 123 In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS), 124 a Traffic Engineering Database (TED) is used in computing paths for 125 connection oriented packet services and for circuits. The TED 126 contains all relevant information that a Path Computation Element 127 (PCE) needs to perform its computations. It is important that the 128 TED be complete and accurate each time, the PCE performs a path 129 computation. 131 In MPLS and GMPLS, interior gateway routing protocols (IGPs) have 132 been used to create and maintain a copy of the TED at each node 133 running the IGP. One of the benefits of the PCE architecture 134 [RFC4655] is the use of computationally more sophisticated path 135 computation algorithms and the realization that these may need 136 enhanced processing power not necessarily available at each node 137 participating in an IGP. 139 Section 4.3 of [RFC4655] describes the potential load of the TED on a 140 network node and proposes an architecture where the TED is maintained 141 by the PCE rather than the network nodes. However, it does not 142 describe how a PCE would obtain the information needed to populate 143 its TED. PCE may construct its TED by participating in the IGP 144 ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for 145 GMPLS). An alternative is offered by BGP-LS [RFC7752] . 147 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 148 provide stateful control. A stateful PCE has access to not only the 149 information carried by the network's Interior Gateway Protocol (IGP), 150 but also the set of active paths and their reserved resources for its 151 computations. PCC can delegate the rights to modify the LSP 152 parameters to an Active Stateful PCE. This requires PCE to quickly 153 be updated on any changes in the Topology and TEDB, so that PCE can 154 meet the need for updating LSPs effectively and in a timely manner. 155 The fastest way for a PCE to be updated on TED changes is via a 156 direct interface with each network node and with incremental update 157 from each network node with only the attribute that is modified. 159 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and 160 teardown of PCE-initiated LSPs under the stateful PCE model, without 161 the need for local configuration on the PCC, thus allowing for a 162 dynamic network that is centrally controlled and deployed. This 163 model requires timely topology and TED update at the PCE. 165 [I-D.leedhody-teas-pcep-ls] proposes some other approaches for 166 learning and maintaining the Link-State and TE information directly 167 on a PCE as an alternative to IGPs and BGP flooding and investigate 168 the impact from the PCE, routing protocol, and node perspectives. 170 [RFC5440] describes the specifications for the Path Computation 171 Element Communication Protocol (PCEP). PCEP specifies the 172 communication between a Path Computation Client (PCC) and a Path 173 Computation Element (PCE), or between two PCEs based on the PCE 174 architecture [RFC4655]. 176 This document describes a mechanism by which Link State and TE 177 information can be collected from networks and shared with PCE using 178 the PCEP itself. This is achieved using a new PCEP message format. 179 The mechanism is applicable to physical and virtual links as well as 180 further subjected to various policies. 182 A network node maintains one or more databases for storing link-state 183 and TE information about nodes and links in any given area. Link 184 attributes stored in these databases include: local/remote IP 185 addresses, local/ remote interface identifiers, link metric and TE 186 metric, link bandwidth, reservable bandwidth, per CoS class 187 reservation state, preemption and Shared Risk Link Groups (SRLG). 188 The node's PCEP process can retrieve topology from these databases 189 and distribute it to a PCE, either directly or via another PCEP 190 Speaker, using the encoding specified in this document. 192 Further [RFC6805] describes Hierarchical-PCE architecture, where a 193 parent PCE maintains a domain topology map. To build this domain 194 topology map, the child PCE can carry the border nodes and inter- 195 domain link information to the parent PCE using the mechanism 196 described in this document. Further as described in 197 [I-D.dhody-pce-applicability-actn], the child PCE can also transport 198 abstract Link-State and TE information from child PCE to a Parent PCE 199 using the mechanism described in this document to build an abstract 200 topology at the parent PCE. 202 [I-D.ietf-pce-stateful-pce] describe LSP state synchronization 203 between PCCs and PCEs in case of stateful PCE. This document does 204 not make any change to the LSP state synchronization process. The 205 mechanism described in this document are on top of the existing LSP 206 state synchronization. 208 1.1. Requirements Language 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [RFC2119]. 214 2. Terminology 216 The terminology is as per [RFC4655] and [RFC5440]. 218 3. Applicability 220 As per [I-D.leedhody-teas-pcep-ls], the mechanism specified in this 221 draft is applicable to: 223 o Where there is no IGP or BGP-LS running in the network. 225 o Where there is no IGP or BGP-LS running at the PCE to learn link- 226 state and TE information. 228 o Where there is IGP or BGP-LS running but with a need for a faster 229 TE and link-state population and convergence at the PCE. 231 * A PCE may receive partial information (say basic TE, link- 232 state) from IGP and other information (optical and impairment) 233 from PCEP. 235 * A PCE may receive an incremental update (as opposed to the 236 entire information of the node/link). 238 * A PCE may receive full information from both existing mechanism 239 (IGP or BGP) and PCEP. 241 o Where there is a need for transporting (abstract) Link-State and 242 TE information from child PCE to a Parent PCE in H-PCE [RFC6805]; 243 as well as for Physical Network Controller (PNC) to Multi-Domain 244 Service Coordinator (MDSC) in Abstraction and Control of TE 245 Networks (ACTN) [I-D.ietf-teas-actn-framework]. 247 A PCC may further choose to send only local information or both local 248 and remote learned information. 250 How a PCE manages the link-state (and TE) information is 251 implementation specific and thus out of scope of this document. 253 The prefix information in PCEP-LS can also help in determining the 254 domain of the endpoints in H-PCE (and ACTN). Section 4.5 of 255 [RFC6805] describe various mechanism and procedures that might be 256 used, PCEP-LS provides a simple mechanism to exchange this 257 information. 259 4. Requirements for PCEP extension 261 Following key requirements associated with link-state (and TE) 262 distribution are identified for PCEP: 264 1. The PCEP speaker supporting this draft MUST be a mechanism to 265 advertise the Link-State (and TE) distribution capability. 267 2. PCC supporting this draft MUST have the capability to report the 268 link-state (and TE) information to the PCE. This includes self 269 originated information and remote information learned via routing 270 protocols. PCC MUST be capable to do the initial bulk sync at 271 the time of session initialization as well as changes after. 273 3. A PCE MAY learn link-state (and TE) from PCEP as well as from 274 existing mechanism like IGP/BGP-LS. PCEP extension MUST have a 275 mechanism to link the information learned via other means. There 276 MUST NOT be any changes to the existing link-state (and TE) 277 population mechanism via IGP/BGP-LS. PCEP extension SHOULD keep 278 the properties in a protocol (IGP or BGP-LS) neutral way, such 279 that an implementation may not need to know about any OSPF or IS- 280 IS or BGP protocol specifics. 282 4. It SHOULD be possible to encode only the changes in link-state 283 (and TE) properties (after the initial sync) in PCEP messages. 285 5. The same mechanism should be used for both MPLS TE as well as 286 GMPLS, optical and impairment aware properties. 288 6. The same mechanism should be used for PCE to PCE Link-state (and 289 TE) synchronization. 291 7. The extension in this draft SHOULD be extensible to support 292 various architecture options listed in 293 [I-D.leedhody-teas-pcep-ls]. 295 5. New Functions to distribute link-state (and TE) via PCEP 297 Several new functions are required in PCEP to support distribution of 298 link-state (and TE) information. A function can be initiated either 299 from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). 300 The new functions are: 302 o Capability advertisement (E-C,C-E): both the PCC and the PCE must 303 announce during PCEP session establishment that they support PCEP 304 extensions for distribution of link-state (and TE) information 305 defined in this document. 307 o Link-State (and TE) synchronization (C-E): after the session 308 between the PCC and a PCE is initialized, the PCE must learn Link- 309 State (and TE) information before it can perform path 310 computations. In case of stateful PCE it is RECOMENDED that this 311 operation be done before LSP state synchronization. 313 o Link-State (and TE) Report (C-E): a PCC sends a LS (and TE) report 314 to a PCE whenever the Link-State and TE information changes. 316 6. Overview of Extension to PCEP 318 6.1. New Messages 320 In this document, we define a new PCEP messages called LS Report 321 (LSRpt), a PCEP message sent by a PCC to a PCE to report link-state 322 (and TE) information. Each LS Report in a LSRpt message can contain 323 the node or link properties. An unique PCEP specific LS identifier 324 (LS-ID) is also carried in the message to identify a node or link and 325 that remains constant for the lifetime of a PCEP session. This 326 identifier on its own is sufficient when no IGP or BGP-LS running in 327 the network for PCE to learn link-state (and TE) information. Incase 328 PCE learns some information from PCEP and some from the existing 329 mechanism, the PCC SHOULD include the mapping of IGP or BGP-LS 330 identifier to map the information populated via PCEP with IGP/BGP-LS. 331 See Section 8.1 for details. 333 6.2. Capability Advertisement 335 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 336 advertise their support of LS (and TE) distribution via PCEP 337 extensions. A PCEP Speaker includes the "LS Capability" TLV, 338 described in Section 9.1.1, in the OPEN Object to advertise its 339 support for PCEP-LS extensions. The presence of the LS Capability 340 TLV in PCC's OPEN Object indicates that the PCC is willing to send LS 341 Reports whenever local link-state (and TE) information changes. The 342 presence of the LS Capability TLV in PCE's OPEN message indicates 343 that the PCE is interested in receiving LS Reports whenever local 344 link-state (and TE) information changes. 346 The PCEP protocol extensions for LS (and TE) distribution MUST NOT be 347 used if one or both PCEP Speakers have not included the LS Capability 348 TLV in their respective OPEN message. If the PCE that supports the 349 extensions of this draft but did not advertise this capability, then 350 upon receipt of a LSRpt message from the PCC, it SHOULD generate a 351 PCErr with error-type 19 (Invalid Operation), error-value TBD1 352 (Attempted LS Report if LS capability was not advertised) and it will 353 terminate the PCEP session. 355 The LS reports sent by PCC MAY carry the remote link-state (and TE) 356 information learned via existing means like IGP and BGP-LS only if 357 both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV 358 to 'Remote Allowed (R Flag = 1)'. If this is not the case and LS 359 reports carry remote link-state (and TE) information, then a PCErr 360 with error-type 19 (Invalid Operation) and error-value TBD1 361 (Attempted LS Report if LS remote capability was not advertised) and 362 it will terminate the PCEP session. 364 6.3. Initial Link-State (and TE) Synchronization 366 The purpose of LS Synchronization is to provide a checkpoint-in- time 367 state replica of a PCC's link-state (and TE) data base in a PCE. 368 State Synchronization is performed immediately after the 369 Initialization phase (see [RFC5440]]). In case of stateful PCE 370 ([I-D.ietf-pce-stateful-pce]) it is RECOMENDED that the LS 371 synchronization should be done before LSP state synchronization. 373 During LS Synchronization, a PCC first takes a snapshot of the state 374 of its database, then sends the snapshot to a PCE in a sequence of LS 375 Reports. Each LS Report sent during LS Synchronization has the SYNC 376 Flag in the LS Object set to 1. The end of synchronization marker is 377 a LSRpt message with the SYNC Flag set to 0 for an LS Object with LS- 378 ID equal to the reserved value 0. If the PCC has no link-state to 379 synchronize, it will only send the end of synchronization marker. 381 Either the PCE or the PCC MAY terminate the session using the PCEP 382 session termination procedures during the synchronization phase. If 383 the session is terminated, the PCE MUST clean up state it received 384 from this PCC. The session re-establishment MUST be re-attempted per 385 the procedures defined in [RFC5440], including use of a back-off 386 timer. 388 If the PCC encounters a problem which prevents it from completing the 389 LS synchronization, it MUST send a PCErr message with error-type TBD2 390 (LS Synchronization Error) and error-value 2 (indicating an internal 391 PCC error) to the PCE and terminate the session. 393 The PCE does not send positive acknowledgements for properly received 394 LS synchronization messages. It MUST respond with a PCErr message 395 with error-type TBD2 (LS Synchronization Error) and error-value 1 396 (indicating an error in processing the LSRpt) if it encounters a 397 problem with the LS Report it received from the PCC and it MUST 398 terminate the session. 400 The LS reports can carry local as well as remote link-state (and TE) 401 information depending on the R flag in LS capability TLV. 403 The successful LS Synchronization sequences is shown in Figure 1. 405 +-+-+ +-+-+ 406 |PCC| |PCE| 407 +-+-+ +-+-+ 408 | | 409 |-----LSRpt, SYNC=1----->| (Sync start) 410 | | 411 |-----LSRpt, SYNC=1----->| 412 | . | 413 | . | 414 | . | 415 |-----LSRpt, SYNC=1----->| 416 | . | 417 | . | 418 | . | 419 | | 420 |-----LSRpt, SYNC=0----->| (End of sync marker 421 | | LS Report 422 | | for LS-ID=0) 423 | | (Sync done) 425 Figure 1: Successful LS synchronization 427 The sequence where the PCE fails during the LS Synchronization phase 428 is shown in Figure 2. 430 +-+-+ +-+-+ 431 |PCC| |PCE| 432 +-+-+ +-+-+ 433 | | 434 |-----LSRpt, SYNC=1----->| 435 | | 436 |-----LSRpt, SYNC=1----->| 437 | . | 438 | . | 439 | . | 440 |-----LSRpt, SYNC=1----->| 441 | | 442 |---LSRpt,SYNC=1 | 443 | \ ,-PCErr---| 444 | \ / | 445 | \/ | 446 | /\ | 447 | / `-------->| (Ignored) 448 |<--------` | 450 Figure 2: Failed LS synchronization (PCE failure) 452 The sequence where the PCC fails during the LS Synchronization phase 453 is shown in Figure 3. 455 +-+-+ +-+-+ 456 |PCC| |PCE| 457 +-+-+ +-+-+ 458 | | 459 |-----LSRpt, SYNC=1----->| 460 | | 461 |-----LSRpt, SYNC=1----->| 462 | . | 463 | . | 464 | . | 465 |-------- PCErr--------->| 466 | | 468 Figure 3: Failed LS synchronization (PCC failure) 470 6.3.1. Optimizations for LS Synchronization 472 These optimizations are described in 473 [I-D.kondreddy-pce-pcep-ls-sync-optimizations]. 475 6.4. LS Report 477 The PCC MUST report any changes in the link-state (and TE) 478 information to the PCE by sending a LS Report carried on a LSRpt 479 message to the PCE. Each node and Link would be uniquely identified 480 by a PCEP LS identifier (LS-ID). The LS reports may carry local as 481 well as remote link-state (and TE) information depending on the R 482 flag in LS capability TLV. In case R flag is set, It MAY also 483 include the mapping of IGP or BGP-LS identifier to map the 484 information populated via PCEP with IGP/BGP-LS. 486 More details about LSRpt message are in Section 8.1. 488 7. Transport 490 A permanent PCEP session MUST be established between a PCE and PCC 491 supporting link-state (and TE) distribution via PCEP. In the case of 492 session failure, session re-establishment MUST be re-attempted per 493 the procedures defined in [RFC5440]. 495 8. PCEP Messages 497 As defined in [RFC5440], a PCEP message consists of a common header 498 followed by a variable-length body made of a set of objects that can 499 be either mandatory or optional. An object is said to be mandatory 500 in a PCEP message when the object must be included for the message to 501 be considered valid. For each PCEP message type, a set of rules is 502 defined that specify the set of objects that the message can carry. 503 An implementation MUST form the PCEP messages using the object 504 ordering specified in this document. 506 8.1. LS Report Message 508 A PCEP LS Report message (also referred to as LSRpt message) is a 509 PCEP message sent by a PCC to a PCE to report the link-state (and TE) 510 information. A LSRpt message can carry more than one LS Reports. 511 The Message-Type field of the PCEP common header for the LSRpt 512 message is set to [TBD3]. 514 The format of the LSRpt message is as follows: 516 ::= 517 518 Where: 520 ::= [] 522 The LS object is a mandatory object which carries LS information of a 523 node or a link. Each LS object has an unique LS-ID as described in 524 Section 9.2. If the LS object is missing, the receiving PCE MUST 525 send a PCErr message with Error-type=6 (Mandatory Object missing) and 526 Error-value=[TBD4] (LS object missing). 528 A PCE may choose to implement a limit on the LS information a single 529 PCC can populate. If a LSRpt is received that causes the PCE to 530 exceed this limit, it MUST send a PCErr message with error-type 19 531 (invalid operation) and error-value 4 (indicating resource limit 532 exceeded) in response to the LSRpt message triggering this condition 533 and SHOULD terminate the session. 535 8.2. The PCErr Message 537 If a PCEP speaker has advertised the LS capability on the PCEP 538 session, the PCErr message MAY include the LS object. If the error 539 reported is the result of an LS report, then the LS-ID number MUST be 540 the one from the LSRpt that triggered the error. 542 The format of a PCErr message from [RFC5440] is extended as follows: 544 The format of the PCErr message is as follows: 546 ::= 547 ( [] ) | 548 [] 550 ::=[] 552 ::=[ | ] 553 555 ::=[] 557 ::=[] 559 ::=[] 561 9. Objects and TLV 563 The PCEP objects defined in this document are compliant with the PCEP 564 object format defined in [RFC5440]. The P flag and the I flag of the 565 PCEP objects defined in this document MUST always be set to 0 on 566 transmission and MUST be ignored on receipt since these flags are 567 exclusively related to path computation requests. 569 9.1. Open Object 571 This document defines a new optional TLV for use in the OPEN Object. 573 9.1.1. LS Capability TLV 575 The LS-CAPABILITY TLV is an optional TLV for use in the OPEN Object 576 for link-state (and TE) distribution via PCEP capability 577 advertisement. Its format is shown in the following figure: 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Type=[TBD5] | Length=4 | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Flags |R| 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 The type of the TLV is [TBD5] and it has a fixed length of 4 octets. 589 The value comprises a single field - Flags (32 bits): 591 o R (remote - 1 bit): if set to 1 by a PCC, the R Flag indicates 592 that the PCC allows reporting of remote LS information learned via 593 other means like IGP and BGP-LS; if set to 1 by a PCE, the R Flag 594 indicates that the PCE is capable of receiving remote LS 595 information (from the PCC point of view). The R Flag must be 596 advertised by both a PCC and a PCE for LSRpt messages to report 597 remote as well as local LS information on a PCEP session. The 598 TLVs related to IGP/BGP-LS identifier MUST be encoded when both 599 PCEP speakers have the R Flag set. 601 Unassigned bits are considered reserved. They MUST be set to 0 on 602 transmission and MUST be ignored on receipt. 604 Advertisement of the LS capability implies support of local link- 605 state (and TE) distribution, as well as the objects, TLVs and 606 procedures defined in this document. 608 9.2. LS Object 610 The LS (link-state) object MUST be carried within LSRpt messages and 611 MAY be carried within PCErr messages. The LS object contains a set 612 of fields used to specify the target node or link. It also contains 613 a flag indicating to a PCE that the LS synchronization is in 614 progress. The TLVs used with the LS object correlate with the IGP/ 615 BGP-LS encodings. 617 LS Object-Class is [TBD6]. 619 Four Object-Type values are defined for the LS object so far: 621 o LS Node: LS Object-Type is 1. 623 o LS Link: LS Object-Type is 2. 625 o LS IPv4 Topology Prefix: LS Object-Type is 3. 627 o LS IPv6 Topology Prefix: LS Object-Type is 4. 629 The format of all types of LS object is as follows: 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Protocol-ID | Flag |R|S| 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | LS-ID | 637 | | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 // TLVs // 640 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Protocol-ID (8-bit): The field provide the source information. The 644 protocol could be an IGP, BGP-LS or an abstraction algorithm. Incase 645 PCC only provides local information of the PCC, it MUST use Protocol- 646 ID as Direct. The following values are defined (some of them are 647 same as [RFC7752]): 649 +-------------+----------------------------------+ 650 | Protocol-ID | Source protocol | 651 +-------------+----------------------------------+ 652 | 1 | IS-IS Level 1 | 653 | 2 | IS-IS Level 2 | 654 | 3 | OSPFv2 | 655 | 4 | Direct | 656 | 5 | Static configuration | 657 | 6 | OSPFv3 | 658 | 7 | BGP-LS | 659 | 8 | Abstraction | 660 +-------------+----------------------------------+ 662 Flags (24-bit): 664 o S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSRpt sent 665 from a PCC during LS Synchronization. The S Flag MUST be set to 0 666 in other LSRpt messages sent from the PCC. 668 o R (Remove - 1 bit): On LSRpt messages the R Flag indicates that 669 the node/link/prefix has been removed from the PCC and the PCE 670 SHOULD remove from its database. Upon receiving an LS Report with 671 the R Flag set to 1, the PCE SHOULD remove all state for the 672 node/link/prefix identified by the LS Identifiers from its 673 database. 675 LS-ID(64-bit): A PCEP-specific identifier for the node or link or 676 prefix information. A PCC creates an unique LS-ID for each 677 node/link/prefix that is constant for the lifetime of a PCEP session. 678 The PCC will advertise the same LS-ID on all PCEP sessions it 679 maintains at a given times. All subsequent PCEP messages then 680 address the node/link/prefix by the LS-ID. The values of 0 and 681 0xFFFFFFFFFFFFFFFF are reserved. 683 Unassigned bits are considered reserved. They MUST be set to 0 on 684 transmission and MUST be ignored on receipt. 686 TLVs that may be included in the LS Object are described in the 687 following sections. 689 9.2.1. Routing Universe TLV 691 In case of remote link-state (and TE) population when existing IGP/ 692 BGP-LS are also used, OSPF and IS-IS may run multiple routing 693 protocol instances over the same link as described in [RFC7752]. See 694 [RFC6822] and [RFC6549] for more information. These instances define 695 independent "routing universes". The 64-Bit 'Identifier' field is 696 used to identify the "routing universe" where the LS object belongs. 698 The LS objects representing IGP objects (nodes or links or prefix) 699 from the same routing universe MUST have the same 'Identifier' value; 700 LS objects with different 'Identifier' values MUST be considered to 701 be from different routing universes. 703 The format of the optional ROUTING-UNIVERSE TLV is shown in the 704 following figure: 706 0 1 2 3 707 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 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Type=[TBD7] | Length=8 | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Identifier | 712 | | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Below table lists the 'Identifier' values that are defined as well- 716 known in this draft (same as [RFC7752]). 718 +------------+-----------------------------------+ 719 | Identifier | Routing Universe | 720 +------------+-----------------------------------+ 721 | 0 | Default Layer 3 Routing topology | 722 | 1-31 | Reserved | 723 +------------+-----------------------------------+ 725 If this TLV is not present the default value 0 is assumed. 727 9.2.2. Route Distinguisher TLV 729 Tho allow identification of VPN link, node and prefix information in 730 PCEP-LS, a Route Distinguisher (RD) [RFC4364] is used. The LS 731 objects from the same VPN MUST have the same RD; LS objects with 732 different RD values MUST be considered to be from different VPNs. 734 The format of the optional ROUTE-DISTINGUISHER TLV is shown in the 735 following figure: 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Type=[TBD15] | Length=8 | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Route Distinguisher | 743 | | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 The format of RD is as per [RFC4364]. 748 9.2.3. Virtual Network TLV 750 To realize ACTN, the MDSC needs to build an multi-domain topology. 751 This topology is best served, if this is an abstracted view of the 752 underlying network resources of each domain. It is also important to 753 provide a customer view of network slice for each customer. There is 754 a need to control the level of abstraction based on the deployment 755 scenario and business relationship between the controllers. 757 Virtual service coordination function in ACTN incorporates customer 758 service-related knowledge into the virtual network operations in 759 order to seamlessly operate virtual networks while meeting customer's 760 service requirements. [I-D.ietf-teas-actn-requirements] describes 761 various VN operations initiated by a customer/application. In this 762 context, there is a need for associating the abstracted link state 763 and TE topology with a VN "construct" to facilitate VN operations in 764 PCE architecture. 766 VIRTUAL-NETWORK-TLV as per [I-D.leedhody-pce-vn-association] can be 767 included in LS object to identify the link, node and prefix 768 information belongs to a particular VN. 770 9.2.4. Local Node Descriptors TLV 772 As described in [RFC7752], each link is anchored by a pair of Router- 773 IDs that are used by the underlying IGP, namely, 48 Bit ISO System-ID 774 for IS-IS and 32 bit Router-ID for OSPFv2 and OSPFv3. Incase of 775 additional auxiliary Router-IDs used for TE, these MUST also be 776 included in the link attribute TLV (see Section 9.2.9.2). 778 It is desirable that the Router-ID assignments inside the Node 779 Descriptor are globally unique. Some considerations for globally 780 unique Node/Link/Prefix identifiers are described in [RFC7752]. 782 The Local Node Descriptors TLV contains Node Descriptors for the node 783 anchoring the local end of the link. This TLV MUST be included in 784 the LS Report when during a given PCEP session a node/link/prefix is 785 first reported to a PCE. A PCC sends to a PCE the first LS Report 786 either during State Synchronization, or when a new node/link/prefix 787 is learned at the PCC. The value contains one or more Node 788 Descriptor Sub-TLVs, which allows specification of a flexible key for 789 any given node/link/prefix information such that global uniqueness of 790 the node/link/prefix is ensured. 792 This TLV is applicable for all LS Object-Type. 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Type=[TBD8] | Length | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | | 800 // Node Descriptor Sub-TLVs (variable) // 801 | | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 The value contains one or more Node Descriptor Sub-TLVs defined in 805 Section 9.2.6. 807 9.2.5. Remote Node Descriptors TLV 809 The Remote Node Descriptors contains Node Descriptors for the node 810 anchoring the remote end of the link. This TLV MUST be included in 811 the LS Report when during a given PCEP session a link is first 812 reported to a PCE. A PCC sends to a PCE the first LS Report either 813 during State Synchronization, or when a new link is learned at the 814 PCC. The length of this TLV is variable. The value contains one or 815 more Node Descriptor Sub-TLVs defined in Section 9.2.6. 817 This TLV is applicable for LS Link Object-Type. 819 0 1 2 3 820 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 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Type=[TBD9] | Length | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | | 825 // Node Descriptor Sub-TLVs (variable) // 826 | | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 9.2.6. Node Descriptors Sub-TLVs 831 The Node Descriptor Sub-TLV type Type and lengths are listed in the 832 following table: 834 +----------+-------------------+----------+----------------+ 835 | Sub-TLV | Description | Length |Value defined in| 836 +----------+-------------------+----------+----------------+ 837 | 0 | Reserved | - | - | 838 | 1 | Autonomous System | 4 | [RFC7752] | 839 | 2 | BGP-LS Identifier | 4 | / section | 840 | 3 | OSPF Area-ID | 4 | 3.2.1.4 | 841 | 4 | Router-ID | Variable | | 842 +----------+-------------------+----------+----------------+ 844 The sub-TLV values in Node Descriptor TLVs are defined as follows 845 (similar to [RFC7752]): 847 o Autonomous System: opaque value (32 Bit AS Number) 849 o BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 850 ASN, uniquely identifies the BGP-LS domain as described in 851 [RFC7752]. This sub-TLV is present only if the node implements 852 BGP-LS and the ID is set by the operator. 854 o OSPF Area ID: It is used to identify the 32 Bit area to which the 855 LS object belongs. Area Identifier allows the different LS 856 objects of the same node to be discriminated. 858 o Router ID: opaque value. Usage is described in [RFC7752] as IGP 859 Router ID. In case this is not learned from IGP, it SHOULD 860 contain the unique router ID, such as TE router ID. 862 9.2.7. Link Descriptors TLV 864 The Link Descriptors TLV contains Link Descriptors for each link. 865 This TLV MUST be included in the LS Report when during a given PCEP 866 session a link is first reported to a PCE. A PCC sends to a PCE the 867 first LS Report either during State Synchronization, or when a new 868 link is learned at the PCC. The length of this TLV is variable. The 869 value contains one or more Link Descriptor Sub-TLVs. 871 The 'Link descriptor' TLVs uniquely identify a link among multiple 872 parallel links between a pair of anchor routers similar to [RFC7752]. 874 This TLV is applicable for LS Link Object-Type. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Type=[TBD10] | Length | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | | 882 // Link Descriptor Sub-TLVs (variable) // 883 | | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 The Link Descriptor Sub-TLV type and lengths are listed in the 887 following table: 889 +-----------+---------------------+---------------+-----------------+ 890 | Sub-TLV | Description | IS-IS TLV | Value defined | 891 | | | /Sub-TLV | in: | 892 +-----------+---------------------+---------------+-----------------+ 893 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 894 | | Identifiers | | | 895 | 7 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 896 | | address | | | 897 | 8 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 898 | | address | | | 899 | 9 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 900 | | address | | | 901 | 10 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 902 | | address | | | 903 | 5 | Multi-Topology | - | [RFC7752]/ | 904 | | identifier | | 3.2.1.5 | 905 +-----------+---------------------+---------------+-----------------+ 907 The format and semantics of the 'value' fields in most 'Link 908 Descriptor' sub-TLVs correspond to the format and semantics of value 909 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 910 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 911 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 912 carry data sourced either by IS-IS or OSPF or direct. 914 The information about a link present in the LSA/LSP originated by the 915 local node of the link determines the set of sub-TLVs in the Link 916 Descriptor of the link as described in [RFC7752]. 918 9.2.8. Prefix Descriptors TLV 920 The Prefix Descriptors TLV contains Prefix Descriptors uniquely 921 identify an IPv4 or IPv6 Prefix originated by a Node. This TLV MUST 922 be included in the LS Report when during a given PCEP session a 923 prefix is first reported to a PCE. A PCC sends to a PCE the first LS 924 Report either during State Synchronization, or when a new prefix is 925 learned at the PCC. The length of this TLV is variable. 927 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 928 IPv6. 930 0 1 2 3 931 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 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Type=[TBD11] | Length | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | | 936 // Prefix Descriptor Sub-TLVs (variable) // 937 | | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 The value contains one or more Prefix Descriptor Sub-TLVs defined 941 below - 943 +--------------+-----------------------+----------+-----------------+ 944 | TLV Code | Description | Length | Value defined | 945 | Point | | | in: | 946 +--------------+-----------------------+----------+-----------------+ 947 | 5 | Multi-Topology | variable | [RFC7752] | 948 | | Identifier | | /3.2.1.5 | 949 | 11 | OSPF Route Type | 1 | [RFC7752] | 950 | | | | /3.2.3.1 | 951 | 12 | IP Reachability | variable | [RFC7752] | 952 | | Information | | /3.2.3.2 | 953 +--------------+-----------------------+----------+-----------------+ 955 9.2.9. PCEP-LS Attributes 957 9.2.9.1. Node Attributes TLV 959 This is an optional attribute that is used to carry node attributes. 960 This TLV is applicable for LS Node Object-Type. 962 0 1 2 3 963 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 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Type=[TBD12] | Length | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | | 968 // Node Attributes Sub-TLVs (variable) // 969 | | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 The Node Attributes Sub-TLV type and lengths are listed in the 973 following table: 975 +--------------+-----------------------+----------+-----------------+ 976 | Sub TLV | Description | Length | Value defined | 977 | | | | in: | 978 +--------------+-----------------------+----------+-----------------+ 979 | 5 | Multi-Topology | variable | [RFC7752] | 980 | | Identifier | | /3.2.1.5 | 981 | 13 | Node Flag Bits | 1 | [RFC7752] | 982 | | | | /3.3.1.1 | 983 | 14 | Opaque Node | variable | [RFC7752] | 984 | | Properties | | /3.3.1.5 | 985 | 15 | Node Name | variable | [RFC7752] | 986 | | | | /3.3.1.3 | 987 | 16 | IS-IS Area Identifier | variable | [RFC7752] | 988 | | | | /3.3.1.2 | 989 | 17 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 990 | | Local Node | | | 991 | 18 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 992 | | Local Node | | | 993 +--------------+-----------------------+----------+-----------------+ 995 9.2.9.2. Link Attributes TLV 997 This TLV is applicable for LS Link Object-Type. The format and 998 semantics of the 'value' fields in some 'Link Attribute' sub-TLVs 999 correspond to the format and semantics of value fields in IS-IS 1000 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307] 1001 and [RFC7752]. Although the encodings for 'Link Attribute' TLVs were 1002 originally defined for IS-IS, the TLVs can carry data sourced either 1003 by IS-IS or OSPF or direct. 1005 0 1 2 3 1006 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 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | Type=[TBD13] | Length | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | | 1011 // Link Attributes Sub-TLVs (variable) // 1012 | | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 The following 'Link Attribute' sub-TLVs are valid : 1017 +-----------+---------------------+--------------+------------------+ 1018 | Sub-TLV | Description | IS-IS TLV | Defined in: | 1019 | | | /Sub-TLV | | 1020 | | | BGP-LS TLV | | 1021 +-----------+---------------------+--------------+------------------+ 1022 | 17 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1023 | | Local Node | | | 1024 | 18 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1025 | | Local Node | | | 1026 | 19 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1027 | | Remote Node | | | 1028 | 20 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1029 | | Remote Node | | | 1030 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1031 | | Identifiers | | | 1032 | 22 | Administrative | 22/3 | [RFC5305]/3.1 | 1033 | | group (color) | | | 1034 | 23 | Maximum link | 22/9 | [RFC5305]/3.3 | 1035 | | bandwidth | | | 1036 | 24 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1037 | | link bandwidth | | | 1038 | 25 | Unreserved | 22/11 | [RFC5305]/3.6 | 1039 | | bandwidth | | | 1040 | 26 | TE Default Metric | 22/18 | [RFC7752] | 1041 | | | | /3.3.2.3 | 1042 | 27 | Link Protection | 22/20 | [RFC5307]/1.2 | 1043 | | Type | | | 1044 | 28 | MPLS Protocol Mask | 1094 | [RFC7752] | 1045 | | | | /3.3.2.2 | 1046 | 29 | IGP Metric | 1095 | [RFC7752] | 1047 | | | | /3.3.2.4 | 1048 | 30 | Shared Risk Link | 1096 | [RFC7752] | 1049 | | Group | | /3.3.2.5 | 1050 | 31 | Opaque link | 1097 | [RFC7752] | 1051 | | attributes | | /3.3.2.6 | 1052 | 32 | Link Name attribute | 1098 | [RFC7752] | 1053 | | | | /3.3.2.7 | 1054 | 33 | Unidirectional | 22/33 | [RFC7810]/4.1 | 1055 | | Link Delay | | | 1056 | 34 | Min/Max | 22/34 | [RFC7810]/4.2 | 1057 | | Unidirectional Link | | | 1058 | | Delay | | | 1059 | 35 | Unidirectional | 22/35 | [RFC7810]/4.3 | 1060 | | Delay Variation | | | 1061 | 36 | Unidirectional | 22/36 | [RFC7810]/4.4 | 1062 | | Link Loss | | | 1063 | 37 | Unidirectional | 22/37 | [RFC7810]/4.5 | 1064 | | Residual Bandwidth | | | 1065 | 38 | Unidirectional | 22/38 | [RFC7810]/4.6 | 1066 | | Available Bandwidth | | | 1067 | 39 | Unidirectional | 22/39 | [RFC7810]/4.7 | 1068 | | Bandwidth | | | 1069 | | Utilization | | | 1070 | 40 | Extended Admin | 22/14 | [RFC7308]/2.1 | 1071 | | Group (EAG) | | | 1072 +-----------+---------------------+--------------+------------------+ 1074 9.2.9.3. Prefix Attributes TLV 1076 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 1077 IPv6. Prefixes are learned from the IGP (IS-IS or OSPF) or BGP 1078 topology with a set of IGP attributes (such as metric, route tags, 1079 etc.). This section describes the different attributes related to 1080 the IPv4/IPv6 prefixes. Prefix Attributes TLVs SHOULD be encoded in 1081 the LS Prefix Object. 1083 0 1 2 3 1084 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 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | Type=[TBD14] | Length | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | | 1089 // Prefix Attributes Sub-TLVs (variable) // 1090 | | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 The following 'Prefix Attribute' sub-TLVs are valid : 1095 +-----------+---------------------+--------------+------------------+ 1096 | Sub-TLV | Description | BGP-LS TLV | Defined in: | 1097 +-----------+---------------------+--------------+------------------+ 1098 | 41 | IGP Flags | 1152 | [RFC7752] | 1099 | | | | /3.3.3.1 | 1100 | 42 | Route Tag | 1153 | [RFC7752] | 1101 | | | | /3.3.3.2 | 1102 | 43 | Extended Tag | 1154 | [RFC7752] | 1103 | | | | /3.3.3.3 | 1104 | 44 | Prefix Metric | 1155 | [RFC7752] | 1105 | | | | /3.3.3.4 | 1106 | 45 | OSPF Forwarding | 1156 | [RFC7752] | 1107 | | Address | | /3.3.3.5 | 1108 | 46 | Opaque Prefix | 1157 | [RFC7752] | 1109 | | Attribute | | /3.3.3.6 | 1110 +-----------+---------------------+--------------+------------------+ 1112 9.2.10. Removal of an Attribute 1114 One of a key objective of PCEP-LS is to encode and carry only the 1115 impacted attributes of a Node, a Link or a Prefix. To accommodate 1116 this requirement, incase of a removal of an attribute, the sub-TLV 1117 MUST be included with no 'value' field and length=0 to indicate that 1118 the attribute is removed. On receiving a sub-TLV with zero length, 1119 the receiver removes the attribute from the database. 1121 10. Other Considerations 1123 10.1. Inter-AS Links 1125 The main source of LS (and TE) information is the IGP, which is not 1126 active on inter-AS links. In some cases, the IGP may have 1127 information of inter-AS links ([RFC5392], [RFC5316]). In other 1128 cases, an implementation SHOULD provide a means to inject inter-AS 1129 links into PCEP. The exact mechanism used to provision the inter-AS 1130 links is outside the scope of this document. 1132 11. Processing Rules 1134 12. Security Considerations 1136 This document extends PCEP for LS (and TE) distribution including a 1137 new LSRpt message with new object and TLVs. Procedures and protocol 1138 extensions defined in this document do not effect the overall PCEP 1139 security model. See [RFC5440], [I-D.ietf-pce-pceps]. Tampering with 1140 the LSRpt message may have an effect on path computations at PCE. It 1141 also provides adversaries an opportunity to eavesdrop and learn 1142 sensitive information and plan sophisticated attacks on the network 1143 infrastructure. The PCE implementation SHOULD provide mechanisms to 1144 prevent strains created by network flaps and amount of LS (and TE) 1145 information. Thus it is suggested that any mechanism used for 1146 securing the transmission of other PCEP message be applied here as 1147 well. As a general precaution, it is RECOMMENDED that these PCEP 1148 extensions only be activated on authenticated and encrypted sessions 1149 belonging to the same administrative authority. 1151 13. Manageability Considerations 1153 13.1. Control of Function and Policy 1155 TBD. 1157 13.2. Information and Data Models 1159 TBD. 1161 13.3. Liveness Detection and Monitoring 1163 TBD. 1165 13.4. Verify Correct Operations 1167 TBD. 1169 13.5. Requirements On Other Protocols 1171 TBD. 1173 13.6. Impact On Network Operations 1175 TBD. 1177 14. IANA Considerations 1179 This document requests IANA actions to allocate code points for the 1180 protocol elements defined in this document. 1182 14.1. PCEP Messages 1184 IANA created a registry for PCEP messages. Each PCEP message has a 1185 message type value. This document defines a new PCEP message value. 1187 Value Meaning Reference 1188 TBD3 LSRpt [This I-D] 1190 14.2. PCEP Objects 1192 This document defines the following new PCEP Object-classes and 1193 Object-values: 1195 Object-Class Value Name Reference 1196 TBD6 LS Object [This I-D] 1197 Object-Type=1 1198 (LS Node) 1199 Object-Type=2 1200 (LS Link) 1201 Object-Type=3 1202 (LS IPv4 Prefix) 1203 Object-Type=4 1204 (LS IPv6 Prefix) 1206 14.3. LS Object 1208 This document requests that a new sub-registry, named "LS Object 1209 Protocol-ID Field", is created within the "Path Computation Element 1210 Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP 1211 object. New values are to be assigned by Standards Action [RFC5226]. 1213 Value Meaning Reference 1214 1 IS-IS Level 1 [This I-D] 1215 2 IS-IS Level 2 [This I-D] 1216 3 OSPFv2 [This I-D] 1217 4 Direct [This I-D] 1218 5 Static configuration [This I-D] 1219 6 OSPFv3 [This I-D] 1220 7 BGP-LS [This I-D] 1221 8 Abstraction [This I-D] 1223 Further, this document also requests that a new sub-registry, named 1224 "LS Object Flag Field", is created within the "Path Computation 1225 Element Protocol (PCEP) Numbers" registry to manage the Flag field of 1226 the LSP object.New values are to be assigned by Standards Action 1227 [RFC5226]. Each bit should be tracked with the following qualities: 1229 o Bit number (counting from bit 0 as the most significant bit) 1231 o Capability description 1233 o Defining RFC 1235 The following values are defined in this document: 1237 Bit Description Reference 1238 0-21 Unassigned 1239 22 R (Remove bit) [This I-D] 1240 23 S (Sync bit) [This I-D] 1242 14.4. PCEP-Error Object 1244 IANA is requested to make the following allocation in the "PCEP-ERROR 1245 Object Error Types and Values" registry. 1247 Error-Type Meaning Reference 1248 6 Mandatory Object missing [RFC5440] 1249 Error-Value=TBD4 [This I-D] 1250 (LS object missing) 1252 19 Invalid Operation [I-D.ietf-pce-stateful-pce] 1253 Error-Value=TBD1 [This I-D] 1254 (Attempted LS Report if LS 1255 remote capability was not 1256 advertised) 1258 TBD2 LS Synchronization Error [This I-D] 1259 Error-Value=1 1260 (An error in processing the 1261 LSRpt) 1262 Error-Value=2 1263 (An internal PCC error) 1265 14.5. PCEP TLV Type Indicators 1267 This document defines the following new PCEP TLVs. 1269 Value Meaning Reference 1270 TBD5 LS-CAPABILITY TLV [This I-D] 1271 TBD7 ROUTING-UNIVERSE TLV [This I-D] 1272 TBD15 ROUTE-DISTINGUISHER TLV [This I-D] 1273 TBD8 Local Node Descriptors TLV [This I-D] 1274 TBD9 Remote Node Descriptors TLV [This I-D] 1275 TBD10 Link Descriptors TLV [This I-D] 1276 TBD11 Prefix Descriptors TLV [This I-D] 1277 TBD12 Node Attributes TLV [This I-D] 1278 TBD13 Link Attributes TLV [This I-D] 1279 TBD14 Prefix Attributes TLV [This I-D] 1281 14.6. PCEP-LS Sub-TLV Type Indicators 1283 This document specifies the PCEP-LS Sub-TLVs. IANA is requested to 1284 create an "PCEP-LS Sub-TLV Types" sub-registry in the "PCEP TLV Type 1285 Indicators" for the sub-TLVs carried in the PCEP-LS TLV (Local and 1286 Remote Node Descriptors TLV, Link Descriptors TLV, Prefix Descriptors 1287 TLV, Node Attributes TLV, Link Attributes TLV and Prefix Attributes 1288 TLV. This document defines the following types: 1290 +-----------+---------------------+---------------+-----------------+ 1291 | Sub-TLV | Description | Ref | Value defined | 1292 | | | Sub-TLV | in: | 1293 +-----------+---------------------+---------------+-----------------+ 1294 | 1 | Autonomous System | 512 | [RFC7752] | 1295 | | | | /3.2.1.4 | 1296 | 2 | BGP-LS Identifier | 513 | [RFC7752] | 1297 | | | | /3.2.1.4 | 1298 | 3 | OSPF Area-ID | 514 | [RFC7752] | 1299 | | | | /3.2.1.4 | 1300 | 4 | Router-ID | 515 | [RFC7752] | 1301 | | | | /3.2.1.4 | 1302 | 5 | Multi-Topology-ID | 263 | [RFC7752] | 1303 | | | | /3.2.1.5 | 1304 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1305 | | Identifiers | | | 1306 | 7 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1307 | | address | | | 1308 | 8 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1309 | | address | | | 1310 | 9 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1311 | | address | | | 1312 | 10 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1313 | | address | | | 1314 | 11 | OSPF Route Type | 264 | [RFC7752] | 1315 | | | | /3.2.3.1 | 1316 | 12 | IP Reachability | 265 | [RFC7752] | 1317 | | Information | | /3.2.3.2 | 1318 | 13 | Node Flag Bits | 1024 | [RFC7752] | 1319 | | | | /3.3.1.1 | 1320 | 14 | Opaque Node | 1025 | [RFC7752] | 1321 | | Properties | | /3.3.1.5 | 1322 | 15 | Node Name | 1026 | [RFC7752] | 1323 | | | | /3.3.1.3 | 1324 | 16 | IS-IS Area | 1027 | [RFC7752] | 1325 | | Identifier | | /3.3.1.2 | 1326 | 17 | IPv4 Router-ID of | 134/-- | [RFC5305]/4.3 | 1327 | | Local Node | | | 1328 | 18 | IPv6 Router-ID of | 140/-- | [RFC6119]/4.1 | 1329 | | Local Node | | | 1330 | 19 | IPv4 Router-ID of | 134/-- | [RFC5305]/4.3 | 1331 | | Remote Node | | | 1332 | 20 | IPv6 Router-ID of | 140/-- | [RFC6119]/4.1 | 1333 | | Remote Node | | | 1334 | 22 | Administrative | 22/3 | [RFC5305]/3.1 | 1335 | | group (color) | | | 1336 | 23 | Maximum link | 22/9 | [RFC5305]/3.3 | 1337 | | bandwidth | | | 1338 | 24 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1339 | | link bandwidth | | | 1340 | 25 | Unreserved | 22/11 | [RFC5305]/3.6 | 1341 | | bandwidth | | | 1342 | 26 | TE Default Metric | 22/18 | [RFC7752] | 1343 | | | | /3.3.2.3 | 1344 | 27 | Link Protection | 22/20 | [RFC5307]/1.2 | 1345 | | Type | | | 1346 | 28 | MPLS Protocol Mask | 1094 | [RFC7752] | 1347 | | | | /3.3.2.2 | 1348 | 29 | IGP Metric | 1095 | [RFC7752] | 1349 | | | | /3.3.2.4 | 1350 | 30 | Shared Risk Link | 1096 | [RFC7752] | 1351 | | Group | | /3.3.2.5 | 1352 | 31 | Opaque link | 1097 | [RFC7752] | 1353 | | attributes | | /3.3.2.6 | 1354 | 32 | Link Name attribute | 1098 | [RFC7752] | 1355 | | | | /3.3.2.7 | 1356 | 33 | Unidirectional | 22/33 | [RFC7810]/4.1 | 1357 | | Link Delay | | | 1358 | 34 | Min/Max | 22/34 | [RFC7810]/4.2 | 1359 | | Unidirectional Link | | | 1360 | | Delay | | | 1361 | 35 | Unidirectional | 22/35 | [RFC7810]/4.3 | 1362 | | Delay Variation | | | 1363 | 36 | Unidirectional | 22/36 | [RFC7810]/4.4 | 1364 | | Link Loss | | | 1365 | 37 | Unidirectional | 22/37 | [RFC7810]/4.5 | 1366 | | Residual Bandwidth | | | 1367 | 38 | Unidirectional | 22/38 | [RFC7810]/4.6 | 1368 | | Available Bandwidth | | | 1369 | 39 | Unidirectional | 22/39 | [RFC7810]/4.7 | 1370 | | Bandwidth | | | 1371 | | Utilization | | | 1372 | 40 | Extended Admin | 22/14 | [RFC7308]/2.1 | 1373 | | Group (EAG) | | | 1374 | 41 | IGP Flags | 1152 | [RFC7752] | 1375 | | | | /3.3.3.1 | 1376 | 42 | Route Tag | 1153 | [RFC7752] | 1377 | | | | /3.3.3.2 | 1378 | 43 | Extended Tag | 1154 | [RFC7752] | 1379 | | | | /3.3.3.3 | 1380 | 44 | Prefix Metric | 1155 | [RFC7752] | 1381 | | | | /3.3.3.4 | 1382 | 45 | OSPF Forwarding | 1156 | [RFC7752] | 1383 | | Address | | /3.3.3.5 | 1384 | 46 | Opaque Prefix | 1157 | [RFC7752] | 1385 | | Attribute | | /3.3.3.6 | 1386 +-----------+---------------------+---------------+-----------------+ 1387 New values are to be assigned by Standards Action [RFC5226]. 1389 15. TLV/Sub-TLV Code Points Summary 1391 This section contains the global table of all TLVs/Sub-TLVs in LS 1392 object defined in this document. 1394 +-----------+---------------------+---------------+-----------------+ 1395 | TLV | Description | Ref TLV | Value defined | 1396 | | | | in: | 1397 +-----------+---------------------+---------------+-----------------+ 1398 | TBD7 | Routing Universe | -- | Sec 9.2.1 | 1399 | TBD15 | Route | -- | Sec 9.2.2 | 1400 | | Distinguisher | | | 1401 | * | Virtual Network | -- | [leedhody-pce- | 1402 | | | | vn-association] | 1403 | TBD8 | Local Node | 256 | [RFC7752] | 1404 | | Descriptors | | /3.2.1.2 | 1405 | TBD9 | Remote Node | 257 | [RFC7752] | 1406 | | Descriptors | | /3.2.1.3 | 1407 | TBD10 | Link Descriptors | -- | Sec 9.2.8 | 1408 | TBD11 | Prefix Descriptors | -- | Sec 9.2.9 | 1409 | TBD12 | Node Attributes | -- | Sec 9.2.10.1 | 1410 | TBD13 | Link Attributes | -- | Sec 9.2.10.2 | 1411 | TBD14 | Prefix Attributes | -- | Sec 9.2.10.3 | 1412 +-----------+---------------------+---------------+-----------------+ 1414 * this TLV is defined in a different PCEP document 1416 TLV Table 1418 Refer Section 14.6 for the table of Sub-TLVs. 1420 16. Acknowledgments 1422 This document borrows some of the structure and text from the 1423 [RFC7752]. 1425 Thanks to Eric Wu, Venugopal Kondreddy, Mahendra Singh Negi, 1426 Avantika, and Zhengbin Li for the reviews. 1428 17. References 1430 17.1. Normative References 1432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1433 Requirement Levels", BCP 14, RFC 2119, 1434 DOI 10.17487/RFC2119, March 1997, 1435 . 1437 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1438 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1439 2008, . 1441 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1442 in Support of Generalized Multi-Protocol Label Switching 1443 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1444 . 1446 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1447 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1448 DOI 10.17487/RFC5440, March 2009, 1449 . 1451 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1452 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 1453 February 2011, . 1455 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1456 S. Ray, "North-Bound Distribution of Link-State and 1457 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1458 DOI 10.17487/RFC7752, March 2016, 1459 . 1461 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1462 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1463 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1464 . 1466 17.2. Informative References 1468 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1469 (TE) Extensions to OSPF Version 2", RFC 3630, 1470 DOI 10.17487/RFC3630, September 2003, 1471 . 1473 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1474 Support of Generalized Multi-Protocol Label Switching 1475 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1476 . 1478 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1479 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1480 2006, . 1482 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1483 Element (PCE)-Based Architecture", RFC 4655, 1484 DOI 10.17487/RFC4655, August 2006, 1485 . 1487 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1488 Topology (MT) Routing in Intermediate System to 1489 Intermediate Systems (IS-ISs)", RFC 5120, 1490 DOI 10.17487/RFC5120, February 2008, 1491 . 1493 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1494 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1495 DOI 10.17487/RFC5226, May 2008, 1496 . 1498 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1499 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1500 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1501 December 2008, . 1503 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1504 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1505 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 1506 January 2009, . 1508 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1509 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1510 March 2012, . 1512 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1513 Path Computation Element Architecture to the Determination 1514 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1515 DOI 10.17487/RFC6805, November 2012, 1516 . 1518 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 1519 Ward, "IS-IS Multi-Instance", RFC 6822, 1520 DOI 10.17487/RFC6822, December 2012, 1521 . 1523 [I-D.ietf-pce-stateful-pce] 1524 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1525 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1526 pce-16 (work in progress), September 2016. 1528 [I-D.ietf-pce-pce-initiated-lsp] 1529 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1530 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1531 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 1532 progress), July 2016. 1534 [I-D.ietf-pce-pceps] 1535 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1536 Transport for PCEP", draft-ietf-pce-pceps-10 (work in 1537 progress), July 2016. 1539 [I-D.kondreddy-pce-pcep-ls-sync-optimizations] 1540 Kondreddy, V. and M. Negi, "Optimizations of PCEP Link- 1541 State(LS) Synchronization Procedures", draft-kondreddy- 1542 pce-pcep-ls-sync-optimizations-00 (work in progress), 1543 October 2015. 1545 [I-D.leedhody-teas-pcep-ls] 1546 Lee, Y., Dhody, D., and D. Ceccarelli, "Architecture and 1547 Requirement for Distribution of Link-State and TE 1548 Information via PCEP.", draft-leedhody-teas-pcep-ls-02 1549 (work in progress), March 2016. 1551 [I-D.ietf-teas-actn-framework] 1552 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 1553 Control of Traffic Engineered Networks", draft-ietf-teas- 1554 actn-framework-00 (work in progress), July 2016. 1556 [I-D.ietf-teas-actn-requirements] 1557 Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D. 1558 Ceccarelli, "Requirements for Abstraction and Control of 1559 TE Networks", draft-ietf-teas-actn-requirements-03 (work 1560 in progress), July 2016. 1562 [I-D.leedhody-pce-vn-association] 1563 Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions 1564 for Establishing Relationships Between Sets of LSPs and 1565 Virtual Networks", draft-leedhody-pce-vn-association-00 1566 (work in progress), February 2016. 1568 [I-D.dhody-pce-applicability-actn] 1569 Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 1570 Path Computation Element (PCE) for Abstraction and Control 1571 of TE Networks (ACTN)", draft-dhody-pce-applicability- 1572 actn-00 (work in progress), July 2016. 1574 Appendix A. Relevant OSPF TLV and sub-TLV 1576 This section list the relevant TLVs and sub-TLVs defined for OSPF. 1578 +-----------+---------------------+---------------+-----------------+ 1579 | Sub-TLV | Description | OSPF-TE | Value defined | 1580 | | | Sub-TLV | in: | 1581 +-----------+---------------------+---------------+-----------------+ 1582 | 6 | Link Local/Remote | 11 | [RFC4203]/1.1 | 1583 | | Identifiers | | | 1584 | 7 | IPv4 interface | 3 | [RFC3630]/2.5.3 | 1585 | | address | | | 1586 | 8 | IPv4 neighbor | 4 | [RFC3630]/2.5.4 | 1587 | | address | | | 1588 | 9 | IPv6 interface | 19 | [RFC5329]/4.3 | 1589 | | address | | | 1590 | 10 | IPv6 neighbor | 20 | [RFC5329]/4.4 | 1591 | | address | | | 1592 | 17 | IPv4 Router-ID of | 1 | [RFC3630]/2.4.1 | 1593 | | Local Node | | | 1594 | 18 | IPv6 Router-ID of | 3 | [RFC5329]/3 | 1595 | | Local Node | | | 1596 | 19 | IPv4 Router-ID of | 1 | [RFC3630]/2.4.1 | 1597 | | Remote Node | | | 1598 | 20 | IPv6 Router-ID of | 3 | [RFC5329]/3 | 1599 | | Remote Node | | | 1600 | 22 | Administrative | 9 | [RFC3630]/2.5.9 | 1601 | | group (color) | | | 1602 | 23 | Maximum link | 6 | [RFC3630]/2.5.6 | 1603 | | bandwidth | | | 1604 | 24 | Max. reservable | 7 | [RFC3630]/2.5.7 | 1605 | | link bandwidth | | | 1606 | 25 | Unreserved | 8 | [RFC3630]/2.5.8 | 1607 | | bandwidth | | | 1608 | 27 | Link Protection | 14 | [RFC4203]/1.2 | 1609 | | Type | | | 1610 | 30 | Shared Risk Link | 16 | [RFC4203]/1.3 | 1611 | | Group | | | 1612 | 33 | Unidirectional | 27 | [RFC7471]/4.1 | 1613 | | Link Delay | | | 1614 | 34 | Min/Max | 28 | [RFC7471]/4.2 | 1615 | | Unidirectional Link | | | 1616 | | Delay | | | 1617 | 35 | Unidirectional | 29 | [RFC7471]/4.3 | 1618 | | Delay Variation | | | 1619 | 36 | Unidirectional | 30 | [RFC7471]/4.4 | 1620 | | Link Loss | | | 1621 | 37 | Unidirectional | 31 | [RFC7471]/4.5 | 1622 | | Residual Bandwidth | | | 1623 | 38 | Unidirectional | 32 | [RFC7471]/4.6 | 1624 | | Available Bandwidth | | | 1625 | 39 | Unidirectional | 33 | [RFC7471]/4.7 | 1626 | | Bandwidth | | | 1627 | | Utilization | | | 1628 | 40 | Extended Admin | 26 | [RFC7308]/2.1 | 1629 | | Group (EAG) | | | 1630 +-----------+---------------------+---------------+-----------------+ 1632 Appendix B. Examples 1634 These examples are for illustration purposes only to show how the new 1635 PCEP-LS message could be encoded. They are not meant to be an 1636 exhaustive list of all possible use cases and combinations. 1638 B.1. All Nodes 1640 Each node (PCC) in the network chooses to provide its own local node 1641 and link information, and in this way PCE can build the full link 1642 state and TE information. 1644 +--------------------+ +--------------------+ 1645 | | | | 1646 | RTA |10.1.1.1 | RTB | 1647 | 1.1.1.1 |--------------------| 2.2.2.2 | 1648 | Area 0 | 10.1.1.2| Area 0 | 1649 | | | | 1650 +--------------------+ +--------------------+ 1651 RTA 1652 --- 1653 LS Node 1654 TLV - Local Node Descriptors 1655 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1656 Sub-TLV - 4: Router-ID: 1.1.1.1 1657 TLV - Node Attributes TLV 1658 Sub-TLV(s) 1660 LS Link 1661 TLV - Local Node Descriptors 1662 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1663 Sub-TLV - 4: Router-ID: 1.1.1.1 1664 TLV - Remote Node Descriptors 1665 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1666 Sub-TLV - 4: Router-ID: 2.2.2.2 1667 TLV - Link Descriptors 1668 Sub-TLV - 7: IPv4 interface: 10.1.1.1 1669 Sub-TLV - 8: IPv4 neighbor: 10.1.1.2 1670 TLV - Link Attributes TLV 1671 Sub-TLV(s) 1673 RTB 1674 --- 1675 LS Node 1676 TLV - Local Node Descriptors 1677 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1678 Sub-TLV - 4: Router-ID: 2.2.2.2 1679 TLV - Node Attributes TLV 1680 Sub-TLV(s) 1682 LS Link 1683 TLV - Local Node Descriptors 1684 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1685 Sub-TLV - 4: Router-ID: 2.2.2.2 1686 TLV - Remote Node Descriptors 1687 Sub-TLV - 3: OSPF Area-ID: 0.0.0.0 1688 Sub-TLV - 4: Router-ID: 1.1.1.1 1689 TLV - Link Descriptors 1690 Sub-TLV - 7: IPv4 interface: 10.1.1.2 1691 Sub-TLV - 8: IPv4 neighbor: 10.1.1.1 1692 TLV - Link Attributes TLV 1693 Sub-TLV(s) 1695 B.2. Designated Node 1697 A designated node(s) in the network will provide its own local node 1698 as well as all learned remote information, and in this way PCE can 1699 build the full link state and TE information. 1701 As described in Appendix B.1, the same LS Node and Link objects will 1702 be generated with a differance that it would be a designated router 1703 say RTA that generate all this information. 1705 B.3. Between PCEs 1707 As per Hierarchical-PCE [RFC6805], Parent PCE builds an abstract 1708 domain topology map with each domain as an abstract node and inter- 1709 domain links as an abstract link. Each child PCE may provide this 1710 information to the parent PCE. Considering the example in figure 1 1711 of [RFC6805], following LS object will be generated: 1713 PCE1 1714 ---- 1715 LS Node 1716 TLV - Local Node Descriptors 1717 Sub-TLV - 1: Autonomous System: 100 (Domain 1) 1718 Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract) 1720 LS Link 1721 TLV - Local Node Descriptors 1722 Sub-TLV - 1: Autonomous System: 100 1723 Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract) 1724 TLV - Remote Node Descriptors 1725 Sub-TLV - 1: Autonomous System: 200 (Domain 2) 1726 Sub-TLV - 4: Router-ID: 22.22.22.22 (abstract) 1727 TLV - Link Descriptors 1728 Sub-TLV - 7: IPv4 interface: 11.1.1.1 1729 Sub-TLV - 8: IPv4 neighbor: 11.1.1.2 1730 TLV - Link Attributes TLV 1731 Sub-TLV(s) 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 1739 Sub-TLV - 4: Router-ID: 22.22.22.22 (abstract) 1740 TLV - Link Descriptors 1741 Sub-TLV - 7: IPv4 interface: 12.1.1.1 1742 Sub-TLV - 8: IPv4 neighbor: 12.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: 400 (Domain 4) 1752 Sub-TLV - 4: Router-ID: 44.44.44.44 (abstract) 1753 TLV - Link Descriptors 1754 Sub-TLV - 7: IPv4 interface: 13.1.1.1 1755 Sub-TLV - 8: IPv4 neighbor: 13.1.1.2 1756 TLV - Link Attributes TLV 1757 Sub-TLV(s) 1759 * similar information will be generated by other PCE 1760 to help form the abstract domain topology. 1762 Further the exact border nodes and abstract internal path between the 1763 border nodes may also be transported to the Parent PCE to enable ACTN 1764 as described in [I-D.dhody-pce-applicability-actn] using the similar 1765 LS node and link objects encodings. 1767 Appendix C. Contributor Addresses 1769 Udayasree Palle 1770 Huawei Technologies 1771 Divyashree Techno Park, Whitefield 1772 Bangalore, Karnataka 560066 1773 India 1775 EMail: udayasree.palle@huawei.com 1777 Sergio Belotti 1778 Alcatel-Lucent 1779 Italy 1781 EMail: sergio.belotti@alcatel-lucent.com 1783 Veerendranatha Reddy Vallem 1784 Huawei Technologies 1785 Divyashree Techno Park, Whitefield 1786 Bangalore, Karnataka 560066 1787 India 1789 Email: veerendranatharv@huawei.com 1791 Authors' Addresses 1793 Dhruv Dhody 1794 Huawei Technologies 1795 Divyashree Techno Park, Whitefield 1796 Bangalore, Karnataka 560066 1797 India 1799 EMail: dhruv.ietf@gmail.com 1801 Young Lee 1802 Huawei Technologies 1803 5340 Legacy Drive, Building 3 1804 Plano, TX 75023 1805 USA 1807 EMail: leeyoung@huawei.com 1808 Daniele Ceccarelli 1809 Ericsson 1810 Torshamnsgatan,48 1811 Stockholm 1812 Sweden 1814 EMail: daniele.ceccarelli@ericsson.com