Geum.ru

Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача

Вид материалаЗадача

Содержание


2.  Основы MPLS
Подобный материал:
1   ...   38   39   40   41   42   43   44   45   ...   59
2.  Основы MPLS

В этом разделе, вводятся некоторые базовые концепции MPLS, и описывается используемый общий подход.
2.1.  Метки

Метка является коротким идентификатором фиксированной длины, который используется для идентификации FEC. Метка, которая вложена в определенный пакет, представляет класс переадресации FEC (Forwarding Equivalence Class), к которому данный пакет приписан. Обобщая, можно сказать, что пакет приписан FEC, базирующемуся частично или целиком на его адресе места назначения сетевого уровня. Однако кодировка метки никогда не совпадает c этим адресом.

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

Заметим, что L не обязательно представляет FEC F для любого пакета, посланного не Ru и адресованного не Rd. L имеет произвольное значение, чья связь F с Ru и Rd является локальной.

Когда говорится, что пакеты посланы из Ru в Rd, это не означает, что пакеты сформированы в Ru или, что местом назначения является Rd. Скорее, мы подразумеваем, что пересылаемые пакеты поступают в один или оба LSR.

Иногда может оказаться трудно или даже невозможно для Rd сообщить о прибывающих пакетах с меткой L, помещенной в пакет Ru, а не каким-то другим LSR. (Это обычно происходит, когда Ru и Rd не являются соседями). В таких случаях Rd должен убедиться, что имеет место соответствие межу меткой и FEC. То есть, Rd не должен соглашаться на ассоциацию L и FEC F1, в то время как с другим LSR Ru2 согласовано соответствие L с другим FEC F2, если только Rd не может при получении пакетов с меткой L всегда оповещать, вложена ли в пакет метка Ru1 или Ru2. Гарантия однозначной интерпретации меток находится в зоне ответственности LSR.
2.2.  Вышестоящие и нижестоящие LSR

Предположим, что Ru и Rd договорились о соответствии метки L и FEC F, для пакетов, посланных из Ru в Rd. Тогда с учетом этого соответствия, Ru является "вышестоящим LSR", а Rd является "нижестоящим LSR".

Узел является вышестоящим, а другой нижестоящим с учетом того, что в данной ассоциации (метки и класса) метка представляет определенный FEC для пакетов, транспортируемых от вышестоящего узла к нижестоящему. Это, вообще говоря, не означает, что пакеты в этом FEC будут действительно маршрутизированы от вышестоящего узла нижестоящему.
2.3.  Помеченные пакеты

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

Метод кодирования метки должен быть согласован субъектом, ее формирующим и субъектом адресатом.

2.4.  Присвоение меток и рассылка

В архитектуре MPLS, решение об установлении соответствия конкретной метки L и класса FEC F принимается LSR, который является нижестоящим по отношению к этой ассоциации. Нижестоящий LSR информирует вышестоящий LSR об установлении этой ассоциации. Таким образом, метки присваиваются нижестоящим объектом и рассылаются "снизу-вверх".

Если LSR сконструирован так, чтобы анализировать метки и проверять их принадлежность определенному числовому диапазону, тогда нужно лишь позаботиться, чтобы значения меток действительно лежали в этом диапазоне.
2.5.  Атрибуты ассоциации меток (Label Binding)

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

Протокол рассылки меток представляет собой набор процедур, с помощью которых один LSR информирует другие об ассоциациях метка/FEC, которые он сформировал. Два LSR, которые используют протокол рассылки меток для обмена данными об ассоциациях метка/FEC, называются "партнерами рассылки меток". Если два LSR являются партнерами по рассылки меток, мы будем говорить о смежности рассылки меток между ними.

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

Архитектура не предполагает, что должен существовать только один протокол рассылки меток. В действительности, стандартизовано несколько протоколов рассылки меток. Существующие протоколы расширены так, чтобы рассылка меток можно было совместить друг с другом (смотри, например, [MPLS-BGP], [MPLS-RSVP-TUNNELS]). Определены новые протоколы специально для целей рассылки меток (смотри, например, [MPLS-LDP], [MPLS-CR-LDP]).

В данном документе, мы пытаемся использовать акроним "LDP" для ссылок на протокол, определенный в [MPLS-DP].
2.7.  Unsolicited Downstream против Downstream-on-Demand

Архитектура MPLS позволяет LSR непосредственно посылать запросы узлу следующего шага относительно конкретного FEC, и ассоциации метка-FEC. Это называется рассылкой меток по схеме "запрос нижележащего" (downstream-on-demand).

Архитектура MPLS позволяет также LSR посылать ассоциации другим LSR, которые напрямую эти данные не запрашивали. Такой обмен называется рассылкой меток нижележащим без запроса (unsolicited downstream).

Ожидается, что некоторые реализации MPLS будут осуществлять рассылку меток только в режиме downstream-on-demand, другие – только в режиме unsolicited downstream, а некоторые - в обоих режимах. Какой из режимов будет реализован, зависит от характеристик интерфейсов, которые поддерживает конкретная реализация. Однако обе эти схемы рассылки меток могут использоваться в некоторых сетях одновременно. В любом конкретном случае вышестоящий и нижестоящий LSR должны согласовать, какая из схем рассылки будет применена.