Status of –03 version (I)

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. 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)). The 64th IETF Vancouver Meeting

3. 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. The 64th IETF Vancouver Meeting

4. 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. The 64th IETF Vancouver Meeting

5. 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? The 64th IETF Vancouver Meeting

6. 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? The 64th IETF Vancouver Meeting

7. 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? The 64th IETF Vancouver Meeting

8. 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). The 64th IETF Vancouver Meeting

9. 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. The 64th IETF Vancouver Meeting