home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / atommib / atommib-minutes-93jul.txt < prev    next >
Text File  |  1993-09-24  |  9KB  |  260 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Kaj Tesink/Bellcore
  5.  
  6. Minutes of the ATM MIB Working Group (ATOMMIB)
  7.  
  8. Ted Brunner kindly volunteered to take notes for these minutes.
  9.  
  10.  
  11.  
  12. ATM MIB(s) Work
  13.  
  14. Status
  15.  
  16. A draft has been posted and discussed on the mailing list for some time.
  17. The scope is beyond that of ATM Forum's ILMI MIB, which is limited on
  18. local interface.  A new version of the ILMI MIB will have address
  19. registration, and some minor polishing.
  20.  
  21. It has been suggested to maintain, as much as possible, ILMI
  22. compatibility and semantics.  However, given the larger scope of the
  23. IETF ATM MIB, some differences will be unavoidable.
  24.  
  25. Discussion followed on Bellcore's proposed draft MIB.
  26.  
  27.  
  28. Use of ifTable for ATM Interfaces
  29.  
  30. The central point in this discussion was how the ATM protocol stack must
  31. be represented with ifEntries.  The resolution was that the following
  32. ifEntries are necessary:
  33.  
  34.  
  35.    o One ifEntry for the general ATM layer.
  36.  
  37.    o no ifEntries for ATM VC or VP interfaces (this follows the current
  38.      recommendation of the IFMIB Working Group, and avoids unnecessary
  39.      ifEntry proliferation and implied performance statistics per
  40.      VP/VC).
  41.  
  42.    o One ifEntry for all combined AAL3/4 and AAL5 interfaces
  43.      (convergence sublayer).
  44.  
  45.    o One ifEntry for all combined AAL1 and AAL2 interfaces (convergence
  46.      sublayer).
  47.  
  48.  
  49. The specific mapping of ATM parameters to ifEntry objects was not
  50. discussed but is already included in the MIB draft.
  51.  
  52.  
  53.  
  54. The Need for ATM Local Interface Configuration
  55.  
  56. Reference in the MIB draft:  atmInterfaceConfTable.  Some small changes
  57. were suggested and agreed:
  58.  
  59.  
  60.    o The objects atmInterfaceTransmissionType and atmInterfaceMediaType
  61.      are now redundant (the ATM MIB should only be concerned with the
  62.      ATM layers),
  63.  
  64.    o The atmInterfaceIlmiVpiVci requires fixing in the definition
  65.      (range) and description (how it is used),
  66.  
  67.    o A discussion took place on the need to include objects for the
  68.      maximum number of PVCs and SVCs that can be used.  This discussion
  69.      was deferred to the mailing list.  The meaning of
  70.      atmInterfaceConfVxc was questioned (for PVC or SVC). It was agreed
  71.      not to clarify the particular use of this object unless the ATM
  72.      Forum does detail its definition.
  73.  
  74.  
  75.  
  76. The Need for ATM Local Interface Statistics
  77.  
  78. These statistics are now represented by an ifEntry.  No further
  79. statistics were felt necessary.
  80.  
  81.  
  82.   
  83. The Need for ATM Local Interface Statistics Per VCC/VPC
  84.  
  85. The draft MIB proposes for each VC and VP interface a counter for the
  86. number of received and transmitted cells, and the number of discards due
  87. to traffic policing and shaping.  These statistics could, for example,
  88. be used to detect congestion and configuration problems.  Other
  89. suggestions were not to include these statistics at all for VC or VP
  90. interfaces, suggesting that hardware costs outweigh the benefits.  Still
  91. another suggestion was to have a different conformance statement for
  92. public and private interfaces (i.e., public interfaces do have these
  93. statistics, and private interfaces do not).  Keith McCloghrie suggested
  94. a compromise, i.e., to define a test capability that can measure these
  95. statistics for specific VP and VC interfaces for a short amount of time.
  96. Kaj Tesink will produce a draft, which will be discussed on the mailing
  97. list.
  98.  
  99.  
  100. The Need for Physical Level Convergence Level Management
  101.  
  102. The current draft MIB specifies managed objects for the DS3 PLCP, and
  103. for the SONET TC. The contents of the corresponding tables were reviewed
  104. and agreed to.  Discussion focused on whether these tables belonged in
  105. the ATM MIB or in the DS3 and SONET MIBs respectively.  For practical
  106. reasons it was decided to keep them in the ATM MIB. Convergence layers
  107. for other types of physical facilities were not identified but could be
  108. added as needed.
  109.  
  110.  
  111. The Need for AAL Management
  112.  
  113. Management of the AAL layer was decided to be performed via ifTable (see
  114. item b).  As a result of this discussion the draft atmAalPointerTables
  115. are now redundant and can be removed.
  116.  
  117.  
  118. The Need for ATM Connection Management
  119.  
  120. A more lengthy discussion took place on this subject.  In addition, Ken
  121. Rodemann gave a presentation on a generic approach to the management of
  122. virtual connections, suggesting a common approach for Frame Relay, X.25,
  123. and ATM. The generic approach would serve as a sort of umbrella over
  124. connection tables that are specific to the X.25, Frame Relay, or ATM.
  125. The contents of the specific tables would not be affected by adoption of
  126. the generic approach.  Rather, the specific approach would simplify the
  127. overall management of connections.  Discussion of this topic was, due to
  128. lack of time, deferred to the FRNETMIB and IFMIB Working Group meetings.
  129.  
  130. On the specifics of the connection table, the following points were
  131. discussed:
  132.  
  133.  
  134.    o It was agreed that a connection table should work for both
  135.      end-systems and intermediate-systems.
  136.  
  137.    o The desire to maintain commonality with the ILMI MIB was expressed.
  138.      It was also observed that the ILMI MIB does not have a connection
  139.      table (not in its scope), and that the draft table caused only a
  140.      difference in OID values for traffic parameters.
  141.  
  142.    o The proposed draft makes the point of allowing the creation of a
  143.      new association between an ingress and egress with a single table
  144.      row.
  145.  
  146.    o A connection table would benefit considerably from a rowStatus
  147.      column as defined in the SNMPv2 TC.
  148.  
  149.  
  150. Keith McCloghrie and Ted Brunner were tasked to review connection table
  151. alternatives, and post their findings to the mailing list for
  152. discussion.
  153.  
  154.  
  155. The Need for SVC Management
  156.  
  157. Due to lack of time, network management needs for SVCs were not
  158. discussed.  However, a discussion took place on the scope of the
  159. connection table.  In general, the observation was supported that the
  160. connection table should not state whether it applies to SVCs and/or
  161. PVCs, leaving it to implementation as to how the table is applied.
  162.  
  163. See also section, "The Need for ATM Local Interface Configuration," 
  164. for another SVC related issue.
  165.  
  166.  
  167. Any Other ATM MIB Needs
  168.  
  169. None were identified.
  170.   
  171.  
  172.  
  173. SONET MIB Work
  174.  
  175. The issues discussed had been previously raised on the mailing list.  In
  176. addition, the particular use of ifTable was discussed.
  177.  
  178.  
  179. Status
  180.  
  181. The existing Internet-Draft has been kept highly compatible with other
  182. trunk MIBs.  Only minor comments have been made on the mailing list.
  183.  
  184.  
  185. Editorial Items
  186.  
  187.  
  188.    o Some ranges in status objects contain typos.
  189.    o ``other'' should be included in some enumerated lists
  190.    o Language on SDH should be clarified.
  191.    o The label ``photonic'' should be changed, since it also applies to
  192.      electrical interfaces.
  193.  
  194.  
  195. The Need for Interval and Total Tables
  196.  
  197. The mailing list has pointed out that strictly speaking, these tables
  198. are redundant, since they can be deduced from the Current and first
  199. Interval tables.  It was suggested to delete the Total tables, and leave
  200. the number of supported Interval tables as implementation specific.  One
  201. suggestion was made to support at least an hour's worth of Interval
  202. tables.  Another value that was suggested was eight hours.  Given that
  203. some implementations of these tables may already exist, confirmation of
  204. this approach will be sought on the mailing list.
  205.  
  206.  
  207. Use of ifTable
  208.  
  209. This item was reviewed briefly.  The conclusion was to have ifEntries as
  210. follows:
  211.  
  212.  
  213.    o One ifEntry for the combined SONET photonic, section and line
  214.      layers for a particular port,
  215.    o One ifEntry for each SONET path (if used on that port),
  216.    o One ifEntry for each SONET VT (if used on that port)
  217.  
  218.  
  219. A new version of the MIB will be posted that accommodates above points.
  220. Since not all parts of the MIB do apply to each SONET interface, it is
  221. important to specify a precise conformance statement.  The new version
  222. of the MIB will include this.
  223.  
  224.  
  225. Attendees
  226.  
  227. Masuma Ahmed             mxa@sabre.bellcore.com
  228. David Arneson            arneson@ctron.com
  229. Anders Baardsgaad        anders@cc.uit.no
  230. Cynthia Bagwell          cbagwell@gateway.mitre.org
  231. Nutan Behki              Nutan_Behki@qmail.newbridge.com
  232. Tracy Brown              tacox@mail.bellcore.com
  233. Theodore Brunner         tob@thumper.bellcore.com
  234. Jeff Case                case@cs.utk.edu
  235. Chris Chiotasso          chris@andr.ub.com
  236. Jonathan Davar           jdavar@synoptics.comm
  237. David Engel              david@ods.com
  238. Michael Erlinger         mike@jarthur.claremont.edu
  239. David Fresquez           fresquez@vnet.ibm.com
  240. Mike Goguen              goguen@synoptics.com
  241. Juha Heinanen            juha.heinanen@datanet.tele.fi
  242. Steven Horowitz          witz@chipcom.com
  243. Jeff Hughes              jeff@col.hp.com
  244. Carl Madison             carl@startek.com
  245. Andrew Malis             malis@maelstrom.timeplex.com
  246. Keith McCloghrie         kzm@hls.com
  247. George Mouradian         gvm@arch3.att.com
  248. Zbigniew Opalka          zopalka@agile.com
  249. David Perkins            dperkins@synoptics.com
  250. Drew Perkins             ddp@fore.com
  251. James Reeves             jreeves@synoptics.com
  252. Kenneth Rodemann         krr@qsun.att.com
  253. Dan Romascanu            dan@lannet.com
  254. Hal Sandick              sandick@vnet.ibm.com
  255. Jon Saperia              saperia@tay.dec.com
  256. Jean-Bernard Schmitt     jbs@vnet.ibm.com
  257. Dono van-Mierop          dono_van_mierop@3mail.3com.com
  258. James Watt               james@newbridge.com
  259. Steven Willis            steve@wellfleet.com
  260.