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]