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

["Motty Anavi" <[e-mail]>]

Andy,
    There are some differences that can be overcome by existing mechanisms.
We would add more on the technical steps and corrections that can be made to
make IP/UDP a suitable transport.

-- Cheers, Motty

> -----Original Message-----
> From: Andrew G. Malis [mailto:[e-mail]]
> Sent: Tuesday, March 06, 2001 4:25 PM
> To: Motty Anavi
> Cc: Andrew G. Malis; [e-mail]; Yaakov Stein; Schwarzbauer Hanns
> Juergen
> Subject: RE: [PWOT] draft-anavi-tdmoip-01.txt
>
>
> 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