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

Overview Problem: Solution: 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

Interaction of Tunnel & e2e Sessions – Sender Initiated Scenario 2 Reserve with BOUND_SESSSION_ID 2’ Reserve 2’ Reserve 1 Reserve 4 Reserve Tnode (NE) Texit (NE) Tentry (NE) Assumes both end-to-end and tunnel sessions are sender- initiated. Tunnel signaling messages in green and e2e signaling messages in red. The sender first sends an end-to-end RESERVE message which arrives at Tentry. If Tentry supports tunnel signaling and determines that an individual tunnel session needs to be established for the end-to-end session, it chooses the tunnel flow ID, creates the tunnel session and associates the end-to-end session with the tunnel session. Tentry then sends a tunnel RESERVE message matching the requests of the end-to-end session toward the Texit to reserve tunnel resources. Tentry also appends to the original RESERVE message with a tunnel BOUND_SESSION_ID object containing the SID of the tunnel session and sends it toward Texit using normal tunnel encapsulation. The tunnel RESERVE message is processed hop by hop inside the tunnel for the flow identified by the chosen tunnel flow ID. When Texit receives the tunnel RESERVE message, reservation state for the tunnel session will be created. Texit may also send a tunnel RESPONSE message to Tentry. On the other hand, the end-to-end RESERVE message passes through the tunnel intermediate nodes just like any other tunneled packets. When Texit receives the end-to-end RESERVE message, it notices the binding of a tunnel session and checks the state for the tunnel session. When the tunnel session state is available, it updates the end-to-end reservation state using the tunnel session state, removes the tunnel BOUND_SESSION_ID object and forwards the end-to-end RESERVE message further along the path towards the receiver. When the end-to-end reservation finishes, an end-to-end RESPONSE may be sent back from the receiver to the sender. 3’ Response 3’ Response 5 Response 5 Response 5 Response tunnel signaling e2e Signaling

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

Outline Overview Updates since 00 draft Open issues Next steps

Overview Allow NSIS operation over IP tunnels General approach 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

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

Interaction of Tunnel & e2e Sessions – Sender Initiated Scenario 2 Reserve with BOUND_SESSSION_ID 2’ Reserve 2’ Reserve 1 Reserve 4 Reserve Tnode (NE) Texit (NE) Tentry (NE) Assumes both end-to-end and tunnel sessions are sender- initiated. Tunnel signaling messages in green and e2e signaling messages in red. The sender first sends an end-to-end RESERVE message which arrives at Tentry. If Tentry supports tunnel signaling and determines that an individual tunnel session needs to be established for the end-to-end session, it chooses the tunnel flow ID, creates the tunnel session and associates the end-to-end session with the tunnel session. Tentry then sends a tunnel RESERVE message matching the requests of the end-to-end session toward the Texit to reserve tunnel resources. Tentry also appends to the original RESERVE message with a tunnel BOUND_SESSION_ID object containing the SID of the tunnel session and sends it toward Texit using normal tunnel encapsulation. The tunnel RESERVE message is processed hop by hop inside the tunnel for the flow identified by the chosen tunnel flow ID. When Texit receives the tunnel RESERVE message, reservation state for the tunnel session will be created. Texit may also send a tunnel RESPONSE message to Tentry. On the other hand, the end-to-end RESERVE message passes through the tunnel intermediate nodes just like any other tunneled packets. When Texit receives the end-to-end RESERVE message, it notices the binding of a tunnel session and checks the state for the tunnel session. When the tunnel session state is available, it updates the end-to-end reservation state using the tunnel session state, removes the tunnel BOUND_SESSION_ID object and forwards the end-to-end RESERVE message further along the path towards the receiver. When the end-to-end reservation finishes, an end-to-end RESPONSE may be sent back from the receiver to the sender. 3’ Response 3’ Response 5 Response 5 Response 5 Response tunnel signaling e2e Signaling

Interaction of Tunnel & e2e Sessions – Receiver Initiated Scenario 2 Query with BOUND_SESSION_ID 2’ Query 2’ Query 3 Query 1 Query Tnode (NE) Tentry (NE) Texit (NE) 1. Assumes both end-to-end and tunnel sessions are receiver-initiated. 2. When Tentry receives the first end-to-end QUERY message from the sender and knows that this QUERY will trigger a RESERVE, it chooses the tunnel flow ID, creates the tunnel session and sends a tunnel QUERY message matching the requests of the end-to-end session toward the Texit. 3. Tentry also appends to the original QUERY message with a tunnel BOUND_SESSION_ID object containing the SID of the tunnel session and sends it toward the Texit using normal tunnel encapsulation. 4. The tunnel QUERY message is processed hop by hop inside the tunnel for the flow identified by the chosen tunnel flow ID. When Texit receives the tunnel QUERY message, it should create a reservation state for the tunnel session, but it should not send out a tunnel RESERVE message at this time (see open issue II). 5. The end-to-end QUERY message passes along tunnel intermediate nodes just like any other tunneled packets. When Texit receives the end- to-end QUERY message, it notices the binding of a tunnel session and checks state for the tunnel session. When the tunnel session state is available, Texit updates the end-to-end QUERY message using the tunnel session state, removes the tunnel BOUND_SESSION_ID object and forwards the end-to-end QUERY message further along the path. 6. When Texit receives the first end-to-end RESERVE message issued by the receiver, it finds the reservation state of the tunnel session and triggers a tunnel RESERVE message for that session. Meanwhile the end-to-end RESERVE message will be appended with a tunnel BOUND_SESSION_ID object and forwarded towards Tentry. 7. When Tentry receives the tunnel RESERVE, it creates the reservation state for the tunnel session and may send a tunnel RESPONSE back to Texit (not shown). 8. When Tentry receives the end-to-end RESERVE, it creates the end-to- end reservation state and updates it with information from the associated tunnel session reservation state. Then Tentry further forwards the end-to-end RESERVE upstream toward the sender. 9. The sender may send an end-to-end RESPONSE back to receiver (not shown). 5’ Reserve 5’ Reserve 6 Reserve 4 Reserve 5 Reserve with BOUND_SESSION_ID Sender e2e Signaling tunnel signaling

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.

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 Reserved Binding_Codes Session ID

Open Issue II – Conditional Reservation State In receiver-initiated tunnel reservation scenario, when Texit 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?

Open Issue III - NSIS-Tunnel Capability Discovery Capability discovery needed when both Tunnel Entry (Tentry) and Tunnel Exit (Texit) 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)?

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?