Internetworking connectionless and connection-oriented networks

1. Internetworking connectionless and connection-oriented networks Malathi Veeraraghavan Mark Karol Polytechnic University Bell Laboratories mv@poly.edu mk@lucent.com Outline: • Why internetwork? • Prior work • Our proposal

2. Connectionless (CL) Network CL Network Connection-Oriented (CO) Network Case 1 Router Endpoint Switch Endpoint Case 2 Case 3 Why internetwork?

3. Connection-oriented Connectionless Networking modes Switching modes Packet-switching IP ATM Telephony network, SONET/SDH, WDM Circuit-switching Problem Statement • Applications at endpoints start sending data without warning in connectionless networks • CO networks need a connection setup phase • So how do the gateways cope with the traffic arriving from the CL networks without time to set up a connection?

4. Use provisioned connections • Use provisioned connections through CO network • Suitable for some cases CL Network CL Network CO Network Case 1 Provisioned connections: set up a priori based on anticipated traffic Switched connections: set up on demand as traffic arrives

5. Switched connections • Need switched connections for some cases • CL applications have an application-level handshake that can be used to trigger connection setups • e.g., interconnecting an Internet telephony PC to a telephone • e.g., H.245 signaling to Q.931 signaling through the PSTN phone CL Network Router Endpoint Gateway Switch CO Network Endpoint Case 2

6. Prior work • Interesting case - Case 3 • A choice exists of which network to use • Existing solutions: • MPOA (Multi-Protocol Over ATM) • MPLS (Multi-Protocol Label Switching) CL Network CO Network Case 3

7. 7 10 5 1 IP packet 1 1 1 SETUP Solutions - MPOA • MPOA: • Overlay model • Routing data not shared • Good solution if choice to use CO network made based on application needs (e.g., interactive sessions with long holding times) CL Network Interactive application (long-lived flow; if flow classifier is set to use CO network for this flow type) CO Network

8. IP packet 7 10 5 1 1 1 IP packet IP packet 6 1 1 1 1 Solutions - MPOA • MPOA: • Not a good solution if either CL or CO network can be used for a given application (e.g., large bulk-data transfers) CL Network CO Network If flow classification does not detect this as a flow to be handled by the CO network, it will not take advantage of shorter path through the CO network

9. 7 10 IP packet 5 1 1 1 6 1 1 IP packet IP packet SETUP SETUP 1 1 IP packet IP packet SETUP SETUP Solutions - MPLS • MPLS: • Peer model • Routing data is shared • Requires every CO switch to also be a CL router • Same example as last slide - large bulk-data transfer that could go either way CL Network Gateway will select CO network because path is shorter CO/CL Network Packets will be forwarded in CL mode while connection is being set up

10. Proposed solution • Peer model • Routing data is shared • How is this done: routing-related actions • But, not all nodes in the CO network need to have CL capability • Problem created: • Data arrives from the CL endpoints into the gateway before connections are set up • User-plane actions

11. GW1 GW2 GW3 Note: switches have no CL capability Routing related actions • Gateways running OSPF connected by a CO network (non-broadcast network) announce point-to-point links between gateways S4 S2 R6 R3 R1 S1 S5 R5 R2 R7 S3 R4 CO Network CL Network

12. 2 1 5 1 1 1 2 3 1 1 1 1 2 4 1 Routing related actions • Topological view of each router and gateway GW1 R6 R3 Shortest path from R4 to R7 is via GW3 and GW2 GW2 R1 R5 R2 R7 GW3 R4 CL Network User data packets from R4 to R7 arrive at GW3 even before connection is set up

13. User-plane actions • IP datagrams arrive at the gateway to be carried through the CO network when no connection exists through it. • IP datagram could be carrying a TCP segment • IP datagram could be carrying a UDP datagram • CO network used only for flows classified as needing connections or those that can be handled on either network

14. For flows for which the CO network is to be used • TCP segment • If it is a SYN segment, hold it up, set up connection • SYN-related time-outs are large (5 sec) • If it is a data segment, then send zero-window-size acknowledgment to halt data • if persist timers get routed through some other path and new data packets arrive before the connection is set up, send another zero-window-size acknowledgment

15. For flows for which the CO network is to be used • UDP datagram • For applications with user-level message exchange, hold up such messages and set up connection (e.g., H.245 open logical channel) • For applications without such exchanges • use source routing to override default routes • use small-bandwidth provisioned pipes

16. Streaming e.g., live or stored audio or video Interactive e.g., telnet, rlogin, telephony Bulk-data e.g. ftp, smtp, http Small amounts of data transfer Large amounts of data transfer Applications Circuit-switched (CO) networks Packet-switched CO networks CL (packet-switched) networks Circuit-switched or CL networks Peer model needed for this case

17. Comparison of CO network options • Circuit switches • IP traffic is bursty by the time it reaches gateway owing to TCP congestion control • Circuit switching not efficient for bursty traffic • ATM switches • 20% overhead due to 10% cell header overhead + TCP acks not fitting in one cell • Switched IP connections: • Reserve bandwidth and buffer for specific flow (hard state) • No additional overhead IP (network-layer) rides over DLL

18. Switched IP connections • New IP routers capable of performing multi-tuple route lookups/scheduling at wire-speed • destination and source addresses • destination and source ports • protocol type and TOS (Type of Service) • Question: Are there any conditions under which a network of ATM switches or circuit switches can perform better than these “IP switches?”

19. Options • Option 1: • Use protocol conversion not protocol encapsulation • Avoids having to carry TCP ACKs in CO network • Much simpler transport-layer protocol can be used in CO network since the network nodes now maintain state and perform congestion control (instead of state information being maintained at endpoints) • Option 2: • Generate traffic at endpoints in mode appropriate for network used

20. IP DLL DLL DLL DLL APP APP APP APP PHY PHY PHY PHY TCP/UDP TCP/UDP AAL5 AAL5 TCP/UDP TCP/UDP IP IP IP ATM ATM ATM IP Router DLL DLL DLL DLL DLL DLL PHY PHY DLL DLL PHY PHY Endpoint Gateway ATMSwitch Gateway Endpoint Option 1: Protocol conversion • Drawback: TCP state information about many connections needs to be held at the gateways • Feasibility as yet untested.

21. CO interface program CO interface program CGI CO device driver CL Network CO device driver CO Network Option 2: Download software to endpoints Both Windows and Solaris allow for device driver addition Web browser Web server TCP/IP TCP/IP Link-layer module Link-layer module Link-layer mux/demux Link-layer mux/demux

22. Conclusions • For applications whose data can be carried in either the CL network or CO network, internetworking should allow for the exchange of routing information (peer model) • Requiring all CO nodes to have CL capability seems too constraining (an MPLS requirement) • Hence, our proposed solution: • Share routing data • “Halt” or “turn back traffic” while setting up connections • To overcome overheads of protocol encapsulation • Perform protocol conversion, or • Download software to endpoints for CO service