No Specific Working Group T. Ernst
Internet-Draft WIDE at Keio University
Expires: January 17, 2005 N. Montavont
LSIIT - ULP
R. Wakikawa
Keio University
E. Paik
Seoul National University
C. Ng
Panasonic Singapore Labs
K. Kuladinithi
University of Bremen
T. Noel
LSIIT - ULP
July 19, 2004
Goals and Benefits of Multihoming
draft-ernst-generic-goals-and-benefits-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 January 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Ernst, et al. Expires January 17, 2005 [Page 1]
Internet-Draft Goals and Benefits of Multihoming July 2004
Abstract
This document attempts to define the goals and benefits of
multihoming for fixed and mobile hosts and routers. Those goals and
benefits are illustrated with a set of real-life scenarios.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Goals and Benefits of Multihoming . . . . . . . . . . . . . . 4
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Classification and Resulting Issues . . . . . . . . . . . . . 8
5.1 Case 1: One Interface, Multiple Prefixes . . . . . . . . . 8
5.2 Case 2: Several Interfaces . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 16
Ernst, et al. Expires January 17, 2005 [Page 2]
Internet-Draft Goals and Benefits of Multihoming July 2004
1. Introduction
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 need to 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 technology the most
appropriate 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 should thus be able
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 demonstrate 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. The readers should note that we implicitly
assumed multihoming in an IPv6 enviroment when describing the goals
and benefits, though some of them may be applicable to IPv4 as well.
Issues pertaining to site multihoming in fixed networks are discussed
in [3]. Mobility issues pertaining to mobile nodes and mobile
networks are respectively discussed in companion drafts [7] and [6].
The readers may refer to [8] 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 emphasizing the goals and benefits of
multihoming. Then, we describe some real-life scenarios to
illustrate the goals and benefits of multihoming. Next follows a
differentiation between cases where a multihomed node has a single
interface and the cases where it has multiple interfaces and we
conclude with the description of possible configurations at the
network layer.
2. Terminology
This draft is based on the terminology defined in [2]. For the
purpose of clarity, we remind the definition of interface. Terms
related to multihoming are not known to be defined in existing IETF
Ernst, et al. Expires January 17, 2005 [Page 3]
Internet-Draft Goals and Benefits of Multihoming July 2004
RFCs.
Interface (from [2])
A node's point of attachment to a link.
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.
Multihomed Network
From the above definition, it follows that a network is multihomed
when either the network is simultaneously connected to the
Internet via more than one router, or when a router is
multi-prefixed or multi-interfaced.
3. Goals and Benefits of Multihoming
We cannot distinguish the goals from the benefits of multihoming, but
there are several situations where it is either advisable or
beneficial to be multihomed:
Permanent and Ubiquitous Access
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.
Redundancy/Fault-Recovery:
To act upon failure of one point of attachment, i.e. the
functions of a system component 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.
Ernst, et al. Expires January 17, 2005 [Page 4]
Internet-Draft Goals and Benefits of Multihoming July 2004
Load Sharing:
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 [5].
Load Balancing:
To balance load between multiple point of attachments
(simultaneously active or not), usually chosing the less loaded
connection or according to preferences on the mapping between
flows and interfaces.
Bi-casting (n-casting):
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 is useful not to drop packets when a mobile
node changes its interface during communication [1].
Preference Settings:
To provide the user or the application or the ISP the ability to
choose the preferred transmission technology or access network.
for matters of cost, efficiency, politics, bandwidth requirement,
delay, etc.
Increased Bandwidth
To provide the user or the application with more bandwidth than is
available with any one interface. Multiple interfaces connected
to different links can increase the total availble bandwith.
When considering these goals/benefits, one has to consider whether
these goals can be achieved with transparency or without
transparency. Transparency is achieved when switching between
interfaces does not cause the disruption of on-going sessions.
4. Scenarios
The following real-life scenarios highlight the benefits of
multihoming. Each scenario usually yields more than one of the
benefits outlined in the above section. All scenarios focus on
wireless technologies though no mobility management may be involved
(one can use wireless access at office).
Ernst, et al. Expires January 17, 2005 [Page 5]
Internet-Draft Goals and Benefits of Multihoming July 2004
The first scenario focuses on using two wireless interfaces for the
purpose of increasing 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 redundancy and
bi-casting.
Scenario 1: Load Balancing, Increased Bandwidth (no mobility)
Alice 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. Alice uses a WLAN connection
to download the necessary data. However, there is not enough time
and Alice decides to accelerate the download. Her notebook is
equipped with an additional WLAN interface. Alice decides to use
this additional WLAN interface to connect to another access point,
and distribute the different download flows between the wireless
interfaces to accelerate the download.
Scenario 2: Preference Settings and Transparent Flow Handoffs (with
mobility)
Mr. Smith 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. Mr. Smith decides to buy a ticket. However,
the ticket reservation service is only available via a wide area
cellular link of a specific provider. While Mr. Smith is
downloading the news and accessing the train ticket reservation
service, he receives a phone call over a wide area cellular link.
Mr. Smith 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.
Scenario 3: Preference Settings for House Networking (fixed)
Mr. Verne works at home for a publishing company. He has an
in-house network and get access to the Internet via ADSL, a public
802.11b WLAN from the street and satellite. The satellite link he
has access to is only downward but is extremely cheap for TV
broadcasting. He has noticed the 802.11b is unreliable at some
point in time during the day, so he chooses to send requests and
Ernst, et al. Expires January 17, 2005 [Page 6]
Internet-Draft Goals and Benefits of Multihoming July 2004
periodic refreshments for joining the TV broadcasting via ADSL
rather the 802.11b although 802.11b in the street is free. On the
other hand, he has configured his network to use the 802.11b link
at night to publish web content comprising video. Once a week, he
communicate with overseas peer staff by videoconferencing. Voice
being the most important, he has configured his VoIP session over
ADSL. Video is sent at maximum rate when 802.11b is working fine,
otherwise a picture is periodically refreshed over ADSL.
Scenario 4: Load Balancing, Preference Settings, Increased Bandwidth
(no mobility)
An ambulance is called at the scene of a car accident. A
paramedic 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
communication.
Scenario 5: Ubiquitous Access and Load Sharing (with mobility)
Jules drives his car to a new place and constantly keeps some sort
of Internet access through one access technology. 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.
Ernst, et al. Expires January 17, 2005 [Page 7]
Internet-Draft Goals and Benefits of Multihoming July 2004
Scenario 6: Redundancy and Bi-Casting (with no mobility)
Dr. Catherine 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 action and a robot performs her
operation in the battle field. Since the operation is critical,
the delivery of patient images and Catherine's action is done by
bi-casting from/to multiple interfaces. So in case one of the
interface fails, the long-distance operation can be continued.
5. Classification and Resulting Issues
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.
5.1 Case 1: One Interface, Multiple Prefixes
The single-interfaced node is multihomed when several prefixes are
advertised on its interface. The node must therefore configure
several IPv6 addresses. The node has to choose which address to use
when an IPv6 communication is established (e.g. open a TCP
connection). This choice can be influenced by many parameters: user
preference, different price on prefixes, preference flag in Router
Advertisement, destination prefix, etc. An address selection
mechanism is needed.
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 the fact that 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.
This multihomed configuration may yield different issues / benefits
to the node. We now analyse the benefits and the process needed on
this node:
o Ubiquitous Access
Ubiquitous access cannot be guaranteed when the node looses
Ernst, et al. Expires January 17, 2005 [Page 8]
Internet-Draft Goals and Benefits of Multihoming July 2004
Internet connectivity through its sole interface (e.g. the node
is going outside the coverage area of its access point).
o Redundancy
In case of failure of one IPv6 prefix, one of the address of the
node will not be valid anymore. The fact that the node has
another address built with other prefixes should allow it to
recover this sort of failure. However transparency may not be
achieved since on-going sessions using the invalid address would
have to be terminated, and 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
address. The time needed for the detection of the prefix failure
and the time to redirect communications to one of its other
addresses is considered as critical.
o Load sharing
Load Sharing can be performed in the network, according to the
address used by the node. The choice of the address used by the
node and the router selection can be influenced by the load
sharing rules. This benefit is mainly for the network side: if
different access routers or routes can be used to forward the node
traffic, it will share the traffic load on the network.
o Load balancing
As the node has only one interface, load balancing (share traffic
between node's interface) cannot be performed.
o Bi-casting
Bi-casting can be performed to ensure the delivery of packets on
the node. To do so, more than one IPv6 address must be used
simultaneously for one flow. Although packets can not be
distributed to different interfaces on the node, bi-casting would
allow the node to seamlessly change the address used on the node
if such a protocol is used to change address of on-going flow.
Time synchronization can be an issue in this case. If we use
different access technologies or routes for each casting, the
round trip time (RTT) can differ from casting to casting. Thus
the receiver will receive the same contents in different time.
o Preference
The source address can be chosen according to preferences set up
by the user, or according to preferences set up in the network
Ernst, et al. Expires January 17, 2005 [Page 9]
Internet-Draft Goals and Benefits of Multihoming July 2004
(such as with the default router preferences option introduced in
Router Advertisement [4], or by the ISP.
o Increased Bandwidth
With only one interface connected to a link, the node generally
will not be able to enjoy increased bandwidth with multiple
prefixes. However, this benefit might be gained indirectly. For
instance, by alternating between different addresses, the total
throughput may be higher (eg. due to load sharing). Also, some
web and file transfer servers limit transfer bandwidths based on
the client's address. By using different addresses to connect to
the same server, the node may also see an increase in file
transfer rate.
5.2 Case 2: Several Interfaces
The node may use its multiple interfaces either alternatively or
simultaneously. If it alternatively uses its interfaces, the node is
either multihomed if multiple prefixes are advertised on its current
link (case 1, one interface), or not multihomed if only one prefix is
advertised on its current link. We will thus consider that the node
uses multiple interfaces simultaneously. The node must thus
configure at least one IPv6 address per interface (or several
addresses per interface if several prefixes are announced on the
link(s) it is connected to). Also, multiple interfaces can be
connected to the same link as well as to different links. These
configurations will imply different issues.
An address selection mechanism is also needed, but this time the
interface on which the address is bound to will be a supplementary
parameter in the address selection. The different characteristics of
each interface may help to decide first which interface to use.
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
(ubiquitous access) and the capacity and specification of each
technology.
This multihomed configuration may yield different benefits to the
node. We now analyse the benefits and the process needed on this
node:
o Ubiquitous Access
It is easier to guarantee ubiquitous access when the node has
Ernst, et al. Expires January 17, 2005 [Page 10]
Internet-Draft Goals and Benefits of Multihoming July 2004
multiple interfaces since several technologies may be available at
the same time. However, the node must be able to use all
technologies at the same time and to maintain Internet
connectivity while a technology can not be used. It is obvious
that the node must have the choice to use any of the available
technologies, and that this choice must not prevent the node to
redirect a communication to another interface/address.
o Redundancy
Two levels of redundancy can be seen in this case: either one
address of one interface is not valid anymore (e.g. because the
corresponding prefix is not advertised on the link), or the node
can lose its internet connectivity through one interface. In the
former case, the fact that another IPv6 address is available on
the interface would allow the node to switch addresses for
on-going flows. In the latter case, the fact that the node has
another connection to the internet through another interface would
allow it to redirect on-going flow from the previous interface to
the new one. Either case, the node needs to change the IPv6
address for on-going session from the no longer valid address to
one of the address available on the target interface. The
redirection will trigger a decision process to choose the best
target interface to redirect the flow. In both cases,
transparency of the addressses switching is an important issue.
Loss of a prefix: If the node loses one of its prefix, it can no
longer use the corresponding address anymore. So the node needs a
recovery mechanism that allows it to transfer all current
communications to one of its other IPv6 address(es). The time
needed for the detection of the prefix failure and the time to
redirect communications to one of its other addresses may be
critical.
Interface failure: If one of the used interface breaks down (loss
of network connection or access router is not reachable anymore),
the node must be able to redirect all its flows from that
interface to one of the alive interface. The time needed to
discover the failure and to redirect each flow has to be
considered. The scalability of such a solution is also an issue.
Mobility of the node: If the node moves to a new point of
attachment in another subnet, it will need to change its IPv6
addresses. In order to maintain all its previous communications,
it will need to redirect the flows to its new point of attachment,
whatever the old address used for the flow. The scalability of
the redirection can also be considered here.
Ernst, et al. Expires January 17, 2005 [Page 11]
Internet-Draft Goals and Benefits of Multihoming July 2004
o Load Sharing
This benefit is mainly for the network side: if different access
routers or routes can be used to forward traffic going into and
out of the node, they can share the traffic load on the network.
If the node uses several addresses at the same time for its
on-going sessions, load sharing can be performed in the network.
This goal can be a parameter that helps the source address
selection.
o Load balancing
Load balancing can be achieved on the node if several interfaces
are used simultaneously. Several interfaces can be used to spread
the traffic load on the node. This implies the choice of the IPv6
address to use for each flow and the ability to choose a different
addresss for each flow.
o Bi-casting
Bi-casting might be used to ensure the packets delivery on the
node. It also allow seamless redirection between two addresses /
interfaces with zero packets loss. Bi-casting can be performed if
several IPv6 addresses can be simultaneously used for one flow.
One entity between the CN (included) and the node (excluded) must
duplicate the traffic to the destination node.
o Preferences
Interface and address selection is required. The problem can be
seen exactly as in the first case (the node has only one
interface) if we consider that the interface preference is a
parameter for the address selection. Therefore in this case, the
interface selection/preference is a supplementary parameter in the
address selection algorithm.
o Increased Bandwidth
With multiple interface connected to a link, the node generally
will be able to enjoy increased bandwidth.
6. Acknowledgments
7 References
[1] Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile IPv6
Ernst, et al. Expires January 17, 2005 [Page 12]
Internet-Draft Goals and Benefits of Multihoming July 2004
Fast Handovers", draft-elmalki-mobileip-bicasting-v6-05 (work in
progress), November 2003.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[3] Abley, J., Black, B. and V. Gill, "Goals for IPv6
Site-Multihoming Architectures", RFC 3582, August 2003.
[4] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", draft-ietf-ipv6-router-selection-04 (work
in progress), June 2004.
[5] Hinden, R., "IPv6 Host to Router Load Sharing",
draft-ietf-ipv6-host-load-sharing-02 (work in progress), May
2004.
[6] Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in
Network Mobility Support", draft-ietf-nemo-multihoming-issues-00
(work in progress), July 2004.
[7] Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of
Multihoming in Mobile IPv6",
draft-montavont-mobileip-multihoming-pb-statement-01 (work in
progress), Feb 2004.
[8] Fikouras, N., "Mobile IPv4 Flow Mobility Problem Statement",
draft-nomad-mip4-flow-mobility-pb-00.txt (work in progress), Feb
2004.
Authors' Addresses
Ernst Thierry
WIDE at Keio University
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/
Ernst, et al. Expires January 17, 2005 [Page 13]
Internet-Draft Goals and Benefits of Multihoming July 2004
Nicolas Montavont
LSIIT - Univerity Louis Pasteur
Pole API, bureau C444
Boulevard Sebastien Brant
Illkirch 67400
FRANCE
Phone: (33) 3 90 24 45 87
EMail: montavont@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~montavont/
Wakikawa Ryuji
Keio University
Jun Murai Lab., 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.mobileip.jp/
Paik, Eun Kyoung
Seoul National University
Multimedia and Mobile communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-1832
Fax: +82-2-872-2045
EMail: eun@mmlab.snu.ac.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: cwng@psl.com.sg
Ernst, et al. Expires January 17, 2005 [Page 14]
Internet-Draft Goals and Benefits of Multihoming July 2004
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/
Ernst, et al. Expires January 17, 2005 [Page 15]
Internet-Draft Goals and Benefits of Multihoming July 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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 Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ernst, et al. Expires January 17, 2005 [Page 16]