idnits 2.17.1 draft-ietf-ccamp-wson-signaling-07.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 abstract seems to contain references ([RFC6205]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC6205, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2014) is 3677 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: 'WSON-info' is mentioned on line 116, but not defined == Missing Reference: 'WSON-Encode' is mentioned on line 464, but not defined == Missing Reference: 'WSON-OSPF' is mentioned on line 278, but not defined == Missing Reference: 'This ID' is mentioned on line 423, but not defined == Unused Reference: 'RFC2578' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC3477' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'WSON-CompOSPF' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'Xu' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'Winzer06' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'G.959.1' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'G.694.1' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'G.694.2' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'G.Sup43' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'RFC4427' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'RFC4872' is defined on line 524, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5920 -- No information found for draft-lee-ccamp-wson-signal-compatibility-OSPF - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 17 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: September 2014 Y.Lee 6 Huawei 7 G. Martinelli 8 Cisco 9 Hiroaki Harai 10 NICT 12 March 5, 2014 14 Signaling Extensions for Wavelength Switched Optical Networks 15 draft-ietf-ccamp-wson-signaling-07.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 applicable 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 choice in distributed 29 wavelength assignment algorithms. These extensions build on previous 30 work for the control of lambda and G.709 based networks. This 31 document updates [RFC6205] as make it applicable to WSON-LSC capable 32 equipment. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with 37 the provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other documents 46 at any time. It is inappropriate to use Internet-Drafts as 47 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 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 This Internet-Draft will expire on September 5, 2014. 56 Copyright Notice 58 Copyright (c) 2014 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with 66 respect to this document. Code Components extracted from this 67 document must include Simplified BSD License text as described in 68 Section 4.e of the Trust Legal Provisions and are provided without 69 warranty as described in the Simplified BSD License. 71 Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 Table of Contents 79 1. Introduction...................................................3 80 2. Terminology....................................................3 81 3. Requirements for WSON Signaling................................4 82 3.1. WSON Signal Characterization..............................4 83 3.2. Per LSP Network Element Processing Configuration..........5 84 3.3. Bidirectional WSON LSPs...................................6 85 3.4. Distributed Wavelength Assignment Selection Method........6 86 3.5. Optical Impairments.......................................6 87 4. WSON Signal Traffic Parameters, Attributes and Processing......6 88 4.1. Traffic Parameters for Optical Tributary Signals..........7 89 4.2. WSON Processing HOP Attribute TLV Encoding................7 90 4.3. Signal Attributes and Processing Capabilities.............8 91 4.4. Wavelength Assignment Method Selection TLV Encoding.......9 93 5. Security Considerations.......................................10 94 6. IANA Considerations...........................................10 95 7. Acknowledgments...............................................11 96 8. References....................................................12 97 8.1. Normative References.....................................12 98 8.2. Informative References...................................13 99 Author's Addresses...............................................15 100 Intellectual Property Statement..................................16 101 Disclaimer of Validity...........................................17 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 bidirectional wavelength assignment while more advanced 109 extensions are given to support the networks described in [RFC6163] 110 which feature connections requiring configuration of input, output, 111 and general signal processing capabilities at a node along a LSP. 113 These extensions build on previous work for the control of lambda 114 and G.709 based networks [RFC3471]. 116 Related references with this document are [WSON-info] that provides 117 a high-level information model and and [WSON-Encode] that provides 118 common encodings that can be applicable to other protocol extensions 119 such as routing. 121 2. Terminology 123 CWDM: Coarse Wavelength Division Multiplexing. 125 DWDM: Dense Wavelength Division Multiplexing. 127 FOADM: Fixed Optical Add/Drop Multiplexer. 129 ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port 130 count wavelength selective switching element featuring ingress and 131 egress line side ports as well as add/drop side ports. 133 RWA: Routing and Wavelength Assignment. 135 Wavelength Conversion/Converters: The process of converting 136 information bearing optical signal centered at a given wavelength to 137 one with "equivalent" content centered at a different wavelength. 139 Wavelength conversion can be implemented via an optical-electronic- 140 optical (OEO) process or via a strictly optical process. 142 WDM: Wavelength Division Multiplexing. 144 Wavelength Switched Optical Networks (WSON): WDM based optical 145 networks in which switching is performed selectively based on the 146 center wavelength of an optical signal. 148 AWG: Arrayed Waveguide Grating. 150 OXC: Optical Cross Connect. 152 Optical Transmitter: A device that has both a laser tuned on certain 153 wavelength and electronic components, which converts electronic 154 signals into optical signals. 156 Optical Responder: A device that has both optical and electronic 157 components. It detects optical signals and converts optical signals 158 into electronic signals. 160 Optical Transponder: A device that has both an optical transmitter 161 and an optical responder. 163 Optical End Node: The end of a wavelength (optical lambdas) 164 lightpath in the data plane. It may be equipped with some 165 optical/electronic devices such as wavelength 166 multiplexers/demultiplexer (e.g. AWG), optical transponder, etc., 167 which are employed to transmit/terminate the optical signals for 168 data transmission. 170 3. Requirements for WSON Signaling 172 The following requirements for GMPLS based WSON signaling are in 173 addition to the functionality already provided by existing GMPLS 174 signaling mechanisms. 176 3.1. WSON Signal Characterization 178 WSON signaling needs to convey sufficient information characterizing 179 the signal to allow systems along the path to determine 180 compatibility and perform any required local configuration. Examples 181 of such systems include intermediate nodes (ROADMs, OXCs, Wavelength 182 converters, Regenerators, OEO Switches, etc...), links (WDM systems) 183 and end systems (detectors, demodulators, etc...). The details of 184 any local configuration processes are out of the scope of this 185 document. 187 From [RFC6163] we have the following list of WSON signal 188 characteristic information: 190 List 1. WSON Signal Characteristics 192 1. Optical tributary signal class (modulation format). 193 2. FEC: whether forward error correction is used in the digital 194 stream and what type of error correcting code is used 195 3. Center frequency (wavelength) 196 4. Bit rate 197 5. G-PID: General Protocol Identifier for the information format 199 The first three items on this list can change as a WSON signal 200 traverses a network with regenerators, OEO switches, or wavelength 201 converters. These parameters are summarized in the Optical Interface 202 Class as defined in the [WSON-Info] and the assumption is that a 203 class always includes signal compatibility information. 204 An ability to control wavelength conversion already exists in GMPLS 205 signaling along with the ability to share client signal type 206 information (G-PID). In addition, bit rate is a standard GMPLS 207 signaling traffic parameter. It is referred to as Bandwidth Encoding 208 in [RFC3471]. 210 3.2. Per LSP Network Element Processing Configuration 212 In addition to configuring a network element (NE) along an LSP to 213 input or output a signal with specific attributes, we may need to 214 signal the NE to perform specific processing, such as 3R 215 regeneration, on the signal at a particular NE. In [RFC6163] we 216 discussed three types of processing not currently covered by GMPLS: 218 (A) Regeneration (possibly different types) 220 (B) Fault and Performance Monitoring 222 (C) Attribute Conversion 224 The extensions here MUST provide for the configuration of these 225 types of processing at nodes along an LSP. 227 3.3. Bidirectional WSON LSPs 229 WSON signaling can support LSP setup consistent with the wavelength 230 continuity constraint for bidirectional connections. The following 231 cases need to be separately supported: 233 (a) Where the same wavelength is used for both upstream and 234 downstream directions 236 (b) Where different wavelengths can be used for both upstream and 237 downstream directions. 239 This document will review current GMPLS bidirectional solutions 240 according to WSON case. 242 3.4. Distributed Wavelength Assignment Selection Method 244 WSON signaling can support the selection of a specific distributed 245 wavelength assignment method. 247 This method is beneficial in cases of equipment failure, etc., where 248 fast provisioning used in quick recovery is critical to protect 249 carriers/users against system loss. This requires efficient 250 signaling which supports distributed wavelength assignment, in 251 particular when the centralized wavelength assignment capability is 252 not available. 254 As discussed in the [RFC6163] different computational approaches for 255 wavelength assignment are available. One method is the use of 256 distributed wavelength assignment. This feature would allow the 257 specification of a particular approach when more than one is 258 implemented in the systems along the path. 260 3.5. Optical Impairments 262 This draft does not address signaling information related to optical 263 impairments. 265 4. WSON Signal Traffic Parameters, Attributes and Processing 267 As discussed in [RFC6163] single channel optical signals used in 268 WSONs are called "optical tributary signals" and come in a number of 269 classes characterized by modulation format and bit rate. Although 270 WSONs are fairly transparent to the signals they carry, to ensure 271 compatibility amongst various networks devices and end systems it 272 can be important to include key lightpath characteristics as traffic 273 parameters in signaling [RFC6163]. 275 LSPs signaled through extensions provided in this document MUST 276 apply the following signaling parameters: 278 . Switching Capability = WSON-LSC ([WSON-OSPF]). 279 . Encoding Type = Lambda ([RFC3471]) 280 . Label Format = as defined in [RFC6205] 282 [RFC6205] defines the label format as applicable to LSC capable 283 device. This document extend [RFC6205] as make its label format 284 applicable also to WSON-LSC capable devices. 286 4.1. Traffic Parameters for Optical Tributary Signals 288 In [RFC3471] we see that the G-PID (client signal type) and bit rate 289 (byte rate) of the signals are defined as parameters and in 290 [RFC3473] they are conveyed Generalized Label Request object and the 291 RSVP SENDER_TSPEC/FLOWSPEC objects respectively. 293 4.2. WSON Processing HOP Attribute TLV Encoding 295 Section 3.2. provided the requirements for signaling to indicate to 296 a particular NE along an LSP what type of processing to perform on 297 an optical signal or how to configure that NE to accept or transmit 298 an optical signal with particular attributes. 300 To target a specific node, this section defines a WSON_Processing 301 object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures 302 defined in [RSVP-RO]. 304 The content of this TLV is defined in the subsequent sections. (See 305 Section 4.3 for TLV and Section 4.4 for 306 TLV, respectively.) 308 ::= 309 [] 311 The WSON Processing carries sub-TLVs of the same format as a HOP 312 Attributes TLV, as defined in [RSVP-RO]. 314 4.3. Signal Attributes and Processing Capabilities 316 The [WSON-Encode] already provides all necessary definitions and 317 encoding for WSON information required for signaling. In particular, 318 the Resource block information sub-TLV contains, among others, a 319 list of available Optical Interface Classes and processing 320 capabilities. 322 is defined in Section 4.1 of [WSON-Encode]. 324 Type Sub-TLV 326 1 (TBA) 328 At least one sub-TLV MUST always be present in the 329 WSON_Processing HOP Attribute TLV.. At most two sub- 330 TLVs MAY be present in the WSON_Processing HOP Attribute TLV . If 331 more than two objects are encountered, two MUST be processed and the 332 rest SHOULD be ignored. 334 The contains several information as defined by 335 [WSON-Encode]. The following processing rules apply: 337 RB Set Field MAY contain more than one RB Indetifier. Only the first 338 one MUST be processed, the others SHOULD be ignored. 340 The I an E flags MUST be set according to bidirectional LSP 341 signaling and the numbers of RBInformation subobjects available. In 342 case of unidirectional signaling, only one RBInformartion sub-object 343 MUST be processed and I/E bits can be safely ignored. In case of 344 bidirectional signaling: if only one RBInformartion is available, 345 bits I and E MUST be both set to 1, if two RBInformation sub-objects 346 are available, bits I and E MUST have different values. 348 The rest of information available within RBInformation sub-object is 349 Optical Interface Class List, Input Bit Range List and Processing 350 Capability List. Lists MAY contain one or more elements. The usage 351 of WSON Processing object for the bidirectional case is the same as 352 per unidirectional. When an intermediate node uses information from 353 this object to instruct a node about wavelength regeneration, the 354 same information applies to both downstream and upstream directions. 356 4.4. Wavelength Assignment Method Selection TLV Encoding 358 Routing + Distributed wavelength assignment (R+DWA) is one of the 359 options defined by the [RFC6163]. The output from the routing 360 function will be a path but the wavelength will be selected on a 361 hop-by-hop basis. 363 Under this hypothesis the node initiating the signaling process 364 needs to declare its own wavelength availability (through a 365 label_set object). Each intermediate node may delete some labels due 366 to connectivity constraints or its own assignment policy. At the 367 end, the destination node has to make the final decision on the 368 wavelength assignment among the ones received through the signaling 369 process. 371 As discussed in [HZang00] a number of different wavelength 372 assignment algorithms maybe employed. In addition as discussed in 373 [RFC6163] the wavelength assignment can be either for a 374 unidirectional lightpath or for a bidirectional lightpath 375 constrained to use the same lambda in both directions. 377 A simple sub-TLV could be used to indication wavelength assignment 378 directionality and wavelength assignment method as a TLV in the LSP 379 Attributes Object, as defined in [RFC5420]. 381 Type Sub-TLV 383 TDB 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |W| WA Method | Reserved | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Where: 393 . W is a bit, 0 same wavelength in both directions, 1 may use 394 different wavelengths 395 . Wavelength Assignment (WA) Method: 0 unspecified (any), 1 396 First-Fit, 2 Random, 3 Least-Loaded (multi-fiber). Others TBD. 398 5. Security Considerations 400 This document is builds on the mechanisms defined in [RFC3473], and 401 only differs in specific information communicated. As such, this 402 document introduces no new security considerations to the existing 403 GMPLS signaling protocols. See [RFC3473], for details of the 404 supported security measures. Additionally, [RFC5920] provides an 405 overview of security vulnerabilities and protection mechanisms for 406 the GMPLS control plane. 408 6. IANA Considerations 410 Upon approval of this document, IANA will make the following 411 assignments as follows: 413 A new LSP_REQUIRED_ATTRIBUTE type is required 415 Value Sub-TLV Reference 417 3 (Suggested) WSON Processing HOP Attribute TLV [This ID] 419 One new type sub-TLV is allowed within the LSP_Attributes Object 421 Value Sub-TLV Reference 423 4 (Suggested) Wavelength Selection [This ID] 425 7. Acknowledgments 427 Authors would like to thanks Lou Berger and Cyril Margaria for 428 comments and suggestions. 430 8. References 432 8.1. Normative References 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 438 "Structure of Management Information Version 2 (SMIv2)", 439 STD 58, RFC 2578, April 1999. 441 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 442 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 443 Tunnels", RFC 3209, December 2001. 445 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 446 (GMPLS) Signaling Functional Description", RFC 3471, 447 January 2003. 449 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 450 Switching (GMPLS) Signaling Resource ReserVation Protocol- 451 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 452 January 2003. 454 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 455 in Resource ReSerVation Protocol - Traffic Engineering 456 (RSVP-TE)", RFC 3477, January 2003. 458 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. 459 Ayyangar, " Encoding of Attributes for MPLS LSP 460 Establishment Using Resource Reservation Protocol Traffic 461 Engineering (RSVP-TE)", RFC 5420, February 2006. 463 [RFC5920] Luyuan Fang(Ed.), "Security Framework for MPLS and GMPLS 464 Networks", RFC5920, July 2010. [WSON-Encode] Bernstein 465 G., Lee Y., Li D., and W. Imajuku, "Routing and Wavelength 466 Assignment Information Encoding for Wavelength Switched 467 Optical Networks", draft-ietf-ccamp-rwa-wson-encode, work 468 in progress. 470 [RFC6205] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized 471 Labels for G.694 Lambda-Switching Capable Label Switching 472 Routers", RFC 6205, March 2011. 474 [RSVP-RO] Margaria, C., et al, "LSP Attribute in ERO", draft-ietf- 475 ccamp-lsp-attribute-ro,work in progress. 477 8.2. Informative References 479 [WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal 480 and Network Element Compatibility for Wavelength Switched 481 Optical Networks", work in progress: draft-lee-ccamp-wson- 482 signal-compatibility-OSPF. 484 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 485 and PCE Control of Wavelength Switched Optical Networks", 486 work in progress: draft-bernstein-ccamp-wavelength- 487 switched-03.txt, February 2008. 489 [WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 490 Wavelength Assignment Information Model for Wavelength 491 Switched Optical Networks", work in progress: draft-ietf- 492 ccamp-rwa-info, work in progress. 494 [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing 495 and wavelength assignment approaches for wavelength-routed 496 optical WDM networks", Optical Networks Magazine, January 497 2000. 499 [Xu] S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE 500 for Bidirectional Lightpath the Same Wavelength", work in 501 progress: draft-xu-rsvpte-bidir-wave-01, November 2007. 503 [Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced 504 Optical Modulation Formats", Proceedings of the IEEE, vol. 505 94, no. 5, pp. 952-985, May 2006. 507 [G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network 508 Physical Layer Interfaces, March 2006. 510 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 511 applications: DWDM frequency grid, June 2002. 513 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 514 applications: CWDM wavelength grid, December 2003. 516 [G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R 517 in optical transport networks (OTN), November 2006. 519 [RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery 520 (Protection and Restoration) Terminology for Generalized 521 Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 522 2006. 524 [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE 525 Extensions in Support of End-to-End Generalized Multi- 526 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 528 Author's Addresses 530 Greg M. Bernstein (editor) 531 Grotto Networking 532 Fremont California, USA 534 Phone: (510) 573-2237 535 Email: gregb@grotto-networking.com 537 Nicola Andriolli 538 Scuola Superiore Sant'Anna, Pisa, Italy 539 Email: nick@sssup.it 541 Alessio Giorgetti 542 Scuola Superiore Sant'Anna, Pisa, Italy 543 Email: a.giorgetti@sssup.it 545 Lin Guo 546 Key Laboratory of Optical Communication and Lightwave Technologies 547 Ministry of Education 548 P.O. Box 128, Beijing University of Posts and Telecommunications, 549 P.R.China 550 Email: guolintom@gmail.com 552 Hiroaki Harai 553 National Institute of Information and Communications Technology 554 4-2-1 Nukui-Kitamachi, Koganei, 555 Tokyo, 184-8795 Japan 557 Phone: +81 42-327-5418 558 Email: harai@nict.go.jp 560 Yuefeng Ji 561 Key Laboratory of Optical Communication and Lightwave Technologies 562 Ministry of Education 563 P.O. Box 128, Beijing University of Posts and Telecommunications, 564 P.R.China 565 Email: jyf@bupt.edu.cn 567 Daniel King 568 Old Dog Consulting 570 Email: daniel@olddog.co.uk 572 Young Lee (editor) 573 Huawei Technologies 574 5360 Legacy Dr. Building 3 575 Plano, TX 75024 576 USA 578 Phone: (469) 277-5838 579 Email: leeyoung@huawei.com 581 Sugang Xu 582 National Institute of Information and Communications Technology 583 4-2-1 Nukui-Kitamachi, Koganei, 584 Tokyo, 184-8795 Japan 586 Phone: +81 42-327-6927 587 Email: xsg@nict.go.jp 589 Giovanni Martinelli 590 Cisco 591 Via Philips 12 592 20052 Monza, IT 594 Phone: +39 039-209-2044 595 Email: giomarti@cisco.com 597 Intellectual Property Statement 599 The IETF Trust takes no position regarding the validity or scope of 600 any Intellectual Property Rights or other rights that might be 601 claimed to pertain to the implementation or use of the technology 602 described in any IETF Document or the extent to which any license 603 under such rights might or might not be available; nor does it 604 represent that it has made any independent effort to identify any 605 such rights. 607 Copies of Intellectual Property disclosures made to the IETF 608 Secretariat and any assurances of licenses to be made available, or 609 the result of an attempt made to obtain a general license or 610 permission for the use of such proprietary rights by implementers or 611 users of this specification can be obtained from the IETF on-line 612 IPR repository at http://www.ietf.org/ipr 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 any standard or specification contained in an IETF Document. Please 618 address the information to the IETF at ietf-ipr@ietf.org. 620 Disclaimer of Validity 622 All IETF Documents and the information contained therein are 623 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 624 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 625 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 626 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 627 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 628 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 629 FOR A PARTICULAR PURPOSE. 631 Acknowledgment 633 Funding for the RFC Editor function is currently provided by the 634 Internet Society.