180 likes | 279 Views
MPLS. H/W update Brief description of the lab What it is? Why do we need it? Mechanisms and Protocols. Multi-Protocol Label Switching (MPLS). A mechanism for building tunnels Label Switched Path (LSP) Forwarding based on “labels” 20 bits for label Packet contains MPLS header Label
E N D
MPLS • H/W update • Brief description of the lab • What it is? • Why do we need it? • Mechanisms and Protocols
Multi-Protocol Label Switching(MPLS) • A mechanism for building tunnels • Label Switched Path (LSP) • Forwarding based on “labels” • 20 bits for label • Packet contains MPLS header • Label • 3 EXP (experimental) bits • 8 bits for TTL • 1 bit for bottom of stack • EXAMPLE • LSPs are unidirectional
Label Operations • PUSH • Add a label on the packet • At the entry point of the tunnel • Packet may already have a label • Label stack • POP • Remove a label from the packet • At the exit point of the tunnel • SWAP • Exchange the label on the packet with another one • During forwarding inside the tunnel
LSP • Has an “ingress” • Entrance • Egress • Exit • It goes over some transit nodes • What traffic does it carry • Forwarding Equivalence class (FEC) • Anything that matches some rules that use the IP header information • We not have the “EDGE” where information is put into the LSP • Edge classifies packet into a FEC and there is no need to do it again inside the network
MPLS forwarding • Routers than can do MPLS forwarding are called Label Switch Routers (LSRs) • Both a router and an LSR • Before we had the RIB and FIB • Now we (also) have the LIB and the LFIB • Lookup incoming label in LFIB • Determine where the packet goes and • What label it should carry • SWAP labels and send the packet
Label Stack • Can have tunnel hierachies • Push another label on a labeled path • I have a label stack • Forwarding decisions are always based on the label at the top of the stack • Swap operations apply to the label at the top of the stack
Signaling • In order to create the LSP somebody has to setup the labels • They are put in the LFIB – Label FIB • MPLS signaling protocols • Label Distribution Protocol (LDP) • RSVP-TE • Even BGP (for VPNs) • They distribute labels and establish tunnels
Reserved Labels • 0 – IPv4 explicit NULL • 1 – Router Altert • 2 – IPv6 explicit NULL • 3 - Implicit NULL • What are these NULLs? • Determine what the Penultimate hop (PHP) will do • May pop the label completely • Or may keep an empty label in the packet
PHP • Penultimate Hop Popping • The egress scales better • But does not know that it was an MPLS packet • Potentially useful information (e.g. EXP bits) are lost
Label Distribution modes • Ordered vs. Independent • Will I wait for the downstream nodes to give me their label? • Unsolicited vs. on-demand • Will I wait for a neighbor to ask me for a label or I will send my labels to them anyway? • Label Space • Per platform • Per interface • Labels have link-local scope • They are unique for the same link only
What is the big deal • Initially people though MPLS forwarding will be faster than IP forwarding • Not an issue anymore • Now people like MPLS because it can be used to setup tunnels • Tunnels for Traffic Engineering • Tunnels for Recovery from failures • Tunnels for VPNs
How can I use the tunnels • Use them if I am their ingress • Can have a static route pointing to a tunnel next-hop • Share traffic • Between IGP • Between IGP/LSPs • Between LSPs • Can share with unequal weights • Advertise them in IGP and use them as links • “forwarding adjacencies” • I already can do things that I could not do with IGP • Can control quite well where my traffic goes • EXAMPLE
Intro to TE • An ISP has a number of core routers that attach to PoPs • ISP usually knows the traffic matrix • Traffic demands between PoPs • ISP would like to control exactly how this traffic moves around in his network • Can setup a full mesh of LSPs and control exactly what is going on • Of course scalability is a issue
RSVP-TE • Based on Resource Reservation Protocol • Extended to carry labels (TE) • It is a signaling protocol • Sets up network state • Does not have anything to do with routing/forwarding • Basic Idea • I am telling RSVP the path I want and it will setup an LSP over this path • Specify the whole path • Loose of strict source route • RSVP calls it Explicit Route object (ERO)
PATH and RESV messages • Ingress sends a PATH message downstream • Follows the route we specified until it hits the egress • ERO or simply IP forwarding towards the destination • Egress sends a RESV message upstream • Until it hits the ingress • Intermediate routers install state • Labels are allocated • Downstream ordered mode
Soft state • PATH and RESV messages create state in RSVP routers • PATH and RESV messages are send periodically to refresh this state • If state is not refreshed in time it expires and it is cleared • Simpler • Do not need to worry about reliable messages etc • Do not need to check with hellos if my neighbor is alive • But I have the overhead of state refreshes
A big example • How messages are sent • How labels are allocated