RE: [NSIS] notes from L2 Triggers meeting

["Gary Kenward"<[e-mail]>]

Sounds like it was a very productive meeting.
Perhaps they should start serving beer at the wg meetings ;^}

Gary

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: April 4, 2002 01:30
> To: [e-mail]
> Subject: [NSIS] notes from L2 Triggers meeting
> 
> 
> L2-Trigger unofficial meeting
> 
> Tuesday, March 18th, 2002
> IETF-53 Minneapolis, MN
> 
> led by (& notes taken by)
> Aaron Falk <[e-mail]> and
> Carl Williams <[e-mail]>
> 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.
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
>