From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Fri Dec 27 2002 - 17:28:55 GMT-3
At 8:45 AM +0000 12/27/02, kym blair wrote:
>Vijay,
>
>You're right, you'll have to know the path between the source and
>destination to reserve bandwidth at every hop.
May I suggest it's that you have to enable RSVP at every possible hop
through possible paths?
>RSVP is to reserve and guarantee bandwidth, primaily for voice; less
>likely applications include VPNs and multicast video; but future
>designs will be more automated.
I agree that common practice is to provision it manually, but, to
some extent, there is automation. If RSVP keepalives are no longer
heard, the path is torn down. If either host then tries to open a new
reserved path, if the bandwidth for that path can be allocated over
the best route (i.e., not necessarily considering traffic
engineering), you may get the functionality restored.
>
>For now, I would think RSVP will probably only be appied to voice.
>Hopefully there won't be multiple paths between the voice routers.
>If it is applied to a multicast stream or VPN, it seems like it
>should be clear where the source and destinations are.
>
>One thing you should be careful to do ... if the RSVP involves a
>frame-relay subinterface, be sure to apply the RSVP command on
>*both* the subinterface and the physical interface.
>
>I'd like to hear other opinions. Thanks,
>
>Kym
>
>
>
>
>
>
>>From: "Vijay S Jayaraman" <vjayaram@in.ibm.com>
>>Reply-To: "Vijay S Jayaraman" <vjayaram@in.ibm.com>
>>To: ccielab@groupstudy.com
>>Subject: RSVP query
>>Date: Fri, 27 Dec 2002 12:40:51 +0530
>>
>>Hi,
>>If I need to reserve bandwidth using RSVP, I need to enable RSVP on all the
>>interfaces along the entire path of the packet flow......and for each
>>multiple paths too...Is this right?
>>
>>So If I get a question on the lab to reserve bandwidth for a flow and its
>>not mentioned where the packet flow is terminating, what would I need to do
>>to get a 100% on the question?
.
This archive was generated by hypermail 2.1.4 : Fri Jan 17 2003 - 17:21:53 GMT-3