Professional Documents
Culture Documents
GR–831–CORE
ISSUE 1, NOVEMBER 1996
OTGR SECTION 12.1
Comments Requested
(See Preface)
Operations Application
Messages - Language for
Operations Application
Messages
(A Module of OTGR, FR-439)
GENERIC REQUIREMENTS
GR–831–CORE
ISSUE 1, NOVEMBER 1996
Comments Requested
(See Preface)
Operations Application
Messages - Language for
Operations Application
Messages
(A Module of OTGR, FR-439)
Language for Operations Application Messages GR–831–CORE
Copyright Page Issue 1, November 1996
All trademarks and other marks are the property of their respective companies.
This document may not be reproduced without the express written permission of Bellcore
and any reproduction without written authorization is an infringement of Bellcore’s
copyright.
ii
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Notice of Disclaimer
GENERIC REQUIREMENTS
NOTICE OF DISCLAIMER
1. Bellcore Client Company (BCC), as used in this document, means any divested Bell Operating
Company, or its successor, or any regional affiliate thereof.
iii
Language for Operations Application Messages GR–831–CORE
Notice of Disclaimer Issue 1, November 1996
Readers are specifically advised that each BCC may have requirements or specifications
different from the generic descriptions herein. Therefore, any vendors or manufacturers of
products should communicate directly with a BCC to ascertain that company’s needs,
specifications and actual requirements.
Nothing contained herein shall be construed as conferring by implication, estoppel or
otherwise any license or right under any patent, whether or not the use of any information
herein necessarily employs an invention of any existing or later issued patent.
Bellcore does not recommend products and nothing contained herein is intended as a
recommendation of any product to anyone.
If further information regarding technical content is required, please contact:
Thomas F. Brantle
Network Management Foundation and Integration
Bellcore
331 Newman Springs Road, Room 3B-200
Red Bank, NJ 07701-5699
(908) 758-5562
For general information about this or any other Bellcore documents, please contact:
Bellcore Customer Service
8 Corporate Place
Piscataway, New Jersey 08854-4156
1-800-521-CORE (2673) (USA and Canada)
(908) 699-5800 (all others)
(908) 336-2559 (FAX)
iv
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 OTGR Contents and Ordering Information
OTGR Contents
FR-439, 1996 Edition (Sheet 1 of 4)
Document Document Issue/ Publication
Vol. Subset Sec. Number Title Rev. Date
[No Subset] 1.0 GR-471-CORE Introduction Issue 2 January 1995
FR-472 2.1 GR-472-CORE Network Element Issue 2 November 1996
Configuration
Network Element
Management
(NE) Memory
1
Administration 2.3 TR-NWT-000815 Network Element Issue 2 December 1992
Operations Security
2.4 GR-2934-CORE High-Speed Access for Issue 1 September 1996
Switch Network Element
Operations: Software
Management
FR-473 3.0 TR-TSY-000473 Network Maintenance: Issue 3 November 1989
Common
Network
Maintenance: 3.1 TR-TSY-000816 ISDN Basic Rate Access Issue 1 November 1989
Common Portable Test Set
2
[No Subset] 4.0 TR-NWT-000474 Network Maintenance: Issue 4 December 1993
Alarm and Control Network
Element
FR-475 5.1 GR-820-CORE Generic Digital Issue 1 November 1994
Transmission Surveillance
Network
Maintenance: 5.2 TR-TSY-000821 Additional Transport and Issue 1 June 1990
3
Transport Transport-Based Rev. 1 December 1991
Surveillance Surveillance Rev. 2 August 1993
Rev. 3 September 1994
v
Language for Operations Application Messages GR–831–CORE
OTGR Contents and Ordering Information Issue 1, November 1996
OTGR Contents
FR-439, 1996 Edition (Sheet 2 of 4)
Document Document Issue/ Publication
Vol. Subset Sec. Number Title Rev. Date
6.1 GR-818-CORE Generic Test Architecture Issue 1 December 1995
6.2 GR-819-CORE Special Services (SS) and Issue 1 December 1995
SS-Like Networks
6.3 GR-822-CORE Switched Circuits and Issue 1 December 1995
Public Packet Switched
Network (PPSN)
6.4 GR-823-CORE Integrated Services Digital Issue 1 December 1995
Network (ISDN)
FR-476
6.5 GR-1465-CORE Automatic Board-to-Board Issue 1 December 1995
3 Network Testing and DLC Cutover
Maintenance: Testing
Access
and 6.6 GR-1309-CORE TSC/RTU and OTAU Issue 1 June 1995
Testing Requirements for Remote
Optical Fiber Testing
6.7 GR-844-CORE TSC/RTU Generic Issue 2 November 1995
Requirements for Metallic
Loop Testing
6.8 GR-1402-CORE DS3 HCDS TSC/RTU and Issue 1 December 1995
DTAU Functional
Requirements
7.0 GR-477-CORE Network Traffic Issue 2 December 1995
Management
4 8.0 GR-478-CORE Measurements and Data Issue 2 December 1995
[No Subset]
Generation
9.0 Section reserved for future use.
FR-480 10.1 TR-TSY-000824 User System Access Issue 2 February 1988
User System 10.A TR-TSY-000825 User System Language Issue 2 February 1988
Interface (USL)
10.2 GR-826-CORE User Interface Generic Issue 1 June 1994
Requirements
11.0 TR-TSY-000481 Generic Operations Issue 4 June 1990
5 Interface: Overview Rev. 1 March 1991
FR-481 11.1 TR-TSY-000827 Non-OSI Communications Issue 1 November 1988
Architecture
Generic Operations
Interface 11.2 GR-828-CORE OSI Communication Issue 1 September 1994
Architecture Rev. 2 October 1996
11.3 TR-TSY-000829 Embedded Operations Issue 1 November 1989
Channels Rev. 1 September 1996
11.4 TR-TSY-000830 Operations Interworking Issue 1 June 1990
vi
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 OTGR Contents and Ordering Information
OTGR Contents
FR-439, 1996 Edition (Sheet 3 of 4)
Document Document Issue/ Publication
Vol. Subset Sec. Number Title Rev. Date
12.0 GR-811-CORE TL1 Messages Index Issue 2 February 1996
6 12.1 GR-831-CORE Language for Operations Issue 1 November 1996
Application Messages
7 12.2 GR-199-CORE Memory Administration Issue 2 November 1996
Messages
8 12.3 GR-833-CORE Network Maintenance: Issue 2 November 1996
Network Element and
Transport Surveillance
FR-482
Messages
Operations
9 12.4 GR-834-CORE Network Maintenance: Issue 2 November 1996
Application Access and Testing
Messages Messages
12.5 TR-NWT-000835 Network Element Security Issue 3 January 1993
Parameter Administration
Messages
10
12.6 GR-202-CORE Network Maintenance: Issue 2 November 1995
Loop Testing Messages
and the OS/TSC Interface
[No Subset] 13.0 TR-TSY-000483 Embedded Operations Issue 2 February 1988
Interfaces
FR-484 14.1 TR-TSY-000454 Supplier Documentation Issue 1 July 1988
11
for Network Elements Sup. 1 January 1994
Documentation,
Training, and 14.2 GR-839-CORE Supplier-Provided Training Issue 1 July 1996
Supplier Support Generic Requirements
14.3 TR-NWT-000840 Supplier Support Generic Issue 1 December 1991
Requirements (SSGR)
vii
Language for Operations Application Messages GR–831–CORE
OTGR Contents and Ordering Information Issue 1, November 1996
OTGR Contents
FR-439, 1996 Edition (Sheet 4 of 4)
Document Document Issue/ Publication
Vol. Subset Sec. Number Title Rev. Date
15.1 Section reserved for future use.
GR-836-CORE Information Model Issue 2 September 1996
Overview: Transport
Configuration and
Surveillance for Network
12 Elements
15.2 GR-836-IMD Information Model Details: Issue 2 September 1996
Transport Configuration
FR-801 and Surveillance for
Generic Operations Network Elements
Interfaces Using
OSI Tools
13 15.3 GR-376-CORE Network Data Collection Issue 2 September 1996
(NDC)
15.4 GR-495-CORE Network Traffic Issue 2 September 1996
Management
15.5 GR-1469-CORE Generic Requirements on Issue 1 September 1994
Security for OSI-Based
14
Telecommunications
Management Network
Interfaces
15.6 GR-1031-CORE Test Access Management Issue 1 February 1996
Note:
This document is a module of the Operations Technology Generic Requirements (OTGR),
FR-439. The OTGR can be ordered as a complete set, as sections, or as individual modules.
• If the entire set is ordered, select FR-439, and all 15 sections with their subordinate
modules will be delivered.
• If a specific section is required, e.g., Section 12, Operations Application Messages,
select FR-482, and all seven modules of this section will be delivered.
• If one module is requested, e.g., Section 12.1, Language for Operations Application
Messages, select GR-831-CORE, and this single module will be delivered.
viii
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 OTGR Contents and Ordering Information
Ordering Information
To order modules, sections, or the entire OTGR:
• Public should contact:
Bellcore Customer Service
8 Corporate Place, Room 3A-184
Piscataway, New Jersey 08854-4156
1-800-521-CORE (2673) (USA and Canada)
(908) 699-5800 (all others)
(908) 336-2559 (FAX)
• BCC personnel should contact their company document coordinator
• Bellcore employees should call the Bellcore Document Hotline: (908) 699-5802.
Any Questions?
If you have any questions concerning the technical content or structure of the OTGR, please
call the OTGR Hotline at (908) 758-2232.
ix
Language for Operations Application Messages GR–831–CORE
OTGR Contents and Ordering Information Issue 1, November 1996
x
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Contents
Contents Contents
Preface ...................................................................................................................Preface–1
1. Introduction ...............................................................................................................1–1
1.1 Transaction Language 1 (TL1)........................................................................1–1
1.2 Organization of Document ..............................................................................1–2
1.3 TL1 Historical Perspective..............................................................................1–3
1.4 Requirements Terminology.............................................................................1–5
1.5 Requirement Labeling Conventions................................................................1–5
1.6 Requirements Statement..................................................................................1–5
2. TL1 Message Specification.......................................................................................2–1
2.1 TL1 General Message Syntax .........................................................................2–1
2.1.1 Input versus Output ............................................................................2–2
2.2 Characters and Information Units ...................................................................2–3
2.2.1 Identifiers ...........................................................................................2–3
2.2.2 Symbolic Names ................................................................................2–3
2.2.3 Decimal Numbers...............................................................................2–3
2.2.4 Nondecimal Numbers.........................................................................2–4
2.2.5 Text Strings ........................................................................................2–4
2.2.6 Arithmetic Expressions ......................................................................2–4
2.2.7 Keyed Numbers..................................................................................2–4
2.2.8 Numeric String ...................................................................................2–5
2.2.9 Integer ................................................................................................2–5
2.2.10 Inner String.........................................................................................2–5
2.3 Parameter Block Syntax ..................................................................................2–5
2.3.1 Position-Defined Parameters..............................................................2–5
2.3.2 Name-Defined Parameters .................................................................2–6
2.3.3 Name/Position Syntax Conflicts ........................................................2–6
2.4 Boolean Flag Parameters.................................................................................2–7
2.5 Defining a Parameter Block ............................................................................2–7
2.5.1 Parameter Specification .....................................................................2–7
2.5.2 Block Type Selection .........................................................................2–8
2.6 Defining Parameter Values .............................................................................2–8
2.6.1 Compound Arguments .......................................................................2–9
2.6.2 Grouping of Arguments .....................................................................2–9
2.7 Implementation Issues...................................................................................2–10
2.7.1 Correction Characters and Comments .............................................2–10
2.7.2 Restrictions on Nondecimal Numbers and Arithmetic Expressions 2–10
xi
Language for Operations Application Messages GR–831–CORE
Contents Issue 1, November 1996
xii
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Contents
xiii
Language for Operations Application Messages GR–831–CORE
List of Figures Issue 1, November 1996
xiv
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 List of Tables
xv
Language for Operations Application Messages GR–831–CORE
List of Tables Issue 1, November 1996
xvi
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Preface
Preface Preface
The following text describes the Bellcore generic requirements process in effect as of
February 7, 1996, that is applicable to this document. Process changes for certain future
generic requirements reflecting the procedures under the Telecommunications Act of 1996
are expected to be announced by Bellcore in its DIGEST of Technical Information as they
evolve.
Generic Requirements (GRs) provide Bellcore’s view of proposed generic criteria for
telecommunications equipment, systems, or services. GRs are available through a
subscription ordering process from Bellcore. A one-time subscription fee entitles the
subscriber to receive the baseline GR (GR–CORE) along with the Issues List Report (GR–
ILR) and revisions released until the entire package is reissued. Each baseline GR outlines
Bellcore's intended release plans. Bellcore is making the transition to the new GRs from the
former Framework Advisories (FAs), Technical Advisories (TAs), and Technical
References (TRs). Bellcore will identify the stage or phase of any particular release and the
level or expectation of any industry or subscriber interaction.
FA-TA-TR to GR
Bellcore GRs represent a change from the former generic requirements document releases
known as FAs, TAs, and TRs, which reflected a relative maturity level of the proposed
requirements. The new GR integrates those three versions into a single entity. When
appropriate, industry members will be invited to participate in the early development stage
of these requirements. Depending on the extent of early interactions, the first release of a
new GR may have fewer issues to be resolved than the “traditional TA or TR” because
many of the issues that normally would have surfaced during the Open Comment Period
would have been addressed, and possibly resolved, before release of the GR. Maturity level
and completeness of the individual requirements enumerated in the GR and the full GR
itself will be identified in the document's Preface, the Introduction, and throughout the
document as necessary. Terms such as early development, preliminary, or relatively mature
will communicate maturity level to the subscriber.
Preface–1
Language for Operations Application Messages GR–831–CORE
Preface Issue 1, November 1996
along with status or proposed resolutions, and publish them in the form of a GR Issues List
Report (ILR). Bellcore will respond to all comments, whether directly to the submitter or
through the ILR.
In Bellcore’s view, not all comments submitted need become issues requiring subscriber/
industry review, nor may they be germane or suitable to Bellcore's proposed generic
requirements. The ILR is not intended to specifically identify comment submitters by name
or company. It reflects a distillation and compilation of all appropriate comments that
address specific technical issues having an impact on the requirements as originally
presented in the GR, and, that in Bellcore's view, need further subscriber/industry review.
The ILR may also contain suggested editorial or clarification changes or corrections.
The ILR will automatically be provided to all subscribers of this GR. It is intended to be
the means to convey information about the status of the technical requirements and to open
dialog on any proposed changes before such changes are finalized. Subscribers are
encouraged to comment after reviewing the ILR. When appropriate, significant changes or
additional material may also be released as revisions to the GR-CORE. The initial or
baseline GR-CORE, the most current ILR, and any published revisions constitute the most
up-to-date version of these proposed generic requirements. As necessary, the entire
package may be reissued to incorporate all changes. Notification will be released in the
Bellcore DIGEST announcing ILRs, revisions, or planned complete reissues.
The contents of this GR are in the mature development stage. Earlier editions of GR-831-
CORE have been published previously in TA/TR form (e.g., TR-NWT-000831, Issue 3,
July 1993, Revision 1, December 1993). GR-831-ILRs are potentially planned during
1997. These reports will contain ongoing issues resulting from supplier comments on this
GR.
Formatting Comments
To facilitate review of and response to your comments, Bellcore would appreciate your use
of the following format:
A. Identify the GR #, Issue #, and Date.
B. Identify comments by citing the corresponding section, paragraph, requirement, or
Issue ID number(s) used in the GR or in the ILR, and group comments within these
headers:
1. General/Overall Comments
2. Major Business Issues/Concerns
Preface–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Preface
While comments are welcome at any time, release of ILRs or revisions may depend on
either the extent and complexity of comments submitted and/or Bellcore’s planned
schedule for such releases. Bellcore plans to update this GR over the next year. To meet
this schedule, send your comments in writing by March 31, 1997.
Please send to:
Bellcore — GR–831–CORE
Thomas F. Brantle
331 Newman Springs Road, Room 3B-200
Red Bank, NJ 07701-5699
(908) 758-5562
Preface–3
Language for Operations Application Messages GR–831–CORE
Preface Issue 1, November 1996
Preface–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Introduction
1. Introduction
GR-831-CORE, OTGR Section 12.1: Operations Application Messages - Language for
Operations Application Messages, provides implementation level requirements for
Transaction Language 1 (TL1). TL1 is used in the input and output messages that pass
between Operations Systems (OSs) and Network Elements (NEs). Operations domains
such as surveillance, memory administration, and access and testing define and use TL1
messages to accomplish specific functions between the OS and the NE.
The remainder of this section includes
• An overview of TL1 (Section 1.1)
• The organization of this document (Section 1.2)
• A TL1 historical perspective (Section 1.3)
• Requirements terminology (Section 1.4)
• Requirements labeling conventions (Section 1.5)
• The GR-831-CORE requirements statement (Section 1.6).
1–1
Language for Operations Application Messages GR–831–CORE
Introduction Issue 1, November 1996
MESSAGE
INPUT OUTPUT
1–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Introduction
In 1984, following the divestiture of the Bell Operating Companies from the American
Telephone and Telegraph (AT&T) company, it was realized that, in order to provide an
environment in which products from many suppliers could interact within the
telecommunications network, a single operations interface must be defined to which all
suppliers could conform. That is, with a common operations interface, the proprietary
aspects of the many varieties of NEs making up the telecommunications network would be
hidden from the OSs deployed to manage the network. It was noted that the majority of the
operations functions use short message constructs, or Transactions, to initiate,
communicate, and cause execution of specific actions at some remote NE site. Many, but
not all, of these transactions require two-way interactive exchange of related messages.
1–3
Language for Operations Application Messages GR–831–CORE
Introduction Issue 1, November 1996
1–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Introduction
This section describes the labeling conventions of proposed requirements and objectives,
as part of Bellcore's new GR process.
Each Requirement, Objective, Condition, Conditional Requirement, and Conditional
Objective object is identified by both a local and an absolute number. The local number
consists of the object's document section number and its sequence number in the section
(e.g., R3-1 is the first Requirement in Section 3). The local number appears in the margin
to the left of the Requirement. A Requirement object's local number may change in
subsequent issues of a document if other Requirements are added to the section or deleted.
The absolute number is a permanently assigned number that will remain for the life of the
Requirement; it will not change with new issues of the document. The absolute number is
presented in brackets (e.g., [2]) at the beginning of the requirement text.
Neither the local nor the absolute number of a Conditional Requirement or Conditional
Objective depends on the number of the related Condition(s). If there is any ambiguity
about which Conditions apply, the specific Condition(s) will be referred to by number in
the text of the Conditional Requirement or Conditional Objective.
References to Requirements, Objectives, or Conditions published in other Generic
Requirements documents will include both the document number and the Requirement
object’s absolute number. For example, R2345-12 refers to Requirement [12] in GR–2345.
R1-1 [1]The syntactic and semantic rules for TL1 as described in this document
shall be supported by the NEs and OSs, although each application-specific
message may employ only a subset of these rules.
1–5
Language for Operations Application Messages GR–831–CORE
Introduction Issue 1, November 1996
1–6
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Message Specification
The term language, as applied here, is intended to cover all the rules and prior agreements
necessary for a message to carry meaning from one application program to another or from
a person to an application program. The specification of a language can be structured in
layers, in direct analogy to the protocol layers. A suitable set of layers is as follows:
• Syntax is the set of rules that relates the individual tokens (words) within a message to
each other. The TL1 syntax is divided into four basic areas:
— Input command messages from an OS toward an NE
— Acknowledgments from an NE toward an OS
— Output response messages from an NE toward an OS
— Autonomous messages from an NE toward an OS.
• Semantics is the meaning of the individual words.
• Information Structure refers to the names and associated meanings of groups of such
words, syntactically related.
• Intermessage Context deals with the relationship between messages (e.g., the
association of a response with a preceding command).
• Pragmatics defines the activity to be carried out by the receiving application program,
including access to a database and the appropriate generation of error messages.
Pragmatics include the actual specification of commands and their associated
responses.
This document focuses on the syntax and semantics of TL1.
2–1
Language for Operations Application Messages GR–831–CORE
TL1 Message Specification Issue 1, November 1996
The following specification characters (see Table 2-1), akin to the Backus-Naur Form
(BNF), are used throughout this document as a vehicle for defining the syntax:
The syntax for input messages and output messages is considerably different. Among the
fundamental differences are the application of format effectors, particularly spaces,
linefeeds, and carriage returns. As defined later, format effectors are meaningless when
present in input messages and may or may not be ignored in output messages.
Input messages group parameters into blocks separated by colons and, within parameter
blocks, separated by commas; parameters may be further modified with compounding,
ranging, and incrementing operators.
2–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Message Specification
Appendix A gives the character set specified by TL1. Some of the characters are
unspecified and reserved for implementation-dependent use. The basic elements of the
language are built from these characters. These basic elements represent units of
information and punctuation.
When defining new messages, it is important to realize that the words selected for use must
belong to one of the categories called information units. Only these information units,
punctuation characters, and the ancillary facilities of Appendix A can appear in commands.
Within input messages format effectors1 (i.e., spaces, tabs, carriage returns, etc.) are
completely ignored, except within text strings, and thus do not terminate information units.
For example, within a command, COMMAND CODE and COMMANDCODE are treated
in exactly the same way. Within output messages, format effectors may or may not be
ignored (see Sections 4, 5, and 6). The backslash (\) character will be used for escape syntax
within text strings (see Appendix A), i.e., causes the character following to be literally
interpreted.
Appendix A specifies the fourteen types of TL1 information units. This section gives an
informal description with examples.
2.2.1 Identifiers
An identifier starts with a letter and is followed by any number of letters or digits. For
example, A, abc, and xy50 are valid identifiers.2
A symbolic name must contain at least one letter, plus-sign (+), pound-sign (#), or percent-
sign (%) and optionally any digits. For instance, #7SWS, 1A0, 10%, and abc are all valid
symbolic names.
A decimal number is a string of decimal digits with an optional non-trailing period (.). It
does not permit a leading plus-sign (+) or hyphen (-), or have any provision for exponential
1. Format effectors are the six ASCII characters of horizontal tab, vertical tab, space, form feed, line feed,
and carriage return.
2. Note although lowercase is allowed, uppercase is the norm for most implementations. See Section
2.7.3, Case Sensitivity, for further information.
2–3
Language for Operations Application Messages GR–831–CORE
TL1 Message Specification Issue 1, November 1996
notation. Some examples are 88, .005, and 004.100, but 12. is not valid because of the
trailing period (.). Leading zeros are optional except for values constrained to a fixed
format (e.g., date and time).
The optional leading D' (D apostrophe), indicating a decimal number, shall be permitted
only in a particular parameter if it is so stated in the semantics of the command involving
that parameter.
The nondecimal number types, hexadecimal, octal, binary, and keyed, as defined in
Appendix A, will be permitted in TL1 only in a particular parameter if it is so stated in the
semantics of the command involving that parameter.
A text string is any string of ASCII (alphanumeric and/or punctuation) characters (see
Section A.3, Table A-1) enclosed in double-quotes ("). This allows a great deal of
flexibility in defining values because the limitations of identifiers and symbolic names are
overcome at the small cost of quoting the characters for message entry. To enter a double-
quote (") character within a text string, an escaped double-quote (\") is used.
In TL1, arithmetic expressions are used to represent explicitly signed, positive or negative
decimal numbers. The syntax is an optional plus (+) or minus-sign (-), followed by a string
of decimal digits with an optional non-trailing period. The entire expression is contained
in parentheses to prevent parsing ambiguities. Examples of legal arithmetic expressions are
(12), (-15), (+137.038), and (67.23).
Keyed numbers are used to express values that can be entered on an extended (4X4)
telephone keypad. The format is an optional K' (K apostrophe) followed by a string of
decimal digits, the uppercase letters A through D, the asterisk (*), or the pound-sign (#).
2–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Message Specification
A numeric string is a subtype of decimal numbers consisting of only decimal digits. Each
digit in the string is an ASCII representation of a numeric digit.
2.2.9 Integer
An inner string is similar to a text string but is used only within quoted lines of output
messages (see Sections 5 and 6). Because the double-quote character (") has already been
used to enclose the line, another symbol is needed to bracket text containing punctuation or
other special characters. The symbol used is the escaped double-quote (\"). Within an inner
string, a literal double-quote (") is represented by double double-quote (""), and a literal
backslash (\) by double backslash (\\).
For example
"<startTextString>\"<startInnerString>""<and>
\\<endInnerString>\" <endTextString>"
A parameter block always follows a colon and contains a (possibly empty) list of
parameters, separated by commas. In TL1, trailing colon (:) block separators may be
omitted if there are no parameters entered in those last blocks. The parameter syntax, in
general, consists of an optional parameter name, equal-sign (=), and a parameter value.
However, the precise use of these options depends on the type of parameters entered in that
block. A block shall only contain all position-defined parameters or all name-defined
parameters. These two formats are characterized in the following subsections.
2–5
Language for Operations Application Messages GR–831–CORE
TL1 Message Specification Issue 1, November 1996
necessary in a positional block, where it is the order of parameter entries that associates
each value with the corresponding parameter. Some examples of valid position-defined
parameter blocks are given in the following:
: 5, 6, Yes:
: , 6:
TL1 permits omission of commas following the last non-null parameter in a block.
For a block of name-defined parameters, every parameter entry must have a parameter
name and value, with successive entries made in arbitrary order. Parameter names are
always transmitted with name-defined parameters (and order is not significant nor
required).
The use of void parameters, indicated by adjacent separators, is valid only for positional
entry and not for name-defined entry. Parameter defaulting is done by omitting a parameter
entry. Three equivalent examples of a block of name-defined parameters are shown in the
following (assuming the default values are as in the first example):
: P1=1.0, P2=2.0, P3=off:
-or-
: P3=off, P1=1.0:
-or-
: P2=2.0:
The syntax of an entered block of parameters must be consistent with either a name-defined
or a position-defined syntax. The following rules characterize resolution of potential syntax
conflicts:
In TL1, a parameter block must be position-defined if:
• Any parameter values appear without parameter names (i.e., without NAME=)
• Any void parameters (indicated by adjacent separators) appear.
Otherwise, the parameter block has valid syntax for both a position-defined and a
name-defined block.
In the case of position-defined parameters, entered parameter names must match the
defined parameter positions. If more parameters are entered than are defined, the block is
in error. But if fewer are entered, defaults are applied to the trailing parameter positions.
2–6
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Message Specification
When names are attached to all parameter entries, the association of the entry with the
parameter definition is clear. If a parameter name appears more than once, an error will be
generated. If a parameter does not appear at all, the parameter defaults to the specific
default action defined for that particular parameter of that particular command.
In some messages, Boolean parameters (e.g., on/off, yes/no) might be needed. A possible
implementation is to represent one state by the presence of a symbol and the other by its
absence. To minimize the introduction of new symbols, the parameter value symbol chosen
may be the parameter name. While this mechanism is perfectly legal under TL1, it should
be emphasized that the parameter actually has two values: the parameter name value
represents one state, while a null symbol represents the (default) other state. This
representation, whenever used, should be clearly explained in the parameter description.
The parameter block syntax described previously defines the general form of entry for
parameters in an arbitrary block. The syntax is a message-independent format that can be
verified without any knowledge of the block semantics, such as parameter names and
positions. In this section (2.5) and the next (2.6), the focus is on the syntax-related
semantics that apply universally to all parameter blocks.
To check the block semantics, it is necessary to have a block definition that specifies all
valid parameter names and positions for each block of each specified command. This
requires an appropriately ordered list of uppercase TL1 identifiers, each unique to the
block, to serve as parameter names. When describing the syntax for any TL1 message, each
parameter, regardless of whether it is intended for position or name defined entry, must be
represented by a unique name (i.e., <aid> or AID =). Along with parameter names, the valid
parameter values and their functional interpretations need to be specified.
Furthermore, the block type must be specified for each block, as position-defined or name-
defined. Each parameter block must be transmitted in the format corresponding to its block
type. It is also required that the parameter names be transmitted in their uppercase form.
2–7
Language for Operations Application Messages GR–831–CORE
TL1 Message Specification Issue 1, November 1996
Positional entry is useful when most of the defined parameters are entered. Efficiency is
increased because the parameter names are not transmitted and only commas and values
are sent. Since trailing commas may be suppressed, positional entry can also be an efficient
way to enter leading parameters with trailing commas omitted. The use of positional
parameter entry also reduces the time needed for parameter name searching.
One disadvantage of positional entry occurs when a block has many defined parameters
with only a few entered on a particular message request. In this case, all leading commas
must be transmitted, making it somewhat less efficient when only a small number of
parameters are being transmitted. Another advantage of name-defined parameters comes in
providing more flexibility to add parameters in the future without regard for previously
established parameter order, and still retaining compatibility with the previous version of
the message.
A parameter value consists of one or more TL1 information units that may be compounded
and/or grouped together as described in the following subsections. When a parameter is
defined for a particular command, the valid range of parameter values must be defined,
along with its interpretation. This includes the implicit set of units associated with any
numeric values.
Although there are exceptions, usually parameter values are interpreted as character strings
that must match exactly or as numeric values that must satisfy a given range. When numeric
values are specified, they must have a default base associated with them. This will normally
be the decimal base, but it may be binary or any other semantic interpretation desired for
that parameter. For TL1, the use of non-decimal numbers is not supported in general. If it
is necessary to allow a parameter to be entered in bases other than its default base, it must
be specifically stated in that parameter's description.
For non-numeric parameter values, typically a list of character strings will specify their
valid values. The parameter values, unlike parameter names, are case sensitive,1 e.g., the
identifiers A1 and a1 do not match.
A particular parameter may have a valid range that includes both numeric and character
values. For example, a parameter SETTING may take on values of 0 to 15, the identifier
NONE or the text string "N/A". Note that the slash (/) in "N/A" requires that it be entered as
a text string.
2–8
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Message Specification
Closely related information can be compounded into one parameter value by joining the
information units with the hyphen character (-). For example, it may be desirable to use one
parameter, LOCATION, to represent two map components, one given by a letter and the
other by a number. LOCATION = A-21 can be used for this purpose.
Compounding is equivalent to two separate positional parameters combined into one, but
compound fields cannot be omitted the way positional parameters can [e.g., A--C is invalid
syntax but A-null-C (where null is a literal parameter value meaning the parameter is
missing) or A-""-C could be specified for use in a particular command]. It is also
permissible to specify both simple and compound values for the same parameter.
Both simple and compound arguments may be grouped together so one parameter may
actually convey several arguments. This is done by using the connectors ampersand (&)
and double-ampersand (&&).
The ampersand (&) character is most useful when a parameter takes on any combination
of arguments in a specified set. If there are three OPTIONS (e.g., x, y, and z) that can be
selected in any combination, some possible entries could be OPTIONS = x&z or OPTIONS
= x&y&z.
The use of double-ampersand (&&) is reserved for expressing ranges of values. An
example of this usage is RANGE = 1&&10 to enter the values 1,2,3,...,10. Compound
parameters may be also grouped, but note that double-ampersand (&&) can only be used
to range over the last field of the compound parameter (e.g., 2-5-1 && -10 means 2-5-1 &
2-5-2 & ... & 2-5-10).
In TL1, the use of double-ampersand (&&) for ranges shall not be used for a particular
parameter unless it is specifically stated in the semantics of the parameter. In such cases,
the ordering of parameter values must be defined. Unless otherwise stated, it will be
assumed that numeric values have the usual ordering.
It is possible to use increments with && ranges. For example, in RANGE = 2 && 10 .++.
2, the increment value 2 following .++. indicator is used to represent even integers from 2
to 10. TL1 uses the characters .++. instead of ++ to avoid an ambiguity that is described
in the following subsection.
2–9
Language for Operations Application Messages GR–831–CORE
TL1 Message Specification Issue 1, November 1996
This section specifies implementation-related decisions and options. Most options are
related to restrictions on the form of the input commands, which allow an NE to implement
a TL1 command interpreter that is simpler and more efficient than the one needed for the
full human-to-NE capabilities. Some implementations may choose to take advantage of the
TL1 command restrictions to conserve real-time, while others may prefer the extra
reusability of the User System Interface software. Section 2.7.4 discusses these and other
issues.
Any correction characters that may be used on the User System Interface (e.g., delete last
character and delete last line) will have no special meaning in TL1, but will be interpreted
literally. This implies that all corrections must be performed before the command is
transmitted; otherwise, the character will most likely produce invalid syntax. The only
correction that can be used is the delete command, which is conveyed by the ASCII {CAN}
character (cancel). It cancels all present input after the last command, that is, everything
since the last semicolon character.
Because comments do not convey any syntactic or semantic information to the NE, an OS
will not transmit them in input commands.
Nondecimal numbers and arithmetic expressions are not used in TL1 in a general way.
They may not be entered arbitrarily into any numeric parameters, but only in those
particular parameters for which it is specifically allowed by the specification of that
parameter's semantics. Because explicit nondecimal numbers (i.e., those using H', O', and
B') are rarely required, most NEs will not need to recognize and process them. Only those
NEs that support commands requiring explicit nondecimal numbers will need to implement
this feature.
Because every parameter that takes on numeric values has a default (or implied) base
associated with it, the use of H', O', B', and D' are only necessary to indicate that the
following value is not in its default base. Because a requester will send the values in the
default base, and because hexadecimal, octal, and binary numbers can all be represented as
decimal numbers, identifiers, or symbolic names (e.g., 10, A2, 1C, respectively), there is
no need to support the extra nondecimal information units.
Arithmetic expressions are not supported in general, but because decimal numbers are
unsigned, a restricted form of arithmetic expressions is necessary in some commands to
2–10
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Message Specification
where the specifier <sign> can take on the characters plus-sign (+), hyphen (-) or be
omitted. For example, valid arithmetic expressions include (5.0), (-.001), and (+5.0). If the
<sign> is omitted, default is plus-sign (+) and the parentheses could be omitted.
This section discusses issues of character case and, for emphasis, is presented in two parts.
• Command Codes and Parameter Names
• Parameter Values.
Historically, for Command Codes and Parameter Names, TL1 was meant to be case
insensitive even though all Command Codes and Parameter Names were specified as
uppercase characters. To ease the restriction on users entering Input Messages directly to a
NE, lowercase characters were allowed on the interface and the NE was obligated to
translate lowercase character to uppercase before processing the message.
Output Message descriptions have always been documented using uppercase constructions
with no expectation that translation need occur at either a NE or an OS.
In other words, a NE should expect and be prepared to handle Command Codes and/or
Parameter Names in uppercase, lowercase, or mixed case (combinations of uppercase and
lowercase within an Input Message, a Command Code or a Parameter Name).
There are no case restrictions placed on Parameter Values for TL1 Input or Output
Messages. Parameter Values may be either uppercase or lowercase exclusively or in any
combination to accommodate the NE's internal implementation.
In particular, TL1 rules do not suggest or infer that any character mapping of Parameter
Values be done, by either the NE or the OS, with respect to character case. As always, OS
implementations may require that a particular convention be adopted for consistency of
data as represented in master record keeping systems.
2–11
Language for Operations Application Messages GR–831–CORE
TL1 Message Specification Issue 1, November 1996
There was a potential ambiguity to the TL1 command syntax. Consider the following
invalid TL1 expression.
<simple arg> && <simple arg> ++ <decimal number>
The use of double plus-sign (++) as a separator and also as an element in symbolic names
causes a problem, as illustrated in the following example. The parameter value
first&&last++2 can be lexically analyzed as (first) && (last) ++ (2) or as (first) &&
(last++2), because last++2 is a valid symbolic name.
In almost any other context, last++2 would be treated as a symbolic name, but here it is
probably intended to be last ++ 2. Rather than forcing the interpretation to be sensitive to
the context, it is more sensible to change the increment separator. TL1 will use the four
characters period double plus-sign period (.++.) instead of double plus-sign (++) to
resolve this potential ambiguity.
Therefore, the above invalid TL1 expression should be corrected as:
<simple arg> && <simple arg> .++. <decimal number>
2–12
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Input Command Message Structure
Each command must begin with a command code consisting of a mandatory verb followed
by up to two other optional modifiers, each separated by a hyphen.
<command code> ::= <verb>[-<modifier>[-<modifier>]]
3.2.1 Verb
The semantics of the verb are to identify the action to be taken at the NE as a result of
receiving a TL1 message from an OS. The semantic values of the verb are defined within
the context of the functional application in which the message is intended to be used (e.g.,
ENT, ED, RTRV). A list of TL1 verbs is in Appendix C.
3.2.2 Modifiers
The command code modifiers are optional depending upon the specific command and the
application domain. In normal TL1 command usage, the first modifier identifies the object
of the verb where the action is to be applied in the NE. The second modifier further
3–1
Language for Operations Application Messages GR–831–CORE
Input Command Message Structure Issue 1, November 1996
modifies the object of the verb and is interpreted differently for different operations
domains.
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 a DS0 circuit (where T0 indicates transmission hierarchy level 0).
As another example, for switching NEs, the command <verb>-<administrative view>
indicates an action is to be taken on an object entity within the specified administrative view
of the switching NE database.1
The second modifier may be used to further define the identity of the object upon which the
action is to be taken. For example, the command DLT-CRS-T0 will disconnect (DLT) one
or more cross-connected (CRS) DS0 object entities (T0). That is, the modifier CRS is
further defined to identify T0 object entities.
Where suitable, verbs and parameter names have been selected from COMMON
LANGUAGE® documentation.2
Each block contains one or more specifically defined parameters, which are described in
the following subsections. The parameters within each staging block may either be
position-defined or name-defined. Normally a block with a simple parameter will include
1. The information groupings within a switching NE are called administrative views, in which individual
data elements are represented in the form of flat tables or matrices. Each row of an administrative view
represents an object entity; each column represents an attribute (parameter) shared by all of the object
entities in the view. An administrative view is similar in concept to relations in relational database
theory.
COMMON LANGUAGE is a registered trademark and CLEI, CLLI, CLFI, and CLCI are trademarks
of Bellcore.
2. See BR-751-000-101, ST-STS-000122, ANSI T1.201-1987, and ANSI T1.205-1988.
3–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Input Command Message Structure
a position-defined parameter. Blocks with more than one parameter (e.g., the general
block) may use the name-defined construct for the parameters in the 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 NEs or
other devices (which may perform mediation functions). The Target Identification (TID)
code parameter block provides the capability within the TL1 message format to perform
network routing tasks that are normally handled using features at lower layers of a
communications protocol.3 The presence of the TID in all input commands is a
requirement, but its value may be null (i.e., the TID is represented by two successive
colons).
When used, the TID block contains a single position-defined parameter that identifies the
end-target NE to which the input command is directed. An example of TID usage is for
indirect addressing of NEs by transferring subnetwork or gateway path information to
reach the target NE. The value of TID may be any valid simple or compound TL1 identifier
or text string, but it is limited to 20 characters.4 TIDs are configurable items that can be
defined using TL1 provisioning-driven messages. Where appropriate, the TID may assume
a default value equal to the System Identification (SID) code returned in a response
message from an NE. These two identifiers are otherwise independent of each other.
The following guidelines shall be applied in the assignment and application-specific use of
TIDs.
A. A single TID should be assigned to a system meeting a TL1 interface; criteria such as
the following should be used to determine when a single TID is appropriate:
1. Operations functions treat the system components collectively as a single entity.
2. TL1 commands that affect several components in the same way are issued as a
single message.
B. The assignment of multiple TIDs to a system that meets a TL1 interface is not
precluded. For example, if there are multiple subsystems for which no common
operations functions are required or supported, then multiple TIDs may be used. The
following guidelines should be observed in such cases:
1. Use of multiple TIDs at a TL1 interface shall only be done on an exceptional basis.
3. Normally, TL1 messages are sent above the CCITT X.25 protocols as described in TR-TSY-000827.
When used in this way, routing services are provided by the underlying protocols.
4. Important: Note that if either the TID or System Identifier (SID) contains any non-identified
characters (not made up of only letters and digits) such as spaces, the text string form must be used
(i.e., enclosed in double quotes).
3–3
Language for Operations Application Messages GR–831–CORE
Input Command Message Structure Issue 1, November 1996
2. Bilateral concurrence on the use of TIDs in these cases shall be required across all
anticipated applications.
C. A single NE, and thus a single TID, should be associated with the CLLI code of the
physical port associated with the entity meeting the standard TL1 operations interface.
The Access Identification (AID) block normally contains one (or more) simple or
compound parameter(s) that uniquely identifies the entity within the target NE to be acted
upon by the input message to the NE. 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.
Cross connecting two channels calls for two access parameters — one representing the
FROM channel and the other the TO channel. The AID values for this case are of the form:
:[FROM=]<channel no.>,[TO=]<channel no.>:
where the keywords FROM and TO are implicit and need not be included in the AID
character string (i.e., the two parameter values are position-defined).
Another circuit example is the representation of digital facilities that have an inherent
hierarchical structure. Typically, the hierarchy is based on the nesting of lower
transmission rates within higher ones. For example, a DS3 facility (44.736 Mb/s) has 28
DS1 channels (1.544 Mb/s) nested within it. Thus, a single DS1 in such an NE could be
addressed with a compound AID value as follows:
:<ds3>-<ds1>:
That is:
:3-24:
specifies the 24th DS1 within the third DS3. The facility addressing capabilities will vary
among NEs, but this example illustrates the concept of entity addressing within a facility
hierarchy.
3–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Input Command Message Structure
Similarly, some equipment has an inherent hierarchical structure that can be used when
addressing such entities. In this case, the hierarchy is based on the physical arrangement of
the equipment units. For example, a plug-in may be located in a slot on a shelf within a
frame. Thus a single plug-in, in such an NE, could be addressed with a compound AID
value as follows:
:<frame>-<shelf>-<slot>:
That is:
:1-3-6:
specifies the sixth slot in the third shelf within the first frame. Equipment addressing
capabilities will vary among NEs, but this example illustrates the concept of equipment
hierarchical addressing.
A database object entity may require a combination of parameter values for unique
identification. For example, an AID value of the form
:<group>-<group_member>:
is a compound value by which a target object entity is identified uniquely as part of a group
(e.g., trunks within a trunk group).
3–5
Language for Operations Application Messages GR–831–CORE
Input Command Message Structure Issue 1, November 1996
Similarly, for sequential compound key parameters, the first and last group members are
separated by two ampersands followed by a hyphen, as follows:
:<grp>-<first_mbr_key>&&-<last_mbr_key>:
OS-to-NE testing operations illustrate the use of an AID parameter value that is a substitute
(i.e., alias) representing the identity of the objects under test.
One such example is the use of a Test Session Number (TSN) as an alias value. An OS may
establish a testing session with an NE or and intermediate Test System Controller/Remote
Test Unit (TSC/RTU), and assign a unique number to that session. That is, a test
initialization message may be sent from the OS of the form:
CONN-TACC:<tid>:<aid>:<ctag>:<tsn>:<parameters>;
where the <aid> is the identity of the object to be tested and the <tsn> value is the TSN
(Test Session Number) assigned by the OS.5 That session number may then be
subsequently used as an alias AID value representing the object(s) being tested in that
session. That is, subsequent testing commands within that session may be aliased in the
AID parameter block with input messages of the form:
MON-DDS::<tsn>:<ctag>:<parameters>;
where the TID block value is NULL and the value of the AID block is <tsn>. All
subsequent input messages within that session may then identify a specific circuit or unit
of equipment initially identified when the session was established, with the session number,
(TSN), as a substitute (alias) for that circuit level or equipment level address.
Another example is the establishment of a connection between a Test Access Path (TAP)
and a circuit. Once the TAP connection is established, the TAP number may be used as an
alias AID value as long as the connection is maintained between the TAP and the circuit.
5. For historical reasons, the General Block (GB) as Section 3.3.4 describes, has not been implemented
for TL1 messages originating at a Testing Operations System. The TSN parameter is a single position-
defined parameter in place of the GB in test initialization messages. Subsequent testing operation
messages do not have a GB block.
3–6
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Input Command Message Structure
When the first modifier of an input message command code identifies an administrative
view of a database within an NE, the content and format of the AID block of the message
depend on the access method specified by the semantics of the command code modifier.
For example, consider a case where the administrative view represents the subscriber lines
in a switching NE (i.e., LINE). Normally the AID content in the message will be the value
of the primary access key attribute identifying a particular object entity in the LINE
administrative view. The context of the primary access key attribute for a subscriber line is
its Directory Number (DN). A normal input message to make data value changes (i.e.,
EDIT-LINE) in an object entity identified by DN would be of the form:
ED-LI:<tid>:<dn>:...
where the AID value <dn> would be a particular DN identifying the subscriber line to be
changed.
If, however, it is desired to access this same entity by its secondary access key attribute [i.e.,
the corresponding Office Equipment (OE) value] for the object entity, the first command
code modifier will identify a context switch of the AID value by including the pound-sign
(#) as a context switch delimiter within the first modifier value string. The form of the input
message to effect this context switch would be of the form:
ED-LI#OE:<tid>:<oe>:...
where the context of the AID value <oe> would be the OE corresponding to a particular
DN of the subscriber line to be changed.
The third required parameter block of the staging parameter blocks is called the Correlation
Tag (CTAG) block for the message. It contains one position-defined parameter to serve as
a means of correlating an input command with its associated output response(s). The OS
assigns an arbitrary non-zero CTAG value6 for inclusion in the input message and it is the
responsibility of the NE to copy this value into the appropriate field of the output
response(s) associated with that input command. The CTAGs for a given NE received in
commands from multiple OSs need not be unique. The value of CTAG must either be a TL1
identifier or a non-zero decimal number, consisting of no more than six characters.
6. Arbitrary is used in the sense that the value has no significance other than the correlationship function.
3–7
Language for Operations Application Messages GR–831–CORE
Input Command Message Structure Issue 1, November 1996
The fourth and final staging parameter block is the GB, which includes support parameters
whose values affect the way in which the input command is to be executed in the NE.7 The
presence of the GB in all input commands is a requirement8 but its value may be null (i.e.,
the GB is represented by two successive colons).
The following GB functions are currently defined and are of the general form:
:[[<delay activation parameters>],[<contingency flag>],
[<indirect data retrieval identifier>]]:
The parameters may be either position-defined in the order specified below, or name-
defined in which only the keywords having non-default values need be specified in the
input message.
7. The basic concept of the GB is to provide an expansion joint where common support functions may be
incorporated in the input messages as needed.
8. Earlier requirements specified the GB to be an optional block such that operations domains not having
domain-specific features were not required to include the GB in the input messages for that domain.
The mandatory requirement of this issue does not apply to existing deployed products nor need it be
retrofitted into existing products not yet deployed. However, future TL1 products shall comply with this
requirement.
9. The Delayed Activation Order Number parameter is similar in concept to the CTAG parameter.
3–8
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Input Command Message Structure
<yy>-<mm>-<dd>
where <yy> is the last two characters of the year, <mm> is a value in the range from 01 to
12 identifying the month, and <dd> is the day of the month in the range from 01 to 31.
The TIME parameter value is the time within the specified date when the delayed activation
is scheduled to occur and is of the form
<hh>-<mm>-<ss>
where <hh> is a value from 00 to 23 identifying the hour, <mm> is a value in the range
from 00 to 59 identifying the minute within the specified hour, and <ss> is a value in the
range from 00 to 59 identifying the second within the specified minute.
There are three ways in which the input command can specify its action to be executed at
the NE.
1. An input command can be specified to be immediately executed following parsing and
interpretation of the message. This is considered to be the default situation.
2. It can be specified to be held in a pending buffer at the NE and executed at some later
date and time. This is called TIMED DELAY ACTIVATION.
3. It can be specified to be held in a pending buffer in the NE until another input command
is received to execute the command. This is called DELAYED MANUAL
ACTIVATION.
Table 3-1 illustrates the combination definitions for the first three parameters in the GB.
In some cases dependent relationships exist between the records within the same
administrative view; i.e., a relationship may exist between the database records specified
in a multi-entity AID data block such that if all the specified records are not successfully
and completely entered or edited in the database, some degree of overall data integrity is
lost. (An example would be the relationships between the telephone lines making up a
3–9
Language for Operations Application Messages GR–831–CORE
Input Command Message Structure Issue 1, November 1996
Series Completion chain.) The Contingency Flag (CF) parameter is a Boolean data type
within the GB that indicates, when set true (i.e., CF=1), a dependent relationship among
the several records specified in the AID data block of a multi-unit command. The flag value
will thus instruct the NE software that all the specified records must be successfully added
to, modified, or deleted from the designated database view or the entire operation must be
aborted. If the CF is false (i.e., CF=0), partial installation of the records (i.e., best effort) in
a multi-unit message may be completed with a report returned to the OS listing the records
that were not successfully installed in the database. The default value of CF is false and
need not be specified in the GB.
3–10
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Input Command Message Structure
that data is also to be retrieved from the TI administrative view linked to the LINE
administrative view by the presence of the linked_admin_view attribute in the LINE view.
The existing value(s) of the TI pointer(s) determine which object entities of the view are to
be retrieved.10
A second order of indirection is also possible in which a first order linked administrative
view may be successively linked to another administrative view, with data being retrieved
only from the second order view and data from the first order view being omitted from the
retrieval. Extending the former example, suppose the TI administrative view contains a
linkage to the Service Logic Host Route (SLHR) administrative view. The command would
then be of the form:
RTRV-LI::5551234:123:RTRVIND=TI-SLHR;
where TI, the first order linked view, contains a pointer to SLHR, whose value(s) identify
the object entity(ies) to be indirectly retrieved from the SLHR administrative view. In this
example, RTRVIND has a compound value (TI-SLHR) specifying that data is to be retrieved
indirectly from administrative view SLHR. Data is not to be retrieved from administrative
view TI, the TI view only serving as a relay function to identify the second order view.
Similarly, data could be retrieved from object entities of all three administrative views if
the form of the message were:
RTRV-LI::5551234:123:RTRVIND=TI-SLHR&TI;
10. The value(s) of the linked_admin_view attributes are normally set at system set-up time or are
subsequently altered by TL1 Edit (ED) commands to the administrative view in which the
linked_admin_view attributes are contained.
3–11
Language for Operations Application Messages GR–831–CORE
Input Command Message Structure Issue 1, November 1996
The remaining part of any TL1 input command is the payload or subject matter of the
message. This section of the message may consist of zero11 or more data blocks in the
following general form:
(:<px>(,<px>)*)*;
where px represents a parameter (i.e., data item). Each data block is delimited by colons (:)
and the last is terminated by a semi-colon (;). Each data block may have an unlimited
number of data items, each delimited by commas (,). For example, a payload consisting of
three parameter blocks, each containing three parameters would be of the form
...:<p1>,<p2>,<p3>:<p4>,<p5>,<p6>:<p7>,<p8>,<p9>;
The data items within a data block may either be name-defined (of the form
<key_word>=<value>) or position-defined where the values are specified and the
keyword is implied by its position in the data block. All of the data items must be of the
same type within a given data block. The semantics of the data items are operation domain-
specific and vary according to the operation to be performed as a result of the input
message.
Whenever an equal sign (=) is detected within a data block, the data block type is defined
to be a name-defined data block. This implies the data block to be of the form:
...:Keyword1=<value>, Keyword2=<value>,... KeywordN=<value>:...
If a position defined parameter (i.e., a value with no keyword =), an error will be generated
indicating a data block error. That is according to the rule that data types cannot be
intermixed in the same data block.
11. Some input messages, such as data retrievals, may have no explicit payload.
3–12
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Acknowledgments
4. Acknowledgments
There are three types of TL1 output messages: acknowledgments, output response
messages, and autonomous messages. This section deals with Acknowledgments, Section 5
describes output response messages, and Section 6 describes autonomous messages.
The acknowledgment code identifies the reason for the acknowledgment. The CTAG
identifies the associated input command. The less than (<) character is the
acknowledgment terminator.1 The valid values for acknowledgment codes and their
meanings are given in the following subsections.
These acknowledgments imply that the command is being executed. They are used often
for test and access messages requiring a long execution time, e.g., a 1-minute noise test.
These acknowledgments may be followed by either completed or denied output response
messages.
1. Previously referred to as the Ready Indicator and only associated with acknowledgments.
4–1
Language for Operations Application Messages GR–831–CORE
Acknowledgments Issue 1, November 1996
Note that very subtle distinctions made between IP and PF in previous documents have
been eliminated in this document.
OK All Right The command was received and the requested action
was initiated and completed.
Specific uses for the OK acknowledgment are defined in message set criteria documents
(e.g., GR-199-CORE, GR-833-CORE, and GR-834-CORE). In addition, OK is used in
response to a command that has been canceled by inclusion of the CAN (cancel) character.
This acknowledgment should be used only in dire circumstances since the state of
execution status is unknown.
This acknowledgment can also be used to respond to a command that is garbled during
transmission. If the CTAG value of the command could not be determined, then the single
character zero (0) should be used as the acknowledgment CTAG value.
This acknowledgment is seldom used because specific error codes in output response
messages can be employed to signify the same information. However, it can be used if
desired.
4–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Acknowledgments
4–3
Language for Operations Application Messages GR–831–CORE
Acknowledgments Issue 1, November 1996
4–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Output Response Message Structure
which consists of two required entries called header and response identification, an
optional text block, and a required terminator.
The header represents information common to all output response messages; i.e., it is
independent of the type of output response.
The response identification identifies the type of output response message. Five types of
output response messages are defined in this document.
The text block represents information specific to the particular output response message.
This component is optional.
The terminator indicates the termination or continuation of the output response message.
The following sections further describe the structure of the above component constructs.
5.2 Header
and is composed of a source identifier (<sid>) and date and time stamps. The <sid> is
restricted to 20 characters maximum and identifies the NE generating the message. The
syntax of <sid> is any TL1 identifier (simple or compound) or text string. It is suggested
that the NE's CLLI1 code (and possible extension) be used for the source identifier. The
<sid> value is checked by the NE against the <tid> parameter of the input command to
verify that the NE's <sid> matches the command's intended target (i.e., <tid>).
1. Important: if either the TID or SID contains any non-identified characters (not made up of only letters
and digits) such as spaces, the text string form must be used (i.e., enclosed in double quotes).
5–1
Language for Operations Application Messages GR–831–CORE
Output Response Message Structure Issue 1, November 1996
This construct consists of three components, namely, the character M, a correlation tag
(<ctag>), and a completion code. The character M signifies that the message is the
response to an input command message. The output response message shall have the same
<ctag> value as the corresponding input command message for enabling the OS to
associate the received output response message with a previously sent command.
The completion codes are COMPLD, DENY, PRTL, DELAY, and RTRV. Message
designers may further restrict the use of some of these codes. The semantics of the
completion codes are:
5–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Output Response Message Structure
RTRVa represents output response of an input retrieve command (i.e., with command verb
RTRV) that retrieves extensive amount of information from the NE and thus causes
lengthy processing in the NE for gathering all the requested information. For
effective operation, the NE may start returning available information to the OS even
before all the requested information is gathered. In this case, the RTRV completion
code may be used. Multiple responses with RTRV completion codes are permitted
for the same RTRV command, but the final response must have a COMPLD
completion code.
a. The use of this completion code depends on the application domain.
When the <ctag> of an input command cannot be identified (e.g., during dial-up
asynchronous connections with noise and errors prevalent), either the 2-letter
acknowledgment NA may be returned or the DENY response containing the appropriate
error message with the <ctag> set to the single character zero (0) may be returned.
The optional text block is used to represent information specific to the particular output
response. The form of the response text is
((<cr><lf>^^^<unquoted line>)|(<cr><lf>^^^<quoted line>)|
(<cr><lf>^^^<comment>))*
5–3
Language for Operations Application Messages GR–831–CORE
Output Response Message Structure Issue 1, November 1996
The comment component is used to allow free format (i.e., human readable, not machine
parsable) text. The free form text shall always be preceded by the pair of characters slash
asterisk (/*) and followed by the pair of characters asterisk slash (*/).
Note that either the semicolon (;) or the greater than (>) character shall not terminate the
output response message, when they are present as part of a quoted line or within a text
string.
5.5 Terminator
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.
It is a requirement that the size of an output message shall not exceed 4096 bytes. If the size
of an output response message exceeds 4096 bytes, the output information shall be
partitioned into multiple output response messages. A continuation message (i.e.,
subsequent message) needs to have another header and response identification with the
same <ctag>, along with an additional <text block>. Each message shall be terminated by
the greater than (>) character, except the last message, which shall be terminated by the
semicolon (;) character for indicating the completion of the response. The (>) terminator is
also used for intermediate responses in a timed measurement series.
5–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Output Response Message Structure
was issued, a typical NE output response message with COMPLD response code might
look like the following:
<cr> <lf> <lf>
^^^RDBKNJNVK01^93-06-15^09:12:11 <cr> <lf>
M^^1204^COMPLD <cr> <lf>
^^^"5-7:32,NONE" <cr> <lf>
;
was issued and the argument 16 was out of range, the following output response
message (with a DENY response code) might appear:
<cr> <lf> <lf>
^^^RDBKNJNVK01^93-06-15^09:12:11 <cr> <lf>
M^^9904^DENY <cr> <lf>
^^^RRNG <cr> <lf>
^^^"5-16:aid2=16:min=0,max=15" <cr> <lf>
^^^/* Numeric values in the Access Block must be <cr> <lf>
^^^ between 0 and 15. */ <cr> <lf>
;
Also, regarding the previous example illustrating the use of the TL1 comment facility of:
^^^/* Numeric values in the Access Block must be <cr> <lf>
^^^ between 0 and 15. */ <cr> <lf>
has been construed that the portion treated as free format text must be conventionally
formatted to conform to other Output Message syntax rules. The example imposes no
restriction on the TL1 comment facility and is intended only to demonstrate the versatility
that an implementation might choose to present information intended for a display device.
Thus, it is noted that within free format text, the construct
2. The response codes DELAY and RTRV are used in GR-199-CORE for messages for switching NEs.
See GR-199-CORE for examples.
5–5
Language for Operations Application Messages GR–831–CORE
Output Response Message Structure Issue 1, November 1996
was issued and the argument 16 was out of range, the following output response
message (with a PRTL response code) might appear:
<cr> <lf> <lf>
^^^RDBKNJNVK01^93-06-15^09:12:11 <cr> <lf>
M^^9954^PRTL <cr> <lf>
^^^"5-7:32,None" <cr> <lf>
^^^RRNG <cr> <lf>
^^^"5-16:aid2=16:min=0,max=15" <cr> <lf>
^^^/* Numeric values in the Access Block must be <cr> <lf>
^^^ between 0 and 15. */ <cr> <lf>
^^^"5-3:24,None" <cr> <lf>
;
RTRV-LI::9087582000:123:RTRVIND=TI;
The Output Response message could look like this (the example does not show all
applicable administrative view keywords):
5–6
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Autonomous Messages
6. Autonomous Messages
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 (such as the normal Input
Command / Output Response message pair). Typical scenarios where autonomous
messages are used include
• Reporting of alarmed and/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.
Aside from alarm and event reporting, most other autonomous messages are related to
functions that were set up with another Input Command/Output Response message pair.
For example, an OS can schedule periodic reporting of selected NE conditions by sending
the appropriate Input Command to the NE. If the NE is capable of performing the requested
function, it will send a successful Output Response message back to the OS. Subsequent
periodic reporting of the selected conditions would then be accomplished by sending the
report in the form of an appropriate autonomous message. This could also apply to
scheduling diagnostic tests and various audits within an NE. Throughout this section,
spontaneous and autonomous are used interchangeably.
6–1
Language for Operations Application Messages GR–831–CORE
Autonomous Messages Issue 1, November 1996
The <header> is the standard response header that is defined in Section 5 (Output
Response Message Structure). It contains system identifier <sid>, and date and time
stamps. The header is a required entry in all TL1 output response and autonomous
messages. For a more detailed explanation of its parameters and syntax see Section 5.2.
The <auto id> entry for an autonomous message is of the following form
<almcde> is the alarm code. The alarm code indicates the severity of the autonomous
message. Valid values for <almcde> in decreasing order of severity are as follows:
<almcde> Description
*C Critical alarm
** Major alarm
*^ Minor alarm
A^ Non-alarm message
Critical, Major, and Minor correspond to the reporting of alarmed events. The Non-alarm
message designation is used when the NE is reporting non-alarmed events, periodic
measurements, or results of previously scheduled diagnostics or audits.
If multiple alarms are reported in the same message, the alarm code is the highest severity
of those being reported.
6–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Autonomous Messages
1. Although TL1 imposes no restrictions on the length of an Autonomously Generated Correlation Tag,
individual application domains might (e.g., GR-833-CORE restricts the ATAG to a maximum of 10
characters including the decimal point if used).
6–3
Language for Operations Application Messages GR–831–CORE
Autonomous Messages Issue 1, November 1996
An example showing the use of the ATAG to correlate events is included in Section 6.6
(Examples of Autonomous Messages).
6.3.3 <verb>[^<modifier>[^<modifier>]]
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 <unquoted line> and <quoted line> consist of text that is parsable, while
<comment> is not. Each component may appear zero or more times within the text block
and interleave with other component types in any order. A more complete description of
the individual components is in Section 5.4.
6.5 Terminator
1. This is different from the separator character used in Input Command Messages described in Section 2.
6–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Autonomous Messages
This section contains two examples of actual TL1 autonomous messages taken from the
Network Maintenance and Surveillance application domain (GR-833-CORE). Both
examples illustrate typical <verb> and <modifier> combinations, and the second one
shows event correlation via the use of the ATAG.
Assume that periodic performance monitoring information is being sent to a Surveillance
OS. A typical NE might generate the following autonomous output:
Note that the asterisk caret (*^) indicates that it is a minor alarm and the ATAG, 456.123,
indicates that this spontaneous output message was generated as the result of a common
problem. Other messages associated with the same problem would have an ATAG with the
same fractional part (i.e., .123).
Also note the use of embedded format effectors (e.g., <cr> and <lf>) in the
<quoted line>. This is a valid construct and should be handled the same way that it is in the
Input Command message (format effectors are ignored in these instances).
6–5
Language for Operations Application Messages GR–831–CORE
Autonomous Messages Issue 1, November 1996
6–6
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Implementation Guidelines
7. Implementation Guidelines
There are a number of issues that a TL1 implementor must face aside from just syntax and
semantics. The intermessage context and pragmatics must also be handled. The purpose of
this section is to give some guidelines that any implementation must follow for proper
working of a TL1 interface.
7.1 Input
There are a number of considerations that must be made when a command is received by
an NE. These are as follows, in no fixed order:
• Check whether a CAN character has been entered. If so, transmit an OK
acknowledgment.
• Filter non-TL1 characters from the command.
• Check whether processing resources are available for the command. If it is not,
transmit an RL acknowledgment.
• Check whether the command is garbled. If it is, transmit an NA acknowledgment or an
appropriate output error response message. Set the CTAG value to zero (0).
• Transmit an IP or PF acknowledgment if appropriate.
• Check whether this command has higher priority than other commands that may
already be buffered or executing. High priority commands are those that control
execution of other commands. Examples are as follows:
— ABT-CMD - Abort Command
— DISC-MEAS - Disconnect Measurement.
7.2 Output
Once a command has begun execution and its response is being generated, the following
guidelines apply:
• Split long responses and autonomous messages into segments of no more than 4096
characters. This is the current TL1 size limit taken from TR-TSY-000827. Use the
greater than (>) termination character for intermediate segments. All segments of a
long response should be assigned the same CTAG value.
• Use the greater than (>) termination character for intermediate responses to commands
generating periodic outputs, e.g., MEAS-VG (measure voltage) from GR-834-CORE.
7–1
Language for Operations Application Messages GR–831–CORE
Implementation Guidelines Issue 1, November 1996
• Generate message header time/date stamps using the general rule that the time/date
should reflect a time of occurrence rather than the time of transmission. The occurrence
time is clear in some cases and less clear in others. Use the following guidelines to
clarify such scenarios:
— A quickly executing command - the time of execution
— A measurement occurring over time - the time the measurement finished
— An alarm or event - the time when the alarm/event condition occurred or was
detected.
• Assign transmission priorities to output segments as follows:
— Critical alarms (highest)
— Major alarms
— Minor alarms
— Command responses and non-alarm autonomous messages (lowest).
This implies that output of a long response or autonomous message might have to be
interrupted by higher priority messages. To maintain proper message structures, this
interruption should be done only between output message segments.
• If correct processing of a command is lost, terminate execution and transmit an NA
acknowledgment.
• There are five generic command response completion codes - COMPLD, DENY,
PRTL, DELAY, and RTRV. While COMPLD and DENY are always applicable, the
other completion codes can be used if this is specifically stated in the message set
document describing the command.
In Section 3.3.1, “Target Identifier Block (TID),” and Section 5.2, “Header,” regarding
SID, both describe the TID or SID Parameter Block, in part, as being any TL1 Identifier,
either Simple or Compound. Previous documentation emphasized in the narrative the
meaning and implications of compounding parameters through the use of the TL1 hyphen
operator (-). Parsers conforming to formal TL1 Language descriptions that find a hyphen
in this parameter (or any other parameters) block will NOT treat the hyphen as data, but as
a separator of two closely associated units of data or information. One example observed
is a TID/SID constructed with concatenated CLLI Codes and Relay Rack nomenclature,
that is, only:
<clliCode>-<relayRackLocation>
7–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Implementation Guidelines
which may or may NOT be a legal compounding of information depending on the initial
character value of
<relayRackLocation>
7–3
Language for Operations Application Messages GR–831–CORE
Implementation Guidelines Issue 1, November 1996
7–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Grammar
A.1 Introduction
This appendix provides a rigorous definition of TL1 using Backus-Naur Form (BNF). This
is included so that any subtle questions arising from reading the main body of GR-831-
CORE can be resolved. However, it is assumed that the reader already has some familiarity
with TL1 from a reading of the main text of this document.
This appendix uses the BNF notation introduced in Section 2 - the symbols <...>, [...], *.
+, etc. In addition, the following character symbols have been reserved: <sp>, <cr>, <lf>,
<ht>, <vt>, <ff>, and <can>. These are defined in Section A.3. All other characters have
literal meanings. To prevent confusion, single quotes (') are used to surround a literal
character, and double quotation marks (") are considered literal characters.
A.2 Contents
The formal grammar description follows a bottom-up approach. First, the legal character
set and three character classes are defined. Next, the rules for forming characters into
words called information units are given. Next, a BNF function is defined for a common
structure called a parameter value complex. Then grammar rules are given for the top level
input and output messages in terms of information units, punctuation characters, etc. The
final section is a discussion of the various sorts of text string entities that exist within TL1.
The legal character set consists of the subset of ASCII characters shown in the standard
matrix presentation (see Table A-1). Each column of the matrix is labeled by the most
significant hexadecimal digit of the character code, and each row by the least significant
hexadecimal digit.
A–1
Language for Operations Application Messages GR–831–CORE
TL1 Grammar Issue 1, November 1996
Here <ht> = Horizontal Tab, <lf> = Line Feed, <vt> = Vertical Tab, <ff> = Form Feed,
<cr> = Carriage Return, <can> = Cancel, and <sp> = Space.
The cancel character <can> is legal for input messages (commands) only.
The characters not used by TL1 (hex 00-08, 0E-17, 19-1F, and 7F) are reserved for
implementation-dependent use by lower layers of the communications protocol: PAD
control, XON/XOFF stream control, etc. These special characters should be removed from
each message before or during parsing. The injunction against use of the special characters
in TL1 messages cannot be bypassed by trying to hide them in escape sequences (using \'s;
see Section A.8). Escape sequences are not recognized by lower layers that treat TL1
messages as transparent octet streams. If it is essential to allow any possible character in a
message, e.g., in a memory dump, then hexadecimal or some other encoding must be
employed.
Three useful character classes (letters, decimal digits, and format effectors) are as follows:
<let> ::= A | B | ... | Z | a | b | ... | z
<dig> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<fe> ::= <sp> | <cr> | <lf> | <ht> | <vt> | <ff>
A–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Grammar
TL1 messages are built from basic entities called information units (analogous to English
words) combined and delimited by punctuation characters. The types of information units
are defined as follows:
<nil> ::=
<ident> ::= <let> (<let> | <dig>)*
<sym name> ::= <dig>* ((<let> | '+' | # | %) <dig>*)+
<alphanum> ::= (<let> | <dig>)+
<dec num> ::= [D'] <dig>* [.] <dig>+
<arith exp> ::= '(' ['+' | -] <dig>* [.] <dig>+ ')'
<hex num> ::= [H'] (<dig> | A | B | C | D | E | F)+
<oct num> ::= [O'] (0 | 1 | 2 | 3 | 4 | 5 | 6 | 7)+
<bin num> ::= [B'] (0 | 1)+
<keyed num> ::= [K'] (<dig> | A | B | C | D | '*' | #)+
<num str> ::= <dig>+
<integer> ::= <num str>
| '(' ['+' | -] <dig>+ ')'
<text str> ::= " (\" | \\ | <any character except " or \>)* "
<inner str> ::= \" ("" | \\ | <any character except " or \>)* \"
A–3
Language for Operations Application Messages GR–831–CORE
TL1 Grammar Issue 1, November 1996
Information units can be combined using punctuation characters to form more complicated
parameter values expressing compound values, groups of values, ranges of values, etc. The
most general form allowing all possible combinations is called a parameter value complex.
Parameter value complexes appear in TL1 in three types. All three types use exactly the
same rules for forming complexes from information units. The differences among the types
are due only to the classes of allowed information units from which the complexes are
formed.
Repeating the BNF for complex formation three times is lengthy and confusing since each
repetition must use different variables to distinguish the information class allowed. Instead,
immediately below is defined a BNF function called param value complex. It has as an
argument the free variable info unit class. This function is invoked several times in sections
below.
<param value complex(<info unit class>)> ::=
<seq chain> (& <seq chain>)*
A–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Grammar
The connector punctuation characters &, &-, &&, &&-, and .++. are used to express
multiple values from a set and ranges of values. Although not explicitly expressed in the
BNF, the information units used for range limits must be numerical values. For example,
1 && 4 is legal TL1 while A && D is not.
Each input message (command) has a uniform structure consisting of a series of colon-
delimited blocks. The command code, target identifier, access identifier, correlation tag,
and general blocks have fixed internal formats. The remaining blocks have message-
dependent formats.
<input message> ::= <cmd code> : [<tid>] : [<aid>] : <ctag>
:[<general block>] (: <payload block>)* ;
A–5
Language for Operations Application Messages GR–831–CORE
TL1 Grammar Issue 1, November 1996
<name def gen blk> ::= [ON = <order nr>], [DATE = <gb_date>],
[TIME = <gb_time>], [CF = cont_flag]
[,RTRVIND = <idr_ind>]
<cont_flag> ::= 0 | 1
A–6
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Grammar
Output messages are split into three basic classes, command acknowledgments, command
responses, and autonomous messages.
<output message> ::= <acknowledgment>
| <response>
| <autonomous>
A–7
Language for Operations Application Messages GR–831–CORE
TL1 Grammar Issue 1, November 1996
A.7.1 Acknowledgments
Acknowledgments are simple two-letter codes with correlation tags used primarily to
report the status of command execution.
<acknowledgment> ::= <ack code> <sp> <ctag> <cr> <lf> <
<ack code> ::= IP | OK | PF | NA | NG | RL
Responses and autonomous messages are similar in structure and consist of two required
entries called the header and identification, an optional text block, and a terminator symbol.
The header line is composed of a source identifier, date stamp, and time stamp.
<response> ::= <header> <response id> [<text block>] <terminator>
<header> ::= <cr> <lf> <lf> <sp> <sp> <sp> <sid> <sp> <date> <sp>
<time>
A–8
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Grammar
Autonomous messages are normally triggered by alarm conditions and are not in response
to any input message (command). The autonomous identification of output consists of an
alarm severity level code, an autonomously generated correlation tag, and an output code
reporting the general event causing the message.
<auto id> ::= <cr> <lf> <alarm code> <sp> <atag> <sp> <output code>
Both responses and autonomous messages may contain optional text blocks. A text block
consists of a series of lines, each started by a carriage return/line feed sequence. A line can
contain either free text in the form of a comment, or parsable data, but not a mixture of the
two. A parsable data line can take one of two forms called an unquoted line or a quoted line.
The term <line> below refers to logical structure, not physical structure. A single <line>
might have carriage returns and line feeds inside it, thus printing as several physical lines.
<text block> ::= (<cr> <lf> <sp> <sp> <sp> <line>)+
A–9
Language for Operations Application Messages GR–831–CORE
TL1 Grammar Issue 1, November 1996
A quoted line is a special string type the body of which holds inner level parameters. The
inner level is reached by inclusion in quotation marks. The syntax of the inner level is
equivalent to that of a command, i.e, a series of colon-delimited blocks (here called
<block>s). Parameters within each <block> are separated by required commas and
optional format effectors (<fe>s).
Format effectors within a quoted line are ignored unless they occur within inner strings, in
which case they are treated as literal characters.
<quoted line> ::= " <block> (: <block>)* "
<block> ::= <pos def quoted param> (, <fe>* <pos def quoted param>)*
| <name def quoted param> (, <fe>* <name def quoted param>)*
<name def quoted param> ::= <quoted param name> = <quoted param value>
<quoted param value> ::= <param value complex((<quoted info unit class>)>
A–10
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Grammar
| <dec num>
| <arith exp>
| <hex num>
| <oct num>
| <bin num>
| <keyed num>
| <num str>
| <integer>
| <inner str>
The purpose of this section is to clarify the BNF definitions for the various text string type
entities given above and explain the reasons for the definition details. Relevant BNF lines
are repeated here for easy reference.
<text str> ::= " (\" | \\ | <any character except " or \>)* "
<inner str> ::= \" ("" | \\ | <any character except " or \>)* \"
In input messages (commands), it may be necessary to encode a value not derivable from
the rigid information units or complexes of them. It was for this purpose that the <text str>
unit was defined. A text string is an arbitrary sequence of legal TL1 characters surrounded
by quotation marks. Note that here, the term quotation mark always refers to the double
mark symbol (''). Within the body of a text string, a literal quotation mark itself is encoded
by an escaped double-quote - (\"). The escape character - backslash (\) - is represented by
a double backslash - (\\). Literal quotation marks within the body of a text string do not have
to be balanced (paired).
Example: Assume that a command parameter P has the literal value
alarm\event class "fatal"
A–11
Language for Operations Application Messages GR–831–CORE
TL1 Grammar Issue 1, November 1996
Text strings handle all needs for exotic parameter values within input messages. They also
handle the same needs for the parameter values within the header and identification of
output lines for output messages. However, for output message text blocks new
complications arise. Here, quotation marks are used to distinguish an unquoted line from a
quoted line At the inner level of a quoted line, a new construction is needed to encode
arbitrary strings of characters. This construction is the <inner str>. An inner string is an
arbitrary sequence of legal TL1 characters surrounded by escaped quotes (\"). Within the
body of the inner string, a literal quotation mark is indicated by a double double-quote ("");
a literal backslash is indicated by a double backslash (\\).
Example: To return the parameter P (introduced in the example above) as a name-defined
parameter P in a response or autonomous text block quoted line, the form
"P=\"alarm\\event class ""fatal""\",Q= ..."
This value could not be included in a text block unquoted line since the allowed information
units for an unquoted line do not include any type of general string.
A–12
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Style Guide
Output messages rely on certain format effectors to structure the parameters, principally for
human readability, and therefore their presentation relies on the symbolic use of the printed
caret symbol (^) to represent an ASCII space (or blank) character as parameter separators.
Formal description of the TL1 language uses only <sp> and the caret as a symbolic
replacement only occurs with specific input message or output message descriptions and
presentations.
Also, ASCII carriage return characters and linefeed characters are presented as <cr> and
<lf> to show the end of, or the beginning of, a logical block of information as a physical
line on display devices.
B–1
Language for Operations Application Messages GR–831–CORE
TL1 Style Guide Issue 1, November 1996
On occasion, a special effort was attempted to physically associate the <cr> and <lf>
parameter effector with the textual presentation. For simple response output messages, this
has not been a problem. However, for complex messages, with optional text block lines, the
presentation placement of <cr> and <lf> may lead to a more difficult human interpretation
or construction.
As an illustration, a simple normal response output message may contain one optional text
block line and could be presented as
<cr><lf><lf>
^^^<sid>^<date>^<time><cr>><lf>
M^^<ctag>^COMPLD<cr><lf>
[<optional-text-block-line><cr><lf>];
For consistency in presentation style, new and revised documentation will usually adopt the
following:
<cr><lf><lf>^^^<sid>^<date>^<time>
<cr><lf>M^^<ctag>^COMPLD
[<cr><lf><optional-text-block-line>]
<cr><lf>;
Here, <header> and <terminator> (the ASCII character triad of carriage return, linefeed,
and semicolon) are already defined message components and symbolically <sl> (start of
line) is made up of <cr> <lf> <sp> <sp> <sp> that causes the start of a new line on
display devices. Longer normal response output messages may be presented in a more
readable way as
B–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Style Guide
<header>
<sl><text-block-line-one>
<sl><text-block-line-two>
<sl><text-block-line-etc>
<terminator>
In any case, the <sl> <text-block-line> separators are, for presentation purposes,
consistently attached to the beginning of the lines. Now, with this presentation convention,
long descriptions that may need more than one page-text-line can be split without possible
ambiguity. For example
<header>
<sl><parameter1a>,^<parameter1b>,^<parameter1c>,^
<parameter1d>,^<parameter1e>
<sl><parameter2a>,^<parameter2b>,^<parameter2c>,^
<parameter2d>,^<parameter2e>
<terminator>
The representation of optional parameters between pairs of left and right brackets ([]) along
with parameter position holders may lead to a convoluted and correspondingly difficult
understanding of a message. Consider the following partial input command message as an
example:
:<parameter1>:[<parameter2>]:[<parameter3>];
: VALUE1 ;
: VALUE1 : VALUE2 ;
: VALUE1 : VALUE2 : VALUE3 ;
: VALUE1 : : VALUE3 ;
B–3
Language for Operations Application Messages GR–831–CORE
TL1 Style Guide Issue 1, November 1996
The simpler notation, which uses the principle that trailing parameter separators are
unneeded but are permissible, have proved to be more usable.
B–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Message Verbs
C–1
Language for Operations Application Messages GR–831–CORE
TL1 Message Verbs Issue 1, November 1996
C–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Error Codes
D–1
Language for Operations Application Messages GR–831–CORE
TL1 Error Codes Issue 1, November 1996
D–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Error Codes
D–3
Language for Operations Application Messages GR–831–CORE
TL1 Error Codes Issue 1, November 1996
D–4
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 TL1 Error Codes
D–5
Language for Operations Application Messages GR–831–CORE
TL1 Error Codes Issue 1, November 1996
D–6
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 References
References References
Bellcore Documents
• BR-751-000-101, COMMON LANGUAGE® Codes And Abbreviations - Summary Of
Published Practices, Bellcore [Available Under License], Issue 9 (Bellcore,
July 1994).
• ST-STS-000122, Place Code Description, Bellcore, Science and Technology, Issue 2
(Bellcore, June 1990).
• FR-439, Operations Technology Generic Requirements (OTGR), (Bellcore, 1996
Edition).
• GR-199-CORE, OTGR Section 12.2: Operations Application Messages - Memory
Administration Messages (a module of OTGR, FR-439), Issue 2 (Bellcore,
November 1996).
• TR-TSY-000825, OTGR Section 10.A: User System Interface — User System
Language (USL) (a module of OTGR, FR-439), Issue 2 (Bellcore, February 1988).
• TR-TSY-000827, OTGR Section 11.1: Generic Operations Interfaces — Non-OSI
Communications Architecture (a module of OTGR, FR-439), Issue 1 (Bellcore,
November 1988).
• TR-NWT-000831, OTGR Section 12.1: Operations Application Messages - Language
for Operations Application Messages (a module of OTGR, FR-439), Issue 3 (Bellcore,
July 1993), plus Revision 1, December 1993. [Replaced by this GR.]
• GR-833-CORE, OTGR Section 12.3: Operations Application Messages — Network
Maintenance: Network Element and Transport Surveillance Messages (a module of
OTGR, FR-439), Issue 2 (Bellcore, November 1996).
• GR-834-CORE, OTGR Section 12.4: Operations Application Messages —Network
Maintenance: Access and Testing Messages (a module of OTGR, FR-439), Issue 2
(Bellcore, November 1996).
Non-Bellcore Documents
• ANSI T1.201-1987, American National Standard For Telecommunications -
Information Interchange - Structure For The Identification Of Location Entities For
The North American Telecommunications System, 1987, New York, American
National Standards Institute.
• ANSI T1.205-1988, American National Standard For Telecommunications -
Information Interchange - Representation Of Places, States Of The United States,
Provinces And Territories Of Canada, Countries Of The World And Other Unique
References–1
Language for Operations Application Messages GR–831–CORE
References Issue 1, November 1996
Areas For The North American Telecommunications System, 1988, New York,
American National Standards Institute.
• CCITT X.25, CCITT Recommendation X.25, Interface Between Data Terminal
Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals
Operating in the Packet Mode and Connected to Public Data Networks by Dedicated
Circuit, International Telephone and Telegraph Consultative Committee, International
Telecommunications Union, 1988.
• CCITT Z.300, CCITT Recommendations Z.311 - Z.318 and Recommendation Z.341,
International Telephone and Telegraph Consultative Committee, International
Telecommunications Union, November 1984.
NOTE:
All Bellcore documents are subject to change, and their citation in this document reflects
the most current information available at the time of this printing. Readers are advised to
check current status and availability of all documents.
BCC personnel should contact their company document coordinator, and Bellcore
personnel should call (908) 699–5802 to obtain documents.
References–2
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Glossary
Glossary Glossary
AID — Access Identifier
AIN — Advanced Intelligent Network
ASCII — American Standard Code for Information Interchange
AT&T — American Telephone and Telegraph
ATAG — Autonomously Generated Correlation Tag
BNF — Backus-Naur Form
CCITT — International Telegraph and Telephone Consultative Committee
CF — Contingency Flag
CGA — Carrier Group Alarm
CTAG — Correlation Tag
DN — Directory Number
DS0 — Digital Signal 0
DS0B — Digital Signal 0B
DS1 — Digital Signal 1
DS3 — Digital Signal 3
GB — General Block
IP — In Progress
ITU-T — International Telecommunication Union - Telecommunications Standardization
Sector (successor to CCITT)
LAPB — Link Access Procedure, Balanced
NA — No Acknowledgment
NE — Network Element
NG — No Good
NTE — Network Transport Element
MML — Human-Machine Language (formerly Man-Machine Language)
OE — Office Equipment
OK — OK or All Right
ON — Order Number
Glossary–1
Language for Operations Application Messages GR–831–CORE
Glossary Issue 1, November 1996
OS — Operations System
OSI — Open Systems Interconnection
OTGR — Operations Technology Generic Requirements
PAD — Packet Assembler/Disassembler
PF — Printout Follows
QRS — Quasi-Random Signal
RL — Repeat Later
RTU — Remote Test Unit
SID — System Identifier
SLHR — Service Logic Host Route
TAP — Test Access Point
TAU — Test Access Unit
TI — Trigger Item
TID — Target Identifier
TL1 — Transaction Language 1
TSC — Test System Controller
TSN — Test Session Number
USL — User System Language
Glossary–2