One document matched: draft-ohba-mobopts-heterogeneous-requirement-00.txt
MOBOPTS Research Group A. Dutta (Ed.)
Internet-Draft Telcordia
Expires: April 20, 2006 Y. Ohba
TARI
H. Yokota
KDDI R&D Labs
H. Schulzrinne
Columbia Univ.
October 17, 2005
Problem Statement for Heterogeneous Handover
draft-ohba-mobopts-heterogeneous-requirement-00
Status of this Memo
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 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the problem statement and a set of issues and
requirement specific to heterogeneous handover. Careful
consideration needs to be given to these set of requirements while
Dutta (Ed.), et al. Expires April 20, 2006 [Page 1]
Internet-Draft Heterogeneous Handover October 2005
designing an optimized handover framework in a heterogeneous mobility
scenario. These problem statements help determine the key functions
that are responsible for delay during handover involving interdomain
and heterogeneous access technology. Analysis of these issues and
requirements can be applied to any existing mobility optimization
framework.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Handover Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4
3. Performance Requirements . . . . . . . . . . . . . . . . . . . 7
4. Handover Delay Analysis . . . . . . . . . . . . . . . . . . . 9
5. Optimizing Handover Delay . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 Normative References . . . . . . . . . . . . . . . . . . . 15
9.2 Information References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 18
Dutta (Ed.), et al. Expires April 20, 2006 [Page 2]
Internet-Draft Heterogeneous Handover October 2005
1. Introduction
Handover is a process by which a mobile node moves from one point of
attachment to another point of attachment in a network. This
handover can be primarily classified into homogeneous and
heterogeneou handover. Heterogeneous handover includes movement
between various types of wireless networks and different
administrative domains. Supporting terminal handovers across
heterogeneous access networks such as CDMA, 802.11 and GPRS is a
clear challenge, as each access network has different QoS, security
and bandwidth characteristics. Similarly movement between two
different kinds of domains poses a challenge since a mobile will need
to re-establish authentication and authorization as well in the new
domain and each administrative domain may or may not have any prior
security arrangement. In order to be able to provide an optimized
handover solution for a heterogeneous handover case, it is essential
to determine the key functions that contribute to the handover delay.
Determining these key functions help define the right set of
mechanism needed to design an optimized handover framework. In this
document, we introduce the concept of heterogeneous handover,
illustrate the key performance characteristics requirement for a
real-time communication, cite alternate scenarios that represent
a heterogeneous handover involving different access technologies
and different administrative domains. We discuss several
challenges, problems and issues that give rise to handover delay,
packet loss and jitter during the heterogeneous handover. These
issues and problem sets can be used as guidelines while designing
an optimized heterogeneous handover solution.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 3]
Internet-Draft Heterogeneous Handover October 2005
2. Handover Taxonomy
An access network is defined as the backhaul network that provides
the first hop or last hop access to the mobile in an end-to-end
communication system. When a mobile during an active communication
session moves from one access network to another access network and
changes its point of attachment it is subjected to disruption in
continuity of service. During the handover, as the mobile changes
its point-of-attachment in the network a mobile terminal may end up
communicating using its second interface in the new network, change
its subnet or domain it is connected to. Based on the type of
movement and access network we can primarily define the handover in
the following ways. Thus we can define following combination of
handovers in our analysis. Primarily these could be categorized as
A) Inter-subnet and B) Intra-subnet.
An Inter-subnet Handover can comprise the following combination of
handover that fall into category A.
1) Inter-technology, Inter-domain
2) Inter-technology, Intra-domain
3) Intra-technology, Inter-domain
4) Intra-technology, Intra-domain
An intra-subnet handover can consist of the following types of
handover that fall into category B.
1) Intra-Tech, Intra-domain
2) Inter-Tech, Intra-domain
Heterogeneous handover is a handover that requires authorization for
acquisition or modification of resources assigned to a mobile and the
autorization needs interaction with a central authority in a
domain. In many cases an authorization procedure in a
heterogeneous handover follows an authentication procedure that
also requires interaction with a central authority in a domain. All
the scenarios A-1, A-2, A-3, A-4 B1 and B-2 described above could
cover the scope of heterogeneous handover. These will be more clear
as we describe different types of handoff scenarios in the following
sections.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 4]
Internet-Draft Heterogeneous Handover October 2005
+-------------+------------+
| | |
|INTERTECH |INTERTECH |
| INTERDOMAIN |INTRADOMAIN |
| | |
| | |
INTERSUBNET +-------------+------------+
| | |
| INTRATECH |INTRATECH |
| INTERDOMAIN |INTRADOMAIN |
| | |
| | |
+-------------+------------+
| |
| |
INTRASUBNET | INTRATECH & INTRA DOMAIN |
|--------------------------|
| INTERTECH & INTRA DOMAIN |
| |
+--------------------------+
Figure 1: Handover Taxonomy
Intra-subnet: When a mobile moves between two radio access networks
that are part of the same subnet and does not change its layer 3
identifier (i.e. IP address), it is called Intra-subnet handover.
During an intra-subnet handover, the mobile may be subjected to an
inter-technology handover as well if both the access networks with
different radio access technologies (e.g.,CDMA, 802.11) belong to the
same subnet. However during an intra-subnet and inter-technology
handover, the L3 identifier of the terminal may change if the
terminal starts to communicate using an interface that is part of a
different access network.
Inter-subnet: A mobile is subjected to an Inter-subnet handover when
it moves between two different radio access networks that belong to
two different subnets. As a result, its L3 identifier (e.g., IP
address) is changed thus giving rise to a need for any mobility
management protocol such as Mobile IP [RFC3344], Mobile IPv6
[RFC3775], SIP-Mobility [SIPMM], HIP [I-D.ietf-hip-base] that can
take care of the continuity of the existing application. An Inter-
subnet handover can be viewed as a super set of all types of handover
scenarios and may include intra-domain, Inter-domain, Inter-
technology or Intra-technology handover. All of these types of
handovers are described in this document. Inter-subnet handover
potentially gives rise to packet loss and jitter because of delay
Dutta (Ed.), et al. Expires April 20, 2006 [Page 5]
Internet-Draft Heterogeneous Handover October 2005
associated with transition at layer 2 and layer 3.
Inter-technology: A mobile may be equipped with multiple interfaces,
where each interface can support different access technology (802.11,
CDMA). A mobile may like to communicate with one interface at any
time in order to conserve the power. During the handover the mobile
may move out of the footprint of one access technology (e.g., 802.11)
and move into the footprint of a different access technology (e.g.,
CDMA). This will warrant switching of the communicating interface on
the mobile as well. This type of Inter-technology handover is often
called as Vertical Handover since the mobile makes moevement between
two different cell sizes. A vertical handover can be termed as
upward vertical handover or downward vertical handover based on the
direction of movement such as smaller cell to larger cell or vice
versa [vertical]. A mobile moving from 802.11 network to cellullar
network can be viewed as upward vertical handover. An intertechnlogy
handover may affect the quality-of-service of the multimedia
communication, since each access network offers different bandwidth.
Intra-technology: An intra-technology handover is defined when a
mobile moves between the same type of access technology such as
between 802.11[a,b,n] and 802.11 [a,b,n] or between CDMA1XRTT and
CDMA1EVDO. In this scenario a mobile may be equipped with a single
interface (with multiple PHY types of the same technology) or with
multiple interfaces. An Intra-technology handover may involve intra-
subnet or inter-subnet movement and thus may need to change its L3
identifier as it moves.
Inter-domain: A domain can be defined in several ways. But for the
purposes of roaming we define domain as an administrative domain
which consists of networks that are managed by a single
administrative entity which authenticates and authorizes a mobile for
accessing the networks. An administrative entity may be a service
provider, an enterprise and any organization. As a mobile moves
between two administrative domains, it is also subjected to inter-
subnet handover, as two different domains are assumed to be part of
two different subnets. Thus an Inter-domain handover will by-default
be subjected to inter-subnet handover and in addition it may be
subjected to either inter-technology or intra-technology handover.
Inter-domain handover will be sujected to all the transition steps a
subnet handover goes through in addition to an authentication
process. These extra steps contribute to additional delay on the top
of delays due to regular subnet handover.
Intra-domain: When a mobile's movement is confined to movement within
an administrative domain it is called intra-domain movement. An
intra-domain movement may involve intra-subnet, inter-subnet, intra-
technology and inter-technlogy as well.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 6]
Internet-Draft Heterogeneous Handover October 2005
3. Performance Requirements
In order to provide desirable quality of service for interactive VoIP
and streaming traffic, one needs to limit the value of end-to-end
delay, jitter and packet loss to a certain threshold level. ITU-T
and ITU-E standards define the acceptable values for these
parameters. For example for one-way delay, ITU-T G.114 recommends
150 ms as the upper limit for most of the applications, and 400 ms as
generally unacceptable delay. One way delay tolerance for video
conferencing is in the range of 200 to 300 ms. Also if an out-of-
order packet is received after a certain threshold it is considered
lost. References [RFC2679], [RFC2680] and 2681 [RFC2681] describe
some of the measurement techniques for delay and jitter.
An end-to-end delay consists of several components, such as network
delay, operating system (OS) delay, CODEC delay and application
delay. Network delay consists of transmission delay, propagation
delay, queueing delay in the intermediate routers. Operating System
related delay consists of scheduling behavior of the operating system
in the sender and receiver. CODEC delay is generally caused due to
packetization and depacketization at the sender and receiver end.
Application delay is mainly attributed to playout delay that helps
compensate the delay variation within a network. End-to-end delay
and jitter values can be adjusted using proper value of the playout
buffer at the receiver end. In case of interactive VoIP traffic,
end-to-end delay affects the jitter value and is an important issue
to consider. During a mobile's frequent handover, transient traffic
cannot reach the mobile and this contributes to the jitter as well.
If the end system has a playout buffer, then this jitter is subsumed
by the playout buffer delay, but otherwise this adds to the delay for
interactive traffic. Packet loss is typically caused by congestion,
routing instability, link failure, lossy links such as wireless
links. During a mobile's handover a mobile is subjected to packet
loss because of its change in attachment to the network. Thus for
both streaming traffic and VoIP interactive traffic packet loss will
contribute to the service quality of the real-time application.
Number of packets lost is proportional to the delay during handover
and rate of traffic the mobile is receiving. Lost packets contribute
to congestion in case of TCP traffic because of re-transmission, but
it does not add to any congestion in case of streaming traffic that
is RTP/UDP based. Thus it is essential to reduce the packet loss and
effect of handover delay in any mobility management scheme.
We provide some instances of performance requirement here. For
example, according to ETSI TR 101 [ETSI] a normal voice conversation
can tolerate up to 2% packet loss. If a mobile is subjected to
frequent handover during a conversation, each handover will
contribute to packet loss for the period of handover. Thus maximum
Dutta (Ed.), et al. Expires April 20, 2006 [Page 7]
Internet-Draft Heterogeneous Handover October 2005
loss during a conversation needs to be reduced to an acceptable
level. There is no clear threshold value for packet loss for
streaming application, but it needs to be reduced as much as possible
to provide better quality of service to a specific application.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 8]
Internet-Draft Heterogeneous Handover October 2005
4. Handover Delay Analysis
Effects of Heterogeneous handover: We analyze the handover delay
associated with heterogeneous handover and the factors that
contribute to this. As a mobile goes through a heterogeneous
handover process, it is subjected to handover delay because of the
rebinding of properties at several layers of the protocol stack.
There are several common properties that may contribute to the
rebinding of these layers. These properties can mostly be attributed
to things such as access characteristics (e.g., bandwidth, channel
characteristics), access mechanism (e.g. CDMA, CSMA/CA, TDMA),
configuration of layer 3 parameters, re-authentication, re-
authorization, rebinding of security association at all layers.
During any handover procedure any multimedia application running
within a client gets affected because of the delays incurred within
each of the layers of the protocol stack. Next we look at every
layer and analze rebinding of some of these common properties at each
layers as a client is subjected to heterogeneous handover.
Layer 2 delay: Depending upon the access type (e.g., 802.11, CDMA),
the mobile goes through several transition steps, before the new
layer 2 link is re-established. As an example an 802.11 link goes
through the process of scanning, authentication and association
during the reattachment to the new 802.11 access network. Similarly
other access networks such as CDMA and GPRS networks go through a
series of state transitions during their reasociation to the new
point of attachment. Each of these state transitions contributes to
certain delays as the mobile goes through each of these transition.
After a new link is established, depending upon type of handover
scenario, other layers in the protocol need to get rebound. For
example in case of intra-technology, intra-subnet handover, there is
no other layer besides layer 2 that is affected and the handover
delay is attributed to the delay due to layer 2 transitions only.
Even in the case of handoff consisting of intra-domain, intra-
technology, intra-subnet handoff where there is layer 2 delay only,
some sort of authorization procedure needs to be performed when
swithing to the new access network. The procedure may take more
steps if layer-2 characteristics such as QoS characteristics are
different betweeen the old and new access networks than the case
where layer-2 chatersteristics are the same betweeen the old and new
access networks. So the difference of layer-2 characteristics can
qualify a intra-technology handover as a heterogeneous handover as
well. Thus the scenario B-1 may also qualify to be a heterogeneous
handover.
Layer 3 delay: A layer 3 transition process goes through several
steps such as new IP address acquisition, duplicate address
Dutta (Ed.), et al. Expires April 20, 2006 [Page 9]
Internet-Draft Heterogeneous Handover October 2005
detection, ARP update, and local authentication. Where a successful
local authentication allows the mobile to send packets beyond the
first hop router. For example in some cases there is some
authorization process involved even before a new IP address is
obtained. Methods of IP address acquisition are different based on
if it is IPv4, IPv6 and access network is LAN or WAN. There are
several protocols such as DHCP, DHCPv6, PPP or stateless
autoconfiguration that can be used to take care of IP address
acquisition. Each of these methods may take different amount of time
for a layer 3 transition to complete. After a layer 3 transition is
complete and layer 3 address is re-established, there are certain
functions in the upper layer that need to be completed. These
include functions such as sending the binding update from the mobile,
media redirection at the sending host. Delays incurred due to these
functioncs can be attributed to transport delay, processing delay at
the end hosts etc. In the inter-subnet mobility category which is
intra-domain a minimal authorization procedure is needed to obtain
and use the IP address in the new subnet. But the required steps can
be minimized if already established security contexts in the domain
are utilized for the procedure. But inter-subnet, inter-domain
mobility may need additional authorization process.
Application layer delay: In a typical inter-domain mobility scenario
independent of inter-technology or intra-technology handoff, an
authentication and authorization procedure would need to be executed
for establishing layer 2 and layer 3 properties from scratch in the
new domian. This can be an extraordinally undesired delay component
during handoff. References [multinetwork], [hybrid], [interdomain]
are few examples of inter-subnet handover involving inter-domain
mobility that provide some case studies. If the inter-subnet
handover involves inter-domain mobility, then the delay introduced
due to authentication and authorization procedure adds to the
handover latency and consequently affects the ongoing multimedia
sessions. The authentication and authorization procedure may include
EAP authentication where an AAA server may be involved in EAP
messaging during the handover. Depending upon the type of
architecture, in some cases the AAA signals traverse all the way to
the AAA server in the home domain of the mobile as well before the
network service is granted to the mobile in the new network. Thus it
is desirable that interactions between the mobile and AAA servers
must be avoided or be reduced during the handover. By way of
expedited registrations, these interaction can be reduced. But it is
more desirable if these can be avoided altogether during the handover
itself.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 10]
Internet-Draft Heterogeneous Handover October 2005
5. Optimizing Handover Delay
Optimizing the handover delays: Thus it is evident that a mobile is
subjected to different amount of delay based on the types of handover
it is subjected to. For example an intra-subnet, intra-technology
handover will take much less time than inter-subnet and inter-
technology handover, because the mobile goes through a less number
state transitions during the handover process. Thus there are
certain common properties such as characteristics of the access
network, security association at each layers of the protocol stack
during re-attachment, ways of layer 3 binding (e.g., obtaining IP
address, binding update, media redirection), authorization,
authentication in the new network play an important role to determine
the overall handover delay. Thus a heterogeneous handover will be
subjected to higher handover delay compared to complete homogeneous
handover (e.g.,a combination of intra-technology, intra-domain,
intra-subnet).
Thus it is desirable to devise a mechanism or framework that will
help reduce these handover delays either by executing these state
transitions in parallel or completing some of these proactively ahead
of time. A simple example may be to reduce the handover delay by
discovering the new point of attachment, preconfiguring the new L3
identifier, sending the binding update proactively or limiting it
within a certain boundary limit and completing the authentication and
authorization ahead of time prior to the movement into the new
network. There are several optimized mobility management solutions
at different layers, [RFC4068], [RFC4140],[I-D.ohba-mobopts-mpa-
framework], [SIPFAST], currently proposed that attempt to reduce
these handover delay and mitigate the effect of handover delay.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 11]
Internet-Draft Heterogeneous Handover October 2005
6. Security Considerations
This document describes the problem statement and issues associated
with heterogeneous handover. Any framework supporting optimized
heterogeneous handover will need to make sure that the signaling and
data are properly secured during the handover. This security
mechanism can be provided at any layer of the protocol stack.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 12]
Internet-Draft Heterogeneous Handover October 2005
7. IANA Considerations
This document has no actions for IANA.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 13]
Internet-Draft Heterogeneous Handover October 2005
8. Acknowledgments
Authors would like to acknowledge Kenichi Taniuchi, Victor Fajardo
and Subir Das for many helpful discussion.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 14]
Internet-Draft Heterogeneous Handover October 2005
9. References
9.1 Normative References
[ETSI] ETSI, "Telecommunications and Internet Protocols
Harmonization Over Networks (TIPHON) Release 3: end-to-end
Quality of Service in TIPHON systems; Part 1: General aspects
of Quality of Service.", ETSI TR 101 329-6 V2.1.1.
9.2 Information References
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-03 (work in progress), June 2005.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
[I-D.ohba-mobopts-mpa-framework]
Ohba, Y., "A Framework of Media-Independent Pre-
Authentication (MPA)", draft-ohba-mobopts-mpa-framework-01
(work in progress), July 2005.
[SIPMM] Schulzrinne, H. and E. Wedlund, "Application Layer
Mobility USing SIP", ACM MC2R.
[SIPFAST] Dutta, A., Madhani, S., Chen, W., Altintas, O., and H.
Schulzrinned, "Fast handoff Schemes for Application Layer
Mobility Management", PIMRC 2004.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 15]
Internet-Draft Heterogeneous Handover October 2005
[vertical]
Stemm, M. and R. Katz, "Vertical handoffs in wireless
overlay networks", Mobile Network Applications 1998.
[multinetwork]
McNair, J. and F. Zhu, "Vertical Handoffs in Fourth-
Generation Multinetwork Environments", IEEE Wireless
Communications June 2004.
[hybrid] Politis, C., Ann Chew, K., Akhtar, N., Georgiades, M.,
Tafazolli, R., and T. Dagiuklas, "Hybrid Multilayer
Mobility Management with AAA context transfer capabilities
of All-IP Networks", IEEE Wirless Communications August
2004.
[interdomain]
Dutta, Das, Li, Ohba, Baba, and Schulzrinne, "Secured
Mobile Multimedia Communication for Wireless Internet",
IEEE ICNSC 2004 March 2004.
Authors' Addresses
Ashutosh Dutta
Telcordia Technologies
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 3130
Email: adutta@research.telcordia.com
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5305
Email: yohba@tari.toshiba.com
Dutta (Ed.), et al. Expires April 20, 2006 [Page 16]
Internet-Draft Heterogeneous Handover October 2005
Hidetoshi Yokota
KDDI R&D Labs
2-1-15 Ohara Fujimino-Shi
Saitama, Japan 356-8502
Japan
Phone: +81 49 278 7894
Email: yokota@kddilabs.jp
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
Dutta (Ed.), et al. Expires April 20, 2006 [Page 17]
Internet-Draft Heterogeneous Handover October 2005
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 (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dutta (Ed.), et al. Expires April 20, 2006 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 05:59:51 |