RFC 3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks

Network Working Group                                         P. Agarwal
Request for Comments: 3443                                       Brocade
Updates: 3032                                                   B. Akyol
Category: Standards Track                                  Cisco Systems
                                                            January 2003

Обработка TTL в сетях MPLS

Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks

PDF

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

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

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

Copyright (C) The Internet Society (2003). All Rights Reserved.

Тезисы

Этот документ описывает обработку полей TTL1 в иерархических сетях MPLS2. Основным мотивом послужила потребность формализовать прозрачных для TTL режим работы путей с коммутацией по меткам MPLS. Документ обновляет RFC 3032 «MPLS Label Stack Encoding». Описана обработка TTL в иерархических туннелях с режимами Pipe и Uniform с примерами для случаев push и pop. Документ также служит дополнением к RFC 3270 «MPLS Support of Differentiated Services» и объединяет введенную в этом документе терминологию с обработкой TTL в иерархических сетях MPLS.

Используемые соглашения

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

1. Введение и мотивы

Этот документ описывает обработку полей TTL в иерархических сетях MPLS. Мы надеемся, что этот документ детализирует вопросы, рассмотренные в [MPLS-ARCH, MPLS-ENCAPS], а представленные здесь методы дополнят [MPLS-DS].

В частности, вводится новый режим обработки (его называют Pipe Model) для поддержки практики настройки MPLS LSP так, что проходящие через LSP пакеты видят туннель, как один интервал пересылки (hop), независимо от числа промежуточных маршрутизаторов LSR3. Модель Pipe (труба) для TTL в настоящее время применяется во многих сетях и реализуется операторами сетей в форме настраиваемой опции для оборудования нескольких производителей.

Этот документ формализует обработку TTL в сетях MPLS и связывает ее с терминологией, введенной в [MPLS-DS].

2. Обработка TTL в сетях MPLS

2.1. Отличия от RFC 3032 [MPLS-ENCAPS]

  1. [MPLS-ENCAPS] охватывает только однородную модель (Uniform Model), не затрагивая модели Pipe и Short Pipe. Данный документ рассматривает обе эти модели и для полноты включает также модель Uniform.

  2. [MPLS-ENCAPS] не охватывает иерархические LSP, которые рассмотрены здесь.

  3. [MPLS-ENCAPS] не определяет обработку TTL в присутствии PHP4, что рассмотрено здесь.

2.2. Терминология и основы

Как определено в [MPLS-ENCAPS], пакеты MPLS используют заголовок-прокладку (shim) MPLS, который содержит перечисленную ниже информацию о пакете..

  1. Метка MPLS (20 битов).

  2. TTL (8 битов).

  3. Дно (Bottom) стека (1 бит).

  4. Экспериментальные биты (3 бита).

Экспериментальные биты были переопределены в [MPLS-DS] для индикации поведения в плане планирования и формовки (shaping), связанных с пакетом MPLS.

В [MPLS-DS] определены две модели (режима) для туннелей MPLS — Pipe и Uniform. В режиме Pipe сеть MPLS действует подобно устройству (каналу) при прохождении пакетов MPLS через сеть и для узлов, расположенных вне туннеля видны только вход и выход LSP. Сокращенная вариация этого режима (Short Pipe) также определена в [MPLS-DS] с целью различения вариантов пересылки на выходе и трактовок качества обслуживания (QoS). С другой стороны, модель Uniform делает видимыми все узлы, через которые проходит LSP, для расположенных вне туннеля узлов. Здесь модели Pipe и Uniform расширяются за счет включения обработки TTL. Кроме того, в документе описана обработка TTL при выполнении PHP. Подробное описание моделей Pipe и Uniform приведено в [MPLS-DS].

Обработку TTL в сетях MPLS можно разбит на два логических блока: (i) определение TTL на входе для учета любого выхода из туннеля в результате операций MPLS Pop и (ii) обработка (возможно) раскрываемых пакетов и TTL на выходе.

Отметим также, что сигнализация типа LSP (Pipe, Short Pipe или Uniform) выходит за рамки документа и не рассматривается в текущих версиях протоколов распространения меток (например, LDP [MPLS-LDP] и RSVP-TE [MPLS-RSVP]). В настоящее время LSP настраиваются операторами вручную с помощью команд или интерфейса управления сетью.

2.3. Новые термины

iTTL

Значение TTL для использования в качестве TTL на входе. Проверки iTTL не выполняется.

oTTL

Это значение служит в качестве TTL на выходе TTL (исключения указаны в параграфе 3.5). Если явно не указано иное, это значение всегда составляет (iTTL — 1).

oTTL Check

Проверка того, что oTTL > 0. Если эта проверка не проходит, пакет не будет пересылаться. Отметим, что проверка oTTL выполняется лишь в тем случаях, когда в качестве TTL на выходе (IP или MPLS) установлено значения oTTL (исключения указаны в параграфе 3.5).

3. Обработка TTL в разных моделях

В этом разделе описана обработка TTL для LSP, соответствующих каждой из 3 моделей (Uniform, Short Pipe, Pipe) при наличии и отсутствии PHP (когда это применимо).

3.1. Обработка TTL в Uniform LSP (с PHP и без него)

(согласуется с [MPLS-ENCAPS]):

             ========== LSP =============================>
                 +--Swap--(n-2)-...-swap--(n-i)---+
                /      (внешний заголовок)         \
              (n-1)                                (n-i)
              /                                      \
   >--(n)--Push...............(x).....................Pop--(n-i-1)->
            (I)         (внутренний заголовок)        (E или P)

   (n) представляет значение TTL в соответствующем заголовке
   (x) представляет не имеющую значения информацию TTL
   (I) представляет входной узел LSP
   (P) представляет предпоследний узел LSP
   (E) представляет выходной узел LSP

Рисунок показывает обработку TTL для MPLS LSP в режиме Uniform. Отметим, что внутреннее и внешнее значения TTL в пакетах синхронизируются на входе и выходе туннеля.

3.2. Обработка TTL в Short Pipe LSP

3.2.1. Обработка TTL для Short Pipe LSP без PHP

             ========== LSP =============================>
                 +--Swap--(N-1)-...-swap--(N-i)-----+
                /       (внешний заголовок)          \
              (N)                                  (N-i)
              /                                        \
   >--(n)--Push...............(n-1).....................Pop--(n-2)->
            (I)       (внутренний заголовок)            (E)

   (N) представляет значение TTL (может быть не связано с n)
   (n) представляет туннелированное значение TTL в инкапсулированном заголовке
   (I) представляет входной узел LSP
   (E) представляет выходной узел LSP

Модель Short Pipe была введена в [MPLS-DS]. В модели Short Pipe трактовка пересылки на выходном LSR базируется на туннелированном (а не инкапсулирующем) пакете.

3.2.2. Обработка TTL для Short Pipe LSP с PHP

             ========== LSP =====================================>
                 +-Swap-(N-1)-...-swap-(N-i)-+
                /    (внешний заголовок)      \
              (N)                            (N-i)
              /                                \
   >--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)->
            (I)    (внутренний заголовок)    (P)      (E)

   (N) представляет значение TTL (может быть не связано с n)
   (n) представляет туннелированное значение TTL в инкапсулированном заголовке
   (I) представляет входной узел LSP
   (P) представляет предпоследний узел LSP
   (E) представляет выходной узел LSP

Поскольку метка уже была вытолкнута (popped) предпоследним узлом LSP, выходной узел LSP просто уменьшает TTL в заголовке.

Отметим также, что в конце LSP в режиме Short Pipe значение TTL в туннелируемом пакете уменьшается на 2 (независимо от PHP).

3.3. Обработка TTL для Pipe LSP (только без PHP)

             ========== LSP =============================>
                 +--Swap--(N-1)-...-swap--(N-i)-----+
                /       (внешний заголовок)          \
              (N)                                  (N-i)
              /                                        \
   >--(n)--Push...............(n-1)....................Pop--(n-2)->
            (I)       (внутренний заголовок)           (E)

   (N) представляет значение TTL (может быть не связано с n)
   (n) представляет туннелированное значение TTL в инкапсулированном заголовке
   (I) представляет входной узел LSP
   (E) представляет выходной узел LSP

В части TTL трактовка Pipe LSP идентична Short Pipe без PHP.

3.4. Определение TTL на входе (iTTL)

Если входящий пакет относится к протоколу IP, iTTL будет совпадать со значением TTL во входящем пакете IP.

Если входящий пакет относится к MPLS и выполняется процедура Push/Swap/PHP, iTTL будет совпадать со значением TTL верхней входящей метки.

Если входящий пакет относится к MPLS и выполняется процедура Pop (выход из туннеля), значение iTTL основывается на типе туннеля (Pipe или Uniform) в LSP, где происходит выталкивание. Если выталкиваемая метка относится к Pipe LSP, iTTL будет совпадать со значением поля TTL в заголовке, показываемом после выталкивания метки (отметим, что в контексте данного документа может показываться заголовок IP или метка MPLS). Если выталкиваемая метка относится к Uniform LSP, iTTL будет совпадать с TTL вытолкнутой метки. Если последовательно выполняется множество операций выталкивания (Pop), указанная выше процедура будет повторяться с одним исключением — значение iTTL, рассчитанное для предыдущего выталкивания, служит в качестве TTL последующей выталкиваемой метки (т. е. значение TTL, содержащееся в последующей метке, игнорируется и заменяется значением iTTL, полученным для предыдущего выталкивания).

3.5. Определение TTL на выходе и обработка пакетов

После завершения расчета iTTL выполняется проверка oTTL. При успешном завершении проверки oTTL рассчитывается выходное значение TTL пакетов (с метками и без меток) и заголовки пакетов обновляются, как описано ниже.

Если пакет маршрутизировался, как пакет IP, в качестве значение TTL в заголовке пакета IP устанавливается oTTL (iTTL — 1). Значения TTL для всех втолкнутых (pushed) меток определяются в соответствии с параграфом 3.6.

Для пакетов, маршрутизируемых как MPLS, имеется 4 варианта, перечисленных ниже.

  1. Только обмен (Swap-only) — маршрутизируемая метка меняется местами (swapped) с другой меткой, а в поле TTL выходной метки устанавливается значение oTTL.

  2. Обмен с последующим вталкиванием (Swap followed by a Push) — выполняется обмен метками как в п. 1). Значения TTL всех вталкиваемых меток определяются в соответствии с параграфом 3.6.

  3. Выталкивание на предпоследнем этапе (PHP) — маршрутизируемая метка выталкивается (popped). Проверку oTTL следует проводить независимо от использования oTTL для обновления поля TTL в выходном заголовке. Если вытолкнутая (PHPed) метка относилась к Short Pipe LSP, поле TTL показанного PHP заголовка не проверяется и не обновляется. Если вытолкнутая метка относилась к Uniform LSP, в поле TTL показанного PHP заголовка устанавливается значение oTTL. Значения TTL дополнительных меток определяются в соответствии с параграфом 3.6

  4. Выталкивание (Pop) — операция выталкивания происходит до маршрутизации и поэтому здесь не рассматривается.

3.6. Обработка на входе в туннель (Push)

Для каждой вталкиваемой (pushed) метки в режиме Uniform значение TTL копируется из метки/IP-пакета, расположенного непосредственно ниже.

Для каждой вталкиваемой метки в режиме Pipe или Short Pipe в поле TTL устанавливается значение, заданное оператором. Во многих реализациях по умолчанию установлено значение 255.

3.7. Замечания по реализации

  1. Хотя iTTL при обновлении или определении oTTL может инкрементироваться больше, чем на 1, эту возможность следует использовать лишь для «компенсации» узлов, не способных уменьшать значения TTL.

  2. При уменьшении iTTL должны быть приняты меры предотвращение отрицательных значений.

  3. В режиме Short Pipe с включенным PHP значение TTL в туннелированных пакетах не изменяется после операции PHP.

4. Заключение

В этом документе описана возможная обработка полей TTL в сетях MPLS. Разъяснены разные методы, которые могут применяться при наличии иерархических туннелей, а также завершено объединение моделей Pipe и Uniform с обработкой TTL.

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

Этот документ не добавляет вопросов безопасности к отмеченным в [MPLS-ENCAPS, MPLS-DS]. В частности, документ не определяет новых протоколов или расширений существующих и не создает проблем безопасности для имеющихся протоколов. Авторы надеются, что прояснение обработки TTL в сетях MPLS обеспечит преимущества для сетевых операторов и их пользователей за счет упрощения поиска неполадок.

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

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

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

[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, «Multiprotocol Label Switching Architecture», RFC 3031, January 2001.

[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, «MPLS Label Stack Encoding», RFC 3032, January 2001.

[MPLS-DS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen, «Multi-Protocol Label Switching (MPLS) Support of Differentiated Services», RFC 3270, May 2002.

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

[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, «LDP Specification», RFC 3036, January 2001.

[MPLS-RSVP] 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.

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

Авторы благодарят членов рабочей группы MPLS за их отзывы. Отдельная благодарность Shahram Davari и Loa Andersson за внимательное рецензирование документа и комментарии.

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

Puneet Agarwal

Brocade Communications Systems, Inc.

1745 Technology Drive

San Jose, CA 95110

EMail: puneet@acm.org

Bora Akyol

Cisco Systems

170 W. Tasman Drive

San Jose, CA 95134

EMail: bora@cisco.com


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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

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

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


1Time To Live — время жизни.

2Multi-Protocol Label Switching — многопротокольная коммутация по меткам.

3Label switch router — маршрутизатор с коммутацией по меткам.

4Penultimate Hop Popping — «всплывание» (выталкивание) на предпоследнем этапе.




RFC 3471 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description

Network Working Group                                  L. Berger, Editor
Request for Comments: 3471                                Movaz Networks
Category: Standards Track                                   January 2003

 

Описание сигнальных функций GMPLS

Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description

PDF

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

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

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

Copyright (C) The Internet Society (2003). All Rights Reserved.

Тезисы

Этот документ описывает расширение сигнализации MPLS1 для поддержки GMPLS2. Обобщенная MPLS расширяет средства управления MPLS для поддержки систем с временным (например, SONET/SDH3), частотным (длины оптических волн) и пространственным (например, разделение направлений передачи по волокнам) мультиплексированием. Документ представляет функциональные описания расширений. Специфические для протоколов форматы и механизмы, а также технологические детали рассматриваются в отдельных документах.

Оглавление

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

1. Введение

Архитектура MPLS [RFC3031] была определена для поддержки пересылки данных на основе меток. В этой архитектуре предполагается, что маршрутизаторы LSR4 поддерживают средства коммутации, способные (a) распознавать границы пакетов и ячеек, а также (b) обрабатывать заголовки пакетов (LSR, распознающие границы пакетов) или ячеек (LSR, распознающие границы ячеек).

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

С учетом сказанного выше, LSR или, более точно, интерфейсы LSR можно разделить на несколько классов.

  1. Интерфейсы, способные распознавать границы пакетов или ячеек и пересылать данные на основе содержимого их заголовков. Примерами могут служить интерфейсы маршрутизаторов, пересылающие данные на основе содержимого shim-заголовков или интерфейсы ATM-LSR, пересылающие данные на основе ATM VPI/VCI. Такие интерфейсы называют PSC5.

  2. Интерфейсы, пересылающие данные на основе информации из специального временного интервала, периодически повторяющегося в потоке данных. Примерами таких интерфейсов могут служить интерфейсы кросс-коннекторов SONET/SDH. Этот тип интерфейсов обозначают аббревиатурой TDM6.

  3. Интерфейсы, пересылающие данные на основе длины волны, на которой были приняты эти данные. Примером могут служить интерфейсы оптических кросс-коннекторов, которые могут работать на уровне отдельных длин волн. Для интерфейсов этого типа используется аббревиатура LSC7.

  4. Интерфейсы, пересылающие данные на основе их реального размещения в пространстве. Примером могут служить интерфейсы оптических кросс-коннекторов, работающие на уровне отдельных волокон или групп волокон. Для обозначения таких интерфейсов служит аббревиатура FSC8.

Использование вложенных LSP9 обеспечивает масштабирование систем за счет построения иерархии пересылки. На верхнем уровне этой иерархии размещаются интерфейсы FSC, ниже следуют LSC, затем — TDM и далее — PSC. В этом случае LSP, начинающийся и завершающийся на интерфейсе PSC, может быть вложен (вместе с другими LSP) в LSP, который начинается и завершается интерфейсами TDM. Этот LSP, в свою очередь, может быть вложен (вместе с другими LSP) в LSP, начинающийся и завершающийся на интерфейсах LSC, который, в своею очередь, может быть вложен (вместе с другими LSP) в LSP, началом и завершением которого являются интерфейсы FSC. Иерархии LSP подробно описаны в [MPLS-HIERARCHY].

Организация LSP, проходящих только через интерфейсы первого класса, определена в [RFC3036, RFC3212, RFC3209]. Данный документ представляет функциональное описание расширений, требуемых для обобщения средств управления MPLS с целью поддержки всех четырех классов интерфейсов. В документе приводятся только определения и форматы, независимые от протоколов сигнализации. Специфичные для протоколов форматы определены в [RFC3473] и [RFC3472]. Технологические детали также выходят за рамки настоящего документа и рассматриваются в отдельных документах типа [GMPLS-SONET].

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

2. Обзор

Обобщенная коммутация GMPLS отличается от традиционной MPLS поддержкой множества типов коммутации (TDM, диапазон длин волн, волокно/порт). Поддержка множества типов коммутации в GMPLS привела к расширению некоторых базовых функций традиционной коммутации MPLS, а в некоторых случаях — к добавлению новых функций. Эти изменения и дополнения влияют на базовые свойства LSP — выделение меток и обмен ими, однонаправленность LSP, распространение ошибок, данные для синхронизации между входом и выходом.

В традиционной организации трафика MPLS каналы, через которые проходят LSP, могут быть разнотипными с разным представлением меток. Например, LSP может включать каналы между множеством маршрутизаторов, каналы между маршрутизаторами и ATM-LSR, а также каналы между ATM-LSR. GMPLS расширяет это, добавляя представление меток в форме временных интервалов, длин волн, положения в реальном физическом пространстве. Как и в традиционной MPLS TE, где не все LSR способны распознавать границы пакетов (IP) (например, ATM-LSR) на уровне пересылки, обобщенная MPLS включает поддержку LSR, которые не способны распознавать границы пакетов (IP) на своих уровнях пересылки. В традиционной MPLS TE передающий трафик IP путь LSP начинается и завершается на маршрутизаторах. GMPLS расширяет эту трактовку, требуя лишь, чтобы LSP начинались и завершались на похожих типах LSR. Кроме того в обобщенной MPLS набор типов передаваемых через LSP данных расширяется за счет добавления SONET/SDH, 1Gb или 10Gb Ethernet и т. п. Эти отличия от традиционной MPLS отразились на способах запроса меток и обмена ими в GMPLS (см. параграфы 3.1 и 3.2). Специальные случаи коммутации длин волн (Lambda) и диапазонов (Waveband) описаны в параграфе 3.3.

Другим фундаментальным различием между традиционными LSP и неспособными коммутировать пакеты (non-PSC) GMPLS LSP является то, что полоса для LSP может выделяться только дискретными блоками (см. параграф 3.1.3). Число меток на каналах без PSC будет (значительно) меньше числа меток на каналах PSC. Отметим, что использование FA10 (см. [MPLS-HIERARCHY]) обеспечивает механизм, способный повысить эффективность использования полосы каналов в тех случаях, когда полоса может выделяться только дискретными блоками, а также механизм агрегирования состояний пересылки, позволяющий снизить число требуемых меток.

GMPLS обеспечивает вышестоящим (upstream) узлам предлагать метки (см. параграф 3.4). Такое предложение может быть переопределено нижестоящим (downstream) узлом, но в некоторых случаях за это придется расплачиваться временем на организацию LSP. Предложенные метки ценны при организации LSP через некоторые типы оптического оборудования, где возможны существенные (по сравнению с электрическими средами) временные издержки на настройку коммутации. Например, может потребоваться настройка положения микрозеркал, связанная с их перемещением и последующей юстировкой. Если метки и, следовательно, машина коммутации настроены для обратного направления (норма), может потребоваться задержка сообщения в десятки миллисекунд на интервал пересылки для организации применимого пути пересылки. Предложенные метки ценны также для случаев восстановления после отказов узлов.

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

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

GMPLS поддерживает использование конкретной метки на конкретном интерфейсе (см. раздел 6). [RFC3473] также поддерживает механизмы RSVP для быстрого уведомления об отказах.

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

GMPLS также разрешает включать в сигнализацию специфические параметры технологии. Цель этого заключается в передаче специфических параметров технологии в SENDER_TSPEC и других связанных объектах при использовании RSVP, а также в Traffic Parameters TLV при использовании CR-LDP. Форматы специфических для технологий параметров будут определяться по мере необходимости. Пример таких определений имеется в [GMPLS-SONET].

3. Связанные с метками форматы

Для расширения MPLS на оптические и TDM-устройства требуется несколько новых форм «меток». Совокупность этих новых форм называют обобщенными метками (generalized label). Обобщенные метки содержат информацию, которая позволяет принимающему узлу запрограммировать кросс-соединение, независимо от типа такого соединения, чтобы корректно соединиться с входным сегментом пути. В этом разделе описаны запрос обобщенной метки, собственно метка, поддержка коммутации диапазонов, предложенные метки и наборы меток.

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

3.1. Запрос обобщенной метки

Сообщения Generalized Label Request поддерживают обмен характеристиками, которые требуются для поддержки запрашиваемого LSP. Эти характеристики включают представление и содержимое LSP. Отметим, что эти характеристики могут использоваться промежуточными узлами (например, для поддержки определения предпоследнего интервала).

В Generalized Label Request передается параметр представления LSP, называемый LSP Encoding Type. Этот параметр указывает тип представления (например, SONET/SDH/GigE и т. п.), который будет использоваться для данных, связанных с этим LSP. LSP Encoding Type показывает природу LSP, а не природу каналов, через которые этот LSP проходит. Канал может поддерживать множество форматов представления в том смысле, что канал может передавать и коммутировать сигнал с одним или множеством из этих форматов в зависимости от доступности ресурсов и емкости данного канала. В качестве примера рассмотрим LSP для которого указано lambda-представление. Предполагается, что такой LSP будет поддерживаться без электрических преобразований, но не делается каких-либо предположений о типах модуляции и скоростях на промежуточных устройствах. Другие форматы обычно требуют информации о кадрировании и поля параметров разбиты на тип кадрирования и скорость, как показано ниже.

Generalized Label Request также указывает тип коммутации, запрашиваемый для канала. Это поле обычно совпадает для всех каналов в составе LSP.

3.1.1. Требуемая информация

Формат сообщения Generalized Label Request показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type |             G-PID             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LSP Encoding Type — 8 битов

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

Значение

Тип

1

Пакеты

2

Ethernet

3

ANSI/ETSI PDH

4

Резерв

5

SDH ITU-T G.707 / SONET ANSI T1.105

6

Резерв

7

Digital Wrapper

8

Lambda (оптика)

9

Fiber (волокна)

10

Резерв

11

FiberChannel

Типы ANSI PDH и ETSI PDH обозначают соответствующие сетевые технологии — DS1 и DS3 являются примерами ANSI PDH LSP, а E1 LSP — ETSI PDH. Тип Lambda указывает LSP для всего диапазона длин волн, тип Fiber относится к LSP, которые включают оптические порты целиком.

Switching Type — 8 битов

Показывает тип коммутации, который следует использовать на конкретном канале. Это поле требуется для каналов, поддерживающих более одного типа коммутации. Поле следует отображать на одно из значений, анонсируемых для соответствующего канала в Switching Capability Descriptor [GMPLS-RTG]. Определенные к настоящему моменту значения приведены в таблице.

Значение

Тип

1

Packet-Switch Capable-1 (PSC-1)

2

Packet-Switch Capable-2 (PSC-2)

3

Packet-Switch Capable-3 (PSC-3)

4

Packet-Switch Capable-4 (PSC-4)

51

Layer-2 Switch Capable (L2SC)

100

Time-Division-Multiplex Capable (TDM)

150

Lambda-Switch Capable (LSC)

200

Fiber-Switch Capable (FSC)

Generalized PID (G-PID) — 16 битов

Идентификатор данных, передаваемых через этот LSP (например, идентификатор клиентского уровня данного LSP). Идентификатор используется конечными точками и узлами LSP, а в некоторых случаях — предпоследним интервалом. Для пакетных и Ethernet LSP используются стандартные значения Ethertype, прочие указаны в таблице.

Значение

Тип

Технология

0

Неизвестен

Все

1

Резерв

2

Резерв

3

Резерв

4

Резерв

5

Асинхронное отображение E4

SDH

6

Асинхронное отображение DS3/T3

SDH

7

Асинхронное отображение E3

SDH

8

Синхронное битовое отображение E3

SDH

9

Синхронное байтовое отображение E3

SDH

10

Асинхронное отображение DS2/T2

SDH

11

Синхронное битовое отображение DS2/T2

SDH

12

Резерв

13

Асинхронное отображение E1

SDH

14

Синхронное байтовое отображение E1

SDH

15

Синхронное байтовое отображение 31 * DS0

SDH

16

Асинхронное отображение DS1/T1

SDH

17

Синхронное битовое отображение DS1/T1

SDH

18

Синхронное байтовое отображение DS1/T1

SDH

19

VC-11 в VC-12

SDH

20

Резерв

21

Резерв

22

Асинхронный DS1 SF

SONET

23

Асинхронный DS1 ESF

SONET

24

Асинхронный DS3 M23

SONET

25

Асинхронный DS3 с четностью C-Bit

SONET

26

VT/LOVC

SDH

27

STS SPE/HOVC

SDH

28

POS — без скрэмблирования, CRC 16 битов

SDH

29

POS — без скрэмблирования, CRC 32 бита

SDH

30

POS — со скрэмблированием, CRC 16 битов

SDH

31

POS — со скрэмблированием, CRC 32 бита

SDH

32

Отображение ATM

SDH

33

Ethernet

SDH, лямбда, волокно

34

SONET/SDH

Лямбда, волокно

35

Резерв (запрещено для SONET)

Лямбда, волокно

36

Digital Wrapper

Лямбда, волокно

37

Лямбда

Волокно

38

ANSI/ETSI PDH

SDH

39

Резерв

SDH

40

Протокол доступа к каналу (LAP) SDH (X.85 и X.86)

SDH

41

FDDI

SDH, лямбда, волокно

42

DQDB (ETSI ETS 300 216)

SDH

43

FiberChannel-3 (службы)

FiberChannel

44

HDLC

SDH, лямбда, волокно

45

Только Ethernet V2/DIX

SDH, лямбда, волокно

46

Только Ethernet 802.3

SDH, лямбда, волокно

3.1.2. Представление полосы

Пропускная способность представляется 32-битовым числом с плавающей запятой в формате IEEE (в байтах за секунду). Для непакетных LSP полезно определять дискретные значения, указывающие пропускную способность LSP. Некоторые типовые значения для запрашиваемой полосы представлены в таблице (значения являются рекомендуемыми). По мере необходимости будут определяться новые значения. Представление полосы передается в зависимости от протокола (см. [RFC3473] и [RFC3472]).

Тип сигнала

Битовая скорость (Мбит/с)

Значение (байт/с) (IEEE Floating point)

DS0

0,064

0x45FA0000

DS1

1,544

0x483C7A00

E1

2,048

0x487A0000

DS2

6,312

0x4940A080

E2

8,448

0x4980E800

Ethernet

10,00

0x49989680

E3

34,368

0x4A831A80

DS3

44,736

0x4AAAA780

STS-1

51,84

0x4AC5C100

Fast Ethernet

100,00

0x4B3EBC20

E4

139,264

0x4B84D000

FC-0 133M

0x4B7DAD68

OC-3/STM-1

155,52

0x4B9450C0

FC-0 266M

0x4BFDAD68

FC-0 531M

0x4C7D3356

OC-12/STM-4

622,08

0x4C9450C0

GigE

1000,00

0x4CEE6B28

FC-0 1062M

0x4CFD3356

OC-48/STM-16

2488,32

0x4D9450C0

OC-192/STM-64

9953,28

0x4E9450C0

10GigE-LAN

10000,00

0x4E9502F9

OC-768/STM-256

39813,12

0x4F9450C0

3.2. Обобщенная метка

Обобщенные метки (Generalized Label) являются расширением традиционных меток, которое позволяет представлять не только метки, перемещающиеся вместе с пакетами данных, но и метки, идентифицирующие временные интервалы, длины волн или позиции при пространственном мультиплексировании. Например, Generalized Label может переносить метку, которая представляет (a) отдельное волокно в кабеле, (b) одну длину волны в волокне, (c) одну длину волны в диапазоне (или волокне), (d) группу временных интервалов для одной длины волны (или волокна). Она может также передавать метку, представляющую обычную метку MPLS, Frame Relay или ATM (VCI/VPI).

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

Generalized Label переносит только метку одного уровня (иерархия не поддерживается). Если требуется множество уровней (LSP внутри LSP) пути LSP должны организовываться независимо (см. [MPLS-HIERARCHY]).

Каждый объект/TLV Generalized Label oимеет параметр Label переменного размера.

3.2.1. Требуемая информация

Передаваемая в Generalized Label имеет вид:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Label                             |
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Label — переменный размер

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

3.2.1.1. Метки порта и длины волны

Некоторые конфигурации коммутации волокон (FSC) и длин волн (LSC) используют множество каналов данных/соединений, находящихся под контролем одного канала управления. В таких случаях для LSP используются метки, идентифицирующие канал данных/соединение. Отметим, что этот случай не совпадает с использованием [MPLS-BUNDLE].

Информация передается в метке (Port and Wavelength), формат которой показан ниже:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Label                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Label — 32 бита

Указывает используемый порт/волокно или длину волны с точки зрения отправителя объекта/TLV. Значения этого поля значимы только в контексте соседей и получателю может потребоваться преобразование полученного значения в локально значимое. Значения могут задаваться в конфигурации или определяться динамически с помощью протоколов типа [LMP].

3.2.1.2. Прочие метки

Метки GMPLS и Frame Relay представляются 32-битовыми (4 октета) значениями с выравниванием по правому краю. Метки ATM представляются выравниваемыми по правому краю значениями VPI (биты 0 — 15) и VCI (биты 16 — 31).

3.3. Коммутация диапазонов

Специальным случаем коммутации длин волн (lambda) является коммутация диапазонов. Диапазон представляет собой набор длин вол, который может быть целиком переключен в другой диапазон длин волн. Такая коммутация может быть удобна для оптических кроссов, поскольку позволяет переключить множество длин волн разом. Это может обеспечить снижение уровня дисторсии для отдельных длин волн, а также позволяет сделать более точным разделение по отдельным длинам волн. Для поддержки этого специального случая определена метка Waveband.

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

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

3.3.1. Требуемая информация

Для коммутации диапазон используется тот же формат, который был описан для обобщенной метки в параграфе 3.2.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Waveband Id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Start Label                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           End Label                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Waveband Id — 32 бита

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

Start Label — 32 бита

Указывает идентификатор канала наименьшей длины волны диапазона с точки зрения объекта/TLV отправителя.

End Label — 32 бита

Указывает идентификатор канала наибольшей длины волны диапазона с точки зрения объекта/TLV отправителя.

Идентификаторы каналов задаются в конфигурации или с помощью протоколов типа LMP [LMP]. Эти идентификаторы обычно применяются в параметре Label обобщенных меток одного PSC и LSC.

3.4. Предложенные метки

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

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

Информация в предлагаемых метках идентична информации в обобщенных метках. Отметим, что значения поля Label в предлагаемых метках даются с точки зрения объекта /TLV отправителя.

3.5. Набор меток

Наборы меток (Label Set) применяются для ограничения числа меток, выбираемых нижележащим узлом, неким множеством приемлемых меток. Это ограничение используется на уровне интервала пересылки (hop).

Опишем 4 случая, когда применение Label Set будет полезным для оптического домена. К первому случаю относятся ситуации, когда оконечное оборудование может использовать для передачи лишь небольшой набор длин волн или диапазонов. Вторым является случай наличия цепочки интерфейсов, не способных преобразовывать длину волны (не поддерживающие CI) и требующих сквозного использования одной длины волны на группе интервалов пересылки или даже на всем пути. В третьем случае имеется потребность в ограничении числа выполняемых преобразования длины волны с целью снижения уровня искажений оптических сигналов. Последним является случай, когда на разных концах одного соединения поддерживаются разные наборы длин волн.

Label Set используется для ограничения наборов меток, которые могут применяться на конкретном пути LSP между двумя партнерами. Получатель Label Set должен ограничить свой выбор меток в соответствии с полученным набором. Как м отдельные метки, Label Set может применяться на множестве интервалов. В этом случае каждый узел генерирует свой исходящий Label Set, возможно на основе Label Set и с учетом возможностей оборудования. Предполагается, что этот случай будет нормой для устройств с интерфейсами без поддержки преобразования длин волн (CI-incapable).

Использование Label Set не является обязательным. При отсутствии такого набора могут применяться из числа приемлемых. Концептуально, отсутствие Label Set эквивалентно получения набора {U}, содержащего все приемлемые метки.

3.5.1. Требуемая информация

Набор меток состоит из одного или множества объектов/TLV Label_Set, содержащих по одному или более элементов Label Set. Элемент называется идентификатором субканала и его формат совпадает с форматом обобщенной метки.

Label_Set включает:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Action     |      Reserved     |        Label Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Subchannel 1                         |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                               :                               :
   :                               :                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Subchannel N                         |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Action (действие) — 8 битов

0 — Inclusive List — список включения

Показывает, что объект/TLV содержит один или множество элементов субканалов, включенных в Label Set.

1 — Exclusive List — список исключения

Показывает, что объект/TLV содержит один или множество элементов субканалов, исключенных из Label Set.

2 — Inclusive Range — диапазон включения

Показывает, что объект/TLV содержит диапазон меток. Объект/TLV включает два элемента субканалов — первый задает начало, второй — конец диапазона. Нулевое значение элемента указывает на отсутствие привязки для соответствующей границы.

3 — Exclusive Range — диапазон исключения

Показывает, что объект/TLV содержит диапазон меток, исключенных из Label Set. Объект/TLV включает два элемента субканалов — первый задает начало, второй — конец диапазона. Нулевое значение элемента указывает на отсутствие привязки для соответствующей границы.

Reserved — 10 битов

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

Label Type (тип метки) — 14 битов

Указывает тип и формат меток, передаваемых в объекте /TLV. Значения зависят от сигнального протокола.

Subchannel (субканал) — субканал

Два субканала представляют метку (длину волны, волокно, …), которая может быть выделена. Это поле иметт такой же формат, как указано для меток в параграфе 3.2.

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

4. Двухсторонние LSP

В этом разделе определяется прямая поддержка двухсторонних LSP. Поддержка определяется для LSP, имеющих для обоих направлений одинаковые требования по организации трафика, включая совместное использование для данных и сигнализации (fate sharing), защиту и восстановление, маршрутизаторы LSR и требования к ресурсам (например, задержка и ее вариации). Далее в этом разделе термином «инициатор» (initiator) будет обозначаться узел, который начал организацию LSP, а термином «завершение» (terminator) — узел, являющийся целью данного LSP. Отметим, что для двухсторонних имеется лишь один инициатор и одно завершение.

Обычно для организации двухстороннего LSP при использовании [RFC3209] или [RFC3212] сначала должны независимо создаваться два односторонних пути. Такая модель имеет ряд недостатков.

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

  • Издержки, связанные с управлением, возрастают вдвое по сравнению с односторонним LSP. Это обусловлено тем, что управляющие соединения (например, Path и Resv) должны независимо генерироваться для обоих сегментов двухстороннего LSP.

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

  • Сложнее обеспечить «чистый» интерфейс для оборудования SONET/SDH, на котором может быть основана поинтервальная защита пути с помощью коммутации.

  • Двухсторонние оптические LSP (lightpath) становятся требованием для многих операторов оптических сетей.

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

4.1. Требуемая информация

Для двухсторонних LSP должны выделяться две метки. Организация двухстороннего LSP указывается присутствием объекта/TLV Upstream Label в соответствующем сигнальном сообщении. Формат Upstream Label совпадает с форматом обобщенной метки (параграф 3.2).

4.2. Устранение конфликтов

Могут возникать конфликты из-за выделения меток между двумя двухсторонними LSP, организуемыми в противоположных направлениях. Это происходит в тех случаях, когда обе стороны выделяют одни и те же ресурсы (метки) фактически в одно время. Если нет каких-либо ограничений на использование меток для двухсторонних LSP и имеются дополнительные ресурсы, оба узла будут передавать в восходящем направлении разные метки и конфликта не произойдет. Однако при наличии ограничений на использование меток для двухсторонних LSP (например, они должны быть физически связаны с одной платой ввода-вывода) или отсутствии дополнительных ресурсов требуется разрешение конфликтной ситуации иными средствами. Для устранения конфликта преимущество отдается узлу с большим значением идентификатора (node ID) и этот узел должен передать сообщение PathErr/NOTIFICATION с индикацией ошибки Routing problem/Label allocation failure (проблема маршрутизации или отказ при выделении метки). Получившему такое сообщение узлу следует попытаться выделить другую метку Upstream (и другую Suggested Label, при использовании предлагаемых меток) для двухстороннего пути. Однако при отсутствии доступных ресурсов узел должен выполнить стандартную обработку ошибок.

Для снижения вероятности конфликта можно ввести правило, в соответствии с которым узел с меньшим значением ID никогда не будет предлагать метку в нисходящем направлении и всегда воспринимать Suggested Label от узла восходящего направления с большим ID. Кроме того, поскольку обмен метками может происходить с использованием LMP, можно дополнительно ввести локальное правило (по отношению к меткам с большими номерами из набора меток узла), по которому узел с большим номером может выбирать метки со старшего края диапазона меток, а узел с меньшим номером — с младшего. Этот механизм позволяет усилить алгоритмы плотной упаковки, которые могут применяться для оптимизации диапазонов или длин волн. Следует отметить особый случай использования RSVP с поддержкой этого решения — идентификатор соседнего узла может быть не известен при отправке первоначального сообщения Path. В такой ситуации узлу следует предлагать случайно выбранную метку из числа доступных.

Пример конфликта между двумя узлами (PXC 1 и PXC 2) показан на рисунке 1. В этом примере PXC 1 выделяет метку Upstream Label для канала, соответствующего локальному идентификатору BCId=2 (локальный BCId=7 на PXC 2) и отправляет Suggested Label для канала, соответствующего локальному BCId=1 (локальный BCId=6 на PXC 2). Одновременно PXC 2 выделяет метку Upstream Label для канала, соответствующего его локальному BCId=6 (локальный BCId=1 на PXC 1) и передает Suggested Label для канала, соответствующего его локальному BCId=7 (локальный BCId=2 на PXC 1). Если нет ограничений на метки, которые могут использоваться для двухсторонних LSP и имеются дополнительные ресурсы оба узла PXC 1 и PXC 2 будут передавать в восходящем направлении разные метки и конфликт будет устранен (рисунок 2). Однако при наличии ограничений на метки, которые могут применяться для двухсторонних LSP (например, если они должны быть физически привязаны к одной плате ввода-вывода), потребуется устранение конфликта с использованием идентификатора узла (рисунок 3).

+------------+                         +------------+
+   PXC 1    +                         +   PXC 2    +
+            +                 SL1,UL2 +            +
+          1 +------------------------>+ 6          +
+            + UL1, SL2                +            +
+          2 +<------------------------+ 7          +
+            +                         +            +
+            +                         +            +
+          3 +------------------------>+ 8          +
+            +                         +            +
+          4 +<------------------------+ 9          +
+------------+                         +------------+

Рисунок 1. Конфликт меток

В этом примере PXC 1 выделяет метку Upstream Label, используя BCId=2 (BCId=7 на PXC 2), и метку Suggested Label, используя BCId=1 (BCId=6 на PXC 2). Одновременно PXC 2 выделяет метку Upstream Label, используя BCId=6 (BCId=1 на PXC 1), и Suggested Label, используя BCId=7 (BCId=2 на PXC 1).

+------------+                         +------------+
+   PXC 1    +                         +   PXC 2    +
+            +                     UL2 +            +
+          1 +------------------------>+ 6          +
+            + UL1                     +            +
+          2 +<------------------------+ 7          +
+            +                         +            +
+            +                      L1 +            +
+          3 +------------------------>+ 8          +
+            + L2                      +            +
+          4 +<------------------------+ 9          +
+------------+                         +------------+

Рисунок 2. Устранение конфликта при неограниченных ресурсах.


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

+------------+                         +------------+
+   PXC 1    +                         +   PXC 2    +
+            +                     UL2 +            +
+          1 +------------------------>+ 6          +
+            + L2                      +            +
+          2 +<------------------------+ 7          +
+            +                         +            +
+            +                      L1 +            +
+          3 +------------------------>+ 8          +
+            +  UL1                    +            +
+          4 +<------------------------+ 9          +
+------------+                         +------------+

Рисунок 3. Устранение конфликта при ограниченных ресурсах.


В этом случае должны использоваться метки 1,2 и 3,4 на PXC 1 (метки 6,7 и 8,9 на PXC 2, соответственно) для одного двухстороннего соединения. Поскольку узел PXC 2 имеет большее значение идентификатора, ему отдается преимущество и узел PXC 1 должен поменять используемый набор меток.

5. Уведомление о Label Error

В традиционной MPLS и GMPLS возникают ситуации, приводящие к сообщениям о неприемлемом значении метки (Unacceptable label value), как описано в [RFC3209], [RFC3472] и [RFC3473]. При возникновении таких ситуаций для узла, генерирующего такое сообщение может оказаться полезным указание вызвавшей ошибку метки. Для этого в GMPLS обеспечивается возможность передачи дополнительных данных поле Acceptable Label Set, включаемое в подходящее протокольное сообщение об ошибке (см. [RFC3472] и [RFC3473]).

Формат Acceptable Label Set идентичен формату Label Set, описанному в параграфе 3.5.1.

6. Явное управление метками

В традиционной MPLS интерфейсы, используемые LSP могут контролироваться через явные маршруты (например, ERO или ER-Hop). Это позволяет включать конкретный узел/интерфейс и завершать LSP на конкретном выходном интерфейсе выходного LSR. Этот интерфейс может иметь адрес, но это не обязательно (unnumbered) [MPLS-UNNUM].

Возникают случаи, когда семантика наличия явных маршрутов не обеспечивает полной информации для достаточного контроля LS. Это происходит, если инициатор LSP пожелает выбрать метку, используемую на канале. Проблема, в частности, связана с тем, что ERO и ER-Hop не поддерживают субобъектов явных меток. Примером желательности такого механизма будет случай «сращивания» двух LSP, когда «голова» одного пути присоединяется к «хвосту» другого. Возникновение таких ситуаций достаточно очевидно для каналов без поддержки PSC.

Для решения этой проблемы предназначен субобъект ERO/ER Hop.

6.1. Требуемая информация

Label Explicit и Record Routes собержат:

L — 1 бит

Этот бит должен иметь значение 0.

U — 1 бит

Этот бит указывает направление метки — значение 0 применяется для меток нисходящего направления, 1 — для восходящего. Бит применяется только для двухсторонних LSP.

Label — переменный размер

Это поле идентифицирует используемую метку. Формат поля идентичен формату поля Label в Generalized Label, описанному в параграфе 3.2.1.

Размещение и порядок этих полей зависит от протокола сигнализации.

7. Информация о защите

Информация о защите (Protection Information) передается в новом объекте/TLV и служит для указания связанных с соединением атрибутов защиты запрошенного LSP. Использование Protection Information для конкретного LSP является не обязательным. Protection Information в настоящее время указывает желаемый тип защиты LSP. Если запрошен конкретный тип (например, 1+1 или 1:N), запрос на организацию соединения обрабатывается лишь в том случае, когда этот уровень защиты может быть обеспечен. Отметим, что возможности защиты каналов могут анонсироваться в маршрутизации (см. [GMPLS-RTG]). Алгоритмы расчета путем принимают информацию о защите во внимание при поиске пути для организации LSP.

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

7.1. Требуемая информация

В Protection Information передаются следующие данные:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|                  Reserved                       | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Secondary (S) 1 бит

Установка этого флага показывает, что запрашиваемый LSP является вторичным LSP.

Reserved 25 битов

Это поле является резервным. Оно должно содержать нулевое значение при передаче и должно игнорироваться на приемной стороне. Транзитным узлам следует передавать эти биты в неизменном виде.

Link Flags 6 битов

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

Определены следующие флаги:

0x20 Enhanced

Указывает, что следует использовать на канальном уровне схему защиты, которая более надежна, чем Dedicated 1+1 (например, 4 волокна BLSR/MS-SPRING).

0x10 Dedicated 1+1

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

0x08 Dedicated 1:1

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

0x04 Shared

Указывает, что для поддержки LSP следует использовать схему защиты с разделяемым соединением канального уровня (например, 1:N).

0x02 Unprotected

Показывает, что для LSP не следует использовать какую-либо защиту на канальном уровне.

0x01 Extra Traffic

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

8. Информация об административном статусе

Данные Administrative Status Information передаются в новом объекте/TLV и используются в настоящее время двумя способами. Во-первых, они показывают административный статус конкретного LSP. Путь может находиться в состоянии up (активен) или down (не активен), а также в режиме тестирования (testing) или удаления. Предпринимаемые узлом действия, основанные на состоянии пути, определяются локально. Примером таких действий может служить подавление сигналов тревоги для LSP в состоянии down или testing, а также информирование о связанных с соединением сигналах, имеющих приоритет не выше Non service affecting (без воздействия на сервис).

Второй вариант использования Administrative Status Information связан с индикацией запросов на установку административного состояния LSP. Информация всегда транслируется входному узлу, который действует по запросу.

Различия в применении зависят от протокола и более подробно описаны в [RFC3473] и [RFC3472]. Применение Administrative Status Information для конкретного LSP не является обязательным.

8.1. Требуемая информация

Информация, передаваемая в Administrative Status Information, показана ниже.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                        Reserved                       |T|A|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reflect (R) — 1 бит

Установленный бит говорит, что граничному узлу следует вернуть объект/TLV в подходящем для этого сообщении. Этот флаг недопустимо устанавливать в запросах смены состояния (например, сообщениях Notify).

Reserved — 28 битов

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

Testing (T) — 1 бит

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

Administratively down (A) — 1 бит

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

Deletion in progress (D) — 1 бит

Установленный флаг показывает, что следует выполнить локальные действия, связанные с разборкой LSP. Граничные узлы могут использовать этот флаг для контроля за разрывом соединений.

9. Разделение каналов управления

Концепция канала управления, отдельного от сигнализации, передаваемой в канале данных, была введена в MPLS вместе с группировкой соединений (bundling) в [MPLS-BUNDLE]. В GMPLS разделение каналов данных и управления может быть обусловлено многими факторами, включая группировку и другие случаи, когда каналы данных не могут передаваться вместе с управляющей информацией в основной полосе. В этом разделе рассматриваются два тесно связанных вопроса — идентификация каналов данных в сигнализации и обработка отказов в каналах управления, не влияющих на каналы данных.

9.1. Идентификация интерфейсов

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

В тех случаях, когда явно нет взаимно-однозначной связи между каналом данных и каналом управления, в сигнализации требуется передать дополнительную информацию, идентифицирующую канал данных, для которого будет осуществляться управление. GMPLS поддерживает явную идентификацию каналов данных с помощью идентификаторов интерфейсов. GMPLS позволяет использовать множество схем идентификации интерфейсов, включая адреса IPv4 и IPv6, индексы интерфейсов (см. [MPLS-UNNUM]) и компоненты интерфейсов (организуются путем настройки или с помощью протоколов типа [LMP]). Во всех случаях выбор интерфейса указывается узлом восходящего направления с использованием адресов и идентификатором, применяемых вышестоящим узлом.

9.1.1. Требуемая информация

Информация, передаваемая в 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                              TLV                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Для каждого TLV используется показанный ниже формат.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Value                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length — 16 битов

Показывает общий размер TLV (4 + размер поля Value) в октетах. Для полей Value, размер которых не кратен 4, должно использоваться дополнение нулями для выравнивания по 4-октетной границе.

Type — 16 битов

Указывает тип идентифицируемого интерфейса. Определенные значения показаны ниже.

Тип

Размер

Формат

Описание

1

8

Адрес IPv4

IPv4

2

20

Адрес IPv6

IPv6

3

12

См. ниже IF_INDEX

Индекс интерфейса

4

12

См. ниже COMPONENT_IF_DOWNSTREAM

Компонентный интерфейс

5

12

См. ниже COMPONENT_IF_UPSTREAM

Компонентный интерфейс

Для типов 3 — 5 поле Value имеет формат, показанный ниже.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            IP Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Interface ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP Address — 32 бита

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

Interface ID — 32 бита

Для типа 3 поле Interface ID содержит идентификатор интерфейса.

Для типов 4 и 5 поле Interface ID указывает собранный компонентный канал. Может использоваться специальное значение 0xFFFFFFFF для индикации того, что одна и та же метка применима ко всем компонентым каналам.

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

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

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

Оба случая обрабатываются в зависимости от протокола 9см. [RFC3473] и [RFC3472]).

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

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

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

Были получены полезные комментарии и предложения от многих людей, включая Igor Bryskin, Adrian Farrel, Ben Mack-Crane, Dimitri Papadimitriou, Fong Liaw и Juergen Heiles. Некоторые разделы документа основаны на тексте, представленном Fong Liaw.

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

Этот документ не порождает новых вопросов безопасности по сравнению с отмеченными в [RFC3212] и [RFC3209], которые к соответствующим определяемым протоколами формам GMPLS (см. [RFC3473] и [RFC3472]).

12. Согласование с IANA

IANA будет администрировать выделение новых значений в пространствах имен, определенных в данном документе. В этом параграфе используется терминология BCP 26 «Guidelines for Writing an IANA Considerations Section in RFCs» [BCP26].

В данном документе определены следующие пространства имен:

  • LSP Encoding Type — 8 битов;

  • Switching Type — 8 битов;

  • Generalized PID (G-PID) — 16 битов;

  • Action — 8 битов;

  • Interface_ID Type — 16 битов.

Все новые значения следует выделять по процедуре IETF Consensus или документировать в спецификации.

LSP Encoding Type — допустимы значения от 1 до 255 (включительно), данный документ определяет значения 1 — 11.

Switching Type — допустимы значения от 1 до 255 (включительно), данный документ определяет значения 1 — 4, 100, 150 и 200.

Generalized PID (G-PID) — допустимы значения от 0 до 1500 (включительно), данный документ определяет значения 0 — 46.

Action — допустимы значения от 1 до 255 (включительно), данный документ определяет значения 0 — 3.

Interface_ID Type — допустимы значения от 1 до 65535 (включительно), данный документ определяет значения 1 — 5.

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

Текст этого раздела взят из параграфа 10.4 работы [RFC2026].

The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF’s procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

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

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

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

[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, «LDP Specification», RFC 303611, January 2001.

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

[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, «Constraint-Based LSP Setup using LDP», RFC 3212, January 2002.

[RFC3472] Ashwood-Smith, P. and L. Berger, Editors, «Generalized Multi-Protocol Label Switching (GMPLS) Signaling — Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions», RFC 3472, January 2003.

[RFC3473] Berger, L., Editor «Generalized Multi-Protocol Label Switching (GMPLS) Signaling — Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions», RFC 3473, January 2003.

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

[GMPLS-RTG] Kompella, K., et al., «Routing Extensions in Support of Generalized MPLS», Work in Progress12.

[GMPLS-SONET] Ashwood-Smith, P., et al., «GMPLS — SONET / SDH Specifics», Work in Progress.

[LMP] Lang, et al., «Link Management Protocol», Work in Progress13.

[MPLS-BUNDLE] Kompella, K., Rekhter, Y. and L. Berger, «Link Bundling in MPLS Traffic Engineering», Work in Progress14.

[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, «LSP Hierarchy with MPLS TE», Work in Progress15.

[RFC2026] Bradner, S., «The Internet Standards Process – Revision 3,» BCP 9, RFC 2026, October 1996.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, «Multiprotocol label switching Architecture», RFC 3031, January 2001.

15. Разработчики

Peter Ashwood-Smith

Nortel Networks Corp.

P.O. Box 3511 Station C,

Ottawa, ON K1Y 4H7

Canada

Phone: +1 613 763 4534

EMail: petera@nortelnetworks.com

Ayan Banerjee

Calient Networks

5853 Rue Ferrari

San Jose, CA 95138

Phone: +1 408 972-3645

EMail: abanerjee@calient.net

Lou Berger

Movaz Networks, Inc.

7926 Jones Branch Drive

Suite 615

McLean VA, 22102

Phone: +1 703 847-1801

EMail: lberger@movaz.com

Greg Bernstein

EMail: gregb@grotto-networking.com

John Drake

Calient Networks

5853 Rue Ferrari

San Jose, CA 95138

Phone: +1 408 972 3720

EMail: jdrake@calient.net

Yanhe Fan

Axiowave Networks, Inc.

200 Nickerson Road

Marlborough, MA 01752

Phone: + 1 774 348 4627

EMail: yfan@axiowave.com

Kireeti Kompella

Juniper Networks, Inc.

1194 N. Mathilda Ave.

Sunnyvale, CA 94089

EMail: kireeti@juniper.net

Jonathan P. Lang

EMail: jplang@ieee.org

Eric Mannie

Independent Consultant

2 Avenue de la Folle Chanson

1050 Brussels

Belgium

EMail: eric_mannie@hotmail.com

Bala Rajagopalan

Tellium, Inc.

2 Crescent Place

P.O. Box 901

Oceanport, NJ 07757-0901

Phone: +1 732 923 4237

Fax: +1 732 923 9804

EMail: braja@tellium.com

Yakov Rekhter

Juniper Networks, Inc.

EMail: yakov@juniper.net

Debanjan Saha

EMail: debanjan@acm.org

Vishal Sharma

Metanoia, Inc.

1600 Villa Street, Unit 352

Mountain View, CA 94041-1174

Phone: +1 650-386-6723

EMail: v.sharma@ieee.org

George Swallow

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA 01824

Phone: +1 978 244 8143

EMail: swallow@cisco.com

Z. Bo Tang

EMail: botang01@yahoo.com

16. Адрес редактора

Lou Berger

Movaz Networks, Inc.

7926 Jones Branch Drive

Suite 615

McLean VA, 22102

Phone: +1 703 847-1801

EMail: lberger@movaz.com

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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

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

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

1Multi-Protocol Label Switching — многопротокольная коммутация по меткам.

2Generalized MPLS — обобщенная MPLS.

3Synchronous Optical Network, Synchronous Digital Hierarchy.

4Label Switching Router — маршрутизатор с коммутацией по меткам.

5Packet-Switch Capable — способные коммутировать пакеты.

6Time-Division Multiplex Capable — поддерживающие мультиплексирование с разделением по времени.

7Lambda Switch Capable — способные коммутировать по длине волны (лямбда).

8Fiber-Switch Capable — способные коммутировать волокна.

9Label Switched Path — путь с коммутацией по меткам.

10Forwarding Adjacency – смежность по пересылке.

11Этот документ признан устаревшим и заменен RFC 5036. Прим. перев.

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

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

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

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




RFC 3448 TCP Friendly Rate Control (TFRC): Protocol Specification

Network Working Group                                     M. Handley
Request for Comments: 3448                                  S. Floyd
Category: Standards Track                                       ICIR
                                                           J. Padhye
                                                           Microsoft
                                                           J. Widmer
                                              University of Mannheim
                                                        January 2003

 

Дружественный к TCP контроль скорости (TFRC) — спецификация протокола

TCP Friendly Rate Control (TFRC): Protocol Specification

PDF

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

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

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

Copyright (C) The Internet Society (2003). All Rights Reserved.

Тезисы

В этом документе приведена спецификация протокола TFRC2, который представляет собой механизм контроля насыщения для потоков с индивидуальной адресацией в среде Internet, обеспечивающей доставку по-возможности3. Этот механизм обеспечивает достаточно беспристрастное деление полосы с конкурирующими потоками TCP, но отличается значительно меньшими временными вариациями пропускной способности по сравнению с TCP, что делает этот механизм более подходящим для таких приложений, как телефония или потоковая передача, где важна постоянная скорость потока данных.

Оглавление

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

1. Введение

В этот документе содержится спецификация TFRC, представляющего собой механизм контроля насыщения, разработанный для потоков данных с индивидуальной адресацией в среде Internet, передаваемых одновременно с трафиком TCP [2]. Вместо задания протокола целиком в этом документе дается спецификация механизма контроля насыщения, который может использоваться транспортными протоколами типа RTP [7] в приложениях, включающих сквозной контроль насыщения на уровне приложений, или в контексте контроля насыщения на конечных точках [1]. В документе не рассматриваются форматы пакетов и вопросы надежности. Связанные с реализациями вопросы достаточно кратко рассмотрены в главе 8.

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

Платой за более стабильную пропускную способность по сравнению с TCP в условиях конкуренции за полосу является более медленная реакция TFRC на изменение доступной полосы пропускания. Таким образом, TFRC следует использовать лишь в тех случаях, когда приложениям требуется стабильная пропускная способность и, в частности, предотвращение двукратного снижения скорости передачи, принятого в TCP в ответ на отбрасывание одного пакета. Для приложений, которым просто нужно передать данные за возможно кратчайшее время, рекомендуется использовать TCP или, в тех случаях, когда надежность не требуется, механизм контроля насыщения AIMD4 с параметрами, близкими к тем, которые применяются в TCP.

Механизм TFRC разработан для приложений, которые используют пакеты фиксированного размера и меняют скорость передачи таких пакетов в ответ на возникновение перегрузок (насыщения). Для некоторых звуковых приложений требуется обеспечение фиксированного интервала времени между передачей последовательных пакетов и варьирование размера пакетов в ответ на возникновение перегрузки. Механизм контроля насыщения, предложенный в этом документе, для таких приложений не подходит, однако эту задачу решает механизм TFRC-PS5, являющийся вариантом TFRC для приложений с фиксированной частотой передачи и изменением размера пакетов при возникновении насыщения. Спецификация TFRC-PS будет приведена в отдельном документе6.

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

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

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14, RFC 2119 и показывают уровень требований к реализациям в части соответствия TFRC.

3. Механизм протокола

Для контроля насыщения TFRC напрямую использует уравнение пропускной способности для разрешенной скорости передачи, как функции от частоты фактов потери пакетов и времени кругового обхода. Для беспристрастной конкуренции с TCP, механизм TFRC использует принятое в TCP уравнение для пропускной способности, выражающее скорость передачи TCP, как функцию от частоты фактов потери пакетов, времени кругового обхода и размера сегментов. Определим факт потери, как случай утраты одного или более маркированного пакета из окна данных; маркированными считаются пакеты, помеченные явным индикатором насыщения ECN7 [6].

В общем виде механизм контроля насыщения TFRC можно описать следующим образом:

  • Получатель определяет частоту фактов потери пакетов и передает эту информацию отправителю.
  • Отправитель использует эти сообщения от получателя для определения времени кругового обхода (RTT8).
  • Значения частоты фактов потери и RTT передаются в уравнение пропускной способности TFRC и результирующая скорость передачи ограничена значением не более удвоенной скорости приема.
  • Отправитель подстраивает скорость передачи в соответствии с допустимой скоростью передачи X.

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

3.1. Уравнение для пропускной способности TCP

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

Уравнение пропускной способности, которое мы рекомендуем для использования в TFRC, является слегка упрощенным вариантом уравнения для Reno TCP из работы [4]. В идеальном случае уравнение для пропускной способности следовало бы создавать на основе SACK9 TCP, однако тесты и эксперименты показывают, что различия между двумя уравнениями достаточно малы.

Пропускная способность выражается уравнением

                                  s
X = --------------------------------------------------------------
    R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2)))

где:

X — скорость передачи (байт/сек);

s — размер пакетов (байт);

R — время кругового обхода в секундах;

p — вероятность потерь (0 — 1.0) — доля потерянных пакетов в от общего числа переданных пакетов;

t_RTO — тайм-аут повторной передачи TCP в секундах;

b — число пакетов, подтверждаемых одним пакетом TCP ACK.

Упростим это выражение, приняв t_RTO = 4*R. Возможен более точный расчет t_RTO, однако эксперименты с выбранным значением показали достаточно беспристрастное деление полосы с существующими реализациями TCP [9]. Другим возможным вариантом является выбор для t_RTO большего из 2 значений (4R, 1 секунда) в соответствии с рекомендациями по установке для RTO значения не меньше 1 секунды [5].

Многие соединения TCP используют режим отложенных подтверждений, когда пакет подтверждения передается для каждого второго принятого пакета (b = 2). Однако TCP позволяет передавать подтверждения для каждого пакета (b = 1). Поскольку множество реализаций TCP не использует режима отложенных подтверждений, рекомендуется использовать b = 1.

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

Параметры s (размер пакета), p (вероятность потери) и R (RTT) должны измеряться или рассчитываться реализацией TFRC. Измерение s рассматривается в параграфе 4.1, измерение R — в параграфе 4.3, а измерение p — в разделе 5. Далее в этом документе все значения скоростей приводятся в байтах/сек.

3.2. Содержимое пакетов

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

3.2.1. Пакеты данных

Каждый пакет данных, передаваемый отправителем, содержит следующую информацию:

  • Порядковый номер. Этот номер увеличивается на 1 с каждым переданным пакетом. Поле должно быть достаточно большим, чтобы в списке недавних пакетов получателя не появлялись разные пакеты с одинаковым порядковым номером.
  • Временная метка момента передачи. Будем обозначать ts_i временную метку пакета с порядковым номером i. Разрешение для временных меток обычно измеряется миллисекундами. Эти временные метки используются получателем для определения потерь пакетов, которые следует отнести к одному событию (факту потери). Эти метки получатель возвращает отправителю в качестве «эхо» для того, чтобы тот мог оценить время кругового обхода (это нужно для отправителей, не сохраняющих временных меток переданных пакетов). Отметим, что существует альтернативный вариант использования временных меток, когда значение метки инкрементируется каждую четверть времени кругового обхода; такой точности достаточно для отнесения потерь пакетов к одному событию в контексте протокола, где это понятно как отправителю, так и получателю, а отправитель сохраняет временные метки переданных пакетов.
  • Оценка времени кругового обхода отправителем. Оценка, передаваемая в пакете i обозначается R_i. Оценка времени кругового обхода используется получателем вместе с временными метками для определения множества потерь пакетов, относящихся к одному событию. Если отправитель передает передает грубые «временные метки», которые увеличиваются каждую четверть периода кругового обхода, как описано выше, такому отправителю не нужно передавать свою оценку времени кругового обхода.

3.2.2. Пакеты обратной связи

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

  • Временная метка последнего принятого пакета (t_recvdata). Если последний принятый пакет имеет номер i, то t_recvdata = ts_i. Эта временная метка используется отправителем для оценки времени кругового обхода и требуется только в тех случаях, когда отправитель не сохраняет временные метки переданных пакетов данных.
  • Интервал времени между приемом последнего пакета и генерацией данного пакета обратной связи. Будем обозначать этот интервал t_delay.
  • Оценка получателем скорости приема данных с момента отправки последнего пакета обратной связи. Будем обозначать этот интервал X_recv.

  • Текущее значение вероятности потери по оценке получателя (p).

4. Протокол отправителя данных

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

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

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

4.1. Измерение размера пакетов

Параметр s (размер пакета) обычно известен приложению, но могут быть два исключительных случая:

  • Размер пакетов данных меняется естественным образом в зависимости от данных. В этом случае, хотя размер пакетов меняется, его вариации не отражаются на скорости передачи. Обычно можно без опаски использовать средний размер пакета в качестве s.
  • Для контроля насыщения приложение может менять размер пакетов, а не скорость их передачи. Это обычная практика для аудио-приложений, в которых пакеты данных передаются с фиксированным интервалом, требуемым для представления каждого пакета. Для таких приложений требуется совершенно иной способ измерения параметров.

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

4.2. Инициализация отправителя

Для инициализации отправителя устанавливается скорость передачи X = 1 пакет/сек и таймер обратной связи — 2 секунды. Начальные значения R (RTT) и t_RTO остаются неопределенными, пока не будут установлены в соответствии с приведенными ниже рекомендациями. Начальное значение tld11 при замедленном старте устанавливается равным -1.

4.3. Поведение отправителя при получении пакета обратной связи

Отправитель знает свою текущую скорость передачи X и поддерживает оценку текущего значения времени кругового обхода R, а также оценивает значение тайм-аута повторной передачи t_RTO.

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

  1. Рассчитывается новое значение времени кругового обхода:

R_sample = (t_now - t_recvdata) - t_delay
  1. Обновляется оценка времени кругового обхода:
Если ранее не было получено пакета обратной связи
   R = R_sample;
иначе
   R = q*R + (1-q)*R_sample;

Алгоритм TFRC не чувствителен к точному значению константы q, но рекомендуется задавать значение 0.9.

  1. Обновляется значение тайм-аута:

t_RTO = 4*R
  1. Обновляется значение скорости передачи:
If (p > 0)
  ;X_calc рассчитывается с использованием уравнения для пропускной способности TCP.
   X = max(min(X_calc, 2*X_recv), s/t_mbi);
Else
   If (t_now - tld >= R)
      X = max(min(2*X, 2*X_recv), s/R);
      tld = t_now;

Отметим, что при p == 0 отправитель находится в фазе замедленного старта, в которой он приблизительно удваивает скорость передачи в течение каждого периода кругового обхода, если не наблюдается фактов потери. Значение s/R дает минимальную скорость передачи в процессе замедленного старта — 1 пакет за время RTT. Параметр t_mbi имеет значение 64 секунды и показывает максимальный интервал между передачей пакетов12 при сохраняющемся отсутствии пакетов обратной связи. Таким образом, при p > 0 отправитель передает по крайней мере каждые 64 секунды.

  1. Сбрасывается таймер обратной связи по истечении max(4*R, 2*s/X) секунд.

4.4. Завершение отсчета таймера обратной связи

Если отсчет таймера обратной связи завершился, отправителю следует выполнить следующие операции:

  1. Снизить скорость передачи вдвое. Если отправитель принимал от получателя пакеты обратной связи снижение осуществляется путем изменения кэшированной отправителем копии X_recv (скорость приема). Поскольку скорость передачи ограничена значением, не превышающим 2 * X_recv, изменение X_recv будет ограничивать текущую скорость передачи, но позволит отправителю использовать замедленный старт, удваивая скорость передачи через каждый интервал RTT, если пакеты обратной связи будут говорить об отсутствии потерь.

If (X_calc > 2*X_recv)
   X_recv = max(X_recv/2, s/(2*t_mbi));
Else
   X_recv = X_calc/4;

Значение s/(2*t_mbi) не позволяет снижение скорости передачи до значений менее 1 пакета за 64 секунды в случаях постоянного отсутствия пакетов обратной связи.

  1. После этого должно быть пересчитано значение X в соответствии с п 4 в предыдущем параграфе.

Если отсчет таймера обратной связи завершается, когда у отправителя еще нет образца RTT и он не получал еще пакетов обратной связи, этап 1) можно пропустить и напрямую снизить скорость передачи вдвое:

X = max(X/2, s/t_mbi)
  1. Перезапустить таймер обратной связи по истечении max(4*R, 2*s/X) секунд.

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

Если отправитель бездействует с момента запуска таймера обратной связи и значение X_recv меньше 4 пакетов за время кругового обхода, значение X_recv не следует уменьшать вдвое по завершении отсчета таймера. Это позволяет никогда не снижать скорость передачи менее 2 пакетов за время кругового обхода в результате бездействия.

4.5. Предотвращение осцилляций

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

Если ранее не было получено пакетов обратной связи
   R_sqmean = sqrt(R_sample);
иначе
   R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);

Таким образом, R_sqmean изменяется пропорционально квадратному корню измеренного значения RTT. Константу q2 следует устанавливать по аналогии с q; по умолчанию рекомендуется использовать значение 0,9.

Отправитель получает базовое значение скорости передачи X из уравнения пропускной способности. После этого отправитель рассчитывает новое значение скорости передачи X_inst следующим образом:

X_inst = X * R_sqmean / sqrt(R_sample);

Когда sqrt(R_sample) больше R_sqmean, очередь обычно увеличивается и для стабильной работы требуется снижение скорости передачи.

Примечание. Такое изменение требуется не во всех случаях, особенно при высоком уровне статистического мультиплексирования в сети. Однако рекомендуется вносить это изменение поскольку оно улучшает поведение TFRC в средах с низким уровнем статистического мультиплексирования. Если это изменение не выполняется, рекомендуется использовать очень малые значения q (0 или близкие к нулю значения).

4.6. Планирование передачи пакетов

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

t_ipi = s/X_inst;

Когда отправитель начинает передачу в момент t_0, он рассчитывает значение t_ipi и номинальное время передачи пакета 1 будет t_1 = t_0 + t_ipi. Когда приложение простаивает, оно проверяет текущее значение t_now и запрашивает повторный расчет интервала по истечении t_ipi — (t_now — t_0) секунд. Когда приложение снова планирует передачу, оно опять проверяет текущее значение t_now. Если t_now > (t_1 — delta), пакет 1 передается.

В этот момент рассчитывается новое значение t_ipi, которое применяется для расчета времени передачи t_2 для пакета 2 — t2 = t_1 + t_ipi. Этот процесс повторяется для каждого пакета с отсчетом времени от номинального момента передачи предыдущего пакета.

В некоторых случаях, когда номинальное время передачи следующего пакета t_i рассчитано, может оказаться, что t_now > t_i — delta. В таких случаях пакет следует передавать без промедления. Таким образом, если операционная система обеспечивает лишь грубую гранулярность таймеров и скорость передачи высока, TFRC может передавать короткие группы пакетов, разделенные интервалами с гранулярностью таймера операционной системы.

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

delta = min(t_ipi/2, t_gran/2);

t_gran равно 10 мсек для многих Unix-систем. Если значение t_неизвестно, обычно можно без опасений принимать его равным 10 мсек.

5. Расчет частоты потерь (p)

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

5.1. Детектирование потерь и маркированные пакеты

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

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

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

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

5.2. Трансляция истории потерь в факт потери

TFRC требует устойчивости к нескольким последовательным потерям пакетов, когда эти потери относятся к одному событию (факту потери). Это похоже на поведение протокола TCP, который (обычно) лишь однократно за период RTT уменьшает наполовину окно насыщения. Таким образом, получатель должен отобразить историю потери пакетов в запись о факте потери, трактуя как факт потери утрату одного или более пакетов в течение периода RTT. Для выполнения такого отображения получателю нужно знать значение RTT, которое обычно периодически сообщается отправителем в форме управляющей информации, присоединяемой в конце пакета данных. Для TFRC способ передачи результатов измерения RTT получателю не имеет значения, однако рекомендуется использовать для этого рассчитанное отправителем значение RTT (R в параграфе 4.3).

Для того, чтобы определить, относится потеря или маркированный пакет к новому факту потери или является продолжением существующего, нужно сравнить порядковые номера и временные метки пакетов, принятых получателем. Для маркированного пакета S_new время приема T_new можно определить напрямую. Для потерянного пакета нужно использовать интерполяцию, чтобы определить номинальное «время прибытия». Предположим, что:

S_loss — порядковый номер потерянного пакета;

S_before — порядковый номер последнего пакета, прибывшего с номером меньше S_loss;

S_after — порядковый номер первого пакета, прибывшего с номером больше S_loss;

T_before — время приема S_before;

T_after — время приема S_after.

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

Для потерянного пакета S_loss можно интерполировать его номинальное «время доставки» на основе значений S_before и S_after:

T_loss = T_before + ((T_after — T_before) * (S_loss - S_before)/(S_after - S_before));

Отметим, что в тех случаях, когда между порядковыми номерами S_before и S_after наблюдался переход через 0, порядковые номера следует изменить с учетом этого факта до выполнения расчетов. Если больший порядковый номер имеет значение S_max b S_before > S_after, замены каждого номера S на S’ = (S + (S_max + 1)/2) mod (S_max + 1) будет достаточно.

Если было определено, что потерянный пакет S_old служит началом нового факта потери и мы определили, что пакет S_new был потерян, мы интерполируем номинальное время прибытия пакетов S_old и S_new, как T_old и T_new, соответственно.

Если T_old + R >= T_new, потеря пакета S_new относится к текущему факту потери, в противном случае S_new является первым пакетом, относящимся к новому факту.

5.3. Интервал между потерями

Если интервал между потерями A определен, как начинающийся с пакета S_A, а интервал B — с пакета S_B, число пакетов в интервале между потерями A составляет (S_B — S_A).

5.4. Средний интервал между потерями

Для расчета частоты потерь p сначала вычисли продолжительность среднего интервала между потерями. Это осуществляется с помощью взвешенного фильтра, определяющего средний интервал на основе значений n последних интервалов.

Веса w_0 — w_(n-1) определяются следующим образом:

If (i < n/2)
   w_i = 1;
Else
   w_i = 1 - (i - (n/2 - 1))/(n/2 + 1);

Таким образом, для n=8, значения весов w_0 — w_7 составят:

1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2

Значение числа интервалов n используется при расчете частоты фактов потерь, определяющей скорость реакции TFRC на изменение уровня насыщения. В соответствии с настоящей спецификацией TFRC не следует использовать со значениями n, существенно превышающими 8, для трафика, который может перемешиваться в сети Internet с трафиком TCP. В крайнем случае при использовании значений n > 8 потребуется некоторое изменение механизмов TFRC для обеспечения более резкого отклика на значительную потерю пакетов в течение 2 и более периодов кругового обхода.

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

Таким образом, если последние интервалы между потерями обозначить от I_0 до I_n и I_0 будет относиться к последнему факту потерь, средний интервал рассчитывается следующим образом:

I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
   I_tot0 = I_tot0 + (I_i * w_i);
   W_tot = W_tot + w_i;
}
for (i = 1 to n) {
   I_tot1 = I_tot1 + (I_i * w_(i-1));
}
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;

Вероятность потерь p будет равна:

p = 1/I_mean;

5.5. Дисконтирование истории

Как было показано в параграфе 5.4, последний интервал между потерями дает 1/(0.75*n) часть общего веса при расчете среднего интервала, независимо от продолжительности этого интервала. В этом параграфе описан дополнительный механизм «дисконтирования истории»13, рассмотренный в работах [3] и [9], который позволяет приемному узлу TFRC подбирать весовые параметры, придавая больший вес последнему интервалу между потерями, когда этот интервал более, чем вдвое превышает рассчитанное значение среднего интервала.

Для дисконтирования истории свяжем коэффициент DF_i (число с плавающей запятой) с каждым интервалом L_i (для i > 0). Общая история дисконтирования для каждого интервала между потерями будет храниться в массиве коэффициентов. В начальный момент значения элементов массива DF_i устанавливаются в 1:

for (i = 1 to n) {
   DF_i = 1;
}

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

Как описано в параграфе 5.4, средний интервал между потерями вычисляется с использованием n значений предыдущих интервалов I_1, …, I_n и значения I_0, которое представляет собой число пакетов, полученных с момента последнего факта потерь. Расчет среднего интервала с использованием коэффициентов дисконтирования незначительно отличается от процедуры, описанной в параграфе 5.4:

I_tot0 = I_0 * w_0
I_tot1 = 0;
W_tot0 = w_0
W_tot1 = 0;
for (i = 1 to n-1) {
   I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF);
   W_tot0 = W_tot0 + w_i * DF_i * DF;
}
for (i = 1 to n) {
   I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i);
   W_tot1 = W_tot1 + w_(i-1) * DF_i;
}
p = min(W_tot0/I_tot0, W_tot1/I_tot1);

Общий коэффициент дисконтирования DF обновляется при получении каждого пакета. Сначала получатель рассчитывает средневзвешенное значение I_mean для интервалов потерь I_1, …, I_n:

I_tot = 0;
W_tot = 0;
for (i = 1 to n) {
   W_tot = W_tot + w_(i-1) * DF_i;
   I_tot = I_tot + (I_i * w_(i-1) * DF_i);
}
I_mean = I_tot / W_tot;

Значение I_mean сравнивается с числом пакетов, полученных с момента последнего факта потери — I_0. Если I_0 превышает I_mean более, чем вдвое, это говорит о том, что новый интервал потерь существенно превышает старые значения и значение общего коэффициента DF изменяется для снижения относительного веся более старых интервалов:

if (I_0 > 2 * I_mean) {
   DF = 2 * I_mean/I_0;
   if (DF < THRESHOLD)
      DF = THRESHOLD;
} else
   DF = 1;

Отличное от 0 значение порога THRESHOLD обеспечивает гарантию того, что информация о более ранних интервалах в периоды высокого насыщения не будет полностью обесценена. Рекомендуется устанавливать THRESHOLD = 0.5. Отметим, что прибытие каждого нового пакета ведет к дополнительному росту I_0 и коэффициент DF будет обновляться.

При новом факте потерь текущий интервал переходит из I_0 в I_1, интервал I_i — в I_(i+1), а интервал I_n отбрасывается. Предыдущий коэффициент DF включается в массив коэффициентов дисконтирования. Поскольку DF_i, показывает коэффициент, связанный с интервалом I_i, значения DF_i в массиве также смещаются при новом факте потерь. Процедура сдвига имеет вид:

for (i = 1 to n) {
   DF_i = DF * DF_i;
}
for (i = n-1 to 0 step -1) {
   DF_(i+1) = DF_i;
}
I_0 = 1;
DF_0 = 1;
DF = 1;

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

6. Протокол получателя данных

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

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

6.1. Поведение получателя при приеме пакета данных

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

  1. добавляет пакет в список принятых (историю);
  2. сохраняет прежнее значение p, как p_prev и рассчитывает новое значение, как описано в разделе 5;
  3. если p > p_prev, таймер обратной связи считается истекшим и выполняются действия, описанные в параграфе 6.2;

    при p <= p_prev никаких действий не предпринимается.

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

6.2. Завершение отсчета таймера обратной связи

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

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

  1. расчет среднего интервала между потерями с использованием описанной выше процедуры;
  2. расчет измеренного значения скорости приема X_recv на основе пакетов, принятых в течение предшествующих R_m секунд;
  3. подготовка и передача пакета обратной связи, содержащего информацию, описанную в параграфе 3.2.2;
  4. сброс и повторный запуск таймера обратной связи на R_m секунд.

Если с момента отправки последнего сообщения обратной связи не было принято пакетов данных, сообщение обратной связи не передается, таймер обратной связи сбрасывается и повторно запускается на R_m секунд.

6.3. Инициализация приемника

Приемник инициализируется первым доставленным ему пакетом. Предположим, что этот пакет имеет порядковый номер i.

При получении первого пакета:

  • устанавливается p=0;
  • устанавливается X_recv = 0;
  • подготавливается и передается пакет обратной связи;
  • устанавливается таймер обратной связи на R_i секунд.

6.3.1. Инициализация истории потерь после первого факта потери

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

TFRC делает это путем нахождения некого значения p для которого уравнение пропускной способности из параграфа 3.1 дает скорость передачи, отклоняющуюся от X_recv в пределах 5%, для текущего размера пакетов s и периода кругового обхода R. Для первого интервала между потерями устанавливается значение 1/p (5% погрешность допускается потому, что уравнение пропускной способности сложно обратить и без погрешности пришлось бы рассчитывать p численными методами).

7. Серверные варианты

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

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

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

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

8. Вопросы реализации

В этом документе приведена спецификация механизма контроля насыщения TFRC для прикладных и транспортных протоколов. В данном разделе кратко рассматриваются некоторые вопросы реализации механизма.

Для t_RTO = 4*R и b = 1 уравнение пропускной способности из параграфа 3.1 можно записать в виде:

       s
X = --------
    R * f(p)

где

f(p) = sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2))

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

Многие операции умножения (например, q и 1-q для расчета среднего времени кругового обхода, умножение на 4 для тайм-аута) могут быть реализованы с помощью операций сдвига регистра.

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

Расчет среднего интервала между потерями в параграфе 5.4 включает умножение на весовые коэффициенты w_0 — w_(n-1), которые для n=8 имеют значения:

1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2.

С незначительной потерей точности можно использовать в качестве весовых коэффициентов значения степеней числа два или суммы таких значений, например:

1.0, 1.0, 1.0, 1.0, 0.75, 0.5, 0.25, 0.25.

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

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

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

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

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

Предполагается, что протоколы, использующие ECN14 с TFRC будут также поддерживать обратную связь от получателя с использованием ECN nonce [WES02]. ECN nonce представляет собой модификацию ECN с защитой отправителя от нечаянного или злонамеренного сокрытия маркированных пакетов. Однако детали использования таких механизмов зависят от транспортного протокола и не рассматриваются в этом документе.

10. Согласование с IANA

Этот документ не требует согласования с IANA.

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

Мы благодарим за отклики и конструктивные предложения по развитию механизма контроля насыщения на основе уравнения пропускной способности широкий круг людей, включая членов исследовательской группы Reliable Multicast, рабочей группы Reliable Multicast Transport и исследовательской группы End-to-End. Выражаем благодарность также Ken Lofgren, Mike Luby, Eduardo Urzaiz, Vladica Stanisic, Randall Stewart, Shushan Wen и Wendy Lee (lhh@zsu.edu.cn) за отклики к ранней версии этого документа и благодарим Mark Allman за множество откликов по поводу использования документа для создания работоспособных реализаций механизма.

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

[1] Balakrishnan, H., Rahul, H., and S. Seshan, «An Integrated Congestion Management Architecture for Internet Hosts,»15 Proc. ACM SIGCOMM, Cambridge, MA, September 1999.

[2] Floyd, S., Handley, M., Padhye, J. and J. Widmer, «Equation-Based Congestion Control for Unicast Applications»16, August 2000, Proc. ACM SIGCOMM 2000.

[3] Floyd, S., Handley, M., Padhye, J. and J. Widmer, «Equation-Based Congestion Control for Unicast Applications: the Extended Version»17, ICSI tech report TR-00-03, March 2000.

[4] Padhye, J., Firoiu, V., Towsley, D. and J. Kurose, «Modeling TCP Throughput: A Simple Model and its Empirical Validation»18, Proc. ACM SIGCOMM 1998.

[5] Paxson V. and M. Allman, «Computing TCP’s Retransmission Timer», RFC 2988, November 2000.

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

[7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, «RTP: A Transport Protocol for Real-Time Applications», RFC 1889, January 1996.

[8] Wetherall, D., Ely, D., N. Spring, S. Savage, and T. Anderson, «Robust Congestion Signaling», IEEE International Conference on Network Protocols, November 2001.

[9] Widmer, J., «Equation-Based Congestion Control», Diploma Thesis, University of Mannheim, February 2000. URL «http://www.icir.org/tfrc/«.

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

Mark Handley

ICIR/ICSI

1947 Center St, Suite 600

Berkeley, CA 94708

EMail: mjh@icir.org

Sally Floyd

ICIR/ICSI

1947 Center St, Suite 600

Berkeley, CA 94708

EMail: floyd@icir.org

Jitendra Padhye

Microsoft Research

EMail: padhye@microsoft.com

Joerg Widmer

Lehrstuhl Praktische Informatik IV

Universitat Mannheim

L 15, 16 — Room 415

D-68131 Mannheim

Germany

EMail: widmer@informatik.uni-mannheim.de


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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

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

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

1В настоящее время действие этого документа отменено RFC 5348. Прим. перев.

2TCP-Friendly Rate Control.

3В оригинале используется термин best efforts. Прим. перев.

4Additive-Increase, Multiplicative-Decrease — аддитивный рост, мультипликативное снижение.

5TFRC-PacketSize

6Спецификация TFRC-PS опубликована в RFC 4828. Прим. перев.

7Explicit Congestion Notification.

8Round-trip time.

9Selective acknowledgment — селективное подтверждение.

10В оригинале используется термин nofeedback timer. Прим. перев.

11Time Last Doubled — время последнего удвоения.

12Inter-packet backoff interval.

13History discounting mechanism.

14Explicit Congestion Notification — явное уведомление о насыщении. Прим. перев.

15Документ доступен по ссылке http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-771.pdf. Прим. перев.

16Документ доступен по ссылке http://www.icir.org/tfrc/tcp-friendly.pdf. Прим. перев.

17Документ доступен по ссылке http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36.8816&rep=rep1&type=pdf. Прим. перев.

18Документ доступен по ссылке http://www.sigcomm.org/sigcomm98/tp/paper25.pdf. Прим. перев.