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

[Marcus Brunner <[e-mail]>]

Georgios,

see inline

--On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)" 
<[e-mail]> 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
>
>
>
>
> -----Original Message-----
> From: Marcus Brunner [mailto:[e-mail]]
> Sent: maandag 28 januari 2002 14:37
> To: Georgios Karagiannis (ELN)
> Cc: [e-mail]
> Subject: RE: Independence of signalling and data path (was RE: [NSIS]
> Two kindsof requirements)
>
>
> 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)"
> <[e-mail]> wrote:
>
>> 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|---------->|ehos
>>| t| -----|                      |-----|             |-----|
>>| |-----|
>>|     |                      |     |             |     |           | 
|
>>| -----|            |-----|   |-----|             |-----|
>>| |-----| 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:[e-mail]]
>> Sent: maandag 28 januari 2002 12:04
>> To: Georgios Karagiannis (ELN); '[e-mail]'
>> Cc: [e-mail]
>> 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)"
>> <[e-mail]> 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:[e-mail]]
>>> Sent: vrijdag 25 januari 2002 19:40
>>> To: [e-mail]
>>> Cc: Georgios Karagiannis (ELN); [e-mail]
>>> 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)" <[e-mail]> 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:[e-mail]]
>>>> > Sent: vrijdag 25 januari 2002 17:09
>>>> > To: Georgios Karagiannis (ELN); 'Schneider, Marco'
>>>> > Cc: [e-mail]
>>>> > 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)"  <[e-mail]> 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:[e-mail]]
>>>> >> Sent: dinsdag 22 januari 2002 1:03
>>>> >> To: 'Georgios Karagiannis (ELN)'; '[e-mail]'
>>>> >> Cc: [e-mail]
>>>> >> 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:[e-mail]]
>>>> >> Sent: Monday, January 21, 2002 4:30 AM
>>>> >> To: '[e-mail]'
>>>> >> Cc: [e-mail]
>>>> >> 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:[e-mail]]
>>>> >> Sent: 18 January 2002 20:10
>>>> >> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John
>>>> >> (NRC/Helsinki); [e-mail]; Yaron Kahana; Geib, Ruediger;
>>>> >> [e-mail]
>>>> >> Cc: [e-mail]
>>>> >> 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:[e-mail]]
>>>> >> Sent: Friday, January 18, 2002 9:18 AM
>>>> >> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>>>> >> [e-mail]; Yaron Kahana; Geib, Ruediger;
>>>> >> [e-mail]
>>>> >> Cc: [e-mail]
>>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>>> >>
>>>> >>
>>>> >> Defined below [RRR]
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: Schneider, Marco [mailto:[e-mail]]
>>>> >> Sent: Thursday, January 17, 2002 8:47 PM
>>>> >> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John
>>>> >> (NRC/Helsinki); [e-mail]; Yaron Kahana; Geib, Ruediger;
>>>> >> [e-mail]
>>>> >> Cc: [e-mail]
>>>> >> 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
>>>> >> [e-mail]
>>>> >> https://www1.ietf.org/mailman/listinfo/nsis
>>>> >>
>>>> >> _______________________________________________
>>>> >> nsis mailing list
>>>> >> [e-mail]
>>>> >> https://www1.ietf.org/mailman/listinfo/nsis
>>>> >>
>>>> >> _______________________________________________
>>>> >> nsis mailing list
>>>> >> [e-mail]
>>>> >> https://www1.ietf.org/mailman/listinfo/nsis
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --------------------------------------
>>>> > Dr. Marcus Brunner
>>>> > Network Laboratories
>>>> > NEC Europe Ltd.
>>>> >
>>>> > E-Mail: [e-mail]
>>>> > WWW:    http://www.ccrle.nec.de/
>>>> > personal home page: http://www.brubers.org/marcus
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > nsis mailing list
>>>> > [e-mail]
>>>> > https://www1.ietf.org/mailman/listinfo/nsis
>>>> >
>>>>
>>>> --------------------------------------
>>>> Dr. Marcus Brunner
>>>> Network Laboratories
>>>> NEC Europe Ltd.
>>>>
>>>> E-Mail: [e-mail]
>>>> WWW:    http://www.ccrle.nec.de/
>>>> personal home page: http://www.brubers.org/marcus
>>>>
>>>> _______________________________________________
>>>> nsis mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/nsis
>>>
>>
>>
>>
>> --------------------------------------
>> Dr. Marcus Brunner
>> Network Laboratories
>> NEC Europe Ltd.
>>
>> E-Mail: [e-mail]
>> WWW:    http://www.ccrle.nec.de/
>> personal home page: http://www.brubers.org/marcus
>>
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: [e-mail]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>



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

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



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