Internet Engineering Task Force                               R. Hancock
Internet-Draft                                           J. Manner (ed.)
Expires: April, 2004                                             C. Shen
                                                           October, 2003

         Interactions of Routing and Mobility on NTLP and NSLP

Status of this Memo

   This document is a submission to Next Steps in Signaling Working
   Group. Comments should be submitted to the mailing

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire in April, 2004.

   Copyright Notice

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


   IP packet routing and changes in routes can have major influence on
   protocols and services that set state in network nodes. Routing may
   change, for example, due to node failure within the network, need for
   load balancing, multihoming or due to end-host or even network
   mobility. This draft is a first step in helping us to decide on how
   these problems should be handled and how interactions with other
   protocols should be handled and a stimulus to further security work.

Hancock et al              Expires April 2004                   [Page 1]

Internet-Draft        Routing and Mobility in NSIS          October 2003

Table of Contents

   1 Introduction .................................................    2
   2 Short Problem Statement ......................................    3
   3 Session Path Change ..........................................    4
   3.1 Problem Statement ..........................................    4
   3.2 Possible Scenarios for Session Path Change .................    5
   3.2.1 Cases corresponding to a NNE as UCOR .....................    6
   3.2.2 Cases corresponding to a PNE as UCOR .....................    8
   3.2.3 Cases corresponding to a FNE as UCOR .....................   10
   3.3 Detection of Session Path Change ...........................   12
   3.4 Response to Route Change caused Session Path Change ........   13
   3.4.1 Network Monitoring based UCOR detection ..................   13
   3.4.2 Data Packet Monitoring based UCOR detection ..............   14
   3.4.3 Signaling packet Monitoring based DCOR detection .........   14
   3.5 Other cases ................................................   15
   3.6 QoS routing Considerations .................................   15
   3.7 Response to Mobility Caused Session Path Change ............   15
   4 IP Mobility and Multihoming ..................................   15
   4.1 Comparison with Route Changes ..............................   15
   4.2 Analysis Overview ..........................................   17
   4.3 MN-Terminating Session .....................................   19
   4.3.1 CN (Sender) Initiated Setup and Teardown .................   19
   4.3.2 MN (Receiver) Initiated Setup and Teardown ...............   21
   4.4 MN-Originating Session .....................................   25
   4.4.1 MN (Sender) Initiated Setup and Teardown .................   25
   4.4.2 CN (Receiver) Initiated Setup and Teardown ...............   27
   4.5 Summary of the Analysis ....................................   29
   4.6 Further Interactions with Fast Handover Protocols ..........   31
   5 Security Considerations ......................................   33
   6 Contributors .................................................   34
   7 Acknowledgments ..............................................   34
   8 Informative References .......................................   34
   9 Author's Addresses ...........................................   34

1.  Introduction

   This draft addresses Mobility related considerations for NSIS. Given
   the scope of mobility, it is helpful to discuss it together with two
   other closely related topics, namely, route change and IP address
   changes.  Generally speaking, the relationship among the three is:

   1. All mobility necessarily incurs route change, usually at edge of
   the network. But route change may also be caused by reasons other
   than mobility, such as routing protocol adaptation in response to
   varying network conditions. The latter type of route changes usually
   occurs in the middle of the network.

   2. Normal IP mobility (i.e., Macro-mobility) involves change of MN IP
   addresses. Micro mobility usually does not cause change of IP
   addresses. Hierarchical mobility contains both macro-mobility and
   micro-mobility scenarios and thus limits the effect of IP address
   change into a smaller scale than that of macro-mobility. Since IP

Hancock et al              Expires April 2004                   [Page 2]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   address is usually part of the flow identifier, change of IP
   addresses implies change of flow identifier.

   A route change triggered by host mobility may or may not involve
   changes in IP addresses. Some Local Mobility Management (LMM)
   mechanisms may change the IP address assigned to the mobile node
   within the access network, for example, mechanisms based on a
   hierarchy of mobility handling routers. Some protocols either use
   tunneling to forward packets towards the new location of the mobile
   node, or set and update per-host routing entries in the network, as
   for instance, ad-hoc routing protocols.

   Issues that also affect the state management in NSIS are host
   multihoming, the actual routing path created by mobility management
   protocols, whether the routing is optimal or triangular, the use of a
   context transfer framework, and who and when notices the need for
   updating states. This latter involves noticing the need to update
   states, for example, whether it is the sender or the receiver of the
   data stream, or some intermediary router. Moreover, whole mobile
   networks will need to be studied in more depth in the context of

2.  Short Problem Statement

   The various services that may make use of the forthcoming NSIS
   protocols set state within network nodes and routers. There are
   various issues that must be handled carefully when the NSIS protocols
   are used in non-static environments, as for instance, mobile nodes in
   wireless access networks. The following list is a short summary of
   the main issues that must be considered when the NTLP and NSLP
   protocols are used in dynamic environments:

   - Interactions with session state information and routing information
   (=IP address)

   - If session states are set for single unicast communications, state
   on the obsolete path must be removed quickly after the routing

   - Changes in states and routing should only be signaled within the
   affect part of the network, and, thus, should not require end-to-end
   signaling. This may not always be possible, if, for example, the IP
   address of the sender or receiver changes.

   - Possibility to keep signaling local, or within an identified scope.
   This would be useful, especially in mobile networks, to be able to
   reserve only local resources. This feature would require that the
   node terminating the NSIS signaling must be a different node than the
   one receiving the user data.

   - Various LMM mechanisms use tunneling or affect routing table
   entries.  These changes, and tunnels in general, affect the way NSIS
   protocols are able to set state on the same path as the user data,

Hancock et al              Expires April 2004                   [Page 3]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   and are able to identify the original IP packets carrying user data.

   - Route changes noticed by NTLP, or some other entity within an NSIS
   router, should be propagated to NSLP, and or NTLP, respectively. This
   is similar to the operation of RSVP, where routing changes noticed by
   the router are propagated to the RSVP process running on the router.

   - Interactions of NTLP/NSLP and Mobile IP need to be taken into

   - Interactions with NTLP/NSLP and CARD and CT need to be studied.

   - Slow wireless links may require additional considerations within
   NSIS, for example, state refreshes, and any other NSIS-related
   signaling, should be sent less frequent over the wireless link than
   within the wired network.

   - Issues in discovering the cross-over router to find the limit of
   the affected path.

   - A critical issue is also the security of the signaling, AAA and
   encryption. When a node moves or routing changes happen within the
   network, how can the new peer, for example, a new access router,
   authenticate and decrypt protected NTLP/NSLP messages?

3.  Session Path Change

3.1.  Problem Statement

   In this document session path change is used to refer to the common
   aspect of route change and mobility. Path change is further divided
   into downstream path change and upstream path change: In NSIS
   context, a downstream path change occurs when the outgoing interface
   for a session has changed; an upstream path change occurs when the
   incoming interface for a session has changed. Path change results in
   divergence of packets in data plane and/or in control plane.  We
   refer to the node where this divergence starts as the Upstream Cross-
   Over Router (UCOR) and the node where this divergence ends as a
   Downstream Cross-Over Router (DCOR).

   It should be noted that:

   1. It is possible to adopt a more NSIS-aware UCOR/DCOR definition
   rather than this strict "route splitting point" definition. For
   example, in cases where the route splitting point is not NSIS
   capable, the UCOR/DCOR could be defined as the NTLP/NSLP node
   downstream or upstream of it.

   2. Although this definition is meant to refer to routers (as the name
   suggests). It is also possible and interesting to extend it to
   include end nodes especially in Mobility and Multi-homing scenarios.
   For example, in sender mobility case, the MN *could* view the result
   of its mobility functions (change of IP address) as similar to a

Hancock et al              Expires April 2004                   [Page 4]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   downstream routing change event (it needs intelligence to do that)
   and be defined as a UCOR. In multi-homing case, the MN *could* view
   the result of its multi-homing functions (change of outgoing
   interface) as similar to a downstream routing change event and be
   defined as a UCOR.

   We consider a mixed signaling configuration scenario outlined in
   Figure 1 (copied from [1]), i.e., not all routers in the path are
   NSIS Entities (NEs); All NEs support NTLP; but not all NEs support
   all NSLPs. We use NSLP1 as an example in the description below. We
   refer to the three types of nodes seen by a particular session as:
   Full-NSIS Entity or FNE (supports NTLP and the specific NSLP1),
   Partial NSIS Entity or PNE (supports NTLP but not the specific
   NSLP1); Non-NSIS Entity (NNE) (supports neither NTLP nor NSLP1).

       +-----------+     +----+     +----+     +----+      +-----------+
       |Application|---->| R1 |---->| R2 |---->| R3 |---->|Application|
       |   +--+    |     |+--+|     |+--+|     +----+     |   +--+    |
       |   |NE|====|=====||NE||=====||NE||================|===|NE|    |
       |   +--+    |     |+--+|     |+--+|                |   +--+    |
       +-----------+     +----+     +----+                +-----------+

           Figure 1(a): Simple Signaling and Data Flows

                  +------+    +------+    +------+    +------+
                  |  NE  |    |  NE  |    |  NE  |    |  NE  |
                  |+----+|    |      |    |+----+|    |+----+|
                  ||NSLP||    |      |    ||NSLP||    ||NSLP||
                  || 1  ||    |      |    || 2  ||    || 1  ||
                  |+----+|    |      |    |+----+|    |+----+|
                  |  ||  |    |      |    |      |    |  ||  |
                  |+----+|    |+----+|    |+----+|    |+----+|
                  |+----+|    |+----+|    |+----+|    |+----+|
                  +------+    +------+    +------+    +------+

              Figure 1(b): Signaling with Heterogeneous NSLPs

3.2.  Possible Scenarios for Session Path Change

   Session path change can be caused by either route change or mobility.
   The main difference of these two cases, in terms of UCOR and DCOR can
   be summarized as follows:

   In case of route change, usually both UCOR and DCOR exist and they
   form a loop; In case of mobility, Sender mobility will create a DCOR,
   Receiver mobility will create a UCOR. If the MN is both sending and
   receiving, there will be both UCOR and DCOR, they may or may not be
   in the same physical node depending on the routing symmetry. Session
   path changes caused by mobility are analyzed in more detail in
   Section 4.1.

Hancock et al              Expires April 2004                   [Page 5]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   Since either UCOR or DCOR can be any of the FNE, PNE or NNE, we have
   9 possible UCOR/DCOR combinations for route change and 6 possible
   cases for sender/receiver mobility. From topology point of view, the
   6 mobility cases are actually simplified versions of corresponding
   route change cases. However, mobility also involves other aspects not
   present in route change, such as mobility signaling and change of
   Flow Identifiers.

   In the following, we illustrate the 9 route change scenarios.

3.2.1.  Cases corresponding to a NNE as UCOR

   The following Figure 2 shows an example network before path change:

         +------+              +------+    +------+    +------+
         |  R1  |              |  R2  |    |  R3  |    |  R4  |
         |      |L1A      L2A  |      |    |+----+|    |+----+|
         |      |---> ... ---->|      |--->||NSLP||--->||NSLP||--->
         |      |              |      |    || 2  ||    || 1  ||
         +------+              +------+    |+----+|    |+----+|
                                           |      |    |  ||  |
                                           |+----+|    |+----+|
       ===========> ... ==================>||NTLP||====||NTLP||===>
                                           |+----+|    |+----+|
                                           +------+    +------+
                     Figure 2: Case A: UCOR is an NNE,

   The following three figures show the three possibilities after path
   change for the example network:

Hancock et al              Expires April 2004                   [Page 6]

Internet-Draft        Routing and Mobility in NSIS          October 2003

       +------+                +------+    +------+    +------+
       |  R1  |                |  R2  |    |  R3  |    |  R4  |
       |      |                |      |    |+----+|    |+----+|
       |      |--->            |      |--->||NSLP||--->||NSLP||--->
       |      |                |      |    || 2  ||    || 1  ||
       +------+                +------+    |+----+|    |+----+|
         | ||                      |       |      |    |  ||  |
         | ||                      |       |+----+|    |+----+|
         | ||                      |       ||NTLP||====||NTLP||===>
         | ||                      |       |+----+|    |+----+|
         | ||                      |       +------+    +------+
         | ||                      |          ||
         |  ===============...=================
         |                         |

       Figure 3a: Case A.I DCOR is an NNE

           +------+                +------+    +------+    +------+
           |  R1  |                |  R2  |    |  R3  |    |  R4  |
           |      |                |      |    |+----+|    |+----+|
           |      |--->            |      |    ||NSLP||--->||NSLP||--->
           |      |                |      |    || 2  ||    || 1  ||
           +------+                +------+    |+----+|    |+----+|
             | ||                              |      |    |  ||  |
             | ||                              |+----+|    |+----+|
             | ||                              ||NTLP||====||NTLP||===>
             | ||                              |+----+|    |+----+|
             | ||                              +------+    +------+
             | ||                                || |
             |  ===============...================  |
             |                                      |

       Figure 3b: Case A.II DCOR is an PNE

           +------+                +------+    +------+    +------+
           |  R1  |                |  R2  |    |  R3  |    |  R4  |
           |      |                |      |    |+----+|    |+----+|
           |      |--->            |      |    ||NSLP||    ||NSLP||--->
           |      |                |      |    || 2  ||    || 1  ||
           +------+                +------+    |+----+|    |+----+|
             | ||                              |      |    |  ||  |
             | ||                              |+----+|    |+----+|
             | ||                              ||NTLP||    ||NTLP||===>
             | ||                              |+----+|    |+----+|
             | ||                              +------+    +------+
             | ||                                            || |
             |  ===============...============================  |
             |                                                  |

       Figure 3c: Case A.III: DCOR is an FNE

Hancock et al              Expires April 2004                   [Page 7]

Internet-Draft        Routing and Mobility in NSIS          October 2003

3.2.2.  Cases corresponding to a PNE as UCOR

   The following Figure 4 shows an example network before path change:

       +------+               +------+    +------+    +------+
       |  R1  |               |  R2  |    |  R3  |    |  R4  |
       |+----+|L1A       L2A  |      |    |+----+|    |+----+|
       ||NSLP||---> ... ----> |      |--->||NSLP||--->||NSLP||--->
       || 2  ||               |      |    || 2  ||    || 1  ||
       |+----+|               +------+    |+----+|    |+----+|
       |      |                           |      |    |  ||  |
       |+----+|                           |+----+|    |+----+|
   ====||NTLP||===> ... ==================>||NTLP||====||NTLP||===>
       |+----+|                           |+----+|    |+----+|
       +------+                           +------+    +------+

   Figure 4: Case B: UCOR is a PNE

   The following three figures show the three possibilities after path
   change for the example network:

Hancock et al              Expires April 2004                   [Page 8]

Internet-Draft        Routing and Mobility in NSIS          October 2003

           +------+            +------+    +------+    +------+
           |  R1  |            |  R2  |    |  R3  |    |  R4  |
           |+----+|            |      |    |+----+|    |+----+|
           ||NSLP||--->        |      |--->||NSLP||--->||NSLP||--->
           || 2  ||            |      |    || 2  ||    || 1  ||
           |+----+|            +------+    |+----+|    |+----+|
           |      |                ^       |      |    |  ||  |
           |+----+|                |       |+----+|    |+----+|
       ====||NTLP||===>            |       ||NTLP||====||NTLP||===>
           |+----+|                |       |+----+|    |+----+|
           +------+                |       +------+    +------+
            |  ||                  |          ||
            |   ==============...===============
            |                      |

       Figure 5a: Case B.I: DCOR is an NNE

           +------+                +------+    +------+    +------+
           |  R1  |                |  R2  |    |  R3  |    |  R4  |
           |+----+|                |      |    |+----+|    |+----+|
           ||NSLP||--->            |      |    ||NSLP||--->||NSLP||--->
           || 2  ||                |      |    || 2  ||    || 1  ||
           |+----+|                +------+    |+----+|    |+----+|
           |      |                            |      |    |  ||  |
           |+----+|                            |+----+|    |+----+|
       ====||NTLP||                            ||NTLP||====||NTLP||===>
           |+----+|                            |+----+|    |+----+|
           +------+                            +------+    +------+
            |  ||                                ||^
            |   ==============...================= |
            |                                      |

       Figure 5b: Case B.II: DCOR is a PNE

           +------+                +------+    +------+    +------+
           |  R1  |                |  R2  |    |  R3  |    |  R4  |
           |+----+|                |      |    |+----+|    |+----+|
           ||NSLP||--->            |      |    ||NSLP||--->||NSLP||--->
           || 2  ||                |      |    || 2  ||    || 1  ||
           |+----+|                +------+    |+----+|    |+----+|
           |      |                            |      |    |  ||  |
           |+----+|                            |+----+|    |+----+|
       ====||NTLP||===>                        ||NTLP||====||NTLP||===>
           |+----+|                            |+----+|    |+----+|
           +------+                            +------+    +------+
             |  ||                                           || ^
             |   ==============...============================  |
             |                                                  |

       Figure 5c: Case B.III: DCOR is a FNE

Hancock et al              Expires April 2004                   [Page 9]

Internet-Draft        Routing and Mobility in NSIS          October 2003

3.2.3.  Cases corresponding to a FNE as UCOR

   The following Figure 6 shows an example network before path change:

       +------+                +------+    +------+    +------+
       |  R1  |                |  R2  |    |  R3  |    |  R4  |
       |+----+|L1A         L2A |      |    |+----+|    |+----+|
       ||NSLP||---> ... ------>|      |--->||NSLP||--->||NSLP||--->
       || 1  ||                |      |    || 2  ||    || 1  ||
       |+----+|                +------+    |+----+|    |+----+|
       |  ||  |                            |      |    |  ||  |
       |+----+|                            |+----+|    |+----+|
   ====||NTLP||===> ... ==================>||NTLP||====||NTLP||===>
       |+----+|                            |+----+|    |+----+|
       +------+                            +------+    +------+

   Figure 6: Case C: UCOR is a FNE

   The following three figures show the three possibilities after path
   change for the example network:

Hancock et al              Expires April 2004                  [Page 10]

Internet-Draft        Routing and Mobility in NSIS          October 2003

           +------+                +------+    +------+    +------+
           |  R1  |                |  R2  |    |  R3  |    |  R4  |
           |+----+|L1A          L2A|      |    |+----+|    |+----+|
           ||NSLP||--->       ---->|      |--->||NSLP||--->||NSLP||--->
           || 1  ||                |      |    || 2  ||    || 1  ||
           |+----+|                +------+    |+----+|    |+----+|
           |  ||  |                    ^       |      |    |  ||  |
           |+----+|                    |       |+----+|    |+----+|
       ====||NTLP||===>                |L2B    ||NTLP||====||NTLP||===>
           |+----+|                    |       |+----+|    |+----+|
           +------+                    |       +------+    +------+
             |  ||                     |          ||
             |   ==============...=================
             |                         |

       Figure 7a: Case C.I: DCOR is a NNE

           +------+                +------+    +------+    +------+
           |  R1  |                |  R2  |    |  R3  |    |  R4  |
           |+----+|                |      |    |+----+|    |+----+|
           ||NSLP||--->            |      |    ||NSLP||--->||NSLP||--->
           || 1  ||                |      |    || 2  ||    || 1  ||
           |+----+|                +------+    |+----+|    |+----+|
           |  ||  |                            |      |    |  ||  |
           |+----+|                            |+----+|    |+----+|
       ====||NTLP||===>                        ||NTLP||====||NTLP||===>
           |+----+|                            |+----+|    |+----+|
           +------+                            +------+    +------+
             |  ||                               || ^
             |   ==============...================= |
             |                                      |

       Figure 7b: Case C.II: DCOR is a PNE

           +------+                +------+    +------+    +------+
           |  R1  |                |  R2  |    |  R3  |    |  R4  |
           |+----+|                |      |    |+----+|    |+----+|
           ||NSLP||--->            |      |    ||NSLP||--->||NSLP||--->
           || 1  ||                |      |    || 2  ||    || 1  ||
           |+----+|                +------+    |+----+|    |+----+|
           |  ||  |                            |      |    |  ||  |
           |+----+|                            |+----+|    |+----+|
       ====||NTLP||===>                        ||NTLP||====||NTLP||===>
           |+----+|                            |+----+|    |+----+|
           +------+                            +------+    +------+
             |  ||                                            || ^
             |   ===============...============================  |
             |                                                   |

       Figure 7c: Case C.III: DCOR is a FNE

Hancock et al              Expires April 2004                  [Page 11]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   Following is a summary of the above 9 cases with their indexes (UCOR-

    o A.I   NNF - NNF
    o A.II  NNF - PNF
    o A.III NNF - FNF
    o B.I   PNF - NNF
    o B.II  PNF - PNF
    o B.III PNF - FNF
    o C.I   FNF - NNF
    o C.II  FNF - PNF
    o C.III FNF - FNF

   In all above 9 cases, route change will affect the NTLP/NSLP peer
   relationship of the UCOR and DCOR depending on the number of NEs in
   the old path and new path between the UCOR and DCOR. The 6 mobility
   cases as simplified versions of the route change cases may be derived
   from above figures by taking away either UCOR or DCOR appropriately.
   So similar changes in NTLP/NSLP peer relationship of UCOR/DCOR can be

3.3.  Detection of Session Path Change

   By default the time until some action may be taken to tackle the path
   divergence depends on when the next signaling action (e.g. NTLP
   refresh or NSLP refresh, if applicable) is scheduled. Path change
   detection may be used to shorten this period. The detection mechanism
   is also related to its causes: route change or mobility.

   In this section we only discuss route change detection. Note that
   mobility caused path change would usually be triggered by node
   movement. Movement detection is part of the mobility scheme and out
   of scope of this document.

   A summary of route change detection methods are provided in [1].

   (a) monitoring changes in local interface state

   (b) monitoring topology changes in a link-state routing protocol

   (c) inference from changes in data packet TTL

   (d) inference from loss of packet stream in a flow-aware router

   (e) inference from changes in signaling packet TTL

   (f) changed route of an end-to-end addressed signaling packet

   (g) changed route of a specific end-to-end addressed probe packet

   These methods can be categorized as being based on network monitoring
   (method a-b), based on data packet monitoring (method c-d) and based
   on monitoring signaling protocol messages (method e-g).

Hancock et al              Expires April 2004                  [Page 12]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   Whatever method is used, the detection function needs to be mapped to
   NTLP, NSLP and the corresponding routing related module.

   Network monitoring based approach is applicable in all NNE, PNE and
   FNEs. It is usually used to detect downstream route change. Data
   packet monitoring is in theory possible in all NE types. In reality
   it would only ever be done on FNEs. This is because in order to
   monitor the data flow right, the NE needs to be told about its
   characteristics, and only an FNE would have this information.
   Signaling protocol message based monitoring is usually applicable
   only in PNE and FNEs, but not in NNEs.  It is usually used to detect
   upstream route change.

   From Signaling application point of view, if the detection is not
   done by itself, there are normally two methods it can learn about
   path change from the actual detection function: polling or
   asynchronous notification.

3.4.  Response to Route Change caused Session Path Change

   In this section we look at responses of nodes that detect path
   changes (refer to as detection nodes below) upon a session path
   change event.  The main focus here is to identify the UCOR/DCOR and
   take appropriate local repair actions. Local repair essentially tries
   to achieve the following as fast (and secure) as possible:
   Installation of state on the new path; and removal of state on the
   old path. Under the layer split concept, we will probably have local
   repair problem in both layers. It is important to note that,
   generally speaking, to do any of these route change procedures, an
   involved node has to have per-flow state ('be a stateful node' in

3.4.1.  Network Monitoring based UCOR detection

   Network Monitoring may be used to identify UCOR. It is important to
   note that in case of route change, a chain of routers between the
   actual UCOR and DCOR, inclusive, may detect the route to a
   destination has changed.  But only the first router where the session
   traffic actually starts to diverge should be identified as UCOR. It
   is still an open question how these routers may decide locally
   whether they are indeed the UCOR or not.

   If this kind of decision can be made, those Detection Routers other
   than the UCOR or DCOR may do the following depending on its NSIS
   capability: do nothing (NNE); delete the existing session state (FNE)
   and delete related NTLP state only if the connection is also no
   longer used by any other session (PNE and FNE). Alternatively, the
   Detection Routers other than UCOR or DCOR may do nothing but waiting
   for explicit state teardown or timeout.

   The action taken by UCOR also depends on its type.

Hancock et al              Expires April 2004                  [Page 13]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   If UCOR is a NNE (case A.I-A.III), there is nothing much we can do.

   If UCOR is a PNE (case B.I-B.III), an NTLP level local repair is
   invoked. This may involve: if a "rediscovery timer" (such as in [2]
   similar to the route pinning effect) is used, stop it immediately
   (un-pin the route) and construct a discovery message for an immediate
   peer discovery. The discovery result will tell the NTLP whether its
   peer has changed or not. If a new peer is discovered, NTLP may create
   an association with the new peer and teardown its original
   association with the old peer (if that connection is no longer used
   by any application sessions). In either case (NTLP peer changed or
   not), subsequent NSLP refresh for this session will be able to use
   updated peer information without delay.

   If UCOR is a FNE (case C.I-C.III) A NSLP local repair may follow the
   NTLP local repair. In these cases, the NTLP may deliver a signal to
   NSLP that causes NSLP to start a local repair for downstream route
   change. An example procedure could involve: NSLP sends "RESERVE"
   refresh (as in terminology of [3])immediately, without waiting for
   the refresh timer timeout. This message will be forwarded by NTLP
   towards its updated peer and thus setup necessary states in any newly
   added NSLP nodes up to the DCOR. Explicit teardown of orphaned states
   in the obsolete path might be initiated by messages from UCOR, DCOR
   or even those routers themselves.

   If NSLP level local repair is desired in the case when UCOR is a PNE,
   the NSLP needs to maintain a reverse routing state vs. flow id. The
   PNE noticed a routing change for a given flow id, and knows any NSLP-
   aware nodes that can handle the route change must be upstream of it.
   So it looks up the reverse routing state table and notifies its
   upstream neighbor, and then the upstream neighbor (which may be
   another PNE) has to repeat the process until an FNE is reached. (What
   is hard is for the upstream node to know whether or not to forward
   this notification any further.)

3.4.2.  Data Packet Monitoring based UCOR detection

   These two methods could give some idea of upstream route change, but
   do not tell exactly where the change is. Also there could be many
   detection nodes but hard to tell which one is the Action Node. It
   might be costly to ask each of them to do local repair. But if they
   indeed do, the process might be similar to that in the next section.

3.4.3.  Signaling packet Monitoring based DCOR detection

   Signaling Packet Monitoring may be used to detect upstream route
   changes. As mentioned above, this approach requires that the DCOR be
   signaling aware so these cases correspond to cases A.III, B.III,
   C.III.  In a way similar to that of RSVP, NSLP can identify DCOR by
   comparing the SII contained in the signaling message. For example, if
   the "RESERVE" message for the same session is found to have arrived
   from a node with a different SII, upstream route change is assumed.

Hancock et al              Expires April 2004                  [Page 14]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   The main action DCOR needs to take is the removal of orphaned state
   in the obsolete path. (Only applicable when those routers between
   UCOR and DCOR cannot delete the state themselves earlier). This also
   requires the NTLP to support explicit routing based on SII. The DCOR
   issues a teardown message towards the old peer's SII, this message
   will be routed peer to peer in the reversed direction along the
   obsolete segment and tear down any related state inside the segment.
   This teardown message might also contain some flag indicating it is a
   local repair teardown to facilitate them being identified by the
   UCOR. UCOR should terminate the local repair teardown messages when
   they arrive.

3.5.  Other cases

   There are several cases that the above discussion does not cover,
   including case A.I,A.II, B.I,B.II, C.I,C.II, when the DCOR is not
   FNE. In fact, it seems that if the Detection Routers between UCOR and
   DCOR do not require an explicit state teardown message, these cases
   will be fine as far as DCOR is concerned. Otherwise, more analysis is

3.6.  QoS routing Considerations

   The above discussion applies to normal routing mechanisms which do
   not differentiate route selection for signaling packets or data
   packets. In the presence of QoS routing, it is important to make sure
   signaling packets and data packets of the same session will select
   the same route for path-coupled operation. If route pinning is used,
   the route should be unpinned immediately whenever a route change is
   detected or notified. Other than that, the process should be similar
   to that of the above.

3.7.  Response to Mobility Caused Session Path Change

   Mobility caused session path change can be divided into path change
   with or without change of Flow ID. The case without change of Flow ID
   usually falls into the Micro-mobility category. The analysis of this
   case will be provided in a later version of this document.

4.  IP Mobility and Multihoming

4.1.  Comparison with Route Changes

   The basic case of route change processing for a single flow can be
   extended to the more complex situations of IP layer mobility and
   multihoming. These have several aspects in common with the route
   change case, specifically:

   a) the significance of upstream and downstream crossover routers
   (including how to find them, especially in heterogeneous signaling

Hancock et al              Expires April 2004                  [Page 15]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   application environments)

   b) the possibility that the characteristics of the two path segments
   may be very different (for example, with different resource
   availabilities, or even supporting totally different resource
   negotiation capabilities)

   c) the possibility that the different paths may traverse different
   administrative domains, so that authorization status for one path may
   be inapplicable to the other.

   However, there are several features of the IP mobility and
   multihoming situations which lead to additional requirements on the
   signaling, or suggest that alternative signaling designs may be
   appropriate. The most important of these are as follows:

   1. IP mobility and multihoming introduce a new address for the mobile
   or multihomed node, and this address will lead to a new flow
   identification. This new flow identification will (generally) have to
   be communicated to the correspondent (so it can update transport or
   application layer state to recognize the new flow), and also to
   intermediate nodes on the path (so they can update packet classifiers
   to recognize the new flow). In contrast, in the route change case, it
   may be possible to hide the signaling entirely between the UCOR and
   DCOR, especially if path characteristics and authorization properties
   do not change.

   2. The 'new' flow may persist for some time in parallel with the old.
   This is certainly true in the multihoming case, and can also be case
   with IP mobility. Indeed, the most important initial usage of IP
   mobility may be mainly in inter-technology, inter-system scenarios,
   where the actual 'handover' process takes a long time to complete,
   and so make-before-break is actually necessary to achieve any form of
   session continuity. The signaling solution therefore has to manage
   these two flows 'side-by-side', as compared to the route change case
   where a very rapid flow path modification is the goal.

   3. Conversely, in the IP mobility case, it is also likely that at
   some stage the 'old' flow involving the old IP address has resources
   which are to be released, but that the old flow path is not
   physically available to send signaling messages on (and even that the
   old IP address is not even valid). This can make explicit teardown of
   such resources much harder; however, since this includes scarce
   resources on access links, it may be that long refresh times are in
   use (to minimize signaling overhead) and so explicit teardown is of
   additional importance. In the route change case, the UCOR and DCOR
   are typically reachable even after the route change, at least by some

   4. Mobility events and multihoming configurations are generally known
   (and in fact initially only known) to the flow endpoints and cannot
   be independently detected in the network infrastructure (except in
   the micro mobility scenarios mentioned in section TBD 3.7).
   Therefore, crossover router discovery has to be done as a side effect

Hancock et al              Expires April 2004                  [Page 16]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   of NSIS signaling exchanges, often end to end ones. Discovery is
   therefore a more time consuming process, but less vulnerable to the
   complex case where multiple nodes believe they are the crossover
   router, which can occur in the route change case with local signaling
   repair being triggered by direct interactions with the routing

   5. Finally, the most significant difference is that in the mobility
   and multihoming case, the network infrastructure is asked to perform
   joint operations on two different flows which are only associated by
   their session identifier. However, only the flow endpoints have any
   reason to accept assertions about the relationship between such
   flows: the signaling initiator is actually responsible for choosing
   the session identifier for each flow, and its correspondent will have
   been updated (somehow, presumably securely) at the transport or
   application layer.

   In contrast, nodes within the network have no reason to accept that a
   new flow is related in any way to the old; we have to prevent the
   situation that any node in the Internet can send a signaling message
   into the network with a session identifier which effectively 'steals'
   resources at any node it crosses which has a flow with a matching
   session identifier. These and other security issues with the session
   identifier have been analyzed in more detail in [4]. In the route
   change case, the flow identifier is constant and flow identifier
   spoofing is difficult in practice because of the constraints imposed
   by the routing system. Decoupling the session identification from
   these constraints is the signaling equivalent of breaking the
   connection between locators and identifiers, which is well known to
   lead to a large of number of interesting security issues; an
   excellent overview of these issues in the context of Mobile IP is
   provided in [5].

4.2.  Analysis Overview

   In what follows, we consider the impact of these mobility and
   multihoming specific considerations on a set of four basic scenarios,
   similar to the route change analysis of the previous section. The
   requirements on session identifier behavior are outlined, as well as
   the implications for overall signaling behavior and consequences for
   signaling update latency. These 'call flows' can be used as a
   starting point for deriving requirements on detailed NSIS
   functionality to support mobile or multihoming operation; some of
   these are mentioned during the analysis.

   We consider here only a simplified set of possible scenarios.
   Specifically, we initially only have four. In what follows we use the
   term MN for the mobile or multihomed node, and CN for its

    *) There is a choice of whether the session (i.e. the paired flows)
   is inbound or outbound from the MN;

Hancock et al              Expires April 2004                  [Page 17]

Internet-Draft        Routing and Mobility in NSIS          October 2003

    *) There is an independent choice of whether the MN or CN has
   initiated the signaling.

   In addition, for each scenario, we consider the cases of setup of the
   new flow and the teardown of the old (of course, these two could be
   carried out simultaneously).

   This is still a highly simplified set of possibilities. Our main
   restriction is that there is a hop-by-hop authorization procedure,
   where each node requests resources or other state manipulations from
   its direct NSIS neighbor, and this request propagates from one end of
   the flow (the initiator) to the other (the responder). Clearly, more
   complex authorization scenarios are possible, and this would have a
   major impact on the analysis. It turns out that the hop-by-hop
   authorization assumption, while a very natural approach (and possibly
   the only one which is operationally feasible), has a strong influence
   on what exchanges are necessary and restricts how much these can be
   optimized. Further discussion of the NSIS authorization problem,
   specifically in the case of QoS, is contained in [6].

   In addition to this simplification, we only consider homogeneous
   signaling environments, where the single signaling application is
   supported on all the nodes we care about (i.e. every node considered
   below is an FNE, including MN and CN). Also, for this mobility
   analysis, we have not attempted to distinguish precisely between NSLP
   and NTLP functionality, except in separating the concept of setting
   up reverse path state and installing signaling application state (the
   former being basic NTLP functionality and the latter being the role
   of the NSLP, along with authorization aspects).

   In the teardown case, it is still somewhat open whether a tear can
   propagate in the opposite direction to the original state setup. This
   would correspond to a node removing state which it did not install,
   and therefore might not be consistent with a strict viewpoint on
   authorization. However, in a soft-state protocol, the same effect can
   in any case be simulated by having nodes unilaterally reduce their
   state refresh period to some small time and notify their initiating
   peer of this fact in case the state still needs to be retained for
   some reason.  We call this process 'accelerated expiration'. (If this
   whole discussion seems absurdly finicky, simply replace the phrase
   'accelerated expiration' by 'teardown by the responder'.)

   One of the main goals of this signaling is to avoid double
   reservations on the shared path segment. Influenced by the QoS use
   case, we refer to this as 'state sharing' (e.g. a resource
   reservation can be used by packets for either flow). In reality, the
   correct processing depends on the specifics of the signaling
   application, for which the concept of sharing might not even apply,
   but some form of merging or joint processing still would.

Hancock et al              Expires April 2004                  [Page 18]

Internet-Draft        Routing and Mobility in NSIS          October 2003

4.3.  MN-Terminating Session

   In the case where the session is terminating at the MN, we have the
   situation shown diagrammatically in Figure 8.

                    +--+          +---+   new flow
          new       |MN|<<<<<<<<<<|NAR|<<<<<<<<<<<<<^
          address   +--+          +---+             ^
                  ^                              +----+          +--+
                  |                              |UCOR|<<<<<<<<<<|CN|
                  |                              |    |<<<<<<<<<<|  |
                  |                              +----+          +--+
                  | +--+          +---+             V    shared
          original  |MN|<<<<<<<<<<|OAR|<<<<<<<<<<<<<V    segment
          address   +--+          +---+   original
                  MN acts
                  as DCOR

                      Figure 8: Session from CN to MN

   The following facts are common to both sender and receiver initiated

   *) In general, only a NSIS message sent all the way downstream from
   the CN can discover the UCOR.

   *) The CN must know the MN's new address to be able to send this

   *) The CN must be informed of this new address by a (end-to-end)
   upper layer message from the MN. We refer to this message as 'add-
   IP'; it can be sent as soon as the MN is <= 1RTT in advance of being
   able to receive messages addressed to it. It is this message which
   must initiate the whole re-routing process.

   The MN- and CN-initiated cases are now considered separately.

4.3.1.  CN (Sender) Initiated Setup and Teardown

   The sender initiated case is the simplest of all the four cases, for
   both setup and teardown.

   For the setup case, the NSIS function in the CN is triggered by the
   add-IP message. Because the CN is managing the signaling for the
   session anyway, it has all the information necessary to be able to
   send a single downstream NSIS message for the new flow which travels
   all the way to the MN; in particular, the CN can make the correlation
   between the old and new flows based on local upper layer information
   and set the session identifier in the signaling for the new flow
   appropriately.  On the shared segment, it can update the state to

Hancock et al              Expires April 2004                  [Page 19]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   refer to both flows for the same session identifier; on the new
   segment, it installs state in the normal way for a new flow (this
   includes any admission control operations). Flow traffic can be sent
   immediately after this NSIS message has been sent, and it will
   receive correct treatment provided it does not 'overtake' the
   signaling (which could travel more slowly on the new path segment,
   since the NSIS processing there is more complex).

   For the teardown case, the simplest solution is that the MN sends a
   corresponding 'delete-IP' message end-to-end to the CN, which then
   tears the old flow state down in the same way.

   Another possibility is that the MN could send this delete-IP in an
   upstream NSIS message hop-by-hop, which would remove the state by
   accelerated expiration and carry the upper layer delete-IP message as
   a payload. Ideally this can be sent via the OAR, either directly from
   the MN or via the NAR if FMIP edge tunneling or context transfer is
   being used. Otherwise, it has to be sent using the reverse path state
   of the new flow, but ignored until it reaches the UCOR at which point
   it continues upstream as normal and is also reflected back along the
   old path towards the OAR as far as possible. Traffic sent by the CN
   during this time (while the delete-IP message is still propagating
   upstream) will receive degraded treatment as the state is gradually

   In both teardown cases, there is a potential race condition if the
   teardown or its equivalent is processed on the shared segment before
   the installation of the new flow state (because then the session as a
   whole would be lost there and the new flow state request would have
   to go through admission control). This means that the MN must monitor
   inbound NSIS signaling and only generate messages which could start
   the teardown process when the new flow setup has apparently

   All of these message sequences are shown diagrammatically in Figure

Hancock et al              Expires April 2004                  [Page 20]

Internet-Draft        Routing and Mobility in NSIS          October 2003

          MN                      UCOR                    CN

           ----------------------------------------------->    +
                           add-IP (end to end)                 |
           <-----<-----<------<------<------<------<-------    | Flow
                        NSIS setup (hop by hop)                | Setup
                           (discovers UCOR)                    |
           <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<    +

           ----------------------------------------------->    +
                              delete-IP                        | Flow
                                                               | Tear
           <-----<-----<------<------<------<------<-------    | (1)
                            NSIS teardown                      +

           ------>----->------>------>------>------>------>    +
                     NSIS teardown & delete-IP                 |
                     (accelerated expiration)                  |
                                                               | Flow
           <------<------<-------                              | Tear
            NSIS teardown on old                               | (2)
            segment if upstream                                |
            message was sent via NAR                           +

            Figure 9: CN(Sender)-Initiated MN-Terminating Flows

   Session Identifier Security Considerations: In this particular case,
   there are no interesting requirements on the session identifier. This
   is because all signaling state modification requests are either
   'fresh' (and so no optimizations were possible with it anyway), or
   because the requests come from the same peers as the state was
   originally installed by, and the initial request comes from the
   initiator itself. (It will be seen that all the other cases are
   rather more complex.)

4.3.2.  MN (Receiver) Initiated Setup and Teardown

   The receiver initiated case is more complex than the sender initiated
   case, for both setup and teardown.

   For the setup case, the process begins the same as with sender
   initiation, with an end-to-end add-IP message. Even though the CN is
   not controlling the overall signaling process, its NSIS function must
   still be triggered by this to send a downstream NSIS message whose
   sole purpose is to discover the UCOR and set up reverse routing state
   on the new path. In principal this should be no different from what
   was needed to set up reverse routing state for the original flow;
   however, the NSIS message needs to include the same signaling

Hancock et al              Expires April 2004                  [Page 21]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   application identifier and session identifier as used for the
   signaling for the original flow. This may have some implications for
   how the session identifier values are managed.

   There are then two cases for how the actual state installation should
   take place. This has to be done by signaling messages flowing in the
   MN-CN direction.

   1. The downstream message goes all the way to the MN on the new path;
   this is followed by a setup message in the upstream direction. This
   is processed normally on the new path segment, and once it reaches
   the UCOR state merging can take place on the shared segment.

   2. The downstream message reaches the UCOR, and this is immediately
   able to begin state merging on the shared segment. In the meantime,
   the downstream message continues to the MN and causes state setup on
   the new path segment (but this only needs to carry on up to the

   These two options are illustrated in Figure 10. There are different
   options for when traffic can be sent from the CN, depending on
   whether the CN waits to see that state has been installed before
   using the new path. In particular, if the CN wants a guarantee that
   state has been installed end to end, the timing optimization of
   option (2) is not actually exploited in reality. The two options
   differ in what requirements are placed on the session identifier so
   far as implied authorization is concerned, and these are discussed at
   the end of this subsection.

Hancock et al              Expires April 2004                  [Page 22]

Internet-Draft        Routing and Mobility in NSIS          October 2003

          MN                      UCOR                    CN

           ----------------------------------------------->    +
                           add-IP (end to end)                 |
           <-----<-----<------<------<------<------<-------    |
                  NSIS path state setup (hop by hop)           |
                                         <<<<<<<<<<<<<<<<<<    |
                                           Traffic start       |
                                          (optimistic CN)      | Flow
                                                               | Setup
           ------>----->------>------>------>------>------>    | (1)
                     NSIS signaling state setup                |
                     (or sharing from UCOR to CN)              |
                                         <<<<<<<<<<<<<<<<<<    |
                                           Traffic start       |
                                          (pessimistic CN)     |

           ----------------------------------------------->    +
                           add-IP (end to end)                 |
           <-----<-----<------<------<------<------<-------    |
           .      NSIS path state setup (hop by hop)           |
           .                         .   <<<<<<<<<<<<<<<<<<    |
           .                         .     Traffic start       |
           .                         .    (optimistic CN)      |
           .                         .                         |
           .                         .------>------>------>    |
           .                           NSIS shared state       | Flow
           .                            setup from UCOR        | Setup
           .                             <<<<<<<<<<<<<<<<<<    | (2)
           .                               Traffic start       |
           .                           (fairly optimistic CN)  |
           .                                                   |
           .----->----->------>------.                         |
               NSIS new state setup  .------>------>------>    |
                 from MN to UCOR         Notification of       |
                                         setup complete        |
                                           (optional)          |
                                         <<<<<<<<<<<<<<<<<<    |
                                           Traffic start       |
                                          (pessimistic CN)     +

          Figure 10: MN(Receiver)-Initiated MN Terminating Flows
                               (Setup cases)

   The teardown case can be handled in two ways also. If the route via
   the OAR is still available (directly or via the NAR), the MN can send
   an upstream hop-by-hop NSIS message which removes state on the old
   path and can carry delete-IP as a payload. If the route is
   unavailable, this message has to be sent upstream using the reverse
   path state of the new flow; from the UCOR to the CN it is handled as

Hancock et al              Expires April 2004                  [Page 23]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   normal, and at the UCOR it is turned round and used to remove the old
   path state via accelerated expiration. The same possibilities for a
   race condition exist as in the CN(sender) initiated case. These
   sequences are shown in Figure 11.

          MN                      UCOR                    CN
            ------>----->------>------>------>------>------>    | Flow
                      NSIS teardown & delete-IP                 | Tear
                                                                | (1)

            -------------------------->------>------>------>    |
                      NSIS teardown & delete-IP                 |
            <------<------<-------                              | Flow
             NSIS teardown on old                               | Tear
             segment if upstream                                | (2)
             message was sent via NAR                           |
             (accelerated expiration)                           |

          Figure 11: MN(Receiver)-Initiated MN Terminating Flows
                             (Teardown cases)

   Session Identifier Security Considerations: For this receiver
   initiated case, we have two security issues for the session
   identifier, and which ones are relevant depends on which setup
   message sequence is used.

   *) The 'Different Peer' Issue: When the UCOR sets up the sharing of
   signaling state for the two flows on the path back to the CN, it is
   essentially saying: "the state which I previously installed on behalf
   of my downstream peer on the old path [e.g. maybe the OAR] can now
   also be used on behalf of my downstream peer on the new path [e.g.
   maybe the NAR]". In other words, the UCOR has to reason that the two
   downstream peers (who could be in different administrative domains
   and may have no knowledge of each other) are happy to have their
   independent requests for upstream state use shared resources solely
   on the basis that the session identifiers match, and hence
   (presumably) that they originated with the same MN. A legalistic
   downstream peer on the old path might claim that the resources it had
   reserved and paid for on the shared segment had just been been
   stolen. This assumption is needed for both setup cases.

   *) The 'Indirect Initiator' Issue: In addition, when the 'speeded up'
   setup approach (case 1) is used, where the UCOR begins to install
   state sharing on the upstream path as soon as it has seen the
   downstream path state message with an existing session identifier for
   a new flow, the UCOR is doing this without having received any
   signaling message originating (directly or indirectly) from the MN

Hancock et al              Expires April 2004                  [Page 24]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   which actually initiated the signaling. In other words, the UCOR is
   saying "I believe that the new flow I am being told about for this
   session identifier is one which is for the same MN as the existing
   flow, and I therefore believe that MN will be happy for state to be
   shared between the two flows". If the UCOR is only willing to proceed
   after verifying this information by a signaling exchange which
   involves the MN itself, this reduces to the simpler case 1 setup
   approach, i.e. with no latency saving.

   Note that no additional considerations apply from the teardown case,
   because either signaling comes from the MN like a normal teardown or
   accelerated expiration is used.

4.4.  MN-Originating Session

   In the case where the session is originating at the MN, we have the
   situation shown diagrammatically in Figure 12.

                    +--+          +---+   new flow
          new       |MN|>>>>>>>>>>|NAR|>>>>>>>>>>>>>V
          address   +--+          +---+             V
                  ^                              +----+          +--+
                  |                              |DCOR|>>>>>>>>>>|CN|
                  |                              |    |>>>>>>>>>>|  |
                  |                              +----+          +--+
                  | +--+          +---+             ^    shared
          original  |MN|>>>>>>>>>>|OAR|>>>>>>>>>>>>>^    segment
          address   +--+          +---+   original
                  MN acts
                  as UCOR
                     Figure 12: Session from MN to CN

   The general treatment of the MN originating session is simpler than
   the MN terminating case, because the node which has moved can also
   directly generate the signaling which discovers the COR - there is no
   need to involve the CN in this process. However, we still expect
   there to be an end to end add-IP message, if only to inform the CN of
   the new address (without which traffic sent from this new address
   will probably be ignored or filtered). This message can be sent as
   soon as the new IP address is active, and traffic can be sent as soon
   as the add-IP procedure is complete. The remaining discussion differs
   between the MN- and CN-initiated cases.

4.4.1.  MN (Sender) Initiated Setup and Teardown

   The setup case is relatively simple here. The MN originates an NSIS
   signaling state setup message for the new flow with the same session
   identifier as for the existing flow (which it chose anyway).  This
   has to be sent on the new path (via the NAR) and state is set up from

Hancock et al              Expires April 2004                  [Page 25]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   the MN to DCOR in the normal way. The DCOR can be identified when it
   processes this message, and the remainder of the state is set up
   shared with the existing flow from the DCOR to the CN.

   For the teardown case, no delete-IP message is strictly needed (the
   MN just stops using the old address when it feels like it). If the
   NSIS teardown message can be sent using the old path (via the OAR),
   state teardown is done in the usual way (once the state for the new
   flow has been set up, i.e. to avoid losing the state completely on
   the shared segment). If only the new path is available, the message
   has to be sent via the DCOR and use accelerated expiration on the
   upstream segment from the DCOR towards the OAR. This is basically the
   same set of possibilities as for receiver-initiated MN-terminating
   flows (which is reasonable, since in each case it is the MN which is
   managing the signaling process).

   All these message sequences are shown in Figure 13.

          MN                      DCOR                    CN
           ------>----->------>------>------>------>------>    |
                  NSIS path state setup (hop by hop)           | Flow
                (possibly including add-IP as payload)         | Setup
           >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    |
                           Traffic start                       |

           ------>----->------>------>------>------>------>    | Flow
                     NSIS teardown & delete-IP                 | Tear
                                                               | (1)

           -------------------------->------>------>------>    +
                     NSIS teardown & delete-IP                 |
           <------<------<-------                              | Flow
            NSIS teardown on old                               | Tear
            segment if upstream                                | (2)
            message was sent via NAR                           |
            (accelerated expiration)                           |
          Figure 13: MN(Receiver)-Initiated MN Terminating Flows

   Session Identifier Security Considerations: The 'Different Peer'
   security issue applies to state sharing on the shared path segment
   identically as in the other MN initiated case.  However, since all
   state manipulation messages originate at the MN, the 'Indirect
   Initiator' issue does not arise.

Hancock et al              Expires April 2004                  [Page 26]

Internet-Draft        Routing and Mobility in NSIS          October 2003

4.4.2.  CN (Receiver) Initiated Setup and Teardown

   The setup case here has to install reverse path state to allow the
   signaling state manipulation messages to propagate upstream from the
   CN. Note that the reverse path state is being installed for the new
   flow, and at the DCOR this will be different from the reverse path
   state for the existing flow for that session. Therefore, the reverse
   path state must be indexed by the flow identification, rather than
   the session identification.

   Once reverse path state has been installed, signaling state
   installation can be done by two methods, similar to the other
   receiver initiated case. The difference is that the 'early' setup can
   take place on the new path segment rather than on the shared path

   Teardown is quite simple in this case. A delete-IP message is needed
   to inform the CN that the old flow is no longer active; however, once
   this has been received, the teardown can be initiated from the CN
   with normal signaling (the necessary reverse path state already
   exists to route this signaling).

   All these signaling exchanges are shown in Figure 14 below.

Hancock et al              Expires April 2004                  [Page 27]

Internet-Draft        Routing and Mobility in NSIS          October 2003

          MN                      DCOR                    CN

           ------>----->------>------>------>------>------>    +
                  NSIS path state setup (hop by hop)           |
                    (including add-IP as payload)              |
           >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>                    |
           Traffic start (optimistic MN)                       |
                                                               | Flow
           <-----<-----<------<------<------<------<-------    | Setup
                     NSIS signaling state setup                | (1)
                     (or sharing from DCOR to CN)              |
           >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>                    |
           Traffic start (pessimistic MN)                      |

           ------>----->------>------>------>------>------>    |
                  NSIS path state setup (hop by hop)      .    |
                    (including add-IP as payload)         .    |
           >>>>>>>>>>>>>>>>>>        .                    .    |
             Traffic start           .                    .    |
            (optimistic MN)          .                    .    |
                                     .                    .    |
           <-----<-----<------<------.                    .    |
               NSIS new state setup                       .    | Flow
                 from DCOR to MN                          .    | Setup
           >>>>>>>>>>>>>>>>>>                             .    | (2)
             Traffic start           .------<------<------.    |
          fairly optimistic MN)      . NSIS shared state       |
                                     .  setup to DCOR          |
                                     .                         |
           <-----<-----<------<------.                         |
                 Notification of                               |
                 setup complete                                |
                   (optional)                                  |
           >>>>>>>>>>>>>>>>>>                                  |
           Traffic start (pessimistic MN)                      |

           ----------------------------------------------->    |
                              delete-IP                        | Flow
                                                               | Tear
           <-----<-----<------<------<------<------<-------    |
                            NSIS teardown                      |
          Figure 14: CN(Receiver)-Initiated CN Terminating Flows

   Session Identifier Security Considerations: In this case, the shared
   path segment has both flows initiated by the same endpoint.
   Therefore, the 'Different Peer' issue does not arise. However, the
   'Indirect Initiator' issue arises in the second flow setup case,
   where the DCOR attempts to install state on the new path segment

Hancock et al              Expires April 2004                  [Page 28]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   before any signaling messages have arrived from the CN. As before,
   any confirmation exchange between the CN and DCOR reduces this case
   to the simpler setup exchange.

4.5.  Summary of the Analysis

   The most significant conclusion of the analysis is that the
   interaction with the authorisation model has extremely important
   impacts on the message flows. In many cases, the information needed
   to complete the mobility processing (updates on the shared path or
   installation/teardown on the new and old segments) is available at
   the crossover router quite early in the message exchange, but the
   crossover router may be unable to use it because it comes from an
   unknown neighbour or from the 'wrong direction'. This is therefore an
   authorisation issue. Authorisation interactions are sometimes
   considered as an 'add-on' during design, especially if some
   sophisticated special purpose authorisation protocol is being used.
   However, even the filtering that is done on messages to ensure they
   come from an appropriate source can be considered as an authorisation
   issue; ignoring these issues when designing the basic message flows
   is liable to mean that the protocol design ends up being
   fundemantally incapable of being secured against theft-of-service
   attacks and other abuses.

   Because the authorisation constraints arise from the hop-by-hop
   authorisation assumption, it might be that a more flexible or
   powerful authorisation model would make mobility handling much
   easier. For example, if the signaling initiator had a direct
   authorisation relationship with the COR, most of these problems would
   be eliminated.  However, the consequence of routing is that in
   general the COR can be anywhere in the network, and the precise
   location of the COR depends on what handover has taken place and the
   flow direction. Therefore, in general, to have a prior authorisation
   relationship with the COR means in practice that the signaling
   initiator must have this relationship with every NSIS node along the
   flow path; this is likely to be operationally infeasible.

   Two different session id security issues were identified, the
   'Different Peer' and 'Indirect Initiator' issues. The applicability
   of these issues is shown in the following table (which has some
   pleasing structural symmetries).

Hancock et al              Expires April 2004                  [Page 29]

Internet-Draft        Routing and Mobility in NSIS          October 2003

       Table 1: Applicability of Session Id Issues to Various Scenarios
       |    Mobile    | Sender or  | Different Peer |    Indirect    |
       | originating  |  receiver  |     issue      |   Initiator    |
       |      or      | initiated? |                |     issue      |
       | terminating? |            |                |                |
       | Terminating  |   Sender   |      N/A       |      N/A       |
       |  (inbound)   |            |                |                |
       | Terminating  |  Receiver  |   Applies to   |  Applies only  |
       |  (inbound)   |            |    resource    | if accelerated |
       |              |            |   sharing on   |    setup on    |
       |              |            | shared segment | shared segment |
       |              |            |                |  is done from  |
       |              |            |                |      UCOR      |
       | Originating  |   Sender   |   Applies to   |      N/A       |
       |              |            |    resource    |                |
       |              |            |   sharing on   |                |
       |              |            | shared segment |                |
       | Originating  |  Receiver  |      N/A       |  Applies only  |
       |              |            |                | if accelerated |
       |              |            |                |  setup on new  |
       |              |            |                |   segment is   |
       |              |            |                | done from DCOR |

   The indirect initiator issue applies in 50% of the cases, but only if
   speedup up state installation is needed from the COR. This case needs
   to be analysed from two perspectives:

    *) Whether the speedup is actually valuable. Clearly, in some cases
   (e.g. multihoming) it is probably not; on the other hand, if one is
   attempting to achieve a seamless hard IP handover, every speedup is
   valuable. Techniques such as those in [Thomas] could be used to model
   whether signalling is on the critical time path in the overall setup

    *) Whether the threat is real, and what form of session identifier
   protection mitigates it best.

   The different peer issue also applies in 50% of the cases, but is
   unavoidable in those cases. Whether it is a problem depends again on
   finer details of the authorisation model. For example, one approach
   would be for the second flow on the shared segment to be given a
   lower priority (if this concept is applicable to the signalling
   application in use); this prevents it from stealing resources from
   the first flow, only using resources that the first flow is not
   using. In slow time, the new peer would take over the session
   completely (e.g. after the first flow is deleted). This would be
   perfectly applicable for QoS signalling for example, but might be

Hancock et al              Expires April 2004                  [Page 30]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   very dangerous for middlebox control.

   The analysis also exposes some interesting protocol interactions in
   the end system, especially concerning how and when addresses are
   allocated and released and used for traffic, and how and when session
   identifiers are allocated and coordinated. Race conditions could be
   commonplace and additional end-to-end or end-to-COR acknowledgements
   might be needed to handle them. This requires further call flow
   analysis, but can probably only be completed once the allocation of
   mobility functionality to different layers of the NSIS protocol stack
   has been defined in more detail.

   A topic that has not yet been considered is the use of network
   internal mobility proxies (e.g. as are used in several local mobility
   management schemes). These have several properties which are very
   relevant to the issues analysed here, in particular:

    *) they may be able to hide the end system address change (making it
   look more like a routing change);

    *) they may provide a fixed internal node which will always be the
   COR for a local mobility event, or at least allow the COR to be pre-
   authorisation between the MN and proxy, which could address both of
   the session id security issues (especially the indirect initiator

   Further analysis of such LMM solutions is needed to determine whether
   there is a common signalling approach to each of them, and whether
   signalling interactions with them can be constrained inside the
   network or whether it would require different behaviour in MN or
   (even worse) CN to exploit them.

4.6.  Further Interactions with Fast Handover Protocols

   In the context of mobility between different access routers, it is
   common to consider additional local performance optimizations in two
   areas: selection of the best access router to handover to, and
   transfer of state information between the access routers to avoid
   having to regenerate it in the new access router after handover. The
   Seamoby working group is developing protocols solutions for these
   functions (CARD and CT respectively) but the following considerations
   apply to these functions in general, regardless of which particular
   protocol is used to implement them.

   Detailed solutions are not proposed here, but rather a discussion of
   the way in which these functions should interact with NSIS signaling.
   In addition, signaling should be able to operate independently of
   these protocols (and this is the assumption for the main mobility
   analysis earlier in this document). However, significant performance
   gains could be achieved if they could be made to cooperate. In
   addition, the resource signaling aspects of these CARD/CT and NSIS
   protocols could profitably use a common set of resource types and
   definitions, since they will probably be supporting the same overall

Hancock et al              Expires April 2004                  [Page 31]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   signaling application.

   The question arises, what the mode of interaction should be:
   independent operation, NSIS triggering access router discovery and
   state transfer, or vice versa. The questions for the two cases seem
   to be independent.

   For access router discovery, a typical model of operation is that the
   mobile carries out an information gathering exercise about a range of
   capabilities. In addition, where those capabilities relate purely to
   the AR and mobile, there is no role for NSIS (its special
   functionality is not relevant). However, considering resource
   aspects, one aspect of the AR 'capability' is resource availability
   on the path between it and the correspondent, and NSIS should be able
   to fulfill this part. Indeed, this is effectively precisely the
   application considered in [7], where it is a sort of special case of
   resource signaling during handover. This means that CARD should be
   able to trigger some of the NSIS signalling, maybe discovering COR
   location and checking admission control status on the new path,
   before the handover has actually taken place.

   Therefore, a possible model of access router discovery/NSIS
   relationship is that some entity in a candidate AR triggers NSIS
   using resource and reservation information (including session id)
   from the current AR to find out about what would be available on the
   new path. Note that this should be a query rather than an actual
   state setup; this semantic could be included either in the service
   definition or the signalling itself.

   The case of state transfer is more complex. There are two obvious
   options, corresponding to whether one transfers just signaling
   application state or NSIS protocol state as well:

    1. "State transfer triggering NSIS": A state transfer process passes
   the to request that resource.

    2. "NSIS using state transfer": NSIS transfers its own state
   information from the old to the new AR. It can then carry out the
   same update signaling as though it was a single 'virtual AR' which
   had just had a topology change towards the correspondent. (This is
   essentially the conceptual model of [8].)

   The first model is simpler, and maybe more in line with the basic
   state transfer expectation; however, it seems hard to avoid double
   reservations since the two NSIS protocol instances are not
   coordinated (if we regard the session identifier as part of NSIS
   protocol state rather than signaling application state). In addition,
   NSIS protocol state may itself be time consuming to set up (for
   example, if it requires peer-peer authentication before actual
   signaling messages can be transferred.) Therefore, the second model
   seems more appropriate. An advantage of the 'virtual AR' model is
   that it ensures that the impact of the interaction is limited to the
   NSIS instances at ARs themselves, since the rest of the network must
   be able to handle a topology change anyway: the scenario looks more

Hancock et al              Expires April 2004                  [Page 32]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   like a route change with an IP address change rather than a full
   mobility event.

   Note that there is an open issue of who is responsible between the
   mobile and AR to decide that the state transfer procedures have not
   happened for whatever reason - e.g. because they were not even
   implemented - and take recovery action to have the mobile refresh
   reservations promptly. It appears this has to be an NSIS
   responsibility in the AR, and probably requires a custom notification
   message for this circumstance.

5.  Security Considerations

   This draft discusses signaling flows to handle route change and
   mobility events and multihoming scenarios. Many security
   considerations apply to such signaling flows; in particular, all the
   issues of message protection, denial of service protection, theft and
   abuse of service, authorisation and so on that apply to the 'normal'
   signaling case continue to apply here also.

   Some special considerations arise from the route change/mobility
   issues discussed in this draft. In particular, authorisation for path
   change (for flows) and more particularly for flow change (for
   sessions) needs to be considered carefully. The latter is extensively
   discussed in section 4, and section 4.5 in particular.

   A second special issue is the need to do rapid signaling exchanges
   during or after handovers. This is not a security issue itself, but
   it does impose new performance constraints on the security mechanisms
   that are used to protect signaling in general. Specifically, in the
   case of a MN attaching to a new AR, the need for time consuming node
   authentication procedures before signaling information can be
   exchanged should be minimised; this might be a motivation for context
   transfer of such authentication state.

   It appears that there are few or no new basic denial of service
   attacks that arise in these scenarios (or rather, any attack that
   could be mounted in these scenarios could also be mounted in the
   normal case).  Instead, the new problem is that signaling flows which
   might have been seen as denial of service attacks in the normal case
   (such as signaling messages for a flow arriving from a previously
   unknown peer) now have to be treated as potentially legitimate and
   secured by other means.

   Once the functionality described in this document has been allocated
   to specific components in the NSIS protocol suite, a more complete
   security analysis of the overall protocol behaviours will be
   required. In the meantime, consideration of the scenarios described
   here may be helpful in refining the view of what are the realistic
   security goals for NSIS signaling as a whole.

Hancock et al              Expires April 2004                  [Page 33]

Internet-Draft        Routing and Mobility in NSIS          October 2003

6.  Contributors

   This draft initially written by Robert Hancock, Jukka Manner, and
   Charles Q. Shen.

7.  Acknowledgments

   Acknowledgments go to Xiaoming Fu, Eleanor Hepworth, Cornelia
   Kappler, Georgios Karagiannis, Andrew McDonald, Henning Schulzrinne,
   Hannes Tschofenig.

8.  Informative References

   [1] R. Hancock, et al., "Next Steps in Signaling: Framework".
   Internet Draft (work in progress), draft-ietf-nsis-fw-04

   [2] H. Schulzrinne, "CASP - Cross-Application Signaling Protocol".
   Internet Draft (work in progress), draft-schulzrinne-nsis-casp-01

   [3] S. van den Bosch, et al., "NSLP for Quality-of-Service
   Signaling".  Internet Draft (work in progress), draft-ietf-nsis-qos-

   [4] H. Tschofenig, et al., "Security Implications of the Session
   Identifier".  Internet Draft (work in progress), draft-tschofenig-

   [5] P. Nikander, et al., "Mobile IP version 6 Route Optimization
   Security Design Background". Internet Draft (work in progress),

   [6] H. Tschofenig, et al., "QoS NSLP Authorization Issues". Internet
   Draft (work in progress), draft-tschofenig-nsis-qos-authz-issues-00

   [7] X. Fu, et al., "QoS-Conditionalized Binding Update in Mobile
   IPv6". Internet Draft (work in progress), draft-tkn-nsis-qosbinding-

   [8] M. Thomas, "Analysis of Mobile IP and RSVP Interactions".
   Internet Draft (work in progress), draft-thomas-nsis-rsvp-analysis-00

9.  Author's Addresses

   Questions about this document may be directed to:

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

   Voice:  +44-1794-833601

Hancock et al              Expires April 2004                  [Page 34]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   Fax:    +44-1794-833434

   Jukka Manner
   Department of Computer Science
   University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)

   Voice:  +358-9-191-44210
   Fax:    +358-9-191-44441

   Charles Q. Shen
   Department of Electrical Engineering
   Columbia University
   500 West 120th Street
   New York, NY 10027

   Voice: +1-212-854-5599
   Fax: +1-212-932-9421

Hancock et al              Expires April 2004                  [Page 35]

Internet-Draft        Routing and Mobility in NSIS          October 2003

   Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Hancock et al              Expires April 2004                  [Page 36]