idnits 2.17.1 draft-xu-rsvpte-bidir-wave-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 601. 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 ([RFC4420]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sugang Xu 2 Internet-Draft Hiroaki Harai 3 Intended status: Standards Track NICT 4 Expires: May 2008 Daniel King 5 Aria Networks 6 November 12 2007 8 Extensions to GMPLS RSVP-TE for Bidirectional Lightpath 9 with the Same Wavelength 11 draft-xu-rsvpte-bidir-wave-01 13 Status of This Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware have 17 been or will be disclosed, and any of which he or she becomes aware 18 will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 For bidirectional lightpaths provisioning, in the case of optical nodes 42 that do not support wavelength conversion, it would be necessary to use 43 the same wavelength along the route on each direction. In certain 44 optical network scenarios, the use of the same wavelength on both 45 directions would be advantageous. For instance, some ROADMs may 46 add/drop the same wavelength simultaneously. In other cases, the users' 47 optical end nodes are equipped with fixed-wavelength transponders. 49 This document describes extensions to RSVP-TE signaling for 50 bidirectional wavelength lightpaths that require the same wavelength on 51 both directions. By using an LSP_ATTRIBUTES object defined in [RFC4420], 52 the extensions enable the new type lightpaths to support the low cost 53 configuration at users' optical end nodes. 55 Table of Contents 57 1. Conventions Used in This Document................................2 58 2. Terminology......................................................2 59 3. Introduction and Problem Statement...............................3 60 3.1 Port-remapping Problem..........................................3 61 3.2 Port-remapping with OXC.........................................6 62 4. Avoiding Port-remapping Problem..................................7 63 4.1 Bidirectional Lightpath using Same Wavelength on Both Directions.7 64 4.2 Inefficient Alternate Solutions.................................7 65 4.2.1 Unidirectional Lightpaths with the Same Wavelength............7 66 4.2.2 Upstream Label Set and Label Set..............................7 67 5. Using LSP_ATTRIBUTES Object......................................8 68 6. Label Set Object and Bidirectional Lightpath.....................8 69 6.1 Procedure.......................................................8 70 7. Backward Compatibility Considerations............................9 71 8. Wavelength Assignment Issue..................................... 9 72 9. Link Bundling Issue.............................................10 73 10. IANA Considerations............................................10 74 11. Security Considerations........................................10 75 12. Acknowledgements...............................................10 76 13. Normative References...........................................10 77 14. Authors' Addresses.............................................10 79 1. Conventions Used in This Document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Terminology 87 The readers are assumed to be familiar with the terminology defined 88 in [RFC3471], [RFC3473] and [RFC4420]. 90 The term "node" in this document, when used in the context of the 91 procedure description in section 6, refers to the GMPLS node which 92 is the signaling controller in the control plane. 94 The term "receiver" in this document indicates a GMPLS node, which 95 receives messages from its GMPLS neighbor nodes. 97 The term "optical transmitter" in this document is a device that has 98 both a laser tuned on certain wavelength and electronic components, 99 which converts electronic signals into optical signals. 101 The term "optical responder" in this document is a device that has 102 both optical and electronic components. It detects optical signals 103 and converts optical signals into electronic signals. 105 The term "optical transponder" in this document is a device that has 106 both an optical transmitter and an optical responder. 108 The term "optical end node" in this document is the end of a wavelength 109 (optical lambdas) lightpath in the data plane. It may be equipped with 110 some optical/electronic devices such as wavelength 111 multiplexers/demultiplexer (e.g. arrayed wavelength grating (AWG)), 112 optical transponder, etc., which are employed to transmit/terminate the 113 optical signals for data transmission. 115 The term "wavelength-routed network" in this document is a network 116 that consists of transit nodes which may be equipped with wavelength 117 selective switching elements such as reconfigurable optical add/drop 118 multiplexer (ROADM) or optical cross-connect (OXC), and optical end 119 nodes at edges. Wavelength lightpaths between optical end nodes can 120 be established across the network. 122 3. Introduction and Problem Statement 124 With the Lambda Switch (LSC) support defined in GMPLS [RFC3471] and 125 RSVP-TE signaling [RFC3473], by properly configuring the wavelength 126 selective switching elements such as ROADMs or OXCs at the transit 127 nodes, both unidirectional and bidirectional wavelength (optical 128 lambdas) lightpaths can be established in a wavelength-routed network. 129 To provide high-performance full-duplex transmission links between 130 users' optical end nodes (e.g. computers, switches and routers, which 131 are equipped with the necessary optical transmitters and responders) 132 directly, bidirectional lightpaths should be established between users' 133 optical end nodes. 135 This document considers the various scenarios where bidirectional 136 lightpaths would be required for users' direct full-duplex end-end 137 communications. By using the LSP_ATTRIBUTES object defined in [RFC4420], 138 new extensions to RSVP-TE signaling are introduced. These extensions 139 enable the lightpath to support the required configuration to enable the 140 same wavelength to be used on both directions between the users' optical 141 end nodes. 143 The extensions in this document would be applied to various scenarios. 144 For example, only a specific wavelength among the multiplexed 145 wavelengths could be added/dropped to an optical end node. In another 146 case, some type of ROADMs may add/drop the same wavelength 147 simultaneously. In these cases, using the same wavelength on both 148 directions is a solution. Another problem that takes into account users' 149 convenience, avoiding port-remapping, is stated as follows. 151 3.1 Port-remapping Problem 153 In the context of CI-incapable [RFC3471] wavelength-routed networks, 154 where the nodes in the networks cannot support wavelength conversion, 155 the same wavelength on each link along a unidirectional lightpath 156 should be reserved. According to the definition in [RFC3471], a 157 bidirectional lightpath can be seen as a pair of unidirectional 158 lightpaths, which are provisioned along the same route simultaneously 159 by the RSVP-TE signaling with Upstream Label and Label Set Objects in 160 the messages [RFC3473]. 162 A previously defined bidirectional lightpath does not 163 necessarily require the same wavelength on both directions. 164 In consequence, the selection of the upstream and downstream labels 165 are independent. That is to say, when establishing a bidirectional 166 wavelength lightpath, the wavelengths on both directions selected 167 using RSVP-TE may be different. This may result in a 168 wavelength-routed network specific port-remapping problem at both 169 ends of the bidirectional lightpath. This problem occurs in the 170 following situations: 172 (1) Fixed wavelength multiplexer/demultiplexer like AWGs may be employed 173 at each node. Each incoming and outgoing wavelength is with a dedicated 174 fixed port of AWG. For example, wavelength lambda 1 is on port 1, and 175 wavelength lambda 2 is on port 2, and so on. See Fig.3.1.1. 177 +--+ 178 | |---> lambda 1: port 1 179 -->| |---> lambda 2: port 2 180 | |---> lambda 3: port 3 181 +--+ 182 A. AWG Demultiplexer case. 184 +--+ 185 | |<--- lambda 1: port 1 186 <--| |<--- lambda 2: port 2 187 | |<--- lambda 3: port 3 188 +--+ 189 B. AWG Multiplexer case. 191 Fig.3.1.1. The fixed wavelength-port mapping of AWG 192 Multiplexer/Demultiplexer. 194 (2) Compared to a wavelength-tunable optical transponder array, low cost 195 fixed-tuned optical transponder array may be employed at the edge node. 196 In an optical transponder, the optical responder is bound with the 197 transmitter. Each of the optical transmitters and responders are 198 physically connected to one port of AWG or OXC according to the 199 configuration. See Fig.3.1.2. 201 +--+ +----+ 202 | |<---lambda 1---| T1 | 203 <--| |<---lambda 2---| T2 | 204 | |<---lambda 3---| T3 | 205 +--+ +----+ 206 AWG Multiplexer optical transmitter array 207 A. The configuration with the optical transmitters connecting AWG. 209 +--+ +----+ 210 | |---lambda 1--->| R1 | 211 -->| |---lambda 2--->| R2 | 212 | |---lambda 3--->| R3 | 213 +--+ +----+ 214 AWG Demultiplexer optical responder array 215 B. One possible configuration with the optical responders connecting 216 AWG. 218 +--+ +-----+ +----+ 219 | |--->| |--->| R1 | 220 -->| |--->| OXC |--->| R2 | 221 | |--->| |--->| R3 | 222 +--+ +-----+ +----+ 223 AWG Demultiplexer optical responder array 224 C. One possible configuration with the optical responders connecting 225 OXC. 227 Fig.3.1.2. The fixed optical transmitter/responder- AGW/OXC port 228 mapping at the optical end nodes. 230 Consider a bidirectional lightpath with different wavelengths on two 231 directions. The optical transmitter of which output wavelength is the 232 same as the outgoing-wavelength (say lambda 1) is chosen first for 233 using the lightpath. Then, the optical responder attached to that 234 transmitter should be selected for receiving the incoming wavelength 235 (say lambda 2). The responder generally can receive any of different 236 wavelengths. Therefore, if another bidirectional lightpath is 237 assigned the same outgoing wavelength (lambda 1) but with a different 238 incoming wavelength (say lambda 3), the same transmitter and responder 239 pair is selected. See Fig.3.1.3. 241 +----+ 242 <-lambda 1---| T1 | 243 +----+ 244 A. Optical transmitter T1 sends optical signals on lambda 1. 246 +----+ 247 -lambda 2--->| R1 | 248 +----+ 249 B. Optical responder R1 receives optical signals on lambda 2 for one 250 bidirectional lightpath. 252 +----+ 253 -lambda 3--->| R1 | 254 +----+ 255 C. Optical responder R1 can receive optical signals on lambda 3 for 256 another bidirectional lightpath. 258 Fig.3.1.3. Transmitter sends optical signals on the fixed-tuned 259 wavelength; the responder can receive data on different wavelengths. 261 However, the communication using the transponder and the 262 bidirectional lightpath with different wavelengths will not succeed 263 under the situations (1) and (2) mentioned above. Remember the fixed 264 port mapping that each incoming wavelength is fixed on a unique port 265 of AWG due to the situation (1), and the optical responder is also 266 fixedly connected to a unique port of AWG or OXC due to the situation 267 (2). Conversely, the incoming wavelength may change every 268 lightpath (see lambda 2 and lambda 3 in the above case) for the same 269 outgoing wavelength (lambda 1). The current incoming wavelength 270 (lambda 3) is not on the port of AWG to which the optical responder 271 connects originally (lambda 2), see Fig. 3.1.4. To connect the 272 optical responder to the proper port on which the incoming wavelength 273 is, even in different outgoing wavelengths, a port-remapping process 274 between the optical responder and AWG ports may be required. 276 +--+ +----+ 277 | |<---lambda 1---| T1 | 278 <--| |<---lambda 2---| T2 | 279 | |<---lambda 3---| T3 | 280 +--+ +----+ 281 AWG Multiplexer 282 A. Optical transmitter T1 sends optical signals on lambda 1. 284 +--+ 285 | |-- +----+ 286 -->| |--lambda2---->| R1 | 287 | |--lambda3-X +----+ 288 +--+ 289 AWG Demultiplexer 290 B. Optical responder R1 cannot receive optical signals on lambda 3 291 due to the fixed port mapping, in case of that R1 is physically 292 connected to the port 2 of lambda 2 on AWG. 294 Fig. 3.1.4. Port-remapping problem occurs due to the fixed 295 port-mapping between the optical responder and AWG port. 297 3.2 Port-remapping with OXC 299 The port-remapping capability depends on the system configurations 300 at users' optical end nodes. For example, an OXC may be employed 301 to switch the incoming wavelength from the port of AWG to the port 302 which the optical responder is connected physically, see Fig. 3.2.1. 303 However, equipping users' optical end nodes with OXCs introduces 304 extra costs. There exists a trade-off between port-remapping 305 capability and cost/system complexity. 307 +--+ +-------+ +----+ 308 | |-lambda 1-->| /--|--->| R1 | 309 -->| |-lambda 2-->|---/ |--->| R2 | 310 | |-lambda 3-->| OXC |--->| R3 | 311 +--+ +-------+ +----+ 312 AWG Demultiplexer 313 A. The optical responder R1 can receive the optical signals on lambda 314 2. 316 +--+ +-------+ +----+ 317 | |-lambda 1-->| /---|--->| R1 | 318 -->| |-lambda 2-->| / |--->| R2 | 319 | |-lambda 3-->|-/ OXC |--->| R3 | 320 +--+ +-------+ +----+ 321 AWG Demultiplexer 322 B. The optical responder R1 can receive the optical signals on lambda 323 3. 325 Fig.3.2.1. The port-remapping capability provided by OXC. 327 Users have various types of optical end node configurations to 328 choose from. Some configurations such as those equipped with OXCs might 329 provide flexibility but could be costly and potentially complicated. 330 Equally, while other configurations without OXCs might lack the 331 flexibility they may be inexpensive and easy to use and maintain. 333 4. Avoiding Port-remapping Problem 335 Which solution will be employed depends on the considerations of the 336 flexibility and cost/complexity trade-off. If users do not have 337 port-remapping capability at optical end nodes, then it is 338 necessary to avoid the port-remapping, and find a feasible approach 339 to provide users full-duplex transmission capability with 340 bidirectional lightpath. 342 4.1 Bidirectional Lightpath using Same Wavelength on Both Directions 344 A feasible approach is to establish a bidirectional lightpath with 345 the same wavelength on both directions. At the optical end node, 346 fixed-tuned transponder array is connected to the proper ports of AWG 347 according to the wavelength. Optical transmitter and responder pair 348 connecting the selected outgoing and incoming wavelength ports of AWG 349 will be assigned to the bidirectional lightpath. In this document, 350 the bidirectional lightpath with the same wavelength on both 351 directions is introduced as a complementary lightpath type. 353 4.2 Inefficient Alternate Solutions 355 4.2.1 Unidirectional Lightpaths with the Same Wavelength 357 Separately establishing two unidirectional lightpaths on different 358 directions using the same wavelength between two optical end nodes might 359 be an approach to support users' full-duplex transmission requirement. 360 The same wavelength requirement could be achieved by sequentially 361 scanning the wavelengths' availability on both directions. Establish 362 one-way lightpath first and verify the availability of the same 363 wavelength on another lightpath. If the wavelength is not available 364 on both directions, release the former unidirectional lightpath, and 365 repeat this process with a next wavelength, until an available 366 wavelength is found on both directions. However, this solution is 367 inefficient because it might be time consuming during the scan process 368 of the wavelength availability verification. 370 4.2.2 Upstream Label Set and Label Set 372 Another approach is to extent the RSVP-TE signaling by defining an 373 Upstream Label Set object, and to select the common free wavelengths 374 along the upstream and downstream lightpaths. Although it inherits 375 the idea of Upstream Label from traditional bidirectional LSP, it is 376 still not a neat solution and is inefficient. 378 The simplest way is to only define an extension to the processing of 379 Label Set [RFC3473], and leave the other processes untouched. The 380 issues related to this new functionality including an LSP_ATTRIBUTES 381 object defined in [RFC4420] and the new procedure are described in 382 the following sections. 384 5. Using LSP_ATTRIBUTES Object 386 To trigger the new functionality at each GMPLS node, it is necessary 387 to notify the receiver the new type lightpath request. One 388 multi-purpose flag/attribute parameter container object called 389 LSP_ATTRIBUTES object and related mechanism defined in [RFC4420] meet 390 this requirement. One bit in Attributes Flags TLV which indicates the 391 new type lightpath, say, the bidirectional same wavelength lightpath 392 will be present in an LSP_ATTRIBUTES object. Please refer to 393 [RFC4420] for detailed descriptions of the Flag and related issues. 395 6. Label Set Object and Bidirectional Lightpath 397 Considering the system configuration mentioned above, it is needed 398 to add a new function into RSVP-TE to support bidirectional lightpath 399 with same wavelength on both directions. 401 6.1 Procedure 403 The lightpath setup procedure is described below: 405 (1) Ingress node adds the new type lightpath indication in an 406 LSP_ATTRIBUTES object. It is propagated in the Path message in the 407 same way as that of a Label Set object for downstream; 409 (2) On reception of a Path message containing both the new type 410 lightpath indication in an LSP_ATTRIBUTES object and Label Set object, 411 the receiver checks the local LSP database to see if the Label Set 412 TLVs are acceptable on both directions jointly. If there are 413 acceptable wavelengths, then copy the values of them into new Label 414 Set TLVs, and forward the Path message to the downstream node. 415 Otherwise the Path message will be terminated, and a PathErr message 416 with a "Routing problem/Label Set" indication will be generated; 418 (3) On reception of a Path message containing both such a new type 419 lightpath indication in an LSP_ATTRIBUTES object and an Upstream Label 420 object, the receiver MUST terminate the Path message using a PathErr 421 message with Error Code "Unknown Attributes TLV" and Error Value set 422 to the value of the new type lightpath TLV type code; 424 (4) On reception of a Path message containing both the new type 425 lightpath indication in an LSP_ATTRIBUTES object and Label Set object, 426 the egress node verifies whether the Label Set TLVs are acceptable, 427 if one or more wavelengths are available on both directions, then any 428 one available wavelength could be selected. A Resv message is 429 generated and propagated to upstream node; 431 (5) When a Resv message is received at an intermediate node, if it is a 432 new type lightpath, the intermediate node allocates the label to 433 interfaces on both directions and update internal database for this 434 bidirectional same wavelength lightpath, then configures the local ROADM 435 or OXC on both directions. 437 Except the procedure related to Label Set object, the other processes 438 will be left untouched. 440 7. Backward Compatibility Considerations 442 Due to the introduction of new processing on Label Set object, it is 443 required that each node in the lightpath is able to recognize the new 444 type lightpath indication Flag carried by an LSP_ATTRIBUTES object, 445 and deal with the new Label Set operation correctly. It is noted that 446 this new extension is not backward compatible. 448 According to the descriptions in [RFC4420], an LSR that does not 449 recognize a TLV type code carried in this object MUST reject the Path 450 message using a PathErr message with Error Code "Unknown Attributes 451 TLV" and Error Value set to the value of the Attributes Flags TLV type 452 code. 454 An LSR that does not recognize a bit set in the Attributes Flags TLV 455 MUST reject the Path message using a PathErr message with Error Code 456 "Unknown Attributes Bit" and Error Value set to the bit number of the 457 new type lightpath Flag in the Attributes Flags. 459 The reader is referred to the detailed backward compatibility 460 considerations expressed in [RFC4420]. 462 8. Wavelength Assignment Issue 464 This signaling approach can be used for both combined routing and 465 wavelength assignment and separate routing and wavelength assignment 466 approaches, with and without Path Computation Element (PCE) support. 467 This signaling provides a unified signaling solution for different 468 scenarios. 470 a) Given a routing and wavelength assignment solution e.g. derived from 471 a PCE, an ingress node can put one wavelength label in Label set or a 472 Suggested label object to specify the wavelength. 474 b) Given only routing solution e.g. from a PCE, an ingress node can set 475 one or more available wavelength label objects in Label set, and let the 476 egress node resolve the wavelength assignment in a distributed fashion. 478 c) Because this signaling solution can resolve wavelength assignment 479 problem itself, even without interaction with a PCE, by using an 480 explicit route e.g. manually, it is still possible to establish a 481 bidirectional lightpath. For example, a second lightpath is requested 482 between the same node pair of the previously established lightpath, e.g. 483 for quick recovery from failures, bidirectional signaling may negate a 484 PCE request. LSP set up time may also be reduced. Moreover, compared to 485 other crank back signaling approaches shown above, for distributed 486 wavelength assignment, this approach would have a lower blocking 487 probability and a shorter provisioning time. 489 9. Link Bundling Issue 491 PCE path computation problems may occur when computing bidirectional 492 lightpaths. In a GMPLS network where multiple component links are 493 aggregated into a link bundle and advertised as a single bidirectional 494 TE link, the Traffic Engineering Database (TED) may indicate the 495 availability of a particular lambda in both directions on the TE link. 496 However, it may actually be the case that the lambda is only available 497 in one direction on one component link, and the other direction is only 498 available on a different component link. In this scenario, creating an 499 end-to-end path that uses the same lambdas and the same component links 500 in both directions presents a PCE path computation problem. This 501 signaling can be used to verify the solution received from PCE. 503 10. IANA Considerations 505 One bit in Attributes Flags TLV which indicates the new type lightpath, 506 say, the bidirectional same wavelength lightpath will be present in an 507 LSP_ATTRIBUTES object. For example, one possible position in Attributes 508 Flags TLV is suggested to be the 9th bit. The actions for IANA are under 509 discussion, and will be added to the document in a later draft. 511 11. Security Considerations 513 This document adds new procedure related only to Label Set object at 514 each node. It does not introduce any new direct security issues, and 515 the reader is referred to the security considerations expressed in 516 [RFC3473] and [RFC4420]. 518 12. Acknowledgements 520 The authors would like to thank to Adrian Farrel for helpful comments 521 and feedback. 523 13. Normative References 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, March 1997. 528 [RFC3471] Berger, L. (Ed.), "Generalized Multi-Protocol Label 529 Switching (GMPLS) Signaling Functional Description", RFC 3471, 530 January 2003. 532 [RFC3473] Berger, L. (Ed.), "Generalized Multi-Protocol Label 533 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 534 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 536 [RFC4420] A. Farrel, et al., "Encoding of Attributes for 537 Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 538 Establishment Using Resource ReserVation Protocol-Traffic 539 Engineering (RSVP-TE) ", RFC 4420, February 2006 541 14. Authors' Addresses 542 Sugang Xu 543 National Institute of Information and Communications Technology 544 4-2-1 Nukui-Kitamachi, Koganei, Tokyo, 184-8795 Japan 546 Phone: +81 42-327-6927 547 Email: xsg@nict.go.jp 549 Hiroaki Harai 550 National Institute of Information and Communications Technology 551 4-2-1 Nukui-Kitamachi, Koganei, Tokyo, 184-8795 Japan 553 Phone: +81 42-327-5418 554 Email: harai@nict.go.jp 556 Daniel King 557 Aria Networks 558 44/45 Market Place, Chippenham, SN15 3HU, United Kingdom 560 Phone: +44 7790 775187 561 Email: daniel.king@aria-networks.com 563 Full Copyright Statement 565 Copyright (C) The IETF Trust (2007). 567 This document is subject to the rights, licenses and restrictions 568 contained in BCP 78, and except as set forth therein, the authors 569 retain all their rights. 571 This document and the information contained herein are provided on an 572 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 573 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 574 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 575 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 576 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 577 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 579 Intellectual Property 581 The IETF takes no position regarding the validity or scope of any 582 Intellectual Property Rights or other rights that might be claimed to 583 pertain to the implementation or use of the technology described in 584 this document or the extent to which any license under such rights 585 might or might not be available; nor does it represent that it has 586 made any independent effort to identify any such rights. Information 587 on the procedures with respect to rights in RFC documents can be 588 found in BCP 78 and BCP 79. 590 Copies of IPR disclosures made to the IETF Secretariat and any 591 assurances of licenses to be made available, or the result of an 592 attempt made to obtain a general license or permission for the use of 593 such proprietary rights by implementers or users of this 594 specification can be obtained from the IETF on-line IPR repository at 595 http://www.ietf.org/ipr. 597 The IETF invites any interested party to bring to its attention any 598 copyrights, patents or patent applications, or other proprietary 599 rights that may cover technology that may be required to implement 600 this standard. Please address the information to the IETF at 601 ietf-ipr@ietf.org. 603 Acknowledgements 605 Funding for the RFC Editor function is provided by the IETF 606 Administrative Support Activity (IASA).