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]