Перевод RFC 4197 — Требования к сквозной эмуляции каналов TDM через сети пакетной коммутации

: RFC: 4197; Оригинал: Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks; Категория: Информационный; Дата публикации: Октябрь 2005; Авторы: Maximilian Riegel , Sasha Vainshtein , Yaakov Stein , Prayson Pate , Ron Cohen , Tim Frost; Перевод: Николай Малых

Статус документа

Документ содержит информацию, адресованную сообществу Internet. В документе не содержится каких-либо стандартов Internet. Допускается свободное распространение документа.

Тезисы

В данном документе определены специфические требования к сквозной эмуляции устройств, передающих цифровые сигналы TDM (Time Division Multiplexed — мультиплексирование с разделением во времени), как PDH (Plesiochronous Digital Hierarchy — плезиохронная цифровая иерархия), так и SONET (Synchronous Optical NETwork — цифровая оптическая сеть) / SDH (Synchronous Digital Hierarchy — синхронная цифровая иерархия), в сетях пакетной коммутации. Документ использует архитектуру общего назначения PWE3 (Pseudo Wire Emulation Edge-to-Edge — эмуляция прямых соединений). Описанные требования основаны на базовых требованиях PWE3 (там, где эти требования применимы), к которым добавлены специфические требования для устройств TDM.

1. Введение
2. Предпосылки
3. Терминология
4. Эталонные модели
5. Эмулируемые службы
6. Базовые требования
7. Зависящие от сервиса требования
8. Вопросы безопасности
9. Литература
10. Разработчики документа

1. Введение

В этом документе рассматриваются требования для сквозной эмуляции каналов передачи цифровых сигналов TDM (PDH и SONET/SDH) через сети с коммутацией пакетов (PSN — Packet-Switched Networks). Эти требования основаны на архитектуре эмуляции прямых соединений PWE3, описанной в [RFC3985]. Документ опирается на применимые требования [RFC3916] и дополняет этот документ определением специфических требований для устройств TDM. Термин TDM в данном документе используется для обозначения синхронных битовых потоков PDH и SONET/SDH.

1.1. Устройства TDM в иерархии PDH

Битовые потоки, традиционно используемые в различных регионах, описаны в спецификации [G.702]. Например, в Северной Америке используются битовые потоки T1 (1,544 Мбит/с) и T3 (44,736 Мбит/с), а в Европе — E1 (2,048 Мбит/с) и E3 (34,368 Мбит/с). Хотя TDM можно использовать для передачи неструктурированных битовых потоков со скоростями, определенными в [G.702], существуют стандартизованные методы передачи битовых потоков в форме блоков, называемых кадрами (frame), каждый из которых содержит одинаковое число битов.

В связи с частотой выборки для голосового (телефонного) трафика скорости битовых потоков всегда кратны 8000, следовательно кадр T1 содержит 193 бита, а кадр E1 — 256 битов. Число битов в кадре называют размером кадра.

Кадрирование осуществляется путем периодической вставки в битовый поток определенных последовательностей битов, позволяющих определять границы кадров (например, 1 бит кадрирования на кадр T1 или 8-битовая последовательность на каждый кадр E1). Детали генерации и использования битов кадрирования рассмотрены в документах [G.704], [G.706] и [G.751]. В бесструктурных потоках TDM все биты могут использоваться для передачи информации.

Кадрированные потоки TDM зачастую используются для мультиплексирования множества каналов (например, телефонных соединений, каждое из которых включает 8000 восьмибитовых выборок в секунду) в последовательность временных интервалов, занимающих одинаковые позиции в каждом кадре. Такое мультиплексирование называют «channelized TDM» и оно вносит в поток дополнительную структуру.

В некоторых случаях кадрирование также определяет группы последовательных кадров, которые называют мультикадрами. Такая группировка создает дополнительный уровень структурирования битовых потоков TDM.

1.1.1. Структура и транспортные режимы TDM

Unstructured TDM — бесструктурный поток TDM
Битовый поток TDM передаваемый со скоростью, определенной в [G.702]. Все биты такого потока могут использоваться для передачи пользовательских данных.
Structured TDM — структурированный поток TDM
Поток TDM с одним или несколькими уровнями структурирования, включая кадрирование, канализацию и мультикадры (в соответствии со спецификациями [G.704], [G.751] и [T1.107]).
Structure-Agnostic Transport — структурно-независимый транспорт
Передача бесструктурных потоков TDM или структурированных потоков TDM в тех случаях, когда структура потока не имеет значения с точки зрения транспорта. В таких случаях любая структуризация, которая может присутствовать в потоке, прозрачно передается вместе с данными и инкапсуляция не обеспечивает механизмов обнаружения или использования структуры потока.
Structure-Aware Transport — структурированный транспорт
Транспорт TDM является структурированным, когда по крайней мере один из уровней структуры принимается во внимание. При структурированном транспорте не существует гарантии передачи всех битов потока TDM через сеть PSN (в частности, биты синхронизации могут вырезаться из потока на входе в сеть пакетной коммутации и обычно восстанавливаются на выходе) и соблюдения порядка следования битов в потоке (порядок битов обычно восстанавливается на выходе из PSN, однако известно по крайней мере одно исключение из этого правила — потеря мультикадровой синхронизации между данными TDM и битами CAS, создаваемой цифровыми кросс-коннекторами, используемыми как NSP (Native Service Processing); этот случай описан в документе [TR-NWT-170]).

1.2. Устройства SONET/SDH

Термин SONET обозначает используемые в Северной Америке синхронные оптические сети, описанные в документе [T1.105]. Работа таких сетей основана на концепции передачи блоков Nx783 байтов с периодом 125 мксек. Такие блоки информации называют STS-1 SPE (Synchronous Payload Envelope) и они могут объединяться для повышения эффективности использования полосы (например, STS-N) или делиться на более мелкие блоки (Virtual Tributary — Виртуальный поток). Объединенные блоки могут использоваться для передачи любого трафика от пакетов IP до ячеек ATM и сигналов DVS (Digital Video Signals — цифровой поток видео-информации). Отдельные блоки STS-1 SPE зачастую используются для передачи индивидуальных каналов TDM (DS3 или E3). Когда 783-байтовые контейнеры делятся на части, они обычно используются для передачи отдельных потоков TDM T1 или E1.

SDH представляет собой международный аналог и расширение SONET, описанное в [G.707].

Как SONET, так и SDH добавляют достаточно большой объем служебной информации (transport overhead), используемой для мониторинга, детектирования отказов и других функций обслуживания на различных типах оптических и электрических соединений. В дополнение к этому информационные блоки (payload area) также включают служебную информацию для сквозного мониторинга, детектирования отказов и обслуживания. Если блоки данных делятся на узкополосные каналы (например, T1/E1), добавляется служебная информация для сквозного мониторинга отдельных каналов T1/E1.

В этом документе обсуждаются требования для случаев эмуляции сервиса SONET/SDH. Такие службы включают сквозную эмуляцию информационных блоков SONET (STS-1 SPE), эмуляцию объединенных блоков (STS-N SPE), а также эмуляцию дробных каналов (sub-STS-1). Дробные каналы, равно как их аналоги для случая SDH, обозначаются термином VT(Virtual Tributaries — виртуальные разветвления).

2. Предпосылки

В [RFC3916] указаны общие требования к сквозной эмуляции устройств различных типов. Однако эти требования, равно как и требования [RFC3985], не учитывают специфику устройств TDM.

Необходимость создания документа, дополняющего требования [RFC3916] в части сквозной эмуляции устройств TDM, обусловлены множеством причин:

Специфика устройств TDM; в частности:
- необходимость согласования синхронизации входящих и исходящих сигналов для каждого направления PW (Pseudo Wire — псевдо-соединение);
- необходимость ограничения флуктуаций синхронизации на передающей стороне в пределах, задаваемых соответствующим нормативным документом, с учетом вариаций задержки пакетов в сети PSN.
Специфика приложений, использующих устройства TDM (например, телефонная связь):
- необходимость принятия мер по минимизации сквозной задержки;
- относительная устойчивость к возникновению ошибок в передаваемых данных.
В некоторых случаях могут возникать специфические требования; например, для передачи сигнальной информации характерны:
- сравнительная устойчивость к задержкам в одном направлении;
- чувствительность к возникающим при передаче ошибкам.
Специфика ожиданий потребителя относительно сквозных характеристик сервиса, который основан на эмуляции устройств TDM. Например, опыт реализации таких соединений через сети SONET/SDH показывает:
- необходимость изоляции проблем, вносимых PSN, от проблем, возникающих за пределами пакетных сетей;
- чувствительность к ошибочным соединениям;
- чувствительность к неожиданным разрывам соединений и т. д.

3. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC2119].

Термины, определенные в параграфе 1.4 документа [RFC3985], используются в соответствии с этими определениями. Однако ряд терминов используется в специфической для TDM трактовке. В частности:

Сети TDM используют сигнализацию CAS (Channel-Associated Signaling — поканальная сигнализация) или CCS (Common Channel Signaling — сигнализация с общим сигнальным каналом) для управления и анонсирования состояния телефонных приложений, передачи сигналов таким приложениям и маршрутизации (адресации) соединений. Такие сигналы должны гарантированно передаваться через сети PSN для обеспечения корректной работы оконечного телефонного оборудования.

CAS (Channel-Associated Signaling)
Сигналы CAS передаются в том же кадре T1 или E1, что и телефонные разговоры, но используют отдельную от голосового канала полосу. Поскольку сигнализация CAS может передаваться при более низких скоростях, нежели TDM-трафик во временных интервалах, не возникает необходимости обновления всех битов CAS в каждом кадре TDM. Следовательно, цикл прохода всех сигнальных битов CAS завершается только после передачи некоторого количества кадров TDM — это количество определяет новую структуру, называемую мультикадром (multiframe) или суперкадром (superframe). Общеприняты мультикадры размером в 12, 16 или 24 кадра, продолжительность которых составляет 1,5, 2 и 3 мсек., соответственно.
CCS (Common Channel Signaling)
Сигнализация CCS использует отдельный цифровой канал для передачи асинхронных сообщений, относящихся к состоянию телефонных приложений, в выделенных временных интервалах потока TDM. Этот канал может представлять собой один или несколько смежных временных интервалов одного транка TDM (связанная с транком сигнализация CCS) или может передаваться через независимую сеть.

CCS обычно работает на основе HDLC с использованием кодов бездействия (idle code) или сообщений keep-alive, передаваемых в отсутствие сигнальных событий (например, снятия трубки). Примерами основанных на HDLC систем CCS являются SS7 [Q.700] и ISDN PRI [Q.931].

Примечание: Для сетей TDM будут использоваться термины «jitter» и «wander» в соответствии с определениями [G.810] для описания кратковременных и долгосрочных вариаций значимых цифровых сигналов. Для сетей PSN эти характеристики будем обозначать термином PDV (packet delay variation — вариации задержки пакетов) (см. [RFC3393]).

4. Эталонные модели

4.1. Базовые модели PWE3

Базовые модели определены в [RFC3985]

4.1 (Network Reference Model — сетевая эталонная модель),
4.2 (PWE3 Pre-processing — предварительная обработка),
4.3 (Maintenance Reference Model — эталонная модель обслуживания),
4.4 (Protocol Stack Reference Model — эталонная модель стека протоколов),
4.5 (Pre-processing Extension to Protocol Stack Reference Model — расширение предварительной обработки для эталонной модели стека протоколов).

Эти модели полностью применимы к настоящему документу без каких-либо изменений.

Все рассматриваемые в этом документе типы сервиса являются специальными случаями битовых потоков (Bit-stream) и структурированных битовых потоков (Structured bit-stream), определенными в параграфе 3.3 документа [RFC3985].

4.2. Восстановление синхронизации

Восстановление синхронизации (Clock recovery) — это воссоздание битов синхронизации на основе потока доставленных пакетов. Решение такой задачи при значительных флуктуациях в потоке принимаемых пакетов может быть достаточно сложным.

4.3. Эталонная модель сетевой синхронизации

На рисунке 1 показан базовый вариант эталонной модели сетевой синхронизации:

       +---------------+               +---------------+
       |      PE1      |               |      PE2      |
    K  |   +--+        |               |        +--+   |  G
    |  |   | J|        |               |        | H|   |  |
    v  |   v  |        |               |        v  |   |  v
+---+  | +-+  +-+  +-+ |  +--+   +--+  | +-+  +-+  +-+ |  +---+
|   |  | |P|  |D|  |P| |  |  |   |  |  | |P|  |E|  |P| |  |   |
|   |<===|h|<:|e|<:|h|<:::|  |<::|  |<:::|h|<:|n|<=|h|<===|   |
|   |  | |y|  |c|  |y| |  |  |   |  |  | |y|  |c|  |y| |  |   |
| C |  | +-+  +-+  +-+ |  |  |   |  |  | +-+  +-+  +-+ |  | C |
| E |  |               |  |S1|   |S2|  |               |  | E |
| 1 |  | +-+  +-+  +-+ |  |  |   |  |  | +-+  +-+  +-+ |  | 2 |
|   |  | |P|  |E|  |P| |  |  |   |  |  | |P|  |D|  |P| |  |   |
|   |===>|h|=>|n|:>|h|:::>|  |::>|  |:::>|h|:>|e|=>|h|===>|   |
|   |  | |y|  |c|  |y| |  |  |   |  |  | |y|  |c|  |y| |  |   |
+---+  | +-+  +-+  +-+ |  +--+   +--+  | +-+  +-+  +-+ |  +---+
 ^  ^  |   |  ^        |               |        |  ^   |  ^  ^
 |  |  |   |B |        |<------+------>|        |  |   |  |  |
 |  A  |   +--+        |       |       |        +--+-E |  F  |
 |     +---------------+      +-+      +---------------+     |
 |             ^              |I|               ^            |
 |             |              +-+               |            |
 |             C                                D            |
 +-----------------------------L-----------------------------+
Рисунок 1: Эталонная модель сетевой синхронизации

Описание использованных на рисунке обозначений приведено ниже.

CE1, CE2
Пользовательские оконечные устройства, завершающие эмулируемые соединения TDM.
PE1, PE2
Краевые устройства сетевых операторов, адаптирующие сервис для PW.
S1, S2
Магистральные маршрутизаторы операторов.
Phy
Физический интерфейс, завершающий соединение TDM.
Enc
Интерфейс PW на границе PSN, где происходит инкапсуляция.
Dec
Связанный с CE интерфейс PW, где происходит декапсуляция. Этот интерфейс содержит компенсационный буфер (jitter buffer) ограниченного размера.
"==>"
Устройства с TDM-подключением.
"::>"
PW, обеспечивающие сквозную эмуляцию соединений TDM.

Символы A-L обозначают варианты синхронизации:

A
Синхронизация, используемая CE1 для передачи от устройства с TDM-подключением в направлении CE1.
B
Синхронизация, восстановленная PE1 из входящего потока TDM. A и B имеют одинаковую частоту.
G
Синхронизация, используемая CE2 для передачи от устройства с TDM-подключением в направлении CE2.
H
Синхронизация, восстановленная PE2 из входящего потока TDM. G и H имеют одинаковую частоту.
C, D
Локальные генераторы синхросигналов, доступные PE1 и PE2, соответственно.
E
Синхронизация, используемая PE2 для передачи сигналов от устройства с TDM-подключением устройству CE2 (восстановленная синхронизация).
F
Синхронизация, восстановленная CE2 из входящего потока TDM (E и F имеют одинаковую частоту).
I
если этот сигнал существует, он является общим источником синхронизации для PE1 и PE2.
J
Синхронизация, используемая PE1 для передачи от устройства с TDM-подключением устройству CE1 (восстановленная синхронизация).
K
Синхронизация, восстановленная CE1 из входящего потока TDM (J и K имеют одинаковую частоту).
L
Если этот сигнал существует, он является общим источником синхронизации для CE1 и CE2. Отметим, что различные пары устройств CE могут использовать разные опорные источники синхросигналов.

Требование сквозной эмуляции соединений TDM заключается в том, что сигналы B и E, а также H и J имели одинаковые частоты. Подходящий метод синхронизации будет определяться схемой сетевой синхронизации.

Ниже рассмотрены варианты сценариев синхронизации.

4.3.1. Сценарии с сетью синхронизации

В зависимости от того, какая часть сети имеет общий источник синхронизации, возможны два варианта сценария:

Сценарий синхронизации PE:

Рисунок 2 представляет собой адаптированный вариант эталонной сетевой модели и представляет сценарий PE-синхронизации.

Общий источник сигналов I доступен всем устройствам PE, а локальные источники C и D привязаны к I:

Сигналы E и J совпадают с D и C, соответственно.
Сигналы A и G совпадают с сигналами K и F, соответственно (т. е., устройства CE1 и CE2 используют шлейфовую синхронизацию).

                 +-----+                 +-----+
+-----+    |     |- - -|=================|- - -|     |    +-----+
| /-- |<---------|............PW1..............|<---------| <-\ |
|| CE |    |     | PE1 |                 | PE2 |     |    |CE2 ||
| \-> |--------->|............PW2..............|--------->| --/ |
+-----+    |     |- - -|=================|- - -|     |    +-----+
                 +-----+                 +-----+
                    ^                       ^
                    |C                      |D
                    +-----------+-----------+
                                |
                               +-+
                               |I|
                               +-+
Рисунок 2: Сценарий синхронизации PE

Сценарий синхронизации CE:

На рисунке 3 показан адаптированный вариант базовой модели сетевой синхронизации для случая CE.

Общим опорным источником является сигнал L, доступный всем устройствам CE, а локальные источники A и G привязаны к L:

Сигналы E и J совпадают с G и A, соответственно (т. е., PE1 и PE2 используют шлейфовую синхронизацию).

                 +-----+                 +-----+
+-----+    |     |- - -|=================|- - -|     |    +-----+
|     |<---------|............PW1..............|<---------|     |
| CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
|     |--------->|............PW2..............|--------->|     |
+-----+    |     |- - -|=================|- - -|     |    +-----+
  ^              +-----+                 +-----+              ^
  |A                                                         G|
  +----------------------------+------------------------------+
                               |
                              +-+
                              |L|
                              +-+
Рисунок 3: Сценарий синхронизации CE

Отметим, что в обоих случаях синхро сигналы через сеть PSN не передаются.

4.3.2. Сценарий с синхронизацией через сеть PSN

В этом случае каждое устройство CE использует свой источник для синхронизации передачи и сигналы этого источника должны передаваться через сеть PSN и восстанавливаться соответствующим удаленным устройством PE. При восстановлении может использоваться общий для PE источник сигналов I.

На рисунке 4 показан сценарий синхронизации через сеть.

Общий источник синхросигналов I доступен всем устройствам PE, а локальные генераторы C и D привязаны к I:

Сигналы A и G генерируются локально и не привязаны к общему источнику.
Сигналы E и J генерируются в соответствии с общим источником синхронизации, доступным всем устройствам PE.

В несколько отличающемся варианте этого сценария одно (но не оба) из устройств CE может использовать сигналы синхронизации приема в качестве источника синхронизации передачи (шлейфовая синхронизация).

                 +-----+                 +-----+           v
+-----+    |     |- - -|=================|- - -|     |    +-----+
|     |<---------|............PW1..............|<---------|     |
| CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
|     |--------->|............PW2..............|--------->|     |
+-----+    |     |- - -|=================|- - -|     |    +-----+
     ^           +-----+<-------+------->+-----+
     |A                         |
                               +-+
                               |I|
                               +-+
Рисунок 4: Сценарий с синхронизацией через сеть PSN

В этом случае синхросигналы (различие между опорным сигналом I и входящей синхронизацией A) должны явно передаваться от устройства PE на входе устройству PE на выходе.

4.3.3. Сценарий адаптивной синхронизации

Сценарий адаптивной синхронизации характеризуется 2 особенностями:

отсутствует общий источник сигналов I, доступный устройствам PE1 и PE2.
Отсутствует общий источник сигналов L, доступный устройствам CE1 и CE2.

На рисунке 5 показан сценарий адап тивной синхронизации.

                  |J                                       |G
                  v                                        |
                 +-----+                 +-----+           v
+-----+    |     |- - -|=================|- - -|     |    +-----+
|     |<---------|............PW1..............|<---------|     |
| CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
|     |--------->|............PW2..............|--------->|     |
+-----+    |     |- - -|=================|- - -|     |    +-----+
     ^           +-----+                 +-----+
     |                                        ^
    A|                                       E|
Рисунок 5: Сценарий адаптивной синхронизации

Синхронизация сигналов A и E в этом сценарии сложнее, нежели в других сценариях синхронизации.

Отметим, что разница между сигналами A и E должна быть достаточно малой, чтобы обеспечить отсутствие случаев переполнения или опустошения компенсационного буфера.

В этом сценарии синхросигналы могут явно передаваться PE на входе устройству PE на выходе (например, с помощью RTP).

5. Эмулируемые службы

В этой главе определены требования к уровням информации (payload) и инкапсуляции для сквозной эмуляции сервиса TDM с битовыми и структурированными битовыми потоками пользовательской информации.

Всякий раз, когда это возможно, требования данного документа следует выполнять только на уровне инкапсуляции. В редких случаях применимости требований к обоим уровням это отмечается в документе явно.

Обусловленный сервисом уровень инкапсуляции для сквозной эмуляции устройств включает в себя два варианта поддержки служб через сети PSN.

5.1. Структурно-независимая передача сигналов за пределами PDH

Независимый от структуры транспорт рассматривается для следующих случаев:

E1 в соответствии с [G.704].
T1 (DS1) в соответствии с [G.704].
E3 в соответствии с [G.751].
T3 (DS3) в соответствии с [T1.107].

5.2. Передача структурированных потоков за пределами PDH

Структурированный транспорт рассматривается для сигналов:

E1/T1 с одним уровнем структурирования, вносимым кадрами [G.704].
NxDS0 с использованием CAS или без CAS.

5.3. Структурированный транспорт для устройств SONET/SDH

Структурированный транспорт рассматривается для следующих каналов SONET/SDH:

SONET STS-1 SPE/SDH VC-3.
SONET STS-Nc SPE (N = 3, 12, 48, 192) / SDH VC-4, VC-4-4c, VC-4-16c, VC-4-64c.
SONET VT-N (N = 1.5, 2, 3, 6) / SDH VC-11, VC-12, VC-2.
SONET Nx VT-N / SDH Nx VC-11/VC-12/VC-2/VC-3.

Отметим, что не существует независимого от структуры транспорта для SONET/SDH. Для этого типа структура должна приниматься во внимание всегда.

6. Базовые требования

6.1. Общие требования к PW

Уровни инкапсуляции и информации должны удовлетворять общим требованиям к PW, определенным в [RFC3916]:

Доставка необходимой информации из заголовков:
- для структурно-независимого транспорта эти функции могут обеспечиваться информационным уровнем;
- для структурированного транспорта необходимая информация должна обеспечиваться уровнем инкапсуляции;
- структурированный транспорт для устройств SONET/SDH должен сохранять информацию о пути (path overhead) как часть передаваемых данных (payload); соответствующие компоненты транспортной служебной информации (transport overhead) могут передаваться на уровне инкапсуляции.
Поддержка мультиплексирования и демультиплексирования, если таковые поддерживаются эмулируемыми устройствами. Это относится к соединениям NxDS0 (с сигнализацией или без нее) и NxVT-x в одном STS-1 SPE или VC-4:
- для таких соединений уровни информации и инкапсуляции должны совместно обеспечивать раздельную трактовку каждого суб-канала (sub-circuit);
- PW следует обеспечивать достаточный объем информации для мультиплексирования и демультипрексирования в NSP; снижение сложности эмуляции PW за счет использования схем NSP для мультиплексирования и демультиплексирования может служить предпочтительным решением.
Посредничество или прозрачная передача служебных сообщений (Maintenance Message) эмулируемых служб в зависимости от используемого сценария.
Рассмотрение вопроса о зависимости объема служебной информации от PSN (см. параграф 7.5).
Детектирование и обработка отказов PW. Список таких отказов приведен в параграфе 7.9.

Индикаторы фрагментации могут использоваться структурированным транспортом в тех случаях, когда структура данных вступает в конфликт с задержками при пакетировании или возникают проблемы с Path MTU между парами устройств PE.

Приведенное ниже требование [RFC3916] неприменимо для эмуляции устройств TDM:

поддержка различных размеров PDU.

6.2. Общие требованиями в части передаваемых данных

Структурно-независимый транспорт трактует соединения TDM как битовые потоки данных, определенные в [RFC3985].

Структурированный транспорт трактует такие соединения как структурированные битовые потоки, определенные в [RFC3985].

Соответственно, уровень инкапсуляции должен обеспечивать единую службу упорядочивания и ему следует при необходимости обеспечивать службу синхронизации (см. параграф 4.3).

Примечание: Уровень инкапсуляции может поддерживать Length-сервис, но это не является обязательным.

6.3. Вопросы архитектуры

Уровни информации и инкапсуляции следует реализовать на основе единых архитектурных принципов, как описано в главе 3 [RFC1958] и [RFC3985].

При необходимости информационный уровень может использовать ту или иную фору адаптации естественных данных TDM для достижения хорошо документированных задач. В таких случаях следует использовать методы адаптации стандартов.

7. Зависящие от сервиса требования

7.1. Связность

Эмуляция должна обеспечивать передачу сигналов между однотипными устройствами AC (см. главу 5), использующими (если это применимо) одинаковую скорость.
Уровню инкапсуляции следует сохранять независимость от специфических характеристик соединения между устройствами AC и PE на разных сторонах PW.

7.2. Синхронизация

Уровень инкапсуляции должен обеспечивать сервис синхронизации, достаточный для того, чтобы:
- согласовать входящую и исходящую синхронизацию независимо от используемого сценария сетевой синхронизации;
- сохранять флуктуации (jitter и wander) исходящей синхронизации в определяемых типом сервиса пределах, заданных соответствующими нормативными документами.
При доступности одного прецизионного источника синхронизации для всех устройств PE в данном домене, уровню инкапсуляции следует обеспечивать возможность использования этого источника (например, для более точного восстановления синхронизации естественного сервиса).

7.3. Устойчивость к ошибкам

Устойчивость эмулируемого сервиса к ошибкам зависит не только от протокола сквозной эмуляции, но и от корректной реализации перечисленных ниже процедур.

7.3.1. Потеря пакетов

Сквозная эмуляция устройств TDM может предполагать очень малую вероятность потери пакетов между входным и выходным устройствами PE. В частности не требуется обеспечивать механизмов повтора передачи.

Для минимизации воздействия потери пакетов на принимающее устройство уровню инкапсуляции следует:

Разрешить принимающему устройству PE независимую интерпретацию данных TDM в каждом пакете (см. [RFC2736]). Это требование может не соблюдаться в тех случаях, когда приемному устройству PE приходиться интерпретировать структуры, размер которых превышает MTU для пути между парой PE.
Разрешить надежное детектирование потери пакетов (см. следующий параграф). В частности, следует разрешить оценку времени доставки следующего пакета и констатацию потери пакета на основе такой оценки.
Минимизировать влияние потери пакетов на восстановление синхронизации в приемном устройтве PE.
Повысить устойчивость TDM-интерфейса CE к потере пакетов путем подстановки устройством PE недостающих данных.

7.3.2. Нарушение порядка доставки

Уровень инкапсуляции должен обеспечивать механизмы гарантированной упорядоченной доставки пакетов, передающих данные TDM через сети PSN. Пакеты, доставленные с нарушением порядка:

должны детектироваться;
сдедует восстанавливать порядок следования пакетов, если они были доставлены не слишком поздно и не слишком рано.

Пакеты, для которых невозможно восстановить порядок следования, должны трактоваться как потерянные.

7.4. Сигнализация CE

Неструктурированные соединения TDM обычно не требуют каких-либо механизмов передачи сигнальной информации CE, являющейся частью эмулируемого сервиса.

Некоторые приложения CE, использующие структурированные соединения TDM (например, телефония) требуют передачи сигнальной информации об изменении состояния этих соединений.

Уровню инкапсуляции следует поддерживать сигнальную информацию о состоянии приложений CE для соответствующих устройств, обеспечивая:

возможность поддержки различных схем сигнализации с минимальным воздействием на инкапсуляцию данных TDM;
мультиплексирование специфичных для приложения сигналов CE и данных эмулируемого сервиса в один ;
синхронизацию (с учетом специфических требований приложения) между сигналами CE и данными на выходе PW;
вероятностное восстановление при возможных потерях пакетов в сети PSN;
детерминированное восстановление состояния приложения CE после организации PW и отказа в сети.

Для сигналов CE, используемых в целях обслуживания (управление шлейфами, мониторинг и т.п.), следует применять базовый протокол обслуживания PWE3.

7.5. Использование полосы PSN

Уровню инкапсуляции следует обеспечивать возможность эффективного согласования перечисленных ниже противоречивых требований:
- Эффективное использование полосы PSN. Предполагается, что размер заголовков уровня инкапсуляции не зависит от размера пакетов и увеличение размера передаваемых пакетов повышает эффективность использования полосы.
- Незначительная сквозная задержка. Малые значения задержки являются основным требованием для голосовых приложений TDM. Задержка на пакетирование является одной из компонент общей задержки и растет при увеличении размера пакетов.
Компенсационный буфер увеличивает задержку для эмулируемого соединения. Не следует дозволять, чтобы дополнительная задержка, вносимая компенсационным буфером, превышала значение вариации задержки пакетов в сети PSN.
Уровень инкапсуляции может обеспечивать экономию полосы PSN за счет отказа от передачи поврежденных данных TDM через сеть PSN.
Уровень инкапсуляции может обеспечивать возможность экономии полосы PSN для случая структурированного транспорта за счет отказа от передачи неактивных каналов.
Уровень инкапсуляции может обеспечивать динамическое отключение временно бездействующих каналов в случае использования структурированного транспорта.

Если динамическое исключение каналов используется, по умолчанию недопустимо нарушение целостности структур, передаваемых через PW.
Для NxDS0 уровень инкапсуляции должен обеспечивать возможность сохранять сквозную задержку независимо от скорости.

7.6. Вариации задержки пакетов

Уровню инкапсуляции следует обеспечивать возможность компенсации вариаций задержки пакетов пока флуктуации синхронизации на передающей стороне не выходят за нормативные пределы.

Уровень инкапсуляции может обеспечивать в процессе работы адаптацию задержки, вносимой компенсационным буфером, если вариации задержки пакетов изменяются с течением времени. Такая адаптация может вносить дополнительные ошибки (в допустимых нормативами пределах), но не следует позволять увеличение флуктуаций wander) синхронизации на передающей стороне.

7.7. Совместимость с инфраструктурой сетей пакетной коммутации (PSN)

Комбинациям уровня инкапсуляции и уровней туннелирования PSN, используемых для сквозной эмуляции устройств TDM, следует быть совместимыми с существующей инфраструктурой PSN. В частности, следует обеспечивать совместимость с механизмами сжатия заголовков в каналах, где это имеет существенное щзначение.

7.8. Контроль насыщения

Устройства TDM работают с постоянной скоростью и, следовательно, вносят в сеть PSN постоянный уровень трафика. Механизм изменения скорости, используемый протоколом TCP для контроля насыщения в сети, следовательно неприменим для эмуляции устройств TDM.

Должна обеспечиваться возможность разрыва эмулируемых TDM PW при возникновении насыщения в сети.

Следует принимать меры по предотвращению ситуаций, когда множество TDM PW одновременно отключается (shut down) и восстанавливается, поскольку это приводит к нестабильности работы PSN.

Дополнительные сведения о контроле насыщения можно найти в параграфе 6.5 документа [RFC3985].

7.9. Детектирование отказов

Уровню инкапсуляции для сквозной эмуляции сервиса TDM следует независимо или совместно с нижележащим уровнем стека PWE3 обеспечивать детектирование, обработку и генерацию отчетов для следующих ситуаций:

Ошибочные соединение или заблудившиеся пакеты. Важность этого требования обусловлена ожиданиями пользователей, основанными на надежном детектировании ошибочных соединений в сетях SONET/SDH.
Потеря пакетов. Детектирование потери пакетов требуется для обеспечения целостности синхронизации, как обсуждалось в параграфе 7.3.1. Кроме того, механизм детектирования потери пакетов следует обеспечивать для локализации отказов в эмулируемых устройствах.
Пакеты с некорректным форматом.

7.10. Мониторинг работы

Уровню инкапсуляции для сквозной эмуляции сервиса TDM следует обеспечивать сбор данных мониторинга работы (PM — performance monitoring), совместимых с параметрами, определенными для «классических» служб на базе TDM. Применимость [G.826] требует дополнительного изучения.

8. Вопросы безопасности

Рассмотрение вопросов безопасности в [RFC3916] полностью применимо для случая эмуляции служб TDM. Кроме того, службы TDM чувствительны к вариациям задержки пакетов [параграф 7.6] и требуется защита от такого типа атак.

9. Литература

9.1. Нормативные документы

[RFC2119]

Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, Март 1997.

9.2. Информационные ресурсы

[RFC3916]	Xiao, X., McPherson, D., and P. Pate, «Требования к сквозной эмуляции псевдо-провода (PWE3)», RFC 3916, Сентябрь 2004
[RFC3985]	Bryant, S. и P. Pate, «Архитектура сквозной эмуляции псевдо-провода (PWE3)», RFC 3985, Март 2005
[G.702]	ITU-T Recommendation G.702 (11/88) — Digital hierarchy bit rates
[G.704]	ITU-T Recommendation G.704 (10/98) — Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s hierarchical levels
[G.706]	ITU-T Recommendation G.706 (04/91) — Frame alignment and cyclic redundancy check (CRC) procedures relating to basic frame structures defined in Recommendation G.704
[G.707]	ITU-T Recommendation G.707 (10/00) — Network node interface for the synchronous digital hierarchy (SDH)
[G.751]	ITU-T Recommendation G.751 (11/88) — Digital multiplex equipments operating at the third order bit rate of 34 368 Kbit/s and the fourth order bit rate of 139 264 Kbit/s and using positive justification
[G.810]	ITU-T Recommendation G.810 (08/96) — Definitions and terminology for synchronization networks
[G.826]	ITU-T Recommendation G.826 (02/99) — Error performance parameters and objectives for international, constant bit rate digital paths at or above the primary rate
[Q.700]	ITU-T Recommendation Q.700 (03/93) — Introduction to CCITT Signalling System No. 7
[Q.931]	ITU-T Recommendation Q.931 (05/98) — ISDN user-network interface layer 3 specification for basic call control
[RFC1958]	Carpenter, B., «Architectural Principles of the Internet», RFC 1958, Июнь 1996.
[RFC2736]	Handley, M. и C. Perkins, «Guidelines for Writers of RTP Payload Format Specifications», BCP 36, RFC 2736, Декабрь 1999.
[RFC3393]	Demichelis, C. и P. Chimento, «IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)», RFC 3393, Ноябрь 2002.
[T1.105]	ANSI T1.105 — 2001 Synchronous Optical Network (SONET) — Basic Description including Multiplex Structure, Rates, and Formats, Май 2001
[T1.107]	ANSI T1.107 — 1995. Digital Hierarchy — Format Specification
[TR-NWT-170]	Digital Cross Connect Systems — Generic Requirements and Objectives, Bellcore, TR-NWT-170, Январь 1993

10. Разработчики документа

В разработку этого документа внесли свой вклад:

Sasha Vainshtein
Axerra Networks
EMail: moc.arrexa@ahsas

Yaakov Stein
RAD Data Communication
EMail: moc.dar@s_vokaay

Prayson Pate
Overture Networks, Inc.
EMail: moc.skrowtenerutrevo@etap.nosyarp

Ron Cohen
Lycium Networks
EMail: moc.skrowtenmuicyl@cnor

Tim Frost
Zarlink Semiconductor
EMail: moc.knilraz@tsorf.mit

Адрес автора

Maximilian Riegel
Siemens AG
St-Martin-Str 76
Munich 81541 Germany
Phone: +49-89-636-75194
EMail: moc.snemeis@legeir.nailimixam

RFC 4197 — Требования к сквозной эмуляции каналов TDM через сети пакетной коммутации