6/1/99 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

6/1/99 2

Why internetwork?

Router

Switch

Endpoint

Endpoint

Connection-Oriented (CO)Network

Connectionless (CL) Network CL Network

6/1/99 3

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?

Connectionless Connection-oriented

Packet-switching

Circuit-switching

Switching modesNetworking modes

ATM

Telephony network,SONET/SDH, WDM

IP

6/1/99 4

Use provisioned connections

• Use provisioned connections through CO network– Suitable for some cases

Provisioned connections: set up a priori based on anticipated trafficSwitched connections: set up on demand as traffic arrives

CO Network

CL Network CL Network

6/1/99 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

CO NetworkSwitch

CL NetworkRouter

Endpoint

Endpoint

Gateway

6/1/99 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)

CO Network

CL Network

6/1/99 7

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)

11

5710

11

CO Network

CL Network

SETUP

Interactive application(long-lived flow;if flow classifier is set to use CO network forthis flow type)

IP packet

6/1/99 8

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)

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

1 1

1 1

61

5710

11

CO Network

CL NetworkIP packet

IP packet IP packet

6/1/99 9

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

1 1

1 1

61

5710

11

CO/CL Network

CL NetworkIP packet

Gateway will selectCO network becausepath is shorter

IP packetSETUP

IP packet SETUPIP packet

SETUP

IP packetSETUP

Packets will be forwarded in CL mode while

connection is being set up

6/1/99 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

6/1/99 11

Routing related actions

• Gateways running OSPF connected by a CO network (non-broadcast network) announce point-to-point links between gateways

R1S1

R2

R4R7

R5

R3R6

S4

S5

S3

S2

CL NetworkCO Network

GW1

GW2

GW3

Note: switches have no CL capability

6/1/99 12

Routing related actions

• Topological view of each router and gateway

R1

R2

R4R7

R5

R3R6

CL Network

GW1

GW2

GW3

31

1 2

4

1

5

2

1

2

1

1

1

1

1

Shortest path fromR4 to R7 is viaGW3 and GW2

User data packets from R4 to R7 arrive at GW3 even before connection is set up

6/1/99 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

6/1/99 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

6/1/99 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

Applications

Bulk-datae.g. ftp, smtp, http

Interactivee.g., telnet, rlogin,

telephonyPacket-switched CO networks

CL (packet-switched) networks

Small amounts ofdata transfer

Large amounts ofdata transfer

Circuit-switched or CL networks

Streaminge.g., live or stored

audio or videoCircuit-switched (CO) networks

Peer model needed for this case

6/1/99 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

6/1/99 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?”

6/1/99 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

6/1/99 20

Option 1: Protocol conversion

• Drawback: TCP state information about many connections needs to be held at the gateways

• Feasibility as yet untested.

DLL

IP

TCP/UDP

APP

PHY

Endpoint

DLL

IP

TCP/UDP

APP

PHY

Endpoint

DLL

ATM

AAL5

APP

PHY

TCP/UDP

IP

DLL

DLL

Gateway

DLL

IP

TCP/UDP

APP

PHY

AAL5

ATM

DLL

DLL

GatewayRouter

IP

DLL

PHY PHY

DLL

ATM

ATM Switch

DLL

PHY PHY

DLL

6/1/99 21

Option 2: Download software to endpoints

Web browser

TCP/IP

Link-layer module

CO Network

CL Network

Web server

TCP/IP

Link-layer module

CO device driver

CO interfaceprogram

CO device driver

CO interfaceprogram CGI

Link-layermux/demux

Link-layermux/demux

Both Windowsand Solaris allowfor device driver

addition

6/1/99 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