NSIS Operation Over IP Tunnels draft-shen-nsis-tunnel-00.txt

1. NSIS Operation Over IP Tunnelsdraft-shen-nsis-tunnel-00.txt Charles Shen, Henning Schulzrinne Sung-Hyuck Lee, Jong Ho Bang IETF#63 – Paris, France August 2005

2. Outline • Problem Statement • Related Work • Design Goals • Design Approach • Basic Operation Examples

3. Problem Statement • Currently looking at QoS signalling • Three types of tunnels (RFC 2746) • Type 1 - Best effort • Type 2 - Supporting aggregate resource management • Type 3 - Supporting dynamic individual flow signalling • Problems on signalling operation over the tunnel • Tunnel Signalling - Normal signalling messages not identified inside a tunnel. • Packet Classification – E2e data packet classification fields not examined inside a tunnel.

4. RFC 2746 – RSVP over Tunnel • Tunnel Signaling • Signaling over the tunnel is carried out by a tunnel session. • The e2e session is associated with its tunnel session using a SESSION_ASSOC RSVP object. • The same association mechanism supports both type 2 & 3 tunnels. • Tunnel Packet Classification • QoS data packets are UDP encapsulated, the added UDP source and destination port numbers provide tunnel sessions with the same packet classification granularity as flows outside the tunnel. • IPSEC Data Flows are not UDP encapsulated, they use the SPI for classification purpose [RFC 2207]

5. NSIS Differences • Two-layer architecture for general purpose signaling. • QoS NSLP allows both sender initiated and receiver initiated reservations. • QoS NSLP deals only with unicast. • New features, such as Session ID, to facilitate operation in specific environments (e.g. mobility).

6. Major Design Goals • Support both aggregate managed and individual signaling tunnels. • Work with most, if not all, existing IP tunneling schemes. • Place the tunnel related functionalities only in one or both of the tunnel end points. • If possible, make NSIS tunnel signaling handle specific events (e.g. mobility) in a consistent way as that of NSIS signaling without tunneling.

7. Design Approaches - Signaling over the Tunnel • Managed by one or both tunnel end points • Open issue – how should the e2e and tunnel session be associated? • Option I: Different Session IDs - Current QoS NSLP provides a BOUND_SESSION_ID object. • Pro: same association mechanism can be used for aggregate and individual tunnels • Option II: Shared Session IDs – Probably an intra-session binding object is needed. • Pro: Try to keep Session ID unchanged is why we created it; also facilitates mobility handling.

8. Design Approaches - Tunnel Packet Classification • Base Tunnel Encapsulation Header with • IPv6 flow label • IPv4 or IPv6 DSCP field • Tunnel specific fields (e.g. SPI for IPSEC) • Extra UDP header • Additional interfaces at tunnel end points

9. Sender Tentry Tnode Texit Receiver RESERVE RESERVE’ RESERVE’ RESPONSE’ RESPONSE’ RESERVE RESERVE RESPONSE RESPONSE RESPONSE Basic Operation Example - Sender Initiated Scenario A

10. Sender Tentry Tnode Texit Receiver RESERVE RESERVE’ RESERVE’ RESERVE RESERVE RESPONSE RESPONSE’ RESPONSE’ RESPONSE RESPONSE Basic Operation Example - Sender Initiated Scenario B

11. Sender Tentry Tnode Texit Receiver QUERY QUERY QUERY RESERVE RESERVE QUERY’ QUERY’ RESERVE’ RESERVE’ RESPONSE’ RESPONSE’ RESERVE RESPONSE RESPONSE RESPONSE Basic Operation Example - Receiver Initiated Scenario A

12. Sender Tentry Tnode Texit Receiver QUERY QUERY QUERY RESERVE RESERVE RESERVE QUERY’ QUERY’ RESERVE’ RESERVE’ RESPONSE’ RESPONSE’ RESPONSE RESPONSE RESPONSE Basic Operation Example - Receiver Initiated Scenario B