Hi, Mike:
The fundamental issue is that we should be able to map the H.323 QOS over
the lower network layer.
H.323 standard has already defined how the lower network layer QOS (e.g.,
RSVP [guaranteed, controlled, best effort], ATM QOS [CBR, rt-VBR, nrt-VBR,
ABR, UBR]).
Now, if we define H.323 application layer QOS only without defining the
mapping, this will not provide backward compatibility to the existing H.323
standard.
This is the concern.
So, the "scope" should include the "mapping" of the H.323 QOS to the lower
network layer QOS.
I am not speaking which functional entity (e.g., you are mentioning about
the resource manager, etc.) will do the mapping or how the mapping will be
implemented within the network by any functional entity.
I am urging that contributions should be brought explaining how the H.323
QOS can provide backward compatibility without defining the mapping.
So, the simplest solution is that we should include "mapping" as a part of
scope.
Best regards,
Radhika R. Roy
AT&T
> -----Original Message-----
> From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM]
> Sent: Tuesday, February 22, 2000 1:56 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 Annex N draft
>
> 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@ATTMAIL.COM]
> > Sent: Monday, February 21, 2000 8:06 PM
> > To: ITU-SG16(a)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(a)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(a)44comms.com
> > > +44-1457-877718 (T)
> > > +44-1457-877721 (F) << File: [No Description] >>
