[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] DNA Goals response
Dear Jim
Thanks for your kind feedback. Such a detailed comments. A sight for
a sore eyes. :-)
I see two main issues.
1. The definition of 'link'
I think there is a confusion around the 'link' definition. We define link as of
RFC 2461, a communication facility or medium over which nodes can
communicate at the link layer.
Here is the example which will illustrate my point.
Suppose two APs are one the same ethernet segment and share one AR
like below. Also assume an MN is attached to an AR through AP1.
|
__|____
| |
| AR |
|___ __|
__________|__________________
| |
__|__ __ |__
| AP1 | | AP2 |
|____ | |___ _|
Though there are two BSS, there is only one link. If the MN moves from AP1
to AP2, it still remains at the same link.
We discussed about the term 'link' in DNA ML for a while ago. Though we were
not entirely happy with the term, we could not find a better term.
Kindly find my presentation at 58th IETF meeting in which I tried to clarify the
notion of link there.
http://www.ctie.monash.edu.au/dna/DNAv6JH58.ppt
In the discussion concerning terms, L2 link and L3 link, we decided to use 'link'
for 'L3 link' and 'attachment point' for 'L2 link'. You can find more details in
Feb DNA ML.
2. Analysis parts
Goals drafts contains the analysis related parts, Sec 2 DNA in Existing IPv6 Systems
and Sec 3 Problems in DNA. I understand that you suggest to cut them down.
It was our intention to present the current state of art of DNA, without
evaluating the pro and con of the possible solutions. We aimed to describe
the limitation of the existing IPv6 to clarify the Goals.
We thought that it would be useful for Goals draft to include some analysis
but you seemed to disagree. Right? Kindly confirm yourself.
If so, I will start a thread about this and in case WG decide to remove the
analysis parts, we will remove them or generate a separate draft.
I wish we take a pragmatic approach, (rather than dogmatic). We'd better make
a decision based on whether it would help Goals draft to include analysis part or not.
Also kindly find my inline comments.
> Except for some intro section and section 4 this entire document does
> not represent goals but analysis. I think they should be two different
> docs and two different thread debates. Comments to the point in line. I
> am less concerned in this response with the correctness of statements
> but more about the layout of the goals document and what I think we need
> a current analysis document both of which require different discussions
> and thoughts.
I see your point.
> > Abstract
> >
> > At the time a host establishes a new link-layer connection, it may or
> > may not have a valid IP configuration for Internet connectivity. The
> > host may check for link change, i.e. determine whether a link change
> > has occurred, and then, based on the result, it can automatically
> > decide whether its IP configuration is still valid or not. While
> > checking for link change, the host may also collect necessary
> > information to initiate a new IP configuration for the case that the
> > IP subnet has changed. In this memo, this procedure is called
> >
> > Detecting Network Attachment (DNA).
> >
> > Rapid attachment detection is required when a host has on-going data
> > traffic. Current DNA schemes are inadequate to support real-time
> > applications. The existing procedures for advertising network
> > information incur reception delays and do not provide enough
> > information to properly determine the identity of links. For
> > to-be-defined, efficient DNA schemes, a way to correctly represent a
> > link change, a complete and consistent procedure for network
> > information advertisement and a rapid delivery of the advertisements
> > will be necessary.
>
> I would just keep the first paragraph for the abstract.
The second part is more about analysis. In case WG decide to do away with
the analysis, we will make a modification accordingly.
> > 1. Introduction
> >
> > When a host has established a new link-layer connection, it can send
> > and receive some IP packets at the link, particularly those used for
> > configuration. On the other hand, the host has full Internet
> > connectivity only when it is able to exchange packets with arbitrary
> > destinations.
> >
> > When a link-layer connection is established or re-established, the
> > host doesn't know whether its existing IP configuration is still
> > valid for Internet connectivity. A subnet change might have occurred
> > when the host changed its attachment point.
> >
> > In practice, the host doesn't know which of its addresses are valid
> > on the newly attached link. A host knows neither if its existing
> > default router is on this link, nor whether its neighbor cache
> > entries are valid. Correct configuration of each of these components
> > are necessary in order to send packets on and off the link.
>
> Add during "movement to new link" to the above is input.
The host only changes it's link-layer connection. It's not certain whether
it moves to a new link or not yet.
> > While other information for IP connectivity (such as DNS server
> > configuration) is also important, obtaining most of such information
> > depends on the determination of correct global addressing and valid
> > default router configuration.
>
> I think the paragraph above needs work. I could find all this on a link
> with no router at all. Or clarification.
The above is not clear to me. You could find all 'WHAT'?
> > Hence, to determine the need of a further configuration, a
> > host needs to check at least that:
> >
> > 1) Whether it knows a (partially) reachable default router.
>
> I don't think this is true unless you add on a new link.
A host is under uncertainty. It doesn't know whether a link change happened or not.
> > 2) Whether it possesses a valid IP address.
>
> If it is on a new link it does not and it is on a new link then it hears
> the Ras.
ditto. :-)
> The key is the host knowing its link. Some can argue because link
> prefixes cannot be duplicated the chance of not knowing is very slim
> because a host can hear all prefixes and it is the case of them changing
> very rapidly is the problem. That is why an option to send all prefixes
> is a good thing to pursue.
I see.
> > Partial reachability indicates that the host is able to receive
> > packets from the router, but not necessarily vice versa.
>
> Not sure about this. How is this possible. If I can get a packet from
> an address then I can send to an address? Does this need to be worded
> differently or more explanation.
Assume I receive an RA from a new Router. It confirms that I can receive
a packet from the router. But it doesn't confirm the router can receive a packet
from me.
> > To examine the status of the existing configuration, a host may check
> > whether a 'link change' has occurred.
>
> OK so this is layer 2? Or layer 3? Or some API? Needs to be more
> specific or removed.
>
> This is my point we should state the goals not provide a history and
> education other than to say link detection needs further investigation.
I see your point. But IMO, it's useful to provide some history and education
to clarity goals. Let WG decide it. Vox Populi, Vox Dei. :-)
> > Today a link change necessitates an IP configuration change.
> > Whenever the host detects that it has remained at the same link, it
> > can usually assume its IP configuration is still valid.
>
> Not usually but always that is what the timers in stateless or stateful
> are all about. Whats up with that statement?
I had in mind the case of changing APs while staying on the same link with
huge L2 handoff delay, the period between deassociation with an old AP and
reassociation with a new AP. For example, Boeing people are using 4 satellites
around the world to get 5Mbps downlink to the airplanes, and it takes 30sec
for the airplane to handover from one satellite to the other. In such cases, I
thought DAD & NUD is necessary even when a host is attached to the same
link.
> > Otherwise,
> > the existing one is no longer valid and a new configuration must be
> > acquired. Hence a host only needs to check for link change to
> > examine the validity of its IP configuration.
>
> Correct this is fine and almost enough for the introduction in my view.
I see your point.
> > In the process of checking for link change, a host may collect some
> > of the necessary information for a new IP configuration, for example
> > on-link prefixes. So, when an IP subnet change has occurred, a host
> > can immediately initiate the process of getting a new IP
> > configuration. This may reduce handoff delay and minimize signaling.
>
> OK I agree but shouldn't this be part of a solutions section and is this
> a goal?
I thought this as ALSO goal. 'Detecting link identity' is a MUST goal.
This is 'Would be nice" Goal.
> > Rapid attachment detection is required for a device that changes
> > subnet while having on-going sessions. This may be the case if a
> > host is connected intermittently, is a mobile node, or has urgent
> > data to transmit upon attachment to a link.
>
> This is a goal yes.
ok
> > The process by which a host collects the appropriate information,
> > detects the identity of its currently attached link, and ascertains
> > the validity of its IP configuration, is called Detecting Network
> > Attachment (DNA).
>
> This is a goal yes.
ok.
> > It is important to note that DNA process does not include the actual
> > IP configuration procedure. For example, with respect to DHCP, the
> > DNA process may determine that the host needs to get some
> > configuration information from a DHCP server. However, the process
> > of actually retrieving the information from a DHCP server falls
> > beyond the scope of DNA.
>
> OK this is a non-goal.
ok
> > 2. Detecting Network Attachment in Existing IPv6 Systems
> >
> > When a host changes its attachment point, for efficiency, a host
> > should examine whether its IP configuration is still valid before
> > initiating the process of acquiring a new IP configuration.
>
> OK now we are in the solution space not goals.
I see. You want this removed?
> > DNA process aims to examine whether a host's current IP
> > configuration
> > is still valid. To achieve this goal, DNA process checks
> > whether the
> > host is still at the same link. Also, DNA process
> > collects necessary
> > information for a new IP configuration.
>
> This is an algorithm suggestion not a goal.
The above is just a rephrasing of the below.
The process by which a host collects the appropriate information,
detects the identity of its currently attached link, and ascertains
the validity of its IP configuration, is called Detecting Network
Attachment (DNA).
> > For this, the following mechanisms and data are available to hosts:
> >
> > 1) Router Solicitation/Router Advertisement (RS/RA) messages
> > 2) Neighbor Solicitation/Neighbor Advertisement (NS/NA) messages
> > 3) Information provided by the link-layer
>
> Ditto.
I see your point.
> > Currently there is no way to represent the identity of links such
> > that link changes can be detected instantly. The information in the
> > above messages cannot be used to unambiguously identify links.
> > Section 3 gives the detail.
>
> This is not a goal. I don't agree with #3 if I know at #3 my link is
> changed then RS/RA/NS/NA are all on the new link.
Host can't decide whether it moves to a new link or not by receiving
just a single RA (or NA).
> > Though the set of all the assigned prefixes may be used to represent
> > a link identity, it is difficult for a host to attain and retain all
> > the prefixes with certainty. Moreover there may be links without
> > any advertised prefix.
>
> Turn the above into a goal and suggest things to look for in the goals.
This is the current state of art.
> > Hence, to check for link change, as of today, a host must resort to
> > guessing, based on Router Discovery and Neighbor Unreachability
> > Detection (NUD). A host can examines whether 1) its existing default
> > router is still reachable and 2) its IP addresses are still valid.
>
> I can know I am on a new link from the link layer and physical layer for
> WiFi, 3G, etc..Ethernet MACs are new. The answer could be a new field
> in those layers and maybe we should look at that and talk with IEEE?
I think the difference of link definition results in the above difference of opinions.
In WiFi, the link layer can notify the identity of the current link-layer connection,
maybe BSS, but can't indicate the identity of a currently attached link.
> > After a network attachment, a host receives new (solicited or
> > unsolicited) RAs and compares them with the previously received ones.
> > It checks whether the information in the new RAs, the prefixes and
> > the router addresses, matches with the stored ones, the configured IP
> > addresses and the default router addresses.
>
> This is solution not a goal.
This is the existing DNA scheme and not a proposed solution.
> Ditto on the rest of the section it is not goals.
I agree that it's not goals. But I think they are useful for goals description.
> > 3.1 Wireless link properties
> >
> > 1) Unclear boundary
> >
> > Unlike wired environments, what constitutes wireless link is variable
> > in both time and space. It doesn't have clear boundaries.
> > This may
> > be illustrated by the fact that a host may contact
> > multiple (802.11)
> > access points at the same time. Moreover reachability on
> > a wireless
> > link is very volatile, which may make link detection hard.
>
> Any device is aware of which wireless net is attached to and that data
> is available so I am unclear the statements above are valid? I also do
> not agree link detection is hard.
In Wireless environment, a host may ping-poing between two links rapidly.
In that case, a host will have difficulty.
> > 2) Asymmetric reachability
> >
> > In some wireless environments, it may be possible to receive
> > periodically multicast advertisement information without being able
> > to send IP packets to the network. In these cases, it is
> > insufficient to rely upon reception of unsolicited advertisement
> > information as confirmation of router reachability.
>
> This is old and not the norm. It also applies to radio more than say
> WiFi and current medias.
I see.
> > 3.2 Inadequacies in RA information
> >
> > Usually a host receives the information necessary for IP
> > configuration from RA messages. Based on the current definition [4],
> > the information contained in RA messages is inadequate to represent a
> > link change. RA messages are not designed to represent link
> > identities and have inherent ambiguities.
>
> This has nothing to do with Goals and a podium to present one view.
> RA's are not to represent link change so lets make one.
> But this is a goals document.
DNA Goal is to 'detect a link identity'. Isn't it useful to write that an RA
can't indicate a link identity?
> > 1) Link local scope of Router Address
> >
> > Usually a router address is contained in the source address field of
> > RA messages. That router address is link-local scope and its
> > uniqueness can't be guaranteed out side of a link.
> >
> > So if it happens that two different router interfaces have the same
> > link-local address, a host can't detect that it has moved from one
> > interface to another by checking the router address in RA messages.
> >
> > On the other hand, a host can't be sure that its default router is
> > reachable, even if it can communicate with the router that has the
> > same address as its existing router address. That router may be a
> > different one, which happens to have the same link-local address as
> > its default router address.
>
> We can require that the router use non-link local addresses with a
> prefix and those cannot be duplicated across the links. I am not
> advocating that but the above statement is not entirely honest or tells
> the whole story and also again not a goal.
The above is about the existing problem of link-local scope of router
address.
> > 2) Omission of Prefix Information Option
> >
> > To check the validity of its IP address, a host should examine
> > whether the prefix of its IP address is advertised on the link to
> > which it is currently attached.
> >
> > The host checks whether the prefix of its IP addresses are present in
> > the Prefix Information Option of incoming RA messages. But an
> > unsolicited RA message can omit some prefixes for convenience, for
> > example to save bandwidth [4].
>
> So we fix that in RA's or add new RA fro mobile nodes.
Under current standard, hosts can't be 100% sure that it knows all the
prefixes, even if it does. That uncertainty results in the uncertain address
validity determination.
> > Hence, the host can't be sure that the prefix of its current IP
> > address is not supported on the current link, even though the prefix
> > is not contained in a received RA.
> >
> > 3.3 Delays
> >
> > The following issues cause DNA delay that may result in communication
> > disruption.
> >
> > 1) Delay for receiving a hint
>
> What type of hint and where is the delay at driver interrupt, IP queue,
> upto TCP or UDP in the stack? This is a bold and not well defended
> statement as is at all.
Hint doesn't exclusively mean link-layer hint, the indication from the link
layer. In below, I described the reason of delay for each hint.
> > For rapid attachment detection, hints can be used to tell a host that
> > a link change might have happened. This hint itself doesn't confirm
> > a link change, but can be used to initiate the appropriate
> > procedures.
>
> Correct but lets go look at the IEEE properties of each link media first
> and be sure.
There are hints from L3.
> > Hints come in various forms, and differ in how they indicate a new
> > attachment. They can be link-layer indications, the lack of RA from
> > the default router or the receipt of a new RA. The time taken to
> > receive a hint also varies.
> >
> > As soon as a new link-layer connection has been made, the link-layer
> > may send a link up notification to the IP layer. A host may
> > interpret a new network attachment as a hint for a possible link
> > change. With link-layer support, a host can receive a hint almost
> > instantly.
>
> Correct and flush its caches.
I see.
> > [9] defines the use of RA Interval Timer expiry for a hint. A host
> > keeps monitoring periodic RAs and interprets the lack of them as a
> > hint. It may implement its own policy to determine the number of
> > missing RAs for a hint. Hence the delay depends on the Router
> > Advertisement interval.
> >
> > Without the schemes such as above, a host must receive a new RA from
> > a new router to detect a possible link change. The detection time
> > then also depends on the Router advertisement frequency.
> >
> > Periodic RA beaconing transmits packets within an interval varying
> > randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds.
> > Because a network attachment is unrelated to the advertisement time
> > on the new link, the host is expected to arrive on average half way
> > through the interval. This is approximately 1.75 seconds with [4]
> > advertisement rates.
> >
> > 2) Delay for checking current default router Unreachability
> >
> > When a host examines the reachability of the current
> > default router,
> > a certain delay occurs if the current default router is not
> > reachable.
> >
> > Usually it's easier to detect a node's presence than its
> > absence. A
> > host sends a solicitation message and, upon the receipt of a reply,
> > it can assume that it's there.
> >
> > To be sure that a node is absent, time needs to be taken to ensure
> > that the lack of a reply is not due to another reasons
> > (for example, packet loss, MAC latency, or processing delay). So it
> > takes time to
> > verify the unreachability of the current router.
> >
> > After a host moves to another link, if it uses NUD for
> > detection, it
> > will take more than 3 seconds to recognize that the
> > current router is
> > no longer reachable [4].
>
> That is configurable.
You mean you can configure a host to perform NUD less than 3 secs?
> > 3) Random delay execution for RS/ RA exchange
> >
> > Router Solicitation and Router Advertisement messages are used for
> > Router Discovery. According to [4], it is sometimes
> > necessary for a
> > host to wait a random amount of time to send an RS and for a router
> > to wait to reply an RA.
> >
> > Before a host sends an initial solicitation, it SHOULD delay the
> > transmission for a random amount of time between 0 and
> > MAX_RTR_SOLICITATION_DELAY (1 second). Also Router Advertisements
> > sent in response to a Router Solicitation MUST be delayed
> > by a random
> > time between 0 and MAX_RA_DELAY_TIME (0.5 seconds).
>
> This is configurable.
Configurable under RFC 2461?
> > 4. Goals for Detecting Network Attachment
> >
> > DNA solutions should be 1) Precise, 2) Sufficiently fast and 3) Of
> > limited signaling. The solutions should correctly
> > determine whether
> > a link change has occurred. They also should be sufficiently fast
> > lest there should be service disruption. They should not flood the
> > link with related signaling.
> >
> > It will be necessary to investigate the usage of available
> > tools, NS/
> > NA messages, RS/RA messages, link-layer hints and other features.
> > This will allow precise description of procedures for efficient DNA
> > Schemes.
> >
> > 4.1 Goals list
> >
> > G1 DNA schemes should detect the identity of the currently attached
> > link to ascertain the validity of the existing IP configuration.
> > They should recognize and determine whether a link change has
> > occurred and initiate the process of acquiring a new
> > configuration
> > if necessary.
> >
> > G2 When upper-layer protocol sessions are being supported, DNA
> > schemes should detect the identity of an attached link rapidly,
> > with minimal latency.
> >
> > G3 In the case where a host has not changed a link or subnet, an IP
> > configuration change should not occur.
> >
> > G4 DNA schemes should not cause undue signaling on a link.
> >
> > G5 DNA schemes should make use of existing signaling
> > mechanisms where
> > available.
> >
> > G6 DNA schemes should make use of signaling within the link
> > (particularly link-local scope messages), since communication
> > off-link may not be achievable in the case of a link change.
> >
> > G7 DNA schemes should be compatible with security schemes such as
> > Secure Neighbour Discovery [8] and IPSec [7].
> >
> > G8 A host configured for DNA should not expose itself to additional
> > man in the middle or identity revealing attacks.
> >
> > G9 A host or router configured for DNA should not expose itself or
> > other devices on the link to additional denial of
> > service attacks.
> >
> > G10 The Routers supporting DNA should work appropriately with hosts
> > using unmodified configuration schemes, such as [4] and [6].
> >
> > G11 The Hosts supporting DNA should be able to work with unmodified
> > routers and hosts which do not support DNA schemes.
>
> The above is the list of goals we should be debating not all the upfront
> opinions and text. That is second step after the goals.
That part is about the existing schemes, not the proposed solutions.
Thanks for your taking trouble to provide feedback. It made things clearer for me.
Best Regards
JinHyeock