RFC: 3032
Оригинал: MPLS Label Stack Encoding
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , , , ,
Перевод: Мельников Дмитрий Анатольевич

Оглавление

1. Предисловие

Этот стандарт определяет правила кодирования, используемые LSR-маршрутизаторами при передаче помеченных IP-пакетов по сквозным каналам передачи данных, организуемых PPP-протоколом (Point-to-Point Protocol, протокол (канального уровня) сквозного канала передачи данных), и каналам передачи данных локальных вычислительных сетей (ЛВС). Предлагаемые правила кодирования могут быть полезны и для других типов соединений канального уровня.

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

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

2. Набор маркеров

2.1. Кодирование набора маркеров

Набор маркеров представляет собой последовательность «записей набора маркеров». Каждая запись в наборе включает четыре байта (рис. 1).

| 0                                  19 | 20             22 |23 | 24         31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Значение маркера            | Экспериментальные | S | «Время жизни» |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рис. 1. Формат записи набора маркеров

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

Каждая запись набора маркеров включает следующие поля:

  1. Бит «S» (окончание набора маркеров)

    Этот бит указывает на окончание набора маркеров, если он установлен в «1». Если же он нулевой, то за этой записью набора ещё будут следовать записи.

  2. «Время жизни» (Time to Live, TTL)

    Это 8-битовое поле используется для кодирования TTL-значения.

  3. «Экспериментальное поле» (3 бита)

    Это 3-битовое поле зарезервировано для экспериментальных исследований.

  4. «Значение маркера потока» (20 бит)

    Это 20-битовое поле содержит реальное значение маркера потока.

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

    1. следующий ретрансляционный участок, по которому будет далее транслироваться IP-пакет;

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

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

    1. Значение «0» представляет собой «явный нулевой маркер для IPv4-протокола» (IPv4 explicit NULL label). Это значение может располагаться только (и только) на самом нижнем уровне набора маркеров. Оно указывает на то, что набор маркеров должен быть удалён, а дальнейшая доставка IP-пакета, должна осуществляться на основе IPv4-заголовка.

    2. Значение «1» представляет собой «маркер-предупреждение для маршрутизатора» (router alert label). Этот маркер может располагаться на любом, кроме самого нижнего, уровне набора маркеров. Если полученный IP-пакет содержит, на самом верхнем уровне набора, маркер с таким значением, то он должен быть обработан локальным программным модулем. Реальная доставка IP-пакета определяется маркером, расположенным ниже этого маркера в наборе. Однако, если IP-пакет направляется дальше, то целесообразно перед отправкой вставить «маркер-предупреждение» обратно в набор маркеров. Использование такого маркера аналогично использованию дополнительной функции в IP-пакетах «функция предупреждения для маршрутизатора» (router alert option, RFC-2113[?] ). Так как этот маркер не может размещаться на самом нижнем уровне набора маркеров, он никак не связан с каким-либо протоколом сетевого уровня.

    3. Значение «2» представляет собой «явный нулевой маркер для IPv6-протокола» (IPv6 explicit NULL label). Это значение может располагаться только (и только) на самом нижнем уровне набора маркеров. Оно указывает на то, что набор маркеров должен быть удалён, а дальнейшая доставка IP-пакета, должна осуществляться на основе IPv6-заголовка.

    4. Значение «3» представляет собой «неявный нулевой маркер» (implicit NULL label). Такой маркер назначается и распространяется LSR-маршрутизаторами, но никогда не подвергается процедуре повторного обрамления. Если LSR-маршрутизатору следует заменить маркер верхнего уровня в наборе на новый маркер, а новым маркером является неявный нулевой маркер, то LSR-маршрутизатор просто удалит весь набор маркеров вместо возможной замены маркеров. Несмотря на то, что это значение маркера никогда не может быть подвергнуто повторному обрамлению, это необходимо отразить в LDP-протоколе, т.е. это значение зарезервировать.

    5. Значения «4…15» зарезервированы.

2.2. Определение протокола сетевого уровня

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

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

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

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

2.3. Формирование сообщений ICMP-протокола для помеченных IP-пакетов

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

  1. у LSR-маршрутизатора должна быть возможность определения, что соответствующий помеченный пакет является IP-пакетом;
  2. у LSR-маршрутизатора должна быть возможность определения маршрута до адреса отправителя IP-пакета.

2.3.1. Формирование туннеля через транзитный маршрутизационный сетевой сегмент

Предположим, что для «прокладки туннеля» через транзитный маршрутизационный сетевой сегмент используется MPLS-коммутация, и что внутренние маршрутизаторы сегмента ничего не знают о внешних маршрутах. Например, внутренние маршрутизаторы сегмента функционируют в соответствие OSPF-протоколом, и они могут знать только о том, как связаться с другими узлами-получателями в пределах этого OSPF-сегмента. Сетевой сегмент может включать несколько граничных маршрутизаторов автономной системы (Autonomous System Border Router, ASBR), которые при взаимодействии друг с другом используют BGP-протокол. Тем не менее, в данном примере маршруты, сформированные с помощью BGP-протокола, не распространяются на OSPF-сегмент, а LSR-маршрутизаторы, которые не являются ASBR-маршрутизаторами, не реализуют BGP-протокол.

В данном примере, только ASBR-маршрутизатор «будет знать» как направить некоторый произвольный пакет его отправителю. Если внутреннему маршрутизатору понадобиться передать ICMP-сообщение отправителю IP-пакета, то он просто не будет знать, как его передать. Одним из возможных решений является наличие одного или более ASBR-маршрутизаторов, которые в режиме «по умолчанию» начинают взаимодействовать с другими маршрутизаторами по IGP-протоколу.

Примечание. В данном случае от BGP-протокола не требуется поддержка режима «по умолчанию».

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

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

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

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

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

Этот способ может быть очень полезен, если ICMP-сообщение является сообщением «Превышение времени» (time exceeded) или сообщением «Получатель не достижим — необходима фрагментация и бит «DF» установлен в единицу» (destination unreachable because fragmentation needed and DF set).

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

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

2.4. Обработка TTL-поля

2.4.1. Определения

Термин «входящее TTL-время» (incoming TTL) помеченного пакета определяет значение в TTL-поле самой верхней записи набора маркеров в момент получения пакета.

Термин «исходящее TTL-время» (outgoing TTL) помеченного пакета определяет значение, которое должно быть больше:

  1. входящего TTL-времени, уменьшенного на единицу;
  2. нуля.

2.4.2. Независимые от протоколов правила

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

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

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

2.4.3. Зависимые от IP-протокола правила

Введём обозначение «IP/TTL-поле». Значение этого поля должно быть равно значению, которое содержится в TTL-поле заголовка IPv4-пакета или в поле «Hop Limit» (максимальное число ретрансляционных участков, RFC-2460) заголовка IPv6-пакета (в зависимости от того, какая версия IP-протокола используется).

Когда IP-пакет маркируется впервые, тогда значение в TTL-поле записи набора маркеров должно быть равно значению IP/TTL-поля. (Если значение IP/TTL-поля следует уменьшить на единицу, как часть обработки IP-пакета, то подразумевается, что это уже было сделано.)

Если маркер «удаляется», и в результате набор маркеров остаётся пустым, то значение IP/TTL-поля должно быть заменено на значение исходящего TTL-времени, как было рассмотрено выше. В IPv4-протоколе это потребует изменения контрольной проверочной суммы IPv4-заголовка пакета.

Это указывает на то, что могут возникнуть ситуации, в которых сетевая администрация предпочитает уменьшать на единицу значение в TTL-поле заголовка IPv4-пакета, как это осуществляется в сетевом MPLS-сегменте, вместо уменьшения значения в TTL-поле заголовка IPv4-пакета на число ретрансляционных участков LSP-маршрута, в границах сетевого сегмента.

2.4.4. Трансляция между узлами, реализующими различные типы процедуры повторного обрамления

Иногда LSR-маршрутизатор может получить помеченный пакет, который, например, был передан с выходного интерфейса ATM/LSR-коммутатора (LC-ATM, RFC-3035[?] ), и может понадобиться передать такой пакет по сквозному соединению канального уровня (PPP-протокол), либо через ЛВС. Тогда входящий пакет не будет обработан с использованием процедуры повторного обрамления, устанавливаемой данным стандартом, в то время как исходящий пакет будет обработан с использованием такой процедуры.

В таком случае, значение входящего TTL-времени определяется с помощью процедур, используемых при доставке помеченных пакетов, например, с помощью ATM/LSR-коммутаторов. А обработка TTL-поля осуществляется, как было описано ранее.

Иногда LSR-маршрутизатор может получить помеченный пакет, который, например, был передан по сквозному соединению канального уровня (PPP-протокол), либо через ЛВС, и может понадобиться передать такой пакет, скажем, на входной интерфейс ATM/LSR-коммутатора.

Тогда входящий пакет будет обработан с использованием процедуры повторного обрамления, устанавливаемой данным стандартом, в то время как исходящий пакет будет не обработан с использованием такой процедуры. В таком случае, процедура доставки значения исходящего TTL-времени определяется процедурами, используемыми при доставке помеченных пакетов, например, с помощью ATM/LSR-коммутаторов.

3. Фрагментация и определение маршрута с минимальным MTU-значением

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

Кроме того, можно получить пакет (маркированный или нет), который при отправке имел размер, не превышающий разрешённое допустимое значение для передачи по линии связи, но который стал намного длиннее благодаря одному или нескольким дополнительным маркерам, вставленным в набор маркеров. В MPLS-системах размер пакетов может увеличиваться за счёт вставленных дополнительных маркеров. Таким образом, если получен помеченный пакет, который был обрамлён в кадр (frame) канального уровня с полем полезной нагрузки (payload), имеющим длину 1500 байт, то после вставки дополнительного маркера понадобиться отправить кадр канального уровня с полем полезной нагрузки, имеющим длину 1504 байта.

Вообще IPv4-узлы, которые не используют процедуру поиска маршрута с минимальным MTU-значением (path MTU discovery, RFC-1191, далее — MTU-маршрут), транслируют IP-пакеты, которые содержат не более 576 байт. Так как в большинстве Internet-сетей используется процедура поиска MTU-маршрута, то в своём большинстве современные линии связи позволяют передавать кадры канального уровня с 1500-байтовой полезной нагрузкой, и поэтому вероятность использования процедуры фрагментации пакетов, в том числе и помеченных, чрезвычайна мала.

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

К сожалению, некоторые IP-узлы формируют IP-пакеты, включающие 1500 байт, пока IP-адреса отправителя и получателя имеют один и тот же определённый номер сети. В таких случаях существует риск фрагментации, особенно когда такие IP-пакеты маркируются. (Даже при таких условиях, фрагментация не возможна до тех пор, пока IP-пакет должен транслироваться через ЛВС «Ethernet» (некоторой разновидности) в период между начальным маркированием и удалением последнего маркера.)

3.1. Термины и определения

В дальнейшем используются следующие термины, касающиеся канального уровня Internet-архитектуры:

  • Поле полезной нагрузки кадра (frame payload)

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

  • Стандартный максимальный размер поля полезной нагрузки кадра (conventional maximum frame payload size)

    Этот размер допускается стандартами передачи по линиям/каналам связи (например, для ЛВС «Ethernet» этот размер составляет 1500 байт).

  • Реальный (действительный) максимальный размер поля полезной нагрузки кадра (true maximum frame payload size)

    Это максимальный размер поля полезной нагрузки, который может быть передан и получен через подключённый к каналу передачи данных физический интерфейс сетевого программно-аппаратного комплекса. В ЛВС «Ethernet» и стандарта 802.3 считается, что реальный максимальный размер поля полезной нагрузки кадра на 4…8 байт больше, чем стандартный максимальный размер поля (если не используются заголовки стандартов 802.1Q и 802.1p, и если коммутатор или мост не могут ничего добавить, когда кадр транслируется на свой следующий ретрансляционный участок). Например, считается, что большая часть современного Ethernet-оборудования способна корректно передавать и принимать кадры, содержащие в поле полезной нагрузки 1504 байта или даже 1508 байт, по крайней мере, до тех пор, пока Ethernet-заголовок не содержит полей, предусмотренных стандартами 802.1Q и 802.1p.

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

  • Эффективный максимальный размер поля полезной нагрузки кадра для помеченных IP-пакетов (effective maximum frame payload size for labeled packets)

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

  • Впервые помеченный IP-пакет (initially labeled IP datagram)

    Предположим, что некоторый LSR-маршрутизатор получил непомеченный IP-пакет, и что этот LSR-маршрутизатор перед отправкой IP-пакета вставляет в него маркер. Такой IP-пакет именуется впервые помеченным IP-пакетом в этом LSR-маршрутизаторе.

  • Ранее помеченный IP-пакет (previously labeled IP datagram)

    Это IP-пакет, который был помечен до того, как поступил на вход некоторого LSR-маршрутизатора.

3.2. Максимальный размер впервые помеченного IP-пакета

Каждый LSR-маршрутизатор, который способен:

  1. принимать не помеченный IP-пакет;
  2. добавлять набор маркеров в IP-пакет;
  3. доставлять итоговый помеченный IP-пакет, должен поддерживать конфигурационный параметр (параметр настройки), известный как «максимальный размер впервые помеченного IP-пакета» (maximum initially labeled IP datagram size), который может иметь не отрицательное значение.

Если этот параметр настройки имеет нулевое значение, то это не имеет никакого эффекта.

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

Если:

  1. получен не помеченный IP-пакет;
  2. в заголовке этого IP-пакета бит «DF»[?] (Don't Fragment) имеет нулевое значение («можно фрагментировать»);

и:

  1. этот IP-пакет необходимо пометить, прежде чем он будет отправлен;
  2. размер IP-пакета (перед маркированием) превышает значение этого параметра;

то:

  1. IP-пакет должен быть поделён на фрагменты, причём длина каждого фрагмента не должна превышать значение этого параметра;
  2. каждый фрагмент должен быть помечен ещё до его отправки.

Например, если параметр настройки имеет значение 1488, то любой не помеченный IP-пакет, длиной более 1488 байт, должен быть фрагментирован ещё до его маркирования. Каждый фрагмент можно будет транслировать по 1500-байтовому каналу передачи данных (т.е., использовать кадр, у которого длина поля полезной нагрузки составляет 1500 байт) без последствий, даже если в его набор маркеров будет вставлено несколько маркеров, например, три.

Другими словами, установка этого параметра в ненулевое значение позволяет исключить фрагментацию ранее помеченных IP-пакетов, но это может привести, в некотором смысле, к ненужной фрагментации впервые маркируемых IP-пакетов.

Следует заметить, что установка этого параметра не даёт эффекта при обработке IP-пакетов, в которых бит «DF» имеет значение «1» («не фрагментировать»). Следовательно, при установке этого параметра результат процедуры поиска MTU-маршрута остаётся неизменным.

3.3. Если размер помеченного IP-пакета слишком большой

Помеченный IP-пакет, размер которого превышает стандартный максимальный размер поля полезной нагрузки кадра, передаваемого по определённому каналу передачи данных, может считаться «слишком большим» (too big).

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

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

3.4. Обработка помеченных IPv4-пакетов, которые являются «слишком большими»

Если помеченный IPv4-пакет является слишком большим, а бит «DF» в IP-заголовке имеет значение «0» («можно фрагментировать»), то LSR-маршрутизатор может по-умолчанию удалить этот IPv4-пакет.

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

Если LSR-маршрутизатор принял решение не уничтожать помеченный IPv4-пакет, являющийся слишком большим, или если в этом пакете бит «DF» имеет значение «1», то он обязан выполнить следующую процедуру (алгоритм):

  1. Очистить записи набора маркеров до получения IPv4-пакета.

  2. Пусть N будет числом (количество) байт в наборе маркеров (т.е., число записей в наборе маркеров кратное 4).

  3. Если в заголовке IPv4-пакета бит «DF» имеет значение «0» («можно фрагментировать»), то:

    1. Фрагментировать IPv4-пакет, и при этом каждый фрагмент должен иметь длину, по крайней мере, на N байт меньше, чем эффективный максимальный размер поля полезной нагрузки кадра.

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

    3. Транслировать фрагменты.

  4. Если в заголовке IPv4-пакета бит «DF» имеет значение «1» («не фрагментировать»), то:

    1. IPv4-пакет не должен транслироваться далее.

    2. Сформировать ICMP-сообщение «Узел-получатель не достижим» (destination unreachable):

      1. В поле «Код ошибки» заголовка этого ICMP-сообщения установить значение «4» (требуется фрагментация, и установка бита «DF», fragmentation required and DF set).

      2. В поле «MTU-значение следующего ретрансляционного участка» (next-hop MTU, RFC-1191) заголовка этого ICMP-сообщения установить значение, равное разнице между значением эффективного максимального размера поля полезной нагрузки кадра и значением N.

    3. Если возможно, то передать это ICMP-сообщение «Узел-получатель не достижим» отправителю уничтоженного IPv4-пакета.

3.5. Обработка помеченных IPv6-пакетов, которые являются «слишком большими»

При обработке помеченного IPv6-пакета, являющегося слишком большим, LSR-маршрутизатор обязан выполнить следующую процедуру (алгоритм):

  1. Очистить записи набора маркеров до получения IPv6-пакета;

  2. Пусть N будет числом (количество) байт в наборе маркеров (т.е., число записей в наборе маркеров кратное 4).

  3. Если IPv6-пакет содержит более 1280 байт (не включая записи набора маркеров), или если IPv6-пакет не содержит заголовок расширения «Фрагментация», то:

    1. Сформировать ICMP-сообщение «Сообщение слишком большое» (too big message), и установить в поле «MTU-значение следующего ретрансляционного участка» заголовка этого ICMP-сообщения значение, равное разнице между значением эффективного максимального размера поля полезной нагрузки кадра и значением N.

    2. Если возможно, то передать это ICMP-сообщение «Сообщение слиш- ком большое» отправителю уничтоженного IPv6-пакета.

    3. Удалить помеченный IPv6-пакет.

  4. Если IPv6-пакет содержит не более 1280 байт, или если IPv6-пакет содержит заголовок расширения «Фрагментация», то:

    1. Фрагментировать IPv6-пакет, и при этом каждый фрагмент должен иметь длину, по крайней мере, на N байт меньше, чем эффективный максимальный размер поля полезной нагрузки кадра.

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

    3. Транслировать фрагменты.

    Повторная сборка фрагментов будет проведена в узле-получателе.

3.6. Последствия, вызванные процедурой поиска MTU-маршрута

Рассмотренные выше процедуры обработки IP-пакетов, содержащих бит «DF» со значением «1», но являющихся «слишком большими», влияют на процедуры поиска MTU-маршрута (RFC-1191). IP-узлы, которые применяют эти процедуры, будут устанавливать MTU-маршрут, в котором MTU-значение достаточно мало, что позволит вставить в IP-пакет n маркеров, и при этом не возникнет необходимости в процедуре фрагментации (где n — число маркеров, которые фактически вставлены в пакет, доставляемому по выбранному маршруту).

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

Следует заметить, что процедура поиска MTU-маршрута будет «работать» корректно, если только в точке, в которой необходимо провести фрагментирование помеченных IP-пакетов, можно добиться, чтобы ICMP-сообщение «Узел-получатель не достижим» было направлено по адресу узла-отправителя.

Если невозможно направить ICMP-сообщение «Узел-получатель не достижим» по адресу узла-отправителя в рамках MPLS-туннеля, но настройка сети позволяет LSR-маршрутизатору в крайней точке передачи туннеля принимать IP-пакеты, которые должны быть переданы по туннелю, но, в тоже время, эти IP-пакеты являются слишком большие, чтобы их транслировать по туннелю не фрагментируемыми, то:

  • LSR-маршрутизатор в крайней точке передачи туннеля должен обладать способностью определения MTU-значение туннеля в целом. Он это может сделать путём передачи IP-пакетов по туннелю в крайнюю точку приёма этого туннеля, и путём выполнения процедуры поиска MTU-маршрута в интересах таких IP-пакетов.

  • Каждый раз, когда в крайней точке передачи туннеля необходимо отправить в туннель IP-пакет, а последний в своём заголовке содержит бит «DF» со значением «1», и он превышает MTU-значение туннеля, то в крайней точке передачи туннеля должно быть передано ICMP-сообщение «Узел-получатель не достижим» узлу-отправителю этого IP-пакета, содержащее код ошибки «Требуется фрагментация, и установка бита «DF» и установленное значение (как это было описано выше) в поле «MTU-значение следующего ретрансляционного участка».

4. Доставка помеченных пакетов по PPP-соединениям

PPP-протокол реализует стандартный способ транспортировки многопротокольных пакетов по сквозным соединениям канального уровня. Этот протокол определяет дополнительный протокол управления линией (каналом) связи (Link Control Protocol, LCP) и предоставляет семейство протоколов сетевого управления (Network Control Protocol, NCP) для формирования и настройки различных протоколов сетевого уровня.

4.1. Введение

PPP-протокол включает три следующих основных компонента:

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

  2. LCP-протокол для формирования, настройки и тестирования соединений канального уровня.

  3. Совокупность NCP-протоколов для установки и настройки различных протоколов сетевого уровня.

С целью установления сквозного соединения PPP-протокола, каждая сторона PPP-соединения должна, во-первых, передать LCP-сообщения для настройки и проверки соединения канального уровня (канала передачи данных). После того, как соединение установлено, и все его необходимые дополнительные параметры согласованы с помощью LCP-протокола, PPP-протокол обязан отправить пакеты протокола MPLS-управления (MPLS Control Protocol) с целью обеспечения последующей доставки помеченных пакетов. После того, как выполнение соответствующих протокольных процедур MPLS-управления (как конечного автомата) переведёт соединение в открытое состояние (opened state), помеченные пакеты могут доставляться по сквозному соединению.

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

4.2. NCP-протокол (в рамках PPP-протокола) для MPLS-коммутации

Протокол управления MPLS-коммутацией (MPLS Control Protocol, MPLSCP) несёт ответственность за использование (не использование) MPLS-коммутации на сквозных PPP-соединениях. Он использует способ обмена пакетами, аналогичный LCP-протоколу. Пакеты MPLSCP-протокола не используются до тех пор, пока выполнение соответствующих процедур PPP-протокола не достигнет фазы функционирования протокола сетевого уровня. MPLSCP-пакеты, полученные до наступления этой фазы, должны по-умолчанию уничтожаться.

MPLSCP-протокол полностью совпадает с LCP-протоколом, за исключением следующих аспектов:

  1. Модификации кадра

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

  2. Поле протокола канального уровня

    В поле полезной нагрузки PPP-кадра может размещаться всего лишь один MPLSCP-пакет, а в поле «Протокол» этого же кадра содержится значение 0x8281 («MPLS»).

  3. Поле «Код»

    Используется только один и следующих семи кодов: Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack и Code-Reject. Другие коды должны рассматриваться как неизвестные и просто уничтожаться.

  4. Значения тайм-аута

    Пакеты MPLSCP-протокола не используются до тех пор, пока выполнение соответствующих процедур PPP-протокола не достигнет фазы функционирования протокола сетевого уровня. Реально действующий программный модуль должен быть настроен на ожидание окончания фаз «Аутентификация» и «Определение качества соединения», а после завершения этих фаз он должен включить счётчик тайм-аута и ожидать ответного кода Configure-Ack (подтверждение настройки сквозного соединения) или иного ответа. Последнее означает, что программный модуль прерывает соединение только после вмешательства пользователя или по истечении установленного времени соединения.

  5. Дополнительные функции настройки

    Не предусмотрены.

4.3. Передача помеченных пакетов

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

В поле полезной нагрузки PPP-кадра может размещаться всего лишь один помеченный, а в поле «Протокол» этого же кадра содержится, либо значение 0x0281 («MPLS Unicast», однонаправленный маркер), либо значение 0x0283 («MPLS Multicast», групповой маркер). Максимальный размер помеченного пакета, транслируемого по PPP-соединению, равен длине поле полезной нагрузки PPP-кадра, в котором размещается данный пакет.

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

4.4. Дополнительные функции настройки протокола управления коммутацией на основе маркеров потока

В рамках протокола управления коммутацией на основе маркеров потока такие функции отсутствуют.

5. Доставка помеченных пакетов через лвс

Лишь только один помеченный пакет доставляется в каждом кадре ЛВС.

Набор маркеров размещается непосредственно перед заголовком сетевого уровня, и следует за любыми заголовками канального уровня, включая, например, заголовки стандарта 802.1Q, которые могут существовать.

Для указания того, что в кадре ЛВС доставляется MPLS-пакет с однонаправленным маркером, используется значение 0x8847 в поле «Ether Type» (тип транслируемого пакета) заголовка этого кадра.

Для указания того, что в кадре ЛВС доставляется MPLS-пакет с многонаправленным маркером, используется значение 0x8848 в поле «Ether Type» заголовка этого кадра.

Эти значения в поле «Ether Type» могут использоваться при доставке помеченных пакетов в кадрах Ethernet и 802.3 LLC/SNAP стандартов. Процедура выбора одного из двух этих стандартов в данном документе не рассматривается.

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

Label values 0-15 inclusive have special meaning, as specified in this document, or as further assigned by IANA.

In this document, label values 0-3 are specified in section 2.1.

Label values 4-15 may be assigned by IANA, based on IETF Consensus.

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

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

Существуют две проблемы обеспечения ИБ, вытекающие из MPLS-архитектуры, и которые могут быть указаны здесь:

  • Некоторые маршрутизаторы могут использовать процедуры обеспечения безопасности, которые зависят от заголовка сетевого уровня, расположенного в фиксированном месте относительно заголовка канального уровня. Указанные процедуры не будут «работать» при использовании MPLS-коммутации помеченных пакетов, так как вставка таких пакетов в кадр канального уровня предусматривает изменяемый размер некоторых полей кадра.

  • MPLS-маркер имеет смысл в силу некоторого соглашения между LSR-маршрутизаторами, один из которых вставляет маркер в набор маркеров («запись маркера»), а другой интерпретирует этот маркер («чтение маркера»). Тем не менее, набор маркеров не имеет каких-либо средств для определения, кто вписал соответствующий маркер. Если помеченные пакеты поступают от ненадёжных источников, то такие пакеты могут доставляться по нелегитимным маршрутам.

Ссылки

[1] Rosen, E., Viswanathan, A., and R. Callon, «Архитектура многопротокольной коммутации на основе маркеров потока (MPLS)», RFC 3031, Январь 2001.
[2] Bradner, S., «Ключевые слова для обозначения уровня требований в RFC», BCP 14, RFC 2119, Март 1997.
[3] Postel, J., «Протокол ICMP», STD 5, RFC 792, Сентябрь 1981.
[4] Mogul, J. и S. Deering, «Исследование MTU на пути следования сообщения», RFC 1191, Ноябрь 1990.
[5] Katz, D., «IP Router Alert Option», RFC 2113, Февраль 1997.
[6] Simpson, W., Editor, «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, Июль 1994.
[7] Conta, A. и S. Deering, «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 1885, Декабрь 1995.
[8] McCann, J., Deering, S. и J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, Август 1996.
[9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. и G. Swallow, «Применение MPLS-коммутации в сетях с асинхронным режимом доставки», RFC 3035, Январь 2001.
2007 - 2022 © Русские переводы RFC, IETF, ISOC.