RE: [Tsvwg] Rr:Comments on draft-lefaucheur-rsvp-dste-02.txt

Hi Rurick,

________________________________

	From: Rurick Kellermann [mailto:rurick@nortel.com] 
	Sent: mercredi 9 mars 2005 20:53
	To: Francois Le Faucheur (flefauch)
	Cc: tsvwg@ietf.org
	Subject: Re: [Tsvwg] Rr:Comments on
draft-lefaucheur-rsvp-dste-02.txt

	Francois, 

	Each of the hosts issuing a RESV is waiting for an approval of
its 
	request. When aggregation is performed, one might have the case
where 
	the aggregate of the reservation could fail due to b/w, etc.  

	In that case, a) shouldn't the aggregator inform the individual
hosts 
	with a PathErr message? 
	[FLF:] Remember that with RSVP the reservation is controlled by
the destination (which issues the Resv). In case of CAC failure, you
want to notify the destination and the way to do that is to send a
ResvErr. The source need not be informed about the CAC failure.

	In the context of achieving CAC for VoIP, the destination , upon
receipt of a ResvErr, would then notify its Call Manager (eg SIP
Proxy/Server) that the reservation (aka "SIP precondition") is not met.
The CAll Manager woul take appropriate action (eg abort call setup and
return some tone indicating network busy).

	 b) if the condition which caused the PathErr 
	message persists, say due to insufficient b/w for the aggregate,

	 some 
	individual requests could have obtained a PATH if they had been 
	responded individually (i.e. through a PATH message instead of
an 
	E2EPATH). 
	[FLF:] I am not quite with you. Say we have a TE tunnel with
bandwidth B which can currently fit 10 calls. Say, we have 10 calls that
try to get established. Each source will send a Path, ecah destination
will send a Resv which will all be accepted by CAC over teh tunnel. Say
another 5 calls come and the Tunnel head-end can increase the Tunnel
size to fit total of 15 calls. Then the 5 additional calls will get
accepted. Say another 5 calls come in, and say teh TE tunnel Head-end
can no longer increase teh TE Tunnel size. Then each source for these 5
last call will send a Path and each destination will send a Resv. Each
Resv will be rejected by CAC on teh tunnel headend and a ResvErr (with
error cause "no bandwidth") will be generated by teh tunnel head-end
towards each destination.

	Does that clarify?

	Francois

	Regards, 

	Rurick 

	> >> 5) Section 3.6 
	> >> 
	> >> On a reservation failure at the aggregator, is a PathErr 
	> >> also sent out 
	> >> upstream (towards sender) ? 
	>  
	> I don't believe so. 
	> In regular RSVP, Path Err report errors in the processing of
Path 
	> messages. In case of CAC rejection on the Resv, we should just
send a 
	> ResvhErr. The destination may decide to try make a smaller
reservation 
	> or try a different Intserv service. Everything is normal as
far Path is 
	> concerned. 
	> 
	> >> Finally, you may want to mention somewhere (just to prevent

	> >> confusion) 
	> >> that these reservations are assumed to be unidirectional. 
	>  
	> We can state that. But RSVP reservations are unidirectional of
course, 
	> so sas there something specific that you feel would create
confusion? 
	> 
	> Thank you for your review an comments. 
	> 
	> Francois 
	> 
	> >> thanks, 
	> >> -arthi 
	> >> 
	> 
	> _______________________________________________ 
	> tsvwg mailing list 
	> tsvwg@ietf.org 
	> https://www1.ietf.org/mailman/listinfo/tsvwg 
	> 