Network Working Group C.H. Lee
Internet-Draft J.R. Zheng
Expires: April 18, 2007 C.M. Huang
National Cheng Kung University
October 15, 2006
SIP-based Network Mobility (SIP-NEMO) Route Optimization (RO)
draft-ming-nemo-sipnemo-01.txt
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 April 18, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Network Mobility (NEMO) Basic Support protocol enables a mobile
network to change its point of attachment and keeps nodes in the
mobile network reachable when the mobile network moves in the
Internet. However, using the NEMO Basic Support protocol, all
traffic must pass through the bi-directional tunnel between a mobile
router and its home agent when the mobile router leaves its home
network. The bi-directional tunnel results in sub-optimal routing
C.H. Lee, et al. Expires April 18, 2007 [Page 1]
Internet-Draft SIP-NEMO RO October 2006
and long transmission delay. This document describes the SIP-based
Network Mobility (SIP-NEMO) Route Optimization (RO) that achieves
optimal routing and reduces the limitation induced by Mobile IPv6.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of the SIP-NEMO . . . . . . . . . . . . . . . . . . . 5
2.1. Data Structure . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Invitation . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Header Translation . . . . . . . . . . . . . . . . . . . . 10
3. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Basic Route Optimization . . . . . . . . . . . . . . . . . 12
3.2. Nested Route Optimization . . . . . . . . . . . . . . . . 13
3.3. Local Route Optimization . . . . . . . . . . . . . . . . . 14
4. Signal Reduction . . . . . . . . . . . . . . . . . . . . . . . 15
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
C.H. Lee, et al. Expires April 18, 2007 [Page 2]
Internet-Draft SIP-NEMO RO October 2006
1. Introduction
The NEMO Basic Support protocol [1] extends Mobile IPv6 (MIPv6) [2]
to support network mobility. When a Mobile Router (MR) changes its
point of attachment and leaves its home network, it would establish a
bi-directional tunnel to its Home Agent (HA) for keeping the
reachablity of all nodes in the mobile network. The tunnel is set up
once the Binding Update (BU), which carries the current Care-of-
Address (CoA) of the MR, is successfully sent to the HA.
Network Mobility Route Optimization Problem Statement [3] and Network
Mobility Route Optimization Solution Space Analysis [4] describe the
limitation and sub-optimality of the NEMO Basic Support protocol.
With the NEMO Basic Support protocol, all traffic to and from the
mobile network must go through the bi-directional tunnel and result
in a longer route. This kind of sub-optimal routing leads to
transmission delay, packet overhead and bottleneck of the HA.
Applications, e.g., real-time streaming, may be unable to tolerate
such sub-optimality.
Session Initiation Protocol (SIP) [5] is an application-layer control
protocol. SIP can create, maintain and terminate the sessions with
more than one node. Applications, such as VoIP and Video
conferences, employ SIP for signaling. Since SIP supports name
mapping and redirection services, SIP is also used for personal
mobility [10].
The document describes protocol extensions to SIP to support network
mobility. The extensions, which is called SIP-based Network Mobility
(SIP-NEMO) protocol, are compatiable with SIP and satisfy the essence
of network mobility that has been described in [6]. Furthermore,
SIP-NEMO achieves Route Optimization (RO) even if the mobile network
is nested arbitrarily.
It is expected for readers to be familiar with general terminologies
related to NEMO defined in [7], and SIP defined in [5] and [8]. A
point to note is that a mobile network is away from its home network
throughout this document unless it is explicitly specified that it is
at home.
1.1. 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 [9].
This document defines the following terms.
C.H. Lee, et al. Expires April 18, 2007 [Page 3]
Internet-Draft SIP-NEMO RO October 2006
SIP Network Mobility Server (SIP-NMS)
The entity which is the default gateway of the mobile network.
SIP Home Server (SIP-HS)
The entity which plays the role of recording the current point
of attachment of the SIP-NMS.
SIP Foreign Server (SIP-FS)
The entity which provides a URI-list service for signal
reduction.
SIP Mobile Node (SIP-MN)
The Mobile Node with SIP capacity.
SIP Correspondent Node (SIP-CN)
The Correspondent Node with SIP capacity.
Sub-SIP-NMS
The downstream SIP-NMS in the nested mobile network.
Parent-SIP-NMS
The upstream SIP-NMS in the nested mobile network
Root-SIP-NMS
The SIP-NMS which is at the top level of the nested mobile
network.
C.H. Lee, et al. Expires April 18, 2007 [Page 4]
Internet-Draft SIP-NEMO RO October 2006
2. Overview of the SIP-NEMO
In SIP-NEMO, a mobile network is a subnet that is able to move
arbitrarily in the Internet. A mobile network can be accessed in the
Internet via a specified entity called SIP Network Mobility Server
(SIP-NMS) which manages all traffic to and from the mobile network.
A mobile network MAY consist of nested subnets, i.e., a SIP-NMS can
be attached to other mobile networks belonging to different SIP-NMSs.
Figure 1 depicts the architecture of SIP-NEMO. In Figure 1, the
mobile network carried by SIP-NMS 2 is nested because SIP-NMS 3 is
attached to SIP-NMS 2.
+-------------------+ +-------------------+
| SIP-MN_SIP Server | | SIP-CN_SIP Server |
+-----------+-------+ +-------+-----------+
| |
| |
+--------+ +------+--------------------+-------+ +--------+
| SIP-HS +---+ Internet +---+ SIP-CN |
+--------+ +------+--------------------+-------+ +--------+
| |
+-----+-----+ +-----+-----+
| SIP-NMS 1 | | SIP-NMS 2 |
+-----+-----+ +-----+-----+
| |
| +-----+-----+
---+---+-------- + SIP-NMS 3 |
| +-----+-----+
+----+-----+ |
| SIP-MN 1 | --------+----+---
+----------+ |
+----+-----+
| SIP-MN 2 |
+----------+
Figure 1: The architecture of SIP-NEMO.
The SIP-NMS is different from the mobile router of NEMO, which solves
the network mobility problem by extending the Mobile IPv6 protocol.
The SIP-NMS employs SIP to solve the network mobility problem. One
SIP-NMS is a Back-To-Back User Agent (B2BUA) and acts as the gateway
of a mobile network.
Each SIP-NMS MUST have its associated SIP Home Server (SIP-HS). When
the SIP-NMS registers with its SIP-HS, the SIP-NMS can get an unique
URI address. Once the mobile network moves to a new subnet, the SIP-
C.H. Lee, et al. Expires April 18, 2007 [Page 5]
Internet-Draft SIP-NEMO RO October 2006
NMS will acquire a new address. As soon as the SIP-NMS acquires a
new address from the new subnet, it re-registers with its SIP-HS
using the REGISTER method. The SIP-HS SHOULD bind the new address of
the SIP-NMS to its unique URI address after receiving the REGISTER
request, as described in Section 2.2.
If a SIP Mobile Node (SIP-MN) is attached to a mobile network, it
SHOULD register with the corresponding SIP-NMS using the REGISTER
method, as described in Section 2.2. Since the SIP-NMS is the
gateway of a mobile network, the registered SIP-MN SHOULD communicate
with SIP Correspondent Nodes (SIP-CNs) via the SIP-NMS.
Once the mobile network changes its point of attachment, the SIP-NMS
re-invites all on-going sessions instead of all SIP-MNs in the mobile
network using the INVITE method, as described in Section 2.3. Hence,
the SIP-NMS can make all SIP-MNs be transparent to the movement of
the mobile network.
2.1. Data Structure
Each SIP-NMS and SIP-HS MUST maintain a Binding List. The Binding
List is maintained for recording information about each registered
node. An entry is created or updated when a SIP-NMS or a SIP-HS
receives a REGISTER request. Each Binding List entry contains the
following fields.
o URI. URI indicates the URI address of a node. Each SIP-MN and
SIP-NMS has its own URI address. The URI address SHOULD be unique
and be usually used to the FROM field of the SIP header for
identification.
o Contact. Contact indicates the contact address of a node. After
changing the point of attachment, a node can get a new address
from the new attached subnet. The contact address of the node is
usually recorded in the CONTACT field of the SIP header.
Moreover, the SIP-NMS MUST maintain a Session List. The Session List
is maintained for recording information about the status of the on-
goning session. An entry is create or update when a SIP-NMS receives
an INVITE request. Each Session List entry contains the following
fields.
o FROM-URI. FROM-URI indicates the unique URI address of the
caller. FROM-URI is retrieved from the FROM field of the SIP
header.
o FROM-Contact. FROM-Contact indicates the contact address of the
caller. FROM-Contact is retrieved from the CONTACT field of the
C.H. Lee, et al. Expires April 18, 2007 [Page 6]
Internet-Draft SIP-NEMO RO October 2006
SIP header.
o TO-URI. TO-URI indicates the unique URI address of the callee.
TO-URI is retrieved from the TO field of the SIP header.
o TO-Contact. TO-Contact indicates the contact address of the
callee. If the callee is a SIP-CN, the contact address is
retrieved from the INVITE field of the SIP header; if the callee
is a SIP-MN, the contact address is referenced to the Binding List
based on the TO field of the SIP header.
o Status. Status can be 'INVITING', 'RINGING', 'SUCCESS' and
'TERMINATED'. Once Staus becomes 'TERMINATED', this entry SHOULD
be deleted from the Session List.
o LR. If LR is TURE, it means that there is a local route inside
the mobile network. The default value is FALSE.
2.2. Registration
Registration creates a binding between the current address and the
unique URI address. In SIP-NEMO, not only each SIP-NMS SHOULD
register with its SIP-HS but also all nodes attached to a mobile
network SHOULD register with the corresponding SIP-NMS of the mobile
network. Two kinds of registration are described as follows.
o A node registers with the SIP-NMS.
When a SIP-MN enters a mobile network, it would get a new
address from the mobile network. Once it acquires a new
address, it SHOULD register with the SIP-NMS by sending a
REGISTER request to the SIP-NMS. The SIP-NMS MUST create an
entry in its Binding List for this SIP-MN. Then, the SIP-NMS
SHOULD reply the SIP-MN with a 200 OK message.
In additiion to the registration with the SIP-NMS, the SIP-MN
also needs to re-register with its SIP server about its new
address. In SIP-NEMO, the SIP-NMS SHOULD translate part of SIP
header in the REGISTER request and then forward the request to
the SIP-MN's SIP server. The header translation uses the
unique URI address of the SIP-NMS in place of the SIP-MN's new
address as described in Section 2.4. Therefore, if a SIP-CN
wants to invite this SIP-MN, it MUST invite the SIP-NMS first.
The invitation process is described in Section 2.3.
Figure 2 depicts the complete registration process. After the
successful registration with the SIP-NMS, the SIP-MN is able to
configure the SIP-NMS as a SIP proxy.
C.H. Lee, et al. Expires April 18, 2007 [Page 7]
Internet-Draft SIP-NEMO RO October 2006
SIP-MN SIP-NMS SIP-MN_SIP Server
| | |
| REGISTER | |
|--------------->| |
| | |
| 200 OK | |
|<---------------| REGISTER |
| |--------------->|
| | |
| | 200 OK |
| |<---------------|
| | |
Figure 2: A SIP-MN registers with the SIP-NMS.
When a SIP-NMS enters another mobile network and becomes a
nested mobile network, it SHOULD also register with the
corresponding SIP-NMS. The newly SIP-NMS is called Sub-SIP-NMS
and the SIP-NMS registered by the newly SIP-NMS is called
Parent-SIP-NMS. The Parent-SIP-NMS MUST create a new entry in
its Binding List for the Sub-SIP-NMS. After the successful
registration, the Parent-SIP-NMS also translates the REGISTER
request and then forwards the request to the Sub-SIP-NMS's
SIP-HS as a SIP-MN registers with the SIP-NMS.
o A SIP-NMS registers with the SIP-HS.
When each SIP-NMS changes its point of attachement in the
Internet, it would get a new address from the new subnet. Once
it acquires a new address, it MUST re-register with the SIP-HS
as a SIP client. The re-registration process employs the
REGISTER method, i.e., sending a REGISTER request to the
SIP-HS.
Once the SIP-HS receives a REGISTER request, it SHOULD check
whether the SIP-NMS has registered or not. If the SIP-NMS has
registered before, the SIP-HS SHOULD use the new address of the
SIP-NMS in place of the current address in the Binding List.
Then, the SIP-HS SHOULD response a 200-OK reply to the SIP-NMS.
If the SIP-NMS has not registered with the SIP-HS, the SIP-HS
MUST create a new entry in the Binding List and assign an
unique URI address to the SIP-NMS. Then, the SIP-HS retrieves
the new address of the SIP-NMS from the REGISTER request and
then puts the new address into the Binding List.
C.H. Lee, et al. Expires April 18, 2007 [Page 8]
Internet-Draft SIP-NEMO RO October 2006
2.3. Invitation
Invitation creates a session between a SIP-MN and a SIP-CN. If a
SIP-CN wants to invite a SIP-MN which is in a mobile network, the
SIP-CN SHOULD send an INVITE request to the SIP-MN's SIP server. As
described in Section 2.2, the SIP server MUST redirect the request to
the URI address of the SIP-NMS. In order to invite the SIP-NMS, the
SIP-CN MUST re-send the request to the SIP-NMS's SIP-HS. When the
SIP-HS receives the INVITE request, it SHOULD look up its Binding
List and check whether the invited SIP-NMS has registered or not. If
the SIP-NMS has registered before, the SIP-HS MUST translate the
request by adding the RECORD-ROUTE field in which the value is set to
the SIP-NMS's URI address and then forward the request to the current
address of the SIP-NMS. The added RECORD-ROUTE field can indicate
the next hop when the mobile network is nested.
When the SIP-NMS receives an INVITE request, it SHOULD check whether
the invited SIP-MN is in its carried mobile network or not by looking
up its Binding List. If the SIP-MN is in the mobile network, the
SIP-NMS can determine the current address of the SIP-MN from the
Binding List; if the SIP-MN is not in the Binding List, the SIP-NMS
SHOULD check the RECORD-ROUTE field in the SIP header and determine
whether any node in the Binding List is indicated in the RECORD-ROUTE
field. Then, the SIP-NMS would take the node indicated in the
RECORD-ROUTE field as the next hop. Next, the SIP-NMS MUST create an
entry in the Session List for this session. The information about
the caller and the callee, such as the unique URI address, the
current address or the session status, are retrieved from the SIP
header of the INVITE request and recorded in the Session List as
described in Section 2.1. Finally, the SIP-NMS MUST translate part
of the SIP header and forword the request to the SIP-MN or the next
hop.
However, when a mobile network changes its point of attachment, the
sessions between the SIP-MNs in the mobile network and the SIP-CNs
would be interrupted unless performing the re-invitation. The SIP-
NMS plays the role of re-inviting. Once the SIP-NMS is attached to a
new subnet and acquires a new address from the new subnet, it would
send INVITE requests to all SIP-CNs without informing SIP-MNs in the
mobile network. Hence, all SIP-MNs in the mobile network are
transparent to the movement.
Figure 3 depicts the re-invitation after the SIP-NMS moves to a new
subnet.
C.H. Lee, et al. Expires April 18, 2007 [Page 9]
Internet-Draft SIP-NEMO RO October 2006
SIP-NMS SIP-CNs
| |
| INVITE |
|===============>|
| |
| 180 RINGING |
|<---------------|
| 200 OK |
|<---------------|
| |
Figure 3: The re-invitation after the SIP-NMS moves.
The SIP-NMS is able to re-invite all SIP-CNs in place of all SIP-MNs
in the mobile network because the SIP-NMS creates a Session List in
which the information of all sessions is recorded. One entry is
added in the Session List when the SIP-MN invites or is invited. If
the session is terminated, the corresponding entry is deleted from
the session cache. Therefore, after the movement of the mobile
network, the SIP-NMS MUST look up the Session List and re-invite all
sessions that are still recorded in the Session List.
2.4. Header Translation
In SIP-NEMO, a SIP-NMS does not just forward the REGISTER and INVITE
requests. In order to support network mobility, the SIP-NMS MUST
translate part of the SIP header in order to route the transmission
directly. Two SIP methods, REGISTER and INVITE, are taken into
consideration.
For the REGISTER request, the SIP-NMS SHOULD translate the CONTACT
field in the SIP header from the SIP-MN's new address to the SIP-
NMS's URI address. Therefore, all requests to the SIP-MN will be
redirected to the SIP-NMS.
One point to note is that the SIP-NMS MUST translate the REGISTER
requests that are sent by the registered nodes. If the SIP-NMS
receives a REGISTER request that is not sent by the registered node,
it SHOULD bypass the request without any translation. For example,
in Figure 1, if SIP-NMS 2 receives a REGISTER request from the SIP-MN
2, which registers with SIP-NMS 3, SIP-NMS 2 just forwards the
request but does not translate it.
For the INVITE request, the SIP-NMS SHOULD translate the CONTACT
field from the SIP-MN's new address to the SIP-NMS's contact address
and add the RECORD-ROUTE field in which the SIP-NMS's URI address is
filled. The RECORD-ROUTE field is set to force all following
requests of this session to be routed via the SIP-NMS.
C.H. Lee, et al. Expires April 18, 2007 [Page 10]
Internet-Draft SIP-NEMO RO October 2006
Unlike the REGISTER request, the SIP-NMS MUST translate all INVITE
requests to and from the mobile network and create the corrsponding
entry in its Session List. Once the mobile network changes it point
of attachment, the SIP-NMS is able to re-invite all sessions.
In order to handle the routing of the nested mobile network, the
SIP-HS MUST translate all INVITE requests of all registered SIP-NMSs,
too. The SIP-HS SHOULD add the RECORD-ROUTE field in which the value
is set to the URI address of the SIP-NMS. Therefore, if the mobile
network is nested, the SIP-NMS can determine the next hop according
to the RECORD-ROUTE field in the SIP header.
One point to note is that the same RECORD-ROUTE field MUST NOT be
added more than one time in order to aviod the routing loop. If the
SIP-NMS has added the RECORD-ROUTE field, its corresponding SIP-HS
MUST NOT add the same field, and vice versa.
C.H. Lee, et al. Expires April 18, 2007 [Page 11]
Internet-Draft SIP-NEMO RO October 2006
3. Route Optimization
Using the header translation, SIP-NEMO can solve the route sub-
optimality problem even if the mobile network has complex levels of
nesting. All data are directly transmitted between the SIP-MN and
the SIP-CN via the corresponding SIP-NMSs without any intermediate
node, e.g., Home Agent.
3.1. Basic Route Optimization
The basic route optimization considers that the mobile network has
only a single level of nesting. If a SIP-CN which is outside a
mobile network wants to invite a SIP-MN which is inside a mobile
network, the SIP-CN SHOULD send an INVITE request to the SIP-MN's SIP
server. The SIP server of the SIP-MN redirects the INVITE request to
the SIP-HS according to the previous registration, as described in
Section 2.2. Then, the SIP-HS checks its Binding List, translates
the request as descried in Section 2.4 and forwards the request to
the current address of the SIP-NMS. Finally, the SIP-NMS creates an
entry in the Session List for this session, translates the request
and forwards the request to the SIP-MN based on its Binding List as
described in Section 2.3.
After receiving the INVITE request, the SIP-MN is able to reply the
SIP-CN via the SIP-NMS directly without passing the response message
to the SIP-HS or the SIP server. Therefore, in addition to the
begining of the invitation, the route between the SIP-MN and the
SIP-CN is optimal, i.e., without going through any intermediate node.
Figure 4 depicts the basic route optimization.
+-------------------+ 2.Redirect +--------+
| SIP-MN_SIP Server |==============| SIP-HS |
+-------------------+ +--------+
|| || 3.INVITE
|| 1.INVITE ||
+--------+ +---------+ 4.INVITE +--------+
| SIP-CN |********************| SIP-NMS |=============| SIP-MN |
+--------+ +---------+*************+--------+
=====: Inviting path *****: Optimal path
Figure 4: Basic route optimization
On the otehr hand, if the SIP-MN wants to invite a SIP-CN in the
Internet, it SHOULD send an INVITE request to the SIP-CN's SIP server
via the SIP-NMS. The SIP server of the SIP-CN redirects the INVITE
C.H. Lee, et al. Expires April 18, 2007 [Page 12]
Internet-Draft SIP-NEMO RO October 2006
request to the current address of the SIP-CN. The SIP-CN can
response the reply directly back to the SIP-NMS because the INVITE
request has been translated by the SIP-NMS, as described in
Section 2.4.
3.2. Nested Route Optimization
The nested route optimization considers that the mobile network is
nested and has various levels of complexity. For example, a mobile
network has two levels of nesting. The Root-SIP-NMS is called SIP-
NMS 1 and its corresponding SIP-HS is called SIP-HS 1. The SIP-NMS
of the second level is called SIP-NMS 2 and its SIP-HS is called
SIP-HS 2. If a SIP-CN wants to invite a SIP-MN which is attached to
SIP-NMS 2, the SIP-CN SHOULD send an INVITE to the SIP-MN's SIP
server. Then, the INVITE request would be transmitted as the
sequence depicted in Figure 5.
1.INVITE 2.Redirect 3.INVITE
+------+ +-----------------+ +--------+ +--------+
|SIP-CN|======|SIP-MN_SIP Server|========|SIP-HS 2|========|SIP-HS 1|
+------+ +-----------------+ +--------+ +--------+
* ||
***************** 4.INVITE||
******************** ||
************ ||
* ||
+------+ 6.INVITE +---------+ 5.INVITE +---------+
|SIP-MN|====================|SIP-NMS 2|===================|SIP-NMS 1|
+------+********************+---------+*******************+---------+
=====: Inviting path *****: Optimal path
Figure 5: Nested route optimization
After the session is established, data can be transmitted from the
SIP-CN to the Root-SIP-NMS, i.e., SIP-NMS 1 in this example. The
Root-SIP-NMS can forward data downstream according to the RECORD-
ROUTE field in the SIP header, as described in Section 2.3 and
Section 2.4.
If the SIP-MN wants to invite a SIP-CN, the SIP-MN SHOULD send an
INVITE request to the SIP-CN's SIP server via SIP-NMS 2 and SIP-NMS
1. After the SIP server redirects the request to the SIP-CN, the
SIP-CN can reply the SIP-MN driectly by sending the response to SIP-
NMS 1. Then, SIP-NMS 1 forwards the response to SIP-NMS 2. Finally,
SIP-NMS 2 forwards to the SIP-MN and the session is established.
C.H. Lee, et al. Expires April 18, 2007 [Page 13]
Internet-Draft SIP-NEMO RO October 2006
3.3. Local Route Optimization
The local route optimization considers that a SIP-MN and a SIP-CN are
in the same mobile network but managed by different SIP-NMSs. For
example, a nested mobile network is made up of three SIP-NMSs, in
which the Root-SIP-NMS is called SIP-NMS 1 and its corresponding
SIP-HS is called SIP-HS 1. Two Sub-SIP-NMSs, SIP-NMS 2 and SIP-NMS
3, are attached to SIP-NMS 1 and the corresponding SIP-HSs are SIP-HS
2 and SIP-HS 3. A SIP-CN is attached to SIP-NMS 2 and a SIP-MN is
attached to SIP-NMS 3. Thus, when the SIP-CN want to invite the
SIP-MN, the SIP-CN SHOULD send an INVITE to the SIP-MN's SIP server.
The INVITE request would be delivered as the sequence depicted in
Figure 6.
4.Redirect 5.INVITE
+-----------------+ +--------+ +--------+
|SIP-MN_SIP Server|==========|SIP-HS 3|====================|SIP-HS 1|
+-----------------+ +--------+ +--------+
\\ 3.INVITE 6.INVITE //
==================== ==========================
\\ //
+---------+ 2.INVITE +---------+ 7.INVITE +---------+
|SIP-NMS 2|=================|SIP-NMS 1|===================|SIP-NMS 3|
+---------+*****************+---------+*******************+---------+
*|| ||*
*|| 1.INVITE 8.INVITE||*
*|| ||*
+------+ +------+
|SIP-CN| |SIP-MN|
+------+ +------+
=====: Inviting path *****: Optimal path
Figure 6: Local route optimization
Since SIP-NMS 1 is the parent-SIP-NMS of SIP-NMS 2, as described in
Section 2.3 and Section 2.4, the SIP-NMS 1 MUST create an entry in
the Session List for this session. When SIP-HS 1 forwards the INVITE
request to SIP-NMS 1, SIP-NMS 1 is able to determine that it has
received the same INVITE request twice by discovering the existed
entry for this session. Therefore, SIP-NMS 1 MUST set the LR flag to
TURE. Once the LR flag is TURE, the data SHOULD be transmitted only
inside the mobile network without going through the Internet.
C.H. Lee, et al. Expires April 18, 2007 [Page 14]
Internet-Draft SIP-NEMO RO October 2006
4. Signal Reduction
When a mobile network changes its point of attachment, the
corresponding SIP-NMS should be responsible for the re-invitation as
described in Section 2.3. However, the re-invitation may produce a
burst of INVITE messages on wireless links. In order to compress
these INVITE messages, SIP-FSs which distribute in the Internet are
proposed to provide a URI-list service.
Since these INVITE messages sent to each SIP-CN are similar, the SIP-
NMS is able to combine all destinations, i.e., the addresses of all
corresponding SIP-CNs, into a URI list. Figure 7 depicts an example
of a URI list. In the URI list, an entry presents a corresponding
SIP-CN and each entry has 2 attibutes. The "uri" field indicates the
destination address and the "src" field indicates the source address.
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com" src="sip:a@home.com"/>
<entry uri="sip:ted@example.net" src="sip:b@home2.com"/>
</list>
</resource-lists>
Figure 7: URI list.
Figure 8 depicts the process of the re-invitation with a URI-list
service. Once the SIP-NMS looks up the Session List and then creates
the corresponding URI list, the SIP-NMS would embed the URI list in
an INVITE message. Then, the SIP-NMS would send this INVITE message
to a local SIP-FS. When a SIP-FS receives an INVITE message with an
embedded URI list, the SIP-FS is responsible for re-producing the
original INVITE messages for each SIP-CN. The SIP-FS SHOULD replace
(1) the INVITE field and the TO field of the INVITE message with the
uri field of the URI list and (2) the FROM field of the INVITE
message with the src field of the URI list. Finally, the SIP-FS
sends each re-produced INVITE message to the corresponding
destination.
C.H. Lee, et al. Expires April 18, 2007 [Page 15]
Internet-Draft SIP-NEMO RO October 2006
SIP-NMS SIP-FS SIP-CN 1 SIP-CN 2
| INVITE with a | | |
| URI list | | |
|===============>| | |
| 200 OK | | |
|<---------------| | |
| | INVITE | |
| |--------------->| |
| | INVITE | |
| |-------------------------------->|
| | | |
| | 180 RINGING | |
|<--------------------------------| |
| | | 180 RINGING |
|<-------------------------------------------------|
| | 200 OK | |
|<--------------------------------| |
| | | 200 OK |
|<-------------------------------------------------|
| | | |
Figure 8: The re-invitation with a URI list service.
One point to note is that signal reduction is OPTIONAL but is
RECOMMENDED to operate in the proposed SIP-NEMO.
C.H. Lee, et al. Expires April 18, 2007 [Page 16]
Internet-Draft SIP-NEMO RO October 2006
5. Analysis
Based on [4], we attempt to analyze SIP-NEMO RO from the following
perspectives.
o Involved Entities.
In SIP-NEMO, the SIP-NMS and the SIP-HS are involved in route
optimization. When the SIP-HS or the SIP-NMS receives the
INVITE message, they MUST translate the SIP header as described
in Section 2.4. Therefore, data can be transmitted to the SIP-
NMS without any intermediate node, such as a SIP-HS or a SIP
server.
Since SIP-NEMO is able to achieve RO using the header
translation in the SIP-NMS and the SIP-HS, a SIP-MN and a
SIP-CN are general SIP clients. Hence, SIP-NEMO can be
compatible with SIP. Any node supporting SIP can roam into the
SIP-NEMO environment.
o Transmission Route.
As described in Section 3, the transmission route from a SIP-CN
to a SIP-MN MUST be (SIP-CN)-(SIP server)-(SIP-HS)^n-(SIP-
NMS)^n-(SIP-MN), in which n is the number of levels of mobile
network. On the other hand, the transmission route from a
SIP-MN to a SIP-CN MUST be (SIP-MN)-(SIP-NMS)^n-(SIP server)-
(SIP-CN). However, after the invitation process, the
transmission route MUST be reduced to be (SIP-CN)-(SIP-NMS)^n-
(SIP-MN). Based on the above transmission route, SIP-NMEO can
be proved to possess the optimal transmission route between a
SIP-MN and a SIP-CN.
o Signaling Overhead.
Because SIP is a control protocol for signaling, SIP-NEMO RO is
done off-plane, i.e., sending signaling messages independently
from the data packets. Hence, no additional header SHOULD be
be appended to each data packet. Besides, SIP-NEMO use the
header translation in place of the encapsulation. Thus, the
increase of the SIP header is not proportional to the level of
nesting. SIP-NEMO MUST NOT increase the header overhead due to
signaling.
Although SIP-NEMO RO has no header overhead problem, SIP-NEMO
RO may induce a burst of signaling messages during the re-
invitation. Since the transmission quality of wireless links
is easily affected by a large number of small-sized packets,
C.H. Lee, et al. Expires April 18, 2007 [Page 17]
Internet-Draft SIP-NEMO RO October 2006
SIP-NEMO is RECOMMENDED to employ a URI-list service to
aggregate a lot of small-sized INVITE messages into one packet
for reducing the signaling messages on wireless links.
C.H. Lee, et al. Expires April 18, 2007 [Page 18]
Internet-Draft SIP-NEMO RO October 2006
6. Security Considerations
This is an informational document that describes the extensions to
SIP to support network mobility and does not introduce any additional
security concern.
C.H. Lee, et al. Expires April 18, 2007 [Page 19]
Internet-Draft SIP-NEMO RO October 2006
7. IANA Considerations
This is an informational document and does not require any IANA
action.
C.H. Lee, et al. Expires April 18, 2007 [Page 20]
Internet-Draft SIP-NEMO RO October 2006
8. Change Log
1. Added Section 3.3 and Section 4.
2. Added a new field "LR" in the Session List.
3. Revised Figure 4 and Figure 5.
4. Revised Section 2.1 and Section 5.
C.H. Lee, et al. Expires April 18, 2007 [Page 21]
Internet-Draft SIP-NEMO RO October 2006
9. References
9.1. Normative References
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Ng, C., "Network Mobility Route Optimization Problem Statement",
draft-ietf-nemo-ro-problem-statement-03 (work in progress),
September 2006.
[4] Ng, C., "Network Mobility Route Optimization Solution Space
Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in
progress), September 2006.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[6] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-05 (work in progress),
October 2005.
[7] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-05 (work in progress), March 2006.
[8] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", BCP 75, RFC 3665, December 2003.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[10] Pandya, R., "Emerging mobile and personal communication
systems", IEEE Communications Magazine , Vol. 33, pp. 44--52,
June 1995.
C.H. Lee, et al. Expires April 18, 2007 [Page 22]
Internet-Draft SIP-NEMO RO October 2006
Authors' Addresses
Chao-Hsien Lee
National Cheng Kung University
No.1, Ta-Hsueh Road
Tainan, Taiwan 70101
R.O.C.
Phone: 88606-2080362
Email: leech@locust.csie.ncku.edu.tw
Ji-Ren Zheng
National Cheng Kung University
No.1, Ta-Hsueh Road
Tainan, Taiwan 70101
R.O.C.
Phone: 88606-2080362
Email: zhengjr@locust.csie.ncku.edu.tw
Chung-Ming Huang
National Cheng Kung University
No.1, Ta-Hsueh Road
Tainan, Taiwan 70101
R.O.C.
Phone: 88606-2757575 ext 62523
Email: huangcm@locust.csie.ncku.edu.tw
URI: http://www.mmnetlab.csie.ncku.edu.tw
C.H. Lee, et al. Expires April 18, 2007 [Page 23]
Internet-Draft SIP-NEMO RO October 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
C.H. Lee, et al. Expires April 18, 2007 [Page 24]