Subject: [NSIS] Two kinds of requirements

From: [email-masked]
Date: Fri, 21 Dec 2001 12:24:39 +0100

Hello all,

From the discussion in Salt Lake city and the drafts submitted, one can
easily see that people are suggesting improvements to QoS signalling at
two totally different levels (some at session level and some at
transport level).

First of all, there are drafts suggesting some improvements in the
session setup procedures (i.e. the ability to negotiate the preferred
QoS level between end users during SDP negotiation in SIP, so before the
actual resources are being setup). The QoS information negotiated at the
session layer determines the QoS level both endusers have to use for 
their local access connection. This first kind of 'session level QoS
negotiation' happens end-to-end between the two end-users.

Secondly, there are drafts suggesting that we need
improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
used to actually provision the QoS at the transport level between two
endusers. This second kind of 'transport level QoS signalling' can
consist of several phases: end-to-edge and edge-to-edge. 

It's important that everybody realises that, in order to give endusers
true end-to-end Quality of Service, we need improvements for QoS both at
session and transport level. Also its important to understand that they
are not uncorrelated. Providers want to be able to control (e.g. via
policy control mechanisms) that the QoS requested at the transport level
is not exceeding the QoS negotiated/authorised previously at session
level. So, what about developing in NSIS a modular framework
incorporating both session and transport level QoS signalling with
possible hooks between the two layers (e.g. for policy enforcement).

Lieve

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

---

From: Brian Williams <[email-masked]>
Date: 23 Dec 2001 10:57:20 +1100

Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian