Энциклопедия сетевых протоколов

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

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

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

Аннотация

Этот документ описывает способы обнаружения трансляторов сетевых адресов (NAT¹) между хостами IPsec и согласования применения инкапсуляции в UDP пакетов IPsec, передаваемых через NAT при обмене ключами (IKE²).

1. Введение

Этот документ состоит из двух частей. Первая часть описывает, что требуется сделать в фазе 1 IKE (Phase 1) для работы через трансляторы сетевых адресов (NAT-Traversal), включая обнаружение поддержки NAT-Traversal на другой стороне и обнаружения устройств NAT между партнерами.

Во второй части описано использование инкапсулированных в UDP пакетов IPsec в ускоренном режиме³ IKE. Рассматриваются также способы передачи партнеру исходных адресов отправителя и получателя, если они требуются. Эти адреса используются в транспортном режиме для инкрементального обновления контрольных сумм TCP/IP с целью сохранения их корректности после прохождения через устройства NAT (само устройство NAT не может сделать этого, поскольку контрольные суммы NAT TCP/IP находятся внутри пакета IPsec, инкапсулированного в UDP).

В [RFC3948] описаны детали инкапсуляции в UDP, а в [RFC3715] приведена базовая информация и мотивировка NAT-Traversal в целом. В комбинации с [RFC3948] данный документ представляет безусловно совместимое решение в части требований, определенных в [RFC3715].

В базовом сценарии для этого документа инициатор размещается за устройством NA(P)T, а отвечающая сторона имеет фиксированный адрес IP.

Этот документ определяет протокол, который будет работать даже при размещении обеих сторон за трансляторами NAT, но обработка случаев, когда отвечающая сторона также размещается за транслятором адресов, выходит за рамки этого документа. В одном варианте отвечающая сторона размещается за транслятором NAT со статическим адресом (для одного адреса IP может быть только один ответчик, поскольку нет возможности использовать порт получателя, отличающийся от 500/4500). Такая ситуация известна из конфигурационных параметров.

2. Уровни требований

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

3. Фаза 1

Обнаружение поддержки работы через NAT (NAT-Traversal) и присутствия устройств NAT на пути между двумя партнерами IKE выполняется в фазе 1 IKE [RFC2409] .

Транслятор NAT может сменить порт отправителя IKE UDP и получатели должны быть способны обрабатывать пакеты IKE, в которых номер порта отправителя отличается от 500. Трансляторы NAT меняют порт отправителя с учетом приведенных ниже условий.

порт не меняется, если за устройством NAT размещается только один хост IPsec;
для первого хоста IPsec устройство NAT может сохранить порт 500 и менять его только для соединений других хостов.

Получатели должны отвечать по адресу отправителя из пакета (см. [RFC3715], параграф 2.1, п. d). Это означает, что при смене исходным ответчиком ключей или отправке уведомлений исходному оператору исходный ответчик должен отправлять пакеты с тем же номером порта и адресом IP, которые использовались при последнем обращении к IKE SA.

Например, когда инициатор передает пакет с номерами портов отправителя и получателя 500, транслятор NAT может заменить порт отправителя на 12312, сохранив порт получателя 500. Отвечающий должен быть способен обработать пакет, отправленный из порта 12312 и отвечать на него пакетом из порта 500 в порт 12312. Устройство NAT тогда будет транслировать этого пакет, устанавливая для портов отправителя и получателя значение 500.

3.1. Детектирование поддержки работы через NAT

Возможность работы удаленного хоста через NAT (NAT-Traversal) определяется путем обмена идентификаторами производителей. В двух первых сообщениях фазы 1 (Phase 1) элемент данных с идентификатором производителя (vendor id payload) для данной спецификации должен передаваться, если он поддерживается (и он должен приниматься обеими сторонами) для проб NAT-Traversal. Содержимое этого элемента данных является хэш-суммой MD5 для

      RFC 3947

или (в шестнадцатеричной форме)

      4a131c81070358455c5728f20e95452f

3.2. Обнаружение присутствия NAT

Элемент данных NAT-D⁴ не только позволяет обнаружить присутствие NAT между партнерами IKE, но и определяет место расположения трансляторов NAT. Это имеет важное значение для передачи пакетов keepalive от устройств, расположенных «за» трансляторами NAT.

Для обнаружения устройств NAT между двумя хостами проверяется изменение адресов IP или номеров портов на пути доставки. Это выполняется путем передачи хэш-значений для адресов IP и номеров портов обоих партнеров IKE с каждой из сторон на другую. Если обе стороны рассчитывают эти хэш-значения и получают одинаковые результаты, это говорит об отсутствии преобразований NAT между ними. Если хэш-значения различаются, это говорит о том, что адрес или номер порта был где-то изменен. Это означает, что для передачи пакетов IPsec будет использоваться NAT-Traversal.

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

Хэш-значения передаются в форме серий элементов NAT-D. Каждый элемент содержит одно хэш-значение, поэтому при передаче множества значений используется соответствующее число элементов NAT-D. В обычно ситуации применяется только два элемента NAT-D.

Элементы данных NAT-D включаются в третий и четвертый пакеты основного режима (Main Mode) и во второй и третий — агрессивного режима (Aggressive Mode).

Формат пакетов NAT-D показан на рисунке.

        1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
      +---------------+---------------+---------------+---------------+
      | Next Payload  | RESERVED      | Payload length                |
      +---------------+---------------+---------------+---------------+
      ~                 HASH для адреса и порта                       ~
      +---------------+---------------+---------------+---------------+

Идентификатор типа для элемента данных NAT-D имеет значение 20.

Значение HASH расcчитывается по формуле

         HASH = HASH(CKY-I | CKY-R | IP | Port)

Здесь используется согласованный алгоритм хэширования (HASH). Все данные в HASH представляются в сетевом порядке байтов. IP представляет 4 октета адреса IPv4 или 16 октетов адреса IPv6. Номер порта указывается 2-октетным значением с сетевым порядком байтов. Первый элемент NAT-D содержит IP-адрес и номер порта удаленной стороны (т. е., адрес получателя пакета UDP). Остальные элементы NAT-D содержат возможные адреса IP и номера портов для локальной стороны (т. е., все возможные адреса отправителя в пакетах UDP).

Если на пути нет устройств NAT первый полученный элемент NAT-D будет совпадать с одним из локальных элементов NAT-D (т. е., элементов NAT-D, передаваемых данным хостом), а один из оставшихся элементов NAT-D должен совпадать с адресом и портом удаленной стороны. Если первая проверка дает несовпадение (т. е., первый элемент NAT-D не соответствует ни одному из локальных адресов IP и портов), это говорит о динамическом преобразовании NAT на пути между партнерами, поэтому данной стороне соединения следует начать передачу пакетов keepalive, как описано в [RFC3948] (эта сторона расположена за NAT).

CKY-I и CKY-R указывают значения cookie инициатора и ответчика, которые добавляются при расчете хэш-функции для предотвращения атак с предварительным расчетом (precomputation attack), делающих адреса IP и порты недоступными.

Ниже приведен пример обмена Phase 1 с использованием NAT-Traversal в основном режиме (Main Mode — аутентификация с подписями).

   Инициатор                           Ответчик
   ------------                        ------------
   HDR, SA, VID                -->
                                       <-- HDR, SA, VID
   HDR, KE, Ni, NAT-D, NAT-D   -->
                                       <-- HDR, KE, Nr, NAT-D, NAT-D
   HDR*#, IDii, [CERT, ] SIG_I -->

Ниже приведен пример обмена Phase 1 с использованием NAT-Traversal в агрессивном режиме (Aggressive Mode — аутентификация с подписями).

   Инициатор                           Ответчик
   ------------                        ------------
   HDR, SA, KE, Ni, IDii, VID  -->
                                       <-- HDR, SA, KE, Nr, Idir, [CERT, ], VID, NAT-D,
                                               NAT-D, SIG_R
   HDR*#, [CERT, ], NAT-D, NAT-D,
                        SIG_I  -->

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

4. Смена портов

Осведомленные об IPsec трансляторы NAT могут вызывать проблемы (см. параграф 2.3 в [RFC3715]). Некоторые устройства NAT не будут менять порт отправителя IKE 500 даже при наличии за транслятором NAT множества клиентов ([RFC3715], параграф 2.3, п. n). Они также могут применять для демультиплексирования трафика IKE cookie вместо номера порта отправителя ([RFC3715], параграф 2.3, п. m). Обе эти ситуации являются проблематичными для базовой прозрачности NAT, поскольку протоколу IKE трудно определить возможности транслятора NAT. Лучшим решением будет просто максимально быстрый перенос трафика IKE из порта 500 для предотвращения описанных выше ситуаций в осведомленных об IPsec трансляторах NAT.

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

В основном режиме (Main Mode) инициатор должен сменить порты при передаче элемента данных ID, если между хостами имеется устройство NAT. Инициатор должен установить для портов отправителя и получателя значения UDP 4500. Все последующие пакеты для этого партнера (включая информационные уведомления) должны передаваться в порт 4500. В дополнение к этому перед данными IKE должен помещаться маркер non-ESP, позволяющий демультиплексировать трафик, как описано в [RFC3948].

Таким образом, пакет IKE будет иметь вид

         IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I

Это предполагает аутентификацию с использованием подписей. 4-байтовый маркер non-ESP определен в [RFC3948].

При получении этого пакета ответчиком он выполняет обычную расшифровку и обработку различных элементов данных. После успешного завершения ответчик должен обновить свое локальное состояние так, что все последующие пакеты (включая информационные уведомления) для партнера использовали новый номер порта и, возможно, новый адрес IP, полученные из корректного входящего пакета. Номера портов в общем случае будут различаться, поскольку NAT будет отображать UDP(500,500) в UDP(X,500), а UDP(4500,4500) в UDP(Y,4500). Адрес IP будет иногда отличаться от заранее измененного IP-адреса. Ответчик должен направлять все последующие пакеты IKE данному партнеру, используя UDP(4500,Y).

Аналогично, если ответчик меняет ключи Phase 1 SA, согласование замены должно начинаться с использованием UDP(4500,Y). Все реализации, обеспечивающие работу через NAT, должны поддерживать согласование, начинающееся через порт 4500. если согласование начинается через порт 4500, номер порта не потребуется менять в течение обмена.

После смены порта получение пакета на порту 500 будет говорить о том, сто это старый пакет. Если пакет является информационным, его можно обработать в соответствии с локальной политикой (если она разрешает это). Если пакет относится к Main Mode или Aggressive Mode (с теми же значениями cookie, что и в предыдущем пакете), его следует отбросить. Если пакет относится к новому обмену основного или агрессивного режима, он обрабатывается обычным путем (другая сторона могла быть перезагружена и начала обмен по этой причине).

Ниже приведен пример обмена Phase 1 с использованием NAT-Traversal в основном режиме (аутентификация с подписями) с заменой порта.

   Инициатор                           Ответчик
   ------------                        ------------
   UDP(500,500) HDR, SA, VID -->
                                       <-- UDP(500,X) HDR, SA, VID
   UDP(500,500) HDR, KE, Ni,
                NAT-D, NAT-D -->
                                       <-- UDP(500,X) HDR, KE, Nr, NAT-D, NAT-D
   UDP(4500,4500) HDR*#, IDii,
               [CERT, ]SIG_I -->
                                       <-- UDP(4500,Y) HDR*#, Idir, [ CERT, ], SIG_R

Процедура для Aggressive Mode очень похожа. После обнаружения NAT инициатор передает пакет IP UDP(4500,4500) вида <4-байтовый маркер non-ESP> HDR*, [CERT, ], NAT-D, NAT-D, SIG_I. Ответчик выполняет обработку, подобную описанной выше, и при ее успешном завершении должен обновить свои внутренние порты IKE. Ответчик должен отправлять все последующие пакеты IKE этому партнеру, используя UDP(4500,Y).

   Инициатор                           Ответчик
   ------------                        ------------
   UDP(500,500) HDR, SA, KE,
                 Ni, IDii, VID -->
                                       <-- UDP(500,X) HDR, SA, KE, Nr, IDir, [CERT, ],
                                               VID, NAT-D, NAT-D, SIG_R
   UDP(4500,4500) HDR*#, [CERT, ],
           NAT-D, NAT-D, SIG_I -->
                                       <-- UDP(4500, Y) HDR*#, ...

При включенной поддержке работы через NAT поле номера порта в элементе данных ID для режимов Main Mode/Aggressive Mode должно иметь значение 0.

Наиболее распространенным вариантом размещения ответчика за NAT является простое преобразование адресов 1:1 в трансляторе NAT. В этом случае инициатор так же меняет номера обоих портов на 4500. Ответчик применяет алгоритм, аналогичный вышеописанному, хотя в этом случае Y = 4500 и трансляции портов не происходит.

Другой случай смены портов включает определение используемых портов внешними средствами (out-of-band), рассмотрение которых выходит за рамки этого документа. Например, если ответчик находится за устройством NAT, транслирующим номера портов, а инициатору нужно связаться с таким ответчиком, обычно инициатор определяет используемые порты через некий другой сервер. После того, как инициатор узнает номера портов, используемые для работы через NAT (обычно что-то типа UDP(Z,4500)), он инициирует соединения, используя эти порты. Это похоже на описанный выше случай смены ключей ответчиком, когда номера используемых портов известны заранее и никаких дополнительных изменений не требуется. Отсчет таймера keepalive начинается после перехода на новый номер порта и сообщения keepalive не передаются в порт 500.

5. Ускоренный режим

После фазы 1 обе стороны знают о наличии между ними транслятора NAT. Окончательное решение об использовании NAT-Traversal относится к ускоренному режиму (Quick Mode). Применение NAT-Traversal согласуется в элементах данных SA ускоренного режиме. В Quick Mode обе стороны могут также передавать исходные адреса своих пакетов IPsec (в транспортном режиме) на другую сторону и каждая из сторон может скорректировать поле контрольной суммы TCP/IP после преобразования NAT.

5.1. Согласование инкапсуляции для NAT-Traversal

Согласование работы через NAT (NAT-Traversal) добавляет два новых режима инкапсуляции, приведенных ниже.

   UDP-Encapsulated-Tunnel         3
   UDP-Encapsulated-Transport      4

Обычно не имеет смысла предлагать сразу обычный туннельный или транспортный режим и режимы UDP-Encapsulated. Инкапсуляция в UDP требуется для обеспечения передачи трафика, не относящегося к протоколам UDP/TCP, через трансляторы NAT (см. [RFC3715], параграф 2.2, п. i).

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

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

Инициаторам не следует включать в свои предложения одновременно обычный туннельный или транспортный режим и режим UDP-Encapsulated-Tunnel или UDP-Encapsulated-Transport.

5.2. Передача исходных адресов отправителя и получателя

Для обновления контрольных сумм TCP оба партнера должны знать использованные партнером при создании пакета адреса IP (см. [RFC3715], параграф 2.1, п. b). Для инициатора исходным адресом будет его адрес IP, а исходным адресом ответчика будет воспринятый IP-адрес партнера. Для ответчика исходным адресом инициатора будет воспринятый адрес партнера, а исходным адресом ответчика — его собственный адрес IP.

Исходные адреса передаются с использованием элемента данных NAT-OA (NAT Original Address).

Первым является элемент Initiator NAT-OA, вторым — Responder NAT-OA.

Пример 1

         Инициатор <---------> NAT <---------> Ответчик
                  ^               ^           ^
                Iaddr           NatPub      Raddr

Инициатор, находящийся за NAT обменивается данными с публично доступным ответчиком. Адреса IP ответчика и инициатора обозначим Iaddr и Raddr, публичный адрес транслятора NAT — NatPub.

   Инициатор
                     NAT-OAi = Iaddr
                     NAT-OAr = Raddr
   Ответчик
                     NAT-OAi = NATPub
                     NAT-OAr = Raddr

Пример 2

         Инициатор <------> NAT1 <---------> NAT2 <-------> Ответчик
                  ^             ^           ^              ^
                Iaddr        Nat1Pub     Nat2Pub         Raddr

Здесь NAT2 «публикует» адрес Nat2Pub для ответчика и пересылает весь направленный по этому адресу трафик ответчику.

   Инициатор
                     NAT-OAi = Iaddr
                     NAT-OAr = Nat2Pub
   Ответчик
                     NAT-OAi = Nat1Pub
                     NAT-OAr = Raddr

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

Элементы данных NAT-OA передаются в первом и втором пакетах ускоренного режим (Quick Mode). Инициатор должен передавать эти элементы, если он предлагает любой из режимов UDP-Encapsulated⁵, а ответчик должен передавать такой элемент только при выборе режима UDP-Encapsulated-Transport. Возможна передача инициатором элемента NAT-OA при одновременной поддержке транспортного и туннельного режима UDP-Encapsulated. В такой ситуации ответчик, выбравший туннельный режим UDP-Encapsulated, не возвращает элемента данных NAT-OA.

Формат пакета NAT-OA показан на рисунке.

         1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
       +---------------+---------------+---------------+---------------+
       | Next Payload  | RESERVED      | Payload length                |
       +---------------+---------------+---------------+---------------+
       | ID Type       | RESERVED      | RESERVED                      |
       +---------------+---------------+---------------+---------------+
       |         Адрес  IPv4 (4 октета) или IPv6 (16 октетов)          |
       +---------------+---------------+---------------+---------------+

Идентификатор типа для элементов данных NAT-OA имеет значение 21.

Поле ID Type определено в [RFC2407]. Разрешены только типы ID_IPV4_ADDR и ID_IPV6_ADDR. Два резервных поля после ID Type должны иметь нулевые значения.

Ниже приведен пример Quick Mode с использованием элементов данных NAT-OA.

   Инициатор                           Ответчик
   ------------                        ------------
   HDR*, HASH(1), SA, Ni, [, KE]
       [, IDci, IDcr ]
       [, NAT-OAi, NAT-OAr] -->
                                       <-- HDR*, HASH(2), SA, Nr, [, KE]
                                                 [, IDci, IDcr ] [, NAT-OAi, NAT-OAr]
   HDR*, HASH(3)            -->

6. Уведомления INITIAL-CONTACT

Адрес отправителя и номер порта⁶ в уведомлении INITIAL-CONTACT для расположенного за транслятором NAT хоста не имеют смысла (NAT заменит их), поэтому адреса IP и номера портов недопустимо использовать для идентификации удаляемой IKE/IPsec SA (см. [RFC3715], параграф 2.1, п. c). Взамен следует использовать элемент данных ID, переданный другой стороной. Т. е. при получении INITIAL-CONTACT от другой стороны, принимающему следует удалить все связи SA, ассоциированные с этим элементом ID.

7. Восстановление после утраты отображения NAT

В некоторых случаях транслятор NAT может удалять отображения, которые еще используются (например, при слишком редких сообщениях keepalive или в результате перезагрузки устройства NAT). В таких случаях стороне, не расположенной за транслятором NAT следует использовать последний корректный пакет IKE или IPsec, инкапсулированный в UDP, от другой стороны для определения адреса IP и номера порта, которые следует использовать. Хосту, расположенному за динамическим NAT, недопустимо делать это (такое поведение открывает возможность для DoS-атаки), поскольку адрес и номер порта другой стороны не изменились (она не находится за NAT).

Любой аутентифицированный IKE пакет ESP или IKE может служить для обнаружения смена адреса и номера порта, но сообщения keepalive не подходят для этого, поскольку они не аутентифицируются.

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

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

Пробы IKE раскрывают поддержку NAT-Traversal для любого, кто может отслеживать трафик, однако раскрытие поддержки работы через трансляторы NAT не создает новых уязвимостей.
Значение механизмов аутентификации на основе адресов IP сразу же исчезает при появлении трансляторов NAT. Это совсем не обязательно считать недостатком (для любой реальной защиты следует использовать отличные от адресов IP способы аутентификации). Это означает, что аутентификация с заранее распространенными ключами (pre-shared key) не может применяться в основном режиме (Main Mode) без использования групповых (group-shared) ключей для находящихся за NAT хостов. Использование групповых ключей связано с огромным риском, поскольку оно позволяет любому члену группы аутентифицировать себя у любой другой стороны, заявив себя в качестве «кого-то из группы». Т. е., обычный пользователь может выдать себя за шлюз VPN и действовать, как «человек посередине» (man in the middle), читая/изменяя весь трафик, идущий другим членам группы или от них. Использование групповых ключей не рекомендуется.
Поскольку внутреннее адресное пространство имеет размер лишь 32 бита и обычно занято достаточно неплотно, для злоумышленника может оказаться возможным определение внутреннего адреса, используемого за транслятором NAT, путем проверки всех возможных адресов IP на предмет соответствия хэш-значению. Номера портов обычно фиксированы (500), а значения cookie можно извлечь из пакетов. Это ограничивает число рассчитываемых хэш-значений до 232. Если требуется угадать адрес из приватных блоков IP, число рассчитываемых значений снижается до 2²⁴ + 2 * (2¹⁶)⁷.
Элементы данных NAT-D и Vendor ID не аутентифицируются ни в основном (Main Mode), ни в агрессивном (Aggressive Mode) режиме. Это означает, что атакующий может удалить, изменить или вставить такой элемент. Удаляя или добавляя элементы, атакующий может организовывать атаку на отказ служб (DoS⁸). Изменяя пакеты NAT-D, атакующий может вынудить обе стороны использовать режимы UDP-Encapsulated вместо прямой организации туннеля или транспортного соединения, что приведет к неоправданному расходу полосы.
Передача исходного адреса отправителя в ускоренном режиме раскрывает другой стороне внутренний адрес IP за транслятором NAT. Однако в этом случае другая сторона уже аутентифицирована (подтвердила свою подлинность) и передача исходного адреса отправителя нужна только в транспортном режиме.
Обновление адресов и портов при инкапсуляции IKE SA/ESP в UDP для каждого приемлемого аутентифицированного пакета может вызывать отказ служб (DoS), если атакующий имеет возможность прослушивать весь трафик в сети, менять порядок пакетов и вставлять новые пакеты перед пакетом, который он уже видел. Иными словами, атакующий может взять аутентифицированный пакет от хоста, находящегося за NAT, поменять порты UDP отправителя/получателя или адрес IP и передать с нарушением порядка этот пакет перед реальным пакетом. Хост, не находящийся за NAT, обновит у себя отображение IP-адреса и порта, а потом будет передавать последующий трафик по обманным адресу и порту. Эта проблема решается сразу же, как только атакующий прекращает изменение пакетов — первый же пакет от реального хоста восстановит нормальную ситуацию. В реализациях следует поддерживать аудит событий при каждом изменении отображений и не разрешать такие изменения слишком часто.

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

Этот документ включает два новых «магических значения», выделенные в имеющемся реестре IANA для IPsec и изменены названия для зарегистрированного ранее порта 4500. Документ также определяет два новых элемента данных для IKE.

В реестр Internet Security Association and Key Management Protocol (ISAKMP) Identifiers добавлены указанные в таблице идентификаторы режимов инкапсуляции.

Имя	Значение	Документ
UDP-Encapsulated-Tunnel	3	[RFC3947]
UDP-Encapsulated-Transport	4	[RFC3947]

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

Имя	Номер/имя	Описание	Документ
ipsec-nat-t	4500/tcp	IPsec NAT-Traversal	[RFC3947]
ipsec-nat-t	4500/udp	IPsec NAT-Traversal	[RFC3947]

В реестр Next Payload Types добавлены новые типы элементов данных IKE:

         NAT-D         20         NAT Discovery Payload
         NAT-OA        21         NAT Original Address Payload

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

Вопросы UNSAF [RFC3424] решаются требованиями совместимости IPsec-NAT, описанными в [RFC3715].

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

Спасибо Markus Stenberg, Larry DiBurro и William Dixon за активное участие в подготовке этого документа.

Спасибо Tatu Ylonen, Santeri Paavolainen и Joern Sierwald, которые подготовили документы, послужившие основой для данного документа.

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

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

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409⁹, November 1998.

[RFC2407] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407¹, November 1998.

[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, «UDP Encapsulation of IPsec Packets», RFC 3948, January 2005.

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

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

[RFC3715] Aboba, B. and W. Dixon, «IPsec-Network Address Translation (NAT) Compatibility Requirements», RFC 3715, March 2004.

[RFC3424] Daigle, L. and IAB, «IAB Considerations for Unilateral Self-Address Fixing (UNSAF) Across Network Address Translation», RFC 3424, November 2002.

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

Tero Kivinen

SafeNet, Inc.

Fredrikinkatu 47

FIN-00100 HELSINKI

Finland

EMail: kivinen@safenet-inc.com

Ari Huttunen

F-Secure Corporation

Tammasaarenkatu 7,

FIN-00181 HELSINKI

Finland

EMail: Ari.Huttunen@F-Secure.com

Brian Swander

Microsoft

One Microsoft Way

Redmond, WA 98052

USA

EMail: briansw@microsoft.com

Victor Volpe

Cisco Systems

124 Grove Street

Suite 205

Franklin, MA 02038

USA

EMail: vvolpe@cisco.com

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

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

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

Copyright (C) The Internet Society (2005).

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

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

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

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

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

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

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

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

1Network address translation.

2Internet Key Exchange.

3Quick Mode.

4NAT discovery — обнаружение NAT.

5В оригинале ошибочно сказано UDP-Encapsulated-Transport. См. https://www.rfc-editor.org/errata_search.php?eid=4936. Прим. перев.

6В оригинале ошибочно сказано port address. См. https://www.rfc-editor.org/errata_search.php?eid=4937. Прим. перев.

7Суммарный размер выделенных для приватных сетей блоков адресов IP (RFC 1918). Прим. перев.

8Denial of Service.

9Этот документ признан устаревшим и заменен RFC 4306, который затем заменен RFC 5996, а после — RFC 7296. Прим. перев.

Рубрика: RFC | Комментарии отключены

Опыт организации граничных шлюзов на основе Linux

Опубликовано 12.01.2005 автором Nikolai Malykh

Опыт организации граничных шлюзов на основе Linux

(тезисы доклада на конференции “open source forum ’05”)

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

ЗАО BiLiM Systems

Санкт-Петербург

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

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

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

Операционные системы семейства UNIX содержат все, что необходимо для организации такого шлюза, в своем составе или в числе прикладных программ. Мы выбрали для организации шлюза ОС RedHat, хотя в процессе его создания и последующего развития от исходного набора файлов RedHat мало что осталось, поскольку большая часть используемых пакетов была собрана из исходных кодов с внесением во многих случаях тех или иных изменений. В качестве аппаратной платформы используется ПК общего назначения с процессором Celeron 300 МГц, оперативной памятью размеров 512 Мбайт и дисковым накопителем размером 20 Гбайт. Очевидно, что рыночная стоимость такого ПК на сегодняшний день не превышает нескольких десятков долларов.

Шлюз используется для маршрутизации пакетов между четырьмя сегментами FastEthernet – 2 внешних канала, локальная сеть компании и сегмент публичных серверов (DMZ). Наша компания имеет зарегистрированную автономную систему, поэтому на шлюзе поддерживается протокол BGP4 для анонсирования наших префиксов и получения маршрутной информации от 2 провайдеров.

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

Для обеспечения маршрутизации используется пакет Zebra с незначительными доработками, который собран с поддержкой лишь реально используемых протоколов OSPF и BGP4. Фильтрация пакетов и учет трафика осуществляются на основе Netfilter/iptables с незначительными доработками по сравнению со стандартным набором, распространяемым в составе ядра, iptables и POM. Для мониторинга целостности файловой системы шлюза используется пакет samhain, а для проверки на наличие в системе враждебного кода набор утилит, включающий chkrootkit, rkhunter и др. Контроль записей в журнальных файлах осуществляется с помощью простой утилиты logcheck. Для обеспечения дополнительной надежности некоторые записи дублируются на сервере syslog, находящемся внутри сети компании. В качестве системы детектирования попыток вторжения или иных нежелательных действий (например сканирования портов) для шлюза и внутренних сетей используется стандартный пакет Snort. В нашем случае шлюз служит лишь в качестве набора датчиков Snort, собирающих информацию и передающих ее в базу данных на один из внутренних серверов. Кроме того, попытки входа в систему или проникновения в сеть регистрируются также с помощью утилиты hostsentry и набора правил iptables. Дополнительным детектором попыток сканирования служит утилита portsentry и набор правил iptables.

Перечислим набор функций, реализованных на шлюзе:

маршрутизация пакетов IP с поддержкой протоколов BGP4 и OSPF;
трансляция адресов для входящего и исходящего трафика;
межсетевое экранирование с учетом состояния соединений (stateful);
фильтрация пакетов, входящих в сеть и выходящих наружу:

ingress-фильтрация в соответствии с RFC 2267;
фильтрация спама на основе списков доступа;
фильтрация спама по частоте попыток подключения;
фильтрация попыток несанкционированного доступа к шлюзу по протоколу SSH;
фильтрация нежелательного трафика по протоколам, номерам портов и адресам IP;
управление полосой для исходящего трафика;
детектирование попыток сканирования или проникновения в сеть;
блокирование DoS-атак на шлюз и хосты внутренних сетей;

мониторинг работы сервера, включая уровень загрузки внешних каналов и процессора, целостность файловой системы;
удаленное управление с использованием SSH-соединений и Web-интерфейса;
детектирование попыток вторжения и сканирования для шлюза и внутренней сети;
детектирование и блокирование недопустимого исходящего трафика для предотвращения возможности организации атак из сети компании;
система мониторинга и оповещения администратора о сигналах тревоги по электронной почте или с помощью SMS;
учет трафика пользователей из внутренней сети;
система LookingGlass для проверки связности сети из удаленных точек.

Данный шлюз в описанной конфигурации используется с начала 2002 года и доказал свою надежность и эффективность.

Рубрика: Linux | Комментарии отключены

Генератор пакетов, встроенный в ядро Linux

Опубликовано 30.12.2004 автором Nikolai Malykh

PDF

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

Для использования генератора пакетов потребуется ядро со включенной при компиляции опцией Packet Generator (NET_PKTGEN). Если функции генератора пакетов реализованы в виде модуля (NET_PKTGEN=m) для работы с генератором нужно загрузить модуль с помощью команды

modprobe pktgen

После загрузки модуля (или сразу после загрузки ОС, если генератор встроен в ядро) в дереве /proc появится каталог /proc/net/pktgen, содержащий файлы pg с номерами от 0 до n-1 (n — число ядер) и n файлов pb_busy с идентичными номерами. Каждая пара файлов соответствует одному процессу генерации пакетов (будем называть такие процессы “виртуальными генераторами”). Процессы могут активизироваться параллельно, что позволяет создать множество управляемых потоков трафика. Файлы pg* содержат сведения о номере версии генератора, параметрах генерации пакетов и результатах предыдущего цикла , как показано ниже

pktgen version 1.33
Params: count 100000  pkt_size: 60  frags: 0  ipg: 0  clone_skb: 0 odev ""
     dst_min:   dst_max:   src_min:   src_max:
     src_mac: 00:00:00:00:00:00  dst_mac: 00:00:00:00:00:00
     udp_src_min: 9  udp_src_max: 9  udp_dst_min: 9  udp_dst_max: 9
     src_mac_count: 0  dst_mac_count: 0
     Flags:
Current:
     pkts-sofar: 0  errors: 0
     started: 0ms  stopped: 0ms  now: 1105536041221ms  idle: 0ns
     seq_num: 0  cur_dst_mac_offset: 0  cur_src_mac_offset: 0
     cur_saddr: 0x0  cur_daddr: 0x0  cur_udp_dst: 0  cur_udp_src: 0
Result: Idle

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

Файлы pb_busy содержат просто флаги использования для каждого из виртуальных генераторов 0 – 7. Значение 1 в файле говорит о том, что соответствующий генератор в данный момент используется. Наличие файлов с флагами позволяет создавать shell-сценарии для длительной генерации пакетов с изменяющимися параметрами.

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

Параметр	Описание
clone_skb <целое число>	Определяет число буферов skb (“копия” пакета, создаваемая в ядре), создаваемых для генерации пакетов. При нулевом значении параметра (используется по умолчанию) буферы выделяются для каждого генерируемого пакета, что позволяет использовать в пакетах временные метки. Значение, отличное от нуля задает передачу соответствующего числа пакетов с использованием одного буфера skb.
count <целое число>	Этот необязательный параметр задает количество передаваемых пакетов. Нулевое значение счетчика обеспечивает генерацию неограниченного числа пакетов (процесс генерации продолжается до тех пор, пока не будет получена команда stop). По умолчанию программа генерирует 100000 пакетов.
dst X.X.X.X	Этот параметр является обязательным и задает IP-адрес получателя пакетов.
dst_min X.X.X.X	Задает нижнюю границу диапазона адресов получателей. По умолчанию используется значение параметра dst.
dst_max X.X.X.X	Задает верхнюю границу диапазона адресов получателей.
dstmac <MAC-адрес>	Устанавливает MAC-адрес получателя. По умолчанию используется значение 00:00:00:00:00:00. При использовании генератора в коммутируемой сети следует явно задавать MAC-адрес получателя или указывать в этом поле широковещательный адрес, поскольку в противном случае пакеты не уйдут дальше коммутатора. Если же адресат пакетов находится в другой локальной сети (за маршрутизатором), в этом поле следует указывать MAC-адрес интерфейса маршрутизатора, через который будут доставляться пакеты.
dst_mac_count <целое число>	Задает количество MAC-адресов получателей в используемом при генерации пакетов диапазоне с начальным значением dstmac.
flag [имя]	Задает флаг управления генерацией. Возможны значения флагов: IPSRC_RND — использовать случайный адрес IP для отправителя; IPDST_RND — использовать случайный адрес IP для получателя; UDPSRC_RND — использовать случайный номер порта UDP для отправителя; UDPDST_RND — использовать случайный номер порта UDP для получателя; MACSRC_RND — использовать случайный MAC-адрес для отправителя; MACDST_RND — использовать случайный MAC-адрес для получателя. Адреса и номера портов выбираются из диапазона, заданного минимальным и максимальным значением. При установке соответствующего флага выбор значений осуществляется случайным способом, при отсутствии флага значения перебираются по порядку.
ipg <целое число>	Задает интервал между пакетами в наносекундах. При нулевом значении параметра (используется по умолчанию) интервал между последовательными пакетами определяется загрузкой процессора и его тактовой частотой. Максимальное значение параметра ipg может составлять 4294967295 (2³²), что обеспечивает генерацию пакетов с интервалом 4,295 сек. При попытке указать значение за пределами этого диапазона будут считаны первые 10 знаков числа (слева направо) и произведено преобразование к типу unsigned long (32 бита) с возможной потерей старших битов.
odev <имя устройства>	Задает имя интерфейса, используемого для генерации пакетов. Параметр является обязательным даже при наличии в системе единственного интерфейса.
pkt_size <целое число>	Задает размер генерируемых кадров Ethernet в байтах без учета поля FCS. По умолчанию используется значение pkt_size=ETH_ZLEN=60.
src_min X.X.X.X	Задает IP-адрес отправителя или нижнюю границу диапазона адресов.
src_max X.X.X.X	Задает верхнюю границу диапазона IP-адресов отправителей.
srcmac <MAC-адрес>	Устанавливает MAC-адрес отправителя. По умолчанию устанавливается MAC-адрес интерфейса, используемого для передачи пакетов.
src_mac_count <целое число>	Задает количество MAC-адресов отправителя в используемом диапазоне с начальным значением srcmac.
stop	Останавливает генерацию пакетов. Этот параметр передается без кавычек.
udp_src_min <целое число>	Задает минимальный номер порта UDP для отправителя. По умолчанию используется порт 9 (discard).
udp_src_max <целое число>	Задает максимальный номер порта UDP для отправителя. По умолчанию используется порт 9 (discard).
udp_dst_min <целое число>	Задает минимальный номер порта UDP для получателя. По умолчанию используется порт 9 (discard).
udp_dst_max <целое число>	Задает максимальный номер порта UDP для получателя. По умолчанию используется порт 9 (discard).

Для генерации пакетов нужно создать shell-сценарий, который содержит приведенные ниже строки:

#! /bin/sh
# загрузка модуля генерации пакетов
modprobe pktgen

# укажите “виртуальный генератор” pgN (N = 0 .. 7) в переменной PGDEV
PGDEV=/proc/net/pktgen/pg7		# будем использовать виртуальный генератор 7

function pgset() {
    local result
    echo $1 > $PGDEV
    result=`cat $PGDEV | fgrep "Result: OK:"`
    if [ "$result" = "" ]; then
         cat $PGDEV | fgrep Result:
    fi
}

function pg() {
    echo inject > $PGDEV
    cat $PGDEV
}

#поместите ниже команды управления генерацией

и команды установки параметров генерации, каждая из которых имеет вид:

pgset “параметр значение”

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

pgset "odev eth0" 			# будем передавать пакеты в сеть через интерфейс eth0
pgset "count 1000000" 		        # задаем число генерируемых пакетов
pgset "dst 172.16.33.2" 		# указываем IP-адрес получателя пакетов
pgset "dstmac 00:05:5d:00:33:44"	# указываем MAC-адрес интерфейса маршрутизатора
pg					# начать генерацию пакетов

После создания файла сценария сохраните его и установите для него возможность записи (сделать это можно, например, с помощью команды chmod 755 <имя файла>). Для простоты будем называть такие файлы по именам виртуальных генераторов (например, pg7.sh). Далее в командной строке набираем

./pg7.sh

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

После генерации пакетов на экран будет выведена статистика работы генератора. Эти же параметры и результаты будут сохранены в файле /proc/net/pktgen/pg0 и могут использоваться в качестве принятых по умолчанию параметров при следующем запуске генератора для того же pg. Пример вывода для рассмотренного сценария генерации приведен ниже

pktgen version 1.33
Params: count 1000000  pkt_size: 60  frags: 0  ipg: 0  clone_skb: 0 odev "eth0"
     dst_min: 172.16.33.2  dst_max:   src_min: 192.168.77.33  src_max:
     src_mac: 00:A0:CC:60:6F:B7  dst_mac: 00:05:5D:00:33:44
     udp_src_min: 9  udp_src_max: 9  udp_dst_min: 9  udp_dst_max: 9
     src_mac_count: 0  dst_mac_count: 0
     Flags:
Current:
     pkts-sofar: 1000000  errors: 0
     started: 1105547763535ms  stopped: 1105547777329ms  now: 1105547777329ms  idle: 1952323633ns
     seq_num: 1030000  cur_dst_mac_offset: 0  cur_src_mac_offset: 0
     cur_saddr: 0x21c830d4  cur_daddr: 0x22110ac  cur_udp_dst: 9  cur_udp_src: 9
Result: OK: 13790262(c10040403+d3749859) usec, 1000000 (64byte,0frags)
  72514pps 37Mb/sec (37127168bps) errors: 0

На хосте 172.16.33.2 для мониторинга была использована команда

tcpdump -n -vvv host 172.16.33.2

фрагмент вывода которой приведен ниже

19:36:00.609255 192.168.77.33.9 > 172.16.33.2.9: [no cksum] udp 18 (ttl 2, id 23130, len 46)
19:36:00.609280 192.168.77.33.9 > 172.16.33.2.9: [no cksum] udp 18 (ttl 2, id 23130, len 46)
19:36:00.609304 192.168.77.33.9 > 172.16.33.2.9: [no cksum] udp 18 (ttl 2, id 23130, len 46)
19:36:00.609327 192.168.77.33.9 > 172.16.33.2.9: [no cksum] udp 18 (ttl 2, id 23130, len 46)
19:36:00.609349 192.168.77.33.9 > 172.16.33.2.9: [no cksum] udp 18 (ttl 2, id 23130, len 46)
19:36:00.609372 192.168.77.33.9 > 172.16.33.2.9: [no cksum] udp 18 (ttl 2, id 23130, len 46)
19:36:00.609394 192.168.77.33.9 > 172.16.33.2.9: [no cksum] udp 18 (ttl 2, id 23130, len 46)
19:36:00.609418 192.168.77.33.9 > 172.16.33.2.9: [no cksum] udp 18 (ttl 2, id 23130, len 46)

Мы не задавали интервал между пакетами и используемое по умолчанию значение 0 обеспечило их генерацию с интервалом около 25 мксек, как можно видеть из приведенных результатов. Размер пакетов также не был указан, поэтому генерировались пакеты минимального размера 60 байт. При генерации в заголовках IP устанавливается значение TTL=3, что полностью соответствует результатам мониторинга. В принятых пакетах TTL=2, поскольку между генератором и получателем находится коммутатор сетевого уровня (маршрутизатор). В качестве номера порта использовались принятые по умолчанию значения 9 (порт службы discard).

Усложним сценарий генерации пакетов, добавив диапазоны значений для адреса отправителя и номеров портов отправителя и получателя, а также зададим случайный характер выбора значений. Укажем также размер кадров (1400 байт) и интервал между генерируемыми пакетами (50 нсек). Фрагмент сценария с установкой параметров пакетов показан ниже

pgset "odev eth0"
pgset "pkt_size 1400" # размер кадра
pgset "count 1000000"
pgset "ipg 50" # интервал между пакетами
pgset "dst 172.16.33.2"
pgset "dstmac 00:05:5d:00:33:44"
pgset "src_min 192.168.77.1"
pgset "src_max 192.168.77.254"
pgset "udp_src_min 1"
pgset "udp_src_max 1024"
pgset "udp_dst_min 1"
pgset "udp_dst_max 1024"
pgset "flag IPSRC_RND"
pgset "flag UDPSRC_RND"
pgset "flag UDPDST_RND"
pg

Фрагмент вывода tcpdump на хосте 172.16.33.2 показывает

20:06:57.617840 192.168.77.225.743 > 172.16.33.2.945: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.617889 192.168.77.191.662 > 172.16.33.2.720: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618033 192.168.77.103.726 > 172.16.33.2.378: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618097 192.168.77.140.79 > 172.16.33.2.948: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618145 192.168.77.2.828 > 172.16.33.2.239: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618197 192.168.77.79.1003 > 172.16.33.2.195: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618240 192.168.77.49.27 > 172.16.33.2.837: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618576 192.168.77.85.969 > 172.16.33.2.940: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618619 192.168.77.169.430 > 172.16.33.2.865: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618662 192.168.77.79.97 > 172.16.33.2.130: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618705 192.168.77.66.181 > 172.16.33.2.355: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618930 192.168.77.45.710 > 172.16.33.2.214: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.618976 192.168.77.213.594 > 172.16.33.2.155: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.619305 192.168.77.250.692 > 172.16.33.2.665: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.619355 192.168.77.93.853 > 172.16.33.2.99: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.619398 192.168.77.242.609 > 172.16.33.2.520: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.619448 192.168.77.8.14 > 172.16.33.2.577: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.619490 192.168.77.144.306 > 172.16.33.2.335: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.619667 192.168.77.175.141 > 172.16.33.2.30: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.620138 192.168.77.47.558 > 172.16.33.2.87: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.620183 192.168.77.143.293 > 172.16.33.2.236: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)
20:06:57.620225 192.168.77.72.670 > 172.16.33.2.813: [no cksum] udp 1358 (ttl 2, id 23130, len 1386)

Из приведенных значений видно, что действительно генерировались кадры размером 1400 байт, содержащие пакеты IP и поле FCS общим размером 1386 байт (14 байт занимает заголовок канального уровня), в которых содержались дейтаграммы UDP размером 1358 байт (24 байта занимает заголовок IP и 4 байта поле FCS канального уровня). Адреса отправителя, а также номера портов отправителя и получателя случайным образом изменялись в заданном диапазоне.

Результаты работы генератора показаны ниже

pktgen version 1.33
Params: count 1000000 pkt_size: 1400 frags: 0 ipg: 50 clone_skb: 0 odev "eth0"
     dst_min: 172.16.33.2 dst_max: src_min: 192.168.77.1 src_max: 192.168.77.254
     src_mac: 00:A0:CC:60:6F:B7 dst_mac: 00:05:5D:00:33:44
     udp_src_min: 1 udp_src_max: 1024 udp_dst_min: 1 udp_dst_max: 1024
     src_mac_count: 0 dst_mac_count: 0
     Flags: IPSRC_RND UDPSRC_RND UDPDST_RND
Current:
     pkts-sofar: 999998 errors: 0
     started: 1105549619362ms stopped: 1105549762716ms now: 1105549762716ms idle: 118927868357ns
     seq_num: 2469997 cur_dst_mac_offset: 0 cur_src_mac_offset: 0
     cur_saddr: 0xefc830d4 cur_daddr: 0x22110ac cur_udp_dst: 241 cur_udp_src: 706
Result: OK: 143321561(c139571702+d3749859) usec, 999998 (1404byte,0frags)
6977pps 78Mb/sec (78365664bps) errors: 0

Как вы можете видеть, в данном случае поток трафика составил 78 Мбит/с, что для устройства 100Base-TX достаточно хороший результат. В зависимости от настройки параметров мне удавалось получать значения до 90 Мбит/с для одного процесса генерации пакетов.

Как уже было сказано выше, вы можете создать множество сценариев генерации для одного или нескольких “виртуальных генераторов” pg и запускать их последовательно или одновременно (до 8) вручную или с помощью дополнительных shell-сценариев, выбирающих скрипты запуска генерации. Таким образом можно протестировать различные конфигурации хостов, маршрутизаторов, коммутаторов для проверки производительности их работы. Генератор пакетов достаточно эффективно можно использовать и при тестировании систем обеспечения безопасности (пакетные фильтры, IDS, средства обнаружения сканеров, системы мониторинга трафика и т. п.). Ваши возможности тестирования систем канального и сетевого уровня, а также работающих по протоколу UDP сетевых приложений реально могут быть ограничены только вашей фантазией.

Опишу здесь один интересный и не совсем очевидный вариант использования генератора для прецизионного измерения вариаций задержки в сети. При установке параметра clone_skb=0 для каждого генерируемого пакета создается новый буфер skb и в поле данных пакета UDP включается временная метка. Метки содержат время в формате timeval, принятом в Linux. Первая пара байтов метки содержит время генерации буфера в секундах, вторая – дробную часть момента генерации в микросекундах. Найти эту метку можно по смещению — +8 от начала поля данных UDP, +16 от начала заголовка UDP, +36 от начала заголовка IP или +50 от начала кадра Ethernet. Как уве было сказано, временная метка содержит 8 байтов, из которых 4 байта с меньшим смещением содержат число секунд, а 4 байта с большим смещением – число микросекунд в момент генерации буфера skb. Эти сведения в комбинации с временными параметрами, полученными при сборе пакетов позволяют весьма точно измерить вариации задержки при доставке пакетов через сеть. Если же часы в исходной и конечной точках синхронизированы между собой, вы можете с высокой точностью измерять не только вариации задержки, но и ее абсолютные значения.

Указывается в пакетах и порядковый номер. Нумерация ведется независимо для каждого pg, причем при активизации нового теста (без перезагрузки модуля pktgen) нумерация продолжается с того значения, которое было достигнуто в предыдущем сеансе для этого pg. Наличие порядковых номеров позволяет использовать пакеты для тестирования систем со множеством путей доставки, проверяя сохранность порядка доставки при использовании разных путей. Порядковый номер (4 байта) расположен перед временными метками (+4 от начала поля данных UDP). Первые 4 байта поля данных занимает сигнатура генератора 0xbe9be955, которую также можно использовать в программах анализа для идентификации полей порядкового номера и временных меток.

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

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

Генерируемые пакеты передаются ядром непосредственно в устройство (точнее буфер skb), поэтому большинство средств сетевого мониторинга на локальном компьютере просто не сможет видеть этих пакетов.
Пакеты генерируются с малым временем жизни (TTL = 3), что ограничивает дальность их распространения. Это сделано осознанно в целях ограничения области распространения генерируемых пакетов. Вы можете изменить это значение, внеся изменения в исходный код модуля и собрав заново модуль. Можно поменять значение TTL в пакетах и другими способами, но следует быть осторожным, поскольку при неаккуратном обращении выпущенные за пределы вашей сети пакеты могут доставить кому-либо серьезные неприятности.
По умолчанию кадры Ethernet, содержащие созданные генератором пакеты, имеют в поле MAC-адреса получателя значение 00:00:00:00:00:00, поэтому в коммутируемой сети эти пакеты просто не попадут к получателю. Для задания MAC-адреса получателя служат параметры dstmac, dst_mac_count и flag, описанные выше. Напомним еще раз, что при наличии между генератором и адресатом маршрутизаторов и иных устройств, обрабатывающих пакеты на сетевом уровне, в качестве MAC-адреса получателя следует указывать значение адреса интерфейса такого устройства.
При указании диапазона номеров порта для отправителя или получателя следует различать два случая:

если значение udp_*_min >= udp_*_max, пакеты генерируются с номерами портов от udp_*_min до udp_*_max, включая граничные точки [udp_*_min, udp_*_max];
если udp_*_min < udp_*_max, используются номера портов из диапазонов [0, udp_*_max) и (udp_*_min, 65535].

Значения некоторых параметров, устанавливаемых при помощи команды pgset в целях упрощения не проверяются на этапе установки. Для обеспечения корректной работы генератора параметры проверяются в процессе генерации пакетов с приведением значений к заданному типу в соответствии с правилами преобразования языка C. Поэтому при вводе слишком больших значений для некоторых параметров (в частности, ipg) вы просто будете терять старшие двоичные разряды заданного значения. Например, задав для ipg значение 4294967296 (2^32), вы получите на самом деле ipg=0.
Если при повторном запуске генератора с тем же номером pg тот или иной параметр не был установлен с помощью команды pgset, при генерации пакетов будет использовано предыдущее значение данного параметра, которое сохранено в файле /proc/net/pktgen/pg*.

В заключение следует отметить, что входящий в состав ядра исходный код генератора (net/core/pktgen.c) и файл документации (Documentation/networking/pktgen.txt) содержит целый ряд ошибок. Обнаруженные ошибки исправлены и корректный исходный код генератора пакетов будет включен в новые версии ядра. При желании вы сможете загрузить исправленный файл, воспользовавшись приведенной ссылкой http://bugme.osdl.org/show_bug.cgi?id=4037. Исправленный вариант обеспечивает корректную установку и обработку значений всех параметров в соответствии с приведенной в данной статье и документации модуля информацией. Отметим также, что включенный в официальное ядро исходный код генератора можно использовать, но в некоторых ситуациях могут возникать проблемы с установкой желаемых параметров, что затруднит проведение тестов с помощью этого генератора.

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

Рубрика: Linux, Измерения и тестирование | Комментарии отключены

RFC 3942 Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options

Опубликовано 26.11.2004 автором Nikolai Malykh

Network Working Group                                            B. Volz
Request for Comments: 3942                           Cisco Systems, Inc.
Updates: 2132                                              November 2004
Category: Standards Track

Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options

Реклассификация опций протокола DHCPv4

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

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

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

Аннотация

Этот документ обновляет RFC 2132 для реклассификации кодов опций протокола DHCPv4¹ с десятичными значениями 128 — 223 как общедоступных с управлением IANA в соответствии с RFC 2939. Документ указывает IANA сделать эти опции доступными для распределения как общедоступных опций DHCP.

Оглавление

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

1. Введение

Определенный в DHCPv4 [RFC2131] диапазон общедоступных опций (1 — 127) почти исчерпан. Усилия, подобные [RFC3679] помогли продлить срок жизни этого пространства, однако в конце концов оно закончится.

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

2. Уровни требований

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

3. Основания

Пространство опций DHCP (0 — 255) было разделено на два диапазона [RFC2132]:

1 — 127 — общедоступные опции, распределяемые в соответствии с [RFC2939];
128 — 254 — специфические для сайта опции.

Особые опции 0 (заполнение — pad) и 255 (конец опций — end) были определены в [RFC2131].

3.1. Диапазон общедоступных опций

Пространство опций общего назначение (1 — 127) почти закончилось. Недавняя работа [RFC3679] позволила продлить время, поскольку освободила часть выделенных, не не используемых опций. Время от времени можно пересматривать опции для определения неиспользуемых кодов, которые можно вернуть.

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

Использование кодов 126 и 127 для 16-битовых опций было предложено Ralph Droms в конце 1996 г. Однако это существенно усложняет первую опцию, выделенную в этом пространстве, поскольку требует реализации поддержки 16-битовых опций. В результате коды 126 и 127 были возвращены [RFC3679].
Использование нового magic cookie и 16-битовых кодов опций. Однако это имеет целый рад недостатков:
- усложняет первую опцию, выделенную в новом пространстве, поскольку требует внесения значительных изменений в программы клиентов, серверов и ретрансляторов;
- может негативно влиять на имеющиеся программы клиентов, серверов и ретрансляторов, которые не смогут должным образом проверить значение magic cookie;
- требует поддержки обоих форматов сообщений в обозримом будущем;
- требует от клиентов передавать множество сообщений DHCPDISCOVER (по 1 для каждого magic cookie).
Реклассификация части отданных для сайтов опций как общедоступных. Влияние этого изменения минимально и затронет лишь сайты, которые использовали такие опции — их придется перенумеровать.

3.2. Диапазон опций для сайтов

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

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

4. Реклассификация опций

Коды опций 128 — 223 классифицируются как общедоступные, а для сайтов остается 31 опция (224 — 254).

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

Опции 128 — 223 будут переведены IANA в состояние недоступных (Unavailable) и пока не будут распределяться в качестве общедоступных.
Производители, использующие одну или множество таких опций, в течение 6 месяцев после публикации этого RFC уведомляют рабочую группу DHC и IANA о применении конкретных номеров опций и согласии опубликовать документ об их использовании в серии RFC. IANA переведет эти опции из состояния Unavailable в Tentatively Assigned (предварительно распределены). У производителя будет 18 месяцев после публикации этого RFC’s до начала процесса документирования путем представления документа Internet-Draft.

Примечание. Если на один номер опции будет претендовать несколько производителей, продемонстрировавших достаточно широкое применение опции, этот номер не будут выделен ни одному из них и они должны будут пройти обычный процесс получения номера общедоступной опции [RFC2939].
Все опции, которые сохранят состояние Unavailable через 6 месяцев после публикации этого RFC, будут переведены IANA в состояние Unassigned (не выделено). Эти опции становятся доступными для распределения в соответствии с [RFC2939].
Для опций в состоянии Tentatively Assigned у производителей будет 18 месяцев с момента публикации этого RFC на представление документа Internet-Draft, описывающего опцию. Документированное использование должно соответствовать реальному. После публикации документа об использовании опции как RFC агентство IANA переведет опцию в состояние Assigned (выделено).

Если Internet-Draft не будет представлен в течение 18 месяцев или срок действия документов Internet-Draft истечет через 18 месяцев, IANA переведет опцию в состояние Unassigned и она станет доступной для обычного распределения в соответствии с [RFC2939].

Сайтам, использующим опции из реклассифицированного диапазона, следует предпринять действия по смене номеров своих опций на значения из оставшегося диапазона. Если сайту нужно более 31 опции, он должен решить свои задачи с помощью других опций, таких как Relay Agent Information [RFC3046].

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

Этот документ сам по себе не обеспечивает безопасности и не влияет на текущую безопасность DCHP, описанную в [RFC2131].

6. Взаимодействие с IANA

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

Расширить пространство общедоступных опций DHCPv4 с 1 — 127 до 1 — 223. Новые опции 128 — 223 указываются ка недоступные (Unavailable) и их недопустимо выделять.
Принимать уведомления от производителей, использующих опции из диапазона 128-223 и желающих документировать их использование. Опции переводятся IANA в состояние Tentatively Assigned.
Изменение статуса опций Unavailable на Available по истечении 6 с момента публикации этого RFC для распределения в соответствии с [RFC2939].
Смена статуса Tentatively-Assigned на Unavailable по истечении 18 месяцев с момент публикации этого RFC и позднее (пока существует статус Tentatively-Assigned), если нет действующего документа Internet-Draft по использованию опции.

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

Большое спасибо Ralph Droms и Ted Lemon за их вклад и ранние работы по различным вариантам решения задачи.

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

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

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

[RFC2131] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, March 1997.

[RFC2132] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, March 1997.

[RFC2939] Droms, R., «Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types», BCP 43, RFC 2939, September 2000.

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

[RFC3046] Patrick, M., «DHCP Relay Agent Information Option», RFC 3046, January 2001.

[RFC3679] Droms, R., «Unused Dynamic Host Configuration Protocol (DHCP) Option Codes», RFC 3679, January 2004.

Адрес автора

Bernard Volz

Cisco Systems, Inc.

1414 Massachusetts Ave.

Boxborough, MA 01719

USA

Phone: +1 978 936 0382

EMail: volz@cisco.com

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

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

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

Copyright (C) The Internet Society (2004).

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

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

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

1Dynamic Host Configuration Protocol version 4 — протокол динамической настройки конфигурации хоста, версия 4.

Рубрика: RFC | Комментарии отключены

Мосты Ethernet

Опубликовано 05.11.2004 автором Nikolai Malykh

PDF

По материалам стандарта 802.1D-2004 — IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges.

Маркировка разделов и ссылки соответствуют указанному выше документу.

7. Принципы работы моста

В этом разделе

Разъяснены основные элементы работы мостов (Bridge) и перечислены поддерживаемые ими функции.
Описана архитектурная модель моста, регулирующая предоставление функций.
Представлена модель работы моста в терминах процессов (Process) и объектов (Entity), поддерживающих функции моста.
Детализированы требования к локальным сетям на базе мостов (Bridged Local Area Network) и задана адресация объектов в мостах.

7.1 Работа моста

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

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

7.1.1 Трансляция

Мост MAC транслирует отдельные пользовательские кадры данных между устройствами MAC в среде ЛВС на основе мостов, подключенными к портам этого моста. Ниже перечислены функции для поддержки трансляции кадров и QoS.

Прием кадров.
Отбрасывание кадров с ошибками (6.3.2).
Отбрасывание кадров, в которых frame_type отличается от user_data_frame (6.4).
Регенерация приоритета пользователя при необходимости (6.4).
Отбрасывание кадров для предотвращения петель в физической топологии сети.
Отбрасывание кадров для поддержки управления физической топологией сети.
Отбрасывание кадров в соответствии с фильтрами.
Отбрасывание кадров со служебными данными (service data unit) избыточного размера (6.3.8).
Пересылка полученных кадров в другие порты моста.
Выбор класса трафика после применения фильтров.
Размещение кадров в очередях в соответствии с классом трафика.
Отбрасывание кадров в случае превышения ими максимально допустимой задержки для моста (6.3.6).
Выбор кадров из очередей для передачи.
Выбор выходного приоритета (6.3.9).
Отображение служебных данных и новый расчет FCS¹ при необходимости (6.3.7, 7.7.6).
Передача кадров.

7.1.2 Данные для фильтрации и трансляции

Мост фильтрует кадры (т. е., не передает кадры полученные портом в другие порты или порт данного моста) для предотвращения дублирования кадров (6.3.4) и обеспечения административного контроля над сетевыми ресурсами. Функции, поддерживающие фильтрацию и управление ею, перечислены ниже.

Распределенный расчет и настройка состояния Port State (7.4) для каждого Bridge Port в сети с целью создания полного, простого и симметрично подключенного связующего дерева активной топологии.
Административная установка состояний MAC_Enabled (6.4.2) или Administrative Bridge Port (14.8.2.2) для исключения портов из активной топологии.
Принятая по умолчанию или заданная администратором конфигурация протокола RSTP² (раздел 17) для включения в активную топологию конкретных портов моста и подключенных к нему ЛВС.

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

Постоянная конфигурация зарезервированных адресов.
Явная настройка статических фильтров.
Автоматическое определение динамических данных фильтрации для индивидуальных адресов получателей на основе наблюдения адресов источников сетевого трафика.
Отбрасывание устаревших динамических данных фильтрации.
Автоматическое добавление и удаление динамических данных фильтрации в результате обменов GMRP.

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

Явная настройка классов трафика, связанная с портами моста.

7.1.3 Управление мостом

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

Рисунок 7-1. ЛВС на основе мостов.

7.2 Архитектура моста

Модель моста включает:

транслятор MAC Relay Entity, соединяющий порты моста;
не менее двух портов;
объекты вышележащего уровня (Higher-Layer Entity), включая не менее одного объекта STP (Spanning Tree Protocol Entity).

Транслятор MAC выполняет независимые от метода доступа к среде функции (Media Access Method Independent Function) трансляции кадров между портами моста, фильтрации кадров и получения динамических данных фильтрации. Он использует внутренний сервисный подуровень (Internal Sublayer Service, 6.4, 6.5), обеспечиваемый отдельными объектами MAC на каждом порту.

Каждый порт моста получает кадры из подключенной к нему ЛВС и передает кадры в ЛВС. Отдельный объект MAC (MAC Entity), постоянно связанный с портом, обеспечивает внутренний сервис (6.4, 6.5) для приема и передачи кадров. Объекты MAC выполняют все функции, зависящие от метода доступа к среде (Media Access Method Dependent Function), т. е. протокол и процедуры MAC.

Объект STP рассчитывает и настраивает активную топологию сети.

Объект STP и другие пользователи вышележащего уровня, такие как управление мостом (Bridge Management, 7.1.3), и объекты GARP, включая GARP Participant (Раздел 12), используют процедуры управления логическим каналом (LLC³). Эти процедуры обеспечиваются раздельно для каждого порта и используют сервис MAC, предоставляемый отдельными объектами MAC.

Рисунок 7-2. Порты моста.

На рисунке 7-1 приведен пример физической топологии ЛВС на основе мостов. ЛВС соединяются мостами MAC Bridge и каждый порт моста служит для подключения одной ЛВС. На рисунке 7-2 показан мост с двумя портами, а на рисунке 7-3 — архитектура такого моста. Термин «объекты LLC» (LLC Entities) на рисунках 7-3 и 7-9 относится к объединению функций канального уровня (включая демультиплексирование), обеспечиваемых LLC (ISO/IEC 8802-2), а интерпретация типа в поле Length/Type соответствует стандарту IEEE Std 802.3.

Рисунок 7-3. Архитектура моста.

7.3 Модель работы

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

Параграфы 7.5 и 7.6 задают использование объектом трансляции MAC (MAC Relay Entity) внутреннего сервисного подуровня. Информация о состоянии порта (Port State, 7.4) регулирует участие каждого порта в работе ЛВС.

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

Процесс пересылки (7.7) отправляет полученные кадры, которые будут транслироваться в другие порты моста, фильтруя кадры на основе данных из базы фильтров (Filtering Database, 7.9) и состояния портов моста (7.4).
Процесс обучения (Learning Process, 7.8) на основе наблюдаемых адресов отправителей в кадрах, принятых каждым портом, обновляет базу фильтров (7.9) с учетом состояния порта (7.4).
База фильтров (Filtering Database, 7.9) содержит данные для фильтрации и поддерживает запросы процесса пересылки о возможности отправки кадров с данным полем MAC Address для получателя в данный порт.

Каждый порт моста работает также в качестве конечной станции, обеспечивающей сервис MAC подуровню LLC, который, в свою очередь, поддерживает работу объекта STP (7.10) и других возможных пользователей LLC, таких как протоколы управления мостом (7.11).

Каждый порт моста должен поддерживать работу процедур LLC типа 1 для обеспечения работы объекта STP. Порты моста могут поддерживать другие типы процедур LLC, которые могут использоваться другими протоколами.

Рисунок 7-4. Трансляция кадров MAC.

На рисунке 7-4 показан пример трансляции кадра между портами двухпортового моста.

Рисунок 7-5. Наблюдение сетевого трафика.

На рисунке 7-5 проиллюстрировано включение информации, передаваемой в одном кадре, принятом на одном из портов двухпортового моста в базу фильтров (Filtering Database).

Рисунок 7-6. Работа GARP.

На рисунке 7-6 показаны прием и передача кадра BPDU4 объектом STP.

Рисунок 7-7. Работа протокола соединения между мостами.

На рисунке 7-7 показано получение и передача GARP PDU5 объектом GARP (7.10).

7.4 Состояние портов и активная топология

Каждый порт моста имеет рабочее состояние (Port State), которое управляет пересылкой кадров MAC этим портом и использованием адресов отправителей в кадрах для обучения.

Активная топология сети на основе мостов в любой момент представляет собой набор коммуникационных путей, образованных соединениями между ЛВС и мостами через пересылающие порты. Функция распределенного алгоритма связующего дерева (Spanning Tree) и реализующего его протокола (раздел 17) заключается в установке состояния портов для создания активной топологии, которая просто обеспечивает пересылку кадров между любой заданной парой MAC-адресов, используемых конечными станциями ЛВС. Пересылка и обучение, выполняемые каждым портом моста, поддерживается динамически для предотвращения временных петель и избыточного трафика в сети с минимизацией отказов в обслуживании в результате изменения физической топологии сети.

Любому порту, который не включен (например, имеет MAC_Operational = False, 6.4.2 или исключен из активной топологии путем установки Administrative Bridge Port State = Disabled, 14.8.2.2) или был динамически исключен из процесса пересылки и обучения, назначается состояние Discarding (отбрасывание кадров). Любому порту, на котором разрешено обучение, но запрещена пересылка, назначается состояние Learning, а порту с разрешенным обучением и пересылкой — Forwarding.

Примечание. Текущая база IETF Bridge MIB (IETF RFC 1493) использует состояния (dot1dStpPortState) disabled (отключен), blocking (заблокирован), listening (прослушивание), learning (обучение), forwarding (пересылка) и broken (оторван от сети). Состояния learning и forwarding точно соответствуют состояниям Learning и Forwarding, заданным этим стандартом. Состояния disabled, blocking, listening и broken соответствуют состоянию порта Discarding — хотя эти значения dot1dStpPortState служат для указания различных причин отбрасывания кадров, в процессах Forwarding и Learning они не различаются. Состояние dot1dStpPortState = broken представляет отказ или недоступность MAC для порта, как указано MAC_Operational = FALSE. Состояние disabled представляет исключение порта из активной топологии административными мерами (Administrative Port State = Disabled). Состояние blocking представляет исключение порта из активной топологии алгоритмом STP (роль порта Alternate или Backup, 17.7), listening представляет порт, который алгоритмом STP выбран в качестве участника активной топологии (роль порта Root или Designated), но временно отбрасывает кадры для защиты от петель или некорректного обучения.

На рисунке 7-6 показана работа объекта STP, который использует алгоритм Spanning Tree и связанные с ним протоколы, а также изменение данных состояния порта в процессе определения активной топологии ЛВС.

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

На рисунке 7-5 показано использование данных состояния для порта, принимающего кадр, процессом обучения (Learning) с целью определения возможности включения данных о местонахождении станции в базу фильтров (Filtering Database).

7.5 Прием кадра

Отдельный объект MAC каждого Bridge Port проверяет все кадры, передаваемые в подключенной ЛВС.

Принятые кадры без ошибок (error-free) получают индикацию M_UNITDATA⁶, обработка которой описана ниже.

Кадры с M_UNITDATA.indication frame_type = user_data_frame (6.4) нужно представлять процессам обучения и пересылки. Кадры с другими значениями frame_type не нужно представлять процессу пересылки, но они могут представляться процессу обучения.

Кадры с frame_type = user_data_frame, конечным получателем которых является порт моста, нужно представлять подуровню LLC. Такие кадры содержат индивидуальный MAC-адрес порта или связанный с портом адрес группы (7.12) в поле адреса получателя. Кадры, поданные LLC, могут также передаваться процессу пересылки, как указано выше.

Кадры, адресованные в порт моста (как конечную станцию) и ретранслированные в данный порт другим портом того же моста, тоже нужно представлять подуровню LLC. Никакие другие кадры в LLC не подаются.

7.5.1 Регенерация приоритета пользователя

Значение user_priority в каждом принятом кадре восстанавливается на основании полученного в кадре значения user_priority и таблицы регенерации (User Priority Regeneration) для принимающего порта. Таблица задает восстановленное значение user_priority для каждого из восьми7 возможных значений (от 0 до 7) user_priority в принятых кадрах. В таблице 7-1 приведены используемые по умолчанию значения, которые следует применять как исходные в таблицах каждого порта.

Таблица User Priority Regeneration может быть изменена системой управления, как описано в разделе 14. В таких случаях система управления должна быть способна независимо установить записи каждой таблицы для всех приемных портов и полученных значений user_priority и все значения должны лежать в диапазоне из таблицы 7-1.

Примечание. Значения в таблице User Priority Regeneration для данного порта должны быть согласованы с user_priority для трафика, полученного через данный порт, в остальной части сети и следует генерировать подходящие значения приоритета доступа для каждого MAC. Значения user_priority используются:

через таблицу классов трафика (7.7.3) при определении класса для данного выходного порта;
через фиксированные, связанные с MAC отображения (7.7.5) для определения приоритета доступа.

В таблице 7-1 показаны принятые по умолчанию значения для регенерации приоритета. В таблице приведены значения таблицы классов трафика для всех возможных количеств поддерживаемых классов. В таблице 7-4 указаны фиксированные отображения user_priority на приоритет доступа, которые требуются для разных методов выходных MAC.

Таблица 7-1. User Priority Regeneration.

Приоритет пользователя	Восстановленный приоритет по умолчанию	Диапазон
0	0	0-7
1	1	0-7
2	2	0-7
3	3	0-7
4	4	0-7
5	5	0-7
6	6	0-7
7	7	0-7

7.6 Передача кадра

Отдельный объект MAC для каждого порта передает кадры, поданные в порт объектом MAC Relay.

Ретранслированные кадры представляются для передачи посредством Forwarding Process. Примитив M_UNITDATA.request связанный с таким кадром содержит поля адресов получателя и отправителя, полученные в соответствующем примитиве M_UNITDATA.indication.

LLC PDU представляются подуровнем LLC как пользователи сервиса MAC, обеспечиваемого Bridge Port. Кадры, передаваемые для доставки PDU, содержат индивидуальный MAC-адрес порта в поле отправителя.

Каждый кадр передается в соответствии с процедурами MAC для конкретной технологии IEEE 802 LAN. В поле frame_type соответствующего M_UNITDATA.request должно быть значение user_data_frame (6.5).

Кадры, переданные по запросу пользователя LLC сервиса MAC, обеспечиваемого портом, также должны представляться объекту MAC Relay.

7.7 Процесс пересылки

Кадры, отправленные Forwarding Process после приема любым из портов моста (7.5), нужно пересылать через другой порт моста, выбранный функциями процесса пересылки. Эти функции учитывают топологические ограничения (7.7.1), использует Filtering Database для фильтрации кадров (7.7.2), помещают кадры в очереди (7.7.3), выбирают кадры из очередей для передачи (7.7.4), отображают приоритеты (7.7.5) и при необходимости перечитывают FCS (7.7.6).

Функции Forwarding Process описаны в параграфах 7.7.1–7.7.6 в терминах действий, выполняемых для данного кадра, полученного на данном порту (приемный порт). Кадры могут пересылаться для передачи в выходные порты (порты передачи), а также отбрасываться без передачи в другой порт.

Примечание. Это описание процесса пересылки ограничивается работой функции трансляции MAC Bridge и не рассматривает действия реальных реализаций после передачи кадра уровню MAC для отправки. В некоторых реализациях MAC при определенных условиях может возникать та или иная неопределенность между передачей выбранных кадров уровню MAC для отправки и реальной последовательностью кадров в среде ЛВС. Примером этого могут служить разные значения Token Holding Time в ЛВС FDDI. Такие неопределенности могут приводить к кажущемуся нарушению правил постановки в очередь и приоритизации. В результате становится невозможной проверка соответствия стандарту для некоторых реализаций путем простого сопоставления наблюдаемого в ЛВС трафика с описываемой моделью Forwarding Process. Проверки соответствия должны также учитывать поведение реализации MAC.

На рисунке 7-4 показана работа процесса пересылки с одним экземпляром кадра, транслируемого между портами двухпортового моста. На рисунке 7-8 представлены детали Forwarding Process.

Рисунок 7-8. Операции процесса пересылки.

7.7.1 Соблюдение активной топологии

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

Принявший кадр Port находился в состоянии Forwarding (7.4).
Предполагаемый порт передачи находится в состоянии Forwarding.
Предполагаемый порт передачи не является принявшим кадр портом.
Размер mac_service_data_unit в кадре не превышает максимальное значение mac_service_data_unit в ЛВС, подключенной к порту, предполагаемому для передачи.

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

7.7.2 Фильтрация кадров

Решение о фильтрации принимается процессом пересылки на основании:

MAC-адреса получателя в принятом кадре;
информации в Filtering Database для данного MAC-адреса и приемного порта;
принятого по умолчанию поведения групповой фильтрации для возможного порта передачи (7.9.4).

Для каждого возможного порта передачи (7.7.1) кадр должен пересылаться или отбрасываться (фильтроваться) в соответствии с определением типов записей в Filtering Database (7.9.1, 7.9.2, 7.9.3). Требуемое поведение пересылки и фильтрации описано в параграфах 7.9.4, 7.9.5 и таблицах 7-6, 7-7 и 7-8.

7.7.3 Постановка кадра в очередь

Процесс пересылки обеспечивает хранилище для помещенных в очередь кадров, ожидающих представления конкретным объектам MAC для каждого Bridge Port с целью передачи. Порядок кадров, полученных на одном порту моста должен сохраняться для:

индивидуальных кадров с данным значением user_priority и комбинацией destination_address и source_address;
групповых кадров с данным user_priority и destination_address.

Процесс пересылки может поддерживать более одной очереди на передачу для данного Bridge Port. Кадры помещаются в очереди на основе значений user_priority (7.5.1) с использованием таблицы классов трафика, которая является частью данных состояния, связанных с каждым портом. Очереди и классы трафика связаны взаимно-однозначным отображением.

Таблицы классов поддерживают до восьми классов трафика, что позволяет разделить очереди для каждого уровня user_priority. Классы трафика нумеруются от 0 до N-1, где N указывает число классов трафика для данного выходного порта. Таблицы классов трафика могут быть управляемыми. Класс трафика 0 соответствует неускоренному (nonexpedited) трафику, остальные соответствуют в той или иной мере ускоренным классам.

Примечание. В конкретном мосту может быть реализовано разное число классов трафика для различных портов. Порты с уровнями MAC, которые поддерживают один уровень приоритета передачи типа CSMA/CD, могут поддерживать более одного класса трафика.

Если процесс пересылки не поддерживает ускоренные классы трафика для данного порта (т. е. для порта имеется единственный класс), все значения user_priority отображаются на класс 0. В мостах с поддержкой ускоренного трафика рекомендуемые отображения user_priority для разного числа классов показаны в таблице 7-2. Каждая запись таблицы указывает класс трафика, назначенный для кадров с данным user_priority.

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

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

Кадры, помещенные в очередь передачи для порта, нужно удалять из этой очереди, для выполнения требований к максимальной транзитной задержке в мосту (6.3.6, таблица 7-3).

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

Таблица 7-2. Рекомендуемые отображения user_priority на класс трафика⁸.

		1	2	3	4	5	6	7	8
		Число доступных классов трафика
Пользовательский приоритет	0 (по умолч.)	0	0	0	1	1	1	1	2
	1	0	0	0	0	0	0	0	0
	2	0	0	0	0	0	0	0	1
	3	0	0	0	1	1	2	2	3
	4	0	1	1	2	2	3	3	4
	5	0	1	1	2	3	4	4	5
	6	0	1	2	3	4	5	5	6
	7	0	1	2	3	4	5	5	7

Таблица 7-3. Допустимая транзитная задержка в мосту.

Параметр	Рекомендуемое значение	Абсолютный максимум
Максимальная транзитная задержка	1,0 секунда	4,0 секунды

7.7.4 Выбор для передачи

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

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

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

7.7.5 Отображение приоритета

Параметр user_priority в примитиве M_UNITDATA.request (6.4) должен совпадать с параметром user_priority в соответствующей индикации данных.

Отображение user_priority на выходной приоритет доступа (access_priority) осуществляется статическими методами уровня MAC. Параметр access_priority в примитиве M_UNITDATA.request (6.4) должен определяться из user_priority в соответствии с таблицей 7-4. Показанные значения должны быть неизменными.

Таблица 7-4. Приоритет доступа на выходе.

user_priority	Приоритет доступа на выходе
user_priority	IEEE 802.3	IEEE 802.5	IEEE 802.11	FDDI
0	0	0	0	0
1	0	1	0	1
2	0	2	0	2
3	0	3	0	3
4	0	4	0	4
5	0	5	0	5
6	0	6	0	6
7	0	6	0	6

7.7.6 Перерасчет FCS

Когда кадр пересылается между двумя объектами MAC одного типа IEEE 802 и данные, учтенные в FCS, не изменяются, значение FCS, полученное в примитиве M_UNITDATA.indication может быть представлено в соответствующий примитив M_UNITDATA.request без перерасчета (6.3.7). Для кадров, пересылаемых между ЛВС с одним типом MAC, мост не должен показывать скорость незамеченных ошибок кадров больше, чем будет достигнута сохранением FCS.

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

Примечание. Имеется две возможности расчета действительного значения FCS. В первом случае генерируется новое значение FCS путем алгоритмического изменения полученного значения FCS, с учетом знания алгоритма FCS и преобразований кадра между его приемом и передачей. Второй вариант основан на обычных процедурах MAC для пересчета FCS в исходящем кадре. Первый вариант может защитить от роста числа незамеченных ошибок в кадрах. Этот подход более подробно рассмотрен в информационном Приложении F. Параметр frame_check_sequence в Internal Sublayer Service (6.4) указывает пригодность или непригодность FCS, отсутствие этого параметра в запросе данных указывает передающему уровню MAC, что значение FCS рассчитано заново.

7.8 Процесс обучения

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

Процесс обучения должен создавать или обновлять динамический фильтр (Dynamic Filtering Entry, 7.9, 7.9.2) в Filtering Database, связанный с MAC Address, в поле отправителя полученного портом кадра, при выполнении всех перечисленных условий.

Принимающий порт находится в состоянии Learning или Forwarding (7.4).
Поле адреса отправителя в кадре указывает конкретную конечную станцию (не групповой адрес).
Не существует записи Static Filtering Entry (7.9, 7.9.1) для соответствующего MAC-адреса, в которой Port Map задает пересылку (Forwarding) или фильтрацию (Filtering) для данного порта.
Результирующее число записей в базе не превышает размер Filtering Database.

Если база Filtering Database уже заполнена, но нужно добавить в нее новую запись, для освобождения места может быть удалена одна из имеющихся записей.

На рисунке 7-5 показана работа процесса обучения при включении в Filtering Database информации о местоположении станции из одного кадра, принятого портом моста.

7.9 База фильтров

База фильтров (Filtering Database) поддерживает запросы процесса пересылки для решения вопросов пересылки кадра, принятого на данном порту с данным MAC-адресом получателя в данный возможный порт передачи (7.7.1, 7.7.2). База содержит записи двух типов:

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

Один тип записей (Static Filtering Entry) представляет всю статическую информацию в Filtering Database для индивидуальных и групповых MAC-адресов. Этот тип позволяет контролировать:

пересылку кадров по индивидуальным адресам получателей;
включение в Filtering Database динамических записей, связанных с расширенными услугами фильтрации (Extended Filtering Services), и использование этой информации.

База фильтров должна содержать записи типа Static Filtering Entry.

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

Для представления динамических фильтров используется два типа записей. Тип Dynamic Filtering Entry используется для указания портов, на которых будут наблюдаться (learning) индивидуальные адреса. Эти записи создаются и обновляются процессом обучения (Learning Process, 7.8), имеют ограниченное время действия и удаляются по окончании срока из Filtering Database. Тип Group Registration Entry поддерживает регистрацию групп MAC-адресов. Эти записи создаются, изменяются и удаляются протоколом GMRP в поддержку расширенных услуг фильтрации (Extended Filtering Services, 6.6.5, 7.9.3, раздел 10) с учетом состояния управляющего элемента Restricted_Group_Registration (10.3.2.3). Если этот элемент имеет значение TRUE, создание Group Registration Entry не разрешено, пока нет записи Static Filtering Entry, которая позволяет динамическую регистрацию для соответствующей группы. Динамические фильтры можно прочитать с помощью удаленного управления через систему Bridge Management (7.11), а также с помощью операций, описанных в разделе 14. Динамические и статические записи включают:

спецификацию MAC-адреса;
отображение Port Map с управляющим элементом для каждого выходного порта и спецификации MAC-адреса.

Службы фильтрации (Filtering Service), поддерживаемые мостом (базовые и расширенные), определяют принятое по умолчанию поведение моста применительно к пересылке кадров, адресованных группе MAC-адресов. В мостах с поддержкой Extended Filtering Services принятое по умолчанию поведение каждого порта для группы MAC-адресов может быть настроено статически или динамически с помощью записей Static Filtering и/или Group Registration, которые могут содержать приведенные ниже спецификации MAC-адресов.

All Group Addresses (все групповые адреса), для которых нет более конкретной записи Static Filtering.
All Unregistered Group Addresses (т. е., все групповые MAC-адреса, не указанные в Group Registration Entry), для которых не существует более конкретной записи Static Filtering.

Примечание. Спецификация All Group Addresses [g)] при использовании в записи Static Filtering с подходящей спецификацией элемента управления обеспечивает возможность настроить для моста, который поддерживает Extended Filtering Services, поведение обеспечивающее лишь Basic Filtering Service на некоторых или всех портах. Это может быть обусловлено двумя причинами:

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

База Filtering Database должна поддерживать создание, обновление и удаление записей Dynamic Filtering процессом обучения (7.8). В мостах с поддержкой Extended Filtering Services база фильтров должна поддерживать создание, обновление и удаление записей Group Registration протоколом GMRP (раздел 10).

На рисунке 7-4 показано использование Filtering Database процессом пересылки для трансляции кадра между портами двухпортового моста.

Рисунок 7-5 иллюстрирует создание или обновление динамической записи в Filtering Database процессом обучения.

На рисунке 7-6 показана работа объекта STP (7.10) и уведомление им Filtering Database об изменении активной топологии, переданном протоколом STP.

7.9.1 Статические фильтры

Статический фильтр (Static Filtering Entry) задает:

спецификацию MAC-адреса, содержащую одно из перечисленных значений:
1. индивидуальный MAC-адрес;
2. групповой MAC-адрес;
3. все групповые адреса, для которых не существует более конкретной записи Static Filtering;
4. все незарегистрированные групповые адреса, для которых не существует более конкретной записи Static Filtering;
отображение Port Map, содержащее элемент управления для каждого выходного порта, указывающий, что кадр с MAC-адресом получателя, который соответствует данной спецификации будет:
1. пересылаться независимо от динамических фильтров в базе Filtering Database;
2. фильтроваться независимо от динамических фильтров;
3. пересылаться или фильтроваться в зависимости от динамических фильтров или в соответствии с принятым по умолчанию поведением групповой фильтрации для выходного порта (7.9.4), если для конкретного адреса нет динамических фильтров.

Все мосты должны обеспечивать возможность поддержки первых двух вариантов спецификации MAC-адреса и первых двух вариантов элементов управления для всех записей Static Filtering [т. е. должны иметь возможность поддержки пп. a1), a2), b1) и b2)].

Мост с поддержкой Extended Filtering Services должен иметь возможность поддержки всех четырех вариантов спецификации MAC-адреса и всех трех вариантов элемента управления для записей Static Filtering, которые задают групповые MAC-адреса, и может поддерживать все три элемента управления для записей Static Filtering, которые задают индивидуальные MAC-адреса [т. е. должны поддерживаться пп. a1) — a4) и может поддерживаться п. b3) в дополнение к поддержке b1) и b2)].

Для данной спецификации MAC-адреса может создаваться отдельная запись Static Filtering со своим отображением Port Map для каждого входного порта из которого кадры принимаются процессом пересылки.

В дополнение к контролю пересылки кадров записи Static Filtering для групповых MAC-адресов обеспечивают значения Registrar Administrative Control для протокола GMRP (разделы 10 и 12, параграф 12.8.1). Статическая конфигурация пересылки кадров, адресованных конкретной группе, в выходной порт указывается значением Registration Fixed для этого порта (желание получать адресованные в группу кадры даже при отсутствии динамической информации). Статическая конфигурация фильтрации кадров, которые в противном случае могли бы быть отправлены в выходной порт, указывается значением Registration Forbidden. Отсутствие записи Static Filtering для группового адреса или настройка пересылки или фильтрации на основе динамических фильтров указывается значением Normal Registration.

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

7.9.2 Динамические фильтры

Динамический фильтр (Dynamic Filtering Entry) задает:

индивидуальный MAC-адрес;
отображение Port Map, содержащее элемент управления, который определяет пересылку кадров, направленных по этому MAC-адресу, в один порт.

Примечание 1. Это эквивалентно указанию номера одного порта, поэтому данная спецификация является прямым эквивалентом динамических фильтров IEEE Std 802.1D в редакции 1993 года.

Записи Dynamic Filtering создаются и обновляются процессом обучения (7.8). Они должны автоматически удаляться по истечении заданного времени Ageing Time (таблица 7-5) с момента создания или обновления записи. Для данного MAC-адреса в базе Filtering Database должно создаваться не более одной записи Dynamic Filtering.

Запись Dynamic Filtering не должна создаваться или обновляться процессом обучения, если для этого MAC-адреса уже имеется любая запись Static Filtering со спецификацией элемента управления для выходного порта, указанного процессом обучения, которая задает пересылку или фильтрацию независимо от динамического фильтра.

Примечание 2. Для мостов, которые не разрешают (необязательную) возможность задавать записи Static Filtering для пересылки и фильтрации на основе динамической информации (см. 7.9.1), включая мосты, соответствующие стандарту IEEE Std 802.1D в редакции 1993 года, это препятствует созданию записей Dynamic Filtering, когда для того же MAC-адреса имеется запись Static Filtering. Это гарантирует соответствие таких мостов спецификации, которая запрещает создавать запись Dynamic Filtering при наличии Static Filtering Entry.

Для мостов, которые разрешают возможность задавать записи Static Filtering для пересылки и фильтрации на основе динамической информации, записи Dynamic Filtering и Static Filtering существуют одновременно для одного MAC-адреса, пока адрес не наблюдался (learning) на порту, для которого имеется запись Static Filtering, задающая «пересылку и фильтрацию независимо от какой-либо динамической информации».

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

Записи Dynamic Filtering не могут создаваться или обновляться системой управления.

Если имеется запись Dynamic Filtering для данного MAC-адреса, создание или обновление записи Static Filtering для того же адреса вызывает удаление любой конфликтующей информации, которая может присутствовать в Dynamic Filtering. Если удаление таких конфликтующих данных будет приводить к отображению Port Map, которое не задает пересылки в какой-либо порт, запись Dynamic Filtering удаляется из Filtering Database.

Старение (ageing) записей Dynamic Filtering гарантирует, что конечные станции, которые были перемещены в другую часть сети, не будут «изолированы навсегда» Принимаются также во внимание изменения активной топологии ЛВС на основе мостов, которые могут «перемещать» конечные станции с точки зрения моста (т. е. путь к этим станциям в результате изменения будет проходить через другой порт моста).

Значение Ageing Time может быть задано системой управления (раздел 14). Диапазон возможных значений и рекомендуемое по умолчанию значение указаны в таблице 7-5. Заданное для использования по умолчанию значение избавляет в большинстве случаев от необходимости явной настройки. Если значение Ageing Time может устанавливаться системой управления, мост должен иметь возможность задавать значения из указанного диапазона с шагом в 1 сек.

Таблица 7-5. Время старения записей.

Параметр	Рекомендуемое по умолчанию значение	Диапазон
Время старения (Ageing Time)	300,0 секунд	10,0 — 1000000,0 секунд

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

Алгоритм и протокол RSTP⁹, заданные в разделе 17, включают процедуру уведомления всех мостов в ЛВС на базе мостов об изменении активной топологии, чтобы записи Dynamic Filtering могли быть удалены из Filtering Database. Если топология не меняется, эта процедура позволяет использовать обычное старение с увеличенным сроком, когда конечные станции не генерируют кадров (возможно отключаясь), не жертвуя возможностью ЛВС продолжать обслуживание станций после автоматической настройки.

7.9.3 Записи регистрации групп

Запись регистрации группы (Group Registration Entry) задает:

спецификацию MAC-адреса, содержащую одно из перечисленных:
1. групповой MAC-адрес;
2. все групповые адреса, для которых не существует более конкретной записи Static Filtering;
3. все незарегистрированные групповые адреса, для которых не существует более конкретной записи Static Filtering;
отображение Port Map, содержащее элемент управления для каждого выходного порта, который задает пересылку или фильтрацию кадров, направленных по MAC-адресу.

Записи регистрации групп создаются, изменяются и удаляются с помощью операций GMRP (раздел 10). Для данной спецификации MAC-адреса должно создаваться не более одной записи Group Registration в базе Filtering Database.

Примечание. Возможно наличие записей Static Filtering со значениями Forward или Filter для некоторых или всех портов, маскирующих динамические значения в соответствующих записях Group Registration. Значения в Group Registration будут по-прежнему обновляться GMRP, поэтому последующее обновление данной записи для разрешения использования динамических фильтров на одном или множестве портов незамедлительно активирует корректное состояние регистрации GMRP, которое до этого было замаскировано статической информацией.

7.9.4 Принятая по умолчанию групповая фильтрация

Пересылкой и фильтрацией адресованных в группу кадров на каждом выходном порту моста с поддержкой Extended Filtering Services можно управлять путем создания записи Static Filtering, которая задает принятые по умолчанию действия для All Group Addresses, и записи Static Filtering которая задает принятое по умолчанию поведение для All Unregistered Group Addresses (7.9.1). Оба принятых по умолчанию варианта поведения, измененных более явными записями Filtering Database, применимыми к MAC-адресу в данном кадре, приемному и выходному портам, выглядят, как показано ниже.

Примечание 1. Как сказано в параграфе 7.9.1, мост может поддерживать создание отдельных записей Static Filtering с разными Port Map для каждого приемного порта. Если это не поддерживается, данная запись Static Filtering применяется для всех приемных портов.

Пересылка для всех групп. Кадр пересылается, если явная запись Static Filtering не задает фильтрацию вне зависимости от каких-либо динамических фильтров.
Пересылка для незарегистрированных групп. Кадр пересылается, если не выполняется ни одно из условий.
1. Явная запись Static Filtering задает фильтрацию вне зависимости от каких-либо динамических фильтров.
2. Явная запись Static Filtering задает пересылку или фильтрацию на основе динамической информации и имеется применимая явная запись Group Registration, задающая фильтрацию.
3. Нет явной применимой записи Static Filtering, но имеется применимая запись Group Registration, задающая фильтрацию.
Фильтрация для незарегистрированных групп. Кадр фильтруется, если не выполняется ни одно из условий.
1. Явная запись Static Filtering Entry задает фильтрацию независимо от каких-либо динамических фильтров.
2. Явная запись Static Filtering задает пересылку или фильтрацию на основе динамической информации и имеется применимая явная запись Group Registration, задающая пересылку.
3. Нет явной применимой записи Static Filtering, но имеется применимая запись Group Registration, задающая пересылку.

В мостах с поддержкой Basic Filtering Services по умолчанию для групповой фильтрации используется поведение «пересылать все группы во все порты моста».

Примечание 2. Пересылка всех групп напрямую соответствует поведению, заданному в IEEE Std 802.1D 1993 года, где пересылаются кадры с групповым MAC-адресом, для которых нет статической информации в Filtering Database. Режим Forward All Groups использует информацию из записей Static Filtering для конкретных групповых MAC-адресов, но переопределяет информацию, содержащуюся в записях Group Registration. Режим Forward Unregistered Groups аналогичен поведению пересылки в мосту по отношению к индивидуальным MAC-адресам — если нет статической или динамической информации для конкретного группового MAC-адреса, кадр пересылается, в противном случае пересылка кадра управляется статически заданными или динамически определенными данными.

Примечание 3. Результатом является то, что принятое по умолчанию поведение групповой фильтрации может быть настроено для каждого порта в мосту с помощью записей Static Filtering, которые динамически определяются записями Group Registration создаваемыми или обновляемыми GMRP (раздел 10). Например, при отсутствии в Filtering Database статической или динамической информации для адресов All Group или All Unregistered Group по умолчанию будет использоваться поведение Filter Unregistered Groups для всех портов. Далее создание записи Dynamic Group Registration для адресов All Unregistered Group с Registered на данном порту приведет к тому, что порт будет использовать поведение Forward Unregistered Groups. Аналогично, создание записи Static Filtering для адресов All Group с Registration Fixed на данном порту приведет к поведению Forward All Groups. Следовательно, использование подходящих комбинаций Registration Fixed, Registration Forbidden и Normal Registration в Port Map записей Static Filtering для спецификаций адресов All Group и All Unregistered Group позволяет для данного порта выполнить один из перечисленных ниже вариантов:

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

7.9.5 Запросы к базе Filtering Database

Каждая запись в Filtering Database содержит:

спецификацию MAC-адреса;
отображение Port Map с элементом управления для каждого выходного порта.

Данный индивидуальный MAC-адрес может быть в записи Static Filtering, Dynamic Filtering, обоих или ни в одной. В таблице 7-6 приведены комбинации данных Static Filtering и Dynamic Filtering для задания пересылки или фильтрации кадров с индивидуальным MAC-адресом получателя на выходном порту.

Таблица 7-6. Комбинация статических и динамических записей для отдельного MAC-адреса.

Данные о фильтрации	Элемент управления статическим фильтром для отдельного MAC-адреса и порта задает:
	Пересылка	Фильтрация	Используется динамический фильтр или нет статического. Элемент управления динамическим фильтром для этого MAC-адреса и порта задает:
	Пересылка	Фильтрация	Пересылка	Фильтрация	Нет динамического фильтра
Результат	Пересылка	Фильтрация	Пересылка	Фильтрация	Пересылка

В таблице 7-7 показаны результаты (Registered или Not Registered) комбинирования записей Static Filtering и Group Registration для адресов All Group Addresses и All Unregistered Group Addresses.

Таблица 7-7. Комбинация статических фильтров и регистрации групп.

Данные о фильтрации	Элемент управления статическим фильтром для отдельного MAC-адреса и порта задает:
Регистрация зафиксирована (пересылка)	Регистрация запрещена (фильтрация)	Используется динамический фильтр или нет статического. Элемент управления динамическим фильтром для этого MAC-адреса и порта задает:
Зарегистрирован (пересылка)	Не зарегистрирован (фильтрация)	Нет регистрационной записи группы
Результат	Зарегистрирован	Не зарегистрирован	Зарегистрирован	Не зарегистрирован	Не зарегистрирован

Данные о фильтрации

Элемент управления статическим фильтром для отдельного MAC-адреса и порта задает:

Регистрация зафиксирована (пересылка)

Регистрация запрещена (фильтрация)

Используется динамический фильтр или нет статического. Элемент управления динамическим фильтром для этого MAC-адреса и порта задает:

Зарегистрирован

(пересылка)

Не зарегистрирован

(фильтрация)

Нет регистрационной записи группы

Результат

Зарегистрирован

Не зарегистрирован

Зарегистрирован

Не зарегистрирован

В таблице 7-8 показаны результаты комбинирования данных записей Static Filtering и Group Registration для конкретных групповых MAC-адресов с результатами из таблицы 7-7 для All Group Addresses и All Unregistered Group Addresses, указывающие пересылку или фильтрацию кадра с групповым MAC-адресом получателя на выходном порту.

Таблица 7-8. Пересылки или фильтрация для конкретной группы MAC-адресов.

				Элемент управления статическим фильтром для отдельного MAC-адреса и порта задает:
				Регистрация зафиксирована (пересылка)	Регистрация запрещена (фильтрация)	Используются данные регистрации группы или нет статической записи. Элемент управления записи Group Registration для этого MAC-адреса и порта задает:
				Регистрация зафиксирована (пересылка)	Регистрация запрещена (фильтрация)	Зарегистрирован (пересылка)	Не зарегистрирован (фильтрация)	Нет регистрационной записи группы
Элементы управления адресами All Group для данного порта задают (таблица 7-7):	Не зарегистрирован	Элементы управления адресами All Unregistered Group для данного порта задают (таблица 7-7):	Не зарегистрирован	Пересылка	Фильтрация	Пересылка	Фильтрация	Фильтрация (Unregistered Groups)
	Не зарегистрирован		Зарегистрирован	Пересылка	Фильтрация	Пересылка	Фильтрация	Фильтрация (Unregistered Groups)
	Зарегистрирован			Пересылка	Фильтрация	Пересылка (All Group)	Пересылка (All Group)	Пересылка (All Group)

7.9.6 Постоянная база данных

Постоянная база данных (Permanent Database) обеспечивает фиксированное хранилище для множества записей Static Filtering. База Filtering Database должна инициализироваться записями Filtering Database из постоянного хранилища.

Записи могут добавляться в постоянную базу и удаляться из нее путем явных воздействий системы управления с помощью функциональности, описанной в разделе 14. Изменения содержимого записей Static Filtering в Permanent Database не влияют на решения о пересылке и фильтрации, принимаемые процессом пересылки, пока Filtering Database не будет инициализирована с использованием обновленных записей.

Примечание 1. Этот аспект Permanent Database можно рассматривать как предоставление «загрузочного образа» для Filtering Database, определяющего содержимое первоначальных записей до того, как будут добавлены динамические фильтры.

Примечание 2. В параграфе 10.3.2.3 определено начальное содержимое Permanent Database, требуемое для работы GMRP.

7.10 Объект STP и объекты GARP

Объект STP работает с протоколом RSTP10. Объекты STP в мостах, подключенных к данной отдельной ЛВС в сети на базе мостов, взаимодействуют между собой путем обмена BPDU11.

На рисунке 7-6 показана работа объекта STP, включая прием и передачу кадров с BPDU, изменение данных состояния, связанных с отдельными портами моста, и уведомление Filtering Database об изменении активной топологии.

Объекты GARP работают с алгоритмами и протоколами приложений GARP, поддерживаемых мостом, и состоят из множества участников GARP (Participant) для данных приложений GARP (параграф 12.2, раздел 10). Объекты GARP мостов, подключенных к данной отдельной ЛВС, взаимодействуют путем обмена GARP PDU12.

Рисунок 7-7 иллюстрирует работу объекта GARP, включая прием и передачу кадров с GARP PDU, использование данных управления из Filtering Database и уведомление Filtering Database об изменениях фильтров.

7.11 Управление мостом

Возможности удаленного управления могут предоставляться мостом и моделируются как выполняемые объектом Bridge Management. Обеспечиваемые возможности и поддерживаемые операции заданы в разделе 14. Протоколы управления мостом (Bridge Management) используют службу, обеспечиваемую с помощью процедур LLC, которые используют услуги MAC, обеспечиваемые Bridged Local Area Network.

7.12 Адресация

Все объекты MAC, взаимодействующие через Bridged LAN, используют 48-битовые адреса. Это могут быть глобально администрируемые адреса (Universally Administered Address) или комбинация с локально администрируемыми адресами.

7.12.1 Конечные станции

Кадры, передаваемые между конечными станциями с использованием сервиса MAC, обеспечиваемого Bridged LAN, содержат MAC-адреса отправителя и получателя в соответствующих полях. Адреса или иные средства идентификации мостов не передаются в кадрах между пользователями и не нужны для трансляции кадров в сети.

Широковещательный адрес и другие групповые MAC-адреса применимы при использовании сервиса MAC, обеспечиваемого Bridged LAN в целом. При отсутствии явных фильтров, заданных системой управления в записях Static Filtering или протоколом GMRP в записях Group Registration (разделы 14 и 10, параграф 7.9), кадры с такими адресами получателей транслируются через сеть.

7.12.2 Порты моста

Отдельные объекты MAC, связанные с каждым портом моста, должны иметь индивидуальные MAC-адреса. Эти адреса используются для всех процедур MAC, требуемых отдельным уровнем MAC.

Кадры, полученные из ЛВС, к которой подключен порт, или транслируемые в нее, содержащие MAC-адрес порта в поле получателя MAC, должны быть представлены пользователю сервиса MAC (LLC) и пользователю сервиса LLC для LSAP, указанного адресом получателя LLC как для конечной станции.

7.12.3 Объекты протоколов STP и GARP

Объекты STP получают и передают только BPDU, которые приходят от других объектов STP или передаются им (или при подключении двух портов моста к одной ЛВС между этими портами).

Объекты GARP получают и передают только GARP PDU (12.10), которые передаются в соответствии с требованиями поддерживаемого приложения GARP.

Объект STP или GARP использует примитив DL_UNITDATA.request (см. IEEE Std 802.2), предоставляемый отдельными объектами LLC, связанными с каждым активным портом моста, для передачи BPDU или GARP PDU. Каждый модуль PDU передается в один выбранный порт моста. PDU принимаются через соответствующие примитивы DL_UNITDATA.indication. Параметры source_address и destination_address в DL_UNITDATA.request должны содержать стандартные адреса LLC, выделенные протоколам STP для моста. Это идентифицирует объекты STP и GARP среди других пользователей LLC.

Каждый примитив DL_UNITDATA.request приводит к передаче блока PDU с командой LLC UI, который содержит BPDU или GARP PDU в своем информационном поле. Поля адресов LLC для получателя и отправителя содержат значения, представленные в примитиве запроса.

Значение, выделенное для LLC-адреса протокола STP, приведено в таблице 7-9¹³.

Таблица 7-9. Стандартный адрес LLC

Адрес	Значение
Bridge Spanning Tree Protocol	01000010

Представление кода. Младший бит значения указывается справа, значимость битов возрастает справа налево. Следует отметить, что используемое здесь представление кода выбрано для обеспечения согласованности с представлением, используемым в этом стандарте, однако оно отличается от ISO/IEC TR 11802-1: 1997.

Стандарт определяет поле идентификатора протокола (Protocol Identifier), присутствующее во всех BPDU (раздел 9) и GARP PDU (параграф 12.10), которое служит для указания разных протоколов, поддерживаемых объектами STP и GARP в области действия адреса LLC. Стандарт задает одно значение Protocol Identifier в разделе 9 для использования в BPDU. Это значение служит для идентификации BPDU, передаваемых между объектами STP алгоритма и протокола RSTP (раздел 17). Второе значение идентификатора для использования в GARP PDU определено в параграфе 12.10. Это значение служит для идентификации GARP PDU, передаваемых между участниками GARP в операциях протокола, описанных в разделе 12. Другие значения этого поля зарезервированы для будущих спецификаций.

Объекты STP и GARP, принимающие BPDU или GARP PDU с неизвестным значением Protocol Identifier должны отбрасывать такие PDU.

Объект STP, работающий с алгоритмом и протоколом RSTP (раздел 17), всегда передает BPDU, адресованные всем другим объектам STP, подключенным к ЛВС, в которую передается кадр с BPDU. Для этой цели выделен 48-битовый универсальный адрес, известный как Bridge Group Address, который должен указываться в поле получателя всех кадров MAC, содержащих BPDU. Значение адреса приведено в таблице 7-10. Этот групповой адрес должен быть указан в Permanent Database (7.12.6), чтобы ограничить распространение BPDU отдельной ЛВС.

Таблица 7-10. Зарезервированные адреса

Адрес	Значение
Bridge Group	01-80-C2-00-00-00
Операция IEEE Std 802.3x Full Duplex PAUSE	01-80-C2-00-00-01
IEEE Std 802.3ad Slow_Protocols_Multicast	01-80-C2-00-00-02
IEEE P802.1X PAE	01-80-C2-00-00-03
Резерв для будущей стандартизации	01-80-C2-00-00-04
Резерв для будущей стандартизации	01-80-C2-00-00-05
Резерв для будущей стандартизации	01-80-C2-00-00-06
Резерв для будущей стандартизации	01-80-C2-00-00-07
Резерв для будущей стандартизации	01-80-C2-00-00-08
Резерв для будущей стандартизации	01-80-C2-00-00-09
Резерв для будущей стандартизации	01-80-C2-00-00-0A
Резерв для будущей стандартизации	01-80-C2-00-00-0B
Резерв для будущей стандартизации	01-80-C2-00-00-0C
Резерв для будущей стандартизации	01-80-C2-00-00-0D
Резерв для будущей стандартизации	01-80-C2-00-00-0E
Резерв для будущей стандартизации	01-80-C2-00-00-0F

Объект GARP, который

работает с протоколом GARP (раздел 12);
поддерживает данное приложение GARP,

всегда передает GARP PDU, адресованные всем остальным объектам GARP, которые

реализуют то же приложение GARP;
подключены к ЛВС, куда передается кадр с GARP PDU.

Групповой MAC-адрес, относящийся к соответствующему приложению GARP, должен указываться в поле MAC-адреса получателя для объектов GARP данной группы. Для этого выделен набор 48-битовых универсальных адресов, называемый адресами GARP Application. Значения этих адресов приведены в таблице 12-1. Эти групповые MAC-адреса зарезервированы для выделения стандартным протоколам в соответствии с заданными критериями (раздел 5.5 в стандарте ISO/IEC TR 11802-2) и указываются в записях Static Filtering базы фильтрации (7.9.1), а также в Permanent Database (7.9.6), как показано ниже.

Адреса GARP Application, назначенные приложениям GARP, которые поддерживаются мостом, настраиваются так, чтобы ограничить распространение GARP PDU данным приложением GARP в ЛВС, куда они передаются.
Адреса GARP Application, назначенные приложениям GARP, которые не поддерживаются мостом, не включаются в Filtering Database и Permanent Database.

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

Поле адреса отправителя в кадрах MAC с BPDU или GARP PDU для приложений GARP, поддерживаемых мостом, должно содержать индивидуальный MAC-адрес порта, через который PDU передается (7.12.2).

7.12.4 Объекты управления мостом

Объект управления мостом (Bridge Management Entity) передает и принимает протокольные блоки данных, используя сервис, обеспечиваемый отдельным объектом LLC, связанным с портом моста. Каждый объект LLC использует сервис MAC, предоставляемый объектом MAC данного порта и поддерживаемый Bridged LAN в целом. Как пользователь сервиса MAC, предоставляемого Bridged LAN, объект Bridge Management может быть подключен к любой точке сети. Кадры, адресованные объекту Bridge Management, будут транслироваться мостами, если это требуется для доступа в ЛВС, к которой подключен объект.

Для предотвращения дублирование кадров с каждой точкой подключения связывается уникальный адрес. Объект Bridge Management для конкретного моста обозначается одним или множеством индивидуальных MAC-адресов в соответствии с идентификатором протокола вышележащего уровня и адресной информацией. Объект может иметь одну или множество точек подключения к Bridged LAN через порты моста, с которым объект связан.

Стандарт задает групповой адрес общего пользования, который служит для передачи запросов объектам Bridge Management, связанным со всеми портами моста, которые подключены к Bridged LAN. Запрос управления в кадре MAC с таким адресом в поле получателя обычно будет приводить к получению множества откликов от одного моста. Этот адрес называют All LANs Bridge Management Group Address и его значение приведено в таблице 7-11.

Таблица 7-11. Зарезервированный адрес.

Адрес	Значение
All LANs Bridge Management Group	01-80-C2-00-00-10

7.12.5 Однозначная идентификация моста

Для каждого моста должен быть выделен уникальный 48-битовый MAC-адрес (Universally Administered), называемый Bridge Address. Это может быть индивидуальный MAC-адрес Bridge Port и в таком случае рекомендуется использовать порт с наименьшим номером (Port 1).

7.12.6 Зарезервированные адреса

Кадры с любым из групповых MAC-адресов, указанных в таблице 7-10, в поле получателя мосту не следует ретранслировать. Эти адреса задаются в Permanent Database. Система управления не должна разрешать изменение или удаление таких записей из баз Permanent и Filtering.

Эти групповые MAC-адреса зарезервированы для стандартных протоколов в соответствии с критериями выделения раздела 5.5 в стандарте ISO/IEC TR 11802-2.

7.12.7 Точки подключения объектов вышележащего уровня

Объекты вышележащего уровня (Higher-Layer Entity) в мосту, такие как STP (7.10), GARP (7.10) и Bridge Management (7.11), моделируются как подключенные напрямую к одной или нескольким ЛВС, соединенных с портами моста точно так же, как конечные станции сети. Хотя эти объекты и функции ретрансляции моста используют такие же индивидуальные объекты MAC для приема и передачи кадров, адресация и подключение этих объектов выглядят так, будто они подключены как отдельные конечные станции «вне» порта или портов, к которым они действительно подключены. На рисунке 7-9 приведен функциональный эквивалент рисунка 7-3 с указанием логического разделения между точками подключения, используемыми объектами Higher-Layer и объектом MAC Relay.

Рисунок 7-9. Логические точки подключения объектов Higher-Layer и MAC Relay.

На рисунке 7-10 показана информация, используемая для управления пересылкой кадров из одного порта моста в другой (Port State и содержимое Filtering Database), в виде цепочки переключателей (в разомкнутом состоянии), помещенных в путь, обеспечиваемый объектом MAC Relay. Для моста, пересылающего кадр между двумя портами все три переключателя должны находиться в замкнутом состоянии. Показывая объекты Higher-Layer с общей точкой подключения к каждой ЛВС, используемой каждым портом моста для пересылки кадров, этот рисунок также иллюстрирует точку, показанную на рисунке 7-9, — элементы управления в пути пересылки не оказывают влияния на способность объекта Higher-Layer передавать и принимать кадры из данной ЛВС, используя прямое подключение к ней (например, между объектом A и LAN A) и влияют лишь на путь непрямой передачи и приема (например, между объектом A и LAN B).

Для функций, обеспечиваемых объектами Higher-Layer требуется один из приведенных ниже вариантов.

Одна точка подключения к Bridged LAN, обеспечивающая связность со станциями, подключенными к сети в любой точке (определяется администратором), как это делает объект Bridge Management.
Отдельные точки подключения к каждой ЛВС, соединенной с портом моста, обеспечивающие связность лишь с партнерскими объектами, подключенными непосредственно к этой ЛВС, как это делают объекты STP и GARP.

Рисунок 7-10. Влияние управляющей информации на путь пересылки.

Во втором случае важно, чтобы функция связывала каждый принятый и переданный кадр с точкой присоединения. Кадры, принятые или переданные через одну точку присоединения, не будут транслироваться в другие порты и подключенные ЛВС (или из них), поэтому MAC-адреса (7.12.3, 7.12.6, таблица 7-10), используемые для доступа к этим функциям, должны быть постоянно включены в базу Filtering Database (7.9.6).

Примечание 1. Для доступа к функциям с разными точками подключения обычно служат групповые MAC-адреса.

Примечание 2. Один объект Higher-Layer может включать функцию, требуемую для одной точки подключения, и функцию, требуемую для разных точек. Доступ к этим двум функциям осуществляется по разным MAC-адресам.

На рисунке 7-11 показана связность пути пересылки кадров, адресованных объектам Higher-Layer, которым требуется точка подключения для каждого порта. Конфигурация Permanent Database во всех мостах для предотвращения ретрансляции кадров, адресованных этим объектам, означает, что они будут получать кадры только через точки прямого подключения (например, из LAN A в объект A и из LAN B в объект B), независимо от состояния портов.

Рисунок 7-11. Точки подключения на уровне порта.

На рисунках 7-12 и 7-13 показана связность пути пересылки кадров, адресованных объекту Higher-Layer, которому требуется одна точка подключения. В обоих случаях Filtering Database разрешает трансляцию кадров, как и состояния портов на рисунке 7-12, где кадры из LAN B транслируются мостом объекту A и LAN A.

Рисунок 7-12. Одна точка подключения (трансляция разрешена).

На рисунке 7-13 кадры из LAN A принимаются объектом напрямую, но кадры из LAN B не транслируются мостом и будут приниматься объектом лишь при наличии другого пути пересылки между LAN A и LAN B. Если показанное на рисунке состояние Discarding Port вызвано расчетом связующего дерева (а не административным запретом), такой путь будет проходить через один или множество мостов. Если нет активного пути STP от B к A, сеть разделится на две Bridged LAN и показанный на рисунке объект Higher-Layer будет доступен через LAN A.

Рисунок 7-13. Одна точка подключения (трансляция не разрешена).

Конкретные объекты Higher-Layer могут учитывать административное состояние порта (Administrative Bridge Port State) в соответствии с их спецификацией. Объект STP относится к их числу и BPDU никогда не передаются и не принимаются на портах с административным состоянием Disabled.

Если объект MAC порта в мосту не работает, объект Higher-Layer, непосредственно связанный с этим портом, будет недоступен, как показано на рисунке 7-14. Объект STP гарантирует состояние порта Discarding, если MAC_Operational (6.4.2) имеет значение FALSE, даже при административном состоянии порта Enabled.

Рисунок 7-14. Эффект состояния порта.

Связность, обеспечиваемая для объектов Higher-Layer и ЛВС, которые образуют Bridged LAN, может дополнительно контролироваться портом моста, выступающим в качестве порта доступа в сеть (IEEE Std 802.1X). Работа управления доступом на уровне порта дает эффект создания двух разных точек доступа в ЛВС. Одной точкой является неуправляемый порт и обмен кадрами через него не зависит от результата проверки полномочий (authorization state), а другой (управляемый) порт разрешает только полномочный обмен кадрами. Если порт не имеет полномочий, объект STP, который использует управляемый порт (как делает объект MAC Relay), не сможет обмениваться BPDU с другими мостами, подключенными к LAN A, и будет устанавливать для Bridge Port состояние Discarding.

Примечание. Если объект STP не знает о состоянии порта Unauthorized и предполагает, что порт может принимать и передавать BPDU, он может установить для Bridge Port State значение Forwarding. После разрешения использовать порт в этом случае может возникать временная петля в сети.

На рисунке 7-15 показана связность, обеспечиваемая объектам Higher-Layer, если объект MAC физически способен передавать и принимать кадры, т. е. MAC_Operational = TRUE, но AuthControlledPortStatus имеет значение Unauthorized. Higher-Layer Entity A и PAE (объект доступа к порту, в котором работает протокол разрешения доступа) подключены к неуправляемому порту и могут передавать и принимать кадры, используя объект MAC, связанный с портом, а Higher-Layer Entity B не может этого. Ни один из трех объектов не может принимать кадры из LAN B или передавать их туда.

Рисунок 7-15. Эффект предоставления полномочий.

Примечание. Значения административного и рабочего состояния, связанные с MAC, состояние полномочности порта и Bridge Port State, совпадают с параметрами ifAdminStatus и ifOperStatus, связанными с соответствующими определениями интерфейса (см. IETF RFC 2233).

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

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

1Frame Check Sequence — контрольная сумма кадра.

2Rapid Spanning Tree Protocol — ускоренный протокол связующего дерева.

3Logical Link Control.

4Bridge Protocol Data Unit — блок данных протокола моста.

5Protocol Data Unit — блок данных протокола.

6Кадры с ошибками, определенными соответствующей спецификацией MAC, отбрасываются объектом MAC без какой-либо индикации M_UNITDATA (6.4).

7Технологии IEEE 802 LAN поддерживают до 8 значений user_priority. В информационном приложении G даны дополнительные описания значений user_priority и их отображения на классы трафика.

8Основания для этого отображения рассмотрены в информационном Приложении G. Кадры с принятым по умолчанию приоритетом пользователя получают преимущество перед классами 1 и 2 в мостах с 4 и более классами трафика.

9Rapid Spanning Tree.

10Rapid Spanning Tree Protocol.

11Bridge Protocol Data Unit — модуль данных протокола мостов.

12GARP Protocol Data Unit — модуль данных протокола GARP.

13ISO/IEC TR 11802-1: 1997 содержит полный список стандартных назначений адресов LLC и критерии выделения.

Рубрика: Основы | Комментарии отключены

RFC 3954 Cisco Systems NetFlow Services Export Version 9

Опубликовано 18.10.2004 автором Nikolai Malykh

Network Working Group B.                                 Claise, Ed.
Request for Comments: 3954                             Cisco Systems
Category: Informational                                 October 2004

Протокол экспорта NetFlow версии 9

Cisco Systems NetFlow Services Export Version 9

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

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

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

Примечание IESG

В этом RFC документирован протокол экспорта NetFlow версии 9 в том виде, как он был представлен IETF в качестве основы для работы IPFIX WG.

Данный RFC сам по себе не рассматривается как возможный стандарт Internet. IETF не несет ответственности за возможность использования протокола с теми или иными целями и специально отмечает, что данный протокол не рассматривался полностью IETF на предмет безопасности, контроля насыщения и некорректного взаимодействия с другими протоколами. Редактор RFC принимал решение о публикации документа по своему усмотрению.

Аннотация

В этом документе содержится спецификация формата экспорта данных NetFlow версии 9 компании Cisco Systems для использования в реализациях сетевых элементов и/или программах сбора данных мониторинга. Формат экспорта NetFlow версии 9 использует шаблоны для предоставления доступа к информации о потоках пакетов IP с высоким уровнем гибкости и расширяемости. Шаблон определяет набор полей с соответствующими описаниями структуры и семантики.

Оглавление

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

1. Введение

Сервис NetFlow компании Cisco Systems обеспечивает администраторам доступ к информации о потоках IP в сети передачи данных. Элементы сети (маршрутизаторы и коммутаторы) собирают данные о потоках и экспортируют их в коллекторы¹. Собранные данные обеспечивают точное измерение параметров использования ресурсов с хорошей детализацией и гибким выбором параметров мониторинга.

Поток данных определяется как однонаправленная последовательность пакетов с неким общим набором свойств, проходящих через сетевое устройство. Собранная информация о потоках экспортируется на внешнее устройство, называемое коллектором NetFlow. Информация о потоках включает большой набор параметров — в частности, адреса IP, счетчики пакетов и байтов, временные метки, значения ToS², номера портов приложений, входные и выходные интерфейсы и т. п.

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

В этом документе содержится спецификация протокола экспорта NetFlow версии 9. Документ рассматривает спецификацию для реализаций протокола с точки зрения как сетевых элементов, так и коллекторов NetFlow. Эта спецификация должна помочь разработчикам реализаций NetFlow v.9 для различных платформ и различных производителей, снижая риск утраты интероперабельности. Формат экспорта NetFlow версии 9 использует шаблоны для предоставления доступа к информации о потоках пакетов IP с высоким уровнем гибкости и расширяемости.

Шаблон определяет набор полей с соответствующими описаниями структуры и семантики.

Основанная на шаблонах модель обеспечивает ряд преимуществ:

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

Рабочая группа IETF IPFIX (IP Flow Information eXport⁴) разрабатывает новый протокол на основе версии 9 протокола NetFlow. Новый протокол IPFIX будет обеспечивать преимущества в ряде областей (устойчивый к перегрузкам траспорт, встроенная защита и т. п.). Более подробно узнать об этом протоколе можно из материалов рабочей группы IPFIX.

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

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

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

Observation Point — точка наблюдения

Observation Point представляет собой место в сети, где можно отслеживать пакеты IP (например, один или несколько интерфейсов маршрутизатора или другого сетевого устройства). Каждая точка наблюдения связана с областью (доменом) наблюдения — Observation Domain.

Observation Domain — область (домен) наблюдения

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

IP Flow или Flow — поток IP или поток

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

Flow Record — запись о потоке

Записи о потоках обеспечивают информацию о потоках IP в точке наблюдения. В этом документе используется также термин «запись для данных о потоке» (Flow Data Record) для обозначения данных NetFlow.

Exporter — экспортер

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

NetFlow Collector — коллектор NetFlow

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

Export Packet — пакет экспорта

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

Packet Header — заголовок пакета

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

Template Record — шаблон

Шаблон определяет структуру и интерпретацию полей записи данных о потоке.

Flow Data Record — запись данных о потоке

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

Options Template Record — шаблон опций

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

Options Data Record — запись данных опций

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

FlowSet — набор потоков

FlowSet — базовый термин для набора записей о потоках, имеющих похожую структуру. В пакетах экспорта после заголовка следует один или множество наборов FlowSet. Существует три разных типа наборов FlowSet: Template FlowSet, Options Template FlowSet и Data FlowSet.

Template FlowSet — набор шаблонов

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

Options Template FlowSet — набор шаблонов опций

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

Data FlowSet — набор данных

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

2.1. Таблица терминов

	Содержимое
FlowSet	Template Record	Data Record
Data FlowSet	/	Запись (записи) Flow Data или Options Data
Template FlowSet	Шаблон(ы)	/
Options Template FlowSet	Шаблон(ы) опций	/

Набор Data FlowSet состоит из записей данных опций или данных о потоке без включения шаблона. Шаблон определяет запись данных о потоке, а шаблон опций — запись данных опции.

Набор Template FlowSet состоит из шаблонов без включения данных о потоке или опциях.

Набор Options Template FlowSet состоит из шаблонов опций без включения данных о потоке или опциях.

3. Картина NetFlow на стороне экспортера

3.1. Процесс NetFlow у экспортера

Процесс NetFlow на стороне экспортера отвечает за создание потоков (Flow) из наблюдаемых пакетов IP. Детали этого процесса выходят за рамки данного документа.

3.2. Окончание срока действия потока

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

Экспортер может детектировать окончание потока. Например, при обнаружении в потоке TCP [RFC793] пакета с флагом FIN или RST запись о потоке экспортируется.
Поток неактивен в течение заданного времени. Значение тайм-аута следует делать настраиваемым на стороне экспортера с возможностью задания нулевого тайм-аута для немедленного завершения.
Для долгосрочных потоков экспортеру следует экспортировать записи о потоке на регулярной основе. Значение периода экспорта следует делать настраиваемым на стороне экспортера.
Если у экспортера возникают внутренние ограничения, возможно досрочное завершение (экспорт) потока. Причиной такого досрочного завершения может явиться достижение верхней ганицы счетчиков или нехватка памяти.

3.3. Транспортный протокол

Для обеспечения эффективной обработки на уровне экспортеров с учетом большого объема пакетов экспорта в протоколе NetFlow используется инкапсуляция этих пакетов в дейтаграммы транспортного протокола UDP [RFC768] для передачи коллектору NetFlow. Однако NetFlow версии 9 обеспечивает независимость от транспортного протокола. Следовательно, обеспечивается возможность работы на базе протоколов с контролем насыщения, таких, как SCTP [RFC2960].

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

Протокол UDP [RFC768] не поддерживает контроля насыщения, поэтому при развертывании NetFlow версии 9 в чувствительной к перегрузкам среде соединение между экспортером и коллектором осуществляется по выделенному каналу. Это обеспечивает воздействие выбросов трафика NetFlow исключительно на выделенный канал без негативного влияния на работу сети. Когда коллектор NetFlow невозможно разместить в одном интервале маршрутизации (one-hop distance) от экспортера или путь между экспортером и коллектором используется не только для передачи данных мониторинга, путь экспорта данных следует строить так, чтобы на нем обеспечивалась устойчивость к максимальным пикам трафика NetFlow от экспортера. Отметим, что при использовании слишком медленного канала экспортер может входить в насыщение.

4. Структура пакета

Пакет экспорта состоит из заголовка, за которым следует по крайней мере один набор данных FlowSet. В качестве FlowSet могут использоваться три типа наборов данных: шаблон (Template), данные (Data), шаблон опций (Options Template).

     +--------+-------------------------------------------+
     |        | +----------+ +---------+ +----------+     |
     | Packet | | Template | | Data    | | Options  |     |
     | Header | | FlowSet  | | FlowSet | | Template | ... |
     |        | |          | |         | | FlowSet  |     |
     |        | +----------+ +---------+ +----------+     |
     +--------+-------------------------------------------+

Пакет экспорта

Идентификатор набора FlowSet ID служит для идентификации различных типов FlowSet. Значения FlowSet ID меньше 256 зарезервированы для специальных наборов типа Template FlowSet (ID 0) и Options Template FlowSet (ID 1). Для наборов Data FlowSet используется значение FlowSet ID больше 255.

Формат наборов Template, Data и Options Template обсуждается ниже. Экспортер должен использовать для всех двоичных целых чисел в заголовке и наборах FlowSet сетевой порядок байтов (его также называют big-endian).

Ниже приведено несколько примеров пакетов экспорта.

Пакет, состоящий из чередующихся наборов Template, Data и Options Template. Примером может служить вновь созданный шаблон, который нужно экспортировать как можно скорей. Поэтому, если уже есть пакет экспорта с Data FlowSet, подготавливаемый к экспорту, в него включают наборы Template и Option Template, чередуя их с данными, как показано на рисунке с учетом доступного в пакете пространства.
```
+--------+--------------------------------------------------------+
|        | +----------+ +---------+     +-----------+ +---------+ |
| Packet | | Template | | Data    |     | Options   | | Data    | |
| Header | | FlowSet  | | FlowSet | ... | Template  | | FlowSet | |
|        | |          | |         |     | FlowSet   | |         | |
|        | +----------+ +---------+     +-----------+ +---------+ |
+--------+--------------------------------------------------------+
```
Пакет экспорта, включающий только наборы Data. Примером может служить пакет экспорта, создаваемый после определения шаблонов записей для передачи их коллектору NetFlow Collector; большая часть пакетов экспорта включает только наборы Data FlowSet.
```
   +--------+----------------------------------------------+
   |        | +---------+     +---------+      +---------+ |
   | Packet | | Data    | ... | Data    | ...  | Data    | |
   | Header | | FlowSet | ... | FlowSet | ...  | FlowSet | |
   |        | +---------+     +---------+      +---------+ |
   +--------+----------------------------------------------+
```
Пакет экспорта, содержащий только наборы Template и Options Template. Например, экспортер может периодически передавать пакеты, содержащие Template и Options Template, чтобы помочь обеспечить коллектору корректность записей Template и Options Template при получении соответствующих записей Flow Data.

   +--------+-------------------------------------------------+
   |        | +----------+     +----------+      +----------+ |
   | Packet | | Template |     | Template |      | Options  | |
   | Header | | FlowSet  | ... | FlowSet  | ...  | Template | |
   |        | |          |     |          |      | FlowSet  | |
   |        | +----------+     +----------+      +----------+ |
   +--------+-------------------------------------------------+

5. Формат пакета экспорта

5.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Version Number          |            Count              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           sysUpTime                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           UNIX Secs                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ниже приведено описание полей заголовка.

Version — версия

Версия формата Flow Record, экспортируемого в данном пакете. Для текущей версии значение этого поля равно 9.

Count — счетчик

Общее число записей в пакете экспорта, равное сумме числа записей Options FlowSet, Template FlowSet и Data FlowSet.

sysUpTime

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

UNIX Secs

Число секунд, прошедших с момента 0000 UTC 1970 до момента отправки экспортером пакета экспорта.

Sequence Number — порядковый номер

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

Source ID

32-битовое значение, идентифицирующее область наблюдения экспортера. Коллекторам NetFlow следует использовать IP-адрес отправителя в комбинации с Source ID для идентификации различных потоков экспорта от одного экспортера.

5.2. Формат шаблона FlowSet

Одним из существенных элементов NetFlow является Template FlowSet. Шаблоны существенно повышают уровень гибкости формата записей о потоках, поскольку они позволяют коллекторам обрабатывать записи о потоках даже при отсутствии возможности интерпретации всех содержащихся в записи данных. Формат Template FlowSet показан на рисунке.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       FlowSet ID = 0          |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID 256          |         Field Count           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Field Type 1           |         Field Length 1        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Field Type 2           |         Field Length 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...               |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Field Type N           |         Field Length N        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID 257          |         Field Count           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Field Type 1           |         Field Length 1        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Field Type 2           |         Field Length 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...               |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Field Type M           |         Field Length M        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...               |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Template ID K          |         Field Count           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...               |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ниже приводится описание полей шаблона.

FlowSet ID — идентификатор набора

Для Template FlowSet зарезервировано значение FlowSet ID = 0.

Length — размер

Общий размер данного набора FlowSet. Поскольку Template FlowSet может включать множество записей Template Record, для определения позиции следующей записи FlowSet, которая может иметь любой тип FlowSet, должно использоваться значение поля Length. Размер представляет собой сумму размеров полей FlowSet ID, Length, а также всех записей Template Record в данном наборе FlowSet.

Template ID — идентификатор шаблона

Каждой из вновь генерируемых записей Template присваивается уникальное значение Template ID. Уникальность должна обеспечиваться в масштабе области наблюдения, генерирующей Template ID. Значения Template ID от 0 до 255 зарезервированы для наборов Template FlowSet, Options FlowSet и других зарезервированных наборов FlowSet, которые будут создаваться. Template ID для наборов Data FlowSets принимают значения от 256 до 65535.

Field Count — счетчик полей

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

Field Type — тип поля

Числовой идентификатор типа поля. Идентификаторы описаны в параграфе «Определения типов полей».

Field Length — размер поля

Размер соответствующего Field Type в байтах (см. параграф «Определения типов полей»).

5.3. Формат Data FlowSet

Формат набора Data FlowSet показан на рисунке.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   FlowSet ID = Template ID    |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 1 - Field Value 1    |   Record 1 - Field Value 2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 1 - Field Value 3    |             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 2 - Field Value 1    |   Record 2 - Field Value 2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 2 - Field Value 3    |             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 3 - Field Value 1    |             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ...              |            Padding            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ниже приведены описания полей Data FlowSet.

FlowSet ID = Template ID

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

Length — размер

Размер данного набора FlowSet, определяемый суммой размеров полей FlowSet ID, Length, всех записей Flow Record в данном наборе FlowSet и байтов заполнения, если они используются.

Record N — Field Value M — запись N — значение поля M

Оставшаяся часть Data FlowSet представляет собой набор записей Flow Data, каждая из которых является набором значений полей. Поля Type и Length заранее определяются в записи Template Record, указанной полем FlowSet ID или Template ID.

Padding – заполнение

Экспортеру следует использовать байты заполнения для выравнивания наборов FlowSet по 4-байтовой границе. Важно отметить, что значение поля Length учитывает байты заполнения. Для заполнения следует использовать значения 0.

Интерпретация формата Data FlowSet возможна только в тех случаях, когда коллектору доступен шаблон Template FlowSet, соответствующий значению Template ID.

6. Опции

6.1. Формат шаблона опций

Записи Options Template (и соответствующие записи Options Data) используются для передачи данных о конфигурации процесса NetFlow или специфических для процесса данных, а не информации о потоке IP.

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

Формат набора Options Template FlowSet показан на рисунке.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       FlowSet ID = 1          |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Template ID           |      Option Scope Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Option Length          |       Scope 1 Field Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Scope 1 Field Length      |               ...             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Scope N Field Length      |      Option 1 Field Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Option 1 Field Length     |             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Option M Field Length     |           Padding             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ниже описаны поля Options Template FlowSet.

FlowSet ID = 1

Значение FlowSet ID = 1 соответствует шаблону опций (Options Template).

Length — размер

Общий размер данного набора FlowSet. Каждый набор шаблонов опций может включать множество записей Options Template. Следовательно, поле Length должно использоваться для определения начала следующей записи FlowSet, которая может представлять собой Template FlowSet или Data FlowSet.

Значения поля Length равно сумме размеров полей FlowSet ID и Length, а также всех записей Options Template в данном FlowSet Template ID.

Template ID — идентификатор шаблона

Идентификатор данного шаблона опций. Значение этого поля больше 255.

Option Scope Length — размер определений поля Scope

Размер (в байтах) всех определений поля Scope, содержащегося в записи Options Template (использование поля Scope рассматривается ниже).

Option Length — размер опций

Размер (в байтах) всех полей определения опций, содержащихся в данной записи Options Template.

Scope 1 Field Type — тип поля Scope 1

Часть процесса Exporter/NetFlow, на которую указывает запись Options Template. В настоящее время определены значения:

1 System — система;

2 Interface — интерфейс;

3 Line Card — линейная плата;

4 Cache — кэш;

5 Template — шаблон.

Например, процесс NetFlow может быть реализован для каждого интерфейса и запись Options Template будет говорить о конфигурации интерфейса, если в качестве типа поля Scope будет указано значение 2 (интерфейс). Соответствующий идентификатор интерфейса будет в этом случае передаваться в связанном наборе Options Data. Возможна дополнительная конкретизация Scope путем указания множества типов, которым соответствует процесс. Отметим, что поля Scope всегда предшествуют полям Option.

Scope 1 Field Length — размер поля Scope 1

Размер (в байтах) поля Scope в записи Options Data.

Option 1 Field Type — тип поля Option 1

Числовой идентификатор типа поля, которое будет появляться в записи Options Template. Значения идентификаторов приведены в параграфе «Определения типов полей».

Option 1 Field Length — размер поля Option 1

Размер поля Option в байтах.

Padding — заполнение

Экспортеру следует использовать байты заполнения для выравнивания начала следующего набора FlowSet по 4-байтовой границе. Важно отметить, что байты заполнения учитываются в поле Length. Для заполнения следует использовать значение 0.

6.2. Формат данных опций

Записи Options Data передаются в наборах Data FlowSets регулярно, но не с каждой записью Flow Data. Частота отправки записей Options Data задается в конфигурации (см. параграф «Управление шаблонами»).

Формат набора Data FlowSet с записями Options Data показан на рисунке.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    FlowSet ID = Template ID   |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 1 - Scope 1 Value    |Record 1 - Option Field 1 Value|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Record 1 - Option Field 2 Value|             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 2 - Scope 1 Value    |Record 2 - Option Field 1 Value|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Record 2 - Option Field 2 Value|             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 3 - Scope 1 Value    |Record 3 - Option Field 1 Value|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Record 3 - Option Field 2 Value|             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ...              |            Padding            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ниже приводится описание полей записей Options Data в наборе Data FlowSet.

FlowSet ID = Template ID

Идентификатор FlowSet ID предшествует каждой группе записей Options Data в наборе Data FlowSet. Значение FlowSet ID совпадает с созданным ранее идентификатором Template ID соответствующей записи Options Template. Коллектор должен использовать FlowSet ID для отображения подходящего типа и размера значений всех последующих полей.

Length — размер

Размер данного набора FlowSet, определяемый суммой размеров полей FlowSet ID и Length, всех записей Options Data в данном наборе FlowSet и байтов заполнения, если они используются.

Record N — Option Field M Value — запись N — значение поля опции M

Оставшаяся часть Data FlowSet представляет собой набор записей о потоках, каждая из которых содержит область охвата и значения полей. Тип и размер полей определяются записью Options Template, указанной идентификатором FlowSet ID или Template ID.

Padding — заполнение

Формат Data FlowSet может интерпретироваться только при доступности для коллектора набора Options Template FlowSet, соответствующего идентификатору Template ID.

7. Управление шаблонами

Записи Flow Data, соответствующие Template Record, могут появляться в том же или последующих пакетах. Записи Template не обязательно передавать в каждом пакете экспорта. Поэтому коллектор NetFlow должен сохранять запись Template для интерпретации соответствующих записей Flow Data, которые будут получены в последующих пакетах.

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

Значения Template ID должны сохраняться в течение всего срока жизни процесса NetFlow на стороне экспортера. Если экспортер или процесс NetFlow по той или иной причине запускается заново (перезагрузка), вся информация о шаблонах теряется и значения Template ID создаются заново. Таким образом, согласованность идентификаторов Template ID после рестарта экспортера или процесса NetFlow не гарантируется.

Вновь созданной записи Template экспортером присваивается неиспользуемое значение Template ID. Если конфигурация шаблона изменяется, текущее значение Template ID «закрывается» и его не следует использовать до перезапуска экспортера или процесса NetFlow. Если коллектор получает новое определение для уже существующего идентификатора Template ID, он должен отбросить предыдущее определение шаблона и использовать взамен новое.

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

Экспортер передает наборы данных Template FlowSet и Options Template FlowSet в следующих случаях:

После перезапуска процесса NetFlow экспортеру недопустимо передавать какие-либо Data FlowSet без отправки соответствующего Template FlowSet и требуемого Options Template FlowSet в предыдущем пакете экспорта или включения этих наборов в тот же пакет. Можно передавать Template FlowSet и Options Template FlowSet заранее, без каких-либо Data FlowSets для того, чтобы обеспечить гарантию наличия у коллектора корректного шаблона до получения первой записи Flow или Options Data.
В случае смены конфигурации экспортеру следует в ускоренном режиме передать новые определения шаблона. В таких случаях экспортер может передать измененные записи Template и Options Template без каких-либо данных заранее, чтобы обеспечить гарантию наличия у коллектора корректного шаблона до получения данных.
В регулярном режиме экспортер должен передать все записи Template и Options Template для обновления коллектора. Срок жизни идентификаторов Template ID на коллекторе ограничен и эти идентификаторы должны периодически обновляться. Существует два варианта обновления шаблонов на стороне коллектора:

обновление через каждые N пакетов экспорта;
обновление по времени — через каждые N минут.

Обе опции должны быть настраиваемыми пользователем на стороне экспортера. При выполнении одного из условий экспортер должен передать Template FlowSet и Options Template.

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

8. Определения типов полей

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

Тип поля	Код	Размер в байтах	Описание
IN_BYTES	1	N	Счетчик входящих данных с размерностью N x 8 битов для подсчета числа байтов, связанных с потоком IP. По умолчанию N = 4.
IN_PKTS	2	N	Счетчик входящих данных с размерностью N x 8 битов для подсчета числа пакетов, связанных с потоком IP. По умолчанию N = 4.
FLOWS	3	N	Число агрегированных потоков; по умолчанию N = 4.
PROTOCOL	4	1	Тип протокола IP.
TOS	5	1	Байт типа обслуживания, задаваемый на входном интерфейсе.
TCP_FLAGS	6	1	Флаги TCP; объединение всех флагов TCP, замеченных в данном потоке.
L4_SRC_PORT	7	2	Номер порта TCP/UDP на стороне отправителя (например, FTP, Telnet и т. п.).
IPV4_SRC_ADDR	8	4	Адрес IPv4 на стороне отправителя.
SRC_MASK	9	1	Число непрерывных битов в маске подсети на стороне отправителя (значение маски в нотации /).
INPUT_SNMP	10	N	Индекс входного интерфейса. По умолчанию N = 2, но могут использоваться большие значения.
L4_DST_PORT	11	2	Номер порта TCP/UDP на стороне получателя (например, FTP, Telnet и т. п.).
IPV4_DST_ADDR	12	4	Адрес IPv4 на стороне получателя.
DST_MASK	13	1	Число непрерывных битов в маске подсети на стороне получателя (значение маски в нотации /).
OUTPUT_SNMP	14	N	Индекс выходного интерфейса. По умолчанию N = 2, но могут использоваться большие значения.
IPV4_NEXT_HOP	15	4	Адрес IPv4 для следующего маршрутизатора.
SRC_AS	16	N	Номер автономной системы BGP на стороне отправителя. N может принимать значения 2 или 4. По умолчанию N = 2.
DST_AS	17	N	Номер автономной системы BGP на стороне получателя. N может принимать значения 2 или 4. По умолчанию N = 2.
BGP_IPV4_NEXT_HOP	18	4	IP-адрес следующего маршрутизатора в домене BGP.
MUL_DST_PKTS	19	N	Счетчик исходящих пакетов IP с групповой адресацией с размерностью N x 8 битов для учета пакетов, связанных с потоком IP. По умолчанию N = 4.
MUL_DST_BYTES	20	N	Счетчик исходящих октетов (байтов) с групповой адресацией с размерностью N x 8 битов для учета байтов, связанных с потоком IP. По умолчанию N = 4.
LAST_SWITCHED	21	4	Значение sysUptime в миллисекундах на момент коммутации последнего пакета в данном потоке.
FIRST_SWITCHED	22	4	Значение sysUptime в миллисекундах на момент коммутации первого пакета в данном потоке.
OUT_BYTES	23	N	Счетчик исходящих данных с размерностью N x 8 битов для подсчета числа байтов, связанных с потоком IP. По умолчанию N = 4.
OUT_PKTS	24	N	Счетчик исходящих данных с размерностью N x 8 битов для подсчета числа пакетов, связанных с потоком IP. По умолчанию N = 4.
IPV6_SRC_ADDR	27	16	Адрес IPv6 на стороне отправителя.
IPV6_DST_ADDR	28	16	Адрес IPv6 на стороне получателя.
IPV6_SRC_MASK	29	1	Число непрерывных битов в маске IPv6 на стороне отправителя.
IPV6_DST_MASK	30	1	Число непрерывных битов в маске IPv6 на стороне получателя.
IPV6_FLOW_LABEL	31	3	Метка потока IPv6 в соответствии с RFC 2460.
ICMP_TYPE	32	2	Тип пакета ICMP⁵; в отчете указывается, как ICMP Type * 256 + ICMP code.
MUL_IGMP_TYPE	33	1	Тип пакета IGMP⁶.
SAMPLING_INTERVAL	34	4	При использовании выборки NetFlow этот параметр определяет скорость выборки; например, значение 100 показывает, что отбирается каждый сотый пакет.
SAMPLING_ALGORITHM	35	1	Задает на уровне платформы алгоритм выборки NetFlow: 0x01 — детерминированная выборка; 0x02 — случайная выборка. Используется вместе с SAMPLING_INTERVAL.
FLOW_ACTIVE_TIMEOUT	36	2	Тайм-аут (в секундах) для активных потоков в кэше NetFlow.
FLOW_INACTIVE_TIMEOUT	37	2	Тайм-аут (в секундах) для неактивных потоков в кэше NetFlow.
ENGINE_TYPE	38	1	Тип машины коммутации потоков (маршрутный процессор, интерфейсная плата и т. п.).
ENGINE_ID	39	1	Числовой идентификатор машины коммутации потоков.
TOTAL_BYTES_EXP	40	N	Счетчик с размерностью N x 8 битов для подсчета байтов, экспортированных областью наблюдения. По умолчанию N = 4.
TOTAL_PKTS_EXP	41	N	Счетчик с размерностью N x 8 битов для подсчета пакетов, экспортированных областью наблюдения. По умолчанию N = 4.
TOTAL_FLOWS_EXP	42	N	Счетчик с размерностью N x 8 битов для подсчета потоков, экспортированных областью наблюдения. По умолчанию N = 4.
MPLS_TOP_LABEL_TYPE	46	1	Тип метки MPLS: 0x00 UNKNOWN 0x01 TE-MIDPT 0x02 ATOM 0x03 VPN 0x04 BGP 0x05 LDP
MPLS_TOP_LABEL_IP_ADDR	47	4	Класс эквивалента пересылки⁷, соответствующий метке MPLS.
FLOW_SAMPLER_ID	48	1	Идентификатор, показываемый в «show flow-sampler».
FLOW_SAMPLER_MODE	49	1	Тип алгоритма, используемого для выборки данных: 0x02 — случайная выборка. Используется вместе с FLOW_SAMPLER_RANDOM_INTERVAL⁸
FLOW_SAMPLER_RANDOM_INTERVAL	50	4	Интервал выборки (в пакетах). Используется вместе с FLOW_SAMPLER_MODE
DST_TOS	55	1	Байт типа обслуживания, задаваемый на выходном интерфейсе.
SRC_MAC	56	6	MAC-адрес на стороне отправителя.
DST_MAC	57	6	MAC-адрес на стороне получателя.
SRC_VLAN	58	2	Идентификатор виртуальной ЛВС (VLAN), связанной со входным интерфейсом.
DST_VLAN	59	2	Идентификатор виртуальной ЛВС (VLAN), связанной с выходным интерфейсом.
IP_PROTOCOL_VERSION	60	1	Номер версии протокола IP (4 для IPv4, 6 для IPv6). При отсутствии в шаблоне предполагается версия 4.
DIRECTION	61	1	Направление потока: 0 — входной; 1 — выходной.
IPV6_NEXT_HOP	62	16	Адрес IPv6 для следующего маршрутизатора.
BGP_IPV6_NEXT_HOP	63	16	Следующий маршрутизатор в домене BGP.
IPV6_OPTION_HEADERS	64	4	Битовое поле, показывающее заголовки опций IPv6, обнаруженные в потоке.
MPLS_LABEL_1	70	3	Метка MPLS на позиции 1 в стеке.
MPLS_LABEL_2	71	3	Метка MPLS на позиции 2 в стеке.
MPLS_LABEL_3	72	3	Метка MPLS на позиции 3 в стеке.
MPLS_LABEL_4	73	3	Метка MPLS на позиции 4 в стеке.
MPLS_LABEL_5	74	3	Метка MPLS на позиции 5 в стеке.
MPLS_LABEL_6	75	3	Метка MPLS на позиции 6 в стеке.
MPLS_LABEL_7	76	3	Метка MPLS на позиции 7 в стеке.
MPLS_LABEL_8	77	3	Метка MPLS на позиции 8 в стеке.
MPLS_LABEL_9	78	3	Метка MPLS на позиции 9 в стеке.
MPLS_LABEL_10	79	3	Метка MPLS на позиции 10 в стеке.

Значение поля является числовым идентификатором данного типа. Для фирменных полей зарезервированы значения: 25, 26, 43 — 45, 51 — 54 и 65 — 69.

При необходимости расширения в список будут добавляться новые типы полей. Новые типы учитываются на стороне экспортера и коллектора, но формат экспорта NetFlow при этом не меняется. Список обновлений типов полей доступен на сайте http://www.cisco.com.

В некоторых случаях размер поля фиксирован по определению (например, для полей PROTOCOL и IPV4_SRC_ADDR). Однако часть типов имеет переменный размер. Это повышает эффективность использования памяти на коллекторе и снижает загрузку сети, по которой осуществляется обмен данными между экспортером и коллектором. Например, для поля IN_BYTES маршрутизатору доступа может быть достаточно 32-битового счетчика (N = 4), а магистральному маршрутизатору потребуется 64 бита (N = 8).

Все счетчики и другие числовые объекты выражаются бесзнаковыми целыми числами размерностью N * 8 битов.

9. Коллектор

Коллектор получает записи Template от экспортера (обычно до получения записей Flow Data или Options Data). Записи Flow Data (или Options Data) в этом случае могут декодироваться и сохраняться на локальных устройствах. Если записи Template не были получены к моменту приема Flow Data (или Options Data), коллектору следует сохранять записи Flow Data (или Options Data) и декодировать их после приема Template. Для коллектора недопустимо предполагать, что Data FlowSet и связанный с ним Template FlowSet (или Options Template FlowSet) экспортируются в одном пакете.

Для коллектора недопустимо предполагать, что в пакете экспорта содержится один и только один набор Template FlowSet.

Срок жизни шаблона в коллекторе ограничен фиксированным тайм-аутом обновления. Срок существования шаблонов, не обновленных экспортером до тайм-аута, истекает. Для коллектора недопустимы попытки декодирования записей Flow или Options Data с истекшим сроком существования шаблона. В любой момент времени коллектору следует поддерживать для всех текущих записей Template и Options Template информацию об экспортере, области наблюдения, последнем полученном пакете экспорта, а также Template ID и определение шаблона.

Отметим, что область наблюдения идентифицируется полем Source ID из пакета экспорта.

При изменении конфигурации часов на стороне экспортера коллектору следует отбросить все записи Template и Options Template, связанные с этим экспортером, чтобы коллектор получил новый набор значений Exporter, Observation Domain, Template ID, Template Definition, Last Received.

Значение Template ID уникально для экспортера и области наблюдения.

Если коллектор получает новую запись Template (например, при перезапуске экспортера), он должен незамедлительно переписать существующую запись Template.

В заключение отметим, что коллектор должен принимать байты заполнения в наборах Data FlowSet и Options Template FlowSet, которые могут использоваться для записей Flow Data, Options Data и Template. Информация о типах записей приведена в таблице параграфа 2.1.

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

Протокол NetFlow версии 9 был разработан в предположении, что экспортер и коллектор находятся в одной приватной сети. Однако этот протокол может использоваться для передачи записей о потоках через публичную сеть Internet, что подвергает записи Flow различным угрозам. Например, атакующий может захватывать, менять или вставлять пакеты экспорта. Следовательно, существует риск перехвата или подмены информации IP Flow в целях атаки на коллектор NetFlow.

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

Протокол IPFIX, использующий NetFlow версии 9 в качестве базового протокола, снимает описанные здесь проблемы безопасности. Дополнительную информацию можно найти в проекте требований IPFIX по безопасности [RFC3917].

10.1. Раскрытие данных из потока

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

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

10.2. Фальшивые записи для потоков и шаблонов

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

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

10.3. Атаки на коллектор NetFlow

DoS-атаки на коллектор NetFlow могут отнимать значительные ресурсы компьютера и коллектор не сможет принять и декодировать некоторые пакеты экспорта NetFlow. Эта опасность не является специфической для NetFlow версии 9 и для снижения вредного влияния могут применяться существующие методы смягчения DoS-атак.

11. Примеры

Рассмотрим пакет экспорта, включающий Template FlowSet, Data FlowSet (с тремя записями Flow Data), Options Template FlowSet и Data FlowSet (с 2 записями Options Data).

Формат пакета показан на рисунке.

   +--------+---------------------------------------------. . .
   |        | +--------------+ +-----------------------+
   | Packet | | Template     | | Data                  |
   | Header | | FlowSet      | | FlowSet               |   . . .
   |        | | (1 Template) | | (3 Flow Data Records) |
   |        | +--------------+ +-----------------------+
   +--------+---------------------------------------------. . .

       . . .+-------------------------------------------------+
            +------------------+ +--------------------------+ |
            | Options          | | Data                     | |
       . . .| Template FlowSet | | FlowSet                  | |
            | (1 Template)     | | (2 Options Data Records) | |
            +------------------+ +--------------------------+ |
       . . .--------------------------------------------------+

11.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Version = 9               |          Count = 7            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           sysUpTime                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           UNIX Secs                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Source ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

11.2. Пример шаблона FlowSet

Мы хоти включить в отчет следующие типы полей:

IP-адрес отправителя (IPv4), размером 4 байта;
IP-адрес получателя (IPv4), размером 4 байта;
IP-адрес следующего маршрутизатора (IPv4), размером 4 байта;
число байтов в потоке;
число пакетов в потоке.

Следовательно, набор Template FlowSet будет иметь вид:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       FlowSet ID = 0          |      Length = 28 bytes        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID 256         |       Field Count = 5         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     IP_SRC_ADDR = 8           |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     IP_DST_ADDR = 12          |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     IP_NEXT_HOP = 15          |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       IN_PKTS = 2             |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       IN_BYTES = 1            |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

11.3. Пример Data FlowSet

В этом примере отчет включает три записи о потоках:

IP-адрес отправителя	IP-адрес получателя	Адрес следующего маршрутизатора	Число пакетов	Число байтов
198.168.1.12	10.5.12.254	192.168.1.1	5009	5344385
192.168.1.27	10.5.12.23	192.168.1.1	748	388934
192.168.1.56	10.5.12.65	192.168.1.1	5	6534

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       FlowSet ID = 256        |          Length = 64          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          198.168.1.12                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          10.5.12.254                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.168.1.1                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             5009                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            5344385                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.168.1.27                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           10.5.12.23                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.168.1.1                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              748                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             388934                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.168.1.56                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           10.5.12.65                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           192.168.1.1                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               5                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              6534                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Отметим, что заполнение в этом примере не требуется.

11.4. Пример Options Template FlowSet

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

общее число пакетов экспорта;
общее число экспортируемых потоков;

Формат Options Template FlowSet показан на рисунке.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       FlowSet ID = 1          |          Length = 24          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID 257         |    Option Scope Length = 4    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Option Length = 8       |  Scope 1 Field Type = 3       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Scope 1 Field Length = 2    |   TOTAL_EXP_PKTS_SENT = 41    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |     TOTAL_FLOWS_EXP = 42      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |           Padding             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

11.5. Пример Data FlowSet с записями Options Data

В этом примере отчет включает две записи.

Идентификатор линейной платы	Пакет экспорта	Поток экспорта
1	345	10201
2	690	20402

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    FlowSet ID = 257           |         Length = 16           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             1                 |             345               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           10201               |              2                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            690                |            20402              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

[RFC768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, «Stream Control Transmission Protocol», RFC 2960, October 2000.

[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, «Requirements for IP Flow Information Export (IPFIX)», RFC 3917, October 2004.

13. Авторы

Этот документ совместно написали Vamsidhar Valluri, Martin Djernaes, Ganesh Sadasivan и Benoit Claise.

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

Авторы благодарны Pritam Shah, Paul Kohler, Dmitri Bouianovski и Stewart Bryant за их ценные технические замечания.

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

Benoit Claise (Editor)

Cisco Systems

De Kleetlaan 6a b1

1831 Diegem

Belgium

Phone: +32 2 704 5622

EMail: bclaise@cisco.com

Ganesh Sadasivan

Cisco Systems, Inc.

3750 Cisco Way

San Jose, CA 95134

USA

Phone: +1 408 527-0251

EMail: gsadasiv@cisco.com

Vamsi Valluri

Cisco Systems, Inc.

510 McCarthy Blvd.

San Jose, CA 95035

USA

Phone: +1 408 525-1835

EMail: vvalluri@cisco.com

Martin Djernaes

Cisco Systems, Inc.

510 McCarthy Blvd.

San Jose, CA 95035

USA

Phone: +1 408 853-1676

EMail: djernaes@cisco.com

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

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

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

Copyright (C) The Internet Society (2004).

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

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

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

1Сборщики информации. Прим. перев.

2Type of Service — тип обслуживания пакетов.

3Internet Service Provider – поставщик услуг Internet. Прим. перев.

4Экспорт информации о потоках IP.

5Internet Control Message Protocol — протокол управляющих сообщений Internet.

6Internet Group Management Protocol — протокол управления группами Internet.

7Forwarding Equivalent Class

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

Рубрика: RFC | Оставить комментарий

RFC 3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture

Опубликовано 18.10.2004 автором Nikolai Malykh

Network Working Group                                 E. Mannie, Ed.
Request for Comments: 3945                              October 2004
Category: Standards Track

GMPLS — обобщенная архитектура многопротокольной коммутации по меткам

Generalized Multi-Protocol Label Switching (GMPLS) Architecture

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

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

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

Аннотация

Сети передачи данных ближайшего будущего будут состоять из таких элементов, как маршрутизаторы, системы DWDM¹, ADM², PXC³, OXC⁴ и т. п., которые будут использовать обобщенную коммутацию по меткам (GMPLS⁵) для динамического предоставления ресурсов и обеспечения живучести сети с использованием технологий защиты и восстановления.

В этом документе описана архитектура GMPLS. Технология GMPLS является расширением MPLS для использования временного мультиплексирования (например, SONET/SDH, PDH, G.709), разделения по длинам волн (лямбда) и пространственной коммутации (например, входной порт или волокно в выходной порт или волокно). GMPLS фокусируется на уровне управления системами, где разные технологии могут использовать физически отличающиеся методы передачи данных и пересылки. Целью является разработка механизмов сигнализации и маршрутизации для уровня управления.

Оглавление

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

1. Введение

Описанная здесь архитектура включает основные блоки, требуемые для построения согласованного уровня управления многочисленными системами (уровнями) коммутации. Архитектура не ограничивает способов взаимодействия различных уровней коммутации. Могут применяться разные модели (например, наложение — overlay, добавление — augment или интеграция — integrate). Более того, каждая пара смежных уровней может взаимодействовать разными способами, что приводит к возникновению множества возможных комбинаций и предоставляет свободу выбора производителям и операторам.

Архитектура явно разделяет уровни (плоскости) управления и пересылки. Кроме того, уровень управления явно делится на две части — сигнальная включает протоколы сигнализации, а маршрутная — протоколы маршрутизации.

Этот документ является обобщением архитектуры многопротокольной коммутации по меткам (MPLS⁶) [RFC3031] и в некоторых случаях может незначительно отличаться от своего предшественника, поскольку в настоящем документе рассматриваются не только технологии с коммутацией кадров. Целью настоящего документа не является повторное описание концепций, используемых в архитектуре MPLS. Цель состоит в описании концепций, специфичных для обобщенной коммутации по меткам (GMPLS).

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

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

1.1. Используемые сокращения

AS Autonomous System — автономная система.

BGP Border Gateway Protocol — протокол граничного шлюза (протокол внешней маршрутизации).

CR-LDP Constraint-based Routing LDP — LDP с вмененной маршрутизацией.

CSPF Constraint-based Shortest Path First — вмененная маршрутизация по кратчайшему пути.

DWDM Dense Wavelength Division Multiplexing — мультиплексирование с разделением по длине волны и высокой плотностью.

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

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

IGP Interior Gateway Protocol — протокол внутренней маршрутизации.

LDP Label Distribution Protocol — протокол распространения меток.

LMP Link Management Protocol — протокол управления метками.

LSA Link State Advertisement — анонс состояния канала.

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

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

MIB Management Information Base — база данных управления.

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

NMS Network Management System — система управления сетью.

OXC Optical Cross-Connect — оптический кросс-коннектор.

PXC Photonic Cross-Connect — фотонный кросс-коннектор.

RSVP ReSource reserVation Protocol — протокол резервирования ресурсов.

SDH Synchronous Digital Hierarchy — синхронная цифровая иерархия.

SONET Synchronous Optical Networks — синхронные оптические сети.

STM(-N) Synchronous Transport Module (-N) — модуль синхронного транспорта уровня N.

STS(-N) Synchronous Transport Signal-Level N (SONET) — сигнал синхронного транспорта уровня N.

TDM Time Division Multiplexing — мультиплексирование с разделением по времени.

TE Traffic Engineering — построение трафика.

1.2. Множество типов иерархий коммутации и пересылки

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

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

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

Интерфейсы с коммутацией пакетов (PSC⁸):Интерфейсы, способные распознавать границы пакетов и пересылать данные на основе содержимого заголовков каждого пакета. Примерами таких интерфейсов могут служить интерфейсы маршрутизаторов, пересылающих пакеты на основе заголовков IP, и интерфейсы маршрутизаторов, коммутирующие пакеты на основе данных shim-заголовков MPLS.
Интерфейсы с коммутацией на уровне 2 (L2SC⁹):Интерфейсы, которые распознают границы кадров/ячеек и могут коммутировать данные на основе содержимого заголовков этих кадров/ячеек. Примерами могут служить интерфейсы мостов Ethernet, которые коммутируют пакеты на основе заголовков MAC, и интерфейсы ATM-LSR, пересылающие данные на основе ATM VPI/VCI.
Интерфейсы с коммутацией TDM¹⁰:Интерфейсы, которые коммутируют данные на основе временного интервала в циклически повторяющейся структуре. Примерами могут служить интерфейсы кросс-коннекторов SONET/SDH (XC), терминальных мультиплексоров (TM¹¹), мультиплексоров ADM. Другим примером могут быть интерфейсы, поддерживающие G.709 (digital wrapper) и интерфейсы PDH.
Интерфейсы с коммутацией длин волн (LSC¹²):Интерфейсы, коммутирующие данные на основе длины волны, на которой эти данные были получены. Примерами таких интерфейсов являются интерфейсы кросс-коннекторов PXC или OXC, способные работать на уровне отдельных длин волн. Другим примером могут служить интерфейсы PXC, которые работают на уровне групп длин волн (полосы) и оптические интерфейсы G.709.
Интерфейсы с коммутацией оптических волокон (FSC¹³):Интерфейсы, которые коммутируют данные на базе их пространственного (физического) расположения. Примером могут служить интерфейсы PXC или OXC, способные работать на уровне одного или группы волокон.

Соединение может быть организовано только между парой однотипных интерфейсов (с возможным участием промежуточных интерфейсов того же типа). В зависимости от используемой на каждом из интерфейсов технологии именование устройств может различаться (например, устройство SDH, оптический путь и т. п.). В контексте GMPLS все такие устройства (каналы) именуются путями с коммутацией по меткам (LSP¹⁴).

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

Например, иерархия может быть организована, если интерфейс может мультиплексировать несколько LSP с одной технологией (скажем, несколько SONET/SDH LSP низкого уровня — VT2/VC-12 в один SONET/SDH LSP — STS-3c/VC-4¹⁵).

Вложенность может использоваться и между разными типами интерфейсов. На верхнем уровне иерархии располагаются интерфейсы FSC, далее следуют LSC, TDM, L2SC и, наконец, PSC. Таким образом, LSP, начинающийся и заканчивающийся на интерфейсе PSC, может быть вложенным (вместе с другими LSP) в LSP, который начинается и заканчивается на интерфейсах L2SC. Этот LSP, в свою очередь, может быть вложен (вместе с другими LSP) в LSP, что начинается и заканчивается на интерфейсах TDM. Этот путь также может быть вложен (вместе с другими LSP) в LSP, начинающийся и заканчивающийся на интерфейсах LSC. И, наконец, этот путь может быть вместе с другими LSP вложенным в LSP, который начинается и заканчивается на интерфейсе FSC.

1.3. Расширение уровня управления MPLS

Организация LSP, проходящих только через интерфейсы PSC или L2SC, определена для уровней управления MPLS и/или MPLS-TE. GMPLS расширяет эти уровни управления для поддержки каждого из пяти классов интерфейсов (т. е., уровней), определенных в предыдущем параграфе.

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

Уровень управления GMPLS включает несколько базовых элементов, описанных ниже. Эти элементы базируются на общепринятых протоколах сигнализации и маршрутизации, которые были расширены или изменены для поддержки GMPLS. Для адресации применяется IPv4 и/или IPv6. Для поддержки работы GMPLS требуется только один специализированный протокол, который обеспечивает сигнализацию при управлении каналами [LMP].

GMPLS в действительности базируется на расширении TE¹⁶ для MPLS или MPLS-TE [RFC2702]. Это обусловлено тем, что большинство технологий, которые могут использоваться ниже уровня PSC, требует некоторого построения трафика. Размещение LSP на таких уровнях в общем случае требует принимать во внимание некоторые ограничения (такие, как кадрирование, полоса пропускания, поддержка защиты и т. п.) и обходить унаследованный алгоритм поиска кратчайшего пути SPF¹⁷. Отметим, однако, что эти требования не обязательны и в некоторых случаях можно применять маршрутизацию SPF.

Чтобы способствовать вмененной¹⁸ SPF-маршрутизации LSP, узлам, создающим LSP, требуется больше информации о каналах в сети, нежели предоставляют стандартные протоколы внутридоменной маршрутизации. Эти атрибуты TE распространяются с использованием транспортных механизмов, доступных IGP (например, лавинной рассылки) и принимаются во внимание алгоритмом маршрутизации LSP. Оптимизация маршрутов LSP может также потребовать некоторых экспериментов по использованию эвристических методов, которые предоставляют входные данные для расчета пути и процесса организации LSP.

По определению TE-канал представляется в анонсах состояния канала IS-IS/OSPF Link State, а также в базе данных о состоянии каналов некоторых физических ресурсов и их свойств между парой узлов GMPLS. Каналы TE используются уровнем управления GMPLS (маршрутизация и сигнализация) для организации LSP.

Требуются расширения для традиционных протоколов и алгоритмов маршрутизации, обеспечивающие однотипное представление и передачу информации TE, а также поддержку явных (например, задаваемых отправителем) маршрутов, которые нужны для сигнализации. Кроме того, сигнализация должна иметь возможность передачи параметров (таких, как полоса пропускания, тип сигнала, необходимость защиты/восстановления, положение в конкретном мультиплексе и т. п.) требуемого канала (LSP). Большинство таких расширений уже определено для построения трафика PSC и L2SC в MPLS. GMPLS главным образом определяет дополнительные расширения для построения трафика TDM, LSC и FSC. Лишь небольшое число элементов зависит от используемой технологии.

Таким образом, GMPLS расширяет два сигнальных протокола, определенных для сигнализации MPLS-TE — RSVP-TE [RFC3209] и CR-LDP [RFC3212]. Однако GMPLS не задает, какой из этих двух протоколов должен использоваться. Производители и операторы могут сами оценить эти варианты с учетом своих интересов.

Поскольку сигнализация GMPLS основана на RSVP-TE и CR-LDP, она диктует выделение и распространение меток по запросу вниз (downstream-on-demand) с инициированным на входе упорядоченным контролем. Обычно используется либеральное удержание меток, но в некоторых случаях может применяться консервативный режим удержания.

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

GMPLS также расширяет для TE два традиционных протокола внутридоменной маршрутизации на основе состояния каналов — OSPF-TE [OSPF-TE] и IS-IS-TE [ISIS-TE]. Однако при использовании явной (заданной отправителем) маршрутизации применяемые этими протоколами алгоритмы больше не требуется стандартизовать. Расширение для междоменной маршрутизации (например, BGP) требует дополнительного исследования.

Использование технологий типа DWDM предполагает наличие очень большого числа соединений между парой смежных узлов (сотни или тысячи длин при использовании множества волокон). Такое количество соединений изначально не рассматривалось для уровня управления IP или MPLS, хотя это может быть сделано. Требуются некоторые незначительные изменения этих уровней управления, если мы хотим улучшить их использование в контексте GMPLS.

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

Для решения этой проблемы было введено понятие связывания каналов (link bundling). Тем не менее, настройка конфигурации и управление такими каналами (даже если они безадресные) требуют значительных усилий. Протокол управления каналом LMP¹⁹) позволяет решить эту проблему.

LMP работает между смежными узлами уровня данных и служит для управления каналами TE. В частности, LMP обеспечивает механизмы поддержки связности каналов управления (IP Control Channel Maintenance), проверки физической связности каналов передачи данных (Link Verification), сопоставления данных о свойствах каналов (Link Property Correlation) и контроля отказов (Fault Localization и Fault Notification). Уникальной особенностью LMP является возможность локализации отказов в прозрачных и «темных» (opaque) сетях (т. е., независимо от схемы кодирования и полосы каналов передачи данных).

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

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

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

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

1.4. Ключевые расширения GMPLS для MPLS-TE

Ниже рассмотрены некоторые важные расширения, добавленные GMPLS в MPLS-TE. Некоторые из них обеспечивают ключевые преимущества GMPLS при управлении уровнями TDM, LSC и FSC.

В MPLS-TE каналы, через которые проходит LSP, могут включать комбинации соединений с гетерогенным представлением меток (например, каналы между маршрутизаторами, между маршрутизатором и ATM-LSR, между ATM-LSR). GMPLS может работать с такими путями, а также поддерживает соединения, где метки кодируются во временной интервал, длину волны или положение в пространстве.
В MPLS-TE путь LSP, передающий трафик IP, начинается и заканчивается на маршрутизаторе. GMPLS дополнительно требует, чтобы LSP начинался и заканчивался на интерфейсах похожих типов.
Типы данных, которые могут передаваться в GMPLS с помощью LSP, расширены и позволяют включать данные SONET/SDH, G.709, 1Gb или 10Gb Ethernet и т. п.
Использование смежности по пересылке (FA²⁰) обеспечивает механизм повышения эффективности использования полосы в тех случаях, когда полоса может выделяться только дискретными порциями. Обеспечивается также механизм агрегирования состояния пересылки, позволяющий снизить число требуемых меток.
GMPLS позволяет восходящим узлам предлагать метки для снижения задержки при организации LSP. Эти предложения могут быть отменены (изменены) нисходящим узлом, но в некоторых случаях такая отмена потребует больших издержек, нежели организация LSP.
GMPLS расширяет возможности ограничения диапазона меток, которые могут быть выбраны нисходящим узлом. В GMPLS восходящий узел может ограничивать метки для LSP на уровне отдельных интервалов или пути LSP в целом. Такая возможность полезна в фотонных сетях, где преобразование длин волн может быть недоступно.
Хотя традиционные LSP на базе TE (и даже LDP) являются односторонними, GMPLS поддерживает организацию двухсторонних LSP.
GMPLS поддерживает завершение LSP на конкретном выходном порту, т. е. выбор порта на приемной стороне.
GMPLS с RSVP-TE поддерживает специфические механизмы RSVP для быстрого уведомления об отказах.Отметим также некоторые ключевые различия между MPLS-TE и GMPLS:
На интерфейсах TDM, LSC и FSC полоса для LSP может выделяться только дискретными блоками.
Предполагается многократное снижение числа меток на каналах TDM, LSC или FSC по сравнению с PSC и L2SC, поскольку в первом случае метки являются «физическими», а во втором — логическими.

2. Модель адресации и маршрутизации

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

Поскольку уровни управления и данных в GMPLS разделены, соседи по уровню управления (например, определенные с помощью IGP) могут не быть соседями на уровне данных. Следовательно, нужны механизмы типа LMP для организации TE-каналов с соседними узлами.

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

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

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

В модели с перекрытием каждый отдельный уровень, отличный от PSC, может быть виден, как набор автономных систем (AS), соединенных между собой произвольным способом. Подобно традиционной маршрутизации IP, каждая AS управляется одним административным органом. Например, AS может быть сеть SONET/SDH данного оператора. Набор соединенных между собой AS может быть виден как «сеть сетей» SONET/SDH.

Обмен маршрутной информацией между AS может осуществляться с помощью протокола междоменной маршрутизации типа BGP-4. В таких случаях обычно имеется множество проверенных схем маршрутизации на основе правил, которые BGP обеспечивает в контексте, отличном от PSC. Исключения для BGP-TE в контексте уровней, отличных от PSC, требуют дальнейшего изучения.

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

Маршрутный домен состоит из поддерживающих GMPLS узлов (т. е., сетевых устройств с поддержкой функций GMPLS). Эти узлы могут быть краевыми (т. е., хосты, входные или выходные LSR) или внутренними LSR. Примером хоста, не являющегося PSC, может служить терминальный мультиплексор (TM²¹) SONET/SDH. Другим примером является интерфейсная плата SONET/SDH в маршрутизаторе IP или коммутаторе ATM.

Отметим, что построение трафика внутри домена требует использования протоколов динамической маршрутизации по состоянию каналов типа OSPF или IS-IS.

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

2.1. Адресация уровней PSC и не-PSC

Факт использования адресов IPv4 и/или IPv6 не означает, что эти адреса должны выделяться из публичного адресного пространства IPv4 и/или /or IPv6, используемого для Internet. Если не требуется обмен с другими операторами, могут применяться приватные адреса IP, в противном случае нужны публичные адреса IP. Естественно, при использовании одноранговой модели два уровня могут разделять одно адресное пространство. И, наконец, каналы TE могут быть безадресными (unnumbered), т. е., не иметь адресов IP совсем (в случаях нехватки адресов IP или слишком высоких издержек на поддержку адресации).

Отметим, что использование публичных адресов IPv4 и/или IPv6 для уровней, отличных от PSC, может давать преимущества, если предполагается применение одноранговой модели с уровнем IP.

Если рассмотреть повышение уровня масштабируемости, предлагаемое в следующем параграфе, каждого из адресных пространств IPv4 (32 бита) и IPv6 (128 битов) более, чем достаточно для размещения любого уровня, отличного от =PSC. Резонно предположить, что число устройств, не относящихся к PSC (например, узлы SONET/SDH), будет гораздо меньше числа существующих сегодня хостов и маршрутизаторов IP.

2.2. Повышение уровня масштабируемости GMPLS

Уровни TDM, LSC и FSC вводят новые ограничения на модели адресации и маршрутизации IP, поскольку на этих уровнях пара узлов может соединяться через несколько сотен параллельных физических каналов (например, длин волн). Новое поколение систем DWDM будет поддерживать несколько сот длин волн в одном волокне.

Связывание адреса IP с каждым концом каждого физического канала, представление каждого канала, как отдельной смежности по маршрутизации, а также анонсирование и поддержка состояния каждого физического канала становятся непрактичными. По этой причине GMPLS расширяет модели адресации и маршрутизации MPLS.

Для повышения уровня масштабируемости адресации и маршрутизации могут использоваться два дополнительных механизма — безадресные каналы и связывание каналов. Эти механизмы могут использоваться одновременно. Для применения этих механизмов требуется расширение протоколов сигнализации (RSVP-TE и CR-LDP) и маршрутизации (OSPF-TE и IS-IS-TE).

2.3. Расширения TE для протоколов маршрутизации IP

Традиционно канал TE анонсируется, как дополнение в «обычному» каналу OSPF или IS-IS, т. е., смежность «поднимает» канал. Когда канал поднимается, анонсируются обычные IGP-свойства (прежде всего, метрика SPF) этого канала и свойства TE.

GMPLS вносит три дополнительных требования:

во-первых, каналы, не относящиеся к PSC, могут, тем не менее иметь свойства TE, однако OSPF-смежность не может быть напрямую «поднята» на таких каналах;
во-вторых, LSP могут анонсироваться протоколам маршрутизации, как TE-каналы «точка-точка» (т. е., как FA-смежность²²); таким образом, анонсируемый TE-канал не обязательно связывает двух прямых соседей OSPF;
в-третьих, множество каналов может анонсироваться, как один канал TE (например, с целью повышения уровня масштабируемости), в результате чего утрачивается взаимно-однозначное соответствие между обычной смежностью и каналами TE.

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

Важное TE-свойство канала TE связано с учетом полосы пропускания для этого канала. GMPLS будет определять различные правила учета для разных уровней, отличных от PSC. Однако базовыми атрибутами полосы пропускания определяемыми в маршрутных расширениях TE и GMPLS, являются такие параметры, как нерезервированная полоса (unreserved bandwidth), максимальная резервируемая полоса (maximum reservable bandwidth) и максимальная полоса LSP.

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

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

Наличие канала TE между парой LSR не предполагает существования отношений смежности IGP между этими LSR. Канал TE должен также иметь те или иные средства, с помощью которых анонсирующий LSR может узнать о жизнеспособности канала (например, сообщения LMP Hello). Когда LSR знает, что TE-канал активен и может определить TE-свойства канала TE, этот LSR может анонсировать этот канал своим GMPLS-соседям по OSPF или IS-IS, используя объекты TE (TLV). Будем называть интерфейсы, через которые организуются расширенные с помощью GMPLS отношения смежности OSPF или IS-IS, «каналами управления».

3. Безадресные каналы

Безадресными каналами (интерфейсами) называют каналы (интерфейсы), не имеющие адресов IP. Безадресные каналы могут включаться в сигнализацию MPLS TE, а (TE) информация о таких каналах может передаваться в расширения IGP TE (IS-IS-TE и OSPF-TE).

Возможность задания безадресных каналов в сигнализации MPLS TE требует расширения RSVP-TE [RFC3477] и CR-LDP [RFC3480]. Сигнализация MPLS-TE не обеспечивает поддержку безадресных каналов, поскольку она не может показать безадресный канал в своих объектах/TLV Explicit Route и Record Route (такого TLV нет для CR-LDP). GMPLS определяет простые расширения для индикации безадресных каналов в эти два объекта /TLV с использованием нового субобъекта/суб-TLV (Unnumbered Interface ID).Поскольку безадресные каналы не идентифицируются адресом IP, для целей MPLS TE каждый конец канала должен получить некий другой идентификатор (локальный для LSR, к которому относится канал). LSR на безадресных каналах обмениваются между собой идентификаторами, которые каждый присвоил каналу. Обмен идентификаторами может быть выполнен с помощью конфигурационных параметров, протокола типа LMP ([LMP]), RSVP-TE/CR-LDP (особенно для описанного ниже случая, где канал образует смежность по пересылке) или расширение IS-IS/OSPF ([ISIS-TE-GMPLS], [OSPF-TE-GMPLS]).Рассмотрим (безадресный) канал между LSR A и B. LSR A выбирает идентификатор для канала и так же поступает LSR B. С точки зрения A идентификатор, который A выделил для канала, является «локальным идентификатором канала» (или просто локальным идентификатором), а идентификатор, присвоенный этому каналу маршрутизатором B, будет «удаленным идентификатором канала» (удаленным идентификатором). С точки зрения B локальный и удаленный идентификаторы поменяются местами.Новый субобъект/суб-TLV Unnumbered Interface ID для объекта/TLV ER содержит значение Router ID маршрутизатора LSR на восходящей стороне безадресного канала и локальный по отношению к восходящему LSR идентификатор канала.Новый субобъект Unnumbered Interface ID для объекта RR содержит локальный идентификатор с точки зрения добавившего объект RR маршрутизатора LSR.
Возможность передавать (TE) информацию о безадресных каналах в расширения IGP TE требует новых суб-TLV для расширенного IS Reachability TLV, определенного в IS-IS-TE, и TE LSA («темный» LSA), определенного в OSPF-TE. Определены два суб-TLV — Link Local Identifier и Link Remote Identifier .

3.1. Безадресная смежность по пересылке

Если LSR, на котором начинается LSP, анонсирует этот LSP как безадресную FA в IS-IS/OSPF или LSR использует эту FA, как безадресную компоненту связки каналов, LSR должен выделить для этой FA идентификатор интерфейса. Если LSP является двухсторонним, другой конец пути делает то же самое и выделяет идентификатор интерфейса для обратной FA.

Сигнализация расширяется для передачи Interface ID смежности FA в новом объекте/TLV LSP Tunnel Interface ID. Этот объект/TLV содержит значение Router ID (маршрутизатора LSR, генерирующего объект) и Interface ID. В сообщении Path/REQUEST это поле называется Forward Interface ID, а в сообщении Resv/MAPPING — Reverse Interface ID.

4. Связывание каналов

Концепция связывания каналов весьма важна для некоторых сетей, использующих уровень управления GMPLS, как определено в документе [BUNDLE]. Типичным примером являются оптические многосвязные (optical meshed) сети, где смежные оптические кросс-коннекторы (LSR) соединяются между собой несколькими сотнями «параллельных» длин волн. Рассмотрим для такой сети применение протоколов маршрутизации по состоянию каналов (типа OSPF или IS-IS) с подходящими расширениями для обнаружения ресурсов и динамического расчета маршрутов. Каждая длина волны в такой ситуации должна анонсироваться отдельно, если не используется связывание каналов.

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

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

Целью связывания каналов является повышение уровня масштабируемости за счет снижения объема информации, обрабатываемой OSPF и/или IS-IS. Это снижение обеспечивается за счет агрегирования/абстрагирования данных. Как и в других приложениях агрегирования/абстрагирования в результате некоторая часть информации теряется. Для ограничения размера потерь требуется ограничить типы данных, которые можно агрегировать/абстрагировать.

4.1. Ограничения на связывание

При связывании каналов возникают некоторые ограничения, которые перечислены здесь. Все компоненты связки должны начинаться и заканчиваться на одной паре маршрутизаторов LSR; все компоненты должны иметь некий набор общих характеристик или свойств, определенных в [OSPF-TE] и [ISIS-TE], а именно:

— тип канала (например, «точка-точка» или множественный доступ);

— метрика TE (административная стоимость);

— набор классов ресурсов на каждом конце канала (например, цвета).

Отметим, что FA может также быть компонентой связки. Фактически, связка может состоять из смеси физических каналов «точка-точка» и смежностей FA, но все они должны иметь общий набор свойств.

4.2. Вопросы маршрутизации для связок

Связка каналов представляет собой просто другой тип канала TE, как определено в документе [GMPLS-ROUTING]. Жизнеспособность связки определяется жизнеспособностью каждой из ее компонент. Связка сохраняется, пока работает хотя бы одна из ее компонент. Жизнеспособность компоненты может быть определена несколькими способами — сообщения Hello узлов IS-IS или OSPF через компоненту, RSVP Hello (hop local), LMP Hello (link local), а также индикация уровней 1 или 2.

Отметим, что (согласно спецификации RSVP-TE [RFC3209]) механизм RSVP Hello предназначен для использования в тех случаях, когда недоступны уведомления об отказах на канальном уровне, а безадресные каналы не используются или в случаях, когда механизмов канального уровня недостаточно для своевременного обнаружения отказавшего узла.

После того, как рабочее состояние связки определено, она может быть анонсирована, как канал TE с лавинной рассылкой информации TE. Если приветствия IS-IS/OSPF передаются через каналы-компоненты, то лавинная рассылки IS-IS/OSPF может быть ограничена одной из компонент канала.

Отметим, что анонсирование связки TE между парой LSR не подразумевает наличия IGP-смежности между этими LSR по данному каналу. Фактически, в некоторых случаях канал TE между парой LSR может анонсироваться даже при полном отсутствии смежности IGP между LSR (например, когда канал TE представляет собой FA).

Формирование связки включает агрегирование идентичных параметров TE каждой компоненты для создания агрегатных параметров TE. Канал TE, как определено в [GMPLS-ROUTING], имеет множество параметров и для каждого из параметров должны быть определены адекватные правила агрегирования.

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

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

4.3. Вопросы сигнализации

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

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

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

4.3.1. Неявная индикация

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

4.3.2. Явная индикация через идентификатор интерфейса с адресом

Этот механизм требует для компоненты связки наличия уникального удаленного адреса IP. Восходящий узел показывает выбор компоненты путем включения нового объекта IF_ID RSVP_HOP или IF_ID TLV, содержащего адрес IPv4 или IPv6 в сообщении Path/Label Request (см. [RFC3473] и [RFC3472], соответственно). Для двухсторонних LSP восходящий узел указывает компоненту связки в каждом из направлений.

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

4.3.3. Явная индикация через идентификатор безадресного интерфейса

В этом варианте каждая безадресная компонента связки получает уникальный идентификатор интерфейса (32 бита). Восходящий узел показывает выбор компоненты путем включения нового объекта IF_ID RSVP_HOP или IF_ID TLV в сообщение Path/Label Request (см. [RFC3473] и [RFC3472], соответственно).

Этот объект/TLV передает идентификатор интерфейса выбранной компоненты в нисходящем направлении для одностороннего LSP и, в дополнение, — идентификатор интерфейса выбранной компоненты двухстороннего LSP в восходящем направлении.

Два LSR на каждом конце связки обмениваются идентификаторами интерфейсов. Обмен может осуществляться путем задания конфигурационных параметров, с помощью протокола типа LMP (предпочтительно), с помощью RSVP-TE/CR-LDP (особенно для тех случаев, когда канал-компонента представляет собой FA), а также с помощью расширений IS-IS или OSPF.

4.4. Безадресные связки каналов

Связка каналов, как таковая, может иметь адрес или быть безадресной, независимо от наличия адресов у компонент связки. Наличие адреса у связки оказывает влияние на анонсирование канала в IS-IS/OSPF и формат LSP ERO, которые будут проходить через связку. Идентификаторы интерфейсов для всех исходящих безадресных каналов (каналов-компонент, FA или связок) данного LSR должны быть уникальными в контексте данного LSR.

4.5. Формирование связок каналов

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

Например, первым свойством для связывания компонент может быть корреляция по ISC²³ [GMPLS-ROUTING], вторым — представление (Encoding) [GMPLS-ROUTING], третьим, установленный администратором «вес» (Administrative Weight — стоимость), четвертым — класс ресурса (Resource Class) и заключительным — метрика типа SRLG²⁴. При маршрутизации дополнительного пути для защиты общий принцип заключается в том, что дополнительный путь не маршрутизируется через какие-либо каналы, относящиеся к той же группе SRLG, в которую входит какая-либо из компонент. Таким образом, правило заключается в том, чтобы группировать каналы с одинаковым набором SRLG.

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

5. Связь с UNI

Интерфейс между краевым узлом GMPLS и маршрутизатором GMPLS LSR со стороны сети можно называть интерфейсом UNI²⁵, тогда как интерфейс между двумя узлами LSR со стороны сети — NNI²⁶.

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

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

Модель GMPLS ставит задачей построение непротиворечивой модели для сегодняшнего дня, рассматривая одновременно оба интерфейса UNI и NNI [GMPLS-OVERLAY]. По этой причине поначалу некоторые специфические вопросы UNI игнорируются. GMPLS будет развиваться для поддержки частностей на уровне UNI другими комитетами по стандартизации (см. дальше).

5.1. Связь с OIF UNI

Этот параграф включен лишь для упоминания о работе OIF, связанной с GMPLS. Текущая спецификация OIF UNI [OIF-UNI] определяет интерфейс между клиентским оборудованием SONET/SDH и сетью SONET/SDH, каждый из которых находится под своим административным управлением. Этот интерфейс предназначен для модели с перекрытием. OIF UNI определяет для UNI дополнительные механизмы, действующие на базе GMPLS.

Например, процедура обнаружения сервиса в OIF является предшественником процедур обнаружения сервиса в UNI. Обнаружение сервиса позволяет клиенту определить статические параметры соединения с сетью, включая сигнальный протокол UNI, тип конкатенации, уровень прозрачности, а также «тип разнообразия» (узел, канал, SRLG), поддерживаемого сетью.

Поскольку существующий интерфейс OIF UNI не включает фотонные сети, G.709 Digital Wrapper и т. п. с точки зрения архитектуры GMPLS относятся к UNI.

5.2. Достижимость через UNI

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

Краевой узел (хост или LSR) может более или менее глубоко быть вовлечен в маршрутизацию GMPLS. На UNI могут поддерживаться 4 разных модели маршрутизации — на основе конфигурационных параметров, на основе частичного партнерства, на основе безучастного прослушивания²⁷ и на основе полного партнерства.

Маршрутизация на основе конфигурационных параметров. Эта модель требует ручной или автоматической настройки конфигурации краевого узла с указанием списка соседних LSR, отсортированного по предпочтительности. Для автоматической настройки конфигурации может использоваться, например, протокол DHCP. Обмена маршрутной информацией на уровне UNI не происходит, за возможным исключением передачи упорядоченного списка LSR. Указанный список является единственной маршрутной информацией, используемой краевым узлом. Краевой узел по умолчанию отправляет запрос на LSP предпочтительному маршрутизатору LSR. Этот LSR может возвращать сообщения ICMP redirect для перенаправления некоторых запросов LSP на другой LSR, соединенный с краевым узлом. GMPLS не препятствует использованию этой модели.
Частичное партнерство. Через UNI осуществляется ограниченный обмен маршрутной информацией (главным образом, о доступности) с использованием неких расширений на сигнальном уровне. Информация о доступности, передаваемая на уровне UNI, может использоваться для инициирования принятия краевым узлом конкретного решения о маршрутизации через сеть. GMPLS в настоящее время не имеет возможности поддерживать эту модель.
Безучастное прослушивание. Краевой узел может прослушивать протоколы маршрутизации и принимать решения на основе полученной информации. Краевой узел получает полные маршрутные данные, включая расширения для построения трафика. LSR следует прозрачно пересылать все маршрутные PDU краевому узлу. Краевой узел в этом случае может рассчитать полностью явный маршрут, принимая во внимание маршрутные данные по всему пути. GMPLS не препятствует использованию этой модели.
Полное партнерство. В дополнение к прослушиванию маршрутной информации краевой узел принимает участие в ее распространении, организуя отношения смежности с соседями и анонсируя LSA. Это полезно только в тех ситуациях, когда обеспечиваются преимущества для краевого узла за счет анонсирования своей информации по построению трафика. GMPLS не препятствует использованию этой модели.

6. Управление каналом

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

Управление каналом представляет собой набор процедур, организуемых между смежными узлами, которые обеспечивают локальный сервис типа управления каналом управления, проверки связности каналов, сопосталения свойств каналов и контроля отказов. Протокол LMP²⁸ [LMP] был определен специально для выполнения этих операций. Разработка LMP была начата в контексте GMPLS, но его основные свойства можно применять и в ином контексте.

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

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

6.1. Канал управления и управление им

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

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

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

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

LMP не задает механизм доставки сигналов в канале управления, однако предполагается, что сообщения доставляются по каналу управления на базе протокола IP. Более того, в результате использования IP для доставки сообщений протокол канального уровня не рассматривается в LMP. Для каждого направления управляющего канала выделяется 32-битовый (отличный от 0) целочисленный идентификатор CCId²⁹.

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

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

Протокол Hello включает две фазы — согласование и сохранение (keep-alive). Первая фаза позволяет согласовать некоторые базовые параметры Hello (например, частоту передачи приветствий). Вторая фаза включает облегченный и быстрый двухсторонний обмен сообщениями Hello.

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

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

6.2. Корреляция свойств канала

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

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

6.3. Проверка связности

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

Эту процедуру следует выполнять при организации канала передачи данных и периодически повторять для всех невыделенных (свободных) каналов передачи данных.

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

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

6.4. Контроль отказов

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

Отметим, что локализация отказов может также использоваться для поддержки некоторых (локальных) механизмов защиты/восстановления.

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

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

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

6.5. LMP для оптических линейных систем DWDM

В полностью оптических средах LMP фокусируется на обмене данными между партнерами (например,OXC-OXC). OLS³⁰ известен очень большой объем информации о канале между парой оптических кросс-коннекторов OXC. Предоставление этой информации уровню управления может повысить уровень эффективности использования сети за счет снижения выполняемой вручную настройки, а также значительно улучшить детектирование и устранение отказов.

LMP-WDM [LMP-WDM] определяет расширения LMP для использования между OXC и OLS. Эти расширения предназначены для выполнения требований к оптическим канальным интерфейсам, описанным в [OLI-REQ].

Детектирование отказов особенно важно для случаев, когда в сети применяются только фотонные коммутаторы (PXC). После организации соединения PXC имеет весьма ограниченные возможности контроля состояния этого соединения. Хотя устройства PXC полностью оптические, обычно на длинных линиях используются системы OLS с электрическим завершением и оптической регенерацией сигналов. Это обеспечивает возможность мониторинга состояния каналов между PXC. В таких случаях в OLS можно использовать расширения LMP-WDM с передачей информации в PXC.

В дополнение к известной OLS информации о канале, которая передается через LMP-WDM, некоторая информация от OXC может также передаваться в OLS с помощью LMP-WDM. Эта информация полезна для работы с сигналами тревоги и мониторинга каналов (например, мониторинг трассы). Работа с сигналами тревоги важна, поскольку административное состояние соединения, известное OXC (например, информация, полученная из объекта Admin Status сигнализации GMPLS [RFC3471]), может использоваться для устранения фиктивных сигналов тревоги. Например, OXC может знать, что соединение работает (up), отключено (down), тестируется или будет удалено (deletion-in-progress). OXC может использовать эту информацию для подавления сигналов тревоги от OLS, когда соединение находится в состоянии down, тестируется или удаляется.

Важно отметить, что OXC может быть партнером одной или нескольких систем OLS, а OLS может быть партнером одного или нескольких кросс-коннекторов OXC. Хотя существует много схожего в сессиях OXC-OXC LMP и OXC-OLS LMP (особенно в части управления каналом управления и проверки связности), имеются также некоторые различия. Эти различия обусловлены в первую очередь природой каналов OXC-OLS и целями организации сессий OXC-OLS LMP. Каналы OXC-OXC могут использоваться в качестве основы для сигнализации GMPLS и маршрутизации на оптическом уровне. Обмен информацией через сеансы LMP-WDM служит для дополнения сведений о каналах между OXC.

Для того, чтобы информация, передаваемая через сессии OXC-OLS LMP, могла использоваться в сессиях OXC-OXC, эта информация должна координироваться OXC. Однако сеансы OXC-OXC и OXC-OLS в LMP работают независимо и должны управляться раздельно. Критически важным требованием для сессий OXC-OLS LMP является способность OLS сделать канал данных прозрачным, когда не используется процедура проверки канала. Это обусловлено тем, что один и тот же канал данных может проверяться между OXC-OLS и между OXC-OXC. Процедура проверки в LMP используется для координации процедуры Test (и, следовательно, прозрачности/непрозрачности каналов данных). Для поддержки независимости сессий в LMP должна обеспечиваться возможность их активизации в произвольном порядке. В частности, это должно быть возможно для сессий OXC-OXC LMP, которые работают без сессии OXC-OLS LMP и наоборот.

7. Обобщенная сигнализация

Сигнализация GMPLS расширяет некоторые базовые функции сигнализации RSVP-TE и CR-LDP, а в некоторых случаях добавляет функциональность. Эти изменения и дополнения влияют на базовые свойства LSP — запрос меток и обмен информацией о метках, однонаправленная природа LSP, распространение информации об ошибках, данные, распространяемые для синхронизации входа и выхода.

Спецификация ядра сигнальных функций GMPLS состоит из трех частей:

описание сигнальных функций [RFC3471];
расширения RSVP-TE [RFC3473];
расширения CR-LDP [RFC3472].

В дополнение к этому имеется два документа, связанных с конкретными технологиями:

расширения GMPLS для управления SONET/SDH [RFC3946];
расширения GMPLS для управления G.709 [GMPLS-G709].

Для GMPLS применимы профили MPLS, выраженные в терминах свойств MPLS [RFC3031]:

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

Сигнализация GMPLS определяет новые «строительные блоки» в дополнение к MPLS-TE:

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

Эти блоки более детально описаны ниже. Полную их спецификацию можно найти в соответствующих документах.

Отметим, что технология GMPLS является весьма общей и имеет множество опций. Только блоки 1, 2 и 10 являются обязательными и только в конкретном формате, который требуется. Блоки 6 и 9 обычно следует реализовать. Блоки 3, 4, 5, 7, 8, 11 и 12 являются опциональными.

Типичная коммутируемая сеть SONET/SDH будет включать блоки 1, 2 (метки SONET/SDH ), 6, 9, 10 и 11. Блоки 7 и 8 являются опциональными, поскольку защита может быть обеспечена с помощью служебных байтов SONET/SDH.

Типичная сеть с коммутацией по длинам волн будет реализовать блоки 1, 2 (базовый формат), 4, 5, 6, 7, 8, 9 и 11. Блок 3 требуется только для частного случая коммутации диапазонов длин волн.

Типичная сеть с коммутацией волокон будет реализовать блоки 1, 2 (базовый формат), 6, 7, 8, 9 и 11.

В типичной сети MPLS-IP перечисленные блоки не будут реализованы, поскольку отсутствие блока 1 будет указывать традиционную сеть MPLS-IP. Отметим, однако, что блоки 1 и 8 могут использоваться для сигнализации MPLS-IP. В этом случае сеть MPLS-IP может получить дополнительную защиту каналов (не поддерживается в CR-LDP, частично поддерживается в RSVP-TE). Блок 2 является обычной меткой MPLS и нового формата не требуется.

GMPLS не задает профилей для реализаций RSVP-TE и CR-LDP с целью поддержки GMPLS за исключением того, что напрямую связано с процедурами GMPLS. Выбор необязательных процедур и элементов RSVP-TE и CR-LDP остается за разработчиком. Некоторые опциональные элементы MPLS-TE могут быть полезны для уровней TDM, LSC и FSC (например, приоритеты организации и удержания, наследуемые из MPLS-TE).

7.1. Как запрашивать LSP (обзор)

TDM, LSC или FSC LSP организуются путем передачи сообщения PATH/Label Request в нисходящем направлении к адресату. Это сообщение содержит обобщенный запрос метки (Generalized Label Request) с типом LSP (т. е., определяется уровнем) и типом данных. В сообщение обычно добавляется объект ERO³¹, но он может быть добавлен и/или заполнен первым или используемым по умолчанию LSR.

Требуемая полоса кодируется в объекте RSVP-TE SENDER_TSPEC или CR-LDP Traffic Parameters TLV. В этих параметрах трафика указываются специфические параметры используемой технологии (такие, как тип сигнала, конкатенация и/или прозрачность для SONET/SDH LSP). Для некоторых технологий может просто задаваться требуемая полоса (значение с плавающей точкой).

Локальная защита для канала может быть запрошена с помощью объекта/TLV Protection Information. Сквозная защита LSP рассматривается ниже в параграфе 11. Защита и восстановление LSP.

Если LSP является двухсторонним, в сообщениях Path/Label Request указывается также метка Upstream. Эта метка будет использоваться в восходящем направлении.

Кроме того, в сообщение могут включаться метки Suggested, Label Set и Waveband. Прочие операции определены в MPLS-TE.

Нисходящий узел будет передавать обратно сообщение Resv/Label Mapping, включающее объект/TLV Generalized Label, который может содержать несколько меток Generalized Label. Например, при запросе SONET/SDH с конкатенацией может возвращаться несколько меток.

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

В случае непрерывной конкатенации SONET/SDH любого типа возвращается единственная метка. Эта метка является нижним сигналом из непрерывной конкатенации сигналов (порядок определен в [RFC3946]).

В случае «мультипликации³²» SONET/SDH возвращается явно упорядоченный список всех сигналов, входящих в LSP.

7.2. Обобщенный запрос метки

Generalized Label Request представляет собой новый объект/TLV, который добавляется в сообщение RSVP-TE Path взамен обычного Label Request или в сообщение CR-LDP Request в дополнение к имеющимся TLV. В сообщение может включаться только одна метка, поэтому можно запрашивать по одному LSP на сигнальное сообщение.

Generalized Label Request обеспечивает три основных характеристики (параметра) требуемые для поддержки запрашиваемого LSP — Encoding Type (тип представления), Switching Type (тип коммутации, которая должна применяться) и тип данных LSP, называемый G-PID³³.

LSP Encoding Type показывает тип представления, который будет использоваться для данных, связанных с LSP, т. е., тип технологии (например, SDH, SONET, Ethernet, ANSI PDH и т. п.). Это значение показывает природу LSP, а не природу каналов, через которые проходит LSP. Тип представления указывается поэтапно на каждом узле.

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

Узлы должны проверять, что тип, указанный значением Switching Type, реально поддерживается на соответствующем входном интерфейсе и при отсутствии такой поддержки должно генерироваться уведомление с индикацией Routing problem/Switching Type (проблемы при маршрутизации — тип коммутации).

Тип данных LSP (G-PID) идентифицирует данные, передаваемые через LSP, т. е., показывает идентификатор клиентского уровня для этого LSP. Для некоторых технологий это значение также показывает отображение, используемое клиентским уровнем (например, отображение байтов синхронизации E1). Значение должно интерпретироваться в соответствии с типом представления LSP и используется узлами на конечных точках (в некоторых случаях на предпоследнем узле) LSP для определения, какому клиентскому уровню адресован запрос.

Прочие параметры, относящиеся к конкретной технологии, не передаются в сообщениях Generalized Label Request, и включаются в связанные с технологией параметры трафика, рассматриваемые ниже. В настоящее время определены два набора параметров трафика — один для SONET/SDH, а второй для G.709.

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

7.3. Параметры трафика SONET/SDH

Параметры GMPLS для трафика SONET/SDH [RFC3946] используют развитые возможности технологий SONET [ANSI-T1.105] и SDH [ITUT-G.707].

Первый параметр задает тип элементарного сигнала SONET/SDH для включения в запрашиваемый LSP (например, VC-11, VT6, VC-4, STS-3c и т. п.). К элементарному сигналу могут быть применены некоторые преобразования для создания окончательного сигнала, который реально запрашивается для LSP.

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

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

Для RSVP-TE параметры трафика SONET/SDH передаются в новом SENDER_TSPEC и FLOWSPEC, которые имеют одинаковый формат. Значение Adspec не связывается с SENDER_TSPEC — оно просто опускается или используется принятое по умолчанию значение. Содержимое объекта FLOWSPEC, полученного в сообщении Resv, должно быть идентично содержимому SENDER_TSPEC в соответствующем сообщении Path. Иными словами, получателю обычно не разрешается менять значения параметров трафика. Однако возможен некоторый уровень согласования параметров, как описано в [RFC3946].

Для CR-LDP параметры трафика SONET/SDH просто передаются в новом TLV.

Отметим, что общее рассмотрение SONET/SDH и GMPLS приведено в работе [SONET-SDH-GMPLS-FRM].

7.4. Параметры трафика G.709

Говоря простым языком, сети на основе стандарта [ITUT-G.709] делятся на два основных уровня — оптический (длины волн) и цифровой. Эти два уровня делятся на подуровни и коммутация происходит на двух конкретных подуровнях — оптический уровень OCh (оптический канал) и электрический уровень ODU (блок данных оптического канала). Для обозначения ODU с разной полосой используется нотация ODUk.

Параметры трафика G.709 в GMPLS [GMPLS-G709] используют широкое возможности сетей ITU-T G.709.

Первый параметр задает тип элементарного сигнала G.709 для включения в запрашиваемый LSP (например, ODU1, OCh 40 Гбит/с и т. п.). К элементарному сигналу могут быть применены некоторые преобразования для создания окончательного сигнала, который реально запрашивается для LSP.

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

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

Дополнительные параметры трафика мультиплексирования ODUk позволяют указать отображение ODUk (ODUj на ODUk) для запросов LSP с использованием мультиплексов ODUk. G.709 поддерживает мультиплексирование типа ODUj в ODUk (k > j) и ODU1 с ODU2 в ODU3.

Для RSVP-TE параметры трафика G.709 передаются в новом SENDER_TSPEC и FLOWSPEC, которые имеют одинаковый формат. Значение Adspec не связывается с SENDER_TSPEC — оно просто опускается или используется принятое по умолчанию значение. Содержимое объекта FLOWSPEC, полученного в сообщении Resv, должно быть идентично содержимому SENDER_TSPEC в соответствующем сообщении Path. Иными словами, получателю обычно не разрешается менять значения параметров трафика.

Для CR-LDP параметры трафика G.709 просто передаются в новом TLV.

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

Для некоторых технологий, которые (пока) не имеют специфических параметров трафика, просто требуется представление полосы пропускания, передаваемое в базовом формате. Значение полосы передается в виде 32-битового числа с плавающей запятой в формате IEEE (единицей измерения является байт/с). Способ передачи значения зависит от протокола. Для LSP, не использующих пакеты, рекомендуется определять набор дискретных значений для идентификации полосы пропускания LSP.

Следует отметить, что описанное представление полосы не применяется в сетях SONET/SDH и G.709, для которых параметры трафика полностью определяют запрашиваемый сигнал SONET/SDH или G.709.

Полоса задается в поле Peak Data Rate (пиковая скорость передачи данных) объектов Int-Serv для RSVP-TE в объектах SENDER_TSPEC и FLOWSPEC, а также в полях Peak Data Rate и Committed Data Rate (контрактная скорость передачи данных) CR-LDP Traffic Parameters TLV.

7.6. Обобщенные метки

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

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

SDH и SONET определяют свою структуру мультиплексирования. Эта структура будет использоваться в качестве дерева имен для создания уникальных меток. Такие метки будут уникально идентифицировать точную позицию (временные интервалы) сигнала в мультиплексной структуре. Поскольку структура мультиплексов SONET может рассматриваться, как подмножество структуры SDH, для обеих технологий используется один формат меток. Аналогичные концепции применяются и при построении меток для уровней ODU в G.709.

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

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

7.7. Переключение диапазона длин волн

Коммутация оптических диапазонов является частным случаем коммутации длин волн. Оптический диапазон представляет собой «непрерывное» множество длин волн, которые совместно могут быть скоммутированы в другой диапазон. Для оптимизации процесса такое поведение может быть желательным для фотонных кросс-коннекторов. Это позволяет снизить дисторсию для отдельных длин волн и может обеспечить более тонкое разделение отдельных длин волн. Для поддержки этого специального случая определена метка Waveband.

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

В контексте коммутации диапазонов обобщенные метки служат для индикации диапазона длин волн и включают три поля — идентификатор длины волны (waveband ID), начальная метка (Start Label) и конечная метка (End Label). Начальная и конечная метки являются идентификаторами каналов, показывающие, с точки зрения отправителя, наименьшее и наибольшее значение длины волны диапазона.

7.8. Предложение меток восходящим узлом

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

7.9. Ограничение меток восходящим узлом

Восходящий узел может (опционально) ограничивать выбор меток от нисходящего узла неким набором приемлемых меток. Реализация таких ограничений обеспечивается включением списков и/или диапазонов включенных (подходящих) или исключенный (неприемлемых) меток в Label Set. Если ограничений не задано, могут использоваться все метки из диапазона допустимых значений. Существует по крайней мере 4 ситуации, когда ограничение меток полезно в «оптическом» домене.

Случай 1: оконечное оборудование способно принимать и передавать сигналы лишь в малом наборе длин волн/диапазонов.

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

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

Случай 4: две стороны канала поддерживают разные наборы длин волн.

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

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

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

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

Обычно для организации двухстороннего LSP при использовании RSVP-TE [RFC3209] или CR-LDP [RFC3212] требуется независимая организация пары односторонних путей. Эта модель имеет несколько недостатков.

Задержка при организации двухстороннего LSP равна периоду кругового обхода для сигнализации плюс задержка сигнализации при транзите «инициатор-завершение». Это не только увеличивает задержку при организации LSP, но и увеличивает задержку обнаружения неудачи при организации LSP на удвоенное время транзита «инициатор-завершение». Такие задержки весьма существенны для LSP, организуемых в целях восстановления.
Объем передаваемой служебной информации удваивается по сравнению с односторонним LSP. Это обусловлено тем, что должны генерироваться раздельные управляющие сообщения (например, Path и Resv) для обоих сегментов двухстороннего LSP.
Поскольку ресурсы организуются в раздельных сегментах, выбор маршрута усложняется. Потенциально также возникает дополнительная конкуренция при выделении ресурсов, которая может снижать вероятность успешной организации двухстороннего соединения.
Более сложно обеспечить понятный интерфейс для оборудования SONET/SDH, которое может полагаться на двухсторонние поэтапные пути в целях защитной коммутации. Отметим, что существующее оборудование SONET/SDH передает управляющую информацию по тому же каналу, где передаются данные.
Двухсторонние оптические LSP (или световые пути) представляются естественной потребностью для многих сервис-провайдеров оптических сетей.

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

Для двухсторонних LSP должны выделяться две метки. Организация двухстороннего LSP инициируется наличием метки Upstream Label в соответствующем сигнальном сообщении.

7.11. Разрешение конфликтов для двухсторонних LSP

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

7.12. Быстрое уведомление об отказах

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

Приемлемый набор меток Label Set для уведомления об ошибке Label Error.Существуют ситуации в традиционной MPLS и GMPLS, которые приводят к выдаче сообщений об ошибке с индикацией недопустимого значения метки (Unacceptable label value). При возникновении таких ошибок узлу полезно генерировать сообщение об ошибке для индикации неприемлемой метки. Для таких случаев в GMPLS введена возможность передачи такого типа информации с помощью Acceptable Label Set. Набор Acceptable Label Set передается в подходящих сообщениях об ошибках соответствующего протокола. Формат Acceptable Label Set идентичен формату Label Set.
Ускоренное уведомление.Расширения RSVP-TE обеспечивают возможность ускоренного уведомления определенных узлов об отказах и других ошибках. Для CR-LDP подобных механизмов в настоящее время не определено. Первое расширение идентифицирует условия, при которых передаются уведомления о событиях. Второе расширение обеспечивает ускоренные уведомления о событиях с помощью сообщений Notify. Эти расширения могут использоваться механизмами быстрого восстановления. Уведомления могут запрашиваться как для восходящего, так и для нисходящего направления.Сообщение Notify обеспечивает обобщенный механизм уведомления, который отличается от определенных в настоящее время сообщений об ошибках тем, что уведомления могут быть «нацелены» на узел, отличный от непосредственного соседа в восходящем или нисходящем направлении. Сообщение Notify не является заменой существующим сообщениям об ошибках. Сообщение Notify может передаваться (a) обычным способом, когда не являющиеся целью узлы просто пересылают сообщение Notify целевому узлу, подобно обработке ResvConf в [RFC2205], или (b) инкапсулироваться в новый заголовок IP, где в качестве получателя указан целевой адрес IP.
Быстрое устранение промежуточных состояний.
Специфическая оптимизация RSVP в некоторых случаях позволяет быстрее устранять промежуточные состояния. Это расширение полезно при работе со специфическими механизмами RSVP.

7.13. Защита канала

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

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

В настоящее время определены флаги для шести типов защиты, которые могут применяться по отдельности или в комбинации — enhanced (улучшенный), dedicated 1+1 (выделенный 1+1), dedicated 1:1 (выделенный 1:1), shared (разделяемый), unprotected (без защиты), extra traffic (избыточный трафик). Точные определения каждого из этих типов приведены в параграфе 7.1 документа [RFC3471].

7.14. Явная маршрутизация и явное управление метками

За счет использования явного маршрута пути, взятые для LSP, могут контролироваться более или менее точно. Обычно узел на головной стороне (head-end) LSP находит явный маршрут и строит ERO³⁴/ER³⁵, содержащий этот маршрут. Возможно, что краевой узел не строит никакого явного маршрута и просто передает сигнальный запрос используемому по умолчанию соседнему LSR (так будет поступать хост IP/MPLS). Например, явный маршрут может быть добавлен в сигнальное сообщение первым коммутирующим узлом от имени краевого узла. Отметим также, что явный маршрут меняется промежуточными LSR в процессе прохождения к адресату.

Явный маршрут исходно определен в MPLS-TE, как список абстрактных узлов (т. е., групп узлов), через которые проходит явный путь. Каждый абстрактный узел может представляет собой адресный префикс IPv4/IPv6 или номер AS. Это позволяет генератору явного маршрута не иметь полной информации о деталях пути. В простейшем случае абстрактный узел может представлять собой точный адрес IP (32 бита), идентифицирующий конкретный узел (его называют простым абстрактным узлом).

MPLS-TE поддерживает строгие (strict) и нестрогие (loose0 абстрактные узлы. Путь между строим узлом и его предшественником должен включать только сетевые узлы строгого узла и предшествующего ему абстрактного узла. Путь между нестрогим узлом и его предшественником может включать не только сетевые узлы нестрогого узла или предшествующего ему абстрактного узла, но и прочие узлы сети.

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

В частности, явный контроль меток в явном маршруте позволяет завершать LSP на конкретном выходном порту выходного узла. Действительно, субобъект/TLV должен следовать за субобъектом/TLV, содержащим адрес IP или идентификатор интерфейса (для безадресного интерфейса), связанный с каналом, который будет использоваться.

Это может быть полезно в случаях, когда желательно объединить два LSP (т. е., при соединении «хвоста» одного LSP с «головой» второго LSP).

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

7.15. Запись маршрута

Для повышения уровня надежности и управляемости организуемых LSP в RSVP-TE была введена концепция записи маршрута со следующими функциями:

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

В архитектуре GMPLS только вторая и третья функции применимы главным образом для уровней TDM, LSC и FSC.

7.16. Модификация и перемаршрутизация LSP

Модификация и перемаршрутизация LSP уже доступны в MPLS-TE и GMPLS не добавляет в них ничего нового. В рамках концепции make-before-break³⁶ старый путь используется, пока создается новый путь, что позволяет предотвратить удвоенный расход ресурсов. Затем узел, меняющий маршрутизацию, может переключиться на новый путь и закрыть старый. Эта возможность поддерживается в RSVP-TE (с использованием разделяемый явных фильтров) и CR-LDP (с использованием флага индикации действия).

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

7.17. Обслуживание административного статуса LSP

GMPLS обеспечивает дополнительную возможность индикации административного статуса LSP с использованием нового объекта/TLV Admin Status. Информация об административном статусе может использоваться двумя способами.

В первом случае объект/TLV Admin Status передается в сообщении Path/Label Request или Resv/Label Mapping для индикации административного статуса LSP. В этом варианте информация об административном статусе показывает состояние LSP, которое может принимать значения up (активен) или down (не активен), указывать режим тестирования (testing) или процесс удаления.

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

Возможно, что некоторые узлы на пути LSP не будут поддерживать Admin Status. В таких случаях объект будет проходить через узел в неизменном виде и обработка может продолжаться.

В некоторых условиях (в частности, для оптических сетей) полезно устанавливать для LSP статус being deleted (будет удален) до его перевода в неактивное состояние, чтобы предотвратить генерацию бесполезных сигналов тревоги. Входной LSR перед удалением LSP помещает подходящий объект/TLV Admin Status в сообщение Path/Label Request (с установкой для флага индикации действия значения modify). Транзитные LSR обрабатывают объект/TLV Admin Status и пересылают его. Выходной LSR отвечает сообщением Resv/Label Mapping (с установкой для флага индикации действия значения modify) с объектом Admin Status. При получении такого сообщения и объекта входной узел передает сообщение PathTear/Release в нисходящем направлении для удаления LSP и обычной обработки RSVP-TE/CR-LDP.

Во втором случае объект/TLV Admin Status передается в сообщении Notification/Label Mapping (с установкой для флага индикации действия значения modify) для запроса у входного узла смены административного статуса LSP. Это позволяет промежуточным и выходным узлам инициировать смену административного статуса пути. В частности, это позволяет промежуточным и выходным LSR запрашивать освобождение LSP по инициативе входного узла.

7.18. Отделение канала управления

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

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

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

Выбор интерфейса данных для использования всегда осуществляется отправителем сообщения Path/Label Request и указывается путем включения идентификатора интерфейса канала данных в сообщение с помощью нового субтипа объекта/TLV RSVP_HOP.

Для двухсторонних LSP отправитель выбирает интерфейс данных в каждом направлении. Во всех случаях, кроме связок, восходящий интерфейс определяется нисходящим интерфейсом. Для связок отправитель сообщения Path/Label Request явно указывает интерфейс-компоненту, используемую в каждом направлении. Новый объект/TLV используется в сообщении Resv/Label Mapping для индикации использования нисходящим узлом указанного интерфейса (интерфейсов).

Новый объект/TLV может содержать список вложенных TLV, каждый из которых может адресом IPv4/IPv6, индексом интерфейса, идентификатором нисходящего или восходящего интерфейса-компоненты. В трех последних случаях вложенный TLV содержит IP-адрес и идентификатор интерфейса (адрес IP будет использоваться для идентификации Interface ID, в качестве которого может служить, например, идентификатор маршрутизатора для экземпляра).

В некоторых случаях полезно идентифицировать конкретный интерфейс, с которым связана ошибка. Для этого определены объекты RSVP IF_ID и ERROR_SPEC.

8. Смежность по пересылке (FA)

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

Агрегирование осуществляется с помощью (a) LSR, создающего TE LSP, (b) LSR, формирующего смежность по пересылке за пределами данного LSP (анонсирование данного LSP, как канала TE в IS-IS/OSPF), (c) дозволения другим LSR использовать смежность по пересылке в своих расчетах путей и (d) вложения LSP, начинающихся на других LSR в данный LSP (например, за счет создания стека меток в случае IP).

ISIS/OSPF в лавинном режиме рассылает информацию FA так же, как прочую информацию о состояниях каналов. В результате такой рассылки LSR имеет в своей базе данных о состоянии каналов TE не только обычную информацию о каналах, но и данные об FA.

LSR при расчете путей использует не только обычную информацию о каналах, но и данные FA. После расчета пути LSR использует RSVP-TE/CR-LDP для организации связывания меток на пути. FA требует лишь простого расширения для протоколов сигнализации и маршрутизации.

8.1. Смежность по маршрутизации и пересылке

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

FA анонсируются, как каналы GMPLS TE типа определенных в [HIERARCHY]. Каналы GMPLS TE анонсируются в OSPF и IS-IS в соответствии с определениями [OSPF-TE-GMPLS] и [ISIS-TE-GMPLS]. Эти документы задают также расширения [OSPF-TE] и [ISIS-TE], определяющие каналы TE.

При динамическом создании FA атрибуты TE наследуются от FA-LSP, индуцировавшего создание FA. В документе [HIERARCHY] описано, как каждый из TE-параметров FA наследуется от FA-LSP. Отметим, что полоса пропускания FA должна быть не меньше полосы FA-LSP, вызвавшего создание, но может быть больше, если для полосы FA-LSP доступны только дискретные значения. В общем случае для динамически создаваемой смежности по пересылке может потребоваться основанный на правилах механизм связывания атрибутов со смежностью по пересылке.

Анонс FA может содержать информацию о пути, взятую из FA-LSP, связанного с FA. Другие LSR могут использовать эту информацию для расчета путей. Информация передается в новых OSPF и IS-IS TLV, которые называют Path TLV.

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

Если отношения смежности по пересылке связываются (путем связки каналов) и получаемая в результате связка передает Path TLV, лежащий в основе путь для всех FA-LSP, формирующих каналы-компоненты, должен быть один и тот же.

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

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

8.2. Аспекты сигнализации

В целях обработки явного маршрута в сообщении Path/Request пути LSP, который будет туннелироваться через смежность по пересылке, LSR в «голове» FA-LSP видит LSR в «хвосте» FA-LSP, как смежный (один интервал IP).

8.3. Каскадирование смежности по пересылке

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

Определены новые суб-TLV для OSPF и IS-IS, позволяющие анонсировать возможности мультиплексирования для каждого интерфейса — PSC, L2SC, TDM, LSC или FSC. Эти суб-TLV называют дескрипторами возможностей коммутации интерфейса³⁷ и они служат дополнением к суб-TLV, определенных в [OSPF-TE-GMPLS] и [ISIS-TE-GMPLS]. Информация, передаваемая в этих суб-TLV, используется для создания областей (region) LSP и определения границ областей.

При расчете пути для LSP могут приниматься во внимание границы областей. Например, расчет может ограничивать пути, принимаемые для LSP, могут ограничиваться набором каналов, которые поддерживают мультиплексирование/демультиплексирование PSC. Когда требуется, чтобы LSP пересекал границу области, на лежащем в основе уровне (т. е., на уровне L2SC) может организовываться FA. Это может вызвать каскадирование FA между уровнями в показанном здесь порядке — L2SC, далее TDM, затем LSC и, наконец, FSC.

9. Смежность по маршрутизации и сигнализации

По определению два узла являются смежными по маршрутизации (IS-IS/OSPF), если они являются соседями в IS-IS/OSPF.

По определению два узла являются смежными по сигнализации (RSVP-TE/CR-LDP), если они являются соседями в RSVP-TE/CR-LDP. Узлы A и B являются соседями RSVP-TE, если они напрямую обмениваются сообщениями RSVP-TE (Path/Resv) (например, как описано в параграфах 7.1.1 и 7.1.2 документа [HIERARCHY]). Отношения соседства включают обмен сообщениями RSVP-TE Hello.

По определению смежность по пересылке (FA) представляет собой канал TE между двумя узлами GMPLS, путь которого проходит через один или множество узлов (G)MPLS в том же экземпляре уровня управления (G)MPLS. Если между парой узлов есть один или множество каналов, не являющихся TE-каналами, предполагается (но не требуется), что эти узлы являются смежными по маршрутизации. Если между парой узлов нет каналов TE, не являющихся FA , предполагается (но не требуется), что эти два узла не являются смежными по маршрутизации. Разумеется, что если каналы TE между двумя узлами используются для организации LSP, два узла должны быть смежными по сигнализации.

Если нужно организовать отношения смежности по маршрутизации и/или сигнализации между двумя узлами, между ними должен быть путь IP. Этот путь может быть, например, каналом TE с поддержкой на интерфейсах коммутации PSC, чем-нибудь, похожим на канал IP (например, туннель GRE или двухсторонний LSP с поддержкой на интерфейсах коммутации PSC).

Канал TE может оказаться непригодным для прямой организации смежности по маршрутизации и/или сигнализации. Это обусловлено тем, что в GMPLS смежность по маршрутизации и сигнализации требует обмена данными на уровне кадров/пакетов и канал TE (например, канал между OXC) может быть неспособен обмениваться данными на уровне пакетов. В этом случае смежность по маршрутизации и сигнализации организуется с помощью одного или множества каналов управления (см. [LMP]).

Между парой узлов может быть канала TE даже при отсутствии между этими узлами смежности по маршрутизации. Естественно, на каждом узле должен работать протокол OSPF/IS-IS с расширениями GMPLS для того, чтобы можно было анонсировать канал TE. Точнее говоря, на узле должно работать расширение GMPLS для каналов TE с поддержкой коммутации на интерфейсах (см. [GMPLS-ROUTING]), отличной от PSC. Более того, на этом узле должны работать расширения GMPLS или MPLS для каналов TE с поддержкой на интерфейсах коммутации PSC.

Следует использовать механизмы отделения канала управления³⁸ [RFC3471] даже в тех случаях, когда путь путь IP между двумя узлами является каналом TE. Т. е., сигнализации RSVP-TE/CR-LDP следует использовать объект Interface_ID (IF_ID) для указания конкретного канала TE при организации LSP.

Путь IP может включать множество интервалов IP. В этом случае следует использовать механизмы, описанные в параграфах 7.1.1 b 7.1.2 of [HIERARCHY] (в дополнение к Control Channel Separation).

10. Обработка отказов на уровне управления

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

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

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

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

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

Эти вопросы решаются на уровне конкретных протоколов, как описано в [RFC3473], [RFC3472], [OSPF-TE-GMPLS] и [ISIS-TE-GMPLS]. Отметим, что это применимо только для случаев, когда имеются механизмы детектирования отказов на каналах данных независимо от отказов на каналах управления.

Устойчивость к отказам LDP³⁹ [RFC3479] задает процедуры восстановления при отказах канала управления. В [RFC3473] указано, как осуществляется восстановление при отказах каналов управления и узлов.

11. Защита и восстановление LSP

В этом разделе рассматриваются вопросы защиты и восстановления (P&R⁴⁰) для GMPLS LSP. Это обусловлено требованиями [RFC3386] и некоторыми принципами, намеченными в [RFC3469]. По мере определения механизмов GMPLS P&R защита и восстановление будут улучшаться. Ниже приведен перечень вопросов, рассматриваемых в данном разделе.

Информация этого раздела применима только к ситуациям, когда подверженные влиянию отказов LSP относятся у уровню данных (транспорту). В разделе 10 рассмотрены вопросы обработки отказов уровня управления на каналах управления и узлах. Данный раздел фокусируется на P&R для уровней TDM, LSC и FSC. Существуют специфические требования P&R для этих уровней, которые отсутствуют на уровне PSC.
В данном разделе рассматриваются вопросы P&R внутри области в отличие от P&R между областями и между доменами. Отметим, что P&R можно ограничить даже уровнем оборудования заказчика, уровнем набора однотипного оборудования или уровнем одной области маршрутизации.
В этом разделе рассматривается P&R внутри одного уровня (горизонтальная иерархия, определенная в [RFC3386]) в отличие от P&R между уровнями (вертикальная иерархия).
Механизмы P&R в общем случае предназначены для обработки одиночных отказов, которые делают необходимым многообразие SRLG. Восстановление при множественных отказах требует дополнительного исследования.
Поддерживаются как кольцевая, так и многосвязная (mesh) топология.

В дальнейшем предполагается, что:

устройства TDM, LSC и FSC обычно выделяют ресурсы для восстановления способом, отличным от «выделения по возможности⁴¹»; ресурсы для восстановления уже используются (выделены) или зарезервированы логически (независимо от того, используются ли они для прерываемого трафика, эти ресурсы не могут быть доступны для обычного трафика);
совместно используемые механизмы P&R позволяют операторам максимизировать коэффициент загрузки их сети;
передача прерываемого избыточного трафика с использованием предназначенных для восстановления ресурсов удобна для операторов=.

11.1. Обеспечение защиты через домены и уровни

Для описания архитектуры P&R требуется рассмотреть два варианта иерархии [RFC3386]:

Горизонтальная иерархия, содержащая множество доменов P&R, представляющая важность в основанной на LSP схеме защиты. Зона действия P&R может быть расширена через канал (или интервал), административный домен или подсеть, LSP в целом.Административный домен может состоять из одного домена P&R или представлять собой объединение множества более мелких доменов P&R. Оператор может конфигурировать домены P&R на основе требований заказчиков с учетом сетевой топологии и требований по построению трафика.
Вертикальная иерархия, включающая множество уровней P&R с различной гранулярностью (поток пакетов, трейлер STS, световой путь, волокно и т. п.).При отсутствии адекватной координации P&R отказ может распространяться на следующий уровень иерархии P&R. Это может порождать «коллизии» и одновременные действия по восстановлению могут вызывать конфликты, снижать уровень использования ресурсов и вызывать нестабильности [MANCHESTER]. Следовательно, нужна согласованная стратегия защиты для координации действий по восстановлению в разных доменах и уровнях. Возможность использования GMPLS на разных уровнях может упростить такую координацию.Существует два типа стратегии расширения защиты — «снизу вверх» и «сверху вниз». Первый вариант предполагает, что схемы восстановления «нижнего уровня» является более рациональной. Следовательно, она может подавить и задержать P&R вышележащего уровня. В варианте расширения сверху вниз предпринимается попытка выполнить P&R на верхних уровнях до вовлечения в работу P&R нижележащих уровней. P&R верхнего уровня выбирается для сервиса и обеспечивает возможность перемаршрутизации на уровне CoS или LSP.

Сервисные соглашения (SLA⁴²) между сетевыми операторами и их клиентами нужны для определения необходимости временных рамок P&R для каждого уровня и каждого домена.

11.2. Отображение сервиса на ресурсы P&R

Выбор схемы P&R является компромиссом между уровнем полезной загрузки сети (стоимость) и временем прерывания обслуживания. С учетом этого предполагается что сервис-провайдеры будут поддерживать широкий спектр типов услуг и уровней сервиса.

Можно классифицировать LSP в небольшой набор уровней сервиса. Вместе с другими параметрами уровень сервиса определяет параметры надежности LSP. Уровень сервиса, связанный с данным LSP, отображается на одну или множество схем P&R в процессе организации LSP. Преимущество такого отображения заключается в том, что LSP может использовать разные схемы P&R⁴³ в разных сегментах сети (например, некоторые каналы могут использовать span-защиту, а другие сегменты LSP — кольцевую). Очевидно, что такие детали определяются сервис-провайдером.

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

Критерием дифференцирования между уровнями сервиса является время прерывания обслуживания при отказах в сети, которое определяется продолжительностью периода между возникновением отказа и восстановлением связности. Выбор уровня сервиса (или схемы P&R) следует производить на основе требований по обслуживанию для различных приложений.

11.3. Классификация характеристик механизма P&R

              +-Расчет по    +-Организация     +-Ресурсы выделены
              | запросу      | по запросу      | заранее
              |              |                 |
Обеспечение   |              |                 |
восстан. LSP -+-Предв. расчет+-Предв. Организ. +-Ресурсы выделены
по запросу 

               +--- выделенный (1:1, 1+1)
               |
               |
               +--- разделяемый (1:N, кольцо, разделяемая сеть)
               |
Уровень        |
избыточности---+--- по возможности

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

11.4. Этапы P&R

Восстановление при отказе или повреждении в сети осуществляется в несколько этапов, как рассмотрено в работе [RFC3469], включая обнаружение отказа, его локализацию, уведомление, восстановление (т. е. собственно P&R) и возобновление трафика (т. е. возврат трафика к исходному состоянию работающего LSP или создание нового пути).

Детектирование отказа представляет зависит от технологии и реализации. В общем случае отказы обнаруживаются с помощью механизмов нижележащих уровней (например, SONET/SDH, LOL⁴⁴). Когда узел детектирует отказ, объекту GMPLS может передаваться сигнал тревоги, который будет инициировать соответствующие действия или передаваться на нижележащий уровень (например, SONET/SDH AIS).
Локализация отказа может выполняться с помощью GMPLS (например, путем использования локализации отказов LMP — см. параграф 6.4).
Уведомления об отказах могут обеспечиваться средствами GMPLS (например, с помощью уведомлений GMPLS RSVP-TE/CR-LDP — см. параграф 7.12).
В этом разделе рассматриваются различные механизмы, доступные для восстановления и возобновления трафика после детектирования и локализации отказа, а также уведомления о нем.

11.5. Стратегия восстановления

Методы P&R можно разделить на защиту (Protection) и восстановление (Restoration). Для целей защиты ресурсы, используемые в защиту конечных точек, организуются до возникновения отказа и связность при возникновении отказа обеспечивается простым переключением, выполняемым на защищенных конечных точках. При восстановлении же, напротив, используется сигнализация для выделения ресурсов по восстанавливаемому пути.

Целью защиты является максимально быстрая реакция и защита может основываться на использовании избыточных полей управления для координации конечных точек. Защита для сетей SONET/SDH описана в документах [ITUT-G.841] и [ANSI-T1.105]. Механизмы защиты можно классифицировать по уровню избыточности и возможности их совместного использования.
Механизмы восстановления могут опираться на протоколы сигнализации для координации переключений в процессе восстановления, а также могут включать простое восстановление с сигнализацией по факту возобновления сервиса или упреждающую сигнализацию (до возобновления обслуживания).

P&R можно применять локально или в режиме сквозной работы. В локальном варианте P&R фокусируется на возникающих вблизи отказах с целью снижения задержки при восстановлении сервиса. В сквозном режиме восстановлением управляют исходный и завершающий узлы LSP.

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

11.6. Механизмы восстановления — схемы защиты

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

1+1 Link Protection. Два заранее подготовленных ресурса используются параллельно. Например, данные передаются одновременно по двум параллельным каналам и на приемной стороне используется селектор для выбора лучшего источника (см. также [GMPLS-FUNCT]).
1:N Link Protection. Рабочие и защитные ресурсы (N рабочих, 1 резервный) подготавливаются заранее. При отказе рабочего ресурса данные переключаются на защитный ресурс с использованием механизма координации (например, в служебных байтах). В более общем случае N рабочих и M защитных ресурсов позволяют организовать защиту M:N (см. также [GMPLS-FUNCT]).
Enhanced Protection. Могут применяться различные механизмы (типа защитных колец) для повышения уровня защиты при отказе более одного канала для обеспечения возможности обхода отказавшего узла или интервала (span) узлов с использованием заранее подготовленной топологии защитных ресурсов (на момент подготовки этого документа ссылок на завершенные работы не было).
1+1 LSP Protection. Одновременная передача данных по рабочему и защитному LSP с выбором на оконечной стороне (см. также [GMPLS-FUNCT]).

11.7. Механизмы восстановления — схемы восстановления

Благодаря использованию в GMPLS распределенного уровня управления, восстановление можно выполнить за десятки миллисекунд. Значительно сложнее восстановить обслуживание при использовании только NMS⁴⁵ — в таких случаях восстановление занимает секунды.

Сквозное восстановление LSP с возобновлением. Сквозной путь восстановления организуется после отказа Путь восстановления может динамически рассчитываться после отказа или подготавливаться заранее (зачастую, при организации LSP). Важно подчеркнуть, что до отказа по пути восстановления не используется какой-либо специальной сигнализации и полоса для восстановления не резервируется. Следовательно, в таких случаях нет гарантии, что данный путь восстановления будет доступен в момент возникновения отказа. В результате при восстановлении может возникать задержка, связанная с поиском доступного пути.
Сквозное восстановление LSP с предварительной сигнализацией для резервирования полосы, но без предварительного выделения меток. Путь восстановления рассчитывается до отказа и для этого пути передаются сигнальные сообщения с целью резервирования полосы, но метки заранее не выбираются (см. также [GMPLS-FUNCT]).Ресурсы, резервируемые на каждом канале пути восстановления, могут относиться к разным рабочим LSP, которые предположительно не могут отказать одновременно. Для определения уровня влияния отказов на разделяемых независимых каналах может применяться локальная политика узла. При обнаружении отказа по пути восстановления инициируется сигнализация LSP для выполнения требуемых переключений.
Сквозное восстановление LSP с предварительной сигнализацией для резервирования полосы и предварительным выделением меток. Путь восстановления рассчитывается до отказа, для этого пути передаются сигнальные сообщения с целью резервирования полосы и заранее выбираются метки (см. также [GMPLS-FUNCT]).Ресурсы, резервируемые на каждом канале пути восстановления, могут относиться к разным рабочим LSP, которые предположительно не могут отказать одновременно. В сетях на основе технологий TDM, LSC и FSC после обнаружения отказа используется сигнализация LSP для организации требуемых переключений на промежуточных коммутаторах пути восстановления с использованием заранее выделенных меток.
Локальное восстановление LSP. Описанные выше модели могут использоваться локально (не в сквозном режиме) с целью снижения времени восстановления (на момент подготовки этого документа ссылок на завершенные работы не было).

11.8. Критерии выбора схемы

В этом параграфе рассматриваются критерии, которые могут быть использованы при выборе механизмов P&R.

Отказоустойчивость. В общем случае снижение уровня предварительного планирования пути восстановления будет повышать отказоустойчивость схемы восстановления при условии доступности требуемых ресурсов. Схемы восстановления с заранее подготовленными путями не смогут обеспечить восстановления при отказах, затрагивающих одновременно рабочий и восстановительный путь. Поэтому пути следует выбирать как можно более развязанные между собой (т. е., не связанные на уровне узлов и SRLG), чтобы один отказ не мог воздействовать на оба пути. Риск одновременного отказа на обоих путях можно снизить путем пересчета пути восстановления при возникновении на нем отказа.Предварительный выбор меток снижает уровень гибкости для многих сценариев отказа по сравнению с восстановлением без предварительного выбора метки. Если возникает отказ, воздействующий на два LSP, разделяющие метку на общем узле путей восстановления, восстановление возможно только для одного из этих LSP, если не будет изменено выделение метки.Отказоустойчивость схемы восстановления зависит также от размера резервируемой для восстановления полосы. По мере роста совместного использования полосы восстановления (снижение резерва) схема восстановления становится менее устойчивой к отказам. Схемы восстановления с предварительной сигнализацией для резервирования полосы (с предварительным выбором метки или без такового) могут обеспечивать резерв полосы для восстановления при любом заданном множестве отказов (отказ одного SRLG, отказ произвольной пары SRLG и т. п.). Очевидно, что для более крупных отказов выделяется большая полоса для восстановления. Таким образом, уровень защиты сети определяется политикой выделения полосы для восстановления.
Время восстановления. В общем случае повышение уровня предварительного планирования восстановительного пути ускоряет работу схемы P&R. Схемы защиты обычно работают быстрее схем восстановления. Восстановление при зарезервированной с помощью сигнализации полосе (значительно) быстрее, чем восстановление с возобновлением пути. Локальное восстановление обычно быстрее сквозного.Требования к времени восстановления для защитной коммутации SONET/SDH (не включая время обнаружения отказа) в [ITUT-G.841] задают значение 50 мсек, с учетом ограничений на расстояния, число вовлеченных соединений и число узлов в кольце при использовании улучшенной кольцевой схемы защиты.
Временные параметры механизмов восстановления для других технологий определены в [RFC3386].
Совместное использование ресурсов. Защита каналов по схеме 1+1 и 1:N, а также защита LSP требует наличия выделенных путей восстановления с ограниченной возможность использования этих путей для других целей — схема 1+1 совместного использования каналов, 1:N разрешает некоторое использование защитных ресурсов для передачи другого (прерываемого) трафика. Гибкость решения ограничивается топологией (например, использованием традиционной технологии защитного кольца). Уровень дозволенного совместного использования защитных ресурсов напрямую влияет на размер восстановительного пула. В схемах восстановления с возобновлением может быть определен восстановительный пула, из которого выбираются все маршруты, доступные после аварии. Таким образом, степень совместного использования определяется размером доступной восстановительной емкости. При восстановлении с предварительным резервированием полосы с помощью сигнализации объем восстановительных ресурсов определяется локальной политикой резервирования полосы. Во всех схемах восстановления прерываемые ресурсы могут использовать резервную емкость, когда она не требуется.

12. Управление сетью

Сервис-провайдеры (SP⁴⁶) широко используют системы сетевого управления для настройки конфигурации, мониторинга и обслуживания различных устройств в своих сетях. Важно подчеркнуть, что оборудование SP может быть распределено географически по разным сайтам и это повышает уровень важности вопросов распределенного управления. Сервис-провайдерам следует использовать систему NMS⁴⁷, стандартные протоколы управления типа SNMP (см. [RFC3410], [RFC3411] и [RFC3416]) и соответствующие модули MIB⁴⁸ в качестве стандартных интерфейсов для настройки, мониторинга и обслуживания устройств, расположенных на разных площадках. Провайдеры могут также использовать командный интерфейс управления (CLI⁴⁹), предоставляемый производителями оборудования. Однако такое решение нельзя отнести к стандартным и рекомендуемым по причине отсутствия стандартов для языка и интерфейса CLI, что приводит к наличию N⁵⁰ разных CLI в сети с оборудованием N различных производителей. В контексте GMPLS наличие стандартных интерфейсов (например, SNMP) для устройств SP очень важно в силу особенностей самой технологии GMPLS. Поскольку GMPLS включает множество разных технологий, используемых на уровнях управления и данных, очень важна гибкость интерфейсов управления, чтобы обеспечить администраторам возможность простого, эффективного и стандартного управления GMPLS.

12.1. Системы сетевого управления (NMS)

Системе NMS следует поддерживать информацию о каждом устройстве в системе. Отметим, что система NMS на практике может включать несколько распределенных приложений (например, средства сбора сигналов тревоги, консоли управления, приложения для опроса и т. п.), которые совместно образуют систему управления сетью оператора. За счет этого система управления позволяет принимать решения по предоставлению услуг и управлению на основе полной информации о сети SP. Информация по настройке и предоставлению услуг (например, запросы новых услуг) может вводиться в NMS и в последствии распространяться по протоколу SNMP на удаленные устройства. Это делает задачу управления сетью SP более компактной и менее трудоемкой по сравнению с управлением на уровне отдельных устройств (например, с помощью CLI).

Защита и контроль доступа может обеспечиваться на основе моделей USM⁵¹ SNMPv3 [RFC3414] и VACM⁵² [RFC3415]. Эти модели могут очень эффективно применяться в сети SP, поскольку сервис-провайдер получает доступ и контроль для всех устройств своего домена. Требуется разработка стандартизованных MIB, которые позволят обеспечить повсеместное использование модели для управления, настройки и мониторинга устройств внутри сети и даже через границы сетей SP.

12.2. База данных управления (MIB)

В контексте GMPLS очень важно наличие стандартизованных интерфейсов для устройств. Поскольку GMPLS включает на уровне управления множество технологий, важно обеспечить достаточную гибкость модулей SNMP MIB, которая позволит администраторам полностью контролировать уровень управления. Для реализации этого следует использовать модули MIB, которые могут кооперироваться (например, скоординированное создание строк в агентах), или обобщенные модули MIB, которые агрегируют некоторые из нужных действий и передают детальную информацию в устройства. Важно отметить, что при некоторых обстоятельствах может потребоваться дублирование некоторого незначительного подмножества объектов в новых модулях MIB для обеспечения удобства управления. Управление некоторыми частями GMPLS может также обеспечиваться на основе имеющихся интерфейсов MIB (например, SONET MIB) или интерфейсов, которые будут определены. Модули MIB могут оказаться уже определенными в IETF или ITU. Для имеющихся модулей MIB могут потребоваться расширения с учетом желаемой для GMPLS функциональности. В таких случаях рабочим группам следует подготовить новые версии MIB с требуемыми расширениями.

12.3. Инструментальные средства

Как и в традиционных сетях для отладки и мониторинга GMPLS нужны инструменты типа traceroute [RFC1393] и ping [RFC2151] прежде всего для топологии уровня управления GMPLS, которая будет подражать топологии уровня данных. Более того, такие средства обеспечивают информацию о доступности сетей. Протоколы управления GMPLS должны будут показывать часть информации для обеспечения корректной работы таких инструментов и обеспечения информации для GMPLS. Эти инструменты должны работать из командной строки (CLI). Следует также обеспечить возможность удаленной работы с инструментами через интерфейс SNMP [RFC2925].

12.4. Корреляция отказов на разных уровнях

По природе GMPLS и в силу использования множества уровней контроля и передачи данных и управляющей информации GMPLS нужно, чтобы информация об отказе на одном уровне передавалась на смежные (выше- и нижележащий) уровни для уведомления последних об авариях. Однако с учетом природы этих уровней возможна (и весьма вероятна) передача сотен и даже тысяч уведомлений между уровнями. Такое поведение нежелательно по ряду причин. Во-первых, эти уведомления будут перегружать устройства работой. Во-вторых, если устройства запрограммированы на генерацию сообщений SNMP Notification [RFC3417] может приводить к лавинам уведомлений о приеме уведомлений. Более того, система NMS, которая должна обрабатывать такие уведомления, будет вынуждена работать со множеством дубликатов информации. По этой причине, если 1000 интерфейсов на уровне B собирается в один интерфейс нижележащего уровня A и на интерфейсе A возникнет авария, каждому интерфейсу уровня B не следует передавать уведомления. Взамен следует передать одно уведомление от интерфейса уровня A. Система NMS, принявшая такое уведомление, должна быть способна найти корреляцию между фактом отказа интерфейса и индуцированными авариями на интерфейсах уровня B, а также предпринять соответствующие действия.

Поддерживающим GMPLS устройствам следует обеспечивать механизм агрегирования, резюмирования, включения и отключения межуровневых уведомлений с учетом приведенных выше соображений. В контексте модулей SNMP MIB все модули, используемые GMPLS, должны обеспечивать возможность разрешения/запрета для всех объектов уведомлений. Более того, эти MIB должны также обеспечивать объекты или функциональность для резюмирования (как сказано выше). Системы NMS и стандартные инструменты обработки уведомлений или их отслеживания на множестве уровней в любом данном устройстве должны быть способны обрабатывать значительный объем информации, которая потенциальном может генерироваться сетевыми устройствами GMPLS.

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

GMPLS определяет архитектуру уровня управления для множества технологий и типов сетевых элементов. В общем случае с момента, когда LSP, организованные с помощью GMPLS, смогут передавать большие объемы информации и потреблять значительные сетевые ресурсы, требуются механизмы защиты для обеспечения безопасности лежащей в основе сети от атак на уровень управления и/или несанкционированного использования транспортных ресурсов. Уровню управления GMPLS следует включать механизмы, предотвращающие или минимизирующие риск вставки или подмены трафика управления со стороны атакующих. Эти риски зависят от уровня доверия между узлами, которые обмениваются управляющими сообщениями GMPLS, а также от реализации и физических характеристик каналов управления. Например, канал управления в основной полосе оптического волокна использующий служебные байты SONET/SDH в общем случае менее уязвим, нежели канал управления в основной полосе сети IP.

Механизмы защиты могут обеспечивать аутентификацию и конфиденциальность. Аутентификация может обеспечивать проверку источника, целостность сообщений и предотвращение повторного использования, а конфиденциальность гарантирует недоступность для посторонних содержимого сообщений. В ситуациях, когда реализация GMPLS требует в основном аутентификации, могут использоваться соответствующие механизмы протоколов-компонент GMPLS (см.[RFC2747], [RFC3036], [RFC2385] и [LMP]). В дополнение к этому может применяться стек протоколов IPsec (см.[RFC2402], [RFC2406] и [RFC2409]) для обеспечения аутентификации и/или конфиденциальности в каналах управления GMPLS. IPsec обеспечивает преимущества комбинированной защиты для всех протокольных компонент GMPLS, а также для управления.

Связанным вопросом является проверка полномочности запросов на выделение ресурсов в поддерживающих GMPLS узлах. Проверка полномочий позволяет определить, является ли запрашивающая ресурсы сторона идентифицированной и имеет ли она право доступа к ресурсам. Это определение обычно выполняется на основе локальной политики [RFC2753] (например, путем задания предельной полосы, доступной некому «пользователю» в условиях конкурентного доступа к ресурсам. Такая политика может стать достаточно сложной, по мере роста в ней учитывается числа пользователей, типов ресурсов и более изощренной проверки полномочий.

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

В заключение следует отметить, что технология GMPLS сама по себе не создает новых проблем безопасности для существующих протоколов сигнализации MPLS-TE (RSVP-TE, CR-LDP), маршрутизации (OSPF-TE, IS-IS-TE) и сетевого управления (SNMP).

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

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

Большое спасибо Ben Mack-Crane (Tellabs) за обсуждение вопросов, связанных с SONET/SDH. Благодарим также Pedro Falcao, Alexandre Geyssens, Michael Moelants, Xavier Neerdaels и Philippe Noel из Ebone за их поддержку по вопросам, связанным с SONET/SDH и оптическими технологиями. В заключение хотим поблагодарить Krishna Mitra (Consultant), Curtis Villamizar (Avici), Ron Bonica (WorldCom) и Bert Wijnen (Lucent) за их работу по подготовке раздела 12.

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

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

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, «Multiprotocol Label Switching Architecture», RFC 3031, 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.

[RFC3471] Berger, L., «Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description», RFC 3471, January 2003.

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

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

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

[ANSI-T1.105] «Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, And Formats,» ANSI T1.105, 2000.

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

[GMPLS-FUNCT] Lang, J.P., Ed. and B. Rajagopalan, Ed., «Generalized MPLS Recovery Functional Specification», Work in Progress⁵⁵.

[GMPLS-G709] Papadimitriou, D., Ed., «GMPLS Signaling Extensions for G.709 Optical Transport Networks Control», Work in Progress⁵⁶.

[GMPLS-OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, «GMPLS UNI: RSVP Support for the Overlay Model», Work in Progress⁵⁷.

[GMPLS-ROUTING] Kompella, K., Ed. and Y. Rekhter, Ed., «Routing Extensions in Support of Generalized Multi-Protocol Label Switching», Work in Progress⁵⁸.

[RFC3946] Mannie, E., Ed. and Papadimitriou D., Ed., «Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control», RFC 3946⁵⁹, October 2004.

[HIERARCHY] Kompella, K. and Y. Rekhter, «LSP Hierarchy with Generalized MPLS TE», Work in Progress⁶⁰.

[ISIS-TE] Smit, H. and T. Li, «Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)», RFC 3784⁶¹, June 2004.

[ISIS-TE-GMPLS] Kompella, K., Ed. and Y. Rekhter, Ed., «IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching», Work in Progress⁶².

[ITUT-G.707] ITU-T, «Network Node Interface for the Synchronous Digital Hierarchy», Recommendation G.707, October 2000.

[ITUT-G.709] ITU-T, «Interface for the Optical Transport Network (OTN),» Recommendation G.709 version 1.0 (and Amendment 1), February 2001 (and October 2001).

[ITUT-G.841] ITU-T, «Types and Characteristics of SDH Network Protection Architectures,» Recommendation G.841, October 1998.

[LMP] Lang, J., Ed., «Link Management Protocol (LMP)», Work in Progress⁶³.

[LMP-WDM] Fredette, A., Ed. and J. Lang Ed., «Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems», Work in Progress⁶⁴.

[MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, «The Evolution of Transport Network Survivability,» IEEE Communications Magazine, August 1999.

[OIF-UNI] The Optical Internetworking Forum, «User Network Interface (UNI) 1.0 Signaling Specification — Implementation Agreement OIF-UNI-01.0,» October 2001.

[OLI-REQ] Fredette, A., Ed., «Optical Link Interface Requirements,» Work in Progress.

[OSPF-TE-GMPLS] Kompella, K., Ed. and Y. Rekhter, Ed., «OSPF Extensions in Support of Generalized Multi-Protocol Label Switching», Work in Progress⁶⁵.

[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, «Traffic Engineering (TE) Extensions to OSPF Version 2», RFC 3630, September 2003.

[RFC1393] Malkin, G., «Traceroute Using an IP Option», RFC 1393, January 1993.

[RFC2151] Kessler, G. and S. Shepard, «A Primer On Internet and TCP/IP Tools and Utilities», RFC 2151, June 1997.

[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, September 1997.

[RFC2385] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[RFC2402] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 2402⁶⁷, November 1998.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406⁶⁸, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409⁶⁹, November 1998.

[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and J. McManus, «Requirements for Traffic Engineering Over MPLS», RFC 2702, September 1999.

[RFC2747] Baker, F., Lindell, B., and M. Talwar, «RSVP Cryptographic Authentication», RFC 2747, January 2000.

[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, «A Framework for Policy-based Admission Control», RFC 2753, January 2000.

[RFC2925] White, K., «Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations», RFC 2925⁷⁰, September 2000.

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

[RFC3386] Lai, W. and D. McDysan, «Network Hierarchy and Multilayer Survivability», RFC 3386, November 2002.

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, «Introduction and Applicability Statements for Internet-Standard Management Framework», RFC 3410, December 2002.

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, «An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks», STD 62, RFC 3411, December 2002.

[RFC3414] Blumenthal, U. and B. Wijnen, «User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)», STD 62, RFC 3414, December 2002.

[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, «View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3415, December 2002.

[RFC3416] Presuhn, R., «Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3416, December 2002.

[RFC3417] Presuhn, R., «Transport Mappings for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3417, December 2002.

[RFC3469] Sharma, V. and F. Hellstrand, «Framework for Multi-Protocol Label Switching (MPLS)-based Recovery», RFC 3469, February 2003.

[RFC3477] Kompella, K. and Y. Rekhter, «Signalling Unnumbered Links in Resource ReSerVation Protocol — Traffic Engineering (RSVP-TE)», RFC 3477, January 2003.

[RFC3479] Farrel, A., «Fault Tolerance for the Label Distribution Protocol (LDP)», RFC 3479, February 2003.

[RFC3480] Kompella, K., Rekhter, Y., and A. Kullberg, «Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)», RFC 3480, February 2003.

[SONET-SDH-GMPLS-FRM] Bernstein, G., Mannie, E., and V. Sharma, «Framework for GMPLS-based Control of SDH/SONET Networks», Work in Progress⁷².

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

Peter Ashwood-Smith

Nortel

P.O. Box 3511 Station C,

Ottawa, ON K1Y 4H7, Canada

EMail: petera@nortelnetworks.com

Eric Mannie

Consult

Phone: +32 2 648-5023

Mobile: +32 (0)495-221775

EMail: eric_mannie@hotmail.com

Daniel O. Awduche

Consult

EMail: awduche@awduche.com

Thomas D. Nadeau

Cisco

250 Apollo Drive

Chelmsford, MA 01824, USA

EMail: tnadeau@cisco.com

Ayan Banerjee

Calient

5853 Rue Ferrari

San Jose, CA 95138, USA

EMail: abanerjee@calient.net

Lyndon Ong

Ciena

10480 Ridgeview Ct

Cupertino, CA 95014, USA

EMail: lyong@ciena.com

Debashis Basak

Accelight

70 Abele Road, Bldg.1200

Bridgeville, PA 15017, USA

EMail: dbasak@accelight.com

Dimitri Papadimitriou

Alcatel

Francis Wellesplein, 1

B-2018 Antwerpen, Belgium

EMail: dimitri.papadimitriou@alcatel.be

Lou Berger

Movaz

7926 Jones Branch Drive

MCLean VA, 22102, USA

EMail: lberger@movaz.com

Dimitrios Pendarakis

Tellium

2 Crescent Place, P.O. Box 901

Oceanport, NJ 07757-0901, USA

EMail: dpendarakis@tellium.com

Greg Bernstein

Grotto

EMail: gregb@grotto-networking.com

Bala Rajagopalan

Tellium

2 Crescent Place, P.O. Box 901

Oceanport, NJ 07757-0901, USA

EMail: braja@tellium.com

Sudheer Dharanikota

Consult

EMail: sudheer@ieee.org

Yakov Rekhter

Juniper

1194 N. Mathilda Ave.

Sunnyvale, CA 94089, USA

EMail: yakov@juniper.net

John Drake

Calient

5853 Rue Ferrari

San Jose, CA 95138, USA

EMail: jdrake@calient.net

Debanjan Saha

Tellium

2 Crescent Place

Oceanport, NJ 07757-0901, USA

EMail: dsaha@tellium.com

Yanhe Fan

Axiowave

200 Nickerson Road

Marlborough, MA 01752, USA

EMail: yfan@axiowave.com

Hal Sandick

Shepard M.S.

2401 Dakota Street

Durham, NC 27705, USA

EMail: sandick@nc.rr.com

Don Fedyk

Nortel

600 Technology Park Drive

Billerica, MA 01821, USA

EMail: dwfedyk@nortelnetworks.com

Vishal Sharma

Metanoia

1600 Villa Street, Unit 352

Mountain View, CA 94041, USA

EMail: v.sharma@ieee.org

Gert Grammel

Alcatel

Lorenzstrasse, 10

70435 Stuttgart, Germany

EMail: gert.grammel@alcatel.de

George Swallow

Cisco

250 Apollo Drive

Chelmsford, MA 01824, USA

EMail: swallow@cisco.com

Dan Guo

Turin

1415 N. McDowell Blvd,

Petaluma, CA 95454, USA

EMail: dguo@turinnetworks.com

Z. Bo Tang

Tellium

2 Crescent Place, P.O. Box 901

Oceanport, NJ 07757-0901, USA

EMail: btang@tellium.com

Kireeti Kompella

Juniper

1194 N. Mathilda Ave.

Sunnyvale, CA 94089, USA

EMail: kireeti@juniper.net

Jennifer Yates

AT&T

180 Park Avenue

Florham Park, NJ 07932, USA

EMail: jyates@research.att.com

Alan Kullberg

NetPlane

888 Washington

St.Dedham, MA 02026, USA

EMail: akullber@netplane.com

George R. Young

Edgeflow

329 March Road

Ottawa, Ontario, K2K 2E1, Canada

EMail: george.young@edgeflow.com

Jonathan P. Lang

Rincon Networks

EMail: jplang@ieee.org

John Yu

Hammerhead Systems

640 Clyde Court

Mountain View, CA 94043, USA

EMail: john@hammerheadsystems.com

Fong Liaw

Solas Research

Solas Research, LLC

EMail: fongliaw@yahoo.com

Alex Zinin

Alcatel

1420 North McDowell Ave

Petaluma, CA 94954, USA

EMail: alex.zinin@alcatel.com

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

Eric Mannie (консультант)

Avenue de la Folle Chanson, 2

B-1050 Brussels, Belgium

Phone: +32 2 648-5023

Mobile: +32 (0)495-221775

EMail: eric_mannie@hotmail.com

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

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

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

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

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

Funding for the RFC Editor function is currently provided by the Internet Society.

1Dense Wavelength Division Multiplexing — мультиплексирование с разделением по длине волны и высокой плотностью.

2Add-Drop Multiplexor — мультиплексор с возможностью отвода.

3Photonic cross-connect — фотонный кросс-коннектор.

4Optical cross-connect — оптический кросс-коннектор.

5Generalized Multi-Protocol Label Switching.

6Multi-Protocol Label Switching.

7Label Switching Router.

8Packet Switch Capable.

9Layer-2 Switch Capable.

10Time-Division Multiplex Capable.

11Terminal Multiplexer.

12Lambda Switch Capable.

13Fiber-Switch Capable.

14Label Switched Path.

15В иерархии мультиплексирования SONET/SDH определено несколько вложенных уровней сигнализации.

16Traffic Engineering — построение трафика.

17Shortest-Path First.

18В оригинале «constrained-based». Прим. перев.

19Link Management Protocol.

20Forwarding Adjacencies.

21Terminal Multiplexer — терминальный мультиплексор.

22Отношения смежности по пересылке рассматриваются в разделе 8. Смежность по пересылке (FA).

23Interface Switching Capability — коммутационные возможности интерфейса.

24Shared Risk Link Group — группа каналов с общим риском.

25User to Network Interface — интерфейс между пользователем и сетью.

26Network to Network Interface — интерфейс между сетями.

27Silent listening.

28Link Management Protocol — протокол управления каналом.

29Control Channel Identifier — идентификатор канала управления.

30Optical Line System (оптическая линейная система) или терминальный мультиплексор WDM.

31Explicit Route Object — объект явно заданного маршрута.

32Совместная маршрутизация устройств без конкатенации, но с включением всех устройств в один LSP.

33Generalized PID — обобщенный PID.

34Explicit Route Object — объект явного маршрута.

35Explicit Route TLV — TLV явного маршрута.

36Создать новый путь до разрыва имеющегося пути.

37Interface Switching Capability Descriptor sub-TLV.

38Control Channel Separation.

39LDP Fault tolerance.

40Protection and Restoration.

41Non-best effort way.

42Service Level Agreement.

43В оригинале ошибочно указано P&E. Прим. перев.

44Loss-of-Light — потеря оптического сигнала.

45Network Management System – система сетевого управления. Прим. перев.

46Service Provider.

47Network Management System.

48Management Information Base — база данных управления. Прим. перев.

49Command line interface.

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

51User-based Security Model — модель защиты с управлением на уровне отдельных пользователей.

52View-based Access Control Model — управление доступом на уровне представления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

69Этот документ обновлен RFC 4305. Прим. перев.

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

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

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

Рубрика: RFC | Оставить комментарий

RFC 3925 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)

Опубликовано 07.10.2004 автором Nikolai Malykh

Network Working Group                                     J. Littlefield
Request for Comments: 3925                           Cisco Systems, Inc.
Category: Standards Track                                   October 2004

Опции идентификации производителя для DHCPv4

Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)

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

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

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

Аннотация

Опции протокола DHCP¹ для Vendor Class и Vendor-Specific Information могут быть ограничительными и неоднозначными, когда клиент DHCP представляет множество производителей. В этом документе определяются две новых опции, основанные на опциях IPv6 для информации класса производителя и связанной с производителем информации, которые содержат Enterprise Number для устранения неоднозначности.

Оглавление

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

1. Введение

Протокол DHCP для IPv4, описанный в RFC 2131 [2], определяет опции, которые позволяют клиенту указать тип производителя (опция 60), а клиенту и серверу DHCP — обменяться зависящей от производителя информацией (опция 43) [5]. Хотя не запрещена передача множества копий этих опций в одном сообщении, это может приводить к неоднозначной интерпретации особенно для в тех случаях, когда информация связана с множеством производителей. Производитель, указанный опцией 60, определяет интерпретацию опции 43, которая не содержит указания производителя. Кроме того, конкатенация множества экземпляров одной опции, требуемая RFC 2131 и описанная в RFC 3396 [4], означает, что множественные копии опций 60 или 43 не будут независимыми.

При некоторых обстоятельствах реализации может потребоваться поддержка множества независимо определенных форм фирменной информации производителей. Например, реализация, которая должна соответствовать отраслевому стандарту использования DHCPv4 для обеспечения взаимодействия в той или иной технологической области, может потребоваться поддержка заданных производителями данной отрасли опций. Но той же реализации может потребоваться поддержка фирменных опций ее производителя. В частности, эта проблема возникает для производителей устройств, которые поддерживают стандарты [9], а также DOCSIS, CableHome и PacketCable, поскольку эти стандарты определяют отраслевое применение опций 60 и 43.

В этом документе определены две новых опции, моделирующие опции IPv6 для класса производителя и фирменной информации производителя, определенные в RFC 3315 [6], которые содержат выделенные IANA значения Enterprise Number [3] для устранения неоднозначной трактовки содержимого этих опций. При необходимости эти новые опции можно использовать в дополнение к имеющимся опциям vendor class и vendor information, определений которых данный документ не меняет.

1.1. Уровни требований

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

2. Поддержка множества производителей

Каждая из определенных в этом документе опций может включать данные более чем для одного производителя. Данные каждой опции, определенные здесь, включают номер организации (назначается IANA [3]), за которым следует размер данных, а далее — фирменные данные производителя. Эта последовательность может повторяться в каждой опции. Поскольку размер агрегата фирменных данных для каждой из опций может превышать 255 октетов, эти опции объявляются concatenation-requiring (требуется конкатенация) в соответствии с RFC 3396 [4]. Поэтому для каждой из двух определенных здесь опций агрегат из всех экземпляров фирменных данных рассматривается как одна длинная опция. Такие длинные опции можно поделить на более мелкие при кодировании пакетов в соответствии с RFC 3396 по любым границам октетов, удобным для реализации. Деления по границам между данными разных производителей не требуется, но это может быть удобно для кодирования или отслеживания пакетов.

3. Опция Vendor-Identifying Vendor Class

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

Эта опция может использоваться везде, где применима опция Vendor Class Identifier (60), как описано в RFC 2131 [2], за исключением сообщений DHCPNAK, где другие опции не разрешаются. Наиболее полезна эта опция в сообщениях от клиента DHCP к серверу DHCP (DHCPDISCOVER, DHCPREQUEST, DHCPINFORM).

Формат опции V-I Vendor Class показан ниже.

                        1 1 1 1 1 1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  option-code  |  option-len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      enterprise-number1       |
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   data-len1   |               |
   +-+-+-+-+-+-+-+-+               |
   /      vendor-class-data1       /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
   |      enterprise-number2       |   ^
   |                               |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   |   data-len2   |               | не обязательно
   +-+-+-+-+-+-+-+-+               |   |
   /      vendor-class-data2       /   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   ~            ...                ~   V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----

option-code

OPTION_V-I_VENDOR_CLASS (124).

option-len

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

enterprise-numberN

32-битовое значение Enterprise Number производителя из реестра IANA [3].

data-lenN

Размер поля vendor-class-data.

vendor-class-dataN

Детали аппаратной конфигурации хоста, на котором работает клиент, или соответствия отраслевому консорциуму.

Эта опция содержит информацию, соответствующую одному или нескольким значениям Enterprise Number. Может присутствовать множество экземпляров опции, которые должны объединяться в соответствии с RFC 3396 [4]. Значению Enterprise Number следует присутствовать только один раз для всех экземпляров опции. При наличии множества Enterprise Number поведение становится неопределенным. Информация для каждого Enterprise Number трактуется независимо от ее использования с другими Enterprise Number или в отдельной опции.

Поле vendor-class-data представляет собой последовательность отдельных элементов, каждый из которых описывает некоторые характеристики аппаратной конфигурации или возможностей клиента. Примеры экземпляров vendor-class-data могут включать версию операционной системы клиента, объем памяти, доступной клиенту, и т. п.

Каждый экземпляр vendor-class-data имеет показанный ниже формат.

                        1 1 1 1 1 1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   data-len    |               |
   +-+-+-+-+-+-+-+-+  opaque-data  |
   /                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Однооктетное поле data-len указывает размер данных vendor class, использующих сетевой порядок байтов.

4. Опция Vendor-Identifying Vendor-Specific Information

Клиенты и серверы DHCP могут использовать эту опцию для обмена данными конкретного производителя. При необходимости опцию может передавать каждая из сторон. Хотя обычно клиент передает опцию Vendor-Identifying Vendor Class для получения полезной ему опции Vendor-Identifying Vendor-Specific Information, это не обязательно.

Опция может включаться в любой пакет, для которого RFC 2131 [2] разрешает «прочие» опции (в частности, DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK и DHCPINFORM).

Формат опции V-I Vendor-specific Information показан ниже.

                        1 1 1 1 1 1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  option-code  |  option-len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      enterprise-number1       |
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   data-len1   |               |
   +-+-+-+-+-+-+-+-+ option-data1  |
   /                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
   |      enterprise-number2       |   ^
   |                               |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   |   data-len2   |               | не обязательно
   +-+-+-+-+-+-+-+-+ option-data2  |   |
   /                               /   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   ~            ...                ~   V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----

option-code

OPTION_V-I_VENDOR_OPTS (125).

option-len

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

enterprise-numberN

32-битовое значение Enterprise Number производителя из реестра IANA [3].

data-lenN

Размер поля option-data.

option-dataN

Фирменные опции производителя, описанные ниже.

Определение информации, передаваемой в этой опции, зависит от производителя, который указывается полем enterprise-number. Опция содержит информацию, соответствующую одному или нескольким значениям Enterprise Number. Может присутствовать множество экземпляров опции, которые должны объединяться в соответствии с RFC 3396 [4].

Значение Enterprise Number следует включать лишь один раз для всех экземпляров опции. При наличии нескольких Enterprise Number поведение становится неопределенным. Информация для каждого Enterprise Number трактуется независимо от ее использования с другими Enterprise Number или в отдельной опции.

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

Инкапсулированное поле option-data должно кодироваться последовательностью полей код-размер-значение, идентичной формату поля опций DHCP. Коды опций, определенные производителем, идентифицируются полем enterprise-number и не контролируются агентством IANA. Коды 0 и 255 не имеют специального значения. Каждая из инкапсулированных опций использует показанный ниже формат.

                        1 1 1 1 1 1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  subopt-code  |  subopt-len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /        sub-option-data        /
   /                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

subopt-code

Код инкапсулированной опции.

subopt-len

Целое число без знака, указывающее размер поля option-data данной инкапсулированной опции в октетах.

sub-option-data

Область данных инкапсулированной опции.

5. Взаимодействие с IANA

Значения кодов опций OPTION_V-I_VENDOR_CLASS и OPTION_V-I_VENDOR_OPTS выделены из пространства, определенного для опций DHCP в RFC 2939 [7].

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

Этот документ не связан с обеспечением безопасности и не влияет на уровень защиты. Протокол DHCP поддерживает механизмы проверки подлинности и защиты целостности сообщений, описанные в RFC 3118 [8], которые могут использоваться для аутентификации данных, передаваемых в описанных здесь опциях.

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

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

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

[2] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, March 1997.

[3] IANA, «Private Enterprise Numbers», <http://www.iana.org/assignments/enterprise-numbers>.

[4] Lemon, T. and S. Cheshire, «Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)», RFC 3396, November 2002.

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

[5] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, March 1997.

[6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 3315, July 2003.

[7] Droms, R., «Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types», BCP 43, RFC 2939, September 2000.

[8] Droms, R. and W. Arbaugh, «Authentication for DHCP Messages», RFC 3118, June 2001.

[9] <http://www.cablelabs.com/>

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

Josh Littlefield

Cisco Systems, Inc.

1414 Massachusetts Avenue

Boxborough, MA 01719

USA

Phone: +1 978-936-1379

EMail: joshl@cisco.com

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

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

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

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

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

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

1Dynamic Host Configuration Protocol — протокол динамической настройки конфигурации хоста.

Рубрика: RFC | Комментарии отключены

RFC 3879 Deprecating Site Local Addresses

Опубликовано 29.09.2004 автором Nikolai Malykh

Network Working Group                                         C. Huitema
Request for Comments: 3879                                     Microsoft
Category: Standards Track                                   B. Carpenter
                                                                     IBM
                                                          September 2004

Отмена адресов Site Local

Deprecating Site Local Addresses

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

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

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

Аннотация

Этот документ рассматривает вопросы использования индивидуальных адресов IPv6 site-local в их исходной форме и формально отменяет их применение. Данная отмена не запрещает продолжение их использования до момента стандартизации и реализации замены.

1. Введение

В течение некоторого времени рабочая группа IPv6 занималась обсуждением множества вопросов, связанных с использованием локальных для сайта (site local) адресов. На заседании в марте 2003 года группа достигла определенного соглашения по этим вопросам в части замены таких адресов в их предложенной изначально форме. Хотя единодушия по этому вопросу не было достигнуто, на заседании в июле 2003 года рабочая группа подтвердила необходимость документирования этих проблем и последующего принятия решения об отказе от использования индивидуальных адресов IPv6 site-local.

Локальные для сайта адреса были определены в архитектуре адресации IPv6 [RFC3513] (параграф 2.5.6).

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

Цели такой отмены и решения по замене адресов будут описаны в дополнительных документах. Однако формальный отказ не отменяет применение ранее развернутых адресов site-local до момента стандартизации и реализации замены.

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

2. Негативные эффекты адресов Site Local

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

Как было отмечено, адресация site local не обеспечивает однозначности — адреса типа FEC0::1 могут присутствовать на множестве сайтов, а сам адрес не содержит какой-либо индикации сайта, к которому он относится. Это создает проблемы для разработчиков приложений и маршрутизаторов, а также сетевых администраторов. Проблема связана с нечеткостью определения сайта. Более подробное рассмотрение этого вопроса будет приведено ниже.

2.1. Проблема разработчиков — область действия идентификаторов

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

Приложение может узнать или вспомнить, что некий корреспондент использует адрес FEC0::1234:5678:9ABC, а потом попытаться поместить такой адрес в структуру адреса сокета и организовать соединение. Такая попытка завершится отказом, поскольку не будет задана переменная site identifier, как в FEC0::1234:5678:9ABC%1 (использование символа % в качестве разделителя для идентификатора зоны задано в [SCOPING]). Проблема усугубляется тем, что идентификатор сайта меняется в зависимости от конкретизации хоста (например, может быть %1 или %2), что не позволяет сохранить идентификатор хоста в памяти или узнать у сервера имен.

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

2.2. Проблема разработчиков — локальная адресация

Простые приложения клиент-сервер с разделяемым адресом IP на прикладном уровне усложняются при использовании адресации IPv6 site-local. Эти приложения должны будут принимать интеллектуальные решения в части прохождения адресов через границу сайта. На практике для решения таких вопросов приложениям потребуется информация о топологии сети. Локальные для сайта адреса могут быть применены для случаев, когда клиент и сервер размещаются на одном сайте, но попытки использовать их для разнесенных между сайтами клиентов и серверов будут заканчиваться неожиданными ошибками (например, сбросом соединения партнером) или организаций соединений не с тем узлом. Отказоустойчивость и безопасность при отправке пакетов неизвестному хосту может существенно меняться от приложения к приложению.

Приложения с множеством участников (Multi-party), которые передают адреса IP на прикладном уровне, сталкиваются с особой проблемой. Даже если узел может корректно определить место нахождения удаленного узла (на этом же или другом сайте), он не сможет узнать по какому адресу нужно отправлять пакеты для него. Наилучшим выходом для таких приложений может оказаться переход на использование только глобальных адресов. Однако это будет препятствовать использованию таких приложений в изолированных и периодически подключаемых сетях, для которых доступны только адреса site-local, и может приводить к несовместимости с использованием в некоторых случаях адресов site-local для контроля доступа.

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

2.3. Проблема администраторов — утечки

Поддержка локальных для сайта адресов IPv6 во многих случаях проще работы с приватными блоками адресов RFC 1918 [RFC1918] в некоторых сетях IPv4. Теоретически, адреса, определенные в RFC 1918 должны использоваться только локально и не появляться в сети Internet. На практике такие адреса «утекают» в публичные сети. Комбинация утечек и неоднозначностей будет вызывать проблемы управления сетями.

Имена и адреса хостов приватных сетей могут «утекать» в почтовых сообщениях, web-страницах или файлах. Использование приватных адресов в полях отправителя или получателя запросов TCP или сообщений UDP (например, DNS или traceroute) будут приводить к отказам или доставке откликов на совершенно другие хосты.

Опыт использования адресов RFC 1918 показал также некоторые нетривиальные утечки в дополнение к приватным адресам в заголовках. Приватные адреса могут указываться также реверсных запросах DNS, которые будут создавать бесполезную загрузку инфраструктуры DNS. В общем случае многие приложения, использующие адреса IP напрямую, будут в конечном итоге приводить к путаницам и отказам.

Утечки вряд ли можно предотвратить. В то время, как некоторые приложения по своей природе имеют ограниченную область действия (например, Router Advertisement, Neighbor Discovery), большинство приложений не имеет таких концептуальных ограничений. В результате происходят утечки через границы (stuff leaks across the borders). Неоднозначность локальной для сайта адресации будет препятствовать поиску причин утечек. В результате утечки становятся трудно уловимыми, что вызывает разочарование администраторов.

2.4. Проблема маршрутизаторов — рост сложности

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

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

Неоднозначность адресации имеет очевидные проявления на многосайтовых маршрутизаторах. В классической архитектуре маршрутизации выходной интерфейс непосредственно определяется адресом получателя в соответствии с единой таблицей маршрутизации. Однако для маршрутизатора, соединенного с несколькими сайтами, маршрутизация пакетов с локальными для сайта адресами зависит также от интерфейса, через который пакет был принят. Интерфейсы связываются с сайтами и маршрутные записи для адресов site-local становятся зависимыми от сайта. Поддержка такой возможности требует реализации специальных функций в протоколах маршрутизации с методов виртуализации таблиц маршрутизации и пересылки, которые обычно применяются для VPN. Это создает дополнительные сложности при реализации и обслуживании маршрутизаторов.

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

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

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

2.5. Определение сайта

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

За пределами локального канала (link-local) границы области действия определены достаточно плохо. Что такое сайт? Является ли сайтом корпоративная сеть в целом или сайты должны быть территориально локализованы? Многие современные сети разделены на внутреннюю часть и внешнюю ДМЗ¹, отделенную межсетевым экраном. Серверы в ДМЗ доступны как из внутренней сети, так и для хостов Internet. Относятся ли хосты ДМЗ и внутренней сети к одному сайту?

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

Имеются хорошо известные и важные случаи, когда основанный на областях действия подход не будет работать, — сети, не соединенные напрямую, мобильные узлы, мобильные сети, междоменные VPN, сети с использованием хостинга, случаи слияния или разделения сетей и т. п. В частности, это означает, что «область действия» (scope) невозможно отобразить концентрическими кругами, как в примитивной модели канал/локальный/глобальный (link/local/global). Области могут перекрываться или проникать одна в другую. Принадлежность пары хостов к одной области может даже отличаться для разных протоколов.

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

3. Разработка более эффективного решения

В предыдущем разделе приведены аргументы против локальных для сайта (site-local) адресов. Тем не менее, очевидны и некоторые преимущества такой адресации, без которых такие адреса были бы уже давно удалены из спецификации. Преимуществом таких адресов является простота, стабильность и частных характер распределения. Однако такие преимущества могут быть достигнуты и при использовании иной архитектуры. Примером может служить [Hinden/Haberman], где адреса не содержат неоднозначностей и не имеют явной области действия.

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

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

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

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

Остается вопрос anycast-адресации. Такие адреса являются неоднозначными по своему устройству, поскольку они относятся, по определению, ко всем хостам, которым был присвоен данный адрес anycast. Локальные для канала или глобальные адреса могут оказаться «впечатанными» в программный код. Нужны дополнительные исследования необходимости использования адресов anycast с областью действия между локальной для канала и глобальной.

4. Отказ от применения

Этот документ формально отменяет использование префикса локальных для сайта (site-local) индивидуальных адресов IPv6, определенного в [RFC3513], как 1111111011 или FEC0::/10. Специальная обработка для этого префикса должна быть исключена из новых реализаций. Префикс недопустимо выделять для иного применения до того, как он будет заново стандартизован IETF. Новые версии архитектуры адресации [RFC3513] будут включать эту информацию.

Реализации маршрутизаторов следует настраивать для отказа от маршрутизации этого префикса по умолчанию.

Упоминания локальных для сайта адресов следует удалить из новых версий документов Default Address Selection for Internet Protocol version 6 [RFC3484], Basic Socket Interface Extensions for IPv6 [RFC3493] и Internet Protocol Version 6 (IPv6) Addressing Architecture [RFC3513]. Имеющиеся упоминания локальных адресов следует удалить из новых версий других документов IETF при их обновлении. Такие документы включают [RFC2772, RFC2894, RFC3082, RFC3111, RFC3142, RFC3177, RFC3316].

Существующие реализации и развернутые системы могут продолжать использование этого префикса.

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

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

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

6. Взаимодействие с IANA

Агентству IANA направлен запрос на маркировку префикса FEC0::/10, как отмененного (deprecated) со ссылкой на данный документ. Последующее использование этого префикса для тех или иных целей потребует прохождения процедуры стандартизации (IETF Standards Action) [RFC2434].

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

Авторы благодарны Fred Templin, Peter Bieringer, Chirayu Patel, Pekka Savola и Alain Baudot за обзор начальной версии документа. Текст параграфа 2.2 включает два абзаца из версии Margaret Wasserman, описывающие влияние локальной для сайта адресации. Alain Durand указал на необходимость пересмотра существующего RFC со ссылками на локальные для сайта адреса.

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

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

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

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

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

8.2. Информационные ссылки

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[RFC2772] ockell, R. and R. Fink, «6Bone Backbone Routing Guidelines», RFC 2772, February 2000.

[RFC2894] Crawford, M., «Router Renumbering for IPv6», RFC 2894, August 2000.

[RFC3082] Kempf, J. and J. Goldschmidt, «Notification and Subscription for SLP», RFC 3082, March 2001.

[RFC3111] Guttman, E., «Service Location Protocol Modifications for IPv6», RFC 3111, May 2001.

[RFC3142] Hagino, J. and K. Yamamoto, «An Ipv6-to-IPv4 Transport Relay Translator», RFC 3142, June 2001.

[RFC3177] IAB and IESG, «IAB/IESG Recommendations on Ipv6 Address», RFC 3177, September 2001.

[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, «Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts», RFC 3316, April 2003.

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

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

[Hinden/Haberman] Hinden, R. and B. Haberman, «Unique Local Ipv6 Unicast Addresses», Work in Progress, June 2004.

[SCOPING] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, «IPv6 Scoped Address Architecture», Work in Progress, August 2004.

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

Christian Huitema

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052-6399

USA

EMail: huitema@microsoft.com

Brian Carpenter

IBM Corporation

Sauemerstrasse 4

8803 Rueschlikon

Switzerland

EMail: brc@zurich.ibm.com

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

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

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

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

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

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

1«Демилитаризованная» зона.

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

Рубрика: RFC | Комментарии отключены

RFC 3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)

Опубликовано 17.09.2004 автором Nikolai Malykh

Network Working Group                                   X. Xiao, Ed.
Request for Comments: 3916                       Riverstone Networks
Category: Informational                            D. McPherson, Ed.
                                                      Arbor Networks
                                                        P. Pate, Ed.
                                                   Overture Networks
                                                      September 2004

Требования к сквозной эмуляции псевдопровода (PWE3)

Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)

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

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

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

Аннотация

В это документе описываются базовые требования для PWE3¹, разработанные группой PWE3 WG. Документ включает рекомендации для других рабочих групп, занимающихся определением механизмов эмуляции псевдопроводов для сетей Ethernet, ATM и Frame Relay. Требования к эмуляции псевдопроводов для (синхронных битовых потоков, определенный в спецификации ITU G.702) рассматриваются в отдельном документе². Следует отметить, что рабочая группа PWE3 занимается стандартизацией механизмов, которые могут использоваться для обеспечения сервиса PWE3, но не сервисом, как таковым.

Оглавление

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

1. Введение

1.1. Что такое псевдопровод?

Эмуляция сквозного псевдопровода (PWE3) представляет собой механизм эмуляции существенных атрибутов различных типов сетевого сервиса (ATM, Frame Relay или Ethernet) через сети с коммутацией пакетов (PSN³). Обязательные функции псевдопровода PW включают инкапсуляцию обусловленных типом сервиса PDU⁴, получаемых входным портом и передачу их через путь или туннель с обеспечением синхронизации, порядка доставки и иных операций, требуемых для эмуляции поведения и характеристик сервиса с максимально возможной полнотой.

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

1.2. Современная архитектура сетей

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

1.2.1. Множество разнотипных сетей

У любого, предоставляющего различные типы услуг сервис-провайдера, сетевая инфраструктура обычно включает “параллельные” или перекрывающиеся сети. Каждая из таких сетей поддерживает свой тип сервиса (например, Frame Relay, доступ в Internet и т. п.). Такое решение ведет к увеличению расходов как на приобретение оборудования, так и на его обслуживание. Кроме того, наличие множества разнотипных сетей усложняет планирование и управление. У сервис-провайдеров возникают естественные вопросы:

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

Конвергенция поможет сервис-провайдерам ответить на все эти вопросы и обеспечить согласованное и экономичное развитие сети.

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

Для повышения эффективности инвестиций и снижения эксплуатационных расходов сервис-провайдеры зачастую стараются использовать одну сетевую технологию для доставки различных типов сервиса.

Поскольку пакетный трафик занимает все большую часть доступной полосы сетей, растет целесообразность перевода сетей общего пользования на протоколы IP. Однако многие сервис-провайдеры сталкиваются с проблемами при развертывании оптимизированных для передачи пакетов сетей. Хотя трафик Internet и является наиболее быстро расширяющимся по объему, на сегодняшний день он не является преобладающим. Например, трафик Frame Relay по-прежнему имеет суммарный объем, превышающий объем естественного трафика IP. А частные каналы TDM обеспечивают трафик, который по своему уровню превосходит трафик Frame Relay. Кроме того, в сетях общего пользования имеется огромное количество старого оборудования, которое не способно работать по протоколу IP. Сервис-провайдеры продолжают использовать не поддерживающее IP оборудование для различных типов сервиса и возникает необходимость сопряжения такого оборудования с оптимизированными для передачи трафика IP сетями.

1.3. PWE3 как путь сближения

Как сервис-провайдеры могут реализовать свои преимущества в новых инфраструктурах, оптимизированных для передачи пакетов, и продолжить использование установленного оборудования с сохранением трафика, передаваемого через это оборудование? Как они могут перейти от сетей Frame Relay или ATM, не нарушая работу существующих типов сервиса?

Одним из вариантов является эмуляция устройств или служб с использованием псевдопроводов (PW). Эмуляция устройств в сетях ATM и взаимодействие между сетями Frame Relay и ATM уже стандартизованы. Эмуляция позволяет передавать трафик существующих типов сервиса через новую инфраструктуру и, таким образом, обеспечивает возможность взаимодействия разнородных сетей.

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

1.4. Приложения, подходящие для PWE3

Что делает приложение подходящим (или неподходящим) для использования с PWE3? При рассмотрении PW как основы для реализации приложений следует получить ответы на приведенные ниже вопросы:

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

Если на все 4 вопроса дан положительных ответ, это приложение подходит для PWE3. В остальных случаях требуется более внимательный учет требований пользователей, сервис-провайдеров, производителей оборудования и сетевых технологий.

1.5. Резюме

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

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

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

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

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

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

Физическое или виртуальное устройство, обеспечивающее подключение CE к PE. В качестве AC может выступать Frame Relay DLCI, ATM VPI/VCI, порт Ethernet, VLAN, канал HDLC, соединение PPP на физическом интерфейсе, сессия PPP через туннель L2TP, MPLS LSP и т. п.

Customer Edge (CE) – пользовательский край

Устройство, на котором сервис начинается или завершается. Для CE не имеет значения используется эмулируемый естественный сервис.

Packet Switched Network (PSN) – сеть с коммутацией пакетов

В контексте PWE3 это сеть, использующая IP или MPLS в качестве механизма пересылки пакетов.

Provider Edge (PE) – провайдерский край

Устройство, обеспечивающее PWE3 для CE.

Pseudo Wire (PW) – псевдопровод

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

Pseudo Wire Emulation Edge to Edge (PWE3) – сквозная эмуляция псевдопровода

Механизм, эмулирующий значимые атрибуты сервиса (например, выделенные каналы T1 или Frame Relay) через сеть PSN.

Pseudo Wire PDU – модуль данных псевдопровода

Протокольный модуль данных (PDU⁵), передаваемый в PW и содержащий все данные и управляющую информацию, требуемые для эмуляции сервиса.

PSN Tunnel – туннель PSN

Туннель через сеть PSN, внутри которого поддерживается один или несколько PW.

                    |<------- Pseudo Wire ------>|
                    |                            |
                    |    |<-- PSN Tunnel -->|    |
                    V    V                  V    V
                    +----+                  +----+
   +-----+          | PE1|==================| PE2|          +-----+
   |     |----------|............PW1.............|----------|     |
   | CE1 |          |    |                  |    |          | CE2 |
   |     |----------|............PW2.............|----------|     |
   +-----+  ^       |    |==================|    |          +-----+
         ^  |       +----+                  +----+          ^
         |  |   Provider Edge 1         Provider Edge 2     |
         |  |                                               |
         | Attachment Circuit                               |
         |                                                  |
         |<-------------- Emulated Service ---------------->|

   Customer                                                 Customer
    Edge 1                                                   Edge 2

Рисунок 1: Эталонная модель PWE3

3. Эталонная модель PWE3

Псевдопровод (PW) представляет собой соединение между устройствами провайдерского края (PE), к которым подключены два AC. В качестве AC могут использоваться Frame Relay DLCI, ATM VPI/VCI, порт Ethernet, VLAN, канал HDLC, соединение PPP на физическом интерфейсе, сессия PPP через туннель L2TP, MPLS LSP и т. п.

В процессе организации PW два устройства PE будут настроены вручную или автоматически согласуют параметры эмулируемого сервиса, что позволит впоследствии корректно обрабатывать пакеты, поступающие с другого конца псевдопровода. После организации PW между парой PE кадры, полученные одним из PE от AC, инкапсулируются и передаются через PW удаленному PE, где восстанавливаются естественные для данного сервиса кадры и передаются в устройство CE. Детальное описание архитектуры PWE3 приведено в документе [PWE3_ARCH].

В этом документе не используется допущений о природе PW (например, сессия [L2TPv3], [MPLS] LSP) или PSN (например, IP или MPLS). Вместо этого описываются базовые требования, которые применимы ко всем типам PW и PSN для всех эмулируемых служб, включая Ethernet, ATM, Frame Relay и т. д.

4. Обработка пакетов

В этой главе описаны требования PWE3 в части данных.

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

Каждое устройство PE должно обеспечивать механизм инкапсуляции PDU от AC. Следует отметить, что инкапсулируемые PDU могут включать или не включать заголовки канального уровня (L2) – это зависит от типа сервиса. Каждый сервис PWE3 должен указывать что собой представляет PDU.

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

Конкретные требования к инкапсуляции PDU рассматриваются ниже.

4.1.1. Передача требуемой информации из заголовков канального уровня

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

4.1.2. Поддержка переменного размера PDU

Реализации PWE3 должны поддерживать PDU переменной длины, если такие PDU поддерживаются исходным сервисом. Например, от PWE3 для Frame Relay требуется поддержка переменного размера кадров.

4.1.3. Поддержка мультиплексирования и демультиплексирования

Если исходный сервис может группировать множество устройств (соединений) в “транк” (например, объединение ATM VCC в VPC или поддержка на одном порту множества интерфейсов Ethernet 802.1Q), следует обеспечивать какие-либо механизмы, позволяющие использовать один PW для соединения двух транковых устройств. С точки зрения инкапсуляции должна передаваться информация, достаточная для того, чтобы PW на приемной стороне мог демультиплексировать отдельные устройста (соединения).

4.1.4. Проверка корректности PW-PDU

Большинство кадров L2 имеют поле контрольной суммы для проверки целостности кадра. Каждый сервис PWE3 должен указывать требуется ли сохранение контрольных сумм кадров при передаче через PW или контрольные суммы могут исключаться на входном PE и заново рассчитываться на выходном PE. Для протоколов типа ATM и FR контрольные суммы включают данные канального уровня (идентификаторы устройств — FR DLCI или ATM VPI/VCI). Следовательно, такие контрольные суммы должны исключаться на входном PE и заново рассчитываться на выходе.

4.1.5. Доставка информации о типе данных

В некоторых случаях желательно отличать трафик PW от других типов трафика (например, IPv4, IPv6 или OAM). В частности, при использовании ECMP⁶ в сети PSN такое различие может использоваться для снижения вероятности нарушения порядка доставки пакетов PW при использовании механизмов распределения нагрузки. При необходимости следует обеспечивать какой-либо механизм поддержки таких различий. Такие механизмы могут определены рабочей группой PWE3 или другими группами.

4.2. Порядок доставки кадров

Когда пакеты, содержащие PW PDU проходят через PW, порядок их доставки может нарушаться. Для некоторых типов сервиса требуется сохранение порядка доставки кадров (это может относиться только к кадрам управления или ко всем кадрам). В таких случаях должен обеспечиваться тот или иной механизм обеспечения упорядоченной доставки. Одним из вариантов решения этой задачи может служить включение порядковых номеров в заголовки PW, что позволит детектировать нарушение порядка на приемной стороне. Механизм восстановления нарушенного порядка может обеспечиваться NSP-обработкой⁷ [PWE3_ARCH], но этот вопрос выходит за рамки PWE3.

4.3. Дублирование кадров

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

4.4. Фрагментация

Если суммарный размер данных L2 и связанных с ними заголовков PWE3 и PSN превосходит значение MTU на пути через PSN, может возникнуть необходимость фрагментации данных L2 (в противном случае кадр L2 может быть отброшен на пути). Для некоторых типов сервиса фрагментация может потребоваться также для сохранения относительной позиции управляющего кадра среди кадров данных (например, относительное положение ячеек ATM PM). В общем случае фрагментация оказывает влияние на производительность и, следовательно, фрагментации следует избегать по возможности. Однако для отдельных типов сервиса требования фрагментации могут быть иными. Для случаев, когда фрагментация необходима, документ PWE3 для соответствующего типа сервиса должен указывать следует ли отбрасывать кадр или фрагментировать его. Если эмулируемый сервис выбирает для кадра отбрасывание, это должно быть указано в заявлении о применимости.

4.5. Объединение PDU для снижения объема служебного трафика

Когда размер L2 PDU мал, для снижения загрузки туннеля PSN можно объединять множество PDU перед тем, как в пакет будет добавлен заголовок туннеля PSN. Каждый инкапсулированный PDU по-прежнему содержит свой заголовок PW, поэтому PE на выходе знает как обрабатывать данные. Однако при объединении PDU следует принимать во внимание рост задержек и их флуктуаций (jitter), а также влияние потери пакетов.

5. Обслуживание эмулируемого сервиса

В этой главе рассматриваются требования по обслуживанию PWE3.

5.1. Организация и разрыв псевдопроводных соединений

Псевдопроводное соединение PW должно быть организовано до того, как будет использоваться эмулируемое устройство, и должно разрываться после того, как необходимость использования эмулируемого устройства отпадет. Организация и разрыв PW могут инициироваться командами из системы управления PE, командами Setup/Teardown со стороны AC (например, ATM SVC) или с помощью механизмов автоматического детектирования.

В каждой реализации PWE3 должен быть определен тот или иной механизм организации PW. В процессе установки соединения PE требуется обмен той или иной информацией (например, определение возможностей удаленной стороны). Механизм организации соединения должен обеспечивать устройствам PE способ обмена всей необходимой информацией. Например, обе конечные точки должны согласовать методы инкапсуляции PDU и поддержки упорядоченной доставки кадров. Выбор сигнального протокола и передаваемой информации зависит от типа сервиса. Каждая реализация PWE3 должна указывать это. Ручная настройка PW может рассматриваться как специальный случай организации соединений.

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

5.2. Обработка управляющих сообщений исходного сервиса

Некоторые типы сервиса в естественной форме поддерживают те или иные механизмы, используемые для обслуживания (например, ATM OAM или FR LMI). Служебные сообщения этих механизмов могут передаваться в основной полосе (т. е, помещаться вместе с данными в одном AC) или по отдельному каналу (например, с использованием выделенного для управления устройства). Для таких служб все передаваемые в основной полосе управляющие сообщения следует также передавать в основной полосе так же, как данные, с использованием соответствующего PW на удаленное устройство CE. Иными словами, для передаваемых в основной полосе управляющих сообщений не требуется трансляции в устройствах PE. Кроме того, может оказаться желательным обеспечения максимальной надежности доставки управляющих сообщений. Механизмы обеспечения высокой надежности доставки не определяются рабочей группой PWE3.

Управляющие сообщения, передаваемые по отдельному каналу между CE и PE могут относиться к различным AC между данной парой CE PE. Эти сообщения должны обрабатываться на локальном PE, а в некоторых случаях и на удаленном PE. Если в естественной форме сервиса используются те или иные управляющие сообщения, передаваемые по отдельному каналу, соответствующий эмулируемый сервис должен указать способы обработки таких сообщений в устройствах PE. В общем случае такие сообщения транслируются в in-band-сообщения естественного сервиса или определяемые PWE управляющие сообщения для каждого AC, связанного с данным сообщением, типа out-of-band. Для примера предположим, что некоторые AC между CE и PE используют ATM VCC в VPC. При получении F4 AIS [UNI3.0] от CE устройству PE следует транслировать F4 AIS с F5 AIS и передать сообщение удаленному CE для каждого VCC. В качестве альтернативного варианта PE следует генерировать определяемое PWE управляющее сообщение (например, аннулирование метки) удаленному PE для каждого VCC. Когда удаленное устройство PE получает такое сообщение может потребоваться генерация управляющего сообщения для естественного сервиса и передача этого сообщения подключенному CE.

5.3. Инициированные PE управляющие сообщения

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

Причина, по которой от PE требуется генерация сообщений при возникновении отказов, обусловлена тем, что наличие PW между парой CE будет существенно снижать возможности CE в части обслуживания. Пример подобной ситуации показан на рисунке. Если два CE соединены напрямую проводами, естественный сервис (например, ATM) может использовать уведомления от нижележащего уровня (например, уровня физического канала) для обслуживания. Например, ATM PVC может передавать сигнал Down при повреждении физического канала. Рассмотрим теперь несколько иную ситуацию.

   +-----+ Phy-link +----+              +----+ Phy-link +-----+
   | CE1 |----------| PE1|......PW......|PE2 |----------| CE2 |
   +-----+          +----+              +----+          +-----+

Если происходит отказ в PW между PE1 и PE2, устройства CE1 и CE2 не будут получать уведомлений о повреждении физического канала. В результате этого они не смогут своевременно объявить об отказе в эмулируемом устройстве приложениям вышележащих уровней. Следовательно, при отказе PW устройствам PE1 и PE2 необходимо инициировать передачу служебных сообщений, уведомляющих клиентский уровень CE1 и CE2, использующих данный PW как серверный уровень (в этом случае клиентским уровнем является эмулируемый сервис). Если происходит повреждение физического канала между PE1 и CE1, устройство PE1 должно инициировать передачу некого служебного сообщения (или сообщений), которые будут уведомлять клиентский уровень CE2. Устройство PE2 также может быть вовлечено в процесс генерации служебных сообщений.

В редких случаях, когда в физическом соединении между CE возникает множество битовых ошибок, для физического соединения может декларироваться состояние Down с уведомлением клиентского уровня устройств CE. В псевдо-соединениях PW может происходить потеря пакетов, их повреждение или нарушение порядка доставки. Такие события могут рассматриваться как «обобщенные битовые ошибки⁸» с декларированием для PW состояния Down и детектированием для PE необходимости генерации служебного сообщения, уведомляющего клиентский уровень CE.

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

условий, при которых требуется генерация служебных сообщений по инициативе PE;
формата служебных сообщений;
способов обработки служебных сообщений на удаленном PE.

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

Статус группы эмулируемых устройств может быть изменен в результате одного сетевого инцидента. Например, при отказе физического канала между CE и PE все эмулируемые устройства, работающие через этот канал тоже откажут. Желательно, чтобы одно сообщение использовалось для уведомления всей группы эмулируемых устройств, соединенных с одним удаленным PE. Метод PWE3 может обеспечивать тот или иной механизм уведомления об изменении состояния группы эмулируемых устройств. Одним из возможных вариантов является связывание каждого эмулируемого устройства с идентификатором группы (group ID) при организации PW для этого эмулируемого устройства. В служебном сообщении этот идентификатор группы может служить для указания на все эмулируемые устройства данной группы.

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

Приведенные в этой главе требования согласованы с философией управления ITU-T для телекоммуникационных сетей [G805] (т. е., с концепцией уровень клиента/уровень сервера).

6. Управление эмулируемыми службами

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

6.1. Базы MIB

Должны обеспечиваться базы SNMP MIB [SMIV2] для управления каждым эмулируемым устройством, а также псевдопроводом в целом. Эти базы MIB следует создавать с учетом приведенных ниже требований.

6.2. Общие требования к MIB

Новые базы MIB должны добавлять или расширять, когда это применимо, существующие таблицы, как определено в других, связанных с сервисом MIB для существующих типов сервиса таких, как MPLS или L2TP. Например, ifTable, как определено в Interface MIB [IFMIB] должна быть дополнена для поддержки учета пакетов, доставленных с нарушением порядка. Другим примером может служить расширение MPLS-TE-MIB [TEMIB] для эмуляции устройств через MPLS. Например, вместо того, чтобы переопределять tunnelTable для обеспечения устройствам PWE возможности использовать туннели MPLS, записи этой таблицы должны быть расширены для добавления связанных с PWE объектов. Еще одним примером может служить расширение IP Tunnel MIB [IPTUNMIB] таким способом, чтобы обеспечить связанную с PWE3 семантику при использовании отличного от MPLS транспорта для PSN. Такой подход упрощает естественное расширение объектов, определенных в существующих MIB с точки зрения управления, а также взаимодействие с существующими реализациями агентов управления.

Устройства подключения (AC) должны появляться как интерфейсы в таблице ifTable.

6.3. Настройка и обслуживание

Таблицы MIB должны быть разработаны с целью облегчения настройки конфигурации и обслуживания AC.

Базы MIB должны облегчать настройку и мониторинг AC внутри PSN.

6.4. Мониторинг производительности

Базы MIB должны собирать статистику производительности и данных об отказах.

Базы MIB должны содержать описание использования существующих счетчиков для эмуляции PW. Имеющиеся счетчики не следует заменять.

6.5. Контроль отказов и уведомления о них

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

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

6.6. Проверка и трассировка псевдопроводных соединений

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

7. Недостатки эмулируемых служб

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

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

7.1. Характеристики эмулируемого сервиса

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

Должна обеспечиваться возможность задать тип (например, Ethernet),наследуемый от естественного сервиса, скорость(например, 100 Мбит/с) и размер MTU для эмулируемого устройства, если это возможно для естественного устройства.
Если две конечных точки (CE1 и CE2) эмулируемого устройства #1 соединены с PE1 и PE2, соответственно, а точки CE3 и CE4 эмулируемого устройства #2 также соединены с PE1 и PE2, тогда PW этих двух эмулируемых устройств могут использовать один и тот же физический путь между PE1 и PE2. Но с точки зрения каждого из CE эмулируемое устройство должно представляться выделенным (unshared). Например, пара CE1/CE2 не должна знать о существовании эмулируемого устройства #2 или CE3/CE4.
При отказе в эмулируемом устройстве (на одной из ACs или в средней части PW) оба CE должны быть уведомлены своевременно, если такие уведомления поддерживаются для естественного сервиса (см. параграф 5.3). Трактовка понятия “своевременность” зависит от типа сервиса.
Если естественное устройство позволяет организовать отношения смежности для протокола маршрутизации (например, IGP), должна обеспечиваться возможность организации таких же отношений через эмулируемое устройство.

7.2. Качество обслуживания для эмулируемого сервиса

От эмулируемых устройств не требуется обеспечение такого же качества сервиса, который присущ естественным устройствам. Рабочая группа PWE3 лишь определяет механизмы эмуляции PW, но не сами эмулируемые типы сервиса. Уровень сервиса, достаточный для поддержки тех или иных эмулируемых служб между сервис-провайдером (SP) и его пользователями определяется этими сторонами и не входит в число задач рабочей группы PWE3.

8. Что не относится к числу требований

В различных частях этого документа обозначены некоторые характеристики (аспекты), которые не являются требованиями к эмулируемомму сервису. Эти аспекты не входят в число задач рабочей группы PWE3. Краткий перечень таких вопросов приведен ниже:

межсетевое взаимодействие⁹;
В межсетевом взаимодействии IWF (Interworking Function) между двумя непохожими протоколами (например, ATM и MPLS, Frame Relay и ATM, ATM и IP, ATM и L2TP и т. п.) прерывает действие используемого в одной сети протокола и транслирует (т. е., отображает) управляющие данные PCI¹⁰ в данные PCI того протокола, который используется в другой сети, для функций пользовательского, управляющего и контролирующего плана.
иыбор отдельных типов PW;
точное соответствие эмулируемых устройств их естественным аналогам;
определение механизмов сигнализации для туннелей PSN;
определение механизмов управления трафиком для пакетов, содержащих PW PDU;
обеспечение той или иной групповой адресации, которая не является естественной для эмулируемой среды.Например, передача кадров Ethernet по групповым адресам IEEE-48 входит в число рассматриваемых вопросов, тогда как групповая адресация типа [MARS] не входит в их число.

9. Качество обслуживания (QoS)

Некоторые службы в естественной форме (например, ATM) могут предлагать более высокое качество обслуживания, нежели доступный в сети Internet уровень best effort¹¹. Параметры QoS, следовательно, важны для того, чтобы эмулируемые услуги были совместимы (но не обязательно идентичны) с естественной их формой. Сетевые операторы сами определяют, как им обеспечивать QoS – они могут выбрать их с учетом имеющихся ресурсов и/или развернутых механизмов QoS.

Чтобы воспользоваться механизмами QoS, определенными другими рабочими группами (например, схемы управления трафиком, определенные группой DiffServ), желательно иметь некоторые механизмы, приводящие к дифференциации пакетов на основе инкапсуляции PDU. Эти механизмы не определены непосредственно в PWE3. Например, если получаемые в результате пакеты относятся к MPLS или IP, поля EXP или DSCP этих пакетов могут применяться для маркировки и дифференциации. PWE3 может включать рекомендации по маркировке и дифференциации.

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

10. Вопросы междоменного взаимодействия

Эмуляция PWE имеет значение для конечных точек PW и прозрачна для сетевых устройств между этими точками. Следовательно, междоменные PWE подобны внутридоменным PWE. Если конечные точки PW используют одну модель PWE, они могут эффективно взаимодействовать между собой, независимо от того, относятся эти точки к одному домену или к разным. Для междоменного взаимодействия могут стать более важными вопросы безопасности (например, может использоваться аутентификация конечных точек). При междоменном взаимодействии усложняется поддержка QoS, поскольку сервис-провайдеры не имеют сквозного контроля за трафиком и не могут изменять политику контроля трафика других провайдеров. Для решения задачи обеспечения QoS при междоменном взаимодействии требуется кооперация провайдеров. После того, как на уровне контракта будет достигнуто соглашение об обеспечении высокого качества обслуживания того или иного трафика (например, PWE), можно будет использовать механизмы. созданные другими рабочими группами (например, Diffserv).

Междоменные туннели PSN в общем случае сложнее с точки зрения организации, разрыва и поддержки, нежели туннели внутри домена. Но эта проблема относится к протоколам туннелирования PSN (таким, как MPLS и L2TPv3) и выходит за пределы PWE3.

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

Конечные устройства PW, механизмы демультиплексирования PW и данные естественного сервиса могут быть уязвимы для атак. PWE3 следует усиливать механизмы, обеспечиваемые демультиплексорами PW и уровнем PSN. Этим механизмам следует обеспечивать защиту конечных точек PW и механизмов демультиплексирования PW от атак на службы (DoS) и подмены модулей данных естественного сервиса. Предотвращение несанкционированного доступа к конечным точкам PW и другим сетевым устройствам в общем случае обеспечивает эффективную защиту от DoS-атак и подмены (spoofing), обеспечивая важный механизм защиты. Следует обеспечить также механизмы защиты от подмены туннелируемых данных PW. Проверка корректности трафика, адресованного конечной точкой мультиплексору PW является важной компонентой обеспечения целостности инкапсуляции PW. Могут использоваться протоколы защиты, типа [RFC2401].

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

Авторы выражают свою признательность M. Aissaoui, M. Bocci, S. Bryant, R. Cohen, N. Harrison, G. Heron, T. Johnson, A. Malis, L. Martini, E. Rosen, J. Rutemiller, T. So, Y. Stein, S. Vainshtein.

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

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

[IFMIB] McCloghrie, K. and F. Kastenholz, «The Interfaces Group MIB», RFC 2863, June 2000.

[SMIV2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

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

[G805] «Generic Functional Architecture of Transport Networks», ITU-T Recommendation G.805, 2000.

[IPTUNMIB] Thaler, D., «IP Tunnel MIB», RFC 2667, August 1999.

[L2TPv3] Lau, J., Townsley, M., and I. Goyret, et al., «Layer Two Tunneling Protocol (Version 3)», Work in Progress¹², June 2004.

[MARS] Armitage, G., «Support for Multicast over UNI 3.0/3.1 based ATM Networks», RFC 2022, November 1996.

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

[PWE3_ARCH] S. Bryant and P. Pate, et. al., «PWE3 Architecture», Work in Progress¹⁴, March 2004.

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

[TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, «Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)», RFC 3812, June 2004.

[UNI3.0] ATM Forum, «ATM User-Network Interface Specification Version 3.0», Sept. 1993.

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

XiPeng Xiao (редактор)

Riverstone Networks

5200 Great America Parkway

Santa Clara, CA 95054

EMail: xxiao@riverstonenet.com

Danny McPherson (редактор)

Arbor Networks

EMail: danny@arbor.net

Prayson Pate (редактор)

Overture Networks

507 Airport Boulevard, Suite 111

Morrisville, NC, USA 27560

EMail: prayson.pate@overturenetworks.com

Vijay Gill

AOL Time Warner

EMail: vijaygill9@aol.com

Kireeti Kompella

Juniper Networks, Inc.

1194 N. Mathilda Ave.

Sunnyvale, CA 94089

EMail: kireeti@juniper.net

Thomas D. Nadeau

Cisco Systems, Inc.

300 Beaver Brook Drive

Boxborough, MA 01719

EMail: tnadeau@cisco.com

Craig White

Level 3 Communications, LLC.

1025 Eldorado Blvd.

Broomfield, CO, 80021

EMail: Craig.White@Level3.com

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

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