Examining the Resv Message
Purpose
Each receiver host sends reservation request (Resv) messages upstream toward senders and sender applications. Resv messages must follow exactly the reverse path of Path messages. Resv messages create and maintain a reservation state in each router along the way. Resv messages are sent periodically to refresh reservation states.
Figure 12 shows an RSVP Resv message that flows upstream from R3 toward the destination interface address (10.1.13.1) on ingress router R1, ensuring that the network allocates resources along the reverse path that the downstream messages followed.
To ensure that Resv messages are displayed in the output, include the resv flag at the [edit protocols rsvp traceoptions] hierarchy level.
Action
To examine the Resv message, enter the following JUNOS CLI command:
user@R1>monitor startfilename
Sample Output 1
[edit protocols rsvp]
user@R1# show
traceoptions {
file rsvp-log;
flag packets detail;
flag resv detail;
}
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
Sample Output 2
user@R1> clear log rsvp-log
user@R1> monitor start rsvp-log
user@R1>
*** rsvp-log ***
Jun 29 15:57:19 RSVP recv Resv 10.1.13.2->10.1.13.1 Len=136 so-0/0/2.0
Jun 29 15:57:19 Session7 Len 16 10.0.0.5(port/tunnel ID 26619) Proto 0
Jun 29 15:57:19 Hop Len 12 10.1.13.2/0x08678198
Jun 29 15:57:19 Time Len 8 30000 ms
Jun 29 15:57:19 Style Len 8 FF
Jun 29 15:57:19 Flow Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500
Jun 29 15:57:19 Filter7 Len 12 10.0.0.1(port/lsp ID 5)
Jun 29 15:57:19 Label Len 8 100624
Jun 29 15:57:19 RecRoute Len 28 10.1.13.2 10.1.36.2 10.1.56.1
monitor stop
What It Means
Sample Output 1 shows the configuration of RSVP tracing on ingress router R1. The packets and resv flags are included at the [edit protocols rsvp traceoptions] hierarchy level to provide slightly different information about RSVP traffic. For more information about RSVP tracing flags, see Table 17. The detail option is included to show granular details about the configured flags.
Sample Output 2 shows clear commands, the output for the rsvp-log file, and that monitoring was started and then stopped.
The first line of the rsvp-log output indicates that this is an Resv message. The source address of the IP packet is 10.1.13.2 (R3). The destination address of the IP packet is 10.1.13.1 (R1). The incoming interface on R1 is interface so-0/0/2.
All subsequent lines of sample output indicate object values for this Resv message and are indented in the output. To facilitate this discussion, each line of output for each object is displayed before the corresponding explanation.
The Session object (Session7) indicates that this is C-Type 7 for LSP tunnel IPv4, defined in RFC 3209. The RSVP session is defined by three values: the destination IP address (10.0.0.5), a 16-bit field that indicates the tunnel ID (26619) and is unique for the length of the RSVP session, and the protocol number (Proto 0). Note that the Session object in the Path message on "Session7 Len 16 10.0.0.5(port/tunnel ID 26619) Proto 0" is the same as in the Resv message.
The Hop object indicates the IP address of the interface (10.1.13.2) on the router (R3) sending the Resv message.
The Time object indicates how long before RSVP must refresh the session state (30000 ms). By default the value is recorded in milliseconds. RFC 3209 dictates that a router can refresh the state within plus or minus 50 percent of the time. In this case, RFC 3209 allows a router to refresh the state between 15 and 45 seconds.
The Style object indicates the reservation style. The reservation style for this ResvTear message is fixed filter (FF), indicating that the bandwidth allocation in a Resv message cannot be shared with any other session or sender/filter combination. Each different physical path is identified by an LSP ID, listed in the filter object. A reservation message that indicates a fixed filter style consists of distinct reservations among explicit senders. For this session, the router cannot share the bandwidth with any other RSVP LSP signaling messages that share the same session ID and have different LSP IDs.
Other available reservation styles are shared explicit (SE) and wildcard filter (WF). For more information on reservation styles, see the JUNOS MPLS Applications Configuration Guide.
The Flow object indicates the allocated bandwidth and is the same information contained in the Tspec object in the Path message. This RSVP session uses the default of 0, no bandwidth is reserved. The Flow object includes two different types of RSVP bandwidth allocations: controlled load and guaranteed delivery.
- Controlled load specifies a maximum transmission rate and a maximum burst size. The peak value is always set to infinity (
Inf), unless guaranteed delivery is specified. RFC 3209 recommends support only for null service and controlled load bandwidth services. Guaranteed delivery is not currently recommended, so there should never be a value forInfin theFlowobject. - Guaranteed delivery specifies a peak transmission rate; for example, 45 Mbps. The JUNOS software does not support guaranteed delivery. Instead you can specify a maximum transmission rate; for example, 45 Mbps. Because it is possible to burst at the maximum rate, the size parameter indicates a maximum burst size of 45 Mbps. The lowercase
m (m20)and uppercaseM(M 1500) indicate the minimum and maximum sizes for the RSVP MTU rate. RSVP treats any packet smaller than m20 as 20 bytes, and any packet larger than M1500 as 1500 bytes.
The Filter object defines the source of the session 10.0.0.1 (R1). The number (7) after Filter indicates that this is C-Type 7 for IPv4, defined in RFC 3209. The Filter object contains the source address of the LSP and the LSP ID. The LSP ID changes, depending on the signaling path. The Filter object contains the same information as the Sender object of the Path message.
The Label object contains the label value (100624) that is mapped to the LSP identified by the session value.
The record route object (RecRoute) contains the list of IP addresses through which this Resv message passed.