tl1 tutorial

of 43

TL1 Tutorial In telecommunication industry, TL1 is the most popular Command Line Interface (CLI) and the de facto standard management protocol. This tutorial covers the history and evolution of TL1, message structure and syntax of TL1 commands, and the TL1 features.

of 43

Table of Contents TL1 Tutorial ......................................................................................................... 1 1.0 History and Evolution of TL1.......................................................................... 4 2.0 TL1 – The Telecom Management Protocol...................................................... 5

2.1 TL1 and SNMP: A comparison.......................................................................... 5 3.0 TL1 Language ................................................................................................ 8 3.1 TL1 Message Types........................................................................................ 9 3.2 TL1 Input Message ...................................................................................... 10

3.2.1 Command Code .........................................................................................10 3.2.2 Staging Block ............................................................................................10 3.2.3 Payload Block ............................................................................................12 3.2.4 Examples for TL1 input commands: .............................................................12

3.3 TL1 Acknowledgment .................................................................................. 13 3.3.1 Acknowledgment code................................................................................13 3.3.2 CTAG .......................................................................................................13 3.3.3 Terminator................................................................................................13

3.4 TL1 Response Message ................................................................................ 14 3.4.1 Response Header .......................................................................................14 3.4.2 Response ID..............................................................................................14 3.4.3 Response Block .........................................................................................15 3.4.4 Terminators ..............................................................................................15 3.4.5 Examples for TL1 response messages: .........................................................16

3.5 TL1 Autonomous Message ........................................................................... 17 3.5.1 Header .....................................................................................................17 3.5.2 Auto ID ...................................................................................................17 3.5.3 Text Block.................................................................................................18 3.5.4 Terminators ..............................................................................................18 3.5.5 Examples for TL1 input commands: .............................................................19

3.6 Verb List ..................................................................................................... 20 3.7 TL1 Parameters ........................................................................................... 21

3.7.1 Position-Defined Parameters .......................................................................21 3.7.2 Name-Defined Parameters ..........................................................................21

4.0 TL1 Provisioning Messages.......................................................................... 22 4.1 Equipment Provisioning Messages...................................................................22 4.2 Facilities Provisioning Messages......................................................................22 4.3 Cross-connect Provisioning ............................................................................22 4.4 Facility Protection Group (FFP) Provisioning .....................................................23 4.5 Gateway NE Map Provisioning ........................................................................23

5.0 TL1 Protection Switching Messages............................................................. 24 5.1 Switching Messages ......................................................................................24 5.2 SONET Protection Switching Messages ...........................................................24 5.3 Non-SONET Line Protection Switching Messages ...............................................24

6.0 Telcordia GRs .............................................................................................. 27 7.0 Gateway NE ................................................................................................. 28

7.1 TL1 Deployment Scenario ..............................................................................28 7.2 Need for Gateway NE ....................................................................................28 7.3 How GNE Works ...........................................................................................30 7.4 Building TL1 Agent for GNE............................................................................30

8.0 Delayed Activation....................................................................................... 31 8.1 Need for Delayed Activation ...........................................................................31 8.2 How delayed activation works ........................................................................31

of 43

8.3 Delayed activation parameters .......................................................................31 8.4 How to set the delayed activation parameters in a TL1 command .......................32 8.5 How to retrieve pending commands ................................................................32 8.6 How to activate pending commands................................................................32 8.7 How to cancel pending commands ..................................................................33

9.0 Security ....................................................................................................... 34 9.1 Telcordia's view on security ...........................................................................34 9.2 Implementing Security in TL1.........................................................................35 9.3 Building TL1 Agent from Security point of view.................................................38

10.0 TL1 and OSMINE certification .................................................................... 39 10.1 Key Benefits of OSMINE...............................................................................39 10.2 Preparing Yourself for OSMINE Certification....................................................39 10.3 How easy is it? ...........................................................................................39

11.0 Glossary .................................................................................................... 41

of 43

1.0 History and Evolution of TL1 During the mid-80s, Bellcore embarked on specifying a standard man-machine language to manage network elements (NEs.) It was to be based on Z.300 series Man Machine Language (MML) standards. It was designated Transaction Language 1 or simply TL1. This effort encompassed specifying a language as well as message set(s) for managing a variety of Telecom equipments from different domains. During that time, Bellcore was also developing a fault management OSS (Operations Support System) called Network Monitoring and Analysis (NMA) for the Regional Holding Companies (RHCs). Incidentally, TL1 was chosen as NMA’s element management protocol. Consequently, for NEs to be NMA manageable, TL1 support became mandatory. TL1 made its foray into carrier networks well over a decade ago and during the subsequent years; TL1 deployments became widespread in the RHC space. Circuit switches were the only ones that did not embrace TL1 and continued to operate their proprietary interfaces. Today TL1 is a management protocol of choice for majority of SONET and access infrastructure in North America.

of 43

2.0 TL1 – The Telecom Management Protocol TL1 excels as the de facto standard telecom management protocol with the following advantages over other protocols. Standard Command Line Interface: Being ASCII, human operators can compose input message and directly interpret responses and events. Unlike many other CLIs, TL1 is not free form, with the syntax of one command differing from the next. As a result, element managers use the same TL1 interface. Man-Machine Language: TL1 messages are in plain ASCII text, so operators and developers alike can always read them. As messages are easily readable, TL1 does not require sophisticated debuggers or protocol analyzers - what you see is what you get. Delayed Activation: Delay Activation is a function whereby an input message (request) can be stored in a Message Pending buffer at the NE, for final execution later, either automatically or by a subsequent message from the OS. Autonomous Message Tracking: ATAG (Autonomous Message Tag) in autonomous message allows an OS to determine if it has failed to receive any spontaneous outputs by checking for omissions in the sequence of messages received. Acknowledgment: An acknowledgment is a brief output message generated in response to an input command message. As per the standards, an acknowledgment should be used if an output response message to the command cannot be transmitted within 2 seconds of its receipt. 2.1 TL1 and SNMP: A comparison The purpose of this comparison is to give you a clear understanding of TL1 by comparing it with SNMP. This is not aimed at projecting any protocol better than the other.

SL No

Functions & Features TL1 SNMP

1.

Operations: Operations are the actions initiated by manager to manage the managed objects.

Input Messages. It may operate on some data or it may initiate some action in NE.

GET, SET, GET-NEXT, and GET-BULK Here, all requests will operate on data.

2.

Notification: A notification is one generated by the NE to report some unusual occurrence. It can be either periodic or spontaneous.

Autonomous Message

Trap, Notification, and Inform

3.

Management Information Model: Abstract representation of managed object.

There is no such information model used in TL1. Here every thing is action to be taken at NE.

The Internet Structure of Management Information (SMI) defines the rules for how management information is described and stored. Here, it is called as MIB (Management

of 43

Information Model).

4.

Encoding: Transforming the messages that are sent over communication channel.

There is no encoding here. TL1 messages are in plain ASCII text.

ASN.1 encoding is used here.

5.

Notification Tracking: Provision in notification that allows an OS to determine if it has failed to receive any spontaneous outputs by checking for omissions in the sequence of messages received

ATAG in autonomous message allows an OS to determine if it has failed to receive any spontaneous outputs by checking for omissions in the sequence of messages received.

Inform can be used by agent. Inform is nothing but Confirmed Notification. After an Inform message is sent out, the agent will get back with a response message for the transmitted Inform message.

6.

Acknowledgment: An acknowledgment is a short reply from the NE indicating that an input command message is being acted upon or has been immediately rejected.

Yes No

7.

Delay Activation: Delay Activation is a function whereby an input message (request) may be stored in a Message Pending buffer at the NE for final execution later, either automatically or by a subsequent message from the OS.

Yes No

8.

Man-Machine Language: Operators can compose request message and directly interpret responses and events.

Yes. TL1 is man -machine and machine -machine language. Therefore, it can be managed from both the craft terminal and OSS.

Machine-Machine Language. It requires manager application.

9.

Security: Security is concerned with protecting managed resources from unauthorized access.

It can be implemented by using system and resource access control mechanism. System access control needs persistent connection between OSS and NE for authentication (System access

SNMPv3 uses USM (User Security Model) and VACM (View based Access Control Mechanism) security model. Here, authentication is done per message. So connection between OSS and NE may be persistent or not.

of 43

control).

of 43

3.0 TL1 Language A TL1 resource is one, which uses TL1 protocol for communication. To perform functions on these resources and to manage them, TL1 messages are used. TL1 messages comprise two sets: Input messages - these are the messages sent to a TL1 resource with an intention

of operating, maintaining, or provisioning the TL1 resource. Responses and Autonomous messages - these are messages emitted by the NEs

when they are in receipt of an input message (response) or when they notify about an event or an alarm condition in the NE (autonomous message)

Telcordia standardized these messages by specifying rules for syntax, structure, and semantics of TL1 messages (GR-831). Any TL1 message should adhere to these specifications so that they all speak a common TL1 language.

of 43

3.1 TL1 Message Types There are four types of TL1 messages, namely input message, response, acknowledgment, and autonomous message.

TL1 Input Messages These messages are also called as commands. They are used to operate on the NEs. Input messages can be sent either by the OSS via a GUI or by an operator via a command line interface. TL1 Response Messages These are messages sent by the NEs as a token of receipt for the input message. When the input messages are sent, you can specify whether a response is required or not. If a response is required then the NE sends an immediate message. On receipt of the input message indicating that, the message has been received. TL1 Acknowledgment Messages These are brief messages from the NE to OSS acknowledging the receipt of a TL1 command. It updates the user on the status of a given command. Acknowledgment is issued if the normal response to a message will be delayed by more than two seconds. TL1 Autonomous Messages These are messages sent by the NEs, on their own without being requested by the OSS, on occurrence of an event or an alarmed condition of the NE. Autonomous messages also report the periodic data collected.

of 43

3.2 TL1 Input Message TL1 input messages are also called TL1 commands. They are used to operate specific tasks on the NEs. They can be sent either by the OSS via a GUI or by an operator via a command line interface. TL1 input message or the TL1 command takes the following format command_code:staging_block:payload_blocks;

3.2.1 Command Code The command code part of the input message defines the nature of the task that is to be executed on the NE. It is also called the VMM (verb-modifier-modifier). A command code has the following format verb-modifier1-modifier2 Verb: Refers to the type of action to be taken on the NE (in case of input message)

or the type of event that has occurred in the NE (in case of autonomous message). Refer to the table of verbs to know the list of verbs that are used in messaging.

Modifiers: These are optional qualifiers for the input message. Depending on the complexity of the message, one can use modifiers. Modifier 1 and modifier 2 are used to identify and describe the object in the NE, which has to be acted upon by the message, respectively.

3.2.2 Staging Block The staging block part of the input message helps in identifying the exact resource in the NE, which has to be acted upon by the command. The staging block has the following format :TID:AID:CTAG:generalblock: Target Identifier (TID) Every TL1 network element is assigned with a Target Identifier (TID), which uniquely identifies the NE. TID is used for identifying the end NE when commands from OSSs are

of 43

routed through a gateway network element.

TID can be of maximum 20 ASCII characters limited to letters, digits, and hypens.

In direct routing, where commands are sent to an NE directly from the OSS, the TID value will be null.

In indirect routing, where commands are sent to NEs via an intermediate GNE, a valid TID value is essential.

TID should be equal to the system identification code (SID) that is returned in a response message from the NE.

Access Identifier (AID) The access identifier contains one or more simple or compound parameters that uniquely identify the entity, within or associated with the target NE, to be acted upon by the input message. Typical examples of entities addressed by the AID parameter value are as follows:

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) CTAG is used to correlate a response or acknowledgment with the originating input message. It is an OSS-generated integer that helps in correlating the input command with the feedback got from the NE. Without a CTAG, you will not be sure of which response correlates to which command. General Block The general block holds the information that mandates how the command will be handled by the NE.

General block is mandatory in commands that have payload. General block can be used to specify the delayed-activation parameters. If delayed-activation is not supported then general block may be null

(represented by two semi-colons ::). General block has the following format :[[<delayed activation parameters>],[<contingency flag>],[<indirect data retrieval identifier>]]:

Delayed Activation Parameters - There are three parameters involved in delayed activation. 1)ORDER NO, 2) DATE, 3) TIME.

Contingency Flag - This parameter can specify whether or not a message can have partial success when more than one AID is specified.

Indirect Data Retrieval - Indirect data retrieval is used in a RTRV message and instructs the NE to return data for linked administrative views. The parameter here is RTRVIND=<linked_admin_view>[-<linked_admin_view>].

of 43

3.2.3 Payload Block Any additional information that is required to carryout the command is specified in this payload block.

Payload block consists of zero or more datablocks. Each datablock is separated by colons.

Every datablock may contain multiple datacomponents, separated by commas. Datacomponents may be either position-defined or name-defined parameters.

Payload block has the following format payload_block::=data_block_list;data_block_list::=data_block | data_block_list:data_block 3.2.4 Examples for TL1 input commands: Message definition Example command ACT-USER::USER NAME:<Ctag>::PASSWORD;

ACT-USER::root:4::public;

ENT-USER-SECU ::<UID>:<CTag>: PID,CID,UAP : PCND,PCNN,POINT,UOUT,LSTOILIST;

ENT-USER-SECU::user1:13::user1,TCP,2:56,8,4,10,87,file;

ENT-TCPRE:<TID>::<ctag>:<GB>:<ENE>,<IP address>,<port number>;

ENT-TCPRE:GNE1::4::NE3,192.168.1.1,9090;

ALW-EX:::<C TAG>:ON,DATE,TIME,CF,RTRVIND:;

ALW-EX: : : 2 : 1,01-03-17 , 11-22-40, : ;

ENT-CRS-STS1:<TID>:<from channel>,<to channel>:<ctag>::;

ENT-CRS-STS1:GATE:STS-4-2,STS-7-3:43::;

ED-PID:<TID>:<UID>:<CTAG>::<OLD PID>,<NEW PID>;

ED-PID:POUND:private:123::public,hareens12;

of 43

3.3 TL1 Acknowledgment An acknowledgment is a brief TL1 output message from the NE to an OSS acknowledging the receipt of a request. It updates the user on the status of a given command. Acknowledgment should be issued if the normal response to a message will be delayed longer than two seconds. TL1 acknowledgment can take the following format acknowledgment_code ctag terminator

An example for acknowledgment message is OK 12345 > where, OK - acknowledgment code, 12345 - ctag, greater than symbol > - terminator 3.3.1 Acknowledgment code Standard TL1 acknowledgment codes are

IP: In Progress PF: Printout follows (identical to IP) OK: All right NA: No acknowledgment NG: No Good RL: Repeat Later system busy

3.3.2 CTAG Refers to the correlation tag of the input message to which this acknowledgment is made. 3.3.3 Terminator TL1 acknowledgments always end with greater than symbol > terminator.

of 43

3.4 TL1 Response Message TL1 response message, its structure, and syntax are discussed in detail here. Response is an output message sent by the NE to OSS on completion of the task requested by the TL1 input message. It may be preceded by an acknowledgment message. A simple response message confirms the outcome of the requested task or operation. It says whether the requested task was completed successfully or not. A complex response message, in addition to giving the status of the task, includes data in the message. TL1 response message takes the following format header response_id [response_block] terminator

3.4.1 Response Header Response message’s header block take the following form: ^^^sid^year-month-day^hour:min:sec

Here, SID is the source identifier, year-month-day and hour:min:sec represent the date and time of the message. SID Source identifier represents the name of the NE used for identifying the NE emitting the message. SID is similar to the target identifier. 3.4.2 Response ID Response ID identifies the type of output message - whether it is a response or an autonomous message. Response Id takes the following format M^^ctag^completion_code M - used to differentiate between response and autonomous message ctag - indicates the correlation tag assigned with the input message. completion code - indicates the status of the task - whether it is completed

successfully or not.

of 43

Completion code Type Parameters

Success response code

COMPLD - indicates successful completion of the requested operation. DELAY - indicates successful delayed activation of the requested operation.

Other response code

DENY - indicates failure of the TL1 command and provides an error message with the reason for the failure. PRTL - indicates partially successful response. That is, the requested action can be completed for some of the specified AIDs, but not all. RTRV - indicates that the response is successful, but it is lengthy and is being returned in multiple parts. Final response has a COMPLD response code.

Error Categories Whenever a TL1 command fails, the response message contains the failure code. Following are the failure codes EXXX - Equipage errors FXXX - Fault errors IXXX - Input errors PXXX - Privilege errors RXXX - Resource errors SXXX - Status errors 3.4.3 Response Block TL1 output messages contain text blocks. These text blocks hold the main body of the output message and the payload. In response messages, these text blocks are called response blocks. Response block have quoted lines, unquoted lines, and comments.

An unquoted line is made up of a list of parameters (either name defined or position defined) separated by mandatory white spaces or optional commas.

A quoted line consists of a double quoted (") line of machine parsable text. A comment allows free form text messages to be generated by the NE for

presentation to the OS. The comment must begin with /* and end with */. 3.4.4 Terminators Syntax of terminators : <cr><lf>( ; | > ) The semicolon (;)indicates the termination of output messages and greater than (>) character indicates more output associated with this response will follow under another header. The size of the output message should not exceed 4096 bytes. If it exceeds the specified size, then the output response is split into multiple responses with the same CTAG.

of 43

3.4.5 Examples for TL1 response messages: TL1 Input Message Corresponding Response Message RTRV-USER-SECU::root:12::; <CR>

<LF><LF> Source 02-01-09 20:25:02<CR> <LF>M 12 RTRV<CR> <LF> "UID=root:CID=TCP&CRAFT,UAP=1:PAGE=60, PCND=7, PCNN=3,POINT=180,UOUT=90, LSTOI=1"<CR> <LF>;

ENT-TCPRE:GNE1::4::NE3, 192.168.1.1,9090;

<CR> <LF><LF> System 02-01-11 19:30:43<CR> <LF>M 4 COMPLD<CR> <LF>;

ACT-USER::root:4::public;

<CR> <LF><LF> Source 02-05-06 14:26:12<CR> <LF>M 4 COMPLD<CR> <LF> "UID=root:LASTLOGIN=Mon May 6 14:25:13 2002,UNSUCCESSATTEMPTS=0"<CR> <LF>;

ENT-CRS-STS1::STS-4-3, STS-2-1:43:;

Error Message <CR> <LF><LF> Source 02-05-06 14:30:42<CR> <LF>M 4 DENY<CR> <LF> EANS<CR> <LF> "ACCESS NOT SUPPORTED"<CR> <LF>;

of 43

3.5 TL1 Autonomous Message Autonomous messages are output messages sent by the NEs to report alarms, performance data, configuration changes, or condition changes. Messages relating to alarm conditions are spontaneously triggered by the NE without intervention. Messages relating to periodic reporting of performance data values are scheduled by the operator.

Autonomous message has the following format header auto_id [text_block] terminator 3.5.1 Header Autonomous message’s header block take the following form: ^^^sid^year-month-day^hour:min:sec

Here, SID is the source identifier, year-month-day and hour:min:sec represent the date and time of the message. SID Source identifier represents the name of the NE used for identifying the NE emitting the message. SID is similar to the target identifier. 3.5.2 Auto ID Autonomous identifier block has the following format alarm_code^atag^verb [-modifier1[-modifier2]] Alarm Code Alarm code indicates the severity of the alarm. One of the four severity levels, given below in the table, is assigned to every event condition. Alarm Code (almcde) Description Corresponding notification code

(ntfcncde) *C Critical alarm condition CR ** Major alarm condition MJ *^ Minor alarm condition MN

A^ Non-alarmed autonomous message CL, NA

of 43

If multiple alarms are reported, the alarm code will correspond to the alarm with the highest severity. Non-alarmed code is used when the NE reports non-alarmed autonomous messages such as those reporting performance data measurements. ATAG Every TL1 autonomous message, that the NE generates autonomously, contains a unique identifier called the Autonomous TAG (ATAG). It is an integer value (e.g., 198) incremented by one for each message. These ATAGs can be used for alarm correlation. The OSS can look for the continuity of the ATAG values and verify that no message is lost. If the OSS senses an ATAG out of sequence, it can request the missing data to be sent again from the NE. Fractional ATAG : Sometimes ATAG may be associated with a second decimal,

component. It helps in correlating multiple events with a single source (e.g., 198.7).

ATAG character length GR-833 specifies the character length of ATAG to be

maximum of 10 characters including the fractional component. VMM VMM represents the verb-modifier1-modifier2 format or the command code. The verb indicates the action to be taken on the NE, as requested by the TL1 command, or the type of autonomous event that is fired by the NE. The modifiers further qualify the command as to which object is acted upon by the command and give additional description about the object. 3.5.3 Text Block Text blocks hold the main body of the output message and the payload. Text blocks have quoted lines, unquoted lines, and comments An unquoted line is made up of a list of parameters (either name defined or

position defined) separated by mandatory white spaces or optional commas. A quoted line consists of a double quoted (") line of machine parsable text. A comment allows free form text messages to be generated by the NE for

presentation to the OS. The comment must begin with /* and end with */. 3.5.4 Terminators Syntax of terminators: <cr><lf>( ; | > ) The semicolon (;)indicates the termination of output messages and greater than (>) character indicates more output associated with this autonomous message will follow under another header. The size of the autonomous message should not exceed 4096 bytes. If it exceeds the specified size, then the autonomous message is split into multiple responses with the same CTAG.

of 43

3.5.5 Examples for TL1 input commands: Autonomous Message definition Description <CR> <LF><LF> Source 02-01-15 14:28:09 <CR> <LF>** 1 REPT ALM SECU <CR> <LF>"SECURITY LOG:CR,LOGBUFROVFL-SECULOG"<CR> <LF>;

This autonomous message will be sent when the security log file is completely full.

<CR> <LF><LF> Source 02-05-06 13:23:03<CR> <LF>A 1 REPT EVT SESSION<CR> <LF> "root:NO,"<CR> <LF> /*NOTICE: This is a private computer system.<LF> Unauthorized access or use may lead to prosecution.*/<CR> <LF>;

This autonomous message will be sent when a user logs in.

of 43

3.6 Verb List The table contains a list of generic TL 1 command verbs.

S.No Verb Definition 1 ABT Abort 2 ACPT Accept 3 ACT Activate 4 ALW Allow 5 AUD Audit 6 CANC Cancel 7 CHG Change 8 CMPR Compare 9 CONN Connect 10 COPY Copy 11 CPY Copy 12 CRPT Corrupt 13 CRTE Create 14 DGN Diagnose 15 DISC Disconnect 16 DLT Delete 17 ED Edit 18 ENCAP Encapsulation 19 ENT Enter 20 EX Exercise 21 EXIT Exit 22 FLTLOC FaultLocate 23 INH Inhibit 24 INIT Initialize 25 MEAS Measure 26 MON Monitor 27 OPR Operate 28 RD Read 29 REC Recover 30 RECNFGR Reconfigure 31 REPT Report 32 RLS Release 33 RMV Remove 34 RST Restore 35 RTRV Retrieve 36 SCHED Schedule 37 SET Set 38 SND Send 39 STA Start 40 STP Stop 41 TEST Test 42 TRACE Trace 43 WRT Write

of 43

3.7 TL1 Parameters The parameters used in TL1 message can be broadly classified into two : Position-defined parameters and Name-defined parameters. 3.7.1 Position-Defined Parameters Position-defined parameters take the following form ValueA, ValueB, .... (comma separated values) They appear in the same block in any TL1 message. It is necessary to retain delimiters for position-defined parameters. Meaning, if a position defined parameter takes a null value, then empty commas exist to represent the null value. Example : ValueA,,, ValueB, (here the two commas represented in red indicate the presence of two null values valueA and valueC). Good example for position defined parameters is the CTAG 3.7.2 Name-Defined Parameters Name-defined parameters take the following form Name1=Value1, name2=value2, …. The parameter names are case sensitive, whereas the value are not case-sensitive. You need not retain delimiters to mention the null value of the values. Example: name1=value1, name3=value3…..(though the parameter 2 is missing here, you need not have an empty comma) NOTE : In a TL1 message you can't mix name-defined and position-defined parameters inside a single block. The type of parameter used inside a single block (separated by colon) should be of only one type either name-defined or position-defined. However, you can have multiple blocks inside the payload block each of different type. For example, in the cross connect command given below ED-CRS-STS1:TID:FROM_AID, TO_AID:CTAG::common_block:specific_block:state_block; the common block and the state block are position defined, whereas the specific block is name defined.

of 43

4.0 TL1 Provisioning Messages The following are the types of provisioning messages used by TL1 operators.

4.1 Equipment Provisioning Messages

The equipment provisioning messages defined in GR-199 are provided in the table below. These messages are used to implement equipment provisioning.

DLT-EQPT Delete equipment

ED-EQPT Edit equipment/ Usually used to re-provision an existing entity

ENT-EQPT Edit equipment/ Usually used to provision a new entity

RTRV-EQPT Retrieve a list of equipment

4.2 Facilities Provisioning Messages

TL1 supports configuration and provisioning of facilities. The table below gives you the facilities provisioning messages defined in GR-199.

DLT-mod1 Delete the attributes of a given entity

ED-mod1 Edit the attributes of an existing entity

ENT-mod1 Edit the attributes of a new entity

RMV-mod1 Remove entity from service

RST-mod1 Restore entity to service

RTRV-mod1 Retrieve the attributes of a given entity

4.3 Cross-connect Provisioning

The cross connect provisioning messages are provided in the table below.

DLT-CRS-mod2 Delete a crossconnect

ED-CRS-mod2 Edit information about crossconnected transmission entities.

ENT-CRS-mod2 Enter information about crossconnected transmission entities.

RTRV-CRS Retrieve crossconnected channels

RTRV-CRS-mod2 Retrieve information about crossconnected transmission entities.

of 43

4.4 Facility Protection Group (FFP) Provisioning

TL1 provides messages to support facility protection provisioning. Facility protection groups associate a protecting (alternate) facility with a protected (preferred) facility.

DLT-FFP-mod2 Delete members of a facility protection group or the entire facility protection group

ED-FFP-mod2 Edit information about members of a facility protection group or the entire facility protection group

ENT-FFP-mod2 Create a facility protection group and enter attributes about that group

RTRV-FFP-mod2 Retrieve information about a facility protection for the given access identifier(s)

4.5 Gateway NE Map Provisioning

It is possible for you to configure gateway NEs to manage table entries. There are two types of tables, facilitating message routing: OSACMAP correlates specific OSs to OSI application associations. Each entry maps the OS's X.25 SNPA to an OSI application context ID. TADRMAP correlates the TIDs of the subtending NEs to their network addresses.

DLT-OSACMAP Delete an entry in gateway NE's OS application context mapping table.

ED-OSACMAP Edit an entry in gateway NE's OS application context mapping table.

ED-OSACMAP Create an entry in gateway NE's OS application context mapping table.

RTRV-OSACMAP Retrieve the gateway NE's OS application context mapping table.

DLT-TADRMAP Delete an entry in gateway NE's TID to NSAP mapping table.

ED-TADRMAP Edit an entry in gateway NE's TID to network address mapping table.

ENT-TADRMAP Create an entry in gateway NE's TID to network address mapping table.

RTRV-TADRMAP Retrieve the gateway NE's TID to network address mapping table.

of 43

5.0 TL1 Protection Switching Messages The following are the TL1 protection switching messages used by TL1 operators.

TL1 protection switching messages help switching capability between working, protection, and backup entities. You have messages to control the backup capabilities of redundant equipment units and facilities.

5.1 Switching Messages

NEs provide protection switching upon detecting trouble in the line. You can implement the functions using the switching messages shown below. These messages are defined in GR-833[1].

EX-SW This command instructs an NE to exercise the algorithm for switching from a an equipment or facility entity from working to protection.

REPT-SW Generated by the NE after it has autonomously switched an active unit of a duplex equipment pair to standby and switched its mate to active.

SONET Protection switching messages for SONET NEs.

Non-SONET Protection switching messages for non-SONET NEs.

5.2 SONET Protection Switching Messages

SONET provides automatic protection switching upon detecting trouble in the line. You can implement the functions using the switching messages shown below. These messages are defined in GR-833[1].

OPR-PROTNSW

Instructs a SONET NE to initiate a SONET line or path protection switch request. User switch requests initiated with this command (i.e., forced switch, lockout, and manual switch) remain active until they are released via the RLS PROTNSW command or overridden by a higher priority protection switch request. To initiate protection switch exercise, use EX SW.

RLS-PROTNSW

Instructs a SONET NE to release a SONET line or path protection switch.

5.3 Non-SONET Line Protection Switching Messages

The following commands instruct NEs to allow or inhibit automatic / manual switching to protection or working. DO NOT USE THESE COMMANDS FOR SONET LINE PROTECTION SWITCHING.

ALW-SWDX Thi d i t t th NE t ll t ti l it hi t

of 43

protection for a managed inventory or facility entity on a duplex system.

To inhibit from switching to protection, use INH-SWDX.

ALW-SWTOPROTN-xx

This command instructs the NE to allow automatic or manual switching to protection for a managed inventory or facility entity. This function is sometimes called "release lockon" or "release lockout."

The AID in this command identifies either the equipment unit or facility for which switching to protection is being allowed. The entity may be the working unit or the protection unit.

• For a working unit, this command allows the unit to access any protection unit, and the state of the working unit changes from IS-NR-ACT-LOCK to IS-NR-ACT.

• For a protection unit, this command allows the protection unit to be accessed by any working unit, and its state changes from IS-NR-STBY-LOCK to IS-NR-STBY.

To inhibit from switching to protection, use INH-SWTOPROTN.

ALW-SWTOWKG-xx

This command instructs the NE to allow automatic or manual switching to working for a managed inventory or facility entity that has been switched to protection. The ALW-SWTOWKG function is sometimes called "release lockon a protection unit" or "release lockout a working unit."

To inhibit from switching back to working, use INH-SWTOWKG.

INH-SWDX-xx This command instructs the NE to inhibit automatic or manual switching to protection for a managed inventory or facility entity on a duplex system.

Any NE for which switching to protection is inhibited with the INH-SWDX command should include the appropriate condition type information in response to a RTRV-COND request.

INH-SWTOPROTN-xx

This command instructs the NE to inhibit automatic or manual switching to protection for a managed inventory or facility entity.

Any NE for which switching to protection is inhibited with the INH-SWTOPROTN command should include the appropriate condition type information in response to a RTRV-COND request.

INH-SWTOWKG-xx

This command instructs the NE to inhibit automatic or manual switching to working for a managed inventory or facility entity that has been switched to protection.

Any NE for which switching to working is inhibited with the INH-SWTOWKG command should include the appropriate condition type information in response to a RTRV-COND request.

of 43

SW-DX-xx This command instructs an NE to switch an equipment unit or facility with the mate unit within the NE.

SW-TOPROTN-xx Perform a protection switch

SW-TOWKG-xx Release a unit from protection

of 43

6.0 Telcordia GRs Tellcordia specifies standards for TL1 by publishing GRs .Generic Requirements (GR) provide Tellcordia's view of proposed generic criteria for telecommunications equipment, systems, or services. The table below gives a partial list of the Telcordia GRs. GR831 - Operations Application Messages - Language for Operations Application Messages It provides implementation level requirements for TL1.This document mainly focuses on the syntax and semantics of TL1 messages(input, output, acknowledgment and autonomous). GR199 -This document provides the messages and data dictionary information required for the memory administration functions for SONET and switching NEs. It also provides provisioning messages for common NE and message related to Gateway NE. GR833 - NE and Transport Surveillance Messages. This documents describes message structures for network maintenance and surveillance functions. GR 815 - proposes the Telcordia view of the generic requirements for Network Elements (NEs) and Network Systems (NSs) security, i.e., the generic security features required of a total NE/NS environment. These requirements are generic and are not specific to any particular NE/NS. GR 815 defines the baseline security requirements ie. a minimum level of security. Additional security may be needed for specific applications. TR 835 - describes Bellcore's view of message structures and data elements for Network Element and Network System Security administration. SR-NWT-002723 -provides applicable TL1 Messages for SONET Network Elements. Where to get GRs?. Visit the following URL to get more information about GRs. http://telecom-info.telcordia.com/

of 43

7.0 Gateway NE

Gateway NE has the capability to route input messages from the EMS to the NEs. And it also routes the autonomous messages from the NEs to the EMS. This article speaks more about this GNE in detail.

7.1 TL1 Deployment Scenario

In TL1, there are two major types of NE deployment. One is the deployment in a ring or bus topology and the other is deployment in a linear topology. Systems such as SONET, SDH, etc., are examples of deployment in a ring topology. A system such as IDLC is an example for deployment in linear or non-ring topology.

SONET systems interconnect the devices in a ring manner. Any command to the NEs should pass through this ring. IDLC system interconnects the devices in a linear manner. A manager, which communicates with the devices, requires a TCP/IP connection.

7.2 Need for Gateway NE

In SONET systems, a command can reach an NE after passing the intermittent NEs. A device as such cannot pass on the command. Hence, at least one of the devices should be a gateway element so that it passes the command to the intended device.

Figure 1.0

In SONET systems, apart from the normal operations channel, there is another channel called Data Communication Channel (DCC). Used only for administrative and management operations. A command, sent through DCC travels through all NEs in the path before reaching the target NE. NEs present in between the GNE and the ENDNE (target NE) are called Intermediate NEs (INEs).

of 43

Figure 2.0

IDLC systems require a dedicated TCP/IP connections between NEs and the manager. Holding a dedicated TCP/IP connection for every NE is not a scalable solution. Hence, at least one of the NEs should be gateway element to enable routing of messages between OSS and the NEs.

Figure 3.0

For security reasons, some NEs have restrictions on the number of "simultaneous user sessions". While managing such elements, the management applications and the craft operators face a "resource constraint problem" accentuated by the user session restrictions. Installing a GNE and routing the messages from multiple operators via the GNE solve this problem. Refer to figure 3.0.

of 43

Note :You can correlate GNE with the proxy feature of other management protocols. Without GNE, the management of TL1 networked devices will become difficult.

7.3 How GNE Works

A gateway network element has the ability to route information between NEs and the OSSs. It holds a persistent connection with the manager to enable message routing. The TIDs in the input command help GNE to identify the target NE. GNE maintains the list of TIDs of the NEs connected to it. Whenever GNE receives a TL1 input message, it routes the message to the appropriate NE by referring the TID. The GNE will also route the autonomous messages from the NEs to the OSS.

If the device is IP based, then the GNE opens up a TCP/IP connection, sends the command, and then closes the TCP/IP connection. In a SONET system, there is a dedicated channel called Embedded Operations Channel (EOC). GNE uses separate EOC commands such as ENT-EOCRE, ED-EOCRE, DLT-EOCRE, RTRV-EOCRE (refer to GR199) to add, delete, edit, and retrieve EOC entries in the GNE table.

Some networks use multiple communication channels, such as TCP/IP and X2.5. The routing entries for such channels will be different. Hence, for every protocol, you have to implement TL1 commands, similar to those of EOC commands. This enables the GNE to route messages in these channels over the specified protocol.

7.4 Building TL1 Agent for GNE

For an NE to act as a gateway NE, its agent should support the following.

• It should maintain a routing table (TID, subtended NE details(e.g. IP address and portnumber).

• It should also implement TL1 Messages for manipulating routing table.

The differentiation between NE and GNE lies in the agent that is installed in it. GNE’s agent should have the capability to interpret the commands and identify the target NE. It should then send the command to the target NE, by opening a session. If the command is intended for the GNE itself, it executes the command on itself.

of 43

8.0 Delayed Activation

Delayed activation is an intrinsic feature of TL1 that helps you to execute commands automatically at predefined date/time. This article speaks about this feature in detail.

8.1 Need for Delayed Activation

For service maintenance and performance analysis, operators run huge tasks in the NE, during lean hours. Provisioning thousand subscribers at a time is a good example for such tasks. The delayed activation feature comes handy in such situations. It allows operators to specify the date & time of execution in the command. Hence, operators need not sit back for long hours and send all those commands. Instead, they can send commands for automatic execution by specifying the date & time. And the NE executes the commands at the specified date/time without requiring a human operator.

8.2 How delayed activation works

NEs store the TL1 commands (only those with delayed activation) in a message pending buffer. The agent executes these commands at the specified date/time (date/time is specified in each command). It also sends a response message on completion of the operation.

8.3 Delayed activation parameters

[ON=] - ON represents the ORDER NUMBER. It is a numeric value assigned by you. The NE to internally identify the delayed input message uses this number. [DATE=] - DATE represents the exact date at which the delayed activation should occur. It takes the following format <yy>- <mm > - <dd> [TIME=] - TIME represents the exact time at which the delayed activation should occur. It takes the following format: <hh> - <mm> - <ss>

of 43

8.4 How to set the delayed activation parameters in a TL1 command You have to specify the three delayed activation parameters in the general block. Syntax of TL1 command: <command code>: <TID>: <AID>:< CTAG>: <general block>:<payload block>; Delayed activation parameters can be specified in the general block as shown below: Generalblock ::= <ON>,<DATE>,<TIME>,<CF>,<INDRTRV>

Example:

The following command ENT-CRS-STS1:TID:STS-3-2,STS-4-3:44:1, ,, : ; creates a cross connect between two channels, STS-3-2 and STS-4-3. To set the delayed activation parameters for this command, refer the table below

Delayed Activation at Command 23:00 hrs same day

ENT-CRS-STS1:TID:STS-3-2,STS-4-3:44:210198, , 23-00-00, : ;

on dec 06, 2002 ENT-CRS-STS1:TID:STS-3-2,STS-4-3:44:210198,02-12-06 , , : ;

23:00 hrs on dec06th2002

ENT-CRS-STS1:TID:STS-3-2,STS-4-3:44:210198,02-12-06,23-00-00, : ;

where, 210198 indicates ORDER NUMBER, 23:00:00 indicates time, 02-12-06 indicates date.

8.5 How to retrieve pending commands

To retrieve the TL1 commands with delayed activation , which are stored in the NE, the following command can be used RTRV-DA::[ALL|ORDNUM]:<ctag>::TTYPE ,TTIMEGE, TTIMELE; The NE will retrieve all the pending delayed activation commands if you specify ALL in the retrieve message. To retrieve specific commands from the NE specify the ORDER NUMBER of those commands in the retrieve message. After retrieval of the commands, you can make necessary changes in that command and re-send if necessary.

8.6 How to activate pending commands

You can activate a pending command manually by sending a TL1 command. The command for activating the pending messages takes the following format. ACT-DA::[ALL|ORDNUM]:<ctag>::; By specifying ALL you activate all the pending commands. To activate specific pending commands, specify the exact ORDER NUMBER of the commands.

of 43

8.7 How to cancel pending commands

You can delete a pending command using the following command CANC-DA::[ALL|ORDNUM]:<ctag>::; By specifying ALL you delete all the pending commands. To delete specific commands, specify the ORDER NUMBER of the commands

of 43

9.0 Security

In networked environments, the chances for security breaches are always high. Successful security breaches can affect the network’s performance and degrade the quality of service. In high quality telecommunication networks, poor performance would result in a dissatisfied user. This is not acceptable in today’s competitive world. Customer retention is key to business success. Some of the bad effects of intended security breaches include service thefts, disclosure of confidential information, collapse of the entire system etc. These are the worst nightmares for service providers. An immaculate security system becomes indispensable for anybody offering service over his networks.

9.1 Telcordia's view on security

GR 815 proposes the generic security features required of a total Network Element -Network System (NE/NS) environment. It defines the baseline security requirements and is not specific to any particular NE/NS.

TR 835 proposes the message structures and data elements for NE/NS security administration. It specifies five types of security views for implementing system access control and resource access control. It also defines set of commands for manipulating all the security view data.

5 security views specified in TR 835 User security view: Contains system access control parameters such as user name, password, password aging, privilege, etc. NE uses this data to authenticate a user when he tries to establish a session with the NE.

Channel security view: Contains channel related security parameters such as channel name, privilege, time-out interval, etc.

Command security view: Contains command access control parameters such as command name and privilege associated with all operation related commands.

Operations parameter related security view: Contains restrictions on the accessibility of records (rows) and fields (column) of an operations-related database.

Resource-related security view: Contains the resource access control parameters such as resource name and privilege associated with all operations-related resources such as executable programs that may not provide database type "view".

of 43

9.2 Implementing Security in TL1

The following are the key challenges faced in TL1 security administration.

1. User Authentication. 2. Restricting the authenticated users from using privileged commands. 3. Restricting the authenticated users from accessing specific resources in the NE. 4. Restricting the authenticated users from accessing privileged data from the data

tables. 5. Implementing security over the various channels through which the session is

established. 6. Keeping track of all the security-related events that happen in the network.

TL1 agent plays a major role in security. It receives all the TL1 commands and serves as the single point of communication. You have to configure the agent for implementing security in the device. Sending proper commands to the agent and thereby storing right information in the NE can easily deal with all the above-mentioned key challenges. The agent validates the commands with the help of data stored in the NE. It can execute or reject the commands based on the validation output.

9.2.1 Authenticating the Users

You can configure the agent and store authorized usernames and passwords in the NE [refer user security view in TR-835]. When users login with their username-password, the system access control (authentication mechanism) authorizes the establishment of session. NE uses the data stored in the user security view for validating the user name-password.

The input message for entering new user details into the user security view takes the following format. ENT-USER-SECU ::<UID>:<CTag>: PID,CID,UAP : PCND,PCNN,POINT,UOUT,LSTOILIST; where, PID,CID, and UAP are position defined and their values have to be entered in that order. The next list is name defined and can be entered in any sequence provided the right values are assigned to the appropriate parameters.

Example : The following command creates a new user "user1" with user security parameter values shown in it. ENT-USER-SECU::user1:13::user1,TCP,2:56,8,4,10,87,file;

Other commands related to user security view ED-USER-SECU: For editing existing user details. DLT-USER-SECU :For deleting an user. (session will not be established for this user) INH-USER-SECU: For inhibiting or disabling an existing user without deleting the user account. ALW-USER-SECU : For allowing a user ID which has been inhibited earlier. CANC-USER-SECU: For terminating a user session.

of 43

9.2.2 Restricting Users from Using Privileged Commands

You can configure the agent to store authorized commands for every user in the NE [refer command security view in TR-835]. When users send commands, the command access control mechanism authorizes the commands. NE uses the data stored in the command security view for this purpose. The command is either executed or rejected based on the output of the validation.

The input message for entering security parameters associated with a command takes the following format. ENT-CMD-SECU:<TID>:<AID>:<CTag>: <GB> :CAP;

Example

The following command enters the security parameters for the command get-sm-msgda in the command security view. ENT-CMD-SECU::get-sm-msgda:11::1&2;

Other commands related to command security view ED-CMD-SECU: For editing the security parameter values of a command. DEL-CMD-SECU: For deleting the security parameters associated with a command. RTRV-CMD-SECU: For retrieving the details of any command.

9.2.3. Restricting Users from Accessing Privileged Resources

A device may comprise of many entities such as ports, database tables etc. Access to certain entities should be restricted for security reasons. You can configure the agent to store a list of authorized resources for every user in the NE [refer resource related security view in TR-835]. When the agent receives a command, it compares the equipment ID of the command with the data stored in the table. The command is either executed or rejected based on the output of the validation.

The input command for storing security parameters associated with the resources takes the following format. ENT-RSC-SECU:<TID>:<AID>: <CTag>:<GB>:RAP;

Example ENT-RSC-SECU::device1:23::2;

Other commands related to resource-related security view ED-RSC-SECU: For editing the security parameters associated with resources in the NE. DLT-RSC-SECU: For deleting the security parameters associated with resources in the NE. RTRV-RSC-SECU: For retrieving the details of any resource available in the resource-related security view.

of 43

9.2.4 Restricting Users from Accessing Data from Tables

NE stores all the information in data tables. To prevent users from accessing high privileged data, you have to configure the agent and enable it to store the permissible data for every user. [refer operations parameter related security view in TR-835]. When the agent receives a command, it validates the requested data against the data stored in the operations parameter related security view. The NE executes the command based on the output of the validation.

The input command for storing security parameters in the operations parameter related security view takes the following format. ENT-SECU:<TID>:<AID>: <CTag>:<GB>:a,RCI:FAP ; where, "a" is the position-defined parameter that specifies the view. RCI is a position-defined list of Record Control Identifier(s) authorized to access the AID. FAP is a keyword-defined parameter block that may contain any keyword that specifies any field (i.e., column) of the view specified by the parameter "a".

Example ENT-SECU::1:6::adiskTable,TCP:adiskCapacity=2;

Other commands related to operations parameter related security viewED-SECU: For editing the security parameters associated with the fields of a record(s) in a user implemented view (e.g., Line View, Trunk View). DLT-SECU: For deleting any security parameters associated with the fields of a record(s) in a user implemented view (e.g., Line View, Trunk View).

9.2.5 Channel Level Security

It is true that a session is required to communicate with an NE. Channel refers to the session or the transmission line. A channel may be of any protocol such as such as TCP/IP, EOC, RS232, and X2.5. You can configure NEs for the following, with respect to channel security. 1) How many incorrect login attempts can be tolerated, 2) How long should the channel be locked out if the incorrect login attempt exceeds the limit, 3) What should be the time-out period for a channel. (Meaning, if the channel is idle beyond the time-out period, then the channel is closed.)

The input command for storing channel-related security parameters in the channel security view takes the following format. ENT-CID-SECU : <TID> : <CID>: <CTag>:<GB>:CHAP:DURAL,MXINV,TMOUT; where, CHAP is a position defined parameter. DURAL, MXINV, TMOUT are name defined and can be entered in any sequence provided the right values are assigned to the appropriate parameters.

Example The following command adds a new channel "craft " to the channel security view. ENT-CID-SECU::craft:10::2:5,00-13-23,26;

Other commands related to operations parameter related security view

of 43

ED-CID-SECU: For editing security parameters values associated with a channel identifier in the channel security view. DLT-CID-SECU: For deleting security parameter values of any channel identifier. CANC-CID-SECU: For terminating a session which is ongoing with the NE over a channel ID. RTRV-CID-SECU: For retrieving values of security parameters associated with a channel identifier.

9.2.6 Logging the Security Events:

Logging refers to keeping track of the events that happen in the network. The security system should record security-related events such as invalid login attempts, unauthorized attempts to access resources, etc., in the security log. Security log is a tool for security audit. Network administrators can infer more from the security logs and security audit. Security logging system should be capable of sending event notification to the system administrator.

9.3 Building TL1 Agent from Security point of view

If you are an equipment vendor aspiring to build the right TL1 agent for your NE, please check out whether the tool, which you use to build your agent, supports the requirements as specified in the Telcordia's TR 835. Building an agent confirming to the standards will help you implement a more reliable security implementation. If you wish to sell your equipment to the ILECs, the conformance to Telcordia's requirements become an added advantage for your devices and have more probability of getting through the integration process successfully

of 43

10.0 TL1 and OSMINE certification Equipment vendors aspiring to sell their equipments to ILECs should be aware that supporting TL1 in itself is not a panacea. An important milestone they have to pass is OSMINE compliance to ensure that their equipment can reliably interoperate with existing Telcordia OSSs in the targeted service provider network(s). OSMINE is a service offered by Telcordia and can cost NE vendors well over a Million dollars and take over a year to complete. OSMINE comes as an unwelcome surprise for some, especially for those who come from the IP (data) domain. Considering the fact that successful completion of OSMINE is just a stepping-stone to getting access to the golden ring of ILEC market, the associated opportunity cost is pretty high. During the CLEC heyday, it was not uncommon for NE vendors to forego the OSMINE efforts (it is worthwhile mentioning some were not even aware of such a process) in lieu of pursuing the growing CLEC market. However, since the collapse of the CLECs, OSMINE is becoming a requirement to survive. During 2001, established NE vendors such as Cisco, Ciena, Fujitsu, Lucent, Tellabs, and Nortel made significant investments on the OSMINE front. The total investment from these companies alone was over a 100M. Startups such as Metro-optix, Coriolis Networks, Astral Point (now a part of Alcatel) have embarked on OSMINE as well. Many others are in the process. 10.1 Key Benefits of OSMINE

• OSMINE ensures multivendor interoperability and easy integration of provisioning and other OSS in use at local exchange carriers.

• It enables the NE to meet the flow-through requirements specified by service providers.

• Integration of NE with embedded OSSs becomes much easier when the product is deployed.

• NEs have greater marketability and salability in the ILEC market.

10.2 Preparing Yourself for OSMINE Certification

Being an equipment vendor, you have to submit a few things along with your NE or EMS for OSMINE certification. The three major steps involved before submitting your NE are given below

10.2.1. Choosing the Telcordia's OSS for which integration of NE is required.

You need to decide on which OSS you NE should be interoperable. This depends on the application of your equipment. Telcordia has the following OSSs for management.

SERVICE PROVISIONING AND ACTIVATION SUITE Telcordia TIRKS® Telcordia Network Configuration Manager (NCON) Telcordia Transport Element Activation Manager (TEMS)

of 43

Telcordia LFACS Telcordia SWITCH® Telcordia Customer Network Manager (FLEXCOM)

SERVICE ASSURANCE SUITE Fault Management Telcordia NMA® System (NMA) Telcordia Surveillance Manager (SM)

PERFORMANCE MANAGEMENT Telcordia Network Performance Monitor (NPM) Telcordia Service Level Manager (SLM) Telcordia Network Capacity Manager (NCM)

10.2.2 Providing complete description of NE

You need to provide extensive documentation on the NE. It will be more like a user manual of the device.

10.2.3. Filling out NEIR form.

You have to fill the NEIR form ( Network Element Information Request) and submit along with the NE. This document will give a complete understanding of the NE to the people in Telcordia. The NEIR document requires the following information

• Physical layout • Hardware configuration • Network topology • Protection scheme • AID modeling • CLEI code • Supported input messages and autonomous messages.

10.3 How easy is it?

Though OSMINE process is expensive and time intensive, proper planning and implementation of TL1 interface makes OSMINE process much easier. For more details refer SR-683, Process Description of Operations Systems Modifications for the Integration of Network Elements (OSMINE) and also visit www.telcordia.com

of 43

11.0 Glossary Acknowledgment An acknowledgment is a short reply from the NE indicating that an input command message is being acted upon or has been immediately rejected. The essential purpose of an acknowledgment is to assure a user that a command that takes a long time to execute has been received by the NE. AID - Access Identifier AID is one of the blocks in the Staging Parameter Block of an input message .The Access IDentifier (AID) block normally consists of one or more parameters that uniquely identify the entity, within the target NE, to be acted upon by the input message. ATAG - Autonomous Tag ATAG is one of parameter in an autonomous message . 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. Autonomous message An autonomous message is an unsolicited message from the NE to the appropriate OS for reporting any event occurred in an NE. Circuit A circuit is a connection between two points used to provide a service to the customer. CLEC - Competitive Local Exchange Carrier A business authorized by the Telecommunications Act of 1996 that can deliver alternative dial-tone and other services using an incumbent carrier's equipment. CLEI - Common Language Equipment Identifier. Common Language Equipment Identifier, unique code assigned by Bellcore for label on each telecom device. CTAG - Correlation Tag CTAG is one of the blocks in the Staging Parameter Block of an input message .It contains one position defined parameter to serve as a means of correlating an input command with its associated output response. Delayed Activation Delay Activation is one of the features available in TL1. 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, either automatically or by a subsequent message from the OS. Digital Cross Connect(DCS) Digital cross connect or DCS is a device that switches channel between two or more transmission facilities.The types of network cross connections managed by a DCS can range from STSx to DSx. DS-N Digital signal-N is a term for the series of standard digital transmission rate. DS-

of 43

0=64kbps, DS-1=T-1=1.544 mpbs. Facility A facility is a transmission line or path. For example, STS1 is a facility. GNE - Gateway NE It is the NE that routes the input message from the manager to the appropriate NE. ILEC - Incumbent Local Exchange Carrier The companies that were in business before the CLECs. The highest-visibility ILECs are the regional Bell operating companies, or RBOCs. Input message An input command message is a message from an OS or other source to an NE. The message requests the NE to perform some operations-related action. NE - Network Element It is an equipment(node) in the network. For example, ADM (Add Drop Multiplexer ) is an NE. OC-N Optical Carrier, Level-N in SONET. OC-1 = 51.84 mpbs. OSMINE - Operations System Modifications for the Integration of Network Element. OSMINE Services is the integration process, which makes Telcordia OSSs and equipment providers Network Elements (NEs) compatible. The services provide NEs supported in various Telcordia OSSs, which are operational in service provider's networks . OSS - Operations Support System Operations Support System is a network management system used by telecom service provider o to provision, monitor, and maintain facilities. Output response An output response message is a detailed reply (or set of replies) to an input command message. It contains information indicating whether the command was executed successfully and any data needs to be returned to the OS/user. RBOC - Regional Bell Operating Company The regional telephone companies that resulted from the break-up of AT&T. Eighty percent of North American service providers are RBOC. SONET - Synchronous Optical Network A set of standards for optical transport. STS -N Synchronous Transport Signal, level N; electrical equivalent of OC-N. STS-1= 51.84 mbps. TID - Target Identifier TID is one of component in input message. It identifies the NE to which message to be routed. Gateway NE will make use of TID to route TL1 messages.

of 43

TL1 – Transaction Language -1 Transaction Language 1 (TL1) is an ASCII or man-machine management protocol used for managing Telecommunication networks. It is defined by Telcordia (previously known as Bellcore). T-N The T-carrier system is digital, using pulse code modulation and time-division multiplexing introduced by Bell Systems. T-1 = 1.544 mpbs , T-3=44.736 mpbs.

tl1 tutorial

Documents