RSVP-TE

The Ixia protocol server implements a part of the Resource Reservation Protocol (RSVP) used for Traffic Engineering (TE). This subset of the RSVP protocol, referred to as RSVP-TE, is used in the process of constructing a path through a sequence of MPLS-enabled label switched routers (LSRs), while reserving necessary bandwidth resources. The use of an internal gateway routing protocol (IGP), such as OSPF, is also required to automatically determine the `next hop' router.

Multi-Protocol Label Switching (MPLS) allows rapid forwarding of packets across a sequence of routers, without time-consuming examination of the packet contents at each hop. Label switching has been used extensively for ATM traffic, where overhead bytes for each `cell,' or packet, of data constitute a large percentage of the overall data transmitted. The addition of a `label' value to the header information in each cell or packet supplies the only forwarding information required to transit the MPLS domain. Based on information in its forwarding table, each LSR replaces (swaps) the incoming label with a new one which directs the packet to the next hop.

The most important output from an RSVP-TE setup session is the set of MPLSlabels, which are used by the MPLS-enabled routers along the path to efficiently forward network traffic. The operation of RSVP-TE is shown in the following figure.

Figure: RSVP-TE Overview

Through the use of RSVP-TE message exchanges, the router at the entry to the MPLS domain, also known as an Ingress LSR, initiates the creation of a dynamic `tunneled' pathway to the Egress LSR, the router at the exit side of the MPLS domain. Packets which pass through this `tunnel' are essentially `protected' from the extensive packet processing normally imposed by each router it traverses. Once this special pathway or Label Switched Path (LSP) is established, the router can forward, rather than route, packets across the domain, saving considerable processing time at each intermediate LSR (Transit LSR). The resulting tunneled pathway is known as an LSP Tunnel. The traffic flows through an LSP Tunnel are unidirectional. To establish bidirectional traffic through the MPLS domain, a second LSP Tunnel must be created in the opposite direction.

An LSP Tunnel is defined by a Destination Address (the IP address of the Egress LSR), and a Tunnel ID. At a finer level of granularity are LSP IDs. Essentially, these LSP IDs can serve to provide a set of aliases for alternate hop-by-hop paths between a single pair of Ingress and Egress LSRs, and therefore exist within the same LSP Tunnel.

Note: Note: Ingress LSRs and Egress LSRs are also known as Label Edge Routers (LERs).

Two principal RSVP-TE message types are used to establish LSP Tunnels:

An additional HELLO message is used between neighbor LSRs to ensure that LSRs are alive. This allows for quick tunnel replacement in the case of link or router failure.

A set of labels is passed in the RESV messages sent upstream from the egress to the ingress router. A label is sent from one LSR to its upstream neighbor telling the upstream router which label to use when later sending downstream traffic.

Three scenarios are currently supported to test MPLS/RSVP-TE on a DUT using Ixia equipment:

  1. The DUT acts as the Ingress LSR, and the Egress LSR is simulated by an Ixia port.
  2. The DUT acts as the Egress LSR, and the Ingress LSR is simulated by an Ixia port.
  3. The DUT acts as a Transit/Intermediate LSR, and the Ingress and Egress LSRs are simulated by Ixia ports.

PATH Messages

PATH messages contain a number of objects which define the tunnel to be established. These are shown in the following table.

RSVP-TE PATH Message Objects
Object Contents Usage

SESSION

 

Describes the destination router and associates a tunnel ID with the session.

 

tunnel endpoint

The destination router's IP address.

 

tunnel ID

A unique LSP tunnel ID.

SENDER_TEMPLATE

 

The description of the sender.

 

tunnel sender address

The sender router's IP address.

 

LSP ID

A unique LSP ID.

LABEL_REQUEST

 

Asks all the LSRs to send back label values through RESV messages.

SENDER_TSPEC andADSPEC

 

Both of these objects deal with bandwidth and other QoS requirements for the path.

TIME_VALUES

 

Timing values related to the refresh of tunnel information.

 

refresh interval

The interval between messages.

EXPLICIT_ROUTE

 

Allows the sender to request that the LSP tunnel follow a specific path from ingress to egress router. See Explicit_Route for more details.

SESSION_ATTRIBUTE

 

Other attributes associated with the session: tunnel establishment priorities, session name, and optionally resource affinity.

RSVP_HOP

 

Describes the immediate upstream router's address to the downstream router.

Explicit_Route

An explicit route is a particular path in the network topology. Typically, the explicit route is determined by a node with the intent of directing traffic along that path. An explicit route is described as a list of groups of nodes along the explicit route. In addition to the ability to identify specific nodes along the path, an explicit route can identify a group of nodes that must be traversed along the path. Each group of nodes is called an abstract node. Thus, an explicit route is a specification of a set of abstract nodes to be traversed.

There are three types of objects in an explicit route:

Each node has a loose bit associated with it. If the bit is not set, the node is considered strict. The path between a strict node and its preceding node may only include network nodes from the strict node and its preceding abstract node. The path between a loose node and its preceding node may include other network nodes that are not part of the strict node or its preceding abstract node.

RESV Message

The RESV message contains object that indicate the success of the PATH request and the details of the assigned tunnel. These are shown in the following table.

RSVP-TE RESV Message Objects
Object Usage

SESSION

Indicates which session is being responded to.

TIME_VALUES

As in the PATH message but from the downstream LSR to the upstream LSR.

STYLE

The type of reservation assigned by the egress router. This relates to whether individual tunnels are requested for each sender-destination connection or whether some connections may use the same tunnel.

FILTER_SPEC

The sender router's IP address and the LSP ID.

LABEL

The label value assigned by the downstream router for use by the upstream router.

RECORD_ROUTE

If requested, the complete route from the destination back to the source. The contents of this object include the IP addresses in either v4 or v6 format of all the LSRs encountered in the formation of the LSP, and optionally the labels used at each step. Each LSR on the upstream path perpends its own address information.

RESV_CONF

If present, it indicates that the ingress router should send a RESV_CONF message in response to the destination to indicate that the tunnel has been completely established.

Other Messages

Several additional messages are used in RSVP-TE, as explained in the following table.

Additional RSVP-TE Messages
Message Usage

PATH_ERR

Any LSR may determine that it cannot accommodate the tunnel requested in a PATH message. In this case it sends a PATH_ERR message back to the sender.

PATH_TEAR

When a sender router determines that it wants to tear down a tunnel, it sends a PATH_TEAR message to the destination router.

RESV_ERR

If a router cannot handle a reservation, it sends a RESV_ERR back to the destination router.

RESV_TEAR

When a destination router determines that it wants to tear down a tunnel, it sends a RESV_TEAR message upstream to the source router.

RESV_CONF

When requested, a sender router responds to the destination router with a RESV_CONF message to indicate that a complete tunnel has been successfully established.

RSVP-TE Fast Reroute

RSVP-TE Fast Reroute allows to configure backup LSP tunnels to provide local repair/protection ONLY for explicitly-routed LSPs/LSP tunnels, termed protected LSPs as described in IETF DRAFT draft-ietf-mpls-rsvp-lsp-fastreroute-03.

An example diagram of a backup scenario for rerouting around a downed link, using an LSP Detour, is shown in the following figure.

Figure: RSVP-TE Fast Reroute Backup Link (Detour) Example

The following image shows an example diagram for a backup scenario to reroute around a downed node, using an LSP Detour.

Figure: RSVP-TE Fast Reroute Backup Node (Detour) Example

The one-to-one backup method is based on including a DETOUR object in the Path message. The head-end router, the Point of Local Repair (PLR), sets up a separate detour LSP for each LSP it protects. For the Facility backup method, the PLR sets up a tunnel to protect multiple LSPs simultaneously, by using the MPLS label stack.

Ixia Test Model

The Ixia test process is designed so as to fully exercise RSVP functionality in MPLS routers. An Ixia port can simulate any number of LSR routers at the same time. Each router operates in an ingress or egress mode. In the following discussion, LSRs I and II refer to the figure in RSVP-TE Overview.

If requested, HELLO messages are generated and responded to in either mode.

When the Ixia port operates in Ingress mode, it attempts to set up LSP tunnels for each combination of sender router and destination router, using any number of LSP tunnels and any number of LSP IDs for each LSP tunnel. Thus the number of PATH messages that the Ixia port attempts to generate for each refresh interval is:

# of sender routers x # of destination routers x # of LSPs x # of LSP tunnels

The protocol server records all labels and other information that it receives on behalf of its simulated routers and displays those in a convenient format.