|
|
Transaction Language 1 (TL1) is the most widely used management protocol in telecommunications Networks. It manages most of the broadband and access networks and is increasingly being used worldwide for newer management applications. Despite its low profile, TL1 today remains the only widely implemented, vendor-independent telecom management protocol.
There are three basic requirements for a management interface. With the pace of technology improvements, you must be able to develop new interfaces quickly. In addition, as new features are added to an existing element, you must be able to upgrade the management interface easily. Finally, the deployed interface must be able to keep up with the performance and usability requirements of the management systems and network elements that it connects.
As TL1 interfaces are string-based and human-readable, they can be rapidly developed and easily updated. No special decoders are needed for debugging, and new messages can be added with minimal effort. This contrasts with the complex environments required to develop and maintain other protocol interfaces, for which development cycles of nine to 12 months regularly fall behind hardware enhancements. Finally, TL1 is scalable, as shown by its ability to work with scalable management systems such as Bellcore's Network Monitoring and Analysis system.
With the continuing interest in management using TL1, there is a strong need for better tools and support for management of new and existing TL1 devices. To address this need and simplify management using TL1, WebNMS supports TL1 in a number of its products, and enables rapid delivery of carrier-class management solutions that leverage the use of the TL1 protocol.
WebNMS now provides an end-to-end management support for networks of TL1 devices, including device agent and management applications.
TL1 facilitates communication between a managed device (a device with TL1 agent), and a TL1 manager. The TL1 agent on the managed device serves to provide access to data stored in the managed device. The TL1 manager uses this access to monitor and control the managed device. TL1 protocol communicates via TCP. Data (TL1 Messages) is sent and received in the form of byte stream.
TL1 specifies four types of messages as follows :
Input Command Messages
Acknowledgment Messages
Output Response Messages
Autonomous Messages
An Input command message is a message from an OS or other sources (manager) to a Network Element (NE) i.e. an agent. The message, requests the NE to perform some action. The general structure of a TL1 input message is of the form
<command_code>:<staging_parameter_blocks>:<message_payload_block>;
Command Code
It determines the action to be taken at the NE as a result of receiving the input message. Each command must begin with a command code consisting of a mandatory verb followed by up to two optional identifiers, each separated by hyphen.
<command code> ::= <verb>[-<modifier>[-<modifiers>]]
Verb identifies the action to be taken at the NE as a result of receiving a TL1 message from an OS. The command code modifiers are optional depending upon the specific command and application domain. The first modifier identifies where the action is to be applied in the NE. The second modifier may be used to further define the identity of the object upon which the action is to be taken.
For example, a <verb>-EQPT can be used to indicate that an action, specified by the value of the verb, is to be taken on an equipment object. A <verb>-T0 indicates an action is being taken on DS0 circuit.
As another example, for switching NE's, the command <verb>-<administrative view> indicates an action is to be taken on an object entity within the specific administrative view of the switching NE database.
Another example is shown to illustrate how the second modifier is used. The command DLT-CRS-T0 will disconnect (DLT) one or more cross connected (CRS) DS0 object entities (T0).The modifier CRS is further defined to identify T0 object entities.
Staging Parameter Block
These are a series of four data blocks following the command code that provide information to establish and uniquely identify an object entity within an NE to be managed by a remote OS and to specify certain options as to how the input command is to be executed in the NE. The structure of the staging parameter blocks consists of the following series:
:[<targetidentifier>]:<accessidentifier(s)>:<correlationtag>:[<general block>]:
Each block may have one or more specifically defined parameters. The parameters within each staging block may either be position-defined or name-defined.
Target Identifier Block
An input message associated with the management of a particular object may be directly addressed to an NE or it may be routed to or through one or more intermediate NE's. The Target Identification code ( TID ) parameter block provides the capability within the TL1 message format to perform network routing tasks. The presence of the TID in all input commands is a requirement, but its value may be null (represented by two successive colons).
The TID block contains a single position-defined parameter that identifies the end-target NE to which the input command is directed. The value of TID may be any valid simple or compound TL1 identifier or text string limited to 20 characters.
Access Identifier Block
The Access Identifier (AID) block normally contains one or more parameters that uniquely identifies the entity within the target NE to be acted upon by the input message. Typical examples of entities addressed by the AID parameter values are:
Circuits and common equipment modules having hierarchical relationships.
Record entities within the context of an administrative view of the NE database.
Test session and Test Access Point aliases.
Correlation Tag (CTAG)
It contains one position defined parameter to serve as a means of correlating an input command with its associated output response. The OS assigns an arbitrary non-zero CTAG value and it is the responsibility of the NE to copy this value into the output response associated with that input command. The value of CTAG must either be a TL1 identifier or a non-zero decimal number consisting of not more than six characters.
General Block (GB)
It includes support parameters whose values affect the way in which the input command is to be executed in the NE. The presence of GB in all input commands is a requirement but its value may be null (represented by two successive colons). The form of the General Block is :
:[[<delay activation parameters>],[<contingency flag>],[<indirect data retrieval identifier>]]:
Delay Activation is a function whereby an input message may be stored in a message pending buffer at the NE for final execution at some later time. The Delay Activation function is provided by a set of parameters within the GB of the form :
[ON=]<order no.>,[DATE=]<date>,[TIME=]<time>
Contingency Flag parameter is a boolean data type within the GB that indicates, when set true, a dependent relationship among the several records specified in the AID data block of a multi-unit command. If CF is false, partial installation of the records in a multi unit message may be completed with a report sent to the OS listing the records that were not successfully installed in a database.
Indirect Data Retrieval Indicator is a functional capability by which information may be retrieved from more than one linked administrative view by a single RTRV command.
Message Payload Block
This block indicates the subject matter of the message. This section may consists of zero or more data blocks in the form.
(:<Px>(,<Px>)*)*;
Here Px represents a data item. Each data block is delimited by colons (:) and the last terminated by a semicolon (;). Each data block may have an unlimited number of data items, each delimited by commas (,). The data items within a data block may be either name-defined (<keyword>=<value>) or position-defined where values are specified and the keyword is implied by its position in the data block.
General Format
An acknowledgment is a brief output message generated in response to an input command message. An NE may optionally have the ability to turn on or off acknowledgments via a Standard input command, Custom command, or message from a local terminal. In general, an acknowledgment is later followed by an output response message to the command. However, in some circumstances, an acknowledgment is the only output message triggered by a command. An acknowledgment should be used if an output response message to the command cannot be transmitted within two seconds of its receipt.
The format of an acknowledgment is as follows:
<acknowledgment
code> ^ <ctag> <cr> <lf>
The acknowledgment code identifies the reason for the acknowledgment. The CTAG identifies the associated input command. The less than (<) character is the acknowledgment terminator.
Acknowledgment Codes
The valid values for acknowledgment codes and their meanings are given below.
IP - In Progress and PF - Printout Follows
The request has been initiated. These acknowledgments should produce output messages that give a termination report or a termination report and results of the command. They are used often for test and access messages requiring a long execution time. These acknowledgments are often followed by either Completed or Denied response messages.
OK - All Right
The command was received and the requested action was initiated and completed. In addition, OK is used in response to a command that has been canceled by inclusion of the CAN (Cancel) character.
NA - No Acknowledgment
This command is sent if initiation or execution of the requested command is not possible. Under abnormal conditions, NA is sent when command has been accepted but control of the processing has been lost. It can also be used to respond in circumstances if the command is garbled during transmission. If the CTAG value of the command could not be determined, then Zero(0) should be used as a ctag value for the acknowledgment.
NG - No Good ( Not Used )
The command is valid but the requested action conflicts with current system or equipment status. For inadequate system resources use RL instead of NG. This acknowledgment code is seldom used because specific error codes in output response messages can be employed to signify the same information. It can be used if desired.
RL - Repeat Later
The requested action cannot be executed due to unavailable system resources caused by system overload, excessive queue lengths, busy programs etc. The command can be sent at later times for any response.
Example
IP 23
<
where IP indicates request is in progress and 23 indicates CTAG value as that of the input message.
An Autonomous message is a message that is sent from the NE to the appropriate OS without having an explicit input message associated with it.
Typical scenarios where autonomous messages are used include :
Reporting of alarmed or non-alarmed trouble events.
Reporting of scheduled diagnostic tests in the NE.
Reporting of Performance Monitoring data.
Reporting of a change in the NE's database.
Periodic reporting of selected NE conditions.
General Format
The general structure of a TL1 Autonomous message is :
<header> <auto id> [ <text block> ] <terminator>
Here the text block is the optional field and all other fields are essential.
Header
The Header represents information common to all output response and autonomous messages. It contains System identifier <sid>,date and time stamps.
<cr><lf><lf>^^^<sid>^<year>-<month>-<day>^<hour>:<minute>:<second>
It contains System identifier <sid>, date and time stamps.<sid> is restricted to 20 characters maximum and identifies the NE generating the message. The syntax of <sid> is any TL1 identifier or text string. The <year><month><day> construct represent the day in which the output response is generated. The <hour><minute> <second> construct represent the time at which the output response is generated.
AutoID
It indicates the severity and the nature of the Autonomous message. The <Auto id> entry for an autonomous message is of the form
<cr><lf> <almcde>^<atag>^<verb>[^<modifier>[^<modifier>]]
Where <almcde> is the alarm code. It can be any of the following based on the severity of the autonomous message.
| Alarm Code | Description |
|---|---|
|
*C |
Critical Alarm |
|
** |
Major Alarm |
|
*^ |
Minor Alarm |
|
A^ |
Non-Alarm Message |
If Multiple Alarms are reported in the same message, the alarm code is the highest severity of those being reported.
<atag> is the Autonomously Generated Correlation Tag. It is assigned by the NE, must be sequential and must be included in all autonomously generated messages. It allows an OS to correlate spontaneous outputs triggered by a common problem and also to identify whether the OS has failed to receive any output. Also, It allows an OS to determine if it has failed to receive any spontaneous outputs by checking for omissions in the sequence of messages received.
<verb>[^<modifier>[^<modifier>]] entry identifies the nature of the spontaneous output. The first identifier is a required entry and indicates the message verb. The autonomous message can have two optional modifiers separated by space character.
Text Block
The optional [<text block>] is used to represent information specific to the particular autonomous message. The format of the text block is as follows:
(<cr><lf>^^^<unquoted line>)|(<cr><lf>^^^<quoted line>)|(<cr><lf>^^^<comment>)
It consists of three components namely unquoted line, quoted line and comment. Both quoted and unquoted lines consists of text that is parsable, while comment is not.
Terminator
The terminator block has the form
<cr><lf> ( ; | >)
This is required for all TL1 message types.
Example
<cr> <lf> <lf>
^^^BOCAFLMA015^93-06-02^12:00:00 <CR><lf>
A^^789^REPT^PM^T1 <cr><lf>
^^^"AID-T1-1:CVL,50" <cr><lf>
^^^"AID-T1-1:CVL,50" <cr><lf>
....
....
^^^"AID-T1-n:CVL,22" <cr><lf>
;
Here '^' symbol indicates Space
General Format
A TL1 output response message is the response to a TL1 input command message. The general structure of a TL1 output response message is of the form
<header> <response identification> [<text block>] <termination>
which consists of a optional text block and all the other blocks are essential.
Header
The Header represents information common to all output response.
<cr><lf><lf>^^^<sid>^<year>-<month>-<day>^<hour>:<minute>:<second>
It contains System identifier <sid>, date and time stamps.<sid> is restricted to 20 characters maximum and identifies the NE generating the message. The syntax of <sid> is any TL1 identifier or text string. The <year><month><day> construct represent the day in which the output response is generated. The <hour><minute> <second> construct represent the time at which the output response is generated.
Response Identification
The form of the response identification is :
<cr><lf>M^^<ctag>^<completion code>
This construct consists of three components namely the character M, a correlation Tag and a completion code. The character M signifies that the message is the response to the input command. The ctag must be the same as that of the input message to associate the response with the proper input command.
The various completion codes are described below.
| Completion Code | Description |
|---|---|
|
COMPLD |
Total successful execution of the input command. |
|
DENY |
Total denial of the input command. |
|
PRTL |
Partial successful execution of the input command. This response code is valid when the ctag in the general block is FALSE represents successful queuing of the input command submitted for delayed activation.. |
|
DELAY |
Successful queuing of the input command submitted for delayed activation. |
|
RTRY |
Output response of a input retrieve command that retrieves extensive amount of information from the NE and uses more time for processing |
Text Block
The optional [<text block>] is used to represent information specific to the particular autonomous message. The format of the text block is as follows :-
((<cr><lf>^^^<unquoted line>) | (<cr><lf>^^^<quoted line>) |(<cr><lf>^^^<comment>))
It consists of three components namely unquoted line, quoted line and comment. Both quoted and unquoted lines consists of text that is parsable, while comment is not.The most popular usage of unquoted line is for representing error codes in some response messages. The quoted line consists of parsable text and shall be preceded and followed by double quotes. The comment line is used to allow free format text. It should be preceded by ( /* ) and followed by ( */ ).
Terminator
The form of the terminator is :
<cr><lf>( ; | > )
The terminator is represented by either the semicolon (;) character or the greater than (>) character. The semicolon (;) character is used to indicate the termination of the output response message. The greater than (>) character is used to indicate that more output associated with this response will follow under another header.
Since the size of the output message should not exceed 4096 bytes, it is important to split the response into blocks with the same Ctag. The (>) terminator is also used for intermediate responses in a timed measurement series.
Example
Assume that the input command
UPDATE : RDBKNJNVK01 : 5-7 :1204 ; was issued, a typical NE output message will look like the following :
^^^RDBKNJNVK01^93-06-15^09:12:11
<cr><lf>
M^^1204^COMPLD <cr><lf>
^^^"5-7:32,None" <cr><lf>
;
Here '^' indicates space character.
|
|