Resource Reservation Protocol (RSVP)

After a path is calculated with CSPF, that path needs to be signalled across the network for two reasons:

• To establish a hop-by-hop chain of labels that represent the path

• To consume any consumable resources (bandwidth) across that path

This signalling is accomplished using RSVP, along with RSVP extensions for MPLS TE. RSVP itself is specified in RFC 2205, with some pertinent extensions in RFC 2210. The MPLS TE extensions to RSVP are specified in RFC 3209.

The RSVP discussion in this chapter is divided into four parts:

• RSVP basics

• RSVP packets

• RSVP operation

• RSVP in the real world

The two most important sections to understand are “RSVP Basics” and “RSVP in the Real World.” The “RSVP Packets” and “RSVP Operation” sections are useful for understanding exactly how RSVP does what it does.

RSVP Basics

RSVP is a signalling mechanism used to reserve resources throughout a network. It has its own protocol type (46), although it is possible to encapsulate RSVP in UDP. MPLS TE never encapsulates RSVP in UDP, so that isn't discussed further.

RSVP is not a routing protocol. Any routing decisions are made by the IGP (including TE extensions) and CSPF. RSVP's only job is to signal and maintain resource reservations across a network. In MPLS TE, RSVP reserves bandwidth at the control-plane layer; there is no forwarding-plane policing of traffic. When used for other purposes (such as VoIP or DLSW+ reservations), RSVP can be used to reserve Weighted Fair Queuing (WFQ) space or build ATM SVCs. Those uses are not discussed here.

RSVP has three basic functions:

• Path setup and maintenance

• Path teardown

• Error signalling

RSVP is a soft-state protocol. This means that it needs to periodically refresh its reservations in the network by resignalling them. This is different from a hard-state protocol, which signals its request once and then assumes that the request is up until it is explicitly taken down. With RSVP, a request goes away either if it is explicitly removed from the network by RSVP or if the reservation times out.

Table 4-20 lists the nine different defined RSVP message types.

These message types are explained in more detail in the upcoming section “RSVP Packets.”

Path Setup and Maintenance

Although path setup and maintenance are similar, they differ in a subtle way. Even though they use the same message formats do to what they do, it's worth explaining them separately the first time around.

Path Setup

After a tunnel headend completes its CSPF for a particular tunnel, it needs to signal this request to the network. The headend does this by sending a Path message to the next-hop node along the calculated path to the destination. The router that sent the Path message is called the upstream router, and the router that received the message is called the down-stream router. The upstream router is sometimes called the previous hop (phop).

After a downstream router receives a Path message, it does a few things. It checks the message's format to make sure everything is OK, and then it checks the amount of bandwidth the received Path message is asking for. This process is known as admission control.

If admission control is successful and the Path message is allowed to reserve the bandwidth it wants, the downstream router creates a new Path message and sends it to the next hop in the Explicit Route Object (ERO), which is covered later in this chapter. Path messages follow this chain until they reach the last node in the ERO—the MPLS TE tunnel tail.

The tunnel tail performs admission control on the Path message, just like any other downstream router. When the tail realizes that it is the destination of the Path message, it replies with a Resv message. Think of the Resv message as an ACK back to the upstream router. The Resv message not only contains an acknowledgment that the reservation made it all the way to the tunnel tail, but it also contains the incoming label that the upstream router should use to send packets along the TE LSP to the tail. Figure 4-11 shows the exchange of RSVP path and Resv messages during LSP setup.

Figure 4-11 has 10 steps. The following is a walk-through of what happens with Path and Resv messages in those steps. Assume that R1 has done its CSPF already and knows that it wants to reserve bandwidth along the path R1→R2→R3→R5→R6→R7:

At this point, R1 is done. It has received a Resv message for the tunnel to R7 it set up, and it knows which outgoing label to use. The Tunnel interface on R1 now comes up/up (until this point, the Tunnel interface is up/down).

Path Maintenance

At first glance, path maintenance looks just like path setup. Every 30 seconds (give or take 50 percent—see “RSVP Operation” later in this chapter), a headend sends one Path message per tunnel to its downstream neighbors. If a router sends out four Path messages in a row and does not see a Resv during that time, it considers the reservation gone and sends a message upstream, indicating that the reservation is gone.

However, there is one important thing to understand here. Path and Resv messages are both sent independently and asynchronously from one neighbor to another. Look again at Figure 4-11. Every 30 seconds, R1 sends a Path message for its one TE reservation to R2. And every 30 seconds, R2 sends a Resv message to R1 for that same reservation. The two messages, however, are not connected. A Resv message used to refresh an existing reservation is not sent in response to a Path message, as an ICMP Echo Reply would be sent in response to an ICMP Echo Request.

Why are things done this way? Largely to accommodate the merging of flows in “classic” RSVP (VoIP, DSLW+, that sort of thing), and these messages don't really apply to TE. If this doesn't make sense to you, don't worry about it. Just remember this when you start troubleshooting a TE problem and you don't see ping/ACK behavior with Path and Resv messages.

Path Teardown

Path teardown is pretty straightforward. If a node (usually the headend) decides that a reservation is no longer necessary in the network, it sends a PathTear along the same path that the Path message followed and a ResvTear along the same path that the Resv message followed.

PathTear messages are most commonly seen when the headend decides it no longer wants a reservation in the network (when a tunnel is shut down or reroutes off a certain path, for example). ResvTear messages are sent in response to PathTear messages to signal that the tunnel tail has removed the reservation from the network. Cisco IOS Software sends Resv messages and asks for confirmation that the reservation has been torn down; this results in a ResvTearConf message being sent back from the headend to the tail. PathTear and ResvTear messages can also be sent in response to an error condition in the middle of the network. You'll read more about this in the “RSVP Operation” section.

Much like refresh messages, PathTear messages don't have to go all the way downstream before taking effect. In Figure 4-11, if R1 sends a PathTear to R2, R2 immediately replies with a ResvTear and then sends its own PathTear downstream.

Error Signalling

Occasionally, there can be errors in RSVP signalling. These errors are signalled by PathErr or ResvErr messages. An error detected in a Path message is responded to with a PathErr message, and an error detected in a Resv message is responded to with a ResvErr message. Error messages are sent upstream toward the source of the error; a PathErr is sent toward the upstream from a downstream node, and a ResvErr is sent downstream from an upstream node. You'll read more about this in the next section.

RSVP Packets

The RSVP packet format is pretty straightforward. Every RSVP message is composed of a common header, followed by one or more objects. The number of objects in a message depends on exactly what the message is trying to accomplish.

RSVP Common Header

Figure 4-12 shows the RSVP common header format.

Table 4-21 explains the fields in the RSVP common header.

RSVP Object Class Formats

RSVP objects all have the same basic format, as illustrated in Figure 4-13.

Table 4-22 describes the fields in the basic RSVP object format.

Twenty-three different object classes are defined. Not all of them are used in RSVP signalling for MPLS TE, but for the sake of completeness, they're all listed in Table 4-23.

Each class has its own C-Type number space. The C-Type numbers are unique within a class. For example, the SESSION class has four defined C-Types: IPv4, IPv6, LSP_TUNNEL_IPv4, and LSP_TUNNEL_IPv6. The numbers assigned to these C-Types are 1, 2, 7, and 8. LABEL_REQUEST has three C-Types defined: Without Label Range, With ATM Label Range, and With Frame Relay Label Range. The numbers assigned to these C-Types are 1, 2, and 3. You can see that a C-Type of 1 is not enough to uniquely identify a message's contents; you need to look at both the class and C-Type numbers.

An RSVP message contains one or more objects. Not all messages contain all objects. The objects a message contains depends on the message definition.

Table 4-24 lists the classes and C-Types used in Cisco's implementation of RSVP-TE.

To give you the complete picture, the following sections look at all the object formats. They might not make much sense in isolation. It's probably best to scan this section, read the sections about the various message formats later in this chapter, and then come back here if you're a glutton for details and/or punishment.

SESSION Class

Figure 4-14 shows the SESSION class object format.

The SESSION object is defined in RFC 2205. RFC 3209 defines C-Type 7 (LSP_TUNNEL_IPV4), which has the four fields described in Table 4-25.

TIME_VALUES Class

Figure 4-15 shows the TIME_VALUES class object format.

RFC 2205 defines the TIME_VALUES object as the refresh period (in milliseconds) used to send Path or Resv messages.

ERROR_SPEC Class

Figure 4-16 shows the ERROR_SPEC class object format.

RFC 2205 defines the ERROR_SPEC object and also defines error codes 00 through 23. RFC 3209 defines error code 24, which holds errors specific to MPLS TE. In MPLS TE, you're most likely to see error code 00 (Confirmation—sent in response to receiving a message with a CONFIRMATION object) or error code 24.

When the error code is 00, the error value is also 00.

When the error code is 24, there are 10 possible error values, as documented in Table 4-26. There's also an error code 25 that generally only shows up when using Fast Reroute, and which is covered in more detail in Chapter 7.

Generally, the Flags field is 0 when you're using MPLS TE.

SCOPE Class

Figure 4-17 shows the SCOPE class object format.

RFC 2205 defines the SCOPE class. The SCOPE class is not used in Cisco's MPLS TE implementation because it implies a wildcard reservation style, whereas MPLS TE uses Shared Explicit or Fixed Filter (see the “Shared Explicit Reservation Style” section).

STYLE Class

Figure 4-18 shows the STYLE class object format.

The STYLE class specifies the reservation style. The three possible styles are

• Wildcard Filter

• Fixed Filter

• Shared Explicit

Cisco IOS Software uses Shared Explicit for MPLS TE reservations.

The Flags field is unused. The Option Vector is always 0x12, indicating Shared Explicit style. See the “Shared Explicit Reservation Style” section for more details.

FLOWSPEC Class

Figure 4-19 shows the FLOWSPEC class object format.

The FLOWSPEC class is defined in RFC 2210. Cisco IOS Software requests Controlled-Load service when reserving a TE tunnel. The FLOWSPEC format is complex and has many things in it that RSVP for MPLS TE doesn't use.

The FLOWSPEC is used in Resv messages—Resv, ResvTear, ResvErr, ResvConf, ResvTearConf. Its only use in MPLS TE is to use the average rate section of the FLOWSPEC to specify the bandwidth desired, in bytes. Not bits. Bytes. So if you configure a tunnel with tunnel mpls traffic-eng 100000 to request 100 Mbps of bandwidth, this gets signalled as 12,500,000 bytes per second (100 Mb is 100,000 Kb is 100,000,000 bits, which is 12,500,000 bytes).

FILTER_SPEC Class

Figure 4-20 shows the FILTER_SPEC class object format.

The FILTER_SPEC class is defined in RFC 2205. RFC 3209 adds the C-Type 7, LSP Tunnel IPv4. The IPv4 Tunnel Sender Address field specifies the router ID of the TE tunnel headend, and the LSP ID field specifies the tunnel's LSP ID. The LSP ID changes when a tunnel's properties change (a bandwidth change or path change). See the “RSVP Operations” section for more information on how this is used. FILTER_SPEC is seen only in Resv and Resv-associated messages (ResvTear, ResvErr, and so on).

SENDER_TEMPLATE Class

Figure 4-21 shows the SENDER_TEMPLATE class object format.

The SENDER_TEMPLATE is defined in RFC 2205, and RFC 3209 defines the C-Type 7, LSP Tunnel IPv4. It has the same format and purpose as the FILTER_SPEC class. Why does the same information have two different names, depending on direction? We have no idea. But it does.

SENDER_TSPEC Class

Figure 4-22 shows the SENDER_TSPEC class object format.

The SENDER_TSPEC class is generally seen only in Path messages. It's the same thing as FLOWSPEC, except that SENDER_TSPEC is seen in Path messages. Just like FLOWSPEC, the only part of SENDER_TSPEC that MPLS TE cares about is the average rate section.

ADSPEC Class

Figure 4-23 shows the ADSPEC class object format.

ADSPEC is another of those complicated formats, as defined in RFC 2210. Like SENDER_TSPEC, ADSPEC is seen only in Path messages.

RESV_CONFIRM Class

Figure 4-24 shows the RESV_CONFIRM class object format.

RESV_CONFIRM is defined in RFC 2205. It signals a request for confirmation; it appears in the Resv and ResvTear messages. The RESV_CONFIRM class sometimes shows up as CONFIRM; it's the same thing.

RSVP_LABEL Class

Figure 4-25 shows the RSVP_LABEL class object format.

The RSVP_LABEL class (sometimes just called LABEL) is defined in RFC 3209. It is a 32-bit quantity, in part because all RSVP objects must be a multiple of 4 bytes, but in frame mode, it carries the 20-bit label that the phop should use for a particular tunnel. The RSVP_LABEL class is seen only in Resv messages.

LABEL_REQUEST Class

Figure 4-26 shows the LABEL_REQUEST class object format.

The LABEL_REQUEST object requests a label. An RSVP_LABEL object responds to it. The LABEL_REQUEST object is seen only in Path messages. It contains, in the upper 16 bits, the Layer 3 Protocol Identifier (L3PID) that is carried in the label. Cisco IOS always signals 0x800 (IP); the existence of the L3PID is somewhat historical. The fact that the LABEL_REQUEST object exists is enough to tell the downstream node that it is expected to provide a label.

EXPLICIT_ROUTE Class

Figure 4-27 shows the EXPLICIT_ROUTE class object format.

The EXPLICIT_ROUTE object defines the path that an MPLS TE tunnel takes. Often called the ERO, it is defined in RFC 3209. The ERO is seen only in Path messages.

The ERO is a collection of subobjects. The subobject is an 8-byte quantity pictured in Figure 4-27; the IPv4 Prefix subobject is the only one Cisco IOS currently supports. Table 4-27 shows the fields in the IPv4 subobject.

RECORD_ROUTE Class

Figure 4-28 shows the RECORD_ROUTE class object format.

The RECORD_ROUTE object is defined in RFC 3209. There are two different RECORD_ROUTE subobjects; one is used to record the IP addresses at every hop, and the other is used to record the label used at every hop. Route recording can be configured by using the tunnel interface command tunnel mpls traffic-eng record-route.

RECORD_ROUTE allows you to do two things—record the IP address at each hop in the path, or record the label. The behavior is determined by the Label Recording bit in the SESSION_ATTRIBUTE flag string.

Table 4-28 describes the items in the RECORD_ROUTE object.

HELLO Class

Figure 4-29 shows the HELLO class object format.

The HELLO class has two C-Types: Hello Request (Type 1) and Hello ACK (Type 2). They are both encoded the same. The Source Instance and Destination Instance are two counters used to track RSVP neighbor state; think of HELLO messages as RSVP-level keepalives. See RFC 3209 (particularly Section 5.3) for more details on HELLO messages.

SESSION_ATTRIBUTE Class

Figure 4-30 shows the SESSION_ATTRIBUTE class object format.

The SESSION_ATTRIBUTE class is defined in RFC 3209. SESSION_ATTRIBUTE is seen only in Path messages.

SESSION_ATTRIBUTE has two types—with and without resource affinity (RA). Currently, Cisco IOS supports only the LSP Tunnel C-Type without RA (C-Type 7). This object has five fields, as listed in Table 4-29.

RSVP Message Formats

This section examines message formats, both in theory and in practice. The objects dissected are as follows:

• Path

• Resv

• PathTear

• ResvTear

• PathErr

• ResvErr

• ResvConf

• ResvTearConf

• Hello

All the debugs in this section were captured with debug ip rsvp path detail or debug ip rsvp resv detail.

Figure 4-31 shows the basic topology used to gather all these debugs.

There is a single tunnel from gsr4 to gsr8. Its configuration is shown in Example 4-9.

Example 4-9. gsr4 to gsr8 Tunnel Configuration

							interface Tunnel8
							ip unnumbered Loopback0
							no ip directed-broadcast
							tunnel destination 192.168.1.8
							tunnel mode mpls traffic-eng
							tunnel mpls traffic-eng priority 7 7
							tunnel mpls traffic-eng bandwidth 100000
							tunnel mpls traffic-eng path-option 10 dynamic
							end
						

Path Message

The Path message is defined in RFC 3209, as shown in Example 4-10.

Example 4-10. Path Message

<Path Message> :       <Common Header> [ <INTEGRITY> ]
                       <SESSION> <RSVP_HOP>
                       <TIME_VALUES>
                       [ <EXPLICIT_ROUTE> ]
                       <LABEL_REQUEST>
                       [ <SESSION_ATTRIBUTE> ]
                       [ <POLICY_DATA> ... ]
                       <SENDER_TEMPLATE>
                       <SENDER_TSPEC>
                       [ <ADSPEC> ]
                       [ <RECORD_ROUTE> ]

Example 4-11 shows a Path message as captured in debug ip rsvp path detail. The debug was run on the tunnel headend, gsr4.

Example 4-11. Decoded Path Message

1.  RSVP:      version:1 flags:0000 type:PATH cksum:1049 ttl:254 reserved:0      length:200
2.   SESSION              type 7 length 16:
3.     Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4
4.   HOP                  type 1 length 12: C0A80304
5.                                      : 00000000
6.   TIME_VALUES          type 1 length 8 : 00007530
7.   EXPLICIT_ROUTE       type 1 length 36:
8.     (#1) Strict IPv4 Prefix, 8 bytes, 192.168.3.5/32
9.     (#2) Strict IPv4 Prefix, 8 bytes, 192.168.10.6/32
10.     (#3) Strict IPv4 Prefix, 8 bytes, 192.168.9.8/32
11.     (#4) Strict IPv4 Prefix, 8 bytes, 192.168.1.8/32
12.   LABEL_REQUEST        type 1 length 8 : 00000800
13.   SESSION_ATTRIBUTE    type 7 length 16:
14.     setup_pri: 7, reservation_pri: 7 MAY REROUTE
15.     SESSION_NAME:gsr4_t8
16.   SENDER_TEMPLATE      type 7 length 12:
17.     Source 192.168.1.4, tunnel_id 1948
18.   SENDER_TSPEC         type 2 length 36:
19.     version=0, length in words=7
20.     service id=1, service length=6
21.     parameter id=127, flags=0, parameter length=5
22.     average rate=12500000 bytes/sec, burst depth=1000 bytes
23.     peak rate   = 12500000 bytes/sec
24.     min unit=0 bytes, max unit=0 bytes
25.   ADSPEC               type 2 length 48:
26.   version=0  length in words=10
27. General Parameters  break bit=0  service length=8
28.                                           IS Hops:1
29.                Minimum Path Bandwidth (bytes/sec):19375000
30.                       Path Latency (microseconds):0
31.                                          Path MTU:4470
32.   Controlled Load Service  break bit=0  service length=0

Table 4-30 analyzes, line by line, the output shown in Example 4-11.

Resv Message

A Resv message contains information similar to that shown in a Path message. Example 4-12 provides the Resv message definition.

Example 4-12. Resv Message

<Resv Message> :       <Common Header> [ <INTEGRITY> ]
                       <SESSION>  <RSVP_HOP>
                       <TIME_VALUES>
                       [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                       [ <POLICY_DATA> ... ]
                       <STYLE>
                       <FLOWSPEC>
                       <FILTER_SPEC>
                       <LABEL>
                       [ <RECORD_ROUTE> ]

Example 4-13 shows the message received on gsr4, as seen with debug ip rsvp resv detail.

Example 4-13. Decoded Resv Message

1.  RSVP:      version:1 flags:0000 type:RESV cksum:0000 ttl:255 reserved:0
      length:108
2.   SESSION              type 7 length 16:
3.     Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4
4.   HOP                  type 1 length 12: C0A80305
5.                                      : 00000000
6.   TIME_VALUES          type 1 length 8 : 00007530
7.   STYLE                type 1 length 8 :
8.     RSVP_SE_OPTION
9.   FLOWSPEC             type 2 length 36:
10.    version = 0 length in words = 7
11.    service id = 5, service length = 6
12.    tspec parameter id = 127, tspec flags = 0, tspec length = 5
13.    average rate = 12500000 bytes/sec, burst depth = 1000 bytes
14.    peak rate    = 2147483647 bytes/sec
15.    min unit = 0 bytes, max unit = 0 bytes
16.  FILTER_SPEC          type 7 length 12:
17.    Source 192.168.1.4, tunnel_id 1955
18.  LABEL                type 1 length 8 : 00000017

As you can see, a Resv message looks much like a Path message. The major difference between the contents of a Resv message and the contents of a Path message is that Resv messages do not contain the following items found in a Path message:

• An Explicit Route object

• A Session Attribute object

• An AdSpec

The output in Example 4-13 also highlights some differences between Resv messages and Path messages, as documented in Table 4-31.

PathTear Message

The PathTear message is composed of messages you've seen before, as shown in Example 4-14.

Example 4-14. PathTear Definition

<PathTear Message> : <Common Header> [ <INTEGRITY> ]
                     <SESSION> <RSVP_HOP>
                     <SENDER_TEMPLATE>
                     <SENDER_TSPEC>
                     [ <ADSPEC> ]

A PathTear message was captured on gsr5 when Tunnel8 on gsr4 was shut down. Example 4-15 shows the debug results.

Example 4-15. PathTear Message

RSVP:      version:1 flags:0000 type:PTEAR cksum:0000 ttl:254 reserved:0 length:132
 SESSION              type 7 length 16:
   Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4
 HOP                  type 1 length 12: C0A80304
                                    : 00000000
 SENDER_TEMPLATE      type 7 length 12:
   Source 192.168.1.4, tunnel_id 1955
 SENDER_TSPEC         type 2 length 36:
   version=0, length in words=7
   service id=1, service length=6
   parameter id=127, flags=0, parameter length=5
   average rate=12500000 bytes/sec, burst depth=1000 bytes
   peak rate   =12500000 bytes/sec
   min unit=0 bytes, max unit=0 bytes
 ADSPEC               type 2 length 48:
 version=0  length in words=10
 General Parameters  break bit=0  service length=8
                                         IS Hops:0
              Minimum Path Bandwidth (bytes/sec):2147483647
                     Path Latency (microseconds):0
                                        Path MTU:-1
 Controlled Load Service  break bit=0  service length=0

ResvTear Message

ResvTear also contains objects that might be familiar by now; there's nothing new under the sun here. The message shown in Example 4-16 was captured on gsr4. The ResvTear in question was sent by gsr5 in response to gsr4's PathTear when gsr4's Tunnel8 was shut down.

Example 4-16. ResvTear Definition

<ResvTear Message> : <Common Header> [<INTEGRITY>]
                     <SESSION>
                     <RSVP_HOP>
                     [ <SCOPE> ]
                     <STYLE>
                     <FLOWSPEC>
                     <FILTER_SPEC>

Example 4-17 shows the decode.

Example 4-17. ResvTear Message

RSVP:      version:1 flags:0000 type:RTEAR cksum:9E95 ttl:255 reserved:0 length:
  100
 SESSION              type 7 length 16:
   Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4
 HOP                  type 1 length 12: C0A80305
                                    : 00000000
 STYLE                type 1 length 8 :
   RSVP_SE_OPTION
 FLOWSPEC             type 2 length 36:
   version = 0 length in words = 7
   service id = 5, service length = 6
   tspec parameter id = 127, tspec flags = 0, tspec length = 5
   average rate = 12500000 bytes/sec, burst depth = 1000 bytes
   peak rate    = 2147483647 bytes/sec
   min unit = 0 bytes, max unit = 0 bytes
 FILTER_SPEC          type 7 length 12:
   Source 192.168.1.4, tunnel_id 1956
 CONFIRM              type 1 length 8 : C0A80305

About the only thing notable and new here is that this message contains a CONFIRM object. The CONFIRM object is a request for confirmation that the ResvTear actually took place. The node requesting the confirmation is 192.168.3.5, which is the interface address on gsr5 on the subnet between gsr4 and gsr5. A Cisco node responds to a ResvTear that contains a CONFIRM object by sending a ResvTearConfirm object. Interoperability with non-Cisco equipment isn't a problem; any device that doesn't understand what to do with a ResvTear with CONFIRM just ignores the CONFIRM message. For MPLS TE, not receiving a ResvTearConfirm won't hurt anything.

PathErr Message

Example 4-18 shows the PathErr message definition.

Example 4-18. PathErr Definition

<PathErr message> : <Common Header> [ <INTEGRITY> ]
                    <SESSION> <ERROR_SPEC>
                    [ <POLICY_DATA> ...]
                    <SENDER_TEMPLATE>
                    <SENDER_TSPEC>
                    [ <ADSPEC> ]

This error message was captured on gsr4. A PathErr with a bogus hop in the ERO was sent to gsr5, which forwarded it to gsr6. This error message is gsr6 complaining about that bad hop. Example 4-19 decodes this error message.

Example 4-19. PathErr Decode

1.  RSVP:      version:1 flags:0000 type:PERR cksum:0000 ttl:255 reserved:0      length:132
2.   SESSION              type 7 length 16:
3.     Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4
4.   ERROR_SPEC           type 1 length 12:
5.     Node 192.168.10.6
6.     Code 24
7.     Value 2
8.     Flags 0x00
9.   SENDER_TEMPLATE      type 7 length 12:
10.     Source 192.168.1.4, tunnel_id 8909
11.   SENDER_TSPEC         type 2 length 36:
12.        version=0, length in words=7
13.                   Minimum Path Bandwidth (bytes/sec):2147483647
14.                          Path Latency (microseconds):0
15.                                             Path MTU:-1
16.   Controlled Load Service  break bit=0  service length=0

ERROR_SPEC (lines 4 through 8) is a new object here. The Node field is the address of the node that detected the error—192.168.10.6 is gsr6's IP address on the subnet between gsr5 and gsr6. The Code of 24 indicates that this error is of type “Routing Problem,” and the Value of 2 means that the specific routing problem is “Bad strict node.”

ResvErr Message

Example 4-20 provides the ResvErr message definition.

Example 4-20. ResvErr Definition

<ResvErr Message> : <Common Header> [ <INTEGRITY> ]
                    <SESSION>
                    <RSVP_HOP>
                    <ERROR_SPEC>
                    [ <SCOPE> ]
                    [ <POLICY_DATA> ]
                    <STYLE>
                    <FLOWSPEC>
                    <FILTER_LIST>

Because of how RSVP signalling works, it's difficult to cause a ResvErr on purpose. Most errors that could be caught by a ResvErr would be caught first by a PathErr, so they'd never make it this far. A ResvErr looks a lot like a PathErr, though, so the decodes look similar.

ResvConf Message

ResvConf messages are sent in response to a Resv message containing a CONFIRM object. Currently, the Cisco IOS Software does not put the CONFIRM object in a ResvConf—at least, not for MPLS TE. Example 4-21 shows the message definition for a ResvConf.

Example 4-21. ResvConf Definition

<ResvConf message> : <Common Header> [ <INTEGRITY> ]
                     <SESSION> <ERROR_SPEC>
                     <RESV_CONFIRM>
                     <STYLE>
                    <FLOWSPEC>
                    <FILTER_LIST>

ResvTearConf Message

The ResvTearConf message is used by Cisco to confirm that a ResvTear took place. It's proprietary, but is easily identifiable in debugs. ResvTearConf is sent in response to a Resv message that contains a CONFIRM object.

Example 4-22 shows the message definition for the ResvTearConf message.

Example 4-22. ResvTearConf Definition

<ResvTearConf Message> : <Common Header>
                         <SESSION>
                         <ERROR_SPEC>
                         <CONFIRM>
                         <STYLE>
                         <FLOWSPEC>
                         <FILTER_SPEC>

Example 4-23 shows the decode of a ResvTearConf message.

Example 4-23. ResvTearConf Decode

RSVP:      version:1 flags:0000 type:RTEAR-CONFIRM cksum:0000 ttl:255 reserved:0
  length :100
 SESSION              type 7 length 16:
   Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4
 ERROR_SPEC           type 1 length 12:
   Node 192.168.9.6
   Code 0
   Value 0
   Flags 0x00
 CONFIRM              type 1 length 8 : C0A80908
 STYLE                type 1 length 8 :
   RSVP_SE_OPTION
 FLOWSPEC             type 2 length 36:
   version = 0 length in words = 7
   service id = 5, service length = 6
   tspec parameter id = 127, tspec flags = 0, tspec length = 5
   average rate = 12500000 bytes/sec, burst depth = 1000 bytes
   peak rate    = 2147483647 bytes/sec
   min unit = 0 bytes, max unit = 0 bytes
 FILTER_SPEC          type 7 length 12:
   Source 192.168.1.4, tunnel_id 3992

Two things stand out in this decode. One is that the ResvTearConf contains an ERROR_SPEC message. An ERROR_SPEC with a Code of 0x0 is in fact a confirmation; this is what's sent in response to receiving a message with a CONFIRM request in it. The Node address is the node that is sending the ResvTearConf; the CONFIRM object contains the address of the node that the ResvTearConf message is being sent to. The Node address is 192.168.9.6, and the CONFIRM object turns out to be 192.168.9.8. This decode was captured on gsr8. It shows the incoming ResvTearConf that came from gsr6. A ResvTearConf acts much like a ResvErr, in that it is sent hop-by-hop from the headend to the tail.

Hello Message

The Hello message format is pretty straightforward. The Hello message itself is shown in Example 4-24.

Example 4-24. Hello Definition

<Hello Message> : <Common Header> [ <INTEGRITY> ]
                  <HELLO>

RSVP Operation

By now, you should have a pretty good grip on the RSVP components—at least as far as MPLS TE is concerned. A lot of RSVP stuff that doesn't apply to MPLS TE (more about the QoS specifications, flow merging, and so on) has been skipped over, but unless you run a non-TE RSVP network now, you'll never miss it.

You might be wondering how some of the protocol mechanisms fit together. This section is designed to answer these questions:

• What is make-before-break?

• How do the refresh mechanisms work?

• When, where, and to whom are messages sent?

• What good are strict and loose ERO subobjects?

• What about implicit and explicit null signalling at the penultimate hop?

What Is Make-Before-Break?

Make-before-break is an RSVP-TE mechanism that allows you to change some characteristics of a TE tunnel (namely, bandwidth and the path a tunnel takes) with virtually no data loss and without double-booking bandwidth. Consider Figure 4-32.

The bandwidths indicated are before any bandwidth is reserved from the network.

If R1 signals a 35 Mb request to the network, it goes over the top path, R1→R2→R5. That leaves the R1→R2 segment with 10 Mb available bandwidth and the R2→R5 segment with 65 Mb available bandwidth.

What if, at some point in the future, R1 wants to increase its reservation size to 80 Mb? This bandwidth has to come from the bottom path, because there's no way to get an 80 Mb reservation across the R1→R2→R5 path. So R1 reserves 80 Mb along the path R1→R3→R4→R5. This leaves 20 Mb available along each link in the bottom path. For a short while, R1 reserves bandwidth across both paths and therefore reserves a total of 115 Mb (35 Mb across the top and 80 Mb across the bottom) of bandwidth. However, the 35 Mb reservation is released soon after the 80 Mb reservation is made, and all is well. Make-before-break is simply the rule that a tunnel headend should not release an old reservation until the new reservation is in place; this minimizes data loss.

Sounds simple, right? It is. But there's a tricky piece to it. Look at Figure 4-33.

This looks like Figure 4-32, except that the link from R4 to R5 now goes from R4 to R2. R1 still makes its 35 Mb reservation across R1→R2→R5; nothing changes there.

Then what happens? R1 tries to make an 80 Mb reservation across R1→R3→R4→ R2→R5. But it can't! Because the first reservation from R1 to R5 has consumed 35 Mb of the 100 Mb from R2 to R5, that leaves the R2→R5 link with only 65 Mb of bandwidth! If R1 were to signal the reservation anyway, R2 would see an 80 Mb bandwidth request for a link that has only 65 Mb of capacity and would reject the reservation.

What to do now? R1 could tear down the R1→R2→R5 reservation and then build the R1→R3→R4→R2→R5 reservation. But that's stupid. During the window when the old reservation is gone and the new one is being established, traffic forwarded from R1 to R5 might not have particularly good service because it follows the shortest path, which in this case, means putting 80 Mb of data down a path whose smallest link is 45 Mb. This is bad. Even though R1 might not start out by sending that much data down the shortest path, the general idea of tearing down one reservation to make room for another is still not a good one. It's like tearing down your house in order to build a new one on the same lot: Where do you live in the meantime?

Shared Explicit Reservation Style

Fortunately, there is a better way to do this. You might recall that RSVP has a facility called Shared Explicit (SE). SE is a reservation style that allows an existing LSP to share bandwidth with itself so that double booking doesn't happen. This avoids problems such as those shown in Figure 4-33, where, even if you allowed double booking, the second reservation would still never get established.

So how does SE work? SE reservations have two components:

• Requesting SE reservation style from the network

• Being able to identify that a given reservation is “the same” as an existing reservation, so the bandwidth should be shared

SE reservation style is requested by the tunnel headend using a flag in the SESSION_ATTRIBUTE object. The alternative to SE is something called Fixed Filter (FF), but it's never used by Cisco's MPLS TE implementation, so it's not discussed here. Suffice it to say, FF doesn't allow you to share bandwidth the way SE does, so an FF reservation would still leave you with the problem presented in Figure 4-33.

But how do you identify two reservations as the same one so that they can share bandwidth? As it turns out, this is relatively easy. All RSVP reservations are uniquely identified with a five-tuple of {Sender Address, LSP ID, Endpoint Address, Tunnel ID, Extended Tunnel ID}. The first two items in this five-tuple are found in the SENDER_TEMPLATE (and FILTER_SPEC) objects; the last three are found in the SESSION object. If two Path message are seen in which all five of these are the same, they are considered two representatives of the same reservation.

The Sender Address is the RID of the tunnel headend. The Endpoint Address is the RID of the tunnel tail. The Extended Tunnel ID is either all 0s or an IP address on the router; this is used in some protection schemes, but it doesn't matter for this discussion. And the Tunnel ID is the tunnel interface number at the headend.

Those four are pretty simple. But that leaves the LSP ID. Think of the LSP ID as an “instantiation counter”: Every time the tunnel changes either its bandwidth requirement or the path it takes, the LSP ID increments by 1.

The rule of the SE reservation process for MPLS TE is that if two reservations are seen with the same five-tuple, except that they have different LSP IDs, the two reservations are for different LSPs, but they share bandwidth.

Assume that in Figure 4-33, R1's RID is 1.1.1.1 and R5's is 5.5.5.5. Table 4-32 shows what R1 sends out and what R4 does with the information it receives.

In this way, both Res1 and Res2 are allowed to coexist until Res1 is removed from the network. The implication is that after Res2 starts to share the reservation with Res1, Res1 will shortly no longer be active and will never try to compete with Res2 for bandwidth. In other words, after Res2 has shared the bandwidth with Res1, the implicit assumption is that Res1 will no longer try to use the bandwidth at the same time as Res2.

Wait a minute. Why does Res2 ask for 80 Mbps? Can't it just ask for 45 Mbps, leave the Res1 reservation in place, and get along just fine?

Well, sure. Except for the major holes in that plan, it works fine. Here are the two big holes in that idea:

• Keeping Res1 in place means consuming bandwidth across the R1→R2 link that's no longer going to be used.

• Asking for only 45 Mbps instead of 80 Mbps reserves only 45 Mbps across segments such as R1→R3, R3→R4, and R4→R2. This can lead to problems because Res2 might actually have 80 Mbps sent down it, and if someone else reserves the other 55 Mbps along any part of the R1→R3→R4→R2 path, there's likely to be unwarranted congestion.

But other than that, no, there are no problems whatsoever with this approach. None.

So that's make-before-break. SE reservation style is, as you can see, an integral part of the make-before-break strategy.

How Do the Refresh Mechanisms Work?

This can be confusing to most people. As you already know, RSVP is a soft-state protocol. As such, reservations are periodically refreshed. Reservations are sent using Path and Resv messages. There is no difference between the Path and Resv messages used to set up the LSP initially and the ones used to refresh it; the packet formats are the same. The way a router tells a new setup from a refresh is to see if it has an existing reservation with a five-tuple that matches the Path or Resv message in question.

Two major points to understand when talking about refresh mechanisms are

• The refresh timers are jittered.

• Path and Resv messages are sent independently between two routers

Refresh Timers Are Jittered

As you know, Path and Resv messages are sent every 30 seconds. They're not really sent every 30 seconds, however; they're sent on a 30-second timer with 50 percent jitter. So a given reservation has a Path message sent to refresh it every 15 to 45 seconds. It's the same deal with the Resv message for that reservation—every 15 to 45 seconds. And so it is for every refresh message.

The actual refresh formula is in RFC 2205, Section 3.7. The general idea is that a neighbor sends its refresh interval (R) to its neighbor in the TIME_VALUES object in its Path and Resv messages. Each router also knows how many messages it is willing to miss before declaring the reservation dead (call this K).

The neighbor computes a holdtime L for this message with the formula

In the current IOS implementation, R is 30 seconds and K is 3. So L is at least 157.5 seconds. This means that a router can go just under 157.5 seconds with no refresh before tearing down a neighbor. This is enough time that a router can have three consecutive intervals of worst-case jitter (with all packets lost) on the refresh timer (45 seconds) before timing out.

What this means is that, occasionally, you see something like Figure 4-34, in which the Path message refresh timer happened to fire at 00:00 and 00:45, and the Resv message refresh timer happened to fire at 00:15 and 00:30.

This is perfectly normal. It's important to understand that Path and Resv messages are not sent in ping/ACK fashion, but are sent independently from one another. This brings us to the next point.

Path and Resv Messages Are Sent Independently

Take a look at Figure 4-35.

Assume that a single tunnel is set up from gsr4 to gsr8.

In addition to Path and Resv messages being on separate timers, when used for refreshes, they're not propagated hop-by-hop from the head to the tail, but instead are sent independently by each node. One possible refresh scenario might look like Figure 4-36.

Figure 4-36 is a bit of an oversimplification; you won't see gsr4 send a Path message every 15 seconds five times in a row. Specifically, Rule 5 of section 3.7 of RFC 2205 limits the amount of time between any two consecutive refreshes. This figure, however, conveys the general idea. Path and Resv messages, when used for refresh, are independent of each other and are not propagated from head to tail.

When, Where, and to Whom Are Messages Sent?

As mentioned before, there are nine RSVP message types. Table 4-33 summarizes what messages are sent when and where.

This table has five columns:

• Message— The message type.

• Function— What the message is used for.

• Direction— The direction in which the message is sent. Downstream means “toward the tunnel tail, away from the head.” Upstream means “toward the tunnel head, away from the tail.”

• Destination Address— The destination IP address on the packet. Some RSVP messages carry the tunnel tail RID as their destination IP address, and others carry the IP address of the next-hop interface. All RSVP messages have their outgoing interface as the packet's source address.

• Router Alert?— Some RSVP messages carry the Router Alert option (as specified in RFC 2113), and others don't.

To help understand the terminology (upstream/downstream, tail versus next-hop destination address, and the existence of Router Alert), see Figure 4-37.

In Figure 4-37, gsr4 wants to signal an LSP from gsr4 to gsr8 along the path gsr4→gsr5→gsr6→gsr8.

After gsr4 computes the path it wants the tunnel to take, gsr4 sends a Path message out on the wire between gsr4 and gsr6. The Path message's contents are discussed in the next section. The destination IP address on the packet is gsr8's TE RID. This Path message has the Router Alert option.

Because the Router Alert option is set in the packet, gsr6 examines it. gsr6 makes some modifications to the packet (see the EXPLICIT_ROUTE object explanation in Table 4-27) and sends it out its top link to gsr8. gsr8 also examines the packet, modifies it, and sends it to gsr8.

At every hop in the path, the destination IP address on the Path message remains the same—gsr8. The Router Alert (RA) is always present in the Path message.

When gsr8 sends the Resv message upstream, the destination address is gsr6 (specifically, gsr6's address on the link between gsr6 and gsr8). Also, the Router Alert option is never present in the packet.

You might notice a pattern here:

• All messages that have the RA option set are sent in the downstream direction.

• All messages that have the RA option set have the tunnel tail as their destination IP address.

• All messages either have the Router Alert option set or put the next hop (either upstream or downstream) interface address as the destination address on the packet.

Why are things done this way? Largely for reasons that don't exist in an MPLS network. Controlling which messages carry the Router Alert option and which messages have the next hop as their destination address allows routers to detect the presence of non-RSVP routers in the path. But you can't build a TE tunnel through a router that doesn't speak RSVP, because MPLS Traffic Engineering needs not only a bandwidth reservation, but also a label allocation.

If you are interested, check out Section 2.9 of RFC 2205 for details on how this works.

Strict Versus Loose ERO Subobject

The discussion of the EXPLICIT_ROUTE object showed that an L (Loose) bit can be set on a hop in the ERO to indicate a Loose route. But what is a Loose route?

The ERO is encoded as a series of subobjects called abstract nodes. An abstract node can be either an IPv4 address, an IPv6 address, or an autonomous system. Cisco IOS Software currently supports only IPv4 addresses in the ERO.

Each subobject can be either a strict hop or a loose hop. Most of what Cisco IOS Software uses are strict hops, save some interarea traffic engineering uses and other specific cases.

When a router processes a strict hop, the IPv4 address in the subobject must be directly connected to the router doing the processing, or there is an error in the ERO.

Sometimes, though, the subobject is a loose hop. If a router processes an ERO subobject with a loose hop, it is the responsibility of that router to generate a set of strict hops to get this Path message to the destination and replace the single loose hop with the newly generated set of strict hops.

Implicit Versus Explicit Null

As you know, a tunnel tail can signal two kinds of labels—implicit null and explicit null. Explicit null is signalled by using the value 0 in the Label field of the LABEL object. Implicit null is signalled by using the value 3 in the Label field of the LABEL object.

By default, the tunnel tail node signals explicit null in its Resv message:

LABEL                type 1 length 8 : 00000000

However, if you look at the penultimate hop, as demonstrated in Example 4-25, you see that the explicit-null value is interpreted as implicit null, on both the tail (gsr8) and the penultimate hop (gsr6).

Example 4-25. Explicit Null Interpreted as Implicit Null

gsr8#show mpls traffic-eng tunnels role tail
LSP Tunnel gsr4_t8 is signalled, connection is up
  InLabel  : POS0/1, implicit-null
  OutLabel :  -

gsr6#show mpls traffic-eng tunnels role middle
LSP Tunnel gsr4_t8 is signalled, connection is up
  InLabel  : POS3/2, 16
  OutLabel : POS3/0, implicit-null

How did we get into this state? It's a long story, and mostly historical. You can use a few knobs to control this behavior. On the tunnel tail, you can use the knob mpls traffic-eng signalling advertise implicit-null to make the tail advertise implicit null:

LABEL                type 1 length 8 : 00000003

But no matter what you do on the tail, the penultimate hop still interprets the advertised label as implicit null, as confirmed by the output shown in Example 4-26.

Example 4-26. Confirming Implicit-Null Interpretation on the Penultimate Hop

gsr6#show mpls traffic-eng tunnels role middle
LSP Tunnel gsr4_t8 is signalled, connection is up
  InLabel  : POS3/2, 16
  OutLabel : POS3/0, implicit-null

If you care about sending explicit null from the penultimate hop to the tail, you need to enable the hidden command mpls traffic-eng signalling interpret explicit-null verbatim on the penultimate hop. After that, things look the way you'd expect them to, as shown in Example 4-27.

Example 4-27. Interpreting Explicit Null Properly on the Penultimate Hop

gsr6#show run | include verbatim
mpls traffic-eng signalling interpret explicit-null verbatim

gsr6#show mpls traffic-eng tunnels role middle
LSP Tunnel gsr4_t8 is signalled, connection is up
  InLabel  :    POS3/2, 12304
  OutLabel : POS3/0, explicit-null
						

When you think about it, how often do you care if it's implicit null or explicit null? It makes little or no difference almost all the time. But the knob's there if you need to use it. One place you might have a need for explicit rather than implicit null is with QoS. See Chapter 6, “Quality of Service with MPLS TE”—specifically, the section “Label Stack Treatment”—for more details.

RSVP Message Pacing

When there is a disruption in the network (a link flap, a router reboot, and so on), this can result in a significant amount of signalling. If a link flaps, for example, a PathErr or ResvErr needs to be sent for every tunnel crossing that link. If there are 2000 TE tunnels across a link, that means 2000 PathErrs/ResvErrs. It is possible to send more messages out an interface than the next hop can handle.

When RSVP messages are sent out, they are sent either hop-by-hop or with the router alert bit set. This means that every router along the path for these RSVP messages needs to pay attention to them. Operationally, this means that every RSVP message that comes in on an interface goes through that interface's input queue. The input queue has a default size of 75 packets, as you can see in Example 4-28.

Example 4-28. Displaying the Input Queue Size

gsr5#show interfaces p5/0
POS5/0 is up, line protocol is up
  Hardware is Packet over SONET
  Internet address is 192.168.12.5/24
  MTU 4470 bytes, BW 622000 Kbit, DLY 100 usec, rely 255/255, load 1/255
  Encapsulation HDLC, crc 16, loopback not set
  Keepalive set (10 sec)
  Scramble disabled
  Last input 00:00:00, output 00:00:02, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 7000 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     11687 packets input, 10119458 bytes, 0 no buffer
     Received 0 broadcasts, 16 runts, 0 giants, 0 throttles
              0 parity
     622 input errors, 606 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     11674 packets output, 10141348 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     1 carrier transitions

After messages go into the input queue, they are processed by the application they're destined for; in this case, RSVP is the focus of attention. All other applications that terminate on a router take their packets from the input queue—BGP, SNMP, Telnet, and so forth.

If there's enough signalling traffic in the network, it is possible for an interface to receive more packets for its input queue than it can hold. If a packet is received that is destined for the input queue, and the input queue for that interface is full, the packet is dropped.

This has unfortunate side effects on RSVP. If an RSVP message is lost, the node that sent it will not send it again until it's time to refresh that message—30 seconds, plus or minus 50% jitter.

One way to solve this problem is to make the input queue very large. You can adjust the input queue size with the command hold-queue size input. Making the input queue significantly bigger is a perfectly valid solution, especially on higher-end platforms that don't use the input queue to switch packets. However, no matter how much bigger you make the input queue, you run the risk of having a burst of signalling traffic that fills up the input queue, resulting in dropped packets and slower signalling convergence.

The best solution to this problem is RSVP message pacing. Message pacing controls the rate at which RSVP messages are sent so that the input queue on the other end of the link is not overloaded.

Message pacing is enabled with the global command ip rsvp msg-pacing, as demonstrated in Example 4-29.

Example 4-29. Configuring RSVP Message Pacing

gsr5(config)#ip rsvp msg-pacing ?
  burst    Configure a max burst of rsvp msgs queued to an output interface
  maxsize  Configure max number of rsvp msgs queued to an output interface
  period   Configure a period in msecs
  <cr>

Table 4-34 lists the three options available for the ip rsvp msg-pacing command.

With the defaults for burst, maxsize, and period, this means that up to 200 messages per second can be sent out a given interface, and up to 500 messages (so 2.5 seconds of messages) can be queued.

Message pacing is disabled by default, but it's a good idea to enable it. If pacing doesn't kick in, nothing will be hurt, and it can only help if you end up generating a large burst of messages.

RSVP in the Real World

So far, this section has covered a lot of RSVP theory, but not much in the way of hands-on stuff. Although there's not much to configuring RSVP, there are a fair number of useful show commands you should know about.

All show commands in this section were captured on a router using the topology shown in Figure 4-38, which you should be familiar with by now.

The tunnel topology has changed a bit. There are 50 TE tunnels from gsr4 to gsr8, each reserving 2 Mbps of bandwidth, and 50 TE tunnels from gsr8 to gsr4, each reserving 1 Mbps of bandwidth.

This section doesn't cover all the possible RSVP show commands (see the documentation for the relevant Cisco IOS Software release you're using, or just use ? and check for yourself), but it covers the four most useful ones:

• show ip rsvp counters

• show ip rsvp interface

• show ip rsvp neighbor

• show ip rsvp reservation

show ip rsvp counters Command

show ip rsvp counters shows you counts, either per-interface or across the entire box, of the RSVP message types that have happened since the router has been up. Example 4-30 demonstrates all the possible options with this command.

Example 4-30. show ip rsvp counters Options

gsr5#show ip rsvp counters ?
  interface  RSVP statistics for interface
  summary    RSVP statistics summary
  |          Output modifiers
  <cr>

Example 4-31 shows the basic output from this command (with most interfaces removed for readability).

Example 4-31. show ip rsvp counters Example

gsr5#show ip rsvp counters
...
POS4/1                  Recv      Xmit                        Recv      Xmit
   Path                 1956      1143   Resv                 1137      1270
   PathError               0         0   ResvError               0         0
   PathTear                0        38   ResvTear               38         0
   ResvConfirm             0         0   ResvTearConfirm         0        38
   UnknownMsg              0         0   Errors                  0         0
POS4/2                  Recv      Xmit                        Recv      Xmit
   Path                 1164      1277   Resv                 1294      1148
   PathError               0         0   ResvError               0         0
   PathTear               38         0   ResvTear                0        38
   ResvConfirm             0         0   ResvTearConfirm        38         0
   UnknownMsg              0         0   Errors                  0         0
...
Non RSVP i/f's          Recv      Xmit                        Recv      Xmit
   Path                    0         0   Resv                    0         0
   PathError               0         0   ResvError               0         0
   PathTear                0         0   ResvTear                0         0
   ResvConfirm             0         0   ResvTearConfirm         0         0
   UnknownMsg              0         0   Errors                  0         0
All Interfaces          Recv      Xmit                        Recv      Xmit
   Path                 3120      2420   Resv                 2431      2418
   PathError               0         0   ResvError               0         0
   PathTear               38        38   ResvTear               38        38
   ResvConfirm             0         0   ResvTearConfirm        38        38
   UnknownMsg              0         0   Errors                  0         0

Using the interface or summary option gives you counters for the specified interface or gives you only the All Interfaces output, shown at the bottom of Example 4-31.

show ip rsvp interface Command

show ip rsvp interface lists which interfaces have RSVP configured on them, how much bandwidth is currently allocated (reserved), and the interface and flow maximum. Example 4-32 shows typical output from this command.

Example 4-32. show ip rsvp interface Example

gsr5#show ip rsvp interface
interface    allocated  i/f max  flow max sub max
PO0/0        0G         1866M    1866M    0G
PO1/0        0G         0G       0G       0G
PO3/0        0G         3169033K 3169033K 0G
PO4/0        0G         116250K  116250K  0G
PO4/1        50M        116250K  116250K  0G
							PO4/2        100M       116250K  116250K  0G
PO5/0        0G         466500K  466500K  0G

You might recall from Chapter 3 that the command ip rsvp bandwidth x y configures an interface's reservable bandwidth. x is the i/f max, and y is the flow max, which MPLS TE doesn't use. In this output, POS4/2 is the interface on gsr5 that faces gsr6. RSVP reservations are always made from the bandwidth pool on the outgoing interface.

Note that 50 Mbps is reserved on POS4/1 (the interface facing gsr4) and 100 Mbps is reserved on POS4/2 (the interface facing gsr6). The 50 Mbps corresponds to the 50 1-Mbps tunnels from gsr8 to gsr4, and the 100 Mb corresponds to the 50 2-Mbps tunnels from gsr4 to gsr8.

show ip rsvp neighbor Command

As shown in Example 4-33, output from the show ip rsvp neighbor command is pretty easy to understand.

Example 4-33. show ip rsvp neighbor Example

gsr5#show ip rsvp neighbor
Interface  Neighbor        Encapsulation
PO4/1      192.168.3.4     RSVP
PO4/2      192.168.10.6    RSVP

One thing to remember is that RSVP does not have an explicit neighbor discovery phase. This means that if you enable RSVP on two interfaces, they will not see each other as RSVP neighbors until they start seeing Path and Resv messages from one another. Just having the interface RSVP enabled isn't enough.

The Encapsulation column can be either RSVP or UDP, but for MPLS TE it is always RSVP.

You can specify an interface as an optional parameter to this command, but this doesn't result in anything more exciting than the output of show ip rsvp neighbor for only one interface.

show ip rsvp reservation Command

This command is interesting. It has two distinct versions of output, show ip rsvp reservation and show ip rsvp reservation detail. Example 4-34 shows typical output from this command without the detail option.

Example 4-34. show ip rsvp reservation Output

gsr5#show ip rsvp reservation
To            From          Pro DPort Sport Next Hop      I/F   Fi Serv BPS Bytes
192.168.1.4   192.168.1.8   0   1     1     192.168.3.4   PO4/1 SE LOAD 1M    1K
192.168.1.4   192.168.1.8   0   2     1     192.168.3.4   PO4/1 SE LOAD 1M    1K
192.168.1.4   192.168.1.8   0   3     1     192.168.3.4   PO4/1 SE LOAD 1M    1K
192.168.1.4   192.168.1.8   0   4     1     192.168.3.4   PO4/1 SE LOAD 1M    1K
192.168.1.4   192.168.1.8   0   5     1     192.168.3.4   PO4/1 SE LOAD 1M    1K
192.168.1.4   192.168.1.8   0   6     1     192.168.3.4   PO4/1 SE LOAD 1M    1K
192.168.1.4   192.168.1.8   0   7     1     192.168.3.4   PO4/1 SE LOAD 1M    1K
192.168.1.4   192.168.1.8   0   8     1     192.168.3.4   PO4/1 SE LOAD 1M    1K
192.168.1.4   192.168.1.8   0   9     1     192.168.3.4   PO4/1 SE LOAD 1M    1K
192.168.1.4   192.168.1.8   0   10    1     192.168.3.4   PO4/1 SE LOAD 1M    1K
...
192.168.1.8   192.168.1.4   0   41    15    192.168.10.6  PO4/2 SE LOAD 2M    1K
192.168.1.8   192.168.1.4   0   42    15    192.168.10.6  PO4/2 SE LOAD 2M    1K
192.168.1.8   192.168.1.4   0   43    16    192.168.10.6  PO4/2 SE LOAD 2M    1K
192.168.1.8   192.168.1.4   0   44    15    192.168.10.6  PO4/2 SE LOAD 2M    1K
192.168.1.8   192.168.1.4   0   45    15    192.168.10.6  PO4/2 SE LOAD 2M    1K
192.168.1.8   192.168.1.4   0   46    15    192.168.10.6  PO4/2 SE LOAD 2M    1K
192.168.1.8   192.168.1.4   0   47    15    192.168.10.6  PO4/2 SE LOAD 2M    1K
192.168.1.8   192.168.1.4   0   48    15    192.168.10.6  PO4/2 SE LOAD 2M    1K
192.168.1.8   192.168.1.4   0   49    15    192.168.10.6  PO4/2 SE LOAD 2M    1K
192.168.1.8   192.168.1.4   0   50    15    192.168.10.6  PO4/2 SE LOAD 2M    1K

If the full output from show ip rsvp reservation were printed here, it would have 100 lines—50 reservations from gsr4 to gsr8 and 50 from gsr8 to gsr4. Example 4-32 shows the first ten tunnels from gsr8 to gsr4 (to 192.168.1.4 and from 192.168.1.8) and the last ten tunnels from gsr4 to gsr8 (to 192.168.1.8 and from 192.168.1.4).

Table 4-35 documents the fields shown in Example 4-34.

show ip rsvp reservation also has a detail option. It provides information similar to the output shown in Example 4-35.

Example 4-35. show ip rsvp reservation detail Output

gsr5#show ip rsvp reservation detail

RSVP Reservation. Destination is 192.168.1.4, Source is 192.168.1.8,
  Protocol is 0  , Destination port is 1, Source port is 1
  Next Hop is 192.168.3.4, Interface is POS4/1
  Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
  Average Bitrate is 1M bits/sec, Maximum Burst is 1K bytes
  Label is 0
						

Not only is this information easier to read, but it also contains the label that was received in the Resv for this tunnel. In this case, the label is 0 because this tunnel is destined for 192.168.1.4, and gsr5 is the penultimate hop. Look at a TE tunnel going from gsr4 to gsr8 in Example 4-36.

Example 4-36. show ip rsvp reservation detail Output

gsr5#show ip rsvp reservation detail 192.168.1.8
RSVP Reservation. Destination is 192.168.1.8, Source is 192.168.1.4,
  Protocol is 0  , Destination port is 1, Source port is 16
  Next Hop is 192.168.10.6, Interface is POS4/2
  Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
  Average Bitrate is 2M bits/sec, Maximum Burst is 1K bytes
  Label is 12311
						

In this case, you see that the learned label for this tunnel is 12311. This matches the output of show mpls traffic-eng tunnels in Example 4-37, as it should.

Example 4-37. show mpls traffic-eng tunnels Output

gsr5#show mpls traffic-eng tunnels name gsr4_t1

LSP Tunnel gsr4_t1 is signalled, connection is up
  InLabel  : POS4/1, 12342
  OutLabel : POS4/2, 12311
  RSVP signalling Info:
       Src 192.168.1.4, Dst 192.168.1.8, Tun_Id 1, Tun_Instance 16
    RSVP Path Info:
      My Address: 192.168.3.5
      Explicit Route: 192.168.10.6 192.168.9.8 192.168.1.8
      Record   Route:  NONE
      Tspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=2000 kbits
    RSVP Resv Info:
      Record   Route:  NONE
      Fspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=Inf

show ip rsvp reservation gives you the option of an IP address or host name. Using that option shows you all tunnels destined for the specified router ID.