Subject: RE: Independence of signalling and data path (was RE: [NSIS] Two kindsof requirements)

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 28 Jan 2002 13:32:53 +0100

Hi Marcus

Please see my comments/remarks in line:

[MB]>> I am not sure, what exactly you mean by 
[MB]>> the "host to proxy" version of the 
[MB]>> protocol, but the main problem lies in mobil 
[MB]>> environments, where I currently see a problem.

Please let me explain how I see the QoS scenario
that you are thinking of by using the QoS framework that 
was proposed by me some time ago.

         NSIS protocol              NSIS protocol       NSIS protocol
         (host - host)               (host - host)      (host - host)
|-----|   (first-part)       |-----|(second-part)|-----|(third-part|-----|
|ehost|<-------------------->|ehost|<----------->|ehost|---------->|ehost|
|-----|                      |-----|             |-----|           |-----|
|     |                      |     |             |     |           |     |
|-----|            |-----|   |-----|             |-----|           |-----|
|eedge|            |eedge|   |eedge|             |eedge|           |eedge|
|-----|            |-----|   |-----|             |-----|           |-----|
|     |            |     |   |     |             |     |           |     |
|-----|   |----|   |-----|   |-----|   |----|    |-----|   |----|  |-----|
|ehop |   |ehop|   |ehop |   |ehop |   |ehop|    |ehop |   |ehop|  |ehop |
|-----|   |----|   |-----|   |-----|   |----|    |-----|   |----|  |-----|
end-host1 interior   edge      BB1      interior   BB2    interior end-host2
         w/in domain                   w/in domain       w/in domain

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

NSIS protocol (host - host): is a NSIS protocol version
that is:
  *  started at a host (could be an-end host or a 
     Bandwidth Broker (BB))
  * terminated at a host (could be an-end host or a 
     Bandwidth Broker (BB))

In the above figure the end to end QoS signaling solution 
is provided by three NSIS protocol parts.
  * the first-part is started at end-host1 and is 
    terminated at BB1 (Note that the end-host1 must know the 
    address of BB1); 
  * the second-part is started at BB1 and is terminated 
    at BB2(Note that the BB1 must know the 
    address of BB2);
  * the third part is started at BB2 and is terminated at
    end-host2 (Note that the BB2 must know the 
    address of endhost2);

For this scenario the NSIS protocol decomposition is as follows:

 * A "host" could be an end host or a Bandwidth Broker (BB).
   It can process and use the "everyhost", "everyedge", and "everyhop"
   protocol components. However, in this scenario (that uses BBs), 
   the "everyedge" and "everyhop" components may not be used. 
   Therefore the QoS framework 
   will look as depicted in figure above.

 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. However, in this scenario (that uses BBs), 
   the "everyedge" and "everyhop" components may not be 
   used (or checked), since they will 
   be  not set (e.g., empty). 
   The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component. However, in this scenario 
   (that uses BBs), "everyhop" component may not be 
   used (or checked), since it will 
   be not set (e.g., empty). The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward. 

PLEASE NOTE that in my opinion, this scenario is only useful 
when you will consider that:
* BB's or QoS controllers are used;
* the end-host should know the address of the first hop Bandwidth Broker;
* the BBs should be aware (know) the addresses of neighboring BBs;
* BB's or QoS controllers should be able to relate 
  the QoS signaling to the data path;

In general the above considerations are very difficult to 
fulfill. Please note that we need a NSIS protocol that can 
be applied in general. Of course your
scenario, but other types as well will be included.  

I think that the example explained above 
is providing a possible solution to your problem. 

[MB] What is in your opinion the problem of requiring 
[MB] independent signalling and data pathes?

First of all: I will just try to explain what this independence means.
It means that the NSIS signaling messages my follow a different path 
then the user data packets (associated to these NSIS signaling 
messages). 

Second:  the problem of this independence is that the NSIS protocol
in most of the cases is useless. 
Thus, for example, if the NSIS signaling messages will 
signal QoS information to an edge node, and the user 
data packets (associated to this QoS information)
will not pass through the same edge node, then 
the NSIS protocol in most of the cases is useless. 

Please note that when the signaling path is independent than 
the user data path, then the NSIS protocol will only be useful 
when:

* BB's or QoS controllers are used;
* the end-host should know the address of the first hop Bandwidth Broker;
* the BBs should be aware (know) the addresses of neighbouring BBs;
* BB's or QoS controllers should be able to relate 
  the QoS signalling to the data path;

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.
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);

Best regards,
Georgios

-----Original Message-----
From: Marcus Brunner [mailto:[email-masked]]
Sent: maandag 28 januari 2002 12:04
To: Georgios Karagiannis (ELN); [email-masked]'
Cc: [email-masked]
Subject: RE: Independence of signalling and data path (was RE: [NSIS]
Two kindsof requirements)

Georgios,

I am not sure, what exactly you mean by the "host to proxy" version of the 
protocol, but the main problem lies in mobil environments, where I 
currently see a problem.

What is in your opinion the problem of requiring independent signalling and 
data pathes?

Marcus

--On Monday, January 28, 2002 9:52 AM +0100 "Georgios Karagiannis (ELN)" 
<[email-masked]> wrote:

> Hi Xiaoming and Marcus
>
> If you would like to have a QoS communication between a
> QoS initiator and a QoS controller you could
> then use the "host to proxy" version of the NSIS protocol.
>
> You could then accomplish exactly the same functionality
> without requiring that the signaling path is independent from
> the data path.
>
> Best regards,
> Georgios
>
> -----Original Message-----
> From: Xiaoming Fu [mailto:[email-masked]]
> Sent: vrijdag 25 januari 2002 19:40
> To: [email-masked]
> Cc: Georgios Karagiannis (ELN); [email-masked]
> Subject: Re: Independence of signalling and data path (was RE: [NSIS]
> Two kindsof requirements)
>
>
> Marcus,
>
> Marcus Brunner wrote:
>>
>> I you want to see SIP in you can sure. But that was our intention.
>>
>> I  personally think, that the signalling path should not be bound to the
>> data path. Whether you need to know the location of the QoS controller
>> heavility depends on the specific protocols defined (and might be regard
>> implementation dependent)
>
> Yeap. e.g., when BB is used signaling may be needed between BBs of
> adjacent  QoS domains.	
>
> Xiaoming
>
>>
>> Marcus
>>
>> --On Friday, January 25, 2002 5:04 PM +0100 "Georgios Karagiannis (ELN)"
>> <[email-masked]> wrote:
>>
>> > Hi Marcus
>> >
>> > yes, but from what I understood from your draft
>> > you assume that the QoS initiator will have to know the
>> > location of the QoS controller and that the
>> > signaling path may follow a different path than
>> > the user data. It seems SIP to me.
>> >
>> > Best Regards,
>> > Georgios
>> >
>> >
>> > -----Original Message-----
>> > From: Marcus Brunner [mailto:[email-masked]]
>> > Sent: vrijdag 25 januari 2002 17:09
>> > To: Georgios Karagiannis (ELN); 'Schneider, Marco'
>> > Cc: [email-masked]
>> > Subject: RE: [NSIS] Two kinds of requirements
>> >
>> >
>> > Looks nice for fixed network. However, as soon as mobility is involved
>> > it gets more difficult. That was the reason that in our framewrok we
>> > talk about QoS initiator and QoS controller, instead of teh
>> > componenets where the componenets are sitting (which we find not
>> > really relevant)
>> >
>> > Marcus
>> >
>> > --On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis
>> > (ELN)"  <[email-masked]> wrote:
>> >
>> >> Hi Marco
>> >>
>> >> The possible NSIS protocol components that can be
>> >> used on the different NSIS protocol types are the following:
>> >>
>> >>  * used components in "end host to end host" NSIS scenario:
>> >>       [everyhost], [everyedge], [everyhop]
>> >>
>> >>  * used components in "end host to proxy" NSIS scenario:
>> >>       [everyhost], [everyedge], [everyhop]
>> >>
>> >>  * used components in "end host to edge" NSIS scenario:
>> >>       [everyedge], [everyhop]
>> >>
>> >>  * used components in "edge to edge" NSIS scenario:
>> >>       [everyedge], [everyhop]
>> >>
>> >> Regarding the priority, we should decide it after the requirements,
>> >> architecture and framework drafts are done!
>> >>
>> >> Best regards,
>> >> Georgios
>> >>
>> >> -----Original Message-----
>> >> From: Schneider, Marco [mailto:[email-masked]]
>> >> Sent: dinsdag 22 januari 2002 1:03
>> >> To: 'Georgios Karagiannis (ELN)'; [email-masked]'
>> >> Cc: [email-masked]
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Hi Georgios, All
>> >>
>> >> If by x -- y you mean a protocol that runs directly between x and y
>> >> (e.g. end host -- end host, end host -- proxy...) then strictly
>> >> speaking we are discussing four  functionally distinct interfaces and
>> >> thus four functionally distinct protocols(possibly three if we group
>> >> end host -- proxy and  end host -- edge together). In my opinion:
>> >> First we need to decide which of these interfaces are in scope.
>> >> Second we need to decide which one(s) we will address first. Third we
>> >> need to define the requirements for each for each of the interfaces
>> >> independently.
>> >>
>> >> With respect to scope and priority, I think we need to address in
>> >> order: 1) end host -- edge/proxy
>> >> 2) domain edge -- domain edge
>> >>
>> >>
>> >> Marco
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Georgios Karagiannis (ELN)
>> >> [mailto:[email-masked]]
>> >> Sent: Monday, January 21, 2002 4:30 AM
>> >> To: [email-masked]'
>> >> Cc: [email-masked]
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >>
>> >> Hi Dick
>> >>
>> >> Please see my comment in line:
>> >> [DK]>> I do agree that it need not be processed on a per hop basis as
>> >> it can [DK]>> transverse a domain with a single QoS mechanism. That
>> >> mechanism, be it
>> >> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning,
>> >> takes care of
>> >> [DK]>> the policing and the "path" establishment within the domain.
>> >>
>> >> Please note that at the moment there are scenarios that will need to
>> >> process the [everyhop] component. Some of these scenarios are the
>> >> Radio Access
>> >> Network and Mobile IP,..
>> >> Therefore, the [everyhop] component should be supported by the NSIS
>> >> protocol.
>> >> However a "host" or a "edge" should be able to activated or not.
>> >>
>> >> Furthermore, in my opinion the NSIS protocol should be:
>> >> end host - end host: the NSIS protocol is terminated at end hosts;
>> >> end host - proxy: the NSIS protocol is terminated at end host and
>> >> proxy; end host - edge: the NSIS protocol is terminated at end end
>> >> host and edge; edge - edge: the NSIS protocol is terminated at egdes
>> >> of one/multiple domains;
>> >>
>> >>
>> >> Best regards,
>> >> Georgios
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Schneider, Marco [mailto:[email-masked]]
>> >> Sent: 18 January 2002 20:10
>> >> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John
>> >> (NRC/Helsinki); [email-masked]; Yaron Kahana; Geib, Ruediger;
>> >> [email-masked]
>> >> Cc: [email-masked]
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Hi Roy,
>> >>
>> >> Below is the original text from your reponse to Gary Kenward.
>> >> Hopefully the context is clear.
>> >>
>> >> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>> >> application (e.g., SIP-based VoIP) that the user likes to express (as
>> >> opposed to "service"). Similarly, instead of network services, we
>> >> would say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We
>> >> would develop the end-to-end (application layer) QOS signaling
>> >> protocol (say, NSIS QOS). Now, there needs to have some kinds of
>> >> standards how NSIS QOS will be mapped over RSVP, DiffServ, MPLS, etc."
>> >>
>> >> So by End-to-End you mean between directly between two "users". This
>> >> is session level signaling and I don't believe the signaling part is
>> >> within the scope of this working group. An application level QOS
>> >> specification may be.
>> >>
>> >> After a session level agreement on QOS, the host/client/customer will
>> >> need to signal an actual reservation request to the network for the
>> >> necessary QOS agreed to at the session level. This is the protocol
>> >> that we need to work on.
>> >>
>> >> This approach is discussed in the SIP draft "SIP Extensions for Media
>> >> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>> >> "Framework for session set-up with media authorization"
>> >> (draft-ietf-rap-session-auth-02.txt).
>> >>
>> >> Marco Schneider
>> >>
>> >> -----Original Message-----
>> >> From: Roy, Radhika R, ALASO [mailto:[email-masked]]
>> >> Sent: Friday, January 18, 2002 9:18 AM
>> >> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>> >> [email-masked]; Yaron Kahana; Geib, Ruediger;
>> >> [email-masked]
>> >> Cc: [email-masked]
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Defined below [RRR]
>> >>
>> >> -----Original Message-----
>> >> From: Schneider, Marco [mailto:[email-masked]]
>> >> Sent: Thursday, January 17, 2002 8:47 PM
>> >> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>> >> [email-masked]; Yaron Kahana; Geib, Ruediger;
>> >> [email-masked]
>> >> Cc: [email-masked]
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Hi Roy,
>> >>
>> >> Can you please define what you mean by "End-to-End Application Layer
>> >> QOS Signaling". Thanks.
>> >>
>> >> [RRR] Suppose an user is initiation a SIP call to another user with
>> >> audio, video, and data. The use needs to express the needs of QOS for
>> >> audio, video, and data to another user.
>> >>
>> >> [RRR] The signaling mechanism that allows to express the QOS
>> >> parameters of audio, video, and data is termed as the "End-to-End
>> >> Application Layer QOS Signaling."
>> >>
>> >> Marco Schneider
>> >>
>> >> _______________________________________________
>> >> nsis mailing list
>> >> [email-masked]
>> >> https://www1.ietf.org/mailman/listinfo/nsis
>> >>
>> >> _______________________________________________
>> >> nsis mailing list
>> >> [email-masked]
>> >> https://www1.ietf.org/mailman/listinfo/nsis
>> >>
>> >> _______________________________________________
>> >> nsis mailing list
>> >> [email-masked]
>> >> https://www1.ietf.org/mailman/listinfo/nsis
>> >>
>> >
>> >
>> >
>> > --------------------------------------
>> > Dr. Marcus Brunner
>> > Network Laboratories
>> > NEC Europe Ltd.
>> >
>> > E-Mail: [email-masked]
>> > WWW:    http://www.ccrle.nec.de/
>> > personal home page: http://www.brubers.org/marcus
>> >
>> >
>> > _______________________________________________
>> > nsis mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/nsis
>> >
>>
>> --------------------------------------
>> Dr. Marcus Brunner
>> Network Laboratories
>> NEC Europe Ltd.
>>
>> E-Mail: [email-masked]
>> WWW:    http://www.ccrle.nec.de/
>> personal home page: http://www.brubers.org/marcus
>>
>> _______________________________________________
>> nsis mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/nsis
>

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

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

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 28 Jan 2002 14:36:55 +0100

Georgios,

So, I think you much in line with that req. The protocol from host to BB 
does not depend on the data path completly. What the constrain for the 
communication are is a different question. And whether, the protocol work 
between ehost, eedge, ehop, all of them can be controllers and initiators 
on the other side. So they do not require data and signalling on the same 
path.

Marcus

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

>| -----|   (first-part)       |-----|(second-part)|-----|(third-part|-----|
>| ehost|<-------------------->|ehost|<----------->|ehost|---------->|ehost|
>| -----|                      |-----|             |-----|           |-----|
>|     |                      |     |             |     |           |     |
>| -----|            |-----|   |-----|             |-----|           |-----|
>| eedge|            |eedge|   |eedge|             |eedge|           |eedge|
>| -----|            |-----|   |-----|             |-----|           |-----|
>|     |            |     |   |     |             |     |           |     |
>| -----|   |----|   |-----|   |-----|   |----|    |-----|   |----|  |-----|
>| ehop |   |ehop|   |ehop |   |ehop |   |ehop|    |ehop |   |ehop|  |ehop |
>| -----|   |----|   |-----|   |-----|   |----|    |-----|   |----|  |-----|
> end-host1 interior   edge      BB1      interior   BB2    interior
> end-host2          w/in domain                   w/in domain       w/in
> domain
>
>    ehost = everyhost
>    eedge = everyedge
>    ehop  = everyhop
>
> I am not sure, what exactly you mean by the "host to proxy" version of
> the  protocol, but the main problem lies in mobil environments, where I
> currently see a problem.
>
> What is in your opinion the problem of requiring independent signalling
> and  data pathes?
>
> Marcus
>
>>> >> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John