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-05)

• Sung-Hyuck Lee, Seong-Ho Jeong,
  Hannes Tschofenig, Xiaoming Fu, Jukka Manner
• The 66th IETF meeting in Montreal, Canada
• July. 12, 2006

2
Status of 05 version (I)

• Closed issues since the Dallas meeting
• 8 Localized State Update
• Advanced feature
• Need to be discussed in a separated draft
• Clarified issues
• Explicit Routes
• In interaction with Mobile IP, the explicit
  routes in NSIS signaling do not happen
• 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.
• 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)

3
Status of 05 version (II)

• Clarified issues (cont.)
• 10 Multihoming-related issues
• In load balancing scenarios, Path Type Identifier
  can classify the type of CRN (e.g., LB-CRN or
  HO-CRN).
• Use of CRN Discovery flag bit
• Prevent processing overhead.
• 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)).
• 11 Mobility object
• Pertinent to ping-pong type handover issues and
  3 for correct operation.
• Need to be discussed (new issues)
• Key Exchange
• When a handover happens, how to verify the
  signaling messages from (or to) the MN.

4
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.

5
Clarification on 3 Invalid NSIS Responder
problem (II)
OAR
NAR
CRN
CN
MN
Refresh
Error message
Teardown
CN
Notify
CRN
Last Node
Refresh
Refresh
Response
NAR
Refresh
OAR
Notify
6
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.

7
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
8
Open issue 11 Mobility Object

• Description
• The Mobility object which has Mobility_Event_Coun
  ter (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.
• RSN is not appropriate to resolve the ping-pong
  type handover
• 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?

9
Next Steps

• Resolve remaining issues.
• Identify and further clarify the following
  issues.
• The security-related issues
• If open issues and problems are detected ? give
  guidance to protocol authors (before protocols
  are frozen).