Status of –04 version (I)

1. Applicability Statement of NSIS Protocols in Mobile Environments (draft-ietf-nsis-applicability-mobility-signaling-04) Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner The 65th IETF meeting in Dallas, USA Mar. 23, 2006

2. Status of –04 version (I) • Closed issues since the Vancouver meeting: • #7: Peering Agreement Issue • Advanced feature • #5: Optimal refresh timer value for mobile environment • Difficult to provide a generic mechanism • Clarified issues: • #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. • Reuse API of Mobile IP or a common triggering mechanism. • #4: Authorization-related issues with teardown • solved by a notification message of QoS-NSLP • #6: CRN discovery and State Update on the IP-tunneling path • Separate signaling session for the tunneling path • Optimized tunnel signaling is required for mobility scenarios. The 65th IETF Dallas Meeting

3. Status of –04 version (II) • Clarified issues (cont.): • #9: Dead Peer Discovery • Failure by rerouting can be detected by routing modules, GIST, and QoS NSLP. • Pertinent to ‘#3: Invalid NR problem’ and ‘#11: Mobility Object’. • Link layer information hints (e.g., link layer trigger or NSIS signaling) • #10: Multihoming-related issues • In load balancing scenarios, Path Type Identifier can classify the type of CRN (e.g., LB-CRN or HO-CRN). • Remaining issues to be resolved: • #3: Invalid NSIS Responder problem • Pertinent to ‘#9: Dead Peer Discovery’ and ‘#11: Mobility object’. • Some possible proposals (e.g., Mobility Object: handover_init (HI)). • #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. • #11: Mobility object • Pertinent to ping-pong type handover issues and #3 for correct operation. The 65th IETF Dallas Meeting

4. Clarification on #1: CRN Discovery • NSLP_Br_ID • Just a name representing the branches that are made by the processing of Message Routing State. • An explicit identifier for CRN discovery is not needed • CRN_DISCOVERY (CD) flag bit • Prevent NEs from unnecessarily performing CRN discovery processing rather than incorrectly perceiving it is CRN. • More useful in the case of multihoming and tunneling. • In the multihoming scenarios, several CRNs can be discovered because of multiple paths. In this case, which CRN is in charge of State Update? • Is this CD flag bit useful for enhancement of the GIST and NSLP specifications? The 65th IETF Dallas Meeting

5. Clarification on #3: Invalid NSIS Responder problem (I) • Issues: • RESPONSE (or Refresh) message can not be sent to the corresponding QNI (or QNE: e.g., AR) if QNR (e.g., an MN) performs handover. • Identification of the last node for mobility scenarios • Suggestion to protocols: • Use the link information hints (e.g., Handover_Init (HI) field of the Mobility object) to inform the current AR of a handover. • In this case, there are two approaches • The current AR may be a proxy for the MN (the last node) and it may be able to send RESPONSE messages in response to refresh (e.g., RESERVE) messages. • The current AR just forwards the NOTIFY message including the HI field toward CRN to prevent the NI from removing the NSIS state. The 65th IETF Dallas Meeting

6. Clarification on #3: Invalid NSIS Responder problem (II) MN OAR NAR CRN CN Refresh Error message Teardown CN Notify CRN Last Node Refresh Refresh Response NAR Refresh OAR Notify The 65th IETF Dallas Meeting

7. Clarification on #10: Multihoming-related issues (I) • Description: • NSIS-aware nodes (e.g., MN, HA, CN, etc.) may be multihomed. • Also, multiple CRNs may be found for NSIS signaling in such multihomed environments. • The following questions arise: • Which CRN 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? • In load balancing scenarios, CRN classification is required • Load Balancing (LB)-CRN for multiple flows or Handover (HO)-CRN for mobility. • Path type ID prevents CRN to unnecessarily perform State Update. The 65th IETF Dallas Meeting

8. Clarification on #10: Multihoming-related issues (II) LB- CRN Router 3 PT ID (Y) PT ID (X) Figure 2 AR 2 AR 3 AR 1 CN HO- CRN AP3 AP1 AP2 Router 3 MN LB- CRN PT ID (X) PT ID (Y) Figure 1 AR 2 AR 3 AR 1 CN AP3 AP1 AP2 MN The 65th IETF Dallas Meeting

9. Open issue #11 Mobility Object • Description: • The Mobility object which has ‘Mobility_Event_Counter (MEC)’ and ‘Handover_Init (HI)’ can be used to solve ‘the fast or ping-pong typehandover’ 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. • Question: • Does the mobility object need to be included in NxLP messages as an option? • Which primitives need to be used in order for NTLP (GIST) to notify QoS-NSLP of the mobility events? The 65th IETF Dallas Meeting

10. Next steps • Resolve remaining 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 65th IETF Dallas Meeting