RFC 4724 Graceful Restart Mechanism for BGP

Network Working Group                                          S. Sangli
Request for Comments: 4724                                       E. Chen
Category: Standards Track                                  Cisco Systems
                                                             R. Fernando
                                                              J. Scudder
                                                              Y. Rekhter
                                                        Juniper Networks
                                                            January 2007

Graceful Restart Mechanism for BGP

Механизм аккуратного перезапуска для BGP

PDF

Статус документа

В этом документе приведена спецификация проекта стандартного протокола Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущий статус стандартизации протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.

Авторские права

Copyright (C) The IETF Trust (2007).

Тезисы

Этот документ описывает механизм для BGP который поможет минимизировать негативное влияние перезапуска BGP на маршрутизацию. Задан маркер End-of-RIB, который может применяться для передачи информации о схождении маршрутов. Определена новая возможность BGP — Graceful Restart Capability, позволяющая узлу BGP указать свою способность сохранять состояние пересылки при перезапуске BGP. Кроме того, очерчены процедуры для временного сохранения маршрутной информации при разрыве и повторной организации сессии TCP.

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

Оглавление

Исключено в версии HTML

1. Введение

Обычно при перезапуске маршрутизатора BGP все его партнеры BGP видят разрыв и последующее восстановление сессии. Такой переход «вкл. — выкл.» приводит к перебою маршрутизации (routing flap) и вызывает пересчет маршрутов BGP, генерацию маршрутных обновлений BGP и ненужные сбои в таблицах пересылки, которые могут охватывать множество доменов маршрутизации. Такие перебои в маршрутизации могут создавать временные «черные дыры» и петли в маршрутизации. Кроме того, это ведет к расходу ресурсов на уровне управления затронутых перебоем маршрутизаторов. В результате снижается общая производительность сети.

В этом документе описан механизм для BGP, который поможет минимизировать негативное влияние перезапуска BGP на маршрутизацию. Задан маркер End-of-RIB, который может служить для передачи информации о схождении маршрутов. Определена новая возможность BGP — Graceful Restart Capability, позволяющая узлу BGP указать свою способность сохранять состояние пересылки в процессе перезапуска BGP. Кроме того, очерчены процедуры для временного сохранения маршрутной информации при разрыве и повторной организации сессии TCP.

1.1 Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [RFC2119].

2. Маркер для End-of-RIB

Сообщение UPDATE без доступных NLRI1 и с пустым NLRI отзыва задано в качестве маркера End-of-RIB2, который может использоваться узлом BGP для индикации его партнеру завершения начального обновления маршрутов после организации сессии. Для семейства индивидуальных адресов IPv4 маркер End-of-RIB является сообщением UPDATE с минимальным размером [BGP-4]. Для других семейств адресов это будет сообщение UPDATE, содержащее лишь атрибут MP_UNREACH_NLRI [BGP-MP] без отзываемых маршрутов для данной пары <AFI, SAFI>.

Хотя маркер End-of-RIB задан для «аккуратного перезапуска» BGP, отмечено, что генерация такого маркера при завершении начального обновления будет полезна для схождения маршрутов в общем случае, поэтому такая практика рекомендуется.

Кроме того, для схождения маршрутов было бы лучше, если бы узел BGP мог заранее указать своему партнеру, что он будет генерировать маркер End-of-RIB, независимо от способности сохранять свое состояние пересылки при перезапуске BGP. Это может быть достигнуто с помощью возможности Graceful Restart Capability, описанной ниже.

3. Возможность аккуратного перезапуска

Graceful Restart Capability является новой возможностью BGP [BGP-CAP], которая позволяет узлу BGP указать свою способность сохранять состояние пересылки при перезапуске BGP. Она может применяться также для передачи партнеру своего намерения создавать маркер End-of-RIB при завершении начального обновления маршрутов.

Определение возможности приведено ниже.

Capability code

64

Capability length

переменная

Capability value

Поля Restart Flags и Restart Time, а также от 0 до 63 блоков <AFI, SAFI, Flags for address family>, как показано ниже.


+--------------------------------------------------+
| Restart Flags (4 бита)                           |
+--------------------------------------------------+
| Restart Time in seconds (12 битов)               |
+--------------------------------------------------+
| Address Family Identifier (16 битов)             |
+--------------------------------------------------+
| Subsequent Address Family Identifier (8 битов)   |
+--------------------------------------------------+
| Flags for Address Family (8 битов)               |
+--------------------------------------------------+
| ...                                              |
+--------------------------------------------------+
| Address Family Identifier (16 битов)             |
+--------------------------------------------------+
| Subsequent Address Family Identifier (8 битов)   |
+--------------------------------------------------+
| Flags for Address Family (8 битов)               |
+--------------------------------------------------+

Ниже описаны поля значения Capability.

Restart Flags

Это поле содержит флаги, относящиеся к перезапуску.

 0 1 2 3
+-+-+-+-+
|R|Resv.|
+-+-+-+-+

Старший бит определен как флаг перезапуска (Restart State — R), который может применяться для предотвращения возможного «зависания», вызванного ожиданием маркера End-of-RIB при перезапуске множества связанных между собой узлов BGP. Установленный (1) флаг указывает, что узел BGP был перезапущен и его партнерам недопустимо ждать маркера End-of-RIB перед анонсированием узлу маршрутной информации.

Оставшиеся биты являются резервными и должны сбрасываться (0) при передаче и игнорироваться на приеме.

Restart Time

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

Address Family Identifier (AFI), Subsequent Address Family Identifier (SAFI)

Комбинация AFI и SAFI указывает, что Graceful Restart поддерживается для маршрутов с данными семействами адресов. Маршруты можно связать с определенными AFI и SAFI явно путем кодирования [BGP-MP] или неявно указать <AFI=IPv4, SAFI=Unicast> путем кодирования [BGP-4].

Flags for Address Family

Это поле содержит флаги, относящиеся к маршрутами, которые будут анонсироваться с данными AFI и SAFI.


 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|   Reserved  |
+-+-+-+-+-+-+-+-+

Старший бит определен в качестве флага состояния пересылки (Forwarding State — F), который позволяет указать, сохранено ли состояние пересылки для маршрутов, анонсированных с указанными AFI и SAFI, при предшествующем перезапуске BGP. Установленное (1) значение говорит о сохранении состояния пересылки.

Оставшиеся биты являются резервными и должны сбрасываться (0) при передаче и игнорироваться на приеме.

Когда отправитель этой возможности не включает в анонс <AFI, SAFI>, это означает, что он не может сохранить состояние пересылки в при перезапуске BGP, но поддерживает процедуры, определенные в параграфе 4.2. В таких случаях указанное отправителем значение Restart Time не имеет реального смысла.

Узлу BGP недопустимо включать более одного экземпляра Graceful Restart Capability в свой анонс возможностей [BGP-CAP]. При наличии нескольких экземпляров Graceful Restart Capability в анонсе принимающая сторона должна игнорировать все экземпляры Graceful Restart Capability, кроме последнего.

Включение <AFI=IPv4, SAFI=unicast> в Graceful Restart Capability не подразумевает, что маршрутные данные для индивидуальных адресов IPv4 следует передавать с использованием расширений [BGP-MP] — она может передаваться в поле NLRI сообщения BGP UPDATE.

4. Операции

Узел BGP может анонсировать Graceful Restart Capability для семейства адресов своему партнеру, если он может сохранять свое состояние пересылки для этого семейства адресов при перезапуске BGP. Но даже при неспособности узла сохранить состояние пересылки при перезапуске BGP ему рекомендуется анонсировать своему партнеру Graceful Restart Capability без включения в нее <AFI, SAFI>. Для этого имеются две причины. Во-первых, это показывает намерение узла генерировать маркер End-of-RIB при завершении начального обновления маршрутов, что в общем случае полезно для схождения маршрутов. Во-вторых, это указывает поддержку партнеров, которые хотят использовать «аккуратный перезапуск» (graceful restart).

Маркер End-of-RIB должен передаваться узлом BGP его партнеру после завершения начального обновления маршрутов (включая случай отсутствия обновлений) для семейства адресов после организации сессии BGP.

Следует отметить, что при разрыве сессии TCP в результате приема или передачи сообщения BGP NOTIFICATION должны выполняться обычные процедуры BGP.

Предлагается использовать по умолчанию значение Restart Time, не превышающее HOLDTIME из сообщения OPEN.

Далее «перезапускаемым узлом» (Restarting Speaker) называется узел, на котором перезапускается BGP, а «принимающим узлом» (Receiving Speaker) называется партнер перезапускающегося узла.

Следует помнить, что Graceful Restart Capability для семейства адресов анонсируется перезапускаемым узлом и воспринимается принимающим узлом, а между этими узлами имеется сессия BGP. Ниже подробно рассматриваются процедуры, которым должны следовать перезапускаемые и принимающий узел после начала перезапуска.

4.1. Процедуры для перезапускаемого узла

При перезапуске Restarting Speaker должен (по возможности) сохранить состояние пересылки для маршрутов BGP в Loc-RIB и должен отметить его как «замороженное» (stale). Во время пересылки недопустимо отличать «замороженную» информацию от остальной.

Для восстановления сессии с партнером перезапускаемый узел должен установить бит Restart State в Graceful Restart Capability сообщения OPEN. Пока это не разрешено конфигурацией, бит Forwarding State для семейства адресов может устанавливаться лишь в случаях, когда состояние пересылки реально сохранено при перезапуске.

После восстановления сессии Restarting Speaker будет получать и обрабатывать сообщения BGP от своих партнеров. Однако он должен отложить выбор маршрутов для семейства адресов, пока (a) не получит маркеры End-of-RIB от всех партнеров (исключая установивших бит Restart State в переданной возможности и не передавших возможность аккуратного перезапуска) или (b) не завершится отсчет таймера Selection_Deferral_Timer (см. ниже). Следует отметить, что до выбора маршрутов узел не будет иметь маршрутов для анонсирования своим партнерам и обновления состояния пересылки.

При одновременном перезапуске IGP3 и BGP может быть полезно дождаться схождения IGP перед выбором маршрутов BGP.

После выбора маршрутов узлом BGP состояние пересылки узла должно быть обновлено и вся «замороженная» ранее информация должна быть удалена. После этого можно анонсировать партнерам Adj-RIB-Out. По завершении начального обновления для семейства адресов (включая отсутствие обновлений) должен передаваться маркер End-of-RIB.

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

Если хочется применять Graceful Restart только при запланированном перезапуске (а не при каждом), одним из способов является установка бита Forwarding State (1) после запланированного перезапуска и сбров (0) в иных случаях. Другие варианты решения этой задачи выходят за рамки документа.

4.2. Процедуры для принимающего узла

При перезапуске Restarting Speaker принимающий узел не всегда может определить разрыв сессии TCP с перезапускаемым узлом. Это зависит от реализации TCP, использования [BGP-AUTH] и конкретных условий перезапуска. Если разрыв сессии TCP не обнаружен, узел должен считать последующую попытку организации сессии указанием разрыва прежней сессии TCP и действовать подобающим образом (при получении Graceful Restart Capability от партнера). Описание поведения в терминах машины конечных состояний дано в разделе 54.

«Подобающие действия» в этом контексте означают, что узел должен закрыть прежнюю сессию TCP и сохранить новую. Отметим, что это поведение отличается от принятого по умолчанию в параграфе 6.8 [BGP-4]. Поскольку прежнее соединение считается разорванным, передавать сообщение NOTIFICATION не следует — просто закрывается сессия TCP.

Когда Receiving Speaker обнаруживает разрыв соединения TCP для сессии BGP с партнером, анонсировавшим Graceful Restart Capability, он должен сохранить полученные от партнера маршруты для всех семейств адресов, которые были получены в Graceful Restart Capability, и должен пометить их как «замороженные». При обработке последующих перезапусков маршруты (от партнера), помеченные ранее как «замороженные», должны быть удалены. Маршрутизатору недопустимо при пересылке отличать «замороженную» маршрутную информацию от другой.

В восстановленной сессии принимающему узлу недопустимо устанавливать бит Restart State возможности Graceful Restart Capability в сообщении OPEN, если сам этот узел не перезапускался. Наличие и значение бита Forwarding State для семейства адресов зависит от реального состояния пересылки и конфигурации.

Если сессия не была восстановлена с течение интервала Restart Time, ранее анонсированного пратнером, принимающий узел должен удалить все «замороженные» маршруты от этого партнера.

Узел BGP может иметь тот или иной способ проверки жизнеспособности состояния пересылки своего партнера, например с помощью [BFD]5 или данных мониторинга на канальном уровне. Детали таких механизмов выходят за рамки этого документа. Если нежизнеспособность состояния пересылки партнера будет определена до восстановления сессии, узел может удалить все «замороженные» маршруты от этого партнера.

Если после восстановления сессии бит Forwarding State для конкретного семейства адресов не установлен во вновь полученной возможности Graceful Restart Capability, конкретное семейство адресов не включено в Graceful Restart Capability или сама эта возможность не получена в восстановленной сессии, Receiving Speaker должен незамедлительно удалить все «замороженные» маршруты от партнера для этого семейства адресов.

Принимающий узел должен передать своему партнеру маркер End-of-RIB по завершении начального обновления для семейства адресов (включая отсутствие обновлений).

Принимающий узел должен заменить «замороженные» маршруты полученными от партнера обновлениями. После получения от партнера маркера End-of-RIB для семейства адресов принимающий узел должен незамедлительно удалить все маршруты от партнера, помеченные как «замороженные» для семейства адресов.

Для установки верхней границы времени сохранения «замороженных» маршрутов реализация может поддерживать (настраиваемый) таймер.

5. Изменения в машине состояний BGP

Как отмечено в параграфе «4.2. Процедуры для принимающего узла», этот документ меняет машину состояний BGP.

Конкретные изменения, вносимые в параграф 8.2.2 [BGP-4] приведены ниже.

Состояние Idle

Текст:

  • инициализировать все ресурсы BGP для соединения с партнером;

Заменяется текстом:

  • инициализировать все ресурсы BGP для соединения с партнером, кроме ресурсов, требуемых для сохранения маршрутов в соответствии с параграфом «4.2. Процедуры для принимающего узла» данного документа;

Состояние Established

Текст:

В ответ на индикацию завершения организации соединения TCP (Событие 16 или 17) следует отслеживать второе соединение, пока не будет передано сообщение OPEN.

Заменяется текстом:

Если возможность Graceful Restart Capability с одним или несколькими AFI/SAFI не была получена для этой сессии, в ответ на индикацию завершения организации соединения TCP (Событие 16 или 17) нужно отслеживать второе соединение, пока не будет передано сообщение OPEN.

Однако если в сессии была получена возможность Graceful Restart Capability с одним или несколькими AFI/SAFI, в этвет на событие 16 или 17 локальная система будет:

  • сохранять все маршруты, связанные с соединением, в соответствии с параграфом «4.2. Процедуры для принимающего узла» данного документа;

  • освобождать все остальные ресурсы BGP;

  • сбрасывать соединение TCP, связанное с организованной (ESTABLISHED) сессией,

  • инициализировать все ресурсы BGP для соединения с партнером, кроме ресурсов, требуемых для сохранения маршрутов в соответствии с параграфом «4.2. Процедуры для принимающего узла» данного документа;

  • устанавливать ConnectRetryTimer = 0;

  • запускать таймер ConnectRetryTimer с начальным значением;

  • переходить в состояние Connect.

Текст:

Если локальная система получает сообщение NOTIFICATION (Событие 24 или 25) или сигнал TcpConnectionFails (Событие 18) от нижележащего уровня TCP, она будет:

  • устанавливать ConnectRetryTimer = 0;

  • удалять все маршруты, связанные с соединением;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • переходить в состояние Idle.

Заменяется текстом:

Если локальная система получает сообщение NOTIFICATION (Событие 24 или 25) или сигнал TcpConnectionFails (Событие 18) от нижележащего уровня TCP, а возможность Graceful Restart с одним или множеством AFI/SAFI не была получена в этой сессии, локальная система будет:

  • устанавливать ConnectRetryTimer = 0;

  • удалять все маршруты, связанные с соединением;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • переходить в состояние Idle.

Однако если локальная система получает TcpConnectionFails (Событие 18) от нижележащего TCP и возможность Graceful Restart Capability с одним или несколькими AFI/SAFI была получена в этой сессии, локальная система будет:

  • устанавливать ConnectRetryTimer = 0;

  • сохранять все маршруты, связанные с соединением, в соответствии с параграфом «4.2. Процедуры для принимающего узла» данного документа;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • переходить в состояние Idle.

6. Вопросы развертывания

Хотя описанные здесь процедуры помогают минимизировать влияние маршрутных перебоев, отмечено, что при перезапуске маршрутизатора, поддерживающего BGP Graceful Restart или при перезапуске без сохранения состояния пересылки (например, при сбое питания) возможны временные маршрутные петли или «черные дыры» в сети, если маршрутные данные меняются до того, как вовлеченные маршрутизаторы завершат обновление или схождение маршрутов. Если не все маршрутизаторы IBGP поддерживают Graceful Restart, в зависимости от топологии может увеличиваться вероятность возникновения петель и «черных дыр» при выполнении процедуры Graceful Restart.

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

В заключение следует отметить, что преимущества развертывания BGP Graceful Restart в автономной системе, где протоколы IGP и BGP тесно связаны (т. е. будут перезапускаться совместно), а IGP не имет возможности, подобной Graceful Restart Capability, снижаются по сравнению с ситуацией, где IGP имеют похожую возможность.

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

Поскольку при использовании этого предложения новое соединение может вызывать разрыв имеющегося, это может «открыть дверь» для атак на отказ служб. Однако уже отмечено, что протокол BGP без проверки подлинности уязвим для атак на службы через атаки на транспорт TCP. Обычно транспорт TCP защищают с помощью [BGP-AUTH]. Такая проверка подлинности будет защищать и от атак на службы путем организации ложных новых соединений.

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

Таким образом, можно считать, что данное предложение не меняет базовую модель (и имеющиеся проблемы) безопасности BGP-4.

Отметим также, что реализации могут использовать управление аккуратным перезапуском через настройку конфигурации. Если аккуратный перезапуск не разрешен, базовая модель безопасности BGP-4 не меняется.

8. Благодарности

Авторы благодарны Bruce Cole, Lars Eggert, Bill Fenner, Eric Gray, Jeffrey Haas, Sam Hartman, Alvaro Retana, Pekka Savola Naiming Shen, Satinder Singh, Mark Townsley, David Ward, Shane Wright и Alex Zinin за рецензии и замечания.

9. Взаимодействие с IANA

Этот документ определяет новую возможность BGP — Graceful Restart Capability, для которой выделен код 64.

10. Литература

10.1. Нормативные документы

[BGP-4] Rekhter, Y., Li, T., and S. Hares, «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, «Multiprotocol Extensions for BGP-4», RFC 2858, June 2000.

[BGP-CAP] Chandra, R. and J. Scudder, «Capabilities Advertisement with BGP-4», RFC 3392, November 2002.

[BGP-AUTH] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

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

[IANA-AFI] http://www.iana.org/assignments/address-family-numbers

[IANA-SAFI] http://www.iana.org/assignments/safi-namespace

10.2. Дополнительная литература

[BFD] Katz, D. and D. Ward, «Bidirectional Forwarding Detection», Work in Progress6.

Адреса авторов

Srihari R. Sangli

Cisco Systems, Inc.

EMail: rsrihari@cisco.com

Yakov Rekhter

Juniper Networks, Inc.

EMail: yakov@juniper.net

Rex Fernando

Juniper Networks, Inc.

EMail: rex@juniper.net

John G. Scudder

Juniper Networks, Inc.

EMail: jgs@juniper.net

Enke Chen

Cisco Systems, Inc.

EMail: enkechen@cisco.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспеченоInternet Society.

1Network Layer Reachability Information — информация о доступности на сетевом уровне.

2Конец базы маршрутной информации (RIB).

3Interior Gateway Protocol — протокол внутреннего шлюза (маршрутизации).

4В оригинале ошибочно указан раздел 8, см. https://www.rfc-editor.org/errata/eid4193. Прим. перев.

5Bidirectional Forwarding Detection — обнаружение двухсторонней пересылки.

6Опубликовано в RFC 5880. Прим. перев.




RFC 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling

Network Working Group                                   K. Kompella, Ed.
Request for Comments: 4761                               Y. Rekhter, Ed.
Category: Standards Track                               Juniper Networks
                                                            January 2007

Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling

VPLS с использованием BGP для автоматического обнаружения и сигнализации

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The IETF Trust (2007).

Замечание IESG

Рабочая группа L2VPN создала два отдельных документа — RFC 4762 и этот документ, в которых реализованы похожие функции на основе разных протоколов сигнализации. Отметим, что оба метода обычно называют VPLS, хотя они отличаются и не совместимы друг с другом.

Тезисы

Услуги VPLS1, называемые также TLS2 и VPSN3, являются полезными предложениями сервис-провайдеров (SP4). Этот сервис предоставляет виртуальную частную сеть (VPN5) L2, однако в случае VPLS пользователи VPN соединяются через «многоточечную» (multipoint) ЛВС Ethernet в отличие от обычных L2 VPN с соединениями «точка-точка».

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

Оглавление

Исключено в версии HTML.

1. Введение

Услуги VPLS, называемые также TLS и VPSN, являются полезными предложениями сервис-провайдеров (SP). Виртуальные частные ЛВС (почти) во всех отношениях проявляются для абонентов SP как обычные Ethernet ЛВС. Однако в VPLS абоненты реально не подключены к одной ЛВС и могут быть соединены через городскую или распределенную сеть. По сути, VPLS «склеивает» отдельные ЛВС через сеть с коммутацией пакетов так, что они представляются и функционируют как единая ЛВС [9]. Это обеспечивается за счет встраивания функций обучения, лавинной рассылки и пересылки кадров в контекст псевдопроводов, соединяющих отдельные ЛВС через сеть с коммутацией пакетов.

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

Другие варианты организации сервиса включают [14], где можно создавать L2 VPN с использованием Ethernet для соединения сетей и [13], где можно организовывать соединения Ethernet через сеть с коммутацией пакетов. Однако оба эти варианта предлагают услуги Ethernet «точка-точка». VPLS отличается от них предоставлением многоточечного обслуживания. Механизм организации псевдопроводов для VPLS с использованием протокола распространения меток LDP6 определен в [10].

1.1. Область действия документа

Этот документ состоит из 4 основных частей, определяющих функциональную модель VPLS, уровень управления для организации VPLS, уровень данных для VPLS (инкапсуляция и пересылка данных) и варианты развертывания.

Функциональная модель базового сервиса VPLS очерчена в разделе 2. Здесь описаны предлагаемые услуги, компоненты, взаимодействующие для организации сервиса, и верхний уровень таких взаимодействий.

Описываемый в документе уровень управления использует расширение Multiprotocol BGP [4] для организации сервиса VPLS, т. е. автоматического обнаружения членов VPLS, а также организации и разрыва псевдопроводов, создающих данный экземпляр VPLS. Кроме того, в разделе 3 описана организация VPLS через границы автономных систем (AS7), а также обслуживание многодомных компонент. Использование BGP для уровня управления VPN не ново (см. [14], [6], [11]) и приведенное здесь описание базируется на механизмах, предложенных в работе [6].

Уровень пересылки и действия краевых маршрутизаторов провайдера (PE8), предлагающих услуги VPLS, описаны в разделе 4.

В разделе 5 определено понятие «отвязанной» операции, а также взаимодействия отвязанных и неотвязанных PE. Отвязывание повышает уровень гибкости при развертывании VPLS.

1.2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [1].

2. Функциональная модель

                                                   -----
                                                  /  A1 \
    ----                                     ____CE1     |
   /    \          --------       --------  /    |       |
  |  A2 CE2-      /        \     /        PE1     \     /
   \    /   \    /          \___/          | \     -----
    ----     ---PE2                        |  \
                |                          |   \   -----
                |  Сеть сервис-провайдера  |    \ /     \
                |                          |     CE5  A5 |
                |            ___           |   /  \     /
         |----|  \          /   \         PE4_/    -----
         |u-PE|--PE3       /     \       /
         |----|    --------       -------
  ----  /   |    ----
 /    \/    \   /    \        CE = краевое устройство абонента
|  A3 CE3    --CE4 A4 |       PE = краевой маршрутизатор провайдера
 \    /         \    /        u-PE = агрегирование L2
  ----           ----         A<n> = абонентский сайт n

Рисунок 1. Пример VPLS.


Описываемая модель графически представлена на рисунке 1.

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

Терминология похожа на используемую в [6] — сеть сервис-провайдера (SP) с внутренними (P9) и граничными (PE) маршрутизаторами, а также абонентскими краевыми устройствами (CE10). Однако здесь используется дополнительная концепция — u-PE — устройство L2 PE, используемое для агрегирования на канальном уровне (L2), которое описано в разделе 5. Устройства PE и u-PE знают о VPLS (VPLS-aware), т. е. им известно о предлагаемом сервисе VPLS. Термин VE обозначает краевое устройство VPLS, которым может служить PE или u-PE.

Устройства CE (которые могут принадлежать SP или абоненту и управляться им), напротив, ничего не знают о VPLS. CE соединяются с другими CE в рамках VPLS через коммутируемую сеть L2. Это означает, что CE не требуют внесения программных или аппаратных изменений для поддержки VPLS.

Устройство CE может быть соединено с PE или u-PE через коммутаторы L2, которые не знают о VPLS. С точки зрения VPLS такие коммутаторы L2 невидимы и поэтому далее не рассматриваются. Кроме того, u-PE могут подключаться к PE через устройства L2 и L3, как будет описано ниже.

Термин «демультиплексор» обозначает идентификатор в пакете данных, указывающий экземпляр VPLS, к которому относится пакет, а также входной маршрутизатор PE. В этом документе демультиплексором считается метка MPLS.

Термин VPLS обозначает сервис, а также конкретный экземпляр этого сервиса (т. е. эмулируемую ЛВС). Различия определяются контекстом.

2.2. Допущения

Сеть SP представляет собой сеть с коммутацией пакетов. Предполагается полная (логическая) связность между устройствами PE через туннели, в которые инкапсулируются и пересылаются относящиеся к сервису (например, VPLS) пакеты. Это могут быть туннели IP, такие как GRE11 или туннели MPLS, организованные RSVP-TE12 или LDP. Эти туннели организуются независимо от услуг, предлагаемых на их основе. Организация туннелей и сигнализация не рассматриваются в документе.

Лавинная рассылка (flooding) и изучение MAC-адресов (learning), рассмотренные в разделе 4, являются частью сервиса VPLS. Однако эти действия являются «частным делом» устройства SP, т. е. в описанном ниже сервисе VPLS ни одно устройство SP не запрашивает у других лавинной рассылки или изучения MAC-адресов от его имени.

Для всех PE, участвующих в сервисе VPLS, предполагается полная связность на уровне данных, т. е. наличие двухстороннего псевдопровода между каждой парой устройств PE, участвующих в сервисе VPLS, когда каждый (входной) маршрутизатор PE может напрямую передать пакет VPLS выходному (выходным) PE без использования промежуточных PE (см. параграф 4.2.5.). Это требует полной логической связности VPLS PE на уровне управления так, что PE может передать другому PE сообщение о необходимости организации между ними псевдопровода. Альтернативные варианты соединений рассмотрены в параграфе 3.6.

2.3. Взаимодействие

VPLS представляет собой «услуги ЛВС», где устройства CE, относящиеся к данному экземпляру VPLS V, могут взаимодействовать через сеть SP, как будто они подключены к единой локальной сети. VPLS является «частной» в том смысле, что устройства CE из разных VPLS не могут взаимодействовать. «Виртуальный» характер VPLS заключается в том, что в одной сети с коммутацией пакетов может одновременно существовать множество VPLS.

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

Устройства u-PE взаимодействуют с PE для организации соединений с удаленными PE или u-PE в том же сервисе VPLS. Это взаимодействие происходит на уровне управления.

Устройства PE могут одновременно участвовать в VPLS и IP VPN [6]. Это независимые услуги и данные для каждого типа сервиса хранятся раздельно в NLRI13, имеющих разные идентификаторы семейства адресов (AFI14) и последующего семейства адресов (SAFI15). Следовательно, реализация должна поддерживать свои хранилища маршрутных данных для каждого сервиса. Однако множество экземпляров сервиса может пользоваться одними базовыми туннелями, а для демультиплексирования пакетов разных служб применяются метки VPLS или VPN.

3. Уровень управления

Двумя основными функциями уровня управления VPLS являются автоматическое обнаружение, а также организация и удаление псевдопроводов, составляющих VPLS, часто называемые сигнализацией. Эти функции описаны в параграфах 3.1 и 3.2. Обе эти функции реализуются с помощью одиночных анонсов BGP Update. В параграфе 3.3 более подробно описаны протокольные операции BGP для VPLS. В параграфе 3.4 описана организация псевдопроводов через несколько автономных систем (AS), а в параграфе 3.5 — работа многодомных узлов.

3.1. Автоматическое обнаружение

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

В первом варианте требуется большая работа по настройке конфигурации, поскольку для всех PE данного экземпляра VPLS нужна организация полносвязных (full mesh) соединений (т. е. каждый маршрутизатор PE в данном экземпляре VPLS должен иметь псевдопровод к каждому другому PE в этом экземпляре). Кроме того, при изменении топологии VPLS (например, при добавлении или удалении PE) конфигурацию VPLS требуется менять на всех PE.

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

3.1.1. Функции

Устройство PE, участвующее в данном экземпляре VPLS V, должно быть способно сказать всем другим PE в VPLS V о своем участии в V. PE должны также иметь способ оповещения остальных о своем выходе из VPLS. Для выполнения этих задач PE требуются способы идентификации VPLS и взаимодействия со всеми остальными PE.

Устройства u-PE также должны знать, из чего состоит данный экземпляр VPLS, однако некоторые детали им не нужны. Устройство (устройства) PE, к которому подключено устройство u-PE, предоставляет u-PE абстракцию VPLS, как описано в разделе 5.

3.1.2. Спецификация протокола

Описанный здесь механизм автоматического обнаружения основан на работах [14] и [6], он использует расширенные группы BGP [5] для идентификации участников VPLS. В частности, используется группа Route Target, формат которой описан в работе [5]. Семантика применения Route Target описана в [6] и используется для VPLS.

Поскольку предполагается полная связность в VPLS, одного Route Target RT достаточно для данной VPLS V и RT фактически служит идентификатором для VPLS V.

PE анонсирует (обычно с помощью I-BGP) свою принадлежность к VPLS V, указывая свои NLRI для V (см. следующий параграф) с Route Target RT и принимает NLRI от других PE, имеющих Route Target RT. PE анонсирует свой выход из V путем отзыва всех NLRI, анонсированных с Route Target RT.

3.2. Сигнализация

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

Напомним, что демультиплексор служит для того, чтобы различать потоки трафика в туннеле, где каждый поток может представлять свой сервис. В случае VPLS демультиплексор не только указывает принадлежность пакета к VPLS, но и задает входное устройство PE. Принадлежность к сервису используется для пересылки пакета, а информация о входном устройстве — для изучения MAC-адресов. Описываемые здесь демультиплексоры являются метками MPLS. Однако следует отметить, что туннели PE-PE могут быть не только туннелями MPLS.

Использование отдельного сообщения BGP Update для отправки демультиплексора каждому удаленному PE потребует от PE передачи N таких сообщений для N удаленных PE. Описанное здесь решение позволяет PE передать одно (общее) сообщение Update, содержащее демультиплексоры для всех удаленных PE, вместо N отдельных сообщений. Это снижает загрузку уровня управления на исходном PE и узлах BGP Route Reflector, которые могут быть вовлечены в распространение сообщения Update другим PE.

3.2.1. Блоки меток

Для решения задачи вводится понятие блока меток, который определяется базой LB16 и размером VBS VE-блока, представляющего собой множество меток {LB, LB+1, …, LB+VBS-1}. Рассмотрим работу такого блока. Всем PE в данном экземпляре VPLS в процессе настройки присваиваются уникальные идентификаторы VE ID. Устройство PE X, желающее передать обновление VPLS, отправляет один и тот же блок меток всем остальным PE. Каждое принимающее устройство PE выводит метку, предназначенную для PE X, путем добавления своего (уникального) VE ID к базе меток. Таким способом каждое устройство PE получает уникальный демультиплексор для PE X в данном экземпляре VPLS.

Это простое понятие дополняется концепцией смещения VE-блока VBO. Блок меток, определяемый <LB, VBO, VBS>, представляет собой множество {LB+VBO, LB+VBO+1, …, LB+VBO+VBS-1}. Т. е. взамен одного большого блока меток, охватывающего все VE ID в VPLS, можно задать несколько блоков, имеющих разные базы. Это упрощает управление блоками и позволяет PE X аккуратно обрабатывать добавление в VPLS устройства PE, идентификатор VE ID которого не охватывается набором блоков меток, уже анонсированных устройством PE X.

При загрузке PE или настройке нового экземпляра VPLS процесс BGP может захотеть дождаться приема нескольких анонсов для данного экземпляра VPLS от других PE для повышения эффективности выделения блоков меток.

3.2.2. VPLS BGP NLRI

Описанные ниже VPLS BGP NLRI с новыми семействами адресов AFI и SAFI (см. [4]) служат для обмена информацией о принадлежности к VPLS и демультиплексорами.

VPLS BGP NLRI включает информационные элементы VE ID, VE Block Offset, VE Block Size и базу меток (LB). Формат VPLS NLRI показан на рисунке 2. AFI представляет собой L2VPN AFI (25), а SAFI — VPLS SAFI (65). Поле Length указывает размер в октетах.

+------------------------------------+
|  Length (2 октета)                 |
+------------------------------------+
|  Route Distinguisher  (8 октетов)  |
+------------------------------------+
|  VE ID (2 октета)                  |
+------------------------------------+
|  VE Block Offset (2 октета)        |
+------------------------------------+
|  VE Block Size (2 октета)          |
+------------------------------------+
|  Label Base (3 октета)             |
+------------------------------------+

Рисунок 2. BGP NLRI для информации VPLS.


Устройство PE, участвующее в VPLS, должно иметь хотя бы один идентификатор VE ID. Если устройство PE является VE, оно обычно имеет один идентификатор VE ID. Если устройство PE подключено к нескольким u-PE, оно будет иметь свой VE ID для каждого u-PE. Оно может иметь дополнительный идентификатор VE ID для себя при работе в качестве VE в данном экземпляре VPLS. Далее мы будем обозначать устройство PE, анонсирующее VPLS NLRI, как PE-a и считать, что оно владеет VE ID V (относящимся к самому PE-a или к устройству u-PE, подключенному к PE-a).

Идентификаторы VE ID обычно назначаются администратором сети. Их область действия ограничивается экземпляром VPLS. Данный идентификатор VE ID следует относить лишь к одному PE, если устройство CE не является многодомным (см. параграф 3.5).

Блок меток представляет собой набор меток демультиплексирования, используемых для связи с данным VE ID. VPLS BGP NLRI с VE ID V, VE Block Offset VBO, VE Block Size VBS, и базой меток LB сообщает партнерам:

блок меток для V — метки от LB до (LB + VBS — 1);

набор удаленного VE для V — от VBO до (VBO + VBS — 1).

Имеется взаимно-однозначное соответствие между набором удаленного VE и блоком меток — VE ID (VBO + n) соответствует метке (LB + n).

3.2.3. Организация и разрыв PW

Пусть PE-a является частью VPLS foo и делает анонсы с VE ID V, VE Block Offset VBO, VE Block Size VBS и базой меток LB. Если PE-b тоже является частью VPLS и имеет VE ID W, PE-b выполняет перечисленные ниже операции.

  1. Проверяется принадлежность W к «набору удаленного VE» устройства PE-a — если VBO <= W < VBO + VBS, W is является частью набора удаленного VE для PE-a. В противном случае PE-b игнорирует это сообщение и пропускает остальную часть этой процедуры.

  2. Организуется PW к устройству PE-a. Метка демультиплексора для передачи трафика от PE-b к PE-a рассчитывается как (LB + W — VBO).

  3. Проверяется принадлежность V к «набору удаленного VE», анонсируемому PE-b, т. е. PE-b проверяет, относится ли V к тому или иному набору удаленного VE, который анонсирован PE-b (например, VE Block Offset VBO’, VE Block Size VBS’ и база меток LB’). Если это не так, устройство PE-b должно выполнить новый анонс, как описано в параграфе 3.3.

  4. Организуется PW от PE-a. Метка демультиплексора с которой PE-b следует ожидать трафик от PE-a, рассчитывается как (LB’ + V — VBO’).

Если Y отзывает NLRI для V, используемый X, узел X должен удалить свое окончание псевдопровода между X и Y.

3.2.4. Сигнальные возможности PE

Описанный ниже расширенный атрибут «Layer2 Info Extended Community» используется для передачи сигнальной информации о псевдопроводах, которые будут организованы для данного экземпляра VPLS. Значения для этого атрибута выделяются IANA (в настоящее время используется значение 0x800A). Эта информация включает Encaps Type (тип инкапсуляции в псевдопроводах), Control Flags (данные управления для псевдопроводов) и MTU17 для псевдопроводов.

Encaps Type для VPLS имеет значение 19.

+------------------------------------+
| Extended community type (2 октета) |
+------------------------------------+
|  Encaps Type (1 октет)             |
+------------------------------------+
|  Control Flags (1 октет)           |
+------------------------------------+
|  Layer-2 MTU (2 октета)            |
+------------------------------------+
|  Reserved (2 октета)               |
+------------------------------------+

Рисунок 3. Расширенная группа Layer2 Info.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   MBZ     |C|S|      (MBZ = ДОЛЖНО быть 0)
+-+-+-+-+-+-+-+-+

Рисунок 4. Вектор флагов управления.


Флаги управления показаны на рисунке 4. Биты поля MBZ должны устанавливаться в 0 при передаче, а приемная сторона должна игнорировать эти биты.

C

При установленном (1) флаге слово управления [7] должно присутствовать при передаче пакетов VPLS этому устройству PE, при сброшенном (0) флаге наличие слова управления недопустимо.

S

При установленном (1) флаге передача пакетов VPLS этому устройству PE должна упорядочиваться, при сброшенном (0) флаге упорядочивание недопустимо.

3.3. Работа BGP VPLS

Для создания нового экземпляра VPLS (скажем, VPLS foo) администратор сети должен указать для него RT (например, RT-foo). Это будет использоваться всеми PE для обслуживания VPLS foo. Для настройки данного PE (скажем, PE-a) как участника VPLS foo сетевому администратору нужно лишь выбрать VE ID V для PE-a (если устройство PE-a подключено к u-PE, PE-a может иметь несколько VE ID и указанные ниже действия выполняются для каждого VE ID). Для PE может также указываться обозначение маршрута (RD18), если этого не делать, будет автоматически создано уникальное значение RD для VPLS foo. Предположим, что RD имеет значение RD-foo-a. После этого PE-a создает начальный блок меток и набор удаленного VE для V, определяемый VE Block Offset VBO, VE Block Size VBS и базой меток LB. Этот набор может быть пустым.

Затем PE-a создает VPLS BGP NLRI с RD-foo-a, VE ID V, VE Block Offset VBO, VE Block Size VBS и базой меток LB. К нему устройство присоединяет Layer2 Info Extended Community и RT со значением RT-foo. В качестве BGP Next Hop для этого NLRI устройство указывает себя и анонсирует NLRI своим партнерам. Протоколом сетевого уровня, связанным с сетевым адресом Next Hop для комбинации <AFI=L2VPN AFI, SAFI=VPLS SAFI> является IP, эта привязка требуется разделом 5 в [4]. Если поле Length в Next Hop имеет значение 4, Next Hop содержит адрес IPv4, при Length = 16 — адрес IPv6.

Если PE-a получает от другого PE (скажем, PE-b) анонс VPLS BGP с RT-foo и VE ID W, это говорит PE-a, что PE-b участвует с том же экземпляре VPLS (автоматическое обнаружение). Тогда PE-a организует свою часть псевдопровода VPLS между PE-a и PE-b, используя механизм, описанный в параграфе 3.2. Устройство PE-b аналогичным путем определит участие PE-a в том же экземпляре VPLS и должно организовать свою часть псевдопровода VPLS. Таким образом, сигнализация и организация псевдопровода обеспечиваются с помощью одного сообщения Update.

Если W нет ни в одном наборе удаленного VE, анонсированном PE-a для VE ID V в VPLS foo, PE-b не сможет быть частью псевдопровода к PE-a. Для решения этой проблемы PE-a может отозвать прежний анонс(ы) для VPLS foo и передать новое сообщение Update с большим набором удаленного VE и блоком меток, включающим все VE ID для VPLS foo. Однако это может вызвать прерывание обслуживания. Другим вариантом является создание устройством PE-a нового набора удаленного VE с соответствующим блоком меток и его анонс в новом сообщении Update без отзыва прежних анонсов.

Если конфигурация PE-a меняется с удалением VE ID V из VPLS foo, устройство PE-a должно отозвать все свои анонсы для VPLS foo, содержащие VE ID V. Если все соединения между PE-a и его устройствами CE в VPLS foo отключены (down), PE-a следует отозвать все свои NLRI для VPLS foo или как-то информировать другие PE в VPLS foo о том, что устройство PE-a больше не подключено к своим CE.

3.4. VPLS через множество AS

Как в [14] и [6], описанные выше функции автоматического обнаружения и сигнализации обычно анонсируются через I-BGP. Это предполагает, что все сайты в VPLS подключены к устройствам PE одной автономной системы (AS).

Однако сайты VPLS могут подключаться к PE из разных AS. Это ведет к возникновению двух проблем — (1) между этими PE не будет соединений I-BGP и потребуются другие методы сигнализации через AS, (2) между AS может не быть туннелей PE-PE.

Аналогичная проблема решается в разделе 10 документа [6]. Для решения проблемы (1) предложены 3 метода, каждый из которых имеет аналоги в VPLS через множество AS.

Схема такого сервиса VPLS приведена на рисунке 5.

 __________       ____________       ____________       __________
/          \     /            \     /            \     /          \
            \___/        AS 1  \   /  AS 2        \___/
                                \ /
  +-----+           +-------+    |    +-------+           +-----+
  | PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 |
  +-----+           +-------+    |    +-------+           +-----+
             ___                / \                ___
            /   \              /   \              /   \
\__________/     \____________/     \____________/     \__________/

Рисунок 5. VPLS через множество AS.


Как и в упомянутых выше документах, предлагается три метода сигнализации для VPLS через сети нескольких провайдеров. Метод (a) наиболее прост концептуально и в реализации, он требует соединения Ethernet между AS, а также состояний для уровней данных и управления VPLS на граничных маршрутизаторах AS (ASBR19). Метод (b) требует состояния уровня управления VPLS на ASBR и MPLS для соединений между AS (это не обязательно Ethernet). Для метода (c) требуется MPLS на соединениях AS-AS, но не нужны состояния VPLS на маршрутизаторах ASBR.

3.4.1. Метод (a) — соединения VPLS-VPLS на ASBR

В этом методе граничный маршрутизатор ASBR1 служит в качестве PE для всех VPLS в AS1 и AS, к которым ASBR1 подключен (в данном случае AS2). ASBR в соседней AS (ASBR2) представляется ASBR1 устройством CE для VPLS, которые проходят через AS1 и AS2. Маршрутизатор ASBR2 служит PE для этого экземпляра VPLS с точки зрения AS2 и видит ASBR1 как устройство CE.

Этот метод не требует поддержки MPLS на канале ASBR1-ASBR2, но требует передачи через этот канал трафика Ethernet и наличия отдельного субинтерфейса VLAN для каждого сервиса VPLS, проходящего через канал. Кроме того, от ASBR1 требуется выполнение функций PE (обнаружение, сигнализация, изучение MAC-адресов, лавинная рассылка, инкапсуляция и т. п.) для всех VPLS, проходящих через ASBR1. Это создает значительную нагрузку на уровнях управления и данных в ASBR1, что ограничивает число multi-AS VPLS.

Отметим, что в общем случае между парой AS организуется множество соединений для резервирования. В таких случаях должен применяться протокол STP20 [15] или иные способы обнаружения и предотвращения петель для каждого экземпляра VPLS, проходящего через эти AS, чтобы для каждого экземпляра VPLS могла быть построена топология без петель. Это создает добавочную нагрузку на ASBR и PE, участвующие в таких VPLS, поскольку на устройствах требуется поддерживать алгоритм обнаружения петель для каждого экземпляра VPLS. Решение этого вопроса выходит за рамки документа.

3.4.2. Метод (b) — распространение данных VPLS между ASBR с помощью EBGP

Для этого метода нужно партнерство I-BGP между устройствами PE в AS1 и ASBR1 в AS1 (возможно через рефлектор маршрутов), партнерство E-BGP между ASBR1 и ASBR2 в AS2, а также партнерство I-BGP между ASBR2 и устройствами PE в AS2. В приведенном выше примере PE1 передает маршрутизатору ASBR1 анонс VPLS NLRI с блоком меток, указывая себя в качестве BGP nexthop. ASBR1 передает NLRI маршрутизатору ASBR2 с новым блоком меток и собой в качестве BGP nexthop, а ASBR2 передает NLRI устройству PE2 с новым блоком и собой в качестве nexthop. В результате возникают три туннеля — T1 от PE1 до ASBR1, T2 от ASBR1 до ASBR2 и T3 от ASBR2 до PE2. В каждом туннеле метка VPLS будет использоваться для определения принимающего устройства. Например, меткой VPLS в T1 будет метка из блока, переданного ASBR1 устройству PE1. Маршрутизаторы ASBR отвечают за прием пакетов VPLS, инкапсулированных в туннель и выполнение соответствующих операций замены меток (см. ниже), позволяющих следующему устройству корректно идентифицировать и переслать пакет.

Блок VPLS NLRI, переданный ASBR1 маршрутизатору ASBR2 (и NLRI от ASBR2 к PE2), идентичен VPLS NLRI от PE1 к ASBR1, за исключением блока меток. Точнее, поля Length, Route Distinguisher, VE ID, VE Block Offset и VE Block Size должны совпадать, а Label Base могут различаться. Кроме того, маршрутизатор ASBR1 должен также обновить свой путь пересылки, как описано ниже.

Если LB от PE1 имеет значение L1, Label-block Size — N, LB от ASBR1 — L2, а метка туннеля от ASBR1 к PE1 — T, маршрутизатор ASBR1 должен выполнить для своего пути пересылки следующие операции:

поменять L2 на L1 и втолкнуть T;

поменять L2+1 на L1+1 и втолкнуть T;

…;

поменять L2+N-1 на L1+N-1 и втолкнуть T.

Маршрутизатор ASBR2 должен действовать аналогично, но ему может не потребоваться метка туннеля, если он напрямую соединен с ASBR1.

Когда устройство PE2 хочет передать пакет VPLS устройству PE1, оно использует VE ID для получения нужной метки VPLS из блока ASBR2 для PE1 и применяет метку туннеля для доступа к ASBR2. Маршрутизатор ASBR2 меняет метку туннеля VPLS на метку от ASBR1, затем ASBR1 меняет метку туннеля VPLS на метку от PE1 и выталкивает метку туннеля для доступа к PE1.

Для этого метода требуется поддержка MPLS на интерфейсе ASBR1-ASBR2, но не требуется Ethernet на канальном уровне. Кроме того, маршрутизаторы ASBR принимают участие в распространении информации VPLS. Однако требования к уровню данных ASBR значительно проще, чем для метода (a) и ограничиваются операциями с метками. Наконец, формирование беспетлевой топологии VPLS осуществляется на уровне маршрутизации путем выбора BGP path и nexthop, поэтому не нужно поддерживать STP для каждого экземпляра VPLS. В результате этот метод обеспечивает более эффективную расширяемость по сравнению с методом (a).

3.4.3. Метод (c) — распространение данных VPLS с помощью Multi-Hop EBGP

В этом методе используется партнерство multi-hop E-BGP между устройствами PE (или, предпочтительно, Route Reflector) в AS1 устройствами PE (или Route Reflector) в AS2. PE1 передает VPLS NLRI с метками и собой в качестве nexthop устройству PE2. При использовании рефлектора маршрутов BGP nexthop не меняется. Это требует наличия туннеля LSP от PE1 до PE2. Такой туннель можно создать как в разделе 10 (c) документа [6] (например, используя E-BGP для обмена маршрутами с метками для loopback-интерфейсов PE).

Когда PE1 хочет передать пакет VPLS устройству PE2, он вталкивает метку VPLS, соответствующую его VE ID в пакет. Затем он выталкивает метку (метки) туннеля для доступа к PE2.

Этот метод не требует информации VPLS (на уровне данных или управления) на ASBR. Маршрутизаторам ASBR нужно лишь организовать туннели LSP между устройствами PE на уровне управления и выполнять операции с метками на уровне данных. Как и в методе (b), формирование беспетлевой топологии VPLS осуществляется на уровне маршрутизации путем выбора пути BGP и nexthop, поэтому не нужно поддерживать STP для каждого экземпляра VPLS. Этот вариант явно обеспечивает лучшую расширяемость среди всех трех методов, представленных здесь.

3.4.4. Назначение VE ID во множестве AS

Чтобы упростить выделение VE ID для VPLS через множество AS, можно задать диапазоны значений для каждой AS. Например, AS1использует VE ID от 1 до 100, AS2 — от 101 до 200 и т. д. При наличии 10 сайтов, подключенных к AS1 и 20 — к AS2, выделенными значениями VE ID могут быть 1-10 и 101 — 120. Это минимизирует число передаваемых VPLS NLRI при обеспечении уникальности VE ID.

Если в приведенном выше примере AS1 требуется больше 100 сайтов, выделенный AS1 диапазон значений будет другим. Единственным предостережением является отсутствие перекрытий между диапазонами VE ID разных AS. Исключением из этого правила являются многодомные подключения, рассматриваемые ниже.

3.5. Многодомные подключения и выбор пути

Зачастую желательно иметь многодомный сайт VPLS, т. е. подключить его ко множеству PE, возможно даже из разных AS. В таких случаях для PE, подключенных к одному сайту, можно задать одно или разные значения VE ID. В последнем случае обязательно использовать протокол STP на устройстве CE, а возможно и на устройствах PE для создания топологии VPLS без петель. Способы реализации этого выходят за рамки документа, однако в остальной части этого параграфа более подробно рассматривается первый вариант. Отметим, что многодомное подключение к SP и протокол STP на устройствах CE могут применяться совместно. Пользователям VPLS рекомендуется применять STP, если устройства CE поддерживают протокол.

Если устройствам PE, подключенным к одному сайту, назначается одинаковый идентификатор VE ID, беспетлевая топология формируется механизмами маршрутизации, в частности, выбором пути BGP. Когда узел BGP получает два эквивалентных NLRI (см. ниже), он применяет стандартные критерии выбора пути (такие, как Local Preference и AS Path Length) для определения нужного NLRI (узел должен выбрать один). Если выбранный блок NLRI позднее отзывается, узел BGP применяет механизм выбора пути к оставшимся эквивалентным VPLS NLRI для выбора другого. Если таких NLRI больше нет, связанная с ними информация о пересылке удаляется.

Два VPLS NLRI считаются эквивалентными с точки зрения выбора пути, если значения Route Distinguisher, VE ID и VE Block Offset у них совпадают. Если двум PE выделено одно значение VE ID в данном экземпляре VPLS, они должны использовать одинаковое значение Route Distinguisher, а также им следует анонсировать один VE Block Size для данного VE Offset.

3.6. Иерархические BGP VPLS

В этом параграфе описано, как можно расширить уровень управления VPLS при использовании BGP. Имеется по меньшей мере три аспекта расширяемости уровня управления.

  1. Уход от требования полносвязных (full mesh) соединений между всеми узлами VPLS BGP.

  2. Ограничение числа сообщений BGP VPLS за счет их передачи лишь заинтересованным узлам BGP.

  3. Упрощение процедур добавления и удаления узлов BGP для VPLS или других приложений.

К счастью, применение BGP для маршрутизации Internet и IP VPN дало несколько хороших решений для этих проблем. Основным вариантом является использование иерархии на основе рефлекторов маршрутов BGP RR21 [8]. Идея заключается в назначении небольшого набора рефлекторов маршрутов, а затем организации сессий BGP между каждым узлом BGP и одним или множеством RR. В этом случае не требуется организации полносвязных соединений между всеми узлами BGP. Если для конкретного провайдера требуется большое число RR, этот метод можно использовать рекурсивно, заменяя полносвязные соединения между всеми RR их соединениями с RR другого уровня. Применение RR решает проблемы 1 и 3.

Важно подчеркнуть, что применение RR для VPLS и VPN полностью относится к уровню управления. RR не создает состояний и требований к пересылке на уровне данных, а также не меняет путей пересылки трафика VPLS. Это отличается от модели иерархического сервиса VPLS, определенной в [10].

Другим следствием такого подхода является отсутствие требования обработки одним набором RR всех сообщений BGP или обработки отдельным RR всех сообщений от данного PE. Можно определить несколько наборов RR, например, один для обработки VPLS, другой для IP VPN, а третий для маршрутизации Internet. Возможно другое разделение, когда то или иное подмножество VPLS и IP VPN обрабатывается одним набором RR, а второе подмножество — другим. Использование фильтрации целей маршрутов (RTF22), описанной в [12], позволяет сделать это более просто и эффективно.

Проблема 2 (передача сообщений BGP VPLS лишь заинтересованным узлам BGP) решается с помощью RTF. Этот метод «ортогонален» использованию RR, но они хорошо работают вместе. Фильтрация RTF также очень эффективна для VPLS через множество AS. Подробности и преимущества использования RTF описаны в [12]. Следует также упомянуть один аспект уровня управления, с которым часто возникает путаница. Обмен MAC-адресами не выполняется по протоколу BGP. Все операции изучения и старения MAC-адресов выполняются на уровне данных отдельно для каждого PE. Единственной задачей сообщений BGP VPLS является автоматическое обнаружение и обмен метками.

Таким образом, обработка BGP для VPLS возникает

  1. при добавлении или удалении PE из VPLS;

  2. при отказе в сети, отключающем (down) туннель PE-PE или канал PE-CE.

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

4. Уровень данных

В этом разделе описаны два аспекта уровня данных для устройств PE и u-PE, участвующих в VPLS, — инкапсуляция и пересылка.

4.1. Инкапсуляция

Кадры Ethernet, полученные от устройств CE, инкапсулируются для передачи через сеть с коммутацией пакетов, к которой подключены PE. Инкапсуляция выполняется в соответствии с [7].

4.2. Пересылка

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

4.2.1. Изучение MAC-адресов

Как было отмечено выше, ключевым отличием VPLS является поддержка многоточечного сервиса. Это означает, что всей сети сервис-провайдера следует быть одним логическим обучающимся мостом для каждого сервиса VPLS, поддерживаемого в сети SP. Логическими портами «моста» SP являются абонентские порты, а также псевдопровода на VE. Как обычный обучаемый мост изучает MAC-адреса на своих портах, так и мост SP должен изучать MAC-адреса на своих VE.

Обучение заключается в связывании MAC-адресов отправителей пакетов с (логическими) портами, через которые пакеты приходят. Эта привязка создает таблицу FIB23, используемую для пересылки пакетов. Предположим, например, что мост получает пакет с MAC-адресом отправителя S на (логическом) порту P. Если после этого мост получит пакет с MAC-адресом получателя S, он будет знать, что пакет нужно передать через порт P.

Если VE узнает MAC-адрес отправителя S на логическом порту P, а затем видит S на другом порту P’, устройство VE должно обновить свою таблицу FIB, указав в ней новый порт P’. VE может реализовать механизм демпфирования смены (flapping) портов-источников для данного MAC-адреса.

4.2.2. Старение

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

«Возрастом» MAC-адреса S на логическом порту P считается время с момента, когда он последний раз наблюдался в качестве MAC-адреса отправителя на порту P. Если возраст превышает время старения T, запись для S должна быть удалена из FIB. При каждом появлении S в качестве MAC-адреса отправителя на порту P возраст S сбрасывается (0).

Реализации следует предоставлять средство настройки времени старения T на уровне VPLS. В дополнение к этому реализация может ускорять старение всех MAC в VPLS для некоторых ситуаций (например, при изменении топологии STP в данном экземпляре VPLS).

4.2.3. Лавинная рассылка

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

В примере на рисунке 1 устройство PE2 будет отвечать за лавинную рассылку кадра всем другим PE в том же экземпляре VPLS, если CE2 передаст PE2 кадр Ethernet с отсутствующим в таблице FIB устройства PE2 (для данного экземпляра VPLS) адресом получателя. При получении такого кадра PE1 будет отвечать за дальнейшую лавинную рассылку кадра устройствам CE1 и CE5 (если PE1 не знает, какое из устройств CE «владеет» этим MAC-адресом).

С другой стороны, если устройство PE3 получает кадр, оно будет поручать лавинную рассылку своему u-PE. Если устройство PE3 подключено к двум u-PE, оно будет анонсировать наличие двух u-PE. PE3 может анонсировать неспособность к лавинной рассылке и в этом случае будет получать 2 кадра (по одному для каждого u-PE) или указать возможность лавинной рассылки, получая при этом один экземпляр кадра, который будет пересылаться обоим u-PE.

4.2.4. Широковещательные и групповые кадры

Имеются общеизвестные широковещательные MAC-адреса. Кадр Ethernet с широковещательным MAC-адресом получателя должен передаваться всем станциям данного экземпляра VPLS. Это может быть реализовано так же, как выполняется лавинная рассылка.

Имеется также легко распознаваемое множество групповых (multicast) MAC-адресов. Кадры Ethernet с групповым MAC-адресом получателя могут передаваться широковещательно всем станциям. VE может также применять те или иные методы ограничения групповой пересылки меньшим множеством получателей, которые указали заинтересованность в соответствующей multicast-группе. Рассмотрение этого вопроса выходит за рамки документа.

4.2.5. Пересылка с «расщепленным горизонтом»

Когда поддерживающее лавинную рассылку устройство PE (скажем, PEx) получает широковещательный кадр Ethernet или кадр с неизвестным MAC-адресом получателя, оно должно применять лавинную рассылку для этого кадра. Если кадр принят от подключенного CE, устройство PEx должно передать копию кадра всем другим подключенным CE, а также устройствам PE, участвующим в VPLS. Если же кадр приходит от другого PE (например, PEy), устройство PEx должно передать копию пакета лишь подключенным CE. PEx недопустимо передавать такой кадр другим PE, поскольку устройство PEy уже сделало это. Это называют пересылкой с «расщепленным горизонтом» и такая является следствием наличия полной связности между PE в рамках VPLS.

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

4.2.6. Квалифицированное и неквалифицированное обучение

Ключом для нормального обучения Ethernet MAC обычно служат (6-октетные) MAC-адреса. Это называется неквалифицированным обучением. Однако возможно включение в процесс имеющихся в кадрах тегов VLAN и тогда это называется квалифицированным обучением.

В случае VPLS обучение выполняется в контексте экземпляра VPLS, который обычно соответствует одному абоненту. Если абонент применяет теги VLAN, он может разделять квалифицированное и неквалифицированное обучение. Если ключом при обучении в VPLS является лишь MAC-адрес, VPLS будет работать в режиме неквалифицированного обучения. Если ключом служит абонентский тег VLAN и MAC-адрес, VPLS использует квалифицированное обучение.

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

4.2.7. Класс обслуживания

Для поддержки разных классов обслуживания в рамках VPLS реализация может сопоставлять биты 802.1p в абонентских кадрах Ethernet с тегами VLAN с битами EXP в псевдопроводе и/или метке туннеля, что позволяет по-разному обрабатывать кадры VPLS в сети с коммутацией пакетов.

Чтобы такое сопоставление было полезно, реализации следует разрешать свое отображение для каждого экземпляра VPLS, поскольку каждый абонент VPLS может иметь свое представление об установке поведения битов 802.1p.

5. Варианты развертывания

При развертывании сети с поддержкой VPLS оператор должен решить, какие функции будут обеспечивать устройства с поддержкой VPLS, расположенные близко к абонентам (VE). Используемый по умолчанию случай, описанный в этом документе, предполагает применение в качестве VE маршрутизаторов PE. Однако имеется много причин, по которым VE может быть устройством, выполняющим все функции L2 (такие как изучение MAC-адресов и лавинная рассылка), а также ограниченный набор функций L3 (такие, как взаимодействие со своим PE), но не поддерживающим, например, полноценного обнаружения и сигнализации PE-PE. Такие устройства называются u-PE.

Поскольку у обоих вариантов есть свои преимущества, хотелось бы иметь возможность их совместного применения. Представленные здесь механизмы сигнализации позволяют это. Например, в данной сети оператора одно устройство PE может напрямую подключаться к CE, другое — к устройствам u-PE, соединенным с устройствами CE, а третье может подключаться напрямую к абонентам через те или иные интерфейсы и к устройствам u-PE — через другие. Все эти PE будут одинаково выполнять обнаружение и сигнализацию. Функции обучения и пересылки зависят от того, является ли устройство u-PE, однако это локальный вопрос, не связанный с сигнализацией. Детали работы u-PE и их взаимодействия с устройствами PE и другими u-PE выходят за рамки этого документа.

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

Основное внимание в VPLS уделяется приватности данных, т. е. данные в VPLS распространяются только узлам данного экземпляра VPLS и недоступны каким-либо внешним агентам или другим VPLS. Отметим, что сервис VPLS не предоставляет защиты конфиденциальности, целостности и проверки подлинности. Пакеты VPLS передаются в сеть пакетной коммутации в открытом виде и злоумышленник на пути передачи24 может перехватывать пакет, а в некоторых случаях имеет возможность помещать свои пакеты в поток данных. Если требуется защита, в качестве туннелей PE-PE могут служить туннели IPsec. Для дополнительной защиты оконечные системы на сайтах VPLS могут использовать подходящее шифрование пакетов до их отправки в сеть сервис-провайдера.

Имеется два аспекта, связанных с приватностью в VPLS — безопасность уровня управления и защита пути пересылки. Компрометация уровня управления может приводить к передаче устройством PE данных, относящихся к одному экземпляру VPLS, в другой, созданию «черной дыры» для данных VPLS или даже отправки их перехватывающему устройству. Ни одно из таких событий не приемлемо с точки зрения приватности. Поскольку весь обмен на уровне управления осуществляется по протоколу BGP, методы, описанные в [2], могут помочь при проверке подлинности сообщений BGP, осложняя подмену обновлений (которые могут использоваться для направления трафика VPLS другому экземпляру VPLS) или отзыв данных (атаки на отказ в обслуживании). В методах (b) и (c) для работы через множество AS, описанных в разделе 3, это обеспечивает защиту сеансов BGP между AS, а также между устройствами ASBR, PE и рефлекторами маршрутов. Можно также применять методы, описанные в разделе 10 (b) и (c) документа [6], как для уровня управления, так и для уровня данных. Отметим, что методы [2] не помогут сохранить приватность меток VPLS, а зная эти метки, можно перехватить трафик VPLS. Однако для этого нужен доступ к путям данных в сети SP.

Возможны ошибочные конфигурации, ведущие к непреднамеренным подключениям устройств CE не к тем VPLS. Это может быть вызвано, например, некорректным Route Target для экземпляра VPLS. Эта проблема, как отмечено в [6], требует дополнительного исследования.

Для защиты уровня данных нужно обеспечить корректное поведение туннелей PE-PE (это выходит за рамки документа) и восприятие меток VPLS только от разрешенных интерфейсов. Для PE такими интерфейсами будут каналы к маршрутизаторам P, для ASBR — канал от маршрутизатора ASBR в AS, являющуюся частью данного экземпляра VPLS. При организации VPLS через множество AS особенно важно восприятие пакетов VPLS VPLS лишь от разрешенных интерфейсов.

В документе [3] описано туннелирование MPLS-in-IP и MPLS-in-GRE. Если желательно применение таких туннелей для транспортировки пакетов VPLS, нужно разобраться с вопросами безопасности, отмеченными в разделе 8 упомянутого документа. Любая реализация VPLS, которая позволяет туннелировать пакеты VPLS в соответствии с указанным документом, должна включать поддержку IPsec, которую можно использовать, как описано здесь. Если туннель не защищен с помощью IPsec, описанная в параграфе 8.2 этого документа фильтрация по адресам IP на граничных маршрутизаторах, будет единственным способом обеспечить на выходе из туннеля в конкретное устройство PE присутствие пакетов только от разрешенных входных точек туннелей (т. е. отсечь пакеты с подставным адресом отправителя). Поскольку граничные маршрутизаторы зачастую фильтруют лишь по адресам отправителей, фильтрация пакетов может оказаться неэффективной, если выходной PE не может проверить IP-адрес отправителя во всех принимаемых пакетах и сравнить его со списком IP-адресов разрешенных начальных точек туннелей. Любая реализация, разрешающая применять инкапсуляцию MPLS-in-IP или MPLS-in-GRE без защиты IPsec, должна позволять выходному PE такую проверку по IP-адресам для всех полученных туннелированных пакетов.

7. Взаимодействие с IANA

Агентство IANA выделило значение AFI 25 для информации L2VPN. Это значение совпадает с AFI, запрошенным в [11].

Агентство IANA выделило значение 0x800a для Layer2 Info Extended Community.

8. Литература

8.1. Нормативные документы

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

[2] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[3] Worster, T., Rekhter, Y., and E. Rosen, «Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)», RFC 4023, March 2005.

[4] Bates, T., Katz, D., and Y. Rekhter, «Multiprotocol Extensions for BGP-4», RFC 4760, January 2007.

[5] Sangli, S., Tappan, D., and Y. Rekhter, «BGP Extended Communities Attribute», RFC 4360, February 2006.

[6] Rosen, E. and Y. Rekhter, «BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4364, February 2006.

[7] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, «Encapsulation Methods for Transport of Ethernet over MPLS Networks», RFC 4448, April 2006.

8.2. Дополнительная литература

[8] Bates, T., Chen, E., and R. Chandra, «BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)», RFC 4456, April 2006.

[9] Andersson, L. and E. Rosen, «Framework for Layer 2 Virtual Private Networks (L2VPNs)», RFC 4664, September 2006.

[10] Lasserre, M., Ed. and V. Kompella, Ed., «Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling», RFC 4762, January 2007.

[11] Ould-Brahim, H., «Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs», Work in Progress, April 2006.

[12] Marques, P., «Constrained VPN Route Distribution», Work in Progress, June 2005.

[13] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, «Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)», RFC 4447, April 2006.

[14] Kompella, K., «Layer 2 VPNs Over Tunnels», Work in Progress, January 2006.

[15] Institute of Electrical and Electronics Engineers, «Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Common specifications — Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e. ISO/IEC 15802-3: 1998.», IEEE Standard 802.1D, July 1998.

Приложение A. Участники работы

Ниже перечислены участники работы над документом.

Javier Achirica, Telefonica
Loa Andersson, Acreo
Giles Heron, Tellabs
Sunil Khandekar, Alcatel-Lucent
Chaitanya Kodeboyina, Nuova Systems
Vach Kompella, Alcatel-Lucent
Marc Lasserre, Alcatel-Lucent
Pierre Lin
Pascal Menezes
Ashwin Moranganti, Appian
Hamid Ould-Brahim, Nortel
Seo Yeong-il, Korea Tel

Приложение B. Благодарности

Спасибо Joe Regan и Alfred Nothaft за их вклад в работу. Большое спасибо Eric Ji, Chaitanya Kodeboyina, Mike Loomis и Elwyn Davies за подробные рецензии.

Адреса редакторов

Kireeti Kompella

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA 94089

US

EMail: kireeti@juniper.net

Yakov Rekhter

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA 94089

US

EMail: yakov@juniper.net


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru


Полное заявление авторских прав

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Virtual Private LAN Service — услуги виртуальной частной ЛВС.

2Transparent LAN Services — услуги «прозрачной ЛВС».

3Virtual Private Switched Network — виртуальная частная коммутируемая сеть.

4Service Provider.

5Virtual Private Network.

6Label Distribution Protocol.

7Autonomous System.

8Provider Edge.

9Provider-only — только для провайдера.

10Customer Edge.

11Generic Routing Encapsulation — базовая инкапсуляция маршрутных данных.

12Reservation Protocol — Traffic Engineering — протокол резервирования ресурсов — организация трафика.

13Network Layer Reachability Information — информация о доступности на сетевом уровне.

14Address Family Identifier.

15Subsequent Address Family Identifier.

16Label base.

17Maximum Transmission Unit — максимальный передаваемый блок.

18Route Distinguisher.

19AS border router.

20Spanning Tree Protocol — протокол связующего дерева.

21Route Reflector.

22Route Target Filtering.

23Forwarding Information Base — база информации для пересылки кадров.

24Man-in-the-middle — человек посередине.




RFC 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling

Network Working Group                                   M. Lasserre, Ed.
Request for Comments: 4762                              V. Kompella, Ed.
Category: Standards Track                                 Alcatel-Lucent
                                                            January 2007

Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling

VPLS с использованием сигнализации LDP

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The IETF Trust (2007).

Замечание IESG

Рабочая группа L2VPN создала два отдельных документа — RFC 4761 и этот документ, в которых реализованы похожие функции на основе разных протоколов сигнализации. Отметим, что оба метода обычно называют VPLS, хотя они отличаются и не совместимы друг с другом.

Тезисы

Этот документ описывает решение по организации с использованием псевдопроводов услуг VPLS1, которые раньше предоставлялись на основе других технологий туннелирования, известных как TLS2. VPLS создает сегмент эмулируемой ЛВС для заданного множества пользователей, т. е. организуется широковещательный домен L2, поддерживающий обучение и пересылку по адресам Ethernet MAC и ограниченный заданным множеством пользователей. На одном краевом устройстве провайдера (PE3) может поддерживаться множество независимых служб VPLS.

Этот документ описывает функции уровня управления для сигнализации меток псевдопровода с использованием протокола LDP4, расширяющего RFC 4447. Метод не зависит от протокола обнаружения. Описаны также функции пересылки на уровне данных с концентрацией на функциях обучения (learning) для MAC-адресов. Инкапсуляция пакетов VPLS описана в RFC 4448.

Оглавление

Исключено в версии HTML.

1. Введение

Технология Ethernet стала преобладающей в сфере локальных сетей (ЛВС) и получает признание в качестве технологии доступа, особенно в городских и распределенных сетях (MAN5 и WAN6, соответственно). Основным назначением служб VPLS является обеспечение связности между географически разделенными пользовательскими сайтами через сети MAN и WAN, как будто эти сайты подключены к одной ЛВС. Предполагаемые применения для конечных пользователей можно разделить на две категории:

  • соединение маршрутизаторов абонента — маршрутизация ЛВС;

  • соединение коммутаторов абонента — коммутация ЛВС.

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

[RFC4448] определяет способ передачи кадров L2 через псевдопровод (PW) «точка-точка». Этот документ описывает расширение [RFC4447] для транспортировки трафика Ethernet/802.3 и VLAN [802.1Q] через множество сайтов, относящихся к одному широковещательному домену L2 или VPLS. Отметим, что та же модель может применяться к другим технологиям 802.1. Она описывает простой и расширяемый способ обеспечивать услуги виртуальных ЛВС, включая подобающую рассылку широковещательного, группового и индивидуального трафика неизвестных адресатов через сеть MPLS, без необходимости использовать серверы преобразования адресов или иные внешние серверы, как описано в [L2VPN-REQ].

Приведенное ниже обсуждение применимо к устройствам, способным поддерживать VPLS и туннелировать пакеты с метками между собой. Полученное в результате множество соединенных между собой устройств образует MPLS VPN.

2. Термины

Q-in-Q

Расширение 802.1ad Provider Bridge, известное также как стековые VLAN и Q-in-Q.

Qualified learning — квалифицированное обучение

Режим обучения, в котором каждая VLAN абонента отображается на свой экземпляр VPLS.

Service delimiter — указатель сервиса

Информация, используемая для идентификации конкретного экземпляра абонентского сервиса. Обычно представляется в заголовке инкапсуляции абонентских кадров (например, VLAN Id).

Tagged frame — кадр с тегом

Кадр с идентификатором 802.1Q VLAN.

Unqualified learning — неквалифицированное обучение

Режим обучения, в котором все VLAN одного абонента отображаются на один экземпляр VPLS.

Untagged frame — кадр без тега

Кадр, не имеющий идентификатора 802.1Q VLAN.

2.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

3. Сокращения

AC Attachment Circuit (устройство подключения).

BPDU Bridge Protocol Data Unit (блок данных протокола мостов).

CE Customer Edge device (краевое устройство абонента).

FEC Forwarding Equivalence Class (класс эквивалентности пересылки).

FIB Forwarding Information Base (база информации для пересылки).

GRE Generic Routing Encapsulation (базовая инкапсуляция маршрутных данных).

IPsec IP security (безопасность IP).

L2TP Layer Two Tunneling Protocol (туннельный протокол уровня 2).

LAN Local Area Network (локальная сеть, ЛВС).

LDP Label Distribution Protocol (протокол распространения меток).

MTU-s Multi-Tenant Unit switch (коммутатор для множества арендаторов).

PE Provider Edge device (краевое устройство провайдера).

PW Pseudowire (псевдопровод).

STP Spanning Tree Protocol (протокол связующего дерева).

VLAN Virtual LAN (виртуальная ЛВС).

VLAN tag VLAN Identifier (идентификатор VLAN).

4. Топологическая модель для VPLS

Участвующий в VPLS интерфейс должен быть способен рассылать в лавинном режиме (flood), пересылать и фильтровать кадры Ethernet. На рисунке 1 показана топологическая модель VPLS. Множество устройств PE, соединенных между собой псевдопроводами PW, представляется одной эмулируемой ЛВС для абонента X. Каждое устройство PE будет формировать MAC для своего PW и связывать подключенные напрямую MAC-адреса с локальными портами в сторону абонента. Это моделирует стандартное обучение IEEE 802.1 MAC.

+-----+                                              +-----+
| CE1 +---+      ...........................     +---| CE2 |
+-----+   |      .                         .     |   +-----+
 Сайт 1   |   +----+                    +----+   |   Сайт 2
          +---| PE |       Облако       | PE |---+
              +----+                    +----+
                 .                         .
                 .         +----+          .
                 ..........| PE |...........
                           +----+         ^
                             |            |
                             |            +-- Эмулируемая ЛВС
                           +-----+
                           | CE3 |
                           +-----+
                           Сайт 3

Рисунок 1. Топологическая модель VPLS для абонента с 3 сайтами.


Отметим еще раз, что в документе приводятся конкретные примеры использования транспортных туннелей MPLS, но PW могут применять и другие туннели (как указано в [RFC4447]), например, GRE, L2TP, IPsec, если они позволяют идентифицировать исходное устройство PE, поскольку это нужно для процесса обучения MAC.

Областью применения VPLS являются устройства PE в сети сервис-провайдера и это подчеркивает тот факт, что кроме разграничения абонентского сервиса, форма доступа к сайту абонента никак не связана с VPLS [L2VPN-REQ]. Иными словами, устройство присоединения (AC), подключенное к абоненту, может быть физическим портом Ethernet, логическим (тег) портом Ethernet, ATM PVC, передающим кадры Ethernet и т. п., включая даже Ethernet PW.

PE обычно является граничным маршрутизатором, способным работать с сигнальным протоколом LDP и/или протоколами маршрутизации для организации PW. Кроме того, он способен организовывать транспортные туннели к другим PE и доставлять трафик через PW.

4.1. Пересылка и лавинная рассылка

Одним из свойств сервиса Ethernet является передача кадров по широковещательным адресам и лавинная рассылка во все порты кадров с неизвестным MAC-адресом получателя. Для лавинной рассылки в сети сервис-провайдера все кадры с неизвестным индивидуальным адресом, а также широковещательные и групповые кадры рассылаются в лавинном режиме через все соответствующие PW всем узлам PE, участвующим в VPLS, а также всем устройствам AC.

Отметим, что групповые кадры являются особым случаем и не обязательно требуют рассылки всем членам VPN. Для простоты по умолчанию используется широковещательная рассылка групповых кадров.

Для пересылки кадра устройство PE должно быть способно связать MAC-адрес получателя с PW. Неразумно, а порой и невозможно требовать настройки на всех PE статической привязки всех возможных MAC-адресов к PW. Поэтому поддерживающим VPLS устройствам PE следует иметь возможность динамического изучения MAC на AC и PW, а также пересылки и репликации пакетов через AC и PW.

4.2. Изучение адресов

В отличие от BGP VPN [RFC4364], информация о доступности не анонсируется и не распространяется на уровне управления. Доступность определяется стандартными функциями обучения моста на уровне данных.

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

При смене состояния PW или AC требуется выполнять стандартные операции обучения, фильтрации и рассылки, определенные в [802.1D-ORIG], [802.1D-REV] и [802.1Q].

4.3. Топология туннелей

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

В Ethernet L2VPN на сервис-провайдера ложится ответственность за создание топологии без петель. Для простоты определим топологию VPLS как полносвязный (full mesh) набор PW.

4.4. VPLS без петель

Если топология VPLS не является полносвязной, может оказаться, что пара PE не связана напрямую через PW и будет использовать промежуточные PE для трансляции пакетов. Такая топология будет требовать применения того или иного протокола устранения петель, подобного STP.

Вместо этого между PE организуется полносвязная сеть PW. Поскольку в этом случае каждое устройство PE напрямую соединяется со всеми другими PE в составе VPLS через псевдопровод PW, трансляция пакетов уже не требуется и можно использовать для устранения петель простое правило «расщепления горизонта» (split horizon), в соответствии с которым PE недопустимо пересылать трафик из одного PW в другой из состава той же сети соединений VPLS.

Отметим, что абоненты могут применять протокол STP (скажем, в соответствии с [802.1D-REV]), например, при наличии у абонента дополнительных соединений (back door) для резервирования на случай отказа в VPLS. В таких случаях STP BPDU7 просто туннелируются через облако провайдера.

5. Обнаружение

Требуется возможность настройки адресов удаленных PE вручную. Однако ручная настройка перестает быть необходимой при использовании процедур автоматического обнаружения. Данный документ совместим со множеством процедур автоматического обнаружения ([RADIUS-DISC], [BGP-DISC]).

6. Уровень управления

Этот документ описывает функции уровня управления для сигнализации меток PW. Выполнены некоторые базовые работы в части поддержки многодомности (multi-homing). Расширениям, обеспечивающим многодомность, следует работать независимо от базовых операций VPLS и здесь они не рассматриваются.

6.1. Сигнализация демультиплексоров на базе LDP

Полная связность сессий LDP служит для организации сети PW. Требование полносвязной сети PW может приводить к большому числу сессий LDP. В разделе 10 рассмотрен вариант организации иерархической топологии для снижения числа связей в VPLS.

Поскольку сессии LDP организуются между двумя PE, все PW между этими двумя PE сигнализируются в одной сессии.

В [RFC4447] описано два типа FEC — PWid FEC Element (FEC типа 128) и Generalized PWid FEC Element (FEC типа 129). Исходные элементы FEC, применяемые для VPLS, совместимы с PWid FEC Element. Описание сигнализации с использованием элементов PWid FEC перенесено в Приложение A. Ниже вместо этого описано применение более обобщенного дескриптора L2VPN — Generalized PWid FEC Element.

6.1.1. Использование обобщенного элемента PWid FEC

В [RFC4447] описана обобщенная структура FEC, которая будет применяться для сигнализации VPLS, описанной ниже. Рассматривается назначение полей Generalized PWid FEC Element в контексте сигнализации VPLS.

Control bit (C) — слово управления

Этот бит указывает использование слова управления, описанного в [RFC4447].

PW type — тип псевдопровода

Разрешенными типами PW являются Ethernet (0x0005) и Ethernet tagged (0x004), как указано в [RFC4446].

PW info length – размер информации псевдопровода

В соответствии с [RFC4447].

Attachment Group Identifier (AGI), Length, Value – идентификатор группы подключения, размер, значение

Уникальное имя данной VPLS. AGI указывает тип имени, а Length — размер поля Value, в котором задано имя VPLS. Термин AGI используется наравне с термином «идентификатор VPLS».

Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII)

Это пустые (null) значения, поскольку сеть PW в VPLS завершается таблицами обучения MAC, а не отдельными устройствами подключения. Использование непустых TAII и SAII зарезервировано на будущее.

Interface Parameters – параметры интерфейса

MTU

Максимальный размер передаваемого блока (MTU8) в VPLS должен совпадать для всех PW в сети (mesh).

Optional Description String – необязательная строка описания

В соответствии с [RFC4447].

Requested VLAN ID – запрошенный идентификатор VLAN

Если PW работает в режиме Ethernet с тегами, этот параметр может служить для сигнализации вставки подходящего VLAN ID, как определено в [RFC4448].

6.2. Отзыв MAC-адресов

Может оказаться желательным удаление или отмена обучения (unlearn) для определенных динамически MAC-адресов с целью ускорить схождение. Это достигается передачей сообщения LDP Address Withdraw со списком MAC-адресов для удаления всем другим PE через соответствующие сессии LDP.

Здесь определяется необязательный элемент MAC List TLV в LDP для задания списка MAC-адресов, которые будут удалены (или для них будет отменено обучение) с помощью сообщений LDP Address Withdraw.

Сообщения Address Withdraw с MAC List TLV могут поддерживаться для ускоренного удаления MAC-адресов в результате изменения топологии (например, отказ основного канала для двудомного коммутатора с поддержкой VPLS).

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

6.2.1. TLV со списком MAC

Отмена обучения (unlearn) для MAC-адреса может быть указана передачей сообщения LDP Address Withdraw с новым MAC List TLV, формат которого описан ниже. Представление адреса MAC List TLV в 6-октетном формате MAC определено документами IEEE 802 [802.1D-ORIG] [802.1D-REV].

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|       Type                |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      MAC address #1                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        MAC address #1         |      MAC Address #2           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      MAC address #2                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                              ...                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      MAC address #n                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        MAC address #n         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


U bit

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

F bit

Флаг пересылки, который должен иметь значение 0. Поскольку применяется адресный (targeted) механизм LDP, пересылка TLV недопустима.

Type

Поле типа, которое должно иметь значение 0x0404 (MAC List TLV).

Length

Поле, указывающее общий размер (в октетах) MAC-адресов в TLV. Размер должен быть кратным 6.

MAC Address

MAC-адрес(а) для удаления.

Сообщение MAC Address Withdraw содержит FEC TLV (для указания VPLS), MAC Address TLV и необязательные параметры. Для сигнализации MAC Address Withdraw необязательных параметров не определено. Отметим, что при получении устройством PE непонятного сообщения MAC Address Withdraw, сообщение должно игнорироваться. В этом случае вместо очистки таблицы MAC-адресов будет продолжаться использование несвежей информации, пока не возникнет одно указанных ниже условий.

  • Принят пакет с известной привязкой MAC-адреса из другого PW, которая заменит прежнюю привязку.

  • Привязка устарела.

Сообщения MAC Address Withdraw лишь помогают ускорить схождение, поэтому PE, не понимающие сообщения, продолжат участвовать в VPLS.

6.2.2. Сообщение об отзыве с TLV со списком MAC-адресов

Обработка MAC List TLV из полученного сообщения Address Withdraw включает перечисленные ниже операции.

  • Для каждого MAC-адреса в TLV удаляется привязка к AC или PW, откуда было принято сообщение.

  • Для каждого сообщения MAC Address Withdraw с пустым списком адресов удаляются все MAC-адреса, связанные с экземпляром VPLS (задается FEC TLV), за исключением MAC-адресов, узнанных (learned) через PW, связанный с сигнальной сессией, в которой получено сообщение.

Областью действия MAC List TLV является VPLS, указанная полем FEC TLV в сообщении MAC Address Withdraw. Число MAC-адресов можно определить из поля размера TLV.

7. Пересылка данных в Ethernet PW

В этом разделе описано поведение уровня данных Ethernet PW, используемых в VPLS. Хотя инкапсуляция похожа на описанную в [RFC4448], функции вырезания указывающего сервис тега и использование «нормализованных» кадров Ethernet дополнительно описаны здесь.

7.1. Инкапсуляция VPLS

В VPLS абонентские кадры Ethernet без преамбулы инкапсулируются с заголовком, определенным в [RFC4448]. Определение типов абонентских кадров Ethernet приведено ниже.

  • Если полученный PE кадр имеет инкапсуляцию, используемую данным PE в качестве обозначения сервиса (т. е. для идентификации конкретного абонента и/или конкретного сервиса для данного абонента), инкапсуляцию можно вырезать до отправки кадра в VPLS. На выходе кадра из VPLS сервисный тег может быть возвращен.

  • Если пришедший в PE кадр имеет инкапсуляцию, не используемую данным PE в качестве обозначения сервиса, инкапсуляцию кадра не следует менять в VPLS. К таким кадрам относятся, например, кадры с заданными клиентом тегами VLAN, о которых сервис-провайдер не знает и которые не хочет менять.

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

Аналогично при поступлении кадра на обращенный в сторону абонента порт через ATM или Frame Relay VC, указывающий экземпляр абонентской VPLS, инкапсуляция ATM или FR будет удалена перед отправкой кадра в VPLS.

И напротив, при получении на обращенном в сторону абонента порту кадра с тегом VLAN, указывающим домен VLAN в абонентской сети L2, этот тег будет сохранен, поскольку он связан с остальной частью кадра.

В соответствии с этими правилами проходящие через VPLS кадры Ethernet всегда являются абонентскими. Отметим, что действия на входе и выходе с указывающими сервис тегами являются локальными и ни одно из устройств PE не сигнализирует другим о таких действиях. Это позволяет, например, смешивать и сопоставлять службы с тегами VLAN и без таковых на любой стороне и не передавать через VPLS теги VLAN с локальной значимостью. Указателем сервиса может служить и метка MPLS, поэтому Ethernet PW, определенный в [RFC4448], может применяться соединением для доступа к PE. Инкапсуляция RFC 1483 Bridged PVC также может указывать сервис. На основе ограничения области локальной значимости инкапсуляции краевыми устройствами, можно создать иерархическую модель VPLS для обеспечения возможности создания расширяемых систем VPLS, как описано ниже.

7.2. Обучение VPLS

Обучение выполняется на основе абонентских кадров Ethernet, как определено выше. База пересылки FIB отслеживает отображение адреса абонентского кадра Ethernet на подходящий PW. Определим два режима обучения — квалифицированный и неквалифицированный. Квалифицированное обучение применяется по умолчанию и должно поддерживаться, неквалифицированное обучение является необязательным.

При неквалифицированном обучении все VLAN одного абонента обслуживаются одной VPLS, что означает использование одного широковещательного домена и адресного пространства MAC. Поэтому MAC-адреса должны быть уникальными и не перекрываться в разных VLAN абонента, поскольку в противном случае их не удастся различить в VPLS и это может приводить к потере абонентских кадров. Применение неквалифицированного обучения представляет собой сервис VPLS на основе портов (т. е. абонентские AC не мультиплексируются и весь трафик на физическом порту, который может включать множество абонентских VLAN, отображается на один экземпляр VPLS).

При квалифицированном обучении каждой абонентской VLAN назначается свой экземпляр VPLS, что означает для каждой VLAN абонента отдельный домен широковещания и адресное пространство MAC. Поэтому при квалифицированном обучении MAC-адреса в разных VLAN абонента могут перекрываться, но корректность их обработки будет обеспечиваться использованием в каждой VLAN отдельной FIB, т. е. каждая VLAN абонента будет иметь свое пространство MAC-адресов. Поскольку VPLS по умолчанию передает групповые кадры в широковещательном режиме, квалифицированное обучение сужает область широковещания до одной абонентской VLAN. Квалифицированное обучение может приводить к росту размеров FIB, поскольку в таблицах будут храниться MAC-адреса вместе с тегами VLAN.

Для использования STP с квалифицированным обучением устройства VPLS PE должны быть способны пересылать STP BPDU нужным экземплярам VPLS. В иерархическом варианте VPLS (см. раздел 10) могут добавляться теги обозначения сервиса (Q-in-Q или [RFC4448]), чтобы PE могли однозначно идентифицировать весь абонентский трафик, включая STP BPDU. В базовом варианте VPLS восходящие коммутаторы должны вставлять такие теги обозначения сервиса. Когда порт доступа используется для множества абонентов, должны применяться зарезервированные теги VLAN для абонентских доменов, чтобы передавать трафик STP. Кадры STP инкапсулируются с уникальными для каждого абонента провайдерскими тегами (как и обычный трафик абонентов), а PE просматривают эти теги для передачи таких кадров через соответствующий экземпляр VPLS.

8. Пересылка данных в Ethernet VLAN PW

В этом разделе описано поведение уровня данных для Ethernet VLAN PW в VPLS. Хотя инкапсуляция похожа на описанную в [RFC4448], ниже рассмотрены функции наложения тегов и использования «нормализованных» кадров Ethernet. Обучение выполняется так же, как для Ethernet PW.

8.1. Инкапсуляция VPLS

В VPLS абонентские кадры Ethernet без преамбулы инкапсулируются с заголовком, определенным в [RFC4448]. Определение типов абонентских кадров Ethernet приведено ниже.

  • Если принятый PE кадр имеет инкапсуляцию, которая является частью пользовательского кадра и служит данному PE в качестве обозначения сервиса (т. е. для идентификации конкретного абонента и/или конкретного сервиса для данного абонента), инкапсуляция сохраняется при передаче кадра в VPLS, если не указан необязательный параметр Requested VLAN ID (в этом случае тег VLAN заменяется до отправки кадра в PW).

  • При поступлении в PE кадра с инкапсуляцией без требуемого тега VLAN, в него добавляется пустой (null) тег, если не задан необязательный параметр Requested VLAN ID.

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

Ethernet VLAN PW обеспечивает простой способ сохранить абонентские биты 802.1p.

VPLS может включать оба типа псевдопроводов — Ethernet и Ethernet VLAN. Однако при невозможности поддержки в PE одновременно обоих типов PW следует передавать в неподдерживаемые PW сообщение Label Release с кодом «Unknown FEC», как указано в [RFC3036].

9. Работа VPLS

На рисунке 2 показан пример, где услуги VPLS обеспечиваются между PE1, PE2 и PE3. VPLS объединяет 4 сайта абонента (A1, A2, A3, A4), подключенные через устройства CE1, CE2, CE3 и CE4, соответственно.

Изначально VPLS организуется так, что PE1, PE2 и PE3 имеют полносвязный набор Ethernet PW. Экземпляр VPLS указывается идентификатором AGI. В этом примере PE1 сообщает метку PW 102 устройству PE2 и 103 — устройству PE3, а PE2 сообщает метку 201 устройству PE1 и 203 — устройству PE3.

                                                 -----
                                                /  A1 \
   ----                                    ----CE1    |
  /    \          --------       -------  /     |     |
  | A2 CE2-      /        \     /       PE1     \     /
  \    /   \    /          \---/         \       -----
   ----     ---PE2                        |
               |  Сеть сервис-провайдера  |
                \          /   \         /
         -----  PE3       /     \       /
         |Agg|_/  --------       -------
        -|   |
 ----  / -----  ----
/    \/    \   /    \      CE = краевой маршрутизатор абонента
| A3 CE3    -CE4 A4 |      PE = краевой маршрутизатор провайдера
\    /         \    /      Agg = агрегирование L2
 ----           ----

Рисунок 2. Пример VPLS.


Предположим, что пакет из A1 предназначен для A2. Он приходит на CE1 с MAC-адресом отправителя M1 и MAC-адресом получателя M2. Если PE1 не знает, где находится M2, он использует лавинную рассылку пакета, т. е. передаст его PE2 и PE3. PE2 получит этот пакет с меткой PW 201 и может сделать вывод, что MAC-адрес M1 расположен за PE1, поскольку метка 201 была передана PE1. Поэтому можно связать MAC-адрес M1 с меткой PW 102.

9.1. Старение MAC-адресов

Устройствам PE, изучающим удаленные MAC-адреса, следует иметь механизм старения, позволяющий удалять неиспользуемые записи, связанные с меткой PW. Это важно как для экономии памяти, так и для администрирования. Например, если абонентский сайт A9 отключен, другие PE должны в конце концов «забыть» MAC-адреса этого сайта.

Таймер старения для MAC-адреса M следует сбрасывать при получении пакета с MAC-адресом отправителя M.

10. Иерархическая модель VPLS

Описанное выше решение требует полносвязного набора туннелей LSP между маршрутизаторами PE, участвующими в сервисе VPLS. Для каждой услуги VPLS должно быть организовано n*(n-1)/2 PW между маршрутизаторами PE. Хотя это ведет к издержкам на сигнализацию, реальной проблемой для крупномасштабных систем являются требования репликации пакетов для каждого псевдопровода PW на маршрутизаторе PE. Описанные в этом документе иерархические соединения снижают издержки на сигнализацию и репликацию, позволяя создавать большие системы.

Зачастую сервис-провайдеры размещают небольшое число устройств в зданиях со множеством арендаторов и затем агрегируют их в PE центрального офиса (CO10). В некоторых случаях могут применяться стандартные теги IEEE 802.1q для более простого отображения интерфейсов CE на каналы доступа в VPLS на маршрутизаторах PE.

Часто выгодно распространить методы туннелирования услуг VPLS на домен коммутируемого доступа. Это можно сделать путем реализации устройств доступа как PE и организации PW между ними и другими краевыми устройствами как базового сервиса VPLS. Другим способом является применение [RFC4448] PW или логических интерфейсов Q-in-Q между устройством доступа и выбранными маршрутизаторами PE с поддержкой VPLS. Инкапсуляция Q-in-Q является другой формой туннелирования L2, которая может применяться с сигнализацией MPLS, как описано ниже. В двух приведенных ниже сценариях рассматривается альтернативный подход. PW ядра VPLS (концентратор) дополняются PW доступа (лучи) для формирования 2-уровневой иерархической VPLS (H-VPLS).

Лучевые PW могут быть реализованы с помощью любого туннельного механизма L2 и за счет расширения первого уровня путем включения маршрутизаторов VPLS PE без функций моста. Такие PE будут расширять лучевые PW от коммутатора L2, подключенного к ним через ядро сети оператора, к маршрутизатору VPLS PE с функциями моста, служащему концентратором PW. Мы опишем также участие требуемых для VPLS узлов и простых CE без поддержки MPLS в работе иерархической VPLS.

В оставшейся части документа устройства с поддержкой функций моста обозначаются MTU-s, а PE без функций моста — PE-r. Устройства с поддержкой функций моста и маршрутизатора обозначаются PE-rs.

10.1. Иерархическая связность

В этом параграфе описана модель соединений в виде концентратора с лучами (hub and spoke — звезда) и требования к мостам и устройствам MTU-s для поддержки лучевых соединений.

10.1.1. Лучевая связность для устройств с функциями моста

На рисунке 3 к устройству MTU-s подключены три абонентских сайта через устройства CE-1, CE-2, CE-3. MTU-s имеет одно соединение (PW-1) с PE1-rs, а это устройство подключено к полносвязному базовому сервису VPLS. Для каждого сервиса VPLS организуется один лучевой PW между MTU-s и PE-rs на базе [RFC4447]. В отличие от традиционных PW, завершающихся на физическом (или логическом с тегом VLAN) порту, лучевой PW завершается на экземпляре виртуального коммутатора (VSI11, см [L2FRAME]) на устройствах MTU-s и PE-rs.

                                                      PE2-rs
                                                    +--------+
                                                    |        |
                                                    |   --   |
                                                    |  /  \  |
CE-1                                                |  \S /  |
 \                                                  |   --   |
  \                                                 +--------+
   \   MTU-s                          PE1-rs        /   |
    +--------+                      +--------+     /    |
    |        |                      |        |    /     |
    |   --   |      PW-1            |   --   |---/      |
    |  /  \--|- - - - - - - - - - - |  /  \  |          |
    |  \S /  |                      |  \S /  |          |
    |   --   |                      |   --   |---\      |
    +--------+                      +--------+    \     |
     /                                             \    |
   ----                                             +--------+
  |Agg |                                            |        |
   ----                                             |  --    |
  /    \                                            | /  \   |
CE-2  CE-3                                          | \S /   |
                                                    |  --    |
                                                    +--------+
                                                      PE3-rs
    Agg = агрегирование L2
    --
   /  \
   \S / = экземпляр виртуального коммутатора
    --

Рисунок 3. Пример иерархической модели VPLS.


MTU-s и PE-rs рассматривают каждое лучевое соединение подобно AC в сервисе VPLS. Метка PW служит для привязки трафика луча к экземпляру VPLS.

10.1.1.1. Работа MTU-s

MTU-s определяется как устройство, поддерживающее функциональность коммутатора L2 и все обычные функции обучения и репликации кадров во все порты, включая луч, рассматриваемый как виртуальный порт. Пакеты для неизвестных получателей реплицируются во все обслуживаемые порты, включая порт луча. После изучения MAC-адресов трафик между CE1 и CE2 будет локально коммутироваться MTU-s, снижая загрузку луча в направлении PE-rs. Аналогично, трафик между CE1 или CE2 и любым удаленным адресатом коммутируется напрямую в луч и передается PE-rs через PW «точка-точка».

Поскольку MTU-s поддерживает функции моста, требуется лишь один псевдопровод PW на экземпляр VPLS при любом числе соединений доступа в одном сервисе VPLS. Это также снижает издержки на сигнализацию между MTU-s и PE-rs.

Если устройство MTU-s напрямую подключено к PE-rs, в луче могут применяться другие методы инкапсуляции (например, Q-in-Q).

10.1.1.2. Работа PE-rs

PE-rs представляет собой устройство, поддерживающее все функции моста для сервиса VPLS, а также маршрутизацию и инкапсуляцию MPLS, т. е. все описанные выше функции для базового сервиса VPLS.

Работа PE-rs не зависит от типа устройства на другой стороне луча. Таким образом, луч от MTU-s рассматривается как виртуальный порт и PE-rs будет коммутировать трафик между лучевым PW, псевдопроводами концентратора PW и устройствами AC после изучения MAC-адресов.

10.1.2. Преимущества лучевых соединений

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

  • Снимается необходимость организации полносвязной сети туннелей и PW для всех устройств, участвующих в сервисе VPLS.

  • Снижаются издержки на сигнализацию за счет снижения числа PW, требуемых для сервиса VPLS.

  • Узловое обнаружение сегментов VPLS. MTU-s нужно знать лишь узел PE-rs, хотя устройство участвует в сервисе VPLS, охватывающем множество устройств. С другой стороны, каждое устройство VPLS PE-rs должно знать о всех других VPLS PE-rs, а также о всех локально подключенных устройствах MTU-s и PE-r.

  • Добавление других сайтов требует настройки новых MTU-s, но не требует какого-либо обеспечения для имеющихся в данном сервисе устройств MTU-s.

  • Иерархические соединения могут служить для организации сервиса VPLS через множество доменов сервис-провайдеров, как описано ниже.

Отметим, что по мере роста числа устройств, участвующих в VPLS, растет и число устройств, в которых требуется поддержка обучения и репликации.

10.1.3. Лучевые соединения для устройств, не являющихся мостами

В некоторых случаях поддерживающие функции мостов устройства PE-rs могут отсутствовать в сети или устройства PE-r могут быть уже установлены. В этом параграфе описано, как устройства PE-r, не поддерживающие функций мостов VPLS, могут применяться для сервиса VPLS.

На рисунке 4 три абонентских сайта (CE-1, CE-2, CE-3) подключены к VPLS через устройство PE-r. Для каждого устройства подключения, участвующего в сервисе VPLS, маршрутизатор PE-r создает PW «точка-точка», завершающиеся на VSI маршрутизатора PE1-rs.

                                                      PE2-rs
                                                    +--------+
                                                    |        |
                                                    |   --   |
                                                    |  /  \  |
CE-1                                                |  \S /  |
 \                                                  |   --   |
  \                                                 +--------+
   \   PE-r                           PE1-rs        /   |
    +--------+                      +--------+     /    |
    |\       |                      |        |    /     |
    | \      |      PW-1            |   --   |---/      |
    |  ------|- - - - - - - - - - - |  /  \  |          |
    |   -----|- - - - - - - - - - - |  \S /  |          |
    |  /     |                      |   --   |---\      |
    +--------+                      +--------+    \     |
     /                                             \    |
   ----                                           +--------+
  | Agg|                                          |        |
   ----                                           |  --    |
  /    \                                          | /  \   |
CE-2  CE-3                                        | \S /   |
                                                  |  --    |
                                                  +--------+
                                                    PE3-rs

Рисунок 4. Пример иерархической VPLS с лучами без мостов.


PE-r является устройством, поддерживающим маршрутизацию, но не поддерживающим функции моста. Однако оно может создавать PW между собой и PE-rs. Для каждого порта, поддерживаемого в сервисе VPLS, организуется PW от PE-r к PE-rs. После организации PW функции обучения и репликации на PE-r не нужны. Весь трафик, полученный на любом из AC, передается в PW. Аналогично, весь трафик, полученный на PW, передается в AC, где завершается PW. Таким образом, трафик от CE1, адресованный CE2, коммутируется на PE1-rs, а не на PE-r.

Отметим, что в случае использования устройствами PE-r провайдерских VLAN (P-VLAN12) в качестве демультиплексора вместо PW, маршрутизатор PE1-rs может работать с ними и отображать эти «каналы» в домен VPLS для организации функций моста между ними.

Эта модель отличается большими издержками по сравнению с моделью на основе лучей MTU-s, поскольку требуется PW для каждого устройства AC, участвующего в сервисе, в отличие от одного PW на сервис (независимо от числа AC) при использовании MTU-s. Однако этот подход обладает преимуществом за счет предоставления услуг VPLS вместе с маршрутизируемым сервисом Internet без добавления нового MTU-s.

10.2. Избыточные лучевые соединения

Очевидной слабостью описанной модели «hub and spoke» является то, что MTU-s имеют одно соединение с PE-rs. В случае отказа соединения или PE-rs устройство MTU-s полностью теряет связь с сетью.

В этом параграфе описан способ организации резервных соединений для предотвращения потери связности с MTU-s. Описанный механизм подходит как для MTU-s, так и для PE-r.

10.2.1. Двудомный MTU-s

Для защиты от отказа соединений PW или устройств PE-rs применяются двудомные MTU-s или PE-r с подключением к двум устройствам PE-rs, которые должны относиться к одному экземпляру сервиса VPLS.

На рисунке 5 два абонентских сайта подключены через CE-1 и CE-2 к устройству MTU-s, которое организует до двух PW (один для PE1-rs, другой для PE3-rs) для каждого экземпляра VPLS. Один из двух PW назначается основным и работает в обычных условиях, а другой служит резервным и поддерживается в режиме ожидания (standby). MTU-s согласует метки PW для основного и резервного псевдопровода, но не использует резервный PW до возникновения отказа на основном PW. Выбор первичного и вторичного луча выходит за рамки этой спецификации. Например, одним из вариантов может быть экземпляр STP, работающий между MTU-s и двумя узлами PE-rs. Другие методы требуют настройки.

                                                      PE2-rs
                                                    +--------+
                                                    |        |
                                                    |   --   |
                                                    |  /  \  |
CE-1                                                |  \S /  |
  \                                                 |   --   |
   \                                                +--------+
    \  MTU-s                          PE1-rs        /   |
    +--------+                      +--------+     /    |
    |        |                      |        |    /     |
    |   --   |   Основной PW        |   --   |---/      |
    |  /  \  |- - - - - - - - - - - |  /  \  |          |
    |  \S /  |                      |  \S /  |          |
    |   --   |                      |   --   |---\      |
    +--------+                      +--------+    \     |
      /      \                                     \    |
     /        \                                     +--------+
    /          \                                    |        |
   CE-2         \                                   |  --    |
                 \     Вторичный PW                 | /  \   |
                  - - - - - - - - - - - - - - - - - | \S /   |
                                                    |  --    |
                                                    +--------+
                                                      PE3-rs

Рисунок 5. Пример двудомного MTU-s.


10.2.2. Обнаружение отказов и восстановление

MTU-s следует контролировать использование лучей к устройствам PE-rs. Если узлами служат PW, для согласования меток PW применяется протокол LDP и сообщения hello, используемые в сессиях LDP, можно применять для детектирования отказа основного PW. Использование других механизмов, способных детектировать отказы быстрее, выходит за рамки этой спецификации.

При отказе основного PW устройство MTU-s незамедлительно переключается на резервный PW. В этот момент PE3-rs, завершающий резервный PW, начинает изучение MAC адресов на лучевом PW. Все другие узлы PE-rs в сети считают, что CE-1 и CE-2 расположены за PE1-rs и могут продолжать передачу трафика PE1-rs, пока не узнают, что эти устройства находятся за PE3-rs. Процесс отмены обучения (unlearning) может занять много времени, что может оказать негативное влияние на связность протоколов верхних уровней с CE1 и CE2. Для более быстрого схождения устройство PE3-rs, где активируется вторичный PW, может передать сообщение для сброса адресов (как описано в параграфе 6.2), используя MAC List TLV (см. раздел 6), всем узлам PE-rs. При получении этого сообщения узлы PE-rs будут сбрасывать MAC-адреса, связанные с этим экземпляром VPLS.

10.3. Многодоменный сервис VPLS

Иерархия может также применяться для организации крупномасштабного сервиса VPLS в одном домене или сервиса, охватывающего множество доменов, без необходимости организации полносвязных соединений между всеми поддерживающими VPLS устройствами. Две полносвязных сети VPLS можно соединить вместе через один туннель LSP между «граничными» устройствами VPLS. Для объединения двух доменов организуется один лучевой PW на сервис VPLS.

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

Это создает трехуровневую иерархическую модель, включающую лучевую (hub-and-spoke) топологию между устройствами MTU-s и PE-rs, полносвязную топологию между PE-rs и полносвязную сеть междоменных лучей между краевыми устройствами PE-rs.

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

11. Иерархическая модель VPLS с сетями доступа Ethernet

В этом параграфе иерархическая модель расширена для включения сетей доступа Ethernet. Модель сохраняет иерархическую архитектуру, описанную выше, с использованием полносвязных соединений между устройствами PE-rs, однако не задается ограничений для сетей доступа Ethernet (например, топология между MTU-s и PE-rs не обязательно «звезда»).

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

Один из подходов к туннелированию абонентского трафика Ethernet через сеть доступа Ethernet заключается в добавлении тега VLAN к абонентским данным (они уже могут иметь свой тег). Дополнительный тег называют P-VLAN. Внутри сети оператора каждая сеть P-VLAN указывает абонента или, более точно, экземпляр VPLS для данного абонента. Поэтому имеется взаимно-однозначное соответствие между P-VLAN и экземпляром VPLS. В этой модели устройства MTU-s должны быть способны добавлять дополнительный тег P-VLAN к немультиплексируемым AC, где абонентские VLAN не служат указателем сервиса. Эта функциональность описана в [802.1ad].

Если абонентские VLAN должны служить указателями сервиса (например, AC является мультиплексируемым портом), устройства MTU-s должны обеспечивать трансляцию абонентских VLAN (C-VLAN13) в P-VLAN или вталкивание дополнительного тега P-VLAN для предотвращения проблем, связанных с использованием перекрывающихся VLAN разными абонентами. Поэтому MTU-s в этой модели могут рассматриваться как типичные мосты с поддержкой такой дополнительной возможности. Эта функциональность описана в [802.1ad].

Устройства PE-rs должны быть способны выполнять функции моста через стандартные порты Ethernet в направлении сети доступа, а также через PW в направлении ядра сети. В этой модели для PE-rs может потребоваться запуск протокола STP в направлении сети доступа в дополнение к «расщеплению горизонта» для ядра MPLS. PE-rs должны отображать P-VLAN на экземпляр VPLS и связанные с ним PW (и наоборот).

Детали, относящиеся к операциям моста для MTU-s и PE-rs (например, формат инкапсуляции для сообщений Q-in-Q, обработка протокола управления абонентских сетей Ethernet и т. п.), выходят за рамки этого документа и описаны в [802.1ad]. Тем не менее, важной частью является взаимодействие между модулем моста и псевдопроводами MPLS/IP PW в устройствах PE-rs, которое не отличается от обычного поведения VPLS.

11.1. Расширяемость

Поскольку каждая P-VLAN соответствует экземпляру VPLS, общее число поддерживаемых экземпляров VPLS ограничено значением 4K. P-VLAN служит локальным обозначением сервиса в сети оператора, которое вырезается при отображении на PW в экземпляре VPLS. Поэтому ограничение в 4K применимо лишь в сети доступа Ethernet (остров Ethernet), а не во всей сети. Сеть SP состоит из ядра MPLS/IP, соединяющего множество островов Ethernet. Поэтому число экземпляров VPLS может расти с ростом числа островов Ethernet (сети доступа в городе могут быть представлены одним или множеством островов).

11.2. Двудомные устройства и восстановление при отказах

В этой модели MTU-s может быть двудомным для различных устройств (агрегаторы и устройства PE-rs). Защита от отказов для узлов доступа в сеть и каналов может быть обеспечена за счет применения STP на каждом острове. STP каждого из островов не зависит от других островов и не взаимодействует с ними. Если остров имеет более одного PE-rs, между этими PE-rs используется полносвязная сеть PW для передачи пакетов SP BPDU с острова. На уровне P-VLAN протокол STP будет назначать одно устройство PE-rs для передачи трафика через ядро. Защита от петель через ядро выполняется с использованием «расщепления горизонта», а защита от отказов в ядре — с помощью стандартной перемаршрутизации IP/MPLS.

12. Участники работы

Loa Andersson, TLA
Ron Haberman, Alcatel-Lucent
Juha Heinanen, Independent
Giles Heron, Tellabs
Sunil Khandekar, Alcatel-Lucent
Luca Martini, Cisco
Pascal Menezes, Independent
Rob Nath, Alcatel-Lucent
Eric Puetz, AT&T
Vasile Radoaca, Independent
Ali Sajassi, Cisco
Yetik Serbest, AT&T
Nick Slabakov, Juniper
Andrew Smith, Consultant
Tom Soon, AT&T
Nick Tingle, Alcatel-Lucent

13. Благодарности

Спасибо Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel Halpern, Bill Hong, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov Rekhter, Sasha Vainshtein и Du Wenhua за их полезные замечания.

Спасибо также Rajiv Papneja (ISOCORE), Winston Liu (Ixia) и Charlie Hundall за указание проблем в черновых вариантах, связанных с тестированием интероперабельности.

Спасибо Ina Minei, Bob Thomas, Eric Gray и Dimitri Papadimitriou за техническое рецензирование документа.

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

Более полное рассмотрение вопросов безопасности, связанных с L2VPN, приведено в [RFC4111]. Незащищенные услуги VPLS имеют некоторые уязвимости, создающие риски для сетей абонентов и провайдеров. Большинства проблем безопасности можно избежать путем реализации соответствующих мер защиты. Некоторые из них можно предотвратить с помощью имеющихся протоколов.

  • Уровень данных

    • Изоляция трафика между доменами VPLS гарантируется использованием на уровне VPLS своей таблицы L2 FIB и своих PW.

    • Абонентский трафик, состоящий из кадров Ethernet, передается через VPLS без изменений. Если нужна защита, абонентский трафик следует шифровать и/или аутентифицировать до отправки в сеть сервис-провайдера.

    • Предотвращение широковещательных штормов может обеспечиваться использованием маршрутизаторов в качестве устройств CPE или правилами для объема широковещательного трафика от абонента.

  • Уровень управления

    • Следует применять методы защиты LDP (аутентификация), как описано в [RFC3036]. Это будет предотвращать нарушения работы PE в VPLS с помощью подставных сообщений.

  • Атаки на отказ в обслуживании

    • Следует реализовать те или иные меры по ограничению числа MAC-адресов (на сайт и VPLS), которым PE может обучиться.

15. Взаимодействие с IANA

Поле типа в MAC List TLV определенно со значением 0x404 в параграфе 6.2.1.

16. Литература

16.1. Нормативные документы

[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, «Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)», RFC 4447, April 2006.

[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, «Encapsulation Methods for Transport of Ethernet over MPLS Networks», RFC 4448, April 2006.

[802.1D-ORIG] Original 802.1D — ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 «MAC Bridges».

[802.1D-REV] 802.1D — «Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Common specifications — Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e.» ISO/IEC 15802-3: 1998.

[802.1Q] 802.1Q — ANSI/IEEE Draft Standard P802.1Q/D11, «IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks», July 1998.

[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, «LDP Specification», RFC 3036, January 2001.

[RFC4446] Martini, L., «IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)», BCP 116, RFC 4446, April 2006.

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

16.2. Дополнительная литература

[RFC4364] Rosen, E. and Y. Rekhter, «BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4364, February 2006.

[RADIUS-DISC] Heinanen, J., Weber, G., Ed., Townsley, W., Booth, S., and W. Luo, «Using Radius for PE-Based VPN Discovery», Work in Progress, October 2005.

[BGP-DISC] Ould-Brahim, H., Ed., Rosen, E., Ed., and Y. Rekhter, Ed., «Using BGP as an Auto-Discovery Mechanism for Network-based VPNs», Work in Progress14, September 2006.

[L2FRAME] Andersson, L. and E. Rosen, «Framework for Layer 2 Virtual Private Networks (L2VPNs)», RFC 4664, September 2006.

[L2VPN-REQ] Augustyn, W. and Y. Serbest, «Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks», RFC 4665, September 2006.

[RFC4111] Fang, L., «Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)», RFC 4111, July 2005.

[802.1ad] «IEEE standard for Provider Bridges», Work in Progress15, December 2002.

Приложение A. Сигнализация VPLS с использованием PWid FEC

Этот раздел был сохранен потому, что остаются реализации, применяющие эту версию сигнализации для VPLS.

Сигнальная информация VPLS передается в сообщениях Label Mapping, отправляемых без запроса в нисходящем направлении, и содержащих приведенную ниже структуру PWid FEC TLV.

Поля PW, C, PW Info Length, Group ID и Interface parameters определены в [RFC4447].

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    PW TLV     |C|         PW Type             |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Group ID                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        PWID                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Interface parameters                    |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Мы используем тип Ethernet PW для указания PW, которые передают трафик при многоточечной связности.

В VPLS мы используем идентификатор PWID (который при использовании обобщенного PWid FEC будет заменяться более обобщенным идентификатором AGI, для расширения области действия VPLS), указывающий сегмент эмулируемой ЛВС. Отметим, что PWID в соответствии с [RFC4447] является идентификатором сервиса, указывающим службу, эмулирующую виртуальный канал «точка-точка». В VPLS идентификатор PWID является единственным указателем сервиса, поэтому он имеет глобальную значимость для всех PE, вовлеченных в экземпляр VPLS16.


Адреса авторов

Marc Lasserre

Alcatel-Lucent

EMail: mlasserre@alcatel-lucent.com

Vach Kompella

Alcatel-Lucent

EMail: vach.kompella@alcatel-lucent.com

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru


Полное заявление авторских прав

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Virtual Private LAN Service — услуги виртуальной частной ЛВС.

2Transparent LAN Services — услуги «прозрачной ЛВС».

3Provider Edge.

4Label Distribution Protocol.

5Metropolitan Area Network.

6Wide Area Network.

7Bridge PDU — блок данных протокола мостов.

8Maximum Transmission Unit.

9Предложено исключить в этом предложении указание конкретного сайта A. См. https://www.rfc-editor.org/errata/eid4834. Прим. перев.

10Central Office.

11Virtual switch instance.

12Provider VLAN.

13Customer VLAN.

14Работа опубликована в RFC 5195. Прим. перев.

15Стандарт принят и включен в IEEE Std 802.1Q-2011.

16В оригинале этот абзац содержит ошибки. См. https://www.rfc-editor.org/errata/eid4144. Прим. перев.




RFC 4760 Multiprotocol Extensions for BGP-4

Network Working Group                                       T. Bates
Request for Comments: 4760                             Cisco Systems
Obsoletes: 2858                                           R. Chandra
Category: Standards Track                              Sonoa Systems
                                                             D. Katz
                                                          Y. Rekhter
                                                    Juniper Networks
                                                        January 2007

 

Многопротокольные расширения для BGP-4

Multiprotocol Extensions for BGP-4

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The IETF Trust (2007).

Тезисы

В этом документе определяется расширение протокола BGP-4, позволяющее передавать информацию для различных протоколов сетевого уровня (например, IPv6, IPX, L3VPN и т. п.). Расширение обеспечивает обратную совместимость – маршрутизаторы, поддерживающие это расширение, смогут нормально работать с маршрутизаторами, которые его не поддерживают.

1. Введение

Только три компоненты информации, передаваемой с помощью BGP-4 [BGP-4], непосредственно связаны с IPv4: (a) атрибут NEXT_HOP (указывается адресом IPv4), (b) AGGREGATOR (содержит адрес IPv4) и (c) NLRI (выражается префиксом адреса IPv4). В этом документе предполагается, что любой узел BGP (включая те, которые поддерживают описанное здесь расширение) имеет адрес IPv4 (который будет вместе с другими параметрами использоваться в атрибуте AGGREGATOR). Следовательно, для того, чтобы BGP-4 поддерживал маршрутизацию для множества протоколов сетевого уровня, в BGP-4 требуется добавить только два элемента: (a) возможность связывания отдельного протокола сетевого уровня с информацией о следующем интервале (next hop) и (b) возможность связывания протокола сетевого уровня с NLRI. Для идентификации протоколов сетевого уровня данный документ использует значение Address Family (семейство адресов), определенное в [IANA-AF], и Subsequent Address Family1 (описано в этом документе).

Легко увидеть, что информация о следующем интервале (значение атрибута NEXT_HOP) имеет смысл (и необходима) только в комбинации с анонсами доступных адресатов – в комбинации же с анонсами недоступных адресатов (отзыв маршрутов) информация о следующем интервале не имеет смысла. Это позволяет предположить, что анонсирование доступных адресатов следует объединять с анонсированием следующего интервала, который будет использоваться для этих адресатов, и анонсирование доступных адресатов следует отделить от анонсирования недоступных адресатов.

Для обеспечения совместимости с предыдущими спецификациями и упрощения перехода к поддержке многопротокольного расширения в BGP-4 в данном документе используются два новых атрибута – MP_REACH_NLRI2 и MP_UNREACH_NLRI3. Первый атрибут (MP_REACH_NLRI) используется для передачи набора доступных адресов с информацией о следующем интервале, который будет использоваться для пересылки по этим адресам. Второй атрибут (MP_UNREACH_NLRI) служит для передачи наборов недоступных адресатов. Оба эти атрибута являются необязательными и непереходными. Таким образом, узел BGP, не поддерживающий многопротокольное расширение, просто будет игнорировать содержащуюся в этих атрибутах информацию и не станет передавать ее другим узлам BGP.

2. Описание требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

3. MP_REACH_NLRI (тип 14)

Этот необязательный и нетранзитивный атрибут может использоваться с двумя целями:

  1. анонсирование партнеру возможного маршрута;

  2. обеспечение маршрутизатору возможности анонсирования адреса сетевого уровня маршрутизатора, который следует использовать как следующий интервал (next hop) на пути к адресату, указанному в поле NLRI4 атрибута MP_NLRI.

Формат представления атрибута показан на рисунке.

+--------------------------------------------------+
| Address Family Identifier (2 октета)             |
+--------------------------------------------------+
| Subsequent Address Family Identifier (1 октет)   |
+--------------------------------------------------+
| Length of Next Hop Network Address (1 октет)     |
+--------------------------------------------------+
| Network Address of Next Hop (перемен.)           |
+--------------------------------------------------+
| Резерв (1 октет)                                 |
+--------------------------------------------------+
| Network Layer Reachability Information (перемен.)|
+--------------------------------------------------+

Назначение полей описано ниже.

Address Family Identifier (AFI) – идентификатор семейства адресов

Это поле в комбинации с полем Subsequent Address Family Identifier идентифицирует набор протоколов сетевого уровня, к которым должен относится адрес, передаваемый в поле Next Hop, способ представления адреса следующего интервала и семантику последующих данных NLRI. Если значение Next Hop разрешено для нескольких протоколов сетевого уровня, представление Next Hop должно обеспечивать способ определения протокола сетевого уровня.

Определенные к настоящему времени значения поля AFI заданы в реестре IANA Address Family Numbers [IANA-AF].

Subsequent Address Family Identifier (SAFI) – дополнительный идентификатор семейства адресов

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

Length of Next Hop Network Address – размер адреса следующего интервала

1-октетное поле, указывающее размер поля Network Address of Next Hop в октетах.

Network Address of Next Hop – сетевой адрес для следующего интервала

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

Резерв

Это 1-октетное поле должно устанавливаться в 0, а при получении значение поля следует игнорировать.

Network Layer Reachability Information (NLRI) – информация о доступности на сетевом уровне

Поле переменной длины, содержащее список NLRI для возможных маршрутов, которые будут анонсироваться этим атрибутом. Семантика NLRI определяется комбинацией значений <AFI, SAFI> в данном атрибуте.

Если поле Subsequent Address Family Identifier содержит одно из значений, определенных в данном документе, каждое значение NLRI кодируется в соответствии с параграфом 5. Представление NLRI данного документа.

Информация о следующем интервале (next hop), передаваемая в атрибуте пути MP_REACH_NLRI, определяет адрес сетевого уровня маршрутизатора, который следует использовать в качестве следующего этапа пересылки адресатам, указанным в атрибуте MP_NLRI сообщения UPDATE.

Правила для информации о следующем интервале совпадают с правилами для информации, передаваемой в атрибуте BGP NEXT_HOP (см. параграф 5.1.3 документа [BGP-4]).

Сообщение UPDATE, содержащее MP_REACH_NLRI, должно также включать атрибуты ORIGIN и AS_PATH (как для EBGP, так и для IBGP). Более того, в обменах IBGP такие сообщения должны также включать атрибут LOCAL_PREF.

В сообщения UPDATE, не содержащие NLRI, кроме значения в атрибуте MP_REACH_NLRI, не следует включать атрибут NEXT_HOP. Если такое сообщение содержит атрибут NEXT_HOP, получившему это сообщение узлу BGP следует игнорировать данный атрибут.

В сообщение UPDATE не следует включать один префикс (одну пару <AFI, SAFI>) более одного раза для полей WITHDRAWN ROUTES, NLRI, MP_REACH_NLRI и MP_UNREACH_NLRI. Обработка сообщений UPDATE с дубликатами префиксов не определена.

4. MP_UNREACH_NLRI (тип 15)

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

Формат атрибута показан на рисунке.

+-----------------------------------------------+
| Address Family Identifier (2 октета)          |
+-----------------------------------------------+
| Subsequent Address Family Identifier (1 октет)|
+-----------------------------------------------+
| Withdrawn Routes (перемен.)                   |
+-----------------------------------------------+

Назначение полей атрибута описано ниже.

Address Family Identifier (AFI) – идентификатор семейства адресов

Это поле в комбинации с полем Subsequent Address Family Identifier идентифицирует набор протоколов сетевого уровня, к которым должен относится адрес, передаваемый в поле Next Hop, способ представления адреса следующего интервала и семантику последующих данных NLRI. Если значение Next Hop разрешено для нескольких протоколов сетевого уровня, представление Next Hop должно обеспечивать способ определения протокола сетевого уровня5.

Определенные к настоящему времени значения поля AFI заданы в реестре IANA Address Family Numbers [IANA-AF].

Subsequent Address Family Identifier (SAFI) – дополнительный идентификатор семейства адресов

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

Withdrawn Routes NLRI – отзываемые маршруты

Поле переменной длины, содержащее значения NLRI для отзываемых маршрутов. Семантика NLRI определяется комбинацией значений <AFI, SAFI> в атрибуте.

При установке в поле Subsequent Address Family Identifier одного из определенных в данном документе значений, каждое поле NLRI кодируется в соответствии с параграфом 5. Представление NLRI.

Сообщение UPDATE, содержащее MP_UNREACH_NLRI, может не включать других атрибутов пути.

5. Представление NLRI

Информация о доступности на сетевом уровне (NLRI) представляется в форме одной или множества пар <length, prefix>, показанных на рисунке.

+------------------+
| Length (1 октет) |
+------------------+
| Prefix (перемен.)|
+------------------+

Назначение каждого поля пар описано ниже.

  1. Length — размер

    Поле Length указывает размер адресного префикса в битах. Нулевой размер показывает, что префикс соответствует всем (как указано для данного семейства) адресам (т. е., сам префикс содержит 0 октетов).

  2. Prefix — префикс

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

6. Дополнительный идентификатор семейства адресов

Этот документ определяет следующие значения поля Subsequent Address Family Identifier для атрибутов MP_REACH_NLRI и MP_UNREACH_NLRI:

1 – NLRI используется для unicast-пересылки (по конкретному адресу);

2 – NLRI используется для групповой пересылки.

Реализация может поддерживать все или часть определенных в этом документе значений SAFI или не поддерживать их совсем.

7. Обработка ошибок

Если узел BGP получает от соседа сообщение UPDATE с атрибутом MP_REACH_NLRI или MP_UNREACH_NLRI и видит, что атрибут указан некорректно, он должен удалить все маршруты BGP, полученные от данного соседа, в которых значения AFI/SAFI совпадают с одним из содержащихся в некорректном атрибуте MP_REACH_NLRI или MP_UNREACH_NLRI. До завершения сеанса BGP, в котором получено сообщение UPDATE, узлу следует игнорировать все последующие маршруты с данным AFI/SAFI, принятые в этой сессии.

В дополнение к сказанному узел может прервать сеанс BGP, в котором было получено сообщение UPDATE. Сессию следует прерывать с помощью сообщения NOTIFICATION, содержащего код/субкод ошибки Update Message Error/Optional Attribute Error.

8. Использование анонсирования возможностей BGP

Узлу BGP, использующему описанное здесь расширение, следует применять процедуры анонсирования возможностей (Capability Advertisement) [BGP-CAP] для определения возможности использования данного расширения при работе с тем или иным партнером.

Для полей дополнительного параметра Capabilities следует установить приведенные здесь значения. Поле Capability Code должно содержать значение 1 (указывает на Multiprotocol Extensions). Поле Capability Length должно иметь значение 4. Формат поля Capability Value показан на рисунке.

0       7      15      23      31
+-------+-------+-------+-------+
|      AFI      | Res.  | SAFI  |
+-------+-------+-------+-------+

Компоненты этого поля описаны ниже.

AFI — идентификатор семейства адресов (16 битов), представляемый так же, как для Multiprotocol Extensions;

Res. — резервное поле (8 битов); отправителю следует устанавливать для этого поля значение 07, а получателю – игнорировать его;

SAFI – дополнительный идентификатор семейства адресов (8 битов), представляемый так же, как для Multiprotocol Extensions.

Узел, поддерживающий множество пар <AFI, SAFI>, включает их как множество возможностей в дополнительный параметр Capabilities.

Чтобы организовать двухсторонний обмен маршрутной информацией для той или иной пары <AFI, SAFI> между двумя узлами BGP, каждый из этих узлов должен анонсировать партнеру (с помощью механизма Capability Advertisement) возможность поддержки маршрутов для соответствующей пары <AFI, SAFI>.

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

Как указано выше, атрибуты MPL_REACH_NLRI и MP_UNREACH_NLRI содержат поле дополнительного идентификатора семейства адресов (SAFI). Пространство имен SAFI определено в данном документе. IANA поддерживает и регистрирует значения SAFI, как описано ниже.

  • значения 1 и 2 выделены в настоящем документе;
  • значение 3 является резервным; оно было выделено в RFC 2858 для целей, не получивших распространения, поэтому данный документ отменяет это выделение;
  • значения от 5 до 63 выделяются IANA с использованием процедуры стандартизации (Standards Action), определенной в [RFC2434], или процедуры предварительного распределения (Early IANA Allocation), определенной в [RFC4020];
  • SAFI из диапазона 67 — 127 распределяются IANA в порядке поступления запросов (процедура First Come First Served), как описано в RFC 2434;
  • значения 0 и 255 являются резервными;
  • значения от 128 до 240 являются часть выделенного ранее блока для приватного использования; на момент принятия данного документа неиспользуемые значения были предоставлены IANA руководителем Routing Area; во избежание конфликтов эти значения (130, 131, 135 — 139 и 141 — 240) рассматриваются, как резервные;
  • значения от 241 до 254 выделены для приватного использования и не распределяются IANA.

10. Сравнение с RFC 2858

Этот документ согласует использование информации о следующем интервале с информацией, передаваемой в атрибуте пути BGP NEXT_HOP.

Из документа удалено определение SAFI 3 и отменено использование SAFI 3.

В этом документе изменено распределение пространства значений SAFI. В частности, RFC 2858 определял значения SAFI от 128 до 240 для приватного использования. В данном документе распределение этого блока передается IANA и неиспользуемые значения 130, 131, 135 — 139 и 141 — 240 из этого диапазона следует рассматривать в качестве резервных.

В этом документе поле Number of SNPA8 переведено в состояние резервного, а последующие поля атрибута MP_REACH_NLRI, связанные с SNPA, удалены.

11. Сравнение с RFC 2283

Этот документ ограничивает атрибут MP_REACH_NLRI передачей единственного экземпляра <AFI, SAFI, Next Hop Information, …>.

Этот документ ограничивает атрибут MP_UNREACH_NLRI передачей единственного экземпляра <AFI, SAFI, …>.

Этот документ разъясняет обработку сообщений UPDATE, не содержащих NLRI, кроме значения в атрибуте MP_REACH_NLRI.

Этот документ разъясняет обработку ошибок при наличии атрибутов MP_REACH_NLRI или MP_UNREACH_NLRI.

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

Этот документ включает раздел 9. Согласование с IANA.

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

Данное расширение не оказывает влияния на вопросы безопасности, связанные с протоколом BGP.

13. Благодарности

Авторы благодарят членов рабочей группы IDR за обзор и комментарии к документу.

14. Нормативные документы

[BGP-CAP] Chandra, R. and J. Scudder, «Capabilities Advertisement with BGP-4», RFC 3392, November 2002.

[BGP-4] Rekhter, Y., Li, T., and S. Hares, «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[IANA-AF] «Address Family Numbers», Reachable from http://www.iana.org/numbers.html

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

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC4020] Kompella, K. and A. Zinin, «Early IANA Allocation of Standards Track Code Points», BCP 100, RFC 4020, February 2005.

Адреса авторов

Tony Bates

Cisco Systems, Inc.

EMail: tbates@cisco.com

Ravi Chandra

Sonoa Systems

EMail: rchandra@sonoasystems.com

Dave Katz

Juniper Networks, Inc.

EMail: dkatz@juniper.net

Yakov Rekhter

Juniper Networks, Inc.

EMail: yakov@juniper.net


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Дополнительное семейство адресов.

2Multiprotocol Reachable NLRI

3Multiprotocol Unreachable NLRI

4Network Layer Reachability Information – информация о доступности на сетевом уровне.

5Yakov Rekhter предложил иную редакцию этого абзаца (см. http://rfc-editor.org/errata_search.php?eid=1573). «Это поле в комбинации с полем Subsequent Address Family Identifier определяет семантику информации NLRI для отзываемых этим атрибутом маршрутов.» Прим. перев.

7Отметим, что если это поле не сбрасывать в 0, могут возникать проблемы с получателями, которые не будут игнорировать значение поля. Кроме того, могут возникать проблемы при переопределении этого поля.

8Subnetwork Points of Attachment — точки подключения подсетей. Прим. перев.

9В настоящее время этот документ утратил силу и заменен RFC 5492. Прим. перев.

11В настоящее время этот документ утратил силу и заменен RFC 5226. Прим. перев.

Сохранить