E. Rosen, RFC-3032, MPLS Label Stack Encoding

Аннотация

"Многопротокольная коммутация меток (MPLS)" [1] требует наличия набора процедур для пакетов со стеком меток (помеченных пакетов). Маршрутизаторы, которые поддерживают MPLS, называются LSR (Label Switching Routers). Для того чтобы переслать помеченный пакет по конкретному каналу, LSR должен поддерживать систему представления стека меток и обработки пакетов сетевого уровня. В данном документе специфицирована система представления стека меток, используемая LSR, для того чтобы передавать помеченные пакеты по каналам PPP (Point-to-Point Protocol), по каналам данных LAN, и возможно по другим каналам. В других каналах кодирование может быть иным, но представление стека меток должно быть стандартным. Здесь также специфицируются правила и процедуры для обработки различных полей записей в стеке меток.

1. Введение

"Многопротокольная коммутация меток (MPLS)" [1] требует набора процедур для дополнения пакетов сетевого уровня "стеком меток", таким образом превращая их в помеченные пакеты. Маршрутизаторы, которые поддерживают протокол MPLS, называются LSR (Label Switching Routers). Для того чтобы передать помеченный пакет по определенному каналу, LSR должен поддерживать методику кодирования, и анализа помеченных пакетов. Данный документ специфицирует кодирование, используемое LSR, для того чтобы передать помеченный пакет по каналу данных PPP и LAN. Специфицированная кодировка может быть применена и в других каналах данных.

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

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

2. Стек меток

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

Стек меток представляет собой последовательность записей. Каждая запись в стек имеет длину 4 октета. Формат такой записи показан на рис. 1.

Рис. 1. Формат записи стека меток

Запись стека меток размещается после заголовка канального уровня, и перед заголовком сетевого уровня (например, между Ethernet- и IP-заголовком). Верх стека записывается первым, а дно - последним. Сетевой заголовок следует сразу вслед за записью стека меток с битом S=1. Каждая запись стека меток содержит в себе следующие поля:

1. Дно стека (S)

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

Замечание переводчика. Следует заметить, что данный формат меток не является единственно возможным (я здесь не имею в виду ATM или FR). В IP-телефонии, например, предлагается использовать метку, которая содержит (слева-направо) код 0х8100, за которым идет 3-битовое поле приоритета (0-7) и идентификатор VPN (0-4095). Смотри журнал LANline N10, 2002, стр 140).

2. Время жизни (TTL)

Это 8-битовое поле служит для представления значения времени жизни пакета. Обработка этого поля описана в разделе 2.4.

3. Экспериментальное поле

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

4. Значение метки

Это 20-битовое поле несет в себе код метки.

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

a)     следующий шаг, куда должен быть переадресован пакет;

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

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

i.    Значение 0 представляет "IPv4 Explicit NULL Label". Это значение метки является единственно допустимым для дна стека меток. Оно указывает, что стек должен быть очищен, и переадресация пакета должна основываться на IPv4-заголовке.

ii.   Значение 1 представляет "Router Alert Label". Это значение метки является легальным в любом месте стека меток за исключением дна. Когда полученный пакет содержит такую метку на вершине стека, он доставлен локальному модулю для обработки. Действительная переадресация пакета определяется меткой, в его стеке. Однако, если пакет переадресуется дальше, еще до переадресации в стек должна быть занесена метка Router Alert. Использование этой метки сходно с применением опции "Router Alert" в IP-пакетах [5]. Так как эта метка не может лежать на дне стека, она не ассоциируется с определенным протоколом сетевого уровня.

iii.  Значение 2 представляет "IPv6 Explicit NULL Label". Это значение метки является единственно допустимым для записи на дне стека. Оно указывает, что стек должен быть очищен, а переадресация пакетов должна после этого основываться на заголовке IPv6.

iv.  Значение 3 представляет "Implicit NULL Label". Это метка, которую LSR может присваивать и рассылать, но которая в действительности никогда не используется при инкапсуляции. Когда LSR замещает метку на верху стека на новую, и эта новая метка является "Implicit NULL", LSR очистит стек вместо того, чтобы осуществить замену. Хотя это значение не может появиться при инкапсуляции, оно должно быть специфицировано в протоколе рассылки меток, так что значение может считаться зарезервированным.

v. Значения 4-15 зарезервированы.

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

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

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

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

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

 

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

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

1. Данный LSR должен быть способен определить, что конкретный помеченный пакет является IP-пакетом.

2. Данный LSR должен быть способен проложить путь до места назначения IP-пакета.

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

2.3.1. Туннелирование через транзитную область маршрутизации

Предположим, что MPLS используется для организации туннеля через транзитную область маршрутизации, где данные о внешних маршрутах не попадает к внутренним маршрутизаторам. Например, внутренние маршрутизаторы работают с протоколом OSPF, и могут только знать, как достичь объектов в пределах зоны OSPF. Домен может содержать несколько пограничных маршрутизаторов автономной системы ASBR (Autonomous System Border Routers), которые взаимодействуют друг с другом с помощью BGP. Однако в этом примере маршруты от BGP не рассылаются OSPF, и LSR, которые не являются ASBR, поддерживают BGP.

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

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

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

2.3.2. Туннелирование частных адресов через общедоступную опорную сеть

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

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

Эта технология может быть весьма полезной, если ICMP-сообщением является "Time Exceeded" (время истекло) или "Destination Unreachable because fragmentation needed and DF set" (место назначение недостижимо из-за необходимости фрагментации и DF=1).

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

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

2.4. Обработка поля времени жизни

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

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

a) входное значение TTL минус один,

b) нуль.

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

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

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

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

2.4.3.  Правила, зависящие от IP

Мы определяем поле "IP TTL" равным величине поля IPv4 TTL, или значению поля IPv6 Hop Limit, в зависимости оттого, что используется.

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

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

Признается, что могут существовать ситуации, когда сетевая администрация предпочитает декрементировать IPv4 TTL на 1 при прохождении через домен MPLS, вместо того чтобы декрементировать IPv4 TTL на число LSR в домене.

2.4.4. Преобразование различных инкапсуляций

Иногда LSR может получить помеченный пакет через, например, интерфейс ATM (LC-ATM) [9], и должен будет послать его через PPP или LAN. Тогда входной пакет будет получен без инкапсуляции, описанной в данном документе, а будет послан уже с применением такой инкапсуляции.

В этом случае значение "входное TTL" определяется процедурами обработки помеченных пакетов, например, в интерфейсе LC-ATM. Обработка TTL будет тогда происходить так, как это описано выше. Иногда LSR может получить помеченный пакет через канал PPP или LAN, и должен его послать на выход через интерфейс LC-ATM. Тогда входной пакет будет принят с использованием инкапсуляции, описанной в данном документе, а выходной пакет послан с привлечением иной инкапсуляции. В этом случае процедура формирования значения "выходного TTL" определяется процедурами, применяемыми к помеченным пакетам, например, в интерфейсах LC-ATM.

3. Фрагментация и определение MTU пути

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

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

В этом разделе специфицируются правила обработки помеченных пакетов, которые являются "слишком большими". В частности, речь идет о правилах, которые гарантируют, что ЭВМ, использующие определение MTU пути [4], и ЭВМ, работающие с IPv6 [7,8], будут способны формировать IP-дейтограммы, которые не нуждаются в фрагментации, даже если эти дейтограммы получили дополнительные метки при прохождении через сеть.

Вообще, ЭВМ IPv4, которые не используют определение MTU пути [4], посылают IP-дейтограммы, содержащие не более 576 байт. Так как большинство используемых MTU равняются 1500 байт или больше, вероятность того, что такие дейтограммы будут нуждаться в фрагментации, даже если они помечены, весьма мала.

Некоторые ЭВМ, которые не используют определение MTU пути [4], формируют IP-дейтограммы, содержащие 1500 байт. Поскольку IP-адреса отправителя и получателя в одной и той же субсети, эти дейтограммы не проходят через маршрутизаторы, и, следовательно, не будут фрагментироваться

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

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

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

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

-  Поле данных кадра:

Содержимое поля данных кадра, исключая любые заголовки и поля завершения кадра (например, MAC-заголовки, LLC-заголовки, 802.1Q-заголовки, PPP-заголовки, контрольные суммы, и т.д.).

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

-  Обычный максимальный размер поля данных кадра:

Максимальный размер поля данных кадра определяется стандартами канала данных. Например, обычный максимальный размер поля данных кадра для Ethernet равен 1500 байтов.

-  Истинный максимальный размер поля данных кадра:

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

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

-  Эффективный максимальный размер поля данных для помеченных кадров:

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

-  Первично помеченная IP-дейтограмма:

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

-  Ранее помеченная IP-дейтограмма:

IP-дейтограмма, которая уже была помечена до того, как была получена конкретным LSR.

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

Каждый LSR, который способен

a) получать непомеченные IP-дейтограммы,

b) добавлять метки в стек дейтограммы, и

c) переадресовывать полученный в результате помеченный пакет,

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

a) получена непомеченная IP-дейтограмма, и

b) эта дейтограмма имеет в заголовке бит DF=0, и

c) дейтограмма перед переадресацией должна быть помечена, и

d) размер дейтограммы (до пометки) превышает значение данного параметра, тогда

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

b)     Каждый фрагмент должен быть помечен и после этого переадресован.

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

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

Заметим, что установка этого параметра не влияет на обработку IP-дейтограмм, которые содержат бит DF=1, следовательно, установка этого параметра не влияет на результат определения MTU пути.

3.3. Когда помеченная IP-дейтограмма слишком велика?

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

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

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

3.4. Обработка помеченных дейтограмм Ipv4, которые слишком длинны

Если помеченная IPv4 дейтограмма "слишком велика", и бит DF в IP заголовке =1, тогда LSR может отбросить дейтограмму.

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

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

1. Удалить записи в стеке, чтобы получить IP-дейтограмму.

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

3. Если IP-дейтограмма содержит в IP заголовке бит "Don't Fragment" =0:

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

b.      Преобразовать каждый фрагмент, снабдив его заголовком, который имела исходная дейтограмма.

c.      Переадресовать фрагменты.

4. Если IP-дейтограмма содержит в IP заголовке бит "Don't Fragment" =1:

a.      Дейтограмма не должна переадресовываться.

b.      Сформировать ICMP-сообщение “Адресат недостижим”:

i.            Установить значение поля [3] равным "Fragmentation Required and DF Set",

ii.         Установить значение поля Next-Hop MTU [4] равным разности между эффективным максимальным размером поля данных кадра и величиной N

c.      Если возможно, послать ICMP-сообщение “Адресат недостижим” отправителю отброшенной дейтограммы.

3.5.  Обработка помеченных дейтограмм IPv6, которые слишком длинны

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

1. Удалить записи в стеке, чтобы получить IP-дейтограмму.

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

3. Если IP-дейтограмма содержит более 1280 байтов (не считая записи стека меток), или, если она не содержит заголовка фрагмента, тогда:

a.      Сформировать ICMP-сообщение “Too Big Message”, и установить значение поля Next-Hop MTU равным разности между эффективным максимальным размером поля данных кадра и величиной N.

b.      Если возможно, послать отправителю дейтограммы ICMP-сообщение “Too Big Message”.

c.      Отбросить помеченную IPv6-дейтограмму.

4. Если IP-дейтограмма не длиннее 1280 октетов, и содержит заголовок фрагмента, тогда

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

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

c.      Переадресовать фрагменты.

Восстановление сообщения из фрагментов осуществляется конечным получателем.

3.6.  Реализация с учетом определения MTU пути

Описанные выше процедуры обработки дейтограмм, которые имеют в заголовке бит DF=1, но являются "слишком большими", связаны с процедурами определения MTU пути RFC 1191 [4]. ЭВМ, которые используют эти процедуры, определят MTU, который достаточно мал, чтобы позволить занесение в дейтограмму n маркеров, без необходимости фрагментации. Здесь n равно числу меток, заносимых на используемом пути через домен.

Другими словами, дейтограммы от ЭВМ, которые используют определение MTU пути, никогда не потребуют фрагментации из-за занесения меток в заголовок. Заметим, что дейтограммы от ЭВМ, использующих определение MTU пути, имеют бит DF=1, и таким образом не могут быть фрагментированы в любом случае.

Отметим также, что определение MTU пути будет работать корректно, только если в точке, где может потребоваться фрагментация помеченной IP-дейтограммы, возможна посылка отправителю ICMP сообщения “Destination Unreachable”. Смотри раздел 2.3. Если невозможна посылка отправителю слишком большой дейтограммы ICMP-сообщения из MPLS "туннеля", но конфигурация сети предоставляет возможность LSR конца туннеля получать слишком большие пакеты, которые должны проходить через туннель, тогда:

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

-  Всякий раз, когда передающий конец туннеля должен посылать пакет в туннель, и этот пакет имеет DF=1, а его длина превышает значение MTU туннеля, передающий конец должен послать ICMP-сообщение “Destination Unreachable” узлу, приславшему пакет с кодом "Fragmentation Required and DF Set ", и полем Next-Hop MTU установленным так, как показано выше.

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

Протокол PPP (Point-to-Point Protocol) [6] предоставляет стандартный метод транспортировки многопротокольных дейтограмм через каналы точка-точка. PPP определяет расширяемый протокол управления каналом и предлагает семейство протоколов управления сетью для установления и конфигурации различных протоколов сетевого уровня.

В этом разделе определен протокол управления сетью для установления и конфигурации коммутации меток в канале PPP.

4.1.  Введение

PPP содержит три основные компонента:

1. Метод инкапсуляции мультипротокольных дейтограмм.

2. Протокол управления каналом LCP (Link Control Protocol ) установления, конфигурации и тестирования канала.

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

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

4.2.  Протокол управления PPP для MPLS

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

Протокол управления MPLS тождественен протоколу управления каналом [6] за следующими исключениями:

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

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

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

В информационное поле пакета PPP вкладывается только один пакет MPLSCP, где поле протокола PPP содержит шестнадцатеричный код 8281 (MPLS).

3. Поле кода

Используются только коды от 1 до 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack и Code-Reject). Прочие коды должны рассматриваться как нераспознанные и приводить к Code-Rejects.

4. Таймауты

Пакеты MPLSCP не могут пересылаться, пока PPP не достигнет фазы протокола сетевого уровня. Реализация должна быть готова ждать окончания аутентификации и определения качества канала, прежде чем наступит таймаут в ожидании Configure-Ack или других откликов.

4.3.  Посылка помеченных пакетов

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

В информационное поле пакета PPP вкладывается только один помеченный пакет, где поле протокола PPP содержит шестнадцатеричные значения кода тип 0281 (MPLS Unicast) или 0283 (MPLS Multicast). Максимальная длина помеченного пакета, переданного через канал PPP, та же что и максимальная длина информационного поля инкапсулированного пакета PPP.

Заметим, что определены два кода для помеченных пакетов, один для мультикастных и один для уникастных. Как только MPLSCP переходит в рабочее состояние (Opened), по каналу PPP могут посылаться как мультикаст, так и уникаст-пакеты.

5.  Пересылка помеченных пакетов в среде LAN

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

Шестнадцатеричный код Ethertype 8847 используется для индикации того, что кадр содержит уникастный MPLS-пакет. Шестнадцатеричный код Ethertype 8848 служит для указания того, что кадр содержит MPLS-пакет.

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

6.  Соображения IANA

Значения меток 0-15 включительно имеют специальное назначение, как это определено в данном документе, или как позднее будет задано IANA. В этом документе, значения меток 0-3 специфицированы в разделе 2.1. Значения меток 4-15 могут быть определены IANA, на основе согласия с IETF.

7. Соображения безопасности

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

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

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

-  Метка MPLS имеет силу в результате соглашения между LSR, который заносит метку в стек ("автор метки"), и LSR, который интерпретирует эту метку ("читатель метки"). Однако стек меток не предлагает никаких средств определения того, кто является автором конкретной метки. Если помеченные пакеты восприняты от ненадежных источников, результатом может стать то, что пакеты будут маршрутизированы незаконным образом.

8.  Библиография

[1] Rosen, E., Viswanathan, A., и R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

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

[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.

[4] Mogul, J. и S. Deering, "Path MTU Discovery", RFC 1191, November 1990.

[5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.

[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

[7] Conta, A. и S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, December 1995.

[8] McCann, J., Deering, S. и J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.

[9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. и G. Swallow, "MPLS Using LDP и ATM VC Switching", RFC 3035, January 2001.