SlideShare a Scribd company logo

TRAFFIC-ENG MPLS mpls mpls mpls mpls .pdf

S
saifullucky7

The document outlines the requirements and mechanisms for MPLS Traffic Engineering (TE), detailing the use of link-state routing protocols for resource allocation and the calculation of paths using Constrained Shortest Path First (CSPF). It explains how RSVP operates within MPLS TE to reserve network resources, including the signaling of paths and reservations, handling of error messages, and the implementation of protections for links and nodes. Additionally, it discusses techniques for merging backup paths and managing traffic in the event of failures to ensure continuous data flow.

Technology
1 of 28
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Traffic-Eng MPLS
General Notes: 2 Link-State Routing Protocol: MPLS TE requires a link-state routing protocol (IS-IS or OSPF) for resource allocation information flooding through the network. Routers flood resource attributes to make them available at the headend router of the TE tunnel during LSP path computation. OSPF can use extended link attributes, creating an extended link- state database (TE database), which includes additional link attributes similar to Router LSAs. Opaque LSAs: Opaque LSAs are not flooded to routers that cannot process opaque information. Routers capable of processing opaque LSAs set the O-bit in the DBD packet’s Options field during the DBD exchange. Traffic Engineering LSA (TE LSA): The TE LSA, an opaque LSA, carries additional attributes related to TE links. Standard link- state database flooding mechanisms are used to distribute TE LSAs, which describe routers, point-to-point links, and connections to multi-access networks (similar to Router LSAs).
General Notes: 3 • 4) Types of TE LSAs: There are two types of Traffic Engineering LSAs (TE LSAs): 1. Router Address TLV (Type 1): Specifies the stable IP address (usually the Loopback interface) of the advertising router. 2- Link TLV (Type 2): Describes a TE link and is composed of several sub-TLVs that specify link attributes. These include: •Link Type: Indicates whether the link is point-to-point or multi- access. •Link ID: Identifies the other end of the link. For point-to-point links, this is the Router-ID of the neighbor. For multi-access links, it’s the IP address of the DR. •Local Interface IP Address: Specifies the IP address(es) of the interface corresponding to this link. Multiple addresses are listed if applicable. •Remote Interface IP Address: Specifies the IP address(es) of the neighbor’s interface. For multi-access links, this is set to 0.0.0.0. Traffic Engineering Metric: Specifies the link’s metric for TE purposes. It can differ from the OSPF metric and is configurable. Maximum Bandwidth: Specifies the maximum bandwidth available for use on this link. This can be configured or defaults to the interface bandwidth. Maximum Reservable Bandwidth: Specifies the maximum reservable bandwidth in the link’s direction. It is configurable. Unreserved Bandwidth: Specifies the total unreserved bandwidth at eight priority levels (0-7). Administrative Group (Resource/Link Color): A 4-byte bitmask assigned by the network administrator. Each set bit represents an administrative group. It’s configurable via the mpls traffic-eng attribute-flags command.
General Notes: 4 5. In regular SPF calculation, a router calculates the shortest paths to destinations based solely on the least metric (cost). 6. CSPF, used for TE tunnels, differs from SPF. It considers more than just link cost; it factors in bandwidth, link attributes, and administrative weight to calculate the best path to the tunnel tailend router. The headend router performs this calculation by eliminating links that don't meet the required bandwidth. The outcome is an ordered list of IP addresses representing the next-hop routers in the TE LSP. 7. CSPF takes the input from, both, user-specified path constraints and the information in TE database, before initiating the path computation. 8) So, the CSPF computes a path PE1-P2-P3-PE4 to setup a TE LSP to 3.3.3.3 on PE4 router. This information is passed to RSVP. 9) the CSPF calculation result is called ERO , this ERO is the path nodes or interface address , this ERO is then passed to the RSVP , the RSVP messages is now signaled according to the normal unicast routing table but the path is decided by CSPF ERO . 10) By default, MPLS TE uses TE metrics of the links to route TE tunnels. However, by default TE metrics are same as the IGP metrics. To change this default behaviour of using TE metrics of the links to route TE tunnels over to IGP, use
General Notes: 5 11.Tiebreakers in CSPF: In regular SPF, multiple equal-cost paths (ECMP) can be computed. However, CSPF always computes a single path. If two paths are equal, CSPF uses these rules to break the tie: • a. Choose the path with the largest minimum available bandwidth. b. Choose the path with the lowest hop count (fewest routers). c. If still tied, select a path at random. 12) Resource Reservation Protocol (RSVP) operation in MPLS TE: ================================================= Once CSPF is completed, the path needs to be signaled across the network to establish a TE LSP and to consume resources across that path. RSVP (protocol type 46) is used to reserve resource throughout the network. Extensions were made to RSVP to allow RSVP to carry MPLS labels and other TE specifics. RSVP tries to signal the TE tunnel along the path from headend to tailend LSR. RSVP needs to signal it to get the label information set up at each LSR. RSVP also reserves bandwidth along the path. RSVP messages are sent by the headend router to identify resource availability along the path.
RSVP Messages 6 • 1. RSVP PATH Message: • The RSVP PATH message is sent by the headend router after CSPF to signal the path to the network. It includes the following components: • SESSION: Carries Session Type (LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6), Tunnel Destination IP, Tunnel ID, and Extended Tunnel ID (usually Tunnel Source IP). • HOP: Contains the upstream LSR's interface IP (previous hop). • TIME VALUES: Refresh period (default 30,000 ms). • EXPLICIT ROUTE (ERO): Defines the path the MPLS TE tunnel takes, using IPv4 sub-objects with IP addresses. • LABEL REQUEST: Requests a label with Layer 3 Protocol ID (0x0800 for IPv4). • SESSION ATTRIBUTE: Includes LSP setup and holding priorities, and protection flags (link-protection, node-protection). Cisco IOS sets the SE style flag for Shared Explicit reservation. • SENDER TEMPLATE: Carries Tunnel Sender IP (Router-ID of headend) and LSP ID (changes with tunnel properties). • SENDER TSPEC: Defines traffic characteristics, including requested bandwidth for the LSP tunnel. • ADSPEC: Describes the reservation model for end-to-end service prediction. • Note: Setup and hold priorities are sent in RSVP Path messages in session attributes.
RSVP Messages 7 • 2. RSVP RESV Message: • The RSVP RESV message is sent by the TE tunnel tailend router to confirm the reservation request sent by the PATH message. It is responsible for label assignment for the LSP mapping to the TE tunnel. This process propagates upstream, where each hop assigns a local label and sends it back to the headend router. • SESSION: Same information as in the PATH message. • HOP: Contains the downstream LSR’s interface IP (next hop). • TIME VALUES: Refresh period (default 30,000 ms). • STYLE: Defines reservation styles: • Fixed Filter (FF): Creates a unique reservation per sender, assigning a separate label for each. • Wildcard Filter (WF): A shared reservation for all senders to a session, creating a multipoint-to-point LSP. • Shared Explicit (SE): Allows explicit sender specification, assigning different labels for each sender, creating a separate LSP per sender. • FLOWSPEC: Specifies QoS and tunnel bandwidth in bytes/sec. • FILTERSPEC: Contains the Tunnel Sender IP (Router-ID of headend) and LSP ID, similar to the SENDER TEMPLATE in the PATH message. • LABEL: Contains the label value used by PHOP for the tunnel.
RSVP Messages 8 • 3. RSVP Error Messages: • When resources requested for the RSVP session are unavailable, the router generates error messages and sends them back to the router that initiated the request. There are two types of RSVP error messages: PATHERR and RESVERR. • PATHERR: Sent upstream to the sender that caused the error. • RESVERR: Sent downstream. • ERROR SPEC: This object contains the Error Code and Error Value, which help to decode the error types. A common Error Code 00 indicates confirmation sent in response to receiving a confirmation object.
RSVP Messages 9 • 4. RSVP Tear Messages: • RSVP uses two types of tear messages: PATHTEAR and RESVTEAR. • PATHTEAR: Travels downstream towards all receivers from the point of initiation. • RESVTEAR: Travels upstream towards all senders. • These messages clear the reservation states on the router, allowing the router to reuse resources for other requests. Tear messages may be triggered by state timeouts or tunnel pre-emption. • Note: RECORD ROUTE: Adds the outgoing interface IP address to the RECORD ROUTE for tracking.
Operations of LSP Tunnels - Special Notes 10 1.PATH Message Handling: •The PATH message is sent to the next-hop (downstream) router, referred to as P2. •The P2 router performs admission control, ensuring that the requested bandwidth is available. •If admission control succeeds, the P2 router generates a new PATH message and sends it to the next-hop in the ERO (Explicit Route Object). •P2 router tracks the interface from which the PATH message was received. 2.RESV Message Handling: •The PE4 router, upon recognizing that it is the destination for the PATH message, responds with a RESV message. •During the RESV message generation, PE4 begins the label allocation process. •PE4 assigns an explicit-null label (label value 0) to the LSP tunnel, which the upstream router (P3) will use to forward packets to PE4. This label is included in the LABEL object of the RESV message. •The RESV message is sent back along the reverse path of the ERO in the PATH message. •The RECORD ROUTE object is initialized, adding the outgoing interface IP address of PE4. •The explicit-null label is interpreted as an implicit-null label (label value 3) at both the tailend (PE4) and penultimate-hop (P3) routers. •To modify this default behavior, the command mpls traffic-eng signalling advertise implicit-null can be used on the tailend router.
Operations of LSP Tunnels - Special Notes 11 14. Routing Traffic Inside TE Tunnels 1.Using Static Route: • Traffic can be routed through a TE tunnel by configuring static routes that point to the tunnel endpoint. 2.Using Policy-based Routing: • Policy-based routing (PBR) can be applied to direct traffic over a specific TE tunnel based on defined policies such as source/destination IP or protocol type. 3.Autoroute Announce: • The Autoroute Announce feature enables the headend router to announce the TE tunnel as a route. This method does not modify the topology database on other routers in the network. 4.Forwarding Adjacency: • A bi-directional LSP (Label Switched Path) is set up, and adjacency is formed over the TE tunnel. This allows the router to forward traffic using the tunnel. Note: •Forwarding Adjacency requires the ip ospf 1 area 0 command under the tunnel configuration in IOS-XE to advertise the tunnel as a link in the OSPF database. However, this command is not needed in IOS-XR for the same functionality.
Operations of LSP Tunnels - Special Notes 12 15. Link Protection for MPLS TE Tunnels 1.Link Protection Overview: •Link protection ensures that traffic being forwarded on an LSP can still reach its destination if a link in the LSP fails. Abackup tunnel is established to route traffic around the failed link. 2.Operation During Link Failure: •When a link (e.g., P2-P4) fails, traffic for the primary TE tunnel is rerouted through a backup tunnel around the failed link and reaches the destination (e.g., PE5). •The router where traffic is switched from the main path to the backup path is called the Point of Local Repair (PLR). •The router where traffic merges back from the backup path to the main path is called the Merge Point (MP). 3.Before Link Failure: •3.1) Backup Path Readiness: The backup path must be precomputed and signaled before any link failure to ensure traffic can be rerouted smoothly. •3.2) Tunnel Configuration: On the headend router, enable the following command under the tunnel interface to prepare the system for link protection: bash tunnel mpls traffic-eng fast-reroute •3.3) RSVP PATH Signaling: When PE1 signals the RSVP PATH messages for the TE tunnel, it sets the local protection desired flag in the Session_Attribute object, indicating the need for protection along the entire path to PE5. •3.4) Backup Tunnel Preconfiguration: On the PLR, the backup tunnel must be preconfigured. Use the following command on the interface facing the backup tunnel: bash mpls traffic-eng backup-path Tunnel 100 •3.5) CSPF for Protection Path: The PLR router runs a CSPF (Constrained Shortest Path First) calculation to find an alternate path to the MP router, avoiding the failed link (P2-P4). The backup path is configured similarly to a regular MPLS TE tunnel using RSVP.
Operations of LSP Tunnels - Special Notes 13 3.6 Techniques for Merging Traffic from Backup Path to Protected Path at the Merge Point (MP) There are two techniques for handling the merging of traffic from a backup path to the protected path at the MP: 3.6.1 Facility Backup (N:1) •In Facility Backup, traffic arriving over the backup tunnel at the MP uses the same label as it would have if it had arrived over the failed (or protected) link. •To achieve this, the PLR pushes an extra label of the backup tunnel onto the label stack of the main tunnel. •Additionally, the P4 router advertises an implicit-null label to P3, enabling penultimate-hop popping (PHP) for the backup tunnel label before the MP. •This technique allows multiple LSPs crossing the protected link (P2-P4) to be protected by a single backup tunnel, making it an N:1 backup mechanism (one backup tunnel for multiple LSPs). •Cisco IOS supports this technique. 3.6.2 One-to-One Backup (1:1) •In One-to-One Backup, traffic arriving at the MP uses a different label than the one used by the main path. •No extra label is pushed into the label stack by the PLR in this case. •A separate backup tunnel is required for each LSP to ensure traffic is handled independently. •This technique results in a 1:1 backup mechanism (one backup tunnel for each LSP).
Operations of LSP Tunnels - Special Notes 14 4) After Link Failure:The backup path plays a crucial role in maintaining traffic flow for LSPs when a link failure occurs, allowing the network to continue forwarding traffic while the headend router computes a new path avoiding the failed link. Here's how the process unfolds: PLR Notification of Link Failure: The Point of Local Repair (PLR) router (P2 in this case) detects the link failure. The PLR notifies the headend router (PE1) about the failure. This notification is sent using an RSVP PATH Error message.
Operations of LSP Tunnels - Special Notes 15 16) Node Protection for MPLS TE Tunnels: Node protection (also called NNHOP or Next Next-Hop FRR) provides protection for MPLS TE tunnels, covering not only link failures but also node failures. This ensures that if a node along the path fails, traffic can be rerouted via a backup path. 1) Before Failure: Backup Path Configuration: The backup path is preconfigured to ensure traffic is rerouted when a failure occurs. In the case of a failure at node P4, the backup path from P2 to P5 (via P2-P3-P5) is established, avoiding P4. The backup path uses CSPF to compute a route, and RSVP PATH & RESV messages are sent to form the tunnel. 2) Enabling Node Protection: On the headend router (PE1), node protection is enabled using the command:tunnel mpls traffic-eng fast-reroute node-protect ensures that protection is available in case of node failure.
Operations of LSP Tunnels - Special Notes 16 1.RSVP PATH Message: 1. When PE1 signals the RSVP PATH message, it sets the node protection desired flag and label recording desired flag in the Session_Attribute object. 2. The label recording flag ensures that label information is included in the RSVP Record Route (RRO) sub-object, specifically in the Label sub-object. 3. This allows the Point of Local Repair (PLR) to know which labels should be used for rerouting traffic. By pre-configuring the backup paths and enabling node protection, the network can rapidly respond to failures in both links and nodes, ensuring continuous traffic flow with minimal disruption
Operations of LSP Tunnels - Special Notes 17 16) Node Protection for MPLS TE Tunnels (Continued): 4) Router Behavior When Node Protection is Desired: •When P2 router (which also acts as the Point of Local Repair or PLR) receives the RSVP PATH message from PE1 router, it identifies that node protection is requested. •The P2 router sets the Local Protection Available flag in the Record Route Object (RRO) and sends the PATH message along the defined path towards PE6 router. •As the message propagates, all routers along the path (including P2) are aware that node protection is available at P2 router. •PE1 router is not yet aware of the protection availability at this stage. 5) Path Setup with RESV Message: •PE router agrees to set up the path and responds by sending an RSVP RESV message towards PE1 router. This message includes the Label for the tunnel inside the Label object. •As the RESV message arrives at P2 router, it further processes the message by: •Sending the RESV message to PE1 router with the Local Protection Available flag set in the RRO object. •Additionally, P2 router includes the node-id flag in the RESV message for 2.2.2.2/32, indicating that node protection is available at this specific node. This mechanism ensures that the PLR (P2 router) and the rest of the routers in the network are aware that node protection has been successfully configured, and the path is protected in case of a node failure. The protection status is propagated through the RRO and RESV messages, ensuring that all routers along the path are prepared to reroute traffic in case of failure.
Operations of LSP Tunnels - Special Notes 18 3) After Failure 1.Similar to the link protection mechanism, when the P2 router detects the failure of the P4 router (or the link connecting P2 to P4), it suppresses any event notifications to the PE1 router to prevent the teardown of the LSP. Instead, the P2 router sends a Path Error message to the PE1 router with a Notify error code, a Tunnel Locally Repaired sub-code, and details about the node where the error was detected. The outbound FRR status on the P2 router changes to Active. 2.Upon receiving the Path Error message from the P2 router, the PE1 router recognizes the change in resources and sends out a PATH message to re-route traffic to an alternate path. It then receives a RESV message with a different path in the RRO, indicating a failover to the backup path. 3.In summary, node protection provides resilience against both link and node failures. Label recording is essential because the PLR must know the label that the MP expects the traffic to arrive with.
Operations of LSP Tunnels - Special Notes 19 Example: ======== Node Protection: ================ label 30 label 20 R1--------------R2-------------R3----------R5 R1--------------------R4---------------R5 label 50 WHEN R2 fails , how R1 Knows about label assign from R3 to R2 ( label 20 ) ? R1 will Know the label in the RRO , then R1 will send the traffic with label 50 ( backup tunnel and label 20 ) label 20 which is known to R1 by the RRO check point in Link Protection: =================== there is no need for R1 to Know this label because traffic will be directed already to R2 which already Know the label 20
Operations of LSP Tunnels - Special Notes 20 17) Interarea TE tunnels : 1- One of the limitations of TE LSP paths is that they are computed for a single IGP area only, due to the lack of visibility into the topology of other IGP areas. In OSPF, the ABR hides the topology between two areas. This poses a challenge in large networks where multiple IGP areas are deployed or in cases where the network spans multiple service providers. This scenario is often referred to as interdomain traffic engineering. 2- Consider a network with three OSPF areas where an MPLS TE tunnel must be established from PE1 to PE2. Since PE1 and PE2 reside in different areas, PE1 lacks the necessary information to compute an end-to-end path that satisfies TE constraints. Once a path is computed, signaling is carried out as usual, even across areas or autonomous systems (ASs). 3- MPLS traffic engineering across areas is supported only within a single domain because the MPLS TE Router ID is advertised only within a single area. A second area cannot establish a tunnel with a route marked as "OIA" (inter-area). 3-1 To set up an RSVP-signaled TE LSP, three steps are required: Path computation Resource reservation Label distribution 3-2 Autoroute announce cannot be used for inter-AS traffic engineering, nor can autoroute destination.
Operations of LSP Tunnels - Special Notes 21 • 3.2.1. Contiguous LSP: (Typically used in inter-area and interdomain scenarios, but only when RSVP is deployed in both domains and areas) • In this method, an end-to-end LSP is established between PE1 and PE2 using hop-by-hop signaling between adjacent neighbors. Both loose and strict hops can be defined: • Loose hops indicate the ABR, specifying that some details of the route are left to the ABR's discretion. • In this case, there is no direct link between the ABR and its area, but MPLS traffic engineering ensures the path is known. 3.1. Gathering TE Information: Link information is carried in the same way as in regular MPLS TE. OSPF Opaque LSA Type 10 (TE LSAs) are used to advertise link-specific details such as link type, maximum reservable bandwidth, unreserved bandwidth, TE metric, attribute flags, and more. 3.2. Path Setup: Path setup is discussed before path computation because understanding how a path is set up is essential. For interdomain TE, there are three methods to set up an LSP:
Operations of LSP Tunnels - Special Notes 22 3.2.2. LSP Stitching: (Typically used in inter-area and interdomain scenarios where RSVP and SR are deployed across different domains or areas) Smaller TE LSPs are established within individual areas or domains and then stitched together to form an end-to-end LSP. Each smaller LSP is mapped with a 1:1 relationship, often represented using Binding SIDs in SR environments. In interdomain scenarios, there must be a link between the two ASBRs, and it must be part of the MPLS Traffic Engineering Database (TED). Additionally, the link between the two ASBRs must be configured with ASBR Forced Link Flooding when RSVP is used.
Operations of LSP Tunnels - Special Notes 23 3.3. Path Computation for Contiguous LSP: 1.For contiguous LSPs, the exit points out of the areas (or domains) must be known. The headend router (PE1) does not have visibility of the entire path of the LSP. Instead, the path to the next border router (e.g., ABR1) is computed, added to the Explicit Route Object (ERO), and the LSP is signaled. Thus, the path is computed per-domain. •In per-domain path computation, the path is computed separately within each domain, from one border router to the next. •The IP addresses of the border routers must be known to the LSP headend. •The headend router defines the path explicitly because it cannot dynamically compute the end-to-end path. Border routers are configured as loose hops, meaning the path to these border routers (e.g., ABR1) can be dynamically found. After reaching ABR1, the next path to ABR2 is computed by ABR1 and added to the ERO object in a process known as ERO Expansion. Each border router (ABR) runs constrained SPF (cSPF) to compute a path to the next border router that satisfies user-defined constraints. 2.Key Observations: •Loose hops for ABRs: The ABRs are configured as loose hops in the headend router. •Strict hops in ERO: While ABR1 (2.2.2.2) is configured as a loose hop, the ERO carries it as a strict hop because PE1 can compute a path to ABR1 directly. •Loose hops for ABR2: ABR2 (3.3.3.3) is carried as a loose hop in the ERO because PE1 lacks link information for the path to 3.3.3.3. Therefore, ABR1 is responsible for computing the path to ABR2. 3.At ABR1, all IP addresses leading to ABR2 are included as strict hops in the ERO object. 4.At ABR2, the router dynamically computes the path to the final destination (e.g., PE2).
Operations of LSP Tunnels - Special Notes 24 6) Crank back: In regular MPLS TE within a single IGP area, RSVP PathErr messages provide the headend router with necessary information in case of an LSP failure, such as resource unavailability on a specific link. However, when the failure involves a link in a different area than the headend router, this information is less meaningful for the headend router. Example Scenario: If the link between ABR2 and PE2 is unavailable, sending an error message back to the PE1 router serves little purpose. Instead, this error message is more relevant to ABR2, as it can attempt to compute an alternate path within Area 2 that avoids the ABR2-PE2 link. 1.ABR2 Attempts an Alternate Path: 1. ABR2 tries to identify an alternative path, possibly through another border router, such as ABR3. 2. If the ABR2-ABR3 link is operational, the LSP can be rerouted through ABR3 to reach PE2. 2.Escalation to ABR1 if No Alternative Exists: 1. If the ABR2-ABR3 link is also unavailable, ABR2 cannot find an alternative path. 2. In this case, the error is escalated upstream to ABR1. ABR1 then assumes the responsibility of finding a new path that avoids ABR2 entirely. This process, where error messages are forwarded upstream to identify alternative paths, is known as crankback. It ensures that routing adjustments are made closer to the point of failure, reducing the impact on the headend router and improving the network's ability to recover from failures.
Operations of LSP Tunnels - Special Notes 25 7) ASBR Forced Link Flooding: When forced link flooding is configured on an interface, the MPLS TE link management module advertises the link to all nodes. This advertisement updates the TE topology database on all nodes within the inter-AS environment with the link's information. Key Features: 1.Advertisement Without IGP Adjacencies: ASBR forced link flooding enables the advertisement of links even when IGP adjacencies are not established on those links. 1. TE LSPs can traverse such links between two nodes running BGP (or static routes), even if the exit ASBR is not explicitly listed in the IP explicit path. 2. This allows a headend LSR to consider these links during TE LSP path computation. 2.Activation: To enable ASBR forced link flooding: 1. Configure the link as passive. 2. Provide neighbor information, such as the neighbor IGP ID and the neighbor TE ID. 3.Link-State Advertisement: 1. OSPF uses opaque LSA Type 10 to flood TE link information across the network. ASBR forced link flooding ensures comprehensive visibility of inter-AS TE links, facilitating efficient LSP path computation and traversal, even in scenarios without direct IGP adjacencies.
Operations of LSP Tunnels - Special Notes 26 ASBR Links Configuration interface GigabitEthernet2 ip address 10.8.5.5 255.255.255.0 negotiation auto mpls traffic-eng tunnels mpls traffic-eng administrative-weight 20 mpls traffic-eng passive-interface nbr-te-id 10.0.0.8 nbr-if-addr 10.8.5.8 nbr-igp-id ospf 10.0.0.8 no mop enabled no mop sysid end
Operations of LSP Tunnels - Special Notes 27 Notes: 1.No Stitching Between RSVP & RSVP: 1. Stitching is only supported between SR and RSVP. 2. In RSVP, labels cannot be added to the explicit path, whereas in Segment Routing (SR), we can insert a Binding SID of an RSVP tunnel. 3. Therefore, stitching is not possible in inter-area MPLS Traffic Engineering (TE) tunnels, and only contiguous LSPs can be used. 2.No Stitching in Interdomain MPLS Traffic Engineering: 1. Stitching is only needed between RSVP and SR. 2. Interdomain MPLS TE does not support stitching between RSVP tunnels. 3.ASBR Forced Link Required in Interdomain MPLS Traffic Engineering: 1. For interdomain MPLS Traffic Engineering, ASBR Forced Link Flooding is necessary between the two ASBRs. 2. This ensures the visibility of links for TE across domain boundaries. 4.Check LAP for Inter-AS & Inter-Area Traffic Engineering: 1. It's important to review LAP (Link Aggregation Protocol) for proper integration and configuration in Inter-AS and Inter-Area Traffic Engineering scenarios. 5.Cannot Use Autoroute Announce for Inter-AS Traffic Engineering: 1. Autoroute announce and auto-route destination cannot be used for inter-AS traffic engineering. 2. These features are not compatible with inter-domain TE scenarios and require manual configuration of explicit routing.
Operations of LSP Tunnels - Special Notes 28 TE Attributes TE (Traffic Engineering) attributes are parameters used to manage and control traffic flow within a network. They help determine path selection, resource allocation, and Quality of Service (QoS) for various traffic flows. Common TE attributes include: 1.Bandwidth: Represents the link or path capacity, typically measured in bits per second (bps). It indicates the maximum data transfer rate and is critical for path selection and resource reservation. 2.Link Metrics: Numerical values assigned to links that determine the cost or preference of a path. These metrics can be based on factors like bandwidth, delay, jitter, and packet loss, guiding the algorithm to select the best path. 3.Administrative Groups: Links are grouped based on administrative policies. These groups influence path selection, with certain links prioritized or reserved for specific types of traffic. 4.Affinity: Represents specific requirements or characteristics of a traffic flow, such as application or service level. Affinity values help ensure traffic flows are assigned to paths that meet their needs. 5.Constraints: Conditions like maximum delay, minimum bandwidth, or specific routing requirements that paths must satisfy. Constraints ensure selected paths meet necessary criteria. 6.Preemption: Defines whether lower-priority traffic can be preempted by higher-priority flows. This attribute helps optimize resource usage and manage QoS by reallocating resources when necessary.

More Related Content

Similar to TRAFFIC-ENG MPLS mpls mpls mpls mpls .pdf (20)

PDF
PLNOG 7: Rafał Szarecki - MPLS in an advanced version
PROIDEA
 
PPT
Mpls
rahulvce07
 
PDF
mpls.pdf
Huynh MVT
 
PDF
mpls-05
kj teoh
 
PDF
Segment Routing: A Tutorial
APNIC
 
PPT
Sl3c3
FNian
 
PDF
Segment Routing
APNIC
 
PPTX
Introduction to MPLS - NANOG 61
Richard Steenbergen
 
PPT
Mpls Services
Kristof De Brouwer
 
PPTX
MENOG-Segment Routing Introduction
Rasoul Mesghali, CCIE RS
 
PPT
Mpls-Multi Protocol label Switching
Sumit Pathak
 
PDF
MPLS Concepts and Fundamentals
Shawn Zandi
 
PDF
mplste-130112120119-phpapp02.pdf
Huynh MVT
 
PDF
PLNOG 13: Julian Lucek: Centralized Traffic Enginnering
PROIDEA
 
PPT
MPLS_TEFGREGERGDFSGERTGERGRFGERGERGRG.ppt
ajaiesg
 
PPT
Pot for getting to learn the basics of mpls
amit347423
 
PDF
MPLS Lecture1(H)-102020.pdf
MulugetaTsehay1
 
PDF
MPLS Tutorial2
kennedy Ochieng Ndire
 
PDF
MPLS Tutorial
kennedy Ochieng Ndire
 
PPT
MPLS RSVP-TE Auto-Bandwidth - Practical Lessons Learned
Richard Steenbergen
 
PLNOG 7: Rafał Szarecki - MPLS in an advanced version
PROIDEA
 
Mpls
rahulvce07
 
mpls.pdf
Huynh MVT
 
mpls-05
kj teoh
 
Segment Routing: A Tutorial
APNIC
 
Sl3c3
FNian
 
Segment Routing
APNIC
 
Introduction to MPLS - NANOG 61
Richard Steenbergen
 
Mpls Services
Kristof De Brouwer
 
MENOG-Segment Routing Introduction
Rasoul Mesghali, CCIE RS
 
Mpls-Multi Protocol label Switching
Sumit Pathak
 
MPLS Concepts and Fundamentals
Shawn Zandi
 
mplste-130112120119-phpapp02.pdf
Huynh MVT
 
PLNOG 13: Julian Lucek: Centralized Traffic Enginnering
PROIDEA
 
MPLS_TEFGREGERGDFSGERTGERGRFGERGERGRG.ppt
ajaiesg
 
Pot for getting to learn the basics of mpls
amit347423
 
MPLS Lecture1(H)-102020.pdf
MulugetaTsehay1
 
MPLS Tutorial2
kennedy Ochieng Ndire
 
MPLS Tutorial
kennedy Ochieng Ndire
 
MPLS RSVP-TE Auto-Bandwidth - Practical Lessons Learned
Richard Steenbergen
 

Recently uploaded (20)

PDF
Impact of IEEE Computer Society in Advancing Emerging Technologies including ...
Hironori Washizaki
 
PPTX
Building and Operating a Private Cloud with CloudStack and LINBIT CloudStack ...
ShapeBlue
 
PDF
DevBcn - Building 10x Organizations Using Modern Productivity Metrics
Justin Reock
 
PDF
Productivity Management Software | Workstatus
Lovely Baghel
 
PDF
CIFDAQ Weekly Market Wrap for 11th July 2025
CIFDAQ
 
PDF
CloudStack GPU Integration - Rohit Yadav
ShapeBlue
 
PDF
Windsurf Meetup Ottawa 2025-07-12 - Planning Mode at Reliza.pdf
Pavel Shukhman
 
PDF
Complete JavaScript Notes: From Basics to Advanced Concepts.pdf
haydendavispro
 
PDF
Upskill to Agentic Automation 2025 - Kickoff Meeting
DianaGray10
 
PDF
HR agent at Mediq: Lessons learned on Agent Builder & Maestro by Tacstone Tec...
UiPathCommunity
 
PDF
TrustArc Webinar - Data Privacy Trends 2025: Mid-Year Insights & Program Stra...
TrustArc
 
PDF
Arcee AI - building and working with small language models (06/25)
Julien SIMON
 
PDF
Building Resilience with Digital Twins : Lessons from Korea
SANGHEE SHIN
 
PDF
Wojciech Ciemski for Top Cyber News MAGAZINE. June 2025
Dr. Ludmila Morozova-Buss
 
PDF
HCIP-Data Center Facility Deployment V2.0 Training Material (Without Remarks ...
mcastillo49
 
PDF
Shuen Mei Parth Sharma Boost Productivity, Innovation and Efficiency wit...
AWS Chicago
 
PPT
Interview paper part 3, It is based on Interview Prep
SoumyadeepGhosh39
 
PDF
Why Orbit Edge Tech is a Top Next JS Development Company in 2025
mahendraalaska08
 
PDF
Upgrading to z_OS V2R4 Part 01 of 02.pdf
Flavio787771
 
PDF
Novus-Safe Pro: Brochure-What is Novus Safe Pro?.pdf
Novus Hi-Tech
 
Impact of IEEE Computer Society in Advancing Emerging Technologies including ...
Hironori Washizaki
 
Building and Operating a Private Cloud with CloudStack and LINBIT CloudStack ...
ShapeBlue
 
DevBcn - Building 10x Organizations Using Modern Productivity Metrics
Justin Reock
 
Productivity Management Software | Workstatus
Lovely Baghel
 
CIFDAQ Weekly Market Wrap for 11th July 2025
CIFDAQ
 
CloudStack GPU Integration - Rohit Yadav
ShapeBlue
 
Windsurf Meetup Ottawa 2025-07-12 - Planning Mode at Reliza.pdf
Pavel Shukhman
 
Complete JavaScript Notes: From Basics to Advanced Concepts.pdf
haydendavispro
 
Upskill to Agentic Automation 2025 - Kickoff Meeting
DianaGray10
 
HR agent at Mediq: Lessons learned on Agent Builder & Maestro by Tacstone Tec...
UiPathCommunity
 
TrustArc Webinar - Data Privacy Trends 2025: Mid-Year Insights & Program Stra...
TrustArc
 
Arcee AI - building and working with small language models (06/25)
Julien SIMON
 
Building Resilience with Digital Twins : Lessons from Korea
SANGHEE SHIN
 
Wojciech Ciemski for Top Cyber News MAGAZINE. June 2025
Dr. Ludmila Morozova-Buss
 
HCIP-Data Center Facility Deployment V2.0 Training Material (Without Remarks ...
mcastillo49
 
Shuen Mei Parth Sharma Boost Productivity, Innovation and Efficiency wit...
AWS Chicago
 
Interview paper part 3, It is based on Interview Prep
SoumyadeepGhosh39
 
Why Orbit Edge Tech is a Top Next JS Development Company in 2025
mahendraalaska08
 
Upgrading to z_OS V2R4 Part 01 of 02.pdf
Flavio787771
 
Novus-Safe Pro: Brochure-What is Novus Safe Pro?.pdf
Novus Hi-Tech
 
Ad

TRAFFIC-ENG MPLS mpls mpls mpls mpls .pdf

  • 2. General Notes: 2 Link-State Routing Protocol: MPLS TE requires a link-state routing protocol (IS-IS or OSPF) for resource allocation information flooding through the network. Routers flood resource attributes to make them available at the headend router of the TE tunnel during LSP path computation. OSPF can use extended link attributes, creating an extended link- state database (TE database), which includes additional link attributes similar to Router LSAs. Opaque LSAs: Opaque LSAs are not flooded to routers that cannot process opaque information. Routers capable of processing opaque LSAs set the O-bit in the DBD packet’s Options field during the DBD exchange. Traffic Engineering LSA (TE LSA): The TE LSA, an opaque LSA, carries additional attributes related to TE links. Standard link- state database flooding mechanisms are used to distribute TE LSAs, which describe routers, point-to-point links, and connections to multi-access networks (similar to Router LSAs).
  • 3. General Notes: 3 • 4) Types of TE LSAs: There are two types of Traffic Engineering LSAs (TE LSAs): 1. Router Address TLV (Type 1): Specifies the stable IP address (usually the Loopback interface) of the advertising router. 2- Link TLV (Type 2): Describes a TE link and is composed of several sub-TLVs that specify link attributes. These include: •Link Type: Indicates whether the link is point-to-point or multi- access. •Link ID: Identifies the other end of the link. For point-to-point links, this is the Router-ID of the neighbor. For multi-access links, it’s the IP address of the DR. •Local Interface IP Address: Specifies the IP address(es) of the interface corresponding to this link. Multiple addresses are listed if applicable. •Remote Interface IP Address: Specifies the IP address(es) of the neighbor’s interface. For multi-access links, this is set to 0.0.0.0. Traffic Engineering Metric: Specifies the link’s metric for TE purposes. It can differ from the OSPF metric and is configurable. Maximum Bandwidth: Specifies the maximum bandwidth available for use on this link. This can be configured or defaults to the interface bandwidth. Maximum Reservable Bandwidth: Specifies the maximum reservable bandwidth in the link’s direction. It is configurable. Unreserved Bandwidth: Specifies the total unreserved bandwidth at eight priority levels (0-7). Administrative Group (Resource/Link Color): A 4-byte bitmask assigned by the network administrator. Each set bit represents an administrative group. It’s configurable via the mpls traffic-eng attribute-flags command.
  • 4. General Notes: 4 5. In regular SPF calculation, a router calculates the shortest paths to destinations based solely on the least metric (cost). 6. CSPF, used for TE tunnels, differs from SPF. It considers more than just link cost; it factors in bandwidth, link attributes, and administrative weight to calculate the best path to the tunnel tailend router. The headend router performs this calculation by eliminating links that don't meet the required bandwidth. The outcome is an ordered list of IP addresses representing the next-hop routers in the TE LSP. 7. CSPF takes the input from, both, user-specified path constraints and the information in TE database, before initiating the path computation. 8) So, the CSPF computes a path PE1-P2-P3-PE4 to setup a TE LSP to 3.3.3.3 on PE4 router. This information is passed to RSVP. 9) the CSPF calculation result is called ERO , this ERO is the path nodes or interface address , this ERO is then passed to the RSVP , the RSVP messages is now signaled according to the normal unicast routing table but the path is decided by CSPF ERO . 10) By default, MPLS TE uses TE metrics of the links to route TE tunnels. However, by default TE metrics are same as the IGP metrics. To change this default behaviour of using TE metrics of the links to route TE tunnels over to IGP, use
  • 5. General Notes: 5 11.Tiebreakers in CSPF: In regular SPF, multiple equal-cost paths (ECMP) can be computed. However, CSPF always computes a single path. If two paths are equal, CSPF uses these rules to break the tie: • a. Choose the path with the largest minimum available bandwidth. b. Choose the path with the lowest hop count (fewest routers). c. If still tied, select a path at random. 12) Resource Reservation Protocol (RSVP) operation in MPLS TE: ================================================= Once CSPF is completed, the path needs to be signaled across the network to establish a TE LSP and to consume resources across that path. RSVP (protocol type 46) is used to reserve resource throughout the network. Extensions were made to RSVP to allow RSVP to carry MPLS labels and other TE specifics. RSVP tries to signal the TE tunnel along the path from headend to tailend LSR. RSVP needs to signal it to get the label information set up at each LSR. RSVP also reserves bandwidth along the path. RSVP messages are sent by the headend router to identify resource availability along the path.
  • 6. RSVP Messages 6 • 1. RSVP PATH Message: • The RSVP PATH message is sent by the headend router after CSPF to signal the path to the network. It includes the following components: • SESSION: Carries Session Type (LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6), Tunnel Destination IP, Tunnel ID, and Extended Tunnel ID (usually Tunnel Source IP). • HOP: Contains the upstream LSR's interface IP (previous hop). • TIME VALUES: Refresh period (default 30,000 ms). • EXPLICIT ROUTE (ERO): Defines the path the MPLS TE tunnel takes, using IPv4 sub-objects with IP addresses. • LABEL REQUEST: Requests a label with Layer 3 Protocol ID (0x0800 for IPv4). • SESSION ATTRIBUTE: Includes LSP setup and holding priorities, and protection flags (link-protection, node-protection). Cisco IOS sets the SE style flag for Shared Explicit reservation. • SENDER TEMPLATE: Carries Tunnel Sender IP (Router-ID of headend) and LSP ID (changes with tunnel properties). • SENDER TSPEC: Defines traffic characteristics, including requested bandwidth for the LSP tunnel. • ADSPEC: Describes the reservation model for end-to-end service prediction. • Note: Setup and hold priorities are sent in RSVP Path messages in session attributes.
  • 7. RSVP Messages 7 • 2. RSVP RESV Message: • The RSVP RESV message is sent by the TE tunnel tailend router to confirm the reservation request sent by the PATH message. It is responsible for label assignment for the LSP mapping to the TE tunnel. This process propagates upstream, where each hop assigns a local label and sends it back to the headend router. • SESSION: Same information as in the PATH message. • HOP: Contains the downstream LSR’s interface IP (next hop). • TIME VALUES: Refresh period (default 30,000 ms). • STYLE: Defines reservation styles: • Fixed Filter (FF): Creates a unique reservation per sender, assigning a separate label for each. • Wildcard Filter (WF): A shared reservation for all senders to a session, creating a multipoint-to-point LSP. • Shared Explicit (SE): Allows explicit sender specification, assigning different labels for each sender, creating a separate LSP per sender. • FLOWSPEC: Specifies QoS and tunnel bandwidth in bytes/sec. • FILTERSPEC: Contains the Tunnel Sender IP (Router-ID of headend) and LSP ID, similar to the SENDER TEMPLATE in the PATH message. • LABEL: Contains the label value used by PHOP for the tunnel.
  • 8. RSVP Messages 8 • 3. RSVP Error Messages: • When resources requested for the RSVP session are unavailable, the router generates error messages and sends them back to the router that initiated the request. There are two types of RSVP error messages: PATHERR and RESVERR. • PATHERR: Sent upstream to the sender that caused the error. • RESVERR: Sent downstream. • ERROR SPEC: This object contains the Error Code and Error Value, which help to decode the error types. A common Error Code 00 indicates confirmation sent in response to receiving a confirmation object.
  • 9. RSVP Messages 9 • 4. RSVP Tear Messages: • RSVP uses two types of tear messages: PATHTEAR and RESVTEAR. • PATHTEAR: Travels downstream towards all receivers from the point of initiation. • RESVTEAR: Travels upstream towards all senders. • These messages clear the reservation states on the router, allowing the router to reuse resources for other requests. Tear messages may be triggered by state timeouts or tunnel pre-emption. • Note: RECORD ROUTE: Adds the outgoing interface IP address to the RECORD ROUTE for tracking.
  • 10. Operations of LSP Tunnels - Special Notes 10 1.PATH Message Handling: •The PATH message is sent to the next-hop (downstream) router, referred to as P2. •The P2 router performs admission control, ensuring that the requested bandwidth is available. •If admission control succeeds, the P2 router generates a new PATH message and sends it to the next-hop in the ERO (Explicit Route Object). •P2 router tracks the interface from which the PATH message was received. 2.RESV Message Handling: •The PE4 router, upon recognizing that it is the destination for the PATH message, responds with a RESV message. •During the RESV message generation, PE4 begins the label allocation process. •PE4 assigns an explicit-null label (label value 0) to the LSP tunnel, which the upstream router (P3) will use to forward packets to PE4. This label is included in the LABEL object of the RESV message. •The RESV message is sent back along the reverse path of the ERO in the PATH message. •The RECORD ROUTE object is initialized, adding the outgoing interface IP address of PE4. •The explicit-null label is interpreted as an implicit-null label (label value 3) at both the tailend (PE4) and penultimate-hop (P3) routers. •To modify this default behavior, the command mpls traffic-eng signalling advertise implicit-null can be used on the tailend router.
  • 11. Operations of LSP Tunnels - Special Notes 11 14. Routing Traffic Inside TE Tunnels 1.Using Static Route: • Traffic can be routed through a TE tunnel by configuring static routes that point to the tunnel endpoint. 2.Using Policy-based Routing: • Policy-based routing (PBR) can be applied to direct traffic over a specific TE tunnel based on defined policies such as source/destination IP or protocol type. 3.Autoroute Announce: • The Autoroute Announce feature enables the headend router to announce the TE tunnel as a route. This method does not modify the topology database on other routers in the network. 4.Forwarding Adjacency: • A bi-directional LSP (Label Switched Path) is set up, and adjacency is formed over the TE tunnel. This allows the router to forward traffic using the tunnel. Note: •Forwarding Adjacency requires the ip ospf 1 area 0 command under the tunnel configuration in IOS-XE to advertise the tunnel as a link in the OSPF database. However, this command is not needed in IOS-XR for the same functionality.
  • 12. Operations of LSP Tunnels - Special Notes 12 15. Link Protection for MPLS TE Tunnels 1.Link Protection Overview: •Link protection ensures that traffic being forwarded on an LSP can still reach its destination if a link in the LSP fails. Abackup tunnel is established to route traffic around the failed link. 2.Operation During Link Failure: •When a link (e.g., P2-P4) fails, traffic for the primary TE tunnel is rerouted through a backup tunnel around the failed link and reaches the destination (e.g., PE5). •The router where traffic is switched from the main path to the backup path is called the Point of Local Repair (PLR). •The router where traffic merges back from the backup path to the main path is called the Merge Point (MP). 3.Before Link Failure: •3.1) Backup Path Readiness: The backup path must be precomputed and signaled before any link failure to ensure traffic can be rerouted smoothly. •3.2) Tunnel Configuration: On the headend router, enable the following command under the tunnel interface to prepare the system for link protection: bash tunnel mpls traffic-eng fast-reroute •3.3) RSVP PATH Signaling: When PE1 signals the RSVP PATH messages for the TE tunnel, it sets the local protection desired flag in the Session_Attribute object, indicating the need for protection along the entire path to PE5. •3.4) Backup Tunnel Preconfiguration: On the PLR, the backup tunnel must be preconfigured. Use the following command on the interface facing the backup tunnel: bash mpls traffic-eng backup-path Tunnel 100 •3.5) CSPF for Protection Path: The PLR router runs a CSPF (Constrained Shortest Path First) calculation to find an alternate path to the MP router, avoiding the failed link (P2-P4). The backup path is configured similarly to a regular MPLS TE tunnel using RSVP.
  • 13. Operations of LSP Tunnels - Special Notes 13 3.6 Techniques for Merging Traffic from Backup Path to Protected Path at the Merge Point (MP) There are two techniques for handling the merging of traffic from a backup path to the protected path at the MP: 3.6.1 Facility Backup (N:1) •In Facility Backup, traffic arriving over the backup tunnel at the MP uses the same label as it would have if it had arrived over the failed (or protected) link. •To achieve this, the PLR pushes an extra label of the backup tunnel onto the label stack of the main tunnel. •Additionally, the P4 router advertises an implicit-null label to P3, enabling penultimate-hop popping (PHP) for the backup tunnel label before the MP. •This technique allows multiple LSPs crossing the protected link (P2-P4) to be protected by a single backup tunnel, making it an N:1 backup mechanism (one backup tunnel for multiple LSPs). •Cisco IOS supports this technique. 3.6.2 One-to-One Backup (1:1) •In One-to-One Backup, traffic arriving at the MP uses a different label than the one used by the main path. •No extra label is pushed into the label stack by the PLR in this case. •A separate backup tunnel is required for each LSP to ensure traffic is handled independently. •This technique results in a 1:1 backup mechanism (one backup tunnel for each LSP).
  • 14. Operations of LSP Tunnels - Special Notes 14 4) After Link Failure:The backup path plays a crucial role in maintaining traffic flow for LSPs when a link failure occurs, allowing the network to continue forwarding traffic while the headend router computes a new path avoiding the failed link. Here's how the process unfolds: PLR Notification of Link Failure: The Point of Local Repair (PLR) router (P2 in this case) detects the link failure. The PLR notifies the headend router (PE1) about the failure. This notification is sent using an RSVP PATH Error message.
  • 15. Operations of LSP Tunnels - Special Notes 15 16) Node Protection for MPLS TE Tunnels: Node protection (also called NNHOP or Next Next-Hop FRR) provides protection for MPLS TE tunnels, covering not only link failures but also node failures. This ensures that if a node along the path fails, traffic can be rerouted via a backup path. 1) Before Failure: Backup Path Configuration: The backup path is preconfigured to ensure traffic is rerouted when a failure occurs. In the case of a failure at node P4, the backup path from P2 to P5 (via P2-P3-P5) is established, avoiding P4. The backup path uses CSPF to compute a route, and RSVP PATH & RESV messages are sent to form the tunnel. 2) Enabling Node Protection: On the headend router (PE1), node protection is enabled using the command:tunnel mpls traffic-eng fast-reroute node-protect ensures that protection is available in case of node failure.
  • 16. Operations of LSP Tunnels - Special Notes 16 1.RSVP PATH Message: 1. When PE1 signals the RSVP PATH message, it sets the node protection desired flag and label recording desired flag in the Session_Attribute object. 2. The label recording flag ensures that label information is included in the RSVP Record Route (RRO) sub-object, specifically in the Label sub-object. 3. This allows the Point of Local Repair (PLR) to know which labels should be used for rerouting traffic. By pre-configuring the backup paths and enabling node protection, the network can rapidly respond to failures in both links and nodes, ensuring continuous traffic flow with minimal disruption
  • 17. Operations of LSP Tunnels - Special Notes 17 16) Node Protection for MPLS TE Tunnels (Continued): 4) Router Behavior When Node Protection is Desired: •When P2 router (which also acts as the Point of Local Repair or PLR) receives the RSVP PATH message from PE1 router, it identifies that node protection is requested. •The P2 router sets the Local Protection Available flag in the Record Route Object (RRO) and sends the PATH message along the defined path towards PE6 router. •As the message propagates, all routers along the path (including P2) are aware that node protection is available at P2 router. •PE1 router is not yet aware of the protection availability at this stage. 5) Path Setup with RESV Message: •PE router agrees to set up the path and responds by sending an RSVP RESV message towards PE1 router. This message includes the Label for the tunnel inside the Label object. •As the RESV message arrives at P2 router, it further processes the message by: •Sending the RESV message to PE1 router with the Local Protection Available flag set in the RRO object. •Additionally, P2 router includes the node-id flag in the RESV message for 2.2.2.2/32, indicating that node protection is available at this specific node. This mechanism ensures that the PLR (P2 router) and the rest of the routers in the network are aware that node protection has been successfully configured, and the path is protected in case of a node failure. The protection status is propagated through the RRO and RESV messages, ensuring that all routers along the path are prepared to reroute traffic in case of failure.
  • 18. Operations of LSP Tunnels - Special Notes 18 3) After Failure 1.Similar to the link protection mechanism, when the P2 router detects the failure of the P4 router (or the link connecting P2 to P4), it suppresses any event notifications to the PE1 router to prevent the teardown of the LSP. Instead, the P2 router sends a Path Error message to the PE1 router with a Notify error code, a Tunnel Locally Repaired sub-code, and details about the node where the error was detected. The outbound FRR status on the P2 router changes to Active. 2.Upon receiving the Path Error message from the P2 router, the PE1 router recognizes the change in resources and sends out a PATH message to re-route traffic to an alternate path. It then receives a RESV message with a different path in the RRO, indicating a failover to the backup path. 3.In summary, node protection provides resilience against both link and node failures. Label recording is essential because the PLR must know the label that the MP expects the traffic to arrive with.
  • 19. Operations of LSP Tunnels - Special Notes 19 Example: ======== Node Protection: ================ label 30 label 20 R1--------------R2-------------R3----------R5 R1--------------------R4---------------R5 label 50 WHEN R2 fails , how R1 Knows about label assign from R3 to R2 ( label 20 ) ? R1 will Know the label in the RRO , then R1 will send the traffic with label 50 ( backup tunnel and label 20 ) label 20 which is known to R1 by the RRO check point in Link Protection: =================== there is no need for R1 to Know this label because traffic will be directed already to R2 which already Know the label 20
  • 20. Operations of LSP Tunnels - Special Notes 20 17) Interarea TE tunnels : 1- One of the limitations of TE LSP paths is that they are computed for a single IGP area only, due to the lack of visibility into the topology of other IGP areas. In OSPF, the ABR hides the topology between two areas. This poses a challenge in large networks where multiple IGP areas are deployed or in cases where the network spans multiple service providers. This scenario is often referred to as interdomain traffic engineering. 2- Consider a network with three OSPF areas where an MPLS TE tunnel must be established from PE1 to PE2. Since PE1 and PE2 reside in different areas, PE1 lacks the necessary information to compute an end-to-end path that satisfies TE constraints. Once a path is computed, signaling is carried out as usual, even across areas or autonomous systems (ASs). 3- MPLS traffic engineering across areas is supported only within a single domain because the MPLS TE Router ID is advertised only within a single area. A second area cannot establish a tunnel with a route marked as "OIA" (inter-area). 3-1 To set up an RSVP-signaled TE LSP, three steps are required: Path computation Resource reservation Label distribution 3-2 Autoroute announce cannot be used for inter-AS traffic engineering, nor can autoroute destination.
  • 21. Operations of LSP Tunnels - Special Notes 21 • 3.2.1. Contiguous LSP: (Typically used in inter-area and interdomain scenarios, but only when RSVP is deployed in both domains and areas) • In this method, an end-to-end LSP is established between PE1 and PE2 using hop-by-hop signaling between adjacent neighbors. Both loose and strict hops can be defined: • Loose hops indicate the ABR, specifying that some details of the route are left to the ABR's discretion. • In this case, there is no direct link between the ABR and its area, but MPLS traffic engineering ensures the path is known. 3.1. Gathering TE Information: Link information is carried in the same way as in regular MPLS TE. OSPF Opaque LSA Type 10 (TE LSAs) are used to advertise link-specific details such as link type, maximum reservable bandwidth, unreserved bandwidth, TE metric, attribute flags, and more. 3.2. Path Setup: Path setup is discussed before path computation because understanding how a path is set up is essential. For interdomain TE, there are three methods to set up an LSP:
  • 22. Operations of LSP Tunnels - Special Notes 22 3.2.2. LSP Stitching: (Typically used in inter-area and interdomain scenarios where RSVP and SR are deployed across different domains or areas) Smaller TE LSPs are established within individual areas or domains and then stitched together to form an end-to-end LSP. Each smaller LSP is mapped with a 1:1 relationship, often represented using Binding SIDs in SR environments. In interdomain scenarios, there must be a link between the two ASBRs, and it must be part of the MPLS Traffic Engineering Database (TED). Additionally, the link between the two ASBRs must be configured with ASBR Forced Link Flooding when RSVP is used.
  • 23. Operations of LSP Tunnels - Special Notes 23 3.3. Path Computation for Contiguous LSP: 1.For contiguous LSPs, the exit points out of the areas (or domains) must be known. The headend router (PE1) does not have visibility of the entire path of the LSP. Instead, the path to the next border router (e.g., ABR1) is computed, added to the Explicit Route Object (ERO), and the LSP is signaled. Thus, the path is computed per-domain. •In per-domain path computation, the path is computed separately within each domain, from one border router to the next. •The IP addresses of the border routers must be known to the LSP headend. •The headend router defines the path explicitly because it cannot dynamically compute the end-to-end path. Border routers are configured as loose hops, meaning the path to these border routers (e.g., ABR1) can be dynamically found. After reaching ABR1, the next path to ABR2 is computed by ABR1 and added to the ERO object in a process known as ERO Expansion. Each border router (ABR) runs constrained SPF (cSPF) to compute a path to the next border router that satisfies user-defined constraints. 2.Key Observations: •Loose hops for ABRs: The ABRs are configured as loose hops in the headend router. •Strict hops in ERO: While ABR1 (2.2.2.2) is configured as a loose hop, the ERO carries it as a strict hop because PE1 can compute a path to ABR1 directly. •Loose hops for ABR2: ABR2 (3.3.3.3) is carried as a loose hop in the ERO because PE1 lacks link information for the path to 3.3.3.3. Therefore, ABR1 is responsible for computing the path to ABR2. 3.At ABR1, all IP addresses leading to ABR2 are included as strict hops in the ERO object. 4.At ABR2, the router dynamically computes the path to the final destination (e.g., PE2).
  • 24. Operations of LSP Tunnels - Special Notes 24 6) Crank back: In regular MPLS TE within a single IGP area, RSVP PathErr messages provide the headend router with necessary information in case of an LSP failure, such as resource unavailability on a specific link. However, when the failure involves a link in a different area than the headend router, this information is less meaningful for the headend router. Example Scenario: If the link between ABR2 and PE2 is unavailable, sending an error message back to the PE1 router serves little purpose. Instead, this error message is more relevant to ABR2, as it can attempt to compute an alternate path within Area 2 that avoids the ABR2-PE2 link. 1.ABR2 Attempts an Alternate Path: 1. ABR2 tries to identify an alternative path, possibly through another border router, such as ABR3. 2. If the ABR2-ABR3 link is operational, the LSP can be rerouted through ABR3 to reach PE2. 2.Escalation to ABR1 if No Alternative Exists: 1. If the ABR2-ABR3 link is also unavailable, ABR2 cannot find an alternative path. 2. In this case, the error is escalated upstream to ABR1. ABR1 then assumes the responsibility of finding a new path that avoids ABR2 entirely. This process, where error messages are forwarded upstream to identify alternative paths, is known as crankback. It ensures that routing adjustments are made closer to the point of failure, reducing the impact on the headend router and improving the network's ability to recover from failures.
  • 25. Operations of LSP Tunnels - Special Notes 25 7) ASBR Forced Link Flooding: When forced link flooding is configured on an interface, the MPLS TE link management module advertises the link to all nodes. This advertisement updates the TE topology database on all nodes within the inter-AS environment with the link's information. Key Features: 1.Advertisement Without IGP Adjacencies: ASBR forced link flooding enables the advertisement of links even when IGP adjacencies are not established on those links. 1. TE LSPs can traverse such links between two nodes running BGP (or static routes), even if the exit ASBR is not explicitly listed in the IP explicit path. 2. This allows a headend LSR to consider these links during TE LSP path computation. 2.Activation: To enable ASBR forced link flooding: 1. Configure the link as passive. 2. Provide neighbor information, such as the neighbor IGP ID and the neighbor TE ID. 3.Link-State Advertisement: 1. OSPF uses opaque LSA Type 10 to flood TE link information across the network. ASBR forced link flooding ensures comprehensive visibility of inter-AS TE links, facilitating efficient LSP path computation and traversal, even in scenarios without direct IGP adjacencies.
  • 26. Operations of LSP Tunnels - Special Notes 26 ASBR Links Configuration interface GigabitEthernet2 ip address 10.8.5.5 255.255.255.0 negotiation auto mpls traffic-eng tunnels mpls traffic-eng administrative-weight 20 mpls traffic-eng passive-interface nbr-te-id 10.0.0.8 nbr-if-addr 10.8.5.8 nbr-igp-id ospf 10.0.0.8 no mop enabled no mop sysid end
  • 27. Operations of LSP Tunnels - Special Notes 27 Notes: 1.No Stitching Between RSVP & RSVP: 1. Stitching is only supported between SR and RSVP. 2. In RSVP, labels cannot be added to the explicit path, whereas in Segment Routing (SR), we can insert a Binding SID of an RSVP tunnel. 3. Therefore, stitching is not possible in inter-area MPLS Traffic Engineering (TE) tunnels, and only contiguous LSPs can be used. 2.No Stitching in Interdomain MPLS Traffic Engineering: 1. Stitching is only needed between RSVP and SR. 2. Interdomain MPLS TE does not support stitching between RSVP tunnels. 3.ASBR Forced Link Required in Interdomain MPLS Traffic Engineering: 1. For interdomain MPLS Traffic Engineering, ASBR Forced Link Flooding is necessary between the two ASBRs. 2. This ensures the visibility of links for TE across domain boundaries. 4.Check LAP for Inter-AS & Inter-Area Traffic Engineering: 1. It's important to review LAP (Link Aggregation Protocol) for proper integration and configuration in Inter-AS and Inter-Area Traffic Engineering scenarios. 5.Cannot Use Autoroute Announce for Inter-AS Traffic Engineering: 1. Autoroute announce and auto-route destination cannot be used for inter-AS traffic engineering. 2. These features are not compatible with inter-domain TE scenarios and require manual configuration of explicit routing.
  • 28. Operations of LSP Tunnels - Special Notes 28 TE Attributes TE (Traffic Engineering) attributes are parameters used to manage and control traffic flow within a network. They help determine path selection, resource allocation, and Quality of Service (QoS) for various traffic flows. Common TE attributes include: 1.Bandwidth: Represents the link or path capacity, typically measured in bits per second (bps). It indicates the maximum data transfer rate and is critical for path selection and resource reservation. 2.Link Metrics: Numerical values assigned to links that determine the cost or preference of a path. These metrics can be based on factors like bandwidth, delay, jitter, and packet loss, guiding the algorithm to select the best path. 3.Administrative Groups: Links are grouped based on administrative policies. These groups influence path selection, with certain links prioritized or reserved for specific types of traffic. 4.Affinity: Represents specific requirements or characteristics of a traffic flow, such as application or service level. Affinity values help ensure traffic flows are assigned to paths that meet their needs. 5.Constraints: Conditions like maximum delay, minimum bandwidth, or specific routing requirements that paths must satisfy. Constraints ensure selected paths meet necessary criteria. 6.Preemption: Defines whether lower-priority traffic can be preempted by higher-priority flows. This attribute helps optimize resource usage and manage QoS by reallocating resources when necessary.