Subject: [dhcwg] Proposed Resolution to DNA Issue 25: "Link Up" not defined

From: Bernard Aboba <[email-masked]>
Date: Wed, 1 Jun 2005 17:49:37 -0700 (PDT)

The text of DNA Issue 25 (submitted during IETF Last Call) is included
below.  This and other DNA issues are available for inspection here:
http://www.drizzle.com/~aboba/DNA/

The proposed resolution is as follows:

"Link Down
An event provided by the link layer that signifies a state change
associated with the interface no longer being capable of
communicating IP packets. A Link Down event is only generated once
the link layer considers the link unusable; transient periods of
high frame loss are not sufficient. DNAv4 does not utilize "Link
Down" indications.

Link Up
An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating IP
packets."

------------------------------------------------------------------------
Issue 25: Link Up Not Defined
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: May 23, 2005
Reference:
Document: DNA-11
Comment type: T
Priority: S
Section: 1.2
Rationale/Explanation of issue:

Recently, in a liaison letter from IEEE 802.21, some questions were raised
about the use of the terms "Link Up" and "Link Down".

To ensure we had this right in in the DNA document, I went in search of
definitions
of these terms. However, I could not find a definition in the following
documents:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt
http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-dna-soln-frame-00.txt
http://www.watersprings.org/pub/id/draft-yamamoto-dna-term-00.txt

This struck me as more than a little odd, particularly when I found myself
asking basic questions about the meaning of these terms.

For example, in wireless communications link quality can be highly
transient; when multi-path interference is present, the S/N ratio can dip
20-30 dB within the space of a few feet.

In a wired network, the "up" link state is one exhibiting very low
frame loss, whereas the "down" state is one exhibiting 100 percent loss.
It is therefore clear when a link transitions from "down" to "up"; a
"Link Up" event is sent upon this transition. Similarly, it is clear
when a link transitions from "up" to "down" and a "Link Down" event
is sent upon this transition.

However, on a wireless network, intermediate frame loss rates are often
observed, so that links may be neither "up" nor "down" according to the
idealized definition. In this case, when are "Link Up" and "Link Down"
events sent?

Does the term "Link Up" refer to an event that only occurs when a link
has entered a link layer protocol state associated with the
initial ability to handle IP traffic? For example, within PPP does a
"Link Up" event only occur after the completion of IPCP negotiation?
Or in 802.11i, only after completion of the 4-way handshake?

Or can a "Link Up" event occur when a STA wanders out of range of an
access point, retransmits packets multiple times without a response,
scans, and then returns within range of the same AP, all without
changing state within the link layer state machine? In this scenario,
is a "Link Down" event also sent?

Similarly, does "Link Down" refer only to an event that occurs when a link
has entered a link layer protocol state that is not associated with the
ability to handle IP traffic? For example, in PPP a "Link Down" event
is presumably sent on receipt of an LCP-Terminate; in 802.11, a
Disassociate or Deauthenticate frame might trigger a "Link Down" event.

But can a "Link Down" event also be sent due to a transient decline in
link quality? For example, can this event be sent when a host wanders
out of range and retransmits a frame until it gives up? Or is a more
substantial outage required, affecting several distinct frames? In
other words, is a "Link Down" event, unlike a "Link Up" event, affected
by link quality?

I ask these questions because it seems to me that the precise definition
of these events may determine whether they are likely to be spurious, as
well as whether they arrive in a timely way.

For example, I have observed 802.11 NICs that will retransmit a lost frame
for >30 seconds after an AP is turned off before scanning for another
point of attachment. I have observed other NICs that will begin to scan
after two retransmissions.

[Jim Busse]

Historically, a lot of IETF documents use "link up" as triggers for other
events, without defining the meaning of "link up" state. Scary.

Sun defines the "link up" state on an ethernet device as the result of the
link meeting a basic set of tunable parameters. These statistics determine
when the Sun OS sets the "link up" state. Sun docs reprinted here without
permission....

"When auto-negotiation is enabled, the adv_*_cap statistics show which
capabilities are advertised to the link partner. When auto-negotiation is
disabled in forced mode, the statistics precisely show how a link should
function and that it must be matched on the link partner to achieve a
valid
link up.

"The lp_cap_* parameters exist as kernel statistics for an Ethernet
device. The statistics are the advertised capabilities provided by the
link partner on completion of auto-negotiation. If the capabilities match
the capabilities provided in the local advertisement, the link can proceed
to a link up state. If no match is found, the link remains down. In two
other instances, lp_cap_* values might all be zero: when a cable is not
present, when forced mode is enabled."

Microsoft and Apple may have similar definitions, but I couldn't find any
in my MS references or on-line. I don't know how to look at Apple stuff...
:-(

There are a couple of instances of Link Up definition in other IETF docs,
but the definitions are pretty loose:

>From draft-pentland-dna-protocol-00.txt

DNAv6 assumes that the host's wireless link interface software and
hardware is capable of delivering a 'link up' event notification when
layer 2 on the host is configured and sufficiently stable for IP
traffic. "

Link down is not defined in that document.

>From draft-jung-mobileip-fastho-chain-00.txt

"two simple triggers of Layer 2 are required. One is the Link Up trigger.
MN or new AR receive the Link Up trigger when the MN arrives on the link
with the new AR. "

I'm not sure if the definition of "link up" and "link down" states are
within the scope of the DNA charter. I think the OS determines whether the
link is stable enough to perform the duties required by the OS, and is
therefore an OS construct, not a DNA construct.

[Tom Petch]

The terms have been in use by the IETF since at least RFC1157 (May 1990)
and while I have seen no formal definition in that or subsequent
documents, manufacturers have shown fair consensus on the meaning, about
the ability to send an IP packet. The beauty of IP being an unreliable
network is linkUp tells you nothing about what happens to the packet after
it has left the box, only that nothing stopped it leaving:-)

[Erik Nordmark]

If we are trying to solve the DNA issue, and ignore that hosts might
have multiple NICs, then we can come up with what we need operationally.
My take is that this should be sufficient:
They layer 2 probably has some internal set of states at which it is
known that no IP packets can be passed. Thus the loss probability is
100% due to the state at the driver/NIC/AP/whatever.

For DNAs purposes it is useful to get a 'link up' notification from L2
when L2 moves out of the state(s) where no IP packets are passed.
Likewise, if DNA needs a 'link down' notification, it is probably most
useful for DNA if that notification arrives when L2 moves from a state
where IP packets might be passed, to a state where they are guaranteed
to not pass. We do need to ensure that at least a 'link up' notification
is generated when the L2 connectivity changes, even if that change is
near instantaneous (quickly unplugging the Ethernet cable and plugging
one back in again; associating with an 802.11 AP even if the old AP was
believed to still be reachable).

With the above definitions we'll minimize what DNA would consider
spurious notifications just because of signal strength, yet never miss
the case when the layer 3 link is different.

That is the simple case.
Enter multihoming (multi-NICcing if you'd like)...

When a host has multiple NICs there might be any number of policy
related ways the host wants to choose. This could be based on a
combination of signal strength, "flakiness history", cost, and it might
be different for different applications running on the same host.
I think that is out of scope for DNA, but it probably makes sense to
explicitly mention it in the context of the L2 event notifications,
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.

[Bernard Aboba]

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.

[Erik Nordmark] Agree 100%.

[Alper Yergin]

http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt

We have the definitions as:

Node's establishment of a link-layer connection with an attachment
point that signifies the availability of IP service (i.e., being able
to send and receive IP packets) between the two is considered a link
up event.

Link down event signifies the discontinuation of the IP service
between the node and the attachment point. When the link-layer
connection is physically or logically torn down and it can no longer
carry IP packets, this is considered to be a link down event.

> Does the term "Link Up" refer to an event that only occurs when a link
> has entered a link layer protocol state associated with the
> initial ability to handle IP traffic?

Yes. This event should be associated with a state transition within the
L2. In the new state, the L2 should be willing to accept IP packets from
L3, and look for an opportunity to transmit them. (as opposed to
returning an immediate error message stating the request cannot be
fulfilled -- interface is down, IP service not available, etc.)

> For example, within PPP does a
> "Link Up" event only occur after the completion of IPCP negotiation?
> Or in 802.11i, only after completion of the 4-way handshake?

Yes and yes, as we stated in the dna-link-info I-D.

> Or can a "Link Up" event occur when a STA wanders out of range of an
> access point, retransmits packets multiple times without a response,
> scans, and then returns within range of the same AP, all without
> changing state within the link layer state machine? In this scenario,
> is a "Link Down" event also sent?

I don't think so.

> Similarly, does "Link Down" refer only to an event that occurs when a
link
> has entered a link layer protocol state that is not associated with the
> ability to handle IP traffic? For example, in PPP a "Link Down" event
> is presumably sent on receipt of an LCP-Terminate; in 802.11, a
> Disassociate or Deauthenticate frame might trigger a "Link Down"
event.

Yes, we covered those in the same I-D as well.

> But can a "Link Down" event also be sent due to a transient decline in
> link quality? For example, can this event be sent when a host wanders
> out of range and retransmits a frame until it gives up? Or is a more
> substantial outage required, affecting several distinct frames? In
> other words, is a "Link Down" event, unlike a "Link Up" event, affected
> by link quality?

Eventually a continued "low quality" may lead to the L2 deciding a state
change that leads to a "link down", but this is a L2 design and
implementation decision.

> For example, I have observed 802.11 NICs that will retransmit a lost
frame
> for >30 seconds after an AP is turned off before scanning for another
> point of attachment. I have observed other NICs that will begin to scan
> after two retransmissions.

I think this is a L2 implementation issue. At what point the L2 decides
that it has lost its connection to an access network.

[Bernard Aboba]

Using Alper's definition as a starting point, here a proposed definition
of "Link Down" and "Link Up". What do people think?

Link Down
An event provided by the link layer that signifies that the link is
no longer capable of communicating IP packets.

Link Up
An event provided by the link layer that signifies that the link
has become capable of communicating IP packets.

[Brett Pentland]

Works for me. My only concern would be about what would happen if an L2
technology comes along that can move its attachment point without any
intermediate period of disconnection, perhaps through some out-of-band
pre-establishmment of the new connection (and it would be good if such a
technology did!).

Perhaps it would just be a matter of using these definitions, but
ensuring that a transition like above causes a matched pair of Link Down
/ Link Up events to be generated.

As an aside: for draft-pentland-dna-solution-00 we only really
considered Link Up, because that is the point at which the network
layer on that interface is able to take some action (sending an RS, in
this case, to find out what the Link Up means). Link Down is probably
useful for coordinating between multiple interfaces, as are some of
the events that might be able to be triggered by the intermediate
connectivity situations that you described, but that is outside the
scope of what we tried to achieve in the proposal.

[Erik Nordmark]

I think it would be good if the definitions would clarify that even if
the link layer on the host sees 100% packet loss for a short while, it
doesn't necessarily imply that a link down event should be generated.
(It presumably shouldn't be generated until the link layer abandons the
L2 association/connection/whatever.)

[Brett Pentland] How about:

Link Down
An event provided by the link layer that signifies a state change
associated with the interface no longer being capable of
communicating IP packets.

Link Up
An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating
IP packets.

[Erik Nordmark]

I think it would be good if the definitions would clarify that even if
the link layer on the host sees 100% packet loss for a short while, it
doesn't necessarily imply that a link down event should be generated.
(It presumably shouldn't be generated until the link layer abandons the
L2 association/connection/whatever.)

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg