H.323 Annex N draft

Mike Buckley mikebuckley at ATTMAIL.COM
Tue Feb 22 13:56:17 EST 2000


Hi Radhika,

I am not sure what your concern is here.

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

You areright that the text of the scope was not discussed during the meeting.
The point was made, however, in discussions that Annex N required a scope
statement.  I drafted something for discussion based on the documents
presented at the meeting, and off line discussions I had with interested parties
(included yourself).  It is a draft and we can change it.

>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 compatibility. Similar is the
>case for the ATM QOS.

Radhika, could you clarify what you mean by the backward compatibility issue?
I don't think anyone is disagreeing that the scheme must be compatible with the
use of RSVP from the terminal.  What specific constraints do you see imposed
by Appendix II?

What are the issues with ATM?

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

I don't see that you have made a case out for mapping in the H.323 application.
If application and transport are independent the mapping will take place in the
Resource Manager in the transport layer and  the H.323 mechanisms will be
independent of it.

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 am not sure what you are asking me to make a contribution on.  The text as
>it stands reflects the wish of the meeting last week and the discussions at the
>lunchtime editing meeting.  What do you see precluded by the existing text?

Mike




____________________ Begin Original Message
___________________________
Date: Tue Feb 22 08:43:28 -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: Generic-Text
Content-Length: 7049

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 at ATTMAIL.COM]
> Sent: Monday, February 21, 2000 8:06 PM
> To:   ITU-SG16 at 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 at ATTMAIL.COM]
> > Sent: Monday, February 21, 2000 2:31 PM
> > To:   ITU-SG16 at 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 at 44comms.com
> > +44-1457-877718 (T)
> > +44-1457-877721 (F) << File: [No Description] >>



More information about the sg16-avd mailing list