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

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

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

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

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

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

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

8
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
9
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.
• 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?

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