Internet Draft Carl E. Williams Document: draft-williams-l2-probstmt-00.txt Alper E. Yegin Expires: December 2002 James Kempf DoCoMo USA Labs Problem Statement for Link-layer Triggers work Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This is an individual draft for consideration by the PILC Working Group. 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. Abstract Much discussion has resulted over the last few years regarding L2 triggers in wired and wireless scenarios. Recent wireless goals have been to collect requirements from various IETF related working groups for L2 triggers in wireless environments. For example, the Mobile IP and SeaMoby working groups require such L2 information to optimize handoff. It was the hope that the output of such an effort would be used to design an API or protocol if desired. A requirements draft [REQ] discusses requirements from the following FMIPv6, low latency MIPv4, and SeaMoby context transfer work. Discussion over the last several months in the PILC working group raises concerns about a generic L2 trigger framework independent if the it is for wired-line or wireless application. The goal of this document is to provide a clear problem statement of L2 triggers. Discussion has also been documented in this problem statement regarding special needs of the wireless application. For example, the method for communicating L2 information to L3 may be better suited for the wire-lined case (e.g., MIB) but not for the wireless scenario. Finally, recommendations on where to go with the L2 trigger area in IETF has been provided. This draft is preliminary. Williams, Yegin, Kempf Expires December 2002 [Page 2] L2 Triggers prob stmt June 2002 Table of Contents 1.0 Introduction.................................................2 2.0 Terminology..................................................2 3.0 L2 triggers and architectural principals.....................4 4.0 Delivery of L2 Triggers......................................5 5.0 Guidance to L2 protocol Designers............................5 6.0 Security Considerations......................................6 7.0 References...................................................6 8.0 AuthorÆs Addresses...........................................6 1.0 Introduction The need for communication about L2 state to L3 is not new. Routers have been handling it, largely with proprietary means for years. Routers are in fact the canonical customers for this function; they by definition perform their principal L3 function based on L2 state information. Routing folks have learned a lot about how links lie about their state (e.g., links that fails half-duplex). In fact, router manufacturers may have insight as to which metrics would be of interest or possible how to extend or abstract them if they are willing to share the information. The most common need expressed in various IETF discussions is for a link up/down indicator. This might be extended to be a table containing reachability to multiple access points for technologies where that is possible. 1.1 Interaction with mobility handover of a host Wireless and mobile hosts are subject to changing their point of attachment from one access network to another. This process is called a handover. Handovers involve a change in link-layer connectivity, and sometimes in network-layer connectivity as well. A host has to identify a new attachment point, disassociate from the current link, and associate with a new link. After this process, depending on whether the new link is still part of the same network subnet as the previous link, host may also need to take actions to re-establish network-layer connectivity. Link-layer of a host and the access node on the access network has knowledge and control on the link-layer events. These events may include anticipation and execution of a host associating/ disassociating with the link. While information on these events is already available to the link-layer of involved parties, they are transparent to the network-layers. [REQ] identifies scenarios where availability of this information at the network-layer is required for re-establishing network-layer connectivity. Williams, Yegin, Kempf Expires December 2002 [Page 3] L2 Triggers prob stmt June 2002 In mobileIP on a wireless link, an L3 handover may, but does not always, occur when the mobile node moves to a new access point. Link layer protocols provide more accurate, and possibly timelier, reachability information than L3 'hello' protocols. There is great benefit if a mobileIP L3 can learn that a handover is imminent, rather than waiting until after the old link is gone. Early warning may allow mobileIP to optimize the L3 hand-off process in a number of ways, such as triggering an L3 early hand-off or moving context to the new router. Indeed, certain IETF protocols already exist and rely on this information to function [FMIPV4] [FMIPV6] and others perform better when this information is available [MIPV4] [MIPV6]. Link-layer events are communicated to the network-layer in the form of link-layer (L2) trigger. [REQ] identifies the type of information that needs to be carried in L2 triggers. This draft will discuss the problem space for L2 triggers. This includes architectural principles and some comments on issues regarding the amount of information to reveal from L2 to L3. Other discussion will entail on how the L2 information is delivered and what some next steps for IETF is in terms of L2 triggers work. 2.0 Terminology The following terms are used in this document. L2 Trigger An L2 trigger is an abstraction of a notification from L2 (potentially including parameter information) that a certain event has happened or is about to happen. An L2 trigger is not associated with any specific L2 but rather is abstracted from the kind of L2 information that is or could be available from a wide variety of radio link protocols. L2 Handover Change of MN's link layer connection from one AP to another. No change in off-subnet routing reachability information is required. L3 Handover Change of MN's routable address from one AR to another. An L3 handover results in a change in the MN's routing reachability, that will require action on the part of the IP mobility protocol running in the MN and/or ARs. Williams, Yegin, Kempf Expires December 2002 [Page 4] L2 Triggers prob stmt June 2002 3.0 L2 triggers and architectural principals Emerging communication technologies and standards are being developed and adopted instantaneously. The separation between the layers made it possible for technologies within each layer to advance at their own pace, independent of the other layers. The separation of domains made it possible to apply rules to the technologies within the domain, independent of other domains. Creating intelligent networks requires bridging the gap between layers, which, in turn, calls for new architectures and technologies. The question with L2 triggers becomes the value of to reveal *any* information that might be of interest to any part of the host, e.g., bit error rate, or link bandwidth. For example, a video codec (e.g., MPEG-4) might behave differently if it was aware of the bit error rate of the wireless link. This suggests an architecture which is not general - leading to applications that are too tightly bound to specific link types or depend on the assumption that the 'difficult' link is the one nearest the end host. The Internet layer, as the 'waist in the protocol hourglass' insulates the application from the link layer. The question of what information ought to be passed up from L3 is separate from what info L3 could usefully get from L2, and should be considered separately. Only a very limited, general set of parameters would be appropriate above L3 and defining appropriate parameters based on link characteristics is a very difficult task. Even adding a metric such as signal strength is difficult when link technologies are heterogeneous. There's value in finding implicit rather than explicit mechanisms. Again the focus should be firmly on L2/L3 communication, rather than enabling applications (or, presumably, transport) to interact directly with L2. While L2 triggers are likely to color how the L3 protocol is implemented on top of that L2, they should not influence the specification of the abstract L2 triggers themselves. Williams, Yegin, Kempf Expires December 2002 [Page 5] L2 Triggers prob stmt June 2002 4.0 Delivery of L2 Triggers In an IETF pre-BOF discussion at the IETF-54 meeting on L2 triggers the thinking was that the difficult task that needs to be done is to determine the right set of metrics to abstract and capture them in a common location. It was widely recognized that the question of the delivery mechanism is really secondary to the question of what information should be passed between L2 and L3. However, within the wireless and mobility area the delivery of L2 triggers is critical to key protocols dealing with the performance of mobility handover. Thus, proposals such as to standardize these metrics in the form of a MIB are unacceptable. Indeed, the requirement for these mobility enhancements is that the delivery mechanism be instant and have no overhead. It is not required that the delivery mechanism be standardized via some API. Events such as link-down and link-up are used to indicate when certain protocol events should take place. This is used in the context of Mobile IP and fast handovers for Mobile IP. These protocols rely on the existence of such indications from lower layers. When L2 and L3 are located on the same node, these triggers can be communicated locally. But in the case where they are separated (such as Access Points and Access Routers in WLAN are separated) a protocol is needed to convey the triggers from one end to other. 5.0 Where to go from here: Guidance to L2 protocol Designers Protocols such as [FMIPv6] rely on L2 triggers, even though the draft specification doesnÆt call this out explicitly. The proposal is to Have the editors of these drafts such as FMIPv6 will describe how to implement the particular protocol on a particular link layer. Such an L2 triggers draft would provide the abstract framework for reference in these link layer specific drafts. Since the requirement for these drafts has been recognized as large, and because the MANET working group also are interested in review, the Wireless Technical Directorate has recommended submitting as an individual informational draft, but first putting it through Last Call in both working groups to obtain Proper review. The focus is initially on the specification on how various mobility related protocols will specify the triggers. It is hoped that these abstractions can be specified in a more general sense at some later point. These documents should at some point become information RFCs within the appropriate working group. Discussion on providing a generic abstract for L2 triggers (e.g., Link Up/Link Down) will continue to be discussed in the PILC working group alias. Williams, Yegin, Kempf Expires December 2002 [Page 6] L2 Triggers prob stmt June 2002 6.0 Security Considerations L2 triggers are used in making routing decisions as stated in [REQ]. As such, their misuse can lead to undesirable side effects and therefore must be prohibited. 7.0 References [REQ] J. Kempf, et. al. Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems (work in Progress). draft-manyfolks-l2-mobilereq-02.txt, June 2002. [MIPV4] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [MIPV6] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6 (work in progress). draft-ietf-mobileip-ipv6-17.txt, May 2002. [FMIPV4] K. El-Malki, et. al., Low Latency Handoff in Mobile IPv4 draft-ietf-mobileip-lowlatencyhandoffs-v4-01.txt. [FMIPV6] G. Dommety, et. al. Fast Handovers for Mobile IPv6 (work in progress). draft-ietf-mobileip-fast-mipv6-04.txt, March 2002. [AUTH] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [ENCR] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). Request for Comments (Proposed Standard) 2406, Internet Engineering Task Force, November 1998. 8.0 Author's Addresses Carl E. Williams DoCoMo Communications Laboratories USA, Inc. 181 Metro Drive, Suite 300 Phone: +1 408 451 4741 San Jose, CA 95110 Fax: +1 408 451 1090 USA email: carlw@docomolabs-usa.com Alper E. Yegin DoCoMo Communications Laboratories USA, Inc. 181 Metro Drive, Suite 300 Phone: +1 408 451 4743 San Jose, CA 95110 Fax: +1 408 451 1090 USA email: alper@docomolabs-usa.com James Kempf DoCoMo Communications Laboratories USA, Inc. 181 Metro Drive, Suite 300 Phone: +1 408 451 4711 San Jose, CA 95110 Fax: +1 408 451 1090 USA email: kempf@docomolabs-usa.com Williams, Yegin, Kempf Expires December 2002