One document matched: draft-ohba-mobopts-heterogeneous-requirement-01.txt
Differences from draft-ohba-mobopts-heterogeneous-requirement-00.txt
MOBOPTS Research Group A. Dutta (Ed.)
Internet-Draft Telcordia
Expires: August 30, 2006 Y. Ohba
TARI
H. Yokota
KDDI R&D Labs
H. Schulzrinne
Columbia Univ.
February 26, 2006
Problem Statement for Heterogeneous Handover
draft-ohba-mobopts-heterogeneous-requirement-01
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 August 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 August 30, 2006 [Page 1]
Internet-Draft Heterogeneous Handover February 2006
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 . . . . . . . . . . . . . . . . . . . 8
4. Handover Delay Analysis . . . . . . . . . . . . . . . . . . . 10
4.1. Layer 2 delay . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Layer 3 Delay . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Application Layer Delay . . . . . . . . . . . . . . . . . 12
5. Optimizing Handover Delay . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Information References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Dutta (Ed.), et al. Expires August 30, 2006 [Page 2]
Internet-Draft Heterogeneous Handover February 2006
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 technologies 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
mechanisms 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 August 30, 2006 [Page 3]
Internet-Draft Heterogeneous Handover February 2006
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 the
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. 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, B-1 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 August 30, 2006 [Page 4]
Internet-Draft Heterogeneous Handover February 2006
+-------------+-------------+------------+
| | | |
| |INTERTECH |INTERTECH |
| | INTERDOMAIN |INTRADOMAIN |
| | | |
| | A-1 | A-2 |
| INTERSUBNET +-------------+------------+
| | | |
| | INTRATECH |INTRATECH |
| | INTERDOMAIN |INTRADOMAIN |
| | | |
| | A-3 | A-4 |
+-------------+--------------------------+
| | INTRATECH & INTRA DOMAIN |
| | B-1 |
| INTRASUBNET +--------------------------+
| | |
| | INTERTECH & INTRADOMAIN |
| | B-2 |
+-------------+--------------------------+
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 broadcast
domain, 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 effective
L3 identifier of the terminal may change if the terminal starts to
communicate using an interface that is part of a different access
network, since the IP address associated with each interface will be
different although these addresses belong to the same subnet.
Inter-subnet: A mobile is subjected to an Inter-subnet handover when
it moves between two 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 orthogonal to intra-subnet handoff 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
Dutta (Ed.), et al. Expires August 30, 2006 [Page 5]
Internet-Draft Heterogeneous Handover February 2006
packet loss and jitter because of delay 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 movement 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 inter-
technology 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 depending upon type of movement. An intra-technology
handover may involve networks with different access characteristics
and thus may very well belong to heterogeneous handover category.
However a handover between 802.11b networks if these belong to same
subnet or domain may not be termed as heterogeneous handover.
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 exclusively have 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
Dutta (Ed.), et al. Expires August 30, 2006 [Page 6]
Internet-Draft Heterogeneous Handover February 2006
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 August 30, 2006 [Page 7]
Internet-Draft Heterogeneous Handover February 2006
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-R 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.
Different CODECs will give rise to different delay, for example G.729
encodes speech at 8 Kbps and adds one-way delay of about 25 ms.
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 may contribute to jitter even if the
packet loss is avoided by means of buffering or some other forwarding
mechanism. 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. The
performance requirement will vary based on the type of application
Dutta (Ed.), et al. Expires August 30, 2006 [Page 8]
Internet-Draft Heterogeneous Handover February 2006
and its characteristics such as delay tolerance and loss tolerance
limit. Interactive traffic such as VoIP and streaming traffic will
have different tolerance for delay and packet loss. 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 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. Similarly there are other
factors such as Transmission Rating Factor (R), End to End delay (one
way mouth-to-ear) and Call blocking ratio that are some of the
parameters that determine the QoS metrics. R factor is standardized
by ITU-T G.107. R value is based on E Model. An R value of 50 is
considered to be poor and a value of 90 can be considered as the best
that provides most user satisfaction. As an example, a class B QoS
which is equivalent to cellular telephony has a R factor that is
greater than 70, E2E delay of less than 150 ms and call blocking
ratio which is less than or equal to 0.15. Class A QoS that is the
highest and is equivalent to fixed phone quality has an R value that
is more than 80, E2E delay that is less than 100 ms. Similarly, 3GPP
TS23.107 defines 4 classes: conversational, streaming, interactive
and background. The streaming class has the packet (SDU) error rates
ranging from 0.1 to 0.00001 and the transfer delay of less than
300ms. On the other hand, in ITU-T Y.1541, streaming is categorized
as Class 4 out of existing 6 classes, where the upper bound of the
transfer delay is 1 sec and the upper bound of packet loss ratio is
0.001, thus its delay tolerance is more than that of 3GPP's. The
delay variation is not specified in this class. On the other hand
different vendor products suggest values up to 3 to 4 sec as
tolerance value for the streaming traffic.
Dutta (Ed.), et al. Expires August 30, 2006 [Page 9]
Internet-Draft Heterogeneous Handover February 2006
4. Handover Delay Analysis
This section analyzes 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 re-establishment or modification 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. In the next subsections we
provide analysis of several sub-components that give rise to the
delay within each layer.
4.1. 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 point. Similarly other access networks such
as CDMA and GPRS networks go through a series of state transitions
during their reassociation to the new point of attachment. Each of
these state transitions contributes to certain delays as the mobile
goes through each of these intra-layer transitions. After a new
layer 2 link is established, depending upon the type of handover
scenario, other layers in the protocol need to go through the
rebinding process. 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,
an authentication and authorization procedure needs to be performed
when switching 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 access characteristics
can qualify a intra-technology handover as a heterogeneous handover
as well. Hence the scenario B-1 may also qualify to be a
Dutta (Ed.), et al. Expires August 30, 2006 [Page 10]
Internet-Draft Heterogeneous Handover February 2006
heterogeneous handover as it may involve movement between 802.11b and
802.11n network or between CDMA1XRTT or CDMA1XEVDO networks. In case
of movement between 802.11 type networks EAP authentication and 4-way
handshake involving 802.11i can also add delay. Similarly in case of
handoff between CDMA2000 family networks authentication procedure
such as CHAP for PPP session may add to the layer 2 delay.
4.2. Layer 3 Delay
A layer 3 transition process goes through several steps such as new
IP address acquisition, duplicate address detection, ARP update, and
local authentication. Similarly a successful local authentication
allows the mobile to send packets beyond the first hop router and may
add delay to the handover process. 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
functions can be attributed to transport delay, processing delay at
the end hosts etc. In the inter-subnet, intra-domain mobility
category an authentication procedure is needed to obtain and use the
IP address in the new subnet. But inter-subnet, inter-domain
mobility may need additional authorization process. For example
during an interdomain movement that includes MIPv4 as the binding
protocol, AAA interaction will contribute to additional delay.
In a typical inter-domain mobility scenario independent of inter-
technology or intra-technology handoff, an authentication and
authorization procedure need to be executed for establishing layer 2
and layer 3 properties from scratch in the new domain. 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
Dutta (Ed.), et al. Expires August 30, 2006 [Page 11]
Internet-Draft Heterogeneous Handover February 2006
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.
4.3. Application Layer Delay
Application layer delay is the delay needed to re-establish or modify
application layer properties involving end-to-end applications such
as SIP specific sessions . Application layer binding update or any
other mid-session signaling thus can be regarded as application layer
delay. By way of application layer signaling any mid-session info
such as IP address, codec parameters can also be changed.
Dutta (Ed.), et al. Expires August 30, 2006 [Page 12]
Internet-Draft Heterogeneous Handover February 2006
5. Optimizing Handover Delay
It is evident from the analysis provided in the previous section 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 of 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. But the required steps can be minimized
if already established security contexts in the domain are utilized
for the procedure. Thus without any optimization technique, any type
of heterogeneous handover will be subjected to higher handover delay
compared to complete homogeneous handover (e.g.,a combination of
intra-technology (802.11b - 802.11b), intra-domain, intra-subnet).
Thus it is desirable to devise a mechanism or framework that helps
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
completing the authentication and authorization ahead of time prior
to the movement into the new network. Additional level of
optimizations for other layer 2 and layer 3 related operation may
also be possible. In some cases lower layer hints may help to
optimize upper layer delays as well. 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.
In case of intra-domain movement, it might be possible to give
authorization to the mobile on the use of every access network within
the domain at the time of mobile's initial entry to the domain so
that no additional authorization is required for each heterogeneous
movement as well as homogeneous movement. This approach still needs
authentication for each access network in the domain during mobile's
movement to make sure that the entity attaching to the access network
is the authorized mobile. Pre-authentication will help minimize such
post-movement authentication delay for such an approach as well. For
example during a movement to a CDMA1xEVDO network, a PPP connection
cannot be set up until user authentication is complete using
procedures such as CHAP or PAP with all the way to a AAA server in
the home or a visited domain. In order to make the handover to a new
PPP network faster pre-authentication using CHAP and PAP can take
Dutta (Ed.), et al. Expires August 30, 2006 [Page 13]
Internet-Draft Heterogeneous Handover February 2006
place ahead of time allowing part of this phase to be set up ahead of
time.
Dutta (Ed.), et al. Expires August 30, 2006 [Page 14]
Internet-Draft Heterogeneous Handover February 2006
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 August 30, 2006 [Page 15]
Internet-Draft Heterogeneous Handover February 2006
7. IANA Considerations
This document has no actions for IANA.
Dutta (Ed.), et al. Expires August 30, 2006 [Page 16]
Internet-Draft Heterogeneous Handover February 2006
8. Acknowledgments
Authors would like to acknowledge Kenichi Taniuchi, Victor Fajardo
and Subir Das for many helpful discussion.
Dutta (Ed.), et al. Expires August 30, 2006 [Page 17]
Internet-Draft Heterogeneous Handover February 2006
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-04 (work in progress), October 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 August 30, 2006 [Page 18]
Internet-Draft Heterogeneous Handover February 2006
[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.
Dutta (Ed.), et al. Expires August 30, 2006 [Page 19]
Internet-Draft Heterogeneous Handover February 2006
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
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 August 30, 2006 [Page 20]
Internet-Draft Heterogeneous Handover February 2006
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 (2006). 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 August 30, 2006 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 05:19:22 |