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



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


Copyright Notice


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


Abstract


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




Lee, et al.              Expires April 18, 2005                 [Page 1]


Internet-Draft          Applicability Statement             October 2004



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


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements Notation and Terminology  . . . . . . . . . . . .  4
   3.  Problem Statement and General Considerations . . . . . . . . .  7
     3.1   Problem statement  . . . . . . . . . . . . . . . . . . . .  7
     3.2   General considerations . . . . . . . . . . . . . . . . . .  9
   4.  Basic Operations for Mobility Support  . . . . . . . . . . . . 10
     4.1   Generic route changes and mobility . . . . . . . . . . . . 10
     4.2   CRN discovery  . . . . . . . . . . . . . . . . . . . . . . 13
       4.2.1   Possible approaches for CRN discovery  . . . . . . . . 13
       4.2.2   The identifiers for CRN discovery  . . . . . . . . . . 14
       4.2.3   The procedure of CRN discovery . . . . . . . . . . . . 16
     4.3   Path update  . . . . . . . . . . . . . . . . . . . . . . . 17
       4.3.1   State setup and update . . . . . . . . . . . . . . . . 17
       4.3.2   State teardown . . . . . . . . . . . . . . . . . . . . 19
   5.  Mobility-Related Issues with NSIS Protocols  . . . . . . . . . 20
     5.1   Specific issues with NTLP  . . . . . . . . . . . . . . . . 20
     5.2   Specific issues with QoS-NSLP  . . . . . . . . . . . . . . 21
     5.3   Specific issues with NAT/FW NSLP . . . . . . . . . . . . . 23
     5.4   Common issues related to NTLP and NSLP . . . . . . . . . . 24
   6.  Applicability Statement  . . . . . . . . . . . . . . . . . . . 24
     6.1   Support for macro mobility-based scenarios . . . . . . . . 24
       6.1.1   Implications to Mobile IP-related scenarios  . . . . . 25
         6.1.1.1   Mobile IPv4-specific issues  . . . . . . . . . . . 27
         6.1.1.2   Mobile IPv6-specific issues  . . . . . . . . . . . 29
     6.2   Multihoming scenarios  . . . . . . . . . . . . . . . . . . 31
       6.2.1   Overview . . . . . . . . . . . . . . . . . . . . . . . 31
       6.2.2   Some examples of NTLP/NSLP support . . . . . . . . . . 31
     6.3   QoS performance considerations in mobility scenarios . . . 32
     6.4   Use cases of identifiers . . . . . . . . . . . . . . . . . 34
     6.5   Peer failure scenarios . . . . . . . . . . . . . . . . . . 35
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 37
     7.1   MN as data sender  . . . . . . . . . . . . . . . . . . . . 37
       7.1.1   MN is authorizing entity . . . . . . . . . . . . . . . 37
       7.1.2   CN is authorizing entity . . . . . . . . . . . . . . . 39
         7.1.2.1   CN asks MN to trigger action (on behalf of the
                   CN)  . . . . . . . . . . . . . . . . . . . . . . . 40
         7.1.2.2   CN uses installed state to route message
                   backwards  . . . . . . . . . . . . . . . . . . . . 41
         7.1.2.3   MN and CN are authorized . . . . . . . . . . . . . 42
       7.1.3   CN as data sender  . . . . . . . . . . . . . . . . . . 42
         7.1.3.1   CN is authorizing entity . . . . . . . . . . . . . 42
         7.1.3.2   MN is authorizing entity . . . . . . . . . . . . . 44




Lee, et al.              Expires April 18, 2005                 [Page 2]


Internet-Draft          Applicability Statement             October 2004



       7.1.4   Multi-homing Scenarios . . . . . . . . . . . . . . . . 44
         7.1.4.1   MN as data sender  . . . . . . . . . . . . . . . . 44
         7.1.4.2   CN as data sender  . . . . . . . . . . . . . . . . 45
       7.1.5   Proxy Scenario . . . . . . . . . . . . . . . . . . . . 46
       7.1.6   Conclusion . . . . . . . . . . . . . . . . . . . . . . 46
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 47
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 47
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 48
       Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 49
       Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 50
       Intellectual Property and Copyright Statements . . . . . . . . 51








































Lee, et al.              Expires April 18, 2005                 [Page 3]


Internet-Draft          Applicability Statement             October 2004



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 identifier.  Local mobility usually does
   not cause the change of the global IP addresses, but affects the
   routing paths within the local access network.


   The goals of this draft are to present the effects of mobility on the
   NSIS Transport Layer Protocol (NTLP) and on the NSIS Signaling Layer
   Protocols (NSLP).  The NTLP is an application independent protocol to
   transport service-related information between nodes in a network, 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 discusses the operation of the NSIS protocols in very
   basic mobility scenarios (e.g., macro-mobility management protocols
   such as Mobile IPv4 and Mobile IPv6), including support for
   multi-homing.  More complex scenarios and issues of 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.


   O  Downstream


      The direction from a data sender towards the destination.


   O  Upstream


      The direction from a data destination towards the sender.


   O  Crossover Node (CRN)




Lee, et al.              Expires April 18, 2005                 [Page 4]


Internet-Draft          Applicability Statement             October 2004



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


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


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


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


            NSIS CRN is 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 to perform the path update.


         There are some differences between route changes and mobility
         in forming 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 receiver 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 April 18, 2005                 [Page 5]


Internet-Draft          Applicability Statement             October 2004



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


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


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


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


   O  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 sender, the Path Update is initiated by an NI on
         the common path (e.g., a CN, an HA, or an MAP).


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


      In case of route changes, the update of NSIS state on the common
      path is not required and it is called Local Repair which localizes
      the NSIS signaling.  Especially, in mobility scenarios, if the




Lee, et al.              Expires April 18, 2005                 [Page 6]


Internet-Draft          Applicability Statement             October 2004



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


   O  Dead Peer Discovery (DPD)


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


   O  Downlink


      The direction from the CN towards the MN.


   O  Uplink


      The direction from the MN towards the CN.




3.  Problem Statement and General Considerations


3.1  Problem statement


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


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


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


   O  Latency of route changes


      The change of route and IP addresses 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.


   O  Explicit routes


      Signaling protocols usually expect the data traffic to follow the
      same path as the signaling traffic, but the data traffic sometimes
      traverses the path different from the path of signaling traffic




Lee, et al.              Expires April 18, 2005                 [Page 7]


Internet-Draft          Applicability Statement             October 2004



      due to the adaptation of routing protocol according to varying
      network conditions such as load balancing, load sharing and
      mobility.  For example, Mobile IP adds the possibility to use
      routing headers to define explicit routes, which diverts the
      traffic from an expected path.


   O  IP-in-IP encapsulation


      Mobility protocols may use IP-in-IP encapsulation on the segments
      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.


   O  Ping-pong type handover


      NSIS needs to remove states quickly along the old path in order 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 it adds overhead.


   O  Upstream Path Update vs.  Downstream Path Update


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


   O  State identification problem


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


   O  Double reservation Problem


      Since the state on the old path (and the common path) still




Lee, et al.              Expires April 18, 2005                 [Page 8]


Internet-Draft          Applicability Statement             October 2004



      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 existing state on the old path can
      be torn down by the timeout of soft state, the refresh timer value
      in the core or wired network is quite long (e.g., 30 seconds in
      QoS-NSLP).  As a result, in case of QoS-NSLP, the double
      reservation problem leads to the waste of resources and call
      blocking.


   O  End-to-end signaling Problem


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


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


3.2  General considerations


   This draft discusses NSIS state establishment (e.g., QoS-NSLP, NAT/
   FW, etc) in the macromobility-based scenarios (e.g., basic Mobile IP
   (v4 and v6) handovers) and the interaction with the specific
   micromobility protocols leading to performance optimization of NSIS
   signaling will be left for future work.


   Our assumptions in this document and the general considerations are:


   O  Session-ID is used to index state


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




Lee, et al.              Expires April 18, 2005                 [Page 9]


Internet-Draft          Applicability Statement             October 2004



      most handover procedures.


   O  Routing may be asymmetric


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


   O  The CN is not a mobile device


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




4.  Basic Operations for Mobility Support


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


4.1  Generic route changes and mobility


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


   Although the mobility may be considered similar to the route changes,
   the main difference is that the Message Routing Information (MRI:
   e.g., flow identifier) may not change after the route 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 changes brings on the change of signaling topology and it




Lee, et al.              Expires April 18, 2005                [Page 10]


Internet-Draft          Applicability Statement             October 2004



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



                               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.1 The topology for NSIS signaling in case of the route changes


   However, the mobility results in creating a common path, an old path,
   and a new path, and the old and new paths only converge or diverge




Lee, et al.              Expires April 18, 2005                [Page 11]


Internet-Draft          Applicability Statement             October 2004



   according to the direction of each signaling flow as shown in Figure
   2.



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


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


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


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


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


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



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


   These topological changes caused by mobility make the signaling state
   established on the old path useless and therefore it should be
   removed (in the end).  In addition, the existing NSIS state should




Lee, et al.              Expires April 18, 2005                [Page 12]


Internet-Draft          Applicability Statement             October 2004



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


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


4.2  CRN discovery


4.2.1  Possible approaches for CRN discovery


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


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




Lee, et al.              Expires April 18, 2005                [Page 13]


Internet-Draft          Applicability Statement             October 2004



   identifier, so signaling application can be identified at the NTLP
   level.  For example, in the connection mode of NTLP, when NTLP
   establishes a messaging association between two adjacent peers, the
   NTLP peers exchange message routing state information through GIMPS
   query and response messages.  Therefore, although the CRN can be
   discovered at the NTLP level, the discovered CRN could be actually
   NSLP-aware node which has an involved signaling application.


   There can also be two different approaches for CRN discovery
   according as whether the discovery is coupled with signaling message
   or not: the coupled approach and uncoupled approaches.  If the
   signaling to update NSIS state along a new path or the common path,
   after route changes or mobility, is done simultaneously with the CRN
   discovery procedure, it is called the coupled approach.  If the
   signaling to do Path Update is done after the CRN discovery is
   completed, it is called the uncoupled approach.  These approaches may
   have some effect on security aspect.  Generally, the coupled approach
   would be preferred to the uncoupled approach to reduce the delay for
   signaling setup.  Note that CRN discovery and Path Update described
   in this draft are based on the coupled approach.


4.2.2  The identifiers for CRN discovery


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


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


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


   The NSLP branch identifier as a virtual branch identifier can be used
   to establish or delete NSIS associations between peers and it can
   also be used as an identifier to determine the CRN at the GIMPS
   layer.  The NSLP branch identifier can consist of the location
   information of peer nodes with the correspondent NSLP ID by the




Lee, et al.              Expires April 18, 2005                [Page 14]


Internet-Draft          Applicability Statement             October 2004



   procedure of GIMPS message association.  For instance, as shown in
   Figure 3, for the downstream case, NSLP1 of node A requires a
   messaging association for sending its messages towards node D after a
   route changes.  In this case, NSIS entity A creates an NSLP branch ID
   for NSLP 1 toward node D and increases the counter of NSLP branch ID
   to locally distinguish each virtual interface identifier between
   adjacent NSLP peers: the corresponding NSLP br.ID is 1-D-#2
   (NSLP_ID-flow_direction (D or U)-br_counter_No).  Note that the NSLP
   branch identifier can be included in the NSIS message, but it can
   also be considered as an implementation issue.  This identifier would
   be more useful when the merging point of the old path and a new path
   is not an NSLP CRN after the route changes as shown in Figure 3 (a).



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


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


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


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


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




Lee, et al.              Expires April 18, 2005                [Page 15]


Internet-Draft          Applicability Statement             October 2004



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


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


      Figure.3 Routing state table and NSLP branch ID


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


4.2.3  The procedure of CRN discovery


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


   -  Whether the same NSLP ID exists


   -  Whether the corresponding CRN is already discovered


   -  Whether the same session identifier and MRI exist


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


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





Lee, et al.              Expires April 18, 2005                [Page 16]


Internet-Draft          Applicability Statement             October 2004



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


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


   -  When an MN (as a sender) undergoes handover, the UCRN can be
      determined for upstream flow by the method above.  In this case,
      the UCRN should be the node (closet to the MN) where the signaling
      flow begins to logically diverge: it is similar to the creation of
      the routing table of node A as shown in Figure 3 (b) except for
      the unchanged flow ID.  Since the UCRN is determined by whether
      outgoing path diverges or not, the UCRN discovery is more complex
      than the DCRN discovery.


4.3  Path update


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


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


4.3.1  State setup and update


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




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


Internet-Draft          Applicability Statement             October 2004



   Path Update also needs to have an appropriate priority over local
   requests for the resources.


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


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


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


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






Lee, et al.              Expires April 18, 2005                [Page 18]


Internet-Draft          Applicability Statement             October 2004



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


     (a) Sender Initiated Reservation



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


      (b) Receiver Initiated Reservation


     Figure.4 Sender- vs. Receiver-initiated reservation


4.3.2  State teardown


   After re-establishment of the NSIS state along the new path, the
   state on the obsolete path need to be quickly removed by path update
   mechanism to prevent the waste of resources due to double reservation
   (and resource allocation problem by call blocking) and to reduce the
   cost of using the resources in the access network as described in
   Section 3.1.  Although the release of the existing state on the old
   path can be accomplished by timeout of soft state, the refresh timer




Lee, et al.              Expires April 18, 2005                [Page 19]


Internet-Draft          Applicability Statement             October 2004



   value may be quite long and the maintenance of the NSIS state on the
   obsolete path may not be necessary.  Therefore, the transmission of a
   teardown message is particularly preferred to the use of refresh
   timer to quickly delete the old state.  Note that, however, it is not
   necessary for the GIMPS to be explicitly removed because of the
   inexpensiveness of the state maintenance 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.  In
   this case, the release of old state on the obsolete path can be
   accomplished by comparing the NSLP branch IDs and through reverse
   routing using SII.  This can prevent the teardown message from being
   forwarding toward along the common path.  However, whether the
   teardown message can be sent toward the opposite direction to the
   state initiating node is still an open question.  This also leads to
   authorization problem because a node which does not initiate
   signaling for establishing the NSIS state can delete the state.


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




5.  Mobility-Related Issues with NSIS Protocols


5.1  Specific issues with NTLP


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


   NTLP is responsible for detecting route changes, updating its own
   routing state consistently, and informing NSLPs at affected nodes.




Lee, et al.              Expires April 18, 2005                [Page 20]


Internet-Draft          Applicability Statement             October 2004



   In mobile environments, for an end-to-end signaling flow, its
   signaling path can be changed upon a successful Mobile IP
   registration.  This means a new peer discovery procedure needs to be
   triggered (e.g., through certain routing interface) and a new NTLP
   message routing state must be adapted.


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


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


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


5.2  Specific issues with QoS-NSLP


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


   -  When/how should QoS-NSLP signaling be initiated after mobility?




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


Internet-Draft          Applicability Statement             October 2004



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


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


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


   -  How/by who can RESPONSE message be sent to the corresponding QNI
      if QNR (e.g., an MN)  performs handover before the receipt of the
      message? If RESERVE (for refresh) including Response request is
      sent to the MN from a node but the MN begins to handover the OAR
      in behalf of the MN may be a proxy to initiate RESPONSE message.
      In this case, the MN may notify OAR of the handover or error
      conditions (the-last-node-is-not-detected) using NOTIFY message.
      This ½invalid-NR¯ problem is discussed further in Section 6.5.


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




Lee, et al.              Expires April 18, 2005                [Page 22]


Internet-Draft          Applicability Statement             October 2004



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


   Some issues according to performance gain (for example, refresh
   reduction) and dead peer are discussed further in Section 6, The
   advanced features such as bi-directional reservation, aggregation
   reservation, session binding, layering, peer agreement, and so on
   will be future work and the second part of mobility discussion.


5.3  Specific issues with NAT/FW NSLP


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


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


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




Lee, et al.              Expires April 18, 2005                [Page 23]


Internet-Draft          Applicability Statement             October 2004



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


5.4  Common issues related to NTLP and NSLP


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


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




6.  Applicability Statement


6.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,
   and other global mobility approaches will be discussed further in the
   next version of this draft.


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


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




Lee, et al.              Expires April 18, 2005                [Page 24]


Internet-Draft          Applicability Statement             October 2004



      an appropriate CRN discovery and a Path Update.


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


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


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


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


6.1.1  Implications to Mobile IP-related scenarios


   As NSIS is path-coupled signaling, one imposed requirement here is
   that the NSIS protocols are to be typically associated with a route
   changes for route optimization  between the CN & the MN and an
   IP-in-IP encapsulation from the HA to the MN, and those interaction
   also needs to be notified to all NSLPs by the API between GIMPS and




Lee, et al.              Expires April 18, 2005                [Page 25]


Internet-Draft          Applicability Statement             October 2004



   NSLP for the CRN discovery and the Path Update as described in
   Section 4.  Therefore, NTLP or NSLP needs to have an interface with
   the Mobile IP to immediately react to the mobility event.  In other
   words, NSIS implementation needs to be designed to react based on the
   endpoint notification of which behaviour of Mobile IP has taken place
   and probably, when the timer of Mobile IP refreshes (to keep
   corresponding NSLPs appropriate reacting to it).


   An ideal interface between NSIS signaling and the Mobile IP should
   make that NSIS signaling is able to react to the mobility event as
   soon as possible whenever Mobile IP changes its characteristics in
   any place for the flows.  In general, it is appropriate that NTLP is
   involved in the interaction with the Mobile IP 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 of the update of state when mobility is detected.
   Here also are some issues which rise when the API between the NSIS
   and the Mobile IP is considered.


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


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


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


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




Lee, et al.              Expires April 18, 2005                [Page 26]


Internet-Draft          Applicability Statement             October 2004



6.1.1.1  Mobile IPv4-specific issues


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


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




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


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


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


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


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


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





Lee, et al.              Expires April 18, 2005                [Page 27]


Internet-Draft          Applicability Statement             October 2004



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


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



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


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


   Figure 5. Implications for signaling under different Mobile IPv4
             scenarios


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


   -  For downstream signaling flow, the MN needs to perform the CRN
      discovery (DCRN) and the (downstream) Path Update toward the CN as
      described in Section 4 to establish the NSIS state along the new
      path between the MN and the CN as shown in Figure 5 (a).  If the
      reverse tunnel is used and the state along the tunneling path does
      not exist, the NSIS state may be established along the tunneling
      path from the FA to the HA  as shown in Figure 5 (b).  In this
      case, the DCRN may be discovered on the tunneling path and the new
      flow identifier for the tunneling state update may need to be
      created.


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


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


   -  For downstream signaling flow, the NSIS signaling for the DCRN




Lee, et al.              Expires April 18, 2005                [Page 28]


Internet-Draft          Applicability Statement             October 2004



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


   -  For upstream signaling flow, the NSIS signaling for the UCRN
      discovery and the Path Update is also equal to the case for FA CoA
      above (as shown in Figure 5 (d)) except the end of point of
      tunneling path.  That is, the NSIS state may be established along
      the tunneling path from the HA to the MN  as shown in Figure 5
      (e).


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


6.1.1.2  Mobile IPv6-specific issues


   The Mobile IPv6 case differs from Mobile IPv4 in that an FA is not
   required in the data path and the Route Optimization process between
   the MN and CN is basically used to avoid the triangular routing in
   the Mobile IPv4 scenarios as shown in Figure 6 [10].  Therefore, if
   the use of route optimization is not mandatory, data flow routing and
   NSIS signaling procedure (including the CRN discovery and the Path
   Update) of Mobile IPv6 would be similar to that of the Mobile IPv4
   described in Section 6.1.1.1.


   When an MN (as a sender) arrives at a new AR and the binding process
   is successfully completed, for downstream signaling flow, the MN may
   initiate NSIS signaling for DCRN discovery and the (downstream) Path
   Update to establish the state along the new path between the MN and
   the CN or the tunneling path from the MN to the HA if the reverse
   tunnel is used, as shown in Figure 6 (a) & (b), respectively.  For
   upstream signaling flow, the CN may also update the state along the
   common path toward the HA through the Path Update and afterward the
   NSIS state along the tunneling segment from the HA to the MN may be
   updated by interaction with IP tunneling  as shown in Figure 6 (d).
   However, if the route optimization is performed successfully between
   the CN and the MN, for upstream flow, CN needs to newly initiate NSIS
   signaling to discover an appropriate UCRN and do the Path Update
   along a new path between the CN and the MN as shown in Figure 6 (c):




Lee, et al.              Expires April 18, 2005                [Page 29]


Internet-Draft          Applicability Statement             October 2004



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


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




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


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


         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 April 18, 2005                [Page 30]


Internet-Draft          Applicability Statement             October 2004



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


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


   Figure 6. Implications for signaling under different Mobile IPv6
   scenarios


6.2  Multihoming scenarios


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


6.2.2  Some examples of NTLP/NSLP support


   NTLP uses an endpoint address (e.g., CoA) to install message routing
   state.  In multi-homed MN scenarios, there can be multiple CoAs for
   the MN, and therefore an appropriate CoA should be selected to
   establish NSIS state between the MN and CN.  If the multi-homed MN
   has multiple network interfaces, each network interface may use a
   different CoA.  To find a feasible signaling path, multiple NSIS
   messages (e.g., multiple QUERY messages) may be sent from the MN to




Lee, et al.              Expires April 18, 2005                [Page 31]


Internet-Draft          Applicability Statement             October 2004



   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).  According to the decision, the HA or CN could send a
   signaling message (e.g., RESERVE) for further action.


   In case of handover where the new CoA for an MN introduced in Mobile
   IP has to invoke a change of message routing state, both new and old
   addresses can be 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 certain NSIS state update on the new path during
   this period, however the signaling ends need to be careful, so that
   the correct routing information will be delivered for setting up new
   or updating existing message routing state in the correct path
   segment.  Furthermore, performing such actions should not cause NSLP
   service interruption, protocol misbehaviors or security holes.


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


   For load balancing, NSIS may need to install NSIS state along
   multiple paths.  In this case, multiple NSIS messages (e.g., multiple
   QUERY messages) could be sent to the remote endpoint to establish
   NSIS state although the sender is the same MN.  In this way, multiple
   paths for load balancing can be set up between the same ends.


   A more detailed analysis of the NTLP/NSLP functionality in different
   multihomed scenarios (e.g., including load balancing, moving
   multi-home MN, bi-casting, etc.) will be presented in the next
   version.


6.3  QoS performance considerations in mobility scenarios


   The routing characteristics of mobile IP system described in Section
   6.1 cause the session path to be changed and in this case the exiting
   protocols which do not support NSIS signaling in dynamic environment
   can cause the problems addressed in Section 3.1.  Particularly, in
   mobile/wireless environments, QoS parameters such as resource
   utilization and signaling latency need to be considered so that how
   NSIS protocols should interact with mobility protocols is correctly
   evaluated.  In the perspective of resource utilization, the double
   reservation problem (leading to the waste of resource and call
   blocking) in various handover scenarios may be alleviated by the
   procedure of the CRN discovery and the Path Update described in
   Section 4.  However, we need to take into consideration how the
   resource utilization of the NSIS signaling flow itself can be




Lee, et al.              Expires April 18, 2005                [Page 32]


Internet-Draft          Applicability Statement             October 2004



   managed: The adjustment of refresh time interval and refresh
   reduction.


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


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


   After the state along a new path established, QNEs along the
   signaling path may send refresh message to the neighboring peer node
   before the expiration of refresh timer to only update the state
   previously installed along the path or the changed flow ID along the
   common path after the CRN discovery.  In this case, the overhead
   required to perform refreshes can be reduced, in similar way to that
   proposed for RSVP [Refresh Reduction]: Refresh Reduction.  Once a
   RESPONSE message has been received indicating the successful
   installation of a reservation, subsequent refreshing RESERVE messages




Lee, et al.              Expires April 18, 2005                [Page 33]


Internet-Draft          Applicability Statement             October 2004



   can simply refer to the existing reservation, rather than including
   the complete reservation specification.  For example, only the
   Session_ID and the SII with no QSPEC at all are sent to just refresh
   the state (e.g., reservation) previously installed and additionally
   the changed flow ID with together those IDs is only sent to update it
   along the common path.  Especially, the use of reduced refresh
   messages over wireless channels or in access networks as well as in
   core networks results in having the advantage of efficient
   utilization of resources.


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


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


6.4  Use cases of identifiers


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


   When an NSIS signaling message (e.g., RESERVE) with an existing SID
   and a different SII is received, an NE (e.g., QNE) knows its upstream
   peer has changed.  In mobile environments, the SID and SII can be
   used to detect the CRN.  For example, after the handover of an MN, if
   an NE (e.g., QNE) on the data path receives an NSLP message (e.g.,
   RESERVE) with an SID for which it already has state installed but




Lee, et al.              Expires April 18, 2005                [Page 34]


Internet-Draft          Applicability Statement             October 2004



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


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


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


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


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


6.5  Peer failure scenarios


   A dead peer can occur either because a link or a network node failed,
   or because the MN moved away without informing NSLP/NTLP (it is




Lee, et al.              Expires April 18, 2005                [Page 35]


Internet-Draft          Applicability Statement             October 2004



   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.


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


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


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


   The failure of an AR may make the interactions with Seamoby protocols
   (such as CARD and CT) impossible.  In this case, the neighboring peer
   closest to the dead AR may need to interact with such protocols.  A
   more detailed analysis of interactions with Seamoby protocols is
   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.









Lee, et al.              Expires April 18, 2005                [Page 36]


Internet-Draft          Applicability Statement             October 2004



7.  Security Considerations


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


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


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


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


7.1  MN as data sender


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


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


7.1.1  MN is authorizing entity


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


   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?





Lee, et al.              Expires April 18, 2005                [Page 37]


Internet-Draft          Applicability Statement             October 2004



   -  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


              Figure 7: MN authorized initial reservation


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


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



       MN                    DCRN                      CN


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


                      Figure 8: MN authorizes DCRN


   The following questions are of interest:


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




Lee, et al.              Expires April 18, 2005                [Page 38]


Internet-Draft          Applicability Statement             October 2004



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


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


   The case of a corresponding node triggering an action is discussed in
   the paragraph below.  Figure 9 shows the exchange graphically.


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



       MN                    DCNR                       CN


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


                      Figure 9: CN triggers action


   The following questions arise:


   -  Why should the MN trust the trigger?


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


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


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


7.1.2  CN is authorizing entity


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




Lee, et al.              Expires April 18, 2005                [Page 39]


Internet-Draft          Applicability Statement             October 2004



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


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


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



      MN                    DCRN                          CN


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


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


   The following questions need to be considered:


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


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




Lee, et al.              Expires April 18, 2005                [Page 40]


Internet-Draft          Applicability Statement             October 2004



      from the CN and the MN?


7.1.2.2  CN uses installed state to route message backwards


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



      MN                    DCNR                          CN


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


     Figure 11: CN uses installed state to route message backwards


   Figure 11 raises a few questions:





Lee, et al.              Expires April 18, 2005                [Page 41]


Internet-Draft          Applicability Statement             October 2004



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


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


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


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


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


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


7.1.2.3  MN and CN are authorized


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


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


7.1.3  CN as data sender


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


7.1.3.1  CN is authorizing entity





Lee, et al.              Expires April 18, 2005                [Page 42]


Internet-Draft          Applicability Statement             October 2004



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



       MN                    UCNR                      CN


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


               Figure 12: CN as data sender is authorized


   Since the mobile node first detects the route 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 12.


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


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




Lee, et al.              Expires April 18, 2005                [Page 43]


Internet-Draft          Applicability Statement             October 2004



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


7.1.3.2  MN is authorizing entity


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


7.1.4  Multi-homing Scenarios


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


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


7.1.4.1  MN as data sender


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



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


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


                Figure 13: Multi-homed MN as data sender




Lee, et al.              Expires April 18, 2005                [Page 44]


Internet-Draft          Applicability Statement             October 2004



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


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


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


7.1.4.2  CN as data sender


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



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


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


                Figure 14: Multi-homed CN as data sender





Lee, et al.              Expires April 18, 2005                [Page 45]


Internet-Draft          Applicability Statement             October 2004



   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.


7.1.5  Proxy Scenario


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


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


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


7.1.6  Conclusion


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


   From the scenarios we can observe the following issues:


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


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


   -  Many authorization problems arise after the initial setup of
      resources along the path.  This problem can be stated as: "Is an
      entity allowed to perform the indicated action?" Only a few




Lee, et al.              Expires April 18, 2005                [Page 46]


Internet-Draft          Applicability Statement             October 2004



      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.




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-03 (work in progress),
         July 2004.


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


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


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


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




Lee, et al.              Expires April 18, 2005                [Page 47]


Internet-Draft          Applicability Statement             October 2004



         2004.


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


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


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


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


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


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


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


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


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



Authors' Addresses


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


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





Lee, et al.              Expires April 18, 2005                [Page 48]


Internet-Draft          Applicability Statement             October 2004



   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


   EMail: Hannes.Tschofenig@siemens.com



   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.





Lee, et al.              Expires April 18, 2005                [Page 49]


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.















































Lee, et al.              Expires April 18, 2005                [Page 50]


Internet-Draft          Applicability Statement             October 2004



Intellectual Property Statement


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


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


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



Disclaimer of Validity


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



Copyright Statement


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



Acknowledgment


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




Lee, et al.              Expires April 18, 2005                [Page 51]