Internet Draft                                     Alper Yegin (Editor)
Document: draft-yegin-dna-l2-hints-01.txt               DoCoMo USA Labs
Expires: August 2004                                       Eric Njedjou
                                                     France Telecom R&D
                                                        Siva Veerepalli
                                                          Qualcomm, Inc
                                                      Nicolas Montavont
                                                            Thomas Noel
                                        LSIIT -University Louis Pasteur



    Link-layer Triggers and 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. Link-layer event notifications
(triggers) along with optional auxiliary data (hints) can help the IP
module make expedited decisions regarding configuration changes. This
draft provides a non-exhaustive catalogue of triggers and hints from
well-known link-layer technologies.











Yegin et al.          Expires April August 2004
[Page 2]                L2 Triggers and Hints            February 2004

Table of Contents

   1.0  Introduction.................................................2
   2.0  Terminology..................................................3
   3.0  Link-layer Triggers and Hints in Various Systems.............6
   3.1.  GPRS........................................................6
   3.1.1.  Network Reference Model...................................7
   3.1.2.  Link-layer Events and Information.........................7
   3.2.  3GPP2......................................................11
   3.2.1.  Network Reference Model..................................11
   3.2.2.  Link-layer Events and Information........................13
   3.3.  WLAN.......................................................14
   3.3.1.  Network Reference Model..................................15
   3.3.2.  Link-layer Events and Information........................17
   4.0  Triggers and Hints..........................................17
   4.1.  Link-up Trigger and Associated Hints.......................18
   4.2.  Link-down Trigger..........................................18
   5.0  Security Considerations.....................................19
   6.0  References..................................................19
   7.0  Acknowledgements............................................20
   Appendix A.......................................................20
   A.1. Routing Area and Cell Change................................20
   A.1.1. Link-layer Information....................................21
   A.2. Sub-link-layer Information..................................21
   Authors' Addresses...............................................22
   Full Copyright Statement.........................................22



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.

   Link-layer event notifications to the IP are considered link-layer
   triggers. From detecting network attachment perspective, an



Yegin et. al.         Expires April August 2004
[Page 3]                L2 Triggers and Hints           February 2004

   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.

   A link-layer trigger 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 triggers 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 triggers and hints that can
   be realistically expected from various access technologies. The
   objective of this draft is to provide a catalogue of existing link-
   layer triggers and hints in various architectures.

   The document limits itself to the minimum set of link-layer triggers
   that are necessary for detecting network attachment. These triggers
   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)



Yegin et. al.         Expires April August 2004
[Page 4]                L2 Triggers and Hints           February 2004


   BSC    Base Station Controller. A BSC controls a set of BTS. (3GPP,
          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)

   LLC    Logical Link Control. Data link protocol between the MT and
          SGSN. (3GPP)

   MN     Mobile Node. A host or router that changes its point of
          attachment from one network or subnet to another.





Yegin et. al.         Expires April August 2004
[Page 5]                L2 Triggers and Hints           February 2004

   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)

   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



Yegin et. al.         Expires April August 2004
[Page 6]                L2 Triggers and Hints           February 2004

          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 Triggers and Hints in Various Systems

   This section provides an overview of various architectures and
   discusses associated link-layer triggers and 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.
   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).



Yegin et. al.         Expires April August 2004
[Page 7]                L2 Triggers and Hints           February 2004

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

   When connecting, first a GPRS attach needs to be 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.



Yegin et. al.         Expires April August 2004
[Page 8]                L2 Triggers and Hints           February 2004


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

   The "Detach Accept" message is also preceded by a "Detach Request"
   message from the side initiating the detachment procedure. This
   message is an indication 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)

   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



Yegin et. al.         Expires April August 2004
[Page 9]                L2 Triggers and Hints           February 2004

   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.

   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.


               +--------------+
               | PDP Context1 |                        +-------+
               |   NSAPI 1    |                        |       |
               | ------------ |       +------+         |       |
               |   GPRS MT    +-------+ TLLI +---------| SGSN  |
               | ------------ |       +------+         |       |
               | PDP Context2 |                        |       |
               |   NSAPI 2    |                        +-------+
               +--------------+

            Figure 2. NSAPI and TLLI (link identifier).





Yegin et. al.         Expires April August 2004
[Page 10]               L2 Triggers and Hints            February 2004

   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 trigger
   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 an indication 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 trigger 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.

   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.









Yegin et. al.         Expires April August 2004
[Page 11]               L2 Triggers and Hints            February 2004

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.


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



Yegin et. al.         Expires April August 2004
[Page 12]               L2 Triggers and Hints            February 2004

   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.


                                   +======+
                                   |      |
                                   |  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






Yegin et. al.         Expires April August 2004
[Page 13]               L2 Triggers and Hints            February 2004

   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.

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

   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.





Yegin et. al.         Expires April August 2004
[Page 14]               L2 Triggers and Hints            February 2004

   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.

   As described above, a lower-layer indication (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 a trigger and 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 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
   other, i.e. without any infrastructure or intermediate hop. In
   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 August 2004
[Page 15]               L2 Triggers and Hints            February 2004

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
   to maintain its ongoing communication sessions, such as Mobile IP
   [MIPv4, MIPv6].



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.

   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.

   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. Note that even if the two APs belong to the same
   ESS, they can be on different IP subnets. No assumption is made on
   the location of APs in IEEE 802.11 series.

   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



Yegin et. al.         Expires April August 2004
[Page 17]               L2 Triggers and Hints            February 2004

   the synchronization of the session key. This triggers the change of
   the state of the IEEE 802.1X port from blocked to unblocked.
   Subsequently, data packets can be exchanged on the link.


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.

   In a WLAN that does not support RSN, 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 does not receive a
   De-authentication message or a De-association 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 conveys that the MN's point of attachment to
   the network may have changed. There is no mechanism at the link-
   layer that allows the MN to know if it has also changed the IP
   subnet.

   In a RSN, data packets between the MN and the AP are allowed upon
   successful completion of a 4-way handshake. In this case, the
   reception of a (Re-)Association Response does not imply the link is
   established yet.

   When the MN receives a De-authentication message (in the case of the
   MAC layer authentication) or a Disassociation message, it means that
   the MN is no longer authenticated or associated with the AP that
   sent the message. So this message indicates that IP packets can not
   be sent through this link until the reception of a subsequent
   (Re)Association Response or 4-way handshake.


4.0  Triggers and Hints

   A small set of useful link-layer triggers and hints can be
   identified based on the technologies described in Section 3.0. This
   document limits the scope to those that are relevant to network-
   layer configuration changes.






Yegin et. al.         Expires April August 2004
[Page 18]               L2 Triggers and Hints            February 2004

4.1. Link-up Trigger and Associated Hints

   This trigger is asynchronously provided to IP when a new link
   instance is created. This trigger 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 trigger as a sign of possible
   configuration change. It may react to link-up trigger 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 trigger 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
   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.

   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.


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.

   The deactivation of PDP context in GPRS networks can be used to
   generate the link-down trigger. Bringing down a PPP connection in
   3GPP2 would have the same effect. De-authentication and
   disassociation events in IEEE 802.11 non-RSN, and disassociation




Yegin et. al.         Expires April August 2004
[Page 19]               L2 Triggers and Hints            February 2004

   event in IEEE 802.11 RSN can be used to generate a link-down trigger
   being sent to IP.


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.


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.




Yegin et. al.         Expires April August 2004
[Page 20]               L2 Triggers and Hints            February 2004

   [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:
   Further Higher Data Rate Extension in the 2.4 GHz Band, June 2003.

   [80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD FOR
   Telecommunications and Information Exchange between Systems û
   LAN/MAN Specific Requirements - Part 11: Wireless Medium Access
   Control (MAC) and physical layer specifications: Specification for
   Enhanced Security", August 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.

   [DNA4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
   I-D draft-ietf-dhc-dna-ipv4-05.txt, January 2004.


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



Yegin et. al.         Expires April August 2004
[Page 21]               L2 Triggers and Hints            February 2004

   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. Link-layer Information

   The MT initiates the RA update procedure by sending a "Routing Area
   Update Request" to the new SGSN. This is potentially an indication
   of
   an imminent SGSN change (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 an indication that 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 Information

   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 information
   are:

   - RXLEV, the received signal strength
   - RXQUAL, the received signal quality










Yegin et. al.         Expires April August 2004
[Page 22]               L2 Triggers and Hints            February 2004

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



Yegin et. al.         Expires April August 2004
[Page 23]               L2 Triggers and Hints            February 2004


   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 August 2004