Передача данных с коммутацией по меткам

Вышестоящий LSR: процедура Release

Предположим, что Rd является LSR, который связывает метку с адресным префиксом X и который послал эту ассоциацию LSR Ru. Если Rd не оказался следующим шагом Ru L3 для адресного префикса X или перестал быть следующим шагом Ru L3 для адресного префикса X, Ru перестанет использовать метку. Процедура Release определяет то, как Ru работает в этом случае. Существует две возможные процедуры, управляющие поведением Ru.

ReleaseOnChange

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

NoReleaseOnChange

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

Вышестоящий LSR: процедура labelUse

Предположим, что Ru является LSR, который получил ассоциацию метки L для адресного префикса X от LSR Rd. Ru является вышестоящим по отношению к Rd с учетом X , и в действительности Rd является следующим шагом Ru L3 для X.

Ru воспользуется ассоциацией, если Rd является следующим шагом Ru L3 для X. Если в момент получения ассоциации Ru Rd не является следующим шагом Ru L3 для X, Ru не будет использовать эту ассоциацию. Ru может, однако начать использовать ассоциацию позже, если Rd станет следующим шагом Ru L3 для X. Процедура labelUse определяет, как Ru использует ассоциацию Rd. Существует две процедуры, которые может применить Ru.

UseImmediate

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

UseIfLoopNotDetected

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

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

Нижестоящий LSR: процедура отзыва

В этом случае существует только одна процедура. Когда LSR Rd решает разорвать ассоциацию между меткой L и адресным префиксом X, тогда это решение должно быть доведено до сведения всех LSR, которым эта ассоциация была прислана. Требуется, чтобы уведомление о разрыве ассоциации между L и X было послано Rd в LSR Ru, прежде чем Rd пришлет Ru какие-либо иные ассоциации L с какими-либо префиксами Y, где X != Y. Если Ru узнал о новой ассоциации L и Y, до того как получил данные о разрыве ассоциации L и X, и если пакеты, соответствующие префиксам X и Y, переадресуются из Ru в Rd, тогда в течение некоторого времени Ru будет помечать пакеты, относящиеся к X и к Y, меткой L.

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

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

Схемы MPLS: поддерживаемые комбинации процедур

Рассмотрим два LSR, Ru и Rd, которые являются партнерами рассылки меток для некоторого набора адресных префиксов, где Ru является вышестоящим партнером, а Rd — нижестоящим.

Схема MPLS, которая управляет взаимодействием Ru и Rd, может быть описана с помощью пяти процедур: <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. Так как существует только одна процедура отзыва, она здесь не упоминается. Появление "*" в одной из позиций в качестве подмены означает, что в данной категории возможна любая процедура; появление N/A в некоторой позиции указывает, что не нужна никакая процедура данной категории.

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

Схемы для LSR, которые поддерживают объединение меток

Если Ru и Rd являются партнерами по рассылке меток, и оба поддерживают объединение меток, должна использоваться одна из следующих схем.

1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate >

   Это не затребованная рассылка меток вниз по течению с независимым управлением, свободным режимом удержания меток и без детектирования маршрутных петель.
2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>

   Это не затребованная рассылка меток вниз по течению с независимым управлением, свободным режимом удержания меток и детектированием петель.
3. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange,*>

   Это не затребованная рассылка меток вниз по течению с упорядоченным управлением (со стороны конца маршрута) и консервативным режимом удержанием меток. Детектирование петель опционно.
4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>

   Это не затребованная рассылка меток вниз по течению с упорядоченным управлением (со стороны конца маршрута) и свободным режимом удержанием меток. Детектирование петель опционно.
5. <PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>

   Это рассылка меток вниз по течению по запросу (downstreamondemand) с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием петель.
6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate>

   Это рассылка меток вниз по течению по запросу с независимым управлением, консервативным режимом удержания меток и без детектирования петель.
7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected>

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

Схемы для LSR, которые не поддерживают объединение меток

Предположим, что R1, R2, R3 и R4 являются ATM-коммутаторами, которые не поддерживают объединение меток, но используются в качестве LSR. Предположим далее, что маршрут L3 шаг-за-шагом для адресного префикса X имеет вид <R1, R2, R 3, R4> и что пакеты, адресованные X, могут войти в сеть через любой из этих LSR. Так как здесь нет возможности реализовать схему мультиточка-точка, LSP должны быть реализованы как VC точка-точка, что означает необходимость трех таких VC для адресного префикса X: <R1, R2, R3, R4>, <R2, R3, R4> и <R3, R4>.

Следовательно, если R1 и R2 являются MPLS-партнерами и любой из них является LSR, который реализован с использованием обычного коммутирующего оборудования ATM (т.e., без подавления перекрытия ячеек) или по какой-то иной причине не способен осуществлять объединение меток, то используемая схема MPLS между R1 и R 2 должна быть одной из перечисленных ниже.

1. <PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>

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

   Использование процедуры RequestOnRequest вынудит R4 послать R3 три метки для X ; R3 пошлет К2 2 метки для X, а R2 пошлет одну метку R1 для X.
2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate>

   Это рассылка меток вниз по течению по запросу с независимым управлением, консервативным режимом удержания меток и без детектирования петель.
3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>

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

Соображения совместимости

Легко видеть, что некоторые пятерки не образуют жизнеспособных схем MPLS. Например:

<PulledUnconditional, RequestNever, *, *, *>

<PulledConditional, RequestNever, *, *, *>

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

<*, RequestNever, *, *, ReleaseOnChange>

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

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

1. Каждый субъект должен объявить, поддерживает ли он объединение меток.
2. Если Rd не поддерживает объединение меток, он должен выбрать либо процедуру PulledUnconditional, либо PulledConditional. Если Rd выбирает PulledConditional, Ru вынужден использовать процедуру RequestRetry.

   То есть, если нижестоящий LSR не поддерживает объединения меток, его предпочтения имеют приоритет при выборе схемы MPLS.
3. Если Ru не поддерживает объединение меток, а Rd поддерживает, Ru должен выбрать процедуру RequestRetry или RequestNoRetry. Это вынуждает Rd использовать соответственно процедуру PulledConditional или PulledUnConditional.

   То есть, если только один из LSR не поддерживает объединение меток, его предпочтения имеют приоритет при выборе схем MPLS.
4. Если как Ru, так и Rd поддерживают объединение меток, тогда выбор между свободным и консервативным режимами удержания меток остается за Ru. То есть, Ru предоставляется выбрать либо RequestWhenNeeded/ReleaseOnChange (консервативный), либо RequestNever/NoReleaseOnChange (свободный). Однако выбор push либо pull и условного либо безусловногой алгоритма работы с метками принадлежит Rd. Если Ru выбирает свободный режим удержания меток, Rd может выбрать либо PushUnconditional, либо PushConditional. Если Ru выбирает консервативный режим удержания меток, Rd может выбрать PushConditional, PulledConditional или PulledUnconditional.

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

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

11.5. Кодирование меток в MPLS

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

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

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

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

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

Запись стека меток размещается после заголовка канального уровня, и перед заголовком сетевого уровня (например, между 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-битовое поле определяет время жизни пакета.
3. Значение метки

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

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

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

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

1. Значение 0 представляет IPv4 Explicit NULL Label. Это значение метки является единственно допустимым для дна стека меток. Оно указывает, что стек должен быть очищен и переадресация пакета должна основываться на IPv4-заголовке.
2. Значение 1 представляет Router Alert Label. Это значение метки является легальным в любом месте стека меток за исключением дна. Когда полученный пакет содержит такую метку на вершине стека, он доставлен локальному модулю для обработки. Действительная переадресация пакета определяется меткой в его стеке. Однако, если пакет переадресуется дальше, еще до переадресации в стек должна быть занесена метка Router Alert. Использование этой метки сходно с применением опции Router Alert в IP-пакетах [11.5]. Так как эта метка не может лежать на дне стека, она не ассоциируется с определенным протоколом сетевого уровня.
3. Значение 2 представляет собой IPv6 Explicit NULL Label. Это значение метки является единственно допустимым для записи на дне стека. Оно указывает, что стек должен быть очищен, а переадресация пакетов должна после этого основываться на заголовке IPv6.
4. Значение 3 представляет Implicit NULL Label. Это метка, которую LSR может присваивать и рассылать, но которая в действительности никогда не используется при инкапсуляции. Когда LSR замещает метку на верху стека на новую и эта новая метка является Implicit NULL, LSR очистит стек вместо того, чтобы осуществить замену. Хотя это значение не может появиться при инкапсуляции, оно должно быть специфицировано в протоколе рассылки меток, так что значение может считаться зарезервированным.
5. Значения 4-15 зарезервированы на будущее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В некоторых случаях, когда 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-сообщений, проблем это создать не должно.

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

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

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

b) нуль.

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

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

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

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