Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] TDM or ATM/FR service emulation over RPR ring




All,

The results of this offline discussion would be most useful
if condensed into an informative annex. The existing MAC
capabilities were intended to support TDM traffic, I would
like to see an informational annex that validates the transfer
of intent into reality.

I would claim that 802.17 has _most_ of the features required
to support TDM traffic. However, a couple of areas might have
been missed:
  1) Dynamic changes in levels of allocated class-A bandwidths
  2) Synchronized time-of-day timers, so that information can
     trickle out of the destination at the same rate that it
     arrived at the source.

I am providing contributions, through comments, in these areas.
Others are, of course, also encouraged to do so, in the form of
normative-text supplements and/or informative annex content.

DVJ


David V. James, PhD
Chief Architect
Network Processing Solutions
Data Communications Division
Cypress Semiconductor
110 Nortech Parkway
San Jose, CA 95134
Work: +1.408.942.2010
Cell: +1.650.954.6906
Fax:  +1.408.942.2099
Work: djz@xxxxxxxxxxx
Base: dvj@xxxxxxxxxxxx

> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of tom k. johnson
> Sent: Tuesday, March 05, 2002 12:09 PM
> To: Ray Kuo; Leon Bruckman; Murali
> Cc: stds-802-17@xxxxxxxx; Yu Ning
> Subject: RE: [RPRWG] TDM or ATM/FR service emulation over RPR ring
>
>
>
> Leon.
>
> I would be interested in listening to this off-line discussion as well :-)
>
> Thanks
>
> -Tom
>
>
> > -----Original Message-----
> > From: Ray Kuo [mailto:RKuo@xxxxxxxxxxxxxxxxxx]
> > Sent: Tuesday, March 05, 2002 12:42 PM
> > To: Leon Bruckman; 'Murali'
> > Cc: stds-802-17@xxxxxxxx; 'Yu Ning'
> > Subject: RE: [RPRWG] TDM or ATM/FR service emulation over RPR ring
> >
> >
> >
> > Hi Leon:
> >
> > I think this is interesting question also.
> > Could you answer to this list or cc to me?
> >
> > Thanks!
> > Ray Kuo
> >
> > -----Original Message-----
> > From: Leon Bruckman [mailto:leonb@xxxxxxxxxxxxx]
> > Sent: Tuesday, March 05, 2002 3:56 AM
> > To: 'Murali'
> > Cc: stds-802-17@xxxxxxxx; 'Yu Ning'
> > Subject: RE: [RPRWG] TDM or ATM/FR service emulation over RPR ring
> >
> >
> >
> > Hi Murali,
> > Since I believe this is not in the scope of the WG, let us
> > take it off line.
> >
> > I will answer soon.
> > Leon
> >
> > -----Original Message-----
> > From: Murali [mailto:murali.subramanian@xxxxxxxxx]
> > Sent: Tuesday, March 05, 2002 1:53 PM
> > To: Leon Bruckman
> > Cc: stds-802-17@xxxxxxxx; 'Yu Ning'
> > Subject: Re: [RPRWG] TDM or ATM/FR service emulation over RPR ring
> >
> >
> > Hi Leon,
> >
> >         I have also a question related to TDM/FR/ATM
> > emulation over RPR.
> >         How do we identify the destination node MAC address
> > in such a case
> > and set the priority?
> >
> >         Request for your inputs.
> >
> > Regards,
> > Murali.S
> >
> > ----- Original Message -----
> > From: "Leon Bruckman" <leonb@xxxxxxxxxxxxx>
> > To: "'Yu Ning'" <yuning@xxxxxxxxxxxxxxx>
> > Cc: <stds-802-17@xxxxxxxx>
> > Sent: Tuesday, March 05, 2002 2:49 PM
> > Subject: RE: [RPRWG] TDM or ATM/FR service emulation over RPR ring
> >
> >
> > >
> > > Hi Yu,
> > > RPR Standard defines a MAC and does not deal directly with how to
> > transport
> > > the services. It provides Classes of Service that can be
> > used to transport
> > > different services, but these classes are defined based on their
> > > characteristics (delay, delay variation,..) and not on the type of
> > service.
> > >
> > > As for the specific way of transporting TDM/FR/ATM over
> > packet networks I
> > > recommend you to look in the IETF PWE3 work.
> > >
> > > And yes, we have considered the stringent timing
> > requirements of TDM over
> > > RPR (you can see some presentations of simulations results
> > as early as
> > March
> > > 2001). From the results, and also theoretical calculations,
> > for high rate
> > > ring there is no problem to deal with the delay variation
> > using a small
> > > dejitter buffer at the receiver.
> > >
> > > Leon Bruckman
> > > VP & Chief System Architect
> > > Corrigent Systems
> > >
> > > -----Original Message-----
> > > From: Yu Ning [mailto:yuning@xxxxxxxxxxxxxxx]
> > > Sent: Tuesday, March 05, 2002 10:12 AM
> > > To: stds-802-17@xxxxxxxx
> > > Subject: [RPRWG] TDM or ATM/FR service emulation over RPR ring
> > >
> > >
> > >
> > > Hi All,
> > >
> > > Apologize if this question been asked before (pls give a
> > pointer to former
> > > answer then.)
> > >
> > > How is the TDM, ATM/FR service emulation provided through RPR ring ?
> > > Is this emulation based on a protocol translation scenario
> > (protocol field
> > > mapping), or raw encapsulation scenario (put TDM/ATM/FR frame as RPR
> > > payload)?
> > >
> > > Because I saw some product brochure from vendors, like Luminous,
> > Riverstone,
> > > their MAN box has both Ethernet interface and PDH
> > interface, like E1/T1,
> > and
> > > all through RPR backhaul (said so). It just puzzled me how
> > to emulate
> > these
> > > service through RPR ring.
> > >
> > > I've checked RPR whitepaper, and rfc2892, there is no description on
> > > service emulation issue, only a natural L3 IP into RPR
> > frame illustration.
> > >
> > > If TDM via RPR ring, anyone considered the stringent timing
> > requirement
> > > from TDM ?
> > >
> > >
> > > thanks for any input.
> > >
> > >
> > > Yu Ning
> > >
> > > ______________________________________
> > >
> > > (Mr.) Yu Ning, Chief Engineer
> > > ChinaNET (AS4134) Senior Support
> > > Internet Dep. DCBU, China Telecom
> > > Beijing, P.R.China +86-10-62072357
> > > Personal Page-> http://navidog.126.com
> > > ______________________________________
> > >
> >
>