One document matched: draft-yegin-l2-triggers-00.txt
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 | PAFTECH AB 2003-2026 | 2026-04-22 06:32:48 |