draft-ietf-dna-link-information-02.txt   draft-ietf-dna-link-information-03.txt 
Network Working Group A. Yegin, Ed. Network Working Group A. Yegin, Ed.
Internet-Draft Samsung AIT Internet-Draft Samsung AIT
Expires: January 9, 2006 July 8, 2005 Expires: April 27, 2006 October 24, 2005
Link-layer Event Notifications for Detecting Network Attachments Link-layer Event Notifications for Detecting Network Attachments
draft-ietf-dna-link-information-02.txt draft-ietf-dna-link-information-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006. This Internet-Draft will expire on April 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Certain network access technologies are capable of providing various Certain network access technologies are capable of providing various
link-layer status information to IP. Link-layer event notifications link-layer status information to IP. Link-layer event notifications
can help IP expeditiously detect configuration changes. This can help IP expeditiously detect configuration changes. This
skipping to change at page 3, line 22 skipping to change at page 3, line 22
A node changing its point-of attachment to the network may end up A node changing its point-of attachment to the network may end up
changing its IP subnet and therefore require re-configuration of IP- changing its IP subnet and therefore require re-configuration of IP-
layer parameters, such as IP address, default gateway information, layer parameters, such as IP address, default gateway information,
and DNS server address. Detecting the subnet change can usually use and DNS server address. Detecting the subnet change can usually use
network-layer indications such as a change in the advertised prefixes network-layer indications such as a change in the advertised prefixes
(i.e., appearance and disappearance of prefixes). But generally (i.e., appearance and disappearance of prefixes). But generally
reliance on such indications does not yield rapid detection, since reliance on such indications does not yield rapid detection, since
these indications are not readily available upon node changing its these indications are not readily available upon node changing its
point of attachment. point of attachment.
The changes on the underlying link-layer status can be relayed to IP The changes to the underlying link-layer status can be relayed to IP
in the form of link-layer event notifications. Establishment and in the form of link-layer event notifications. Establishment and
tear down of a link-layer connection are two basic events types. tear down of a link-layer connection are two basic events types.
Additional information can be conveyed in addition to the event type, Additional information can be conveyed in addition to the event type,
such as the identifier of the network attachment point (e.g., IEEE such as the identifier of the network attachment point (e.g., IEEE
802.11 BSSID and SSID), or network-layer configuration parameters 802.11 BSSID and SSID), or network-layer configuration parameters
obtained via the link-layer attachment process if available. It is obtained via the link-layer attachment process if available. It is
envisaged that such event notifications can in certain circumstances envisaged that such event notifications can in certain circumstances
be used to expedite the inter-subnet movement detection and be used to expedite the inter-subnet movement detection and
reconfiguration process. For example, the notification indicating reconfiguration process. For example, the notification indicating
that the node has established a new link-layer connection MAY be used that the node has established a new link-layer connection MAY be used
for immediately probing the network for a possible configuration for immediately probing the network for a possible configuration
change. In the absence of such a notification from the link-layer, change. In the absence of such a notification from the link-layer,
IP has to wait for indications that are not immediately available, IP has to wait for indications that are not immediately available,
such as receipt of next scheduled router advertisement, such as receipt of next scheduled router advertisement,
unreachability of the default gateway, etc. unreachability of the default gateway, etc.
It be noted that a link-layer event notification does not always It should be noted that a link-layer event notification does not
translate into a subnet change. Even if the node has torn down a always translate into a subnet change. Even if the node has torn
link-layer connection with one attachment point and established a new down a link-layer connection with one attachment point and
connection with another, it may still be attached to the same IP established a new connection with another, it may still be attached
subnet. For example, several IEEE 802.11 access points can be to the same IP subnet. For example, several IEEE 802.11 access
attached to the same IP subnet. Moving among these access points points can be attached to the same IP subnet. Moving among these
does not warrant any IP-layer configuration change. access points does not warrant any IP-layer configuration change.
In order to enable an enhanced scheme for detecting change of subnet, In order to enable an enhanced scheme for detecting change of subnet,
we need to define link-layer event notifications that can be we need to define link-layer event notifications that can be
realistically expected from various access technologies. The realistically expected from various access technologies. The
objective of this draft is to provide a catalogue of link-layer objective of this draft is to provide a catalogue of link-layer
events and notifications in various architectures. While this events and notifications in various architectures. While this
document mentions the utility of this information for detecting document mentions the utility of this information for detecting
change of subnet (or, detecting network attachment - DNA), the change of subnet (or, detecting network attachment - DNA), the
detailed usage is left to other documents, namely DNA solution detailed usage is left to other documents, namely DNA solution
specifications. specifications.
The document limits itself to the minimum set of information that is The document limits itself to the minimum set of information that is
necessary for solving the DNA problem [I-D.ietf-dna-goals]. A necessary for solving the DNA problem [I-D.ietf-dna-goals]. A
broader set of information (e.g., signal strenght, packet loss, etc.) broader set of information (e.g., signal strength, packet loss, etc.)
may be used for other problem spaces, such as anticipation-based may be used for other problem spaces, such as anticipation-based
Mobile IP fast handovers [I-D.ietf-mobileip-lowlatency-handoffs-v4] Mobile IP fast handovers [I-D.ietf-mobileip-lowlatency-handoffs-v4]
[I-D.ietf-mipshop-fast-mipv6]. Separate documents that are backward- [I-D.ietf-mipshop-fast-mipv6]. Separate documents that are backward-
compatible with this one can be generated to discuss further compatible with this one can be generated to discuss further
enhancements. enhancements.
These event notifications are considered with hosts in mind, although These event notifications are considered with hosts in mind, although
they may also be available on the network side (e.g., on the access they may also be available on the network side (e.g., on the access
points and routers). An API or protocol-based standard interface may points and routers). An API or protocol-based standard interface may
be defined between the link-layer and IP for conveying this be defined between the link-layer and IP for conveying this
skipping to change at page 10, line 27 skipping to change at page 10, line 27
configuration MUST be changed upon movement. There is no standards- configuration MUST be changed upon movement. There is no standards-
mandated one-to-one relation between the BSSID/SSID pairs and IP mandated one-to-one relation between the BSSID/SSID pairs and IP
subnets. An AP with a given BSSID can connect a STA to any one of subnets. An AP with a given BSSID can connect a STA to any one of
multiple IP subnets. Similarly, an ESS with the given SSID may span multiple IP subnets. Similarly, an ESS with the given SSID may span
multiple IP subnets. And finally, the SSIDs are not globally unique. multiple IP subnets. And finally, the SSIDs are not globally unique.
The same SSID may be used by multiple independent ESSs. See Appendix The same SSID may be used by multiple independent ESSs. See Appendix
A of [DNA4] for a detailed discussion. Nevertheless, BSSID/SSID A of [DNA4] for a detailed discussion. Nevertheless, BSSID/SSID
information may be used in a probabilistic way by the DNA process, information may be used in a probabilistic way by the DNA process,
hence it is provided with the link up event notification. hence it is provided with the link up event notification.
Disassociation event in RSN-based, and de-authentication and Disassociation event in non-RSN-based, and de-authentication and
disassociation events in non-RSN-based WiFi networks MUST translate disassociation events in RSN-based WiFi networks MUST translate to
to link down events, and generate the corresponding link-layer link down events, and generate the corresponding link-layer
notifications. notifications.
In ad-hoc mode, mobile station (STA) in range may directly In ad-hoc mode, mobile stations (STA) in range may directly
communicate with others, i.e., without any infrastructure or communicate with each other, i.e., without any infrastructure or
intermediate hop. The set of communicating STAs is called IBSS for intermediate hop. The set of communicating STAs is called IBSS for
Independent Basic Service Set. In an IBSS, only STA services are Independent Basic Service Set. In an IBSS, only STA services are
available, i.e. authentication, deauthentication, privacy and MSDU available, i.e. authentication, deauthentication, privacy and MSDU
delivery. STAs do not associate with each other, and therefore may delivery. STAs do not associate with each other, and therefore may
exchange data frames in state 2 (authenticated and not associated) or exchange data frames in state 2 (authenticated and not associated) or
even in state 1 (unauthenticated and unassociated) if the even in state 1 (unauthenticated and unassociated) if the
Distribution System is not used (i.e., "To DS" and "From DS" bits are Distribution System is not used (i.e., "To DS" and "From DS" bits are
clear). If authentication is performed, a link up indication can be clear). If authentication is performed, a link up indication can be
generated upon authentication, and a link down indication can be generated upon authentication, and a link down indication can be
generated upon deauthentication. Concerning the link layer generated upon deauthentication. Concerning the link layer
identification, both the BSSID (which is a random MAC address chosen 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 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. not to make any assumptions on the IP network configuration.
2.4 IEEE 802.3 CSMA/CD 2.4 IEEE 802.3 CSMA/CD
IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most
commonly deployed Local Area Network technology in use today. As commonly deployed Local Area Network technology in use today. As
deployed today, it is specified by both a physical layer/medium deployed today, it is specified by a physical layer/medium access
access control (MAC) layer specification [IEEE-802.3]. In order to control (MAC) layer specification [IEEE-802.3]. In order to provide
provide connection of different LANs together into a larger network, connection of different LANs together into a larger network, 802.3
802.3 LANs are often bridged together [IEEE-802.1D]. LANs are often bridged together [IEEE-802.1D].
In this section, the terms 802.3 and Ethernet are used In this section, the terms 802.3 and Ethernet are used
interchangeably. This section describes some issues in providing interchangeably. This section describes some issues in providing
link-layer indications on Ethernet networks, and shows how bridging link-layer indications on Ethernet networks, and shows how bridging
affects these indications. affects these indications.
In Ethernet networks, hosts are connected by wires or by optic fibre In Ethernet networks, hosts are connected by wires or by optic fibre
to a switch (bridge), a bus (e.g., co-axial cable), a repeater (hub), to a switch (bridge), a bus (e.g., co-axial cable), a repeater (hub),
or directly to another Ethernet device. Interfaces are symmetric, in or directly to another Ethernet device. Interfaces are symmetric, in
that while many different physical layers may be present, medium that while many different physical layers may be present, medium
skipping to change at page 12, line 15 skipping to change at page 12, line 15
This indication do not definitively ensure that packets will be able This indication do not definitively ensure that packets will be able
to be received through the bridge domain, though [see the next to be received through the bridge domain, though [see the next
section]. Such operations are governed by bridging. section]. Such operations are governed by bridging.
PMA_LINK.indicate(FAIL) MUST be used to generate a link down PMA_LINK.indicate(FAIL) MUST be used to generate a link down
notification. notification.
2.4.2 IEEE 802.1D Bridging and Its Effects on Link-layer Event 2.4.2 IEEE 802.1D Bridging and Its Effects on Link-layer Event
Notifications Notifications
Ethernet networks commonly consist of LANs joined together by Ethernet networks commonly consist of LANs joined together by
transparent bridges (usually implemented as switches). Tranparent transparent bridges (usually implemented as switches). Transparent
bridges require the active topology to be loop free. The Spanning bridges require the active topology to be loop free. The Spanning
Tree Protocol (STP) achieves this by the exchange of Bridge Protocol Tree Protocol (STP) achieves this by the exchange of Bridge Protocol
Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where
required, the blocking of ports (i.e., not forwarding). required, the blocking of ports (i.e., not forwarding).
By default, the spanning tree protocol does not know whether a By default, the spanning tree protocol does not know whether a
particular newly connected piece of Ethernet will cause a loop. particular newly connected piece of Ethernet will cause a loop.
Therefore it will block all traffic from and to newly connected ports Therefore it will block all traffic from and to newly connected ports
with the exception of some unbridged management frames. The STP will with the exception of some unbridged management frames. The STP will
skipping to change at page 18, line 8 skipping to change at page 18, line 8
5. Contributors 5. Contributors
Text for the specific link-layer technologies covered by this Text for the specific link-layer technologies covered by this
document are contributed by Eric Njedjou (GPRS), Siva Veerepalli document are contributed by Eric Njedjou (GPRS), Siva Veerepalli
(cdma2000), Nicolas Montavont (IEEE 802.11b), Thomas Noel (IEEE (cdma2000), Nicolas Montavont (IEEE 802.11b), Thomas Noel (IEEE
802.11b), and Greg Daley (IEEE 802.3). 802.11b), and Greg Daley (IEEE 802.3).
6. Acknowledgements 6. Acknowledgements
The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye, The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye,
JinHyeock Choi, John Loughney, Pekka Nikander, Tom Petch, Dan JinHyeock Choi, John Loughney, Pekka Nikander, Brett Pentland, Tom
Romascanu, Pekka Savola, and Muhammad Mukarram bin Tariq for their Petch, Dan Romascanu, Pekka Savola, and Muhammad Mukarram bin Tariq
useful comments and suggestions. for their useful comments and suggestions.
7. References 7. References
7.1 Normative References 7.1 Normative References
[CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", . [CDMA2K] "IS-835 - cdma2000 Wireless IP Network Standard", .
[GPRS] "Digital cellular telecommunications system (Phase 2+); [GPRS] "Digital cellular telecommunications system (Phase 2+);
General Packet Radio Service (GPRS) Service description; General Packet Radio Service (GPRS) Service description;
Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98. Stage 2", 3GPP 3GPP TS 03.60 version 7.9.0 Release 98.
skipping to change at page 21, line 19 skipping to change at page 21, line 19
General Packet Radio Service (GPRS) Service description; General Packet Radio Service (GPRS) Service description;
Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0 Stage 2 (Release 6)", 3GPP 3GPP TS 23.060 version 6.5.0
2004-06. 2004-06.
[I-D.ietf-mipshop-fast-mipv6] [I-D.ietf-mipshop-fast-mipv6]
Koodli, R., "Fast Handovers for Mobile IPv6", Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-03 (work in progress), draft-ietf-mipshop-fast-mipv6-03 (work in progress),
October 2004. October 2004.
[I-D.ietf-mobileip-lowlatency-handoffs-v4] [I-D.ietf-mobileip-lowlatency-handoffs-v4]
Malki, K., "Low latency Handoffs in Mobile IPv4", Malki, K., "Low Latency Handoffs in Mobile IPv4",
draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in draft-ietf-mobileip-lowlatency-handoffs-v4-11 (work in
progress), June 2004. progress), October 2005.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
Author's Address Author's Address
Alper E. Yegin (editor) Alper E. Yegin (editor)
Samsung Advanced Institute of Technology Samsung Advanced Institute of Technology
75 West Plumeria Drive 75 West Plumeria Drive
skipping to change at page 22, line 13 skipping to change at page 22, line 13
Email: alper.yegin@samsung.com Email: alper.yegin@samsung.com
Appendix A. Change History Appendix A. Change History
The following changes were made on draft version 00: The following changes were made on draft version 00:
- IEEE 802.11 ad-hoc mode discussion added. - IEEE 802.11 ad-hoc mode discussion added.
- IPv6 address configuration over 3GPP networks clarified. - IPv6 address configuration over 3GPP networks clarified.
The following change were made on draft version 01: The following changes were made on draft version 01:
- Text for IEEE 802.3 added. - Text for IEEE 802.3 added.
- Multiple 3GPP PDP Contexts scenario clarified. - Multiple 3GPP PDP Contexts scenario clarified.
The following change was made on draft version 02:
- Editorial fixes as suggested by WG last call feedback.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 14 change blocks. 
29 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/