390 likes | 404 Views
Explore the basics of MPLS, a blend of VCs and IP that enhances traffic engineering, core network simplicity, and VPN services without radical router redesigns. Learn how MPLS tagging optimizes packet forwarding and routing decisions.
E N D
Lecture 14MPLSIntro to Transport, Reliability, and TCP 15-441 Networking, Spring 2007 As usual, adapted from Srini Seshan and David Anderson, 15-441, Fall ‘06
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 3 (IP) header MPLS label Layer 2 header Layer 2 header
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
MPLS core, IP interface MPLS tag assigned MPLS tag stripped IP IP IP IP C 1 3 A R2 2 1 3 4 1 3 R1 R4 2 4 2 4 1 3 B R3 D 2 4 MPLS forwarding in core
MPLS use case #1: VPNs 10.1.0.0/24 10.1.0.0/24 C 1 3 A R2 2 1 3 4 1 3 R1 R4 2 4 2 4 1 3 B R3 D 2 4 10.1.0.0/24 10.1.0.0/24 MPLS tags can differentiate green VPN from orange VPN.
MPLS use case #2: Reduced State Core EBGP EBGP C A R2 A-> C pkt Internal routers must know all C destinations R1 R4 IP Core R3 EBGP C 1 3 A R2 2 1 3 4 1 3 R1 MPLS Core R4 2 4 2 4 R1 uses MPLS tunnel to R4. R1 and R4 know routes, but R2 and R3 don’t. 1 3 R3 2 4 .
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.
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 CoS S TTL 8 20 3 1
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
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.
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
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 trade-offs. • 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
Transport Layer • Transport introduction • Error recovery & flow control
Transport Protocols • Lowest level end-to-end 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
Functionality Split • Network provides best-effort delivery • End-systems implement many functions • Reliability • In-order delivery • Demultiplexing • Message boundaries • Connection abstraction • Congestion control • …
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
“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 UDP: User Datagram Protocol [RFC 768] 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
Often used for streaming multimedia apps Loss tolerant Rate sensitive Other UDP uses (why?): DNS, SNMP Reliable transfer over UDP Must be at application layer Application-specific error recovery UDP, cont. 32 bits Source port # Dest port # Length, in bytes of UDP segment, including header Checksum Length Application data (message) UDP segment format
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? UDP Checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment – optional use!
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
TCP Header Source port Destination port Sequence number Flags: SYN FIN RESET PUSH URG ACK Acknowledgement HdrLen Advertised window Flags 0 Checksum Urgent pointer Options (variable) Data
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 1987 Karn’s algorithm to better estimate round-trip time 1990 4.3BSD Reno fast retransmit delayed ACK’s 1983 BSD Unix 4.2 supports TCP/IP 1988 Van Jacobson’s algorithms congestion avoidance and congestion control (most implemented in 4.3BSD Tahoe) 1986 Congestion collapse observed 1974 TCP described by Vint Cerf and Bob Kahn In IEEE Trans Comm 1982 TCP & IP RFC 793 & 791 1990 1975 1980 1985
TCP Through the 1990s 1994 T/TCP (Braden) Transaction TCP 1996 SACK TCP (Floyd et al) Selective Acknowledgement 1996 FACK TCP (Mathis et al) extension to SACK 1996 Hoe NewReno startup and loss recovery 1993 TCP Vegas (Brakmo et al) delay-based congestion avoidance 1994 ECN (Floyd) Explicit Congestion Notification 1994 1993 1996
Outline • Transport introduction • Error recovery & flow control
Packet ACK 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 Sender Receiver Timeout Time
Packet Packet Packet Packet Packet ACK ACK ACK ACK ACK Recovering from Error Timeout Timeout Timeout Time Packet Timeout Timeout Timeout Early timeout DUPLICATEPACKETS!!! ACK lost Packet lost
Problems with Stop and Wait • How to recognize a duplicate • Performance • Can only send one packet per round trip
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 Pkt 0 ACK 0 ACK 0 ACK 1 How to Recognize Resends? Pkt 0 Pkt 1
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
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
Sender/Receiver State Sender Receiver Next expected Max acceptable Max ACK received Next seqnum … … … … Sender window Receiver window Sent & Acked Sent Not Acked Received & Acked Acceptable Packet OK to Send Not Usable Not Usable
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
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
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
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 Selective Repeat
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
Next Lecture • Congestion control • TCP Reliability