Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner

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

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

3. Addressed Not-addressed 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

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

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

6. Open issue # 1: CRN-discovery issues (II) • Procedure of Messaging Association GIMPS-Query Router Alert Option Querying Node Responding Node 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

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

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

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

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

11. 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?

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

13. Open issue #3: Invalid NSIS Responder Problem (II) MN OAR NAR CRN CN Refresh HO Error message Teardown CN CRN Refresh NAR OAR

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

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

16. 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 approachin order to release the old state in mobility scenarios(#4)

17. 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?

18. 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 QUERYmessage 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?

19. 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?

20. Open issue #8: Localized Path Update (II) CN DCRN 2 3 NAR Upstream Path Update OAR 1 Sender CN Downstream Path Update UCRN 1 3 2 NAR OAR Receiver

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

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

23. Implementation Experience on NSIS Mobility

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

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

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

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