1 / 9

NSIS Protocols Applicability in Mobile Environments

Discusses issues and clarifications on NSIS protocols in mobile environments, focusing on signaling optimization for mobility scenarios.

sallyr
Download Presentation

NSIS Protocols Applicability in Mobile Environments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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) The 66th IETF Montreal Meeting

  3. 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. The 66th IETF Montreal Meeting

  4. Clarification on #3: Invalid NSIS Responder problem (I) • Issues: • RESPONSE (or Refresh) message can notbe 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 66th IETF Montreal Meeting

  5. 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 66th IETF Montreal Meeting

  6. 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 66th IETF Montreal Meeting

  7. 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 66th IETF Montreal Meeting

  8. 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. • 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? The 66th IETF Montreal Meeting

  9. 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). The 66th IETF Montreal Meeting

More Related