[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] RE: (forward) Review of Link-information
Hi Bernard,
Thanks for the comments. Please see below for my response.
>
> Here you go. My comments denoted with [BA].
>
>
>
------------------------------------------------------------------------
-
> Review of draft-ietf-dna-link-information-01.txt
>
> [BA] Overall, my take is that this document does not clearly
> distinguish
> Link Establishment/Termination events from "Up"/"Down" link state
> changes.
> As I understand it, DNA cares mostly about Link Establishment events,
> not
> about whether a link is encountering low or high frame loss at a
given
> instant. In DNA, bi-directional reachability at the IP layer
> determines whether a link is suitable for use, so that link quality
> monitoring is not required.
Link up is meant to reflect Link Establishment, and Link Down is for
Link Termination. I'll make sure to clarify this in the document.
>
> It is important for the document to clarify the usage of terms, since
> the
> definition of the "Up" and "Down" link states can be somewhat murky
in
> wireless networks. Please see: "The Mistaken Axioms of Wireless
Network
> Research":
> http://www.pdos.lcs.mit.edu/decouto/papers/kotz03.pdf
>
> 1. Introduction
>
> " The changes on the underlying link-layer status can be relayed to
> IP
> in the form of link-layer event notifications. Establishment and
> tear down of a link-layer connection are two basic events types."
>
> [BA] I think you are referring to explicit messages resulting in
> establishment (e.g. PPP IPCP) or teardown (PPP LCP-terminate) of the
> link-layer. However, in wireless technologies the mobile node can
> wander
> out of range or suffer from high frame loss for other reasons; in
> these
> cases there can be links in intermediate states between "up" (low
loss)
> and "down" (high loss). The distinction between link
> establishment/teardown events and the link state is an important one.
These intermediate states are not as interesting to DNA, as they do not
change the IP configuration. They make the current configuration not
useful (e.g., no IP packets received), but that does not call for
changing the configuration. I'll clarify this in the document as well.
> "Additional information can be conveyed in addition to the event
> type,
> such as the identifier of the network attachment point, or
> network-layer configuration parameters obtained via the link-layer
> attachment process."
>
> [BA] By identifier I assume you mean MAC layer address, no? Of are
you
> referring perhaps to "network identifiers" such as SSID?
Both are possible, depending on the technology. But since they are not
used in this document, I have not got into the details of what they
might be. But I guess I can give these as examples, good idea.
> I would add
> "if available" to the end of the sentence, since some link
technologies
> do not provide network-layer configuration.
OK, will do.
>
> For example, the
> notification indicating that the node has established a new
> link-layer connection can be used for immediately probing the
> network
> for a possible configuration change. In the absence of such a
> notification from the link-layer, IP has to wait for indications
> that
> are not immediately available, such as receipt of next scheduled
> router advertisement, unreachability of the default gateway, etc.
>
> [BA] This seems to imply that assignment of a new address via PPP
IPCP
> (an event) would need to be "confirmed" by DNA.
I'll soften the text to make sure reader don't think confirmation is
always done. PPP is a good example when it is not needed.
> The current DNAv4 spec
> assumes that this is not necessary; essentially the bi-directional
> reachability established via PPP IPCP is "good enough" to not require
> an additional demonstration of default gateway reachability.
>
> " Two basic link-layer events are considered potentially useful to
DNA
> process: link up and link down. Both of these events are
> deterministic, and their notifications are provided to IP-layer
> after
> the events successfully conclude."
>
> [BA] The "Up" and "Down" link states are only determinstic on wired
> networks. On wireless networks, frame loss can be intermediate
between
> the "up" and "down" states, so that link state indications may not be
> reliable.
OK.
>
> 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.
>
> [BA] I think we need to distinguish changes in link state due to
frame
> loss from "Link Establishment" and "Link Termination" events. As
used
> in this document I am not clear whether "Link Up" refers to the state
> of the link or whether we are really talking about a "Link
> Establishment"
> event. For example, a link can be established, and then experience
high
> frame loss (e.g. mobile node wanders out of range). Does this then
> constitute a "Link Down" event, followed by a "Link Up" event when
> frame loss becomes low again? For the purposes of DNA, don't we
> only need to care about "Link Establishment" events (not even
> "Link Termination")?
Yes, and I will take care of this.
>
> [TO-DO: How about ad-hoc networks? Attached neighbors may be
> considered attachment points].
>
> [BA] Adhoc networks are tricky because each adjacency is a "link"
which
> may be in an intermediate state between "up" and "down". Also, there
> may not be a clearly delineated point at which IP traffic can be
sent.
> For example, in 802.11 adhoc it is possible to send data frames with
> "For DS" and "To DS" both set to zero, even in state 1 (unassociated,
> unauthenticated). Given this, when is the link "established"? One
> view could be that it is only established when the destination is
> enabled to forward packets to other nodes.
This is really tricky... What would you recommend we do about this?
> By the time the notification is
> delivered, the link-layer of the node must be ready to accept IP
> packets from the IP and the physical-layers.
>
> [BA] This sentence and other text related to specific link
technologies
> leads me to believe that "Link Up" as used in this document refers to
a
> "Link Establishment" event, rather than the link state. Is that
right?
Yes.
>
> 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.
>
> [BA] Here you are mixing "Link Termination" events with the "down"
> link state. There may be no explicit teardown event. A node may
> wander out of range, or may experience multi-path interference,
causing
> high loss.
In the absence of an explicit tear-down, the MAC layer should have some
timeout mechanism to locally decide the link is terminated. That should
generate the link down notification.
>
> Among these two events the first one to take place after an
> interface
> becomes enabled must be a link up event. During the time a
network
> interface is enabled, it may go through a series of link up and
down
> events. Each time the interface changes its point of attachment,
a
> link down event with the previous attachment point must be
followed
> by a link up event with the new one.
>
> [BA] The problem is that in some implementations the "Link Down"
event
> may (mistakenly) result in teardown of TCP connections. As a result,
> only
> a series of "Link Establishment" messages are seen.
I didn't understand how what TCP does relates to lost "link downs"?
These event notifications are generated by L2, consumed by L3.
> Also in the above
> paragraph I am not clear if you are talking about the up/down link
> states
> or explicit establishment/termination events.
>
> Furthermore, IP-layer configuration
> parameters obtained during link-layer connection may be exactly
what
> the DNA process is trying to discover (e.g., IP address configured
> during PPP link establishment).
>
> [BA] This confuses me. Why would DNA need to be invoked in the case
> where the network configuration is set by the link layer?
The DNA process can subscribe to L2 event notifications on all
interfaces available. On a PPP interface, it does not have to really
perform much "DNA" for the reasons discussed above (NULL operation).
Nevertheless, DNA process can be the central module that has a
system-level view of the interfaces and connectivity.
>
> 3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as
> the
> link-layer protocol between the MS and the PDSN. Before any IP
> packets may be sent or received, PPP must reach the Network-Layer
> Protocol phase, and the IP Control Protocol (IPCP [RFC1332],
IPV6CP
> [RFC2472]) reach the Opened state. When these states are reached
in
> PPP, a link up event notification must be delivered to the
IP-layer.
>
> [BA] It is also true that most hosts interface to GPRS/EDGE/UMTS
> networks
> via PPP as well. So the statement above seems more general, and you
> might
> include a subsection on PPP early on, then reference it.
The 3GPP text is not discussing PPP at all. It's built around the PDP
context. As I understand, PDP is in fact implemented using PPP. I
thought it is better to keep the discussion as high-level as possible
(i.e., talking PDP instead of PPP). For that, 3GPP2 is the only place
detailed PPP discussion is taking place for now.
>
> Since there is no
> standards-mandated correlation between the interface-identifier
and
> other IP-layer configuration parameters, this information is
deemed
> not useful for DNA (hence it is not provided as auxiliary
> information).
>
> [BA] Saying it is useful for DNA is not the same as saying it is not
> provided. Since the information may be used, it does need to be
> available
> to the Internet layer.
OK, I'll fix that.
>
> 2.3 IEEE 802.11/WiFi
>
> A STA must establish a IEEE
> 802.11 link with an AP in order to send and receive IP packets.
In
> a
> WiFi network that supports Robust Secure Network (RSN
> [IEEE-802.11i]), successful completion of 4-way handshake between
> the
> STA and AP commences the availability of IP service. The link up
> event notification must be generated upon this event. In
> non-RSN-based networks, successful association or re-association
> events on the link-layer must cause a link up notification sent to
> the IP-layer.
>
> As part of the link establishment, Basic Service Set
Identification
> (BSSID) and Service Set Identifier (SSID) associated with the AP
is
> learned by the STA. BSSID is a unique identifier of the AP. Its
> value is set to the MAC address of the AP.
>
> [BA] I would delete the last sentence; an AP may have multiple MAC
> addresses (e.g. on the wired side and on the wireless side).
I see, OK.
>
> In ad-hoc mode, mobile station (STA) in range may directly
> communicate with others, i.e., without any infrastructure or
> intermediate hop. The set of communicating STAs is called IBSS
for
> Indepedant Basic Service Set. In an IBSS, only station services
are
>
> Indepedant -> Independent
>
> available, i.e. authentication, deauthentication, privacy and
MSDU
> delivery. STAs do not associate with each other, and therefore
may
> exchange data frames in state 2 (authenticated and not associated)
> or
> even in state 1 (unauthenticated and unassociated) if
authentication
> is not used.
>
> [BA] They can exchange data frames in state 1 only if "To DS" and
"From
> DS" bits are clear. This is not dependent on authentication (e.g.
> State
> 1, not State 2).
I'd need to ask co-author Nicolas to look at this. I'm not too familiar
with these details.
>
> Although a link up indication can be generated upon
> authentication, one may not be present per latter usage. If
> authentication is performed, a deauthentication event is used for
> generating the link down indication. Concerning the link layer
> identification, both the BSSID (which is a random MAC address
chosen
> by a STA of the IBSS) and SSID may be used to identify a link, but
> not to make any assumptions on the IP network configuration.
>
> [BA] This is a reasonable guess at how it should work, but I'm not
> clear
> that it is strictly correct. If the goal is only for two nodes to
> exchange data frames, this can occur in State 1 without
authentication.
> So if the packets can be exchanged, the link can be "up". Without
> explicit link establishment, whether the link is "up" or "down"
becomes
> dependent on the frame loss, which is non-deterministic.
>
> To clear this up, you might ask Bob O'Hara, editor of 802.11ma.
I'm deferring this to Nicolas as well.
>
> [IEEE-802.11i]
> Institute of Electrical and Electronics Engineers,
"Draft
> Supplement to STANDARD FOR Telecommunications and
> Information Exchange between Systems - LAN/MAN Specific
> Requirements - Part 11: Wireless Medium Access Control
> (MAC) and physical layer (PHY) specifications:
> Specification for Enhanced Security", IEEE Draft
802.11I/
> D8, February 2004.
>
> [BA] This document is final now.
Thanks for the useful comments. We'll incorporate them to the next rev.
Alper