Internet Engineering Task Force NSIS Internet Draft X. Fu, H. Schulzrinne, H. Tschofenig U. Goettingen/Columbia U./Siemens draft-fu-nsis-mobility-00.txt 23 June 2003 Expires: December 2003 Mobility Support in NSIS 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract Mobility support was one of the shortcommings of RSVP and a number of proposals have been made in the past to improve various features. This document attempts to determine what the expected functionality is, how various problems can be solved and what implications are caused by certain design decisions. X. Fu et. al. [Page 1] Internet Draft NSIS Mobility 23 June 2003 1 Introduction The NSIS working group is currently working on the two-layer architec- ture with a generic NTLP protocol and various NSLP applications (e.g. QoS and NAT/Firewall traversal). The NSIS Framework [1] describes the functionality of the individual layers in detail. Mobility support is one of the items on a list of desired features for future QoS signaling protocols. Unfortunately, mobility support for a generic signaling protocol still causes a lot of confusion. To start the discussion in the working group the expected functionality has to be discussed and the implications for the protocol design evaluated. A recently published MIP QoS requirements document [2] lists some of the requirements. Interactions of RSVP signaling with Mobile IP have previously been investigated, e.g., in [3,4]. In RSVP, as signaling sessions are identi- fied by IP addresses, it becomes difficult to address host mobility net- works [5,6]. When a mobile node (MN) moves, the state established along the previous route remains until it times out after multiples of the soft-state interval, typically after more than a minute. With even mod- est mobility, large amounts of "obsoleted" state may cause inefficient resource allocation. In addition, IP-in-IP encapsulation in Mobile IP (MIP) causes RSVP messages sent to the MN also be encapsulated as mes- sages with a new protocol number in its outer header, thus concealed to the RSVP nodes along the path and unable to perform signaling tasks cor- rectly. This document attempts to determine what the expected functionality is, how various problems can be solved and what implications are caused by certain design decisions, to deal with mobility support in NSIS. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. In addition, this document frequently uses the following terms or abbre- viations most of which are defined in Mobile IP, SEAMOBY and NSIS related documents: Home Address (HoA) Home Agent (HA) Foreign Agent (FA) X. Fu et. al. [Page 2] Internet Draft NSIS Mobility 23 June 2003 Care-of-Address (CoA) Correspondent Node (CN) Mobile Node (MN) Access Router (AR) Mobile IP (MIP):Mobile IPv4 (MIPv4) or Mobile IPv6 (MIPv6) Hierarchical Mobile IPv6 (HMIPv6) Fast Handovers: proposals for fast handover enhancements to MIP, such as Fast Handovers for Mobile IPv6 (FMIPv6) and Low latency Handoffs in Mobile IPv4. Localized Mobilitiy Management (LMM): micro-mobility proposals such as HMIPv6 and Mobile IPv4 Regional Registration. Regional Care-of-Address (RCoA) On-Link Care-of-Address (LCoA) Mobility Anchor Point (MAP) Gateway Foreign Agent (GFA) Standard routing: standard IP packets without routing header or IP- in-IP encapsulation are routed according to the destination address field in the IP header Normal routing / direct routing: routing data packets with routing header (kind of "source routing") or standard routing, i.e., without using (mobility related) tunnels. Routing with Mobile IP tunnels: packets with IP-in-IP encapsulation are routed according to the destination address field in the outer header. These packets are encapsulated at the entry of a Mobile IP tunnel and decapsulated at the exit of a Mobile IP tunnel. Next Steps in Signaling (NSIS) NSIS Entity (NE) NSIS Transport-Layer Protocol (NTLP) X. Fu et. al. [Page 3] Internet Draft NSIS Mobility 23 June 2003 NSIS Signaling-Layer Protocol (NSLP) Peer discovery Cross-over Router (CR):the NSIS-aware node which is the nearest to the MN but locates in the common path where new and old paths converge after a handoff. 3 Mobility Support in NSIS: Problem Statement Efforts like [8,9,10,3,1,11] have been made to analyse mobility issues in this area and result in some interesting discussions. What has not emerged is a consensus for defining what problems would be expected, what functionalities need to be contained in NSIS to tackle mobility support and how various problems can be solved. This section attempts to make a summary of problems and next section discusses possible solu- tions. In the past the following issues with mobility support in NSIS have been discovered: Issue 1 - Indexing state information: If state information, which is stored at routers along the path, is indexed based on the Care of Address (CoA) then it is unaccessible after most handover procedures. With the handover procedure the mobile node obtains a new Care of Address. Issue 2 - Double Reservation: State information should not be established twice between the cross-over router (CR) and the CN. Issue 3 - State Update: Updating state information along the entire path might be nec- essary, for example, due to the selection of the flow identi- fier. If an application uses the IPv6 Flow Label (3-tuple) for the flow identifier then end host mobility requires updating the flow identitifer along the entire path. Issue 4 - Keeping Signaling Local: End-to-end signaling is typically expensive. In some cases it might be desireable to keep signaling messages local. This might require to either add a "local only" flag (or something like scoping) or to have the cross-over router (or the MAP) to decide by itself whether to stop signaling or to forward the X. Fu et. al. [Page 4] Internet Draft NSIS Mobility 23 June 2003 signaling message to the corresponding node. Issue 5 - Sender-Initiated Reservations: Sender-initiated reservations seem to be more efficient in mobile environments. Until now, the NSIS working group has not yet discussed which approach (sender- or receiver-initiated reservations; or even both) should be supported by a future signaling protocol. In some cases receiver-initiated reserva- tions are better (e.g. Firewall/NAT traversal) whereas in other cases it might even be required to have more than one roundtrip (e.g. when price distribution has to be considered). Issue 6 - Partial State Release: It might be desireable to delete previously established state on the "obsoleted" path (i.e. along the path between the cross-over router and the old access router). In mobility sce- narios it is desireable to delete these states as soon as pos- sible, particularly for fast mobility. Soft-state timeouts might be too inefficient. 3.1 Synchronization Issues Issue 7 - Synchronziation Problems: Partial state release might cause synchronization problems or race conditions in some cases. For example, if an MN moves rapidly from one AR0 to another AR1 afterwards to a third AR2, local repair messages may be initiated along AR1 and AR2 sub- sequently, but the message along AR1 may arrive later than that along AR2. As illustrated in Fig. 1, this may cause the states be incorrectly updated (step 7 in CR) and released (step 8 in AR2). Another example of this problem is a ping-pong effect where a mobile node switches between two neighboring ARs, possibly causing states be released or updated incorrectly. 3.2 Tunnel Issues In addition to direct routing between a mobile node (MN) and the corre- sponding node (CN), Mobile IP and various local mobility management (LMM) [12,13,14] and fast handoff [15,16] schemes may add one or more IP-in-IP encapsulation tunnel(s) between the home agent (HA) and the corresponding node (CN), as summarized in the appendix. Thus, data pack- ets may take one of several possible routes: X. Fu et. al. [Page 5] Internet Draft NSIS Mobility 23 June 2003 +-------+ | AR0 | / +-------+ +------+ / \ 5teardown *| CN | / \ * +------+ / \ * /1refresh+-------+ 6refresh\ +--------+ * | ---> | AR1 |------------- + CR |4,7update \ +-------+ +--------+ \ / refresh(AR2) is initiated \ / later than refresh(AR1), but +-----+ \ 2refresh 8teardown/ can arrive at CR earlier. | MN | \ / +-----+ _\/ +---------+ / 3refresh | AR2 | +---------+ Figure 1: Fast Movement Issue: an Example · For data packets from the MN towards the CN: 1a) direct routing, or 1b) (in case of reverse tunnel [17,6]) reverse tunnel segment from the MN to the HA plus a direct routing segment from the HA to the CN. · For data packets from the CN towards the MN: 2a) optimized path from CN to MN (using routing header through the CoA); 2b) non-optimized path which consists of a normal routing segment from CN to HA and another tunnel segment from HA to FA/MN; 2c) for LMM schemes, GFA/MAP divides the tunnel segment from HA to FA/MN in 2b) into two segments, a tunnel from HA to GFA/MAP plus another tunnel from GFA/MAP to FA/MAP; 2d) for fast handover schemes [15,16], an additional tunnel is inserted in 2b): the tunnel between old and new access routers. X. Fu et. al. [Page 6] Internet Draft NSIS Mobility 23 June 2003 For (2c) and (2d) the exit of a tunnel is immediately the entry of next tunnel. IP-in-IP encapsulation in Mobile IP, for example in (1b), (2b), (2c) and (2d), causes each signaling message in end-to-end addressing schemes like RSVP to be encapsulated inside a tunnel message. The tunnel hides the RSVP message and make intermediate nodes between the tunnel entry and the tunnel exit invisible. The following issues can be identified for the interworking between Mobile IP and NSIS: Issue 8 - Non-Unaware NSIS Tunnel Endpoints: If the two end points of a tunnel do not support NSIS then it is impossible to provide signaling services for any NSIS node inside the tunnel. In order to (for example) make a QoS reser- vation for tunnels, it is necessary to have the tunnel end points to support NSIS. Issue 9 - Selective Tunnel Reservations: When an application triggers a per-flow QoS reservation then in some cases it is desired to trigger a QoS reservation also for the tunnel. In some cases it is, however, not desireable to support a QoS reservation for a tunnel. It must therefore be possible for NSIS to decide whether a reservation for a tunnel is desired. An end-to-end reservation must not automat- ically be extended to the tunnel since the tunnel might also serve as a means for aggreagation. Issue 10 - Discovery Procedure: As previously stated NSIS signaling messages are hidden inside a tunnel. It is therefore necessary to trigger a separate dis- cover and signaling message exchange for the tunneled region. The signaling messages must either be prevented to "enter" the tunnel, need to experience special treatment after encapsula- tion or require different addressing (i.e. addressing the tun- neled reservation towards the tunnel exit). 3.3 NSLP/NTLP Interaction Issue Issue 11 - NSLP/NTLP Interworking: The NTLP should be able to notify the NSLP to update state (by initializing NSLP refresh/teardown messages appropriately). An open issue is, however, how and what information the NSLP can X. Fu et. al. [Page 7] Internet Draft NSIS Mobility 23 June 2003 expect from NTLP, or directly from the routing interface. 3.4 Routing Interface Issue Issue 12 - NSIS/Routing API: Mobility reflects different route change (due to changes in the binding cache, for example in HA, CN, FA/MN, GFA/MAP) or due to creating, updating or delet- ing tunnels. An API is required for the communication between the operating system and the NSIS daemon, upon which NSIS is able to trigger the necessary action. 4 Possible Solutions To deal with the issues summarized in Section 3, we describe some possi- ble approaches to address them. 4.1 NTLP and Discovery First, issues 1-2 can be resolved by a unique session identifier inde- pendent on flow identifier (which reflects the traffic information), to index the state information. When the MN moves, the NTLP only changes the flow identifier of the session, without changing the session identi- fier. This change takes place when an NTLP node detects the introduction or release of MIP tunnels or simply a route change in the MN or the CN. Then it triggers the next-hop discovery mechanism to determine the new next signaling node and updates its information in the NTLP state according to the unique session identifier. Issue 3 -- releasing of existing state in the old path, by default, can be achieved by the state timer expiration. However, as the state timer is relatively long, keeping state in these nodes may be inefficient. Alternatively, we propose to use local explicit teardown messages. A reasonable place for initiating such a teardown message is the cross- over router (CR), i.e., the node where the old and new paths merge after a route has changed. To help the release of the obsoleted states and determine the behavior of the cross-over router, we further introduce a next-hop branch identifier. Once a new next NSIS node is determined, the NTLP state in the current associates it with a new next-hop branch iden- tifier (to represent the new branch). Then a refresh message is sent through the new branch to establish the necessary states, until the cross-over router with a same NTLP session state is reached. After that a teardown message assigned with the old branch identifier can be sent reversely towards another end point and terminated by finding a differ- ent branch identifier for the same session state. To reflect the change of flow identifier for NTLP sessions, it is also necessary to refresh the common path (e.g., the path between the CR and the HA, or between the CN and the HA). This needs to differentiate from X. Fu et. al. [Page 8] Internet Draft NSIS Mobility 23 June 2003 the CN as data source to the MN as data source. · For the MN as data source: the route change in the MN triggers a refresh towards the CN. A refresh is then sent along the newly- discovered branch towards the CN; after the CR is determined, the CR sends a teardown along the reverse path of last-recently-used branch, and the refresh is forwarded on toward the CN. · For the CN as data source: the route change in the CN (in route optimization case), the HA or the GFA/MAP/... (other cases -- typically a tunnel segment is created or modified and thus causes a route change in such nodes for the path from the CN to the MN) triggers a refresh towards the MN. The state in first segment (between the route change point to the CR) is refreshed with the updated flow identifier; then a local repair takes place from CR: a refresh is sent along the newly-discovered branch and a tear- down is sent along the last-recently-used branch. There are additionally two issues with this local repair process. First, a teardown message arriving at MN (along the obsoleted branch), if arrives earlier than the refresh message (along the new branch), can incorrectly make a decision to release the state in the MN. There are two possible solutions: 1) only allow the MN to initiate the release of states in the obsoleted branch, but this solution does not work if the MN looses its connection to the old AR at all; or 2) still let CR to initiate release, but mandate the MN not to remove state upon an earlier-arrived tear- down message; or 3) let CR to initiate release after a period of time (e.g., an RTT) after initiating the refresh in the new branch. Our suggestion is 2), as it neither potentially remains "orphan" states nor introduces additional states in the routers. Second issue concerns with delivery of teardown messages. In case of peer-to-peer addressing of NSIS signaling messages, the above description works. However, in case of end-to-end addressing of NSIS signaling messages, default routing in the CR may cause the teardown messages to follow the same path as the refresh messages traverse (i.e., in the new path), however these teardown messages need to be sent through the obsoleted branch. One solution is to specify the logical outgoing interface -- logical interface han- dle (LIH), same as in RSVP [18] -- for each branch and use it for message delivery. To deal with issue 7 requires effective sequencing of branches. Our pro- posal is to let the CR always assign a next branch id different from the current branch id. A refresh with an existing session identifier will cause a state update (and accordingly cause a release) only when the branch identifier in the refresh is larger than that in the current X. Fu et. al. [Page 9] Internet Draft NSIS Mobility 23 June 2003 state. Issue 8 can be resolved by mandatory NTLP support in the tunnel end points, as well as the CN and the MN. When an NSIS node detects the introduction of an MIP tunnel, if signaling into the tunnel is desired, it can issue a discovery towards the tunnel exit, not to the destination address of the end-to-end reservation. For the NSIS node inside the tun- nel, it can do that in the same way. Issue 11 and issue 12 require API functionality within NSIS and the operating system (notification of mobility route change, etc.). Issues 4-6, 8-9 and 10 are covered/resolved while presenting themselves or discussing other issues. Additionally, issue 5 requires to perform reverse signaling during the local repair for receiver-initiated signal- ing services. In the example in Fig. 2, an MN acting as the data sender communicates with a CN. When it changes its AR to that of a new network, it is asso- ciated with a new CoA (nCoA) and the flow identifier in the signaling message is changed. The session identifier, however, remains intact so that only a single state is held in the NSIS nodes along the path from the CR to the CN. After the CR is determined, it can issue a teardown message to release states towards the MN along the reverse path that former signaling messages traverse. Note the refresh messages arriving at the CR will be forwarded on towards the signaling target, to refresh existing states to reflect the change in flow identifier. Fig. 3 illustrates an example for CN as a data source. 4.2 NSLP and NTLP/NSLP Interactions The creation, update or removal of NTLP state also triggers associated NSLP entity(ies) to create, update or release related NSLP state accord- ingly. For example, before sending an NTLP refresh, the NTLP entity can trigger QoS NSLP and let the latter to request a Reserve refresh message toward the QoS NSLP target address. However, not all NSLP functionali- ties can be supported. For example, it may be impossible/unnecessary to request NSLP response upon the receipt of the NSLP teardown message in the NSLP responder, as the NTLP state along the path has been already released. In general, upon a NTLP notification, the NSLP should decide by its own which its next behavior is. (Issue 11) 4.3 Routing Interface X. Fu et. al. [Page 10] Internet Draft NSIS Mobility 23 June 2003 +----+ +----+ /\ ----|AR0 |----| R |--- \ / +----+ +----+ \ \teardown / \ \(Branch_id=2) / Branch_id=0 \ \ +----+ +----+ +----+ | MN | (Branch_id=2)| CR |-----| CN | +----+ teardown/ +----+ +----+ \ Branch_id=1 V / / \ \ +----+ +----+ / / \ ----|AR1 |----| R |--- / \ +----+ +----+ / Branch_id\=2 +----+ / ----|AR2 |------------- +----+ Figure 2: Local Repair Proposal +----+ +----+ /\ ----|AR0 |----| R |--- \ / +----+ +----+ \ \Teardown / \ \(Branch_id=1) / Branch_id=0 \ \ +----+ +----+ +----+ | MN | | CR |-----| CN | +----+ +----+ +----+ \ Branch_id=1 / <--- \ +----+ +----+ /Refresh ----|AR1 |----| R |--- +----+ +----+ Figure 3: Local Repair case with CN as data sender There are two approaches for NSIS to interact with routing (issue 12). One is API, upon which NSIS can query the mobility routing status. X. Fu et. al. [Page 11] Internet Draft NSIS Mobility 23 June 2003 Another is to provide route change notification to NSIS whenever a mobility route change happens (e.g., binding cache changes). As the first approach typically introduces some delay in state management per handoff, we suggest the notification (active) way. This can also sim- plify the trigger design when the NTLP refresh timer is different from the timer for binding management. The natural interface for NSIS to access routing interface would be in the NTLP. 4.4 Operation of Proposed Mobility Support Mechanisms What we eventually need to support mobility in NSIS might be: - a mobility module (to determine state index, decide which is the CR and do local repair) co-located with NTLP. - a mobility tunnel-aware module co-located with NSIS peer discovery. - a mobility object/field in NTLP header to indicate branch-id and/or scope. - logical interface handles (LIH) in addition to PHOP and NHOP in the NTLP state. - a mobility route change notification interface in mobility-aware nodes. A pseudocode for proposed solution for mobility support in NSIS is described in Fig. 4. 5 Security Considerations The introduction of the session identifier to tackle some mobility related issues has security implications which are described in [19]. Some questions raised in this context may deserve discussions within the NSIS working group. 6 Open Issues · End-to-end addressing v.s. peer-to-peer addressing of NSIS sig- naling messages; · Message format and routing interface definition; · An Obsoleted_Branch_Removal flag for deciding whether to remove actively states in the obsoleted branch; · Interworking with Context Transfer. X. Fu et. al. [Page 12] Internet Draft NSIS Mobility 23 June 2003 IF(a node detects a mobility route change)/*MN,CN,HA or FA/MAP/GFA/...*/ flow_id = (nCoA, CN, ...); next_hop = discovery(dest); /* if the node is a tunnel entry or inside a tunnel, dest is the tunnel exit; otherwise dest is normal dest */ IF(next_hop != old_next_hop) /* this is a new branch */ branch_id = (branch_id + 1) % MAX_VAL; creat_state(&state,branch_id,flow_id,session_id,...); ELSE /*update the existing state with the new flow_id */ update(&state(session_id), flow_id); ENDIF /* send a refresh, local repair if it is a new branch */ mesg = new_msg (''refresh'', branch_id, flow_id, session_id,...); send_msg(&mesg); ENDIF /* Determine the cross-over router */ IF(a node gets a msg with t_flag == 0) IF(session_id(msg) == session_id(state)) /* decide whether to update branch_id */ IF(branch_id(msg) >= (branch_id(state)+1) % MAX_VAL) branch_oid = branch_id(state); update(&state(session_id), branch_id(msg)); ENDIF /* then send a teardown mesg in the old path */ mesg=new_msg(``teardown'', branch_oid, flow_id, session_id,...); send_msg(&mesg); /* send the teardown mesg along old path */ forward_msg(&msg); /* forward refresh mesg on */ ELSE /* it is not the cross-over router */ IF(session_id(msg) does not exit in local state) create(&state(session_id, flow_id(&msg))); ELSE update(&state(session_id), flow_id(&msg)); ENDIF forward_msg(&msg); ENDIF ENDIF /* Determine the end of teardown msg */ IF(a node gets a teardown msg) IF(branch_id(&msg) > branch_id(&state)) remove(&state); forward_msg(&msg); ENDIF /*else stop here, don't forward on the teardown msg*/ ENDIF Figure 4: Pseudocode for proposed mobility support in NSIS X. Fu et. al. [Page 13] Internet Draft NSIS Mobility 23 June 2003 7 Acknowledgment The authors would like to acknowledge discussions with Rene Soltwisch, Robert Hancock, Andrew McDonald, Hemant Chaskar and other members of the NSIS working group for numerous discussions on various aspects of this topic. 8 Authors' Addresses Xiaoming Fu Institute for Informatics University of Goettingen Lotzestr. 16-18 37083 Goettingen Germany EMail: fu@cs.uni-goettingen.de Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA EMail: hgs@cs.columbia.edu Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany EMail: Hannes.Tschofenig@siemens.com Appendix -- Data Flows under Different IP Mobility Schemes We summarize possible data flows under different IPv6 mobilitiy schemes as Figures 5-10 (note we are not discussing about mobility management messages flows; IPv4 is quite similar and not presented here). They can be further summarized into two cases: - Fully IPv6 normal routing, or - A normal routing segment + one or more IP-in-IP tunnel(s) X. Fu et. al. [Page 14] Internet Draft NSIS Mobility 23 June 2003 The implications is we need to take special care to tunnel segment. If the NSIS NTLP follows similar concept in CASP, i.e., NTLP messages are addressed in a peer-to-peer way, the concern regarding tunnels becomes: 1) how to address&deliver discovery messages in tunnel entry points, 2) whether to signal into tunnels (if so, again how to address discovery messages). Some other implications behind: - For fully IPv6 normal routing, the cross-over router can be located anywhere between MN and CN; - For routing with tunnel segment, the cross-over router can only be located somewhere between the HA (a tunnel entry) and the CN (for fast/hierarchical mobility, could be in a small segment between HA and CN). This further implicates, if we want to do local repair in such case, we need to signal into the tunnel; also, tunnel end points are therefore needed to support NSIS. MN CN | | |IPv6+HomeAdressOpt | |--------------------------------->| | | Figure 5: MIPv6: MN-->CN, no reverse tunnel 9 Bibliography [1] R. Hancock 4met24m 4mal.24m, "Next steps in signaling: Framework." Internet Draft, work in progress, Nov. 2002. X. Fu et. al. [Page 15] Internet Draft NSIS Mobility 23 June 2003 MN CN |IPv6(tunnel)| | |----------->| IPv6(normal) | | |--------------------->| | | | Figure 6: MIPv6: MN-->CN, with reverse tunnel CN MN | | |MIPv6(RH) | |--------------------------------->| | | Figure 7: MIPv6: CN-->MN, route optimization CN HA MIPv6(RH) MN | |-------------------->| |IPv6(normal)| | |----------->| | | | MIPv6(tunnel) | | |-------------------->| | | | Figure 8: MIPv6: CN-->MN, no route optimization [2] H. Chaskar, "Requirements of a qos solution for mobile ip," 2003. Work in progress. X. Fu et. al. [Page 16] Internet Draft NSIS Mobility 23 June 2003 CN HA MAP nAR(MN) | | | | | IPv6 | | | |---------->| | | | (normal) | | | | | MIPv6 | | | |----------->| | | | (tunnel) | | | | |HMIPv6 | | | |-------->| | | |(tunnel) | Figure 9: HMIPv6: CN-->MN, no route optimization CN pAR nAR MN | | | | |MIPv6(normal-HA-tunnel) | | |----------------------->| | | | | | | | FMIPv6 | | | |<-----------| | | | (tunnel) | | | | FMIPv6 (tunnel) | | |---------------------->| | | | | Figure 10: FMIPv6: CN-->MN, no route optimization [3] M. Thomas, "Analysis of mobile ip and rsvp interactions," Internet Draft, Internet Engineering Task Force, 2002. Work in progress. [4] J. Manner et al., "Localized RSVP." Internet Draft, work in progress, May 2002. [5] C. Perkins, "Ip mobility support for ipv4," 2002. Work in progress. X. Fu et. al. [Page 17] Internet Draft NSIS Mobility 23 June 2003 [6] D. Johnson, C. Perkins, and J. Arkko, "Mobility support in IPv6," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [7] S. Bradner, "Key words for use in RFCs to indicate requirement lev- els," RFC 2119, Internet Engineering Task Force, Mar. 1997. [8] C. Westphal and H. Chaskar, "Qos signaling framework for mobile IP," Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. [9] C. Shen et al., "Mobility extensions to RSVP in an RSVP-mobile IPv6 framework," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [10] H. Schuzrinne, H. Tschofenig, X. Fu, J. Eisl, and R. Hancock, "Casp -- cross-application signaling protocol." Internet draft, work in progress, Sept. 2002. [11] M. Brunner, "Requirements for QoS signaling protocols." Internet Draft, work in progress, July 2002. [12] C. Williams, "Localized mobility management requirements," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [13] H. Soliman, C. Castelluccia, K. Malki, and L. Bellier, "Hierarchi- cal MIPv6 mobility management (HMIPv6)," Internet Draft, Internet Engi- neering Task Force, July 2002. Work in progress. [14] E. Gustafsson, A. Jonsson, and C. Perkins, "Mobile IPv4 regional registration," Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in progress. [15] G. Dommety, A. Yegin, C. Perkins, G. Tsirtsis, K. Malki, and M. Khalil, "Fast handovers for mobile IPv6," Internet Draft, Internet Engi- neering Task Force, Mar. 2002. Work in progress. [16] K. Malki et al., "Low latency handoffs in mobile IPv4," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [17] G. Montenegro and Ed, "Reverse tunneling for mobile IP, revised," RFC 3024, Internet Engineering Task Force, Jan. 2001. [18] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource reservation protocol (rsvp) -- version 1 functional specification." RFC 2205, Sept. 1997. X. Fu et. al. [Page 18] Internet Draft NSIS Mobility 23 June 2003 [19] H. Tschofenig, H. Schulzrinne, et al., "Security implications of the session identifier," internet draft, Internet Engieering Task Force, June 2003. work in progress. X. Fu et. al. [Page 19] Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 3 Mobility Support in NSIS: Problem Statement . . . . . . . 4 3.1 Synchronization Issues . . . . . . . . . . . . . . . . . 5 3.2 Tunnel Issues . . . . . . . . . . . . . . . . . . . . . . 5 3.3 NSLP/NTLP Interaction Issue . . . . . . . . . . . . . . . 7 3.4 Routing Interface Issue . . . . . . . . . . . . . . . . . 8 4 Possible Solutions . . . . . . . . . . . . . . . . . . . 8 4.1 NTLP and Discovery . . . . . . . . . . . . . . . . . . . 8 4.2 NSLP and NTLP/NSLP Interactions . . . . . . . . . . . . . 10 4.3 Routing Interface . . . . . . . . . . . . . . . . . . . . 10 4.4 Operation of Proposed Mobility Support Mechanisms . . . . 12 5 Security Considerations . . . . . . . . . . . . . . . . . 12 6 Open Issues . . . . . . . . . . . . . . . . . . . . . . . 12 7 Acknowledgment . . . . . . . . . . . . . . . . . . . . . 14 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . 14 9 Bibliography . . . . . . . . . . . . . . . . . . . . . . 15 X. Fu et. al. [Page 1]