Download MPLS, Transport Intro, TCP Intro

Lecture 14
MPLS
Intro to Transport, Reliability, and TCP
15-441 Networking, Spring 2007
As usual, adapted from Srini Seshan and David Anderson, 15-441, Fall ‘06
1
Multi Protocol Label Switching MPLS

Selective combination of VCs + IP
» Today: MPLS useful for traffic engineering, reducing core
complexity, and VPNs

Core idea: Layer 2 carries VC label
» Could be ATM (which has its own tag)
» Could be a “shim” on top of Ethernet/etc.:
» Existing routers could act as MPLS switches just by examining
that shim -- no radical re-design. Gets flexibility benefits, though
not cell switching advantages
Layer 3 (IP) header
Layer 2 header
Layer 3 (IP) header
MPLS label
Layer 2 header
2
MPLS + IP

Map packet onto Forward Equivalence Class (FEC)
» Simple case: longest prefix match of destination address
» More complex if QoS of policy routing is used

In MPLS, a label is associated with the packet when it
enters the network and forwarding is based on the
label in the network core.
» Label is swapped (as ATM VCIs)

Potential advantages.
»
»
»
»
Packet forwarding can be faster
Routing can be based on ingress router and port
Can use more complex routing decisions
Can force packets to followed a pinned route
3
MPLS core, IP interface
MPLS tag
assigned
MPLS tag
stripped
IP
IP
IP
IP
1
A
1
3
2
R2
C
3
4
1
R1
2
B
4
3
R4
1
2
R3
3
2
4
D
4
MPLS forwarding in core
4
MPLS use case #1: VPNs
10.1.0.0/24
10.1.0.0/24
1
A
1
3
2
R2
C
3
4
1
R1
2
B
4
R4
1
2
10.1.0.0/24
3
R3
3
2
4
D
4
10.1.0.0/24
MPLS tags can differentiate green VPN from orange VPN.
5
MPLS use case #2: Reduced
State Core
EBGP
A
EBGP C
R2
R1
A-> C pkt
Internal routers must
know all C destinations
R3
1
A
1
R4
IP Core
3
2
R2
EBGP C
3
4
1
R1 MPLS Core
2
4
R1 uses MPLS tunnel to R4.
. R4 know routes, but
R1 and
R2 and R3 don’t.
1
2
R3
3
3
R4
2
4
4
6
MPLS use case #3: Traffic
Engineering


As discussed earlier -- can pick routes based
upon more than just destination
Used in practice by many ISPs, though
certainly not all.
7
MPLS Mechanisms

MPLS packet forwarding: implementation of
the label is technology specific.
» Could be ATM VCI or a short extra “MPLS” header

Supports stacked labels.
» Operations can be “swap” (normal label swapping),
“push” and “pop” labels.
– VERY flexible! Like creating tunnels, but much
simpler -- only adds a small label.
Label
20
CoS S
3
1
TTL
8
8
MPLS Discussion

Original motivation.
» Fast packet forwarding:
– Use of ATM hardware
– Avoid complex “longest prefix” route lookup
– Limitations of routing table sizes
» Quality of service

Currently mostly used for traffic engineering
and network management.
» LSPs can be thought of as “programmable links” that can
be set up under software control
» on top of a simple, static hardware infrastructure
9
Further reading - MPLS

MPLS isn’t in the book - sorry. Juniper has a
few good presentations at NANOG (the North
American Network Operators Group; a big
collection of ISPs):
» http://www.nanog.org/mtg-0310/minei.html
» http://www.nanog.org/mtg-0402/minei.html
» Practical and realistic view of what people are doing
_today_ with MPLS.
10
Packets over SONET


Same as statically
configured ATM
pipes, but pipes are
SONET channels.
Properties.
– Bandwidth
management is
much less flexible
+ Much lower
transmission
overhead (no ATM
headers)
mux
OC-48
mux
mux
11
Take Home Points


Costs/benefits/goals of virtual circuits
Cell switching (ATM)
» Fixed-size pkts: Fast hardware
» Packet size picked for low voice jitter. Understand tradeoffs.
» Beware packet shredder effect (drop entire pkt)

Tag/label swapping
» Basis for most VCs.
» Makes label assignment link-local. Understand
mechanism.

MPLS - IP meets virtual circuits
» MPLS tunnels used for VPNs, traffic engineering, reduced
core routing table sizes
12
Transport Layer

Transport introduction

Error recovery & flow control
13
Transport Protocols

Lowest level end-toend protocol.
» Header generated by
sender is interpreted
only by the destination
» Routers view transport
header as part of the
payload
7
7
6
6
5
5
Transport
Transport
IP
IP
IP
Datalink
2
2
Datalink
Physical
1
1
Physical
router
14
Functionality Split


Network provides best-effort delivery
End-systems implement many functions
»
»
»
»
»
»
»
Reliability
In-order delivery
Demultiplexing
Message boundaries
Connection abstraction
Congestion control
…
15
Transport Protocols


UDP provides just integrity and demux
TCP adds…
»
»
»
»
»
»
»
Connection-oriented
Reliable
Ordered
Point-to-point
Byte-stream
Full duplex
Flow and congestion controlled
16
UDP: User Datagram Protocol
[RFC 768]


“No frills,” “bare bones”
Internet transport protocol
“Best effort” service, UDP
segments may be:
» Lost
» Delivered out of order to app

Connectionless:
» No handshaking between
UDP sender, receiver
» Each UDP segment handled
independently of others
Why is there a UDP?




No connection establishment
(which can add delay)
Simple: no connection state
at sender, receiver
Small header
No congestion control: UDP
can blast away as fast as
desired
17
UDP, cont.

Often used for
streaming multimedia
apps
» Loss tolerant
» Rate sensitive

Other UDP uses
(why?):
Length, in
bytes of UDP
segment,
including
header
32 bits
Source port #
Dest port #
Length
Checksum
» DNS, SNMP

Reliable transfer over
UDP
» Must be at application
layer
» Application-specific error
recovery
Application
data
(message)
UDP segment format
18
UDP Checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
– optional use!
Sender:



Treat segment contents as
sequence of 16-bit integers
Checksum: addition (1’s
complement sum) of segment
contents
Sender puts checksum value
into UDP checksum field
Receiver:


Compute checksum of
received segment
Check if computed
checksum equals
checksum field value:
» NO - error detected
» YES - no error detected
But maybe errors
nonethless?
19
High-Level TCP Characteristics

Protocol implemented entirely at the ends
» Fate sharing

Protocol has evolved over time and will
continue to do so
»
»
»
»
Nearly impossible to change the header
Use options to add information to the header
Change processing at endpoints
Backward compatibility is what makes it TCP
20
TCP Header
Source port
Destination port
Sequence number
Flags: SYN
FIN
RESET
PUSH
URG
ACK
Acknowledgement
HdrLen 0
Flags
Advertised window
Checksum
Urgent pointer
Options (variable)
Data
21
Evolution of TCP
1984
Nagel’s algorithm
to reduce overhead
of small packets;
predicts congestion
collapse
1975
Three-way handshake
Raymond Tomlinson
In SIGCOMM 75
1983
BSD Unix 4.2
supports TCP/IP
1974
TCP described by
Vint Cerf and Bob Kahn
In IEEE Trans Comm
1986
Congestion
collapse
observed
1982
TCP & IP
RFC 793 & 791
1975
1980
1987
Karn’s algorithm
to better estimate
round-trip time
1985
1990
4.3BSD Reno
fast retransmit
delayed ACK’s
1988
Van Jacobson’s
algorithms
congestion avoidance
and congestion control
(most implemented in
4.3BSD Tahoe)
1990
22
TCP Through the 1990s
1994
T/TCP
(Braden)
Transaction
TCP
1993
1994
TCP Vegas
ECN
(Brakmo et al)
(Floyd)
delay-based
Explicit
congestion avoidance Congestion
Notification
1993
1994
1996
SACK TCP
(Floyd et al)
Selective
Acknowledgement
1996
Hoe
NewReno startup
and loss recovery
1996
FACK TCP
(Mathis et al)
extension to SACK
1996
23
Outline

Transport introduction

Error recovery & flow control
24
Stop and Wait

ARQ
» Receiver sends acknowledgement
(ACK) when it receives packet
» Sender waits for ACK and
timeouts if it does not arrive
within some time period

Simplest ARQ protocol
Send a packet, stop and
wait until ACK arrives
Receiver
Timeout

Sender
Time
25
ACK lost
Timeout
Timeout
Timeout
Timeout
Timeout
Time
Timeout
Recovering from Error
Packet lost
Early timeout
DUPLICATE
PACKETS!!!
26
Problems with Stop and Wait


How to recognize a duplicate
Performance
» Can only send one packet per round trip
27
How to Recognize Resends?

Use sequence numbers
» both packets and acks

Sequence # in packet is
finite  How big should it
be?
» For stop and wait?

One bit – won’t send seq
#1 until received ACK for
seq #0
28
How to Keep the Pipe Full?

Send multiple packets without
waiting for first to be acked
» Number of pkts in flight = window

Reliable, unordered delivery
» Several parallel stop & waits
» Send new packet after each ack
» Sender keeps list of unack’ed
packets; resends after timeout
» Receiver same as stop & wait

How large a window is needed?
» Suppose 10Mbps link, 4ms delay,
500byte pkts
– 1? 10? 20?
» Round trip delay * bandwidth =
capacity of pipe
29
Sliding Window


Reliable, ordered delivery
Receiver has to hold onto a packet until all
prior packets have arrived
» Why might this be difficult for just parallel stop & wait?
» Sender must prevent buffer overflow at receiver

Circular buffer at sender and receiver
» Packets in transit  buffer size
» Advance when sender and receiver agree packets at
beginning have been received
30
Sender/Receiver State
Sender
Max ACK received
Receiver
Next expected
Next seqnum
…
…
…
…
Sender window
Sent & Acked
Sent Not Acked
OK to Send
Not Usable
Max acceptable
Receiver window
Received & Acked
Acceptable Packet
Not Usable
31
Sequence Numbers

How large do sequence numbers need to be?
» Must be able to detect wrap-around
» Depends on sender/receiver window size

E.g.
» Max seq = 7, send win=recv win=7
» If pkts 0..6 are sent succesfully and all acks lost
– Receiver expects 7,0..5, sender retransmits old 0..6!!!

Max sequence must be  send window + recv window
32
Window Sliding – Common Case

On reception of new ACK (i.e. ACK for something that was not
acked earlier)
» Increase sequence of max ACK received
» Send next packet

On reception of new in-order data packet (next expected)
» Hand packet to application
» Send cumulative ACK – acknowledges reception of all packets up to
sequence number
» Increase sequence of max acceptable packet
33
Loss Recovery

On reception of out-of-order packet
» Send nothing (wait for source to timeout)
» Cumulative ACK (helps source identify loss)

Timeout (Go-Back-N recovery)
» Set timer upon transmission of packet
» Retransmit all unacknowledged packets

Performance during loss recovery
» No longer have an entire window in transit
» Can have much more clever loss recovery
34
Go-Back-N in Action
35
Selective Repeat

Receiver individually acknowledges all correctly received
pkts
» Buffers packets, as needed, for eventual in-order delivery to upper
layer

Sender only resends packets for which ACK not received
» Sender timer for each unACKed packet

Sender window
» N consecutive seq #’s
» Again limits seq #s of sent, unACKed packets
36
Selective Repeat: Sender,
Receiver Windows
37
Important Lessons

Transport service
» UDP  mostly just IP service
» TCP  congestion controlled, reliable, byte stream

Types of ARQ protocols
» Stop-and-wait  slow, simple
» Go-back-n  can keep link utilized (except w/ losses)
» Selective repeat  efficient loss recovery

Sliding window flow control
» Addresses buffering issues and keeps link utilized
38
Next Lecture

Congestion control

TCP Reliability
39