NSIS Working Group L. Cordeiro
Internet-Draft M. Curado
Expires: August 21, 2008 Univ. Coimbra
P. Neves
PTIn
S. Sargento
Univ. Aveiro
G. Landi
CPR
X. Fu
Univ. Goettingen
February 18, 2008
Media Independent Handover Network Signalling Layer Protocol (MIH NSLP)
draft-cordeiro-nsis-mih-nslp
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Cordeiro, et al. Expires August 21, 2008 [Page 1]
Internet-Draft MIH NSLP February 2008
Abstract
This memo defines the Media Independent Handover Network Signalling
Layer Protocol (MIH NSLP) for the transport of messages from the IEEE
802.21 standard using the Next Steps in Signalling (NSIS) framework.
The MIH NSLP is responsible for the transport of MIH messages to
remote entities reporting on link layer information, in order to
support seamless mobility in heterogeneous environments. A usage
example of the MIH NSLP is also provided.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Media Independent Handover NSLP Specification . . . . . . . . 7
4.1. MIH NSLP Architecture . . . . . . . . . . . . . . . . . . 8
4.2. MIH Message Transport . . . . . . . . . . . . . . . . . . 9
4.3. Mapping between MIHF ID and Network Addresses . . . . . . 11
5. Mobility Scenario Example . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Cordeiro, et al. Expires August 21, 2008 [Page 2]
Internet-Draft MIH NSLP February 2008
1. Introduction
In order to improve the handover between heterogeneous access
networks, the IEEE 802.21 standard is being defined to provide Media
Independent Handover services (MIH). IEEE 802.21/MIH makes available
link layer information to the upper network layers, both locally and
remotely. Although the standard defines the guidelines to transport
the MIH protocol messages to remote entities, namely the need to be
reliable and to guarantee security of the messages exchanged, it does
not specify a transport mechanism. [1] describes a possible design
for the MIH transport mechanism; however it requires a multitude of
new protocol elements and is also limited in several technical
constraints such as message size and protocol discovery.
The IETF NSIS WG is finalizing the base protocols to offer flexible
and extensible signalling services for a variety of application,
including the General Internet Signaling Transport (GIST) for support
secure, reliable, congestion-controlled data transport, as well as
other features desired for signalling. Given the potential of NSIS
to perform Quality of Service (QoS) signalling for real-time
applications in wired and wireless scenarios, which is also often
desired by the applications using MIH, we propose to use GIST to
transport MIH messages. Therefore, this document defines a Media
Independent Handover NSIS Signalling Layer Protocol (MIH NSLP) to
support seamless mobility in heterogeneous network environments
through the integration of MIH and NSIS.
This document is structured as follows. Section 3 presents the
motivation for the development of a MIH NSLP. Section 4 details the
MIH NSLP and Section 5 shows an example of the use of the MIH NSLP in
a mobility scenario.
2. Terminology and Abbreviations
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 [2].
The following additional terms are used:
o E2E: End-to-End
o QoS: Quality of Service
o MIH: Media Independent Handover
Cordeiro, et al. Expires August 21, 2008 [Page 3]
Internet-Draft MIH NSLP February 2008
o MIH NSLP: Media Independent Handover NSIS Signaling Layer
Protocol, uses NSIS as the transport protocol for MIH messages.
o NSIS: Next Steps in Signaling
o GIST: General Internet Signaling Transport
o WLAN: Wireless Local Area Networks
o WiMAX: Worldwide Interoperability for Microwave Access
o UMTS: Universal Mobile Telephone Service
o MBMS: Multicast and Broadcast Multimedia Services
o DVB: Digital Video Broadcast
o SAP: Service Access Point
o MICS: Media Independent Command Services
o MIES: Media Independent Event Services
o MIIS: Media Independent Information Services
o MIHF: Media Independent Handover Function
o MIHU: Media Independent Handover User
o ASN: WiMAX Access Service Network
o AN: Access Network
o CSN: WiMAX Connectivity Service Network
o CN: Core Network
o MS: Mobile Station
o TCP: Transmission Control Protocol
o UDP: User Datagram Protocol
o BS: WiMAX Base Station
o SS: WiMAX Subscriber Station
Cordeiro, et al. Expires August 21, 2008 [Page 4]
Internet-Draft MIH NSLP February 2008
o AP: WiFi Access Point
o SF: WiMAX Service Flow
o HA: MIP Home Agent
o CoA: MIP Care of Address
o AAA: Authentication, Authorization and Accounting
o ASN-GW: WiMAX Access Service Network Gateway
o MIH Registration Server: responsible to handle the MIHF ID into
network address mapping.
3. Problem Statement
With the current evolution of network technologies we envision that,
in a near future, there will be a heterogeneous landscape of
different technologies such as WLAN, WiMAX, UMTS/MBMS and DVB,
providing ubiquitous network access to users. The wide availability
of co-located technologies and the growing trend of users' mobility,
require the seamless support of mobility and service continuity.
Nevertheless, due to the large number of new access technologies, it
is very difficult to provide seamless mobility across these
technologies.
In order to optimize the handover process, the IEEE is currently
defining the 802.21 standard, focused on Media Independent Handover
services (MIH). The main goal of the IEEE 802.21 standard is to
provide link layer information to the upper layers, optimizing the
handover process between heterogeneous access networks. The Media
Independent Handover Function (MIHF) is the core component of the
802.21 standard. It provides a set of well defined and standardized
Service Access Points (SAP) with both the link layer (MIH_LINK_SAP)
and the upper layers (MIH_SAP) that will use this information (MIH
users). A set of services is provided through these interfaces in
order to facilitate the communication process:
o Media Independent Command Service (MICS): allows higher layers to
configure, control and get information from the lower layer.
o Media Independent Event Service (MIES): allows higher layers to
receive indications from link layers.
o Media Independent Information Service (MIIS): provides a framework
and corresponding mechanisms by which a MIHF entity obtains static
Cordeiro, et al. Expires August 21, 2008 [Page 5]
Internet-Draft MIH NSLP February 2008
network information.
Events and commands can be local and/or remote. Local events are
generated from the link layer and propagated towards the MIH users
within the local device. Remote events are propagated towards a MIH
user connected to a peer MIHF.
Several network elements might be interested to receive notifications
from the lower layers, and therefore the MIH protocol has been
defined to propagate the MIH services towards the peer MIHFs.
Figure 1 illustrates the distribution of the MIHF entities across the
network components.
<-------- Domain X ---------> <--------- Domain Y -------->
+------+ +------+ +------+ +------+
| MS |<-->| AN1 |\ /| AN1 |<-->| MS |
| MIHF | | MIHF | \ / | MIHF | | MIHF |
+------+ +------+ \ / +------+ +------+
. +------+ +-----+| .
. | CN |<---->| CN | .
. | MIHF | | MIHF | .
. +------+ +------+ .
+------+ +------+ / \ +------+ +------+
| MS |<-->| ANn | / \ | ANn |<-->| MS |
| MIHF | | MIHF |/ \| MIHF | | MIHF |
+------+ +------+ +------+ +------+
Figure 1: MIHF Communication Model
The MIHFs might be spread in several network elements inside the same
domain, or even across different domains. In Figure 1 we illustrate
two different domains (domain X and domain Y). Each domain is
composed by the Core Network (CN), responsible for the overall
management and control of the network, connected to several Access
Networks (AN). Each AN provides connectivity to the Mobile Stations
(MS), using wired/wireless access technologies (e.g. WiMAX, DVB,
WiFi, UMTS). As depicted in Figure 1, each one of these entities -
CN, AN and MS - is a potential candidate to host the MIHF entity.
Therefore, MIH messages SHALL be able to reach all the MIHFs in the
network, independently of their location.
However, no specific transport mechanism is defined to carry the MIH
protocol messages between remote MIHFs. Only the guidelines to
transmit the MIH messages across the network are defined in the MIH
standard. The transport protocol used MUST be reliable, guaranteeing
Cordeiro, et al. Expires August 21, 2008 [Page 6]
Internet-Draft MIH NSLP February 2008
the correct delivery of the messages to the peer MIHF, and provide
security over the exchanged messages.
The Transmission Control Protocol (TCP) is able to satisfy the
reliability requirement posed by the MIH protocol. It provides error
control and flow control, guaranteeing the in-order delivery of the
packets. However, although TCP offers reliability, it does not
guarantee fast-packet delivery due to its retransmission mechanism.
In what concerns the User Datagram Protocol (UDP), it assures fast-
packet delivery, but it does not guarantee the correct packet
delivery, and therefore is unreliable.
As a result, a reliable, secure and fast-delivery solution to
transport MIH protocol messages between peer MIHFs is required.
Although a new fast-delivery solution can be designed, other existent
solutions can be envisioned.
To address seamless mobility support, media independent handovers
together with fast/local mobility approaches are not sufficient.
When users move while accessing real-time services, resources need to
be reserved in advance in the new network to guarantee that the
services maintain their quality. Next Steps in Signalling (NSIS) [3]
QoS signalling protocol is an emergent QoS signalling and reservation
protocol with capabilities to be used in mobile environments. NSIS
decomposes the overall signalling protocol suite into a generic
(lower) layer and specific upper layers for each specific signalling
application. In the lower layer, General Internet Signalling
Transport (GIST) [4] offers transport services to higher layer
signalling applications for two purposes: sending and receiving
signalling messages between neighbour hops (NSIS entities), and
exchanging control and feedback information. Above this layer, there
is the NSIS Signalling Layer Protocol (NSLP) layer [5], which
generically stands for any protocol within the signalling application
layer.
NSIS is very well suited for heterogeneous wired and wireless
networks and is able to interact with mobility protocols for seamless
handovers. Therefore, to enable the support of seamless mobility,
MIH can be integrated with NSIS and cooperate in the handover
process. To provide a clean cooperation with low overhead (both in
messages exchanged and time), and since MIH protocol messages require
a transport protocol, we propose and define a MIH NSLP to use NSIS as
a transport protocol for MIH messages.
4. Media Independent Handover NSLP Specification
In order to use the NSIS framework to transport MIH messages, a
Cordeiro, et al. Expires August 21, 2008 [Page 7]
Internet-Draft MIH NSLP February 2008
specific NSLP, the Media Independent Handover NSLP, is developed in
this document. The MIH NSLP allows the distribution of MIH messages
across different networks. The following describes the procedure to
transport MIH messages within the MIH NSLP, followed by the
specification of the MIH NSLP architecture.
4.1. MIH NSLP Architecture
The MIH NSLP is responsible for the transport of MIH Messages using
the GIST protocol. Figure 2 details the architecture of NSIS usage
as the MIHF transport protocol.
+----------+
| MIHF |
+----------+
| ^
+----------|--|----------+
|NSIS | | |
| v | |
| +------------------+ |
| | MIH NSLP | |
| +------------------+ |
| | ^ |
| v | |
| +------------------+ |
<--|--| GIST |--|-->
| +------------------+ |
+------------------------+
Figure 2: MIH NSLP architecture
This figure shows the interaction between the MIH NSLP, the MIHF and
the GIST protocol.
The MIH NSLP interface with MIHF handles the MIHF MIH Message
exchange. This interface is compliant with the MIH_NET_SAP defined
in [6].
The MIH NSLP interface with GIST handles message transport. This
interface is specified in [4].
The MIH NSLP is split in six different functionalities as follows:
o Interface with MIHF
Cordeiro, et al. Expires August 21, 2008 [Page 8]
Internet-Draft MIH NSLP February 2008
o Interface with GIST
o Message transport (and retransmission if acknowledge is required)
o Message reception
o Message interception
o MIH Registration Server (only active through an election process -
out of scope)
* Registration
* DeRegistration
* Request
* Messages retransmission
These functionalities are described in the next sections.
4.2. MIH Message Transport
As specified in [6], MIHF entities need to propagate MIH messages
towards peer MIHF entities. The MIH standard does not include the
specification of a transport protocol, at layer 3, and only the
requirements for this protocol are defined. These requirements can
be summed up to reliability and security over the MIH exchanged
messages, requirements that are met by the GIST protocol.
Figure 3 shows an example of the NSIS usage to transport MIH
Messages.
+--------------+ +--------------+ +--------------+
| MIHF | | MIHF | | MIHF |
| Source | | Middle | | Destination |
+--------------+ +--------------+ +--------------+
| ^ | ^
V | v |
+--------------+ +--------------+ +--------------+
| NSIS |=====>| NSIS |=====>| NSIS |
+--------------+ +--------------+ +--------------+
--> MIHF interface messages
==> NSIS messages
Cordeiro, et al. Expires August 21, 2008 [Page 9]
Internet-Draft MIH NSLP February 2008
Figure 3: NSIS usage to transport MIH Messages
This figure presents the interaction between the MIHF and the NSIS
framework and the transport of MIH Messages between a Source and a
Destination MIHF. In this scenario, the Middle MIHF also intervenes
by receiving the message exchanged due to the intercept NSIS feature.
The processing of these intercepted messages is out of the scope of
this document.
To be able to transport the MIH Messages, NSIS requires the
destination network address of the MIHF Destination. However, MIH
entities only handle MIHF Identifiers (ID) to identify the remote
MIHF. Therefore, there is the need to perform the mapping between
the MIHF ID and the correspondent network addresses, which is under
NSIS responsibility.
The main functionality of the MIH NSLP is to handle the mapping
between MIHF ID and network addresses, since GIST is able to provide
all the required functionalities required by the MIH specification
for MIH Message transport. The mapping procedure is described in the
next sub-section.
Figure 4 shows the procedure to send MIH Messages to the remote MIHF
when the remote MIHF IP Address is available, either through the
cache mechanisms or resorting to the mapping procedure.
Source Middle Destination
MIH NSLP MIH NSLP MIH NSLP
| | |
| DATA(MIHF Msg) | |
|-------------------->| DATA(MIHF Msg) |
| |-------------------->|
| | |
| | DATA ACK()[opt] |
| DATA ACK()[opt] |<--------------------|
|<--------------------|
| |
Figure 4: Message transport between two MIH NSLP
In this figure the MIHF Message needs to be sent from the Source MIH
NSLP to the Destination MIH NSLP. To send the MIHF Message, the MIH
NSLP creates a MIH NSLP DATA message with the MIHF Message as one of
its components.
During the message exchange, the DATA message is intercepted in the
Cordeiro, et al. Expires August 21, 2008 [Page 10]
Internet-Draft MIH NSLP February 2008
Middle MIHF. According to the MIH NSLP architecture, this feature
could be useful for several scenarios. However, this feature is out
of scope of this document. If no specific action is defined in the
Middle MIHF entity, the MIH NSLP MUST forward the DATA message to the
Destination MIH NSLP.
When a DATA message reaches the destination, the MIHF Message is
forwarded to the local MIHF for processing. The MIH Message
information is transparent to the MIH NSLP. The MIHF processing is
defined in [6].
Optionally, a DATA ACK message can be sent to the Source MIH NSLP
when the DATA message arrives to the Destination MIH NSLP. This
feature can be requested by the Source MIH NSLP and SHOULD depend on
the transfer attributes requested to GIST (reliable and/or secure).
A MIHF response to the received MIH Message is treated as a new
request by the MIH NSLP. The MIH NSLP does not handle states for the
MIH Messages.
4.3. Mapping between MIHF ID and Network Addresses
In order to map all MIHF ID into network addresses a MIH Registration
Server is required. This MIH Registration Server is responsible for
handling the mapping between MIHF ID and network addresses of MIHF
entities. For this purpose one entity MUST be elected as a MIH
Registration Server. The election of this entity is out of scope of
this document because it depends on specific deployment scenarios
characteristics. In the example described in Section 5 an
appropriate choice would be the CN entity. The knowledge of the MIH
Registration Server MUST be known to all MIHF entities involved.
With the usage of the MIH Registration Server, when a MIH NSLP needs
to send a MIH Message to a remote MIHF, it queries the MIH
Registration Server in order to receive the appropriate network
address. Figure 5 and Figure 6 highlight the MIH NSLP message
exchange to perform a MIHF ID mapping to a network address.
Figure 5 describes the procedure that a MIH NSLP performs when it is
ready to transport MIH Messages.
Cordeiro, et al. Expires August 21, 2008 [Page 11]
Internet-Draft MIH NSLP February 2008
MIH MIH Registration
NSLP Server
| |
| IP REGISTER |
| (MIHF ID, IP) |
|-------------------->|
| | +-----------------+
| | | Register IP |
| IP REGISTER ACK() | +-----------------+
|<--------------------|
| |
. .
. .
. IP DEREGISTER .
| (MIHF ID) |
|-------------------->|
| | +-----------------+
| | | DeRegister IP |
| IP DEREGISTER ACK() | +-----------------+
|<--------------------|
| |
Figure 5: MIH NSLP registration/deregistration in a MIH Registration
Server
This registration procedure is composed by four MIH NSLP messages,
the IP REGISTER, the IP REGISTER ACK, IP DEREGISTER and the IP
DEREGISTER ACK. The IP REGISTER message is sent by the MIH NSLP to
the MIH Registration Server to register its MIHF ID and IP Address in
the MIH Registration Server. To confirm the registration of the MIH
NSLP, the MIH Registration Server sends an IP REGISTER ACK to the MIH
NSLP with the result of the registration. The registration result
can be:
o Successful: the registration process was successful;
o Warning due to duplicate MIHF ID: the received MIHF ID already
exists with a different IP Address;
o Warning due to duplicate IP Address: the received IP Address
already exist with a different MIHF ID;
o Internal failure: an error occurred not related to the request
received.
After a successful/warning registration procedure the MIH
Registration Server is able to map this MIHF ID to the appropriate IP
Cordeiro, et al. Expires August 21, 2008 [Page 12]
Internet-Draft MIH NSLP February 2008
Address and the MIH NSLP is ready to transport MIH Messages. The MIH
NSLP actions to a warning and failure registration are implementation
dependent.
The IP DEREGISTER message is sent to the MIH Registration Server when
the MIH NSLP intends to stop functions. This message includes the
MIHF ID that is to be removed from the registry. After the registry
deregistration the MIH Registration Server send an IP DEREGISTRATION
ACK to the MIH NSLP notifying it of the registration result. The
deregistration result can be:
o Successful: the deregistration process was successful;
o Warning due to unknown MIHF ID: the received MIHF ID does not
exists;
o Internal failure: an error occurred not related to the request
received.
Figure 6 describes the procedure that a MIH NSLP performs to map a
MIHF ID to an IP Address.
MIH MIH Registration
NSLP Server
| |
| IP REQUEST(MIHF ID) |
|-------------------->|
| | +-----------------+
| | | Mapping MIHF ID |
| | | to IP Address |
| IP RESPONSE(IP) | +-----------------+
|<--------------------|
| |
| IP ERROR() |(When an error in
|<--------------------| mapping occurs)
| |
Figure 6: MIH NSLP mapping procedure
In this figure there are two MIH NSLP messages, the IP REQUEST and
the IP RESPONSE. The IP REQUEST message is sent from the MIH NSLP
that requires the mapping to the MIH Registration Server with the
MIHF ID that needs to be mapped to an IP address. After the MIH
Registration Server mapping, an IP RESPONSE message is sent from the
MIH Registration Server to the requesting MIH NSLP. This message
includes the IP address that resulted from the mapping of the request
Cordeiro, et al. Expires August 21, 2008 [Page 13]
Internet-Draft MIH NSLP February 2008
MIHF ID.
In the MIHF ID mapping process some errors MAY occur. When an error
happens the MIH Registration Server entity MUST send an IP ERROR
message to the requesting MIH NSLP stating the error. The possible
errors are:
o Unknown MIHF ID: there is no reference to the requested MIHF ID;
o Unknown IP Address: there is no IP Address associated to the
requested MIHF ID;
o Internal Error: an error occurred not related to the MIHF ID or
the IP Address.
When IP REGISTER, IP DEREGISTER and IP REQUEST messages are sent, a
timer MUST be set to prevent the case of starvation due to a failure
in receiving the respective responses. These cases can occur when:
o The MIH Registration Server cannot be reached;
o The MIH Registration Server fails to respond.
If a timer expires, the IP REGISTER, IP DEREGISTER or IP REQUEST
message MUST be retransmitted until a maximum of three times. Each
time the timer expires the timer period SHOULD be doubled.
For the IP REGISTER ACK, IP DEREGISTER ACK, IP RESPONSE and IP ERROR
messages there is no need for timers. In the case these messages
fail to arrive to the MIH NSLP, the retransmission procedure will
force the resend of the appropriate response message.
5. Mobility Scenario Example
This section will present an example (including a picture) of the use
the Mobility NSLP to transport MIH messages in the mobility context -
controlled by the CSN.
This section presents a sample mobility scenario, where the exchange
of MIHF messages among different network nodes allows the efficient
management of control plane functionalities, such as data plane
configuration and resource reservation for the traffic flows involved
in the handover.
The example scenario is shown in Figure 7. It consists of a Mobile
Node (MN) with two network interfaces (ETH and WiFi) which is
connected to a Wi-Fi Access-Point attached to a WiMAX fixed
Cordeiro, et al. Expires August 21, 2008 [Page 14]
Internet-Draft MIH NSLP February 2008
Subscriber Station (serving SS). The MN moves and, since the radio
signal becomes lower, the user decides for the ETH connection and
plugs in the cable. The ETH network is connected to another WiMAX
fixed Subscriber Station (target SS), located in the same Access
Service Network of the serving SS. Both the stations are connected
to Base Stations (BS) controlled by the same ASN gateway (ASN-GW).
______
| | ______ _______ _______
| MN | | IEEE | | IEEE | | IEEE |
|______|****** |802.11|=====|802.16d|-.-.-.-.-|802.16d|
|| | AP | | SS | | BS | ________
|| |______| |_______| |_______|=====| |
|| | |
|| | |
|| | ASN-GW |
\/ | |
______ | |
| | _______ _______ | |
| MN | | IEEE | | IEEE |=====|________|
|______|====================|802.16d|-.-.-.-.-|802.16d|
| SS | | BS |
|_______| |_______|
******** Wi-Fi Link
-.-.-.-. Wi-MAX Link
Figure 7: Example of Mobility Scenario with heterogeneous networks
This type of scenario includes a double mobility. The host is
initially connected via Wi-Fi and afterwards uses the wired ETH
connection (mobility between heterogeneous networks). At the same
time the handovers involves two Subscriber Stations of the same WiMAX
technology (IEEE 802.16d), following the intra-ASN WiMAX mobility
model.
The considered MN hosts some active applications that require
specific levels of guaranteed QoS. Therefore the related sessions
are initially associated to a particular set of Service Flows (SFs)
allocated on the WiMAX channel between the serving SS and its BS.
Each SF is characterized by a specific scheduling class and some
parameters, like bandwidth and jitter that specify the QoS level for
the data traffic.
Following a network-initiated approach, the SF configuration and
activation is handled at the ASN-GW level by specific procedures that
Cordeiro, et al. Expires August 21, 2008 [Page 15]
Internet-Draft MIH NSLP February 2008
intercept different kinds of high level signalling (i.e. QoS NSLP,
SIP) in order to extract the QoS parameters required by the
application, map them in a set of SFs and finally configure the BSs
to allocate the resources on the wireless link.
The MN handover requires the WiMAX channel re-configuration, with the
creation and the activation of suitable SFs between the target SS and
the related BS. On the other hand, the existing SFs between the
serving SS and the related BS MUST be removed. This procedure SHOULD
be transparent to the high level signalling and, at the same time,
requires the direct action of the ASN-GW for the session management
and the explicit resource allocation in the WiMAX link.
This objective can be easily reached with the exchange of MIH
messages between the MN and the ASN-GW using the MIH NSLP. When
specific MIH Events are received by the gateway, the ASN-GW module
that handles the sessions and the WiMAX resource allocation (i.e. the
MIH User - MIHU) is informed of probable imminent handovers,
configures the resources on the new path and updates its internal
status with the up-to-date information about the involved sessions.
Similarly, if the mobility management system is based on a
centralized approach where handovers are controlled entirely at the
ASN-GW level, this MIHU can be able to send specific MIH Commands in
order to coordinate all the procedures at the lower layers. In such
situation, the handover management and the related decisions can be
more efficient if the ASN-GW is able to receive and process the
information provided by the Media Independent Information Service.
In this case the exchange of MIHF messages with other network
entities allows the MIHU to receive both lower layers and upper
layers information that can have an impact on the selection of the
target network during the handovers.
In the considered scenario, the MIH NSLP message exchange can be used
in order to achieve handovers based on the Make Before Break model
where the needed resources are configured before the actual
disconnection from the serving Point of Attachment (PoA) and
afterwards the resources on the old link are released. This approach
allows the applications to receive coherent QoS guarantees in case of
handovers between different networks.
As shown in Figure 8, the imminent disconnection of the MN from the
current Wi-Fi Access Point is notified to the ASN-GW through a Remote
MIH Link Going Down message, leading to the automatic resource re-
configuration on the WiMAX link. The deletion of the existing SFs
between the serving SS and BS is triggered by the following Remote
MIH Link Down message that signals the occurred disconnection from
the Wi-Fi network.
Cordeiro, et al. Expires August 21, 2008 [Page 16]
Internet-Draft MIH NSLP February 2008
MN MN Serving Target ASN-GW ASN-GW
Lower MIHF WiMAX WiMAX MIHF MIHU
Layers BS BS
| | | | | |
| Link | | | | |
|-Going-->| | | | |
| Down | MIH Link | | |
| |-------Going Down------------->| MIH Link|
| | | | |-Going-->|
| | | | | Down |
| | | | | |
| | | | | |
| | | |<-----Resource------|
| | | |------Allocation--->|
| | | | | |
|-Link--->| | | | |
| Down | MIH Link | | |
| |-------Down------------------->| |
| | | | | MIH |
| | | | |-Link--->|
| | | | | Down |
| | | | | |
| | |<----------Resource------------|
| | |-----------Release------------>|
| | | | | |
| | | | | |
Figure 8: MIHF Signalling and resource control
As a further example (Figure 9), we can consider a mobility scenario
in a single WiMAX network, where a Mobile Station IEEE 802.16e (MS)
moves from the serving BS to the target BS. Following the intra-ASN
scenario, both the BSs are located in the same access service network
and are controlled by the same ASN-GW. We can assume that the
management of the high level sessions and the associated QoS is
handled at the ASN-GW level, as in the previous scenario.
Cordeiro, et al. Expires August 21, 2008 [Page 17]
Internet-Draft MIH NSLP February 2008
_______ _______
| IEEE | | IEEE |
|802.16e|-.-.-.-.-|802.16e|
| MS | | BS | ________
|_______| |_______|=====| |
| |
| |
| ASN-GW |
| |
| |
_______ _______ | |
| IEEE | | IEEE |=====|________|
|802.16e|-.-.-.-.-|802.16e|
| MS | | BS |
|_______| |_______|
-.-.-.-. Wi-MAX Link
Figure 9: Example of Mobility Scenario in a WiMAX network - ASN-
anchored
In this case, the handover management can be coordinated directly
among the MS and the involved BSs, through the creation and the
activation of suitable SFs on the target path and the deletion of the
previous ones. Nevertheless the ASN-GW can obtain some notifications
about the handovers and the occurred changes in lower layers through
the MIH Event Service messages received through the MIH NSLP. These
notifications allow the ASN-GW to correctly update the mobility
"context" (SS and BS MAC address, SFs and classifiers, WiMAX security
information, HA IP address, CoA, DHCP server, AAA server) for each
existing session, so that it is able to manage possible resource re-
configuration if required by the associated high level signalling.
In IEEE 802.16e networks, the MS can move between BSs under control
of different ASNs and managed by different ASN-GWs (CSN-anchored
mobility). In this case, the functionalities for the handover
management SHOULD be split among different entities located not only
in the ASN but also in the Connectivity Service Network and in the
core network. The MIH NSLP protocol can be used in order to
propagate the MIH Event and Command messages along the full path
between the serving and the target BS, towards all the MIH peers
located in ASNs and CSNs of different domains (Figure 10).
Cordeiro, et al. Expires August 21, 2008 [Page 18]
Internet-Draft MIH NSLP February 2008
_______
| IEEE | _________ _______
|802.16e| | IEEE | | |
|__MS___|-.---.-.-.-.| 802.16e |=========| ASN |
|| | BS | | GW 1 | _______
|| |(serving)| |_______|=======| |
|| |_________| | CSN 1 |
|| |_______|
|| |
\/ ___|___
_______ | |
| IEEE | _________ _______ | CSN 2 |
|802.16e| | IEEE | | |=======|_______|
|__MS___|-.-.-.-.-.-.| 802.16e |=========| ASN |
| BS | | GW 2 |
|(target) | |_______|
|_________|
-.-.-.-. Wi-MAX Link
Figure 10: Example of Mobility Scenario in a WiMAX network - CSN-
anchored
6. Security Considerations
The exchange of MIH NSLP messages MUST be secured against security
threats, which have been identified in [7]. GIST is responsible for
some of the security aspects of signalling [3]. Additionally, NSLPs
MUST be in charge of threats concerning authorization, message
protection, rate limitation, and prevention of denial of service
attacks, as described in [4]. The use of these mechanisms in MIH
NSLP is under study.
7. Open issues
This document specifies the MIH NSLP protocol, but leaves some issues
unaddressed:
o The usage of MIH NSLP and GIST as the MIHF transport protocol adds
additional security threats that are not addressed in the GIST and
MIHF specifications. Some of these security issues are:
* The interception of MIH Messages by middle MIHF entities;
Cordeiro, et al. Expires August 21, 2008 [Page 19]
Internet-Draft MIH NSLP February 2008
* The registration and deregistration process;
* Unauthorized requests or unauthorized MIH Messages.
o The MIH NSLP registration procedure needs to include a refresh
feature to maintain the MIH Registry Server updated. The MIH
Registry Server should use soft states to store the mapping
information;
o A default timer value SHOULD be proposed for the MIH NSLP message
retransmit timer.
o The MIH NSLP messages MUST be specified. A MIH NSLP Message
SHOULD consist of:
* A common message header;
* A group of type-length-value (TLV) objects.
o Several optimizations SHOULD be done to the MIH NSLP protocol.
These optimizations SHOULD minimize the number of signalling
messages and improve the MIH NSLP performance. An example of an
optimization is the usage of a cache feature for the MIHF ID and
IP Address mapping in the source and middle MIH NSLP.
These open issues will be addressed in future versions of this
document.
8. Acknowledgments
The authors would like to thank all the partners of the IST FP6
Integrated Project WEIRD which were involved in the development of
the mobility architecture of the project, especially, Eugen Borcoci,
Massimiliano Taglieri and Bruno Sousa.
9. Normative References
[1] Melia, T., Bajko, G., Das, S., Golmie, N., Xia, Z., and J.
Zuniga, "Mobility Services Framework Design",
draft-ietf-mipshop-mstp-solution-01 (work in progress),
February 2008.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Cordeiro, et al. Expires August 21, 2008 [Page 20]
Internet-Draft MIH NSLP February 2008
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005.
[4] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-15 (work in
progress), February 2008.
[5] Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Quality-
of-Service Signaling", draft-ietf-nsis-qos-nslp-16 (work in
progress), February 2008.
[6] "IEEE Draft Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", IEEE 802.21 Working Group,
February 2007.
[7] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
Steps in Signaling (NSIS)", RFC 4081, June 2005.
Authors' Addresses
Luis Cordeiro
University of Coimbra
Polo II - Pinhal de Marrocos
Coimbra 3030-290
Portugal
Email: cordeiro@dei.uc.pt
Marilia Curado
University of Coimbra
Polo II - Pinhal de Marrocos
Coimbra 3030-290
Portugal
Email: marilia@dei.uc.pt
Pedro Neves
Portugal Telecom Inovacao, S.A.
Rua Eng. Jose Ferreira Pinto Basto
Aveiro 3810-106
Portugal
Email: est-p-neves@ptinovacao.pt
Cordeiro, et al. Expires August 21, 2008 [Page 21]
Internet-Draft MIH NSLP February 2008
Susana Sargento
University of Aveiro
Campus Universitario de Santiago
Aveiro 3810-193
Portugal
Email: ssargento@det.ua.pt
Giada Landi
Consorzio Pisa Ricerche
Via Turati, 43-45
Pisa 56125
Italy
Email: g.landi@cpr.it
Xiaoming Fu
University of Goettingen
Lotzestrasse 16-18
Goettingen 37083
Germany
Email: fu@cs.uni-goettingen.de
Cordeiro, et al. Expires August 21, 2008 [Page 22]
Internet-Draft MIH NSLP February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Cordeiro, et al. Expires August 21, 2008 [Page 23]