1 / 65

Optical core networks MPLS - advanced

Optical core networks MPLS - advanced. Piero Castoldi, Scuola Superiore Sant’Anna, castoldi@sssup.it. Outline. Introduction to Constraint based Routing and Traffic Engineering CR-LDP (Constraint-based Routing Label Distribution protocol)

sigourney-buckley
Download Presentation

Optical core networks MPLS - advanced

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. Optical core networksMPLS - advanced Piero Castoldi, Scuola Superiore Sant’Anna, castoldi@sssup.it

  2. Outline • Introduction to Constraint based Routing and Traffic Engineering • CR-LDP (Constraint-based Routing Label Distribution protocol) • RSVP-TE (Reservation protocol with Traffic Engineering Extensions) • MPLS Resilience Mechanisms CREDIT: some figures are taken from the presentation “MPLS tutorial” by Peter Ashwood-Smith Bilel N. Jamoussi

  3. Introduction to Explicit Routing and Traffic Engineering

  4. Partitioning IP Routing and MPLS Forwarding Based on: Classful Addr. Prefix? Classless Addr. Prefix? Multicast Addr.? Port No.? ToS Field? IP Routing OSPF, IS-IS, BGP, RIP Forwarding Table Forwarding Based on: Exact Match on Fixed Length Label MPLS • Current network has multiple forwarding paradigms • - classful longest prefix match (Class A,B,C boundaries) • - classless longest prefix match (variable boundaries) [when subnetting] • - multicast (exact match on source and destination) • - type-of-service (longest prefix. match on addr. + exact match on ToS) • Next generation routers will be based on hardware for route look-up • - changes will require new hardware with new algorithm • MPLS has a consistent algorithm for all types of forwarding; partitions routing/forwarding • domains and nicely allows to do traffic engineering

  5. Traffic Engineering B C Demand A D Traffic engineering is the process of mapping traffic demand onto a network Network Topology • Purpose of traffic engineering • Maximize utilization of links and nodes throughout the network • Engineer links to achieve required delay, grade-of-service • Spread the network traffic across network links to minimize impact of failure • Ensure available spare link capacity for re-routing traffic on failure • Meet policy requirements imposed by the network operator

  6. IP Follows a Tree to the Destination Dest=a.b.c.d Dest=a.b.c.d Dest=a.b.c.d - IP will over-utilize best paths and under-utilize not-so-good paths.

  7. Hop-by-hop LDP - Ultra fast, simple forwarding a.k.a switching - Follows same route as normal IP datapath - So like IP, LDP will over-utilize best paths and under-utilize less good paths. #216 #963 #14 #612 #462 #311 #99 #5

  8. Why explicited-routed LSP? #427 #216 #819 #77 #18 #963 #14 #612 #462 #311 #99 #5 • Two types of Label Switched Paths: • Hop by hop (LDP) • Explicit Routing (LDP+”ER”)

  9. Constraint-based Routing • Mechanism for LSP setup • To support Traffic Engineering Requirements • Based on Explicit Route (ER) • ER is a constraint • Various Constraints …. • Strict and Loose Explicit Routes • Traffic Characteristics of a path • Preemption • Route Pinning • Resource Class, ….

  10. How to implement constraint-based Routing (CR) • MPLS/LDP(Label Distribution Protocol) • Traffic Engineering Requirements • QoS Routing & Provisioning • Use ‘Explicit Routes’ (ER) for LSP setup • Two Solutions • CR-LDP: Extensions to LDP • RSVP Extensions: Extensions to RSVP

  11. Labels Distribution protocols (1) • MPLS Traffic Engineering tunnels (LSPs) are not limited to IP route selection procedures if explicit routing is used and thus will spread network traffic more uniformly across the backbone taking advantage of all available links. • A signaling protocol is required to set up these explicit MPLS routes or tunnels. • CR-LDP and RSVP-TE are both signaling mechanisms used to support Traffic Engineering across an MPLS network. • RSVP is a QoS signaling protocol that is an IETF standard and has existed for quite some time. • RSVP-TE extends RSVP to support label distribution and explicit routing • CR-LDP proposed to extend LDP (designed for hop-by-hop label distribution to support QoS signaling and explicit routing).

  12. Labels Distribution protocols (2) • There are many similarities between CR-LDP and RSVP-TE for constraint-based routing. • The Explicit Route Objects (ERO) that are used are extremely similar. • Both protocols use ordered Label Switched Path (LSP) setup procedures. • Both protocols include some QoS information in the signaling messages to enable resource allocation and LSP establishment to take place automatically. • At the present time CR-LDP development has ended and RSVP-TE has emerged as the preferred protocol for performing traffic engineering.

  13. CR-LDP Constrained based routing Label distribution protocol

  14. CR-LDP • CR-LDP is an extensions to LDP • LDP: for Best-Effort Services • Routing Protocol Information Only • CR-LDP: for QoS Services (Diffserv) • Routing Protocol + Constraints • CR-LSP is setup by Ingress LSR • How to find the Explicit Routes ? • By network provider • Based on various constraints • Currently, Unidirectional point-to-point CR-LSP

  15. Concept of Constraint-based Routing (CR) & & = Example: USE: (links with sufficient resources) AND (links of type “someColor”) AND (links that have delay less than 200 ms)

  16. CR-LSP • Constraint-based Routed LSP • is a path like any other LSP • But, CR-LSP is • Based on Explicit Routes • Based on Routing Table plus Constraints • initiated by Ingress LSR • for traffic load balancing & QoS routing

  17. Strict & Loose Routes • Explicit Route (ER) • ER consists of a list of ER-hops (or nodes) • ER is represented in a “Label Request” message • Strict ER-hop: one node • Loose ER-hop: a group of nodes • Subset of the nodes may be traversed by CR-LSP • This increases local flexibility for LSP setup • Allow imperfect information on a detailed path • Abstract Node : including strict & loose node • Thus, CR-LSP is a list of abstract nodes

  18. Other Constraints • Traffic Characteristic of a Path • Constraints on Bandwidth: peak rate, committed rate • Preemption • If a route with sufficient resource can not be found • Then existing path is preempted by the new path • Setup & Holding Priority for a path • Route Pinning (in a loose ER-hop) • Resource Classes (Colors) • Which resource class (link) can be used by CR-LSP ?

  19. Basic LDP Message additions provided in CR-LDP • Additional TLVs (Type-Length-Value) • Preemption TLV • LSPID: A unique tunnel identifier within an MPLS network. • ER: An explicit route, normally a list of IPV4 addresses to follow (source route) the label request message. • Resource Class (Class): to constrain the route to only links of this Class. Basically a 32 bit mask used for constraint based computations. • Traffic Parameters: similar to ATM call setup, which specify treatment and reserve resources.

  20. Constraint-based Routing using LDP (CR-LDP) • Built on existing LDP messages over TCP. • Defines an Explicit Route (ER): • An ER is a detailed path that can traverse any link supporting CR-LDP. • Defines a set of constraints for LSP computation and admission: • Expectation and Allocation of resources: • Peak burst & rate, Committed burst & rate, Excess burst, Frequency, Weight. • Preemption Level: • Setup and Holding Priority with respect to other LSPs. • Resource Class: • Color of traffic inclusion, exclusion rules for links.

  21. ER-LSP Setup using CR-LDP 2. Request message processed and next node determined. Path list modified to <C,D> 3. Request message terminates. 1. Label Request message. It contains ER path < B,C,D> 6. When LER A receives label mapping, the ER established. 5. LSR C receives label to use for sending data to LER D. Label table updated 4. Label mapping message originates. • Ordered, on-demand, explicited routed LSP setup LER A LSR B LSR C LER D ER Label Switched Path Ingress Egress

  22. Label Request Message • Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return Message ID TLV (mandatory) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPID TLV (CR-LDP, mandatory) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pinning TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Class TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pre-emption TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  23. Label Mapping Message • Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Request Message ID TLV (mandatory) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPID TLV (CR-LDP, mandatory) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  24. Explicit Route TLV • ER-TLV specifies the path to be taken by CR-LSP • ER-TLV is composed of one or more ER-Hop TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| ER-TLV (0x0800) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-Hop TLV 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-Hop TLV 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-Hop TLV n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  25. ER-Hop TLV • L bit: strict (0) or loose (1) ER-Hop • Four ER-Hop types are currently defined 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| ER-Hop-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Content // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value Type In Loose ER-Hop ----- --------------------- --------------- 0x801 IPv4 prefix prefix < 32 bit 0x802 IPv6 prefix prefix < 128 bit 0x803 Autonomous system number AS domain 0x804 LSPID tunnel ingress pt. (new CR-LSP, stacking)

  26. Traffic Parameters (1) • TLV Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Traf. Param. TLV (0x0810)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Frequency | Reserved | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate (PDR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Burst Size (PBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Data Rate (CDR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Burst Size (CBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Excess Burst Size (EBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  27. Traffic Parameters (2) • Flags (1 octet) • Each traffic parameter is Negotiable or not • Frequency (1 octet) • How often should ‘CDR’ be available for CR-LSP ? • Very Frequent, Frequent, Unspecified • Weight (1 octet) • Relative share of possible excess bandwidth • Weight of CR-LSP in terms of Resources • MPLS-domain specific

  28. Traffic Parameters (3) • Parameters • Peak Data Rate (PDR): peak rate • Peak Burst Size (PBS) • Committed Data Rate (CDR): mean rate • Committed Burst Size (CBS) • Excess Burst Size (EBS): the extent to exceed CDR • Peak Rate Token Bucket • PDR with PBS • Committed Rate Token Bucket • CDR with CBS and EBS

  29. Peak rate • The maximum rate at which traffic should be sent to the CR-LSP • Defined by a token bucket (bucket is continuously fed by tokens at a certain rate and each token allows the transit of an amount of packet segments) with parameters • Peak data rate (PDR) • Peak burst size (PBS) • May be unused by setting PDR or PBS or both to positive infinity

  30. Committed rate • The rate that the MPLS domain commits to be available to the CR-LSP • Defined by a token bucket with parameters • Committed data rate (CDR) • Committed burst size (CBS) • Committed rate is the bandwidth that should be reserved for the CR-LSP • CDR = 0 makes sense; CDR = + less • CBS describes the burstiness with which traffic may be sent to the CR-LSP

  31. Excess burst size • Measure the extent by which the traffic sent on a CR-LSP exceeds the committed rate • Defined as an additional limit on the committed rate • Can be useful for resource reservation • If a network uses the excess burst size for resource allocation then its edge function should regulate the parameter and perhaps mark or drop packets • EBS = 0 and EBS = + both make sense

  32. Frequency • The Frequency specifies at what granularity the CDR, allocated to the CR-LSP, is made available, i.e. how often the average statistics should be collected to do policing. • Constraints the variable delay that the network may introduce, it affects jitter of packets delivery • Constrains the amount of buffering that a LSR may use • Values: • Very frequently: no more than one packet may be buffered • Frequently: only a few packets may be buffered • Unspecified: a large amount of buffering is acceptable

  33. Weight • Specifies the CR-LSP’s weight in the “relative share algorithm” • Implied but not stated: • CR-LSPs with a larger weight get a bigger relative share of the “excess bandwidth” • Values: • 0 — the weight is not specified • 1-255 — weights; larger numbers are larger weights

  34. Negotiation flags If a parameter is flagged as negotiable then LSRs may replace the parameter value with a smaller value in the label request mess age. LSRs descover the Res F6 F5 F4 F3 F2 F1 negotiated values in the label mapping message. Label request - possible downward negotiation Weight Negotiation Flag CDR Negotiation Flag PDR Negotiation Flag CBS Negotiation Flag PBS Negotiation Flag EBS Negotiation Flag Label mapping - no negotiation

  35. Preemption TLV • Setup & holding Priority • 0 (most important path) • 7 (least important path) • Competition between ... • HoldPrio of “Old” LSP and SetPrio of “New” LSP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Preemption-TLV (0x0820) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SetPrio | HoldPrio | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  36. LSPpreemption (1) • A CR-LSP carries an LSP priority. This priority can be used to allow new LSPs to bump existing LSPs of lower priority in order to steal their resources. • This is especially useful during times of failure and allows you to rank the LSPs such that the most important obtain resources before less important LSPs. • These are called the setupPriority and a holdingPriority and 8 levels are provided.

  37. LSPpreemption (2) • When an LSP is established its setupPriority is compared with the holdingPriority of existing LSPs, any with lower holdingPriority may be bumped to obtain their resources. • This process may continue in a domino fashion until the lowest holdingPriority LSPs either clear or are on the worst routes.

  38. LSP preemption (3) Route={A,B,C} This LSP must be preempted. Now this one can proceed. #216 #14 #972 #462 B C A

  39. Topology database for bumping LOW PRI Topology Database sees 8 levels of bandwidth, depending on the setup priority of the LSP, a subset of that bandwidth is seen as available. The highest priority sees all bandwidth used and free at levels lower that it, etc. to the lowest priority which only sees unused bandwidth. HIGH PRI

  40. LSP-ID TLV • Unique identifier of a CR-LSP • LSP-ID is composed of • Ingress LSR ID • Locally unique CR-LSP ID within the Ingress LSR 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| LSPID-TLV (0x0821) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Local CRLSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress LSR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  41. Resource Class TLV • Resource Class defined in [TER] • Currently, 32 resource classes are defined • Which links (of 32) are acceptable by this CR-LSP ? • allows the network topology to be pruned • In particular, for “Loose ER-hop” 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| ResCls-TLV (0x0822) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RsCls | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  42. Route Pinning TLV • P bit • 1 : Route-pinning is requested • 0 : Route-pinning is not requested • When it is not desirable to change the path 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x823 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  43. Extension to RSVP, i.e. RSVP-TE (Reservation Protocol with Traffic Engineering Extensions)

  44. RSVP Extensions • Overview • Use of RSVP to establish ‘LSP tunnel’ • Functionality is almost the sane as CR-LDP • Requirements for Traffic Engineering • RSVP piggybacks Label Information • Additional RSVP Objects for Explicit Routing • Motivations • RSVP is a popular and mature technology • RSVP Flow: MPLS FEC • RSVP Signaling: Downstream on Demand

  45. Five New Objects • New objects are added to RSVP Path & Resv message • Similar functionality to CR-LDP, for example, • Label Request Object (in RSVP Path Message) • Label Request Message (in CR-LDP) Object name Applicable RSVP messages --------------- ------------------------ LABEL_REQUEST Path LABEL Resv EXPLICIT_ROUTE Path RECORD_ROUTE Path, Resv SESSION_ATTRIBUTE Path

  46. LSP Tunnel Operation • RSVP Path Message • Label_Request Object • Explicit_Route Object • Session_Attribute Object • additional control info.: preemption, priority, ... • Record_Route Object • error notification, loop detection, .. • RSVP Resv Message • Label Object • Record_Route Object • Sender receives information on the actual route

  47. Use of RSVP extensions for the creation of CR-LSP • RSVP was originally introduced to handle IntServ (management if single IP flows) • RSVP is a signaling protocol for applications to reserve resources by setting up state in hosts and routers • Protocol that can be easily extended with new fields .

  48. RSVP messages • RSVP has superseded CR-LDP thanks to easy extension implementation • Sent typically in UDP • PATH messages, sent downstream along the data path setting path state • RESV reservation requests sent by the receivers

  49. ER-LSP setup using RSVP-TE • TE (Traffic Engineering) extensions to RSVP • Built on RSVP messages over IP. • In RSVP, a source requests resources along a path. • Then the source regularly sends refresh messages to keep the reservations active. • Extensions to RSVP: • Explicit Route Object • Label Request • Label Object • Session Attribute • Record Route Object • Defines a set of constraints for LSP computation and admission: • Expectation and Allocation of resources: Uses Inserv-style reservations • Preemption Level: Setup and Holding Priority with respect to other LSPs.

  50. RSVP-TE message format

More Related