Re: [DNA-BOF] Example of 'IP neighbourhood' instead of 'L3 link' incharter.

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

Hi Kostas,

Kostas Pentikousis wrote:
> Hi Greg!
> 
> Please find some comments, suggestions, and nits in-line.
> 
> On Fri, 9 Jan 2004, Greg Daley wrote:
> 
> |When an IP node detects or suspects that its underlying link
> |layer (L2) connectivity has or may have undergone a change, it
> |needs to check whether its IP layer (L3) configuration and
> |connectivity are still valid or have changed. In the case that
> |the L3 connectivity has changed, the node needs to reconfigure
> |and may need to initiate mobility procedures, such as sending
> |Mobile IP binding updates. Changes in an L2 connection do not
> |necessarily mean that there has been change in L3 connectivity.
> 
> It's clear what "detects" mean: a(n error) message from the layer
> below. But what does "suspect" mean?

I guess that when you get a L2 hint, you may begin to
believe something, but not be sure.

In this case it's worth checking.

Is this not clear?


> What about replacing "link layer (L2) connectivity" with "link
> layer binding"? Do we actually need "IP layer (L3) configuration
> *and* connectivity". Why isn't "configuration" enough?

connectivity is required, since in wireless environments,
reception of messages of one class or in one direction
doesn't imply bidirectional reachability.

Therefore, checking that bidirectional communication to
the router (or another fixed network-layer entity) exists
confirms connectivity.


> Suggested text:
> 
> When an IP node detects (or suspects?) a change in its link layer
> [connectivity|binding] it needs to check whether its IP
> configuration is still valid. Changes in link layer
> [connectivity|binding] may force a node to modify its IP
> configuration by initiating mobility procedures such as sending
> Mobile IP updates [RFC 3344]. However, in many cases, link layer
> changes do not necessitate IP reconfiguration.

I think that there's a difference of emphasis here.

In the current charter, the IP configuration must be changed
_and_ IP Mobility signalling may be required.

In your version, IP mobility signalling is required for
the IP configuration.

This implies that IP mobility signalling is the natural
consequence of using DNA. This is actually what's being
avoided.

We're trying to ensure that the change detection works
for hosts which don't use IP mobility such as
multicast clients (that's why this group isn't part
of the IP mobility working groups).

> 
> |For the purposes of detecting network attachment, an IP
> |neighbourhood is defined by the range within which IP packets may
> |be sent without resorting to forwarding. In other words, a
> |neighbourhood is the range where a given IP configuration is
> |valid.
> 
> s/defined by/defined as/
> 
> I'm not very comfortable with defining this new term: IP
> neighborhood

That's OK. It's not official, just an idea.

> |In IPv6, the IP layer configuration information includes the set
> |of valid unicast addresses[RFC2462, RFC3315], the DAD status of
> |the addresses[RFC2462], valid routing prefixes[RFC2461], set of
> |default routers[RFC2461], neighbor and destination
> |caches[RFC2461], multicast listener (MLD) state[RFC2710]. The
> |current IPv6 stateless and stateful autoconfiguration procedures
> |may take a fairly long time due to delays associated with Router
> |Discovery and Duplicate Address Detection processes.
> 
> s/[RFC/ [RFC /
> s/DAD/Duplicate Address Detection/ (acronym not defined)
> s/ processes//
>
Thanks.

> |In some wireless technologies, the link layer state and events
> |may not be accurate and unambiguous from the IP point of view.
> 
> Well, are they at least unambiguous from the LL point of view?


Yes, as far as I know.  There's often a unique identifier
for a base-station, which can be drawn upon.

> s/may not be accurate and unambiguous/may be ambiguous/
> 
Thanks.


> |For example, a host may be able to see a base station but still
> |be unable to deliver or receive IP packets within the IP
> |neighborhood. Similarily, a hardware indication that a radio link
> |is up does not necessarily mean that all link layer
> |configuration, such as authentication or virtual LAN connectivity
> |has been completed. Therefore detecting network attachment
> |requires not only change detection but IP layer connectivity
> |testing.
> 
> What does "see a base station" mean? Sense its presense at the LL?
> 
> s/Similarily/Moreover/
>
> s/authentication or virtual LAN/authentication and virtual LAN/

Thanks.

> 
> Does "In sum, detecting network attachement requires not only
> detection of link layer [connectivity|binding] changes, but also
> determining whether IP reconfiguration is needed."
> 
> read better than
> 
> "Therefore detecting network attachment requires not only change
> detection but IP layer connectivity testing."?

Not really, the idea is to show IP connectivity (that we have
reachability with IP messages), rather than at the lower layer,
which for some reason may be working.

For example, I have a black hole WLAN access point 10 metres from
my desk. It works fine at L2.

> |The purpose of the DNA working group is to define standards track
> |and BCP documents that allow hosts to detect their IP layer
> |configuration and connectivity status quickly, proposing some
> |optimization to the current specifications that would allow a
> |host to reconfigure its IPv6 layer faster than today.
> 
> Suggested text:
> 
> The purpose of the DNA working group is to produce Standards Track
> and BCP documents that describe how hosts can quickly determine
> the validity of their IP configuration, and propose optimizations
> to current specifications allowing for faster IPv6
> reconfiguration.
> 
> 
> |Initiation of neighbourhood change detection procedures can be
> |achieved either through reception of messages at the IP layer or
> |through indications from other layers. The working group will
> |produce a document that contains a catalogue of the indications
> |available from a number of link layer technologies.
> 
> Is the following problem relevant to the WG? Assume that a user is
> at an outdoors cafe which offers 802.11 connectivity at $x/min.
> After a while, Mr. Nice Guy turns on his free-to-all wireless
> access point allowing anyone to share his broadband connection.
> Shouldn't the user be informed of the offering and permitted to
> switch to the free AP?

I'd guess that the presence of the AP itself (to which one's
not associated) and the choice of which to use wouldn't be
explicitly under the jurisdiction of DNA.

There is experimental work on candidate access router
discovery in seamoby, which could provide an in-band mechanism
to determine the rates charged on neighboring routers.
The policy decision isn't really covered here.

Of course, having interfaces charged per MB or per Minute
may affect the DNA strategy for that interface.
For example, when charged per MB, you may wish to
use a passive strategy which sends few packets to determine
new IP addresses, especially if you have an alternative
connection (for example, the 3G network could be per MB and
the active WLAN could be free or charged per hour).

> |The working group will define best current practice for nodes
> |making use of existing L3 and L2 information for detecting
> |network attachment.
> |
> |The working group will define a set extensions to the
> 
> s/a set/a set of/

Thanks.

> 
> |current IPv6 configuration protocols [RFC2461, 2462, possibly
> |RFC3315] that allow the nodes to discover whether L3
> |configuration or connectivity may have changed more reliably and
> |easily than today.
> 
> (again "L3 connectivity")
> 
> |
> |?In order to detect network attachment, it is important
> |?to be able to send and receive IP packets, even if the
> |?IP neighbourhood has changed. The DNA WG will develop
> |?a system which allows use of an IPv6 addresses without
> |?the latency cost of the traditional DAD [RFC2462].
> |?Such a system may allow the transfer of user data
> |?while neighbourhood change detection and DAD
> |?procedures are in progress.
> |
> |The DNA WG will not define new procedures or APIs
> |related to link layers.
> 
> IMO, the paragraph is redundant and restrictive, but I agree with
> an earlier of your posts about the possibility of initiating a
> different/follow-up WG.
> 
> <snip>
> 
> |Aug 2004: Submit Goals for Detecting Network Attachment
> |           in IPv6 as informational.
> 
> s/informational/Informational/
> 
> |
> |Aug 2004: Submit Best Current Practice for Detecting
> |           Network Attachment in IPv6 as BCP
> |
> |Aug 2004: Submit Existing Link Layer Hints Catalogue as
> |           informational.
> 
> s/informational/Informational/
> 
> |
> |?Aug 2004: Submit IPv6 DAD Optimization Goals as
> |?          informational.
> 
> s/informational/Informational/
> 
> Kudos for your excellent work!

Thanks for your feedback.

Greg