Internet Engineering Task Force                          Charles Qi Shen
Internet Draft                                                       ICR
July 12, 2002
Expires: January 2003

         Several Framework Issues Regarding NSIS and Mobility


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section&nbsp;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-

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

   To view the list Internet-Draft Shadow Directories, see

1 Abstract

   This memo discusses several framework issues related to Next Step In
   Signaling (NSIS) and mobility interaction. The first issue is related
   to handoff impact on NSIS operation. We present several general
   requirements for NSIS and mobility, followed by evaluation of how
   specific approaches using Mobile IP or other mechanisms might fit
   into the picture. Other issues covered include NSIS and mobility
   signaling layering and soft-state management.

2 Introduction

   The IETF Next Step In Signaling (NSIS) WG is currently looking at
   requirements and framework issues for a general resource signaling
   protocol. It is expected that the interaction between such a protocol
   (or protocol suite) and general mobility mechanisms is an important
   part of the overall framework.

   This memo presents our view on several framework issues concerning
   NSIS and Mobility interaction. The discussions here are largely

Charles Qi Shen                                               [Page 1]

Internet Draft       NSIS Mobility Framework Issues        July 12, 2002

   driven by our experience in designing and prototyping an RSVP-Mobile
   IPv6 interoperation framework [1,2] as well as by some good coverage
   on the same topic in existing NSIS framework proposals such as [3].

   The first issue is related to impact of handoff on NSIS operation.
   Since NSIS is expected to be interacting with general mobility
   mechanisms, we take the approach of analyzing some general
   requirements concerning NSIS and general mobility problem first. Then
   we use Mobile IPv6 and other mobility mechanisms as examples, to show
   how they may fit into these requirements when applied. The important
   point is to show how distinct features of specific mobility
   mechanisms make them distinct in their ability to meet the given
   requirements. After the handoff issue, we also talked about issues
   such as Signaling Layering and Soft-State management.

   Our basic assumption in this memo is in-band signaling with a one-
   sender and one-receiver scenario.

3 Issues about Handoff Impact on NSIS Protocol Operation

3.1 The Need for a Separate View on Data and Control Plane Identifiers

   In exsiting signaling protocol such as RSVP, resource reservation is
   usually done for a flow from a Sender to a Receiver. Typically a flow
   is identified by the IP 5-tuple (Src, Dst address, protocol id and
   port number) or in IPv6 by the IP 3-tuple (Src, Dst address and Flow
   Label). This flow identifier basically serves two purposes in two

        o Data Plane: it is used by packet classification mechanism for
          filtering the data packets that are entitled to the reserved

        o Control Plane: it is used by the state management entity in
          locating the specific state maintained for the specific flow.
          The flow identifier can actually be seen as a reservation
          identifier in this sense.

   Although it is fine to have a single identifier used in both Data and
   Control plane as in the traditional case, problems arises due to
   mobility may require two different identifiers to be used in
   respective planes, although they should still keep associated with
   each other.

3.2 Handoff Problem Statement and Basic Requirements

   Handoff is the major cause for the complexity in NSIS and mobility
   interaction. Handoff basically results in the original flow path

Charles Qi Shen                                               [Page 2]

Internet Draft       NSIS Mobility Framework Issues        July 12, 2002

   between a sender and a receiver being split into three portions, all
   of which intersects at a cross-over router: The unchanged (common to
   old and new) portion, the newly added portion and the obsoleted
   portion. To simplify, we will denote the three as: Common path, new
   path, obsoleted path respectively.

   The ideal requirements for NSIS and mobility interaction, looking
   from two different planes respectively, could be:

        o Control Plane: During handoff signaling phase, routers within
          the common path should be kept transparent to mobility;
          routers within the new path should establish corresponding
          states as soon as possible, and routers within the old path
          should delete corresponding states as soon as possible.

        o Data Plane: The Data Plane should be transparent to mobility
          if possible.

   Fulfillment of the Control Plane requirement ensures minimized impact
   caused by handoff on state management. Otherwise, it is likely that
   handoff signaling will have to be propagated along the common path to
   update state information in routers there and additional mechanism is
   also required to ensure no duplication of states/reservations is
   created for the same flow due to handoff.

   Fulfillment of the Data Plane requirement ensures a seamless service
   for data packets belong to the flow. Otherwise it is likely that
   service disruption will be perceived due to handoff. Note that unable
   to fulfill the Data Plane requirement potentially excludes the
   possibility of complete fulfillment of Control Plane requirement, as
   will be shown below.

3.3 Evaluation of Existing Framework Proposals using Mobile IP Against

   Mobile IP is likely to be one of the pre-dominant mechanism used for
   IP mobility. With Mobile IP, MN is assigned HA and CoAs. The former
   keeps constant while the latter changes during handoff. So whether
   and how these addresses are used to form Data Plane/ Control Plane
   identifier will have important impact on how the proposal will meet
   the above stated requirements.

3.3.1 Approach I

   Approach I: In [1], it is proposed that MNs' HAs instead of CoAs are
   used in the 3-tuple Data Plane flow identifier for packet
   classification. Furthermore HAs are also used to identify
   corresponding reservation states, thus it is used as Control Plane

Charles Qi Shen                                               [Page 3]

Internet Draft       NSIS Mobility Framework Issues        July 12, 2002

   reservation identifier as well.

   It can be seen that in this approach, Data Plane identifier and
   Control Plane identifier share the same information, which is HA.
   Both of them are kept constant as well. Thus both Data Plane and
   Control Plane requirements are met.

   However, it is understood that an additional issue with this approach
   is: the placement of MNs' HA in IP header as specified in current
   Mobile IPv6 makes it necessary to complicate the packet
   classification engine if HAs are used as Data Plane flow identifier.

3.3.2 Approach II

   Approach II: The alternative to using MN's HA as Data Plane flow
   identifier is naturally the use of MN's CoA, such as in [4].

   It can be seen that with this approach, the Data Plane requirement
   can not be met because the flow identifier changes during handoff.
   The changed flow identifier will have to be propagated along the
   common path, in addition to the new path. Thus the first part of
   Control Plane requirement, which states routers in common path be
   kept transparent to handoff, can not be met as well. The rest part of
   the Control Plane requirement however, can be met by using separate
   reservation identifiers. Example could be the session identifier as
   in [4]. By comparing the previous QoS session identifiers and new QoS
   session identifiers in the signaling packet and state information,
   the cross-over router could be identified and duplication of
   reservation for the same flow may be avoided.

3.3.3 Approach III

   Approach III: Based on the above analysis, a third approach is also
   possible: to combine the above approach II for Data Plane and
   approach I for Control Plane. That is, use CoAs for flow identifier
   thus relieves the concern on packet classification, while use HAs to
   form a unique identifier in the Control Plane. The use of HAs for
   unique identifier in Control planes seems to be natural for a
   protocol like Mobile IP. This is also in line with what is mentioned
   in [5], flow state establishment methods SHOULD include the Mobile IP
   HAs if available, to avoid state duplication on fixed portions of the
   path when either end changes its Care-of Address. This approach can
   be seen as one step further from [1,2] and is currently under study.

3.3.4 Summary Notes

   In summary, the following are the possibilities that can happen when
   matching an existing solution with the two requirements:

Charles Qi Shen                                               [Page 4]

Internet Draft       NSIS Mobility Framework Issues        July 12, 2002

        o Both requirements are met, such as approach I. (Although
          additional concern with Packet Classification could present.)

        o The Data Plane requirement is not met, then the Control Plane
          requirement can at most be partially met, such as approach II
          and III.

        o The Control Plane requirement is not met. It is still possible
          to meet the Data Plane requirement although this kind of
          approaches seem less attractive. The reason is when Data Plain
          requirement can be fulfilled, it is usually not difficult to
          meet the Control Plane requirement at the same time.

        o Neither of the requirements are met. This is likely when the
          resource signaling and mobility mechanism are completely
          unaware of each other.

3.4 Evaluation with Other Possible Mobility Mechanisms Against

   According to the above analysis, how a given mobility mechanism can
   fulfill the requirements when interact with NSIS is largely dependent
   on the mechanism feature itself. In the case of Mobile IPv6, it seems
   difficult to achieve the Data plane requirement without complicating
   the packet classification engine. Other mobility mechanisms, or
   optimization schemes to Mobile IPv6, however, might make it possible
   in certain situations, for example in the case of Local mobility
   management [6].

   As in local mobility management, when the mobile node is moving
   within a Local Coverage Area (LCA), its change of IP address is not
   seen by nodes beyond that area. It may be preferable to look at the
   flow path in two segments, one from the border of LCA to CN and the
   other within LCA. For the first segment, the Data Plane requirement
   can be easily fulfilled as long as MN is within the LCA, hence it is
   also not difficult to meet the Control Plane requirement for that
   part. A both-requirement-met approach can be applied in this

   It should be noted that within LCA or when the MN moves out of LCA,
   the situation is quite different since there are IP address changes.
   Approaches similar to what has been discussed above for Mobile IPv6
   may be applied. This example implies that there might be a
   requirement for NSIS to interact with LMM, similar to the requirement
   for it to interact with Fast handoff and Context Transfer, if

4 Issues on Signaling Layering Between NSIS and Mobility

Charles Qi Shen                                               [Page 5]

Internet Draft       NSIS Mobility Framework Issues        July 12, 2002

   It is expected that NSIS would use a multi-level architecture. In
   most of existing NSIS framework proposals (e.g., [7,3]) it is assumed
   that there exists a NSIS protocol transport level. This raises a
   possible problem of additional signaling layering issue as far as
   mobility is concerned. Specifically, NSIS's general protocol
   transport should be properly and efficiently layered with the
   mobility signaling transport, if such a need for a mixed resource and
   mobility signaling is present (similar to what is mentioned in [3] as
   tight integration).  Some existing work has already lead to the
   question of whether resource signaling should be layered on top of
   mobility signaling or should it be the other way around. The first
   approach is taken by [8,9,10]. And as stated in [3], this is
   considered as a special case of NSIS layering, with the mobility
   protocol playing the role of the signaling transport. The second
   approach is taken by [1] which puts mobility related information into
   resource signaling messages transported by resource signaling
   protocols' own mechanism.

   It in fact seems pre-mature to answer the question of which is better
   at this time, when the exact nature of a generic transport layer for
   NSIS has not even been clearly defined. However, considering the
   general purpose of NSIS and the requirement that NSIS - mobility
   should be considered without assuming any specific mobility, it seems
   more appropriate at least initially, not to layer resource signaling
   messages on any particular mobility mechanism.  Rather we suggest
   that it may be preferable to define some common interface between
   NSIS and (any) mobility mechanisms, probably by putting a mobility
   adaptation level(layer) in the overall NSIS framework. Specific
   parameters passed into the adaptation layer can be mobility mechanism
   dependent if required. Ultimately these signaling could still be
   supported by the NSIS signaling transport itself. For this kind of
   framework, [2] might serve as one possible starting point.

5 Issue on Soft-State Management in NSIS and Mobility Interaction

   When soft-state mechanism is used for the NSIS protocol, how the
   refresh is done could have important implications when NSIS and
   mobility is concerned. If the NSIS refresh message is issued end to
   end and processed and forwarded by each intermediate routers similar
   to, e.g the RSVP Path refresh case, this implies: First, in order to
   route the refresh message correctly, the sender may have to know the
   receiver's new location.  Second, intermediate routers also need to
   maintain its own copy of the receiver's new loaction before it can
   forward the refresh to the next hop, this is required if the
   signaling mechanism in the router do not want to rely on IP header of
   the received Refresh message to construct the Refresh message that is
   sent out to next hop (to maintain a clear interface between the
   signaling protocol and IP layer).  This means the handoff signaling

Charles Qi Shen                                               [Page 6]

Internet Draft       NSIS Mobility Framework Issues        July 12, 2002

   message will always have to go beyond the cross-over router even
   though a unique reservation identifier may be used. This has been
   shown in [1,2]. Note that this problem is present for all three
   approaches mentioned in the first section of this memo. The problem
   might be partially relieved if a direct neighbor to neighbor refresh
   mechanism were used.

6 Bibliography

   [1] C. Q. Shen, W. Seah, A. Lo, H. Zheng, and M. Greis, "An
   Interoperation Framework for Using RSVP in Mobile IPv6 Networks,"
   draft-shen-rsvp-mobileipv6-interop-00.txt , July 2001.  Work in

   [2] C. Q. Shen, "Mobility Extensions to RSVP in an RSVP-Mobile
   IPv6 Framework," draft-shen-nsis-rsvp-mobileipv6-00.txt , July 2002.
   Work in Progress.

   [3] R. Hancock, "Next Steps in Signaling: A Framework
   Proposal," draft-hancock-nsis-fw-00.txt , June 2002.  Work in

   [4] C. Westphal and H. Chaskar, "QoS Signaling Framework for Mobile
   IP," draft-westphal-nsis-qos-mobileip-00.txt , June 2002.  Work in

   [5] J. Rajahalme et. al., "IPv6 Flow Label Specification," draft-
   ietf-ipv6-flow-label-02.txt , June 2002.  Work in Progress.

   [6] C. Williams, "Localized Mobility Management Requirements,"
   draft-ietf-mobileip-lmm-requirements-02.txt , June 2002.  Work in

   [7] R. Braden and B. Lindell, "A Two-Level Architecture for Internet
   Signaling," draft-braden-2level-signal-arch-00.txt , November 2001.
   Work in Progress.

   [8] H. Chaskar and R. Koodli, "A Framework for QoS Support in Mobile
   IPv6," draft-chaskar-mobileip-qos-01.txt , March 2001.  Work in

   [9] X. Fu and et al., "QoS-Conditionalized Binding Update in Mobile
   IPv6," draft-tkn-nsis-qosbinding-mipv6-00.txt , January 2002.  Work
   in Progress.

   [10] Z. Kan, "Two-plane and Three-tier QoS Framework for Mobile IPv6
   Networks," draft-kan-qos-framework-00.txt , April 2002.  Work in

Charles Qi Shen                                               [Page 7]

Internet Draft       NSIS Mobility Framework Issues        July 12, 2002

7 Authors' addresses

   Charles Qi Shen
   Institute for Communications Research (ICR)
   20 Science Park Road
   #02-34/37, TeleTech Park
   Singapore Science Park II
   Singapore 117674
   Phone: +65 6870-9358

8 Full Copyright Statement

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

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. This
   document and the information contained herein is provided on an "AS

                           Table of Contents

   1          Abstract ............................................    1
   2          Introduction ........................................    1
   3          Issues about Handoff Impact on NSIS Protocol
   Operation ......................................................    2

Charles Qi Shen                                               [Page 8]

Internet Draft       NSIS Mobility Framework Issues        July 12, 2002

   3.1        The Need for a Separate View on Data and Control
   Plane Identifiers ..............................................    2
   3.2        Handoff Problem Statement and Basic Requirements ....    2
   3.3        Evaluation of Existing Framework Proposals using
   Mobile IP Against Requirements .................................    3
   3.3.1      Approach I ..........................................    3
   3.3.2      Approach II .........................................    4
   3.3.3      Approach III ........................................    4
   3.3.4      Summary Notes .......................................    4
   3.4        Evaluation with Other Possible Mobility Mechanisms
   Against Requirements ...........................................    5
   4          Issues on Signaling Layering Between NSIS and
   Mobility .......................................................    5
   5          Issue on Soft-State Management in NSIS and
   Mobility Interaction ...........................................    6
   6          Bibliography ........................................    7
   7          Authors' addresses ..................................    8
   8          Full Copyright Statement ............................    8

Charles Qi Shen                                               [Page 9]