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

5.2.3. Условия функциональной совместимости

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

  • <PulledUnconditional, RequestNever, *, *, *> и <PulledConditional, RequestNever, *, *, *>

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

  • <*, RequestNever, *, *, ReleaseOnChange>

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

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

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

  2. Если Rd не обеспечивает слияние маркеров, то он обязан выбрать одну из двух субпроцедур, либо «безусловное извлечение» (PulledUnconditional), либо «условное извлечение» (PulledConditional). Если Rd выбрал субпроцедуру «условное извлечение», то он вынужден использовать субпроцедуру «повторение запроса» (RequestRetry). Т.е., если LSRНП не поддерживает слияние маркеров, то его предпочтения являются приоритетными при выборе MPLS-схемы.

  3. Если Ru не обеспечивает слияние маркеров, а Rd обеспечивает, то Ru обязан выбрать одну из двух субпроцедур, либо «повторение запроса» (RequestRetry), либо «не повторять запрос» (RequestNoRetry). Это вынуждает Rd использовать из двух субпроцедур, либо «условное извлечение» (PulledConditional), либо «безусловное извлечение» (PulledUnconditional), соответственно. Т.е., если только один из LSR-маршрутизаторов не поддерживает слияние маркеров, то его предпочтения являются приоритетными при выборе MPLS-схемы.

  4. Если оба, Rd и Ru, реализуют процедуру слияния маркеров, выбор одного их двух режимов сохранения маркеров, свободного или консервативного режима, принадлежит Ru. Т.е., Ru предоставляется выбор использования субпроцедур, либо «RequestWhenNeeded/ReleaseOnChange» (консервативный режим), либо «RequestNever/NoReleaseOnChange» (свободный режим). Однако, право выбора «вставка» или «извлечение» и «условный» или «безусловный» принадлежит Rd. Если Ru выбирает свободный режим сохранения маркеров, то Rd может выбрать одну из двух субпроцедур, либо «безусловная вставка», либо «условная вставка». Если Ru выбирает консервативный режим сохранения маркеров, то Rd может выбрать одну из трёх субпроцедур, либо «условная вставка», либо «условное извлечение», либо «безусловное извлечение». Все вместе эти варианты выбора определяют используемую MPLS-схему.

2007 - 2018 © Русские переводы RFC, IETF, ISOC.