Subject: RE: H.323 with ATM

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 Apr 1999 15:25:13 -0500

The RMOA "Gateway for H.323 Media Transport Over ATM" is essentially a 
finished document now and needs only to go throught the final ballot.

H.323 Annex C assumes ATM end-to-end. The ATM Forum document focuses more
on the case where the edges are not ATM. The intention is that ITU-T 
H.323v3 incorporates the ATM Forum's specification.

In Annex C, the terminals themselves are ATM aware, so setting up SVCs
is easier. In the ATM Forum's specification, it is a bit more difficult to
figure out when to setup the SVCs, and how to used them bi-directionnaly.

What Jonathan said is absolutely true.

There is basically two parts to the spec: one dealing with how to set-up
SVCs based on H.245/H.225.0 information, and the other on RTP header 
compression transported over AAL5 (the compression mechanism is derived
from RTP/UDP/IP compression over PPP).

(I would have preferred to have the document splitted in two)

These two parts are distinct: the compession part could be used with other
protocols like SIP of MEGACO. As far as diffserv or RSVP as the trigger, 
well, I guess it needs more thinking. I guess it also depends on the
philosophy of what you want to do: do you need an explicit association
between the SVC and the "call/connection" at the H.225.0/H.245 or not?

-----
François Audet  Tel:+1 408 565 5675 mailto:[email-masked]
Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com 

> -----Original Message-----
> From: Francois D. Menard [mailto:[email-masked]] 
> Sent: Thursday, April 22, 1999 7:04 AM
> To: Ami Amir
> Cc: Jonathan Rosenberg; Abhishek Singh; Henning Schulzrinne; Eric Ho;
> IPTEL IETF Mailing List
> Subject: RE: H.323 with ATM
> 
> 
> 
> How does that align with the ATM Forum document written by 
> Francois Audet
> of Nortel ?
> 
> -=Francois=-
> 
> On Thu, 22 Apr 1999, Ami Amir wrote:
> 
> > Am I just butting in?
> > 
> > H.323 Annex C is all about how to run H.323 over ATM. 
> > 
> > FYI
> > 
> > Ami
> > 
> > 	-----Original Message-----
> > 	From:	Jonathan Rosenberg [SMTP:[email-masked]]
> > 	Sent:	Thursday, April 22, 1999 12:06 AM
> > 	To:	Abhishek Singh
> > 	Cc:	Henning Schulzrinne; Eric Ho; IPTEL IETF Mailing List
> > 	Subject:	Re: H.323 with ATM
> > 
> > 	Abhishek Singh wrote:
> > 	> 
> > 	> Hi Henning,
> > 	> 
> > 	> RMOA is rather revolutiory. I know SIP would work over
> > 	> any damn thing, but so would H.323. But the beauty of
> > 	> RMOA work is that instead of using RTP/UDP/IP over ATM
> > 	> in an unintelligent way it does use the QOS feautures
> > 	> of ATM rather than using RTP.
> > 
> > 	Rather than using RTP?? RTP doesn't provide QoS... 
> There is nothing
> > 	which prevents you from taking an RTP packet at an ATM boundary,
> > 	extracting it, and sending it over an ATM VC that has some QoS
> > 	associated with it (CBR or something), RTP in tact. 
> Whether or not
> > you
> > 	compress RTP is a separate issue.
> > 
> > 	Of course, this poor edge box now has to do some 
> application level
> > 	processing instead of being a pure layer 3/2 device. 
> Any end to end
> > 	security will make it impossible for the box to find 
> the RTP packets
> > as
> > 	well. It seems like it would be easier to stay at layer 3, and
> > establish
> > 	VC's based on RSVP or diffserv, or something like 
> that... but thats
> > a
> > 	separate issue.

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "ronald h. davis" <[email-masked]>
Date: Fri, 23 Apr 1999 07:52:59 -0500

> H.323v3 incorporates the ATM Forum's specification.

but from h.323 and h.323 annex c you can derive the same case as is
described in the atm forum document.  as i read the document, the c/d 
effectively implements the gatekeeper routed model for h.225/h.245 
channels.

> between the SVC and the "call/connection" at the H.225.0/H.245 or not?

i'm a bit confused about the question but i would say that the
answer is most definitely; if you're going to split call control
signalling and bearer connection control signalling, then you need
some means of correlating the two.  i don't think this was the issue
that jonathan had in mind but i say this because in the version of
the atm forum contribution that i have, there was no mention of use
of the broadband high layer information element or generic identifier
transport information element to do this correlation.  let me qualify
this by saying that my copy is from october...

as far as using rsvp or diffserv as a trigger for svc establishment,
i would think that you would want to be able to do that as well if
the intent is to have some means of providing end-to-end qos across
atm and ip network boundaries.  but this is the case of doing ip over
atm which annex c sought to avoid.  the annex c approach does get into
application layer processing at the interworking node as jonathan
mentioned, but you save the ip overhead.  there is an internet draft by 
garrett, et. al. which describes the interworking of controlled load 
service and guaranteed service with atm.

-- 
  __  ______  __  / __/ |       lucent technologies, naperville il, usa
_/ (_(_) / (_(_/_/_(_/  .       [email-masked]
author of "atm for public networks" published by mcgraw-hill
     http://www.amazon.com/exec/obidos/ASIN/0071344764

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Apr 1999 10:05:03 -0400

ronald h. davis wrote:
> some means of correlating the two. 

No, I don't think you need this explicit association. For regular IP
over ATM, its completely absent. Remember, this case here is not ATM end
to end (in which case you *would* need it), but rather IP on the
periphery, with an ATM cloud in the middle (at least, this is my
interpretation, correct me if I have completely misunderstood the model
here). When the RSVP hits the ATM cloud, it causes an SVC to be set up
(of course, RSVP and UNI signaling are in the opposite directions, but
that can be handled).  RTP packets come in, are sent through this SVC
(possibly being compressed), and then completely reproduced (IP header
and all), and the far end. They are then carried over normal IP to the
end. The recipient wouldn't even notice that there was an SVC. 

The great advantage of using RSVP or diffserv as a trigger for SVC
establishment is that is application independent. Lets not forget that
IP telephony is only one of many IP apps which will need QoS. By making
this QoS mechanism H.323 specific, you narrow the scope of the service
that can be provided (only H.323, and only the version you support),
make this edge box more complex, and in general break the end to end
model.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------