Re: [DNA-BOF] Initial Reading List ideas for DNA

[Alper Yegin <alper@docomolabs-usa.com>]

Hi Greg,

>> http://www.yegin.org/alper/draft-manyfolks-l2-mobilereq-02.txt
>> 
>> This work was originally driven by the Mobile IP fast handovers work. We
>> made an attempt to formally define link-layer triggers (so called hints in
>> Bernard's document) in an abstract form. Their details differ among
>> link-layer technologies, but a uniform abstraction is needed from IP
>> perspective. Potential consumers of these triggers are discussed in the
>> document.
> 
> There's certainly a lot of value in L2 'Link UP' triggering on the
> attaching host.  We've used this trigger to solicit an RA
> with a FastRA capable router in very short time.
> I think that section 6.0 summarizes the general benefits of this
> technology, without requiring mobility signalling.
> 
> The work on context transfer, and oAR/nAR triggering may be more
> oriented toward Fast MIPv6 or Seamoby work.

Yes, these are the existing consumers of the link-layer triggers.
Triggers are not necessarily customized for them though.

> 
> Hasn't this work been picked up by another WG?

Nope. Closest is the TRIGTRAN which is a bof, and they simply deal with
describing how these triggers (or a subset) will be used/consumed by
transport protocols. What is missing is the definition the triggers
(possibly an informational RFC for the aforementioned document). Other WGs,
like DNA when it becomes one, can refer to this RFC and specify how it can
use the triggers (define another consumer).

> 
>> http://ietf.org/internet-drafts/draft-yegin-l2-triggers-01.txt
>> 
>> This draft proposes a protocol that conveys the link-layer triggers when the
>> trigger is generated on one IP node and consumed in another. Example
>> scenario is WLAN APs connected to access routers. If the access router wants
>> to know when a host connects or disconnects, it needs to be notified by the
>> AP.
> 
> I agree that the presence of triggers at the AP provides some
> incongruity, which samsung's FRD attempts to solve (through RA caching).
> Has there been any discussion about the possibility of using AAA
> proxying for transferring L2 triggers between APs and ARs?

I'm not aware of any.

> 
> Is there a value in developing a separate protocol? I was wondering
> if it was valid to configure APs to use the AR as a AAA proxy.
> This would provide some trust (validation by the AR's AAA service)
> in allowing APs to send triggers.

I'd think using AAA signaling for delivering triggers stretches the protocol
beyond its intended use and has limitations. But this is for another thread
to discuss...

>> I think the relevance of link-layer triggers to DNA comes from this: We can
>> develop some heuristics for hosts to consume some network layer information
>> (such as DHCP info, router advertisements, ND or ARP results) to determine
>> if it has moved. Using link-layer triggers would not only enhance the
>> perfomance of these mechanisms, but also help increase the confidence of the
>> hosts in such determinations.
> 
> 
> I'm certainly interested if Triggering systems may be used to
> assist attachment detection.  I still think that any communication
> between the attaching host and the access network will have to
> use existing mechanisms though.

So, DNA WG should not invent new protocol signaling between the network and
the host? This sounds like an appealing goal.

> Given this premise, I think that DNA would have to work even
> without L2 hints...

Using link-layer triggers does not incur additional signaling between the
host and the network. Triggers in most of the cases don't even involve any
protocols. But still we need to provide guidelines to implementors about
what they are, and how they should be used - hence the informational RFC.

> 
> About using L2 triggers to free up resources, an analogous
> triggering may be applicable for upper layer sessions, similar to
> the work done by Spencer Dawkins on TCP.
> 
> I'm thinking that L2 triggering may be just a part of the solution
> though.  Once the link identity has been determined (for example,
> if we know we have attached to a network where the current address
> is no-longer valid), then host internal signalling may be
> provided to free ND caches, TCP sessions &etc.
> 
> There wouldn't be direct correspondence between L2 and upper layers
> except through Network Attachment Detection.  I think that
> we would have to try to develop a robust enough mechanism for the
> detection that it could be relied upon even without the L2 trigger.
> (Though it may not be so fast).

L2 triggers are not only for performance. They can also play an active role
in increasing the confidence of the mechanism. For example network-layer
indications coupled with a link-layer movement feedback can be regarded as a
clear sign of movement.

> 
> Of course, once we start talking about this, there's always the
> possibility that the work could be described as "Implementation
> Specific".  It may be possible to provide information to implementors
> though how this may be done.
> 
> 
>> Another angle on this work is, we might also consider the network side for
>> assisting network attachment detection. If the network is made aware of
>> arrival of a new host, it might provide additional hints to the host.
> 
> Sorry to self-advertise here, but we've done some work on
> identifying the link in RA messages, which provides a strong
> hint to attaching devices about the validity of their configuration.
> 
> This works without requiring L2 trigger support.
> 
> http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-00.txt
> 
> In the case where the network knows about the attachment,
> it can send an RA from an AP (Cached) or from the AR (after trigger from
> AP).  If it contains a LinkID, it may be possible to
> provide unambiguous detection of attachment with just the RA message.

I quickly checked it. This is an interesting work.

> 
>> Finally, while detecting network attachment is important for host to take
>> actions to restore IP-layer connectivity, detecting detachment of a host is
>> also important/useful for networks in order to at least free up resources.
>> Do we consider this in scope?
> 
> I'm not sure yet!
> 
> There seems to be a lot which people are interested in.
> 
> Maybe we can talk about what we need to achieve first,
> and then describe what means are considered to have good
> potential.

Along with that, we should also be developing some understanding of what we
won't be doing (out of scope items). This information is sometimes as
important as the other one.

> 
> Experience in WGs which have attempted to define some
> of these methods previously (for example mobileip) may
> be beneficial.
> 
> At this stage, collecting a reading list is not about
> how to solve the problems, but talking about previous work,
> so that people can gain a picture of what has been happening
> in areas which may complement their own interest.
> 
> Thanks for the references.

Cheers,

Alper