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

[Greg Daley <greg.daley@eng.monash.edu.au>]

Alper Yegin wrote:
[Part cut]
> 
>>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...

OK, it is a Hack :)
Maybe we can discuss this later.


>>>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.

I'm not sure if it is completely possible,
although no new behaviour is likely to be
available from the network for IPv4.

> 
>>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.
You mentioned that DNA was a trigger client technology
(like trigtran, for example).

Do you see the role of a general
trigger document to be in DNA or elsewhere?



>>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.

This is correct if the detection cannot be easily
achieved in some other fashion.  If it can be
detected unambiguously without a trigger, then
we can simplify specifications by leaving triggers
out of a base document.

>>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.
>
Indeed :)

Greg