Internet DRAFT - draft-han-mopopts-uldriven
draft-han-mopopts-uldriven
IRTF MOBOPTS Research Group Younhee Han
Internet Draft Xiaoyu Liu
Document: draft-han-mopopts-uldriven-00.txt Heejin Jang
Expires: January 9, 2005 Samsung AIT
July 11, 2004
Upper Layer-driven Link Layer Action
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 3667.
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 January 5, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes scenarios where upper layer-driven link layer
actions are necessary. A set of primitives is proposed for these
interactions between the upper layers and the link layer.
Han, et al. Expires December 30, 2004 [Page 1]
Upper Layer-driven Link Layer Action July 2004
Table of Contents
1. Introduction...................................................3
2. Scenario.......................................................3
2.1 Notifying Exact Time of Link Switch (in FMIPv6)............3
2.2 Optimal Selection of Radio Link............................4
3. Interaction Semantics..........................................5
3.1 Link_Poll_Request..........................................5
3.2 Link_Poll_Response.........................................5
3.3 Link_Switch_Request........................................6
3.4 Link_Down_Request..........................................6
3.5 Link_Up_Request............................................6
3.6 Link_Switch_Response/Link_Down_Response/Link_Up_Response...6
4. Security Considerations........................................7
References........................................................7
Author's Address..................................................7
Intellectual Property Statement...................................8
Disclaimer of Validity............................................9
Copyright Statement...............................................9
Acknowledgment....................................................9
Han, et al. Expires December 30, 2004 [Page 2]
Upper Layer-driven Link Layer Action July 2004
1. Introduction
Protocol layering is a common technique to simplify networking design
by dividing it into functional layers, and assigning protocols to
perform each layer's stack. Protocol layering produces simple
protocols, each with a few well-defined tasks. These protocols can
then be assembled into a useful whole. However, keeping the strict
layering all the time may result in inefficient implementation of a
protocol suite.
In IEEE and IETF, various proposals have been made for utilizing
link-layer indication to optimize configuration of Internet layer and
have an effect on Transport or Application layer. Particularly, it
becomes popular to utilize link-layer indication to expedite Internet
layer handover. For example, [1] defines the generic triggers,
including "Link Up", "Link Down", "Link Going Down", "Link Going Up",
"Link Quality Crosses Threshold", "Trigger Rollback", and "Better
Signal Quality AP Available". [2] provides a catalogue of existing
"Link Up" and "Link Down" triggers from well-known link-layer
technologies, such as GPRS, 3GPP2, and WLAN.
From upper layer perspective, link-layer indication is "advisory." It
is expected upper layer protocols register a kind of callback
function into link-layer, and passively just hear events come from
link layer. In some cases, however, it is necessary for upper layer
to actively request link layer to take an action, such as disconnect
from or connect to a radio link.
This document describes scenarios where upper layer-driven link layer
actions are necessary. A set of primitives is proposed for these
interactions between the upper layers and the link layer. The
precedent work of this document is one of our contributions to IEEE
802.21 [3].
2. Scenario
2.1 Notifying Exact Time of Link Switch (in FMIPv6)
FMIPv6 (Fast Handover for Mobile IPv6) [4] describes a protocol to
replace MIPv6 (Mobile IPv6) [5] movement detection algorithm and new
CoA configuration procedure. It also specifies a bi-directional
tunnel establishment typically between previous CoA and new CoA so
that the MN can continue to receive or send packets while it
completes the binding update to HA and CNs on the new subnet. If
possible, this tunnel establishment and the commencement of packet
tunneling should be done before MN attaches to new link. Otherwise,
they should be achieved immediately after MN attaches to new link.
Han, et al. Expires December 30, 2004 [Page 3]
Upper Layer-driven Link Layer Action July 2004
According to FMIPv6 specification, the scenario in which an MN
receives an acknowledgement of the fast binding update in the current
link is called 'predictive' mode of operation. The scenario in which
an MN does not receive such acknowledgement in the current link is
called 'reactive' mode of operation. In the latter case, MN cannot
ascertain whether the fast binding update has been successfully
processed. Hence, MN should (re)send the fast binding update, which
is encapsulated in fast neighbor advertisement message, as soon as it
attaches to new attachment point. This procedure will cause wireless
resources to be more used and an additional processing at new access
router is required to check whether or not the new CoA is already
confirmed (or whether or not the new CoA is already used by other
node). This fact implies that the 'predictive' mode is more effective
than 'reactive' mode, and it is highly recommended that MN should
receive the acknowledgement in the current link. Current FMIPv6
specifies MN should send FBU_RETRIES fast binding updates in case
that it does not receive the acknowledgement still when attaching to
the current link.
It is noted that the acknowledgement received by MN in the current
link indicates that packet tunneling would already commence. Hence,
MN SHOULD switch its connectivity into the new attachment point
immediately after receiving the acknowledgement. Otherwise, there is
no way for MN to receive the tunneled packets unless the previous
access router (the sender of tunneled packet) also begins to copy the
incoming packets and forward them to previous CoA on its link. But,
such transmission of two packet copies can impose much load on both
wired and wireless network.
If the signal strength with current attachment point becomes weaker
than a predefined value of signal strength, MN SHOULD switch its
connectivity into the new attachment point without concerns about
receiving acknowledgement.
After sending the fast binding update, if MN could still communicate
without the abrupt deterioration of signal strength, the optimal way
to achieve seamless handover without much packet loss would be to
command layer 2 to fast switch into the new attachment point as soon
as the packet tunneling begin. The time when Layer 3 receives the
acknowledgement is the most adequate. This scenario gives us another
example to describe a link layer activity triggered from Layer 3.
2.2 Optimal Selection of Radio Link
As more and more wireless networks are deployed and overlapped,
mobile hosts nowadays are equipped with multiple network interfaces.
Network technologies differ in terms of bandwidth, delay, capacity,
coverage and potentially their charging methods. As a result, how to
select the optimal network becomes an interesting problem. Moreover,
Han, et al. Expires December 30, 2004 [Page 4]
Upper Layer-driven Link Layer Action July 2004
it is a more challenging task to seamlessly handover between these
networks.
In a heterogeneous network environment, vertical handover may be
triggered by lower layer events, e.g. the degradation of signal
strength or link-down. On the other hand, upper layers should also be
able to initiate vertical handover even when multiple radio links are
available. Upper layer entity, either in the mobile host or in
network side, determines the 'best' wireless interface and makes
handoff decision.
In this scenario, upper layer entity should monitor the dynamic
changes of different links, either currently connected or potentially
available. A polling message is issued by upper layers to MAC layer
of different types of links, periodically or event-triggered. The
status information of the link is reported to upper layers.
The vertical handoff decision may be based on a set of policies or
user preferences. After the handoff decision is made, the upper layer
issues commands to force a given interface to take an action, such as
connect or disconnect from a link.
3. Interaction Semantics
The semantics of upper layer-driven link layer activity must be
generally defined so that many link layer technologies can easily
accept it. The mapping of these semantics to a set of specific layers
is implementation specific and out of scope.
3.1 Link_Poll_Request
This is issued by upper layer entities to discover the status of the
currently connected and potentially available links. The source of
this can be local or remote one. Parameters are defined as follows:
- Link type: 802.11/802.15/802.16e/GPRS/GSM/UMTS, etc
- Link layer identifier of polled interface
- Link layer identifier of polling network entity (in case of remote
type)
- Others (to be defined later)
3.2 Link_Poll_Response
This is corresponding to Link_Poll_Request to report link status to
Upper Layer Entities. The source of this is the recipient of
Link_Poll_Request, hence can be local or remote one. Parameters are
defined as follows:
Han, et al. Expires December 30, 2004 [Page 5]
Upper Layer-driven Link Layer Action July 2004
- Link type: 802.11/802.15/802.16e/GPRS/GSM/UMTS, etc
- Link layer identifier of polled interface
- Link attributes: link quality, QoS parameters, security, attachment
point address, etc.
- Others (to be defined later)
3.3 Link_Switch_Request
This is issued by upper layer entities to force a given interface to
switch from one link to another. The source of this can be local or
remote one. Parameters are defined as follows:
- New link type
- Link layer identifier of interface
- Link layer identifier of new attachment point
- Reason codes: service price/QoS/user preferences, etc
- Others (to be defined later)
3.4 Link_Down_Request
This is issued by upper layer entities to force a given interface to
be inactive. So, the corresponding interface cannot be used to send
packets. The source of this can be local or remote one. Parameters
are defined as follows:
- Link layer identifier of interface
- Reason codes: service price/QoS/user preferences, etc
- Others (to be defined later)
3.5 Link_Up_Request
This is issued by upper layer entities to force a given interface to
be active. So, upper layers use the corresponding interface to send
packets. The source of this can be local or remote one. Parameters
are defined as follows:
- Link layer identifier of interface
- Reason codes: service price/QoS/user preferences, etc
- Others (to be defined later)
3.6 Link_Switch_Response/Link_Down_Response/Link_Up_Response
These are issued by a link layer to report the result of
Link_Switch_Request/Link_Down_Request/Link_Up_Request, respectively.
The sources of these are the recipients of each corresponding request,
hence can be local or remote one. Parameters are defined as follows:
- Result codes: success/failure
- Others (to be defined later)
Han, et al. Expires December 30, 2004 [Page 6]
Upper Layer-driven Link Layer Action July 2004
4. Security Considerations
Secure interactions between the upper layers and the link layer MUST
be ensured, since upper layer-driven link layer activity is typically
insecure. A spoofed or modified upper layer request can still be used
to launch the potential denial of service attacks on the host and the
associated network. This is especially important in cases where
insecure interactions are used as a substitute for the existing
secure mechanisms.
Source of interaction initiator may be not authenticated or
authorized in case of local interaction mechanism. However, the
authentication and authorization MUST be always required when the
source is remote one.
References
[1] Gupta, V. and D. Johnston, "A Generalized Model for Link Layer
Triggers", submission to IEEE 802.21 (work in progress), March
2004, available at:
http://www.ieee802.org/handoff/march04_meeting_docs/Generalized_t
riggers-02.pdf.
[2] Yegin, A., "Link-layer Hints for Detecting Network Attachments",
draft-yegin-dna-l2-hints-01 (work in progress), February 2004.
[3] Liu, X. and Han, Y., "Interaction between Layer 2 and Upper
Layers in IEEE 802.21", submission to IEEE 802.21 (work in
progress), March 2004, available at:
http://www.ieee802.org/handoff/march04_meeting_docs/802.21_L2_upp
er_layer_interaction_r1.ppt
[4] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop
-fast-mipv6-01 (work in progress), February 2004.
[5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-24 (work in progress), July 2003.
Author's Addresses
Younhee Han
SAMSUNG Advanced Institute of Technology
i-Networking Laboratory
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
Han, et al. Expires December 30, 2004 [Page 7]
Upper Layer-driven Link Layer Action July 2004
KOREA
Phone: +82 31 280 9585
EMail: yh21.han@samsung.com
Xiaoyu Liu
SAMSUNG Advanced Institute of Technology
i-Networking Laboratory
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9233
EMail: heejin.jang@samsung.com
Heejin Jang
SAMSUNG Advanced Institute of Technology
i-Networking Laboratory
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9233
EMail: heejin.jang@samsung.com
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 IETF's procedures with respect to rights in IETF 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
Han, et al. Expires December 30, 2004 [Page 8]
Upper Layer-driven Link Layer Action July 2004
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
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.
Han, et al. Expires December 30, 2004 [Page 9]
