1. Applicability Statement of NSIS Protocols in Mobile Environments (draft-ietf-nsis-applicability-mobility-signaling-03) Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner The 64th IETF meeting in Vancouver, Canada Nov. 9, 2005

2. The 64 th IETF Vancouver Meeting Status of –03 version (I) Issues closed since the Munich interim meeting (May, 2005). –#4: Authorization-related issues with teardown solved by disabling of “reverse removal” –#7: Priority of signaling messages Can not be used due to security issues –#1: CRN discovery Discovery mechanisms on CRN is more efficient at NTLP (GIST) than NSLP layer. –#12: Terminology: Path Update State Update was preferred. Remaining issues to be resolved: –#2: Mobile IP specific API Implementation-specific between Mobile IP and NSIS, but the usage of an API between GIST and NSLP needs to be described. –#3: Invalid NSIS Responder problem Some possible proposals to solve the 'invalid NR' problem in mobility scenarios was described (e.g., Mobility Object: handover_init (HI)).

3. Nov. 9, 2005The 64 th IETF Vancouver Meeting Status of –03 version (II) Remaining issues to be resolved (cont.): –#5: Optimal refresh timer value for mobile environment Difficult to provide a generic mechanism. Give guidelines: offer detailed values (for specific scenarios) –#6: CRN discovery and State Update on the IP-tunneling path Described possible scenarios based on draft-shen-nsis-tunnel-01. Flow (IDs) management issues. –#8: Localized State Update Identify the difference b/w the local mobility and micro mobility management protocols in case of interaction with NSIS protocols Consider signaling optimization in the vertical handover scenarios. –#9: Dead Peer Discovery Pertinent to ‘#3: Invalid NR problem’ –#10: Multihoming-related issues Updated based on draft-lee-nsis-multihoming-mobility-00. –#11: Mobility object Pertinent to #1 and #3 for correct operation.

4. Nov. 9, 2005The 64 th IETF Vancouver Meeting Open issue #9: Dead Peer Discovery Issues: –Dead peers (e.g., AR (or FA), CRN, HA, CN or MN ) can occur because either a link or a network node failed, or MN moved away without informing NTLP/NSLP (e.g., QoS- or NAT/FW-NSLP). –GIST may detect the problems after some time: it says that GIST discovery might be slow (?). Question: –How can dead peers be detected in a fast and efficient manner in mobility scenarios? Or, GIST discovery? –Do some “dead peer” cases need to be identified in more details? e.g., MN’ moving-away, CRN failure, CARs’ failure, FA/HA’s failure, and so on.

5. Nov. 9, 2005The 64 th IETF Vancouver Meeting Open issue #10 Multihoming-related issues Issues: –An NSIS-aware node (e.g., MN, HA, CN, etc.) may be multihomed. NSIS signaling can be used in such multihomed environments. –In this case, which NxLP functionality is needed in various multihoming scenarios (e.g., bandwidth increase, load balancing, bi-casting, resilience, etc.) is an open question. –Based on draft-lee-nsis-multihoming-mobility-00. Question: –Which of CRNs is the most appropriate node to do the State Update? –How should multiple CRNs differentiate the State Update for multihoming from the generic State Update? –How do NSIS-aware nodes (e.g., CRNs) authorize multiple flows with different flow identifiers for the same session?

6. Nov. 9, 2005The 64 th IETF Vancouver Meeting Open issue #11 Mobility Object Description: –The Mobility objects such as ‘Mobility_Event_Counter (MEC)’ and ‘Handover_Init (HI)’ can be used to solve ‘the fast or ping-pong type’ handover and the Invalid NR problem, respectively. The MEC field can inform the CRN of which incoming message is the latest. The HI field can explicitly inform AR (or CRN) that a handover is now initiated. –QoS-NSLP flag (e.g., NO_REPLACE flag) may be helpful for a ping- pong type handover because of preventing state on the old path from being torn down. Question: –Do those mobility objects need to be included in NxLP messages? –Which primitives need to be used in order for NTLP (GIST) to notify QoS-NSLP of the mobility events?

7. Nov. 9, 2005The 64 th IETF Vancouver Meeting Status of –03 version (III) Some overlapped issues between QoS-NSLP and NSIS- mobility drafts –#29: Make-before-break handovers (including Seamoby-related issues) -> closed Addressed at the initial NSIS-mobility draft but closed. –#33: Priority of signaling messages to GIMPS-NSLP API & #39 Explicit indication of refresh -> closed Related to the “priority of signaling messages (#7)” –#32: Last node problem Similar to the “Invalid NR problem (#3)” –#17: Node failure and restart handling “Dead peer discovery (#9)” How should we resolve the conflict? Who describes what?

8. Nov. 9, 2005The 64 th IETF Vancouver Meeting Next steps Resolve the open issues. Identify and further clarify the following issues. –Localized signaling issues –The security-related issues If open issues and problems are detected  give guidance to protocol authors (before protocols are frozen).

9. Nov. 9, 2005The 64 th IETF Vancouver Meeting NSIS-mobility Issue Tracker Issue tracker can be found at http://www.tschofenig.com:8080/nsismob Practical comments from NSIS folks are needed; Please visit there and put on some texts on it.