Transcript PPT Version

Applicability Statement of NSIS
Protocols in Mobile Environments
(draft-ietf-nsis-applicability-mobility-signaling-01)
Sung-Hyuck Lee, Seong-Ho Jeong,
Hannes Tschofenig, Xiaoming Fu, Jukka Manner
NSIS Interim Meeting in Munich, Germany
Mar. 8, 2005
Outline
• Current Status
– Identified Issues
– Duplicated issues addressed in QoS-NSLP and NSIS mobility drafts
• Main issues
–
–
–
–
–
–
–
–
–
CRN-discovery issues
Interfaces between mobility management and NSIS protocols
Invalid NSIS Responder Problem
Authorization-related issues with teardown
Optimal refresh timer value for mobile environments
CRN discovery and Path Update on the IP-tunneling Path
Priority of signaling messages
Localized Path Update
Other possible issues
• Next Steps
Addressed
Current Status
Not-addressed
• Issues identified: overview
–
–
–
–
–
Crossover node (CRN) discovery-related issue
Interfaces between mobility management and NSIS protocols
Invalid NSIS Responder (NR) Problem
Optimal refresh timer value for mobile environments
CRN discovery and Path Update on the IP-tunneling Path
– Localized Path Update
– Multihoming-related issues
– Priority of signaling messages (of MN rather than that of fixed
hosts)
– Update of firewall rules and NAT bindings
– Re-use of NAT/FW-NSLP's old state
– Security issues
Duplicated issues addressed in NSIS WG-IDs
• Some issues addressed through the QoS-NSLP issue list
– Make-before-break handovers (including Seamoby-related issues)
• Addressed at the initial NSIS mobility draft, but removed by Allison’s
comments
– Last node problem
• Similar to the “Invalid NR problem”
– Explicit indication of refresh & priority-related issues
• Related to the “priority of signaling messages”
– Node failure and restart handling
• “Dead peer discovery”
– etc.
Open Issue #1: CRN-discovery issues (I)
• Question:
– Which layer should be responsible for the NSLP CRN discovery,
NTLP (GIMPS) or NSLP (e.g., QoS-NSLP and NAT/FW-NSLP)?
• Description:
– The NSLP CRN can be discovered at the GIMPS during the
procedures of the peer discovery and the messaging association
• Although the QoS-NSLP can detect the change of signaling path and
discover the NSLP CRN by keeping track of SII
– Processing overheads (NTLP vs. NSLP) and the functions of the
identifiers in NTLP and NSLP.
Open issue # 1: CRN-discovery issues (II)
• Procedure of Messaging Association
GIMPS-Query
Querying
Node
Router Alert Option
MRI/SID/NSLPID
Q-Node Network Layer Info
Query Cookie
[Q-Node Stack-proposal
Q-Node Stack-Config Data]
[NSLP payload]
GIMPS-Response
MRI/SID/NSLPID
R-Node Network Layer Info
Query Cookie
[R-Node Stack-proposal
R-Node Stack-Config Data]
[Responder Cookie]
[NSLP payload]
GIMPS-Confirm
Responding
Node
Open issue #1: CRN-discovery issues (III)
Need to check:
- Whether the same NSLP_ID
exists
- Whether the corresponding
CRN has been discovered
- Whether the same SID and
MRI exist
MO
Flow ID
Session ID
NSLP_Br_ID
= Logical
interfaces
Switching
Fabric
- Whether the NSP_Br_ID has
changed
- Optionally, the Mobility
identifier can be examined
NSLP-CRN
Physical merging point
AR1
AR2
Switching
Fabric
Physical
interface
Open issue#1: CRN-discovery issues (IV)
• Possible options:
– (a) the NTLP should discover NSLP CRN where the routes of flows are
merged, and report this to the NSLP
– (b) the NSLP should decide whether it is a CRN which has to do Path
Update (i.e., local repair)
• Preference (a)
– (a) may decrease the complexity of overall NSIS protocol processing,
– Considering other signaling applications including NAT/FW-NSLP, the
operation may be simpler with (a).
• Preference (b)
– (b) requires additional messages at the NSLP level, but this may be
required anyway for reporting route changes which are discovered directly
by signaling applications.
Open issue #2: Interfaces between mobility
management and NSIS protocols (I)
• Question:
– Is it necessary to define a Mobile IP-specific API in NSIS, or a
common triggering mechanism between routing and NSIS
processes to monitor the operations of other mobility protocols?
• Description:
– NSIS protocols may need to monitor the procedure of Mobile IP
and then to react to the mobility events to continually support the
existing NSIS state after handover,
– That is, an NSIS implementation needs to be developed to react
based on the endpoint notification.
Open issue #2: Interfaces between mobility
management and NSIS protocols (II)
• Additional questions rise…
– Which information of the mobility management protocols should
be monitored?
– How and what information can the NSLP expect from NTLP, or
directly from the routing interface after a mobility event happens?
– How is the binding update interval coordinated with the NSIS
signaling interval?
Open issue #2: Interfaces between mobility
management and NSIS protocols (III)
• Suggestion and related questions
– List some triggers from NTLP and Mobile IP
– Analyze the sorts of events from Mobile IP
• What does the event mean?
• Where is the event detected?
• What bit of NSIS the event could usefully be delivered to locally
– Questions
• Are some mobility events visible to the NTLP when a Mobile IP
handover (new CoA) would just pop up as a new flow?
• Can NTLP know about relationship b/w old and new CoAs?
• If not, is NSLP interested in caring about the relationship?
Open issue #3: Invalid NSIS Responder
Problem (I)
• Question:
– How/by whom can RESPONSE (or Refresh) message be sent to
the corresponding QNI if QNR (e.g., an MN) performs handover
before the receipt of the message?
• Description:
– If the old AR is the last node on the old path due to the MN's
handover, its QoS-NSLP may trigger an error message to indicate
that QoS-NSLP messages (e.g., RESERVE) cannot be forwarded
any further.
– In this case, an error message should not be sent to avoid any
teardown on the old path before re-establishing the state along the
new path (make-before-break handover).
Open issue #3: Invalid NSIS Responder
Problem (II)
MN
OAR
NAR
Refresh
HO
Error message
Teardown
CN
CRN
Refresh
NAR
OAR
CRN
CN
Open issue #3: Invalid NSIS Responder
Problem (II)
• Suggestion to protocols:
– May use handover_init (HI) field of the Mobility object to inform
the current AR of a handover.
– In this case, there may be some approaches to solve the Invalid NR
problem
• 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 (or
RESERVE) messages.
• The current AR may forward the NOTIFY message including the HI
field toward CN to prevent the NI from removing the NSIS state.
– Identification of the last node in mobility scenarios
Open issue #4: Authorization-related issues
with teardown (Closed?)
• Question:
– Can the teardown message be sent toward the opposite direction to the
state initiating node when tearing down the obsolete state after CRN
discovery?
• Description:
– This leads to an authorization problem because a node which does not
initiate signaling for establishing the QoS-NSLP state may delete the state.
• Suggestion:
– Disabling of “reverse removal”: Only a state installer can perform
teardown.
• The session/reservation ownership problem (draft-tschofenig-nsis-sid-00.txt).
»
• Additional question,
– Is it necessary to use the tear-down message to release the old state?
• The old state will time out by using soft state as the general approach.
Open issue #5: Optimal refresh timer
value for mobile environments
• Question:
– How should the refresh timer value be set up according to various
mobility scenarios?
• Description:
– In the frequent handover scenarios, the maintenance of state on the
old path for a long time is not necessary.
– The QoS-NSLP needs to choose appropriate refresh intervals
depending on the network environment (e.g., access network, or
core network) to reduce the waste of resources.
• In the case where the soft state approach is preferred to any explicit
tear-down approach in order to release the old state in mobility
scenarios (#4)
Open issue #6: CRN discovery and Path
Update on the IP-tunneling Path
• Question:
– How can NSIS discover the CRN and perform Path Update on the
tunneling path?
• Details:
– When IP-tunneling is used in the MIP-based network, it is also needed to
perform the path update on the tunneling path.
• If the CRN is located on the tunneling path, how can the CRN be discovered
for the path update?
• When/how to re-setup the state and remove the old state on the tunneling path?
• If route optimization is used after IP-tunneling, when should the state on the
tunneling path be removed?
• Comments from ML
– The operation on the tunneling path can be related to flow ID management.
– Do the issues need to be more clarified in this draft or a separate draft?
Open issue #7: Priority of signaling
messages
• Question:
– Should a high priority be given to the signaling message to
expedite signaling process?
• Description:
– Some messages of QoS-NSLP need to be used to check the
availability of resources in a new access network to ensure that the
moving MN get the required QoS. For example, the QUERY
message can be used for that purpose.
• Additional question:
– Does a high priority need to be given to signaling messages of MN
rather than that of fixed hosts?
Open issue #8: Localized Path Update (I)
• Question:
– Do we need to consider some micro-mobility management protocols to
localize NSIS signaling after mobility event?
• Description:
– One of major issues on QoS signaling in mobility is end-to-end signaling
problem because it causes QoS degradation by undesired delay.
– The Path Update needs to be localized to enhance performance parameters
such as signaling setup delay, resource utilization, and so on.
– A possible approach: the interaction b/w the micro-mobility management
protocols (e.g., HMIP, FMIP, etc.) and NTLP protocols.
– For example, when interacting with HMIP, how is the Path Update
performed with scoped signaling messages within the access network
under the control of MAP?
– Rising Question: Does micro-mobility management protocols need to be
considered in the NSIS mobility draft?
Open issue #8: Localized Path Update (II)
CN
DCRN
2
3
OAR
NAR
Upstream Path Update
1
Sender
CN
UCRN
Downstream Path Update
1
3
2
OAR
NAR
Receiver
Other potential issues
• Update of firewall rules and NAT bindings (closed?)
• Re-use of NAT/FW-NSLP's old state (closed?)
• Security issues
– Key exchanges
– AAA-related issues
Next steps
• Identify and clarify the following issues
–
–
–
–
Multihoming-related issues
The security-related issues
The QSPEC-related issues
Performance constraints (e.g., scarce bandwidth on wireless link)
• 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)
Implementation Experience on NSIS
Mobility
NSIS mobility implementation
• NTLP/QoS-NSLP prototype
–
–
–
–
Redhat Linux 9.0 – Kernel version 2.4.x
IPv6 only (But, some codes are available in both IPv4 and IPv6)
Based on draft-ietf-nsis-ntlp-04.txt
Based on draft-ietf-nsis-qos-nslp-03.txt
• Mobile IPv6 prototype
– Source code: sait-mipv6-2.4.22
– Based on draft-ietf-mip6-mobileip-24.txt
• Some applications
– Streaming server: VLC
– Background traffic: Mgen
– Measurement tool: TTT
Structure of MIPv6 Testbed
eth1 – 3ffe:2e01:1:7::1/64
eth1 – 3ffe:2e00:e:c::2/64
eth1 – 3ffe:2e00:c:b::2/64
eth0 – 3ffe:2e00:e:c::1/64
eth3 – 3ffe:2e00:c:a::2/64
CRN
Core Router
HA
NR-1
eth2 – 3ffe:2e00:e:b::1/64
eth1 – 3ffe:2e00:e:a::1/64
eth0 – 3ffe:2e00:c:a::1/64
eth1 – 3ffe:2e00:c:b::1/64
NAR
PAR
eth0 – 3ffe:2e00:e:a::2/64
eth1 – 3ffe:2e00:e:b::2/64
eth1 – 3ffe:2e01:1:5::1/64
eth0 – 3ffe:2e01:1:6::1/64
MN
eth0 – 3ffe:2e01:1:5:……
MN
eth0 – 3ffe:2e01:1:6:……
CN
eth1 – 3ffe:2e01:1:7::1/64
Testbed Scenarios
HA
TTT
IPv6
Hub
Core Network
CRN
AR 1
AP 1
AR 2
IPv6
AP 2
MN
Over-subscribed
Network
Under-subscribed
Network
IPv6
CN
(Streaming server)
Thank you for your attention!
Please give comments on the NSIS mailing list.