[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
   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-

   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
   The list of Internet-Draft Shadow Directories can be accessed at


   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

   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

    L2 Handover

         Change of MN's link layer connection from one AP to another.
         No change in off-subnet routing reachability information is

    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

   [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