IETF Next Steps in Signaling                                 S. Lee, Ed.
Internet-Draft                                               SAMSUNG AIT
Expires: January 17, 2005                                       S. Jeong
                                                                    HUFS
                                                           H. Tschofenig
                                                              Siemens AG
                                                                   X. Fu
                                                     Univ. of Goettingen
                                                               J. Manner
                                                       Univ. of Helsinki
                                                           July 19, 2004


    Applicability Statement of NSIS Protocols in Mobile Environments
           draft-manyfolks-signaling-protocol-mobility-01.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 January 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   Mobility of an IP-based node affects routing paths, and as a result,
   can have a dramatic effect on protocol operation and state



Lee, et al.             Expires January 17, 2005                [Page 1]


Internet-Draft          Applicability Statement                July 2004


   management.  This draft discusses the effects mobility can cause to
   the NSIS protocols, and how the protocols operate in different
   scenarios, and together with mobility management protocols.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Problem Statement and General Considerations . . . . . . . . .  8
     3.1   Problem statement  . . . . . . . . . . . . . . . . . . . .  8
     3.2   General Considerations . . . . . . . . . . . . . . . . . . 10
   4.  Basic operations for mobility support  . . . . . . . . . . . . 11
     4.1   Generic Route Changes and Mobility . . . . . . . . . . . . 11
     4.2   CRN Discovery  . . . . . . . . . . . . . . . . . . . . . . 14
       4.2.1   Possible approaches for CRN discovery  . . . . . . . . 14
       4.2.2   The identifiers for CRN discovery  . . . . . . . . . . 15
       4.2.3   The procedure of the CRN discovery . . . . . . . . . . 17
     4.3   Path update  . . . . . . . . . . . . . . . . . . . . . . . 18
       4.3.1   State setup and update . . . . . . . . . . . . . . . . 18
       4.3.2   State Teardown . . . . . . . . . . . . . . . . . . . . 20
   5.  Mobility-Related Issues with NSIS Protocols  . . . . . . . . . 22
     5.1   Specific Issues with NTLP  . . . . . . . . . . . . . . . . 22
     5.2   Specific Issues with QoS-NSLP  . . . . . . . . . . . . . . 23
     5.3   Specific Issues with NAT/FW NSLP . . . . . . . . . . . . . 24
     5.4   Common issues related to NTLP and NSLP . . . . . . . . . . 25
   6.  Applicability Statement  . . . . . . . . . . . . . . . . . . . 26
     6.1   Support for Macro Mobility-based scenarios . . . . . . . . 26
       6.1.1   Implications to Mobile IP-related scenarios  . . . . . 27
         6.1.1.1   Mobile IPv4-specific issues  . . . . . . . . . . . 28
         6.1.1.2   Mobile IPv6-specific issues  . . . . . . . . . . . 30
     6.2   Multihoming/make-before-break scenarios  . . . . . . . . . 32
       6.2.1   Overview . . . . . . . . . . . . . . . . . . . . . . . 32
       6.2.2   NTLP/NSLP support  . . . . . . . . . . . . . . . . . . 33
     6.3   QoS Performance Considerations in mobility scenarios . . . 33
     6.4   Use cases of Identifiers . . . . . . . . . . . . . . . . . 35
     6.5   Peer Failure Scenarios . . . . . . . . . . . . . . . . . . 36
     6.6   Guidelines for design of NTLP and NSLPs  . . . . . . . . . 37
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 38
     7.1   MN as data sender  . . . . . . . . . . . . . . . . . . . . 38
       7.1.1   MN is authorizing entity . . . . . . . . . . . . . . . 38
       7.1.2   CN is authorizing entity . . . . . . . . . . . . . . . 40
         7.1.2.1   CN asks MN to trigger action (on behalf of the
                   CN)  . . . . . . . . . . . . . . . . . . . . . . . 41
         7.1.2.2   CN uses installed state to route message
                   backwards  . . . . . . . . . . . . . . . . . . . . 42
         7.1.2.3   MN and CN are authorized . . . . . . . . . . . . . 43
       7.1.3   CN as data sender  . . . . . . . . . . . . . . . . . . 43
         7.1.3.1   CN is authorizing entity . . . . . . . . . . . . . 43



Lee, et al.             Expires January 17, 2005                [Page 2]


Internet-Draft          Applicability Statement                July 2004


         7.1.3.2   MN is authorizing entity . . . . . . . . . . . . . 45
       7.1.4   Multi-homing Scenarios . . . . . . . . . . . . . . . . 45
         7.1.4.1   MN as data sender  . . . . . . . . . . . . . . . . 45
         7.1.4.2   CN as data sender  . . . . . . . . . . . . . . . . 46
       7.1.5   Proxy Scenario . . . . . . . . . . . . . . . . . . . . 47
       7.1.6   Conclusion . . . . . . . . . . . . . . . . . . . . . . 47
   8.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 49
     8.1   Interaction with Other Mobility-Related Protocols  . . . . 49
       8.1.1   Interaction with Seamoby Protocols . . . . . . . . . . 49
       8.1.2   Interaction with Local Mobility Management
               Protocols  . . . . . . . . . . . . . . . . . . . . . . 49
       8.1.3   State Establishment in Network Mobility Scenarios  . . 50
     8.2   Additional Issues on CRN discovery and Path Update . . . . 50
     8.3   Support for the Ping-Pong Type of Movement . . . . . . . . 50
     8.4   When both end-hosts are mobile . . . . . . . . . . . . . . 50
     8.5   Bi-directional State Establishment . . . . . . . . . . . . 51
     8.6   Priority Reservation . . . . . . . . . . . . . . . . . . . 51
     8.7   Aggregation of End-to-End Flows in Mobile Environments . . 51
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 53
   9.2   Informative References . . . . . . . . . . . . . . . . . . . 53
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 54
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
   B.  Anticipated Handover . . . . . . . . . . . . . . . . . . . . . 57
       Intellectual Property and Copyright Statements . . . . . . . . 59


























Lee, et al.             Expires January 17, 2005                [Page 3]


Internet-Draft          Applicability Statement                July 2004


1.  Introduction

   The mobility of IP-based nodes incurs route change, usually at the
   edge of the network.  Route change may also be caused by reasons
   other than mobility, such as routing protocol adaptation in response
   to varying network conditions (load sharing, load balancing, etc), or
   host multi-homing.  Normal IP mobility (i.e., macro-mobility) also
   involves the change of mobile node IP addresses.  Since IP addresses
   are usually part of flow identifiers, the change of IP addresses
   implies the change of flow identifier.  Local mobility usually does
   not cause the change of the global IP addresses, but affects the
   routing paths within the local access network.

   The goals of this draft are to present the effects of mobility on the
   NSIS Transport Layer Protocol (NTLP) and on the NSIS Signaling Layer
   Protocols (NSLP).  The NTLP is an application independent protocol to
   transport service-related information between nodes in a network.
   Each specific service has its own NSLP protocol.This draft also
   discusses how the NSIS protocols should work in various mobility
   scenarios.

   The discussion is divided into two parts.  The first part discusses
   the operation of the NSIS protocols in very basic mobility scenarios
   (e.g., macro-mobility management protocols such as Mobile IPv4 and
   Mobile IPv6), including support for multi-homing.  The second part
   takes the discussion to more complex scenarios and issues on
   interworking with various mobility-related protocols such as Seamoby
   and local mobility management protocols.























Lee, et al.             Expires January 17, 2005                [Page 4]


Internet-Draft          Applicability Statement                July 2004


2.  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 [1].

   The terminology in this draft is based on [2] and [3].  In addition,
   the following terms are used.

   O  Downstream

      The flow from a data sender towards the destination.

   O  Upstream

      The flow from a data destination towards the sender.

   O  Crossover Node (CRN)

      A Crossover Node is a node that for a given function is a merging
      point of two or more separate sets of state information.  The CRN
      may not necessarily be a physical route splitting point.  There
      can be different types of logical (but not necessarily physical)
      CRNs according to signaling states, flow direction, mobility
      management, and normal routing (not caused by mobility):

         From the perspective of NSIS states (i.e., NSLP and NTLP
         states), the types of CRN are basically classified as follows.

            NSLP CRN, from the NSLP's point of view, is a signaling
            application-aware node in the network where the
            correspondent signaling flows begin to merge or split after
            route changes and mobility.  The NSLP CRN may be different
            according to the types of NSLP.

            NTLP CRN, from the NTLP's point of view, is a network node
            where more than one NTLP states begin to merge or split
            after route changes and mobility.

            NSIS CRN is either an NTLP CRN or an NSLP CRN.  Note that
            although the types of CRN differ according to the state
            information, the CRN required for QoS-NSLP operation is the
            NSLP CRN which has the corresponding signaling application
            information to perform the path update.

         There are some differences between route change and mobility in
         forming CRN according to the direction of signaling flows
         followed by data flows



Lee, et al.             Expires January 17, 2005                [Page 5]


Internet-Draft          Applicability Statement                July 2004



            In the mobility scenarios, there are two different types of
            merging point in the network according to the direction of
            signaling flows followed by data flows as shown in Figure 2
            of Section 4.1, where we assume that the MN is a data
            sender.

               Upstream CRN, after a handover, is the node closest to
               the data receiver from which the state information
               towards the data sender begins to diverge.

               Downstream CRN, after a handover, is the node closest to
               the data sender from which the state information towards
               the data receiver begins to converge.

               In this case, the DCRN and the UCRN may be different due
               to the asymmetric characteristics of routing although the
               CN is the same.

            In the route changes, the path change of signaling flows
            results in forming a chain of two CRNs regardless of the
            direction of signaling flows followed by data flows as shown
            in figure 1 of Section 4.1, which is referred to as a
            divergence-convergence pair:

               Upstream CRN, after a route changes, is the node at which
               the state information towards the data sender begins to
               diverge, or to converge.  As a result, a
               (divergent-convergent) UCRN pair will be formed.

               Downstream CRN, after a route changes, is the node at
               which the state information towards the data receiver
               begins to diverge, or to converge.  As a result, a
               (divergent-convergent) DCRN pair will be formed.

         From mobility management point of view, mobility CRN is the
         node where the old and new paths (physically) merge.  Note that
         in general, mobility CRN may be different from the NSLP CRN or
         NTLP CRN.

         Routing CRN is the node where using normal routing, the old and
         new paths (rather physically) merge.  Depending on the location
         of nodes, the routing CRN may not be equal to the NSLP CRN or
         NTLP CRN.

   O  Path Update and Local Repair

      Path Update is the procedure for the re-establishment of NSIS



Lee, et al.             Expires January 17, 2005                [Page 6]


Internet-Draft          Applicability Statement                July 2004


      state on the new path, the teardown of NSIS state on the old path,
      and the update of NSIS state on the common path due to the
      mobility.  This is used to improve mobility handling for the
      affected flows.

         Upstream Path Update: Path Update for the upstream signaling
         flow which is initiated by an upstream signaling initiator.  If
         the MN is a sender, the Path Update is initiated by an NI on
         the common path (e.g., a CN, an HA, or an MAP).

         Downstream Path Update: Path Update for the downstream
         signaling flow which is triggered by a downstream signaling
         initiator.  If the MN is a sender, the Path Update is triggered
         by an NI on the new path (e.g., an MN, a mobile agent, or an
         AR).

      In case of route changes, the update of NSIS state on the common
      path is not required and it is called Local Repair which localizes
      the NSIS signaling.  Especially, in mobility scenarios, if the
      NSIS signaling interacts with localized mobility management
      protocols (e.g., HMIPv6), the Path Update can be localized within
      the access network.

   O  Dead Peer Discovery (DPD)

      The procedure for finding a dead NSIS peer due to a link/node
      failure and due to an MN moving away.

   O  Downlink

      The direction from the CN towards the MN.

   O  Uplink

      The direction from the MN towards the CN.
















Lee, et al.             Expires January 17, 2005                [Page 7]


Internet-Draft          Applicability Statement                July 2004


3.  Problem Statement and General Considerations

3.1  Problem statement

   IP mobility in its simplest form only includes route changes.  Still,
   the various protocols that seek to support the mobility of end hosts
   may use very special techniques to reach their goals.  Most of these
   techniques are common IP mechanisms that can also be found in fixed
   networks, and therefore, are not by themselves particular.  The
   operation of NSIS signaling protocols are affected by the following
   issues:

   O  Change of route and possibly change of the MN IP address

      Topology changes entail the change of routes for data packets sent
      to or from the MN and may lead to the change of host IP addresses.

   O  Latency of route changes

      The change of route and IP addresses is typically much faster and
      frequent than traditional route changes, for example, those due to
      failure, adding or removal of nodes/links.

   O  Explicit routes

      Signaling protocols usually expect the data traffic to follow the
      same path as the signaling traffic, but the data traffic sometimes
      traverses the path different from the path of signaling traffic
      due to the adaptation of routing protocol according to varying
      network conditions such as load balancing, load sharing and
      mobility.  For example,Mobile IP adds the possibility to use
      routing headers to define explicit routes, which diverts the
      traffic from an expected path.

   O  IP-in-IP encapsulation

      Mobility protocols may use IP-in-IP encapsulation on the segmnts
      of the end-to-end path for routing traffic from the CN to the MN,
      and vice versa.  Encapsulation harms any attempt to identify and
      filter.  Moreover, encapsulation may lead to changes in the
      routing paths, since the sender and destination IP address differ
      from the values in the original user data packet.  The same
      considerations apply if the signaling packets are encapsulated,
      too.

   O  Ping-pong type handover

      NSIS needs to remove states quickly along the old path in order to



Lee, et al.             Expires January 17, 2005                [Page 8]


Internet-Draft          Applicability Statement                July 2004


      mitigate the waste of resources.  However, in a ping-pong type
      handover, the MN returns to the previous AR after staying with the
      new AR only for a short while, the prompt removal of state along
      the old path causes the state to be re-established soon again and
      it adds overhead.

   O  Upstream Path Update vs.  Downstream Path Update

      Since the upstream and downstream paths may not be equal, the
      upstream and downstream CRNs may not be equal, either.  In this
      case, Path Update needs to be handled independently for upstream
      and downstream flows, including, e.g., the discovery of upstream
      and downstream CRNs.

   O  State identification problem

      A mobility event may cause the address of flow endpoints to
      change, and in this case it is desirable that signaling
      application state is independent of the underlying flow to keep
      the state from being re-installed completely.  Therefore, the
      session and flow identifiers need to be created separately, and
      this makes it possible to correlate the session identifier with
      the signaling application about the different flows with the same
      network control state.

   O  Double reservation Problem

      Since the state on the old path (and the common path) still
      remains as it is after re-establishing the state along the new
      path due to mobility (or route change), the double reservation
      problem occurs.  Although the existing state on the old path can
      be torn down by the timeout of soft state, the refresh timer value
      in the core or wired network is quite long (e.g., 30 seconds in
      QoS-NSLP).  As a result, in case of QoS-NSLP, the double
      reservation problem leads to the waste of resources and call
      blocking.

   O  End-to-end signaling Problem

      The mobility may change the flow identifier, and the change of
      flow identifier requires state update along the entire path to
      reflect the physical location of the MN, resulting in the
      end-to-end signaling.  This also incurs a long state setup delay
      and signaling overhead which affect network performance.
      Ultimately, the long state setup delay may particularly give rise
      to the service blackout or degradation for multimedia application
      in the mobility environment.




Lee, et al.             Expires January 17, 2005                [Page 9]


Internet-Draft          Applicability Statement                July 2004


   In summary, NSIS signaling needs to work with basic mobility which
   can be considered as an extension to the general route (topological)
   change, to handle the change of IP address, and to support mobile IP
   tunnels and multi-homing.  In this case, Path Update should be
   localized, and handled independently for upstream and downstream
   flows.

3.2  General Considerations

   At the first step, this draft discusses NSIS state establishment
   (e.g., QoS-NSLP, NAT/FW, etc) in the macromobility-based scenarios
   (e.g., basic Mobile IP (v4 and v6) handovers) and the interaction
   with the specific micromobility protocols leading to performance
   optimization of NSIS signaling would be discussed further in the next
   version of the draft.

   Our assumptions in this document and the general considerations are:

   O  Session-ID is used to index state

      Even if an MN has a permanent IP address (its home address), it
      cannot be used to index state in the network since the home
      address may not easily be visible to interior nodes.  Other types
      of mobile nodes (e.g., using SIP or other application layer
      techniques) may not have permanent addresses at all.  After a
      movement it obtains a new CoA, which is the basis for routing its
      data.  If signaling-associated state is indexed based on some
      temporary data plane information, such as CoA, the state indexed
      by previous CoAs might be inaccessible for the signaling after
      most handover procedures.

   O  Routing may be asymmetric

      IP packets arriving to and leaving the MN may be routed
      differently.  This may be due to the basic triangular routing of
      MIPv4, due to the operation of an LMM protocol, or due to
      asymmetric routing caused by the basic operation of the IP routing
      protocols themselves.

   O  The CN is not a mobile device

      We may later add text to consider a mobile CN, too.









Lee, et al.             Expires January 17, 2005               [Page 10]


Internet-Draft          Applicability Statement                July 2004


4.  Basic operations for mobility support

   In this section, we discuss the basic operations of NSIS signaling
   needed after the route changes including the mobility.  The basic
   operations include how an appropriate CRN is discovered and how the
   Path Update is performed by the NSIS signaling according to the
   direction of data flows.  The procedure of CRN discovery (in Section
   4.2.3) can be applied in the same way as for both the generic route
   changes and mobility.  However, the Path Update for the generic route
   changes is different from that for mobility.  This draft mainly
   discusses the Path Update for the route changes caused by mobility.

4.1  Generic Route Changes and Mobility

   The generic route changes occurs due to load sharing, load balancing,
   an link or node failure, but the mobility is associated with the
   change of the network attachment point.  These cause divergence (or
   convergence) between the old path along which state has already been
   installed and the new path along which data forwarding will actually
   happen.

   Although the mobility may be considered similar to the route changes,
   the main difference is that the Message Routing Information (MRI:
   e.g., flow identifier) may not change after the route change while
   the mobility may cause the change of MRI by having a new network
   attachment point.  Since the session should remain the same after any
   mobility event, the MRI should not be used to identify the session of
   any signaling application [4].

   The route changes brings on the change of signaling topology and it
   results in difference according to the types of route change (e.g.,
   the route changes or mobility).  The route changes generally forms
   two common paths, an old path, and a new path, where the old path and
   the new path begin to diverge from one common path and afterward to
   converge to another common path for each direction of signaling flows
   (e.g., downstream or upstream flows) as shown in Figure 1.


                               Old path
                       +---+      +---+
                 ^ --->|NE | ...  |NE | ------V
     common path ^     +---+      +---+       V   common path
    +--+       +----+                      +----+          +--+
    |S |-----> |DCRN|                      |DCRN| -------> |R |
    |  |       |    |                      |    |          |  |
    +--+       +----+       New path       +----+          +--+
                 V     +---+      +---+       ^
                 V --->|NE | ...  |NAR| ------^



Lee, et al.             Expires January 17, 2005               [Page 11]


Internet-Draft          Applicability Statement                July 2004


                       +---+      +---+


      =======(downstream signaling followed by data flows) ========>

   (a) The topology for downstream NSIS signaling flow after the
      route changes

                            Old path
                       +---+      +---+
                 v <---|NE | ...  |NE | ----- ^
     common path v     +---+      +---+       ^  common path
    +--+       +----+                      +----+          +--+
    |S |<----- |UCRN|                      |UCRN| <------- |R |
    |  |       |    |                      |    |          |  |
    +--+       +----+       New path       +----+          +--+
                 ^     +---+      +---+       v
                 ^ <---|NE | ...  |NAR| ----- v
                       +---+      +---+


      <=====(upstream signaling followed by data flows) ========

   (b) The topology for upstream NSIS signaling flow after the
      route changes

   Figure.1 The topology for NSIS signaling in case of the route changes

   However, the mobility results in creating a common path, an old path,
   and a new path, and the old and new paths only converge or diverge
   according to the direction of each signaling flow as shown in Figure
   2.


                                Old path
              +--+        +---+
    original  |MN|------> |OAR| -------------V
    address   +--+        +---+              V   common path
               |                          +----+          +--+
               |                          |DCRN| -------> |CN|
               |                          |    |    >>>>> |  |
               v                New path  +----+   ^      +--+
              +--+        +---+              ^     ^
     New CoA  |MN|------> |NAR|--------------^     ^
              +--+        +---+                    ^
                  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
                        (Binding process)




Lee, et al.             Expires January 17, 2005               [Page 12]


Internet-Draft          Applicability Statement                July 2004


     ====(downstream signaling followed by data flows) ======>

   (a) The topology for downstream NSIS signaling flow due to
      mobility.


                                Old path
              +--+        +---+
    original  |MN|<------ |OAR| -------------^
    address   +--+        +---+              ^   common path
               |                          +----+          +--+
               |                          |UCRN| <------- |CN|
               |                          |    |    >>>>> |  |
               v                New path  +----+   ^      +--+
              +--+        +---+              v     ^
     New CoA  |MN|<------ |NAR|--------------v     ^
              +--+        +---+                    ^
                  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
                        (Binding process)

     <=====(upstream signaling followed by data flows) =====

   (b) The topology for upstream NSIS signaling flow due to
      mobility.

   Figure.2 The topology for NSIS signaling caused by mobility.

            Figure 2: Signaling topology by mobility event.

   These topological changes caused by mobility make the signaling state
   established on the old path useless and therefore removed (in the
   end).  In addition, the existing NSIS state should also be
   re-established along the new path and to be updated along the common
   path.  Note that to minimize the impact on seamless service and
   improve signaling scalability, NSIS signaling should be localized
   when route changes (including mobility) occur; the localized
   signaling procedure is referred to as Local Repair in this draft (in
   case of the interaction with localized mobility protocols: see the
   terminology section).  As an example, in mobility scenarios, although
   NSIS signaling messages are initiated by an MN or CN and sent to the
   opposite terminating point of the path, the path in the wireless
   access network usually changes only partially.  Therefore, the NSLP/
   NTLP needs to limit the scope of signaling information to a local
   section of the signaling path.  One of the most appropriate nodes to
   do the Local Repair (or Path Update) can be the Crossover node (CRN)
   where the old and new session paths meet.

   The NTLP module (of a node experiencing a topological change) should



Lee, et al.             Expires January 17, 2005               [Page 13]


Internet-Draft          Applicability Statement                July 2004


   detect it through the various mechanisms described in [4] at
   transport level and triggers the NSLP operation over itself, and then
   the NSLP should initiate necessary NSIS state establishment (i.e.,
   QoS re-establishment) along the new path and the update or removal of
   associated states, at the signaling application level.  Note that in
   the case of QoS-NSLP, state re-establishment due to the route changes
   does not need any state update along the entire signaling path since
   the flow identifier does not change (in other words, the IP address
   of endpoint does not change).

4.2  CRN Discovery

4.2.1  Possible approaches for CRN discovery

   The approaches for CRN discovery can be divided into two classes
   according to which layer is responsible for the discovery of CRN, and
   whether the discovery is coupled with the transport of signaling
   application messages.

   From the NSIS protocol stack point of view, the CRN can be discovered
   at both NTLP and NSLP layers.  First, the CRN discovery at the NSLP
   layer is possible using the information contained in NSLP signaling
   messages sent from the signaling initiator.  For example, NSLP can
   realize that it is a CRN by comparing the Source Identification
   Information (SII) contained in the incoming signaling message to the
   one stored previously in the node.  However, since NTLP is
   responsible for detecting the path change of data (or signaling) flow
   (and the route changes may easily be detected at the NTLP level
   rather than at the NSLP), CRN discovery can be considered as an
   extension to the peer discovery at the NTLP level (e.g., using GIMPS
   query-response [2]).  In general, the GIMPS message has message
   routing state information such as flow/session/signaling application
   identifier, so signaling application can be identified at the NTLP
   level.  For example, in the connection mode of NTLP, when NTLP
   establishes a messaging association between two adjacent peers, the
   NTLP peers exchange message routing state information through   GIMPS
   query and response messages.  Therefore, although the CRN can be
   discovered at the NTLP level, the discovered CRN could be actually
   NSLP-aware node which has an involved signaling application.

   There can also be two different approaches for CRN discovery
   according as whether the discovery is coupled with signaling message
   or not: the coupled approach and uncoupled approaches.  If the
   signaling to update NSIS state along a new path or the common path,
   after route changes or mobility, is done simultaneously with the CRN
   discovery procedure, it is called the coupled approach.  If the
   signaling to do Path Update is done after the CRN discovery is
   completed, it is called the uncoupled approach.  These approaches may



Lee, et al.             Expires January 17, 2005               [Page 14]


Internet-Draft          Applicability Statement                July 2004


   have some effect on security aspect.  Generally, the coupled approach
   would be preferred to the uncoupled approach to reduce the delay for
   signaling setup.  Note that CRN discovery and Path Update described
   in this draft are based on the coupled approach.

4.2.2  The identifiers for CRN discovery

   There are some basic identifiers which can be used for CRN discovery
   at the NTLP level: session identifier, flow identifier (MRI), and
   signaling application identifier (NSLP_ID) related to message routing
   state [2]), and NSLP branch identifier related to the direction of
   NSIS signaling branch.

   The session identifier in the GIMPS message is used to easily
   identify the involved session because it remains the same while the
   MRI may (or may not) change due to handover.  The MRI is used to
   specify the relationship between the address information and the
   state (e.g., QoS-NSLP state) re-establishment.  In other words, the
   change of MRI indicates topological changes and therefore it
   represents that the state along the common path should be updated
   after the CRN discovery.

   The signaling application identifier (NSLP_ID) is used to refer to
   the corresponding NSLP at GIMPS level, and in the context of CRN
   discovery it helps to discover an appropriate NSLP CRN using the
   GIMPS peer discovery message.

   The NSLP branch identifier as a virtual branch identifier can be used
   to establish or delete NSIS associations between peers and it can
   also be used as an identifier to determine the CRN at the GIMPS
   layer.  The NSLP branch identifier can consist of the location
   information of peer nodes with the correspondent NSLP ID by the
   procedure of GIMPS message association.  For instance, as shown in
   Figure 3, for the downstream case, NSLP1 of node A requires a
   messaging association for sending its messages towards node D after a
   route changes.  In this case, NSIS entity A creates an NSLP branch ID
   for NSLP 1 toward node D and increases the counter of NSLP branch ID
   to locally distinguish each virtual interface identifier between
   adjacent NSLP peers: the corresponding NSLP br.ID is 1-D-#2.  Note
   that the NSLP branch identifier can be included in the NSIS message,
   but it can also be considered as an implementation issue.  This
   identifier would be more useful when the merging point of the old
   path and a new path is not an NSLP CRN after the route change.


                                  Old path
                           +-----+     +-----+
                     ^---->|NSLP1| ... |NSLP1| ----V



Lee, et al.             Expires January 17, 2005               [Page 15]


Internet-Draft          Applicability Statement                July 2004


    common path      ^     +-----+     +-----+     V    common path
       +-----+    +-----+     C           K      +-----+    +-----+
   --->|NSLP1|--->|     |                        |     |--->|NSLP1|-->
       |NSLP2|    |NSLP2|                        |NSLP2|    |NSLP2|
       +-----+    +-----+      New path          +-----+    +-----+
         A        B  V    +-----+     +-----+     ^  M       N
                     V--->|NSLP1| ... |NSLP1| ----^
                          +-----+     +-----+
                              D           L

                        =======(Flow direction) ========>


   (a) NSIS signaling topology for downstream signaling flow after the
      route changes in the middle of the network

    +------------------+-------+-------+--------+------------+-------+
    |  Message Routing |Session| NSLP  |Upstream| Downstream | NSLP  |
    |    Information   |  ID   |  ID   |  Peer  |    Peer    |Br. ID |
    +------------------+-------+-------+--------+------------+-------+
    |   Method = Path  | 0xABCD| NSLP1 |   Z    | Pointer to | 1-D-#1|
    |Coupled; Flow ID =|       |       |        |   A-C      |       |
    |  {IP-#X, IP-#V,  |       |       |        | Pointer to | 1-D-#2|
    | protocol, ports} |       |       |        |   A-D      |       |
    |                  |       |       |        |            | 1-U-#1|
    |   Method = Path  |       |       |        |            |       |
    |Coupled; Flow ID =| 0x1234| NSLP2 |   Z    |   (null)   | 2-D-#1|
    |  {IP-#X, IP-#V,  |       |       |        |            |       |
    | protocol, ports} |       |       |        |            | 2-U-#1|
    +------------------+-------+-------+--------+------------+-------+

   (b) Routing state table at node A (NSLP CRN)

    +------------------+-------+-------+----------+----------+-------+
    |  Message Routing |Session| NSLP  |Upstream  |Downstream| NSLP  |
    |    Information   |  ID   |  ID   |  Peer    |   Peer   |Br. ID |
    +------------------+-------+-------+----------+----------+-------+
    |   Method = Path  | 0xABCD| NSLP1 |Pointer to|  (null)  | 1-U-#1|
    |Coupled; Flow ID =|       |       |  K-N     |          |       |
    |  {IP-#X, IP-#V,  |       |       |Pointer to|          | 1-U-#2|
    | protocol, ports} |       |       |  L-N     |          |       |
    |                  |       |       |          |          | 1-D-#1|
    |   Method = Path  |       |       |          |          |       |
    |Coupled; Flow ID =| 0x1234| NSLP2 |   M      |  (null)  | 2-U-#1|
    |  {IP-#X, IP-#V,  |       |       |          |          |       |
    | protocol, ports} |       |       |          |          | 2-D-#1|
    +------------------+-------+-------+----------+----------+-------+




Lee, et al.             Expires January 17, 2005               [Page 16]


Internet-Draft          Applicability Statement                July 2004


   (C) Routing state table at node N (NSLP CRN)

      Figure.3 Routing state table and NSLP branch ID

   Optionally, the mobility identifier as an object form can also be
   used for immediate CRN discovery in various mobility scenarios.  The
   mobility object can also be used for other purposes.  The more
   details are discussed further in Section 6.4.

4.2.3  The procedure of the CRN discovery

   In general, when a mobility event occurs, the CRN can be recognized
   by comparing the existing message routing information (e.g., the NSLP
   ID, the session identifier and MRI) and the NSLP branch ID with the
   message routing information and the NSLP branch ID (with different
   counter number) included in the NTLP peer discovery message initiated
   by an NI (e.g., an MN or a CN).  For example, if an NTLP message is
   routed to an NSIS peer node, the following information (shown in
   Figure 3  (b) and (c)) is checked:

   -  Whether the same NSLP ID exists,

   -  Whether the corresponding CRN is already discovered,

   -  Whether the same session identifier and MRI exist,

   -  Whether the NSLP branch identifier is changed: for example, as
      shown in Figure 3 (b), it for NSLP 1 changed to 1-D-#2 from
      1-D-#1,

   -  Optionally, check the mobility identifier, if any: for example,
      the Mobility object to know which message is sent due to the
      latest handover (see Section 6.4).

   The CRN discovery can be further divided into UCRN discovery and DCRN
   discovery according to which node is a signaling initiator (by
   upstream or downstream), or whether the MN is a data sender:

   -  If the MN is a data sender and when a mobility event occurs, the
      MN begins to transmit signaling messages toward a CN in the
      downstream direction.  In this case, an NSLP-aware node recognizes
      that the session paths logically converge, and then the NSLP-aware
      node realizes it is the DCRN through the procedure above: the
      procedure of CRN discovery is similar to the creation of the
      routing table of node N except for the unchanged flow ID.

   -  When an MN (as a sender) undergoes handover, the UCRN can be
      determined for upstream flow by the method above.  In this case,



Lee, et al.             Expires January 17, 2005               [Page 17]


Internet-Draft          Applicability Statement                July 2004


      the UCRN should be the first node where the signaling flow begins
      to logically diverge: it is similar to the creation of the routing
      table of node A except for the unchanged flow ID.  Since the UCRN
      is determined by whether outgoing path diverges or not, the UCRN
      discovery is more complex than the DCRN discovery.

4.3  Path update

   The CRN discovery is different according to the direction of
   signaling flow in mobility scenarios, and the DCRN operates
   independently of the UCRN although DCRN and UCRN can be
   simultaneously ferreted in bi-directional state establishment.
   Therefore, the procedures for path update may differ according to the
   direction of signaling flows as defined in terminology section: the
   upstream Path Update and the downstream Path Update.  In this case,
   each signaling initiator has to be authorized for secure signaling.

   For both types of path update, NSIS protocol needs to interact with
   various mobility signaling protocols, if any (during or posterior
   handover) to obtain performance gains through fast re-establishment
   of the NSIS states along the new path.  In this case, NSIS also needs
   to monitor the movement of a mobile node through several methods
   [4].In this section, we assume that an MN is a data sender.In this
   section, we assume that an MN is a data sender.

4.3.1  State setup and update

   Before initiating the Path Update, an MN or a CN needs to have its
   session ownership by the procedure of authentication and
   authorization and to check the availability of resources on the new
   path.  If the resources along the new path run short of, it needs to
   keep state  previously established for the flows while blocking new
   requests.  In this case, NSIS signaling for the Path Update also
   needs to have an appropriate priority over local requests for the
   resources.

   In the downstream path update, if resource availability is assured,
   the MN initiates the NSIS signaling for state setup toward a CN along
   the new path, and the DCRN discovery is implicitly done by this type
   of signaling initiated by the MN.  In this case, the node where the
   old and new logical session paths converge realizes that it is the
   DCRN, and afterward the DCRN sends a response message toward the MN
   to notify of NSLP state installed (e.g., in QoS-NSLP) or installs the
   NSLP states as responding the NSLP signaling initiated by the MN
   (e.g., as in RSVP).  In this case, the sender-initiated approach
   (e.g., QoS-NSLP) leads to faster setup than the receiver-initiated
   approach as RSVP as shown in Figure 4 below.  And then, the DCRN
   sends a refresh message toward the signaling destination to update



Lee, et al.             Expires January 17, 2005               [Page 18]


Internet-Draft          Applicability Statement                July 2004


   the changed MRI on the common path and also sends a teardown message
   toward the old AR to delete the NSIS states along the obsolete path
   (if possible).


      NI (MN)       NF         NF       NR (CN)
         |          |          |          |
         | RESERVE  |          |          |
         +--------->| RESERVE  |          |
         |          +--------->| RESERVE  |
         |          |          +--------->|
         |          |          |          |
         |          |          | RESPONSE |
         |          | RESPONSE |<---------+
         | RESPONSE |<---------+          |
         |<---------+          |          |
         |          |          |          |
         |          |          |          |

     (a) Sender Initiated Reservation


      NI (MN)       NF         NF       NR (CN)
         |          |          |          |
         | QUERY    |          |          |
         +--------->| QUERY    |          |
         |          +--------->| QUERY    |
         |          |          +--------->|
         |          |          |          |
         |          |          | RESERVE  |
         |          | RESERVE  |<---------+
         | RESERVE  |<---------+          |
         |<---------+          |          |
         |          |          |          |
         | RESPONSE |          |          |
         +--------->| RESPONSE |          |
         |          +--------->| RESPONSE |
         |          |          +--------->|
         |          |          |          |

      b) Receiver Initiated Reservation


     Figure.4 Sender- vs. Receiver-intiated reservation

   In the case of upstream path update, the CN (or a HA/ a GFA/MAP)
   sends a refresh message toward the MN to perform path update.  UCRN
   is discovered implicitly by the CN-initiated signaling along the



Lee, et al.             Expires January 17, 2005               [Page 19]


Internet-Draft          Applicability Statement                July 2004


   common path, and the node from which the common path begins to
   diverge into the old and new logical session paths realizes that it
   is the UCRN.  In this case, the CN should be informed of the movement
   event using an NSIS signaling message sent by the MN or monitoring
   the mobility signaling after detecting a change in its binding entry
   (see Section 6.1).  After the UCRN is determined as described in
   Section 4.2.3, it may send a refresh message to the MN along the new
   path while establishing the NSIS association between the updated
   peers, and afterward the UCRN may send a teardown message toward the
   old AR to delete the NSIS state on the obsolete path (if possible).

   The state update in control plane on the common path to reflect the
   changed MRI brings issues on the end-to-end signaling addressed in
   Section 3.1.  Although the state update does not give rise to
   re-process AAA and admission control, it may lead to the signaling
   overhead and latency.

   One of the goals of path update is to avoid double reservations (in
   case of QoS signaling) on the common path described in Section 3.1.
   The double reservation occurred along the common path may be solved
   by establishing a signaling association using the unique session
   identifier and by the update of packet classifier/flow identifier.
   In this case, the NSLP state can be shared for flows with different
   flow identifiers.

4.3.2  State Teardown

   After re-establishment of the NSIS state along the new path, the
   state on the obsolete path need to be quickly removed by path update
   mechanism to prevent the waste of resources due to double reservation
   (and resource allocation problem by call blocking) and to reduce the
   cost of using the resources in the access network as described in
   Section 3.1.  Although the release of the existing state on the old
   path can be accomplished by timeout of soft state, the refresh timer
   value may be quite long and the maintenance of the NSIS state on the
   obsolete path may not be necessary.  Therefore, the transmission of a
   teardown message is particularly preferred to the use of refresh
   timer to quickly delete the old state.  Note that, however, it is not
   necessary for the GIMPS to be explicitly removed because of the
   inexpensiveness of the state maintenance.

   The CRN is an appropriate point to initiate the teardown toward the
   old AR after re-establishment of the state along the new path.  In
   this case, the release of old state on the obsolete path can be
   accomplished by comparing the NSLP branch ID and through reverse
   routing using SII.  This can prevent the teardown message from being
   forwarding toward along the common path.  However, whether the
   teardown message can be sent toward the opposite direction to the



Lee, et al.             Expires January 17, 2005               [Page 20]


Internet-Draft          Applicability Statement                July 2004


   state initiating node is still an open question.  This also leads to
   authorization problem because a node which does not initiate
   signaling for establishing the NSIS state can delete the state.

   The immediate removal of state along the old path may not be
   appropriate for some mobility situations.  For instance, in the fast
   handover of a ping-pong type where an MN may return to the previous
   AR after staying at a new AR for a short while, it causes signaling
   overhead and when to delete the state along the obsolete path remains
   still an open issue and needs to be discussed further in the later
   version of this draft.  Another example is the last node detection
   problem.  If the old AR is the last node due to handover, its NSLP
   may trigger an error message to indicate that NSLP messages cannot be
   forwarded any further.  This error message may cause the removal of
   the old states.  However, although the error message is initiated,
   the state on the old path should not be deleted before
   re-establishing the state along the new path (make-before-break
   handover).  The more details are discussed further in Section 6.5.

































Lee, et al.             Expires January 17, 2005               [Page 21]


Internet-Draft          Applicability Statement                July 2004


5.  Mobility-Related Issues with NSIS Protocols

5.1  Specific Issues with NTLP

   The NTLP protocol maintains a per-flow message routing state and a
   per-peer messaging association state.  The former is installed and
   maintained by a peer discovery mechanism, while the latter is set up
   by the normal procedures of transport (and security protocols, when
   secure channel for C-message transport is desired) that comprise the
   messaging association.

   NTLP is responsible for detecting route change, updating its own
   routing state consistently, and informing NSLPs at affected nodes.
   In mobility environments, for an end-to-end signaling flow, its
   signaling path can be changed upon a successful MIP registration.
   This means a new peer discovery procedure needs to be triggered
   (e.g., through certain routing interface) and a new NTLP message
   routing state must be adapted.

   NTLP provides 5 mechanisms to detect a route change.  In uplink
   signaling case in mobility environments an MN can use the first
   approach, local trigger, to determine next hop has changed and
   initiate a new peer discovery until downstream CRN is found.  In
   downlink signaling case mobility environments, most detection
   mechanisms at CN, HA or other mobility agents (if they support NSIS
   at all) can only determine a route has "changed", i.e., a binding
   cache changed.  However, these entities do not necessitate an actual
   NTLP or NSLP CRN, and the latter is the actual node of NSIS interests
   and needs to be detected.  This is an issue related to an NTLP
   implementation's scale of re-discovery.

   After detecting a route change has occurred, in addition to updating
   the message routing state, an NTLP implementation at the downstream
   CRN needs to notify local NSLP(s) to initiate their own state local
   repairs.  Messaging association state can be ignored as it is
   per-peer meaningful and not very expensive.

   NTLP works with general IP tunneling by applying the same
   encapsulation to NSIS messages as data packets.  Most mobility
   protocols involve IP-in-IP encapsulation in part of the signaling
   path.  As this becomes effective dynamically after a mobility
   registration, an NTLP implementation should gain the knowledge about
   the introduction or change of encapsulation methods in the responding
   node, if NSLPs want to be signaled into these tunnels.  Moreover,
   IP-in-IP encapsulation is simultaneously coupled with route change,
   thus an NTLP implementation needs to interact with mobility
   registration carefully.




Lee, et al.             Expires January 17, 2005               [Page 22]


Internet-Draft          Applicability Statement                July 2004


5.2  Specific Issues with QoS-NSLP

   The QoS-NSLP protocol establishes and maintains QoS-related state at
   NSIS aware nodes along the path of data flow to support some
   forwarding resources required for that flow.  In mobility scenarios,
   as mentioned in Section 4, the QoS-NSLP protocol needs to immediately
   perform the procedure of the Path Update after an appropriate CRN is
   discovered to continue to support QoS-related state for that session.
   In this case, the following basic issues rise when considering
   interaction with GIMPS layer as well as mobility protocols:

   -  When/how is QoS-NSLP signaling initiated after mobility? For
      instance, if an MN is a sender and the sender-initiated
      reservation approach is used, when does the MN send RESERVE
      message forward CN to do the Path Update (and CRN discovery if
      coupled approach is used)? In the receiver-initiated reservation,
      when is Query message sent to a corresponding receiver or node
      initiating reservation? In this case, QoS-NSLP should know or
      detect the MNí¯s movement, e.g., through the SII notified over API
      between GIMPS and QoS-NSLP (see Sections 5.4 and 6.1).

   -  How/when does an MN know/find out what resources are available
      before a reservation is made after handover? And If QoS-resources
      in a new access network are oversubscribed, how is the reservation
      for required resources made? The QoS-NSLP of MN may be able to
      know the availability of resources at the new access network using
      Query message.  In this case, the Query message needs to have a
      priority rather than any other signaling: priority signaling for
      call setup.  If an MN moves an access network which does not have
      a sufficient resources available, the MN may fail to reserve the
      resources and it tries to keep the previous state by its mulihomed
      interfaces.  In such an oversubscribed scenario, certain signaling
      message required for reservation may also be prioritized, but how
      those signaling messages are dealt with priority is still open and
      so needs to be discussed further in the later version of this
      draft.

   -  Which layer should the (NSLP) CRN discovery be performed at, GIMPS
      or QoS-NSLP? Although a QoS-NSLP can detect the change of
      signaling path and discover the CRN by keeping track of SII, The
      CRN discovery may be preferred at the GIMPS layer to at the
      QoS-NSLP.  As mentioned Section 4, since GIMPS detects the CRN as
      an extension of peer discovery, it does not add processing
      overhead.

   -  How/by who can RESPONSE message be sent to the corresponding QNI
      if QNR (e.g., an MN) of the RESPONSE message performs handover
      before the receipt of the message? If RESERVE (for refresh)



Lee, et al.             Expires January 17, 2005               [Page 23]


Internet-Draft          Applicability Statement                July 2004


      including Response request is sent to the MN from a node but the
      MN begins to handover the OAR in behalf of the MN may be a proxy
      to initiate RESPONSE message.  In this case, the MN may notify OAR
      of the handover or error conditions
      (the-last-node-is-not-detected) using NOTIFY message.  This
      í«invalid-NRí¯ problem is discussed further in Section 6.5.

   -  How is refresh time set up in the situation of frequent handover?
      The QoS-NSLP uses peer-to-peer refreshing approach to allow QNEs
      to choose appropriate refresh intervals according to their network
      environments (e.g., an access network, or a core network).  In
      mobility environments, refresh time intervals-related issues are
      discussed in Section 6.3

   -  How does CRN immediately remove the state along the old path after
      the establishment of state along a new path? The CRN can delete
      the state along the old path by keeping track of SII or using
      Request Identification Information (RII).  Since the SII object is
      similar in nature to the RSVP HOP object [5], RESERVE message set
      with TEAR flag can be forwarded to the direction of reverse path.
      In route change, the RII contained RESPONSE_REQUEST object (if
      any) allows the CRN to correctly send back the RESERVE message
      with TEAR flag to an appropriate (scoped) node.  Note that as
      mentioned in Section 5.1, NTLP state along the old path does not
      need to be explicitly deleted before the expiration of the refresh
      time interval because of inexpensive of NTLP state.

   Some issues according to performance gain, bi-directional
   reservation, aggregation reservation and various handover scenarios
   are discussed further in Section 6: for example, refresh reduction,
   session binding, layering, peer agreement, and so on.

5.3  Specific Issues with NAT/FW NSLP

   The NAT/Firewall NSLP [6] establishes and maintains firewall pinholes
   and NAT bindings at NAT/FW NSLP nodes along the data path.  With
   regard to mobility a few issues need to be considered:

      In case of an IP address change firewall rules and/or NAT bindings
      become invalid which effectively prevents the end host from
      sending or receiving data packets.  For example, without updating
      the firewall pinhole by a NSIS aware data sender who is located
      behind a firewall data packets with a new source IP address are
      most likely dropped at the firewall.  If a data receiver , who is
      located behind a NAT, changes its IP address then incoming packets
      are rewritten at the NAT and forwarded to the wrong IP address.
      The QoS NSLPs might 'only' temporarily experience a weaker quality
      of service if the installed flow identifier is not uptodate.



Lee, et al.             Expires January 17, 2005               [Page 24]


Internet-Draft          Applicability Statement                July 2004


      Although NSIS applies the soft-state principle and allocated state
      times out without refresh messages, it is possible that mobility
      leaves state (such as firewall pinholes) in place for some time.
      Since the NAT/Firewall NSLP aims to install pinholes (and NAT
      bindings) it is possible to re-use this installed state once a
      mobile node roams to a new location.  Deleting state along the old
      path helps to limit this problem.  However, this problem exists
      anyway as identified in [7] due to the capability of IP spoofing
      since the main problem is the usage of non-cryptographically based
      IP address filters.  Hence, the NAT/Firewall NSLP is (in a
      mobility environment) not in the same fashion concerned about
      deletion of state along the old path.

      There also seem to be some differences between the security
      functionality required by the QoS NSLP and the NAT/Firewall NSLP
      (as analysed in [7], in [6] and in [8].  The security solution for
      the NAT/Firewall NSLP needs to reflect mobility specific security
      issues.  This also has an impact on refresh handling (i.e.,
      peer-to-peer vs.  end-to-end), authorization issues, the usage of
      the session identifier and  end-to-end security (with regard to
      the binding between NSIS and the application layer signaling).

5.4  Common issues related to NTLP and NSLP

   In mobile environments, mobility related information for path update
   can be exchanged through the API specified in [NTLP].  For example,
   when a route change due to mobility occurs, SII-Handle can be
   provided from GIMPS to an NSLP in order to inform of the route
   change.  The SII-Handle is a handle to a data structure, identifying
   peer addresses and interfaces.  It can be used to identify route
   changes and for explicit routing to a particular GIMPS next hop.
   Based on the information, the involved NSLP can initiate path update
   by sending necessary signaling messages through the API.  The details
   on the API are an implementation issue.

   Message routing information (MRI) and Session ID are also shared by
   the GIMPS and NSLP through the API.  Whenever there is any route
   change due to mobility the MRI will be updated although the Session
   ID will not change.  The MRI should be consistent with the SII-Handle
   described above.











Lee, et al.             Expires January 17, 2005               [Page 25]


Internet-Draft          Applicability Statement                July 2004


6.  Applicability Statement

6.1  Support for Macro Mobility-based scenarios

   This section considers how should NSIS protocols interact with the
   basic macro mobility protocols such as Mobile IPv4 and Mobile IPv6,
   and other global mobility approaches will be discussed further in the
   next version of this draft.

   The NSIS signaling needs to consider the following scenarios related
   to basic Mobile IP to interact with it.

   (1) A flow associated with an MN, either sent or received by the MN,
      may desire to be continuely served signaling services after a
      mobile IP handover.  In this case, NSIS needs to be able to signal
      for such flows upon an MN's movements to seamlessly provide the
      correspondin service to one (e.g., QoS).  The signaling procedure
      results in creating a new NSIS branch along the new path through
      an appropriate CRN discovery and a Path Update.

   (2) Either the sender or the receiver of an MN's flow can initialize
      an NSIS signaling, and it is essential to require the NSIS
      signaling initiator to be authorized to initialize the signaling.
      Note that nodes within the network may also initiate NSIS
      signaling for the given session, for example, to handle route
      changes caused by Mobile IP routing in the middle of the network,
      or to support seamless handovers.

   (3) Data traffic, in either direction between an MN and a CN, can be
      routed directly using a routing header, or indirectly by IP-in-IP
      encapsulation (or the combination of them) in different segments
      of the data transmission depending on the mobility mode (either
      route optimization or triangle routing is used; whether reverse
      tunneling is used; either mobile IPv4 or IPv6 is used; whether LMM
      is used, etc.).  In this case, NSIS signaling needs to immediately
      be initiated by using a mobility routing interface (e.g., mobility
      API) between the NSIS protocols and the Mobile IP according to the
      method of each routing.

   (4) An MN's handover can be either intra-domain (within an access
      network domain) or inter-domain (from an access network domain to
      another), which mainly concerns with topology information
      exchange, authorization and accounting issues.  The interworking
      with NSIS signaling and some mobility management protocols (i.e.,
      HMIP, FMIP, etc) in various handover scenarios may give rise to
      some performance gains (see Section 6.3).

   (5) In mobile IPv6, an MN can support multiple care-of-addresses at



Lee, et al.             Expires January 17, 2005               [Page 26]


Internet-Draft          Applicability Statement                July 2004


      one time, if it is connected to multiple access networks
      simultaneously (or even if it is connected to one access network).
      Although only one primary care-of-address will be used for routing
      traffic from the CN to the MN, this multi-homing feature
      potentially can be used to enhance the NSIS signaling performance
      (see Section 6.2).  The inter-domain handover, for instance, may
      require additional latency to perform the NSIS signaling procedure
      including authentication and authorization rather than the
      intra-domain handover, but the latency penalty of NSIS signaling
      can be mitigated if the MN is multi-homed.

6.1.1  Implications to Mobile IP-related scenarios

   As NSIS is path-coupled signaling, one imposed requirement here is
   that the NSIS protocols are to be typically associated with a route
   changes for route optimization  between the CN & the MN and an
   IP-in-IP encapsulation from the HA to the MN as well as mobility, and
   those interaction also needs to be notified to all NSLPs by the API
   between GIMPS and NSLP for the CRN discovery and the Path Update as
   described in Section 4.  Therefore, NTLP or NSLP needs to have an
   interface with the Mobile IP to immediately react to the mobility
   event.  In other words, NSIS implementation needs to be designed to
   react based on the endpoint notification of which behaviour of Mobile
   IP has taken place and probably, when the timer of Mobile IP
   refreshes (to keep corresponding NSLPs reacting to it).

   An ideal interface between NSIS signaling and the Mobile IP should
   make that NSIS signaling is able to react to the mobility event as
   soon as possible whenever Mobile IP changes its characteristics in
   any place for the flows, In general, it is appropriate that NTLP is
   involved in the interaction with the Mobile IP rahter than NSLP,
   because NTLP is responsible for detecting the mobility and routing
   NSIS messages.  Therefore, it is reasonable to assume NTLP should be
   able to notify NSLP of the update of state when mobiity is detected.
   Here also are some issues which rise when the API between the NSIS
   and the Mobile IP is considered.

   -  Which information does the NTLP detect the movement based on?
      After an MN arrives at a new network attachment point, current
      reachability information is transferred from the MN to its HA as
      the last procedure of handover.  It indicates that NTLP may need
      to interact with the start/completion of a binding process (e.g.,
      registration request in Mobile IPv4 and Binding Update in Mobile
      IPv6) to detect the IP address change and refer to the tunnel
      information of Mobile IP.  Therefore, provided the NTLP detects
      the mobility using the information of binding process, faster
      state establishment and removal can be performed.  However, in the
      fast or ping-pong handover, it may result in considerable



Lee, et al.             Expires January 17, 2005               [Page 27]


Internet-Draft          Applicability Statement                July 2004


      signaling overhead and some possible errors.

   -  How and what information can the NSLP expect from NTLP, or
      directly from the routing interface after mobility?

   -  How to coordinate the mobility binding update interval and NSIS
      signaling interval? Since the Binding Update or the Registration
      request message occur periodically even for the MN with the same
      point of attachment, the movement detection based on the binding
      process sometimes causes the NTLP/NSLP to inappropriately initiate
      the CRN discovery and the Path Update.  Although the issue is
      closely related to implementation, it needs to be considered to
      have the performance gain of NSIS signaling.

   An overall coordination/synchronization about the interworking with
   the NSIS and the Mobile IP is still open and needs to be discussed
   further.

6.1.1.1  Mobile IPv4-specific issues

   The data flows of Mobile IPv4 are forwarded based on the triangular
   routing (even if route optimization is considered an extended
   option), and an MN retains a new CoA from the FA (or the external
   method such as DHCP) in the corresponding access network unlike the
   Mobile IPv6 whenever the MN arrives at the new network attachment
   point (e.g., a FA or a foreign link)[9].  When the MN is a sender,
   the downstream data flows from the MN are directly transferred to the
   CN not necessarily through the HA or indirectly through the HA using
   the reverse routing.  On the other hand, upstream data flows from the
   CN are routed through the IP tunneling between the HA and the FA (or
   the HA and the MN in the case of the Co-located CoA).  In this case
   of such a routing which is dependent on the HA, it represents that
   the NSIS signaling needs to interact with the IP tunneling of Mobile
   IP to provide an appropriate signaling service for that flow.

   The following figures 5 (a)-(e) show the NSIS signaling flows
   required according to the direction of data flows and the routing
   methods .



         MN        FA (or FL)                         CN
         |             |                               |
         | IPv4-based Standard IP routing              |
         |------------ |------------------------------>|
         |             |                               |

       (a) MIPv4: MN-->CN, no reverse tunnel



Lee, et al.             Expires January 17, 2005               [Page 28]


Internet-Draft          Applicability Statement                July 2004


         MN              FA               HA              CN
         | IPv4 (normal)  |                |               |
         |--------------->| IPv4(tunnel)   |               |
         |                |--------------->| IPv4 (normal) |
         |                |                |-------------->|

       (b) MIPv4: MN-->CN, the reverse tunnel with FA Care-of-Address

         MN             (FL)               HA             CN
         |               |                |               |
         |        IPv4(tunnel)            |               |
         |------------------------------->|IPv4 (normal)  |
         |               |                |-------------->|

       (c) MIPv4: MN-->CN, the reverse tunnel with Co-located
         Care-of-address

         CN              HA                FA             MN
         |IPv4 (normal)  |                 |              |
         |-------------->|                 |              |
         |               |  MIPv4 (tunnel) |              |
         |               |---------------->| IPv4 (normal)|
         |               |                 |------------->|

       (d) MIPv4: CN-->MN, Foreign agent Care-of-address


         CN              HA                (FL)           MN
         |IPv4(normal )  |                 |              |
         |-------------->|                 |              |
         |               | MIPv4 (tunnel)  |              |
         |               |------------------------------->|
         |               |                 |              |

       (e) MIPv4: CN-->MN with Co-located Care-of-address

   Figure 5. Implications for signaling under different Mobile IPv4
             scenarios

   When an MN (as a sender) arrives at a new FA and the corresponding
   binding process for the FA CoA is completed:

   -  For downstream signaling flow, the MN needs to perform the CRN
      discovery (DCRN) and the (downstream) Path Update toward the CN as
      described in Section 4 to establish the NSIS state  along the new
      path between the MN and the CN as shown in Figure 6 (a).  If the
      reverse tunnel is used and the state along the tunneling path does
      not exist, the NSIS state may be established along the tunneling



Lee, et al.             Expires January 17, 2005               [Page 29]


Internet-Draft          Applicability Statement                July 2004


      path from the FA to the HA  as shown in Figure 6 (b).  In this
      case, the DCRN may be discovered on the tunneling path and the new
      flow identifier for the tunneling state update may need to be
      created.

   -  For upstream signaling flow, the CN may initiate the NSIS
      signaling to update the existing state between the CN and the HA,
      and then NSIS signaling may need to interact with IP tunneling to
      also update the state along the tunneling segment from the HA to
      the FA as shown in Figure 6 (d).  In this case, the UCRN may be
      discovered somewhere on the tunneling path, and the new flow
      identifier for the tunneling state update may be created.

   When the MN (as a sender) arrives at a new foreign link and the
   corresponding binding process for the co-located CoA is completed:

   -  For downstream signaling flow, the NSIS signaling for the DCRN
      discovery and the Path Update is equal to the case for FA CoA
      above (as shown in Figure (a)) except that in case of using the
      reverse tunnel, the NSIS state may be established along the
      tunneling path from the MN to the HA  as shown in Figure 6 (C).

   -  For upstream signaling flow, the CN may initiate the NSIS
      signaling to update the existing state between the CN and the HA
      and then NSIS signaling may need to interact with IP tunneling to
      also update the state along the tunneling segment from the HA to
      the MN as shown in Figure 6 (e).  In this case, the UCRN may
      eventually be discovered somewhere on the tunneling path, and the
      new flow identifier for the tunneling state update may also be
      created.

   Note that in the case of interaction with IP tunneling, DCRN and UCRN
   may be identified at the same node on the tunneling path.  For
   example, NSIS CRN may usually be the HA if the HA and the FA are
   NSIS-aware and the NSIS state along the tunneling path is not
   established.  Therefore, the CRN discovery may be affected according
   to the interaction with NSIS signaling and IP tunneling, and the FA
   and the HA should be NSIS-aware to do the Path Update along the
   appropriate path.  However, the effect that the IP tunneling has on
   the CRN discovery and the Path Update needs to be discussed further.

6.1.1.2  Mobile IPv6-specific issues

   The Mobile IPv6 case differs from Mobile IPv4 in that an FA is not
   required in the data path and the Route Optimization process between
   the MN and CN is basically used to avoid the triangular routing in
   the Mobile IPv4 scenarios as shown in Figure 6 [10].  Therefore, if
   the use of route optimization is not mandatory, data flow routing and



Lee, et al.             Expires January 17, 2005               [Page 30]


Internet-Draft          Applicability Statement                July 2004


   NSIS signaling procedure (including the CRN discovery and the Path
   Update) of Mobile IPv6 would be similar to that of the Mobile IPv4
   described in Section 6.1.2.1.

   When an MN (as a sender) arrives at a new AR and the binding process
   is successfully completed, for downstream signaling flow, the MN may
   initiate NSIS signaling for DCRN discovery and the (downstream) Path
   Update to establish the state along the new path between the MN and
   the CN or the tunneling path from the MN to the HA if the reverse
   tunnel is used, as shown in Figure 6 (a) & (b), repectively.  for
   upstream signaling flow, the CN may also update the state along the
   common path toward the HA through the Path Update and afterward the
   NSIS state along the tunneling segment from the HA to the MN may be
   updated by interaction with IP tunneling  as shown in Figure 6 (d).
   However, if the route optimization is performed successfully between
   the CN and the MN, for upstream flow, CN needs to newly initiate NSIS
   signaling to discover an appropriate UCRN and do the Path Update
   along a new path between the CN and the MN as shown in Figure 6 (c):
   bidirectional state establishment may be required.  In this case, the
   obsolete path of the existing tunneling segments needs to
   appropriately be removed after re-establishment of NSIS state along
   the optimized path.  However, when to remove the tunneling segment
   and/or how to tear it down through the interworking with the
   IP-tunneling is still an open issue.

   Although the routing of Mobile IPv4 with the co-located CoA is
   similar to that of Mobile IPv6 as shown in Figure 5 (a), (c) and (e),
   one of the differences between the Mobile IPv6 and the Mobile IPv4 is
   the method to acquire the CoA.  That is, the Mobile IPv6 can usually
   acquire the CoA from the corresponding access router or external
   method through the stateless autoconfiguration or the stateful
   autoconfiguration (e.g., DHCPv6), respectively , and the Mobile IPv4
   obtains the co-located CoA using an external method such as DHCP.
   This difference may have some effects on the creation of flow
   identifier and make NSIS signaling performed differently according to
   Mobile IP mode.  However, it is still open and needs to be discussed
   further in the later version of this draft.



          MN                                             CN
          |                                              |
          |IPv6+HomeAdressOpt                            |
          |--------------------------------------------->|
          |                                              |

         (a) MIPv6: MN-->CN, no reverse tunnel




Lee, et al.             Expires January 17, 2005               [Page 31]


Internet-Draft          Applicability Statement                July 2004


         MN             HA                              CN
          |IPv6(tunnel)  |                               |
          |------------->| IPv6(normal)                  |
          |              |------------------------------>|
          |              |                               |

         (b) MIPv6: MN-->CN, with reverse tunnel

         CN                                             MN
          |                                              |
          | MIPv6(RH Type 2)                             |
          |--------------------------------------------->|
          |                                              |

         (c) MIPv6: CN-->MN, route optimization

         CN             HA                              MN
          |IPv6(normal)  |                               |
          |------------->|                               |
          |              |     MIPv6(tunnel)             |
          |              |------------------------------>|
          |              |                               |

         (d) MIPv6: CN-->MN, no route optimization

   Figure 6. Implications for signaling under different Mobile IPv6
   scenarios

6.2  Multihoming/make-before-break scenarios

6.2.1  Overview

   A host that is an initiator or responder of signaling messages may be
   either multi-homed or mobile in some cases.  Especially, when current
   activities in the multi6 WG are considered, multi-homed hosts and
   scenarios may be very common in a future IPv6 Internet.  Such
   scenarios may also include load balancing techniques, i.e., when
   multiple connections to different providers are used simultaneously.
   Therefore, multi-homed hosts may use different paths that converge at
   some CRN.  If load balancing is active, the paths are used at the
   same time, but if multi-homing is used for resilience only, the
   active path changes during fail-over.

   For mobile hosts flow paths are changed when the point of network
   attachment is changed.  This may also require a change of state in
   network elements along the old and new paths.The term "seamless
   mobility" is often referred to mean that the MN is able to keep an
   ongoing session seamlessly (without experiencing perceivable service



Lee, et al.             Expires January 17, 2005               [Page 32]


Internet-Draft          Applicability Statement                July 2004


   interruption or performance penalty) during and after moving from one
   access network to another.  Measures to achieve seamless mobility
   include soft handover and anticipated handover [QoSSig4G].  The
   former requires the MN to keep the old path, while data is received
   over the new path.  This approach is only possible if the MN is
   multi-homed.  Appendix B discusses fast state installation by using
   anticipated handovers, in which the MN signals the new path while
   still connected to the old one.

6.2.2  NTLP/NSLP support

   NTLP uses endpoint address to install message routing state, thus the
   new address for an MN introduced in MIP has to invoke a change of
   message routing state.  In multihomed MN scenarios, both new address
   and old address can be valid during a certain period of time, the new
   data path may co-exist with the old one.  It is theoretically
   possible to perform certain NSIS state update in the new path during
   this period, however the signaling ends need to be careful, so that
   the correct routing information will be delivered for setting up new
   or updating existing message routing state in the correct path
   segment.  Furthermore, performing such actions should not cause NSLP
   service interruption, protocol misbehaviors or security holes and
   thus should be discouraged.

6.3  QoS Performance Considerations in mobility scenarios

   The routing characteristics of mobile IP system described in Section
   6.1 cause the session path to be changed and in this case the exiting
   protocols which do not support signaling in dynamic environment where
   route change or mobility event occurs can cause the problems
   addressed in Section 3.1.  Particularly, in mobile/wireless
   environments, QoS parameters such as resource utilization and
   signaling latency need to be considered so that how NSIS protocols
   should interact with mobility protocols is correctly evaluated.  In
   the perspective of resource utilization, the double reservation
   problem leading to the waste of resource and call blocking is
   generally known in handover scenarios and it may be alleviated by the
   procedure of the CRN discovery and the Path Update described in
   Section 4.  In this section, we take into consideration on how the
   resource utilization of the NSIS signaling flow itself can be
   managed: The adjustment of refresh time interval and refresh
   reduction.

   The NSIS protocol suite normally use a soft-state approach based on
   the peer-to-peer refreshing to manage state in NEs.  At the GIMPS
   layer, the state is maintained through the exchange of GIMPS query/
   response messages between adjacent peers [2].  In this case, the peer
   relationship is maintained using a timer which implies how long the



Lee, et al.             Expires January 17, 2005               [Page 33]


Internet-Draft          Applicability Statement                July 2004


   association between the peers can be considered valid.  That is, if
   it has not been refreshed until the timer expires (e.g., after 30
   seconds as a default value), the peer relationship is removed.  The
   management of state (i.e., routing state and messaging association)
   can be controlled in this way.  In case of QoS-NSLP, states are also
   set up and then maintained for the reservation of desired resources
   using the peer-to-peer refresh messages.  The peer-to-peer based
   refreshment allows the QoS-NSLP to appropriately select the refresh
   time by considering the current network environment.  For example, it
   may set the refresh timer value in the mobile/wireless (access)
   network to a smaller value than that in the core (wired) network by
   the method described in [11].  In the situation of frequent handover,
   the adjustment of the refresh time results in minimizing the waste of
   resources.  Note that, however, unlike the QoS-NSLP, the refresh time
   of NTLP state doesn't need to be adjusted according to the type of
   the network from the perspective of resource utilization.
   Furthermore, NTLP state along the obsolete path does not also need to
   be explicitly removed before the expiration of refresh timer.

   In mobile and wireless networks, the QoS-NSLP (rather than the NTLP)
   is able to set the refresh timer value depending on the handover type
   (e.g., make-before-break or break-before-make handovers ) or the
   reservation style (e.g., pre-establishment or re-establishment) to
   optimize the resources utilization.  For example, in the
   make-before-break handover, appropriate refresh time intervals are
   able to be notified using the reserved field of REFRESH object, and
   if the refresh time value is set to a little higher value than the
   estimated handover latency, the MN can be provided with seamless QoS
   service using the pre-reserved resources, and the resources which are
   pre-reserved but unused will be timely released after handover [12].

   After the state along a new path established, QNEs along the
   signaling path may send refresh message to the neighboring peer node
   before the expiration of refresh timer to only update the state
   previously installed along the path or the changed flow ID along the
   common path after the CRN discovery.  In this case, the overhead
   required to perform refreshes can be reduced, in similar way to that
   proposed for RSVP [Refresh Reduction]: Refresh Reduction.  Once a
   RESPONSE message has been received indicating the successful
   installation of a reservation, subsequent refreshing RESERVE messages
   can simply refer to the existing reservation, rather than including
   the complete reservation specification.  For example, only the
   Session_ID and the SII with no QSPEC at all are sent to just refresh
   the state (e.g., reservation) previously installed and additionally
   the changed flow ID with together those ID is only sent to update it
   along the common path.  Especially, the use of reduced refresh
   messages over wireless channels or in access networks as well as in
   core networks results in having the advantage of efficient



Lee, et al.             Expires January 17, 2005               [Page 34]


Internet-Draft          Applicability Statement                July 2004


   utilization of resources.

   As mentioned in Section 3.1, in the mobility scenarios unlike the
   route change, the end-to-end signaling problem according to the Path
   Update gives rise to the deterioration of network performance such as
   the signaling overhead, service blackout, and so on.  To reduce
   signaling latency in the Mobile IP-based scenarios, the NSIS protocol
   suit needs to interwork with localized mobility management (LMM).  If
   the GIMPS/QoS-NSLP protocols operate over Hierarchical Mobile IPv6
   and the CRN is discovered between an MN and MAP, the procedure of the
   Path Update can be localized.  However, it needs to be discussed
   further how the Path Update is performed with scoped signaling
   messages within the access network under the MAP.

   In the inter-domain handover, additional latency occurs to perform
   the NSIS signaling procedure including authentication and
   authorization rather than that in the intra-domain handover.  In this
   case, a possible scenario for mitigation of the latency penalty may
   be that the MN is multi-homed, or the NSIS protocols interact with
   mobility protocols such as Seamoby protocols (e.g., CARD and CTP) and
   FMIP.  Another scenario is to use peering agreement which allows that
   for an aggregate reservation, aggregation authorization is performed
   once on an inter-domain link without the check of the authorization
   of each individual session.  However, those issues are still open how
   those approaches can be used by the NSIS protocol suit.

6.4  Use cases of Identifiers

   The current NTLP and QoS-NSLP drafts have defined important
   identifiers including Session Identifier (SID), flow identifier,
   signaling application identifier (NSLPID), Source Identification
   Information (SII), Reservation Sequence Number (RSN), and so on.
   These IDs are useful for different purposes in NSIS signaling.

   When an NSIS signaling message (e.g., RESERVE) with an existing SID
   and a different SII is received, an NE (e.g., QNE) knows its upstream
   peer has changed.  In mobile environments, the SID and SII can be
   used to detect the CRN.  For example, after the handover of an MN, if
   an NE (e.g., QNE) on the data path receives an NSLP message (e.g.,
   RESERVE) with an SID for which it already has state installed but
   with a different SII, the QNE can determine that it is a merging
   point (i.e., an NSLP CRN) of the old and new paths, accordingly,
   involve state setup in the new path and teardown of the state on the
   old path.  However, if an NE (e.g., QNE) receives an NSIS message
   (e.g., RESERVE) with a special flag (e.g., NO_REPLACE flag) set but
   with the different SII, teardown of the state on the old path should
   not happen.  This may apply to a ping-pong type of handover where an
   MN wishes to keep state to its old attachment point in case it moves



Lee, et al.             Expires January 17, 2005               [Page 35]


Internet-Draft          Applicability Statement                July 2004


   back there.

   It is also possible to discover the CRN using message the routing
   information (MRI) and SID at the GIMPS level.  The MRI is used by
   GIMPS in determining the correct next GIMPS hop for the signaling
   message [2].  Whether the CRN is discovered by NTLP or NSLP is still
   an open question.  If the CRN is discovered using the MRI, the SII
   may be redundant in terms of CRN discovery.  In any case, the MRI
   should be consistent with the SII.

   The data flow will typically be classified by the flow identifier at
   NEs.  The flow identifier may change due to mobility.  In this case,
   it should be updated on the common path so that the data flow can get
   necessary treatment.

   The RSN may be useful in detecting duplicate messages in the mobile
   environment.  For example, it is possible for the MN to move to the
   2nd NAR soon after being attached to the 1st NAR.  In this case, an
   NSIS node may receive the RESERVE message twice.  The problem arises
   without using RSN, when the RESERVE message from the 1st NAR arrives
   later than the RESERVE message from the 2nd NAR.

   Optionally, although a mobility object has not been defined in the
   NTLP/NSLP drafts, it may be used to inform of the handover of an MN
   or a route change [12] and therefore to expedite the CRN discovery.
   The mobility object may be defined in the NTLP (e.g., in GIMPS
   payload) or NSLP messages to notify of any mobility event explicitly,
   and it may contain various mobility-related fields, e.g.,
   mobility_event_counter and handover_init fields.  The
   mobility_event_counter field can be used to detect the latest
   handover event to avoid any confusion about where to send a
   confirmation message and to handle the ping-pong type of movement
   described in Section 6.7.  The handover_init field can be used to
   explicitly inform that a handover is now initiated for fast state
   re-establishment and to handle the invalid NR problem described in
   Section 6.5.

6.5  Peer Failure Scenarios

   A dead peer can occur either because a link or a network node, or
   because the MN moved away without informing NSLP/NTLP (it is
   recommended to link mobility- and NSIS signaling such that this does
   not happen).

   Dead peers of interest in mobility scenarios include CRN, MN, and AR.
   In general, it is possible that only NSIS functions (i.e., NTLP/NSLP)
   of the node may fail, or the physical hardware.




Lee, et al.             Expires January 17, 2005               [Page 36]


Internet-Draft          Applicability Statement                July 2004


   An MN may either fail or move.  When it fails, it becomes a dead
   peer.  When it moves, it either retains or changes its IP address
   (e.g., CoA).  If it moves and changes its IP address without
   notifying NSLP/NTLP, it also becomes a dead peer.

   The failure of a (potential) NSIS CRN may result in incomplete state
   re-establishment on the new path and incomplete teardown on the old
   path after handover.  In this case, a new CRN should be discovered
   immediately by the CRN discovery procedure described above.

   The failure or movement of an MN may cause the 'invalid NR' problem
   [12] where the NR is the MN.  If the MN moves, care should be taken
   to prevent the teardown of NSIS state on the old path before the NSIS
   state is re-established on the new path.  In this case, an error
   message should not be generated/sent to avoid any teardown on the old
   path.  It may be possible that the MN is not the NR, but a router in
   the access network (possibly the AR) is proxying for the MN instead.

   The failure of an AR may make the interactions with seamoby protocols
   (such as CARD and CT) impossible.  In this case, the neighboring peer
   closest to the dead AR may need to interact with such protocols.

   In any case, dead peers should be discovered fast to minimize service
   interruption.  The procedures for dead peer discovery (DPD) should be
   the same no matter why a peer is dead, because an NE discovering a
   dead peer cannot judge the specific reason.  The procedures for DPD
   should be handled by the NTLP.  In fact, the DPD can be considered as
   an extension to the GIMPS peer discovery.  A peer discovery message
   can be periodically transmitted to the neighboring peer (e.g.,
   responding node in [2]), and the responding node can send a response
   message.  To determine if the peer is alive, the use of a timer may
   be helpful.  For example, the response message may need to be
   received by the sender (e.g.,querying node in [2]) before the timer
   expires.  Otherwise, the responding node can be considered dead.

6.6  Guidelines for design of NTLP and NSLPs

   (XF) My interpretion is: in this whole doc we emphasis on the
   judging/stating whether/how current NTLP/NSLPs support mobility
   scenarios.  If we keep 6.6 here, we should keep it rather short and
   avoid long description of new solutions.  Or just a summary of which
   features are not supported in current protoocls (and need to be taken
   care) and general considerations for new NSLPs.








Lee, et al.             Expires January 17, 2005               [Page 37]


Internet-Draft          Applicability Statement                July 2004


7.  Security Considerations

   This section describes authorization issues for mobility scenarios in
   NSIS.  It tries to raise additional questions beyond those discussed
   in [13].

   For the discussion of various authorization problems we assume that
   initial authorization is strongly coupled to authorization handling
   in subsequent message interactions.  Making this assumption has some
   implication to the signaling message behavior.  It is certainly
   possible that the entities who request the initial reservation or a
   firewall pinhole and those who subsequently cause modifications are
   not the same entities.

   NSIS NSLPs define a flexible authorization scheme.  As argued in [14]
   it is necessary to consider cases where the sender, the receiver or
   both are authorizing a reservation.  For NAT and Firewall signaling
   it is necessary that, the sender and the receiver, authorize the
   creation of a NAT binding and the creation of a firewall pinhole.

   Subsequently, we will consider the case where the mobile node acts as
   a data sender followed by a discussion of the CN as a data sender.

7.1  MN as data sender

   This section refers to Figure 2 where the MN acts as a data sender
   which moves from one point of attachment to another.

   This description starts with an initial flow setup triggered by the
   MN which is also authorized by the MN.

7.1.1  MN is authorizing entity

   This scenario considers the initial flow setup executed by the MN
   whereby the MN provides authorization for the initial flow setup.
   The initial setup might be used to create state for subsequent
   authorization actions by the MN.  It is obvious that the
   authorization for the NSLP application (e.g., QoS NSLP) has to
   provided.  Depending on the underlying authorization model it might
   be either peer-to-peer or end-to-middle.  This authorization decision
   can possibly be treated independent of the authorization issues
   discussed in this section.


      MN                                              CN

       ------>----->------>------>------>------>------>    +
                  ACTION (MN is authz)                     |



Lee, et al.             Expires January 17, 2005               [Page 38]


Internet-Draft          Applicability Statement                July 2004


                                                           |
       <-----<-----<------<------<------<------<-------    | Flow
                           ACK                             | Setup
                                                           |
                                                           |
       ===============================================>    +
                            Traffic

              Figure 7: MN authorized initial reservation

   The following questions seem to be interesting:

   -  Should the MN indicate that it is the authorizing entity for
      subsequent actions to all entities along the path?

   -  What information should be used for this purpose?

   -  Who should add this information? Should the visited network of the
      MN add something to the signaling message during the initial flow
      setup?

   -  How do other entities along the path learn this information?

   Next, the case for a mobile node authorizing the DCRN is considered.
   This communication is illustrated in Figure 8.

   The movement of the mobile node after the initial flow setup requires
   authorization.  Various session ownership authorization issues are
   illustrated in [13].


       MN                    DCRN                      CN

                                                          + E.g.
       ------>----->------>------>------>------>------>   | Movement
                           ACTION                         | with state
                                                          | creation at
       <-----<-----<------<------<------<------<-------   + new path
                            ACK

                      Figure 8: MN authorizes DCRN

   The following questions are of interest:

   -  Why should the DCRN execute something on behalf of the MN? (i.e.,
      why should it trust the MN and what information can the DCRN use
      for verification?) As an example, the DCRN might delete state
      along the old segment.



Lee, et al.             Expires January 17, 2005               [Page 39]


Internet-Draft          Applicability Statement                July 2004


   -  Should the DCOR alone be able to start signaling (the DCOR might
      be a designed node in some mobility protocols (e.g., MAP)) since
      it is the node which has more information that other nodes based
      on the mobility signaling protocols?

   -  How should other nodes between the MN and the DCRN and the nodes
      between the DCNR and the CN know that the DCRN is now acting on
      behalf of the MN?

   The case of a corresponding node triggering an action is discussed.
   shows the exchange graphically.

   In this scenario the CN wants to, for example, tear-down a
   reservation.


       MN                    DCNR                       CN

      <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    +
                         TRIGGER                          | E.g.
                                                          | Tear
                                                          | Down
       ------>----->------>------>------>------>------>   |
                           ACTION                         |
                                                          |
       <-----<-----<------<------<------<------<-------   +
                            ACK

                      Figure 9: CN triggers action

   The following questions arise:

   -  Why should the MN trust the trigger?

   -  Is it possible to specify the security properties of the trigger
      message in more detail? Is this an NSIS signaling message?

   -  The discussions about an indicator which entity to charge for the
      reservation might be relevant (see [14]).

   -  Should the CN restrict the actions of the MN (e.g., delete,
      update, create)? On the shared segment it might, for example, be
      possible to restrict the allowed action to a flow identifier
      update.

7.1.2  CN is authorizing entity

   This scenario is similar to the CN triggering in Section 7.1.1.  Two



Lee, et al.             Expires January 17, 2005               [Page 40]


Internet-Draft          Applicability Statement                July 2004


   slightly different protocol variations will be considered.
   Authorizing some actions in the reverse data flow direction is more
   difficult as it can easily be seen in Figure 10.

7.1.2.1  CN asks MN to trigger action (on behalf of the CN)

   In Figure 10 the CN authorizes the MN to start signaling after, for
   example, a movement.  After receiving the trigger message (and some
   authorization information) the mobile node starts signaling along the
   new segment and automatically discovers the DCRN.  The message
   travels along the shared segment to the CN and updates the flow
   identifier (if necessary).  The MN might additionally allow the DCRN
   to delete the reservation along the old segment.


      MN                    DCRN                          CN

       <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    +
                           TRIGGER                         |
                                                           |
       ------>----->------>------>------>------>------>    |
          ACTION  (CN is authz; MN on behalf of CN)        |
      +-----------------+       +-----------------+        |
      |  Action:        |       |  Action:        |        |
      |  'create' along)|       |  'update' along)|        |
      |  new segment)   |       |  shared segment)|        | Action
      +-----------------+       +-----------------+        |
       <------<------<-------                              |
      +-----------------+                                  |
      |  Action:        |                                  |
      |  'delete' along)|                                  |
      |  old segment)   |                                  |
      +-----------------+                                  |
      <-----<-----<------<------<------<------<-------     |
                          ACK                              |
                                                           |
                                                           |
      ===============================================>     |
                           Traffic                         +

    Figure 10: CN asks MN to trigger an action (on behalf of the CN)

   The following questions need to be considered:

   -  How should the "delegation" mechanism work such that intermediate
      nodes believe the MN that it is acting on behalf of the CN?

   -  Is it possible to carry this information with the trigger message



Lee, et al.             Expires January 17, 2005               [Page 41]


Internet-Draft          Applicability Statement                July 2004


      from the CN and the MN?

7.1.2.2  CN uses installed state to route message backwards

   As a second variant the CN uses NSIS installed state to route a
   signaling message backwards along the path.  In some rare cases the
   DCNR node might be known already.  In this case it is possible to
   stop the update process along the shared segment and to possibly mark
   installed state along the old segment for deletion.  When the MN
   receives the message it again has to install state along the new
   segment towards the DCOR.  The mobile node might also trigger the
   deletion of resources along the old segment together with this state
   creation (pessimistic delete).  An optimistic delete operation is
   certainly more error prone.


      MN                    DCNR                          CN

   [    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> ] +
   [                     TRIGGER (e.g., MIP)             ] |
                                                           |
        ------<-----<------<------<------<------<------<   |
                   ACTION  (CN is authz)                   |
        +--------------------+  +-----------------+        |
        |  Action:optimistic |  |  Action:        |        |
        |  'delete' along    |  |  'update' along)|        |
        |  old segment)      |  |  shared segment)|        |
        +--------------------+  +-----------------+        |
       >------>------>----------->------>------>-------    |
        +-----------------+            ACK                 |
        |  Action:        |                                | Action
        |  'create' along)|                                |
        |  new segment)   |                                |
        +-----------------+                                |
        <------<------<-------                             |
        +-------------------+                              |
        | Action:pessimistic|                              |
        | 'delete' along)   |                              |
        | old segment)      |                              |
        +-------------------+                              |
                                                           |
       ===============================================>    |
                            Traffic                        +

     Figure 11: CN uses installed state to route message backwards

   Figure 11 raises a few questions:




Lee, et al.             Expires January 17, 2005               [Page 42]


Internet-Draft          Applicability Statement                July 2004


      The security properties of the trigger message need to be
      evaluated.

      It is not always possible to route signaling message backwards
      from the CN to the MN:

      -  state at the new path might not be established (hence the
         signaling message cannot travel backwards)

      -  the signaling message might not reach the MN via the old
         segment.

      In the multi-homing case where the mobile node can be reached via
      more than one path it is possible to execute this exchange.  The
      same might be true for some local repair cases.

      The messages triggered by the MN (namely create state along the
      new segment and the pessimistic 'delete along the old segment)
      still need to be executed on behalf of the CN.  Compared to the
      first variant there might be some room for optimization since the
      first message was transmitted by the CN.

7.1.2.3  MN and CN are authorized

   If we argue that the authorization at the NSLP layer is somehow tight
   to the authorization for certain protocol actions then we also have
   to consider the case where the MN and the CN have to contribute to
   the authorization decision.  This situation appears, for example, in
   the NAT/Firewall signaling case but also in the area of QoS
   reservation where both parties might need to share the cost of a
   reservation.

   If both end hosts are authorized then some signaling message
   exchanges are less difficult since the trigger message does not need
   to include authorization information.  Some problems, however, do not
   disappear such as the session ownership problem and additional
   problems might be caused by certain solution approaches.  Since this
   section does not discuss solutions the reader is referred to the [13]
   draft which lists a few strawman proposals for addressing the session
   ownership problem.

7.1.3  CN as data sender

   In this section we consider the scenarios where the CN acts as a data
   sender.  Figure 2 shows the topology and the participating entities.

7.1.3.1  CN is authorizing entity




Lee, et al.             Expires January 17, 2005               [Page 43]


Internet-Draft          Applicability Statement                July 2004


   This scenario is similar to the one described in Section 7.1.1.  No
   additional problems arise with a scenario where the CN is both data
   sender and also the authorizing entity.  In Figure 8 the CN
   authorizes the UCNR to delete the old segment and to establish a new
   reservation along the new segment.  Furthermore, at the shared
   segment only an update of the flow identifier might be necessary.


       MN                    UCNR                      CN

                                                          + E.g.
       <-----<-----<------<------<------<------<-------   | Create
                           ACTION                         | new
     +-----------------+     |     +-----------------+    | State
     |  Action:        |     |     |  Action:        |    |
     |  'create' along)|     |     |  'update' along)|    |
     |  new segment)   |     |     |  shared segment)|    |
     +-----------------+     |     +-----------------+    |
      <------<------<--------+                            |
     +-----------------+                                  |
     |  Action:        |                                  |
     |  'delete' along)|                                  |
     |  old segment)   |                                  |
     +-----------------+                                  |
                                                          |
      >----->----->------>------>------>------>------>    |
         ACK (along new path)                             |
                                                          |
      <===============================================    +
                            Traffic

               Figure 12: CN as data sender is authorized

   Since the mobile node first detects the route change.  A trigger to
   the CN allows the CN to quickly react on the route change.  There are
   three variants:

   -  The MN sends a trigger to the CN and the CN starts signaling as
      shown in Figure 12.

   -  The MN routes the message back along the reverse path using the
      previously established state along the old route.  This mechanism
      only works if the MN is able to send messages along the old path.
      As a generic mechanism this is not suggested.

   -  An intermediate node act on its own.  This might be possible that
      the UCRN is an entity which participates in the mobility signaling
      (e.g., Mobility Anchor Point (MAP)) exchange.  Depending on the



Lee, et al.             Expires January 17, 2005               [Page 44]


Internet-Draft          Applicability Statement                July 2004


      message exchange it needs to be studied whether the signaling
      message provides sufficient authorization to trigger the NSIS
      exchange.

7.1.3.2  MN is authorizing entity

   In this scenario we consider the case where the CN is the data sender
   but the MN authorizes actions.  The considerations are similar to
   those elaborated in Section 7.1.3 where the MN is the data sender but
   the CN is the authorizing entity.

7.1.4  Multi-homing Scenarios

   Multi-homing scenarios have the property that the more than one path
   belongs to a signaling session.  In Figure 13 the MN uses two
   interfaces to route NSIS message towards the CN.  The two individual
   sessions are tight together with the same session identifier.  The MN
   needs to indicate that both reservations need to be kept alive (and
   the DCRN should not delete a reservation).  At the shared segment
   only a single reservation is stored.

   From an authorization point of view the session ownership issues is
   applicable since the DCRN needs to merge the two reservations into a
   single one along the shared segment.

7.1.4.1  MN as data sender

   This section shows the multi-homing scenario with the MN as a data
   sender.


                         segment 2
                            +---+
            ^>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>V
            ^               +---+             V
         +----+                            +----+          +--+
         | MN |                            |DCNR|>>>>>>>>>>|CN|
         |UCNR|                            |    |>>>>>>>>>>|  |
         +----+                            +----+          +--+
            v               +---+             ^    shared
            v>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>^    segment
                            +---+
                         segment 1

   ===============================================================>
                            Traffic

                Figure 13: Multi-homed MN as data sender



Lee, et al.             Expires January 17, 2005               [Page 45]


Internet-Draft          Applicability Statement                July 2004


   If the MN is the authorizing entity then the session ownership
   problem needs to be solved.  Without solving this type of
   authorization problem it is possible for an adversary to "join" the
   reservation at the shared segment.  Furthermore, it is an open issue
   whether reservation merging is allowed only for cases where one flow
   identifier is used at different interfaces or even with different
   flow identifiers.

   If the CN is the authorizing entity then, again, some message needs
   to be sent from the CN to the MN to trigger the exchange or to route
   the request backwards along the established path.  The MN is
   reachable via the two paths.

   Mobility handling might be smoother since it is possible that only
   one interface experiences an IP address change with all the
   previously discussed implications.

7.1.4.2  CN as data sender

   This section shows the multi-homing scenario with the CN as a data
   sender.  The scenario is simpler (for the CN authorizing case) than
   the one described in Section 7.1 since the signaling message along
   the shared segment travels the previously established path.  It shows
   some similarities with a route change scenario.  At the mobile node
   itself the two paths merge which again leads to a session ownership
   problem.  How should the MN know whether a signaling message with the
   same session identifier hitting a different interface belongs to the
   indicated session authorized by the CN?

   If the MN is the authorizing entity then again communication between
   the end hosts is required as a trigger.  Routing the signaling
   messages in the reverse path might, in some cases, also be possible.


                        segment 2
                           +---+
           v<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<^
           v               +---+             ^
        +----+                            +----+          +--+
        | MN |                            |UCRN|<<<<<<<<<<|CN|
        |DCRN|                            |    |<<<<<<<<<<|  |
        +----+                            +----+          +--+
           ^               +---+             v    shared
           ^<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<v    segment
                           +---+
                        segment 1

   <=============================================================



Lee, et al.             Expires January 17, 2005               [Page 46]


Internet-Draft          Applicability Statement                July 2004


                            Traffic

                Figure 14: Multi-homed CN as data sender


7.1.5  Proxy Scenario

   The proxy scenarios refers to those cases where one of the end hosts
   or even both end hosts are not NSIS aware.  Two security implications
   need to be studied:

   -  First, there is an authorization issue with regard to the NSLP
      application.  For QoS signaling the end host (and the user) has to
      authorize the QoS reservation since the reservation might require
      the user is charged for it.  Since the end host is not NSIS aware
      some other mechanism or protocol needs to be available with
      provides this functionality.  For NAT/Firewall signaling delayed
      authorization assures that both end hosts authorize the packet
      filter creation at their local networks (particularly in case of
      missing trust relationship between intermediate networks).

   -  Second, the authorization issues which relate to the session
      ownership problem also need to be studied.  Since the session
      ownership issues are a related to the signaling participating
      nodes and not to the users or the true end points we think that it
      does not lead to complications.  This is, however, only true if we
      assume that authorization at the NSLP and authorization decisions
      for the signaling message handling is decoupled.

7.1.6  Conclusion

   This section tries to point to some authorization aspects for NSIS
   signaling in a mobility environment.  Performance is important in
   mobility environments but a proper security handling accounts for a
   high percentage of the total performance.  It is important to
   consider this aspect in the analysis of mobility proposals.

   From the scenarios we can observe the following issues:

   -  Signaling in the direction of the data path is simpler than in the
      opposite direction.

   -  There are many similarities between the scenarios where the MN
      acts as a data sender and the scenarios the CN acts as a data
      sender, particularly if multi-homing scenarios are included.

   -  Many authorization problems arise after the initial setup of
      resources along the path.  This problem can be stated as: "Is an



Lee, et al.             Expires January 17, 2005               [Page 47]


Internet-Draft          Applicability Statement                July 2004


      entity allowed to perform the indicated action?" Only a few
      problems are related to the initial signaling message exchange.

   -  If the data sender triggers the signaling message exchange and
      also provides authorization then the complexity can be kept fairly
      low.

   -  NSLP authorization decisions should be treated separately from
      authorization decisions which affect the signaling message
      exchange.

   During the work a few open issues have been selected:

   -  This section does not consider the different message types.

   -  The implication of price determination caused by mobility is
      excluded from this description.

   -  It was tried to keep the description in this section very generic.
      Implications of certain mobility protocols are therefore not
      considered.






























Lee, et al.             Expires January 17, 2005               [Page 48]


Internet-Draft          Applicability Statement                July 2004


8.  Open Issues

   This section highlights some issues which may need further discussion
   in the future.

8.1  Interaction with Other Mobility-Related Protocols

8.1.1  Interaction with Seamoby Protocols

   The NSIS protocol suite should be able to operate independently of
   Seamoby protocols such as Context Transfer Protocol (CTP) and
   Candidate Access Router Discovery (CARD).  However, significant
   performance gains can be achieved if NSIS signaling can interact with
   such protocols.  For example, with the help of CARD and CTP, NSIS
   signaling can quickly re-establish the NSIS state on the new path by
   reducing the state re-setup delay.  However, making use of the CARD
   and CT protocols requires the ability from NTLP/NSLP to do (at that
   stage) off-path signaling on-behalf of the MN; this has implications
   on the authorization of signaling.

   For efficient interaction between NSIS and Seamoby protocols, it is
   desirable to select the optimal NSIS-aware candidate access router
   (CAR) and to transfer NSIS state information fast between the old and
   new access routers to avoid reestablishing the state from the
   beginning.

   If NSIS is not able to interact with CARD/CTP for some reason, it may
   be desirable to discover the CAR by using a CAR discovery mechanism
   which can be an extension to the NTLP peer discovery, and to check
   whether necessary resources are available on the new candidate path
   before handover is completed.  However, this will also cause off-path
   signaling.

8.1.2  Interaction with Local Mobility Management Protocols

   Localized mobility management [LMM] mechanisms reduce the latency in
   mobility management signaling upon Care of Address change.  These
   schemes, such as fast handover [15]  and hierarchical mobile IPv6
   [HMIPv6], complicates NSIS signaling, for example, by associating new
   scoped care-of-addresses for a mobile node, and introducing one or
   more IP-in-IP encapsulated segment(s) in the path traversed by the
   communicating traffic.  The additional CoA and IP-in-IP tunnels have
   implications for both the NTLP and NSLP.

   Whenever a mobility protocol changes characteristics in any place for
   the flow, NSIS signaling should be able to react accordingly as soon
   as possible.  However, an overall coordination/synchronization needs
   further study.



Lee, et al.             Expires January 17, 2005               [Page 49]


Internet-Draft          Applicability Statement                July 2004


8.1.3  State Establishment in Network Mobility Scenarios

   The solutions in the nemo WG will support preservation of route
   aggregation in the network when flows of MNs (and/or fixed hosts) in
   a mobile network are sent to the same CN.  In this case, aggregate
   state installation, e.g., for aggregate reservation (or group
   reservation), should be considered to guarantee resources along the
   aggregated path between the mobile router of the mobile network and
   the CN.  From NSIS perspective, to deal with aggregate state
   installation in such a situation, problems caused by the nested
   mobile network and various scenarios for network mobility, should be
   examined.

8.2  Additional Issues on CRN discovery and Path Update

   The CRN discovery may be initiated before the handover is completed
   for optimal performance.  To do this, an efficient mechanism may be
   needed to find a potential CRN as fast as possible.  In this case,
   seamoby protocols such as CARD and CTP may be involved.

   The state update in the control plane on the shared/common path to
   reflect the changed flow identifier brings issues on the end-to-end
   signaling.  Although the state update does not cause re-processing of
   AAA and admission control, it leads to the signaling overhead.

   When NSIS operates together with HMIPv6 and a MAP is an NSIS-aware
   node, the CRN can be discovered in the local region.  How to discover
   the CRN in such an environment is an open question.

8.3  Support for the Ping-Pong Type of Movement

   NSIS signaling to release resources on the old path should be done as
   quickly as possible to avoid waste of resources.  When the route
   change occurs in the mobile access network where resources are
   scarce, it is inefficient to wait until the soft-state timer expires.
   However, immediate release of resources along the old path may not be
   desirable in some cases.  For example, in case of a ping-pong type of
   movement, the immediate release of state on the old path should be
   avoided so that resources along the old path can be reused after a
   short period of time.  The current QoS-NSLP draft has defined
   NO-REPLACE flag which can be used to support such a ping-pong type of
   movement.

8.4  When both end-hosts are mobile

   It is possible that both end hosts are mobile devices.  Therefore,
   signaling between two mobile devices should be considered.  Until
   now, we are assuming a non-mobile correspondent node.  Problems can



Lee, et al.             Expires January 17, 2005               [Page 50]


Internet-Draft          Applicability Statement                July 2004


   show up if both devices start to signal at the same time.

8.5  Bi-directional State Establishment

   Although the bidirectional data flows have the same end points, the
   paths in the two directions do not need to be the same.  Therefore,
   the CRN of the downstream path may be different from that of the
   upstream path in mobile scenarios.  As a matter of course, the
   Session ID in the downstream reservation should be different from
   that of the upstream reservation.  If the routes (i.e., upstream and
   downstream paths) are symmetric, an NSIS single signaling message can
   be used to install state in both directions.  If the routes are
   asymmetric, an NSIS signaling message from the originator (e.g., MN
   or CN) can trigger an independent signaling message from the
   responder.

   Bi-directional reservations can be considered as a special case of
   fate sharing.  The current QoS-NSLP has defined BOUND_SESSION_ID
   which can be used to relate bidirectional flows to each other.  Since
   BOUND_SESSION_ID can also be used to support aggregate reservation,
   care should be taken when both the bidirectional reservation and the
   aggregate reservation are supported at the same time.

8.6  Priority Reservation

   The QoS-NSLP draft [11] defines a Priority object in the QSPEC
   template.  In mobile environments, priority of certain signaling
   messages over others may be required when a message loss during call
   set-up is less harmful than during handover.  Priority of certain
   reservations over others may be required when QoS resources are
   oversubscribed.  In that case, existing reservations may be preempted
   in other to make room for new higher-priority reservations e.g., to
   support handover.  Although supportfor the reservation priority is a
   QoS model specific issue, it may be useful to support a call which
   needs a certain amount of resources immediately after handover of an
   MN.

8.7  Aggregation of End-to-End Flows in Mobile Environments

   Session binding defined in the QoS-NSLP draft [11] can be used to
   support aggregation.  An aggregated session may have a different flow
   ID from the end-to-end message sent or received by an MN.  Including
   the BOUND_SESSION_ID object in a session indicates a dependency
   relation.  By default, a session that is bound to another session
   with the BOUND_SESSION_ID object shares fate with it.  In mobile
   environments where a route change due to mobility occurs, an
   end-to-end flow may need to be bound to a new aggregate flow which is
   different from the current one due to route change.  Therefore, it



Lee, et al.             Expires January 17, 2005               [Page 51]


Internet-Draft          Applicability Statement                July 2004


   may be desirable to re-setup session binding as quickly as possible.


















































Lee, et al.             Expires January 17, 2005               [Page 52]


Internet-Draft          Applicability Statement                July 2004


9.  References

9.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

9.2  Informative References

   [2]   Schulzrinne, H., "GIMPS: General Internet Messaging Protocol
         for Signaling", draft-ietf-nsis-ntlp-02 (work in progress),
         June 2004.

   [3]   Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
         3753, June 2004.

   [4]   Hancock, R., "Next Steps in Signaling: Framework",
         draft-ietf-nsis-fw-06 (work in progress), July 2004.

   [5]   Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
         "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
         Specification", RFC 2205, September 1997.

   [6]   Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
         (NSLP)", draft-ietf-nsis-nslp-natfw-02 (work in progress), May
         2004.

   [7]   Fessi, A., "Security Threats for the NAT/Firewall NSLP",
         draft-fessi-nsis-natfw-threats-00 (work in progress), May 2004.

   [8]   Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security
         Problems", draft-tschofenig-nsis-natfw-security-problems-00
         (work in progress), July 2004.

   [9]   "IP Mobility Support for IPv4, revised",
         draft-ietf-mip4-rfc3344bis-00 (work in progress), July 2004.

   [10]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [11]  Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
         Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03
         (work in progress), May 2004.

   [12]  Lee, S., "Mobility Functions in the QoS-NSLP",
         draft-lee-nsis-mobility-nslp-01 (work in progress), November
         2003.




Lee, et al.             Expires January 17, 2005               [Page 53]


Internet-Draft          Applicability Statement                July 2004


   [13]  Tschofenig, H., "Security Implications of the Session
         Identifier", draft-tschofenig-nsis-sid-00 (work in progress),
         June 2003.

   [14]  Tschofenig, H., "NSIS Authentication, Authorization and
         Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 (work
         in progress), March 2003.

   [15]  Dommety, G., "Fast Handovers for Mobile IPv6",
         draft-ietf-mobileip-fast-mipv6-05 (work in progress), October
         2002.


Authors' Addresses

   Sung-Hyuck Lee
   SAMSUNG Advanced Institute of Technology
   San 14-1, Nongseo-ri, Giheung-eup
   Yongin-si, Gyeonggi-do  449-712
   KOREA

   Phone: +82 31 280 9585
   EMail: starsu.lee@samsung.com


   Seong-Ho Jeong
   Hankuk University of FS
   89 Wangsan Mohyun
   Yongin-si, Gyeonggi-do  449-791
   KOREA

   Phone: +82 31 330 4642
   EMail: shjeong@hufs.ac.kr


   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   Munich,   81739
   Germany

   Phone:
   EMail: Hannes.Tschofenig@siemens.com


   Xiaoming Fu
   University of Goettingen
   Telematics Group



Lee, et al.             Expires January 17, 2005               [Page 54]


Internet-Draft          Applicability Statement                July 2004


   Lotzestr. 16-18
   Goettingen  37083
   Germany

   EMail: fu@cs.uni-goettingen.de


   Jukka Manner
   Department of Computer Science University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   HELSINKI,   FIN-00014
   Finland

   Phone: +358-9-191-44210
   EMail: jmanner@cs.helsinki.fi


   Roland Bless
   Institute of Telematics, Universitaet Karlsruhe (TH)
   Zirkel 2
   76128 Karlsruhe
   Germany
   EMail: bless@tm.uka.de


   Paulo Mendes
   DoCoMo Communications Laboratories Europe GmbH
   Landsberger Str. 312
   80687 Munich, Germany

   Voice:  +49-89-56824-226
   Fax:    +49-89-56824-300
   E-mail: mendes@docomolab-euro.com


   Robert Hancock
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom

   Voice:  +44-1794-833601
   Fax:    +44-1794-833434
   E-Mail: robert.hancock@roke.co.uk











Lee, et al.             Expires January 17, 2005               [Page 55]


Internet-Draft          Applicability Statement                July 2004


Appendix A.  Acknowledgements

   The authors would like to thank Jongho Bang, Cornelia Kappler,
   Byoung-Joon Lee, Henning Schulzrinne, and Charles Q.  Shen for
   significant contributions in four earlier drafts and the previous
   draft.













































Lee, et al.             Expires January 17, 2005               [Page 56]


Internet-Draft          Applicability Statement                July 2004


Appendix B.  Anticipated Handover

   With an anticipated handover, state in the new path can be set in
   advance, which means before the MN gets any layer 3 connectivity to
   the new access router.  Anticipated handovers require the discovery
   of candidate access points or access routers (CARD may help), and the
   ability of the MN to trigger the signaling to set up the new path via
   the old access router.  If the sender is moving, the old access
   router may directly signal to the candidate access router.  However,
   the new path up to/from the CRN must be also figured out which is
   especially not that easy in case the MN is acting as receiver.  In a
   QoS scenario, an anticipated handover checks resource availability
   along a potential new path before an MN actually changes its point of
   attachment.  Therefore, if there are not enough resources available
   along the new path an unsuccessful handover (or period of QoS
   degradation) can be avoided and the MN can stay connected to its
   current point of attachment (if possible).

   Anticipated handovers offer mainly two advantages:

   -  reducing seamless handover latency, because most signaling to set
      up resources in the new path is carried out in advance.

   -  avoiding unsuccessful handovers or unnecessary periods of QoS
      degradation.

   The first point is especially important in inter-domain handover
   scenarios where signaling procedures will take longer and additional
   time consuming authentication procedures may be necessary.  On the
   other hand, the higher resource consumption may be considered as
   disadvantage if resources along the new path could be reserved
   successfully, but the old path is still used (dual reservation after
   split or merge CRN).  However, an indication for handover completion
   (thereby triggering release of the obsolete path) may help to keep
   this period as short as possible.

   To perform an anticipated handover, MNs do not have to be
   multi-homed.  However, anticipated handovers may involve some kind of
   NSIS proxy [2] on the new access network to signal on the new path on
   behalf of the MN.  If we assume that the end-to-edge communication is
   done between the MN and its access router, some study is required to
   determine how to signal between the MN's current access router and
   the NSIS proxy in the new access network, e.g., how to discover the
   most suitable NSIS proxy, and to establish a communication between
   access networks.  The latter issue involves out-of-path signaling.

   Moreover, in some anticipated signaling scenarios, NSIS signaling
   cannot be triggered by the mobility protocol, which requires some



Lee, et al.             Expires January 17, 2005               [Page 57]


Internet-Draft          Applicability Statement                July 2004


   study about other possible triggers, such as:

   -  Cross-layer triggering.  For instance, the layer-2 mechanism can
      give some information about a possible movement.

   -  Context-awareness triggering.  For instance, information about a
      lower traffic load in some neighbor access networks can trigger
      the establishment of state in a new path.

   It follows a conceptual description of a signaling exchange of an
   anticipated handover for resource reservation.

   In this scenario, we assume the sender is moving.

   -  The MN must discover candidate access points or routers and signal
      its current AR to initiate an anticipated handover.

   -  The current AR has to discover its corresponding signaling peer,
      usually the candidate AR.  This may be accomplished with similar
      techniques like CARD, e.g., by learning addresses from moving
      nodes.  Different domains may exchange corresponding information
      due to roaming agreements.

   -  A new signaling association must be setup between the current AR
      and the candidate AR.

   -  The current AR signals a request for an anticipated handover to
      the candidate AR.  The candidate AR sets up a new reservation
      state along the new path downstream.  The session id should be
      used in order to allow the crossover node CRN to discover the
      handover process.  In case reservation parameters are not changed,
      signaling can stop at the CRN, which will then generate a response
      that is sent back to the candidate AR.  Otherwise signaling along
      the unchanged path may also be required in order to prepare the
      intended changes.

   -  The candidate AR forwards the result of the new path setup to the
      current AR.  The new reservation should be removed automatically
      by using timers if the handover is not performed by the MN within
      a certain period (it never shows up at the CAR).

   -  The candidate AR forwards the result of the new path setup to the
      current AR.  The new reservation should be removed automatically
      by using timers if the handover is not performed by the MN within
      a certain period (it never shows up at the CAR).






Lee, et al.             Expires January 17, 2005               [Page 58]


Internet-Draft          Applicability Statement                July 2004


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 (2004).  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.




Lee, et al.             Expires January 17, 2005               [Page 59]