Subject: RE: [NSIS] RE: Independence of signaling and data path

From: "Freytsis, Ilya" <[email-masked]>
Date: Thu, 31 Jan 2002 18:46:02 -0500

Hi John,

I think it would help if you elaborate on the context to use the term
"proxy".

On the different subject I would like to discuss the idea prompted by the
discussions with the telephony carriers who are thinking about migrating to
VoIP and associated QoS issues. 
So far we were talking about the following entities participating in NSIS
signaling: hosts, routers/switches and controllers/BB. When we were touching
applications it was assumed something running on the host, communicating to
the other end on the other host, aware of its QoS needs and requesting QoS
from the network (please correct me here if I am completely wrong). It seems
that VoIP does not quite fit into this model since it includes other
entities (lets call it softswitch/SS even everybody agrees it is not
precisely defined but sufficient for my goal) that want to be part of the
resource allocation game but do not generate the traffic and have no
knowledge of the network topology. What I mean that from the telephony
carriers perspective only the centralize intelligence of the VoIP
application should be allowed to requests resources from the network and
endpoint (VoIP gateways, IP phones) should be prohibited to do it. (It seems
to me it is possible only with the network deploying QoS technology based
centralized resource management). This function of the SS (in my example)
can be called for the lack of the better term "Resource-Request Broker". My
question is: should NSIS protocol accommodate this functional entity? I am
pretty sure that applications other than VoIP and multimedia conferencing
may have similar requirements. 
I vote for it but I am thrilled to hear others.

Ilya Freytsis

From: [email-masked]
charset="iso-8859-1"
Subject: RE: [NSIS] RE: Independence of signaling and data path
Date: Thu, 31 Jan 2002 14:52:28 +0200
To: <[email-masked]>
Cc: <[email-masked]>

Hi Ilya,

> I think there is a big difference between idea of "router" 
> and "BB". Router is one of the most generic ideas in the
> IP world while "BB" can be much more tightly coupled
> with the bandwidth management technology in use. For that
> reason I believe it would be much easier to standardize router-router
> interworkings and leave router-BB (within the same domain) and BB-BB
> (inter-domain) in the realm of specific technology. On the 
> other hands if we'll be able to find a common ground between different 
> technologies for the BB-BB interface I definitely would not object
> to include it into NSIS.

Perhaps we should use a more generic term, such as proxy.
This proxy could be light-weight & reside at an edge router, 
or at a bandwidth broker.  I think that we should stick
to a more generic term, because when discussing Bandwidth 
broakers, we come very close to actual reservation mechanisms.

John

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