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

1
Applicability Statement of NSIS Protocols in
Mobile Environments (draft-ietf-nsis-applicab
ility-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

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

3
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-mobili
  ty-00.
• 11 Mobility object
• Pertinent to 1 and 3 for correct operation.

4
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/HAs failure, and so
  on.

5
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?

6
Open issue 11 Mobility Object

• Description
• The Mobility objects such as Mobility_Event_Count
  er (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?

7
Status of 03 version (III)

• Some overlapped issues between QoS-NSLP and
  NSIS-mobility drafts
• 29 Make-before-break handovers (including
  Seamoby-related issues) -gt closed
• Addressed at the initial NSIS-mobility draft but
  closed.
• 33 Priority of signaling messages to GIMPS-NSLP
  API 39 Explicit indication of refresh -gt
  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?

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

9
NSIS-mobility Issue Tracker

• Issue tracker can be found at http//www.tschofeni
  g.com8080/nsismob
• Practical comments from NSIS folks are needed
  Please visit there and put on some texts on it.