Network Working Group C.H. Lee Internet-Draft C.M. Huang Expires: April 18, 2007 National Cheng Kung University October 15, 2006 Multihoming in SIP-based Network Mobility (SIP-NEMO) draft-ming-monami6-multihomed-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 18, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Network mobility is proposed to let a mobile network change its point of attachment and still to keep all nodes attached to the mobile network globally reachable. However, due to scare bandwidth, limited signaling coverage and frequent link failure, a mobile network needs multihoming, i.e., multiple paths simultaneously to access the Internet, on the perspective of performance and reliability. The document specifies how to support multihoming in network mobility using the Session Initiation Protocol (SIP). The proposed Multihomed C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 1] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 SIP-based Network Mobility (SIP-NEMO) can dynamically select a path per session according to the status of egress interfaces and/or gateways. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of Multihomed SIP-NEMO . . . . . . . . . . . . . . . 5 2.1. Data Structure . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Classification . . . . . . . . . . . . . . . . . . . . . . 6 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. (n,1): Multiple E-faces, Single SIP-NMS . . . . . . . . . 9 3.2. (1,n): Single E-face, Multiple SIP-NMSs . . . . . . . . . 10 3.3. (n,n): Multiple E-faces, Multiple SIP-NMSs . . . . . . . . 13 4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Path Selection . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 15 4.3. Load Balance/Sharing . . . . . . . . . . . . . . . . . . . 15 4.4. Re-homing . . . . . . . . . . . . . . . . . . . . . . . . 16 4.5. Synchronization . . . . . . . . . . . . . . . . . . . . . 16 4.6. Nesting . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 2] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 1. Introduction Network mobility support provides a group of nodes to access the Internet continuously when they move together. 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. Analysis of Multihoming in Network Mobility Support [3] has investigated the multihoming classifications and issues in NEMO. With the advance of wireless technologies, new devices are tending to possess more than one network interface for connecting different access networks. Although new access techniques can provide wide bandwidth and support fast movement, a mobile network should have more than one path simultaneously to the Internet on the performance and reliability concerns. SIP-based Network Mobility (SIP-NEMO) Route Optimization (RO) [4] describes protocol extensions to SIP to support network mobility. The proposed SIP-NEMO protocol are compatiable with SIP and satisfy the essence of network mobility that has been described in [5]. Since SIP-NEMO uses SIP instead of Mobile IPv6, SIP-NEMO is able to achieve Route Optimization (RO) and to reduce the complexity of nesting without the limitation of Mobile IPv6. This document describes the extensions to SIP-NEMO to support multihoming. The proposed Multihomed SIP-NEMO supports that a mobile network has more than one egress gateway or/and an egress gateway has more than one egress network interface. Therefore, Multihomed SIP- NEMO selects one path, i.e., a gateway and/or an interface, for each session dynamically. If the current path is failed, Multihomed SIP- NEMO redirects sessions to alternative paths dynamically. It is expected for readers to be familiar with general terminologies related to NEMO defined in [6], SIP REFER method defined in [7], and SIP-NEMO defined in [4]. 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 & C.M. Huang Expires April 18, 2007 [Page 3] Internet-Draft MULTIHOMING IN SIP-NEMO 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 Mobile Node (SIP-MN) The Mobile Node with SIP capacity. SIP Correspondent Node (SIP-CN) The Correspondent Node with SIP capacity. Egress Interface (E-face) The network interface of a SIP-NMS which is attached to the Internet. Ingress Interface (I-face) The network interface of a SIP-NMS which provides a local link inside the mobile network. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 4] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 2. Overview of Multihomed SIP-NEMO As SIP-NEMO defined in [4], a mobile network is a subnet which can change it point of attachment arbitrarily in the Internet. SIP Network Mobility Server (SIP-NMS) is responsible for managing all traffic to and from its carried mobile network. The difference between SIP-NEMO defined in [4] and Multihomed SIP-NEMO defined in this document is whether a mobile network has more than one egress path to the Internet or not. A mobile network has multiple egress paths because it MAY have multiple SIP-NMSs or/and its SIP-NMS MAY possess multiple E-faces. Figure 1 depicts the architecture of Multihomed SIP-NEMO. In Figure 1, the mobile network has two SIP-NMSs in which SIP-NMS 1 has two E-faces. Thus, this mobile network has three egress paths simultaneously to the Internet. +-------------------+ +-------------------+ | SIP-MN_SIP Server | | SIP-CN_SIP Server | +-----------+-------+ +-------+-----------+ | | | | +--------+ +------+--------------------+-------+ +--------+ | SIP-HS +---+ Internet +---+ SIP-CN | +--------+ +---+-----+-----------------+-------+ +--------+ | | | E-face 1 | | E-face 2 | | | | +--+-----+--+ +-----+-----+ | SIP-NMS 1 | | SIP-NMS 2 | +-----+-----+ +-----+-----+ | | | | I-face | | -------+----------+---------+-------- | +----+-----+ | SIP-MN | +----------+ Figure 1: The architecture of SIP-NEMO. One point to note is that this document would only focus on multiple egress paths to the Internet. If a mobile network has multiple paths inside itself, e.g., a SIP-NMS has multiple I-faces or a SIP-MN has multiple network interfaces, these situations MUST go beyond the scope of this document. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 5] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 2.1. Data Structure In order to handle multihoming in SIP-NEMO, several new fields SHOULD be included in the Binding List and the Session List. Besides, a new list called Egress List is also defined in this document. For the Binding List, each entry adds the following fields. o Priority. Since a SIP-NMS MAY have multiple E-faces, it MAY have multiple contact addresses. Priority indicates the ranking of each contact address. For the same SIP-NMS, the value of Priority MUST be unique. For the Session List, each entry adds the following fields. o E-face ID. When a session is being established, E-face ID indicates the chosen E-face for this session. In Multihomed SIP-NEMO, each SIP-NMS MUST maintain a Egress List. The Egress List is maintained for recording information about the possible paths to the Internet. Each entry in the Egress List indicates a egress path. An entry is created or updated when a SIP- NMS has a new E-face or it receives the NOTIFY messages from other SIP-NMS. Each Egress List entry contains the following fields. o Host ID. Host ID indicates which SIP-NMS is responsible for managing this path. o E-face ID. E-face ID indicates which E-face is responsible for managing this path. o Contact. Contact indicates the corresponding contact address of this E-face. o Status. Status indicates whether this path is working or not. If Status is ON, it means that this path is available. If Status is OFF, it means that this path is unavailable and triggers the sessions using this path to be redirected to another path. o Load. Load indicates the workload of this path. 2.2. Classification Referring to Figure 1, multihomed configuration of a mobile network depends on how many SIP-NMSs are present and how many E-faces the SIP-NMSs have. For convenience, each classification is denoted by 2-tuple (x,y), where 'x' and 'y' are defined as follows. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 6] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 o 'x' indicates the number of SIP-NMSs inside a mobile network. x=1 implies that a mobile network has only one SIP-NMS. x=n implies that a mobile network has more than one SIP-NMS. o 'y' indicates the number of E-faces inside a SIP-NMS. y=1 implies that a SIP-NMS has only one E-face. y=n implies that a SIP-NMS has more than one E-face. Different values of 'x' and 'y' produces different combinations of (x,y). There are totally four possible configurations. Each configuration is identified as follows. o (1,1): Single E-face, Single SIP-NMS The (1,1) case means a mobile network has one SIP-NMS and this SIP-NMS has one E-face. If the E-face gets only one contact address from the visited subnet, this mobile network has only one egress path to the Internet. Since this situation has been solved in [4], Multihomed SIP-NEMO SHOULD NOT take this situation into considation in this document. To satisfy the requirement of multihomed configuration, at least the E-face is able to get more than one contact address. Multihomed SIP-NEMO would take this kind of situation, i.e., an E-face has several contact addresses, as the (n,1) case. o (n,1): Multiple E-faces, Single SIP-NMS The (n, 1) case means that a mobile network has one SIP-NMS and this SIP-NMS has more than one E-face. Since all E-faces is managed by the same SIP-NMS, the SIP-NMS MUST be responsible for selecting one of E-faces when a session is being established. Once the SIP-NMS detects a certain E-face is unavailable, it SHOULD look up the Session List and redirect the sessions using the failed E-face to other E-faces. o (1,n): Single E-face, Multiple SIP-NMSs The (1, n) case means that a mobile network has more than one SIP-NMS and each SIP-NMS has one E-face. In Multihomed SIP- NEMO, each SIP-NMS has its own corresponding SIP-HS. In oter words, each SIP-NMS is independent. SIP-NMSs can detects others' existence by the advertisement on the local link. When a new SIP-NMS joins this mobile network, other SIP-NMSs MUST use the SUBSCRIBE and NOTIFY methods for the negotiation with C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 7] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 the newly-joined SIP-NMS, and vice versa. After the negotiation, each SIP-NMS can select other SIP-NMS as the egress path using the REFER method. Once a certain SIP-NMS suffers the link failure, the failed SIP-NMS SHOULD redirect the registered SIP-MNs to other SIP-NMSs. o (n,n): Multiple E-faces, Multiple SIP-NMSs Tne (n,n) case means a mobile network has more than one SIP-NMS and each SIP-NMS has more than one E-face. In Multihomed SIP- NEMO, the (n,n) case is considered as the combination of (n,1) and (1,n). When a SIP-MN is attached to a mobile network of (n,n), it selects a SIP-NMS arbitrarily as the default SIP-NMS. The default SIP-NMS has two tasks. First, the default SIP-NMS SHOULD help the SIP-MN recover its global reachability by sending a REGISTER request to the SIP-MN's SIP server as described in [4]. Second, the default SIP-NMS SHOULD help the SIP-MN determine one of SIP-NMSs as the (1,n) case and one of E-faces as the (n,1) case. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 8] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 3. Operation Since Multihomed SIP-NEMO inherits SIP-NEMO, the basic operations, such as registration and header translation, is the same as defined in [4]. This section would focus on the invitation of each case. 3.1. (n,1): Multiple E-faces, Single SIP-NMS In the (1,n) case, Multihomed SIP-NEMO SHOULD determine an E-face when a session is being established. In this case, Multihomed SIP- NEMO assumes that the SIP-NMS has a permanent and unique URI address, which is got from the corresponding SIP-HS after the registration. Each E-face of a SIP-NMS can get contact addresses from the visited subnet. All information about each E-face, e.g., contact address or workload, is recorded in the Egress List defined in Section 2.1. Figure 2 depicts the invitation of (n,1). When a SIP-MN wants to invite a SIP-CN, the SIP-MN sends a INVITE request to the SIP-CN via the SIP-NMS. After the header translation, the SIP-NMS selects one of E-faces by looking up the Egress List and then sends the INVITE request to the SIP-CN. SIP-MN SIP-NMS SIP-CN | | | | INVITE | | |--------------->| | | +-----------+ | | |Egress List| | | +-----------+ | | | INVITE | | |--------------->| | | 180 RINGING | | |<---------------| | 180 RINGING | | |<---------------| | | | 200 OK | | |<---------------| | 200 OK | | |<---------------| | | | | | DATA | DATA | |<==============>|<==============>| | | | Figure 2: Invitation of (n,1) On the other hand, if a SIP-CN wants to invite a SIP-MN, the SIP-CN C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 9] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 sends an INVITE request to the SIP-MN's SIP server and then the SIP server redirects the INVITE request to the SIP-NMS's SIP-HS due to the header translation. Since the SIP-NMS has multiple contact addresses, its SIP-HS has several entries mapping to this SIP-NMS in the Binding List. The SIP-HS SHOULD selects a path according to the Priority field and then forward the INVITE request to the SIP-NMS via the selected path. Finally, the SIP-NMS SHOULD create an new entries in its Session List and forward the INVITE request to the SIP-MN as described in [4]. 3.2. (1,n): Single E-face, Multiple SIP-NMSs In the (n,1) case, Multihomed SIP-NEMO SHOULD determine a SIP-NMS when a session is being established. Multihomed SIP-NEMO assumes that a SIP-NMS SHOULD advertise itself periodically after it joins a mobile network. Each SIP-NMS can detect other SIP-NMSs inside the same mobile network by receiving the advertisements. Figure 3 depicts the negotiation between two SIP-NMS. When SIP-NMS 2 joins a mobile network, it advertises itself. When SIP-NMS 1 receives the advertisement of SIP-NMS 2, SIP-NMS 1 sends a SUBSCRIBE request to SIP-NMS 2 to synchronize the Egress List of SIP-NMS 2. Once SIP-NMS 2 accepts the request of SIP-NMS 1, SIP-NMS 2 responses a NOTIFY message which embeds its Egress List to SIP-NMS 1. Hereafter, if the Egress List of SIP-NMS 2 has some changes, e.g., a link failure, SIP- NMS 2 SHOULD inform SIP-NMS 1 about the changes by sending another NOTIFY message. SIP-NMS 2 can subscribe SIP-NMS 1 using the same operation as depicted in Figure 3. After the negotiation, SIP-NMS 1 and SIP-NMS 2 are synchronized to share the load of a mobile network. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 10] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 SIP-NMS 1 SIP-NMS 2 | | | Advertisement | |<--------------------------------| | | | SUBSCRIBE | |-------------------------------->| | 202 ACCEPTED | |<--------------------------------| | | | NOTIFY | |<--------------------------------| | 200 OK | |-------------------------------->| | | Event | |<----- | NOTIFY | |<--------------------------------| | 200 OK | |-------------------------------->| | | Figure 3: Synchronization between two SIP-NMSs We supposes that a SIP-MN is registered to SIP-NMS 1. When the SIP-MN wants to invite a SIP-CN, the SIP-MN sends a INVITE request to the SIP-CN via SIP-NMS 1. After looking up the Egress List, if SIP- NMS 1 determines that it can provide service, the invitation is similar in Figure 2. If SIP-NMS 1 determines that SIP-NMS 2 can provide better service, the invitation is depicted in Figure 4. SIP- NMS 1 sends a REFER request to SIP-NMS in order to ask SIP-NMS 2 to provide service for the SIP-MN. If SIP-NMS 2 accepts the request, SIP-NMS 2 responses a NOTIFY message which embeds some information of the redirection to SIP-NMS 1. Once SIP-NMS 1 receives the NOTIFY message from SIP-NMS 2, SIP-NMS 1 informs the SIP-MN about the redirection. At the same time, SIP-NMS 2 starts to send a INVITE request to the SIP-CN for the SIP-MN. When the SIP-CN accepts the invitation of the SIP-MN, SIP-NMS 2 would inform SIP-NMS 1 using a NOTIFY message. Next, SIP-NMS 1 would terminate the session with the SIP-MN. The SIP-MN would re-register to SIP-NMS 2 and establish the session to the SIP-CN. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 11] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 SIP-MN SIP-NMS 1 SIP-NMS 2 SIP-CN | | | | | INVITE | | | |--------------->| | | | +-----------+ | | | |Egress List| | | | +-----------+ | | | 100 TRYING | | | |<---------------| | | | | REFER | | | |--------------->| | | | 202 ACCEPTED | | | |<---------------| | | | NOTIFY | | | |<---------------| | | | 200 OK | | | |--------------->| | |380 ALTERNATIVE | | | | SERVICE | | INVITE | |<---------------| |--------------->| | ACK | | 180 RINGING | |--------------->| |<---------------| | | | 200 OK | | | |<---------------| | | NOTIFY | | | |<---------------| | | | 200 OK | | | |--------------->| | | BYE | | | |<---------------| | | | 200 OK | | | |--------------->| | | | | REGISTER | | |-------------------------------->| | | | 200 OK | | |<--------------------------------| | | | | | | | DATA | DATA | |<===============================>|<==============>| | | | | Figure 4: Invitation of (1,n) On the other hand, if a SIP-CN wants to invite a SIP-MN, the SIP-CN sends an INVITE request to the SIP-MN's SIP server. Then, due to the header translation, the SIP server SHOULD redirect the INVITE request to the corresponding SIP-HS which is responsible for managing the SIP-NMS registered latest by SIP-MN. Finally, the INVITE request is C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 12] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 forwarded to the current location of the SIP-NMS. 3.3. (n,n): Multiple E-faces, Multiple SIP-NMSs In the (n,n) case, Multihomed SIP-NEMO SHOULD determine a SIP-NMS and an E-face of the selected SIP-NMS when a session is being established. In this case, Multihomed SIP-NEMO assumes that SIP-NNs MAY receives several advertisements from different SIP-NMSs. SIP-MNs can select one of SIP-NMS as their default SIP-NMS arbitrarily. Once a SIP-MN determines its default SIP-NMS, it would register to the selected SIP-NMS using the registration process defined in [4]. The invitation of (n,n) is composed of (1,n) and (n,1). When a SIP- NMS regarding SIP-NMS 1 as the default SIP-NMS wants to invite a SIP-CN, the SIP-MN sends a INVITE request to the SIP-CN via SIP-NMS 1. After looking up the Egress List, if SIP-NMS 1 determines that it can provide service, the invitation is similar in Figure 2. If SIP- NMS 1 determines that SIP-NMS 2 can provide better service, the invitation is depicted in Figure 5. SIP-NMS 1 sends a REFER request to SIP-NMS in order to ask SIP-NMS 2 to provide service for the SIP-MN. If SIP-NMS 2 accepts the request, SIP-NMS 2 looks up its Egress List again for selecting one of its E-faces. Then, SIP-NMS 2 sends the INVITE request using the select E-face to the SIP-CN. Finally, the SIP-MN is redirected from SIP-NMS 1 to SIP-NMS 2. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 13] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 SIP-MN SIP-NMS 1 SIP-NMS 2 SIP-CN | | | | | Advertisement | | | |<---------------| Advertisement | | |<--------------------------------| | | REGISTER | | | |--------------->| | | | | | | | INVITE | | | |--------------->| | | | +-----------+ | | | |Egress List| | | | +-----------+ | | | | REFER | | | |--------------->| | | | NOTIFY | | | |<---------------| | |380 ALTERNATIVE | | | | SERVICE | +-----------+ | |<---------------| |Egress List| | | | +-----------+ | | | | INVITE | | | |--------------->| | | NOTIFY | | | |<---------------| | | BYE | | | |<---------------| | | | | REGISTER | | |-------------------------------->| | | | | | | | DATA | DATA | |<===============================>|<==============>| | | | | Figure 5: Invitation of (n,n) On the other hand, when a SIP-CN wants to invite a SIP-MN, the invitation process is also the combination of the (n,1) and (1,n) cases. The SIP-CN sends an INVITE request to the SIP-MN's SIP server. The SIP server redirects the INVITE request to the coresponding SIP-HS which takes charge of the SIP-NMS registered latest by the SIP-MN. Then, the SIP-HS selects a path according the Priority field in the Binding List to forward the INVITE request to the SIP-NMS. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 14] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 4. Multihoming Issues Based on [3], this section analyzes Multihomed SIP-NEMO from the following perspectives. 4.1. Path Selection Path selection is the key issue of multihoming. Multihomed SIP-NEMO classifiies the possible multihoming configurations of a mobile network and provides a path management mechanism based on SIP. First, Multihomed SIP-NEMO defines an Egress List for recording the path information in the (n,1) case. Next, Multihomed SIP-NEMO employs the SUBSCRIBE and NOTIFY methods for the negotiation between two SIP-NMSs and the REFER method for the redirection from one SIP- NMS to another one in the (1,n) case. Finally, Multihomed SIP-NEMO shows how to combine (n,1) and (1,n) in the (n,n) case. Therefore, Multihomed SIP-NEMO can apply to all possible multihoming configurations. It is important to note that Multihomed SIP-NEMO do not specify any selection policy. Multihomed SIP-NEMO only proposes the necessary fields in an Egress List, e.g., Load and Status. Multihomed SIP-NEMO do not propose how to calculate the best path. The optimized selection policy is beyond the scope of this document. 4.2. Fault Tolerance If a link failure happens, Multihomed SIP-NEMO can redirect sessions using the failed path to other alternative paths. The re-invitation is the same as described in Section 3. When a SIP-NMS detects that one of its E-face is failed, it looks up its Egress List for finding out alternative paths. The alternative paths MAY be its other E-faces or E-faces of other SIP-NMSs in the same mobile network. As described in Section 3.1, the switch between two E-faces is controlled by the corresponding SIP-NMS. On the other hands, the switch between two SIP-NMS depends on the REFER method as described in Section 3.2. 4.3. Load Balance/Sharing Multihomed SIP-NEMO designs a field "Load" in the Egress List for the load balance/sharing concern. However, Multihomed SIP-NEMO do not proposed any load balance policy. For example, if a single E-face gets several contact addresses, the Egress List MUST exist several entries mapping to the same E-face. In this situation, distribuing load to each entry is different from distributing load to each E-face. Thus, a well-defined load balance mechanism is RECOMMENDED to handle this kinds of situation. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 15] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 4.4. Re-homing When a link failure is detected, except the re-invitation, a re- homing event happens. In the (n,1) case, the SIP-NMS SHOULD inform its SIP-HS about the failed link. In the (1,n) case, the newly- registered SIP-NMS would inform the SIP-MN's SIP server to update the SIP-MN's current location. These re-registration process is similar and defined in [4]. Thus, a new session is being established to this SIP-MN without passing through the failed path. 4.5. Synchronization In Multihomed SIP-NEMO, SIP-NMS synchorization is achieved by the SUBSCRIBE and NOTIFY methods. The goal of synchronization is to exchange the Egress List of each other. Once the Egress List is synchronized, SIP-NMSs inside the same mobile network can selects the paths maintained by other SIP-NMSs. 4.6. Nesting Multihomed SIP-NEMO is proposed to hanle the multihoming configuration in SIP-NEMO. Although Multihomed SIP-NEMO can let a mobile network become nested, the routing path inside the mobile network MAY NOT keep optimal as the increase of the nesting level and the multihoming complexity. Multihomed SIP-NEMO only achieves route optimization (RO) between the mobile network and the Internet. However, the RO inside the nested and multihomed mobile network MAY go beyond the scope of this document. We do not discuss this issue in this document. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 16] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 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 & C.M. Huang Expires April 18, 2007 [Page 17] Internet-Draft MULTIHOMING IN SIP-NEMO October 2006 6. IANA Considerations This is an informational document and does not require any IANA action. 7. 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., "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-06 (work in progress), June 2006. [4] Lee, C., "SIP-based Network Mobility (SIP-NEMO) Route Optimization", draft-ming-nemo-sipnemo-00 (work in progress), October 2005. [5] Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-05 (work in progress), October 2005. [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-05 (work in progress), March 2006. [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. C.H. Lee & C.M. Huang Expires April 18, 2007 [Page 18] Internet-Draft MULTIHOMING IN SIP-NEMO 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 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 & C.M. Huang Expires April 18, 2007 [Page 19] Internet-Draft MULTIHOMING IN SIP-NEMO 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 & C.M. Huang Expires April 18, 2007 [Page 20]