Introduction to MPLS

Transcription

1 Introduction to MPLS Based on MPLS tutorial from Tim Griffin and MPLS/VPN tutorial from hris hase 1 What s all this talk about MPLS? MPLS is going to solve all of our problems MPLS is a solution in search of a problem MPLS is all about traffic engineering MPLS is what I wish on all of my competitors MPLS is all about virtual private networks MPLS solves network operations problems MPLS creates network operations problems MPLS is all about lowering operational costs MPLS is going to cost more than its worth MPLS is the natural next step in Internet evolution MPLS is too complicated to survive in the Internet But what is MPLS anyway? 2 1

2 Goals of this Tutorial To understand MPLS from a purely technical point of view avoid the hype avoid the cynicism To understand the broad technical issues without getting lost in the vast number of details the gains thecosts the tradeoffs 3 Outline Why MPLS? Problems with current IP routing and forwarding omplexity of overlay model What is MPLS? Label swapping Label distribution onstraint based routing What applications could exploit MPLS? Traffic Engineering Virtual Private Networks Both Layer 2 and Layer 3 VPNs 4 2

3 IP forwarding paths are implemented with destination-based next hop tables Dest. Nxt Hop Default to upstream router A R R1 R4 B R R2 R3 R5 A B D E default R R1 Direct R3 R1 R3 R1 Dest. A B D E default Nxt Hop R2 R2 Direct R5 R5 R2 D E Dest. A B D E default Nxt Hop R4 R3 R3 R4 Direct R4 5 IP Forwarding Process 1. Remove a packet from an input queue 2. heck for sanity, decrement TTL field 4. Place packet on correct output queue If queues get full, just drop packets! Forwarding Process 3. Match packet s destination to a table entry IP Forwarding Table If queues get full, just drop packets! Router 6 3

4 IP routing protocols assume all forwarding is destination-based B R The Fish A The next-hop forwarding paradigm does not allow router R to choose a route to A based on who originated the traffic, B or. 7 IP forwarding tables are maintained by dynamic routing protocols RIP Process BGP Process RIP Routing tables BGP Routing tables BGP OSPF Process OSPF Routing tables RIP Domain OSPF Domain IP Forwarding Table OS kernel 8 4

5 Shortest Path Routing: Link weights tend to attract or repel all traffic A B D A 2 1 D B Overlay Networks B A Layer 2 (virtual circuits) B A Layer

6 Advantages of Overlay Networks ATM and Frame Relay switches offer high reliability and low cost Virtual circuits can be reengineered without changing the layer 3 network Large degree of control over traffic Detailed per-circuit statistics Isolates layer 2 network management from the details of higher layer services 11 Problems with Overlay Networks Often use proprietary protocols and management tools Often requires full meshing of statically provisioned virtual circuits ATM cell tax ---- about 20% of bandwidth If layer 3 is all IP, then the overlay model seems overly complicated and costly Advances in optical networking cast some doubt on the entire approach Overlay model is just fine when layer 2 network provides diverse non IP services (e.g., IPv6, AppleTalk, IPX, ) 12 6

7 Blur Layer 2 and 3? router switch (ATM, Frame) this is not a router this is not a switch what is it? 13 Sanity heck? The problems with IP forwarding and routing do not require technologies like MPLS Many can be addressed with simple solutions. Like the design of simple networks! The problems are not show stoppers The MPLS cure will have side effects For many applications, TP/IP handles congestion very well Technologies like MPLS may be very valuable if they can enable new services and generate new revenue 14 7

8 MPLS = MultiProtocol Label Switching Network MPLS Data Link Physical A Layer 2.5 tunneling protocol Based on ATM-like notion of label swapping A simple way of labeling each network layer packet Independent of Link Layer Independent of Network Layer Used to set up Label-switched paths (LSP), similar to ATM PVs RF 3031 : Multiprotocol Label Switching Architecture 15 MPLS Data Plane 16 8

9 Generic MPLS Encapsulation Layer 2 Header MPLS Label 1 MPLS Label 2 MPLS Label n Layer 3 Packet Label Exp S TTL Often called a shim (or sham ) header RF MPLS Label Stack Encoding Label: Label Value, 20 bits Exp: Experimental, 3 bits S: Bottom of Stack, 1 bit TTL: Time to Live, 8 bits 17 Forwarding via Label Swapping 417 data 288 data Labels are short, fixed-length values. 18 9

10 Popping Labels data 288 data 577 data data 19 Pushing Labels 288 data data data 577 data 20 10

11 A Label Switched Path (LSP) POP! SWAP! SWAP! PUSH! data 417 data 666 data 233 data data tail end A label switched path head end Often called an MPLS tunnel: payload headers are not Inspected inside of an LSP. Payload could be MPLS 21 Label Switched Routers IP IP out IP Forwarding Table IP in IP 77 data Label Swapping Table 23 data MPLS out MPLS in The data plane represents IP Lookup + label push represents label pop + IP lookup 22 11

12 Forwarding Equivalence lass (FE) IP2 417 IP2 666 IP2 233 IP2 IP2 IP1 417 IP1 666 IP1 233 IP1 IP1 Packets IP1 and IP2 are forwarded in the same way --- they are in the same FE. Network layer headers are not inspected inside an MPLS LSP. This means that inside of the tunnel the LSRs do not need full IP forwarding table. 23 LSP Merge IP2 417 IP2 823 IP2 912 IP2 IP2 IP1 111 IP1 666 IP1 233 IP1 IP1 IP2 417 IP2 823 IP2 912 IP2 IP2 IP1 417 IP1 666 IP1 233 IP1 IP1 24 LSP merge 12

13 Penultimate Hop Popping POP + IP Lookup SWAP SWAP PUSH IP 417 IP 666 IP 233 IP IP IP Lookup POP SWAP PUSH IP IP 666 IP 233 IP IP 25 LSP Hierarchy via Label Stacking IP2 IP2 POP 66 IP IP IP IP2 PUSH 66 IP2 23 IP IP IP IP1 23 IP1 POP PUSH IP1 IP1 Did I get carried away on this slide? 26 13

14 MPLS Tunnels come at a cost IMP messages may be generated in the middle of a tunnel, but the source address of the bad packet may not be in the IP forwarding table of the LSR! TTL expired: traceroute depends on this! MTU exceeded: Path MTU Discovery (RF1191) depends on this! None of the proposed solutions are without their own problems 27 MPLS also supports native encapsulation Layer 2 PPP Ethernet ATM Frame MPLS generic encapsulation VPI/VI DLI rest of label stack... generic encapsulation... generic encapsulation... IP datagram 28 14

15 But Native Labels May ause Big Headaches No TTL! Loop detection? Loop prevention? LSP merge may not be supported Label bindings cannot flow from destination to source, but must be requested at source MPLS was initially designed to exploit the existence of ATM hardware and reduce the complexity of overlay networks. But IP/MPLS with native ATM labels results in a large number of problems and complications. 29 MPLS ontrol Plane 30 15

16 Basic MPLS ontrol Plane MPLS control plane = IP control plane + label distribution Label distribution protocols are needed to (1) create label FE bindings (2) distribute bindings to neighbors, (3) maintain consistent label swapping tables 31 Label Distribution: Option I Good Points Piggyback label information on top of existing IP routing protocol Guarantees consistency of IP forwarding tables and MPLS label swapping tables No new protocol required Bad Points Allows only traditional destination-based, hop-byhop forwarding paths Some IP routing protocols are not suitable Need explicit binding of label to FE Link state protocols (OSPF, ISIS) are implicit, and so are not good piggyback candidates Distance vector (RIP) and path vector (BGP) are good candidates. Example: BGP

17 Label Distribution: Option II reate new label distribution protocol(s) Good Points ompatible with Link State routing protocols Not limited to destination-based, hop-by-hop forwarding paths Bad Points Additional complexity of new protocol and interactions with existing protocols Transient inconsistencies between IP forwarding tables and MPLS label swapping tables Examples: LDP (IETF) and TDP (isco proprietary) 33 The ontrol Plane IP Routing Protocols + IP Routing Tables Label distribution protocols + Label Binding Tables Routing messages Label distribution messages IP IP out IP Forwarding Table IP in IP 77 data Label Swapping Table 23 data MPLS out MPLS in 34 17

18 Label Distribution with BGP arrying Label Information in BGP-4 draft-ietf-mpls-bgp4-05.txt (1/2001) Associates a label (or label stack) with the BGP next hop. Uses multiprotocol features of BGP: RF Multiprotocol Extensions for BGP-4 So routes with labels are in a different address space than a vanilla routes (no labels) 35 BGP piggyback not required for simple ibgp optimization Map traffic to the LSP that terminates at the egress router chosen by BGP BGP route Internal BGP IP AS 444 A 417 IP 666 IP 233 IP IP AS 888 B Routers A and B do not need full routing tables. They only need IGP routes (and label bindings)

19 BGP piggyback allows Interdomain LSPs BGP route With label 99 Internal BGP with label 99 Use top of stack to get to egress router, bottom of stack for LSP in AS IP IP IP IP IP AS 444 AS MPLS tunnels can decrease size of core routing state ore routers need only IGP routes and LSPs for IGP routes Implies less route oscillation Implies less memory Implies less PU usage Are these really problems? BUT: still need route reflectors to avoid full mesh and/or to reduce BGP table size at border routers BUT: since your core routers do not have full tables you now have all of the MPLS problems associated with IMP source unknown (TTL, MTU, traceroute ) 38 19

20 Label Distribution Protocol (LDP) RF LDP Specification. (1/2001) Dynamic distribution of label binding information Supports only vanilla IP hop-by-hop paths LSR discovery Reliable transport with TP Incremental maintenance of label swapping tables (only deltas are exchanged) Designed to be extensible with Type-Length- Value (TLV) coding of messages Modes of behavior that are negotiated during session initialization Label retention (liberal or conservative) LSP control (ordered or independent) Label assignment (unsolicited or on-demand) 39 LDP Message ategories Discovery messages: used to announce and maintain the presence of an LSR in a network. Session messages: used to establish, maintain, and terminate sessions between LDP peers. Advertisement messages: used to create, change, and delete label mappings for FEs. Notification messages: used to provide advisory information and to signal error information

21 LDP and Hop-by-Hop routing network /24 next-hop network direct /24 next-hop network A /24 next-hop B /24 network next-hop A B D /24 LSP LDP 417 LDP 666 LDP / / /24 Generate new label And bind to destination A pop swap swap push B D IP 417 IP 666 IP 233 IP IP 41 MPLS Traffic Engineering 42 21

22 MPLS Traffic Engineering The optimization goals of traffic engineering are To enhance the performance of IP traffic while utilizing Network resources economically and reliably. Intra-Domain A Framework for Internet Traffic Engineering Draft-ietf-tewg-framework-02.txt A major goal of Internet Traffic Engineering is to facilitate efficient and reliable network operations while simultaneously optimizing network resource utilization and performance. Intra-Domain RF 2702 Requirements for Traffic Engineering over MPLS 43 TE May Require Going Beyond Hop-by-Hop Routing Explicit routes Allow traffic sources to set up paths onstraint based routing hose only best paths that do no violate some constraints Needs explicit routing May need resource reservation Traffic classification Map traffic to appropriate LSPs 44 22

23 Hop-by-Hop vs. Explicit Routes Distributed control LSP trees rooted at destination Destination based forwarding Originates at source Paths from sources to destinations Traffic to path mapping based on what configuration commands your vendor(s) provide 45 Explicit path Setup REQUEST LSPID 17 REQUEST LSPID 17 REQUEST LSPID 17 Request path D->->B->A with LSPID 17 A B D LSP reply 417 reply 666 reply 233 LSPID 17 LSPID 17 LSPID 17 pop swap swap push IP 417 IP 666 IP 233 IP IP 46 23

24 onstraint Based Routing Basic components 1. Specify path constraints 2. Extend topology database to include resource and constraint information 3. Find paths that do not violate constraints and optimize some metric 4. Signal to reserve resources along path 5. Set up LSP along path (with explicit route) 6. Map ingress traffic to the appropriate LSPs Note: (3) could be offline, or online (perhaps an extension to OSPF) Problem here: OSPF areas hide information for scalability. So these extensions work best only within an area Extend Link State Protocols (IS-IS, OSPF) Extend RSVP or LDP or both! Problem here: what is the correct resource model for IP services? 47 Resource Reservation + Label Distribution Two emerging/competing/dueling approaches: Add label distribution and explicit routes to a resource reservation protocol RSVP-TE R-LDP + + Add explicit routes and resource reservation to a label distribution protocol RSVP LDP RSVP-TE: Extensions to RSVP for LSP Tunnels draft-ietf-mpls-rsvp-lsp-tunnel-08.txt onstraint-based LSP Setup using LDP draft-ietf-mpls-cr-lpd-05.txt 48 24

25 The Fish Revisited B LSP2 A LSP1 Need at least one explicit route to A 49 Use Shortest Paths to get beyond Shortest Paths! The IP routing protocol at LSR A is configured to (privately) see A -> LSP as one link with weight 1. 1 A LSP 2 2 D B 1 1 Vanilla IP forwarding 50 25

26 MPLS Fast Reroute Using MPLS TE to improve availability RSVP-TE creates backup tunnels On failure of protected LSP, packets are shoved down backup LSP tunnel Switchover is faster than waiting for SPF to calculate and signal a new LSP For local repair (link or node) can recover ~100ms or better Backup LSP is already in place, so as soon as the failure is detected locally the headend just needs to reprogram the label FIB 51 Link Protection reate backup LSP around link to Next Hop With or without reservation an also backup normal LDP LSP Backup tunnel. Pushes label 51 onto tunnel A D 2 pop B 45 Protected LSP 52 26

27 Node Protection reate backup tunnel LSP for two hops away (next-next hop) Backs up RSVP-TE tunnel Learns labels from RESV recorded route of protected tunnel Backup tunnel. 2 D Pushes label 45 onto tunnel pop 3 A B 45 Protected LSP 53 Path Protection reate an end-to-end diverse backup tunnel Slower than local protection have to wait for headend to detect failure Backup LSP D 2 A pop B 45 Protected LSP 54 27

28 MPLS TE: Is it worth the cost? Much of the traffic across a (transit) ISPs network is interdomain traffic ongestion is most common on peering links The current work on MPLS TE does not apply to interdomain links! (Actually, it does not even work well across OSPF areas ) MPLS TE is probably most valuable when IP services require more than best effort VPNs with SLAs? Supporting differentiated services? 55 VPNs with MPLS Traditional VPN overlay model: MPLS-based Layer 2 VPNs draft-kompella-mpls-l2vpn-02.txt Whither Layer 2 VPNs? draft-kb-ppvpn-l2vpn-motiv-00.txt New VPN peering model: RF BGP/MPLS VPNs 56 28

29 Traditional Overlay VPNs B A Provider s Layer 2 Network (ATM, Frame Relay, X.25) A B ustomer s Layer 2 VPN 57 Why Not Use MPLS Tunnels? B A Provider s MPLS enabled network A MPLS LSP B MPLS LSP ustomer s Layer 2 VPN MPLS LSP 58 29

30 Potential Advantages of MPLS Layer 2 VPNs Provider needs only a single network infrastructure to support public IP, and VPN services, traffic engineered services, and differentiated services Additional routing burden on provider is bounded lean separation of administrative responsibilities. Service provider does MPLS connectivity, customer does layer 3 connectivity Easy transition for customers currently using traditional Layer 2 VPNs 59 BGP/MPLS VPNs RF 2547 Is Peer Model of VPN (not Overlay) Also draft-rosen-rfc2547bis-02.txt isco configuration info : 120newft/120t/120t5/vpn.htm AT&T s IPFR service is based on this RF

31 RF 2547 Model VPN 2 VPN 1 VPN Provider Network VPN 1 VPN 2 61 Es and PEs ustomer Site E = customer edge PE = provider edge Provider Network 62 31

32 VPN Address Overlap Means Vanilla Forwarding Tables an t Work Site 2 p1 Site 1 p1 VPRN 2 Provider VPRN 1 Site 3 p2 Dest. p1 p2 Nxt Hop???? Site 4 p2 63 VPN Overlap Means Vanilla Forwarding Vanilla forwarding Tables tables an t are out Work Site 2 VPRN 1 Site 1 p2 p1 VPRN 2 Provider Site 3 p3 Dest. p1 p2 p3 Nxt Hop s1 s2 s3 Violates isolation Guarantee of A VPN: site 1 can Exchange traffic with Site 3! 64 32

33 RF 2547 : Per site forwarding tables alled VRFs, for "VPN Routing and Forwarding" tables. Site 2 VPRN 1 Site 1 p2 p1 VPRN 2 Provider Site 2 FT Site 3 p3 Site 1 FT Dest. Nxt Hop p2 s2 Site 3 FT Dest. Nxt Hop p2 s2 Dest. p1 p3 Nxt Hop s1 s3 65 Tunnels required across backbone Site 2 VPRN 1 Site 1 p2 p1 VPRN 2 VPRN 3 Site 3 p3 Site 4 p

34 Follow the Route and Follow the Packet MPLS VPN loud LSR3 LSR1 LSR2 PER1 PER2 R1 Site 1 R1 at Site 1 has a packet addressed to a host in network Z at Site 2. How does it get there? Network Z R2 Site 2 67 LSP Setup for OSPF Route to PER2 MPLS VPN loud L4 L2 LSR3 L2 pop L1 L2 LSR1 LSR2 PER2 L1 PER1 PER2 R1 Li - labels requested via LDP from next hop neighbor for each routing table entry LSP for the OSPF route to reach PER2 R

35 How MPLS VPNs work 1) Follow the routes Each VPN on a PER has a private routing table alled a Virtual Routing Forwarding (vrf) table vrf is assigned attributes that are unique to the VPN Route Targets (RT) - attached to VPN routes.» only vrfs with common RTs share routes Route Distinguishers (RD) - appended to routes to ensure uniqueness even if VPNs have overlapping address spaces» reates a new address family called vpnv4 = RD+ipv4 NOTE: RTs and RDs are applied to routes, NOT packets 2) Follow the packet A stack of two labels is used to forward the packet on the interior LSP and then external interface 69 VPN extensions Route Target (RT) BGP 64 bit extended community value First 16bit identify as RT type. Other 48 bit is variable onventional format ASN:X, i.e., 16b:32b Route Distinguisher (RD) BGP 64 bit extended community value First 16bit identify as RD type. Other 48 bit is variable onventional format ASN:X, i.e., 16b:32b 70 35

36 Distributing ustomer Routes Q: How does PER2 learn Rt Z? A: Either via BGP or statically configured MPLS VPN loud LSR3 LSR1 LSR2 LNK1 PER1 PER2 LNK2 Network Z R1 Li -labels LSP LNK2 data: vrf1 vrf1: RT1, RD1 table: Rt Z LNK2 R2 71 ustomer Routes Distributed via IBGP with Label MPLS VPN loud LSR3 LSR1 LSR2 PER1 PER2 IBGP msg LNK2 Network Z R1 Li -labels LSP RD1+Z, L4, RT1, PER2 LNK2 data: vrf1 vrf1: RT1, RD1 table: Rt Z L4,R2,LNK2 R

37 Only vrfs with Matching RTs Import Route Q: Why different RDs can be used? A: RDs ensure unique addresses and are NOT related to VPN connectivity! Unique RDs on all PEs help route reflectors balance load MPLS VPN loud LSR3 LNK1 data: vrf1 vrf1: RT1, RD2 table: Rt Z L4, PER2 PER2 L1, LSR1 PER1 LSR1 LSR2 PER2 LNK2 Network Z R1 Li -labels LSP LNK2 data: vrf1 vrf1: RT1, RD1 table: Rt Z L4,R2,LNK2 R2 73 R1 learns RT Z Q: How does R1 learn Rt Z? A: Either via BGP or statically configured MPLS VPN loud LSR3 LNK1 data: vrf1 vrf1: RT1, RD2 table: Rt Z L4, PER2 PER2 L1, LSR1 R1 LNK1 LSR1 PER1 table: Rt Z PER1,LNK1 Li -labels LSP LSR2 PER2 LNK2 data: vrf1 vrf1: RT1, RD1 table: Rt Z L4,R2,LNK2 Network Z R

38 Packet for Rt Z forwarded by R1 MPLS VPN loud LSR3 LNK1 data: vrf1 vrf1: RT1, RD1 table: Rt Z L4, PER2 PER2 L1, LSR1 PER1 LSR1 LSR2 PER2 R1 Z packet Li -labels table: Rt Z PER1,LNK1 LSP LNK2 data: vrf1 vrf1: RT1, RD1 table: Rt Z L4,R2,LNK2 Route Z R2 75 Top label is label-switched through interior Q: What happens at end of LSP? MPLS VPN loud LSR3 L2 pop LNK1 data: vrf1 vrf1: RT1, RD1 table: Rt Z L4, PER2 PER2 L1, LSR1 L1 L2 LSR1 PER1 L1 L4 Z packet LSR2 PER2 Route Z R1 Li -labels LSP LNK2 data: vrf1 vrf1: RT1, RD1 table: Rt Z L4,R2,LNK2 R

39 Q: What next? Top label popped at end of LSP MPLS VPN loud LSR3 LSR1 LSR2 PER1 PER2 L4 Z packet R1 Li -labels LSP LNK2 data: vrf1 vrf1: RT1, RD1 table: Rt Z L4,R2,LNK2 Route Z R2 77 Inner label determines egress interface and then is popped Q: Is inner label necessary? A: No. An optimization. It saves an IP lookup MPLS VPN loud LSR3 LSR1 LSR2 PER1 PER2 Z packet R1 Li -labels LSP LNK2 data: vrf1 vrf1: RT1, RD1 table: Rt Z L4,R2,LNK2 Route Z R

40 Purpose of BGP Label Indicates which vrf and optionally which interface on the egress PER Locally, the egress PER will treat labels in two possible ways: Non-aggregate label is associated with an external route Will be switched directly to an outgoing interface IP header is not examined Aggregate label is associated with a locally originated or directly connected route Packet will be looked up in the vrf context 79 MPLS in ore Not Needed MPLS for IGP domain serves as a tunneling method among PERs ould use other tunneling methods Advantages to MPLS: Full mesh of LSP tunnels automatically created an use MPLS TE Internet draft to use IP or GRE tunneling Automatically (treat vpnv4 BGP next hop as a recursive encapsulation) BGP/IPsec VPN <draft-declercq-bgp-ipsec-vpn-00.txt> 80 40

41 RF 2547 Summary Piggyback VPN information on BGP New address family New attributes for membership New Per-site forwarding tables (VRFs) Use MPLS Tunnels between PEs No need for VPN routes on backbone LSRs, only on PEs 81 MPLS VPN Security Private routing table for each VPN (vrf) VPN membership identity associated with each access connection VPN membership is not determined by IP header, only by interface (e.g., DLI, VPI/VI, PPP, VLAN tag). Label and RT for VPN attached to routes advertised for interface. Route and its matching label are only imported by routing tables that match the VPN RT. Impossible for a packet on a PV in one vrf to spoof its way or jump into another vrf 82 41

42 Layer 2 VPNs vs. BGP/MPLS VPNs ustomer routing stays with customer May allow an easier transition for customers currently using Frame/ATM circuits Familiar paradigm Easier to extend to multiple providers ustomer routing is outsourced to provider Transition may be complicated if customer has many extranets or multiple providers New peering paradigm Not clear how multiple provider will work (IMHO) 83 Summary MPLS is an interesting and potentially valuable technology because it provides an efficient and scalable tunneling mechanism provides an efficient and scalable mechanism for extending IP routing with explicit routes 84 42

43 More info on MPLS MPLS working group MPLS list archive MPLS Resource enter Peter Ashwood-Smith s NANOG Tutorial MPLS: Technology and Applications. By Bruce Davie and Yakov Rekhter. Morgan Kaufmann MPLS: Is it all it's cracked up to be? Talk by Pravin K. Johri 85 More info on MPLS TE tewg working group NANOG Tutorial by Jeff Doyle and hris Summers NANOG Tutorial by Robert Raszuk

44 More info on MPLS VPNs PPVPN working group PPVPN Archive NANOG Panel:Provider-Provisioned VPNs MPLS and VPN Architectures. By Ivan Pepelnjak and Jim Guichard. isco Press