Subject: [pilc] RE: AD request / L2 Views Problem Statement

From: Scott Corson <[email-masked]>
Date: Fri, 10 May 2002 13:23:08 -0400

Phil, All,

I posted a still largely conceptual draft

http://www.ietf.org/internet-drafts/draft-corson-triggered-00.txt

that's related to this discussion...was mostly done before Phil raised this
whole IP underbelly API issue, and is more related to the L2 triggers BOF
that James has been after for some time.

Probably 10x the words required given the content (sorry), but just a bit of
rationale that I wanted to explain.

Regards,

-Scott

> -----Original Message-----
> From: Phil Neumiller [mailto:[email-masked]]
> Sent: Tuesday, May 07, 2002 11:27 AM
> To: Eric Whitehill; Scott Corson; [email-masked];
> [email-masked]; Rex Buddenberg; 
> [email-masked]; Dr. Chane
> L. Fullmer; [email-masked]; 'William Ivancic';
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Anders Lindgren; [email-masked];
> [email-masked]; Armando L. Caro Jr.
> Cc: [email-masked]
> Subject: AD request / L2 Views Problem Statement
> 
> 
> Hi Eric,
> 
> I am reluctant to carry on discussions on the pilc list, 
> since I would like confirmation
> from an AD whether they want this discussion here or 
> someplace else.  I assume they
> do, since they relocated the L2 triggers BOF to PILC.   I 
> believe at this point we are
> discussing things within the scope of that planned BOF.  
> 
> AD Request,
> 
> Scott and/or Allison can probably provide clarity here.  I 
> want to express that my 
> desired "perspective" is to position ourselves as link layer 
> designers that want to
> see some standardization on the IP underbelly, i.e. an API if 
> you will, to IPs darker
> side, and a standardized way for IP to send events (at the 
> millisecond time scale)
> "up" to the IP layer.  This means adding standardization to 
> IP, not link layers.  It
> means we want to standardize the way link layers "talk to" IP 
> in the upward
> direction.   The first proposal is a high performance queue 
> for event notification offered
> by the IP layer to bound link layers.  The simplest use of 
> this queue is simply to buffer
> the notifications and forward them to the transport layer if 
> not "hooked" by the IP
> layer.
> 
> With respect to your question Eric, several people have sent 
> comments on the problem
> statement and everything at this point is work-in-progress 
> and everybody is welcome to
> contribute whatever they whenever they can.  Before getting 
> to a formal problem 
> statement, it may prove fruitful to first entertain some 
> philosophical discussions regarding
> the under-specified IP underbelly.  Perhaps many feel that 
> the current underbelly mechanisms
> of arp, rarp, icmp, etc are sufficient for wireless 
> devices???   Maybe the definition of a 
> host/gateway just needs some sprucing up (RFC 1122 / RFC 1123)?
> 
> Best Regards,
> 
> Phil
> 
> 
> ----- Original Message ----- 
> From: "Eric Whitehill" <[email-masked]>
> 
> 
> > Phil,
> > 
> > Perhaps I didn't see it, but did everyone agree to the 
> problem statement
> > that you included in 
> > your 4/30 e-mail?
> > 
> > Eric
> > 
> 
> 

_______________________________________________
pilc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 10 May 2002 15:40:04 -0700 (PDT)

Hi Scott,
  I am attaching something that can be used to the
effect of a charter.
  Any comments?

--behcet
--- Scott Corson <[email-masked]> wrote:

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother's Day is May 12th!
http://shopping.yahoo.com

L2 Triggers BOF (l2tr)

July 2002
================================

CHAIRS:	 

o DESCRIPTION OF THE BOF:
  =======================

The purpose of L2 Triggers work is to develop layer 2 service specifications for wireless links.  Service interactions between the IP layer and the link layer will be identified and defined precisely. The work may involve the definition of a protocol to carry the interaction occurring at layer 2 entities to where L3 interface exists. The work will concentrate on the definition of service interactions from layer 2 towards layer 3, aka triggers.

The ability to quickly and efficiently determine the existence (or non-existence) of a link is needed most commonly as a consequence of 
movement-induced changes in network topology.  Mobile handoff, 
whether in cellular or WLAN contexts, generally requires that the 
entire process complete within 10's of milliseconds is seamless 
voice service is to be maintained.  This requires very fast 
detection of changes in link status.  Since a link layer best 
knows its current link status it is natural to use L2 triggers for this purpose.

While the link status for L3 handover protocols is expected to be the most popular use of L2 triggers, there are other areas or protocols that may benefit from L2 events to be triggered to layer 3, e.g. IP Paging protocol. 

The work will concentrate on identifying the triggers needed by IP layer such as the link status. For each trigger it is necessary to identify the parameters to be passed. It is also important to identify the best formalism to define these parameters. The use of API languages such as C, Java will be considered. Another aspect of formalism is whether or not callbacks should be used or is it preferable to define the triggers in the form of operating system primitives.

The technical problems to be solved include:

 -  generic triggers and triggers specific to different layer 3 protocols such as handover, paging, MANET routing, etc.
-  L2 trigger transport protocol.
-  Triggers specific to each link such as cellular, 802.11, HIPERLAN1, HYPERLAN2, Bluetooth, future technologies such as Flash OFDM.

 -  The work may optionally extend to the coordination for the definition of Layer 2 trigger transport protocol for the links that do not support it with IEEE, Bluetooth, PPs and other organizations. L2 trigger transport protocol must use IP transport and may be version dependent.

The work on L2 triggers needs some amount of collaboration and synchronization with MobileIP WG and MANET WG and IP Paging BOF.

o The BOF's goals are:
  ===================

- Show why L2 triggers need to be defined.

- Assess interest in forming a Working Group on L2 triggers.

- Get feedback on the problem statement, which could be used as the
  basis for a Working Group Charter. The discussion of the problem
  statement on the mailing list is recommended prior to the BOF. The BOF
  will be used to form a working group.

- Reach consensus on the terminology to be used for L2 triggers.
  A discussion on terminology on the mailing list is recommended to  
  speed up the process of reaching consensus.

- Outline a number of requirements that must or should be met by the
  solutions for supporting a L2 trigger transport protocol. 

- Come up with an architecture document for L2 trigger transport protocol.  

- Outline any security issues.  

o L2TR BOF AGENDA (54th IETF Yokohama)
  ========================================

- Introduction and agenda bashing 5 min

- TBD
  
- General discussion and opinions on moving forward - All 20 min

o DELIVERABLES
  ============

- Terminology, Problem Scope: July 02

- L2 Trigger APIs : during 03
- Requirements and Framework: December 02

- L2 Trigger Transport Protocols : during 03

o MAILING LIST:
  =============

  [email-masked]

  Subscription instructions can be found at ietf.org.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 10 May 2002 23:23:55 -0400

Behcet,

Given that we are comming from a manet list, keeping this referant
might be helpful.

I don't think it is helpful to reference voice, except as one of
many problem domains where link-state topology changes are usefully
triggered up-stack.

Eric