Internet Draft                                        Alper E. Yegin
   Document: draft-yegin-l2-triggers-00.txt             DoCoMo USA Labs
   Expires: December 2002                                     June 2002




                       Link-layer Triggers Protocol


                            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

   Wireless and mobile hosts are subject to changing their point of
   attachment from one access network to another. These changes result
   in link-layer events such as link up and link down. Information on
   these events can be conveyed to interested parties in the form of
   link-layer triggers. Primary consumers of this information are the
   modules implementing mobility related network-layer protocols. When
   provider and consumer of this information are co-located on the same
   IP node, required communication can take place via internal
   mechanisms. But when they are separate, as in the case of networks
   using wired-to-wireless bridges, a transport mechanism is needed to
   convey link-layer triggers. This draft defines a UDP based client-
   server protocol for transporting link-layer triggers between two IP
   nodes.







   Yegin                Expires December 2002
   [Page 2]                  L2 Triggers                    June 2002

   Table of Contents

   1.0  Introduction.................................................2
   2.0  Protocol Overview............................................4
   3.0  Protocol Details.............................................5
      3.1. Hello Message.............................................6
      3.2. Registration Message......................................6
      3.3. Trigger Message...........................................7
      3.4. Query Message.............................................9
   4.0  Security Considerations.....................................10
   5.0  IPR Statement...............................................10
   6.0  Acknowledgements............................................11
   7.0  References..................................................11
   8.0  Author's Addresses..........................................11
   9.0  Full Copyright Statement....................................12


1.0  Introduction

   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. Certain protocols
   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.

   Link-layer and network-layer of a host are co-located on the same IP
   node in a standard network stack implementation. Therefore L2 events
   take place on the same node and network-layer can be notified via
   internal mechanisms. A simple interface between two modules running
   on the same IP node should be sufficient.





   Yegin                Expires December 2002
   [Page 3]                  L2 Triggers                    June 2002



                           ~~~~~~~~~~~~~~~~~~
                        \|/     wireless     \|/
                         |        link        |
   +------+  wired  +----+---+            +---+----+  wired  +--------+
   |      |  link   | access |            | access |  link   |        |
   | host +---------+ device |            | point  +---------+ access |
   |      |         |(bridge)|            |(bridge)|         | router |
   +------+         +--------+            +--------+         +--------+

                Figure 1. Host connecting via wireless bridges


   A problem arises when wireless bridges are used in connecting hosts
   to networks. Figure 1 illustrates a host connecting to an access
   router via wireless bridges. Wireless bridges are connected to each
   other via a wireless link which is defined by its two end points. As
   an example, a laptop might be using a cell phone to associate with a
   wireless link. Similarly an access router might be using a base
   station to provide service over the wireless link. In this case,
   only the bridges can know when a host is associated/disassociated
   with the link. Neither the host nor the access router can use an
   internal method to get informed about the L2 events associated with
   the wireless link.  This is where a new transport is needed to
   convey L2 trigger information between two IP nodes (i.e., from
   bridges to the interested parties).

                           ~~~~~..    ..~~~~~
                        \|/                  \|/
             link        |                    |       link
   +------+  down   +----+---+            +---+----+  down   +--------+
   |      | <------ | access |            | access | ------> |        |
   | host +---------+ device |            | point  +---------+ access |
   |      |         |(bridge)|            |(bridge)|         | router |
   +------+         +--------+            +--------+         +--------+

         Figure 2. Link down triggers sent when host disassociates


   This new transport is defined as L2 triggers protocol in this draft.
   This is a UDP based client-server protocol to transport L2 event
   information from access devices/points to other IP nodes such as
   mobile hosts and access routers.











   Yegin                Expires December 2002
   [Page 4]                  L2 Triggers                    June 2002

2.0  Protocol Overview

   In this protocol, bridges are the servers that have firsthand
   knowledge on the L2 events, and hosts and routers using these
   bridges are the clients that are interested in these L2 events.
   Bridges must be capable of running IP and UDP in order to use this
   protocol.


                           ~~~~~~~~~~~~~~~~~~
                        \|/     wireless     \|/
                         |        link        |
   +------+  wired  +----+---+            +---+----+  wired  +--------+
   |      |  link   | access |            | access |  link   |        |
   | host +---------+ device |            | point  +---------+ access |
   |      |         |(bridge)|            |(bridge)|         | router |
   +------+         +--------+            +--------+         +--------+

    client <------->  server                 server <------->  client

           Figure 3. Clients and servers of L2 triggers protocol


   First thing is the identification of servers by the clients. This
   can happen either by manual configuration, or by dynamic discovery.
   Clients can discover servers on the same subnet by multicasting a
   Hello message to a well-known IP address. Servers must respond to
   this message by a unicast Hello message sent back. A client may
   periodically send these multicast Hello messages to keep track of
   active servers. It can also send a unicast Hello message to learn if
   a server is still alive. When a server starts, it must multicast a
   Hello message to announce its service. A client must not respond to
   this unsolicited Hello message.

   Once a client identifies a server to receive L2 triggers from, it
   must register with the server. Client must send a Registration
   message to the server and the server must send back a Registration
   Acknowledgement message. Each registration has a lifetime and must
   be renewed before expiration. After this point server will be
   notifying the client about the L2 events that take place on the
   server. Client can de-register from the server at any time by
   sending a Registration message with 0 lifetime, and the server must
   send back a Registration Acknowledgement message with 0 lifetime.

   When a L2 event takes place on the server, it must send a Trigger
   message to every one of the registered clients. Server may choose to
   combine more than one L2 trigger in a single message, which is
   subject to local policy. Server may also request an acknowledgement
   from the client, and client must send back a Trigger
   Acknowledgement. L2 triggers include Link Down, Link Up, Source Pre-
   trigger, Target Pre-trigger, and Mobile Pre-trigger as defined in
   [REQ]. Additionally server may send a Pre-trigger Cancel in the



   Yegin                Expires December 2002
   [Page 5]                  L2 Triggers                    June 2002

   Trigger message to indicate conditions leading to an earlier sent
   Pre-trigger has changed and that pre-trigger must be disregarded.

   In addition to getting notified of the L2 events, clients can query
   the server for the status of a specific link. A host can query its
   access device to learn if it is still associated to a specific
   access point. Similarly, an access router can query its access point
   to learn if a specific host is still associated with it. Clients
   send a Query Request message to the server, and server replies with
   a Query Response.


3.0  Protocol Details

   L2 triggers protocol is a UDP based client-server protocol. Both
   clients and servers join a well-known multicast group (TBD) and
   listen on a well-known port (TBD). Protocol format is as follows:

      IP fields:

         Source Address
           Typically the interface address from which the message is
           sent.

         Destination Address
           Typically the interface address to which the message is
           sent. TBD when the Hello message is multicasted.

         Time-to-live
           Always set to 255 when sent. The receiver must verify this
           value to limit use of this protocol to nodes on the same IP
           link.

      UDP fields:

         Source Port
           Variable, when not sent as a response. TBD when sent as a
           Response to an incoming message.

         Destination Port
           Copied from the incoming message's source port when sent as
           a response, TBD otherwise.

      The UDP header is followed by the protocol fields shown below:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |               Data ...                        ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




   Yegin                Expires December 2002
   [Page 6]                  L2 Triggers                    June 2002



        Type
          1 Hello
          2 Registration
          3 Trigger
          4 Query

        Data
          Data specific to a given Type.


3.1. Hello Message

   This message is used by clients to discover servers, and by servers
   to announce their availability.

   The UDP header is followed by the following protocol fields for a
   Hello message.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |C|  Reserved   |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Type
          1 Hello

        C
          Client bit. Set to 1 when Hello message is sent by a client,
          set to 0 otherwise.

        Reserved
          Reserved bits, sent as 0.


3.2. Registration Message

   Clients use this message for registering with the servers. Servers
   start delivering L2 triggers to registered clients. Same message is
   used for both Registration Request and Registration
   Acknowledgements.

   The UDP header is followed by the following protocol fields for a
   Registration message.







   Yegin                Expires December 2002
   [Page 7]                  L2 Triggers                    June 2002



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |R|  Reserved   |         Lifetime              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Type
          2 Registration

        R
          Request bit. Set to 1 when this is a Registration Request
          message, set to 0 when this is a Registration Acknowledgement
          message.


        Reserved
           Reserved bits, sent as 0.

        Lifetime
           The number of seconds remaining before the registration
           is considered expired.  This field is set to the requested
           lifetime value by the client, and granted lifetime value by
           the server. A value of zero indicates a request for
           deregistration.  A value of 0xffff indicates infinity.


3.3. Trigger Message

   This message is used by servers to deliver L2 event notifications to
   the clients.

   The UDP header is followed by the following protocol fields for a
   Trigger message.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |A|   Reserved  |       Identification          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Data ...                            ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Type
          3 Trigger

        A
          Acknowledge request bit. When set, the client must send back



   Yegin                Expires December 2002
   [Page 8]                  L2 Triggers                    June 2002

          an acknowledgement. Client sends back a Trigger message with
          A bit set to zero, Identification copied from the incoming
          Trigger message, and no data to acknowledge receipt of a
          Trigger message.

        Reserved
          Reserved bits, sent as 0.

        Identification
          A 16-bit number, constructed by the server, used for
          matching Trigger messages with Trigger Acknowledgement
          messages.

        Data
          L2 event specific data. Server can send information relating
          to one or more L2 events.

   Data field can contain a stream of L2 event related data. Each L2
   event data is carried in the following format:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Event Type  |  Data Length  |          Event Data ...       ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Event Type
          1 Link Up
          2 Link Down
          3 Source Pre-trigger
          4 Target Pre-trigger
          5 Mobile Pre-trigger

        Data Length
          Length of Event Data field in bytes.

        Event Data
          Event Data includes a single L2 address for Link Up, Link
          Down, and Mobile Trigger events. When a host receives a Link
          Up trigger, L2 address specified in the Event Data field
          indicates the link-layer address of the newly associated
          access point. Similarly, when an access router receives a
          Link Up trigger, L2 this address indicates the link-layer
          address of the newly associated access device.

          Event Data includes two L2 addresses for Source Trigger and
          Target Trigger messages. First one is the L2 address of an
          access point, and the second one is the L2 address of an
          access device. When an access router receives a Source
          Trigger, first L2 address indicates the anticipated



   Yegin                Expires December 2002
   [Page 9]                  L2 Triggers                    June 2002

          destination access point of an access device which is
          identified by the second L2 address. Similarly, when an
          access router receives a Target Trigger, first L2 address
          indicates the source access point of an anticipated access
          device which is identified by the second L2 address.

          Since Pre-triggers are based on anticipation but not actual
          events, they might need to be cancelled in case conditions
          leading to their anticipation change. In this case, servers
          send another Pre-trigger and set the L2 address field of
          access point to 0, and specify the access device in the
          second L2 address field. Client must be able to identify an
          earlier sent L2 trigger based on the L2 address of the access
          device and disregard the previous event. Similarly L2 address
          set to 0 indicates a Pre-trigger cancellation for Mobile
          Pre-triggers.

          A L2 address is specified in variable length field. The
          content and format of this field (including byte and bit
          ordering) is expected to be specified in specific documents
          that describe how IP operates over different link layers.

          Both access routers and hosts can receive Link Up, Link Down.
          Only hosts can receive Mobile Pre-trigger, and only access
          routers can receive Source Pre-trigger and Target
          Pre-trigger.


3.4. Query Message

   This message is used by clients for querying state of a given link.

   The UDP header is followed by the following protocol fields for a
   Query message.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |R|  Reserved   |A|  Reserved   | L2 Address .. ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Type
          4 Query

        R
          Request bit. Set to 1 when this is a Query Request message,
          Set to 0 when this is a Query Response message.

        Reserved
          Reserved bits, sent as 0.



   Yegin                Expires December 2002
   [Page 10]                 L2 Triggers                    June 2002



        A
          Association bit. Set to 0 when sent in a Query Request and
          ignored upon receipt. Set to 1 in a Query Response message if
          the queried L2 address is still associated, 0 otherwise.

        Reserved
          Reserved bits, sent as 0.

        L2 Address
          L2 address of the wireless link remote end-point queried by
          the sender of a Query Request message. If Query Request is
          sent by a host, this field contains L2 address of an access
          point. If Query Request is sent by an access router, this
          field contains L2 address of an access device. The Query
          Response must copy this field from the incoming Query
          Request, set the R bit to 1, and specify the A bit according
          to the link state.

          L2 address is specified in variable length field. The content
          and format of this field (including byte and bit ordering) is
          expected to be specified in specific documents that describe
          how IP operates over different link layers.


4.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.

   The time-to-live field of messages sent are set to 255 and verified
   by the receivers. Therefore nodes that are not on the same IP link
   cannot use this protocol. This method provides protection against
   unauthorized use of protocol by off-link nodes.

   Protection against unauthorized use by on-link nodes can be
   accomplished by using IPsec [AUTH] [ENCR]. Hello messages do not
   have to be secured. But Registration, Trigger, and Query messages
   can be secured by using IPsec. IPsec can provide both authentication
   and privacy when needed. Required security associations among
   clients and servers need to be established in advance.


5.0  IPR Statement

   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.




   Yegin                Expires December 2002
   [Page 11]                 L2 Triggers                    June 2002



6.0  Acknowledgements

   Author of this draft would like to thank Carl Williams, Daichi
   Funato, and Youngjune Gwon for their valuable comments and
   discussions.


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
            (work in progress).
            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

   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








   Yegin                Expires December 2002
   [Page 12]                 L2 Triggers                    June 2002

9.0  Full Copyright Statement

   Copyright (C) The Internet Society (2002).   All Rights Reserved.

   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared, copied,
   published and distributed, in whole or in part, without
   restriction of any kind, provided that the above copyright notice
   and this paragraph are included on all such copies and derivative
   works.   However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to the
   Internet Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which case the
   procedures for copyrights defined in the Internet Standards
   process must be followed, or as required to translate it into
   languages other than English.

   The limited permissions granted above are perpetual and will not
   be revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on
   an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS 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.




























   Yegin                Expires December 2002