AAA

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

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

Документ содержит информацию, адресованную сообществу 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. Введение

В этом документе рассматриваются требования для сквозной эмуляции каналов передачи цифровых сигналов 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

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, обусловлены множеством причин:

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 для обеспечения корректной работы оконечного телефонного оборудования.

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

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

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

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

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

Все рассматриваемые в этом документе типы сервиса являются специальными случаями битовых потоков (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: Эталонная модель сетевой синхронизации

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

На рисунке 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  5. Детектирование и обработка отказов PW. Список таких отказов приведен в параграфе 7.9.

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

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

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. Уровень инкапсуляции должен обеспечивать сервис синхронизации, достаточный для того, чтобы:

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

    • сохранять флуктуации (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 и данных эмулируемого сервиса в один ;
  3. синхронизацию (с учетом специфических требований приложения) между сигналами CE и данными на выходе PW;
  4. вероятностное восстановление при возможных потерях пакетов в сети PSN;
  5. детерминированное восстановление состояния приложения CE после организации PW и отказа в сети.

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

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

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

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

    • Незначительная сквозная задержка. Малые значения задержки являются основным требованием для голосовых приложений 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 — performance monitoring), совместимых с параметрами, определенными для «классических» служб на базе TDM. Применимость [G.826] требует дополнительного изучения.

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

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

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

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

  1. [RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

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

  1. [RFC3916] Xiao, X., McPherson, D., and P. Pate, «Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)», RFC 3916, September 2004
  2. [RFC3985] Bryant, S. and P. Pate, «Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture», RFC 3985, March 2005
  3. [G.702] ITU-T Recommendation G.702 (11/88) — Digital hierarchy bit rates
  4. [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
  5. [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
  6. [G.707] ITU-T Recommendation G.707 (10/00) — Network node interface for the synchronous digital hierarchy (SDH)
  7. [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
  8. [G.810] ITU-T Recommendation G.810 (08/96) — Definitions and terminology for synchronization networks
  9. [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
  10. [Q.700] ITU-T Recommendation Q.700 (03/93) — Introduction to CCITT Signalling System No. 7
  11. [Q.931] ITU-T Recommendation Q.931 (05/98) — ISDN user-network interface layer 3 specification for basic call control
  12. [RFC1958] Carpenter, B., «Architectural Principles of the Internet», RFC 1958, June 1996.
  13. [RFC2736] Handley, M. and C. Perkins, «Guidelines for Writers of RTP Payload Format Specifications», BCP 36, RFC 2736, December 1999.
  14. [RFC3393] Demichelis, C. and P. Chimento, «IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)», RFC 3393, November 2002.
  15. [T1.105] ANSI T1.105 — 2001 Synchronous Optical Network (SONET) — Basic Description including Multiplex Structure, Rates, and Formats, May 2001
  16. [T1.107] ANSI T1.107 — 1995. Digital Hierarchy — Format Specification
  17. [TR-NWT-170] Digital Cross Connect Systems — Generic Requirements and Objectives, Bellcore, TR-NWT-170, January 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

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

Николай Малых, moc.milib@hkylamn