One document matched: draft-daniel-mip6-optimized-vertical-handover-00.txt
MIP6 WG S. Daniel Park
Internet Draft Samsung Electronics
Expires: 30 July 2004 Eric Njedjou
France Telecom R&D
Nicolas Montavont
LSIIT
31 January 2004
L2 Triggers Optimized Mobile IPv6 Vertical Handover:
The 802.11/GPRS Example
<draft-daniel-mip6-optimized-vertical-handover-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document describes a mechanism that extends Mobile IPv6
protocol to smoothly manage handovers for Mobile Nodes equipped with
multiple interfaces and moving across different and heterogeneous
links. For this purpose, the document provides indications on how to
use the link events information to optimize L3 movement detection.
Park, Njedjou, Montavont Expires - July 2004 [Page 1]
Internet Draft 802.11 and GPRS Handover January 2004
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................4
3. Terminology....................................................4
4. Standard mobile IPv6 node behavior for movement detection and
handover...........................................................5
4.1 Limitation of the standard mechanism.......................5
5. Layer 2 Triggers / Hints.......................................6
5.1 Introduction and Background................................6
5.2 Differences between L2 Triggers and L2 Hints...............7
5.3 Some Definitions...........................................7
6. Link triggers/hints optimized mobile IPv6 vertical handover....8
6.1 How the l2 information should be utilized to enhance
movement detection and handover.................................8
6.1.1 Use of LINK-UP trigger...................................8
6.1.2 Use of the LINK-TYPE hint................................9
6.1.3 Use of LINK-DOWN trigger.................................9
6.2 Previously defined optimizations to movement detection....10
7. Example of 802.11 / GPRS handover.............................10
7.1 GPRS and 802.11 coexistence...............................10
7.2 GPRS and 802.11 link triggers/hints.......................11
7.2.1 GPRS....................................................11
7.2.2 802.11..................................................12
7.2.3 LINK-TYPE indication....................................13
7.3 Mobile IPv6 node recommended behavior from 802.11 to GPRS.13
7.4 Mobile IPv6 node recommended behavior from GPRS to 802.11.14
8. Security Considerations.......................................15
9. References....................................................15
9.1 Normative References......................................15
9.2 Informative References....................................15
Park, Njedjou, Montavont Expires - July 2004 [Page 2]
Internet Draft 802.11 and GPRS Handover January 2004
1. Introduction
In order to provide sessions continuity for wireless users, Mobile
IPv6 protocol [MIPv6] is currently available. It is capable of
handling IP handovers between different subnets, in a transparent
way for higher-level connections.
Various solutions have been developed within the IETF to provide
signaling and handoff optimizations to [MIPv6], such as Hierarchical
Mobility ([HMIPv6]) and Fast Handoffs ([FMIPv6]). [FMIPv6] allows a
Mobile Node to anticipate its attachment with a prospective default
router (behind a new link), by helping to prepare the new IP
configuration in advance, in a way to enable the Mobile Node to send
and receive packets as soon as it attaches to the new link. [FMIPv6]
assumes that this new IP configuration is to be received through the
currently used network interface.
[FMIPv6] requires adding additional support to IPv6 implementation
in routers, which already deployed IPv6 infrastructure may not be
ready to afford. Still, today, mobile users require ubiquitous
Internet access, which implies being able to support smooth
handovers from one IP subnet to another each serving a radio
coverage of a different technology.
Mobile Nodes are more and more equipped with several interfaces of
different L2 technologies. As such they may be reachable through
multiple links at the same time or alternatively use each interface
depending on the network environment. It is then possible to totally
prepare, and more importantly, build the IP configuration to be used
on a new link, while still using the currently active care-of-
address (built on another link). In this case, there may be no need
to use the RtSolPr/PrRtAdv exchange to learn the IP configuration to
be used on the new link as this can be directly done with the new
Access Router (AR) by using a second L2 interface connected to the
AP serving this new link. Therefore, the new IP configuration of the
target interface can be done without interfering the communication
on the currently used interface if it is still connected to the
network. For these reasons, [FMPv6] may not be useful for vertical
handover, when the new IP configuration can be done before of the
actual vertical handover.
Nevertheless, the handover still needs to be made smoothly. And, In
order to optimally achieve a MIPv6 vertical handoff, the generic,
link-layer independent movement detection mechanism as described in
Park, Njedjou, Montavont Expires - July 2004 [Page 3]
Internet Draft 802.11 and GPRS Handover January 2004
[MIPv6] appears not sufficient. Effectively, it concentrates on
detecting Layer3 movement while timely knowledge of L2 events might
be beneficial to assist in seamless operations.
In this document, we describe a link-layer triggers optimized
movement detection process for Mobile IPv6 protocol. For this
purpose, we briefly describe the standard [MIPv6] movement detection
process and exhibit its limits. We then introduce the link triggers
and hints, before describing the enhanced movement detection
algorithm. We further apply the optimization to the GPRS/802.11
Mobile IPv6 handover case after having identified the link
triggers/hints to be used for both technologies.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
3. Terminology
Access Point (AP)
An Access Point is a layer 2 device that is connected to the wired
Network and offers the wireless link connection to the MN.
Access Router (AR)
A router residing on the edge of an Access Network and connected to
one or more APs. An AR offers IP connectivity to Mobile Nodes.
GGSN
Gateway GPRS Support Node. A router between the GPRS network and an
external network (i.e, the Internet). The GGSN is an example of an
Access Network Gateway.
GPRS
General Packet Radio Service. Packet-switched data
transmission service on top of the GSM network.
Layer 2 Handoff (L2 Handoff)
A process of terminating existing link layer connectivity and
obtaining new one. This handoff alone is transparent to the routing
at the IP layer.
Park, Njedjou, Montavont Expires - July 2004 [Page 4]
Internet Draft 802.11 and GPRS Handover January 2004
Layer 3 Handoff (L3 Handoff)
A process of terminating existing network layer connectivity and
obtaining new one.
Mobile Node (MN)
A host or router that changes its point of attachment from one
network or subnet to another
4. Standard mobile IPv6 node behavior for movement detection and
handover
Section 11.5 of [MIPv6] describes a generic movement detection
process, that uses the absence of due Router Advertisements (RAs)
and Neighbor Unreachability Detection (NUD) to detect when the
default router is no longer reachable. This triggers Router
Discovery, initiated by the sending of RAs, to learn about the
presence of a candidate new default router. After discovering new
routers, the mobile node performs DAD for link-local address,
selects a new router, performs prefix discovery for that router to
form a new care-of address and, as a consequence, performs the
binding update and route optimization.
4.1 Limitation of the standard mechanism
The only use of L3 information in [MIPv6] movement detection
algorithm has the following consequences;
1. A Mobile Node is not able to detect that its default router is no
longer reachable unless
- The RA Advertisement interval expires without the MN receiving
any other advertisement.
- It has packets to send
2. Moreover, a Mobile Node is not able to detect that it has lost
attachment to its default router even with such hints as the
reception of a new RA with a new prefix. Effectively, the reception
of a new RA advertising a new prefix does not determine a lost of L3
connectivity as there might be multiple routers sharing the link.
Park, Njedjou, Montavont Expires - July 2004 [Page 5]
Internet Draft 802.11 and GPRS Handover January 2004
3. A Mobile Node has to wait until it receives a RA to acquire
knowledge of the presence of a new router. Still, for the purpose of
achieving smooth handovers from one IP subnet to another, it might
be unaffordable for some time-constrained applications to realize
that reachability with the default router has been lost, long after
it really had. It may be unaffordable as well for such applications
to wait for received RAs before discovering new routers and form a
new care-of address.
To quickly detect any L3 movement (i.e loss of attachment with
default router and discovery of new router), link-layer indication
might be precious. However current Mobile IPv6 protocol [MIPv6] does
not indicate how to make use of these L2 indications , well kown as
triggers, but consider it as an item for further studies. The two
next sections are an attempt to address this well known deficiency
to [MIPv6].
5. Layer 2 Triggers / Hints
5.1 Introduction and Background
L2 triggers were introduced in the IETF terminology a long time ago.
In [manyfloks], the concept of L2 triggers was defined to optimize
IP handovers between access points belonging to different subnets.
In this context, five L2 triggers were proposed: two messages in
reaction to a L2 handover/connection establishment (Link up and Link
Down) and three messages that are issued before a L2 handover occurs
(Source Trigger, Target Trigger or Mobile Trigger). These pre-
handover messages were designed to help L3 operations because they
allowed the anticipation of potential movements. The Fast Handoffs
specification, [FMIPv6], which proposes extension to Standard Mobile
IP to support smooth handover, describes a message exchange between
the MN and its old and new ARs to enhance movement operation. The
mechanism is based on an anticipation of movement where the MN is
supposed to discover close APs. The way the MN discovers its
neighboring APs is not defined in the document. Moreover, the
documents says that L2 triggering can be used for anticipation and
start of the Fast Handover mechanism, but as of today no general L2
trigger specification exists.
[802.11fh] details how to perform a MIPv6 fast handover over IEEE
802.11 networks. The feasability of the anticipation in IEEE 802.11
Park, Njedjou, Montavont Expires - July 2004 [Page 6]
Internet Draft 802.11 and GPRS Handover January 2004
networks is studied and a specific L2 trigger to IEEE 802.11 is
proposed.
It is also to be noted that the use of L2 information by the IP
layer was discussed in MANET Working Group for ad-hoc devices. L2
triggering and L2 parameters were identified as being capable of
enhancing the routing protocol in an ad-hoc environment; If a node
has different choices to compute its next hop, the intensity of
signal between itself and its neighbors could be considered in the
choice of the next hop.
More recently, a new Working Group has been setting up, called
Detecting Network Attachment (DNA), which aims is to determine the
operations needed to faster discover the IPv6 subnet a MN is to
connect to. In this context, the information to be extracted from L2
for use by L3 has been discussed in [L2Hint] and [Parameters]. The
goal of this work in progress is to provide a catalog of L2 triggers
and L2 hints available at the link layer. We can expect that this
catalog will lead to a generic abstraction of the L2 technologies
that can be used by the IP layer for different purposes: IP
attachment detection, handover optimization, anticipation of
movement, etc. Such an abstraction will consist in events and states
of the L2, as well as L2 parameters. An abstraction aims at defining
optimized L3 operations over any L2 technologies, independently from
these technologies.
5.2 Differences between L2 Triggers and L2 Hints
In the specification of L2-L3 interaction, a distinction is made
between L2 Triggers and L2 Hints; a L2 Trigger is an event that
occured at the Link Layer that is forwarded to the upper layer
(Layer 3). This event can help the Layer 3 to instantaneously react
by initiating an L3 operation (such as to trigger a L3 handover).
A L2 Hint is an information that can be optionally transported with
a L2 trigger and that can help the Layer 3 enhance triggered
operations. Therefore, it is a supplementary information transported
with the L2 Trigger that even help to make L3 link discovery faster.
5.3 Some Definitions
Park, Njedjou, Montavont Expires - July 2004 [Page 7]
Internet Draft 802.11 and GPRS Handover January 2004
LINK-UP trigger: This event corresponds to the establishment of a
new L2 link, which allows IP communication over it. This is
typically a new full connection between the MN and an AP.
LINK-DOWN trigger: This event corresponds to a L2 Link that has been
broken down. This typically happens when a current connection
between the MN and an AP has been terminated. The interface which
generates this trigger can not be used for communication until a
connection with an AP is made (LINK UP).
LINK-TYPE hint: The type of the technology from which the trigger
was generated, e.g., GPRS or WLAN.
6. Link triggers/hints optimized mobile IPv6 vertical handover
6.1 How the l2 information should be utilized to enhance movement
detection and handover
In this section, we try to show how information extracted from lower
layer protocols, namely triggers and hints, can provide better
performance for the movement detection algorithm. The gain in
performance is not measured here but could be the subject of other
documents.
6.1.1 Use of LINK-UP trigger
When a LINK-UP indication is received from L2, the Mobile Node
immediately sends a Router Solicitation message (rather than waiting
for any Router Advertisement message to be received). On some types
of links, routers could be configured in a way to avoid sending
unsolicited Router Solicitation messages or to sending them at a
frequency not adapted to mobility demands. Waiting for RAs in such
cases could be really prejudicial for the performance of Mobile IPv6.
It is to be noted that the random time advised by RFC 2461 between 0
and MAX_ROUTER_SOLICITATION_DELAY before sending any RS can be
avoided for optimization purposes, as it is accepted that Mobile
Nodes constraints render it essential the need to have the shortest
possible router discovery time.
The LINK UP indication should be accompanied by a LINK-TYPE
indication. The use of the LINK-TYPE parameter is explained later in
this section.
Park, Njedjou, Montavont Expires - July 2004 [Page 8]
Internet Draft 802.11 and GPRS Handover January 2004
The Mobile Node then processes the RA received as response to the RS,
builds a table where it associates the RA information on the new
link with the LINK-TYPE parameter, then performs DAD, Prefix
Discovery, IP address auto-configuration, care-of-address
construction as usual.
6.1.2 Use of the LINK-TYPE hint
A Mobile Node should send at least one RS each time it discovers a
new link. In doing so, when at least two RAs have been received on
different links, and care-of-addresses have been correspondingly
built, the Mobile Node can use the LINK-TYPE indication associated
to each RA (thus to each Care-of-address) in the selection of the
primary care-of address as described in [MIPv6]. In such a way, the
Mobile Node would be able to choose to have its primary care-of-
address on one link offering as an example, better characteristics
with respect to bandwidth and latency, than any other link available.
This is why it makes sense to immediately proceed to sending a
Router Solicitation when a LINK-UP indication is received, as the
link features deducted from the LINK-TYPE hint can lead to the
preference of the newly discovered link for the choice of the
primary care-of-address. It is to be reminded that the intent here
is not to specify how the care-of-address should be selected but
rather to indicate elements that can help this selection.
6.1.3 Use of LINK-DOWN trigger
When a LINK-DOWN indication is received from L2 the Mobile Node
should immediately invalidate the care-of-address associated with
the link in question, this in accordance with [MIPv6], re-select a
new primary care-of-address if available, or wait for the next LINK-
UP indication to proceed to active Router Discovery again.
This avoid loosing the time corresponding to the delay experienced
in waiting for the Mobile Node to realize that it is no more
receiving any RA added to the delay for performing any IP
connectivity check as NUD.
If the Mobile Node was already engaged in a NUD check, upon
reception of a LINK-DOWN indication for the link associated with the
router the check has been initiated for, the check can be
Park, Njedjou, Montavont Expires - July 2004 [Page 9]
Internet Draft 802.11 and GPRS Handover January 2004
immediately aborted as the result of NUD can be anticipated by the
information that the link is lost.
6.2 Previously defined optimizations to movement detection
A couple of Mobile IPv6 movement detection optimisations schemes
have been suggested within the IETF: [FastRA] and [LinkID] seek to
reduce the time taken to perform Router Discovery but from a layer 3
perspective. As for [FRD], it makes use of Layer 2 information to
accelerate the process of Router Discovery but requires
modifications to L2 technologies and especially Access Points.
7. Example of 802.11 / GPRS handover
7.1 GPRS and 802.11 coexistence
The increasing popularity of IEEE 802.11-based WLANs, which are
deployed in such areas as Hot Spots, combined to the recent advent
of 2.5G wide-area wireless networks such as GPRS, has created the
need to judiciously make use of these two wireless IP access
technologies by taking advantage of their complementarity for moving
users.
While it is indicated to let the l2 handle the horizontal handover
where there is no need of configuration change at IP layer as it is
the case in most 802.11b and GPRS deployment scenarios, such
vertical handoffs as GPRS to WLAN or vice-versa would quite often
require a change of subnet. And from most views, Mobile IP looks an
appropriate candidate to help perform this specific inter-technology
handoff.
Based on the link triggers and hints we've specified in the
precedent section for each of the aforementioned technologies, we
hereafter apply the optimized Mobile IPv6 movement detection process
presented in section 3 to the GPRS/WLAN handoff case.
Park, Njedjou, Montavont Expires - July 2004 [Page 10]
Internet Draft 802.11 and GPRS Handover January 2004
-------
/ \
| Internet +-------------------------------------+
\ / |
---+--- \ |
| \ |
| +------------+ |
| | |
+--+--+ +---+--+ +--+--+
| AR1 | | GGSN | | AR2 |
+--+--+ +---+--+ +--+--+
| | |
| \ GPRS |
| \ |
| \ |
+-+--+ +----+ +-+--+ +--+-+
| AP |.......| AP | |SGSN| | AP |
+----+ +----+ * +----+ * +----+
. . * . * .
. . * . * .
. . * . * .
+----+ * +----+ * +----+
| MN |============> * ===> | MN | ====> | MN |
+----+ movement * +----+ * +----+
* *
802.11 coverage * * 802.11 coverage
* *
* * * * * * * * * * * * * * *
Fig. Movement scenario of a MN between GPRS and 802.11 coverage
7.2 GPRS and 802.11 link triggers/hints
We identify the link triggers/hints to be used for each technology.
7.2.1 GPRS
LINK-UP indication
A MN that wants to establish IP level connections through its GPRS
interface should first request the GPRS network to settle the
necessary soft state mechanism (GPRS tunneling Protocol) between the
Park, Njedjou, Montavont Expires - July 2004 [Page 11]
Internet Draft 802.11 and GPRS Handover January 2004
GPRS AP (SGSN) it is attached to and the AR (GGSN) corresponding to
the type of network it is requesting connection for (Intranet,
Internet). This routing mechanism between the SGSN and the GGSN
enable the forwarding of IP packets between the MN and external data
networks as the Internet or an Intranet (via the GGSN). The process
by which this is made possible is designated as a PDP Context
activation. It corresponds to the IP configuration process.
A PDP Context is considered activated on the MT side as soon as an
"Activate PDP Context Accept" message has been received from the
SGSN. As such, the reception of this message can be considered as a
LINK-UP indication for the MN GPRS/UMTS interface.
LINK-DOWN indication
The GPRS network can initiate a PDP context deactivation at any time.
A "Deactivate PDP Context Request" message is then sent by the SGSN
(GPRS AP). The reception of this message is an indication that the
IP configuration of the MN's GPRS interface is about to be deleted
by the network.
As such, the reception of the message can be considered as a LINK-
DOWN trigger for the GPRS/UMTS interface
7.2.2 802.11
LINK-UP indication
In order to have an IP level connection through an IEEE 802.11
network, a MN must be associated with an Access Point. The last
messages exchanged between the MN and a target Access Point to
establish a connection is a (Re)Association Response sent from the
Access Point to the MN. This message indicates to the MN the status
of the association (accepted or rejected). If the association is
accepted, then the MN can usually start to send and receive IP
packets through the Access Point.
But, if the MN is connecting to an Access Point which uses enhanced
security mechanisms as defined in [IEEE 802.11i] (MN enters a Robust
Security Network), the reception of the (Re)Association Response is
not the relevant trigger that informs that IP packets can be
exchanged. In a Robust Security Network, an IEEE 802.1x port is used
on each station (Access Point and MN) to filter packets: while a
Park, Njedjou, Montavont Expires - July 2004 [Page 12]
Internet Draft 802.11 and GPRS Handover January 2004
mutual authentication of both the Access Point and the MN is not
done, all data packets are discarded. Instead, EAP packets are used
to transport authentication. Upon the reception of an "EAP-accept"
message with a successful status, the data packets are authorized to
use the association between the access point and the MN.
To summarize this section, in a non-secure 802.11 network, a
successful (re)association response can be taken as a Link-Up
trigger while in 802.1x, it is the EAP-accept message which is taken
as a Link-Up trigger.
LINK-DOWN indication
To allow IP packets exchange with a MN using an IEEE 802.11
interface, the MN has to be authenticated and associated with an AP.
As soon as the MN is no more authenticated or associated to an AP,
IP connectivity is broken. Upon the reception of "Disassociation"
message, the MN is considered disconnected and then has no more IP
connectivity through the AP. Therefore, the "Disassociation" message
is to be considered as a Link-Down trigger.
It has to be noted that a Disassociation message is not required to
be sent each time a MN disassociates from an AP. In IEEE 802.11, if
a MN measures a poor signal with its current AP, it can
disassociates by itself and no messages are sent.
7.2.3 LINK-TYPE indication
The LINK-TYPE indication would generally not be directly provided by
the L2. Each implementation of the L2 messages extraction will have
to figure out how it is able to fetch the information.
7.3 Mobile IPv6 node recommended behavior from 802.11 to GPRS
Here the Mobile Node steps outside of the 802.11b Access Point radio
range it is attached to. It is assumed that no other in-range
802.11b AP is present to offer connectivity.
At some time in the movement, a "disassociation" beacon will be
received by the host, triggering the MN to immediately invalidate
the care-of-address associated with the 802.11b interface, and
select the care-of-address associated to GPRS as its primary then
Park, Njedjou, Montavont Expires - July 2004 [Page 13]
Internet Draft 802.11 and GPRS Handover January 2004
register it to its Home Agent. This assumes that the GPRS interface
was still up.
Note that power consumption considerations on Mobile Terminals as
laptops and PDAs can dictate the need for deactivation of all
interfaces but the one associated to the primary care-of-address. In
such a case, smooth handoff operation require exploiting any hint
from 802.11b layer that the MN will soon be de-associated. Reception
of such a hint then anticipates the build-up of the PDP context that
will be necessary to establish the GPRS care-of-address (A "Activate
PDP context Request" message is sent to the SGSN): once the
"Activate PDP context Accept" message is received from the network,
the MN sends a RS to the IPv6 GGSN to receive router prefix
information and form new care-of-address. DAD can be avoided here as
the shared link concept utilized in such networks as 802.11b is not
valid in 3GPP networks where every MN holds a "private" link-layer
connectivity with the AP (i.e unknown to other MNs that are GPRS-
connected to the same AP). The GPRS IPv6 address is then selected as
primary and registered to the HA. It may happen that the 802.11b
link get down before all the previous process is performed. Still,
it is better to anticipate the loss of 802.11 link connection as
this results in reduced packets loss.
7.4 Mobile IPv6 node recommended behavior from GPRS to 802.11
This step represents the Mobile Node arriving inside a 802.11
network. Start of this step is indicated on the Mobile Node by the
reception of an "association" or "EAP-accept" message, coming from
the nearest in-range Access Point. This triggers the sending by the
MN of a Router Solicitation message to check router presence on the
newly discovered 802.11 link and receive prefix information in order
to build care-of-address after performing Duplicate Address
Detection. Next, the registration process with the Home Agent is
completed.
For smooth handoff operation, [MIPv6] does not preclude the use of a
still valid previous primary care-of-address for the reception of
packets after registering a new primary care-of-address to the HA.
Therefore, the Mobile Node can keep its GPRS interface and
associated care-of-address active for an additional period of time
that will have to be tuned according to such criteria as the GPRS
link latency. Effectively, the latency encountered on such links can
cause the packets sent before the new care-of-address was registered
to arrive with delay.
Park, Njedjou, Montavont Expires - July 2004 [Page 14]
Internet Draft 802.11 and GPRS Handover January 2004
8. Security Considerations
Implementations of the L2 triggers extraction should guarantee that
the information received at the IP layer is originated from the MN
L2 stack rather than sent by a malicious node.
9. References
9.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[MIPv6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in
IPv6. Internet Draft (work in progress), July 2003.
[WLAN] "Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", ANSI/IEEE Std 802.11, 1999
Edition.
[GPRS] 3GPP TS 03.60 (release 1998) "Digital cellular
telecommunications system (Phase 2+); General Packet
Radio Service (GPRS) Service description; Stage 2",
version 7.9.0
[REQ] M. Wasserman, Ed. "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", RFC
3314, September 2002
[802.11i] IEEE Sd 802.11i/D7.0, Medium Access Control (MAC)
Security Enhancements, October 2003.
[802.11fh] Peter J. McCann, Mobile IPv6 Fast Handover for 802.11
networks, draft-mccan-mobile-802.11fh-01.txt, expired in
May 2003.
9.2 Informative References
[MoveDetect]G. Delay, J. Choi, "Movement Detection Optimization in
Mobile IPv6", Internet Draft, May 2003.
Park, Njedjou, Montavont Expires - July 2004 [Page 15]
Internet Draft 802.11 and GPRS Handover January 2004
[FASTRA] M. Khalil, J. Kempf, B. Pentland. "IPv6 Fast Router
Advertisement (FastRA) ", Internet Draft (work in
progress), October 2002.
[LINKID] B. Pentland, G Daley, J Choi. "Router Advertisement Link
Identification for Mobile IPv6 Movement Detection",
Internet Draft (work in progress), May 2003
[FRD] J. Choi, D. Shin. "Fast Router Discovery with RA
Caching in AP", Internet Draft (work in progress), Feb
2003.
[manyfolks] A. Yegin, D. Funato, K. El Malki, Y. Gwon, J. Kempf,
M. Pettersson, P.Roberts, H. Soliman, A. Takeshita,
"Supporting Optimized Handover for IP Mobility -
Requirements for Underlying Systems", draft-manyfolks-
l2-mobilereq-02.txt, expired December 2002.
[fmipv6] R. Koodli et al, "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-00.txt, October 2003.
[Link Hints]Alper Yegin, E. Njedjou, S. Veerepalli, N. Montavont,
T. Noel, "Link-layer Hints for Detecting Network
Attachments", draft-yegin-dna-l2-hints-00.txt, November
2003.
[Parameter] P. Bertin, T. Noel, N. Montavont, "Parameters for Link
Hints", draft-bertin-hints-params-00.txt, September 2003.
Acknowledgements
Leave your name
Park, Njedjou, Montavont Expires - July 2004 [Page 16]
Internet Draft 802.11 and GPRS Handover January 2004
Authors' Addresses
Soohong Daniel Park
Samsung Electronics
416, Maetan-3dong, Youngtong-gu, Suwon
Korea
Phone: +82 31 200 4508
Email: soohong.park@samsung.com
Eric Njedjou
France Telecom R&D
4, Rue du Clos Courtel BP 91226
35512 Cesson-S‰vign‰
Fr&nce
Phone: +33 299124202
Email: eric.njedjou@francetelecom.com
URL: http://perso.rd.francetelecom.fr
Nicolas Montavont
LSIIT Universit‰ Louis Pasteur
Pole API, bureau C430
Boulevard Sebastien Brant
Illkirch 67400
FranceT
Phone: (33) 390244587
Email:montavont@dpt-info.u-strasbg.fr
URL: www-r2.u-strasbg.fr/~montavont
Park, Njedjou, Montavont Expires - July 2004 [Page 17]
Internet Draft 802.11 and GPRS Handover January 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Park, Njedjou, Montavont Expires - July 2004 [Page 18]
Internet Draft 802.11 and GPRS Handover January 2004
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Park, Njedjou, Montavont Expires - July 2004 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-21 18:15:12 |