Chapter 10 - Resource Reservation Protocol | Cisco Multicast Routing & Switching

Chapter 10: Resource Reservation Protocol


	Overview


	The Resource ReSerVation Protocol (RSVP) is an Internet control protocol that is used by unicast and multicast receivers to request a specific quality of service (QoS) for the data flow from a unicast or multicast source. RSVP would typically be used to establish a bandwidth reservation for real-time traffic, such as voice or video, as opposed to data traffic, such as a file transfer. RSVP can prevent a data application from depleting the bandwidth available for real-time traffic. Without a guaranteed bandwidth along the path from sender to receiver, real-time traffic can suffer from jitter or delay inconsistencies.


	RSVP is also used by routers to forward QoS requests on the path from the receiver to the source. RSVP is not a routing protocol but is a transport layer control protocol used to establish a QoS along a routed path. RSVP interoperates with unicast and multicast routing protocols to determine the path along which QoS reservations need to be made. If available, resources are reserved in each router along the selected path from the receiver to the source. QoS Reservations are unidirectional, typically from the source to the receiver (see Figure 10-1).


	Figure 10-1: RSVP request flows along the shared or source-based multicast tree


	The RSVP request will flow along the source-based or shared multicast tree depending on which multicast routing protocol has been enabled. The RSVP requests are forwarded towards the source by examining the routing table and determining the next hop toward the source. The functional components of RSVP run as a background process in parallel with the data path as shown in Figure 10-2.


	Figure 10-2: RSVP functional modules for host and router implementations

When a resource reservation request is initiated, the request is sent to the policy and admission control modules. The admission control module will check to see if the node can satisfy the request. The policy control module determines if the entity requesting the reservation has the required privileges to do so. If either of these checks is unsuccessful, the application will be notified of the failure. If no failures occur, the classifier and the packet scheduler establish the requested reservation. Multicast membership is usually dynamic. Hosts can join or leave a multicast group at any time. To accommodate the dynamic nature of multicast data flows, RSVP will periodically send refresh messages along the data flow path in order to maintain the established reservation. When refresh messages stop being sent, the reservation will timeout, releasing the resources back to the system.

RSVP Reservation Model


	An RSVP reservation request is referred to as a flow descriptor. The flow descriptor consists of two elements. The first element is the flowspec, which specifies the QoS and is used in conjunction with the packet scheduler. The second element is the filter spec, which is used to determine which packets in the flow will receive the QoS that has been reserved at the node. The filter spec is used to inform the packet classifier of the parameters that will be checked to determine if a packet is a candidate for the QoS reservation. The RSVP specification currently has a basic filter specification consisting of the sender s IP address and the UDP/TCP source port number. Figure 10-3 shows the relationship between the flow descriptor and the RSVP functional model.


	Figure 10-3: Flow descriptor and RSVP functional model relationships


	Reservation Styles


	A style refers to a reservation request and the set of options pertaining to that request. Reservations can be distinct or shared. A distinct reservation is one in which a specific reservation is established for each sender to a particular multicast group. A shared reservation is one where all senders for a session share a reservation. For both styles the selection of the sender can either be explicitly referenced in the request or not referenced at all. The not referenced case is referred to as the wildcard case in which every sender is automatically selected. For the explicit sender case, each filter specification will match only one sender. The wildcard case would not need a sender filter specification. Table 10-1 lists the various styles that can be used when setting up a resource reservation.


	Table 10-1: RSVP Reservation Styles


	Sender Selection


Distinct Reservation


Shared Reservation


	Explicit


Fixed-Filter (FF) style


Shared-Explicit (SE) style


	Wildcard


(None Defined)


Wildcard-Filter (WF) style


	Wildcard-Filter (WF) Style


	The WF style is a shared reservation style with implicit sender selection. Since all reservations are sharing the same resource allocation, the amount of resource that needs to be reserved is equal to the largest value of the resource requested by all receivers. The WF style is represented by the equation


	WF(*{Q})


	with the asterisk signifying a wildcard sender selection and Q signifying the flowspec. The symbol Q, or flowspec, is essentially the QoS or amount of bandwidth requested by the receiver. The network in Figure 10-4 shows a WF scenario. The receivers are requesting bandwidth for a particular session that is supported by sources 1,2, and 3. The receivers don t care from which source the data arrives so all are using the wildcard specification WF({Q}). Receiver 1 is requesting 500K and sends a WF({500K}) RSVP request to router A.


	Figure 10-4: WF(*{Q}) reservation style example


	Router A receives only one WF request and attempts to allocate the bandwidth on the input interface, E0, and the output interface, S0. For reservation requests, input and output interfaces refer to the direction of the reservation request flow. The data flow from the sources will reverse the direction of these interfaces. For the following examples, assume the routers have the resources to satisfy reservation requests. Since the request is a shared reservation request, router A will allocate the largest of the requested allocations. With only one request, the allocation will equal what receiver 1 requested. The same argument applies to routers C and D and receivers 2 and 3. Router C will allocate 300K on the E0 and E1 interfaces, while router D will allocate 200K on the E0 and E1 interfaces. Router A will receive one reservation request on interface S2 for 500K and two reservation requests for 200K and 300K on interface E0. Router A will allocate 500K on interface S2. The largest of the two requests, 300K, is received on interface E0. On interfaces S0 and S1, Router A has to be able to handle the largest of the three requests received. For this case, a 500K allocation is reserved on the S0 and S1 interfaces and the reservation is forwarded toward the sources. Routers E and F only receive an RSVP request for 500K. This amount will be allocated on all interfaces between the sources and the receivers. The bandwidth allocations for the WF example network in Figure 10-4 are listed in Table 10-2.


	Table 10-2: Bandwidth Allocations for the Wildcard-Filter Style Example


	Router


Interface E0


Interface E1


Interface S0


Interface S1


Interface S2


	A


300K


500K


500K


500K


	B


500K


500K


	C


300K


300K


	D


200K


200K


	E


500K


500K


	F


500K


500K


	Fixed-Filter (FF) Style


	Fixed-filter reservations have distinct reservations with explicit sender selection. For each FF reservation established, the router must allocate bandwidth for each request. The total bandwidth allocated is the sum of the bandwidths requested by each FF request for a distinct source. If two or more receivers request a resource and specify the same sender, the allocated resource will be shared by the receivers for that sender. The FF style can be represented by


	FF(S{Q})


	where S is the specific sender and Q is the flowspec. The FF style is contained in Figure 10-5 with the total bandwidth allocations shown in Table 10-3.


	Figure 10-5: Fixed Filter FF(S{Q}) reservation style example


	Table 10-3: Bandwidth Allocations for the Fixed-Filter Style Example


	Router


Interface E0


Interface E1


Interface S0


Interface S1


Interface S2


	A


400K


600K


400K


900K


	B


900K


900K


	C


400K


400K


	D


100K


100K


	E


400K


400K


	F


600K


600K


	Shared Explicit (SE) Style


	Shared Explicit style reservations are characterized by a shared reservation and an explicit sender, creating a reservation that is shared by specific senders. The SE style is represented by


	SE((S1,S2,...Sn){Q})


	indicating that the list of senders shares the reservation Q. SE style type reservations are illustrated in Figure 10-6 with the bandwidth allocations listed in Table 10-4.


	Figure 10-6: Shared Explicit SE(S{Q}) reservation style example


	Table 10-4: Bandwidth Allocations for the Shared-Explicit (SE) Style Example


	Router


Interface E0


Interface E1


Interface S0


Interface S1


Interface S2


	A


300K


300K


300K


100K


	B


100K


100K


	C


300K


300K


	D


200K


200K


	E


300K


300K


	F


300K


300K


	When router A in Figure 10-6 receives the requests


	SE(S1{{200K}) + SE((S1,S3){300K})


	from routers C and D, the filter specs are combined and the flow spec is set to the largest flow spec received. The resulting flow descriptor will be ((S1,S2,S3){300K}).

Reservation Style Summary


	The three RSVP styles and the actions a router will take when merging requests are summarized in Figures 10-7 through 10-10.


	Figure 10-7: The merging of WF style RSVP requests. The size of the resource allocated is equal to the largest, regardless of the senders.


	Figure 10-8: The merging of FF style RSVP requests for distinct sources is shown. For each distinct source allocated, the requested resource is shown also. For a common source allocated, the largest of the resource is requested. The allocated bandwidth equals 300.


	Figure 10-9: The merging of FF style RSVP requests for a common source. For a common source, allocate the largest of the resources requested. The allocated bandwidth equals 100.


	Figure 10-10: The merging of SE style RSVP requests. Merge all sources and allocate the largest of the requested resource for all specified sources. The total bandwidth allocated equals 300.


	RSVP Protocol Messages


	When discussing RSVP messages we need to agree on the definition of terms. Figure 10-11 illustrates some fundamental terms used in discussing RSVP messages. The incoming and outgoing interfaces, as well as the next and previous hops, are from the point of view of the data flow. RSVP utilizes two types of messages for resource reservation. The first message is a reservation request (RESV) message that is sent from receivers to senders. The RESV messages will traverse the network from the receiver to the sources in the messages along the RPF interfaces as discussed in previous chapters. A reservation state will be established in each router along the path.


	Figure 10-11: RSVP terminology


	Each source that implements RSVP will transmit Path messages along the route that the data will follow. At each node along the path, the path state is stored. The path state is used to route the reservation messages. A fundamental component of the path state is the IP address of the previous hop. In Figure 10-11, the previous hop for router B is router A, as shown. The path message contains other required components and possibly optional components for the establishment of the path state. The two required components are the Sender Template and the Sender Tspec. Sender Template contains a description of the structure of the packets that the source sends in the form of a filter spec. This implies that the sender template will contain the IP address of the source and possibly the UDP port the source is using. The Sender Tspec defines the characteristics of the traffic the source will originate in order to prevent over-reservation. An optional component of a path message is the Adspec. An Adspec carries One Pass With Advertising (OPWA) information. As the Path message travels towards the receiver, information is collected at each node so the receiver is able to predict the end-to-end service. This information is referred to as an advertisement, hence, the name Adspec. When the path message arrives at a node, the Adspec is passed to the local traffic control module. The local traffic control module updates the Adspec which is sent in a path message to the next downstream node.


	The state that is established along the path from the source to receiver is a dynamic, or soft, state. It is refreshed by periodic path and reservation messages. If there are any changes in the reservation request, they are contained in the request updating the soft state in the routers. The state maintains a cleanup timeout timer whose expiration causes the state to be deleted. A state may also be deleted by the reception of a teardown message. Teardown messages will remove reservation of path state upon reception of the message. Two types of states are established path and reservation so two teardown messages ResvTear and PathTear are also established.


	RSVP uses two messages to report errors. For path errors, the PathErr message is used. PathErr messages are sent upstream toward the source that was the cause of the error. Intermediate nodes the PathErr message crosses won t have its path state modified. For reservation errors, the ResvErr message is used. When a reservation request is denied by the admission control module, existing reservations are unaffected and the error is reported to all affected receivers. ResvErr messages create a new state in the nodes the error message traverses. This state is called the blockade state and prevents the flowspec that caused the error to be omitted from the flowspec merging process.


	RSVP confirmation messages (ResvConf) are used to signal the requesting receiver that the reservation was successful. When a reservation request reaches a merge point and the request is smaller than or equal to an existing reservation, the reservation has succeeded. At this point, if the receiver requested a confirmation, then a ResvConf message will be sent back to the receiver.


	There may be situations where RSVP reservation and path messages may be routed through routers that are not RSVP capable (see Figure 10-12).


	Figure 10-12: A non-RSVP router in the path between the receiver and source


	A path message from the source will be forwarded towards the destination by both the RSVP capable and non-RSVP capable routers and allow RSVP to operate correctly. Problems may arise because there is no knowledge about the non-RSVP router and whether or not it can handle the reservations that were setup on the RSVP capable routers. In this case RSVP will propagate a non-RSVP flag to the local traffic control module and will be forwarded using Adspecs. Non-RSVP capable routers can cause an RSVP message to arrive at the wrong node or the wrong interface on the correct node. A Logical Interface Handle (LIH) is used to handle the case of the wrong interface on the right router. The previous hop information in the path message will contain the IP address of the previous hop and a LIH identifying the interface.


	RSVP Message Formats


	Every RSVP message begins with a common header (see Figure 10-13).


	Figure 10-13: RSVP message header format


	Version


Four-bit version number. Current version is 1.


	Flags


Four-bit number. Not defined.


	Msg type


Eight-bit number.


	1 = Path


	2 = Resv


	3 = PathErr


	4 = ResvErr


	5 = PathTear


	6 = ResvTear


	7 = ResvConf


	RSVP Checksum


16-bit ones complement sum of the RSVP message.


	Send_TTL


Eight-bit original TTL value of the message.


	RSVP Length


16-bit total length of the RSVP message.


	Each RSVP message has an object field that follows the common header. The object field has a minimum size of 32-bits, as shown in Figure 10-14.


	Figure 10-14: RSVP Object format


	Length


	Sixteen-bit length in bytes of the object. The length must be a multiple of four and the minimum length is four bytes.


	C-Type


	Identifies the address family. One is for IPv4 and 2 is for IPv6.


	Class-Num


	Type of object contained in the message. The Class-Num identifiers and their corresponding packet formats and descriptions are contained in Figures 10-15 10-16.


	Figure 10-15: IPv4 UDP Session Object; Class-Num = 1 C-Type = 1


	Figure 10-16: IPv6 UDP Session object; Class-Num = 1 C-Type = 2


	Class-Num identifies one of the following objects.


	NULL


	NULL objects are ignored and can be anywhere in the message. The object length is a multiple of four bytes.


	SESSION


	A session object is required in every RSVP message. This object will contain the IP address of the destination, the IP protocol ID and the destination port.


	RSVP_HOP


	Contains the IP address of the RSVP node that sent the message along with the Logical Interface Handle (LIH). For downstream messages, the object is referred to as a previous hop (PHOP) object and for next hop or upstream messages it is referred to as a next hop (NHOP) object.


	TIME_VALUES


	Every Path and RESV message will contain a TIME_VALUES object that contains the refresh period. This object is required in every Resv and Path message.


	STYLE


	Contains the reservation style, WF, FF, or SE, and style specific information not contained in FLOWSPEC or FILTER_SPEC objects.


	FLOWSPEC


	Contains the desired QoS. Used in the RESV message.


	FILTER_SPEC


	Used to identify the data packets in a session that should receive the requested QoS. Used in the RESV message.


	SENDER_TEMPLATE


	Contains the sender s IP address and is required in the Path message.


	ADSPEC


	Contains OPWA information and is used in the PATH message.


	ERROR_SPEC


	Identifies the error that is being returned in a PathErr or ResvErr message. Also used as a confirmation in a ResvConf message.


	POLICY_DATA


	Not currently specified.


	INTEGRITY


	Contains cryptographic information to authenticate the originating node and to verify the message.


	SCOPE


	Contains a list of senders to which the message is forwarded.


	RESV_CONFIRM


	Contains the IP address of the receiver that requested the confirmation.


	The Session class object, shown in Figures 10-15 and 10-16, specifies the session for the objects that follow in the message. The destination address, in conjunction with the UDP destination port field, identifies the session. The destination address can be either a multicast or unicast address.


	The RSVP_HOP message (see Figures 10-17 and 10-18) contains the IP address and Logical Interface Handle (LIH) of the RSVP node that forwarded the message.


	Figure 10-17: IPv4 RSVP_HOP object; Class-Num = 3 C-Type = 1


	Figure 10-18: IPv6 RSVP_HOP object; Class-Num = 3 C-Type = 2


	The TIME_VALUE object (see Figure 10-19) contains the refresh period in milliseconds.


	Figure 10-19: TIME_VALUES object; Class-Num = 5 C-Type = 1


	The ERROR_SPEC object contains the IP address of the node where the error was detected (see Figure 10-21). The flags field has the values listed on the following page.


	Figure 10-20: IPv4 ERROR_SPEC object; Class-Num = 6 C-Type = 1


	Figure 10-21: IPv6 ERROR_SPEC object; Class-Num = 6 C-Type = 2


	0x01 (InPlace)


	If this bit is set then a reservation is in place on the node where the error occurred. Only used in a ResvErr message.


	0x02 (NotGuilty)


	If set then indicates that the FLOWSPEC that failed was greater than the FLOWSPEC that was requested by the receiver.


	Error code 0


	Type


	Confirmation.


	Description


	Used in the ERROR_SPEC object in a ResvConf message.


	Error Value


	0


	Error Code 1


	Type


	Admission Control Failure.


	Description


	The reservation request failed due to resource(s) not available.


	Error Value


	The 16 bits of the error value are defined as follows:


	15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0


	s s u r c c c c c c c c c c c c


	ss = 00


	Error Code 2


	Type


	Policy control failure.


	Description


	A reservation or path message failed for administrative reasons.


	Error Value


	Undefined.


	Error Code 3


	Type


	No path state for the session and the resv message cannot be forwarded.


	Error value


	Undefined.


	Error Code 4


	Type


	No sender information for the Resv message.


	Description


	A path state exists for the session but the state does not contain a flow descriptor that matches the sender in the Resv message.


	Error value


	Undefined.


	Error Code 5


	Type


	Conflicting reservation style.


	Description


	The requested reservation style conflicts with the existing style.


	Error Value


	Lower order 16-bits of the option vector of the existing style.


	Error Code 6


	Type


	Unknown reservation style.


	Error Code 7


	Type


	Conflicting destination ports.


	Description


	Sessions for the same destination address and protocol and appeared with both zero and non-zero destination port fields.


	Error Value


	Undefined.


	Error Code 8


	Type


	Conflicting sender ports.


	Description


	The sender port is both zero and non-zero in path messages for the same session.


	Error Code 9,10,11


	Type


	Reserved.


	Error Code 12


	Type


	Service preempted.


	Description


	The service requested by the STYLE object and the flow descriptor has been administratively preempted.


	Error value


	Error Code 13


	Type


	Unknown object class.


	Error Value


	Contains the Class-Num and C-type of the unknown object.


	Error Code 14


	Type


	Unknown object C-type.


	Error Value


	Contains the Class-Num and C-type of the unknown object.


	Error Code 15, 16, 17, 18, 19, 20


	Type


	Reserved.


	Error Code 21


	Type


	Traffic control error.


	Description


	Traffic control call failed due to the format or contents of the request.


	Error Code 22


	Type


	Traffic control system error.


	Description


	A system error was detected and reported by the traffic control modules.


	Error Value


	System specific.


	Error Code 23


	Type


	RSVP system error.


	Description


	Every RSVP message is rebuilt at every hop and an error in a node could cause a malformed message.


	Error Value


	Implementation dependent.


	The SCOPE class object is a list of IP addresses used for routing messages with wildcard scope without loops (see Figures 10-22 and 10-23). The addresses must be listed in ascending order.


	Figure 10-22: IPv4 SCOPE List object; Class-Num = 7 C-Type = 1


	Figure 10-23: IPv6 SCOPE List object; Class-Num = 7 C-Type = 2


	The STYLE object identifies the reservation type (see Figure 10-24) and the flags field is not defined. The 24-bit option vector (see Figure 10-25) identifies the style.


	Figure 10-24: STYLE object; Class-Num = 8 C-Type = 1


	0x10001-WF 0x01010-FF 0x10010-SE


	Figure 10-25: Option Vector bit definitions


	The FILTER_SPEC object contains the IP source address for the sender (see Figures 10-26, 10-27, and 10-28). The source port field contains the UDP/TCP port for the sender or 0 to indicate none.


	Figure 10-26: IPv4 FILTER_SPEC object; Class-Num = 10 C-Type = 1


	Figure 10-27: IPv6 FILTER_SPEC object; Class-Num = 10 C-Type = 2


	Figure 10-28: IPv6 FILTER_SPEC object; Class-Num = 10 C-Type = 3


	The SENDER_TEMPLATE object contains the IP source address for the sender (see Figures 10-29, 10-30, and 10-31). The source port field contains the UDP/TCP port for the sender or 0 to indicate none.


	Figure 10-29: IPv4 SENDER_TEMPLATE object; Class-Num = 11 C-Type = 1


	Figure 10-30: IPv6 SENDER_TEMPLATE object; Class-Num = 11 C-Type = 2


	Figure 10-31: IPv6 SENDER_TEMPLATE object; Class-Num = 11 C-Type = 3

Configuring and Monitoring RSVP


	Three types of configuration commands can be used to configure or monitor RSVP. The first type is configuration commands used to enable and configure RSVP. The second type of RSVP command is used to view RSVP configurations and parameters. The third type of RSVP command is used for debugging an RSVP configuration. Each command will be presented and the use of the command will be explained. After the command overview we will examine RSVP scenarios and the use of all three types of RSVP commands.


	RSVP Configuration Commands


	RSVP is disabled on router interfaces and this is the default interface state. In order for a router to participate in RSVP, RSVP must be enabled on the interfaces using the command


	ip rsvp bandwidth [interface-kbps] [single-flow-kbps]


	interface-kbpsOptional parameter. Value can be 1 10,000,000.


	Optional parameter. Value can be 1 10,000,000.


	The parameters shown in brackets are optional parameters. The first optional parameter is the total amount of bandwidth that will be reserved on the interface for RSVP flows. The second optional parameter is the amount of bandwidth that can be allocated to a single flow.


	By default 75 percent of the bandwidth on an interface can be reserved.


	Example


	For the router in Figure 10-34, reserve 75 percent of the bandwidth on the ethernet interfaces with a limit of 10 percent of the bandwidth for any one flow.


	Figure 10-32: IPv4 RESV_CONFIRM object; Class-Num = 15 C-Type = 1


	Figure 10-33: IPv6 RESV_CONFIRM object; Class-Num = 15 C-Type = 2


	Figure 10-34: Enabling RSVP and reserving bandwidth on router interfaces


	interface Ethernet 0

ip address 10.1.1.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 7500 1000

interface Ethernet 1

ip address 10.1.1.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 7500 1000


	To disable RSVP on an interface, use the command


	no ip rsvp bandwidth interface-kbps single-flow-kbps


	By default, any neighbor can request a reservation on a router interface. If only selected neighbors are to be permitted to request a reservation using RSVP, we would use the interface command


	ip rsvp neighbors access-list-number


	access-list-number


	Integer from 1 to 199. 1 to 99 for a standard access list. 100 199 for an extended access list.


	In Figure 10-35, we want to only permit the receiver with IP address 10.1.4.2 to be able to request a reservation. There is an implicit deny any at the end of every access list. Therefore the access list in Figure 10-35 will block all other receivers from requesting reservations. If we wanted to only block 10.1.4.2 from making a reservation but permit any other receiver to request a reservation then we would need the access list shown in Figure 10-36. The permit any is required because of the implicit deny any at the end of the list.


	Figure 10-35: Allow only sender 10.1.4.2 to request a reservation


	Figure 10-36: Deny sender 10.1.4.2 from requesting a reservation


	Router C

interface Ethernet 0

ip address 10.1.4.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth

ip rsvp neighbors 1

access-list 1 permit host 10.1.4.1

Router C

interface Ethernet 0

ip address 10.1.4.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth

ip rsvp neighbors 1

access-list 1 deny host 10.1.4.1

access-list 1 permit any


	To remove an access list for a neighbor, use the interface command


	no ip rsvp neighbors access-list-number


	We have seen that RSVP will periodically send refresh messages for PATH and RESV messages. The refresh messages keep the path and reservation states in place by preventing them from timing out. The router can be configured to behave as though it were receiving reservation or path messages using


	ip rsvp sender session-ip-address sender-ip-address

[tcp|udp|ip-protocol] session-dport sender-sport

previous-hop-ip-address previous-hop-interface bandwidth burst-size


	for PATH messages and


	ip rsvp reservation session-ip-address sender-ip-address

[tcp|udp|ip-protocol] session-dport sender-sport

next-hop-ip-address next-hop-interface

{ff|se|wf} {rate|load} bandwidth burst-size


	for RESV messages. The explanations of the parameters for the two messages are listed below.


	session-ip-address


	For a unicast session, this is the address of the receiver. For a multicast session, this is the session IP multicast address.


	sender-ip-address


	IP address of the sender.


	tcp\|udp\|ip-protocol


	session dport session sport


	Destination and source port numbers. If one is zero then both must be zero.


	previous-hop-ip-address


	Address of the sender if the sender is connected to the interface or address of the router interface on the path back to the sender.


	previous-hop-interface


	Interface type of the previous hop. It can be ethernet, loopback, null, or serial.


	next-hop-ip-address


	Hostname or address of the receiver or the address of the router interface on the path back to the receiver.


	next-hop-interface


	Interface type of the next hop. Can be ethernet, loopback, null, or serial.


	:ff \| se \| wf


	Reservation style: fixed filter, shared explicit, or wild card.


	rate \| load


	QoS: guaranteed bit rate service or controlled load service.


	bandwidth


	Optional. Average bit rate (kbps) to reserve, up to 75 percent of the interface capacity. Range is 1 to 10,000,000.


	burst-size


	Optional. Maximum burst size (kilobytes of data in the queue). Range is 1 to 65,535.


	To remove the effect these commands, use the form


	no ip rsvp sender session-ip-address sender-ip-address

[tcp|udp|ip-protocol] session-dport sender-sport

previous-hop-ip-address previous-hop-interface bandwidth burst-size


	for PATH messages and


	no ip rsvp reservation session-ip-address sender-ip-address

[tcp|udp|ip-protocol] session-dport sender-sport

next-hop-ip-address next-hop-interface

{ff|se|wf} {rate|load} bandwidth burst-size


	for RESV messages.


	In Figure 10-37, routers A and C are configured so the sender path state and the receivers reservation never time out.


	Router A


	Interface Ethernet0 ip address 10.1.1.2 255.255.255.0 ip pim dense-mode ip rsvp bandwidth ip rsvp sender 225.1.1.1 10.1.1.1 udp 20 30 10.1.1.1 ethernet0 50 5


	Figure 10-37: Example of static RSVP reservations


	Router C


	interface Ethernet0 ip address 10.1.4.1 255.255.255.0 ip pim dense-mode ip rsvp bandwidth ip rsvp reservation 255.1.1.1 10.1.4.2 ethernet0 ff rate 300 60


	The final RSVP configuration command addresses the encapsulation of the RSVP messages. If the router detects that RSVP neighbors are using UDP encapsulation, the router will automatically generate UDP encapsulated messages. In some situations, a host will not originate a message unless it has heard from the router. To configure the router to generate UDP encapsulated RSVP multicasts, use the command


	ip rsvp udp-multicast multicast-address

RSVP Scenarios


	In this section, various RSVP scenarios are presented to illustrate the use of the RSVP configuration and monitoring commands. Another purpose is to present examples of different combinations of RSVP styles and verify that the router that is the merge point does indeed merge, as presented earlier in the chapter. The first scenarios involve one receiver and one sender, with the receiver requesting either a WF, FF, or SE style reservation. The configurations used do not need any actual multicast senders or receivers. These configurations are meant for you to configure in your own lab for the purpose of practicing and understanding the commands. Senders and receivers will be simulated using the IP_RSVP_SENDER and IP_RSVP_RESERVATION commands. The initial configuration for the network in Figure 10-38 is shown in Listings 10-1 through 10-3.


	Figure 10-38: Network for RSVP configuration examples containing a single source and a single reservation


	Listing 10-1: Initial configuration for single server single reservation scenarios router A


	hostname A

ip multicast-routing

ip dvmrp route-limit 7000

interface Loopback0

ip address 172.16.1.1 255.255.255.0

ip pim dense-mode

interface Serial0

ip address 10.1.2.1 255.255.255.0

ip pim dense-mode

router eigrp 100

network 10.0.0.0

network 172.16.0.0


	Listing 10-2: Initial configuration for single server single reservation scenarios router B


	hostname B

ip multicast-routing

ip dvmrp route-limit 7000

interface Loopback0

ip address 172.16.2.1 255.255.255.0

ip pim dense-mode

interface Serial0

ip address 10.1.2.2 255.255.255.0

ip pim dense-mode

clockrate 1544000

interface Serial1

ip address 10.1.3.1 255.255.255.0

ip pim dense-mode

clockrate 15440000

router eigrp 100

network 10.0.0.0


	Listing 10-3: Initial configuration for single server single reservation scenarios router C


	hostname C

ip multicast-routing

ip dvmrp route-limit 7000

interface Loopback0

ip address 172.16.3.1 255.255.255.0

ip pim dense-mode

ip igmp join-group 224.250.250.1

interface Serial1

ip address 10.1.3.2 255.255.255.0

ip pim dense-mode

bandwidth 1544

no fair-queue

router eigrp 100

network 10.0.0.0

network 172.16.0.0


	Router A

interface Ethernet0

ip address 10.1.1.2 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth

ip rsvp sender 225.1.1.1 10.1.1.1 udp 20 30 10.1.1.1 ethernet0 50 5

Router C

interface Ethernet0

ip address 10.1.4.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth

ip rsvp reservation 225.1.1.1 10.1.4.2 udp 30 20 10.1.4.2 ethernet0 ff rate 300 60


	The initial configurations for routers A, B, and C do not contain any RSVP configuration commands. Initially ip multicast routing and PIM-DM has been configured. Also, the simulated sender and receiver will be located on the loopback interfaces. Since both RSVP and PIM-DM relay on the ip unicast routing table, EIGRP has been enabled on all routers. The first RSVP configuration step is to enable RSVP on all interfaces using the command


	ip rsvp bandwidth interface-kbps single-flow-kbps


	For these examples we will not use the optional parameters so the form of the command is


	ip rsvp bandwidth <CR>


	When we use this command on each interface and then list the configuration we can see that the default bandwidth reserved for RSVP is 75 percent of the interface bandwidth. The serial interfaces have been configured for T1 bandwidth, 1.544 Mbits, and 75 percent of 1.544 Mbits is 1.158 Mbit as shown in Listing 10-4. The next step is to simulate the sender on router A with the command


	Listing 10-4: Enabling RSVP on the router interfaces


	hostname A

interface Loopback0

ip address 172.16.1.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 1705033 1705033

interface Serial0

ip address 10.1.2.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 1158 1158

fair-queue 64 256 1000

hostname B

interface Serial0

ip address 10.1.2.2 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 1158 1158

fair-queue 64 256 1000

clockrate 1544000

interface Serial1

ip address 10.1.3.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 1158 1158

fair-queue 64 256 1000

clockrate 1544000

hostname C

interface Loopback0

ip address 172.16.3.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 1705033 1705033

ip igmp join-group 224.250.250.1

interface Serial1

ip address 10.1.3.2 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 1500 1500

bandwidth 1544

no fair-queue


	ip rsvp sender 224.250.250.1 172.16.1.2 UDP 20 30 172.16.1.2 Lo0 50 10.


	To verify that RSVP Path messages are being sent by router A use the command show ip rsvp sender on routers A, B, and C as shown.


	A#sh ip rsvp sender


	To


From


Pro


Dport


Sport


Prev Hop


I/F


BPS


Bytes


	224.250 .250.1


172.16. 1.2


UDP


20


30


172.16.1.2


Lo0


50K


10K


	B#show ip rsvp sender


	To


From


Pro


Dport


Sport


Prev Hop


I/F


BPS


Bytes


	224.250 .250.1


172.16. 1.2


UDP


20


30


10.1.2.1


Se0


50K


10K


	C#show ip rsvp sender


	To


From


Pro


Dport


Sport


Prev Hop


I/F


BPS


Bytes


	224.250. 250.1


172.16. 1.2


UDP


20


30


10.1.3.1


Se1


50K


10K


	where


	To


	IP addresses of the receiver


	From


	IP Address of the sender


	Pro


	Protocol code


	Dport


	Destination port number


	Sport


	Source port number


	Prev Hop


	IP address of the previous hop


	I/F


	Interface of the previous hop


	BPS


	Reservation rate in bits per second the sender is advertising it might achieve


	Bytes


	Bytes of the burst size the sender is advertising it might achieve


	The final step for the single sender single receiver scenarios is to simulate RSVP Resv messages from the receiver attached to router C using the global command


	ip rsvp reservation 224.250.250.1 172.16.1.2 UDP 20 30 172.16.3.4 Lo0 WF RATE 100 200


	The first scenario requests a WF style reservation. The effect of this command can be seen by using the commands show ip rsvp reservation and show ip rsvp request on routers A, B, and C.


	A#sh ip rsvp request


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


0.0.0.0


UDP


20


0


172.16. 1.2


Lo0


WF


RATE


100K


200K

A#sh ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250 .250.1


0.0.0.0


UDP


20


0


10.1.2.2


Se0


WF


RATE


100K


200K


	B#sh ip rsvp request


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


0.0.0.0


UDP


20


0


10.1.2.1


Se0


WF


RATE


100K


200K

B#sh ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


0.0.0.0


UDP


20


0


10.1.3.2


Se1


WF


RATE


100K


200K


	C#show ip rsvp request


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


0.0.0.0


UDP


20


0


10.1.3.1


Se1


WF


RATE


100K


200K

C#show ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


0.0.0.0


UDP


20


0


172.16.3.4


Lo0


WF


RATE


100K


200K


	The second scenario for the single sender single receiver group is when the receiver requests a FF style reservation. First, remove the WF reservation from router C using the command


	no ip rsvp reservation 224.250.250.1 172.16.1.2 UDP 20 30 172.16.3.4 Lo0 WF RATE 100 200


	Install the FF Style Reservation on Router C with the Global Command


	ip rsvp reservation 224.250.250.1 172.16.1.2 UDP 20 30 172.16.3.4 Lo0 FF RATE 100 200


	The only change in the command was to replace WF with FF. Verify the reservation by examining routers A, B, and C.


	A#sh ip rsvp request


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250 .250.1


172.16. 1.2


UDP


20


30


172.16.1.2


Lo0


FF


RATE


100K


200K

A#sh ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


172.16 .1.2


UDP


20


30


10.1.2.2


Se0


FF


RATE


100K


200K


	B#sh ip rsvp request


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250.250.1


172.16 .1.2


UDP


20


30


10.1.2.1


Se0


FF


RATE


100K


200K


	Bash ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250 .250.1


172.16 .1.2


UDP


20


30


10.1.3.2


Se1


FF


RATE


100K


200K


	C#show ip rsvp request


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


172.16. 1.2


UDP


20


30


10.1.3.1


Se1


FF


RATE


100K


200K

C#show ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250 .250.1


172.16 .1.2


UDP


20


30


172.16.3.4


Lo0


FF


RATE


100K


200K


	Notice that three fields have changed. The most obvious is the reservation style which has changed from WF to FF. The from address was 0.0.0.0 with a source port of 0 for the WF style. With the FF style the from address is 172.16.1.2 with a source port of 30. The WF filter style did not care about the source of the traffic but the FF style does. Finally replace the FF style reservation with the SE style reservation and examine the effect.


	ip rsvp reservation 224.250.250.1 172.16.1.2 UDP 20 30 172.16.3.4 Lo0 SE RATE 100 200.


	A#sh ip rsvp request


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


172.16 .1.2


UDP


20


30


172.16.1.2


Lo0


SE


RATE


100K


200K

A#sh ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


172.16 .1.2


UDP


20


30


10.1.2.2


Se0


SE


RATE


100K


200K


	B#sh ip rsvp request


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250 .250.1


172.16 .1.2


UDP


20


30


10.1.2.1


Se0


SE


RATE


100K


200K

B#sh ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


172.16 .1.2


UDP


20


30


10.1.3.2


Se1


SE


RATE


100K


200K


	C#show ip rsvp request


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


172.16. 1.2


UDP


20


30


10.1.3.1


Se1


SE


RATE


100K


200K

C#show ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250 .250.1


172.16 .1.2


UDP


20


30


172.16.3.4


Lo0


FF


RATE


100K


200K


	Notice that the only change is that FF has changed to SE. Before moving on to the scenarios involving multiple senders and receivers, the rest of the rsvp show commands will be presented. All of the ip rsvp show commands can be listed by executing


	B#show ip rsvp ?

installed

RSVP installed reservations

interface

RSVP interface information

neighbor

RSVP neighbor information

request

RSVP Reservations Upstream

reservation

RSVP Reservation Requests from Downstream

sender

RSVP Path State information


	The show commands listed above will be demonstrated on router B for the previous scenario.


	B#show ip rsvp installed ?

Loopback Loopback interface

Null Null interface

Serial Serial

<cr>


	The show ip rsvp installed command has the option of showing all interfaces, if <cr> is chosen, or a particular interface as shown below.


	B#show ip rsvp installed serial1

RSVP: Serial1

BPS

From

Protoc

DPort

Sport

Weight

Conver
sation

100K

224.
250.
250.1

172.16
.1.2

UDP

264


	The weight and conversion entries are Weighed Fair Queueing (WFQ) parameters. If WFQ is not configured on the interface then these parameters will be zero.


	B#show ip rsvp interface ?

Loopback Loopback interface

Null Null interface

Serial Serial

<cr>


	B#show ip rsvp interface Serial1


	interfac


allocate


i/f max


flow max


per/255


UDP IP


UDP_IP


UDP M/C


	Se1


100K


1158K


1158K


22 /255


0 1


0


0


	The fields for the show ip rsvp interface command are


	interfac


	interface name


	allocate


	current allocation


	i/f max


	maximum bandwidth that can be allocated


	flow max


	maximum flow possible on the interface


	per/255


	percent of the bandwidth utilized (22/255 = 8.6 percent)


	UDP


	number of neighbors sending UDP encapsulated RSVP


	IP


	number of neighbors sending IP encapsulated RSVP


	UDP_IP


	number of neighbors sending both UDP and IP encapsulated RSVP


	UDP M/C


	IS UDP configured on this interface? 0 = no 1 = yes


	Figure 10-39: RSVP scenario with multiple receivers and a single source


	B#show ip rsvp neighbor ?

Loopback Loopback interface

Null Null interface

Serial Serial

<cr>


	B#show ip rsvp neighbor

Interfac

Neighbor

Encapsulation

Se0

10.1.2.1

RSVP

Se1

10.1.3.2

RSVP


	The show ip rsvp neighbor command simply displays the routers current rsvp neighbors.


	Now configure and examine scenarios with multiple receivers and multiple senders for the three RSVP reservation styles. The scenarios that will be configured are listed.


	1.		Multiple WF requests with a single source.


	2.		Multiple FF requests with a single source.


	3.		Multiple SE requests with a single source.


	4.		Multiple WF requests with multiple sources.


	5.		Multiple FF requests with multiple sources.


	6.		Multiple SE requests with multiple sources.


	For the first three scenarios involving multiple receivers we need to configure two more receivers on router C.


	Router C

interface Loopback0

ip address 172.16.3.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 1705033 1705033

ip rsvp udp-multicasts 224.0.0.14

ip igmp join-group 224.250.250.1

interface Loopback1

ip address 172.16.5.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 1705033 1705033

ip rsvp udp-multicasts 224.0.0.14

ip igmp join-group 224.250.250.1

interface Loopback2

ip address 172.16.4.1

ip pim dense-mode

ip rsvp bandwidth 1705033 1705033

ip rsvp udp-multicasts 224.0.0.14

ip igmp join-group 224.250.250.1

ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.3.2 Lo0 WF RATE 100 200

ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.5.2 Lo1 WF RATE 100 200

ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.4.2 Lo2 WF RATE 100 200


	There are now three WF reservations for the multicast group 224.250.250.1 installed on router C.


	C#show ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


0.0.0.0


UDP


20


0


172.16.3.2


Lo0


WF


RATE


100K


200K


	224.250. 250.1


0.0.0.0


UDP


20


0


172.16.5.2


Lo1


WF


RATE


100K


200K


	224.250. 250.1


0.0.0.0


UDP


20


0


172.16.4.2


Lo2


WF


RATE


100K


200K


	C#show ip rsvp installed

RSVP: Loopback0

BPS

From

Protoc

DPort

Sport

100K

224.250.
250.1

0.0.0.0

UDP

RSVP: Loopback1

BPS

From

Protoc

DPort

Sport

100K

224.250.
250.1

0.0.0.0

UDP

RSVP: Loopback2

BPS

From

Protoc

DPort

Sport

100K

224.250.
250.1

0.0.0.0

UDP


	What reservations do you expect to see installed on router B?


	B#show ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


0.0.0.0


UDP


20


0


10.1.3.2


Se1


WF


RATE


100K


200K

R4#show ip rsvp installed

RSVP: Serial1


	BPS


To


From


Protoc


Dport


Sport


Weight


Conver- sation


	100K


224. 250.250.1


0.0.0.0


UDP


20


0


4


264


	Router B has a reservation that has merged the three WF reservations from router C.


	For the FF case remove the WF reservations and install the FF reservations on router C.


	no ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.3.2 Lo0 WF RATE 100 200

no ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.5.2 Lo1 WF RATE 100 200

no ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.4.2 Lo2 WF RATE 100 200

ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.3.2 Lo0 FF RATE 100 200

ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.5.2 Lo1 FF RATE 100 200

ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.4.2 Lo2 FF RATE 100 200


	C#show ip rsvp reservation

From

Pro

Dport

Sport

Next Hop

I/F

Serv

BPS

Bytes

224.250.
250.1

172.16
.1.2

UDP

172.16
.3.2

Lo0

RATE

100K

200K

224.250.
250.1

172.16
.1.2

UDP

172.16
.5.2

Lo1

RATE

100K

200K

224.250.
250.1

172.16
.1.2

UDP

172.16
.4.2

Lo2

RATE

100K

200K

C#show ip rsvp installed

RSVP: Loopback0

BPS

From

Protoc

Dport

Sport

100K

224.250.250.1

172.16.1.2

UDP

RSVP: Loopback1

BPS

From

Protoc

Dport

Sport

100K

224.250.250.1

172.16.1.2

UDP

RSVP: Loopback2

BPS

From

Protoc

Dport

Sport

100K

224.250.250.1

172.16.1.2

UDP


	B#show ip rsvp reservation

From

Pro

Dport

Sport

Next Hop

I/F

Serv

BPS

Bytes

224.250.
250.1

172.16
.1.2

UDP

10.1.
3.2

Se1

RATE

100K

200K

R4#show ip rsvp installed

RSVP: Serial1

BPS

From

Protoc

DPort

Sport

Weight

Conver
sation

100K

224.250
.250.1

172.16.
1.2

UDP

264


	As with the WF case, the three FF reservations have been merged into one FF reservation since all reference the same source.


	The final single-source multiple-receiver case is the SE style reservation. Configure the SE style on router C using the following commands to verify that the reservations have been installed.


	no ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.3.2 Lo0 FF RATE 100 200

no ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.5.2 Lo1 FF RATE 100 200

no ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.4.2 Lo2 FF RATE 100 200

ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.3.2 Lo0 SE RATE 100 200

ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.5.2 Lo1 SE RATE 100 200

ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.4.2 Lo2 SE RATE 100 200


	C#show ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250 .250.1


172.16. 1.2


UDP


20


0


172.16.3.2


Lo0


SE


RATE


100K


200K


	224.250 .250.1


172.16. 1.2


UDP


20


0


172.16.5.2


Lo1


SE


RATE


100K


200K


	224.250 .250.1


172.16. 1.2


UDP


20


0


172.16.4.2


Lo2


SE


RATE


100K


200K

C#show ip rsvp installed

RSVP: Loopback0

BPS

From

Protoc

DPort

Sport

100K

224.25
0.250.1

172.16.1.2

UDP

RSVP: Loopback1

BPS

From

Protoc

DPort

Sport

100K

224.25
0.250.1

172.16.1.2

UDP

RSVP: Loopback2

BPS

From

Protoc

DPort

Sport

100K

224.25
0.250.1

172.16.1.2

UDP


	B#show ip rsvp reservation


	To

From

Pro

Dport

Sport

Next Hop

I/F

Serv

BPS

Bytes

224.250.
250.1

172.1
6.1.2

UDP

10.1.3.2

Se1

RATE

100K

200K

B#sh ip rsvp installed

RSVP: Serial0 has no installed reservations

RSVP: Serial1

BPS

From

Protoc

Dport

Sport

Weight

Conver
sation

100K

224.250.
250.1

172.16
.1.2

UDP

264


	The final three RSVP scenarios involve multiple senders and multiple receivers as shown in Figure 10-40.


	Figure 10-40: Multiple sender and multiple receiver RSVP scenario


	The loopback interfaces and reservation requests on router C need to be reconfigured, as do the senders on router A.


	Router C

interface Loopback0

ip address 172.16.3.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 1705033 1705033

ip rsvp udp-multicasts 224.0.0.14

ip igmp join-group 224.250.250.1

interface Loopback1

ip address 172.16.5.1 255.255.255.0

ip pim dense-mode

ip rsvp bandwidth 1705033 1705033

ip rsvp udp-multicasts 224.0.0.14

ip igmp join-group 224.250.250.2

interface Loopback2

no ip address

ip pim dense-mode

ip rsvp bandwidth 1705033 1705033

ip rsvp udp-multicasts 224.0.0.14

ip igmp join-group 224.250.250.3

ip rsvp reservation 224.250.250.1 0.0.0.0 UDP 20 0 172.16.3.2 Lo0 WF RATE 100 200

ip rsvp reservation 224.250.250.2 0.0.0.0 UDP 20 0 172.16.4.2 Lo1 WF RATE 100 200

ip rsvp reservation 224.250.250.3 0.0.0.0 UDP 20 0 172.16.5.2 Lo2 WF RATE 100 200

Router A

ip rsvp sender 224.250.250.1 172.16.1.2 UDP 20 30 172.16.1.2 Lo0 50 10

ip rsvp sender 224.250.250.2 172.16.1.2 UDP 20 30 172.16.1.2 Lo0 50 10

ip rsvp sender 224.250.250.3 172.16.1.2 UDP 20 30 172.16.1.2 Lo0 50 10

A#show ip rsvp sender


	To


From


Pro


Dport


Sport


Prev Hop


I/F


BPS


Bytes


	224.250. 250.1


172.16. 1.2


UDP


20


30


172.16.1.2


Lo0


50K


10K


	224.250. 250.2


172.16. 1.2


UDP


20


30


172.16.1.2


Lo0


50K


10K


	224.250. 250.3


172.16. 1.2


UDP


20


30


172.16.1.2


Lo0


50K


10K

C#show ip rsvp reservation


	To


From


Pro


DPort


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


0.0.0.0


UDP


20


0


172.16.3.2


Lo0


WF


RATE


100K


200K


	224.250. 250.2


0.0.0.0


UDP


20


0


172.16.4.2


Lo1


WF


RATE


100K


200K


	224.250. 250.3


0.0.0.0


UDP


20


0


172.16.5.2


Lo2


WF


RATE


100K


200K

B#show ip rsvp reservation


	To


From


Pro


DPort


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224.250. 250.1


0.0.0.0


UDP


20


0


10.1.3.2


Se1


WF


RATE


100K


200K


	224.250. 250.2


0.0.0.0


UDP


20


0


10.1.3.2


Se1


WF


RATE


100K


200K


	224.250. 250.3


0.0.0.0


UDP


20


0


10.1.3.2


Se1


WF


RATE


100K


200K

B#sh ip rsvp installed

RSVP: Serial1

BPS

From

Protoc

DPort

Sport

Weight

Conver
sation

100K

224.250
.250.3

0.0.0.0

UDP

266

100K

224.250
.250.2

0.0.0.0

UDP

265

100K

224.250
.250.1

0.0.0.0

UDP

264

ip rsvp reservation 224.250.250.1 172.16.1.2 UDP 20 0 172.16.3.2 Lo0 FF RATE 100 200

ip rsvp reservation 224.250.250.2 172.16.1.2 UDP 20 0 172.16.4.2 Lo1 FF RATE 100 200

ip rsvp reservation 224.250.250.3 172.16.1.2 UDP 20 0 172.16.5.2 Lo2 FF RATE 100 200

C#show ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224. 250. 250.1


172.16 .1.2


UDP


20


0


172.16.3.2


Lo0


FF


RATE


100K


200K


	224. 250. 250.2


172.16 .1.2


UDP


20


0


172.16.3.2


Lo1


FF


RATE


100K


200K


	224. 250. 250.3


172.16 .1.2


UDP


20


0


172.16.3.2


Lo2


FF


RATE


100K


200K

C#show ip rsvp installed

RSVP:

Loopback0

BPS

From

Protoc

Dport

Sport

100K

224.250
.250.1

172.16.1.2

UDP

RSVP:

Loopback1

BPS

From

Protoc

Dport

Sport

100K

224.250
.250.2

172.16.1.2

UDP

RSVP:

Loopback2

BPS

From

Protoc

DPort

Sport

100K

224.250
.250.3

172.16.1.2

UDP

B#show ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224. 250. 250.1


172.16 .1.2


UDP


20


0


10.1.3.2


Se1


FF


RATE


100K


200K


	224. 250. 250.2


172.16 .1.2


UDP


20


0


10.1.3.2


Se1


FF


RATE


100K


200K


	224. 250. 250.3


172.16 .1.2


UDP


20


0


10.1.3.2


Se1


FF


RATE


100K


200K

B#show ip rsvp installed

RSVP: Serial1

BPS

From

Protoc

Dport

Sport

Weight

Conver
sation

100K

224.250.
250.3

172.16.
1.2

UDP

266

100K

224.250.
250.2

172.16
.1.2

UDP

265

100K

224.250.
250.1

172.16
.1.2

UDP

264

ip rsvp reservation 224.250.250.1 172.16.1.2 UDP 20 0 172.16.3.2 Lo0 SE RATE 100 200

ip rsvp reservation 224.250.250.2 172.16.1.2 UDP 20 0 172.16.3.2 Lo1 SE RATE 100 200

ip rsvp reservation 224.250.250.3 172.16.1.2 UDP 20 0 172.16.3.2 Lo2 SE RATE 100 200

C#show ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224. 250. 250.1


172.16 .1.2


UDP


20


0


172.16.3.2


Lo0


SE


RATE


100K


200K


	224. 250. 250.2


172.16 .1.2


UDP


20


0


172.16.3.2


Lo1


SE


RATE


100K


200K


	224. 250. 250.3


172.16 .1.2


UDP


20


0


172.16.3.2


Lo2


SE


RATE


100K


200K

C#show ip rsvp installed

RSVP:

Loopback0

BPS

From

Protoc

Dport

Sport

100K

224.250
.250.1

172.16.1.2

UDP

RSVP:

Loopback1

BPS

From

Protoc

Dport

Sport

100K

224.250
.250.2

172.16.1.2

UDP

RSVP:

Loopback2

BPS

From

Protoc

Dport

Sport

100K

224.250
.250.3

172.16.1.2

UDP

B#show ip rsvp reservation


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224. 250. 250.1


172.16 .1.2


UDP


20


0


10.1.3.2


Se1


SE


RATE


100K


200K


	224. 250. 250.2


172.16 .1.2


UDP


20


0


10.1.3.2


Se1


SE


RATE


100K


200K


	224. 250. 250.3


172.16 .1.2


UDP


20


0


10.1.3.2


Se1


SE


RATE


100K


200K

B#show ip rsvp installed

RSVP: Serial1

BPS

From

Protoc

DPort

Sport

Weight

Conver
sation

100K

224.250.
250.3

172.16
.1.2

UDP

266

100K

224.250.
250.2

172.16
.1.2

UDP

265

100K

224.250.
250.1

172.16
.1.2

UDP

264

B#show ip rsvp res


	To


From


Pro


Dport


Sport


Next Hop


I/F


Fi


Serv


BPS


Bytes


	224. 250. 250.1


172.16 .1.2


UDP


20


0


172.16.3.2


Lo0


SE


RATE


100K


200K


	224. 250. 250.2


172.16 .1.2


UDP


20


0


172.16.3.2


Lo1


FF


RATE


100K


200K


	224. 250. 250.3


0.0.0.0


UDP


20


0


172.16.3.2


Lo2


WF


RATE


100K


200K

RSVP: Serial0 has no installed reservations

RSVP: Serial1

BPS

From

Protoc

Dport

Sport

Weight

Convers
ation

100K

224.250
.250.3

0.0.0.0

UDP

266

100K

224.250
.250.2

172.16.1.2

UDP

265

100K

224.250
.250.1

172.16.1.2

UDP

264

ip rsvp reservation 224.250.250.1 172.16.1.2 UDP 20 0 172.16.3.2 Lo0 SE RATE 100 200

ip rsvp reservation 224.250.250.2 172.16.1.2 UDP 20 0 172.16.3.2 Lo1 FF RATE 100 200

ip rsvp reservation 224.250.250.3 0.0.0.0 UDP 20 0 172.16.3.2 Lo2 WF RATE 100 200


	Debugging RSVP


	To verify the operation of RSVP use the following debug commands.


	B#debug ip rsvp

RSVP debugging is on

RSVP: Sending RESV message for 224.250.250.3

RSVP: send reservation to 10.1.2.1 about 224.250.250.3

RSVP: IP to 10.1.2.1 length=108 checksum=4DA7 (null)

RSVP: send path multicast about 224.250.250.2 on Serial1

RSVP: IP to 224.250.250.2 length=172 checksum=567F (Serial1)

RSVP: RESV message for 224.250.250.2 (Serial1) from 10.1.3.2

RSVP: PATH message for 224.250.250.2(Serial0) from 10.1.2.1

RSVP: send path multicast about 224.250.250.2 on Serial1

RSVP: IP to 224.250.250.2 length=172 checksum=567F (Serial1)

RSVP: Sending RESV message for 224.250.250.1

RSVP: send reservation to 10.1.2.1 about 224.250.250.1

RSVP: IP to 10.1.2.1 length=108 checksum=5393 (null)

RSVP: Sending RESV message for 224.250.250.2

RSVP: send reservation to 10.1.2.1 about 224.250.250.2

RSVP: IP to 10.1.2.1 length=108 checksum=4DA8 (null)

RSVP: send path multicast about 224.250.250.3 on Serial1

RSVP: IP to 224.250.250.3 length=172 checksum=567E (Serial1)

RSVP: PATH message for 224.250.250.3(Serial0) from 10.1.2.1

RSVP: send path multicast about 224.250.250.3 on Serial1

RSVP: IP to 224.250.250.3 length=172 checksum=567E (Serial1)

RSVP: send path multicast about 224.250.250.1 on Serial1

RSVP: IP to 224.250.250.1 length=172 checksum=5680 (Serial1)

RSVP: PATH message for 224.250.250.1(Serial0) from 10.1.2.1

RSVP: send path multicast about 224.250.250.1 on Serial1

RSVP: IP to 224.250.250.1 length=172 checksum=5680 (Serial1)

RSVP: RESV message for 224.250.250.1 (Serial1) from 10.1.3.2

RSVP: RESV message for 224.250.250.3 (Serial1) from 10.1.3.2

B#debug ip rsvp detail ?

<1 99> Access list

path RSVP packet contents (PATH only)

resv RSVP packet contents (RESV only)

<cr>

B#debug ip rsvp detail path ?

<1 99> Access list

<cr>


	Detailed debug information can be gathered using the detail form of the RSVP debug command for either Path or RESV debugging.


	B#debug ip rsvp detail path

RSVP debugging is on

RSVP: IP to 10.1.2.1 length=108 checksum=4DA8 (null)

RSVP: IP to 10.1.2.1 length=108 checksum=5393 (null)

RSVP: message received from 172.16.1.2

RSVP: version:1 flags:0000 type:PATH cksum:0000 ttl:62 reserved:0 length:172

SESSION

type 1 length 12: E0FAFA03
: 11000014

HOP

type 1 length 12: 0A010201
: 00000000

TIME_VALUES

type 1 length 8 : 00007530

SENDER_TEMPLATE

type 1 length 12: AC100102
: 0000001E

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=6250 bytes/sec burst depth=10000 bytes peak rate=193000 bytes/sec

min unit=0 bytes max unit=1514 bytes

ADSPEC type 2 length 84:

version=0 length in words=19

General Parameters break bit=0 service length=8

IS Hops:1

Minimum Path Bandwidth (bytes/sec):193000

Path Latency (microseconds):0

Path MTU:1500

Guaranteed Service break bit=0 service length=8

Path Delay (microseconds):3000

Path Jitter (microseconds):7772

Path delay since shaping (microseconds):3000

Path Jitter since shaping (microseconds):7772

Controlled Load Service break bit=0 service length=0

B#debug ip rsvp detail resv

RSVP debugging is on

RSVP: Sending RESV message for 224.250.250.1

RSVP: send reservation to 10.1.2.1 about 224.250.250.1

RSVP: IP to 10.1.2.1 length=108 checksum=5393 (null)

RSVP: version:1 flags:0000 type:RESV cksum:5393 ttl:255 reserved:0 length:108

SESSION type 1 length 12: E0FAFA01

: 11000014

HOP type 1 length 12: 0A010202

: 00000000

TIME_VALUES type 1 length 8 : 00007530

STYLE type 1 length 8 : 00000012

FLOWSPEC type 2 length 48:

version = 0 length in words = 10

service id = 2 service length = 9

tspec parameter id = 127 tspec flags = 0 tspec length = 5

average rate = 12500 bytes/sec burst depth = 200000 bytes peak rate = 12

500 bytes/sec

min unit = 0 bytes max unit = 65535 bytes

rspec parameter id=130 rspec flags=0 rspec length=2

requested rate=12500 slack=0

FILTER_SPEC type 1 length 12: AC100102

: 00000000


	Finally, reservations on a router can be cleared by using the clear ip rsvp command.


	B#clear ip rsvp ?

reservation Clear RSVP reservations

sender Clear RSVP path state information

B#clear ip rsvp res ?

* Clear all reservations

Hostname or A.B.C.D Destination address

B#clear ip rsvp res *