В облаке MPLS маршруты определяются протоколом уровня L3. Чтобы улучшить рабочие характеристики сети эти маршруты могут быть преобразованы в пути уровня L2. Кроме этого, MPLS предлагает средства улучшения сетевых услуг, такие как QoS/CoS, управление трафиком и т.д.
Существующие уникастные протоколы маршрутизации формируют некоторый (оптимальный) кратчайший путь для определенной пары отправитель-получатель. Заметим, что уникастные протоколы могут работать по-разному в случае путей с эквивалентной метрикой. Для мультикастинга оптимальное решение (минимальная цена соединения N узлов) предполагает вычисление дерева Штайнера (Steiner). К сожалению, ни один современный мультикастный протокол маршрутизации не может сформировать такого дерева. Разные мультикастные протоколы формируют различные деревья.
Обсуждение в данном документе концентрируется на протоколах внутридоменной мультикастинг маршрутизации.


Документ RFC 822, который прослужил без малого 20 лет, регламентировал работу лишь с текстовыми сообщениями (передача аудио- видео- или графических сообщений в нем не рассматривалась). Но даже в случае чисто текстовых документов возникали проблемы при работе с языковыми наборами, требующими символов, которые отсутствуют в US-ASCII.
Одним из существенных ограничений традиционной электронной почты, базирующейся на RFC 821-822, является установка предельного размера строки (1000 7-битовых US-ASCII символов). Это вынуждало пользователей конвертировать текст различными методами в последовательность US-ASCII-кодов (например, процедура uuencode или преобразование в коды Base-64).
Существенные проблемы возникали при почтовом обмене между узлами, поддерживающими протоколы RFC 822 и X.400. Протокол X.400 [X400] определяет механизм включения нетекстовых материалов в почтовые сообщения. Существующие протоколы согласования работы X.400 и RFC 822 предполагают, что X.400 осуществляет преобразование нетекстовых вставок в формат IA5Text, или такие сообщения просто выбрасываются. Отправитель сообщения часто не знает о возможностях получателя, что может привести к тому, что последний, получив сообщения, попросту не сможет его прочесть. Таким образом, нужен механизм согласования возможностей отправителя и получателя на начальной стадии их взаимодействия до начала передачи тела сообщения.
В протоколе MIME регламентируется следующее:

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

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

  • Поле заголовка Content-Transfer-Encoding, которое может использоваться для задания типа преобразования.

  • Два дополнительные поля заголовка, предусмотренные для уточнения описания данных в теле сообщения (Content-ID и Content-Description).


    Современные протоколы Интернет с самого начала создавались таким образом, чтобы их было легко расширить или модернизировать. В частности, MIME [RFC-2045] является открытой системой, допускающей введение новых типов объектов, символьных наборов и методов доступа без изменения базового протокола. Однако необходим процесс регистрации, чтобы гарантировать, что набор таких значений соответствует стандарту и может использоваться в общедоступных сетях.
    Здесь рассматриваются процедуры регистрации, которые осуществляются через IANA (Internet Assigned Numbers Authority), центральной инстанции для решения этих проблем.
    Процесс регистрации для типов среды был первоначально определен в контексте асинхронной почтовой среды Интернет. В этой почтовой среде существует необходимость ограничить число возможных типов среды, чтобы увеличить вероятность успешного взаимодействия с удаленной почтовой системой, когда ее возможности заранее не известны.


    В разделе 2.9 описания архитектуры MPLS [2] протокол рассылки меток определен как набор процедур, с помощью которых один маршрутизатор LSR (Label Switched Router) информирует другие о значении меток, используемых для переадресации трафика между ними и через них. Архитектура MPLS не предполагает существования единственного протокола рассылки меток. Данная статья представляет собой спецификацию расширения протокола RSVP для формирования маршрутов (LSP) с коммутацией по меткам в MPLS-сетях.
    Несколько новых особенностей, описанных здесь, мотивировались требованиями управления трафиком в рамках MPLS (смотри [3]). В частности, расширенный протокол RSVP поддерживает реализацию явной прокладки LSP, с или без резервирования ресурсов. Он также поддерживает плавное изменение маршрута LSP, установление приоритетов и обнаружение циклических путей.
    LSP, сформированные RSVP, могут использоваться для транспортировки потоков трафика ("Traffic Trunks"), как это описано в [3]. Два LSP между отправителем и получателем могут образовывать единый поток трафика. Наоборот несколько потоков трафика могут транспортироваться одним LSP, если бы, например, LSP могли предоставлять несколько классов услуг. Применимость этих расширений обсуждается в [10].
    Так как трафик, который проходит по маршруту с коммутацией меток, определен меткой, заданной входным узлом LSP, эти маршруты могут рассматриваться как туннели, обеспечивающие связь между обычной IP-маршрутизацией и механизмами отбора (фильтрации). Когда LSP используется так, мы называем их LSP-туннелями.
    LSP-туннели допускают реализацию различных политик оптимизации работы сети. Например, LSP-туннели могут обходить автоматически или вручную точки отказов в сети, области перегрузок или узкие места. Более того, несколько параллельных LSP-туннелей могут быть проложено между двумя узлами, и трафик между этими узлами может быть направлен через эти LSP-туннели согласно местной политике маршрутизации. Хотя предполагается, что управление трафиком (то есть, оптимизация рабочих характеристик сети) является важным приложением этой спецификации, расширенный протокол RSVP может быть использован в более широком контексте.
    Целью данной статьи является описание использования RSVP для формирования LSP-туннелей. Предполагается полностью описать все объекты, форматы пакетов и процедуры, необходимые для реализации совместимых реализаций. Определено несколько объектов, которые улучшают управление и диагностику LSP-туннелей. В статье обсуждаются также средства быстрого детектирования отказа узлов посредством нового сообщения HELLO.
    Все объекты и сообщения, обсуждаемые в данной статье, являются опционными по отношению RSVP. В данной статье обсуждается ситуация, когда определенный объект не поддерживается конкретным узлом.


    В области MPLS [MPLS_ARCH], когда поток данных проходит по общему пути, маршрут с коммутацией по меткам LSP (Label Switched Path) может быть сформирован с привлечением сигнальных протоколов MPLS. Во входном маршрутизаторе с коммутацией по меткам LSR (Label Switch Router), каждому пакету присваивается метка, и он передается далее “вниз по течению”. В каждом LSR вдоль LSP, метки используются для определения следующего шага переадресации пакета.
    При предоставлении дифференцированных услуг Diff-Serv (Differentiated Service) [DIFF_ARCH] все IP-пакеты, проходящие через канал и требующие того же уровня Diff-Serv, образуют ансамбль BA (Behavior Aggregate). Во входном узле области Diff-Serv, пакеты классифицируются и помечаются с помощью кода DSCP (Diff-Serv Code Point), который соответствует их ансамблю BA. В каждом промежуточном узле, DSCP используется для определения пошагового поведения PHB (Per Hop Behavior), которое задает последовательность обработки и, в некоторых случаях, вероятность отбрасывания пакетов.
    В данном документе рассмотрена схема поддержки ансамблей ВА Diff-Serv, чье PHB-поведение определено (в [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) для сетей MPLS. Данная схема основана на использовании комбинации двух типов LSP:
  • LSP, которые могут транспортировать несколько ансамблей ВА, так что поле EXP заголовка MPLS передает LSR характер PHB, которое следует применить к пакету.
  • LSP, которые транспортируют только один ансамбль ВА, так что обработка пакетов в LSR целиком определяется значением их метки, приоритет отбрасывания пакета задается полем EXP заголовка MPLS или на уровне инкапсуляции канала специфическим механизмом отбрасывания (ATM, Frame Relay, 802.1).

    • Как указано в [DIFF_HEADER], сервис провайдеры не должны использовать одни и те же механизмы узла или конфигурации для дифференциации услуг внутри сети, и свободно могут конфигурировать параметры узла любым способом, который подходит для них и соответствует объективным условиям управления трафиком. Таким образом, предложение, рассмотренное в данном документе, предоставляет сервис провайдерам достаточную свободу того, как осуществлять маршрутизацию для разных классов услуг Diff-Serv или как управлять трафиком в пределах их области ответственности (например, разделить классы услуг, поддерживаемые через разные LSP и маршрутизируемые независимо, и классы услуг поддерживаемые одним LSP и маршрутизируемые вместе).
    Так как протокол MPLS ориентирован на маршрут, он может в потенциале обеспечить большее быстродействие и более предсказуемые возможности защиты и восстановления при изменениях топологии, которые обычны для IP-систем, маршрутизируемых пошагово. В данном документе мы называем это "MPLS защитой". Хотя такие возможности и связанные с ними механизмы находятся за пределами данной спецификации, отмечается, что они могут предложить разные уровни защиты для различных LSP. Так как рассмотренное здесь решение позволяет сервис провайдеру выбрать то, как следует установить соответствие между классами обслуживания Diff-Serv и LSP, оно предоставляет определенную гибкость в выборе уровня защиты для различных классов услуг Diff-Serv (например, некоторые классы услуг могут поддерживаться LSP, обеспечивающими такую защиту, другие LSP могут не предлагать такой защиты).
    Более того, решение, предлагаемое в данном документе, позволяет сохранять пространство меток и уменьшает объем обменов, сопряженных с процедурами set-up/tear-down, прибегая, где возможно, к использованию нескольких LSP для заданного FEC (Forwarding Equivalent Class) [MPLS_ARCH].
    Эта спецификация позволяет поддерживать в рамках сетей MPLS дифференциальные услуги как для IPv4, так и IPv6.
    Схема, описанная в данном документе, не препятствует использованию битов поля EXP для поддержки явного уведомления о перегрузке ECN (Explicit Congestion Notification) совместно с Diff-Serv в рамках MPLS. Однако способы поддержки ECN в среде MPLS в данной статье не рассматриваются.


    Архитектура протокола MPLS [RFC3031] была определена для переадресации пакетов на основе меток. В этой архитектуре предполагается, что маршрутизаторы LSR способны (a) распознавать границы пакетов или ячеек, и (b) могут обрабатывать заголовки пакетов (для LSR, способных распознавать границы пакетов) или заголовки ячеек (для LSR, способных распознавать границы ячеек).
    Исходная архитектура теперь распространена на LSR, которые не могут распознавать ни границы пакетов, ни границы ячеек, и, следовательно, не могут переадресовать данные на основе информации, содержащейся в заголовках пакетов или ячеек. Такие LSR в частности включают в себя приборы, где решение о переадресации принимается на основе временного домена, длины волны или номера физического порта.
    Подобные LSR, или точнее интерфейсы LSR, могут быть отнесены к следующим классам:
    Интерфейсы, которые распознают границы пакетов/ячеек и могут переадресовать данные с учетом содержимого заголовка пакета/ячейки. Примерами могут служить интерфейсы маршрутизаторов, которые переадресуют данные на основе содержимого промежуточных заголовков, интерфейсы ATM-LSR, которые переадресуют данные на основе VPI/VCI ATM. Такие интерфейсы считаются способными коммутировать пакеты (PSC - Packet-Switch Capable).
    Интерфейсы, которыеи переадресуют данные на основе циклических временных доменов. Примером такого интерфейса является соединение SONET/SDH. Такие интерфейсы считаются мультиплексирующими по времени (TDM).
    Интерфейсы, которые переадресуют данные на основе длины волны, на которой данные получены. Примером такого интерфейса является оптические коммутаторы, которые работают на уровне отдельных длин волн. Такие интерфейсы считаются l -переключателями LSC (Lambda Switch Capable).
    Интерфейсы, которые переадресуют данные на основе положения данных в реальном физическом пространстве. Примером такого интерфейса является оптическое подключение, которое работает на уровне одного (или нескольких) волокон. Такие интерфейсы считаются оптическими переключателями FSC (Fiber-Switch Capable).


    Протокол обобщенного MPLS раздвигает его применимость с поддержки пакетных интерфейсов (PSC) и коммутации до поддержки трех новых классов интерфейсов и коммутации:TDM (Time-Division Multiplex - мультиплексирование по времени), l-коммутатор (LSC) и волоконный коммутатор (FSC). Функциональное описание расширений MPLS, необходимых для поддержки новых классов интерфейсов и коммутации сделано в [RFC3471]. Этот документ рассматривает специфические форматы RSVP-TE и механизмы, необходимые для поддержки всех четырех классов интерфейсов.
    [RFC3471] следует рассматривать как составную часть этого документа. В этом документе определены также возможности RSVP-TE, для поддержки быстрого уведомления об отказах, смотри разделы 4.2 и 4.3.


    Язык описания маршрутной политики RPSL (Routing Policy Specification Language) позволяет оператору сети специфицировать маршрутную политику на различных уровнях иерархии Интернет, например, на уровне автономных систем (AS). Так что низкоуровневые конфигурации маршрутизаторов могут генерироваться на основании спецификаций RPSL. Язык RPSL является расширяемым и не препятствует внедрению новых протоколов маршрутизации.
    Язык RPSL призван заменить язык спецификации маршрутной политики, используемый в настоящее время и описанный в документах RIPE-181 [6] или RFC-1786 [7]. RIPE-81 [8] был первым языком, использованным в Интернет для спецификации маршрутных политик. В процессе использования RIPE-181 стало понятно, что некоторые политики не могут быть специфицированы и необходим более совершенный язык.
    Язык RPSL был сконструирован так, чтобы описание всей политики маршрутизации записывалось в одну распределенную базу данных, улучшая целостность маршрутизации в Интернет. RPSL не является языком конфигурации маршрутизатора. Язык RPSL сформирован так, чтобы конфигурация маршрутизатора осуществлялась на основе описания маршрутной политики автономной системы (класс aut-num) в сочетании с описанием маршрутизатора (класс inet-rtr), которое предоставляет идентификатор маршрутизатора, номер автономной системы, описания интерфейсов и партнеров маршрутизатора. Эти данные используются совместно с глобальной базой данных карты автономных систем (класс as-set), и информацией об автономных системах отправителях и о маршрутных префиксах (классы route и route-set).
    Язык RPSL является объектно-ориентированным, то есть, объекты содержат блоки описания политики и административную информацию. Эти объекты регистрируются в IRR (Internet Routing Registry) авторизованными организациями. О IRR смотри [1, 17, 4].
    Далее рассматриваются классы, которые используются для определения различных политик и административных объектов. Класс "mntner" определяет средства, предназначенные для добавления, уничтожения и модификации набора объектов. Классы "person" и "role" описывают технический и административный персонал, с которым можно установить контакт. Автономные системы (AS) специфицируются с помощью класса "aut-num". Маршруты специфицируются посредством класса "route". Наборы объектов могут быть определены с помощью классов "as-set", "route-set", "filter-set", "peering-set" и "rtr-set". Класс "dictionary" предоставляет возможность расширения возможностей языка. Класс "inet-rtr" используется для спецификации маршрутизаторов. Многие из этих классов были определены ранее, смотри [6, 13, 16, 12, 5].

    Анонсирование меток Downstream Unsolicited

    Вообще, LSR ниже по течению ответственен за анонсирование меток, когда он хочет, чтобы вышестоящий LSR использовал конкретную метку. Вышестоящий LSR может послать запрос присвоения метки (mapping request), если он этого захочет.
    Комбинация режима Downstream Unsolicited и консервативного удержания метки может вести к ситуации, когда LSR освобождает метку для заданного FEC, которая ему может быть нужна в будущем. Например, если LSR Rd анонсирует LSR Ru метку для FEC, для которого Ru не является следующим шагом, Ru освободит метку. Если следующим шагом Ru для FEC позднее станет Rd, ему потребуется метка, которая была ранее освобождена.
    Чтобы разрешить эту проблему, либо Ru может явно запросить метку, когда она ему нужна, либо Rd может периодически предлагать ее Ru. Во многих ситуациях Ru будет знать, когда ему нужна метка от Rd. Например, когда его следующим шагом для FEC становится Rd. Однако могут возникать ситуации, когда Ru не имеет нужной информации. Например, Rd может пытаться сформировать LSP с нестандартными свойствами. Необходимость для Ru в этой ситуации явно запросить метку потребует, чтобы он поддерживал состояния LSP с нестандартными свойствами.
    В ситуациях, где Ru знает, что ему нужна метка, он ответственен за явный запрос метки посредством посылки сообщения Label Request. В ситуациях, где Ru не может знать, что ему нужна метка, Rd ответственен за периодическое анонсирование метки Ru.
    Для этой версии LDP, единственная ситуация, когда Ru знает, что ему нужна метка для FEC от Rd, это когда Rd является следующим шагом для FEC, Ru не имеет метки от Rd, и LSP для FEC является единственным, который может быть сформирован с TLV, определенными в данном документе.



    Анонсирование меток вниз по течению по запросу (Downstream on Demand)

    Вообще, при работе в режиме Downstream on Demand (вниз по течению по запросу) вышестоящий LSR ответственен за организацию присвоения меток. Однако если не следовать определенным правилам, может так случиться, что LSR-соседи с разными режимами анонсирования попадут в ситуацию активного тупика, когда все функционирует нормально, но метки не рассылаются. Например, рассмотрим два LSR Ru и Rd, где Ru является вышестоящим LSR, а Rd - нижестоящим LSR для конкретного FEC. В этом примере Ru использует режим анонсирования Downstream Unsolicited, а Rd использует режим Downstream on Demand. В этом случае Rd может предполагать, что Ru, запросит метку, когда он захочет, а Ru может предполагать, что Rd анонсирует метку, если захочет, чтобы Ru ее использовал. Если Rd и Ru работают, как это предполагается, никаких меток не будет посылаться от Rd к Ru.
    Эта ситуация активного тупика может быть исключена, если следовать правилу: LSR, работающий в режиме Downstream on Demand, не должен посылать анонсирования установления добровольного соответствия меток (unsolicited mapping). Следовательно, если нижестоящий LSR работает в режиме Downstream on Demand, вышестоящий LSR ответственен за посылку запросов присвоения меток, как это требуется.



    Независимое управление присвоением меток

    Если LSR сконфигурирован для независимого управления, сообщения установления соответствия передается LSR при выполнении любого из следующих условий:
  • LSR распознает новый FEC с помощью маршрутной таблицы, и используется режим анонсирования меток Downstream Unsolicited.

  • LSR получает сообщение запроса от вышестоящего партнера для FEC, присутствующего в маршрутной таблице LSR .

  • Следующий шаг для FEC изменился, и активизировано детектирование петель.

  • Атрибуты соответствия изменились.

  • Отклик на присвоение метки от узла-следующего шага вниз по течению и

  • не было установления соответствия со стороны выше по течению или

  • сконфигурировано детектирование петель или

  • атрибуты соответствия изменились.




    • Обязательное соответствие PHB-->EXP

    PHB Поле EXP
    DF > 000
    CSn > 000
    AFn1 > 001
    AFn2 > 010
    AFn3 > 011
    EF > 000



    Партнеры рассылки меток для адресного префикса

    LSR R1 и R2 считаются партнерами рассылки меток для адресного префикса X, если и только если выполнено одно из следующих условий:
    1. Маршрут R1 к X является маршрутом, который прислан определенным IGP, а R2 является соседом R1 по данным IGP.
    2. Маршрут R1 к X является маршрутом, который прислан в какой-то момент в результате работы алгоритма маршрутизации A1, и этот маршрут рассылается алгоритмом маршрутизации A2, а R2 является соседом R1 согласно A2.
    3. R1 является выходной точкой LSP-туннеля, который находится внутри другого LSP, а R2 является входной точкой этого туннеля, R1 и R2 являются клиентами IGP, и находятся в той же области IGP (если данный IGP имеет области), а маршрут от R1 к X был получен через IGP, или в результате рассылки R1 данному IGP.
    4. Маршрут R1 к X является маршрутом, который прислан BGP, а R2 является BGP-партнером R1.
    Вообще, эти правила гарантируют то, что, если маршрут до определенного адресного префикса рассылается через IGP, партнеры рассылки меток для данного адресного префикса являются IGP-соседями. Если маршрут определенного адресного префикса рассылается через BGP, партнеры рассылки меток для данного адресного префикса являются BGP партнерами. В других случаях LSP-туннелирования конечные точки туннеля являются партнерами по рассылке меток.



    На момент формирования данной спецификации

    На момент формирования данной спецификации не существовало стандартных таблиц соответствия PHB и классов трафика 802.1. Следовательно, LSR, поддерживающий несколько классов трафика 802.1 через интерфейс LAN, должен позволять локальную конфигурацию таблицы PHB-->802.1. Эта таблица относится ко всем исходящим LSP, сформированным LSR для данного интерфейса LAN.


    PushUnconditional

    Пусть Rd является LSR. Предположим, что:
    1. X является адресным префиксом в маршрутной таблице Rd
    2. Ru является партнером по рассылке меток Rd с точки зрения X
    Когда бы эти условия ни выполнялись, Rd должен связать метку с X и послать эту ассоциацию Ru. Отслеживание ассоциаций, которые посылаются Ru, и контроль того, что Ru всегда имеет эти ассоциации, является областью ответственности Rd.
    Эта процедура должна использоваться LSR, которые выполняют не затребованное присвоение меток в независимом режиме управления LSP.



    ReleaseOnChange

    Ru должен ликвидировать ассоциацию и информировать Rd об этом. Эту процедуру следует использовать в консервативном режиме удержания меток (Label Retention Mode).



    Соответствие PHB-->CLP по умолчанию

    PHB CLP бит
    DF > 0
    CSn > 0
    AFn1 > 0
    AFn2 > 1
    AFn3 > 1
    EF > 0



    Упорядоченное управление присвоением меток

    Если LSR осуществляет упорядоченное управление, сообщение установления соответствия передается нижерасположенным LSR при выполнении любого из следующих условий:
  • LSR распознает новый FEC из маршрутной таблицы, и он является выходным для этого FEC.

  • LSR получает сообщение запроса от вышестоящего партнера для FEC, присутствующего в маршрутной таблице LSR, и LSR является выходным для этого FEC или имеет установленное соответствие для зоны вниз по течению.

  • Следующий шаг для FEC изменился и активизировано детектирование петель.

  • Атрибуты соответствия изменились.

  • Отклик на присвоение метки от узла следующего шага ниже по течению и

  • не сформировано никакого соответствия узлом выше по течению или

  • сконфигурировано детектирование петель или

  • атрибуты соответствия изменились.




    • UseImmediate

    Ru может начать использовать ассоциацию немедленно. В любое время, когда Ru получил ассоциацию для X от Rd , а Rd является следующим шагом Ru L3 для X, Rd будет также следующим шагом Ru LSP для X . Эта процедура применяется, когда не используется детектирование петель.



    Вектор пути в случае присвоения метки

    В разделе "Детектирование петель" специфицируются ситуации, когда LSR должен включать TLV вектора пути в сообщения присвоения метки. LSR, который получает вектор пути в сообщении присвоения метки, должен выполнить процедуры, описанные в разделе "Детектирование петель".
    Если LSR детектирует петлю, он должен отвергнуть сообщение присвоения метки для того, чтобы исключить зацикливания сообщений. LSR должен:
  • Передать LSR-отправителю сообщение освобождения метки (Label Release), несущее в себе TLV статуса, сигнализируя о "Детектировании петли".

  • Не передавать сообщение дальше.

  • Проверить, относится ли сообщение присвоения метки к существующему LSP. Если это так, LSR должен разъединить любые метки выше по течению, которые объединены для области вниз по течению для заданного FEC.

    • Заметим, что сообщение присвоения метки с TLV вектора расстояния переадресуется до тех пор пока:
  • Не обнаружена петля,

  • Достигнуто начало LSP, или

  • Достигнут максимум вектора пути или числа шагов. Это обрабатывается, как если бы была детектирована петля.




    • Вектор пути запроса метки

    Раздел "детектирование петель" специфицирует ситуации, когда LSR должен включить TLV вектора пути в сообщение запроса метки.
    LSR, который получает вектор пути в сообщении запроса метки, должен выполнить процедуры, описанные в разделе "детектирование петель". Если LSR детектирует петлю, он должен отвергнуть сообщение запроса метки.
    LSR должен:
  • Послать сообщение уведомления LSR-отправителю, сигнализируя, что "Обнаружена петля".

  • Не передавать дальше сообщение запроса метки.

    • Заметим, что сообщение запроса метки с TLV вектора пути переадресуется до тех пор пока:
  • Будет найдена петля,

  • Будет достигнут конец LSP,

  • Будет достигнут верхний предел длины вектора пути или числа шагов. Это обрабатывается как, если бы была детектирована петля пути.




    • Истечение таймера KeepAlive сессии

    Это фатальная ошибка, сигнализируемая кодом статуса KeepAlive Timer Expired (таймер KeepAlive истек).



    Неизвестный или некорректный TLV

    Некорректный TLV, содержащийся в LDP сообщении, которое является частью механизма LDP выявления, приводит к молчаливому отбрасыванию сообщения.
    TLV, содержащееся в сообщении LDP, которое получено по TCP-соединению имеет некорректный формат, если:
  • Длина TLV слишком велика, то есть, указывает, что TLV простирается за пределы содержащего его сообщения. Это фатальная ошибка, сигнализируемая кодом статуса Bad TLV Length (неверная длина TLV).

  • Тип TLV не известен.
    Если тип TLV < 0x8000 (старший бит 0), это ошибка, сигнализируемая кодом статуса Unknown TLV (неизвестный TLV).
    Если тип TLV >= 0x8000 (старший бит 1), TLV молча игнорируется.
  • Значение TLV некорректно. Это случается, когда получатель обрабатывает TLV, но не может декодировать значение TLV. Это интерпретируется как ошибка при отправке или получении LSR. Это фатальная ошибка, сигнализируемая кодом статуса Malformed TLV Value (некорректное значение TLV).




    • Некорректный PDU или сообщение

    Некорректно сформатированные LDP PDU или сообщения, которые являются частью механизма выявления LDP, молча отбрасываются. LDP PDU, полученный через TCP-соединение для LDP-сессии сформатировано некорректно, если:
  • Идентификатор LDP в заголовке PDU неизвестен получателю, или он известен, но этот идентификатор не ассоциирован получателем с партнером LDP для этой сессии. Это фатальная ошибка, сигнализируемая кодом состояния Bad LDP Identifier (некорректный идентификатор).

  • Версия протокола LDP не поддерживается получателем, или он поддерживается, но это не та версия, которая согласована при установлении сессии. Это фатальная ошибка, сигнализируемая кодом статуса Bad Protocol Version (плохой код версии).

  • Поле длины PDU слишком мало (< 14) или слишком велико (> максимальной длины PDU). Это фатальная ошибка, сигнализируемая кодом состояния Bad PDU Length (неверная длина PDU).
    LDP-сообщение некорректно, если:
  • Тип сообщения неизвестен.
    Если тип сообщения < 0x8000 (старший бит = 0) - это ошибка, сигнализируемая кодом статуса Unknown Message Type (неизвестный тип сообщения). Если тип сообщения >= 0x8000 (старший бит = 1), оно молча отбрасывается.
  • Длина сообщения слишком велика, то есть, индицирует, что сообщение занимает места больше, чем отведено в LDP PDU. Это фатальная ошибка, сигнализируемая кодом статуса Bad Message Length (неверная длина сообщения).

  • В сообщении нет одного или более обязательных параметров. Это не фатальная ошибка, сигнализируемая кодом статуса Missing Message Parameters (пропущены обязательные параметры).




    • Одностороннее прерывание сессии

    Это фатальная ошибка, сигнализируемая кодом статуса Shutdown. Сообщение уведомления может опционно включать в себя TLV расширенного статуса, чтобы объяснить причину Shutdown. LSR-отправитель завершает сессию немедленно, после отправки уведомления.



    PushConditional

    Пусть Rd является LSR. Предположим, что:
    1. X является адресным префиксом в маршрутной таблице Rd
    2. Ru является партнером Rd по рассылке меток с учетом X
    3. Rd является либо концом LSP, либо прокси концом LSP для X , или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, и Rn связал метку с X и послал эту ассоциацию Rd.
    Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru.
    Поскольку PushUnconditional вызывает рассылку ассоциаций меток всем адресным префиксам маршрутной таблицы, PushConditional вызывает рассылку ассоциаций меток только тем адресным префиксам, для которых получены ассоциации от одного следующего шага LSP, или для которых не существует следующего шага с поддержкой MPLS L3.
    Эта процедуру следует использовать LSR, которые выполняют не затребованное присвоение меток в упорядоченном режиме управления LSP.



    Рассылаемые метки

    Для того чтобы использовать MPLS для переадресации пакетов согласно маршруту шаг-за-шагом, соответствующему какому-либо адресному префиксу, каждый LSR должен:
    1. Связать один или более меток с каждым адресным префиксом, который обнаружен в маршрутной таблице.
    2. Для каждого такого адресного префикса X, использовать протокол рассылки меток для уведомления партнеров (в рамках Х) о существовании ассоциации метки с данным префиксом.
    Существует также обстоятельство, при котором LSR должен рассылать ассоциации меток для адресного префикса, даже если он не является LSR, который установил связь между меткой и префиксом:
    3. Если R1 использует BGP для рассылки маршрута до X, называя некоторый другой LSR R2 в качестве следующего BGP шага к X, и если R1 знает, что R2 присвоена метка L, тогда R1 должен разослать уведомление об ассоциации L и X всем BGP-партнерам, которым он рассылает это маршрут.
    Эти правила гарантируют, что метки, ассоциированные с адресным префиксам, которые соответствуют маршрутам BGP, рассылаются IGP-соседям, если и только если BGP-маршруты разосланы IGP. Другими словами, метки, привязанные к BGP-маршрутам, рассылаются только другим BGP-агентам.
    Эти правила имею целью указать, какие ассоциации меток должны рассылаться данным LSR другим LSR.



    Разные события

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



    RequestNoRetry

    Ru никогда не должен посылать запрос повторно, предполагая, что Rd предоставит необходимую ассоциацию автоматически, когда она станет доступной. Это полезно, если Rd использует процедуру PushUnconditional или PushConditional, т.e., если применена не запрошенная рассылка меток нижестоящим объектам.
    Заметим, что если Rd отвечает, что он не может предоставить ассоциацию Ru, из-за тех же условий ошибки, а не по причине того, что Rd не имеет следующего шага, поведение Ru будет управляться условиями восстановления после ошибки протокола рассылки меток, а не процедурой NotAvailable.



    События сообщения инициализации

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



    События, вызванные другими сообщениями

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



    UseIfLoopNotDetected

    Эта процедура аналогична UseImmediate, если только Ru не детектировал петлю в LSP. Если детектирована петля, Ru прекратит использовать метку L для переадресации пакетов в Rd.
    Эта процедура используется, когда работает детектирование петель маршрутов. Это будет продолжаться до тех пор, пока не изменится следующий шаг для X, или пока не будет ликвидирован петлевой маршрут.



    Внутренние ошибки

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



    PulledUnconditional

    Пусть Rd является LSR. Предположим, что:
    1. X является адресным префиксом в маршрутной таблице Rd
    2. Ru является партнером Rd по рассылке меток с учетом X
    3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru
    Затем Rd должен связать метку с X и послать эту ассоциацию Ru. Заметим, что если X отсутствует в маршрутной таблице Rd, или если Rd не является партнером Ru по рассылке меток с учетом X, тогда Rd должен проинформировать Ru о том, что в данный момент не может предоставить ассоциацию.
    Если Rd уже переслал Ru ассоциацию метки для адресного префикса X, и получил новый запрос от Ru ассоциации для адресного префикса X, он свяжет вторую метку, и пошлет новую ассоциацию Ru . Первая ассоциация метки остается в силе.
    Эта процедура будет использоваться LSR, выполняющими рассылку меток downstream-on-demand, используя независимый режим управления LSP.



    RequestOnRequest

    Процедура посылает запрос всякий раз, когда приходит запрос в дополнение к необходимым протокольным запросам (как это описано в разделе 3.1.2.2). Если Ru не способен быть входом LSP, он может выдать запрос, только когда получает запрос сверху.
    Если Rd получает такой запрос от Ru, для адресного префикса, для которого Rd уже послал метку Ru, Rd присвоит новую метку, ассоциирует ее с X, и разошлет эту ассоциацию. Может ли Rd послать эту ассоциацию Ru немедленно или нет, зависит от используемой процедуры рассылки. Эту процедуру следует использовать LSR, которые осуществляют рассылку меток downstream-on-demand, но не выполняют объединения меток, например, ATM-LSR, которые не способны объединять VC.



    PulledConditional

    Пусть Rd является LSR. Предположим, что:
    1. X является адресным префиксом в маршрутной таблице Rd
    2. Ru является партнером Rd по рассылке меток с учетом X
    3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru
    4. Rd является либо концом LSP, либо прокси концом LSP для X, или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, а Rn связал метку с X и послал эту ассоциацию Rd
    Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru . Заметим, что если X отсутствует в маршрутной таблице Rd, а получить ассоциацию для X через следующий шаг Rd для X невозможно, или если Rd не является партнером Ru по пересылке меток с учетом X, тогда Rd должен проинформировать Ru, что не может в данный момент предоставить ему необходимую ассоциацию.
    Однако, если хотя бы одно условие не выполнено, Rn не выдает метку Rd, а Rd должен отложить отклик для Ru до тех пор, пока Rn не пришлет ассоциацию метки.
    Если Rd послал Ru ассоциацию метки для адресного префикса X, а спустя какое-то время любой из атрибутов ассоциации метки изменился, Rd должен заново послать Ru ассоциацию с новым значением атрибута. Он должен сделать это даже если Ru не послал нового запроса. Эту процедуру следует использовать LSR, которые осуществляют ассоциацию меток downstream-on-demand в упорядоченном режиме управления LSP.
    В разделе 4.2, мы обсудим то, как выбрать конкретную процедуру, которую следует использовать в конкретной ситуации, и как гарантировать совместимость работы LSR, выбравших разные процедуры.



    >5.Формат сообщения Hello

    Сообщениями Hello всегда обмениваются только RSVP соседи. Адрес IP отправителя равен IP-адресу узла-отправителя. IP-адрес места назначения равен IP-адресу соседнего узла.
    Механизм HELLO предназначен для использования только непосредственными соседями. Когда обмен сообщениями HELLO осуществляют соседи, поле IP TTL всех исходящих сообщений HELLO следует устанавливать равным 1.
    Сообщение Hello имеет тип Msg равный 20. Формат сообщения Hello показан ниже:


    ::= [ ]




    A.1.Детектирование доступности ресурсов локальной метки

    Краткое изложение:
    После того как LSR послал LDP-партнеру уведомление No Label Resources, когда ресурсы оказываются доступными, он посылает соответствующее уведомление (Label Resources Available) каждому из партнеров.
    Контекст:
  • LSR. LSR, обрабатывающий событие.

  • Атрибуты. Атрибуты, записанные в отложенном сообщении присвоения метки.

    • Алгоритм:

    ResA.1 Начать итерацию через ResA.4 для каждого партнера, которому LSR посылал ранее уведомление No Label Resources (Нет ресурсов для метки).
    ResA.2 Исполнить процедуру Send_Notification(Peer, Label Resources Available)
    ResA.3 Стереть запись о том, что ранее было послано партнеру уведомление No Label Resources.
    ResA.4 Завершить итерацию в точке ResA.1
    ResA.5 Начать итерацию через ResA.8 для каждой записи ассоциации метка-FEC, необходимой для партнера, когда нет ресурсов. (Смотри замечание 1.)
    ResA.6 Исполнить процедуру Send_Label(Peer, FEC, Attributes). Если процедура не прошла, прервать итерацию.
    ResA.7 Очистить запись ассоциации метка-FEC, которая нужна, но для этого нет ресурсов.
    ResA.8 Завершить итерацию в точке ResA.5
    ResA.9 DONE.

    Замечания:
  • Итерация с ResA.5 по ResA.8 обрабатывает ситуации, когда LSR использует рассылку меток в режиме Downstream Unsolicited и ранее не мог присвоить метку для FEC.




    • A.1.Детектирование изменения FEC следующего шага

    Краткое изложение:
    Отклик LSR на изменение следующего шага для FEC может включать в себя одну или более операций:
  • Удаление из таблицы маршрутизации метки, соответствующей старому значению следующего шага для FEC;

  • Передача сообщений присвоения метки для FEC одному или более партнерам LDP;

  • Передача запроса метки новому узлу следующего шага для заданного FEC;

  • Любая операция, которая может иметь место, когда LSR получает ассоциацию метка-FEC из узла следующего шага.
    Контекст:
  • LSR. LSR, обрабатывающий событие.

  • FEC. FEC, для которого изменился следующий шаг.

  • New Next Hop. Новый следующий шаг для данного FEC.

  • Old Next Hop. Предыдущий следующий шаг для FEC.

  • OldLabel. Метка, (если имеется) ранее полученная от старого узла следующего шага.

  • CurAttributes. Атрибуты, если имеются, ассоциированные в настоящее время с данным FEC.

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

    • Алгоритм :

    NH.1 Получал ли LSR ранее от старого узла следующего шага и сохранил ли ассоциацию метка-FEC? Если нет, goto NH.6.
    NH.2 Удалить метку из маршрутной таблицы. (Смотри замечание 1.)
    NH.3 Использует ли LSR свободное сохранение меток? Если да, goto NH.6.
    NH.4 Исполнить процедуру Send_Message(Old Next Hop, Label Release, OldLabel).
    NH.5 Удалить ассоциацию метка-FEC, ранее полученную от старого узла следующего шага.
    NH.6 Имеет ли LSR ожидающий запрос метки со старым значением следующего шага? Если нет, goto NH.10.
    NH.7 Использует ли LSR консервативное сохранение меток?

    Если нет, goto NH.10.
    NH.8 Исполнить процедуру Send_ Message(Old Next Hop, Label Abort Request, FEC, TLV), где TLV является ID запроса метки, который несет в себе ID ожидающего запроса метки.
    NH.9 Записать запрос ликвидации метки для FEC как ожидающий для старого узла следующего шага.
    NH.10 Имеется новый следующий шаг для данного FEC?

    Если нет, goto NH.16.
    NH.11 Получил ли ранее LSR от нового узла следующего шага ассоциацию метка-FEC? Если нет, goto NH.13.
    NH.12 Генерировать событие: Получена ассоциация метки от нового узла следующего шага. Goto NH.20. (Смотри замечание 2.)
    NH.13 Использует ли LSR анонсирование Downstream on Demand? ИЛИ

    Использует ли узел следующего шага анонсирование Downstream on Demand? ИЛИ

    Использует ли LSR консервативное сохранение меток?

    Смотри замечание 3.) Если да, goto NH.14. Если нет, goto NH.20.
    NH.14 Исполнить процедуру Prepare_Label_Request_Attributes(следующий шаг, FEC, CurAttributes, SAttributes)
    NH.15 Исполнить процедуру Send_Label_Request(New Next Hop, FEC, SAttributes). (Смотри замечание 4.) Goto NH.20.
    NH.16 Продолжить итерацию через NH.19 для следующего партнера
    NH.17 Послал ли LSR ранее партнеру ассоциацию метка-FEC?

    Если нет, продолжить итерацию для следующего партера через NH.16.
    NH.18 Исполнить процедуру Send_Label_Withdraw(Peer, FEC, Label previously sent to Peer).
    NH.19 Завершить итерацию через NH.16.
    NH.20 DONE

    Замечания:
  • Если метки нет в таблице маршрутизации, NH.2 не имеет последствий.

  • Если LSR имеет метку для FEC от нового узла следующего шага, ему следует вести себя, как если бы он только что получил метку от нового узла следующего шага.

  • Целью проверки режима сохранения метки является избежание участка с шагами LMp.12- LMp.13 процедуры обработки сообщения присвоения метки, где LSR, работая в режиме консервативного сохранения метки, может отправить сообщение присвоения метки, полученное от нового узла следующего шага, прежде чем обнаружит, что следующий шаг для данного FEC изменился.

  • Вне зависимости от используемой LSR процедуры запроса метки, он должен послать запрос метки, если условия в NH.8 выполняются. Следовательно, он выполняет непосредственно процедуру Send_Label_Request, а не процедуру запроса метки LSR.




    • A.1.Истечение таймаута отложенного запроса метки

    Краткое изложение:
    Запросы метки откладываются в ответ на уведомления No Route (нет маршрута) и Loop Detected (обнаружена петля). Когда для отложенного запроса метки истекает время таймаута, LSR посылает запрос метки.
    Контекст:
  • LSR. LSR, обрабатывающий событие.

  • FEC. FEC, ассоциированный с событием таймаута.

  • Партнер. LDP-партнер, ассоциированный с событием таймаута.

  • Атрибуты. Атрибуты, запомненные вместе с сообщением отложенного запроса метки.

    • Алгоритм:

    TO.1 Извлечь запись отложенного запроса метки.
    TO.2 Является ли партнер узлом следующего шага для FEC?

    Если нет, goto TO.4.
    TO.3 Исполнить процедуру Send_Label_Request(Peer, FEC).
    TO.4 DONE.




    A.1.LSR решает не переадресовывать пакеты по метке для данного FEC

    Краткое изложение:
    LSR может в одностороннем порядке решить прекратить использование ассоциации метка-FEC для коммутации пакетов. LSR, который делает это, должен послать партнеру сообщение отзыва метки для FEC (label withdraw).
    Контекст:
  • Партнер. Партнер.

  • FEC. FEC.

  • PrevAdvLabel. Метка для FEC, ранее анонсированная для партнера.

    • Алгоритм:

    NoLS.1 Исполнить процедуру Send_Label_Withdraw(Peer, FEC, PrevAdvLabel). (Смотри замечание 1.)
    NoLS.2 DONE

    Замечания:
  • LSR может удалить метку из таблицы маршрутизации в результате выполнения освобождения метки в ответ на запрос отзыва.




    • A.1.Получение Label Release (освобождение метки)

    Краткое изложение:
    Когда LSR получает от партнера сообщение освобождения метки для FEC, он проверяет, удерживают ли другие партнеры освобожденную метку. Если никто этого не делает, LSR прекращает использование метки для переадресации, если он еще не сделал это, и, если LSR удерживает ассоциацию метки и FEC следующего шага, он освобождает метку.
    Контекст:
  • LSR. LSR, обрабатывающий события.

  • MsgSource. Партнер LDP, который посылает сообщение.

  • Метка. Метка, специфицированная в сообщении.

  • FEC. FEC, специфицированный в сообщении.

    • Алгоритм:

    LRl.1 Удалить MsgSource из записи партнеров, где хранится метка для заданного FEC. (Смотри замечание 1.)
    LRl.2 Соответствует ли сообщение сообщению отзыва метки для FEC, посланной ранее MsgSource? Если нет, goto LRl.4
    LRl.3 Ликвидировать запись для отзываемой метки, посланную ранее MsgSource.
    LRl.4 Способен ли LSR объединять метки для этого FEC?

    Если нет, goto LRl.6. (Смотри замечание 2.)
    LRl.5 Имеет ли LSR метку, ранее анонсированную для этого FEC другим партнерам? Если да, goto LRl.10.
    LRl.6 Является ли LSR выходным для этого FEC? Если да, goto LRl.10
    LRl.7 Имеется ли следующий шаг для FEC? И

    Имеет ли LSR, полученную ранее от узла следующего шага ассоциацию метка-FEC? Если нет, goto LRl.10.
    LRl.8 Сконфигурирован ли LSR для переадресации запросов освобождения метки? Если нет, goto LRl.10. (Смотри замечание 3.)
    LRl.9 Исполнить процедуру Send_Message (Next Hop, Label Release, FEC, Label from Next Hop).
    LRl.10 Удалить метку из MsgSourceи не использовать ее для переадресаций пакетов.
    LRl.11 Содержит ли кто-то из партнеров ассоциацию метки и FEC?

    Если да, goto LRl.13.
    LRl.12 Освободить метку.
    LRl.13 DONE.

    Замечания:
  • Если LSR использует режим рассылки меток Downstream Unsolicited, он не должен повторно анонсировать MsgSource ассоциацию метка-FEC до тех пор, пока MsgSource не запросит этого.

  • Шаги с LRl.4 по LRl.8 служат для определения, следует ли LSR передавать запрос об освобождении метки дальше партнерам ниже по течению (LRl.9).

  • Если LRl.8 достигнут, ни один LSR выше по течению не содержит ассоциации метки с данным FEC, и LSR получает ассоциацию метка-FEC от узла следующего шага. LSR может передавать запрос освобождения метки узлу следующего шага. Путем передачи запросов освобождения метки LSR освобождает ресурсы для меток. Поступая так, он также увеличивает задержку восстановления LSP.

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



    A.1.Получение Label Withdraw (отзыв метки)

    Краткое изложение:
    Когда LSR получает сообщение отзыва метки для FEC от партнера LDP, он откликается посылкой сообщения освобождения метки и удаляет метку из таблиц переадресации. Если используется упорядоченное управление, LSR посылает сообщение отзыва метки каждому LDP партнеру, которому ранее было послано сообщение присвоения метки для FEC. Если LSR использует режим анонсирования меток Downstream on Demand при независимом управлении, он действует так, как если бы он только что распознал FEC.
    Контекст:
  • LSR. LSR, обрабатывающий события.

  • MsgSource. LDP партнер, который посылает сообщение.

  • Label. Метка, специфицированная в сообщении.

  • FEC. FEC, специфицированная в сообщении.

    • Алгоритм:

    LWd.1 Удалить метку из таблицы переадресации. (Смотри замечание 1.)
    LWd.2 Исполнить процедуру Send_Message(MsgSource, Label Release, FEC, Label)
    LWd.3 Имеет ли LSR полученную ранее от MsgSource и сохраненную ассоциацию метка-FEC? Если нет, goto LWd.13.
    LWd.4 Уничтожить ассоциацию метка-FEC, полученную ранее от MsgSource.
    LWd.5 Использует ли LSR упорядоченное управление? Если да, goto LWd.8.
    LWd.6 Использует ли MsgSource анонсирование меток в режиме Downstream On Demand? Если нет, goto LWd.13.
    LWd.7 Генерировать событие: Рапознавание нового FEC. Goto LWd.13. (Смотри замечание 2.)
    LWd.8 Продолжить итерацию через LWd.12 для каждого партнера, отличного от MsgSource.
    LWd.9 Послал ли LSR ранее партнеру ассоциацию метка-FEC? Если нет, продолжить итерацию для следующего партнера через LWd.8.
    LWd.10 Согласуется ли метка, посланная ранее партнеру, с отзываемой меткой? Если нет, продолжить итерацию для следующего партнера черезt LWd.8. (Смотри замечание 3.)
    LWd.11 Исполнить процедуру Send_Label_Withdraw(Peer, FEC, Метка посланная ранее партнеру).
    LWd.12 Закончить итерацию через LWd.8.
    LWd.13 DONE

    Замечания:
  • Если метка не используется для переадресации, шаг LWd.1 не будет иметь последствий.

  • LWd.7 обрабатывает случаи, когда LSR использует рассылку меток в режиме Downstream On Demand при независимом управлении. В этой ситуации LSR должен посылать запрос метки в узел следующего шага для FEC, как если бы он только что распознал FEC.

  • LWd.10 работает как в случае поддержки объединения меток (одна или более входных меток ставится в соответствие одной выходной метке), так и в отсутствии объединения (одна метка ставится в соответствие выходной метке).




    • A.1.Получение уведомления / детектирование петли

    Краткое изложение:
    Когда LSR в ответ на запрос или сообщение присвоение метки получает от партнера статусный код, свидетельствующий о наличии петли, он ведет себя так, как если бы он получил уведомление об отсутствии маршрута.
    Контекст:
    Смотри "Получение уведомления / нет пути".
    Алгоритм:
    Смотри " Получение уведомления / нет пути"
    Замечания:
  • Когда в ответ на запрос метки приходит уведомление о детектировании петли, оно приходит в TLV статусного кода. Когда это является откликом на присвоение метки, оно прибывает в TLV статусного кода сообщения об освобождении метки.




    • A.1.Получение уведомления / Нет пути

    Краткое изложение:
    Когда LSR получает от партнера LDP уведомление No Route в ответ сообщение запроса метки, его реакция диктуется процедурой Label No Route. LSR либо не будет предпринимать никаких действий, либо отложит запрос метки путем запуска таймера и пошлет запрос партнеру позднее, когда время таймера истечет.
    Контекст:
  • LSR. LSR, обрабатывающий события.

  • FEC. FEC, для которого была запрошена метка.

  • Атрибуты. Атрибуты, ассоциированные с запросом метки.

  • MsgSource. LDP-партер, который послал сообщение уведомления.

    • Алгоритм:

    NoNH.1 Стереть запись о запросе метки для FEC, посланном в MsgSource.
    NoNH.2 LSR выполняет процедуру Label No Route (нет пути для метки).

    Для запросов без дублирования
    1. Goto NoNH.3.
    Для повторного запроса
  • Записать отложенный запрос метки для FEC и атрибуты, которые нужно послать MsgSource.

  • Запуск таймаута. Goto NoNH.3.

    • NoNH.3 DONE.



    A.1.Получение уведомления / Нет ресурсов для метки

    Краткое изложение:
    Когда LSR получает от LDP-партнера уведомление No Label Resources (нет ресурсов для метки), он прекращает посылать партнеру сообщения запросов метки до тех пор, пока не получит от партнера уведомление Label Resources Available (ресурсы имеются).
    Контекст:
  • LSR. LSR, который обрабатывает событие.

  • FEC. FEC, для которого запрашивалась метка.

  • MsgSource. LDP-партнер, который послал уведомление.

    • Алгоритм:

    NoRes.1 Стереть запись о запросе метки для FEC, посланный по адресу MsgSource
    NoRes.2 Нужна запись ассоциации метка-FEC от MsgSource, но нет ресурсов для метки
    NoRes.3 Установить статусную запись, индицирующую, что он не в порядке, чтобы послать MsgSource запрос метки.
    NoRes.4 DONE




    A.1.Получение уведомления / ресурсы для метки доступны

    Краткое изложение:
    Когда LSR получает от LDP-партнера уведомление о доступности ресурсов для метки, он возобновляет посылку запросов метки партнеру.
    Контекст:
  • LSR. LSR, обрабатывающий событие.

  • MsgSource. LDP-партнер, который послал сообщение уведомления.

  • SAttributes. Атрибуты, запомненные с отложенным запросом метки.

    • Алгоритм:

    Res.1 Установить статусную запись в состояние, указывающее на возможность отправки MsgSource запроса метки.
    Res.2 Начать итерацию через Res.6 для каждой записи ассоциации метка-FEC, необходимой MsgSource, для которой нет ресурсов.
    Res.3 Является ли MsgSource следующим шагом для FEC?

    Если нет, goto Res.5.
    Res.4 Исполнить процедуру Send_Label_Request(MsgSource, FEC, SAttributes) Если процедура не прошла, прервать итерацию.
    Res.5 Стереть запись о том, что нет ресурсов для ассоциации метка-FEC, нужной MsgSource.
    Res.6 Завершить итерацию в точке Res.2
    Res.7 DONE.




    A.1.Получение уведомления/запрос метки аннулирован (Label Request Aborted)

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

  • FEC. FEC, для которого запрашивалась метка.

  • RequestMessageID. ID сообщения запроса метки, который следует ликвидировать.

  • MsgSource. LDP партнер, который послал сообщение уведомления.

    • Алгоритм :

    LRqA.1 Соответствует ли уведомление запросу метки для заданного FEC, который надлежит удалить? (Смотри примечание 1).

    Если нет, goto LRqA.3.
    LRqA.2 Записать, что запрос метки для данного FEC удален.
    LRqA.3 DONE

    Замечания:
    1. LSR использует FEC и Request Message ID, чтобы локализовать свою запись, если она имеется, о ликвидируемом запросе метки.



    A.1.Получение запроса ликвидации метки (Label Abort Request)

    Краткое изложение:
    Когда LSR получает от партнера сообщение запроса ликвидации метки, он проверяет, реагировал ли он уже на этот запрос. Если реагировал, то он молча игнорирует сообщение. Если не реагировал, он посылает партнеру уведомление подтверждения выполнения запроса ликвидации. Кроме того, если он имеет отложенный запрос для рассматриваемого LSP,он посылает нижерасположенному партнеру запрос ликвидации метки.
    Контекст:
  • LSR. LSR, обрабатывающий события.

  • MsgSource. LDP партнер, который посылает сообщение.

  • FEC. FEC, специфицированный в сообщении.

  • RequestMessageID. ID сообщения запроса метки, подлежащего ликвидации.

  • Next Hop. Следующий шаг для FEC.

    • Алгоритм:

    LAbR.1 Согласуется ли сообщение с полученным ранее запросом метки от MsgSource? (Смотри замечание 1.) Если нет, goto LAbR.12.
    LAbR.2 Среагировал ли LSR на ранее полученный запрос метки? Если да, goto LAbR.12.
    LAbR.3 Исполнить процедуру Send_ Message(MsgSource, Notification, Label Request Aborted, TLV), где TLV характеризует ID сообщения запроса метки, полученное в сообщение запроса ликвидации метки.
    LAbR.4 Имеется ли у LSR сообщение запроса метки для FEC?

    Если да, goto LAbR.7
    LAbR.5 Имеет ли LSR ассоциацию метки и FEC? Если нет, goto LAbR.11
    LAbR.6 Сгенерировать событие: От MsgSource получено сообщение освобождения метки для FEC. (Смотри замечание 2.) Goto LAbR.11.
    LAbR.7 Объединяет ли LSR метки LSP для FEC? Если нет, goto LAbR.9.
    LAbR.8 Отличаются ли вышестоящие партнеры от MsgSource, который запросил метку для FEC? Если да, goto LAbR.11.
    LAbR.9 Исполнить процедуру Send_Message(Next Hop, Label Abort Request, FEC, TLV), где TLV характеризует ID сообщения запроса метки, используемой LSR в сообщении запроса метки.
    LAbR.10 Записать, что запрос ликвидации метки для FEC в ожидании.
    LAbR.11 Стереть запись запроса метки для FEC от MsgSource.
    LAbR.12 DONE

    Замечания:
  • LSR использует FEC и TLV ID сообщения запроса метки, содержащееся в запросе ликвидации, чтобы найти свою запись (если таковая имеется) для полученного ранее от MsgSource запроса метки.

  • Если LSR получил ассоциацию метки от NextHop, он должен себя вести так, как если бы он анонсировал эту метку MsgSource, и MsgSource освободил ее.




    • A.1.Присвоение меток

    Краткое изложение:
    Отклик LSR на присылку FEC-метки от LDP-партнера может включать одну или более следующих операций:
  • Передача партнеру LDP сообщения освобождения метки для FEC;

  • Передача одному или более партнерам LDP сообщения присвоения метки для FEC,

  • Инсталляция LSR вновь полученных меток для переадресации пакетов.

    • Контекст:
  • LSR. LSR, обрабатывающий события.

  • MsgSource. LDP-партнер, который посылает сообщение.

  • FEC. Специфицированный в сообщении FEC.

  • Метка. Специфицированная в сообщении метка.

  • PrevAdvLabel. Метка для FEC, если имеется, ранее анонсированная вышестоящим партнером.

  • StoredHopCount. Число шагов ранее записанное для FEC.

  • RAttributes. Атрибуты, полученные с сообщением. Напр., число шагов, вектор пути.

  • SAttributes должны быть включены в сообщение присвоения метки, если имеются, то пересылаются вышестоящим партнерам.

    • Алгоритм:

    LMp.1 Соответствует ли полученная метка запросу метки FEC, посланному ранее MsgSource. Если нет, goto LMp.3.
    LMp.2 Стереть запись запроса метки FEC.
    LMp.3 Выполнить процедуру Check_Received_Attributes (MsgSource, LabelMapping, RAttributes). Если не зарегистрировано петель, goto LMp.9.
    LMp.4 Получил ли LSR от MsgSource метку для FEC? (Смотри замечание 1.) Если нет, goto LMp.8. (Смотри замечание 2.)
    LMp.5 Соответствует ли требованиям метка, полученная ранее от MsgSource (т.e., метка полученная в сообщении)? (Смотри замечание 3)

    Если нет, goto LMp.8. (Смотри замечание 4.)
    LMp.6 Стереть ассоциацию метки для FEC, полученную ранее от MsgSource.
    LMp.7 Удалить метку из таблицы маршрутизации. (Смотри замечание 5.)

    Goto LMp.33.
    LMp.8 Исполнить процедуру Send_Message (MsgSource, Label Release, FEC, Label, Loop Detected Status code). Goto LMp.33.
    LMp.9 Получил ли LSR ранее ассоциацию метки и FEC от MsgSource для рассматриваемого LSP? (Смотри замечание 6.) Если нет, goto LMp.11.
    LMp.10 Соответствует ли метка, полученная ранее от MsgSource, метке в сообщении? (Смотри замечание 3.) Если нет, goto LMp.32. (Смотри замечание 4.)
    LMp.11 Определить следующий шаг для FEC.
    LMp.12 Является ли MsgSource следующим шагом для FEC?

    Если да, goto LMp.14.
    LMp.13 LSR выполнить процедуру освобождения метки:
    <
    Для консервативного сохранения меток:

    1. Goto LMp.32.

    Для свободного сохранения меток:

    1. Записать ассоциацию метки и FEC и RAttributes, полученные от MsgSource.

    Goto LMp.33.

    LMp.14 Является ли LSR входным для FEC? Если нет, goto LMp.16.
    LMp.15 Начать использование метки для переадресации пакетов.
    LMp.16 Запись ассоциации метка-FEC и RAttributes были получены от MsgSource.
    LMp.17 Продолжить итерацию через LMp.31 для каждого партнера. (Смотри замечание 7).
    LMp.18 Послал ли ранее LSR ассоциацию метки и FEC партнерам LSP? (Смотри замечание 8.) Если да, goto LMp.22.
    LMp.19 Используется ли LSR режим упорядоченного управления рассылкой меток Downstream Unsolicited? Если нет, goto LMp.28.
    LMp.20 Исполнить процедуру Prepare_Label_Mapping_Attributes Peer,FEC,RAttributes,SAttributes, IsPropagating, StoredHopCount).
    LMp.21 Исполнить процедуру Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). Goto LMp.28
    LMp.22 Продолжить итерацию через LMp.27 для каждой ассоциации метки и FEC, посланной ранее партнеру.
    LMp.23 Являются ли RAttributes в полученной ассоциации метки взаимно согласующимися с ранее посланными партнеру? Если да, продолжить итерацию через LMp.22 для следующей метки. (Смотри замечание 9.)
    LMp.24 Выполнить процедуру Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).
    LMp.25 Исполнить процедуру Send_Message(Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). (Смотри замечание 10.)
    LMp.26 Обновить запись ассоциации метки с FEC, посланную ранее партнеру, включить новые атрибуты.
    LMp.27 Завершить итерацию через LMp.22.
    LMp.28 Имеет ли LSR какие-либо запросы метки для FEC от партнера, помеченные как ожидающие? Если нет, goto LMp.30.
    LMp.29 LSR выполнить процедуру рассылки метки:
    Для независимого управления в режиме Downstream Unsolicited ИЛИ

    Для упорядоченного управления в режиме Downstream unsolicited

  • Процедура исполнения

    Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount).


  • Выполнить процедуру Send_Label (Peer, FEC, SAttributes). Если процедура терпит неудачу, продолжить итерацию для следующего партнера с LMp.17.


  • Если нет ожидающих запросов для партнера goto LMp.30. (Смотри замечание 11.)


    • Для независимого управления в режиме Downstream On Demand ИЛИ

    Для упорядоченного управления в режиме Downstream On Demand

  • Продолжить итерацию через шаг 5 для каждого ожидающего запроса метки для FEC.


  • Исполнить процедуру Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount)


  • Исполнить процедуру Send_Label (Peer, FEC, SAttributes). Если процедура потерпела неудачу, продолжить итерацию для следующего партнера с LMp.17.


  • Стереть запись ожидающего запроса.


  • Завершить итерацию с шага 1.


  • Goto LMp.30.


    • LMp.30 LSR выполняет процедуру Label Use:
    Для немедленного использования ИЛИ

    для использования, когда нет детектированных петель

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


  • Начать применение метки, полученной и посланной партеру, для переадресации пакетов.


  • Завершить итерацию с шага 1.


  • Goto LMp.31.


    • LMp.31 Завершить итерацию через LMp.17. Goto LMp.33.
    LMp.32 Исполнить процедуру Send_Message (MsgSource, Label Release, FEC, Label).
    LMp.33 DONE.
    Замечания:

  • Если LSR способен объединять метки, он должен получить как минимум одну ассоциацию метки и FEC для рассматриваемого LSP. В случае без объединения может быть получено много ассоциаций меток для FEC.


  • Если LSR детектировал петлю и он ранее не получил от MsgSource ассоциацию метки и FEC, он просто освобождает метку.


  • Соответствует ли метка, полученная в сообщении, какой-либо одной или более ассоциаций, идентифицированных на предыдущем шаге (LMp.4 или LMp.9)?


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


  • Если метка не используется для целей коммутации, шаг LMp.7 не имеет значения.



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


  • LMp.17 итерация включает MsgSource, для того чтобы обработать случай, когда LSR работает в режиме упорядоченного управления Downstream Unsolicited. Упорядоченное управление предотвращает анонсирование метки LSR для FEC, до тех пор пока не получит ассоциацию метки с FEC от узла следующего шага (MsgSource).


  • Если LSR объединяет LSP, он может иметь ранее посланные ассоциации меток и FEC до одного или более партеров. Если LSR не может объединять метки, он может посылать ассоциации меток LSP по большей части до одного LSR.


  • При этом тестировании рассматривается атрибут детектирования петель в векторе пути. Если полученный RAttributes включает в себя вектор пути, и ранее партнеру вектор пути не посылался, или если полученный вектор пути не согласуется с аналогичным вектором, посланным ранее партнеру, тогда атрибуты считаются несогласованными. Заметим, что от LSR не требуется запоминание полученного вектора пути, после того как он переслал вектор в сообщении ассоциации метки. Если LSR не запоминает вектор пути, у него нет способа проверить взаимную согласованность вновь полученного вектора пути. Это означает, что когда бы LSR ни получал сообщение, содержащее вектор пути, он должен всегда передавать его дальше.


  • Шаги с LMp.22 по LMp.27 имеют дело с ситуацией, которая может иметь место, когда LSR использует независимое управление и получает метки со стороны нижерасположенного партнера, после этого он посылает эти сообщения вверх по течению. В этой ситуации LSR следует передавать любые изменения атрибутов, таких как число шагов, вверх. Если сконфигурировано детектирование петель, передаваемые атрибуты должны содержать вектор пути.


  • LSR, работающий в режиме Downstream Unsolicited, должен обработать любое приходящее сообщение запроса метки. Если имеются отложенные запросы метки, переходим в режим Downstream on Demand, для того чтобы удовлетворить отложенные запросы.



    • A.1.Распознавание нового FEC

    Краткое изложение:
    Отклик LSR на получение данных о новом FEC из маршрутной таблицы может включать в себя одну или более операций:
  • Передача ассоциации метка-FEC одному или более партнерам LDP;

  • Передача запроса метки для FEC узлу следующего шага;

  • Любая из этих операций может реализоваться, когда LSR получает ассоциацию метка-FEC от узла следующего шага.
    Контекст:
  • LSR. LSR, обрабатывающий события.

  • FEC. Вновь распознанный FEC.

  • Next Hop. Следующий шаг для FEC.

  • InitAttributes. Атрибуты, которые должны быть сопряжены с новым FEC. (Смотри замечание 1).

  • SAttributes. Атрибуты, которые должны быть включены в ассоциацию метки или в сообщение запроса метки, если они имеются, то посылаются партнеру.

  • StoredHopCount. Число шагов, сопряженное с ассоциацией метка-FEC, (если имеется) полученное ранее от узла следующего шага.

    • Алгоритм:
    FEC.1 Выполнение LSR процедуры рассылки меток:
    Для независимого управления в режиме Downstream Unsolicited
  • Осуществить итерацию через шаг 5 для каждого из партнеров.

  • Получил ли LSR ранее и сохранил ли ассоциацию метка-FEC от узла следующего шага? Если да, установить флаг рассылки равным IsPropagating. Если нет, - установить равным NotPropagating.

  • Исполнить процедуру Prepare_Label_Mapping_Attributes(Peer, FEC, InitAttributes, SAttributes, Propagating, Unknown hop count(0)).

  • Исполнить процедуру Send_Label (Peer, FEC, SAttributes)

  • Завершить итерацию через шаг 1. Goto FEC.2.

  • Для упорядоченного управления в режиме Downstream Unsolicited

  • Выполнить итерацию через шаг 5 для каждого из партнеров.

  • Является ли LSR выходным для этого FEC? ИЛИ получил ли LSR ранее от узла следующего шага и сохранил ли ассоциацию метка-FEC?

    Если нет, продолжить итерацию для следующего партнера.

  • Исполнить процедуру Prepare_ Label_ Mapping_Attributes( Peer, FEC, InitAttributes, SAttributes, Propagating, StoredHopCount).

  • Исполнить процедуру Send_Label (Peer, FEC, SAttributes)

  • Завершить итерацию в точке 1. Goto FEC.2.

    • Для независимого управления в режиме Downstream On Demand ИЛИ

    Для упорядоченного управления в режиме Downstream On Demand

    1. Goto FEC.2. (Смотри замечание 2.)

    FEC.2 Получил ли LSR ранее от узла следующего шага и сохранил ли ассоциацию метка-FEC? Если да, goto FEC.5
    FEC.3 Является ли следующим шагом партнер LDP? Если нет, Goto FEC.6
    FEC.4 LSR выполняет процедуру запроса метки:
    В отсутствии запросов

    1. Goto FEC.6

    Для запроса, когда необходимо ИЛИ

    для запроса по запросу

  • Исполнить процедуру Prepare_Label_Request_Attributes(Next Hop, FEC, InitAttributes, SAttributes);


  • Исполнить процедуру Send_Label_Request (Next Hop, FEC, SAttributes).


    • Goto FEC.6.

    FEC.5 Генерировать событие: От узла следующего шага получена ассоциация метки. (Смотри замечание 3.)
    FEC.6 DONE.
    Замечания:

  • Примером атрибута, который может быть частью InitAttributes, является атрибут спецификации желательных характеристик LSP, таких как класс услуг ( CoS). (Заметим, что в то время как текущая версия LDP не специфицирует атрибут CoS, это могут делать расширения).

    Заметим, что InitAttributes не включают в себя известное число шагов или вектор пути.

  • LSR, использующий режим рассылки меток Downstream On Demand, пошлет метку, только если он ранее получил запрос метки, помеченный как ожидающий. LSR не будет иметь таких ждущих запросов, так как он реагирует на любой запрос метки для неизвестного FEC путем посылки запрашивающему LSR уведомления No Route (нет маршрута) и отбрасыванием такого запроса; смотри LRq.3


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



    • A.1.Запрос получения метки

    Краткое изложение:
    Отклик LSR на подтверждение запроса FEC-метки от партнера LDP может включать одну или более операций:
  • Cообщение уведомления запрашивающему LSR, объясняющее, почему не может быть присвоена метка для данного FEC;

  • Передача сообщения присвоения метки для FEC запрашивающему LSR;

  • Передача узлу следующего шага запроса метки для FEC;

  • Инсталляция меток для переадресации пакетов LSR.
    Контекст:
  • LSR. LSR, обрабатывающий событие.

  • MsgSource. LDP-партнер, который посылает сообщение.

  • FEC. FEC, специфицированный в сообщении.

  • RAttributes. Атрибуты, полученные в сообщении. Например, число шагов, вектор пути.

  • SAttributes. Атрибуты, подлежащие включению в сообщение запроса метки, и передаваемые узлу следующего шага FEC.

  • StoredHopCount. Число шагов, если таковые имеются, записанные ранее для FEC.

    • Алгоритм:

    LRq.1 Исполняемая процедура Check_Received_Attributes (MsgSource, LabelRequest, RAttributes). Если детектирована петля, goto LRq.13.
    LRq.2 Имеется следующий шаг для FEC? Если нет, goto LRq.5.
    LRq.3 Является ли MsgSource следующим шагом? Если нет, goto LRq.6.
    LRq.4 Исполняется процедура Send_Notification (MsgSource, Loop Detected). Goto LRq.13
    LRq.5 Исполняется процедура Send_Notification (MsgSource, No Route). Goto LRq.13.
    LRq.6 LSR получил запрос метки для FEC от MsgSource?

    Если нет, goto LRq.8. (Смотри замечание 1.)
    LRq.7 Является ли запрос метки задублированным?

    Если да, Goto LRq.13. (Смотри замечание 2.)
    LRq.8 Записать запрос метки для FEC, полученный от MsgSource и пометить его, как ожидающий.
    LRq.9 LSR выполняет процедуру рассылки метки:

    Для независимого управления в режиме Downstream Unsolicited ИЛИ

    Для независимого управления в режиме Downstream On Demand
  • Получил ли LSR и сохранил ли метку от узла следующего шага для FEC?.
    Если да, установить переадресацию на IsPropagating.
    Если нет, установить переадресацию на NotPropagating.
  • Исполняемая процедура
    Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, Propagating, StoredHopCount).

  • Исполнить процедуру Send_Label (MsgSource, FEC, SAttributes).


  • Является ли LSR выходным для FEC? ИЛИ


    • Получил ли LSR и сохранил ли метку от узла следующего шага для FEC?

    Если да, goto LRq.11. Если нет, goto LRq.10.

    Для упорядоченного управления в режиме Downstream Unsolicited ИЛИ

    для упорядоченного управления в режиме Downstream On Demand

  • Является ли LSR выходным для FEC? ИЛИ

    Получил ли LSR и сохранил ли метку от узла следующего шага для FEC? (Смотри замечание 3.) Если нет, goto LRq.10.

  • Исполняемая процедура

    Prepare_Label_Mapping_Attributes(MsgSource,FEC,RAttributes,SAttributes,IsPropagating,StoredHopCount)

  • Исполнить процедуру Send_Label(MsgSource, FEC, SAttributes).


    • Goto LRq.11.

    LRq.10 LSR выполнить процедуру запроса метки:
    Если запрос запрещен

    1. Goto LRq.13.

    Для режима запрос по необходимости ИЛИ

    для режима запрос на запрос

  • Исполнить процедуру Prepare_Label_Request_Attributes (Next Hop, FEC,RAttributes, SAttributes);


  • Исполнить процедуру Send_Label_Request (Next Hop, FEC, SAttributes).


    • Goto LRq.13.

    LRq.11 Послал ли LSR успешно метку для FEC в MsgSource?

    Если нет, goto LRq.13. (Смотри замечание 4.)
    LRq.12 LSR выполнить процедуру Label Use.
    Для немедленного использования ИЛИ

    для применения, если петля не детектирована

    1. Инсталлировать метку, посланную MsgSource и метку из узла следующего шага (если LSR не является выходным) для выполнения переадресации.

    LRq.13 DONE

    Замечания:

  • В случае, когда MsgSource является LSR, неспособным объединять метки, он пошлет запрос метки каждому партнеру LDP выше по течению, с целью получения метки для заданного FEC. LSR должен быть способен отличать такие запросы от MsgSource без поддержки объединения от дублирующих запросов метки.

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

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

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

  • Если LSR не поддерживает объединение меток, такая проверка потерпит неудачу.


  • Процедура Send_Label может потерпеть неудачу из-за недостатка ресурсов для меток, в таком случае LSR не должен выполнять процедуру Label Use.



    • A.2.Check_Received_Attributes

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

  • MsgType. Тип полученного сообщения.

  • RAttributes. Атрибуты в сообщении.

    • Дополнительный контекст:
  • LSR Id. Уникальный Id данного LSR.

  • Hop Count. Число шагов, если таковые имеются в полученных атрибутах.

  • Path Vector. Вектор пути, если таковой имеется в полученных атрибутах.

    • Алгоритм:

    CRa.1 Включает ли в себя RAttributes число шагов? Если нет, goto CRa.5.
    CRa.2 Превышает ли число шагов максимально допустимый порог?

    Если да, goto CRa.6.
    CRa.3 Включает ли в себя RAttributes вектор пути? Если нет, goto CRa.5.
    CRa.4 Включает ли в себя вектор пути Id LSR? ИЛИ превышает ли длина вектора пути максимально допустимый порог? Если да, goto CRa.6
    CRa.5 Прислать в ответ No Loop Detected (петель не зарегистрировано).
    CRa.6 Является ли MsgType (тип сообщения) LabelMapping?

    Если да, goto CRa.8. (Смотри замечание 1.)
    CRa.7 Исполнить процедуру Send_Notification(MsgSource, Loop Detected)
    CRa.8 Прислать флаг обнаружения петли
    CRa.9 DONE

    Замечания:
  • Когда проверяемые атрибуты получены в сообщении присвоения метки, LSR посылает уведомление об обнаружении петли в TLV статусного кода сообщения об освобождении метки. Смотри раздел "Получение присвоения метки".




    • A.2.Prepare_Label_Mapping_Attributes

    Краткое изложение:
    Эта процедура используется всякий раз, когда нужно послать партнеру сообщение присвоения метки, содержащее число шагов и вектор пути.
    Параметры:
  • Peer. LDP-партнер, которому посылается сообщение.

  • FEC. FEC, для которого посылается запрос метки.

  • RAttributes. Атрибуты, которые этот LSR ассоциирует с LSP для FEC.

  • SAttributes. Атрибуты, подлежащие включению в сообщение присвоения метки.

  • IsPropagating. LSR посылает сообщение присвоения метки, чтобы реализовать рассылку метки, которую он получил от узла следующего шага для заданного FEC.

  • PrevHopCount. Число шагов, которые LSR ассоциирует с LSP для FEC.
    Дополнительный контекст:
  • LSR Id. Уникальный Id данного LSR.

    • Алгоритм:

    PMpA.1 Нужно ли число шагов для данного партнера (смотри замечание 1.)? ИЛИ

    Включает ли RAttributes число шагов? ИЛИ

    Сконфигурировано ли на данном LSR детектирование петель?

    Если нет, goto PMpA.21.
    PMpA.2 Является ли LSR выходным для FEC? Если нет, goto PMpA.4.
    PMpA.3 Включить число шагов 1 в SAttributes. Goto PMpA.21.
    PMpA.4 Имеет ли RAttributes число шагов? Если нет, goto PMpA.8.
    PMpA.5 Является ли LSR краевым для домена, чьи LSR не осуществляют декрементацию TTL И

    Находится ли партнер в этом домене (Смотри замечание 2).

    Если нет , goto PMpA.7.
    PMpA.6 Включить число шагов 1 в SAttributes. Goto PMpA.9.
    PMpA.7 Инкрементировать число шагов RAttributes и скопировать результат

    в SAttributes. Смотри замечание 2. Goto PMpA.9.
    PMpA.8 Включить число шагов = unknown (0) в SAttributes.
    PMpA.9 Сконфигурировано ли на данном LSR детектирование петель?

    Если нет, goto PMpA.21.
    PMpA.10 Имеют ли RAttributes вектор пути? Если да, goto PMpA.19.
    PMpA.11 Пересылает ли LSR полученные данные о присвоенных метках?

    Если нет , goto PMpA.20.
    PMpA.12 Поддерживает ли LSR объединение меток? Если нет, goto PMpA.14.
    PMpA.13 Посылал ли LSR партнеру ранее сообщение присвоения метки для FEC? Если нет, goto PMpA.20.
    PMpA.14 Включает ли RAttributes число шагов? Если нет, goto PMpA.21.
    PMpA.15 Равно ли число шагов в Rattributes unknown (0)? Если да, goto PMpA.20.
    PMpA.16 Посылал ли LSR ранее партнеру сообщение присвоения метки для FEC? Если нет goto PMpA.21.
    PMpA.17 Отличается ли число шагов в RAttributes от PrevHopCount?

    Если нет goto PMpA.21.
    PMpA.18 Является ли число шагов в RAttributes > PrevHopCount? ИЛИ

    Является ли PrevHopCount unknown(0) Если нет, goto PMpA.21.
    PMpA.19 Добавить Id LSR в начало вектора пути из RAttributes и скопировать результат в SAttributes. Goto PMpA.21.
    PMpA.20 Включить вектор пути длиной 1, содержащий Id LSR в SAttributes.
    PMpA.21 DONE.

    Замечания:
  • Канал до партнера может требовать, чтобы число шагов было включено в сообщения присвоения метки; например, смотри [RFC3035] и [RFC3034].

  • Если LSR является пограничным для облака LSR, которые не выполняют декрементацию TTL и он осуществляет пересылку сообщений присвоения меток вверх по течению в этом облаке, он устанавливает число шагов равным 1, так что число шагов через облако оказывается вычисленным верно. Это гарантирует правильное управление TTL для пакетов переадресуемых через область LSP, которая проходит через облако.

  • Для арифметики числа шагов, unknown + 1 = unknown.

    • Назад:

    Оглавление:
    Вперёд:



    A.2.Prepare_Label_Request_Attributes

    Краткое изложение:
    Эта процедура используется всякий раз, когда нужно послать партнеру запрос метки, чтобы вычислить число шагов и вектор пути для включения в сообщение.
    Параметры:
  • Peer. LDP-партнер, которому должно быть послано сообщение.

  • FEC. FEC, для которого нужно послать запрос метки.

  • RAttributes. Атрибуты, которые этот LSR ассоциирует с LSP для FEC.

  • SAttributes. Атрибуты, которые следует включить в сообщение запроса метки.
    Дополнительный контекст:
  • LSR Id. Уникальный Id данного LSR.

    • Алгоритм :

    PRqA.1 Нужно ли число шагов данному партнеру (Смотри замечание 1.)? ИЛИ Содержат ли RAttributes число шагов? ИЛИ Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PRqA.14.
    PRqA.2 Является ли LSR входным для FEC? Если нет, goto PRqA.6.
    PRqA.3 Включить число шагов 1 в SAttributes.
    PRqA.4 Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PRqA.14.
    PRqA.5 Способен ли LSR объединять метки?

    Если да, goto PRqA.14. Если нет, goto PRqA.13.
    PRqA.6 Включают ли RAttributes в себя число шагов? Если нет, goto PRqA.8.
    PRqA.7 Инкрементировать число шагов в RAttributes и копировать полученное значение в SAttributes. (Смотри замечание 2.) Goto PRqA.9.
    PRqA.8 Включить число шагов = unknown 0) в SAttributes.
    PRqA.9 Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PRqA.14.
    PRqA.10 Имеют ли RAttributes вектор пути? Если да, goto PRqA.12.
    PRqA.11 Способен ли LSR объединять метки? Если да, goto PRqA.14. Если нет, goto PRqA.13.
    PRqA.12 Добавить Id LSR в начало вектора пути из RAttributes и скопировать результат в SAttributes. Goto PRqA.14.
    PRqA.13 Включить вектор пути с длиной 1, содержащий Id LSR в SAttributes.
    PRqA.14 DONE.

    Замечания:
  • Канал с партнером может требовать, чтобы число шагов было включено в запрос метки; смотри, например [RFC3035] и [RFC3034].

  • Для арифметики числа шагов, unknown + 1 = unknown.




    • A.2.Send_Label_Request

    Краткое изложение:
    LSR использует процедуру Send_Label_Request для посылки партнеру LDP запроса метки для FEC, если в текущий момент это разрешено.
    Параметры:
  • Партнер. LDP-партнер, которому следует послать запрос метки.

  • FEC. FEC, для которого послан запрос метки.

  • Атрибуты. Атрибуты, подлежащие включению в запрос метки. Например, число шагов, вектор пути.
    Дополнительный контекст:
  • LSR. LSR, выполняющий процедуру.

    • Алгоритм:

    SLRq.1 Был ли ранее послан партнеру запрос метки для FEC и помечен ли он как неисполненный? Если да, вернуть флаг успеха. (Смотри замечание 1.)
    SLRq.2 Свидетельствует ли статусная запись о готовности послать запросы метки набору партнеров?

    Если нет, goto SLRq.6
    SLRq.3 Исполнить процедуру Send_Message(Peer, Label Request, FEC, Attributes).
    SLRq.4 Запись запроса метки для FEC была послана партнеру и помечена как нереализованная.
    SLRq.5 Вернуть флаг успеха
    SLRq.6 Отложить запрос метки путем записи ассоциации метка- FEC и необходимых атрибутов от партнера в ситуации, когда ресурсов для метки нет.
    SLRq.7 Вернуть флаг неудачи.

    Замечания:
  • Если LSR не может объединять метки, он должен различать попытки посылки запросов меток для FEC, отправленные разными вышестоящими LDP-партнерами, от дублирующих запросов. Эта процедура не посылает дублирующих запросов меток.




    • A.2.Send_Label_Withdraw

    Краткое изложение:
    LSR использует процедуру Send_Label_Withdraw (посылка запроса отзыва метки), чтобы отозвать метку для данного FEC у LDP-партнера. Чтобы выполнить это, LSR посылает партнеру сообщение отзыва метки (Label Withdraw).
    Параметры:
  • Партнер. LDP партнер, которому должно быть послано сообщение отзыва метки.

  • FEC. FEC, для которого должна быть отозвана метка.

  • Метка. Метка, подлежащая отзыву.
    Дополнительный контекст:
  • LSR. LSR, выполняющий процедуру.

    • Алгоритм:

    SWd.1 Исполнить процедуру Send_Message(Peer, Label Withdraw, FEC, Label)
    SWd.2 Запись отзыва метки для FEC была помечена как нереализованная и послана партнеру.




    A.2.Send_Label

    Краткое изложение:
    Процедура Send_ Label, если возможно, присваивает метку для LDP партнерf, и посылает партнеру ассоциацию метка-FEC. Если LSR не может присвоить метку, и если он имеет отложенный запрос метки от партнера, он посылает LDP-партнеру уведомление No Label Resources (нет ресурсов для метки).
    Параметры:
  • Партнер. LDP-партнер, которому следует послать ассоциацию метки.

  • FEC. FEC, для которого послана присвоенная метка.

  • Атрибуты. Атрибуты, подлежащие включению в ассоциацию метки.
    Дополнительный контекст:
  • LSR. LSR, выполняющий процедуру.

  • Метка. Присвоенная метка, посланная партнеру.

    • Алгоритм:

    SL.1 Должен ли LSR присвоить метку? Если нет, goto SL.9.
    SL.2 Присвоить метку и связать ее с FEC.
    SL.3 Ввести метку в таблицу маршрутизации.
    SL.4 Исполнить процедуру Send_Message(Peer, Label Mapping, FEC, Label, Attributes).
    SL.5 Записать ассоциацию метка-FEC и атрибуты, посланные партнеру.
    SL.6 Имеет ли LSR запись запроса метки от партнера, помеченную, как отложенная? Если нет, goto SL.8.
    SL.7 Стереть запись отложенного запроса метки партнера
    SL.8 Вернуть флаг успеха.
    SL.9 Имеет ли LSR запрос метки для FEC от партнера, помеченный как отложенный? Если нет, goto SL.13.
    SL.10 Исполнить процедуру Send_Notification(Peer, No Label Resources).
    SL.11 Стереть запись отложенного запроса метки, поступившего от партнера.
    SL.12 Запись уведомления No Label Resources послана партнеру.

    Goto SL.14.
    SL.13 Нужна запись присвоения метки для FEC и атрибуты для партнера, но нет ресурсов для метки. (Смотри замечание 1.)
    SL.14 Вернуть флаг неудачи.

    Замечания:
  • SL.13 обрабатывает ситуацию рассылки меток в режиме Downstream Unsolicited, когда LSR неспособен присвоить метку для FEC, чтобы послать партнеру.




    • A.2.Send_Message

    Краткое изложение:
    LSR использует процедуру Send_Message, чтобы послать LDP-партнеру LDP-сообщение.
    Параметры:
  • Peer. LDP партнер, которому надо послать сообщение.

  • Message Type. Тип сообщения, которое нужно послать.

  • Дополнительное содержимое сообщения . . . .

    • Алгоритм:
    Эта процедура является средством, с помощью которого LSR отправляет LDP-сообщение специфицированного типа специфицированному LDP-партнеру.



    A.2.Send_Notification

    Краткое изложение:
    LSR использует процедуру Send_ Notification, чтобы послать LDP-партнеру сообщение уведомления.
    Параметры:
  • Партнер. LDP-партнер, которому посылается уведомление.

  • Статус. Статусный код, подлежащий включению в сообщение уведомления.

    • Алгоритм:

    SNt.1 Исполнить процедуру Send_Message(Peer, Notification, Status)




    A.3 Сценарий 8 (или менее) BA, общее управление трафиком, общая защита MPLS

    Сервис провайдер, работающий через MPLS с 8 (или менее) BA, управляющий трафиком (т.е., реализующий выбор одного общего маршрута для всех BA), может выбрать режим Diff-Serv с одним E-LSP на каждый FEC. При этом обеспечивается общая защита MPLS (т.е., восстановление услуг для всех PSC) и используются вставные заголовки MPLS. Каналы формируются посредством RSVP [RSVP_MPLS_TE] или CR-LDP [CR-LDP_MPLS_TE] с привлечением предварительной конфигурации таблиц соответствия. Процедуры можно суммировать следующим образом:

  • Сервис провайдер конфигурирует в каждом LSR двунаправленное соответствие между каждым PHB и значением поля EXP (например, 000<-->AF11, 001<-->AF12, 010<-->AF13)

  • Сервис провайдер конфигурирует каждый LSR, и задает в каждом интерфейсе алгоритм формирования трафика каждого PSC (например, полосу пропускания, выделяемую для AF1) и приоритеты отбрасывания пакетов для каждого PHB (например, схему отбрасывания для AF11, AF12, AF13)

  • LSR формирует по одному E-LSP на FEC, которые будут использовать предварительное конфигурирование таблиц соответствия:

  • используя протокол RSVP, как это специфицировано выше (т.e., отсутствие объекта DIFFSERV RSVP в сообщении PATH, содержащем объект LABEL_REQUEST), или

  • используя протокол CR-LDP, как это специфицировано выше (т.е., отсутствие Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping).

  • защита активизируется для всех E-LSP, для того чтобы осуществить защиту MPLS за счет механизмов, находящихся за пределами рассмотрения в данном документе.



    A.4 Сценарий управление трафиком для каждого OA /защита MPLS

    Сервис провайдер, который работает через MPLS с любым числом BA, осуществляет управление трафиком для каждого OA (т.е., выбирая отдельный путь для каждого OA) и выполняет защиту MPLS для каждого OA в сети (т.е., выполняет защиту с потенциально разными уровнями защиты для различных OA), может выбрать режим Diff-Serv через MPLS с использованием одного L-LSP на , эта пара устанавливается посредством RSVP или CR-LDP. Процедуры можно суммировать следующим образом:

  • Сервис провайдер конфигурирует каждый LSR и задает для каждого интерфейса алгоритм формирования трафика каждого PSC (например, полосу пропускания, выделяемую для AF1) и приоритеты отбрасывания пакетов для PHB (например, схему отбрасывания для AF11, AF 12, AF13);

  • LSR формирует по одному L-LSP для каждого :

  • используя RSVP, как это описано выше, для согласования L-LSP PSC (т.е., объекта DIFFSERV RSVP в сообщении PATH, содержащем LABEL_REQUEST), или

  • используя протокол CR-LDP, как это специфицировано выше, для согласования L-LSP PSC (т.е., Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping).

  • активируется разный уровень защиты (потенциально разный уровень защиты для каждого PSC).



    A.6 Сценарий отсутствие управления

    Сервис провайдер, который не выполняет управление трафиком и не осуществляет защиту MPLS для 8 (или менее) BA, выполняет управление трафиком для каждого OA/защиту MPLS для прочих BA (т.е., формирует отдельный путь для каждого OA, соответствующего другим BA и осуществляет защиту MPLS с потенциально разной политикой для каждого из этих OA) и использует вставные заголовки MPLS, может выбрать режим Diff-Serv через MPLS, используя для каждого FEC:

  • один E-LSP, использующий предварительную конфигурацию таблиц соответствия, формируемых посредством LDP, чтобы поддерживать набор из 8 (или менее) BA без управления трафиком/без защиты, и

  • один L-LSP на пару , сформированную посредством RSVP или CR-LDP для поддержки других BA.
    Процедуры можно суммировать следующим образом:

  • Сервис провайдер конфигурирует для каждого LSR двунаправленное соответствие между PHB и значением поля EXP для BA, поддерживаемых через E-LSP;

  • Сервис провайдер конфигурирует каждый LSR и задает для каждого интерфейса алгоритм формирования трафика PSC, поддерживаемый в E-LSP и приоритеты отбрасывания пакетов для каждого PHB;

  • Сервис провайдер конфигурирует каждый LSR и задает для каждого интерфейса алгоритм формирования трафика PSC, поддерживаемый в L-LSP и приоритеты отбрасывания пакетов для каждого PHB;

  • LSR сообщают об установлении отдельного E-LSP для каждого FEC в отсутствии управления трафиком для BA, используя LDP, как это специфицировано выше (т.е., без Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping);

  • LSR сообщают об установлении отдельного L-LSP при для остальных BA:

  • используя протокол RSVP, как это специфицировано выше, для установления L-LSP PSC (т.е., объект DIFFSERV RSVP в сообщении PATH, содержащем объект LABEL_REQUEST), или

  • используя протокол CR-LDP, как это специфицировано выше, для установления L-LSP PSC (т.е., Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping).

  • для E-LSP защита не реализуется.

  • в разных L-LSP достигается соответствующий уровень защиты (потенциально с разным уровнем защиты, зависящим от L-LSP PSC).



    A.Обработка событий при рассылке меток

    В данном разделе определены процедуры LDP рассылки меток, путем описания алгоритма для каждого варианта рассылки. Требования, предъявляемые к реализации LDP, заключаются в том, что обработка событий должна иметь результат, специфицированный алгоритмом. То есть, реализация не должна следовать в точности шагам, описанным в алгоритме, если достигается аналогичный результат.
    Алгоритмы для обработки событий, сопряженных с рассылкой меток, используют аналогичные операции. Приведенные ниже спецификации объединяют эти операции в процедурные блоки. Спецификации этих общих процедур содержатся в разделе "Общие процедуры рассылки меток".
    Реализация должна использовать структуры данных, чтобы хранить информацию о протокольной активности. В этом приложении специфицирована информация, которую следует записывать, чтобы охарактеризовать статус алгоритма.



    A.Общие процедуры рассылки меток

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



    A.Сценарий 8 (или менее) BA, отсутствие управления трафиком, отсутствие защиты MPLS

    Сервис провайдер, работающий с 8 (или меньше) BA через MPLS, без управления трафиком, без MPLS-защиты и использующий инкапсуляцию вставных заголовков MPLS, может решить работать с Diff-Serv через MPLS, используя по одному E-LSP на FEC, сформированные посредством LDP. Кроме того, сервис провайдер может решить использовать предварительно сконфигурированную таблицу EXP<-->PHB. Процедуры можно суммировать следующим образом:

  • Сервис провайдер конфигурирует для каждого LSR, двунаправленное соответствие между каждым PHB и значением поля EXP (например, 000<-->AF11, 001<-->AF12, 010<-->AF13);

  • Сервис провайдер конфигурирует для каждого LSR, и для каждого интерфейса, порядок обработки каждого PSC (например, полоса пропускания, выделяемая AF1) и приоритеты отбрасывания для каждого PHB (например, режим отбрасывания для AF11, AF12, AF13);

  • LSR формирует один E-LSP на один FEC, используя LDP в соответствии со спецификацией, представленной выше (т.е., без Diff-Serv TLV в сообщениях LDP запрос метки/ассоциация метки, неявно указывая на то, что является E-LSP и что он использует предварительно сконфигурированное соответствие).



    A.Сценарий 8 (или менее) BA, управление трафиком для каждого OA /защита MPLS

    Сервис провайдер работающий через MPLS с 8 (или менее) BA, выполняя управление трафиком для каждого OA (т.е., формируя отдельный маршрут для каждого OA) и выполняя защиту MPLS для каждого OA (т.е., осуществляя защиту с потенциально разными уровнями для разных OA), может выбрать работу с Diff-Serv через MPLS, используя по одному E-LSP на пару , определяемую посредством RSVP или CR-LDP. Кроме того, сервис провайдер может выбрать предварительное конфигурирование таблиц согласования для всех E-LSP. Процедуры можно суммировать следующим образом:

  • Сервис провайдер конфигурирует для каждого LSR двунаправленное соответствие между PHB и значением поля EXP (например, 000<-->AF11, 001<-->AF12, 010<-->AF13)

  • Сервис провайдер конфигурирует каждый LSR и задает для каждого интерфейса, алгоритм формирования трафика каждого PSC (например, полосу пропускания, выделенную для AF1) и приоритеты отбрасывания пакетов для каждого PHB (например, схему отбрасывания для AF11, AF12, AF13)

  • LSR согласует формирование одного E-LSP для каждого :

  • используя протокол RSVP, как это специфицировано выше, для уведомления о том, что LSP является E-LSP, который использует предварительно сконфигурированную таблицу соответствий (т.е., отсутствие объекта DIFFSERV RSVP в сообщении PATH, содержащем LABEL_REQUEST), или

  • используя протокол CR-LDP, как это специфицировано выше, для уведомления о том, что LSP является E-LSP, который использует предварительно сконфигурированную таблицу соответствий (т.е., отсутствие Diff-Serv TLV в сообщениях LDP Label Request/Mapping)

  • Сервис провайдер конфигурирует для каждого E-LSP в начальном конце этого пути критерии отбора/переадресации так, чтобы только пакеты, принадлежащие данному OA, переадресовывались в E-LSP, сформированный для соответствующего FEC и OA.

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



    A.Сценарий Более 8 BA, отсутствие управления трафиком, отсутствие защиты MPLS

    Сервис провайдер, работающий через MPLS с более чем 8 BA, без управления трафиком, без использования MPLS защиты и с применением вставных заголовков MPLS, может выбрать режим Diff-Serv поверх MPLS для каждого FEC:

  • один E-LSP, сформированный с помощью LDP и использующий предварительно сконфигурированную таблицу соответствия для поддержания набора из 8 (или менее) BA, и

  • один L-LSP, для каждой пары , сформированных посредством LDP для поддержания других BA.
    Процедуры можно суммировать следующим образом:

  • Сервис провайдер конфигурирует в каждом LSR двунаправленное соответствие между каждым PHB и значением поля EXP для BA транспортируемого через E-LSP;

  • Сервис провайдер конфигурирует каждый LSR и определяет в каждом интерфейсе, алгоритм формирования трафика каждого PSC, поддерживаемого для E-LSP , задает приоритеты отбрасывания пакетов для каждого PHB;

  • Сервис провайдер конфигурирует каждый LSR и определяет в каждом интерфейсе алгоритм формирования трафика каждого PSC, поддерживаемого для L-LSP и задает приоритеты отбрасывания пакетов для каждого PHB;

  • LSR согласуют формирование отдельного E-LSP для каждого FEC набора E-LSP, транспортирующего BA, используя LDP, как это специфицировано выше (т.е., без Diff-Serv TLV в LDP сообщениях Label Request/Label Mapping, чтобы неявно индицировать, что LSP является E-LSP и что он использует предварительно сконфигурированные таблицы соответствия).

  • LSR согласуют формирование отдельного L-LSP на каждую пару для прочих BA, используя LDP, как это специфицировано выше (т.е., Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping, чтобы индицировать L-LSP PSC).



    Административная информация состояний

    Административная статусная информация содержится в объекте Admin_Status. Объект предоставляет информацию, относящуюся к административному состоянию конкретного LSP. Информация используется двумя способами. В первом, объект содержится в сообщениях Path и Resv для указания административного состояния LSP. Во втором, объект транспортируется в сообщении уведомления для запроса к входному узлу изменить административное состояние LSP.



    Адрес пересылки PDP (PDPRedirAddr)

    PDP при закрытии PEP-сессии для конкретного типа клиента может опционно использовать этот объект для того чтобы переадресовать PEP на специфицированный адрес сервера и заданный порт TCP:
    C-Num = 13,
    C-Type = 1, IPv4-адрес+ TCP порт
    0123
    Формат IPv4-адреса

    /////////////////////////TCP Port Number
    C-Type = 2, IPv6-адрес + TCP порт

    012>3 
    Формат IPv6-адреса
     



    Агрегатирование

    В уникастинге различные адреса места назначения объединяются в одной записи маршрутной таблицы, предоставляя один FEC и один LSP.
    Гранулярность мультикастинг потоков равна (*, G) для совмещенных деревьев и (S,G) для деревьев отправителя, где S - адрес отправителя, а G - мультикастинг адрес группы.

    Одним из путей распределения трафика в FEC является создание отдельного FEC для каждого адресного префикса, появляющегося в маршрутной таблице. Однако в пределах области MPLS, это может вызвать определенные последствия для набора FEC, в частности, все потоки в этих FEC будут следовать одним и тем же маршрутом. Например, набор различных адресных префиксов может иметь один и тот же выходной узел, а обмен меток может быть использован только для доставки трафика до выходного узла. В этом случае, в пределах домена MPLS, объединение таких FEC само является классом FEC. Это предлагает выбор: следует ли ассоциировать отдельные метки с каждым компонентом FEC, или следует ли ассоциировать отдельную метку с объединением, а метку использовать для всего трафика в объединении? Процедура ассоциации отдельной метки с объединением FEC, который сам является FEC (внутри некоторого домена), и применения меток для трафика в объединении, называется "агрегатированием". Архитектура MPLS допускает агрегатирование. Агрегатирование может уменьшить число меток, с которыми нужно иметь дело заданному набору пакетов, и может сократить объем управляющего трафика.
    Данный набор FEC, который является "агрегатируемым" в одном FEC, допускается (a) агрегатировать их в один FEC, (b) агрегатировать их в набор FEC, или (c) не агрегатировать их совсем. Таким образом, мы можем говорить о "гранулярности" агрегатирования, начиная с (a) "грубой гранулярности", кончая (c) "тонкой гранулярностью".
    Когда используется упорядоченное управление, каждый LSR должен адаптировать для данного набора FEC гранулярность, используемую на следующем шагу для этих FEC.
    Когда используется независимое управление, допускается, чтобы имелись два смежных LSR, Ru и Rd, которые агрегатируют некоторый набор FEC по-разному.
    Если Ru имеет более тонкую гранулярность, чем Rd, это не создает проблем. Это означает, что, когда Ru нужно переадресовать помеченные пакеты для этих FEC в Rd, может потребоваться установить соответствие между n и m метками, где n > m. В качестве опции Ru может отозвать набор из n меток, который он разослал, и затем разослать набор из m меток, соответствующих уровню гранулярности Rd. Совсем не нужно гарантировать корректность операции, но это вызовет сокращение числа меток, разосланных Ru, Ru не получает какого-либо преимущества при рассылке большего числа меток. Решение делать это или нет, является исключительно локальным.
    Если Ru имеет более грубую гранулярность, чем Rd (т.e., Rd разослал n меток для набора FEC, в то время как Ru разослал m, где n > m), имеется два варианта:
    -  Можно принять более тонкий уровень гранулярности для Rd. Это бы потребовало отзыва разосланных m, и рассылки n меток. Это предпочтительная опция.
    -  Можно просто установить соответствие между m метками и субнабором Rd из n меток, если он может определить, что это не изменит маршрутизацию. Например, предположим, что Ru использует одну метку для всех потоков, которые должны пройти определенный выходной LSR, тогда как Rd привязывает к такому трафику некоторое число разных меток, в зависимости от места назначения пакетов. Если Ru знает адрес выходного маршрутизатора, и, если Rd связал метку с FEC, который идентифицирован этим адресом, тогда Ru может просто использовать эту метку.
    В любом случае, каждый LSR должен знать (при конфигурации) какую гранулярность использовать для формируемых меток. Когда используется упорядоченное управление, требуется чтобы каждый узел знал гранулярность только для FEC, который покидает сеть MPLS в этом узле. Для независимого управления, наилучший результат может быть получен, путем конфигурации всех LSR так, чтобы они знали гранулярность каждого FEC. Однако во многих случаях это может быть сделано путем использования одной метки с гранулярностью, которая реализует все FEC (такой как "одна метка на IP-префикс таблицы переадресации" или "одна метка на выходной узел").



    Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)

    Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
    (E. Rosen. Multiprotocol Label Switching Architecture, RFC-3031.)



    AСценарий Более 8 BA, отсутствие управления трафиком, отсутствие защиты MPLS

    Сервис провайдер, работающий через MPLS с более чем 8 BAs, без управления трафиком, без защиты MPLS и использующий вставные заголовки MPLS, может выбрать режим Diff-Serv, используя два E-LSP на один FEC, установленный посредством LDP и согласованные таблицы EXP<-->PHB.
    Процедуры можно суммировать следующим образом:

  • Сервис провайдер конфигурирует для каждого LSR и каждого интерфейса алгоритм формирования трафика PSC (например, полосу пропускания, выделенную для AF1) и приоритеты отбрасывания пакетов для каждого PHB (например, схему отбрасывания для AF11, AF12,AF13)

  • LSR сообщают об установлении двух E-LSP для каждого FEC, используя LDP в соответствии с вышеприведенной спецификацией (т.e., Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping для явного указания того, что LSP является E-LSP, а его таблицей соответствия служит EXP<-->PHB). Согласованное соответствие будет указывать на субнабор 8 (или менее) BA, транспортируемых по каждому E-LSP, и на величины EXP, которые согласованы для каждого BA в каждом E-LSP.
    Приложение B. Примеры сценариев резервирования полосы пропускания



    ATM-коммутаторы в качестве LSR

    Процедуры переадресации MPLS подобны тем, что используются в ATM-коммутаторах. ATM-коммутаторы используют входной порт и значение поля VPI/VCI входящего пакета в качестве индекса в таблице коммутации (cross-connect), из которой они получают номер выходного порта и выходного значения VPI/VCI. Следовательно, если одна или более меток могут быть занесены непосредственно в поля заголовков, которые доступны коммутаторам, тогда коммутаторы после модификации программ смогут быть использованы в качестве LSR. Мы будем называть такие устройства "ATM-LSR". Имеется три способа представления меток в заголовках ячеек ATM (предпочтительно использовать AAL5):
    1. SVC кодирование
    Используется поле VPI/VCI для записи метки, размещенной на верху стека. Эта методика может использоваться в любой сети. Посредством этой методики LSP реализуется как ATM SVC, а протокол рассылки меток становится сигнальным протоколом ATM. ATM-LSR не может выполнять команды "push" или "pop" для стека меток.
    2. SVP кодирование
    Используется поле VPI для записи метки, размещенной на верху стека, а поле VCI для записи второй метки стека, если такая существует. Эта методика имеет некоторые преимущества по отношению к предыдущей, здесь возможно переключение виртуальных каналов с помощью ATM "VP-switching". То есть, LSP реализуются как ATM SVP.
    Однако эта методика не может использоваться всегда. Если сеть включает виртуальный маршрут ATM через ATM-сеть, не поддерживающую MPLS, тогда поле VPI необязательно доступно для использования в MPLS.
    Когда используется этот метод представления, ATM-LSR на выходе виртуального канала VP эффективно реализует операцию "pop".
    3. Многоточечное кодирование SVP
    Для размещения метки на вершине стека используется поле VPI, а для размещения второй метки стека, если таковая имеется, используется часть поля VCI, остальная часть поля VCI служит для идентификации входного LSP. Если применяется эта технология, традиционные возможности ATM VP-коммутации могут использоваться для построения виртуальных маршрутов мультиточка-точка. Ячейки от разных пакетов будут нести тогда разные значения VCI. Как это будет показано в разделе 2.26, это позволяет нам осуществлять объединение меток, не получая проблем перекрытия ячеек, для ATM-коммутаторов, реализующих виртуальные маршруты мультиточка-точка, но которые не имеют возможностей объединения VC.
    Эта методика зависит от наличия возможности присвоения 16-битовых значений VCI каждому ATM-коммутатору, так что ни одно значение VCI не будет соответствовать двум разным коммутаторам.
    Если имеется больше меток в стеке, чем места в заголовке ATM, тогда ATM представление должно комбинироваться с общей инкапсуляцией.



    Атрибут defaultСпецификация политики по умолчанию

    Политика маршрутизации по умолчанию специфицируется с помощью атрибута default. Атрибут default имеет следующий синтаксис:
    default: to [action ] [networks ]
    Спецификации и являются опционными. Семантика выглядит следующим образом: Спецификация указывает на AS (и маршрутизатор, если он имеется) по умолчанию; спецификация , если присутствует, указывает на различные атрибуты конфигурации по умолчанию. Например, относительное предпочтение, если определено несколько маршрутов по умолчанию; а спецификация , если имеется, является фильтром политики. Маршрутизатор использует политику по умолчанию, если он получает от партнера маршруты, которые удовлетворяют требованиям фильтра .
    В следующем примере, AS1 маршрутизируется по умолчанию через AS2.
    aut-num: AS1
    default: to AS2
    В следующем примере, марштутизатор 1.1.1.1 в AS1 маршрутизуется по умолчанию через 1.1.1.2 в AS2.
    aut-num: AS1
    default: to AS2 1.1.1.2 at 1.1.1.1
    В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и AS3, но предпочитает AS2, а не AS3.
    aut-num: AS1
    default: to AS2 action pref = 1;
    default: to AS3 action pref = 2;
    В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и использует 128.9.0.0/16 в качестве сети по умолчанию.
    aut-num: AS1
    default: to AS2 networks { 128.9.0.0/16 }



    Атрибут export: Спецификация экспортной политики

    Аналогично выражение экспортной политики специфицируется с помощью атрибута export. Атрибут export имеет следующий синтаксис:
    export:to [action ]
    . . .
    to [action ]
    announce

    Спецификация действия является опционной. Семантика атрибута export выглядит следующим образом: набор маршрутов, который соответствует пересылается всем партнерам, специфицированным в , в то время как экспортируемые маршруты из , реализуются.
    Например
    aut-num: AS1
    export: to AS2 action med = 5; community .= { 70 }; announce AS4
    В этом примере, маршруты AS4 объявляются автономной системе AS2 со значением атрибута med, равным 5 и атрибута community = 70.
    Пример:
    aut-num: AS1
    export: to AS-FOO announce ANY
    В этом примере, AS1 объявляет все свои маршруты автономным системам AS из набора AS-FOO.



    Атрибут import: Спецификация политики импорта

    В RPSL политика импорта определяется двумя выражениями импортной политики. Каждое выражение импортной политики специфицируется с помощью атрибута import. Атрибут import имеет следующий синтаксис:
    import:from [action ] . . .
    from [action ]
    accept

    Спецификация действия является опционной. Семантика атрибута import выглядит следующим образом: набор маршрутов, который соответствует импортируется от всех партнеров в , в то время как импортируемые маршруты , <>ction-M> реализуются.
    Например
    aut-num: AS1
    import: from AS2 action pref = 1; accept { 128.9.0.0/16 }
    Этот пример утверждает, что маршрут 128.9.0.0/16 воспринят от AS2 с предпочтением 1. Далее рассматривается спецификация действий (action).



    Атрибуты ассоциации меток (Label Binding)

    Конкретная ассоциация метки L и класса FEC F, анонсируемая Rd для Ru, может иметь соответствующие атрибуты. Если Ru работает как нижестоящий LSR, и анонсирует ассоциацию метки и класса FEC F, тогда при определенных обстоятельствах, может оказаться нужно разослать соответствующий атрибут, полученный от Rd.



    Аутентичность и целостность сообщений LDP

    В этом разделе специфицируется механизм защиты от введения фальсифицированных TCP-сегментов в потоки соединений LDP-сессии. Использование этого механизма должно поддерживаться как конфигурируемая опция.
    Механизм базируется на применении опции подписи TCP MD5, описанной в [RFC2385] для BGP. Смотри описание хэш-функций MD5 в [RFC1321].



    B.Сценарий отсутствие резервирования полосы пропускания

    Рассмотрим случай, когда сетевой администратор решил:

  • иметь Diff-Serv ресурсы, полностью обеспечиваемые в режиме off-line (например, через интерфейс командной строки, посредством SNMP, COPS,...)

  • иметь маршрутизацию Shortest Path, используемую для всех видов трафика Diff-Serv.
    Это наиболее приемлемая модель обеспечения Diff-Serv через сеть без поддержки MPLS IP. В этом случае, E-LSP и/или L-LSP будут устанавливаться без согласованной полосы пропускания.



    B.Сценарий Резервирование полосы пропускания для управления доступом для каждого PSC

    Рассмотрим случай, когда сетевой администратор решил:

  • иметь ресурсы Diff-Serv, полностью обеспечиваемые в режиме off-line (например, через интерфейс командной строки, посредством SNMP, COPS, и пр.);

  • использовать L-LSP;

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



    B.Сценарий Резервирование полосы

    Рассмотрим случай, когда сетевой администратор решил:
  • использовать L-LSP;
  • иметь маршрутизацию, базирующуюся на ограничениях (Constraint Based Routing), реализуемую для каждого PSC отдельно, где одним из ограничения является доступность полосы из ресурса, выделенного соответствующему PSC.
  • иметь динамически адаптируемые ресурсы Diff-Serv.

    • В этом случае L-LSP будут формироваться с согласованной полосой пропускания. Полоса пропускания, согласованная при формировании L-LSP, будет использоваться LSR при настройке ресурсов для соответствующих PSC (например, веса трафика) и далее для управления, чтобы гарантировать обеспечения ограничений на полосу пропускания для PSC.
    Ссылки
    [ANSI/IEEE] ANSI/IEEE Std 802.1D, 1993 Edition, incorporating IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998 и P802.12e)
    [ATMF_TM] ATM Forum, "Traffic Management Specification Version 4.1", March 1999.
    [CR-LDP_MPLS_TE]Jamoussi, B., Editor, Andersson, L., Callon, R. и R. Dantu, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
    [DCLASS]Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
    [DIFF_AF]Heinanen, J., Baker, F., Weiss, W. и J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
    [DIFF_ARCH]Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. и W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
    [DIFF_EF] Davie, B., Charny, A., Baker, F., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. и D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
    [DIFF_HEADER]Nichols, K., Blake, S., Baker, F. и D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 и IPv6 Headers", RFC 2474, December 1998.
    [DIFF_NEW]Grossman, D., "New Terminology и Clarifications for Diffserv", RFC 3260, April 2002.
    [DIFF_TUNNEL]Black, D., "Differentiated Services и Tunnels", RFC 2983, October 2000.
    [ECN]Ramakrishnan, K., Floyd, S. и D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
    [IANA]Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
    [IEEE_802.1]ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision и redesignation of ISO/IEC 10038:98.
    [LDP]Andersson, L., Doolan, D., Feldman, N., Fredette, A. и B. Thomas, "LDP Specification", RFC 3036, January 2001.
    [MPLS_ARCH] Rosen, E., Viswanathan, A. и R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
    [MPLS_ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y. и P. Doolan, "MPLS using LDP и ATM VC Switching", RFC 3035, January 2001.
    [MPLS_ENCAPS]Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. и A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
    [MPLS_FR]Conta, A., Doolan, P. и A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
    [MPLS_VPN]Rosen, E., "BGP/MPLS VPNs", Work in Progress.
    [NULL]Bernet, Y., Smith, A. и B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
    [PHBID]Black, D., Brim, S., Carpenter, B. и F. Le Faucheur, "Per Hop Behavior Identification Codes" RFC 3140, June 2001.
    [RSVP]Braden, R., Zhang, L., Berson, S., Herzog, S. и S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional pecification", RFC 2205, September 1997.
    [RSVP_MPLS_TE]Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. и G. Swallow, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.




    Базовая модель

    Базовая модель

    Рис. .1. Схема взаимодействия различных частей COPS.
    На рисунке .1 показано взаимодействие различных компонентов политики (взято из [WRK]). Здесь, COPS используется для обмена описаниями политики между узлами реализации политики PEP (Policy Enforcement Point) и удаленными пунктами принятия политических решений PDP (Policy Decision Point) в пределах контекста конкретного типа клиента. Может использоваться опционный пункт принятия локального политического решения LPDP (Local Policy Decision Point) в отсутствии PDP.
    Предполагается, что каждый конкретный клиент политики функционально совместим с PEP [WRK]. PEP может обмениваться информацией с сервером политики.
    PEP ответственен за инициализацию постоянного TCP-соединения с PDP. Узел PEP использует это соединение для посылки запросов и получения откликов-решений от удаленного PDP. Коммуникация между PEP и удаленным PDP происходит в основном в форме обменов запрос-решение, хотя удаленный PDP может по своей инициативе послать PEP и не запрошенное решение, чтобы вызвать изменение одобренных ранее состояний запросов. PEP имеет также возможность сообщать удаленному >PDP, что решение PDP успешно исполнено локально. Узел PEP ответственен за уведомление PDP об изменении состояния запроса в PEP. Наконец, в функции PEP входит аннулирование любого состояния, которое не может быть использовано из-за событий, имевших место у клиента, или в силу решений, принятых сервером.
    После этого PEP посылает конфигурационный запрос, и ожидает присылки от PDP именованных блоков конфигурационных данных (в виде сообщений-решений). Когда именованные конфигурационные данные успешно доставлены PEP, он должен послать PDP сообщение-отчет, подтверждающее получение конфигурационных данных. Сервер с помощью сообщения-решения может после этого обновить или удалить конфигурационную информацию. Когда PDP посылает решение об удалении именованной конфигурационной информации на PEP, PEP стирает специфицированные данные и посылает PDP в качестве подтверждения сообщение-отчет.
    Протокол политики предполагает коммуникацию с само идентифицируемыми объектами, которые содержат данные, необходимые для идентификации состояний запроса, устанавливающие контекст запроса, его тип, содержащие ссылки на поступившие ранее запросы, принятые политические решения, поступившие сообщения об ошибках и прочие данные специфичные для клиента.
    Чтобы идентифицировать разные виды клиентов, в каждом сообщении приводится тип клиента. Разные типы клиентов могут иметь различные специфические данные и могут требовать различных политических решений. Ожидается, что каждый новый тип клиента имеет соответствующее описание, характеризующее специфику его взаимодействия с данным протоколом описания политики.
    Контекст каждого запроса соответствует типу события, его вызвавшего. Объект контекста COPS идентифицирует тип запроса и сообщения, которые вызвали данное политическое событие, посредством своих полей типа сообщения и запроса. COPS идентифицирует три типа событий: (1) приход сообщения (2) выделение локальных ресурсов, и (3) переадресацию исходящего сообщения. Каждое из этих сообщений может потребовать различных решений. Содержимое сообщений COPS-запросов/решений зависит от контекста. Четвертый тип запроса полезен для типов клиентов, которые хотят получить конфигурационную информацию от PDP. Это позволяет PEP послать конфигурационный запрос специфическому именованному устройству или модулю, который требует инсталляции конфигурационной информации. PEP может также иметь возможность принимать локальные политические решения с помощью LPDP (Local Policy Decision Point) [WRK], однако, PDP всегда остается точкой принятия решений. Это означает, что соответствующая информация о локальных решениях должна передаваться PDP. То есть, PDP должен быть предоставлен доступ к информации, чтобы принять окончательное политическое решение. Чтобы обеспечить такую возможность, PEP должен послать информацию о локальном решении удаленному PDP посредством объекта решения LPDP. PEP должен затем следовать решению PDP, так как оно является окончательным.
    Наконец, допустимость ошибки (fault tolerance) является обязательной особенностью данного протокола, в частности из-за того, что он ассоциируется с управлением услугами и безопасностью в распределенных сетях. Допустимость ошибки может быть достигнута за счет того, что PEP и удаленный PDP постоянно проверяют свое соединение путем посылки тестовых сообщений keep-alive ("еще жив?"). Когда обнаружен отказ, PEP должен попытаться восстановить контакт с удаленным PDP или соединиться с альтернативным (backup) PDP. Пока PEP не имеет связи, он должен ограничиться принятием локальных решений. Как только соединение восстановлено, PEP должен уведомить PDP о любом ликвидированном состоянии или о событиях, которые произошли с момента потери соединения. Кроме того, удаленный PDP может потребовать, чтобы все внутренние состояния PEP были заново синхронизованы (все ранее поступившие запросы должны быть продублированы). После отказа и до того как новое соединение будет восстановлено в полном объеме, ущерб в обслуживании может быть минимизирован, если PEP кэширует переданные ранее решения и продолжает их использовать в течение некоторого ограниченного времени. В разделах 2.3 и 2.5 детально рассмотрены механизмы COPS для обеспечения надежности.



    Базовые моменты при посылке почтовых сообщений

    Почта в Интернет не совершенная однородная система. Почта может оказаться поврежденной на нескольких этапах ее транспортировки к месту назначения. Почтовое сообщение может проходить через участки среды, использующие различные сетевые технологии. Многие сетевые и почтовые технологии не поддерживают полную функциональность, возможную в рамках протокола SMTP. Почтовое сообщение, проходя через эти среды, может быть модифицировано, для того чтобы решить проблему его передачи адресату.
    В сети Интернет имеется большое число почтовых агентов, которые в процессе реализации протокола SMTP, модифицируют сообщения на пролете. Следующие соображения могут оказаться полезными любому, кто разрабатывает формат данных (тип среды), который бы сохранялся неповрежденным в любых сетевых средах и для любых почтовых агентов. Заметим, что данные, закодированные в base64, удовлетворяют этим требованиям, а некоторые хорошо известные механизмы, в частности утилита UNIX uuencode, не удовлетворяет. Заметим также, что данные, закодированные с использованием закавыченных последовательностей печатных символов, успешно преодолевают большинство почтовых шлюзов, но могут быть повреждены в системах, которые используют символьный набор EBCDIC.
    1)

    При некоторых обстоятельствах кодирование, использованное для данных, может изменить работу почтового шлюза или агента пользователя. В частности, может потребоваться преобразование из base64 в закавыченную печатную форму и обратно. Это может вызвать искажения для последовательностей CRLF, определяющих границы строк в тексте.2)Многие системы могут выбрать для хранения и представления текста другое локальное соглашение для обозначения начала новой строки. Это локальное соглашение может не согласовываться с RFC-822, где для этого используется CRLF. Известны системы, где для этой цели применяют один символ CR, один LF, CRLF, или нечто совсем другое. В результате получается, что изолированные CR и LF символы не вполне надежны; они могут быть потеряны или преобразованы некоторыми системами в другие разделители, следовательно, на них нельзя положиться.3)Передача нулей (US-ASCII значение 0) проблематична в Интернет-почте. Это по большей части результат введения нулей, используемых в качестве завершающего символа во многих стандартных программных библиотеках реального времени в языке Си. Практика использования нулей в качестве завершающего символа настолько распространена, что нельзя рассчитывать на то, что эти нули будут сохранены в сообщении.4)TAB (HT) символы могут быть неверно интерпретированы или автоматически преобразованы в переменное число пробелов. Это неизбежно в некоторых условиях, в особенности тех, которые базируются на символьном наборе US-ASCII. Такое преобразование не рекомендуется, но может случиться и форматы почты не должны полагаться на сохранение символов TAB (HT).5)Строки длиннее 76 символов могут быть разорваны или укорочены некоторыми почтовыми агентами. Разрыв строк или укорочение при транспортировке почты не рекомендуется, но избежать этого иногда невозможно. Приложения, которые требуют длинных строк, должны каким то образом делать различие между "мягким" и "жестким" разрывом строки. Простым способом решить эту проблему является применение кодирования с помощью закавыченных строк печатных символов. 6)Завершающие символы строки (SP и HT) могут быть отброшены некоторыми транспортными агентами, в то время как другие могут дополнить строки этими символами так, что все строки почтового файла обретают равную длину. На присутствие завершающих символов SP или HT рассчитывать не приходится.7)Многие почтовые домены используют вариации символьного набора US-ASCII, или работают с символьными наборами типа EBCDIC, который содержит большинство но не все символы из US-ASCII. Корректная трансляция символов в не инвариантный набор не может быть зависимой от конвертирующих шлюзов по дороге. Например, возникает проблема при пересылке информации, обработанной программой uuencodE, через сеть BITNET. Аналогичные проблемы могут возникнуть без прохода через шлюз, так как многие ЭВМ в Интернет используют символьный набор отличный от US-ASCII. Определение печатной строки в X.400 добавляет новые ограничения в некоторых специфических случаях. В частности, символами, которые могут быть пропущены через любые шлюзы, считаются 73 символа. В их число входят прописные и строчные буквы A-Z и a-z, 10 цифр - 0-9 и следующие одиннадцать специальных символов.

    "'" (US-ASCII десятичное значение 39)
    "(" (US-ASCII десятичное значение 40)
    ")" (US-ASCII десятичное значение 41)
    "+" (US-ASCII десятичное значение 43)
    "," (US-ASCII десятичное значение 44)
    "-" (US-ASCII десятичное значение 45)
    "." (US-ASCII десятичное значение 46)
    "/" (US-ASCII десятичное значение 47)
    ":" (US-ASCII десятичное значение 58)
    "=" (US-ASCII десятичное значение 61)
    "?" (US-ASCII десятичное значение 63)

    Максимально переносимое почтовое сообщение имеет короткие строки, содержащие только эти 73 с имвола. Кодирование base64 отвечает этому правилу. (8)Некоторые почтовые транспортные агенты искажают данные, которые содержат определенные символьные строки. В частности, одиночный символ точка (".") на строке может быть поврежден в некоторых SMTP реализациях, а строки, которые начинаются с пяти символов "From " (пятым символом является пробел), также могут быть повреждены. Хорошие агенты-отправители могут предотвратить эти искажения путем кодирования данных (например, в закавыченных строках печатных символов в начале строки вместо "From " используется "=46rom " и "=2E" вместо одиночной ".").
    Заметим, что приведенный выше список не является рекомендацией для почтовых транспортных агентов. В документе RFC-821 не запрещается заменять символы или разрывать длинные строки. Более того, данный список отражает негативную практику для существующих сетей и программные реализации должны быть устойчивы против таких эффектов, с которыми им придется столкнуться.



    Базовый механизма выявления

    Чтобы запустить базовый механизм выявления в LDP для заданного интерфейса LSR периодически посылает в канал LDP сообщения. Канальные сообщения Hello посылаются в виде UDP-пакетов, адресованных в стандартный порт выявления партнеров LDP, "всем маршрутизаторам субсети" методом мультикастинг-адресации.
    Канальное сообщение LDP Hello, посланное LSR, содержит в себе идентификатор LDP для пространства меток, которое LSR намерен использовать для интерфейса, а также дополнительную информацию.
    Отклик на канальное сообщение LDP Hello идентифицирует сопредельность (adjacency) с потенциальным LDP партнером, достижимым на канальном уровне интерфейса, а также пространство меток, которое партнер намерен использовать для данного интерфейса.



     BGP и LDP

    Во многих сценариях, желательно установить связь между метками и FEC, который может быть сопряжен с маршрутами и адресными префиксами (смотри раздел 3.1).
    Протокол BGP рассылает маршруты, и, если BGP-отправителю нужно разослать метки своим BGP-партнерам, использование BGP для целей распределения меток (смотри [MPLS-BGP]) имеет ряд преимуществ. В частности, это позволяет BGP рефлекторам маршрутов рассылать метки, таким образом обеспечивая существенную масштабируемость по сравнению с использованием LDP для пересылки меток между BGP партнерами.



    Цели

    Ниже предлагается список основных задач DHCP.
    oDHCP представляет собой механизм, а не политику. DHCP должен управляться местными системными администраторами, путем задания желательных конфигурационных параметров.
    oКлиенты не должны требовать ручной конфигурации. Каждый клиент должен быть способен прочесть локальные конфигурационные параметры.
    oСети не должны требовать ручной конфигурации для отдельных клиентов. В нормальных условиях, сетевой администратор не должен вводить какие-либо индивидуальные конфигурационные параметры клиента.
    oDHCP не требует отдельного сервера для каждой субсети.
    oКлиент DHCP должен быть готов получить несколько откликов на запрос конфигурационных параметров. Для повышения надежности и быстродействия можно использовать несколько DHCP-серверов, обслуживающих перекрывающиеся области сети.
    oDHCP должен сосуществовать с ЭВМ, которые сконфигурированы вручную.
    oDHCP должен быть совместим с логикой работы BOOTP-агента, описанной в RFC-951 и RFC-1542 [21].
    oDHCP должен обслуживать существующих клиентов BOOTP.

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




    Частные расширения LDP производителя

    Частные сообщения и TLV производителя используются для обмена между LSR частной информацией производителя.



    Частные сообщения LDP производителя

    Код типа в диапазоне 0x3E00 - 0x3EFF зарезервирован для частных сообщений производителя.
    Частные сообщения LDP производителя

    U бит
    Бит неизвестного сообщения. При подтверждении неизвестного сообщения, если U=0, отправителю сообщения возвращается уведомление; если U=1, неизвестное сообщение молча игнорируется.
    Определение того, будет ли воспринято частное сообщение производителя, базируется на типе сообщения и параметре ID производителя.
    Тип сообщения
    Код типа сообщения лежит в диапазоне 0x3E00 - 0x3EFF. Вместе с типом сообщения и ID производителя специфицирует то, как будет интерпретироваться сообщение.
    Длина сообщения
    Специфицирует суммарную длину в октетах полей ID сообщения, ID производителя, остальных обязательных параметров и опционных параметров.
    ID сообщения
    32-битовый код, используемый для идентификации этого сообщения. Используется LSR-отправителем, чтобы упростить идентификацию уведомлений, которые могут относиться к этому сообщению. LSR, посылающий уведомление, в качестве отклика на это сообщение, будет включать этот Id в сообщение уведомления; смотри раздел "Сообщение уведомления".
    ID производителя
    ID производителя 802, как это предписано IEEE.
    Остальные обязательные параметры
    Набор переменной длины остальных обязательных параметров.
    Опционные параметры
    Набор переменной длины опционных параметров сообщения.



    Частные TLV LDP производителя

    Диапазон кодов типа 0x3E00 - 0x3EFF зарезервирован для частных TLV производителя. Формат частных TLV производителя представлен ниже:
    Частные TLV LDP производителя

    U бит
    Бит неизвестного TLV. При получении неизвестного TLV, если U=0, отправителю сообщения должно быть прислано уведомление, а само сообщение проигнорировано; если U=1, неизвестное TLV молча игнорируется, а остальная часть сообщения обрабатывается так, как если бы неизвестного TLV не существовало.
    Определение того, понятно ли частное сообщение производителя, зависит от типа и обязательного поля ID производителя.
    F бит
    Бит переадресации неизвестного TLV. Этот бит используется, только когда U=1, а сообщение LDP, содержащее неизвестное TLV, должно быть переадресовано. Если F=0, неизвестное TLV не переадресуется вместе с содержащим его сообщением; если F=1, неизвестное TLV переадресуется вместе с содержащим его сообщением.
    Тип
    Значение тип лежит в диапазоне 0x3E00 - 0x3EFF. Вместе с типом и Id производителя поле специфицирует, как следует интерпретировать поле данных.
    Длина
    Специфицирует суммарную длину в октетах идентификатора производителя и поля данных.
    Id производителя
    ID производителя 802, как это предписано IEEE.
    Данные
    Остальные октеты после ID производителя в поле значение являются опционными данными, зависящими от производителя.



    Client-Accept (CAT) PDP -> PEP

    Сообщение Client-Accept используется для позитивного отклика на сообщение Client-Open. Это сообщение пришлет PEP объект таймера, заключающий в себе максимальный временной интервал между сообщениями keep-alive. Опционно, если нужно, может быть добавлен таймер, специфицирующий минимально допустимый интервал между аккоунтинг-сообщениями-отчетами.
    ::=

    []
    []
    Если PDP отказывает клиенту, он пошлет сообщение Client-Close.
    Таймер KA соответствует максимальному приемлемому времени между сообщениями, посылаемыми от PDP к PEP. Время выдержки таймера определяется PDP и измеряется в секундах. Значение времени выдержки 0 означает, что не требуется верификации вторичного соединения.
    Опционный таймер ACCT позволяет PDP проинформировать PEP о том, что периодические аккоунтинг-отчеты не должны превышать специфицированный временной интервал для каждого дескриптора клиента. Это позволяет PDP контролировать частоту, с которой PEP посылает аккоунтинг-отчеты. Вообще, сообщения Report типа аккоунтинг посылаются PDP, когда определен соответствующий PEP. Аккоунтинг-таймер по большей части используется PDP, чтобы поддерживать частоту актуализаций на приемлемом уровне (т.e. предотвращать перегрузку PEP под действием аккоунтинг-отчетов от PDP). Не включение этого объекта в сообщение означает, что не существует для PDP каких-либо ограничений на частоту аккоунтинг-актуализации.
    Если PEP получает сообщение Client-Accept с неверным форматом, он должен сгенерировать сообщение Client-Close, где специфицирован соответствующий код ошибки.



    Client-Close (CC) PEP -> PDP, PDP -> PEP

    Сообщение Client-Close может быть послано как PDP, так и PEP с тем, чтобы обратить внимание противоположной стороны на то, что указанный тип клиента более не поддерживается.
    ::=

    []
    []
    Объект Error включен, чтобы описать причину закрытия (например, запрошенный тип клиента не поддерживается удаленным PDP или отказ в работе клиента).
    PDP может опционно включать PDP-объект адреса перенаправления, для того чтобы проинформировать PEP об альтернативном PDP, который он должен использовать для типа клиента, специфицированного в общем заголовке.



    Client-Open (OPN) PEP -> PDP

    Сообщение Client-Open может использоваться PEP, для того чтобы специфицировать PDP типы клиента, которые PEP может поддерживать, и последний PDP, с которым PEP устанавливал соединение при данном типе клиента. Сообщение Client-Open может быть послано PDP в любое время, допускаются множественные сообщения Client-Open для одного и того же типа клиента (в случае общих изменений состояния).
    ::=

    []
    []
    []
    PEPID является символическим именем с переменной длиной, которое однозначно идентифицирует клиента для PDP (смотри раздел 2.2.11).
    Именованный объект ClientSI может быть включен для передачи дополнительной глобальной информации о PEP к PDP, когда необходимо (как это специфицировано в соответствующем расширении документа для заданного типа клиента).
    PEP может также предоставить объект Last PDP Address в его сообщении Client-Open, специфицирующий последний PDP (для заданного типа клиента), для которого он кэширует решения с момента последней перезагрузки (reboot). PDP может использовать эту информацию, чтобы определить подходящий режим синхронизации (смотри раздел 2.5).
    Если PDP получает сообщение Client-Open с неверным форматом, он должен сформировать сообщение Client-Close, специфицирующее соответствующий код ошибки.



     Деревья LSP как объекты мультиточка-точка

    Рассмотрим случай, когда пакеты P1 и P2 имеют адреса места назначения в префиксе Х. Предположим, что маршрут шаг-за-шагом для P1 представляет собой , а путем шаг-за-шагом для P2 является . Давайте предположим, что R3 связывает метку L3 с X, и отсылает эту ассоциацию R2. R2 связывает метку L2 с X, и посылает эту ассоциацию в R1 и R4. Когда R2 получает пакет P1, его входная метка будет также L2. R2 заменит L2 на L3, и пошлет P1 в R3. Когда R2 получает пакет P2, его входная метка будет также L2. R2 снова заменит L2 на L3, и пошлет P2 в R3.
    Заметим далее, что когда P1 и P2 двигаются от R2 к R3, они несут одну и ту же метку, и с точки зрения MPLS, они не различимы. Таким образом, вместо того чтобы говорить о двух разных LSP, и , мы можем говорить об одном дереве LSP мультиточка-точка (Multipoint-to-Point LSP Tree), которое мы можем обозначить как <{ R1, R4}, R2, R3>.
    Это создает трудности, когда мы пытаемся использовать обычные ATM-коммутаторы в качестве LSR. Так как обычные ATM-коммутаторы не поддерживают соединения мультиточка-точка, должны существовать процедуры, гарантирующие, чтобы каждый LSP реализовал VC по схеме точка-точка. Однако если используются ATM-коммутаторы, которые поддерживают VC мультиточка-точка, тогда LSP может быть реализован эффективно по такой схеме. Альтернативой может служить ситуация, когда можно использовать многоточечное представление SVP (раздел 2.25.2), LSP может быть реализован как SVP мультиточка-точка.



    Деревья с общим отправителем

    Мультикастные IP протоколы маршрутизации формируют либо деревья отправителя (S,G), т.е. по дереву для каждого отправителя (S) и для группы (G), или деревья с совмещением (*, G), т.е. одно дерево для каждой мультикаст-группы (Рис. 1).
    Деревья с общим отправителем

    Рис. 1. Дерево с совмещением и деревья отправителя
    Преимуществом использования деревьев с совмещением, в случае применения переключения по меткам, является то, что деревья с совмещением требуют меньше меток, чем деревья отправителя (1 метка на группу против одной метки на отправителя и на группу). Однако проецирование деревьев с совмещением на уровень L2 подразумевает формирование LSP мультиточка-мультиточка (mp2mp).
    Заметим, что на практике деревья с совмещением часто используются только для выявления новых отправителей групп, а переключение на дерево отправителя производится при низких потоках данных.



    Детектирование петель

    Детектирование петель является конфигурируемой опцией, которая предоставляет механизм нахождения циклических сегментов LSP и для предотвращения зацикливания сообщений запроса метки.
    Механизм использует TLV вектора пути и числа шагов, содержащиеся в сообщениях запроса и присвоения метки. Он строится на следующих базовых свойствах этих TLV:
  • TLV вектора пути содержит список LSR, через которые проходит сообщение, его содержащее. LSR идентифицируется в списке вектора с помощью уникальных Id LSR, которые являются первыми четырьмя октетами идентификатора его LDP. Когда LSR передает сообщение, содержащее TLV вектора пути, он добавляет в список вектора пути свой идентификатор (Id LSR). LSR, который получает сообщение с вектором пути, содержащим его Id, регистрирует, что сообщение прошло по замкнутому пути (по петле). LDP поддерживает понятие максимально допустимой длины вектора пути. LSR, который детектирует, что вектор пути достиг максимальной длины, поступает также как в случае регистрации петлевого маршрута.

  • TLV числа шагов содержит число LSR, которые сообщение, содержащее его, прошло. Когда LSR пересылает сообщение, содержащее TLV числа шагов, он увеличивает это число на 1. LSR, который регистрирует, что число шагов достигло заданного при конфигурации максимума, ведет себя так, как если бы была зарегистрирована петля. Согласно договоренности число 0 интерпретируется, как неизвестное число шагов. Инкрементирование такого значения сохраняет его величину (unknown =0).

    • Заметим, что TLV числа шагов и его процедуры используются без TLV вектора пути в ситуации, когда детектирование петель не предусмотрено на уровне конфигурации (смотри [RFC3035] и [RFC3034]).



    Diff-Serv TLV

    Diff-Serv TLV имеет следующие форматы:
    Diff-Serv TLV для E-LSP:
    Diff-Serv TLV

    Рис. 11.
    T :1 бит
    Тип LSP. Устанавливается равным 0 для E-LSP
    Зарезервировано: 27 бит
    Это поле зарезервировано на будущее. Оно должно быть установлено равным нулю при передаче, и должно игнорироваться при приеме.
    MAPnb: 4 бита
    Индицирует число записей MAP, включенных в объект DIFFSERV. Оно может быть установлено равным любому числу от 1 до 8.
    MAP: 32 бита
    Каждая запись MAP определяет соответствие между одним значением поля EXP и одним PHB. Запись MAP имеет формат, показанный на рис. 9.
    Diff-Serv TLV для L-LSP:
    Diff-Serv TLV

    Рис. 12.
    T :1 бит
    Тип LSP. Устанавливается равным 1 для L-LSP
    Зарезервировано: 15 бит
    Это поле зарезервировано на будущее. Оно должно быть установлено равным нулю при передаче, и должно игнорироваться при приеме.
    PSC: 16 бит
    PSC индицирует класс обслуживания PHB, который должен быть поддержан LSP. PSC кодируется так, как специфицировано в [PHBID].



    Дискретные значения типа среды

    Пять из семи базовых значений типа среды относятся к дискретным телам. Содержимое этих типов должно обрабатываться с использование механизмов за пределами MIME, они непрозрачны для MIME-процессоров.
    4.1. Тип среды Text
    Тип среды "text" предназначен для посылки материала, который имеет принципиально текстуальную форму. Параметр "charset" можно использовать для указания символьного набора тела субтипов "text", включая субтип "text/plain", который является общим субтипом для чистого текста. Чистый текст не содержит форматирующих команд, спецификаций атрибутов шрифтов, инструкций обработки, директив интерпретации или разметки. Чистый текст представляет собой последовательность символов, которая может содержать разрывы строк или страниц.
    Помимо чистого текста существует много форматов, называемых "богатый" текст ("rich text"). Интересной характеристикой многих таких представлений является то, что они читабельны даже без программы, которая его интерпретирует. Полезно затем отличать их на верхнем уровне от таких нечитабельных данных как изображения, звук или текст, представленный в нечитаемом виде. В отсутствии подходящей интерпретирующей программы разумно показать субтипы "text" пользователю, в то время как это неразумно для большей части нетекстовых данных. Такие форматированные текстовые данные должны представляться с помощью субтипов "text".
    4.1.1. Представление разрывов строк
    Каноническая форма любого субтипа MIME "text" должна всегда оформлять разрыв строки с помощью последовательности CRLF. Аналогично, любое появление CRLF в тексте MIME должно означать разрыв строки. Использование CR и LF по отдельности вне обозначения разрыва строки запрещено. Это правило работает вне зависимости от используемого символьного набора.
    Правильная интерпретация разрывов строк при отображении текста зависит от типа среды. Следует учитывать, что одно и то же оформление разрывов строк при отображении "text/plain" может восприниматься корректно, в то время как для других субтипов "text", например, "text/enriched" [RFC-1896] аналогичные разрывы строк будут восприниматься как неверные. Нет необходимости в добавлении каких-либо разрывов строк при отображении "text/plain", в то время как отображение "text/enriched" требует введения соответствующего оформления разрывов строк.
    Некоторые протоколы определяют максимальную длину строки. Например, SMTP [RFC-821] допускает максимум 998 октетов перед последовательностью CRLF. Для того чтобы реализовать транспортировку посредством такого протокола, данные, содержащие слишком длинные сегменты без CRLF, должны быть закодированы с применением соответствующего content-transfer-encoding.
    4.1.2. Параметр Charset

    Критическим параметром, который может быть специфицирован в поле Content-Type для данных "text/plain", является символьный набор. Он специфицируется параметром "charset", например, как:

    Content-type: text/plain; charset=iso-8859-1

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

    Для других субтипов "text", семантика параметра "charset" должна быть определена аналогично параметрам, заданным для "text/plain", т.e., тело состоит полностью из символов данного набора. В частности, авторы будущих определений субтипов "text" должны обратить особое внимание мультиоктетным символьным наборам. Параметр charset для субтипов "text" дает имя символьному набору, как это определено в RFC 2045.

    Заметим, что специфицированный символьный набор включает в себя 8-битовые коды и эти символы используются в теле, поле заголовка Content-Transfer-Encoding и для передачи данных с помощью транспортных протоколов (например, SMTP) необходима соответствующая кодировка, такая как [RFC-821].

    Значение символьного набора по умолчанию, равное US-ASCII, являлось причиной многих неурядиц в прошлом. Для того чтобы исключить какие-либо неопределенности в будущем, настоятельно рекомендуется новым агентам пользователя задавать символьный набор в явном виде в качестве параметра типа среды в поле заголовка Content-Type. "US-ASCII" не указывает на произвольный 7-битовый символьный набор, а говорит о том, что все октеты в теле должны интерпретироваться как символы US-ASCII. Национальные и ориентированные на приложения версии ISO 646 [ISO-646] обычно не идентичны US-ASCII, и их непосредственное применение в электронной почте может вызвать проблемы. Имя символьного набора "US-ASCII" относится к кодам, заданным в документе ANSI X3.4-1986 [US- ASCII].

    Полный набор символов US-ASCII представлен в ANSI X3.4-1986. Заметим, что управляющие символы, включая DEL (0-31, 127) не имеют определенного значения, исключение составляет комбинация CRLF (US-ASCII значения 13 и 10) обозначающая разрыв строки. Два символа имеют широко используемые функции, это: FF (12) - продолжить последующий текст с начала новой страницы, и TAB или HT (9) часто (хотя и не всегда) означает "переместить курсор в следующую колонку. Колонки нумеруются, начиная с нуля и их позиции кратны 8. Помимо этих случаев любые управляющие символы или DEL в теле объекта могут появиться при следующих условиях.

    (1)
    по причине того, что субтип текста, отличающийся от "plain", приписывает им некоторые дополнительные значения, или (2) в рамках контекста частного соглашения между отправителем и получателем.
    Определены следующие значения charset:

    (1) US-ASCII - как это определено в ANSI X3.4-1986 [US-ASCII].
    (2)
    ISO-8859-X -- где "X" следует замещать как это требуется для частей ISO-8859 [ISO-8859]. Допустимыми подменами "X" являются цифры от 1 до 10.

    Символы с кодами в диапазоне 128-159 не имеют стандартизованных значений в рамках ISO-8859-X. Символы с кодами меньше 128 в ISO-8859-X имеют те же значения, что и в US-ASCII.

    Значения символьных наборов "ISO-8859-6" и "ISO-8859-8" специфицируют применение визуального метода [RFC-1556].

    Все эти символьные наборы используются как чисто 7-битовые или 8-битовые без модификаций связанных или .

    Никакие символьные наборы, отличные от определенных выше, не могут использоваться в электронной почте без публикации и формальной регистрации в IANA. Допустимы частные соглашения, в этом случае имя символьного набора должно начинаться с "X-".

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

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

    4.1.3. Субтип Subtype

    Простейшим и наиболее важным субтипом "text" является "plain". Он указывает, что текст не содержит форматирующих команд или директив. Чистый текст может отображаться непосредственно без какой-либо обработки. По умолчанию для электронной почты предполагается тип среды "text/plain; charset=us-ascii".

    4.1.4. Не распознанные субтипы

    Не распознанные субтипы "text" должны обрабатываться как чистый текст ("plain"), поскольку реализация MIME знает, как работать с данным символьным набором. Не распознанные субтипы, которые также специфицируют нераспознаваемый символьный набор, должны обрабатываться как "application/octet- stream".

    4.2. Тип среды Image


    Тип среды "image" указывает, что тело содержит изображение. Субтип называет имя специфического формата изображения. Эти имена не чувствительны к регистру. Исходным субтипом является "jpeg", который использует кодировку JFIF для формата JPEG [JPEG]. Не распознанные субтипы "image" должны обрабатываться как "application/octet-stream".

    4.3. Тип среды Audio

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

    Содержимое субтипа "audio/basic" представляет собой моноканальное звуковое кодирование, использующее 8-битоый ISDN-стандарт с m-функцией преобразования [PCM] с частотой стробирования 8000 Hz. Не распознанные субтипы "audio" должны обрабатываться как "application/octet-stream".

    4.4. Тип среды Type

    Тип среды "video" указывает, что тело содержит движущееся изображение, возможно цветное и в сопровождении звука. Термин 'video' используется в самом общем значении, и не подразумевает какого-то конкретного формата. Субтип "mpeg" относится к видео закодированного согласно стандарту MPEG [MPEG]. Не распознанные субтипы "video" должны обрабатываться как "application/octet-stream".

    4.5. Тип среды Application

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

    Такие приложения могут быть определены как субтипы типа среды "application". В данном документе определены два субтипа:

    octet-stream и PostScript.

    4.5.1. Субтип Octet-Stream (поток октетов)


    Субтип "octet-stream" используется для индикации того, что тело содержит произвольные двоичные данные. В настоящее время определены следующие параметры:
    (1) TYPE - общий тип или категория двоичных данных. Это параметр предназначен для оператора-получателя, а не для программы обработки.
    (2) PADDING - число бит заполнителя, добавленного к потоку бит, представляющему действительное содержимое, для того чтобы получить байт-ориентированный поток. Используется, когда число бит в теле не кратно 8
    Оба эти параметра являются опционными.

    4.5.2. Субтип PostScript

    Тип среды "application/postscript" указывает на программу PostScript. В настоящее время допускается два варианта языка PostScript. Исходный вариант уровня 1 описан в [POSTSCRIPT], а более новый вариант уровня 2 рассмотрен в [POSTSCRIPT2].

    Описания языка PostScript предоставляет возможности внутренней пометки специфических возможностей данного приложения. Эта пометка, называемая DSC (document structuring conventions) PostScript, предоставляет существенно больше информации, чем уровень языка. Использование DSC рекомендуется даже тогда, когда это непосредственно не требуется, так как обеспечивает более широкую совместимость. Документы, которые недостаточно структурированы, не могут быть проверены с целью выяснения того, могут ли они работать в данной среде.

    Работа универсальных интерпретаторов PostScript представляет серьезную угрозу безопасности, разработчикам не рекомендуется просто посылать тела PostScript имеющимся ("off-the-shelf") интерпретаторам. В то время как посылка PostScript-файла на принтер обычно безопасна, программисты должны рассмотреть все возможные последствия, прежде чем ввести интерактивное отображение тел типа PostScript на их читающих средствах MIME.

    Ниже перечислены возможные проблемы, связанные с транспортировкой объектов PostScript.

    (1)
    В список опасных операций языка PostScript входят "deletefile", "renamefile", "filenameforall" и "file". "File" является единственной опасной процедурой, которая применяется для входных/выходных потоков не стандартных данных. Конкретные реализации могут определить не стандартные файловые операторы, которые могут также представлять угрозу безопасности. "Filenameforall", - оператор поиска файлов, может показаться на первый взгляд безобидным.
    Заметим, что этот оператор может раскрыть информацию о том, к каким файлам имеет доступ пользователь, а эти данные могут облегчить задачу хакеру. Отправители сообщений должны избегать использования потенциально опасных файловых операторов, так как такие операторы, скорее всего, недоступны в PostScript приложениях, где приняты меры по обеспечению безопасности. Программное обеспечение, которое используется для приема и отображения, должно блокировать потенциально опасные файловые операторы или принять меры по ограничению их возможностей. (2) Язык PostScript предоставляет возможность для выхода из цикла интерпретатора или сервера. Операторы, сопряженные с выходом интерпретатора из цикла могут интерферировать с процедурами последующей обработки документов. Операторы PostScript, которые выводят интерпретатор из цикла, включают в себя серверы выхода и начала задания. Программе отправки сообщения не следует генерировать PostScript, который зависит от функционирования выхода интерпретатора из цикла, так как такая процедура может отсутствовать в реализациях с повышенной безопасностью. Программа приема сообщений должна полностью блокировать работу операторов "startjob" и "exitserver", также какие-либо изменения в среде PostScript на постоянной основе. Если эти операции не могут быть полностью исключены, для их выполнения должен быть организован контролируемый доступ с необходимостью ввода пароля. (3)PostScript предоставляет операторы для установки системных параметров и специфических параметров внешних устройств. Эти установки параметров могут влиять неблагоприятным образом на работу интерпретатора. Процедуры PostScript, которые устанавливают системные параметры, могут включать в себя операторы "setsystemparams" и "setdevparams". Программа отправки не должна генерировать PostScript-сообщений, которые зависят от установки системных параметров. Программа приема и отображения сообщений должна блокировать изменение системных параметров. Если блокировка по каким-либо причинам невозможна, процедура установки параметров должна требовать специфического пароля. (4) Некоторые реализации PostScript предоставляют нестандартные возможности для прямой загрузки и исполнения машинных кодов. Такие возможности чреваты злоупотреблениями. Программа отправки сообщений не должна использовать такие возможности. Программа приема и отображения сообщений не должна позволять применение таких операторов, если они имеются. (5)PostScript является расширяемым языком, и многое, если не большинство, его реализаций предоставляют большое число расширений. Программа отправки сообщений не должна использовать нестандартные расширения. Программа приема и отображения сообщений должна быть уверена, что эти нестандартные расширения не представляют угрозы. (6) Имеется возможность написания такой PostScript-программы, которая потребует огромных системных ресурсов. Можно также написать PostScript-фрагмент, который реализует бесконечный цикл. Оба варианта представляют угрозу для ничего не подозревающего получателя. Программа отправки сообщений должна избегать создания и распространения таких кодов. Программа приема и отображения сообщений должна предоставлять подходящий механизм для блокировки исполнения и удаления таких программ по истечении некоторого заданного времени. (7) Существует возможность включения двоичной информации в PostScript-текст. Это не рекомендуется в электронной почте, так как это не поддерживается всеми PostScript-интерпретаторами, потому что сильно усложняет использование транспортного кодирования MIME. (8) Наконец, в некоторых интерпретаторах PostScript вполне возможны ошибки, которые могут использоваться для получения не авторизованного доступа к системе получателя.4.5.3. Другие субтипы приложений

    Ожидается, что в будущем будут определены многие другие субтипы "application". Реализации MIME должны уметь обрабатывать нераспознанные субтипы как "application/octet-stream".


    Добавление субобъектов в объект Explicit Route

    После выбора следующего шага, узел может изменить явный маршрут следующими способами. Если в процессе реализации алгоритма (см. раздел 4.3.4.1) объект EXPLICIT_ROUTE удален, узел может добавить новый объект EXPLICIT_ROUTE.
    В противном случае, если узел является членом абстрактного узла первого субобъекта, перед первым субобъектом может быть введена последовательность субобъектов или первый субобъект может быть заменен. Каждый субобъект в этой последовательности должен представлять абстрактный узел, который является субнабором текущего абстрактного узла.
    В качестве альтернативы, если первый субобъект является свободным, перед ним может быть введена произвольная последовательность субобъектов.

    4.3.5. Петли
    Так как объект EXPLICIT_ROUTE имеет конечную длину, существование свободных узлов предполагает, что возможно формирование петлевых путей в период переходных процессов, сопряженных с реализацией маршрутных протоколов. Это может быть детектировано исходным узлом явного маршрута путем использования еще одного непрозрачного объекта маршрута, называемого RECORD_ROUTE. Объект RECORD_ROUTE используется для сбора детальной информации о маршруте и является полезным для детектирования петель и для диагностики.

    4.3.6. Прямая совместимость
    Ожидается, что со временем могут быть определены новые субобъекты. Узел, который столкнулся в процессе обработки ERO с нераспознанным субобъектом, посылает отправителю PathErr с кодом ошибки "Routing Error" и значением ошибки "Bad Explicit Route Object". Присутствие нераспознанного субобъекта, который не встретился в ходе обработки ERO, следует игнорировать. Он передается далее вместе с остальной частью стека ERO.

    4.3.7. Отсутствие поддержки объекта Explicit Route
    Маршрутизатор RSVP, который не распознает объект EXPLICIT_ROUTE, посылает отправителю PathErr с кодом ошибки "Unknown object class". Это вызывает отказ формирования пути. Отправитель должен уведомить руководство, что LSP не может быть сформирован и возможно предпримет действия по резервированию без EXPLICIT_ROUTE или с привлечением другого явного маршрута.



    Дополнительные поля заголовка MIME

    Будущие документы могут содержать дополнительные поля заголовков MIME для различных целей. Любое новое поле заголовка, которое описывает содержимое сообщения должно начинаться со строки "Content-", для того чтобы такие поля можно было с гарантией отличить от обычных полей заголовков сообщения, следующих стандарту RFC-822.
    MIME-extension-field := <Любое поле заголовка RFC-822, которое начинается со строки "Content-">
    Используя поля заголовка MIME-Version, Content-Type и Content-Transfer-Encoding, можно подключить стандартным образом произвольные типы данных и добиться совместимости с требованиями документа RFC-822. Никакие ограничения введенные документами RFC-821 или RFC-822 не нарушаются, были приняты меры, чтобы исключить проблемы, связанные с дополнительными ограничениями из-за свойств некоторых механизмов пересылки почты по Интернет (см. RFC-2049).
    Приложение A -- обзор грамматики
    Это приложение содержит грамматические описания всех конструкций, содержащихся в протоколе MIME.
    attribute := token Распознавание атрибутов не зависит от регистра, в котором написаны их имена.
    composite-type:="message" / "multipart" / extension-token 
    Content:="Content-Type" ":" type "/" subtype *(";" parameter) Распознавание типов среды и субтипов не зависит от регистра, в котором написаны их имена.
    description:=  "Content-Description" ":" *text 
    discrete-type:="text" / "image" / "audio" / "video" / "application" / extension-token 
    encoding:="Content-Transfer-Encoding" ":" mechanism 
    entity-headers:=

    [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF )  extension-token:=ietf-token / x-token  hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") Октет должен использоваться для символов > 127, =, пробелов или TAB в конце строк, и рекомендуется для любого символа вне списка "mail-safe" RFC 2049. iana-token := <Общедоступная лексема. Лексемы этого формата должны регистрироваться IANA, как это определено в RFC 2048.>  ietf-token := <Лексема расширения, определенная согласно RFC и зарегистрированная IANA.>  Id := "Content-ID" ":" msg-id  mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token  MIME-extension-field := <Любое поле заголовка RFC 822, которое начинается со строки "Content-">  MIME-message-headers := entity-headers fields version CRLF Порядок полей заголовка, заданный в BNF-определении не играет никакой роли. MIME-part-headers:=Заголовки объекта [поля] Любое поле, начинающееся с "content-", не имеет строго заданного значения и может игнорироваться.parameter:=атрибут "=" значение Ptext:=hex-octet / safe-char  qp-line := *(qp-segment transport-padding CRLF) транспортный заполнитель qp-части  qp-part:=qp-секцияМаксимальная длина 76 символовqp-section:=[*(ptext / SPACE / TAB) ptext] qp-segment:=qp-секция *(SPACE / TAB) "=" Максимальная длина 76 символовQuoted-printable:=qp-line *(CRLF qp-line)  safe-char:=<любой октет с десятичным кодом от 33 до 60, включительно, и с 62 до 126>Символы вне списка "mail-safe" в RFC 2049 не рекомендуются.subtype:=Лексема расширения / лексема iana  Token:=1*<любой US-ASCII-символ за исключением SPACE, CTLs, или tspecials>  transport-padding := *LWSP-charПрограмма-отправитель не должна формировать транспортное заполнение ненулевой длины, но получатели должны быть способны обрабатывать такие транспортные заполнители. tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "="При использовании в значениях параметров они должны иметь формат закавыченных строк. Type := discretetype / compositetype Value := лексема / закавыченная строка version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT x-token := <Два символа "X-" или "x-", за которыми следует без пробела любая лексема>
    II. Типы среды

    1. Введение

    Поле Content- Type используется для спецификации природы информации в теле MIME-объекта путем присвоения идентификаторов типа и субтипа среды и предоставления дополнительной информации, которая может быть необходима для данной разновидности среды. За именами типа и субтипа среды в поле следует набор параметров, заданных в нотации атрибут/значение. Порядок следования параметров не существенен.

    Тип среды верхнего уровня используется для декларации общего типа данных, в то время как субтип определяет специфический формат данного типа информации. Таким образом, тип среды "image/xyz" говорит агенту пользователя, что данные характеризуют изображение и имеют формат "xyz". Такая информация может использоваться, для того чтобы решить, отображать ли пользователю исходные данные нераспознанного субтипа. Такие действия могут быть разумными для нераспознанного фрагмента субтипа "text", но не для субтипов "image" или "audio". По этой причине, зарегистрированные субтипы "text", "image", "audio" и "video" не должны содержать встроенных фрагментов другого типа. Такие составные форматы должны использовать типы "multipart" или "application".

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

    Поле заголовка Content-Type и механизм типа среды спроектированы так, чтобы сохранить масштабируемость, обеспечивая постепенный рост со временем числа пар тип/субтип и сопряженных с ними параметров. Транспортное кодирование MIME, а также типы доступа "message/external-body" со временем могут обрести новые значения. Для того чтобы гарантировать то, что такие значения разработаны и специфицированы корректно, в MIME предусмотрен процесс регистрации, который использует IANA (Internet Assigned Numbers Authority) в качестве главного органа контролирующего данный процесс (см. RFC 2048). В данном разделе описаны семь стандартизованных типов среды верхнего уровня.


    Дополнительные выводы 10. Поле TTL

    Поле TTL в IP-заголовке обычно используется для детектирования петель. В IP мультикастинге оно также используется для ограничения области распространения пакетов. Таким образом, в LSR, которые не поддерживают функция декрементации TTL (например, ATM LSR), функция ограничения области действия пострадает. Предположим, что можно вычислить заранее число шагов для заданного LSP. В уникастном LSP значение TTL может декрементироваться на входе или выходе из узла. В случае мультикаста все ветви дерева могут иметь разную длину, так что TTL может декрементироваться только на выходе, потенциально растрачивая полосу пропускания, если TTL окажется меньше или равным нулю.



    Другие маршрутные протоколы, мультипротокольные

    Более сложный синтаксис атрибутов import и export выглядит следующим образом:
    import: [protocol ] [into ]
    from [action ] . . .
    from [action ]accept

    export: [protocol ] [into ]
    to [action ] . . .
    to [action ]announce

    Этот синтаксис используется там, где при описании политики других протоколов маршрутизации могут использоваться спецификации опционных протоколов, или для введения маршрутов одного протокола в другой протокол, или для многопротокольной маршрутной политики. Корректные имена протоколов определены в словаре. является именем протокола, чьими маршрутами производится обмен. представляет собой имя протокола, который принимает данные об этих маршрутах. Как так и являются протоколами по умолчанию для IEGP (Internet Exterior Gateway Protocol), в настоящее время его функцию выполняет BGP. В последующем примере все маршруты interAS передаются протоколу RIP.
    aut-num: AS1
    import: from AS2 accept AS2
    export: protocol BGP4 into RIP to AS1 announce ANY
    В следующем примере, AS1 воспринимает маршруты AS2, включая любые адресные префиксы больше префиксов маршрутов AS2, но не передает эти дополнительные префиксы протоколу OSPF.
    aut-num: AS1
    import: from AS2 accept AS2^+
    export: protocol BGP4 into OSPF to AS1 announce AS2
    В следующем примере, AS1 передает свои статические маршруты (маршруты, которые являются членами набора AS1:RS-STATIC-ROUTES) маршрутному протоколу interAS и дважды добавляет AS1 к своему маршрутному набору AS.
    aut-num: AS1
    import:protocol STATIC into BGP4 from AS1 action aspath.prepend(AS1, AS1);
    accept AS1:RS-STATIC-ROUTES

    В следующем примере, AS1 воспринимает другой набор уникастных маршрутов для реверсивной мультикастной переадресации из AS2:
    aut-num: AS1
    import: from AS2 accept AS2
    import: protocol IDMR
    from AS2 accept AS2:RS-RPF-ROUTES



    Другие применения LSP-туннелей, маршрутизированных шаг-за-шагом

    Использование LSP-туннелей, маршрутизированных шаг-за-шагом не ограничено туннелями между узлами BGP. Любая ситуация, в которой мог бы использоваться туннель с инкапсуляцией, является приемлемой для применения LSP-туннеля, маршрутизируемого шаг-за-шагом. Вместо инкапсуляции пакета с новым заголовком, чей адрес места назначения является адресом приемной точки туннеля, производится занесение в стек метки, соответствующей адресному префиксу, который ассоциируется с адресом конечной точки туннеля. Пакет, посланный в туннель, может быть помеченным или нет.
    Если начальный узел туннеля намеревается направить помеченный пакет в туннель, он должен сначала заменить значение метки в стеке на значение, полученное от узла конца туннеля. Затем он должен занести в стек метку, которая соответствует самому туннелю. Чтобы разрешить это, конечные точки туннеля должны быть явными партнерами обмена метками. Ассоциации меток, которыми они должны обмениваться не играют никакой роли для LSR в пределах туннеля.



    Двунаправленные LSP

    В этом разделе определены двунаправленные LSP. Поддержка определена для LSP, которые имеют те же требования управления трафиком, включая долю совмещения, защиту и восстановление, LSR, и ресурсные требования (напр., задержка и разброс) для каждого из направлений. В дальнейшем под "инициатором" подразумевается узел, который начинает формирование LSP, а под "терминатором" подразумевается узел, который является конечным пунктом LSP. Заметим, что для полнодуплексных LSP, имеется только один инициатор и один терминатор.
    В норме для установления двунаправленного LSP при использовании [RFC3209] или [RFC3212] должны быть независимо сформированы два однонаправленных маршрута. Этот подход имеет следующие недостатки:
    Время установления двунаправленного LSP равно одному RTT плюс одна задержка переходного процесса инициатор-адресат. Это время не только покрывает время установления для случая успешного формирования LSP, но распространяется на худший случай обнаружения недоступного LSP, что в два раза больше переходного процесса инициатор-адресат. Эти задержки особенно существенны для LSP, которые формируются для целей восстановления.
    Избыточность управления в два раза больше чем в случае однонаправленных LSP. Это связано с тем, что нужно генерировать отдельные управляющие сообщения (напр., Path и Resv) для обоих сегментов двунаправленного LSP.
    Из-за ресурсов, занятых в отдельных сегментах выбор маршрута оказывается осложненным. Можно ожидать дополнительной конкуренции при выделении ресурсов, которая может уменьшить вероятность успешного формирования двунаправленного соединения.
    Труднее предоставить хороший интерфейс для оборудования SONET/SDH, которое может базироваться на двунаправленных пошаговых маршрутах.
    Двунаправленные оптические LSP (или световоды) рассматриваются в качестве требования большинством сетевых сервис-провайдеров.
    В случае двунаправленных LSP, пути данных вниз и вверх по течению, т.е., от инициатора до адресата и от адресата к инициатору устанавливаются с использованием одного набора сигнальных сообщений. Это уменьшает время установления до одного RTT между инициатором и адресатом плюс время обработки, и ограничивает избыточность управления до уровня числа сообщений однонаправленного LSP.

    Установление двунаправленного LSP отмечается наличием вышестоящей метки (Upstream Label) в сообщении Path. Объект Upstream_Label имеет тот же формат, что и обобщенная метка, смотри раздел 2.3. Объект Upstream_Label использует номер класса 35 (в форме 0bbbbbbb) и C-тип метки.



    EXP-Inferred-PSC LSP (E-LSP)

    Один LSP может использоваться для поддержки одного или более OA. Такие LSP могут поддерживать до восьми BA для заданного FEC, вне зависимости оттого, сколько OA охватывают эти BA. Для таких LSP, поле EXP заголовка MPLS используется LSR, чтобы определить PHB, которое следует применить к пакету. Это включает как PSC, так и приоритет отбрасывания.
    Мы называем такие LSP - "EXP-inferred-PSC LSPs" (E-LSP), так как PSC пакета, транспортируемого по этому LSP, зависит от значения поля EXP конкретного пакета.
    Установление соответствия между полем EXP и PHB (т.е., PSC и приоритет отбрасывания) для заданного LSP, либо осуществляется явно путем сигнального обмена при выполнении процедуры set-up, либо базируется на предварительном конфигурировании. Подробное описание E-LSP представлено в разделе 3.



    Фальсификация

    Существует два вида LDP-коммуникаций, которые могут быть объектом атак фальсификации (spoofing).
    1. Выявление обменов, реализуемых через UDP.
    LSR, подключенные непосредственно к каналу, обмениваются базовыми сообщениями Hello через этот канал. Угроза фальсификации базовых Hello может быть уменьшена посредством:
  • Прием базовых Hellos только через интерфейсы, к которым достойные доверия LSR подключены непосредственно.

  • Игнорирование базовых Hello, которые не адресованы ко всем маршрутизаторам мультикастной группы данной субсети.

    • LSR, не подключенные непосредственно к каналу, могут использовать сообщения расширенного Hello, чтобы демонстрировать желание установить LDP сессию. LSR может уменьшить угрозу фальсификации расширенных Hello путем фильтрации их и приема только тех, что были отправлены с адресов разрешительного списка.
    2. Коммуникационные сессии через TCP.
    LDP специфицирует использование опции подписи TCP MD5, чтобы обеспечить аутентичность и целостность сообщений сессии. [RFC2385] декларирует, что аутентификация MD5 рассматривается сейчас как слишком слабая для данного приложения. Отмечается также, что могла бы использоваться аналогичная опция TCP с более сильным алгоритмом хэширования (например, SHA-1). Однако заметим, что LDP может использовать любую технику дайджестов для TCP сообщений.



    FEC TLV

    Метки связаны с FEC (Forwarding Equivalence Class). FEC представляет собой список из одного или более элементов FEC. TLV FEC кодирует значения FEC. Формат представления FEC показан ниже:
    FEC TLV

    Элементы FEC от 1 до n
    Существует несколько типов элементов FEC; смотри раздел "FEC". Кодирование элементов FEC зависит от типа элемента.
    Значение элемента FEC кодируется как однооктетное поле, которое специфицирует тип элемента, и поле переменной длины, которое представляет собой значение элемента, зависящее от типа. Заметим, что в то время как представление значения элемента FEC зависит от типа, представление самого элемента FEC является единственным, где стандартное кодирование LDP TLV не используется.
    Значения элемента FEC кодируется следующим образом:

    Название элемента FEC
    Тип
    Значение
    Wildcard 0x01 Нет значения; т.e., 0 октетов значения; смотри ниже
    Префикс 0x02 Смотри ниже
    Адрес ЭВМ 0x03 Полный адрес ЭВМ; смотри ниже

    Заметим, что эта версия LDP поддерживает использование нескольких элементов FEC на один FEC для сообщения присвоения метки. Использование нескольких элементов FEC в других сообщениях в данной версии запрещено.
    Элемент Wildcard FEC
    Предназначен для использования только в сообщениях присвоения и отзыва меток. Указывает, что отзыв/присвоение следует применить ко всем FEC, ассоциированным с меткой в пределах следующего TLV метки. Кодирование значений элементов префикса FEC:
    FEC TLV

    Семейство адресов
    Двухоктетная величина, содержащая значение из списка кодов семейств адресов (смотри [RFC1700]), которое характеризует семейство адресов для адресного префикса в поле префикс.
    PreLen
    Однооктетное целое без знака, содержащее длину в битах последующего адресного префикса. Длина равная 0 говорит о том, что префикс соответствует всем адресам (адрес назначения по умолчанию); в этом случае сам префикс имеет нуль октетов).
    Префикс
    Адресный префикс, закодированный согласно полю семейство адресов, чья длина в битах была специфицирована в поле PreLen, дополненному до границы, кратной байту.
    Элемент FEC адреса ЭВМ имеет формат, описанный ниже:
    FEC TLV

    Семейство адресов
    Двухоктетная величина, содержащая значение из списка кодов семейств адресов (смотри [RFC1700]), которое характеризует семейство адресов для адресного префикса в поле префикс.
    Длина адреса ЭВМ
    Длина адреса ЭВМ в октетах.
    Адрес ЭВМ
    Адрес, закодированный согласно полю семейство адресов.



    FEC

    Необходимо точно определить, какие пакеты могут быть поставлены в соответствие каждому LSP. Это делается с помощью FEC-спецификации для каждого LSP. FEC идентифицирует набор пакетов, которые могут быть ассоциированы с данным LSP.
    Каждый FEC специфицируется как набор из одного или более элементов FEC. Каждый FEC-элемент определяет набор пакетов, которые могут быть ассоциированы с соответствующим LSP. Когда LSP пользуется несколькими элементами FEC, такой LSP завершается в узле (или раньше), где элементы FEC не могут более следовать одним путем.
    Ниже определяются типы элементов FEC. Если потребуется, может быть добавлен новый FEC:
  • Адресный префикс. Этот элемент является адресным префиксом произвольной длины от 0 до полного адреса включительно.

  • Адрес ЭВМ. Этот элемент является полным адресом ЭВМ.

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

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

  • Если пакет в точности соответствует одному LSP, пакет ассоциируется с этим LSP.

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


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


    • Целесообразно отметить несколько следствий этих правил:

  • Пакет может быть послан по LSP, чей адресный префикс элемента FEC является адресом выходного маршрутизатора, ТОЛЬКО если нет LSP, согласующихся с адресом места назначения пакета.


  • Пакет может соответствовать двум LSP, одному с FEC элементом адреса ЭВМ, а другому с FEC элементом префикса адреса. В этом случае пакеты ассоциируются всегда со вторым из этих LSP.


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



    • Формат с привязкой ресурса

    Класс SESSION_ATTRIBUTE = 207, LSP_TUNNEL_RA C-тип = 1

    Формат с привязкой ресурса

    Рис. 15.

    Исключает любой32-битный вектор, представляющий набор атрибутов фильтров, сопряженных с туннелем, каждый из которых может объявлять канал неприемлемымВключает любой32-битный вектор, представляющий набор атрибутов фильтров, сопряженных с туннелем, каждый из которых может объявить канал приемлемым (с точки зрения данного теста). Нулевой набор (все биты равны нулю) автоматически проходит.Включают все32-битный вектор, представляющий набор атрибутов фильтров, сопряженных с туннелем, каждый из которых должен присутствовать, чтобы канал был приемлем (с точки зрения данного теста). Нулевой набор (все биты равны нулю) автоматически проходит.Приоритет SetupПриоритет сессии с точки зрения захвата ресурсов, в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет Setup используется при решении, может ли сессия идти вне очереди по отношению к другой сессииПриоритет удержанияПриоритет сессии с точки зрения удержания ресурсов, в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет удержания используется при решении, может ли сессия быть замещена другой сессиейФлаги0x01 Желательна локальная защита
    Этот флаг позволяет промежуточным маршрутизаторам использовать механизм локального восстановления, который может вызвать нарушение объекта явного маршрута. Когда детектирована ошибка в смежном канале вниз по течению или узле, транзитный маршрутизатор может переадресовать трафик для службы быстрого восстановления.

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

    0x04 Желателен стиль SE
    Этот флаг индицирует то, что входной узел туннеля может решить изменить маршрут этого туннеля без его удаления. Узел конца туннеля, реагируя на сообщение Resv, должен использовать стиль SE.Длина имениДлина отображаемой строки до заполнителя в байтахИмя сессии Строка символов дополненная нулем



    Формат сообщений Path

    Сообщения Path имеют следующий формат:
    ::= [ ]


    [ ]

    [ ]
    [ ]
    [ ... ]
    [ ]
    ::=
    [ ]
    [ ]



    Формат сообщений RSVP, связанных с Diff-Serv

    В данном документе определен один новый объект RSVP: DIFFSERV. Подробное описание этого объекта представлено ниже. Этот новый объект применим к сообщениям Path. Данная спецификация определяет только использование объекта DIFFSERV в сообщениях Path, предназначенных для установления туннелей LSP в соответствии [RSVP_MPLS_TE], и, таким образом, содержащих объект Session с C-Type равным LSP_TUNNEL_IPv4 и объект LABEL_REQUEST.
    Ограничения, определенные в [RSVP_MPLS_TE] для поддержки установления туннелей LSP с помощью RSVP, применимы для формирования туннелей LSP, поддерживающих Diff-Serv: например, поддерживаются только уникастные LSP, а мультикастные будут рассмотрены позднее.
    Этот новый объект DIFFSERV является опционным с точки зрения RSVP, для того чтобы реализации RSVP, несвязанные с формированием MPLS LSP не должны поддерживать этот объект.
    Объект DIFFSERV является опционным для поддержки туннелей LSP, как это определено в [RSVP_MPLS_TE]. LSR, способный поддерживать Diff-Serv E-LSP, использующий предварительно сконфигурированные таблицы EXP<-->PHB в согласии с этой спецификацией может поддерживать объект DIFFSERV. LSR, способный поддерживать Diff-Serv E-LSP, использующий согласованную таблицу EXP<-->PHB, в согласии с этой спецификацией должен поддерживать объект DIFFSERV. LSR, способный поддерживать Diff-Serv L-LSP, в согласии с этой спецификацией должен поддерживать объект DIFFSERV.



    Форматы, относящиеся к меткам

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

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



    Форматы сообщений RSVP

    В этом разделе описаны форматы сообщений RSVP. Там где они отличаются, форматы для однонаправленных LSP представлены отдельно от двунаправленных LSP. MESSAGE_ID и сопряженные объекты определены в [RFC2961]. Формат сообщения Path представлен ниже:
    ::= [ ]
    [ [ | ] ... ]
    [ ]


    [ ]

    [ ]
    [ ... ]
    [ ]
    [ ]
    [ ]
    [ ... ]

    Формат дескриптора отправителя для однонаправленного LSP имеет вид:
    ::=
    [ ]
    [ ]
    [ ]
    [ ]
    Формат дескриптора отправителя для двунаправленного LSP имеет вид:
    ::=
    [ ]
    [ ]
    [ ]
    [ ]

    Формат сообщения PathErr имеет вид:
    ::= [ ]
    [ [| ] ... ]
    [ ]

    [ ... ]
    [ ... ]

    Формат сообщения Resv имеет вид:
    ::= [ ]
    [ [| ] ... ]
    [ ]


    [ ] [ ]
    [ ]
    [ ]
    [ ... ]