Connection( less & oriented)

1. 6/1/99 1
Internetworking connectionless
and connection-oriented networks
Malathi Veeraraghavan Mark Karol
Polytechnic UniversityBell Laboratories
[email protected] [email protected]
Outline:
»Why internetwork?
»Prior work
»Our proposal

2. 6/1/99 2
Why internetwork?
Router
Switch
Endpoint
Endpoint
Connection-Oriented (CO)
Network
Connectionless (CL) NetworkCL Network

3. 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 modes
Networking modes
ATM
Telephony network,
SONET/SDH, WDM
IP

4. 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 traffic
Switched connections: set up on demand as traffic arrives
CO Network
CL Network CL Network

5. 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 Network
Switch
CL Network
Router
Endpoint
Endpoint
Gateway

6. 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

7. 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)
1
1
5
7
10
1
1
CO Network
CL Network
SETUP
Interactive application
(long-lived flow;
if flow classifier is set
to use CO network for
this flow type)
IP packet

8. 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
6
1
5
7
10
1
1
CO Network
CL Network
IP packet
IP packetIP packet

9. 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
6
1
5
7
10
1
1
CO/CL Network
CL Network
IP packet
Gateway will select
CO network because
path is shorter
IP packet
SETUP
IP packet
SETUP
IP packet
SETUP
IP packet
SETUP
Packets will be forwarded in
CL mode while
connection is being set up

10. 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

11. 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
R1
S1
R2
R4
R7
R5
R3
R
6
S4
S5
S3
S2
CL Network
CO Network
GW1
GW2
GW3
Note: switches have no CL capability

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

13. 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

14. 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

15. 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

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

17. 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

18. 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?”

19. 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

20. 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
PHYPHY
DLL
ATM
ATM Switch
DLL
PHYPHY
DLL

21. 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 interface
program
CO device driver
CO interface
program
CGI
Link-layer
mux/demux
Link-layer
mux/demux
Both Windows
and Solaris allow
for device driver
addition

22. 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