idnits 2.17.1 draft-ietf-ccamp-wson-signal-compatibility-ospf-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) 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 (September 2, 2010) is 4984 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: 'RWA-Encode' is mentioned on line 176, but not defined == Missing Reference: 'RFC 3630' is mentioned on line 193, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 193, but not defined == Unused Reference: 'RFC3471' is defined on line 238, but no explicit reference was found in the text == Unused Reference: 'G.694.1' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'RFC4202' is defined on line 249, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC4328' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'RFC5307' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'Lambda-Labels' is defined on line 269, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' -- No information found for draft-ietf-ccamp-rwa-WSON-Framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'WSON-Frame' ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-rwa-info (ref. 'WSON-Info') Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 4 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: March 2011 Grotto Networking 6 September 2, 2010 8 OSPF Enhancement for Signal and Network Element Compatibility for 9 Wavelength Switched Optical Networks 11 draft-ietf-ccamp-wson-signal-compatibility-ospf-02.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 September 2, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 42 2010 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Abstract 56 This document provides GMPLS OSPF routing enhancements to support 57 signal compatibility constraints associated with WSON network 58 elements. These routing enhancements are required in common optical 59 or hybrid electro-optical networks where not all of the optical 60 signals in the network are compatible with all network elements 61 participating in the network. 63 This compatibility constraint model is applicable to common optical 64 or hybrid electro optical systems such as OEO switches, regenerators, 65 and wavelength converters since such systems can be limited to 66 processing only certain types of WSON signals. 68 Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC-2119 [RFC2119]. 74 Table of Contents 76 1. Introduction...................................................3 77 1.1. Revision History..........................................3 78 2. Compatibility and Accessibility Sub-TLVs.......................3 79 2.1. Resource Block Information sub-TLV........................4 80 3. Security Considerations........................................5 81 4. IANA Considerations............................................5 82 4.1. Node Information..........................................5 83 5. References.....................................................6 84 5.1. Normative References......................................6 85 6. Contributors...................................................7 86 Authors' Addresses................................................7 87 Intellectual Property Statement...................................8 89 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 90 2010 92 Disclaimer of Validity............................................8 94 1. Introduction 96 The documents [WSON-Frame, WSON-Info, RWA-Encode] explain how to 97 extend the wavelength switched optical network (WSON) control plane 98 to allow both multiple WSON signal types and common hybrid electro 99 optical systems as well hybrid systems containing optical switching 100 and electro-optical resources. In WSON, not all of the optical 101 signals in the network are compatible with all network elements 102 participating in the network. Therefore, signal compatibility is an 103 important constraint in path computation in a WSON. 105 This document provides GMPLS OSPF routing enhancements to support 106 signal compatibility constraints associated with general WSON network 107 elements. These routing enhancements are required in common optical 108 or hybrid electro-optical networks where not all of the optical 109 signals in the network are compatible with all network elements 110 participating in the network. 112 This compatibility constraint model is applicable to common optical 113 or hybrid electro optical systems such as OEO switches, regenerators, 114 and wavelength converters since such systems can be limited to 115 processing only certain types of WSON signals. 117 1.1. Revision History 119 From 00 to 01: The details of the encodings for compatibility moved 120 from this document to [RWA_Encode]. 122 From 01 to 02: Editorial changes. 124 2. Compatibility and Accessibility Sub-TLVs 126 The encodings described in [RWA-Encode] involve node level 127 properties, rather than link level, and hence belong in an 128 appropriate node oriented top level TLV. The OSPF TE LSA node 129 attribute TLV of [OSPF-Node] is used for this purpose. 131 This document defines four OSPF TE LSA node attribute sub-TLVs based 132 on the encodings in [RWA-Encode]: 134 Sub-TLV Type Length Name 136 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 137 2010 139 TBA variable Resource Block Information 140 TBA variable Resource Block Accessibility 141 TBA variable Resource Block Wavelength Constraints 142 TBA variable Resource Block Pool State 144 The detail encodings of these sub-TLVs are found in [RWA-Encode] as 145 indicated in the table below. 147 Name Section[RWA-Encode] 148 Resource Block Information 5.1 149 Resource Block Accessibility 4.1 150 Resource Block Wavelength Constraints 4.2 151 Resource Block Pool State 4.3 153 Among the sub-TLVs defined above, the Resource Block Pool State sub- 154 TLV is dynamic in nature while the rest are static. As such, it will 155 be separated out from the rest and make use of multiple TE LSA 156 instances per source, per RFC3630 multiple instance capability. 158 2.1. Resource Block Information sub-TLV 160 There are seven nested sub-TLVs defined in the Resource Block 161 Information sub-TLV. 163 Sub-TLV Type Length Name 165 TBA variable Input Modulation Format List 166 TBA variable Input FEC Type List 167 TBA variable Input Bit Range List 168 TBA variable Input Client Signal List 169 TBA variable Processing Capability List 170 TBA variable Output Modulation Format List 171 TBA variable Output FEC Type List 173 The detail encodings of these sub-TLVs are found in [RWA-Encode] as 174 indicated in the table below. 176 Name Section[RWA-Encode] 178 Input Modulation Format List 5.2 179 Input FEC Type List 5.3 180 Input Bit Range List 5.4 181 Input Client Signal List 5.5 183 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 184 2010 186 Processing Capability List 5.6 187 Output Modulation Format List 5.7 188 Output FEC Type List 5.8 190 3. Security Considerations 192 This document does not introduce any further security issues other 193 than those discussed in [RFC 3630], [RFC 4203]. 195 4. IANA Considerations 197 According to [RFC3630], the OSPF TE LSA and Types for sub-TLVs for 198 each top level Types must be assigned by Expert Review, and must be 199 registered with IANA. 201 IANA is requested to allocate new Types for the sub-TLVs as defined 202 in Sections 2 and 2.1 as follows: 204 4.1. Node Information 206 This document introduces the following sub-TLVs of Node Attribute TLV 207 (Value TBD, see [OSPF-Node]) 209 Sub-TLV Type Length Name 211 TBA variable Resource Block Information 212 TBA variable Resource Block Accessibility 213 TBA variable Resource Block Wavelength Constraints 214 TBA variable Resource Block Pool State 216 Sub-TLV Type Length Name 218 TBA variable Input Modulation Format List 219 TBA variable Input FEC Type List 220 TBA variable Input Bit Range List 221 TBA variable Input Client Signal List 222 TBA variable Processing Capability List 223 TBA variable Output Modulation Format List 224 TBA variable Output FEC Type List 226 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 227 2010 228 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 229 2010 231 5. References 233 5.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 239 (GMPLS) Signaling Functional Description", RFC 3471, 240 January 2003. 242 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 243 Engineering (TE) Extensions to OSPF Version 2", RFC 244 3630, September 2003. 246 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 247 applications: DWDM frequency grid", June, 2002. 249 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 250 in Support of Generalized Multi-Protocol Label Switching 251 (GMPLS)", RFC 4202, October 2005 253 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 254 Support of Generalized Multi-Protocol Label Switching 255 (GMPLS)", RFC 4203, October 2005. 257 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 258 Switching (GMPLS) Signaling Extensions for G.709 Optical 259 Transport Networks Control", RFC 4328, January 2006. 261 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 262 in Support of Generalized Multi-Protocol Label Switching 263 (GMPLS)", RFC 5307, October 2008. 265 [OSPF-Node] R. Aggarwal and K. Kompella, "Advertising a Router's 266 Local Addresses in OSPF TE Extensions", draft-ietf-ospf- 267 te-node-addr, work in progress. 269 [Lambda-Labels] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, 270 "Generalized Labels for G.694 Lambda-Switching 271 Capable Label Switching Routers", draft-ietf-ccamp- 272 gmpls-g-694-lambda-labels, work in progress. 274 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 275 2010 277 [WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 278 and PCE Control of Wavelength Switched Optical 279 Networks", draft-ietf-ccamp-rwa-WSON-Framework, work in 280 progress. 282 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 283 Wavelength Assignment Information Model for Wavelength 284 Switched Optical Networks", draft-ietf-ccamp-rwa-info 285 work in progress. 287 [RWA-Encode]G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 288 Wavelength Assignment Information Encoding for 289 Wavelength Switched Optical Networks", draft-ietf- 290 ccamp-rwa-wson-encode, work in progress. 292 6. Contributors 294 Authors' Addresses 296 Young Lee (ed.) 297 Huawei Technologies 298 1700 Alma Drive, Suite 100 299 Plano, TX 75075 300 USA 302 Phone: (972) 509-5599 (x2240) 303 Email: ylee@huawei.com 305 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 306 2010 308 Greg M. Bernstein (ed.) 309 Grotto Networking 310 Fremont California, USA 312 Phone: (510) 573-2237 313 Email: gregb@grotto-networking.com 315 Intellectual Property Statement 317 The IETF Trust takes no position regarding the validity or scope of 318 any Intellectual Property Rights or other rights that might be 319 claimed to pertain to the implementation or use of the technology 320 described in any IETF Document or the extent to which any license 321 under such rights might or might not be available; nor does it 322 represent that it has made any independent effort to identify any 323 such rights. 325 Copies of Intellectual Property disclosures made to the IETF 326 Secretariat and any assurances of licenses to be made available, or 327 the result of an attempt made to obtain a general license or 328 permission for the use of such proprietary rights by implementers or 329 users of this specification can be obtained from the IETF on-line IPR 330 repository at http://www.ietf.org/ipr 332 The IETF invites any interested party to bring to its attention any 333 copyrights, patents or patent applications, or other proprietary 334 rights that may cover technology that may be required to implement 335 any standard or specification contained in an IETF Document. Please 336 address the information to the IETF at ietf-ipr@ietf.org. 338 Disclaimer of Validity 340 All IETF Documents and the information contained therein are provided 341 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 342 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 343 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 344 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 345 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 346 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 347 FOR A PARTICULAR PURPOSE. 349 Internet-Draft OSPF Enhancement for WSON Signal Compatibility September 350 2010 352 Acknowledgment 354 Funding for the RFC Editor function is currently provided by the 355 Internet Society.