notes from L2 Triggers meeting
Aaron Falk <falk@ISI.EDU> Wed, 03 April 2002 23:58 UTC
Subject: notes from L2 Triggers meeting
From: Aaron Falk <falk@ISI.EDU>
To: pilc <pilc@grc.nasa.gov>
Cc: Carl Williams <carlw@docomolabs-usa.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.2
Date: Wed, 03 Apr 2002 15:58:23 -0800
Message-Id: <1017878303.3859.203.camel@nit>
Mime-Version: 1.0
Sender: owner-pilc@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 7494
Lines: 148
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.
- notes from L2 Triggers meeting Aaron Falk