idnits 2.17.1 draft-ietf-ccamp-wson-signaling-04.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 == Line 298 has weird spacing: '...ards to speci...' -- The document date (October 22, 2012) is 4203 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: 'ASSOC-ext' is mentioned on line 363, but not defined == Unused Reference: 'RFC2578' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'WSON-CompOSPF' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'Winzer06' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'G.959.1' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'G.694.1' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'G.694.2' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'G.Sup43' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC4427' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'ASSOC-Ext' is defined on line 531, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-rwa-wson-encode-18 -- No information found for draft-lee-ccamp-wson-signal-compatibility-OSPF - is the name correct? == Outdated reference: A later version (-24) exists of draft-ietf-ccamp-rwa-info-16 == Outdated reference: A later version (-03) exists of draft-ietf-ccamp-assoc-info-00 -- No information found for draft-zhang-mpls-tp-rsvp-te-ext-associated-lsp - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Bernstein 2 Internet Draft Grotto Networking 3 Intended status: Standards Track Sugang Xu 4 NICT 5 Expires: April 2013 Y.Lee 6 Huawei 7 G. Martinelli 8 Cisco 9 Hiroaki Harai 10 NICT 12 October 22, 2012 14 Signaling Extensions for Wavelength Switched Optical Networks 15 draft-ietf-ccamp-wson-signaling-04.txt 17 Abstract 19 This memo provides extensions to Generalized Multi-Protocol Label 20 Switching (GMPLS) signaling for control of wavelength switched 21 optical networks (WSON). Such extensions are necessary in WSONs 22 under a number of conditions including: (a) when optional 23 processing, such as regeneration, must be configured to occur at 24 specific nodes along a path, (b) where equipment must be configured 25 to accept an optical signal with specific attributes, or (c) where 26 equipment must be configured to output an optical signal with 27 specific attributes. In addition this memo provides mechanisms to 28 support distributed wavelength assignment with bidirectional LSPs, 29 and choice in distributed wavelength assignment algorithms. These 30 extensions build on previous work for the control of lambda and 31 G.709 based networks. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with 36 the provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six 44 months and may be updated, replaced, or obsoleted by other documents 45 at any time. It is inappropriate to use Internet-Drafts as 46 reference material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 This Internet-Draft will expire on April 22, 2007. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with 65 respect to this document. Code Components extracted from this 66 document must include Simplified BSD License text as described in 67 Section 4.e of the Trust Legal Provisions and are provided without 68 warranty as described in the Simplified BSD License. 70 Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 Table of Contents 78 1. Introduction...................................................3 79 2. Terminology....................................................3 80 3. Requirements for WSON Signaling................................4 81 3.1. WSON Signal Characterization..............................4 82 3.2. Per LSP Network Element Processing Configuration..........5 83 3.3. Bi-Directional WSON LSPs..................................5 84 3.4. Distributed Wavelength Assignment Support.................6 85 3.5. Out of Scope..............................................6 86 4. WSON Signal Traffic Parameters, Attributes and Processing......6 87 4.1. Traffic Parameters for Optical Tributary Signals..........6 88 4.2. Signal Attributes and Processing..........................7 89 4.2.1. WSON Processing Object Encoding......................8 90 5. Bidirectional Lightpath Setup..................................8 91 6. RWA Related....................................................9 92 6.1. Wavelength Assignment Method Selection....................9 93 7. Security Considerations.......................................10 94 8. IANA Considerations...........................................10 95 9. Acknowledgments...............................................10 96 10. References...................................................11 97 10.1. Normative References....................................11 98 10.2. Informative References..................................11 99 Author's Addresses...............................................14 100 Intellectual Property Statement..................................15 101 Disclaimer of Validity...........................................16 103 1. Introduction 105 This memo provides extensions to Generalized Multi-Protocol Label 106 Switching (GMPLS) signaling for control of wavelength switched 107 optical networks (WSON). Fundamental extensions are given to permit 108 simultaneous bi-directional wavelength assignment while more 109 advanced extensions are given to support the networks described in 110 [RFC6163] which feature connections requiring configuration of 111 input, output, and general signal processing capabilities at a node 112 along a LSP. 114 These extensions build on previous work for the control of lambda 115 and G.709 based networks. 117 2. Terminology 119 CWDM: Coarse Wavelength Division Multiplexing. 121 DWDM: Dense Wavelength Division Multiplexing. 123 FOADM: Fixed Optical Add/Drop Multiplexer. 125 ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port 126 count wavelength selective switching element featuring ingress and 127 egress line side ports as well as add/drop side ports. 129 RWA: Routing and Wavelength Assignment. 131 Wavelength Conversion/Converters: The process of converting an 132 information bearing optical signal centered at a given wavelength to 133 one with "equivalent" content centered at a different wavelength. 134 Wavelength conversion can be implemented via an optical-electronic- 135 optical (OEO) process or via a strictly optical process. 137 WDM: Wavelength Division Multiplexing. 139 Wavelength Switched Optical Networks (WSON): WDM based optical 140 networks in which switching is performed selectively based on the 141 center wavelength of an optical signal. 143 AWG: Arrayed Waveguide Grating. 145 OXC: Optical Cross Connect. 147 Optical Transmitter: A device that has both a laser tuned on certain 148 wavelength and electronic components, which converts electronic 149 signals into optical signals. 151 Optical Responder: A device that has both optical and electronic 152 components. It detects optical signals and converts optical signals 153 into electronic signals. 155 Optical Transponder: A device that has both an optical transmitter 156 and an optical responder. 158 Optical End Node: The end of a wavelength (optical lambdas) 159 lightpath in the data plane. It may be equipped with some 160 optical/electronic devices such as wavelength 161 multiplexers/demultiplexer (e.g. AWG), optical transponder, etc., 162 which are employed to transmit/terminate the optical signals for 163 data transmission. 165 3. Requirements for WSON Signaling 167 The following requirements for GMPLS based WSON signaling are in 168 addition to the functionality already provided by existing GMPLS 169 signaling mechanisms. 171 3.1. WSON Signal Characterization 173 WSON signaling MUST convey sufficient information characterizing the 174 signal to allow systems along the path to determine compatibility 175 and perform any required local configuration. Examples of such 176 systems include intermediate nodes (ROADMs, OXCs, Wavelength 177 converters, Regenerators, OEO Switches, etc...), links (WDM systems) 178 and end systems (detectors, demodulators, etc...). The details of 179 any local configuration processes are out of the scope of this 180 document. 182 From [RFC6163] we have the following list of WSON signal 183 characteristic information: 185 List 1. WSON Signal Characteristics 187 1. Optical tributary signal class (modulation format). 188 2. FEC: whether forward error correction is used in the digital 189 stream and what type of error correcting code is used 190 3. Center frequency (wavelength) 191 4. Bit rate 192 5. G-PID: General Protocol Identifier for the information format 194 The first three items on this list can change as a WSON signal 195 traverses a network with regenerators, OEO switches, or wavelength 196 converters. These parameters are summarized in the Optical Interface 197 Class as defined in the [WSON-Info] and the assumption is that a 198 class always includes signal compatibility information. 199 An ability to control wavelength conversion already exists in GMPLS 200 signaling along with the ability to share client signal type 201 information (G-PID). In addition, bit rate is a standard GMPLS 202 signaling traffic parameter. It is referred to as Bandwidth Encoding 203 in [RFC3471]. 205 3.2. Per LSP Network Element Processing Configuration 207 In addition to configuring a network element (NE) along an LSP to 208 input or output a signal with specific attributes, we may need to 209 signal the NE to perform specific processing, such as 3R 210 regeneration, on the signal at a particular NE. In [RFC6163] we 211 discussed three types of processing not currently covered by GMPLS: 213 (A) Regeneration (possibly different types) 215 (B) Fault and Performance Monitoring 217 (C) Attribute Conversion 219 The extensions here MUST provide for the configuration of these 220 types of processing at nodes along an LSP. 222 3.3. Bi-Directional WSON LSPs 224 WSON signaling MAY support LSP setup consistent with the wavelength 225 continuity constraint for bi-directional connections. The following 226 cases MAY be separately supported: 228 (a) Where the same wavelength is used for both upstream and 229 downstream directions 231 (b) Where different wavelengths can be used for both upstream and 232 downstream directions. 234 This document will review current GMPLS bidirectional solutions 235 according to WSON case. 237 3.4. Distributed Wavelength Assignment Support 239 WSON signaling MAY support the selection of a specific distributed 240 wavelength assignment method. 242 This method is beneficial in cases of equipment failure, etc., where 243 fast provisioning used in quick recovery is critical to protect 244 carriers/users against system loss. This requires efficient 245 signaling which supports distributed wavelength assignment, in 246 particular when the centralized wavelength assignment capability is 247 not available. 249 As discussed in the [RFC6163] different computational approaches for 250 wavelength assignment are available. One method is the use of 251 distributed wavelength assignment. This feature would allow the 252 specification of a particular approach when more than one is 253 implemented in the systems along the path. 255 3.5. Out of Scope 257 This draft does not address signaling information related to optical 258 impairments. 260 4. WSON Signal Traffic Parameters, Attributes and Processing 262 As discussed in [RFC6163] single channel optical signals used in 263 WSONs are called "optical tributary signals" and come in a number of 264 classes characterized by modulation format and bit rate. Although 265 WSONs are fairly transparent to the signals they carry, to ensure 266 compatibility amongst various networks devices and end systems it 267 can be important to include key lightpath characteristics as traffic 268 parameters in signaling [RFC6163]. 270 4.1. Traffic Parameters for Optical Tributary Signals 272 In [RFC3471] we see that the G-PID (client signal type) and bit rate 273 (byte rate) of the signals are defined as parameters and in 275 [RFC3473] they are conveyed Generalized Label Request object and the 276 RSVP SENDER_TSPEC/FLOWSPEC objects respectively. 278 4.2. Signal Attributes and Processing 280 Section 3.2. gave the requirements for signaling to indicate to a 281 particular NE along an LSP what type of processing to perform on an 282 optical signal or how to configure that NE to accept or transmit an 283 optical signal with particular attributes. 285 One way of accomplishing this is via a new EXPLICIT_ROUTE subobject. 286 Reference [RFC3209] defines the EXPLICIT_ROUTE object (ERO) and a 287 number of subobjects, while reference [RFC5420] defines general 288 mechanisms for dealing with additional LSP attributes. Although 289 reference [RFC5420] defines a RECORD_ROUTE object (RRO) attributes 290 subobject, it does not define an ERO subobject for LSP attributes. 292 Regardless of the exact coding for the ERO subobject conveying the 293 input, output, or processing instructions. This new "processing" 294 subobject would follow a subobject containing the IP address, or the 295 interface identifier [RFC3477], associated with the link on which it 296 is to be used along with any label subobjects [RFC3473]. 298 In regards to specific information required, the [WSON-Encode] 299 already provides all necessary definitions and encoding. In 300 particular the Resource block information sub-TLV which contains, 301 among others, a list of available Optical Interface Classes and 302 processing capabilities. 304 The WSON Signal Processing object is defined as an LSP_ATTRIBUTES 305 and extends the PATH message. It is defined as the following: 307 ::= 309 Where: 311 is the object defined in Section 5.1 of [WSON- 312 Encode]. 314 This is the only sub-TLV available within the . 315 Only one object MUST be present. 317 4.2.1. WSON Processing Object Encoding 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | | 325 ~ Value ~ 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Type: to be defined by IANA 331 Value: sub-TLVS according to section 4.1. 333 5. Bidirectional Lightpath Setup 335 With the wavelength continuity constraint in CI-incapable [RFC3471] 336 WSONs, where the nodes in the networks cannot support wavelength 337 conversion, the same wavelength on each link along a unidirectional 338 lightpath should be reserved. In addition to the wavelength 339 continuity constraint, requirement 3.3 gives us another constraint 340 on wavelength usage in data plane, in particular, it requires the 341 same wavelength to be used in both directions. [RFC6163] in section 342 6.1 reports on the implication to GMPLS signaling related to both 343 bi-directionality and Distributed Wavelengths Assignment. 345 Current GMPLS solution defines a bidirectional LSP (as defined by 346 [RFC3471]). The label distribution is based on Label_Set and 347 Upstream_Label objects. In case of specific constraints such as the 348 same wavelengths in both directions, it may require several 349 signaling attempts using information from the Acceptable_Label_Set 350 received from path error messages. Since this mechanism is currently 351 available and proven to work, no additional extensions are needed 352 for WSON. Potential optimizations are left for further studies. 354 The usage of object for the bidirectional case is 355 the same as per unidirectional. When an intermediate node uses 356 information from this object to instruct a node about wavelength 357 regeneration, the same information applies to both downstream and 358 upstream directions. 360 Some implementations may prefer using two unidirectional LSPs. This 361 solution has been always available as per [RFC3209] however recent 362 work introduces the association concept [RFC4872] and [ASSOC-Info]. 363 Recent transport evolutions [ASSOC-ext] provide a way to associate 364 two unidirectional LSPs as a bidirectional LSP. In line with this, a 365 small extension can make this approach work for the WSON case. 367 6. RWA Related 369 6.1. Wavelength Assignment Method Selection 371 Routing + Distributed wavelength assignment (R+DWA) is one of the 372 options defined by the [RFC6163]. The output from the routing 373 function will be a path but the wavelength will be selected on a 374 hop-by-hop basis. 376 Under this hypothesis the node initiating the signaling process 377 needs to declare its own wavelength availability (through a 378 label_set object). Each intermediate node may delete some labels due 379 to connectivity constraints or its own assignment policy. At the 380 end, the destination node has to make the final decision on the 381 wavelength assignment among the ones received through the signaling 382 process. 384 As discussed in [HZang00] a number of different wavelength 385 assignment algorithms maybe employed. In addition as discussed in 386 [RFC6163] the wavelength assignment can be either for a 387 unidirectional lightpath or for a bidirectional lightpath 388 constrained to use the same lambda in both directions. 390 A simple TLV could be used to indication wavelength assignment 391 directionality and wavelength assignment method. This would be 392 placed in an LSP_REQUIRED_ATTRIBUTES object per [RFC5420]. The use 393 of a TLV in the LSP required attributes object was pointed out in 394 [Xu]. 396 [TO DO: The directionality stuff needs to be reconciled with the 397 earlier material] 399 Unique Wavelength: 0 same wavelength in both directions, 1 may use 400 different wavelengths [TBD: shall we use only 1 bit] 401 Wavelength Assignment Method: 0 unspecified (any), 1 First-Fit, 2 402 Random, 3 Least-Loaded (multi-fiber). Others TBD. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Unique WL | WA Method | Reserved | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 7. Security Considerations 412 This document has no requirement for a change to the security models 413 within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE, 414 and PCEP security models could be operated unchanged. 416 However satisfying the requirements for RWA using the existing 417 protocols may significantly affect the loading of those protocols. 418 This makes the operation of the network more vulnerable to denial of 419 service attacks. Therefore additional care maybe required to ensure 420 that the protocols are secure in the WSON environment. 422 Furthermore the additional information distributed in order to 423 address the RWA problem represents a disclosure of network 424 capabilities that an operator may wish to keep private. 425 Consideration should be given to securing this information. 427 8. IANA Considerations 429 TBD. Once finalized in our approach we will need identifiers for 430 such things and modulation types, modulation parameters, wavelength 431 assignment methods, etc... 433 9. Acknowledgments 435 Authors would like to thanks Lou Berger and Cyril Margaria for 436 comments and suggestions. 438 10. References 440 10.1. Normative References 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, March 1997. 445 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 446 "Structure of Management Information Version 2 (SMIv2)", 447 STD 58, RFC 2578, April 1999. 449 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 450 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 451 Tunnels", RFC 3209, December 2001. 453 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 454 (GMPLS) Signaling Functional Description", RFC 3471, 455 January 2003. 457 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 458 Switching (GMPLS) Signaling Resource ReserVation Protocol- 459 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 460 January 2003. 462 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 463 in Resource ReSerVation Protocol - Traffic Engineering 464 (RSVP-TE)", RFC 3477, January 2003. 466 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. 467 Ayyangar, " Encoding of Attributes for MPLS LSP 468 Establishment Using Resource Reservation Protocol Traffic 469 Engineering (RSVP-TE)", RFC 5420, February 2006. 471 [WSON-Encode] Bernstein G., Lee Y., Li D., and W. Imajuku, "Routing 472 and Wavelength Assignment Information Encoding for 473 Wavelength Switched Optical Networks", draft-ietf-ccamp- 474 rwa-wson-encode-18 (work in progress), September 2012. 476 10.2. Informative References 478 [WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal 479 and Network Element Compatibility for Wavelength Switched 480 Optical Networks", work in progress: draft-lee-ccamp-wson- 481 signal-compatibility-OSPF. 483 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 484 and PCE Control of Wavelength Switched Optical Networks", 485 work in progress: draft-bernstein-ccamp-wavelength- 486 switched-03.txt, February 2008. 488 [WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 489 Wavelength Assignment Information Model for Wavelength 490 Switched Optical Networks", work in progress: draft-ietf- 491 ccamp-rwa-info-16, September 2012. 493 [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing 494 and wavelength assignment approaches for wavelength-routed 495 optical WDM networks", Optical Networks Magazine, January 496 2000. 498 [Xu] S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE 499 for Bidirectional Lightpath the Same Wavelength", work in 500 progress: draft-xu-rsvpte-bidir-wave-01, November 2007. 502 [Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced 503 Optical Modulation Formats", Proceedings of the IEEE, vol. 504 94, no. 5, pp. 952-985, May 2006. 506 [G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network 507 Physical Layer Interfaces, March 2006. 509 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 510 applications: DWDM frequency grid, June 2002. 512 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 513 applications: CWDM wavelength grid, December 2003. 515 [G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R 516 in optical transport networks (OTN), November 2006. 518 [RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery 519 (Protection and Restoration) Terminology for Generalized 520 Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 521 2006. 523 [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE 524 Extensions in Support of End-to-End Generalized Multi- 525 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 527 [ASSOC-Info] Berger, L., Faucheur, F., and A. Narayanan, "Usage of 528 The RSVP Association Object", draft-ietf-ccamp-assoc-info- 529 00 (work in progress), October 2010. 531 [ASSOC-Ext] Zhang, F., Jing, R., "RSVP-TE Extension to Establish 532 Associated Bidirectional LSP", draft-zhang-mpls-tp-rsvp- 533 te-ext-associated-lsp-03 (work in progress), February 534 2011. 536 Author's Addresses 538 Greg M. Bernstein (editor) 539 Grotto Networking 540 Fremont California, USA 542 Phone: (510) 573-2237 543 Email: gregb@grotto-networking.com 545 Nicola Andriolli 546 Scuola Superiore Sant'Anna, Pisa, Italy 547 Email: nick@sssup.it 549 Alessio Giorgetti 550 Scuola Superiore Sant'Anna, Pisa, Italy 551 Email: a.giorgetti@sssup.it 553 Lin Guo 554 Key Laboratory of Optical Communication and Lightwave Technologies 555 Ministry of Education 556 P.O. Box 128, Beijing University of Posts and Telecommunications, 557 P.R.China 558 Email: guolintom@gmail.com 560 Hiroaki Harai 561 National Institute of Information and Communications Technology 562 4-2-1 Nukui-Kitamachi, Koganei, 563 Tokyo, 184-8795 Japan 565 Phone: +81 42-327-5418 566 Email: harai@nict.go.jp 568 Yuefeng Ji 569 Key Laboratory of Optical Communication and Lightwave Technologies 570 Ministry of Education 571 P.O. Box 128, Beijing University of Posts and Telecommunications, 572 P.R.China 573 Email: jyf@bupt.edu.cn 575 Daniel King 576 Old Dog Consulting 578 Email: daniel@olddog.co.uk 580 Young Lee (editor) 581 Huawei Technologies 582 1700 Alma Drive, Suite 100 583 Plano, TX 75075 584 USA 586 Phone: (972) 509-5599 (x2240) 587 Email: ylee@huawei.com 589 Sugang Xu 590 National Institute of Information and Communications Technology 591 4-2-1 Nukui-Kitamachi, Koganei, 592 Tokyo, 184-8795 Japan 594 Phone: +81 42-327-6927 595 Email: xsg@nict.go.jp 597 Giovanni Martinelli 598 Cisco 599 Via Philips 12 600 20052 Monza, IT 602 Phone: +39 039-209-2044 603 Email: giomarti@cisco.com 605 Intellectual Property Statement 607 The IETF Trust takes no position regarding the validity or scope of 608 any Intellectual Property Rights or other rights that might be 609 claimed to pertain to the implementation or use of the technology 610 described in any IETF Document or the extent to which any license 611 under such rights might or might not be available; nor does it 612 represent that it has made any independent effort to identify any 613 such rights. 615 Copies of Intellectual Property disclosures made to the IETF 616 Secretariat and any assurances of licenses to be made available, or 617 the result of an attempt made to obtain a general license or 618 permission for the use of such proprietary rights by implementers or 619 users of this specification can be obtained from the IETF on-line 620 IPR repository at http://www.ietf.org/ipr 622 The IETF invites any interested party to bring to its attention any 623 copyrights, patents or patent applications, or other proprietary 624 rights that may cover technology that may be required to implement 625 any standard or specification contained in an IETF Document. Please 626 address the information to the IETF at ietf-ipr@ietf.org. 628 Disclaimer of Validity 630 All IETF Documents and the information contained therein are 631 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 632 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 633 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 634 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 635 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 636 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 637 FOR A PARTICULAR PURPOSE. 639 Acknowledgment 641 Funding for the RFC Editor function is currently provided by the 642 Internet Society.