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 09:52:33 +0100

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

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

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 28 Jan 2002 12:04:29 +0100

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:

> Yeap. e.g., when BB is used signaling may be needed between BBs of
> adjacent  QoS domains.	
>
> Xiaoming
>
>>
>> Marcus
>>
>> > 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
>> >
>> >> 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
>> >> [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
>> >> process the [everyhop] component. Some of these scenarios are the
>> >> Radio Access
>> >> Network and Mobile IP,..
>> >> 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
>> >>
>> >>
>> >> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John
>> >> (NRC/Helsinki); [email-masked]; Yaron Kahana; Geib, Ruediger;
>> >> [email-masked]
>> >> Cc: [email-masked]
>> >> Below is the original text from your reponse to Gary Kenward.
>> >> Hopefully the context is clear.
>> >>
>> >> 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.
>> >>
>> >> necessary QOS agreed to at the session level. This is the protocol
>> >> that we need to work on.
>> >>
>> >> Can you please define what you mean by "End-to-End Application Layer
>> >> QOS Signaling". Thanks.
>> >>
>> >> [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
>> >>