IETF Next Steps in Signaling                                 S. Lee, Ed.
Internet-Draft                                               Samsung AIT
Expires: August 21, 2005                                        S. Jeong
                                                                    HUFS
                                                           H. Tschofenig
                                                              Siemens AG
                                                                   X. Fu
                                                     Univ. of Goettingen
                                                               J. Manner
                                                       Univ. of Helsinki
                                                       February 20, 2005


    Applicability Statement of NSIS Protocols in Mobile Environments
        draft-ietf-nsis-applicability-mobility-signaling-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 August 21, 2005.

Copyright Notice

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

Abstract

   The mobility of an IP-based node affects routing paths, and as a
   result, can have a significant effect on the protocol operation and



Lee, et al.             Expires August 21, 2005                 [Page 1]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   state 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.  Requirements Notation and Terminology  . . . . . . . . . . . .  4
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  7
     3.1   General problems . . . . . . . . . . . . . . . . . . . . .  7
     3.2   Mobility-Related Issues with NSIS Protocols  . . . . . . .  9
       3.2.1   NTLP-Specific Problems . . . . . . . . . . . . . . . .  9
       3.2.2   QoS-NSLP-Specific Problems . . . . . . . . . . . . . . 10
       3.2.3   NAT/FW NSLP-Specific Problems  . . . . . . . . . . . . 11
       3.2.4   Common problems related to both NTLP and NSLP  . . . . 11
   4.  Basic Operations for Mobility Support  . . . . . . . . . . . . 12
     4.1   Route changes caused by mobility . . . . . . . . . . . . . 13
     4.2   CRN discovery  . . . . . . . . . . . . . . . . . . . . . . 15
       4.2.1   Possible approaches for CRN discovery  . . . . . . . . 15
       4.2.2   The identifiers for CRN discovery  . . . . . . . . . . 16
       4.2.3   The procedures of CRN discovery  . . . . . . . . . . . 17
     4.3   Path update  . . . . . . . . . . . . . . . . . . . . . . . 18
       4.3.1   State setup and update . . . . . . . . . . . . . . . . 19
       4.3.2   State teardown . . . . . . . . . . . . . . . . . . . . 21
   5.  Applicability Statement  . . . . . . . . . . . . . . . . . . . 21
     5.1   Support for macro mobility-based scenarios . . . . . . . . 22
       5.1.1   Implications to Mobile IP-related scenarios  . . . . . 22
         5.1.1.1   Mobile IPv4-specific issues  . . . . . . . . . . . 24
         5.1.1.2   Mobile IPv6-specific issues  . . . . . . . . . . . 26
     5.2   Multihoming scenarios  . . . . . . . . . . . . . . . . . . 28
       5.2.1   Overview . . . . . . . . . . . . . . . . . . . . . . . 28
       5.2.2   Examples of NTLP/NSLP support for mobility . . . . . . 28
     5.3   QoS performance considerations in mobility scenarios . . . 29
     5.4   Support for Ping-Pong type handover  . . . . . . . . . . . 31
     5.5   Peer failure scenarios . . . . . . . . . . . . . . . . . . 32
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
     6.1   MN as data sender  . . . . . . . . . . . . . . . . . . . . 34
       6.1.1   MN is authorizing entity . . . . . . . . . . . . . . . 34
       6.1.2   CN is authorizing entity . . . . . . . . . . . . . . . 36
         6.1.2.1   CN asks MN to trigger action (on behalf of the
                   CN)  . . . . . . . . . . . . . . . . . . . . . . . 36
         6.1.2.2   CN uses installed state to route message
                   backwards  . . . . . . . . . . . . . . . . . . . . 37
         6.1.2.3   MN and CN are authorized . . . . . . . . . . . . . 39
       6.1.3   CN as data sender  . . . . . . . . . . . . . . . . . . 39
         6.1.3.1   CN is authorizing entity . . . . . . . . . . . . . 39
         6.1.3.2   MN is authorizing entity . . . . . . . . . . . . . 40
       6.1.4   Multi-homing Scenarios . . . . . . . . . . . . . . . . 40



Lee, et al.             Expires August 21, 2005                 [Page 2]


Internet-Draft         NSIS Signaling in Mobility          February 2005


         6.1.4.1   MN as data sender  . . . . . . . . . . . . . . . . 41
         6.1.4.2   CN as data sender  . . . . . . . . . . . . . . . . 41
       6.1.5   Proxy Scenario . . . . . . . . . . . . . . . . . . . . 42
       6.1.6   Conclusion . . . . . . . . . . . . . . . . . . . . . . 43
   7.  Change History . . . . . . . . . . . . . . . . . . . . . . . . 44
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 45
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 45
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
       Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47
       Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 47
   A.  Generic Route Changes  . . . . . . . . . . . . . . . . . . . . 47
       Intellectual Property and Copyright Statements . . . . . . . . 49






































Lee, et al.             Expires August 21, 2005                 [Page 3]


Internet-Draft         NSIS Signaling in Mobility          February 2005


1.  Introduction

   The mobility of IP-based nodes incurs route changes, usually at the
   edge of the network.  Route changes 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 identifiers.  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, and
   each specific service has its own NSLP protocol. This draft also
   discusses how the NSIS protocols should work in various mobility
   scenarios.

   This draft mainly discusses the operations 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.  More complex scenarios and issues on interworking with
   various mobility-related protocols, such as Seamoby and local
   mobility management protocols, are left for future work.



2.  Requirements Notation and 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.

   (1) Downstream

      The direction from a data sender towards the destination.

   (2) Upstream

      The direction from a data destination towards the sender.

   (3) Crossover Node (CRN)



Lee, et al.             Expires August 21, 2005                 [Page 4]


Internet-Draft         NSIS Signaling in Mobility          February 2005


      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 the signaling states, flow directions, mobility
      management types, and generic 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
            corresponding signaling flows begin to merge or split after
            route changes or 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 or mobility.

            NSIS CRN is an NTLP CRN and/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 for the path update.

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

            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 (UCRN), after a handover, is the node
               closest to the data sender from which the state
               information towards the data sender begins to diverge.

               Downstream CRN (DCRN), 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.




Lee, et al.             Expires August 21, 2005                 [Page 5]


Internet-Draft         NSIS Signaling in Mobility          February 2005


            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 14 of Appendix, 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 the mobility management point of view, mobility CRN is the
         node where the old and new paths (physically) merge.  Note that
         in general, the mobility CRN may be different from the NSLP CRN
         or NTLP CRN.

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

   (4) Path Update and Local Repair

      Path Update is the procedure for the re-establishment of NSIS
      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 data 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 data sender, the Path Update is
         triggered by an NI on the new path (e.g., an MN, a mobility
         agent, or an AR).

      In case of route changes, the update of NSIS state on the common
      path is not required due to no change of flow identifiers, which
      makes the NSIS signaling the localized.  Especially, in mobility



Lee, et al.             Expires August 21, 2005                 [Page 6]


Internet-Draft         NSIS Signaling in Mobility          February 2005


      scenarios, if the NSIS signaling interacts with localized mobility
      management protocols (e.g., HMIPv6), the Path Update can be
      localized within the access network.

   (5) Dead Peer Discovery (DPD)

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



3.  Problem Statement

   IP mobility in its simplest form only includes route changes.  The
   various protocols that seek to support the mobility of end hosts may
   use some techniques to reach their goals.  This section identifies
   problems caused by mobility, which may have a significant impact on
   the operations of NSIS protocols.

3.1  General problems

   The general problems caused by mobility are as follows.

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

   (2) Latency of route changes

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

   (3) 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 the
      routing headers to define explicit routes, which diverts the
      traffic from an expected path, too.

   (4) IP-in-IP encapsulation




Lee, et al.             Expires August 21, 2005                 [Page 7]


Internet-Draft         NSIS Signaling in Mobility          February 2005


      Mobility protocols may use IP-in-IP encapsulation on the segment
      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 addresses
      differ from the values in the original user data packet.  The same
      considerations apply if the signaling packets are encapsulated,
      too.

   (5) Ping-pong type handover

      Signaling protocols should remove states quickly along the old
      path to 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, so the prompt removal of
      state along the old path causes the state to be re-established
      soon again, and therefore it adds overhead.

   (6) 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.  Therefore,
      the Path Update needs to be handled independently for upstream and
      downstream flows, including the discovery of upstream and
      downstream CRNs.

   (7) State identification problem

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

   (8) 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 changes), the double reservation
      problem occurs.  Although the state on the old and common paths
      can be torn down by the timeout of soft state, the refresh timer
      value may be quite long (e.g., 30s as a default value in RSVP).
      This problem results in the waste of resources and call blocking.

   (9) End-to-end signaling problem




Lee, et al.             Expires August 21, 2005                 [Page 8]


Internet-Draft         NSIS Signaling in Mobility          February 2005


      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 increased signaling overhead, which affects overall
      performance of signaling protocols.  The long state setup delay
      may ultimately give rise to the service blackout or degradation of
      multimedia services in mobile environments.

   (10) Identification of the crossover node

      When a handover at the edge of network has happened, in the
      typical case, only a part of the end-to-end path used by the data
      packets changes.  In this situation, the CRN plays a central role
      in managing the establishment of the new signaling application
      state, and removing any useless state.

   (11) Key exchange

      When a handover happens, nodes on the new path must be able to
      verify the signaling messages of the MN, and vice versa.  For
      example, if signaling messages are encrypted on a hop-by-hop
      basis, the new access router should be able to continue the
      message encryption and decryption with the incoming MN.

   (12) AA Issues

      The Path Update procedure may be initiated by the MN, the CN, or
      even nodes within the network (e.g., MAP/GPA in HMIP).  This Path
      Update on behalf of the MN raises authentication and authorization
      issues.

3.2  Mobility-Related Issues with NSIS Protocols

   Considering the issues identified in Section 3.1, this section mainly
   discusses the concerns that arise for the NSIS protocols.

3.2.1  NTLP-Specific Problems

   (1) Interfaces between Mobile IP and NSIS protocols

      To continue to support the existing NSIS state for a session, the
      NTLP protocol should be immediately involved in the CRN discovery
      and Path Update after a mobility event (e.g., handover) happens.
      In this situation, is it necessary to define a Mobile IP-specific
      API in NSIS? Should a common triggering mechanism between routing
      and NSIS processes be defined to monitor the operations of other
      mobility protocols and trigger a relevant event accordingly?



Lee, et al.             Expires August 21, 2005                 [Page 9]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   (2) Localized Path Update

      NSIS protocols need to make the Path Update localized to enhance
      and performance parameters such as signaling setup delay, resource
      utilization, and in this case, a few issues on the interaction
      between the micro-mobility management protocols and NTLP protocols
      arise.  For example, when interacting with HMIP, how is the Path
      Update performed with scoped signaling messages within the access
      network under the control of MAP?

3.2.2  QoS-NSLP-Specific Problems

   (1) Invalid NR problem

      If the old AR is the last node on the old signaling path due to
      the MNí¯s handover, its QoS-NSLP may trigger an error message to
      indicate that QoS-NSLP messages cannot be forwarded any further.
      This error message may mistakenly cause the removal of the state
      on the obsolete path, which is called the í«invalid NR problemí¯
      [12].

   (2) Priority of signaling messages

      Some messages of QoS-NSLP need to be used to check the
      availability of resources in a new access network to ensure that
      the moving MN gets the required QoS.  for example, the Query
      message can be used for that purpose.  In this case, should a high
      priority be given to the signaling message to expedite the
      process?

   (3) Optimal refresh timer value for mobile environments

      In the situation where handover occurs frequently, the maintenance
      of signaling state on the old path for a long time is not
      necessary.  The QoS-NSLP needs to choose appropriate refresh
      intervals depending on the network environment (e.g., access
      network, or core network).

   (4) Athorization-related issues with teardown

      When tearing down the obsolete state after CRN discovery, can
      the teardown message be sent toward the opposite direction to
      the state initiating node?  This leads to an
      authorization problem because a node which does not initiate
      signaling for establishing the QoS-NSLP state may delete the
      state.

   (5) Peering agreement issue



Lee, et al.             Expires August 21, 2005                [Page 10]


Internet-Draft         NSIS Signaling in Mobility          February 2005


      In the inter-domain handover scenarios, how is the peering
      agreement established for aggregate reservation and authorization
      to support individual sessions?

   (6) Dead peer discovery

      A dead peer can occur either because a link or a network node
      failed, or because the MN moved away without informing QoS-NSLP
      (it is recommended to link mobility and NSIS signaling such that
      this does not happen).  How can dead peers be detected in a fast
      and efficient manner?

3.2.3  NAT/FW NSLP-Specific Problems

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

   (1) Update of firewall rules and NAT bindings

      When an IP address changes, 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 an NSIS-aware data sender (located behind
      a firewall), data packets with a new source IP address are most
      likely dropped at the firewall.  If a data receiver (located
      behind a NAT) changes its IP address, incoming packets are
      rewritten at the NAT and forwarded to the wrong IP address.  In
      this case, the QoS-NSLP might 'only' temporarily experience a
      weaker QoS if the installed flow identifier is not up-to-date.

   (2) Re-use of NAT/FW-NSLP's old state

      Although NSIS states can be released by applying the soft-state
      principle, mobility can leave states (such as firewall pinholes)
      in place for some time.  Since the NAT/FW-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 due to the capability of IP
      spoofing as identified in [7], and the main problem is the usage
      of non-cryptography-based IP address filters.  Therefore, the
      teardown of the NAT/FW-NSLP state in mobility scenarios needs to
      be considered in the fashion different from that of QoS-NSLP
      state.

3.2.4  Common problems related to both NTLP and NSLP




Lee, et al.             Expires August 21, 2005                [Page 11]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   (1) CRN discovery-related issues

      Which layer should be responsible for the CRN discovery, NTLP
      (GIMPS) or NSLP (QoS-NSLP)? Although the QoS-NSLP can detect the
      change of signaling path and discover the CRN by keeping track of
      SII, the CRN discovery at the NTLP layer may be preferred to at
      the QoS-NSLP.  However, is there any advantage if NSLP discovers
      the CRN?

   (2) CRN discovery and Path Update on the IP-tunneling path

      Considering interworking with IP-tunneling, NTLP needs to consider
      how to perform CRN discovery and Path Update on the IP-tunneling
      path.  For example, whether the GIMPS peer discovery can be used
      for the CRN discovery on the tunnel should be discussed further.
      Additionally, after route optimization, when to remove the
      tunneling segment on the signaling path and/or how to tear down
      the state via interworking with the IP-tunneling operation should
      also be discussed.

   (3) Issues on API between NTLP and NSLP

      In mobile environments, mobility-related information for Path
      Update can be exchanged through the API specified in [2].  Based
      on the information, the involved NSLP can initiate Path Update by
      sending necessary signaling messages through the API.  However,
      what information should be sent from GIMPS to an NSLP to inform of
      the route changes needs to be discussed further.  The details on
      the API can be an implementation issue.

   (4) Multihoming-related issues

      A host that is an initiator or responder of signaling messages may
      be multi-homed in mobile environments.  NSIS signaling protocols
      should use such multi-homed interfaces to perform load-balancing
      and load-sharing, or to support seamless mobility.  However, which
      NxLP functionality is required in various multihoming scenarios
      (e.g., load balancing, bi-casting, etc.) is an open question.  An
      overall coordination for interworking between the NSIS protocol
      and multihoming capability needs to be discussed further.



4.  Basic Operations for Mobility Support

   In this section, we mainly discuss the basic operations of NSIS
   signaling protocols needed after route changes caused by mobility.
   The basic operations include how to discover an appropriate CRN and



Lee, et al.             Expires August 21, 2005                [Page 12]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   how to perform the Path Update according to the direction of data
   flows.  The procedures for CRN discovery (explained in Section 4.2.3)
   can be applied in the same way for both the generic route changes and
   mobility.  However, the Path Update for mobility is different from
   that for the generic route changes as address in Section 2.

4.1  Route changes caused by mobility

   The route change caused by mobility occurs due to the change of the
   network attachment point.  It causes divergence (or convergence)
   between the old path where the NSIS state has already been installed
   and the new path where data forwarding will actually happen.

   Although the mobility may be considered similar to the generic route
   changes, the main difference is that the Message Routing Information
   (MRI: e.g., flow identifier) may not change after the route changes
   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 change brings on the change of signaling topology, and this
   causes differences between the types of route changes (e.g., the
   generic route changes or mobility) (see Appendix).  The mobility
   generally creates a common path, an old path, and a new path, and the
   old and new paths converge or diverge depending on the direction of
   each signaling flow as shown in Figure 1.


                                Old path
              +--+        +-----+
    original  |MN|------> |OAR  | ----------V
              |  |        |NSLP1|
    address   +--+        +-----+           V   common path
               |             K            +-----+   +-----+    +--+
               |                          |     |---|NSLP1|--->|CN|
               |                          |NSLP2|   |NSLP2|    |  |
               v                New path  +-----+   +-----+    +--+
              +--+        +-----+           ^ M        N
     New CoA  |MN|------> |NAR  |-----------^      >>>>>>>>>>>>
              |  |        |NSLP1|                  ^
              +--+        +-----+                  ^
                             L                     ^
                  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
                         (Binding process)
     ====(downstream signaling followed by data flows) ======>

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



Lee, et al.             Expires August 21, 2005                [Page 13]


Internet-Draft         NSIS Signaling in Mobility          February 2005


      mobility

                               Old path
              +--+        +-----+
    original  |MN|<------ |OAR  | ---------^
    address   |  |        |NSLP1|          ^
              +--+        +-----+          ^   common path
               |             C            +-----+   +-----+    +--+
               |                          |     |<---|NSLP1|---|CN|
               |                          |NSLP2|   |NSLP2|    |  |
               v                New path  +-----+   +-----+    +--+
              +--+        +-----+          V B        A
     New CoA  |MN|<------ |NAR  |----------V      >>>>>>>>>>>>
              |  |        |NSLP1|                  ^
              +--+        +-----+                  ^
                             D                     ^
                                                   ^
                  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
                        (Binding process)

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

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


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

   These topological changes caused by mobility make the NSIS state
   established on the old path useless and therefore it should be
   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.

   NSIS signaling should be localized when route changes (including
   mobility) occur to minimize the impact on the seamless service and to
   improve signaling scalability, This localized signaling procedure is
   referred to as Path Update (see the Terminology section).  In mobile
   environments, the NSLP/NTLP needs to limit the scope of signaling
   information only to the affected section of the signaling path
   because the path in the wireless access network usually changes only
   partially.

   One of the most appropriate nodes to perform the Path Update is the
   CRN where the old and new session paths meet logically.  Therefore,
   the CRN discovery can be a crucial element to alleviate the double
   reservation and end-to-end signaling problems identified in Section
   3.1.



Lee, et al.             Expires August 21, 2005                [Page 14]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   The NTLP (of a node experiencing a topological change) should detect
   the route change through the various mechanisms described in [4] at
   the transport level and trigger the necessary operation of the
   relevant NSLP.  For example, the NSLP should initiate NSIS state
   re-establishment (i.e., QoS re-establishment) along the new path and
   the update or removal of the existing state at the signaling
   application level.

4.2  CRN discovery

4.2.1  Possible approaches for CRN discovery

   The approaches for CRN discovery can be divided into two classes
   according as which layer is responsible for the CRN discovery
   (addressed in Section 3.2.2), 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 either NTLP or NSLP layer.  For the CRN discovery at the NSLP
   layer, the information contained in NSLP signaling messages sent from
   the NSIS initiator (NI) can be used.  For example, the NSLP of an
   NSIS node can determine whether the node is a CRN by comparing the
   Source Identification Information (SII) contained in the incoming
   signaling message to the one stored previously in the node.

   It is also possible to discover the CRN at the NTLP layer since NTLP
   is responsible for detecting the path change of data (or signaling)
   flow (the route changes may easily be detected at the NTLP level
   rather than at the NSLP).  The 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
   identifiers, so the signaling application can be identified at the
   NTLP level.  In the connection mode of NTLP, when NTLP establishes a
   messaging association between two adjacent peers, two 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 an NSLP-aware
   node which has an involved signaling application.

   There can also be two different approaches for the CRN discovery
   according as whether the discovery is coupled with signaling message
   or not: coupled approach and uncoupled approach.  In the coupled
   approach, the signaling to install the NSIS state along the new path
   or update the state along the common path is performed simultaneously
   with the CRN discovery.  In the uncoupled approach, the signaling for
   the Path Update is performed after the CRN discovery is completed.
   These two approaches may have some effect on security aspect.



Lee, et al.             Expires August 21, 2005                [Page 15]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   Generally, the coupled approach would be preferred to the uncoupled
   approach to reduce the delay for signaling setup.  Note that the 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 the CRN
   discovery at the NTLP level: session identifier (SID), flow
   identifier (MRI), and signaling application identifier (NSLP_ID)
   related to message routing state [2], and NSLP branch identifier
   (NSLP_Br_ID) which identifies an NSIS signaling branch.

   The SID 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 a
   topological change to the CRN and therefore it represents that the
   state along the common path should be updated.

   The NSLP_ID is used to refer to the corresponding NSLP at the GIMPS
   level, and it helps to discover an appropriate NSLP CRN using the
   GIMPS peer discovery message.

   As a virtual branch identifier, the NSLP_Br_ID can be used to
   establish or delete NSIS associations between NSIS peers.  It can
   also be used as an identifier to determine the CRN at the GIMPS
   layer.  The NSLP_Br_ID may include the location information of NSIS
   peer nodes with the corresponding NSLP ID obtained by the procedure
   of GIMPS message association.  For instance, as shown in Figure 2,
   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_Br_ID for NSLP
   1 toward node D and increases the counter of NSLP_Br_ID to locally
   distinguish each virtual interface identifier between adjacent NSLP
   peers: the corresponding NSLP_Br_ID is 1-D-#2; 1, D, and #2 indicate
   an NSLP_ID-flow, a flow direction (Downstream or Upstream), and a
   value of the branch counter, respectively.  Note that the NSLP_Br_ID
   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 physical merging point of the old path and the new path is not an
   NSLP CRN as shown in Figure 2 (a).








Lee, et al.             Expires August 21, 2005                [Page 16]


Internet-Draft         NSIS Signaling in Mobility          February 2005


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

   (a) 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|          | 1-U-#1|
    |Coupled; Flow ID =|       |       |  K-N     |          |       |
    |  {IP-#X, IP-#V,  |       |       |Pointer to|          | 1-U-#2|
    | protocol, ports} |       |       |  L-N     |          |       |
    |                  |       |       |          |    O     | 1-D-#1|
    |   Method = Path  |       |       |          |          |       |
    |Coupled; Flow ID =| 0x1234| NSLP2 |          | Pointer  | 2-D-#1|
    |  {IP-#X, IP-#V,  |       |       |          | to N-R   |       |
    | protocol, ports} |       |       |    M     |          | 2-U-#1|
    +------------------+-------+-------+----------+----------+-------+

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

      Figure 2. Routing state table and NSLP branch ID

   Optionally, the Mobility identifier as an object form can also be
   used to inform of the handover of an MN or a route change [12] and
   therefore to expedite the CRN discovery.  For example, the
   mobility_event_counter (MEC) field in the mobility object can be used
   to detect the latest handover event to avoid any confusion about
   where to send the confirmation message.  Therefore, the Mobility
   identifier is useful to discover the most appropriate CRN.

4.2.3  The procedures of CRN discovery

   When a mobility event occurs, the CRN can be recognized by comparing



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


Internet-Draft         NSIS Signaling in Mobility          February 2005


   the previously stored identifiers with the identifiers included in
   the incoming NSIS 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 2 (a) and (b))
   should be checked to determine if the current node is CRN:

   -  Whether the same NSLP_ID exists

   -  Whether the corresponding CRN has already been discovered

   -  Whether the same SID and MRI exist

   -  Whether the NSLP_Br_ID has been changed: for example, as shown in
      Figure 3 (a), for NSLP 1 it has been changed to 1-D-#2 from
      1-D-#1.

   -  Optionally, the Mobility identifier can be examined, if any.  For
      example, the MEC field of the Mobility object can be used to find
      out which message has been sent due to the latest handover.

   The CRN discovery can be further divided into the UCRN discovery and
   DCRN discovery according as 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 undergoes a handover, the MN begins
      to transmit signaling messages toward a CN in the downstream
      direction.  If an NSLP-aware node recognizes that the session
      paths logically converge at that node, and then the node
      determines that it is the DCRN; the procedure for CRN discovery
      corresponds to the creation of the routing table of node N as
      shown in Figure 2 (b).

   -  When an MN (as a sender) undergoes handover, the UCRN can be
      discovered for the upstream flow.  The UCRN should be the node
      (closest to the MN) where the signaling flow begins to logically
      diverge: it corresponds to the creation of the routing table of
      node A as shown in Figure 2 (a).  Since the UCRN is determined
      according as whether the outgoing path diverges or not, the UCRN
      discovery is more complex than the DCRN discovery.

4.3  Path update

   The CRN discovery procedures are different depending on the direction
   of signaling flows in mobility scenarios, and therefore the
   procedures for Path Update also are different according to the
   direction of signaling flow.  The Path Update can be divided into
   upstream Path Update and downstream Path Update.  For both types of
   Path Update, the NSIS protocol may need to interact with various



Lee, et al.             Expires August 21, 2005                [Page 18]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   mobility signaling protocols, if any (during or posterior handover)
   to obtain performance gains (e.g., through fast re-establishment of
   the NSIS state on the new path).  For this purpose, NSIS may also
   need to monitor the movement of the MN through several methods [4].
   In this section, we assume that an MN is a data sender.

4.3.1  State setup and update

   Before initiating the Path Update, the MN or CN needs to have its
   session ownership by the procedures for authentication and
   authorization and to check the availability of resources on the new
   path.  In case of QoS-NSLP, the Query message can be used to find the
   availability of resources in the new access network.  It may be
   desirable to provide the Query message with a higher priority than
   other signaling messages.  If the resources along the new path are
   not sufficient, it may be needed to keep the state established
   previously using multihomed interfaces while blocking incoming new
   requests (see Section 6.2).  In this situation, providing NSIS
   signaling for the Path Update with a high priority over local
   requests for the resources will be helpful for seamless service.

   In the downstream Path Update, if resources are available, the MN
   initiates the NSIS signaling for state re-setup toward a CN along the
   new path, and the DCRN discovery is implicitly performed by this type
   of signaling as described in Section 4.2.3.  When the DCRN is
   discovered, it sends a response message toward the MN to notify of
   the NSLP state installed (e.g., QoS-NSLP state) or installs the NSLP
   state as a response to the initiated NSLP signaling (e.g., as in
   RSVP).  In case of QoS-NSLP, the sender-initiated approach leads to
   faster setup than the receiver-initiated approach as in RSVP as shown
   in Figure 3.  And then, the DCRN sends a refresh message toward the
   signaling destination to update the changed MRI on the common path
   and also sends a teardown message toward the old AR to delete the
   NSIS state (if possible).

   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
   common path as described in Section 4.2.3.  In this case, the CN
   should be informed of the mobility event using an NSIS signaling
   message sent by the MN or monitoring the mobility signaling procedure
   (e.g., detecting a change in its binding entry (see Section 6.1)).
   After the UCRN is determined, it may send a refresh message to the MN
   along the new path while establishing the NSIS association between
   the newly found peers.  Afterward, the UCRN may send a teardown
   message toward the old AR to delete the NSIS state (if possible).

   The state update on the common path to reflect the changed MRI brings



Lee, et al.             Expires August 21, 2005                [Page 19]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   issues on the end-to-end signaling addressed in Section 3.1.
   Although the state update does not give rise to re-processing of AAA
   and admission control, it may lead to the increased signaling
   overhead and latency.

   One of the goals of the Path Update is to avoid the double
   reservation (in QoS signaling) on the common path as described in
   Section 3.1.  The double reservation problem can be solved by
   establishing a signaling association using a unique SID and by
   updating packet classifier/flow identifier.  In this case, the NSLP
   state should be shared for flows with different flow identifiers.


      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 3. Sender- vs. Receiver-initiated reservation




Lee, et al.             Expires August 21, 2005                [Page 20]


Internet-Draft         NSIS Signaling in Mobility          February 2005


4.3.2  State teardown

   After re-establishment of the NSIS state along the new path, the
   state on the obsolete path needs to be quickly removed by the 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 resources in the access network as
   identified in Section 3.1.  Although the release of the existing
   state on the old path can be accomplished by the timeout of soft
   state, the refresh timer value may be quite long and the maintenance
   of the NSIS state on the old path is not necessary.  Therefore, the
   transmission of a teardown message is useful 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 at the GIMPS layer [2].

   The CRN is an appropriate point to initiate the teardown toward the
   old AR after re-establishment of the state along the new path.  The
   release of the state on the obsolete path can be accomplished by
   comparing the NSLP_Br_IDs and through reverse routing using SII.
   This can prevent the teardown message from being forwarded toward
   along the common path.

   It may not desirable to allow the teardown message to be sent toward
   the opposite direction to the state initiating node.  This is because
   it leads to an authorization problem because a node which does not
   initiate signaling for establishing the NSIS state can delete the
   already established state.  One simple way to avoid the authorization
   problem is to disallow the transmission of the teardown message in
   the reverse direction.

   The immediate removal of state along the old path may not be always
   appropriate for some mobility situations addressed in Section 3.  For
   instance, in the ping-pong type of fast handover, it increases
   signaling overhead, and thus when to delete the state along the
   obsolete path needs to be discussed further (see Section 5.4).
   Another example is the í«invalid NRí¯ problem.  If the old AR is the
   last node on the signaling path due to handover, its NSLP may trigger
   an error message to indicate that NSLP messages cannot be forwarded
   any further.  This error message can immediately remove the state on
   the old path, which 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 5.5.



5.  Applicability Statement




Lee, et al.             Expires August 21, 2005                [Page 21]


Internet-Draft         NSIS Signaling in Mobility          February 2005


5.1  Support for macro mobility-based scenarios

   This section considers how NSIS protocols should interact with the
   basic macro-mobility protocols such as Mobile IPv4 and Mobile IPv6.
   Basically, the following scenarios need to be considered.

   (1) A flow associated with an MN, either sent or received by the MN,
      desires to continually get signaling services even after a Mobile
      IP handover.  In this case, NSIS needs to be able to signal for
      such flows upon the MN's movement to provide seamless service
      (e.g., seamless QoS).  The signaling procedures will create a new
      NSIS branch in the changed direction of flow through the CRN
      discovery and Path Update.

   (2) Either the sender or the receiver of a flow can initialize NSIS
      signaling, and a node within the network may also initiate NSIS
      signaling for the given session to handle route changes caused by
      Mobile IP-based routing, or to support seamless handover if
      necessary.  In this case, it is essential to require the NI to be
      authorized to initialize NSIS signaling.

   (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 a combination of both approaches) on different
      segments of the data path depending on the operation of the
      mobility protocol (e.g., Mobile IPv4, Mobile IPv6, LMM, reverse
      tunneling, etc.) In this case, NSIS signaling needs to immediately
      be initiated via a mobility routing interface (e.g., mobility API)
      between the NSIS protocol and the Mobile IP.

   (4) An MN undergoes either intra-domain (within an access network
      domain) handover or inter-domain (from an access network domain to
      another) handover.  In case of the inter-domain handover, topology
      information exchange, authorization and accounting issues may be
      more complicated.  In such various handover scenarios, the
      interaction between NSIS signaling and some mobility management
      protocols (e.g., HMIP, FMIP, etc..) may give rise to significant
      performance gains (see Section 5.3).

   (5) With Mobile IPv6, an MN can support multiple CoAs at a time, if
      it is connected to multiple access networks simultaneously (even
      if it is connected to one access network).  Although only one
      primary CoA 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 5.2).

5.1.1  Implications to Mobile IP-related scenarios




Lee, et al.             Expires August 21, 2005                [Page 22]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   As NSIS is path-coupled signaling, one imposed requirement here is
   that the NSIS protocols are to be associated with route changes to
   support route optimization between the CN & the MN, and the IP-in-IP
   encapsulation from the HA to the MN.  This interaction needs to be
   notified to all NSLPs (by the API between GIMPS and NSLP) for the CRN
   discovery and the Path Update.  Therefore, NTLP or NSLP needs to have
   an interface with the Mobile IP to react to the mobility event.  In
   other words, an NSIS implementation needs to be developed to react
   based on the endpoint notification regarding which behaviour of a
   mobility protocol has taken place (e.g., the timer of Mobile IP
   expires).

   An ideal interface between the NSIS signaling and the Mobile IP
   should make it possible for NSIS signaling to immediately react to
   the mobility event whenever Mobile IP changes its related
   characteristics in any place for the flows.  In general, it is
   appropriate that NTLP is involved in the interaction with the Mobile
   IP rather 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 for the necessity of state
   update when the mobility is detected.

   Here are also some issues which arise concerning the API between the
   NSIS protocol and the Mobile IP.

   -  Which information should be used to detect the movement? After an
      MN moves to a new network attachment point, the new reachability
      information is transferred from the MN to its HA as the last
      procedure of handover.  It indicates that the NTLP may need to
      interact with a binding process (e.g., a registration request in
      Mobile IPv4 and Binding Update in Mobile IPv6) to detect the IP
      address change and refer to the tunneling-related information.
      Provided that the NTLP detects the mobility using the information
      regarding binding process, faster state establishment and removal
      can be performed.  However, in the fast or ping-pong type
      handover, it may result in significant signaling overhead and some
      possible errors (see Section 5.4).

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

   -  How is the mobility binding update interval coordinated with the
      NSIS signaling interval? Since the binding update or the
      registration request occurs periodically even for the MN with the
      same point of attachment, the movement detection based on the
      binding process may cause the NTLP/NSLP to initiate the CRN
      discovery and the Path Update inappropriately.  To avoid the



Lee, et al.             Expires August 21, 2005                [Page 23]


Internet-Draft         NSIS Signaling in Mobility          February 2005


      problem, the change of CoA should be checked carefully.  Although
      this issue is closely related to implementation, it should be
      considered to obtain any performance gains in signaling.

   An overall coordination/synchronization for the interworking between
   the NSIS and the Mobile IP needs to be discussed further.

5.1.1.1  Mobile IPv4-specific issues

   With Mobile IPv4, the data flows are forwarded based on the
   triangular routing, and an MN retains a new CoA from the FA (or an
   external method such as DHCP) in the visited access network [5].
   When the MN acts as a sender, the downstream data flows sent 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 sent from the CN are routed through the IP
   tunneling between the HA and the FA (or the HA and the MN in case of
   the Co-located CoA).  With this approach, routing is dependent on the
   HA, and therefore the NSIS protocols needs to interact with the IP
   tunneling procedure of Mobile IP for signaling.

   The Figures 5 (a) to (e) show the NSIS signaling flows depending on
   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

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

     (b) MIPv4: MN-->CN, the reverse tunnel with FA CoA

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

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



Lee, et al.             Expires August 21, 2005                [Page 24]


Internet-Draft         NSIS Signaling in Mobility          February 2005


         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 the 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 4 (a).  If
      the reverse tunnel is used and the state along the tunneling path
      does not exist, the NSIS state should be established along the
      tunneling path from the FA to the HA as shown in Figure 4 (b).  In
      this case, a DCRN may be discovered on the tunneling path and the
      new flow identifier for the state update on the tunnel may need to
      be created.

   -  For the upstream signaling flow, the CN may initiate the NSIS
      signaling to update the existing state between the CN and the HA,
      and in this case NSIS signaling should interact with the IP
      tunneling operation to update the state along the tunneling
      segment from the HA to the FA as shown in Figure 4 (d).  During
      this operation, a UCRN may be discovered on the tunneling path,
      and the new flow identifier for the state update on the tunnel may
      need to 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 the downstream signaling flow, the NSIS signaling for the DCRN



Lee, et al.             Expires August 21, 2005                [Page 25]


Internet-Draft         NSIS Signaling in Mobility          February 2005


      discovery and the Path Update is the same as the case for FA CoA
      above except for the use of the reverse tunnel path from the MN to
      the HA as shown in Figure 4 (C).

   -  For the upstream signaling flow, the NSIS signaling for the UCRN
      discovery and the Path Update is also the same as the case for FA
      CoA above except for the end point of tunneling path from the HA
      to the MN as shown in Figure 4 (e).

   Note that the DCRN and UCRN may be identified at the same node on the
   tunneling path.  For example, NSIS CRN may be usually 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 will be
   affected depending on the type of interaction between NSIS signaling
   and IP tunneling.  The FA and the HA should be NSIS-aware to do the
   Path Update along the appropriate path.  The effect that the IP
   tunneling has on the CRN discovery and the Path Update should be
   discussed further.

5.1.1.2  Mobile IPv6-specific issues

   Unlike Mobile IPv4, with Mobile IPv6, the FA is not required in the
   data path and the route optimization process between the MN and CN
   can be used to avoid the triangular routing in the Mobile IPv4
   scenario as shown in Figure 5 [9].  If the use of route optimization
   is not mandatory, data flow routing and NSIS signaling procedures
   (including the CRN discovery and the Path Update) will be similar to
   the case of using the Mobile IPv4 with co-located CoA described in
   Section 5.1.1.1.

   When an MN (as a sender) arrives at a new AR and the binding process
   is successfully completed,

   -  For the downstream signaling flow, the MN may initiate NSIS
      signaling for the 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 Figures 5 (a) and (b), respectively.

   -  For the 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 via the interaction with IP tunneling
      operation as shown in Figure 5 (d).  However, if the route
      optimization is used between the CN and the MN, for the 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 5 (c): the bidirectional



Lee, et al.             Expires August 21, 2005                [Page 26]


Internet-Draft         NSIS Signaling in Mobility          February 2005


      state establishment may be required.  In this case, the obsolete
      path of the existing tunneling segments needs to be removed after
      re-establishment of NSIS state along the optimized path.  When to
      remove the tunneling segment and/or how to tear it down through
      the interworking with the IP-tunneling operation is still an open
      issue.

   Although the routing based on Mobile IPv4 with the co-located CoA is
   similar to the case of Mobile IPv6, one of the differences is the
   method to acquire the CoA.  The Mobile IPv6 is able to acquire the
   CoA from the corresponding access router or external method through
   the stateless autoconfiguration or the stateful autoconfiguration
   (e.g., DHCPv6), respectively while the Mobile IPv4 obtains the CoA
   through from FA or 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.  It is still an open
   issue and needs to be discussed further in the later version of this
   draft.


          MN                                             CN
          |                                              |
          |IPv6+HomeAdressOpt                            |
          |--------------------------------------------->|
          |                                              |
         (a) MIPv6: MN-->CN, no reverse tunnel

         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









Lee, et al.             Expires August 21, 2005                [Page 27]


Internet-Draft         NSIS Signaling in Mobility          February 2005


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

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

   Figure 6. Implications for signaling under different Mobile IPv6
   scenarios

5.2  Multihoming scenarios

5.2.1  Overview

   A host that is an initiator or responder of signaling messages may be
   not only mobile but also multi-homed.  When considering current
   activities in the Multi6 and HIP WGs, multi-homed hosts and scenarios
   may be common in the future IPv6-based Internet.  Such scenarios may
   include load balancing where multiple connections to different
   providers are used simultaneously.  In this case, the multi-homed MN
   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.

   The term "seamless mobility" is often referred to mean that the MN is
   able to keep an ongoing session seamlessly (without experiencing
   perceivable service 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.
   The former requires the MN to keep the old path, while data is
   received over the new path.  This approach is possible if the MN is
   multi-homed.

   Other possible scenarios may include bi-casting, bandwidth increase,
   etc.

5.2.2  Examples of NTLP/NSLP support for mobility

   The NTLP uses an endpoint address (e.g., CoA) to install message
   routing state.  In multi-homed MN scenarios, there are multiple CoAs
   for the MN, and therefore an appropriate CoA should be selected to
   establish the NSIS state between the MN and the CN.

   If the multi-homed MN has multiple network interfaces, each network
   interface may use a unique CoA.  To find a feasible signaling path,
   multiple NSIS messages (e.g., multiple QUERY messages of the



Lee, et al.             Expires August 21, 2005                [Page 28]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   QoS-NSLP) can be sent from the MN to the HA or CN (in case of route
   optimization), the HA or CN may decide which one to choose based on
   some criteria (e.g., resource availability, delay, etc.).  According
   to the decision, the HA or CN should send a signaling message (e.g.,
   RESERVE) to the MN with the selected CoA for further action.

   In the situation where the new CoA introduced in Mobile causes the
   change of message routing state, both new and old addresses are valid
   during a certain period of time, and the new data path may co-exist
   with the old one.  It is theoretically possible to perform an NSIS
   state update on the new path during this period, however the
   signaling endpoints need to be careful, so that the correct routing
   information will be delivered for setting up a new message routing
   state or updating the existing message routing state on the correct
   path segment.  In addition, performing such actions should not cause
   any NSLP service interruption, protocol misbehaviors, or security
   holes.

   When there is a need for inter-domain handover, an additional delay
   may be caused to perform authentication and authorization compared to
   the intra-domain handover, but the latency penalty of NSIS signaling
   can be mitigated if the MN is multi-homed.

   For load balancing purposes, NSIS may need to install the NSIS state
   along multiple paths.  In this case, multiple NSIS messages (e.g.,
   multiple QUERY messages in case of QoS-NSLP) can be sent to the
   remote endpoint to establish NSIS state.  In this way, multiple paths
   can be set up for load balancing between the same endpoints.

   A more detailed analysis of the NTLP/NSLP functionality in different
   multi-homed scenarios (e.g., including load balancing, bi-casting,
   etc.) will be presented in the later version of this draft.

5.3  QoS performance considerations in mobility scenarios

   The routing characteristics of Mobile IP described in Section 5.1
   cause the session path to be changed and the exiting protocols which
   do not support NSIS signaling in dynamic environment may cause the
   problems addressed in Section 3.1.  In particular, QoS performance in
   terms of resources utilization and signaling latency needs to be
   examined so that how NSIS protocols should interact with mobility
   protocols is correctly analyzed.  From the perspective of resource
   utilization, the double reservation problem can be alleviated by the
   CRN discovery and the Path Update.  However, how to manage the
   resource utilization in NSIS signaling should be taken into account;
   in this regard, the adjustment of refresh interval should be
   considered as addressed in Section 3.2.




Lee, et al.             Expires August 21, 2005                [Page 29]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   The NSIS protocol suite normally uses a soft-state approach based on
   the peer-to-peer refresh 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].  The peer relationship is
   maintained using a timer which indicates how long the association
   between the peers can be considered valid.  In other words, if the
   timer has not been refreshed until it expires (e.g., in 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 set up and maintained using the
   peer-to-peer refresh messages.  The peer-to-peer based refresh allows
   the QoS-NSLP to appropriately select the refresh interval by
   considering the current network environment.  For example, the
   refresh timer value is set to a smaller value in the mobile/wireless
   (access) network than that in the core (wired) network as in [7].
   Especially, in the situation where handover happens very frequently,
   the adjustment of the refresh interval reduces the waste of
   resources.  However, unlike the QoS-NSLP, the refresh timer of NTLP
   state does not need to be adjusted in the network since resource
   reservation is not involve directly.  Furthermore, the NTLP state
   along the obsolete path does not need to be explicitly removed before
   the expiration of refresh timer.

   In mobile 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) or the reservation
   style (e.g., pre-establishment or re-establishment) to optimize the
   resources utilization.  For example, in the make-before-break
   handover, an appropriate refresh time interval can be notified using
   the reserved field of REFRESH object [8].  If the refresh timer 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 without the waste of resources.

   After the state setup on the new path, QNEs on the signaling path may
   send a refresh message to the neighboring peer node before the
   refresh timer expires to update only the state previously installed
   along the path, or update the changed flow ID along the common path .
   The overhead required to perform refresh can be reduced, in a way
   similar to the refresh reduction in RSVP [9].  Once a RESPONSE
   message which indicates the successful installation of a reservation
   has been received, subsequent RESERVE messages for refresh can simply
   refer to the existing reservation, rather than including the complete
   reservation specification.  For example, in case of QoS-NSLP, only
   the SID and the SII with no QSPEC are sent to just refresh the state
   (e.g., reservation) previously installed.  The changed flow ID



Lee, et al.             Expires August 21, 2005                [Page 30]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   together with those IDs is only sent to update it along the common
   path.  Especially, transmission of the reduced number of refresh
   messages over wireless channels, access networks, or core networks
   results in the efficient utilization of resources.

   As mentioned in Section 3.1, unlike the generic route changes, in
   mobility scenarios, the end-to-end signaling problem by the Path
   Update gives rise to the degradation of network performance such as
   increased signaling overhead, service blackout, and so on.  To reduce
   signaling latency in the Mobile IP-based scenarios, the NSIS protocol
   suite needs to interwork with localized mobility management (LMM).
   If the GIMPS/NSLP( QoS-NSLP or NAT/FW-NSLP) protocols interacts with
   Hierarchical Mobile IPv6 and the CRN is discovered between an MN and
   MAP, the Path Update can be localized.  However, how the Path Update
   is performed with scoped signaling messages within the access network
   under the MAP is for further study.

   In the inter-domain handover, a possible way to mitigate the latency
   penalty is to use the multi-homed MN.  It is also possible to allow
   the NSIS protocols to interact with mobility protocols such as
   Seamoby protocols (e.g., CARD and CTP) and FMIP.  Another scenario is
   to use peering agreement which allows aggregation authorization to be
   performed for aggregate reservation on an inter-domain link without
   authorizing each individual session.  How these approaches can be
   used in NSIS signaling is for further study.

5.4  Support for Ping-Pong type handover

   NSIS signaling needs to consider the interaction with ping-pong type
   handover as addressed in Section 3.1 because it has a significant
   effect on when to initiate signaling for state setup or for state
   release.  With the sender-initiated approach, if an MN (as a sender)
   undergoes a handover to a new AR, the NTLP interacts with the binding
   process of Mobile IP to initiate state setup.  However, if the MN
   moves to other ARs or the previous AR again in a short while,
   signaling using the interaction with the binding process may result
   in considerable signaling overhead and some possible errors.
   Immediate teardown of state on the old path may also bring on the
   similar result.  Some identifiers defined in [5][6] may be useful for
   this situation.

   An NE (e.g., QNE) can determine if it is a merging point (i.e., an
   NSLP CRN) of the old and new paths, an involved state setup on the
   new path and state teardown on the old path.  However, if the QNE
   receives an NSIS message (e.g., RESERVE) with a special flag (e.g.,
   NO_REPLACE flag) set but with the different SII, state teardown on
   the old path should not happen.  This may apply to a ping-pong type
   handover where the MN wishes to keep state to its old attachment



Lee, et al.             Expires August 21, 2005                [Page 31]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   point in case it moves back there.

   The Reservation Sequence Number (RSN) may be useful in detecting
   duplicate messages in the mobile environment.  For example, it is
   possible for the MN to move to the second NAR soon after being
   attached to the 1st NAR.  The CRN may receive the RESERVE messages
   (with different RSN) twice when the RESERVE message from the 1st NAR
   arrives later than the RESERVE message from the 2nd NAR.  In this
   case, the CRN should determine which ESERVE message is the latest one
   via the RSN.

   The Mobility object described in Section 4.2.2 can 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 (MEC).  The MEC
   field can inform the CRN of which incoming massage is the latest and
   so it is useful to detect the latest handover event for avoiding any
   confusion about where to send a confirmation message and to handle
   the ping-pong type of movement.

5.5  Peer failure scenarios

   A dead peer can occur either because a link or a network node failed,
   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.  In this regard, the
   following issues arise.

   -  An MN may either fail or move.  When it fails, it becomes a dead
      peer.  If it moves and changes its IP address without notifying
      NSLP/NTLP, it also becomes a dead peer.  The failure or movement
      of an MN may cause the 'invalid NR' problem [8] where the NR is
      the MN addressed in Section 3.2.  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.  The problem can be solved by using
      hanover_init (HI) field of the Mobility object described in
      Section 5.4.  The HI field can explicitly inform AR that a
      handover is now initiated, and thus the invalid NR problem can be
      resolved [12].  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.




Lee, et al.             Expires August 21, 2005                [Page 32]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   -  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 in
      Section 4.2.3.

   -  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.  A more detailed analysis of interactions with
      Seamoby protocols is left for future work.

   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.  Security Considerations

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

   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 [8]
   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



Lee, et al.             Expires August 21, 2005                [Page 33]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   a data sender followed by a discussion of the CN as a data sender.

6.1  MN as data sender

   This section refers to Figure 1 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.

6.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 be
   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.

   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?


      MN                                              CN

       ------>----->------>------>------>------>------>    +
                  ACTION (MN is authz)                     |
                                                           |
       <-----<-----<------<------<------<------<-------    | Flow
                           ACK                             | Setup
                                                           |
                                                           |
       ===============================================>    +
                            Traffic




Lee, et al.             Expires August 21, 2005                [Page 34]


Internet-Draft         NSIS Signaling in Mobility          February 2005


              Figure 6: MN authorized initial reservation

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

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


       MN                    DCRN                      CN

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

                      Figure 7: 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.

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

   -  How should other nodes between the MN and the DCRN and the nodes
      between the DCRN 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 in
   the paragraph below.  Figure 8 shows the exchange graphically.

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


       MN                    DCRN                       CN

      <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    +
                         TRIGGER                          | E.g.



Lee, et al.             Expires August 21, 2005                [Page 35]


Internet-Draft         NSIS Signaling in Mobility          February 2005


                                                          | Tear
                                                          | Down
       ------>----->------>------>------>------>------>   |
                           ACTION                         |
                                                          |
       <-----<-----<------<------<------<------<-------   +
                            ACK

                      Figure 8: 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 [8]).

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

6.1.2  CN is authorizing entity

   This scenario is similar to the CN triggering in Section 6.1.1.  Two
   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 9.

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

   In Figure 9 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                         |
                                                           |



Lee, et al.             Expires August 21, 2005                [Page 36]


Internet-Draft         NSIS Signaling in Mobility          February 2005


       ------>----->------>------>------>------>------>    |
          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 9: 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
      from the CN and the MN?

6.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
   DCRN 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 DCRN.  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)             ] |



Lee, et al.             Expires August 21, 2005                [Page 37]


Internet-Draft         NSIS Signaling in Mobility          February 2005


                                                           |
        ------<-----<------<------<------<------<------<   |
                   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 10: CN uses installed state to route message backwards

   Figure 10 raises a few questions:

      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



Lee, et al.             Expires August 21, 2005                [Page 38]


Internet-Draft         NSIS Signaling in Mobility          February 2005


      first message was transmitted by the CN.

6.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 [7]
   draft which lists a few strawman proposals for addressing the session
   ownership problem.

6.1.3  CN as data sender

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

6.1.3.1  CN is authorizing entity

   This scenario is similar to the one described in Section 6.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                    UCRN                      CN

                                                          + E.g.
       <-----<-----<------<------<------<------<-------   | Create
                           ACTION                         | new
     +-----------------+     |     +-----------------+    | State
     |  Action:        |     |     |  Action:        |    |
     |  'create' along)|     |     |  'update' along)|    |
     |  new segment)   |     |     |  shared segment)|    |
     +-----------------+     |     +-----------------+    |
      <------<------<--------+                            |
     +-----------------+                                  |



Lee, et al.             Expires August 21, 2005                [Page 39]


Internet-Draft         NSIS Signaling in Mobility          February 2005


     |  Action:        |                                  |
     |  'delete' along)|                                  |
     |  old segment)   |                                  |
     +-----------------+                                  |
                                                          |
      >----->----->------>------>------>------>------>    |
         ACK (along new path)                             |
                                                          |
      <===============================================    +
                            Traffic

               Figure 11: CN as data sender is authorized

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

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

   -  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
      message exchange it needs to be studied whether the signaling
      message provides sufficient authorization to trigger the NSIS
      exchange.

6.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 6.1.3 where the MN is the data sender but
   the CN is the authorizing entity.

6.1.4  Multi-homing Scenarios

   Multi-homing scenarios have the property that the more than one path
   belongs to a signaling session.  In Figure 12 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.



Lee, et al.             Expires August 21, 2005                [Page 40]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   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.

6.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 |                            |DCRN|>>>>>>>>>>|CN|
         |UCRN|                            |    |>>>>>>>>>>|  |
         +----+                            +----+          +--+
            v               +---+             ^    shared
            v>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>^    segment
                            +---+
                         segment 1

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

                Figure 12: Multi-homed MN as data sender

   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.

6.1.4.2  CN as data sender

   This section shows the multi-homing scenario with the CN as a data



Lee, et al.             Expires August 21, 2005                [Page 41]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   sender.  The scenario is simpler (for the CN authorizing case) than
   the one described in Section 6.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?


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

   <=============================================================
                            Traffic

                Figure 13: Multi-homed CN as data sender

   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.

6.1.5  Proxy Scenario

   The proxy scenarios refer 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 which
      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).




Lee, et al.             Expires August 21, 2005                [Page 42]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   -  Second, the authorization issues which relate to the session
      ownership problem also need to be studied.  Since the session
      ownership issues are 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.

6.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
      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 August 21, 2005                [Page 43]


Internet-Draft         NSIS Signaling in Mobility          February 2005


7.  Change History

   The major change made to the initial version of the draft is to
   re-arrange the issues addressed in the draft in order to clearly
   identify general issues caused by mobility itself and NSIS
   protocols-specific issues.  The generic route changes-related text in
   Section 4 was moved into Appendix to make this draft more
   mobility-specific.

   Specifically, the following changes have been made:

   1.  Removed the terminologies, 'uplink' and 'downlink' in Section 2.

   2.  Removed the terminology, 'local repair' in Sections 2 and 4.

   3.  Re-arranged all problems in Section 3 by merging the
      'mobility-related issues with NSIS protocols' section and the
      'problem statement and general considerations' section.

   4.  Removed the general considerations section in Section 3.

   5.  Modified the problem statement section and moved it into the
      general problem section in Section 3.1.

   6.  Added more problems including 'Identification of the crossover
      node', 'Key exchanges', and 'AA-related Issues' to Section 3.1

   7.  Added the 'Multihoming-related issues' to Section 3.2.4

   8.  Removed the issues on 'how to immediately delete the state on the
      old path' in Section 3.2.

   9.  Moved the generic route changes-related text in Section 4.1 into
      Appendix.

   10.  Removed the figure describing "NSIS signaling topology for
      downstream signaling flow after the route changes in the middle of
      the network" in Figure 2.

   11.  Added 'NSLP_IDs' to each node in Figure 1.

   12.  Removed the 'use cases of identifiers' section, and instead,
      added the 'support for ping-pong type handover' section to Section
      5.

   13.  Added this change history.





Lee, et al.             Expires August 21, 2005                [Page 44]


Internet-Draft         NSIS Signaling in Mobility          February 2005


8.  References

8.1  Normative References

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

8.2  Informative References

   [2]   Schulzrinne, H., "GIMPS: General Internet Messaging Protocol
         for Signaling", draft-ietf-nsis-ntlp-04 (work in progress),
         October 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-07 (work in progress), December 2004.

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

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

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

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

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

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

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

   [12]  Perkins, C., "IP Mobility Support for IPv4, revised",



Lee, et al.             Expires August 21, 2005                [Page 45]


Internet-Draft         NSIS Signaling in Mobility          February 2005


         draft-ietf-mip4-rfc3344bis-01 (work in progress), October 2004.

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

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

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

   [16]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
         Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
         2961, April 2001.


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



Lee, et al.             Expires August 21, 2005                [Page 46]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   Xiaoming Fu
   University of Goettingen
   Telematics Group
   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



Contributors

   Many individuals have contributed to this draft.  Since it was not
   possible to list them all in the authors section, this section was
   created to have a sincere respect for other authors, Paulo Mendes,
   Robert Hancock and Roland Bless.  Separating authors into two groups
   was done without treating any one of them better (or worse) than
   others.



Acknowledgement

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



Appendix A.  Generic Route Changes

   The mobility occurs due to the change of the network attachment
   point, but the generic route changes is associated with load sharing,
   load balancing, or a link (or node) failure.  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



Lee, et al.             Expires August 21, 2005                [Page 47]


Internet-Draft         NSIS Signaling in Mobility          February 2005


   actually happen.

   The route changes brings on the change of signaling topology and it
   results in difference according to the types of route changes (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 14.


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

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

   (a) The topology for downstream NSIS signaling flow after
      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
      route changes

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




Lee, et al.             Expires August 21, 2005                [Page 48]


Internet-Draft         NSIS Signaling in Mobility          February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Lee, et al.             Expires August 21, 2005                [Page 49]