Subject: [DNA] Interactions with DHCPv6

From: Brett Pentland <[email-masked]>
Date: Sat, 21 May 2005 12:20:35 +1000

Hi folks,

Section 18.1.2 of RFC 3315 (DHCPv6) contains a DNA procedure.
How this interacts with any proposed solution for DNA
(including the BCP documents) needs to be considered.

The DT has started discussing this over the last day or so
and I have pasted that thread into an issue with the
proposal we submitted a few weeks ago.  This can be found at:

http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASoln1Issue017

All comment appreciated.
Cheers,
Brett.

---

From: James Kempf <[email-masked]>
Date: Mon, 23 May 2005 09:17:37 -0700

Hi Brett,

I can't think of any case where CONFIRM would come up with a diffferent
answer from DNA.

I think the DNA spec ought to say that DHCP CONFIRM isn't necessary if DNA
confirms that the host is still on-link. Unfortunately, RFC 3315 says MUST,
so the statement will probably have to be phrased as SHOULD or MAY until the
DHCP spec changed is changed.

            jak

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 May 2005 23:33:33 -0700 (PDT)

Recently, in a liaison letter from IEEE 802.21, some questions were raised
about the use of the terms "Link Up" and "Link Down" within
draft-iab-link-indications-01.txt.

In revising the document, I went about 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.

---

From: James Kempf <[email-masked]>
Date: Tue, 24 May 2005 09:34:56 -0700

Bernard,

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?
Given the diversity of link technologies, I think that is really all one can
say from the IP layer. 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. In addition, there are likely to be other policy matters - how
the radio transport is used (like, for example, actual number of ARQs v.s.
the maximum number, which is typically in the radio link standard), whether
reauthorization is required on handover, etc. - that can differ even between
two different terminals utilizing the same transport, or even two of the
same terminals talking to two different wireless service providers.

That said, I'm not saying that defining exactly what constitutes acceptable
link quality for a particular radio transport isn't an interesting and
important problem. 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.

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?

            jak

---

From: Jim Busse <[email-masked]>
Date: Tue, 24 May 2005 10:51:22 -0700

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.

Best regards

Jim Busse

---

From: Tom Petch <[email-masked]>
Date: Tue, 24 May 2005 19:23:24 +0200

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

Tom Petch

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 24 May 2005 12:15:33 -0700

> idealized definition.  In this case, when are "Link Up" and "Link Down"

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.

    Erik

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 May 2005 13:28:05 -0700 (PDT)

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

> The details of what constitutes acceptable link
> standpoint.

Yes, but that will eventually be reflected in a state transition within
the link layer state machine.

> Actually, it is quite vital and I would expect that any

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.

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 May 2005 13:43:41 -0700 (PDT)

> the case when the layer 3 link is different.

Yes, I think that is a reasonable approach.

> related ways the host wants to choose.

I think it's important to distinguish what choices we are talking about.
If we are talking about choosing which NIC to transmit on, that is
influenced by a variety of factors such as routing metrics, Strong/Weak
host model.  So link indications only influence this to the extent that
they are taken into account within the routing metrics.  Just because a
link is not preferred in terms of routing to a particular destination
prefix does not mean it is "down".

If we are talking about the decision to bring a link up or down (e.g.
"dial in demand" or "idle timeout") that is a different decision.  I'd
argue that "Link Up" or "Link Down" events are the consequence of these
decisions.

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

"Cost" and "flakiness history" (frame loss) have in the past been
incorporated into routing metrics, whereas signal strength has been used
in the decision about whether to bring a link up, since in these
circumstances frame loss cannot yet be observed.

In most implementations all applications share the same routing
table and interfaces, and the decision to bring links "up" or "down" is
typically handled below the application, which makes the decision on which
interface(s) to bind to.

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 24 May 2005 13:49:43 -0700

> not a determinant of "Link Up" and "Link Down" events.

Agree 100%.

    Erik

---

From: James Kempf <[email-masked]>
Date: Tue, 24 May 2005 14:50:07 -0700

> only reflects the former but not the latter consideration.

Agree.

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

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

> definition in other places which use the term, such as the DNAv4 document.

OK.

>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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 24 May 2005 15:04:59 -0700

Hi Bernard,

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

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.

> 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

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

> is a "Link Down" event also sent?

I don't think so.

> Disassociate or Deauthenticate frame might trigger a "Link Down"
event.

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

> other words, is a "Link Down" event, unlike a "Link Up" event,
affected

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. 

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

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 May 2005 15:37:16 -0700 (PDT)

> in the driver, but are they of any concern to the IP stack?

"High probability" is different from "the link layer is in a state where
IP packet transmission is not possible".  The former depends on link
quality, whereas the latter depends on the link layer state machine.  As a
result, the former is likely to be highly transient, while the latter is
likely to be less so.

> example, other NIC cards might have different policies, or the policy might

Experiments do indicate that NICs behave quite differently, and some of
that difference is due to different approaches taken by reasonable
implementations as opposed to obviously broken behavior.   For example,
better 802.11 NIC implementations start scanning after only a few
retransmissions (~3) since 3 consecutive lost frames is unlikely to be
caused by collisions.  These implementations still obey the 802.11
default shortretrylimit (7) so they continue retransmitting
even as the NIC is interleaving scans to find another potential point
of attachment.  In most cases a "Link Down" is not signalled unless
frame loss continues and another suitable AP cannot be found within the
ESS.

> from a frame transmission standpoint?

Since EAP supports retransmission, and on 802.11 802.1X frames are sent to
a unicast address, it is possible for 802.1X authentication to complete
even in situations where there is high frame loss.  So it is possible for
an 802.11i link to reach the "Link Up" state even though link quality is
poor.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 May 2005 15:40:44 -0700 (PDT)

>    to send and receive IP packets) between the two is considered a link

Does this preclude "Link Up" from being sent on a uni-directional link?
In other words, must the link layer demonstrate bi-directional
reachability prior to sending a "Link Up" event?

>    carry IP packets, this is considered to be a link down event.

This seems compatible with existing usage and some of the previous
discussion.

> > is a "Link Down" event also sent?

I would agree.

> change that leads to a "link down", but this is a L2 design and

Agree that the operative term is "eventually" (e.g. link layer state
transition).

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 May 2005 15:59:31 -0700 (PDT)

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.

---

From: James Kempf <[email-masked]>
Date: Tue, 24 May 2005 16:08:59 -0700

> result, the former is likely to be highly transient, while the latter is

Ok,  so is ~(IP packet transmission not possible) == (IP packet transmission
possible)? From your previous emails, I have the impression that you think
this is an oversimplification, is that right?

> an 802.11i link to reach the "Link Up" state even though link quality is

From the IP stack's standpoint, "Link Up" on a link where 802.1x is required
means: "802.1x is complete and the controlled port is now open for traffic".
Even if the link is of stellar quality, the IP stack can't get any packets
out prior to that. If the state is: "802.1x is complete and has failed, the
controlled port is closed" means the link is still down. This particular
state transition has nothing to do with the link quality, from the IP
stack's viewpoint, even though the transition of the state machine regarding
 whether frames can successfully get across the link does affect whether or
not 802.1x completes.

If 802.1x is not required on the link, then the transition of interest to
the IP stack is controlled by the link quality alone.

So my point was, link quality is not the only factor that influences whether
the driver can report "Link Up" to the IP stack. Sorry for being not clear.

            jak

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 May 2005 16:45:18 -0700 (PDT)

> this is an oversimplification, is that right?

IP packet transmission "possible" is an indication that the link
layer will accept an IP packet for transmission.  Whether it actually
arrives depends on the link quality.

Where we have perhaps over-simplified is in assuming that links are either
"up" or "down" in terms of their frame loss (e.g. either low loss or high
loss in both directions).  In some cases (e.g. outdoor mesh networks) the
data shows that links can be in intermediate states as well as exhibiting
considerable asymmetry.

However, those over-simplifications won't affect DNA as long as our definition
of "Link Up" is not dependent on frame loss.  However, it is not
clear to me that other "link indications" are as robust.  For
example, are indications such as "Link Going Down" dependent on frame
loss, are they indicative of a decision to bring the link down?

---

From: Alper Yegin <[email-masked]>
Date: Tue, 24 May 2005 16:50:37 -0700

> reachability prior to sending a "Link Up" event?

We haven't really considered uni-directional links... Hmmm, should DNA
deal with that?

Assuming we are only talking about bi-directional links, I presume the
reachability test would be performed implicitly (e.g., 4-way handshake)
or explicitly by the L2. 

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 May 2005 17:07:33 -0700 (PDT)

> We haven't really considered uni-directional links... Hmmm, should DNA

I'm not suggesting that DNA deal with this -- but I don't think that the
"Link Up" event depends on demonstration of bi-directional connectivity,
just on reaching a link layer state where "IP packet communication" is
enabled.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 24 May 2005 18:12:25 -0700

>      has become capable of communicating IP packets.

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

    Erik

---

From: Brett Pentland <[email-masked]>
Date: Wed, 25 May 2005 11:23:14 +1000

>      has become capable of communicating IP packets.

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.

Brett.

---

From: Brett Pentland <[email-masked]>
Date: Wed, 25 May 2005 11:27:59 +1000

> L2 association/connection/whatever.)

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.

Brett.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 May 2005 05:57:49 -0700 (PDT)

>       associated with the interface becoming capable of communicating

Looks good.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 May 2005 06:06:26 -0700 (PDT)

Here is the revised terminology section for DNAv4 (ARP terms left out for
brevity).  Comments welcome.

DHCP client
     A DHCP client or "client" is an Internet host using the Dynamic
     Host Configuration protocol (DHCP) [RFC2131] to obtain
     configuration parameters such as a network address.

DHCP server
     A DHCP server or "server" is an Internet host that returns
     configuration parameters to DHCP clients.

Attachment Point
     The link endpoint on the link to which the host is currently
     connected.

Link
     A communication facility or medium over which network nodes can
     communicate.  Each link is associated with a minimum of two
     endpoints.  Each link endpoint has a unique link-layer identifier.

Link Down

Link Layer
     Conceptual layer of control or processing logic that is responsible
     for maintaining control of the data link.  The data link layer
     functions provide an interface between the higher-layer logic and
     the data link.  The link layer is the layer immediately below IP.

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

Most Likely Attachment Network (MLAN)
     The attached network heuristically determined by the host to be
     most likely, based on hints.

Routable address
     In this specification, the term "routable address" refers to any
     address other than an IPv4 Link-Local address.  This includes
     private addresses as specified in [RFC1918].

Valid address
     In this specification, the term "valid address" refers to either a
     static IPv4 address, or an address assigned via DHCPv4 which has
     not been relinquished, and whose lease has not yet expired.

---

From: James Kempf <[email-masked]>
Date: Wed, 25 May 2005 08:38:03 -0700

Sounds good to me.

            jak

---

From: James Kempf <[email-masked]>
Date: Wed, 25 May 2005 08:55:48 -0700

> arrives depends on the link quality.

I agree that an indication from the link that it is "up" and ready to accept
IP traffic is no guarantee that the packet will be transmitted. The IP layer
also needs to exercise some control if packet loss becomes unacceptably
high, perhaps by switching to another interface, or triggering a handover on
the interface where packet loss is high if the driver allows IP level
handover triggering.

> loss, are they indicative of a decision to bring the link down?

I interpret "Link Going Down" to mean that the mobile node and base station
have begun some procedure to initiate handover. In cellular protocols, there
is extensive negotiation between the mobile node and base station prior to a
handover. 802.16e also has this characteristic. An indication of "Link Going
Down" on such a protocol would mean that negotiation has begun for handover
and, at some short time in the future (perhaps indeterminate), packets will
no longer be accepted for transmission. For 802.11, "Link Going Down" is
meaningless because handover is completely controlled by the mobile node,
and the link continues to accept packets until the AP scan interrupts packet
transmission (and even there, I've seen some NICs that interrupt for AP scan
then send a few packets out prior to the reassociation).

            jak

---

From: James Kempf <[email-masked]>
Date: Wed, 25 May 2005 09:08:15 -0700

Brett,

> / Link Up events to be generated.

It really depends on how the L2 software exposes this capability to the IP
stack. In certain sense, this technology already exists with CDMA soft
handover, but the problem is that the driver does not expose the outstanding
soft handover legs to the IP layer. The soft handover legs look like a
single link from the IP layer's perspective, and are handled as such by the
network.

I think Flarion's OFDM also allows the terminal to have outstanding links to
two base stations at a time, but I do not know how these are exposed to the
IP stack. I believe they use the forward link (to the new base station) to
perform Mobile IPv4 CoA registration while still receiving packets on the
backward link (to the old base station).

If the L2 software hides the L2 handover latency, then "Link Up" and Link
Down" never occur during handover, although they may occur at other times,
for example, if the terminal moves out of range of any base stations.

            jak

---

From: Alper Yegin <[email-masked]>
Date: Wed, 25 May 2005 10:13:52 -0700

>      associated with the interface becoming capable of communicating
IP
>      packets.

I think the main document to define these terms is the "L2 event
notifications for DNA" (dna-link-info) I-D. We could have the DNAv4 and
DNAv6 solution drafts point to it. But since DNAv4 I-D is ahead in the
process, we'd have to include them in that document as well. I'd
recommend adding a reference to dna-link-info for a more detailed
discussions on the link up/down.

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 May 2005 10:49:43 -0700 (PDT)

> have begun some procedure to initiate handover.

It is one thing to have an "idle timeout" feature that will cause a given
interface to be brought down to due to lack of traffic.  This signal
presumably is sent from upper layers to the lower layer.  It is another
thing to have the lower layer predict its future link quality.  Existing
data shows that link quality can be highly variable so that these
predictions are not necessarily very accurate.

> In cellular protocols, there
> no longer be accepted for transmission.
>
> For 802.11, "Link Going Down" is

Agreed.

---

From: James Kempf <[email-masked]>
Date: Wed, 25 May 2005 11:47:59 -0700

Bernard,

> predictions are not necessarily very accurate.

In CDMA, the link quality predictions are very accurate. The host and base
station do closed loop and open loop power control to keep the signal
strength within range so that the signal quality is acceptable. The
standards typically have a minimum power level defined at which the base
station and mobile node initiate handover. After a handover, the power level
for handover is lower to avoid hystersis and ping ponging.

In 802.16 (which is a TDMA protocol), the base station and terminal exchange
link quality information periodically. Also, the terminal can initiate
periodic ranging, in which it starts transmitting at the lowest power and
steps up the power level until it reaches a level at which the signal
quality is optimal to the base station.

I also have heard that 802.11k is supposed to help provide similar
functionality to 802.11, though I have not looked into it.

That said, I think it makes sense to keep the worst case in mind when
designing DNA, and current 802.11 is certainly a candidate for that, as
you've indicated.

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 May 2005 12:03:32 -0700

Brett Pentland wrote:

>> (It presumably shouldn't be generated until the link layer abandons 
>> the L2 association/connection/whatever.)
> 
> 
> How about:
> 
> Link Down

I feel we need to be more explicit about the 100% packet loss case to 
avoid misunderstandings.

    Erik

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 26 May 2005 10:07:47 +0900

Dear Bernard

Let me check whether my understanding is correct, especially 
w.r.t. "link". 

>     endpoints.  Each link endpoint has a unique link-layer identifier.

I'd like to apply the above to the specific example as below.  

Assume there are two 802.11 APs, AP1 and AP2 
and a router R on an ethernet segment as below. 
Also assume a host, H, is attached to AP1. 
(I don't remember how many times I used this one. :-))

                                 +----+ 
                                 |  R  | 
                                 +----+                    
                                   | 
                             +-----+--------+ 
                             |                       | 
                          +----+         +----+ 
                          |AP 1|         |AP 2| 
                          +----+         +----+       

                          +----+         
                          | H  |           
                          +----+         

Then 
1) There is only one link. 
2) AP1 and AP2 are link endpoints of the link.
3) BSSID of each AP is the unique link-layer identifier for link endpoint. 
4) AP1 is the Attachment Point of H. 

Right? 

If so, my concern is that the above may not be clear to the reader, 
I am afraid people may think there are two links in the above example. 
(Either I don't remember how many times this happened. :-() 
These are the words we use for "link" in CPL draft to prevent that. 

                          The term 'link' used in this document is as
   defined in RFC 2461 [1], which is a layer 3 definition.  NOTE that
   that definition is completely different than the definition of the
   term 'link' in IEEE 802 standards.

"Words" by themselves may not be enough for clear terminology 
definition. I think that it would help to provide an example like above. 
 
One more thing, I think it would better to use "Point of Attachment" 
instead of "Attachment Point". 

With "Attachment Point", we could not use an abbreviation because 
usually AP means 802.11 thing. This we belatedly found out while 
writing a draft. With "Point of Attachment", we can use "PoA". 
IEEE 802.21 WG uses the term "Point of Attachment" and its 
abbreviation "PoA" 

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 May 2005 18:20:40 -0700 (PDT)

> IEEE 802.21 WG uses the term "Point of Attachment" and its

OK.  Ideally we would be consistent between 802.21, DNAv4 and DNAv6.  Is
this possible?

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 26 May 2005 10:40:17 +0900

> OK.  Ideally we would be consistent between 802.21, DNAv4 and DNAv6. Is 

I think so. 

For DNAv4 & DNAv6, now there are few discrepancies aside 
the ones inherent in v4/ v6 differences. Also DNA WG has liaison 
relationship with IEEE 802.21 WG. 

We may ask chairs to synchronize the terminology with 802.21. 

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 26 May 2005 10:48:05 +0900

Dear Alper 

> notifications for DNA" (dna-link-info) I-D. 

It will be of much help if dna-link-info I-D also defines other terms 
such as 
- Point of Attachment (Attachment Point) 
- Link
- Valid address. 

Best Regards

JinHyeock

---

From: Brett Pentland <[email-masked]>
Date: Thu, 26 May 2005 13:10:48 +1000

> for example, if the terminal moves out of range of any base stations.

If such a handover involves changing L3 links, then for DNA it would be
really good to have "Link Up" or at least some kind of signal to trigger
the DNA process.

Brett.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 26 May 2005 00:47:11 -0700

Hi JinHyeock,

I think defining PoA and Link makes sense. But I don't think "valid
address" belongs to the L2 event notifications context.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of JinHyeock Choi
> Sent: Wednesday, May 25, 2005 6:48 PM
> To: Alper Yegin
> Cc: Bernard Aboba; [email-masked]
> Subject: Re: [DNA] Revised terminology section for DNAv4
> 
> Dear Alper
> 
> > > Link Down
> > >
> > > Link Up
> >

---

From: James Kempf <[email-masked]>
Date: Thu, 26 May 2005 09:11:38 -0700

Brett,

> really good to have "Link Up" or at least some kind of signal to trigger

Yes, but I think that a radio protocol that supports make-before-break would
have to support that independently of DNA. Even if it uses RFC 2461, it
still needs some way to trigger the RS.

But I'm speculating. Is Hesham or George on this list? They are at Flarion,
which has a make-before-break radio protocol, perhaps they could tell us how
IP link handover is triggered.

            jak

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 28 May 2005 13:57:58 -0700 (PDT)

> L2 association/connection/whatever.)

How about this?

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.

Link Up

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 31 May 2005 07:49:24 -0700

> associated with the interface becoming capable of communicating

Works for me.
Thanks,
    Erik