Subject: [NSIS] section on QI/QC and QI/QC terminology

From: [email-masked]
Date: Tue, 5 Mar 2002 14:30:46 +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.

Hope this helps,
Sven.

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 8 Mar 2002 11:43:59 +0100

Hi Sven

I propose to postpone the terminology of QoS Initiator and
QoS Controller to framework draft. Meaning that 
the terms QoS Initiator and QoS Controller will not be used 
in the NSIS WG requirements draft.

The main reason for this is that, according to John,
the NSIS WG requirements draft should not contain any separation/grouping 
of QoS requirements. This separation will probably be done in the 
framework draft. There we could also define entities such as 
QI and QC.

Best Regards,
Georgios

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: dinsdag 5 maart 2002 14:31
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [NSIS] section on QI/QC and QI/QC terminology

Hi,

Hope this helps,
Sven.

---

From: [email-masked]
Date: Fri, 8 Mar 2002 13:36:13 +0200

Hi Georgios,

> framework draft. There we could also define entities such as 

Bigger question to the Working Group.  Is NSIS peer-to-peer;
Client-server; or a mixture.  I can see it as a mixture.
In end-to-edge signaling, it is client-server, however, in 
both end-to-end and edge-to-edge, it is peer-to-peer.

I think the Requirements document should have some terminology
that describes the parties involved in the signaling ... however,
I don't think that the WG has decided on what terminology to use.

John

---

From: [email-masked]
Date: Fri, 8 Mar 2002 15:28:49 +0100

Georgios,

OK, if that is the consensus. Let's get back to the suggestion when we
discuss the framework then. One of the basic points in the referenced mail
was the distinction between NSIS as a local QoS protocol and an end-to-end
protocol. Do you think it makes sense to have this?

Sven.

"Georgios Karagiannis (ELN)" <[email-masked]> on
08/03/2002 11:43:59

  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL,         
               [email-masked]                                  
                                                              
  cc:                                                         

  Subject      RE: [NSIS] section on QI/QC and QI/QC          
  :            terminology                                    

Hi Sven

Best Regards,
Georgios

-----Original Message-----

Hi,

Hope this helps,
Sven.

---

From: Kappler Cornelia <[email-masked]>
Date: Fri, 8 Mar 2002 16:53:22 +0100

Hi John and Georgios, 

as probably everybody else I agree we need to settle on some terminology. The alternative is, in each requirement, to list all possibilities we can think of. Instead of e.g.:

"5.3.1. Possibility for automatic release of resources after failure
When the QoS Intitiator goes down, the resources it requested should be released since they are no longer necessary"

we put

"5.3.1... When an end system, an edge router, or a signalling proxy go down and they have been initiating a reservation, the resources they requested should be released since..."

not too elegant, and, more importantly, not sufficiently general. So lets say

"5.3.1 ...When an entity that initiated a reservation goes down, the resources it requested..."

To make it more legible we replace "entity that initiated a reservation" = QoS Intitiator

This provides the additional benefit that in a terminology section we can more precisely define what a QoS Initiator is (may be the perfectly precise definition could be left to the framework). Likewise QoS Controller.

[If you would rather use "ETIAR" (Entity That Intitiated A Reservation) or whatever fine with me. (sorry for becoming silly)]

I dont understand yet how this implies a separation / grouping of requirements. There has been so much going on on this list that I lost this bit. Georgios, may be you could  expand on this problem?

Regarding whether NSIS is client/server or peer2peer or a mixture, do we need to fix this in the requirements?

Cornelia

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, March 08, 2002 12:36 PM
> To:	[email-masked]; [email-masked]; [email-masked]
> Subject:	RE: [NSIS] section on QI/QC and QI/QC terminology
> 
> Hi Georgios,
>

---

From: [email-masked]
Date: Mon, 11 Mar 2002 09:24:11 +0100

Cornelia,

I agree with you that we need to have easy terminology to describe what we
are talking about. There is one thing missing in the QI/QC terminology. As
far as I understand, the QI initiates the QoS *for the NSIS signaling*. So
it is not necessarily the end host even if the end host initiates the
signaling. Therefore, I would propose to call it 'initiating a particular
level of NSIS signaling'

Do you agree?,
Svenm.

Kappler Cornelia <[email-masked]> on 08/03/2002 16:53:22

  To:          "[email-masked]'"                    
               <[email-masked]>,                     
               [email-masked],          
               [email-masked]                                  
                                                              
  cc:          (bcc: Sven VAN DEN BOSCH/BE/ALCATEL)           

Hi John and Georgios,

as probably everybody else I agree we need to settle on some terminology.
The alternative is, in each requirement, to list all possibilities we can
think of. Instead of e.g.:

"5.3.1. Possibility for automatic release of resources after failure
When the QoS Intitiator goes down, the resources it requested should be
released since they are no longer necessary"

we put

"5.3.1... When an end system, an edge router, or a signalling proxy go down
and they have been initiating a reservation, the resources they requested
should be released since..."

not too elegant, and, more importantly, not sufficiently general. So lets
say

"5.3.1 ...When an entity that initiated a reservation goes down, the
resources it requested..."

To make it more legible we replace "entity that initiated a reservation" =
QoS Intitiator

This provides the additional benefit that in a terminology section we can
more precisely define what a QoS Initiator is (may be the perfectly precise
definition could be left to the framework). Likewise QoS Controller.

[If you would rather use "ETIAR" (Entity That Intitiated A Reservation) or
whatever fine with me. (sorry for becoming silly)]

I dont understand yet how this implies a separation / grouping of
requirements. There has been so much going on on this list that I lost this
bit. Georgios, may be you could  expand on this problem?

Regarding whether NSIS is client/server or peer2peer or a mixture, do we
need to fix this in the requirements?

Cornelia

> To:     [email-masked];
[email-masked]; [email-masked]

---

From: Kappler Cornelia <[email-masked]>
Date: Tue, 12 Mar 2002 12:29:05 +0100

I agree. Cornelia

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Monday, March 11, 2002 9:24 AM
> To:	Kappler Cornelia
> Cc:	[email-masked]'; [email-masked]; [email-masked]
> > > the terms QoS Initiator and QoS Controller will not be used>

---

From: Kappler Cornelia <[email-masked]>
Date: Tue, 12 Mar 2002 16:23:06 +0100

Hi Sven, 

thank you for your detailed analysis.

I agree with you the current definition of QI ("receives trigger from _higher_ layer to start signaling") does run into problems for some scenarios, such as in UMTS, where PDP context signaling (from a _lower_ layer) is being translated into normal IP QoS signaling at the GGSN (possibly via the P-CSCF). 

Your suggestion points a way for solving this problem (by offering an alternative Def of QI, and also of QC and QR). However I have the following comments (inline). Generally I'd like to modify your definitions somewhat to lift unnecessary restrictions on protocol design and network structure they seem to imply. I am not sure though whether my modifications dont run into other problems :-)

> Sent:	Tuesday, March 05, 2002 2:31 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject:	section on QI/QC and QI/QC terminology
> 
> Hi,
> 
	The term "end2end QoS signaling protocol" I dont find entirely fitting, since it seems to imply participation of end hosts. However, a typical scenario we discuss is edge2edge signaling. What about "global QoS signaling protocol"?

	Would e2e per-flow signaling - tunnelled through most of the network - which might be necessary when no SIP-type e2e exchange of QoS took place, be "local" NSIS signaling? Probably not. However when regarded as "global", what about another signaling on top, signaling for aggregates? This is one of the unnecessary restrictions / assumptions I see with your approach.

	Your figure seems to imply global NSIS QoS signaling is always triggered by end host signaling. However e.g. signaling for aggregates deep in the backbone might only loosly be coupled to end host signaling. (You may not have intended your figure as covering all possible scenarios)

> actually competes with other technologies offering local QoS, such as PDP,
	ok. This maps my view.

>          +--+   +--+          +--+   +--+          +--+   +--+> 
>           ^       v             ^     v             ^      v
	This seems to already imply a design choice. Why would the "e2e" / global NSIS protocol not also support mobility? In this case local signaling support is not needed.

	...In fact I dont have any particular oppinion on this subject. However in my view some detailed analysis is necessary to decide whether mobility support by a local protocol is always sufficient!? 

> modular and the mobility aspects need to be separable from the rest
	OK.

> means that the host will always trigger the local QoS signaling mechanism.
	Why would the host never trigger the global NSIS protocol?

> Receiver of a local QoS signaling mechanism.
	These triggers make sense to me (although a QC isn't a higher layer, is it?). However what about the following problem with this definition: In an RSVP-like scenario, per-flow signaling is tunnelled through an aggregation area (may be this is how the NSIS protocol is going to work, too). The aggregating router initiating the tunnelling, would it be a QR for the per-flow signaling? Not really, because the signalling is not terminated.So it is a QC. But then the QI initiating the aggregation is triggered by a QC. 

	May be we have to become very broad with the QI Def by saying "network entity initiating NSIS signaling, including an entity initiating one type of NSIS signaling after terminating another type of NSIS signaling.In which case it would also be a QR."

	Note I restrict QI to NSIS signaling because we dont need to worry about other kinds of signaling except by providing hooks for integrating it. With this Def the GGSN (P-CSCF) classifies as QI as well as an aggregating entity. The "including" sentence I put in to provide for interworking of local and global NSIS signaling e.g. at an NSIS proxy.

	Another point: I'd rather not restrict the QI to be located on the boundary of a QoS Domain: It may be a bandwidth broker, located anywhere in a domain, it may be a end host (is the end host always located "at the boundary" of a QoS domain?). What if there is a address boundary inside a QoS domain? Would address translation involve re-initiating QoS signaling? Plus there may be a number of reasons for not locating the QI at the boundary. Locating the QI at the boundary or a QoS domain includes too many asumption about the network structure. So my suggestion is dropping this restriction.

> the QI and that it may trigger a QI or QC in the NSIS end-to-end protocol.
	Again I have an issue with "located at the boundary..:".

	Looking forward to your comments

	Cornelia

---

From: [email-masked]
Date: Tue, 12 Mar 2002 16:59:20 +0100

Hi Cornelia,

Thanks for your reply. I have some comments inline.

Bye,
Sven.

Kappler Cornelia <[email-masked]> on 12/03/2002 16:23:06

                                                              
  cc:          Maarten BUCHLI/BE/ALCATEL@ALCATEL, Danny       
               GODERIS/BE/ALCATEL@ALCATEL, Hancock Robert     
               <[email-masked]>                    

  Subject      RE: section on QI/QC and QI/QC terminology     
  :                                                           

Hi Sven,

I agree with you the current definition of QI ("receives trigger from
_higher_ layer to start signaling") does run into problems for some
scenarios, such as in UMTS, where PDP context signaling (from a _lower_
layer) is being translated into normal IP QoS signaling at the GGSN
(possibly via the P-CSCF).

Your suggestion points a way for solving this problem (by offering an
alternative Def of QI, and also of QC and QR). However I have the following
comments (inline). Generally I'd like to modify your definitions somewhat
to lift unnecessary restrictions on protocol design and network structure
they seem to imply. I am not sure though whether my modifications dont run
into other problems :-)

> From:   [email-masked]
[SMTP:[email-masked]]
> QI,QC,QR roles for e2e QoS protocol
     The term "end2end QoS signaling protocol" I dont find entirely
fitting, since it seems to imply participation of end hosts. However, a
typical scenario we discuss is edge2edge signaling. What about "global QoS
signaling protocol"?

Sven>> The picture has two layers of NSIS signaling:
- end-to-end NSIS signaling (where the QI and the QR are located at the
edge of the network). I don't think it completely maps to your edge-to-edge
scenario because that specifically talks about edges of domains. Here it is
really the edge of the network from the end-hosts point of view.
- NSIS as a local QoS signaling protocol. Note that between the end host
and the edge of the network, there is only NSIS signaling at this level.
This means that NSIS end-to-end does not require participation of the end
host. Even if the end host is an NSIS speaker, it will use NSIS as a local
QoS signaling protocol to get to the (top-level) QI where mapping will take
place and end-to-end signaling is initiated.

     Would e2e per-flow signaling - tunnelled through most of the network -
which might be necessary when no SIP-type e2e exchange of QoS took place,
be "local" NSIS signaling? Probably not. However when regarded as "global",
what about another signaling on top, signaling for aggregates? This is one
of the unnecessary restrictions / assumptions I see with your approach.

Sven>> Setting up the aggregates is a local matter for each of the QCs. A
QC may choose to modify its aggregate based on incoming micro-flows but
this process will not be triggered by microflow arrivals.

     Your figure seems to imply global NSIS QoS signaling is always
triggered by end host signaling. However e.g. signaling for aggregates deep
in the backbone might only loosly be coupled to end host signaling. (You
may not have intended your figure as covering all possible scenarios)

Sven>> Signaling for aggregates in the backbone is not triggered by the
NSIS end-to-end signaling. In fact, for this a local QoS technology is used
under the authority of the QC (via network management). This local
technology may exist or it may be another application of the local NSIS
signaling.

     ok. This maps my view.

> QI,QC,QR roles for e2e QoS protocol
     This seems to already imply a design choice. Why would the "e2e" /
global NSIS protocol not also support mobility? In this case local
signaling support is not needed.

     ...In fact I dont have any particular oppinion on this subject.
However in my view some detailed analysis is necessary to decide whether
mobility support by a local protocol is always sufficient!?

Sven>> I think mobility definitely needs to be supported in the local
protocol. When the (top-level) QI is a fixed point (joint point of
reservation) then the end-to-end (or top-level) signaling does not need to
support mobility. This relaxes some of the requirements which is a good
thing. I think that without loss of generality we can have this situation.
The only design impact this may have is when we want to use the same
protocol for local and global NSIS signaling. In this case we need to make
it modular so that a global QC only has to look at the information relevant
to him. This requirement was already identified.

     OK.

Sven>> It doesn't need to. When he is an NSIS speaker he can initiate the
local NSIS protocol. At the global QI his requirement will then be mapped
into the e2e NSIS protocol. If he didn't have any requirements that can't
be offered be the global NSIS protocol he could theoretically initiate  e2e
signaling. I don't think it is needed however.

> Receiver of a local QoS signaling mechanism.
     These triggers make sense to me (although a QC isn't a higher layer,
is it?). However what about the following problem with this definition: In
an RSVP-like scenario, per-flow signaling is tunnelled through an
aggregation area (may be this is how the NSIS protocol is going to work,
too). The aggregating router initiating the tunnelling, would it be a QR
for the per-flow signaling? Not really, because the signalling is not
terminated.So it is a QC. But then the QI initiating the aggregation is
triggered by a QC.

Sven>> In the definition, I mentioned application or end-to-end/global QC
as possible triggers. So maybe we should say that a QC on the client NSIS
layer (global) can trigger a QI on the server NSIS layer (local). Would
this solve the issue in you opinion?

     May be we have to become very broad with the QI Def by saying "network
entity initiating NSIS signaling, including an entity initiating one type
of NSIS signaling after terminating another type of NSIS signaling.In which
case it would also be a QR."

     Note I restrict QI to NSIS signaling because we dont need to worry
about other kinds of signaling except by providing hooks for integrating
it. With this Def the GGSN (P-CSCF) classifies as QI as well as an
aggregating entity. The "including" sentence I put in to provide for
interworking of local and global NSIS signaling e.g. at an NSIS proxy.

Sven>> I fully agree: QI/QC only have a meaning in NSIS signaling.

     Another point: I'd rather not restrict the QI to be located on the
boundary of a QoS Domain: It may be a bandwidth broker, located anywhere in
a domain, it may be a end host (is the end host always located "at the
boundary" of a QoS domain?). What if there is a address boundary inside a
QoS domain? Would address translation involve re-initiating QoS signaling?
Plus there may be a number of reasons for not locating the QI at the
boundary. Locating the QI at the boundary or a QoS domain includes too many
asumption about the network structure. So my suggestion is dropping this
restriction.

Sven>> OK. Maybe we should say: located at the boundary of an NSIS
signaling domain.

     Cornelia

---

From: Kappler Cornelia <[email-masked]>
Date: Fri, 15 Mar 2002 15:17:19 +0100

Hi Sven, 

what I dont understand yet is whether your QI/QC relationship Figure (describing basically a NSIS framework) is supposed to cover all scenarios in which NSIS signaling is applicable, or just is applicable to a subset, such as those described in your Req draft. 

I think you have in mind a general framework. In this case I have a different views of the NSIS scope / I find your framework too restrictive. Before embarking on a discussion on this though I'd like to doublecheck your intention?

Cornelia

> Sent:	Tuesday, March 12, 2002 4:59 PM
> To:	Kappler Cornelia
> Cc:	[email-masked]; [email-masked]; [email-masked]; Hancock Robert
> Subject:	RE: section on QI/QC and QI/QC terminology
> 
> Hi Cornelia,
> 
> > +--+ (b) +--+  +--+(b)+--+(b)+--+   +--+(b)+--+(b)+--+   +--+ (b) +--+> 
> > end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on> 
> a
> > r> outer. Note that in this picture, the signaling in the access is done
> with
> this solve the issue in you opinion?> 
> 
>      May be we have to become very broad with the QI Def by sa> ying "network

---

From: [email-masked]
Date: Mon, 18 Mar 2002 12:22:51 +0100

Hi Cornelia,

The figure describing NSIS used as a local and as a global protocol was
intended as a general framework
and not specifically towards a certain scenario.

Why do you consider it too restrictive?

Regards,
Maarten

Kappler Cornelia <[email-masked]> on 15/03/2002 15:17:19

 To:      Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, Kappler      
          Cornelia <[email-masked]>          
                                                              
 cc:      [email-masked], Maarten BUCHLI/BE/ALCATEL@ALCATEL,   
          Danny GODERIS/BE/ALCATEL@ALCATEL, Hancock Robert    
          <[email-masked]>                         

 Subject: [NSIS] RE: section on QI/QC and QI/QC terminology   

Hi Sven,

what I dont understand yet is whether your QI/QC relationship Figure
(describing basically a NSIS framework) is supposed to cover all scenarios
in which NSIS signaling is applicable, or just is applicable to a subset,
such as those described in your Req draft.

I think you have in mind a general framework. In this case I have a
different views of the NSIS scope / I find your framework too restrictive.
Before embarking on a discussion on this though I'd like to doublecheck
your intention?

Cornelia

> > Both of the above scenarios assume that the host is not NSIS-aware.
This
> is

---

From: Kappler Cornelia <[email-masked]>
Date: Wed, 20 Mar 2002 19:00:03 +0100

Hi Maarten and Sven, 

may be this discussion is outdated by what you've been discussing at the NSIS WG meeting which unfortunately I was not able to attend. 

Anyways

> Why do you consider it too restrictive?
Cornelia:

Let me summarize your framework as I understand it:

You fix a two-level signaling hierarchy for any kind of signaling scenario (e.g. mobile and fixed): end-to-end (global) and local. In a first step, NSIS is only global, and interworks with local signaling mechanisms. I.e. it is nowhere "stand-alone". In a second step, we would also have a local NSIS signaling protocol, which may replace the "legacy" local signaling. Global and local signaling must always work together, i.e. with just one of them QoS cannot be set up e2e.

The end host never initiates global / end-to-end signaling,  but just does local signaling to some access router (gateway), which acts as a proxy and QI, and translates the reservation into NSIS e2e/global signaling

Now why do I consider this as too restrictive:

- why is it necessary to always involve a proxy? Why would the end host never initiate e2e signaling?

- it fixes a two-level hierarchy. However, more deeply nested hierarchies are also possible. E.g. when some edge router pipes a per-flow aggregation into a (possibly previously set-up) aggregate reservation. Note this idea can even be extended by the next edge router piping the aggregates it receives into "super- aggregates".

"Sven>> Setting up the aggregates is a local matter for each of the QCs. A
QC may choose to modify its aggregate based on incoming micro-flows but
this process will not be triggered by microflow arrivals."

Cornelia:
When a QC initiates an aggregate reservation it is a QI! (or rather: the logical QC instance on a particular node receives per flow signaling and triggers (based on incoming micro-flows, but not because of a particular microflow arrival, I agree) the logical QI instance on the same node to initiate or modify an aggregate reservation.) This is also consistent with the terminology definition you sent out after the NSIS meeting, where the QC may trigger a QI to initiate another instance of the NSIS protocol

Another example of a more-than-two-level hierarchy: a QC initiates per-flow e2e signaling. At the edge of some administrative domain a QC tunnels it to the other edge of the domain and initiates local (domain-specific) NSIS signaling, may be because a mapping of QoS parameters to local scope parameters is necessary. Now this administrative domain consists of more than one QoS domain, i.e. different QoS mechanisms are supported. At the edge of each of these domains, local (non-NSIS) signaling mechanisms are therefore initiated (e.g. RSVP, or no signaling, and instead DSCPs). 

This last example may be a bitfar fetched... however I think we should allow the protocol to be arbitrarily deeply nested, if only because it is more general and we dont know what the future is going to bring. Besides I dont see having an arbitrary number of levels would make the protocol more complicated 

- what about a scenario where no end host is involved, but a BB triggers an edge router to set-up an aggregate reservation through a domain? The BB would send this trigger because of some SLA agreement process rather than because of the interpretation of per-flow reservations. I dont think this would map to your framework either, because there is no reason for starting with a local NSIS signaling that later is translated into global NSIS signaling.

Best regards, Cornelia

---

From: [email-masked]
Date: Thu, 21 Mar 2002 17:34:31 +0100

Hi Cornelia,

I have written some comments in-line with [MB].

Regards,
Maarten

Kappler Cornelia <[email-masked]> on 20/03/2002 19:00:03

 To:      Maarten BUCHLI/BE/ALCATEL@ALCATEL                   
                                                              
 cc:      Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL,              
          [email-masked], Danny GODERIS/BE/ALCATEL@ALCATEL,    
          Hancock Robert <[email-masked]>          

 Subject: RE: [NSIS] RE: section on QI/QC and QI/QC           
          terminology                                         

Hi Maarten and Sven,

may be this discussion is outdated by what you've been discussing at the
NSIS WG meeting which unfortunately I was not able to attend.

Anyways

Cornelia:

You fix a two-level signaling hierarchy for any kind of signaling scenario
(e.g. mobile and fixed): end-to-end (global) and local. In a first step,
NSIS is only global, and interworks with local signaling mechanisms. I.e.
it is nowhere "stand-alone". In a second step, we would also have a local
NSIS signaling protocol, which may replace the "legacy" local signaling.
Global and local signaling must always work together, i.e. with just one of
them QoS cannot be set up e2e.

The end host never initiates global / end-to-end signaling,  but just does
local signaling to some access router (gateway), which acts as a proxy and
QI, and translates the reservation into NSIS e2e/global signaling

- why is it necessary to always involve a proxy? Why would the end host
never initiate e2e signaling?

[MB] First option is that access networks will still use their technology
specific QoS protocol. In this case there is a clear need to have an entity
(proxy) that translated the access QoS signaling to the global NSIS
signaling.
Another (more future oriented) option is that the access network speaks
NSIS.
However, such a (local) NSIS access protocol requires much more
functionality,
e.g. mobility support. Therefore, the local NSIS protocol in the access
will
be much more specific while the QoS signaling in the core can be kept as
simple
as possible. Also, a proxy allows for smooth migration from access specific
QoS protocols to an NSIS protocol.

But indeed, there may be cases where a host initiates the global NSIS
signaling.

- it fixes a two-level hierarchy. However, more deeply nested hierarchies
are also possible. E.g. when some edge router pipes a per-flow aggregation
into a (possibly previously set-up) aggregate reservation. Note this idea
can even be extended by the next edge router piping the aggregates it
receives into "super- aggregates".

[MB] Agree, the number of hierarchy may be arbitrary although in most cases
two levels of hierarchy should be sufficient.

Cornelia:
When a QC initiates an aggregate reservation it is a QI! (or rather: the
logical QC instance on a particular node receives per flow signaling and
triggers (based on incoming micro-flows, but not because of a particular
microflow arrival, I agree) the logical QI instance on the same node to
initiate or modify an aggregate reservation.) This is also consistent with
the terminology definition you sent out after the NSIS meeting, where the
QC may trigger a QI to initiate another instance of the NSIS protocol

Another example of a more-than-two-level hierarchy: a QC initiates per-flow
e2e signaling. At the edge of some administrative domain a QC tunnels it to
the other edge of the domain and initiates local (domain-specific) NSIS
signaling, may be because a mapping of QoS parameters to local scope
parameters is necessary. Now this administrative domain consists of more
than one QoS domain, i.e. different QoS mechanisms are supported. At the
edge of each of these domains, local (non-NSIS) signaling mechanisms are
therefore initiated (e.g. RSVP, or no signaling, and instead DSCPs).

This last example may be a bitfar fetched... however I think we should
allow the protocol to be arbitrarily deeply nested, if only because it is
more general and we dont know what the future is going to bring. Besides I
dont see having an arbitrary number of levels would make the protocol more
complicated

- what about a scenario where no end host is involved, but a BB triggers an
edge router to set-up an aggregate reservation through a domain? The BB
would send this trigger because of some SLA agreement process rather than
because of the interpretation of per-flow reservations. I dont think this
would map to your framework either, because there is no reason for starting
with a local NSIS signaling that later is translated into global NSIS
signaling.

[MB] Indeed, the BB will trigger the setup of traffic trunks
(i.e.bandwidth pipes) due to the establishment of an SLA. How a BB
provisions SLSs is outside the scope of NSIS in my opinion. Some
local NSIS protocol may be involved but for sure this won't be
translated into a global NSIS protocol.

---

From: Kappler Cornelia <[email-masked]>
Date: Fri, 22 Mar 2002 20:00:01 +0100

Hi Maarten, 

So you agree our scenario is not general, because it assumes usage of a signaling proxy and fixes a two-level-only hierarchy??

Best regards, Cornelia

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, March 21, 2002 5:35 PM
> To:	Kappler Cornelia
> Cc:	[email-masked]; [email-masked]; [email-masked]; Hancock Robert
> Subject:	RE: [NSIS] RE: section on QI/QC and QI/QC terminology
> 
> Hi Cornelia,
> 
> are also possible. E.g. when some edge router pipes a per-flow aggregation>