Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary b e tween a customer and the network)

From: [email-masked]
Date: Fri, 18 Jan 2002 16:44:37 -0000

There is something missing for me in your logic. What is 3?

I can better relate to the terminology of everyhop; everyedge; everyhost. Is
3 the everyhost bit?

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 18 January 2002 16:12
To: [email-masked]'; Schneider, Marco;
[email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
be tween a customer and the network)

Sorry, previous picture is garbled by mailer. 

[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3------------------------------------------------>
[host]

The 3 is our goal and is comprised of 1 and 2. As we know, there are
solutions for 2 (MPLS, DiffServ, PNNI, over-provisioning, etc). What we need
to solve is the 1.  Now what about translation (or mapping) between 1 and 2?
Do we need to standardize it?  If yes, where? In NSIS group or elsewhere?

Regardless, the objective of 1 is KISS and universal. The complexity of 1
and 2 mapping must be born by the [edge].

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

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; [email-masked];
[email-masked]
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements (priority on the
boundary be tween a customer and the network)

I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

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

Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.

However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.

|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host

  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, [email-masked] wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> 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: "Chen, Weijing" <[email-masked]>
Date: Fri, 18 Jan 2002 13:08:42 -0600

Dick,

3 is more a function than a particular protocol or protocol component. Allow
me to illustrate the QoS service delivery chain with the diagram below:

[host]<-------------------3----------------------------------------------->[
host]

a) The user locates the service provider or other subscriber(s) that he
wishes to contact.  The result of this step is that the subscriber will know
the network addresses of the other subscriber(s)) he wishes to contact, and
the QoS he wishes to use to contact them. (By SIP, SDP, DNS, web, or any
application level session protocol)
b) The user negotiates with the network to establish the desired
communications capabilities with the other subscriber(s). (By signaling
protocol 1)
c) The network internally allocates the resources to fulfill the
subscriber's request. (By signaling protocol 2 (e.g. PNNI, MPLS, RSVP, or
even over-provisioning) and mapping of QoS of 1 to QoS of 2)
d) The user authenticates with the other subscriber(s) and is authorized to
receive services from them. (By other security means)
e) The user then communicates with the other subscriber(s)) to receive
services. (By underline transport link reserved previously in step b and c.
)
f) At the conclusion of the session, billing information is recorded so the
subscriber can be billed for the network services.

Now 3 is the experience of the user who got QoS service from the network.
The actual protocols involved are 1 and 2. The 1 does not really go from
end-to-end, but from end-to-network, and network-to-end. The edge will do
the network-to-network. Again standardization of 1 to 2 QoS mapping is
debatable which I don't have an opinion yet.

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

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, January 18, 2002 10:45 AM
To:	Chen, Weijing; [email-masked]; Schneider, Marco;
[email-masked]
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements  (priority on the
boundary b e tween a customer and the network)

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 18 January 2002 16:12
To: [email-masked]'; Schneider, Marco;

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

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; [email-masked];
[email-masked]
Cc:	[email-masked]

I do not agree.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

Marco Schneider

-----Original Message-----

Hi Dick 

|---------|
|---------|

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Allen, Keith" <[email-masked]>
Date: Fri, 18 Jan 2002 14:03:03 -0600

Hi all,

I'm still trying to get caught up on the terminology and semantics of the
discussion you are having, and I'm having some difficulty understanding the
edge-edge, hop-hop, and host-host discussion.

In telephony signaling, at least, the concept of "termination" is used.  An
entity "terminates" signaling if it receives signaling information,
understands it, and takes some action in response to it.  Now, part of the
action taken in response to a signaling message might be to formulate
another signaling message (using either the same signaling protocol or a
different protocol) and send it along to another entity, but it has still
"terminated" the signaling.  An entity that does not terminate signaling
would just blindly convey a signaling packet without looking at its
contents.

Given this concept, has NSIS converged upon the entities that will terminate
the signaling protocol it is trying to define?  If we coarsely define the
universe as consisting of network service providers and network service
users, I can think of the following possible combinations of entities for
"terminating" a signaling exchange:

1. user - service provider
2. service provider - service provider
3. user - user
4. within a service provider's domain
5. within a user's domain

I hope NSIS is focused on (1).  (2) would also be useful, but the needs of
this interaction differ some from (1) and trying to define a single protocol
that does both might be difficult.  Users rarely interface directly with
other users without a service provider in between, so (3) would seem to be a
low priority.  Users may want to exchange data with each other about QoS,
though, using the network as a non-terminating transport mechanism for this
exchange.  I think, however, there will be lots of protocols that spring up
for this.  Things like SIP, H.248(?) and even the ubiquitous XML could end
up being used for this.  I think NSIS should focus elsewhere and not try to
duplicate these efforts.  There are already some protocols defined that
might fit the bill for (4) and (5), so again NSIS should not duplicate these
efforts or work them at a lower priority.

Of course, focusing on (1) and possibly (2) does not mean the others can be
ignored.  NSIS should be cognizant of the developments in those areas so its
work meshes well.

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

 -----Original Message-----
From: 	Chen, Weijing  
Sent:	Friday, January 18, 2002 1:09 PM
To:	[email-masked]'; Schneider, Marco
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements  (priority on the

Dick,

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

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 18 January 2002 16:12
To: [email-masked]'; Schneider, Marco;

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

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; [email-masked];
[email-masked]
Cc:	[email-masked]

I do not agree.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

Marco Schneider

-----Original Message-----

Hi Dick 

|---------|
|---------|

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: [email-masked]
Date: Mon, 21 Jan 2002 10:45:52 -0000

I have a worry about this.

The "2" flow works as you have shown, but in reality a 
[edge]<---2---[hop]-->[edge]
is really
[edge][domain]<--2--[hop]-->[domain]  ...(cont next line)
<--2--[hop]-->[domain]<--2--[hop]-->[domain][edge]

where the flow

[domain]<--2--[hop]-->[domain]
implies a domain bounded by an interworking function and containing one or
more switching functions (i.e. at least a router or possibly a multiplexor
or switch etc.)

The inter-domain aspect is complex because of differing technology/QoS
solutions and the "who does the interworking" problems. If the interdomain
problem is solved by a standardised QoS request signalling protocol, then
this can be "mapped" down to the "2" flow you have shown.

This simplifies the interworking problem. Given a set of protocols, then the
requirement to interwork each protocol to all the others is a problem of
forever increasing complexity. If you interwork to a single generic protocol
then the interworking problem is 1x(NumProtocols). Every time you add a new
QoS mechanism, then the you only need one additional interworking solution.

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 18 January 2002 19:09
To: [email-masked]'; Schneider, Marco
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
b e tween a customer and the network)

Dick,

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

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 18 January 2002 16:12
To: [email-masked]'; Schneider, Marco;

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

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; [email-masked];
[email-masked]
Cc:	[email-masked]

I do not agree.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

Marco Schneider

-----Original Message-----

Hi Dick 

|---------|
|---------|

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Chen, Weijing" <[email-masked]>
Date: Mon, 21 Jan 2002 12:05:57 -0600

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

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Monday, January 21, 2002 4:46 AM
To:	Chen, Weijing; Schneider, Marco
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements   (priority on the

where the flow

[wj] The inter-domain could use [host]-to-[edge] solution too. The receiving
domain is the [edge], and sending domain is the [host], and vice versa.

[wj] If we accept the [host]-to-[edge] solution as inter-domain solution,
then the standard mapping will be every other protocol mapping to
[host]-to-[edge].

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 18 January 2002 19:09
To: [email-masked]'; Schneider, Marco
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary

Dick,

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

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 18 January 2002 16:12
To: [email-masked]'; Schneider, Marco;

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

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; [email-masked];
[email-masked]
Cc:	[email-masked]

I do not agree.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

Marco Schneider

-----Original Message-----

Hi Dick 

|---------|
|---------|

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: [email-masked]
Date: Fri, 25 Jan 2002 16:41:13 -0000

Whoops. Of course the network can satisfy the request using
overprovisioning, management set-up, etc.

The problem is that these methods are not dynamic. They usually apply to a
scenarios where there is more bandwidth than the users will ever need, which
is an oxymoron. Users needs expand to take up the bandwidth available (see
the greenhouse effect below). But what about negotiation and re-negotiation?
What about VPN crossing interdomain boundary - just contracts? (actually I
think contracts are just a method of the lawyers getting their hands on more
money!).

An amusing aside to illustrate the above point: The Greenhouse Effect.

I read a gardening magazine in which therre was a letter, almost
complaining, from someone who had bought a greenhouse (or glasshouse) a year
previously. The person had read in the same magazine an article about
"Choosing your greenhouse", and the article outlined  various ways of
deciding how much square area you would need in your new greenhouse. The
article then recommended that the prospective purchaser increase the square
area by 50%, as this exactly how much extra space will be needed one year
after purchase.
The letter writer was complaining that they followed ALL the advice and
bought a greenhouse 50% larger than their perceived needs. Now, one year
later, it was too small, and they wished they had bought one 50% bigger than
the purchased size.

So, however much you have, you can always fill it.

Happy weekend.

Dick 

-----Original Message-----
From: Marcus Brunner [mailto:[email-masked]]
Sent: 25 January 2002 16:25
To: [email-masked]; [email-masked];

Dick,

There are other means for inter-domain setup. E.g., on a management 
interface, contacting for traffic trunks etc.

Marcus

--On Friday, January 18, 2002 11:12 AM +0000 [email-masked] wrote:

>
> I do not agree.
>
> What is the point of completing the work enabling the customer to signal
> to the network, if the network cannot signal between domains? The network
> can never satisfy the request.
>
> Dick
>
> carrier) or Edge to Core, I think that we need to prioritize on a
> signaling protocol across the boundary between a customer and the
> network. Note that the customer could be an individual, an ISP or another
> Carrier.
>
> Marco Schneider
>
> specify a protocol that can be used independent of the underlying
> transport  technology, but that can satisfy the QoS requirements imposed
> by these  underlying transport technologies. Otherwise the protocol will
> not be suitable
> and useful.
>
>| ---------|
>| ---------|
>| everyhost|<------------------------------------------------------->|ever
>| yho
> st|
>| ---------|
>| ---------|
>|         |                                                         |
>|
>| ---------|   |---------|                             |---------|
>| ---------|
>| everyedge|<->|everyedge|<--------------------------->|everyedge|<->|ever
>| yed
> ge|
>| ---------|   |---------|                             |---------|
>| ---------|
>|         |   |         |                             |         |   |
>|
>| ---------|   |---------|   |--------|   |--------|   |---------|
>| ---------|
>| everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
>| <->|everyhop |
>| ---------|   |---------|   |--------|   |--------|   |---------|
>| ---------|
>  *  interior: can be any router within a domain and it can process and
> use      only the "everyhop" protocol component.
> application-related signalling for QoS (at session level) and QoS
> signalling protocols used to actually provision the QoS at the transport
> level. Brian is right that there will never be an enhancement to a single
> session protocol that will satisfy all applications.
> However, for similar reasons, it is never going to be possible to
> prescribe a single QoS mechanism to be used in all networks. Existing
> networks (or domains) will not be changed overnight and new networks
> already face several workable mechanisms to deploy QoS.
>
> and may lend itself to the signalling of pre-defined QoS classes rather
> than parameters.
>
> Dick Knight
>

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