Applicability Statement of NSIS Protocols in Mobile Environments (draft-ietf-nsis-applicability-mobility-signaling-00) Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tshofenig, Xiaoming Fu, Jukka Manner The 61 st IETF Meeting Nov. 8, 2004

Introduction The goals of this draft are to present the effects of mobility on the GIMPS and on the NSLP. This draft discusses the operation of the NSIS protocols in very basic mobility scenarios (e.g., macro-mobility management protocols such as Mobile IPv4 and Mobile IPv6), including support for multi-homing. More complex scenarios and issues of interworking with various mobility-related protocols, such as Seamoby, local mobility management protocols, NEMO, and so on, are left for future work.

Overview Basic Operations for Mobility Support –Generic route changes vs. mobility –CRN discovery –Path update Mobility-Related Issues with NSIS Protocols –Specific issues with NTLP (GIMPS) –Specific issues with QoS-NSLP –Specific issues with NAT/FW NSLP –Common issues related to NTLP and NSLP Applicability Statement –Support for macro mobility-based scenarios –Multihoming scenarios –QoS performance considerations in mobility scenarios –Use cases of identifiers –Peer failure scenarios Security Considerations

Some Identified Issues (I) According to signaling states, flow direction, and the cause of route changes (e.g., generic route changes or mobility) –There are some different types of Crossover node (CRN), –There are also some differences in CRN discovery –The operations for Path update (or Local repair) are different –Note that it is more appropriate to discover CRN at GIMPS level than at NSLP level

Some Identified Issues (II) According to the characteristics of mobility or macro- mobility management –The Path Update may lead to the signaling overhead and latency. –The immediate removal of state along the old path may not be appropriate for some mobility situations, such as the fast handover of a ping-pong type. –When NR is a mobile node, the last node detection problem occurs; it is called “Invalid NR problem” –NSIS needs to have an interface with mobility management protocols (e.g., Mobile IP) to immediately react to a mobility event. –NSIS signaling needs to interact with IP tunneling to also update the state along the tunneling segment between HA to MN (or FA). –In multi-homed MN scenarios, multiple CoAs for the MN can be used to establish NSIS state between the MN and CN by selecting an appropriate path (e.g., load balancing, load sharing, etc.).

Changes from the previous version Open issues section was removed. –We will focus on interaction with NSIS and basic macro-mobility management protocols in this draft rather than advanced features- related issues (e.g., Seamoby, micro-mobility management protocols, NEMO and so on) Multi-homing scenarios section was updated –Load sharing or -balancing, and recovery-related issues have been discussed. –Anticipated handover-related issues were removed Appendix section was deleted –Anticipated handover-related issues were removed

Open issues The following issues are still open: –Whether the teardown message can be sent toward the opposite direction to the state initiating node –Which information does the NTLP detect the movement based on? –How is refresh time set up in the situation of frequent handover? –How does CRN safely remove the state along the old path after the establishment of state along a new path? –How and what information can the NSLP expect from NTLP, or directly from the routing interface after mobility? –How to coordinate the mobility binding update interval and NSIS signaling interval? –When to remove the tunneling segment and/or how to tear it down through the interworking with the IP-tunneling

Next Steps As mentioned in the 60 th IETF meeting, –Consolidate the list of open issues (done) –Define design choices for the NSIS protocols –Evaluate the design choices –Find answers and make a decision before protocols are frozen

Thank you for your attention! Please give comments on the draft in the NSIS mailing list.