CURRENT_MEETING_REPORT_
Reported by Kaj Tesink/Bellcore
Minutes of the ATM MIB Working Group (ATOMMIB)
Ted Brunner kindly volunteered to take notes for these minutes.
ATM MIB(s) Work
Status
A draft has been posted and discussed on the mailing list for some time.
The scope is beyond that of ATM Forum's ILMI MIB, which is limited on
local interface. A new version of the ILMI MIB will have address
registration, and some minor polishing.
It has been suggested to maintain, as much as possible, ILMI
compatibility and semantics. However, given the larger scope of the
IETF ATM MIB, some differences will be unavoidable.
Discussion followed on Bellcore's proposed draft MIB.
Use of ifTable for ATM Interfaces
The central point in this discussion was how the ATM protocol stack must
be represented with ifEntries. The resolution was that the following
ifEntries are necessary:
o One ifEntry for the general ATM layer.
o no ifEntries for ATM VC or VP interfaces (this follows the current
recommendation of the IFMIB Working Group, and avoids unnecessary
ifEntry proliferation and implied performance statistics per
VP/VC).
o One ifEntry for all combined AAL3/4 and AAL5 interfaces
(convergence sublayer).
o One ifEntry for all combined AAL1 and AAL2 interfaces (convergence
sublayer).
The specific mapping of ATM parameters to ifEntry objects was not
discussed but is already included in the MIB draft.
The Need for ATM Local Interface Configuration
Reference in the MIB draft: atmInterfaceConfTable. Some small changes
were suggested and agreed:
o The objects atmInterfaceTransmissionType and atmInterfaceMediaType
are now redundant (the ATM MIB should only be concerned with the
ATM layers),
o The atmInterfaceIlmiVpiVci requires fixing in the definition
(range) and description (how it is used),
o A discussion took place on the need to include objects for the
maximum number of PVCs and SVCs that can be used. This discussion
was deferred to the mailing list. The meaning of
atmInterfaceConfVxc was questioned (for PVC or SVC). It was agreed
not to clarify the particular use of this object unless the ATM
Forum does detail its definition.
The Need for ATM Local Interface Statistics
These statistics are now represented by an ifEntry. No further
statistics were felt necessary.
The Need for ATM Local Interface Statistics Per VCC/VPC
The draft MIB proposes for each VC and VP interface a counter for the
number of received and transmitted cells, and the number of discards due
to traffic policing and shaping. These statistics could, for example,
be used to detect congestion and configuration problems. Other
suggestions were not to include these statistics at all for VC or VP
interfaces, suggesting that hardware costs outweigh the benefits. Still
another suggestion was to have a different conformance statement for
public and private interfaces (i.e., public interfaces do have these
statistics, and private interfaces do not). Keith McCloghrie suggested
a compromise, i.e., to define a test capability that can measure these
statistics for specific VP and VC interfaces for a short amount of time.
Kaj Tesink will produce a draft, which will be discussed on the mailing
list.
The Need for Physical Level Convergence Level Management
The current draft MIB specifies managed objects for the DS3 PLCP, and
for the SONET TC. The contents of the corresponding tables were reviewed
and agreed to. Discussion focused on whether these tables belonged in
the ATM MIB or in the DS3 and SONET MIBs respectively. For practical
reasons it was decided to keep them in the ATM MIB. Convergence layers
for other types of physical facilities were not identified but could be
added as needed.
The Need for AAL Management
Management of the AAL layer was decided to be performed via ifTable (see
item b). As a result of this discussion the draft atmAalPointerTables
are now redundant and can be removed.
The Need for ATM Connection Management
A more lengthy discussion took place on this subject. In addition, Ken
Rodemann gave a presentation on a generic approach to the management of
virtual connections, suggesting a common approach for Frame Relay, X.25,
and ATM. The generic approach would serve as a sort of umbrella over
connection tables that are specific to the X.25, Frame Relay, or ATM.
The contents of the specific tables would not be affected by adoption of
the generic approach. Rather, the specific approach would simplify the
overall management of connections. Discussion of this topic was, due to
lack of time, deferred to the FRNETMIB and IFMIB Working Group meetings.
On the specifics of the connection table, the following points were
discussed:
o It was agreed that a connection table should work for both
end-systems and intermediate-systems.
o The desire to maintain commonality with the ILMI MIB was expressed.
It was also observed that the ILMI MIB does not have a connection
table (not in its scope), and that the draft table caused only a
difference in OID values for traffic parameters.
o The proposed draft makes the point of allowing the creation of a
new association between an ingress and egress with a single table
row.
o A connection table would benefit considerably from a rowStatus
column as defined in the SNMPv2 TC.
Keith McCloghrie and Ted Brunner were tasked to review connection table
alternatives, and post their findings to the mailing list for
discussion.
The Need for SVC Management
Due to lack of time, network management needs for SVCs were not
discussed. However, a discussion took place on the scope of the
connection table. In general, the observation was supported that the
connection table should not state whether it applies to SVCs and/or
PVCs, leaving it to implementation as to how the table is applied.
See also section, "The Need for ATM Local Interface Configuration,"
for another SVC related issue.
Any Other ATM MIB Needs
None were identified.
SONET MIB Work
The issues discussed had been previously raised on the mailing list. In
addition, the particular use of ifTable was discussed.
Status
The existing Internet-Draft has been kept highly compatible with other
trunk MIBs. Only minor comments have been made on the mailing list.
Editorial Items
o Some ranges in status objects contain typos.
o ``other'' should be included in some enumerated lists
o Language on SDH should be clarified.
o The label ``photonic'' should be changed, since it also applies to
electrical interfaces.
The Need for Interval and Total Tables
The mailing list has pointed out that strictly speaking, these tables
are redundant, since they can be deduced from the Current and first
Interval tables. It was suggested to delete the Total tables, and leave
the number of supported Interval tables as implementation specific. One
suggestion was made to support at least an hour's worth of Interval
tables. Another value that was suggested was eight hours. Given that
some implementations of these tables may already exist, confirmation of
this approach will be sought on the mailing list.
Use of ifTable
This item was reviewed briefly. The conclusion was to have ifEntries as
follows:
o One ifEntry for the combined SONET photonic, section and line
layers for a particular port,
o One ifEntry for each SONET path (if used on that port),
o One ifEntry for each SONET VT (if used on that port)
A new version of the MIB will be posted that accommodates above points.
Since not all parts of the MIB do apply to each SONET interface, it is
important to specify a precise conformance statement. The new version
of the MIB will include this.
Attendees
Masuma Ahmed mxa@sabre.bellcore.com
David Arneson arneson@ctron.com
Anders Baardsgaad anders@cc.uit.no
Cynthia Bagwell cbagwell@gateway.mitre.org
Nutan Behki Nutan_Behki@qmail.newbridge.com
Tracy Brown tacox@mail.bellcore.com
Theodore Brunner tob@thumper.bellcore.com
Jeff Case case@cs.utk.edu
Chris Chiotasso chris@andr.ub.com
Jonathan Davar jdavar@synoptics.comm
David Engel david@ods.com
Michael Erlinger mike@jarthur.claremont.edu
David Fresquez fresquez@vnet.ibm.com
Mike Goguen goguen@synoptics.com
Juha Heinanen juha.heinanen@datanet.tele.fi
Steven Horowitz witz@chipcom.com
Jeff Hughes jeff@col.hp.com
Carl Madison carl@startek.com
Andrew Malis malis@maelstrom.timeplex.com
Keith McCloghrie kzm@hls.com
George Mouradian gvm@arch3.att.com
Zbigniew Opalka zopalka@agile.com
David Perkins dperkins@synoptics.com
Drew Perkins ddp@fore.com
James Reeves jreeves@synoptics.com
Kenneth Rodemann krr@qsun.att.com
Dan Romascanu dan@lannet.com
Hal Sandick sandick@vnet.ibm.com
Jon Saperia saperia@tay.dec.com
Jean-Bernard Schmitt jbs@vnet.ibm.com
Dono van-Mierop dono_van_mierop@3mail.3com.com
James Watt james@newbridge.com
Steven Willis steve@wellfleet.com