Subject: RE: [NSIS] Two kinds of requirements

From: "Allen, Keith" <[email-masked]>
Date: Mon, 21 Jan 2002 13:07:16 -0600

All,

Along the lines of my earlier reference to Use Cases, what do you think
about beginning to document the requirements the protocol should meet as a
set of use cases describing how network users (or actually their network
devices) use the protocol-to-be to access the QoS capabilities of the
network.  For example, one use case could show a voice over IP caller,
another a network administrator setting up an Ethernet VPN, etc.  If the
protocol has to support mobile handoffs, we would have a use case showing
that.  It would give us a focal point instead of just e-mail.

Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
[email-masked]

 -----Original Message-----
From: 	Allen, Keith  
Sent:	Monday, January 21, 2002 11:37 AM
To:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Should the design of the protocol be driven by the needs of the user or the
currently implemented network?  If we choose the latter we will end up with
a protocol that will be obsolete when the next new network innovation takes
place, and it may not meet the basic needs of the subscriber.

The Object-Oriented software world has turned to user-centric requirements
(in the form of Use Cases) as the basis for analysis and design.  They are
getting good results with this process.  We should also focus on what the
user wants to do.  The user sends a request to the network, then he doesn't
care what the network has to do to meet it.  If it turns out that RSVP can't
meet the needs of the subscriber it will have to evolve or be replaced.
Unfortunately, though, we don't even know if RSVP will suffice because we
haven't captured what the user can do.

Form follows function.  The function of this protocol should be to enable
subscribers to utilize the guaranteed QoS capabilities of the network on
demand. 

Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
[email-masked]

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Monday, January 21, 2002 11:15 AM
To:	Chen, Weijing; [email-masked]
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Weijing,

I can understand your desire to concentrate on the user-network problem
space.

However - I am concerned that the result will be an agreed and working
solution
in this problem space that is then not supported at the network-network
interface
(interdomain in IP speak, NNI in PSTN jargon).

If the user-network interface is one protocol and then the next hop is RSVP
with intserv,
then the next is MPLS with LSP and so on, will you see anything at the far
and distant end
that looks anything like the original user-network request?

Dick

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 21 January 2002 16:20
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]'
Subject: RE: [NSIS] Two kinds of requirements

I am afraid that we are creating a Utopian solution here.

>>Therefore, the [everyhop] component should be supported by the NSIS
protocol.
>>However a "host" or a "edge" should be able to activated or not.

It is not question of who activate it. It is the question of who initiate
it. Who is going to stuff the [everyhop] component into signaling message?
Don't expect it from [end host].

>>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;
This should be our focus now.

>>edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;

Yes, a universal protocol used by different segments is very nice. But can
it be agreed on and implementable? The missing piece in today's protocol
soup is user-to-network signaling, sort of DTMF in data world. Let's solve
it first here in NSIS. Later on we can engage on a more ambition mission.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----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

_______________________________________________
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: Marcus Brunner <[email-masked]>
Date: Fri, 25 Jan 2002 17:01:31 +0100

Keith,

In http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt we 
have 4 different scenarios.
1) A user reqests QoS -> moves to a different access router (mobility 
scenario)
2) A user has a running session with defined QoS negotiated move the 
session to a different terminal (different IP address) (session mobility)
3) A access network provider requests QoS from a backbone provider (I think 
this what people call access to core signalling)
4) A backbone provider requests QoS from another backbone provider 
(inter-domain)

Is this what you mean by use cases? I have to admit that the simplest case 
(the one used before 1 and 2 can happen has been forgotten (the user 
requests QoS)

Marcus

--On Monday, January 21, 2002 1:07 PM -0600 "Allen, Keith" 
<[email-masked]> wrote:

> Should the design of the protocol be driven by the needs of the user or
> the currently implemented network?  If we choose the latter we will end
> up with a protocol that will be obsolete when the next new network
> innovation takes place, and it may not meet the basic needs of the
> subscriber.
>
> user wants to do.  The user sends a request to the network, then he
> doesn't care what the network has to do to meet it.  If it turns out that
> RSVP can't meet the needs of the subscriber it will have to evolve or be
> replaced. Unfortunately, though, we don't even know if RSVP will suffice
> because we haven't captured what the user can do.
>
> If the user-network interface is one protocol and then the next hop is
> RSVP with intserv,
> [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
> 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."
>
> 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.
>
> 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.
>
> video, and data. The use needs to express the needs of QOS for audio,
> video, and data to another user.
>

--------------------------------------
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