Subject: [NSIS] proposals related to NSIS WG draft

From: "Sven Van den Bosch" <[email-masked]>
Date: Tue, 19 Mar 2002 23:43:32 +0100

Hi all,

As an outcome of this morning's NSIS meeting, we propose the following 
detailed additions to the WG draft.

1. Terminology

- QoS Controller: Network entity responsible for interpreting and 
implementing the signaled QoS in the network. Failure to do so implies an 
admission control decision. It can only be triggered by another NSIS entity 
of the same instance (a QoS Initiator or another QoS Controller).

- QoS Receiver: Network entity, located at the edge of or inside a QoS 
domain, responsible for terminating an instance of an NSIS protocol. It has 
the additional functionality that it may initiate an acknowledgment towards 
the QI and that it may trigger another NSIS entity (QoS Initiator or QoS 
Controller of another instance of the NSIS protocol)

- QoS Initiator: Network entity, located at the edge of or inside a QoS 
domain, responsible for initiating an instance of an NSIS QoS signaling 
protocol. It may be triggered by the application layer, by the termination 
of a local QoS signaling mechanism (possibly another instance of NSIS 
signaling) or by a QoS Controller of another of a client instance of an NSIS 
protocol. It provides a mapping between the QoS parameters contained in the 
trigger and the QoS parameters in the instance of the NSIS protocol for 
which is serves as QoS Initiator.

2. Use cases/scenarios: 2 are available from the draft-buchli (sections 4.1 
and 4.2)

3. Requirements

* New requirements
- in section MUST support priority
The priority of a flow is essentially decoupled from its QoS requirements. 
Therefore the protocol MUST support priority. As a consequence, it MUST 
support preemption of traffic flows in case of congestion or failure. A 
preemption action MAY trigger an attempt to resetup the request by means of 
another instance of an NSIS signaling protocol.

- in section 5.3: MAY support grouping of microflows (possibly only for 
feedback)
As a consequence of the optimization for the interactive multimedia 
services, the signaling should allow one unique request for several micro 
flows having the same origination and destination IP addresses. This is 
usually the case for multimedia SIP calls where the voice and video micro 
flows follow the same path. This grouping of requests allows optimization of 
the QoS processing. Note that this may be detrimental for the call setup 
time. The use of grouping for microflows may be restricted to teardown 
and/or notification messages when call setup time is a concern.

- in section 5.5: Protocol content
The per-flow QoS requests are mapped onto the bandwidth pipe, which is 
specified by an SLS. These pipes may provide statistical guarantees such as 
delay and packet loss bounds (depending on the QoS class). In order to 
invoke per-flow QoS services the only parameter needed is a required rate, a 
means to identify the data path (mapping on SLS) and eventually a 
reservation identifier.

1) Microflow/reservation description
The signaling should allow the request to describe the microflow whose QoS 
would be guaranteed by giving at least the source and destination IP 
addresses of the media flow. In case the QC is stateful (per microflow) 
there may be a need to include a unique reservation identifier (e.g. QI 
identifier+counter) such that in case of e.g. a tear down message the 
reservation can be easily identified in the QC.

2) Traffic descriptor
The required peak rate must be signaled. Optionally the traffic parameters 
may be expressed in terms of token bucket parameters (similar to the TSpec 
in RSVP).

- in section 5.10: Interworking with provisioning

* Requirements for which to change priority or formulation
- MUST support signalling to entities outside the data path (reformulation)

- MUST NOT be adversely impacted by mobility aspects (applicable for 
end-to-end)
A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT be 
adversely affected by mobility issues. Any mobility scenario should be 
tackled by other uses of an NSIS protocol and is outside the realm of an 
end-to-end application of the NSIS protocol.

_________________________________________________________________
Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp.

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

---

From: Kappler Cornelia <[email-masked]>
Date: Wed, 20 Mar 2002 18:57:43 +0100

Hi Sven, 

some inline comments on the new definitions / Reqs (which in general I like)

Cornelia

> -----Original Message-----
> From:	Sven Van den Bosch [SMTP:[email-masked]]
> Sent:	Tuesday, March 19, 2002 11:44 PM
> To:	[email-masked]
> Subject:	[NSIS] proposals related to NSIS WG draft
> 
> Hi all,
> 
	"instance": NSIS protocol instance? One should probably also provide the definition of NSIS protocol instance.

> Controller of another instance of the NSIS protocol)
	why would it trigger a QC?

> which is serves as QoS Initiator.
	what is a "client instance of an NSIS protocol"?

> means to identify the data path (mapping on SLS) and eventually a 
	- "per-flow QoS requests _may be_ mapped onto ..."?
	- "rate" = bandwidth?

> would be guaranteed by giving at least the source and destination IP > 
> addresses of the media flow. In case the QC is stateful (per microflow) > 
	what is "other uses of an NSIS protocol"? What is an "e2e app of the NSIS protocol" (I understand this looking at the figures you provided in a recent email, however they are not part of the Req doc)Does this imply NSIS is not supporting mobility? Or: it MUST be possible to support mobility locally, without invoking e2e NSIS signaling?

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Wed, 20 Mar 2002 19:24:46 -0500

My comments inline. 
Ilya
From: "Sven Van den Bosch" <[email-masked]>
To: [email-masked]
Date: Tue, 19 Mar 2002 23:43:32 +0100
Subject: [NSIS] proposals related to NSIS WG draft

Hi all,

1. Terminology

[IF>>] The following statement should be added to this set of definitions:
QI, QC and QR can be located within the same or different QoS [sub]domains. 
Otherwise the case of two QoS [sub]domains (different QoS technology) with
centralized Bandwidth Brokers communicating directly to each other is not
covered.

3. Requirements

* New requirements

[IF>>] It seems to me that max packet size can be as important criteria for
decision to accept or reject a microflow into the pipe as rate.

2) Traffic descriptor

[IF>>] I strongly support it!

---

From: "Sven Van den Bosch" <[email-masked]>
Date: Thu, 21 Mar 2002 16:26:32 +0100

Cornelia,

I have some comments inline.

>From: Kappler Cornelia <[email-masked]>
>To: "'Sven Van den Bosch'" <[email-masked]>, [email-masked]
>Subject: RE: [NSIS] proposals related to NSIS WG draft
>Date: Wed, 20 Mar 2002 18:57:43 +0100
>
>Hi Sven,
>

I see an NSIS protocol instance as a flow of NSIS messages staring at a QI 
and ending at a QR while passing through zero or more QCs.

>	why would it trigger a QC?
The scenario here would be: the QC triggers, upon receiving an NSIS message, 
an instance of NSIS at a QI. Signalling then propagates at the lower NSIS 
layer to a QR which would hand over control back to the QC. In that case 
there would be a client-server relationship between the two instances of 
NSIS.
>	what is a "client instance of an NSIS protocol"?
See the scenario above.
>	- "per-flow QoS requests _may be_ mapped onto ..."?
OK, I agree on this one. It is possible that they do not need to be mapped. 
Rate indeed equals BW.
>	what is "other uses of an NSIS protocol"? What is an "e2e app of the NSIS 
>protocol" (I understand this looking at the figures you provided in a 
>recent email, however they are not part of the Req doc)Does this imply NSIS 
>is not supporting mobility? Or: it MUST be possible to support mobility 
>locally, without invoking e2e NSIS signaling?

There may be some confusion here. We have identified three potential network 
parts where NSIS may be applicable: the host-to-first-hop, the access and 
edge-to-edge (covering core, interdomain). Clearly there are different 
requirements in each part. In the access and first-hop mobility will have to 
be supported. Edge-to-edge it must not be supported. We are going to try to 
put this in the requirements by providing the MUST, SHOULD, MAY tables per 
network part where they apply. We don't exclude that there will be one NSIS 
protocol (in which case it needs to be modular) but it is likely that there 
can be more. Hence, other uses of an NSIS protocol.
The question about layering has come up in our discussions too and I think 
we ahve agreed to put the picture in my mail into the requirements document 
for some clarification on this.

Do you think this is a good idea?

Thanks for your comments,
Sven.

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

---

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

Hi Sven,

Comments inline

> and ending at a QR while passing through zero or more QCs.
	Is this definition unique? Is it always possible to identify "a flow of NSIS messages"? I.e. are there no bifurcations or aggregations of NSIS messages? What about multicast reservations? What about when a message is altered by addition or deletion of objects (e.g. domain specific information) - is this still the same protocol instance? May be we should add: "...which all carry the same reservation identifier"?

	(I am not up to date on the current terminology regarding reservation identifiers)

	Does everybody agree such a definition should be added to the terminology section?

> there would be a client-server relationship between the two instances of 
	Lets call the triggering QC "QC1" and the QC being handed control from the QR "QC2".
	Is there any relation at all between the QR and QC2? Wouldnt the "triggering instance" of NSIS just tunnel between QC1 and QC2 (i.e. QC1 addresses QC2 directly)?

	A scenario in which such a triggering takes place would be e.g. per-flow NSIS signaling being tunneled through an aggregation region, or "generic NSIS signaling" being replaced inside one (QoS) domain by another instance of NSIS signaling (another NSIS protocol, or same protocol with different QoS information), particulary suited to the needs of this domain. In both cases I see the original NSIS protocol instance being tunneled rather than "switched back on" by the QR trigger (there may also be a timing problem unless the "triggering instance" is piggybacked on the "triggered instance"). 

	Well, the my reasoning above implies QC1 knows QC2. In RSVP for Aggregates this is the case. I dont know about the general case?

> >	what is a "client instance of an NSIS protocol"?
	I'm not sure about the implications of defining client / server instances? Doesnt this map to a two-level-hierarchy-only signaling model?

	In any event, if we stick to this, the term should be defined, too.

> > > - MUST NOT be adversely impacted by mobility aspects (applicable for> 
> > > end-to-end)
	A table with MUST / SHOULD / MAY per network part is a good idea, including the figure, too (as long as it is clear we dont exclude a more-than-two-level signaling hierarchy ;-). However, I unfortunately still dont get the meaning of "other uses". May be you could reformulate the requirement using another term?

	Cornelia

---

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

> > > > domain, responsible for terminating an instance of an NSIS protocol. Ithas
>      Is there any relation at all between the QR and QC2? Wouldnt the
> "triggering instance" of NSIS just tunnel between QC1 and QC2 (i.e. QC1
> addresses QC2 directly)?
> 
>      A scenario in which such a triggering takes place would be e.g.
> per-flow NSIS signaling being tunneled through an aggregation region, or
> "generic NSIS signaling" being replaced inside one (QoS) domain by another
> instance of NSIS signaling (another NSIS protocol, or same protocol with
> different QoS information), particulary suited to the needs of this domain.
> In both cases I see the original NSIS protocol instance being tunneled
> rather than "switched back on" by the QR trigger (there may also be a
> timing problem unless the "triggering instance" is piggybacked on the
> "triggered instance").
> 
>      Well, the my reasoning above implies QC1 knows QC2. In RSVP for
> Aggregates this is the case. I dont know about the general case?
> 
> Sven>> Q1 could be the same as Q2 (potentially even outside the data path)
> and it could wait for confirmation that a pipe has been set up before
> proceeding with the setup.
> 
	Cornelia:
	I see your point. 

> > > > A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT
> > >be adversely affected by mobility issues. Any mobility scenario should be
>      A table with MUST / SHOULD / MAY per network part is a good idea,
> including the figure, too (as long as it is clear we dont exclude a> 
> more-than-two-level signaling hierarchy ;-). However, I unfortunately still
> dont get the meaning of "other uses". May be you could reformulate the
> requirement using another term?
> 
> Sven>> Assuming that the NSIS protocol is edge-to-edge, the other uses are
> local applications of an NSIS protocol, e.g. in the access or locally in
> the core (as opposed to edge-to-edge).
> 
>   Cornelia:
	OK. While I think in principle this makes sense, in practice this might run into problems because it seems to assume a particular network structure: Wouldnt it be difficult to define exactly what is edge-to-edge? Obviously it excludes an access network. What about a mobile network without an access network (may not exist but this is conceivable, isnt it?)

	Or: what about the mobile node uses a proxy (probably located in the access network, but not necessarily). At handoff, the proxy might change, so the signaling originating from the proxy would have to deal with mobility.

	Cornelia