Subject: [NSIS] RE: Independence of signalling and data path

From: "Freytsis, Ilya" <[email-masked]>
Date: Tue, 29 Jan 2002 12:45:26 -0500

Marcus, 

Let me add my 2cents into this discussion:

It looks to me that this discussion got very heated because it is at the
very border between general QoS signaling and specific QoS technology in use
(by the domain). The fact that you mentioned such terms as "Controller" and
"BB" indicates to me that you have a particular technology in mind that
based on this kind of entities. Tell me how the node at the edge of the RSVP
or DiffServe domain can get such an idea as a BB that governs the
neighboring domain. On the other hand the framework advocated by Georgios
somewhat implies the use of the hop-by-hop QoS technology (and probably for
this reason is opposed by some people including myself) that relies on
signaling and data path being the same.
The way to resolve this conflict in my mind is something along the following
lines:
1. The general NSIS signaling being used between the host and the edge and
between the edges of the neighboring domains (based on different QoS
technology) should follow the same path as data (or lay out the path for the
data if you wish).
2. It is up to the edge nodes that understand used within domain QoS
technology to communicate to the BB or controller and translate NSIS generic
signaling into something specific for this domain. Obviously the generic
NSIS signaling has to be recreated at the domain egress edge.
3. In this scenario the host can be enabled with the particular QoS
technology and use specific signaling for communication with the first
domain or can use generic NSIS signaling.
4. The communication between neighboring domains using the same QoS
technology can be done in the specific for the technology fashion though
translation to NSIS and back will be always available if for whatever reason
those domains prefer it.

In other words I am suggesting the following global analogy: 
If you view the domain with a QoS technology as a virtual router than NSIS
signaling used between those routers follows the same path as data. What
happens within the router is not a NSIS business.

Ilya Freytsis

Date: Tue, 29 Jan 2002 11:36:05 +0100
From: Marcus Brunner <[email-masked]>
Reply-To: [email-masked]
To: "Georgios Karagiannis (ELN)" <[email-masked]>
Cc: [email-masked]
n.se>
Subject: [NSIS] RE: Independence of signalling and data path (was RE: [NSIS]
Two			kindsof  requirements)

Georgios,

see inline

--On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)" 
<[email-masked]> wrote:

> Hi Marcus
>
>
> [MB]>> So, I think you much in line with that req. The protocol
> [MB]>> from host to BB does not depend on the data path
> [MB}>> completly. What the constrain for the
> [MB]>> communication are is a different question.
>
> I will repeat what was already said in my previous e-mail:
>
> This is only true when the following CONSIDEARTIONS are
> fulfilled:
>
> * BB's or QoS controllers are used;

-> QoS controllers are no BBs in our understanding, the hop by hop 
signalling is a special case, where each hop has a QoS controller and QoS 
initiator functionality runing.

> * the end-host should know the address of the first hop Bandwidth Broker;

An end-host needs to know quite a bit of servers/nodes anyway. I even think 
there are solutions (e.g. AAA servers), where the first hop router is 
forwarding the signalling messages to the right place.

> * the BBs should be aware (know) the addresses of neighboring BBs;

Sure, you need interdoamin routing anyway.

> * BB's or QoS controllers should be able to relate
>    the QoS signaling to the data path;
>

yes true, I think this is the core functionality of a signalling protocol. 
Only depends on the information available in the signaling message.

>
>  In GENERAL the above CONSIDERATIONS are very difficult to
>  fulfill. Please note that we need a NSIS protocol that can
>  be applied for GENERAL cases. Of course YOUR
>  SCENARIO, but OTHER TYPES as well will be INCLUDED.
>

IMO, with the QoS initator and QoS controller framework we excaclty target 
a more general case then the hop-by-hop signalling.

> Thus, in GENERAL the path followed by signaling
> messages and the path followed by user data packets (associated
> to these signaling messages) MUST BE THE SAME!!
>

No, I do not agree.

>
> Solution on how signaling messages and user data
> packets can follow the same path:
> The signaling messages will
> follow the same path as the user data packets when for example,
> the IP destination address of the signaling messages is the same
> as the IP destination address of the user data packets.

Not necessarly (but normally packet with the same destination likely take 
the same path)

> Typical IP routing protocols will route both signaling messages
> and user data packets that have the same IP destination address through
> the same path. RSVPv1 uses something similar (on the PATH messages
> and user data packets having the same flow ID);
>
> [MB]>> And whether, the
> [MB]>> protocol work
> [MB]>> between ehost, eedge, ehop, all of them can be controllers
> [MB]>> and initiators
> [MB] on the other side. So they do not require data and signalling
> [MB] on the same path.
>
> What do you mean, would you like to have a NSIS protocol version
> that starts at one hop router and terminates at the next first hop router.
> This protocol will be very slow, very complex, and in my opinion
> not useful!
>

You have to be more specific on slow and complex.
If you mean with slow the signalling delay (I think you are better of not 
performing some actions in each hop)

The complextity in terms CPU heavily depends on the complexity of the state 
machine, which defionitly not defined yet. But you are definitly right, 
that it needs to be simple.

Marcus

> Best regards,
> Georgios

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

---

From: Paulo Mendes <[email-masked]>
Date: Tue, 29 Jan 2002 17:14:10 -0500

Hello

Well.. This seems more clear to me, but I still have some doubts :).

So, does this means that NSIS only needs two versions: host-edge and 
edge-edge? And that the hop-hop inside each domain is a concern of each 
network provider and not NSIS?

If I understood correctly resources management entities inside each 
domain (BB or other) don't need a host-host NSIS *version* to 
communicate, being the inter-domain communication made by the edge-edge 
NSIS *version*. Is this right?

Cheers
Paulo

-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes