Transcript Internetworking of connectionless and connection

Internetworking connectionless
and connection-oriented networks
Malathi Veeraraghavan
Polytechnic University
[email protected]
Mark Karol
Bell Laboratories
[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?
Switching modes
Networking modes
Connectionless
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)
6/1/99
7
10
1
1
5
1
1
SETUP
CO Network
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
5
1
6
IP packet
1
CO Network
1
1
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
6/1/99
8
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
IP packet
7
10
1
1
Gateway will select
CO network because
path is shorter
IP packet
SETUP
Packets will be forwarded in
CL mode while
connection is being set up
6/1/99
5
1
6
1
1
IP packet
SETUP
CO
1
IP packet
SETUP
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-windowsize 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
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
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
17
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
18
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
19
Option 1: Protocol conversion
APP
APP
TCP/UDP
IP
IP
APP
TCP/UDP
AAL5
IP
ATM
AAL5
ATM
APP
TCP/UDP
ATM
IP
TCP/UDP
IP
DLL
DLL DLL
DLL
DLL
DLL DLL
DLL
DLL
DLL
PHY
PHY PHY
PHY
DLL
PHY PHY
PHY
DLL
PHY
Endpoint
Router
Gateway
ATM Switch
Gateway
Endpoint
• Drawback: TCP state information about many
connections needs to be held at the gateways
• Feasibility as yet untested.
6/1/99
20
Option 2: Download software
to endpoints
Web browser
CO interface
program
CO device driver
TCP/IP
Both Windows
and Solaris allow
for device driver
addition
Web server
CO interface
program
CGI
CO device driver
Link-layer module
TCP/IP
Link-layer module
CL Network
Link-layer
mux/demux
Link-layer
mux/demux
CO Network
6/1/99
21
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
6/1/99
22