idnits 2.17.1 draft-li-ccamp-imp-feedback-signaling-00.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Once the egress node has collected all the impairment information, it MUST decide whether to configure the involved nodes along the path to establish the LSP after calculation. The calculation procedure can be referred to [G.680] and [G.sup39]. The egress node finds that only if some parameters have been configured, the selected wavelength label can satisfy the impairment requirement. A reliable message MUST be used to configure the parameter to the specified nodes. So, a newly defined object named Configuration Route Object (CRO) is introduced in the Resv message to configure the involved nodes in the path. This object MUST include the specified node address and calculated parameter values. The process procedure of the CRO object is the same as the Label object that the Resv message MUST not be passed to the next hop unless the configuration is done. The format of the CRO object is illustrated in figure 3. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o The ingress node first checks out the wavelength usage information on the outgoing interface, and fills the available wavelength in the Label set object in the path message. Then it records the configurable parameters in the extended RRO object including (modulation format ,FEC, power, attenuation, etc.). The accumulated four approximated impairment parameters (OSNR, CD, PMD, XT) with the default parameters can be carried in the LSP required attribute object as described in [I-D.martinelli-ccamp-optical-imp-signaling]. o The transit nodes check their own available wavelength on the outgoing interfaces and prune the Label set object. Then update the four accumulated impairment parameters with the default parameters respectively. The control plane will inspect that if these nodes have any configurable parameters, if they do (For example, the channel attenuation can be adjusted), the parameters will be recorded to the RRO object as mentioned in section. o Once the egress node has received the path message, it will firstly check if there are any available labels that satisfy the wavelength continuity constraints. If there exist available wavelengths and the corresponding optical impairment is acceptable, the process procedure of the Resv message is the similar to [I-D.martinelli-ccamp-optical-imp-signaling]. The egress node SHOULD select the local transponders of the node and choose the wavelength in the label object, and signal type (modulation, FEC) in the CRO object respectively in the Resv message. If the egress node finds that there are available wavelengths only when some impairment parameters are adjusted among certain nodes, the calculated parameters to satisfy the impairment validation requirment were put in the CRO object carried by Resv message to configure the involved network element among the path. It is worth to note that which nodes and parameters are going to be configured is due to the egress's local policy, that is to say, not every configurable node MUST be configured. o Once received the Resv message, the transit nodes will check the CRO object if they need some parameter configuration. If they need, the Resv message MUST not be transferred to the next hop unless the selected wavelength cross-connection and parameter configuration have been finished. o The ingress node finally choose the selected wavelength, and signal type to the local transponder and checks if there are any parameters need to be configured according to the CRO Object. Once the wavelength cross-connection and the parameter configuration process are done, the LSP has been successfully established. -- The document date (March 7, 2011) is 4798 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'G.680' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.sup39' ** Downref: Normative reference to an Informational RFC: RFC 5920 == Outdated reference: A later version (-06) exists of draft-bernstein-wson-impairment-info-03 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-wson-impairments-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Li, Ed. 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track March 7, 2011 5 Expires: September 8, 2011 7 RSVP-TE Extensions in Support of Distributed Impairment Validation with 8 Feedback Control 9 draft-li-ccamp-imp-feedback-signaling-00 11 Abstract 13 The impairment validation of the light path in a Wavelength Switched 14 Optical Network (WSON) can be implemented with a distributed hop by 15 hop process by signaling protocol. This memo proposes feedback 16 control of some parameters related to impairment evaluation results 17 with the extensions to the Resource Reservation Traffic Engineering 18 (RSVP-TE) signaling protocol in order to establish an optical path 19 with a higher probability. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 8, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. RSVP-TE extensions . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Procedure for distributed impairment validation . . . . . . . 7 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 9.1. Normative references . . . . . . . . . . . . . . . . . . . 8 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 WSON technology was deployed to provide an end to end optical path 71 that can be used to carry client signals transparently. From the 72 perspective of control plane, the light path provision needs to 73 resolve the problems including routing, wavelength assignment (WA) 74 and impairment validation (IV). As detailed in 75 [I-D.ietf-ccamp-wson-impairments], there are three main frameworks to 76 resolve these problems: 1 Combined Routing, WA and IV; 2 Separated 77 routing, WA or IV; 3 Distributed WA and/or IV. Among the three 78 processes, distributed WA and/or IV can eliminate the need to 79 distributed wavelength availability and impairment characteristics of 80 network elements and links via routing protocols or other means. The 81 approach of distributed process can be accomplished by extending to 82 the RSVP-TE signaling protocol of [RFC3471] and [RFC3473] to collect 83 the accumulated impairment parameters hop by hop and validated the 84 available wavelgnth at the egress node. The examples of such an 85 approach can be found in [I-D.martinelli-ccamp-optical-imp-signaling] 86 and [I-D.agraz-ccamp-wson-impairment-rsvp]. 88 However, in these scenarios, the ingress and transit nodes do not 89 know the detailed impairment parameters of other nodes at first, so 90 the establishment of the LSP by such an approach may suffer a much 91 higher blocking probability. 93 In this memo we propose feedback control of some parameters related 94 to impairment evaluation results so as to provide a relatively higher 95 probability in setting up a LSP. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 3. Motivation 105 According to ITU-T recommendation [G.680]and 106 [I-D.bernstein-wson-impairment-info], the performance of an optical 107 network is subjected to several parameters including optical signal 108 noise ratio (OSNR), chromatic dispersion (CD), polarization mode 109 dispersion (PMD), cross talk (XT) (considering the approximated 110 impairment estimation situation ). Besides, the impairment tolerance 111 has a close connection with the signal bit-rate, modulation format 112 and Forwarding Error Code (FEC) used in the path. 114 For a point to point lambda connection in WSON, the channel power, 115 modulation format, FEC, dispersion compensation (electronic 116 dispersion compensate technology) may be configured in the ingress 117 and egress nodes. And in the passive transit nodes without 3R or 118 wavelength conversion, the channel power may be adjusted, while in 119 the active transit nodes, the parameters mentioned above as in the 120 ingress or egress ends may also be configured. According to [G.680], 121 adjusting the optical channel power will contribute to significant 122 change of OSNR. It is demonstrated that the channel (corresponding 123 to a wavelength) power of the transmitter can be configured by 124 adjusting the laser's current of the ingress node and the channel 125 attenuation at the others. Then adjusting the channel pre/post 126 electronic dispersion compensation of the transmitter or receiver 127 respectively will change the total dispersion tolerance. While, in 128 the 100G and above or future ultra-wideband network, per channel CD, 129 PMD passive compensation on all nodes may be able to be deployed to 130 further solve the dispersion tolerance. The selection of all the 131 parameters mentioned above spread in the network elements will have a 132 direct impact on the impairment validation results. 134 However, in the existing distributed WA and IV schemes, these 135 parameters are not mentioned to be configured in signaling which have 136 an implication of system-default value. As the situation of every 137 LSP's setup can be so different that these system-default or previous 138 defined parameters may lead to a relative higher blocking probability 139 in impairment validation. Hence, a new signaling procedure is 140 introduced to record the parameters that is configurable in the Path 141 message and carry out feedback control in the Resv message leading to 142 a higher probability in establishing the LSP. 144 4. RSVP-TE extensions 146 In order to realize feedback control of the parameters, a variable 147 impairment sub-TLV and a Configuration Route Object (CRO) are defined 148 in the Path and Resv message respectively. In the signaling 149 procedure, the egress node needs to know which nodes among the path 150 to be configured after collecting all the impairment information, so 151 the configurable node and interface addresses MUST be known. 152 [RFC3209] has defined the Record Route Object (RRO) to record the 153 attribute of the node and corresponding interface when establishing a 154 new LSP. This document extended the application of this object by 155 including a variable impairment sub-TLV to carry the configurable 156 parameters along the path. The format of the variable impairment sub 157 TLV is illustrated in figure 1: 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Componet Type | Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Wavelength label | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 // Parameters Sub sub-TLVs // 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 figure 1: variable impairment sub-TLV 173 The newly defined variable impairment sub-TLV SHOULD be nested in the 174 RRO object after the corresponding node and interface address. More 175 than one variable impairment sub-TLV is allowed if there are multiple 176 components can be configured at the node. 178 Component type: indicated the type of network element in the node, 179 such as transmitter, receiver amplifier, attenuator, dispersion 180 compensator or else. 182 Length: the Length contains the total length of the subobject in 183 bytes. The length MUST be at least 4, and MUST be a multiple of 4. 185 Wavelength Label: this field indicated which channel the signal was 186 about to be carried on. The carried impairment related parameters 187 SHOULD be configured in the single channel or single wavelength to 188 avoid impact on other tunnels/LSP. 190 Parameter sub-sub tlv: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Parameter type | Length | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Parameter Value default | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 // Parameter range // 201 | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 figure 2: Parameters sub-sub-TLV 206 Parameter type: this field defines the configurable impairment 207 parameter type. Including power, modulation format, FEC, amount of 208 attenuation , amount of dispersion compensation (including CD and 209 PMD), etc. 211 Default parameter: this field defines the system-default or pevious 212 defined values of the impairment related parameters. This filed 213 might be OPTIONAL with the parameter type of modulation format and 214 FEC. 216 Parameter value range: defines the available capacity of the 217 parameter type. For signal, this filed SHOULD be a category of 218 supported modulation format and FEC type, Whiel for 219 powerGBP[not]attenuation, CD or PMD this filed SHOULD contain two 220 elements: the lower and the upper limit of the parameters. 222 Once the egress node has collected all the impairment information, it 223 MUST decide whether to configure the involved nodes along the path to 224 establish the LSP after calculation. The calculation procedure can 225 be referred to [G.680] and [G.sup39]. The egress node finds that 226 only if some parameters have been configured, the selected wavelength 227 label can satisfy the impairment requirement. A reliable message 228 MUST be used to configure the parameter to the specified nodes. So, 229 a newly defined object named Configuration Route Object (CRO) is 230 introduced in the Resv message to configure the involved nodes in the 231 path. This object MUST include the specified node address and 232 calculated parameter values. The process procedure of the CRO object 233 is the same as the Label object that the Resv message MUST not be 234 passed to the next hop unless the configuration is done. The format 235 of the CRO object is illustrated in figure 3. 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 | Type | Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Node & Interface address sub-TLV | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | 245 // Variable impairment sub-TLVs // 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 figure 3: Paramete sub-sub-TLV 251 The structure of the CRO object is similar to the extended RRO object 252 including the node & interface address and Variable impairment 253 congigure sub-TLV (shown in figure 1 which alse contains the 254 parameter sub-sub TLVs). However, the specified feedback parameter 255 value replaces the system default value in the parameter sub-sub TLV, 256 while the paramter range SHOULD be omitted. 258 5. Procedure for distributed impairment validation 260 This section details the distributed wavelength assignment and 261 impairment validation with the extended RSVP-TE signaling mentioned 262 in this doucoment by the following procedure: 264 o The ingress node first checks out the wavelength usage information 265 on the outgoing interface, and fills the available wavelength in 266 the Label set object in the path message. Then it records the 267 configurable parameters in the extended RRO object including 268 (modulation format ,FEC, power, attenuation, etc.). The 269 accumulated four approximated impairment parameters (OSNR, CD, 270 PMD, XT) with the default parameters can be carried in the LSP 271 required attribute object as described in 272 [I-D.martinelli-ccamp-optical-imp-signaling]. 273 o The transit nodes check their own available wavelength on the 274 outgoing interfaces and prune the Label set object. Then update 275 the four accumulated impairment parameters with the default 276 parameters respectively. The control plane will inspect that if 277 these nodes have any configurable parameters, if they do (For 278 example, the channel attenuation can be adjusted), the parameters 279 will be recorded to the RRO object as mentioned in section. 280 o Once the egress node has received the path message, it will 281 firstly check if there are any available labels that satisfy the 282 wavelength continuity constraints. If there exist available 283 wavelengths and the corresponding optical impairment is 284 acceptable, the process procedure of the Resv message is the 285 similar to [I-D.martinelli-ccamp-optical-imp-signaling]. The 286 egress node SHOULD select the local transponders of the node and 287 choose the wavelength in the label object, and signal type 288 (modulation, FEC) in the CRO object respectively in the Resv 289 message. If the egress node finds that there are available 290 wavelengths only when some impairment parameters are adjusted 291 among certain nodes, the calculated parameters to satisfy the 292 impairment validation requirment were put in the CRO object 293 carried by Resv message to configure the involved network element 294 among the path. It is worth to note that which nodes and 295 parameters are going to be configured is due to the egress's local 296 policy, that is to say, not every configurable node MUST be 297 configured. 298 o Once received the Resv message, the transit nodes will check the 299 CRO object if they need some parameter configuration. If they 300 need, the Resv message MUST not be transferred to the next hop 301 unless the selected wavelength cross-connection and parameter 302 configuration have been finished. 303 o The ingress node finally choose the selected wavelength, and 304 signal type to the local transponder and checks if there are any 305 parameters need to be configured according to the CRO Object. 306 Once the wavelength cross-connection and the parameter 307 configuration process are done, the LSP has been successfully 308 established. 310 Note that in the path message, any node that cannot recognize the 311 extended variable sub object MUST ignore it and transfer the RRO 312 object transparently. While in the Resv message, if the specify node 313 cannot recognize the CRO object or a failure in configuration MUST 314 reject the setup of the LSP and sent a ResvError message with Error 315 code "unknown object" or "CRO configuration failure". 317 6. Acknowledgements 319 7. IANA Considerations 321 A future revision of this document will present requests to IANA for 322 codepoint allocation. 324 8. Security Considerations 326 This document has no requirement for a change to the security models 327 within MPLS and GMPLS associated signaling protocols. For details of 328 the specific security measures refer to the documents that define the 329 protocols ([RFC3209], [RFC3471], [RFC3473], ). [RFC5920] provides an 330 overview of security vulnerabilities and protection mechanisms for 331 the GMPLS control plane. 333 9. References 335 9.1. Normative references 337 [G.680] International Telecommunications Union, "Physical transfer 338 functions of optical network elements", Recommendation 339 G.680, December 2007 . 341 [G.sup39] International Telecommunications Union, "Optical system 342 design and engineering considerations", Recommendation 343 G.sup39, December 2007 . 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 349 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 350 Tunnels", RFC 3209, December 2001. 352 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 353 (GMPLS) Signaling Functional Description", RFC 3471, 354 January 2003. 356 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 357 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 358 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 360 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 361 Networks", RFC 5920, July 2010. 363 9.2. Informative References 365 [I-D.agraz-ccamp-wson-impairment-rsvp] 366 Agraz, F., Ye, Y., Han, J., Saradhi, C., and A. 367 Francescon, "RSVP-TE Extensions in Support of Impairment 368 Aware Routing and Wavelength Assignment in Wavelength 369 Switched Optical Networks (WSONs)", 370 draft-agraz-ccamp-wson-impairment-rsvp-00 (work in 371 progress), October 2010. 373 [I-D.bernstein-wson-impairment-info] 374 Lee, Y., Bernstein, G., Systems, C., Martinelli, G., and 375 A. Zanardi, "Information Model for Impaired Optical Path 376 Validation", draft-bernstein-wson-impairment-info-03 (work 377 in progress), October 2010. 379 [I-D.ietf-ccamp-wson-impairments] 380 Bernstein, G., Lee, Y., Li, D., Martinelli, G., Chen, M., 381 Han, J., Galimberti, G., Tanzi, A., Bianchi, D., Kattan, 382 M., Schroetter, D., Ceccarelli, D., Bellagamba, E., and D. 383 Caviglia, "A Framework for the Control of Wavelength 384 Switched Optical Networks (WSON) with Impairments", 385 draft-ietf-ccamp-wson-impairments-04 (work in progress), 386 October 2010. 388 [I-D.martinelli-ccamp-optical-imp-signaling] 389 Martinelli, G. and A. Zanardi, "GMPLS Signaling Extensions 390 for Optical Impairment Aware Lightpath Setup", 391 draft-martinelli-ccamp-optical-imp-signaling-03 (work in 392 progress), October 2010. 394 Author's Address 396 Yao Li (editor) 397 ZTE Corporation 398 4F,RD Building 2,Zijinghua Road 399 Yuhuatai District,Nanjing 210012 400 P.R.China 402 Phone: +86 025 528778199 403 Email: li.yao3@zte.com.cn