Subject: [NSIS] text on layering - original mail

From: "Sven Van den Bosch" <[email-masked]>
Date: Thu, 21 Mar 2002 03:49:07 +0100

Hi,

We have been thinking about the QI/QC definitions and we have tried to
arrange the QC/QI functional entities in a logical relation that covers the
use case scenarios that have been proposed so far. From this, we hope to
derive clearer definitions.

The general logical relationships are depicted below (for simplicity, only
signaling relations are drawn)

             +--+ (a) +--+       (a)       +--+ (a) +---+
          +->|QI|---->|QC|---------------->|QC|---->| QR|--+
QI,QC,QR roles for e2e QoS protocol
          |  +--+    /+--+\               /+--+\    +---+  |
          |        /        \           /        \         v
+--+ (b) +--+  +--+(b)+--+(b)+--+   +--+(b)+--+(b)+--+   +--+ (b) +--+
|QI|---->|QR|  |QI|-->|QC|-->|QR|   |QI|-->|QC|-->|QR|   |QI|---->|QR|
QI,QC,QR roles for local QoS protocol
+--+     +--+  +--+   +--+   +--+   +--+   +--+   +--+   +--+     +--+

In this pictures we clearly distinguish two applications for the NSIS
protocol:
(a) NSIS as end-to-end QoS signaling protocol
(b) NSIS as local QoS signaling protocol

Local, in this case, is defined as local to a QoS domain. A QoS domain is
defined as a contiguous part of the network supporting the same QoS
technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), NSIS
actually competes with other technologies offering local QoS, such as PDP,
RSVP, ...

The above picture seems to suggest an out-of-band approach but this is not
the case. The QCs can be implemented in a distributed way and redrawing the
picture then gives a different view.

         +--+(a)+--+   (a)    +--+(a)+--+   (a)    +--+(a)+--+
         |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR|
QI,QC,QR roles for e2e QoS protocol
         +--+   +--+          +--+   +--+          +--+   +--+
          ^       v             ^     v             ^      v
+--+ (b) +--+   +--+(b)+--+(b)+--+   +--+(b)+--+(b)+--+   +--+ (b) +--+
|QI|---->|QR|   |QI|-->|QC|-->|QR|   |QI|-->|QC|-->|QR|   |QI|---->|QR|
QI,QC,QR roles for local QoS protocol
+--+     +--+   +--+   +--+   +--+   +--+   +--+   +--+   +--+     +--+

In this case, it is clear that an in-band solution is also supported. The
end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on a
router. Note that in this picture, the signaling in the access is done with
a local QoS protocol. This can be either an existing protocol, or the NSIS
protocol in its role of local QoS signaling mechanism. This leads to the
following requirements:

(a) If an NSIS protocol is only used end-to-end, then mobility need not be
supported
(b) If an NSIS protocol is used as a local QoS signaling mechanism then
mobility must be supported, both on the QI-QC and QC-QC interface
(c) If the same protocol is desired in (a) and (b), the protocol should be
modular and the mobility aspects need to be separable from the rest

Both of the above scenarios assume that the host is not NSIS-aware. This is
a reasonable assumption in a first phase. In a later stage, when hosts are
NSIS-aware, the host speaks the NSIS protocol, but as a local QoS signaling
technology! This allows this case to be backwards compatible with the above
scenarios. It means that (b) in the access is an NSIS protocol. It also
means that the host will always trigger the local QoS signaling mechanism.

This suggests the following definitions for the QI, QC, QR

- QoS Initiator: Network entity, located at the boundary of a QoS domain,
responsible for initiating a (local or end-to-end) QoS mechanism. If it is
the QI of a local protocol, it can be triggered by higher layers
(applications or end-to-end QoS Controller). If it is the QI of an
end-to-end protocol, it can be triggered by applications or by the QoS
Receiver of a local QoS signaling mechanism.

- QoS Controller: Network entity responsible for interpreting and
implementing the signalled QoS in the network. Failure to do so implies an
admission control decision. It can only be triggered by a QI or another QC.

-QoS Receiver: Network entity, located at the boundary of a QoS domain,
responsible for terminating a (local or end-to-end) QoS mechanism. It has
the additional functionality that it may initiate an acknowledgment towards
the QI and that it may trigger a QI or QC in the NSIS end-to-end protocol.

If this can be accepted by the NSIS community, we propose to add this text
to the requirements document as a clarification of the QI/QC model that is
used there.

_________________________________________________________________
Chat on line met vrienden en probeer MSN Messenger uit: 
http://messenger.msn.nl

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 22 Mar 2002 01:51:29 +0100

Hi Sven,

Why do you make restrictions on triggering? I would remove
that. For instance, you state that a QC can only be triggered by
a QI and a QC. However, there are cases when a QC may decide
to create an aggregate out of existing reservations, so it 
may start a new protocol (trans)action to other QCs in (a) 
without being triggered by other entities.

Regards,
  Roland

[email-masked] said:
> - QoS Initiator: Network entity, located at the boundary of a QoS
> domain, responsible for initiating a (local or end-to-end) QoS
> mechanism. If it is the QI of a local protocol, it can be triggered by
> higher layers (applications or end-to-end QoS Controller). If it is
> the QI of an end-to-end protocol, it can be triggered by applications
> or by the QoS Receiver of a local QoS signaling mechanism.

> implementing the signalled QoS in the network. Failure to do so
> implies an admission control decision. It can only be triggered by a
> QI or another QC.

> -QoS Receiver: Network entity, located at the boundary of a QoS
> domain, responsible for terminating a (local or end-to-end) QoS
> mechanism. It has the additional functionality that it may initiate an
> acknowledgment towards the QI and that it may trigger a QI or QC in
> the NSIS end-to-end protocol.

> If this can be accepted by the NSIS community, we propose to add this
> text to the requirements document as a clarification of the QI/QC
> model that is used there.