Subject: [Tsvwg] Comments on "MLPP-that-works" - Architecture

From: [email-masked]
Date: Thu, 18 Aug 2005 15:23:19 EDT

This draft concentrates completely on the end-to-end model in which the SIP 
endpoints directly send signaling messages between them (including the Reason 
codes which the other is not supposed to see). However, the referenced 
architecture requirements draft specifies that the "SIP trapezoid" must be used, and 
that "proxies" must perform some call control functions in order to properly 
provide the Assured Service capabilities, especially preemption. One essential 
function of the proxy is to "hide" information which the other user is not 
allowed to see.

It would be useful to have a description of how RSVP would operate in such an 
architecture. Specifically, the operation of RSVP in this draft requires the 
endpoint to take an active role in setting up the reservation, responding 
correctly to errors, as well as responding correctly to RSVP-initiated 
preemptions. This may lead to serious problems such as endpoints that do not respond 
properly. For this reason, it was specified that a "network" entity (proxy) must 
take an active part in this process. Consequently, it is necessary for the 
RSVP-detected need to preempt to be passed to the proxy, which then needs to 
decide what to do. The end user device can not be depended on to do this.

Without a description of how RSVP is used with the required architecture, 
this draft should not claim that it satisfies the DoD requirements.

Mike Pierce
Artel

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Fred Baker <[email-masked]>
Date: Thu, 18 Aug 2005 16:01:27 -0700

I can certainly define how an RSVP proxy might work. That said,  
you're still depending on the end device. And you're depending on the  
end device is *spades* in an open loop architecture.

On Aug 18, 2005, at 12:23 PM, [email-masked] wrote:

> It would be useful to have a description of how RSVP would operate  
> in such an architecture. Specifically, the operation of RSVP in  
> this draft requires the endpoint to take an active role in setting  
> up the reservation, responding correctly to errors, as well as  
> responding correctly to RSVP-initiated preemptions. This may lead  
> to serious problems such as endpoints that do not respond properly.  
> For this reason, it was specified that a "network" entity (proxy)  
> must take an active part in this process. Consequently, it is  
> necessary for the RSVP-detected need to preempt to be passed to the  
> proxy, which then needs to decide what to do. The end user device  
> can not be depended on to do this.