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

Status of –04 version (I) PowerPoint PPT Presentation


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

Applicability Statement of NSIS Protocols in Mobile Environments (draft-ietf-nsis-applicability-mobility-signaling-04). Sung-Hyuck Lee , Seong-Ho Jeong , Hannes Tschofenig , Xiaoming Fu , Jukka Manner The 65th IETF meeting in Dallas, USA Mar. 23, 2006.

Download Presentation

Status of –04 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 04 version i

Applicability Statement of NSIS Protocols in Mobile Environments (draft-ietf-nsis-applicability-mobility-signaling-04)

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

The 65th IETF meeting in Dallas, USA

Mar. 23, 2006


Status of 04 version i

Status of –04 version (I)

  • Closed issues since the Vancouver meeting:

    • #7: Peering Agreement Issue

      • Advanced feature

    • #5: Optimal refresh timer value for mobile environment

      • Difficult to provide a generic mechanism

  • Clarified issues:

    • #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.

      • Reuse API of Mobile IP or a common triggering mechanism.

    • #4: Authorization-related issues with teardown

      • solved by a notification message of QoS-NSLP

    • #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.

The 65th IETF Dallas Meeting


Status of 04 version ii

Status of –04 version (II)

  • Clarified issues (cont.):

    • #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)

    • #10: Multihoming-related issues

      • In load balancing scenarios, Path Type Identifier can classify the type of CRN (e.g., LB-CRN or HO-CRN).

  • 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)).

    • #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.

    • #11: Mobility object

      • Pertinent to ping-pong type handover issues and #3 for correct operation.

The 65th IETF Dallas Meeting


Clarification on 1 crn discovery

Clarification on #1: CRN Discovery

  • NSLP_Br_ID

    • Just a name representing the branches that are made by the processing of Message Routing State.

    • An explicit identifier for CRN discovery is not needed

  • CRN_DISCOVERY (CD) flag bit

    • Prevent NEs from unnecessarily performing CRN discovery processing rather than incorrectly perceiving it is CRN.

    • More useful in the case of multihoming and tunneling.

      • In the multihoming scenarios, several CRNs can be discovered because of multiple paths. In this case, which CRN is in charge of State Update?

    • Is this CD flag bit useful for enhancement of the GIST and NSLP specifications?

The 65th IETF Dallas Meeting


Clarification on 3 invalid nsis responder problem i

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.

The 65th IETF Dallas Meeting


Clarification on 3 invalid nsis responder problem ii

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 65th IETF Dallas Meeting


Clarification on 10 multihoming related issues i

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 65th IETF Dallas Meeting


Clarification on 10 multihoming related issues ii

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 65th IETF Dallas Meeting


Open issue 11 mobility object

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.

      • 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 65th IETF Dallas Meeting


Next steps

Next steps

  • Resolve remaining 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 65th IETF Dallas Meeting


  • Login