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

From: Kappler Cornelia <[email-masked]>
Date: Tue, 26 Mar 2002 14:37:39 +0100

Hi Roland, 

> -----Original Message-----
> From:	Roland Bless [SMTP:[email-masked]]
> Sent:	Monday, March 25, 2002 5:07 PM
> To:	Kappler Cornelia
> Cc:	[email-masked]'; [email-masked]; [email-masked]
> Subject:	Re: [NSIS] text on layering - original mail 
> 
> Hi Cornelia,
> 
> > I think the simplest way to include "starting of an aggregate
> > reservation" is viewing the (logical) entity starting this aggregate as
> > a QI. Note the "logical". I'm not proposing additional functionality in
> 
> Surely, one can see it as a logical QI, but this is although 
> generally true for QC <-> QC dialogues. I think we need a 
> clearer definition here (what if the QoS receiver QR is the initiator?),
> etc. I see an nsis protocol as a two-party protocol between two 
> entities. The QI,QC,QR terminology tries to catch the different roles
> of the parties for concatenated dialogues between those entities.
> I'm not sure whether we currently catch all possible cases here.
> 
	I'm not quite sure what you're getting at. Do you view one instance of NSIS signaling as always only between two parties, i.e. at each QC one instance is terminated, and a new instance is originated to talk to the next-hop QC? This is not how I (and I would assume most other people) see it. Rather an NSIS instance is always originated a QI, and always terminated at a QR. If a node terminates a NSIS instance (acting as a QR) there are no problems for the same node to also intitiate an NSIS instance (acting as a QI). For example - ... (thinking...) -  when this node is located at the edge of a mobile access network, and it wishes to employ a different NSIS protocol in the access e.g. to cover mobility.

	I think the definitions Sven sent out the other day are rather clear. Could you send concrete examples of cases that are not covered?

> > an aggregating router.
>                  ^^^^^^
> Who says that a QC must be a router?
> 
	Of course not, you're right. (but this doesnt change my point)

	Cornelia

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

---

From: Roland Bless <[email-masked]>
Date: Wed, 27 Mar 2002 13:02:15 +0100

Hi Cornelia,

> 	I'm not quite sure what you're getting at. Do you view one instance
> of NSIS signaling as always only between two parties, i.e. at each QC
> one instance is terminated, and a new instance is originated to talk to

I fear we run in terminology trouble here: I'm not sure what you mean 
by "instance" and "terminate". Maybe we mean the same, so let me 
explain my view (although we want to get rid of the QI/QC model in
the requirements):

- A QI requests a reservation from its QC and it will get (later on) 
  a response to this request from the same QC. I call this a
  "signaling transaction" because the request and the response
  relate to the same reservation. An nsis protocol will define
  exact rules for this dialogue between QI and QC (thus two-party
  protocol).

- When a QC receives a request from a QI, various things
  can happen, among which are:
  a) it can start a domain-internal signaling for local QoS provisioning,
     this may involve edge-to-edge signaling where other QCs are
     involved. In this case another QC (egress edge) may continue 
     the signaling.
  b) it signals another QC in the next domain along the path 
     (note, that this may be the adjacent QC or an aggregate endpoint, 
     thus a "logically" adjacent QC). The original request is usually 
     modified by the QC.

- A QC receives a request from a QC (also an nsis protocol). This QC may 
  forward the request further if the QR is not "the next hop". 
  If the QR is the next entity to be asked, the QC send a request towards
  the QR, or, the QC acts on behalf of the QR as a proxy, and, e.g. performs
  admission control for the QR according to a predefined policy.

- Due to asymmetric paths it may be required that a QR signals the sender
  to act as a QI. Thus, it will get also the response from the sender.

To summarize:
- A QI just requests a reservation from its QC. How the QC manages
  to allocate resources along the path to the QR (within its own domain
  and along other domains) is usually not of interest for the QI and
  should be transparent.
- We have a hop-by-hop (logical hops) signaling protocol which is
  in some sense "terminated" at each hop, because usually new
  request messages are created at each nsis hop. Surely, these
  request messages are logically related to each other, because
  they are related to the same reservation.
- nsis should allow logical end-to-end signaling in the sense that
  a QR is usually also involved in the overall signaling procedure
  (except when a proxy is used instead).

> the next-hop QC? This is not how I (and I would assume most other
> people) see it. Rather an NSIS instance is always originated a QI, and
> always terminated at a QR. If a node terminates a NSIS instance (acting
> as a QR) there are no problems for the same node to also intitiate an
> NSIS instance (acting as a QI). For example - ... (thinking...) -  when
> this node is located at the edge of a mobile access network, and it
> wishes to employ a different NSIS protocol in the access e.g. to cover
> mobility.

I don't get your point here. I find the above described model rather 
flexible and fitting well into the nsis charter.

> 	I think the definitions Sven sent out the other day are rather clear.
>  Could you send concrete examples of cases that are not covered?

Consider receiver initiated unicast resource reservations:
a "QR" acts as a QI to contact the sender which then acts as a QI.
This is possible, but currently a little bit confusing, when we 
say that a QI may be triggered by a QR etc.
In this case we may have:
Receiver (QI) -> Sender (QR)
Sender (QI) -> QC ... -> Receiver (QR)

> 	Of course not, you're right. (but this doesnt change my point)

Regards,
 Roland