This chapter contains configurations for Resource Reservation Protocol - Traffic Engineering (RSVP-TE).

RSVP-TE is a signaling protocol that supports explicit routing capabilities, To do this, an Explicit Route (ER) object is incorporated into RSVP PATH messages. This object encapsulates a sequence of hops that constitute the explicitly-routed path. Using the ER object, the paths taken by label-switched RSVP-MPLS flows can be pre-determined without conventional IP routing. An ER path can be administratively specified or computed based on CSPF and any policy requirements dictated by the operator through the trunk node, taking the current network state into consideration. A useful application of explicit routing is Traffic Engineering (TE). Using explicitly-routed LSPs, an ingress node can control the path through which traffic flows from itself, through the MPLS network, to the egress node. Explicit routing is therefore useful for the optimization of network resources and an increase in the quality of traffic-oriented performance.

RSVP-TE is a signaling protocol that supports explicit routing capabilities to establish LSPs in a MPLS network. OcNOS RSVP-TE:

In addition, OcNOS RSVP-TE may be used in unison with BGP to generate MPLS/BGP VPNs, and in unison with LDP to generate Layer-2 Virtual Circuits.

To establish a trunk on a system:

OcNOS, Constrained Shortest Path First (CSPF) calculation is enabled by default.Typically, CSPF is disabled when all of the participating nodes do not support the required traffic engineering extensions and LSPs are configured manually to use an explicit path. In this case, an LSP is established only along the path specified by the operator.

The RSVP trunk can be configured using CSPF (Constraint-based Shortest Path First). In this case, the RSVP daemon (rsvpd) sends a request to the CSPF server to compute a path through the network to reach the destination. CSPF returns a hop-by-hop path called the Explicit Route to the RSVP daemon to be used in the Explicit Route Object (ERO). Each router along the path sends a Path message only to the nexthop specified in the ERO. In the OcNOS implementation, CSPF is enabled by default and if no-cspf is not specified, the trunk is CSPF enabled automatically.

In the OcNOS implementation, a network can be mapped to a particular trunk using map-route configuration.

Explicit Route hops can be configured manually in the trunk configuration. In this case, the RSVP daemon uses the configured hops as Explicit Route Objects (ERO). It sets up the LSP using specified hops only.

An ERO is composed of IP addresses called hops. An ERO hop can be defined as loose or strict. A loose hop can be reached by any available route. A strict hop must be reached via a direct link and cannot be routed over any alternate routers in between. In this example, since R3 is defined as loose hop, R2 can use R4 as an intermediate hop to reach R3. However, if it was a strict hop, then R2 would have to use interface eth1 to reach R3 directly.

Although the attributes of a Secondary LSP are independent of the Primary LSP, a Secondary LSP cannot be configured without first configuring a Primary LSP. In addition to information on how to configure a secondary LSP, this example illustrates how to define a non-default setup and the hold priority for an LSP. Setup and hold priorities are used to determine which LSP should be given a preference when competing for resources. Specifically, the setup priority of an un-established LSP is compared to the hold priorities of established LSPs, and the numerically lower one is given a preference. However, once the LSP is established, its setup priority is never used until it is pre-empted or reset and is being brought up again.

This example shows the number of configured RSVP sessions in a router.

RSVP Multiple Secondary feature tries to provide continuous protection when multiple failures happen. In majority scenarios, feature tries to provide seamless protection. This is a proprietary feature where user can configure multiple secondary sessions in a rsvp-trunk. Each secondary will be associated with a priority. Priority secondary sessions must be programmed with a predefined path. User can configure a maximum of five priority levels. Lowest priority number corresponds to highest priority. Highest priority session will be signaled to be programmed as secondary session. If highest priority session cannot come up, then next available secondary will be selected based on polling. During primary session fail-over, programmed secondary priority session will protect the primary and then goes for an MBB update to act as the primary session until primary comes up. Once the highest priority session comes up as acting primary session, next available secondary priority session will be programmed to signal and come up secondary. Re-optimization timer executed once in every 5 minutes to ensure the best priority session serves as secondary. Configuration updates on secondary priority configurations doesn't trigger MBB and session will be restarted. This example illustrates how to create SVI, enable IGP protocols and RSVP on SVI.

vlan 501-506 bridge 1 state enable

This example shows the number of configured RSVP sessions in a router.

Bridge Configuration

vlan 507-5012 bridge 1 state enable

 

vlan 513-518 bridge 1 state enable

no bridge 1 spanning-tree enable bridge-forward

VLAN creation

vlan 519-524 bridge 1 state enable

This example shows the number of configured RSVP sessions in a router.

To add administrative group constraints (also known as color constraints) to an LSP:

The configuration in this example forces the primary LSP to be setup through links that belong either to administrative group A or C. A link that does not belong to either of these administrative groups will not be used for setting up the LSP.

Some common parameters can be configured in the Router mode on the RSVP-TE daemon. These parameters are global and affect all LSPs. In the following example the interval between two consecutive hello messages is set. The neighbor is defined by the neighbor command. Hello exchanges are enabled only between explicitly configured neighbors (configure this router as a neighbor on R2 (IP address 10.10.23.60).

The Fast Reroute (FRR) configuration is a MPLS resiliency technology that provides fast traffic recovery when there is a link or router failure on mission critical services. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in tens of milliseconds, in the event of a failure. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. This method is used to protect links and nodes during network failure.

In the below configurations each FRR trunk is mapped to VPWS,VPLS and L3 VPN services.So it includes configurations of VPWS,VPLS and L3 VPN also.

Figure 3-7 is a simple topology example for FRR:

This example shows MPLS ping and trace route for RSVP

To share the load across multiple members of a LAG port in the core of an MPLS network we can use entropy labels

An Entropy Label is always preceded by an Entropy level indicator which is a special Label with value seven, and indicates the next label present is an Entropy label. The trade off is the MPLS stack depth increases by two and it reduces overhead on transit routers.

Entropy labels will only be added when the remote edge node advertises its capability for Entropy.

The examples below show how entropy can be enabled on a provider edge node as per the setup we need to enable on RTR29 and RTR30 to have entropy enabled in both directions:

This enables ELC signaling for RSVP.

For validation, use:

Follow these steps to configure RSVP LSP Re-optimization.

 

Follow these steps to force the LSP to be re-optimized.