idnits 2.17.1 draft-lee-pce-pcep-ls-optical-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 322 has weird spacing: '...ibution in op...' -- The document date (March 7, 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'BGP-LS' is mentioned on line 263, but not defined == Missing Reference: 'RFC7579' is mentioned on line 286, but not defined == Missing Reference: 'RFC7138' is mentioned on line 274, but not defined == Missing Reference: 'RFC7580' is mentioned on line 286, but not defined == Unused Reference: 'RFC5305' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC5307' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'S-PCE-GMPLS' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC7399' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC8231' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC8281' is defined on line 433, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Young Lee 2 Internet Draft Samsung 3 Intended Status: Experimental Haomian Zheng 4 Expires: September 2022 Huawei 5 Daniele Ceccarelli 6 Ericsson 7 Wei Wang 8 Beijing Univ. of Posts and Telecom 9 Peter Park 10 KT 11 Bin Young Yoon 12 ETRI 14 March 7, 2022 16 PCEP Extension for Distribution of Link-State and TE Information for 17 Optical Networks 19 draft-lee-pce-pcep-ls-optical-11 21 Abstract 23 In order to compute and provide optimal paths, Path Computation 24 Elements (PCEs) require an accurate and timely Traffic Engineering 25 Database (TED). Traditionally this Link State and TE information has 26 been obtained from a link state routing protocol (supporting traffic 27 engineering extensions). 29 An existing experimental document extends the Path Computation 30 Element Communication Protocol (PCEP) with Link-State and Traffic 31 Engineering (TE) Information. This document provides further 32 experimental extensions to collect Link-State and TE information for 33 optical networks. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with 38 the provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 This Internet-Draft will expire on September 7, 2022. 58 Copyright Notice 60 Copyright (c) 2022 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with 68 respect to this document. Code Components extracted from this 69 document must include Simplified BSD License text as described in 70 Section 4.e of the Trust Legal Provisions and are provided without 71 warranty as described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction ................................................ 3 76 1.1. Requirements Language .................................. 3 77 2. Applicability ............................................... 3 78 3. Requirements for PCEP Extension ............................. 4 79 3.1. Reachable Source-Destination ........................... 5 80 3.2. Optical Latency......................................... 5 81 4. PCEP-LS Extensions for Optical Networks ..................... 6 82 4.1. Node Attributes TLV .................................... 6 83 4.2. Link Attributes TLV .................................... 6 84 4.3. PCEP-LS for Optical Network Extension .................. 7 85 5. Security Considerations ..................................... 8 86 6. IANA Considerations ......................................... 8 87 6.1. PCEP-LS Sub-TLV Type Indicators ........................ 8 88 7. References .................................................. 9 89 7.1. Normative References ................................... 9 90 7.2. Informative References ................................. 9 92 Appendix A. Contributor's Address ............................ 11 93 Authors' Addresses ............................................ 11 95 1. Introduction 97 [PCEP-LS] describes an experimental mechanism by which Link State 98 (LS) and Traffic Engineering (TE) information can be collected from 99 packet networks and shared through the Path Computation Element 100 Communication Protocol (PCEP) with a Path Computation Element (PCE). 101 This approach is called PCEP-LS and uses a new PCEP message format. 103 Problems in the optical networks, such as Optical Transport Networks 104 (OTN), is becoming worse due to the growth of the network 105 scalability. Such growths are also challenging the requirement of 106 memory/storage on each equipment. The introduction of a PCEP-based 107 LS helps solving the problem, with equally capability and 108 functionalities. 110 This document describes an experimental extension to PCEP-LS for use 111 in optical networks, and explains how encodings defined in [PCEP-LS] 112 can be used in the optical network contexts. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 2. Applicability 124 There are three main applicabilities of the mechanism described in 125 this document: 127 - Case 1: There is IGP running in optical network but there is a 128 need to collect LS and TE resource information at a PCE from 129 individual or specific optical nodes more frequently of more 130 rapidly than the IGP allows. 132 o A PCE may receive full information or an incremental 133 update (as opposed to the entire TE information of the 134 node/link). 136 - Case 2: There is no IGP running in the optical network and 137 there is a need to collect link-state and TE resource 138 information from the optical nodes for use by the PCE. 140 - Case 3: There is a need to share abstract optical link-state 141 and TE information from child PCE to a parent PCE in a 142 hierarchical PCE (H-PCE) system per [RFC6805] and [RFC8751]. 143 Alternatively, this requirement may exist between a Physical 144 Network Controller (PNC) and a Multi-Domain Service 145 Coordinator (MDSC) in the Abstraction and Control of TE 146 Networks (ACTN) architecture [RFC8453]. 148 Note: The applicability for Case 3 may arise as a consequence 149 of Case 1 and Case 2. When TE information changes occur in the 150 optical network, this may also affect abstracted TE 151 information and thus needs to be updated to the parent 152 PCE/MSDC from each child PCE/PNC. 154 3. Requirements for PCEP Extension 156 The key requirements associated with link-state and TE information 157 distribution are identified for PCEP and listed in Section 4 of 158 [PCEP-LS]. These new functions introduced to PCEP to support 159 distribution of link-state (and TE) information are described in 160 Section 5 of [PCEP-LS]. Details of PCEP messages and related 161 Objects/TLVs are specified in Sections 8 and 9 of [PCEP-LS]. The key 162 requirements and new functions specified in [PCEP-LS] are equally 163 applicable to optical networks. 165 Besides the generic requirements specified in [PCEP-LS], optical 166 specific features also need to be considered. As a connection-based 167 network, there are specific parameters such as reachability table, 168 optical latency, wavelength consistency, and some other parameters 169 that need to be included during the topology collection. Without 170 these restrictions, the path computation may be inaccurate or 171 infeasible for deployment, therefore these information MUST be 172 included in the PCEP. 174 The procedure for using the optical parameters is described in 175 following sections. 177 3.1. Reachable Source-Destination 179 The reachable source-destination node pair indicates that there are 180 some OCh paths between two nodes. The reachability is restricted by 181 impairment, wavelength consistency and so on. This information is 182 necessary at the PCE to ensure that the path computed between source 183 node and destination node is feasible. In this scenario, the PCE is 184 responsible for computing how many OCh paths are available to set up 185 connections between source and destination node. Moreover, if a set 186 of optical wavelengths is indicated in the path computation request, 187 the PCE also determines whether a wavelength from the set of 188 preselected optical wavelengths is available for the source- 189 destination pair connection. 191 To enable the PCE to complete the above functions, the reachable 192 relationship and OMS link information need to be reported to the 193 PCE. Once the PCE detects that any wavelength is available, the 194 corresponding OMS link is marked as a candidate link in the optical 195 network, which can then be used for path computation in the future. 197 Moreover, in a hierarchical PCE architecture, the information above 198 needs to be reported from child PCE to parent PCE, which acts as a 199 service coordinator. 201 3.2. Optical Latency 203 It is the usual case that the PCC indicates the latency when 204 requesting the path computation. In optical networks the latency is 205 a very sensitive parameter and there is stricter requirement on 206 latency. Given the number of OCh paths between source-destination 207 nodes, the PCE also need to determine how many OCh path satisfy the 208 indicated latency threshold. 210 There is usually an algorithm running on the PCE to guarantee the 211 performance of the computed path. During the computation, the delay 212 factor may be converted into a kind of link weight. After the 213 algorithm provides the candidate paths between the source and 214 destination nodes, the PCE selects the best path by computing the 215 total path propagation delay. 217 Optical PCEs contain optimization algorithms, e.g., shortest path 218 algorithm, to select the best-performing path. 220 4. PCEP-LS Extensions for Optical Networks 222 This section provides the additional PCEP-LS extensions necessary to 223 support optical networks. All Objects/TLVs defined in [PCEP-LS] are 224 applicable to optical networks. 226 4.1. Node Attributes TLV 228 The Node-Attributed TLV is defined in Section 9.3.9.1 of [PCEP-LS]. 229 This TLV is applicable for LS Node Object-Type as defined in [PCEP- 230 LS]. 232 This TLV contains a number of Sub-TLVs. [PCEP-LS] defines that any 233 Node-Attribute defined for BGP-LS [BGP-LS] can be used as a Sub-TLV 234 of the PCEP Node-Attribute TLV. BGP-LS does not support optical 235 networks, so the Node-Attribute Sub-TLVs shown below are defined in 236 this document for use in PCEP-LS for optical networks. 238 TBD1 The Connectivity Matrix Sub-TLV is used as defined in 239 [RFC7579]. 241 TBD2 The Resource Block Information Sub-TLV is used as defined in 242 [RFC7688]. 244 TBD3 The Resource Block Accessibility Sub-TLV is used as defined in 245 [RFC7688]. 247 TBD4 The Resource Block Wavelength Constraint Sub-TLV is used as 248 defined in [RFC7688]. 250 TBD5 The Resource Block Pool State Sub-TLV is used as defined in 251 [RFC7688]. 253 TBD6 The Resource Block Shared Access Wavelength Availability 254 Sub-TLV is used as defined in [RFC7688]. 256 4.2. Link Attributes TLV 258 The Link-Attributes TLV is defined in Section 9.3.9.2 of [PCEP-LS]. 259 This TLV is applicable for the LS Link Object-Type as defined in 260 [PCEP-LS]. 262 This TLV contains a number of Sub-TLVs. [PCEP-LS] defines that any 263 Node-Attribute defined for BGP-LS [BGP-LS] can be used as a Sub-TLV 264 of the PCEP Link-Attribute TLV. BGP-LS does not support optical 265 networks, so the Link-Attribute Sub-TLVs shown below are defined in 266 this document for use in PCEP-LS for optical networks. 268 TBD7 The ISCD Sub-TLV is used to describe the Interface Switching 269 Capability Descriptor as defined in [RFC4203]. 271 TBD8 The OTN-TDM SCSI Sub-TLV is used to describe the Optical 272 Transport Network Time Division Multiplexing Switching 273 Capability Specific Information as defined in [RFC4203] and 274 [RFC7138]. 276 TBD9 The WSON-LSC SCSI Sub-TLV is used to describe the Wavelength 277 Switched Optical Network Lambda Switch Capable Switching 278 Capability Specific Information as defined in [RFC4203] and 279 [RFC7688]. 281 TBD10 The Flexi-grid SCSI Sub-TLV is used to describe the Flexi-grid 282 Switching Capability Specific Information as defined in 283 [RFC8363]. 285 TBD11 The Port Label Restriction Sub-TLV is used as defined in 286 [RFC7579], [RFC7580], and [RFC8363]. 288 4.3. PCEP-LS for Optical Network Extension 290 This section provides additional PCEP-LS extension necessary to 291 support the optical network parameters discussed in Sections 3.1 and 292 3.2. 294 Collection of link state and TE information is necessary before the 295 path computation processing can be done. The procedure can be 296 divided into: 1) link state collection by receiving the 297 corresponding topology information in periodically; 2) path 298 computation on the PCE, triggered by receiving a path computation 299 request message from a PCC, and completed by transmitting a path 300 computation reply with the path computation result, per [RFC4655]. 302 For OTN networks, maximum bandwidth available may be per ODU 0/1/2/3 303 switching level or aggregated across all ODU switching levels (i.e., 304 ODUj/k). 306 For Wavelength Switched Optical Networks (WSON) , Routing and 307 Wavelength Assignment (RWA) information collected from Network 308 Elements (Nes) would be utilized to compute light paths. The list of 309 information collected can be found in [RFC7688]. More specifically, 310 the maximum bandwidth available may be per lambda/frequency level 311 (OCh) or aggregated across all lambda/frequency levels. Per OCh 312 level abstraction gives more detailed data to the P-PCE at the 313 expense of more information processing. Either the OCh-level or the 314 aggregated level abstraction in the RWA constraint (i.e., wavelength 315 continuity) needs to be taken into account by the PCE during path 316 computation. Resource Block Accessibility (i.e., wavelength 317 conversion information) in [RFC7688] needs to be taken into account 318 in order to guarantee the reliability of optical path computation. 320 5. Security Considerations 322 This document extends PCEP for LS (and TE) distribution in optical 323 networks by including a set of Sub-TLVs to be carried in existing 324 TLVs of existing messages. Procedures and protocol extensions 325 defined in this document do not affect the overall PCEP security 326 model (see [RFC5440] and [RFC8253]). The PCE implementation SHOULD 327 provide mechanisms to prevent strains created by network flaps and 328 amount of LS (and TE) information as defined in [PCEP-LS]. Thus, 329 any mechanism used for securing the transmission of other PCEP 330 message SHOULD be applied here as well. As a general precaution, it 331 is RECOMMENDED that these PCEP extensions only be activated on 332 authenticated and encrypted sessions belonging to the same 333 administrative authority. 335 6. IANA Considerations 337 This document requests IANA actions to allocate code points for the 338 protocol elements defined in this document. 340 6.1. PCEP-LS Sub-TLV Type Indicators 342 PCEP-LS] requests IANA to create a registry of "PCEP-LS Sub-TLV Type 343 Indicators". IANA is requested to make the following allocations 344 from this registry using the range 1 to 255. 346 +-----------+-------------------------------------------------- 347 | Sub-TLV | Meaning 348 +-----------+-------------------------------------------------- 349 | TBD1 | Connectivity Matrix 350 | TBD2 | Resource Block Information 351 | TBD3 | Resource Block Accessibility 352 | TBD4 | Resource Block Wavelength Constraint 353 | TBD5 | Resource Block Pool State 354 | TBD6 | Resource Block Shared Access Wavelength Available 355 | TBD7 | ISCD 356 | TBD8 | OTN-TDM SCSI 357 | TBD9 | WSON-LSC SCSI 358 | TBD10 | Flexi-grid SCSI 359 | TBD11 | Port Label Restriction 361 7. References 363 7.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 369 Engineering", RFC 5305, October 2008. 371 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 372 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 373 March 2009. 375 [RFC7688] Lee, Y., Ed., and G. Bernstein, Ed., "GMPLS OSPF 376 Enhancement for Signal and Network Element Compatibility 377 for Wavelength Switched Optical Networks", RFC 7688, 378 November 2015. 380 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 381 Key Words", RFC 8174, May 2017. 383 7.2. Informative References 385 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 386 (TE) Extensions to OSPF Version 2", RFC 3630, September 387 2003. 389 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 390 Support of Generalized Multi-Protocol Label Switching 391 (GMPLS)", RFC 4203, October 2005. 393 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 394 Element (PCE)-Based Architecture", RFC 4655, August 2006. 396 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 397 in Support of Generalized Multi-Protocol Label Switching 398 (GMPLS)", RFC 5307, October 2008. 400 [RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and 401 S.Ray, "North-Bound Distribution of Link-State and TE 402 information using BGP", RFC 7752, March 2016. 404 [S-PCE-GMPLS] X. Zhang, et. al, "Path Computation Element (PCE) 405 Protocol Extensions for Stateful PCE Usage in GMPLS- 406 controlled Networks", draft-ietf-pce-pcep-stateful-pce- 407 gmpls, work in progress. 409 [RFC7399] A. Farrel and D. king, "Unanswered Questions in the Path 410 Computation Element Architecture", RFC 7399, October 2015. 412 [RFC8453] D.Ceccarelli, and Y. Lee (Editors), "Framework for 413 Abstraction and Control of TE Networks", RFC453, August, 414 2018. 416 [RFC6805] A. Farrel and D. King, "The Application of the Path 417 Computation Element Architecture to the Determination of a 418 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 419 2012. 421 [PCEP-LS] D. Dhody, Y. Lee and D. Ceccarelli "PCEP Extension for 422 Distribution of Link-State and TE Information.", draft- 423 dhodylee-pce-pcep-ls, work in progress, July, 2020 425 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 426 Extensions for Stateful PCE", RFC8231, September 2017. 428 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., Dhody, D., 429 "PCEPS: Usage of TLS to Provide a Secure Transport for the 430 Path Computation Element Communication Protocol (PCEP)", 431 RFC8253, October 2017. 433 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 434 Extensions for PCE-initiated LSP Setup in a Stateful PCE 435 Model", RFC8281, December 2017. 437 [RFC8751] D. Dhody, Y. Lee and D. Ceccarelli, "Hierarchical Stateful 438 Path Computation Element (PCE)", RFC8751, March 2020. 440 [RFC8363] X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. 441 Ceccarelli, "GMPLS OSPF Extensions in support of Flexi- 442 grid DWDM networks", RFC8363, May 2018. 444 Appendix A. Contributor's Address 446 Dhruv Dhody 447 Huawei Technologies 448 Divyashree Techno Park, Whitefield 449 Bangalore, Karnataka 560066 450 India 451 Email: dhruv.ietf@gmail.com 453 Authors' Addresses 455 Young Lee 456 Samsung 457 Email: younglee.tx@gmail.com 459 Haomian Zheng 460 Huawei Technologies Co., Ltd. 461 Email: zhenghaomian@huawei.com 463 Daniele Ceccarelli 464 Ericsson 465 Torshamnsgatan,48 466 Stockholm 467 Sweden 468 EMail: daniele.ceccarelli@ericsson.com 470 Wei Wang 471 Beijing University of Posts and Telecom 472 No. 10, Xitucheng Rd. Haidian District, Beijing 100876, China 473 Email: weiw@bupt.edu.cn 475 Peter Park 476 KT 477 Email: peter.park@kt.com 479 Bin Yeong Yoon 480 ETRI 481 Email: byyun@etri.re.kr