| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2006.
Copyright © The Internet Society (2005).
This document attempts to define the goals and benefits of multihoming for fixed and mobile nodes (hosts and routers), i.e. from a node point of view, as investigated in the Monami6 WG, and not from a site point of view as investigated in the Shim6 WG. Those goals and benefits are illustrated with a set of scenarios. This document is generic in the sense that the benefits of node multihoming can be shared by both fixed end nodes and mobile end nodes. It is intended to satisfy the first item as specified on the Monami6 charter and as such, working group approval as a working group document will be sought.
1.
Introduction
2.
Terminology
3.
Scenarios and Motivations
3.1.
Need to Accelerate Transmission
3.2.
Need to Redirect Established Sessions
3.3.
Need to Set Up Preferences
3.4.
Need for Reliability and Ubiquity
3.5.
Need for Ubiquitous Access
3.6.
Need for Reliability
4.
Goals and Benefits of Multihoming
4.1.
Permanent and Ubiquitous Access
4.2.
Reliability
4.3.
Load Sharing
4.4.
Load Balancing/Flow Distribution
4.5.
Preference Settings
4.6.
Aggregate Bandwidth
5.
Classification
5.1.
Case 1: One Interface, Multiple Prefixes
5.2.
Case 2: Several Interfaces
6.
Issues
6.1.
Source Address Selection
6.2.
Recovery Delay
6.3.
Change of Traffic Characteristics
6.4.
Address Change
7.
Conclusion
8.
Acknowledgments
9.
References
Appendix A.
Change Log From Previous Version
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
New equipments shipped on the market now often integrate several access technologies (both wired and wireless). The main purpose of this integration is to federate all means of communications in order to access the Internet ubiquitously (from everywhere and at any time) as no single technology can be expected to be deployed everywhere. Flows may thus be redirected from one interface to the other due to the loss of connectivity or change of the network conditions.
Several access technologies are also integrated in order to increase bandwidth availability or to select the the most appropriate technology according to the type of flow or choices of the user. Basically, each network interface has different cost, performance, bandwidth, access range, and reliability. Users are also willing to select the most appropriate set of network interface(s) depending on the network environment, particularly in wireless networks which are mutable and less reliable than wired networks. Users should also be able to select the most appropriate interface per communication type or to combine a set of interfaces to get sufficient bandwidth.
The purpose of this document is to emphasize the goals and benefits of multihoming for fixed and mobile hosts and routers in a generic fashion, i.e. without focusing on issues pertaining to hosts, or routers, or mobility.
Issues pertaining to site multihoming in fixed networks are discussed in [1] (Abley, J., Black, B., and V. Gill, “Goals for IPv6 Site-Multihoming Architectures,” August 2003.). Mobility issues pertaining to mobile nodes and mobile networks are respectively discussed in companion drafts [2] (Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, “Analysis of Multihoming in Mobile IPv6,” October 2005.) and [3] (Ng, C., Ernst, T., Paik, E., and M. Bagnulo, “Analysis of Multihoming in Network Mobility Support,” October 2005.). Our document is targetted to IPv6, although our analysis may be applicable to IPv4 as well. The readers may refer to [4] (Fikouras, N., “Mobile IPv4 Flow Mobility Problem Statement,” Feb 2004.) for a description of the problem specific to Mobile IPv4.
This document is organized as follows: we first define the terms used in the document before illustrating the motivations by means of some scenarios in Section 3 (Scenarios and Motivations). These scenarios are then used to emphasize the goals and benefits of multihoming in Section 4 (Goals and Benefits of Multihoming). Next follows in Section 5 (Classification) an analysis of the multihoming configurations according to two different cases (the node either has a single interface or multiple interfaces). We conclude in Section 6 (Issues) with a number of generic issues that will have to be solved for the node to benefit effectively from its multihomed configuration.
| TOC |
This draft is based on the terminology defined in [5] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.). For the purpose of clarity, we remind the definition of interface. Terms related to multihoming are not known to be defined in existing IETF RFCs.
- Interface
- A node's point of attachment to a link (from [5] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.))
- Multihomed Node
- A node (either a host or a router) is multihomed when it has several IPv6 addresses to choose between, i.e. in the following cases when it is either:
- multi-prefixed: multiple prefixes are advertised on the link(s) the node is attached to, or.
- multi-interfaced: the node has multiple interfaces to choose between, on the same link or not.
| TOC |
The following real-life scenarios highlight the motivations for multihoming. Each scenario usually yields more than one of the goals and benefits outlined in Section 4 (Goals and Benefits of Multihoming). All scenarios focus on wireless technologies though no mobility management may be involved (one can use wireless access at office).
The first scenario focuses on using two wireless interfaces for the purpose of increasing aggregate bandwidth while the second shows the usage of preference settings. The third is a combination of the first two. The fourth and fifth illustrate how multiple connections can provide ubiquitous Internet access and how load can be balanced according to some preferences. The last one illustrates reliabilty.
| TOC |
Mona is at the airport waiting to board the plane. She receives a call from her husband. This audio communication is received via a wireless local area network (WLAN) link realized over one of the available hot-spots. She knows this is going to be a long flight and wishes to catch up on some work. Mona uses a WLAN connection to download the necessary data. However, there is not enough time and Mona decides to accelerate the download. Her notebook is equipped with an additional WLAN interface. Mona decides to use this additional WLAN interface to connect to another access point, and distribute the different download flows between the two wireless interfaces.
| TOC |
Oliver is on his way to work waiting at a train station. He uses this opportunity and the presence of a WLAN hot-spot to download the news from his favorite on-line news channel. His train is announced. Oliver decides to buy a ticket. However, the ticket reservation service is only available via a wide area cellular link of a specific provider. While Oliver is downloading the news and accessing the train ticket reservation service, he receives a phone call over a wide area cellular link. Oliver decides he wishes to initiate a video flow for this communication. The bandwidth and traversal delay of the wide area cellular link is not adequate for the video conference, so both flows (video/audio) are transferred to the WLAN link provided by the hot-spot. This transfer occurs transparently and without affecting any other active flows.
| TOC |
Nami works at home for a publishing company. She has an in-house network and get access to the Internet via ADSL, a public 802.11b WLAN from the street and satellite. She has subscribed to the cheapest ADSL service with limited uplink bandwidth. Also, the satellite link she has access to is downlink only, but it is extremely cheap for TV broadcasting. She has noticed the 802.11b is unreliable at some point in time during the day, so she chooses to send requests and periodic refreshments for joining the TV broadcasting via ADSL rather than the 802.11b although 802.11b in the street is free. On the other hand, she has configured her network to use the 802.11b link at night to publish web content comprising video. Once a week, she communicates with overseas peer staff by videoconferencing. Voice being the most important, she has configured her VoIP session over ADSL. Video is sent at maximum rate when 802.11b is working fine, otherwise the video is sent at lower rate.
| TOC |
Alice is a paramedic. Her ambulance is called at the scene of a car accident. She initiates a communication to a hospital via a wide area cellular link for the relay of low bit-rate live video from the site of the crash to assess the severity of the accident. It is identified that one of the passengers has suffered a severe head injury. The paramedic decides to consult a specialist via video conferencing. This session is initiated from the specialist via the same wide area cellular link. Meanwhile, the paramedic requests for the download of the patient medical records from the hospital servers. The paramedic decides in mid-session that the wide area cellular link is too slow for this download and transfers the download to the ambulance satellite link. Even though this link provides a significantly faster bit rate it has a longer traversal delay and only down-link is available. For this, only the down-stream of the download is transferred while up-stream proceeds over the wide area cellular link. Connectivity with the ambulance is managed over a WLAN link between the paramedic and the ambulance. Even though the paramedic has performed a partial hand-off for the transfer of the download down-stream to the satellite link, the upstream and the video conferencing session remains on the wide area cellular link. This serves best the time constraint requirements of the real time communications.
| TOC |
Max drives his car and constantly keeps some sort of Internet connectivity through one of the available access technologies. His car navigator downloads road information from the Internet and his car-audio plays on-line audio streaming. When his car passes an area where both high-data-rate WLAN and low-data-rate cellular network are available, it distributes load to the WLAN access and the cellular network access. When his car passes an area where only a wide coverage-range cellular network is available, it maintains its connection via the cellular network.
| TOC |
Dr. Ingrid performs an operation via long-distance medical system. She watches a patient in a battle field over the screen which delivers real-time images of the patient. Sensors on her arms deliver her operational actions and a robot performs the actual operation in the battle field. Since the operation is critical, the delivery of patient images and Dr. Ingrid's action is done by bi-casting from/to multiple interfaces bound to a distinct technology or distinct radio range. So in case packets are delayed or one of the interface fails to maintain connectivity to the network, her distant operation can be continued.
| TOC |
We cannot really distinguish the goals from the benefits of multihoming, but there are several situations where it is either advisable or beneficial to be multihomed. We use the scenarios presented in the previous section to highlight the goals and benefits of multihoming. Figure 1 (Goals Applying to Each Scenario) summarizes which goals apply to any of the scenario introduced in section Section 3 (Scenarios and Motivations).
+========================================+=======================+ | | Scenarios | | +---+---+---+---+---+---+ | Goals | 1 | 2 | 3 | 4 | 5 | 6 | +========================================+===+===+===+===+===+===+ | Ubiquitous Access | ? | ? | | o | o | | +----------------------------------------+---+---+---+---+---+---+ | Reliability | | | o | o | o | o | +----------------------------------------+---+---+---+---+---+---+ | Flow Redirection | | o | o | o | o | | +----------------------------------------+---+---+---+---+---+---+ | Load Sharing | | | | | o | | +----------------------------------------+---+---+---+---+---+---+ | Load Balalancing | o | | o | o | | | +----------------------------------------+---+---+---+---+---+---+ | Preference Settings | | o | o | o | | | +----------------------------------------+---+---+---+---+---+---+ | Aggregate Bandwidth | o | | | o | | | +========================================+===+===+===+===+===+===+ | Usages: F=Fixed N=Nomadic M=Mobile | N | N | F | M | M | F | +========================================+===+===+===+===+===+===+
| Figure 1: Goals Applying to Each Scenario |
| TOC |
To provide an extended coverage area via distinct access technologies. Multiple interfaces bound to distinct technologies can be used to ensure a permanent connectivity is offered, anywhere, anytime, with anyone.
| TOC |
To act upon failure at one point of attachment, i.e. the functions of a system component (e.g. interface, access network) are assumed by secondary system components when the primary component becomes unavailable (e.g. failure). Connectivity is guaranteed as long as at least one connection to the Internet is maintained.
A potential means is to duplicate a particular flow simultaneously through different routes. This minimizes packet loss typically for real-time communication and burst traffic. It also minimizes delay of packet delivery caused by congestion and achieves more reliable real-time communication than single-casting. For mobile computing, bi-casting avoids dropping packets when a mobile node changes its interface during communication [6] (Malki, K. and H. Soliman, “Simultaneous Bindings for Mobile IPv6 Fast Handovers,” July 2005.).
| TOC |
To spread network traffic load among several routes. This is achieved when traffic load is distributed among different connections between the node and the Internet [7] (Hinden, R. and D. Thaler, “IPv6 Host to Router Load Sharing,” June 2005.).
| TOC |
To separate a flow between multiple points of attachment (simultaneously active or not) of a node, usually chosing the less loaded connection or according to preferences on the mapping between flows and interfaces.
| TOC |
This goal is to provide the user, the application or the ISP the ability to choose the preferred transmission technology or access network based on cost, efficiency, policies, bandwidth requirement, delay, etc.
| TOC |
This goal is to provide the user or the application with more bandwidth. Bandwidth available to the user or the application may be limited by the underlying technology (e.g. GSM has scarce bandwidth) or by some policies (e.g. monthly rate paid by the user). Multiple interfaces connected to different links or ISPs can increase the total available bandwith.
| TOC |
From the definition of a multihomed node it follows that a multihomed node has several IPv6 addresses to choose between. In order to expose the goals and benefits to manage multihomed nodes, we propose to distinguish two main cases: either the node has only one interface, or the node has several interfaces. In the former case, the node is multihomed when multilpe prefixes are advertised. This distinction is important and sometimes subtle but the implications are important.
| TOC |
The single-interfaced node is multihomed when several prefixes are advertised on its interface. The node must therefore configure several IPv6 addresses.
A typical example is a node with an IEEE 802.11 interface, connected to an access point. The access point is connected trough an Ethernet link to two access routers. Each access router is configured to send Router Advertisements on the link and can be used as default router. Several reasons may lead to configure two access routers are on the same link: for instance, the access points may be shared between different ISPs, or two access routers may be used for redundancy or load sharing purposes. The node will then build two global IPv6 addresses on its interface.
We now analyse which of the goals detailed in Section 4 (Goals and Benefits of Multihoming) can be met with this configuration.
| TOC |
In this case, the node may use its multiple interfaces either alternatively or simultaneously. If used simultaneously, the node uses several IPv6 addresses at the same time (at least one address per interface, or several if several prefixes are announced on the link(s) it is connected to). If used alternatively, the node may switch between its interfaces (e.g, one at a time), which is the case described above in Section 5.1 (Case 1: One Interface, Multiple Prefixes). In the paragraphs below, we assume that multiple interfaces are used simultaneously. We also note that multiple interfaces can be connected to the same link as well as to different links. These configurations will imply different issues. All these multihomed configurations may yield different benefits to the node.
A typical example is a node with two interfaces, each one on a different technology (e.g. a WLAN IEEE 802.11b interface and a 3GPP GPRS interface), in order to benefit from a better coverage area and the characteristics of each technology.
We now analyse how each of the goals listed in Section 4 (Goals and Benefits of Multihoming) can be met with such multihomed configuration:
| TOC |
In this section, we attempt to list a number of generic issues that will have to be solved in order to meet the multihoming goals.
Figure 2 (Issues and their Importance for Each Case) summarizes which issues apply to each of the case detailed in the previous section. The sign '+', '-' or '=' indicated is the issue is more important, less important, or equally important to solve for the case under consideration
+====================================+=====+=====+ | | Cases | | +-----+-----+ | Issues | (1) | (2) | +====================================+=====+=====+ | Source Address Selection | o = | o = | +------------------------------------+-----+-----+ | Recovery Delay | o | o + | +------------------------------------+-----+-----+ | Change of e2e Path Characteristics | o - | o + | +------------------------------------+-----+-----+ | Address Change | o + | o + | +------------------------------------+-----+-----+ | XXXX MORE TO COME +------------------------------------+-----+-----+ | XXXX MORE TO COME +====================================+=====+=====+
| Figure 2: Issues and their Importance for Each Case |
| TOC |
The multihomed node has several addresses. The appropriate address must be chosen when an IPv6 communication is established (e.g. when a TCP connection is opened). This choice can be influenced by many parameters: user preferences, ingress filtering, preference flag in Router Advertisement, destination prefix, type of interface, link characteristics, etc. An address selection mechanism is needed for this.
| TOC |
The time needed for detecting an address has become invalid and the time to redirect communications to one of its other addresses is considered as critical.
However, transport sessions with multihoming capabilies such as SCTP may be able to continue easily since SCTP has built-in transmission rate control mechanims to take into account the differences between two paths.
| TOC |
The change of path for a specific session (e.g. due to change of interface) may cause changes on the end-to-end path characteristics (higher delay, different PMTU, etc). This could have an impact on upper layer protocols such as transport protocols (particularly TCP) or applications that are sensitive to changes.
| TOC |
In some situations, it will be necessary to divert some or all of the sessions from one interface or prefix to another (e.g. due to loss of network connection or the access router becoming unreachable - this could be particularly frequent for mobile nodes). With no support mechanism, an address change would cause on-going sessions using the invalid former address to terminate, and to be restarted using the new address. To avoid this, the node needs a recovery mechanism allowing to redirect all current communication to one of its other IPv6 addresses.
In the case of a mobile node changing its point of attachment using the same interface, all flows must be redirected to the new location in order to maintain sessions. A mobility management solution may be required, such as Mobile IPv6 [9] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) for mobile hosts or NEMO Basic Support [10] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.) for mobile routers. Additional mechanisms may be needed if the node was using several addresses on its old link, such as which flow to redirect, which address must be associated with the new address(es). The scalability of the operations involved in the redirection of flows may also be an issue, if we consider that the node had several addresses on the old link and several flows and/or correspondents. Issues pertaining to Mobile IPv6 and NEMO Basic Support are explained in companion drafts [2] (Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, “Analysis of Multihoming in Mobile IPv6,” October 2005.) and [3] (Ng, C., Ernst, T., Paik, E., and M. Bagnulo, “Analysis of Multihoming in Network Mobility Support,” October 2005.) respectively.
| TOC |
In this document we show the concrete need for multihoming at the level of the end node. We emphasized the needs and goals of having multiple interfaces at the communicating end node. Such interfaces could be used as one as the replacement of the other (ubiquitous access to the Internet, reliability) or simultaneously (load sharing, load balancing/flow distribution, preference settings or aggregate bandwidth).
Such goals are motivated for fixed nodes and mobile nodes, but the need prevail for mobile nodes (hosts and routers). Goals can only be met once some issues are solved. Issues specific to mobile hosts and mobile routers are investigated in documents of the MONAMI6 and NEMO working groups at the IETF.
| TOC |
We would like to thank all the people who have provided comments on this draft, and also co-authors of earlier documents in which authors of this present document have been engaged. As such, we would like to thank Niko A. Fikouras, Hesham Soliman, Ken Nagami, and many others.
| TOC |
| [1] | Abley, J., Black, B., and V. Gill, “Goals for IPv6 Site-Multihoming Architectures,” RFC 3582, August 2003. |
| [2] | Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, “Analysis of Multihoming in Mobile IPv6,” draft-montavont-mobileip-multihoming-pb-statement-05 (work in progress), October 2005. |
| [3] | Ng, C., Ernst, T., Paik, E., and M. Bagnulo, “Analysis of Multihoming in Network Mobility Support,” draft-ietf-nemo-multihoming-issues-04 (work in progress), October 2005. |
| [4] | Fikouras, N., “Mobile IPv4 Flow Mobility Problem Statement,” draft-nomad-mip4-flow-mobility-pb-00.txt (work in progress), Feb 2004. |
| [5] | Manner, J. and M. Kojo, “Mobility Related Terminology,” RFC 3753, June 2004. |
| [6] | Malki, K. and H. Soliman, “Simultaneous Bindings for Mobile IPv6 Fast Handovers,” draft-elmalki-mobileip-bicasting-v6-06 (work in progress), July 2005. |
| [7] | Hinden, R. and D. Thaler, “IPv6 Host to Router Load Sharing,” draft-ietf-ipv6-host-load-sharing-04 (work in progress), June 2005. |
| [8] | Draves, R. and D. Thaler, “Default Router Preferences and More-Specific Routes,” draft-ietf-ipv6-router-selection-07 (work in progress), January 2005. |
| [9] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004. |
| [10] | Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” RFC 3963, January 2005. |
| TOC |
| TOC |
| Thierry Ernst | |
| Keio University / WIDE | |
| Jun Murai Lab., Keio University. | |
| K-square Town Campus, 1488-8 Ogura, Saiwa-Ku | |
| Kawasaki, Kanagawa 212-0054 | |
| Japan | |
| Phone: | +81-44-580-1600 |
| Fax: | +81-44-580-1437 |
| Email: | ernst@sfc.wide.ad.jp |
| URI: | http://www.sfc.wide.ad.jp/~ernst/ |
| Nicolas Montavont | |
| Ecole Nationale Superieure des telecommunications de Bretagne | |
| 2, rue de la chataigneraie | |
| Cesson Sevigne 35576 | |
| France | |
| Phone: | (+33) 2 99 12 70 23 |
| Email: | nicolas.montavont@enst-bretagne.fr |
| URI: | http://www-r2.u-strasbg.fr/~montavont/ |
| Ryuji Wakikawa | |
| Keio University | |
| Department of Environmental Information, Keio University. | |
| 5322 Endo | |
| Fujisawa, Kanagawa 252-8520 | |
| Japan | |
| Phone: | +81-466-49-1100 |
| Fax: | +81-466-49-1395 |
| Email: | ryuji@sfc.wide.ad.jp |
| URI: | http://www.wakikawa.net/ |
| Eun Kyoung Paik | |
| KT | |
| Portable Internet Team, Convergence Lab., KT | |
| 17 Woomyeon-dong, Seocho-gu | |
| Seoul 137-792 | |
| Korea | |
| Phone: | +82-2-526-5233 |
| Fax: | +82-2-526-5200 |
| Email: | euna@kt.co.kr |
| URI: | http://mmlab.snu.ac.kr/~eun/ |
| Chan-Wah Ng | |
| Panasonic Singapore Laboratories Pte Ltd | |
| Blk 1022 Tai Seng Ave #06-3530 | |
| Tai Seng Industrial Estate | |
| Singapore 534415 | |
| SG | |
| Phone: | +65 65505420 |
| Email: | chanwah.ng@sg.panasonic.com |
| Koojana Kuladinithi | |
| University of Bremen | |
| ComNets-ikom,University of Bremen. | |
| Otto-Hahn-Allee NW 1 | |
| Bremen, Bremen 28359 | |
| Germany | |
| Phone: | +49-421-218-8264 |
| Fax: | +49-421-218-3601 |
| Email: | koo@comnets.uni-bremen.de |
| URI: | http://www.comnets.uni-bremen.de/~koo/ |
| Thomas Noel | |
| LSIIT - Univerity Louis Pasteur | |
| Pole API, bureau C444 | |
| Boulevard Sebastien Brant | |
| Illkirch 67400 | |
| FRANCE | |
| Phone: | (33) 3 90 24 45 92 |
| Email: | noel@dpt-info.u-strasbg.fr |
| URI: | http://www-r2.u-strasbg.fr/~noel/ |
| TOC |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright © The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.