Cell Relay Archive

Cell Relay Retreat>List Archive>month:1999-Oct> msg00049



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: idle cells definition

  • From: "C. M. Heard/VVNET, Inc." <heard@vvnet.com>
  • Date: 13 Oct 1999 22:39:39 GMT


> From: Paul Koning <pkoning@xedia.com>
> Date: Tue, 12 Oct 1999 11:44:43 -0400
[ ... ]
> "C. M. Heard/VVNET, Inc." wrote:
[ ... ]
> > From a very formalistic point of view, using unassigned cells amounts
> > to performing cell rate decoupling at the ATM layer, while using idle
> > cells amounts to performing cell rate decoupling at the physical layer.
>
> Formalistic, indeed.  This distinction is one that can
> please only protocol lawyers; all others just consider it
> a useless pain in the neck that has no value whatsoever but
> adds confusion and possibly causes problems.

I do not disagree :-)))  As I pointed out in a post to the CR mailing
list, idle and unassigned cells are almost always discarded by the
same piece of hardware, which makes the distinction unreal from an
implementation perspective.

> > In all the ATM layer chips that I know of (and I've only dealt with ATM
> > over SONET) the ATM layer chip takes care of this function.  A well-designed
> > chip will let you choose the values for GFC, PT, and CLP to be transmitted
> > in cells that are inserted for cell rate decoupling, and will let you
> > choose zero, one, or don't care for the values that the bits in these fields
> > are required to have in order for a received cell with VPI=VCI=0 to be
> > treated as time fill (i.e. discarded).
>
> I've seen a couple: all but one let you specify receive side
> idle detection with don't cares so you don't need to tell the
> receiver what sort of idles to expect.  Unfortunately, there's
> one that has to be told a specific pattern for send and for
> receive, with no support for don't cares.  So that particular
> chip could give you interoperability problems.  Well, perhaps
> not in a NIC, where the SAR is a second line of defense.

Right.  In a switch you'd tend to flood useless junk onto the backplane
or into the switching fabric if the ATM layer device was set to discard
idle cells and the remote peer used unassigned cells.

> > The best practice from a standpoint of interoperability is to have the
> > receiver discard _all_ cells with VPI=VCI=0 regardless of what the PT,
> > CLP, and (at the UNI) GFC values are.  You are asking for interoperability
> > problems if you use a chipset or buy a piece of ATM gear that does not
> > allow this.  We recently considered (and rejected) an otherwise attractive
> > ATM/PoS chip because it could not do this.
>
> 12001?  Yes, what you say makes a lot of sense...

I cannot name the manufacturer of the chip in question, since we got the
data sheet under NDA.

> > Time fill cells inserted by the transmitter SHOULD have PT (and GFC, if
> > applicable) configurable with a default value of zero, but having fixed
> > values of zero for these fields would probably be OK.  You are asking
> > for interoperability problems if the outgoing CLP cannot be configured.
> > In an ideal world the choice would not matter, but there are some
> > devices that only discard VPI=VCI=0 cells with a specific CLP value.
> > The default should probably be CLP=0 (unassigned cells) in North America
> > and CLP=1 (idle cells) in Europe or for international links.
>
> I didn't realize this is a location-specific thing.  Why would
> the default depend on where you are?

The assumption I'm making is that European customers would be more likely to
insist on compliance with ITU-T standards, which call for idle cells, whereas
North American customers would be more likely to insist on compliance with
ANSI standards, which the last time I looked called for unassigned cells.
If T1.646 has recently been revised to specify idle cells, then I'd change
my advice and recommend using idle cells by default in all markets.  Does
someone with a recent copy of T1.646 care to comment on this?

Mike
--
C. M. Heard/VVNET, Inc.
heard@vvnet.com