Question? Leave a message!




Label Switching and MPLS

Label Switching and MPLS 4
Label Switching and MPLS Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1Overview  IPoverATM to MPLS: History of IP Switching  MPLS: generalization of labels, decoupling of control plane  Label distribution/setup protocols: RSVP, LDP  Introduction to Traffic Engineering Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2IP: ―BestEffort Philosophy‖  Well architected, not necessarily worked out in detail  Realization: can‘t predict the future  Architectural decisions: stuff above  Make it reasonable transport  Make it flexible network  Make it extensible stuff below Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3IP Control Plane Evolution  Again, just good enough (besteffort) …  But again, flexible, extensible  Distance Vector routing was fine for quite a while  Just in time, along came link state (OSPF and ISIS)  Now a burning question in OSPF/ISIS is:  Convergence ―in a few seconds‖ is not good enough  See NANOG June 2002 for interesting videos and papers on how to fix LSrouting for fast convergence  Goal: ―Business‖ IP for service providers…  Make me money – new services, GoS  Don‘t lose me money – uptime, SLAs  OSPF/BGP not originally designed to support QoS or multiple services (eg: VoIP, VPNs) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 4ATM – Perfectionist‘s Dream  Connectionoriented  Does everything and does it well stuff above  Anticipated all future uses and transport factored them in network  Philosophical mismatch with IP ATM Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 5Overlay Model for IPoverATM Internetworking  Goal: Run IP over ATM core networks  Why ATM switches offered performance, predictable behavior and services (CBR, VBR, GFR…)  ISPs created ―overlay‖ networks that presented a virtual topology to the edge routers in their network  Using ATM virtual circuits, the virtual network could be reengineered without changing the physical network  Benefits  Full traffic control  Percircuit statistics  More balanced flow of traffic across links Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 6Overlay Model (Contd)  ATM core ringed by routers  PVCs overlaid onto physical network A Physical View B C A Logical C View B Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 7Issue 1: Mapping IP dataplane to ATM: Address Resolution Woes  A variety of serverbased address resolution servers:  ATMARP (RFC 1577), LANE server, BUS server, MPOA server, NHRP server….  Use of separate ptpt and ptmpt VCs with servers  Multiple servers + backup VCs to them needed for fault tolerance  Separate servers needed in every LOGICAL domain (eg: LIS)  Mismatch between the notion of IP subnet and ATM network sizing  Cutthrough forwarding between nodes on same ATM network hard to achieve Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 8Issue 2: Mapping IP controlplane (eg: OSPF) to ATM  Basic OSPF assumes that subnets are ptpt or offer broadcast capability.  ATM is a NonBroadcast Multiple Access (NBMA) media  NBMA ―segments‖ support multiple ―routers‖ with ptpt VCs but do not support datalink broadcast/mcast capability  Each VC is costly = setting up full mesh for OSPF Hello messages is prohibitively expensive  Two ―flooding adjacency‖ models in OSPF:  NonBroadcast Multiple Access (NBMA) model  PointtoMultipoint (ptmpt) Model  Different tradeoffs… Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 9Partial Mesh: NBMA model 1. Neighbor discovery: manually configured 2. Dijkstra SPF views NBMA as a full mesh Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10Partial Mesh: ptmpt model Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 11NBMA vs PtMpt Subnet Model  Key assumption in NBMA model:  Each router on the subnet can communicate with every other (same as IP subnetmodel)  But this requires a ―full mesh‖ of expensive PVCs at the lower layer  Many organizations have a hubandspoke PVC setup, a.k.a. ―partial mesh‖  Conversion into NBMA model requires multiple IP subnets, and complex configuration (see fig on next slide)  OSPF‘s ptmpt subnet model breaks the rule that two routers on the same network must be able to talk directly  Can turn partial PVC mesh into a single IP subnet Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 12OSPF Designated Routers (DRs): NBMA Case  Instead of sending a separate routerLSA for each router, one ―designated router‖ can create a networkLSA for the subnet Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 13OSPF Designated Router (DR): NBMA Case  One router elected as a designated router (DR)  Each router in subnet maintains ―flooding adjacency‖ with the DR, I.e., sends acks of LSAs to DR  DR informs each router of other routers on LAN  DR generates the networkLSA on subnet‘s behalf after synchronizing with all routers  Complex election protocol for DR in case of failure Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 14DR and BDR in OSPF NBMA model  In NBMA model: DR and BDR only maintain VCs and Hellos with all routers on NBMA Flooding in NBMA always goes through DR Multicast not available to optimize LSA flooding. DR generates networkLSA Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 15Summary: IPtoATM Overlay Model Drawbacks  IPtoATM: controlplane mapping issues  Need a full mesh of ATM PVCs for mapping IP routing  Both NBMA and PtMpt mapping models have drawbacks  IPtoATM: dataplane mapping issues  Address resolution (eg: LANE, RFC 1577, MPOA, NHRP) requires a complex distributed server and multicast VC infrastructure  SegmentationandReassembly (SAR) of IP packets into ATM cells can have a multipliereffect on performance even if one cell in a packet is lost  ATM SAR has trouble scaling to OC48 and OC192 speeds  PacketoverSONET (POS) emerged as an alternative at the link layer  ATM + AAL5 overhead (20) deemed excessive Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 16Reexamining Basics: Routing vs Switching Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 17IP Routing vs IP Switching Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 18MPLS: Best of Both Worlds PACKET CIRCUIT HYBRID ROUTING SWITCHING IP MPLS ATM TDM +IP Caveat: one cares about combining the best of both worlds only for large ISP networks that need both features Note: the ―hybrid‖ also happens to be a solution that Shivkumar Kalyanaraman bypasses IPoverATM mapping woes Rensselaer Polytechnic Institute 19History: Ipsilon‘s IP Switching: Concept Hybrid: IP routing (control plane) + ATM switching (data plane) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 20Ipsilon‘s IP Switching ATM VCs setup when new IP “flows” seen, I.e., “datadriven” VC setup Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 21Issues with Ipsilon‘s IP switching Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 22Tag Switching Key difference: tags can be setup in the background using IP routing protocols (I.e. controldriven VC setup) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 23Alphabet Soup MPLS working group in IETF was formed to reach a common standard Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 24MPLS Broad Concept: Route at Edge, Switch in Core IP IP L1 IP L2 IP L3 IP IP Forwarding IP Forwarding LABEL SWITCHING Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 25MPLS Terminology  LDP: Label Distribution Protocol  LSP: Label Switched Path  FEC: Forwarding Equivalence Class  LSR: Label Switching Router  LER: Label Edge Router (Useful term not in standards)  MPLS is ―multiprotocol‖ both in terms of the protocols it supports ABOVE it and BELOW it in the protocol stack Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 26MPLS Header  IP packet is encapsulated in MPLS header and sent down LSP … IP Packet 32bit MPLS Header  IP packet is restored at end of LSP by egress router TTL is adjusted by default Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 27MPLS Label Stack Concept Allows nested tunnels, that are opaque, I.e. do not know or care what protocol data they carry (a.k.a multiprotocol) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 28MPLS Header Label EXP S TTL  Label  Used to match packet to LSP  Experimental bits  Carries packet queuing priority (CoS)  Stacking bit: can build ―stacks‖ of labels  Goal: nested tunnels  Time to live  Copied from IP TTL Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 29Multiprotocol operation The abstract notion of a ―label‖ can be mapped to multiple circuit or VCoriented technologies • ATM label is called VPI/VCI and travels with cell. • Frame Relay label is called a DLCI and travels with frame. • TDM label is called a timeslot its implied, like a lane. • X25 a label is an LCN • Proprietary labels: TAG (in tag switching) etc.. • Frequency or Wavelength substitution where ―label‖ is a light frequency/wavelength (idea in GMPLS) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 30Label Encapsulation ATM FR Ethernet PPP L2 VPI VCI DLCI “Shim Label” Label “Shim Label” ……. IP PAYLOAD MPLS Encapsulation is specified over various media types. Top labels may use existing format, lower label(s) use a new ―shim‖ label format. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 31MPLS Encapsulation ATM ATM LSR constrained by the cell format imposed by existing ATM standards 5 Octets ATM Header VPI VCI PT HEC CLP Format Label Option 1 Label Combined Label Option 2 Option 3 ATM VPI (Tunnel) Label AAL 5 PDU Frame (nx48 bytes) n ••• 1 Network Layer Header Generic Label Encap. AAL5 Trailer ATM and Packet (eg. IP) (PPP/LAN format) SAR 48 Bytes 48 Bytes ATM Header • • • ATM Payload • Top 1 or 2 labels are contained in the VPI/VCI fields of ATM header one in each or single label in combined field, negotiated by LDP • Further fields in stack are encoded with ‗shim‘ header in PPP/LAN format must be at least one, with bottom label distinguished with ‗explicit NULL‘ • TTL is carried in top label in stack, as a proxy for ATM header (that lacks TTL) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 32MPLS Encapsulation Frame Relay Generic Encap. Q.922 (PPP/LAN Format) Header Layer 3 Header and Packet n 1 ••• C/ FE E BE D E DLCI Size = 10, 17, 23 Bits DLCI DLCI R CN A CN E A • Current label value carried in DLCI field of Frame Relay header • Can use either 2 or 4 octet Q.922 Address (10, 17, 23 bytes) • Generic encapsulation contains n labels for stack of depth n top label contains TTL (which FR header lacks), ‗explicit NULL‘ label value Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 33MPLS Encapsulation: PPP LAN Data Links MPLS ‗Shim‘ Headers (1n) n ••• 1 Network Layer Header Layer 2 Header and Packet (eg. IP) (eg. PPP, 802.3) 4 Octets Label Stack TTL Label Exp. S Entry Format Label: Label Value, 20 bits (016 reserved) Exp.: Experimental, 3 bits (was Class of Service) S: Bottom of Stack, 1 bit (1 = last entry in label stack) TTL: Time to Live, 8 bits • Network layer must be inferable from value of bottom label of the stack • TTL must be set to the value of the IP TTL field when packet is first labelled • When last label is popped off stack, MPLS TTL to be copied to IP TTL field • Pushing multiple labels may cause length of frame to exceed layer2 MTU LSR must support ―Max. IP Datagram Size for Labelling‖ parameter any unlabelled datagram greater in size than this parameter is to be fragmented MPLS on PPP links and LANs uses ‗Shim‘ Header Inserted Between Layer 2 and Layer 3 Headers Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 34MPLS Forwarding: Example  An IP packet destined to 134.112.1.5/32 arrives in SF  San Francisco has route for 134.112/16  Next hop is the LSP to New York 134.112/16 New York IP 134.112.1.5 0 San 1965 Francisco 1026 Santa Fe Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 35MPLS Forwarding Example  San Francisco prepends MPLS header onto IP packet and sends packet to first transit router in the path 134.112/16 New York San Francisco Santa Fe Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 36MPLS Forwarding Example  Because the packet arrived at Santa Fe with an MPLS header, Santa Fe forwards it using the MPLS forwarding table  MPLS forwarding table derived from mpls.0 switching table 134.112/16 New York San Francisco Santa Fe Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 37MPLS Forwarding Example  Packet arrives from penultimate router with label 0  Egress router sees label 0 and strips MPLS header  Egress router performs standard IP forwarding decision IP 134.112/16 New York San Francisco Santa Fe Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 38Label Setup/Signaling: MPLS Using IP Routing Protocols Dest Out 47.1 1 Dest Out 47.2 2 47.1 1 47.3 3 47.2 2 47.3 3 47.1 1 3 2 1 3 Dest Out 2 47.1 1 47.2 2 47.3 3 1 47.2 3 47.3 2 • Destination based forwarding tables as built by OSPF, ISIS, RIP, etc. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 39Regular IP Forwarding Dest Out 47.1 1 Dest Out 47.2 2 47.1 1 47.3 3 47.2 2 47.3 3 47.1 1 IP 47.1.1.1 2 IP 47.1.1.1 1 3 Dest Out 2 47.1 1 47.2 2 IP 47.1.1.1 47.3 3 1 47.2 3 47.3 2 IP 47.1.1.1 IP destination address unchanged in packet header Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 40MPLS Label Distribution Intf Label Dest Intf Intf Label Dest Intf Label In In Out In In Out Out 3 0.40 47.1 1 3 0.50 47.1 1 0.40 1 47.1 Request: 47.1 3 3 Intf Dest Intf Label In Out Out 2 1 3 47.1 1 0.50 Mapping: 0.40 1 2 47.3 3 47.2 2 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 41Label Switched Path (LSP) Intf Label Dest Intf Intf Label Dest Intf Label In In Out In In Out Out 3 0.40 47.1 1 3 0.50 47.1 1 0.40 IP 47.1.1.1 1 47.1 Intf Dest Intf Label 3 3 In Out Out 2 3 47.1 1 0.50 1 1 2 47.3 3 47.2 2 IP 47.1.1.1 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 42A General Vanilla LSP 14 311 216 99 311 963 311 963 14 612 462 311 99 5 A Vanilla LSP is actually part of a tree from every source to that destination (unidirectional). Vanilla LDP builds that tree using existing IP forwarding tables to route the control messages. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 43Explicitly Routed (ER) LSP Route= A,B,C 14 972 216 B 14 C A 972 462 ERLSP follows route that source chooses. In other words, the control message to establish the LSP (label request) is source routed. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 44Explicitly Routed (ER) LSP Contd Intf Label Dest Intf Intf Label Dest Intf Label In In Out In In Out Out 3 0.40 47.1 1 3 0.50 47.1 1 0.40 Intf Dest Intf Label IP 47.1.1.1 In Out Out 1 47.1 3 47.1.1 2 1.33 3 3 3 47.1 1 0.50 2 1 1 2 47.3 3 47.2 2 IP 47.1.1.1 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 45ER LSP advantages •Operator has routing flexibility (policybased, QoSbased) •Can use routes other than shortest path •Can compute routes based on constraints in exactly the same manner as ATM based on distributed topology database. (traffic engineering) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 46ER LSP discord • Two signaling options proposed in the standards: CRLDP, RSVP extensions: — CRLDP = LDP + Explicit Route — RSVP ext = Traditional RSVP + Explicit Route + Scalability Extensions • Not going to be resolved any time soon, market will probably have to resolve it. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 47Traffic Engineering  TE: “…that aspect of Internet network engineering dealing with the issue of performance evaluation and performance optimization of operational IP networks …’’  Two abstract subproblems:  1. Define a traffic aggregate (eg: OC or Tcarrier hierarchy, or ATM PVCs)  2. Map the traffic aggregate to an explicitly setup path  Cannot do this in OSPF or BGP4 today  OSPF and BGP4 offer only a SINGLE path B B B 11 11 1 4 2 22 A A D D D EE E 1 2 A 1 1 2 2 Links AB and BD are overloaded C C C LiC nk an s AC not a dnd o t C hD is a w re ov ith O eS rlPF oaded Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 48Why not TE with OSPF/BGP  Internet connectionless routing protocols designed to find only one route (path)  The ―connectionless‖ approach to TE is to ―tweak‖ (I.e. change) link weights in IGP (OSPF, ISIS) or EGP (BGP4) protocols  Assumptions: Quasistatic traffic, knowledge of demand matrix  Limitations:  Performance is fundamentally limited by the single shortest/policy path nature:  All flows to a destination prefix mapped to the same path  Desire to map traffic to different route (eg: for loadbalancing reasons) = the single default route MUST be changed  Changing parameters (eg: OSPF link weights) changes routes AND changes the traffic mapped to the routes  Leads to extra control traffic (eg: OSPF floods or BGP4 update message), convergence problems and routing instability  Summary: Traffic mapping coupled with route availability in OSPF/BGP  MPLS decouples traffic trunking from path setup Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 49Traffic Engineering w/ MPLS (Step I)  Engineer unidirectional paths through your network without using the IGP‘s shortest path calculation IGP shortest path New York San Francisco traffic engineered path Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 50Traffic Engineering w/ MPLS (Part II)  IP prefixes (or traffic aggregates) can now be bound to MPLE Label Switched Paths (LSPs) New York 192.168.1/24 San Francisco 134.112/16 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 51Traffic Aggregates: Forwarding Equivalence Classes LSR LSR LER LER LSP IP1 IP1 IP1 L1 IP1 L2 IP1 L3 IP2 L1 IP2 L2 IP2 L3 IP2 IP2 Packets are destined for different address prefixes, but can be mapped to common path • FEC = ―A subset of packets that are all treated the same way by a router‖ • The concept of FECs provides for a great deal of flexibility and scalability • In conventional routing, a packet is assigned to a FEC at each hop (i.e. L3 lookup), in MPLS it is only done once at the network ingress Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 52Signaled TE Approach (eg: MPLS)  Features:  In MPLS, the choice of a route (and its setup) is orthogonal to the problem of traffic mapping onto a route  Signaling maps global IDs (addresses, path specification) to local IDs (labels)  FEC mechanism for defining traffic aggregates, label stacking for multilevel opaque tunneling  Issues:  Requires extensive upgrades in the network  Hard to internetwork beyond area boundaries  Very hard to go beyond AS boundaries (even in same organization)  Impossible for interdomain routing across multiple organizations = interdomain TE has to be Shivkumar Kalyanaraman Rensselaer Pcon olytechnic ne Insction titute less 53HopbyHop vs. Explicit Routing HopbyHop Routing Explicit Routing • Distributes routing of control traffic • Source routing of control traffic • Builds a set of trees either fragment • Builds a path from source to dest by fragment like a random fill, or backwards, or forwards in organized • Requires manual provisioning, or manner. automated creation mechanisms. • Reroute on failure impacted by • LSPs can be ranked so some reroute convergence time of routing protocol very quickly and/or backup paths may be preprovisioned for rapid restoration • Existing routing protocols are destination prefix based • Operator has routing flexibility (policy based, QoSbased, • Difficult to perform traffic engineering, QoSbased routing • Adapts well to traffic engineering Explicit routing shows great promise for traffic engineering Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 54RSVP: ―Resource reSerVation Protocol‖  A generic QoS signaling protocol  An Internet control protocol Uses IP as its network layer  Originally designed for hosttohost  Uses the IGP to determine paths  RSVP is not A data transport protocol A routing protocol  RFC 2205 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 55Recall: Signaling ideas  Classic scheme: sender initiated  SETUP, SETUPACK, SETUPRESPONSE  Admission control  Tentative resource reservation and confirmation  Simplex and duplex setup; no multicast support Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 56RSVP: Internet Signaling  Creates and maintains distributed reservation state  Decoupled from routing also to support IP multicast model:  Multicast trees setup by routing protocols, not RSVP (unlike ATM or telephony signaling)  Key features of RSVP:  Receiverinitiated: scales for multicast  Softstate: reservation times out unless refreshed  Latest paths discovered through ―PATH‖ messages (forward direction) and used by RESV mesgs (reverse direction).  Again dictated by needs of decoupling from IP routing and to support IP multicast model Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 57RSVP Path Signaling Example  Signaling protocol sets up path from San Francisco to New York, reserving bandwidth along the way Seattle New York (Egress) San Francisco (Ingress) Miami Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 58RSVP Path Signaling Example  Once path is established, signaling protocol assigns label numbers in reverse order from New York to San Francisco Seattle New York (Egress) 3 San Francisco (Ingress) Miami Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 59Call Admission  Session must first declare its QOS requirement and characterize the traffic it will send through the network  Rspec: defines the QOS being requested  Tspec: defines the traffic characteristics  A signaling protocol is needed to carry the Rspec and T spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 60Call Admission  Call Admission: routers will admit calls based on their Rspec and Tspec and base on the current resource allocated at the routers to other calls. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 61Summary: Basic RSVP Path Signaling  Reservation for simplex (unidirectional) flows  Ingress router initiates connection  ―Soft‖ state  Path and resources are maintained dynamically  Can change during the life of the RSVP session  Path message sent downstream  Resv message sent upstream PATH PATH PATH Sender Router Router Receiver RESV RESV RESV Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 62MPLS Extensions to RSVP  Path and Resv message objects Explicit Route Object (ERO) Label Request Object Label Object Record Route Object Session Attribute Object Tspec Object  For more detail on contents of objects: daftietfmplsrsvplsptunnel04.txt Extensions to RSVP for LSP Tunnels Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 63Explicit Route Object  Used to specify the explicit route RSVP Path messages take for setting up LSP  Can specify loose or strict routes Loose routes rely on routing table to find destination Strict routes specify the directlyconnected next router  A route can have both loose and strict components Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 64ERO: Strict Route  Next hop must be directly connected to previous hop Egress C E F LSR ERO B strict; C strict; E strict; D strict; F strict; A B D Ingress Strict LSR Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 65ERO: Loose Route  Consult the routing table at each hop to determine the best path: similar to IP routing option concept Egress C E F LSR ERO D loose; A B D Ingress Loose LSR Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 66ERO: Strict/Loose Path  Strict and loose routes can be mixed Egress C E F LSR ERO C strict; D loose; F strict; Strict A B D Ingress Loose LSR Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 67Label Objects  Label Request Object Added to PATH message at ingress LSR Requests that each LSR provide label to upstream LSR  Label Object Carried in RESV messages along return path upstream Provides label to upstream LSR Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 68Record Route Object— PATH Message  Added to PATH message by ingress LSR  Adds outgoing IP address of each hop in the path In downstream direction  Loop detection mechanism Sends ―Routing problem, loop detected‖ PathErr message Drops PATH message Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 69Session Attribute Object  Added to PATH message by ingress router  Controls LSP Priority Preemption Fastreroute  Identifies session ASCII character string for LSP name Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 70Adjacency Maintenance—Hello Message  New RSVP extension: leverage RSVP for hellos Hello message Hello Request Hello Acknowledge  Rapid node to node failure detection Asynchronous updates 3 second default update timer 12 second default dead timer Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 71Path Maintenance — Refresh Messages  Maintains reservation of each LSP  Sent every 30 seconds by default  Consists of PATH and RESV messages Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 72RSVP Message Aggregation  Bundles up to 30 RSVP messages within single PDU  Controls Flooding of PathTear or PathErr messages Periodic refresh messages (PATH and RESV)  Enhances protocol efficiency and reliability  Disabled by default Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 73Traffic Engineering: Constrained Routing Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 74Signaled vs Constrained LSPs  Common Features  Signaled by RSVP  MPLS labels automatically assigned  Configured on ingress router only  Signaled LSPs  CSPF not used (I.e. normal IP routing is used)  User configured ERO handed to RSVP for signaling  RSVP consults routing table to make next hop decision  Constrained LSPs  CSPF used  Full path computed by CSPF at ingress router  Complete ERO handed to RSVP for signaling Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 75Constrained Shortest Path First Algorithm  Modified ―shortest path first‖ algorithm  Finds shortest path based on IGP metric while satisfying additional QoS constraints  Integrates TED (Traffic Engineering Database)  IGP topology information  Available bandwidth  Link color  Modified by administrative constraints  Maximum hop count  Bandwidth  Strict or loose routing  Administrative groups Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 76Computing the ERO  Ingress LSR passes user defined restrictions to CSPF  Strict and loose hops  Bandwidth constraints  Admin Groups  CSPF algorithm  Factors in user defined restrictions  Runs computation against the TED  Determines the shortest path  CSPF hands full ERO to RSVP for signaling Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 77Summary: Key Benifits of MPLS  Goal: Lowoverhead virtual circuits for IP  Originally designed to make routers faster by leveraging ATM switch cores (bypasses IPoverATM overlay problems)  Fixed label lookup faster than longest match used by IP routing  Caveat: Not true anymore  IP forwarding has broken terabit/s speeds through innovative datastructures (next class)  PPPoverSONET (POS) provides a link layer  Value of MPLS is now purportedly in ―traffic engineering‖  Same forwarding mechanism can support multiple new services (eg: VoIP, VPNs etc)  Allows network resource optimization at the level of routing (eg: constrained based routing)  Allow survivability and fastreroute features…  Can be generalized for optical networks (GMPLS) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 78
Website URL
Comment