Purpose
ResvTear messages remove reservation states along a path, travelling upstream toward senders of the session. In a sense, ResvTear messages do the opposite of Resv messages. ResvTear messages typically are initiated by a receiver application or a router when its reservation state times out.
ResvTear messages are not required, but they enhance network performance because they release network resources quickly. If ResvTear messages are lost or not generated, reservation states eventually time out when they are not refreshed, and the resources associated with the reservation are released.
Figure 14 shows an RSVP ResvTear message that flows upstream from router R3 to R1, ensuring that the network removes resources allocated along the reverse path that the downstream messages followed.
Figure 14: RSVP ResvTear Message
To ensure that ResvTear messages are displayed in the output, include the resvtear flag at the [edit protocols rsvp traceoptions] hierarchy level.
Action
To examine the ResvTear message, enter the following JUNOS CLI command:
Sample Output 1
[edit protocols rsvp]
user@R1# show
traceoptions {
file rsvp-log;
flag packets detail;
flag resvtear 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 *** [...Output truncated...] Jun 30 09:27:43 RSVP recv ResvTear 10.1.13.2->10.1.13.1 Len=56 so-0/0/2.0 Jun 30 09:27:43 Session7 Len 16 10.0.0.5(port/tunnel ID 26619) Proto 0 Jun 30 09:27:43 Hop Len 12 10.1.13.2/0x08678198 Jun 30 09:27:43 Style Len 8 FF Jun 30 09:27:43 Filter7 Len 12 10.0.0.1(port/lsp ID 7) monitor stop
Meaning
Sample Output 1 shows the configuration of RSVP tracing on ingress router R1. The packets and resvtear 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 18. 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 ResvTear message from R3 (10.1.13.2) to R1 (10.0.0.1). The outgoing interface is so-0/0/2.0 on R3. When a Path message containing an RRO is received by an intermediate router, the router stores a copy of it in the path state block. The ResvTear message deletes state information for the specified RSVP session from the reservation state blocks of routers with knowledge of this MPLS tunnel.
All subsequent lines of sample output indicate object values for this ResvTear 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).
The Hop object indicates the last IP address (10.1.13.1) that this RSVP ResvTear message visited.
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 Filterobject defines the source of the session 10.0.0.1 (R1). The number after Filter (Filter7) indicates that this is C-Type 7 for IPv4, defined in RFC 3209. It 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.