Re: [DNA] Definition of "Link Up" and "Link Down" events?

[James Kempf <kempf@docomolabs-usa.com>]

> > As a practical matter, I think the definition of Link Up for DNA is: is
it
> > now possible to push an IP packet across the link? And the definition of
> > link down is: is it now not possible to push an IP packet across the
link?
>
> I would suggest that there is an important distinction between "the link
> layer state is now such that IP transport is permitted" versus "at this
> moment, the link quality is such that communication is likely to be
> successful."  The former is typically well defined within a link layer,
> whereas the latter is a matter of judgement.  My belief is that "Link Up"
> only reflects the former but not the latter consideration.
>

Agree.

> > The details of what constitutes acceptable link
> > quality to rule that an IP packet can be pushed across the link are
likely
> > to be different for UWB than for Super 3G or 802.16 from a radio
technical
> > standpoint.
>
> Yes, but that will eventually be reflected in a state transition within
> the link layer state machine.
>

But is this really of concern to IP? The IP layer just wants to know whether
or not the link layer thinks there's a high probability of getting a packet
across. The details of how that's done are indeed part of the state machine
in the driver, but are they of any concern to the IP stack?


> > Actually, it is quite vital and I would expect that any
> > radio link specification would have that kind of information available
for
> > the packet data service.
>
> Yes, but that may be considered separately from "Link Up" and "Link Down"
> indications.  For example, a link may have made a transition to a state in
> which IP packet transmission is permitted, yet extensive frame loss may be
> observed.  Such a link may provide information on the frame loss to upper
> layers which may affect routing metrics, but it does not send a "Link
> Down" indication until the loss is sufficiently persistent to cause the
> link layer state machine to transition.
>

Right, that's what I was trying to get at with the statement on policy. In
the case you've cited, the NIC policy is that extensive frame loss is not
sufficient to trigger a "Link Down". That might not always be the case, for
example, other NIC cards might have different policies, or the policy might
be configurable.

> > If the WG can arrive at a concensus definition of Link Up and Link Down
for
> > DNA, do you think it would be worthwhile writing it down, possibly in
the
> > solution framework document?
>
> There was a terminology document at one point, so that might be the best
> place to include it.  However, it also seems necessary to include that
> definition in other places which use the term, such as the DNAv4 document.
>

OK.

>> saying that the host implementation can benefit from finding out about
>> significant changes in signal strength, observed L2 retransmissions,
>> etc., as some of the inputs to the hosts policy choices.
>
>Sure, but I'd suggest that we should be clear that this additional info is
>not a determinant of "Link Up" and "Link Down" events.

Hmm, what about the case where 802.1x authentication must complete prior to
"Link Up"? That has nothing whatsoever to do with the quality of the link
from a frame transmission standpoint?

        jak