The 66th IETF meeting in Montreal, Canada Applicability Statement of NSIS Protocols in Mobile Environments (draft-ietf-nsis-applicability-mobility-signaling-05) Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner The 66th IETF meeting in Montreal, Canada July. 12, 2006

The 66th IETF Montreal Meeting Status of –05 version (I) Closed issues since the Dallas meeting: #8: Localized State Update Advanced feature Need to be discussed in a separated draft Clarified issues: Explicit Routes In interaction with Mobile IP, the explicit routes in NSIS signaling do not happen #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. #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) July. 12, 2006 The 66th IETF Montreal Meeting

Status of –05 version (II) Clarified issues (cont.): #10: Multihoming-related issues In load balancing scenarios, Path Type Identifier can classify the type of CRN (e.g., LB-CRN or HO-CRN). Use of CRN Discovery flag bit Prevent processing overhead. 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)). #11: Mobility object Pertinent to ping-pong type handover issues and #3 for correct operation. Need to be discussed (new issues) Key Exchange When a handover happens, how to verify the signaling messages from (or to) the MN. July. 12, 2006 The 66th IETF Montreal Meeting

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. July. 12, 2006 The 66th IETF Montreal Meeting

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 OAR Refresh Notify July. 12, 2006 The 66th IETF Montreal Meeting

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. July. 12, 2006 The 66th IETF Montreal Meeting

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 July. 12, 2006 The 66th IETF Montreal Meeting MN

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 type handover’ and ‘the Invalid NR problem’, respectively. The MEC field can inform the CRN of which incoming message is the latest. RSN is not appropriate to resolve the ping-pong type handover 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? July. 12, 2006 The 66th IETF Montreal Meeting

The 66th IETF Montreal Meeting Next Steps Resolve remaining issues. Identify and further clarify the following issues. The security-related issues If open issues and problems are detected  give guidance to protocol authors (before protocols are frozen). July. 12, 2006 The 66th IETF Montreal Meeting