idnits 2.17.1 draft-lee-ccamp-wson-signal-compatibility-ospf-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 5. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 12, 2009) is 5310 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 section? 'RFC2119' on line 498 looks like a reference -- Missing reference section? 'WSON-Compat' on line 526 looks like a reference -- Missing reference section? 'G.709' on line 155 looks like a reference -- Missing reference section? 'G.707' on line 155 looks like a reference -- Missing reference section? 'RFC3471' on line 501 looks like a reference -- Missing reference section? 'RFC4328' on line 516 looks like a reference -- Missing reference section? 'RFC4202' on line 508 looks like a reference -- Missing reference section? 'RFC4203' on line 512 looks like a reference -- Missing reference section? 'RFC5307' on line 520 looks like a reference -- Missing reference section? 'RFC2578' on line 364 looks like a reference -- Missing reference section? 'RFC 3630' on line 484 looks like a reference -- Missing reference section? 'RFC 4203' on line 484 looks like a reference -- Missing reference section? 'G.694.1' on line 505 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 14 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: Standards Track G. Bernstein 4 Expires: April 2010 Grotto Networking 6 October 12, 2009 8 OSPF Enhancement for Signal and Network Element Compatibility for 9 Wavelength Switched Optical Networks 11 draft-lee-ccamp-wson-signal-compatibility-ospf-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on April 12, 2007. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document provides GMPLS OSPF routing enhancements to support 50 signal compatibility constraints associated with WSON network 51 elements. These routing enhancements are required in common optical 52 or hybrid electro-optical networks where not all of the optical 53 signals in the network are compatible with all network elements 54 participating in the network. 56 This compatibility constraint model is applicable to common optical 57 or hybrid electro optical systems such as OEO switches, regenerators, 58 and wavelength converters since such systems can be limited to 59 processing only certain types of WSON signals. 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC-2119 [RFC2119]. 67 Table of Contents 69 1. Introduction...................................................3 70 2. WSON Network Element Compatibility Information Model...........3 71 2.1. Modulation Type List......................................4 72 2.2. FEC Type List.............................................4 73 2.3. Bit Rate Range List.......................................4 74 2.4. Acceptable Client Signal List.............................4 75 3. GMPLS OSPF Routing Protocol Enhancement to support Compatibility5 76 3.1. Modulation Type List sub-TLV..............................5 77 3.2. FEC Type List sub-TLV.....................................7 78 3.3. Bit Rate Range List sub-TLV...............................9 79 3.4. Processing Capability List sub-TLV.......................10 80 3.5. Client Signal List sub-TLV...............................12 81 4. Security Considerations.......................................12 82 5. IANA Considerations...........................................12 83 6. Acknowledgments...............................................12 84 7. References....................................................13 85 7.1. Normative References.....................................13 86 7.2. Informative References...................................13 87 8. Contributors..................................................14 88 Authors' Addresses...............................................14 89 Intellectual Property Statement..................................14 90 Disclaimer of Validity...........................................15 92 1. Introduction 94 The document [WSON-Compat] explains how to extend the wavelength 95 switched optical network (WSON) control plane to allow both multiple 96 WSON signal types and common hybrid electro optical systems. In WSON, 97 not all of the optical signals in the network are compatible with all 98 network elements participating in the network. Therefore, signal 99 compatibility is an important constraint in path computation in a 100 WSON. 102 This document provides GMPLS OSPF routing enhancements to support 103 signal compatibility constraints associated with WSON network 104 elements. These routing enhancements are required in common optical 105 or hybrid electro-optical networks where not all of the optical 106 signals in the network are compatible with all network elements 107 participating in the network. 109 This compatibility constraint model is applicable to common optical 110 or hybrid electro optical systems such as OEO switches, regenerators, 111 and wavelength converters since such systems can be limited to 112 processing only certain types of WSON signals. 114 2. WSON Network Element Compatibility Information Model 116 In [WSON-Compat] it was explained that a network element (NE) in a 117 WSON may or may not be compatible with a particular optical signal 118 based upon the following criteria: 120 1. Limited wavelength range -- Already modeled in GMPLS for WSON 122 2. Modulation type restriction (including forward error correction - 123 FEC- coding) 125 3. Bit rate range restriction (includes a particular rate) 127 4. Client signal dependence 129 In the following we furnish an information model for the above 130 properties. This model can be either applied to all ports of a 131 network element, i.e., NE wide, or to individual ports, i.e., on a 132 link level. 134 2.1. Modulation Type List 136 Modulation type, also known as optical tributary signal class, comes 137 in two distinct flavors: (i) ITU-T standardized types; (ii) vendor 138 specific types. The permitted modulation type list can include any 139 mixture of standardized and vendor specific types. 141 ::= [|]... 143 Where the STANDARD_MODULATION object just represents one of the ITU-T 144 standardized optical tributary signal class and the VENDOR_MODULATION 145 object identifies one vendor specific modulation type. 147 2.2. FEC Type List 149 Some devices can handle more than one FEC type and hence a list is 150 needed. 152 ::= [] 154 Where the FEC object represents one of the ITU-T standardized FEC 155 defined in [G.709] and [G.707] or vendor-specific FEC. 157 2.3. Bit Rate Range List 159 Some devices can handle more than one particular bit rate range and 160 hence a list is needed. 162 ::= []... 164 ::= 166 Where the START_RATE object represents the lower end of the range and 167 the END_RATE object represents the higher end of the range. 169 2.4. Acceptable Client Signal List 171 The list is simply: 173 ::=[]... 175 Where the Generalized Protocol Identifiers (GPID) object represents 176 one of the IETF standardized GPID values as defined in [RFC3471] and 177 [RFC4328]. 179 3. GMPLS OSPF Routing Protocol Enhancement to support Compatibility 181 This section describes GMPLS OSPF Routing protocol enhancement based 182 on network element compatibility information model defined in the 183 previous section. Note that the encoding defined in this section is 184 specific for OSPF extension, but similar encoding can be applied to 185 IS-IS and alternative methods distributing traffic engineering 186 information. 188 In [RFC4202], Routing extensions for GMPLS, the concept of an 189 Interface Switching Capability Descriptors is defined. In particular 190 a "Lambda-Switch Capable" (LSC) descriptor is listed. Reference 191 [RFC4202] also states: "Depending on a particular Interface Switching 192 Capability, the Interface Switching Capability Descriptor may include 193 additional information, as specified below." However no mention is 194 made of the compatibility criteria discussed in [WSON-Compat], i.e., 195 modulation type, FEC type, bit rate range, or client signal. The only 196 additional information currently defined is "reservable bandwidth per 197 priority". 199 In references [RFC4203] and [RFC5307] a variable length sub-TLV type 200 for Interface Switching Capability Descriptors (ISCD) is defined. 201 There is a section in the general ISCD sub-TLV called "Switching 202 Capability-specific information". They then state: "When the 203 Switching Capability field is LSC, there is no Switching Capability 204 specific information field present." 206 [It is an open question whether we can add new information to the 207 existing LSC ISCD. In either case the following suggests an encoding 208 that could be used within the switching capability specific 209 information field or as separate sub-TLVs.] 211 3.1. Modulation Type List sub-TLV 213 The modulation type list sub-TLV may consist of two different types 214 of fields: a standard modulation field or a vendor specific 215 modulation field. Both start with the same 32 bit header shown below. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 |S|I| Modulation ID | Length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Where S bit set to 1 indicates a standardized modulation format and S 224 bit set to 0 indicates a vendor specific modulation format. The 225 length is the length in bytes of the entire modulation type field. 227 Where I bit set to 1 indicates it is an input modulation constraint 228 and I bit set to 0 indicates it is an output modulation constraint. 230 Note that if an output modulation is not specified then it is implied 231 that it is the same as the input modulation. In such case, no 232 modulation conversion is performed. 234 The format for the standardized type for the input modulation is 235 given by: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |1|1| Modulation ID | Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Possible additional modulation parameters depending upon | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 : the modulation ID : 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Modulation ID (S bit = 1); Input modulation (I bit = 1) 249 Takes on the following currently defined values: 251 0 Reserved 253 1 optical tributary signal class NRZ 1.25G 255 2 optical tributary signal class NRZ 2.5G 257 3 optical tributary signal class NRZ 10G 259 4 optical tributary signal class NRZ 40G 261 5 optical tributary signal class RZ 40G 263 Note that future modulation types may require additional parameters 264 in their characterization. 266 The format for vendor specific modulation field (for input 267 constraint) is given by: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 |0|1| Vendor Modulation ID | Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Enterprise Number | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 : Any vendor specific additional modulation parameters : 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Vendor Modulation ID 281 This is a vendor assigned identifier for the modulation type. 283 Enterprise Number 285 A unique identifier of an organization encoded as a 32-bit integer. 286 Enterprise Numbers are assigned by IANA and managed through an IANA 287 registry [RFC2578]. 289 Vendor Specific Additional parameters 291 There can be potentially additional parameters characterizing the 292 vendor specific modulation. 294 3.2. FEC Type List sub-TLV 296 The FEC type list sub-TLV may consist of two different types of 297 fields: a standard FEC field or a vendor specific FEC field. Both 298 start with the same 32 bit header shown below. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |S|I| FEC ID | Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Possible additional FEC parameters depending upon | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 : the FEC ID : 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Where S bit set to 1 indicates a standardized FEC format and S bit 311 set to 0 indicates a vendor specific FEC format. The length is the 312 length in bytes of the entire FEC type field. 314 Where I bit set to 1 indicates it is an input FEC constraint and I 315 bit set to 0 indicates it is an output FEC constraint. 317 Note that if an output FEC is not specified then it is implied that 318 it is the same as the input FEC. In such case, no FEC conversion is 319 performed. 321 The length is the length in bytes of the entire FEC type field. 323 The format for input standard FEC field is given by: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 |1|1| FEC ID | Length | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Possible additional FEC parameters depending upon | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 : the FEC ID : 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Takes on the following currently defined values for the standard 336 FEC ID: 338 0 Reserved 340 1 G.709 RS FEC 342 2 G.709V compliant Ultra FEC 344 The format for input vendor-specific FEC field is given by: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |0|1| Vendor FEC ID | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Enterprise Number | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 : Any vendor specific additional FEC parameters : 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Vendor FEC ID 358 This is a vendor assigned identifier for the FEC type. 360 Enterprise Number 362 A unique identifier of an organization encoded as a 32-bit integer. 363 Enterprise Numbers are assigned by IANA and managed through an IANA 364 registry [RFC2578]. 366 Vendor Specific Additional FEC parameters 368 There can be potentially additional parameters characterizing the 369 vendor specific FEC. 371 3.3. Bit Rate Range List sub-TLV 373 The bit rate range list sub-TLV makes use of the following bit rate 374 range field: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Starting Bit Rate | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Ending Bit Rate | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 The starting and ending bit rates are given as 32 bit IEEE floating 385 point numbers in bits per second. Note that the starting bit rate is 386 less than or equal to the ending bit rate. 388 The bit rate range list sub-TLV is then given by: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+ Bit Range Field #1 +-+-+-+-+-+-+-+-+-+ 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 : : : 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+ Bit Range Field #M +-+-+-+-+-+-+-+-+-+ 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 3.4. Processing Capability List sub-TLV 406 The processing capability list sub-TLV is a list of WSON network 407 element (NE) that can perform signal processing functions including: 409 1. Regeneration capability 411 2. Fault and performance monitoring 413 3. Vendor Specific capability 415 Note that the code points for Fault and performance monitoring and 416 vendor specific capability are subject to further study. 418 The processing capability list sub-TLV is then given by: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Processing Cap ID | Length | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Possible additional capability parameters depending upon | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 : the processing ID : 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 When the processing Cap ID is "regeneration capability", the 431 following additional capability parameters are provided in the sub- 432 TLV: 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | T | C | Reserved | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Where T bit indicates the type of regenerator: 442 T=0: Reserved 444 T=1: 1R Regenerator 446 T=2: 2R Regenerator 448 T=3: 3R Regenerator 450 Where C bit indicates the capability of regenerator: 452 C=0: Reserved 454 C=1: Fixed Regeneration Point 456 C=2: Selective Regeneration Pools 458 Note that when the capability of regenerator is indicated to be 459 Selective Regeneration Pools, regeneration pool properties such as 460 ingress and egress restrictions and availability need to be 461 specified. This encoding is to be determined in the later revision. 463 3.5. Client Signal List sub-TLV 465 The acceptable client signal list sub-TLV is a list of Generalized 466 Protocol Identifiers (GPIDs). GPIDs are assigned by IANA and many are 467 defined in [RFC3471] and [RFC4328]. 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Number of GPIDs | GPID #1 | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 : | : 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | GPID #N | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Where the number of GPIDs is an integer greater than or equal to one. 481 4. Security Considerations 483 This document does not introduce any further security issues other 484 than those discussed in [RFC 3630], [RFC 4203]. 486 5. IANA Considerations 488 TBD. 490 6. Acknowledgments 492 This document was prepared using 2-Word-v2.0.template.dot. 494 7. References 496 7.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 502 (GMPLS) Signaling Functional Description", RFC 3471, 503 January 2003. 505 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 506 applications: DWDM frequency grid", June, 2002. 508 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 509 in Support of Generalized Multi-Protocol Label Switching 510 (GMPLS)", RFC 4202, October 2005 512 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 513 Support of Generalized Multi-Protocol Label Switching 514 (GMPLS)", RFC 4203, October 2005. 516 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 517 Switching (GMPLS) Signaling Extensions for G.709 Optical 518 Transport Networks Control", RFC 4328, January 2006. 520 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 521 in Support of Generalized Multi-Protocol Label Switching 522 (GMPLS)", RFC 5307, October 2008. 524 7.2. Informative References 526 [WSON-Compat] G. Bernstein, Y. Lee, B. Mack-Crane, "WSON Signal 527 Characteristics and Network Element Compatibility 528 Constraints for GMPLS ", draft-bernstein-ccamp-wson 529 compatibility, work in progress. 531 8. Contributors 533 Authors' Addresses 535 Young Lee (ed.) 536 Huawei Technologies 537 1700 Alma Drive, Suite 100 538 Plano, TX 75075 539 USA 541 Phone: (972) 509-5599 (x2240) 542 Email: ylee@huawei.com 544 Greg M. Bernstein (ed.) 545 Grotto Networking 546 Fremont California, USA 548 Phone: (510) 573-2237 549 Email: gregb@grotto-networking.com 551 Intellectual Property Statement 553 The IETF Trust takes no position regarding the validity or scope of 554 any Intellectual Property Rights or other rights that might be 555 claimed to pertain to the implementation or use of the technology 556 described in any IETF Document or the extent to which any license 557 under such rights might or might not be available; nor does it 558 represent that it has made any independent effort to identify any 559 such rights. 561 Copies of Intellectual Property disclosures made to the IETF 562 Secretariat and any assurances of licenses to be made available, or 563 the result of an attempt made to obtain a general license or 564 permission for the use of such proprietary rights by implementers or 565 users of this specification can be obtained from the IETF on-line IPR 566 repository at http://www.ietf.org/ipr 568 The IETF invites any interested party to bring to its attention any 569 copyrights, patents or patent applications, or other proprietary 570 rights that may cover technology that may be required to implement 571 any standard or specification contained in an IETF Document. Please 572 address the information to the IETF at ietf-ipr@ietf.org. 574 Disclaimer of Validity 576 All IETF Documents and the information contained therein are provided 577 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 578 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 579 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 580 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 581 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 582 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 583 FOR A PARTICULAR PURPOSE. 585 Acknowledgment 587 Funding for the RFC Editor function is currently provided by the 588 Internet Society.