1 / 39

Lecture 14 MPLS Intro to Transport, Reliability, and TCP

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. Multi Protocol Label Switching - MPLS. Selective combination of VCs + IP

jmaria
Download Presentation

Lecture 14 MPLS Intro to Transport, Reliability, and TCP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

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

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

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

  13. Transport Layer • Transport introduction • Error recovery & flow control

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

  15. Functionality Split • Network provides best-effort delivery • End-systems implement many functions • Reliability • In-order delivery • Demultiplexing • Message boundaries • Connection abstraction • Congestion control • …

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

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

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

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

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

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

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

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

  24. Outline • Transport introduction • Error recovery & flow control

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

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

  27. Problems with Stop and Wait • How to recognize a duplicate • Performance • Can only send one packet per round trip

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

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

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

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

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

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

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

  35. Go-Back-N in Action

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

  37. Selective Repeat: Sender, Receiver Windows

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

  39. Next Lecture • Congestion control • TCP Reliability

More Related