Applicability Statement of NSIS Protocols in Mobile Environments draftietfnsisapplicabilitymobilitys

1
Applicability Statement of NSIS Protocols in
Mobile Environments (draft-ietf-nsis-applicab
ility-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.tschofeni
  g.com8080/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/HAs 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_Count
  er (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)