slide1 n.
Skip this Video
Download Presentation
Status of –03 version (I)

Loading in 2 Seconds...

play fullscreen
1 / 9

Status of –03 version (I) - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Status of –03 version (I)' - shaman

Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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

status of 03 version i
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

status of 03 version ii
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

open issue 9 dead peer discovery
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

open issue 10 multihoming related issues
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

open issue 11 mobility object
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

status of 03 version iii
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

next steps
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

nsis mobility issue tracker
NSIS-mobility Issue Tracker
  • Issue tracker can be found at
  • Practical comments from NSIS folks are needed; Please visit there and put on some texts on it.

The 64th IETF Vancouver Meeting