RSVP is one way. Typically RSVP is initialize by sender.
Typically, an RSVP-capable application running on an end system host on one side of a router network sends either unicast or multicast RSVP PATH (Set Up) messages to the destination end system or host on the other side of the router network with which it wishes to communicate. The initiating application is referred to as the sender; the target or destination application is called the receiver. In this example, the sender runs on the host upstream from Router A and the receiver runs on the host downstream from Router C. The router network delivers the RSVP PATH messages from the sender to the receiver. The receiver replies with RSVP RESV messages in an attempt to reserve across the network the requested resources that are required between itself and the sender. The RSVP RESV messages specify the parameters for the requisite QoS that the router network connecting the systems should attempt to offer.
In the example, the RSVP PATH messages flow in one direction: downstream from the sender, which in this example is Router A. (If the host were to initiate the RSVP PATH message, the message would flow from the host to Router A.) Router A sends the message downstream to Router B, and Router B sends it downstream to Router C. (If the downstream host were the actual receiver, Router C would send the RSVP PATH message downstream to the receiver host.) Each router in the router network must process the RSVP PATH message and route it to the next downstream hop.
The RSVP RESV messages flow in one direction: upstream from the receiver (in this example, Router C), upstream from Router C to Router B, and upstream from Router B to Router A. If the downstream host were the receiver, the message would originate with the host, which would send it to Router C. If the upstream host were the sender, the final destination of the RSVP RESV message would be the upstream host. At each hop, the router receiving the RSVP RESV message must determine whether it can honor the reservation request.
The ip rsvp bandwidth command both enables RSVP on an interface and specifies the amount of bandwidth on the interface that can be reserved (and the amount of bandwidth that can be allocated to a single flow). To ensure QoS for the RSVP reservation, WFQ is configured on the interfaces enabled for the reservation.
If the router network is capable of offering the specified (QoS) level of service, then an end-to-end reserved path is established. If not, the reservation attempt is rejected and a RESV ERROR message is sent to the receiver. The ability of each router in the network to honor the requested level of service is verified, link by link, as the RSVP RESV messages are sent across the router network to the sender. However, the data itself for which the bandwidth is reserved travels one way only: from the sender to receiver across an established PATH. Therefore, the QoS is effective in only one direction. This is the common case for one-to-many multicast data flows.
Weighted Fair Queuing (WFQ) needs to be enabled for RSVP. Although
WFQ is normally enabled by default on the Serial interfaces (2.048 Mbps and
below), once Frame Relay Traffic Shaping is enabled, WFQ is disabled.
1. Frame Relay
You need to enable the following step
1.1 Enable WFQ
If you do not use frame-relay traffic-shaping, make sure the interface is enabld for WFQ(Default). If you do use traffic-shaping, you need to enable WFQ in the map-class.
It is better to enable traffic shaping because that will be enfore queueing on the Per-VC.
1.2 Configure bandwidth under the both interface and sub-interface.
ip rsvp bandwidth 128(interface-max) 64 (per flow max)
it is important to note that when using subinterfaces that the ip rsvp bandwidth command will need to be applied to the physical along with the subinterface. If more than one subinterface is using RSVP, the physical interface’s ip rsvp bandwidth command will be the sum of all the subinterface’s ip rsvp bandwidth commands.
Example:
interface Serial3/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
ip rsvp bandwidth 500 64 //Interface-max 500=350+150, single flow max = max {subinterfaces}
!
interface Serial3/0.1 point-to-point
ip address 10.1.1.1 255.255.0.0
frame-relay interface-dlci 101
class fr-voip
ip rsvp bandwidth 350 64
!
interface Serial3/0.2 point-to-point
ip address 10.3.1.1 255.255.0.0
frame-relay interface-dlci 201
class fast-vcs
ip rsvp bandwidth 150 32
!
map-class frame-relay fr-voip
frame-relay cir 800000
frame-relay bc 8000
frame-relay mincir 128000
frame-relay fragment 280 //option
no frame-relay adaptive-shaping
frame-relay fair-queue //Enable WFQ
!
map-class frame-relay fast-vcs
frame-relay cir 200000
frame-relay bc 2000
frame-relay mincir 60000
frame-relay fragment 280
no frame-relay adaptive-shaping
frame-relay fair-queue //Enable WFQ
Rack1R5#show frame-relay pvc 101
PVC Statistics for interface Serial1/0 (Frame Relay DTE)
DLCI = 504, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.1
No comments:
Post a Comment