Network Working Group                                                                                           M. Riegel
Request for Comments: 4197 Category: Informational
Siemens AG October 2005
Требования к сквозной эмуляции каналов TDM через сети пакетной коммутации
Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks
Статус документа
Документ содержит информацию, адресованную сообществу Internet. В документе не содержится каких-либо стандартов Internet. Допускается свободное распространение документа.
Авторские права
Copyright (C) The Internet Society (2005).
Тезисы
В данном документе определены специфические требования к сквозной эмуляции устройств, передающих цифровые сигналы TDM1 (как PDH2, так и SONET/SDH3) в сетях пакетной коммутации. Документ использует архитектуру общего назначения PWE34. Описанные требования основаны на базовых требованиях PWE3 (там, где эти требования применимы), к которым добавлены специфические требования для устройств TDM.
Оглавление
1. В
2. П
3. Т
4. Э
.............................................................................................2
..........................................................................................2
........................................................................................2
.........................................................................................2
........................................................................................3..
............................................................................................3
..........................................................................................4
4.1. Базовые модели PWE3......................................................................................................................................................................4..
.............................................................................................4
.........................................................................................4
..........................................................................................5
...........................................................................................6
........................................................................................6
.............................................................................................6
........................................................................................6
........................................................................................6
........................................................................................7
...........................................................................................7
.........................................................................................7
........................................................................................7
.........................................................................................7
5.
Э
6. Ба
7.
Зависящие от сервиса требования ....................................................................................................................................................... ........7
7.1. Связность ........................................................................................................................................................................... ..... .. ............ 7
7.2. Синхронизация ......................................................................................................................................................................... ....... ....8
7.3. Устойчивость к ошибкам ........................................................................................................................................... ........................ 8
7.3.1. Потеря пакетов .......................................................................................................................................................................... 8.
7.3.2. Нарушение порядка доставки ............................................................................................................................................... ..8..
7.4. Сигнализация CE ..................................................................................................................................................... ..... .. ...................... 8
7.5. Использование полосы PSN .......................................................................................................................................... .................... 8
7.6. Вариации задержки пакетов ..................................................................................................................................... .. ......................... 9
7.7. Совместмость с инфраструктурой сетей пакетной коммутации (PSN) .................................................................................... .....9
7.8. Контроль насыщения ..................................................................................................................................................................... ....9.
7.9. Детектирование отказов ................................................................................................................................................................ ....9. .
7.10. Мониторинг работы ..................................................................................................................................................................... ....9.
8. Вопросы безопасности ........................................................................................................................................................ ....... .................... 9
9. Литература ............................................................................................................................................................................................... ....9..
9.1. Нормативные документы .............................................................................................................................................................. .......9. .
9.2. Информационные ресурсы ................................................................................................................................................ ................ 9
10. Разработчики документа ............................................................................................................................................................... .......... 10
1Time Division Multiplexed – мультиплексирование с разделением во времени.
2Plesiochronous Digital Hierarchy – плезиохронная цифровая иерархия.
3Synchronous Optical NETwork – цифровая оптическая сеть (используется в основном на американском континенте), Synchronous
Digital Hierarchy – синхронная цифровая иерархия (используется в основном в Европе). Прим. перев.
4Pseudo Wire Emulation Edge-to-Edge – эмуляция прямых соединений.
rfc.com.ru                                                                                                                                                   rfc.com.ru
Перевод RFC 4197
1. Введение
В этом документе рассматриваются требования для сквозной эмуляции каналов передачи цифровых сигналов TDM (PDH и SONET/SDH) через сети с коммутацией пакетов (PSN5). Эти требования основаны на архитектуре эмуляции прямых соединений 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 восьмибитовых выборок в секунду) в последовательность временных интервалов6, занимающих одинаковые позиции в каждом кадре. Такое мультиплексирование называют "channelized TDM7" и оно вносит в поток дополнительную структуру.
В некоторых случаях кадрирование также определяет группы последовательных кадров, которые называют мультикадрами8. Такая группировка создает дополнительный уровень структурирования битовых потоков 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, создаваемой цифровыми кросс-коннекторами, используемыми как NSP9; этот случай описан в документе [TR-NWT-170]).
1.2. Устройства SONET/SDH
Термин SONET обозначает используемые в Северной Америке синхронные оптические сети, описанные в документе [T1.105]. Работа таких сетей основана на концепции передачи блоков Nx783 байтов10 с периодом 125 мксек. Такие блоки информации называют STS-1 SPE11 и они могут объединяться для повышения эффективности использования полосы (например, STS-N) или делиться на более мелкие блоки (Virtual Tributary12). Объединенные блоки13 могут использоваться для передачи любого трафика от пакетов IP до ячеек ATM и сигналов DVS14. Отдельные блоки STS-1 SPE зачастую используются для передачи индивидуальных каналов TDM (DS3 или E3). Когда 783-байтовые контейнеры делятся на части, они обычно используются для передачи отдельных потоков TDM T1 или E1.
SDH представляет собой международный аналог и расширение SONET, описанное в [G.707].
Как SONET, так и SDH добавляют достаточно большой объем служебной информации (transport overhead), используемой для мониторинга, детектирования отказов и других функций обслуживания на различных типах оптических и электрических соединений. В дополнение к этому информационные блоки (payload area) также включают служебную информацию для сквозного
5Packet-Switched Networks
6Imeslot – тайм-слот, временной интервал.
7Канализированный поток TDM.
8multiframe
9Native Service Processing
10payload container
11synchronous payload envelope
12Виртуальный поток
13concatenated circuits
14Digital Video Signals – цифровой поток видео-информации.
rfc.com.ru                                                                                     2                                                            rfc.com.ru
Перевод RFC 4197                                                                                               
мониторинга, детектирования отказов и обслуживания. Если блоки данных делятся на узкополосные каналы (например, T1/E1), добавляется служебная информация для сквозного мониторинга отдельных каналов T1/E1.
В этом документе обсуждаются требования для случаев эмуляции сервиса SONET/SDH. Такие службы включают сквозную эмуляцию информационных блоков SONET (STS-1 SPE), эмуляцию объединенных блоков (STS-N SPE), а также эмуляцию дробных каналов (sub-STS-1). Дробные каналы, равно как их аналоги для случая SDH, обозначаются термином VT15).
2. Предпосылки
В [RFC3916] указаны общие требования к сквозной эмуляции устройств различных типов. Однако эти требования, равно как и требования [RFC3985], не учитывают специфику устройств TDM.
Необходимость создания документа, дополняющего требования [RFC3916] в части сквозной эмуляции устройств TDM, обусловлены множеством причин:
♦    Специфика устройств TDM; в частности:
♦    необходимость согласования синхронизации входящих и исходящих сигналов для каждого направления PW16;
♦    необходимость ограничения флуктуаций17 синхронизации на передающей стороне в пределах, задаваемых соответствующим нормативным документом, с учетом вариаций задержки пакетов в сети 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 используют сигнализацию CAS18 или CCS19 для управления и анонсирования состояния телефонных приложений, передачи сигналов таким приложениям и маршрутизации (адресации) соединений. Такие сигналы должны гарантированно передаваться через сети 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 эти характеристики будем обозначать термином PDV20 (см. [RFC3393]).
15Virtual Tributaries – виртуальные разветвления .
16Pseudo Wire – псевдо-соединение.
17В оригинале используются термины jitter (дрожь) и wander (отклонение). Прим. перев.
18Channel-Associated Signaling – поканальная сигнализация.
19Common Channel Signaling – сигнализация с общим сигнальным каналом.
20packet delay variation – вариации задержки пакетов.
rfc.com.ru                                                                          3                                                                        rfc.com.ru
Перевод RFC 4197
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 показан базовый вариант эталонной модели сетевой синхрониза­ции. Описание использованных на рисунке обозначений приведено ниже.
CE1, CE2
Пользовательские оконечные устрой­ства, завершающие эмулируемые соеди­нения TDM.
PE1, PE2
Краевые устройства сетевых операторов, адаптирующие сервис для PW.
S1, S2
Магистральные маршрутизаторы опера­торов.
Phy
Физический интерфейс, завершающий соединение TDM.
Enc
Интерфейс PW на границе PSN, где происходит инкапсуляция.
Dec
РЕ1
++
I Л v |
-+ I I I I
РЕ2
I Н| v |
G I v
С Е
1
+-+
|Р| <=|h|<:
lyl
+-+
+-+ ID|
|е|<: |с|
+-+
+-+
|Р| |h|<
lyl
+-+
+-+ |P|
+-+ +-+
IE| |P|
S2
:|h|<:|n|<=|h|<== lyl Ic| |y|
+-+ +-+ +-+
С E 2
SI
+-+ +-+ +-+
|P| ID| |P|
>|h|:>|e|=>|h|=
lyl Ic| |y|
+-+ +-+ +-+ I л I I I        I
++-E |
--------------+
л
I
D
+-+ +-+ +-+
|Р| |Е| |Р|
>|h|=>|n|:>|h|:
lyl |с| |у|
+-+ +-+ +-+
I А
I л IB |
++
I
l<-
I
+
--+
I
+-+
HI
+-+
->l I
+
I F
I С
Рисунок 1: Эталонная модель сетевой синхронизации
Связанный с 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
4
Перевод RFC 4197
Локальные генераторы синхросигналов, доступные PE1 и PE2, соответственно.
E
Синхронизация, используемая PE2 для передачи сигналов от устройства с TDM-подключением устройству CE2 (восстановленная синхронизация).
F
Синхронизация, восстановленная CE2 из входящего потока TDM (E и F имеют одинаковую частоту).
I
если этот сигнал существует, он является общим источником синхронизации для PE1 и PE2.
J
Синхронизация, используемая PE1 для передачи от устройства синхронизация).
K
с TDM-подключением устройству CE1 (восстановленная
Синхронизация, восстановленная CE1 из входящего потока TDM (J и K имеют одинаковую частоту).
L
Если этот сигнал существует, он является общим источником синхронизации для CE1 и CE2. Отметим, что различные пары устройств CE могут использовать разные опорные источники синхросигналов.
Требование сквозной эмуляции соединений TDM заключается в том, что сигналы B и E, а также H и J имели одинаковые частоты. Подходящий метод синхронизации будет определяться схемой сетевой синхронизации.
Ниже рассмотрены варианты сценариев синхронизации.
4.3.1. Сценарии с сетью синхронизации
В зависимости от того, какая часть сети
имеет общий источник синхронизации, +
возможны два варианта сценария:
+-----+
I /|<-
| | СЕ | I \-> I-
+-----+
|
РЕ1 |
.PW1. .PW2.
| РЕ2
+-----+
"I <-\ I
ICE2 || ->1 / I
+-----+
Сценарий синхронизации PE:
Рисунок 2 представляет собой адап­тированный вариант эталонной се­тевой модели и представляет сцена­рий PE-синхронизации.
Общий источник сигналов I досту­пен всем устройствам PE, а локаль­ные источники C и D привязаны к I:
Сигналы E и J совпадают с D и
I
+
+
I
+-+
HI
+-+
ID
-+
Рисунок 2: Сценарий синхронизации PE
Сигналы A и G совпадают с сигналами K и F, соответственно (т. е., устройства CE1 и CE2 используют шлейфовую синхронизацию).
Сценарий синхронизации CE:
+-----+
I         к-
I СЕ1 | I                 I —
+-----+
л
|А
+-----
I
-+ -1 =
= 1
I
+-----+
--I I | СЕ2 |
->1 I
+-----+
л
G|
-------+
На рисунке 3 показан адаптирован­ный вариант базовой модели сете­вой синхронизации для случая CE.
Общим опорным источником яв­ляется сигнал L, доступный всем устройствам CE, а локальные источ­ники A и G привязаны к L:
Сигналы E и J совпадают с G и A, соответственно (т. е., PE1 и PE2 используют шлейфовую синхронизацию).
Отметим, что в обоих случаях синхро­сигналы через сеть PSN не передаются.
РЕ1 |
.PW1. .PW2.
| РЕ2
I
+-+ |L| +-+
Рисунок 3: Сценарий синхронизации CE
4.3.2. Сценарий с синхронизацией через сеть PSN
В этом случае каждое устройство CE использует свой источник для синхронизации передачи и сигналы этого источника должны передаваться через сеть PSN и восстанавливаться соответствующим удаленным устройством PE. При восстановлении может использоваться общий для PE источник сигналов I.
На рисунке 4 показан сценарий синхронизации через сеть.
Общий источник синхросигналов I доступен всем устройствам PE, а локальные генераторы C и D привязаны к I:
♦    Сигналы A и G генерируются локально и не привязаны к общему источнику.
♦    Сигналы E и J генерируются в соответствии с общим источником синхронизации, доступным всем устройствам PE.
5
Перевод RFC 4197
В несколько отличающемся варианте этого сценария одно (но не оба) из устройств CE может использовать сигналы синхронизации приема в качестве источника синхронизации передачи (шлейфовая синхронизация).
В этом случае синхросигналы (различие между опорным сигналом I и входящей синхронизацией A) должны явно передаваться от устройства PE на входе21 устройству PE на выходе22.
4.3.3.                   Сценарий
адаптивной
синхронизации
Сценарий адаптивной синхронизации характеризуется 2 особенностями:
♦    отсутствует общий источник сигна­лов I, доступный устройствам PE1 и PE2.
♦    Отсутствует общий источник сигна­лов L, доступный устройствам CE1 и CE2.
На рисунке 5 показан сценарий адап­тивной синхронизации.
+-----+
I         к-
I СЕ1 | I                 I —
+-----+
л
|А
РЕ1 |
.PW1. .PW2.
| РЕ2
IG v
+-----+
-I                 I
| СЕ2 | ->1 I
+-----+
-+<-
+-
I
+ -+
HI
+ -+
->+-
Рисунок 4: Сценарий с синхронизацией через сеть PSN
+-----+
I         к-
I СЕ1 | I                 I —
+-----+
л
I
А|
и
v
IG I v
+-----+
-I                 I
| СЕ2 |
->1 I
+-----+
РЕ1 |
.PW1. .PW2.
| РЕ2
E|
Рисунок 5: Сценарий адаптивной синхронизации
Синхронизация сигналов A и E в этом
сценарии сложнее, нежели в других сценариях синхронизации.
Отметим, что разница между сигналами A и E должна быть достаточно малой, чтобы обеспечить отсутствие случаев переполнения или опустошения компенсационного буфера23.
В этом сценарии синхросигналы могут явно передаваться PE на входе устройству PE на выходе (например, с помощью RTP).
5. Эмулируемые службы
В этой главе определены требования к уровням информации (payload)24 и инкапсуляции для сквозной эмуляции сервиса 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.
21Ingress PE.
22Egress PE.
23jitter buffer overflow/underflow.
24Далее в переводе этот уровень будет для краткости называться информационным. Прим. перев.
rfc.com.ru                                                                                     6
Перевод RFC 4197
 
Отметим, что не существует независимого от структуры транспорта для SONET/SDH. Для этого типа структура должна приниматься во внимание всегда.
6. Базовые требования
6.1. Общие требования к PW
Уровни инкапсуляции и информации должны удовлетворять общим требованиям к PW, определенным в [RFC3916]:
1.    Доставка необходимой информации из заголовков:
A)  для структурно-независимого транспорта эти функции могут обеспечиваться информационным уровнем;
B)   для структурированного транспорта необходимая информация должна обеспечиваться уровнем инкапсуляции;
C)   структурированный транспорт для устройств SONET/SDH должен сохранять информацию о пути (path overhead) как часть передаваемых данных (payload); соответствующие компоненты транспортной служебной информации (transport overhead) могут передаваться на уровне инкапсуляции.
2.    Поддержка мультиплексирования и демультиплексирования, если таковые поддерживаются эмулируемыми устройствами. Это относится к соединениям NxDS0 (с сигнализацией или без нее) и NxVT-x в одном STS-1 SPE или VC-4:
A)  для таких соединений уровни информации и инкапсуляции должны совместно обеспечивать раздельную трактовку каждого суб-канала (sub-circuit);
B)  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-сервис25, но это не является обязательным.
6.3. Вопросы архитектуры
Уровни информации и инкапсуляции следует реализовать на основе единых архитектурных принципов, как описано в главе 3 [RFC1958] и [RFC3985].
При необходимости информационный уровень может использовать ту или иную фору адаптации естественных данных TDM для достижения хорошо документированных задач. В таких случаях следует использовать методы адаптации стандартов.
7. Зависящие от сервиса требования
7.1. Связность
1.    Эмуляция должна обеспечивать передачу сигналов между однотипными устройствами AC26 (см. главу 5), использующими (если это применимо) одинаковую скорость.
2.    Уровню инкапсуляции следует сохранять независимость от специфических характеристик соединения между устройствами AC и PE на разных сторонах PW.
7.2. Синхронизация
1.    Уровень инкапсуляции должен обеспечивать сервис синхронизации, достаточный для того, чтобы:
A)  согласовать входящую и исходящую синхронизацию независимо от используемого сценария сетевой синхронизации;
B)  сохранять флуктуации (jitter и wander) исходящей синхронизации в определяемых типом сервиса пределах, заданных соответствующими нормативными документами.
2.    При доступности одного прецизионного источника синхронизации для всех устройств PE в данном домене, уровню инкапсуляции следует обеспечивать возможность использования этого источника (например, для более точного восстановления синхронизации естественного сервиса).
7.3. Устойчивость к ошибкам
Устойчивость эмулируемого сервиса к ошибкам зависит не только от протокола сквозной эмуляции, но и от корректной
25Размер пользовательских данных
26Attachment Circuit – соединительное устройство, устройство подключения.
rfc.com.ru                                                                          7                                                                        rfc.com.ru
Перевод RFC 4197
реализации перечисленных ниже процедур.
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.   Уровню инкапсуляции следует обеспечивать возможность эффективного согласования перечисленных ниже противоречивых требований:
A)  Эффективное использование полосы PSN. Предполагается, что размер заголовков уровня инкапсуляции не зависит от размера пакетов и увеличение размера передаваемых пакетов повышает эффективность использования полосы.
B)  Незначительная сквозная задержка. Малые значения задержки являются основным требованием для голосовых приложений TDM. Задержка на пакетирование является одной из компонент общей задержки и растет при увеличении размера пакетов.
Компенсационный буфер увеличивает задержку для эмулируемого соединения. Не следует дозволять, чтобы дополнительная задержка, вносимая компенсационным буфером, превышала значение вариации задержки пакетов в сети PSN.
2.   Уровень инкапсуляции может обеспечивать экономию полосы PSN за счет отказа от передачи поврежденных данных TDM через сеть PSN.
3.   Уровень инкапсуляции может обеспечивать возможность экономии полосы PSN для случая структурированного транспорта за счет отказа от передачи неактивных каналов.
4.   Уровень инкапсуляции может обеспечивать динамическое отключение временно бездействующих каналов в случае использования структурированного транспорта.
Если динамическое исключение каналов используется, по умолчанию недопустимо нарушение целостности структур, передаваемых через PW.
5.   Для NxDS0 уровень инкапсуляции должен обеспечивать возможность сохранять сквозную задержку независимо от скорости.
7.6. Вариации задержки пакетов
Уровню инкапсуляции следует обеспечивать возможность компенсации вариаций задержки пакетов пока флуктуации синхронизации на передающей стороне не выходят за нормативные пределы.
Уровень инкапсуляции может обеспечивать в процессе работы адаптацию задержки, вносимой компенсационным буфером, если вариации задержки пакетов изменяются с течением времени. Такая адаптация может вносить дополнительные ошибки (в
8
Перевод RFC 4197
допустимых нормативами пределах), но не следует позволять увеличение флуктуаций 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 следует обеспечивать сбор данных мониторинга работы (PM27), совместимых с параметрами, определенными для “классических” служб на базе 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 211928, 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.
27performance monitoring
28Перевод этого документа на русский язык имеется на сайте rfc.com.ru.
rfc.com.ru                                                                          9                                                                        rfc.com.ru
Перевод RFC 4197
[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.
Ron Cohen
Lycium Networks
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
Полное заявление авторских прав
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Интеллектуальная собственность
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
Перевод на русский язык
Николай Малых (nmalykh@bilim.com)
rfc.com.ru                                                                                   10                                                           rfc.com.ru