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.
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:
- PATH message. A PATH message is generated by the ingress router and sent toward the egress router. This is termed the downstream direction. This PATH message is a request by the sending LSR for the establishment of an LSP to the egress router. Each LSR in the path to the destination router digests the PATH message and does one of three things:
- If the LSR cannot accommodate the request, it rejects the request by sending a PATH_ERR message back to the source indicating the nature of the rejection.
- If the LSR is not the egress router, it sends a PATH message to the next LSR toward the destination router.
- If the LSR is the egress router, it should respond with a RESV message back to its most recent neighbor.
- RESV message. A RESV message is generated by the egress router and sent over the reverse path that the PATH messages took. This is termed the upstream direction.
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:
- The DUT acts as the Ingress LSR, and the Egress LSR is simulated by an Ixia port.
- The DUT acts as the Egress LSR, and the Ingress LSR is simulated by an Ixia port.
- 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.
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:
- IPv4 prefix
- IPv6 prefix
- Autonomous system number
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.
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.
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.
- Ingress mode: LSRs I and II are termed a neighbor pair, where LSR I is the upstream router being simulated and LSR II is its immediate downstream neighbor. The Ixia port generates the PATH and HELLO messages that LSR I would send. LSR II is the Device Under Test (DUT) and may be an egress router or be connected to other LSRs, as shown in the figure.
- Egress mode: the Ixia port simulates LSR II while LSR I is the DUT. The Ixia port interprets PATH messages that it receives to determine if they are directed for any of the defined destination routers. If that is the case, it responds with appropriate RESV messages.
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.