One document matched: draft-yegin-dna-l2-hints-00.txt
Internet Draft Alper Yegin (Editor)
Document: draft-yegin-dna-l2-hints-00.txt DoCoMo USA Labs
Expires: April 2004 Eric Njedjou
France Telecom R&D
Siva Veerepalli
Qualcomm, Inc
Nicolas Montavont
Thomas Noel
LSIIT - University Louis Pasteur
Link-layer Hints for Detecting Network Attachments
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Certain link-layer technologies are capable of providing various link
status information to the IP module. Indicating the status of the link,
such as connected or disconnected, and the link identifier can help the
IP module make intelligent decisions regarding configuration changes.
It has been identified that such information can be used as hints for
network attachment detection purposes. This draft provides a
non-exhaustive catalogue of such hints from well-known link-layer
technologies. Furthermore, a high-level abstraction is defined to
categorize such hints.
Yegin et al. Expires April 2004
[Page 2] L2 Hints October 2003
Table of Contents
1.0 Introduction.................................................2
2.0 Terminology..................................................3
3.0 Link-layer Hints in Various Systems..........................6
3.1. GPRS........................................................6
3.1.1. Network Reference Model...................................7
3.1.2. Link-layer Hints..........................................7
3.2. 3GPP2......................................................11
3.2.1. Network Reference Model..................................12
3.2.2. Link-layer Hints.........................................14
3.3. WLAN.......................................................15
3.3.1. Network Reference Model...................................16
3.3.2. Link-layer Hints.........................................17
4.0 Abstraction.................................................18
4.1. Link Identifier............................................18
4.2. Link-up Hint...............................................19
4.3. Link-down Hint.............................................19
5.0 Security Considerations.....................................20
6.0 References..................................................20
7.0 Acknowledgements............................................21
Appendix A.......................................................21
Authors' Addresses...............................................22
Full Copyright Statement.........................................23
1.0 Introduction
It is not an uncommon occurrence for a host to change its point-of
attachment to the network. This can happen due to mobile usage
(e.g., a mobile phone moving among base stations) or nomadic usage
(e.g., road-warrior case).
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. It has been identified that
receiving explicit 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 hint to further probe
Yegin et. al. Expires April 2004
[Page 3] L2 Hints October 2003
the network for a possible configuration change. Such an indication
cannot be used to positively determine the need for a configuration
change as it might very well be the case that the host is still
connected to the same IP subnet despite the link change. For
example, there might be several IEEE 802.11b access points connected
to the same access router. Moving among these access points does not
warrant any IP-layer configuration change. This is why the link-
layer hints should be used as "advisory-only" unless stated
otherwise.
In order to enable an enhanced network attachment detection scheme,
we need to identify types of link-layer hints that can be
realistically expected from various access technologies. The
objective of this draft is to provide a catalogue of existing link-
layer hints in various architectures. Later, this catalogue is used
to define an abstraction for these hints. The movement detection
schemes should be able to incorporate these hints in their abstract
form for simplicity. Furthermore, this abstraction should enable the
link-layer developers to align their implementations according to
the needs of IP. This is not an API design, although the abstraction
can be used to define one.
The document limits itself to the minimum set of link-layer hints
that are necessary for detecting network attachment. These hints are
considered with hosts in mind, although they may also be available
on the network side (e.g., on the access router).
2.0 Terminology
Some of the terminology differs among the discussed architectures.
An architecture name is provided in parenthesis when a term has
limited applicability.
3GPP Third Generation Partnership Project
3GPP2 Third Generation Partnership Project 2
ANID Access Network Identifier. Identifies the packet switched area
served by a unique combination of RAN and MSC area. (3GPP2)
AP Access Point. An access point is an entity that provides
bridging between the radio link and the wired network. (WLAN)
APN Access Point Name. A parameter of the PDP context, in the form
of a logical name that is used to select the GGSN or the
external IP network. (3GPP)
AT Access Terminal. Another term used for Mobile Terminal in 3GPP2
networks. (3GPP2)
BSC Base Station Controller. A BSC controls a set of BTS. (3GPP,
Yegin et. al. Expires April 2004
[Page 4] L2 Hints October 2003
3GPP2)
BSS Base Station System. The system that is made up of BTSs and
BSCs. (3GPP)
BSS Basic Service Set. A BSS is composed of one AP and its attached
MNs. (WLAN)
BSSID Basic Service Set Identification. A unique identifier of a BSS.
In infrastructure mode, it is the MAC address of the AP.
(WLAN)
BTS Base Transceiver Station. Mobile terminalÆs radio attachment
point to the network. A BTS is responsible for MTs within a
given radio cell.(3GPP, 3GPP2)
ESS Extended Service Set. The set composed of APs and associated
MNs(BSSs) that share a common distribution system. (WLAN)
FA Foreign Agent. A router on a mobile node's visited network
which provides routing services to the mobile node while
registered.
GGSN Gateway GPRS Support Node. A router between the GPRS core
network and an external IP network. (3GPP)
GMM GPRS Mobility Management. Sub-link-layer protocol between the
MT and the SGSN for handling MT movement. (3GPP)
GPRS General Packet Radio Service. Packet-switched data
transmission service on top of the GSM network. (3GPP)
GTP GPRS Tunneling Protocol. A protocol for encapsulating user data
traffic between the SGSN and the GGSN. (3GPP)
HA A router on a mobile node's home network which tunnels
datagrams for delivery to the mobile node when it is away from
home, and maintains current location information for the mobile
node.
IMSI International Mobile Subscriber Identity. A 12-digit number
that uniquely identifies a GPRS subscriber smart card. (3GPP)
Link An association between a host and a link-layer access device
(e.g., IEEE 802.11b access point) for the purpose of IP
connectivity service. In an abstract form, a link is identified
by its end-points. An additional token may be needed to handle
cases when multiple link instances exist between the same
end-points. The actual link identifiers are access technology
and architecture specific.
LLC Logical Link Control. Data link protocol between the MT and
Yegin et. al. Expires April 2004
[Page 5] L2 Hints October 2003
SGSN. (3GPP)
MN Mobile Node. A host or router that changes its point of
attachment from one network or subnet to another.
MN Mobile Node. The conjunction of a Mobile Terminal, a SIM card
and Terminal Equipment. (3GPP)
MT Mobile Terminal. For example, a mobile phone handset or a
PCMCIA card. (3GPP)
MS Mobile Station. For example, a mobile phone or a combination of
mobile terminal (e.g., a phone) and terminal equipment (e.g., a
laptop). (3GPP2)
MUX Multiplex Layer. A link layer protocol used to multiplex
signaling and RLP protocols. (3GPP2)
NSAPI Network Layer Service Access Point Identifier. It is used to
identify a PDP context between MT and SGSN on top of the
Logical Link Control layer. It is set by the MT. (3GPP)
P-TMSI
Packet TMSI. A temporary IMSI allocated by the GPRS network to
the MT upon IMSI attach procedure.(3GPP)
PCF Packet Control Function (3GPP2)
PDP Address
Address of a MN for a given PDP context. (3GPP)
PDP Context
Soft state maintained between the Mobile Terminal, the SGSN and
the GGSN for guaranteeing a negotiated quality of service for
the IP flows exchanged between the GPRS Mobile Terminal and an
external Packet Data Network such as Internet. (3GPP)
PDSN Packet Data Serving Node. The default gateway router for MNs in
3GPP2 networks. (3GPP2)
PLMN Public Land Mobile Network. A GPRS Network operated on a
national territory. (3GPP)
PPP Point-to-Point Protocol
RA Routing Area. Set of adjacent cells. A given number of RAs are
under the control of one SGSN. (3GPP)
RAN Radio Access Network. (3GPP, 3GPP2)
Yegin et. al. Expires April 2004
[Page 6] L2 Hints October 2003
RLP Radio Link Protocol. A link-layer protocol used to improve the
physical-layer frame error rate over the air. (3GPP2)
R-P RAN-to-PDSN interface. Also known as the A10/A11 interface.
(3GPP2)
SGSN Serving GPRS Support Node. A router directly connected to the
GPRS Radio Sub-System that handles the mobility of terminals
attached to the RAs under its authority. The SGSN is also the
Radio Sub-System interface to the GPRS IP core network. It
could be considered as an equivalent to the IEEE 802.11 access
point. (3GPP)
SM Session Management. Sub-link-layer protocol between the MT and
the GGSN that handles the activation/deactivation of a PDP
Context. (3GPP)
SSID Service Set Identifier. Identifier of an ESS. (WLAN)
TE Terminal Equipment. A user's laptop for example. TE can connect
to the network via MT. (3GPP)
TI Transaction Identifier. This is the association between an
NSAPI and an identifier corresponding to an operation performed
on the associated PDP context. For example a "Modify PDP
Context Request" will be identified by a Transaction
Identifier. (3GPP)
TLLI Temporary Logical Link Identity. It is used by the SGSN to
identify a particular Mobile Terminal at the logical link
control layer. (3GPP)
3.0 Link-layer Hints in Various Systems
This section provides an overview of various architectures and
discusses associated link-layer hints.
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.
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.
Yegin et. al. Expires April 2004
[Page 7] L2 Hints October 2003
The GPRS architecture consists of a Radio Access Network and a
packet domain Core Network.
- The GPRS Radio Access Network is composed of Mobile Terminals, a
Base Station Subsystem (BSS) and Serving GPRS Support Nodes (SGSN).
The BSS is made up of radio cells called Base Transceiver Stations
(BTS) served under the control of Base Station Controllers (BSC).
So-called Routing Areas are formed by the subdivision of BSCs. Each
SGSN in the GPRS architecture controls a set of RAs;
- 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.
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.
3.1.1. Network Reference Model
Most of the hints described in this document come from messages
exchanged on top of the Logical Link Control protocol (LLC) running
between the Mobile Terminal and the SGSN. The messages are part of
the GPRS Mobility Management (GMM) and Session Management (SM)
protocols and ensure functionalities such as GPRS attach, detach,
PDP Context activation and deactivation, Routing Area update.
|
+----| <-------------GMM/SM--------------> +-----+
| | <--------------LLC----------------> | |
| | | |
| | \ / | |
| MT | +-----+ |SGSN |
| | Radio interface | |<---------------->| |
| |<----Protocols--->| BSS | | |
+----+ (RLC, MAC, L1) +-----+ +-----+
Figure 1. Signaling protocol stack between MT and SGSN
3.1.2. Link-layer Hints
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 hints 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.
Yegin et. al. Expires April 2004
[Page 8] L2 Hints October 2003
A GPRS attach is made to the SGSN. The procedure is attempted
whenever a GPRS-enabled Mobile Terminal is being switched on. The
attachment can also take place at any time while the MT is switched
on, for example following a detach forced by the network. The MT
provides its identity during the attach request to the network in
the form of a so-called Packet Temporary Mobile Subscriber Identity
(P-TMSI). If the MT has no valid P-TMSI, it provides its IMSI.
Before the MT becomes GPRS attached, it scans for available GPRS
networks, as well as acquires the identities of their cells in the
covered area. It is also possible for the MT to obtain the radio
capabilities of these cells.
When a MT has performed the GPRS attach, it becomes in 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
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. This can be a hint to the
network-layer of the Mobile Node that a GPRS Network has been found
and that the GPRS interface of the MN is attached to it.
The MT is considered detached from the GPRS Network when it has
received/sent a "Detach Accept message" from/to the SGSN. This is an
indication that the link-layer connectivity is being lost.
The "Detach Accept" message is also preceded by a "Detach Request"
message from the side initiating the detachment procedure. This
message is a hint that a detachment from the GPRS network is about
to take place. The network-layer could then anticipate the loss of
connectivity.
The "Attach Accept" message comes along with an update of the Mobile
Terminal Mobility Management context held at the GMM/MM level. This
message contains:
- The Packet Temporary Mobile Station Identifier (P-TMSI). The P-
TMSI is a temporary IMSI allocated by the GPRS network upon attach
(if no P-TMSI was already present). It is used for subscriber
location hiding purpose in substitution to the IMSI.
- The current Cell Identity (CI)
- The current Routing Area Identity (RAI) which identifies the
serving SGSN
- The ciphering algorithm, key (Kc) and sequence number (CKSN)
Yegin et. al. Expires April 2004
[Page 9] L2 Hints October 2003
Once the GPRS MT is attached, the attached network information can
be sent to it via the "MM information" message that contains:
- The network name known as Public Land Mobile Network ID in 3GPP
terminology
- Network registration type (Home or Roaming)
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/from its remote IP peers.
The process by which this is made possible is designated as a PDP
Context Request.
The aim of this function is also to provide IP-level configuration
on top of the GPRS link-layer attachment, in order for the MN to get
IP reachability with external networks, such as Internet. The
establishment of a PDP context is partially based on link-layer
characteristics negotiated between the MT and the GPRS network (SGSN
and GGSN). These characteristics include the QoS profile that will
be guaranteed by the SGSN and GGSN (e.g., maximum delay, link
reliability, peak and mean throughputs). When the MT requests a PDP
context, it selects a Network Service Access Point Identifier
(NSAPI) that it sends to the SGSN with the request. The NSAPI is
sent (as part of the PDP Context request message) on top the Logical
Link Control layer identified for that MT by the TLLI. In this way,
the SGSN is able to uniquely identify the PDP context.
A PDP context Activation procedure can also be initiated by the GGSN
(Network-requested PDP Context Activation) but this alternative is
not likely to happen so often.
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.
Yegin et. al. Expires April 2004
[Page 10] L2 Hints October 2003
+--------------+
| PDP Context1 | +-------+
| NSAPI 1 | | |
| ------------ | +------+ | |
| GPRS MT +-------+ TLLI +---------| SGSN |
| ------------ | +------+ | |
| PDP Context2 | | |
| NSAPI 2 | +-------+
+--------------+
Figure 2. NSAPI and TLLI (link identifier).
A PDP context is considered activated on the MT side as soon as an
"Activate PDP Context Accept" message has been received from the
GGSN. The reception of this message can be considered as a hint that
the GPRS network will be providing a certain link-layer quality-of
service for which parameters (e.g., delay, reliability, throughput)
are included with the messages described below.
When the network is about to modify a PDP Context, it informs the MT
by sending a "Modify PDP Context Request" message. This can also be
an indication at the MN's network-layer that the link-layer
characteristics on the GPRS attachment are about to change. The MN
could then be able to anticipate such a change, which would likely
be a drop or an increase of service quality. The "Modify PDP Context
Accept" message confirms the modification and is a hint that the
initially negotiated PDP context characteristics are no longer
valid.
A "Deactivate PDP Context Request" message is sent by the MN or
received from the SGSN depending on which side has initiated the
deactivation procedure. The transmission or reception of this
message can serve as a hint that the IP configuration of the MN's
GPRS interface or one of its IP configuration (in case multiple PDP
Contexts are present on the MT), is about to be deleted. This could
help the MN anticipate the coming loss of IP attachment. A
"Deactivate PDP Context Accept" sent or received by the MT is a
confirmation that the PDP context is being deleted.
The "Activate PDP Context Accept" message comes along with a
modification of the GMM context that contains the following
information:
- The TI (transaction identifier) associated to the procedure of
activating a PDP context. It consists of the NSAPI generated by the
MT for that PDP context and an operation identifier,
- The IP address for that PDP context,
- The QoS Profile negotiated with the network,
- The Radio Priority level for data transmission.
Yegin et. al. Expires April 2004
[Page 11] L2 Hints October 2003
The "Modify PDP Context Accept" comes along with the following
information:
-The TI associated to the procedure,
-The new QoS profile negotiated with the network,
-The radio priority level for data transmission.
The "Deactivate PDP Context Accept" message comes along with the TI
associated to the procedure.
3.2. 3GPP2
3GPP2 (cdma2000) packet data services provide mobile users wide area
high-speed access to packet switched networks. 3GPP2 consists of
multiple radio access technologies, namely 1x EV, 1x EV-DO and 1x
EV-DV, where the order shows the evolution of technology in the
industry. 1x Evolution Data Only (1x EV-DO) and 1x Evolution Data-
Voice (1x EV-DV) are enhanced air interface technologies that are
optimized for higher data rates.
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.
Yegin et. al. Expires April 2004
[Page 12] L2 Hints October 2003
3.2.1. Network Reference Model
Some of the major components of the 3GPP2 packet network
architecture (see Figure 3) consist of:
- Mobile Node (also known as Mobile Station or Access Terminal in
3GPP2), which allows mobile access to packet-switched networks over
a wireless connection,
- Radio Access Network, which consists of the Base Station
Transceivers (BTS), Base Station Controllers (BSC), and the Packet
Control Function (PCF),
- 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.
+-------------------------+
| RAN |
+====+ | +=====+ +=====+ | +======+
| | | | BSC/| | | | | |
| MN |-----------| | BTS |-------| PCF |--|-------| PDSN |
| | | | | A8/A9 | | |A10/A11| |
+====+ | +=====+ +=====+ | +======+
| |
+-------------------------+
Figure 3. Packet Network Reference Model
Figure 4 shows the hierarchical relationship between the RAN,
PDSN/FA and HA. The control and bearer interfaces between the BSC
and PCF are known as the A9 and A8 interface respectively, while the
control and bearer interfaces between PCF and PDSN are known as the
A11 and A10 interfaces respectively. Note that, the A11/A10
interface is also known as the R-P interface (for RAN-PDSN
interface). The A9 and A11 interfaces are used to establish A8 and
A10 connections. The A8 and A10 connections are used to tunnel link
layer data (PPP frames) between the BSC and PDSN.
Yegin et. al. Expires April 2004
[Page 13] L2 Hints October 2003
+======+
| |
| HA |
| |
+======+
|
|
+--------------+---------------+
| | |
+======+ +======+ +======+
| | | | | |
| PDSN | | PDSN | | PDSN |
| | | | | |
+======+ +======+ +======+
/ \ / \ / \
A10/A11---------/---\------------/---\----------/---\---------
/ \ / \ / \
/ \ / \ / \
+======+ +======+ +======+ \ / \
| | | | | | +======+ +======+
| PCF | | PCF | | PCF | | | | |
| | | | | | | PCF | | PCF |
+======+ +======+ +======+ | | | |
| / \ | +======+ +======+
A8/A9 ----|--------/---\------|----------|-------------|-----
| / \ | | |
+====+ +====+ +====+ +====+ +====+ +====+
| | | | | | | | | | | |
|BSC | |BSC | |BSC | |BSC | |BSC | |BSC |
| | | | | | | | | | | |
+====+ +====+ +====+ +====+ +====+ +====+
+====+
| |
| MS | ------->
| |
+====+
Figure 4. Hierarchical relationship between RAN, PDSN and HA
A PCF controls one or more BSCs. The area served by each PCF is
identified by the Access Network Identifier (ANID). This is referred
to as the SUBNET ID in the 1x EV-DO system. Any given BSC is
associated with one and only one PCF. The combination of BSC and PCF
is also known as the RAN. Each PCF can communicate with one or more
PDSNs. However, for a given mobile user, the PCF typically
establishes a connection with a specific PDSN.
Yegin et. al. Expires April 2004
[Page 14] L2 Hints October 2003
Link-layer-related (e.g., handover) information is provided by the
RAN to the MS via 3GPP2 overhead signaling messages broadcast over
the air interface.
A number of other important components of the architecture that
enable call setup (such as the MSC, HLR, AC and/or AAA servers) are
left out for the sake of simplicity. None of these components have a
direct impact on the discussion of link-layer hints.
3.2.2. Link-layer Hints
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.
MN transitions from DORMANT to ACTIVE state when the MN has some
data to send or the network (PDSN) has data to send to the MN. When
a MN in ACTIVE packet data service state hands off from one RAN to
another, it results in an ANID change. An ANID change may or may not
result in a change in the MN point of attachment to the network
(i.e., PDSN).
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.
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.
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 as a link-layer hint 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
Yegin et. al. Expires April 2004
[Page 15] L2 Hints October 2003
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.
As described above, a lower-layer hint (ANID change) allows a MN to
discover a potential change in the network point of attachment. From
IP's perspective, changes in the PPP link status provide hints about
the network attachment change.
3.3. WLAN
WLANs are the 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.
The IEEE 802.11 series are specified by IEEE since 1997 and the
currently available standards are IEEE 802.11b [802.11b] and IEEE
802.11g [802.11g] operating in the 2.4GHz band, and IEEE 802.11a
[802.11a] operating in the 5GHz band. The specification defines both
the MAC-layer and the physical-layer (e.g., modulation techniques
and radio propagation). The MAC level is the same for all these
technologies.
Two operating modes are available in the IEEE 802.11 series. In
ad-hoc mode, each equipment in range may directly communicate with
each other, i.e. without any infrastructure or intermediate hop. In
the infrastructure mode, all link-layer frames are transmitted to an
access point (AP) which then forwards them to the final receiver.
In this section MN refers to a IEEE 802.11 station without the AP
functionality.
Yegin et. al. Expires April 2004
[Page 16] L2 Hints October 2003
3.3.1. Network Reference Model
In the infrastructure mode, the network connectivity is offered to
MN (IEEE 802.11 station) through an AP. An AP is a bridge between
the wireless domain and the wired domain. The coverage area of an AP
defines a cell. A BSS (Basic Service Set) is composed of one AP and
at least one attached MN. A common IEEE 802.11 infrastructure is
shown in Figure 5.
Access Router-----Internet-----Access Router
| |
| LAN LAN |
-+----+---- -+--------+------+-
| | |
| ~~~~~~~~~~~AP2~~~~~~~~~ |
~~~~~~~AP1~~~~~~~~ ~~~~~~~AP3~~~~~~~~
~ ~ ~ ~ ~ ~
~ ~ ~ ~ ~ ~
~ MN ~ ~ ~ ~ ~
~ ~ ~ ~ ~ MN ~
~ ~ MN ~ ~ ~ ~
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
BSS of AP1 ~ ~ BSS of AP3
~ MN ~
~ ~
~~~~~~~~~~~~~~~~~~~~~~~
BSS of AP2
Figure 5: Architecture of IEEE 802.11 access.
When several APs are connected together through a DS (Distribution
System), the set of all cells is called ESS for Extended Service
Set. The structure of the DS is not defined in the IEEE 802.11
standard and any technology can be used as DS medium. The document
IEEE 802.11f [IAPP] proposes the Inter-AP protocol (IAPP) to be used
between APs of the same ESS. Some information on attached MNs may be
exchanged in an ESS in order to enable context transfers and enhance
MN's roaming.
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
Yegin et. al. Expires April 2004
[Page 17] L2 Hints October 2003
to maintain its ongoing communication sessions, such as Mobile IP
[MIPv4, MIPv6].
A MN must be associated 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 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.
Being associated implies that the MN has established a relationship
with the AP. 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.
Once the MN discovers its target AP and its parameters, an
authentication phase begins (exchange of Authentication
Request/Response).
When a MN succeeds the authentication process, it can associate with
the AP (exchange of Association Request/Response). The MN sends its
different link-layer parameters and the AP may accept to include the
MN in the BSS. A MN may also issue a Re-association Request when the
new AP belongs to the same ESS as the old AP of the MN. The
Re-association message contains the MAC address of the old AP of the
MN, allowing the new AP to inform old AP that the MN will now be
associated with it. It can be noted that even if the two APs belong
the same ESS, they can be on different IP subnets. No assumption is
made on the location of APs in IEEE 802.11 series.
3.3.2. Link-layer Hints
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.
Upon reception of the Association (or Re-association) response
message from the AP indicating that the association is accepted, the
MN is associated to the AP. It can then transmit and receive data
packets through this AP. This association is valid as long as the MN
Yegin et. al. Expires April 2004
[Page 18] L2 Hints October 2003
does not receive a Deauthentication message or a Deassociation
message from its AP, or the MN moves to a new AP.
So the reception of a (Re-)Association Response that completes a
successful association can be taken as a hint that the point of
attachment to the network of the MN may have changed. There is no
mechanism at the link-layer that allows the MN to know if it has
also changed of IP network.
When the MN receives a Deauthentication message or a Disassociation
message, it means that the MN is no longer authenticated or
associated with the AP which sends the message. So this message may
be a hint to indicate that IP packets can not be sent through this
interface until the reception of a subsequent Association Response.
If the MN wants to associate with the AP which sent the message, it
needs to re-authenticate itself.
The link identifier used by the MN is the BSSID (Basic Service Set
Identification). The BSSID is the MAC address of the AP and must
uniquely identify a BSS. However, several SSIDs can be configured on
a single AP, to enable different VLANs for example. So a MN can
switch between two SSIDs and change its network-layer configuration
while connected to the same AP. Therefore, in the context of DNA,
use of (BSSID, SSID) tuple is suggested as the link identifier.
BSSID and SSID information is included in Association Request and
Authentication Request sent by MN, and in Probe Response sent by the
AP.
4.0 Abstraction
Successful usage of link-layer hints by IP depends on the
availability of a common framework. Abstracting useful link-layer
hints is essential for providing interoperability between the
various link-layers and IP. This document limits the scope of hints
to those that are relevant to network-layer configuration changes.
4.1. Link Identifier
An identifier should used to address a link on the host side. Any
given link-layer hint should be accompanied with the associated link
identifier.
In GPRS networks, the relevant link-layer events provide a TI
(Transaction Identifier) that includes NSAPI (Network Layer Service
Access Point Identifier). NSAPI can be used as the link identifier
as it can uniquely identify the associated PDP context.
3GPP2 networks use PPP for the link-layer. Ideally a unique
identifier associated with the PPP instance should be the link
identifier. But the architecture does not provide such a handle. The
closest it provides is ANID (Access Network Identifier), which is
Yegin et. al. Expires April 2004
[Page 19] L2 Hints October 2003
associated with a PCF. A change in ANID (PCF) may or may not result
in a change in PPP link status. When ANID is used as the link
identifier, its change should not be interpreted as a link change
from IP perspective. [TBD: the loose relation between ANID and PPP
link is an issue.]
IEEE 802.11 networks can rely on using the (BSSID, SSID) tuple as
the link identifier.
4.2. Link-up Hint
This hint is asynchronously provided to IP when a new link instance
is created. This hint may be generated even when the host does not
change its physical point-of attachment but creates a new link
instance with the current link-layer access device.
Network-layer may interpret this hint as a sign of possible
configuration change. It may react to link-up hint by reconfirming
its current configuration (e.g.: sending a router solicitation in
the case of stateless IPv6 address auto-configuration). The detailed
use of link-up hint for detecting network attachment is outside the
scope of this draft.
Creation of a new PDP context can be used to generate a link-up hint
in GPRS networks. Similarly, a new PPP link establishment can lead
to a hint in 3GPP2 networks. Note that, these are in reality more
than simple "hints". They usually lead to network-layer
configuration changes some of which take place during the link
establishment (e.g., IP address assignment during PPP link
establishment). [TBD: another term might be needed for these types]
In IEEE 802.11 networks, association and re-association events
indicate that a new link is brought up.
4.3. Link-down Hint
This hint is asynchronously provided to IP when an existing link
instance is removed.
Network-layer may interpret this hint as a sign of possible
configuration change. This hint might be followed by a link-up hint
in the case of a handover. The detailed use of link-down hint for
detecting network attachment is outside the scope of this draft.
The deactivation of PDP context in GPRS networks can be used to
generate the link-down hint. Bringing down a PPP connection in 3GPP2
would have the same effect. De-authentication and disassociation
events in IEEE 802.11 networks can lead to a link-down hint being
sent to IP.
Yegin et. al. Expires April 2004
[Page 20] L2 Hints October 2003
5.0 Security Considerations
The link-layer 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 hint can still be used to launch a
denial-of service attack on the host and the associated network.
Secure generation and delivery of these hints MUST be ensured. This
is a subject for lower-layer designs and therefore it is outside the
scope of this document.
6.0 References
[3GPP2/TIA] "IS-835 - cdma2000 Wireless IP Network Standard"
[3GPP2/TIA] "IS-2001 û Interoperability Specification (IOS) for
cdma2000 Access Network Interfaces"
[GPRS-AT] "Digital cellular telecommunications system (Phase 2+); AT
command set for GPRS Mobile Equipment (ME), (GSM 07.07 version 7.8.0
Release 98).
[GPRS] "Digital cellular telecommunications system (Phase 2+);
General Packet Radio Service (GPRS) Service description; Stage 2",
(3GPP TS 03.60 version 7.9.0 Release 98).
[GPRS-LINK]"Digital cellular telecommunications system (Phase 2+);
Radio subsystem link control", (GSM 03.05 version 7.0.0 Release 98).
[IAPP] IEEE Std. 802.11f/D3, Draft supplement to IEEE Std 802.11,
1999 Edition, "Recommanded Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation", January
2002.
[802.11b] IEEE Std 802 Part 11, "Information technology -
Telecomunications anbd information exchange between systems - Local
and metropolitan area networks - Specific requirements - Part 11:
Wireless Lan Medium Access Control (MAC) And Physical Layer (PHY)
Specifications", August 1999.
[802.11a] IEEE Std 802.11a-1999, supplement to IEEE Std 802.11-1999,
"Part 11: Wireless MAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications: High-speed Physical Layer in the 5 GHZ
band, September 1999.
[802.11g] IEEE Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999
edition, "Part 11: Wireless "Part 11: Wireless MAN Medium Access
Control (MAC) and Physical Layer (PHY) specifications. Amendemnt 4:
Yegin et. al. Expires April 2004
[Page 21] L2 Hints October 2003
Further Higher Data Rate Extension in the 2.4 GHz Band, June 2003.
[MIPv4] Perkins, C., "IP Mobility Support for IPv4", RFC3344, August
2002.
[MIPv6] Perkins, C. and J. Arko, "Mobility Support in IPv6", I-D
draft-ietf-mobileip-ipv6-24.txt, June 2003.
7.0 Acknowledgements
The authors would like to acknowledge Sanjeev Athalye (Qualcomm) and
Muhammad Mukarram bin Tariq (DoCoMo USA Labs) for their useful
comments and suggestions.
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.
A.1. Routing Area and Cell Change
The GPRS Radio Sub-System is organized in sets of Routing Areas
(RAs), each set managed by a unique SGSN. The RAs are in turn
divided into cells.
A GPRS MT detects that it has entered a new cell by comparing the
cell's identity just received with the cell identity stored in the
MT's Mobility Management context. A cell update procedure with the
network then takes place between the MT and the SGSN.
If the new cell is inside a new RA, the MT detects it by
periodically comparing the RA identifier stored in its MM context
with that just received from the new cell and initiates a RA update
procedure with the SGSN. If the SGSN receiving the RA update request
realizes that the old RA is not handled by itself, then it knows
that an inter-SGSN RA update is required. Necessary updates are
performed in the GPRS Network Sub-System:
- The new SGSN starts a handover procedure whereby it requests and
receives the MM and PDP contexts from the old SGSN of the MT, before
packet tunneling can start to the GGSN.
- The MT location is updated in the network.
A.1.1. Hints
Yegin et. al. Expires April 2004
[Page 22] L2 Hints October 2003
The MT initiates the RA update procedure by sending a "Routing Area
Update Request" to the new SGSN. This is potentially a hint to the
IP layer advertising an imminent change of SGSN (GPRS Access Point).
The network confirms that it has updated the RA (SGSN) by sending a
"Routing Area Update Accept" to the MT. The MN can utilize this
message as a hint the MT's SGSN has changed following the handover
procedure.
The accept message comes along with an update of the MM context with
new information as described below:
- New P-TMSI
- New Cell Identity
- New RA Identity
- New ciphering algorithm, key and sequence number
A.2. Sub-link-layer Hints
Some of the information, such as the signal quality (e.g., channel's
Bit Error Rate) and signal level, are not link-layer information but
rather GPRS Radio Link Control (RLC) parameters. Nonetheless, their
knowledge at the network-layer might be useful to assess the
pertinence of deciding to attach in the case where their values are
below the limits which are deemed necessary or required for the
attachment.
The RLC parameters corresponding to the two identified hints are:
- RXLEV, the received signal strength
- RXQUAL, the received signal quality
Authors' Addresses
Alper E. Yegin
DoCoMo Communications Laboratories USA, Inc.
181 Metro Drive, Suite 300 Phone: +1 408 451 4743
San Jose, CA 95110 Fax: +1 408 451 1090
USA email: alper@docomolabs-usa.com
Eric Njedjou
France Telecom R & D
4, Rue du Clos Courtel BP 91226 Phone: +33 299124202
35512 Cesson-S‰vign‰ email: eric.njedjou@france-
telecom.com
France
Siva Veerepalli
Qualcomm, Incorporated.
5775 Morehouse Drive Phone : +1 858 658 4628
San Diego, CA 92131 Fax : +1 734 661 1812
Yegin et. al. Expires April 2004
[Page 23] L2 Hints October 2003
USA email : sivav@qualcomm.com
Nicolas Montavont
LSIIT - University Louis Pasteur Phone: (33) 390244587
Pole API, bureau C430 email: montavont@dpt-info.u-strasbg.fr
Boulevard Sebastien Brant URI: www-r2.u-strasbg.fr/~montavont
Illkirch 67400
France
Thomas Noel
LSIIT - University Louis Pasteur Phone: (33) 390244592
Pole API, bureau C428 email: noel@dpt-info.u-strasbg.fr
Boulevard Sebastien Brant URI: www-r2.u-strasbg.fr/~noel/
Illkirch 67400
France
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Yegin et. al. Expires April 2004 | PAFTECH AB 2003-2026 | 2026-04-23 12:59:40 |