RFC 4234 Augmented BNF for Syntax Specifications: ABNF

Network Working Group                                D. Crocker, Ed.
Request for Comments: 4234               Brandenburg InternetWorking
Obsoletes: 2234                                           P. Overell
Category: Standards Track                                  THUS plc.
                                                        October 2005

Расширенная спецификация синтаксиса Бэкуса-Наура (ABNF)

Augmented BNF for Syntax Specifications: ABNF

PDF

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

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа «Internet Official Protocol Standards» (STD 1)1. Документ может распространяться без ограничений.

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

Copyright (C) The Internet Society (2005).

Тезисы

Технические спецификации Internet зачастую требуют использования формального синтаксиса. За долгие годы модифицированная версия формы Бэкуса-Наура (BNF2), названная (ABNF3) приобрела популярность во множестве спецификаций Internet. В данном документе содержится спецификация ABNF. Эта форма сочетает компактность и простоту с достаточно мощными средствами представления. Различия между стандартной формой BNF и ABNF включают правила именования, повторения, варианты, независимость от порядка (order-independence) и диапазоны значений. Данная спецификация также включает дополнительные определения правил и кодирования для основы лексического анализатора типов, используемого в нескольких спецификациях Internet.

Оглавление

Исключено из версии HTML

1. Введение

В технических спецификациях Internet часто требуется определять формальный синтаксис и можно выбирать ту или иную нотацию, которую авторы считают полезной. За долгие годы модифицированная версия формы Бэкуса-Наура (BNF), названная (ABNF) приобрела популярность во множестве спецификаций Internet. Эта форма сочетает компактность и простоту с достаточно мощными средствами представления. В раннюю эпоху Arpanet каждая спецификация использовала свое определение ABNF. К таким определениям относится спецификация электронной почты [RFC733] и более поздний документ [RFC822], которые стали основой для последующих определений ABNF. Текущий документ разделяет эти определения для того, чтобы можно было независимо ссылаться на них. Кроме того в этом документе внесены некоторые изменения и усовершенствования.

Различия между стандартной формой BNF и ABNF включают правила именования, повторения, варианты, независимость от порядка (order-independence) и диапазоны значений. В Приложении B даются определения правил и кодирования для основы лексического анализатора типа, используемого в нескольких спецификациях Internet. Они приводятся для удобства и отделения от метаязыка, определенного в основной части данного документа, и его формального статуса.

Отличия от [RFC2234]:

В параграфе 3.7 фраза : «Т. е., в точности <N> включений <element>» была заменена фразой: «Т. е., в точности <n> включений <element>.»

В некоторые продолжающиеся строки комментариев включены символы «;» в начале строк.

2. Определения правил

2.1 Именование правил

Имя правила является лишь именем как таковым, т. е., последовательностью символов, начинающейся с буквы4 или цифры, за которой следует комбинация букв, цифр и знаков дефиса (-).

Примечание: строчные и прописные буквы в именах правил не различаются.

Имена <rulename>, <Rulename>, <RULENAME> <rUlENamE> указывают на одно правило.

В отличие от исходной формы BNF угловые скобки (< и >) не являются обязательными. Однако в такие скобки могут заключаться имена правил, когда нужно подчеркнуть использование имени правила. Это обычно относится к именам правил, указанным в свободной форме, или для выделения имен правил включенных в строку без разделения символами пробела, как показано ниже при обсуждении повторов.

2.2. Форма правил

Правила определяются следующим способом:

name = elements crlf

где <name> — имя правила, <elements> — одно или множество имен правила или терминальных спецификаций, а <crlf> — индикатор завершения строки (возврат каретки с последующим переводом строки). Знак равенства отделяет имя от определения правила. Элементы формируют последовательность из одного или множества имен правил и/или определений значений, объединенных с помощью различных операторов, определяемых в данном документе, таких, как повторы или варианты.

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

2.3. Терминальные значения

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

Терминалы задаются одной или множеством цифр с явно заданным основанием. В настоящее время определены следующие варианты оснований чисел:

b = binary (двоичное)
d = decimal (десятичное)
x = hexadecimal (шестнадцатеричное)

Следовательно, записи:

CR = %d13
CR = %x0D

задают, соответственно, десятичное и шестнадцатеричное представление символа возврата каретки [US-ASCII].

Связанные (concatenated) строки таких значений задаются в компактной форме с использованием символа точки (.) в качестве разделителя. Следовательно,

CRLF = %d13.10

ABNF разрешает указывать текстовые строки непосредственно, помещая текст в двойные кавычки.

command = "command string"

Текстовые строки интерпретируются как связанное множество печатных символов.

Примечание: регистр букв текстовых строках ABNF не принимается во внимание, а в качестве набора символов используется us-ascii.

Следовательно,

rulename = "abc"

и

rulename = "aBc"

будут соответствовать «abc», «Abc», «aBc», «abC», «ABc», «aBC», «AbC» и «ABC».

Для задания правила, в котором регистр символов принимается во внимание, символы следует задавать по-отдельности.

Например,

rulename = %d97 %d98 %d99

или

rulename = %d97.98.99

будут соответствовать только строкам, содержащим лишь строчные буквы abc.

2.4. Внешнее кодирование

Внешнее представление символов терминальных значений будет меняться в соответствии с условиями среды хранения и передачи. Следовательно, одна и та же грамматическая конструкция ABNF может иметь различное внешнее кодирование (например, одно представление для 7-битовой среды US-ASCII, другое для двоичной среды на базе октетов, третье для 16-битовой среды Unicode). Детали кодирования выходят за пределы ABNF, хотя в Приложении В5 приводятся определения для 7-битовой среды US-ASCII, как наиболее распространенной в Internet.

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

3. Операторы

3.1. Конкатенация: Rule1 Rule2

Правило может определять простую, упорядоченную строку значений (например, слияние последовательных символов) путем перечисления последовательности имен правил. Например,

foo = %x61 ; a
bar = %x62 ; b
mumble = foo bar foo

В результате правило <mumble> будет соответствовать строке строчных букв «aba».

Пробельные символы: Конкатенация является основой модели разбора ABNF. Строка непрерывных символов (значений) разбирается согласно правилам, определенным в ABNF. Для спецификаций Internet в силу исторических причин допускается свободное «рассеяние» символов пробела и горизонтальной табуляции вокруг основных конструкций (таких, как специальные разделители или строки-атомы).

Примечание:

В данной спецификации ABNF не предполагается неявно такого «рассеяния» пробельных символов.

Любая грамматическая конструкция, которая разрешает «рассеяние» пробельных символов вокруг разделителей и сегментов строк, должна указывать это явно. Зачастую бывает полезно обеспечить пустое пространство в основных правилах, которые используются среди правил вышележащих уровней. «Основные» правила могут формироваться в лексический анализатор или просто быть частью главного набора правил.

3.2. Варианты: Rule1 / Rule2

Элементы, разделенные символом дробной черты (/), задают варианты. Следовательно,

foo / bar

будет принимать значение <foo> или <bar>.

Примечание:

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

3.3. Дополнительные варианты: Rule1 =/ Rule2

Иногда удобно задавать список вариантов в виде фрагментов, т. е., начальному правилу соответствует один или множество вариантов, а последующие определения правил добавляют набор вариантов. Это особенно полезно для создания иной независимой спецификации, которая является производной от того же родительского набора правил, как это часто бывает со списками параметров. ABNF поддерживает такие дополнения с помощью конструкции:

oldrule =/ дополнительные-варианты

Таким образом, набор правил

ruleset = alt1 / alt2
ruleset =/ alt3
ruleset =/ alt4 / alt5

представляет собой то же самое, что

ruleset = alt1 / alt2 / alt3 / alt4 / alt5

3.4. Диапазоны вариантов: %c##-##

Диапазон вариантов цифровых значений может быть представлен в компактной форме с использованием символа дефиса (-) для индикации диапазона вариантов. Следовательно,

DIGIT = %x30-39

является эквивалентом:

DIGIT = «0» / «1» / «2» / «3» / «4» / «5» / «6» / «7» / «8» / «9»

Конкатенация цифровых значений и диапазон цифровых значений не могут быть заданы в одной строке. Цифровое значение может использовать нотацию с точками для конкатенации или нотацию с дефисом для задания одного диапазона значений. Следовательно, для задания одного печатного символа между последовательностями завершения строк, можно указать:

char-line = %x0D.0A %x20-7E %x0D.0A

3.5. Упорядоченная группа: (Rule1 Rule2)

Элементы, заключенные в круглые скобки, трактуются как один элемент со строгим упорядочением. Таким образом,

elem (foo / bar) blat

соответствует (elem foo blat) или (elem bar blat), а

elem foo / bar blat

соответствует (elem foo) или (bar blat).

Примечание:

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

Следовательно, рекомендуется использовать приведенную ниже форму:

(elem foo) / (bar blat)

Это позволит предотвратить ошибочную интерпретацию при невнимательном чтении.

Упорядоченные группы используются также внутри свободного текста для выделения порядка слов в тексте.

3.6. Переменное число повторов: *Rule

Оператор *, предшествующий элементу, указывает на повторение. Полная форма имеет вид:

<a>*<b>element

где <a> и <b> — необязательные десятичные значения, показывающие минимальное (<a>) и максимальное (<b>) число повторов элемента.

По умолчанию для верхнего и нижнего порога используются значения 0 и “бесконечность”, поэтому *<element> позволяет любое число элементов (включая 0), 1*<element> требует по крайней мере один элемент, 3*3<element> разрешает в точности три повтора, а 1*2<element> разрешает 1 или 2 повтора.

3.7. Заданное число повторов: nRule

Правило вида:

<n>element

эквивалентно правилу

<n>*<n>element

Т. е., допускается в точности <n> включений <element>. Таким образом 2DIGIT представляет собой двухзначное число, а 3ALPHA – строку из трех букв.

3.8. Необязательная последовательность: [RULE]

В квадратных скобках указывается необязательная последовательность элементов.

[foo bar]

эквивалентно

*1(foo bar).

3.9. Комментарий: ; Comment

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

3.10. Старшинство операторов

Описанные выше операторы имеют разный уровень старшинства (порядок применения). Далее операторы перечислены в соответствии со старшинством – сначала указаны операторы с высшим приоритетом, а последним указан оператор с низшим уровнем старшинства:

Строки, имена (Strings, Names formation)

Комментарий (Comment)

Диапазон значений (Value range)

Повтор (Repetition)

Группировка, необязательные последовательности (Grouping, Optional)

Конкатенация (Concatenation)

Варианты (Alternative)

Использование вариантов, произвольно перемешанных с операторами конкатенации, может привести к путанице.

Снова рекомендуется использовать оператор группировки для явного указания сливаемых воедино групп.

4. ABNF-определение для ABNF

Примечания:

  1. Этот синтаксис требует сравнительно строгого форматирования правил. Следовательно, включенный в спецификацию вариант набора правил может потребовать предварительной обработки для того, чтобы он мог быть обработан анализатором ABNF .

  2. Синтаксис использует правила, приведенные в Приложении B (Основы ABNF для ABNF).

         rulelist       =  1*( rule / (*c-wsp c-nl) )
         rule           =  rulename defined-as elements c-nl
                                ; продолжение, если следующая строка начинается с пробела
         rulename       =  ALPHA *(ALPHA / DIGIT / "-")
         defined-as     =  *c-wsp ("=" / "=/") *c-wsp
                                ; определение базовых правил и дополнительных вариантов
         elements       =  alternation *c-wsp
         c-wsp          =  WSP / (c-nl WSP)
         c-nl           =  comment / CRLF
                                ; комментарий или новая строка
         comment        =  ";" *(WSP / VCHAR) CRLF
         alternation    =  concatenation *(*c-wsp "/" *c-wsp concatenation)
         concatenation  =  repetition *(1*c-wsp repetition)
         repetition     =  [repeat] element
         repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)
         element        =  rulename / group / option / char-val / num-val / prose-val
         group          =  "(" *c-wsp alternation *c-wsp ")"
         option         =  "[" *c-wsp alternation *c-wsp "]"
         char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                                ; заключенная в кавычки строка SP и VCHAR без DQUOTE
         num-val        =  "%" (bin-val / dec-val / hex-val)
         bin-val        =  "b" 1*BIT [ 1*("." 1*BIT) / ("-" 1*BIT) ]
                                ; последовательность объединенных битовых 
                                ; значений или один диапазон ONEOF
         dec-val        =  "d" 1*DIGIT [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
         hex-val        =  "x" 1*HEXDIG [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
         prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
                                ; заключенная в угловые скобки последовательность SP и VCHAR
                                ; за исключением правых угловых скобок будет использоваться
                                ; как последний шанс

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

Искренне надеемся, что вопросы безопасности не имеют отношения к этому документу.

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

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

[US-ASCII] American National Standards Institute, «Coded Character Set — 7-bit American Standard Code for Information Interchange», ANSI X3.4, 1986.

6.2. Дополнительная литература

[RFC2234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.

[RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, «Standard for the format of ARPA network text messages», RFC 733, November 1977.

[RFC822] Crocker, D., «Standard for the format of ARPA Internet text messages», STD 11, RFC 8227, August 1982.

Приложение A. Благодарности

Изначальная спецификация синтаксиса ABNF была приведена в RFC 733. Ken L. Harrenstien из SRI International выполнил работу по кодированию для расширенного BNF, позволившему сделать представление более компактным и ясным.

Этот недавний проект начался как простая работа по выделению части документа RFC 822, который неоднократно использовался в спецификациях, не связанных с электронной почтой, и являлся описанием расширенного варианта BNF. Вместо простого копирования имеющегося текста в отдельный документ, рабочая группа предпочла внимательное рассмотрение преимуществ и недостатков существующей спецификации и других спецификаций, выпущенных за последние 15 лет. Это сделало проект более амбициозным, нежели предполагалось в начале. Интересно отметить, что полученный результат не слишком значительно отличается от оригинала, хотя некоторые решения (типа удаления списков — list notation) стали сюрпризом.

Эта «отдельная» версия спецификации была частью работы группы DRUMS, значительный вклад в которую внесли Jerome Abela, Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete Resnick и Henning Schulzrinne.

Julian Reschke заслуживает отдельной благодарности за преобразование чернового варианта в формат XML.

Приложение B. Основы ABNF для ABNF

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

B.1. Базовые правила

Для некоторых базовых правил (таких, как SP, HTAB, CRLF, DIGIT, ALPHA и т. п.) используются заглавные буквы.

         ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z
         BIT            =  "0" / "1"
         CHAR           =  %x01-7F
                                ; любой 7-битовый символ US-ASCII, за исключением NUL
         CR             =  %x0D
                                ; возврат каретки

         CRLF           =  CR LF
                                ; стандартная в Internet последовательность для новой строки
         CTL            =  %x00-1F / %x7F
                                ; коды управления
         DIGIT          =  %x30-39
                                ; цифры 0-9
         DQUOTE         =  %x22
                                ; " (двойные кавычки)
         HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
         HTAB           =  %x09
                                ; символ горизонтальной табуляции
         LF             =  %x0A
                                ; перевод строки
         LWSP           =  *(WSP / CRLF WSP)
                                ; linear white space (после новой строки)
         OCTET          =  %x00-FF
                                ; 8 битов данных
         SP             =  %x20
         VCHAR          =  %x21-7E
                                ; видимые (печатные) символы
         WSP            =  SP / HTAB
                                ; пробельные символы

 

B.2. Общие правила кодирования

Для внешнего представления данных используется 7-битовая кодировка US-ASCII с нулевым значением старшего бита. Строки значений используют «сетевой порядок байтов», при котором старший (наиболее значимый байт) указывается слева и передается через сеть первым.

Адреса авторов

Dave Crocker (редактор)

Brandenburg InternetWorking

675 Spruce Dr.

Sunnyvale, CA 94086

US

Phone: +1.408.246.8253

EMail: dcrocker@bbiw.net

Paul Overell

THUS plc.

1/2 Berkeley Square

99 Berkeley Street

Glasgow

G3 7HR

UK

EMail: paul.overell@thus.net


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

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

nmalykh@protocols.ru

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

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.

1Этот документ признан устаревшим и земенен RFC 5234, перевод которого имеется на сайте www.protocols.ru. Прим. перев.

2Backus-Naur Form

3Augmented BNF – расширенная форма Бэкуса-Наура. Прим. перев.

4Здесь и далее в тексте документа термин “буква” означает буквы латинского алфавита. Прим. перев.

5В оригинале ошибочно указано Приложение A. Прим. перев.

7Этот документ признан устаревшим и заменен RFC 2822, а тот, в свою очередь, — RFC 5322, перевод которого имеется на сайте www.protocols.ru. Прим. перев.




RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers

Network Working Group                                    E. Nordmark
Request for Comments: 4213                    Sun Microsystems, Inc.
Obsoletes: 2893                                          R. Gilligan
Category: Standards Track                             Intransa, Inc.
                                                        October 2005

 

Базовые механизмы перехода для хостов и маршрутизаторов IPv6

Basic Transition Mechanisms for IPv6 Hosts and Routers

PDF

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

Этот документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования предложенного протокола. Информацию о текущем статусе протокола и состоянии стандартизации можно найти в документе Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.

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

Copyright (C) The Internet Society (2005).

Тезисы

Этот документ задает механизмы совместимости с IPv4, которые могут быть развернуты на хостах и маршрутизаторах IPv6. Приведены спецификации двух механизмов — двойной стек и настраиваемое туннелирование. Механизм с двойным стеком протоколов предполагает полную реализацию обеих версий протокола IP (IPv4 b IPv6), а механизм настраиваемого туннелирования позволяет передавать пакеты IPv6 через инфраструктуру маршрутизации IPv4 без ее изменения.

Этот документ служит заменой RFC 2893.

Оглавление

Исключено из версии HTML

1. Введение

Ключевым элементом успешного перехода на IPv6 является совместимость с большой базой установленных хостов и маршрутизаторов IPv4. Обеспечение совместимости с IPv4 при развертывании IPv6 упростит задачу перевода сети Internet на протокол IPv6. В этой спецификации определены два механизма, которые могут быть реализованы на хостах и маршрутизаторах IPv6 для обеспечения совместимости с хостами и маршрутизаторами IPv4.

Описанные в документе механизмы разработаны для развертывания на хостах и маршрутизаторах IPv6, которым требуется интероперабельность с хостами IPv4 и возможность использования инфраструктуры маршрутизации IPv4. Предполагается, что такая совместимость потребуется для большинства узлов Internet в течение длительного (возможно, неопределенного) срока.

Предлагаемые здесь механизмы включают:

  • Dual IP (двойной стек IP) — метод обеспечения полной поддержки обеих версий протокола IP (IPv4 и IPv6) на хостах и маршрутизаторах.
  • Настраиваемое туннелирование IPv6 через IPv4 — метод организации туннелей «точка-точка» за счет инкапсуляции пакетов IPv6 с заголовками IPv4 для передачи через маршрутную инфраструктуру IPv4.

Механизмы, определенные здесь, предназначены на роль основных инструментов перехода — расширяемого набора методов, которые разработчики и пользователи могут применять для упрощения перехода на новую версию протокола. Использование конкретных инструментов определяется реальными потребностями. Разработчики и сайты самостоятельно принимают решения о выборе конкретных методов решения своих задач.

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

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

Ниже определены основные термины, используемые в этом документе.

Типы узлов

IPv4-only node (только IPv4)

Хост или маршрутизатор, на котором развернут только протокол IPv4. Такие узлы не понимают протокол IPv6. Установленная база хостов и маршрутизаторов IPv4, существовавших до начала перехода относится к этому типу узлов.

IPv6/IPv4 node (IPv6 и IPv4)

Хосты и маршрутизаторы, поддерживающие протоколы IPv4 b IPv6.

IPv6-only node (только IPv6)

Хост или маршрутизатор, который поддерживает IPv6, но не поддерживает IPv4. Работа узлов этого типа в данном документе не рассматривается.

IPv6 node (узел IPv6)

Любой хост или маршрутизатор, поддерживающий IPv6. Узлы типа IPv6/IPv4 и IPv6-only относятся к узлам IPv6.

IPv4 node (узел IPv4)

Любой хост или маршрутизатор, поддерживающий IPv4. Узлы типа IPv6/IPv4 и IPv4-only относятся к узлам IPv4.

Методы, используемые при переходе

IPv6-over-IPv4 tunneling (туннелирование IPv6 через IPv4)

Метод инкапсуляции пакетов IPv6 в пакеты IPv4, которые могут передаваться через инфраструктуру маршрутизации IPv4.

Configured tunneling (настраиваемое туннелирование)

Туннелирование IPv6-over-IPv4 при котором адреса IPv4 конечных точек туннеля определяются конфигурационными параметрами этих точек. Все туннели предполагаются двухсторонними. Туннель обеспечивает (виртуальный) канал «точка-точка» для уровня IPv6 с использованием заданных в конфигурации адресов IPv4 в качестве адресов конечных точек нижележащего уровня.

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

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

2. Работа Dual IP

Наиболее простым способом обеспечения совместимости узлов IPv6 с узлами, поддерживающими только IPv4, является полная реализация протокола IPv4. Узлы, полностью поддерживающие оба протокола IPv4 и IPv6, называют узлами IPv6/IPv4. Такие узлы способными передавать и принимать как пакеты IPv4, так и пакеты IPv6. Они могут напрямую взаимодействовать с узлами IPv4, используя пакеты IPv4, и с узлами IPv6, используя пакеты IPv6.

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

  • стек IPv4 включен, а IPv6 отключен;
  • стек IPv6 включен, а IPv4 отключен;
  • оба стека протоколов включены.

Узлы IPv6/IPv4 с отключенным стеком IPv6 будут работать, как узлы IPv4-only. Аналогично, узлы IPv6/IPv4 с отключенным стеком IPv4 будут работать, как IPv6-only. Узлы IPv6/IPv4 могут поддерживать конфигурационные параметры для включения и отключения их стеков IPv4 или IPv6.

Метод настраиваемого туннелирования, описанный в разделе 3, может использоваться в дополнение к методу Dual IP.

2.1. Настройка адресов

Поскольку узлы IPv6/IPv4 поддерживают обе версии протокола, для них в конфигурации могут задаваться адреса как IPv4, так и IPv6. Узлы IPv6/IPv4 используют механизмы IPv4 (например, DHCP) для получения адресов IPv4 и механизмы IPv6 (например, автоматическая настройка конфигурации [RFC2462] и/или DHCPv6) для получения адресов IPv6.

2.2. DNS

Система доменных имен (DNS1) используется как в IPv4, так и в IPv6 для отображения имен хостов на адреса IP и обратно. Для адресов IPv6 в документе [RFC3596] определен новый тип записей о ресурсах — AAAA. Поскольку узлы IPv6/IPv4 должны обеспечивать интероперабельность с узлами Ipv4и IPv6, они должны поддерживать библиотеки преобразования, способные работать как с записями IPv4 типа A, так и с записями IPv6 типа AAAA. Отметим, что поиск записей A и AAAA не зависит от протокола, используемого для передачи пакетов DNS (IPv4 или IPv6), поэтому не делается допущения о том, что серверы DNS знают о возможностях поддержки IPv4/IPv6 на запрашивающих узлах.

Вопросы использования IPv6 с DNS и рабочие рекомендации более подробно рассмотрены в других документах (например, [DNSOPV6]).

Библиотеки преобразования DNS (resolver) на узлах IPv6/IPv4 должны поддерживать обработку записей обоих типов AAAA и A. Однако, если запросы возвращают записи AAAA с адресом IPv6 и записи A с адресом IPv4, библиотека преобразования может упорядочивать возвращаемые приложению результаты с учетом версии пакетов IP, используемых в коммуникациях с конкретным узлом — сначала IPv6 или сначала IPv4.

Приложениям следует поддерживать возможность задания желаемых типов записей (IPv4, IPv6 или оба типа [RFC3493]). Это определяет, какие семейства адресов преобразователь будет искать. Если приложение не указывает своего выбора или запрашивает оба типа, для библиотек преобразования недопустима фильтрация записей.

Поскольку большинство приложений пытаются использовать адреса в порядке, возвращаемом преобразователем, это может оказывать влияние на выбор версии IP «предпочитаемой» приложением.

Реальные механизмы упорядочения выходят за пределы этого документа. Более подробно выбор адресов рассмотрен в [RFC3484].

3. Механизмы настраиваемого туннелирования

В большинстве вариантов развертывания инфраструктура маршрутизации IPv6 будет строиться достаточно долго. Пока будет создаваться инфраструктура IPv6, существующая инфраструктура маршрутизации IPv4 будет продолжать функционирование и может использоваться для передачи трафика IPv6. Туннелирование обеспечивает возможность использования существующей инфраструктуры маршрутизации IPv4 для доставки трафика IPv6.

Хосты и маршрутизаторы IPv6/IPv4 могут туннелировать дейтаграммы IPv6 через области маршрутной топологии IPv4 за счет их инкапсуляции в пакеты IPv4. Туннелирование можно организовать множеством способов:

  • Router-to-Router. Маршрутизаторы IPv6/IPv4, соединенные через инфраструктуру IPv4, могут туннелировать между собой пакеты IPv6. В этом случае туннель представляет собой один сегмент сквозного пути пакетов IPv6.
  • Host-to-Router. Хосты IPv6/IPv4 могут туннелировать пакеты IPv6 на промежуточные маршрутизаторы IPv6/IPv4, доступные через инфраструктуру IPv4. Этот тип туннеля представляет собой первый сегмент сквозного пути доставки пакетов.
  • Host-to-Host. Хосты IPv6/IPv4, связанные через инфраструктуру IPv4 могут туннелировать пакеты IPv6 между собой. В этом случае туннель будет представлять собой весь сквозной путь доставки пакетов.
  • Router-to-Host. Маршрутизаторы IPv6/IPv4 могут туннелировать пакеты IPv6 конечным получателям IPv6/IPv4. В этом случае туннель представляет собой последний сегмент сквозного пути доставки пакетов.

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

Основными элементами туннелирования являются:

  • входной узел туннеля (инкапсулятор), создающий заголовок инкапсуляции IPv4 и передающий инкапсулированный пакет;
  • выходной узел туннеля (декапсулятор), принимающий инкапсулированный пакет, выполняющий при необходимости сборку фрагментов, удаляющий заголовок IPv4 и обрабатывающий принятый пакет IPv6;
  • инкапсулятору может потребоваться поддержка информации о состоянии для каждого туннеля, включающей такие данные, как MTU для туннеля, чтобы соответствующим образом обрабатывать пакеты IPv6, пересылаемые в туннель.

При настраиваем туннелировании адреса конечных точек туннеля определяются на инкапсуляторе из конфигурационных параметров, хранящихся для каждого туннеля. Когда пакеты IPv6 передаются через туннель, адреса отправителя и получателя в инкапсулирующем заголовке IPv4 задаются в соответствии с параграфом 3.5.

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

Декапсулятор проверяет соответствие пакетов с номером протокола 41 настроенным на нем туннелям и принимает только пакеты, в которых адрес отправителя IPv4 соответствует настроенному на декапсуляторе туннелю. Следовательно, оператор должен гарантировать, что конфигурация адресов IPv4 для туннелей совпадает на стороне инкапсулятора и декапсулятора.

3.1. Инкапсуляция

Инкапсуляция дейтаграмм IPv6 в пакеты IPv4 показана на рисунке.

Инкапсуляция IPv6 в IPv4.

Кроме добавления заголовка IPv4 инкапсулятор решает некоторые более сложные вопросы:

  • определяет необходимость фрагментирования и передачи сообщений ICMPv6 packet too big2 отправителям пакетов;
  • способ передачи сообщений ICMPv4 от маршрутизаторов вдоль туннеля отправителю исходных пакетов, как сообщений ICMPv6.

Эти вопросы рассмотрены в последующих параграфах.

3.2. MTU для туннеля и фрагментация

В примитивном варианте инкапсулятор может рассматривать процесс инкапсуляции, как IPv6, использующий протокол IPv4 в качестве канального уровня с очень большим значением MTU (до 65535-20 байтов; 20 байтов расходуются на инкапсулирующий заголовок IPv4). Инкапсулятору нужно лишь передавать сообщения ICMPv6 packet too big отправителям пакетов, размер которых превышает это значение MTU. Однако такая схема не будет эффективной и не обеспечит интероперабельности по перечисленным ниже трем причинам. Следовательно, недопустимо использовать такую примитивную схему.

  1. Возникает избыточная фрагментация. Фрагментации на уровне IPv4 следует избегать, поскольку могут возникать проблемы с производительностью в результате потери блоков данных, размер которых меньше размера при повторе передачи [KM97].
  2. Любая фрагментация IPv4 внутри туннеля (между инкапсулятором и декапсулятором) будет приводить к сборке фрагментов в конечной точке туннеля. Для туннелей, завершающихся на маршрутизаторах, потребуется дополнительный расход памяти и других ресурсов на сборку фрагментов IPv4 в полный пакет IPv6 до его пересылки.
  3. У инкапсулятора может не быть возможности узнать о способности декапсулятора дефрагментировать такие пакеты IPv4 (см. параграф 3.6) и способности декапсулятора обрабатывать столь большие блоки IPv6 MRU3.

Следовательно, инкапсулятору недопустимо трактовать туннель, как интерфейс с MTU = 64 кбайт, а взамен этого следует использовать статически заданное фиксированное значение MTU или необязательный механизм динамического определения MTU на основе MTU на пути IPv4 к конечной точке туннеля.

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

3.2.1. Статическое значение MTU для туннеля

Узел, использующий статическое значение MTU для туннеля, трактует туннельный интерфейс, как интерфейс с фиксированным MTU. По умолчанию значение MTU должно лежать в диапазоне от 1280 до 1480 байтов (включительно), но следует устанавливать значение 1280 байтов. Если используемое по умолчанию значение отличается от 1280, реализация должна иметь конфигурационный параметр, позволяющий изменить значение MTU.

Узел должен быть способен воспринимать фрагментированные пакеты IPv6, размер которых после сборки не превышает 1500 октетов [RFC2460]. Этот документ также включает требования (см. параграф 3.6) для количества сборок фрагментов IPv4 и IPv6 MRU, которые должны поддерживаться всеми декапсуляторами. Это гарантирует интероперабельность при всех фиксированных значениях MTU из диапазона 1280 — 1480 байтов.

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

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

  • когда пакеты IPv4 с номером протокола 41 будут передаваться через среду, которая может иметь меньшее значение path MTU (например, IPv4 VPN4), выбор большого значения может привести к излишней фрагментации IPv4;
  • при использовании туннеля для транспортировки туннелированных пакетов IPv6 (например, мобильный узел с настраиваемым туннелем IPv6-in-IPv4 и туннельный интерфейс Ipv6-in-IPv6), выбор слишком малого значения может приводить к излишней фрагментации IPv6.

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

При использовании статического MTU для туннеля, в инкапсулирующем заголовке IPv4 недопустимо устанавливать флаг DF5. В результате этого инкапсулятор не должен получать сообщений ICMPv4 о недопустимо большом размере для инкапсулированных им пакетов.

3.2.2. Динамическое значение MTU для туннеля

Динамическое определение MTU является необязательным. Однако при его реализации следует выполнять рекомендации, содержащиеся в данном документе.

Фрагментация внутри туннеля может быть сведена к минимуму за счет определения инкапсулятором значений IPv4 MTU в туннеле с помощью протокола IPv4 Path MTU Discovery Protocol [RFC1191] и записи результирующего значения MTU для всего пути. Уровень IPv6 в инкапсуляторе может в этом случае рассматривать туннель, как канальный уровень со значением MTU, равным IPv4 MTU для пути за вычетом размера инкапсулирующего заголовка IPv4.

Отметим, что это не предотвращает фрагментации IPv4 в тех случаях, когда значение MTU для пути IPv4 будет давать для IPv6 MTU значение менее 1280 байтов (любой канальный уровень, используемый IPv6, должен иметь значение MTU не менее 1280 байтов [RFC2460]). В этом случае уровень IPv6 «видит» канальный уровень с MTU = 1280, а инкапсулятор использует фрагментацию IPv4 для пересылки 1280-байтовых пакетов IPv6.

Инкапсулятору следует реализовать приведенный ниже алгоритм для решения вопроса об использовании фрагментации IPv4 при пересылке через туннель пакетов IPv6, размер которых превышает MTU для пути через туннель, и возврате отправителю сообщений ICMPv6 о недопустимом размере пакетов [RFC1981]:

if (IPv4 path MTU - 20) < 1280
   if размер пакета > 1280 байтов
      Передать сообщение ICMPv6 packet too big с MTU = 1280 и отбросить пакет else
      Инкапсулировать пакет без установки флага DF в заголовке IPv4. Полученный
      пакет IPv4 может быть фрагментирован уровнем IPv4 на инкапсуляторе или
      другом маршрутизаторе по пути IPv4.
   endif
else
   if размер пакета > (IPv4 path MTU - 20)
      Передать сообщение ICMPv6 «packet too big» с MTU = (IPv4 path MTU — 20) и
      отбросить пакет.
   else
      Инкапсулировать и установить флаг DF в заголовке IPv4.
   endif
endif

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

Отметим, что при использовании динамических значений MTU для туннелей могут возникать «черные дыры» IPv4 MTU, когда сообщения ICMPv4 о недопустимом размере пакетов будут отбрасываться межсетевыми экранами или не будут генерироваться маршрутизаторами [RFC1435, RFC2923].

3.3. Hop Limit

Туннели IPv6-over-IPv4 моделируются с точки зрения IPv6, как «один интервал». Туннель является «черным ящиком» для пользователей и не детектируется средствами диагностики сетей типа traceroute.

Модель на базе «одного интервала» реализуется реализуется за счет процессов инкапсуляции/декапсуляции, которые устанавливают значение поля IPv6 hop limit, как при пересылке через любой другой канал данных (т. е., они уменьшают значение поля hop limit на 1 при пересылке пакета IPv6). Исходный и конечный узлы не меняют значение этого поля.

Значение TTL в инкапсулирующем заголовке IPv4 выбирается по усмотрению реализации протокола. Предлагаемые в настоящее время значения опубликованы в документе Assigned Numbers [RFC3232][ASSIGNED]. Разработчики могут обеспечивать механизмы, позволяющие администратору задавать значение IPv4 TTL, как IP Tunnel MIB [RFC4087].

3.4. Обработка сообщений ICMPv4 об ошибках

       +--------------+
       |Заголовок IPv4|
       |  dst = узел  |
       | инкапсуляции |
       +--------------+
       |  Заголовок   |
       |    ICMPv4    |
- -    +--------------+
       |Заголовок IPv4|
       |  src = узел  |
Пакет  | инкапсуляции |
       +--------------+   - -
IPv4   |  Заголовок   |
       |     IPv6     |   Исходный пакет 
с      +--------------+   IPv6 - может
       | Транспортный |   использоваться
ошибкой|  заголовок   |   для генерации
       +--------------+   сообщения ICMPv6
       |              |   передаваемого
       ~    Данные    ~   отправителю.
       |              |
- -    +--------------+   - -

 

Сообщение ICMPv4, возвращаемое инкапсулятору

В ответ на переданные в туннель пакеты инкапсулятор может получать сообщения ICMPv4 об ошибках от маршрутизаторов IPv4 в туннеле. Эти пакеты адресуются инкапсулятору, поскольку он является источником IPv4 для пакета.

Обработка сообщений ICMPv4 применима только для динамического определения MTU, хотя эти функции могут использоваться и при статическом задании MTU для туннеля.

Сообщения ICMPv4 о недопустимо большом размере пакетов обрабатываются в соответствии с механизмом IPv4 Path MTU Discovery [RFC1191] и полученное в результате значение MTU для пути записывается уровнем IPv4. Это значение MTU для пути используется IPv6 для решения вопроса о генерации сообщений ICMPv6 packet too big, как описано в параграфе 3.2.2.

Обработка других типов сообщений ICMPv4 зависит от доступности информации из инкапсулированного пакета, вызвавшего ошибку.

Многие старые маршрутизаторы IPv4 возвращают лишь 8 байтов данных после заголовка IPv4 в вызвавшем ошибку пакете. Этой информации недостаточно для включения адресных полей заголовка IPv6. Более современные маршрутизаторы IPv4 могут возвращать количество данных после заголовка IPv4, достаточное для включения полного заголовка IPv6 и, возможно, некоторого объема данных (см. [RFC1812]).

Если объем данных из вызвавшего ошибку пакета достаточно велик, инкапсулятор может извлечь информацию из инкапсулированного пакета IPv6 и использовать ее для генерации сообщения ICMPv6 исходному отправителю IPv6, как показано на рисунке.

При получении сообщений ICMPv4, отличных от packet too big, полезно записывать эти события в системный журнал, как ошибки, связанные с туннелем. При достаточно объеме данных узел может передавать сообщения ICMPv6 типа unreachable6 с кодом address unreachable7 отправителю IPv6 (код address unreachable подходит, поскольку с точки зрения IPv6 туннель является каналом, а этот код служит для связанных с каналами ошибок [RFC2463]).

Отметим, что в случаях превышения MTU для пути IPv4, если данных, связанных с сообщением ICMPv4 об ошибке, недостаточно или сообщение ICMPv4 не вызывает генерации сообщения ICMPv6 при достаточном объеме данных, будет отбрасываться не менее двух пакетов (взамен отбрасывания не менее одного для случая одноуровневого определения MTU). Рассмотрим случай, когда хост IPv6 подключен к маршрутизатору IPv4/IPv6, который соединен с сетью, где генерируется сообщение ICMPv4 об избыточном размере пакета. Сначала маршрутизатору нужно определить значение MTU (IPv4) для туннеля, что вызовет потерю по крайней мере одного пакета, а потом хосту нужно узнать значение MTU (IPv6) от маршрутизатора, что приведет к потере еще по крайней мере одного пакета. Тем не менее во всех случаях может теряться более одного пакета, если одновременно приходит множество избыточно больших пакетов.

3.5. Создание заголовка IPv4

При инкапсуляции пакета IPv6 в дейтаграмму IPv4 поля заголовка IPv4 устанавливаются следующим образом:

Version

4

IP Header Length (в 32-битовых словах)

5 (в инкапсулирующем заголовке нет опций IPv4).

Type of Service

0, если явно не задано иное (см. [RFC2983] и параграф 9.1 [RFC3168], где рассматривается использование поля ToS и туннелирование).

Total Length

Размер данных из заголовка IPv6 плюс размер заголовков IPv6 и IPv4 (т. е., размер данных IPv6 + 60 байтов).

Identification

Генерируется, как для прочих пакетов IPv4, передаваемых системой.

Flags

Флаг DF устанавливается в соответствии с параграфом 3.2. При фрагментировании в пакетах, не содержащих последний фрагмент устанавливается флаг MF8.

Fragment Offset

Устанавливается в соответствии с фрагментированием.

Time to Live

Устанавливается реализацией, как описано в параграфе 3.3.

Protocol

41 (номер протокола для IPv6).

Header Checksum

Контрольная сумма заголовка IPv4 [RFC791].

Source Address

Адрес IPv4 для инкапсулятора (адрес, заданный администратором, или адрес выходного интерфейса).

Destination Address

Адрес IPv4 для конечной точки туннеля.

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

3.6. Декапсуляция

Когда хост или маршрутизатор IPv6/IPv4 получает дейтаграмму IPv4, направленную по одному из его собственных адресов IPv4 или адресу связанной с ним multicast-группы и поле протокола имеет значение 41, это говорит о том, что пакет может относиться к туннелю и нужно проверить его принадлежность к одному из настроенных туннельных интерфейсов (путем просмотра адресов отправителя и получателя), собрать фрагменты (если использовалась фрагментация IPv4), удалить заголовок IPv4 и передать полученную в результате дейтаграмму IPv6 на уровень IPv6 этого узла.

Декапсулятор должен убедиться в корректности адреса источника туннеля до начала обработки пакета, чтобы предотвратить проблемы, связанные с подменой адресов (см. раздел 4). Такая проверка выполняется также для пакетов, доставленных транспортным протоколам на декапсуляторе. Проверка выполняется путем сравнения адреса отправителя IPv4 с адресом инкапсулятора, заданном на декапсуляторе. Пакеты, для которых адреса не соответствуют, должны отбрасываться; сообщения ICMP при этом генерировать не следует. Однако, если реализация обычно передает сообщения ICMP при получении пакетов неизвестных протоколов, она может передать сообщение (например, ICMPv4 Protocol 41 Unreachable).

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

Независимо от других форм входной фильтрации IPv4, которые администратор может задать, реализация может выполнять фильтрацию входящих пакетов (т. е., проверять, что пакеты, приходят с интерфейса в направлении маршрута пересылки к конечной точке туннеля, подобно проверке RPF9 [RFC3704]). Поскольку такая проверка может создавать проблемы в туннелях, маршрутизируемых по нескольким каналам, рекомендуется по умолчанию отключать эту проверку. Пакеты, не прошедшие проверку, следует отбрасывать; генерировать сообщения ICMP при этом не следует.

Декапсулятор должен быть способен поддерживать на туннельных интерфейсах значение IPv6 MRU не менее 1500 байтов и не менее самого большого из значений MTU (IPv6) на этом декапсуляторе.

Декапсулятор должен быть способен собирать фрагменты IPv4 пакетов размером (после сборки) до 1500 байтов и не менее наибольшего значения MTU (IPv4) для интерфейсов декапсулятора. Значение 1500 байтов обусловлено результатом инкапсуляции с использованием статического MTU (параграф 3.2.1), тогда, как инкапсуляторы с динамическим выбором (параграф 3.2.2) могут создавать пакеты размер которых определяется наибольшим значением MTU на декапсуляторе (отметим, что это значение строго совпадает с MTU интерфейса последнего маршрутизатора IPv4 перед данным декапсулятором, но для большинства каналов значения MTU одинаковы для всех соседей).

Ограничение на размер собираемых пакетов позволяет инкапсулятору динамически определять значение MTU и использовать преимущества больших значений MTU для пути IPv4. Реализация может иметь конфигурационный параметр, позволяющий установить больший размер буфера сборки для туннеля, нежели указано выше, но использовать меньшие размеры буферов недопустимо.

+-------------+
|  Заголовок  |
|    IPv4     |
+-------------+                 +-------------+
|  Заголовок  |                 |  Заголовок  |
|    IPv6     |                 |    IPv6     |
+-------------+                 +-------------+
|  Заголовок  |                 |  Заголовок  |
|транспортного|      ===>       |транспортного|
|   уровня    |                 |   уровня    |
+-------------+                 +-------------+
|             |                 |             |
~   Данные    ~                 ~   Данные    ~
|             |                 |             |
+-------------+                 +-------------+

 

Декапсуляция IPv6 из IPv4

Декапсуляция показана на рисунке справа.

Декапсулятор выполняет сборку фрагментов IPv4 перед декапсуляцией пакета IPv6.

При декапсуляции пакета заголовок IPv6 не меняется (см. [RFC2983] и параграф 9.1 [RFC3168] в части поля ToS и туннелирования). Если пакет будет пересылаться дальше, значение hop limit уменьшается на 1.

Инкапсулирующий заголовок IPv4 отбрасывается и корректность полученного пакета проверяется при передаче уровню IPv6. При реконструкции пакета IPv6 размер должен определяться по значению поля IPv6 payload length, поскольку в пакете IPv4 могло использоваться заполнение (т. е., после отбрасывания заголовка остаток может превышать размер пакета IPv6).

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

  • все групповые адреса (FF00::/8);
  • все loopback-адреса (::1);
  • все совместимые с IPv4 адреса IPv6 [RFC3513] (::/96), исключая незаданный адрес для детектирования дубликатов10 (::/128);
  • все отображаемые на IPv4 адреса IPv6 (::ffff:0:0/96).

В дополнение к этому на узле следует настроить входную фильтрацию [RFC2827][RFC3704] по адресам отправителей IPv6, подобным адресам любого из интерфейсов узла. Например,

  1. если туннель направлен в Internet, узел следует настроить на проверку того, что его префиксы не используются в адресах отправителей;
  2. если туннель направлен в периферийную сеть, на узле следует настроить проверку того, что адреса отправителей относятся к данной периферийной сети.

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

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

3.7. Адреса Link-Local

Настраиваемые туннели имеют интерфейсы IPv6 (через «канальный уровень» IPv4) и поэтому должны иметь адреса link-local. Эти адреса используются, например, протоколами маршрутизации, работающими через туннели.

Идентификатор интерфейса [RFC3513] в таких случаях может быть основан на 32-битовом адресе IPv4 соответствующего интерфейса или сформирован иным способом, обеспечивающим разумную вероятность уникальности идентификаторов на разных концах туннеля.

Отметим, что может оказаться желательным формирование адреса link-local так, чтобы минимизировать вероятность и влияние смены этого адреса при изменении топологии или замене оборудования.

Если для формирования адреса IPv6 link-local используется адрес IPv4, идентификатором интерфейса будет адрес IPv4, дополненный слева нулями (prepend). Отметим, что бит Universal/Local имеет значение 0, показывающее, что идентификатор интерфейса не является уникальным в глобальном масштабе. Адрес link-local формируется путем добавления идентификатора интерфейса в конец адресного префикса FE80::/64.

+-------+-------+-------+-------+-------+-------+------+------+
|  FE      80      00      00      00      00      00     00  |
+-------+-------+-------+-------+-------+-------+------+------+
|  00      00      00      00   |         Адрес IPv4          |
+-------+-------+-------+-------+-------+-------+------+------+

 

Когда хост имеет более одного адреса IPv4 на рассматриваемом физическом интерфейсе, выбор одного из этих адресов IPv4 для формирования адреса link-local осуществляется администратором или разработчиком.

3.8. Обнаружение соседей через туннели

Реализации с настраиваемыми туннелями должны по крайней мере воспринимать (и отвечать на них) пакеты зондирования, используемые для определения недоступности соседа (NUD11) [RFC2461]. Реализациям следует также передавать тестовые пакеты NUD для обнаружения отказов в сконфигурированных туннелях, чтобы можно было перейти на использование другого пути к адресату. Отметим, что механизм Neighbor Discovery позволяет отказаться от передачи пакетов NUD на каналах между маршрутизаторами, если протокол маршрутизации отслеживает доступность в обоих направлениях.

Предполагается, что настраиваемые туннели не имеют адресов link-layer для обнаружения соседей даже при наличии адреса link-layer (IPv4). Это означает, что:

  • отправителям пакетов Neighbor Discovery не следует включать опцию Source Link Layer Address или Target Link Layer Address на туннельном канале;
  • получатель должен в любом случае обрабатывать пакет Neighbor Discovery, отбрасывая без уведомления опции Source Link Layer Address и Target Link Layer Address, полученные в туннельном канале.

Отказ от использования опций адресов link-layer согласуется с практикой использования механизма Neighbor Discovery на других каналах «точка-точка».

4. Угрозы, связанные с подменой адресов отправителей

Приведенная выше спецификация включает правила проверки адресов отправителя для туннелей (в частности входная фильтрация [RFC2827][RFC3704]), выполняемой в общем случае до декапсуляции пакетов. При использовании туннелей IP-in-IP (независимо от версии IP) важно, чтобы это не использовалось для обхода любых входных фильтров, применяемых для пакетов, не относящихся к туннелям. Таким образом, приведенные в этом документе правила построены таким образом, чтобы использование входной фильтрации для IPv4 и IPv6 не давало простого пути обхода фильтров.

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

  • внешний адрес отправителя IPv4 — реальный адрес IPv4 атакующего;
  • внешний адрес получателя IPv4 — адрес IPv4 декапсулятора;
  • внутренний адрес отправителя IPv6 — Alice (декапсулятор или узел вблизи его);
  • внутренний адрес получателя IPv6 — Bob.

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

Решением этой проблемы будет восприятие инкапсулятором исключительно тех пакетов, адреса отправителей которых явно указаны в числе других сторон туннелей, как описано в параграфе 3.6. Хотя и это решение не обеспечивает полной защиты в случаях отсутствия входных фильтров, оно, тем не менее, существенно повышает уровень безопасности. Более подробно проблемы угроз рассмотрены в следующем разделе документа.

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

Базовые вопросы безопасности при использовании протокола IPv6 рассмотрены в работе [V6SEC].

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

Некоторые механизмы (например, Neighbor Discovery) опираются на значение Hop Count = 255 и/или адреса link-local, как некую гарантию происхождения пакета на другой стороне канала в полудоверенной среде. Туннели более уязвимы к нарушению таких допущений, нежели физические каналы, поскольку атакующий из любой точки Internet может отправлять пакеты IPv6-in-IPv4 декапсулятору туннеля, что приведет к попаданию подставных инкапсулированных пакетов IPv6 на интерфейс настраиваемого туннеля, если проверки при декапсуляции не способны обнаруживать такие подставные пакеты.

По этой причине в данном документе указывается, что декапсуляторы выполняют перечисленные ниже проверки (см. также параграф 3.6) для снижения уровня угроз:

  • адрес отправителя IPv4 в пакет должен совпадать с заданным в конфигурации адресом другой стороны туннеля;
  • независимо от имеющейся входной фильтрации IPv4 администратор может настроить, а реализация может выполнять входную фильтрацию IPv4 для проверки получения пакетов IPv4 с ожидаемого интерфейса (по причине возможных проблем такая проверка по умолчанию может быть отключена);
  • пакеты IPv6 с некоторыми обычно некорректными адресами отправителя IPv6 должны отбрасываться (см. параграф 3.6);
  • следует выполнять входную фильтрацию IPv6 (обычно требует настройки со стороны оператора) для проверки получения пакетов IPv6 с ожидаемого интерфейса.

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

Если остаточные угрозы после проверки адресов отправителей в туннеле представляются значимыми, следует использовать туннелирование с аутентификацией, например, IPsec [RFC2401] (предпочтительно) или GRE12 с заранее созданным секретным ключом [RFC2890]. Поскольку настраиваемые туннели организуются в той или иной степени вручную, организация ключей не должна создать существенных проблем. Организация защищенных IPsec туннелей IPv6-in-IPv4 описана в отдельном документе [V64IPSEC].

Если туннелирование осуществляется в рамках одного административного домена, подобающая входная фильтрация на краю домена может избавить от внешних угроз. Следовательно, короткие туннели являются более предпочтительными, чем длинные, которые могут проходить через Internet.

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

При отбрасывании пакетов, не прошедших проверку по адресам отправителя IPv4 для туннеля узлу не следует «подтверждать» существование туннеля, поскольку эта информация может использоваться для проверки доступности адресов конечных точек туннелей. По этой причине в данной спецификации сказано, что такие пакеты должны отбрасываться, а сообщения ICMP об ошибках генерировать не следует, если реализация обычно не передает сообщений ICMP о недоступности получателя для неизвестных протоколов (в этом случае можно передавать тот же код). Как должно быть очевидно, возврат другого кода ICMP может показать, что включен стек IPv6 (или обработка туннелей для протокола 41). Поведение реализации должно быть согласованным, иначе она становится прозрачной для зондирования.

6. Благодарности

Авторы благодарят членов рабочих групп IPv6, ngtrans13 и v6ops за их предложения и рецензирование этого документа. Особо следует отметить (в алфавитном порядке) Jim Bound, Ross Callon, Tim Chown, Alex Conta, Bob Hinden, Bill Manning, John Moy, Mohan Parthasarathy, Chirayu Patel, Pekka Savola и Fred Templin за множество полезных предложений. Pekka Savola помог при редактировании окончательной версии спецификации.

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

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

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[RFC1981] McCann, J., Deering, S., and J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, August 1996.

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

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[RFC2463] Conta, A. and S. Deering, «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 2463, December 1998.

7.2. Дополнительная литература

[ASSIGNED] IANA, «Assigned numbers online database», http://www.iana.org/numbers.html

[DNSOPV6] Durand, A., Ihren, J., and Savola P., «Operational Considerations and Issues with IPv6 DNS», Work in Progress15, October 2004.

[KM97] Kent, C., and J. Mogul, «Fragmentation Considered Harmful». In Proc. SIGCOMM ’87 Workshop on Frontiers in Computer Communications Technology. August 1987.

[V6SEC] Savola, P., «IPv6 Transition/Co-existence Security Considerations», Work in Progress16, October 2004.

[V64IPSEC] Graveman, R., et al., «Using IPsec to Secure IPv6-over-IPv4 Tunnels», Work in Progress17, December 2004.

[RFC1435] Knowles, S., «IESG Advice from Experience with Path MTU Discovery», RFC 1435, March 1993.

[RFC1812] Baker, F., «Requirements for IP Version 4 Routers», RFC 1812, June 1995.

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 240118, November 1998.

[RFC2461] Narten, T., Nordmark, E., and W. Simpson, «Neighbor Discovery for IP Version 6 (IPv6)», RFC 2461, December 1998.

[RFC2462] Thomson, S. and T. Narten, «IPv6 Stateless Address Autoconfiguration», RFC 2462, December 1998.

[RFC2827] Ferguson, P. and D. Senie, «Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing», BCP 38, RFC 2827, May 2000.

[RFC2890] Dommety, G., «Key and Sequence Number Extensions to GRE», RFC 2890, September 2000.

[RFC2923] Lahey, K., «TCP Problems with Path MTU Discovery», RFC 2923, September 2000.

[RFC2983] Black, D., «Differentiated Services and Tunnels», RFC 2983, October 2000.

[RFC3056] Carpenter, B. and K. Moore, «Connection of IPv6 Domains via IPv4 Clouds», RFC 3056, February 2001.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[RFC3232] Reynolds, J., «Assigned Numbers: RFC 1700 is Replaced by an On-line Database», RFC 3232, January 2002.

[RFC3484] Draves, R., «Default Address Selection for Internet Protocol version 6 (IPv6)», RFC 3484, February 2003.

[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, «Basic Socket Interface Extensions for IPv6», RFC 3493, February 2003.

[RFC3513] Hinden, R. and S. Deering, «Internet Protocol Version 6 (IPv6) Addressing Architecture», RFC 3513, April 2003.

[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, «DNS Extensions to Support IP Version 6», RFC 3596, October 2003.

[RFC3704] Baker, F. and P. Savola, «Ingress Filtering for Multihomed Networks», BCP 84, RFC 3704, March 2004.

[RFC4087] Thaler, D., «IP Tunnel MIB», RFC 4087, June 2005.

8. Отличия от RFC 2893

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

RFC 2893 описывает механизм автоматического туннелирования. Однако в RFC 3056 [RFC3056] описан механизм более общего назначения, который дает каждому узлу с (глобальным) адресом IPv4 префикс /48 IPv6, которого достаточно для всего сайта.

Ниже перечислены отличия от RFC 2893:

  • удалены ссылки на записи A6 и сохранены ссылки на AAAA;
  • удалено автоматическое туннелирование и совместимые с IPv4 адреса;
  • удален используемый по умолчанию настраиваемый туннель с адресом IPv4 Anycast Address;
  • удален раздел Source Address Selection20, поскольку он был включен в другой документ ([RFC3484]);
  • удалено упоминание 6over4;
  • список литературы разделен на две части (нормативные документы и дополнительная литература);
  • удалены слова «or equal» в выражении «if (IPv4 path MTU — 20) is less than or equal to 1280»21;
  • Удален текст: «However, IPv6 may be used in some environments where interoperability with IPv4 is not required. IPv6 nodes that are designed to be used in such environments need not use or even implement these mechanisms.»22
  • Раздельно описаны классы со статическим (Static MTU) и динамическим (Dynamic MTU) определением MTU; указано, что динамический механизм является необязательным, но при его реализации следует выполнять правила параграфа 3.2.2;
  • Указано, что по умолчанию статическое значение MTU лежит в диапазоне от 1280 до 1480 байтов и может быть настраиваемым; рассмотрено использование больших значений для Static MTU;
  • заданы минимальные правила сборки фрагментом IPv4 и IPv6 MRU для повышения уровня интероперабельности и минимизации «черных дыр»;
  • явно указаны ссылки на [RFC2983] и [RFC3168] в описании поля ToS;
  • исправлена ссылка на реестр Assigned Numbers (online-версия) с указанием RFC23 Assigned Numbers is obsolete;
  • исправлен текст о входной фильтрации; в частности, указано, что фильтрация применима к пакетам, доставленным транспортным протоколам на декапсуляторе, а также к пересылаемым декапсулятором пакетам, а также указано, как проверка на декапсуляторах помогает при наличии входной фильтрации IPv4 и IPv6;
  • удалено одностороннее туннелирование; предполагается, что все туннели являются двухсторонними и организуются между адресами конечных точек (а не узлами);
  • удалены рекомендации по анонсированию адресов в DNS, поскольку они не относятся к данной спецификации, и даны ссылки на соответствующие документы;
  • удалено требование следует (SHOULD) для формирования адресов link-local на базе адресов IPv4;
  • добавлено требование следует для реализации опции установки адреса отправителя в туннеле, а также обсуждена польза этой опции;
  • добавлено более строгое описание проверки адреса отправителя — оба адреса (IPv4 и IPv6) должны проверяться, а фильтрация типа RPF является опциональной;
  • переписан раздел «Вопросы безопасности» с уточнением угроз при туннелировании;
  • добавлено примечание об использовании TTL=255 при инкапсуляции;
  • в параграфе 3.2 расширено обсуждение использования «бесконечного» значения IPv6 MTU, явно ведущего к проблемам интероперабельности;
  • добавлено явное требование при использовании обоих методов определения MTU выбирать один метод для каждого канала независимо;
  • отмечено, что обработка сообщений ICMPv4 об ошибках применима только при динамическом определении MTU;
  • разъяснено описание фильтрации записей DNS; API следует использовать и при его отсутствии фильтрация недопустима; упорядочение выходит за пределы спецификации и описано в RFC3484;
  • отмечено, что адрес получателя IPv4 может быть групповым;
  • рекомендовано обеспечивать опцию включения строгой фильтрации на входе для каждого интерфейса;
  • обобщен текст о данных в сообщениях ICMPv4;
  • внесено множество редакционных правок.

Адреса авторов

Erik Nordmark

Sun Microsystems

17 Network Circle

Menlo Park, CA 94025

USA

Phone: +1 650 786 2921

EMail: erik.nordmark@sun.com

Robert E. Gilligan

Intransa, Inc.

2870 Zanker Rd., Suite 100

San Jose, CA 95134 USA

Phone : +1 408 678 8600

Fax : +1 408 678 8800

EMail: bob.gilligan@acm.org


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

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

nmalykh@gmail.com

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

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.

1Domain Naming System.

2Слишком большой пакет.

3Maximum Receive Unit — максимальный принимаемый блок.

4Virtual Private Network — виртуальная частная сеть.

5Don’t Fragment — не фрагментировать.

6Недоступен.

7Адрес недоступен.

8More Fragments — есть еще фрагменты.

9Strict Reverse Path Forwarding — строгая проверка обратного пути пересылки.

10The unspecified address for Duplicate Address Detection.

11Neighbor Unreachability Detection.

12Generic Routing Encapsulation — базовая инкапсуляция маршрутных данных.

13Next Generation Transition — переход к следующему поколению (IP).

15Работа завершена и опубликована в RFC 4472. Прим. перев.

16Работа завершена и опубликована в RFC 4942. Прим. перев.

17Работа завершена и опубликована в RFC 4891. Прим. перев.

18Документ признан устаревшим и заменен RFC 4301. Прим. перев.

20Выбор адреса отправителя.

21< вместо . Прим. перев.

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

23RFC3232. Прим. перев.




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).

Тезисы

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

Оглавление

Исключено из версии HTML

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) также включают служебную информацию для сквозного мониторинга, детектирования отказов и обслуживания. Если блоки данных делятся на узкополосные каналы (например, 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]).

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 на входе21 устройству PE на выходе22.

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

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

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

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

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

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

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

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

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

  1. При доступности одного прецизионного источника синхронизации для всех устройств 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 следует обеспечивать сбор данных мониторинга работы (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 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@gmail.com

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

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.

1Time Division Multiplexed – мультиплексирование с разделением во времени.

2Plesiochronous Digital Hierarchy – плезиохронная цифровая иерархия.

3Synchronous Optical NETwork – цифровая оптическая сеть (используется в основном на американском континенте), Synchronous Digital Hierarchy – синхронная цифровая иерархия (используется в основном в Европе). Прим. перев.

4Pseudo Wire Emulation Edge-to-Edge – эмуляция прямых соединений.

5Packet-Switched Networks/

6Timeslot — тайм-слот, временной интервал.

7Канализированный поток TDM.

8Multiframe.

9Native Service Processing

10Payload container.

11Synchronous payload envelope.

12Виртуальный поток.

13Concatenated circuits.

14Digital Video Signals — сигналы цифрового видео.

15Virtual Tributaries – виртуальные разветвления .

16Pseudo Wire – псевдо-провод.

17В оригинале используются термины jitter (дрожь) и wander (отклонение). Прим. перев.

18Channel-Associated Signaling – поканальная сигнализация.

19Common Channel Signaling – сигнализация с общим сигнальным каналом.

20packet delay variation – вариации задержки пакетов.

21Ingress PE.

22Egress PE.

23Jitter buffer overflow/underflow.

24Далее в переводе этот уровень будет для краткости называться информационным. Прим. перев.

25Размер пользовательских данных.

26Attachment Circuit – соединительное устройство, устройство подключения.

27Performance monitoring.




RFC 4204 Link Management Protocol (LMP)

Network Working Group                                       J. Lang, Ed.
Request for Comments: 4204                                   Sonos, Inc.
Category: Standards Track                                   October 2005

Протокол управления каналом (LMP)

Link Management Protocol (LMP)

PDF

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

В этом документе содержится проект стандарта для протокола Internet, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

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

Copyright (C) The Internet Society (2005).

Тезисы

В целях эффективного масштабирования множество каналов передачи данных может объединяться в один канал организации трафика (TE1). Кроме того, управление каналами TE не ограничивается передачей сообщений в основной полосе и может осуществляться с помощью специальных каналов управления. Этот документ содержит спецификацию протокола управления каналом (LMP2), который поддерживается между парами узлов и служит для управления каналами TE. В частности, LMP будет применяться для поддержки связности каналов управления, проверки физической связности каналов данных, корреляции данных о свойствах каналов, подавления сигналов в нисходящем направлении и локализации отказов на каналах для защиты и восстановления в множестве разнотипных сетей.

Оглавление

Исключено в версии HTML.

1. Введение

Разрабатывают сети с маршрутизаторами, коммутаторами, кросс-коннекторами, системами DWDM3 и мультиплексорами ADM4, использующими общий уровень управления (common control plane), например, GMPLS5 для динамического распределения ресурсов и обеспечения жизнестойкости сети с использованием средств защиты и восстановления. Пара узлов может иметь тысячи соединений между собой и каждое такое соединение может включать множество каналов передачи данных с использованием мультиплексирования (например, Frame Relay DLCI на уровне 2 или временные интервалы TDM6, длины волн WDM7 на уровне 1). В целях масштабирования множество каналов данных может объединяться в один канал TE.

Для обеспечения коммуникаций между узлами для маршрутизации, сигнализации и управления каналами требуется пара доступных один для другого интерфейсов IP. Такую пару интерфейсов будем называть здесь «каналом управления». Отметим, что взаимная доступность интерфейсов не предполагает наличия между ними непосредственного соединения IP — между узлами может находиться сеть IP. Более того, интерфейс, через который передаются и принимаются управляющие сообщения может не совпадать с интерфейсом, используемым для передачи потока данных. Этот документ задает спецификацию протокола управления каналом (LMP), работающего между парами узлов и используемого для поддержки соединений TE и проверки доступности канала управления. Далее в документе узлы, участвующие в работе протокола, зазываются соседями LMP ил просто соседними узлами.

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

К выполняемым протоколом LMP задачам относится проверка группировки каналов в соединения TE, а также проверка совпадения свойств этих каналов на обеих сторонах соединения — это называется корреляцией свойств каналов (link property correlation). Кроме того, LMP может обмениваться этими свойствами с модулем IGP, который, в свою очередь, может анонсировать их другим узлам сети. LMP может также сообщать модулю сигнализации отображения между соединениями TE и каналами управления. Таким образом, LMP исполняет функции «склеивания» на уровне управления.

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

Для целей этого документа канал данных может рассматриваться каждым узлом, как завершающийся на порту или компонентном соединении, в зависимости от возможностей мультиплексирования конечной точки данного канала — компонентное соединение поддерживает мультиплексирование, порт не поддерживает. Это различие важно, поскольку управление такими каналами (включая, например, выделение ресурсов, присвоение меток и из физическую верификацию) зависит от возможностей мультиплексирования. Например, коммутатор Frame Relay может демультиплексировать интерфейс по виртуальным устройствам на основе значений DLCI, кросс-коннектор SONET с интерфейсами OC-192 может демультиплексировать поток OC-192 в 4 потока OC-48. Если множество интерфейсов группируется в один канал TE с использованием связывания (link bundling) [RFC4201], ресурсы канала должны идентифицироваться с использованием трех уровней — Link_Id, идентификатор компонентного соединения и метка, указывающая виртуальное устройство, временной интервал и т. п. Выделение ресурсов происходит на нижнем уровне (метки), а физические соединения выполняются на уровне компонентного канала. В качестве другого примера рассмотрим оптический коммутатор (например, PXC) прозрачно коммутирующий оптические пути OC-192. Если множество интерфейсов снова группируется в один канал TE, связывания каналов [RFC4201] не требуется и нужны только два уровня идентификации — Link_Id и Port_Id. В этом случае выделение ресурсов и физическое подключение выполняются на нижнем уровне (порт).

Для обеспечения взаимодействия между устройствами с разными возможностями мультиплексирования поддерживающим LMP устройствам следует разрешать локальную настройку субканалов на компонентных соединениях, как (логических) каналов данных. Например, если маршрутизатор с интерфейсами 4 OC-48 подключен через мультиплексор 4:1 MUX к кросс-коннектору с интерфейсами OC-192, кросс-коннектору следует обеспечивать возможность настройки каждого субканала (например, STS-48c SPE, если 4:1 MUX является мультиплексором SONET), как канала данных.

Протокол LMP предназначен для поддержки агрегирования одного или множества каналов данных в канал TE (порты или компонентные соединения в каналы TE). Целью формирования канала TE является группировка/отображение информации о некоторых физических ресурсах (и их свойствах) в информацию, которая будет применяться CSPF8 для расчета пути, а также послужит для сигнализации GMPLS.

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

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

Предполагается, что читатель знаком с терминологией [RFC3471], [RFC4202] и [RFC4201].

Bundled Link — составной канал

В соответствии с [RFC4201] составной канал является каналом TE и по этом причине для целей сигнализации GMPLS комбинации <link identifier, label> не достаточно для однозначной идентификации соответствующих ресурсов, используемых LSP. Составной канал включает два или более компонентных соединения.

Control Channel — канал управления

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

Component Link — композитный канал

В соответствии с [RFC4201] компонентное соединение представляет собой подмножество ресурсов канала TE, такое, что (a) отделение от других минимально и (b) в каждом подмножестве метки достаточно для однозначной идентификации соответствующих ресурсов, используемых LSP.

Data Link — канал передачи данных

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

Link Property Correlation — корреляция свойств канала

Процедура организации связи (корреляции) между локальными и удаленными свойствами канала TE.

Multiplex Capability — возможности мультиплексирования

Способность мультиплексировать/демультиплексировать поток данных по субпотокам для коммутирования.

Node_Id — идентификатор узла

Для узла OSPF идентификатор LMP Node_Id совпадает с адресом, содержащимся в OSPF Router Address TLV. Для узла IS-IS при анонсировании TE Router ID TLV идентификатор Node_Id совпадает с анонсируемым Router ID.

Port — порт

Интерфейс, завершающий канал данных.

TE Link — канал TE

В соответствии с [RFC4202] канал TE является логической конструкцией, представляющей способ группировки/отображения информации о неких физических ресурсах (и их свойствах), соединяющих маршрутизаторы LSR, в данные, используемые CSPF для расчета пути и сигнализации GMPLS.

Transparent — прозрачный

Устройство называется X-прозрачным, если оно пересылает входящие сигналы со входа на выход без проверки и изменения X-компоненты этих сигналов. Например, коммутатор Frame Relay прозрачен на сетевом уровне, а оптические коммутаторы прозрачны для электрических сигналов.

2. Обзор LMP

Двумя основными процедурами LMP являются поддержка канала управления и корреляция свойств канала. Поддержка канала управления служит для организации и обслуживания каналов управления между смежными узлами. Это выполняется с использованием сообщений Config и механизма ускоренного обмена сообщениями keep-alive, который нужен в тех случаях, когда не доступны механизмы нижележащих уровней для обнаружения отказов в канале управления. Корреляция свойств канала используется для синхронизации свойств канала TE и проверки его конфигурации.

LMP требует, чтобы между парой узлов имелся хотя бы один активный двухсторонний канал управления. Каждое направление канала управления идентифицируется значением CC_Id9 и два направления связываются между собой с помощью обмена сообщениями LMP Config. За исключением сообщений Test, которые могут применяться транспортным механизмом для обмена в основной полосе, все пакеты LMP передаются по протоколу UDP через порт LMP. Кодирование для канала управления на уровне логического канала (L2) выходит за рамки этого документа.

LMP-смежность между парой узлов возникает при наличии хотя бы одного двухстороннего канала управления между ними. Для каждой смежности может существовать множество одновременно действующих каналов управления, однако характеристики должны согласовываться для каждого канала индивидуально. При использовании LMP fast keep-alive не канале управления обмен сообщениями LMP Hello должен выполняться через канал управления. Другие сообщения LMP могут передаваться через любой активный канал управления между парой смежных узлов. Активные каналы управления могут группироваться в логический канал управления для сигнализации маршрутизации и коррелирования свойств.

Функция коррелирования свойств канала LMP предназначена для агрегирования множества каналов данных (порты или компонентные соединения) в канал TE и синхронизации свойств канала TE. Частью этой функции является обмен сообщениями LinkSummary. Такие сообщения включают локальный и удаленный идентификатор Link_Id, список всех каналов данные в составе канала TE и различные свойства канала. Сообщения LinkSummaryAck или LinkSummaryNack должны передаваться в ответ на сообщение LinkSummary, указывающее согласование свойств канала или отмену такого согласования.

Сообщения LMP передаются с гарантией доставки, основанной на использовании Message_Id и повторов передачи. Идентификаторы сообщений передаются в объектах MESSAGE_ID. В сообщении LMP можно включать не более одного объекта MESSAGE_ID. Для сообщений, относящихся к каналам управления, Message_Id находятся в области действия канала управления, через который сообщение передается. Для сообщений, относящихся к каналам TE, значения Message_Id находятся в области действия смежности LMP. Значения Message_Id монотонно увеличиваются с возвратом в 0 при достижении максимума.

В этом документе определены две дополнительных процедуры LMP — проверка связности канала и контроль отказов. Эти процедуры полезны, в частности, когда каналы управления физически отделены от каналов данных. Проверка связности канала используется для обнаружения уровня данных (data plane discovery), обмена Interface_Id (эти идентификаторы применяются в сигнализации GMPLS в качестве меток порта или идентификатора композитного соединения, в зависимости от конфигурации), а также проверки физической связности. Проверка выполняется путем передачи сообщений Test через каналы данных и возврата в ответ на них сообщений TestStatus через канал управления. Отметим, что сообщение Test является единственным сообщением LMP, передаваемым по каналам данных. Обмен сообщениями ChannelStatus между применяется смежными узлами для подавления нисходящих сигналов и локализации отказов в целях защиты и восстановления.

Для проверки связности канала LMP сообщение Test передается по каналам данных. Для X-прозрачных устройств это требует проверки и изменения аспекта X в сигналах. Процедура проверки связности канала LMP координируется с помощью обмена сообщениями BeginVerify через канал управления. Для поддержки разных аспектов прозрачности в сообщения BeginVerify и BeginVerifyAck включен механизм VTM10. Отметим, что не вводится требования одновременной потери прозрачности всеми каналами данных — считается возможной потеря прозрачности, как минимум, на одном канале. Также не требуется использовать одну физическую среду для канала управления и канала TE, однако канал управления должен завершаться на тех же двух элементах управления, которые служат для управления каналом TE. Поскольку обмен сообщениями BeginVerify координирует процедуру Test, он естественным образом координирует режим прозрачности каналов данных.

Процедура контроля отказов LMP основана на обмене сообщениями ChannelStatus, включающем ChannelStatus, ChannelStatusAck, ChannelStatusRequest и ChannelStatusResponse. Сообщение ChannelStatus передается без запроса и служит для уведомления соседа LMP о состоянии одного или множества каналов данных в канале TE. Сообщение ChannelStatusAck служит для подтверждения приема ChannelStatus. Сообщение ChannelStatusRequest используется для запроса у соседа LMP данных о состоянии одного или множества каналов данных в канале TE. Сообщение ChannelStatusResponse служит для подтверждения приема ChannelStatusRequest и содержит запрошенные данные.

3. Поддержка канала управления

Для организации смежности LMP между двумя узлами должен быть активирован хотя бы один двухсторонний канал управления. Каналы управления могут применяться для обмена управляющей информацией типа данных о поддержке канала или контроле отказов (с использованием протокола сообщений типа описанного здесь LMP), данных управления путями или распространением меток (с использованием сигнального протокола типа RSVP-TE [RFC3209]) и данных о сетевой топологии и распространении сведений о состояниях (с использованием расширений для организации трафика в протоколах типа OSPF [RFC3630] или IS-IS [RFC3784]).

Для целей LMP точная реализация канала управления не задается — это может быть, например, отдельная длина волны или волокно, соединение Ethernet, туннель IP через отдельную сеть управления или просто дополнительные байты в канале данных. Каждый узел задает для канала управления уникальный (для себя) 32-битовый целочисленный идентификатор, отличный от 0, CC_Id. Значения идентификаторов берутся из одного пространства с идентификаторами безадресных интерфейсов. Пакеты LMP передаются по протоколу UDP с использованием порта LMP. Таким образом, канальное представление управляющего канала не является частью спецификации LMP.

Для организации канала управления нужно знать IP-адрес, которому будут приниматься пакеты на удаленной стороне. Этот адрес можно задать в конфигурации вручную или определить автоматически. Отметим, что для сигнализации по основному каналу (in-band signaling) канал управления можно явно задать в конфигурации конкретного канала данных. В этом случае можно использовать обмен сообщениями Config для динамического определения адреса IP на удаленном конце канала управления. Это выполняется путем передачи сообщения Config с индивидуальным адресом отправителя по групповому адресу IP (224.0.0.1 или ff02::1). В ответ должны передаваться сообщения ConfigAck и ConfigNack по адресу IP из поля отправителя в заголовке пакета с сообщением Config.

Каналы управления существуют независимо от каналов TE и между парой узлом может быть организовано множество одновременных каналов управления. Отдельные каналы управления могут быть реализованы разными способами, например, один может быть создан в оптическом волокне, а другой вне волокна. В любом случае параметры должны согласовываться через каждый канал управления для поддержки связности LMP, если иные механизмы не доступны. Поскольку каналы управления электрически завершаются на каждом узле, можно детектировать отказы каналов управления с использованием нижележащих уровней (например, SONET/SDH).

Имеется четыре сообщения LMP, которые применяются для управления отдельными каналами — Config, ConfigAck, ConfigNack и Hello. Эти сообщения должны передаваться через канал, к которому они относятся. Все прочие сообщения LMP можно передавать через любой активный канал управления между парой смежных узлов LMP.

Для поддержки смежности LMP требуется наличие хотя бы одного активного канала между парой смежных узлов (напомним, что между парой узлом может одновременно существовать множество активных каналов управления). При отказе канала управления можно использовать дополнительный канал управления, как описано ниже.

3.1. Согласование параметров

Активизация канала управления начинается с обмена для согласования параметров, использующего сообщения Config, ConfigAck и ConfigNack. Содержимое этих сообщений создается на основе объектов LMP, которые могут быть согласуемыми или несогласуемыми (указываются битом N в заголовке объектов). Согласуемые объекты могут применяться для согласования партнерами LMP неких значений. Несогласуемые объекты служат для анонсирования конкретных значений, которые не нужно или невозможно согласовать.

Для активизации канала управления удаленному партнеру должно быть передано сообщение Config и от него локальный узел должен получить сообщение ConfigAck. В сообщении Config содержится локальный идентификатор канала управления (CC_Id), идентификатор узла-отправителя (Node_Id), идентификатор сообщения Message_Id для обеспечения гарантированной доставки, а также объект CONFIG. Возможно одновременное начало процедуры активизации канала управления с обеих сторон. Для предотвращения неоднозначностей в атких случаях «выигрывает» узел с большим значением Node_Id, а узел с меньшим Node_Id должен прекратить передачу сообщения Config и ответить на принятое сообщение Config. Если значения Node_Id совпадают, это говорит о некорректной настройке конфигурации одного или обоих узлов. В этом случае узлы могут продолжить повторы передачи сообщений Config, надеясь на устранение конфигурационных ошибок. Отметим, что эту проблему может решить оператор, сменив значение Node_Id на одной или обеих сторонах.

Сообщения ConfigAck служат для подтверждения приема сообщений Config и выражения согласия со всеми конфигурационными параметрами (согласуемыми и несогласуемыми).

Сообщения ConfigNack подтверждают прием Config и указывают какие (если они есть) из несогласуемых объектов CONFIG не приемлесы, а также предлагают дополнительные значения для согласуемых параметров.

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

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

При использовании множества каналов управления на одном физическом интерфейсе обмен для согласования параметров выполняется для каждого канала управления. Разные сообщения LMP для согласования параметров связываются с соответствующими каналами по уникальным в масштабе узла значениям идентификаторов (CC_Id).

3.2. Протокол Hello

Как только будет активизирован канал управления между парой смежных узлов, через него можно начинать использование протокола LMP Hello для организации связности между узлами и детектирования отказов в канале управления. Протокол LMP Hello используется в качестве облегченного механизма проверки «живучести» канала (keep-alive) для быстрого реагирования на отказы, чтобы не терялись сообщения IGP Hello и соответствующие отношения смежности (link-state adjacency) без необходимости не удалялись.

3.2.1. Согласование параметров Hello

До отправки сообщений Hello должны быть согласованы параметры HelloInterval и HelloDeadInterval на локальном и удаленном узлах. Обмен этими параметрами выполняется в сообщении Config. Параметр HelloInterval задает частоту передачи сообщений LMP Hello в миллисекундах (мсек). Например, при значении параметра 150 передающий узел будет отправлять сообщения Hello хотя бы один раз за каждые 150 мсек. HelloDeadInterval указывает интервал (в мсек), в течение которого устройство будет ожидать сообщения Hello, пока не сочтет канал управления «умершим».

Значение HelloDeadInterval должно быть больше HelloInterval и следует делать его по крайней мере втрое больше HelloInterval. Если не используется механизм ускоренной проверки живучести (fast keep-alive) LMP, для параметров HelloInterval и HelloDeadInterval должно устанавливаться значение 0.

Значения HelloInterval и HelloDeadInterval следует выбирать аккуратно для обеспечения быстрого отклика на отказы канала управления и отсутствия перегрузок. В силу этого очевидно использование различных значений параметров в разных реализациях каналов управления. Для каналов управления, организованных через прямое соединение, предлагается по умолчанию использовать значения HelloInterval = 150 и HelloDeadInterval = 500 мсек.

Когда узел передал или получил сообщение ConfigAck, он может начинать отправку сообщений Hello. После отправки сообщения Hello и получения приемлемого Hello (т. е., с ожидаемым порядковым номером — см. параграф 3.2.2) канал управления переходит в активное состояние (up) (возможен переход в состояние up без отправки сообщений Hello, если для индикации двухсторонней связности канала управления применяются другие методы; например, данные о связности канала управления могут быть получены от транспортного уровня). Однако, если узел получает сообщение ConfigNack взамен ConfigAck, он должен отказаться от передачи сообщения Hello, а канал управления не следует переводить в состояние up. Машина конечный состояний (FSM) для канала управления описана в параграфе 11.1.

3.2.2. Ускоренная проверка жизнеспособности

Каждое сообщение Hello содержит два порядковых номера — первый (TxSeqNum) указывает номер сообщения Hello, которое будет передаваться, а второй (RcvSeqNum) – номер последнего сообщения Hello, полученного от смежного узла через данный канал управления.

Для порядковых номеров имеется два специальных значения. Для TxSeqNum недопустимо использовать значение 0. TxSeqNum = 1 используется для индикации того, что отправитель только начал работу и еще не знает номера последнего переданного сообщения. Таким образом, первое сообщение Hello передается с TxSeqNum = 1 и RxSeqNum = 0. Когда TxSeqNum достигает значения 232-1, следующим номером будет 2, а не 0 или 1, поскольку эти номера имеют особое значение.

При нормальной работе разница между RcvSeqNum в полученном сообщении Hello и локальным номером TxSeqNum для генерируемого сообщений в большинстве случаев будет составлять 1. Эта разность может становиться больше 1 только при перезапуске управляющего канала или достижении максимального номера.

Поскольку 32-битовые порядковые номера могут достигать максимума, можно воспользоваться приведенным ниже выражением для проверки того, что недавно полученное значение TxSeqNum меньше полученного перед этим.

   if ((int) old_id - (int) new_id > 0) {
      новое значение меньше старого;
   }

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

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

  1. После завершения конфигурационного этапа узел A передает сообщения Hello узлу B с {TxSeqNum=1;RcvSeqNum=0}.

  2. Узел A получает Hello от узла B с {TxSeqNum=1;RcvSeqNum=1}. По истечении интервала HelloInterval узел A передает узлу B сообщения Hello {TxSeqNum=2;RcvSeqNum=1}.

  3. Узел A получает Hello от узла B с {TxSeqNum=2;RcvSeqNum=2}. По истечении интервала HelloInterval узел A передает узлу B сообщения Hello {TxSeqNum=3;RcvSeqNum=2}.

3.2.3. Отключение канала управления

Для обеспечения возможности аккуратного отключения канала управления с административными целями имеется флаг ControlChannelDown в базовом заголовке (Common Header) пакетов LMP. При наличии между парой узлов активных каналов передачи данных административное отключение канала управления следует использовать только в тех случаях, когда имеются другие активные каналы управления, которые можно использовать для поддержки каналов данных.

При административном отключении канала управления узел должен устанавливать флаг ControlChannelDown во всех сообщениях LMP, передаваемых через канал управления. Инициировавший отключение управляющего канала узел может прекратить передачу сообщений Hello по истечении HelloDeadInterval секунд или при получении через этот же канал управления сообщения LMP с установленным флагом ControlChannelDown.

Узлу, получившему пакет LMP с установленным флагом ControlChannelDown, следует передать сообщение Hello с установленным флагом ControlChannelDown и перевести канал управления в отключенное состояние (down).

3.2.4. Вырожденное состояние

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

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

4. Сопоставление свойств каналов

В рамках LMP для каналов TE определен обмен для сопоставления свойств каналов с помощью сообщений LinkSummary, LinkSummaryAck и LinkSummaryNack. Содержимое этих сообщений создается с использованием объектов LMP, которые могут быть согласуемыми или несогласуемыми (указывается влагом N в заголовке объекта). Согласуемые объекты служат для того, чтобы стороны могли совместно выбирать значения некоторых параметров канала. Несогласуемые объекты служат для анонсирования конкретных значений, которые не нужно или невозможно согласовать.

Каждый канал TE имеет идентификатор (Link_Id), выделенный на каждой стороне соединения. Эти идентификаторы должны быть одного типа (т. е., IPv4, IPv6 или безадресный) на обеих сторонах. Если принимается сообщение LinkSummary с разными типами канала TE на локальной и удаленной стороне, в ответ должно передаваться сообщение LinkSummaryNack с кодом ошибки Bad TE Link Object. Аналогично, на каждой стороне канала присваивается идентификатор интерфейса (Interface_Id). Эти идентификаторы также должны иметь одинаковый тип на обеих сторонах. При получении LinkSummary с разнотипными Interface_Id на локальной и удаленной стороне в ответ должно передаваться сообщение LinkSummaryNack с кодом ошибки Bad Data Link Object.

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

Сообщения LinkSummary служат для проверки согласованности информации о канале данных и TE на обеих сторонах, а также для (1) агрегирования множества каналов данных (портов или компонентных каналов) в один канал TE, (2) обмена, сопоставления (для обнаружения несогласованности) или изменения параметров канала TE и (3) обмена, сопоставления (для обнаружения несогласованности) или изменения значений Interface_Id (Port_Id или идентификаторы компонентных каналов).

Сообщение LinkSummary включает объект TE_LINK, за которым следует один или множество объектов DATA_LINK. Объект TE_LINK указывает идентификаторы Link_Id на локальной и удаленной стороне канала TE, а также поддержку процедур контроля отказов и верификации для канала TE. Объекты DATA_LINK служат для указания характеристик каналов данных, образующих канал TE. Эти объекты включают локальный и удаленный идентификатор Interface_Id и могут включать один или множество субобъектов с дополнительным описанием свойств каналов данных.

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

Сообщение LinkSummaryAck служит для сигнализации о согласовании отображений Interface_Id и определений свойств каналов. В остальных случаях должно передаваться сообщение LinkSummaryNack, показывающее интерфейсы с некорректным отображением и/или неприемлемые свойства канала. Если сообщение LinkSummaryNack показывает, что отображение Interface_Id некорректно, а процедура проверки включена, процесс проверки канала следует повторить для всех несоответствующих свободных каналов данных. Если сообщение LinkSummaryNack включает согласуемые параметры, должны быть указаны приемлемые значения этих параметров. Если полученное сообщение LinkSummaryNack включает согласуемые параметры, инициатору сообщения LinkSummary следует отправить новое сообщение LinkSummary. В это новое сообщение LinkSummary следует включить новые значения для согласуемых параметров. В этих значениях следует принимать во внимание приемлемые значения параметров из сообщения LinkSummaryNack.

Сообщение LinkSummary может стать довольно большим по причине большого числа объектов DATA LINK. Реализациям LMP следует поддерживать возможность фрагментации при передаче сообщений LMP и они должны поддерживать сборку фрагментов IP при получении сообщений LMP.

5. Проверка связности для канала

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

Поддержка этой процедуры указывается флагом Link Verification Supported в объекте TE_LINK сообщений LinkSummary.

Если получено сообщение BeginVerify, а проверка каналов не поддерживается для соединений TE, в ответ должно передаваться сообщение BeginVerifyNack с кодом ошибки (Error Code), показывающим, что проверка для этого канала TE не поддерживается (Link Verification Procedure not supported for this TE Link).

Уникальной характеристикой прозрачных устройств является то, что данные не изменяются и не проверяются в процессе нормальной работы. Это создает сложности при проверке связности каналов данных и организации отображения меток. Поэтому для обеспечения подобающей проверки связности канала данных требуется непрозрачность таких каналов до того момента, как они будут выделены для пользовательского трафика. Для поддержки той или иной степени непрозрачности (например, проверка служебных байтов, и терминирование полезной нагрузки IP и т. п.) и, следовательно, поддержки различных механизмов транспортировки сообщений Test в сообщения BeginVerify и BeginVerifyAck включается поле Verify Transport Mechanism.

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

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

После организации между двумя узлами канала управления проверку связности канала данных можно проверить путем обмена сообщениями Test через каждый из каналов данных, указанный в канале TE. Следует отметить, что все сообщения LMP, за исключением Test, будут передаваться через каналы управления и обмен сообщениями Hello через каждый канал управления будет продолжаться и после завершения проверки каналов данных. Сообщение Test передаются через проверяемые каналы. Каналы данных тестируются в направлении передачи, поскольку они являются односторонними. Следовательно, оба узла могут выполнять обмен сообщениями Test одновременно (и независимо).

Для начала процедуры проверки канала локальный узел должен отправить через канал управления сообщение BeginVerify. Для ограничения процедуры Link Verification конкретным каналом TE, локальное значение Link_Id должно отличаться от 0. Если это поле равно 0, канал данных может охватывать множество каналов TE и/или в число проверяемых каналов TE могут попасть еще не настроенные. Для случаев локального Link_Id = 0 используется флаг Verify all Links в объекте BEGIN_VERIFY, позволяющий различать каналы данных, охватывающие множество каналов TE и каналы данных, еще не связанные с каналом TE. В частности, проверка каналов данных, охватывающих множество каналов TE, указывается локальным полем Link_Id = 0 и установкой флага Verify all Links. Проверка каналов данных, которые еще не привязаны к каналам TE, указывается установкой локального поля Link_Id = 0 и сбросом флага Verify all Links.

Сообщение BeginVerify содержит также число проверяемых каналов данных, интервал, в течение которого будут передаваться сообщения Test (VerifyInterval), поддерживаемую схему кодирования и транспортные механизмы, скорость передачи для сообщений Test, а также (в тех случаях, когда каналы данных соответствуют оптическим волокнам) идентификаторы длин волн, на которых будут передаваться сообщения Test.

Если удаленный узел получил сообщение BeginVerify и готов обрабатывать сообщения Test, он должен передать в ответ сообщение BeginVerifyAck, указывающее желаемый для сообщений TEST транспортный механизм. Удаленный узел включает в это сообщение 32-битовое значение Verify_Id, уникальное в масштабах данного узла. Значение Verify_Id может выбираться случайно, однако недопустимо его совпадение с любым Verify_Id, испольуемым в это же время выбравшим значение узлом. Verify_Id после этого используется во всех проверочных сообщениях для того, чтобы различать разных партнеров LMP и/или параллельные процедуры Test. Когда локальный узел получит сообщение BeginVerifyAck от удаленного узла, он может начать тестирование каналов данных путем периодической отправки сообщений Test в каждый канал. Сообщение Test включает Verify_и локальное значение Interface_Id для соответствующего канала данных. Удаленный узел должен передавать в ответ сообщение TestStatusSuccess или TestStatusFailure для каждого проверяемого канала. Для подтверждения приема TestStatusSuccess и TestStatusFailure должно передаваться сообщение TestStatusAck. Неподтвержденные сообщения TestStatusSuccess и TestStatusFailure следует повторять по получения подтверждения или достижения предельного числа повторов (см. также раздел 10).

Для отправителя допустимо прерывание процедуры Test в любой момент после отправки сообщения BeginVerify. Для этого следует передать сообщение EndVerify.

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

При получении сообщения Test идентификатор интерфейса Interface_Id из этого сообщения (используется в GMPLS как метка порта или идентификатор компонентного канала в зависимости от конфигурации) записывается и отображается на локальный идентификатор Interface_Id для принявшего сообщение канала данных, а в ответ должно передаваться сообщение TestStatusSuccess, включающее локальное значение Interface_Id, а также значения Interface_Id и Verify_Id из принятого сообщения Test. Получение TestStatusSuccess показывает, что сообщение Test было обнаружено удаленным узлом и физическая связность канала данных была подтверждена. При получении TestStatusSuccess локальному узлу следует пометить канал данных как активный и отправить удаленному узлу сообщение TestStatusAck. Однако, если сообщение Test не было обнаружено на удаленной стороне в течение периода наблюдения (задается значением VerifyDeadInterval), удаленный узел должен передать через канал управления сообщение TestStatusFailure, показывающее неудачу при проверке физической связности канала данных. Локальному узлу, получившему сообщение TestStatusFailure, следует пометить канал данных как сбойный (FAILED) и передать удаленному узлу сообщение TestStatusAck. После проверки всех каналов данных локальному узлу следует передать сообщение EndVerify для индикации завершения тестирования на данном канале.

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

Локальному и удаленному узлу следует поддерживать полный список отображений Interface_Id для целей сопоставления.

5.1. Пример проверки связности для канала

На рисунке 1 показан пример проверки связности, которая выполняется при добавлении канала между узлами A и B. В этом примере канал TE состоит из трех свободных портов (каждый из которых использует свое волокно) и связан с двухсторонним каналом управления (отмечен буквой c). Процесс проверки связности поэтапно описан ниже.

  • Узлу B через канал управления передается сообщение BeginVerify, говорящее о начале проверки портов, образующих канал TE. Объект LOCAL_LINK_ID в сообщении BeginVerify содержит идентификатор (адрес IP или индекс интерфейса), присвоенный каналу узлом A.

  • Получив сообщение BeginVerify, узел B создает идентификатор Verify_Id и привязывает его к каналу TE от A. Эта привязка используется при получении узлом B сообщений Test от узла A, содержащих Verify_Id. Узел B определяет идентификатор (адрес IP или индекс интерфейса), который узел A присвоил каналу TE, просматривая объект LOCAL_LINK_ID из полученного сообщения BeginVerify (если порты данных еще не выделены для TE Link, привязка ограничена Node_Id для узла A). В ответ на сообщение BeginVerify узел B передает сообщение BeginVerifyAck узлу A. Объект LOCAL_LINK_ID в сообщении BeginVerifyAck служит для передачи идентификатора (адрес IP или индекс интерфейса), который узел B присвоил каналу TE. Объект REMOTE_LINK_ID в сообщении BeginVerifyAck служит для привязки идентификаторов Link_Id, выделенных узлами A и B. Значение Verify_Id возвращается узлу A в сообщении BeginVerifyAck по каналу управления.

  • Когда узел A получает сообщение BeginVerifyAck, он начинает переиодическую отправку сообщений Test через первый порт (Interface Id=1). Сообщение Test включает Interface_Id для порта и значение Verify_Id, присвоенное злом B.

  • При получении узлом B сообщений Test он отображает полученный идентификатор Interface_Id на свой локальный идентификатор Interface_Id = 10 и передает сообщение TestStatusSuccess узлу A через канал управления. Сообщение TestStatusSuccess включает локальное и принятое значения Interface_Id для портов, а также Verify_Id. Идентификатор Verify_Id используется для определения локального и удаленного идентификаторов канала TE (адреса IP или индексы интерфейсов), к которым относятся каналы данных.

  • Узел A будет передавать через канал управления узлу B сообщение TestStatusAck, показывающее, что он получил сообщение TestStatusSuccess.

  • Процесс повторяется до завершения проверки всех портов.

  • Аосле этого узел A передает через канал управления сообщение EndVerify, говорящее узлу B о завершении проверки.

  • B отвечает на это сообщение отправкой через канал управления узлу A сообщения EndVerifyAck.

    Отметим, что эта процедура может применяться для «обнаружения» связности между портами данных.

+---------------------+                      +---------------------+
+                     +                      +                     +
+      Узел A         +<-------- c --------->+        Узел B       +
+                     +                      +                     +
+                     +                      +                     +
+                   1 +--------------------->+ 10                  +
+                     +                      +                     +
+                     +                      +                     +
+                   2 +                /---->+ 11                  +
+                     +          /----/      +                     +
+                     +     /---/            +                     +
+                   3 +----/                 + 12                  +
+                     +                      +                     +
+                     +                      +                     +
+                   4 +--------------------->+ 14                  +
+                     +                      +                     +
+---------------------+                      +---------------------+

Рисунок 1. Пример проверки связности между узлами A и B


6. Обработка отказов

В этом разделе описана необязательная процедура LMP, служащая для обработки отказов путем быстрого уведомления о состоянии одного или множества каналов данных в канале TE. Областью действия этой процедуры является канал TE и поэтому применение этой процедуры согласуется в процессе обмена LinkSummary. Процедура может служить для быстрой изоляции отказов каналов данных и канала TE и предназначена для использования как на односторонних, так и на двухсторонних LSP.

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

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

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

Детектирование отказов должно происходить на ближайшем к отказу уровне — для оптических сетей это физический (оптический) уровень. Одним из способов обнаружения отказов на физическом уровне является детектирование «потери света» (LOL11). Другие методы мониторинга оптических сигналов пока находятся в стадии разработки и не рассматриваются в этом документе. Однако следует понимать, что механизм, используемый для уведомлений об отказах в LMP, не зависит от способа детектирования отказов и основан просто на фактах обнаружения отказа.

6.2. Процедура локализации отказа

В некоторых ситуациях отказ канала данных между двумя узлами распространяется в нисходящем направлении так, что все нисходящие узлы обнаруживают отказ без его локализации. Для предотвращения множественных уведомлений об одном отказе LMP обеспечивает уведомление об отказах с помощью сообщений ChannelStatus. Это сообщение можно использовать для индикации отказа одного или многих каналов данных, а также всего канала TE. Сопоставление отказов выполняется локально на каждом узле, получившем уведомление об отказе.

Для связывания отказа с конкретным каналом между смежными узлами нисходящий (в смысле потока данных) узел , обнаруживший отказ канала данных будет передавать своему соседу в восходящем направлении сообщение ChannelStatus, показывающее, что обнаружен отказ (уведомления для всех каналов с отказами объединяются). Получивший сообщение ChannelStatus восходящий узел должен передать в ответ сообщение ChannelStatusAck, подтверждающее прием ChannelStatus. Восходящему узлу следует провести сопоставление с целью определить, обнаружен ли этот отказ локально для соответствующих LSP. Если, например, будет ясно, что отказ наблюдается на входе восходящего узла или внутри него, восходящий узел будет знать точку отказа. После сопоставления информации об отказах восходящему узлу следует передать нисходящему узлу сообщение ChannelStatus, которое показывает наличие или отсутствие отказа в канале. Если сообщение ChannelStatus не будет получено нисходящим узлом, тому следует передать сообщение ChannelStatusRequest для соответствующего канала. После определения точки отказа можно использовать сигнальный протокол для инициирования процедур защиты или восстановления интервала (span) или пути.

Если отказ произошел на всех каналах данных соединения TE, восходящий узел может быть уведомлен об отказе канала TE без указания конкретных каналов данных. Это выполняется путем отправки уведомления в сообщении ChannelStatus, идентифицирующем канал TE без указания Interface_Id в объекте CHANNEL_STATUS.

6.3. Примеры локализации отказов

На рисунке 2 приведен пример сети, где 4 узла соединены в линейный массив. Каналы управления являются двухсторонними и помечены буквой c. Все LSP также являются двухсторонними.

В первом случае [(a) на рисунке] возникает отказ на одном из направлений двухстороннего LSP. Узел 4 обнаружит этот отказ и передаст узлу 3 сообщение ChannelStatus, сообщающее об отказе (например, LOL) соответствующему восходящему узлу. Узел 3, получив сообщение ChannelStatus от узла 4, вернет тому сообщение ChannelStatusAck и выполнит для него локальное сопоставление. Когда узел 3 выполнит сопоставление для этого отказа и проверит его, он свяжет отказ с каналом данных между узлами 3 и 4. В этот момент узлу 3 следует отправить на узел 4 сообщение ChannelStatus, говорящее о локализации отказа.

Во втором случае [(b) на рисунке] один отказ (например, повреждение волокна) воздействует на оба направления двухстороннего LSP. Узел 2 (узел 3) обнаружит отказ в восходящем (нисходящем) направлении и отправит восходящему (относительно потока данных) узлу сообщение ChannelStatus, говорящее об отказе (например, LOL). Одновременно (не учитывая задержек при распространении) узел 1 (узел 4) обнаружит отказ на восходящем (нисходящем) направлении и будет передавать соответствующему восходящему (относительно потока данных) узлу сообщение ChannelStatus, говорящее об отказе. Узлы 2 и 3 будут локализовать отказ в двух направлениях.

    +-------+        +-------+        +-------+        +-------+
    + Узел1 +        + Узел2 +        + Узел3 +        + Узел4 +
    +       +-- c ---+       +-- c ---+       +-- c ---+       +
----+---\   +        +       +        +       +        +       +
<---+---\\--+--------+-------+---\    +       +        +    /--+--->
    +    \--+--------+-------+---\\---+-------+---##---+---//--+----
    +       +        +       +    \---+-------+--------+---/   +
    +       +        +       +        +       +  (a)   +       +
----+-------+--------+---\   +        +       +        +       +
<---+-------+--------+---\\--+---##---+--\    +        +       +
    +       +        +    \--+---##---+--\\   +        +       +
    +       +        +       +  (b)   +   \\--+--------+-------+--->
    +       +        +       +        +    \--+--------+-------+----
    +       +        +       +        +       +        +       +
    +-------+        +-------+        +-------+        +-------+

Рисунок 2. Показаны 2 типа отказов на каналах данных (символы ##):
(A) канал данных нисходящего направления в двухстороннем LSP,
(B) два канала данных, соответствующих разным направлениям двухстороннего LSP. Каналы управления между узлами помечены буквой c.


6.4. Индикация активации канала

Сообщения ChannelStatus могут служить также для уведомления соседа LMP о том, что для канала данных следует вести активный мониторинг. Это называется индикацией активации канала (Channel Activation Indication). Особенно полезно это в сетях с прозрачными узлами, где может потребоваться переключение состояния канала данных с помощью управляющих сообщений. Например, если канал данных подготовлен заранее, а на физическом канале возникает отказ после проверки канала но до начала отправки туда пользовательского трафика, нужен механизм индикации того, что активность канала сохраняется, поскольку иначе отказ может остаться не обнаруженным.

Сообщение ChannelStatus используется для индикации канала или группы каналов, которые в настоящий момент активны. В ответ на такое сообщение должно передаваться сообщение ChannelStatusAck. При получении ChannelStatus соответствующий канал(ы) данных должен переводиться в состояние Active. Если при переводе канала в активное состояние обнаруживается отказ, следует передать сообщение ChannelStatus, как описано в параграфе 6.2.

6.5. Индикация деактивации канала

Сообщения ChannelStatus могут служить также для уведомления соседа LMP о том, что для канала данных больше не следует вести активный мониторинг. Это сообщение по смыслу обратно описанному в предыдущем параграфе.

При получении сообщения с Channel Deactive Indication соответствующий канал(ы) данных должен выйти из активного состояния.

7. Использование идентификаторов сообщений

Объекты MESSAGE_ID и MESSAGE_ID_ACK включаются в сообщения LMP для обеспечения гарантированной доставки сообщений. Применение таких объектов рассматривается в данном разделе. Объекты MESSAGE_ID и MESSAGE_ID_ACK содержат поле Message_Id.

В любом сообщении LMP может присутствовать лишь один объект MESSAGE_ID/MESSAGE_ID_ACK.

Для сообщений, связанных с каналами управления, поле Message_Id относится к области CC_Id, для сообщений, относящихся к каналу TE, Message_Id относится к области смежности LMP.

Поле Message_Id в объекте MESSAGE_ID содержит выбранное генератором значение. Эти значения должны монотонно возрастать. Значение считается ранее использованным, если оно было передано в сообщении LMP с таким же CC_Id (для относящихся к каналу управления сообщений) или смежностью LMP (для сообщения, относящихся к TE Link). Поле Message_Id в сообщении MESSAGE_ID_ACK содержит значение Message_Id из подтверждаемого сообщения.

Неподтвержденные сообщения с объектом MESSAGE_ID следует передавать повторно, пока оно не будет подтверждено, если число повторов не будет исчерпано раньше (см. раздел 10).

Отметим, что 32-битовое поле Message_Id может достигать верхней границы. Для проверки отношений между последним и предшествующим ему значениями Message_Id можно использовать приведенное ниже выражение:

   Если ((int) old_id - (int) new_id > 0) {
      Новое значение меньше предыдущего;
   }

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

Если получено сообщение Config и значение Message_Id в нем меньше наибольшего значения Message_Id, принятого от того же отправителя для CC_Id, это сообщение следует считать нарушающим порядок.

Если получено сообщение LinkSummary и значение Message_Id в нем меньше наибольшего значения Message_Id, принятого от того же отправителя для TE Link, это сообщение следует считать нарушающим порядок.

Если получено сообщение ChannelStatus с Message_Id меньше наибольшего полученного ранее от того же отправителя Message_Id для заданного канала TE, получателю следует проверить полученное ранее значение Message_Id для состояния каждого канала данных, указанного в сообщении ChannelStatus. Если значение Message_Id превышает наибольшее принятое раньше значение Message_Id по крайней мере для обного из каналов данных, указанных в сообщении, недопустимо считать сообщение нарушающим порядок доставки, в противном случае его следует считать нарушающим порядок. Однако недопустимо менять состояние любого канала данных, если значение Message_Id меньше полученного недавно Message_Id, связанного с каналом данных.

Все остальные сообщения недопустимо считать нарушающими порядок доставки.

8. Аккуратный перезапуск

В этом разделе описан механизм повторной синхронизации состояния LMP после перезапуска уровня управления. Такой перезапуск может быть обусловлен восстановлением первого канала управления после коммуникационного отказа. Сбой коммуникаций может быть результатом отказа LMP-смежности или проблемы на узле, когда состояние управления LMP теряется без воздействия на уровень передачи данных. Последнее обнаруживается установкой флага LMP Restart в общем заголовке (Common Header) сообщений LMP. При отказе на уровне управления в результате потери канала управления информацию канала LMP следует сохранять. В некоторых случаях узел может оказаться способным сохранить информацию о состоянии канала LMP даже при отказе на этом узле. Однако в обоих случаях должна происходить повторная синхронизация состояний каналов данных.

Предполагается, что значения Node_Id и Local Interface_Id сохраняются при перезапуске уровня управления.

После перезапуска уровня управления на узле требуется заново организовать канал(ы) управления с использованием процедур из параграфа 3.1. При повторной организации каналов управления следует передавать сообщение Config с использованием индивидуальных (unicast) адресов IP для отправителя и получателя.

Если отказ уровня управления был результатом отказа узла, при котором состояние управления LMP было потеряно, в сообщениях LMP должен устанавливаться флаг LMP Restart, пока не будет получено сообщение Hello с RcvSeqNum = TxSeqNum (локальное значение). Это показывает активизацию канала управления и обнаружение перезапуска соседа LMP.

Далее предполагается, что перезапуск компоненты LMP происходит только на одной стороне канала TE. При перезапуске компоненты LMP на обеих сторонах TE Link следует использовать обычную процедуру LinkSummary, как описано в разделе 4.

После активизации канала управления сосед LMP должен передать сообщение LinkSummary для каждого TE Link через смежность. Для всех объектов в сообщении LinkSummary бит N должен быть сброшен (0) для индикации того, что параметры не согласуются. Это обеспечивает отображения между локальными/удаленными Link_Id и Interface_Id, параметры соответствующих каналов данных и индикацию каналов данных, выделенных для пользовательского трафика. Когда узел получает сообщение LinkSummary, он проверяет локальную конфигурацию. Если узел способен сохранить информацию о канале LMP при перезапуске, он должен обработать сообщение LinkSummary в соответствии с разделом 4, но флаг выделения (allocated/de-allocated) в объекте DATA_LINK из принятого сообщения LinkSummary должен получать предпочтение по сравнению с любым локальным значением. Однако, если узел не способен сохранить информацию канала LMP при перезапуске, он должен воспринять параметры каналов данных из сообщения LinkSummary и ответить сообщением LinkSummaryAck.

По завершении обмена LinkSummary узлу, выполнявшему перезапуск управления, следует отправить сообщение ChannelStatusRequest для канала TE. Узлу следует также проверить связность всех не выделенных каналов.

9. Адресация

Все сообщения LMP передаются по протоколу UDP через порт LMP (за исключением в некоторых случаях сообщений Test, которые могут быть ограничены транспортным механизмом для передачи сообщений в основной полосе — in-band). Адресом получателя пакета IP может быть адрес, полученный в процедуре Configuration (т. е., адрес отправителя из заголовка пакета с сообщением Config), адрес IP, заданный в конфигурации удаленного узла или Node_Id. Сообщение Config является исключением, как отмечено выше.

Манера адресации для сообщений Config может зависеть от транспортного механизма сигнализации. При использовании канала «точка-точка» сообщения Config следует направлять по групповому адресу (224.0.0.1 или ff02::1). В остальных случаях сообщения Config должны направляться по IP-адресу соседнего узла. Этот адрес может задаваться в конфигурации на обеих сторонах канала управления или определяться автоматически.

10. Процедуры экспоненциального роста интервалов повтора

Этот раздел основан на [RFC2961] и описывает процедуры экспоненциального роста интервалов повторной передачи. Реализации должны использовать описанные процедуры или их эквивалент.

10.1. Работа

Ниже описан один из возможных механизмов экспоненциального увеличения интервалов повтора неподтвержденных сообщений LMP. Передающий узел повторяет сообщение, пока не будет получено подтверждение или достигнуто предельное число повторов. Получив подтверждение, передающий узел прекращает отправку повторов. Интервал между повторными сообщениями определяется таймером ускоренного повтора (rapid retransmission timer). Отчсет этого таймера начинается с небольшого значения, а потом интервал экспоненциально увеличивается вплоть до установленного максимума.

Ниже описаны параметры, которые будут полезны для управления процедурой.

Интервал ускоренного повтора — Ri

Ri определяет интервал повтора передачи неподтвержденного сообщения. После отправки сообщения передающий узел будет повторять передачу (если нет подтверждения) через Ri мсек.

Предел ускоренного повтора — Rl

Rl определяет максимальное число повторов передачи неподтвержденного сообщения.

Увеличение интервала повтора Delta

Параметр Delta задает скорость, с которой отправитель увеличивает интервал повтора передачи. Отношение между двумя последовательными интервалами определяется значением (1 + Delta).

По умолчанию предлагается использовать начальный интервал (Ri) в 500 мсек с удвоением каждого следующего интервала (Delta = 1) и максимальным числом повторов 3.

10.2. Алгоритм повтора передачи

После передачи узлом сообщения, которое требует подтверждения, ему незамедлительно следует запланировать повтор передачи через интервал Ri. Если соответствующее подтверждение придет раньше, повтор передачи следует отменить. В противном случае сообщение передается заново по истечении интервала (1+Delta)*Ri12. Повтор передачи следует продолжать, пока не будет получено подтверждение или достигнуто предельное число повторов Rl.

Передающий узел может применять для повтора требующих подтверждения сообщений приведенный ниже алгоритм.

      Перед исходной передачей устанавливаются значения Rk = Ri и Rn = 0.
      пока (Rn++ < Rl) {
        передать сообщение;
        выждать Rk мсек;
        Rk = Rk * (1 + Delta);
      }
      /* подтверждение или отсутствие отклика от получателя за время Rl */
      выполнить всю требуемую очистку;
      выход;

Асинхронно, когда отправитель получает соответствующее подтверждение, он меняет значения счетчика повторов Rn на Rl.

Отметим, что передающий узел не анонсирует и не согласует использование описанной выше процедуры увеличесния интервала в сообщениях Config или LinkSummary.

11. Машины конечных состояний LMP

11.1. FSM управляющего канала

Машина конечных состояний (FSM) канала управления определяет состояния и логику работы канала управления LMP.

11.1.1. Состояния управляющего канала

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

Down

Это начальное состояние канала управления. В этом состоянии не предпринимается попыток активизации канала управления и передачи сообщений. Для параметров канала управления следует установить начальные значения.

ConfSnd

Канал находится в состоянии согласования параметров. В этом состоянии узел периодически отправляет сообщения Config, ожидая от удаленной стороны ответа в форме сообщения ConfigAck или ConfigNack. FSM не переходит в активное (Active) состояние, пока удаленная сторона не подтвердит параметры.

ConfRcv

Канал находится в состоянии согласования параметров. В этом состоянии узел ждет подходящих конфигурационных параметров от удаленной стороны. После получения и подтверждения этих параметров FSM может переходить в состояние Active.

Active

В этом состоянии узел периодически отправляет сообщения Hello и ждет в ответ приемлемых сообщений Hello. После приема приемлемого сообщения Hello канал может переходить в рабочее (Up) состояние.

Up

Канал управления находится в рабочем состоянии. Узел получает приемлемые сообщения Hello и передает свои сообщения Hello.

GoingDown

Канал управления может перейти в это состояние в результате действий администратора. Пока канал находится в этом состоянии, узел устанавливает бит ControlChannelDown во всех отправляемых сообщениях.

11.1.2. События канала управления

Работа канала управления LMP описывается состояниями и событиями FSM. События порождаются нижележащими протоколами и программными модулями, а также процедурами обработки пакетов и FSM соответствующих каналов TE. Каждое событие имеет номер и символьное имя. Описания событий канала управления приведены ниже.

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

    1. передача сообщения Config;

    2. ожидание приема сообщения Config от удаленного узла.

  2. EvCCDn — это событие возникает при наличии индикации недоступности канала управления.

  3. EvConfDone — это событие показывает прием сообщения ConfigAck, подтверждающего параметры из Config.

  4. EvConfErr — это событие показывает прием сообщения ConfigNack, отвергающего параметры из Config.

  5. EvNewConfOK — новое сообщение Config было принято от соседа и подтверждено ConfigAck.

  6. evNewConfErr — новое сообщение Config было принято от соседа и отвергнуто с передачей ConfigNack.

  7. evContenWin — новое сообщение Config было принято от соседа и в тот же момент соседу было передано сообщение Config. Локальный узел «выиграл состязание» и принятое сообщение Config игнорируется.

  8. evContenLost — новое сообщение Config было принято от соседа и в тот же момент этому соседу было передано сообщение Config. Локальный узел «проиграл состязание».

      1. Сообщение Config подтверждено ConfigAck;

      2. Сообщение Config отвергнуто ConfigNack.

  9. EvAdminDown администратор запросил отключить канал управления административно.

  10. EvNbrGoesDn — от соседа получен пакет с флагом ControlChannelDown.

  11. EvHelloRcvd — получен пакет Hello с ожидаемым значением SeqNum.

  12. EvHoldTimer — завершился отсчет таймера HelloDeadInterval при отсутствии пакетов Hello, что переводит канал управления назад в состояние Negotiation и инициирует один из вариантов (в зависимости от конфигурации)

        1. периодическая отправка сообщений Config;

        2. ожидание сообщений Config от удаленного узла.

  13. EvSeqNumErr — получено сообщение Hello с неожиданным SeqNum, сообщение отброшено.

  14. EvReconfig — параметры канала управления были изменены и требуется новое согласование.

  15. EvConfRet — завершился отсчет таймера повтора и сообщение Config передано снова.

  16. evHelloRet — завершился отсчет таймера HelloInterval и сообщение Hello передано снова.

  17. evDownTimer — завершился отсчет таймера, но не было получено ни одного сообщения с флагом ControlChannelDown.

11.1.3. Описание FSM канала управления

На рисунке 3 показана работа FSM канала управления в форме диаграммы состояний FSM.

                               +--------+
            +----------------->|        |<--------------+
            |       +--------->|  Down  |<----------+   | 
            |       |+---------|        |<-------+  |   |
            |       ||         +--------+        |  |   |
            |       ||           |    ^       2,9| 2|  2|
            |       ||1b       1a|    |          |  |   |
            |       ||           v    |2,9       |  |   |
            |       ||         +--------+        |  |   |
            |       ||      +->|        |<------+|  |   | 
            |       ||  4,7,|  |ConfSnd |       ||  |   | 
            |       || 14,15+--|        |<----+ ||  |   |
            |       ||         +--------+     | ||  |   |
            |       ||       3,8a| |          | ||  |   |
            |       || +---------+ |8b  14,12a| ||  |   |
            |       || |           v          | ||  |   |
            |       |+-|------>+--------+     | ||  |   | 
            |       |  |    +->|        |-----|-|+  |   | 
            |       |  |6,14|  |ConfRcv |     | |   |   | 
            |       |  |    +--|        |<--+ | |   |   | 
            |       |  |       +--------+   | | |   |   |
            |       |  |          5| ^      | | |   |   |
            |       |  +---------+ | |      | | |   |   |
            |       |            | | |      | | |   |   |
            |       |            v v |6,12b | | |   |   |
            |       |10        +--------+   | | |   |   |
            |       +----------|        |   | | |   |   |
            |       |       +--| Active |---|-+ |   |   |
       10,17|       |   5,16|  |        |-------|---+   |
        +-------+ 9 |   13  +->|        |   |   |       | 
        | Going |<--|----------+--------+   |   |       | 
        | Down  |   |           11| ^       |   |       | 
        +-------+   |             | |5      |   |       | 
            ^       |             v |  6,12b|   |       | 
            |9      |10        +--------+   |   |12a,14 | 
            |       +----------|        |---+   |       | 
            |                  |   Up   |-------+       | 
            +------------------|        |---------------+ 
                               +--------+ 
                                 |   ^ 
                                 |   | 
                                 +---+ 
                                11,13,16 

Рисунок 3. Диаграмма состояний FSM канала управления.

 

Событие evCCDn всегда переводит FSM в состояние Down, события evHoldTimer и evReconfig всегда переводят FSM в состояние Negotiation (ConfSnd или ConfRcv).

11.2. FSM канала TE

Машина конечных состояний TE Link FSM определяет состояния и логику работы LMP TE Link.

11.2.1. Состояния канала TE

Канал TE в LMP может находиться в одном из описанных ниже состояний. Каждое состояние соответствует некоторым условиям в канале TE и обычно связано с конкретными типами сообщений LMP, которые периодически передаются на удаленную сторону через соответствующий канал управления или в основной полосе через каналы данных.

Down

Для канала TE еще не выделено каналов данных.

Init

Для канала TE выделены каналы данных, но конфигурация еще не синхронизирована с соседом LMP. Соседу LMP периодически отправляются сообщения LinkSummary.

Up

Это нормальное рабочее состояние канала TE. Для работы между узлами, использующими канал TE, требуется организация хотя бы одного канала управления LMP. В процессе нормальной работы соседу LMP могут передаваться сообщения LinkSummary, генерируемые периодически или по внешним запросам.

Degraded

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

11.2.2. События каналов TE

Работа канала LMP TE описывается состояниями и событиями FSM. События канала TE порождаются программами обработки пакетов и машинами FSM соответствующих каналов управления и каналов данных. Каждое событие имеет номер и символьное имя, приведенные ниже.

  1. EvDCUp — один или множество каналов данных включены и связаны с каналом TE.

  2. EvSumAck — получено и подтверждено сообщение LinkSummary.

  3. EvSumNack — получено и отвергнуто сообщение LinkSummary.

  4. evRcvAck — получено сообщение LinkSummaryAck, подтверждающее конфигурацию TE Link.

  5. evRcvNack — получено сообщение LinkSummaryNack.

  6. evSumRet — завершился отсчет таймера повтора и сообщение LinkSummary передано снова.

  7. evCCUp — включен первый активный канал управления.

  8. evCCDown — отключен последний активный канал управления.

  9. evDCDown — удален последний канал данных TE Link.

11.2.3. Описание машины конечных состояний канала TE

На рисунке 4 показана работа машины конечных состояний LMP TE Link в форме диаграммы смены состояний FSM.

                                  3,7,8
                                   +--+
                                   |  |
                                   |  v
                                +--------+
                                |        |
                  +------------>|  Down  |<---------+
                  |             |        |          |
                  |             +--------+          |
                  |                |  ^             |
                  |               1|  |9            |
                  |                v  |             |
                  |             +--------+          |
                  |             |        |<-+       |
                  |             |  Init  |  |3,5,6  |9
                  |             |        |--+ 7,8   |
                 9|             +--------+          |
                  |                  |              |
                  |               2,4|              |
                  |                  v              |
               +--------+   7   +--------+          |
               |        |------>|        |----------+
               |  Deg   |       |   Up   |
               |        |<------|        |
               +--------+   8   +--------+
                                   |  ^
                                   |  |
                                   +--+
                                 2,3,4,5,6

Рисунок 4. Диаграмма состояний FSM канала LMP TE.


На рисунке 4 субсостояния, возникающие в процессе выполнения процедуры проверки каналов, опущены.

11.3. FSM канала данных

FSM определяет состояния и логику работы канала данных в рамках канала LMP TE. Работа канала данных описывается состояниями и событиями FSM. Каналы данных могут находиться в активном (передача), когда через них передаются сообщения Test, или в пассивном (прием), когда сообщения Test передаются через них. Для обеспечения ясности приведены две FSM для активного и пассивного режима, а набор состояний и событий определен один.

11.3.1. Состояния канала данных

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

Down

Канал данных не включен в пул ресурсов (т. е., канал не обслуживается).

Test

Канал данных тестируется и через него периодически передаются сообщения LMP Test.

PasvTest

Канал данных был проверен входящими тестовыми сообщениями.

Up/Free

Канал данных успешно протестирован и сейчас включен в пул ресурсов (обслуживается). Однако канал еще не выделен для передачи трафика.

Up/Alloc

Канал выделен для передачи трафика.

11.3.2. События канала данных

События канала данных создаются программами обработки пакетов и FSM связанного канала управления и канала TE.

Каждое событие имеет номер и символьное имя, представленные ниже.

  1. evCCUp — поднят (up) первый активный канал управления.

  2. evCCDown — потеряна связность с соседом LMP. Это говорит об отказе на последнем канале управления LMP между соседними узлами.

  3. evStartTst — внешнее событие, включающее передачу сообщений Test через канал данных.

  4. evStartPsv — внешнее событие, включающее прослушивание (прием) сообщений Test через канал данных.

  5. evTestOK — проверка канала завершилась успехом и этот канал может использоваться для организации пути.

    1. Это событие говорит об успешном завершении процедуры Link Verification (раздел 5) для данного канала и получении через канал управления сообщения TestStatusSuccess.

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

  6. evTestRcv — было получено сообщение Test через порт данных и передано сообщение TestStatusSuccess в канал управления.

  7. evTestFail — отрицательный результат процедуры проверки канала, который мог быть обусловлен (a) получением сообщения TestStatusFailure или (b) завершением процедуры проверки без приема сообщения TestStatusSuccess или TestStatusFailure для канала данных.

  8. evPsvTestFail — отрицательный результат процедуры проверки канала, который показывает, что сообщение Test не было обнаружено и (a) время VerifyDeadInterval истекло или (b) процедура проверки завершилась до истечения времени VerifyDeadInterval.

  9. evLnkAlloc — канал данных выделен.

  10. evLnkDealloc — выделение канала данных отменено.

  11. evTestRet — завершился отсчет таймера повтора и сообщение Test передано заново.

  12. evSummaryFail — LinkSummary не соответствует порту данных.

  13. evLocalizeFail — для этого канала данных был обнаружен (локализован) отказ.

  14. evdcDown — канал данных больше не доступен.

11.3.3. Описание FSM активного канала данных

На рисунке 5 показана работа FSM активного канала данных LMP в форме диаграммы смены состояний FSM.

           +------+
           |      |<-------+
+--------->| Down |        |
|     +----|      |<-----+ |
|     |    +------+      | |
|     |5b   3|  ^        | |
|     |      |  |7       | |
|     |      v  |        | |
|     |    +------+      | |
|     |    |      |<-+   | |
|     |    | Test |  |11 | |
|     |    |      |--+   | |
|     |    +------+      | |
|     |     5a| 3^       | |
|     |       |  |       | |
|     |       v  |       | |
|12   |   +---------+    | |
|     +-->|         |14  | |
|         | Up/Free |----+ |
+---------|         |      |
          +---------+      |
             9| ^          |
              | |          |
              v |10        |
          +---------+      |
          |         |13    |
          |Up/Alloc |------+
          |         |
          +---------+

Рисунок 5. FSM активного канала данных.


11.3.4. Описание FSM пассивного канала данных

На рисунке 6 показана работа FSM пассивного канала данных LMP в форме диаграммы смены состояний FSM.

            +------+
            |      |<------+
+---------->| Down |       |
|     +-----|      |<----+ |
|     |     +------+     | |
|     |5b    4|  ^       | |
|     |       |  |8      | |
|     |       v  |       | |
|     |    +----------+  | |
|     |    | PasvTest |  | |
|     |    +----------+  | |
|     |       6|  4^     | |
|     |        |   |     | |
|     |        v   |     | |
|12   |    +---------+   | |
|     +--->| Up/Free |14 | |
|          |         |---+ |
+----------|         |     |
           +---------+     |
               9| ^        |
                | |        |
                v |10      |
           +---------+     |
           |         |13   |
           |Up/Alloc |-----+
           |         |
           +---------+

Рисунок 6. FSM пассивного канала данных.


12. Форматы сообщений LMP

Все сообщения LMP (за исключением в некоторых случаях сообщений Test, которые могут быть ограничены транспортным механизмом передачи сообщений по основному каналу) передаются по протоколу UDP через порт LMP (701).

12.1. Общий заголовок

В дополнение к заголовку UDP и стандартному заголовку IP все сообщения LMP (за исключением в некоторых случаях сообщений Test, которые могут быть ограничены транспортным механизмом передачи сообщений по основному каналу) используют показанный ниже формат заголовков.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers  |      (резерв)         |    Flags      |    Msg Type   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          LMP Length           |          (резерв)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Все резервные (Reserved) поля следует устанавливать в 0 при передаче и игнорировать на приемной стороне.

Все значения указаны в сетевом порядке байтов (big-endian — сначала старший байт).

Vers (4 бита)

Номер версии протокола (1 для текущей версии).

Flags (8 битов)

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

0x01: ControlChannelDown

0x02: LMP Restart

Этот бит устанавливается для индикации отказа на узле и потери состояния управления LMP. Флаг может быть сброшен в 0 при получении сообщения Hello со значением RcvSeqNum, равным локальному TxSeqNum.

Msg Type (8 битов)

Ниже перечислены определенные значения, все остальные значения являются резервными.

1 = Config

2 = ConfigAck

3 = ConfigNack

4 = Hello

5 = BeginVerify

6 = BeginVerifyAck

7 = BeginVerifyNack

8 = EndVerify

9 = EndVerifyAck

10 = Test

11 = TestStatusSuccess

12 = TestStatusFailure

13 = TestStatusAck

14 = LinkSummary

15 = LinkSummaryAck

16 = LinkSummaryNack

17 = ChannelStatus

18 = ChannelStatusAck

19 = ChannelStatusRequest

20 = ChannelStatusResponse

Все сообщения, передаются через канал управления, за исключением сообщений Test, которые передаются через тестируемый канал данных.

LMP Length (16 битов)

Общий размер данного сообщения LMP в байтах с учетом общего заголовка и последующих объектов переменного размера.

12.2. Формат объекта LMP

Сообщения LMP создаются с использованием объектов, каждый из которых идентифицируется классом (Object Class) и типом (Class-type). Каждый объект имеет имя, которое в данном документе всегда указывается заглавными буквами. Объекты LMP могут быть согласуемыми или несогласуемыми (указывается битом N в заголовке объекта). Согласуемые объекты могут использоваться для того, чтобы устройства могли согласовать некие значения. Несогласуемые объекты служат для анонсирования конкретных значений, которые не нужно или невозможно согласовать.

Все значения указываются в сетевом порядке байтов (т. е., big-endian).

Формат объекта LMP показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|   C-Type    |     Class     |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                     (содержимое объекта)                    //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

N (1 бит)

Флаг N указывает возможность согласования объекта (N=1).

C-Type (7 битов)

Значение Class-type, уникальное в данном Object Class. Значения типов определены в разделе 13.

Class (8 битов)

Поле Class указывает тип объекта. Каждый объект имеет имя, которое в данном документе всегда указывается заглавными буквами.

Length (16 битов)

Указывает размер объекта в байтах с учетом полей N, C-Type, Class и Length.

12.3. Сообщения при согласовании параметров

12.3.1. Сообщение Config (Msg Type = 1)

Сообщения Config используются в фазе согласования канала управления LMP. Содержимое сообщений Config создается с использованием объектов LMP. Формат сообщения Config показан ниже.

   <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> <LOCAL_NODE_ID> <CONFIG>

Указанный выше порядок объектов следует соблюдать.

Объект MESSAGE_ID находится с зоне действия объекта LOCAL_CCID.

Сообщения Config должны передаваться периодически, пока не будет (1) получено сообщение ConfigAck или ConfigNack, (2) достигнуто предельное число повторов при отсутствии ConfigAck или ConfigNack или (3) получено сообщение Config от удаленного узла и «состязание» было проиграно (например, Node_Id удаленного узла больше локального Node_Id). Интервал повтора и предельное число попыток задаются в локальной конфигурации.

12.3.2. Сообщение ConfigAck (Msg Type = 2)

Сообщения ConfigAck служат для подтверждения приема сообщений Config и говорят о согласии со всеми предложенными в них параметрами.

   <ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
                           <REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>

Указанный выше порядок объектов следует соблюдать.

Содержимое объектов REMOTE_CCID, MESSAGE_ID_ACK и REMOTE_NODE_ID должно копироваться из подтверждаемого сообщения Config.

12.3.3. Сообщение ConfigNack (Msg Type = 3)

Сообщения ConfigNack служат для подтверждения приема сообщений Config и говорят о несогласии с предложенными (несогласуемыми) параметрами или предлагают другие значения для согласуемых параметров. Параметры, по которым имеется согласие, недопустимо включать в сообщение ConfigNack Message. Формат сообщения ConfigNack показан ниже.

   <ConfigNack Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID> <REMOTE_CCID>
                            <MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>

Указанный выше порядок объектов следует соблюдать.

Содержимое объектов REMOTE_CCID, MESSAGE_ID_ACK и REMOTE_NODE_ID должно копироваться из отвергаемого сообщения Config.

В сообщении Config может оказаться множество неприемлемых параметров.

Если в сообщение ConfigNack включен объект CONFIG для согласуемых параметров, он должен содержать приемлемые значения этих параметров.

Если в сообщение ConfigNack включен объект CONFIG для несогласуемых параметров, он должен содержать копии из объектов CONFIG, полученных в сообщении Config.

Если полученное сообщение ConfigNack включает только согласуемые объекты CONFIG, в ответ следует передать новое сообщение SHOULD. В значениях объекта CONFIG в этом новом сообщении Config следует принимать во внимание приемлемые значения параметров из сообщения ConfigNack.

Если узел получает сообщение Config и распознает в нем объект CONFIG, но не распознает C-Type, в ответ должно быть передано сообщение ConfigNack, включающее неизвестный объект CONFIG.

12.4. Сообщение Hello (Msg Type = 4)

Формат сообщения Hello показан ниже.

   <Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>

Указанный выше порядок объектов следует соблюдать.

Сообщения Hello должны передаваться периодически, хотя бы 1 раз каждые HelloInterval мсек. Если в течение интервала HelloDeadInterval не было получено ни одного сообщения Hello, предполагается отказ канала управления.

12.5. Сообщения для проверки канала

12.5.1. Сообщение BeginVerify (Msg Type = 5)

Сообщение BeginVerify передается через канал управления и служит для инициирования процесса проверки канала. Формат сообщения показан ниже.

   <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
                             <MESSAGE_ID> [<REMOTE_LINK_ID>] <BEGIN_VERIFY>

Указанный выше порядок объектов следует соблюдать.

Для ограничения области действия Link Verification конкретным каналом TE Link поле Link_Id в объекте LOCAL_LINK_ID должно иметь ненулевое значение. Если это поле равно 0, каналы данных будут охватывать множество каналов TE и/или могут включать еще не организованный канал TE. В специальном случае установки локального значения Link_Id = 0 используется флаг Verify all Links объекта BEGIN_VERIFY для того, чтобы различить каналы данных, входящие во множество каналов TE, от тех каналов, которые еще не выделены для канала TE (см. раздел 5).

Если известно отображение между локальным и удаленным Link_Id, может включаться объект REMOTE_LINK_ID.

При включении объекта REMOTE_LINK_ID поле Link_Id в нем должно быть отлично от 0.

Сообщения BeginVerify должны передаваться периодически, пока (1) узел не получит сообщения BeginVerifyAck или BeginVerifyNack о восприятии или отказе от проверки или (2) не будет достигнуто предельное число повторов без BeginVerifyAck или BeginVerifyNack. Интервал и число повторов являются параметрами локальной конфигурации.

12.5.2. Сообщение BeginVerifyAck (Msg Type = 6)

При наличии готовности обрабатывать сообщения Test в ответ на прием сообщения BeginVerify должно передаваться сообщение BeginVerifyAck.

   <BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
                                <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK> <VERIFY_ID>

Указанный выше порядок объектов следует соблюдать.

Если отображение между локальным и удаленным Link_Id известно или может быть определено из сообщения BeginVerify, может включаться объект LOCAL_LINK_ID.

При включении объекта LOCAL_LINK_ID поле Link_Id в нем должно быть отлично от 0.

Содержимое объекта MESSAGE_ID_ACK должно копироваться из подтверждаемого сообщения BeginVerify.

Объект VERIFY_ID содержит уникальное в рамках узла значение, выделяемое создателем сообщения BeginVerifyAck. Это значение служит для уникальной идентификации проверочных процессов (Verification) от множества соседей LMP и/или параллельных процедур Test между парой соседей LMP.

12.5.3. Сообщение BeginVerifyNack (Msg Type = 7)

При отсутствии готовности или желания обрабатывать сообщения Test в ответ на прием сообщения BeginVerify должно передаваться сообщение BeginVerifyNack.

<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>] <MESSAGE_ID_ACK> <ERROR_CODE>

Указанный выше порядок объектов следует соблюдать.

Содержимое объекта MESSAGE_ID_ACK должно копироваться из отвергаемого сообщения BeginVerify.

Если процесс проверки не поддерживается, поле ERROR_CODE должно указывать, что процедура Link Verification не поддерживается.

Если процесс проверки поддерживается, но узел не способен начать процедуру, поле ERROR_CODE должно указывать Unwilling to verify. При получении BeginVerifyNack с таким значением ERROR_CODE узлу, инициировавшему BeginVerify, следует запланировать повтор BeginVerify по истечении Rf секунд (Rf задается локальным параметром).

Если механизм Verification Transport не поддерживается, поле ERROR_CODE должно указывать Unsupported verification transport mechanism.

Если удаленная установка Link_Id не поддерживается и содержимое объекта REMOTE_LINK_ID (из сообщения BeginVerify) не соответствует ни одному из заданных в конфигурации значений, поле ERROR_CODE должно указывать ошибку конфигурации Link_Id.

Если узел, получивший сообщение BeginVerify, распознает объект BEGIN_VERIFY, но не распознает C-Type, поле ERROR_CODE должно указывать Unknown object C-Type.

12.5.4. Сообщение EndVerify (Msg Type = 8)

Сообщение EndVerify передается через канал управления и служит для прерывания процесса тестирования канала. Сообщение EndVerify может передаваться в любой момент узлом, желающим прервать процедуру Verify. Формат сообщения показан ниже.

   <EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>

Указанный выше порядок объектов следует соблюдать.

Сообщения EndVerify передаются периодически, пока не будет (1) получено сообщение EndVerifyAck или (2) исчерпано число повторов без получения EndVerifyAck. Интервал повтора и число попыток задаются параметрами локальной конфигурации.

12.5.5. Сообщение EndVerifyAck (Msg Type = 9)

Сообщение EndVerifyAck передается через канал управления и служит для подтверждения окончания процесса проверки. Формат сообщения показан ниже.

   <EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <VERIFY_ID>

Указанный выше порядок объектов следует соблюдать.

Содержимое объекта MESSAGE_ID_ACK должно быть получено из подтверждаемого сообщения EndVerify.

12.5.6. Сообщение Test (Msg Type = 10)

Сообщение Test передается через канал данных и служит для проверки физической связности канала. Если явно не указано иное, эти сообщения должны передаваться по протоколу UDP, как и все остальные сообщения LMP. Формат сообщения Test показан ниже.

   <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>

Указанный выше порядок объектов следует соблюдать.

Отметим, что эти сообщения передаются через канал данных, а не канал управления. Механизм транспортировки сообщений Test согласуется с помощью поля Verify Transport Mechanism в объекте BEGIN_VERIFY и поля Verify Transport Response в объекте BEGIN_VERIFY_ACK (см. параграфы 13.8 и 13.9).

Локальный (передающий) узел передает данное сообщение Test периодически (по крайней мере один раз за каждые VerifyInterval мсек) в соответствующий канал данных, пока (1) не получит ответное сообщение TestStatusSuccess или TestStatusFailure по каналу управления от удаленного (отвечающего) узла или (2) не произойдет отказ на всех активных каналах управления между этими узлами. Удаленный узел будет передавать данное сообщение TestStatus через канал управления периодически, пока не получит соответствующее сообщение TestStatusAck или EndVerify.

12.5.7. Сообщение TestStatusSuccess (Msg Type = 11)

Сообщение TestStatusSuccess передается через канал управления и служит для передачи отображений между локальным Interface_Id и Interface_Id интерфейса, принявшего сообщение Test.

   <TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID> <MESSAGE_ID>
                                   <LOCAL_INTERFACE_ID> <REMOTE_INTERFACE_ID> <VERIFY_ID>

Указанный выше порядок объектов следует соблюдать.

Содержимое объекта REMOTE_INTERFACE_ID должно браться из подтверждаемого сообщения Test.

12.5.8. Сообщение TestStatusFailure (Msg Type = 12)

Сообщение TestStatusFailure передается через канал управления и служит для для индикации того, что сообщение Test не было получено.

   <TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID>

Указанный выше порядок объектов следует соблюдать.

12.5.9. Сообщение TestStatusAck (Msg Type = 13)

Сообщение TestStatusAck служит для подтверждения приема сообщения TestStatusSuccess или TestStatusFailure.

   <TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <VERIFY_ID>

Указанный выше порядок объектов следует соблюдать.

Содержимое объекта MESSAGE_ID_ACK должно браться из подтверждаемого сообщения TestStatusSuccess или TestStatusFailure.

12.6. Сообщения о состоянии канала

12.6.1. Сообщение LinkSummary (Msg Type = 14)

Сообщения LinkSummary служат для синхронизации Interface_Id и сопоставления свойств каналов TE. Формат LinkSummary показан ниже.

<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK> <DATA_LINK> [<DATA_LINK>...]

Указанный выше порядок объектов следует соблюдать.

Обмен сообщениями LinkSummary может происходить в любой момент, когда на канале не выполняется процесс Verification. Сообщения LinkSummary должны передаваться периодически, пока (1) узел не получит ответного сообщения LinkSummaryAck или LinkSummaryNack или (2) не будет достигнуто предел повторов без получения LinkSummaryAck или LinkSummaryNack. Интервал передачи и число повторов задаются в локальной конфигурации.

12.6.2. Сообщение LinkSummaryAck (Msg Type = 15)

Сообщение LinkSummaryAck служит для индикации согласия на синхронизацию Interface_Id и восприятия/согласия всех параметров канала. Именно при получении этого сообщения локальный узел создает привязки Link_Id.

   <LinkSummaryAck Message> ::=  <Common Header> <MESSAGE_ID_ACK>

Указанный выше порядок объектов следует соблюдать.

12.6.3. Сообщение LinkSummaryNack (Msg Type = 16)

Сообщение LinkSummaryNack служит для индикации несогласия с несогласуемыми (non-negotiated) предложенными параметрами или предложения других значений согласуемых параметров. Параметры, со значениями которых узел согласен, недопустимо включать в сообщение LinkSummaryNack.

<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK> <ERROR_CODE> [<DATA_LINK>...]

Указанный выше порядок объектов следует соблюдать.

Объект данных DATA_LINK должен включать подходящие значения всех согласуемых параметров. Если LinkSummaryNack включает объекты DATA_LINK для несогласуемых параметров, они должны копироваться из объектов DATA_LINK в принятом сообщении LinkSummary.

Если полученное сообщение LinkSummaryNack включает лишь согласуемые параметры, в ответ следует отправить новое сообщение LinkSummary. Значения параметров из принятого сообщения LinkSummary следует принимать во внимание при включении подходящих параметров в новое сообщение LinkSummaryNack.

Если получено сообщение LinkSummary с неприемлемыми несогласуемыми параметрами, поле ERROR_CODE должно указывать Unacceptable non-negotiable LINK_SUMMARY parameters.

Если получено сообщение LinkSummary с неприемлемыми согласуемыми параметрами, поле ERROR_CODE должно указывать Renegotiate LINK_SUMMARY parameters.

Если получено сообщение LinkSummary с непригодным объектом TE_LINK, поле ERROR_CODE должно указывать Invalid TE_LINK object.

Если получено сообщение LinkSummary с непригодным объектом DATA_LINK, поле ERROR_CODE должно указывать Invalid DATA_LINK object.»

Если получено сообщение LinkSummary с объектом TE_LINK, но тип C-Type не известен, поле ERROR_CODE должно указывать Unknown TE_LINK object C-Type.

Если получено сообщение LinkSummary с объектом DATA_LINK, но тип C-Type не известен, поле ERROR_CODE должно указывать Unknown DATA_LINK object C-Type.

12.7. Сообщения контроля отказов

12.7.1. Сообщение ChannelStatus (Msg Type = 17)

Сообщение ChannelStatus передается через канал управления и служит для уведомления соседа LMP о состоянии канала данных. Получивший ChannelStatus узел должен ответить сообщением ChannelStatusAck. Формат ChannelStatus показан ниже.

   <ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID> <MESSAGE_ID> <CHANNEL_STATUS>

Указанный выше порядок объектов следует соблюдать.

Если объект CHANNEL_STATUS не содержит ни одного Interface_Id, это говорит об отказе канала TE целиком.

12.7.2. Сообщение ChannelStatusAck (Msg Type = 18)

Сообщение ChannelStatusAck служит для подтверждения приема ChannelStatus. Формат сообщения показан ниже.

   <ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

Указанный выше порядок объектов следует соблюдать.

Содержимое объекта MESSAGE_ID_ACK должно копироваться из подтверждаемого сообщения ChannelStatus.

12.7.3. Сообщение ChannelStatusRequest (Msg Type = 19)

Сообщения ChannelStatusRequest передаются через канал управления для запроса данных о состоянии одного или множества каналов данных. Принявший ChannelStatusRequest узел должен ответить сообщением ChannelStatusResponse. Формат ChannelStatusRequest показан ниже.

   <ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
                                      <MESSAGE_ID> [<CHANNEL_STATUS_REQUEST>]

Указанный выше порядок объектов следует соблюдать.

Если объект CHANNEL_STATUS_REQUEST не включен в сообщение, ChannelStatusRequest будет служить запросом состояния всех каналов данных в TE Link.

12.7.4. Сообщение ChannelStatusResponse (Msg Type = 20)

Сообщение ChannelStatusResponse служит для подтверждения приема ChannelStatusRequest и уведомления соседа LMP о состоянии каналов данных. Формат сообщения показан ниже.

   <ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK> <CHANNEL_STATUS>

Указанный выше порядок объектов следует соблюдать.

Содержимое объекта MESSAGE_ID_ACK должно копироваться из подтверждаемого сообщения ChannelStatusRequest.

13. Определения объектов LMP

13.1. Класс CCID (Control Channel ID)

Class = 1
C-Type = 1, LOCAL_CCID
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            CC_Id                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

CC_Id 32 бита

Это значение должно отличаться от 0 и быть уникальным в масштабе узла. CC_Id указывает канал управления, который отправитель связывает с сообщением.

Объект не согласуется.

C-Type = 2, REMOTE_CCID
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             CC_Id                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

CC_Id 32 бита

Это значение указывает CC_Id удаленного узла и должен отличаться от 0.

Объект не согласуется.

13.2. Класс NODE_ID

Class = 2
C-Type = 1, LOCAL_NODE_ID
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Node_Id (4 байта)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Node_Id

Это значение указывает узел, создавший пакет LMP.

Объект не согласуется.

C-Type = 2, REMOTE_NODE_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Node_Id (4 байта)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Node_Id

Это значение указывает удаленный узел.

Объект не согласуется.

13.3. Класс LINK_ID

Class = 3
C-Type = 1, IPv4 LOCAL_LINK_ID
C-Type = 2, IPv4 REMOTE_LINK_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link_Id (4 байта)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C-Type = 3, IPv6 LOCAL_LINK_ID
C-Type = 4, IPv6 REMOTE_LINK_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                        Link_Id (16 байтов)                    +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Type = 5, Unnumbered LOCAL_LINK_ID
C-Type = 6, Unnumbered REMOTE_LINK_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link_Id (4 байта)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Link_Id

Для LOCAL_LINK_ID указывает канал отправителя, связанный с сообщением, и должно быть отлично от 0.

Для REMOTE_LINK_ID указывает Link_Id удаленного узла и должно быть отлично от 0.

Объект не согласуется.

13.4. Класс INTERFACE_ID

Class = 4
C-Type = 1, IPv4 LOCAL_INTERFACE_ID
C-Type = 2, IPv4 REMOTE_INTERFACE_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interface_Id (4 байта)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Type = 3, IPv6 LOCAL_INTERFACE_ID
C-Type = 4, IPv6 REMOTE_INTERFACE_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Interface_Id (16 байтов)                +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Type = 5, Unnumbered LOCAL_INTERFACE_ID
C-Type = 6, Unnumbered REMOTE_INTERFACE_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface_Id (4 байта)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Interface_Id

Для LOCAL_INTERFACE_ID это значение указывает канал данных, оно должно отличаться от 0 и быть уникальным в масштабе узла.

Для REMOTE_INTERFACE_ID это значение указывает канал данных на удаленном узле и должно отличаться от 0.

Объект не согласуется.

13.5. Класс MESSAGE_ID

Class = 5
C-Type=1, MessageId
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message_Id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message_Id

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

Объект не согласуется.

C-Type = 2, MessageIdAck
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message_Id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message_Id

Поле Message_Id field служит для идентификации подтверждаемого сообщения и копируется из объекта MESSAGE_ID в этом сообщении.

Объект не согласуется.

13.6. Класс CONFIG

Class = 6.
C-Type = 1, HelloConfig
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         HelloInterval         |      HelloDeadInterval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

HelloInterval 16 битов

Указывает интервал между передачей последовательных пакетов Hello в миллисекундах.

HelloDeadInterval 16 битов

Если в течение интервала HelloDeadInterval не было принято пакетов Hello, предполагается отказ канала управления. Значение HelloDeadInterval указывается в миллисекундах. Значение HelloDeadInterval должно быть больше HelloInterval и его следует делать не меньше 3 * HelloInterval.

Если в LMP не применяется ускоренный механизм keep-alive, в полях HelloInterval и HelloDeadInterval должно быть установлено значение 0.

13.7. Класс HELLO

Class = 7
C-Type = 1, Hello
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           TxSeqNum                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           RcvSeqNum                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TxSeqNum 32 бита

Это поле указывает текущий порядковый номер для данного сообщения Hello. Это значение будет инкрементироваться, когда порядковый номер будет отражен поле RcvSeqNum пакета Hello, полученного через канал управления.

Значение TxSeqNum=0 не разрешается, TxSeqNum=1 служит для обозначения первого сообщения Hello, передаваемого через канал управления.

RcvSeqNum 32 бита

Указывает порядковый номер последнего сообщения Hello, принятого через канал управления. Значение RcvSeqNum=0 служит для обозначения того, что сообщений Hello еще не было получено.

Объект не согласуется.

13.8. Класс BEGIN_VERIFY

Class = 8
C-Type = 1
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags                      |         VerifyInterval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Number of Data Links                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    EncType    |   (резерв)    |  Verify Transport Mechanism   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       TransmissionRate                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Wavelength                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Резервные поля следует устанавливать в 0 при передаче и игнорировать при получении.

Flags 16 битов

Определенные в настоящее время флаги перечислены ниже.

0x0001 Verify all Links — проверить все каналы

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

0x0002 Data Link Type — тип канала данных

При установленном флаге будут проверяться порты, при сброшенном — компонентые соединения.

VerifyInterval 16 битов

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

Number of Data Links 32 бита

Указывает число проверяемых каналов данных.

EncType — 8 битов

Указывает тип кодирования для канала данных. Определенные значения EncType согласованы со значениями LSP Encoding Type из [RFC3471].

Verify Transport Mechanism 16 битов

Определяет транспортный механизм для сообщений Test. Область действия этой битовой маски ограничена для каждого типа кодирования. Локальный узел будет устанавливать биты, соответствующие разным механизмам, которые он может поддерживать для передачи тестовых сообщений LMP. Получатель выбирает подходящий механизм в сообщении BeginVerifyAck.

Ниже приведен флаг, определенный для всех типов кодирования, все остальные флаги зависят от Encoding Type.

0x8000 — Payload (тестовое сообщение будет передаваться в поле данных — payload)

Возможна передача сообщений Test в поле данных (payload). Сообщение Test передается в форме пакета IP, как описано выше.

TransmissionRate 32 бита

Указывает скорость передачи канала данных, через который будут отправляться сообщения Test. Скорость указывается в бит/с с использованием формата IEEE floating-point.

Wavelength 32 бита

Когда канал данных связан с портом или компонентным каналом, способным передавать на разных длинах волн (т. е. оптический порт с поддержкой диапазона длин волн), важно знать, на какой длине волны будет передаваться тестовое сообщение. Это значение соответствует длине волны, используемой для передачи сообщений Test, и имеет локальную значимость. Если используемая для передачи тестовых сообщений длина волны определена однозначно, в этом поле следует указывать значение 0.

13.9. Класс BEGIN_VERIFY_ACK

Class = 9
C-Type = 1
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      VerifyDeadInterval       |   Verify_Transport_Response   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

VerifyDeadInterval 16 битов

Если сообщение Test не было обнаружено в течение интервала VerifyDeadInterval, узел будет передавать сообщение TestStatusFailure для этого канала данных.

Verify_Transport_Response 16 битов

Получатель сообщения BeginVerify (и будущий получатель сообщений TEST) выбирает транспортный механизм из числа предложенных отправителем сообщений Test. В отклике для проверки транспорта должен устанавливаться один и только один бит.

Объект не согласуется.

13.10. Класс VERIFY_ID

Class = 10
C-Type = 1
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Verify_Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Verify_Id 32 бита

Это значение служит для того, чтобы отделить сообщения Test разных каналов TE и/или партнеров LMP. Значение уникально в масштабе узла и выделяется получателем сообщения BeginVerify.

Объект не согласуется.

13.11. Класс TE_LINK

Class = 11
C-Type = 1, IPv4 TE_LINK
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |                    (резерв)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local_Link_Id (4 байта)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote_Link_Id (4 байта)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C-Type = 2, IPv6 TE_LINK
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |                    (резерв)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Local_Link_Id (16 байтов)                +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Remote_Link_Id (16 байтов)               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Type = 3, Unnumbered TE_LINK
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |                    (резерв)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local_Link_Id (4 байта)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote_Link_Id (4 байта)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Резервные поля следует устанавливать в 0 при передаче и игнорировать при получении.

Flags 8 битов

Определенные к настоящему моменту флаги приведены ниже. Все остальные биты следует сбрасывать в 0 при передаче и игнорировать при получении.

0x01 — поддерживается контроль отказов:

0x02 — поддерживается проверка канала.

Local_Link_Id

Указывает Link_Id для локального узла и должен отличаться от 0.

Remote_Link_Id

Указывает Link_Id для удаленного узла и должен отличаться от 0.

13.12. Класс DATA_LINK

Class = 12
C-Type = 1, IPv4 DATA_LINK
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |                    (резерв)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Local_Interface_Id (4 байта)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Remote_Interface_Id (4 байта)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C-Type = 2, IPv6 DATA_LINK
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |                    (резерв)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                   Local_Interface_Id (16 байтов)              +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                   Remote_Interface_Id (16 bytes)              +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Type = 3, Unnumbered DATA_LINK
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |                    (резерв)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Local_Interface_Id (4 байта)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Remote_Interface_Id (4 байта)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Резервные поля следует устанавливать в 0 при передаче и игнорировать при получении.

Flags 8 битов

Определенные к настоящему моменту флаги приведены ниже. Все остальные биты следует сбрасывать в 0 при передаче и игнорировать при получении.

0x01 — тип интерфейса; флаг устанавливается для порта и сбрасывается для компонентного канала;

0x02 — распределенный канал; установленный флаг говорит о выделении канала для пользовательского трафика; при использовании одного Interface_Id для приемного и передающего каналов данных этот бит относится лишь к передающему интерфейсу;

0x04 — отказавший канал; установленный флаг говорит об отказе канала и его непригодности для пользовательского трафика.

Local_Interface_Id

Локальный идентификатор канала данных. Должен быть уникальным в масштабе узла и отличным от 0.

Remote_Interface_Id

Удаленный идентификатор канала данных. Должен быть отличным от 0.

Subobjects

Содержимое объекта DATA_LINK включает последовательность элементов данных переменного размера, называемых субобъектами (определены ниже в параграфе 13.12.1).

Объект DATA_LINK может включать более одного субобъекта. Может присутствовать несколько субобъектов одного типа, если для канала поддерживается множество свойств (capability).

13.12.1. Субобъекты канала данных

Содержимое объекта DATA_LINK включает последовательность элементов данных переменного размера, называемых субобъектами, форма которых показана ниже.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
   |    Type       |    Length     |    (содержимое субобъекта)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+

Type 8 битов

Поле Type указывает тип содержимого субобъекта. В настоящее время определены:

Type = 1, тип коммутации интерфейса;

Type = 2, длина волны.

Length 8 битов

Поле Length указывает размер субобъекта в байтах с учетом полей Type и Length. Значение поля Length должно быть кратно 4.

13.12.1.1. Субобъект типа 1 — тип коммутации интерфейса
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     | Switching Type|   EncType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Minimum Reservable Bandwidth                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Maximum Reservable Bandwidth                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Switching Type 8 битов

Служит для указания локального Interface Switching Type канала TE в соответствии с определением [RFC3471].

EncType 8 битов

Тип кодирования канала данных. Определенные значения EncType совместимы с LSP Encoding Type [RFC3471].

Minimum Reservable Bandwidth 32 бита

Максимальная резервируемая пропускная способность в бит/сек, указанная в формате IEEE floating point.

Maximum Reservable Bandwidth 32 бита

Минимальная резервируемая пропускная способность в бит/сек, указанная в формате IEEE floating point.

Если интерфейс поддерживает лишь одну скорость, максимальное и минимальное значения совпадают.

13.12.1.2. Субобъект типа 2 — длина волны
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |          (резерв)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Wavelength                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Резервное поле следует устанавливать в 0 при передаче и игнорировать при получении.

Wavelength 32 бита

Указывает значение длины волны для данного порта. Это поле имеет значимость только между парой соседей.

13.13. Класс CHANNEL_STATUS

Class = 13
C-Type = 1, IPv4 INTERFACE_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interface_Id (4 байта)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                     Channel Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interface_Id (4 байта)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                     Channel Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C-Type = 2, IPv6 INTERFACE_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Interface_Id (16 байтов)                +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                     Channel Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Interface_Id (16 байтов)                +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                     Channel Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Type = 3, Unnumbered INTERFACE_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface_Id (4 байта)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                     Channel Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface_Id (4 байта)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                     Channel_Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Active (A) — 1 бит

Указывает, что Channel выделен для пользовательского трафика и для канала данных следует использовать активный мониторинг.

Direction (D) 1 бит

Указывает направление (передача или прием) канала данных, заданного в объекте CHANNEL_STATUS. Установленный флаг говорит об использовании канала данных для передачи.

Channel_Status — 30 битов

Указывает состояние канала данных. Определенные значения приведены ниже, все прочие остаются в резерве.

1 Signal Okay (OK) — канал в рабочем состоянии.

2 Signal Degrade (SD) — некритичная ошибка, вызванная превышением порога BER, заданного конфигурацией.

3 Signal Fail (SF) — серьезные ошибки, включая (но не ограничиваясь) потерю сигнала (LOS13) или кадра (LOF14) и Line AIS.

Этот объект содержит один или множество идентификаторов Interface_Id, за которыми следует поле Channel_Status.

Для индикации состояния TE Link в целом должно указываться единственное значение Interface_Id = 0.

13.14. Класс CHANNEL_STATUS_REQUEST

Class = 14
C-Type = 1, IPv4 INTERFACE_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interface_Id (4 байта)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interface_Id (4 байта)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Этот объект содержит один или множество идентификаторов Interface_Id.

Поле Length этого объекта содержит значение 4 + 4N (в байтах), где N — число идентификаторов Interface_Id.

C-Type = 2, IPv6 INTERFACE_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Interface_Id (16 байтов)                +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Interface_Id (16 байтов)                +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Этот объект содержит один или множество идентификаторов Interface_Id.

Поле Length этого объекта содержит значение 4 + 16N (в байтах), где N — число идентификаторов Interface_Id.

C-Type = 3, Unnumbered INTERFACE_ID
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface_Id (4 байта)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface_Id (4 байта)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Этот объект содержит один или множество идентификаторов Interface_Id.

Поле Length этого объекта содержит значение 4 + 4N (в байтах), где N — число идентификаторов Interface_Id.

Объект не согласуется.

13.15. Класс ERROR_CODE

Class = 20
C-Type = 1, BEGIN_VERIFY_ERROR
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ERROR CODE                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Приведенные ниже битовые значения определены для сетевого порядка байтов (big-endian):

0x01 = процедура Link Verification не поддерживается;

0x02 = нежелание проверять;

0x04 = не поддерживается транспортный механизм проверки;

0x08 = ошибка конфигурации Link_Id;

0x10 = неизвестный объект C-Type.

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

Для индикации множества ошибок может быть установлено соответствующее множество битов.

Объект не согласуется.

Если сообщение BeginVerifyNack получено с Error Code 2, узлу-инициатору BeginVerify следует запланировать повторную передачу BeginVerify по истечении Rf (Rf является параметром локальной конфигурации).

C-Type = 2, LINK_SUMMARY_ERROR
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ERROR CODE                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Приведенные ниже битовые значения определены для сетевого порядка байтов (big-endian):

0x01 = неприемленые несогласуемые параметры LINK_SUMMARY;

0x02 =повторное согласование параметров LINK_SUMMARY;

0x04 = непригодный объект TE_LINK;

0x08 = непригодный объект DATA_LINK;

0x10 = неизвестный объект TE_LINK C-Type;

0x20 = неизвестный объект DATA_LINK C-Type.

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

Для индикации множества ошибок может быть установлено соответствующее множество битов.

Объект не согласуется.

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

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

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

[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, «Link Bundling in MPLS Traffic Engineering (TE)», RFC 4201, October 2005.

[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., «Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)», RFC 4202, October 2005.

[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, «RSVP Refresh Overhead Reduction Extensions», RFC 2961, April 2001.

[RFC2402] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 240215, November 1998.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 240616, November 1998.

[RFC2407] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 240717, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 24093, November 1998.

[RFC3471] Berger, L., Ed., «Generalized MPLS — Signaling Functional Description», RFC 3471, January 2003.

14.2. Дополнительная литература

[RFC3630] Katz, D., Kompella, K., and D. Yeung, «Traffic Engineering (TE) Extensions to OSPF Version 2», RFC 3630, September 2003.

[RFC3784] Smit, H. and T. Li, «Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)», RFC 3784, June 2004.

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 240118, November 1998.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, December 2001.

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

Существует множество атак, с которыми могут столкнуться протокольные сессии LMP. Ниже приведены несколько примеров:

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

  • злоумышленник может изменить пакеты управления в пути передачи;

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

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

В этом разделе описан механизм защиты LMP на основе IPsec.

15.1. Требования безопасности

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

  • Защита LMP должна обеспечивать проверку подлинности, целостность и предотвращение повторного использования пакетов (replay).

  • Для трафика LMP защита конфиденциальности не требуется. Нужна лишь проверка подлинности для обеспечения уверенности в том, что пакеты управления (пакеты, переданные через LMP Control Channel) исходили от нужного источника и не были изменены в процессе передачи. Для пакетов LMP Test, передаваемых через каналы данных, защита не требуется.

  • Для трафика LMP защита отождествления конечных точек LMP в общем случае не требуется.

  • Механизму защиту следует поддерживать четко определенные схемы управления ключами, которые следует проанализировать с точки зрения криптографии. Схемы управления ключами должны обеспечивать масштабирование и автоматизацию.

  • Используемые для проверки подлинности алгоритмы должны быть криптостойкими. Кроме того, протокол защиты должен поддерживать использование разных алгоритмов аутентификации и возможность их согласования.

15.2. Механизмы защиты

Стек протоколв IPsec служит для защиты коммуникаций между парой партнеров на сетевом уровне. Этот стек протоколов описан в документах по архитектуре IP Security [RFC2401], IKE [RFC2409], IPsec AH [RFC2402] и IPsec ESP [RFC2406]. Протокол IKE обеспечивает управления ключами в сетях IP, а протоколы AH и ESP служат для защиты трафика IP. IKE определен применительно к протоколу IP.

С учетом требований, приведенных в параграфе 15.1, реализациям рекомендуется в тех случаях, когда требуется защита для LMP, использовать IPsec в соответствии с приведенным ниже описанием.

  1. Реализациям LMP на основе протоколов IPsec следует поддерживать режим ручной установки ключей.

    Этот режим обеспечивает простой способ организации и диагностики функциональности IPsec.

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

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

  2. Должен поддерживаться протокол IPsec ESP с трейлерной аутентификацией в туннельном режиме.

  3. Реализации должны поддерживать протоколы аутентифицированного обмена ключами. Должен применяться протокол IKE [RFC2409] в качестве протокола обмена ключами, если партнеры согласовали динамическую установку ключей.

  4. Реализации должны использовать IPsec DOI [RFC2407].

  5. Для протокола IKE идентификаторы SA, согласованные в Quick Mode, представляют трафик, для которого партнеры согласовали защиту, и включают информацию о пространстве адресов, протоколе и портах.

    При работе LMP на основе IPsec рекомендуется включать в поля данных идентификаторов для режима Quick перечисленную ниже информацию.

    Идентификаторы должны иметь тип адресов IP, а в качестве значений идентификаторов следует указывать IP-адреса коммуникационных партнеров.

    В поле протокола должно быть указано UDP. В поле порта следует указывать значение 0 для индикации того, что номера портов следует игнорировать. Это подразумевает, что весь трафик UDP между партнерами будет передаваться через туннель IPsec. Если реализация поддерживает селекторы по номерам портов, это позволяет сделать селектор более точным, указав поле порта LMP. Однако, если партнер не использует селекторов по номерам портов, реализация должна вернуться к использованию в поле порта значения 0.

  6. Должен поддерживаться «агрессивный» режим согласования IKE.

    Когда взаимодействие с партнером настроено для использования IPsec, предполагается, что все сообщения LMP будут передаваться через туннель IPsec (криптоканал). Точно так же получателю LMP, настроенному на работу с использованием IPsec, следует отвергать весь трафик LMP, пришедший не из криптоканала.

    Криптоканал к соседу LMP может быть организован заранее или первое сообщение LMP, отправленное партнеру, инициирует создание туннеля IPsec.

    Через один криптоканал может быть организовано множество каналов управления. При использовании сообщений LMP Hello для контроля состояния канала управления важно принимать во внимание, что отказ keep-alive в канале управления может быть следствием отказа в криптоканале. Ниже описан метод, рекомендуемый для обеспечения корректной работы коммуникационного пути LMP.

    • Если LMP Hello говорит об отказе в канале управления, переключитесь на другой канал и/или попытайтесь организовать новый канал управления.

    • Обеспечьте работоспособность каналов управления с помощью сообщений LMP Hello. Если на всех каналах управления зафиксированы отказы и нет возможности создать новый канал управления, отключите (удалите) все имеющиеся каналы управления, а также криптоканал (IKE SA и все IPsec SA).

    • Организуйте криптоканал заново. Отказ при организации криптоканала служит индикатором невозможности коммуникаций LMP.

    • Активизируйте канал управления. Отказ при организации канала управления служит индикатором невозможности коммуникаций LMP.

    При динамическом обнаружении партнеров LMP (особенно инициаторов) следует принимать во внимание приведенные ниже замечания.

    При проверке подлинности с заранее распространенным ключом в режиме защиты подлинности (основной режим) общий ключ требуется для расчета значения SKEYID (служит для создания ключей, используемых для шифрования сообщений в процессе обмена ключами). В основном режиме (main mode) IKE заранее известный общий ключ должен быть идентифицирован до получения данных отождествления партнера. Такой общий требуется для расчета SKEYID. В этом момент единственной доступной информацией о партнере является адрес IP с которого выполняется согласование. Определение общего ключа по этоу адресу не представляется возможным, поскольку адреса являются динамическими и не известны заранее.

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

Однако следует отметить уязвимость агрессивного режима к пассивным атакам на службы. Использование общего секрета (групповой секрет) множеством партнеров настоятельно не рекомендуется, поскольку это открывает возможность для организации MITM19атак.

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

Если требуется проверка подлинности на основе заранее распространенного общего ключа (pre-shared key), следует применять агрессивный режим. Значения общих заранее распространенных ключей аутентификации IKE следует защищать, подобно паролям учетных записей пользователей.

16. Взаимодействие с IANA

Агентство IANA выделило номер 701 для порта LMP.

Ниже приведены рекомендации для IANA в части распределения значения в каждом пространстве имен LMP. Диапазоны распределяемых значений поделены на Private Use, Expert Review и Standards Action (в соответствии с [RFC2434]).

Распределение значений LMP из пространства Private Use (т. е., для частных расширений) не требуется документировать. Независимые реализации LMP, использующие одинаковые значения из пространства Private Use в общем случае не смогут взаимодействовать и следует принимать соответствующие меры при использовании таких значения в среде с продукцией разных производителей.

Распределение значений из пространств LMP по процедуре Expert Review осуществляется экспертами, назначенными IESG. Данный документ предполагает использование значений из этих диапазонов лишь для экспериментальных расширений и выделение значений должно сопровождаться RFC со статусом Experimental. Если такие расширения будут сочтены полезными для развертывания, их следует описать в RFC со статусом Standards Track и им должны быть выделены значения из диапазонов Standards Action.

Выделение значений из диапазонов LMP по процедуре Standards Action должно документироваться в Standards Track RFC, которые обычно подаются рабочими группами IETF и в любом случае должны соответствовать обучным процедурам IETF для документов со статусом Proposed Standards.

Резервные биты LMP Common Header следует распределять по процедуре Standards Action, в соответствии с правилами, описанными в [RFC2434].

LMP определяет несколько пространств имен, для которых требуется управление:

  • LMP Message Type (тип сообщения);

  • LMP Object Class (класс объекта);

  • LMP Object Class type (C-Type) (тип класса объектов, который уникален в рамках Object Class);

  • LMP Sub-object Class type (Type) (тип класса субобъектов, который уникален в рамках Object Class).

Пространство LMP Message Type следует распределять в соответствии с правилами, заданными в [RFC2434], — значения 0 — 127 распределяются по процедуре Standards Action, 128 — 240 по процедуре Expert Review, а 241 — 255 резервируются для Private Use.

Пространство LMP Object Class следует распределять в соответствии с правилами, заданными в [RFC2434], — значения 0 — 127 распределяются по процедуре Standards Action, 128 — 247 по процедуре Expert Review, а 248 — 255 резервируются для Private Use.

Правила распределения значений LMP Object Class являются частью определения конкретного класса. Определение Class должно включать описание правил выделения значений Object Class.

Правила распределения значений LMP Sub-object Class являются частью определения конкретного класса. Определение Class должно включать описание правил выделения значений для субобъектов.

Ниже перечислены пространства имен, выделенные IANA.

Пространство имен LMP Message Type.

Сообщение

Тип

Config

1

ConfigAck

2

ConfigNack

3

Hello

4

BeginVerify

5

BeginVerifyAck

6

BeginVerifyNack

7

EndVerify

8

EndVerifyAck

9

Test

10

TestStatusSuccess

11

TestStatusFailure

12

TestStatusAck

13

LinkSummary

14

LinkSummaryAck

15

LinkSummaryNack

16

ChannelStatus

17

ChannelStatusAck

18

ChannelStatusRequest

19

ChannelStatusResponse

20

Пространства имен LMP Object Class и Class type (C-Type)

CCID Class name (1)

Пространство типов CCID Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • LOCAL_CCID (C-Type = 1)

  • REMOTE_CCID (C-Type = 2)

NODE_ID Class name (2)

Пространство типов NODE ID Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • LOCAL_NODE_ID (C-Type = 1)

  • REMOTE_NODE_ID (C-Type = 2)

LINK_ID Class name (3)

Пространство типов LINK_ID Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • IPv4 LOCAL_LINK_ID (C-Type = 1)

  • IPv4 REMOTE_LINK_ID (C-Type = 2)

  • IPv6 LOCAL_LINK_ID (C-Type = 3)

  • IPv6 REMOTE_LINK_ID (C-Type = 4)

  • Unnumbered LOCAL_LINK_ID (C-Type = 5)

  • Unnumbered REMOTE_LINK_ID (C-Type = 6)

INTERFACE_ID Class name (4)

Пространство типов INTERFACE_ID Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • IPv4 LOCAL_INTERFACE_ID (C-Type = 1)

  • IPv4 REMOTE_INTERFACE_ID (C-Type = 2)

  • IPv6 LOCAL_INTERFACE_ID (C-Type = 3)

  • IPv6 REMOTE_INTERFACE_ID (C-Type = 4)

  • Unnumbered LOCAL_INTERFACE_ID (C-Type = 5)

  • Unnumbered REMOTE_INTERFACE_ID (C-Type = 6)

MESSAGE_ID Class name (5)

Пространство типов MESSAGE_ID Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • MESSAGE_ID (C-Type = 1)

  • MESSAGE_ID_ACK (C-Type = 2)

CONFIG Class name (6)

Пространство типов CONFIG Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • HELLO_CONFIG (C-Type = 1)

HELLO Class name (7)

Пространство типов HELLO Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • HELLO (C-Type = 1)

BEGIN_VERIFY Class name (8)

Пространство типов BEGIN_VERIFY Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • Type 1 (C-Type = 1)

BEGIN_VERIFY_ACK Class name (9)

Пространство типов BEGIN_VERIFY_ACK Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • Type 1 (C-Type = 1)

VERIFY_ID Class name (10)

Пространство типов VERIFY_ID Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • Type 1 (C-Type = 1)

TE_LINK Class name (11)

Пространство типов TE_LINK Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • IPv4 TE_LINK (C-Type = 1)

  • IPv6 TE_LINK (C-Type = 2)

  • Unnumbered TE_LINK (C-Type = 3)

DATA_LINK Class name (12)

Пространство типов DATA_LINK Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • IPv4 DATA_LINK (C-Type = 1)

  • IPv6 DATA_LINK (C-Type = 2)

  • Unnumbered DATA_LINK (C-Type = 3)

Пространство имен DATA_LINK Sub-object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 127 выделяются по процедуре Standards Action, 128 — 247 по процедуре Expert Review, а 248 — 255 резервируются для Private Use.

  • Interface Switching Type (sub-object Type = 1)

  • Wavelength (sub-object Type = 2)

CHANNEL_STATUS Class name (13)

Пространство типов CHANNEL_STATUS Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • IPv4 INTERFACE_ID (C-Type = 1)

  • IPv6 INTERFACE_ID (C-Type = 2)

  • Unnumbered INTERFACE_ID (C-Type = 3)

CHANNEL_STATUS_REQUESTClass name (14)

Пространство типов CHANNEL_STATUS_REQUEST Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • IPv4 INTERFACE_ID (C-Type = 1)

  • IPv6 INTERFACE_ID (C-Type = 2)

  • Unnumbered INTERFACE_ID (C-Type = 3)

ERROR_CODE Class name (20)

Пространство типов ERROR_CODE Object Class следует распределять в соответствии с правилами [RFC2434] — значения 0 — 111 выделяются по процедуре Standards Action, 112 — 119 по процедуре Expert Review, а 120 — 127 резервируются для Private Use.

  • BEGIN_VERIFY_ERROR (C-Type = 1)

  • LINK_SUMMARY_ERROR (C-Type = 2)

17. Благодарности

Авторы благодарны Andre Fredette за большой вклад в этот документ. Спасибо также Ayan Banerjee, George Swallow, Adrian Farrel, Dimitri Papadimitriou, Vinay Ravuri и David Drysdale за их значимые комментарии и предложения. Спасибо John Yu, Suresh Katukam и Greg Bernstein за их полезные предложения в части применимости канала управления в основной полосе (in-band).

18. Участники работы

Jonathan P. Lang

Sonos, Inc.

223 E. De La Guerra St.

Santa Barbara, CA 93101

EMail: jplang@ieee.org

Krishna Mitra

Independent Consultant

EMail: kmitra@earthlink.net

John Drake

Calient Networks

5853 Rue Ferrari

San Jose, CA 95138

EMail: jdrake@calient.net

Kireeti Kompella

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, CA 94089

EMail: kireeti@juniper.net

Yakov Rekhter

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, CA 94089

EMail: yakov@juniper.net

Lou Berger

Movaz Networks

EMail: lberger@movaz.com

Debanjan Saha

IBM Watson Research Center

EMail: dsaha@us.ibm.com

Debashis Basak

Accelight Networks

70 Abele Road, Suite 1201

Bridgeville, PA 15017-3470

EMail: dbasak@accelight.com

Hal Sandick

Shepard M.S.

2401 Dakota Street

Durham, NC 27705

EMail: sandick@nc.rr.com

Alex Zinin

Alcatel

EMail: alex.zinin@alcatel.com

Bala Rajagopalan

Intel Corp.

2111 NE 25th Ave

Hillsboro, OR 97123

EMail: bala.rajagopalan@intel.com

Sankar Ramamoorthi

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, CA 94089

EMail: sankarr@juniper.net

Информация для контактов

Jonathan P. Lang

Sonos, Inc.

829 De La Vina, Suite 220

Santa Barbara, CA 93101

EMail: jplang@ieee.org

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

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

nmalykh@protocols.ru

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

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.

1Traffic engineering — организация (построения) трафика.

2Link management protocol — протокол управления каналом.

3Dense wavelength division multiplexed — мультиплексирование по длине волны с высокой плотностью.

4Add-drop multiplexor — мультиплексор с ответвлением.

5Generalized MPLS — обобщенная коммутация по меткам.

6Time division multiplexed — мультиплексирование с разделением по времени.

7Wavelength division multiplexed — мультиплексирование с разделением по длине волны.

8Constrained SPF — поиск кратчайшего пути с учетом ограничений.

9Control Channel Id — идентификатор канала управления.

10Verify Transport Mechanism — механизм проверки транспорта.

11Loss of light.

12Так написано в оригинале, хотя это явно противоречит началу данного абзаца и приведенному ниже алгоритму. Указанное значение относится ко второму повтору, а не к первому, как написано в тексте. Прим. перев.

13Loss of signal.

14Loss of frame.

15Этот документ признан устаревшим и заменен RFC 4302 и RFC 4305. Прим. перев.

16Этот документ признан устаревшим и заменен RFC 4303 и RFC 4305. Прим. перев.

17Этот документ признан устаревшим и заменен RFC 4306. Прим. перев.

18Этот документ признан устаревшим и заменен RFC 4301. Прим. перев.

19Man-in-the-middle — атака с перехватом и изменением данных в пути при участии человека.




RFC 4202 Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)

Network Working Group                                   K. Kompella, Ed.
Request for Comments: 4202                              Y. Rekhter,  Ed.
Category: Standards Track                               Juniper Networks
                                                            October 2005

 

Расширение маршрутизации для поддержки GMPLS

Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)

PDF

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

В этом документе описан проект стандартного протокола Internet, предложенного сообществу Internet, документ служит приглашением к дискуссии в целях развития предложенного протокола. Текущее состояние стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.

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

Copyright (C) The Internet Society (2005).

Тезисы

В этом документе приведена спецификация расширения для поддержки передачи информации о состоянии канала для GMPLS1. Этот документ является дальнейшим развитием маршрутного расширения для поддержки MPLS TE2.

Оглавление

Исключено в версии HTML.

1. Введение

В этом документе приведена спецификация расширения для поддержки передачи информации о состоянии канала для обобщенной многопротокольной коммутации по меткам (GMPLS). Документ является дальнейшим развитием [ISIS-TE], [OSPF-TE], которое потребовалось для поддержки MPLS TE.

Традиционно соединения TE анонсируются, как «обычные» каналы, т. е. они создают маршрутную смежность и свойства активных соединений используются при расчетах кратчайших путей (SPF3) (прежде всего, метрики SPF), после чего свойства TE для соединения анонсируются.

GMPLS отказывается от такого подхода по трем причинам. Во-первых, канала, не способные принимать и передавать данные попакетно (packet-by-packet) могут, тем не менее, иметь свойства TE, однако маршрутной смежности от таких соединений не возникает. Во-вторых, путь с коммутацией по меткам (LSP4) может анонсироваться, как соединение TE типа «точка-точка» (см. [LSP-HIER]) и, таким образом, анонсируемое соединение TE может существовать между парой узлов, не имеющих маршрутной смежности между собой. В-третьих, множество соединений может анонсироваться, как один канал TE (например, в целях масштабирования) и здесь снова не возникает связи между обычной маршрутной смежностью и соединениями TE.

Таким образом, мы имеем более общее понятие канала TE, как «логического» соединения, имеющего свойства TE. Соединение является логическим в том смысле, что оно представляет способ группировки/отображения информации о неких физических ресурсах (и их свойствах) в данные, используемые Constrained SPF5 для расчета пути, а также для сигнализации GMPLS. Такое отображения/группировка должно выполняться согласованно на обеих сторонах соединения. Для проверки согласованности может использоваться протокол LMP [LMP].

В зависимости от природы ресурсов, формирующих конкретное соединение TE, для целей сигнализации GMPLS в некоторых случаях комбинации <идентификатор соединения TE, метка> достаточно для однозначного указания ресурсов, используемых LSP. В других случаях этой комбинации может оказаться недостаточно и для них используются связки каналов [LINK-BUNDLE], позволяющие идентифицировать ресурс с помощью набора <идентификатор соединения TE, идентификатор компонентного канала, метка>.

Некоторые свойства соединений TE могут быть заданы в конфигурации анонсирующих маршрутизаторов LSR6, а остальные могут быть получены от других LSR с помощью некого протокола, а также могут быть выведены из свойств компонентных соединений TE.

Соединение TE между парой LSR не предполагает наличия между этими маршрутизаторами маршрутной смежности (например, IGP). Как было отмечено выше, в некоторых случаях канал TE между парой LSR может анонсироваться даже при отсутствии маршрутной смежности между этими LSR (например, когда соединение TE организует смежность по пересылке — Forwarding Adjacency, как описано в [LSP-HIER]).

Канал TE должен иметь некоторые средства, с помощью которых анонсирующий LSR может узнать о «живости» соединения (это могут быть сообщения hello или иные средства). Когда LSR знает, что канал TE активен и может определить свойства TE для этого соединения, LSR может анонсировать такое соединение своим (обычным) соседям.

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

В документах [ISIS-TE] и [OSPF-TE] определены канонические свойства TE и описано, как связать свойства TE с обычными (коммутация пакетов) соединениями. Данный документ расширяет набор свойств TE и описывает, как связать свойства TE с каналами, не использующими коммутацию пакетов (non-packet-switched), — например, соединениями между оптическими кросс-коннекторами (OXC7). В [LSP-HIER] описано, как связать свойства TE с каналами, формируемыми LSP.

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

1.1. Требования к специфическим для уровня атрибутам TE

При обобщении каналов TE для включения традиционных транспортных средств имеются дополнительные факторы, влияющие на набор требуемой информации о канале TE. Эти факторы обусловлены существующей архитектурой транспортного уровня (например, рекомендации ITU-T G.805 и G.806) и связанными с ней службами. Некоторые из факторов перечислены ниже.

  1. Потребность в LSP для конкретного применения, а не просто обеспечения пропускной способности. Клиенты оптических сетей получают услуги для конкретных приложений, например, устройств VC-3. Это не только предполагает определенную пропускную способность, но и способ структурирования передаваемой информации. Клиента VC-3 не устроит никакой LSP, которые предлагает скорость, отличную от 48,384 Мбит/с, или иное структурирование потока данных. Следствием этого является необходимость поиска маршрута, который обеспечить соединение с требуемыми для конкретного применения свойствами.

  2. Различные варианты применения. Ресурсы между двумя OXC (в частности, трасса G.805) могут иной раз поддерживать одновременно разные варианты применения (адаптации) — пример этого описан в параграфе 2.4.8. В таких случаях факт поддержки двух вариантов применения на одной трассе весьма важен, поскольку два уровня являются зависимыми, а также по причине необходимости обеспечить возможность отображения отношений на данном уровне на маршрутизацию, особенно с учетом недостаточной гибкости транспортных уровней по сравнению с пакетными.

  3. Наследуемые атрибуты. Когда вся иерархия мультиплексирования поддерживается каналом TE, атрибут нижележащего уровня может оказаться применимым для вышележащих уровней. Примером этого могут служить атрибуты защиты. Если канал OC-192 использует защиту 1+1 (дублирующий канал OC-192 для защиты), то STS-3c в этом OC-192 (вышележащий уровень) будет наследовать такие же свойства защиты.

  4. Расширяемость уровней. В дополнение к имеющимся транспортным уровням в будущем могут быть определены новые уровни и приложения (адаптации).

  5. Неоднородные сети, где не все OXC поддерживают одинаковый набор уровней. В сети GMPLS не все элементы транспортной сети уровня могут поддерживать один набор уровней. Например, могут присутствовать коммутаторы, способные поддерживать только VC-11, VC-12 и VC-3, а также коммутаторы, поддерживающие лишь VC-3 и VC-4. Даже если элемент сети не поддерживает конкретный уровень, ему следует иметь возможность узнать, имеются ли где-либо в сети элементы, которые поддерживают адаптацию, позволяющую использовать этот не поддерживаемый уровень. Например, коммутатор VC-11 может использовать поддерживающий VC-3 коммутатор, если знает, что путь VC-11 может быть организован через канал VC-3.

С учетом перечисленных выше факторов при разработке специфических для определенного уровня документов по маршрутизации GMPLS следует использовать для атрибутов каналов TE перечисленные ниже требования.

  1. Разделение атрибутов. Атрибуты одного уровня отделяются от атрибутов других уровней.

  2. Поддержка внутриуровневых атрибутов (например, связи между применениями). Между клиентским и серверным уровнем существует общий механизм описания отношений. Например, «4 клиентских канала типа X могут поддерживаться данным серверным канальным уровнем». Другим примером служит возможность идентификации случаев использования двумя уровнями общего серверного уровня.

  3. Поддержка наследуемых атрибутов. Следует идентифицировать атрибуты, которые могут наследоваться.

  4. Расширяемость уровней. Атрибуты следует представлять в маршрутизации так, чтобы можно было приспособить в будущем новые уровни. Это похоже на обобщение понятия метки.

  5. Явное задание области действия атрибутов. Например, в каких случаях данный атрибут применим ко множеству каналов одного уровня.

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

1.2. Исключение трафика данных из каналов управления

Каналы управления между узлами сети GMPLS (такими, как кросс-коннекторы и/или маршрутизаторы OXC и SDH) обычно служат для передачи трафика управления и администрирования. Эти каналы анонсируются в систему маршрутизации в качестве обычных каналов, как отмечено в предыдущем параграфе, что позволяет маршрутизировать в них, например, сообщения RSVP и сессии telnet. Однако, если маршрутизаторы на краю оптической сети попытаются передавать обычные данные через такие каналы, возможности этих каналов будут полностью исчерпаны.

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

Если предположить, что трафик данных передается получателям BGP, а управляющий — получателям IGP, можно исключить передачу трафика данных на уровень управления, ограничивая выбор следующего интервала BGP (предполагается, что OXC не являются узлами BGP). Предположим, что маршрутизатор R пытается организовать маршрут к BGP-адресату D. R ищет следующий интервал BGP для D в своей таблице маршрутизации IGP. Предположим, что R находит путь к следующему интервалу через интерфейс I. Тогда R проверяет наличие в своей базе данных о состоянии каналов (Link State) записи, связанной с интерфейсом I. Если такая запись имеется и канал не поддерживает коммутацию пакетов (см. [LSP-HIER]), R отбрасывает этот маршрут к получателю D. В противном случае R организует (как обычно) маршрут к получателю D со следующим интервалом I. Отметим, что маршрутизатору R такая проверка нужна лишь в случае наличия у него каналов, не поддерживающих коммутацию пакетов, в случае поддержки коммутации пакетов на всех каналах такая проверка явно становится избыточной.

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

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

2. Развитие маршрутизации GMPLS

В этом разделе определяются усовершенствованные свойства TE каналов GMPLS TE. Представление этой информации в протоколе IS-IS задано в [GMPLS-ISIS], в протоколе OSPF — в [GMPLS-OSPF].

2.1. Поддержка безадресных соединений

Безадресными соединениями являются каналы типа «точка-точка». LSR на каждой стороне безадресного соединения присваивают такому каналу свой идентификатор. Эти идентификаторы представляют собой 32-битовые целые числа, отличные от 0 и уникальные в масштабе маршрутизатора LSR, который выделил значение идентификатора.

Рассмотрим (безадресное) соединение между маршрутизаторами A и B. LSR A выбирает идентификатор для канала и LSR B делает то же самое. С точки зрения A мы называем выделенное этим маршрутизатором значение «идентификатором локального канала» или просто «локальным идентификатором» (link local identifier или local identifier), а значение, выделенное маршрутизатором B — «идентификатором удаленного канала» или «удаленным идентификатором» (link remote identifier или remote identifier). С точки зрения B выделенный этим маршрутизатором идентификатор будет локальным, а выделенный маршрутизатором A — удаленным.

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

2.2. Тип защиты канала

Тип защиты канала (Link Protection Type) представляет имеющиеся возможности защиты этого соединения. Желательно передавать эту информацию так, чтобы она могла использоваться алгоритмом расчета пути для организации LSP с подходящими характеристиками защиты. Эта информация организуется иерархически и при организации пути обычно задается минимально приемлемый уровень защиты, а метод выбора пути служит для поиска пути, обеспечивающего защиту с уровнем не ниже указанного минимума.

Определяемые в данном документе схемы защиты представлены ниже в порядке роста уровня защиты.

Extra Traffic — дополнительный трафик

Тип Extra Traffic означает, что канал используется для защиты другого канала или каналов. LSP на канале этого типа будет теряться при отказе любого из защищаемых каналов.

Unprotected — без защиты

Тип Unprotected означает отсутствие других каналов, обеспечивающих защиту данного соединения. LSP на канале этого типа будет теряться при отказе канала.

Shared — общая защита

Тип Shared говорит о наличии одного или множества несвязанных (disjoint) каналов типа Extra Traffic, защищающих данный канал. Эти каналы типа Extra Traffic используются одним или множеством каналов типа Shared.

Dedicated 1:1 — выделенный канал для защиты

Тип защиты Dedicated 1:1 говорит о наличии одного выделенного, несвязанного (disjoint) канала типа Extra Traffic, защищающего данный канал.

Dedicated 1+1 — выделенный, неанонсируемый канал для защиты

Тип защиты Dedicated 1+1 говорит о наличии выделенного, несвязанного (disjoint) канала, служащего для защиты данного соединения. Однако защитный канал не анонсируется в базе данных о состоянии каналов и, следовательно, не доступен для маршрутизации LSP.

Enhanced — улучшенная защита

Тип защиты Enhanced говорит о наличии схемы, более надежной по сравнению с Dedicated 1+1 (например, 4 волокна BLSR/MS-SPRING), которая используется для защиты данного канала.

Тип защиты канала является необязательным и при его отсутствии в анонсах состояния канала (Link State Advertisement) остается неизвестным.

2.3. Информация SRLG

Множество каналов может создать «группу общего риска» (SRLG8), если они используют общий ресурс, отказ которого будет воздействовать на все каналы группы. Например, два волокна одного кабеля могут быть в одной группе SRLG. Канал может входить во множество групп SRLG. Таким образом, информация SRLG описывает набор групп SRLG, в которые входит данный канал. SRLG идентифицируется 32-битовым целым числом, которое уникально в рамках домена IGP. Информация SRLG представляет собой неупорядоченный список групп SRLG, в которые входит канал.

SRLG для пути LSP представляет собой объединение групп SRLG каналов, образующих LSP. SRLG группы каналов (bundled link) является объединением SRLG всех каналов-компонент.

Если маршрутизатору LSR требуется множество LSP с разной маршрутизацией к другому LSR, при расчете пути следует попытаться маршрутизировать пути так, чтобы они не включали общих каналов и группы SRLG для пути не были связанными.

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

Информация SRLG является необязательной и при ее отсутствии в анонсе состояния канала SRLG для канала остается неизвестной.

2.4. Дескриптор коммутации для интерфейса

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

Дескриптор коммутационных возможностей (дескриптор коммутации) интерфейса (Interface Switching Capability Descriptor) описывает поддерживаемые этим интерфейсом возможности коммутации. Для двухсторонних каналов коммутационные возможности интерфейсов определяются одинаково для обоих направлений.

Анонс Link State Advertisement для канала предает дескриптор(ы) коммутационных возможностей на ближней стороне канала (на стороне LSR, передающего анонс).

Маршрутизатор LSR, выполняющий расчет пути, использует базу данных о состояниях каналов (Link State Database) для определения двухстороннего или одностороннего характера каналов.

Для двухсторонних каналов LSR использует свою базу Link State Database для определения дескрипторов коммутации на удаленной стороне канала, поскольку для таких каналов дескрипторы на разных сторонах могут различаться.

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

Ниже перечислены определенные в этом документе режимы коммутации интерфейсов (Interface Switching Capability).

Коммутация пакетов-1 (PSC-1)

Коммутация пакетов-2 (PSC-2)

Коммутация пакетов-3 (PSC-3)

Коммутация пакетов-4 (PSC-4)

Коммутация кадров (L2SC10)

Мультиплексирование TDM (TDM11)

Коммутация по длине волны (LSC12)

Коммутация волокон (FSC13)

При отсутствии дескриптора коммутации для интерфейса предполагается дескриптор PSC-1.

Дескрипторы коммутационных возможностей интерфейсов служат новым ограничением при расчете путей LSP.

Безотносительно к коммутационным возможностям конкретного интерфейса значение Interface Switching Capability Descriptor всегда включает информацию о поддерживаемом интерфейсом кодировании. Определенные варианты кодирования совпадают с LSP Encoding из [GMPLS-SIG].

Интерфейс может иметь более одного дескриптора коммутации. Это применяется для работы с интерфейсами, поддерживающими разные режимы коммутации, интерфейсами со значениями Max LSP Bandwidth14, различающимися по уровню приоритета, и интерфейсами, поддерживающими дискретные значения пропускной способности.

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

2.4.1. Коммутация кадров или ячеек (L2)

Если интерфейс имеет тип L2SC, это означает, что узел, принимающий данные через этот интерфейс, может коммутировать принятые кадры на основе адресов канального уровня (layer 2). Например, интерфейс, связанный с каналом, который заканчивается на коммутаторе ATM, может рассматриваться, как L2SC.

2.4.2. Коммутация пакетов

Если интерфейс имеет тип PSC-1 — PSC-4, это означает, что узел, получающий данные через такой интерфейс может коммутировать полученные данные на уровне пакетов (packet-by-packet), используя метки, передаваемые в shim-заголовках [RFC3032]. Разные уровни PSC образуют иерархию LSP, туннелируемых через другие LSP.

Для интерфейсов PSC дополнительная информация включает максимальную и минимальную пропускную способность LSP (Maximum LSP Bandwidth, Minimum LSP Bandwidth) и значение MTU на интерфейсе.

Для простого (unbundled) канала Maximum LSP Bandwidth для приоритета p определяется значением меньше незарезервированной пропускной способности для уровня p и параметром Maximum LSP Size, который задается в локальной конфигурации канала и по умолчанию совпадает с Max Link Bandwidth. Максимальная пропускная способность для композитного (bundled) канала определена в [LINK-BUNDLE].

Maximum LSP Bandwidth занимает место параметра Maximum Link Bandwidth ([ISIS-TE], [OSPF-TE]). Однако Maximum Link Bandwidth представляет собой одно фиксированное значение (обычно просто полоса канала), Maximum LSP Bandwidth передается по уровням приоритета и может изменяться по мере организации и разрыва LSP.

Хотя параметр Maximum Link Bandwidth отменяется, для совместимости со старыми версиями можно устанавливать для него значение Maximum LSP Bandwidth для приоритета 7.

Параметр Minimum LSP Bandwidth указывает максимальную пропускную способность, которая может быть зарезервирована для LSP.

Типовые значения Minimum LSP Bandwidth и Maximum LSP Bandwidth приведены в документе [GMPLS-SIG].

На интерфейсе PSC, поддерживающем кодирование Standard SDH, LSP с приоритетом p может зарезервировать любую пропускную способность, разрешаемую иерархией ветви SDH, при этом листья и корень ветви будут определяться значениями Minimum LSP Bandwidth и Maximum LSP Bandwidth для приоритета p.

На интерфейсе PSC, поддерживающем кодирование Arbitrary SDH, LSP с приоритетом p может зарезервировать любую пропускную способность из диапазона от Minimum LSP Bandwidth до Maximum LSP Bandwidth для приоритета p, с учетом того, что резервируемая LSP пропускная способность кратна значению Minimum LSP Bandwidth.

Параметр Interface MTU определяет максимальный размер пакета, который может быть передан этим интерфейсом без фрагментирования.

2.4.3. Мультиплексирование TDM

Если интерфейс относится к типу TDM, это означает, что получающий данные через этот интерфейс узел может мультиплексировать и демультиплексировать каналы данных SDH.

Для интерфейсов TDM дополнительная информация включает Maximum LSP Bandwidth, сведения о поддержке Standard или Arbitrary SDH, а также Minimum LSP Bandwidth.

Для простого (unbundled) канала Maximum LSP Bandwidth для приоритета p определяется, как максимальная пропускная способность, которую может зарезервировать LSP с приоритетом p. Максимальная пропускная способность для композитного (bundled) канала определена в [LINK-BUNDLE].

Параметр Minimum LSP Bandwidth указывает минимальную пропускную способность, которую может резервировать LSP.

Типовые значения Minimum LSP Bandwidth и Maximum LSP Bandwidth приведены в документе [GMPLS-SIG].

На интерфейсе с мультиплексированием Standard SDH путь LSP с приоритетом p может зарезервировать любую пропускную способность, разрешаемую иерархией ветви SDH, при этом листья и корень ветви будут определяться значениями Minimum LSP Bandwidth и Maximum LSP Bandwidth для приоритета p.

На интерфейсе с мультиплексированием Arbitrary SDH путь LSP с приоритетом p может зарезервировать любую пропускную способность из диапазона от Minimum LSP Bandwidth до Maximum LSP Bandwidth для приоритета p, с учетом того, что резервируемая LSP пропускная способность кратна значению Minimum LSP Bandwidth.

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

На интерфейсе, поддерживающем множество ветвей иерархии мультиплексирования SDH, может анонсироваться множество дескрипторов коммутации (по одному на каждую ветвь). Например, для интерфейса, поддерживающего VC-11 и VC-12 (которые не является частью той же ветви иерархии SDH), будет анонсироваться два дескриптора.

2.4.4. Коммутация по длинам волн (Lambda)

Если интерфейс относится к типу LSC, это означает, что получающий данные через этот интерфейс узел может распознавать и коммутировать отдельные длины волн (lambda) на этом интерфейсе. Интерфейсы, поддерживающие единственную длину волны и коммутирующие только ее, относятся к типу LSC.

Дополнительная информация включает резервируемую полосу (Reservable Bandwidth) по уровням приоритета, которая задает пропускную способность LSP, которая может поддерживаться интерфейсом для данного уровня приоритета.

В случае поддержки множества скоростей передачи или вариантов кодирования в одном канале TE для интерфейса может анонсироваться множество дескрипторов коммутации (по одному на каждую комбинацию скорости кодирования). Например, интерфейс LSC может поддерживать организацию LSC LSP при скоростях STM-16 и STM-64.

2.4.5. Коммутация волокон

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

2.4.6. Поддержка множества типов коммутации на интерфейсе

Интрефейс, подключающий канал к маршрутизатору LSR, может поддерживать множество режимов коммутации (Interface Switching Capability). В качестве примера рассмотрим оптический канал, поддерживающий диапазон длин волн, который завершается на интерфейсе маршрутизатора LSR, способного коммутировать одну из длин волн в другой исходящий оптический канал, служить терминальным устройством для той или иной длины волны и демультиплексировать (извлекать) данные для определенной длины волны, используя TDM и коммутируя выделенные каналы TDM в другие исходящие каналы TDM. Для поддержки такого интерфейса анонсы состояния канала (Link State Advertisement) могут включать множество дескрипторов коммутации (Interface Switching Capabilities Descriptor).

2.4.7. Возможности коммутации и метки

Если обозначить канал TE дескрипторами коммутации на обеих сторонах соединения, примеры каналов могут иметь вид:

[PSC, PSC] — канал между двумя пакетными LSR;

[TDM, TDM] — канал между двумя цифровыми кросс-коннекторами;

[LSC, LSC] — канал между двумя OXC;

[PSC, TDM] — канал между пакетным LSR и цифровым кросс-коннектором;

[PSC, LSC] — канал между пакетным LSR и OXC;

[TDM, LSC] — канал между цифровым кросс-коннектором и OXC.

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

[PSC, PSC] — метка передается в shim-заголовке [RFC3032];

[TDM, TDM] — метка представляет временной интервал TDM [GMPLS-SONET-SDH];

[LSC, LSC] — метка представляет длину волны;

[FSC, FSC] — метка представляет порт OXC;

[PSC, TDM] — метка представляет временной интервал TDM [GMPLS-SONET-SDH];

[PSC, LSC] — метка представляет длину волны;

[PSC, FSC] — метка представляет порт;

[TDM, LSC] — метка представляет длину волны;

[TDM, FSC] — метка представляет порт;

[LSC, FSC] — метка представляет порт.

2.4.8. Прочие вопросы

Вполне возможно с течением времени изменение дескриптора коммутации, отражающее создание и удаление LSP. Например, LSP-пути VC-3, VC-4, VC-4-4c, VC-4-16c и VC-4-64c могут быть организованы на интерфейсе STM-64 с кодированием SDH. Изначально в дескрипторе коммутации будут установлены значения Minimum LSP Bandwidth = VC-3 и Maximum LSP Bandwidth = STM-64 для всех уровней приоритета. После организации на интерфейсе пути LSP размера VC-3 с приоритетом 1 он уже не будет поддерживать VC-4-64c для всех LSP, кроме тех, у кого задан приоритет 0. Следовательно, узел будет анонсировать дескриптор коммутации, показывающий, что максимальная пропускная способность LSP составляет уже не STM-64, а STM-16 для всех уровней приоритет, кроме 0 (для приоритета 0 сохранится Maximum LSP Bandwidth = STM-64). Если позднее будет организован другой VC-3 LSP, дескриптор коммутации не изменится. Этот дескриптор будет сохраняться, до того момент, когда узел уже не сможет организовать через этот интерфейс VC-4-16c LSP (это означает, что на интерфейсе уже занято более 144 временных интервалов для организации LSP). После этого дескриптор коммутации снова будет изменен и узел анонсирует новый дескриптор другим узлам.

2.5. Представление пропускной способности

Для представления незарезервированной (Unreserved), а также максимальной (Maximum LSP) и минимальной (Minimum LSP) полосы LSP используются действительные числа с плавающей запятой в формате IEEE [IEEE], как описано в параграфе 3.1.2 of [GMPLS-SIG].

3. Примеры дескрипторов возможностей коммутации

3.1. Интерфейс STM-16 POS в LSR

Дескриптор коммутации:

Режим коммутации = PSC-1

Кодирование = SDH

Максимальная пропускная способность LSP [p] = 2,5 Гбит/с для всех p

Если множество каналов с такими интерфейсами на обоих концах анонсируется в качестве одного соединения TE, следует использовать методы связывания каналов (bundling).

3.2. Интерфейс GigE Packet в LSR

Дескриптор коммутации:

Режим коммутации = PSC-1

Кодирование = Ethernet 802.3

Максимальная пропускная способность LSP [p] = 1,0 Гбит/с для всех p

Если множество каналов с такими интерфейсами на обоих концах анонсируется в качестве одного соединения TE, следует использовать методы связывания каналов (bundling).

3.3. Интерфейс STM-64 SDH в цифровом кросс-коннекторе с Standard SDH

Рассмотрим ветвь дерева иерархии мультиплексирования SDH — VC-3, VC-4, VC-4-4c, VC-4-16c, VC-4-64c. Если возможна организация всех этих соединений на интерфейсе STM-64, анонсируемый дескриптор коммутации для такого интерфейса будет иметь вид:

Дескриптор коммутации:

Режим коммутации = TDM [Standard SDH]

Кодирование = SDH

Минимальная пропускная способность LSP = VC-3

Максимальная пропускная способность LSP [p] = STM-64 для всех p

Если множество каналов с такими интерфейсами на обоих концах анонсируется в качестве одного соединения TE, следует использовать методы связывания каналов (bundling).

3.4. Интерфейс STM-64 SDH в кросс-коннекторе с 2 типами иерархии

Дескриптор коммутации 1:

Режим коммутации = TDM [Standard SDH]

Кодирование = SDH

Минимальная пропускная способность LSP = VC-3

Максимальная пропускная способность LSP [p] = STM-64 для всех p

Дескриптор коммутации 2:

Режим коммутации = TDM [Arbitrary SDH]

Кодирование = SDH

Минимальная пропускная способность LSP = VC-4

Максимальная пропускная способность LSP [p] = STM-64 для всех p

Если множество каналов с такими интерфейсами на обоих концах анонсируется в качестве одного соединения TE, следует использовать методы связывания каналов (bundling).

3.5. Интерфейс Opaque OXC (SDH) с поддержкой 1 длины волны на порт

«Непрозрачным» (opaque) OXC называется режим работы OXC, при котором весь поток одной длины волны (переносящий поток данных SDH) переключается без дополнительного мультиплексирования-демультиплексирования и служебные биты SDH не меняются совсем (или, по крайней мере, не меняются важные).

Интерфейс непрозрачного OXC работает с одной длиной волны и не может коммутировать множество длин волн, как одно целое. Таким образом, интерфейс непрозрачного OXC всегда имеет тип LSC, а не FSC, независимо от применения DWDM вне этого интерфейса.

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

Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе OXC. Все интерфейсы одного OXC должны иметь уникальные в рамках этого OXC идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).

Ниже приведен пример дескриптора коммутации для непрозрачного OXC с кадрированием SDH.

Дескриптор коммутации:

Режим коммутации = LSC

Кодирование = SDH

Резервируемая полоса = определяется кадрированием SDH (например, STM-64)

3.6. Интерфейс Transparent OXC (PXC) с внешней DWDM и кадрированием SDH

Этот пример предполагает соединение устройств DWDM и PXC так, чтобы каждый интерфейс (порт) PXC обслуживал просто одну длину волны. Таким образом, несмотря на возможность интерфейса PXC коммутировать группы из нескольких длин волн, в рассматриваемом случае интерфейс PXC относится к типы LSC, а не FSC.

                     _______
                    |       |
               /|___|       |
              | |___|  PXC  |
      ========| |___|       |
              | |___|       |
               \|   |_______|
             DWDM
         (кадрирование SDH)

 

Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе PXC. Все интерфейсы одного PXC должны иметь уникальные в рамках этого PXC идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).

Ниже приведен пример дескриптора коммутации для непрозрачного OXC (PXC) с внешним мультиплексированием DWDM, которое понимает кадрирование SDH.

Дескриптор коммутации:

Режим коммутации = LSC

Кодирование = SDH (приходит от DWDM)

Максимальная пропускная способность LSP = определяется DWDM (например, STM-64)

3.7. Интерфейс Transparent OXC (PXC) с внешней DWDM, прозрачный для скорости и кадрирования

Этот пример предполагает соединение устройств DWDM и PXC так, чтобы каждый интерфейс (порт) PXC обслуживал просто одну длину волны. Таким образом, несмотря на возможность интерфейса PXC коммутировать группы из нескольких длин волн, в рассматриваемом случае интерфейс PXC относится к типы LSC, а не FSC.

                        _______
                       |       |
                  /|___|       |
                 | |___|  PXC  |
         ========| |___|       |
                 | |___|       |
                  \|   |_______|
                DWDM (прозрачно для битовой скорости и кадрирования)

 

Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе PXC. Все интерфейсы одного PXC должны иметь уникальные в рамках этого PXC идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).

Ниже приведен пример дескриптора коммутации для непрозрачного OXC (PXC) с внешним мультиплексированием DWDM, которое прозрачно для битовой скорости и кадрирования.

Дескриптор коммутации:

Режим коммутации = LSC

Кодирование = Lambda (оптическое)

Резервируемая полоса = Определяется ограничениями оптической технологии

3.8. Интерфейс PXC без внешней DWDM

Отсутствие DWDM между парой PXC предполагает, что интерфейсы кросс-коннекторов не ограничены использованием одной длины волны. Таким образом, интерфейсы анонсируются с типом FSC.

Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе PXC. Все интерфейсы одного PXC должны иметь уникальные в рамках этого PXC идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).

Дескриптор коммутации:

Режим коммутации = FSC

Кодирование = Lambda (оптическое)

Резервируемая полоса = Определяется ограничениями оптической технологии

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

3.9. Интерфейс OXC с внутренней DWDM, понимающий кадрирование SDH

В этом примере предполагается, что соединение между устройствами DWDM и OXC организовано так, что каждый интерфейс кросс-коннектора OXC может индивидуально обрабатывать множество длин волн. В этом случае интерфейс OXC относится к типу LSC, а не FSC.

                  _______
                 |       |
               /||       ||\
              | ||  OXC  || |
      ========| ||       || |====
              | ||       || |
               \||_______||/
             DWDM
         (кадрирование SDH)

 

Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе OXC. Все длины волн на одном интерфейсе OXC должны иметь уникальные в рамках этого интерфейса идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).

Ниже приведен дескриптор коммутации интерфейса OXC с внутренним мультиплексированием DWDM, который понимает кадрирование SDH и поддерживает фиксированные значения пропускной способности.

Дескриптор коммутации:

Режим коммутации = LSC

Кодирование = SDH (приходит от DWDM)

Максимальная пропускная способность LSP = определяется DWDM (например, STM-16)

Режим коммутации = LSC

Кодирование = SDH (приходит от DWDM)

Максимальная пропускная способность LSP = определяется DWDM (например, STM-64)

3.10. Интерфейс OXC с внутренней DWDM, прозрачный для скорости и кадрирования

В этом примере предполагается, что соединение между устройствами DWDM и OXC организовано так, что каждый интерфейс кросс-коннектора OXC может индивидуально обрабатывать множество длин волн. В этом случае интерфейс OXC относится к типу LSC, а не FSC.

                         _______
                        |       |
                      /||       ||\
                     | ||  OXC  || |
             ========| ||       || |====
                     | ||       || |
                      \||_______||/
                    DWDM (прозрачно для битовой скорости и кадрирования)

 

Канал TE представляет собой группу из одного или множества интерфейсов на кросс-коннекторе OXC. Все длины волн на одном интерфейсе OXC должны иметь уникальные в рамках этого интерфейса идентификаторы, которые используются в качестве меток (см. параграф 3.2.1.1 в [GMPLS-SIG]).

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

Дескриптор коммутации:

Режим коммутации = LSC

Кодирование = Lambda (оптическое)

Резервируемая полоса = Определяется ограничениями оптической технологии

4. Примеры интерфейсов, поддерживающих MSC15

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

4.1. Интерфейс на устройстве PXC+TDM с внешним DWDM

Как было указано выше, использование внешнего мультиплексирования DWDM позволяет обслуживать на порту PXC только одну длину волны. На таком порту подключенное устройство PXC+TDM может организовать для длины волны кросс-соединение с другим исходящим оптическим каналом или служить терминальным устройством с интерфейсом SDH и коммутацией каналов SDH.

С точки зрения GMPLS функциональность PXC+TDM рассматривается, как один интерфейс, который описывается двумя дескрипторами коммутации (один для LSC, другой для TDM) с соответствующими параметрами. Например,

Дескриптор коммутации:

Режим коммутации = LSC

Кодирование = SDH (приходит от WDM)

Резервируемая полоса = STM-64

и

Дескриптор коммутации:

Режим коммутации = TDM [Standard SDH]

Кодирование = SDH

Минимальная пропускная способность LSP = VC-3

Максимальная пропускная способность LSP [p] = STM-64 для всех p

4.2. Интерфейс на устройстве Opaque OXC+TDM с внешним DWDM

Интерфейс устройства «непрозрачный OXC+TDM» будет анонсироваться, как LSC+TDM (см. выше).

4.3. Интерфейс на устройстве PXC+LSR с внешним DWDM

Как было указано выше, использование внешнего мультиплексирования DWDM позволяет обслуживать на порту PXC только одну длину волны. На таком порту подключенное устройство PXC+LSR может организовать для длины волны кросс-соединение с другим исходящим оптическим каналом или служить терминальным устройством с пакетным интерфейсом и коммутацией пакетов.

С точки зрения GMPLS функциональность PXC+LSR рассматривается, как один интерфейс, который описывается двумя дескрипторами коммутации (один для LSC, другой для PSC) с соответствующими параметрами. Например,

Дескриптор коммутации:

Режим коммутации = LSC

Кодирование = SDH (приходит от WDM)

Резервируемая полоса = STM-64

и

Дескриптор коммутации:

Режим коммутации = PSC-1

Кодирование = SDH

Максимальная пропускная способность LSP [p] = 10 Гбит/с для всех p

4.4. Интерфейс на устройстве TDM+LSR

На устройстве TDM+LSR с канализованным интерфейсом SDH может быть возможно перечисленное ниже.

  • Некоторые каналы SDH могут быть незавершенными (т. е. они не используются и доступны для выделения).

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

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

С точки зрения GMPLS функциональность TDM+PSC рассматривается, как один интерфейс, который описывается двумя дескрипторами коммутации (один для TDM, другой для PSC) с соответствующими параметрами. Например,

Дескриптор коммутации:

Режим коммутации = TDM [Standard SDH]

Кодирование = SDH

Минимальная пропускная способность LSP = VC-3

Максимальная пропускная способность LSP [p] = STM-64 для всех p

и

Дескриптор коммутации:

Режим коммутации = PSC-1

Кодирование = SDH

Максимальная пропускная способность LSP [p] = 10 Гбит/с для всех p

5. Благодарности

Авторы выражают благодарность Suresh Katukam, Jonathan Lang, Zhi-Wei Lin и Quaizar Vohra за комментарии и вклад в подготовку документа. Спасибо также Stephen Shew за текст, относящийся к представлению возможностей канала TE.

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

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

Хотя весь документ посвящен расширениям, он не задает реализации этих расширений в протоколах маршрутизации (типа OSPF или IS-IS). В документах, посвященных реализации этих расширений в протоколах маршрутизации [GMPLS-OSPF, GMPLS-ISIS], должны описываться также способы и средства защиты информации.

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

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

[GMPLS-OSPF] Kompella, K., Ed. and Y. Rekhter, Ed., «OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)», RFC 4203, October 2005.

[GMPLS-SIG] Berger, L., «Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description», RFC 3471, January 2003.

[GMPLS-SONET-SDH] Mannie, E. and D. Papadimitriou, «Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control», RFC 3946, October 2004.

[IEEE] IEEE, «IEEE Standard for Binary Floating-Point Arithmetic», Standard 754-1985, 1985 (ISBN 1-5593- 7653-8).

[LINK-BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, «Link Bundling in MPLS Traffic Engineering (TE)», RFC 4201, October 2005.

[LMP] Lang, J., Ed., «Link Management Protocol (LMP)», RFC 4204, October 2005.

[LSP-HIER] Kompella, K. and Y. Rekhter, «Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE))», RFC 4206, October 2005.

[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, «Traffic Engineering (TE) Extensions to OSPF Version 2», RFC 3630, September 2003.

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

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, «MPLS Label Stack Encoding», RFC 3032, January 2001.

7.2. Дополнительная литература

[GMPLS-ISIS] Kompella, K., Ed. and Y. Rekhter, Ed., «Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)», RFC 4205, October 2005.

[ISIS-TE] Smit, H. and T. Li, «Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)», RFC 3784, June 2004.

8. Участники работы

Ayan Banerjee

Calient Networks

5853 Rue Ferrari

San Jose, CA 95138

Phone: +1.408.972.3645

EMail: abanerjee@calient.net

John Drake

Calient Networks

5853 Rue Ferrari

San Jose, CA 95138

Phone: (408) 972-3720

EMail: jdrake@calient.net

Greg Bernstein

Ciena Corporation

10480 Ridgeview Court

Cupertino, CA 94014

Phone: (408) 366-4713

EMail: greg@ciena.com

Don Fedyk

Nortel Networks Corp.

600 Technology Park Drive

Billerica, MA 01821

Phone: +1-978-288-4506

EMail: dwfedyk@nortelnetworks.com

Eric Mannie

Libre Exaministe

EMail: eric_mannie@hotmail.com

Debanjan Saha

Tellium Optical Systems

2 Crescent Place

P.O. Box 901

Ocean Port, NJ 07757

Phone: (732) 923-4264

EMail: dsaha@tellium.com

Vishal Sharma

Metanoia, Inc.

335 Elan Village Lane, Unit 203

San Jose, CA 95134-2539

Phone: +1 408-943-1794

EMail: v.sharma@ieee.org

Debashis Basak

AcceLight Networks,

70 Abele Rd, Bldg 1200

Bridgeville PA 15017

EMail: dbasak@accelight.com

Lou Berger

Movaz Networks, Inc.

7926 Jones Branch Drive

Suite 615

McLean VA, 22102

EMail: lberger@movaz.com

Адреса авторов

Kireeti Kompella

Juniper Networks, Inc.

1194 N. Mathilda Ave

Sunnyvale, CA 94089

EMail: kireeti@juniper.net

Yakov Rekhter

Juniper Networks, Inc.

1194 N. Mathilda Ave

Sunnyvale, CA 94089

EMail: yakov@juniper.net

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

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

nmalykh@protocols.ru

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

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.

1Generalized Multi-Protocol Label Switching — обобщенная многопротокольная коммутация по меткам.

2Traffic Engineering — построение трафика.

3Shortest Path First — сначала кратчайший путь.

4Label Switched Path — путь с коммутацией по меткам.

5Выбор кратчайшего пути с учетом ограничений.

6Label Switching Router — маршрутизатор с коммутацией по меткам.

7Optical Cross-Connect — оптический кросс-коннектор.

8Shared risk link group — группа общего риска, связанного с соединениями.

9Packet-Switch Capable — поддержка коммутации пакетов

10Layer-2 Switch Capable — поддержка коммутации на уровне 2 (логический канал).

11Time-Division-Multiplex Capable — поддержка мультиплексирования с разделением по времени.

12Lambda-Switch Capable — поддержка коммутации по длине волны.

13Fiber-Switch Capable — поддержка коммутации оптических волокон.

14Максимальная пропускная способность LSP.

15Множество вариантов коммутации.