Internet Engineering Task Force Charles Qi Shen Internet Draft ICR draft-shen-nsis-mobility-fw-00.txt July 12, 2002 Expires: January 2003 Several Framework Issues Regarding NSIS and Mobility STATUS OF THIS MEMO 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". To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. 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 planes: o Data Plane: it is used by packet classification mechanism for filtering the data packets that are entitled to the reserved resources. 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 Requirements 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 Requirements 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 situation. 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 applicable. 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 Progress. [2] C. Q. Shen et.al., "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 et.al., "Next Steps in Signaling: A Framework Proposal," draft-hancock-nsis-fw-00.txt , June 2002. Work in Progress. [4] C. Westphal and H. Chaskar, "QoS Signaling Framework for Mobile IP," draft-westphal-nsis-qos-mobileip-00.txt , June 2002. Work in Progress. [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 Progress. [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 Progress. [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 Progress. 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 Email: shenqi@icr.a-star.edu.sg 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 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. 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]