Subject: [NSIS] Re: text on layering - original mail

From: Marcus Brunner <[email-masked]>
Date: Thu, 04 Apr 2002 16:23:58 +0200

I got the feeling this might belong into a framework document. Or do you 
think it belongs into the reqs draft.

Marcus

--On Thursday, March 21, 2002 3:49 AM +0100 Sven Van den Bosch 
<[email-masked]> wrote:

> 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
>

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

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

---

From: [email-masked]
Date: Fri, 5 Apr 2002 07:28:01 +0300

Hi Marcus,

> I got the feeling this might belong into a framework 
> document. 

I agree.

John

---

From: [email-masked]
Date: Fri, 5 Apr 2002 08:50:40 +0200

Hi Marcus,

I agree that it is primarily suited for a framework draft. However, we
introduced it also as a rationale for the distinction between the different
uses of an NSIS protocol. As such, it may have some relevance there too.
Given the evolution of the requirements draft, I would agree to save this
for inclusion in the framework.

Sven.

Marcus Brunner <[email-masked]> on 04/04/2002 16:23:58

Please respond to [email-masked]

  To:          Sven Van den Bosch                             
               <[email-masked]>                  
                                                              
  cc:          [email-masked](bcc: Sven VAN DEN                
               BOSCH/BE/ALCATEL)                              

  Subject      [NSIS] Re: text on layering - original mail    
  :                                                           

Marcus