Subject: RE: [NSIS] Two kinds of requirements

From: "Schneider, Marco" <[email-masked]>
Date: Tue, 22 Jan 2002 12:34:20 -0600

Georgios,

Are you suggesting that we organize our requirements according to the
implementation solution you have proposed below? If that is the case then I
strongly disagree. 

Marco
-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]]
Sent: Tuesday, January 22, 2002 3:39 AM
To: Schneider, Marco
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

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

---

From: David Partain <[email-masked]>
Date: Wed, 23 Jan 2002 11:30:13 +0100

Hi,

> implementation solution you have proposed below? If that is the case then I

I don't see Georgios' framework figure or the text above as an
"implementation solution".  It's simply a way of taking a _big_
problem and breaking it down into smaller problem areas that
need attention.

The requirements, in my view, must be based upon the
applications that will use the network ("use case based
requirements").  There seem to be several voices pushing
for this.

If you could, please help me understand exactly what you
disagree with.

Cheers,

dlp