Applicability Statement of NSIS Protocols in Mobile Environments
This presentation is the property of its rightful owner.
Sponsored Links
1 / 9

Status of –03 version (I) PowerPoint PPT Presentation


  • 85 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Status of –03 version (I)

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


Status of 03 version i

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 http://www.tschofenig.com:8080/nsismob

  • Practical comments from NSIS folks are needed; Please visit there and put on some texts on it.

The 64th IETF Vancouver Meeting


  • Login