* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Internetworking of connectionless and connection
Internet protocol suite wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Distributed firewall wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Deep packet inspection wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Computer network wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Network tap wikipedia , lookup
Internetworking connectionless and connection-oriented networks Malathi Veeraraghavan Polytechnic University [email protected] Mark Karol Bell Labs. [email protected] Outline: » Why internetwork? » Prior work » Our proposal 6/1/99 1 Why internetwork? Connectionless (CL) Network CL Network Connection-Oriented (CO) Network Router Endpoint Switch Endpoint 6/1/99 2 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? Networking modes Connectionless Switching modes Packet-switching Circuit-switching 6/1/99 IP Connection-oriented ATM Telephony network, SONET/SDH, WDM 3 Use provisioned connections • Use provisioned connections through CO network – Suitable for some cases CL Network CL Network CO Network Provisioned connections: set up a priori based on anticipated traffic Switched connections: set up on demand as traffic arrives 6/1/99 4 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 Router CL Network Endpoint Gateway Switch CO Network Endpoint 6/1/99 5 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 6/1/99 6 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 IP packet Interactive application (long-lived flow; if flow classifier is set to use CO network for this flow type) 7 10 1 1 5 1 1 SETUP CO Network 6/1/99 7 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 IP packet 7 10 1 1 1 IP packet Does not take advantage of shorter path through the CO network 5 1 6 IP packet 1 CO Network 1 1 Large bulk-data transfers can be handled by either network - if flow classification does not detect this as a flow to be handled by the CO network 6/1/99 8 Solutions - MPLS • MPLS: – – – – Peer model Routing data is shared Requires every CO switch to also be a CL router Consider same example as last slide - large bulk-data transfer that could go either way CL Network IP packet 7 10 1 1 Gateway will select CO network because path is shorter IP packet SETUP 5 1 6 1 1 IP packet SETUP CO 1 IP packet SETUP Packets will be forwarded in CL mode while 6/1/99 connection is being set up 1 /CL Network IP packet SETUP 9 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 6/1/99 10 Routing related actions • Gateways running OSPF connected by a CO network (nonbroadcast network) announce point-to-point links between gateways S4 GW1 S2 R6 R3 GW2 R1 S1 S5 R5 R2 R4 CL Network 6/1/99 R7 GW3 S3 CO Network Note: switches have no CL capability 11 Routing related actions • Topological view of each router and gateway 2 GW1 5 R6 R3 Shortest path from R4 to R7 is via GW3 and GW2 1 R1 1 R5 1 1 GW2 2 3 1 1 R2 1 1 2 R4 R7 4 GW3 1 CL Network User data packets from R4 to R7 arrive at GW3 even before connection is set up 6/1/99 12 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 6/1/99 13 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 acknowledgment to halt data • if persist timers get routed through some other path and data arrives before connection is set up, send another zero-window ack. 6/1/99 14 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 6/1/99 15 Applications Interactive e.g., telnet, rlogin, telephony Bulk-data e.g. ftp, smtp, http Packet-switched CO networks Small amounts of data transfer CL (packet-switched) networks Streaming e.g., live or stored audio or video Circuit-switched (CO) networks Large amounts of data transfer Circuit-switched or CL networks Peer model needed for this case 6/1/99 16 Protocol conversion vs. protocol encapsulation • ATM or label overhead incurred on connection with protocol encapsulation (+ TCP ACKs overhead) • This can be avoided with protocol conversion • Much simpler transport-layer protocol can be used in CO network since the network nodes now maintain state and congestion control (instead of state information being maintained at endpoints) • Can use protocol conversion in switched mode • Drawback: TCP state information about many connections needs to be held at the gateways • Feasibility as yet untested. 6/1/99 17 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 6/1/99 18