Subject: RE: [NSIS] Two kinds of requirements

From: "Allen, Keith" <[email-masked]>
Date: Fri, 25 Jan 2002 10:12:55 -0600

Marcus wrote:

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

Marcus,

Use Cases are a technique used to gather and document requirements.  Using
this technique, the requirements for a system are documented as a set of use
cases which describe the ways in which all the different users of a system
use it.  The four examples you give above would be good places to start.
They would need to be fleshed out quite a bit, with discussion about what
happens when the user's goal cannot be accomplished, etc.

Use cases divide the world into the system under design (in this case, a
network interface supporting the NSIS protocol) and "actors" that utilize or
interact with the system.  My original comment was that taking a use case
approach and simply identifying who the actors are would be a step forward.
For example, if all the actors are end-users, and there are no networks that
use the protocol, that would say that the protocol is only between user and
network, and not network to network.  If there are no use cases that
describe how a user moves from one network interface to another, it would
indicate that mobile users would not be supported.

Simply listing all the different actors that will use the protocol, and the
ways in which they are going to use it would begin to define the scope of
the protocol.  The hard part, then, comes in fleshing out all those use
cases with accurate and precise statements about what the interface does.

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

 -----Original Message-----
From: 	Marcus Brunner [mailto:[email-masked]] 
Sent:	Friday, January 25, 2002 10:02 AM
To:	Allen, Keith; [email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

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

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

--------------------------------------
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: Fri, 25 Jan 2002 18:00:38 +0100

Keith, see inline

--On Friday, January 25, 2002 10:12 AM -0600 "Allen, Keith" 
<[email-masked]> wrote:
[...]
> this technique, the requirements for a system are documented as a set of
> use cases which describe the ways in which all the different users of a
> system use it.  The four examples you give above would be good places to
> start. They would need to be fleshed out quite a bit, with discussion
> about what happens when the user's goal cannot be accomplished, etc.
>

Sure as you said it was ment to be a starting point.

[...]

> Simply listing all the different actors that will use the protocol, and
> the ways in which they are going to use it would begin to define the
> scope of the protocol.  The hard part, then, comes in fleshing out all
> those use cases with accurate and precise statements about what the
> interface does.
>

And what the interface MUST do (or what use case is supported and which one 
not.

Mrcus

>> 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]
>>
>> 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.
>>
>> then the next is MPLS with LSP and so on, will you see anything at the
>> far and distant end
>> it. Who is going to stuff the [everyhop] component into signaling
>> message? Don't expect it from [end host].
>>
>> 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]
>>
>> edge; edge - edge: the NSIS protocol is terminated at egdes of
>> one/multiple domains;
>>
>>
>> Best regards,
>> Georgios
>>
>>
>> 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.
>>
>> [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
>>