One document matched: draft-koki-mobopts-l2-abstractions-01.txt
Differences from draft-koki-mobopts-l2-abstractions-00.txt
IRTF MobOpts RG K. Mitani
Internet-Draft R. Shibui
Expires: April 25, 2005 F. Teraoka
KEIO University
October 25, 2004
Unified L2 Abstractions for L3-Driven Fast Handover
draft-koki-mobopts-l2-abstractions-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 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 as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
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
Mitani, et al. Expires April 25, 2005 [Page 1]
Internet-Draft L2 Abstractions October 2004
defines nine kinds of L2 abstractions in the form of "Primitive".
This concept can be applied to L3-driven fast handover mechanism
using "Primitives".
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Primitives for L2 Abstractions . . . . . . . . . . . . . . . . 6
4. Definitions of Primitives . . . . . . . . . . . . . . . . . . 7
4.1 L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . . 7
4.2 L2-PeerList (Type 1) . . . . . . . . . . . . . . . . . . . 7
4.3 L2-PeerFound (Type 2) . . . . . . . . . . . . . . . . . . 7
4.4 L2-PeerLost (Type 2) . . . . . . . . . . . . . . . . . . . 7
4.5 L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . . 8
4.6 L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . . 8
4.7 L2-LinkQualityChange (Type 2) . . . . . . . . . . . . . . 8
4.8 L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 8
4.9 L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . . 8
5. Definitions of Static Parameters . . . . . . . . . . . . . . . 9
5.1 Network Interface ID (i/f id) . . . . . . . . . . . . . . 9
5.2 Network Interface Type (i/f type) . . . . . . . . . . . . 9
5.3 Network Interface Type Options (i/f type options) . . . . 9
5.4 Network Interface Data Rate (i/f rate) . . . . . . . . . . 9
6. Definitions of Dynamic Parameters . . . . . . . . . . . . . . 10
6.1 Peer (peer) . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Condition (condition) . . . . . . . . . . . . . . . . . . 10
6.3 Threshold (threshold) . . . . . . . . . . . . . . . . . . 10
6.4 Peer List (peer-list) . . . . . . . . . . . . . . . . . . 10
6.5 Security (security) . . . . . . . . . . . . . . . . . . . 10
6.6 Enable/Disable (enable/disable) . . . . . . . . . . . . . 10
6.7 Ack/Error (ack/error) . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
A. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 14
B. Example Operation for FMIPv6 . . . . . . . . . . . . . . . . . 15
Mitani, et al. Expires April 25, 2005 [Page 2]
Internet-Draft L2 Abstractions October 2004
C. Example Mapping of Primitives and IEEE802.11 . . . . . . . . . 17
C.1 L2-LinkStatus . . . . . . . . . . . . . . . . . . . . . . 17
C.2 L2-PeerList . . . . . . . . . . . . . . . . . . . . . . . 17
C.3 L2-PeerFound . . . . . . . . . . . . . . . . . . . . . . . 17
C.4 L2-PeerLost . . . . . . . . . . . . . . . . . . . . . . . 18
C.5 L2-LinkUp . . . . . . . . . . . . . . . . . . . . . . . . 18
C.6 L2-LinkDown . . . . . . . . . . . . . . . . . . . . . . . 18
C.7 L2-LinkQualityChange . . . . . . . . . . . . . . . . . . . 18
C.8 L2-LinkConnect . . . . . . . . . . . . . . . . . . . . . . 18
C.9 L2-LinkDisconnect . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Mitani, et al. Expires April 25, 2005 [Page 3]
Internet-Draft L2 Abstractions October 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 nine kinds
of L2 triggers in the form of "Primitive". This concept can be
applied to L3-driven fast handover mechanism using "Primitives".
Mitani, et al. Expires April 25, 2005 [Page 4]
Internet-Draft L2 Abstractions October 2004
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.
Mitani, et al. Expires April 25, 2005 [Page 5]
Internet-Draft L2 Abstractions October 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 acknowledgment of the request. The indication is a
notification of information to the layer that requested the service,
and the response is the acknowledgment of the indication. In this
architecture, each layer can communicate evenly.
------------------------------------------------------
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
informaiton. 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.
Type 3. To control L2 actions from upper layers
Mitani, et al. Expires April 25, 2005 [Page 6]
Internet-Draft L2 Abstractions October 2004
A "request" primitive is a request for operation. Ack or
nack returns immediately as a "confirm" primitive.
Mitani, et al. Expires April 25, 2005 [Page 7]
Internet-Draft L2 Abstractions October 2004
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.
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.
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
"threshold" parameter, "condition" parameter and 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 "threshold" and the
"enable/disable". The "threshold" parameter prevents unnecessary
detection of peers (e.g., in case the quality level 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.
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 "threshold" parameter, "condition"
Mitani, et al. Expires April 25, 2005 [Page 8]
Internet-Draft L2 Abstractions October 2004
parameter and 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.
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.
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.
4.7 L2-LinkQualityChange (Type 2)
The L2-LinkQualityChange.indication is asynchronously provided to an
upper layer when an existing link is to be disconnected. This
notification contains three special parameters: the "condition", the
"threshold" and the "peer". The "condition" shows the current link
status. The "threshold" is the link quality level for a decision of
notification. The "peer" is the attachment point at which the link
quality is degrading. In the registration processing, the
L2-LinkQualityChange.request carries not only the "enable/disable"
parameter but the "threshold" parameter to specify the threshold of
notification.
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".
Mitani, et al. Expires April 25, 2005 [Page 9]
Internet-Draft L2 Abstractions October 2004
5. Definitions of Static Parameters
This section lists static parameters. Once the values of static
parameters are configured, they do not change frequently during
communication. The following parameters are transferred as a part of
primitives.
5.1 Network Interface ID (i/f id)
The network interface ID identifies uniquely the network interface in
a node. The identifier is an implementation-specific consideration
(e.g., name, index or unique address assigned to each interface).
This parameter is required for all the primitives.
5.2 Network Interface Type (i/f type)
The network interface type indicates the kind of technology of the
network interface (e.g., IEEE802.11a/b/g, 3GPP, etc.). This
parameter is required for all the primitives.
5.3 Network Interface Type Options (i/f type options)
The interface type options indicate the optional technologies
configured for the network interface. (e.g., IEEE802.1x, WPA,
IEEE802.11i, etc.)
5.4 Network Interface Data Rate (i/f rate)
The network interface data rate is the current configured rate of
data transfer. The value means maximum bandwidth of the network
interface.
Mitani, et al. Expires April 25, 2005 [Page 10]
Internet-Draft L2 Abstractions October 2004
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 (peer)
The peer consists of two sub-parameters: the attachment ID and the
network ID. The attachment ID uniquely identifies the Peer. The
network ID is used for specifying the set of Peers or configuration
of PPP connection.
6.2 Condition (condition)
The condition consists of the following sub-parameters: available
bandwidth, link quality level and noise level. These sub-parameters
are abstracted information for considering current quality-of
service. The abstraction algorithms of sub-parameters depend on
hardware device and software implementation. The useful range of
link quality level is from one(bad) to five(good). (TODO: Energy
cost and movement pattern need to be considered?)
6.3 Threshold (threshold)
The threshold consists of the sub-parameter: link quality level.
This parameter indicates the threshold value of link quality for
generating an event notification.
6.4 Peer List (peer-list)
The peer list consists of arbitrary couples of two sub-parameters:
peer and condition. This parameter indicates a list of peers and its
condition.
6.5 Security (security)
The security indicates the current configured security scheme.
6.6 Enable/Disable (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.
Mitani, et al. Expires April 25, 2005 [Page 11]
Internet-Draft L2 Abstractions October 2004
6.7 Ack/Error (ack/error)
When an upper layer requests some notifications, link layer receives
and confirms this "request". If the "request" is valid, the
"confirm" primitive with ack is sent. And if it is invalid, the
"confirm" with Error is sent to an upper layer.
Mitani, et al. Expires April 25, 2005 [Page 12]
Internet-Draft L2 Abstractions October 2004
7. Security Considerations
It is recommended that the implementers consider the security
features to manage the L2 information.
8 References
[1] Koodli, R., Dommety, G., Malki, K., Khalil, M., Perkins, C.,
Soliman, H., Tsirtsis, G. and A. Yegin, "Fast Handovers for
Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in
progress), October 2004.
[2] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
draft-ietf-mipshop-hmipv6-02 (work in progress), June 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
URI: http://www.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
URI: http://www.tera.ics.keio.ac.jp/
Mitani, et al. Expires April 25, 2005 [Page 13]
Internet-Draft L2 Abstractions October 2004
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
URI: http://www.tera.ics.keio.ac.jp/
Mitani, et al. Expires April 25, 2005 [Page 14]
Internet-Draft L2 Abstractions October 2004
Appendix A. Example Scenario
For example, the picture below shows L3-driven fast handover
mechanism using the L2 triggers on MN.
L2 L3
| |
Low |
Signal---LinkQualityChange.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-LinkQualityChange.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.
Mitani, et al. Expires April 25, 2005 [Page 15]
Internet-Draft L2 Abstractions October 2004
Appendix B. Example Operation for FMIPv6
Figure 3 shows the predictive mode of FMIPv6 operation with L3-driven
link switching mechanism.
MN L2 MN L3 PAR L3
| | |
AP<---------PeerList.req----------| |
Scan---------PeerList.cnf--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
|---------PeerFound.ind--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
| | |
~ ~ ~
| | |
Low | |
Signal---LinkQualityChange.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 3: L3-Driven Fast Handover Mechanism with FMIPv6
Mitani, et al. Expires April 25, 2005 [Page 16]
Internet-Draft L2 Abstractions October 2004
When the MN establishes link connectivity with the PAR, it performs
router discovery. Then, the MN can send RtSolPr message to the PAR
in order to resolve access point identifiers to subnet router
information. To 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 radio signal strength is going
down, it sends L2-LinkQualityChange.indication to the network layer.
Then, the MN sends FBU to PAR as the beginning of L3 handover
procedure. The NCoA required for FBU message is determined according
to the MN's policy database and received PrRtAdv message. As a
response to FBU, the MN receives FBack and then switches its link by
L2-LinkConnect.request with specific "peer" parameter immediately.
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 sends FNA message
to NAR immediately. The NAR will send tunneled and buffered packets
to the MN.
Mitani, et al. Expires April 25, 2005 [Page 17]
Internet-Draft L2 Abstractions October 2004
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 for L2-LinkStatus are related to the configuration
of network interface hardware. So, 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 current wireless environment.
There are three sub-parameters of the "condition" parameter:
available bandwidth, link quality level and noise level. An
available bandwidth of the current peer can be obtained by
maintaining transmission rate indication and statistics of frame
transmission at every time the frame transmission occurs. A link
quality level and a noise level can be updated by maintaining the
following parameters and statistics at every time the frame reception
occurs: receive signal strength indication (RSSI), transmission/
reception rate indication, transmit/receive latency, bit error rate,
frame error rate and noise level. 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 all detected APs as peer
candidates (by "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 network interface hardwares that can
notify events to operating system only when the desired event occurs,
by setting threshold from software. Moreover, the MN can transmit
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 are
detected by listening beacons or scanning APs. If the received frame
(mainly beacon or probe response) is not in the AP database described
in Appendix C.2, then the link layer can create
L2-PeerFound.indication.
Mitani, et al. Expires April 25, 2005 [Page 18]
Internet-Draft L2 Abstractions October 2004
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 signal strength of the received frame (mainly beacon
or probe response) is under threshold, then the link layer can create
L2-PeerLost.indication.
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
association response frame or reassociation response frame.
Immediately after receiving it, the link layer can create
L2-LinkUp.indication.
C.6 L2-LinkDown
In IEEE 802.11 networks, L2-LinkDown is notified when disassociation
event occurs. When such event occurs, the MN sends disassociation
frame to 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 can create L2-LinkDown.indication.
C.7 L2-LinkQualityChange
In IEEE 802.11 networks, L2-LinkQualityChange is notified when radio
signal strength of the connected AP is going down. By maintaining
parameters for a link quality level like the description in Appendix
C.1, the link layer can create L2-LinkQualityChange.indication.
C.8 L2-LinkConnect
In IEEE802.11 networks, each AP is identified by BSSID, the service
set of several APs is identified by SSID. When L2-LinkConnect is
used to connect specific AP or service set, the link layer should set
BSSID or SSID. Also, the channel should be set appropriately at the
same time by searching database described in Appendix C.2.
C.9 L2-LinkDisconnect
In IEEE802.11 networks, the MN sends disassociation message to the AP
for disconnection. When L2-LinkDisconnect is used for disconnection
from the current AP, the link layer should send disassociation
message to the appropriate AP, and stop data transmission.
Mitani, et al. Expires April 25, 2005 [Page 19]
Internet-Draft L2 Abstractions October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mitani, et al. Expires April 25, 2005 [Page 20]
IRTF MobOpts RG K. Mitani
Internet-Draft R. Shibui
Expires: April 25, 2005 F. Teraoka
KEIO University
October 25, 2004
Unified L2 Abstractions for L3-Driven Fast Handover
draft-koki-mobopts-l2-abstractions-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 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 as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
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
Mitani, et al. Expires April 25, 2005 [Page 1]
Internet-Draft L2 Abstractions October 2004
defines nine kinds of L2 abstractions in the form of "Primitive".
This concept can be applied to L3-driven fast handover mechanism
using "Primitives".
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Primitives for L2 Abstractions . . . . . . . . . . . . . . . . 6
4. Definitions of Primitives . . . . . . . . . . . . . . . . . . 7
4.1 L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . . 7
4.2 L2-PeerList (Type 1) . . . . . . . . . . . . . . . . . . . 7
4.3 L2-PeerFound (Type 2) . . . . . . . . . . . . . . . . . . 7
4.4 L2-PeerLost (Type 2) . . . . . . . . . . . . . . . . . . . 7
4.5 L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . . 8
4.6 L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . . 8
4.7 L2-LinkQualityChange (Type 2) . . . . . . . . . . . . . . 8
4.8 L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 8
4.9 L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . . 8
5. Definitions of Static Parameters . . . . . . . . . . . . . . . 9
5.1 Network Interface ID (i/f id) . . . . . . . . . . . . . . 9
5.2 Network Interface Type (i/f type) . . . . . . . . . . . . 9
5.3 Network Interface Type Options (i/f type options) . . . . 9
5.4 Network Interface Data Rate (i/f rate) . . . . . . . . . . 9
6. Definitions of Dynamic Parameters . . . . . . . . . . . . . . 10
6.1 Peer (peer) . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Condition (condition) . . . . . . . . . . . . . . . . . . 10
6.3 Threshold (threshold) . . . . . . . . . . . . . . . . . . 10
6.4 Peer List (peer-list) . . . . . . . . . . . . . . . . . . 10
6.5 Security (security) . . . . . . . . . . . . . . . . . . . 10
6.6 Enable/Disable (enable/disable) . . . . . . . . . . . . . 10
6.7 Ack/Error (ack/error) . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
A. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 14
B. Example Operation for FMIPv6 . . . . . . . . . . . . . . . . . 15
Mitani, et al. Expires April 25, 2005 [Page 2]
Internet-Draft L2 Abstractions October 2004
C. Example Mapping of Primitives and IEEE802.11 . . . . . . . . . 17
C.1 L2-LinkStatus . . . . . . . . . . . . . . . . . . . . . . 17
C.2 L2-PeerList . . . . . . . . . . . . . . . . . . . . . . . 17
C.3 L2-PeerFound . . . . . . . . . . . . . . . . . . . . . . . 17
C.4 L2-PeerLost . . . . . . . . . . . . . . . . . . . . . . . 18
C.5 L2-LinkUp . . . . . . . . . . . . . . . . . . . . . . . . 18
C.6 L2-LinkDown . . . . . . . . . . . . . . . . . . . . . . . 18
C.7 L2-LinkQualityChange . . . . . . . . . . . . . . . . . . . 18
C.8 L2-LinkConnect . . . . . . . . . . . . . . . . . . . . . . 18
C.9 L2-LinkDisconnect . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Mitani, et al. Expires April 25, 2005 [Page 3]
Internet-Draft L2 Abstractions October 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 nine kinds
of L2 triggers in the form of "Primitive". This concept can be
applied to L3-driven fast handover mechanism using "Primitives".
Mitani, et al. Expires April 25, 2005 [Page 4]
Internet-Draft L2 Abstractions October 2004
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.
Mitani, et al. Expires April 25, 2005 [Page 5]
Internet-Draft L2 Abstractions October 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 acknowledgment of the request. The indication is a
notification of information to the layer that requested the service,
and the response is the acknowledgment of the indication. In this
architecture, each layer can communicate evenly.
------------------------------------------------------
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
informaiton. 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.
Type 3. To control L2 actions from upper layers
Mitani, et al. Expires April 25, 2005 [Page 6]
Internet-Draft L2 Abstractions October 2004
A "request" primitive is a request for operation. Ack or
nack returns immediately as a "confirm" primitive.
Mitani, et al. Expires April 25, 2005 [Page 7]
Internet-Draft L2 Abstractions October 2004
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.
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.
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
"threshold" parameter, "condition" parameter and 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 "threshold" and the
"enable/disable". The "threshold" parameter prevents unnecessary
detection of peers (e.g., in case the quality level 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.
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 "threshold" parameter, "condition"
Mitani, et al. Expires April 25, 2005 [Page 8]
Internet-Draft L2 Abstractions October 2004
parameter and 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.
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.
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.
4.7 L2-LinkQualityChange (Type 2)
The L2-LinkQualityChange.indication is asynchronously provided to an
upper layer when an existing link is to be disconnected. This
notification contains three special parameters: the "condition", the
"threshold" and the "peer". The "condition" shows the current link
status. The "threshold" is the link quality level for a decision of
notification. The "peer" is the attachment point at which the link
quality is degrading. In the registration processing, the
L2-LinkQualityChange.request carries not only the "enable/disable"
parameter but the "threshold" parameter to specify the threshold of
notification.
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".
Mitani, et al. Expires April 25, 2005 [Page 9]
Internet-Draft L2 Abstractions October 2004
5. Definitions of Static Parameters
This section lists static parameters. Once the values of static
parameters are configured, they do not change frequently during
communication. The following parameters are transferred as a part of
primitives.
5.1 Network Interface ID (i/f id)
The network interface ID identifies uniquely the network interface in
a node. The identifier is an implementation-specific consideration
(e.g., name, index or unique address assigned to each interface).
This parameter is required for all the primitives.
5.2 Network Interface Type (i/f type)
The network interface type indicates the kind of technology of the
network interface (e.g., IEEE802.11a/b/g, 3GPP, etc.). This
parameter is required for all the primitives.
5.3 Network Interface Type Options (i/f type options)
The interface type options indicate the optional technologies
configured for the network interface. (e.g., IEEE802.1x, WPA,
IEEE802.11i, etc.)
5.4 Network Interface Data Rate (i/f rate)
The network interface data rate is the current configured rate of
data transfer. The value means maximum bandwidth of the network
interface.
Mitani, et al. Expires April 25, 2005 [Page 10]
Internet-Draft L2 Abstractions October 2004
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 (peer)
The peer consists of two sub-parameters: the attachment ID and the
network ID. The attachment ID uniquely identifies the Peer. The
network ID is used for specifying the set of Peers or configuration
of PPP connection.
6.2 Condition (condition)
The condition consists of the following sub-parameters: available
bandwidth, link quality level and noise level. These sub-parameters
are abstracted information for considering current quality-of
service. The abstraction algorithms of sub-parameters depend on
hardware device and software implementation. The useful range of
link quality level is from one(bad) to five(good). (TODO: Energy
cost and movement pattern need to be considered?)
6.3 Threshold (threshold)
The threshold consists of the sub-parameter: link quality level.
This parameter indicates the threshold value of link quality for
generating an event notification.
6.4 Peer List (peer-list)
The peer list consists of arbitrary couples of two sub-parameters:
peer and condition. This parameter indicates a list of peers and its
condition.
6.5 Security (security)
The security indicates the current configured security scheme.
6.6 Enable/Disable (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.
Mitani, et al. Expires April 25, 2005 [Page 11]
Internet-Draft L2 Abstractions October 2004
6.7 Ack/Error (ack/error)
When an upper layer requests some notifications, link layer receives
and confirms this "request". If the "request" is valid, the
"confirm" primitive with ack is sent. And if it is invalid, the
"confirm" with Error is sent to an upper layer.
Mitani, et al. Expires April 25, 2005 [Page 12]
Internet-Draft L2 Abstractions October 2004
7. Security Considerations
It is recommended that the implementers consider the security
features to manage the L2 information.
8 References
[1] Koodli, R., Dommety, G., Malki, K., Khalil, M., Perkins, C.,
Soliman, H., Tsirtsis, G. and A. Yegin, "Fast Handovers for
Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in
progress), October 2004.
[2] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
draft-ietf-mipshop-hmipv6-02 (work in progress), June 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
URI: http://www.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
URI: http://www.tera.ics.keio.ac.jp/
Mitani, et al. Expires April 25, 2005 [Page 13]
Internet-Draft L2 Abstractions October 2004
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
URI: http://www.tera.ics.keio.ac.jp/
Mitani, et al. Expires April 25, 2005 [Page 14]
Internet-Draft L2 Abstractions October 2004
Appendix A. Example Scenario
For example, the picture below shows L3-driven fast handover
mechanism using the L2 triggers on MN.
L2 L3
| |
Low |
Signal---LinkQualityChange.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-LinkQualityChange.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.
Mitani, et al. Expires April 25, 2005 [Page 15]
Internet-Draft L2 Abstractions October 2004
Appendix B. Example Operation for FMIPv6
Figure 3 shows the predictive mode of FMIPv6 operation with L3-driven
link switching mechanism.
MN L2 MN L3 PAR L3
| | |
AP<---------PeerList.req----------| |
Scan---------PeerList.cnf--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
|---------PeerFound.ind--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
| | |
~ ~ ~
| | |
Low | |
Signal---LinkQualityChange.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 3: L3-Driven Fast Handover Mechanism with FMIPv6
Mitani, et al. Expires April 25, 2005 [Page 16]
Internet-Draft L2 Abstractions October 2004
When the MN establishes link connectivity with the PAR, it performs
router discovery. Then, the MN can send RtSolPr message to the PAR
in order to resolve access point identifiers to subnet router
information. To 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 radio signal strength is going
down, it sends L2-LinkQualityChange.indication to the network layer.
Then, the MN sends FBU to PAR as the beginning of L3 handover
procedure. The NCoA required for FBU message is determined according
to the MN's policy database and received PrRtAdv message. As a
response to FBU, the MN receives FBack and then switches its link by
L2-LinkConnect.request with specific "peer" parameter immediately.
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 sends FNA message
to NAR immediately. The NAR will send tunneled and buffered packets
to the MN.
Mitani, et al. Expires April 25, 2005 [Page 17]
Internet-Draft L2 Abstractions October 2004
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 for L2-LinkStatus are related to the configuration
of network interface hardware. So, 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 current wireless environment.
There are three sub-parameters of the "condition" parameter:
available bandwidth, link quality level and noise level. An
available bandwidth of the current peer can be obtained by
maintaining transmission rate indication and statistics of frame
transmission at every time the frame transmission occurs. A link
quality level and a noise level can be updated by maintaining the
following parameters and statistics at every time the frame reception
occurs: receive signal strength indication (RSSI), transmission/
reception rate indication, transmit/receive latency, bit error rate,
frame error rate and noise level. 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 all detected APs as peer
candidates (by "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 network interface hardwares that can
notify events to operating system only when the desired event occurs,
by setting threshold from software. Moreover, the MN can transmit
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 are
detected by listening beacons or scanning APs. If the received frame
(mainly beacon or probe response) is not in the AP database described
in Appendix C.2, then the link layer can create
L2-PeerFound.indication.
Mitani, et al. Expires April 25, 2005 [Page 18]
Internet-Draft L2 Abstractions October 2004
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 signal strength of the received frame (mainly beacon
or probe response) is under threshold, then the link layer can create
L2-PeerLost.indication.
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
association response frame or reassociation response frame.
Immediately after receiving it, the link layer can create
L2-LinkUp.indication.
C.6 L2-LinkDown
In IEEE 802.11 networks, L2-LinkDown is notified when disassociation
event occurs. When such event occurs, the MN sends disassociation
frame to 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 can create L2-LinkDown.indication.
C.7 L2-LinkQualityChange
In IEEE 802.11 networks, L2-LinkQualityChange is notified when radio
signal strength of the connected AP is going down. By maintaining
parameters for a link quality level like the description in Appendix
C.1, the link layer can create L2-LinkQualityChange.indication.
C.8 L2-LinkConnect
In IEEE802.11 networks, each AP is identified by BSSID, the service
set of several APs is identified by SSID. When L2-LinkConnect is
used to connect specific AP or service set, the link layer should set
BSSID or SSID. Also, the channel should be set appropriately at the
same time by searching database described in Appendix C.2.
C.9 L2-LinkDisconnect
In IEEE802.11 networks, the MN sends disassociation message to the AP
for disconnection. When L2-LinkDisconnect is used for disconnection
from the current AP, the link layer should send disassociation
message to the appropriate AP, and stop data transmission.
Mitani, et al. Expires April 25, 2005 [Page 19]
Internet-Draft L2 Abstractions October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mitani, et al. Expires April 25, 2005 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-21 19:29:40 |