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
- Gauge interest in creating a standards-track MIB
- Determine the priority of the areas for MIB objects
- Identify existing work in proprietary MIBs that can be used as starting point
- Select working group chair and document editor
- Determine if an interim meeting is needed before the next IETF meeting in March.
Agenda
- Agenda Review/Update (5 minutes)
- Description the devices that would be managed with the GR-303 MIB
- Overview of CMIP GR-303 MIB
- Description of existing IETF MIBS that can be used to manage some aspects, such as DS1 and IF MIBs
- Description of any existing proprietary MIBS
[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:
- Identify minimal set of objects needed to support analog lines.
- Use IETF standards-track objects and information model, specifically the interface MIB in RFC2233, the DS1 MIB in RFC2495, and the DS3 MIB in RFC2496, the Entity MIB in RFC2037 (soon to be updated).
- Optional GR-303 object will be considered later if needed, such as ISDN, testing, and private line objects.
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.
- It might be better not to proceed until the European standard (V5?) is better defined. (This standard is based off of an ITU specification.)
- There are now several proprietary management interfaces. We need to standardize on a management interface.
- It sounds like there are additional features and requirements for GR-303. Sounds like there are additional requirements beyond GR-303. Do we need to have something more than this? No. In IETF documents, we try to specify a minimal subset that will satisfy everyone, then look at doing additional work.
- GR-303 was designed for local loop support of RDT. This does not necessarily map to drop-side management of RDT. This is where SNMP comes into the picture.
- There is the perception that there are items beyond the scope of GR-303 that should be addressed in this meeting. Yes, specifically since GR-303 is defined as RDT to switch protocol, rather than line-side management protocol. The idea is that later we might be able do line side management of the switch, too. So GR-303 is a good starting point.
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.
- It is important to look at voice gatewaying. It is important to know the current status and the setup that each line has been provisioned with, so you know what GR-303 has set up up when you map your voice to IP. You need to know status of the GR303, which you can do with read-only information, and take appropriate action.
Action item: Determine whether or not the MIB will have read-write objects.
- What we are going to do here does not obviate the need for traditional GR-303 control.
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:
- A distinction needs to be made between managing the RDT and managing the IDLC (term not explained). How one manages IDLC should be explored, since this is not expressed in the EOC.
- An IDLC exists on an RDT. This should be addressed in charter.
- Charter should include text indicating that we will resolve V5 concerns. This should go to the mailing list.
- Need to verify that we want to restrict work to GR-303.
- Should we do an analog line table? Consensus is yes. Perhaps two MIB modules should be created.
Proposed Delivery Dates:
- Before next IETF, create Internet Draft and review on mailing list
- Meet at next IETF and resolve issues
- Forward Internet Draft to AD by May
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.