Hi, Mike:

Yes, H.323 QOS will operate independent of the transport mechanisms. That is why, we all brought contributions in the first palce and all our efforts have been made to fulfill that goal. Acordingly, we have created new terminology that is known as H.323 appliction layer QOS. We have define how H.323 QOS works indpendent of any transport mechnaims on end-to-end basis. We have also defined how end-to-end H.323 QOS is signaled vis RAS during the pre-call setup time to discover what kind of QOS classes or parameters are available in a given zone or in different zones with the help of the GKs.

However, a given H.323 QOS class can be chosen by an endpoint to setup (Q.931/932) the call. This may also trigger H.245 OLCs to go for the media for which QOS will be provided to convert the astraction of H.323 QOS to the corresponding network layer QOS (where mapping is needed). Mr. Bowen edited TD-57 WP2/16 accordingly based on the contributions that were accepted in the last Red Bank meeting (Oct'99).

The agreement reached in the last SG16 meeting is as follows [TD-74 (plen) p-20]:

D.472(2/16) [Ericsson] - Generic QoS bearer for IP and ATM

A general method of discussing QoS was presented. This is believed to be more appropriate to IP than the method of TD57, which was viewed as being too ATM-centric. Support was expressed for the idea that TD-57 is too ATM-centric. It was noted that the ATM Forum terminology is used rather than the ITU-T forum QoS terminology. It was agreed that this contribution should be reflected in future versions TD57.

TD57(2/16) [Rapp.] - QoS Architecture and Supporting Protocol

It was noted that there appear to be a conflict between point 1(3) from APC-1705 and xxx accepted at this meeting.

It was agreed that :

1)This is not ready for determination 2)The H.323 material will go in a new Annex N "QoS in H.323 Systems and Networks." 3)It will be determined no earlier than Nov 2000, and more likely in 2001. 4)Liaisons need to be sent to: a)IETF b)TIPHON c)ATM Forum d)SG13 4)3GPP 5)3GPP2 5)Mr. Bowen will update Annex N to reflect D.472, and it will be attached to the liaisons. 6)Mr. Buckley will write the liaison. This liasion will solict specific input against the draft Annex N. 7)Going forward, Mr. Buckley will edit Annex N. He is also chair of the TIPHON QoS working group.

TD5(2/16) is related. It was noted that this work seems very similar to the approach of 3GPP and TIPHON.

D.451(2/16) reports on QoS work in TIPHON. It covers such advanced topics as allocating QoS budget between multiple carriers.

Therefore, the scope provided in your edited document does NOT reflect the agreement.

Moreover, the backward compatibility requirement will also mandate the mapping of H.323 QOS over RSVP (Guaranteed, Controlled, Best effort) and ATM QOS (CBR, rt-VBR, nrt-VBR, ABR, UBR). For example, once an H.323 QOS is agreed on end-to-end basis, an endpoint may use RSVP to implement the H.323 QOS over the transport network. Therefore, it mandates that H.323 QOS MUST be mapped to provide the backward comapatibility. Similar is the case for the ATM QOS.

Hope that this clarify that the H.323 QOS mapping over the transport network is a requirement and the scope MUST reflect this.

However, you are welcome to bring contributions to justify your case in the next OSAKA meeting (May'00) and we will definitely discuss it.

I also plan to provide comments for other part of the document later.

Best regards, Radhika R. Roy

-----Original Message----- From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] Sent: Monday, February 21, 2000 8:06 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 Annex N draft

Hi Radhika,

Thanks for your quick comments.

The agreement last week was that the H.323 mechanisms should operate independently of transport mechanism. This is included in the requirements. So all the mechanisms you list are included.

The backward compatibility is an important issue and one we should discuss carefully as to its implications. In principle I agree with you, backward compatibility with existing H.323 mechanisms should be an important factor. I am not yet sure yet what the implications of this are in the QoS area.

Mike

____________________ Begin Original Message ___________________________ Date: Mon Feb 21 17:56:43 -0500 2000 From: internet!ATT.COM!rrroy (Roy, Radhika R, ALARC) Subject: Re: H.323 Annex N draft To: internet!MAILBAG.INTEL.COM!ITU-SG16 Content-Type: Text Content-Length: 2192

Hi, Mike and All:

I did not have the time go through the whole document yet. However, a quick look into the document provides me to point out about the scope as follows:

1. The contributions were provided for mapping of H.323 QOS over the

network layer QOS. For example, IETF's DiffServ, IntServ/RSVP, and MPLS, and ATM QOS classes: CBR, VBR, rt-VBR, nrt-VRB, and ABR. Those contributions were accepted in the last Red Bank (Oct'99) meeting. Accordingly, the then editor Rich Bowen produced the TD in the last SG16 meeting.

So, the scope of H.323 QOS mapping over the network layer QOS (IP, ATM) shall be there.

However, if you have any disagreement over the decision made in the last Red Bank meeting, please submit a contribution in the upcoming OSAKA meeting (May'00), we can discuss. Until the decision is made based on contributions, the scope of the document shall remain the same as submitted by Mr. Rich Bowen.

2. So far the backward compatibility is concerned, it shall not only

consider Appendix II, but it shall also consider ATM QOS provided in H.323 Annex C. Accordingly, both backward compatibilities should be included as per norm of the ITU standards.

BTW, if you would keep the text the way I suggested, I would think that I did not have to provide my comments as stated above.

Best regards, Radhika R. Roy, AT&T

PS: I am yet to finish reading the whole document. Hope to provide more comments later.

...

-----Original Message----- From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] Sent: Monday, February 21, 2000 2:31 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.323 Annex N draft

Attached is the first draft of the new Annex N of H.323. This was

issued

...

at last week's meeting as TD126 of WP2 but the attached version includes some further minor revisions and additions of informational material (in the Appendices) which needs further review in the light of the adoption of the generic QoS bearer descriptor.

Comments and contributions welcome.

Mike Buckley (editor) mikebuckley@44comms.com +44-1457-877718 (T) +44-1457-877721 (F) << File: [No Description] >>