1. 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
November 2005
IETF 64 - NSIS

2. Outline Overview Updates since 00 draft Open issues Next steps
November 2005
IETF 64 - NSIS

3. 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
November 2005
IETF 64 - NSIS

4. 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
November 2005
IETF 64 - NSIS

5. 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
November 2005
IETF 64 - NSIS

6. 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
November 2005
IETF 64 - NSIS

7. 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.
November 2005
IETF 64 - NSIS

8. 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
November 2005
IETF 64 - NSIS

9. 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?
November 2005
IETF 64 - NSIS

10. 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)?
November 2005
IETF 64 - NSIS

11. 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?
November 2005
IETF 64 - NSIS