1 / 10

Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner

Applicability Statement of NSIS Protocols in Mobile Environments (draft-ietf-nsis-applicability-mobility-signaling-02). Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner The 63 rd IETF meeting in Paris, France Aug. 4, 2005.

ulric-wells
Download Presentation

Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner

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-02) Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner The 63rd IETF meeting in Paris, France Aug. 4, 2005

  2. NSIS-mobility Issue Tracker • Issue tracker can be found at http://www.tschofenig.com:8080/nsismob • Please visit there and put on some texts on it.

  3. Status of –02 version (I) • Issues closed based on discussions at the Munich interim meeting. • #4: Authorization-related issues with teardown • solved by disabling of “reverse removal” • #7: Priority of signaling messages • Can not be used by security issues • Remaining issues to be resolved: • #1: CRN discovery • the pros and cons of two discovery mechanisms on CRN was described in more details: either at NTLP layer or NSLP layer. • #2: Mobile IP specific API • This issue is a little implementation-specific, but the usage of an API 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)).

  4. Status of –02 version (II) • Remaining issues to be resolved (cont.): • #5: Optimal refresh timer value for mobile environment • Difficult to provide generic mechanism. • Provide detailed values (for specific scenarios) • #6: CRN discovery and Path Update on the IP-tunneling path • Described possible issues in NSIS-mobility draft • Suggest solutions in separate drafts • #8: Localized Path 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, #10, #11, and #12: newly found

  5. Status of –02 version (III) • Some overlapped issues between QoS-NSLP and NSIS-mobility drafts • #29: Make-before-break handovers (including Seamoby-related issues) • Addressed at the initial NSIS-mobility draft • #32: Last node problem • Similar to the “Invalid NR problem (#3)” • #33: Priority of signaling messages to GIMPS-NSLP API & #39 Explicit indication of refresh • Related to the “priority of signaling messages (#7)” • #17: Node failure and restart handling • “Dead peer discovery (#9)” • How should we resolve the conflict? • Who describes what?

  6. Open issue #9: Dead Peer Discovery • Issues: • Dead peers (e.g., AR (or FA), CRN, HA or MN ) can occur either because a link or a network node failed, or MN moved away without informing NTLP/NSLP (e.g., QoS- or NAT/FW-NSLP). • GIMPS discovery will detect the problem after some time: it says that GIMPS discovery might be slow (?). • Question: • How can dead peers be detected in a fast and efficient manner in mobility scenarios? GIMPS discovery? • Do some “dead peer” cases need to be identified? • e.g., MN’ moving-away, CRN failure, CARs’ failure, FA/HA’s failure, and so on.

  7. Open issue #10 Multihoming 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. • An overall coordination for interworking between the NSIS protocol suite and multihoming capability needs to be discussed further. • Question: • How should multiple CRNs differentiate the Path Update for multihoming from the generic Path Update? • How do CRNs authorize multiple flows with different flow identifiers for the same session?

  8. 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 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 to notify QoS-NSLP of the mobility events?

  9. Open issue #12 Terminology: Path Update • Description: • The term, "Path Update" has been chosen since the initial manyfolks-draft. • Some folks think that the term does not appropriately represent the meaning of NSIS state recovery. • Currently, the candidates for substitution of the term are • "State Recovery" and "State Update". • Any suggestion?

  10. Next steps • Identify and further clarify the following issues • Tunneling-related issues • Localized signaling issues • Newly found issues • The security-related issues • Describe interaction between NSIS protocol suite and mobility protocols (in detail) • If open issues and problems are detected  give guidance to protocol authors (before protocols are frozen)

More Related