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

Current Status 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 Addressed Not-addressed

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 MRI/SID/NSLPID Responding Node Querying Node Q-Node Network Layer Info Query Cookie Q-Node Stack-Config Data] [Q-Node Stack-proposal Router Alert Option GIMPS-Response [NSLP payload] MRI/SID/NSLPID R-Node Network Layer Info Query Cookie R-Node Stack-Config Data] [R-Node Stack-proposal [NSLP payload] GIMPS-Confirm [Responder Cookie]

Open issue #1: CRN-discovery issues (III) AR1 AR2 Physical merging point NSLP-CRN Switching Fabric NSLP_Br_ID = Logical interfaces Session ID Switching Fabric Physical interface Flow ID MO - Whether the same NSLP_ID exists - Whether the corresponding CRN has been discovered - Whether the same SID and MRI exist - Whether the NSP_Br_ID has changed - Optionally, the Mobility identifier can be examined Need to check:

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) OAR NAR CRN CN Refresh OARNARCRNCNMN Refresh Error message Teardown HO

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) OAR NAR DCRN Sender CN OAR NAR UCRN 3 Receiver CN Downstream Path Update Upstream Path Update

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-mipv –Based on draft-ietf-mip6-mobileip-24.txt Some applications –Streaming server: VLC –Background traffic: Mgen –Measurement tool: TTT

Structure of MIPv6 Testbed MN PAR MN NAR Core Router CRN NR-1 HA CN eth1 – 3ffe:2e01:1:5::1/64 eth0 – 3ffe:2e00:e:a::2/64 eth0 – 3ffe:2e01:1:6::1/64 eth1 – 3ffe:2e00:e:b::2/64 eth1 – 3ffe:2e00:c:b::1/64 eth0 – 3ffe:2e00:c:a::1/64 eth1 – 3ffe:2e01:1:7::1/64 eth0 – 3ffe:2e00:e:c::1/64 eth1 – 3ffe:2e00:c:b::2/64 eth1 – 3ffe:2e00:e:c::2/64 eth3 – 3ffe:2e00:c:a::2/64 eth1 – 3ffe:2e00:e:a::1/64 eth2 – 3ffe:2e00:e:b::1/64 eth0 – 3ffe:2e01:1:5:……eth0 – 3ffe:2e01:1:6:…… eth1 – 3ffe:2e01:1:7::1/64

Testbed Scenarios MN AR 1AR 2 CRN AP 1 AP 2 HA TTT CN IPv6 Hub Core Network Over-subscribed Network Under-subscribed Network (Streaming server) IPv6

Thank you for your attention! Please give comments on the NSIS mailing list.