Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner

1. Applicability Statement of NSIS Protocols in Mobile Environments (draft-ietf-nsis-applicability-mobility-signaling-02) Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner The 63rd IETF meeting in Paris, France Aug. 4, 2005

2. NSIS-mobility Issue Tracker • Issue tracker can be found at http://www.tschofenig.com:8080/nsismob • Please visit there and put on some texts on it.

3. Status of –02 version (I) • Issues closed based on discussions at the Munich interim meeting. • #4: Authorization-related issues with teardown • solved by disabling of “reverse removal” • #7: Priority of signaling messages • Can not be used by security issues • Remaining issues to be resolved: • #1: CRN discovery • the pros and cons of two discovery mechanisms on CRN was described in more details: either at NTLP layer or NSLP layer. • #2: Mobile IP specific API • This issue is a little implementation-specific, but the usage of an API 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)).

4. Status of –02 version (II) • Remaining issues to be resolved (cont.): • #5: Optimal refresh timer value for mobile environment • Difficult to provide generic mechanism. • Provide detailed values (for specific scenarios) • #6: CRN discovery and Path Update on the IP-tunneling path • Described possible issues in NSIS-mobility draft • Suggest solutions in separate drafts • #8: Localized Path 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, #10, #11, and #12: newly found

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

6. Open issue #9: Dead Peer Discovery • Issues: • Dead peers (e.g., AR (or FA), CRN, HA or MN ) can occur either because a link or a network node failed, or MN moved away without informing NTLP/NSLP (e.g., QoS- or NAT/FW-NSLP). • GIMPS discovery will detect the problem after some time: it says that GIMPS discovery might be slow (?). • Question: • How can dead peers be detected in a fast and efficient manner in mobility scenarios? GIMPS discovery? • Do some “dead peer” cases need to be identified? • e.g., MN’ moving-away, CRN failure, CARs’ failure, FA/HA’s failure, and so on.

7. Open issue #10 Multihoming 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. • An overall coordination for interworking between the NSIS protocol suite and multihoming capability needs to be discussed further. • Question: • How should multiple CRNs differentiate the Path Update for multihoming from the generic Path Update? • How do CRNs authorize multiple flows with different flow identifiers for the same session?

8. 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 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 to notify QoS-NSLP of the mobility events?

9. Open issue #12 Terminology: Path Update • Description: • The term, "Path Update" has been chosen since the initial manyfolks-draft. • Some folks think that the term does not appropriately represent the meaning of NSIS state recovery. • Currently, the candidates for substitution of the term are • "State Recovery" and "State Update". • Any suggestion?

10. Next steps • Identify and further clarify the following issues • Tunneling-related issues • Localized signaling issues • Newly found issues • The security-related issues • Describe interaction between NSIS protocol suite and mobility protocols (in detail) • If open issues and problems are detected  give guidance to protocol authors (before protocols are frozen)