idnits 2.17.1 draft-multihoming-generic-goals-and-benefits-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- The document date (February 9, 2004) is 7382 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) == Outdated reference: A later version (-06) exists of draft-elmalki-mobileip-bicasting-v6-05 -- Possible downref: Normative reference to a draft: ref. '1' -- No information found for draft-ietf-seamoby-terminology - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-router-selection-03 == Outdated reference: A later version (-04) exists of draft-ietf-ipv6-host-load-sharing-01 -- No information found for draft-xxx-nemo-multihoming - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' -- No information found for draft-xxx-nemo-multihoming - is the name correct? -- Duplicate reference: draft-xxx-nemo-multihoming, mentioned in '6', was also mentioned in '5'. -- Possible downref: Normative reference to a draft: ref. '6' -- No information found for draft-nomad-mip4-flow-mobility-problem-statement - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 No Specific Working Group T. Ernst 3 Internet-Draft WIDE at Keio University 4 Expires: August 9, 2004 N. Montavont 5 LSIIT - ULP 6 R. Wakikawa 7 Keio University 8 E. Paik 9 Seoul National University 10 C. Ng 11 Panasonic Singapore Labs 12 K. Kuladinithi 13 University of Bremen 14 T. Noel 15 LSIIT - ULP 16 February 9, 2004 18 Goals and Benefits of Multihoming 19 draft-multihoming-generic-goals-and-benefits-00 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at http:// 36 www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 9, 2004. 43 Copyright Notice 45 Copyright (C) The Internet Society (2004). All Rights Reserved. 47 Abstract 49 This document attempts to define the goals and benefits of 50 multihoming for fixed and mobile hosts and routers. Those goals and 51 benefits are illustrated with a set of real-life scenarios. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Goals and Benefits of Multihoming . . . . . . . . . . . . . . 4 61 4. Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Configurations . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 69 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 73 Intellectual Property and Copyright Statements . . . . . . . . 15 75 1. Introduction 77 New equipments shipped on the market now often integrate several 78 wireless technologies. 80 The main purpose of this integration is to federate all means of 81 communications in order to access the Internet ubiquitously (from 82 everywhere and at any time) since a permanent Internet connectivity 83 is now required by some applications. Unfortunately, there is no 84 network interfaces assuring global scale connectivity. Nodes must 85 thus use various type of network interfaces to obtain wide area 86 network connectivity [8]. 88 New equipments also integrate several access technologies in order to 89 increase bandwidth availability or to select the technology the most 90 appropriate according to the type of flow or choices of the user. 91 Basically, each network interface has different cost, performance, 92 bandwidth, access range, and reliability. Users should thus be able 93 to select the most appropriate set of network interface(s) depending 94 on the network environment, particularly in wireless networks which 95 are mutable and less reliable than wired networks. Users should also 96 be able to select the most appropriate interface per communication 97 type or to combine a set of interfaces to get sufficient bandwidth. 99 The purpose of this document is to show real-life scenarios in order 100 to illustrate the goals and benefits of multihoming for fixed and 101 mobile hosts and routers in a generic fashion, i.e. without focusing 102 on issues pertaining to hosts, or routers, or mobility. Specific 103 mobility issues pertaining to mobile nodes and mobile networks are 104 discussed in companion drafts [6], [5] and [7]. 106 This document is organized as follows: we first define the terms used 107 in the document before emphasizing the goals and benefits of 108 multihoming. Next follows a differentiation between cases where a 109 multihomed node has a single interface and the cases where it has 110 multiple interfaces. Then, we describe some real-life scenarios to 111 illustrate the goals and benefits of multihoming and we conclude with 112 the description of possible configurations at the network layer. 114 2. Terminology 116 In this section we define terms related to multihoming: 118 Interface (from [2]) 120 A node's attachment to a link 122 Multihomed Node 124 A node (either a host or a router) is multihomed when it has 125 several IPv6 addresses to choose between, i.e. in the following 126 cases when it is: 128 multi-prefixed: multiple prefixes are advertised on the link(s) 129 the node is attached to. 131 multi-interfaced: the node has multiple interfaces to choose 132 between, on the same link or not. 134 Multihomed Network 136 From the above definition, it follows that a network is multihomed 137 when either the network is simultaneously connected to the 138 Internet via more than one router, or when a router is 139 multi-prefixed or multi-interfaced. 141 3. Goals and Benefits of Multihoming 143 We cannot distinguish the goals of multihoming from the benefits of 144 being multihomed, but we can identify several situations where it is 145 either advisable or beneficial to be multihomed: 147 Ubiquitous Access: 149 To provide an extended coverage area. Multiple interfaces bound to 150 distinct technologies can be used to ensure a permanent 151 connectivity is offered. 153 Redundancy/Fault-Recovery: 155 To act upon failure of one point of attachment, i.e. the functions 156 of a network are assumed by secondary system components when the 157 primary component becomes unavailable (e.g. failure). Connectivity 158 is guaranteed as long as at least one connection to the Internet 159 is maintained. 161 Load Sharing: 163 To spread network traffic load among several routes. This is 164 achieved when traffic load is distributed simultaneously among 165 different connections between the node and the Internet [4]. 167 Load Balancing: 169 To balance load between multiple point of attachments 170 (simultaneously active or not), usually chosing the lest loaded 171 connection. 173 Bi-casting: 175 Bi-casting (n-casting) duplicates a particular flow for 176 simultaneous transmission through different routes. It minimizes 177 packet loss typically for real-time communication and burst 178 traffic. It also minimizes delay of packet delivery caused by 179 congestions and achieves more reliable real-time communication 180 than single-casting. For mobile computing, bi-casting is useful 181 not to drop packets when a mobile node changes its interface 182 during communication [1]. 184 Preference Settings: 186 To provide the user or the application or the ISP the ability to 187 choose the preferred transmission technology or access network for 188 matters of cost, efficiency, politics, bandwidth requirement, 189 delay, etc. 191 When considering these goals/benefits, one has to consider whether 192 these goals can be achieved with transparency or without 193 transparency. Transparency is achieved when switching to a different 194 point of attachment does not cause on-going sessions to break. 196 For instance, ubiquity with transparency is achieved when switching 197 between two different access mechanism does not cause on-going 198 sessions to be disrupted. 200 In order to achieve transparency, a necessary (may or may not be 201 sufficient) condition is for the end-point addresses to remain 202 unchanged. This is in-view of the large amount of Internet traffic 203 today are carried by TCP, which unlike SCTP, cannot handle multiple 204 end-point address pairs. 206 4. Cases 208 From the definition of a multihomed node it follows that a multihomed 209 node has several IPv6 addresses to choose between. In order to expose 210 the goals and benefits to manage multihomed nodes, we propose to 211 distinguish two main cases: either the node has only one interface, 212 or the node has several interfaces. A rough analysis of these two 213 cases is detailed below. 215 Case 1: One Interface 217 The node has one interface. It is multihomed when several prefixes 218 are advertised on its interface. The node must therefore configure 219 several IPv6 addresses. An address selection mechanism is needed. 221 This multihomed configuration may yield the following benefits for 222 the node: 224 * Load sharing can be performed in the network 226 * Redundancy: In case of failure of one IPv6 prefix, one of the 227 address of the node will not be valid anymore. The fact that 228 the node has another address built with other prefixes should 229 allow it to recover this sort of failure, however transparency 230 may not achieved since on-going sessions using the invalid 231 address would have to be terminated, and restarted using the 232 new address. It is also to be noted that all sessions on the 233 node will be disrupted if all prefixes fail to be announced 234 (e.g. all were announced by the same router and this router 235 broke down). 237 * Preference: the source address can be chosen according to 238 preferences set up by the user, or according to preferences set 239 up in the network (such as with the default router preferences 240 option introduced in Router Advertisement [3], or by ISP. 242 Case 2: Several Interfaces 244 The node has more than one interface. The node must therefore 245 configure several IPv6 addresses (one on each interface). An 246 address selection mechanism is needed. 248 This multihomed configuration may yield the following benefits for 249 the node: 251 * Load balancing: between the interfaces 253 * Redundancy: another interface can be used if one fails 255 * Ubiquity: it is more likely to have access to another 256 technology if a technology cannot be used 258 * Preferences: interface and address selection is required. The 259 problem can be seen exactly as in the first case (the node has 260 only one interface) if we consider that the interface 261 preference is a parameter for the address selection. Therefore 262 in this case, the interface selection/preference is a 263 supplementary parameter in the address selection algorithm. 265 5. Scenarios 267 The following scenarios highlight the usage of several interfaces and 268 the benefit of such configuration. Each scenario usually yields more 269 than one benefit. The first scenario focuses on using two wireless 270 interfaces for the purpose of balancing the load while second shows 271 the usage of preference settings. The third is a combination of the 272 first two. The fourth and fifth illustrate how multiple connections 273 can provide ubiquitous Internet access and how load can be balanced 274 according to some preferences. The last one illustrates redundancy 275 and bi-casting. 277 Scenario 1: Load Balancing 279 Alice is at the airport waiting to board the plane. She receives a 280 call from her husband. This audio communication is received via a 281 wireless local area link realized over one of the available 282 hot-spots. She knows this is going to be a long flight and wishes 283 to catch up on some work. Alice uses a wireless LAN connection to 284 download the necessary data. However, there is not enough time and 285 Alice decides to accelerate the download. Her notebook is equipped 286 with an additional wireless local area network interface. Alice 287 decides to distribute the different download flows between the 288 wireless interfaces to accelerate the download. 290 Scenario 2: Preference Settings and Transparent Flow Handoffs 292 Mr. Smith is on his way to work waiting at a train station. He 293 uses this opportunity and the presence of a wireless LAN hot-spot 294 to download the news from his favorite on-line news channel. His 295 train is announced. Mr. Smith decides to buy a ticket. However, 296 the ticket reservation service is only available via a wide area 297 cellular link of a specific provider. While Mr. Smith is 298 downloading the news and accessing the train ticket reservation 299 service, he receives a phone call over a wide area cellular link. 300 Mr. Smith decides he wishes to initiate a video flow for this 301 communication. The bandwidth and traversal delay of the wide area 302 cellular link is not adequate for the video conference, so both 303 flows (video/audio) are transferred to a wireless local area link 304 via a hot-spot. This transfer occurs transparently and without 305 affecting any other active flows. 307 Scenario 3: Preference Settings for House Networking 308 Mr. Vernes works at home for a publishing company. He has an 309 in-house network and get access to the Internet via ADSL, a public 310 802.11b WLAN from the street and satellite. The satellite link he 311 has access to is only downward but is extremely cheap for TV 312 broadcasting. He chooses to send requests for joining the TV 313 broadcasting via ADSL rather the 802.11b although 802.11b in the 314 street is free. He has noticed the 802.11b is unreliable at some 315 point in time during the day. On the other hand, he has configured 316 his network to use the 802.11b link at night to publish web 317 content comprising video. Once a week, he communicate with 318 overseas peer staff by videoconferencing. Voice being the most 319 important, he has configured his VoIP session over ADSL. Video is 320 sent at maximum rate when 802.11b is working fine, otherwise one 321 picture every 5 sec over ADSL. 323 Scenario 4: Ubiquitous Access, Load Balancing, Preference Setting 325 An ambulance is called at the scene of a car accident. A paramedic 326 initiates a communication to a hospital via a wide area cellular 327 link for the relay of low bit-rate live video from the site of the 328 crash to assess the severity of the accident. It is identified 329 that one of the passengers has suffered a severe head injury. The 330 paramedic decides to consult a specialist via video conferencing. 331 This session is initiated from the specialist via the same wide 332 area cellular link. Meanwhile, the paramedic requests for the 333 download of the patient medical records from the hospital servers. 334 The paramedic decides in mid-session that the wide area cellular 335 link is too slow for this download and transfers the download to 336 the ambulance satellite link. Even though this link provides a 337 significantly faster bit rate it has a longer traversal delay and 338 only down-link is available. For this, only the down-stream of the 339 download is transferred while up-stream proceeds over the wide 340 area cellular link. Connectivity with the ambulance is managed 341 over a wireless local area link between the paramedic and the 342 ambulance. Even though the paramedic has performed a partial 343 hand-off for the transfer of the download down-stream to the 344 satellite link, the upstream and the video conferencing session 345 remains on the wide area cellular link. This serves best the time 346 constraint requirements of the real time communication. 348 Scenario 5: Ubiquitous Access and Load Sharing 350 Jules drives his car to a new place and constantly keeps some sort 351 of Internet access through one the access technology. His car 352 navigator downloads road information from the internet and his 353 car-audio serves on-line audio streaming. When his car passes an 354 area where both high-data-rate WLAN and low-data-rate cellular 355 network available, it distributes load to WLAN and cellular 356 connection. When his car passes an area where only 357 wide-coverage-range cellular network is available, it maintains 358 its connection via the cellular network. When Bob passes an area 359 where even cellular networks can not be reached, he can switch to 360 the expensive satellite network with multiple interfaces that his 361 car support. 363 Scenario 6: Redundancy and Bi-Casting 365 Catherine performs an operation via long-distance medical system. 366 She watches a patient in a battle field over the screen which 367 delivers real-time image of the patient. Sensors on her arms 368 deliver her operational action and a robot performs her operation 369 in the battle field. Since the operation is critical, the delivery 370 of patient image and Catherine's action is done by bi-casting 371 from/to multiple interface. So in case of one of the interface 372 failed, Catherine can continue her long-distance operation. 374 6. Configurations 376 This section details the possible network configurations that are 377 considered important. Possible configurations may involve either a 378 fixed host, a mobile host, a fixed router or a mobile router. 380 Case 1: One Interface 382 A typical case of this scenario is a node with an IEEE 802.11 383 interface, connected to an access point. The access point is 384 connected trough an Ethernet link to two access routers. Each 385 access router is configured to send Router Advertisement on the 386 link and can be used as default router. Several reasons may lead 387 to the fact that two access routers are on the same link: for 388 instance, the access points may be shared between different ISPs, 389 or two access routers may be used for redundancy or load sharing 390 purposes. 392 In that case, the node will build two global IPv6 addresses on its 393 interface. When the node establishes an IPv6 communication (e.g. 394 open a TCP connection), it has to choose which address to use. 395 This choice can be influenced by many parameters: user preference, 396 different price on prefixes, preference flag in Router 397 Advertisement, destination prefix... 399 The critical points that can be highlighted here are the 400 following: 402 * Choice of the router: each access router the node is be 403 connected to might have different capacity. As an example, if 404 the node is inside a mobile network and is connected to two 405 mobile routers, each mobile router may implement different 406 technology on their egress interface. This would have a strong 407 impact on the node traffic. 409 * Load Sharing: This benefit is mainly for the network side: if 410 different access routers or routes can be used to forward the 411 node traffic, it will share the traffic load on the network. 413 * Lost of a prefix: If the node looses one of its prefix, it can 414 not use the corresponding address anymore. So the node needs a 415 recovery mechanism allowing to remove all current communication 416 to one of its other IPv6 address. The time needed for the 417 detection of the prefix failure and the time to redirect 418 communications to one of its other addresses is considered as 419 critical. 421 * Mobility of the node: If the node moves to a new point of 422 attachment in another subnet, it will need to change its IPv6 423 addresses. In order to maintain all its previous communication, 424 it will need to redirect the flows to its new location, 425 whatever the old address used for the flow. The scalability of 426 the redirection can also be considered here. 428 Case 2: Multiple Interfaces 430 The typical case of this scenario is a node that has two 431 interfaces, each on a different technology, in order to benefit a 432 better coverage area (ubiquitous access) and the capacity and 433 specification of each technology. Such an example is to have a 434 WLAN interface (e.g. IEEE 802.11b) and a 3GPP interface (e.g. 435 GPRS). In this case, the node may use its two interfaces either 436 alternatively or simultaneously. If it alternatively uses its two 437 interfaces, the node falls into case one (multiple prefixes and 438 one interface) and is multihomed or the node is not multihomed. In 439 the following, we thus consider that the node simultaneously uses 440 its two interfaces. 442 In this case, the node will have one or several addresses per 443 interface according to the number of prefixes announced on the 444 link(s) it is connected to. Also, the two interfaces can be 445 connected to the same link as well as to different link. When 446 considering such a multihoming management, it might imply 447 different issues. Once more this node will have to make a choice 448 between its different addresses, but the interface on which the 449 address is bound to will be a supplementary parameter in the 450 address selection. The different characteristics of each interface 451 may help to decide first which interface to use. 453 The critical points that can be highlighted here are the 454 following: 456 * Choice of the router: each access router the node is be 457 connected to might have different capacity. As an example, if 458 the node is inside a mobile network and is connected to two 459 mobile routers, each mobile router may implement different 460 technology on their egress interface. This would have a strong 461 impact on the node traffic. 463 * Load Balancing: As the node has several available interfaces at 464 the same time, it is interesting to simultaneously use them for 465 different flows. To do so, the node must be able to choose a 466 different interface for each new communication (through the 467 address selection). 469 * Load Sharing: This benefit is mainly for the network side: if 470 different access routers or routes can be used to forward the 471 node traffic, it will share the traffic load on the network. 473 * Lost of a prefix: If the node looses one of its prefix, it can 474 not use the corresponding address anymore. So the node needs a 475 recovery mechanism allowing to remove all current communication 476 to one of its other IPv6 address. The time needed for the 477 detection of the prefix failure and the time to redirect 478 communications to one of its other addresses is considered as 479 critical. 481 * Interface failure: If one of the used interface breaks down 482 (lost of network connection of access router is not reachable 483 anymore), the node must be able to redirect all its flows from 484 that interface to one of the alive interface. The time needed 485 to discover the failure and to redirect each flow has to be 486 considered. The scalability of such a solution is also an 487 issue. 489 * Mobility of the node: If the node moves to a new point of 490 attachment in another subnet, it will need to change its IPv6 491 addresses. In order to maintain all its previous communication, 492 it will need to redirect the flows to its new localization, 493 whatever the old address used for the flow. The scalability of 494 the redirection can also be considered here. 496 7. Acknowledgments 498 References 500 [1] Elmalki, K. and H. Soliman, "Simultaneous Bindings for Mobile 501 IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-05.txt 502 (work in progress), October 2003. 504 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 505 draft-ietf-seamoby-terminology-04 (work in progress), April 506 2003. 508 [3] Draves, R. and D. Thaler, "Default Router Preferences, 509 More-Specific Routes, and Load Sharing", 510 draft-ietf-ipv6-router-selection-03 (work in progress), December 511 2003. 513 [4] Hinden, R. and D. Thaler, "IPv6 Host to Router Load Sharing", 514 draft-ietf-ipv6-host-load-sharing-01 (work in progress), January 515 2004. 517 [5] Ng, C., "Multihoming Issues in Network Mobility Support", 518 draft-xxx-nemo-multihoming-00 (work in progress), Feb 2004. 520 [6] Montavont, N., "Analysis of Multihoming in Mobile IPv6", 521 draft-xxx-nemo-multihoming-00 (work in progress), Feb 2004. 523 [7] Fikouras, N., "Mobile IPv4 Flow Mobility", 524 draft-nomad-mip4-flow-mobility-problem-statement-00.txt (work in 525 progress), Feb 2004. 527 [8] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay 528 Networks", Journal Mobile Networks and Applications, vol. 3, 529 number 4, pages 335-350, 1998. 531 Authors' Addresses 533 Ernst Thierry 534 WIDE at Keio University 535 Jun Murai Lab., Keio University. 536 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 537 Kawasaki, Kanagawa 212-0054 538 Japan 540 Phone: +81-44-580-1600 541 Fax: +81-44-580-1437 542 EMail: ernst@sfc.wide.ad.jp 543 URI: http://www.sfc.wide.ad.jp/~ernst/ 545 Nicolas Montavont 546 LSIIT - Univerity Louis Pasteur 547 Pole API, bureau C444 548 Boulevard Sebastien Brant 549 Illkirch 67400 550 FRANCE 552 Phone: (33) 3 90 24 45 87 553 EMail: montavont@dpt-info.u-strasbg.fr 554 URI: http://www-r2.u-strasbg.fr/~montavont/ 556 Wakikawa Ryuji 557 Keio University 558 Jun Murai Lab., Keio University. 559 5322 Endo 560 Fujisawa, Kanagawa 252-8520 561 Japan 563 Phone: +81-466-49-1100 564 Fax: +81-466-49-1395 565 EMail: ryuji@sfc.wide.ad.jp 566 URI: http://www.mobileip.jp/ 567 Paik, Eun Kyoung 568 Seoul National University 569 Multimedia Communications Lab., Seoul National Univ. 570 Shillim-dong, Kwanak-gu 571 Seoul 151-744 572 Korea 574 Phone: +82-2-880-1832 575 Fax: +82-2-872-2045 576 EMail: eun@mmlab.snu.ac.kr 577 URI: http://mmlab.snu.ac.kr/~eun/ 579 Chan-Wah Ng 580 Panasonic Singapore Laboratories Pte Ltd 581 Blk 1022 Tai Seng Ave #06-3530 582 Tai Seng Industrial Estate 583 Singapore 534415 584 SG 586 Phone: +65 65505420 587 EMail: cwng@psl.com.sg 589 Koojana Kuladinithi 590 University of Bremen 591 ComNets-ikom,University of Bremen. 592 Otto-Hahn-Allee NW 1 593 Bremen, Bremen 28359 594 Germany 596 Phone: +49-421-218-8264 597 Fax: +49-421-218-3601 598 EMail: koo@comnets.uni-bremen.de 599 URI: http://www.comnets.uni-bremen.de/~koo/ 601 Thomas Noel 602 LSIIT - Univerity Louis Pasteur 603 Pole API, bureau C444 604 Boulevard Sebastien Brant 605 Illkirch 67400 606 FRANCE 608 Phone: (33) 3 90 24 45 92 609 EMail: noel@dpt-info.u-strasbg.fr 610 URI: http://www-r2.u-strasbg.fr/~noel/ 612 Intellectual Property Statement 614 The IETF takes no position regarding the validity or scope of any 615 intellectual property or other rights that might be claimed to 616 pertain to the implementation or use of the technology described in 617 this document or the extent to which any license under such rights 618 might or might not be available; neither does it represent that it 619 has made any effort to identify any such rights. Information on the 620 IETF's procedures with respect to rights in standards-track and 621 standards-related documentation can be found in BCP-11. Copies of 622 claims of rights made available for publication and any assurances of 623 licenses to be made available, or the result of an attempt made to 624 obtain a general license or permission for the use of such 625 proprietary rights by implementors or users of this specification can 626 be obtained from the IETF Secretariat. 628 The IETF invites any interested party to bring to its attention any 629 copyrights, patents or patent applications, or other proprietary 630 rights which may cover technology that may be required to practice 631 this standard. Please address the information to the IETF Executive 632 Director. 634 Full Copyright Statement 636 Copyright (C) The Internet Society (2004). All Rights Reserved. 638 This document and translations of it may be copied and furnished to 639 others, and derivative works that comment on or otherwise explain it 640 or assist in its implementation may be prepared, copied, published 641 and distributed, in whole or in part, without restriction of any 642 kind, provided that the above copyright notice and this paragraph are 643 included on all such copies and derivative works. However, this 644 document itself may not be modified in any way, such as by removing 645 the copyright notice or references to the Internet Society or other 646 Internet organizations, except as needed for the purpose of 647 developing Internet standards in which case the procedures for 648 copyrights defined in the Internet Standards process must be 649 followed, or as required to translate it into languages other than 650 English. 652 The limited permissions granted above are perpetual and will not be 653 revoked by the Internet Society or its successors or assignees. 655 This document and the information contained herein is provided on an 656 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 657 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 658 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 659 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 660 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 662 Acknowledgment 664 Funding for the RFC Editor function is currently provided by the 665 Internet Society.