Subject: Fwd: Comments on the Draft AtomMib Specification

From: Kaj Tesink <[email-masked]>
Date: Tue, 24 Nov 1998 21:53:03 +0000

Kevin,

I'm copying your questions and observations to
the [email-masked] list which is the
best place to discuss the issues you raise.
Please subscribe if not yet done so.

On a procedural note, the atm draft has already
been completed and is in being processed by the IESG now.

The issues you raise all concern proposed additions to the
current spec. However, given the status of the spec
any additions will have to be included in some additional 
specification.

Any comments from the list on Kevin's Issues?
Pl copy Kevin also directly as I'm unsure of his 
subscription status.

Kaj

>X-Station-Sent-From: joker.bellcore.com
>Sender: [email-masked]
>Date: Mon, 16 Nov 1998 10:58:21 -0500
>From: knolish <[email-masked]>
>X-Mailer: Mozilla 4.06 [en] (X11; U; Linux 2.0.34 i686)
>To: [email-masked]
>Subject: Comments on the Draft AtomMib Specification
>
>
>I have to support some new chips that map ATM cell streams onto DS3.
>Unfortunately, the AtomMib as it stands and the latest draft that I've
>examined have a number of shortcomings that the current AtomMib has
>with respect to managing ATM physical layer chips that map ATM cells
>onto a DS3 stream.
>
>The draft that I examined is
>
>draft-ietf-atommib-atm1ng-05.txt Tues Oct 13 18:33:27
>
>Please look this over and let me know if you think that it would
>be a reasonable addition to the AtomMib.
>
>thanks,
>
>Kevin Nolish
>[email-masked]
>
>Issue 1
>-------
>
>There needs to be a way to specify the cell mapping used
>by a particular DS3 interface.
>
>There are two different mechanisms defined in the standards for
>mapping ATM cells into a DS1/DS3 stream.  These are the direct mapping
>method and plcp framing method.  There needs to be a way to configure
>the interface with the appropriate method.
>
>I propose the following addition to the MIB to support configuring
>these interfaces:
>
>dsx3AtmCellMappingMode OBJECT-TYPE
>    SYNTAX        Integer (
>                      plcp(1)
>                      direct(2)
>                   )
>    MAX-ACCESS    read-write
>    STATUS        current
>    DESCRIPTION
>          "This variable represents the current mapping mode
>           used by DS3/E3 interfaces that insert ATM cells into
>           a DS3/E3 stream.
>
>	   The values are:
>
>           plcp(1) The interface is using plcp mapping as per
>                      DS3 - af-phy-0054.00 [1]
>		      E3  - ETSI-300-270   [2]
>           direct(2) The interface is using direct mapping as per
>                      ITU-T Recommendation G.804"
>
>Issue 2
>-------
>
>There needs to be a way to specify ATM cells inserted into empty time
>slots by the framer when no outgoing ATM cell payloads are available.
>
>ATM physical interfaces always send cells.  If there is no available
>data, then either IDLE or UNASSIGNED atm cells are sent.  Depending
>upon the phy chip, either IDLE or UNASSIGNED cells can be selected, or
>some phys allow more general bit patterns to be set in the cell
>header.
>
>As a minimum, I think that a two-valued field would suffice.  This
>would cover all of the DS3 framers that I know about.  Some devices
>allow a more complete specification of the header bits.  A 4 byte long
>octet string would allow these devices to be completely configured.
>
>I'm leaning towards the two-valued field on the minimalistic hardware
>dependency approach.
>
>
>ds3AtmCellStuffingMode  OBJECT-TYPE
>     SYNTAX        Integer (
>                      idle (1)
>                      unassigned (2)
>                    )
>     MAX-ACCESS     read-write
>     STATUS         current
>     DESCRIPTION    "This variable represents the current type of
>                     ATM cell inserted into empty outgoing time
>                     slots by the DS3 cell mapper.  IDLE and UNASSIGNED

>                     cell formats are defined in [3].  The header bytes
>                     are
>                                    Cell  Header Octet
>                                    1       2        3        4
>                     idle       00000000 00000000 00000000 0000xxx0
>                     unassigned xxxx0000 00000000 00000000 0000xxx1"
>
>
>Issue 3 
>-------
>
>There needs to be a way to get at per-cell statistics in a DS3 mapping
>interface.  All of the DS3 Phy chips that I've seen support these
>statistics.
>
>txCellCount
>rxCellCount
>rxCellCorrectableHcsErrors
>rxCellUncorrectableHcsErrors
>rxCellLossOfCellDeliniation
>
>These should all be defined as 32 bit counters.
>
>References
>----------
>
>
>[1]  DS3 Physical Layer Interface Specification
>     af-phy-0054.000
>     The ATM Forum Technical Committee
>     July 1996
>
>NOTE:
>     Strictly speaking, this document isn't a standard.  It
>     references various ANSI and ITU standards that define the
>     cell mapping function.
>
>     The chip manuals refer to it, so I figure it's probably 
>     as good a reference as any.
>
>[2]  I haven't tracked down the full reference for this standard
>     yet.  Basically, there are two E* standards that define the
>     mapping of ATM cells onto E* systems
>
>     E1 Rate - ETSI-300-269
>     E3 Rate - ETSI-300-270
>                            
>[3]  User-Network Interface (UNI) Specification
>     Version 3.1
>     The ATM Forum Technical Committee
>     September 1994
>
>     ( Probably need to update this to UNI 4.0 )
> 

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Bellcore
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
       Red Bank, NJ 07701
       USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Gary Hanson <[email-masked]>
Date: Wed, 25 Nov 1998 10:23:48 -0800 (PST)

Hi Kaj and Kevin,

I've got some comments for you below....

Regards,
Gary

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333

> any additions will have to be included in some additional 

Agreed.

> >                      ITU-T Recommendation G.804"

I assume many fielded agents already have this configurability
implemented in enterprise MIBs, so they wouldn't need a new,
standard object to do the same thing.  However, it couldn't hurt
to have a standard object for new and existing agents to share, and
to allow for standard-based CNM configurability.

However, I'd add it to the atmInterfaceExtTable in the ATM2-MIB,
which takes care of a number of configurable items that were
missing in the ATM-MIB.  I'd also name it atmIntfCellMappingMode,
or something similar, since the choice of direct mapping vs. PLCP
framing applies to more than just DS3 interfaces (as you noted, they
also apply to DS1, so does not make much sense to me to name the
object and describe it as if it only applies to DS3).

> >slots by the framer when no outgoing ATM cell payloads are available.

This seems like overkill.  Could you give me an example of when it
is important to do cell rate decoupling with any cell other than the
Unassigned cell indication (00000000 00000000 00000000 0000xxx0)?

> >octet string would allow these devices to be completely configured.

Even if a chip has infinite configurability, what is the value to
be gained by adding a standard object to configure it?

> >I'm leaning towards the two-valued field on the minimalistic hardware

I'd lean in the direction of leaving it out altogether, unless the
value of configurability were demonstrated.

> >                     unassigned xxxx0000 00000000 00000000 0000xxx1"

Umm, these formats don't look right to me.  The one shown as "idle"
is what I would call "unassigned", and the one shown as "unassigned"
is what I would call "invalid pattern" (according to Figure 3-7 in
section 3.4.3 of UNI 3.1, which is cited as [3] above).

What figure of what document did these formats come from?

> >interface.  All of the DS3 Phy chips that I've seen support these

The above are counted via ifInOctets and ifOutOctets and dividing
by 53.  I don't think we need additional standard objects for
these.  (See section 7.2.1 of the atm1ng-05 draft.)

> >rxCellCorrectableHcsErrors

This might be nice to have, but do we need to count all possible
events using standard counters?

> >rxCellUncorrectableHcsErrors

The above is counted by ifInErrors.

> >rxCellLossOfCellDeliniation

What would be counted by this object, the number of times the LCD
occurred?  The presence of "Cell" after "rx" led me at first to
think it counted cells of some sort.

> >These should all be defined as 32 bit counters.

The ifInOctets and ifOutOctets counters also have their 64 bit
counterparts for the faster interfaces.