Cisco Cisco IOS Software Release 12.2(33)SRE

Page de 16
RSVP Interface-Based Receiver Proxy
  Prerequisites for RSVP Interface-Based Receiver Proxy
2
Cisco IOS Release: Multiple releases
Prerequisites for RSVP Interface-Based Receiver Proxy
You must configure an IP address and enable Resource Reservation Protocol (RSVP) on one or more 
interfaces on at least two neighboring routers that share a link within the network.
Restrictions for RSVP Interface-Based Receiver Proxy
Filtering using access control lists (ACLs), application IDs, or other mechanisms is not supported.
A provider edge (PE) router cannot switch from being a proxy node to a transit node for a given flow 
during the lifetime of the flow.
Information About RSVP Interface-Based Receiver Proxy
To use the RSVP Interface-Based Receiver Proxy feature, you should understand the following concepts:
Feature Overview of RSVP Interface-Based Receiver Proxy
The RSVP Interface-Based Receiver Proxy feature allows you to use RSVP to signal reservations and 
guarantee bandwidth on behalf of a receiver that does not support RSVP, by terminating the PATH 
message and generating a RESV message in the upstream direction on an RSVP-capable router on the 
path to the endpoint. An example is a video-on-demand flow from a video server to a set-top box, which 
is a computer that acts as a receiver and decodes the incoming video signal from the video server.
Because set-top boxes may not support RSVP natively, you cannot configure end-to-end RSVP 
reservations between a video server and a set-top box. Instead, you can enable the RSVP interface-based 
receiver proxy on the router that is closest to that set-top box.
The router terminates the end-to-end sessions for many set-top boxes and performs admission control on 
the outbound (or egress) interface of the PATH message, where the receiver proxy is configured, as a 
proxy for Call Admission Control (CAC) on the router-to-set-top link. The RSVP interface-based 
receiver proxy determines which PATH messages to terminate by looking at the outbound interface to be 
used by the traffic flow.
You can configure an RSVP interface-based receiver proxy to terminate PATH messages going out a 
specified interface with a specific action (reply with RESV, or reject). The most common application is 
to configure the receiver proxy on the edge of an administrative domain on interdomain interfaces. The 
router then terminates PATH messages going out the administrative domain while still permitting PATH 
messages transitioning through the router within the same administrative domain to continue 
downstream. 
In the video-on-demand example described above, the last-hop Layer 3 router supporting RSVP 
implements the receiver proxy, which is then configured on the interfaces facing the Layer 2 distribution 
network (for example, Digital Subscriber Line access [DSLAM] or cable distribution). Also, since RSVP 
is running and performing CAC on the router with the receiver proxy, you can configure RSVP 
enhancements such as local policy and Common Open Policy Service (COPS) for more fine-grained 
control on video flow CAC.