L2-Trigger unofficial meeting
Tuesday, March 18th, 2002
IETF-53 Minneapolis, MN
led by (& notes taken by)
Aaron Falk <falk@isi.edu> and
Carl Williams <carlw@docomolabs-usa.com>
attendance: about 55 people
(beer courtesy of NTT DoCoMo)
=============================
Based on interest from folks engaged in manet, mobileip, and seamoby
working groups, an unofficial meeting was held to discuss issues
surrounding the triggers at layer 2 to communicate information to
upper layers in a hosts protocol stack. Two drafts, one discussing
the issues (draft-manyfolks-l2-mobilereq-01.txt) and another proposing
an API (draft-guri-seamoby-paging-trigger-00.txt) had been previously
submitted. The objective of the meeting was to discover if the scope
should be more broad than the drafts proposed. This was accomplished
by a somewhat unstructured discussion that touched on several topics
including what information to express, how it is delivered, and some
possible next steps. The conversation and some perceived conclusions
are summarized below.
WHAT TO EXPRESS
Not a new problem, past experience likely useful:
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 info. Routing folks have
learned a lot about how links lie about their state (e.g., links that fail
half-duplex).
In fact, router manufacturers may have insight as to which metrics would be
of interest or possibly how to extend or abstract them if they are willing
to share the information. Getting input from people familiar with routing
would be valuable.
Small set of common functions seen as useful:
The most common need expressed for information to be revealed was 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. (There already exists an appropriate SNMP
message but it appears to be largely unused.)
Interaction with MobileIP:
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.
Discussion about architectural principles and amount of revealed information:
It was suggested that it might be valuable 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 was widely thought to be a bad idea as it 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.
Some other caveats that were suggested: Triggers should only enable
performance enhancements and not be used for correct protocol
operation. 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. Apps can fight with L3 if it's done wrong.
Management applications considered a special case:
In the context of the above discussion, management applications were seen
as a special case that might require greater access to link information
than would normally be made available to normal applications (or even
protocol stack internals). This is because the application is
intentionally associated with the management of a specific L2 technology.
For example, 802.11 cards typically come with a management application that
reveals information about the card status, link status, and access
point(s). This information is necessary to ensure the correct functioning
of the card and should not be considered an Internet network application.
HOW IS L2 INFORMATION DELIVERED
Options for how to implement L2/3 communication include an API, a MIB, or a
protocol. Most of the applications discussed above do not require
communication across the wire and so a protocol does not seem to be
justified or appropriate. It's unclear whether an API or MIB is more
appropriate. MIBs were considered by some as somewhat 'heavyweight'
because accessing local information typically requires SNMP to localhost
and implies ASN.1 marshaling that is not needed in this situation. This
issue is particularly important to small memory and power-limited wireless
devices.
Most participants agreed 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 MIB or API is
really secondary to the question of what information should be passed
between L2 and L3. In the IETF, that process is frequently captured in a
MIB. However, since the issue is really a matter of internal communication
within a host, it may not be necessary to standardize or even specify the
format or mechanism which is used to communicate across the L2/L3 boundary.
SOME NEXT STEPS
Since the IETF doesn't develop link technologies, one output of an IETF
effort might include an informational RFC on which information to
export/reveal. This document will likely be of interest to other standards
bodies who standardize link technologies. (Some of these ideas have
already been taken to IEEE 802.11. The IEEE is also working on related
issues in the context of OAM.) This might be considered a natural extension
of the PILC working group document "Advice to Subnet Designers."
The IESG will provide advice as to the next process steps. They could
include doing the work in PILC, possibly requiring rechartering,
holding a BoF, creating a new working group, or possibly just an
individual RFC submission. For the moment, the discussion should take
place on the PILC mail list. Subscription instructions are available
through the working group charter page at
http://www.ietf.org/html.charters/pilc-charter.html. Should the work
take place in a seperate working group, naturally a new mailing list
will be formed.
--aaron (for aaron and carl)
Postscript
In the wireless directorate meeting (of chairs of wireless-related working
groups, it was suggested that besides advising link designers, we should
also consider an advisory document to upper layers on how to handle L2
information.
This archive was generated by hypermail 2b29 : Wed Apr 03 2002 - 19:00:11 EST