Internet DRAFT - draft-hossam-igprs
draft-hossam-igprs
Mobile IP Working Group Hossam Afifi
INTERNET DRAFT INT Evry
13 February 2002 Charles E. Perkins
Hannu Flinck
Nokia Research Center
Lionel Morand
France Telecom RD
Internet General Packet Radio Service (IGPRS) Service Description
draft-hossam-igprs-01.txt
Status of this Memo
This document is an individual contribution for consideration by
the Mobile IP Working Group of the Internet Engineering Task Force.
Comments should be submitted to the mailing list.
Distribution of this memo is unlimited.
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
We describe a protocol architecture for the integration of Mobile
IPv6 into the GPRS architecture (UMTS version). The goal of this
architecture is to provide mobility management and authentication
to native IP protocols through the legacy cellular signaling. It
co-exists with the cellular protocols and re-uses a certain set of
them. Moreover, the IGPR architecture supports GPRS roaming by
keeping its database (HLR) consistent. The IGPRS architecture is
based on a set of servers that co-exist with the GPRS entities and
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page i]
Internet Draft IGPRS 13 February 2002
hence support GPRS terminals by maintaining the air interface and the
necessary state machines. IGPRS is hence a data protocol stack for
operators who want to use the UMTS air interface combined with Mobile
IP.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page ii]
Internet Draft IGPRS 13 February 2002
Contents
1. Introduction 1
2. Scope and Scenario of Operation 1
3. Abbreviations and Terminology 1
3.1. MAP Messages List . . . . . . . . . . . . . . . . . . . . 3
3.2. Functions List . . . . . . . . . . . . . . . . . . . . . 3
3.3. Errors List . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Timers List . . . . . . . . . . . . . . . . . . . . . . . 4
3.5. State List . . . . . . . . . . . . . . . . . . . . . . . 4
3.6. Mobile IPv6 Sub-Options List . . . . . . . . . . . . . . 4
4. Protocol and Architecture Overview 6
4.1. Protocol Entities and Identification . . . . . . . . . . 6
4.1.1. Identification . . . . . . . . . . . . . . . . . 8
4.1.2. Address Assignment and Lower Layer Assumptions . 8
4.2. The Mobile Node and IGSS State Machines . . . . . . . . . 8
4.2.1. PMM-DETACHED State . . . . . . . . . . . . . . . 8
4.2.2. PMM-IDLE State . . . . . . . . . . . . . . . . . 9
4.2.3. PMM-CONNECTED State . . . . . . . . . . . . . . . 9
4.3. State transition in the MN and IGSS . . . . . . . . . . . 9
4.3.1. Moving from PMM-DETACHED to PMM-CONNECTED . . . . 10
4.3.2. Moving to PMM-DETACHED . . . . . . . . . . . . . 10
4.3.3. Moving from PMM-IDLE to PMM-CONNECTED . . . . . . 11
5. Migrating GPRS to IGPRS 11
6. IGPRS Procedures and Functions 11
6.1. Periodic RA Update Timer Function . . . . . . . . . . . . 11
6.2. Mobile Reachable Timer Function . . . . . . . . . . . . . 12
6.3. Attach Function . . . . . . . . . . . . . . . . . . . . . 12
6.3.1. Stateless Address Autoconfiguration . . . . . . . 12
6.3.2. Same Domain Routing Update . . . . . . . . . . . 13
6.3.3. Inter-IGSS Attach . . . . . . . . . . . . . . . . 14
6.3.4. Erroneous Attach . . . . . . . . . . . . . . . . 15
6.4. Detach Function . . . . . . . . . . . . . . . . . . . . . 16
6.5. Updating the HLR . . . . . . . . . . . . . . . . . . . . 16
7. Security Functions and Data Elements 17
7.1. Authentication of Subscriber . . . . . . . . . . . . . . 17
7.2. P-TMSI Signature . . . . . . . . . . . . . . . . . . . . 19
8. Message Formats 20
8.1. IMSI/MSISDN transport in NAI . . . . . . . . . . . . . . 20
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page iii]
Internet Draft IGPRS 13 February 2002
8.2. Messages for an attach procedure: first time . . . . . . 20
8.2.1. Messages for attach within the AAA domain . . . . 21
8.2.2. IGSS to HA and HLR . . . . . . . . . . . . . . . 21
8.2.3. AAAH to AAAF IGSS . . . . . . . . . . . . . . . . 23
8.2.4. IGSS to AR . . . . . . . . . . . . . . . . . . . 23
8.2.5. Authentication Error . . . . . . . . . . . . . . 23
8.2.6. Detach . . . . . . . . . . . . . . . . . . . . . 23
8.3. Messages for an attach procedure: inter-IGSS . . . . . . 24
8.3.1. Second Time Attach . . . . . . . . . . . . . . . 24
8.3.2. IGSS Response . . . . . . . . . . . . . . . . . . 24
8.4. Link Layer messages . . . . . . . . . . . . . . . . . . . 24
8.4.1. Router Advertisements . . . . . . . . . . . . . . 24
8.4.2. Link layer indications . . . . . . . . . . . . . 26
8.4.3. Router Advertisements . . . . . . . . . . . . . . 26
8.4.4. Link layer Requirements . . . . . . . . . . . . . 26
9. Additional Security Considerations 27
Addresses 31
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page iv]
Internet Draft IGPRS 13 February 2002
1. Introduction
The IGPRS architecture aims at the integration of the IPv6 protocol
[IPv6 ] in the GPRS [GPRS ] infrastructure. The IGPRS data and
signaling protocol suite is based on Mobile IPv6 [mipv6 ]. It uses
the existing GPRS infrastructure for lower layer data and signaling
transport. Since IGPRS is targeted to co-exist with GPRS, it
specifies also a translation of MAP [MAP ] specifications to Internet
protocols and the transport of RANAP [RANAP ] into DIAMETER messages.
IGPRS uses Mobile IPv6 as the data protocol and DIAMETER [diam ]
as the main signaling protocol for Authentication, Authorization,
and Accounting [AAA ]. At the boundaries we interface the Internet
protocols with the conventional GPRS entities (e.g. HLR) in order
to keep the necessary user management consistency. The IGPRS
interface will be complementary to GPRS protocols and co-exist with
them. Hence, it enables a smooth migration to a Mobile IPv6 enabled
network.
An IGPRS terminal will be able to directly use the Internet (or
intranet) infrastructure for data and signaling transmission. A
GPRS Radio Network Controller that has this additional function will
be able to translate all the traffic coming from an enhanced GPRS
terminal to a conventional IPv6 protocol suite. We assume that
the identification of the subscriber is based on the GPRS network
procedures, through the use of IMSI or the MSISDN.
2. Scope and Scenario of Operation
This specification will produce MIPv6 connectivity in an
infrastructure that can be built on top of existing GPRS systems.
This infrastructure exploits GPRS lower layer (link and physical).
It interworks with HLRs/VLRs. It does not however use GPRS main data
plain infrastructure (GTP) since this is provided by Mobile IPv6.
This specification allows a Mobile Node to start a session in IGPRS
and terminate it in GPRS or vice versa.
3. Abbreviations and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [rfc2119 ].
This document uses terms defined in Mobile IPv6 [mipv6 ], Neighbor
Discovery [nd], and Stateless Address Autoconfiguration [AUTO ]. In
addition, this document uses the following terms:
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 1]
Internet Draft IGPRS 13 February 2002
Access Router
(AR) the router offering connectivity to the mobile node
at IP network level.
HLR The active database storing AAA information in public
cellular networks.
IGSS Internet GPRS Support Server. The main authentication
node. AAAF
IMEI Terminal H/W identification.
IMSI International Mobile Subscriber Identity.
Kc The key used for GSM/GPRS ciphering (8 bytes).
Ki The secret key related to an IMSI stored in HLR and MN.
NAI Network Access Identifier.
MIPv6 Mobile IPv6.
MN Mobile Node.
MSISDN Mobile Station International ISDN Number
RA Routing Area; space of administration for a single IGSS
server.
RAC Routing Area Code; AR IPv6 address.
RAND Random number (16 bytes) used to authenticate GSM/GPRS
users.
RNC Radio Network Controller.
SIM SIM Subscriber Identity Module.
SRES Authentication result (4 bytes) obtained by hashing RAND
with a secret key.
TBF Temporary Block Flows.
TLLI Temporary Logical Link Identity.
TMSI Temporary Mobile Subscriber Identity (5 bytes).
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 2]
Internet Draft IGPRS 13 February 2002
3.1. MAP Messages List
The messages in this section are the relevant messages from the MAP
specification [MAP ].
Send_Authentic_Info_Ind
Sent to the HLR to request authentication information
for a given IMSI.
Send_Authentic_Info_Pos_Rsp
Authentication set list response containing necessary
authentication keys for a given IMSI.
Check_IMEI_Ind
Message Sent to verify the terminal identity through
the IMEI identifier.
Check_IMEI_Pos_Rsp
Answer from the EIR about equipment status
SendParameters
Operation done by the AAAH to request the MN secret key
Ki
Update_Location_Ind
Message sent to update the HLR for a given IMSI.
Update_Location_Pos_Rsp
Response to UpdateLocationInd from the HLR.
Insert_Subscriber_Data_Req
Message sent from the HLR to assert a subscriber in a
new authentication server.
Cancel_Location_Req
Message sent from the HLR to cancel a IMSI entry.
Open_Req
Message sent to begin a new MAP dialogue between two
MAP service users.
Close_Req
Message sent to release an active MAP dialogue.
3.2. Functions List
Attach A set of procedures that enable the mobile node to
configure a valid global address.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 3]
Internet Draft IGPRS 13 February 2002
Detach A set of procedures to disconnect the mobile node.
3.3. Errors List
DIAMETER_ERROR_AUTH_FAILURE
Diameter Error when Authentication fails (AMAv6)
IGPRS Authentication_Error_Reject
Error code sent in BA (code 139).
3.4. Timers List
Periodic RA Update Timer
Maintained in Mobile Node to send a BU
Mobile Reachable Timer
Maintained in IGSS to cancel the MN entry
3.5. State List
PMM-DETACHED Maintained in the MN. Means that the mobile is not
communicating.
PMM-IDLE Maintained in Mobile Node and IGSS. Means that the mobile
was communicating but that it currently does not have a
valid care-of address.
PMM-CONNECTED Maintained in the Mobile and IGSS. Means that the
authentication and mobility management are up to date and
that the mobile can communicate. It means also that a
signalling channel is established with the RNC.
3.6. Mobile IPv6 Sub-Options List
IMSI
Allows the MN to identify itself (BU).
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 4]
Internet Draft IGPRS 13 February 2002
MSISDN
An option that allows to identify a node by its ITU-T
telephone number.
P-TMSI
An option that allows to send/receive a shared key
with the MN (BU and BA).
P-TMSI signature
An option that enables the MN to sign
the P-TMSI sub-option (BU).
RAND
A Nonce that protects against replay.
Previous Care-of Address
It allows the MN to advertise about
its old address.
IMSI Attach Confirm
Allows the MN to send its identity and to
confirm the attachment to
the AR (BU) and then to the IGSS (Optional).
DIAMETER Command List and Features
AMRv6 AA-Mobile-Node-Request-v6 sent from the AAAF to the AAAH
AMAv6 AA-Mobile-Node-Answer-v6 sent from the AAAH to the AAAF
HARv6 Home-Agent-Request-v6 Update to the HA sent from the AAAH
HAAv6 Home-Agent-Answer-v6 Confirmation from the HA to the AAAH
Features MIPv6-Feature-Vector
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 5]
Internet Draft IGPRS 13 February 2002
4. Protocol and Architecture Overview
In this section we describe the main organization of IGPRS, the
different entities and the organization of the overall system.
4.1. Protocol Entities and Identification
The GPRS architecture is divided into a control plane and a data
plane. It is mainly composed of a mobile node (MN), a base station
controler (RNC in UMTS), a tunneling end-point (SGSN), a router
to external data networks (GGSN) and databases (HLR and MSC/VLR).
Data is tunneled through the GPRS Tunneling Protocol (GTP-U). The
figures below show a simplified view of the GPRS data plane. The
architecture is different for GSM than for UMTS.
MS BSS SGSN GGSN HLR MSC/VLR(optional)
+--------+ +------+ +------+ +-----+ +------+ +-----+
|IP | | | | IP | | IP | | MAP | | MAP |
|--------| | | | GTP | | GTP | | SS7 | | SS7 |
| LLC | | | +------+ +-----+ +------+ +-----+
| RLC | | RLC |
| MAC | | MAC |
| GSM/RF | |GSM/RF|
+--------+ +------+
Figure 1: GPRS protocol and entities in the GSM
The proposed IGPRS protocol suite will co-exist with the legacy GPRS
(UMTS) infrastructure, re-use most of its components and lower layers
and replace it in later versions.
We first define the IGSS, which will co-exist with the SGSN. The IGSS
is a Authentication-Authorization-Accounting (AAA) server running
IPv6 with additional DIAMETER, routing and security functions. It is
not simply named a AAA server because it has to support several other
procedures that are not in the scope of the AAA. The MIPv6 Home Agent
typically co-exists with the GGSN.
The RNC implements IP routing and plays the role of an access router.
The mobile node implements the GPRS layers in addition to Mobile
IPv6.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 6]
Internet Draft IGPRS 13 February 2002
MS RNC SGSN GGSN HLR
+--------+ +------------+ +----------+ +-----+ +-----+
|IP | | | | | IP | | IP | | MAP |
|--------| | | | | GTPr| | GTPr| | SS7 |
| RRC | | RRC |RANAP| |RANAP | +-----+ +-----+
| RLC | | RLC |SS7 | | SS7 |
| MAC | | MAC | | +----------+
| UTRAN | |UTRAN | |
+--------+ +------+-----+
Figure 2: GPRS protocol and entities in the UMTS (Control Plane)
AAAF
MN RNC IGSS@SGSN HA@GGSN AAAH HLR
+------+ +----------+ +--------+ +-----+ +--------+---+
|MIPv6 | |(MIPv6) | |DIAMETER| |MIPv6| |DIAMETER|MAP|
|------| |----------| | | | | | | |
| PDCP | |PDCP| | +-----+--+ +-----+ +--------+---+
+------+ +----|RANAP| |RANAP| |
| UMTS | |UMTS| | +-----+--+
+------+ +----|-----+ @ means co-resident with
Figure 3: IGPRS protocols and entities
In our design, IPv6 is implemented on top of the physical layer
and layer 2 of the GPRS protocol. We identify the Mobile node MN,
RNC, IGSS, HLR interface and MSC/VLR interface as the entities
representing IGPRS. The MN interacts with the RNC and with its Home
Agent.
Mobile IPv6 is only seen between the MN, the IGSS (through DIAMETER)
and the HA. The rest of the entities are not part of the mobility
process. We describe in the following section the interaction of the
IPv6 layer with GPRS states. Two groups of procedures in the IGPRS
proposal are affected by timers from the GPRS. The first procedures
are necessary to save air interface resources and to rapidly detect
any MN disappearance. They are the same functions used in the GPRS.
The second set of procedures corresponds to mobility management at
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 7]
Internet Draft IGPRS 13 February 2002
the network level. The IGSS initiates security functions and updates
the HLR with any necessary mobility management information.
4.1.1. Identification
The identification of a MN is based on information built in the
subscriber identification module. IGPRS can use two different
identifiers. The first is the IMSI [imsi ]. It is a number usually
assigned with the subscription of the MN to the network. It usually
remains hidden in the network and is mainly used in the GPRS/GSM
network. The second is the MSISDN. It corresponds to the telephone
number assigned to the MN and is a public information. The MN may
use two identifications if it needs to authenticate itself to a
different ISP than the public operator.
4.1.2. Address Assignment and Lower Layer Assumptions
The MN uses Stateless Address Autoconfiguration [AUTO ] and Router
Advertisements [nd] to get its careof address.
It is to be noted that IGPRS uses one address only for signalling
(mobility and authentication). This does not mean that the MN is
unable to obtain additionnal addresses. IGPRS is based on the IPv6
specifications and hence a MN can create as many as addresses as
necessary by the normal IPv6 configuration procedures.
4.2. The Mobile Node and IGSS State Machines
IGPRS Mobility Management for IPv6 is compatible with the three
different GPRS states, maintained in both the MN and SGSN. IGPRS uses
the same state transition diagram as GPRS. The goal of maintaining
these states tight is to piggyback IPv6 mobility management (BU,
BA, RA,...) into GPRS Radio Resource (RRC) signaling. Each state
describes a certain level of activity and information management.
When the mobile node expects to send or receive user data, it
configures a valid IPv6 care-of address. The network layer in both
the mobile node and IGSS will be able to maintain the current state
of the entity along with the related state variables and to achieve
the necessary procedures.
4.2.1. PMM-DETACHED State
In GPRS PMM-DETACHED state, the subscriber does not execute mobility
management procedures. Cached information in the MN and IGSS is not
valid.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 8]
Internet Draft IGPRS 13 February 2002
Data transmission to and from the mobile node as well as the paging
of the MN are not possible in PMM-DETACHED state. The IGPRS mobile
node is seen as not reachable in this case. The mobile node does
not necessarily have a care-of address or valid default router. It
typically maintains its existing home agent and home addresses. In
order to establish contexts in the MN and the IGSS, the MN performs
the IGPRS Attach procedure explained in Section 6.3.
4.2.2. PMM-IDLE State
The PMM-IDLE state is temporary. The MN has been authenticated
by IGPRS. The MN and IGSS have established contexts for the user
based on the selected identifier (IMSI or MSISDN). Pages for data
or signaling information may be received. Data transmission is not
possible in this state. The MN listens for router advertisements.
Either the MN or the network may initiate the IGPRS Detach procedure
(see section 6.4) to move to the PMM-DETACHED state. After the
``mobile-reachable'' timer expires the IGSS may perform an implicit
detach in order to return to PMM-DETACHED state.
4.2.3. PMM-CONNECTED State
In PMM-CONNECTED state, the IGSS updates the MN state stored locally
with its care-of address. The IGSS receives the MN care-of address
through DIAMETER extensions as explained in Section 6.3.1.
When a mobile node makes a hand-over to a new cell, the default
router may change according to the network topology. The MN learns
its new default router through router advertisements. It has to
periodically authenticate itself through BU messages. The MN may
send and receive IPv6 packets in PMM-CONNECTED state. Whether or
not a radio resource is allocated to the subscriber, the MN remains
in the PMM-CONNECTED state even when no data is being communicated.
The PMM-CONNECTED state is controlled by a timer. When the mobile
node transitions from PMM-CONNECTED state to PMM-DETACHED state, the
information stored in its routing tables node SHOULD be invalidated.
The IGSS may also flush the information it has stored concerning the
MN. In order to transit from PMM-CONNECTED state to PMM-DETACHED
state, the MN initiates the IGPRS Detach procedure (see section 6.4).
This means that the mobile node's care-of address is no longer valid.
4.3. State transition in the MN and IGSS
This section gives details on the events when a MN changes its state.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 9]
Internet Draft IGPRS 13 February 2002
A state transition depends on the current state (PMM-DETACHED,
PMM-IDLE, or PMM-CONNECTED) and the event which occurred (e.g., IGPRS
attach). We describe the necessary IPv6 actions when each such
transition happens.
+------------+ +------------+
/|PMM-DETACHED| /|PMM-DETACHED|
/ +------------+ / +------------+
/ / \ / / \
| V ^ | V ^
| | | ^ | |
| \ / | \ /
| +-------------+ | +-------------+/ \
^ |PMM-CONNECTED| ^ |PMM-CONNECTED| v
| +-------------+ | +-------------+\_/
| / \ | / \
| V ^ | V ^
| | | | | |
\ \ / \ \ /
\ +--------------+ \ +----------+
\|PMM-IDLE | \| PMM-IDLE|
+--------------+ +----------+
MN IGSS
Figure 4: MM state diagrams for MN and IGSS
4.3.1. Moving from PMM-DETACHED to PMM-CONNECTED
This requires executing the IGPRS Attach procedure. The MN requests
access, and a logical link to the AR is set up (see Section 8.4.4).
DIAMETER authentication MAY be initiated if necessary (see the
different cases in Section 6.3.1). After the state transition is
complete, the MN is ready to send and receive data.
4.3.2. Moving to PMM-DETACHED
After moving to the PMM-DETACHED state, the MN is not allowed to
use its care-of address. A router advertisement with lifetime set
to zero will be sent to the node. The care-of address SHOULD be
obsoleted by sending a ICMPv6 ``host unreachable'' to the HA. The AR
when advised by the IGSS that it should detach the MN will send this
ICMPv6 packet.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 10]
Internet Draft IGPRS 13 February 2002
The MN goes into PMM-DETACHED state after executing either of these
functions:
- Detach: The IGSS returns to PMM-DETACHED after expiration of the
Mobile Reachable timer. This can happen also in the MN by receiving
a ``PMM-IDLE failure'' signal from the MAC layer. The MN may ask
explicitly to detach itself by sending a zero lifetime BU to the HA
(See Section 6.4).
- Cancel_Location: The IGSS acting as a AAAH receives a MAP
Cancel_Location_Req message from the HLR. The AAAH forwards
a Session Termination DIAMETER message to the HA, a Session
Termination DIAMETER message to AAAF and in turn to the access
router. The AR sends a ``Router Advertisement'' message with
Lifetime set to zero to the MN.
4.3.3. Moving from PMM-IDLE to PMM-CONNECTED
The mobile node moves from PMM-IDLE to PMM-CONNECTED state when it
sends any packet with IGPRS specific authentication information (note
that the packet should contain a BU with P-TMSI, P-TMSI signature
sub-options).
5. Migrating GPRS to IGPRS
The scope of this section is to define the necessary gateways and
protocol conversion functions to let a soft migration between current
GPRS Release 99 and Release 4 to IGPRS.
This work is in progress. Refer to authors.
6. IGPRS Procedures and Functions
This section describes functions related to timers and to mobility
management maintained for IGPRS in both the MN and network sides.
6.1. Periodic RA Update Timer Function
When the MN sends IPv6 packets to the AR, they are normally routed to
their destination. When the MN sends BUs with IGPRS authentication
sub-options, they SHOULD be sent to the AR. In this case the AR
has to take a specific action concerning IGPRS and build DIAMETER
AMR messages as described later. The Periodic Routing Area Update
Timer function controls the periodic transmission of BU with IGPRS
Authentication messages from the MN. The BU messages containing IGPRS
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 11]
Internet Draft IGPRS 13 February 2002
specific authentication data are sent to the AR. They are forwarded
through DIAMETER extensions to the IGSS acting as the AAAF for this
routing area (this is the same terminology used in GPRS).
When the Routing Area update timer expires, the MN starts a Periodic
Routing Area Update procedure by sending a binding update to the AR
(see Section 6.3.2) with the P-TMSI authentication.
6.2. Mobile Reachable Timer Function
The Mobile Reachable Timer function resides in the IGSS. It controls
the transition from the PMM-IDLE state to the PMM-DETACHED state.
The ``Mobile Reachable Timer'' is slightly longer than the periodic
Routing Area update timer used by an MN. It is stopped when the
PMM-CONNECTED state is entered, reset and started when the state
returns to PMM-IDLE. When the timer expires, no more IGPRS messages
are sent to the MN. Therefore, the IGSS acting as AAAF sends a
DIAMETER message to the IGSS acting as AAAH that forwards the Session
Termination to the HA.
6.3. Attach Function
An IGPRS attach is made with the access router, local IGSS, HA and
results in validating the MN global IPv6 address.
In the attach procedures, the MN provides its identity as explained
in Section 7.1. A Temporary identification should also be used
(P-TMSI). After having executed the IGPRS attach, the MN is in
PMM-CONNECTED state.
If the Attach Request cannot be accepted, the IGSS returns a
Result code AVP with DIAMETER_ERROR_AUTH_FAILURE error code (see
section 8.2.5) in a DIAMETER session termination message. This is
sent to the AAAF and AR. The AR sends a BA with Status field set with
the Authentication Error code.
6.3.1. Stateless Address Autoconfiguration
The attach function covers several situations. The first happens
when the MN is attached to the network for the first time. We assume
that the MN has pre-configured HA and Home Addresses. If this is not
the case, the MN uses the extensions described in [diammip ] in order
to ask for a permanent HA. The attach procedure is then augmented in
the IGPRS system with an access to the HLR (AAAH may request from
its HLR information about the most appropriate HA for the current MN
location).
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 12]
Internet Draft IGPRS 13 February 2002
Authentication (optional in this version) is performed between the MN
and access router using the MIPv6 sub-options field as described in
Section 7.1. It is continued between the access router and IGSS with
DIAMETER extensions. The current draft specification uses the same
authentication procedures as in the GPRS. This leads to an efficient
unique authentication.
It is also to be noted that ciphering should not be used in the GPRS
since it can be replaced by an IPv6 level ciphering according to
users needs.
In the attach procedure, the MN sends a Binding Update to the HA with
a signature involving its secret key. This signature (called SRES
in GPRS) is forwarded in a DIAMETER AMRv6 message to the IGSS. After
the MN is authenticated, the IGSS may send back a P-TMSI that will be
used for any subsequent authentication to the same IGSS.
+-------+ MAP +-------+ HAR +-------+
| HLR |------| AAAH |--------| HA |
+-------+ +-------+ HAA +-------+
\
\
AMA \AMR
\
+------+ BU,BA +----+ AMR +------+
| MN |-------| AR |-----| IGSS |
+------+ +----+ AMA +------+
Figure 5: Attach function for a first time
6.3.2. Same Domain Routing Update
The attach function in the same AAA domain is faster. The AR
receives the BU destination option with the IMSI, P-TMSI, P-TMSI
signature and Old Prefix sub-option fields. It is translated to
an AMRv6 DIAMETER message and sent to the IGSS acting as the AAAF.
This BU is sent to the AR as a destination of the packet. The
IGSS validates directly the request without going to the HLR. Upon
approving the MN, the IGSS (AAAF) sends back a DIAMETER reply (AMAv6)
to the access router to update the MN. The AMRv6 is forwarded in the
same time to the HA (across the AAAH) to establish the necessary IPv6
data forwarding.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 13]
Internet Draft IGPRS 13 February 2002
AAAF AAAH
+------+ BU +----+ AMR +------+ +------+ +----+
| MN |------| AR |------| IGSS |--| IGSS |--| HA |
+------+ BA +----+ AMA +------+ +------+ +----+
Figure 6: Attach function for a second time.
6.3.3. Inter-IGSS Attach
This function is called an Inter-IGSS attach because it consists
in a change of AAAF server for the mobile node. Note that the HA
typically SHOULD not change. The MN sends a BU destination option
(IMSI, P-TMSI, P-TMSI signature, old prefix) to the access router.
The access router builds a DIAMETER AMRv6 message and sends it to the
IGSS. The new AAAF IGSS sends DIAMETER Mobile IPv6 Request message to
the home IGSS (AAAH) containing its new address.
Application level routing in the DIAMETER protocol should be used
to force the AMRv6 to go through the previous IGSS. If the MN is
still authenticated in this previous IGSS it shall answer with a AMA
message. The new IGSS knows about the old one by the Old Prefix
information. Application level routing is optional. It corresponds
to the GPRS design model and may improve the authentication procedure
response time. The AMRv6 message is still forwarded to the AAAH to
let the HA update the forwarding tables.
An Authentication Request MAP message (see section 6.5) is sent to
the HLR to retrieve the necessary information.
AAAH sends a DIAMETER Session Termination Indication (STI) to the old
IGSS (old AAAF).
AAAH updates the HLR with the new AAAF address (MAP Update Location).
If the HLR sends back a Insert Subscriber Data with the GPRS
subscription information, the AAAH will have to answer back and
either confirm or reject the presence of the MN in its routing
area (Insert Subscriber Data Ack MAP message). If the security
functions fail to authenticate the MN or the MN is not allowed
to roam in the area, then the AMRv6 message is rejected, and the
new IGSS returns a DIAMETER AMAv6 with Result-Code AVP set to
DIAMETER_ERROR_AUTH_FAILURE. The Access Router sends a BA with the
IGPRS-authentication-Reject error code (139) Status Field.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 14]
Internet Draft IGPRS 13 February 2002
HAAv6
+-------+ MAP +-------+ HARv6+-------+
| |-----+ IGSS +------+ |
| HLR | ---+ AAAH |--- | HA |
+-------+ / +-------+ \ +-------+
/ \
/ \
AMRv6 / AMAv6 AMRv6 \ AMAv6
/ \
AAAF / \
+----------+ +-----------+
| New IGSS | | Old IGSS |
+----------+ +-----------+
| AAAF
AMRv6|AMAv6
|
+------+
| AR |
+------+
RS | RA
BU | BA
|
+-------+
| MN |
+-------+
Figure 7: Attach function in a new domain
When authentication succeeds the new IGSS updates its own registers
with the MN entry (new care-of address and P-TMSI). It sends an AMA
message to the access router. The access router returns the BA
to the MN containing the new P-TMSI suboption. The MN optionally
acknowledges the new P-TMSI by returning an IMSI-Attach confirm
sub-option (see section ?? ) to the AR. An access router that
receives the packet will have to forward a DIAMETER AMR message to
the IGSS containing the MN confirmation in a MIPv6-Feature-AVP.
6.3.4. Erroneous Attach
If for any reason, or during an intrusion trial, the MN sends in
the BU destination option, a wrong P-TMSI or a wrong signature,
the authentication procedure will be longer. The MN will have to
authenticate itself like for a first time attach.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 15]
Internet Draft IGPRS 13 February 2002
6.4. Detach Function
The Detach Function allows an MN to inform the network that it
wants to make a IGPRS IMSI detach, and it allows the network to
disconnect/inform an MN that it has been IMSI-detached by the
network. The Detach is important since it releases air resources and
affects charging procedures.
The MN is detached from IGPRS either explicitly or implicitly.
- Explicit detach: The network or the MN explicitly requests detach.
- Implicit detach: The network detaches the MN, without notifying the
MN, a configuration-dependent time after the mobile reachable timer
expires, or after an unrecoverable radio error causes disconnection
of the logical link.
In the explicit detach case sent by the node, a BU with Lifetime
set to zero is sent to the access router by the MN. The AR sends a
Session Termination indication to the AAAF. The DIAMETER message is
forwarded to the AAAH that has to notify the HA of detach request
in order to stop forwarding packets to the MN. The HA receives an
ICMP-Host unreachable message from the Home IGSS (AAAH) for that
purpose.
In the explicit detach initiated by the network. The same procedure
updates the HA and the AR. An ICMP Router Advertisement with
Lifetime=0 is sent to the MN IPv6 destination address in order to
de-allocate the routing information.
6.5. Updating the HLR
When the AAAH receives a DIAMETER AMRv6 message to update the new
MN location, it has to update the HLR and the old IGSS. The HLR
operations happen before AAAH sends the HARv6 to the mobile node's
home agent.
The Update Location message contains the SGSN number, IGSS address
and IMSI (as required by the GPRS specifications). When the HLR
responds with a Cancel Location, the message is proxied by the AAAH
and transformed into a DIAMETER Session Termination message. It is
sent to the old IGSS. The Session Termination Ack triggers a Cancel
Location Ack from the AAAH to the HLR with the IMSI parameter. The
Insert Subscriber Data message is necessary to confirm that both
mobility and authentication were valid in the HLR side.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 16]
Internet Draft IGPRS 13 February 2002
AAAH HA HLR Old-AAAF New-AAAF
--------- --- ------ -------- -------
+--- MAP Update Location--->+
+<-----Cancel Location------+
+ +
+----- HARv6--->
+<-----HAAv6---+
+-------DIAMETER Session Termination------>+
+<-----DIAMETER Session Termination Ack----+
+ +
+----Cancel Location Ack--->+
+<--Insert Subscriber Data--+
+----------------- DIAMETER AMAv6---------------------->+
+-Insert Subscr. Data Ack-->+
Figure 8: AAAH dialogue with HLR, using MAP messages,
for mobility management
7. Security Functions and Data Elements
IGPRS provides a number of security functions serving the following
purposes:
- Guard against unauthorized IGPRS service usage (authentication and
service request validation from the HLR).
- Enable user identity confidentiality by providing P-TMSI. (see
section 7.1).
It is optional in this version of draft. It can complement GPRS
authentication [SEC ] by using some of its parameters (IMSI, P-TMSI)
and it can replace it. A dual authentication is also possible
(GPRS-UMTS and IGPRS) and it can help in situation where the operator
is different than the ISP, keeping still one single authentication.
7.1. Authentication of Subscriber
Authentication procedures already defined in GSM and in the DIAMETER
will be used, with the distinction that the procedures executed
between the Home IGSS and the HLR are the GSM functions and those
executed between the IGSS and the MN (passing by the AR) are those
defined in the AAA framework.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 17]
Internet Draft IGPRS 13 February 2002
AAAH HLR Old-AAAF New-AAAF
--------- ------ -------- -------
+ +
+<--------------------DIAMETER AMRv6-------------------+
+ +
+--- Send Authentication--->+
+ + (when the MN is new to the AAAH)
+<---Send Authent. Ack------+
+ +
+ +
+----------------- DIAMETER AMAv6---------------------->+
Figure 9: AAAH dialogue with HLR, using MAP
messages, for authentication
When a mobile node camps on a new cell (with new prefix), it will
receive the router advertisement. The MN proceeds like in the
GSM/GPRS system and uses the Ki to crypt the challange. The MN
issues a BU with the following sub-option: IMSI, P-TMSI, P-TMSI
signature, SRES and old prefix. The AR should build a DIAMETER AMRv6
message with the following AVPs:
- The IMSI should be inserted in the MN NAI. If the MSISDN is used
then we add another NAI.
- The P-TMSI should be inserted as a P-TMSI NAI.
- The P-TMSI signature sould be inserted as a MN-Reg-Request AVP.
- The Challange is inserted in a Nonce AVP.
- The Challenge response (SRES) is sent in the Reg. Req Avp.
If the AAAF has already authenticated the MN (it compares the IMSI
(or MSISDN), P-TMSI with its local information) it will issue an
AMA message to the AR and the AR forwards a BA to the MN. If not,
the AAAF forwards this information to the AAAH. The AAAH obtains
information about the subscriber using the IMSI (or MSISDN). It
sends a Authentication_Info_Request MAP message to the HLR. The HLR
responds with an Authentication_Info_Ack. The AAAH proceeds further
and asks for the MN secret key with the SendParameters MAP operation
where the ``Ki Requested'' argument is set. When the HLR gives back
the secret key to the AAAH, the AAAH will be able to apply the secret
key on the random number (Nonce or RAND) and to compare it with SRES.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 18]
Internet Draft IGPRS 13 February 2002
MN AR AAAF AAAH HLR
--------- ---- ----- ---- ---
Periodic RA+RAND
+<-----------------------+
+ +
+ +
+-BU (IMSI,PTMSI,SRES)-->+
+ +---AMR---->+
+ + (when the
+ + MN is new
+ to the AAAH)
++---AMR------>+
+ Request_Ki
+ Authenticate
++<--AMA-------+
+ +<--AMA-----+
+<--------BA(PTMSI)------+
Figure 10: AAA Procedure in details
If this comparison is successful the AAAH proceeds with the HARv6
and AMAv6 messages. If the comparison fails the AAAH sends back a
failure to the AAAF as described in the DIAMETER protocol with the
Authentication_Failure error. In case of failure the AR sends a BA
with the status field set to the appropriate error.
Upon success, the AAAF will receive an AMAv6 message. It may
construct a P-TMSI and a P-TMSI signature. They are forwarded to
the AR in the same AVPs described in the previous paragraph. The AR
constructs a BA, inserts the P-TMSI and P-TMSI signature. It sends
the BA to the MN.
7.2. P-TMSI Signature
P-TMSI Signature is optionally sent by the IGSS to the MN. If
the P-TMSI Signature has been sent by the IGSS to the MN since
the current P-TMSI was allocated, then the MN includes the P-TMSI
Signature in future Binding Updates for identification checking
purposes. The access router forwards this sub-option in the DIAMETER
AMR message. In the Routing Update procedure, the IGSS compares the
P-TMSI Signature sent by the MN with the signature stored in the
IGSS. If the values do not match, the IGSS should send a DIAMETER AMA
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 19]
Internet Draft IGPRS 13 February 2002
error to the AR. The AR sends back the BA with Authentication error
(Status field) to the MN. The P-TMSI Signature parameter has only
local significance in the IGSS that allocated the signature.
8. Message Formats
This section describes the format for IGPRS messages. We identify
messages from the MN to AR, from the AR to the IGSS, between IGSS
(serving either as AAAF or AAAH) and from the IGSS to the HLR. AAAH
translates DIAMETER messages into the MAP protocol. Finally we
identify messages from the Home IGSS (AAAH) to the HA.
8.1. IMSI/MSISDN transport in NAI
The IMSI and P-TMSI are sent in Sub-Options from the MN to the AR,
and as an NAI in the DIAMETER messages. The IMSI is a 15 digits
maximum length number. The coded form for the IMSI in BU is the
following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| status| IMSI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
status: 4 bits field
0000 Normal Operation
0001 Attach Confirm
Figure 11: Sub-Option Type should contain the IMSI-Attach Type
8.2. Messages for an attach procedure: first time
As described earlier, the attach can happen in these three contexts:
1. first time attach,
2. intra-IGSS attach, and
3. the inter-IGSS attach.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 20]
Internet Draft IGPRS 13 February 2002
We describe the messages sent from and to the MN in the first case.
8.2.1. Messages for attach within the AAA domain
The MN uses a P-TMSI and a P-TMSI signature to authenticate
itself when it is not the first time attach. This is
carried in two separate Sub-Options in BUs. The Sub-Option
length should be expressed as in the GPRS [24.08 ] standard.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P-TMSI | Sub-Option Len| padding | octet 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 3 | 4 | 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The signature Sub-Option contains hexadecimal code obtained
by hashing the P-TMSI and by using the IMSI related
secret code algorithms. The Sub-Option length should
be expressed in bytes (this is typically three bytes).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P-TMSI Sign | Sub-Option Len| hexadecimal value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the BU is received in the AR. The IGPRS specific sub-options are
extracted. The IMSI, MSISDN and P-TMSI are coded as NAIs as follows:
IMSI(in decimal digits notation)@imsi.gprs
MSISDN (in decimal)@msisdn.gprs
P-TMSI (in hexadecimal)@p-tmsi.gprs
8.2.2. IGSS to HA and HLR
The IGSS acting as AAAF sends through DIAMETER Mobile IP Registration
request the received parameters to the AAAH.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 21]
Internet Draft IGPRS 13 February 2002
<AA-Mobile-Nodev6-Request> ::= <DIAMETER Header, Command-Code=AMRv6>
<Session-ID AVP>
[<User-Name AVP> // IMSI or MSISDN
<Host-Name AVP>]
<MIP-Reg-Request AVP> // SRES
<MN-AAA-Auth AVP>
[<Mobile-Node-Address AVP>]
[<Home-Agent-Address AVP>]
[<MIPv6-Feature-Vector AVP>]
[<Previous-FA-NAI AVP> | // Old P-TMSI
<Previous-FA-Addr AVP>] // Old Prefix
<Timestamp AVP>
<Nonce AVP> // RAND
<Integrity-Check-Value AVP> //P-TMSIsigna*
*ture
It is to be noted that for minimizing additional protocol extensions
to IGPRS, the SRES field is sent in the MIP-Reg-Request AVP.
Specifically in the Identification field as shown in the figure.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification = SRES +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
It sends a Send_Authentication_Info message to the HLR and
receives a Send_Authentication_Info_Ack message. The AAAH
updates the HA with the new MN address after receiving
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 22]
Internet Draft IGPRS 13 February 2002
the confirmation from the HLR through the HARv6 message.
<Home-Agent-MIPv6-Request> ::= <DIAMETER Header, Command-Code=HARv6>
<Session-Id AVP>
<Session-Timeout AVP>
<MIP-Reg-Request AVP>
<Mobile-Node-Address AVP>]
8.2.3. AAAH to AAAF IGSS
When the HLR sends an answer to the AAAH. It is forwarded to the AAAF
with a AA-Mobile-Node-v6-Answer:
<AA-Mobile-Node-Answer> ::= <DIAMETER Header, Command-Code=AMAv6>
<Session-Id AVP>
<Session-Timeout AVP>
<Result-Code AVP>
[<Host-Name AVP>]
[<MIP-Reg-Reply AVP>]
[<MN-to-HA-Key AVP>] // New P-TMSI
[<Timestamp AVP>
<Nonce AVP>
<Integrity-Check-Value AVP>] //P-TMSI Sign.
8.2.4. IGSS to AR
The IGSS will make the necessary authentication locally and send
Binding Acknowledgment with the new P-TMSI sub-option (Section 7.2).
8.2.5. Authentication Error
In case of authentication failure or denial of service, the IGSS
sends back an Authentication Error Result AVP. It is forwarded in the
BA with the status field set to Authentication Error.
8.2.6. Detach
The MN may detach itself by sending a BU to the HA with Lifetime set
to zero.
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 23]
Internet Draft IGPRS 13 February 2002
8.3. Messages for an attach procedure: inter-IGSS
8.3.1. Second Time Attach
When the MN has already a valid P-TMSI, it will send it along with
the signature in two Sub-Options to the IGSS.
8.3.2. IGSS Response
The response contains the same information as in the first attach,
i.e. the P-TMSI and P-TMSI signature.
8.4. Link Layer messages
This section describes the procedures that have to be implemented in
the MAC layer to fulfill the necessary IGPRS functions. We identify
two messages carrying IGPRS signalling. The first is the Activate
PDP Context. It is sent simultaneously with the GPRS attach message.
It corresponds to the first BU sent from the mobile node. The second
is the Routeing Area Update Request. It is sent twice from the MN
to the Network. In the first Routeing Area Update, a normal GPRS
message is sent. In the second, the information related to the BU
is inserted in the message. Before we give the details of these
RRC messages, we have to describe the mapping between Routeing Area
Identity and IPv6 prefix.
8.4.1. Router Advertisements
The periodic physical broadcast layer messages corresponding to
the GPRS information have to be translated in the MN into Router
Advertisement messages in IPv6. RAC has hence to be translated
into IPv6 prefix. The structure of a Routeing Area Identity is as
follows.
+----------------------------------------------+-------+
| 8 7 6 4 3 2 1 | |
|------------------------------------------------------|
| Routing Area Identification IEI |octet 1|
| MCC digit 2 MCC digit 1 |octet 2|
| MNC digit 3 MCC digit 3 |octet 3|
| MNC digit 2 MNC digit 1 |octet 4|
| LAC |octet 5|
| LAC contd |octet 6|
| RAC |octet 7|
+------------------------------------------------------+
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 24]
Internet Draft IGPRS 13 February 2002
The first BU sent from the node is encapsulated in a ACTIVATE PDP
Context message.
+------------------------------------------+
|IEI Information Element Length|
|Protocol discriminator 1/2 |
|Transaction identifier 1/2- 3/2|
|Activate PDP context req. message id. 1 |
|Requested NSAPI 1 |
|Requested LLC SAPI 1 |
|Requested QoS 12 |
|Requested PDP address(Home Address) 17 |
|Access point name (BU) 102 |
|Protocol configuration options 3-253 |
+------------------------------------------+
As we can see from the ACTIVATE PDP CONTEXT message, the BU
is inserted in the field usually reserved for a domain name.
Additionnally, the Home Address corresponding to the Mobile Node is
inserted in the Requested PDP Address.
The PDP Type ``IGPRS'' will have to be inserted in the Protocol
Configuration Option in order to inform the network that this is not
a normal GPRS terminal but one supporting IGPRS specifications.
The remaining procedure corresponds to the periodic Routeing Area
Updates and to Routeing Area Updates sent when the MN camps in a new
routing are. When the GPRS layers are notified by a change in the
Routeing Area Identity, a router advertisement is generated locally
to inform the IPv6 layer of the change in the routing subnet. This
triggres the normal GPRS Routeing Area Update Request procedure and
triggers the IGPRS Routeing Area Request message.
+---------------------------------------------------------------+
| Field Type Length |
| Protocol discriminator 1/2 |
| Skip indicator 1/2 |
| Routing area update request message identity 1 |
| Update type 1/2 |
| GPRS ciphering key sequence number 1/2 |
| Old routing area identification 6 |
| MS Radio Access capability 6-52 |
| Old P-TMSI signature 4 |
| Requested READY timer value 2 |
| DRX parameter 3 |
| TMSI status 1 |
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 25]
Internet Draft IGPRS 13 February 2002
| P-TMSI Mobile identity 7 |
| MS network capability 4/10 |
| Access point name (BU) 102 |
+---------------------------------------------------------------+
Note also that in the Routeing Area Update used for IGPRS, the
Update Type is set to IGPRS (bits=111) so that there is no possible
confusion with other messages or syntax errors. The BU is sent in
the Access point Name field that is not usually used in the routeing
area update.
8.4.2. Link layer indications
The GPRS layer has to send Network Unreachable and Link layer failure
whenever this happens. The mobile node receives these messages and
responses by the appropriate MIPv6 signalling as described in the
document.
8.4.3. Router Advertisements
The periodic physical broadcast layer messages corresponding to
the GPRS information have to be translated in the MN into Router
Advertisement messages in IPv6. RAI has hence to be translated into
IPv6 addresses. When this message is refreshed in the lower layers a
MAC layer frame is constructed and furnished to the IPv6 layer. For
IPv6 protocol integrity, this function has to be implemented on both
sides on of the link. The router advertisement contains also the
RAND number used to generate SRES in the MN.
8.4.4. Link layer Requirements
In the GPRS system, the layer 2 for GPRS services is composed of four
sublayers comprising :
- Radio Resource Management (RR) functions;
- Mobility Management (GMM and GMM-AA);
- Logical Link Control (LLC);
- Connection Management (CM) functions.
- Session Management (SM) functions to activate, modify and delete the
contexts for packet data protocols (PDP)
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 26]
Internet Draft IGPRS 13 February*
* 2002
- supporting functions for short messages service conrol.
Since IGPRS replaces many of the GPRS functions, all the described
messages will be sent from the MN as GRR-Data-Req messages, with
SAPI=signalling and LLC-UNI parameters. The normal data messages
will go through the User services (SNDCP) payload as described
in [4.07 ].
A Temporary Block Flow (TBF) is a physical connection used by the two
Radio Resource entities to support the unidirectional transfer of LLC
PDUs on packet data physical channels.
9. Additional Security Considerations
The security of IGPRS depends on the security functions provided in
Mobile IPv6 as well as the basic security architecture defined for
GPRS.
References
[3gpp] . All the documents and drafts are available at http://www.3gpp.or*
*g/3G_Specs/spec_series.htm
.
[RANAP] 3GPP TS 25.413 V3.3.0 (2000-09). Technical Specification 3rd
Generation Partnership Project; Technical Specification Group Radio
Access Network; UTRAN Iu Interface RANAP Signalling (Release 1999).
[imsi] . ETSI EN 300 927 V5.4.0 (2000-08) Digital cellular
telecommunications system (Phase 2+); Numbering, addressing
and identification (GSM 03.03 version 5.4.0 Release 1996).
[SEC] 3GPP TS 33.102 V3.6.0 (2000-10) Technical Specification 3rd
Generation Partnership Project; Technical Specification Group
Services and System Aspects; 3G Security; Security Architecture
(Release 1999).
[nai] B. Aboba, M. Beadles. January The Network Access Identifier. RFC
2486.
[dhcp] J. Bound, M. Carney, C. Perkins. Dynamic Host Configuration
Protocol for IPv6 (DHCPv6). Internet Draft. 5 May 2000.
[diammip] . Calhoun, C. Perkins. DIAMETER Mobile IP Extensions. Internet
Draft. September 2000.
[diam] P. Calhoun, A. Rubens, H. Akhtar. E. Guttman. DIAMETER Base
Protocol. Internet Draft. July 2000
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page*
* 27]
Internet Draft IGPRS 13 February *
*2002
[AAA] S. Farrell et Al. "AAA Authorization Requirements,"
<draft-ietf-aaa-authorization-reqs-01.txt>, October 1999.
[AUTO] S. Thomson, T. Narten. Request For Comments: 2462. IPv6 Stateless
Address Autoconfiguration
[GPRS] 3GPP TS 23.060 V3.5.0 (2000-10). Technical Specification 3rd
Generation Partnership Project; Technical Specification Group
Services and System Aspects; General Packet Radio Service (GPRS);
Service description; Stage 2 (Release 1999).
[imsi] SM ETSI TS 100 977 V8.3.0 (2000-08). RTS/SMG-091111Q8R1. Digital
cellular telecommunications system (Phase 2+); Specification of the
Subscriber Identity Module - Mobile Equipment (SIM - ME) interface
(GSM 11.11 version 8.3.0 Release 1999).
[ICMPv6] A. Conta, S. Deering.Internet Control Message Protocol (ICMPv6) for
the Internet Protocol Version 6 (IPv6) Specification Request for
Comments: 2463
[IPv6] B. Hinden, S. Deering. IP Version 6 Addressing Architecture.
Request for Comments: 2373. July 1998
[mipv6] D. Johnson, C. Perkins. Mobility Support in IPv6. Internet Draft.
27 April 2000 ETSI ETS 300 599 ed.9 (2000-08) Draft
[MAP] RE/TSGN-040902PR9. Digital cellular telecommunications system
(Phase 2); Mobile Application Part (MAP) specification (GSM 09.02
version 4.19.0)
[nd] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP
Version 6 (IPv6). Request for Comments: 2461. December 1998
[imsi] . ETSI EN 300 927 V5.4.0 (2000-08) Digital cellular
telecommunications system (Phase 2+); Numbering, addressing
and identification (GSM 03.03 version 5.4.0 Release 1996).
[4.07] Digital cellular telecommunications system (Phase 2+); Mobile radio
interface signalling layer 3; General aspects (GSM 04.07 version
7.3.0 Release 1998).
[24.08] 3GPP TS 24.008 V3.5.0 (2000-09). Technical Specification 3rd
Generation Partnership Project; Technical Specification Group Core
Network; Mobile radio interface layer 3 specification; Core Network
Protocols - Stage 3 (Release 1999)
[4.60] ETSI EN 301 349 V8.4.0 (2000-05) Mobile Station (MS) - Base Station
System (BSS) interface; Radio Link Control/ Medium Access Control
(RLC/MAC) protocol (GSM 04.60 version 8.4.0 Release 1999).
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page *
*28]
Internet Draft IGPRS 13 February*
* 2002
[NAI] B. Aboba, M. Beadles. January The Network Access Identifier. RFC
2486.
[dhcp] J. Bound, M. Carney, C. Perkins. Dynamic Host Configuration
Protocol for IPv6 (DHCPv6). Internet Draft. 5 May 2000.
[rfc2119] S. Bradner Key words for use in RFCs to Indicate Requirement
Levels.Request for Comments: 2119. IETF.
[diammip] P. Calhoun, C. Perkins. DIAMETER Mobile IPv6 Extensions. Internet
Draft. Work in Progress. September 2000.
[nasreq] P. Calhoun, W. Bulley, A. Rubens, J. Haag. DIAMETER NASREQ
Extensions Internet Draft. IETF.
[mipnai] P. Calhoun, C. Perkins. Mobile IP Network Access Identifier
Extension for IPv4. Request for Comments: 2794. March 2000
[diam] P. Calhoun, A. Rubens, H. Akhtar. E. Guttman. DIAMETER Base
Protocol. Internet Draft. July 2000
[AAA] S. Farrell et Al. "AAA Authorization Requirements,"
<draft-ietf-aaa-authorization-reqs-01.txt>, October 1999.
[MIPCHAP] C. Perkins, P. Calhoun. Mobile IPv4 Challenge/Response Extensions.
INTERNET DRAFT June 2000.
[IGUA] R. Hinden, M. O'Dell, S. Deering. An IPv6 Aggregatable Global
Unicast Address Format. Request for Comments: 2374.
[AUTO] S. Thomson, T. Narten. Request For Comments: 2462. IPv6 Stateless
Address Autoconfiguration
[GPRS] ETSI EN 301 113 V6.3.0 (2000-07). REN/TSGS-010260Q6R2. Digital
cellular telecommunications system (Phase 2+); General Packet Radio
Service (GPRS); Service description; Stage 1 (GSM 02.60 version
6.3.0 Release 1997)
[imsi] SM ETSI TS 100 977 V8.3.0 (2000-08). RTS/SMG-091111Q8R1. Digital
cellular telecommunications system (Phase 2+); Specification of the
Subscriber Identity Module - Mobile Equipment (SIM - ME) interface
(GSM 11.11 version 8.3.0 Release 1999).
[ICMPv6] A. Conta, S. Deering.Internet Control Message Protocol (ICMPv6) for
the Internet Protocol Version 6 (IPv6) Specification Request for
Comments: 2463
[IPv6] B. Hinden, S. Deering. IP Version 6 Addressing Architecture.
Request for Comments: 2373. July 1998
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page*
* 29]
Internet Draft IGPRS 13 February 2*
*002
[mipv6] D. Johnson, C. Perkins. Mobility Support in IPv6. Internet Draft.
27 April 2000 ETSI ETS 300 599 ed.9 (2000-08) Draft
[MAP] RE/TSGN-040902PR9. Digital cellular telecommunications system
(Phase 2); Mobile Application Part (MAP) specification (GSM 09.02
version 4.19.0)
[nd] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP
Version 6 (IPv6). Request for Comments: 2461. December 1998
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 3*
*0]
Internet Draft IGPRS 13 February 2002
Addresses
Questions about this memo can also be directed to the authors:
Hossam Afifi Charles E. Perkins
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Phone: +1-650 625-2768 Phone: +1-650 625-2986
EMail: hossam@iprg.nokia.com EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502
Hannu Flinck
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2402
EMail: hannu.flinck@nokia.com
Fax: +1 650 625-2502
Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 31]
