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