QOS signaling in RAS

Roy, Radhika R, ALCOO rrroy at ATT.COM
Fri Oct 20 08:32:14 EDT 2000


Hi, Ilyya and Mike:

Please see H.323 Appendix II - Transport Level Resource Reservation
Procedure.

The "transportQOS" field simply provides a mechanism who "controls" the
transport level resource reservation: Endpoint or GK. Accordingly, the
resource reservation is made by that particular entity.

Then each entity can use couple of things related to the resource
reservation: 1. BRQ/BCF/BRJ and 2. RSVP (plus ATM QOS for the ATM network as
well).

Now, items 1 and 2 are independent. Item 1 is in RAS (pre-call setup phase)
and item 2 is in H.245 (call setup phase).

Here is my own interpretation: Item 1 has the abstraction of bandwidth
(generic) that can be used on end-to-end basis. That is, this abstraction is
independent of the lower transport network. In other words, the total
bandwidth that is required for the H.323 application (audio, video, and
data) is expressed in the bandwidth field.

However, item 2 is network specific. If there is a single network (either IP
or ATM), it may work. If there are two networks (IP + ATM) between the two
H.323 endpoints, we have problems to use either RSVP or ATM QOS on
end-to-end basis.

In addition, H.323 also provides the abstraction of "circuits: DS0s, etc.
(indirectly bandwidth)" in the context of the PSTN-Packet network in Q.931
call setup phase.

H.323 Annex N is addressing this problem to provide end-to-end QOS not only
for the bandwidth parameter, but for all other parameters including delay,
jitter, bit-error-rate/packet losses for both: 1. Pre-call setup phase (RAS)
and 2. Call setup phase (Q.931/H.245).

AT&T is bringing a contribution related to QOS in the upcoming SG16
November'00 meeting.

Best regards,
Radhika R. Roy
AT&T
+1 732 420 1580

-----Original Message-----
From: Mike Buckley [mailto:mikebuckley at 44COMMS.COM]
Sent: Friday, October 20, 2000 6:16 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: QOS singaling in RAS


Ilya,

We are presently reviewing QoS support in H.323 and a new Annex N to H.323
is in preparation.  The current H.323 assumes homogeneity of network
transport and QoS mechanisms so the only issues to be considered in H.323
are what type if QoS mechanism is supported in the end point.  The new work
recognises that transport may involve a variety of transport mechanisms e.g.
ATM, IP FR, as well as QoS mechanism, e.g. RSVP, DiffServ, MPLS, some of
which may be hidden from the end user.

Maybe other experts could comment on your specific query.

Regards,


Mike Buckley
Editor Annex N

+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley at 44comms.com


----- Original Message -----
From: "Ilya Freytsis" <ifreytsis at CETACEANNETWORKS.COM>
To: <ITU-SG16 at MAILBAG.INTEL.COM>
Sent: Thursday, October 19, 2000 7:46 PM
Subject: QOS singaling in RAS


> Dear experts,
> One of the choices of the RegistrationRejectReason (h225 v3) is
> "transportQOSNotSupported       NULL,   -- endpoint QOS not supported".
How it should be interpreted since it seems there is nothing
> related to transport QOS in registration request PDU itself?
>
> Ilya Freytsis
> Cetacean Networks
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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