1. The 66th IETF meeting in Montreal, Canada
Applicability Statement of NSIS Protocols in Mobile Environments (draft-ietf-nsis-applicability-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. The 66th IETF Montreal Meeting
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)
July. 12, 2006
The 66th IETF Montreal Meeting

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.
July. 12, 2006
The 66th IETF Montreal Meeting

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.
July. 12, 2006
The 66th IETF Montreal Meeting

5. 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
OAR
Refresh
Notify
July. 12, 2006
The 66th IETF Montreal Meeting

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.
July. 12, 2006
The 66th IETF Montreal Meeting

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
July. 12, 2006
The 66th IETF Montreal Meeting MN

8. 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 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?
July. 12, 2006
The 66th IETF Montreal Meeting

9. The 66th IETF Montreal Meeting
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).
July. 12, 2006
The 66th IETF Montreal Meeting