One document matched: draft-koki-mobopts-l2-abstractions-00.txt
INTERNET DRAFT Koki Mitani
12 July 2004 Rie Shibui
Fumio Teraoka
Keio University
Unified L2 Abstractions for L3-Driven Fast Handover
draft-koki-mobopts-l2-abstractions-00.txt
Status of This Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 12, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This draft proposes unified L2 abstractions for L3-driven fast
handover. For efficient network communication, it is vital for a
protocol layer to know or utilize other layer's information such as
L2 triggers. However, in current operating systems, each protocol
layer is designed independently and information exchange between
protocol layers is not allowed. To solve the problem, this draft
defines 9 kinds of L2 abstractions in the form of "Primitive". This
concept can be applied to L3-driven fast handover mechanism using
"Primitives".
K. Mitani et.al. Expires 12 January 2005 [Page i]
Internet Draft L2 Abstractions 12 July 2004
Contents
Status of This Memo i
Copyright Notice i
Abstract i
1. Introduction 2
2. Terminology 2
3. Primitives for L2 Abstractions 3
4. Definitions of Primitives 3
4.1. L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . 4
4.2. L2-PeerList (Type 1) . . . . . . . . . . . . . . . . . . 4
4.3. L2-PeerFound (Type 2) . . . . . . . . . . . . . . . . . . 4
4.4. L2-PeerLost (Type 2) . . . . . . . . . . . . . . . . . . 4
4.5. L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . 5
4.6. L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . 5
4.7. L2-LinkToBeDown (Type 2) . . . . . . . . . . . . . . . . 5
4.8. L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 6
4.9. L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . 6
5. Security Consideration 6
References 6
Authors' Addresses 7
Appendices 8
A. Example Scenario 8
Full Copyright Statement 10
Intellectual Property Statement 10
K. Mitani et.al. Expires 12 January 2005 [Page 1]
Internet Draft L2 Abstractions 12 July 2004
1. Introduction
In recent years, the environment around computers is not static
and changes dynamically. Especially, when a mobile node moves to
a different network, its environment considerably changes. For
example, in the case of wireless communication, parameters such as
radio strength changes widely depends on time or site.
For efficient network communication, it is vital for a protocol
layer to know or utilize other layer's 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, each protocol layer is designed independently
and information exchange between protocol layers is not allowed.
For further handover enhancements, this document defines 9 kinds of
L2 triggers in the form of "Primitive". This concept can be applied
to L3-driven fast handover mechanism using "Primitives".
2. Terminology
This document uses the following terms.
L3-Driven Fast Handover
The handover which is initiated by the network layer on a
mobile node. Since it allows L3 handover preparation during
communication, it can reduce packet loss during handover.
L3-driven fast handover mechanism requires L2 information as a
trigger of 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.
K. Mitani et.al. Expires 12 January 2005 [Page 2]
Internet Draft L2 Abstractions 12 July 2004
3. Primitives for L2 Abstractions
Each layer offers its services by 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 services or information from another layer, and the
confirm is the acknowledgement of the request. The indication is a
notification of information to the layer that requested the service,
and the response is the acknowledgement of the indication. In this
architecture, each layer can communicate evenly.
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
Type 2. To notify upper layers of L2 events
Type 3. To control L2 from upper layers
------------------------------------------------------
Request Response
|| /\ /\ ||
Layer N || || || ||
------------||------||----------||------||------------
|| || || ||
\/ || || \/
Layer N-m Confirm Indication
------------------------------------------------------
Figure 1: Primitives
4. Definitions of Primitives
In order to obtain and change L2 information, some sorts of
Primitives described below are necessary. The following Primitives
are defined.
K. Mitani et.al. Expires 12 January 2005 [Page 3]
Internet Draft L2 Abstractions 12 July 2004
4.1. L2-LinkStatus (Type 1)
The L2-LinkStatus.request is sent to the link layer when an upper
layer needs the current information of the link. In response, the
L2-LinkStatus.confirm returns. The L2-LinkStatus.confirm primitive
contains five special parameters: the "i/f type options", the "i/f
data rate", the "security", the "condition" and the "peer". The "i/f
type options" shows the option of the network interface type, such as
IEEE 802.11i. The "i/f data rate" is the configured data rate of the
network interface. The "security" identifies the current configured
security scheme such as EAP. The "condition" and the "peer" indicates
the current status about the link between the network interface and
the peer.
4.2. L2-PeerList (Type 1)
The L2-PeerList.request is sent to the link layer when an upper
layer needs a list of the candidate peers. In response, the
L2-PeerList.confirm returns with the "peer-list" parameter which is
the list of candidate peers.
In IEEE 802.11 networks, L2-PeerList returns all detected APs as peer
candidates.
4.3. L2-PeerFound (Type 2)
The L2-PeerFound.indication is asynchronously provided to an upper
layer when new peers are detected. This primitive carries the
"peer-list" parameter which contains the information of the new
peers detected. In order to use this notification, the registration
process using L2-PeerFound.request is needed in advance. The
L2-PeerFound.request primitive has two special parameters: the
"condition" and the "enable/disable". The "condition" parameter
prevents unnecessary detection of peers (e.g., in case the quality
of the radio link to a peer is very low). The "enable/disable"
parameter shows whether this notification function is turned on.
When this registration succeeds, the L2-PeerFound.confirm returns
with "ack" parameter in response.
In IEEE 802.11 networks, L2-PeerFound is notified when new peers are
detected by listening beacons or scanning APs.
4.4. L2-PeerLost (Type 2)
The L2-PeerLost.indication is asynchronously provided to an
upper layer when a peer included in the list of candidate peers
is got lost. This primitive carries the "peer-list" parameter
which contains the information of the peers which disappeared
from the candidates list. The registration process using the
L2-PeerLost.request and the L2-PeerLost.confirm is similar to the
L2-PeerFound above.
K. Mitani et.al. Expires 12 January 2005 [Page 4]
Internet Draft L2 Abstractions 12 July 2004
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.
4.5. L2-LinkUp (Type 2)
The L2-LinkUp.indication is asynchronously provided to an upper layer
when a new link is connected. The L2-LinkUp.request contains the
"enable/disable" parameter for registration operation. When the
registration succeeds, the L2-LinkUp.confirm with "ack" parameter
returns.
In IEEE 802.11 networks, L2-LinkUp is notified when association or
reassociation event occurs.
4.6. L2-LinkDown (Type 2)
The L2-LinkDown.indication is asynchronously provided to an upper
layer when an existing link is disconnected. The registration
processing is same as the L2-LinkUp above.
In IEEE 802.11 networks, L2-LinkDown is notified when disassociation
event occurs.
4.7. L2-LinkToBeDown (Type 2)
The L2-LinkToBeDown.indication is asynchronously provided to an upper
layer when an existing link is to be disconnected. This notification
contains two special parameters: the "condition" and the "peer".
The "condition" shows the current link status. The "peer" is the
attachment point at which the link quality is degrading. In the
registration processing, the L2-LinkToBeDown.request carries not
only the "enable/disable" parameter but the "condition" parameter to
specify the threshold of notification.
In IEEE 802.11 networks, L2-LinkToBeDown is notified when radio
signal strength is going down.
4.8. L2-LinkConnect (Type 3)
The L2-LinkConnect.request is sent to the link layer when an upper
layer has to change or create a new link to the specific "peer".
This operation begins after sending L2-LinkConnect.confirm with
"ack".
4.9. L2-LinkDisconnect (Type 3)
The L2-LinkDisconnect.request is sent to the link layer when an upper
layer has to destroy an existing link to the specific "peer". This
operation begins after sending L2-LinkDisconnect.confirm with "ack".
K. Mitani et.al. Expires 12 January 2005 [Page 5]
Internet Draft L2 Abstractions 12 July 2004
5. Security Consideration
It is recommended that the implementers consider the security
features to manage the L2 information.
References
[1] R. Koodli, G. Dommety, K. El-Malki, M. Khalil, C. E. Perkins,
H. Soliman, G. Tsirtsis, and A. E. Yegin. Fast Handovers for
Mobile IPv6, work in progress, Jan. 2004.
[2] H. Soliman, C. Castelluccia, K. El-Malki, and L. Bellier.
Hierarchical Mobile IPv6 mobility management (HMIPv6), work in
progress, Jun. 2004.
K. Mitani et.al. Expires 12 January 2005 [Page 6]
Internet Draft L2 Abstractions 12 July 2004
Authors' Addresses
Koki Mitani
Graduate School of Science and
Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku,
Yokohama, Kanagawa 223-8522
JAPAN
Phone: +81-45-566-1425
EMail: koki@tera.ics.keio.ac.jp
Rie Shibui
Graduate School of Science and
Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku,
Yokohama, Kanagawa 223-8522
JAPAN
Phone: +81-45-566-1425
EMail: shibrie@tera.ics.keio.ac.jp
Fumio Teraoka
Graduate School of Science and
Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku,
Yokohama, Kanagawa 223-8522
JAPAN
Phone: +81-45-566-1425
EMail: tera@ics.keio.ac.jp
K. Mitani et.al. Expires 12 January 2005 [Page 7]
Internet Draft L2 Abstractions 12 July 2004
A. Example Scenario
For example, the picture below shows L3-driven fast handover
mechanism using the L2 triggers on MN.
L2 L3
| |
Low |
Signal-----LinkToBeDown.ind------->|
| |
| Handover
AP<---------PeerList.req------Preparation
Scan---------PeerList.cnf--------->|
| |
|<-------LinkConnect.req----L3 Handover
L2 Handover--LinkConnect.cnf-------->:
: :
: :
finish---------LinkUp.ind---------->:
| :
| finish
| |
L2: Link Layer on MN
L3: Network Layer on MN
req: request
cnf: confirm
ind: indication
Figure 2: L3-Driven Fast Handover Mechanism
In the beginning of the L3-driven handover procedure, L2
detects radio signal strength is going down. Then L2 sends
L2-LinkToBeDown.indication to L3. L3 prepares for handover (e.g.,
CoA generation, DAD) and sends L2-PeerList.request to L2 if the list
of access points is needed.
If L3 decides to perform handover according to some rules, L3 sends
L2-LinkConnect.request with some parameters about candidate access
points to request L2 handover. L2 handover begins after sending
L2-LinkConnect.confirm to L3. When L2 handover finished, L2 sends
L2-LinkUp.indication to notify L3. At last, 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.
K. Mitani et.al. Expires 12 January 2005 [Page 8]
Internet Draft L2 Abstractions 12 July 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
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 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.
K. Mitani et.al. Expires 12 January 2005 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-21 19:41:29 |