PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL

Roy, Radhika R, ALCTA rrroy at ATT.COM
Fri Jun 1 12:52:38 EDT 2001


Hi, Gary:

Let me make it clear: No specific suggestions have been made to
extend/exploit the existing messages/parameters.

So, if a requirement is there that an emergency call need to be handled by
the GK, we can do the following analysis of the requirements:

1. A call needs to be differentiated based on Emergency, High Priority, etc.
2. Allow a preemption of a low priority call by a high priority one if
resources are not available.

May be new signaling messages in H.323 are needed to meet the above
requirements.

If we take the above two, as an example, and if the signaling messages are
there to signal those two appropriately, I believe, a GK will be able to
take the proper decision.

Please note that I have NOT used the word "policy" per se (a GK may create
its own policy by de-fault [proprietary] based on those criteria).

However, if we want to create a standard for "policy" for the inter-domain
calls, for example between the carriers, we need to do more. We may consider
a policy server is behind the GK (something like COPS of the IETF).

Best regards,
Radhika

-----Original Message-----
From: Gary Thom [mailto:gthom at delta-info.com]
Sent: Friday, June 01, 2001 12:21 PM
To: Roy, Radhika R, ALCTA; ITU-SG16 at mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL


My comment was that if the gatekeeper has an addmission pollicy that states
that it only allows 20 calls or 2Mbps of bandwidth, and a high or emergancy
priority call request is being made, the Gateway may stretch it policy to
allow that call.

I also agree that bandwidth requesta are already indicated in the ARQ, so
maybe it is not appropriate to indicate them again in the qos signalling.

 --------------------------------------------
 Name   : Gary A. Thom
 Company: Delta Information Systems, Inc.
 Address: 300 Welsh Rd., Bldg 3
          Horsham, PA 19044 USA
 Phone  : +1-215-657-5270 x123
 Fax    : +1-215-657-5273
 E-mail : gthom at delta-info.com
 Website: www.delta-info.com
--------------------------------------------


-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:rrroy at att.com]
Sent: Friday, June 01, 2001 12:15 PM
To: gthom at delta-info.com; ITU-SG16 at mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL


Hi, Bob and Gary:

There is already an optional requirement in H.323 that the GK does the
admission control. For example, the bandwidth parameters are there where the
GK decides whether the request can be accepted or not.

We can extend/exploit those notions more with respect to the GK admission
control in addition to the SLA.

Best regards,
Radhika

-----Original Message-----
From: Gary Thom [mailto:gthom at DELTA-INFO.COM]
Sent: Friday, June 01, 2001 12:04 PM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL


Bob,

I agree with your discussion of gatekeeper behavior, but there are
gatekeeper actions that need to be taken regardless of the call model.

For example admission policy will be affected by the desired service class.
A service level agreement may relieve addmission restrictions for high
priority calls.

Gary

 --------------------------------------------
 Name   : Gary A. Thom
 Company: Delta Information Systems, Inc.
 Address: 300 Welsh Rd., Bldg 3
          Horsham, PA 19044 USA
 Phone  : +1-215-657-5270 x123
 Fax    : +1-215-657-5273
 E-mail : gthom at delta-info.com
 Website: www.delta-info.com
--------------------------------------------


-----Original Message-----
From: Callaghan, Robert [mailto:Robert.Callaghan at icn.siemens.com]
Sent: Friday, June 01, 2001 10:57 AM
To: 'gthom at delta-info.com'; ITU-SG16 at mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL


Gary,

In the direct call routed model, Gatekeepers only register and authorize
endpoints can calls.  The call control messages do not involve the
gatekeepers and therefore cannot control the gatekeeper handling of the
call.  Even in a gatekeeper routed model, there is no need for more than two
gatekeepers (originating and terminating).  There can be a lot of space and
networks between the two.  Firewalls tend to be used to isolate an
enterprise network from a public network.  The public network involves many
providers and network segments without any firewalls.

The application layer signaling data stream may be able to control its QOS.
In that the RTP streaming data transport is separately routed from the
application data stream.  And it is not possible for one stream to control
another stream without a fundamental change to the Internet fabric.  I doubt
that this will happen.  If it does happen, it will not be fully implements
for a very long time.  (One of the IETF people proposed that this is not an
engineering problem but the basis for a research project.)

Bob

--------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
5500 Broken Sound Blvd,      Boca Raton, Fl 33487
Tel: +1 561 923-1756            Fax: +1 561 923-1403
Email: Robert.Callaghan at ICN.Siemens.com
-----------------------------------------------------------------

-----Original Message-----
From: Gary Thom [mailto:gthom at delta-info.com]
Sent: Friday, June 01, 2001 10:24 AM
To: ITU-SG16 at mailbag.cps.INTEL.COM
Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL

The application layer QOS should be an indication of the abstract quality
and priority requirements or capabilities. This should really be called
"Application Level Service Class" because it affects more than just the
transpost level QOS mechanisms. It also affects Gatekeeper and Gateway
behaviour.

This should be independent of the transport layer mechanisms.

The mapping of service class to transport level QOS and Gatekeeper and
Gateway behavior is an implementation issue or is subject to service level
agreements.

Gary

 --------------------------------------------
 Name   : Gary A. Thom
 Company: Delta Information Systems, Inc.
 Address: 300 Welsh Rd., Bldg 3
          Horsham, PA 19044 USA
 Phone  : +1-215-657-5270 x123
 Fax    : +1-215-657-5273
 E-mail : gthom at delta-info.com
 Website: www.delta-info.com
--------------------------------------------


-----Original Message-----
From: Mailing list for parties associated with ITU-T Study Group 16
[mailto:ITU-SG16 at MAILBAG.INTEL.COM]On Behalf Of Roy, Radhika R, ALCTA
Sent: Friday, June 01, 2001 9:44 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL


Hi, Bob:

You are right that the application layer does not control the lower layers
(e.g., RTP, UDP, IP).

So, there is a requirement how the lower layers can be coupled for
implementation in cooperation with the higher layer. The fact of the matter
is that the lower layers are responsible for sending the media streams
between the source and destination path.

This is the area for implementations and we have to see how far the SG16 is
going to dig to address this problem because our works will be limited
mostly in the upper application layer.

AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a
framework how to address this problem.

Any contributions along this line will be highly appreciated.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Callaghan, Robert [mailto:Robert.Callaghan at icn.siemens.com]
Sent: Friday, June 01, 2001 9:24 AM
To: Roy, Radhika R, ALCTA; ITU-SG16 at mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL


Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS)
may or may not have the end-to-end significance. For example, an IP network
may implement different QOS schemes in different domains (e.g., RVSP in one
domain, DiffServ in another domain).

However, the application layer QOS is end-to-end that remains the same. For
example, an H.323 or SIP call that can traverse several IP domains where
each domain may implement its own network layer QOS schemes while the
H.323/SIP call carry the signaling messages and QOS parameters end-to-end
independent of the underlying network layer QOS mechanisms.

Yes, the application layer is end-to-end.  But does it traverse the exact
same route as RTP transport layer?  I don't think so, in that this is not
IP.  IP routes each packet individually with the right to change routes
independently for each stream, and each packet in a stream.  This is the
basis for load balancing, overload control, and link failure survivability.

With this in mind, the application layer can negotiate an end-to-end QOS
with the ends.  It cannot control the intermediate routing nodes.  A method
is needed to accomplish the end-to-end QOS control via the RTP IP stream.

Bob

--------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
5500 Broken Sound Blvd,      Boca Raton, Fl 33487
Tel: +1 561 923-1756            Fax: +1 561 923-1403
Email: Robert.Callaghan at ICN.Siemens.com
-----------------------------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list