idnits 2.17.1 draft-ietf-pce-wson-routing-wavelength-15.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 -- The document date (October 28, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Lee 2 Internet Draft Huawei 3 Intended status: Informational G. Bernstein 4 Expires: April 2015 Grotto Networking 5 Jonas Martensson 6 Acreo 7 T. Takeda 8 NTT 9 T. Tsuritani 10 KDDI 11 O. G. de Dios 12 Telefonica 14 October 28, 2014 16 PCEP Requirements for WSON Routing and Wavelength Assignment 18 draft-ietf-pce-wson-routing-wavelength-15.txt 20 Abstract 22 This memo provides application-specific requirements for the Path 23 Computation Element communication Protocol (PCEP) for the support of 24 Wavelength Switched Optical Networks (WSON). Lightpath provisioning 25 in WSONs requires a routing and wavelength assignment (RWA) process. 26 From a path computation perspective, wavelength assignment is the 27 process of determining which wavelength can be used on each hop of a 28 path and forms an additional routing constraint to optical light 29 path computation. Requirements for PCEP extensions in support of 30 optical impairments will be addressed in a separate document. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with 35 the provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other documents 44 at any time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on April 28, 2009. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described in 66 Section 4.e of the Trust Legal Provisions and are provided without 67 warranty as described in the Simplified BSD License. 69 Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 Table of Contents 77 1. Introduction...................................................3 78 2. WSON RWA Processes & Architecture..............................4 79 3. Requirements...................................................6 80 3.1. Path Computation Type Option..............................6 81 3.2. RWA Processing............................................6 82 3.3. Bulk RWA Path Request/Reply...............................7 83 3.4. RWA Path Re-optimization Request/Reply....................7 84 3.5. Wavelength Range Constraint...............................8 85 3.6. Wavelength Assignment Preference..........................8 86 3.7. Signal Processing Capability Restriction..................8 87 4. Manageability Considerations...................................9 88 4.1. Control of Function and Policy............................9 89 4.2. Information and Data Models, e.g. MIB module..............9 90 4.3. Liveness Detection and Monitoring........................10 91 4.4. Verifying Correct Operation..............................10 92 4.5. Requirements on Other Protocols and Functional Components10 93 4.6. Impact on Network Operation..............................10 94 5. Security Considerations.......................................10 95 6. IANA Considerations...........................................11 96 7. Acknowledgments...............................................11 97 8. References....................................................11 98 8.1. Normative References.....................................11 99 8.2. Informative References...................................11 100 Authors' Addresses...............................................12 101 Intellectual Property Statement..................................13 102 Disclaimer of Validity...........................................13 104 1. Introduction 106 [RFC4655] defines the PCE-based architecture and explains how a Path 107 Computation Element (PCE) may compute Label Switched Paths (LSP) in 108 Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and 109 Generalized MPLS (GMPLS)-controlled networks at the request of Path 110 Computation Clients (PCCs). A PCC is shown to be any network 111 component that makes such a request and may be for instance an 112 optical switching element within a Wavelength Division Multiplexing 113 (WDM) network. The PCE, itself, can be located anywhere within the 114 network, and may be within an optical switching element, a Network 115 Management System (NMS) or Operational Support System (OSS), or may 116 be an independent network server. 118 The PCE communication Protocol (PCEP) is the communication protocol 119 used between PCC and PCE, and may also be used between cooperating 120 PCEs. [RFC4657] sets out the common protocol requirements for PCEP. 121 Additional application-specific requirements for PCEP are deferred 122 to separate documents. 124 This document provides a set of application-specific PCEP 125 requirements for support of path computation in Wavelength Switched 126 Optical Networks (WSON). WSON refers to WDM-based optical networks 127 in which switching is performed selectively based on the wavelength 128 of an optical signal. 130 The path in WSON is referred to as a lightpath. A lightpath may span 131 multiple fiber links and the path should be assigned a wavelength 132 for each link. 134 A transparent optical network is made up of optical devices that can 135 switch but not convert from one wavelength to another. In a 136 transparent optical network, a lightpath operates on the same 137 wavelength across all fiber links that it traverses. In such case, 138 the lightpath is said to satisfy the wavelength-continuity 139 constraint. Two lightpaths that share a common fiber link cannot be 140 assigned the same wavelength. To do otherwise would result in both 141 signals interfering with each other. Note that advanced additional 142 multiplexing techniques such as polarization based multiplexing are 143 not addressed in this document since the physical layer aspects are 144 not currently standardized. Therefore, assigning the proper 145 wavelength on a lightpath is an essential requirement in the optical 146 path computation process. 148 When a switching node has the ability to perform wavelength 149 conversion the wavelength-continuity constraint can be relaxed, and 150 a lightpath may use different wavelengths on different links along 151 its path from origin to destination. It is, however, to be noted 152 that wavelength converters may be limited for cost reasons, while 153 the number of WDM channels that can be supported in a fiber is also 154 limited. As a WSON can be composed of network nodes that cannot 155 perform wavelength conversion, nodes with limited wavelength 156 conversion, and nodes with full wavelength conversion abilities, 157 wavelength assignment is an additional routing constraint to be 158 considered in all lightpath computations. 160 In this document we first review the processes for routing and 161 wavelength assignment (RWA) used when wavelength continuity 162 constraints are present and then specify requirements for PCEP to 163 support RWA. Requirements for optical impairments will be addressed 164 in a separate document. 166 The remainder of this document uses terminology from [RFC4655]. 168 2. WSON RWA Processes & Architecture 170 In [RFC6163] three alternative process architectures were given for 171 performing routing and wavelength assignment. These are shown 172 schematically in Figure 1. R stands for Routing, WA for Wavelength 173 Assignment, and DWA for Distributed Wavelength Assignment. 175 +-------------------+ 176 | +-------+ +--+ | +-------+ +--+ +-------+ +---+ 177 | | R | |WA| | | R |--->|WA| | R |--->|DWA| 178 | +-------+ +--+ | +-------+ +--+ +-------+ +---+ 179 | Combined | Separate Processes Separate Processes 180 | Processes | WA performed in a 181 +-------------------+ distributed manner 182 (a) (b) (b') 184 Figure 1. RWA process alternatives 186 These alternatives have the following properties and impact on PCEP 187 requirements in this document. 189 (a) Combined Processes (R&WA) 191 Here path selection and wavelength assignment are performed as 192 a single process. The requirements for PCC-PCE interaction 193 with such a combined RWA process PCE is addressed in this 194 document. 196 (b) Routing separate from Wavelength Assignment (R+WA) 198 Here the routing process furnishes one or more potential paths 199 to the wavelength assignment process that then performs final 200 path selection and wavelength assignment. The requirements for 201 PCE-PCE interaction with one PCE implementing the routing 202 process and another implementing the wavelength assignment 203 process are not addressed in this document. 205 (b') Routing and distributed Wavelength Assignment (R+DWA) 207 Here a standard path computation (unaware of detailed 208 wavelength availability) takes place, then wavelength 209 assignment is performed along this path in a distributed 210 manner via signaling (RSVP-TE). This alternative is a 211 particular case of R+WA and it should be covered by GMPLS PCEP 212 extensions and does not present new WSON-specific 213 requirements. 215 In the previous section various process architectures for 216 implementing RWA have been reviewed. Figure 2 shows one typical PCE- 217 based implementation, which is referred to as Combined Process 218 (R&WA). With this architecture, the two processes of routing and 219 wavelength assignment are accessed via a single PCE. This 220 architecture is the base architecture from which the requirements 221 are specified in this document. 223 +----------------------------+ 224 +-----+ | +-------+ +--+ | 225 | | | |Routing| |WA| | 226 | PCC |<----->| +-------+ +--+ | 227 | | | | 228 +-----+ | PCE | 229 +----------------------------+ 231 Figure 2. Combined Process (R&WA) architecture 233 3. Requirements 235 The requirements for the PCC to PCE interface of Figure 2 are 236 specified in this section. 238 3.1. Path Computation Type Option 240 A PCEP request MAY include the path computation type. This can be: 242 (i) Both Routing and Wavelength Assignment (RWA), 244 (ii) Routing only. 246 This requirement is needed to differentiate between the currently 247 supported routing with distributed wavelength assignment option and 248 combined RWA. In case of distributed wavelength assignment option, 249 wavelength assignment will be performed at each node of the route. 251 3.2. RWA Processing 253 (a) When the request is a RWA path computation type, the request 254 MUST further include the wavelength assignment options. At the 255 minimum, the following option should be supported: 257 (i) Explicit Label Control (ELC) [RFC3473] 259 (ii) A set of recommended labels for each hop. The PCC can 260 select the label based on local policy. 262 Note that option (ii) may also be used in R+WA or R+DWA. 264 (b) In case of a RWA computation type, the response MUST include 265 the wavelength(s) assigned to the path and an indication of which 266 label assignment option has been applied (ELC or label set). 268 (c) In the case where a valid path is not found, the response MUST 269 include why the path is not found (e.g., network disconnected, 270 wavelength not found, or both, etc.). Note that 'wavelength not 271 found' may include several sub-cases such as wavelength 272 continuity not met, unsupported FEC/Modulation type, etc. 274 3.3. Bulk RWA Path Request/Reply 276 Sending simultaneous path requests for "routing only" computation is 277 supported by PCEP specification [RFC5440]. To remain consistent the 278 following requirements are added. 280 (a) A PCEP request MUST be able to specify an option for bulk RWA 281 path request. Bulk path request is an ability to request a number 282 of simultaneous RWA path requests. 284 (b) The PCEP response MUST include the path and the assigned 285 wavelength assigned for each RWA path request specified in the 286 original bulk request. 288 3.4. RWA Path Re-optimization Request/Reply 290 1. For a re-optimization request, the request MUST provide both the 291 path and current wavelength to be re-optimized and MAY include 292 the following options: 294 a. Re-optimize the path keeping the same wavelength(s) 296 b. Re-optimize wavelength(s) keeping the same path 298 c. Re-optimize allowing both the wavelength and the path to 299 change 301 2. The corresponding response to the re-optimized request MUST 302 provide the re-optimized path and wavelengths even when the 303 request asked for the path or the wavelength to remain unchanged. 305 3. In case that the new path is not found, the response MUST include 306 why the path is not found (e.g., network disconnected, wavelength 307 not found, or both, etc.). Note that 'wavelength not found' may 308 include several sub-cases such as wavelength continuity not met, 309 unsupported FEC/Modulation type, etc. 311 3.5. Wavelength Range Constraint 313 For any RWA computation type request, the requester (PCC) MUST be 314 allowed to specify a restriction on the wavelengths to be used. The 315 requester MAY use this option to restrict the assigned wavelength 316 for explicit label or label set. This restriction may for example 317 come from the tuning ability of a laser transmitter, any optical 318 element, or a policy-based restriction. 320 Note that the requester (e.g., PCC) is not required to furnish any 321 range restrictions. 323 3.6. Wavelength Assignment Preference 325 1. A RWA computation type request MAY include the requester 326 preference for, e.g., random assignment, descending order, 327 ascending order, etc. A response SHOULD follow the requestor 328 preference unless it conflicts with operator's policy. 330 2. A request for two or more paths MUST allow the requester to 331 include an option constraining the paths to have the same 332 wavelength(s) assigned. This is useful in the case of protection 333 with single transponder (e.g., 1+1 link disjoint paths). 335 In a network with wavelength conversion capabilities (e.g. sparse 3R 336 regenerators), a request SHOULD be able to indicate whether a 337 single, continuous wavelength should be allocated or not. In other 338 words, the requesting PCC SHOULD be able to specify the precedence 339 of wavelength continuity even if wavelength conversion is available. 341 3.7. Signal Processing Capability Restriction 343 Signal processing compatibility is an important constraint for 344 optical path computation. The signal type for an end-to-end optical 345 path must match at source and at destination. 347 The PCC MUST be allowed to specify the signal type at the endpoints 348 (i.e., at source and at destination). The following signal 349 processing capabilities should be supported at a minimum: 351 o Modulation Type List 353 o FEC Type List 355 The PCC MUST also be allowed to state whether transit modification 356 is acceptable for the above signal processing capabilities. 358 4. Manageability Considerations 360 Manageability of WSON Routing and Wavelength Assignment (RWA) with 361 PCE must address the following considerations: 363 4.1. Control of Function and Policy 365 In addition to the parameters already listed in Section 8.1 of 366 [RFC5440], a PCEP implementation SHOULD allow configuring the 367 following PCEP session parameters on a PCC: 369 o The ability to send a WSON RWA request. 371 In addition to the parameters already listed in Section 8.1 of 372 [RFC5440], a PCEP implementation SHOULD allow configuring the 373 following PCEP session parameters on a PCE: 375 o The support for WSON RWA. 377 o The maximum number of bulk path requests associated with WSON 378 RWA per request message. 380 These parameters may be configured as default parameters for any 381 PCEP session the PCEP speaker participates in, or may apply to a 382 specific session with a given PCEP peer or a specific group of 383 sessions with a specific group of PCEP peers. 385 4.2. Information and Data Models, e.g. MIB module 387 As this document only concerns the requirements to support WSON RWA, 388 no additional MIB module is defined in this document. However, the 389 corresponding solution draft will list the information that should 390 be added to the PCE MIB module defined in [PCEP-MIB]. 392 4.3. Liveness Detection and Monitoring 394 No new mechanism is defined in this document that implies any new 395 liveness detection and monitoring requirements in addition to those 396 already listed in section 8.3 of [RFC5440]. 398 4.4. Verifying Correct Operation 400 No new mechanism is defined in this document that implies any new 401 verification requirements in addition to those already listed in 402 section 8.4 of [RFC5440] 404 4.5. Requirements on Other Protocols and Functional Components 406 If PCE discovery mechanisms ([RFC5089] and [RFC5088]) were to be 407 extended for technology-specific capabilities, advertising WSON RWA 408 path computation capability should be considered. 410 4.6. Impact on Network Operation 412 No new mechanism is defined in this document that implies any new 413 network operation requirements in addition to those already listed 414 in section 8.6 of [RFC5440]. 416 5. Security Considerations 418 This document has no requirement for a change to the security models 419 within PCEP [RFC5440]. However the additional information 420 distributed in order to address the RWA problem represents a 421 disclosure of network capabilities that an operator may wish to keep 422 private. Consideration should be given to securing this information. 424 Solutions that address the requirements in this document need to 425 verify that existing PCEP security mechanisms adequately protect the 426 additional network capabilities and must include new mechanisms as 427 necessary. 429 6. IANA Considerations 431 This informational document does not make any requests for IANA 432 action. 434 7. Acknowledgments 436 The authors would like to thank Adrian Farrel, Cycil Margaria and 437 Ramon Casellas for many helpful comments that greatly improved the 438 contents of this draft. 440 This document was prepared using 2-Word-v2.0.template.dot. 442 8. References 444 8.1. Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 450 Element (PCE)-Based Architecture", RFC 4655, August 2006. 452 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 453 Element (PCE) communication Protocol", RFC 5440, March 454 2009. 456 8.2. Informative References 458 [RFC3473] L. Berger, "Generalized Multi-Protocol Label Switching 459 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 460 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 462 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 463 Communication Protocol Generic Requirements", RFC 4657, 464 September 2006. 466 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 467 and PCE Control of Wavelength Switched Optical Networks", 468 RFC 6163, April 2011. 470 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 471 Zhang, "OSPF Protocol Extensions for Path Computation 472 Element (PCE) Discovery", RFC 5088, January 2008. 474 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 475 Zhang, "IS-IS Protocol Extensions for Path Computation 476 Element (PCE) Discovery", RFC 5089, January 2008. 478 [PCEP-MIB] Koushik, K, et al., "PCE communication protocol(PCEP) 479 Management Information Base", draft-ietf-pce-pcep-mib, 480 work in progress. 482 Authors' Addresses 484 Young Lee (Ed.) 485 Huawei Technologies 486 5340 Legacy Drive, Building 3 487 Plano, TX 75245, USA 488 Phone: (469)277-5838 489 Email: leeyoung@huawei.com 491 Greg Bernstein (Ed.) 492 Grotto Networking 493 Fremont, CA, USA 494 Phone: (510) 573-2237 495 Email: gregb@grotto-networking.com 497 Jonas Martensson 498 Acreo 499 Email:Jonas.Martensson@acreo.se 501 Tomonori Takeda 502 NTT Corporation 503 3-9-11, Midori-Cho 504 Musashino-Shi, Tokyo 180-8585, Japan 505 Email: takeda.tomonori@lab.ntt.co.jp 506 Takehiro Tsuritani 507 KDDI R&D Laboratories, Inc. 508 2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan 509 Phone: +81-49-278-7357 510 Email: tsuri@kddilabs.jp 512 Oscar Gonzalez de Dios 513 Telefonica Investigacion y Desarrollo 514 C/ Emilio Vargas 6 515 Madrid, 28043 516 Spain 517 Phone: +34 91 3374013 518 Email: ogondio@tid.es