RE: [PWOT] draft-anavi-tdmoip-01.txt

["Andrew G. Malis" <[e-mail]>]

Motty,

My primary concerns with AAL1 and AAL2 are just that they were designed 
assuming that they are run over ATM, and thus there are assumptions 
regarding the layer below them that IP/UDP may not meet, at least without 
support from diffserv and perhaps other mechanisms, including 
MPLS.  Compensations for the differences of functionality between ATM and 
IP/UDP need to be made explicit in your draft.

Thanks,
Andy

---------

At 3/6/2001 03:18 PM -0500, Motty Anavi wrote:
>Hi Andy,
>      Thank you for your comments. First of all, let me clarify that the
>purpose of the document was to propose a high-level guidelines for a
>solution. It did not go in to the technical details.
>      Having stated that, we fully intend to go over a much more detailed
>technical solution. Our assumption was that it was preferable to present a
>high level view and concentrate on the requirements, so that we could
>establish a work group charter, and drill down later.
>
>    We're also not assuming any specific infrastructure in place that would
>create undue constraints on the implementation of the interworking function.
>
>      As for the specific issues you raised regarding the draft:
>1. Clocking issues - While this is not referenced in the draft directly,
>non-synchronous timing recovery is can be handled through the clocking
>mechanism. Adaptive clocking can be used for that.
>2. QoS - As an interworking function, the protocol should allow for the
>transporting layer to distinguish and prioritize the TDM traffic over lower
>priority traffic. As such, mechanisms allowing prioritization and
>differentiation should be supported. We would add a section dealing with QoS
>interaction. We shouldn't consider QoS requirement of any underlying layer,
>but rather provide a mechanism for that layer to prioritize the time
>critical data using it's own mechanisms.
>3. AAL1 + AAL2 assumptions - I agree that additional facilities should be
>outlined for the exact compensations that are to be made for AAL1 and AAL2
>to be more efficient, however, the crux of the matter is the use of a
>pre-existing standards infrastructure in interworking function to provide
>the basis for a more detailed implementation.
>4. Use of RTP - We are not proposing using RTP. The overhead is quite large,
>considering we can get the RTP clocking benefits through the existing AAL
>structures.
>
>We do consider this draft a good solution and don't consider this just as an
>informational draft.
>
>Hopefully, this will clarify our approach to this draft and also serve to
>enhance your understanding of TDMoIP.
>
>Thanks again for your comments.
>
>-- Cheers, Motty
>
>
> > -----Original Message-----
> > From: Andrew G. Malis [mailto:[e-mail]]
> > Sent: Tuesday, March 06, 2001 12:26 AM
> > To: Motty Anavi
> > Cc: [e-mail]; Yaakov Stein; Schwarzbauer Hanns Juergen
> > Subject: Re: [PWOT] draft-anavi-tdmoip-01.txt
> >
> >
> > Motty,
> >
> > >     This draft proposes a simple way of transporting TDM
> > circuits over IP.
> > >It can be found on the IETF web site at:
> > >http://www.ietf.org/internet-drafts/draft-anavi-tdmoip-01.txt
> > >
> > >I would appreciate any comments you might have.
> >
> > I agree that it's very simple, but it seems to have skimped on
> > many of the
> > issues and details that have been discussed previously in
> > draft-boyle-sts-ip-00.txt and draft-malis-sonet-ces-mpls-03.txt, such as
> > non-synchronous timing recovery, synchronous justification events, outage
> > signaling, efficiency, and interactions with Internet traffic engineering.
> >
> > In addition, AAL1 and AAL2 also make a number of assumptions based upon
> > their usage above ATM, such as insured cell sequentiality and particular
> > jitter and loss bounds, that need to be made explicit if you
> > attempt to use
> > them over IP rather than ATM.  I would be interested in hearing
> > if you are
> > aware of their successful use in non-ATM environments.
> >
> > My final comment is that your text is very unclear regarding the use of
> > RTP.  Its use is discussed in section 2, but not in section 5.
> > Is it used,
> > or not?
> >
> > Cheers,
> > Andy
> >
> > ========
> >
> > At 3/5/2001 12:22 PM -0500, Motty Anavi wrote:
> > >FYI,
> > >
> > >-- Cheers, Motty
> > >
> > >Motty Anavi               |900 Corporate Dr.
> > >RAD data communication    |Mahwah, NJ 07430
> > >Dir. of Product Management|[phone]x213
> > >e-mail: [e-mail]
> > >
> > >
> > >
> > >_______________________________________________
> > >pwot mailing list
> > >[e-mail]
> > >http://www.ietf.org/mailman/listinfo/pwot
> >

________________________________________________________________________
Andrew G. Malis     [e-mail]     phone:[phone]
Vivace Networks/2730 Orchard Parkway/San Jose, CA 95134/fax:[phone]
http://www.vivacenetworks.com


_______________________________________________
pwot mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pwot