1. NSIS Operation Over IP Tunnels draft-ietf-nsis-tunnel-04.txt Charles Shen, Henning Schulzrinne, Sung-Hyuck Lee, Jong Ho Bang IETF#71 – Philadelphia, USA March 2008

2. Overview Problem: NSIS signaling msgs may be unidentifiable inside IP tunnels How to achieve e2e signaling in the presence of IP tunnels (using QoS NSLP as an example)? Solution: Separate tunnel signalling from e2e session signaling Special tunnel flow ID for in-tunnel packet classification Associate tunnel session with e2e session as necessary

3. Interaction of Tunnel & e2e Sessions – Sender Initiated Scenario e2e Signaling tunnel signaling 1 Reserve 2 Reserve 4 Reserve 2 Reserve with BOUND_SESSSION_ID 3 Response 5 Response Tentry (NE) Texit (NE) Tnode (NE)

4. NSIS Operation Over IP Tunnels draft-shen-nsis-tunnel-01.txt Charles Shen, Henning Schulzrinne, Sung-Hyuck Lee, Jong Ho Bang IETF#64 – Vancouver, Canada November 2005

5. Outline Overview Updates since 00 draft Open issues Next steps

6. Overview Allow NSIS operation over IP tunnels Currently looking at QoS NSLP in particular Consider two types of QoS capable tunnels Supporting aggregate resource management Supporting dynamic individual flow signalling General approach Separate tunnel signalling from e2e session Special tunnel Flow ID for in-tunnel packet classification Associate tunnel session with e2e session as necessary

7. Major updates since -00 version Determined interaction between the e2e session and the tunnel session Alternatives moved to appendix Added Main Message Processing Rules at Tunnel Endpoints

8. Interaction of Tunnel & e2e Sessions – Sender Initiated Scenario e2e Signaling tunnel signaling 1 Reserve 2 Reserve 4 Reserve 2 Reserve with BOUND_SESSSION_ID 3 Response 5 Response Tentry (NE) Texit (NE) Tnode (NE)

9. Interaction of Tunnel & e2e Sessions – Receiver Initiated Scenario e2e Signalingtunnel signaling 1 Query 2 Query 3 Query 2 Query with BOUND_SESSION_ID 5 Reserve 5 Reserve with BOUND_SESSION_ID 4 Reserve 6 Reserve 5 Reserve Sender Tentry (NE) Texit (NE) Tnode (NE)

10. Binding Mechanism for e2e session and tunnel session Binding of e2e and its corresponding tunnel session needs to be established at both tunnel endpoints. The notification from one end to the other of the session binding is achieved by BOUND_SESSION_ID object. (See Open Issue I) The other choice, BOUND_FLOW_ID is not chosen considering possible existence of NAT.

11. Open Issue I - Enhanced BOUND_SESSION_ID Current BOUND_SESSION_ID object does not indicate any reason for the binding by itself Propose to add binding codes. Current examples: 0x01 – Tunnel and e2e sessions 0x02 – Bi-directional sessions 0x03 – Aggregate sessions 0x04 – Dependent sessions (one session is alive only if the other is also alive) Different Binding_Codes triggers different msg processing ReservedBinding_Codes Session ID

12. Open Issue II – Conditional Reservation State In receiver-initiated tunnel reservation scenario, when T exit receives the tunnel Query and end-to- end Query (which will trigger a e2e Reserve), it may create and establish state association for the two sessions but it should wait till the receipt of actual end-to-end Reserve message to trigger the actual Tunnel Reserve Need an additional message-specific flag bit in the common header of QUERY message for this conditional reservation state?

13. Open Issue III - NSIS-Tunnel Capability Discovery Capability discovery needed when both Tunnel Entry (T entry ) and Tunnel Exit (T exit ) need to be NSIS-tunnel aware Choices: Generic tunnel capability discovery at GIST layer? For all types of NSLPs? NSLP specific tunnel capability discovery? Discovery at NSLP layer by defining a Node_Char object (similar to that in RFC 2746)?

14. Next steps Solve open issues More detailed message processing and state management rules Other NSLP (e.g., NAT/FW) over IP tunnels Should this be a WG item?