idnits 2.17.1 draft-lee-pce-wson-routing-wavelength-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2009) is 5407 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) == Unused Reference: 'WSON-IMP' is defined on line 372, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4657 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: Standard Track 4 Expires: December 2009 G. Bernstein 5 Grotto Networking 7 Jonas Martensson 8 Acreo 10 T. Takeda 11 NTT 13 T. Otani 14 KDDI 16 June 29, 2009 18 PCEP Requirements for WSON Routing and Wavelength Assignment 20 draft-lee-pce-wson-routing-wavelength-05.txt 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on December 29, 2009. 45 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This memo provides application-specific requirements for the Path 58 Computation Element communication Protocol (PCEP) for the support of 59 Wavelength Switched Optical Networks (WSON). Lightpath provisioning 60 in WSONs requires a routing and wavelength assignment (RWA) process. 61 From a path computation perspective, wavelength assignment is the 62 process of determining which wavelength can be used on each hop of a 63 path and forms an additional routing constraint to optical light path 64 computation. Requirements related to optical impairments will be 65 addressed in a separate document. 67 Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 Table of Contents 75 1. Introduction...................................................3 76 1.1. WSON RWA Processes........................................4 77 2. WSON PCE Architectures and Requirements........................5 78 2.1. RWA PCC to PCE Interface..................................5 79 2.1.1. A new RWA path request...............................6 80 2.1.2. An RWA path re-optimization request..................6 81 2.1.3. Wavelength Range Constraint..........................6 82 3. Manageability Considerations...................................7 83 3.1. Control of Function and Policy............................7 84 3.2. Information and Data Models, e.g. MIB module..............7 85 3.3. Liveness Detection and Monitoring.........................7 86 3.4. Verifying Correct Operation...............................8 87 3.5. Requirements on Other Protocols and Functional Components.8 88 3.6. Impact on Network Operation...............................8 89 4. Security Considerations........................................8 90 5. IANA Considerations............................................8 91 6. Acknowledgments................................................8 92 7. References.....................................................9 93 7.1. Normative References......................................9 94 7.2. Informative References....................................9 95 Authors' Addresses...............................................10 96 Intellectual Property Statement..................................10 97 Disclaimer of Validity...........................................11 99 1. Introduction 101 [RFC4655] defines the PCE based Architecture and explains how a Path 102 Computation Element (PCE) may compute Label Switched Paths (LSP) in 103 Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and 104 Generalized MPLS (GMPLS) networks at the request of Path Computation 105 Clients (PCCs). A PCC is shown to be any network component that 106 makes such a request and may be for instance an Optical Switching 107 Element within a Wavelength Division Multiplexing (WDM) network. The 108 PCE, itself, can be located anywhere within the network, and may be 109 within an optical switching element, a Network Management System 110 (NMS) or Operational Support System (OSS), or may be an independent 111 network server. 113 The PCE communications Protocol (PCEP) is the communication protocol 114 used between PCC and PCE, and may also be used between cooperating 115 PCEs. [RFC4657] sets out the common protocol requirements for PCEP. 116 Additional application-specific requirements for PCEP are deferred to 117 separate documents. 119 This document provides a set of application-specific PCEP 120 requirements for support of path computation in Wavelength Switched 121 Optical Networks (WSON). WSON refers to WDM based optical networks 122 in which switching is performed selectively based on the wavelength 123 of an optical signal. 125 The path in WSON is referred to as a lightpath. A lightpath may span 126 multiple fiber links and the path should be assigned a wavelength for 127 each link. A transparent optical network is made up of optical 128 devices that can switch but not convert from one wavelength to 129 another. In a transparent optical network, a lightpath operates on 130 the same wavelength across all fiber links that it traverses. In such 131 case, the lightpath is said to satisfy the wavelength-continuity 132 constraint. Two lightpaths that share a common fiber link can not be 133 assigned the same wavelength. To do otherwise would result in both 134 signals interfering with each other. Note that advanced additional 135 multiplexing techniques such as polarization based multiplexing are 136 not addressed in this document since the physical layer aspects are 137 not currently standardized. Therefore, assigning the proper 138 wavelength on a lightpath is an essential requirement in the optical 139 path computation process. 141 When a switching node has the ability to perform wavelength 142 conversion the wavelength-continuity constraint can be relaxed, and a 143 lightpath may use different wavelengths on different links along its 144 route from origin to destination. It is, however, to be noted that 145 wavelength converters may be limited due to their relatively high 146 cost, while the number of WDM channels that can be supported in a 147 fiber is also limited. As a WSON can be composed of network nodes 148 that cannot perform wavelength conversion, nodes with limited 149 wavelength conversion, and nodes with full wavelength conversion 150 abilities, wavelength assignment is an additional routing constraint 151 to be considered in all lightpath computation. 153 In this document we first review the processes for routing and 154 wavelength assignment (RWA) used when wavelength continuity 155 constraints are present and then specify requirements for PCEP to 156 support RWA. 158 The remainder of this document uses terminology from [RFC4655]. 160 1.1. WSON RWA Processes 162 In [WSON-Frame] three alternative process architectures were given 163 for performing routing and wavelength assignment. These are shown 164 schematically in Figure 1. 166 +-------------------+ 167 | +-------+ +--+ | +-------+ +--+ +-------+ +---+ 168 | |Routing| |WA| | |Routing|--->|WA| |Routing|--->|DWA| 169 | +-------+ +--+ | +-------+ +--+ +-------+ +---+ 170 | Combined | Separate Processes Separate Processes 171 | Processes | WA performed in a 172 +-------------------+ Distributed manner 173 (a) (b) (c) 175 Figure 1 RWA process alternatives. 177 These alternatives have the following properties and impact on PCEP 178 requirements in this document. 180 1. Combined Processes (R&WA) - Here path selection and wavelength 181 assignment are performed as a single process. The requirements for 182 PCC-PCE interaction with such a combined RWA process PCE is 183 addressed in this document. 185 2. Routing separate from Wavelength Assignment (R+WA) - Here the 186 routing process furnishes one or more potential paths to the 187 wavelength assignment process that then performs final path 188 selection and wavelength assignment. The requirements for PCE-PCE 189 interaction with one PCE implementing the routing process and 190 another implementing the wavelength assignment process are not 191 addressed in this document. 193 3. Routing and distributed Wavelength Assignment (R+DWA) - Here a 194 standard path computation (unaware of detailed wavelength 195 availability) takes place, then wavelength assignment is performed 196 along this path in a distributed manner via signaling (RSVP-TE). 197 This alternative should be covered by existing or emerging GMPLS 198 PCEP extensions and does not present new WSON specific 199 requirements. 201 2. WSON PCE Architectures and Requirements 203 In the previous section we reviewed various process architectures for 204 implementing RWA. In Figure 2 we reduce these alternatives to one 205 typical PCE based implementation, which is referred to as Combined 206 Process (R&WA). In Figure 2 we show the two processes of routing and 207 wavelength assignment accessed via a single PCE. 209 +----------------------------+ 210 +-----+ | +-------+ +--+ | 211 | | | |Routing| |WA| | 212 | PCC |<----->| +-------+ +--+ | 213 | | | | 214 +-----+ | PCE | 215 +----------------------------+ 217 Figure 2 Combined Process (R&WA) architecture 219 2.1. RWA PCC to PCE Interface 221 The requirements for the PCC to PCE interface of Figure 2 are 222 specified in this section. 224 2.1.1. A new RWA path request 226 1. The PCReq Message MUST include the path computation type. This can 227 be: RWA, or only routing. This requirement is needed to 228 differentiate between the currently supported routing with 229 distribute wavelength assignment option and combined RWA. 231 2. The PCRep Message MUST include the route, and wavelengths assigned 232 to the route. In the case where a valid path is not found, the 233 PCRep Message MUST include why the path is not found (e.g., no 234 route, wavelength not found, etc.) 236 2.1.2. An RWA path re-optimization request 238 1. For a re-optimization request, the PCReq Message MUST provide the 239 path to be re-optimized and include the following options: 241 a. Re-optimize the path keeping the same wavelength(s) 243 b. Re-optimize wavelength(s) keeping the same path 245 c. Re-optimize allowing both wavelength and the path to change 247 2. The corresponding PCRep Message for the re-optimized request MUST 248 provide the Re-optimized path and wavelengths. In case that the 249 path is not found, the PCRep Message MUST include why the path is 250 not found (e.g., no route, wavelength not found, both route and 251 wavelength not found, etc.) 253 2.1.3. Wavelength Range Constraint 255 For any PCReq Message that is associated with a request for 256 wavelength assignment the requester (PCC) MUST be able to specify a 257 restriction on the wavelengths to be used. 259 Note that the requestor (PCC) is NOT required to furnish any range 260 restrictions. This restriction is to be interpreted by the PCE as a 261 constraint on the tuning ability of the origination laser 262 transmitter. 264 3. Manageability Considerations 266 Manageability of WSON Routing and Wavelength Assignment (RWA) with 267 PCE must address the following considerations: 269 3.1. Control of Function and Policy 271 In addition to the parameters already listed in Section 8.1 of 272 [PCEP], a PCEP implementation SHOULD allow configuring the following 273 PCEP session parameters on a PCC: 275 o The ability to send a WSON RWA request. 277 In addition to the parameters already listed in Section 8.1 of 278 [PCEP], a PCEP implementation SHOULD allow configuring the following 279 PCEP session parameters on a PCE: 281 o The support for WSON RWA. 283 o The maximum number of synchronized path requests associated with 284 WSON RWA per request message. 286 o A set of WSON RWA specific policies (authorized sender, request 287 rate limiter, etc). 289 These parameters may be configured as default parameters for any PCEP 290 session the PCEP speaker participates in, or may apply to a specific 291 session with a given PCEP peer or a specific group of sessions with a 292 specific group of PCEP peers. 294 3.2. Information and Data Models, e.g. MIB module 296 Extensions to the PCEP MIB module defined in [PCEP-MIB] should be 297 defined, so as to cover the WSON RWA information introduced in this 298 document. A future revision of this document will list the 299 information that should be added to the MIB module. 301 3.3. Liveness Detection and Monitoring 303 Mechanisms defined in this document do not imply any new liveness 304 detection and monitoring requirements in addition to those already 305 listed in section 8.3 of [PCEP]. 307 3.4. Verifying Correct Operation 309 Mechanisms defined in this document do not imply any new verification 310 requirements in addition to those already listed in section 8.4 of 311 [PCEP] 313 3.5. Requirements on Other Protocols and Functional Components 315 The PCE Discovery mechanisms ([RFC5089] and [RFC5088]) may be used to 316 advertise WSON RWA path computation capabilities to PCCs. 318 3.6. Impact on Network Operation 320 Mechanisms defined in this document do not imply any new network 321 operation requirements in addition to those already listed in section 322 8.6 of [PCEP]. 324 4. Security Considerations 326 This document has no requirement for a change to the security models 327 within PCEP [PCEP]. However the additional information distributed in 328 order to address the RWA problem represents a disclosure of network 329 capabilities that an operator may wish to keep private. Consideration 330 should be given to securing this information. 332 5. IANA Considerations 334 A future revision of this document will present requests to IANA for 335 codepoint allocation. 337 6. Acknowledgments 339 The authors would like to thank Adrian Farrel for many helpful 340 comments that greatly improved the contents of this draft. 342 This document was prepared using 2-Word-v2.0.template.dot. 344 7. References 346 7.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 352 Element (PCE)-Based Architecture", RFC 4655, August 2006. 354 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 355 Communication Protocol Generic Requirements", RFC 4657, 356 September 2006. 358 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 359 Element (PCE) communication Protocol (PCEP) - Version 1", 360 RFC 5440, March 2009. 362 [PCEP-MIB] "PCE communication protocol(PCEP) Management Information 363 Base", draft-ietf-pce-pcep-mib, work in progress. 365 7.2. Informative References 367 [WSON-Frame] Bernstein, G. and Lee, Y. (Editors), and W. Imajuku, "A 368 Framework for the Control and Measurement of Wavelength 369 Switched Optical Networks (WSON) with Impairments 370 draft-bernstein-ccamp-wson-impairments, work in progress. 372 [WSON-IMP] Bernstein, G. and Lee, Y. (Editors), and D. Li, "Framework 373 for GMPLS and PCE Control of Wavelength Switched Optical 374 Networks", draft-bernstein-ccamp-wavelength-switched, work 375 in progress. 377 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 378 Zhang, "OSPF Protocol Extensions for Path Computation 379 Element (PCE) Discovery", RFC 5088, January 2008. 381 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 382 Zhang, "IS-IS Protocol Extensions for Path Computation 383 Element (PCE) Discovery", RFC 5089, January 2008. 385 Authors' Addresses 387 Young Lee (Ed.) 388 Huawei Technologies 389 1700 Alma Drive, Suite 100 390 Plano, TX 75075, USA 391 Phone: (972) 509-5599 (x2240) 392 Email: ylee@huawei.com 394 Greg M. Bernstein (ed.) 395 Grotto Networking 396 Fremont California, USA 398 Phone: (510) 573-2237 399 Email: gregb@grotto-networking.com 401 Jonas Martensson 402 Acreo 403 Email:Jonas.Martensson@acreo.se 405 Tomonori Takeda 406 NTT Corporation 407 3-9-11, Midori-Cho 408 Musashino-Shi, Tokyo 180-8585, Japan 409 Email: takeda.tomonori@lab.ntt.co.jp 411 Tomohiro Otani 412 KDDI R&D Laboratories, Inc. 413 2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan 414 Phone: +81-49-278-7357 415 Email: otani@kddilabs.jp 417 Intellectual Property Statement 419 The IETF Trust takes no position regarding the validity or scope of 420 any Intellectual Property Rights or other rights that might be 421 claimed to pertain to the implementation or use of the technology 422 described in any IETF Document or the extent to which any license 423 under such rights might or might not be available; nor does it 424 represent that it has made any independent effort to identify any 425 such rights. 427 Copies of Intellectual Property disclosures made to the IETF 428 Secretariat and any assurances of licenses to be made available, or 429 the result of an attempt made to obtain a general license or 430 permission for the use of such proprietary rights by implementers or 431 users of this specification can be obtained from the IETF on-line IPR 432 repository at http://www.ietf.org/ipr 434 The IETF invites any interested party to bring to its attention any 435 copyrights, patents or patent applications, or other proprietary 436 rights that may cover technology that may be required to implement 437 any standard or specification contained in an IETF Document. Please 438 address the information to the IETF at ietf-ipr@ietf.org. 440 Disclaimer of Validity 442 All IETF Documents and the information contained therein are provided 443 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 444 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 445 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 446 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 447 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 448 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 449 FOR A PARTICULAR PURPOSE. 451 Acknowledgment 453 Funding for the RFC Editor function is currently provided by the 454 Internet Society.