АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Язык операций 1

Язык операций 1 (англ. Transaction Language 1, сокращённо TL1) — широко используемый в Телекоммуникации протокол, служащий общим, независимым от производителя и технологии, человеко-машинным языком для управления инфраструктурой оптических (SONET) и широкополосных сетей в Северной Америке.

TL1 используется во входных и выходных сообщениях, которые передаются между системой поддержки операций (OSS) и сетевыми элементами (СЭ). В таких областях, как наблюдение, управление памятью, доступ и тестирование, применяются сообщения TL1 для выполнения конкретных функций между OSS и СЭ. Стандарт TL1 описан в документе компании Telcordia Technologies (ранее Bellcore) GR-831-CORE: Operations Application Messages[1].

История и стандартизация

Протокол был разработан в 1984 году компанией Bellcore (позднее Telcordia) для унификации управления сетевыми элементами и замены проприетарных протоколов[2]. TL1 является человеко-машинным языком (MML), основанным на стандартах серии Z.300[3]. Основные спецификации протокола закреплены в стандарте Telcordia GR-831-CORE[3].

Имя команды и модификаторы

TL1 — это текстовый язык команд, где каждая команда состоит из набора полей, разделённых двоеточиями, и завершается точкой с запятой.

Общий формат команды

VERB:TID:AID:CTAG:GENBLOCK:OPTIONS;

В каждой команде обязательно должны присутствовать: имя команды (VERB), разделители (двоеточия) и точка с запятой.

  • VERB — код выполняемой команды, имеющий иерархическую структуру «глагол-модификатор1-модификатор2», где части разделяются дефисом. Пример: RTRV-ALM-ALL (извлечь все аварийные сигналы)[4].
  • TID (Target Identifier) — идентификатор цели. Необязателен для большей части команд. Некоторые устройства предварительно сверяют TID в команде с SID (Source Identifier), чтобы убедиться в их совпадении перед выполнением.
 * Примечание: дефис используется как допустимый символ внутри идентификаторов (например, в TID), а не как разделитель полей команды[4].
  • AID (Access Identifier) — идентификатор доступа, определяющий объект, над которым выполняется операция. Формат зависит от объекта:
 * Для указания двух объектов используется амперсанд (&): например, slot 1/port 3 и slot 1/port 7: 1-3&-7
 * Для задания диапазона — двойной амперсанд (&&): порты 3-7 слота 1: 1-3&&-7
  • CTAG (correlation tag) — метка связи, необязательна для большинства команд. Позволяет соотнести команду с ответом — значение CTAG возвращается в ответном сообщении. Если не задано, в ответе будет 0.
  • GENBLOCK (general block) — общий блок, используемый для параметров отложенной активации. Если эти функции не используются, поле может быть пустым, что обозначается двумя двоеточиями подряд (::)[5].
  • OPTIONS — пример именованного параметра внутри блока полезной нагрузки (Payload Block), содержащего данные и опции, необходимые для выполнения запроса[6].

Основные элементы TL1-сообщения

Элемент Символ Роль Пояснение
Точка с запятой ; терминатор Отмечает конец сообщения TL1.
Двоеточие : разделитель Отделяет поля данных в TL1-сообщении.
Запятая , разделитель и заполнитель Разделяет аргументы сообщения и указывает пропущенные аргументы.

Двойное двоеточие (::) используется для обозначения пропуска одного или нескольких необязательных позиционных полей в команде[7].

Например, аргументы от A до E разделяются запятыми: :A,B,C,D,E;

Аргументы могут быть опущены с конца — :A,B; Пробелы внутри аргументов требуют добавления запятых в качестве заполнителей: :,B,,,E;

Строковые значения заключаются в двойные кавычки ("). Для передачи многострочных текстовых блоков используются специальные разделители: блок начинается с символа > и завершается символом ; на новой строке.

Обозначения в TL1-ответах

Для описания ответов на TL1-команды используется синтаксис BNF, как определено в документе Telcordia GR-831-CORE. Следующая таблица описывает используемые условные обозначения:

Символ Описание
^ Представляет пробел
* Предыдущий блок параметров может повторяться 0 или более раз
+ Предыдущий блок параметров должен повторяться 1 или более раз
/* Начало ASCII-комментария в свободной форме
*/ Конец ASCII-комментария в свободной форме
( Начало дополнительного блока
) Конец дополнительного блока
<cr> Символ возврата каретки
<lf> Символ перевода строки

Сообщения TL1

Язык TL1 состоит из различных типов сообщений. Основных типов — четыре:

  1. Входное сообщение — команда, отправляемая системой OSS или пользователем.
  2. Ответное сообщение — сообщение, формируемое сетевым элементом в ответ на входное сообщение.
  3. Сообщение подтверждения приёма — подтверждение принятия входного сообщения, отправляется если время ожидания ответа превышает две секунды.
  4. Независимое сообщение — асинхронное сообщение, формируемое сетевым элементом (уведомления, сообщения об авариях).

Согласно стандарту Telcordia GR-831-CORE, данный список из четырёх типов сообщений является исчерпывающим.

Сообщения TL1 реализуют функции модели OAM&P (англ. Operations, Administration, Maintenance, and Provisioning — Эксплуатация, Администрирование, Обслуживание, Обеспечение)[3]:

  • Эксплуатация (Operations) — повседневный мониторинг состояния сети (например, наблюдение за авариями с помощью автономных сообщений и мониторинг производительности).
  • Администрирование (Administration) — управление ресурсами, безопасностью и данными (например, управление учётными записями пользователей и базами данных)[3].
  • Обслуживание (Maintenance) — обеспечение работоспособности сети (например, идентификация сбоев, тестовый доступ и восстановление после сбоев)[3].
  • Обеспечение (Provisioning) — конфигурация оборудования и активация услуг для клиентов (например, добавление нового абонента или изменение профиля обслуживания)[8].

Структура сообщения TL1

Все сообщения TL1 имеют фиксированную структуру, при этом возможны расширения для новых команд производителями сетевых элементов.

Основные составляющие:

  • Идентификаторы объекта (TID) и источника (SID) — уникальные для каждого сетевого элемента.
  • Идентификатор доступа (AID) — определяет объект внутри СЭ.
  • Метки связи (CTAG/ATAG — correlation tag/autonomous correlation tag) — числа, связывающие команды и ответы.

Общая структура кадра сообщения является строго иерархической и состоит из трёх основных компонентов:[3]

  • Заголовок (Header) — присутствует в ответных и автономных сообщениях, содержит идентификатор источника (SID), а также дату и время генерации.
  • Тело сообщения (Body) — основная часть кадра. Включает в себя блок адресации (Staging Block) и блок данных (General Block) со строгим фиксированным порядком полей[3][5].
  • Терминатор (Trailer) — специальный символ, указывающий на завершение сообщения (стандартно используется точка с запятой «;», а при разбиении длинных ответов — знак «>»)[8].

Входное сообщение TL1

Структура:

Входное сообщение TL1
Код команды Подготовительный блок Блок с полезной нагрузкой
Имя команды атрибут 1 атрибут 2 TID AID CTAG Общий блок Блок данных
ENT USER SECU MyNE sridev 101 password

Пример:

ENT-USER-SECU:MyNE:sridev:101::password;

В блоке данных сложные параметры часто передаются в виде пар «параметр-значение» в формате КЛЮЧЕВОЕСЛОВО=ЗНАЧЕНИЕ, которые разделяются запятыми.

Ответное сообщение TL1

Структура:

Ответное сообщение TL1
Заголовок ответа Идентификатор ответа Ответный блок Указатель конца
SID Дата Время M CTAG Код завершения
MyNE 04-08-14 09:12:04 M 101 COMPLD «UID=sridev:CID=CRAFT,UAP=1:» ;

Заголовок ответного сообщения имеет стандартизированную структуру и включает следующие поля:

  • SID (Source Identifier) — уникальный идентификатор источника, указывающий сетевой элемент, отправивший ответ.
  • Дата и Время (Date / Time) — временные метки генерации ответного сообщения.
  • M — фиксированный признак, указывающий, что данное сообщение является ответным.
  • CTAG (Correlation Tag) — тег корреляции, позволяющий сопоставить ответ с исходной командой[3].

Для обозначения статуса выполнения команды в ответных сообщениях используются коды завершения:

  • COMPLD (Completed) — полное и успешное выполнение запрошенной команды.
  • DENY (Denied) — выполнение команды отклонено.
  • PRTL (Partially Completed) — частичное выполнение команды (например, при применении к нескольким объектам)[3].

Пример:

ENT-USER-SECU:MyNE:sridev:101::password;

Символом-терминатором, обозначающим окончательное завершение ответного сообщения, является точка с запятой (;). Знак «больше» (>) используется как указатель продолжения для многочастных ответов, если вывод превышает установленный лимит и разбивается на несколько частей[4].

Сообщения об ошибках

В протоколе TL1 сообщения об ошибках являются частью стандартных ответных сообщений. Если сетевой элемент не может выполнить полученную команду, он возвращает ответное сообщение с кодом завершения DENY.

Общий синтаксис сообщения об ошибке включает стандартный заголовок, код завершения, четырехсимвольный код ошибки (<ERRCDE>) и опциональный текстовый комментарий (/* <ERRMSG> */):[5]

SID ДАТА ВРЕМЯ M CTAG DENY <ERRCDE> /* <ERRMSG> */ ;[5]

Ошибки, приводящие к генерации ответа с кодом DENY, делятся на пять основных категорий:[9]

  • Input (ошибки ввода) — некорректно введенные команды, неверные идентификаторы или данные[9].
  • Equipage (ошибки оснащения) — указанное оборудование не соответствует фактически установленному[9].
  • Status (ошибки состояния) — текущее состояние сетевого элемента не позволяет выполнить команду[9].
  • Privilege (ошибки привилегий) — недостаток прав для выполнения операции[9].
  • Resources (ошибки ресурсов) — нехватка ресурсов (например, памяти или процессорного времени)[9].

Примеры стандартных кодов ошибок:[5]

  • ICNV (Input, Command Not Valid) — недопустимая команда[5].
  • IITA (Input, Invalid Target Identifier) — неверный идентификатор цели[5].
  • IIAC (Input, Invalid Access Identifier) — неверный идентификатор доступа[5].

Сообщение подтверждения приёма TL1

Структура:

Сообщение подтверждения приёма TL1
Код подтверждения CTAG Конец
OK 101 >

Сообщение о подтверждении отправляется сетевым элементом только в том случае, если обработка входящей команды и формирование окончательного ответа занимает более двух секунд[8].[4]

Стандартные коды подтверждения:

  • IP (In Progress / В процессе) — команда принята и выполняется, но не может быть завершена в течение двух секунд[10].
  • PF (Printout Follows / Далее следует вывод) — выполнение команды в процессе, ответ будет отправлен по завершении задачи[10].
  • OK (All Right / Успешно) — команда была успешно получена[10].
  • RL (Repeat Later / Повторите позже) — команда не может быть обработана в данный момент из-за нехватки системных ресурсов[10].
  • NA (No Acknowledgment / Нет подтверждения) — статус выполнения неизвестен (например, из-за ошибки или искаженной команды)[10].
  • NG (No Good / Неудачно) — команда валидна, но не может быть выполнена из-за проблемы с параметрами[10].

Пример:

OK 101
>

Независимое сообщение TL1

undefined

Структура:

Независимое сообщение TL1
Заголовок сообщения Идентификатор Данные Завершение
SID Дата Время Код аварии ATAG Имя команды
MyNE 04-08-14 09:12:04 A 101 REPT EVT SESSION

Коды критичности аварийных сигналов определяют степень серьёзности события:

  • CR (Critical) — критическая авария, наивысший уровень серьёзности, требующий немедленного внимания.
  • MJ (Major) — серьёзная авария, указывающая на значительную проблему, влияющую на работу сервиса.
  • MN (Minor) — незначительная авария, не влияющая на предоставление услуг, но способная привести к более серьёзным проблемам, если её не устранить.
  • NA (Non-alarmed) — неаварийное сообщение (используется для отчётов о событиях, не связанных с авариями)[3].

Пример:

MyNE 04-08-14 09:12:04
A 101 REPT EVT SESSION
«root:NO,»
;

Основные типы автономных сообщений:

  • REPT ALM (отчёт об аварии) — информирует о возникновении, изменении серьёзности или прекращении аварийных состояний.
  • REPT EVT (отчёт о событии) — сообщает о событиях, не классифицируемых как аварии (например, вход пользователя в систему или изменение состояния оборудования).
  • REPT DBCHG (отчёт об изменении базы данных) — генерируется при изменениях в конфигурационной базе данных сетевого элемента[3].

Современный статус и интеграция

В 2025—2026 годах протокол TL1 считается унаследованным (legacy), однако он сохраняет значительное присутствие в Северной Америке при обслуживании ранее развёрнутого оборудования оптических (SONET) и широкополосных сетей[2][11].

В современных сетевых архитектурах TL1 вытесняется такими протоколами, как NETCONF и RESTful API. В отличие от TL1, ориентированного на ручное управление через текстовый интерфейс, новые стандарты обеспечивают более высокую степень автоматизации, поддерживают транзакционность операций и используют строгие модели данных (например, YANG)[12][13].

Для интеграции управляемых по TL1 сетевых элементов в современные системы поддержки операций (OSS) и управления сетью (NMS) применяется промежуточный уровень абстракции. Взаимодействие осуществляется через шлюзы-медиаторы и программные пробы (например, TL1 Probe), которые транслируют запросы современных API в команды TL1, а полученные от устройств текстовые ответы преобразуют в структурированные форматы[3][2].

Примечания

  1. ↑ TL1 Protocol – FVC::Telecom Network Services (амер. англ.). fvcommunicate.com. Дата обращения: 29 мая 2026.
  2. ↑ 1 2 3 What is TL1? DPS Telecom. Дата обращения: 29 мая 2026.
  3. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 TL1 Protocol: An Overview. ManageEngine. Дата обращения: 29 мая 2026.
  4. ↑ 1 2 3 4 How to Understand TL1 Protocol. DPS Telecom. Дата обращения: 29 мая 2026.
  5. ↑ 1 2 3 4 5 6 7 8 TL1 Tutorial. DPS Telecom. Дата обращения: 29 мая 2026.
  6. ↑ Downstream Interfaces. Oracle. Дата обращения: 29 мая 2026.
  7. ↑ TL1 Reference Guide. Cisco. Дата обращения: 29 мая 2026.
  8. ↑ 1 2 3 TL1 Protocol – FVC::Telecom Network Services. fvcommunicate.com. Дата обращения: 29 мая 2026.
  9. ↑ 1 2 3 4 5 6 TL1 Alarm and Error Codes. Cisco. Дата обращения: 29 мая 2026.
  10. ↑ 1 2 3 4 5 6 TL1 Command Response, Acknowledgement, and Error Messages. DPS Telecom. Дата обращения: 29 мая 2026.
  11. ↑ TL1: The Land That Time Forgot. Telecom Ramblings (1 марта 2020). Дата обращения: 29 мая 2026.
  12. ↑ Введение в NETCONF и YANG. Telecomo. Дата обращения: 29 мая 2026.
  13. ↑ NETCONF vs RESTCONF. devnetdan.com (27 сентября 2020). Дата обращения: 29 мая 2026.

Ссылки

Категории