RSVP
Overview
RSVP is a network control protocol that hosts use to request specific qualities of service from the network for specific data streams. RSVP is also used to deliver QoS requests to all devices in a data path and to establish and maintain the state information required to provide the requested service quality.
RSVP is not a routing protocol. RSVP operates using Unicast and multicast routing protocols. RSVP consults local routing tables to relay RSVP messages. By default, RSVP is enabled on all devices that support it.
RSVP requests typically result in the reservation of resources on each device in the data path. MPLS use this RSVP mechanism to set up traffic-engineered LSPs. RSVP requests resources for unidirectional flows only. RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver.
The RSVP hello protocol detects the loss of a neighbor NE or the reset of a neighbor RSVP state information. In standard RSVP, neighbor monitoring occurs as part of the RSVP soft-state model. The reservation state is maintained as cached information that is first installed and then periodically refreshed by the ingress and egress LSRs.
If the state is not refreshed within a specified time interval, the LSR discards the state because it assumes that either the neighbor NE has been lost or its RSVP state information has been reset.
Diff-Serv Traffic Engineering support
The NFM-P supports Diff-Serv Traffic Engineering, or TE, extensions for RSVP. Diff-Serv TE extensions provide the ability to manage bandwidth in an MPLS network on a per-TE-class basis. With Diff-Serv TE, an LER can perform this on a per-class basis. Therefore, you can set different limits for admission control of LSPs in each TE class over each link in the network.
You do this by setting a bandwidth constraint, which configures the percentage of the RSVP interface bandwidth that each CT shares. The absolute value of the CT share of the interface bandwidth is derived as the percentage of the bandwidth advertised by IGP in the Maximum Reservable link bandwidth TE parameter, that is, the link bandwidth multiplied by the RSVP interface subscription parameter.
This configuration also exists at the RSVP interface level and the value specifically configured for the interface overrides the globally-configured value. The bandwidth constraint value can be changed on the fly. You are also allowed to specify the bandwidth constraint for a CT which is not used in any of the TE class definitions and which is not used by any LSP originating or transiting this NE.
To enable this feature, in summary, you must:
-
configure Diff-Serv Classes on the router RSVP Routing Instances
-
configure protocol properties to allow Diff-Serv Classes on the required router RSVP Interfaces
-
configure traffic engineering and specify the Class Type that the required dynamic LSPs belongs to
-
configure the Diff-Serv Class Type that the required LSP Paths belongs to. This overrides the value set at the LSP level.
-
configure Diff-Serv to LSP FC mappings on the required service tunnels (SDPs). User-entered mappings of FC to LSP name are validated automatically (to avoid configuration conflicts) by checking with the RSVP module.
Dark bandwidth accounting support
The bandwidth availability advertised by IGP in a TE network accounts for RSVP-TE LSP bandwidth requirements. However, other types of labeled traffic may exists on the same links. The bandwidth used by this traffic is called dark bandwidth. You can configure accounting for MPLS-SR related dark bandwidth.
To enable this feature, you must: