MPLS MPLS. Basically: 9 March 2018 AN. Multi-Protocol Label Switching. A bit of history. Multi-Protocol Label Switching.

Transcription

1 Multi-Protocol Label Switching MPLS-TP MP-BGP H-VPLS OSPF-TE LIB MPLS MPLS is not alone LSP ISIS-TE EVPN GMPLS MPLS-TE 9 March 2018 AN T-MPLS LFIB LABEL LDP TAG Used in many (most?) provider networks to provide all kinds of different services RSVP-TE VPLS FEC SR Multi-Protocol Label Switching A bit of history Designed in the ATM era better performance was needed Different services transported over MPLS core Basically: Fixed size label pre-established Faster lookup Label added to packet header No expensive (and recursive) lookups needed Routing was (too) slow edge device of MPLS network applies tag switch forwards according to label swapping table edge device removes tag and forwards packet Label switching started in 1996 Back then ATM was popular, only encapsulations for flows over ATM were defined ATM did not become the big hit and is mostly replaced now by IP/Ethernet devices

2 A bit of history Next Cisco came with Tag Switching (1997) This was brought to the IETF for open standardisation IETF working group involved other vendors and MPLS was defined Tag renamed to Label Because: Back then traffic was growing faster than router vendors and providers could keep up with Existing routing equipment was very expensive Performance was not enough (no in hardware forwarding of packets) Fixed length label lookup was faster RFC-3031: Multiprotocol Label Switching Architecture [June 2001] Multi-Protocol Label Switching The M in MPLS stands for Multi-Protocol, which allows all kinds of different services and encapsulations to be transported over MPLS enabled backbones...because its techniques are applicable to ANY network layer protocol Designed to provide a unified data-carrying service for both circuit-based clients and packetswitching clients which provide a datagram service model (converged networks). To carry many different kinds of traffic, including IP packets, as well as native ATM, SONET, Frame Relay, PPP, HDLC and Ethernet frames, but also Pseudo Wires (PW), VPLS, IP VPNs. Label Switched Paths are similar to circuit-switched paths (virtual circuit) in ATM or FR networks, except not dependent on a particular Layer-2 technology. MPLS defines specific label formats for ATM and Frame Relay, and a generic label format intended for use with most other media. ATM labels correspond to VPI/VCI numbers and may be as long as 24 bits - Frame Relay labels correspond to DLCI numbers and are either 10 or 23 bits long. The generic label is 20 bits long. Destination Based Routing Label switching R1 Lookup destination address in forwarding table R2 Lookup destination address in forwarding table Lookup destination address in forwarding table R4 R1 Lookup label in label database R2 Lookup label in label database Lookup label in label database R /31 inet /31 mpls inet /31 R3 Lookup destination address in forwarding table / inet mpls /31 R3 Lookup label in label database / mpls.0 inet.0 mpls

3 Faster lookups Multi-Protocol Label Switching It was invented for fast(er) routing" (more like L2 switching) Rx 100K IPv4 routes Tx 100K IPv4 routes IDEA: Each flow might be special but numerous flows share the same forwarding behaviour All packets with same label follow the same path Fixed length label lookup is faster than longest match lookups 100K IPv4 FIB entries inet.0 Applications Rx 100K Labeled routes Tx 100K Labeled routes TCP IP MPLS UDP SCTP, MPTCP, DCCP, Layer 3 MPLS is sometimes called: mpls.0 1 MPLS FIB entry Ethernet ATM FR PPP Physical Layer 2 Layer 2.5 protocol Multi-Protocol Label Switching Ethernet header IP header Ethernet header L2 header original packet MPLS header Data IP header L3 header This header is put between Layer-2 and Layer-3 header (a.k.a. shim header) in IP Data SIDE TRACK Routing vs Switching 20 bits 3 bits 1 bit 8 bits Label = a number Label EXP S TTL EXP = experimental bits, for Class of Service (*) S = Bottom of Stack TTL = Time-to-Live (to detect loops) (*) Renamed to Traffic Class field RFC-5462

4 Routing vs Switching Switches switch and Routers route Routing vs Switching Not all entries in RIB have next hops that are directly Switching makes packet (frame) forwarding decisions based on Layer 2 data MAC address Topology Database connected MPLS physical layer-2 address OSPF/ISIS route has an outgoing interface; it s computed by the SPF algorithm and transferred into the IP routing table Routing makes packet forwarding decision based on Layer 3 data IP address OSPF / ISIS BGP BGP route has no outgoing interface and its next hop is not SIDE TRACK logical, hierarchical layer-3 address Switch switches within the subnet/within the network Router routes between the networks recursive lookup - to determine the next hop + outbound interface SIDE TRACK IP Routing table Forwarding table RIB Routing Information Base FIB Forwarding Information Base Simplified view directly connected; the router has to perform recursive lookups to find the outgoing interface IP routes are copied to Forwarding Information Base (FIB) and their next hops are resolved, outgoing interfaces are computed and multiple entries are created when the next-hop resolution results in multiple paths to the same destination Routing vs Switching Useful for MPLS lab Routing vs Switching Switches switch and Routers route. Juniper specific Switching makes packet (frame) forwarding decisions based on Layer 2 data Bridging Routing makes packet forwarding decision based on Layer 3 data MPLS is somewhere in between (Layer 2.5) unless used with ATM or Frame Relay, i.e. L2 protocols that also use something like a label Regardless of how you decide to call the physical (or virtual) device that forwards the data across RIB your network, it s important to understand whether it forwards the data based on physical layer-2 SIDE TRACK FIB SIDE TRACK addresses (we called that bridging) or based on logical, hierarchical layer-3 addresses (what we called routing 20 years ago). Ivan Pepelnjak Blog: See:

5 Routing vs Switching MPLS-based networks scale better than those using ATM or Frame Relay because of two major improvements: Automatic setup of virtual circuits based on network topology (core IP routing information), both between the core switches and between the core (P-routers) and edge (PE-routers) devices. Unless configured otherwise, IP routing protocol performs topology autodiscovery and LDP establishes a full mesh of virtual circuits across the core. LSP - Label Switched Path - Label Edge Router - Label Switching Router FEC - Forwarding Equivalence Class LIB - Label Information Base SIDE TRACK VC merge: Virtual circuits from multiple ingress points to the same egress point can merge within the network. VC merge significantly reduces the overall number of VCs (and the amount of state the core switches have to keep) in fully meshed networks. Important purpose of MPLS: reduces routes in routers and forwarding table entries Multiple IP prefixes into one tag and LSP = Label Edge Router (or PE = Provider Edge router) = Customer Edge router = Label Switching Router (or P = Provider router) R1 Ingress R2 R3 R4 Transit LSP R5 Transit R7 R6 R8 R10 Egress R9 Label locally significant on router Labels only valid between s Actions: push, swap, pop R1 Label push Ingress R2 LSP R3 R4 Transit Label swap Label swap Transit R5 R7 R6 R8 R10 Egress Label pop R9 LSP = Label Switched Path: unidirectional path between s Virtual circuit between pair of routers Before any MPLS forwarding will occur you need to build an LSP! See also:

6 Forwarding Equivalence Class FEC Forwarding Equivalence Class FEC From: RFC3031 Multiprotocol Label Switching Architecture A FEC is a set of packets that a single router: Forwards to the same next hop Out the same interface With the same treatment (such as queuing) FEC can be based on destination prefix, incoming interface, traffic class, source address, normal routing R1 Label push Ingress R2 FEC lookup LSP R3 R4 Transit The ingress router receives packet and determines to which FEC it belongs Forwarded with the same label (over the same LSP) FEC only determined once - at ingress Transit R5 R7 R6 R8 R10 Egress Label pop R9 Packet headers contain considerably more information than is needed simply to choose the next hop. Choosing the next hop can therefore be thought of as the composition of two functions. The first function partitions the entire set of possible packets into a set of "Forwarding Equivalence Classes (FECs)". The second maps each FEC to a next hop. Insofar as the forwarding decision is concerned, different packets which get mapped into the same FEC are indistinguishable. All packets which belong to a particular FEC and which travel from a particular node will follow the same path (or if certain kinds of multi-path routing are in use, they will all follow one of a set of paths associated with the FEC). In conventional IP forwarding, a particular router will typically consider two packets to be in the same FEC if there is some address prefix X in that router's routing tables such that X is the "longest match" for each packet's destination address. As the packet traverses the network, each hop in turn reexamines the packet and assigns it to a FEC. In MPLS, the assignment of a particular packet to a particular FEC is done just once, as the packet enters the network. The FEC to which the packet is assigned is encoded as a short fixed length value known as a "label". When a packet is forwarded to its next hop, the label is sent along with it; that is, the packets are "labeled" before they are forwarded. At subsequent hops, there is no further analysis of the packet's network layer header. Rather, the label is used as an index into a table which specifies the next hop, and a new label. The old label is replaced with the new label, and the packet is forwarded to its next hop. In the MPLS forwarding paradigm, once a packet is assigned to a FEC, no further header analysis is done by subsequent routers; all forwarding is driven by the labels. This has a number of advantages over conventional network layer forwarding. Label Information Base LIB Labels are stored in Label Information Base Database with all label and forwarding information LIB is populated by static entries or dynamic label distribution protocols Mapping between previous hop (incoming port, label) and FEC Mapping between FEC and next hop (outgoing port, label) ingress router PE2 adds label L4 to packets ingress LSP PE2 PE1-push L4 Prefixes distributed with OSPF/ISIS /transit /transit /transit FEC = loopback address PE1 Z Y X PE1 egress (PE1,L4) (PE1,L3) (PE1,L2) (PE1,L1) swap (L4, L3) swap (L3, L2) swap (L2, L1) pop (L1) Label Forwarding Information Base - LFIB: Forwarding table mapping between labels to outgoing interfaces Only the labels for the best path of FEC LIB Y will do similar processing. The LSP setup proceeds from egress to ingress X evaluates whether PE1 is on the IGP shortest path for that FEC. If successful X assigns L2 for FEC PE1, installs forwarding state swapping L2 and L1 and advertises a binding for L2 and FEC PE1 to Y PE1 assigns a Label (L1) to its own Loopback address (FEC) and advertises that to its LDP peer X Each router has its own LIB, and generates the LFIB (Similar to RIB and FIB) LFIB Label actions: Push to the stack, Swap top label, PoP from the stack; S-bit is set to 1 in MPLS header if label is last label on the stack;

7 Penultimate Hop Popping PHP A B Label allocation and distribution D 3 But who/what assigns the labels? Goal is to build a forwarding table with mapping between FEC/incoming label and outgoing label; Routers pick the label values (local significance only) C E G The MPLS architecture uses downstream label allocation: router expects to receive the traffic with label it picked locally F Label 3 is announced by router B to its neighbor E 3 is a special value, Implicit NULL label [RFC-3032]; This triggers Penultimate Hop Popping (PHP) the (E) before the (B) pops the label and forwards normal IP packet to (B); simplifies processing at (saves one lookup); default behaviour of most implementations, not mandatory; 28 = label A Called downstream because label L bound to FEC F at router B was picked by router C who is one hop further down in the direction of the traffic flow from B downstream -> that is required to interpret the label is responsible for assigning it <- upstream B FEC F = 28 C Label allocation and distribution Multi-Protocol Label Switching A receives mapping for Label L for FEC < > from neighbor B A will use Label L for forwarding if and only if B is on the IGP shortest path for destination < > from A s point of view LSPs shift with IGP path changes!!! Danger of black-holing/looping during reconvergence Label = unsigned integer in the range Some reserved numbers: 0-15 (e.g. label 3) A received packet with unrecognised label (unassigned) is dropped Packets can carry more than 1 label = label stack Last-in, first-out stack The forwarding decision is based on label at top of stack (see S-bit!) Question: Should a label be unique within MPLS domain? MPLS so far Short break.. (15 min) MPLS-TP MP-BGP H-VPLS OSPF-TE LIB LSP ISIS-TE EVPN GMPLS MPLS-TE T-MPLS LFIB LABEL LDP TAG RSVP-TE VPLS FEC SR

8 How are the labels distributed and the mappings made? Manual LSP config human control plane You need routing and signalling (control plane functions) Manual configuration of label bindings and LSPs Or define a new protocol Or extend existing protocol to carry labels Both were done: New protocol: LDP (Label Distribution Protocol) Two existing protocols: RSVP and BGP Ps. Answer: No, unique on router (if platform label space) or per interface (if interface label space) protocols { mpls { static-label-switched-path <LSP-name> { ingress { next-hop <address of next-hop router>; to <LSP-endpoint>; push <label>; On all transit routers And on egress router: POP label On ingress router Juniper specific protocols { mpls { static-label-switched-path <LSP-name> { transit <incoming-label> { next-hop <address of next-hop router>; to <LSP-endpoint>; swap <outgoing-label>; Label Distribution Protocol LDP Label Distribution Protocol LDP Fundamental concept in MPLS: 2 s must agree on meaning of labels used to forward traffic Protocol used where one informs another of the LABEL BINDINGS it has made LDP is specifically designed for label binding and distribution - does nothing else but that, no routing, in fact it relies on an IGP for all routing decisions UDP discovery and TCP sessions between peers LDP Peers inform each other of the label bindings An IGP protocol must br configured on all s New IGP routes (prefixes in routing table) lead to new label bindings Labels can be withdrawn when IGP routes are no longer valid Hard-state - expected to work until explicitly torn down LDP works between directly connected neighbors Peers are automatically discovered (via multicast to well-known UDP port) Builds a full mesh of LSPs between all routers LDP establishes LSPs that follow the IGP best path Initialization: exchange information regarding features and modes supported; Next: information regarding binding Labels and FECs exchanged; After discovery a TCP session is established and LDP session is set up; Keep sessions up keep-alive messages are sent; Label messages: advertise new labels, withdraw labels Easy config See

9 Topology Database LDP Database Resource ReserVation Protocol RSVP OSPF / IS-IS BGP LDP RSVP was developed before MPLS Bandwidth reservation protocol for individual traffic flows in network as part of the int-serv model Its mechanism is to reserve bandwidth along each hop of a network for an end-to-end session (*) Routing table (inet.0) RIB Routing Information Base FEC mapping table (inet.3) LIB Label Information Base (mpls.0) Label Routing table Doesn't scale (create, maintain, tear-down state for each traffic flow!), so it is not/hardly used. FIB Forwarding Information Base LFIB Label Forwarding Information Base RSVP extensions for MPLS to create and maintain LSPs and to create associated bandwidth reservations = RSVP-TE [RFC-3209] Better scaling (single LSP can carry all traffic between ingress and egress router pair, not per flow) Forwarding table Juniper specific See also: (*) Integrated Services Architecture [RFC1633]: fine-grained Quality of Service across the Internet RSVP-TE RSVP-signaled LSP does not necessarily follow IGP shortest path Extensions allow for explicit routing (specify entire path or specific transit nodes) Creation of RSVP-signaled LSP: Ingress router initiates by sending an RSVP PATH message destination is the egress router Egress router sends back an RSVP RESV message follows the reverse path back to ingress includes the allocated label Transit routers receiving the RESV message allocate new local label relay message upstream install entry in LIB Signaling protocol, not routing protocol Bandwidth reservation is optional PATH message: Label request object, Record Route Object, Sender-Tspec, Explicit Route Object (ERO) RESV message: label object, Record Route Object ERO object contains list of addresses of nodes through which the LSP must pass (strict or loose) RSVP-TE 5 D C 5 5 F PATH message A B = IGP metric E 5 G 10 RESV state RESV message PATH and RESV messages travel hop-by-hop through network - establish state at each node Periodic exchange of PATH and RESV messages after establishment to refresh the state (if missed LSP is torn down) RSVP-signaled LSPs follow single path from ingress to egress (even in case of multiple available paths) LSP still unidirectional!

10 RSVP-TE Example output Juniper: With Record Route Object routers can check if the path is loop-free From: , State: Up, ActiveRoute: 0, LSPname: LSP-1 ActivePath: LSP-1-P (primary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary LSP-1-P State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 5) S S S S S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): Jun 16 19:01: Selected as active path 29 Jun 16 19:01: Record Route: Jun 16 19:01: Up 27 Jun 16 19:01: Originate Call MP-BGP Multiprotocol Extensions to BGP It supports multiple address families, easy to define and carry new types of reachability information and associated attributes Advertise prefix and label(s) associated with it [RFC-3107] Carrying Label Information in BGP-4: The label mapping information for a particular route is piggybacked in the same BGP Update message that is used to distribute the route itself. Can be used inter-domain (between AS-es BGP is used) Often BGP is already used so no need for another protocol This is used for Layer3 VPN between sites interconnected by MPLS (provider) core network Each VPN has its own VRF (Virtual Routing and Forwarding instance); MPLS forwarding uses stacked labels: outer label for LSP forwarding inner label to differentiate between different VPNs MP-BGP Multiprotocol Extensions to BGP MP-BGP Multiprotocol Extensions to BGP VPN-Customer D VPN-Customer F BGP PE-A MPLS core PE-C BGP VPN-Customer D VPN-Customer D VPN-Customer F PE-A MPLS core PE-C VPN-Customer D VPN-Customer D ISIS/OSPF PE-B VRF VRF VRF VPN-Customer F VPN-Customer D PE-B Each VRF has different VPN label Routes from red VPN not imported! VPN-Customer F VPN-Customer F This is used for Layer3 VPNs between sites interconnected by MPLS (provider) core network Each VPN has its own VRF (Virtual Routing and Forwarding instance) MPLS forwarding uses stacked labels: outer label for LSP forwarding + inner label to differentiate between different VPNs Route distinguisher (RD) : 64 bit field prefixed to Customer IP prefix(es) to make it unique VPN-IPv4 address space prepended to routes in VRF to identify to which VRF they belong Route target (RT): extended BGP community value defines which prefixes are imported and exported on each PE VPN-IPv4 routes are transported with BGP to other PE s - with MPLS label (inner label) See RFC-4364: BGP/MPLS IP Virtual Private Networks (VPNs)

11 Label Distribution Protocols Multi-Protocol Label Switching Can you use different Label distribution protocols at the same time? E.g LDP and RSVP-TE? And also MP-BGP? Yes! Depends on the built topology Depends on services that need to be provisioned Makes it more complex Needs to be provisioned/configured LSPs have to be built before traffic starts flowing RSVP-TE LSPs need to be configured VRF and route distinguisher and route targets in L3 VPNs need to be configured Due to Moore s Law lookup speed is no longer the biggest problem, but since 1997 a lot of ways to use MPLS have been found... Very heavily used: for implementing Traffic Engineering (TE) L3VPN (over the same core) L2VPN (over the same core) Improving network resiliency with MPLS fast reroute Network orchestrators / controllers with GUIs to make it easier Traffic Engineering TE Traffic Engineering TE What is it? Process of manipulating traffic on an (IP) network to enhance the performance Is not network engineering, but linked Reduce overall cost of operations by more efficient use of bandwidth resources With traditional IP and IP routing protocols difficult: tweaking link cost or weight to influence IGP behaviour availability of resources (e.g. bandwidth) not taken into account IGPs distribute network topology information through network Can be used to calculate the routes of LSP automatically When required to establish LSPs not following IGP routes, with guaranteed QoS characteristics and backup LSPs that avoid single points of failure you need more: Cost optimisation (better utilisation of network resources) Congestion management Dynamic services & traffic profiles Efficient routing (predictable, deterministic paths) and rerouting in case of failures Availability/ resilience / fast restoration QoS / separate realtime latency-critical services from other traffic MPLS-TE: set of extensions to MPLS explicit or constraint based routing use RSVP-TE to set up explicit paths bandwidth reservation MORE CONTROL Traffic Engineering extensions -TE ISIS-TE OSPF-TE RFC-3272: Overview and Principles of Internet Traffic Engineering RFC-2702: Requirements for Traffic Engineering over MPLS

12 VPLS Virtual Private LAN Service VPLS Virtual Private LAN Service A VPLS is (provider) service that emulates the full functionality of traditional LAN A Layer 2 Virtual Private Network (VPN) VPLS is "private" in that devices that belong to different VPLSs cannot interact VPLS is "virtual" in that multiple VPLSs can be offered over a common packet switched network (over IP/MPLS network) Ethernet service: frames sent to broadcast addresses and unknown dest MAC addresses are flooded to all ports all unknown unicast, broadcast and multicast frames are flooded over the corresponding Pseudo- Wires to all PE nodes participating in the VPLS PE-A P Responsibility of service provider to create loop-free topology Full-mesh of Pseudo-Wires connecting the edge sites P P P PE-C Using LDP for Signaling [RFC-4762] Using BGP for Auto-Discovery and Signaling [RFC-4761] PE-B MPLS core Single LAN segment EVPN Ethernet VPN VPLS has number of limitations in redundancy, multicast, multihoming, provisioning simplicity New RFC on defining the requirements for a new solution: Ethernet VPN (EVPN) [RFC-7209] Latest New Protocols EVPN is Layer 2 overlay on IP/MPLS network Virtual multipoint bridged connectivity between different Layer 2 domains EVPN Segment Routing Control plane is MP-BGP New address family Allows MAC addresses to be treated as routes in the BGP table Entry can contain just a MAC address or an IP address + MAC address (ARP entry) With or without VLAN tags See: RFC-7432: BGP MPLS-based Ethernet VPN

13 Segment Routing SR Segment Routing SR Alternative for LDP and RSVP-TE in MPLS networks Segment routing is a new forwarding paradigm that provides source routing The source can define the path a packet will take SR uses MPLS to forward packets (in IPv4), but labels are distributed by IGP (OSPF, ISIS) Source Routing the source chooses a path and encodes it in the packet header as an ordered list of segments the rest of the network executes the encoded instructions Segment: an identifier for any type of instruction forwarding or service Example segments: particular node in network, network link, prefix Source Routing: a node steers packets through an ordered list of instructions (segments) that are encoded in the packet header Segment Routing Forwarding Plane MPLS: ordered list of segments is represented as a stack of labels Segment Routing re-uses MPLS data plane without any change Segment is encoded as MPLS label Applicable to IPv4 and IPv6 address families IPv6: an ordered list of segments is encoded in a routing extension header SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain; Application for SR enable some kind of application controller that can steer traffic over different paths, depending on different requirements and the current state of the network; Doing this now requires MPLS-TE, as well as keeping state in many device, with SR, there is no need to keep state in intermediary devices The state is in the packet, not in the network Segment Routing segment routing with central optimization (P - path computation element) A (1) B N routing along any explicit path segment encoded as IPv6 address C O 9103 SR 9103 D P Z Next Header Length Type Segments Left First Segment Flags Reserved Segment 0 Segment 1 Segment 2 Segment n Optional Type Length Value Objects (variable) ordered list of segments is encoded as ordered list of IPv6 addresses in the routing header active segment is indicated by the Destination Address of the packet next active segment is indicated by a pointer in the routing header (1) Picture from: MPLS et cetera MPLS over 15 years old but Still heavily used Still lot of activities on standardisation MPLS-TP MP-BGP H-VPLS OSPF-TE LIB LSP ISIS-TE EVPN GMPLS MPLS-TE Lot of new activities building upon or extending MPLS T-MPLS LFIB LABEL LDP TAG RSVP-TE VPLS FEC SR Just look at the number of RFCs after RFC-3013 and the drafts in the MPLS WG of the IETF: See for more info: IETF SPRING WG and

14 Thanks for your attention! Questions?