RFC 4197 Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks

Network Working Group                                      M. Riegel
Request for Comments: 4197                                Siemens AG
Category: Informational                                 October 2005

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

Requirements for Edge-to-Edge Emulation of

Time Division Multiplexed (TDM) Circuits over Packet Switching Networks

PDF

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

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

Авторские права

Copyright (C) The Internet Society (2005).

Аннотация

В данном документе определены специфические требования к сквозной эмуляции устройств, передающих цифровые сигналы TDM¹ (как PDH², так и SONET/SDH³) в сетях пакетной коммутации. Документ использует архитектуру общего назначения PWE3⁴. Описанные требования основаны на базовых требованиях PWE3 (там, где эти требования применимы), к которым добавлены специфические требования для устройств TDM.

1. Введение

В этом документе рассматриваются требования для сквозной эмуляции каналов передачи цифровых сигналов TDM (PDH и SONET/SDH) через сети с коммутацией пакетов (PSN⁵). Эти требования основаны на архитектуре эмуляции прямых соединений 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⁹; этот случай описан в документе [TR-NWT-170]).

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

Термин SONET обозначает используемые в Северной Америке синхронные оптические сети, описанные в документе [T1.105]. Работа таких сетей основана на концепции передачи блоков Nx783 байтов¹⁰ с периодом 125 мксек. Такие блоки информации называют STS-1 SPE¹¹ и они могут объединяться для повышения эффективности использования полосы (например, STS-N) или делиться на более мелкие блоки (Virtual Tributary¹²). Объединенные блоки¹³ могут использоваться для передачи любого трафика от пакетов IP до ячеек ATM и сигналов DVS¹⁴. Отдельные блоки 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¹⁵).

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

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

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

• Специфика устройств TDM; в частности:

• необходимость согласования синхронизации входящих и исходящих сигналов для каждого направления PW¹⁶;

• необходимость ограничения флуктуаций¹⁷ синхронизации на передающей стороне в пределах, задаваемых соответствующим нормативным документом, с учетом вариаций задержки пакетов в сети 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¹⁸ или CCS¹⁹ для управления и анонсирования состояния телефонных приложений, передачи сигналов таким приложениям и маршрутизации (адресации) соединений. Такие сигналы должны гарантированно передаваться через сети 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²⁰ (см. [RFC3393]).

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

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

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

• 4.1 (Network Reference Model – сетевая эталонная модель),

• 4.2 (PWE3 Pre-processing – предварительная обработка PWE3),

• 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. Сценарии с сетью синхронизации

                    +-----+                 +-----+
   +-----+    |     |- - -|=================|- - -|     |    +-----+
   | /-- |<---------|............PW1..............|<---------| <-\ |
   || CE |    |     | PE1 |                 | PE2 |     |    |CE2 ||
   | \-> |--------->|............PW2..............|--------->| --/ |
   +-----+    |     |- - -|=================|- - -|     |    +-----+
                    +-----+                 +-----+
                       ^                       ^
                       |C                      |D
                       +-----------+-----------+
                                   |
                                  +-+
                                  |I|
                                  +-+

 

Рисунок 2: Сценарий синхронизации PE

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

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

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

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

• Сигналы E и J совпадают с D и C, соответственно.

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

•                   +-----+                 +-----+
   +-----+    |     |- - -|=================|- - -|     |    +-----+
   |     |<---------|............PW1..............|<---------|     |
   | CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
   |     |--------->|............PW2..............|--------->|     |
   +-----+    |     |- - -|=================|- - -|     |    +-----+
     ^              +-----+                 +-----+              ^
     |A                                                         G|
     +----------------------------+------------------------------+
                                  |
                                 +-+
                                 |L|
                                 +-+
  

  Рисунок 3: Сценарий синхронизации CEСценарий синхронизации CE:

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

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

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

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

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

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

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

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

• Сигналы A и G генерируются локально и не привязаны к общему источнику.

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

                                                              |G
                    +-----+                 +-----+           v
   +-----+    |     |- - -|=================|- - -|     |    +-----+
   |     |<---------|............PW1..............|<---------|     |
   | CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
   |     |--------->|............PW2..............|--------->|     |
   +-----+    |     |- - -|=================|- - -|     |    +-----+
        ^           +-----+<-------+------->+-----+
        |A                         |
                                  +-+
                                  |I|
                                  +-+

Рисунок 4: Сценарий с синхронизацией через сеть PSN

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

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

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

                     |J                                       |G
                     v                                        |
                    +-----+                 +-----+           v
   +-----+    |     |- - -|=================|- - -|     |    +-----+
   |     |<---------|............PW1..............|<---------|     |
   | CE1 |    |     | PE1 |                 | PE2 |     |    | CE2 |
   |     |--------->|............PW2..............|--------->|     |
   +-----+    |     |- - -|=================|- - -|     |    +-----+
        ^           +-----+                 +-----+
        |                                        ^
       A|                                       E|

 

Рисунок 5: Сценарий адаптивной синхронизации

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

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

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

На рисунке 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 NxVT-N / SDH NxVC-11/VC-12/VC-2/VC-3.

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

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

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

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

1. Доставка необходимой информации из заголовков:

1. для структурно-независимого транспорта эти функции могут обеспечиваться информационным уровнем;

2. для структурированного транспорта необходимая информация должна обеспечиваться уровнем инкапсуляции;

3. структурированный транспорт для устройств SONET/SDH должен сохранять информацию о пути (path overhead) как часть передаваемых данных (payload); соответствующие компоненты транспортной служебной информации (transport overhead) могут передаваться на уровне инкапсуляции.

2. Поддержка мультиплексирования и демультиплексирования, если таковые поддерживаются эмулируемыми устройствами. Это относится к соединениям NxDS0 (с сигнализацией или без нее) и NxVT-x в одном STS-1 SPE или VC-4:

1. для таких соединений уровни информации и инкапсуляции должны совместно обеспечивать раздельную трактовку каждого субканала (sub-circuit);

2. PW следует обеспечивать достаточный объем информации для мультиплексирования и демультиплексирования в NSP; снижение сложности эмуляции PW за счет использования схем NSP для мультиплексирования и демультиплексирования может служить предпочтительным решением.

3. Посредничество или прозрачная передача служебных сообщений (Maintenance Message) эмулируемых служб в зависимости от используемого сценария.

4. Рассмотрение вопроса о зависимости объема служебной информации от PSN (см. параграф 7.5).

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. Связность

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

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

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

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

1. согласовать входящую и исходящую синхронизацию, независимо от используемого сценария сетевой синхронизации;

2. сохранять флуктуации (jitter и wander) исходящей синхронизации в определяемых типом сервиса пределах, заданных соответствующими нормативными документами.

2. При доступности одного прецизионного источника синхронизации для всех устройств PE в данном домене уровню инкапсуляции следует обеспечивать возможность использования этого источника (например, для более точного восстановления синхронизации естественного сервиса).

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

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

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

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

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

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

2. Разрешить надежное детектирование потери пакетов (см. следующий параграф). В частности, следует разрешить оценку времени доставки следующего пакета и констатацию потери пакета на основе такой оценки.

3. Минимизировать влияние потери пакетов на восстановление синхронизации в приемном устройстве PE.

4. Повысить устойчивость TDM-интерфейса CE к потере пакетов путем подстановки устройством PE недостающих данных.

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

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

1. должны детектироваться;

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

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

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

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

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

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

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

2. мультиплексирование специфичных для приложения сигналов CE и данных эмулируемого сервиса в один PW;

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

4. вероятностное восстановление при возможных потерях пакетов в сети PSN;

5. детерминированное восстановление состояния приложения CE после организации PW и отказа в сети.

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

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

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

1. Эффективное использование полосы PSN. Предполагается, что размер заголовков уровня инкапсуляции не зависит от размера пакетов и увеличение размера передаваемых пакетов повышает эффективность использования полосы.

2. Незначительная сквозная задержка. Малые значения задержки являются основным требованием для голосовых приложений TDM. Задержка на пакетирование является одной из компонент общей задержки и растет при увеличении размера пакетов.

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

2. Уровень инкапсуляции может обеспечивать экономию полосы PSN за счет отказа от передачи поврежденных данных TDM через сеть PSN.
3. Уровень инкапсуляции может обеспечивать возможность экономии полосы PSN для случая структурированного транспорта за счет отказа от передачи неактивных каналов.
4. Уровень инкапсуляции может обеспечивать динамическое отключение временно бездействующих каналов в случае использования структурированного транспорта.
Если динамическое исключение каналов используется, по умолчанию недопустимо нарушение целостности структур, передаваемых через PW.
5. Для 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 обеспечивать детектирование, обработку и генерацию отчетов для следующих ситуаций:

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

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

3. Пакеты с некорректным форматом.

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

Уровню инкапсуляции для сквозной эмуляции сервиса TDM следует обеспечивать сбор данных мониторинга работы (PM²⁷), совместимых с параметрами, определенными для «классических» служб на базе 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, March 1997.

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

[RFC3916] Xiao, X., McPherson, D., and P. Pate, “Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)”, RFC 3916, September 2004.

[RFC3985] Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture”, RFC 3985, March 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, June 1996.

[RFC2736] Handley, M. and C. Perkins, “Guidelines for Writers of RTP Payload Format Specifications”, BCP 36, RFC 2736, December 1999.

[RFC3393] Demichelis, C. and P. Chimento, “IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)”, RFC 3393, November 2002.

[T1.105] ANSI T1.105 – 2001 Synchronous Optical Network (SONET) – Basic Description including Multiplex Structure, Rates, and Formats, May 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, January 1993

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

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

Sasha Vainshtein

Axerra Networks

EMail: sasha@axerra.com

Yaakov Stein

RAD Data Communication

EMail: yaakov_s@rad.com

Prayson Pate

Overture Networks, Inc.

EMail: prayson.pate@overturenetworks.com

Ron Cohen

Lycium Networks

EMail: ronc@lyciumnetworks.com

Tim Frost

Zarlink Semiconductor

EMail: tim.frost@zarlink.com

Адрес автора

Maximilian Riegel

Siemens AG

St-Martin-Str 76

Munich 81541

Germany

Phone: +49-89-636-75194

EMail: maximilian.riegel@siemens.com

---

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.