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