Internet Draft Alper E. Yegin Expires: December 2003 DoCoMo USA Labs June 2003 Link-layer Triggers Protocol draft-yegin-l2-triggers-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 that implement 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 2003 [Page 2] L2 Triggers June 2003 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............................................10 4.0 IANA Considerations.........................................11 5.0 Security Considerations.....................................11 6.0 IPR Statement...............................................11 7.0 Acknowledgements............................................11 8.0 References..................................................11 9.0 Author's Addresses..........................................12 10.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 the 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 have 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) triggers. [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 (e.g., an API) between two modules running on the same IP node should be sufficient. Yegin Expires December 2003 [Page 3] L2 Triggers June 2003 ~~~~~~~~~~~~~~~~~~ \|/ 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 for 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 the 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 2003 [Page 4] L2 Triggers June 2003 2.0 Protocol Overview In this protocol, bridges are the servers that have firsthand knowledge on the L2 events, and hosts and routers that use these bridges are the clients that are interested in knowing 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 a dynamic discovery method. Clients can discover servers on the same subnet by multicasting a Hello message to a well-known IP address and port number. Servers must respond to this message by sending a unicast Hello message. 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 its 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 2003 [Page 5] L2 Triggers June 2003 Trigger message to indicate conditions leading to an earlier 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 with 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Data ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Yegin Expires December 2003 [Page 6] L2 Triggers June 2003 Version The protocol version is set to 1. Type 0 Reserved 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type |C| Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version The protocol version is set to 1. Type 1 Hello C Client bit. Set to 1 when Hello message is sent by a client, set to 0 otherwise. Reserved Reserved flag bits, sent as 0. 3.2. Registration Message Clients use this message for registering with the servers. Servers should deliver L2 triggers only to the registered clients. The same message is used for both Registration Request and Registration Acknowledgement. Yegin Expires December 2003 [Page 7] L2 Triggers June 2003 The UDP header is followed by the following protocol fields for a Registration 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version The protocol version is set to 1. 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 flag 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 0xffffffff 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. Yegin Expires December 2003 [Page 8] L2 Triggers June 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version The protocol version is set to 1. Type 3 Trigger A Acknowledge request bit. When set, the client must send back an acknowledgement. Client sends back a Trigger message with A bit set to zero, Identification copied from the incoming Trigger message, and no data in order to acknowledge receipt of a Trigger message. Reserved Reserved flag bits, sent as 0. Identification A 32-bit number, constructed by the server, used for matching Trigger messages with Trigger Acknowledgement messages. This may be used as a monotonically increasing counter by the server. 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 ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Yegin Expires December 2003 [Page 9] L2 Triggers June 2003 Event Type 0 Reserved 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, 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 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 and Link Down. Only hosts can receive Mobile Pre-trigger, and only access routers can receive Source Pre-trigger and Target Pre-trigger. Yegin Expires December 2003 [Page 10] L2 Triggers June 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type |R| Reserved |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2 Address ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version The protocol version is set to 1. 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. 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 Yegin Expires December 2003 [Page 11] L2 Triggers June 2003 expected to be specified in specific documents that describe how IP operates over different link layers. 4.0 IANA Considerations A link-local multicast IP address and a UDP protocol port number will be registered by IANA. 5.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 the 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. 6.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. 7.0 Acknowledgements Author of this draft would like to thank Carl Williams, Daichi Funato, and Youngjune Gwon for their valuable comments and discussions. 8.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, Yegin Expires December 2003 [Page 12] L2 Triggers June 2003 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. 9.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 10.0 Full Copyright Statement Copyright (C) The Internet Society (2003). 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. Yegin Expires December 2003 [Page 13] L2 Triggers June 2003 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 2003