Network Working Group C.H. Lee
Internet-Draft J.R. Zheng
Expires: April 8, 2006 C.M. Huang
National Cheng Kung University
October 5, 2005
SIP-based Network Mobility (SIP-NEMO) Route Optimization
draft-ming-nemo-sipnemo-00.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 8, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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. It results in sub-optimal routing and long transmission
C.H. Lee, et al. Expires April 8, 2006 [Page 1]
Internet-Draft SIP-NEMO RO October 2005
delay. This document describes the SIP-based Network Mobility (SIP-
NEMO) Route Optimization (RO) that achieves optimal routing and
reduces the limitation due to the bi-direction tunnel using Session
Initiation Protocol (SIP).
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 Optimization . . . . . . . . . . . . . . . . . . . . 12
3.2. Nested Optimization . . . . . . . . . . . . . . . . . . . 13
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
C.H. Lee, et al. Expires April 8, 2006 [Page 2]
Internet-Draft SIP-NEMO RO October 2005
1. Introduction
The NEMO Basic Support protocol [1] extends Mobile IPv6 (MIPv6) [2]
to support network mobility. When the 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. With the
NEMO Basic Support, 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 [9].
The document describes protocol extensions to SIP to support for
network mobility. The extensions, which is called SIP-based Network
Mobility (SIP-NEMO) protocol, are compatiable with SIP and satisfy
the goals and requirements defined in [6] for network mobility.
Furthermore, SIP-NEMO achieves Route Optimization (RO) even if the
mobile network is nested.
It is expected for readers to be familiar with general terminologies
related to NEMO defined in [1], and SIP defined in [5] and [7]. 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 [8].
This document defines the following terms.
C.H. Lee, et al. Expires April 8, 2006 [Page 3]
Internet-Draft SIP-NEMO RO October 2005
SIP Network Mobility Server (SIP-NMS)
The entity which is the default gateway of the mobile network.
It acts as a 'proxy' for all nodes in 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 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 8, 2006 [Page 4]
Internet-Draft SIP-NEMO RO October 2005
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 regarded as a hybrid of SIP proxy and SIP client.
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-
NMS will acquire a new address. As soon as the SIP-NMS acquires a
C.H. Lee, et al. Expires April 8, 2006 [Page 5]
Internet-Draft SIP-NEMO RO October 2005
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. For the SIP-MN, the SIP-NMS
acts as a SIP proxy. Therefore, the registered SIP-MN can
communicate with SIP Correspondent Nodes (SIP-CNs) via the SIP-NMS.
Once the mobile network changes its point of attachment, the SIP-NMS
acts as a SIP client, i.e., 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 The unique URI address of the 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 The current address of the node. After changing the point of
attachment, a node can get a new address from the new attached
subnet. The current 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 The unique URI address of the caller. The URI address is
retrieved from the FROM field of the SIP header.
o The current address of the caller. The current address is
retrieved from the CONTACT field of the SIP header.
C.H. Lee, et al. Expires April 8, 2006 [Page 6]
Internet-Draft SIP-NEMO RO October 2005
o The unique URI address of the callee. The URI address is
retrieved from the TO field of the SIP header.
o The current address of the callee. If the callee is a SIP-CN, the
current address is retrieved from the INVITE field of the SIP
header; if the callee is a SIP-MN, the current address is
referenced to the Binding List based on the TO field of the SIP
header.
o The session status. The session status can be 'INVITING',
'RINGING', 'SUCCESS' and 'TERMINATED'. Once the staus becomes
'TERMINATED', this entry SHOULD be deleted from the Session List.
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 8, 2006 [Page 7]
Internet-Draft SIP-NEMO RO October 2005
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 8, 2006 [Page 8]
Internet-Draft SIP-NEMO RO October 2005
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 8, 2006 [Page 9]
Internet-Draft SIP-NEMO RO October 2005
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 URI 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 8, 2006 [Page 10]
Internet-Draft SIP-NEMO RO October 2005
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 8, 2006 [Page 11]
Internet-Draft SIP-NEMO RO October 2005
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
nested. 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 Optimization
The basic optimization considers that the mobile network has only a
single level of nested. 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. 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 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: The basic 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
request to the current address of the SIP-CN. The SIP-CN can
C.H. Lee, et al. Expires April 8, 2006 [Page 12]
Internet-Draft SIP-NEMO RO October 2005
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 Optimization
The nested optimization considers that the mobile network is nested
and has various levels of complexity. For example, a mobile network
has two levels of nested. 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: The nested 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 8, 2006 [Page 13]
Internet-Draft SIP-NEMO RO October 2005
4. 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, during the invitation process, the
transmission route between a SIP-CN and 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. 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
nested. SIP-NEMO MUST NOT increase the header overhead due to
signaling.
C.H. Lee, et al. Expires April 8, 2006 [Page 14]
Internet-Draft SIP-NEMO RO October 2005
5. 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 8, 2006 [Page 15]
Internet-Draft SIP-NEMO RO October 2005
6. IANA Considerations
This is an informational document and does not require any IANA
action.
C.H. Lee, et al. Expires April 8, 2006 [Page 16]
Internet-Draft SIP-NEMO RO October 2005
7. References
7.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-00 (work in progress),
July 2005.
[4] Ng, C., "Network Mobility Route Optimization Solution Space
Analysis", draft-ietf-nemo-ro-space-analysis-00 (work in
progress), September 2005.
[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-04 (work in progress),
February 2005.
[7] 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.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[9] 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 8, 2006 [Page 17]
Internet-Draft SIP-NEMO RO October 2005
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 8, 2006 [Page 18]
Internet-Draft SIP-NEMO RO October 2005
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 (2005). 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 8, 2006 [Page 19]