IRTF MobOpts RG F. Teraoka
Internet-Draft K. Gogo
Intended status: Informational K. Mitsuya
Expires: March 25, 2007 R. Shibui
K. Mitani
KEIO University
September 21, 2006
Unified L2 Abstractions for L3-Driven Fast Handover
draft-irtf-mobopts-l2-abstractions-01.txt
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 March 25, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Teraoka, et al. Expires March 25, 2007 [Page 1]
Internet-Draft L2 Abstractions September 2006
Abstract
This draft proposes unified L2 abstractions for L3-driven fast
handovers. For efficient network communication, it is vital for a
protocol layer to know or utilize other layer's information such as a
form of L2 triggers. However, each protocol layer is basically
designed independently. Since each protocol layer is also
implemented independently in current operating systems, it is very
hard to exchange control information between protocol layers. To
solve the problem, this draft defines nine kinds of L2 abstractions
in the form of "primitive" to achieve fast handovers in the network
layer. This mechanism is called "L3-driven fast handovers" because
the network layer initiates L2 and L3 handovers by using the
"primitives".
Teraoka, et al. Expires March 25, 2007 [Page 2]
Internet-Draft L2 Abstractions September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Primitives for L2 Abstractions . . . . . . . . . . . . . . . . 7
4. Definitions of Primitives . . . . . . . . . . . . . . . . . . 9
4.1. L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . . 9
4.2. L2-PeerList (Type 1) . . . . . . . . . . . . . . . . . . . 9
4.3. L2-PeerFound (Type 2) . . . . . . . . . . . . . . . . . . 9
4.4. L2-PeerLost (Type 2) . . . . . . . . . . . . . . . . . . . 9
4.5. L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . . 10
4.6. L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . . 10
4.7. L2-LinkGoingDown (Type 2) . . . . . . . . . . . . . . . . 10
4.8. L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 10
4.9. L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . . 10
5. Definitions of Static Parameters . . . . . . . . . . . . . . . 11
5.1. Network Interface ID . . . . . . . . . . . . . . . . . . . 11
6. Definitions of Dynamic Parameters . . . . . . . . . . . . . . 12
6.1. Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Condition . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Peer List . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Enable/Disable . . . . . . . . . . . . . . . . . . . . . . 12
6.5. Ack/Error . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Architectural Considerations . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Example Scenario . . . . . . . . . . . . . . . . . . 19
Appendix B. Example Operation for FMIPv6 . . . . . . . . . . . . 21
B.1. Example Operation-1 for FMIPv6 . . . . . . . . . . . . . . 21
B.2. Example Operation-2 for FMIPv6 . . . . . . . . . . . . . . 23
B.3. Experiment . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix C. Example Mapping of Primitives and IEEE802.11 . . . . 27
C.1. L2-LinkStatus . . . . . . . . . . . . . . . . . . . . . . 27
C.2. L2-PeerList . . . . . . . . . . . . . . . . . . . . . . . 27
C.3. L2-PeerFound . . . . . . . . . . . . . . . . . . . . . . . 27
C.4. L2-PeerLost . . . . . . . . . . . . . . . . . . . . . . . 28
C.5. L2-LinkUp . . . . . . . . . . . . . . . . . . . . . . . . 28
Teraoka, et al. Expires March 25, 2007 [Page 3]
Internet-Draft L2 Abstractions September 2006
C.6. L2-LinkDown . . . . . . . . . . . . . . . . . . . . . . . 28
C.7. L2-LinkGoingDown . . . . . . . . . . . . . . . . . . . . . 28
C.8. L2-LinkConnect . . . . . . . . . . . . . . . . . . . . . . 28
C.9. L2-LinkDisconnect . . . . . . . . . . . . . . . . . . . . 29
Appendix D. Implementation and Evaluation of the Proposed
Model . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix E. Changes from 01 . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 35
Teraoka, et al. Expires March 25, 2007 [Page 4]
Internet-Draft L2 Abstractions September 2006
1. Introduction
In recent years, the execution environment around computers is not
static and changes dynamically. Especially, when a mobile node moves
to a different network, its communication environment considerably
changes. For example, in the case of wireless communication,
parameters such as radio strength largely changes depending on time
or site.
For efficient network communication, it is vital for a protocol layer
to know or utilize other layer's control information. There are
several proposals for seamless handovers in IPv6 network such as Fast
Handovers for Mobile IPv6 (FMIPv6) [1] and Hierarchical Mobile IPv6
(HMIPv6) [2]. In FMIPv6, the network layer must know the indication
of a handover from the link layer in advance to achieve seamless
handovers. However, control information exchange between protocol
layers is not allowed because each protocol layer is designed
independently.
To solve the problem, this draft defines nine kinds of L2
abstractions in the form of "primitive" to achieve fast handovers in
the network layer. This mechanism is called "L3-driven fast
handovers" because the network layer initiates L2 and L3 handovers by
using the "primitives".
Teraoka, et al. Expires March 25, 2007 [Page 5]
Internet-Draft L2 Abstractions September 2006
2. Terminology
This document uses the following terms.
L3-Driven Fast Handover
The handover mechanism which is initiated by the network layer on
a mobile node. Since this mechanism allows the handover
preparation in L3 before the start of an L2 handover on the mobile
node, it can reduce packet loss during a handover. The L3-driven
fast handover mechanism requires L2 information as a trigger of a
handover procedure.
Peer
The attachment point of a mobile node. (e.g., An access point in
IEEE 802.11 networks.)
Primitive
A unit of information which is sent from one layer to another.
There are four classes of primitives: Request, Confirm, Indication
and Response.
Teraoka, et al. Expires March 25, 2007 [Page 6]
Internet-Draft L2 Abstractions September 2006
3. Primitives for L2 Abstractions
Each layer offers its services in the form of primitives. There are
four classes of primitives as shown in Figure 1: Request, Confirm,
Indication, and Response. The request is issued by the layer that
wants to get the services or the information from another layer, and
the confirm is the acknowledgment of the request. The indication is
the notification of the information to the layer that requested the
service, and the response is the acknowledgment of the indication.
In this architecture, a layer can evenly communicate with each other.
------------------------------------------------------
Request Response
|| /\ /\ ||
Layer N || || || ||
------------||------||----------||------||------------
|| || || ||
\/ || || \/
Layer N-m Confirm Indication
------------------------------------------------------
Figure 1: Primitives
The primitive consists of five fields: the protocol layer id to which
this primitive should be sent, the protocol id to which protocol
entity this primitive should be sent, the primitive class (i.e.,
request, confirm, indication, or response), the primitive name, and
parameters.
There are three different usages of "Primitives":
Type 1. To provide L2 information to upper layers immediately
A "Request" primitive is an acquisition request for L2
information. As a "Confirm" primitive, L2 information
returns immediately.
Type 2. To notify upper layers of L2 events asynchronously
"Request" and "Confirm" primitives are used just for
registration. When an event occurs, an "Indication"
primitive is asynchronously delivered to an upper layer.
Teraoka, et al. Expires March 25, 2007 [Page 7]
Internet-Draft L2 Abstractions September 2006
Type 3. To control L2 actions from upper layers
A "Request" primitive is a request for operation. Ack or
nack returns immediately as a "Confirm" primitive.
Teraoka, et al. Expires March 25, 2007 [Page 8]
Internet-Draft L2 Abstractions September 2006
4. Definitions of Primitives
To obtain and exchange L2 information, the following Primitives are
defined.
4.1. L2-LinkStatus (Type 1)
The L2-LinkStatus.request primitive is sent to the link layer when an
upper layer needs the current information of a link. The L2-
LinkStatus.request primitive contains the "Network Interface ID"
parameter. In response, the L2-LinkStatus.confirm primitive returns.
The L2-LinkStatus.confirm primitive contains three parameters:
"Network Interface ID", "Peer", and "Condition". "Peer" and
"Condition" indicate the current status of the link between the
mobile node and a peer.
4.2. L2-PeerList (Type 1)
The L2-PeerList.request primitive is sent to the link layer when an
upper layer needs a list of the candidate peers. The L2-
PeerList.request primitive contains the "Network Interface ID"
parameter. In response, the L2-PeerList.confirm primitive returns
with the "Network Interface ID" parameter and the "Peer List"
parameter. The "Peer List" parameter is a list of the candidate
peers.
4.3. L2-PeerFound (Type 2)
The L2-PeerFound.indication primitive is asynchronously provided to
an upper layer when new peers are detected. This primitive carries
the "Network Interface ID" parameter and the "Peer List" parameter.
The "Peer List" parameter contains the information of new peers
detected by the mobile node. In order to use this notification, the
registration process using the L2-PeerFound.request primitive and the
L2-PeerFound.confirm primitive is needed in advance. The L2-
PeerFound.request primitive has two parameters: "Network Interface
ID" and "Enable/Disable". The "Enable/Disable" parameter shows
whether this notification function is turned on. When this
registration succeeds, the L2-PeerFound.confirm primitive returns
with the "Network Interface ID" parameter and the "Ack" parameter in
response.
4.4. L2-PeerLost (Type 2)
The L2-PeerLost.indication primitive is asynchronously provided to an
upper layer when a peer included in the list of candidate peers
disappears. This primitive carries the "Network Interface ID"
parameter and the "Peer List" parameter. The "Peer List" parameter
Teraoka, et al. Expires March 25, 2007 [Page 9]
Internet-Draft L2 Abstractions September 2006
contains the information of the peers which disappeared from the
candidates list. The registration process using the L2-
PeerLost.request primitive and the L2-PeerLost.confirm primitive is
similar to the L2-PeerFound primitive described above.
4.5. L2-LinkUp (Type 2)
The L2-LinkUp.indication primitive is asynchronously provided to an
upper layer when a new link is connected. This primitive carries the
"Network Interface ID" parameter and the "Peer" parameter. The L2-
LinkUp.request primitive contains the "Network Interface ID"
parameter and the "Enable/Disable" parameter for registration. When
the registration succeeded, the L2-LinkUp.confirm primitive with the
"Network Interface ID" parameter and the "Ack" parameter returns.
4.6. L2-LinkDown (Type 2)
The L2-LinkDown.indication primitive is asynchronously provided to an
upper layer when an existing link is disconnected. The registration
processing is same as the L2-LinkUp primitive described above.
4.7. L2-LinkGoingDown (Type 2)
The L2-LinkGoingDown.indication primitive is asynchronously provided
to an upper layer when an existing link is about to be disconnected.
This notification contains two parameters: "Network Interface ID" and
"Peer". The "Peer" parameter indicates the attachment point at which
the link quality is degrading. In the registration processing, the
L2-LinkGoingDown.request primitive carries the "Network Interface ID"
parameter and the "Enable/Disable" parameter.
4.8. L2-LinkConnect (Type 3)
The L2-LinkConnect.request primitive is sent to the link layer when
an upper layer has to establish a new link to the specific "Peer".
This primitive carries the "Network Interface ID" parameter and the
"Peer" parameter. This operation begins after the link layer returns
the L2-LinkConnect.confirm primitive with "Ack".
4.9. L2-LinkDisconnect (Type 3)
The L2-LinkDisconnect.request primitive is sent to the link layer
when an upper layer has to tear down an existing link to the specific
"Peer". This primitive carries the "Network Interface ID" parameter
and the "Peer" parameter. This operation begins after the link layer
returns the L2-LinkDisconnect.confirm primitive with "Ack".
Teraoka, et al. Expires March 25, 2007 [Page 10]
Internet-Draft L2 Abstractions September 2006
5. Definitions of Static Parameters
This section lists static parameters. Once the values of static
parameters are configured, they basically remain unchanged during
communication. The following parameters are transferred as a part of
primitives.
5.1. Network Interface ID
The "Network interface ID" parameter uniquely identifies the network
interface in the node. The syntax of the identifier is
implementation-specific (e.g., name, index or unique address assigned
to each interface). This parameter also contains the network
interface type which indicates the kind of technology of the network
interface (e.g., IEEE802.11a/b/g, 3GPP, etc.). This parameter is
required in all primitives.
Teraoka, et al. Expires March 25, 2007 [Page 11]
Internet-Draft L2 Abstractions September 2006
6. Definitions of Dynamic Parameters
This section lists dynamic parameters. The values of dynamic
parameters change frequently during communication. The following
parameters are transferred as a part of primitives.
6.1. Peer
The "Peer" parameter uniquely identifies the peer.
6.2. Condition
The "Condition" parameter consists of the following sub-parameters:
available bandwidth and link quality level. These sub-parameters are
the abstracted information that indicates the current quality-of
service. The abstraction algorithms of sub-parameters depend on
hardware devices and software implementation. The useful range of
link quality is divided into five levels; EXCELLENT, GOOD, FAIR, BAD,
NONE in descending order.
6.3. Peer List
The "Peer List" parameter consists of arbitrary couples of two sub-
parameters: "Peer" and "Condition". This parameter shows a list of
peers and its condition.
6.4. Enable/Disable
The "Enable/Disable" flag is used for turning event notification on/
off. When an upper layer needs notifications, the "Request"
primitive with "Enable" is sent to the link layer as registration.
When an upper layer needs no more notifications, the "Request"
primitive with "Disable" is sent.
6.5. Ack/Error
When an upper layer requests some notifications, the link layer
receives and confirms this "Request". If the "Request" is valid, the
"Confirm" primitive with "Ack" is sent to the upper layer. If it is
invalid, the "Confirm" with "Error" is sent to the upper layer.
Teraoka, et al. Expires March 25, 2007 [Page 12]
Internet-Draft L2 Abstractions September 2006
7. Architectural Considerations
The IAB document "Architectural Implications of Link Indications" [3]
discusses the role and the issues of link indications within the
Internet Architecture. This section discusses the architectural
considerations mentioned in Section 2 of the IAB document.
[1] Proposals should avoid use of simplified link models in
circumstances where they do not apply.
The information in each layer should be abstracted before it is
sent to another layer. For example, in IEEE 802.11, the
Received Signal Strength Indicator (RSSI), the number of
retransmissions and existence of association between the mobile
node and the access point are used so that the link layer
indications can adjust themselves to various environments or
situations. The thresholds needed for some link indications
are defined from empirical study.
In the conventional protocol layering model, the Protocol
Entity (PE) is defined as the entity that processes a specific
protocol. Our proposal introduced the Abstract Entity (AE) to
achieve link independency of the link indications. An AE and a
PE make a pair. An AE abstracts the PE-dependent information
to the PE-independent information.
Figure 2 shows AEs and PEs using primitives.
[2] Link indications should be clearly defined, so that it is
understood when they are generated on different link layers.
To make the link information/indications clear, our proposal
defines the 4 types of primitives; request/confirm and
indication/response as described in Section 3. The request is
used to obtain the information of another layer. The confirm
is the reply to the request and it includes the requested
information. The indication is generated when a particular
event occurred. The response is the reply to the indication.
In our proposal about IEEE 802.11b, L2-LinkUp is defined as the
status in which an association to the AP is established, and
L2-LinkDown is defined as the status in which an association to
the AP is not established. L2-LinkGoingdown is generated when
the link quality becomes below the predefined threshold. Since
Teraoka, et al. Expires March 25, 2007 [Page 13]
Internet-Draft L2 Abstractions September 2006
the Received Signal Strength Indicator (RSSI) and the number of
retransmissions are used to abstract and evaluate the link
quality, L2-LinkGoingDown represents the link quality in both
directions. It should use an average of RSSI or the number of
retransmissions damped for one second or more to cope with
transient link conditions.
[3] Proposals must demonstrate robustness against misleading
indications.
Since RSSI changes largely even when the mobile node stands
still according to the measurements in our experiments, our
proposal uses the RSSI, the number of retransmissions, and the
existence of an association to calculate the link status as
described above. In our experiments, there were some "ping-
pong" handovers between two APs. Such ping-pong handovers
could be reduced by detecting the most suitable AP by L2-
LinkStatus when L2-LinkGoingDown is notified. The use of L2
indications is related to parameter thresholds which trigger
handover. These thresholds vary based on the deployment
scenario, and if not configured properly, could lead to
misleading indications.
[4] Upper layers should utilize a timely recovery step so as to
limit the potential damage from link indications determined to
be invalid after they have been acted on.
The proposed L3-driven handover described in Appendix D uses
the L2-LinkGoingDown indication as the trigger for starting
handover. L2-LinkGoingDown is indicated when the link quality
goes down below the specific threshold. This indication is not
canceled even if the link quality goes up soon. As described
above, L2-LinkStatus can be used to detect the most suitable
AP. The IP layer can cancel a handover if it finds that the
current AP is the most suitable one by using L2-LinkStatus when
L2-LingGoingDown is notified.
[5] Proposals must demonstrate that effective congestion control is
maintained.
Since this mechanism is coupled to the IP layer, and not
directly to the transport layer, the proposed mechanism is not
Teraoka, et al. Expires March 25, 2007 [Page 14]
Internet-Draft L2 Abstractions September 2006
directly affecting congestion control.
[6] Proposals must demonstrate the effectiveness of proposed
optimizations.
In IPv6 mobility, the L3-driven handover mechanism using link
indications can dramatically reduce gap time due to handover.
The L3-driven handover mechanism needs the L2-LinkGoingDown
indication to predict disconnection. But L2-LinkGoingDown is
not sometimes trusted because it is difficult to abstract the
link quality. Invalid L2-LinkGoingDown may cause redundant
handover. A handover mechanism using only L2-LinkUp/
L2-LinkDown can also reduce gap time modestly. An example of
an implementation and an evaluation of the L3-driven handover
mechanism is described in Appendix D.
[7] Link indications should not be required by upper layers, in
order to maintain link independence.
Our proposal does not require any modifications to the
transport and upper layers.
[8] Proposals should avoid race conditions, which can occur where
link indications are utilized directly by multiple layers of
the stack.
Since our proposal defines the link indications to only the IP
layer, race conditions between multiple layers never happen.
[9] Proposals should avoid inconsistencies between link and routing
layer metrics.
Our proposal does not deal with routing metrics.
[10] Overhead reduction schemes must avoid compromising
interoperability and introducing link layer dependencies into
the Internet and Transport layers.
Teraoka, et al. Expires March 25, 2007 [Page 15]
Internet-Draft L2 Abstractions September 2006
As described above, the link indications in our proposal are
abstracted to the information independent of link types to
reduce the gap time due to a handover, and the ordinary host
can execute handover without using the link indications defined
in our proposal.
[11] Proposals advocating the transport of link indications beyond
the local host need to carefully consider the layering,
security and transport implications. In general, implicit
signals are preferred to explicit transport of link indications
since they add no new packets in times of network distress,
operate more reliably in the presence of middle boxes such as
NA(P)Ts, are more likely to be backward compatible, and are
less likely to result in security vulnerabilities.
Our proposal does not define exchange of link indications
between nodes.
---------------------------------------------------------
----------=========== ----------===========
| |[ ] | |[ ]
| PE |[ AE ] | PE |[ AE ]
| |[ ] | |[ ]
----------=========== ----------===========
Layer N || /\ || /\
------------||---||-------------------||---||------------
Request|| || Response|| ||
|| || || ||
|| || || ||
|| ||Confirm || ||Indication
------------||---||-------------------||---||------------
\/ || \/ ||
----------=========== ----------===========
| |[ ] | |[ ]
| PE |[ AE ] | PE |[ AE ]
| |[ ] | |[ ]
----------=========== ----------===========
Layer N-m
----------------------------------------------------------
Figure 2: AE and PE with Primitives
Teraoka, et al. Expires March 25, 2007 [Page 16]
Internet-Draft L2 Abstractions September 2006
8. Security Considerations
The IAB document "Architectural Implications of Link Indications" [3]
discusses the role and the issues of link indications within the
Internet Architecture. This section discusses the security
considerations mentioned in Section 4 of the IAB document.
[1] Spoofing
Our proposal is no more insecure than a particular link layer on
which it is implemented.
[2] Indication validation
Transportation of the link indications between nodes is not
assumed, hence this consideration is out of scope in our
proposal.
[3] Denial of service
Our proposal is no more insecure than a particular link layer on
which it is implemented.
Teraoka, et al. Expires March 25, 2007 [Page 17]
Internet-Draft L2 Abstractions September 2006
9. References
[1] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[2] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
RFC 4140, August 2005.
[3] Aboda, B., "Architectural Implications of Link Indications",
draft-iab-link-indications-05 (work in progress), July 2006.
[4] Ishiyama, M., Kunishi, M., Esaki, H., and F. Teraoka, "LINA: A
New Approach to Mobility Support in Wide Area Networks", IEICE
Transactions on Communication vol. E84-B, no. 8, pp. 2076-2086,
August 2001.
Teraoka, et al. Expires March 25, 2007 [Page 18]
Internet-Draft L2 Abstractions September 2006
Appendix A. Example Scenario
For example, the picture below shows L3-driven fast handover
mechanism using the L2 triggers on MN.
L2 L3
| |
|<----------LinkUP.req-----------|
|-----------LinkUP.cnf---------->|
|<-------LinkGoingDown.req-------|
|--------LinkGoingDown.cnf------>|
= =
| |
Low |
Signal-----LinkGoingDown.ind------>|
| |
|<---------PeerList.req----------|
|----------PeerList.cnf------>Handover
| Preparation
|<-------LinkConnect.req---------|
L2 Handover--LinkConnect.cnf-------->:
: :
: :
finish---------LinkUp.ind----->L3 Handover
| finish
| |
L2: Link Layer on MN
L3: Network Layer on MN
req: Request
cnf: Confirm
ind: Indication
Figure 3: L3-Driven Fast Handover Mechanism
First, the L3 issues LinkUp.request to receive LinkUp.indication when
the link becomes available. The L3 also issues LinkGoingDown.request
to receive LinkGoingDown.indication when the link quality goes down
below the threshold.
In the beginning of the L3-driven handover procedure, the L2 detects
the radio signal strength is going down. Then the L2 sends L2-
LinkGoingDown.indication to the L3. The L3 prepares for handover
(e.g., CoA generation, DAD, ND cache creation, and routing table
setting) and sends L2-PeerList.request to the L2 if the list of
access points is needed.
Teraoka, et al. Expires March 25, 2007 [Page 19]
Internet-Draft L2 Abstractions September 2006
If the L3 decides to perform handover according to some rules, the L3
sends L2-LinkConnect.request with some parameters about candidate
access points to request L2 handover. L2 handover begins after the
L3 sends L2-LinkConnect.confirm to the L2. When the L2 handover
finished, the L2 sends L2-LinkUp.indication to notify the L3.
Finally, the L3 performs handover (e.g., sending BU).
One of the important features of L3-driven fast handover using
Primitives is that the L3 handover preparation can be done during
communication. So, it can reduce disruption time during handover.
Teraoka, et al. Expires March 25, 2007 [Page 20]
Internet-Draft L2 Abstractions September 2006
Appendix B. Example Operation for FMIPv6
Here shows 2 scenarios of L3 driven fast handover for FMIPv6.
Scenario 2 is differ from scenario 1 for the timing of sending some
messages.
B.1. Example Operation-1 for FMIPv6
Figure 4 shows the predictive mode of FMIPv6 operation with L3-driven
link switching mechanism.
Teraoka, et al. Expires March 25, 2007 [Page 21]
Internet-Draft L2 Abstractions September 2006
MN-L2 MN-L3 PAR-L3
| | |
AP<---------PeerList.req----------| |
Scan---------PeerList.cnf--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
|---------PeerFound.ind--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
| | |
~ ~ ~
| | |
Low | |
Signal-----LinkGoingDown.ind------>| | NAR-L3
| |-----FBU---->| |
| | |----HI---->|
| | |<--HAck----|
| |<----FBack---| |
|<-------LinkConnect.req---L3 Handover | |
L2 Handover--LinkConnect.cnf-------->: |
: : |
: : |
finish---------LinkUp.ind---------->: |
| :-----------FNA---------->|
| finish<======packets=========|
| | |
MN-L2 : Link Layer on Mobile Node
MN-L3 : Network Layer on Mobile Node
PAR-L3 : Network Layer on Previous Access Router
NAR-L3 : Network Layer on New Access Router
req : Request
cnf : Confirm
ind : Indication
RtSolPr : Router Solicitation for Proxy
PrRtAdv : Proxy Router Advertisement
FBU : Fast Binding Update
FBack : Fast Binding Acknowledgment
FNA : Fast Neighbor Advertisement
HI : Handover Initiate
HAck : Handover Acknowledge
Figure 4: L3-Driven Fast Handover Mechanism with FMIPv6 scenario 1
When the MN establishes link connectivity to the PAR, it performs
router discovery. The MN sends RtSolPr message to the PAR to resolve
the access point identifiers to the subnet router information. To
Teraoka, et al. Expires March 25, 2007 [Page 22]
Internet-Draft L2 Abstractions September 2006
send RtSolPr, a MN discovers one or more access points by sending L2-
PeerList.request to the link layer. As a response to L2-
PeerList.request, L2-PeerList.confirm returns with "Peer List"
parameter which contains identifiers and conditions of nearby access
points. After initial AP discovery, L2-PeerFound.indication with
"Peer List" is also sent from the link layer when one or more access
points are discovered.
When the link layer of the MN detects that radio signal strength is
going down, it sends L2-LinkGoingDown.indication to the network
layer. Then, the MN sends the FBU message to the PAR as the
beginning of the L3 handover procedure. The NCoA required for the
FBU message is determined according to the MN's policy database and
the received PrRtAdv message. As a response to the FBU message, the
MN receives the FBack message and then immediately switches its link
by L2-LinkConnect.request with the specific "Peer" parameter. The
handover policy of the MN is outside the scope of this document.
After L2 handover, the link layer of the MN sends L2-
LinkUp.indication to the network layer. The MN immediately sends the
FNA message to the NAR. The NAR will send tunneled and buffered
packets to the MN.
B.2. Example Operation-2 for FMIPv6
Figure 5 shows the predictive mode of FMIPv6 operation with L3-driven
link switching mechanism.
Teraoka, et al. Expires March 25, 2007 [Page 23]
Internet-Draft L2 Abstractions September 2006
MN-L2 MN-L3 PAR-L3
| | |
AP<---------PeerList.req----------| |
Scan---------PeerList.cnf--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
|---------PeerFound.ind--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
| | |
~ ~ ~
| | |
Low | |
Signal-----LinkGoingDown.ind------>| | NAR-L3
| |-----FBU---->| |
|<-------LinkConnect.req---L3 Handover | |
L2 Handover--LinkConnect.cnf-------->: | |
| | |----HI---->|
| | |<--HAck----|
| | |---FBack-->|
| |<----FBack---------------|
: : |
finish---------LinkUp.ind---------->: |
| :-----------FNA---------->|
| finish<======packets=========|
| | |
MN-L2 : Link Layer on Mobile Node
MN-L3 : Network Layer on Mobile Node
PAR-L3 : Network Layer on Previous Access Router
NAR-L3 : Network Layer on New Access Router
req : Request
cnf : Confirm
ind : Indication
RtSolPr : Router Solicitation for Proxy
PrRtAdv : Proxy Router Advertisement
FBU : Fast Binding Update
FBack : Fast Binding Acknowledgment
FNA : Fast Neighbor Advertisement
HI : Handover Initiate
HAck : Handover Acknowledge
Figure 5: L3-Driven Fast Handover Mechanism with FMIPv6 scenario 2
Unlike the scenario 1, the MN in scenario 2 sends LinkConnect.req
from the network layer to the link layer after MN sends the FBU
message. As the MN sends the FBack message to both AR (not only the
Teraoka, et al. Expires March 25, 2007 [Page 24]
Internet-Draft L2 Abstractions September 2006
PAR but also the NAR), the MN can get the FBack message sent by the
PAR through the NAR, and then it moves to the NAR.
B.3. Experiment
We implemented FMIPv6 and the proposed L2 primitives on FreeBSD-5.4.
Figure 6 shows our test network. The MN is connected to access
routers by using IEEE802.11a wireless LAN. The MN moves from the PAR
to the NAR.
|
+--+---+
|Router|
+--+---+
| 100BaseTX
---+--------+---------+---------+---------+------------
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| PAR | | NAR | | HA | | CN |
+-----+ +-----+ +-----+ +-----+
| |
IEEE802.11a IEEE802.11a PAR, NAR: nexcom EBC
|Channel 7 |Channel7 MN: ThinkPad X31
OS: FreeBSD-5.4
| | KAME/SHISA/TARZAN
+-----+ +-----+
| MN | -------> | MN |
+-----+ +-----+
Figure 6: Test Network
Scenario 1 was used in this experiment. Upon receiving L2-
LinkGoingDown.indication, the L3 of the MN sends the FBU message and
then receives the FBack message. It took 20ms from the transmission
of the FBU message and the reception of the FBack message. After
receiving the FBack message, the L3 of the MN issues L2-
LinkConnect.request to the L2. When L2 handover finishes, the L3
receives L2-LinkUp.ind from the L2. It took 1ms for an L2 handover.
Next, the MN sends the FNA message to the NAR. Upon receiving the
FNA message, the NAR starts forwarding packets to the NM. ICMP echo
request packets were sent at 10ms intervals. It was observed that no
or 1 ICMP echo reply packet was lost during a handover.
Teraoka, et al. Expires March 25, 2007 [Page 25]
Internet-Draft L2 Abstractions September 2006
MN PAR NAR
| | |
|----- RtSolPr --->| |
|<---- PrRtAdv ----| |
| | |
+--- |------ FBU ------>| |
| | |------- HI ------>|
20ms| | | |
| | |<----- HAck ------|
| | | |
+--- |<-------------- FBack -------------->|
| | |
+-- disconnect | |
| 1ms| | |
| connect | |
8-10ms| | | |
| 7ms| | |
| | | |
| +----- FNA -------------------------->|
+-- |<------------------------ deliver packets
| | |
Figure 7: Measured Results
Teraoka, et al. Expires March 25, 2007 [Page 26]
Internet-Draft L2 Abstractions September 2006
Appendix C. Example Mapping of Primitives and IEEE802.11
This section shows examples of the mapping between "Primitives" and
IEEE802.11 parameters.
C.1. L2-LinkStatus
Most of parameters of L2-LinkStatus are related to the configuration
of network interface hardware. The operating system and the device
driver module can easily collect such information. However, to
create the "Condition" parameter, the MN should maintain statistics
and parameters related to the current wireless environment.
There are two sub-parameters of the "Condition" parameter: available
bandwidth and link quality level. The available bandwidth of the
current peer can be obtained by maintaining the transmission rate
indication and the statistics of frame transmission at every time a
frame is sent. A link quality level can be updated by maintaining
the following parameters and statistics at every time a frame is
received: receive signal strength indication (RSSI), transmission/
reception rate indication, transmit/receive latency, bit error rate,
frame error rate and noise level. Link quality level is divided into
five levels: EXCELLENT, GOOD, FAIR, BAD, and NONE in descending
order. Some parameters can be managed by setting threshold from
software. When the parameters cross the threshold, an interrupt is
generated for the software.
C.2. L2-PeerList
In IEEE 802.11 networks, L2-PeerList returns the detected APs which
quality level exceeds the specified threshold as peer candidates (by
the "Peer List" parameter). Therefore, the MN should always maintain
the database of available access points according to reception of
beacon frame, probe response frame and all frames. This AP database
is managed in consideration of time, number of frames and signal
strength. There are some kinds of network interface hardware that
can notify events to operating system only when the desired event
occurs, by setting a threshold from software. Moreover, the MN can
transmit the probe request frame for access point discovery, if
needed.
C.3. L2-PeerFound
In IEEE 802.11 networks, L2-PeerFound is notified when new peers
which link quality level exceeds the specified threshold are detected
by listening beacons or scanning APs. If the received frame (mainly
the beacon or the probe response) is not in the AP database described
in Appendix C.2, then the link layer creates L2-PeerFound.indication.
Teraoka, et al. Expires March 25, 2007 [Page 27]
Internet-Draft L2 Abstractions September 2006
For example, if the threshold of link quality level specified by L2-
PeerFound.request is GOOD, the L2-PeerFound.ind is made and sent to
the upper layer when peer's link quality becomes stronger than to the
level of GOOD.
C.4. L2-PeerLost
In IEEE 802.11 networks, L2-PeerLost is notified when an AP included
in the list of candidate APs is got lost by listening beacons or
scanning APs. If the entry in the AP database described in
Appendix C.2 expires, or link quality level goes under the threshold,
then the link layer creates L2-PeerLost.indication. To calculate the
link quality level, the signal strength of the received frame (mainly
the beacon or the probe response) can be used. For example, if the
threshold of the link quality specified by L2-PeerLost is BAD, L2-
PeerLost.ind is made and sent to the upper layer when peer's link
quality becomes weaker than the level of BAD.
C.5. L2-LinkUp
In IEEE 802.11 networks, L2-LinkUp is notified when association or
reassociation event occurs. When such event occurs, the MN receives
the association response frame or the reassociation response frame.
Immediately after receiving it, the link layer creates L2-
LinkUp.indication.
C.6. L2-LinkDown
In IEEE 802.11 networks, L2-LinkDown is notified when disassociation
event occurs or when no beacon is received during a certain time.
When such event occurs, the MN sends the disassociation frame to the
AP, or the entry of the specific AP is deleted from the AP database
described in Appendix C.2. By detecting such events, the link layer
creates L2-LinkDown.indication.
C.7. L2-LinkGoingDown
In IEEE 802.11 networks, L2-LinkGoingDown is notified when the radio
signal strength of the connected AP is going down and becomes under
the specified threshold.
C.8. L2-LinkConnect
In IEEE802.11 networks, each AP is identified by the BSSID and the
service set of several APs is identified by the SSID. When L2-
LinkConnect is used to connect a specific AP or a service set, the
link layer should set the BSSID or the SSID. Also, the channel
should be set appropriately at the same time by searching the
Teraoka, et al. Expires March 25, 2007 [Page 28]
Internet-Draft L2 Abstractions September 2006
database described in Appendix C.2. To connect to the AP, the MN
should be authenticated by the AP. The MN sends the authentication
message to the AP, and then the MN sends the association message to
associate with the AP.
C.9. L2-LinkDisconnect
In IEEE802.11 networks, the MN sends the disassociation message to
the AP for disconnection. When L2-LinkDisconnect is used for
disconnection from the current AP, the link layer should send the
disassociation message to the appropriate AP, and stop data
transmission.
Teraoka, et al. Expires March 25, 2007 [Page 29]
Internet-Draft L2 Abstractions September 2006
Appendix D. Implementation and Evaluation of the Proposed Model
This section describes an implementation of the proposed link
indication architecture and its evaluation.
An IEEE802.11a wireless LAN device driver was modified to provide
abstract link layer information in the form of primitives defined in
Section 4. The modified driver has two AP lists. One contains the
device dependent information such as the RSSI, the retransmission
count, various AP parameters and various statistics. The device
dependent information except for the AP parameters is updated
whenever the device receives a frame. If the received frame is the
management frame, the AP parameters are also updated according to the
parameters in the frame.
Another AP list contains the abstract information. The abstract
information is updated periodically by using the device dependent
information. In the abstraction processing, for example, the RSSI or
the retransmission count is converted to the common indicator "link
quality".
L2-PeerList and L2-LinkStatus were implemented by using only the
abstract information. Thus, the upper layers can use information of
the current AP and the adjacent APs without depending on the devices.
L2-PeerFound or L2-PeerLost is notified if the link quality went up
or down beyond the thresholds when the abstract information is
updated. If the link quality of the current AP went down below the
specific threshold, L2-LinkGoingDown is notified. L2-LinkUp or L2-
LinkDown is notified when an association with an AP is established or
destroyed. To realize L2-LinkConnect and L2-LinkDisconnect,
functions to connect or disconnect to the specified AP were
implemented. In these functions, since only abstract information is
needed to specify the AP, other layers need not to know the device
dependent information.
In our outdoor testbed, there are eight ARs, each of which is located
at a 80-100m interval. The AP is collocated at the AR. IEEE802.11a
was used as the link layer. The same wireless channel was used at
all the APs. Thus there are eight wireless IPv6 subnets in the
testbed. The mobile node in a car moved at a speed of 30-40 km/h.
When link quality of the current AP goes down, the mobile node
executes L3-driven handover described in Appendix A. An application
called DVTS was running on the mobile node and sent digital video
data at about a 15Mbps data rate through the wireless IPv6 subnet to
the correspondent node, which replayed received digital video data.
In this environment, the L2 handover needed less than 1 msec and
mobility protocol LIN6 [4] needed a few msec for location
registration. Thus, the total gap time due to the handover was 3-4
Teraoka, et al. Expires March 25, 2007 [Page 30]
Internet-Draft L2 Abstractions September 2006
msec. In most case, there was no influence to the replayed pictures
over handover.
Teraoka, et al. Expires March 25, 2007 [Page 31]
Internet-Draft L2 Abstractions September 2006
Appendix E. Changes from 01
- References were updated.
Teraoka, et al. Expires March 25, 2007 [Page 32]
Internet-Draft L2 Abstractions September 2006
Authors' Addresses
Fumio Teraoka
Graduate School of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: 45-566-1425
Email: tera@ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Kazutaka Gogo
Faculty of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: 45-566-1425
Email: gogo@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Koshiro Mitsuya
Jun Murai Lab, Shonan Fujisawa Campus, KEIO University
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81-466-49-1100
Email: mitsuya_at_sfc.wide.ad.jp
URI:
Rie Shibui
Graduate School of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: 45-566-1425
Email: shibrie@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Teraoka, et al. Expires March 25, 2007 [Page 33]
Internet-Draft L2 Abstractions September 2006
Koki Mitani
Graduate School of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: 45-566-1425
Email: koki@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Teraoka, et al. Expires March 25, 2007 [Page 34]
Internet-Draft L2 Abstractions September 2006
Full 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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Teraoka, et al. Expires March 25, 2007 [Page 35]
