13.3. Protocols for Systems Management

There are a number of standardized protocols for conveying telecommunications management information and performing management functions. These protocols have varying levels of penetration in the industry and have differing capabilities in implementing the information models outlined earlier. The following is a brief description of the most widely used protocols. The reader may consult the references for more in-depth information.

13.3.1. Transaction Language 1

Transaction language 1 (TL1) is a command string based protocol developed by BellCore (now Telcordia) in 1984. Since it is based on ASCII string commands, it can be used both for human-to-machine communication and for machine-to-machine communication. Although it is one of the older telecommunications management protocols, TL1 is still quite popular. One reason for this is that it is used as an interface between existing network equipment and existing operation support systems (OSS). A TL1-based management interface is usually required in equipment to be sold to U.S. Regional Bell Operating Companies (RBOCs).

TL1 supports the two basic modes of operations needed in a management protocol, that is, command/response interactions and the generation of autonomous events. Since TL1 messages are “human readable,” it is also frequently used as a standard command line interface (CLI) for equipment management.

13.3.1.1. THE BASIC TL1 COMMAND MESSAGE FORMAT

The format of the TL1 command message is shown below:

command_code:staging_block::parameters_block;

Each of these fields is an ASCII string, subject to specific formatting rules. Command_code typically takes the form, “Verb-Modifier-Modifier”, where the modifiers are optional. Due to TL1's historical lineage, the command codes tend to be cryptic. For example, common “verbs” are DLT (delete the object), ENT (enter or create the object), ED (Edit object properties), and RTRV (retrieve object info).

Staging_block has the form <TID>:<AID>:<CTAG>, where TID is the target identifier, that is, indicates the network element to receive this command, AID is the access identifier, that is, indicates the managed object within the network element to be acted upon, and CTAG is the “correlation tag” entered by the user. This tag is returned in the response by the system, so that a command and the response can be correlated.

Finally, as one might guess, the parameter block is where all the required or optional parameters of a command belong.

Example: Creating connection end points

Before a switch can set up a cross-connection, the end points of the connection have to be established. These are appropriately referred to as connection termination points (CTPs). One possible TL1 command for setting up an STS-3c CTP could be:

ENT-STS3C:MY-BOX1:A-7-3-1:REF137::NAME=CTP1;

Here, the TID field contains “MY-BOX1,” the format of AID used by this manufacturer is <shelf>-<slot>-<subslot>-<timeslot> (A-7-3-1), “REF137” is the correlation tag, and the “NAME=CTP1” is the parameter that gives the CTP a name so that it may be used in other commands. Not shown are a host of optional parameters that may take on default values, for example, integration time on loss of pointer until an alarm is issued, and so on.

If another STS-3c CTP has to be created on a different line card, the following command can be issued:

ENT-STS3C:MY-BOX1:C-6-2-4:REF138::NAME=CTP2;

This command sets up an STS-3c end point in <shelf = C, slot = 6, sub-slot = 2, time slot = 4>.

The following command retrieves the parameters of CTP1:

RTRV-STS3C:MY-BOX1:CTP1::;

Example: Creating a cross connection

The following command can be used to create a cross-connection between the CTPs created above:

ENT-CRS-STS3C:MY-BOX1: CTP1, CTP2: REF139 ::NAME =CRS1, FROMTYPE = CTP, TOTYPE = CTP;

13.3.2. The Simple Network Management Protocol

The simple network management protocol (SNMP) is very popular in data networks, but it is not used much in optical transport networks. SNMP is intended for machine-to-machine interaction, between an “agent” on a network element, say, and a management station. SNMP is currently in its third incarnation [Case+99], with the first version appearing around 1988 [Rose96]. The SNMP framework has four main aspects:

The fourth piece on security is new in SNMPv3 and has been a source of considerable debate in previous versions of SNMP. SNMP is based on a fairly simple “get-set” paradigm, that is, a GET command can be used to fetch information or a SET command can be used to set a variable to a particular value. In addition, a sequence of similar data entities can be easily traversed with a GET-NEXT operator. Finally, SNMP provides a mechanism for issuing autonomous events known as traps.

Since SNMP has not been used much in transport networks, there is a scarcity of standardized MIBs for managing optical networks. At the time of this writing, only one standards track RFC at the IETF was available concerning SONET/SDH interfaces [Tesink99]. Although this MIB is published by the IETF, it is based on models and parameters defined in SONET/SDH standards. The existing MIB primarily covers performance monitoring. Because it is only concerned with SONET/SDH interfaces, it does not include items pertaining to switches as a whole, for example, creation/deletion of cross-connects.

13.3.3. The Common Management Information Protocol

ITU-T's Common Management Information Protocol (CMIP) followed SNMP in 1991. The overall framework for CMIP is similar in form to that of SNMP. CMIP, however, could probably be characterized as more “object-oriented.” With CMIP, there was a set of standards that described the object management model, the syntax for defining these managed objects, and a protocol for performing operations on these managed objects and transporting the results [ITU-T92b, ITU-T92c, ITU-T92l, ITU-T92m]. CMIP, however, has not been a success. Among the reasons for this, the first is that vendors had to include a command line interface (also referred to as a craft interface) on the network element anyway. Due to the implementation complexity of the full object-oriented management service and the protocol, TL1 or a proprietary protocol was initially used rather than CMIP. CMIP was therefore relegated to serve as a protocol between the element and network management systems. Second, the data communications world had settled on SNMP and proprietary protocols. This left a small slice of the overall management pie to CMIP, making it hard for the protocol to reach a critical mass.

13.3.4. CORBA-Based Management

CORBA is an acronym for Common Object Request Broker Architecture. This denotes a standard^[2] service and an associated protocol for making requests and receiving replies from objects on remote systems. CORBA originated in the distributed enterprise-computing context rather than in the telecommunications world. CORBA has found fairly wide acceptance within its scope of applicability, and a great deal has been written about its internals [Mowbray+97, Orfali+98]. CORBA is neutral to the hardware, the operating system, the network protocol, and the programming languages used, and therefore it can be used to glue together heterogeneous distributed systems.

^[2] CORBA is a product of the OMG. Its specification can be obtained at www.omg.org.

CORBA, like SNMP and CMIP, contains a data definition language called the Interface Definition Language (IDL), which is used to specify the interface to the communicating objects. It should be noted that the implementation of objects is system dependent, but not the interface between them. Given an IDL description of the interface to a managed object, it is necessary to (a) bind it with the actual objects within a system and (b) enable these objects for distributed communications.

To bind the interface to actual objects, the IDL description is “compiled” to produce programs in one of different languages (C, C++, Java, COBOL, etc.) to interact with the internal objects in the system. It is the job of a piece of software known as the ORB (Object Request Broker) to enable these internal objects to communicate.

With a fairly well established CORBA infrastructure in place, the bulk of the challenge in using CORBA for telecommunications management is in refining the information models and in defining interfaces for specialized telecommunications management services. For example, a telecommunication management notification service tends to have some unique properties that may differentiate it from a notification service used in general enterprise computing [TMF00].