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]