Re: RE: AD request / L2 Triggers Chapter Statement

Hi Joe,

Sorry about the militancy.   As you can tell, I am a strong advocate of L2 triggers.  I have
been working in wireless for many years and this IS one of the REALLY important missing links
IMHO (excuse the pun).

I had this in mind when I founded (some would say confounded :-) the SeaMoby WG.  This
topic however never made it to the SeaMoby charter.  What I want to see now, is a WG whose
sole purpose in life is to specify an interface to the underside of the IP stack.  This has remained
an implementation specific black art heretofore as you can bear witness.  

I have responded to the rest of your comments below in a more RELAXED manner... :-)

Before I do that, I want to state that many new 3G/4G/MANET type of devices have pretty
beefy real time OS's and can communicate across many simultaneous links that come and go
on milisecond time scales.  Although your virtual link sounds like a nice idea I would recommend
that you carefully study SCTP multi-homing because it can do this already and is an RFC.

onward...

----- Original Message ----- 
From: "Joe Touch" <[email protected]>


> OK - so we agree to disagree on whether anyone would use this 
> information.  My concern is that no existing protocol does anything 
> anywhere near this fast in the Internet; the simple variability in paths
> is enough to kill most 'hard realtime' guarantees on timing. As a 
> result, it isn't clear that they COULD (perhaps not enough to convince 
> you, but can you convince me??).

There are two cases here that are of utmost importance.

1).  The edge device managing multiple 10E0-02 links and attempting to
       multi-home across them and handover seamlessly.  Dropping packets
       (specifically VOIP and or other codec packets) is usually a bad thing.
       In break-before-make L2 systems it is often necessary to drop some
       at the handover seams.  For this reason, it is often necessary to assess
       link quality statistically at higher layers to make informed decisions about
       initiating handover processing.  There is tons of latency involved in
      handovers and registrations and security associations.  Any "heads 
      up" from the link layer is extremely helpful.  Let's face it.  IP was not
      originally conceived for handoffs.  IP is an evolving creature.  The world
      is going mobile and IP must too.

2).  Routers that have several heterogeneous or homogeneous wireless links
       also need to collect link statististics to ensure quality of service.       

> >>What I'm asserting is:
> >>
> >>if it's within two links of the same type, a meta-link can do it
> > 
> > 
> > Yeah, and where is this defined in ANY commercial IP stack???
> 
> No. And rightly so. That would be inside the link layer.

How exactly would these two link layers talk to each other?  Each would have
its own IP address right?

> Can you be more specific (and less inflammatory, please?)?
> E.g., a policy based-routing that would _change_ what it does on a 
> millisecond timescale. Granted that policy routing operates on those 
> timescales, but it isn't clear that anything it does would change on 
> those timescales.

The argument is circuitous.  What we are saying here is that the is a NEED
to do this for seamless handover.  We are not sayint that anything does this 
now.  If you are happy with MANET, and MIP handovers as they stand, then
we can all go home.  If you feel that there is something lacking with respect
to link knowledge being propagated upward to IP and transport then we
have work to do here.

> 
> > Especially with respect to
> > wireless handovers which is the MAIN purpose of this discussion.
> 
> Wireless handovers is a link-layer issue, not necessarily an IP-layer
> issue.

IP over everything.  Dumb network, smart host.  What you are suggesting
is an IP architecture violation.

Handover decisions need to be above the IP layer so that routing can be involved.
How on earth would mobileip and MANET cooperate if the link layer handled the
handovers and there was absolutely no standard way to communicate this to the
IP layer.  You are starting to make my arguments for me Joe!

> So what you're saying is:
> 
> - we NEED L2 triggers

We need a mechanism and interface proviced by IP to allow any and all future L2s to
use a STANDARD IP triggering notification method.

> - we NEED all of IP to change to be realtime to USE L2 triggers

Hmm.  This seems a bit sarcastic to me but I will go with it.  No.  We need an input
queue (can be implementation dependent) on the underside of IP that can accept
events that occur on millisecond time scales.  These events can be forwarded to 
routing modules and transport modules that have registered interest in these events.
What do you mean by "all of IP"?  I would agree that I suggest IPv6 do this for
certain.

> - everyone NEEDS all of this to support one link type for
> certain applications

No.  The beauty is we do this once and every L2 from here to eternity works
seamlessly.  You have it completely backwards.


> Sounds a lot like optimizations.

Yes to the design of the underspecified IP underbelly.  No harm in standardizing
optimizations last time I checked.

> 
> Does anyone else have a position to share on this?? I'm not claiming 
> that this group should not move forward; it would be better, IMO, if 
> there were a clearer reason, however...

Most anyone with experience implementing LLCs, MACs, and interfacing
them to the IP layer clearly sees the need for this work.  In fact all those people
that are CC'd on this EMAIL have expressed interest in precisely this.  That is the
definition of a BOF.  You may just be a different kind of bird!  :-)

Thanks,

Phil (IP underbelly standardization advocate)


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