[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Internet Engineering Task Force                          Roland Bless
Internet-Draft                                            Xiaoming Fu
Expires: July, 2004                                    Robert Hancock
                                                       Seong-Ho Jeong
                                                     Cornelia Kappler
                                                       Sung-Hyuck Lee
                                                    Jukka Manner, Ed.
                                                         Paulo Mendes
                                                    Hannes Tschofenig
                                                        January, 2004


               Mobility and Internet Signaling Protocols
          <draft-manyfolks-signaling-protocol-mobility-00.txt>

Status of this Memo

   This document is a submission to Next Steps in Signaling Working
   Group. Comments should be submitted to the nsis@ietf.org mailing
   list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   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.

   Copyright Notice

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


Abstract

   IP mobility, which in its simplest form includes routing changes, can
   have major influence e.g. on the protocols designed within the NSIS
   Working Group. This draft is a first step in helping us to decide on
   how the problems caused by mobility should be handled within Internet
   signaling protocols, and a stimulus to further security work.



Manyfolks et al             Expires July 2004                   [Page 1]


Internet-Draft       Mobility and Internet Signaling        January 2004

Table of Contents

   1 Introduction .................................................    3
   2 Terminology ..................................................    4
   3 Framework ....................................................    6
   3.1.1 Global Mobility ..........................................    7
   3.1.2 Other Global Mobility Approaches .........................    8
   3.1.3 Global Mobility Procedures ...............................    8
   3.2 Local Mobility Management ..................................    9
   3.3 Context Transfer and Candidate Access Router Discovery .....    9
   3.4 Examples of handovers ......................................   10
   3.5 Short Problem Statement ....................................   13
   4 Cross-over Node Discovery and Path Update ....................   14
   4.1 Background .................................................   14
   4.2 Crossover Node Discovery ...................................   15
   4.2.1 Types of Crossover Node ..................................   15
   4.2.2 Determination of Crossover Node ..........................   16
   4.3 Path update ................................................   19
   4.3.1 State Setup and Update ...................................   19
   4.3.2 State Teardown ...........................................   20
   4.4 Effect of generic routing changes ..........................   21
   4.4.1 CRN discovery ............................................   21
   4.4.2 Path Update ..............................................   22
   4.5 Open Issues ................................................   22
   5 Dead Peer Discovery (DPD) ....................................   23
   5.1 Overview ...................................................   23
   5.2 Failure Cases and Impact of Dead Peers .....................   23
   5.2.1 Failure Cases ............................................   23
   5.2.2 Impact of Dead Peers .....................................   24
   5.3 DPD procedures in NTLP .....................................   25
   6 Case Examples ................................................   26
   6.1 NSIS in the hard-handover case .............................   26
   6.1.1 Signaling on the Unchanged Path ..........................   28
   6.1.2 Signaling on the New Path ................................   28
   6.1.3 Signaling on the Old Path ................................   28
   6.1.4 Interaction between NTLP and NSLP Signaling ..............   29
   6.1.5 Routing of NTLP messages .................................   29
   6.2 Example of Signaling of an Anticipated Handover ............   31
   7 Multihoming-related Issues ...................................   32
   8 Interactions with Mobility Signaling .........................   32
   8.1 Mobility Management Protocols ..............................   32
   8.2 Interactions with Seamoby Protocols ........................   35
   9 Additional issues ............................................   36
   9.1 Both End-Hosts are Mobile ..................................   36
   9.2 Uni- and Bi-directional State Establishment ................   37
   9.3 State Management ...........................................   37
   9.4 State establishment in Network Mobility ....................   38
   10 Guidelines for Designers of new NSLPs .......................   39
   11 Summary of Split of functionality ...........................   40
   12 Security Considerations .....................................   40
   12.1 MN as data sender .........................................   40
   12.1.1 MN is authorizing entity ................................   41
   12.1.2 CN is authorizing entity ................................   43
   12.1.3 MN and CN are authorized ................................   46

Manyfolks et al             Expires July 2004                   [Page 2]


Internet-Draft       Mobility and Internet Signaling        January 2004

   12.2 CN as data sender .........................................   46
   12.2.1 CN is authorizing entity ................................   47
   12.2.2 MN is authorizing entity ................................   48
   12.3 Multi-homing Scenarios ....................................   48
   12.3.1 MN as data sender .......................................   48
   12.3.2 CN as data sender .......................................   49
   12.4 Context Transfer ..........................................   49
   12.5 Proxy Scenario ............................................   50
   12.6 Implications for the costs of a QoS reservation ...........   51
   12.6.1 Missing Cost Control ....................................   51
   12.6.2 Implications for Price Determination ....................   52
   12.7 Conclusion ................................................   52
   13 Contributors ................................................   54
   14 Acknowledgments .............................................   54
   15 Informative References ......................................   54
   16 Author's Addresses ..........................................   56


1.  Introduction

   The mobility of IP-based nodes incurs route change, usually at edge
   of the network. Route change may also be caused by reasons other than
   mobility, such as routing protocol adaptation in response to varying
   network conditions, or host multihoming. Normal IP mobility (i.e.,
   Macro-mobility) also involves change of mobile node IP addresses.
   Since IP addresses are usually part of flow identifiers, change of IP
   addresses implies change of flow identifier.

   Micro mobility usually does not cause change of the global IP
   addresses, but affects the routing paths within the local access
   network. Some Local Mobility Management (LMM) mechanisms may change
   the IP address assigned to the mobile node within the access network,
   for example, mechanisms based on a hierarchy of mobility handling
   routers. Some protocols either use tunneling to forward packets
   towards the new location of the mobile node, or set and update per-
   host routing entries in the network, as for instance, ad-hoc routing
   protocols.

   This draft addresses mobility-related considerations for NSIS. The
   goals of this draft are to analyze the effects of mobility on the
   NSIS Transport Layer Protocol (NTLP) and on the NSIS Signaling Layer
   Protocol (NSLP), and to make sure there are no initial design
   mistakes that break the protocols in mobile environments. The NTLP is
   an application independent protocol to transport service-related
   information between nodes in a network. Each specific service has its
   own NSLP protocol.

   The goals of this draft are not to suggest a design for a separate
   mobility-specific NSIS protocol or to intentionally delay the current
   work. We expect that this study will actually speed-up the current
   work on the NSIS protocols. We do not intend to present specific
   implementation issues in this document, but rather propose how the
   NSIS protocols should be designed to work in a mobile environment.


Manyfolks et al             Expires July 2004                   [Page 3]


Internet-Draft       Mobility and Internet Signaling        January 2004

   A further goal of this draft is to give guidance to people proposing
   new NSLP protocols. The guidelines in this draft would help those
   people make sure their NSLP protocols truly work in wired and
   wireless/mobile environments. Moreover, a goal is to stimulate
   further discussions related to the security and authentication issues
   in a mobile environment making use of the NSIS protocols. We expect
   there to be a common (minimal) set of functions that the NTLP and
   NSLP need to support. Furthermore, we intend to capture any
   additional issues that would need specific precautions, e.g. in
   future NSLPs.

   The discussion is divided into two parts. The first part discusses
   the very basic functionality needed within the NTLP and NSLP
   protocols.  We expect these features to be from most parts already
   available within the NSIS protocols, or at least can be added with
   little effort.

   The second part takes the discussions to more specific scenarios,
   including support for multihoming and inter-working issues with a
   number of mobility-related protocols. These functions would be looked
   at once the first versions of the NSIS protocols are finished.


2.  Terminology

   For terminology related to wireless and mobile networking, we refer
   to [Seamoby-terms].

     Session

       A single application layer flow of information between end points
       that occur during the span of a single connection for which some
       network control state information is to be manipulated or
       monitored. IP mobility may cause the mapping between sessions and
       flows to change, and IP multihoming may mean there is more than
       one flow for a given session.

     Session Identifier

       The identifier used to relate signaling messages to a specific
       session.

     Flow

       A sequence of packets sent from a particular source to a
       particular (unicast or multicast) destination for which special
       handling is provided by the combination of header fields. Only
       unicast, unidirectional flows are considered in this document.

     Flow Identifier

       The identifier used to uniquely identify a particular data flow
       for which the specific service is requested from the network. All
       packets associated with the same flow will be assigned the same

Manyfolks et al             Expires July 2004                   [Page 4]


Internet-Draft       Mobility and Internet Signaling        January 2004

       flow identifier by the source. The flow identifier contains
       information about the flow which should receive a particular
       treatment, and it may consist of a combination of the typical
       5-tuple or, for example, source IP address, destination IP
       address, and flow label in IPv6-based networks. See [I-D.ietf-n
       sis-fw] for more information.

     Crossover Node (CRN)

       A Crossover Node is a node that for a given function is a merging
       point of two or more separate sets of state information, and not
       only a physical route splitting point. In the context of this
       draft, we can distinguish several logical (but not necessarily
       physically) different CRNs:

         NTLP CRN, after a routing change, the node closest to the end
         host from which the NTLP state information towards the CN does
         not change.

         NSLP CRN, after a routing change, the node closest to the end
         host from which the NSLP state information towards the CN does
         not change. The NSLP CRN may be different for different NSLPs.

         NSIS CRN, either an NTLP CRN or an NSLP CRN.

         Upstream CRN, after a handover, the node closest to the data
         receiver from which the state information towards the data
         sender does not change.

         Downstream CRN, after a handover, the node closest to the data
         sender from which the state information towards the data
         receiver does not change.

         Mobility CRN, node at which from the point of view of mobility
         mgmt old and new paths merge, e.g. MAPs in HMIPv6. Note in
         general: mobility CRN is may or may not be equal neither to
         NSLP CRN nor to NTLP CRN.

         Routing CRN, node at which, using normal routing, old and new
         paths merge. In case of HMIP, mobility CRN is also routing CRN.
         However, in case of "normal" MIP with optimized routing,
         mobility mgmt doesn't know a CRN, whereas routing does.
         Depending on the location of nodes, the routing CRN may or may
         not be equal to the NSLP CRN or to NTLP CRN.

     Path Update

       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 route change or mobility.
       This is used to improve mobility handling for the affected flows.

         Upstream Path Update: Path Update for the upstream signaling
         which is initiated by a signaling initiator on the common path

Manyfolks et al             Expires July 2004                   [Page 5]


Internet-Draft       Mobility and Internet Signaling        January 2004

         (e.g., a CN, a HA, or a GFA/MAP).

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

     Dead Peer Discovery (DPD)

       The procedure for finding a dead NSIS peer due to a link or node
       failure and due to a mobile node moving away.

     Downlink

       The direction from the CN towards the mobile node.

     Uplink

       The direction from the mobile node towards the CN.

     Receiver

       The node in the network which is receiving the data packets in a
       flow.

     Sender

       The node in the network which is sending the data packets in a
       flow.

     NSIS Transport-Layer Protocol (NTLP)

       Description...

     NSIS Signaling-Layer Protocol (NSLP)

       Description

     Downstream direction

       Direction from a data source to the destination.

     Upstream direction

       Direction from data destination towards its source.


3.  Framework

   This section describes various mobility scenarios for the detailed
   discussions of mobility issues in NSIS signaling, using basic mobile
   IP (v4 and v6) handover as a starting point...

   Our assumptions in this document and the framework are:


Manyfolks et al             Expires July 2004                   [Page 6]


Internet-Draft       Mobility and Internet Signaling        January 2004

     Session-ID is used to index state

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

       Double state installation in the unchanged path should be
       avoided. This can only be done by establishing a relationship
       between the old and the new flow. This is essentially the same
       problem faced to tear down state in the old path.

     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, or due to the operation of an LMM protocol, or due to
       asymmetric routing caused by the basic operation of the IP
       routing protocols themselves.

     The CN is not a mobile device

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


3.1.1.  Global Mobility

   Each mobile node is always identified by its home address, regardless
   of its current point of attachment to the Internet. In basic mobile
   IP, while situated away from its home, a mobile node is also
   associated with a care-of-address, which provides information about
   the mobile node's current location. After a mobile node registers its
   (primary) care-of address with a router on its home link, known as
   ``home agent'', data packets addressed to the mobile node's home
   address are routed to its care-of-address using IP-in-IP
   encapsulation in the home agent (known as "mobile IP tunneling"). A
   mobile node can also register with the corresponding node, and then
   data packets addressed to the mobile node's home address are either
   IP-in-IP encapsulated (in mobile IPv4) or routed using routing header
   to its care-of-address (in mobile IPv6). Data packets sent by the
   mobile node to the corresponding node can be either directly routed
   to the destination's IP address, or routed through the home agent via
   a reverse tunnel (if reverse tunnel is used). Here, the following
   characteristics are important for support of NSIS signaling:





Manyfolks et al             Expires July 2004                   [Page 7]


Internet-Draft       Mobility and Internet Signaling        January 2004

3.1.2.  Other Global Mobility Approaches

   Other approaches to provide global mobility work in the same generic
   way as MIP, but having a globally unique identifier for the MN, and
   then using an out-of-band signaling mechanism to provide the current
   location of the MN to the requesting party. For example, approaches
   based on DNS updates provide the globally unique DNS name, and the an
   up-to-date physical location of the MN. Another example is SIP, where
   users have globally unique identifiers, e.g. names, and the system is
   able to provide to the caller the current physical location of the
   called party.


3.1.3.  Global Mobility Procedures

   1) A flow associated with a mobile node, either sent or received by
      the mobile node, may continue to desire signaling services after a
      mobile IP handover. NSIS needs to be able to signal for such flows
      upon a mobile node's movements.

   2) Either the sender or the receiver of a mobile node's flow can
      initialize an NSIS signaling. 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 in the middle of the network, or to support seamless
      handovers.

   3) The paths for a mobile node's outgoing traffic to the
      corresponding node and incoming traffic from the corresponding
      node may differ from each other.

   4) Data traffic, in either direction between a mobile node and the
      corresponding node, can be routed directly, routed indirectly
      using a routing header, or IP-in-IP encapsulated, or the
      combination of them in different segments of the data
      transmission, depending on the mobility mode (route optimization
      or triangle routing; use reverse tunneling or not; mobile IPv4 or
      IPv6; whether LMM is used; etc.).

   5) A mobile node's handover can be either intra-domain (inside one
      access network domain) or inter-domain (from one access network
      domain to another), which mainly concerns with topology
      information exchange, authorization and accounting issues. This is
      elaborated in Section 10.7 in [nsis-req].

   6) A mobile node can support multiple care-of-addresses at one time,
      if it is connected to multiple access networks
      simultaneously. Although only one primary care-of-address will be
      used for routing traffic from the corresponding node to the mobile
      node, this multi-homing feature potentially can be used to enhance
      the NSIS signaling performance.



Manyfolks et al             Expires July 2004                   [Page 8]


Internet-Draft       Mobility and Internet Signaling        January 2004

3.2.  Local Mobility Management

   Localized mobility management [lmm] mechanisms reduces the latency in
   mobility management signaling upon Care of Address change.  These
   schemes, such as fast handover [fmip] and hierarchical mobile IPv6
   [hmipv6], complicates the features identified in Section 3.1, for
   example, by associating new scoped care-of-addresses for a mobile
   node, and introducing one or more IP-in-IP encapsulated segment(s) in
   the path traversed by the communicating traffic. The additional CoA
   and IP-in-IP tunnels have implications for both the NTLP and NSLP.
   For example, NTLP needs to decide to perform tunnel handling when
   such tunnels exist in the same path that NTLP messages also traverse,
   while NSLP states may be updated according to the updated CoA in the
   localized domain. A discussion of these advanced characteristics is
   detailed in Section 11.


3.3.  Context Transfer and Candidate Access Router Discovery

   The NSIS protocol suite should be able to operate independently of
   Seamoby protocols such as Context Transfer Protocol (CTP) and
   Candidate Access Router Discovery (CARD). Significant performance
   gains can be achieved if NSIS signaling can interact with such
   protocols.

   When a mobile node has a choice of Candidate Access Routers (CARs) to
   perform handover, the Candidate Access Router Discovery (CARD)
   procedure can be used to identify those CARs along with their
   capabilities (for instance, QoS resource availability). In NSIS
   terminology, CARD can be used to find an appropriate NSLP-aware New
   AR (NAR), and the path leading to the node, where the NSLP state
   could be installed.

   The Context Transfer Protocol (CTP) is used to transfer the NSLP
   state from the Previous AR (PAR) to NAR. When CTP is used, service-
   aware contexts could be quickly re-established in the NAR without
   requiring the MN to explicitly perform all protocol flows for those
   services from scratch. NSLP information, such as QoS state, can be
   transferred using CTP. However, this also concerns the NTLP because
   the context transfer for NSLP states takes place between PAR and NAR,
   which is vertical to the direction of normal NSIS signaling (which is
   between MN and CN).

   With the help of CARD and CTP, NSIS signaling can quickly re-
   establish the NSLP state on the new path by reducing the state re-
   setup delay.  However, making use of the CARD and CT protocols
   requires the ability from NTLP/NSLP to do (at that stage) off-path
   signaling on-behalf of the MN; this has implications on the
   authorization of signaling.






Manyfolks et al             Expires July 2004                   [Page 9]


Internet-Draft       Mobility and Internet Signaling        January 2004

3.4.  Examples of handovers

   The discussions in this document focus on the effects a mobile end
   host can have on NSIS signaling. The fundamental concern in handover
   events is how the signaling can be localized in order to minimize the
   latency of setting up resources on a new path. Here one of the
   critical issues is the location and operation of a cross-over node.
   This section seeks to identify the various scenarios that emerge in
   different types of handovers and network setups.

   There are several issues that affect how resources are set up in a
   mobile environment:

   1. Is the access router (AR) running
      a) NTLP,
      b) NTLP and the NSLP being signaled about, or
      c) neither of the two protocols?

   2. Where are the
      a) NTLP CRN,
      b) NSLP CRN,
      c) mobility CRN, and
      d) routing CRN?

   3. Does the interface at a given CRN routing towards the MN
      a) change after a handover, or
      b) remains the same?

   4. Are the incoming and outgoing packets from the MN
      a) routed through the same routing path (symmetric), or
      b) through different paths (asymmetric routing)?

   Note here, that the NSLP protocol can not be run without the
   transport part of the protocol, the NTLP.

   Figure 3.1 presents possible setups in an access network that
   supports NTLP and NSLPs. It is assumed that all MNs in this draft are
   NSLP aware node. To provide examples of the issues mentioned above,
   consider the following scenarios:

   - MN is connected to AR 1 and makes a handover to AR2. If incoming
   packets are arriving through Path A, the NTLP CRN is router a (RTRa)
   and its interface changes, and the NSLP CRN is RTRb and its interface
   does not change. If resources are set up for outgoing packets and the
   outgoing path changes to Path B due to the network routing table,
   resources must be set up on this new path, and possibly removed on
   the old Path A.

   - MN is connected to AR 2 and makes a handover to AR 3. If packets
   were flowing, and will still continue to flow, on both directions,
   through Path B, the NTLP and NSLP nodes after the AR do not change,
   that is, the interface towards the MN at the NTLP and NSLP CRNs does
   not change.


Manyfolks et al             Expires July 2004                  [Page 10]


Internet-Draft       Mobility and Internet Signaling        January 2004

   - MN is connected to AR 8 and makes a handover to AR 7. If data was
   flowing through Path F before the handover and now flows through Path
   E, the CRNs are not visible in the figure; RTRj is the first-hop NTLP
   and NSLP node from the MN and CRNs are somewhere else. If data flows
   through Path F before and after the handover, there is no NTLP or
   NSLP CRNs, as RTRm remains the first-hop NTLP and NSLP node.

















































Manyfolks et al             Expires July 2004                  [Page 11]


Internet-Draft       Mobility and Internet Signaling        January 2004

            ------
   [MN]     |NSLP|
     |      |AR 1|\
     |      ------ \ ------         ------
     |              \|NTLP|         |NSLP|
     |              /|RTRa| --------|RTRb| ------- Path A ---
     |      ------ / ------         ------
     V      |NSLP|/
            |AR 2|\
            ------ \           ------    ------
                    \------    |NTLP|    |NSLP|
                     |RTRc| -- |RTRd| -- |RTRe| -- Path B ---
                    /------    ------    ------
            ------ /
            |NSLP|/
            |AR 3|\
            ------ \ ------         ------
                    \|NSLP| ------- |NSLP|
                    /|RTRf|         |RTRg| ------- Path C ---
            ------ / ------         ------
            |NTLP|/
            |AR 4|
            ------         Administrative Domain 1
     -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
            ------         Administrative Domain 2
            |AR 5|\
            ------ \ ------         ------
                    \|NTLP|         |NSLP|
                    /|RTRh| ------- |RTRi| ------- Path D ---
                   / ------         ------
            ------/
            |AR 6|
            ------\
                   \ ------         ------
                    \|NSLP|         |NSLP|
                    /|RTRj| ------- |RTRk| ------- Path E ---
                   / ------         ------
            ------/
            |AR 7|
    ^       ------\                ------
    |              \------         |NSLP|
    |               |RTRl| ------- |RTRm| ------- Path F ---
    |              /------         ------
    |       ------/
    |       |AR 8|         'AR': Access Router
   [MN]     ------         'RTRx': Router with id 'x'
                           'NSLP': Node running NTLP and NSLP
                           'NTLP': Node running only NTLP

               Figure 3.1: Examples of network architectures





Manyfolks et al             Expires July 2004                  [Page 12]


Internet-Draft       Mobility and Internet Signaling        January 2004

3.5.  Short Problem Statement

   Based on the discussion in this section, we can highlight some
   critical issues that need to be solved to allow NSIS protocols to
   work in a mobile and wireless environment. There are a number of
   existing signaling protocols [nsis-analysis], however most of them do
   not support signaling in mobility scenarios, or the support is
   insufficient. RSVP [RFC2205], for example, relies on flow's fixed
   source and destination IP addresses, and ports information to
   identify signaling sessions and how signaling messages are routed.
   RSVP also lacks an overall consideration of mobile IP features.

   An NSIS signaling protocol in mobility scenarios needs to consider
   the following issues:

   o Change of route and possibly change of MN IP address

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

   o Latency of route change

   This change of routing and IP addresses is typically much faster than
   traditional route change (for example, those due to failure, adding
   or removal of nodes/links), which makes existing signaling protocols
   to be either unable to handle or at least create an additional
   overhead.

   o Explicit routes

   Moreover, MIPv6 adds the possibility to define explicit routers,
   which creates further issues with routing paths.

   o IP-in-IP encapsulation

   The possible use of IP-in-IP encapsulation segments in the end-to-end
   path for routing traffic from the corresponding node to the mobile
   node (vice versa), associated with a route change of the same
   mobility behavior, makes signaling in mobility scenarios more
   complicated.

   o Localization of state teardown

   In the case of MN movement, only NSIS state between (former point of
   attachment of) MN and the NSIS CRN needs to be torn down: The NSIS
   state between CRN and CN may have to be updated e.g. to reflect a new
   Flow ID, but in any event it is still needed. Besides, tearing it
   down may necessitate re-authentication and re- authorization.
   Complication is added because the NSIS CRN is only known once the
   NSIS signaling along the new path is completed.

   o Ping-pong type handover


Manyfolks et al             Expires July 2004                  [Page 13]


Internet-Draft       Mobility and Internet Signaling        January 2004

   In a ping-pong type handover, the MN returns to the previous AR after
   staying with the new AR only for a short while. On the one hand, NSIS
   should remove quickly in order to free resources. On the other hand,
   in the case of ping-pong type handover, state would need to be
   reestablished soon again, also adding overhead.

   O Upstream local repair vs downstream local repair

   Since upstream and downstream path need not be equal, upstream and
   downstream CRNs need not be equal, either. In fact, local repair
   needs to be handled independently for upstream and downstream flows,
   including, e.g. discovery of upstream and downstream CRN.

   In summary, NSIS signaling needs to work with basic mobility which is
   an extension of general route (topology) change, and typically also
   includes IP address changes, supports mobile IP tunnels and
   multihoming.  Path repair should be localized, and handled
   independently for upstream and downstream flows.


4.  Cross-over Node Discovery and Path Update

   This section discusses how to discover the crossover node (CRN) in
   general and the role of the CRN (especially in Path Update).  This
   section also discusses how the NAT/FW NSLP affects the CRN discovery.


4.1.  Background

   Route change and main characteristics of mobile IP system described
   in Section 3.5 cause the session path to be changed, and therefore
   NSIS state needs to be re-established along the new path. In this
   case, the exiting protocols which do not support signaling in dynamic
   environment where route change or mobility event occurs can cause the
   following basic problems:

     * Double reservation Problem

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

     * End-to-end signaling Problem

     End-to-end signaling has to be considered as the issue-must-be-
     avoided in mobility scenarios, because it causes most problems
     related to service quality, signaling performance, and resource

Manyfolks et al             Expires July 2004                  [Page 14]


Internet-Draft       Mobility and Internet Signaling        January 2004

     availability. The route change caused by mobility, which
     complicates QoS signaling more, may result in the change of flow
     identifier. The change of flow identifier requires state update
     along the entire path to reflect the physical location of the MN:
     end-to-end signaling. This also incurs a long state setup delay,
     signaling overhead, and double reservation which affects network
     performance. Ultimately, the long state setup delay will
     particularly gives rise to the service blackout or degradation for
     multimedia application in the mobility environment.

   To quickly re-establish NSIS state and improve scalability of NSIS
   signaling when route change and mobility event occurs, NSIS signaling
   should be localized, and the localized signaling procedure is
   referred to as path update (see the terminology section). This is
   because, although NSLP messages are initiated by an MN or CN and sent
   to the opposite terminating point of the path, the path in the
   wireless access network usually changes only partially. Therefore,
   the NSLP/NTLP should limit the scope of signaling information to a
   local section of the signaling path.

   The most appropriate node to do path update can be the CRN which is
   not a simple route splitting point, but an NSLP-aware merging point
   where the old and new session paths meet. To minimize the impact on
   seamless service, the CRN should be discovered by the NTLP as quickly
   as possible (see Section 4.2.2 for details), and afterward the
   involved NSLP should be triggered by the NTLP for necessary actions,
   for example, path update in case of QoS-NSLP.


4.2.  Crossover Node Discovery


4.2.1.  Types of Crossover Node

   There can be various types of CRN according to normal route change,
   mobility management, signaling states, and flow direction. In the
   context of NSIS, this section mainly discusses the types of CRN
   according to NSIS signaling states and flow direction.

   From the perspective of NSIS states (i.e., NSLP and NTLP sates), the
   types of CRN are basically divided as follows. First, from the NSLP's
   point of view, the CRN is a signaling application-aware node in the
   network where the signaling flows meet. Second, from the NTLP's point
   of view, it is a network node where more than one NTLP states (e.g.,
   messaging association in [ntlp]). are stored. Although there can be
   various types of CRN according to state information, the CRN required
   for QoS-NSLP operation is NSLP CRN which has the corresponding
   signaling application information to perform the path update.
   Therefore, the CRN for the path update should be a logical NSLP-aware
   merging point rather than just a physical route splitting point. This
   implies that the CRN should not only be NTLP-aware but also NSLP-
   aware even if a CRN is detected by the NTLP. In this process, the
   NTLP should know the corresponding signaling application (e.g. QoS-
   NSLP) at the NSLP layer.

Manyfolks et al             Expires July 2004                  [Page 15]


Internet-Draft       Mobility and Internet Signaling        January 2004

   The path change of a specific NSLP session flows can be caused by
   either route change or mobility, so basically there are two different
   types of merging point in the network according to the direction of
   signaling flows. The path change of downstream signaling flows may
   result in forming a downstream crossover node (DCRN) where the
   logical incoming interfaces start to converge, and the path change of
   upstream signaling flows may result in forming a upstream crossover
   node (UCRN) where the logical outgoing interface begins to diverge.
   Therefore, in general, the path change causes convergence or
   divergence of packets in data plane and/or in control plane (e.g.,
   considering 3G/4G networks).

   There are some differences between route change and mobility in
   forming DCRN and UCRN, and the asymmetric characteristics of routing
   adds complexity to the CRN discovery. When a generic route change
   occurs, the path change of signaling flows results in forming a chain
   of two CRNs, which is referred to as a divergence and convergence
   pair (see Section 4.4.1).

   When a mobility event occurs, the asymmetric characteristics of
   routing between downstream and upstream directions can affect the
   location of the CRN. For instance, the handover of an MN (as an NI)
   will create a DCRN, and the handover of an MN (as an NR) will form a
   UCRN.  However, the DCRN and the UCRN may be the same merging point
   in the network or may be different due to the asymmetric
   characteristics of routing although a CN is the same.

   The CRN will be temporarily formed for path update, and how long the
   CRN will be involved in the path update depends on the period and
   method of re-establishing NSIS states in mobility scenarios. If
   sates, for example, are pre-established during handover to support
   multimedia applications seamlessly, candidate NEs can be ferreted out
   by interacting with Seamoby protocols. In this case, the candidate
   CRN(s) also is (are) discovered to localize the signaling to obtain
   performance gains in the network (see Section 4.2.2).


4.2.2.  Determination of Crossover Node

   A CRN can be discovered at both NTLP and NSLP layers. The CRN
   discovery at the NSLP layer can be done by NSLP signaling messages
   sent from the signaling initiator. For example, NSLP can realize it
   is a CRN by comparing the Source Identification Information (SII)
   contained in the incoming signaling message to that of previously
   stored in the node. However, in particular, the CRN would want to
   delete NTLP state when a particular NSLP is not supported there and
   NTLP state is not needed any more. Therefore, CRN discovery can be
   considered as an extension to the peer discovery at the NTLP level
   (e.g., using GIMPS query-response [ntlp]). In general, GIMPS message
   has message routing state information such as flow/session/signaling
   application identifier, so signaling application can be identified at
   the NTLP level. For example, in the connection mode of NTLP, when
   NTLP establishes messaging association between two adjacent peers,
   the NTLP peers exchange message routing state information through

Manyfolks et al             Expires July 2004                  [Page 16]


Internet-Draft       Mobility and Internet Signaling        January 2004

   GIMPS query and response messages. Therefore, although CRN is
   discovered at the NTLP level, the discovered CRN is actually NSLP-
   aware node which has a involved signaling application.

   There can also be two different approaches in CRN discovery according
   as whether the discovery is coupled with signaling message or not:
   Coupled approach and separated approach. In this case, the CRN
   discovery at each NSIS level depends on the used approach (see
   Section 6.1.4).

   For CRN discovery, some session information such as the flow
   identifier and session identifier can be used.  In addition,
   incoming/outgoing interfaces (e.g., Logical Interface Number: LIN)
   may also be used together with the session information. The CRN
   discovery can be further divided into UCRN discovery and DCRN
   discovery according to which node is a signaling initiator.

   The session identifier in the GIMPS message is used to easily
   identify the involved session because it remains the same while the
   flow identifier may (or may not) change due to handover. The flow
   identifier is used to specify the relationship between the address
   information and the state re-establishment (e.g., QoS-NSLP state re-
   establishment).  That is, the changed flow identifier indicates
   topological changes (i.e., old path, new path, and common path) and
   so the state re-establishment is required.

   The logical interface number (LIN) can be used to establish or delete
   NSIS associations between peers. This identifier is also used to
   determine the CRN. NSIS entities may be able to use the interface
   number to locally distinguish each logical interface identifier
   between adjacent NTLP peers. Note that the LIN can be included in the
   NSIS message, but it can also be considered as an implementation
   issue.

   In general, when a route change due to mobility occurs, CRN can be
   recognized by comparing the existing session information (e.g., the
   session and flow identifiers) with the session information included
   in the peer discovery message initiated by an NI (e.g., an MN or a
   CN) through a different LIN (e.g., an incoming/outgoing LIN).  If the
   session identifier is still the same and the flow identifier and LIN
   has been changed, the current NSLP-aware node realizes it is the CRN.
   Note that the node which performs the CRN discovery should check
   whether the CRN has been discovered or not before realizing it is the
   CRN.

   Optionally, a mobility object can also be used to indicate that the
   MN has experienced a handover and a route change has occurred
   [Jeong01] [Lee01]. In this case, the NSIS protocol (or node) may need
   to interact with mobility protocols to detect the CRN immediately.
   For example, the CRN discovery may need to be triggered in parallel
   with the transmission of the binding update (BU) message (of MIP).

   The mobility object may be defined in the NTLP message (e.g., GIMPS
   payload) to notify any mobility event explicitly, and it contains

Manyfolks et al             Expires July 2004                  [Page 17]


Internet-Draft       Mobility and Internet Signaling        January 2004

   various mobility-related fields such as handover_init field and
   mobility_event_counter field. The handover_init field can be used to
   explicitly inform that a handover is initiated for fast state re-
   establishment. The mobility_event_counter field can be used to detect
   the latest handover event to avoid confusion about where to send a
   confirmation message which indicates that the CRN has been found.

   This type of confirmation may be needed when the MN moves toward the
   second new AR immediately after it undergoes a handover to the first
   new AR from the old AR, because the CRN discovery message from the
   second new AR may arrive earlier than from the first new AR. The
   mobility object may also be defined in the NSLP in a similar way. In
   this case, there should be some relationship between the mobility
   objects of the NTLP and the NSLP.

   If an MN is an NI when a route change due to mobility 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 converge, and then this node performs the comparison of
   session information checking the incoming LIN. After determining that
   the CRN has not been discovered yet, the NSLP-aware node realizes it
   is the DCRN.

   When an MN (as an NR) undergoes handover, the UCRN can be determined
   by checking the outgoing LIN of signaling flow from a CN.  In this
   case, the UCRN should be the first node where the signaling flow
   begins to diverge. Since UCRN is determined by whether outgoing path
   diverges or not, the UCRN discovery is more complex than the DCRN
   discovery. If NSIS operates with HMIPv6 and an MAP is an NSIS-aware
   node, the UCRN can be locally discovered in an access network by the
   method above. If the UCRN is discovered between the MN and the MAP,
   the path update can be actually localized for upstream flows.
   However, note that when interworking with HMIPv6, it is still an open
   question how these nodes decide locally whether they are indeed the
   UCRN.

   The CRN discovery may also be initiated during handover (i.e., before
   handover is completed). However, in this case, a more efficient
   mechanism is needed to find a candidate CRN. For example, after a
   mobility event is detected by the NTLP, the current AR may use CARD
   to transfer the context for fast QoS-NSLP state re-establishment.
   After the candidate AR is found, CTP can be used to transfer the
   context which includes the QoS-NSLP session information for fast QoS-
   NSLP state re-establishment. If an appropriate AR is found and the
   context transfer is completed, a candidate CRN can be discovered
   easily since the candidate CRN discovery is basically the same as
   above.

   In some cases, however, it may not be always possible to use
   mobility-related protocols such as CT and CARD. In this case, the MN
   can initiate the CRN discovery only after it changes the point of
   attachment. To expedite the discovery process, it may be useful to
   transmit the peer discovery message (by the NTLP) and the first
   binding update message at the same time.

Manyfolks et al             Expires July 2004                  [Page 18]


Internet-Draft       Mobility and Internet Signaling        January 2004

4.3.  Path update

   This section discusses possible procedures for path update according
   to the direction of signaling flows. As discussed in Section 4.1, the
   CRN can be a crucial point for path update, since the CRN is the
   NSLP-aware merging point of the old and new paths. From the
   perspective of path update, the CRN plays the role of initiating re-
   installation on the new path, teardown on the old path, and update of
   NSIS state on the common path.

   In mobility scenarios, the flow identifier for NSIS signaling may
   Change. Since the flow identifier is used to identify the signaling
   state installed along the path, the procedures for path update should
   include state update along the entire path to reflect the topological
   change of the MN. 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. For downstream signaling, path update
   is triggered by the MN (or mobile agent) or an AR, which is referred
   to as Downstream Path Update. For the upstream signaling, path update
   is initiated by a CN, a HA, or a GFA/MAP, which is referred to as
   Upstream Path Update. In this case, each signaling initiator has to
   be authorized for secure signaling.


4.3.1.  State Setup and Update

   In both types of path update, NSIS protocol needs to interact with
   mobility signaling and the Seamoby protocols (during or posterior
   handover) to obtain performance gains through fast re-establishment
   of the NSIS states along the new path. In this case, NSIS needs to
   monitor for detecting the movement through several methods [nsis-fw].
   After detecting a mobility event, the NSIS protocol can check
   resource availability on the new path (or new candidate path) through
   CARD or other mechanisms during handover in order to check the
   possibility of state re-establishment on the new path in advance.

   In the downstream path update, if resource availability is assured,
   an MN initiates the NSIS signaling for state setup toward a CN along
   the new path. The DCRN discovery is implicitly done by this type of
   signaling initiated by the MN. In this case, the node where 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 the downstream path update, the sender-initiated
   approach (e.g., QoS-NSLP) leads to faster setup than the receiver-
   initiated approach as RSVP. And then, the DCRN sends a refresh
   message toward the signaling destination to update the changed flow
   identifier on the common path and also sends a teardown message
   toward the old AR to delete the NSIS states along the obsolete path.


Manyfolks et al             Expires July 2004                  [Page 19]


Internet-Draft       Mobility and Internet Signaling        January 2004

   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
   shared 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 the UCRN is determined as described in
   Section 4.2.2, 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.

   The state update in control plane on the shared/common path to
   reflect the changed flow identifier brings issues on the end-to-end
   signaling. Although the state update does not give rise to re-process
   AAA and admission control, it may lead to the signaling overhead. If
   NSIS protocol interacts with Hierarchical Mobile IPv6 scheme, the
   NSIS session only has the changed flow identifier between an MAP/GFA
   and an MN. However, whether the update of the flow identifier for the
   session can be considered only between an MN and an MAP to avoid end-
   to-end signaling is still an open issue.

   One of the goals of path update is to avoid double reservations (in
   case of QoS signaling) on the shared path described in Section 4.1.
   The double reservation problem may be solved by establishing a
   signaling association using the unique session identifier.  That is,
   NSLP state can be shared even if different flow identifiers changes.
   For example, QoS-NSLP state (for resource reservation) can be used by
   packets for either flow.


4.3.2.  State Teardown

   After re-establishment of the NSIS state along the new path, the
   state on the obsolete path should 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 4.1. Although the release of the existing state on the old
   path can be accomplished by timeout of soft state, the refresh timer
   value may be quite long and the maintenance of the NSIS state on the
   obsolete path may not be necessary. Therefore, the transmission of a
   teardown message is particularly preferred to the use of refresh
   timer to quickly delete the old state.

   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 outgoing LINs 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

Manyfolks et al             Expires July 2004                  [Page 20]


Internet-Draft       Mobility and Internet Signaling        January 2004

   authorization problem because a node which does not initiate
   signaling for establishing the NSIS state can delete the state.

   To avoid the waste of resources, the resources on the old path should
   be removed as soon as possible after re-establishing the state along
   the new path. However, this may not be appropriate for 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. When to delete the state along
   the obsolete path remains still an open issue.

   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. This issue can be solved by using the
   handover_init field of mobility object mentioned in Section 4.2.2.
   When an MN, for example, detects a handover, the QoS-NSLP of the MN
   constitutes the MOBILITY object (the handover_init field) in the QoS-
   NSLP signaling message and send it to the current AR (the old AR),
   which prevent the current AR from initiating the error message
   indicating the dealt with more detail in Section 5.


4.4.  Effect of generic routing changes


4.4.1.  CRN discovery

   In case of generic route change, the CRN can be a node which detects
   the change of a data flow in the network. When the downstream or
   upstream data flow begins to travel, a node can detect the route
   change by interacting with NSIS, routing protocol, and detection
   method based on network monitoring, data packet monitoring, or
   signaling message monitoring [nsis-fw]. The node detecting the route
   change starts to discover the next peer via the NTLP peer discovery
   message exchanges and continues to do the peer discovery until
   discovering a node which already has the involved NSLP states.
   Whenever a new peer is discovered, NSIS creates as an association
   with the previous peer using the LINs.

   In case of downstream data flow, the first NSLP-aware node where the
   signaling flow starts to diverge can be considered as a diverging
   DCRN, and the first NSLP-aware node where the signaling flow begins
   to converge can be identified as a converging DCRN. As mentioned in
   Section 4.2.1, the route change of signaling flows results in forming
   a chain of divergence and convergence CRN pair in the network. For
   upstream signaling flow, the first NSLP-aware node where the
   signaling flow diverges can be considered as a diverging UCRN, and
   the first NSLP-aware node where the signaling flow converges can be
   identified as a converging UCRN. However, How an NSLP-aware node
   identified itself whether the first node which converges and diverges
   is CRN is still an open question.


Manyfolks et al             Expires July 2004                  [Page 21]


Internet-Draft       Mobility and Internet Signaling        January 2004

4.4.2.  Path Update

   In generic route change, since the flow identifier does not change,
   state update along the common path is not performed.  Therefore,
   state re-establishment along the new path and teardown along the old
   path are only carried out. There is also no difference between
   downstream signaling and upstream signaling compared to mobility
   scenarios because the diverging CRN should interact with the
   converging CRN for each signaling flow.

   In downstream path update, the diverging and converging DCRN pair is
   discovered after route change as described in Section 4.4.1. In this
   case, the diverging DCRN initiates signaling to establish NSLP states
   on the new path toward the converging DCRN by sending the RESERVE
   message [QoS-NSLP].  Note that in the coupled approach, peer
   discovery is done simultaneously with state re-establishment (see
   Section 6.1.4), and so a diverging node and a converging node are
   implicitly identified as DCRN.

   If each node between the diverging DCRN and the converging DCRN can
   not delete their NSLP state for itself (i.e., refresh timer), the
   converging DCRN can trigger the removal of the obsolete state by
   interworking with the diverging DCRN. Therefore, the converging DCRN
   begins to delete the NSIS states on the obsolete path in the reverse
   direction (e.g., toward the diverging DCRN) after installing state on
   the new path. In this case, the diverging DCRN should be able to
   identify that the teardown message (e.g., RESERVE message in [QoS-
   NSLP]) from the converging DCRN should not be delivered beyond the
   diverging DCRN. For this purpose, the teardown message may have a
   "Path Update (PU)" flag in its header field, or the destination
   address of the teardown message may be that of the diverging DCRN,
   and converging DCRN should know the reverse routing information to
   send the teardown message toward diverging DCRN (e.g., using SII in
   [QoS-NSLP]). For example, the diverging DCRN can prevent the teardown
   message from being forwarded toward a sender by discerning the í—PUí˜
   flag. However, whether the teardown message can be sent toward the
   opposite direction to the original state initiator is still an open
   question. This also leads to authorization problem because a node
   which does not initiate signaling for establishing the NSIS state may
   delete the state.

   For the upstream path update, the divergence and convergence UCRN
   pair also follows the same procedure as above.


4.5.  Open Issues

   There are some open issues that should be discussed in the later
   version of this document, and they are summarized as follows.
     -  In the Interworking with HMIPv6, how can the nodes decide
       locally whether they are indeed the UCRN?

     -  Can the update of the flow identifier for the session when
       interworking with HMIPv6 be considered only between an MN

Manyfolks et al             Expires July 2004                  [Page 22]


Internet-Draft       Mobility and Internet Signaling        January 2004

       and an MAP to avoid end-to-end signaling?

     -  Can the teardown message be sent toward the opposite
       direction of the state initiator?

     -  When is the right time to delete the state along the obsolete
       path for fast handover of a ping-pong type?

     -  How can the crossover node be discovered in the specific
       multicasting/multihoming cases?

     -  How does the NAT/FW NSLP affect the CRN discovery?


5.  Dead Peer Discovery (DPD)


5.1.  Overview

   A dead peer can occur either because a link or a network node,
   including the MN and CRN, failed, or because the mobile node moved
   away without informing NSLP/NTLP (it is recommended to link mobility-
   and nsis signaling such that this does not happen). Hence, DPD is the
   fall-back mechanism for dealing with mobility which is not currently
   hooked into the NSIS protocol suite.

   The procedures for handling DPD should be the same no matter why a
   peer is dead, because an NE discovering a dead peer cannot judge the
   specific reason. That is, DPD due to a link or node failure, and DPD
   due to an MN moving away should trigger the same reaction. In any
   case, dead peers should be discovered as soon as possible to minimize
   service interruption.  Subsequently, NSIS needs to find a different
   path interacting with the routing protocol. Thereby, NSIS needs to
   take into account the possibility that no path to the dead peer
   exists. Once the new path is found, NSIS state needs to be set up
   along the new path, and NSIS state needs to be torn down along the
   old path. However, care must be taken to terminate teardown at the
   CRN since the NSIS state on the common path should not be deleted.


5.2.  Failure Cases and Impact of Dead Peers


5.2.1.  Failure Cases

   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.

   As mentioned above, an MN may either fail or move. When it fails, it
   becomes a dead peer. When it moves, it either changes or retains its
   IP address (e.g., CoA). If it moves and changes its IP address
   without notifying NSLP/NTLP, it also becomes a dead peer. If it moves
   and keeps its IP address, we need to solve a rerouting problem rather

Manyfolks et al             Expires July 2004                  [Page 23]


Internet-Draft       Mobility and Internet Signaling        January 2004

   than a dead peer problem.


5.2.2.  Impact of Dead Peers

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

   The failure or movement of an MN may cause the 'invalid NR' problem
   [draft- lee-nsis-nslp-mobility-01.txt] where the NR is the MN. [the
   following text could be added for clarification: If the MN moves, an
   error message, e.g., can-not- be-forwarded-further, should be
   generated by the MN, since this message may prevent the teardown of
   NSIS state on the old path before NSIS state is re-established on the
   new path]. We may need to also consider the case where the MN is not
   the NR, but a router in the access network (possibly the AR) is
   proxying for the MN instead.

   If the MN moves without changing its IP address, usually this is a
   micro mobility scenario. Two basic ways for handling micro mobility
   are currently used:

   - By source node routing [HMIPv6] towards the MN, i.e. coding the new
   route explicitly in each packet. It is difficult to do nsis-signaling
   for such a scenario, except by also source-node routing signaling
   messages.

   - By changing the so-called Regional CoA, which is not visible
   outside the micro mobility region. Packets destined to the MN are
   always addressed to the Mobility CRN. The Mobility CRN tunnels the
   packet to the MN [HMIPv4, HMIPv6]. Mobility in this case is not
   noticed by NSIS, because NSIS signaling is tunneled the same way as
   data packets. A separate NSIS state needs to be set up for the
   tunnel, and the NSIS state for the old tunnel needs to be torn down.

   Micro mobility with unchanged IP address is also handled in ad-hoc
   routing protocols in which per-host routing entries are changed in
   the routing tables. Hence in this case, mobility results in
   rerouting, just as when an intermediate node or link fails.

   If the MN moves with a changed IP address, the MN reappears somewhere
   else and tries to set up NSIS state along the new path. The
   requirements derived from this scenario contradict those derived from
   a true MN failure, where the MN does not reappear:

   - In the case of MN movement, teardown of NSIS state should be
   terminated at the NSIS CRN (cf Sec. 3.5) However, the NSIS CRN is
   only known once the NSIS signaling along the new path is completed.
   Therefore, state along the new path needs to be established first,
   and only then the old state should be torn down. (See also discussion
   in Sec. 4).


Manyfolks et al             Expires July 2004                  [Page 24]


Internet-Draft       Mobility and Internet Signaling        January 2004

   In contrast, in case of MN failure, NSIS state should be removed
   along the entire path as quickly as possible. A CRN does not exist.

   Recall it is impossible for the NE discovering a dead peer to
   distinguish these two cases. We therefore need to settle on a single
   mechanism for handling both.

   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 CARD and CT.


5.3.  DPD procedures in NTLP

   The procedures of how to do DPD should be handled by the NTLP. In
   fact, the DPD can be considered as an extension to the GIMPS peer
   discovery.  The transmission of peer discovery messages may be
   separated from the transmission of regular signaling messages. It is
   also possible to combine both types of messages for efficiency in
   message delivery. For example, the detection of an NSIS peer and the
   establishment of an NSIS state can be performed using an NSIS message
   at the same time.

   There are cases where an NE does not deliver signaling messages
   successfully to its NSIS peer along the signaling path, for example,
   when an NF (or NR) was disconnected from the network due to one of
   the failures described above, causing a change of signaling path in
   the network. Such dead peers which are no longer reachable should be
   detected. Some possible DPD procedures are described below.

   A peer discovery message can be periodically transmitted to the
   neighboring peer (e.g., responding node in [GIMPS]), 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 [GIMPS]) of the peer discovery message before the
   timer expires. Otherwise, the responding node can be considered dead.

   It is important to check the validity of the peer discovery messages
   for security protection. For example, it may be necessary to
   determine if the peer discovery message has been received from the
   authorized peer.  Cookies such as query-cookie and response-cookie
   [GIMPS] may be useful for this purpose.

   According to the [GIMPS], the NTLP itself does not provide for
   teardown of NTLP state because, as opposed to NSLP state, it is not
   very expensive.  NTLP instead relies on time-out. Upon DPD, NTLP
   informs the local NSLPs about it, and may even send a notification to
   other NTLP peers upstream to inform other NSLPs which it does not
   support locally. It is an open question when to stop propagating this
   information [GIMPS], which is not specific to mobility.

   Local NSLPs (e.g., QoS-NSLP) could either initiate a teardown of the
   corresponding NSLP state upstream, i.e., in the direction opposite to

Manyfolks et al             Expires July 2004                  [Page 25]


Internet-Draft       Mobility and Internet Signaling        January 2004

   the dead peer (possibly accelerated expiration as described in
   [GIMPS] if the node is not authorized to do this) or send a
   notification upstream which might result in the NI to take action.

   Actually in [QoS-NSLP] it is not fixed yet what must happen. A dead
   peer may lead to rerouting, or sometimes, as sometimes in the case of
   a dead NR, no new route being discovered. Rerouting may be noticed by
   more than one NE using one of the detection mechanisms described in
   [GIMPS]. Furthermore, more than one NE may be able to reroute around
   the situation (see Fig. 8 in [GIMPS]). The NE closest to the flow
   sender should become the NSLP CRN.

   Finding the new path and establishing state can be done as described
   in Section 4. The relative timing of state teardown and re-
   establishment is still an open question as discussed in Section
   5.2.2.


6.  Case Examples

   The movement of end-hosts leads to changes in the data path due to
   the change of their point of attachment in the network. This results
   in the original data path between a sender and a receiver to be
   divided into three paths, all of which intersect at a CRN: the
   unchanged path from the CN until the crossover router, the new path
   from the crossover router until the new location of the MN and the
   old path from the crossover router until the old location of the MN.

   Due to rerouting of data packets after handovers, signaling-
   associated states need to be updated or removed. This concerns with
   which information is needed for indexing states and where and when a
   creation, update or removal of these states is required. If
   signaling-associated state is indexed based on flow-Ids, the state
   indexed by the flow-ID referred to the old path might be inaccessible
   for the signaling after most handover procedures. Hence, it is
   assumed that signaling-associated state is indexed by session-IDs.

   This section provides concrete examples of the signaling done in a
   handover situation.


6.1.  NSIS in the hard-handover case

   This example is called hard-handover, or break-before-make handover,
   in which the NSIS signaling, required to update the MN path, happens
   only after the MN is attached to the new access point.

   To update the path between the CN and the MN, state needs to be
   installed in the new path, released from the old one and updated in
   the unchanged path. The NSIS signaling required for this operation
   may be triggered by the mobile node, mobility agent(s), or by the
   access router at which the mobile node is attached to. In any
   situation, the CRN is the starting point or finish point of the NSIS
   signaling messages.

Manyfolks et al             Expires July 2004                  [Page 26]


Internet-Draft       Mobility and Internet Signaling        January 2004

   Since we have to assume that the MN can be a sender as well as a
   receiver, the first difficulty to find a CRN is posed by the
   asymmetric characteristic of routing, as mentioned in Section 4.2.
   Due to routing asymmetry there is no reason for the UCRN and the DCRN
   to be the same in the, even for the same correspondent node.
   Therefore the NSIS signaling sequence required to update the path
   depends on the role of the MN, which is the one detecting the
   attachment to a new network.

   Figures 6.1 and 6.2 illustrate the signaling needed to update the MN
   path in the upstream and downstream direction when the MN is a sender
   or a receiver. In both figures, the "r", "s", and "u" indicate NSIS
   messages to remove state in the old path, set state in the new path
   and update state in the unchanged path. The "t" in Figure 2
   represents the triggering message that the MN sends to the CN. This
   triggering message can be for instance a mobility-binding message.

              +---+
       [MN]    |AR1|<rrrr
        |      +---+ +--+rrr
        |            |R1| r
        |            +--+ +----+  +--+
        |                  |UCRN|--|R3|---[CN]
        |            +--+ /+----+  +--+   u  ^
        |            |R2|/ s    ^  uuuu   u  t
        |      +---+ +--+sss    uuuu  uuuuu  t
        V      |AR2|/<ssss                   t
       [MN]    +---+                         t
         ttttttttttttttttttttttttttttttttttttt

                       Figure 6.1: MN as a receiver

               +---+
       [MN]    |AR1|<rrrr
        |      +---+ +--+rrr
        |            |R1| r
        |            +--+ +----+  +--+
        |                  |DCRN|--|R3|---[CN]
        |            +--+ /+----+  +--+
        |            |R2|/ ^    u  ^
        |      +---+ +--+sss    uuuu
        V      |AR2|/sssss
       [MN]    +---+ss
         s        sss
         ssssssssss

                        Figure 6.2: MN as a sender

   When the MN is the sender, it is assumed that it is the MN that
   starts signaling over the new path to discover the CRN. Also, it can
   be considered that it is the CRN that starts removing state in the
   old path and updating state in the unchanged path.

   When the MN is the receiver, a general assumption would be that it is

Manyfolks et al             Expires July 2004                  [Page 27]


Internet-Draft       Mobility and Internet Signaling        January 2004

   the CN that starts signaling over the unchanged path to discover the
   CRN. The CN can start signaling for instance after receiving a
   binding update message or after detecting a change in its binding
   entry.  However, if local mobility management mechanisms are used for
   mobility, it can be also possible that mobility agents such as the
   handover manager or the mobility anchor point can start the update of
   the MN path. Also, it can be considered that it is the CRN that
   starts signaling to update the old and new path.

   A path update as the one used by RSVP [RFC2205], where the update may
   be triggered by a local route change, is impossible or at least
   difficult in any of the two described situations. The reason is that,
   the node experiencing a route change can only be the MN, CN, HA, or
   other mobility agents, which are not necessarily the CRN. Moreover,
   it is the CoA that changes and not the route to the old CoA.


6.1.1.  Signaling on the Unchanged Path

   The network control state on the unchanged path must be updated to
   reflect new flow identification, if the flow-ID contains a CoA. This
   leads to the problem of requiring end-to-end signaling, which should
   be avoided to decrease the control load overhead. However, it should
   be possible to avoid AAA and admission control processing.


6.1.2.  Signaling on the New Path

   Updating state in a new path may be conditioned by the session
   ownership and the availability of resources. In the latter case, when
   the network is overloaded, it is preferable to keep state belonging
   to previously established flows while blocking new requests.
   Therefore, signaling to update mobile sessions should have priority
   over local requests for resources.


6.1.3.  Signaling on the Old Path

   The signaling to release resources over the old path should be done
   as soon as possible to avoid wasting resources. Typically, the
   changed path is located inside an access network, where resources are
   relatively expensive, thus it might be inefficient to wait for
   typical soft-state timeouts. However, immediately releasing resources
   along the old path might cause problems. In case of a ping-pong type
   of movement, the immediately release of state in the old path can
   have a performance impact higher than the cost of keeping that state.
   This higher performance impact happens, because resources along the
   old path might be reused after a very short time period. This means
   that the MN may return to the previous access network shortly after
   leaving it, which brings some problems about deciding when to release
   state in the old path.




Manyfolks et al             Expires July 2004                  [Page 28]


Internet-Draft       Mobility and Internet Signaling        January 2004

6.1.4.  Interaction between NTLP and NSLP Signaling

   When the MN is the sender, there is a tight relationship between
   signaling to discover the CRN and signaling to update the new path.
   When the MN is the receiver, signaling to discover the CRN is tightly
   related with signaling to update the unchanged path. This means that
   in each one of these situations, signaling to update the new path or
   the unchanged path can be done simultaneously with the signaling
   needed to discover the CRN (coupled approach) or can be done after
   the CRN discovery process (uncoupled approach).

   Although all NEs in a new path have to be discovered by the NTLP peer
   discovery mechanism, the interaction between NTLP and NSLP signaling
   to discover the CRN (NTLP and NSLP) and to update state depends upon
   the used approach. It is assumed that, even though NSIS messages
   follow standard IP routing, different NSLPs can have different NSLP
   CRNs and that the NTLP CRN can be NSLP-unaware. However, it is
   assumed that each NSLP CRN is a NTLP node.

   In the coupled approach, both types of CRNs (NTLP and NSLPs) are
   discovered by using the same signaling message. In this case the NTLP
   message transports different NSLP objects, and in the discovered NTLP
   nodes the appropriate NSLP state will be updated/set (NTLP trigger
   the corresponding NSLP, if any). One advantage of the coupled
   approach is that it encompasses few update time.

   In the uncoupled approach, a NTLP message is sent to discover the
   NTLP CRN and after that a different NSLP message is sent to discover
   the NSLP CRN for each type of NSLP. This approach utilizes additional
   NSLP-based signaling, and NTLP is essentially used as a transparent
   underlying mechanism to transport NSLP messages. Therefore, NTLP
   should be able to notify NSLP to update state by initializing NSLP
   refresh/teardown messages appropriately. An open issue is, however,
   how and what information the NSLP can expect from NTLP, or directly
   from the routing interface. One advantage of the uncoupled approach
   is to allow the NSLP signaling to be timely independent from the NTLP
   one, allowing a more flexible management of the different NSLPs.


6.1.5.  Routing of NTLP messages

   As stated in the NSIS framework document [nsis-fw], there are two
   ways to address a signaling message being transmitted between NEs:

   o Peer-to-peer, where the message is addressed to a neighboring NE
   that is known to be closer to the destination NE.

   o End-to-end, where the message is addressed to the flow destination
   directly, and intercepted by an intervening NE.

   The peer-to-peer signaling is called connection mode in the
   definition of GIMPS [ntlp], while the end-to-end signaling is called
   datagram mode in the same document.


Manyfolks et al             Expires July 2004                  [Page 29]


Internet-Draft       Mobility and Internet Signaling        January 2004

   Each one of these types of messages is necessary for some aspects of
   the NTLP operation. In particular, initial discovery of the next peer
   in a new path will usually require end-to-end addressing, whereas
   reverse routing, signaling on the old path and on the unchanged path
   can be done based on peer-peer addressing. The latter case is
   possible since NEs in such paths should have already messaging
   associations. The used mode is not visible to the NSLP, and the
   information needed in each case is available from the flow-ID or
   locally stored as NTLP state.

   End-to-end routing of signaling messages at NTLP level can be based
   on the flow-ID, while the peer-to-peer signaling can be based on the
   session-ID. In a flow-ID-based approach, NTLP has to rely on a
   mapping between certain fields of the flow-ID, e.g., destination IP
   address and additional IP header information, and local IP routing
   table. In a session-ID-based approach, NTLP can route the signaling
   messages based on a mapping between the session-ID and the local
   NTLP-level state, such as the address of the next/previous NE. If
   there is no existing state, a next-peer discovery has to be performed
   to create such a state.

   As the association of different flow-IDs to a single session-ID is a
   problem common to many signaling applications, the association
   between both identifiers might be done at the NTLP. However, this
   association could also be done at the NSLP layer, if the method used
   to perform such association is specific to each application. In
   either case, it is assumed that the session-ID should be visible
   within the NTLP, allowing it to perform an enhanced forwarding
   control for packets belonging to that session.

   Another three related identifiers, namely the message
   identifier(message-ID) introduced in RFC 2961 [RFC2961], the branch
   identifier (branch-ID) suggested in CASP [I-D.schulzrinne-nsis-
   casp][fu03], and the Reservation Sequence Number (RSN) proposed in
   QoS NSLP [I-D.ietf-nsis-qos-nslp], have been also discussed as
   potential mechanisms useful for mobility support in NSIS.  All of
   three indicate the order in which corresponding signaling messages
   are processed by the corresponding signaling entities (RSVP, CASP-
   NTLP and QoS-NSLP daemons, respectively) and try to address the out-
   of-order problems of signaling messages.

   Message-ID, together with Epoch object in RFC 2961, concerns with
   signaling messages between peering neighbors, where the out-of-order
   problem can come from retransmission/refresh. It was not designed for
   mobility support specifically. As an extension to message-ID concept,
   the branch ID can be used for detecting out-of-order signaling
   messages along different branches each of which can consist of
   multiple hops. It can be useful to avoid explicit teardown messages
   from being forwarded on the unchanged path. Different from the branch
   ID, the RSN is meaningful in a QoS-NSLP node for protecting out-of-
   order problems in each branch, which can consist of multiple QoS NEs.




Manyfolks et al             Expires July 2004                  [Page 30]


Internet-Draft       Mobility and Internet Signaling        January 2004

6.2.  Example of Signaling of an Anticipated Handover

   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 only possible if the MN is
   multihomed.  The present section discusses fast state installation by
   using anticipated handovers, in which the MN signals the new path
   while still connected to the old one.

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

   On the one hand anticipated handover offers mainly two advantages:

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

   - avoiding unsuccessful handovers or unnecessary periods of QoS
   degradation

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

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

Manyfolks et al             Expires July 2004                  [Page 31]


Internet-Draft       Mobility and Internet Signaling        January 2004

   Moreover, in some anticipated signaling scenarios, NSIS signaling
   cannot be triggered by the mobility protocol, which required some
   study about other possible triggers, such as:

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

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


7.  Multihoming-related Issues

   [This will include discussions about how multihoming affect NSIS
   signaling.]

   [JM: How would SCTP and multiple associations between communicating
   parties actually work with NTLP/NSLP?]


8.  Interactions with Mobility Signaling

   This section discusses the interactions between NTLP/NSLP signaling
   and various mobility-related protocol, including MIPv4, MIPv6,
   various LMM protocols, CTP, and CARD.


8.1.  Mobility Management Protocols

   Basically, NSIS signaling is assumed to be performed after mobility
   protocols take place, i.e., completing a handover. This involves a
   number of issues:

   -  whether NTLP or NSLP should have an interface with the mobility
   protocols.

   -  which information needs to be obtained from mobility protocols. As
   routing of NSIS messages is handled by the NTLP, NTLP should interact
   with mobility protocol for the IP address change, start/completion of
   a binding process and mobile IP tunnel information.

   - whether to use traditional routing/NSIS interface to trigger NSIS
   signaling, or use the start/completion information of binding
   processes which changes the characteristics of flows (e.g., in CN, MN
   or HA, as explained below). If NSIS relies on (typically) after
   seconds of routing change detection of a routing/NSIS interface
   mechanism to obtain route change and tunnel change information, it
   can be less processing-intensive, but the time for reacting and
   behaving in mobility scenarios is a concern. Using start/completion
   information of binding processes allows faster state recovery and
   removal, but its disadvantage is that fast or ping-pong movements may
   result in considerable signaling overhead and possible errors.


Manyfolks et al             Expires July 2004                  [Page 32]


Internet-Draft       Mobility and Internet Signaling        January 2004

   - how to coordinate several entities which involved with changing of
   flow characteristics (e.g., the binding processed in MN, CN, HA,
   ...).

   - how to coordinate the mobility binding update interval and NSIS
   signaling interval. Mobility bindings can take place periodically
   even for the MN with the same point of attachment. This concerns with
   the signaling service latency (e.g., installation of packet
   classifier, etc.).

   - how to disseminate the mobility information within the two-layer
   architecture. In general, NTLP is needed to be involved with mobility
   anyway, for example to route NSIS messages along the new path, or to
   transport explicit release signaling messages along old path.
   Therefore, it is reasonable to assume NTLP should be able to notify
   NSLP to update state (by NSLP refresh/teardown messages
   appropriately). An open issue is, however, how and what information
   the NSLP can expect from NTLP, or directly from the routing
   interface.

   The following Figures 8.1 (a)-(f) illustrates the characteristics of
   flows sent between the corresponding node and the mobile node under
   different mobility scenarios (MIPv6, FMIPv6, HMIPv6; the cases of
   flows sent from the mobile node to the corresponding node for FMIPv6
   and HMIPv6 are similar and omitted here).

   To summarize, an ideal interface between NSIS signaling and mobility
   protocols would be that whenever a mobility protocol changes a
   characteristics in any place for the flows, NSIS signaling should be
   able to react accordingly as soon as possible. However, as identified
   above, an overall coordination/synchronization needs further study.

                      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

    Fig. 8.1: Implications for flows under different mobility scenarios





Manyfolks et al             Expires July 2004                  [Page 33]


Internet-Draft       Mobility and Internet Signaling        January 2004

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


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


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

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


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

                  (e) HMIPv6: CN-->MN, no route optimization


                      CN         pAR          nAR        MN
                      |           |            |          |
                      |MIPv6(normal-HA-tunnel) |          |
                      |----------------------->|          |
                      |           |            |          |
                      |           |  FMIPv6    |          |
                      |           |<-----------|          |
                      |           | (tunnel)   |          |
                      |           |      FMIPv6 (tunnel)  |
                      |           |---------------------->|
                      |           |            |          |

                  (f) FMIPv6: CN-->MN, no route optimization

   Fig. 8.1: Implications for flows under different mobility scenarios





Manyfolks et al             Expires July 2004                  [Page 34]


Internet-Draft       Mobility and Internet Signaling        January 2004

8.2.  Interactions with Seamoby Protocols

   Although the NSIS protocol suite operates in a path-coupled way, the
   interactions between NSIS and Seamoby protocols have an effect on
   parts that are out of the signaling path. In the context of handovers
   between old and new access routers, there can be performance
   optimization issues in the following two areas: selection the optimal
   access router to handover to and transfer of state information
   between the old and new access routers to avoid having to regenerate
   it in the new access router after handover. The Seamoby working group
   is developing protocols solutions for these functions (CARD and CTP
   respectively), but a discussion of the way in which these functions
   interact with NSIS signaling is necessary.

   As mentioned in Section 3.3, significant performance gains can be
   achieved if NSIS signaling can interact with such protocols although
   they can operate independently. In this case, some questions arise:
   which scenario these protocols can be used in, or what the mode of
   interaction should be: pre-establishment and re-establishment
   approaches or passive triggering mode where NSIS is triggered by
   CARD/CTP and active triggering mode where NSIS triggers these
   protocols.

   In general, CARD is required to identify candidate ARs (CARs) for
   handover and find capabilities of these CARs prior to the initiation
   of the IP-layer handover. CTP is used to quickly re-establish context
   transfer-candidate services without processing for those services
   from scratch and additionally to provide an interoperable solution
   that supports various layer 2 radio access technologies. However, in
   the pre-establishment using NSIS, CARD/CTP can interact with the NSIS
   protocol suite to ferret NSIS-aware candidate AR where an MN will
   move and establish NSIS state before the completion of handover. That
   is, the interaction between NSIS and CARD/CTP prevents resources from
   being excessively pre-reserved. In this approach, for the fast setup
   of NSIS state, path update along the candidate NEs may also be
   achieved simultaneously with (or through) discovering a candidate
   CRN.

   When a handover, for example, is initiated, the current AR receiving
   the movement detection information (e.g., 'RtSolPr' message in FMIPv6
   [FMIP] if NSIS also interacts with this mobility protocol) from an MN
   may interact with the CARD to ferret an appropriate (NSIS-aware)
   access router (or a few candidate access routers (CARs) may be
   found). In this process, the NTLP of the current AR should be able to
   recognize whether the CAR is an NSIS-aware node after sending the
   'capability reply' message (of CARD). The QoS-NSLP of the AR may need
   to be interaction with the CTP to transfer the QoS-NSLP state
   information to the newly discovered NSIS-aware candidate AR. After
   receiving the context, the NTLP of the candidate AR may be able to
   begin to trigger the discovery of a candidate CRN using the QoS-NSLP
   state information in the coupled approach or separated approach. QoS
   and context transfer issues have already been considered already some
   time ago in [I-D.thomas-nsis-rsvp-analysis]. More recently [CTP-
   Interop] and [Lee01] present ways and some open issues for

Manyfolks et al             Expires July 2004                  [Page 35]


Internet-Draft       Mobility and Internet Signaling        January 2004

   interoperation between NSIS and CTP in both predictive mode and non-
   predictive mode.

   In the re-establishment approach, CARD can be used to only check
   admission control status on the new path before handover is
   completed, and CTP can be used to transfer NSIS state (e.g., QoS-NSLP
   state) to a CAR to quickly re-establish the state along the new path
   after handover. The main objective of interaction in this approach is
   to reduce state setup delay and packet losses due to handover.

   In case of passive triggering mode, CARD/CTP may use NSIS signaling
   to check the admission control status of CAR and pre-establish NSIS
   state on the candidate path and discover a candidate CRN in the pre-
   establishment approach. In this case, resource availability on the
   path between the AR and CN should also be discovered using NSIS
   signaling. A possible example is that some entity in a candidate AR
   can trigger NSIS using resource and reservation information from the
   current AR to find out about how much resources would be available on
   the new path.

   In the context of NSIS, the NSIS protocol generally can trigger the
   CARD/CTP to transfer its own state information from the current AR to
   CAR: active triggering mode where the NSIS protocol should monitor
   the operation of these protocols. Note that the NSIS protocol, in the
   first place, should interact with mobility protocols (i.e., usually
   with FMIPv6), or be coupled with movement detection mechanisms to
   timely initiate the CARD/CTP in both reservation approaches.

   If NSIS does not consider interworking with CARD/CTP or it is not
   possible to use these protocols, NSIS protocol in itself may be able
   to discover the CAR as an extension of NTLP peer discovery mechanism
   in the separated approach, and to check whether resources on the
   candidate path is available or not before the completion of handover.
   However, this also makes NSIS protocol perform path-decoupled
   signaling, and whether these functions in NSIS can be implicitly
   developed is an open issue.


9.  Additional issues

   This section highlights some important issues not discussed earlier
   in this draft.


9.1.  Both End-Hosts are Mobile

   Considerations about signaling between two mobile devices. Until now,
   we are assuming a non-mobile corresponding node. Problems can show up
   if both devices start to signal at the same time.






Manyfolks et al             Expires July 2004                  [Page 36]


Internet-Draft       Mobility and Internet Signaling        January 2004

9.2.  Uni- and Bi-directional State Establishment

   It should be possible to support unidirectional NSIS state
   establishment in both sender- and receiver-oriented modes. For
   example, in case of QoS-NSLP, the MN (as a sender) can initiate a
   reservation setup for its outgoing flows in the sender-initiated
   mode. With the receiver-initiated approach, the MN (as a sender)
   requests the receiver to make a reservation, thus allowing the
   receiver to initiate a reservation for the flow. After handover of
   the MN (as a sender) to a new AR, the state re-establishment should
   be performed in the similar way.

   In addition to the unidirectional NSIS state establishment above,
   bidirectional state establishment can also be supported. In the basic
   case, bidirectional NSIS signaling can simply use a separate instance
   of the same signaling mechanism in each direction. Although the
   bidirectional data flows have the same end points, the paths in the
   two directions do not need to be the same. Therefore, the CRN of the
   downstream path may be different from that of the upstream path in
   mobility scenarios. As a matter of course, the Session ID in the
   downstream reservation should be different from that of the upstream
   reservation. If the routes (i.e., upstream and downstream paths) are
   symmetric, an NSIS single signaling message can be used to install
   state in both directions. If the routes are asymmetric, an NSIS
   signaling message from the originator (e.g., MN or CN) can trigger an
   independent signaling message from the responder.


9.3.  State Management

   The main objective of NSIS is to manage state information along the
   path taken by a data flow. For state management, the NSIS protocol
   suite normally use a soft-state approach to manage state in NEs where
   the state created by the NSIS message has to be periodically
   refreshed.

   At the NTLP layer, the state is maintained through the exchange of
   GIMPS query/response messages between adjacent peers [ntlp]. 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.

   At the NSLP layer, the peer-to-peer refresh messages can also be used
   for state management. In case of QoS-NSLP, states should be set up
   and maintained for the reservation of desired resources. In this
   context, the operation of QoS-NSLP is similar to that of RSVP [RFC
   2205]. An example of state management at the QoS-NSLP layer is as
   follows. Upon receiving a RESERVE message, an NE (specifically the
   QoS-NSLP) sets up state for QoS reservation. This state will be
   deleted unless it is refreshed by a RESERVE message before the
   refresh timer expires. The peer-to-peer based refreshment allows the

Manyfolks et al             Expires July 2004                  [Page 37]


Internet-Draft       Mobility and Internet Signaling        January 2004

   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 [QoS-NSLP]. 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.

   In case of QoS-NSLP, the main objective of the adjustment of the
   refresh time is to minimize the waste of resources due to double
   reservation. Setting the refresh time in the access network
   differently from that of the backbone network can be done by manual
   configuration or an adaptive technique. A possible example of such
   adaptive techniques is to use a field, e.g.,  'REFRESH' field of the
   mobility object (or Refresh object). The 'REFRESH' field may consist
   of 'M' bit for indicating the type of the network (e.g., the
   mobility-supporting access network) and 'PRE' bit for fast QoS re-
   establishment (e.g., pre-reservation). The refresh timer value of
   pre-reservation state should be maintained for a short period of
   time.

   In mobile and wireless networks, the QoS-NSLP (rather than the NTLP)
   should be able to set the refresh timer value depending on the part
   of the network (e.g., an access network or backbone network) or the
   reservation style (e.g., pre-establishment or re-establishment). For
   example, in case of pre-reservation, upon receiving the mobility
   object during handover, the QoS-NSLP of the NE which is supposedly
   involved in the QoS signaling can set the 'PRE' bit of the outgoing
   QoS-NSLP message. In this case, if the refresh timer value of 'PRE'
   bit 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. Note that after
   handover, QoS-NSLP should restore the original refresh timer value in
   order to avoid the overhead due to the frequent transmissions of the
   refresh message (e.g., 'PRE' bit is reset to null and 'M' bit is kept
   to be 1). Note that, however, procedure for computing the refresh
   time is not part of the NSIS protocol. Thus, how to set the refresh
   timer value of the 'M' and 'PRE' bits according to mobility scenarios
   is also an implementation issue.


9.4.  State establishment in Network Mobility

   The network mobility (NEMO) Working Group is focusing on managing the
   mobility of a mobile network (e.g., a leaf network) which changes its
   point of network attachment as a unit through one or more mobile
   routers (MRs). In this case, the leaf network consists of one or more
   MNs and/or fixed hosts, and it may include multiple heterogeneous
   network interfaces. An MR basically has a Home Agent (HA) and bi-
   directional tunneling between the MR and HA to preserve session
   continuity while the MR moves into other point of network attachment.
   The MR as a single node obtains a CoA as in the MIP mechanism, which
   allows nesting of mobile networks. However, the nested mobile

Manyfolks et al             Expires July 2004                  [Page 38]


Internet-Draft       Mobility and Internet Signaling        January 2004

   networks cause the pinball routing problem because flows of each
   mobile network may transit multiple HAs through multiple bi-
   directional tunnelings. A mobile network can also have multihoming-
   related issues through either a single MR which has multiple
   interfaces to the network, or multiple MRs which attach the mobile
   networks to the network.

   The solutions in the NEMO WG will support preservation of route
   aggregation in the network when flows of MNs (and/or fixed hosts) in
   a mobile network are sent to the same CN. In this case, aggregate
   state installation, e.g., for aggregate reservation (or group
   reservation), should be considered to guarantee resources along the
   aggregated route between the MR of the mobile network and the CN.
   This aggregate state installation issue also requires careful
   consideration in view of mobility related issues in NSIS. To deal
   with aggregate state installation in network mobility, issues such as
   multihoming and pinball routing problem caused by the nested mobile
   network and various scenarios for network mobility should be
   considered. However, it is recommended that such issues be handled in
   liaison with NEMO WG which is still at its early stage in developing
   solutions for the route optimization problem. Therefore, it is
   premature to specify details on the aggregate state installation in
   this draft.


10.  Guidelines for Designers of new NSLPs

   This section presents issues that must be taken into account when
   designing a new NSLP for a mobile and wireless environment. The main
   issues are:

   - IP addresses of the communicating nodes can change during the
     lifetime of the session,
   - The bandwidth of the last-hop link may be limited and vary
     drastically,
   - Routing may be asymmetric,
   - There may be tunnels that hide the original IP packet header,

   - an NE before establishing new state should check whether is already
     has state with the same session ID but a different flow ID. If this
     is the case it needs to find out whether it is CRN and act
     accordingly (details to be spelled out).
   - path repair should be localized
   - procedures for handling DPD should be the same independent of
     whether a peer is truly dead or just changed its IP address because
     of handover.

   <Add here a discussion of what those actually mean for the designer,
   e.g. answers to questions like "so what if the link has low
   bandwidth, what do I care?".





Manyfolks et al             Expires July 2004                  [Page 39]


Internet-Draft       Mobility and Internet Signaling        January 2004

11.  Summary of Split of functionality

   <Summary of what functions should go where, NTLP or NSLP>


12.  Security Considerations

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

   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, as we see
   in the subsequent text, has some implication to the signaling message
   behavior. It is certainly possible that the entities who grant the
   initial reservation and those who subsequently cause modifications
   are not the same entities.

   Please also note that NSIS does not mandate a single model for the
   initial authorization step (such as receiver has to provide
   authorization as in RSVP). Hence it is necessary to consider more
   combinations. As argued in [NSIS-AAA] it is necessary to consider
   cases where the sender, the receiver or both are authorizing a
   reservation.  The reader should keep in mind that these signaling
   message exchanges are not only applicable for QoS reservations but
   also for other NSLP applications such as NAT/Firewall signaling. The
   concept of sender- and receiver-initiated reservations is very vague
   in case of NAT/Firewall signaling. There a concept of delayed
   authorization is suggested with requires both, the sender and the
   receiver, to authorize packet and NAT binding establishment.

   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.
   Each scenario is separated into more individual scenarios.


12.1.  MN as data sender

   Figure 12.1 describes a scenario with the MN as a data sender which
   moves from one point of attachment to another. The two flows are
   merged at the DCOR. The path between the DCOR and the CN is referred
   as the shared segment. Along the shared segment it might be necessary
   to update the flow identifier but not the NSLP state itself.











Manyfolks et al             Expires July 2004                  [Page 40]


Internet-Draft       Mobility and Internet Signaling        January 2004

                              new segment

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

   ========================= DATA ===================================>

   Legend:
   >>>>>>>: denotes signaling message flow
            the direction of the arrow shows the direction of the
            initial signaling flow direction
   <------: movement
   <======: data flow (direction indicated with arrow)

                      Figure 12.1: MN as data sender

   We will start with the initial flow setup triggered by the MN and
   also authorized by the MN.


12.1.1.  MN is authorizing entity

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

      MN                                              CN

       ------>----->------>------>------>------>------>    +
                  ACTION (MN is authz)                     |
                                                           |
       <-----<-----<------<------<------<------<-------    | Flow
                           ACK                             | Setup
                                                           |
       ===============================================>    +
                            Traffic
               Figure 12.2: Initial MN authorized flow setup


Manyfolks et al             Expires July 2004                  [Page 41]


Internet-Draft       Mobility and Internet Signaling        January 2004

   The following questions seem to be interesting:

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

   - What information should be used for this purpose?

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

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

   Scenario: The MN authorizes DCOR

   The movement of the mobile node after the initial flow setup requires
   authorization. Various session ownership authorization issues are
   illustrated in the [SID] draft itself. We will not repeat these
   issues in this document again.

       MN                    DCOR                      CN

                                                          + E.g.
       ------>----->------>------>------>------>------>   | Movement
                           ACTION                         | with state
                                                          | creation at
       <-----<-----<------<------<------<------<-------   + new path
                            ACK
                      Figure 12.3: MN authorizes DCOR

   The following questions are of interest:

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

   - 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 DCOR and between the
   DCOR and the CN know that the DCOR is now acting on behalf of the MN?


   Scenario: The CN triggers action

   CN wants to tear-down flow or it wants to trigger an action in the
   network





Manyfolks et al             Expires July 2004                  [Page 42]


Internet-Draft       Mobility and Internet Signaling        January 2004

       MN                    DCOR                      CN


      <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    +
                         TRIGGER                          | E.g.
                                                          | Tear
                                                          | Down
       ------>----->------>------>------>------>------>   |
                           ACTION                         |
                                                          |
       <-----<-----<------<------<------<------<-------   +
                            ACK
                      Figure 12.4: CN triggers action

   Questions:

   - Why should the MN trust the trigger?

   - Is it possible to specify the security properties of the trigger
   message in more detail? (If this is an NSIS message then we could
   argue that hop-by-hop trust does not always replace end-to-end
   security.)

   - (see for example the discussion in <draft-tschofenig-nsis-aaa-
   issues-01.txt> with regard to an indicator which entity to charge for
   the reservation.

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


12.1.2.  CN is authorizing entity

   This scenario is quite similar to the CN triggering in Section 1.1.1.
   Two slightly different protocol variations will be considered.
   Authorizing some actions in the reverse data flow direction is more
   difficult as it can easily be seen in Figure 12.5.

   Variant 1: CN asks MN to trigger action (on behalf of the CN)

   In Figure 12.5 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 DCOR. The message travels
   along the shared segment to the CN and updates the flow identifier
   (if necessary). The MN might additionally allow the DCOR to delete
   the reservation along the old segment.







Manyfolks et al             Expires July 2004                  [Page 43]


Internet-Draft       Mobility and Internet Signaling        January 2004

       MN                    DCOR                         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 12.5: CN asks MN to trigger an action (on behalf of the CN)

   Questions:

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

   - Is it possible to carry this information with the Trigger
     message from the CN and the MN?

   Variant 2: CN uses installed state to route message backward

   As a second variant the CN uses NSIS installed state to route a
   signaling message backward along the path. In some rare cases the
   DCOR 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).  The optimistic delete operation is
   certainly more error prone.

   As it can easily be seen from the description many assumptions have
   to be made in order for this signaling exchange to work. Hence, as a
   generic solution this approach is certainly not suggested. We
   included this scenario for completeness.



Manyfolks et al             Expires July 2004                  [Page 44]


Internet-Draft       Mobility and Internet Signaling        January 2004

      MN                    DCOR                          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 12.6: CN uses installed state to route message backward

   Questions:

   - Similarly as before the security properties of the trigger message
   need to be evaluated.

   - It is not always possible to route the message backward from the
     CN to the MN:

     a) state at the new path might not be established (hence the
        signaling message cannot travel backward)
     b) 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 two paths 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.





Manyfolks et al             Expires July 2004                  [Page 45]


Internet-Draft       Mobility and Internet Signaling        January 2004

12.1.3.  MN and CN are authorized

   If we argue that the authorization at the NSLP layer is somehow tight
   to the authorization issues discussed in this section (i.e.,
   authorization for certain protocol actions) then we also have to
   consider the case where both nodes (MN and CN) have to contribute
   their part 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 costs.

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


12.2.  CN as data sender

   In this section we consider the scenarios where the CN acts as a data
   sender. Except for some minor issues we believe that the requirements
   caused by the signaling exchanges are mostly discussed in Section 1.3
   already.

                              new segment

                   +--+          +---+   new flow
         new       |MN|<<<<<<<<<<|NAR|<<<<<<<<<<<<<^
         address   +--+          +---+             ^
                 ^                              +----+          +--+
                 |                              |UCOR|<<<<<<<<<<|CN|
                 |                              |    |<<<<<<<<<<|  |
                 |                              +----+          +--+
                 | +--+          +---+             V    shared
         original  |MN|<<<<<<<<<<|OAR|<<<<<<<<<<<<<V    segment
         address   +--+          +---+   original
                                           flow
                 MN acts      old segment
                 as DCOR
   <========================= DATA =================================
                      Figure 12.7: CN as data sender

   Figure 12.7 shows the corresponding node as a data sender with the
   mobile node moving from OAR to NAR. As a consequence the CN is
   triggered to update its QoS reservation along the path. The shared
   segment only requires an update of the flow identifier (except if the
   home address is used) but authorization is unaffected since no change
   in authorization or security relationship is required. Then the
   signaling message hits the UCOR where the old segment and the new
   segment form a branch. If necessary then the CN authorized the
   deletion of the old reservation along the old segment and a new

Manyfolks et al             Expires July 2004                  [Page 46]


Internet-Draft       Mobility and Internet Signaling        January 2004

   reservation needs to be created along the new path. In some sense
   this procedure is similar to a route change.  It is even possible
   that the MN is still reachable via both paths.


12.2.1.  CN is authorizing entity

   This scenario is similar to the one described in Section 1.3.1. No
   additional problems arise with a scenario where the CN is both data
   sender and also authorized. In Figure 12.8 the CN authorizes the UCOR
   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                    UCOR                      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.8: CN as data sender is authorized

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

   1) The MN sends a trigger to CN and CN starts signaling flow as shown
   in Figure 12.8.

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

   3) An intermediate node act on its own. This might be possible that
   the UCOR is an entity which participates in the mobility signaling
   (e.g., MAP) exchange. Depending on the message exchange it needs to
   be studied whether the signaling message provides sufficient

Manyfolks et al             Expires July 2004                  [Page 47]


Internet-Draft       Mobility and Internet Signaling        January 2004

   authorization to trigger the NSIS exchange.


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


12.3.  Multi-homing Scenarios

   Multi-homing scenarios have the property that the more than one path
   belongs to a signaling session. In Figure 12.9 the MN uses two
   interfaces to route NSIS message towards the CN. Both 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 DCOR 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 DCOR needs to merge the two reservation into a
   single one along the shared segment.


12.3.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 |                            |DCOR|>>>>>>>>>>|CN|
         |UCOR|                            |    |>>>>>>>>>>|  |
         +----+                            +----+          +--+
            v               +---+             ^    shared
            v>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>^    segment
                            +---+
                         segment 1

   ===============================================================>
                            Traffic
                Figure 12.9: Multi-homed MN as data sender

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

Manyfolks et al             Expires July 2004                  [Page 48]


Internet-Draft       Mobility and Internet Signaling        January 2004

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


12.3.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 1.5.1 since the signaling message along
   the shared segment travels the previously established path. This
   scenario is similar to the 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 appearing at a new interface belongs to the
   indicated session authorized by the CN.

   If the MN is the authorizing entity then again communication between
   the end hosts is required as a trigger. Reverse routing might, in
   some cases, also be possible.

                        segment 2
                           +---+
           v<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<^
           v               +---+             ^
        +----+                            +----+          +--+
        | MN |                            |UCOR|<<<<<<<<<<|CN|
        |DCOR|                            |    |<<<<<<<<<<|  |
        +----+                            +----+          +--+
           ^               +---+             v    shared
           ^<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<v    segment
                           +---+
                        segment 1

   <=============================================================
                            Traffic
                Figure 12.10: Multi-homed CN as data sender


12.4.  Context Transfer

   Figure 12.9 is taken from [CTP-Interop] and reused to illustrate
   authorization issues.

   Intra-domain mobility with the help of the context transfer protocol
   can help to move established state information between different
   access nodes within the same administrative domain including security

Manyfolks et al             Expires July 2004                  [Page 49]


Internet-Draft       Mobility and Internet Signaling        January 2004

   associations, QoS parameters (QoS NSLP state), NTLP state and even
   authorization information. An authorization for a QoS reservation
   granted along one path through the access network might also valid at
   a different access router or even at a different path within the same
   administrative domain. Discussions in the EAP working group, however,
   reveal that this might not always be the case. However, if we extend
   the scheme from intra-domain context transfer to inter-domain context
   transfer then we might encounter some interesting authorization
   problems. Note that these issues do not only address authorization of
   QoS resources, but are more applicable to network access
   authentication and authorization in general. Network access
   authentication and authorization would not necessarily be executed
   again after attaching to the new domain. Instead, a trust
   relationship is established between the new and the old
   administrative domain.

                       +------------+
       +--+            | previous   |        <
       |MN| ---------- | Access     | ------ > ----\
       +--+            | Router(pAR)|        <      \
         |             +------------+          +-------------+
         | moving            ^            IP   |Correspondent|
         |                   |NSIS-CTP   Core  |Node (CN)    |
         V                   |         Network +-------------+
                             v                        /
                       +------------+                /
       +--+            | new        | NSIS   <      /
       |MN| ---------- | Access     | ------ > ----/
       +--+            | Router(nAR)|        <
                       +------------+
                      Figure 12.11: Context Transfer

   For the signaling message exchange in the predictive and non-
   predictive CT mode it can be seen that the assumption is made that
   the MN is the authorizing entity. A communication with the CN does
   not take place and would certainly increase the complexity of the
   protocol exchange. The authorization properties of the Context
   Transfer procedure (and some micro-mobility schemes) need to be
   studied in more detail to see their implications for security.

   The context transfer procedure seems to provide a simple solution for
   some session ownership problems (in case that the MN is authorized).


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

Manyfolks et al             Expires July 2004                  [Page 50]


Internet-Draft       Mobility and Internet Signaling        January 2004

   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.


12.6.  Implications for the costs of a QoS reservation

   It is obvious that mobility support within NSIS raises security
   issues.  A number of mobility scenarios with impacts on security are
   discussed in Section 7 of [NSIS-AAA]. Even if the signaling message
   exchange is restarted from scratch (i.e., using a new flow-ID),
   security handling within NSIS is affected. This type of processing
   is, however, mostly not a topic for this draft.


12.6.1.  Missing Cost Control

   A large number of service providers (e.g., wireless LAN hot spots)
   with complex roaming agreements create a non-transparent cost
   structure. In a traditional subscription-based scenario, users are
   subscribed to their home network and use this trust relationship to
   dynamically establish a financial settlement between the visited
   network and the home network.  Additionally, security associations
   are dynamically established as part of this procedure. This is the
   typical AAA deployment scenario. In these scenarios users do not
   learn the identity of the access network as part of a regular
   authentication and key exchange protocol message exchange.  The
   identity of the access network is possibly never revealed (in a
   secure fashion). The user is therefore only authenticated to the home
   network (and hopefully vice versa). While issuing a QoS reservation
   request to the next NSIS peer (for example in the access network),
   the end host is typically unaware of the cost of such an end-to-end
   QoS reservation. Without knowing the costs it is not possible to
   reject a too expensive QoS reservation.

   Currently there is no standardized protocol available which allows
   users to communicate cost limits, to request cost information for
   network resources or to learn already accumulated costs for a
   particular reservation.

   Especially in mobility environments - where an end host is likely to
   have access to different networks within a short time period - cost
   control is even more complicated.


Manyfolks et al             Expires July 2004                  [Page 51]


Internet-Draft       Mobility and Internet Signaling        January 2004

   Some protocol proposals try to merge existing mobility protocols with
   QoS signaling (i.e., a form of in-band signaling). Thereby the access
   network is queried (towards the crossover router or the MAP) for the
   possibility of making a QoS reservation (without actually making the
   reservation itself). Without a query mechanism, a user cannot take
   reservation costs into account when choosing between different access
   networks (or different access routers). Hence, the user might be able
   to refuse a more expensive service provider. The ability to allow a
   user to choose between different providers might be required - not
   only because of the availability of different access technologies
   (e.g., IEEE 802.1x, Bluetooth, UTRAN) and different service quality
   offered, but also for cost reasons.

   Although real-time notifications of QoS reservation costs (cost
   control) to the user are out of the scope of NSIS, some interaction
   might be required.


12.6.2.  Implications for Price Determination

   The problem of determining the price of a QoS reservation has been
   mentioned in [NSIS-AAA] and closely relates to integrating the end
   host into the process of authorization. Even if the end host is aware
   of the price of a QoS reservation during reservation setup the price
   might change for a number of reasons:

   o First, mobility in general causes a different path to be chosen and
   might therefore require a new price determination. End host mobility
   is visible to the end host itself, therefore the appropriate actions
   can be triggered by the end host to always determine the correct
   price.

   o Route changes somewhere along the path, e.g., mobility in NEMO
   networks or even mobility in ad-hoc networks, create more problems,
   since the route change might not be visible for the end host. If
   price determination is based on the number of networks traversed and
   intermediate nodes which contribute to the total price of a QoS
   reservation, then a periodic price query is necessary. Discussions at
   the NEMO mailing list already point to this problem [Nemo-ML]. If the
   price of QoS reservation is associated with the authorization itself,
   then a periodic re-authorization based on the change of prices or on
   the accumulated costs is necessary.


12.7.  Conclusion

   This security considerations section illustrates the importance of
   authorization for NSIS in a mobility environment. Performance is
   important in mobility environments. 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:


Manyfolks et al             Expires July 2004                  [Page 52]


Internet-Draft       Mobility and Internet Signaling        January 2004

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

   - There are many similarities between the scenarios in Section X (MN
   as data sender) and Section Y (CN as data sender) particularly if we
   include multi-homing scenarios.

   - Most issues are related to authorization problems that appear after
   the initial flow setup took place. In this case we speak about the
   following problem: "Is an entity allowed to perform the indicated
   action." Only a few problems are related to authorization problems
   which already appear during 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.

   In the [SID] draft we tried to raise the question of a possible
   security goal. We list a few variations of this goal:

   Version 1:

   An off-path adversary MUST NOT be able to inject messages which are
   then accepted by NSIS nodes along the path. An NSIS node which once
   was along the data path is not treated as an adversary.

   Version 2:

   Only end points MUST be able to create messages and intermediate NSIS
   nodes MUST be able to verify them.

   Version 3:

   Only the session creator MUST be able to create messages which are
   then successfully verifiable by intermediate NSIS nodes.

   Based on the first version of the goal it might be necessary to
   differentiate between NSIS nodes which are currently part of the
   signaling chain (i.e., nodes which are currently part of the NSIS
   signaling message processing) and NSIS nodes which previously were
   part of this chain.

   Furthermore, it might be useful to differentiate between different
   messages:

   - Refresh, delete or update messages: I assume that these messages
   are not idempotent and hence previous state along some nodes has to
   be established already. To provide security for the 'different peer'
   case it might still be required to provide some security for the
   session identifier. This issue is, however, not as dangerous as the
   threat described in the SID draft.


Manyfolks et al             Expires July 2004                  [Page 53]


Internet-Draft       Mobility and Internet Signaling        January 2004

   - Create messages: This message is particularly dangerous since it
   requires (in case of a sender-initiated message) no previous state.
   The threat description in the SID draft is immediately applicable. A
   receiver-initiated signaling message is, from a session identifier
   point of view, better since previously created state can be used.
   This might provide some security, although not too much considering
   the limited capabilities of the responder to truly provide some
   additional authorization capabilities (due to missing end-to-end
   security protection or in case of signaling proxies).

   - Query alike messages: These message types require little protection
   since they do little harm to the state. They still might allow an
   adversary to gain information about the reserved resources.

   - Error messages: These messages are also sensitive but are typically
   returned after a request was submitted. This is, however, not true
   for asynchronous error messages. Still some state has to be created
   to allow routing along the established path.

   Currently, this analysis does not consider the different message
   types.

   As a final conclusion we must state that more discussion is necessary
   to address security and mobility handling in an appropriate way.
   Particularly, the expected NSIS signaling behavior must be described.
   The improvements due to mobility functionality within NSIS must be
   compared with the increased complexity. Careful analysis and
   performance evaluations are necessary.


13.  Contributors

   This draft initially written by Roland Bless, Xiaoming Fu, Robert
   Hancock, Seong-Ho Jeong, Cornelia Kappler, Sung-Hyuck Lee, Jukka
   Manner, Paulo Mendes, and Hannes Tschofenig.


14.  Acknowledgments

   This draft is based on four earlier drafts by (in alphabetical order)
   Jongho Bang, Roland Bless, Xiaoming Fu, Robert Hancock, Seong-Ho
   Jeong, Cornelia Kappler, Sung-Hyuck Lee, Byoung-Joon Lee, Jukka
   Manner, Paulo Mendes, Henning Schulzrinne, Charles Q. Shen, and
   Hannes Tschofenig.


15.  Informative References

   [mipv4] Perkins, C., "IP Mobility Support for IPv4," RFC 3344, Aug.
   2002.

   [mipv6] Johnson, D., Perkins, C. and J. Arkko, Mobility Support in
   IPv6, draft-ietf-mobileip-ipv6-24 (work in progress), June 2003.


Manyfolks et al             Expires July 2004                  [Page 54]


Internet-Draft       Mobility and Internet Signaling        January 2004

   [lmm] Carl Williams, "Localized Mobility Management Requirements",
   draft-ietf-mipshop-lmm-requirements-00 (work in progress), Oct 2003.

   [fmip] Koodli, R., "Fast Handovers for Mobile IPv6",
   draft-ietf-mipshop-fast-mipv6-00 (work in progress), Oct 2003.

   [hmipv6] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
   "Hierarchical Mobile IPv6 mobility management (HMIPv6)",
   draft-ietf-mipshop-hmipv6-00 (work in progress), Oct. 2003.

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

   [ntlp] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
   Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-00 (work in
   progress), Oct. 2003.

   [nsis-req] Brunner, M., "Requirements for Signaling Protocols",
   draft-ietf-nsis-req-09 (work in progress), August 2003.

   [nsis-analysis] Manner, J., Fu, X. and P. Pan, "Analysis of Existing
   Quality of Service Signaling Protocols",
   draft-ietf-nsis-signalling-analysis-03 (work in progress), Oct 2003.

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

   [RFC2746] Terzis, A., Wroclawski, J. and L. Zhang, "RSVP Operation
   Over IP Tunnels", RFC 2746, January 2000.

   [RFC3583] Chaskar, H., "Requirements of a Quality of Service (QoS)
   Solution for Mobile IP", RFC 3583, September 2003.

   [manner02] Manner, J., Lopez, A., Mihailovic, A., Velayos, H.,
   Hepworth, E. and Y. Khouaja, "Evaluation of mobility and QoS
   interaction", Computer Networks vol.38, no.2, pp.137-163, February
   2002.

   [Seamoby-terms] Jukka Manner, Markku Kojo (editors) Mobility Related
   Terminology Internet Draft (work in progress), November, 2003.

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

   [I-D.schulzrinne-nsis-casp] Schulzrinne, H. and et al., "CASP -
   Cross-Application Signaling Protocol", draft-schulzrinne-nsis-casp-01
   (work in progress), March 2003.

   [fu03] Fu, X., Schulzrinne, H. and H. Tschofenig, "Mobility Support
   for Next-Generation Internet Signaling Protocols", Proceedings of
   IEEE Vehicular Technology Conference 2003-Fall, October 2003.


Manyfolks et al             Expires July 2004                  [Page 55]


Internet-Draft       Mobility and Internet Signaling        January 2004

   [I-D.ietf-nsis-qos-nslp] Van den Bosch, S. and et al., "NSLP for
   Quality-of-Service signaling", draft-iet f-nsis-qos-nslp-00 (work in
   progress), September 2003.

   [I-D.westphal-nsis-qos-mobileip] Westphal, C. and H. Chaskar, "QoS
   Signaling Framework for Mobile IP",
   draft-westphal-nsis-qos-mobileip-00 (work in progress), June 2002.

   [SID] Tschofenig, H. et al.: "Security Implications of the Session
   Identifier", <draft-tschofenig-nsis-sid-00.txt>, (work in progress),
   June 2003.

   [CTP-Interop] "A Framework for Interoperation between NSIS and CTP",
   <draft-soltwisch-nsis-ctp-interop-00.txt>, (work in progress),
   October, 2003.

   [NSIS-AAA] Tschofenig, H., et al.: "NSIS Authentication,
   Authorization and Accounting Issues",
   <draft-tschofenig-nsis-aaa-issues-01.txt>, (work in progress),
   March 2003.

   [NSIS-Authz] Tschofenig, H., et al.: "QoS NSLP Authorization Issues",
   <draft-tschofenig-nsis-qos-authz-issues-00.txt>, (work in progress),
   June 2003.

   [Nemo-ML] Alper, Y., "[nemo] AAA and NEMO", discussion in the IETF
   Nemo Mailing List (available at:
   http://www.nal.motlabs.com/pipermail/nemo/2003-February/000271.html),
   February 2003.

   [Lee01] S.-H. Lee, and et al.,
   "Mobility Functions in the QoS NSLP", Internet Draft, Work in
   progress, October 2003.

   [Jeong01] S.-H. Jeong, and et al.,
   "Mobility Functions in the NTLP", Internet Draft, Work in
   progress, October 2003.

   [I-D.thomas-nsis-rsvp-analysis] Thomas, M., "Analysis of Mobile
   IP and RSVP Interactions", draft-thomas-nsis-rsvp-analysis-00
   (work in progress), November 2002.


16.  Author's Addresses

   Questions about this document may be directed to:

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

Manyfolks et al             Expires July 2004                  [Page 56]


Internet-Draft       Mobility and Internet Signaling        January 2004

   Xiaoming Fu
   University of Goettingen
   Telematics Group
   Lotzestr. 16-18
   Goettingen  37083
   Germany
   E-Mail: fu@cs.uni-goettingen.de

   Robert Hancock
   Siemens/Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom
   Voice:  +44-1794-833601
   Fax:    +44-1794-833434
   E-Mail: robert.hancock@roke.co.uk

   Seong-Ho Jeong
   Hankuk University of FS
   89 Wangsan, Mohyun
   Yongin-si, Gyeonggi-do  449-791
   Korea
   Phone: +82 31 330 4642
   E-Mail: shjeong@hufs.ac.kr

   Cornelia Kappler
   Siemens AG
   Siemensdamm 62
   Berlin  13627
   Germany
   EMail: cornelia.kappler@siemens.com

   Sung-Hyuck Lee
   SAMSUNG Advanced Institute of Technology
   San 14-1, Nongseo-ri, Giheung-eup
   Yongin-si, Gyeonggi-do  449-712
   KOREA
   Voice:  +82-31-280-9585
   Fax:    +82-31-280-9569
   E-Mail: starsu.lee@samsung.com

   Jukka Manner
   Department of Computer Science
   University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   FIN-00014 HELSINKI
   Finland
   Voice:  +358-9-191-44210
   Fax:    +358-9-191-44441
   E-Mail: jmanner@cs.helsinki.fi

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

Manyfolks et al             Expires July 2004                  [Page 57]


Internet-Draft       Mobility and Internet Signaling        January 2004

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

   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   EMail: Hannes.Tschofenig@siemens.com

   Full Copyright Statement

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

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

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

















Manyfolks et al             Expires July 2004                  [Page 58]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/