2.4.14 GR-303 MIB (gr303) bof

Current Meeting Report

Operations and Management Area
GR-303 BOF: Creating an IETF Standards Track SNMP MIB for GR-303
46th IETF, Washington DC, USA
November 11, 1999 9 AM

The purpose of this meeting is to judge interest in creating a standards-track MIB for GR-303 MIB objects.

Leader: David Perkins
Reported by: Steve Moulton

The purposes of this BOF are to


[there was an additional item missed in the slide change]

GR-303 (GeneRal environment-303) is a specification published by Telcordia, which defines the physical and logical interfaces between a class 5 phone witch and a remote data terminal. This specification includes in band management of the remote data terminal (RDT) using CMIP over LAPD on a DS0. The GR-303 has an about 1 inch thick MIB specification, but not much of it is implemented in practice. The operator connects to the class 5 switch to do in band management, and uses TL1 to communicate with the RDT.

In the past there has been little IP involved, thus no need for SNMP. On the new class of RDT devices there is often IP out bound from the RDT, so the RDT has an IP stack and connects to the IP network.

In the current management framework, GR-303 specifies use of in band management between an IDT [term not explained] and RDT using two DS0 channels. The management protocol is CMIP over LAPD. There are many objects (and associated attributes, actions, and notifications) specified in GR-303, but not all are used. Most RDTs also have a proprietary management interface (craft interface) such as TL1-like commands to an ASCII terminal.

The intent of this effort is to leverage work already done for GR-303. Since CMIP-SNMP MIB translations do not generally go smoothly, the intent is to identify the minimal subset of MIB objects needed to effectively manage the RDT, rather than just translate current instrumentation. This effort will also focus on using already defined standards track MIBS where appropriate.

In this effort, nothing will be done for the Class 5 switch side. In the long term it would be good to have switch-side support for SNMP. This is seen as being mostly of interest to smaller switch vendors. The CMIP interface on the class 5 switch is likely to remain in place.

The priorities for this effort are as follows:

At this point a fairly detailed presentation of the GR-303 Management Information Model was given. The presentation described a subset of the generic model required by the Lucent 5ESS switch. This large model was explained in some detail, best understood by viewing the slides. Of most significance was the explanation of the base objects, how they are inherited, and some of the features provided on the customer side (POTS, ISDN, etc). There was no assertion made that all of these need representation in the SNMP MIB. Also, the point was made that the set of objects that might be defined might not all be instantiated in a less advanced RDT.

The following points were brought up in the discussion.

David Perkins: Maybe this is my fault for not clarifying what we want to do. In IETF, when we want to manage a device, there is not a device MIB per se (e.g., a "router MIB"), there is a collection of MIBs to manage the device. This working group is to discuss the set of objects we have in this device. The DS1 MIB includes all of the needed DS1 objects. In the GR-303 MIB there is a equipment object. The entity MIB can be used for the same thing. The purpose of this MIB is to only cover what is covered by the GR-303 specification.

Action item: Determine whether or not the MIB will have read-write objects.

Yes. That is only way to provision lines. The EOC [not defined] is used in a very controlled way - you can do on line provisioning. I doubt anyone is going to extend it. No one is going to emulate the Northern Telecom or Lucent interface.

At this point, a handout and slide was presented with a proposed set of objects.

Discussion centered on how much control to allow the SNMP interface (whether or not you can take an analog line out of service), and whether SNMP should be usable for provisioning, or just for monitoring. There is some feeling that the current RDT-switch protocol is not sufficient, and discussion about whether this should be fixed via SNMP or via fixing the RDT-switch protocol. The point was raised that GR-2833 permits management of the RDT with CMIP, but many companies don't want to put the OSI stack in their devices. There is an interest in getting SNMP used in place of GR-2833 (or craft interface).

GR-2833 was supposed to replace EOC eventually, but this has never happened and probably never will. It is nice model, but big. It is not realistic to think it can be implemented in RDTs with limited processing power.

The next agenda item is the discussion of proprietary MIBS. Work has been done by TollBridge Technologies, Anda and others. At this point, the TollBridge MIB cannot be made public, but a brief discussion follows.

There are some modeling problems with the GR-303 MIB (discovered in TollBridge work while doing CMIP agent). TollBridge replaced some models in GR-303 with simpler models. They are using the DS1 MIB. For cross-connecting logical to physical DS1 a proprietary MIB has been developed, as was as for analog line association. They could use standard SNMP notifications, so they will develop a MIB that will probably map to to the GR-303 MIB to support notifications from GR-303. The MIB is relatively small, and can do both monitoring as well as configuration. They are shadowing GR-303 as much as is practical when it comes to mapping alarms to SNMP notifications. The implementation was done as a core information manager (resource manager) with various interfaces (CMIP, craft, SNMP, HTTP, CORBA, whatever) in the future.

Another speaker mentioned the desire to put SNMP controllability in the CPE (customer premises equipment) as well as in the RDT, and make everything from the RDT on out SNMP-manageable. At this point much of the discussion became too detailed for reasonable inclusion in the minutes.

The discussion then moved to what direction should be taken from here. The consensus is that there is sufficient interest to go forward. The following comments were made on the proposed charter:

Proposed Delivery Dates:

It is suggested that the analog line MIB be a separate document, and that the word analog not show up in the working group name. It is also suggested that if there is an interim meeting before the next IETF, a working group consensus on an Internet Draft can be reachable by May. Most work should be done over the mailing list.

Volunteers were requested for reviewing documents. Six hands were raised.

David Perkins is willing to be document editor, but a working group chairman is needed. Bert Wijnen suggested co-chairs, one from the telecom community and one familiar with the IETF process. A telecom community volunteer (Scott, did not get last name) volunteered given that his work responsibilities permit. Steve Moulton volunteered as the other working group co-chair, given work responsibilities permit.


None received.