[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] Review of draft-yegin-dna-l2hints-01.txt
Hi Alper (CC DNA)
Here is a delayed review of the Link-Hints draft.
Please feel free to ask me any questions
regarding the ideas I expressed in the review
(they are personal opinions only).
Overall, it is a good document, although
there seems to be a lot of extraneous material which
is not relevant to the IP layer configuration.
Since we're referring to other documents, we really only
need enough context to determine what's happening to
L3 or L2/L3 interactions.
Please explicitly reference the documents instead
of having too many details.
Personally, my own view of what hints and triggers
are has changed over time. While I think the existing
use of the words are unambiguous within the document,
it may be worth working out whether there are disparities
with other documents. This isn't something which can
be immediately addressed in this draft though.
Greg
-----
(S 1.0 Introduction)
Each time a host changes its point-of attachment, it is possible
that it will also have to change its IP-layer configurations, such
as its IP address and default gateway information. In order to make
these changes, the IP module has to detect the new network
attachment, realize that the old configuration is no longer valid
and obtain the new configuration parameters. The network detection
phase can usually use network-layer indications such as a change in
the advertised prefixes. But generally reliance on such indications
does not yield rapid detection, since these indications are not
readily available upon a link change.
GD: upon a link change or upon a link-layer change?
Link-layer event notifications to the IP are considered link-layer
triggers. From detecting network attachment perspective,
auxiliary data delivered in association with a trigger is considered
a hint. It has been identified that receiving explicit triggers and
hints from the link-layer would expedite the detection process. The
link-layer indicating that the host has established a new connection
can be used as a trigger to further probe the network for a possible
configuration change. Additional hints when present can be used as
input to this process.
GD: Hints or Triggers?
GD: I'm not sure that the relationship between hints, triggers and
GD: indications are completely the same as in the DNA BCP.
GD: I think that if we want to talk L2 we may call them triggers or
GD: indications.
GD: When we pass them to the L3 they're not really triggers any more
GD: (especially in 802.11), since the L3 may treat all such indications
GD: the same way regardless of their strength (I know I would initially).
GD: In this case it's really a hint to the L3 (an advisory trigger
GD: doesn't sound right).
GD: Perhaps this needs more discussion though...
....
(S 2.0 Terminology)
AT Access Terminal. Another term used for Mobile Terminal in
3GPP2 networks. (3GPP2)
GD: Unused Abbrev.
FA Foreign Agent. A router on a mobile node's visited network
which provides routing services to the mobile node while
registered.
GD: no MIPv4 qualifier.
GTP GPRS Tunneling Protocol. A protocol for encapsulating user
data traffic between the SGSN and the GGSN. (3GPP)
GD: Unused Abbrev
MN Mobile Node. A host or router that changes its point of
attachment from one network or subnet to another.
GD: This term is used generically across almost the entire document,
GD: regardless of whether MobileIP is used or not.
GD: Since DNA doesn't imply Mobile IP(v4 or v6) is required, perhaps
GD: we can use a generic term "wireless host??" which doesn't tie
GD: the reader to the MIP terminology?
MUX Multiplex Layer. A link layer protocol used to multiplex
signaling and RLP protocols. (3GPP2)
GD: Unused Abbrev.
PDP Address
Address of a MN for a given PDP context. (3GPP)
GD: Unused Abbrev
PLMN Public Land Mobile Network. A GPRS Network operated on a
national territory. (3GPP)
GD: Unused Abbrev the expanded version is used for PLMN-ID.
SSID Service Set Identifier. Identifier of an ESS. (WLAN)
GD: Unused
TE Terminal Equipment. A user's laptop for example. TE can
connect to the network via MT. (3GPP)
GD: Unused
....
(S 3.1. GPRS)
Multi-interface terminals are changing the face of wireless IP
connectivity and GPRS [GPRS] is being one of the most pervasive
types of radio link for enabling multi-technology access to the
Internet.
GD: 'is one of the most pervasive [media|types of radio link] for'
GD: Why multi-technology??? Is this a necessary statement when
GD: describing GPRS for DNA?
GPRS is an enhancement to the GSM data transmission architecture and
capabilities, designed to allow for packet switching in user data
transmission within the GPRS network as well as for higher quality
of service for the IP traffic of Mobile Terminals with external
Packets Data Networks (PDN) such as the Internet or corporate LANs.
GD: sentence too long. This needs to be broken into smaller pieces.
GD: Also, I'm not sure where QoS comes in (may be distracting
GD: to the context - which is DNA) I've not read the rest of the
GD: document yet, but please consider removing it:
GD: perhaps:
"GPRS is an enhancement to the GSM data transmission architecture and
capabilities. It is designed to allow for packet switching and
transmission within the [GSM? | GPRS] network, as well as
provide quality of service for mobile terminals connected to the Internet
or corporate network."
...
- An IP Core Network that acts as the transport backbone of user
datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The
GGSN ensures the GPRS IP core network connectivity with external
networks, such as Internet or Local Area Networks.
GD: I'm not sure that this is really a relvant statement since the
GD: network is an opaque tunnel from the point of view of the
GD: mobile stations. It may be worthwhile indicating that packets
GD: traversing the core only see a single IP hop.
From the point of view prevailing in detecting network attachment, the
GPRS access network will be only seen as providing layer 1-2
reachability even if it is able to provide IP connectivity alone.
GD: This is not adequately explained without discussing the tunneling,
GD: if the core network is being described as connected to the internet.
GD: The readers aren't necessarily aware of GPRS's architecture.
(S 3.1.2. Link-layer Events and Information)
In GPRS networks, only network attachment/detachment and subsequent
PDP context changing events will directly impact the IP
configurations, hence should be used as link-layer triggers by IP.
Other events such as routing area and cell change do not directly
imply potential configuration change. More details on those
secondary types of events can be found in Appendix A.
GD: It's not clear from reading below that GPRS attach actually
GD: affects IP connectivity at all, except where it allows
GD: signalling and tunneling messages to reach the GGSN.
GD: I think that the PDP context is far more important, although I
GD: may be misleading myself. Obviously GPRS detach may cause IP layer
GD: state change, too.
...
When a MT has performed the GPRS attach, it becomes in READY state.
GD: it [goes to|moves to] READY state.
In this state, the MT is reachable (using the logical link layer -
LLC) by the GPRS Radio Access Point called the SGSN. Otherwise, its
state is said to be IDLE. During the IDLE state, no IP level
GD: I think I understand what's going on, but am not sure.
GD: are there two states? one for LLC and one for IP PDP?
GD: or are these two different mutually exclusive states?
GD: I think this needs to be clear and explicit.
communication is possible with an external network, such as
Internet. The SGSN identifies the logical link with the MT by the
Temporary Logical Link Identifier (TLLI) it derives from the P-TMSI
that was assigned to the MT. It has to be noted that the MT or SGSN
may initiate a detach procedure (Mobile or Network Initiated
Detach). The MT returns from READY to IDLE STATE upon detachment.
The MT is actually considered GPRS attached when it has received an
"Attach Accept" message from the SGSN. The MT is considered detached
from the GPRS Network when it has sent or received a "Detach Accept
message" from/to the SGSN. This is an indication that the link-layer
connectivity is being lost.
GD: Indeed. I can't see what the GPRS attach indicates to the
GD: IP layer though.
...
A MN that wants to establish IP-level connections through the GPRS
MT should first request the GPRS network to settle the necessary
soft state mechanism (GPRS tunneling protocol) between its serving
SGSN and the GGSN corresponding to the APN specified in the PDP
Context parameters. Only after this tunneling mechanism takes place
can the MN's IP packets be forwarded to and from its remote IP
peers. The process by which this is made possible is designated as a
PDP Context Request.
GD: This is the only time APN is used except for in the terminology section
GD: please consider also providing the long form here.
GD: Is the process of getting a PDP context called PDP context activation
GD: or a PDP context request? please check.
....
The network may also decide to modify an existing PDP Context with a
given MN at any time. Such a modification might be prompted by the
MN's serving SGSN when it estimates that the negotiated QoS profile
can no longer be respected. For instance, the GPRS Network might
temporarily not be able to guarantee the contracted delay, in which
case it would force the related PDP context parameter to be
renegotiated. Note that, a MT can decide not to accept such an
update of its PDP context, in which case it should start a PDP
context deactivation procedure. Furthermore, a PDP context may be
deleted at any time at the request of the MT or the network. After a
PDP context is deleted, the MT returns to simply attached state
(READY STATE). Finally, a Mobile Terminal can hold several PDP
contexts, each corresponding to a different NSAPI.
GD: For the text near "Note that, " in this case, no triggers/hints
GD: would be generated.
GD: Perhaps it is better to just indicate that a trigger
GD: would be generated if there was a GPRS Detach while there were
GD: open PDP contexts (rather than mention states which don't
GD: generate triggers).
GD: Overall, this section ends well.
GD: I think that there is a lot of extraneous discussion of
GD: GPRSisms which don't impact (or don't even have parameters
GD: which directly impact) IP connectivity at all.
GD: Focussing only on that which will have impact on IP, or
GD: which passes (relevant) parameters to IP is a good way to
GD: shorten this.
(S 3.2. 3GPP2)
The aforementioned 3GPP2 technologies share a common core network
infrastructure which enables easy transition to enhanced air
interface technologies. 3GPP2 networks use the Point-to-Point
Protocol (PPP) as the link-layer protocol between the mobile node
and the network access server. Hence, link-layer mechanisms are
pretty consistent across all air interface technologies. Unless
specifically called out, all link-layer mechanisms specified in this
document apply to all 3GPP2 air interface technologies.
GD: perhaps replace "called out" with "indicated".
(S 3.2.1. Network Reference Model)
- Network Access Server known as the Packet Data Switching Node
(PDSN). The PDSN also serves as the Foreign Agent (FA), in the case
of Mobile IP service.
GD: no MIPv4 reference.
(S 3.2.2. Link-layer Events and Information)
While a PPP connection is in ESTABLISHED state at the MN and PDSN,
the packet data service state at the MN can be in ACTIVE or DORMANT
state. In the ACTIVE state, all the bearers between the MN and the
PDSN are in the established state. In the DORMANT state, the radio
link bearer and the A8 connection are torn down to conserve radio
resources. However, the A10 bearer still remains connected, and the
PPP state is maintained both at the MN and PDSN.
GD: PPP doesn't have ESTABLISHED states.
GD: Is this an underlying 3GPP2 state?
GD: also, no distinction between PPP and the NCPs are made.
GD: This is a big issue, since the PPP protocol may have LCP Opened
GD: and the authentication phase Opened, but not yet have a sutiable
GD NCP in Opened state. Therefore IP connectivity is not available.
...
If the ANID changes, but no change in the network attachment point,
a new A10 connection between the new PCF and serving PDSN is
established. If the ANID change results in a change in network
attachment point (i.e., PDSN), the new PDSN initiates a new PPP
connection setup with the MN, resulting in an update of the network
configuration information such as IP address and DNS server address
on the mobile node. In the case of Mobile IP, PPP resynchronization
is followed by Mobile IP registration to update the FA (PDSN)
address in the Mobile IP binding at the HA.
GD: It's not clear how a PPP session does this (address and
GD: DNS resolver) for IPv6. It may be necessary to indicate
GD: the need for change, though.
Hence, a PPP resynchronization from the PDSN could be viewed as a
link-layer event that updates network configuration information in
the MN and further provides an indication to the MN that Mobile IP
registration is required to update the binding in the HA with the
new FA address.
GD: Once again, this is an IPv4 only statement.
GD: Perhaps another way to put it is:
"Hence, a PPP resynchronization from the PDSN could be viewed as a
link-layer event that requires (or provides) configuration
update in the MN. Further, it indicates that address configuration
is either done (for IPv4) or is required (for IPv6) and that
global mobility signaling may be applicable."
On the other hand, when a DORMANT mobile moves, the RAN is not aware
of the presence of the mobile in its area (as the radio link is not
in established state). The RAN relies on the MN to inform it of the
MN's presence. The ANID for the RAN, which is broadcast on the
overhead channel, is used for determining RAN changes by the MN.
When a dormant MN moves and the ANID changes, the MN registers with
the RAN to initiate a new A10 connection between the new RAN and
PDSN. If the ANID change also results in a change in the network
attachment point, not only is a new A10 connection established, but
also a new PPP connection is established between the new PDSN and
MN. The RAN transitions the MN from DORMANT to ACTIVE state in order
to resynchronize the PPP connection. This results in an update in
the network layer configuration information such as IP address and
DNS server address in the MN. In the case of Mobile IP, PPP
resynchronization is followed by Mobile IP registration to update
the FA (PDSN) address in the Mobile IP binding at the HA.
GD: The PPP IPv6CP doesn't modify the DNS server address, nor does it
GD: assign an IPv6 address.
GD: some distinction between IPv4 and IPv6 hosts would be good here.
(S 3.3. WLAN)
WLANs are the wireless extension of the Local Area Networks. A WLAN
GD: WLANs are a wireless extension of the Local Area Networks. A WLAN
offers MNs short range network access at high rate. The maximum
coverage area of a node is usually from few meters indoors to more
than one hundred meter outdoor. The raw bandwidth varies between
1Mbps to 54Mbps depending on the norm used and the configuration of
the equipment.
GD: the maximum is defined as a range, perhaps:
GD: "The coverage area of a node..."
GD: depending on the norm used? can we be more explicit?
...
In this section MN refers to a IEEE 802.11 station without the AP
functionality.
GD: see the terminology section. STA is used in 802.11 (although this
GD: does include the AP's non-AP function), and MT in the 3GPP section.
GD: Either a generic term should be used fairly consistently (with
GD: explicit use of original names where applicable), or the
GD: original names should be used, and reference made between them
GD: in the terminology section.
Yegin et. al. Expires April August 2004
[Page 15] L2 Triggers and Hints February 2004
(S 3.3.1. Network Reference Model)
When a MN moves out of the coverage area of its current AP, it may
attach to a new AP. The new AP can be connected to the same access
network as well as it can be connected to a different access
network, this makes no difference at the link layer. However, if the
new AP is connected to the same subnet as the old AP, the MN can
continue its IP communication through the new AP without any
configuration change at the network-layer. But if the new AP is
connected to a different subnet, the MN needs to configure a new IP
address valid for the new subnet and use some additional mechanism
to maintain its ongoing communication sessions, such as Mobile IP
[MIPv4, MIPv6].
GD: "The new AP can be connected to the same access
GD: network or it can be connected to a different access
GD: network, this makes no difference at the link layer."
GD: s/But, if the new/If the new/
Yegin et. al. Expires April August 2004
[Page 16] L2 Triggers and Hints February 2004
A MN must be associated and authenticated with an AP in order to
send and receive data frames. At any given time, a MN can be
associated with only one AP on each IEEE 802.11 radio interface.
When a MN moves between two APs, it has to switch into promiscuous
mode to discover and initiate a connection with a new AP. A MN
cannot send IP packets during the establishment of a connection with
an AP. In an RSN (Robust Secure Network [802.11i]) the data packets
are still blocked until the IEEE 802.1X authentication and key
management is successfully completed.
GD: s/A MN must be/An MN must be/ (or a Mobile Node must be)
GD: similarly for later instances.
GD: need reference to 802.1X
Being associated implies that the MN has established a relationship
with the AP.
In a WLAN that does not support RSNA (RSN Association), three
different steps are required for the MN to be associated with an AP.
First the MN evaluates the potential APs in its range. In active
mode, the MN scans its default channel to identify the available APs
(exchange of Probe Request and Probe Response). If the MN does not
receive any response from AP (e.g., no APs are operating in this
channel), the MN switches to the next channel and continues the
scanning. In passive mode, the MN only listens to beacons sent by AP
to discover the potential APs.
GD: s/any response from AP/any response from an AP/ (or: from APs)
...
In a IEEE 802.11 RSN, IEEE 802.1X might be used as the
authentication and key management mechanism. In this framework, the
authentication is performed after the MN is connected to the AP by
utilizing protocols above the MAC layer. The process to be
associated with an AP is the same as in the model described above,
except that authentication at the MAC layer must not take place. The
(re-)association of a MN is mapped to an IEEE 802.1X port on the AP,
and the controlled IEEE 802.1X port blocks every data packets. Only
the EAPOL packets are authorized to be sent through the uncontrolled
IEEE 802.1X port. Once the authentication successfully completes,
the 4-way handshake protocol takes place. The 4-way handshake
consists of four EAPOL messages sent between the MN and the AP which
guarantee the liveness of both the AP and the MN, the freshness and
GD: s/In a IEEE802.11 RSN/In an IEEE802.11 RSN/
GD: s/ blocks every data packets/ blocks all data packets/
3.3.2. Link-layer Events and Information
The roaming of MNs between APs is managed by the link-layer protocol
and is known as link-layer handover. As long as the MN moves between
APs in the same access network, the IP layer is not involved in the
movement management. However, when the MN handovers to a new AP in
another IP subnet, the MN needs to perform operations to maintain
its existing communications [MIPv4, MIPv6]. Therefore, even if a
link-layer handover occurs at the link layer, it doesn't necessarily
imply a network-layer handover.
GD: replace "link-layer handover occurs at the link layer"
GD: with "handover occurs at the link-layer"
(S 4.1. Link-up Trigger and Associated Hints)
...
Creation of a new PDP context can be used to generate a link-up
trigger in GPRS networks. Similarly, a new PPP link establishment
can lead to a trigger in 3GPP2 networks. Both of these mechanisms
also provide network-layer configuration on the host. The IP
addresses configured via these mechanisms can be considered as link-
layer hints. In fact, this type of strong hint simplifies the task
of detecting network attachment at the network-layer. This hint
indicates the already configured parameters, hence further network
attachment detection is generally not necessary.
GD: perhaps:
"Similarly, transition of PPP NCPs to the Opened state can
lead tot a trigger in 3GPP2 networks"
GD: IPv6CP doesn't provide network layer configuration (except
GD: a 64bit suffix) change of peer endpoint identifier may be a strong
hint though.
Association and re-association events in non-RSN, and completion of
4-way handshake in RSN can be used to generate a link-up trigger in
IEEE 802.11 networks. Unlike the technologies used in 3GPP and
3GPP2, networkùlayer configuration is not provided as part of link-
layer establishment in IEEE 802.11 networks. Aside from not
providing the IP address configuration, this link-layer does not
present a useful hint to be used with the network attachment
detection process either. This is due to lack of a one-to-one
mapping between IP subnets and link-layer parameters. See Appendix A
of [DNA4] for a detailed discussion.
GD: s/networkùlayer/network-layer/
GD: Actually, I'm not sure that it doesn't provide a useful hint.
GD: reading Appendix A of DNAv4 didn't convince me of it either.
GD: perhaps the wording needs to be changed to indicate that the
GD: information provided from a hint/trigger in 802.11 is not
GD: authoritative (as opposed to not useful).
(S 4.2. Link-down Trigger)
This trigger is asynchronously provided to IP when an existing link
instance is removed.
Network-layer may interpret this trigger as a sign of possible
configuration change. This trigger might be followed by a link-up
trigger in the case of a handover. The detailed use of link-down
trigger for detecting network attachment is outside the scope of
this draft.
GD: link-down triggers may be an indication that configuration
GD: validity has changed (which is important to DNA).
5.0 Security Considerations
The link-layer triggers and hints are advisory only. They SHOULD be
used as indications of possible network-layer configuration change,
not an absolute change. When used in this context, potential
security threats from their use is limited but not necessarily
completely eliminated. A faked link-layer trigger can still be used
to launch a denial-of service attack on the host and the associated
network. Secure generation and delivery of these triggers and hints
MUST be ensured. This is a subject for lower-layer designs and
therefore it is outside the scope of this document.
GD: Please be aware that almost every hint or trigger which has
GD: been mentioned arises from L2 message exchanges.
GD: Particularly those messages generating Link-down triggers/hints
GD: can be used to deny service, if spoofed or replayed.
GD: devices spoofing messages may be able to steal service or
GD: act as men-in-the-middle by impersonating legitimate networks.
GD: Unless the wireless host (MN?) has pre-existing trust
GD: arrangements it can rely upon, hints of network attachment
GD: SHOULD NOT assume any security for services at the
GD: network-layer (nor conceivably the link-layer
GD: in some circumstances).
GD: It may also be possible to bid down a device to associate
GD: with a less secure version of an IEEE 802.11 network.
GD: Since choices of what messages to send on a particular network
GD: may depend on the availability of link encryption, the
GD: hints provided for RSN and non-RSN networks SHOULD be
GD: readily distinguishable.
6.0 References
GD: Please split these as normative and informative
GD: need reference to 802.1X (informative?)
GD: need references to PPP, IPCP and IPv6CP.
Appendix A
This section describes the additional events and the associated
information with the GPRS networks. Unlike the PDP context changes,
the following events do not directly imply potential IP
configuration change.
GD: if this is not relevant to IP layer, is it needed?