Subject: [NSIS] interface model or QC/QI model

From: [email-masked]
Date: Thu, 28 Feb 2002 16:38:51 +0100

Hi all,

I have been thinking about the (many) discussions we have had about the
QC/QI model and what I will call the 'topological interfaces' model. Let me
try to give my take on this.
If we try to make a topological separation in the network we might come up
with:

                +-------------+             +-------------+
                |             |             |             |
+---+         +---+         +---+         +---+         +---+
| H |-------->| EN|-------->| EN|-------->| BN|-------->| BN|
+---+         +---+         +---+         +---+         +---+
                |access       |             |core         |
                +-------------+             +-------------+
host            edge node                   border node

Let's now look at how end-to-end QoS could be signalled in this network. We
deliberately made a distinction between end-to-end QoS signalling (item
(2)) and local QoS signaling (item(1)). Local QoS signaling may be used to
set up 'fat pipes' that can be used by the end-to-end flows.

(1) For the local QoS provisioning and signaling, the situation is fairly
obvious. For each section of the network, we have a local QI (LQI) a local
QoS terminator (LQT), and possibly local QCs (LQC, not shown for
simplicity). Existing local QoS provisioning and signaling solutions could
be reused here. Alternatively, the NSIS protocol could be used here as
well.

+---+    +---++---+         +---+         +---+         +---+
|LQI|--->|LQT||LQI|-------->|LQT|-------->|LQI|-------->|LQT|
+---+    +---++---+         +---+         +---+         +---+

If we try to address the end-to-end responsabilites of the different nodes,
we have three possibilities (note that this lines up with the
host-access-core picture above):

(2.a) host is QI

+---+  NSIS   +---+   NSIS  +---+   NSIS  +---+  NSIS   +---+
| QI|-------->| QC|-------->| QC|-------->| QC|-------->| QC|  end-to-end
+---+         +---+         +---+         +---+         +---+
+---+    +---++---+         +---+         +---+         +---+
|LQI|--->|LQT||LQI|-------->|LQT|-------->|LQI|-------->|LQT|  local
+---+    +---++---+         +---+         +---+         +---+

(2.b) QI before access network

              +---+  NSIS   +---+  NSIS   +---+  NSIS   +---+
              | QI|-------->| QC|-------->| QC|-------->| QC|  end-to-end
              +---+         +---+         +---+         +---+
+---+    +---++---+         +---+         +---+         +---+
|LQI|--->|LQT||LQI|-------->|LQT|-------->|LQI|-------->|LQT|  local
+---+    +---++---+         +---+         +---+         +---+

(2.c) QI before the core network

                            +---+  NSIS   +---+   NSIS  +---+
                            | QI|-------->| QC|-------->| QC|  end-to-end
                            +---+         +---+         +---+
+---+    +---++---+         +---+         +---+         +---+
|LQI|--->|LQT||LQI|-------->|LQT|-------->|LQI|-------->|LQT|  local
+---+    +---++---+         +---+         +---+         +---+

The path to the end-to-end QI is then supported by the local QoS
technologies only (which presupposes the possibility to have a mapiing
between them). It is interesting to note that the location of the logical
(end-to-end) QI-QC interface can map to different topological interfaces
(with different requirements). For instance, in case (2.b) the QI-QC
interface would need to support mobility, whereas in (2.c) it does not. The
conclusion from these pictures is that the split QC/QI is not sufficient in
order to separate NSIS signaling requirements. Note that the QC/QI does
have its merits (see below) and that it could be fixed if we introduce
additional entities (e.g. Proxy QI which relays QI info).

On the other hand, if we look at in-band/out-of-band signaling we can have
the following situations:

(3.a)
                +-------------+             +-------------+
                |             |             |             |
+---+         +---+         +---+         +---+         +---+
| QI|- - - - >| QC|- - - - >| QC|- - - - >| QC|- - - - >| QC|
+---+         +---+         +---+         +---+         +---+
+---+         +---+         +---+         +---+         +---+
| H |-------->| EN|-------->| EN|-------->| BN|-------->| BN|
+---+         +---+         +---+         +---+         +---+
                |access       |             |core         |
                +-------------+             +-------------+
host            edge node                   border node

(3.b)

+---+ - - - - - - - >+---+ - - - - - - - - - - ->+---+
| QI|           +----| QC|----+             +----| QC|----+
+---+           |    +---+    |             |    +---+    |
                |             |             |             |
+---+         +---+         +---+         +---+         +---+
| H |-------->| EN|-------->| EN|-------->| BN|-------->| BN|
+---+         +---+         +---+         +---+         +---+
                |access       |             |core         |
                +-------------+             +-------------+
host            edge node                   border node

This means that we can not necessarily identify a QC or QI with a
particular node on the data path. The QC/QI paradigm, however, is useful
when considering local provisioning actions because a QC (be it distributed
or not) will be responsible to manage the local QoS provisioning. This
means that the usefulness of the QC/QI might lie in the parameters that
need to be considered (for e.g. provisioning) in QC or QI.

In conclusion:
- We need to use topological considerations in order to group the NSIS
signaling requirements.
- QC/QI is a natural way to discuss parameters that need to be available
for provisioning.

We could exploit this by making a distinction between:
- protocol content requirements (per QC/QI)
- protocol signaling requirements (per topological interface)

This would already give a first grouping of requirements and it would also
be inline with the requirement to separate the protocol from 'the
information it carries'.

Regards,
Sven.

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