RFC 5195 BGP-Based Auto-Discovery for Layer-1 VPNs

image_print
Network Working Group                                 H. Ould-Brahim
Request for Comments: 5195                                  D. Fedyk
Category: Standards Track                                     Nortel
                                                          Y. Rekhter
                                                    Juniper Networks
                                                           June 2008

Автоматическое детектирование Layer-1 VPN на основе BGP

BGP-Based Auto-Discovery for Layer-1 VPNs

PDF

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

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

Тезисы

Целью настоящего документа является определение механизма автоматического детектирования Layer-1 VPN (L1VPN) на основе протокола BGP. Механизм автоматического детектирования для L1VPN позволяет устройствам сети провайдера автоматически находить набор PE1, имеющих порты, подключенные к устройствам CE2, которые входят в одну сеть VPN. Эта информация требуется для завершения сигнальной фазы соединений L1VPN. Одной из основных задач механизма автоматического детектирования L1VPN является поддержка модели single-end provisioning, в которой добавление порта в данную L1VPN будет вызывать изменения конфигурации только того устройства PE, которое включает затронутый соединением порт, и устройства CE, подключенного к PE через этот порт.

1. Введение

Целью настоящего документа является определение механизма автоматического детектирования Layer-1 VPN [L1VPN-FRMK]. Механизм автоматического детектирования для L1VPN позволяет устройствам сети провайдера автоматически находить набор PE, имеющих порты, подключенные к устройствам CE, которые входят в одну сеть VPN. Эта информация требуется для завершения сигнальной фазы соединений L1VPN. Одной из основных задач механизма автоматического детектирования L1VPN является поддержка модели «single-end provisioning», в которой добавление порта в данную L1VPN будет вызывать изменения конфигурации только того устройства PE, которое включает затронутый соединением порт, и устройства CE, подключенного к PE через этот порт.

Механизм автоматического детектирования обеспечивается за счет того, что PE анонсирует другим устройствам PE по крайней мере свой адрес IP и список локальных для данного PE пар <private address, provider address>3. После получения этой информации устройства PE будут будут знать список членов VPN, связанных с данным PE, и использовать переданную механизмом автоматического детектирования информацию для преобразования адресов во время сигнальной фазы соединений L1VPN.

Рисунок 1 показывает схему работы механизма автоматического детектирования для L1VPN на основе BGP. Для работы механизма автоматического детектирования требуется активизация BGP только в сети провайдера. Устройства PE поддерживают для каждой VPN информационные таблицы PIT4, относящиеся к парам <private address, provider address>. Дополнительная информация о таблицах PIT приведена в разделе 2.

                PE1                        PE2
            +---------+             +--------------+
+--------+  | +------+|             | +----------+ | +--------+
|  VPN-A |  | |VPN-A ||             | |  VPN-A   | | |  VPN-A |
|   CE1  |--| |PIT   || Распростран.| |  PIT     | |-|   CE2  |
+--------+  | |      ||<----------->| |          | | +--------+
            | +------+| маршр. BGP  | +----------+ |
            |         |             |              |
+--------+  | +------+|             | +----------+ | +--------+
| VPN-B  |  | |VPN-B ||  --------   | |   VPN-B  | | |  VPN-B |
|  CE1   |--| |PIT   || -(магистр)- | |   PIT    | |-|   CE2  |
+--------+  | |      ||   (GMPLS)   | |          | | +--------+
            | +------+|  ---------  | +----------+ |
            |         |             |              |
+--------+  | +-----+ |             | +----------+ | +--------+
| VPN-C  |  | |VPN-C| |             | |   VPN-C  | | |  VPN-C |
|  CE1   |--| |PIT  | |             | |   PIT    | |-|   CE2  |
+--------+  | |     | |             | |          | | +--------+
            | +-----+ |             | +----------+ |
            +---------+             +--------------+

Рисунок 1: BGP Auto-Discovery для L1VPN

В документе [L1VPN-FRMK] описаны два режима работы L1VPN — базовый и расширенный (enhanced). В настоящем документе рассматривается механизм автоматического детектирования только для базового режима.

1.1. Термины

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

2. Процедуры

В контексте L1VPN устройства CE подключаются к PE через один или множество портов и каждый порт может включать один или множество каналов или субканалов. Каждый порт CE, соединяющий CE с PE имеет уникальный в масштабе L1VPN идентификатор (значения идентификаторов в разных L1VPN могут перекрываться). Этот идентификатор мы будем называть CPI5. Каждый порт PE также имеет уникальный в рамках сети провайдера идентификатор. Будем обозначать эти идентификаторы PPI6. Отметим, что для CPI и PPI могут использоваться адреса IPv4 или IPv6.

Для каждой L1VPN, которая имеет на PE хотя бы один сконфигурированный порт, PE поддерживает таблицу PIT, содержащую список пар <CPI, PPI> для всех портов в L1VPN. Отметим, что PIT может также включать маршрутную информацию (например, когда значения CPI определяются с использованием протокола маршрутизации).

Таблица PIT для данного PE включает два типа информации:

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

Информацию первого типа будем называть локальной, а второго — удаленной. Распространение локальной информации другим PE осуществляется с использованием многопротокольного расширения BGP [RFC4760]. Для ограничения потока такой информации только PIT, относящимися к данной L1VPN, мы будем использовать фильтрацию маршрутов BGP на основе Route Target Extended Community [BGP-COMM], как описано ниже.

Для каждой таблицы PIT в конфигурации устройства PE задается по крайней мере одна группа Route Target, которую будем называть export Route Targets, — эта группа будет использоваться для того, чтобы помечать локальную информацию при ее экспорте в BGP провайдера. Гранулярность таких тегов может уменьшаться до уровня отдельной пары <CPI, PPI>. В дополнение к этому конфигурация каждой таблицы PIT в PE содержит по крайней мере одну группу Route Target, которую мы будем называть import Route Targets, — эта группа ограничивает набор маршрутов, которые могут быть импортированы из BGP провайдера в PIT, только теми маршрутами, которые входят по крайней мере в одну из групп импорта.

При добавлении провайдером порта L1VPN в конкретном устройстве PE, этот порт связывается с таблицей PIT данного PE, а таблица PIT связывается с конкретной L1VPN.

Поскольку для заполнения таблиц PIT удаленной информацией используется протокол BGP, который работает со множеством автономных систем (AS7), описанный в этом документе механизм позволяет поддерживать L1VPN, распределенные между несколькими автономными системами.

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

3. Передача информации L1VPN в BGP

Отображения <CPI, PPI> передаются с использованием многопротокольного расширения8 BGP [RFC4760]. Документ [RFC4760] определяет формат двух атрибутов BGP — MP_REACH_NLRI и MP_UNREACH_NLRI, которые могут использоваться для анонсирования и отзыва анонсов информации о доступности. В этом документе добавляется идентификатор семейства адресов, названный Layer-1 VPN auto-discovery information9 (значение 69) и определяется новый формат NLRI10 для передачи CPI и PPI.

В упомянутых выше атрибутах BGP может передаваться одна или множество пар <PPI, CPI>.

Рисунок 2 показывает формат NLRI2.

+---------------------------------------+
| Размер (1 октет)                      |
+---------------------------------------+
| Информация автодетектирования (перем.)|
+---------------------------------------+

Рисунок 2: Кодирование NLRI

Отметим, что представление информации механизма автоматического детектирования описано в [L1VPN-BM] и подчеркнем также, что при значении Length = 4 в поле Next Hop (атрибут MP_REACH_NLRI) значением Next Hop будет адрес IPv4, а при значении 16 Next Hop будет содержать адрес IPv6.

4. Передача информации L1VPN Traffic Engineering в BGP

В дополнение к информации о доступности механизм автоматического детектирования может передавать информацию Traffic Engineering, используемую для выбора исходящего пути. Например, PE может узнать возможности коммутации и максимальную полосу LSP удаленных интерфейсов L1VPN от удаленных PE. Для передачи такой информации в данном документе предлагается использовать атрибут BGP Traffic Engineering [BGP-TE-ATTRIBUTE].

5. Масштабируемость

Напомним, что сеть провайдера состоит из (a) устройств PE, (b) маршрутных рефлекторов11 BGP, (c) узлов P (которые не являются ни PE, ни Route Reflector) и, в случае VPN с использованием нескольких провайдеров, (d) граничных маршрутизаторов автономных систем (ASBR12).

Маршрутизатор PE, если он не является маршрутным рефлектором, не сохраняет связанной с L1VPN информации, пока на не нет хотя бы одной VPN со значением import Route Target, идентичным связанной с VPN информации атрибутов Route Target. Если PE не имеет VPN с соответствующим значением import Route Target, это устройство должно отбрасывать полученную информацию L1VPN. Для отбрасывания информации должна применяться фильтрация на входе. При последующем добавлении import Route Target для одной из VPN устройства PE (операция VPN Join13) устройство PE должно принимать связанную с VPN информацию, которая ранее отбрасывалась.

Для таких случаев должен использоваться механизм обновления, описанный в [BGP-RFSH]. Могут также применяться механизмы фильтрации на выходе [BGP-ORF] и [BGP-CONS] для обеспечения более динамичной фильтрации.

Аналогично, если конкретное значение import Route Target больше не присутствует в VPN какого-либо PE (в результате выполнение одной или множества операций VPN Prune), устройство PE может отбрасывать BGP-маршруты L1VPN и в результате не иметь более import Route Targets в таблицах PIT устройств PE как атрибутов Route Target.

Отметим, что операции VPN Join и VPN Prune являются неразрушающими и не требуют разрыва каких-либо соединений BGP или использования механизма обновления [BGP-RFSH].

В результате использования описанных правил распространения информации ни одному устройству PE не требуется иметь всех маршрутов во все L1VPN — это важно учитывать при рассмотрении вопросов масштабирования.

Рефлекторы маршрутов могут быть разделены между VPN так, чтобы каждая группа рефлекторов передавала маршруты только для подмножества L1VPN, поддерживаемых провайдером. Таким образом ни от одного из рефлекторов не требуется поддержки связанной с VPN информации для всех VPN.

Для VPN, включающих множество провайдеров, при использовании EBGP14 через несколько интервалов маршрутизации от маршрутизаторов ASBR совсем не требуется поддержка и распространение связанной с VPN информации. Маршрутизаторы P не поддерживают у себя какой-либо информации, связанной с VPN.

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

Важно подчеркнуть что возможна поддержка неограниченного числа систем BGP используемых для передачи связанной с VPN информации. Это отличается от ситуации в Internet, где каждая система BGP должна передавать все маршруты Internet. Таким образом, одно значимое (но, возможно, трудно уловимое) различие при использовании BGP для маршрутизации Internet и для распространения связанной с VPN информации состоит в том, что в первом случае невозможно разделение на части, а во втором это реально.

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

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

Критически важно, что для любого маршрутизатора PE недопустимо его «детектирование» в качестве подключенного к VPN до того, как данный PE будет реально подключен к этой VPN, что неоспоримо говорит о наличии у маршрутизатора полномочий на подключение к данной VPN. Если произвольный узел Internet может начать передачу анонсов BGP о своей принадлежности к VPN и такие анонсы будут достигать других узлов PE при условии, что эти узлы PE будут принимать такие анонсы, тогда любой желающий сможет добавить любой сайт к любой L1VPN. Таким образом, описанный здесь механизм предполагает, что конкретный маршрутизатор PE доверяет своим партнерам BGP и, более того, считает этих партнеров обеспечивающими надежную защиту своих локальных подключений (т. е., PE должен верить, что его партнеры подключены к соответствующим L1VPN и имеют на такое подключение право).

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

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

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

В этом документе выделяется новое значение SAFI15, названное Layer-1 VPN auto-discovery information (см. раздел 3). Это значение включено в реестр дополнительных идентификаторов семейств адресов (SAFI) с использованием процедуры Standards Action. Новый идентификатор имеет значение 69.

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

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

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

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

[BGP-RFSH] Chen, E., «Route Refresh Capability for BGP-4», RFC 2918, September 2000.

8.2. Прочие ссылки

[BGP-TE-ATTRIBUTE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., «Traffic Engineering Attribute», Work in Progress, January 2008.

[BGP-ORF] Chen, E. and Y. Rekhter, «Outbound Route Filtering Capability for BGP-4», Work in Progress17, September 2006.

[BGP-CONS] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, «Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)», RFC 4684, November 2006.

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

[L1VPN-FRMK] Takeda, T., Ed., «Framework and Requirements for Layer 1 Virtual Private Networks», RFC 4847, April 2007.

[L1VPN-BM] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, «Layer 1 VPN Basic Mode», Work in Progress18, February 2008.

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

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

Авторы выражают благодарность Adrian Farrel за полезные комментарии.

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

Hamid Ould-Brahim

Nortel

PO Box 3511 Station C

Ottawa ON K1Y 4H7

Canada

Phone: +1 (613) 763 4730

EMail: hbrahim@nortel.com

Yakov Rekhter

Juniper Networks

1194 N. Mathilda Avenue

Sunnyvale, CA 94089

USA

EMail: yakov@juniper.net

Don Fedyk

Nortel

600 Technology Park

Billerica, MA 01821

USA

Phone: +1 (978) 288 3041

Email: dwfedyk@nortel.com


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

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

nmalykh@gmail.com

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

Copyright (C) The IETF Trust (2008).

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.


1Provider Edge — краевое устройство провайдера.

2Customer Edge — краевое устройство пользователя.

3Приватный адрес — адрес провайдера.

4Port Information Table — таблица информации для порта.

5Customer port identifier — идентификатор пользовательского порта.

6Provider port identifier — идентификатор порта провайдера.

7Autonomous system — автономная система. Прим. перев.

8Multiprotocol Extensions. Прим. перев.

9Информация механизма автоматического детектирования Layer-1 VPN.

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

11Route Reflector.

12Autonomous System Border Router — граничный маршрутизатор автономной системы.

13Включение в VPN. Прим. перев.

14External BGP — внешний BGP.

15Subsequent Address Family Identifier — дополнительный идентификатор семейства адресов.

17В настоящее время работа завершена и опубликована в RFC 5291. Перевод имеется на сайте www.protocols.ru. Прим. перев.

18В настоящее время работа завершена и опубликована в RFC 5251. Прим. перев.

Please follow and like us:
error
Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий