Download Internetworking of connectionless and connection

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Peering wikipedia , lookup

Internet protocol suite wikipedia , lookup

Net bias wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Distributed firewall wikipedia , lookup

IEEE 1355 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

Packet switching wikipedia , lookup

Airborne Networking wikipedia , lookup

Transcript
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