RFC 8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery

image_print
Internet Engineering Task Force (IETF)                            B. Wen
Request for Comments: 8466                                       Comcast
Category: Standards Track                               G. Fioccola, Ed.
ISSN: 2070-1721                                           Telecom Italia
                                                                  C. Xie
                                                           China Telecom
                                                                L. Jalil
                                                                 Verizon
                                                            October 2018

A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery

Модель данных YANG для предоставления услуг виртуальных сетей L2 (L2VPN)

PDF

Тезисы

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

Определенная в этом документе модель данных YANG включает услуги VPWS1 («точка-точка») и VPLS2 (многоточечные), которые используют псевдопровода с сигнализаций на основе протокола LDP3 и BGP4, как описано в RFC 4761 и RFC 6624.

Определенная здесь модель данных YANG соответствует архитектуре конфигурационных хранилищ NMDA5, определенной в RFC 8342.

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

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF6 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG7. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8466.

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

Авторские права (Copyright (c) 2018) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

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

1. Введение

Этот документ определяет модель данных YANG для услуг L2 VPN (L2VPN). Модель описывает элементы конфигурации сервиса, которые могут применяться в коммуникационных протоколах между абонентами и сетевыми операторами. Эти элементы могут также служить входными данными для автоматизированных приложений управления и настройки конфигурации, которые могут генерировать конкретные конфигурации для настройки различных элементов сети, обеспечивающих сервис. Способы настройки конфигурации сетевых элементов выходят за рамки этого документа.

Дополнительное рассмотрение способов моделирования услуг с помощью YANG и связей между «абонентскими моделями сервиса», подобными описанным здесь, и конфигурационными моделями можно найти в [RFC8309] и [RFC8199]. В разделах 4 и 6 приведена более подробная информация о способах применения этой модели сервиса и ее роли в общей архитектуре моделирования.

Определенная в этом документе модель YANG включает поддержку услуг VPWS (точка-точка) и VPLS (многоточечные), использующих псевдопровода с сигнализацией на основе протокола LDP и BGP, как описано в [RFC4761] и [RFC6624]. Модель соответствует архитектуре NMDA [RFC8342].

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

Ниже перечислены термины, определенные в [RFC6241] и используемые здесь:

  • client — клиент;

  • configuration data — данные конфигурации;

  • server — сервер;

  • state data — данные состояния.

Ниже перечислены термины, определенные в [RFC7950] и используемые здесь:

  • augment — добавление (усиление);

  • data model — модель данных;

  • data node — узел данных.

Терминология для описания моделей данных YANG заимствована из [RFC7950].

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

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

1.2. Диаграммы деревьев

Диаграммы деревьев в этом документе используют нотацию [RFC8340].

2. Определения

Ниже приведены определения используемых в документе терминов.

Service Provider (SP) — сервис-провайдер

Организация (обычно коммерческое предприятие), отвечающая за работу сети, которая предоставляет услуги VPN клиентам и абонентам.

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

Оборудование, выделенное для конкретного абонента и напрямую подключенное к одному или нескольким устройствам PE через устройства (каналы) присоединения (AC8). Устройсва CE обычно размещаются на площадке абонента и как правило выделяются для одной сети VPN, хотя могут поддерживать и множество VPN, если для каждой применяется свое присоединение AC. Устройствами CE могут быть маршрутизаторы, мосты, коммутаторы или хосты.

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

Управляемое SP оборудование, способное поддерживать множество VPN для разных абонентов и напрямую соединенное с одним или множеством устройств CE через AC. Устройства PE обычно размещаются в точке присутствия SP POP9 и управляются SP.

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

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

Virtual Private Wire Service (VPWS) — услуги виртуального частного провода

VPWS представляет собой устройство «точка-точка» (т. е. канал), соединяющее два устройства CE. Канал организуется в форме логического соединения L2 через PSN. Устройства CE в сети абонента подключаются к PE в сети провайдера через AC, которые являются физическими или логическими устройствами (каналами). VPWS отличается от VPLS тем, что VPLS является многоточечным сервисом, а VPWS обеспечивает соединения «точка-точка». В некоторых реализациях набор VPWS служит для создания сети L2VPN с множеством сайтов.

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

Псевдопровод представляет собой эмуляцию естественного сервиса через PSN. Эмулируемым сервисом может быть ATM, Frame Relay, Ethernet, низкоскоростной канал TDM11 или SONET/SDH12, а сетью PSN — MPLS, IP (IPv4 или IPv6), L2TPv313.

MAC-VRF

Таблица виртуальной маршрутизации и пересылки для MAC14-адресов в PE. Иногда используется термин VSI15.

UNI

Интерфейс пользователя с сетью. Точка физического разделения между областями ответственности абонента и провайдера.

NNI

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

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

BSS

Business Support System — система поддержки бизнеса.

BUM

Broadcast, Unknown Unicast, or Multicast — групповые, неизвестные индивидуальные и широковещательные (кадры).

CoS

Class of Service — класс обслуживания.

LAG

Link Aggregation Group — группы объединенных каналов.

LLDP

Link Layer Discovery Protocol — протокол обнаружения канального уровня.

OAM

Operations, Administration, and Maintenance — эксплуатация, администрирование и поддержка.

OSS

Operations Support System — система поддержки операций.

PDU

Protocol Data Unit — модуль данных протокола.

QoS

Quality of Service — качество обслуживания.

3. Модель сервиса L2 VPN

Сервис VPN уровня 2 (L2VPN16) представляет собой набор сайтов, уполномоченных обмениваться трафиком между собой через общую сетевую инфраструктуру на базе технологии общего назначения. Модель сервиса L2VPN (L2SM17), описанная в этом документе, обеспечивает базовое представление о развертывании соответствующих услуг L2VPN через инфраструктуру общего пользования.

Этот документ представляет L2SM на основе языка моделирования данных YANG [RFC7950] в качестве формального языка, понятного человеку и пригодного для разбора программами, использующими протоколы NETCONF18 [RFC6241] и RESTCONF [RFC8040].

Эта модель ограничена сетями VPN на основе VPWS и VPLS, как описано в [RFC4761] и [RFC6624], а также Ethernet VPN (EVPN), описанными в [RFC7432].

3.1. Типы сервиса L2 VPN

С точки зрения технологии базовые типы сервиса L2VPN включают:

  • VPWS «точка-точка», использующие псевдопровода с сигнализацией LDP или L2TP [RFC6074];

  • многоточечные VPLS, использующие псевдопровода с сигнализацией LDP или L2TP [RFC6074];

  • многоточечные VPLS, использующие уровень управления BGP, как описано в [RFC4761] и [RFC6624];

  • IPLS19, являющиеся функциональным подмножеством услуг VPLS [RFC7436];

  • EVPN на основе BGP MPLS, как описано в [RFC7432] и [RFC7209];

  • EVPN VPWS, как описано в [RFC8214].

3.2. Топология физической сети L2 VPN

На рисунке 1 показана физическая топология типовой сети SP. Большинство SP использует инфраструктуру с мультисервисным ядром IP, MPLS или сегментной маршрутизации (SR20). Входящие кадры L2 отображаются в псевдопровод Ethernet (например, PWE321) или туннель VXLAN22 между устройствами PE. Выбор механизмов туннелирования остается за провайдером и не является частью L2SM.

L2VPN обеспечивает сквозные соединения L2 через инфраструктуру мультисервисного ядра между двумя или более площадками абонента. Устройства AC размещаются между CE и PE, обеспечивая доставку кадров L2 из сети абонента через сеть доступа в провайдерскую сеть или на удаленный сайт. Граничная точка (т. е., UNI) между абонентом и SP может размещаться (1) между узлами абонента и устройством CE или (2) между устройствами CE и PE. Опорное соединение между CE и PE будет описано в L2SM.

SP может также выбрать модель «бесшовного MPLS» для создания туннеля PWE3 или VXLAN между сайтами.

SP может использовать MP-BGP23 для автоматического обнаружения и сигнализации конечных точек туннелей PWE3 или VXLAN.

          Сайт A  |                          | Сайт B
 ---     ----     |        VXLAN/PW          |               ---
|   |   |    |    |<------------------------>|              |   |
| C +---+ CE |    |                          |              | C |
|   |   |    |    |         ---------        |              |   |
 ---     ----\    |        (         )       |              /---
              \  -|--     (           )     -|--     ----  /
               \|    |   (    Сеть     )   |    |   |    |/
                | PE +---+ IP/MPLS/SR  +---+ PE +---+ CE |
               /|    |   (             )   |    |   |    |\
              /  ----     (           )     ----     ----  \
 ---     ----/             (         )                      \---
|   |   |    |              ----+----                       |   |
| C +---+ CE |                  |                           | C |
|   |   |    |                --+--                         |   |
 ---     ----                | PE  |                         ---
                              --+--
                                |      Сайт C
                              --+--
                             | CE  |
                              --+--
                                |
                              --+--
                             |  C  |
                              -----

Рисунок 1. Эталонная сеть для использования L2SM.


Однако с точки зрения абонента все устройства CE будут соединены через имитируемую среду ЛВС, как показано на рисунке 2. Широковещательные и групповые пакеты передаются всем участникам одного домена мостов.

CE---+----+-----+---CE
     |    |     |
     |    |     |
     |    |     |
CE---+    CE    +---CE

Рисунок 2. L2VPN с точки зрения абонента.


4. Использование модели данных сервиса

L2SM обеспечивает абстрактный интерфейс для запроса, настройки и управления компонентами сервиса L2VPN. Модель применяется абонентами, приобретающими соединения и другие услуги у SP, для коммуникаций с этим SP.

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

Настройка конфигурации элементов сети может выполняться через командный интерфейс (CLI25) или иной интерфейс настройки (южную границу — southbound), такой как NETCONF [RFC6241] в комбинации с определяемой устройством и протоколом моделью YANG.

Этот способ использования модели сервиса показан на рисунке 3, а более подробное описание приведено в [RFC8309] и [RFC8199]. Разделение функций оркестровки на уровне сервиса (service orchestrator) и сети (network orchestrator) разъяснено в [RFC8309]. Применение этой модели сервиса не исчерпывается представленным примером, она может использоваться любым компонентом системы управления, но не напрямую элементами сети.

Применение и структуру этой модели следует сравнивать с сервисной моделью L3 VPN, определенной в [RFC8299].

В Metro Ethernet Forum (MEF) [MEF-6] также была разработана архитектура работы сети и сетевого управления, но работа MEF охватывает все аспекты оркестровки жизненного цикла сервиса, включая оплату (billing), соглашения об уровне обслуживания (SLA26), управление заказами и жизненным циклом сервиса. Работа IETF над моделью сервиса обычно более компактна и предлагает простой, самодостаточный модуль YANG. Подробности см. в [RFC8309].

    ---------------------------------
   | Запрашивающее сервис устройство |
    ---------------------------------
           |
           |
     L2SM  |
           |
           |
         -----------------------
        |  Оркестровка сервиса  |
         -----------------------
           |
           |     Модель              +-------------+
           |     доставки    +------>|  Приложение |
           |     сервиса     |       |   BSS/OSS   |
           |                 V       +-------------+
         -----------------------
        |   Оркестровка сети    |
         -----------------------
           |            |
   +----------------+   |
   |Менеджер конфиг.|   |
   +----------------+   |  Модели
           |            |  устройств
           |            |
--------------------------------------------
                   Сеть
                              +++++++
                              + AAA +
                              +++++++

      ++++++++   Опорное   ++++++++           ++++++++      ++++++++
      + CE A + ----------- + PE A +           + PE B + ---- + CE B +
      ++++++++  соединение ++++++++           ++++++++      ++++++++

                 Сайт A                               Сайт B

Рисунок 3. Эталонная архитектура для использования L2SM.


5. Устройство модели данных

Структура модели L2SM позволяет провайдеру перечислить множество устройств разных типов сервиса для одного абонента. Устройство представляет сквозное соединение между двумя или более местоположениями абонента.

Модуль YANG разделен на два основных контейнера — услуги VPN (vpn-services) и сайты (sites). Контейнер vpn-svc в иерархии vpn-services определяет глобальные параметры сервиса VPN для конкретного абонента.

Сайт имеет по меньше мере одно подключение к сети (т. е. доступ сайта в сеть обеспечивающий связь и другими сайтами, как указано в параграфе 5.3.2) и может иметь множество подключений в многодомном случае. Подключение сайта к сети выполняется через опорное соединение (носитель — bearer) на канальном уровне (L2). «Носитель» относится к свойствам ниже уровня L2, а «соединение» к протокольным свойствам L2. Соединение-носитель может динамически выделяться SP, а абонент может задавать некоторые ограничения для управления местом соединения.

Полномочия на обмен трафиком предоставляются на основе политики или топологии VPN, которая определяет правила обмена маршрутной информацией между сайтами.

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

На рисунке 4 показана общая структура модуля YANG.

   module: ietf-l2vpn-svc
   +--rw l2vpn-svc
     +--rw vpn-profiles
     |  +--rw valid-provider-identifiers
     |     +--rw cloud-identifier*  string{cloud-access}?
     |     +--rw qos-profile-identifier* string
     |     +--rw bfd-profile-identifier* string
     |     +--rw remote-carrier-identifier* string
     +--rw vpn-services
     |  +--rw vpn-service* [vpn-id]
     |     +--rw vpn-id                      svc-id
     |     +--rw vpn-svc-type?               identityref
     |     +--rw customer-name?              string
     |     +--rw svc-topo?                   identityref
     |     +--rw cloud-accesses {cloud-access}?
     |     |  +--rw cloud-access* [cloud-identifier]
     |     |     +--rw cloud-identifier
     |     |     |    -> /l2vpn-svc/vpn-profiles/
     |     |     |      valid-provider-identifiers/cloud-identifier
     |     |     +--rw (list-flavor)?
     |     |        +--:(permit-any)
     |     |        |  +--rw permit-any?         empty
     |     |        +--:(deny-any-except)
     |     |        |  +--rw permit-site*
     |     |        |  :    -> /l2vpn-svc/sites/site/site-id
     |     |        +--:(permit-any-except)
     |     |           +--rw deny-site*
     |     |                -> /l2vpn-svc/sites/site/site-id
     |     +--rw frame-delivery {frame-delivery}?
     |     |  +--rw customer-tree-flavors
     |     |  |  +--rw tree-flavor*   identityref
     |     |  +--rw bum-frame-delivery
     |     |  |  +--rw bum-frame-delivery* [frame-type]
     |     |  |     +--rw frame-type       identityref
     |     |  |     +--rw delivery-mode?   identityref
     |     |  +--rw multicast-gp-port-mapping    identityref
     |     +--rw extranet-vpns {extranet-vpn}?
     |     |  +--rw extranet-vpn* [vpn-id]
     |     |     +--rw vpn-id              svc-id
     |     |     +--rw local-sites-role?   identityref
     |     +--rw ce-vlan-preservation        boolean
     |     +--rw ce-vlan-cos-preservation    boolean
     |     +--rw carrierscarrier?            boolean {carrierscarrier}?
     +--rw sites
       +--rw site* [site-id]
        +--rw site-id                                string
        +--rw site-vpn-flavor?                       identityref
        +--rw devices
        |  +--rw device* [device-id]
        |     +--rw device-id     string
        |     +--rw location
        |     |    -> ../../../locations/location/location-id
        |     +--rw management
        |        +--rw transport?   identityref
        |        +--rw address?     inet:ip-address
        +--rw management
        |  +--rw type    identityref
        +--rw locations
        |  +--rw location* [location-id]
        |     +--rw location-id     string
        |     +--rw address?        string
        |     +--rw postal-code?    string
        |     +--rw state?          string
        |     +--rw city?           string
        |     +--rw country-code?   string
        +--rw site-diversity {site-diversity}?
        |  +--rw groups
        |     +--rw group* [group-id]
        |        +--rw group-id    string
        +--rw vpn-policies
        |  +--rw vpn-policy* [vpn-policy-id]
        |     +--rw vpn-policy-id    string
        |     +--rw entries* [id]
        |        +--rw id         string
        |        +--rw filters
        |        |  +--rw filter* [type]
        |        |     +--rw type       identityref
        |        |     +--rw lan-tag*   uint32 {lan-tag}?
        |        +--rw vpn* [vpn-id]
        |           +--rw vpn-id
        |           |    -> /l2vpn-svc/vpn-services/
        |           |            vpn-service/vpn-id
        |           +--rw site-role?   identityref
        +--rw service
        |  +--rw qos {qos}?
        |  |  +--rw qos-classification-policy
        |  |  |  +--rw rule* [id]
        |  |  |     +--rw id                   string
        |  |  |     +--rw (match-type)?
        |  |  |     |  +--:(match-flow)
        |  |  |     |  |  +--rw match-flow
        |  |  |     |  |     +--rw dscp?           inet:dscp
        |  |  |     |  |     +--rw dot1q?          uint16
        |  |  |     |  |     +--rw pcp?            uint8
        |  |  |     |  |     +--rw src-mac?        yang:mac-address
        |  |  |     |  |     +--rw dst-mac?        yang:mac-address
        |  |  |     |  |     +--rw color-type?     identityref
        |  |  |     |  |     +--rw target-sites*
        |  |  |     |  |     |               svc-id {target-sites}?
        |  |  |     |  |     +--rw any?            empty
        |  |  |     |  |     +--rw vpn-id?         svc-id
        |  |  |     |  +--:(match-application)
        |  |  |     |     +--rw match-application?   identityref
        |  |  |     +--rw target-class-id?     string
        |  |  +--rw qos-profile
        |  |     +--rw (qos-profile)?
        |  |        +--:(standard)
        |  |        |  +--rw profile?
        |  |        |       -> /l2vpn-svc/vpn-profiles/
        |  |        |              valid-provider-identifiers/
        |  |        |              qos-profile-identifier
        |  |        +--:(custom)
        |  |           +--rw classes {qos-custom}?
        |  |              +--rw class* [class-id]
        |  |                 +--rw class-id        string
        |  |                 +--rw direction?      identityref
        |  |                 +--rw policing?       identityref
        |  |                 +--rw byte-offset?    uint16
        |  |                 +--rw frame-delay
        |  |                 |  +--rw (flavor)?
        |  |                 |     +--:(lowest)
        |  |                 |     |  +--rw use-lowest-latency? empty
        |  |                 |     +--:(boundary)
        |  |                 |        +--rw delay-bound?     uint16
        |  |                 +--rw frame-jitter
        |  |                 |  +--rw (flavor)?
        |  |                 |     +--:(lowest)
        |  |                 |     |  +--rw use-lowest-jitter? empty
        |  |                 |     +--:(boundary)
        |  |                 |        +--rw delay-bound?     uint32
        |  |                 +--rw frame-loss
        |  |                 |  +--rw rate?   decimal64
        |  |                 +--rw bandwidth
        |  |                    +--rw guaranteed-bw-percent decimal64
        |  |                    +--rw end-to-end?           empty
        |  +--rw carrierscarrier {carrierscarrier}?
        |     +--rw signaling-type?   identityref
        +--rw broadcast-unknown-unicast-multicast {bum}?
        |  +--rw multicast-site-type?            enumeration
        |  +--rw multicast-gp-address-mapping* [id]
        |  |  +--rw id                 uint16
        |  |  +--rw vlan-id            uint16
        |  |  +--rw mac-gp-address     yang:mac-address
        |  |  +--rw port-lag-number?   uint32
        |  +--rw bum-overall-rate?     uint32
        |  +--rw bum-rate-per-type* [type]
        |     +--rw type    identityref
        |     +--rw rate?   uint32
        +--rw mac-loop-prevention {mac-loop-prevention}?
        |  +--rw protection-type?   identityref
        |  +--rw frequency?         uint32
        |  +--rw retry-timer?       uint32
        +--rw access-control-list
        |  +--rw mac* [mac-address]
        |     +--rw mac-address    yang:mac-address
        +--ro actual-site-start?   yang:date-and-time
        +--ro actual-site-stop?    yang:date-and-time
        +--rw bundling-type?       identityref
        +--rw default-ce-vlan-id   uint32
        +--rw site-network-accesses
           +--rw site-network-access* [network-access-id]
           +--rw network-access-id                 string
           +--rw remote-carrier-name?              string
           +--rw type?                             identityref
           +--rw (location-flavor)
           |  +--:(location)
           |  |  +--rw location-reference?
           |  |       -> ../../../locations/location/
           |  |               location-id
           |  +--:(device)
           |     +--rw device-reference?
           |          -> ../../../devices/device/device-id
           +--rw access-diversity {site-diversity}?
           |  +--rw groups
           |  |  +--rw group* [group-id]
           |  |     +--rw group-id    string
           |  +--rw constraints
           |     +--rw constraint* [constraint-type]
           |        +--rw constraint-type    identityref
           |        +--rw target
           |           +--rw (target-flavor)?
           |              +--:(id)
           |              |  +--rw group* [group-id]
           |              |     +--rw group-id    string
           |              +--:(all-accesses)
           |              |  +--rw all-other-accesses?   empty
           |              +--:(all-groups)
           |                 +--rw all-other-groups?     empty
           +--rw bearer
           |  +--rw requested-type {requested-type}?
           |  |  +--rw type?     string
           |  |  +--rw strict?   boolean
           |  +--rw always-on?         boolean {always-on}?
           |  +--rw bearer-reference?  string {bearer-reference}?
           +--rw connection
           |  +--rw encapsulation-type?    identityref
           |  +--rw eth-inf-type?          identityref
           |  +--rw tagged-interface
           |  |  +--rw type?               identityref
           |  |  +--rw dot1q-vlan-tagged {dot1q}?
           |  |  |  +--rw tg-type?    identityref
           |  |  |  +--rw cvlan-id    uint16
           |  |  +--rw priority-tagged
           |  |  |  +--rw tag-type?   identityref
           |  |  +--rw qinq {qinq}?
           |  |  |  +--rw tag-type?   identityref
           |  |  |  +--rw svlan-id    uint16
           |  |  |  +--rw cvlan-id    uint16
           |  |  +--rw qinany {qinany}?
           |  |  |  +--rw tag-type?   identityref
           |  |  |  +--rw svlan-id    uint16
           |  |  +--rw vxlan {vxlan}?
           |  |     +--rw vni-id       uint32
           |  |     +--rw peer-mode?   identityref
           |  |     +--rw peer-list* [peer-ip]
           |  |        +--rw peer-ip    inet:ip-address
           |  +--rw untagged-interface
           |  |  +--rw speed?                 uint32
           |  |  +--rw mode?                  neg-mode
           |  |  +--rw phy-mtu?               uint32
           |  |  +--rw lldp?                  boolean
           |  |  +--rw oam-802.3ah-link {oam-3ah}?
           |  |  |  +--rw enabled?   boolean
           |  |  +--rw uni-loop-prevention?   boolean
           |  +--rw lag-interfaces {lag-interface}?
           |  |  +--rw lag-interface* [index]
           |  |     +--rw index    string
           |  |     +--rw lacp {lacp}?
           |  |        +--rw enabled?           boolean
           |  |        +--rw mode?              neg-mode
           |  |        +--rw speed?             uint32
           |  |        +--rw mini-link-num?     uint32
           |  |        +--rw system-priority?   uint16
           |  |        +--rw micro-bfd {micro-bfd}?
           |  |        |  +--rw enabled?      enumeration
           |  |        |  +--rw interval?     uint32
           |  |        |  +--rw hold-timer?   uint32
           |  |        +--rw bfd {bfd}?
           |  |        |  +--rw enabled?      boolean
           |  |        |  +--rw (holdtime)?
           |  |        |     +--:(profile)
           |  |        |     |  +--rw profile-name?
           |  |        |     |    -> /l2vpn-svc/
           |  |        |     |         vpn-profiles/
           |  |        |     |        valid-provider-identifiers/
           |  |        |     |       bfd-profile-identifier
           |  |        |     +--:(fixed)
           |  |        |        +--rw fixed-value?    uint32
           |  |        +--rw member-links
           |  |        |  +--rw member-link* [name]
           |  |        |     +--rw name                string
           |  |        |     +--rw speed?              uint32
           |  |        |     +--rw mode?               neg-mode
           |  |        |     +--rw link-mtu?           uint32
           |  |        |     +--rw oam-802.3ah-link {oam-3ah}?
           |  |        |        +--rw enabled?  boolean
           |  |        +--rw flow-control?      boolean
           |  |        +--rw lldp?              boolean
           |  +--rw cvlan-id-to-svc-map* [svc-id]
           |  |  +--rw svc-id
           |  |  |    -> /l2vpn-svc/vpn-services/vpn-service/
           |  |  |           vpn-id
           |  |  +--rw cvlan-id* [vid]
           |  |     +--rw vid    uint16
           |  +--rw l2cp-control {l2cp-control}?
           |  |  +--rw stp-rstp-mstp?    control-mode
           |  |  +--rw pause?            control-mode
           |  |  +--rw lacp-lamp?        control-mode
           |  |  +--rw link-oam?         control-mode
           |  |  +--rw esmc?             control-mode
           |  |  +--rw l2cp-802.1x?      control-mode
           |  |  +--rw e-lmi?            control-mode
           |  |  +--rw lldp?             boolean
           |  |  +--rw ptp-peer-delay?   control-mode
           |  |  +--rw garp-mrp?         control-mode
           |  +--rw oam {oam}
           |     +--rw md-name         string
           |     +--rw md-level        uint16
           |     +--rw cfm-802.1-ag* [maid]
           |     |  +--rw maid                     string
           |     |  +--rw mep-id?                  uint32
           |     |  +--rw mep-level?               uint32
           |     |  +--rw mep-up-down?             enumeration
           |     |  +--rw remote-mep-id?           uint32
           |     |  +--rw cos-for-cfm-pdus?        uint32
           |     |  +--rw ccm-interval?            uint32
           |     |  +--rw ccm-holdtime?            uint32
           |     |  +--rw alarm-priority-defect?   identityref
           |     |  +--rw ccm-p-bits-pri?       ccm-priority-type
           |     +--rw y-1731* [maid]
           |        +--rw maid                           string
           |        +--rw mep-id?                        uint32
           |        +--rw type?                       identityref
           |        +--rw remote-mep-id?                 uint32
           |        +--rw message-period?                uint32
           |        +--rw measurement-interval?          uint32
           |        +--rw cos?                           uint32
           |        +--rw loss-measurement?              boolean
           |        +--rw synthetic-loss-measurement?    boolean
           |        +--rw delay-measurement
           |        |  +--rw enable-dm?   boolean
           |        |  +--rw two-way?     boolean
           |        +--rw frame-size?                    uint32
           |        +--rw session-type?               enumeration
           +--rw availability
           |  +--rw access-priority?   uint32
           |  +--rw (redundancy-mode)?
           |     +--:(single-active)
           |     |  +--rw single-active?     empty
           |     +--:(all-active)
           |        +--rw all-active?        empty
           +--rw vpn-attachment
           |  +--rw (attachment-flavor)
           |     +--:(vpn-id)
           |     |  +--rw vpn-id?
           |     |  |    -> /l2vpn-svc/vpn-services/
           |     |  |            vpn-service/vpn-id
           |     |  +--rw site-role?              identityref
           |     +--:(vpn-policy-id)
           |        +--rw vpn-policy-id?
           |             -> ../../../../vpn-policies/
           |                     vpn-policy/vpn-policy-id
           +--rw service
           |  +--rw svc-bandwidth {input-bw}?
           |  |  +--rw bandwidth* [direction type]
           |  |     +--rw direction    identityref
           |  |     +--rw type         identityref
           |  |     +--rw cos-id?      uint8
           |  |     +--rw vpn-id?      svc-id
           |  |     +--rw cir          uint64
           |  |     +--rw cbs          uint64
           |  |     +--rw eir?         uint64
           |  |     +--rw ebs?         uint64
           |  |     +--rw pir?         uint64
           |  |     +--rw pbs?         uint64
           |  +--rw svc-mtu            uint16
           |  +--rw qos {qos}?
           |  |  +--rw qos-classification-policy
           |  |  |  +--rw rule* [id]
           |  |  |     +--rw id                   string
           |  |  |     +--rw (match-type)?
           |  |  |     |  +--:(match-flow)
           |  |  |     |  |  +--rw match-flow
           |  |  |     |  |     +--rw dscp?           inet:dscp
           |  |  |     |  |     +--rw dot1q?          uint16
           |  |  |     |  |     +--rw pcp?            uint8
           |  |  |     |  |     +--rw src-mac?  yang:mac-address
           |  |  |     |  |     +--rw dst-mac?  yang:mac-address
           |  |  |     |  |     +--rw color-type?     identityref
           |  |  |     |  |     +--rw target-sites*
           |  |  |     |  |     |          svc-id {target-sites}?
           |  |  |     |  |     +--rw any?            empty
           |  |  |     |  |     +--rw vpn-id?         svc-id
           |  |  |     |  +--:(match-application)
           |  |  |     |     +--rw match-application? identityref
           |  |  |     +--rw target-class-id?     string
           |  |  +--rw qos-profile
           |  |     +--rw (qos-profile)?
           |  |        +--:(standard)
           |  |        |  +--rw profile?
           |  |        |       -> /l2vpn-svc/vpn-profiles/
           |  |        |              valid-provider-identifiers/
           |  |        |              qos-profile-identifier
           |  |        +--:(custom)
           |  |           +--rw classes {qos-custom}?
           |  |              +--rw class* [class-id]
           |  |                 +--rw class-id        string
           |  |                 +--rw direction?      identityref
           |  |                 +--rw policing?       identityref
           |  |                 +--rw byte-offset?    uint16
           |  |                 +--rw frame-delay
           |  |                 |  +--rw (flavor)?
           |  |                 |     +--:(lowest)
           |  |                 |     |  +--rw use-lowest-latency?
           |  |                 |     |                     empty
           |  |                 |     +--:(boundary)
           |  |                 |        +--rw delay-bound? uint16
           |  |                 +--rw frame-jitter
           |  |                 |  +--rw (flavor)?
           |  |                 |     +--:(lowest)
           |  |                 |     |  +--rw use-lowest-jitter?
           |  |                 |     |                     empty
           |  |                 |     +--:(boundary)
           |  |                 |        +--rw delay-bound? uint32
           |  |                 +--rw frame-loss
           |  |                 |  +--rw rate?   decimal64
           |  |                 +--rw bandwidth
           |  |                    +--rw guaranteed-bw-percent
           |  |                    |                    decimal64
           |  |                    +--rw end-to-end?       empty
           |  +--rw carrierscarrier {carrierscarrier}?
           |     +--rw signaling-type?   identityref
           +--rw broadcast-unknown-unicast-multicast {bum}?
           |  +--rw multicast-site-type?            enumeration
           |  +--rw multicast-gp-address-mapping* [id]
           |  |  +--rw id                 uint16
           |  |  +--rw vlan-id            uint16
           |  |  +--rw mac-gp-address     yang:mac-address
           |  |  +--rw port-lag-number?   uint32
           |  +--rw bum-overall-rate?               uint32
           |  +--rw bum-rate-per-type* [type]
           |     +--rw type    identityref
           |     +--rw rate?   uint32
           +--rw mac-loop-prevention {mac-loop-prevention}?
           |  +--rw protection-type?   identityref
           |  +--rw frequency?         uint32
           |  +--rw retry-timer?       uint32
           +--rw access-control-list
           |  +--rw mac* [mac-address]
           |     +--rw mac-address    yang:mac-address
           +--rw mac-addr-limit
           +--rw limit-number?    uint16
           +--rw time-interval?   uint32
           +--rw action?          identityref

Рисунок 4. Общая структура модуля YANG.

5.1. Свойства и их дополнение

Определенная в этом документе модель включает множество функций, которые обеспечивают возможность модульной реализации. Например, параметры L2 (параграф 5.3.2.2), предлагаемые абоненту, могут включаться и выключаться с помощью функций (возможностей). Модель также определяет некоторые возможности для расширенных опций, таких как поддержка Extranet VPN (параграф 5.2.4), разнородность сайтов (параграф 5.3) и QoS (параграф 5.10.2).

Как и многие другие модели YANG, данная модель может быть дополнена для реализации новых вариантов поведения или специальных возможностей. Например, эта модель определяет VXLAN [RFC7348] для инкапсуляции пакетов Ethernet и если инкапсуляция VXLAN не совсем удовлетворяет требования сервиса, можно реализовать новые опции путем дополнения.

5.2. Обзор сервиса VPN

Элемент списка vpn-service содержит базовую информацию о сервисе VPN. Элемент vpn-id в списке vpn-service задает внутреннюю ссылку для данного сервиса VPN. Этот идентификатор является внутренним для организации, отвечающей за поддержку сервиса VPN.

Список vpn-service содержит перечисленные ниже характеристики.

Информация абонента (customer-name)

Служит для идентификации абонента (заказчика).

Тип сервиса VPN (vpn-svc-type)

Служит для указания типа сервиса VPN. Идентификатор допускает произвольное кодирование для локального администрирования услуг VPN. Отметим, что для расширения базового идентификатора может применяться дополнительный.

Доступ в облако (cloud-access)

Всем сайтам в L2VPN следует по умолчанию предоставлять доступ в облако. Контейнер cloud-access содержит правила предоставления полномочий. Для идентификации целевого сервиса служит указатель облака. Идентификатор является локальным для каждого домена администрирования.

Топология сервиса (svc-topo)

Служит для указания требуемой топологии сервиса VPN.

Служба доставки кадров (frame-delivery)

Определяет поддержку доставки кадров, требуемую для L2VPN, например, групповая, индивидуальная или широковещательная доставка.

Extranet VPN (extranet-vpns)

Указывает, что для конкретной VPN требуется доступ к ресурсам, находящимся в других VPN.

5.2.1. Тип сервиса VPN

Параметр vpn-svc-type определяет тип сервиса для предоставляемых провайдером услуг L2VPN. Текущая версия модели поддерживает шесть вариантов:

  • VPWS «точка-точка» для соединения двух сайтов абонента;

  • VPWS «точка-точка» или «точка-многоточка» для соединения множества сайтов абонента [RFC8214];

  • многоточечные VPLS для соединения множества сайтов абонента;

  • многоточечные VPLS для соединения одного или множества корневых сайтов с набором отделений (leaf site), но без связи между этими отделениями;

  • EVPN [RFC7432] для соединения множества сайтов абонента;

  • EVPN VPWS между двумя или множеством сайтов абонента, как указано в [RFC8214].

Другие типы сервиса L2VPN могут включаться через дополнения. Отметим, что сервис EPL27 или EVPL28 относится к типу E-Line29 [MEF-6] или EVC30, а сервис EP-LAN31 или EVP-LAN32 — к типу E-LAN33 [MEF-6] или многоточечному EVC.

5.2.2. Топология сервиса VPN

Рассматриваемые здесь типы топологии сервиса VPN могут при необходимости использоваться для настройки конфигурации. Описанный в документе модуль поддерживает полносвязные соединения (any-to-any), звезду (Hub-and-Spoke, где концентраторы могут обмениваться трафиком) и Hub-and-Spoke Disjoint (концентраторы не могут обмениваться трафиком). Новые варианты топологии могут быть реализованы в дополнениях. По умолчанию применяется топология any-to-any.

5.2.2.1. Выделение RT

Основанные на PE услуги L2 VPN (такие как VPLS и EVPN с применением BGP в качестве сигнального протокола) могут строиться с использованием целей маршрутов (RT34), как описано в [RFC4364] и [RFC7432]. Предполагается, что система управления автоматически выделяет набор RT при получении запроса на организацию сервиса VPN. Способ выделения RT системой управления выходит за рамки документа, но можно предусмотреть несколько вариантов, как описано в параграфе 6.2.1.1 [RFC8299].

5.2.2.2. Каждый с каждым (Any-to-Any)
+--------------------------------------------------------------+
|  VPN1_Site 1 ------ PE1               PE2 ------ VPN1_Site 2 |
|                                                              |
|  VPN1_Site 3 ------ PE3               PE4 ------ VPN1_Site 4 |
+--------------------------------------------------------------+

Рисунок 5. Топология сервиса Any-to-Any VPN.


В топологии сервиса VPN «any-to-any » все сайты VPN могут взаимодействовать между собой без ограничений. В этой модели предполагается, что система управления, получающая запрос на организацию сервиса any-to-any L2VPN, назначит, а затем настроит MAC-VRF и RT на соответствующих устройствах PE. Для полносвязной топологии в общем случае требуется одно значение RT и каждая таблица MAC-VRF импортирует и экспортирует это значение RT.

5.2.2.3. Концентратор и лучи (Hub-and-Spoke)
+---------------------------------------------------------------+
|   Hub_Site 1 ------ PE1               PE2 ------ Spoke_Site 1 |
|                          +------------------------------------+
|                          |
|                          +------------------------------------+
|   Hub_Site 2 ------ PE3               PE4 ------ Spoke_Site 2 |
+---------------------------------------------------------------+

Рисунок 6. Топология сервиса Hub-and-Spoke VPN.


В топологии сервиса VPN Hub-and-Spoke

  • все сайты-лучи (Spoke) могут взаимодействовать только с сайтами-концентраторами (Hub), т. е. лучи не могут взаимодействовать между собой;

  • концентраторы могут взаимодействовать между собой.

В этой модели предполагается, что система управления, получившая запрос на организацию сервиса Hub-and-Spoke L2VPN, назначит, а затем настроит MAC-VRF и RT на соответствующих устройствах PE. Для Hub-and-Spoke обычно нужны два значения RT (одно для Hub-маршрутов, другое для Spoke). Таблица Hub MAC-VRF, подключающая Hub-сайты, будет экспортировать Hub-маршруты с Hub RT и импортировать Spoke-маршруты через Spoke RT. Будут также импортироваться Hub RT для поддержки коммуникаций между Hub-сайтами. Таблица Spoke MAC-VRF, подключающая Spoke-сайты, будет экспортировать Spoke-маршруты со Spoke RT и импортировать Hub-маршруты через Hub RT.

5.2.2.4. Hub-and-Spoke Disjoint
+---------------------------------------------------------------+
|   Hub_Site 1 ------ PE1               PE2 ------ Spoke_Site 1 |
+--------------------------+  +---------------------------------+
                           |  |
+--------------------------+  +---------------------------------+
|   Hub_Site 2 ------ PE3               PE4 ------ Spoke_Site 2 |
+---------------------------------------------------------------+

Рисунок 7. Топология сервиса Hub-and-Spoke-Disjoint VPN.


В топологии сервиса VPN Hub-and-Spoke-Disjoint

  • все сайты-лучи (Spoke) могут взаимодействовать только с сайтами-концентраторами (Hub), т. е. лучи не могут взаимодействовать между собой;

  • концентраторы не могут взаимодействовать между собой.

В этой модели предполагается, что система управления, получившая запрос на организацию сервиса Hub-and-Spoke-Disjoint L2VPN назначит, а затем настроит VRF и RT для соответствующих устройств PE. В случае Hub-and-Spoke-Disjoint требуется по меньшей мере два значения RT (хотя бы одно для Hub-маршрутов и хотя бы одно для Spoke). Таблица Hub VRF, подключающая сайты Hub, будет экспортировать Hub-маршруты с RT и импортировать Spoke-маршруты через Spoke RT. Таблица Spoke VRF, подключающая сайты Spoke, будет экспортировать Spoke-маршруты со Spoke RT и импортировать Hub-маршруты через Hub RT.

Система управления должна учитывать ограничения для соединений Hub-and-Spoke как в предыдущем случае.

Топологию Hub-and-Spoke Disjoint можно рассматривать как множество Hub-and-Spoke VPN (одна сеть на Hub), использующих общий набор сайтов Spoke.

5.2.3. Доступ к облаку

Эта модель предполагает настройку доступа к облаку через контейнер cloud-access. Использование контейнера cloud-access нацелено на доступ к облачным службам общего пользования и в Internet. Контейнер cloud-access обеспечивает параметры правил предоставления полномочий. Отметим, что в этой модели предполагается некая общность доступа к облакам общего пользования и сети Internet, поэтому такие варианты доступа не различаются. При необходимости для доступа в Internet можно добавить отдельную метку путем дополнения.

Доступ к частным облакам можно организовать через контейнер site, как описано в параграфе 5.3, с использованием совместимого с сайтом типа интерфейса NNI.

Идентификатор облака служит для указания целевого сервиса. Этот идентификатор является локальным для административного домена.

По умолчанию всем сайтам в L2VPN следует разрешать доступ в облако или Internet. Если требуются ограничения, пользователь может настроить некоторые ограничения для отдельных сайтов или узлов с помощью правил, т. е. листа-списка permit-site или deny-site. Лист-список permit-site определяет список сайтов, имеющих полномочия для доступа к облаку, deny-site определяет сайты, которым доступ запрещен. Модель поддерживает варианты deny-any-except (запрет всем кроме …) и permit-any-except (разрешить всем кроме …).

Настройка ограничений в сетевых элементах выходит за рамки документа.

          L2VPN
++++++++++++++++++++++++++++++++     ++++++++++++
+            Сайт 3            + --- + Облако 1 +
+ Сайт 1                       +     ++++++++++++
+                              +
+ Сайт 2                       + --- ++++++++++++
+                              +     + Internet +
+            Сайт 4            +     ++++++++++++
++++++++++++++++++++++++++++++++
             |
        ++++++++++++
        + Облако 2 +
        ++++++++++++

Рисунок 8. Пример конфигурации доступа в облако.


На рисунке 8 показан пример VPN с глобальным доступом в Internet путем создания контейнера cloud-access, указывающего идентификатор контейнера для доступа в Internet (см. приведенный ниже код XML [W3C.REC-xml-20081126]). Уполномоченных сайтов не задано, поскольку доступ в Internet нужен для всех сайтов.

    <?xml version="1.0"?>
       <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
       <vpn-services>
       <vpn-service>
       <vpn-id>123456487</vpn-id>
      <cloud-accesses>
       <cloud-access>
          <cloud-identifier>INTERNET</cloud-identifier>
       </cloud-access>
      </cloud-accesses>
      <ce-vlan-preservation>true</ce-vlan-preservation>
      <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
      </vpn-service>
      </vpn-services>
    </l2vpn-svc>

Если Сайтам 1 и 2 нужно доступ в Облако 1, создается новый контейнер cloud-access с идентификатором Облака 1. Лист-список permit-site в нем указывает Сайты 1 и 2.

    <?xml version="1.0"?>
       <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
        <vpn-services>
         <vpn-service>
         <vpn-id>123456487</vpn-id>
         <cloud-accesses>
          <cloud-access>
            <cloud-identifier>Cloud1</cloud-identifier>
            <permit-site>site1</permit-site>
            <permit-site>site2</permit-site>
          </cloud-access>
         </cloud-accesses>
        <ce-vlan-preservation>true</ce-vlan-preservation>
        <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
       </vpn-service>
       </vpn-services>
    </l2vpn-svc>

Если всем сайтам кроме Сайта 1 нужен доступ в Облако 2, создается контейнер cloud-access с идентификатором Облака 2, в котором лист-список deny-site указывает Сайт 1.

    <?xml version="1.0"?>
      <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
        <vpn-services>
         <vpn-service>
           <vpn-id>123456487</vpn-id>
            <cloud-accesses>
             <cloud-access>
              <cloud-identifier>Cloud2</cloud-identifier>
              <deny-site>site1</deny-site>
            </cloud-access>
           </cloud-accesses>
          <ce-vlan-preservation>true</ce-vlan-preservation>
          <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
        </vpn-service>
      </vpn-services>
    </l2vpn-svc>

5.2.4. Сети Extranet VPN

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

            +-----------+           +-----------+
           /             \         /             \
Сайт A -- |    VPN A      |  ---  |    VPN B      | --- Сайт B
           \             /         \             /      (общие
            +-----------+           +-----------+        ресурсы)

Рисунок 9. Пример общего ресурса VPN.


Как показано на рисунке 9, VPN B имеет на Сайте B отдельные ресурсы, которые должны быть доступны некоторым абонентам/партнерам. В частности, для VPN A должен обеспечиваться доступ к этим ресурсам VPN B.

Такие варианты связи между VPN могут быть реализованы на основе политики VPN, как описано в параграфе 5.5.2.2. Однако в некоторых простых случаях отдельной сети VPN (VPN A) нужен доступ ко всем ресурсам другой VPN (VPN B). Модель обеспечивает простой способ такого соединения за счет использования контейнера extranet-vpns.

Контейнер extranet-vpns определяет список VPN, к которым заданная сеть VPN хочет получить доступ. Контейнеры extranet-vpns используются в абонентских VPN, требующих доступа к ресурсам других VPN. На рисунке 9 для предоставления VPN A доступа в VPN B нужно настроить контейнер extranet-vpns для VPN A с записью, соответствующей VPN B. Настроек сервиса для VPN B не требуется.

Следует отметить, что не требуется настраивать конфигурацию VPN B, если в VPN A эта VPN B указана как внешняя сеть (extranet). Все сайты VPN B будут доступны всем сайтам VPN A.

Лист site-role указывает роль локальных сайтов VPN в топологии сервиса extranet VPN. Определения ролей приведены в параграфе 5.4.

В приведенном ниже примере VPN A обращается к ресурсам VPN B через соединение extranet. Для сайтов VPN A нужна роль Spoke, поскольку этим сайтам не разрешается взаимодействовать между собой через соединение extranet.

     <?xml version="1.0"?>
       <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
        <vpn-services>
          <vpn-service>
            <vpn-id>VPNB</vpn-id>
              <svc-topo>hub-spoke</svc-topo>
             <ce-vlan-preservation>true</ce-vlan-preservation>
             <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
          </vpn-service>
          <vpn-service>
             <vpn-id>VPNA</vpn-id>
               <svc-topo>any-to-any</svc-topo>
                  <extranet-vpns>
                    <extranet-vpn>
                     <vpn-id>VPNB</vpn-id>
                     <local-sites-role>spoke-role</local-sites-role>
                   </extranet-vpn>
                 </extranet-vpns>
             <ce-vlan-preservation>true</ce-vlan-preservation>
             <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
         </vpn-service>
       </vpn-services>
      </l2vpn-svc>

Эта модель не определяет способов создания конфигурации extranet в сети.

В любом более сложном варианте соединений между VPN (например, доступ лишь некоторых сайтов VPN A только к некоторой части сайтов VPN B) требуется присоединение VPN, описанное в параграфе 5.5.2, и, в частности, политика VPN, описанная в параграфе 5.5.2.2.

5.2.5. Услуги доставки кадров

Если для L2VPN поддерживается доставка индивидуальных кадров с неизвестными адресами, а также групповых и широковещательных кадров (BUM), при запросе сервиса потребуется указать некоторые глобальные параметры доставки кадров. Когда CE передает пакеты BUM, на входном PE выполняется репликация и необходимо поддерживать три типа кадров.

Пользователи этой модели должны обеспечить варианты деревьев, которые будут применяться абонентами в L2VPN (customer-tree-flavors). Определенная в документе модель поддерживает двунаправленные (bidirectional), совместно используемые (shared) и основанные на источнике (source-based) деревья, а с помощью дополнений могут поддерживаться другие типы. Одновременно может использоваться множество типов деревьев.

                          Сеть оператора
                          ______________
                         /              \
                        |                |
                        |                |
Recv -- Сайт 2 ------- PE2               |
                        |               PE1 --- Сайт 1 --- Источник 1
                        |                |        \
                        |                |         -- Источник 2
                        |                |
                        |                |
Recv -- Сайт 3 ------- PE3               |
                        |                |
                        |                |
Recv -- Сайт 4 ------- PE4               |
                      / |                |
Recv -- Сайт 5 -------  |                |
                        |                |
                        |                |
                         \______________/

Рисунок 10. Пример услуг доставки кадров BUM.


Отображения multicast-групп на порты могут быть созданы с использованием листа rp-group-mappings. Поддерживается два метода отображения:

  • статическая настройка групповых адресов Ethernet и портов (интерфейсов);

  • протокол управления групповой адресацией на основе технологии L2, обеспечивающей сигнализацию сопоставления групповых адресов с портами (интерфейсами), такой как GARP35/GMRP36 [IEEE-802-1D].

5.3. Обзор сайтов

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

                                               +-------------+
                                              /               \
                                       +-----|      VPN1       |
+------------------+                   |      \               /
|                  |                   |       +-------------+
| Офис в Нью-Йорке |------ (сайт) -----+
|                  |                   |       +-------------+
+------------------+                   |      /               \
                                       +-----|      VPN2       |
                                              \               /
                                               +-------------+

Рисунок 11. Офис абонента с двумя услугами VPN.


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

Мы ограничиваем L2SM внешними интерфейсами (т. е. интерфейсами UNI и NNI), поскольку внутренние интерфейсы и базовая топология выходят за рамки L2SM.

Обычно в организации сервиса нужно документировать перечисленные ниже характеристики интерфейса сайта.

Уникальный идентификатор (site-id)

Произвольная строка, однозначно указывающая сайт в общей сетевой инфраструктуре. Формат site-id определяется локальным администратором сервиса VPN.

Устройство (device)

Абонент может запросить подключение одного или множества устройств CPE к SP для отдельного сайта.

Управление (management)

Определяет модель управления для сайта. Например, тип, транспорт системы управления, адрес. Эти параметры задают границу между SP и абонентом, т. е. владение устройством CE.

Местоположение (location)

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

Отличия сайта (site-diversity)

Представляет те или иные параметры для поддержки разнообразных сайтов.

Доступ сайта к сети (site-network-accesses)

Указывает список портов для сайта и их свойства, в частности параметры носителя (bearer), соединения и сервиса.

Объект site-network-access представляет логическое соединение Ethernet для сайта. Сайт может иметь множество site-network-access.

+------------------+             Сайт
|                  |-------------------------------------
|                  |****** (site-network-access#1) ******
| Офис в Нью-Йорке |
|                  |****** (site-network-access#2) ******
|                  |-------------------------------------
+------------------+

Рисунок 12. Два объекта Site-Network-Access для сайта.


Множество site-network-access используется, например, при многодомных подключениях и в некоторых других случаях.

Конфигурация сайта представляется глобальным элементом, предполагается, что роль системы управления заключается в разделении параметров между разными элементами внутри сети. Например, в случае конфигурации site-network-access система управления должна разделить параметры конфигурации между устройствами PE и CE.

Сайт может иметь однодомное или многодомное подключение. Во втором случае сайт может поддерживать множество site-network-access, в каждом из которых определяется элемент vpn-attachment (подключение к VPN), связывающий site-network-access с данным сайтом, а также указывающий сеть VPN, к которой сайт будет подключен.

5.3.1. Устройства и площадки

Информация в субконтейнере location контейнера site и в контейнере devices позволяет легко отыскать данные о ближайших доступных точках подключения и может применяться для планирования топологии доступа. Она может также использоваться другими компонентами оркестровки сети для выбора восходящего PE и нисходящего CE. Местоположение указывается в терминах почтовой адресации. Более подробные сведения о месте расположения можно указать с помощью дополнений.

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

  Сайт в Нью-Йорке
+------------------+             Сайт
| +--------------+ |-------------------------------------
| | Манхэттен    | |****** (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Бруклин      | |****** (site-network-access#2) ******
| +--------------+ |-------------------------------------
+------------------+

Рисунок 13. Два сайта, два Site-Network-Access.


Абонент может также запросить использование некоторых элементов оборудования (CE) у SP через контейнер devices. Для запрашиваемых CE предполагается управление со стороны провайдера или совместное управление. Может быть запрошено конкретное устройство для конкретной, уже включенной в конфигурацию площадки. Это позволит SP отправить устройство по указанному почтовому адресу. Для сайта с множеством площадок абонент может, например, запросить CE на каждую площадку, где требуется многодомное подключение. В примере на рисунке 13 одно устройство может быть запрошено для площадки на Манхэттене, другое — для площадки в Бруклине.

Используя контейнеры devices и locations, абонент может влиять на организацию многодомного подключения — одно устройство CE, два CE и т. д.

5.3.2. Доступ сайта в сеть

L2SM включает важный набор свойств физических интерфейсов и характеристик уровня Ethernet в контейнере site-network-accesses. Некоторые из них являются важными параметрами реализации, которые должны быть согласованы между абонентом и провайдером.

Как отмечено выше, сайт может быть многодомным. Каждое логическое подключение для сайта определяется контейнером site-network-accesses. Параметр site-network-access определяет способ подключения сайта к сети и включает три основных класса параметров:

  • bearer определяет требования к подключению (ниже уровня L2);

  • connection определяет параметры L2 для подключения;

  • availability определяет политику доступности сайта в соответствии с определениями параграфа 5.8.

Параметр site-network-access имеет конкретный тип. Данный документ определяет 2 типа:

  • point-to-point — соединение типа «точка-точка» между SP и абонентом;

  • multipoint — многоточечное соединение между SP и абонентом.

Тип site-network-access может влиять на параметры, предлагаемые абоненту. Например, SP может не предлагать предоставление защиты от петель MAC при многоточечном доступе. Провайдер сам принимает решение о поддерживаемых параметрах доступа для point-to-point и/или multipoint. Многоточечный доступ выходит за рамки документа. Некоторые контейнеры, определенные в этой модели, могут потребовать расширения для корректной работы при многоточечном доступе.

5.3.2.1. Контейнер bearer

Контейнер bearer определяет требования для подключения сайта (ниже уровня L2) к сети провайдера.

Параметры bearer помогают определить тип используемой для доступа среды передачи.

5.3.2.2. Контейнер connection

Контейнер connection определяет протокольные параметры L2 для подключения (например, vlan-id или circuit-id) и обеспечивают связность между абонентскими коммутаторами Ethernet. В зависимости от режима управления они относятся к адресации сегмента «PE-CE-ЛВС» или «CE-ЛВС абонента». В любом случае они описывают границу разделения ответственности между абонентом и провайдером. Для управляемого абонентом сайта параметры относятся к сегменту соединения «PE-CE-ЛВС», а для управляемого провайдером — к сегменту «CE-ЛВС абонента».

Параметр encapsulation-type позволяет абоненту выбрать инкапсуляцию Ethernet (доступ по портам) или Ethernet VLAN (доступ по VLAN). Все разрешенные типом интерфейса Ethernet (например, с тегами, без тегов, LAG) сервисные кадры могут быть указаны в ether-inf-type.

В соответствии с ether-inf-type контейнер connection представляет также три набора атрибутов канала для интерфейсов с тегами и без тегов, а также необязательного интерфейса LAG. Эти параметры важны для корректной организации соединения между устройствами CE и PE. Контейнер connection определяет также атрибут L2CP37, обеспечивающий протокольное взаимодействие на уровне управления между устройствами CE и PE.

5.3.2.2.1. Интерфейс без тегов

Для каждого интерфейса без тегов (untagged-interface) имеются базовые параметры, такие как индекс и скорость, MTU, настройки автосогласования и управления потоком данных и т. п. В дополнение к этому на основе взаимного соглашения между абонентом и провайдером могут указываться дополнительные возможности — LLDP, IEEE 802.3ah [IEEE-802-3ah] или обнаружение/предотвращение петель MAC на интерфейсе UNI. Если требуется предотвращение петель, для атрибута uni-loop-prevention должно быть установлено значение true.

5.3.2.2.2. Интерфейс с тегами

Если на логическом модуле соединения для интерфейса включены услуги с тегами, в качестве encapsulation-type следует указывать инкапсуляцию Ethernet VLAN (при работе на основе VLAN) или VXLAN, а также следует установить в eth-inf-type индикацию использования тегов.

В дополнение к этому следует указать tagged-interface-type в контейнере tagged-interface для задания режима использования тегов. Текущая модель определяет пять режимов установки тегов VLAN:

  • priority-tagged — SP инкапсулируют и помечают пакеты между CE и PE уровнем приоритета для кадра;

  • dot1q-vlan-tagged — SP инкапсулируют пакеты между CE и PE с одним или множеством абонентских идентификаторов VLAN (CVLAN38);

  • qinq — SP инкапсулируют пакеты на входе в свои сети с множеством идентификаторов CVLAN и одним тегом SP VLAN (SVLAN);

  • qinany — SP инкапсулируют пакеты на входе в свои сети с неизвестными CVLAN и одним тегом SVLAN;

  • vxlan — SP инкапсулирует пакеты на входе в свои сети и идентификатором VNI39 и списком партнеров.

Общий S-tag для устройства Ethernet и (если применимо) отображение C-tag на SVC40 помещаются в контейнер service. Для вариантов qinq и qinany значению S-tag в qinq и qinany в большинстве случаев следует соответствовать значению S-tag в контейнере service, однако в некоторых системах требуется трансляция VLAN для S-tag на обращенном наружу интерфейсе или восходящих PE для «нормализации» внешнего тега VLAN в S-tag сервиса на входе в сеть и обратной трансляции в S-tag при выходе из сети. Одним из примеров является агрегирующий коммутатор L2 на пути — S-tag для SVC ранее был назначен другому сервису и не может использоваться этим AC.

5.3.2.2.3. Интерфейс LAG

Иногда абонентам может потребоваться сборка множества физических каналов в одно логическое соединение LAG (точка-точка) с SP. Обычно на таких соединения применяется протокол LACP41 для динамического добавления или удаления каналов в группу-агрегат. В общем случае LAG позволяет расширить пропускную способность сервиса по сравнению с одиночным каналом, обеспечивая аккуратное снижение пропускной способности при отказе канала в группе, а также повышение уровня доступности.

В L2SM имеется набор атрибутов (под lag-interface), связанных с агрегированием каналов. Абонент и провайдер сначала должны решить, будет ли выполняться обмен LACP PDU между краевыми устройствами, и выбрать для LACP-state значение on или off. При включенном протоколе LACP обе стороны должны указать, (1) будет LACP работать в пассивном или активном режиме и (2) задать временной интервал и уровень приоритета для LACP PDU. Абонент и провайдер могут также определить минимальную пропускную способность агрегата LAG, которая считается допустимой, путем задания необязательного атрибута mini-link-num. Для включения быстрого детектирования отказов на каналах через независимые сессии UDP работает микро-BFD42 [RFC7130] для мониторинга состояния каждого канала в группе. Абоненту и провайдеру следует согласовать интервал BFD hello и время удержания.

Каждый канал группы указывается под интерфейсом LAG с базовыми свойствами физического канала. Некоторые атрибуты, такие как управление потоком данных, тип инкапсуляции, разрешенные Ethertype на входе и установки LLDP задаются на уровне LAG.

5.3.2.2.4. Отображение CVLAN-ID на SVC

Когда более одного сервиса мультиплексируется в один интерфейс, входящие кадры передаются в один из экземпляров сервиса L2VPN в соответствии с заранее согласованным сопоставлением абонентских VLAN с SVC. Множество CVLAN может передаваться через один канал SVC. Тип группировки будет определять связывание множества CVLAN в одном экземпляре сервиса VPN (т. е. группировку VLAN).

Когда это применимо, отображение cvlan-id-to-svc-map содержит список CVLAN, отображенных на один сервис. В большинстве случаев это будет списком доступа по VLAN из внутреннего тега 802.1Q [IEEE-802-1Q] (C-tag).

Сервис VPN можно настроить на сохранение CE-VLAN ID и CE-VLAN CoS от сайта-источника до сайта-получателя. Это нужно в тех случаях, когда абонент хочет использовать информацию из заголовка VLAN на обоих сайтах. Сохранение CE-VLAN ID и CE-VLAN CoS применяется в каждом site-network-access на сайтах. Это сохранение означает, что CE-VLAN ID и/или CE-VLAN CoS на стороне отправителя должны совпадать со значениями этих полей на стороне сайта-получателя, относящегося к тому же сервису L2VPN.

Если разрешена группировка для всех сайтов (тип группировки all-to-one), сохранение применяется для всех входящих кадров сервиса. Если группировка не включена, сохранение применяется для входящих кадров с тегом CE-VLAN ID.

5.3.2.2.5. Поддержка управления L2CP

Абоненту и SP следует заранее согласовать вопрос разрешения протокольных взаимодействий между CE и PE на уровне управления. Для обеспечения эффективной доставки группового трафика абоненты могут применять протоколы управления Ethernet (например, STP43 [IEEE-802-1D]).

Для поддержки эффективной динамической доставки могут использоваться кадры управления групповой передачей Ethernet (например, GARP/GMRP [IEEE-802-1D]) между устройствами CE и PE. Однако недопустимо предполагать, что все CE всегда используют такие протоколы (например, CE может быть маршрутизатором или не знать деталей L2).

MAC-адреса получателей в L2CP PDU относятся к двум резервным блокам, заданным рабочей группой IEEE 802.1. Для пакетов с MAC-адресом получателя из указанных ниже групповых диапазонов применяются особые правила пересылки.

  • Протоколы мостов — 01-80-C2-00-00-00 — 01-80-C2-00-00-0F.

  • Протоколы MRP — 01-80-C2-00-00-20 — 01-80-C2-00-00-2F.

Туннелирование протоколов L2 позволяет SP передавать абонентские L2 PDU через сеть без интерпретации и обработки на промежуточных устройствах. Эти L2CP PDU инкапсулируются с использованием QinQ для передачи через ядро сети с поддержкой MPLS.

Контейнер L2CP-control содержит список обычно используемых протоколов и параметров L2CP. SP может задать для каждого отдельного протокола режим отбрасывания (discard-mode), партнерства (peer-mode) или туннелирования (tunnel-mode).

5.3.2.2.6. Ethernet Service OAM

Применение Ethernet в качестве технологии распределенных сетей предъявляет дополнительные требования к сквозному мониторингу сервиса и контролю отказов в сетях SP, особенно в части доступности сервиса и среднего времени восстановления (MTTR44). Ethernet Service OAM в контексте L2SM означает комбинацию протоколов IEEE 802.1ag [IEEE-802-1ag] и ITU-T Y.1731 [ITU-T-Y-1731].

Вообще говоря, Ethernet Service OAM позволяет SP проверять непрерывность предоставления услуг, изолировать отказы, измерять задержки и их вариации на уровне абонента и доступа сайта в сеть. Информация Ethernet Service OAM дополняет данные других инструментов верхних уровней IP/MPLS OSS для обеспечения SLA.

Функциональная модель обработки отказов 802.1ag CFM45 структурирована в иерархические домены MD46, каждому из которых назначается уникальный уровень обслуживания. MD верхних уровней могут быть вложены в MD нижних уровней, однако домены MD не могут пересекаться. Область действия каждого домена MD полностью находится в сети абонента или сети SP. Домены MD могут взаимодействовать между CE и PE (от абонента к провайдеру) или между PE (взаимодействие провайдеров), а также могут туннелироваться через другую сеть SP.

В зависимости от варианта применения несколько точек MEP47 может размещаться на обращенном наружу интерфейсе, передавая CFM PDU в направлении ядра сети (Up MEP) или в нисходящий канал (Down MEP).

Субконтейнер cfm-802.1-ag в контейнере site-network-access представляет ассоциацию обслуживания CFM MA48, т. е. Down MEP для UNI MA. Для каждой ассоциации MA пользователь может задать идентификатор MAID49, уровень и направление MEP, Remote MEP ID, уровень CoS для CFM PDU, интервал и время удержания сообщений проверки связности (CCM50), уровень генерации сигналов об отказе (т. е. самый низкий приоритет, при котором генерируется сигнал об отказе), тип приоритета CCM и т. п.

Мониторинг производительности ITU-T Y.1731 (PM51) обеспечивает важную телеметрическую информацию, которая включает задержку кадров Ethernet и ее вариации, потери кадров и пропускную способность для кадров. Измерения задержки и ее вариаций могут выполняться в одном или обоих направлениях. Обычно зонд Y.1731 PM передает небольшое число синтетических кадров вместе с обычными кадрами для измерения параметров SLA.

Субконтейнер y-1731 в контейнере site-network-access содержит набор данных для определения параметров зонда PM, включая MAID, локальный и удаленный идентификатор MEP ID, тип PM PDU, период сообщений и интервал измерения, уровень CoS для PM PDU, опции измерения по синтетическим или естественным кадрам, одно или два направления для измерений, размер кадров PM и тип сессии.

5.4. Роли сайта

Сервис VPN имеет определенную топологию, как описано в параграфе 5.2.2. В результате каждому сайту, относящемуся к VPN, назначается в этой топологии определенная роль. Лист site-role указывает роль сайта в конкретной топологии VPN.

В топологии any-to-any (каждый с каждым) все сайты должны играть одну роль — any-to-any-role.

В топологии Hub-and-Spoke или Hub-and-Spoke-Disjoint сайты должны играть роль Hub или Spoke.

5.5. Сайты, входящие в несколько VPN

5.5.1. Варианты VPN на сайте

Сайт может входить в одну или множество сетей VPN и site-vpn-flavor указывает способ мультиплексирования VPN. Возможны 4 типа обращенных наружу соединений, связанных с сервисом EVPN и сайтом. Поэтому модель поддерживает четыре варианта:

  • site-vpn-flavor-single — сайт входит в единственную сеть VPN;

  • site-vpn-flavor-multi — сайт включен во множество VPN и все логические соединения сайтов относятся к одному набору VPN;

  • site-vpn-flavor-nni — сайт представляет интерфейс NNI, где соединяются два административных домена, относящихся к одному или разным провайдерам;

  • site-vpn-flavor-e2e — сайт представляет сквозное многосегментное соединение.

5.5.1.1. Одно подключение — site-vpn-flavor-single

На рисунке 14 показано подключение сайта к одной сети VPN.

                                                   +--------+
+------------------+             Сайт             /          \
|                  |-----------------------------|            |
|                  |***(site-network-access#1)***|    VPN1    |
| Офис в Нью-Йорке |                             |            |
|                  |***(site-network-access#2)***|            |
|                  |-----------------------------|            |
+------------------+                              \          /
                                                   +--------+

Рисунок 14. Одно подключение к VPN.


5.5.1.2. Множество подключений — site-vpn-flavor-multi

На рисунке 15 показано подключение сайта к множеству VPN.

                                                        +---------+
                                                   +---/----+      \
+------------------+             Сайт             /   |      \      |
|                  |--------------------------------- |       |VPN B|
|                  |***(site-network-access#1)******* |       |     |
| Офис в Нью-Йорке |                             |    |       |     |
|                  |***(site-network-access#2)*******  \      |    /
|                  |-----------------------------| VPN A+-----|---+
+------------------+                              \          /
                                                   +--------+

Рисунок 15. Подключение к множеству VPN.


Офис в Нью-Йорке на рисунке 15 является многодомным. Для обоих логических соединений применяются одинаковые правила подключения к VPN и оба соединения относятся к VPN A и VPN B.

Доступ к VPN A или VPN B из офиса в Нью-Йорке выполняется на основе пересылки по MAC-адресу получателя. Возможность доступа к одному адресату из двух VPN может создавать проблемы маршрутизации. В этом случае роль администратора абонентской сети заключается в подходящем отображении MAC-адресов каждой VPN. Более подробное описание приведено в параграфах 5.5.2 и 5.10.2, а поддержка BUM рассмотрена в параграфе 5.10.3.

5.5.1.3. NNI — site-vpn-flavor-nni

Вариант с межсетевым соединением (NNI) можно промоделировать, используя контейнер sites. Для SP полезно указать, что запрашиваемое соединение VPN не относится к обычному сайту, а является NNI, поскольку в этом случае могут по умолчанию применяться другие параметры конфигурации (например, ACL52, правила маршрутизации).

         SP A                                         SP B
  -------------------                         -------------------
 /                   \                       /                   \
|                     |                     |                     |
|                 ++++++++Канал между AS ++++++++                 |
|                 +      +_______________+      +                 |
|                 + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+                 |
|                 +      +               +      +                 |
|                 + ASBR +               + ASBR +                 |
|                 +      +               +      +                 |
|                 + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+                 |
|                 +      +_______________+      +                 |
|                 ++++++++               ++++++++                 |
|                     |                     |                     |
|                     |                     |                     |
|                     |                     |                     |
|                 ++++++++Канал между AS ++++++++                 |
|                 +      +_______________+      +                 |
|                 + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+                 |
|                 +      +               +      +                 |
|                 + ASBR +               + ASBR +                 |
|                 +      +               +      +                 |
|                 + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+                 |
|                 +      +_______________+      +                 |
|                 ++++++++               ++++++++                 |
|                     |                     |                     |
|                     |                     |                     |
 \                   /                       \                   /
  -------------------                         -------------------

Рисунок 16. Сценарий NNI, вариант A.


На рисунке 16 показан вариант A сценария NNI, который можно смоделировать с помощью контейнера sites. Для подключения абонентских VPN (VPN1 и VPN2) к сети SP B провайдер SP A может запросить создание того или иного контейнера site-network-accesses для сети SP B. Можно использовать тип site-vpn-flavor-nni для информирования SP B о том, что это соединение NNI, а не обычное подключение абонента.

5.5.1.4. E2E — site-vpn-flavor-e2e

Сквозное (E2E53) многосегментное соединение VPN организуется из нескольких соединительных сегментов. Для SP будет полезно указать, что запрошенное соединение VPN не является обычным подключением сайта, а служит сквозным соединением VPN, поскольку в случае site-vpn-flavor-e2e по умолчанию могут применяться другие параметры (например, конфигурация QoS). Для организации соединения между Сайтом 1 в SP A и Сайтом 2 в SP B через множество доменов провайдер SP A может запросить организацию сквозного соединения с SP B. Тип site-vpn-flavor-e2e позволяет указать, что это сквозное соединение, а не обычное подключение абонентского сайта.

5.5.2. Присоединение сайта к VPN

По причине наличия множества вариантов site-vpn присоединение сайта к L2VPN выполняется на уровне site-network-access (логический доступ) через контейнер vpn-attachment, который является обязательным. Модель обеспечивает два способа присоединения сайта к VPN:

  • по непосредственной ссылке на целевую сеть VPN;

  • по ссылке на правила присоединения к VPN, которые могут быть более сложными.

Эти опции позволяют пользователю выбрать наиболее подходящий вариант.

5.5.2.1. Указание VPN

Указание vpn-id обеспечивает простой способ привязать конкретное логическое соединение к VPN. Это является лучшим способом для VPN с одним подключением. При указании vpn-id должна добавляться роль сайта (site-role) в топологии целевого сервиса VPN.

    <?xml version="1.0"?>
    <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
     <vpn-services>
        <vpn-service>
          <vpn-id>VPNA</vpn-id>
          <ce-vlan-preservation>true</ce-vlan-preservation>
          <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
        </vpn-service>
        <vpn-service>
          <vpn-id>VPNB</vpn-id>
          <ce-vlan-preservation>true</ce-vlan-preservation>
          <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
        </vpn-service>
     </vpn-services>
     <sites>
       <site>
        <site-id>SITE1</site-id>
       <locations>
        <location>
         <location-id>L1</location-id>
        </location>
       </locations>
       <management>
        <type>customer-managed</type>
          </management>
           <site-network-accesses>
            <site-network-access>
             <network-access-id>LA1</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                     </bandwidth>
                    </svc-bandwidth>
                     <carrierscarrier>
                       <signaling-type>bgp</signaling-type>
                     </carrierscarrier>
                     <svc-mtu>1514</svc-mtu>
                   </service>
            <vpn-attachment>
             <vpn-id>VPNA</vpn-id>
             <site-role>spoke-role</site-role>
            </vpn-attachment>
           </site-network-access>
           <site-network-access>
            <network-access-id>LA2</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                     </bandwidth>
                    </svc-bandwidth>
                     <carrierscarrier>
                       <signaling-type>bgp</signaling-type>
                     </carrierscarrier>
                     <svc-mtu>1514</svc-mtu>
                   </service>
            <vpn-attachment>
             <vpn-id>VPNB</vpn-id>
             <site-role>spoke-role</site-role>
            </vpn-attachment>
           </site-network-access>
          </site-network-accesses>
      </site>
     </sites>
    </l2vpn-svc>

Приведенный выше пример описывает случай множества VPN, где сайт (SITE1) имеет два логических подключения (LA1 и LA2) к сетям VPNA и VPNB.

5.5.2.2. Политика VPN

Список vpn-policy позволяет описать вариант с множеством VPN, где логические подключения относятся к разным VPN.

Поскольку сайт может входить в несколько VPN, список vpn-policy может включать множество записей. Можно использовать фильтр для выбора ЛВС на сайте, которые будут частью определенной сети VPN. Сайт может включать множество сегментов ЛВС, каждый из которых может быть подключен к своей сети VPN. Каждый раз при подключении сайта (или ЛВС) к VPN пользователь должен точно указать его роль (site-role) в топологии целевого сервиса VPN.

+---------------------------------------------------------------+
|       Сайт 1 ------ PE7                                       |
+-------------------------+                 [VPN2]              |
                          |                                     |
+-------------------------+                                     |
|       Сайт 2 ------ PE3               PE4 ------ Сайт 3       |
+-----------------------------------+                           |
                                    |                           |
+-------------------------------------------------------------+ |
|       Сайт 4 ------ PE5           |   PE6 ------ Сайт 5     | |
|                                                             | |
|                      [VPN3]                                 | |
+-------------------------------------------------------------+ |
                                   |                            |
                                   +----------------------------+

Рисунок 17. Пример политики VPN.


На рисунке 17 Сайт 5 входит в VPN3 и VPN2, выступая в качестве Hub для VPN2 и any-to-any для VPN3. Этот вариант подключения описан ниже.

   <?xml version="1.0"?>
    <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
     <vpn-services>
      <vpn-service>
       <vpn-id>VPN2</vpn-id>
       <ce-vlan-preservation>true</ce-vlan-preservation>
       <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
      </vpn-service>
      <vpn-service>
       <vpn-id>VPN3</vpn-id>
       <ce-vlan-preservation>true</ce-vlan-preservation>
       <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
      </vpn-service>
     </vpn-services>
     <sites>
        <site>
       <locations>
        <location>
         <location-id>L1</location-id>
        </location>
       </locations>
       <management>
        <type>customer-managed</type>
       </management>
          <site-id>Site5</site-id>
          <vpn-policies>
           <vpn-policy>
            <vpn-policy-id>POLICY1</vpn-policy-id>
            <entries>
             <id>ENTRY1</id>
             <vpn>
              <vpn-id>VPN2</vpn-id>
              <site-role>hub-role</site-role>
             </vpn>
            </entries>
            <entries>
             <id>ENTRY2</id>
             <vpn>
              <vpn-id>VPN3</vpn-id>
              <site-role>any-to-any-role</site-role>
             </vpn>
            </entries>
           </vpn-policy>
          </vpn-policies>
          <site-network-accesses>
           <site-network-access>
            <network-access-id>LA1</network-access-id>
         <site>
          <site-id>SITE1</site-id>
       <locations>
        <location>
         <location-id>L1</location-id>
        </location>
       </locations>
       <management>
        <type>customer-managed</type>
       </management>
          <site-network-accesses>
           <site-network-access>
            <network-access-id>LA1</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                     </bandwidth>
                    </svc-bandwidth>
                     <carrierscarrier>
                       <signaling-type>bgp</signaling-type>
                     </carrierscarrier>
                     <svc-mtu>1514</svc-mtu>
                   </service>
            <vpn-attachment>
             <vpn-id>VPNA</vpn-id>
             <site-role>spoke-role</site-role>
            </vpn-attachment>
           </site-network-access>
           <site-network-access>
            <network-access-id>LA2</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                     </bandwidth>
                    </svc-bandwidth>
                     <carrierscarrier>
                       <signaling-type>bgp</signaling-type>
                     </carrierscarrier>
                     <svc-mtu>1514</svc-mtu>
                   </service>
            <vpn-attachment>
             <vpn-id>VPNB</vpn-id>
             <site-role>spoke-role</site-role>
            </vpn-attachment>
           </site-network-access>
          </site-network-accesses>
         </site>
            <vpn-attachment>
             <vpn-policy-id>POLICY1</vpn-policy-id>
            </vpn-attachment>
           </site-network-access>
          </site-network-accesses>
         </site>
     </sites>
    </l2vpn-svc>

Если требуется более детальное управление подключением к VPN, можно воспользоваться фильтрацией. Например, если сеть LAN1 Сайта 5 должна быть подключена к VPN2 в роли Hub, а LAN2 должна быть подключена к VPN3, можно использовать приведенную ниже конфигурацию.

    <?xml version="1.0"?>
      <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
        <vpn-services>
          <vpn-service>
            <vpn-id>VPN2</vpn-id>
            <ce-vlan-preservation>true</ce-vlan-preservation>
            <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
            </vpn-service>
            <vpn-service>
             <vpn-id>VPN3</vpn-id>
             <ce-vlan-preservation>true</ce-vlan-preservation>
             <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
            </vpn-service>
        </vpn-services>
      <sites>
       <site>
       <locations>
        <location>
         <location-id>L1</location-id>
        </location>
       </locations>
       <management>
        <type>customer-managed</type>
       </management>
             <site-id>Site5</site-id>
             <vpn-policies>
              <vpn-policy>
               <vpn-policy-id>POLICY1</vpn-policy-id>
               <entries>
                <id>ENTRY1</id>
                <filters>
                  <filter>
                    <type>lan</type>
                    <lan-tag>LAN1</lan-tag>
                  </filter>
                </filters>
                <vpn>
                 <vpn-id>VPN2</vpn-id>
                 <site-role>hub-role</site-role>
                </vpn>
               </entries>
               <entries>
                <id>ENTRY2</id>
                <filters>
                  <filter>
                    <type>lan</type>
                    <lan-tag>LAN2</lan-tag>
                  </filter>
                </filters>
                 <vpn>
                 <vpn-id>VPN3</vpn-id>
                 <site-role>any-to-any-role</site-role>
                </vpn>
               </entries>
              </vpn-policy>
             </vpn-policies>
             <site-network-accesses>
              <site-network-access>
               <network-access-id>LA1</network-access-id>
                 <service>
                   <svc-bandwidth>
                      <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                      </bandwidth>
                     </svc-bandwidth>
                      <carrierscarrier>
                         <signaling-type>bgp</signaling-type>
                      </carrierscarrier>
                       <svc-mtu>1514</svc-mtu>
                   </service>
               <vpn-attachment>
                <vpn-policy-id>POLICY1</vpn-policy-id>
               </vpn-attachment>
              </site-network-access>
             </site-network-accesses>
            </site>
           </sites>
         </l2vpn-svc>

5.6. Определение точки подключения сайта

Система управления будет определять для каждого site-network-access на конкретном сайте точку подключения к сети провайдера (например, PE или агрегирующий коммутатор).

Эта модель определяет параметры и ограничения, которые могут влиять на подключение site-network-access.

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

Параметры расположения сайта (параграф 5.6.2) и типа доступа (параграф 5.6.3) влияют на размещение сервиса, выбираемое системой управления.

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

5.6.1. Ограничение — устройство

При управлении со стороны провайдера или совместном управлении абонент может заказать одно или множество устройств на конкретную площадку, которая уже настроена. Абонент может принудительно задать site-network-access для подключения заказанного устройства.

  Сайт в Нью-Йорке
+------------------+             Сайт
| +--------------+ |-------------------------------------
| | Манхэттен    | |
| |           CE1********* (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Бруклин      | |
| |           CE2********* (site-network-access#2) ******
| +--------------+ |
|                  |-------------------------------------
+------------------+

Рисунок 18. Пример ограничений для устройства.


На рисунке 18 site-network-access#1 связывается с устройством CE1 из запроса. SP должен обеспечить это подключение.

5.6.2. Ограничение и параметр — расположение сайта

Обеспечивая этой моделью информация о местоположении может применяться системой управления при поиске PE для подключения сайта (на стороне SP). С каждым подключением сайта к сети должно быть связано конкретное место. Провайдер должен обеспечивать завершение сервиса в указанной точке доступа сайта в сеть (на стороне абонента). Значение country-code в местоположении сайта следует указывать кодом ISO 3166 и оно похоже на метку country, определенную в [RFC4119].

Местоположение site-network-access определяется значением location-flavor. Для сайтов, управляемых провайдером или совместно с ним, предполагается, что пользователь укажет значение device-reference (для устройства), которое свяжет site-network-access с конкретным устройством, заказанным абонентом. Поскольку устройство связано с конкретным местом, в этом случае информация о местоположении определяется по размещению устройства. Если сайт управляется абонентом, предполагается, что пользователь укажет location-reference (для местоположения) и это значение будет указывать уже настроенное местоположение, что поможет в размещении.

                         POP#1 (Нью-Йорк)
                      +---------+
                      |   PE1   |
 Сайт 1 ---...        |   PE2   |
(Атлантик-Сити)       |   PE3   |
                      +---------+

                         POP#2 (Вашингтон)
                      +---------+
                      |   PE4   |
                      |   PE5   |
                      |   PE6   |
                      +---------+

                         POP#3 (Филадельфия)
                      +---------+
                      |   PE7   |
 Сайт 2 CE#1---...    |   PE8   |
(Рестон)              |   PE9   |
                      +---------+

Рисунок 19. Данные о местоположении сайтов.


На рисунке 19 управляемый абонентом Сайт 1 имеет местоположение L1, а для управляемого провайдером Сайта 2 заказано устройство CE (CE#1). Для Сайта 2 указано местоположение L2. При настройке site-network-access для Сайта 1 пользователь должен указать местоположение L1, чтобы система управления знала, что в этом месте организуется доступ. Затем с учетом расстояния система управления может соединить Сайт 1 с PE в Philadelphia POP. При этом могут также учитываться ресурсы, доступные на PE, для точного определения целевого устройства PE (например, менее загруженного). Для Сайта 2 предполагается, что пользователь настроит site-network-access со ссылкой (device-reference) на CE#1, чтобы система управления знала о том, что доступ будет завершаться в месте размещения устройства CE#1, которое должно быть подключено. Для организации подключения на стороне SP в случае использования ближайшего PE, Сайт 2 может быть подключен к Washington POP.

5.6.3. Ограничение и параметр — тип доступа

Система управления должна выбрать среду для подключения сайта (например, xDSL, арендованная линия, Ethernet). Абонент может задать некоторые параметры и/или ограничения, которые помогут системе управления выбрать среду.

Информацию контейнера bearer следует рассматривать в первую очередь.

  • Параметр requested-type обеспечивает информацию о типе среды, который абонент хочет использовать. Если лист strict имеет значение true, система управления должна считать это строгим ограничением для типа среды. Если strict = false (принято по умолчанию) и запрошенная среда недоступна, система управления может выбрать другой тип среды. Абоненту и провайдеру следует обменяться данными о поддерживаемых типах сред, но механизмы такого обмена выходят за рамки документа.

  • Лист always-on определяет строгое ограничение. При значении true система управления должна выбрать тип среды, которая всегда доступна (always-on), т. е. не может применяться коммутируемый доступ.

  • Параметр bearer-reference используется в тех случаях, когда абонент уже заказал подключение к сети SP отдельно от сайта L2VPN и хочет воспользоваться этим соединением. Строка служит внутренней ссылкой от SP и описывает уже имеющееся соединение. Это требование является строгим и не может быть ослаблено. Способ предоставления ссылки абоненту выходит за рамки документа, но примером может служить указание канала-носителя, заказанного клиентом (с помощью процедуры, выходящей за рамки документа).

Могут применяться также иные внутренние параметры от SP. Система управления может использовать такие параметры, как «input svc-bandwidth» и «output svc-bandwidth» для выбора используемого типа доступа.

5.6.4. Ограничение — разнесение доступа

Каждый элемент site-network-access может включать одно или множество ограничений, которые будут определять размещение доступа. По умолчанию в модели предполагается отсутствие ограничений, но ожидается выделение уникального носителя (bearer) для каждого site-network-access.

Для реализации разных вариантов доступа элементы site-network-access можно помечать с помощью одного или нескольких идентификаторов групп. Идентификатор группы представляет собой строку, которая может включать как явное именование группы сайтов (например, multihomed-set1), так и числовое значение (например, 12345678). Значение каждого group-id локально для администратора абонента и система управления должна обеспечивать разным абонентам возможность использования одинаковых идентификаторов. Один или несколько group-id могут быть также определены на уровне сайта, в результате чего все site-network-access этого сайта должны наследовать идентификаторы group-id своего сайта. Когда в дополнение group-id сайта определяются идентификаторы на уровне site-network-access, система управления должна учитывать объединение всех групп (уровня сайта и уровня site-network-access) для конкретного элемента site-network-access.

Для уже настроенного элемента site-network-access каждое ограничение должно быть выражено применительно к набору site-network-accesses. Уже настроенный элемент site-network-access должен не приниматься во внимание в целевом наборе site-network-accesses. Например, «site-network-access S недопустимо подключать к той же точке присутствия POP, куда подключен контейнер site-network-accesses, являющийся частью Group 10». Набор site-network-accesses, к которому применяются ограничения, может быть указан в форме списка групп all-other-accesses или all-other-groups. Опция all-other-accesses означает, что текущее ограничение site-network-access допустимо применять ко всем site-network-accesses, относящимся к текущему сайту. Опция all-other-groups означает, что ограничение должно применяться ко всем группам, в которые текущий элемент site-network-access не входит.

Текущая модель определяет множество типов ограничений, перечисленных ниже.

  • pe-diverse — текущий элемент site-network-access недопустимо соединять с тем же PE, что и целевой site-network-accesses.

  • pop-diverse — текущий элемент site-network-access недопустимо соединять с той же точкой POP, что и целевой site-network-accesses.

  • linecard-diverse — текущий элемент site-network-access недопустимо соединять с той же линейной платой, что и целевой site-network-accesses. Отметим, что абонент может запросить linecard-diverse для site-network-accesses, но идентификатор текущей используемой линейной платы не следует показывать абоненту.

  • bearer-diverse — текущему элементу site-network-access недопустимо использовать общие компоненты носителя (bearer) с носителями, используемыми целевым site-network-accesses. Элемент bearer-diverse обеспечивает некоторый уровень разнесения доступа. Например, двум bearer-diverse site-network-accesses недопустимо использовать один мультиплексор DSLAM54, BAS55 или коммутатор L2.

  • same-pe — текущий элемент site-network-access должен соединяться с тем же PE, что и целевой site-network-accesses.

  • same-bearer — текущий элемент site-network-access должен соединяться с тем же носителем, что и целевой site-network-accesses.

Типы ограничений могут быть расширены с помощью дополнений. Каждое ограничение должно выражаться в форме «элемент site-network-access S должен быть <constraint-type> (например, pe-diverse, pop-diverse) из <target> site-network-accesses».

Идентификатор group-id, используемый для нацеливания того или иного site-network-accesses, может совпадать с применяемым в текущем элементе site-network-access. Это упрощает настройку для случаев, где группа точек site-network-access имеет ограничения между собой.

5.7. Выделение значений RD

Обозначение маршрута (RD56) является важнейшим параметром L2VPN на основе протокола BGP, описанных в [RFC4364], который обеспечивает возможность различать общие блоки адресов в разных VPN. Поскольку для целей маршрутов (RT) предполагается выделение системой управления таблиц MAC-VRF на целевом PE и RD для этих MAC-VRF, значение RD должно быть уникальным для каждой таблицы MAC-VRF в целевом PE.

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

Если таблицы MAC-VRF нет в целевом PE, система управления инициирует создание MAC-VRF в целевом PE и выделение для нее нового значения RD.

Система управления может применять политику выделения RD на уровне VPN или MAC-VRF в зависимости от правил SP. При выделении на уровне VPN все таблицы MAC-VRF (отправленные в разные PE) в рамках VPN будут использовать общее значение RD. При выделении на уровне MAC-VRF каждой таблице MAC-VRF следует назначать уникальное значение RD. Возможны другие варианты выделения значений и данный документ не ограничивает выбор.

Выделение RD может выполняться таким же способом как для RT. Представленная в параграфе 5.2.2.1 информация пригодна и в этом случае.

Отметим, что SP может настроить целевое устройство PE на автоматическое выделение значений RD. В таких случаях не потребуется какой-либо отдельной системы (backend) для назначения RD.

5.8. Доступность Site-Network-Access

Сайт может быть многодомным с множеством точек site-network-access. Ограничения на размещение, описанные в параграфе 5.6, помогут обеспечить разнесение физических подключений.

При размещении site-network-accesses в сети абонент может захотеть использовать определенную политику маршрутизации для этого доступа. Контейнер site-network-access/availability определяет параметры избыточности для резервирования на данном сайте. Лист access-priority определяет предпочтения для конкретного доступа. Эти предпочтения используются в сценариях «основной-резервный» и «распределение нагрузки». Большее значение access-priority задает более предпочтительное использование. Атрибут redundancy-mode определен для многодомных сайтов и служит для использования в сценариях «один активный» и «активный-активный». Это позволяет поддерживать множество активных путей в состоянии пересылки и для распределения нагрузки.

На рисунке 20 показаны варианты использования атрибута access-priority.

ЛВС Hub#1 (основной/резервный)    ЛВС Hub#2 (распределение нагрузки)
  |                                                     |
  |    access-priority 1          access-priority 1     |
  |--- CE1 ------- PE1            PE3 --------- CE3 --- |
  |                                                     |
  |                                                     |
  |--- CE2 ------- PE2            PE4 --------- CE4 --- |
  |    access-priority 2          access-priority 1     |

                        PE5
                         |
                         |
                         |
                        CE5
                         |
                    Сайт Spoke#1 (однодомный)

Рисунок 20. Пример настройки приоритета доступа.


Для ЛВС Hub#2 требуется распределение нагрузки, поэтому оба site-network-access должны иметь одинаковые значения access-priority. Для ЛВС Hub#1 требуется резервирование доступа и большее значение access-priority определяет основное соединение (site-network-access).

Могут быть промоделированы и более сложные сценарии. Рассмотрим Hub-сайт с 5 подключениями к сети (A1, A2, A3, A4, A5). Абонент хочет в обычных условиях распределять нагрузку между соединениями A1 и A2, при отказе этих каналов — распределять нагрузку между A3 и A4, а случае отказа всех каналов A1, A2, A3 и A4 — использовать канал A5. Это можно реализовать, установив значения access-priority: A1=100, A2=100, A3=50, A4=50, A5=10.

Подход access-priority имеет некоторые ограничения. Например, в описанном выше случае переход на распределение нагрузки между каналами A3 и A4 недостижим в случае отказа лишь одного из каналов A1 и A2. Однако атрибут access-priority хорошо подходит для большинства практических реализаций и при необходимости модель может быть расширена с помощью дополнений.

5.9. SVC MTU

Значение MTU для кадров абонентского сервиса можно вывести из принятого по умолчанию MTU физических интерфейсов или задать в листе svc-mtu, если принятое по умолчанию значение не подходит.

5.10. Контейнер service

Контейнер service определяет параметры сервиса, связанные с сайтом.

5.10.1. Параметр Bandwidth

Параметр bandwidth указывает требования к пропускной способности между устройствами CE и PE, которая может быть указана значением согласованной (CIR57), избыточной (EIR58) или пиковой (PIR59) скорости. Запрошенная пропускная способность выражается как входная и выходная пропускная способность, определяемые относительно сайта абонента. Входная пропускная способность указывает скорость загрузки данных на сайт абонента, выходная — скорость выгрузки данных с сайта в сеть.

Пропускная способность настраивается только на уровне site-network-access (т. е. для соединения сайта с сетью).

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

Параметр svc-bandwidth имеет определенный тип. Данный документ определяет 4 типа:

  • bw-per-access — пропускная способность задается для соединения или доступа сайта в сеть применительно ко всем кадрам сервиса на интерфейсе, связанном с конкретным подключением;

  • bw-per-cos — пропускная способность задается для класса обслуживания (CoS), определяя скорость для всех кадров данного CoS с конкретным cos-id;

  • bw-per-svc — пропускная способность задается для сайта в целом, определяя скорость для всех кадров сервиса, связанных с конкретным экземпляром VPN;

  • «непрозрачная» пропускная способность, не связанная с каким-либо cos-id, экземпляром VPN (vpn-id) или идентификатором доступа сайта в сеть.

Параметр svc-bandwidth должен включать cos-id для типа bw-per-cos. Значения cos-id могут выделяться на основе (1) значения IEEE 802.1p [IEEE-802-1D] в C-tag или (2) кода DSCP60 в заголовке IP61. Измерения выполняются в соответствии с профилем пропускной способности, заданным cos-id.

Для типа bw-per-access параметр svc-bandwidth должен быть связан с конкретным параметром site-network-access-id. С каждым подключением сайта может быть связано множество значений полосы на уровне cos-id.

Для типа bw-per-svc параметр svc-bandwidth должен включать конкретный параметр vpn-id. С одним сервисом EVPN может быть связано множество значений полосы на уровне cos-id.

5.10.2. Параметр QoS

Модель определяет параметры QoS как абстракцию:

  • qos-classification-policy — определяет набор упорядоченных правил классификации абонентского трафика;

  • qos-profile — определяет применяемый профиль планирования QoS.

5.10.2.1. Классификация QoS

Правила классификации QoS определяются параметром qos-classification-policy, который представляет собой упорядоченный список правил, которые сопоставляются с потоками или приложениями, и устанавливают подходящий целевой класс обслуживания CoS (target-class-id). Пользователь может определить сопоставление с использованием более конкретного определения потока (по MAC-адресам отправителей и получателей, cos, dscp, cos-id, color-id и т. п.). Значение color-id может быть назначено кадру для идентификации соответствия профилю QoS. Кадры сервиса считаются «зелеными» (green), если они соответствуют согласованной скорости профиля пропускной способности. «Желтыми» (yellow) считаются кадры, выходящие за пределы согласованной скорости, но соответствующие «избыточной» скорости профиля пропускной способности. «Красными» (red) будут кадры, выходящие за пределы согласованной и избыточной скорости в профиле пропускной способности.

При использовании определения потока пользователь может применить лист-список target-sites для указания получателя потока вместо адреса получателя. В таких случаях привязка между абстракцией сайта и применяемыми для сайта MAC-адресами должна выполняться динамически. Способы организации такой привязки выходят за рамки документа. Связь сайта с L2VPN указывается контейнером vpn-attachment. Поэтому пользователь может идентифицировать получателей в потоке целевой сети VPN с помощью листа-списка target-sites и контейнера vpn-attachment. Правила без оператора сопоставления match считаются правилами «соответствия всему» (match-all). SP может реализовать завершающее правило классификации, если абонент не задал такого правила. Используемый по умолчанию класс определяет SP. В этой модели определены некоторые приложения, но можно добавлять новые с помощью дополнений. Точное значение отождествления каждого приложения зависит от SP, поэтому провайдер должен заранее информировать абонента об использовании сопоставлений по приложениям.

5.10.2.2. Профиль QoS

Пользователь может выбрать стандартный профиль, предоставленный оператором, или создать свой профиль. Профиль QoS (qos-profile) определяет правила планирования трафика, используемые SP.

Абонентский профиль QoS определяется как список записей CoS и связанных в ними свойств, приведенных ниже.

  • direction — служит для указания направления, к которому применяется qos-profile. Эта модель поддерживает направление с сайта в WAN (site-to-wan), из WAN на сайт (wan-to-site) и двухстороннее управление (bidirectional), которое применяется по умолчанию. При выборе двухстороннего управления провайдеру следует обеспечить планирование трафика в соответствии с запрошенными правилами в обоих направлениях (от SP на сайт и обратно). Например, правила планирования могут применяться на стороне PE и на стороне CE канала WAN. В направлении из WAN на сайт провайдеру следует обеспечивать планирование трафика из сети SP на сайт абонента. Например, правила управления трафиком могут быть реализованы лишь на устройстве PE, подключенном к WAN-каналу в направлении абонента.

  • policing — (необязательно) указывает, следует ли применять правила к одной скорости и двум цветами или двум скоростям и трем цветам.

  • byte-offset — (необязательно) указывает число байтов в заголовках кадров, которые не учитываются при ограничении скорости.

  • frame-delay — ограничивает задержки для данного класса. Ограничение задержки может быть указано минимальной возможной задержкой или границей задержки в миллисекундах. Выполнение этого ограничения зависит от реализации SP — может применяться строгий механизм приоритизации для очередей на канале доступа и в ядре сети или создаваться путь маршрутизации с малой задержкой для этого класса трафика.

  • frame-jitter — ограничивает вариации задержек для данного класса. Ограничение может быть выражено как минимальная возможная вариация или граница вариации в миллисекундах. Выполнение этого ограничения зависит от реализации SP — может применяться строгий механизм приоритизации для очередей на канале доступа и в ядре сети или создаваться путь маршрутизации с известной величиной вариаций для этого класса.

  • bandwidth — задает гарантированную пропускную способность для CoS, выражаемую в процентах. Параметр guaranteed-bw-percent использует в качестве единицы отсчета доступную пропускную способность, которой следует быть не ниже значения CIR, определенного во входном или выходном параметре svc-bandwidth. При реализации контейнера qos-profile на стороне CE в качестве единицы отсчета применяется выходное значение svc-bandwidth, а при реализации на стороне PE — входное значение svc-bandwidth. По умолчанию резервирование пропускной способности гарантируется лишь на уровне доступа. Пользователь может применить лист end-to-end для запроса сквозного резервирования пропускной способности, включая транспортную сеть MPLS. Иными словами, SP будет активировать в ядре MPLS те или иные средства обеспечения запрошенной абонентом пропускной способности. Решение этой задачи (например, резервирование RSVP-TE или резервирование в контроллере) выходит за рамки документа.

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

5.10.3. Поддержка BUM

Контейнер broadcast-unknown-unicast-multicast указывает тип сайта в топологии групповой пересылки абонента — источник, получатель или оба сразу. Эти параметры помогают системе управления оптимизировать групповой трафик.

Можно создать множество отображений групп на порты (group-to-port) с помощью списка multicast-gp-address-mapping, определяющего адрес multicast-группы и номер порта LAG. Эти параметры помогают SP выбрать подходящую привязку интерфейса к multicast-группе для удовлетворения требований абонента.

Для обеспечения «прозрачной» доставки данного кадра все групповые кадры L2 (данные и управление) следует без изменений (за исключением VLAN ID) передавать от CE до CE. Значения VLAN ID, заданные SP, также можно менять.

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

Пересылка кадров BUM в многоточечном сервисе включает локальную лавинную рассылку другим устройствам AC того же PE и удаленную репликацию на всех других PE, которая требует дополнительных ресурсов и пропускной способности в ядре сети. На обращенных наружу интерфейсах (UNI или E-NNI62) могут быть реализованы специальные правила обработки кадром BUM с ограничением скорости для них числом пакетов или битов в секунду.

Может задаваться общий порог для всего трафика BUM или отдельные пороги для каждой категории трафика.

5.11. Управление сайтом

Субконтейнер management предназначен для опций управления сайтом с учетом принадлежности устройств и контроля доступа. Ниже кратко описаны тра базовые модели управления.

Управляемое провайдером устройство CE. Провайдер монопольно владеет устройством CE и только он имеет доступ к CE. Граница ответственности SP и абонента размещается между CE и сетью абонента. Этот вариант используется чаще всего.

Управляемое абонентом устройство CE. Абонент монопольно вдадеет устройством CE и только он имеет доступ к CE. Граница ответственности SP и абонента размещается между PE и CE.

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

Выбранная модель управления указывается в листе type. Лист address хранит адрес для управления устройством CE. Лист management-transport служит для указания протокола, используемого для управления (IPv4 или IPv6). На основе выбранной модели управления могут быть заданы дополнительные опции защиты.

5.12. Защита от петель MAC

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

SP может реализовать механизм предотвращения петель на обращенных наружу интерфейсах для многоточечного сервиса, задав порог для переброса MAC-адресов.

Частота переброса MAC-адресов и опции предотвращения петель указываются в контейнере mac-loop-prevention.

5.13. Ограничение числа MAC-адресов

Необязательный контейнер mac-addr-limit содержит предельное число абонентских MAC-адресов и данные, описывающие поведение при достижении предела или старении MAC-адреса.

При реализации нескольких экземпляров сервиса на одном элементе сети таблица MAC-адресов (а также пространство RIB63 для маршрутов MAC в случае EVPN) является совместно используемым ресурсом. Провайдер может ограничивать число MAC-адресов, узнанных от абонента, для одного экземпляра сервиса с помощью листа mac-addr-limit и может применять лист action для указания действий в случае превышения заданного предела — отбрасывание пакета, лавинная рассылка или просто запись события в системный журнал.

Если для услуг «точка-точка» обучение MAC отключено, ограничивать число MAC-адресов не требуется.

5.14. Расширенные возможности VPN

5.14.1. Оператор для операторов

В случае CsC64 [RFC8299] абонент может захотеть организовать сервис MPLS на основе L2VPN для передачи трафика.

ЛВС customer1
   |
   |
  CE1
   |
   | -------------
(vrf_cust1)
 CE1_ISP1
   |                 ISP1 POP
   | Канал MPLS 
   | -------------
   |
(vrf ISP1)
  PE1

 (...)   Магистраль првайдера

  PE2
(vrf ISP1)
   |
   | ------------
   |
   | Канал MPLS 
   |                 ISP1 POP
 CE2_ISP1
(vrf_cust1)
   | ------------
   |
  CE2
   |
ЛВС customer1

Рисунок 21. Сервис MPLS с использованием L2VPN.


В примере на рисунке 21 ISP1 продает услуги L2VPN, но не имеет инфраструктуры ядра между своими точками POP и использует сервис L2VPN в качестве такой инфраструктуры (принадлежащей другому провайдеру) между своими POP.

Для поддержки CsC сервис VPN должен указать поддержку MPLS путем указания для листа carrierscarrier в списке vpn-service значения true. Канал между CE1_ISP1/PE1 и CE2_ISP1/PE2 должен также поддерживать протокол сигнализации MPLS. Конфигурация выполняется на уровне сайта.

В этой модели в качестве сигнального протокола MPLS может применяться LDP или BGP. В случае LDP должен также применяться протокол внутренней маршрутизации IGP. В случае сигнализации BGP протокол BGP должен также служить протоколом маршрутизации.

При использовании CsC запрашиваемый лист svc-mtu должен указывать MPLS MTU, а не MTU на канале.

5.15. Ссылки на внешние идентификаторы

Модель сервиса порой обращается к внешней информации путем задания идентификаторов. Например, для заказа доступа в облако конкретного CSP65 в модели используется идентификатор целевого CSP. Если абонент напрямую применяет модель сервиса в качестве API (например, через RESTCONF или NETCONF) для заказа определенной услуги, провайдеру следует предоставлять список действующих идентификаторов. В случае доступа к облаку SP будет предоставлять идентификаторы, связанные с доступными провайдерами CSP. То же самое относится и к другим идентификаторам (таким, как qos-profile).

Например, установка remote-carrier-name используется в случае NNI, поскольку эта информация нужна текущему L2VPN SP, с которым организуется соединение, тогда как идентификатор облака (cloud-identifier) нужен текущему L2VPN SP и абоненту, поскольку он применяется для доступа к публичному облаку или в Internet.

Способы предоставления провайдером этой информации абоненту выходят за рамки документа.

5.16. Определение NNI и поддержка нескольких AS

Автономная система (AS66) представляет собой сеть или группу сетей с единым администрированием, которая использует один четко определенный протокол маршрутизации. В некоторых случаях требуется организовать VPN через несколько AS, разделенных географически или относящихся к разным SP. Соединения между AS организуются провайдерами и не видны абоненту. Примеры таких соединений включают:

  • партнерские отношения между SP (например, оператор или облако) для расширения сервиса VPN;

  • внутренние границы в рамках одного SP (например, транзитные сети, ядро и ЦОД).

Интерфейсы NNI определяются для организации VPN через множество AS. В [RFC4761] определено множество вариантов реализации VPN NNI (например, VPLS), каждый из которых имеет свои преимущества и недостатки, но этот вопрос выходит за рамки документа. Например в варианте A (две AS) партнеры ASBR67 соединяются через множество интерфейсов, из которых по крайнем мере один, относящийся в обеим AS, будет присутствовать в VPN. Чтобы эти ASBR могли обмениваться блоками меток, они связывают каждый интерфейс с таблицей MAC-VRF (VSI, раздел 2) и сессией BGP. В результате трафик между устройствами в VPLS передается по протоколу Ethernet. В этом варианте все VPN изолированы одна от другой, а поскольку трафик передаются с помощью Ethernet, механизмы QoS для трафика Ethernet могут применяться для обеспечения абонентских соглашений SLA.

  --------                 --------------              -----------
 /        \               /              \            /           \
| Облачный |             |                |          |             |
| провайдер|-----NNI-----|                |----NNI---|     ЦОД     |
|  #1      |             |                |          |             |
 \        /              |                |           \           /
  --------               |                |            -----------
                         |                |
  --------               |    Моя сеть    |           -----------
 /        \              |                |          /           \
| Облачный |             |                |         |             |
| провайдер|-----NNI-----|                |---NNI---| Партнер     |
|  #2      |             |                |         | L2VPN       |
 \        /              |                |         |             |
  --------               |                |         |             |
                          \              /          |             |
                           --------------            \           /
                                 |                    -----------
                                 |
                                NNI
                                 |
                                 |
                         -------------------
                        /                   \
                       |                     |
                       |                     |
                       |                     |
                       |     Партнер L2VPN   |
                       |                     |
                        \                   /
                         -------------------

Рисунок 22. Сеть SP с несколькими NNI.


На рисунке 22 показана сеть SP (Моя сеть), имеющая несколько интерфейсов NNI, используемых для

  • расширения своего присутствия, основанного на партнерстве L2VPN;

  • подключения своих ЦОД к абонентским L2VPN;

  • обеспечения абонентам доступа к частным ресурсам, расположенным в облаке некого провайдера CSP.

5.16.1. Определение NNI, вариант A

         AS A                                         AS B
  -------------------                         -------------------
 /                   \                       /                   \
|                     |                     |                     |
|                 ++++++++ Канал между AS+++++++++                |
|                 +      +_______________+       +                |
|                 +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+                |
|                 +      +               +       +                |
|                 + ASBR +               + ASBR  +                |
|                 +      +               +       +                |
|                 +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+                |
|                 +      +_______________+       +                |
|                 ++++++++               +++++++++                |
|                     |                     |                     |
|                     |                     |                     |
|                     |                     |                     |
|                 ++++++++ Канал между AS+++++++++                |
|                 +      +_______________+       +                |
|                 +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+                |
|                 +      +               +       +                |
|                 + ASBR +               + ASBR  +                |
|                 +      +               +       +                |
|                 +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+                |
|                 +      +_______________+       +                |
|                 ++++++++               +++++++++                |
|                     |                     |                     |
|                     |                     |                     |
 \                   /                       \                   /
  -------------------                         -------------------

Рисунок 23. Интерфейс NNI, вариант A, пример 1.


В варианте A две AS соединены между собой физическими каналами на маршрутизаторах ASBR. Для отказоустойчивости между AS может быть организовано множество физических соединений. Соединение VPN (физическое или логическое на основе физического) создается для каждой сети VPN, которой требуется выход за границу AS.

С точки зрения модели сервиса это соединение VPN может выглядеть сайтом. Предположим, что AS B хочет расширить соединение для VPN C на AS A. Администратор AS B может использовать эту модель сервиса для заказа сайта в AS A. Все варианты могут быть реализованы с использованием возможностей текущей модели. Например, на рисунке 23 показаны два физических соединения, на которые наложены логические соединения VPN. Это можно рассматривать как сценарий с множеством VPN. Администратор AS B может также выбрать подходящий протокол маршрутизации (например, EBGP68) для динамического обмена маршрутами между AS.

В этом документе предполагается, что для варианта A интерфейса NNI следует применять имеющуюся модель сайта VPN.

На рисунке 24 показан пример, где абонент хочет, чтобы его CSP A присоединил свою виртуальную сеть N к имеющейся L2VPN (VPN1) от сервиса L2VPN провайдера SP B.

         CSP A                           L2VPN SP B
  -----------------                     -----------
 /                 \                   /           \
|       |           |                 |             |
|  VM --|       ++++++++     NNI    ++++++++++      |--- VPN1
|       |       +      +____________+        +      |   Сайт 1
|       |-------+(MAC-VRF1)-(VPN1)-(MAC-VRF1)+      |
|       |       +      +            +        +      |
|       |       + ASBR +            + ASBR   +      |
|       |       +      +____________+        +      |
|       |       ++++++++            ++++++++++      |
|  VM --|           |                 |             |--- VPN1
|       |Виртуальная|                 |             |   Сайт 2
|       |сеть       |                 |             |
|  VM --|           |                 |             |--- VPN1
|       |           |                 |             |   Сайт 3
 \                 /                   \           /
  -----------------                     -----------
                                             |
                                             |
VM = Виртуальная машина                     VPN1
                                           Сайт 4

Рисунок 24. Интерфейс NNI, вариант A, пример 2.


Для подключения VPN провайдер CSP или абонент может использовать модель L2SM, раскрытую провайдером SP B. Поскольку интерфейс NNI используется совместно, можно считать, что физическое соединение (bearer) между CSP A и SP B уже имеется. CSP A может запросить через модель сервиса создание нового сайта с одним контейнером site-network-access (single-homing на рисунке 24). В качестве ограничения для размещения CSP A может использовать ссылку на носитель (bearer) от SP A для размещения VPN NNI на имеющемся канале. Приведенный ниже код XML иллюстрирует возможный запрос конфигурации к провайдеру SP B.

   <?xml version="1.0"?>
   <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
    <vpn-profiles>
     <valid-provider-identifiers>
      <qos-profile-identifier>
       <id>GOLD</id>
      </qos-profile-identifier>
      <qos-profile-identifier>
       <id>PLATINUM</id>
      </qos-profile-identifier>
     </valid-provider-identifiers>
    </vpn-profiles>
    <vpn-services>
     <vpn-service>
      <vpn-id>VPN1</vpn-id>
      <ce-vlan-preservation>true</ce-vlan-preservation>
      <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
     </vpn-service>
    </vpn-services>
    <sites>
         <site>
             <site-id>CSP_A_attachment</site-id>
              <locations>
               <location>
                 <location-id>NY1</location-id>
                 <city>NY</city>
                 <country-code>US</country-code>
              </location>
              </locations>
             <site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
               <site-network-accesses>
                 <site-network-access>
                  <network-access-id>CSP_A_VN1</network-access-id>
                          <connection>
                          <encapsulation-type>vlan</encapsulation-type>
                          <eth-inf-type>tagged</eth-inf-type>
                           <tagged-interface>
                            <tagged-inf-type>dot1q</tagged-inf-type>
                            <dot1q-vlan-tagged>
                             <cvlan-id>17</cvlan-id>
                           </dot1q-vlan-tagged>
                           </tagged-interface>
                          </connection>
                            <service>
                              <svc-bandwidth>
                                <bandwidth>
                                 <direction>input-bw</direction>
                                  <type>bw-per-cos</type>
                                   <cir>450000000</cir>
                                   <cbs>20000000</cbs>
                                   <eir>1000000000</eir>
                                   <ebs>200000000</ebs>
                                </bandwidth>
                              </svc-bandwidth>
                              <carrierscarrier>
                                <signaling-type>bgp</signaling-type>
                             </carrierscarrier>
                            </service>
                           <vpn-attachment>
                              <vpn-id>12456487</vpn-id>
                              <site-role>spoke-role</site-role>
                            </vpn-attachment>
                </site-network-access>
             </site-network-accesses>
             <management>
              <type>customer-managed</type>
             </management>
         </site>
    </sites>
   </l2vpn-svc>

Описанный выше случай отличается от сценария использования контейнера cloud-accesses, который обеспечивает доступ в публичное облако, тогда как в примере организуется доступ к приватным ресурсам в сети CSP.

5.16.2. Определение NNI, вариант B

        AS A                                          AS B
  -------------------                         -------------------
 /                   \                       /                   \
|                     |                     |                     |
|                 ++++++++ Канал между AS++++++++                 |
|                 +      +_______________+      +                 |
|                 +      +               +      +                 |
|                 + ASBR +<---MP-BGP---->+ ASBR +                 |
|                 +      +               +      +                 |
|                 +      +_______________+      +                 |
|                 ++++++++               ++++++++                 |
|                     |                     |                     |
|                     |                     |                     |
|                     |                     |                     |
|                 ++++++++ Канал между AS++++++++                 |
|                 +      +_______________+      +                 |
|                 +      +               +      +                 |
|                 + ASBR +<---MP-BGP---->+ ASBR +                 |
|                 +      +               +      +                 |
|                 +      +_______________+      +                 |
|                 ++++++++               ++++++++                 |
|                     |                     |                     |
|                     |                     |                     |
 \                   /                       \                   /
  -------------------                         -------------------

Рисунок 25. Интерфейс NNI, вариант B, пример 1.


В варианте B две AS соединены между собой физическими каналами на ASBR. Для отказоустойчивости может использоваться множество соединений между AS. «VPN-соединение» между AS организуется путем обмена маршрутами VPN с использованием MP-BGP [RFC4761].

Существует три варианта реализации такого интерфейса NNI.

  1. NNI является внутренним для провайдера и расположен между магистралью и ЦОД. Домены являются доверенными и не нужно фильтровать маршруты VPN, т. е. обмен происходит для всех маршрутов. Может применяться фильтрация RT для сохранения некоторых необязательных состояний.

  2. NNI располагается между провайдерами, готовыми обмениваться маршрутами VPN лишь для конкретных RT. Каждый провайдер получил от другого полномочия на использование этих значений RT.

  3. NNI располагается между провайдерами, готовыми обмениваться маршрутами VPN лишь для конкретных RT. Каждый провайдер имеет свою схему RT. Поэтому работающие через две сети абоненты будут получать для конкретной VPN разные RT в каждой сети.

В случае 1 модель сервиса не нужна, поскольку протокол позволяет динамический обмен нужными маршрутами VPN.

В случае 2 требуется политика фильтрации RT на ASBR. С точки зрения модели сервиса требуется согласовать список RT для передачи полномочий.

В случае 3 обе AS должны согласовать VPN RT для обмена, а также отображение VPN RT одной AS на RT из другой.

Такое моделирование выходит за рамки этого документа.

       CSP A                               L3VPN SP B
  -----------------                    ------------------
 /                 \                  /                  \
|       |           |                |                    |
|  VM --|       ++++++++   NNI    ++++++++                |--- VPN1
|       |       +      +__________+      +                |   Сайт 1
|       |-------+      +          +      +                |
|       |       + ASBR +<-MP-BGP->+ ASBR +                |
|       |       +      +__________+      +                |
|       |       ++++++++          ++++++++                |
|  VM --|           |                |                    |--- VPN1
|       |Виртуальная|                |                    |   Сайт 2
|       |сеть       |                |                    |
|  VM --|           |                |                    |--- VPN1
|       |           |                |                    |   Сайт 3
 \                 /                 |                    |
  -----------------                  |                    |
                                      \                  /
                                       ------------------
                                                |
VM = Виртуальная машина                         |
                                               VPN1
                                              Сайт 4

Рисунок 26. Интерфейс NNI, вариант B, пример 2.


На рисунке 26 показано соединение NNI между CSP A и сетью SP B. Провайдеры не доверяют друг другу и каждый применяет свои правила выделения RT. Поэтому в терминах реализации абонентская VPN имеет свое значение RT в каждой сети (RT A в CSP A и RT B в сети SP B). Для подключения виртуальной сети абонента в CSP A к абонентской L2VPN (VPN1) в сети SP B провайдеру CSP A следует запросить у сети SP B создание абонентской VPN на интерфейсе NNI (восприятие соответствующего RT). Трансляция RT выполняется на основе соглашения между двумя SP — SP B может разрешить CSP A запрос трансляции VPN (RT).

5.16.3. Определение NNI, вариант C

         AS A                                           AS B
  -------------------                          -------------------
 /                   \                        /                   \
|                     |                      |                     |
|                     |                      |                     |
|                     |                      |                     |
|                 ++++++++ Multihop EBGP  ++++++++                 |
|                 +      +                +      +                 |
|                 +      +                +      +                 |
|                 + RGW  +<----MP-BGP---->+ RGW  +                 |
|                 +      +                +      +                 |
|                 +      +                +      +                 |
|                 ++++++++                ++++++++                 |
|                     |                      |                     |
|                     |                      |                     |
|                     |                      |                     |
|                     |                      |                     |
|                     |                      |                     |
|                 ++++++++ Канал между AS++++++++                  |
|                 +      +_______________+      +                  |
|                 +      +               +      +                  |
|                 + ASBR +               + ASBR +                  |
|                 +      +               +      +                  |
|                 +      +_______________+      +                  |
|                 ++++++++               ++++++++                  |
|                     |                      |                     |
|                     |                      |                     |
|                     |                      |                     |
|                 ++++++++ Канал между AS++++++++                  |
|                 +      +_______________+      +                  |
|                 +      +               +      +                  |
|                 + ASBR +               + ASBR +                  |
|                 +      +               +      +                  |
|                 +      +_______________+      +                  |
|                 ++++++++               ++++++++                  |
|                     |                      |                     |
|                     |                      |                     |
 \                   /                        \                   /
  -------------------                          -------------------

Рисунок 27. Вариант C для NNI.


С точки зрения сервиса VPN вариант C для NNI очень похож на вариант B, поскольку используется сессия MP-BGP для обмена маршрутами VPN между AS. Различие состоит в том, что уровни пересылки и управления размещаются на разных узлах, поскольку сессия MP-BGP включает несколько этапов пересылки между шлюзами маршрутизации (RGW). С точки зрения сервиса VPN моделирование вариантов B и C выполняется идентично.

5.17. Применимость L2SM в межпровайдерской и междоменной оркестровке

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

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

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

Межпровайдерские управляющие соединения варианта (a) могут быть реализованы с использованием методов, описанных в параграфе 5.16 (например, определение NNI). Многосегментные соединения варианта (b) могут приводить к решениям для соединений между AS, похожим на схему (b) в разделе 10 [RFC4364]. Это можно реализовать путем «сшивания» соединений сайтов и сегментов сервиса в разных доменах. Например, сквозное соединение между сайтами 1 и 3 через множество доменов (скажем, городские сети) может быть организовано путем сшивания соединений доступа на сайте 1 с SEG1, SEG3, SEG4, а также с подключением к сети на сайте 3 (как показано на рисунке 28). Предполагается, что компонент оркестровки на рисунке 3 должен иметь представление о полной абстрактной топологии и доступности ресурсов. Это может основываться на планировании сети.

         ----------   ----------   ----------
        |          | |          | |          |
      +--+        +---+        +---+        +--+
Сайт 1|PE|==SEG1==|   |==SEG3==|   |==SEG4==|PE|Сайт 3
      +--+        +---+        |   |        +--+
        |          | |         |   |         |  ----------
        |          | |         |   |         | |          |
      +--+        +---+        |   |        +---+        +--+
Сайт 2|PE|==SEG2==|   |==SEG5==|   |==SEG6==|   |==SEG7==|PE|Сайт 4
      +--+        +---+        +---+        +---+        +--+
        |          | |          | |          | |          |
         ----------   ----------   ----------   ----------

Рисунок 28. Пример межпровайдерской и междоменной оркестровки.


Отметим, что SEG1, SEG2, SEG3, SEG4, SEG5 и SEG6 можно рассматривать как подключения доступа на сайте и они могут быть созданы как подключения обычных сайтов с использованием L2SM.

На рисунке 28 протокол BGP служит для распространения L2VPN NLRI69 из одной AS в соседнюю. Сначала маршрутизаторы PE используют BGP для распространения L2VPN NLRI маршрутизаторам ASBR или рефлекторам маршрутов, клиентами которых являются ASBR. Затем ASBR использует BGP для распространения этих L2VPN NLRI маршрутизатору ASBR в другой AS, который далее распространит их маршрутизаторам PE в своей AS или, возможно, другим ASBR, которые разошлют анонсы дальше.

В этом случае PE может узнать адрес маршрутизатора ASBR, через который доступендругой PE, для организации соединения с последним. Т. е. локальный PE будет получать анонс BGP с L2VPN NLRI для экземпляра L2VPN, где у локального PE есть подключенные участники. Следующим интервалом BGP в этом L2VPN NLRI будет ASBR локальной AS. Затем вместо создания управляющего соединения через весь путь с удаленным PE, локальный PE создаст соединение лишь с ASBR, т. е. сегмент соединения от PE до ASBR. Маршрутизатор ASBR может организовать соединение с ASBR в следующей AS, а затем «сшить» с соединением от PE, как описано в [RFC6073]. Повторение процедуры на каждом ASBR создаст цепочку соединений, которая после «сшивания» свяжет два маршрутизатора PE.

Отметим, что при описанном подходе локальный маршрутизатор PE может никогда не узнать IP-адрес удаленного PE. Он знает L2VPN NLRI из анонсов удаленного PE, который не обязан включать адрес удаленного PE, и знает IP-адрес ASBR, который служит следующим интервалом BGP для данного NLRI.

При использовании такого подхода для VPLS или полносвязной (full-mesh) VPWS возникает полносвязный набор соединений между PE, но полносвязные управляющие соединения (сессии LDP или L2TPv3) не требуются. Вместо этого управляющие соединения внутри AS организуются между всеми PE данной AS и маршрутизаторами ASBR этой AS. Одно управляющее соединение между ASBR смежных AS может поддерживать множество сегментов соединений AS-AS, если они нужны.

6. Взаимодействие с другими модулями YANG

Как разъяснено в разделе 4, эта модель сервиса не предназначена для элементов сети, а реализуется в системе управления.

Система управления может иметь модульную конструкцию и включать две разных части:

  1. компонент, отвечающий за модель сервиса (назовем его сервисным компонентом);

  2. компонент, отвечающий за настройку элементов сети (назовем его конфигурационным компонентом).

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

В разделе 7 приведен пример трансляции запросов на предоставление сервиса в строки конфигурации маршрутизатора. В экосистеме на основе YANG предполагается использование NETCONF и YANG между конфигурационным компонентом и сетевыми элементами для настройки запрошенного сервиса на этих элементах.

В этой схеме предполагается, что модели данных YANG будут применяться для настройки компонент сервиса на элементах сети. Будет существовать тесная связь между абстрактным представлением, обеспечиваемым этой моделью сервиса, и детальным представлением конфигурации, которое будет обеспечиваться конкретными моделями конфигурации для элементов сети, такими как определены в [MPLS-L2VPN-YANG] и [EVPN-YANG]. Компоненты сервиса, для которых нужна настройка элементов сети для поддержки определенной здесь модели сервиса, включают:

  • определения экземпляров сетей, которые включают правила VPN;

  • физические интерфейсы;

  • параметры уровня Ethernet (например, идентификаторы VLAN);

  • QoS (классификация, профили и т. п.);

  • поддержка Ethernet Service OAM.

7. Пример использования модели сервиса

Как разъяснено в разделе 4, эта модель сервиса предназначена для реализации на уровне управления и не рассчитана на прямое использование элементами сети. Система управления служит центральной точкой настройки сервиса в целом.

В этом разделе приведен пример использования модели системой управления для настройки сервиса L2VPN на элементах сети.

В приведенном ниже примере сервис VPN организуется для 3 сайтов, использующих VPWS «точка-точка» и топологию сервиса VPN Hub-and-Spoke, как показано на рисунке 29. Распределение нагрузки здесь не рассматривается.

Сайт 1
............
:          :             P2P VPWS
:Spoke-сайт:-----PE1--------------------------+
:          :                                  |        Сайт 3
:..........:                                  |      ............
                                              |      :          :
                                             PE3-----: Hub-сайт :
Сайт 2                                        |      :          :
............                                  |      :..........:
:          :             P2P VPWS             |
:Spoke-сайт:-----PE2--------------------------+
:          :
:..........:

Рисунок 29. Эталонная сеть для простого примера.


Приведенный ниже код XML упрощенно описывает общую конфигурацию сервиса для этой сети VPN.

       <?xml version="1.0"?>
       <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
         <vpn-services>
             <vpn-service>
              <vpn-id>12456487</vpn-id>
               <vpn-svc-type>vpws</vpn-svc-type>
               <svc-topo>hub-spoke</svc-topo>
               <ce-vlan-preservation>true</ce-vlan-preservation>
               <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
              </vpn-service>
             <vpn-service>
               <vpn-id>12456488</vpn-id>
               <vpn-svc-type>vpws</vpn-svc-type>
               <svc-topo>hub-spoke</svc-topo>
               <ce-vlan-preservation>true</ce-vlan-preservation>
               <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
              </vpn-service>
         </vpn-services>
       </l2vpn-svc>

При получении запроса на организацию сервиса VPN система управления будет внутренними средствами (или путем взаимодействия с другими компонентами OSS) выделять значения VPN RT. В данном конкретном случае будут выделены два значения RT (100:1 для концентраторов и 100:2 для лучей). Приведенный ниже результат описывает конфигурацию Spoke-сайта 1.

  <?xml version="1.0"?>
  <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
   <vpn-services>
    <vpn-service>
     <vpn-id>12456487</vpn-id>
     <svc-topo>hub-spoke</svc-topo>
     <ce-vlan-preservation>true</ce-vlan-preservation>
     <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
    </vpn-service>
   </vpn-services>
   <sites>
     <site>
        <site-id>Spoke_Site1</site-id>
           <locations>
             <location>
              <location-id>NY1</location-id>
              <city>NY</city>
              <country-code>US</country-code>
             </location>
            </locations>
            <site-network-accesses>
               <site-network-access>
                  <network-access-id>Spoke_UNI-Site1</network-access-id>
                    <access-diversity>
                      <groups>
                        <group>
                          <group-id>20</group-id>
                        </group>
                      </groups>
                    </access-diversity>
                      <connection>
                       <encapsulation-type>vlan</encapsulation-type>
                        <tagged-interface>
                        <dot1q-vlan-tagged>
                          <cvlan-id>17</cvlan-id>
                        </dot1q-vlan-tagged>
                        </tagged-interface>
                        <l2cp-control>
                          <stp-rstp-mstp>tunnel</stp-rstp-mstp>
                          <lldp>true</lldp>
                        </l2cp-control>
                      </connection>
                      <service>
                        <svc-bandwidth>
                          <bandwidth>
                           <direction>input-bw</direction>
                            <type>bw-per-cos</type>
                             <cir>450000000</cir>
                             <cbs>20000000</cbs>
                             <eir>1000000000</eir>
                             <ebs>200000000</ebs>
                          </bandwidth>
                        </svc-bandwidth>
                        <carrierscarrier>
                         <signaling-type>bgp</signaling-type>
                        </carrierscarrier>
                     </service>
                      <vpn-attachment>
                        <vpn-id>12456487</vpn-id>
                        <site-role>spoke-role</site-role>
                      </vpn-attachment>
                    </site-network-access>
                  </site-network-accesses>
                  <management>
                    <type>provider-managed</type>
                  </management>
                </site>
          </sites>
      </l2vpn-svc>

При получении запроса на предоставление Spoke-сайта 1 система управления должна выделить сетевые ресурсы для этого сайта. Она должна сначала определить целевые элементы сети для предоставления доступа и, в частности, устройство PE (возможно, агрегирующий коммутатор). Как описано в параграфах 5.3.1 и 5.6, системе управления следует использовать данные о местоположении и она должна применять ограничения при доступе (access-diversity) для поиска подходящего PE. В этом случае мы считаем, что Spoke-сайт 1 требует разнесения PE с Hub-сайтами и система управления будет выбирать PE по наименьшей удаленности. На основе данных о местоположении система управления найдет доступные PE в ближней к абоненту окрестности и укажет среди них подходящий по требованиям к разнесению доступа.

После выбора PE система управления должна выделить интерфейсные ресурсы на узле. Из доступных ресурсов PE выбирается один интерфейс. Система управления может начать инициализацию узла PE, используя любые удобные средства (например, NETCONF, CLI). Система управления проверит наличие таблицы виртуальной маршрутизации VSI, соответствующей потребностям. Если такой таблицы нет, система предоставит ее — значение RD будет выбрано в соответствии с внутренней политикой, а значения RT будут выведены из конфигурации vpn-policy для сайта (т. е. система управления будет выделять некие значения RT для VPN). Поскольку сайт относится к типу Spoke (site-role), система управления знает, какие RT должны экспортироваться и импортироваться. Сайт управляется провайдером, поэтому могут быть добавлены значения RT для управления (100:5000). В конфигурацию могут также добавляться стандартные для провайдера правила VPN.

Пример созданной конфигурации PE приведен ниже.

l2vpn vsi context one
  vpn id 12456487
     autodiscovery bgp signaling bgp
     ve id 1001     <---- Указывает маршрутизаторы PE в домене VPLS
     ve range 50    <---- Размер VPLS Edge (VE)
     route-distinguisher 100:3123234324
     route-target import 100:1
     route-target import 100:5000    <---- Стандартная конфигурация SP 
     route-target export 100:2             для управляемого провайдером CE
   !

Когда таблица VSI предоставлена, система управления может начать настройку доступа на PE с использованием информации о выделенном интерфейсе. Тег или VLAN (например, тег экземпляра сервиса) выбирается системой управления. Один тег будет выбран из выделенной для PE подсети, другой будет служить для настройки CE.

Между PE и CE будут также настроены протоколы LACP. В модели с провайдерским управлением это будет делать SP. Этот выбор не зависит от протокола LACP, выбранного абонентом.

Пример созданной конфигурации PE показан ниже.

   !
   bridge-domain 1
    member Ethernet0/0 service-instance 100
    member vsi one
   !
   l2 router-id 198.51.100.1
   !
   l2 router-id 2001:db8::10:1/64
   !

   interface Ethernet0/0
    no ip address
    service instance 100 ethernet
   encapsulation dot1q 100
    !

   !
   router bgp 1
    bgp log-neighbor-changes
    neighbor 198.51.100.4 remote-as 1
    neighbor 198.51.100.4 update-source Loopback0
    !
    address-family l2vpn vpls
     neighbor 198.51.100.4 activate
     neighbor 198.51.100.4 send-community extended
     neighbor 198.51.100.4 suppress-signaling-protocol ldp
     neighbor 2001:db8::0a10:4 activate
     neighbor 2001:db8::0a10:4 send-community extended
    exit-address-family

   !
   interface vlan 100     <---- Связывание AC с MAC-VRF на PE 
     no ip address
     xconnect vsi PE1-VPLS-A
   !
   vlan 100
     state active

Поскольку маршрутизатор CE на этом этапе не доступен, система управления может создать полную конфигурацию CE для загрузки вручную (например, до передачи устройства CE абоненту, как описано в параграфе 5.3.1). Конфигурация CE будет создаваться таким же способом, как для устройства PE. На основе (1) типа CE (производитель, модель), выделенного абоненту, и (2) данных о носителе (bearer) система управления определяет требующий настройки интерфейс CE. Предполагается, что настройка канала PE-CE будет выполняться автоматически с использованием провайдерской системы OSS, поскольку оба ресурса обслуживаются внутри. Параметры интерфейса между CE и ЛВС, такие как теги dot1Q, выводятся из соединения Ethernet с учетом распространения системой управления тегов dot1Q между PE и CE внутри подсети. Это позволяет создать для CE конфигурацию plug’n’play.

Пример созданной конфигурации CE показан ниже.

   interface Ethernet0/1
     switchport trunk allowed vlan none
     switchport mode trunk
     service instance 100 ethernet
     encapsulation default
     l2protocol forward cdp
     xconnect 203.0.113.1 100 encapsulation mpls
   !

1Virtual Private Wire Service — услуги виртуального частного провода.

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

3Label Distribution Protocol — протокол распространения меток.

4Border Gateway Protocol — протокол граничного шлюза.

5Network Management Datastore Architecture — архитектура хранилища информации сетевого управления.

6Internet Engineering Task Force.

7Internet Engineering Steering Group.

8Attachment Circuit.

9Point of Presence.

10Packet switched network.

11Time-Division Multiplexing — мультиплексирование с разделением по времени.

12Synchronous Optical Network / Synchronous Digital Hierarchy — синхронная оптическая сеть / синхронная цифровая иерархия.

13Layer 2 Tunneling Protocol version 3 — протокол туннелирования L2, версия 3.

14Media Access Control — управление доступом к среде.

15Virtual Switching Instance — экземпляр виртуальной коммутации.

16Layer 2 VPN.

17L2VPN Service Model.

18Network Configuration Protocol — протокол настройки конфигурации сети.

19IP-only LAN Service — услуги ЛВС с поддержкой только протокола IP.

20Segment Routing.

21Pseudowire Emulation Edge to Edge — сквозная эмуляция псевдопровода.

22Virtual Extensible Local Area Network — виртуальная расширяемая ЛВС.

23Multiprotocol BGP — многопротокольный BGP.

24Authentication, Authorization, and Accounting — проверка подлинности, проверка полномочий, учет.

25Command Line Interface — интефейс командной строки.

26Service Level Agreement.

27Ethernet Private Line — частная линия Ethernet.

28Ethernet Virtual Private Line — виртуальная частная линия Ethernet.

29Ethernet Line — линия Ethernet.

30Ethernet Virtual Circuit — виртуальной устройство (канал) Ethernet.

31Ethernet Private LAN — частная ЛВС Ethernet.

32Ethernet Virtual Private LAN — виртуальная частная ЛВС Ethernet.

33Ethernet LAN — ЛВС Ethernet.

34Route Target.

35Generic Attribute Registration Protocol — базовый протокол регистрации атрибутов.

36GARP Multicast Registration Protocol — протокол регистрации групп GARP.

37Layer 2 Control Protocol — канал управления L2.

38Customer VLAN.

39VXLAN Network Identifier.

40Switched Virtual Circuit — коммутрируемое виртуальное устройство.

41Link Aggregation Control Protocol — протокол управления агрегированием каналов.

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

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

44Mean Time To Repair.

45Connectivity Fault Management — обработка отказов в соединениях.

46Maintenance Domain — домен обслуживания.

47Maintenance Entity Group End Point — конечная точка группы объектов обслуживания.

48Maintenance Association.

49Maintenance Association Identifier.

50Continuity Check Message.

51Performance Monitoring.

52Access Control List — список контроля доступа.

53End-to-end.

54Digital Subscriber Line Access Multiplexer — мультиплексор цифровых абонентских линий доступа.

55Broadband Access Switch — коммутатор широкополосного доступа.

56Route Distinguisher.

57Committed Information Rate — согласованная скорость передачи информации.

58Excess Information Rate — избыточная скорость передачи информации.

59Peak Information Rate — пиковая скорость передачи информации.

60Differentiated Services Code Point — код дифференцированного обслуживания.

61В оригинале ошибочно сказано «в заголовке кадра Ethernet». См. http://www.rfc-editor.org/errata/eid5615. Прим. перев.

62External NNI — внешний интерфейс между сетями.

63Routing Information Base — база маршрутной информации.

64Carriers’ Carriers — оператор для операторов.

65Cloud Service Provider — поставщик облачных услуг.

66Autonomous System.

67AS Border Router — граничный маршрутизатор AS.

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

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

Часть 2

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

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