One document matched: draft-williams-l2-probstmt-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-22 14:47:52 |