Donation Goal Detail
Поддержка HTTPS - Энциклопедия сетевых протоколов

Поддержка HTTPS

С 12 января 2019 года на сайте поддерживаются защищенные соединения HTTPS с заверенным УЦ сертификатом. Если вы заинтересованы в защите ваших коммуникаций, вы можете использовать защищенное соединение, перейдя по ссылке.




RFC 8469 Recommendation to Use the Ethernet Control Word

Internet Engineering Task Force (IETF)                         S. Bryant
Request for Comments: 8469                                      A. Malis
Updates: 4448                                                     Huawei
Category: Standards Track                                    I. Bagdonas
ISSN: 2070-1721                                                  Equinix
                                                           November 2018

Recommendation to Use the Ethernet Control Word

Рекомендации по использованию управляющего слова Ethernet

PDF

Тезисы

Для псевдопроводной (PW1) инкапсуляции Ethernet в RFC 4448 указано, что использование управляющего слова (CW2) не обязательно. В отсутствие CW пакет Ethernet PW может быть ошибочно принят маршрутизатором LSR3 за пакет IP. Это может привести к ошибочному выбору пути для пакета среди ECMP4 а в результате может нарушиться порядок пакетов. Эта проблема стала более серьезной в результате развертывания оборудования с адресами Ethernet MAC5, начинающимися с 0x4 или 0x6. Использование Ethernet PW CW решает эту проблему. Данный документ рекомендует использовать Ethernet PW CW при любых необычных обстоятельствах.

Этот документ обновляет RFC 4448.

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

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

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

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

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

Авторские права (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. Введение

Спецификация псевдопроводной инкапсуляции Ethernet [RFC4448] указывает, что использование управляющего слова CW не обязательно. Маршрутизаторы LSR обычно выполняют поиск после стека меток для определения присутствиея пакета IP в поле данных и, при его обнаружении, выбора следующего интервала (next hop) на основании «пятерки» (five-tuple) — IP-адреса отправителя и получателя, protocol/next-header, номера транспортных портов отправителя и получателя. В отсутствие PW CW пакет Ethernet PW может быть ошибочно принят за пакетом IP маршрутизатором LSR, выбирающим путь ECMP на основе five-tuple. Это может приводить к выбору ошибочного пути ECMP и, в результате, к нарушению порядка доставки пакетов. Дополнительное рассмотрение этой проблемы дано в [RFC4928].

Нарушение порядка в потоке может возникать и при наличии одного пути, если используется классификация трафика и механизмы дифференцированной пересылки. Эти ошибки возникают в результате того, что устройство пересылки некорректно относит пакет к протоколу IP и применяет правила пересылки на основе полей в данных PW (payload).

Пакеты IPv4 и IPv6 начинаются со значений 0x4 и 0x6, соответственно. Может происходить ошибочная идентификация пакета, если пакет Ethernet PW без CW содержит кадр Ethernet с адресом получателя, начинающимся с указанных значений.

По ряду причин эта проблема недавно стала серьезной. Во-первых, Регистрационный комитет IEEE (RAC8) выделил адреса Ethernet MAC, начинающиеся с 0x4 и 0x6, а оборудование с такими MAC-адресами появилось в сетях. Во-вторых, озабоченность вопросами приватности привела к использованию случайных MAC-адресов, назначаемых локально. При случайном назначении адреса, начинающиеся с указанных значений будут составлять приблизительно 1/8 часть всех выделяемых адресов.

Использование Ethernet PW CW решает эту проблему.

Данный документ рекомендует использовать Ethernet PW CW при любых необычных обстоятельствах.

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

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

3. Обоснование

Инкапсуляция Ethernet PW определена в [RFC4448]. Особое значение имеет параграф 4.6, часть которого для удобства читателя приведена ниже. Отметим, что RFC 4448 цитирует [PWE3-CW] для ссылки на [RFC4385] и [VCCV] для ссылки на документ, который в конечном итоге опубликован как [RFC5085].

Управляющее слово, определенное в этом параграфе, основано на Generic PW MPLS Control Word из [PWE3-CW]. Оно обеспечивает возможность упорядочить отдельные кадры в PW, а также избежать распределения пакетов между равноценными путями (ECMP) [RFC2992] и применения механизмов OAM9, включая VCCV [VCCV].

В [PWE3-CW] сказано «Если PW реагирует на нарушение порядка пакетов и передается через MPLS PSN с использованием содержимого данных MPLS (payload) для выбора пути ECMP, псевдопровод может реализовать механизм предотвращения нарушений порядка пакетов». Это требуется для того, чтобы реализации ECMP могли проверить первый полубайт после стека меток MPLS для определения принадлежности пакета к протоколу IP. Если MAC-адрес отправителя в кадре Ethernet, передаваемом через PW без управляющего слова, начинается с 0x4 или 0x6, он будет ошибочно сочтен пакетом IPv4 или IPv6. В зависимости от конфигурации и топологии сети MPLS это может приводить к ситуации, где пакеты данного PW будут передаваться по разным путям. В результате может возрасти число кадров с нарушением порядка доставки в данном PW или пакеты OAM пойдут по пути, отличающемуся от пути обычного трафика (см. параграф 4.4.3 Порядок кадров).

Функции, предоставляемые управляющим словом, могут не требоваться для данного Ethernet PW. Например, ECMP может не быть или не использоваться в данной сети MPLS, соблюдение порядка кадров может не требоваться и пр. В таких случаях роль слова управления невелика и оно может не использоваться. Ранние реализации Ethernet PW развертывались без CW и возможности обрабатывать слово управления при его наличии. Для совместимости со старыми версиями будущие реализации должны быть способны передавать и принимать кадры без CW.

В начале развертывания PW часть коммерчески значимого оборудования была не способна обрабатывать Ethernet CW. Кроме того, в те времена предполагалось, что адреса Ethernet MAC, начинающиеся с 0x4 или 0x6, не будут назначаться IEEE RAC и можно реализовать Ethernet PW без поддержки CW.

С течением времени адреса Ethernet MAC, начинающиеся с 0x4 и 0x6, были выделены RAC. Поэтому допущение о том, что в реальных сетях не будет возникать путаницы между пакетами Ethernet PW без CW и пакетами IP, перестало соответствовать реалиям.

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

Проблема была обозначения в почтовой конференции NANOG, доступной по ссылке https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html.

4. Рекомендации

Неоднозначность идентификации в данных MPLS пакетов Ethernet PW и IP устраняется при использовании Ethernet PW CW. Этот документ обновляет [RFC4448] в том смысле, что входным и выходным граничным устройствам провайдера (PE10) следует поддерживать Ethernet PW CW и при наличии этой поддержки CW должно применяться.

Там, где требуется применение ECMP для трафика Ethernet PW, а входные и выходные устройства PE поддерживают ELI/EL11 [RFC6790] и FAT PW12 [RFC6391], может применяться любой метод. Использование обоих методов на одном PW обычно не требуется и его следует избегать, если позволяют обстоятельства. В случае многосегментных PW при использовании ELI/EL его следует применять на каждом сегменте PW. Метод обеспечения использования ELI/EL на каждом сегменте выходит за рамки этого документа.

5. Равноценные пути (ECMP)

Там, где объем трафика Ethernet PW требует применения ECMP, может использоваться один из двух методов:

  • FAT PW через сеть MPLS PSN13, как описано в [RFC6391];

  • метки энтропии LSP14, как описано в [RFC6790].

RFC 6391 работает на основе повышения энтропии нижней метки стека. Поддержка этой функции требуется на входных и выходных PE. Также требуется, чтобы достаточное число LSR на пути LSP между входным и выходным PE было способно выбирать путь ECMP для пакета MPLS с достаточной глубиной стека.

RFC 6790 работает на основе включения энтропии в путь LSP-часть стека меток. Это требует от входного и выходного PE поддержки вставки и удаления EL и ELI, а также достаточного числа LSR на пути LSP, способных выбирать путь ECMP на основе EL.

В обоих случаях требуется обеспечить прохождение пакетов OAM и пакетов данных по одному пути. Этот вопрос подробно рассмотрен в разделе 7 [RFC6391] и разделе 6 [RFC6790]. Однако в обоих случаях ситуация улучшается по сравнению с поведением ECMP без использования Ethernet PW CW, когда нет возможности обеспечить прохождение пакетов PW OAM по одному пути с пакетами данных PW, для которых ECMP выбирается на основе five-tuple данных IP.

Метка PW вталкивается перед меткой LSP. Поскольку метки ELI/EL являются частью уровня LSP, а не уровня PW, они вталкиваются после метки PW.

6. Пути смягчения проблемы

Когда нет возможности использовать Ethernet PW CW, влияние ECMP может быть предотвращено путем передачи PW по пути с организацией трафика, который не использует поле данных (payload) для распределения нагрузки (например, RSVP-TE [RFC3209]). Однако на таких путях может применяться распределение нагрузки через связки каналов (link-bundle) и, естественно, весь трафик PW должен передаваться через один LSP.

7. Эксплуатационные вопросы

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

Вместо указания типа данных в пакетах MPLS использует уровень управления для сигнализации о типе данных, который следуют за нижней меткой стека. Некоторые LSR пытаются определить типа пакета путем проверки данных MPLS и в ряде случаев просматривают данные дальше PW CW. Если данные представляются пакетом IP или IP указан в заголовке Ethernet, они выполняют расчет ECMP на основе данных, сочтенных полями five-tuple. Однако такое определение типа данных не дает точного результата и при ошибочной идентификации пакета как IP может нарушаться порядок доставки пакетов. Нарушение порядка в этом случае оператору трудно обнаружить. При включении функции, позволяющей использовать информацию из пакета, расположенную после PW CW, при расчете ECMP, оператору следует принимать во внимание возможность нарушения порядка доставки кадров Ethernet, несмотря на присутствие CW.

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

В этом документе отдано предпочтение одной широко распространенной инкапсуляции Ethernet PW над другой. С этим методом связаны вопросы безопасности, рассмотренные в [RFC4448]. Документ не создает других проблем безопасности.

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

Этот документ не запрашивает действий IANA.

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, «Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN», RFC 4385, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>.

[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, «Encapsulation Methods for Transport of Ethernet over MPLS Networks», RFC 4448, DOI 10.17487/RFC4448, April 2006, <https://www.rfc-editor.org/info/rfc4448>.

[RFC4928] Swallow, G., Bryant, S., and L. Andersson, «Avoiding Equal Cost Multipath Treatment in MPLS Networks», BCP 128, RFC 4928, DOI 10.17487/RFC4928, June 2007, <https://www.rfc-editor.org/info/rfc4928>.

[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, «Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network», RFC 6391, DOI 10.17487/RFC6391, November 2011, <https://www.rfc-editor.org/info/rfc6391>.

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, «The Use of Entropy Labels in MPLS Forwarding», RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

[RFC2992] Hopps, C., «Analysis of an Equal-Cost Multi-Path Algorithm», RFC 2992, DOI 10.17487/RFC2992, November 2000, <https://www.rfc-editor.org/info/rfc2992>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., «Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires», RFC 5085, DOI 10.17487/RFC5085, December 2007, <https://www.rfc-editor.org/info/rfc5085>.

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

Авторы благодарят Job Snijders за привлечение внимания к проблеме. Спасибо Pat Thaler за разъяснение вопроса о локальном назначении MAC-адресов и Sasha Vainshtein за ценные разъяснения и замечания.

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

Stewart Bryant

Huawei

Email: stewart.bryant@gmail.com

Andrew G. Malis

Huawei

Email: agmalis@gmail.com

Ignas Bagdonas

Equinix

Email: ibagdona.ietf@gmail.com>


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

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

nmalykh@gmail.com

1Pseudowire.

2Control word.

3Label switching router — маршрутизатор с коммутацией по меткам.

4Equal-cost multipath — множество равноценных путей.

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

6Internet Engineering Task Force.

7Internet Engineering Steering Group.

8Registration Authority Committee.

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

10Provider edge.

11Entropy Label Indicator/Entropy Label — индикатор метки энтропии/метка энтропии.

12Flow-Aware Transport of Pseudowire — осведомленный о потоках транспорт псевдопровода.

13Packet Switched Network — сеть с коммутацией пакетов.

14Label Switched Path — путь с коммутацией по меткам.




RFC 8466 (часть 2)

Часть 1

8. Модуль YANG

Этот модуль YANG импортирует определения типов (typedef) из [RFC6991] и [RFC8341].

<CODE BEGINS> file "ietf-l2vpn-svc@2018-10-09.yang"
module ietf-l2vpn-svc {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc";
  prefix l2vpn-svc;

  import ietf-inet-types {
    prefix inet;
  }
  import ietf-yang-types {
    prefix yang;
  }
  import ietf-netconf-acm {
    prefix nacm;
  }

  organization
    "IETF L2SM Working Group.";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/l2sm/> 
     WG List:  <mailto:l2sm@ietf.org> 
     Editor:   Giuseppe Fioccola
               <mailto:giuseppe.fioccola@tim.it>"; 
  description
    "This YANG module defines a generic service configuration model
     for Layer 2 VPN services common across all vendor
     implementations.

     Copyright (c) 2018 IETF Trust and the persons
     identified as authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info). 

     This version of this YANG module is part of RFC 8466;
     see the RFC itself for full legal notices.";

  revision 2018-10-09 {
    description
      "Initial revision.";
    reference
      "RFC 8466: A YANG Data Model for Layer 2 Virtual Private
       Network (L2VPN) Service Delivery";
  }

  feature carrierscarrier {
    description
      "Enables the support of carriers' carriers (CsC).";
  }

  feature ethernet-oam {
    description
      "Enables the support of Ethernet Service OAM.";
  }

  feature extranet-vpn {
    description
      "Enables the support of extranet VPNs.";
  }

  feature l2cp-control {
    description
      "Enables the support of L2CP control.";
  }

  feature input-bw {
    description
      "Enables the support of input bandwidth in a VPN.";
  }

  feature output-bw {
    description
      "Enables the support of output bandwidth in a VPN.";
  }

  feature uni-list {
    description
      "Enables the support of a list of UNIs in a VPN.";
  }

  feature cloud-access {
    description
      "Allows the VPN to connect to a Cloud Service Provider (CSP)
       or an ISP.";
  }

  feature oam-3ah {
    description
      "Enables the support of OAM 802.3ah.";
  }

  feature micro-bfd {
    description
      "Enables the support of micro-BFD.";
  }

  feature bfd {
    description
      "Enables the support of BFD.";
  }

  feature signaling-options {
    description
      "Enables the support of signaling options.";
  }

  feature site-diversity {
    description
      "Enables the support of site diversity constraints in a VPN.";
  }

  feature encryption {
    description
      "Enables the support of encryption.";
  }

  feature always-on {
    description
      "Enables support for the 'always-on' access constraint.";
  }

  feature requested-type {
    description
      "Enables support for the 'requested-type' access constraint.";
  }

  feature bearer-reference {
    description
      "Enables support for the 'bearer-reference' access
       constraint.";
  }

  feature qos {
    description
      "Enables support for QoS.";
  }

  feature qos-custom {
    description
      "Enables the support of a custom QoS profile.";
  }

  feature lag-interface {
    description
      "Enables LAG interfaces.";
  }

  feature vlan {
    description
      "Enables the support of VLANs.";
  }

  feature dot1q {
    description
      "Enables the support of dot1Q.";
  }

  feature qinq {
    description
      "Enables the support of QinQ.";
  }

  feature qinany {
    description
      "Enables the support of QinAny.";
  }

  feature vxlan {
    description
      "Enables the support of VXLANs.";
  }

  feature lan-tag {
    description
      "Enables LAN tag support in a VPN.";
  }

  feature target-sites {
    description
      "Enables the support of the 'target-sites'
       match-flow parameter.";
  }

  feature bum {
    description
      "Enables BUM capabilities in a VPN.";
  }

  feature mac-loop-prevention {
    description
      "Enables the MAC loop-prevention capability in a VPN.";
  }

  feature lacp {
    description
      "Enables the Link Aggregation Control Protocol (LACP)
       capability in a VPN.";
  }

  feature mac-addr-limit {
    description
      "Enables the MAC address limit capability in a VPN.";
  }

  feature acl {
    description
      "Enables the ACL capability in a VPN.";
  }

  feature cfm {
    description
      "Enables the 802.1ag CFM capability in a VPN.";
  }

  feature y-1731 {
    description
      "Enables the Y.1731 capability in a VPN.";
  }

  typedef svc-id {
    type string;
    description
      "Defines the type of service component identifier.";
  }

  typedef ccm-priority-type {
    type uint8 {
      range "0..7";
    }
    description
      "A 3-bit priority value to be used in the VLAN tag,
       if present in the transmitted frame.";
  }

  typedef control-mode {
    type enumeration {
      enum peer {
        description
          "'peer' mode, i.e., participate in the protocol towards
           the CE.  Peering is common for LACP and the Ethernet
           Local Management Interface (E-LMI) and, occasionally,
           for LLDP.  For VPLSs and VPWSs, the subscriber can also
           request that the SP peer enable spanning tree.";
      }
      enum tunnel {
        description
          "'tunnel' mode, i.e., pass to the egress or destination
           site.  For EPLs, the expectation is that L2CP frames are
           tunneled.";
      }
      enum discard {
        description
          "'discard' mode, i.e., discard the frame.";
      }
    }
    description
      "Defines the type of control mode on L2CP protocols.";
  }

  typedef neg-mode {
    type enumeration {
      enum full-duplex {
        description
          "Defines full-duplex mode.";
      }
      enum auto-neg {
        description
          "Defines auto-negotiation mode.";
      }
    }
    description
      "Defines the type of negotiation mode.";
  }

  identity site-network-access-type {
    description
      "Base identity for the site-network-access type.";
  }

  identity point-to-point {
    base site-network-access-type;
    description
      "Identity for a point-to-point connection.";
  }

  identity multipoint {
    base site-network-access-type;
    description
      "Identity for a multipoint connection, e.g.,
       an Ethernet broadcast segment.";
  }

  identity tag-type {
    description
      "Base identity from which all tag types are derived.";
  }

  identity c-vlan {
    base tag-type;
    description
      "A CVLAN tag, normally using the 0x8100 Ethertype.";
  }

  identity s-vlan {
    base tag-type;
    description
      "An SVLAN tag.";
  }

  identity c-s-vlan {
    base tag-type;
    description
      "Using both a CVLAN tag and an SVLAN tag.";
  }

  identity multicast-tree-type {
    description
      "Base identity for the multicast tree type.";
  }

  identity ssm-tree-type {
    base multicast-tree-type;
    description
      "Identity for the Source-Specific Multicast (SSM) tree type.";
    reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
  }

  identity asm-tree-type {
    base multicast-tree-type;
    description
      "Identity for the Any-Source Multicast (ASM) tree type.";
    reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
  }

  identity bidir-tree-type {
    base multicast-tree-type;
    description
      "Identity for the bidirectional tree type.";
    reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
  }

  identity multicast-gp-address-mapping {
    description
      "Identity for mapping type.";
  }

  identity static-mapping {
    base multicast-gp-address-mapping;
    description
      "Identity for static mapping, i.e., attach the interface
       to the multicast group as a static member.";
  }

  identity dynamic-mapping {
    base multicast-gp-address-mapping;
    description
      "Identity for dynamic mapping, i.e., an interface was added
       to the multicast group as a result of snooping.";
  }

  identity tf-type {
    description
      "Identity for the traffic type.";
  }

  identity multicast-traffic {
    base tf-type;
    description
      "Identity for multicast traffic.";
  }

  identity broadcast-traffic {
    base tf-type;
    description
      "Identity for broadcast traffic.";
  }

  identity unknown-unicast-traffic {
    base tf-type;
    description
      "Identity for unknown unicast traffic.";
  }

  identity encapsulation-type {
    description
      "Identity for the encapsulation type.";
  }

  identity ethernet {
    base encapsulation-type;
    description
      "Identity for Ethernet type.";
  }

  identity vlan {
    base encapsulation-type;
    description
      "Identity for the VLAN type.";
  }

  identity carrierscarrier-type {
    description
      "Identity of the CsC type.";
  }

  identity ldp {
    base carrierscarrier-type;
    description
      "Use LDP as the signaling protocol
       between the PE and the CE.";
  }

  identity bgp {
    base carrierscarrier-type;
    description
      "Use BGP (as per RFC 8277) as the signaling protocol
       between the PE and the CE.
       In this case, BGP must also be configured as
       the routing protocol.";
  }

  identity eth-inf-type {
    description
      "Identity of the Ethernet interface type.";
  }

  identity tagged {
    base eth-inf-type;
    description
      "Identity of the tagged interface type.";
  }

  identity untagged {
    base eth-inf-type;
    description
      "Identity of the untagged interface type.";
  }

  identity lag {
    base eth-inf-type;
    description
      "Identity of the LAG interface type.";
  }

  identity bw-type {
    description
      "Identity of the bandwidth type.";
  }

  identity bw-per-cos {
    base bw-type;
    description
      "Bandwidth is per CoS.";
  }

  identity bw-per-port {
    base bw-type;
    description
      "Bandwidth is per site network access.";
  }

  identity bw-per-site {
    base bw-type;
    description
      "Bandwidth is per site.  It is applicable to
       all the site network accesses within the site.";
  }

  identity bw-per-svc {
    base bw-type;
    description
      "Bandwidth is per VPN service.";
  }

  identity site-vpn-flavor {
    description
      "Base identity for the site VPN service flavor.";
  }

  identity site-vpn-flavor-single {
    base site-vpn-flavor;
    description
      "Identity for the site VPN service flavor.
       Used when the site belongs to only one VPN.";
  }

  identity site-vpn-flavor-multi {
    base site-vpn-flavor;
    description
      "Identity for the site VPN service flavor.
       Used when a logical connection of a site
       belongs to multiple VPNs.";
  }

  identity site-vpn-flavor-nni {
    base site-vpn-flavor;
    description
      "Identity for the site VPN service flavor.
       Used to describe an NNI option A connection.";
  }

  identity service-type {
    description
      "Base identity of the service type.";
  }

  identity vpws {
    base service-type;
    description
      "Point-to-point Virtual Private Wire Service (VPWS)
       service type.";
  }

  identity pwe3 {
    base service-type;
    description
      "Pseudowire Emulation Edge to Edge (PWE3) service type.";
  }

  identity ldp-l2tp-vpls {
    base service-type;
    description
      "LDP-based or L2TP-based multipoint Virtual Private LAN
       Service (VPLS) service type.  This VPLS uses LDP-signaled
       Pseudowires or L2TP-signaled Pseudowires.";
  }

  identity bgp-vpls {
    base service-type;
    description
      "BGP-based multipoint VPLS service type.  This VPLS uses a
       BGP control plane as described in RFCs 4761 and 6624.";
  }

  identity vpws-evpn {
    base service-type;
    description
      "VPWS service type using Ethernet VPNs (EVPNs)
       as specified in RFC 7432.";
  }

  identity pbb-evpn {
    base service-type;
    description
      "Provider Backbone Bridge (PBB) service type using
       EVPNs as specified in RFC 7432.";
  }

  identity bundling-type {
    description
      "The base identity for the bundling type.  It supports
       multiple CE-VLANs associated with an L2VPN service or
       all CE-VLANs associated with an L2VPN service.";
  }

  identity multi-svc-bundling {
    base bundling-type;
    description
      "Identity for multi-service bundling, i.e.,
       multiple CE-VLAN IDs can be associated with an
       L2VPN service at a site.";
  }

  identity one2one-bundling {
    base bundling-type;
    description
      "Identity for one-to-one service bundling, i.e.,
       each L2VPN can be associated with only one CE-VLAN ID
       at a site.";
  }

  identity all2one-bundling {
    base bundling-type;
    description
      "Identity for all-to-one bundling, i.e., all CE-VLAN IDs
       are mapped to one L2VPN service.";
  }

  identity color-id {
    description
      "Base identity of the color ID.";
  }

  identity color-id-cvlan {
    base color-id;
    description
      "Identity of the color ID based on a CVLAN.";
  }

  identity cos-id {
    description
      "Identity of the CoS ID.";
  }

  identity cos-id-pcp {
    base cos-id;
    description
      "Identity of the CoS ID based on the
       Port Control Protocol (PCP).";
  }

  identity cos-id-dscp {
    base cos-id;
    description
      "Identity of the CoS ID based on DSCP.";
  }

  identity color-type {
    description
      "Identity of color types.";
  }

  identity green {
    base color-type;
    description
      "Identity of the 'green' color type.";
  }

  identity yellow {
    base color-type;
    description
      "Identity of the 'yellow' color type.";
  }

  identity red {
    base color-type;
    description
      "Identity of the 'red' color type.";
  }

  identity policing {
    description
      "Identity of the type of policing applied.";
  }

  identity one-rate-two-color {
    base policing;
    description
      "Identity of one-rate, two-color (1R2C).";
  }

  identity two-rate-three-color {
    base policing;
    description
      "Identity of two-rate, three-color (2R3C).";
  }

  identity bum-type {
    description
      "Identity of the BUM type.";
  }

  identity broadcast {
    base bum-type;
    description
      "Identity of broadcast.";
  }

  identity unicast {
    base bum-type;
    description
      "Identity of unicast.";
  }

  identity multicast {
    base bum-type;
    description
      "Identity of multicast.";
  }

  identity loop-prevention-type {
    description
      "Identity of loop prevention.";
  }

  identity shut {
    base loop-prevention-type;
    description
      "Identity of shut protection.";
  }

  identity trap {
    base loop-prevention-type;
    description
      "Identity of trap protection.";
  }

  identity lacp-state {
    description
      "Identity of the LACP state.";
  }

  identity lacp-on {
    base lacp-state;
    description
      "Identity of LACP on.";
  }

  identity lacp-off {
    base lacp-state;
    description
      "Identity of LACP off.";
  }

  identity lacp-mode {
    description
      "Identity of the LACP mode.";
  }

  identity lacp-passive {
    base lacp-mode;
    description
      "Identity of LACP passive.";
  }

  identity lacp-active {
    base lacp-mode;
    description
      "Identity of LACP active.";
  }

  identity lacp-speed {
    description
      "Identity of the LACP speed.";
  }

  identity lacp-fast {
    base lacp-speed;
    description
      "Identity of LACP fast.";
  }

  identity lacp-slow {
    base lacp-speed;
    description
      "Identity of LACP slow.";
  }

  identity bw-direction {
    description
      "Identity for the bandwidth direction.";
  }

  identity input-bw {
    base bw-direction;
    description
      "Identity for the input bandwidth.";
  }

  identity output-bw {
    base bw-direction;
    description
      "Identity for the output bandwidth.";
  }

  identity management {
    description
      "Base identity for the site management scheme.";
  }

  identity co-managed {
    base management;
    description
      "Identity for a co-managed site.";
  }

  identity customer-managed {
    base management;
    description
      "Identity for a customer-managed site.";
  }

  identity provider-managed {
    base management;
    description
      "Identity for a provider-managed site.";
  }

  identity address-family {
    description
      "Identity for an address family.";
  }

  identity ipv4 {
    base address-family;
    description
      "Identity for an IPv4 address family.";
  }

  identity ipv6 {
    base address-family;
    description
      "Identity for an IPv6 address family.";
  }

  identity vpn-topology {
    description
      "Base identity for the VPN topology.";
  }

  identity any-to-any {
    base vpn-topology;
    description
      "Identity for the any-to-any VPN topology.";
  }

  identity hub-spoke {
    base vpn-topology;
    description
      "Identity for the Hub-and-Spoke VPN topology.";
  }

  identity hub-spoke-disjoint {
    base vpn-topology;
    description
      "Identity for the Hub-and-Spoke VPN topology,
       where Hubs cannot communicate with each other.";
  }

  identity site-role {
    description
      "Base identity for a site type.";
  }

  identity any-to-any-role {
    base site-role;
    description
      "Site in an any-to-any L2VPN.";
  }

  identity spoke-role {
    base site-role;
    description
      "Spoke site in a Hub-and-Spoke L2VPN.";
  }

  identity hub-role {
    base site-role;
    description
      "Hub site in a Hub-and-Spoke L2VPN.";
  }

  identity pm-type {
    description
      "Performance-monitoring type.";
  }

  identity loss {
    base pm-type;
    description
      "Loss measurement.";
  }

  identity delay {
    base pm-type;
    description
      "Delay measurement.";
  }

  identity fault-alarm-defect-type {
    description
      "Indicates the alarm-priority defect (i.e., the
       lowest-priority defect that is allowed to
       generate a fault alarm).";
  }

  identity remote-rdi {
    base fault-alarm-defect-type;
    description
      "Indicates the aggregate health
       of the Remote MEPs.";
  }

  identity remote-mac-error {
    base fault-alarm-defect-type;
    description
      "Indicates that one or more of the Remote MEPs are
       reporting a failure in their Port Status TLVs or
       Interface Status TLVs.";
  }

  identity remote-invalid-ccm {
    base fault-alarm-defect-type;
    description
      "Indicates that at least one of the Remote MEP
       state machines is not receiving valid
       Continuity Check Messages (CCMs) from its Remote MEP.";
  }

  identity invalid-ccm {
    base fault-alarm-defect-type;
    description
      "Indicates that one or more invalid CCMs have been
       received and that a period of time 3.5 times the length
       of those CCMs' transmission intervals has not yet expired.";
  }

  identity cross-connect-ccm {
    base fault-alarm-defect-type;
    description
      "Indicates that one or more cross-connect CCMs have been
       received and that 3.5 times the period of at least one of
       those CCMs' transmission intervals has not yet expired.";
  }

  identity frame-delivery-mode {
    description
      "Delivery types.";
  }

  identity discard {
    base frame-delivery-mode;
    description
      "Service frames are discarded.";
  }

  identity unconditional {
    base frame-delivery-mode;
    description
      "Service frames are unconditionally delivered to the
       destination site.";
  }

  identity unknown-discard {
    base frame-delivery-mode;
    description
      "Service frames are conditionally delivered to the
       destination site.  Packets with unknown destination addresses
       will be discarded.";
  }

  identity placement-diversity {
    description
      "Base identity for site placement constraints.";
  }

  identity bearer-diverse {
    base placement-diversity;
    description
      "Identity for bearer diversity.
       The bearers should not use common elements.";
  }

  identity pe-diverse {
    base placement-diversity;
    description
      "Identity for PE diversity.";
  }

  identity pop-diverse {
    base placement-diversity;
    description
      "Identity for POP diversity.";
  }

  identity linecard-diverse {
    base placement-diversity;
    description
      "Identity for linecard diversity.";
  }

  identity same-pe {
    base placement-diversity;
    description
      "Identity for having sites connected on the same PE.";
  }

  identity same-bearer {
    base placement-diversity;
    description
      "Identity for having sites connected using the same bearer.";
  }

  identity tagged-inf-type {
    description
      "Identity for the tagged interface type.";
  }

  identity priority-tagged {
    base tagged-inf-type;
    description
      "Identity for the priority-tagged interface.";
  }

  identity qinq {
    base tagged-inf-type;
    description
      "Identity for the QinQ tagged interface.";
  }

  identity dot1q {
    base tagged-inf-type;
    description
      "Identity for the dot1Q VLAN tagged interface.";
  }

  identity qinany {
    base tagged-inf-type;
    description
      "Identity for the QinAny tagged interface.";
  }

  identity vxlan {
    base tagged-inf-type;
    description
      "Identity for the VXLAN tagged interface.";
  }

  identity provision-model {
    description
      "Base identity for the provision model.";
  }

  identity single-side-provision {
    description
      "Identity for single-sided provisioning with discovery.";
  }

  identity doubled-side-provision {
    description
      "Identity for double-sided provisioning.";
  }

  identity mac-learning-mode {
    description
      "MAC learning mode.";
  }

  identity data-plane {
    base mac-learning-mode;
    description
      "User MAC addresses are learned through ARP broadcast.";
  }

  identity control-plane {
    base mac-learning-mode;
    description
      "User MAC addresses are advertised through EVPN-BGP.";
  }

  identity vpn-policy-filter-type {
    description
      "Base identity for the filter type.";
  }

  identity lan {
    base vpn-policy-filter-type;
    description
      "Identity for a LAN tag filter type.";
  }

  identity mac-action {
    description
      "Base identity for a MAC action.";
  }

  identity drop {
    base mac-action;
    description
      "Identity for dropping a packet.";
  }

  identity flood {
    base mac-action;
    description
      "Identity for packet flooding.";
  }

  identity warning {
    base mac-action;
    description
      "Identity for sending a warning log message.";
  }

  identity qos-profile-direction {
    description
      "Base identity for the QoS-profile direction.";
   }

  identity site-to-wan {
    base qos-profile-direction;
    description
      "Identity for the site-to-WAN direction.";
  }

  identity wan-to-site {
    base qos-profile-direction;
    description
      "Identity for the WAN-to-site direction.";
  }

  identity bidirectional {
    base qos-profile-direction;
    description
      "Identity for both the WAN-to-site direction
       and the site-to-WAN direction.";
  }

  identity vxlan-peer-mode {
    description
      "Base identity for the VXLAN peer mode.";
  }

  identity static-mode {
    base vxlan-peer-mode;
    description
      "Identity for VXLAN access in the static mode.";
  }

  identity bgp-mode {
    base vxlan-peer-mode;
    description
      "Identity for VXLAN access by BGP EVPN learning.";
  }

  identity customer-application {
    description
      "Base identity for a customer application.";
  }

  identity web {
    base customer-application;
    description
      "Identity for a web application (e.g., HTTP, HTTPS).";
  }

  identity mail {
    base customer-application;
    description
      "Identity for a mail application.";
  }

  identity file-transfer {
    base customer-application;
    description
      "Identity for a file-transfer application
       (e.g., FTP, SFTP).";
  }

  identity database {
    base customer-application;
    description
      "Identity for a database application.";
  }

  identity social {
    base customer-application;
    description
      "Identity for a social-network application.";
  }

  identity games {
    base customer-application;
    description
      "Identity for a gaming application.";
  }

  identity p2p {
    base customer-application;
    description
      "Identity for a peer-to-peer application.";
  }

  identity network-management {
    base customer-application;
    description
      "Identity for a management application
       (e.g., Telnet, syslog, SNMP).";
  }

  identity voice {
    base customer-application;
    description
      "Identity for a voice application.";
  }

  identity video {
    base customer-application;
    description
      "Identity for a videoconference application.";
  }

  identity embb {
    base customer-application;
    description
      "Identity for the enhanced Mobile Broadband (eMBB)
       application.  Note that the eMBB application
       requires strict threshold values for a wide variety
       of network performance parameters (e.g., data rate,
       latency, loss rate, reliability).";
  }

  identity urllc {
    base customer-application;
    description
      "Identity for the Ultra-Reliable and Low Latency
       Communications (URLLC) application.  Note that the
       URLLC application requires strict threshold values for
       a wide variety of network performance parameters
       (e.g., latency, reliability).";
  }

  identity mmtc {
    base customer-application;
    description
      "Identity for the massive Machine Type
       Communications (mMTC) application.  Note that the
       mMTC application requires strict threshold values for
       a wide variety of network performance parameters
       (e.g., data rate, latency, loss rate, reliability).";
  }

  grouping site-acl {
    container access-control-list {
      if-feature "acl";
      list mac {
        key "mac-address";
        leaf mac-address {
          type yang:mac-address;
          description
            "MAC addresses.";
        }
        description
          "List of MAC addresses.";
      }
      description
        "Container for the ACL.";
    }
    description
      "Grouping that defines the ACL.";
  }

  grouping site-bum {
    container broadcast-unknown-unicast-multicast {
      if-feature "bum";
      leaf multicast-site-type {
        type enumeration {
          enum receiver-only {
            description
              "The site only has receivers.";
          }
          enum source-only {
            description
              "The site only has sources.";
          }
          enum source-receiver {
            description
              "The site has both sources and receivers.";
          }
        }
        default "source-receiver";
        description
          "Type of multicast site.";
      }
      list multicast-gp-address-mapping {
        key "id";
        leaf id {
          type uint16;
          description
            "Unique identifier for the mapping.";
        }
        leaf vlan-id {
          type uint16 {
            range "0..1024";
          }
          mandatory true;
          description
            "The VLAN ID of the multicast group.
             The range of the 12-bit VLAN ID is 0 to 1024.";
        }
        leaf mac-gp-address {
          type yang:mac-address;
          mandatory true;
          description
            "The MAC address of the multicast group.";
        }
        leaf port-lag-number {
          type uint32;
          description
            "The ports/LAGs belonging to the multicast group.";
        }
        description
          "List of port-to-group mappings.";
      }
      leaf bum-overall-rate {
        type uint64;
        units "bps";
        description
          "Overall rate for BUM.";
      }
      list bum-rate-per-type {
        key "type";
        leaf type {
          type identityref {
            base bum-type;
          }
          description
            "BUM type.";
        }
        leaf rate {
          type uint64;
          units "bps";
          description
            "Rate for BUM.";
        }
        description
          "List of limit rates for the BUM type.";
      }
      description
        "Container of BUM configurations.";
    }
    description
      "Grouping for BUM.";
  }

  grouping site-mac-loop-prevention {
    container mac-loop-prevention {
      if-feature "mac-loop-prevention";
      leaf protection-type {
        type identityref {
          base loop-prevention-type;
        }
        default "trap";
        description
          "Protection type.  By default, the protection
           type is 'trap'.";
      }
      leaf frequency {
        type uint32;
        default "5";
        description
          "The number of times to detect MAC duplication, where
           a 'duplicate MAC address' situation has occurred and
           the duplicate MAC address has been added to a list of
           duplicate MAC addresses.  By default, the number of
           times is 5.";
      }
      leaf retry-timer {
        type uint32;
        units "seconds";
        description
          "The retry timer.  When the retry timer expires,
           the duplicate MAC address will be flushed from
           the MAC-VRF.";
      }
      description
        "Container of MAC loop-prevention parameters.";
    }
    description
      "Grouping for MAC loop prevention.";
  }

  grouping site-service-qos-profile {
    container qos {
      if-feature "qos";
      container qos-classification-policy {
        list rule {
          key "id";
          ordered-by user;
          leaf id {
            type string;
            description
              "A description identifying the QoS classification
               policy rule.";
          }
          choice match-type {
            default "match-flow";
            case match-flow {
              container match-flow {
                leaf dscp {
                  type inet:dscp;
                  description
                    "DSCP value.";
                }
                leaf dot1q {
                  type uint16;
                  description
                    "802.1Q matching.  It is a VLAN tag added into
                     a frame.";
                }
                leaf pcp {
                  type uint8 {
                    range "0..7";
                  }
                  description
                    "PCP value.";
                }
                leaf src-mac {
                  type yang:mac-address;
                  description
                    "Source MAC.";
                }
                leaf dst-mac {
                  type yang:mac-address;
                  description
                    "Destination MAC.";
                }
                leaf color-type {
                  type identityref {
                    base color-type;
                  }
                  description
                    "Color types.";
                }
                leaf-list target-sites {
                  if-feature "target-sites";
                  type svc-id;
                  description
                    "Identifies a site as a traffic destination.";
                }
                leaf any {
                  type empty;
                  description
                    "Allow all.";
                }
                leaf vpn-id {
                  type svc-id;
                  description
                    "Reference to the target VPN.";
                }
                description
                  "Describes flow-matching criteria.";
              }
            }
            case match-application {
              leaf match-application {
                type identityref {
                  base customer-application;
                }
                description
                  "Defines the application to match.";
              }
            }
            description
              "Choice for classification.";
          }
          leaf target-class-id {
            type string;
            description
              "Identification of the CoS.
               This identifier is internal to the
               administration.";
          }
          description
            "List of marking rules.";
        }
        description
          "Configuration of the traffic classification policy.";
      }
      container qos-profile {
        choice qos-profile {
          description
            "Choice for the QoS profile.
             Can be a standard profile or a customized profile.";
          case standard {
            description
              "Standard QoS profile.";
            leaf profile {
              type leafref {
                path "/l2vpn-svc/vpn-profiles/"
                   + "valid-provider-identifiers/"
                   + "qos-profile-identifier";
              }
              description
                "QoS profile to be used.";
            }
          }
          case custom {
            description
              "Customized QoS profile.";
            container classes {
              if-feature "qos-custom";
              list class {
                key "class-id";
                leaf class-id {
                  type string;
                  description
                    "Identification of the CoS.  This identifier is
                     internal to the administration.";
                }
                leaf direction {
                  type identityref {
                    base qos-profile-direction;
                  }
                  default "bidirectional";
                  description
                    "The direction in which the QoS profile is
                     applied.  By default, the direction is
                     bidirectional.";
                }
                leaf policing {
                  type identityref {
                    base policing;
                  }
                  default "one-rate-two-color";
                  description
                    "The policing type can be either one-rate,
                     two-color (1R2C) or two-rate, three-color
                     (2R3C).  By default, the policing type is
                     'one-rate-two-color'.";
                }
                leaf byte-offset {
                  type uint16;
                  description
                    "Number of bytes in the service frame header
                     that are excluded from the QoS calculation
                     (e.g., extra VLAN tags).";
                }
                container frame-delay {
                  choice flavor {
                    case lowest {
                      leaf use-lowest-latency {
                        type empty;
                        description
                          "The traffic class should use the path
                           with the lowest delay.";
                      }
                    }
                    case boundary {
                      leaf delay-bound {
                        type uint16;
                        units "milliseconds";
                        description
                          "The traffic class should use a path
                           with a defined maximum delay.";
                      }
                    }
                    description
                      "Delay constraint on the traffic class.";
                  }
                  description
                    "Delay constraint on the traffic class.";
                }
                container frame-jitter {
                  choice flavor {
                    case lowest {
                      leaf use-lowest-jitter {
                        type empty;
                        description
                          "The traffic class should use the path
                           with the lowest jitter.";
                      }
                    }
                    case boundary {
                      leaf delay-bound {
                        type uint32;
                        units "microseconds";
                        description
                          "The traffic class should use a path
                           with a defined maximum jitter.";
                      }
                    }
                    description
                      "Jitter constraint on the traffic class.";
                  }
                  description
                    "Jitter constraint on the traffic class.";
                }
                container frame-loss {
                  leaf rate {
                    type decimal64 {
                      fraction-digits 2;
                      range "0..100";
                    }
                    units "percent";
                    description
                      "Frame loss rate constraint on the traffic
                       class.";
                  }
                  description
                    "Container for frame loss rate.";
                }
                container bandwidth {
                  leaf guaranteed-bw-percent {
                    type decimal64 {
                      fraction-digits 5;
                      range "0..100";
                    }
                    units "percent";
                    mandatory true;
                    description
                      "Used to define the guaranteed bandwidth
                       as a percentage of the available service
                       bandwidth.";
                  }
                  leaf end-to-end {
                    type empty;
                    description
                      "Used if the bandwidth reservation
                       must be done on the MPLS network too.";
                  }
                  description
                    "Bandwidth constraint on the traffic class.";
                }
                description
                  "List of CoS entries.";
              }
              description
                "Container for list of CoS entries.";
            }
          }
        }
        description
          "Qos profile configuration.";
      }
      description
        "QoS configuration.";
    }
    description
      "Grouping that defines QoS parameters for a site.";
  }

  grouping site-service-mpls {
    container carrierscarrier {
      if-feature "carrierscarrier";
      leaf signaling-type {
        type identityref {
          base carrierscarrier-type;
        }
        default "bgp";
        description
          "CsC.  By default, the signaling type is 'bgp'.";
      }
      description
        "Container for CsC.";
    }
    description
      "Grouping for CsC.";
  }

  container l2vpn-svc {
    container vpn-profiles {
      container valid-provider-identifiers {
        leaf-list cloud-identifier {
          if-feature "cloud-access";
          type string;
          description
            "Identification of the public cloud service or
             Internet service.  Local to each administration.";
        }
        leaf-list qos-profile-identifier {
          type string;
          description
            "Identification of the QoS profile to be used.
             Local to each administration.";
        }
        leaf-list bfd-profile-identifier {
          type string;
          description
            "Identification of the SP BFD profile to be used.
             Local to each administration.";
        }
        leaf-list remote-carrier-identifier {
          type string;
          description
            "Identification of the remote carrier name to be used.
             It can be an L2VPN partner, data-center SP, or
             private CSP.  Local to each administration.";
        }
        nacm:default-deny-write;
        description
          "Container for valid provider identifiers.";
      }
      description
        "Container for VPN profiles.";
    }
    container vpn-services {
      list vpn-service {
        key "vpn-id";
        leaf vpn-id {
          type svc-id;
          description
            "Defines a service identifier.";
        }
        leaf vpn-svc-type {
          type identityref {
            base service-type;
          }
          default "vpws";
          description
            "Service type.  By default, the service type is 'vpws'.";
        }
        leaf customer-name {
          type string;
          description
            "Customer name.";
        }
        leaf svc-topo {
          type identityref {
            base vpn-topology;
          }
          default "any-to-any";
          description
            "Defines the service topology, e.g.,
             'any-to-any', 'hub-spoke'.";
        }
        container cloud-accesses {
          if-feature "cloud-access";
          list cloud-access {
            key "cloud-identifier";
            leaf cloud-identifier {
              type leafref {
                path "/l2vpn-svc/vpn-profiles/"
                   + "valid-provider-identifiers"
                   + "/cloud-identifier";
              }
              description
                "Identification of the cloud service.
                 Local to each administration.";
            }
            choice list-flavor {
              case permit-any {
                leaf permit-any {
                  type empty;
                  description
                    "Allow all sites.";
                }
              }
              case deny-any-except {
                leaf-list permit-site {
                  type leafref {
                    path "/l2vpn-svc/sites/site/site-id";
                  }
                  description
                    "Site ID to be authorized.";
                }
              }
              case permit-any-except {
                leaf-list deny-site {
                  type leafref {
                    path "/l2vpn-svc/sites/site/site-id";
                  }
                  description
                    "Site ID to be denied.";
                }
              }
              description
                "Choice for cloud access policy.
                 By default, all sites in the L2VPN
                 MUST be authorized to access the cloud.";
            }
            description
              "Cloud access configuration.";
          }
          description
            "Container for cloud access configurations.";
        }
        container frame-delivery {
          if-feature "bum";
          container customer-tree-flavors {
            leaf-list tree-flavor {
              type identityref {
                base multicast-tree-type;
              }
              description
                "Type of tree to be used.";
            }
            description
              "Types of trees used by the customer.";
          }
          container bum-deliveries {
            list bum-delivery {
              key "frame-type";
              leaf frame-type {
                type identityref {
                  base tf-type;
                }
                description
                  "Type of frame delivery.  It supports unicast
                   frame delivery, multicast frame delivery,
                   and broadcast frame delivery.";
              }
              leaf delivery-mode {
                type identityref {
                  base frame-delivery-mode;
                }
                default "unconditional";
                description
                  "Defines the frame delivery mode
                   ('unconditional' (default), 'conditional',
                   or 'discard').  By default, service frames are
                   unconditionally delivered to the destination site.";
              }
              description
                "List of frame delivery types and modes.";
            }
            description
              "Defines the frame delivery types and modes.";
          }
          leaf multicast-gp-port-mapping {
            type identityref {
              base multicast-gp-address-mapping;
            }
            mandatory true;
            description
              "Describes the way in which each interface is
               associated with the multicast group.";
          }
          description
            "Multicast global parameters for the VPN service.";
        }
        container extranet-vpns {
          if-feature "extranet-vpn";
          list extranet-vpn {
            key "vpn-id";
            leaf vpn-id {
              type svc-id;
              description
                "Identifies the target VPN that the local VPN wants to
                 access.";
            }
            leaf local-sites-role {
              type identityref {
                base site-role;
              }
              default "any-to-any-role";
              description
                "Describes the role of the local sites in the target
                 VPN topology.  In the any-to-any VPN service topology,
                 the local sites must have the same role, which will be
                 'any-to-any-role'.  In the Hub-and-Spoke VPN service
                 topology or the Hub-and-Spoke-Disjoint VPN service
                 topology, the local sites must have a Hub role or a
                 Spoke role.";
            }
            description
              "List of extranet VPNs to which the local VPN
               is attached.";
          }
          description
            "Container for extranet VPN configurations.";
        }
        leaf ce-vlan-preservation {
          type boolean;
          mandatory true;
          description
            "Preserves the CE-VLAN ID from ingress to egress, i.e.,
             the CE-VLAN tag of the egress frame is identical to
             that of the ingress frame that yielded this
             egress service frame.  If all-to-one bundling within
             a site is enabled, then preservation applies to all
             ingress service frames.  If all-to-one bundling is
             disabled, then preservation applies to tagged
             ingress service frames having CE-VLAN IDs 1 through 4094.";
        }
        leaf ce-vlan-cos-preservation {
          type boolean;
          mandatory true;
          description
            "CE VLAN CoS preservation.  The PCP bits in the CE-VLAN tag
             of the egress frame are identical to those of the
             ingress frame that yielded this egress service frame.";
        }
        leaf carrierscarrier {
          if-feature "carrierscarrier";
          type boolean;
          default "false";
          description
            "The VPN is using CsC, and so MPLS is required.";
        }
        description
          "List of VPN services.";
      }
      description
        "Container for VPN services.";
    }
    container sites {
      list site {
        key "site-id";
        leaf site-id {
          type string;
          description
            "Identifier of the site.";
        }
        leaf site-vpn-flavor {
          type identityref {
            base site-vpn-flavor;
          }
          default "site-vpn-flavor-single";
          description
            "Defines the way that the VPN multiplexing is
             done, e.g., whether the site belongs to
             a single VPN site or a multi-VPN site.  By
             default, the site belongs to a single VPN.";
        }
        container devices {
          when "derived-from-or-self(../management/type, "
             + "'l2vpn-svc:provider-managed') or "
             + "derived-from-or-self(../management/type, "
             + "'l2vpn-svc:co-managed')" {
            description
              "Applicable only for a provider-managed or
               co-managed device.";
          }
          list device {
            key "device-id";
            leaf device-id {
              type string;
              description
                "Identifier for the device.";
            }
            leaf location {
              type leafref {
                path "../../../locations/location/location-id";
              }
              mandatory true;
              description
                "Location of the device.";
            }
            container management {
              when "derived-from-or-self(../../../management/type, "
                 + "'l2vpn-svc:co-managed')" {
                description
                  "Applicable only for a co-managed device.";
              }
              leaf transport {
                type identityref {
                  base address-family;
                }
                description
                  "Transport protocol or address family
                   used for management.";
              }
              leaf address {
                when '(../ transport)' {
                  description
                    "If the address family is specified, then the
                     address should also be specified.  If the
                     transport is not specified, then the address
                     should not be specified.";
                }
                type inet:ip-address;
                description
                  "Management address.";
              }
              description
                "Management configuration.  Applicable only for a
                 co-managed device.";
            }
            description
              "List of devices requested by the customer.";
          }
          description
            "Device configurations.";
        }
        container management {
          leaf type {
            type identityref {
              base management;
            }
            mandatory true;
            description
              "Management type of the connection.";
          }
          description
            "Management configuration.";
        }
        container locations {
          list location {
            key "location-id";
            leaf location-id {
              type string;
              description
                "Location ID.";
            }
            leaf address {
              type string;
              description
                "Address (number and street) of the site.";
            }
            leaf postal-code {
              type string;
              description
                "Postal code of the site.  The format of 'postal-code'
                 is similar to the 'PC' (postal code) label format
                 defined in RFC 4119.";
            }
            leaf state {
              type string;
              description
                "State (region) of the site.  This leaf can also be used
                 to describe a region of a country that does not have
                 states.";
            }
            leaf city {
              type string;
              description
                "City of the site.";
            }
            leaf country-code {
              type string;
              description
                "Country of the site.  The format of 'country-code' is
                 similar to the 'country' label defined in RFC 4119.";
            }
            description
              "List of locations.";
          }
          description
            "Location of the site.";
        }
        container site-diversity {
          if-feature "site-diversity";
          container groups {
            list group {
              key "group-id";
              leaf group-id {
                type string;
                description
                  "The group-id to which the site belongs.";
              }
              description
                "List of group-ids.";
            }
            description
              "Groups to which the site belongs.
               All site network accesses will inherit those group
               values.";
          }
          description
            "The type of diversity constraint.";
        }
        container vpn-policies {
          list vpn-policy {
            key "vpn-policy-id";
            leaf vpn-policy-id {
              type string;
              description
                "Unique identifier for the VPN policy.";
            }
            list entries {
              key "id";
              leaf id {
                type string;
                description
                  "Unique identifier for the policy entry.";
              }
              container filters {
                list filter {
                  key "type";
                  ordered-by user;
                  leaf type {
                    type identityref {
                      base vpn-policy-filter-type;
                    }
                    description
                      "Type of VPN policy filter.";
                  }
                  leaf-list lan-tag {
                    when "derived-from-or-self(../type, "
                       + "'l2vpn-svc:lan')" {
                      description
                        "Only applies when the VPN policy filter is a
                         LAN tag filter.";
                    }
                    if-feature "lan-tag";
                    type uint32;
                    description
                      "List of Ethernet LAN tags to be matched.  An
                       Ethernet LAN tag identifies a particular
                       broadcast domain in a VPN.";
                  }
                  description
                    "List of filters used on the site.  This list can
                     be augmented.";
                }
                description
                  "If a more granular VPN attachment is necessary,
                   filtering can be used.  If used, it permits the
                   splitting of site LANs among multiple VPNs.  The
                   site LAN can be split based on either the LAN tag or
                   the LAN prefix.  If no filter is used, all the LANs
                   will be part of the same VPNs with the same role.";
              }
              list vpn {
                key "vpn-id";
                leaf vpn-id {
                  type leafref {
                    path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
                  }
                  description
                    "Reference to an L2VPN.";
                }
                leaf site-role {
                  type identityref {
                    base site-role;
                  }
                  default "any-to-any-role";
                  description
                    "Role of the site in the L2VPN.";
                }
                description
                  "List of VPNs with which the LAN is associated.";
              }
              description
                "List of entries for an export policy.";
            }
            description
              "List of VPN policies.";
          }
          description
            "VPN policy.";
        }
        container service {
          uses site-service-qos-profile;
          uses site-service-mpls;
          description
            "Service parameters on the attachment.";
        }
        uses site-bum;
        uses site-mac-loop-prevention;
        uses site-acl;
        leaf actual-site-start {
          type yang:date-and-time;
          config false;
          description
            "This leaf is optional.  It indicates the date and time
             when the service at a particular site actually started.";
        }
        leaf actual-site-stop {
          type yang:date-and-time;
          config false;
          description
            "This leaf is optional.  It indicates the date and time
             when the service at a particular site actually stopped.";
        }
        leaf bundling-type {
          type identityref {
            base bundling-type;
          }
          default "one2one-bundling";
          description
            "Bundling type.  By default, each L2VPN
             can be associated with only one
             CE-VLAN, i.e., one-to-one bundling is used.";
        }
        leaf default-ce-vlan-id {
          type uint32;
          mandatory true;
          description
            "Default CE VLAN ID set at the site level.";
        }
        container site-network-accesses {
          list site-network-access {
            key "network-access-id";
            leaf network-access-id {
              type string;
              description
                "Identifier of network access.";
            }
            leaf remote-carrier-name {
              when "derived-from-or-self(../../../site-vpn-flavor,"
                 + "'l2vpn-svc:site-vpn-flavor-nni')" {
                description
                  "Relevant when the site's VPN flavor is
                   'site-vpn-flavor-nni'.";
              }
              type leafref {
                path "/l2vpn-svc/vpn-profiles/"
                   + "valid-provider-identifiers"
                   + "/remote-carrier-identifier";
              }
              description
                "Remote carrier name.  The 'remote-carrier-name'
                 parameter must be configured only when
                 'site-vpn-flavor' is set to 'site-vpn-flavor-nni'.
                 If it is not set, it indicates that the customer
                 does not know the remote carrier's name
                 beforehand.";
            }
            leaf type {
              type identityref {
                base site-network-access-type;
              }
              default "point-to-point";
              description
                "Describes the type of connection, e.g.,
                 point-to-point or multipoint.";
            }
            choice location-flavor {
              case location {
                when "derived-from-or-self(../../management/type, "
                   + "'l2vpn-svc:customer-managed')" {
                  description
                    "Applicable only for a customer-managed device.";
                }
                leaf location-reference {
                  type leafref {
                    path "../../../locations/location/location-id";
                  }
                  description
                    "Location of the site-network-access.";
                }
              }
              case device {
                when "derived-from-or-self(../../management/type, "
                   + "'l2vpn-svc:provider-managed') or "
                   + "derived-from-or-self(../../management/type, "
                   + "'l2vpn-svc:co-managed')" {
                  description
                    "Applicable only for a provider-managed
                     or co-managed device.";
                }
                leaf device-reference {
                  type leafref {
                    path "../../../devices/device/device-id";
                  }
                  description
                    "Identifier of the CE to use.";
                }
              }
              mandatory true;
              description
                "Choice of how to describe the site's location.";
            }
            container access-diversity {
              if-feature "site-diversity";
              container groups {
                list group {
                  key "group-id";
                  leaf group-id {
                    type string;
                    description
                      "Group-id to which the site belongs.";
                  }
                  description
                    "List of group-ids.";
                }
                description
                  "Groups to which the site or site-network-access
                   belongs.";
              }
              container constraints {
                list constraint {
                  key "constraint-type";
                  leaf constraint-type {
                    type identityref {
                      base placement-diversity;
                    }
                    description
                      "The type of diversity constraint.";
                  }
                  container target {
                    choice target-flavor {
                      default "id";
                      case id {
                        list group {
                          key "group-id";
                          leaf group-id {
                            type string;
                            description
                              "The constraint will apply against this
                               particular group-id.";
                          }
                          description
                            "List of groups.";
                        }
                      }
                      case all-accesses {
                        leaf all-other-accesses {
                          type empty;
                          description
                            "The constraint will apply against all other
                             site network accesses of this site.";
                        }
                      }
                      case all-groups {
                        leaf all-other-groups {
                          type empty;
                          description
                            "The constraint will apply against all other
                             groups the customer is managing.";
                        }
                      }
                      description
                        "Choice for the group definition.";
                    }
                    description
                      "The constraint will apply against
                       this list of groups.";
                  }
                  description
                    "List of constraints.";
                }
                description
                  "Constraints for placing this site network access.";
              }
              description
                "Diversity parameters.";
            }
            container bearer {
              container requested-type {
                if-feature "requested-type";
                leaf type {
                  type string;
                  description
                    "Type of requested bearer: Ethernet, ATM, Frame
                     Relay, IP Layer 2 transport, Frame Relay Data
                     Link Connection Identifier (DLCI), SONET/SDH,
                     PPP.";
                }
                leaf strict {
                  type boolean;
                  default "false";
                  description
                    "Defines whether the requested type is a preference
                     or a strict requirement.";
                }
                description
                  "Container for requested types.";
              }
              leaf always-on {
                if-feature "always-on";
                type boolean;
                default "true";
                description
                  "Request for an 'always-on' access type.
                   For example, this could mean no dial-in access
                   type.";
              }
              leaf bearer-reference {
                if-feature "bearer-reference";
                type string;
                description
                  "An internal reference for the SP.";
              }
              description
                "Bearer-specific parameters.  To be augmented.";
            }
            container connection {
              leaf encapsulation-type {
                type identityref {
                  base encapsulation-type;
                }
                default "ethernet";
                description
                  "Encapsulation type.  By default, the
                   encapsulation type is set to 'ethernet'.";
              }
              leaf eth-inf-type {
                type identityref {
                  base eth-inf-type;
                }
                default "untagged";
                description
                  "Ethernet interface type.  By default, the
                   Ethernet interface type is set to 'untagged'.";
              }
              container tagged-interface {
                leaf type {
                  type identityref {
                    base tagged-inf-type;
                  }
                  default "priority-tagged";
                  description
                    "Tagged interface type.  By default,
                     the type of the tagged interface is
                     'priority-tagged'.";
                }
                container dot1q-vlan-tagged {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:dot1q')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'dot1q'.";
                  }
                  if-feature "dot1q";
                  leaf tg-type {
                    type identityref {
                      base tag-type;
                    }
                    default "c-vlan";
                    description
                      "Tag type.  By default, the tag type is
                       'c-vlan'.";
                  }
                  leaf cvlan-id {
                    type uint16;
                    mandatory true;
                    description
                      "VLAN identifier.";
                  }
                  description
                    "Tagged interface.";
                }
                container priority-tagged {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:priority-tagged')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'priority-tagged'.";
                  }
                  leaf tag-type {
                    type identityref {
                      base tag-type;
                    }
                    default "c-vlan";
                    description
                      "Tag type.  By default, the tag type is
                       'c-vlan'.";
                  }
                  description
                    "Priority tagged.";
                }
                container qinq {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:qinq')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'qinq'.";
                  }
                  if-feature "qinq";
                  leaf tag-type {
                    type identityref {
                      base tag-type;
                    }
                    default "c-s-vlan";
                    description
                      "Tag type.  By default, the tag type is
                       'c-s-vlan'.";
                  }
                  leaf svlan-id {
                    type uint16;
                    mandatory true;
                    description
                      "SVLAN identifier.";
                  }
                  leaf cvlan-id {
                    type uint16;
                    mandatory true;
                    description
                      "CVLAN identifier.";
                  }
                  description
                    "QinQ.";
                }
                container qinany {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:qinany')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'qinany'.";
                  }
                  if-feature "qinany";
                  leaf tag-type {
                    type identityref {
                      base tag-type;
                    }
                    default "s-vlan";
                    description
                      "Tag type.  By default, the tag type is
                       's-vlan'.";
                  }
                  leaf svlan-id {
                    type uint16;
                    mandatory true;
                    description
                      "SVLAN ID.";
                  }
                  description
                    "Container for QinAny.";
                }
                container vxlan {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:vxlan')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'vxlan'.";
                  }
                  if-feature "vxlan";
                  leaf vni-id {
                    type uint32;
                    mandatory true;
                    description
                      "VXLAN Network Identifier (VNI).";
                  }
                  leaf peer-mode {
                    type identityref {
                      base vxlan-peer-mode;
                    }
                    default "static-mode";
                    description
                      "Specifies the VXLAN access mode.  By default,
                       the peer mode is set to 'static-mode'.";
                  }
                  list peer-list {
                    key "peer-ip";
                    leaf peer-ip {
                      type inet:ip-address;
                      description
                        "Peer IP.";
                    }
                    description
                      "List of peer IP addresses.";
                  }
                  description
                    "QinQ.";
                }
                description
                  "Container for tagged interfaces.";
              }
              container untagged-interface {
                leaf speed {
                  type uint32;
                  units "mbps";
                  default "10";
                  description
                    "Port speed.";
                }
                leaf mode {
                  type neg-mode;
                  default "auto-neg";
                  description
                    "Negotiation mode.";
                }
                leaf phy-mtu {
                  type uint32;
                  units "bytes";
                  description
                    "PHY MTU.";
                }
                leaf lldp {
                  type boolean;
                  default "false";
                  description
                    "LLDP.  Indicates that LLDP is supported.";
                }
                container oam-802.3ah-link {
                  if-feature "oam-3ah";
                  leaf enabled {
                    type boolean;
                    default "false";
                    description
                      "Indicates whether or not to support
                       OAM 802.3ah links.";
                  }
                  description
                    "Container for OAM 802.3ah links.";
                }
                leaf uni-loop-prevention {
                  type boolean;
                  default "false";
                  description
                    "If this leaf is set to 'true', then the port
                     automatically goes down when a physical
                     loopback is detected.";
                }
                description
                  "Container of untagged interface attribute
                   configurations.";
              }
              container lag-interfaces {
                if-feature "lag-interface";
                list lag-interface {
                  key "index";
                  leaf index {
                    type string;
                    description
                      "LAG interface index.";
                  }
                  container lacp {
                    if-feature "lacp";
                    leaf enabled {
                      type boolean;
                      default "false";
                      description
                        "LACP on/off.  By default, LACP is disabled.";
                    }
                    leaf mode {
                      type neg-mode;
                      description
                        "LACP mode.  LACP modes have active mode and
                         passive mode ('false').  'Active mode' means
                         initiating the auto-speed negotiation and
                         trying to form an Ethernet channel with the
                         other end.  'Passive mode' means not initiating
                         the negotiation but responding to LACP packets
                         initiated by the other end (e.g., full duplex
                         or half duplex).";
                    }
                    leaf speed {
                      type uint32;
                      units "mbps";
                      default "10";
                      description
                        "LACP speed.  By default, the LACP speed is 10
                         Mbps.";
                    }
                    leaf mini-link-num {
                      type uint32;
                      description
                        "Defines the minimum number of links that must
                         be active before the aggregating link is put
                         into service.";
                    }
                    leaf system-priority {
                      type uint16;
                      default "32768";
                      description
                        "Indicates the LACP priority for the system.
                         The range is from 0 to 65535.
                         The default is 32768.";
                    }
                    container micro-bfd {
                      if-feature "micro-bfd";
                      leaf enabled {
                        type enumeration {
                          enum on {
                            description
                              "Micro-bfd on.";
                          }
                          enum off {
                            description
                              "Micro-bfd off.";
                          }
                        }
                        default "off";
                        description
                          "Micro-BFD on/off.  By default, micro-BFD
                           is set to 'off'.";
                      }
                      leaf interval {
                        type uint32;
                        units "milliseconds";
                        description
                          "BFD interval.";
                      }
                      leaf hold-timer {
                        type uint32;
                        units "milliseconds";
                        description
                          "BFD hold timer.";
                      }
                      description
                        "Container of micro-BFD configurations.";
                    }
                    container bfd {
                      if-feature "bfd";
                      leaf enabled {
                        type boolean;
                        default "false";
                        description
                          "BFD activation.  By default, BFD is not
                           activated.";
                      }
                      choice holdtime {
                        default "fixed";
                        case profile {
                          leaf profile-name {
                            type leafref {
                              path "/l2vpn-svc/vpn-profiles/"
                                 + "valid-provider-identifiers"
                                 + "/bfd-profile-identifier";
                            }
                            description
                              "SP well-known profile.";
                          }
                          description
                            "SP well-known profile.";
                        }
                        case fixed {
                          leaf fixed-value {
                            type uint32;
                            units "milliseconds";
                            description
                              "Expected hold time expressed in
                               milliseconds.";
                          }
                        }
                        description
                          "Choice for the hold-time flavor.";
                      }
                      description
                        "Container for BFD.";
                    }
                    container member-links {
                      list member-link {
                        key "name";
                        leaf name {
                          type string;
                          description
                            "Member link name.";
                        }
                        leaf speed {
                          type uint32;
                          units "mbps";
                          default "10";
                          description
                            "Port speed.";
                        }
                        leaf mode {
                          type neg-mode;
                          default "auto-neg";
                          description
                            "Negotiation mode.";
                        }
                        leaf link-mtu {
                          type uint32;
                          units "bytes";
                          description
                            "Link MTU size.";
                        }
                        container oam-802.3ah-link {
                          if-feature "oam-3ah";
                          leaf enabled {
                            type boolean;
                            default "false";
                            description
                              "Indicates whether OAM 802.3ah links are
                               supported.";
                          }
                          description
                            "Container for OAM 802.3ah links.";
                        }
                        description
                          "Member link.";
                      }
                      description
                        "Container of the member link list.";
                    }
                    leaf flow-control {
                      type boolean;
                      default "false";
                      description
                        "Flow control.  Indicates whether flow control
                         is supported.";
                    }
                    leaf lldp {
                      type boolean;
                      default "false";
                      description
                        "LLDP.  Indicates whether LLDP is supported.";
                    }
                    description
                      "LACP.";
                  }
                  description
                    "List of LAG interfaces.";
                }
                description
                  "Container of LAG interface attribute
                   configurations.";
              }
              list cvlan-id-to-svc-map {
                key "svc-id";
                leaf svc-id {
                  type leafref {
                    path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
                  }
                  description
                    "VPN service identifier.";
                }
                list cvlan-id {
                  key "vid";
                  leaf vid {
                    type uint16;
                    description
                      "CVLAN ID.";
                  }
                  description
                    "List of CVLAN-ID-to-SVC-map configurations.";
                }
                description
                  "List of CVLAN-ID-to-L2VPN-service-map
                   configurations.";
              }
              container l2cp-control {
                if-feature "l2cp-control";
                leaf stp-rstp-mstp {
                  type control-mode;
                  description
                    "STP / Rapid STP (RSTP) / Multiple STP (MSTP)
                     protocol type applicable to all sites.";
                }
                leaf pause {
                  type control-mode;
                  description
                    "Pause protocol type applicable to all sites.";
                }
                leaf lacp-lamp {
                  type control-mode;
                  description
                    "LACP / Link Aggregation Marker Protocol (LAMP).";
                }
                leaf link-oam {
                  type control-mode;
                  description
                    "Link OAM.";
                }
                leaf esmc {
                  type control-mode;
                  description
                    "Ethernet Synchronization Messaging Channel
                     (ESMC).";
                }
                leaf l2cp-802.1x {
                  type control-mode;
                  description
                    "IEEE 802.1x.";
                }
                leaf e-lmi {
                  type control-mode;
                  description
                    "E-LMI.";
                }
                leaf lldp {
                  type boolean;
                  description
                    "LLDP protocol type applicable to all sites.";
                }
                leaf ptp-peer-delay {
                  type control-mode;
                  description
                    "Precision Time Protocol (PTP) peer delay.";
                }
                leaf garp-mrp {
                  type control-mode;
                  description
                    "GARP/MRP.";
                }
                description
                  "Container of L2CP control configurations.";
              }
              container oam {
                if-feature "ethernet-oam";
                leaf md-name {
                  type string;
                  mandatory true;
                  description
                    "Maintenance domain name.";
                }
                leaf md-level {
                  type uint16 {
                    range "0..255";
                  }
                  mandatory true;
                  description
                    "Maintenance domain level.  The level may be
                     restricted in certain protocols (e.g.,
                     protocols in Layer 0 to Layer 7).";
                }
                list cfm-8021-ag {
                  if-feature "cfm";
                  key "maid";
                  leaf maid {
                    type string;
                    mandatory true;
                    description
                      "Identifies a Maintenance Association (MA).";
                  }
                  leaf mep-id {
                    type uint32;
                    description
                      "Local Maintenance Entity Group End Point (MEP)
                       ID.  The non-existence of this leaf means
                       that no defects are to be reported.";
                  }
                  leaf mep-level {
                    type uint32;
                    description
                      "Defines the MEP level.  The non-existence of this
                       leaf means that no defects are to be reported.";
                  }
                  leaf mep-up-down {
                    type enumeration {
                      enum up {
                        description
                          "MEP up.";
                      }
                      enum down {
                        description
                          "MEP down.";
                      }
                    }
                    default "up";
                    description
                      "MEP up/down.  By default, MEP up is used.
                       The non-existence of this leaf means that
                       no defects are to be reported.";
                  }
                  leaf remote-mep-id {
                    type uint32;
                    description
                      "Remote MEP ID.  The non-existence of this leaf
                       means that no defects are to be reported.";
                  }
                  leaf cos-for-cfm-pdus {
                    type uint32;
                    description
                      "CoS for CFM PDUs.  The non-existence of this leaf
                       means that no defects are to be reported.";
                  }
                  leaf ccm-interval {
                    type uint32;
                    units "milliseconds";
                    default "10000";
                    description
                      "CCM interval.  By default, the CCM interval is
                       10,000 milliseconds (10 seconds).";
                  }
                  leaf ccm-holdtime {
                    type uint32;
                    units "milliseconds";
                    default "35000";
                    description
                      "CCM hold time.  By default, the CCM hold time
                       is 3.5 times the CCM interval.";
                  }
                  leaf alarm-priority-defect {
                    type identityref {
                      base fault-alarm-defect-type;
                    }
                    default "remote-invalid-ccm";
                    description
                      "The lowest-priority defect that is
                       allowed to generate a fault alarm.  By default,
                       'fault-alarm-defect-type' is set to
                       'remote-invalid-ccm'.  The non-existence of
                       this leaf means that no defects are
                       to be reported.";
                  }
                  leaf ccm-p-bits-pri {
                    type ccm-priority-type;
                    description
                      "The priority parameter for CCMs transmitted by
                       the MEP.  The non-existence of this leaf means
                       that no defects are to be reported.";
                  }
                  description
                    "List of 802.1ag CFM attributes.";
                }
                list y-1731 {
                  if-feature "y-1731";
                  key "maid";
                  leaf maid {
                    type string;
                    mandatory true;
                    description
                      "Identifies an MA.";
                  }
                  leaf mep-id {
                    type uint32;
                    description
                      "Local MEP ID.  The non-existence of this leaf
                       means that no measurements are to be reported.";
                  }
                  leaf type {
                    type identityref {
                      base pm-type;
                    }
                    default "delay";
                    description
                      "Performance-monitoring types.  By default, the
                       performance-monitoring type is set to 'delay'.
                       The non-existence of this leaf means that no
                       measurements are to be reported.";
                  }
                  leaf remote-mep-id {
                    type uint32;
                    description
                      "Remote MEP ID.  The non-existence of this
                       leaf means that no measurements are to be
                       reported.";
                  }
                  leaf message-period {
                    type uint32;
                    units "milliseconds";
                    default "10000";
                    description
                      "Defines the interval between Y.1731
                       performance-monitoring messages.  The message
                       period is expressed in milliseconds.";
                  }
                  leaf measurement-interval {
                    type uint32;
                    units "seconds";
                    description
                      "Specifies the measurement interval for
                       statistics.  The measurement interval is
                       expressed in seconds.";
                  }
                  leaf cos {
                    type uint32;
                    description
                      "CoS.  The non-existence of this leaf means that
                       no measurements are to be reported.";
                  }
                  leaf loss-measurement {
                    type boolean;
                    default "false";
                    description
                      "Indicates whether or not to enable loss
                       measurement.  By default, loss
                       measurement is not enabled.";
                  }
                  leaf synthetic-loss-measurement {
                    type boolean;
                    default "false";
                    description
                      "Indicates whether or not to enable synthetic loss
                       measurement.  By default, synthetic loss
                       measurement is not enabled.";
                  }
                  container delay-measurement {
                    leaf enable-dm {
                      type boolean;
                      default "false";
                      description
                        "Indicates whether or not to enable delay
                         measurement.  By default, delay measurement
                         is not enabled.";
                    }
                    leaf two-way {
                      type boolean;
                      default "false";
                      description
                        "Indicates whether delay measurement is two-way
                         ('true') or one-way ('false').  By default,
                         one-way measurement is enabled.";
                    }
                    description
                      "Container for delay measurement.";
                  }
                  leaf frame-size {
                    type uint32;
                    units "bytes";
                    description
                      "Frame size.  The non-existence of this leaf
                       means that no measurements are to be reported.";
                  }
                  leaf session-type {
                    type enumeration {
                      enum proactive {
                        description
                          "Proactive mode.";
                      }
                      enum on-demand {
                        description
                          "On-demand mode.";
                      }
                    }
                    default "on-demand";
                    description
                      "Session type.  By default, the session type
                       is 'on-demand'.  The non-existence of this
                       leaf means that no measurements are to be
                       reported.";
                  }
                  description
                    "List of configured Y-1731 instances.";
                }
                description
                  "Container for Ethernet Service OAM.";
              }
              description
                "Container for connection requirements.";
            }
            container availability {
              leaf access-priority {
                type uint32;
                default "100";
                description
                  "Access priority.  The higher the access-priority
                   value, the higher the preference will be for the
                   access in question.";
              }
              choice redundancy-mode {
                case single-active {
                  leaf single-active {
                    type empty;
                    description
                      "Single-active mode.";
                  }
                  description
                    "In single-active mode, only one node forwards
                     traffic to and from the Ethernet segment.";
                }
                case all-active {
                  leaf all-active {
                    type empty;
                    description
                      "All-active mode.";
                  }
                  description
                    "In all-active mode, all nodes can forward
                     traffic.";
                }
                description
                  "Redundancy mode choice.";
              }
              description
                "Container of available optional configurations.";
            }
            container vpn-attachment {
              choice attachment-flavor {
                case vpn-id {
                  leaf vpn-id {
                    type leafref {
                      path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
                    }
                    description
                      "Reference to an L2VPN.  Referencing a vpn-id
                       provides an easy way to attach a particular
                       logical access to a VPN.  In this case,
                       the vpn-id must be configured.";
                  }
                  leaf site-role {
                    type identityref {
                      base site-role;
                    }
                    default "any-to-any-role";
                    description
                      "Role of the site in the L2VPN.  When referencing
                       a vpn-id, the site-role setting must be added to
                       express the role of the site in the target VPN
                       service topology.";
                  }
                }
                case vpn-policy-id {
                  leaf vpn-policy-id {
                    type leafref {
                      path "../../../../vpn-policies/vpn-policy/"
                         + "vpn-policy-id";
                    }
                    description
                      "Reference to a VPN policy.";
                  }
                }
                mandatory true;
                description
                  "Choice for the VPN attachment flavor.";
              }
              description
                "Defines the VPN attachment of a site.";
            }
            container service {
              container svc-bandwidth {
                if-feature "input-bw";
                list bandwidth {
                  key "direction type";
                  leaf direction {
                    type identityref {
                      base bw-direction;
                    }
                    description
                      "Indicates the bandwidth direction.  It can be
                       the bandwidth download direction from the SP to
                       the site or the bandwidth upload direction from
                       the site to the SP.";
                  }
                  leaf type {
                    type identityref {
                      base bw-type;
                    }
                    description
                      "Bandwidth type.  By default, the bandwidth type
                       is set to 'bw-per-cos'.";
                  }
                  leaf cos-id {
                    when "derived-from-or-self(../type, "
                       + "'l2vpn-svc:bw-per-cos')" {
                      description
                        "Relevant when the bandwidth type is set to
                         'bw-per-cos'.";
                    }
                    type uint8;
                    description
                      "Identifier of the CoS, indicated by DSCP or a
                       CE-VLAN CoS (802.1p) value in the service frame.
                       If the bandwidth type is set to 'bw-per-cos',
                       the CoS ID MUST also be specified.";
                  }
                  leaf vpn-id {
                    when "derived-from-or-self(../type, "
                       + "'l2vpn-svc:bw-per-svc')" {
                      description
                        "Relevant when the bandwidth type is
                         set as bandwidth per VPN service.";
                    }
                    type svc-id;
                    description
                      "Identifies the target VPN.  If the bandwidth
                       type is set as bandwidth per VPN service, the
                       vpn-id MUST be specified.";
                  }
                  leaf cir {
                    type uint64;
                    units "bps";
                    mandatory true;
                    description
                      "Committed Information Rate.  The maximum number
                       of bits that a port can receive or send over
                       an interface in one second.";
                  }
                  leaf cbs {
                    type uint64;
                    units "bps";
                    mandatory true;
                    description
                      "Committed Burst Size (CBS).  Controls the bursty
                       nature of the traffic.  Traffic that does not
                       use the configured Committed Information Rate
                       (CIR) accumulates credits until the credits
                       reach the configured CBS.";
                  }
                  leaf eir {
                    type uint64;
                    units "bps";
                    description
                      "Excess Information Rate (EIR), i.e., excess frame
                       delivery allowed that is not subject to an SLA.
                       The traffic rate can be limited by the EIR.";
                  }
                  leaf ebs {
                    type uint64;
                    units "bps";
                    description
                      "Excess Burst Size (EBS).  The bandwidth available
                       for burst traffic from the EBS is subject to the
                       amount of bandwidth that is accumulated during
                       periods when traffic allocated by the EIR
                       policy is not used.";
                  }
                  leaf pir {
                    type uint64;
                    units "bps";
                    description
                      "Peak Information Rate, i.e., maximum frame
                       delivery allowed.  It is equal to or less
                       than the sum of the CIR and the EIR.";
                  }
                  leaf pbs {
                    type uint64;
                    units "bps";
                    description
                      "Peak Burst Size.  It is measured in bytes per
                       second.";
                  }
                  description
                    "List of bandwidth values (e.g., per CoS,
                     per vpn-id).";
                }
                description
                  "From the customer site's perspective, the service
                   input/output bandwidth of the connection or
                   download/upload bandwidth from the SP/site
                   to the site/SP.";
              }
              leaf svc-mtu {
                type uint16;
                units "bytes";
                mandatory true;
                description
                  "SVC MTU.  It is also known as the maximum
                   transmission unit or maximum frame size.  When
                   a frame is larger than the MTU, it is broken
                   down, or fragmented, into smaller pieces by
                   the network protocol to accommodate the MTU
                   of the network.  If CsC is enabled,
                   the requested svc-mtu leaf will refer to the
                   MPLS MTU and not to the link MTU.";
              }
              uses site-service-qos-profile;
              uses site-service-mpls;
              description
                "Container for services.";
            }
            uses site-bum;
            uses site-mac-loop-prevention;
            uses site-acl;
            container mac-addr-limit {
              if-feature "mac-addr-limit";
              leaf limit-number {
                type uint16;
                default "2";
                description
                  "Maximum number of MAC addresses learned from
                   the subscriber for a single service instance.
                   The default allowed maximum number of MAC
                   addresses is 2.";
              }
              leaf time-interval {
                type uint32;
                units "seconds";
                default "300";
                description
                  "The aging time of the MAC address.  By default,
                   the aging time is set to 300 seconds.";
              }
              leaf action {
                type identityref {
                  base mac-action;
                }
                default "warning";
                description
                  "Specifies the action taken when the upper limit is
                   exceeded: drop the packet, flood the packet, or
                   simply send a warning log message.  By default,
                   the action is set to 'warning'.";
              }
              description
                "Container of MAC address limit configurations.";
            }
            description
              "List of site network accesses.";
          }
          description
            "Container of port configurations.";
        }
        description
          "List of sites.";
      }
      description
        "Container of site configurations.";
    }
    description
      "Container for L2VPN services.";
  }
}

<CODE ENDS>

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

Модуль YANG, заданный в этом документе, определяет схему данных, которые предназначены для доступа по протоколам сетевого управления, таким как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный транспорт, а обязательным для реализации транспортом — SSH1 [RFC6242]. Нижним уровнем протокола RESTCONF является HTTPS и обязательна реализация защищенного транспорта TLS [RFC8446].

Модель управления доступом NETCONF [RFC8341] обеспечивает способы ограничения доступа, разрешая его конкретным пользователям NETCONF или RESTCONF к заранее заданному набору всех доступных операций протокола NETCONF или RESTCONF, а также компонентам содержимого.

В этом модуле YANG определено множество узлов данных, которые разрешают запись/изменение/удаление (т. е. используют принятое по умолчанию значение config true). Эти узлы данных могут быть уязвимыми или конфиденциальными в некоторых средах. Операции записи (например, edit-config) в такие узлы без подобающей защиты могут оказывать негативное влияние на работу сети. Ниже перечислены такие субдеревья и узлы данных.

  • /l2vpn-svc/vpn-services/vpn-service

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

  • /l2vpn-svc/sites/site

    Записи этого списка включают конфигурации абонентского сайта. Неожиданные изменения этих записей могут вести к нарушению сервиса и/или недопустимому поведению сети.

Некоторые из доступных для чтения узлов данных в этом модуле YANG могут быть уязвимыми или конфиденциальными в отдельных сетевых средах. Важно контролировать доступ (например, get, get-config, notification) к таким узлам. Ниже перечислены такие субдеревья и узлы данных.

  • /l2vpn-svc/vpn-services/vpn-service

  • /l2vpn-svc/sites/site

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

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

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

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

Агентство IANA выделило новое значение URI в реестре «IETF XML Registry» [RFC3688].

      URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
      Registrant Contact: The IESG
      XML: N/A; the requested URI is an XML namespace

Агентство IANA выделило новое имя модуля YANG в реестре «YANG Module Names» [RFC6020].

      name: ietf-l2vpn-svc
      namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
      prefix: l2vpn-svc
      reference: RFC 8466

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC4364] Rosen, E. and Y. Rekhter, «BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., «Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling», RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, «Segmented Pseudowire», RFC 6073, DOI 10.17487/RFC6073, January 2011, <https://www.rfc-editor.org/info/rfc6073>.

[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, «Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)», RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., «Using the NETCONF Protocol over Secure Shell (SSH)», RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, «BGP MPLS-Based Ethernet VPN», RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, «Virtual Private Wire Service Support in Ethernet VPN», RFC 8214, DOI 10.17487/RFC8214, August 2017, <https://www.rfc-editor.org/info/rfc8214>.

[RFC8341] Bierman, A. and M. Bjorklund, «Network Configuration Access Control Model», STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «Network Management Datastore Architecture (NMDA)», RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8446] Rescorla, E., «The Transport Layer Security (TLS) Protocol Version 1.3», RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, «Extensible Markup Language (XML) 1.0 (Fifth Edition)», World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

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

[EVPN-YANG] Brissette, P., Ed., Shah, H., Ed., Chen, I., Ed., Hussain, I., Ed., Tiruveedhula, K., Ed., and J. Rabadan, Ed., «Yang Data Model for EVPN», Work in Progress, draft-ietf-bess-evpn-yang-052, February 2018.

[IEEE-802-1ag] IEEE, «802.1ag — 2007 — IEEE Standard for Local and Metropolitan Area Networks — Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management», DOI 10.1109/IEEESTD.2007.4431836.

[IEEE-802-1D] IEEE, «802.1D-2004 — IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges», DOI 10.1109/IEEESTD.2004.94569.

[IEEE-802-1Q] IEEE, «802.1Q — 2014 — IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks», DOI 10.1109/IEEESTD.2014.6991462.

[IEEE-802-3ah] IEEE, «802.3ah — 2004 — IEEE Standard for Information technology— Local and metropolitan area networks— Part 3: CSMA/CD Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks», DOI 10.1109/IEEESTD.2004.94617.

[ITU-T-Y-1731] International Telecommunication Union, «Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks», ITU-T Recommendation Y.1731, August 2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.

[MEF-6] Metro Ethernet Forum, «Ethernet Services Definitions — Phase 2», April 2008, <https://mef.net/PDF_Documents/technical-specifications/MEF6-1.pdf>.

[MPLS-L2VPN-YANG] Shah, H., Ed., Brissette, P., Ed., Chen, I., Ed., Hussain, I., Ed., Wen, B., Ed., and K. Tiruveedhula, Ed., «YANG Data Model for MPLS-based L2VPN», Work in Progress, draft-ietf-bess-l2vpn-yang-08, February 2018.

[RFC4119] Peterson, J., «A Presence-based GEOPRIV Location Object Format», RFC 4119, DOI 10.17487/RFC4119, December 2005, <https://www.rfc-editor.org/info/rfc4119>.

[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, «Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling», RFC 6624, DOI 10.17487/RFC6624, May 2012, <https://www.rfc-editor.org/info/rfc6624>.

[RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., Binderberger, M., Ed., and J. Haas, Ed., «Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces», RFC 7130, DOI 10.17487/RFC7130, February 2014, <https://www.rfc-editor.org/info/rfc7130>.

[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., Henderickx, W., and A. Isaac, «Requirements for Ethernet VPN (EVPN)», RFC 7209, DOI 10.17487/RFC7209, May 2014, <https://www.rfc-editor.org/info/rfc7209>.

[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, «Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks», RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.

[RFC7436] Shah, H., Rosen, E., Le Faucheur, F., and G. Heron, «IP-Only LAN Service (IPLS)», RFC 7436, DOI 10.17487/RFC7436, January 2015, <https://www.rfc-editor.org/info/rfc7436>.

[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, «YANG Module Classification», RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/info/rfc8199>.

[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, «YANG Data Model for L3VPN Service Delivery», RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.

[RFC8309] Wu, Q., Liu, W., and A. Farrel, «Service Models Explained», RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., «YANG Tree Diagrams», BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

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

Спасибо Qin Wu и Adrian Farrel за содействие в работе над предварительными версиями документа. Спасибо Zonghe Huang, Wei Deng и Xiaoling Song за рецензирование этого документа.

Отдельная благодарность Jan Lindblad за внимательное рецензирование YANG.

Этот документ основан на работе группы L3SM, представленной в [RFC8299].

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

Bin Wen

Comcast

Email: bin_wen@comcast.com

Giuseppe Fioccola (редактор)

Telecom Italia

Email: giuseppe.fioccola@tim.it

Chongfeng Xie

China Telecom

Email: xiechf.bri@chinatelecom.cn

Luay Jalil

Verizon

Email: luay.jalil@verizon.com

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

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

nmalykh@protocols.ru

1Secure Shell.

2Имеется следующая версия документа https://tools.ietf.org/html/draft-ietf-bess-evpn-yang-06. Прим. перев.




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

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




RFC 8423 Reclassification of Suite B Documents to Historic Status

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 8423                                Vigil Security
Category: Informational                                       L. Zieglar
ISSN: 2070-1721                                 National Security Agency
                                                               July 2018

Перевод документов Suite B в статус Historic

Reclassification of Suite B Documents to Historic Status

PDF

Тезисы

Этот документ переводит RFC, относящиеся к набору криптографических алгоритмов Suite B Агентства национальной безопасности США (NSA1), в статус устаревших (Historic) и рассматривает причины этого. Документ переводит в число устаревших информационные RFC 5759, 6239, 6318, 6379, 6380, 6403 и 6460. Кроме того, в статус Historic переводятся три отмененных (obsoleted) информационных RFC 4869, 5008 и 5430.

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

Документ не содержит спецификации Internet Standards Track и публикуется с информационными целями.

Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Не все документы, одобренные IESG, претендуют на статус стандартов Internet, как указано в разделе 2 в RFC 7841.

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

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

Авторские права (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. Введение

Несколько RFC задавали профили протоколов защиты для использования с криптографией АНБ Suite B. Алгоритмы Suite B больше не поддерживаются АНБ и web-страницы со спецификациями этих криптографических алгоритмов больше не доступны.

А июле 2015 года АНБ опубликовало Committee for National Security Systems Advisory Memorandum 02-15 в качестве первого шага по замене алгоритмов Suite B алгоритмами набора CNSA4. Информацию об этих алгоритмах можно найти в [CNSA].

2. Обоснование

Как указано в [CNSA], АНБ переходит с алгоритмов Suite B к алгоритмам CNSA. В результате профили протоколов защиты для алгоритмов Suite B в дальнейшем представляют лишь исторический интерес.

3. RFC, относящиеся к Suite B

В интервале с 2007 г. по 2012 г. было опубликовано несколько относящихся к Suite B документов RFCs с профилями протоколов защиты, использующих алгоритмы Suite B. Эти документы перечислены ниже.

  • [RFC4869], «Suite B Cryptographic Suites for IPsec» (отменен RFC 6379).

  • [RFC5008], «Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)» (отменен RFC 6318).

  • [RFC5430], «Suite B Profile for Transport Layer Security (TLS)» (отменен RFC 6460).

  • [RFC5759], «Suite B Certificate and Certificate Revocation List (CRL) Profile».

  • [RFC6239], «Suite B Cryptographic Suites for Secure Shell (SSH)».

  • [RFC6318], «Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)».

  • [RFC6379], «Suite B Cryptographic Suites for IPsec».

  • [RFC6380], «Suite B Profile for Internet Protocol Security (IPsec)».

  • [RFC6403], «Suite B Profile of Certificate Management over CMS».

  • [RFC6460], «Suite B Profile for Transport Layer Security (TLS)».

4. Документы, ссылающиеся на связанные с Suite B RFC

Эти RFC неоднократно ссылаются один на другой. Такие перекрестные ссылки далее в этом документе не рассматриваются.

В других RFC также имеются ссылки на связанные с Suite B RFC, эти ссылки рассматриваются в следующих параграфах.

4.1. Документы со ссылками на RFC 4869

В одном RFC имеется ссылка на RFC 4869 [RFC4869].

RFC 6071, «IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap» [RFC6071] указывает, что RFC 4869 добавляет 4 предопределенных шифра на основе спецификаций Suite B:

  • шифр IKE/ESP «Suite-B-GCM-128»;

  • шифр IKE/ESP «Suite-B-GCM-256»;

  • шифр IKE/ESP «Suite-B-GMAC-128»;

  • шифр IKE/ESP «Suite-B-GMAC-256».

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

4.2. Документы со ссылками на RFC 5759

В одном RFC имеется ссылка на RFC 5759 [RFC5759].

RFC 6187, «X.509v3 Certificates for Secure Shell Authentication» [RFC6187] указывает, что RFC 5759 содержит дополнительные рекомендации для использования ключей ECDSA5 с Suite B.

4.3. Документы со ссылками на RFC 6379

В одном RFC имеется ссылка на RFC 6379 [RFC6379].

RFC 7321, «Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)» [RFC7321] указывает, что алгоритм AES-GCM используется в Suite B и этот алгоритм стал предпочтительным методом аутентифицированного шифрования в IPsec. RFC 7321 был отменен RFC 8221.

4.4. Документы со ссылками на RFC 6403

В двух RFC имеются ссылки на RFC 6403 [RFC6403].

RFC 6402, «Certificate Management over CMS (CMC) Updates» [RFC6402] указывает, что разработка профиля для Suite B показала необходимость внесенных этим документом обновлений.

RFC 7030, «Enrollment over Secure Transport» [RFC7030] указывает, что сценарии из Приложения к RFC 6403 очень похожи на три описанных сценария.

4.5. Документы со ссылками на RFC 6460

В двух RFC имеются ссылки на RFC 6460 [RFC6460].

RFC 6605, «Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC» [RFC6605] заявляет о копировании части материала из RFC 6460. Статус Standards Track для RFC 6605 не меняется в результате перевода RFC 6460 в состояние Historic.

RFC 7525, «Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)» [RFC7525] отмечает, что профиль Suite B для TLS 1.2 использует разные шифронаборы.

RFC 8253, «PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)» [RFC8253] указывает на RFC 6460 для шифронаборов TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 и TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. Оба эти шифронабора определены в [RFC5289], на который было бы лучше сослаться. Статус Standards Track для RFC 8253 не меняется в результате перевода RFC 6460 в состояние Historic.

5. Влияние перевода связанных с Suite B RFC в статус Historic

Не возникает каких-либо проблем взаимодействия или безопасности в результате перевода связанных с Suite B RFC в статус Historic. Как указано в разделе 4, ни один из переведенных в число устаревших RFC не содержит явной спецификации криптографического алгоритма или идентификатора криптоалгоритма.

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

Документ не требует действий со стороны IANA.

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

Не возникает каких-либо проблем взаимодействия или безопасности в результате перевода связанных с Suite B RFC в статус Historic.

АНБ отказывается от некоторых криптографических алгоритмов и размеров ключей, которые были использованы в профилях Suite B.

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

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

[RFC4869] Law, L. and J. Solinas, «Suite B Cryptographic Suites for IPsec», RFC 4869, DOI 10.17487/RFC4869, May 2007, <https://www.rfc-editor.org/info/rfc4869>.

[RFC5008] Housley, R. and J. Solinas, «Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)», RFC 5008, DOI 10.17487/RFC5008, September 2007, <https://www.rfc-editor.org/info/rfc5008>.

[RFC5430] Salter, M., Rescorla, E., and R. Housley, «Suite B Profile for Transport Layer Security (TLS)», RFC 5430, DOI 10.17487/RFC5430, March 2009, <https://www.rfc-editor.org/info/rfc5430>.

[RFC5759] Solinas, J. and L. Zieglar, «Suite B Certificate and Certificate Revocation List (CRL) Profile», RFC 5759, DOI 10.17487/RFC5759, January 2010, <https://www.rfc-editor.org/info/rfc5759>.

[RFC6239] Igoe, K., «Suite B Cryptographic Suites for Secure Shell (SSH)», RFC 6239, DOI 10.17487/RFC6239, May 2011, <https://www.rfc-editor.org/info/rfc6239>.

[RFC6318] Housley, R. and J. Solinas, «Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)», RFC 6318, DOI 10.17487/RFC6318, June 2011, <https://www.rfc-editor.org/info/rfc6318>.

[RFC6379] Law, L. and J. Solinas, «Suite B Cryptographic Suites for IPsec», RFC 6379, DOI 10.17487/RFC6379, October 2011, <https://www.rfc-editor.org/info/rfc6379>.

[RFC6380] Burgin, K. and M. Peck, «Suite B Profile for Internet Protocol Security (IPsec)», RFC 6380, DOI 10.17487/RFC6380, October 2011, <https://www.rfc-editor.org/info/rfc6380>.

[RFC6403] Zieglar, L., Turner, S., and M. Peck, «Suite B Profile of Certificate Management over CMS», RFC 6403, DOI 10.17487/RFC6403, November 2011, <https://www.rfc-editor.org/info/rfc6403>.

[RFC6460] Salter, M. and R. Housley, «Suite B Profile for Transport Layer Security (TLS)», RFC 6460, DOI 10.17487/RFC6460, January 2012, <https://www.rfc-editor.org/info/rfc6460>.

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

[CNSA] National Security Agency, «Commercial National Security Algorithm Suite», August 2015, <https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm>.

[RFC5289] Rescorla, E., «TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)», RFC 5289, DOI 10.17487/RFC5289, August 2008, <https://www.rfc-editor.org/info/rfc5289>.

[RFC6071] Frankel, S. and S. Krishnan, «IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap», RFC 6071, DOI 10.17487/RFC6071, February 2011, <https://www.rfc-editor.org/info/rfc6071>.

[RFC6187] Igoe, K. and D. Stebila, «X.509v3 Certificates for Secure Shell Authentication», RFC 6187, DOI 10.17487/RFC6187, March 2011, <https://www.rfc-editor.org/info/rfc6187>.

[RFC6402] Schaad, J., «Certificate Management over CMS (CMC) Updates», RFC 6402, DOI 10.17487/RFC6402, November 2011, <https://www.rfc-editor.org/info/rfc6402>.

[RFC6605] Hoffman, P. and W. Wijngaards, «Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC», RFC 6605, DOI 10.17487/RFC6605, April 2012, <https://www.rfc-editor.org/info/rfc6605>.

[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., «Enrollment over Secure Transport», RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.

[RFC7321] McGrew, D. and P. Hoffman, «Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)», RFC 7321, DOI 10.17487/RFC7321, August 2014, <https://www.rfc-editor.org/info/rfc7321>.

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, «Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)», BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.

[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, «PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)», RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.

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

Russ Housley

Vigil Security, LLC

918 Spring Knoll Drive

Herndon, VA 20170

United States of America

Email: housley@vigilsec.com

Lydia Zieglar

National Security Agency

9800 Savage Road

Ft. George G. Meade, MD 20755-6940

United States of America

Email: llziegl@nsa.gov


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

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

nmalykh@gmail.com

1United States National Security Agency.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Commercial National Security Algorithm — коммерческий алгоритм национальной безопасности.

5Elliptic Curve Digital Signature Algorithm — алгоритм цифровой подписи на основе эллиптической кривой.




RFC 8402 Segment Routing Architecture

Internet Engineering Task Force (IETF)                  C. Filsfils, Ed.
Request for Comments: 8402                               S. Previdi, Ed.
Category: Standards Track                                    L. Ginsberg
ISSN: 2070-1721                                      Cisco Systems, Inc.
                                                             B. Decraene
                                                            S. Litkowski
                                                                  Orange
                                                               R. Shakir
                                                            Google, Inc.
                                                               July 2018

Архитектура маршрутизации по сегментам

Segment Routing Architecture

PDF

Тезисы

Маршрутизация по сегментам (SR1) использует парадигму маршрутизации, заданной отправителем (source routing). Узел направляет пакет с помощью упорядоченного списка инструкций, называемых сегментами. Сегмент может представлять инструкцию, основанная на топологии или услугах. Семантика сегмента может быть локальной для узла SR или глобальной в рамках домена SR. Маршрутизация по сегментам обеспечивает механизм, который позволяет ограничивать потоки конкретным топологическим путем при поддержке состояний на уровне потока лишь на входных узлах домена SR.

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

SR можно использовать с архитектурой IPv6 с новым типом заголовка маршрутизации. Сегмент представляется в виде адреса IPv6, а упорядоченный список сегментов — в виде упорядоченного списка адресов IPv6 в заголовке маршрутизации. Активный сегмент указывается адресом получателя (DA2) пакета. Следующий активный сегмент задается указателем в новом заголовке маршрутизации.

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

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

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

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

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

Авторские права (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. Введение

Маршрутизация по сегментам (SR) использует парадигму маршрутизации, заданной отправителем (source routing). Узел направляет пакет с помощью упорядоченного списка инструкций, называемых сегментами. Сегмент может представлять инструкцию, основанная на топологии или услугах. Семантика сегмента может быть локальной для узла SR или глобальной в рамках домена SR. Маршрутизация по сегментам обеспечивает механизм, который позволяет ограничивать потоки конкретным топологическим путем при поддержке состояний на уровне потока лишь на входных узлах домена SR.

Сегменты часто указывают их идентификаторами SID5.

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

Сегмент может быть связан с сервисной инструкцией (например, пакет следует обрабатывать в контейнере или виртуальной машине (VM6), связанной с сегментом). Сегмент может быть связан с трактовкой QoS (например, предоставление для пакетов данного сегмента пропускной способности x Мбит/с).

Архитектура SR поддерживает любые типы связанных с сегментами инструкций.

Архитектура SR поддерживает любой тип уровня управления — распределенный, централизованный или гибридный.

В распределенном варианте выделение сегментов и сигнализация обеспечиваются протоколом IS-IS, OSPF или BGP. Узел сам решает вопрос направления пакетов в SR Policy (например, заранее рассчитанная локальная защита [RFC8355]). Узел индивидуально рассчитывает SR Policy.

В централизованном варианте сегменты выделяются и создаются контроллером SR. Контроллер SR решает, какие узлы должны направлять пакеты в соответствии с правилами заданной отправителем маршрутизации. Контроллер SR рассчитывает правила заданной отправителем маршрутизации. Архитектура SR не ограничивает способы программирования сети контроллером. Возможными вариантами такого программирования являются протоколы NETCONF7, PCEP8 и BGP. Архитектура SR не ограничивает число контроллеров SR. В частности, может применяться множество контроллеров для программирования одного домена SR. Архитектура SR позволяет этим контроллерам обнаруживать экземпляры SID и определять узлы, где они созданы, а также определять доступность на узлах локальных (SRLB) и глобальных (SRGB) меток.

В гибридном варианте базовый распределенный уровень управления дополняется центральным контроллером. Например, при размещении адресата за пределами домена IGP контроллер SR может рассчитать SR Policy от имени узла IGP. Архитектура SR не ограничивает способы взаимодействия узлов, участвующих в управлении, с контроллером SR. Возможными вариантами являются протоколы PCEP и BGP.

Хосты могут быть частью домена SR. Центральный контроллер может информировать хосты о правилах путем их выталкивания на хосты (pushing) или путем ответов на запросы хостов.

Экземпляры архитектуры SR могут создаваться для различных уровней данных. В этом документе рассматриваются два таких экземпляра — SR для MPLS (SR-MPLS) и SR для IPv6 (SRv6).

SR можно применять непосредственно к архитектуре MPLS без изменения уровня пересылки [SR-MPLS]. Сегменты представляются в виде меток MPLS. Экземпляры SR Policy создаются в форме стека меток. Обрабатываемым (активным) сегментом является сегмент на вершине стека. По завершению обработки сегмента соответствующая метка выталкивается из стека.

SR можно применять в архитектуре IPv6 с использованием нового типа заголовков маршрутизации, называемого заголовком SR (SRH9) [IPv6-SRH]. Связанная с сегментом инструкция представляется в виде адреса IPv6. Сегменты SRv6 называют также SRv6 SID. Экземпляр SR Policy создается в форме упорядоченного списка SRv6 SID в заголовке маршрутизации. Активный сегмент указывается адресом получателя (DA) в пакете. Следующий активный сегмент задается указателем SegmentsLeft (SL) в SRH. По завершении обработки SRv6 SID значение SL декрементируется и в DA копируется следующий сегмент. Когда пакет направляется SR Policy, в него добавляется соответствующий заголовок SRH.

В контексте распределенного уровня управления на базе IGP определяется два топологических сегмента — IGP-Adjacency и IGP-Prefix.

В контексте распределенного уровня управления на базе BGP определяется два топологических сегмента — BGP peering и BGP-Prefix.

Головная точка (headend) SR Policy связывает SID (сегмент Binding или BSID) со своей политикой. Когда головная точка получает пакет, активный сегмент которого соответствуют BSID локальной политики SR, она направляет пакет в SR Policy.

Этот документ определяет сегменты IGP, BGP и Binding для уровней данных SR-MPLS и SRv6.

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

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

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

SR-MPLS

Экземпляр SR для уровня данных MPLS.

SRv6

Экземпляр SR для уровня данных IPv6.

Segment — сегмент

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

SID

Идентификатор сегмента. Отметим, что термин SID часто используется вместо термина «сегмент», хотя технически это не совсем точно.

SR-MPLS SID

Метка MPLS или значение индекса в пространстве меток MPLS, явно связанные с сегментом.

SRv6 SID

Адрес IPv6, явно связанный с сегментом.

Segment Routing domain (SR domain) – домен SR

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

Active Segment – активный сегмент

Сегмент, используемый принимающим маршрутизатором для обработки пакета. Для MPLS это верхняя метка в стеке, для IPv6 — адрес получателя [IPv6-SRH].

PUSH — вталкивание

Операция вставки сегмента на вершину списка сегментов. Для SR-MPLS вершиной списка является верхняя (внешняя) метка в стеке. Для SRv6 вершина списка сегментов представлена первым сегментом в заголовке SRH, как определено в [IPv6-SRH].

NEXT – следующий сегмент

При завершении обработки активного сегмента NEXT является операцией проверки следующего сегмента, который становится активным. В SR-MPLS операция NEXT реализуется выталкиванием (POP) верхней метки, в SRv6 — копированием следующего сегмента из SRH в поле адреса получателя заголовка IPv6.

CONTINUE – продолжение сегмента

Активный сегмент не завершен, поэтому он остается активным. В SR-MPLS операция CONTINUE реализуется заменой (SWAP) верхней метки [RFC3031], в SRv6 это обычная операция пересылки IPv6 в соответствии с адресом получателя IPv6.

SR Global Block (SRGB) – глобальный блок SR

Набор глобальных сегментов в домене SR. Если узел участвует в нескольких доменах SR, для каждого из них будет присутствовать блок SRGB. В SR-MPLS блок SRGB является локальным свойством узла и указывает множество локальных меток, зарезервированных для глобальных сегментов. В SR-MPLS настоятельно рекомендуется использовать одинаковые блоки SRGB на всех узлах домена SR. Это упрощает работу и поиск неисправностей, поскольку на каждом узле одна и та же метка будет представлять один и тот же сегмент. В SRv6 блок SRGB представляет собой набор глобальных SRv6 SID в домене SR.

SR Local Block (SRLB) – локальный болк SR

Локальное свойство узла SR. Если узел участвует в нескольких доменах SR, используется один блок SRLB для каждого домена SR. В SR-MPLS блок SRLB представляет собой набор локальных меток, зарезервированных для локальных сегментов. В SRv6 блок SRLB представляет собой набор локальных адресов IPv6, зарезервированных для локальных SRv6 SID. В управляемой контроллерами сети некоторые контроллеры или приложения могут использовать уровень управления для определения доступного набора локальных сегментов.

Global Segment – глобальный сегмент

Сегмент, являющийся частью SRGB домена. Связанная с сегментом инструкция определяется на уровне домена SR. Типичным примером глобального сегмента является топологический кратчайший путь к данному адресату внутри домена SR.

Local Segment – локальный сегмент

В SR-MPLS это локальная метка вне SRGB. Это может быть часть явно анонсируемого SRLB. В SRv6 это может быть любой адрес IPv6 (т. е. адрес может быть частью SRGB, но используется так, что его значимость локальна). Инструкция, связанная с сегментом, определяется на уровне узла.

IGP Segment – сегмент IGP

Базовое имя для сегмента, присоединенного к части информации, анонсируемой link-state IGP (например, префикс или смежность IGP).

IGP-Prefix Segment – сегмент IGP-Prefix

Сегмент IGP-Prefix является сегментом IGP, представляющим префикс IGP. Когда сегмент IGP-Prefix является глобальным в рамках экземпляра или топологии SR IGP, он определяет инструкцию для пересылки пакета по пути, рассчитанному с использованием алгоритма маршрутизации, заданного в поле algorithm, для топологии и экземпляра IGP, где этот сегмент анонсируется. Используется также термин prefix segment (сегмент префикса).

Prefix-SID

Идентификатор SID для сегмента IGP-Prefix.

IGP-Anycast Segment — сегмент IGP-Anycast

Сегмент IGP-Anycast является сегментом IGP-Prefix, который указывает префикс anycast, анонсируемый набором маршрутизаторов.

Anycast-SID

Идентификатор SID для сегмента IGP-Anycast.

IGP-Adjacency Segment – сегмент IGP-Adjacency

Сегмент IGP-Adjacency является сегментом IGP, присоединенным к однонаправленной смежности или набору таких смежностей. По умолчанию сегмент IGP-Adjacency является локальным (если явно не анонсируется иное) для анонсирующего его узла. Называется также Adj-SID.

Adj-SID

Идентификатор SID для сегмента IGP-Adjacency.

IGP-Node Segment – сегмент IGP-Node

Сегмент IGP-Node является сегментом IGP-Prefix, который указывает конкретный маршрутизатор (например, loopback). Называется также Node Segment 9сегмент узла).

Node-SID

Идентификатор SID для сегмента IGP-Node.

SR Policy – правила (политика) SR

Упорядоченный список сегментов. Головная точка SR Policy направляет пакеты в SR Policy. Список сегментов может быть задан явно в SR-MPLS как стек меток и в SRv6 как упорядоченный список SRv6 SID. Кроме того, список сегментов рассчитывается на основе адресата и набора параметров оптимизации и ограничений (например, задержка, сродство, SRLG и т. п.). Расчет может выполняться локально или передаваться серверу PCE. SR Policy может настраиваться оператором, а также обеспечиваться протоколом NETCONF [RFC6241] или PCEP [RFC5440]. Политика SR может применяться для организации трафика (TE10), решения задач OAM11 или быстрой смены маршрутов (FRR12).

Segment List Depth – размер списка сегментов

Число сегментов в SR Policy. Объект, создающий экземпляр SR Policy на узле N, должен быть способен определить возможности sdepth-insertion для узла N. Например, анонсирование свойства PCEP SR, описанное в [PCEP-SR-EXT], является одним из способов обнаружения возможности.

Forwarding Information Base (FIB) – база данных о пересылке

Таблица пересылки узла.

3. Сегменты Link-State IGP

В домене SR узел IGP с поддержкой SR анонсирует сегменты для своих подключенных префиксов и смежностей (соседств). Эти сегменты называют сегментами IGP или IGP SID. Они играют важную роль в SR и позволяют выразить любой путь через домен SR. Такой путь выражается одним сегментом IGP или списком из множества сегментов IGP.

Для анонсирования сегментов IGP требуется расширение протоколов IGP, основанных на состоянии каналов. Эти расширения определены в [ISIS-SR-EXT], [OSPF-SR-EXT] и [OSPFv3-SR-EXT].

3.1. Сегмент IGP-Prefix (Prefix-SID)

Сегмент IGP-Prefix является сегментом IGP, присоединенным к префиксу IGP. Сегмент IGP-Prefix является глобальным (если явно не указано иное) в домене SR. Контекст сегмента IGP-Prefix включает префикс, топологию и алгоритм. Может быть выделено множество SID для одного префикса, пока триплеты <prefix, topology, algorithm> являются уникальными.

Множество экземпляров и топологий определены для IS-IS и OSPF в [RFC5120], [RFC8202], [RFC6549] и [RFC4915].

3.1.1. Алгоритм Prefix-SID

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

Данный документ определяет два алгоритма.

  • По кратчайшему пути (SPF13). Этот алгоритм используется по умолчанию. Пакет пересылается с использованием общепринятого алгоритма SPF, знающего о ECMP14, который реализуется протоколами IGP. Однако промежуточным точкам явно разрешено применять другие алгоритмы пересылки в соответствии с локальной политикой. Алгоритм SPF фактический является используемым по умолчанию в большинстве современных сетей, где локальные правила могут переопределять решение SPF.

  • Строго по кратчайшему пути (Strict-SPF). Этот алгоритм требует пересылать пакет в соответствии с алгоритмом SPF, знающим о ECMP, и инструктирует все маршрутизаторы на пути игнорировать любые локальные правила, переопределяющие решение SPF. Идентификатор SID, анонсируемый с алгоритмом Strict-SPF, обеспечивает неизменность пути SPF, по которому пересылается пакет. Отметим, что механизмы быстройсмены маршрутов (FRR) [RFC5714] совместимы с этим алгоритмом. Иными словами, пакет, полученный с Strict-SPF SID, может быть перемаршрутизирован механизмом FRR. Strict-SPF использует такую же топологию, как алгоритм SPF. Обычно узлы, не поддерживающие Strict-SPF, не будут создавать записей пересылки для этого алгоритма. Ограничение топологии лишь узлами, поддерживающими этот алгоритм, не создает желаемых путей пересылки, поскольку желаемое поведение состоит в следовании маршрутам, рассчитанным по алгоритму SPF. Поэтому исходному узлу SR недопустимо использовать SR Policy с сегментом Strict-SPF, если путь проходит через узлы, не поддерживающие алгоритм Strict-SPF.

Сегмент IGP-Prefix указывает путь к соответствующему префиксу, рассчитанный с использованием привязанного алгоритма. Предполагается, что пакет внесенный где-либо внутри домена SR с активным Prefix-SID, будет пересылаться по пути, рассчитанному с использованием указанного алгоритма. Для этого требуется полносвязная топология маршрутизаторов, поддерживающих этот алгоритм.

3.1.2. SR-MPLS

Когда SR используется с уровнем данных MPLS, идентификаторы SID являются метками MPLS или индексами в пространстве меток MPLS (SRGB или SRLB).

По возможности рекомендуется настраивать идентичные блоки SRGB на всех узлах домена SR. Это упрощает поиск неисправностей, поскольку с одним префиксом связывается одна и та же метка на всех узлах. Кроме того, это упрощает поддержку адресации anycast, как описано в параграфе 3.3.

Ниже перечислены аспекты поведения, связанные с SR на основе уровня данных MPLS.

  • Расширение сигнализации IGP для сегмента IGP-Prefix включает флаг для указания непосредственно подключенным соседям операции NEXT или CONTINUE при обработке SID. Это поведение эквивалентно Penultimate Hop Popping (NEXT) или Ultimate Hop Popping (CONTINUE) в MPLS.

  • Prefix-SID выделяется в форме метки MPLS (или индекса в SRGB), подобно выделению адреса IP. Обычно выделение Prefix-SID происходит в соответствии с политикой оператора или NMS15 и значение SID меняется очень редко.

  • Хотя SR позволяет привязать к перфиксу IGP локальный сегмент, термины «сегмент IGP-Prefix» и Prefix-SID предполагают глобальный сегмент (т. е. SID определяется из анонсируемого SRGB). Это согласуется со всеми описанными примерами использования, которые требуют привязки к префиксам IGP глобальных сегментов.

  • Процессу выделения недопустимо назначать один идентификатор Prefix-SID для разных префиксов.

  • Если узел узнает Prefix-SID со значением, выходящим за пределы локально настроенного диапазона SRGB, этому узлу недопустимо использовать Prefix-SID и следует внести в журнал запись об ошибке в конфигурации.

  • Если узел N анонсирует Prefix-SID SID-R для префикса R, который присоединен к N, и задает операцию CONTINUE для выполнения подключенными напрямую соседями, узел N должен поддерживать показанную ниже запись в FIB.

    Входящий активный сегмент: SID-R

    Входящая операция: NEXT

    Выходной интерфейс: NULL

  • Удаленный узел M должен поддерживать приведенную ниже запись FIB для любого узнанного Prefix-SID SID-R, присоединенного к R.

    Входящий активный сегмент: SID-R

    Входящая операция: Если next-hop префикса R является источником (originator) R, а M дана инструкция удалить активный сегмент, выполняется операция NEXT. В противном случае выполняется CONTINUE.

    Выходной интерфейс: Интерфейс(ы) в направлении next-hop по пути, рассчитанному с использованием алгоритма, анонсированного с SID в направлении префикса R.

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

3.1.3. SRv6

При использовании SR с уровнем данных IPv6:

  • Prefix-SID является адресом IPv6:

  • оператор должен явно создать экземпляр SRv6 SID. Адреса IPv6 по умолчанию не являются SRv6 SID.

Узел N, анонсирующий адрес IPv6 R, подходящий в качестве идентификатора сегмента, должен поддерживать приведенную ниже запись FIB.

Входящий активный сегмент: R

Входящая операция: NEXT

Выходной интерфейс: NULL

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

Независимо от поддержки SR любой удаленный узел IPv6 будет поддерживать обычную (plain) запись IPv6 FIB для любого префикса представляющего или не представляющего сегмент. Это позволяет пересылать пакеты узлу, владеющему SID, даже узлам, не поддерживающим SR.

Для SRv6 возможна поддержка множества алгоритмов. Поскольку связанные с алгоритмами SID являются просто адресами IPv6, связанные с алгоритмом записи пересылки могут быть получены путем выделение узлом связанных с алгоритмом подсетей, к которым относятся связанные с алгоритмами SID.

Не поддерживающие алгоритм узлы могут по-прежнему иметь записи FIB, включающие относящийся к алгоритму адрес, даже в тех случаях, когда данный узел не рассчитывает связанного с алгоритмом пути. Это смягчается тем, что не поддерживающие данный алгоритм узлы не будут включаться в топологию, связанную со специфичным для алгоритма SPF. Поэтому трафик для связанных с алгоритмом адресатов обычно не будет проходить через исключенный узел. Если такой трафик будет приходить на узел и пересылаться им, он будет по-прежнему продвигаться в направлении адресата. Значение next-hop будет указывать поддерживающий алгоритм узел (в этом случае пакеты будут пересылаться по связанным с алгоритмом путям или обрасываться при отсутствии таких путей) или узел который не поддерживает данный алгоритм (в этом случае пакеты будут пересылаться по путям Algorithm 0 в направлении адресата).

3.2. Сегмент IGP-Node (Node-SID)

Сегмент IGP Node-SID недопустимо связывать с префиксом, которым владеет несколько маршрутизаторов в одном домене маршрутизации.

3.3. Сегмент IGP-Anycast (Anycast-SID)

Сегмент Anycast или Anycast-SID форсирует осведомленную об ECMP пересылку в направлении ближайшего узла набора anycast. Это полезно при создании правил организации трафика на макроуровне и механизмов защиты.

Сегментам IGP-Anycast недопустимо указывать на конкретный узел.

Внутри группы anycast все маршрутизаторы домена SR должны анонсировать для одного SID один и тот же префикс.

3.3.1. Anycast-SID в SR-MPLS

                        +--------------+
                        |   Group A    |
                        |192.0.2.10/32 |
                        |    SID:100   |
                        |              |
                 +-----------A1---A3----------+
                 |      |    | \ / |   |      |
      SID:10     |      |    |  /  |   |      |     SID:30
203.0.113.1/32   |      |    | / \ |   |      |  203.0.113.3/32
       PE1------R1----------A2---A4---------R3------PE3
          \     /|      |              |      |\     /
           \   / |      +--------------+      | \   /
            \ /  |                            |  \ /
             /   |                            |   /
            / \  |                            |  / \
           /   \ |      +--------------+      | /   \
          /     \|      |              |      |/     \
        PE2------R2----------B1---B3---------R4------PE4
203.0.113.2/32   |      |    | \ / |   |      | 203.0.113.4/32
      SID:20     |      |    |  /  |   |      |     SID:40
                 |      |    | / \ |   |      |
                 +-----------B2---B4----------+
                        |              |
                        |   Group B    |
                        | 192.0.2.1/32 |
                        |    SID:200   |
                        +--------------+

Рисунок 1. Группы транзитных устройств.


На рисунке 1 показан пример сети с двумя группами транзитных устройств. Группа A включает устройства {A1, A2, A3 и A4}. Для всех этих устройств используется anycast-адрес 192.0.2.10/32 и Anycast-SID 100.

Группа B включает устройства {B1, B2, B3 и B4} с anycast-адресом 192.0.2.1/32 и Anycast-SID 200. В этой топологии каждое краевое устройство PE (Provide Edge) имеет путь в группы A и B.

PE1 может выбрать конкретную группу транзитных устройств для передачи трафика из PE3 или PE4. Это будет выполняться путем вталкивания Anycast-SID выбранной группы в стек.

Обработка anycast и последующих сегментов требует особой осторожности.

                   +-------------------------+
                   |       Group A           |
                   |     192.0.2.10/32       |
                   |        SID:100          |
                   |-------------------------|
                   |                         |
                   |   SRGB:         SRGB:   |
SID:10             |(1000-2000)   (3000-4000)|             SID:30
  PE1---+       +-------A1-------------A3-------+       +---PE3
         \     /   |    | \           / |    |   \     /
          \   /    |    |  +-----+   /  |    |    \   /
   SRGB:   \ /     |    |         \ /   |    |     \ /   SRGB:
(7000-8000) R1     |    |          \    |    |      R3 (6000-7000)
           / \     |    |         / \   |    |     / \
          /   \    |    |  +-----+   \  |    |    /   \
         /     \   |    | /           \ |    |   /     \
  PE2---+       +-------A2-------------A4-------+       +---PE4
SID:20             |   SRGB:         SRGB:   |             SID:40
                   |(2000-3000)   (4000-5000)|
                   |                         |
                   +-------------------------+

Рисунок 2. Транзитные пути через Anycast Group A.


Для случая MPLS в показанной выше топологии при необходимости передачи пакета от устройства PE1 (или PE2) устройству PE3 (или PE4) потребуется инкапсулировать пакет в данные (payload) MPLS с показанным ниже стеком меток.

  • Метка, выделенная R1 для Anycast-SID 100 (внешняя).

  • Метка, выделенная ближайшим маршрутизатором группы A для SID 30 (для получателя PE3).

В этом случае первую метку легко рассчитать. Однако по причине наличия в этой топологии более одного ближайшего устройства (A1 и A2) определение второй метки невозможно, если A1 и A2 не выделят одно и то же значение метки для одного префикса. Устройства A1 и A2 могут быть выпущены разными производителями. Если оба устройства не выделят одинаковые метки для SID 30, будет невозможно использовать anycast Group A в качестве транзитной anycast-группы в направлении PE3. Поэтому PE1 (или PE2) не сможет рассчитать подходящий стек меток для того, чтобы явно направить пакет через устройства группы A. То же самое будет происходить для устройств PE3 и PE4 при попытке передать пакет из PE1 или PE2.

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

Использование сегмента anycast без настройки одинаковых SRGB на всех узлах anycast-группы может приводить к ошибкам в маршрутизации (в среде MPLS VPN может возникать утечка трафика между VPN).

3.4. Сегмент IGP-Adjacency (Adj-SID)

Смежность формируется между локальным (т. е. анонсирующим отношения смежности в IGP) и удаленным (т. е. другой стороной отношений смежности) узлами. Локальный узел должен быть узлом IGP. Удаленный узел может быть смежным соседом IGP или несмежным соседом (например, смежность по пересылке [RFC4206]).

Пакет, инжектируемый в любой точке домена SR со списком сегментов {SN, SNL}, где SN — Node-SID узла N, SNL — Adj-SID, привязанный к N смежностью по каналу L, будет пересылаться по кратчайшему пути к N, а затем будет коммутироваться узлом N без учета кратчайшего пути IP в направлении канала L. Если Adj-SID указывает множество смежностей, узел N будут распределять трафик между элементами множества.

Аналогично при использовании глобального Adj-SID пакет, инжектированный в домен SR со списком сегментов {SNL}, где SNL -глобальный идентификатор Adj-SID, связанный узлом N со смежностью по каналу L, будет пересылаться по кратчайшему пути к N, а затем коммутироваться узлом N без учета кратчайшего пути IP в направлении канала L. Если Adj-SID указывает множество смежностей, узел N будут распределять трафик между элементами множества. Использование глобального Adj-SID позволяет уменьшить размер списка сегментов при выражении пути за счет дополнительного состояния (т. е. глобальный Adj-SID будет вставляться всеми маршрутизаторами области в их таблицы пересылки).

Сегмент IGP-Adjacency или Adj-SID форсирует коммутацию пакета от узла в направлении определенного интерфейса или набора интерфейсов. Это служит ключом к теоретическому доказательству того, что любой путь можно выразить в форме списка сегментов.

Представление Adj-SID включает набор флагов, поддерживаемых приведенную ниже функциональность.

  • Право на защиту (например, с помощью IPFRR или MPLS-FRR). Защита позволяет в случае отказа интерфейсов, связанных с Adj-SID, пересылать пакеты по другому пути. Использование защиты безусловно определяется политикой, т. е. может быть или не быть желательным.

  • Индикация локального или глобального действия Adj-SID. По умолчанию следует использовать локальную область действия.

  • Индикация сохранения Adj-SID при перезапуске уровня управления. Сохранение является ключевым атрибутом, предотвращающим SR Policy от временной некорректности пересылки в результате повторного выделения Adj-SID.

Вес (как описано ниже) также связывается с анонсом Adj-SID.

Узлу следует выделять один идентификатор Adj-SID для каждой из своих смежностей.

Узел может выделять множество Adj-SID для одной смежности. Примером является поддержка Adj-SID с желательной и нежелательной защитой.

Узел может связать одие идентификатор Adj-SID со множеством смежносетй.

Для обеспечения возможности анонсировать в IGP все идентификаторы Adj-SID, представляющие отношения смежности IGP между парой узлов, недопустимо подавление параллельных смежностей протоколом IGP.

Когда узел связывает Adj-SID V с локальным каналом данных L, он должен установить в FIB приведенную ниже запись.

Входящий активный сегмент: V

Входящая операция: NEXT

Выходной интерфейс: L

Adj-SID предполагает пересылку пакетов через указанные Adj-SID смежности от анонсирующего Adj-SID маршрутизатора независимо от стоимости IGP/SPF. Инями словами, использование сегментов смжности переопределяет решение о маршрутизации, принятое алгоритмом SPF.

3.4.1. Параллельные смежности

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

Узел должен создать запись FIB для любого локально инициированного Adj-SID со значением W, связанного с набором каналов B.

Входящий активный сегмент: W

Входящая операция: NEXT

Выходные интерфейсы: балансировка трафика между каналами данных набора B.

Когда параллельные смежности применяются и связаны с одним Adj-SID для оптимизации функции распределения нагрузки можно связать весовой коэффициент с идентификатором Adj-SID, анонсируемым для каждой смежности. Вес указывает вход (или систему SDN/оркестроки) коэффициента загрузки для параллельных смежностей. Как показано на рисунке 3, A и B соединены двумя параллельными отношениями смежности.

      Link-1
    +--------+
    |        |
S---A        B---C
    |        |
    +--------+
      Link-2

Рисунок 3. Параллельные каналы и Adj-SID.


Ужел A анонсирует Adj-SID и весовые коэффициенты

  • Link-1: Adj-SID 1000, weight: 1

  • Link-2: Adj-SID 1000, weight: 2

Узел S получает анонсы параллельных смежностей и понимает, что путем использования Adj-SID 1000 узла A будет распределять трафик между параллельными каналами (Link-1 и Link-2) в отношении 1:2 (т. е. через Link-2 будет передаваться вдвое больше пакетов по сравнению с Link-1).

3.4.2. Сегменты смежности ЛВС

В подсетях ЛВС протоколы link-state определяют концепцию назначенного маршрутизатора (DR16 в OSPF) или назначенной промежуточной системы (DIS17 в IS-IS), которые передают лавинные рассылки в широковещательных подсетях и описывают топологию ЛВС в специальных маршрутных обновлениях (OSPF Type2 LSA или IS-IS Pseudonode LSP).

Сложность заключается в том, что каждый маршрутизатор анонсирует лишь свою связность с DR/DIS, а не каждого отдельного узла в ЛВС. Поэтому нужны дополнительные механизмы протоколов (IS-IS и OSPF) для того. Чтобы каждый маршрутизатор в ЛВС анонсировал Adj-SID, связанный с каждым соседом в LAN.

3.5. Взаимодействия между областями

В приведенном ниже примере предполагается, что все области (area) являются частями одного домена SR.

На рисунке 4 предполагается уровень управления IPv6 и уровень данных MPLS.

               !          !
               !          !
        B------C-----F----G-----K
       /       |          |     |
 S---A/        |          |     |
      \        |          |     |
       \D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150)
               !          !
       Area 1  ! Backbone ! Area 2
               !   area   !

Рисунок 4. Пример топологии Inter-Area.


В области 2 узел Z выделяет Node-SID 150 для своего локального префикса IPv6 2001:DB8::2:1/128.

Граничные маршрутизаторы областей (ABR18) G и J будут распространять префикс и SID в магистральную (опорную — backbone) область путем создания нового экземпляра префикса в соответствии с обычными правилами распространения между областями IGP.

Узлы C и I будут вести себя одинаково при утечке префиксов из магистральной области в область 1. Поэтому узел S будет видеть префикс 2001:DB8::2:1/128 с Prefix-SID 150, анонсируемый узлами C и I.

Следовательно, в результате Prefix-SID останется присоединенным к связанному с ним префиксу IGP через межобластной процесс, который работает в одном домене SR.

Когда узел S передает трафик по адресу 2001:DB8::2:1/128, он вталкивает Node-SID(150) в качестве активного сегмента и пересылает пакеты узлы A.

Когда пакет прибывает в ABR I (или C), ABR пересылает его в соответствии с активным сегментом Node-SID(150). Пересылка происходит через границы областей с использованием одного и того же Node-SID(150), пока пакет не попадет к получателю.

4. Сегменты BGP

Сегменты BGP могут назначаться и распространяться протоколом BGP.

4.1. Сегмент BGP-Prefix

Сегмент BGP-Prefix является сегментом BGP, присоединенным к префиксу BGP.

Сегмент BGP-Prefix является глобальным (если явно не анонсируется иное) внутри домена SR.

Сегмент BGP-Prefix в BGP является эквивалентом сегмента IGP-Prefix.

Вероятным применением сегментов BGP-Prefix является крупномасштабная «скелетообразная» топология (hyper-scale spine-leaf) без IGP, где информация о связности получается исключительно от протокола BGP [RFC7938].

4.2. Сегменты партнерства BGP

В контексте BGP EPE19, как описано в [SR-CENTRAL-EPE], поддерживающий EPE выходной узел может анонсировать сегменты, соответствующие его подключенным партнерам. Эти сегменты называются сегментами партнерства BGP или BGP peering SID. Они позволяют выражать заданные отправителем пути между доменами.

Входной граничный маршрутизатор автономной системы (AS20) может создать список сегментов для направления потока по выбранному пути внутри AS в направлении выбранного выходного граничного маршрутизатора C данной AS через конкретного партнера. Правила организации партнерства BGP, применяемые на входном узле, включают как минимум два сегмента — Node-SID выбранного выходного узла и сегмент партнерства BGP для выбранного выходного партнера или партнерского интерфейса.

Определены три типа сегментов партнерства BGP — PeerNode SID, PeerAdj SID и PeerSet SID.

  • PeerNode SID является локальным сегментом, на анонсирующем его узле BGP семантика сегмента включает:

    • операция SR: NEXT.

    • Next-Hop: подключенный партнерский узел, к которому относится сегмент.

  • PeerAdj SID является локальным сегментом, на анонсирующем его узле BGP семантика сегмента включает:

    • операция SR: NEXT.

    • Next-Hop: партнер, подключенный через интерфейс, с которым связан сегмент.

  • PeerSet SID является локальным сегментом, на анонсирующем его узле BGP семантика сегмента включает:

    • операция SR: NEXT.

    • Next-Hop: балансировка нагрузки через любой подключенный интерфейс к любому партнеру в связанной группе.

    Набор партнеров может включать всех подключенных партнеров из той же AS или их подмножество. Группа может охватывать несколько AS. Определение группы является правилом, задаваемым оператором.

Расширения BGP, требуемые для сигнализации этих сегментов партнерства BGP, определены в [BGPLS-SR-EPE].

5. Сегмент привязки

Для обеспечения масштабируемости, затенения сетей и независимости служб в SR используется Binding SID (BSID). BSID связан с политикой SR Policy, экземпляр которой может включать список SID. Любые пакеты, принятые с активным сегментом, совпадающим с BSID, управляются привязанной SR Policy.

BSID может представлять собой локальный или глобальный идентификатор SID. Локальные BSID следует выделять из SRLB, глобальные должны выделяться из SRGB.

Использование BSID позволяет сохранять экземпляр политики (список SID) лишь на узлах, которым требуется наложить политику. Направление трафика узлу, поддерживающему политику, требует только наложения BSID. Если политика меняется, это означает, что менять потребуется лишь узлы, на которые наложена эта политика. На пользователей политики воздействия не оказывается.

5.1. Сегмент IGP Mirroring Context

Одним из вариантов использования сегмента привязки является поддержка для узла IGP анонсирования его способности обрабатывать трафик, исходно адресованный другому узлу IGP (отраженный узел), указанному адресом IP или Node-SID, при условии, что сегмент контекста отражения (Mirroring Context) вставляется в список сегментов до любого сегмента сервиса, который является локальным на отраженном узле.

Когда данный узел B хочет обеспечить защиту выходного узла A, он анонсирует сегмент, указывающий контекст узла A. Такой сегмент называют сегментом контекста отражения и он указывается идентификатором Mirror SID.

Mirror SID анонсируется с использованием сегмента привязки, определенного в расширениях SR IGP [ISIS-SR-EXT].

В случае отказа точка локального ремонта (PLR21), перенаправляющая трафик с A на B, вталкивает (PUSH) Mirror SID для защищенного трафика. При получении трафика с Mirror SID в качестве активного сегмента B использует этот сегмент и обрабатывает нижележащие сегменты в контексте A.

6. Групповая адресация

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

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

Документ не требует действий сос тороны IANA.

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

Маршрутизацию по сегментам можно применять для уровней данных MPLS и IPv6.

SR добавляет к пакету метаданные (инструкции) со списком элементов пути пересылки (например, узлов, каналов, служб и т. п.), через которые пакет должен пройти. Отмечено, что полный путь заданной отправителем маршрутизации может быть представлен одним сегментом. Это сегмент привязки — Binding SID.

По умолчанию SR работает внутри доверенного домена. Трафик должен фильтроваться на границе домена.

Важное значение имеет использование накопленного опыта для снижения риска несанкционированного доступа внутри доверенного домена. Такой опыт рассмотрен в [RFC4381] и применим как для SR-MPLS, так и для SRv6.

8.1. SR-MPLS

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

SR позволяет выражать заданный отправителем путь в виде одного сегмента (Binding SID). По сравнению с RSVP-TE, где также обеспечивается возможность явной маршрутизации, нет основополагающих различий в плане предоставляемой информации. Как RSVP-TE, так и SR позволяют выразить заданный отправителем путь в одном сегменте.

Когда путь задается с использованием одной метки, синтаксис метаданных RSVP-TE [RFC3209] и SR эквивалентен.

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

Когда путь выражается с использованием стека меток, наличие у кого-либо доступа к смыслу меток (т. е., FEC22) означает знание явного пути. Для уровня данных MPLS изменение уровня данных не требуется и не происходит существенного изменения возможности. Тем не менее, использование стека меток будет расширяться.

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

С точки зрения защиты сети предполагается модель доверия, в которой любой узел, налагающий стек меток, предполагается правомочным для такой операции. Это существенно отличается от обычной практики IP с маршрутизацией по кратчайшему пути, но не имее6т принципиальных отличий от существующих методов явной маршрутизации типа RSVP-TE. По умолчанию для явной маршрутной информации недопустима утечка через границу административного домена. Расширения SR, определенные для различных протоколов, используют механизмы защиты этих протоколов типа шифрования, проверки подлинности, фильтрации и т. п.

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

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

Для уровня данных MPLS не предъявляется новых требований к имеющейся архитектуре, поскольку в MPLS уже разрешена заданная отправителем маршрутизация и создание стеков со множеством меток. А для обеспечения защиты уже используется фильтрация пакетов MPLS на границе области доверия [RFC4381], [RFC5920].

8.2. SRv6

При использовании с уровнем данных IPv6 SR добавляет заголовок SRH [IPv6-SRH] типа Routing Extension, как определено в [RFC8200].

SRH добавляет в пакет IPv6 метаданные со списком элементов пути пересылки (например, узлы, каналы, службы и т. п.), через которые пакет должен пройти, в форме адресов IPv6. Полный путь с заданной отправителем маршрутизацией может быть представлен в пакете с использованием одного сегмента (адреса IPv6).

Граничные маршрутизаторы домена SR должны фильтровать любой внешний трафик, направленный по адресам из SRGB доверенного домена или из SRLB конкретного граничного маршрутизатора. Внешним считается любой трафик, полученный с интерфейса, подключенного к узлу, находящемуся за пределами доверенного домена.

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

В общем случае маршрутизатор SRv6 воспринимает и устанавливает идентификаторы сегментов (в форме адресов IPv6) только в том случае, когда SID анонсируются доверенным источником. Полученная информация проверяется с использованием имеющихся протоколов уровня управления, обеспечивающих механизмы защиты и проверки подлинности. SR не определяет дополнительных механизмов защиты к существующим протоколам уровня управления.

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

  • злонамеренные маршрутные петли;

  • обход контроля доступа;

  • сокрытие источника DoS-атаки.

Вопросы безопасности SR при использовании с уровнем данных IPv6 более подробно рассмотрены в [RFC5095]. Новый заголовок IPv6 SRH определен в [IPv6-SRH]. В этом же документе рассматриваются указанные выше проблемы безопасности.

8.3. Контроль перегрузок

SR не вносит новых требований к контролю перегрузок. По умолчанию предполагается доставка трафика в режиме best effort. Контроль перегрузок может быть реализован на оконечных точках. При использовании правил SR распределение пропускной способности может обеспечиваться на основе мониторинга входящего трафика, связанного с сегментом привязки, указывающим SR Policy. Могут применяться и другие решения типа предложенного в [RFC8084].

9. Проблемы управляемости

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

Варианты использования SR OAM для уровня данных MPLS определены в [RFC8403], а процедуры SR OAM для MPLS — в [RFC8287].

Маршрутизаторы SR получают анонсы SID (индексы, метки или адреса IPv6) от разных протоколов маршрутизации, которые расширены для поддержки SR. Каждый из таких протоколов имеет механизмы мониторинга и поиска неполадок, обеспечивающие работу и функции управления для IP-адресов, которые должны быть расширены с целью обеспечения этих функций для SID.

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

При указании пути в виде стека меток узлам может потребоваться механизм сигнализации уровню управления своих возможностей (размера поддерживаемого стека меток).

Модель данных YANG [RFC6020] для настройки и работы SR определена в [SR-YANG].

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

Адрес получателя (DA) пакет задает адрес активного сегмента, а список сегментов в SRH — полный путь пакета. Проверка пригодности заданного отправителем пути выполняется путем проверки соответствия DA и SRH в пакете эквивалентным записям в таблице маршрутизации.

В контексте уровня данных SRv6 заданный отправителем путь кодируется в SRH, как описано в [IPv6-SRH]. Заданный отправителем путь SRv6 представляется в заголовке SRH в виде списка адресов IPv6, где активный сегмент указывается в поле DA заголовка IPv6. Обычно при проверке любым узлом заголовка пакета можно вывести путь source-routed, к которому пакет относится. Подобно контексту уровня данных SR-MPLS, реализация может создавать пакеты контроля пути и мониторинга, где путь source-routed помещается в SRH, а каждый сегмент пути помещает в пакет соответствующие данные для сквозного контроля пути и производительности.

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, «Multiprotocol Label Switching Architecture», RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

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

[BGPLS-SR-EPE] Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, «BGP-LS extensions for Segment Routing BGP Egress Peer Engineering», Work in Progress, draft-ietf-idr-bgpls-segment-routing-epe-15, March 2018.

[IPv6-SRH] Filsfils, C., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, Ed., «IPv6 Segment Routing Header (SRH)», Work in Progress, draft-ietf-6man-segment-routing-header-14, June 2018.

[ISIS-SR-EXT] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, «IS-IS Extensions for Segment Routing», Work in Progress, draft-ietf-isis-segment-routing-extensions-19, July 2018.

[OSPF-SR-EXT] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, «OSPF Extensions for Segment Routing», Work in Progress, draft-ietf-ospf-segment-routing-extensions-25, April 2018.

[OSPFv3-SR-EXT] Psenak, P., Ed., Filsfils, C., Previdi, S., Ed., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, «OSPFv3 Extensions for Segment Routing», Work in Progress, draft-ietf-ospf-ospfv3-segment-routing-extensions-13, May 2018.

[PCEP-SR-EXT] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, «PCEP Extensions for Segment Routing», Work in Progress, draft-ietf-pce-segment-routing-12, June 2018.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC4206] Kompella, K. and Y. Rekhter, «Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)», RFC 4206, DOI 10.17487/RFC4206, October 2005, <https://www.rfc-editor.org/info/rfc4206>.

[RFC4381] Behringer, M., «Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4381, DOI 10.17487/RFC4381, February 2006, <https://www.rfc-editor.org/info/rfc4381>.

[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, «Multi-Topology (MT) Routing in OSPF», RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, «Deprecation of Type 0 Routing Headers in IPv6», RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.

[RFC5120] Przygienda, T., Shen, N., and N. Sheth, «M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)», RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.

[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., «Path Computation Element (PCE) Communication Protocol (PCEP)», RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.

[RFC5714] Shand, M. and S. Bryant, «IP Fast Reroute Framework», RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.

[RFC5920] Fang, L., Ed., «Security Framework for MPLS and GMPLS Networks», RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, «OSPFv2 Multi-Instance Extensions», RFC 6549, DOI 10.17487/RFC6549, March 2012, <https://www.rfc-editor.org/info/rfc6549>.

[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., «Use of BGP for Routing in Large-Scale Data Centers», RFC 7938, DOI 10.17487/RFC7938, August 2016, <https://www.rfc-editor.org/info/rfc7938>.

[RFC8084] Fairhurst, G., «Network Transport Circuit Breakers», BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.

[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, «IS-IS Multi-Instance», RFC 8202, DOI 10.17487/RFC8202, June 2017, <https://www.rfc-editor.org/info/rfc8202>.

[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, «Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes», RFC 8287, DOI 10.17487/RFC8287, December 2017, <https://www.rfc-editor.org/info/rfc8287>.

[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, «Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks», RFC 8355, DOI 10.17487/RFC8355, March 2018, <https://www.rfc-editor.org/info/rfc8355>.

[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, «A Scalable and Topology-Aware MPLS Data-Plane Monitoring System», RFC 8403, DOI 10.17487/RFC8403, July 2018, <http://www.rfc-editor.org/info/rfc8403>.

[SR-CENTRAL-EPE] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, «Segment Routing Centralized BGP Egress Peer Engineering», Work in Progress, draft-ietf-spring-segment-routing-central-epe-10, December 2017.

[SR-MPLS] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, «Segment Routing with MPLS data plane», Work in Progress, draft-ietf-spring-segment-routing-mpls-14, June 2018.

[SR-YANG] Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, «YANG Data Model for Segment Routing», Work in Progress, draft-ietf-spring-sr-yang-09, June 2018.

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

Спасибо Dave Ward, Peter Psenak, Dan Frost, Stewart Bryant, Pierre Francois, Thomas Telkamp, Ruediger Geib, Hannes Gredler, Pushpasis Sarkar, Eric Rosen, Chris Bowers и Alvaro Retana за их комментарии и рецензирование документа.

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

Перечисленные ниже лица внесли существенный вклад в определение архитектуры сегментной маршрутизации и редактирование этого документа.

Ahmed Bashandy

Cisco Systems, Inc.

Email: bashandy@cisco.com

Martin Horneffer

Deutsche Telekom

Email: Martin.Horneffer@telekom.de

Wim Henderickx

Nokia

Email: wim.henderickx@nokia.com

Jeff Tantsura

Email: jefftant@gmail.com

Edward Crabbe

Email: edward.crabbe@gmail.com

Igor Milojevic

Email: milojevicigor@gmail.com

Saku Ytti

TDC

Email: saku@ytti.fi

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

Clarence Filsfils (редактор)

Cisco Systems, Inc.

Brussels

Belgium

Email: cfilsfil@cisco.com

Stefano Previdi (редактор)

Cisco Systems, Inc.

Italy

Email: stefano@previdi.net

Les Ginsberg

Cisco Systems, Inc.

Email: ginsberg@cisco.com

Bruno Decraene

Orange

FR

Email: bruno.decraene@orange.com

Stephane Litkowski

Orange

France

Email: stephane.litkowski@orange.com

Rob Shakir

Google, Inc.

1600 Amphitheatre Parkway

Mountain View, CA 94043

United States of America

Email: robjs@google.com

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

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

nmalykh@gmail.com

1Segment Routing.

2Destination Address.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Segment Identifier.

6Virtual Machine.

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

8Path Computation Element Communication Protocol — протокол коммуникаций между элементами расчета путей.

9SR Header.

10Traffic Engineering.

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

12Fast Reroute.

13Shortest Path First.

14Equal Cost Multipath — множество расноценных путей.

15Network Management System — система управления сетью.

16Designated Router.

17Designated Intermediate System.

18Area Border Router.

19Egress Peer Engineering — организация исходящих партнеров.

20Autonomous System.

21Point of Local Repair.

22Forwarding Equivalence Class — класс эквивалентности пересылки.




RFC 8342 Network Management Datastore Architecture (NMDA)

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8342                                Tail-f Systems
Updates: 7950                                           J. Schoenwaelder
Category: Standards Track                              Jacobs University
ISSN: 2070-1721                                                P. Shafer
                                                               K. Watsen
                                                        Juniper Networks
                                                               R. Wilton
                                                           Cisco Systems
                                                              March 2018

Архитектура хранилища данных сетевого управления NMDA

Network Management Datastore Architecture (NMDA)

PDF

Тезисы

Хранилища данных являются фундаментальной концепцией привязки моделей данных, написанных на языке моделирования YANG, к протоколам сетевого управления типа NETCONF1 и RESTCONF. Этот документ определяет архитектурную модель для хранилищ данных на основе опыта, полученного с начальными простыми моделями, которая решает вопросы, не поддерживаемые первоначальной моделью. Документ обновляет RFC 7950.

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

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

Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

Авторские права (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. Введение

Этот документ предоставляет архитектурную модель для хранилищ данных, используемых протоколами сетевого управления типа NETCONF [RFC6241] и RESTCONF [RFC8040], а также языком моделирования данных YANG [RFC7950]. Хранилища являются фундаментальной концепцией, привязывающей модели данных сетевого управления к протоколам сетевого управления. Согласование общей архитектурной модели хранилища данных позволит создавать модели данных без привязки к конкретному протоколу сетевого управления. Эта архитектурная основа идентифицирует набор концептуальных хранилищ, но не обязывает все протоколы сетевого управления предоставлять все эти концептуальные хранилища. Архитектура не привязана к кодированию, используемому протоколами сетевого управления.

Данный документ обновляет RFC 7950 в части определения доступного дерева для некоторых вариантов контекста XPath4 (см. параграф 6.1) и контекста вызова операций ( см. параграф 6.2).

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

2. Цели

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

Исходная модель хранилищ данных требует моделирования этих данных в схеме YANG дважды — как объекты config true и config false. Соглашение, принятое в модели данных интерфейса [RFC8343] и модели данных IP [RFC8344], состоит в использовании двух раздельных ветвей с общим корнем — одна ветвь для объектов данных конфигурации, другая для объектов данных текущего состояния.

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

В пересмотренной архитектурной модели хранилищ данных объекты определяются в схеме YANG только один раз, но их независимые экземпляры могут присутствовать в разных хранилищах данных, например, один для настраиваемого значения, а другой для текущего. Это обеспечивает более простое и изящное решение проблемы.

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

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

Используемые в документе термины определены ниже. Некоторые термины используют пересмотренные определения из [RFC6241] и [RFC7950] (см. также раздел 4). Эти пересмотренные определения семантически эквивалентны определениям из [RFC6241] и [RFC7950]. Предполагается, что обновленные определения из этого раздела будут применяться взамен определений [RFC6241] и [RFC7950] при пересмотре этих документов.

datastore – хранилище данных

Концептуальное место для хранения и доступа к информации. Хранилище может быть реализовано, например, в виде файла, базы данных, flash-памяти или их комбинации. Хранилище отображается на экземпляр дерева данных YANG.

schema node — узел схемы

Узел в дереве схемы. Формальное определение приведено в RFC 7950.

datastore schema — схема хранилища данны

Комбинированный набор узлов схемы для всех модулей, поддерживаемых конкретным хранилищем с учетом всех отклонений и активных функций (feature) хранилища.

configuration – конфигурация, данные конфигурации

Данные, которые нужны для перевода устройства из начального состояния в желаемое рабочее состояние. Эти данные моделируются в YANG с использованием узлов config true. Конфигурация может происходить из разных источников.

configuration datastore – хранилище конфигурации

Хранилище данных, содержащее параметры конфигурации.

running configuration datastore – хранилище рабочей конфигурации

Конфигурационное хранилище, содержащее текущие (рабочие) параметры конфигурации устройства. Оно может включать конфигурацию, которая перед применением требует тех или иных преобразований. Это хранилище обозначают <running>.

candidate configuration datastore – хранилище будущей конфигурации, хранилище-кандидат

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

startup configuration datastore — хранилище стартовой конфигурации

Конфигурационное хранилище, содержащие данные, которые будут помещены в рабочее хранилище при следующей загрузке устройства. Это хранилище обозначают <startup>.

intended configuration – предполагаемая конфигурация

Конфигурация, предназначенная для использования устройством. Представляет собой конфигурацию после выполнения всех преобразований в <running> и является конфигурацией, которую система попытается применить.

intended configuration datastore – хранилище предполагаемой конфигурации

Конфигурационное хранилище содержащее полную предполагаемую конфигурацию. Это хранилище обозначают <intended>.

configuration transformation — преобразование конфигурации

Дополнение, изменение или удаление данных конфигурации при передаче между хранилищами <running> и <intended>. Примерами конфигурационных преобразований служат удаление из конфигурации неактивных элементов и создание конфигурации из шаблона.

conventional configuration datastore – традиционное (обычное) хранилище данных конфигурации

Одно из хранилищ <running>, <startup>, <candidate> и <intended>. Эти хранилища используют общую схему и протокольные операции позволяют копировать данные между хранилищами. Термин conventional выбран в качестве общего обозначения всех таких хранилищ.

conventional configuration – конфигурация общего назначения

Конфигурационные данные, хранящиеся в любом из традиционных хранилищ.

dynamic configuration datastore – хранилище динамических данных конфигурации

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

dynamic configuration – динамическая конфигурация

Конфигурация, полученная из динамического хранилища.

learned configuration — выведенная конфигурация

Конфигурация, которая была выведена (learned) путем протокольного взаимодействия с другими системами и не явлется ни традиционной, ни динамической.

system configuration – системная конфигурация

Конфигурация, поставляемая (обеспечиваемая) самой системой.

default configuration – принятая по умолчанию конфигурация

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

applied configuration – примененная конфигурация

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

system state – состояние системы

Дополнительные данные системы, которые не относятся к конфигурационным, это могут быть предназначенные только для чтения параметры состояния или собранная статистика. Состояние системы является временным и меняется в результате взаимодействия с внутренними компонентами или внешними системами. Состояние системы моделируется в YANG с использованием узлов config false.

operational state – рабочее состояние

Комбинация примененной конфигурации и состояния системы.

operational state datastore – хранилище рабочего состояния

Хранилище данные, содержащее полное рабочее состояние устройства. Это хранилище обозначают <operational>.

origin – источник, происхождение

Аннотация метаданных, показывающая источник элементе данных.

remnant configuration – остаточная конфигурация

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

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

client — клиент

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

server — сервер

Объект, который пердоставляет клиенту доступ к данным YANG с помощью некого протокола управления сетью.

notification — уведомление

Инициированное сервером сообщение, указывающее на некое событие, которое распознал сервер.

remote procedure call – вызов удаленной процедуры

Операция которая может быть вызвана клиентом для выполнения на сервере.

4. Предпосылки

Протокол NETCONF [RFC6241] включает приведенные ниже определения.

datastore – хранилище данных

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

configuration datastore — хранилище конфигурации

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

Язык YANG 1.1 [RFC7950] вносит уточнения для использования NETCONF с YANG (обычное дело, но отметим, что протокол NETCONF был создан раньше YANG).

datastore

При моделировании с использованием YANG хранилеще данных реализуется в виде экземпляра дерева данных.

configuration datastore

При моделировании с использованием YANG хранилеще данных реализуется в виде экземпляра дерева конфигурационных данных.

[RFC6244] определяет данные операционного состояния, как показано ниже.

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

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

Опыт реализации и запросы операторов [OpState-Reqs] [OpState-Modeling] показали, что модель хранилища, разработанная изначально для NETCONF и уточненная YANG, требует расширения. В частности, были разработаны понятия предполагаемой конфигурации и примененной конфигурации.

4.1. Исходная модель хранилищ данных

На рисунке 1 показана исходная модель хранилищ данных, используемая сейчас протоколом NETCONF [RFC6241].

+-------------+                 +-----------+
| <candidate> |                 | <startup> |
|  (ct, rw)   |<---+       +--->| (ct, rw)  |
+-------------+    |       |    +-----------+
       |           |       |           |
       |         +-----------+         |
       +-------->| <running> |<--------+
                 | (ct, rw)  |
                 +-----------+
                       |
                       v
                 рабочее состояние  <--- уровень управления
                    (cf, ro)

ct = config true; cf = config false
rw = read-write; ro = read-only
прямоугольники обозначают хранилища

Рисунок 1.


Отметим, что модель на рисунке упрощена, полномочия read-only (ro) и read-write (rw) представлены с точки зрения клиента на концептуальном уровне. В NETCONF, например, поддержка хранилищ <candidate> и <startup> является не обязательной, а запись в хранилище <running> не разрешена. Кроме того, хранилище <startup> может быть изменено только путем копирования в него хранилища <running> <startup> в стандартизованной модели редактирования хранилищ NETCONF. Протокол RESTCONF не показывает таких различий и вместо этого обеспечивает универсальное хранилище с возможностью записи, которое скрывает редактирование через промежуточное хранилище <candidate> путем прямой записи в <running> или иного механизма, зависящего от реализации. RESTCONF также скрывает, как конфигурация становится постоянной. Отметим, что реализации могут иметь дополнительные хранилища, которые могут распространять изменения на <running>. NETCONF явно указывает «именованные хранилища данных» (named datastore).

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

  • Операционное состояние не было определено как хранилище данных, хотя были предложения о создании такого хранилища.

  • Операция NETCONF <get> возвращает содержимое хранилища <running> вместе с операционным состоянием. Это требует хранения данных config false и config true вразных ветвях, если данные операционного состояния по сроку жизни отличаются от конфигурационных данных, в также в тех случаях, когда конфигурация применяется не сразу или возникают проблемы с ее применением.

  • Некоторые реализации используют фирменные механизмы, которые позволяют клиентам сохранять неактивные данные в хранилище <running>. Концептуально такие данные удаляются перед проверкой пригодности конфигурации.

  • Некоторые реализации используют фирменные механизмы, которые позволяют клиентам определять шаблоны конфигурации в хранилище <running>. Эти шаблоны автоматически раскрываются (преобразуются) системой и полученная в результате конфигурация применяется внутренними средствами.

  • Некоторые операторы отмечали, что для них важно получить успешно примененую конфигурацию, которая может быть надмножеством или подможеством конфигурации в хранилище <running>.

5. Архитектурная модель хранилищ данных

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

+-------------+                 +-----------+
| <candidate> |                 | <startup> |
|  (ct, rw)   |<---+       +--->| (ct, rw)  |
+-------------+    |       |    +-----------+
       |           |       |           |
       |         +-----------+         |
       +-------->| <running> |<--------+
                 | (ct, rw)  |
                 +-----------+
                       |
                       |        // преобразования конфигурации,
                       |        // например, удаление узлов с 
                       |        // меткой "inactive", раскрытие
                       |        // шаблонов
                       v
                 +------------+
                 | <intended> | // нужна проверка на пригодность
                 | (ct, ro)   |
                 +------------+
                       |        // применение изменений; может
                       |        // от локальных факторов, например,
                       |        // отсутствие ресурсов, задержки
                       |
  хранилища            |   +-------- выведенная конфигурация
  динамической         |   +-------- конфигурация системы
  конфигурации ---+    |   +-------- конфигурация по умолчанию
                  |    |   |
                  v    v   v
               +---------------+
               | <operational> | <-- состояние сисетмы
               | (ct + cf, ro) |
               +---------------+

     ct = config true; cf = config false
     rw = read-write; ro = read-only
     прямоугольники показывают именованные хранилища

Рисунок 2.


5.1. Традиционные хранилища конфигурации

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

  • <running>

  • <candidate>

  • <startup>

  • <intended>

В будущих документах могут быть определены дополнительные хранилища.

Поток данных между хранилищами описан в разделе 5.

Конкретные протоколы могут определять явные операции копирования между хранилищами (например, NETCONF <copy-config>.

5.1.1. Хранилище стартовой конфигурации (<startup>)

Хранилище стартовой конфигурации <startup> содержит данные, которые устройство использует при своей загрузке (включении). Хранилище <startup> присутствует только на устройствах, имеющих раздельные хранилища для стартовой и рабочей конфигурации.

Хранилище стартовой конфигурации может поддерживаться не всеми протоколами и реализациями.

На устройствах с энерго-независимой памятью содержимое хранилища <startup> обычно будет сохраняться при перезагрузке устройства с использованием этого хранилища. Во время загрузки устройство помещает стартовую конфигурацию в хранилище <running>. Для сохранения новой стартовой конфигурации данные копируются в <startup> с помощью явной или неявной операции протокола.

5.1.2. Хранилище будущей конфигурации (<candidate>)

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

Хранилище будущей конфигурации может поддерживаться не всеми протоколами и реализациями.

Хранилище <candidate> обычно не сохраняется при перезагрузке устройства, даже если для него используется энерго-независимая память. Если хранилище <candidate> сохраняется в такой памяти, в процессе перезагрузки оно заменяется содержимым хранилища <running>.

5.1.3. Хранилище рабочей конфигурации (<running>)

Хранилище рабочей конфигурации <running> представляет собой хранилище с текущей конфигурацией устройства. Оно может содержать конфигурацию, которая перед применением требует преобразования (например, удаление неактивных элементов или раскрытие шаблонов). Однако хранилище <running> всегда должно быть пригодным деревом конфигурационных данных, как указано в параграфе 8.1 [RFC7950].

Хранилище <running> должно поддерживаться, если устройство настраивается с использованием традиционного хранилища конфигурации.

Если устройство не имеет отдельно хранилища <startup> и доступна энерго-независимая память, такое устройство обычно будет использовать эту память для сохранения <running> в процессе перезагрузки.

5.1.4. Хранилище предполагаемой конфигурации (<intended>)

Хранилище предполагаемой конфигурации <intended> открыто только для чтения. Оно представляет конфигурацию после выполнения всех преобразования в <running> (например, расширения шаблонов и удаления неактивных компонент), которую система пытается применить.

Хранилище <intended> тесно связано с <running>. При записи данных в хранилище <running> сервер должен незамедлительно обновить и проверить на пригодность хранилище <intended>.

Содержимое <intended> может также обновляться независимо от <running>, если воздействие преобразований конфигурации меняется, но хранилище <intended> всегда должен быть пригодным деревом данных конфигурации, как указано в параграфе 8.1 [RFC7950].

В простых реализациях хранилища <running> и <intended> идентичны.

Содержимое <intended> также связано с подмножеством config true хранилища <operational>, поэтому клиент может определить, в какой степени предполагаемая конфигурация соответствует текущей, просто проверяя, какая часть содержимого <intended> присутствует в <operational>.

Хранилище <intended> не сохраняется при перезагрузке — его привязка к <running> делает это ненужным.

В настоящее время не определено стандартных механизмов воздействия на хранилище <intended> так, чтобы оно отличалось от <running>, но данная архитектура позволяет определить такие механизмы.

Примером такого механизма может служить поддержка маркировки неактивных узлов в хранилище <running>. Неактивные узлы не будут копироваться в хранилище <intended>. Вторым примером является поддержка шаблонов, которые могут выполнять преобразования конфигурации из <running> для записи в хранилище <intended>.

5.2. Хранилища динамической конфигурации

Модель принимает необходимость хранилищ динамической конфигурации, которые по определению не являются частью постоянной конфигурации устройства. Иногда такие хранилища называют эфемерными (ephemeral datastore), поскольку хранящаяся в них информация теряется при перезагрузке. Хранилища динамической конфигурации взаимодействуют с остальной системой через хранилище <operational>.

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

5.3. Хранилище операционного состояния (<operational>)

Хранилище операционного состояния (<operational>) открыто лишь для чтения и включает все узлы config true и config false, определенные в схеме хранилища данных. В исходной модели NETCONF модель операционного состояния содержит только узлы config false. Причиной включения узлов config true является потребность в представлении рабочих параметров без их дублирования в модели данных.

Хранилище <operational> содержит данные состояния и конфигурацию, реально используемую системой. Это включает примененную конфигурацию из хранилища <intended>, выведенную (learned) и представленную системой конфигурацию, а также значения, принятые по умолчанию, которые определены любыми поддерживаемыми моделями данных. В дополнение к этому <operational> содержит также примененную конфигурацию из хранилища динамической конфигурации.

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

Запросы на поиск узлов из хранилища <operational> всегда возвращают используемое значение для существующих узлов, независимо от наличия в модуле YANG принятых по умолчанию значений. Если для данного узла значение не возвращено, это означает, что узел не используется устройством.

Интерпретация слов «используется системой» (in use) зависит от определения схемы и реализации устройства. Обычно функциональность, которая разрешена (включена) и работает в системе, считается используемой. И наоборот, функциональность, которая не включена и не работает считается «не используемой», поэтому ее не следует включать в <operational>.

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

Нарушаться могут только семантические ограничения. К ним относятся операторы YANG when, must, mandatory, unique, min-elements и max-elements, а также уникальность значений ключей.

Синтаксические ограничения, включая иерархическую организацию, идентификаторы и ограничения по типам, нарушать недопустимо. Если узел в хранилище <operational> не соответствует синтаксическим ограничениям, недопустимо возвращать его, а для информирования об ошибке следует применять другие механизмы.

Хранилище <operational> не сохраняется при перезагрузке устройства.

5.3.1. Остаточная конфигурация

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

Остаточная конфигурация является типичным примером, где семантические ограничения, определенные в модели данных, не могут быть применены для хранилища <operational>, поскольку в системе может сохраняться конфигурация, ограничения которой были пригодны для прежнего варианта, но недействительны в текущей конфигурации. Поскольку ограничения узлов config false могут быть связаны с узлами config true, остаточная конфигурация может вызывать нарушение этих ограничений.

5.3.2. Отсутствующие ресурсы

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

Типичным примером является конфигурация интерфейса, который в настоящее не присутствует. В этом случае конфигурация интерфейса остается в хранилище <intended>, но не включается в <operational>.

Отметим, что пригодность конфигурации не может зависеть от текущего состояния таких ресурсов, поскольку это приводило бы в непригодности конфигурации в случае удаления ресурса. Это неприемлемо, особенно с учетом того, что перезагрузка такого устройства будет приводить к его перезапуску с непригодной конфигурацией. Поэтому конфигурации с отсутствующими ресурсами разрешаются для хранилищ <running> и <intended>, но эти ресурсы не могут присутствовать в <operational>.

5.3.3. Контролируемые системой ресурсы

Иногда ресурсы, контролируемые системой и соответствующие данные появляются (и исчезают) в хранилище <operational> динамически. Если контролируемый системой ресурс имеет соответствующую конфигурацию в <intended> при его появлении, система попытается применить эту конфигурацию и это в конечном итоге приведет к ее появлению в хранилище <operational> (если применение пройдет успешно).

5.3.4. Аннотация метаданных источника

При передаче конфигурации в хранилище <operational> она концептуально помечается аннотацией метаданных [RFC7952]Ю указывающей источник. Источник применяет все узлы за исключением контейнеров отсутствия. Аннотация метаданных origin определена в разделе 7. Значениями служат отождествления YANG, перечисленные ниже.

  • origin — абстрактное базовое отождествление, из которого выводено другое отождествление источника.

  • intended — представляет конфигурацию из хранилища <intended>.

  • dynamic — представляет конфигурацию из хранилища динамической конфигурации.

  • system — представляет конфигурацию, обеспеченную самой системой. Примеры системной конфигурации включают всегда присутствующий интерфейс loopback или конфигурацию интерфейса, которая создается автоматически при наличии оборудования в устройстве.

  • learned — представляет конфигурацию, которая была выведена через протокольные взаимодействия с другими системами (включая такие взаимодействия как согласование канального уровня, протоколы маршрутизации, DHCP).

  • default — представляет конфигурацию с применением значений, принятых по умолчанию в модели данных, используя значения в операторе default или любые значения, описанные в операторе description. Этот источник лишь про отсутствии других источников конфигурации.

  • unknown — представляет конфигурацию, для которой система не может определить источник.

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

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

При возникновении неоднозначностей в части выбора источника, когда конфигурационные данные приходят из нескольких источников сразу, следует использовать оператор description в модуле YANG для выбора подходящего источника. Например,

Если для отдельного узла конфигурации соответствующий оператор description в модуле YANG указывает, что согласованное протоколом значение переписыват значение из конфигурации, в качестве источника следует указывать learned, даже при совпадении выведенного значения с указанным в конфигурации.

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

Если устройство не может точно указать источник данных для отдельного узла конфигурации, следует указывать источник unknown.

6. Воздействие на YANG

6.1. Контекст XPath

Этот параграф обновляет параграф 6.4.1 из RFC 7950.

Если сервер реализует определенную в этом документе архитектуру, доступные деревья для некоторых вариантов контекста XPath уточняются как показано ниже.

  • Если выражение XPath определено в субоператоре узла данных, который представляет состояние системы, доступным деревом является все операционное состояние сервера. Корневой узел имеет в качестве потомков узлы верхнего уровня всех модулей.

  • Если выражение XPath определено в субоператоре оператора notification, доступным деревом является экземпляр уведомления и все операционное состояние сервера. Если уведомление определено на вершине модуля, корневой узел имеет в качестве потомков узлел, представляющий уведомление, которое определено, и узлы верхнего уровня всех модулей. В остальных случаях корневой узел имеет в качестве потомков узлы верхнего уровня всех модулей.

  • Если выражение XPath определено в субоператоре оператора input внутри оператора rpc или action, доступным деревом будет экземпляр RPC или операции и все операционное состояние сервера. Корневой узел имеет в качестве потомков узлы верхнего уровня всех модулей. Кроме того, для RPC корневой узел имеет в качестве потомка также узел, который представляет определяемую операцию RPC. Этот узел имеет в качестве потомков входные параметры операции.

  • Если выражение XPath определено в субоператоре оператора output внутри оператора rpc или action, доступным деревом будет экземпляр RPC или операции и все операционное состояние сервера. Корневой узел имеет в качестве потомков узлы верхнего уровня всех модулей. Кроме того, для RPC корневой узел имеет в качестве потомка также узел, который представляет определяемую операцию RPC. Этот узел имеет в качестве потомков выходные результаты операции.

6.2. Вызовы операций и RPC

Этот параграф обновляет параграф 7.15 из RFC 7950.

Операции всегда вызываются к контексте хранилища операционного состояния. Узел, для которого вызывается операция, должен существовать в хранилище операционного состояния.

Отметим, что этот документ никак не ограничивает результат вызова RPC или операции. Например, можно определить RPC для изменения содержимого того или иного хранилища данных.

7. Модули YANG

   <CODE BEGINS> file "ietf-datastores@2018-02-14.yang"

   module ietf-datastores {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
     prefix ds;

     organization
       "IETF Network Modeling (NETMOD) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>

        WG List:  <mailto:netmod@ietf.org>

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>

        Author:   Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de>

        Author:   Phil Shafer
                  <mailto:phil@juniper.net>

        Author:   Kent Watsen
                  <mailto:kwatsen@juniper.net>

        Author:   Rob Wilton
                  <rwilton@cisco.com>";

     description
       "This YANG module defines a set of identities for identifying
        datastores.

        Copyright (c) 2018 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Simplified BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC 8342
        (https://www.rfc-editor.org/info/rfc8342); see the RFC itself
        for full legal notices.";

     revision 2018-02-14 {
       description
         "Initial revision.";
       reference
         "RFC 8342: Network Management Datastore Architecture (NMDA)";
     }

     /*
      * Отождествления
      */

     identity datastore {
       description
         "Abstract base identity for datastore identities.";
     }

     identity conventional {
       base datastore;
       description
         "Abstract base identity for conventional configuration
          datastores.";
     }

     identity running {
       base conventional;
       description
         "The running configuration datastore.";
     }

     identity candidate {
       base conventional;
       description
         "The candidate configuration datastore.";
     }

     identity startup {
       base conventional;
       description
         "The startup configuration datastore.";
     }

     identity intended {
       base conventional;
       description
         "The intended configuration datastore.";
     }

     identity dynamic {
       base datastore;
       description
         "Abstract base identity for dynamic configuration datastores.";
     }

     identity operational {
       base datastore;
       description
         "The operational state datastore.";
     }

     /*
      * Определения типов
      */

     typedef datastore-ref {
       type identityref {
         base datastore;
       }
       description
         "A datastore identity reference.";
     }
   }

   <CODE ENDS>

   <CODE BEGINS> file "ietf-origin@2018-02-14.yang"

   module ietf-origin {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
     prefix or;

     import ietf-yang-metadata {
       prefix md;
     }

     organization
       "IETF Network Modeling (NETMOD) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>

        WG List:  <mailto:netmod@ietf.org>

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>

        Author:   Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de>

        Author:   Phil Shafer
                  <mailto:phil@juniper.net>

        Author:   Kent Watsen
                  <mailto:kwatsen@juniper.net>

        Author:   Rob Wilton
                  <rwilton@cisco.com>";

     description
       "This YANG module defines an 'origin' metadata annotation and a
        set of identities for the origin value.

        Copyright (c) 2018 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Simplified BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC 8342
        (https://www.rfc-editor.org/info/rfc8342); see the RFC itself
        for full legal notices.";

     revision 2018-02-14 {
       description
         "Initial revision.";
       reference
         "RFC 8342: Network Management Datastore Architecture (NMDA)";
     }

     /*
      * Отождествления
      */

     identity origin {
       description
         "Abstract base identity for the origin annotation.";
     }

     identity intended {
       base origin;
       description
         "Denotes configuration from the intended configuration
          datastore.";
     }

     identity dynamic {
       base origin;
       description
         "Denotes configuration from a dynamic configuration
          datastore.";
     }

     identity system {
       base origin;
       description
         "Denotes configuration originated by the system itself.

          Examples of system configuration include applied configuration
          for an always-existing loopback interface, or interface
          configuration that is auto-created due to the hardware
          currently present in the device.";
     }

     identity learned {
       base origin;
       description
         "Denotes configuration learned from protocol interactions with
          other devices, instead of via either the intended
          configuration datastore or any dynamic configuration
          datastore.

          Examples of protocols that provide learned configuration
          include link-layer negotiations, routing protocols, and
          DHCP.";
     }

     identity default {
       base origin;
       description
         "Denotes configuration that does not have a configured or
          learned value but has a default value in use.  Covers both
          values defined in a 'default' statement and values defined
          via an explanation in a 'description' statement.";
     }

     identity unknown {
       base origin;
       description
         "Denotes configuration for which the system cannot identify the
          origin.";
     }

     /*
      * Определения типов
      */

     typedef origin-ref {
       type identityref {
         base origin;
       }
       description
         "An origin identity reference.";
     }

     /*
      * Metadata annotations
      */

     md:annotation origin {
       type origin-ref;
       description
         "The 'origin' annotation can be present on any configuration
          data node in the operational state datastore.  It specifies
          from where the node originated.  If not specified for a given
          configuration data node, then the origin is the same as the
          origin of its parent node in the data tree.  The origin for
          any top-level configuration data nodes must be specified.";
     }
   }

   <CODE ENDS>

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

8.1. Обновление реестра IETF XML Registry

Этот документ регистрирует два URIs в реестре IETF XML Registry [RFC3688]. В соответствии с форматом [RFC3688] были выполнены приведенные ниже регистрации.

      URI: urn:ietf:params:xml:ns:yang:ietf-datastores
      Registrant Contact: The IESG.
      XML: N/A; the requested URI is an XML namespace.

      URI: urn:ietf:params:xml:ns:yang:ietf-origin
      Registrant Contact: The IESG.
      XML: N/A; the requested URI is an XML namespace.

8.2. Обновление реестра YANG Module Names Registry

Этот документ регистрирует два модуля YANG в реестре YANG Module Names [RFC6020]. В соответствии с форматом [RFC6020] были выполнены приведенные ниже регистрации.

      name:         ietf-datastores
      namespace:    urn:ietf:params:xml:ns:yang:ietf-datastores
      prefix:       ds
      reference:    RFC 8342

      name:         ietf-origin
      namespace:    urn:ietf:params:xml:ns:yang:ietf-origin
      prefix:       or
      reference:    RFC 8342

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

В этом документе обсуждается архитектурная модель для хранилищ данных сетевого управления, используемых протоколами NETCONF/RESTCONF и языком YANG. Это не оказывает влияния на безопасность Internet.

Хотя в этом документе заданы модули YANG, эти модули определяют лишь отождествления и аннотацию метаданных. По этой причине рекомендации по безопасности YANG [YANG-SEC] не используются.

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

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC7952] Lhotka, L., «Defining and Using Metadata with YANG», RFC 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-editor.org/info/rfc7952>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, «Extensible Markup Language (XML) 1.0 (Fifth Edition)», World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

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

[NETMOD-Operational] Bjorklund, M. and L. Lhotka, «Operational Data in NETCONF and YANG», Work in Progress, draft-bjorklund-netmod-operational-00, October 2012.

[OpState-Enhance] Watsen, K., Bierman, A., Bjorklund, M., and J. Schoenwaelder, «Operational State Enhancements for YANG, NETCONF, and RESTCONF», Work in Progress, draft-kwatsen-netmod-opstate-02, February 2016.

[OpState-Modeling] Shakir, R., Shaikh, A., and M. Hines, «Consistent Modeling of Operational State Data in YANG», Work in Progress, draft-openconfig-netmod-opstate-01, July 2015.

[OpState-Reqs] Watsen, K. and T. Nadeau, «Terminology and Requirements for Enhanced Handling of Operational State», Work in Progress, draft-ietf-netmod-opstate-reqs-04, January 2016.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6244] Shafer, P., «An Architecture for Network Management Using NETCONF and YANG», RFC 6244, DOI 10.17487/RFC6244, June 2011, <https://www.rfc-editor.org/info/rfc6244>.

[RFC8343] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8344] Bjorklund, M., «A YANG Data Model for IP Management», RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.

[With-config-state] Wilton, R., «»With-config-state» Capability for NETCONF/RESTCONF», Work in Progress, draft-wilton-netmod-opstate-yang-02, December 2015.

[YANG-SEC] IETF, «YANG Security Guidelines», <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>.

Приложение A. Рекомендации по определению хранилищ

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

A.1. Определение модулей YANG, применимых для хранилища

Для хранилища данных могут быть применимы не все модули YANG. Некоторые хранилища могут вносить ограничения на использование моделей данных. Если для хранилища желательно целевое использование некоторого подмножества, документация должна указывать это.

A.2. Определение применимого подмножества операторов YANG

По умолчанию данные в хранилище моделируются с использованием всех операторов YANG в доступных модулях YANG. Однако возможно задание критериев, которым должны удовлетворять операторы YANG для включения в хранилище. Например, могут разрешаться только узлы config true или узлы config false, имеющие конкретное расширение YANG.

A.3. Определение способов актуализации данных

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

Например, рисунок 2 показывает хранилища динамической конфигурации, подаваемые в хранилище <operational>. Способ такой передачи определяет конкретным хранилищем динамической конфигурации. В некоторых случаях это может происходить неявно просто при попадании данных в хранилище динамической конфигурации, а в других случаях может потребоваться явное действие (например, RPC).

A.4. Определение применимых протоколов

По умолчанию предполагается что взаимодействие с хранилищами может выполняться с обоими протоколами NETCONF и RESTCONF. Однако можно задать использование лишь одного конкретного протокола (например, ForCES5), подмножества операций протокола или доступных возможностей (например, без блокировки или фильтрации по XPath).

A.5. Определение отождествлений YANG для хранилища

Хранилище жлджно быть определено с использованием отождествления YANG, использующего ds:datastore или одно из производных от него отождествлений. Это отождествление требуется, чтобы по по нему можно было ссылаться на хранилище в операциях протокола (например, <get-data>).

Хранилище может быть также определено с использованием в качестве базы отождествления or:origin или производного от него отождествления. Такое отождествление требуется, если хранилище взаимодействует с <operational>, чтобы по нему можно указать хранилище в атрибуте метаданных origin, определенном в разделе 7.

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

Приложение B. Пример эфемерного хранилища

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

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

Свойства примера «эфемерного» хранилища

Имя

Значение

Name

ephemeral

YANG modules

all (default)

YANG nodes

all «config true» data nodes

How applied

changes automatically propagated to <operational>

Protocols

NETCONF/RESTCONF (default)

Defining YANG module

«example-ds-ephemeral»

   module example-ds-ephemeral {
     yang-version 1.1;
     namespace "urn:example:ds-ephemeral";
     prefix eph;

     import ietf-datastores {
       prefix ds;
     }
     import ietf-origin {
       prefix or;
     }

     // datastore identity
     identity ds-ephemeral {
       base ds:dynamic;
       description
         "The ephemeral dynamic configuration datastore.";
     }

     // origin identity
     identity or-ephemeral {
       base or:dynamic;
       description
         "Denotes data from the ephemeral dynamic configuration
          datastore.";
     }
   }

Приложение C. Примеры

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

Фрагменты XML [W3C.REC-xml-20081126] представлены лишь для иллюстрации.

C.1. Пример хранилища System

Ниже показан используемый в примере функциональный модуль.

   module example-system {
     yang-version 1.1;
     namespace urn:example:system;
     prefix sys;

     import ietf-inet-types {
       prefix inet;
     }

     container system {
       leaf hostname {
         type string;
       }

       list interface {
         key name;

         leaf name {
           type string;
         }

         container auto-negotiation {
           leaf enabled {
             type boolean;
             default true;
           }
           leaf speed {
             type uint32;
             units mbps;
             description
               "The advertised speed, in Mbps.";
           }
         }

         leaf speed {
           type uint32;
           units mbps;
           config false;
           description
             "The speed of the interface, in Mbps.";
         }

         list address {
           key ip;

           leaf ip {
             type inet:ip-address;
           }
           leaf prefix-length {
             type uint8;
           }
         }
       }
     }
   }

Оператор настроил имя хоста и два интерфейса и хранилище <intended> имеет вид

   <system xmlns="urn:example:system">

     <hostname>foo.example.com</hostname>

     <interface>
       <name>eth0</name>
       <auto-negotiation>
         <speed>1000</speed>
       </auto-negotiation>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface>
       <name>eth1</name>
       <address>
         <ip>2001:db8::20</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

   </system>

Система обнаружила, что аппаратная часть одного из настроенных интерфейсов (eth1) еще отсутствует, поэтому настройка данного интерфейса не была применена. После этого система получила имя хоста и дополнительный адрес IP для eth0 по протоколу DHCP. В дополнение к установке принятого по умолчанию значения для листа управления автоматическим согласованием (auto-negotiation) в системе также автоматически создан интерфейс loopback. Все упомянутое нашло отражение в хранилище <operational>. Отметим, что атрибут метаданных origin для некоторых узлов данных config true унаследован от их родителей.

   <system
       xmlns="urn:example:system"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

     <hostname or:origin="or:learned">bar.example.com</hostname>

     <interface or:origin="or:intended">
       <name>eth0</name>
       <auto-negotiation>
         <enabled or:origin="or:default">true</enabled>
         <speed>1000</speed>
       </auto-negotiation>
       <speed>100</speed>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
       <address or:origin="or:learned">
         <ip>2001:db8::1:100</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface or:origin="or:system">
       <name>lo0</name>
       <address>
         <ip>::1</ip>
         <prefix-length>128</prefix-length>
       </address>
     </interface>

   </system>

C.2. Пример BGP

Рассмотрим фрагмент функционального модуля BGP

       container bgp {
         leaf local-as {
           type uint32;
         }
         leaf peer-as {
           type uint32;
         }
         list peer {
           key name;
           leaf name {
             type inet:ip-address;
           }
           leaf local-as {
             type uint32;
             description
               "... Defaults to ../local-as.";
           }
           leaf peer-as {
             type uint32;
             description
               "... Defaults to ../peer-as.";
           }
           leaf local-port {
             type inet:port;
           }
           leaf remote-port {
             type inet:port;
             default 179;
           }
           leaf state {
             config false;
             type enumeration {
               enum init;
               enum established;
               enum closing;
             }
           }
         }
       }

В этой модели оба узла bgp/peer/local-as и bgp/peer/peer-as имеют комплексные иерархические значения, позволяя пользователю задать используемые по умолчанию значения для всех партнеров в одном месте.

Модель также следует шаблону полного объединения узлов состояния (config false) и узлов конфигурации (config true). Здесь нет отдельной иерархии bgp-state и связанного с ней повтора узлов сдерживания ограничений и именования. Это делает модель более простой и удобочитаемой.

C.2.1. Хранилища данных

Каждое хранилище дает разные представления этих узлов. Хранилище <running> будет содержать конфигурацию, заданную оператором (например, один партнер BGP). Хранилище <intended> концептуально будет содержать все проверенные на пригодность данные после исключения не предназначенных для такой проверки данных и выполнения всех локальных механизмов преобразования шаблонов. Хранилище <operational> будет показывать данные из <intended>, а также все узлы config false.

C.2.2. Добавление партнера

Если уператор указал одного партнера BGP, этот партнер будет виден в обоих хранилищах <running> и <intended>. Он может также присутствовать в <candidate>, если сервер поддерживает хранилище для будущих конфигураций. Поиск партнера будет возвращать только заданные пользователем значения.

Между появлением партнера в хранилищах <running> и <intended> не должно быть задержки.

Добавим в хранилище <running> представленную ниже информацию.

     <bgp>
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
       </peer>
     </bgp>
C.2.2.1. Хранилище <operational>

Операционное хранилище будет содержать полностью раскрытые данные партнера, включая узлы config false. В нашем примере это означает появление узла state.

Кроме того, хранилище <operational> будет содержать реально используемые (currently in use) значения для всех узлов. Это значит, что local-as и peer-as будут запролнены даже в том случае, когда их значения не заданы в <intended>. При отсутствии bgp/peer/local-as будет использовано значение bgp/local-as, а при отсутствии bgp/peer/peer-as — bgp/peer-as. В операционном представлении это означает, что каждый партнер будет иметь значения для своих local-as и peer-as, даже если эти значения не будут заданы явно, но будут представлены в bgp/local-as и bgp/peer-as.

Каждый из партнеров BGP имеет связанное с ним соединение TCP, использующее значения local-port и remote-port из <intended>. Если эти значения не представлены, они будут выбраны системой. После организации соединения хранилище <operational> будет содержать текущие значения для local-port и remote-port, независимо от их происхождения. Если значения выбраны системой, атрибут origin будет указывать system. Перед организацией соединения один или оба узла могут отсутствовать, поскольку система может еще не иметь их значений.

     <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
          or:origin="or:intended">
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
         <local-as or:origin="or:default">64501</local-as>
         <peer-as or:origin="or:default">64502</peer-as>
         <local-port or:origin="or:system">60794</local-port>
         <remote-port or:origin="or:default">179</remote-port>
         <state>established</state>
       </peer>
     </bgp>

C.2.3. Удаление партнера

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

Рассмотрим сценарий с удалением партнера BGP. В этом случае операционное состояние будет по-прежнему отражать наличие этого партнера до тех пор, пока не будут освобождены ресурсы закрываемого партнерского соединения. В течение переходного периода текущие значения данных будут видны в хранилище <operational> с атрибутом origin, указывающим происхождение исходных данных.

     <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
          or:origin="or:intended">
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
         <local-as or:origin="or:default">64501</local-as>
         <peer-as or:origin="or:default">64502</peer-as>
         <local-port or:origin="or:system">60794</local-port>
         <remote-port or:origin="or:default">179</remote-port>
         <state>closing</state>
       </peer>
     </bgp>

После освобождения ресурсов и закрытия соединения данные о партнере удаляются из хранилища <operational>.

C.3. Пример интерфейса

В этом параграфе используется простая модель данных интерфейса.

     container interfaces {
       list interface {
         key name;
         leaf name {
           type string;
         }
         leaf description {
           type string;
         }
         leaf mtu {
           type uint16;
         }
         leaf-list ip-address {
           type inet:ip-address;
         }
       }
     }

C.3.1. Заранее представленные интерфейсы

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

Если клиент создает интерфейс et-0/0/0, которого в этот момент нет физически, хранилище <intended> может содержать представленную ниже информацию.

     <interfaces>
       <interface>
         <name>et-0/0/0</name>
         <description>Test interface</description>
       </interface>
     </interfaces>

Поскольку интерфейса нет, эти данные не будут присутствовать в хранилище <operational>.

При установке FRU с этим интерфейсом система обнаружит его и обработает соответствующую конфигурацию. Хранилище <operational> будет содержать данные из <intended>, а также узлы, добавленные системой типа текущего значения MTU для интерфейса.

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>et-0/0/0</name>
         <description>Test interface</description>
         <mtu or:origin="or:system">1500</mtu>
       </interface>
     </interfaces>

Если FRU удаляется, данные интерфейса исключаются из хранилища <operational>.

C.3.2. Предоставляемые системой интерфейсы

Рассмотрим систему, предоставляющую петлевой интерфейс lo0 с принятым по умолчанию адресом IPv4 127.0.0.1 и IPv6 ::1. Система будет обеспечивать конфигурацию для этого интерфейса, если для него нет данных в <intended>.

При отсутствии конфигурации для lo0 в хранилище <intended>, <operational> будет показывать предоставляемые системой данные.

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface or:origin="or:system">
         <name>lo0</name>
         <ip-address>127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

Если конфигурация для lo0 имеется в <intended>, хранилище <operational> будет показывать эти данные с источником intended. Если значение ip-address не было задано, предоставленные системой значения будут иметь вид

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>lo0</name>
         <description>loopback</description>
         <ip-address or:origin="or:system">127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

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

Этот документ является результвтом многочисленных обсуждений, тянувшихся с 2010 года. Проблемы исходной модели хранилищ данных были рассмотрены в NETMOD-Operational] [With-config-state] [OpState-Reqs] [OpState-Enhance] [OpState-Modeling], а также [RFC6244]. Перечисленные ниже люди были авторами этих работ или внесли какой-либо иной вклад в создание этого документа.

Работа Juergen Schoenwaelder частично финансировалась в рамках Flamingo — проекта Network of Excellence (ICT-318488), поддерживаемого Европейской комиссией про программе Seventh Framework.

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

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com

Juergen Schoenwaelder

Jacobs University

Email: j.schoenwaelder@jacobs-university.de

Phil Shafer

Juniper Networks

Email: phil@juniper.net

Kent Watsen

Juniper Networks

Email: kwatsen@juniper.net

Robert Wilton

Cisco Systems

Email: rwilton@cisco.com


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

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

nmalykh@gmail.com

1Network Configuration Protocol — протокол настройки сети.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4XML Path Language — язык путей XML.

5Forwarding and Control Element Separation — разделение элементов пересылки и управления.

6Field Replaceable Unit — заменяемый в процессе работы блок.




RFC 8344 A YANG Data Model for IP Management

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8344                                Tail-f Systems
Obsoletes: 7277                                               March 2018
Category: Standards Track
ISSN: 2070-1721

Модель данных YANG для управления IP

A YANG Data Model for IP Management

PDF

Тезисы

Этот документ определяет модель данных YANG для управления реализациями IP. Модель включает данные конфигурации и состояния системы.

Модель данных YANG в этом документе соответствует архитектуре хранилища данных сетевого управления NMDA1, определенной в RFC 8342.

Документ отменяет действие RFC 7277.

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

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

Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

Авторские права (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).

1. Введение

Этот документ определяет модель данных YANG [RFC7950] для управления реализациями IP.

Модель данных охватывает конфигурацию параметров IPv4 и IPv6 на уровне интерфейсов, а также отображение адресов IP на адреса канального уровня. Модель также дает информацию об используемых в работе адресах IP и имеющихся отображениях канального уровня. Параметры на уровне интерфейсов добавлены путем дополнения (augmentation) модели данных интерфейса, определенной в [RFC8343].

Эта версия модели данных IP поддерживает архитектуру хранилищ NMDA [RFC8342].

1.1. Отличия от RFC 7277

Ветви (subtree) ipv4 и ipv6 с узлами данных config false в ветви /interfaces-state/interface отменены. Все узлы данных config false сейчас присутствуют в ветвях ipv4 и ipv6 субдерева /interfaces/interface.

Серверы, не поддерживающие NMDA или желающие работать с клиентами, не поддерживающими NMDA, могут реализовать отмененные ветви ipv4 и ipv6 в субдереве /interfaces-state/interface.

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

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

Перечисленные ниже термины определены в [RFC8342] и не определяются здесь заново.

  • client (клиент);

  • server (сервер);

  • configuration (конфигурация);

  • system state (состояние системы);

  • intended configuration (предполагаемая конфигурация);

  • running configuration datastore (хранилище данных рабочей конфигурации);

  • operational state (операционное состояние);

  • operational state datastore (хранилище данных операционного состояния).

Перечисленные ниже термины определены в [RFC7950] и не определяются здесь заново.

  • augment (дополнение, усиление);

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

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

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

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

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

2. Модель данных IP

Этот документ определяет модуль YANG ietf-ip, который дополняет списки interface, определенные в модуле ietf-interfaces [RFC8343], связанными с IP узлами данных.

Структура узлов данных IP на уровне интерфейса, за исключением отмененных полей данных, приведена ниже.

   module: ietf-ip
     augment /if:interfaces/if:interface:
       +--rw ipv4!
       |  +--rw enabled?      boolean
       |  +--rw forwarding?   boolean
       |  +--rw mtu?          uint16
       |  +--rw address* [ip]
       |  |  +--rw ip               inet:ipv4-address-no-zone
       |  |  +--rw (subnet)
       |  |  |  +--:(prefix-length)
       |  |  |  |  +--rw prefix-length?   uint8
       |  |  |  +--:(netmask)
       |  |  |     +--rw netmask?         yang:dotted-quad
       |  |  |             {ipv4-non-contiguous-netmasks}?
       |  |  +--ro origin?          ip-address-origin
       |  +--rw neighbor* [ip]
       |     +--rw ip                    inet:ipv4-address-no-zone
       |     +--rw link-layer-address    yang:phys-address
       |     +--ro origin?               neighbor-origin
       +--rw ipv6!
          +--rw enabled?                     boolean
          +--rw forwarding?                  boolean
          +--rw mtu?                         uint32
          +--rw address* [ip]
          |  +--rw ip               inet:ipv6-address-no-zone
          |  +--rw prefix-length    uint8
          |  +--ro origin?          ip-address-origin
          |  +--ro status?          enumeration
          +--rw neighbor* [ip]
          |  +--rw ip                    inet:ipv6-address-no-zone
          |  +--rw link-layer-address    yang:phys-address
          |  +--ro origin?               neighbor-origin
          |  +--ro is-router?            empty
          |  +--ro state?                enumeration
          +--rw dup-addr-detect-transmits?   uint32
          +--rw autoconf
             +--rw create-global-addresses?        boolean
             +--rw create-temporary-addresses?     boolean
             |       {ipv6-privacy-autoconf}?
             +--rw temporary-valid-lifetime?       uint32
             |       {ipv6-privacy-autoconf}?
             +--rw temporary-preferred-lifetime?   uint32
                     {ipv6-privacy-autoconf}?

Модель определяет для интерфейса два контейнера — ipv4 и ipv6, представляющие семейства адресов IPv4 и IPv6. В каждом контейнере имеется лист enabled, который показывает разрешено ли семейство адресов на данном интерфейсе, и лист forwarding, показывающий разрешена ли пересылка пакетов IP данного семейства на этом интерфейсе. В каждом контейнере имеется также список адресов и список отображений адресов IP на адреса канального уровня.

3. Связь с IP-MIB

Если устройство реализует IP-MIB [RFC4293], каждая запись в списках ipv4/address и ipv6/address отобрахается в один из объектов ipAddressEntry, где ipAddressIfIndex указывает address в объеке для интерфейса.

IP-MIB определяет объекты для управления сообщениями IPv6 Router Advertisement. Соответствующие узла данных YANG определены в [RFC8022].

Записи ipv4/neighbor и ipv6/neighbor отображаются на ipNetToPhysicalTable.

Ниже приведена таблица соответствия узлов данных YANG объектам IP-MIB.

Узлы данных YANG для интерфейса и связанные объекты IP-MIB.

Узел данных YANG в /if:interfaces/if:interface

Объект IP-MIB

ipv4

ipv4InterfaceEnableStatus

ipv4/enabled

ipv4InterfaceEnableStatus

ipv4/address

ipAddressEntry

ipv4/address/ip

ipAddressAddrType

ipAddressAddr

ipv4/neighbor

ipNetToPhysicalEntry

ipv4/neighbor/ip

ipNetToPhysicalNetAddressType

ipNetToPhysicalNetAddress

ipv4/neighbor/link-layer-address

ipNetToPhysicalPhysAddress

ipv4/neighbor/origin

ipNetToPhysicalType

ipv6

ipv6InterfaceEnableStatus

ipv6/enabled

ipv6InterfaceEnableStatus

ipv6/forwarding

ipv6InterfaceForwarding

ipv6/address

ipAddressEntry

ipv6/address/ip

ipAddressAddrType

ipAddressAddr

ipv4/address/origin

ipAddressOrigin

ipv6/address/status

ipAddressStatus

ipv6/neighbor

ipNetToPhysicalEntry

ipv6/neighbor/ip

ipNetToPhysicalNetAddressType

ipNetToPhysicalNetAddress

ipv6/neighbor/link-layer-address

ipNetToPhysicalPhysAddress

ipv6/neighbor/origin

ipNetToPhysicalType

ipv6/neighbor/state

ipNetToPhysicalState

4. Модуль YANG для управления IP

Этот модуль импортирует определения типов (typedef) из [RFC6991] и [RFC8343], а они ссылаются на [RFC791], [RFC826], [RFC4861], [RFC4862], [RFC4941], [RFC7217] и [RFC8200].

   <CODE BEGINS> file "ietf-ip@2018-02-22.yang"
   module ietf-ip {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ip";
     prefix ip;

     import ietf-interfaces {
       prefix if;
     }
     import ietf-inet-types {
       prefix inet;
     }
     import ietf-yang-types {
       prefix yang;
     }

     organization
       "IETF NETMOD (Network Modeling) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
        WG List:  <mailto:netmod@ietf.org>

        Editor:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>";
     description
       "This module contains a collection of YANG definitions for
        managing IP implementations.

        Copyright (c) 2018 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC 8344; see
        the RFC itself for full legal notices.";

     revision 2018-02-22 {
       description
         "Updated to support NMDA.";
       reference
         "RFC 8344: A YANG Data Model for IP Management";
     }

     revision 2014-06-16 {
       description
         "Initial revision.";
       reference
         "RFC 7277: A YANG Data Model for IP Management";
     }

     /*
      * Функции
      */

     feature ipv4-non-contiguous-netmasks {
       description
         "Indicates support for configuring non-contiguous
          subnet masks.";
     }

     feature ipv6-privacy-autoconf {
       description
         "Indicates support for privacy extensions for stateless address
          autoconfiguration in IPv6.";
       reference
         "RFC 4941: Privacy Extensions for Stateless Address
                    Autoconfiguration in IPv6";
     }

 
    /*
      * Определения типов
      */

     typedef ip-address-origin {
       type enumeration {
         enum other {
           description
             "None of the following.";
         }
         enum static {
           description
             "Indicates that the address has been statically
              configured -- for example, using the Network Configuration
              Protocol (NETCONF) or a command line interface.";
         }
         enum dhcp {
           description
             "Indicates an address that has been assigned to this
              system by a DHCP server.";
         }
         enum link-layer {
           description
             "Indicates an address created by IPv6 stateless
              autoconfiguration that embeds a link-layer address in its
              interface identifier.";
         }
         enum random {
           description
             "Indicates an address chosen by the system at
              random, e.g., an IPv4 address within 169.254/16, a
              temporary address as described in RFC 4941, or a
              semantically opaque address as described in RFC 7217.";
           reference
             "RFC 4941: Privacy Extensions for Stateless Address
                        Autoconfiguration in IPv6
              RFC 7217: A Method for Generating Semantically Opaque
                        Interface Identifiers with IPv6 Stateless
                        Address Autoconfiguration (SLAAC)";
         }
       }
       description
         "The origin of an address.";
     }

     typedef neighbor-origin {
       type enumeration {
         enum other {
           description
             "None of the following.";
         }
         enum static {
           description
             "Indicates that the mapping has been statically
              configured -- for example, using NETCONF or a command line
              interface.";
         }

         enum dynamic {
           description
             "Indicates that the mapping has been dynamically resolved
              using, for example, IPv4 ARP or the IPv6 Neighbor
              Discovery protocol.";
         }
       }
       description
         "The origin of a neighbor entry.";
     }


     /*
      * Узлы данных
      */

     augment "/if:interfaces/if:interface" {
       description
         "IP parameters on interfaces.

          If an interface is not capable of running IP, the server
          must not allow the client to configure these parameters.";

       container ipv4 {
         presence
           "Enables IPv4 unless the 'enabled' leaf
            (which defaults to 'true') is set to 'false'";
         description
           "Parameters for the IPv4 address family.";

         leaf enabled {
           type boolean;
           default true;
           description
             "Controls whether IPv4 is enabled or disabled on this
              interface.  When IPv4 is enabled, this interface is
              connected to an IPv4 stack, and the interface can send
              and receive IPv4 packets.";
         }
         leaf forwarding {
           type boolean;
           default false;
           description
             "Controls IPv4 packet forwarding of datagrams received by,
              but not addressed to, this interface.  IPv4 routers
              forward datagrams.  IPv4 hosts do not (except those
              source-routed via the host).";
         }
         leaf mtu {
           type uint16 {
             range "68..max";
           }
           units "octets";
           description
             "The size, in octets, of the largest IPv4 packet that the
              interface will send and receive.

              The server may restrict the allowed values for this leaf,
              depending on the interface's type.

              If this leaf is not configured, the operationally used MTU
              depends on the interface's type.";
           reference
             "RFC 791: Internet Protocol";
         }
         list address {
           key "ip";
           description
             "The list of IPv4 addresses on the interface.";
           leaf ip {
             type inet:ipv4-address-no-zone;
             description
               "The IPv4 address on the interface.";
           }
           choice subnet {
             mandatory true;
             description
               "The subnet can be specified as a prefix length or,
                if the server supports non-contiguous netmasks, as
                a netmask.";
             leaf prefix-length {
               type uint8 {
                 range "0..32";
               }
               description
                 "The length of the subnet prefix.";
             }

             leaf netmask {
               if-feature ipv4-non-contiguous-netmasks;
               type yang:dotted-quad;
               description
                 "The subnet specified as a netmask.";
             }
           }
           leaf origin {
             type ip-address-origin;
             config false;
             description
               "The origin of this address.";
           }
         }
         list neighbor {
           key "ip";
           description
             "A list of mappings from IPv4 addresses to
              link-layer addresses.

              Entries in this list in the intended configuration are
              used as static entries in the ARP Cache.

              In the operational state, this list represents the ARP
              Cache.";
           reference
             "RFC 826: An Ethernet Address Resolution Protocol";

           leaf ip {
             type inet:ipv4-address-no-zone;
             description
               "The IPv4 address of the neighbor node.";
           }
           leaf link-layer-address {
             type yang:phys-address;
             mandatory true;
             description
               "The link-layer address of the neighbor node.";
           }
           leaf origin {
             type neighbor-origin;
             config false;
             description
               "The origin of this neighbor entry.";
           }
         }
       }

       container ipv6 {
         presence
           "Enables IPv6 unless the 'enabled' leaf
            (which defaults to 'true') is set to 'false'";
         description
           "Parameters for the IPv6 address family.";

         leaf enabled {
           type boolean;
           default true;
           description
             "Controls whether IPv6 is enabled or disabled on this
              interface.  When IPv6 is enabled, this interface is
              connected to an IPv6 stack, and the interface can send
              and receive IPv6 packets.";
         }
         leaf forwarding {
           type boolean;
           default false;
           description
             "Controls IPv6 packet forwarding of datagrams received by,
              but not addressed to, this interface.  IPv6 routers
              forward datagrams.  IPv6 hosts do not (except those
              source-routed via the host).";
           reference
             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
                        Section 6.2.1, IsRouter";
         }
         leaf mtu {
           type uint32 {
             range "1280..max";
           }
           units "octets";
           description
             "The size, in octets, of the largest IPv6 packet that the
              interface will send and receive.

              The server may restrict the allowed values for this leaf,
              depending on the interface's type.

              If this leaf is not configured, the operationally used MTU
              depends on the interface's type.";
           reference
             "RFC 8200: Internet Protocol, Version 6 (IPv6)
                        Specification
                        Section 5";
         }

         list address {
           key "ip";
           description
             "The list of IPv6 addresses on the interface.";

           leaf ip {
             type inet:ipv6-address-no-zone;
             description
               "The IPv6 address on the interface.";
           }
           leaf prefix-length {
             type uint8 {
               range "0..128";
             }
             mandatory true;
             description
               "The length of the subnet prefix.";
           }
           leaf origin {
             type ip-address-origin;
             config false;
             description
               "The origin of this address.";
           }
           leaf status {
             type enumeration {
               enum preferred {
                 description
                   "This is a valid address that can appear as the
                    destination or source address of a packet.";
               }
               enum deprecated {
                 description
                   "This is a valid but deprecated address that should
                    no longer be used as a source address in new
                    communications, but packets addressed to such an
                    address are processed as expected.";
               }
               enum invalid {
                 description
                   "This isn't a valid address, and it shouldn't appear
                    as the destination or source address of a packet.";
               }

               enum inaccessible {
                 description
                   "The address is not accessible because the interface
                    to which this address is assigned is not
                    operational.";
               }
               enum unknown {
                 description
                   "The status cannot be determined for some reason.";
               }

               enum tentative {
                 description
                   "The uniqueness of the address on the link is being
                    verified.  Addresses in this state should not be
                    used for general communication and should only be
                    used to determine the uniqueness of the address.";
               }
               enum duplicate {
                 description
                   "The address has been determined to be non-unique on
                    the link and so must not be used.";
               }
               enum optimistic {
                 description
                   "The address is available for use, subject to
                    restrictions, while its uniqueness on a link is
                    being verified.";
               }
             }
             config false;
             description
               "The status of an address.  Most of the states correspond
                to states from the IPv6 Stateless Address
                Autoconfiguration protocol.";
             reference
               "RFC 4293: Management Information Base for the
                          Internet Protocol (IP)
                          - IpAddressStatusTC
                RFC 4862: IPv6 Stateless Address Autoconfiguration";
           }
         }

         list neighbor {
           key "ip";
           description
             "A list of mappings from IPv6 addresses to
              link-layer addresses.

              Entries in this list in the intended configuration are
              used as static entries in the Neighbor Cache.

              In the operational state, this list represents the
              Neighbor Cache.";
           reference
             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)";

           leaf ip {
             type inet:ipv6-address-no-zone;
             description
               "The IPv6 address of the neighbor node.";
           }
           leaf link-layer-address {
             type yang:phys-address;
             mandatory true;
             description
               "The link-layer address of the neighbor node.

                In the operational state, if the neighbor's 'state' leaf
                is 'incomplete', this leaf is not instantiated.";
           }
           leaf origin {
             type neighbor-origin;
             config false;
             description
               "The origin of this neighbor entry.";
           }
           leaf is-router {
             type empty;
             config false;
             description
               "Indicates that the neighbor node acts as a router.";
           }

           leaf state {
             type enumeration {
               enum incomplete {
                 description
                   "Address resolution is in progress, and the
                    link-layer address of the neighbor has not yet been
                    determined.";
               }
               enum reachable {
                 description
                   "Roughly speaking, the neighbor is known to have been
                    reachable recently (within tens of seconds ago).";
               }
               enum stale {
                 description
                   "The neighbor is no longer known to be reachable, but
                    until traffic is sent to the neighbor no attempt
                    should be made to verify its reachability.";
               }
               enum delay {
                 description
                   "The neighbor is no longer known to be reachable, and
                    traffic has recently been sent to the neighbor.
                    Rather than probe the neighbor immediately, however,
                    delay sending probes for a short while in order to
                    give upper-layer protocols a chance to provide
                    reachability confirmation.";
               }
               enum probe {
                 description
                   "The neighbor is no longer known to be reachable, and
                    unicast Neighbor Solicitation probes are being sent
                    to verify reachability.";
               }
             }
             config false;
             description
               "The Neighbor Unreachability Detection state of this
                entry.";
             reference
               "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
                          Section 7.3.2";
           }
         }

         leaf dup-addr-detect-transmits {
           type uint32;
           default 1;
           description
             "The number of consecutive Neighbor Solicitation messages
              sent while performing Duplicate Address Detection on a
              tentative address.  A value of zero indicates that
              Duplicate Address Detection is not performed on
              tentative addresses.  A value of one indicates a single
              transmission with no follow-up retransmissions.";
           reference
             "RFC 4862: IPv6 Stateless Address Autoconfiguration";
         }
         container autoconf {
           description
             "Parameters to control the autoconfiguration of IPv6
              addresses, as described in RFC 4862.";
           reference
             "RFC 4862: IPv6 Stateless Address Autoconfiguration";

           leaf create-global-addresses {
             type boolean;
             default true;
             description
               "If enabled, the host creates global addresses as
                described in RFC 4862.";
             reference
               "RFC 4862: IPv6 Stateless Address Autoconfiguration
                          Section 5.5";
           }
           leaf create-temporary-addresses {
             if-feature ipv6-privacy-autoconf;
             type boolean;
             default false;
             description
               "If enabled, the host creates temporary addresses as
                described in RFC 4941.";
             reference
               "RFC 4941: Privacy Extensions for Stateless Address
                          Autoconfiguration in IPv6";
           }
           leaf temporary-valid-lifetime {
             if-feature ipv6-privacy-autoconf;
             type uint32;
             units "seconds";
             default 604800;
             description
               "The time period during which the temporary address
                is valid.";
             reference
               "RFC 4941: Privacy Extensions for Stateless Address
                          Autoconfiguration in IPv6
                          - TEMP_VALID_LIFETIME";
           }
           leaf temporary-preferred-lifetime {
             if-feature ipv6-privacy-autoconf;
             type uint32;
             units "seconds";
             default 86400;
             description
               "The time period during which the temporary address is
                preferred.";
             reference
               "RFC 4941: Privacy Extensions for Stateless Address
                          Autoconfiguration in IPv6
                          - TEMP_PREFERRED_LIFETIME";
           }
         }
       }
     }

     /*
      * Унаследованные узлы данных операционных состояний
      */

     augment "/if:interfaces-state/if:interface" {
       status deprecated;
       description
         "Data nodes for the operational state of IP on interfaces.";

       container ipv4 {
         presence
           "Present if IPv4 is enabled on this interface";
         config false;
         status deprecated;
         description
           "Interface-specific parameters for the IPv4 address family.";

         leaf forwarding {
           type boolean;
           status deprecated;
           description
             "Indicates whether IPv4 packet forwarding is enabled or
              disabled on this interface.";
         }
         leaf mtu {
           type uint16 {
             range "68..max";
           }
           units "octets";
           status deprecated;
           description
             "The size, in octets, of the largest IPv4 packet that the
              interface will send and receive.";
           reference
             "RFC 791: Internet Protocol";
         }

         list address {
           key "ip";
           status deprecated;
           description
             "The list of IPv4 addresses on the interface.";

           leaf ip {
             type inet:ipv4-address-no-zone;
             status deprecated;
             description
               "The IPv4 address on the interface.";
           }

           choice subnet {
             status deprecated;
             description
               "The subnet can be specified as a prefix length or,
                if the server supports non-contiguous netmasks, as
                a netmask.";
             leaf prefix-length {
               type uint8 {
                 range "0..32";
               }
               status deprecated;
               description
                 "The length of the subnet prefix.";
             }
             leaf netmask {
               if-feature ipv4-non-contiguous-netmasks;
               type yang:dotted-quad;
               status deprecated;
               description
                 "The subnet specified as a netmask.";
             }
           }
           leaf origin {
             type ip-address-origin;
             status deprecated;
             description
               "The origin of this address.";
           }
         }
         list neighbor {
           key "ip";
           status deprecated;
           description
             "A list of mappings from IPv4 addresses to
              link-layer addresses.

              This list represents the ARP Cache.";
           reference
             "RFC 826: An Ethernet Address Resolution Protocol";

           leaf ip {
             type inet:ipv4-address-no-zone;
             status deprecated;
             description
               "The IPv4 address of the neighbor node.";
           }
           leaf link-layer-address {
             type yang:phys-address;
             status deprecated;
             description
               "The link-layer address of the neighbor node.";
           }
           leaf origin {
             type neighbor-origin;
             status deprecated;
             description
               "The origin of this neighbor entry.";
           }
         }
       }


       container ipv6 {
         presence
           "Present if IPv6 is enabled on this interface";
         config false;
         status deprecated;
         description
           "Parameters for the IPv6 address family.";

         leaf forwarding {
           type boolean;
           default false;
           status deprecated;
           description
             "Indicates whether IPv6 packet forwarding is enabled or
              disabled on this interface.";
           reference
             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
                        Section 6.2.1, IsRouter";
         }
         leaf mtu {
           type uint32 {
             range "1280..max";
           }
           units "octets";
           status deprecated;
           description
             "The size, in octets, of the largest IPv6 packet that the
              interface will send and receive.";
           reference
             "RFC 8200: Internet Protocol, Version 6 (IPv6)
                        Specification
                        Section 5";
         }

         list address {
           key "ip";
           status deprecated;
           description
             "The list of IPv6 addresses on the interface.";

           leaf ip {
             type inet:ipv6-address-no-zone;
             status deprecated;
             description
               "The IPv6 address on the interface.";
           }
           leaf prefix-length {
             type uint8 {
               range "0..128";
             }
             mandatory true;
             status deprecated;
             description
               "The length of the subnet prefix.";
           }
           leaf origin {
             type ip-address-origin;
             status deprecated;
             description
               "The origin of this address.";
           }
           leaf status {
             type enumeration {
               enum preferred {
                 description
                   "This is a valid address that can appear as the
                    destination or source address of a packet.";
               }
               enum deprecated {
                 description
                   "This is a valid but deprecated address that should
                    no longer be used as a source address in new
                    communications, but packets addressed to such an
                    address are processed as expected.";
               }
               enum invalid {
                 description
                   "This isn't a valid address, and it shouldn't appear
                    as the destination or source address of a packet.";
               }

               enum inaccessible {
                 description
                   "The address is not accessible because the interface
                    to which this address is assigned is not
                    operational.";
               }
               enum unknown {
                 description
                   "The status cannot be determined for some reason.";
               }
               enum tentative {
                 description
                   "The uniqueness of the address on the link is being
                    verified.  Addresses in this state should not be
                    used for general communication and should only be
                    used to determine the uniqueness of the address.";
               }
               enum duplicate {
                 description
                   "The address has been determined to be non-unique on
                    the link and so must not be used.";
               }
               enum optimistic {
                 description
                   "The address is available for use, subject to
                    restrictions, while its uniqueness on a link is
                    being verified.";
               }
             }
             status deprecated;
             description
               "The status of an address.  Most of the states correspond
                to states from the IPv6 Stateless Address
                Autoconfiguration protocol.";
             reference
               "RFC 4293: Management Information Base for the
                          Internet Protocol (IP)
                          - IpAddressStatusTC
                RFC 4862: IPv6 Stateless Address Autoconfiguration";
           }
         }

         list neighbor {
           key "ip";
           status deprecated;
           description
             "A list of mappings from IPv6 addresses to
              link-layer addresses.

              This list represents the Neighbor Cache.";
           reference
             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)";

           leaf ip {
             type inet:ipv6-address-no-zone;
             status deprecated;
             description
               "The IPv6 address of the neighbor node.";
           }
           leaf link-layer-address {
             type yang:phys-address;
             status deprecated;
             description
               "The link-layer address of the neighbor node.";
           }
           leaf origin {
             type neighbor-origin;
             status deprecated;
             description
               "The origin of this neighbor entry.";
           }
           leaf is-router {
             type empty;
             status deprecated;
             description
               "Indicates that the neighbor node acts as a router.";
           }
           leaf state {
             type enumeration {
               enum incomplete {
                 description
                   "Address resolution is in progress, and the
                    link-layer address of the neighbor has not yet been
                    determined.";
               }
               enum reachable {
                 description
                   "Roughly speaking, the neighbor is known to have been
                    reachable recently (within tens of seconds ago).";
               }

               enum stale {
                 description
                   "The neighbor is no longer known to be reachable, but
                    until traffic is sent to the neighbor no attempt
                    should be made to verify its reachability.";
               }
               enum delay {
                 description
                   "The neighbor is no longer known to be reachable, and
                    traffic has recently been sent to the neighbor.
                    Rather than probe the neighbor immediately, however,
                    delay sending probes for a short while in order to
                    give upper-layer protocols a chance to provide
                    reachability confirmation.";
               }
               enum probe {
                 description
                   "The neighbor is no longer known to be reachable, and
                    unicast Neighbor Solicitation probes are being sent
                    to verify reachability.";
               }
             }
             status deprecated;
             description
               "The Neighbor Unreachability Detection state of this
                entry.";
             reference
               "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
                          Section 7.3.2";
           }
         }
       }
     }
   }
   <CODE ENDS>

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

Этот документ регистрирует URI в реестре IETF XML Registry [RFC3688]. В соответствии с форматом RFC 3688 выполнены перечисленные ниже регистрации.

      URI: urn:ietf:params:xml:ns:yang:ietf-ip
      Registrant Contact: The NETMOD WG of the IETF.
      XML: N/A; the requested URI is an XML namespace.

Этот документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020].

      Name:         ietf-ip
      Namespace:    urn:ietf:params:xml:ns:yang:ietf-ip
      Prefix:       ip
      Reference:    RFC 8344

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

Описанный в этом документе модуль YANG определяет схему для данных, доступ к которым выполняется с помощью протоколов сетевого управления типа NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный транспортный уровень с обязательной реализациией защищенного транспорта SSH4 [RFC6242]. Нижним уровнем RESTCONF является HTTPS с обязательной для реализацией транспорта TLS [RFC5246].

Модель управления доступом NETCONF [RFC8341] обеспечивает меры по ограничению доступа для отдельных пользователей NETCONF или RESTCONF предопределенным подмножеством всех доступных операций и содержимого NETCONF или RESTCONF.

Многие модели данных, определенные в этом модуле YANG обеспечивают возможность записи, создания и удаления (т. е. по умолчанию установлено config true). Эти узлы данных могут содержать конфиденциальную (sensitive) информацию , а также быть уязвимыми в некоторых сетевых средах. Операции записи (например, edit-config) для таких узлов без подобающей защиты могут оказывать нежелательное воздействие на работу сети. Ниже перечислены ветви (subtree) и узлы данных, которые могут включать конфиденциальную информацию или уязвимости.

ipv4/enabled и ipv6/enabled

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

ipv4/address и ipv6/address

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

ipv4/forwarding и ipv6/forwarding

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

ipv6/autoconf

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

ipv4/mtu и ipv6/mtu

Установка для этих листьев очень малых значений может существенно замедлить работу интерфейсов.

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

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

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, «IPv6 Stateless Address Autoconfiguration», RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, «Privacy Extensions for Stateless Address Autoconfiguration in IPv6», RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., «Using the NETCONF Protocol over Secure Shell (SSH)», RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8341] Bierman, A. and M. Bjorklund, «Network Configuration Access Control Model», STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «Network Management Datastore Architecture (NMDA)», RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8343] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, «Extensible Markup Language (XML) 1.0 (Fifth Edition)», World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

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

[RFC826] Plummer, D., «An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware», STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.

[RFC4293] Routhier, S., Ed., «Management Information Base for the Internet Protocol (IP)», RFC 4293, DOI 10.17487/RFC4293, April 2006, <https://www.rfc-editor.org/info/rfc4293>.

[RFC7217] Gont, F., «A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)», RFC 7217, DOI 10.17487/RFC7217, April 2014, <https://www.rfc-editor.org/info/rfc7217>.

[RFC8022] Lhotka, L. and A. Lindem, «A YANG Data Model for Routing Management», RFC 8022, DOI 10.17487/RFC8022, November 2016, <https://www.rfc-editor.org/info/rfc8022>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., «YANG Tree Diagrams», BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

Прилежение A. Пример отклика NETCONF <get-config>

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

Фрагменты XML [W3C.REC-xml-20081126] в этом и следующем приложении даны лишь в качестве примеров.

   <rpc-reply
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
       message-id="101">
     <data>
       <interfaces
           xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
           xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
         <interface>
           <name>eth0</name>
           <type>ianaift:ethernetCsmacd</type>
           <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
             <address>
               <ip>192.0.2.1</ip>
               <prefix-length>24</prefix-length>
             </address>
           </ipv4>
           <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
             <mtu>1280</mtu>
             <address>
               <ip>2001:db8::10</ip>
               <prefix-length>32</prefix-length>
             </address>
             <dup-addr-detect-transmits>0</dup-addr-detect-transmits>
           </ipv6>
         </interface>
       </interfaces>
     </data>
   </rpc-reply>

Приложение B. Пример отклика NETCONF <get-data>

В этом приложении дан пример отклика на запрос NETCONF <get-data> для хранилища состояния на устройстве, поддерживающем описанную в этом документе модель данных.

В примере используется аннотация origin, определенная в модуле ietf-origin [RFC8342].

   <rpc-reply
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
       message-id="101">
     <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores">
       <interfaces
           xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
           xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
           xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

         <interface or:origin="or:intended">
           <name>eth0</name>
           <type>ianaift:ethernetCsmacd</type>
           <!-- other parameters from ietf-interfaces omitted -->

           <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
             <enabled or:origin="or:default">true</enabled>
             <forwarding or:origin="or:default">false</forwarding>
             <mtu or:origin="or:system">1500</mtu>
             <address>
               <ip>192.0.2.1</ip>
               <prefix-length>24</prefix-length>
               <origin>static</origin>
             </address>
             <neighbor or:origin="or:learned">
               <ip>192.0.2.2</ip>
               <link-layer-address>
                 00:00:5E:00:53:AB
               </link-layer-address>
             </neighbor>
           </ipv4>
           <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
             <enabled or:origin="or:default">true</enabled>
             <forwarding or:origin="or:default">false</forwarding>
             <mtu>1280</mtu>
             <address>
               <ip>2001:db8::10</ip>
               <prefix-length>32</prefix-length>
               <origin>static</origin>
               <status>preferred</status>
             </address>
             <address or:origin="or:learned">
               <ip>2001:db8::1:100</ip>
               <prefix-length>32</prefix-length>
               <origin>dhcp</origin>
               <status>preferred</status>
             </address>
             <dup-addr-detect-transmits>0</dup-addr-detect-transmits>
             <neighbor or:origin="or:learned">
               <ip>2001:db8::1</ip>
               <link-layer-address>
                 00:00:5E:00:53:AB
               </link-layer-address>
               <origin>dynamic</origin>
               <is-router/>
               <state>reachable</state>
             </neighbor>
             <neighbor or:origin="or:learned">
               <ip>2001:db8::4</ip>
               <origin>dynamic</origin>
               <state>incomplete</state>
             </neighbor>
           </ipv6>
         </interface>
       </interfaces>
     </data>
   </rpc-reply>

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

Автор благодарит Jeffrey Lange, Ladislav Lhotka, Juergen Schoenwaelder и Dave Thaler за их полезные комментарии.

Адрес автора

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com


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

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

nmalykh@gmail.com

1Network Management Datastore Architecture.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Secure Shell — защищенная среда выполнения команд.




RFC 8341 Network Configuration Access Control Model

Internet Engineering Task Force (IETF)                        A. Bierman
Request for Comments: 8341                                     YumaWorks
STD: 91                                                     M. Bjorklund
Obsoletes: 6536                                           Tail-f Systems
Category: Standards Track                                     March 2018
ISSN: 2070-1721

Модель управления доступом NETCONF

Network Configuration Access Control Model

PDF

Тезисы

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

Данный документ отменяет RFC 6536.

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

Этот документ является проектом стандарта (Internet Standards Track).

Документ является результатом работы IETF2 и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG3. Дополнительная информация о документах Internet Standard представлена в разделе 2 документа RFC 7841.

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

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

Авторские права (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. Введение

Протоколы NETCONF и RESTCONF не обеспечивают каких-либо стандартных механизмов ограничения доступа пользователей к протокольным операциям и содержимому.

Существует необходимость интероперабельного управления доступом к выбранным администратором частям содержимого NETCONF и RESTCONF в рамках отдельного сервера.

Этот документ решает вопросы управления доступом к операциям и содержимому протоколов NETCONF [RFC6241] и RESTCONF [RFC8040]. Документ включает три основных раздела.

  1. Цели управления доступом.

  2. Модель управления доступом для NETCONF (NACM).

  3. Модель данных YANG (ietf-netconf-acm.yang).

YANG версии 1.1 [RFC7950] добавляет две новых конструкции, для которых требуется специальный контроль доступа. Оператор action похож на оператор rpc, за исключением того, что он размещается в узле данных. Оператор notification также может размещаться в узле данных.

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

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

Приведенные ниже термины определены в [RFC8342] и не переопределяются здесь:

  • datastore — хранилище данных;

  • configuration datastore хранилище конфигурации;

  • conventional configuration datastore традиционное (обычное) хранилище данных конфигурации;

  • candidate configuration datastore хранилище будущей конфигурации, хранилище-кандидат;

  • running configuration datastore хранилище рабочей конфигурации;

  • startup configuration datastore хранилище стартовой конфигурации;

  • operational state datastore хранилище рабочего состояния;

  • client — клиент;

  • server — сервер.

Приведенные ниже термины определены в [RFC6241] и не переопределяются здесь:

  • protocol operation — протокольная операция;

  • session — сессия;

  • user — пользователь.

Приведенные ниже термины определены в [RFC7950] и не переопределяются здесь:

  • action — действие;

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

  • data definition statement — оператор определения данных.

Приведенные ниже термины определены в [RFC8040] и не переопределяются здесь:

  • data resource — ресурс данных;

  • datastore resource — ресурс хранилища данных;

  • operation resource — операционный ресурс;

  • target resource — целевой ресурс.

Приведенный ниже термин определен в [RFC7230] и не переопределяется здесь:

  • request URI — идентификатор запроса.

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

access control – контроль доступа

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

access control model (ACM) – модель контроля доступа

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

access control rule – правило контроля доступа

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

access operation – операция доступа

Способ получения запросом доступа к концептуальному объекту (none — нет, read — чтение, create — создание, delete — удаление, update — обновление или execute — исполнение).

data node hierarchy и иерархия узла данных

Иерархия узлов данных, указывающая конкретный узел action или notification в хранилище данных.

recovery session – сеанс восстановления

Специальная административная сессия, имеющая неограниченный доступ NETCONF без применения каких-либо правил контроля. Механизмы, используемые сервером для определения того, что сеанс является восстановительным, зависят от реализации и выходят за рамки этого документа.

write access – доступ для записи

Общее обозначение операций create, delete и update.

1.2. Отличия от RFC 6536

Процедуры и модель данных NACM были обновлены для поддержки новых возможностей моделирования в версии языка YANG 1.1. Операторы action и notification могут использоваться с узлами данных для определения операций и уведомлений в конкретной модели данных.

Важным применением этих новых операторов YANG является повышение детализации контроля доступа по сравнению с возможностями, предоставляемыми операторами верхнего уровня rpc и notification. Новые операторы action и notification используются внутри узлов данных и доступ к действиям или уведомлениям может быть ограничен для конкретных узлов данных.

Добавлена поддержка протокола RESTCONF, операции которого похожи на протокольные операции NETCONF, что позволило просто сопоставить имеющиеся процедуры и модель данных NACM.

Было разъяснено поведение доступа к узлу данных при совпадении пути для включения соответствующих нисходящих узлов указанного пути.

Разъяснено поведение в части прав доступа к операции <edit-config> для указания того, что право записи не требуется для узлов данных, которые неявно меняются за счет побочных эффектов (типа вычисления операторов YANG when или неявного удаления при создании узла данных в другой ветви оператора YANG choice).

Раздел «Вопросы безопасности» был обновлен в соответствии с документом «YANG module security guidelines» [YANG-SEC]. Отметим, что модуль YANG в этом документе не определяет новых операций RPC.

2. Цели управления доступом

В этом разделе описаны цели разработки модели управления доступом к NETCONF, представленной в разделе 3.

2.1. Точки управления доступом

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

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

Эти точки контроля показаны на рисунке 1 и кратко описаны ниже.

Протокольные операции

Разрешение на вызов конкретных операций протокола.

Хранилище данных

Разрешение считывать и/или изменять конкретные узлы данных внутри хранилища.

Уведомления

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

             +-------------+                 +-------------+
запрос       |протокольная |                 |  доступ к   |
клиента -->  |  операция   | ------------->  | узлу данных |
             | разрешена?  | хранилище данных|  разрешен?  |
             +-------------+ или доступ к    +-------------+
                             данным состояния

             +----------------+
             |  уведомление   |
событие -->  |  разрешено?    |
             +----------------+

Рисунок 1.

2.2. Простота

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

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

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

2.3. Процедурный интерфейс

NETCONF использует модель RPC4 и расширяемый набор протокольных операций. Требуется контроль доступа для любой возможной операции протокола.

2.4. Доступ к хранилищу данных

Необходимо контролировать доступ к конкретным узлам и субдеревьям в хранилище данных независимо от протокольных операций (стандартных или фирменных), используемых для доступа к хранилищу.

2.5. Пользователи и группы

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

В ACM требуется поддержка концепции административных групп, позволяющей четко различать учетные записи администраторов (root account) и других пользователей с меньшими привилегиями. Администратор должен иметь возможность настройки групп.

Необходима возможность передачи полномочий по сопоставлению пользователей с группами централизованному серверу (например, RADIUS [RFC2865] [RFC5607]). Поскольку проверка подлинности выполняется транспортным уровнем и RADIUS выполняет аутентификацию предоставление полномочий сервису одновременно, от транспортного протокола требуется способность сообщать набор имен групп, связанных с пользователем сервера. Администратору необходимо обеспечить возможность отключить использование этих имен групп в ACM.

2.6. Обслуживание

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

2.7. Возможности настройки

Требуются подходящие механизмы настройки и управления, позволяющие упростить администратору все аспекты управления поведением ACM. Для этого нужна стандартная модель данных, подходящая для использования с протокольной операцией <edit-config>. Требуется поддержка правил управления доступом для ограничения доступа к конкретным субдеревьям внутри конфигурационного хранилища.

2.8. Идентификация требующего защиты содержимого

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

Чувствительные в плане безопасности объекты необходимо указывать в разделе RFC «Вопросы безопасности». Это хорошо, но не достаточно в силу приведенных ниже причин.

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

  • Если риски безопасности идентифицированы, администратор должен дополнительно изучить текст RFC и узнать способы снижения рисков.

  • ACM на каждом сервере требуется настроить для снижения рисков безопасности, например, требуя привилегированного доступа к операциям чтения и записи для конкретных данных, указанных в разделе «Вопросы безопасности».

  • Если ACM не настроена заранее, возникает интервал уязвимости между загрузкой новой модели данных а настройкой, включением и отладкой новых правил контроля доступа для этой модели.

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

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

3. Модель управления доступом для NETCONF (NACM)

3.1. Обзор

В этом разделе представлен общий обзор структуры модели управления доступом. Описана модель обработки протокольных сообщений NETCONF и концептуальные требования к контролю доступа в рамках модели.

3.1.1. Свойства

Возможности модели NACM перечислены ниже.

  • Обеспечивается независимый контроль доступа к RPC, действиям,данным и уведомлениям.

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

  • Используется просто и понятный набор разрешений для хранилища данных.

  • Поддержка меток безопасности YANG (например, оператор nacm:default-deny-write) позволяет автоматически исключать доступ к чувствительным данным по умолчанию.

  • Обеспечиваются раздельные режимы, используемые по умолчанию для чтения, записи и выполнения.

  • Правила контроля доступа применяются к настраиваемым группам пользователей.

  • Процедуры выполнения контроля доступа могут быть отключены в процессе работы без удаления каких-либо правил (для отлаживания при возникновении проблем).

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

  • Используются простые неограниченные идентификаторы экземпляров YANG для настройки правил доступа к конкретным узлам данных.

3.1.2. Внешние зависимости

Для целей сетевого управления в этом документе используются протоколы NETCONF [RFC6241] и RESTCONF [RFC8040].

Язык моделирования данных YANG [RFC7950] служит для определения моделей данных, используемых с NETCONF или RESTCONF. YANG также используется для моделей данных в этом документе.

3.1.3. Модель обработки сообщения

На рисунке 1 показана концептуальная модель потока сообщений, включая точки, где применяется контроль доступа в процессе обработки сообщений NETCONF.

Операции RESTCONF отображаются на модель контроля доступа по методу HTTP и классу ресурсов, используемому в операции. Например, метод POST для ресурса данных считается доступом для записи в узел, а метод POST для операции считается доступом operation.

Прямоугольник pre-read data node acc. ctl на рисунке указывает групповой доступ для чтения, поскольку он относится к предкам узла данных для действия или уведомления. Например, если действие определено как /interfaces/interface/reset-interface, группа должна иметь полномочия (1) читать /interfaces и /interfaces/interface, а также (2) выполнять /interfaces/interface/reset-interface.

           +-------------------------+
           |        сессия           |
           |      (username)         |
           +-------------------------+
              |                 ^
              V                 |
    +--------------+     +---------------+
    | диспетчер    |     |  генератор    |
    | сообщений    |     |  сообщений    |
    +--------------+     +---------------+
      |      |               ^         ^
      |      V               |         |
      |  +=============+     |         |
      |  | pre-read    |     |         |
      |  | data node   |     |         |
      |  | acc. ctl    |     |         |
      |  +=============+     |         |
      |    |                 |         |
      V    V                 |         |
+===========+     +-------------+   +----------------+
| operation |---> |  генератор  |   |   генератор    |
| acc. ctl  |     |  откликов   |   | <notification> |
+===========+     +-------------+   +----------------+
      |              ^    ^                ^
      V       +------+    |                |
+-----------+ |   +=============+  +================+
| обработчик| |   |    read     |  | <notification> |
| операции  |-+   | data node   |  |  access ctl    |
|           |     | acc. ctl    |  |                |
+-----------+     +=============+  +================+
      |   |                  ^       ^     ^
      V   +----------------+ |       |     |
+===========+              | |       | +============+
|  write    |              | |       | | pre-read   |
| data node |              | |       | | data node  |
| acc. ctl  | -----------+ | |       | | acc. ctl   |
+===========+            | | |       | +============+
      |                  | | |       |   ^
      V                  V V |       |   |
+---------------+      +-------------------+
|   хранилище   | ---> |      server       |
|  конфигурации |      |  instrumentation  |
|               | <--- |                   |
+---------------+      +-------------------+

Рисунок 2.

Приведенная ниже последовательность концептуальных шагов обработки верхнего уровня выполняется для каждого принятого сообщения <rpc> при включенном контроле доступа.

  • Для каждой активной сессии контроль доступа выполняется индивидуально для всех сообщений <rpc> (кроме <close-session>), полученных сервером, если сессия не идентифицирована как восстановительная.

  • Если вызвана операция <action>, определенная в [RFC7950], доступ к чтению требуется для всех экземпляров в иерархии узлов данных, идентифицирующих указанное действие в хранилище данных, а также требуется доступ к исполнению для узла action. Если пользователь не имеет права читать все указанные узлы данных и выполнять действие, запрос отвергается с возвратом ошибки access-denied.

  • В остальных случаях, если пользователь не имеет права выполнять указанную операцию протокола, запрос отвергается с возвратом ошибки access-denied.

  • При осуществлении протокольной операцией доступа к хранилищу данных, сервер проверяет наличие у пользователя полномочий для доступа к узлам этого хранилища. Если пользователь не имеет полномочий для выполнения запрошенной операции доступа, запрос отвергается с возвратом ошибки access-denied.

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

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

  • Если в субдереве данных задан оператор notification, как указано в [RFC7950], доступ к чтению требуется для всех экземпляров в иерархии узлов данных, идентифицирующих указанное уведомление в хранилище данных, а также к чтению узла notification. Если пользователь не имеет полномочий для чтения всех заданных узлов данных и узла notification, уведомление для этой подписки отбрасывается.

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

3.2. Доступ к хранилищу данных

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

Все обычные хранилища данных и рабочее хранилище контролируются NACM. Локальные и удаленные файлы или хранилища, доступ к которым осуществляется через параметр <url>, не контролируются NACM.

3.2.1. Отображение новых хранилищ данных в NACM

Возможно, что с течением времени будут определены новые хранилища данных для использования с NETCONF. NACM может применяться к другим хранилищам, в которых права доступа определены подобно NACM. Для применения NACM к новому хранилищу данных, для такого хранилища должно быть определено отображение на права доступа NACM CRUDX5. Возможно, что применима будет лишь часть прав доступа NACM. Например, для хранилищ с доступом только на чтение могут потребоваться лишь контроль поиска информации. Операции и права доступа, не поддерживающие модель NACM CRUDX, выходят за рамки этого документа. Хранилищу данных не требуется использовать NACM, например, спецификация хранилища может определять другой метод или не применять контроль доступа совсем.

3.2.2. Права доступа

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

Модель CRUDX может поддерживать все протокольные операции:

  • создание — позволяет клиенту добавлять новые экземпляры узлов данных в хранилище;

  • чтение — позволяет клиенту читать экземпляры данных из хранилища или получать уведомления о событиях;

  • обновление — позволяет клиенту обновлять имеющиеся экземпляры узлов данных в хранилище;

  • удаление — позволяет клиенту удалять экземпляры узлов данных из хранилища;

  • eXec — позволяет клиенту выполнять операции.

3.2.3. Методы RESTCONF

Протокол RESTCONF использует методы HTTP для выполнения операций с хранилищами данных, подобно протоколу NETCONF. Процедуры NACM разрабатывались для протокола NETCONF, поэтому методы RESTCONF были отображены на операции NETCONF для целей обработки контроля доступа. Процедуры исполнения правил, описанные в этом документе, применимы к обоим протоколам, если явно не указано иное.

При обработке запросов RESTCONF к ресурсам данных нужно рассматривать URI запросов, как описано ниже.

  • Для запросов HEAD и GET любые узлы данных, являющиеся предками узлов целевого ресурса, для целей контроля доступа считаются частью поискового запроса.

  • Для запросов PUT, PATCH и DELETE любые узлы данных, являющиеся предками узлов целевого ресурса, для целей контроля доступа на считаются частью запроса на редактирование. Операцией доступа для таких запросов считается none (нет операции). The edit begins at the target resource.

  • Для запросов POST к ресурсам данных любые узлы данных, указанные в URI запроса, включая целевой ресурс, для целей контроля доступа не считаются частью запроса на редактирование. Операцией доступа для таких запросов считается none. Редактирование начинается на дочернем узле целевого ресурса, заданного в теле сообщения.

Контроль доступа применяется для всех запросов RESTCONF. В приведенной ниже таблице приведены сопоставления запросов с операциями протокола NETCONF. Значение none показывает, что операция NACM не применяется к данному методу RESTCONF.

Таблица 1. Сопоставление методов RESTCONF с NETCONF.

 

Метод

Класс ресурсов

Операция NETCONF

Операция доступа

OPTIONS

все

none

none

HEAD

все

<get>, <get-config>

read

GET

все

<get>, <get-config>

read

POST

хранилище, данные

<edit-config>

create

POST

операция

заданная операция

execute

PUT

данные

<edit-config>

create, update

PUT

хранилище

<copy-config>

update

PATCH

данные, хранилище

<edit-config>

update

DELETE

данные

<edit-config>

delete

 

3.2.4. Операции <get> и <get-config>

Права доступа NACM не связаны напрямую с протокольными операциями <get> и <get-config>, а применяются ко всем операциям <rpc>, которые приводить к операции read для целевого хранилища данных. В этом параграфе описано, как эти права доступа применяются к конкретным операциям доступа, поддерживаемым протокольными операциями <get> и <get-config>.

Узлы данных, к которым клиент не имеет доступа на чтение, просто опускаются вместе с их потомками из сообщения <rpc-reply>. Это деляется для того, чтобы обеспечить возможность корректной работы фильтров NETCONF для <get> и <get-config> вместо возврата ошибки access-denied в результате срабатывания фильтров при отсутствии полномочий на чтение некоторых узлов данных. Для целей фильтрации NETCONF критерии выбора применяются к подможеству узлов, которые пользователь имеет право читать, а не ко всему хранилищу данных.

3.2.5. Операция <edit-config>

Права доступа NACM не связаны напрямую с атрибутом «операции» <edit-config>, хотя они похожи. Права доступа NACM применяются ко всем протокольным операциям, которые в результате будут приводить к определенной операции доступа к целевому хранилищу данных. В это параграфе описано как эти права доступа применяются к конкретным операциям доступа, поддерживаемым протокольной операцией <edit-config>.

Если реальной операцией доступа для отдельного узла данных является none (т. е. default-operation=none), контроль доступа для этого узла не применяется. Это требуется для того, чтобы разрешить доступ к субдереву в более крупной структуре данных. Например, пользователь может иметь полномочия на создание новых записей в списке /interfaces/interface, но не иметь полномочий для создания или удаления его родительского контейнера (/interfaces). Если контейнер /interfaces уже имеется в целевом хранилище, при редактировании списка /interfaces/interface эффективной операцией для узла /interfaces будет none.

Если протокольная операция будет приводить к созданию узла в хранилище данных, а пользователь не имеет полномочий на операцию create для этого узла, операция будет отвергнута с ошибкой access-denied.

Если протокольная операция будет приводить к удалению узла в хранилище данных, а пользователь не имеет полномочий на операцию delete для этого узла, операция будет отвергнута с ошибкой access-denied.

Если протокольная операция будет приводить к изменению узла в хранилище данных, а пользователь не имеет полномочий на операцию update для этого узла, операция будет отвергнута с ошибкой access-denied.

Операция <edit-config> для слияния или замены может включать узлы данных, которые являются неизменяемой частью имеющегося хранилища данных. Например, узел container или list может служить для именования, но не изменения соответствующего узла в хранилище. Такие неизменяемые узлы данных игнорируются сервером и не требуют от клиента каких-либо прав доступа.

Операция <edit-config> для слияния может включать узлы данных, но не включать отдельные дочерние узлы, которые присутствуют в хранилище. Эти отсутствующие узлы данных в области действия операции слияния <edit-config> игнорируются сервером и не требуют от клиента каких-либо прав доступа.

Содержимое конкретных узлов с ограничениями доступа недопустимо включать в какие-либо элементы откликов <rpc-error>.

Операция <edit-config> может приводить к неявному созданию или удалению узлов в результате неявных побочных эффектов запрошенной операции. Например выражение оператора YANG when может давать разные результаты, в зависимости от которых узлы данных могут создаваться или удаляться или при создании узла данных в одной из ветвей оператора YANG choice узлы в других вариантах этого оператора могут неявно удаляться. Для узлов данных, которые неявно изменяются в результате побочных эффектов другой разрешенной операции, не требуется прав доступа NACM.

3.2.6. Операция <copy-config>

Контроль доступа для операции <copy-config> требует специального рассмотрения, поскольку эта операция позволяет администратору полностью заменить содержимое целевого хранилища.

Если источником протокольной операции <copy-config> является хранилище рабочей конфигурации, а целью — хранилище стартовой конфигурации, от клиента требуется лишь доступ к выполнению операции <copy-config>.

В остальных случаях используются приведенные ниже правила.

  • Если источником операции <copy-config> является хранилище, узлы данных, к которым у клиента нет доступа на чтение, просто опускаются.

  • Если целью операции <copy-config> является хранилище данных, клиенту нужен доступ к обновляемым узлам. В частности должны выполняться приведенные ниже условия.

    • Если протокольная операция ведет к созданию узла в хранилище, а пользователь не имеет для этого узла права на создание (create), протокольная операция отвергается с ошибкой access-denied.

    • Если протокольная операция ведет к удалению узла в хранилище, а пользователь не имеет для этого узла права на удаление (delete), протокольная операция отвергается с ошибкой access-denied.

    • Если протокольная операция ведет к обновлению узла в хранилище, а пользователь не имеет для этого узла права на обновление (update), протокольная операция отвергается с ошибкой access-denied.

3.2.7. Операция <delete-config>

Доступ к протокольной операции <delete-config> по умолчанию отвергается. Лист exec-default не применяется к этой операции протокола. Для разрешения вызова этой операции правила контроля доступа должны быть заданы явно, если сессия не является восстановительной.

3.2.8. Операция <commit>

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

Например, если сессия может читать все хранилище, но изменять лишь один лист, эта сессия должна иметь право редактирования и представления (commit) лишь для этого листа.

3.2.9. Операция <discard-changes>

От клиента требуется лишь право выполнять протокольную операцию <discard-changes>. Прав доступа к хранилищу не требуется.

3.2.10. Операция <kill-session>

Операция <kill-session> не меняет хранилища напрямую, однако она позволяет из одной сессии прервать другую, которая могла редактировать хранилище данных.

Доступ к протокольной операции <kill-session> по умолчанию отвергается. Лист exec-default не применяется к этой операции протокола. Для разрешения вызова этой операции правила контроля доступа должны быть заданы явно, если сессия не является восстановительной.

3.3. Компоненты модели

В этом разделе определены концептуальные компоненты, относящиеся к модели контроля доступа.

3.3.1. Пользователи

Пользователь (user) является концептуальным элементом, с которым связаны полномочия доступа, предоставленные для отдельной сессии. Пользователь указывается строкой (именем), которая уникальна в масштабе сервера.

Как описано в [RFC6241], строка имени пользователя выводится из транспортного уровня в процессе организации сессии. Если транспортный уровень не может проверить подлинность пользователя, сессия прерывается.

3.3.2. Группы

Доступ к конкретной операции протокола NETCONF предоставляется для сессии. Сессия связана с группой (т. е. не с пользователем).

Группы идентифицируются по именам. Имена уникальны в масштабе сервера.

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

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

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

3.3.3. Сеанс восстановления при аварии

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

3.3.4. Глобальные элементы исполнения

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

3.3.4.1. Переключатель enable-nacm

Глобальный переключатель enable-nacm служит для включения и отключения процедур контроля доступа. Когда этот переключатель имеет значение true, все запросы проверяются на соответствие правилам контроля доступа и выполняются только разрешенные запреты на доступ. При значении глобального переключателя false все запросы на доступ разрешены.

3.3.4.2. Переключатель read-default

Переключатель read-default определяет принятый по умолчанию режим доступа к получению данных в откликах и уведомлениях. Когда глобальный переключатель enable-nacm имеет значение true, данный переключатель используется при отсутствии совпадений с правилами контроля доступа, которые явно разрешают или запрещают доступ к запрошенному хранилищу данных или типу уведомления.

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

Когда этот глобальный переключатель имеет значение deny и нет совпадения с правилом контроля доступа к хранилищу для чтения или получения уведомлений о событиях, доступ отвергается. Это означает, что запрошенные данные не будут переданы клиенту (см п. 11 в параграфе 3.4.5).

3.3.4.3. Переключатель write-default

Переключатель write-default определяет принятый по умолчанию режим доступа к изменению конфигурационных данных. Когда глобальный переключатель enable-nacm имеет значение true, данный переключатель используется при отсутствии совпадений с правилами контроля доступа, которые явно разрешают или запрещают доступ для записи в запрошенное хранилище.

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

Когда этот глобальный переключатель имеет значение deny и нет совпадения с правилом контроля доступа к записи в запрошенное хранилище, такой доступ отвергается (см п. 12 в параграфе 3.4.5).

3.3.4.4. Переключатель exec-default

Переключатель exec-default определяет принятый по умолчанию режим доступа к выполнению протокольных операций. Когда глобальный переключатель enable-nacm имеет значение true, данный переключатель используется при отсутствии совпадений с правилами контроля доступа, которые явно разрешают или запрещают доступ к исполнению запрошенной операции протокола NETCONF.

Когда этот глобальный переключатель имеет значение permit и нет совпадения с правилом контроля доступа к запрошенной операции протокола NETCONF, такой доступ разрешен.

Когда этот глобальный переключатель имеет значение deny и нет совпадения с правилом контроля доступа к запрошенной операции протокола NETCONF, такой доступ отвергается (см п. 12 в параграфе 3.4.4 и п. 13 в параграфе 3.4.5).

3.3.4.5. Переключатель enable-external-groups

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

При значении этого переключателя false имена групп, сообщенные транспортным уровнем, игнорируются NACM.

3.3.5. Правила контроля доступа

В NACM доступны 4 типа правил, перечисленные ниже.

module – правило для модуля

Управляет доступом к определениям в модуле YANG, указанном именем.

protocol operation – правило для протокольной операции

Управляет доступом к конкретной операции протокола, указанной именем и модулем YANG.

data node – правило для узла данных

Управляет доступом к конкретному узлу данных (и его потомкам), указанному путем в концептуальном документе XML для узла данных.

Notification – правило для уведомлений

Управляет доступом к конкретному типу уведомлений, указанному именем и модулем YANG.

3.4. Процедуры исполнения контроля доступа

Необходимо выполнить 6 этапов проверки, 4 из которых относятся к модели обработки сообщений NETCONF (параграф 3.1.3):

  1. начальные операции;

  2. организация сессии;

  3. обработка ошибок access-denied;

  4. проверка пригодности входящих сообщений RPC;

  5. проверка доступа к узлу данных;

  6. полномочия для исходящих <notification>.

Кроме того, нужно учитывать стартовый режим сервера NETCONF, организацию сессии, а также процедуры обработки ошибок access-denied.

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

3.4.1. Начальные операции

При первом запуске сервера NETCONF конфигурация контроля доступа может отсутствовать. Если это не так, серверу недопустимо разрешать какой-либо доступ для записи в любой сессии, кроме восстановительной.

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

3.4.2. Организация сессии

Модель контроля доступа применяется к четко сформированному содержимому XML, передаваемому между клиентом и сервером после организации сессии и успешного обмена сообщениями <hello>.

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

3.4.3. Обработка ошибок access-denied

Тег ошибки access-denied генерируется в тех случаях, когда система контроля доступа отвергает запрос на вызов протокольной операции или выполнение той или иной операции доступа к хранилищу конфигурации.

Серверу недопустимо включать какую-либо информацию, которую клиенту не разрешено читать, в элементы <error-info> откликов <rpc-error>.

3.4.4. Проверка входящих сообщений RPC

На рисунке 3 показана базовая концептуальная структура модели обработки контроля доступа для входящих сообщений NETCONF <rpc> на сервере.

         Сервер NETCONF 
         +------------+
         | Диспетчер  |
         | сообщений  |
         |    XML     |
         +------------+
                |
                |
                V
        +---------------+
        |сообщение <rpc>|
        +---------------+
          |    |     |
          |    |     +--------------------------------+
          |    +---------------+                      |
          V                    V                      V
+------------------+ +--------------------+ +--------------------+
|фирменная операция| |стандартная операция| |стандартная операция|
|    <my-edit>     | |   <edit-config>    | |      <unlock>      |
+------------------+ +--------------------+ +--------------------+
            |                 |
            |                 |
            V                 V
           +----------------------+
           |      Хранилище       |
           |    конфигурации      |
           +----------------------+

Рисунок 3.

 

Контроль доступа начинается с диспетчера сообщений.

После проверки сервером пригодности элемента <rpc>, определения пространства имен URI и имени элемента, запрашивающего протокольную операцию сервер проверяет права пользователя на вызов протокольной операции.

Сервер должен отдельно разрешать каждую операцию протокола, выполняя перечисленные ниже шаги.

  1. Если лист enable-nacm имеет значение false, протокольная операция разрешена.

  2. Если запрашивающая сессия определена как восстановительная, протокольная операция разрешена.

  3. Если запрошена операция NETCONF <close-session>, протокольная операция разрешена.

  4. Проверяются все записи group для поиска в них записи user-name, значение которой совпадает с именем пользователя для сделавшей запрос сессии. Если лист enable-external-groups имеет значение true, эти группы добавляются в список групп, предоставленный транспортным уровнем.

  5. Если групп не найдено, переход к п. 10.

  6. Обрабатываются все записи rule-list в порядке их размещения в конфигурации. Если в rule-list элемент leaf-list для групп не совпадает ни с одной из групп пользователя, обрабатывается следующий элемент rule-list.

  7. Для каждого найденного элемента rule-list обрабатываются все записи по порядку, пока не будет найдено правило, соответствующее запрошенной операции доступа. Правило считается соответствующим при выполнении всех перечисленных ниже условий.

    • Лист module-name в правиле имеет значение * или совпадает с именем модуля YANG, где определена протокольная операция.

    • (1) правило не имеет rule-type или (2) rule-type имеет значение protocol-operation, а rpc-name имеет значение * или совпадает с именем запрошенной операции протокола.

    • Лист access-operations в правиле имеет установленный бит exec или специальное значение *.

  8. Если соответствующее правило найдено, проверяется лист action. Если он имеет значение permit, протокольная операция разрешена, в противном случае она отвергается.

  9. Этот пункт соответствует ситуации, когда не найдено совпадающего правила ни в одной записи rule-list.

  10. Если запрошенная протокольная операция определена в модуле YANG, анонсированном в возможностях сервера, и оператор rpc содержит оператор nacm:default-deny-all, протокольная операция отвергается.

  11. Если протокольная операция является операцией протокола NETCONF <kill-session> или <delete-config>, эта операция отвергается.

  12. Если лист exec-default имеет значение permit, протокольная операция разрешена, иначе она отвергается.

Если пользователь не уполномочен вызывать операцию протокола, генерируется сообщение <rpc-error> с приведенной ниже информацией.

error-tag

access-denied

error-path

Указывает запрошенную операцию. Приведенный ниже пример представляет операцию <edit-config> в базовом пространстве имен NETCONF.

         <error-path
           xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
             /nc:rpc/nc:edit-config
         </error-path>

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

3.4.5. Проверка доступа к узлу данных

Если (1) осуществляется доступ к узлу данных или (2) к узлу привязано действие или уведомление, сервер должен гарантировать, что пользователь уполномочен выполнять запрошенную операцию доступа read, create, update, delete или execute для указанного узла данных.

Если запрошено выполнение действия, сервер должен гарантировать, что пользователь уполномочен выполнять операцию доступа execute.

Если генерируется привязанное к узлу уведомление, сервер должен гарантировать, что пользователь уполномочен выполнять операцию доступа read для запрошенного уведомления.

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

  1. Если лист enable-nacm имеет значение false, доступ разрешен.

  2. Если запрашивающая сессия определена как восстановительная, доступ разрешен.

  3. Проверяются все записи group для поиска в них записи user-name, значение которой совпадает с именем пользователя для сделавшей запрос сессии. Если лист enable-external-groups имеет значение true, эти группы добавляются в список групп, предоставленный транспортным уровнем.

  4. Если групп не найдено, переход к п. 9.

  5. Обрабатываются все записи rule-list в порядке их размещения в конфигурации. Если в rule-list элемент leaf-list для групп не совпадает ни с одной из групп пользователя, обрабатывается следующий элемент rule-list.

  6. Для каждого найденного элемента rule-list обрабатываются все записи по порядку, пока не будет найдено правило, соответствующее запрошенной операции доступа. Правило считается соответствующим при выполнении всех перечисленных ниже условий.

    • Лист module-name в правиле имеет значение * или совпадает с именем модуля YANG, где определена протокольная операция.

    • (1) правило не имеет rule-type или (2) rule-type имеет значение data-node, а path соответствует запрашиваемому узлу данных, действия или уведомления. Путь считается соответствующим, если запрошенный узел является узлом, заданным этим путем, или наследником такого узла.

    • Для операции read лист access-operations в правиле имеет установленный бит read или специальное значение *.

    • Для операции create лист access-operations в правиле имеет установленный бит create или специальное значение *.

    • Для операции delete лист access-operations в правиле имеет установленный бит delete или специальное значение *.

    • Для операции update лист access-operations в правиле имеет установленный бит update или специальное значение *.

    • Для операции execute лист access-operations в правиле имеет установленный бит exec или специальное значение *.

  1. Если соответствующее правило найдено, проверяется лист action. Если он имеет значение permit, протокольная операция разрешена, в противном случае она отвергается. Для операции read отказ (denied) означает, что запрошенные данные не возвращаются в отклике.

  2. Этот пункт соответствует ситуации, когда не найдено совпадающего правила ни в одной записи rule-list.

  3. Если запрошенный узел данных для операции read определен в модуле YANG, анонсированном в возможностях сервера и оператор определения данных содержит оператор nacm:default-deny-all, запрошенный узел данных и все его наследники не включаются в отклик.

  4. Если запрошенный узел данных для операции write определен в модуле YANG, анонсированном в возможностях сервера, и оператор определения данных содержит оператор nacm:default-deny-write или nacm:default-deny-all, запрошенная операция отвергается для узла данных и всех его наследников.

  5. Если для операции read лист read-default имеет значение permit, запрошенный узел включается в отклик, в противном случае запрошенный узел и все его потомки не включаются в отклик.

  6. Если для операции write лист write-default имеет значение permit, запрос разрешается, иначе отвергается.

  7. Если для операции execute лист exec-default имеет значение permit, запрос разрешается, иначе отвергается.

3.4.6. Предоставление полномочий для исходящего уведомления

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

Если уведомление задано в субдереве данных, как указано в [RFC7950], требуется доступ для чтения к уведомлению. Обработка продолжается в соответствии с параграфом 3.4.5.

На рисунке 4 показана концептуальная модель обработки для исходящих сообщений <notification>.

      Сервер NETCONF 
      +------------+
      |  Генератор |
      |  сообщений |
      |     XML    |
      +------------+
            ^
            |
    +----------------+
    |   Генератор    |
    | <notification> |
    +----------------+
            ^
            |
   +=================+
   | <notification>  |
   |контроль доступа |
   |  <eventType>    |
   +=================+
            ^
            |
+------------------------+
| Оборудование сервера   |
+------------------------+
          |     ^
          V     |
 +----------------------+
 |      Хранилище       |
 |     конфигурации     |
 +----------------------+

Рисунок 4.


Для генерации уведомления по указанной подписке [RFC5277] полномочия выдаются в соответствии с приведенным ниже описанием.

  1. Если лист enable-nacm имеет значение false, уведомление разрешено.

  2. Если сессия определена как восстановительная, уведомление разрешено.

  3. Если уведомление отосится к типу NETCONF <replayComplete> или <notificationComplete> [RFC5277], оно разрешено.

  4. Проверяются все записи group для поиска в них записи user-name, значение которой совпадает с именем пользователя для сделавшей запрос сессии. Если лист enable-external-groups имеет значение true, эти группы добавляются в список групп, предоставленный транспортным уровнем.

  5. Если групп не найдено, переход к п. 10.

  6. Обрабатываются все записи rule-list в порядке их размещения в конфигурации. Если в rule-list элемент leaf-list для групп не совпадает ни с одной из групп пользователя, обрабатывается следующий элемент rule-list.

  7. Для каждого найденного элемента rule-list обрабатываются все записи по порядку, пока не будет найдено правило, соответствующее запрошенной операции доступа. Правило считается соответствующим при выполнении всех перечисленных ниже условий.

    • Лист module-name в правиле имеет значение * или совпадает с именем модуля YANG, где определено уведомление.

    • (1) правило не имеет rule-type или (2) rule-type имеет значение notification, а notification-name имеет значение * или совпадает с именем уведомления.

    • Лист access-operations в правиле имеет установленный бит read или специальное значение *.

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

  2. Этот пункт соответствует ситуации, когда не найдено совпадающего правила ни в одной записи rule-list.

  3. Если запрошенное уведомление определено в модуле YANG, анонсированном в возможностях сервера, и оператор notification содержит оператор nacm:default-deny-all, уведомление для соответствующей подписки отбрасывается.

  4. Если для лист read-default имеет значение permit, уведомление разрешено, в противном случае оно отвергается.

3.5. Определения модели данных

3.5.1. Организация данных

На приведенном ниже рисунке показана структура и содержимое модуля NACM YANG.

   module: ietf-netconf-acm
     +--rw nacm
        +--rw enable-nacm?              boolean
        +--rw read-default?             action-type
        +--rw write-default?            action-type
        +--rw exec-default?             action-type
        +--rw enable-external-groups?   boolean
        +--ro denied-operations         yang:zero-based-counter32
        +--ro denied-data-writes        yang:zero-based-counter32
        +--ro denied-notifications      yang:zero-based-counter32
        +--rw groups
        |  +--rw group* [name]
        |     +--rw name         group-name-type
        |     +--rw user-name*   user-name-type
        +--rw rule-list* [name]
           +--rw name     string
           +--rw group*   union
           +--rw rule* [name]
              +--rw name                 string
              +--rw module-name?         union
              +--rw (rule-type)?
              |  +--:(protocol-operation)
              |  |  +--rw rpc-name?            union
              |  +--:(notification)
              |  |  +--rw notification-name?   union
              |  +--:(data-node)
              |     +--rw path                 node-instance-identifier
              +--rw access-operations?   union
              +--rw action               action-type
              +--rw comment?             string

3.5.2. Модуль YANG

Приведенный ниже модуль YANG задает нормативное содержимое NETCONF, которое должно поддерживаться сервером.

Модуль YANG ietf-netconf-acm импортирует определения типов из [RFC6991].

   <CODE BEGINS> file "ietf-netconf-acm@2018-02-14.yang"
   module ietf-netconf-acm {

     namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm";

     prefix nacm;

     import ietf-yang-types {
       prefix yang;
     }

     organization
       "IETF NETCONF (Network Configuration) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netconf/> 
        WG List:  <mailto:netconf@ietf.org> 

        Author:   Andy Bierman
                  <mailto:andy@yumaworks.com> 

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>"; 

     description
       "Модель управления доступом NETCONF.

        Copyright (c) 2012 - 2018 IETF Trust and the persons
        identified as authors of the code.  All rights reserved.

        Распространение и использование в исходной или двоичной форме
        с изменениями или без таковых разрешается в соответствии с 
        упрощенной лицензией BSD, изложенной в параграфе 4.c документа
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Данная версия модуля YANG является частью RFC 8341, где правовые
        вопросы рассмотрены более полно.";

     revision "2018-02-14" {
       description
         "Добавлена поддержка действий и уведомлений YANG 1.1, привязанных
          к узлам данных. Уточнено использование расширений NACM в других
          моделях данных.";
       reference
         "RFC 8341: Network Configuration Access Control Model";
     }

     revision "2012-02-22" {
       description
         "Initial version.";
       reference
         "RFC 6536: Network Configuration Protocol (NETCONF)
                    Access Control Model";
     }

     /*
      * Extension statements
      */

     extension default-deny-write {
       description
         "Служит для индикации того, что узел модели данных
          представляет деликатный параметр безопасности системы.

          При наличии этого расширения сервер NETCONF будет разрешать
          запись для узла лишь указанным «сеансам восстановления». Для
          прочих пользователей требуется явное правило контроля доступа.

          Если используется модуль NACM, он должен быть включен (т. е.
          объект /nacm/enable-nacm должен иметь значение true) или это
          расширение будет игнорироваться.

          Расширение default-deny-write МОЖЕТ присутствовать лишь в
          операторе определения данных. В иных случаях оно игнорируется.";
     }

     extension default-deny-all {
       description
         "Используется для указания того, что узел модели данных управляет
          очень деликатным параметром безопасности.

          При наличии этого расширения сервер NETCONF будет разрешать
          запись для узла лишь указанным «сеансам восстановления». Для
          прочих пользователей требуется явное правило контроля доступа.

          Если используется модуль NACM, он должен быть включен (т. е.
          объект /nacm/enable-nacm должен иметь значение true) или это
          расширение будет игнорироваться.

          Расширение default-deny-all МОЖЕТ присутствовать лишь в
          операторе определения данных, операторе rpc или notification.
          statement. В иных случаях оно игнорируется.";
     }

     /*
      * Производные типы
      */

     typedef user-name-type {
       type string {
         length "1..max";
       }
       description
         "Строка общего назначения для имени пользователя.";
     }

     typedef matchall-string-type {
       type string {
         pattern '\*';
       }
       description
         "Строка, содержащая один символ *, используется для 
          представления всех возможных значений отдельного листа,
          использующего этот тип данных.";
     }

     typedef access-operations-type {
       type bits {
         bit create {
           description
             "Любая операция протокола, создающая новый узел данных.";
         }
         bit read {
           description
             "Любая операция протокола или уведомление, возвращающие
              значение узла данных.";
         }
         bit update {
           description
             "Любая операция протокола, изменяющая узел данных.";
         }

         bit delete {
           description
             "Любая операция протокола, удаляющая узел данных.";
         }
         bit exec {
           description
             "Выполнение заданной операции протокола.";
         }
       }
       description
         "Операция доступа.";
     }

     typedef group-name-type {
       type string {
         length "1..max";
         pattern '[^\*].*';
       }
       description
         "Имя группы администраторов, в которую можно назначить
          пользователей.";
     }

     typedef action-type {
       type enumeration {
         enum permit {
           description
             "Запрошенное действие разрешено.";
         }
         enum deny {
           description
             "Запрошенное действие отвергнуто.";
         }
       }
       description
         "Действие, выполняемое сервером при соответствии 
          конкретному правилу.";
     }

     typedef node-instance-identifier {
       type yang:xpath1.0;
       description
         "Путь, используемый для представления строки идентификатора
          специального узла данных, действия или уведомления.

          Значением идентификатора экземпляра узла является
          выражение YANG instance-identifier без ограничений.

          Применяются те же правила, что и instance-identifier,
          за исключением необязательности предикатов ключей. При
          отсутствии предиката node-instance-identifier представляет
          все возможные экземпляры сервера для этого ключа.

          Это выражение XML Path Language (XPath) оценивается в описанном
          ниже контексте.

             -  Набор деклараций пространств имен включает те, что находятся
                в области действия элемента leaf, где используется тип.

             -  Набор привязок переменных содержит одну переменную USER, 
                которая указывает имя пользователя текущей сессии.

             -  Библиотекой функций служит библиотека ядра, но следует
                отметить, что синтаксические ограничения instance-identifier
                не разрешают функций.

             -  Узлом контекста является корневой узел дерева данных.

          Доступное дерево включает действия и уведомления, привязанные
          к узлам данных.";
     }

     /*
      * Операторы определения данных
      */

     container nacm {
       nacm:default-deny-all;

       description
         "Параметры для модели управления доступом NETCONF.";

       leaf enable-nacm {
         type boolean;
         default "true";
         description
           "Разрешает или запрещает выполнение всех операций 
            контроля доступа NETCONF. Значение true включает
            управление, false отключает.";
       }

       leaf read-default {
         type action-type;
         default "permit";
         description
           "Решает вопрос предоставления доступа на чтение при
            отсутствии подходящего правила для конкретного запроса.";
       }

       leaf write-default {
         type action-type;
         default "deny";
         description
           "Решает вопрос предоставления доступа на создание,
            изменение или удаление при отсутствии подходящего
            правила для конкретного запроса.";
       }

       leaf exec-default {
         type action-type;
         default "permit";
         description
           "Решает вопрос предоставления доступа на исполнение при
            отсутствии подходящего правила для конкретного запроса.";
       }

       leaf enable-external-groups {
         type boolean;
         default "true";
         description
           "Задает, будет ли сервер использовать группы, переданные 
            транспортым уровнем NETCONF при назначении пользователя для
            набора групп NACM. Если этот лист имеет значение false, все
            имена групп, сообщенные транспортным уровнем, сервер игнорирует.";
       }

       leaf denied-operations {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Число случаев отказа от выполнения протокольных операций
            с момента последней перезагрузки сервера.";
       }

       leaf denied-data-writes {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Число случаев отказа от выполнения протокольной операции
            изменения хранилища данных  с момента последней 
            перезагрузки сервера.";
       }

       leaf denied-notifications {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Число случаев отказа от предоставления подписки на 
            уведомления с момента последней перезагрузки сервера.";
       }

       container groups {
         description
           "Группы контроля доступа NETCONF.";

         list group {
           key name;

           description
             "Запись для одной группы NACM. Этот список будет 
              включать лишь заданные в конфигурации, а не полученные 
              от транспортных протоколов записи.";

           leaf name {
             type group-name-type;
             description
               "Имя группы, связанной с этой записью.";
           }

           leaf-list user-name {
             type user-name-type;
             description
               "Каждая запись указывает имя пользователя - члена
                группы, связанной с записью.";
           }
         }
       }

       list rule-list {
         key name;
         ordered-by user;
         description
           "Упорядоченный набор правил контроля доступа.";

         leaf name {
           type string {
             length "1..max";
           }
           description
             "Произвольное имя, назначенное для rule-list.";
         }
         leaf-list group {
           type union {
             type matchall-string-type;
             type group-name-type;
           }
           description
             "Список административных групп, которым будут 
              назначены права доступа, заданные списком rule.

              * указывает, что запись применяется ко всем группам.";
         }

         list rule {
           key name;
           ordered-by user;
           description
             "Одно правило управления доступом.

              Правила обрабатываются в заданном пользователем порядке до 
              первого совпадения. Совпадением считается соответствие 
              module-name, rule-type и access-operations запросу. Если
              правило соответствует, лист action определяет 
              предоставление доступа.";

           leaf name {
             type string {
               length "1..max";
             }
             description
               "Произвольное имя, назначенное для правила.";
           }

           leaf module-name {
             type union {
               type matchall-string-type;
               type string;
             }
             default "*";
             description
               "Имя модуля, связанного с данным правилом.

                Этот лист дает совпадение, если он имеет значение * или 
                объект, требующий доступа, определен в модуле с заданным 
                именем.";
           }
           choice rule-type {
             description
               "Этот выбор будет соответствовать, если все листья в правиле
                соответствуют запросу. При отсутствии листьев выбор 
                соответствует всем запросам.";
             case protocol-operation {
               leaf rpc-name {
                 type union {
                   type matchall-string-type;
                   type string;
                 }
                 description
                   "Этот лист (leaf) считается соответствующим, если он имеет 
                    значение * или его значение совпадает с именем запрошенной
                    протокольной операции.";
               }
             }
             case notification {
               leaf notification-name {
                 type union {
                   type matchall-string-type;
                   type string;
                 }
                 description
                   "Этот лист (leaf) считается соответствующим, если он имеет 
                    значение * или его значение совпадает с именем запрошенного
                    уведомления.";
               }
             }

             case data-node {
               leaf path {
                 type node-instance-identifier;
                 mandatory true;
                 description
                   "Идентификатор экземпляра, связанный с узлом данных,
                    действием или уведомлением, контролируемым данным
                    правилом.

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

                    Специальное значение / указывает все содержимое хранилища.";
               }
             }
           }

           leaf access-operations {
             type union {
               type matchall-string-type;
               type access-operations-type;
             }
             default "*";
             description
               "Операции доступа, связанные с этим правилом.

                Лист будет соответствовать, если он имеет значение * или
                бит, соответствующий запрашиваемой операции, установлен.";
           }

           leaf action {
             type action-type;
             mandatory true;
             description
               "Действие по управлению доступом, связанное с правилом.
                Если определено, что правило соответствует конкретному
                запросу, этот объект указывает, принимается или 
                отвергается запрос.";
           }

           leaf comment {
             type string;
             description
               "Текстовое описание правила доступа.";
           }
         }
       }
     }
   }

   <CODE ENDS>

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

Этот документ повторно использует URI для ietf-netconf-acm в реестре IETF XML.

Документ обновляет регистрацию модуля в реестре YANG Module Names ссылкой на данный RFC вместо RFC 6536 для ietf-netconf-acm. В соответствии с форматом в [RFC6020] регистрируются приведенные ниже параметры.

        Name: ietf-netconf-acm
        Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm
        Prefix: nacm
        Reference: RFC 8341

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

Описанный в этом документе модуль YANG определяет схему для данных, которая разработана для обеспечения доступа с помощью протоколов сетевого управления типа NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный транспорт и обязательным для реализации является защищенный транспорт SSH6 [RFC6242]. Нижним уровнем RESTCONF является протокол HTTPS и обязательный для реализации транспорт TLS [RFC5246].

Модель контроля доступа NETCONF [RFC8341] обеспечивает способы ограничения доступа для отдельных пользователей NETCONF или RESTCONF к предопределенному подмножеству всех доступных протокольных операций и содержимого NETCONF или RESTCONF.

Имеется риск, связанный с недостаточным контролем доступа для опций RESTCONF и методов PATCH. Риск заключается в том, что отклик на OPTIONS и PATCH может варьироваться в зависимости от наличия или отсутствия ресурса, соответствующего пути URL. Это может быть использовано для тривиальной проверки наличия или отсутствия значений в дереве. Поэтому серверу недопустимо менять свои отклики в зависимости от существования ресурса, что может показать наличие или отсутствие экземпляров ресурса. В частности, не следует выдавать какую-либо информацию об экземпляре без уверенности в том, что клиент имеет полномочия, требуемые для такого доступа. Предполагается, что сервер всегда возвращает отклик об ошибке access-denied.

Для многих узлов данных, определенных в этом модуле YANG, возможна запись/создание/удаление (т. е. config имеет значение true, установленное по умолчанию). Такие узлы могут считаться чувствительными или уязвимыми в некоторых сетевых средах. Операции записи (например, edit-config) в такие узлы без надлежащей защиты могут оказывать негативное влияние на работу сети. Ниже перечислены субдеревья и узлы данных с указанием их чувствительности/уязвимости:

  • /nacm: все субдерево /nacm связано с безопасностью (см. подробности в последующих параграфах).

Далее очерчены вопросы, которые администратору нужно рассмотреть при настройке сервера NETCONF с NACM.

5.1. Настройка и мониторинг NACM

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

По умолчанию выполнение NACM включено. По умолчанию доступ read разрешен для всего содержимого хранилища данных (пока в определении данных не задано nacm:default-deny-all), доступ exec разрешен для безопасных операций протокола. Администратор должен обеспечить включение NACM, а также решить, правильно ли настроены принятые по умолчанию параметры. Нужно убедиться в корректности настройки перечисленных ниже узлов данных и параметров:

  • /nacm/enable-nacm (по умолчанию true)

  • /nacm/read-default (по умолчанию permit)

  • /nacm/write-default (по умолчанию deny)

  • /nacm/exec-default (по умолчанию permit)

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

Если разрешена запись для настройки конфигурации правил контроля доступа, нужны меры предотвращения нарушений при выполнении правил контроля доступа. Например, если правила контроля доступа NACM нужно редактировать напрямую в хранилище рабочей конфигурации (т. е. поддерживается и применяется возможность writable-running), нужно принять меры предотвращения непреднамеренного доступа во время редактирования.

Администратор должен убедиться, что трансляция зависящего от транспорта или реализации отождествления пользователя в имя пользователя NACM однозначна и корректна. Это требование подробно описано в параграфе 2.2 [RFC6241].

Администратор должен знать, что структуры данных YANG, представляющие правила контроля доступа (/nacm/rule-list и /nacm/rule-list/rule), упорядочены клиентом. Сервер будет проверять правила контроля доступа в соответствии с их относительным концептуальным порядком в хранилище рабочей конфигурации.

Отметим, что структура данных /nacm/groups содержит имена административных групп, используемых сервером. Эти имена групп могут настраиваться локально и/или через внешний протокол типа RADIUS [RFC2865] [RFC5607].

Для определения имен групп администратор должен понимать свойства безопасности всех внешних протоколов, используемых транспортным уровнем. Например, если протокол не обеспечивает защиты от MITM-атак7, атакующий может подставить имена групп, которые будут затем включены в конфигурацию NACM так, что пользователь получит избыточные полномочия. В таких случаях администратор может отключить такие имена групп, установив для /nacm/enable-external-groups значение false.

Некоторые из доступных для чтения узлов данных в этом модуле YANG могут оказаться чувствительными или уязвимыми в отдельных сетевых средах. Для таких узлов важно контролировать доступ на чтение (например, с помощью get, get-config или notification). Ниже перечислены чувствительные/уязвимые субдеревья и узлы данных:

  • /nacm/enable-nacm

  • /nacm/read-default

  • /nacm/write-default

  • /nacm/exec-default

  • /nacm/enable-external-groups

  • /nacm/groups

  • /nacm/rule-list

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

5.2. Общие вопросы настройки конфигурации

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

Для сессии с некоторыми правами записи (например, вызов <edit-config>), но без какого-либо доступа к конкретному субдереву с конфиденциальными данными можно определить наличие или отсутствие таких данных. Это можно сделать путем повторяющихся вызовов некой операции редактирования (создание, обновление или удаление) с возможным получением отклика access-denied. Такая «ловля на живца» может определить наличие или отсутствие конкретных чувствительных данных даже без наличия поля error-path в отклике <rpc-error>.

Набор возможностей сервера NETCONF может меняться с течением времени. В таких случаях возникает риск добавления на устройстве новых протокольных операций, уведомлений и/или содержимого хранилища. Администратор должен убедиться в том, что правила контроля доступа в этом случае подходят для новых условий. Механизмы обнаружения смены возможностей NETCONF на конкретном устройстве выходят за рамки документа.

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

Возможно, что само определение модели данных (например, оператор YANG when или choice) позволит сессии неявно создавать или удалять узлы, для которых сессия не имеет прав записи, за счет побочных эффектов при обработке разрешенной операции <edit-config>.

Существует риск того, что нестандартные протокольные операции или даже стандартная операция <get> могут возвращать данные, которые являются «псевдонимом» или «копией» конфиденциальных данных из другого объекта. Может просто существовать множество определений модели данных, которые раскрывают или даже настраивают базовое серверное оборудование.

Модель данных может содержать внешние ключи (например, YANG leafref), которые раскрывают значения из другой структуры данных. Администратор должен осознавать деликатность моделей данных с узлами leafref. Это влечет за собой поиск всех объектов leafref, которые «указывают» на деликатные данные (т. е. значений операторов path), явно или неявно включая узлы конфиденциальных данных.

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

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

Сессия может нарушать управление конфигурацией даже без права записи в конфигурацию просто путем блокировки хранилища. Это может делаться для обеспечения стабильности всей или части конфигурации во время операций извлечения данных или возникать в результате DoS-атаки8. Сервер не может различить эти два случая. Администратор может ограничить доступ к исполнению (exec) для перечисленных ниже протокольных операций:

  • <lock>

  • <unlock>

  • <partial-lock>

  • <partial-unlock>

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

Разработчикам нужно четко указать все деликатные данные, уведомления и протокольные операции, определенные в модуле YANG. Для таких определений должен присутствовать оператор nacm:default-deny-write или nacm:default-deny-all в дополнение к четкому описанию рисков безопасности.

Протокольные операции должны быть подобающим образом документированы разработчиком модели данных, чтобы администраторы понимали на какие узлы данных (если они есть) влияют операции протокола и какая информация (если она есть) возвращается в сообщении <rpc-reply>.

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

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5277] Chisholm, S. and H. Trevino, «NETCONF Event Notifications», RFC 5277, DOI 10.17487/RFC5277, July 2008, <https://www.rfc-editor.org/info/rfc5277>.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.http://www.protocols.ru/WP/rfc6242/

[RFC6242] Wasserman, M., «Using the NETCONF Protocol over Secure Shell (SSH)», RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «Network Management Datastore Architecture (NMDA)», RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, «Extensible Markup Language (XML) 1.0 (Fifth Edition)», World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

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

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, «Remote Authentication Dial In User Service (RADIUS)», RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.

[RFC5607] Nelson, D. and G. Weber, «Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management», RFC 5607, DOI 10.17487/RFC5607, July 2009, <https://www.rfc-editor.org/info/rfc5607>.

[YANG-SEC] IETF, «YANG Security Guidelines», <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>.

Приложение A. Примеры использования

Приведенные ниже фрагменты XML [W3C.REC-xml-20081126] служат лишь примерами настройки NACM для решения некоторых задач контроля доступа.

A.1. Пример <groups>

Требуется хотя бы одна запись <group>, чтобы правила контроля доступа могли использоваться.

Приведенный ниже фрагмент XML показывает произвольные группы и не предназначен для практического применения.

   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
     <groups>
       <group>
         <name>admin</name>
         <user-name>admin</user-name>
         <user-name>andy</user-name>
       </group>

       <group>
         <name>limited</name>
         <user-name>wilma</user-name>
         <user-name>bam-bam</user-name>
       </group>

       <group>
         <name>guest</name>
         <user-name>guest</user-name>
         <user-name>guest@example.com</user-name>
       </group>
     </groups>
   </nacm>

Этот пример включает три группы:

   admin: два пользователя с именами admin и andy
   limited: два пользователя с именами wilma и bam-bam
   guest: два пользователя с именами guest и guest@example.com.

A.2. Пример правила для модуля

Правила модуля служат для контроля доступа ко всему содержимому, определенному в конкретном модуле. Правило модуля имеет установленный лист module-name, но не имеет установленных узлов из выбора rule-type.

   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
     <rule-list>
       <name>guest-acl</name>
       <group>guest</group>
       <rule>
         <name>deny-ncm</name>
         <module-name>ietf-netconf-monitoring</module-name>
         <access-operations>*</access-operations>
         <action>deny</action>
         <comment>
             Не позволяет гостям получить доступ к данным 
             мониторинга NETCONF.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>limited-acl</name>
       <group>limited</group>
       <rule>
         <name>permit-ncm</name>
         <module-name>ietf-netconf-monitoring</module-name>
         <access-operations>read</access-operations>
         <action>permit</action>
         <comment>
             Позволяет считывать данные мониторинга NETCONF.
         </comment>
       </rule>
       <rule>
         <name>permit-exec</name>
         <module-name>*</module-name>
         <access-operations>exec</access-operations>
         <action>permit</action>
         <comment>
             Позволяет вызывать поддерживаемые операции сервера.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>admin-acl</name>
       <group>admin</group>
       <rule>
         <name>permit-all</name>
         <module-name>*</module-name>
         <access-operations>*</access-operations>
         <action>permit</action>
         <comment>
             Дает группе admin полный доступ к операциям и данным.
         </comment>
       </rule>
     </rule-list>
   </nacm>

Этот пример демонстрирует 4 правила:

   deny-ncm: предотвращает доступ группы guest к считыванию данных
      мониторинга в модуле YANG ietf-netconf-monitoring.
   permit-ncm: позволяет группе limited читать модуль YANG
      ietf-netconf-monitoring.
   permit-exec: позволяет группе limited вызывать любые протокольные
      операции, поддерживаемые сервером.
   permit-all: предоставляет группе admin полный доступ к содержимому
      сервера. Далее не будет правил, соответствующих группе admin,
      поскольку это правило для модуля.

A.3. Пример правила для протокольной операции

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

   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
     <rule-list>
       <name>guest-limited-acl</name>
       <group>limited</group>
       <group>guest</group>
       <rule>
         <name>deny-kill-session</name>
         <module-name>ietf-netconf</module-name>
         <rpc-name>kill-session</rpc-name>
         <access-operations>exec</access-operations>
         <action>deny</action>
         <comment>
           Не позволяет группам limited и guest 'убить' чужую сессию.
         </comment>
       </rule>
       <rule>
         <name>deny-delete-config</name>
         <module-name>ietf-netconf</module-name>
         <rpc-name>delete-config</rpc-name>
         <access-operations>exec</access-operations>
         <action>deny</action>
         <comment>
            Не позволяет группам limited и guest удалять конфигурации.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>limited-acl</name>
       <group>limited</group>
       <rule>
         <name>permit-edit-config</name>
         <module-name>ietf-netconf</module-name>
         <rpc-name>edit-config</rpc-name>
         <access-operations>exec</access-operations>
         <action>permit</action>
         <comment>
           Позволяет группе limited редактировать конфигурацию.
         </comment>
       </rule>
     </rule-list>
   </nacm>

Этот пример содержит правила для трех операций:

   deny-kill-session: предотвращает вызов группами limited и guest 
      протокольной операции NETCONF <kill-session>.
   deny-delete-config: предотвращает вызов группами limited и guest 
      протокольной операции NETCONF <delete-config>.
   permit-edit-config: разрешает группе limited вызывать операцию
      NETCONF <edit-config>. Это правило не будет работать, пока не
      установлено значение deny для листа exec-default.

A.4. Пример правила для узла данных

Правила узла данных служат для контроля доступа к конкретным (config и non-config) узлам данных в содержимом NETCONF, предоставляемом сервером.

   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
     <rule-list>
       <name>guest-acl</name>
       <group>guest</group>
       <rule>
         <name>deny-nacm</name>
         <path xmlns:n="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
           /n:nacm
         </path>
         <access-operations>*</access-operations>
         <action>deny</action>
         <comment>
           Запрет для группы guest доступа к данным /nacm.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>limited-acl</name>
       <group>limited</group>
       <rule>
         <name>permit-acme-config</name>
         <path xmlns:acme="http://example.com/ns/netconf">
           /acme:acme-netconf/acme:config-parameters
         </path>
         <access-operations>
           read create update delete
         </access-operations>
         <action>permit</action>
         <comment>
           Предоставление группе limited полного доступа к 
           конфигурационным параметрам acme NETCONF. Показана
           длинная форма access-operations вместо сокращенной.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>guest-limited-acl</name>
       <group>guest</group>
       <group>limited</group>
       <rule>
         <name>permit-dummy-interface</name>
         <path xmlns:acme="http://example.com/ns/itf">
           /acme:interfaces/acme:interface[acme:name='dummy']
         </path>
         <access-operations>read update</access-operations>
         <action>permit</action>
         <comment>
           Разрешает группам limited и guest чтение и обновление
           для интерфейса dummy.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>admin-acl</name>
       <group>admin</group>
       <rule>
         <name>permit-interface</name>
         <path xmlns:acme="http://example.com/ns/itf">
           /acme:interfaces/acme:interface
         </path>
         <access-operations>*</access-operations>
         <action>permit</action>
         <comment>
           Разрешает группе admin полный доступ к интерфейсам acme.
         </comment>
       </rule>
     </rule-list>
   </nacm>

Этот пример содержит 4 правила для узлов данных:

   deny-nacm: предотвращает доступ группы guest к субдереву /nacm.
   permit-acme-config: разрешает для группы limited доступ read-write
      к acme <config-parameters>.
   permit-dummy-interface: разрешает для групп limited и guest доступ
      read-update к записи acme <interface> с именем dummy. Запись не
      может быть создана или удалена этими группами, можно лишь менять ее.
   permit-interface: дает группе admin доступ read-write ко всем записям
      acme <interface>.

A.5. Пример правила для уведомления

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

   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
     <rule-list>
       <name>sys-acl</name>
       <group>limited</group>
       <group>guest</group>
       <rule>
         <name>deny-config-change</name>
         <module-name>acme-system</module-name>
         <notification-name>sys-config-change</notification-name>
         <access-operations>read</access-operations>
         <action>deny</action>
         <comment>
           Не позволяет группам guest и limited получать 
           уведомления о смене конфигурации.
         </comment>
       </rule>
     </rule-list>
   </nacm>

Этот пример показывает одно правило для уведомлений:

   deny-config-change: предотвращает отправку в группы limited и
      guest уведомлений о событиях типа acme <sys-config-change>.

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

Andy Bierman

YumaWorks

685 Cochran St.

Suite #160

Simi Valley, CA 93065

United States of America

Email: andy@yumaworks.com

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com


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

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

nmalykh@gmail.com

1Network Configuration.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Remote Procedure Call — вызов удаленных процедур.

5Create, Read, Update, Delete, eXec — создание, чтение, обновление, удаление, исполнение.

6Secure Shell.

7Man-in-the-middle — перехват и изменение пакетов с участием человека.

8Denial-of-service — отказ в обслуживании.




RFC 8340 YANG Tree Diagrams

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8340                                Tail-f Systems
BCP: 215                                                  L. Berger, Ed.
Category: Best Current Practice                  LabN Consulting, L.L.C.
ISSN: 2070-1721                                               March 2018

Диаграммы деревьев YANG

YANG Tree Diagrams

 PDF

Тезисы

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

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

Этот документ относится к категории обмена опытом (Internet Best Current Practice).

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

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

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

Авторские права (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 впервые были опубликованы в RFC 6536. Они используются для упрощенного графического представления модели данных и могут создаваться автоматически с помощью таких инструментов, как pyang [PYANG]. В этом документе описан синтаксис, применяемый в диаграммах деревьев YANG. Предполагается, что этот документ будет обновляться или заменяться по мере внесения изменений в язык YANG [RFC7950].

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

Пример диаграммы дерева можно найти в разделе 3 документа [RFC8343]. Часть такого дерева приведена ниже.

     +--rw interfaces
        +--rw interface* [name]
           +--rw name                        string
           +--rw description?                string
           +--rw type                        identityref
           +--rw enabled?                    boolean
           +--rw link-up-down-trap-enable?   enumeration {if-mib}?

2. Синтаксис диаграммы дерева

В этом разделе описано значение символов, применяемых в диаграммах деревьев YANG.

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

Модуль указывается тегом module:, за которым следует имя модуля <module-name>. Далее следует один или несколько разделов в соответствии с приведенными ниже правилами.

  1. Определенные в модуле узлы верхнего уровня смещаются пробелами на две позиции.

  2. Добавления смещаются на две пробельных позиции и указываются ключевым словом augment, за которым следует целевой узеля дополнения и двоеточие (:).

  3. RPC смещаются на два пробела и указываются тегом rpcs:.

  4. Уведомления смещаются на два пробела и указываются тегом notifications:.

  5. Группировки смещаются на два пробела и указываются ключевым словом grouping, за которым следует имя группировки и двоеточие (:).

  6. Структуры yang-data смещаются на два пробела и указываются ключевым словом yang-data, за которым следует имя структуры yang-data и двоеточие (:).

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

Пример полного формата с учетом соглашений о смещениях приведен ниже.

     module: <module-name>
       +--<node>
       |  +--<node>
       |     +--<node>
       +--<node>
          +--<node>
             +--<node>

       augment <target-node>:
         +--<node>
            +--<node>
            +--<node>
               +--<node>
       augment <target-node>:
         +--<node>

       rpcs:
         +--<rpc-node>
         +--<rpc-node>
            +--<node>
            |  +--<node>
            +--<node>

       notifications:
         +--<notification-node>
         +--<notification-node>
            +--<node>
            |  +--<node>
            +--<node>

       grouping <grouping-name>:
         +--<node>
            +--<node>
            |  +--<node>
            +--<node>
       grouping <grouping-name>:
         +--<node>


       yang-data <yang-data-name>:
         +--<node>
            +--<node>
            |  +--<node>
            +--<node>
       yang-data <yang-data-name>:
         +--<node>

2.1. Субмодуль

Субмодули представляются аналогично модулям, но указываются тегом submodule:, за которым следует имя субмодуля <module-name>. Например,

     submodule: <module-name>
       +--<node>
       |  +--<node>
       |     +--<node>

2.2. Группировка

Узлы в используемой группировке обычно раскрываются, как будто они определены в месте расположения оператора uses. Однако можно не раскрывать оператор uses, а вместо этого просто указывать имя группировки.

Например, приведенная ниже диаграмма показывает группировку tls-transport из [RFC7407] без раскрытия

       +--rw tls
          +---u tls-transport

Если группу раскрыть, она пример вид

       +--rw tls
          +--rw port?                 inet:port-number
          +--rw client-fingerprint?   x509c2n:tls-fingerprint
          +--rw server-fingerprint?   x509c2n:tls-fingerprint
          +--rw server-identity?      snmp:admin-string

Группировки могут присутствовать в разделе groupings.

2.3. Структура yang-data

Если модуль определяет структуры yang-data [RFC8040], эти структуры могут присутствовать в разделе yang-data.

2.4. Сжатое представление узлов

Когда состав узлов внутри схемы модуля не имеет значения в контексте представления дерева, братские узлы и их потомки могут быть «сжаты» с использованием трех точек (…) вместо строк, представляющих реальные узлы.

       +--<node>
       |  ...
       +--<node>
          +--<node>
             +--<node>

2.5. Комментарий

Отдельная строка комментария, начинающегося с символов // (возможно смещенных) и длящегося до конца строки, может использоваться в дереве.

2.6. Представление узла

Каждый узел модуля YANG указывается в форме

     <status>--<flags> <name><opts> <type> <if-features>

       <status> 
         +  текущий
         x  устаревший (deprecated)
         o  отмененный obsolete)

       <flags>
         rw  для узлов данных конфигурации и узлов выбора
         ro  для узлов неконфигурационных данных и узлов выбора,
             выходных параметров rpc и операций (actions), а 
             также параметров уведомлений
         -w  для входных параметров rpc и операций
         -u  для использования в группировках
         -x  для rpc и операций
         -n  для уведомлений
         mp  для узлов с оператором расширения mount-point

Узлы вариантов (case) не имеют флагов.

       <name> имя узла
         (<name>) означает, что узел является узлом выбора
        :(<name>) означает, что узел является узлом варианта (case)

Если узел добавлен в дерево из другого модуля, его имя указывается в форме <prefix>:<name>, где <prefix> указывает префикс, заданный в модуле, где определен узел.

Если узел является вариантом (case) перед <name> побелы не используются.

       <opts> 
         ?  для опционального узла leaf, choice, anydata, anyxml
         !  для контейнера присутствия
         *  для leaf-list или list
         [<keys>] для ключей списка
         /  для узла данных верхнего уровня в смонитрованном модуле
         @  для узла данных верхнего уровня модуля, указанного в точке
            монтирования родительской ссылки

       <type> название типа для leaf и leaf-list

Для leafref тип указывается как (1) -> TARGET, где TARGET указывает путь leafref с удалением (по возможности) ссылок или (2) leafref.

       <if-features> список функций (feature) от которых узел зависит,
         указывается в фигурных скобках, за которыми следует символ ? {...}?

Между разделяемыми пробелами полями (например, <opts> и <type>) число пробелов может быть любым. Дополнительные пробелы могут применяться, например, для выравнивания полей (например, в списке или контейнере) с целью удобочитаемости.

3. Рекомендации по использованию в RFC

В этом разделе приводятся рекомендации, связанные с использованием диаграмм деревьев в RFC.

3.1. Разрыв длинных строк

В документах Internet-Draft и RFC размер строки ограничен 72 символами. Когда представление узла требует более длинной строки, следует использовать перевод строки между <opts> и <type> или между <type> и <if-feature>. Новую строки следует дополнить пробельными символами так, чтобы она начиналась под <name> со смещением в 2 символа.

     notifications:
       +---n yang-library-change
          +--ro module-set-id
                  -> /modules-state/module-set-id

Длинные пути (например, пути leafref или цели дополнения) можно разбивать на несколько строк. Например,

     augment /nat:nat/nat:instances/nat:instance/nat:mapping-table
               /nat:mapping-entry:

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

     pyang -f tree --tree-line-length 50 ietf-yang-library.yang

При включении диаграмм в качестве рисунков с Internet-Draft или RFC имеет смысл указать —tree-line-length 69.

3.2. Группировки

Если модуль YANG состоит только из группировок, диаграмма дерева должна включать группировки. Можно снова воспользоваться компилятором pyang для создания диаграммы дерева с группировками, используя параметры -f tree —tree-print-groupings.

3.3. Длинные диаграммы

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

Пример разделения диаграммы можно видеть в [RFC7407], где параграф 2.4 включает диаграмму конфигурации engine

       +--rw snmp
          +--rw engine
             // дополнительные параметры из ветви engine

Далее в параграфе 2.5 [RFC7407] показана диаграмма конфигурации target

       +--rw snmp
          +--rw target* [name]
             // дополнительные параметры из ветви target

Уже упомянутая команда pyang будет полезна для создания таких деревьев. Для приведенного выше примера использовалась команда

     pyang -f tree --tree-path /snmp/target ietf-snmp.yang

4. Диаграммы деревьев с точками монтирования YANG

Монтирование схемы YANG, определенное в [SCHEMA-MOUNT], требует некоторого обсуждения. Монтирование схемы является базовым механизмом, который позволяет монтировать один или несколько модулей YANG в заданном месте другой (родительской) схемы. Место установки указывается «точкой монтирования» и любой контейнер или список могут служить в качестве таких точек. Точки монтирования указываются путем включения оператора расширения mount-point в качестве субоператора для узла контейнера или списка. Таким образом узлы точек монтирования напрямую указываются в определении схемы модуля и могут быть указаны в дереве с помощью флага mp.

В следующем примере, заимствованном из [YANG-NIs], контейнер vrf-root включает оператор расширения mount-point в качестве части свого определения.

     module: ietf-network-instance
       +--rw network-instances
          +--rw network-instance* [name]
             +--rw name           string
             +--rw enabled?       boolean
             +--rw description?   string
             +--rw (ni-type)?
             +--rw (root-type)
                +--:(vrf-root)
                |  +--mp vrf-root

4.1. Представление деревьев с точками монтирования

Реальные модули, доступные под точкой монтирования, контролируются сервером и предоставляются клиентам. Эта информация обычно представляется через модуль монтирования схемы (ietf-yang-schema-mount), определенный в [SCHEMA-MOUNT]. Модуль монтирования схемы поддерживает раскрытие (exposure) как смонтированных схем, так и «родительских ссылок». Последние используются для оценки выражений XPath3 в смонтированных модулях и не представляют доступные клиенту пути, укаазнная ссылкой информация доступна клиентам через родительскую схему. Монтирование схемы также определяет «строенный» (inline) тип точек монтирования, где смонтированные модули раскрываются через библиотечный модуль YANG.

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

В таких диаграммах точку монтирования следует рассматривать аналогично контейнеру, использующему группировку. Флаги следует устанавливать с учетом листа config, упомянутого выше, а указанные выше опции монтирования должны быть показаны для узлов верхнего уровня в монтируемом или указанном ссылкой модуле. В следующем примере, взятом из [YANG-Nis], представлен предыдущий пример с установленными модулями YANG ietf-routing [YANG-Routing] и ietf-ospf [OSPF-YANG], узлами из модуля YANG ietf-interfaces [RFC8343], доступными через родительскую ссылку, и узел config со значением true.

     module: ietf-network-instance
       +--rw network-instances
          +--rw network-instance* [name]
             +--rw name           string
             +--rw enabled?       boolean
             +--rw description?   string
             +--rw (ni-type)?
             +--rw (root-type)
                +--:(vrf-root)
                   +--mp vrf-root
                      +--ro rt:routing-state/
                      |  +--ro router-id?
                      |  +--ro control-plane-protocols
                      |     +--ro control-plane-protocol* [type name]
                      |        +--ro ospf:ospf
                      |           +--ro instance* [af]
                      |           ...
                      +--rw rt:routing/
                      |  +--rw router-id?
                      |  +--rw control-plane-protocols
                      |     +--rw control-plane-protocol* [type name]
                      |     +--rw ospf:ospf
                      |        +--rw instance* [af]
                      |           ...
                      +--ro if:interfaces@
                      |  ...
                      +--ro if:interfaces-state@
                      |  ...

Следует подчеркнуть, что модуль ietf-ospf дополняет ietf-routing и хотя он не указан в модуле монтирования схемы (или встроенной библиотеке YANG), в диаграмме дерева не используется специального обозначения монтирования.

Определения точки монтирования, самого по себе, не достаточно для указания используются ли смонтированные модули для данных конфигурации или иных данных. Это определяется листом config модуля ietf-yang-schema-mount, связанным с конкретной точкой монтирования и указывается на смонтированных узлах верхнего уровня. Например, в приведенном выше дереве, где лист config для модуля ietf-routing указывает false, узлы в ветви rt:routing будут иметь другие флаги.

                      +--ro rt:routing/
                      |  +--ro router-id?
                      |  +--ro control-plane-protocols
                         ...

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

Этот документ не требует действий IANA.

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

Описанные здесь диаграммы деревьев не оказывают влияния на безопасность.

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

[OSPF-YANG] Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem, «Yang Data Model for OSPF Protocol», Work in Progress, draft-ietf-ospf-yang-10, March 2018.

[PYANG] «pyang», February 2018, <https://github.com/mbj4668/pyang>.

[RFC7407] Bjorklund, M. and J. Schoenwaelder, «A YANG Data Model for SNMP Configuration», RFC 7407, DOI 10.17487/RFC7407, December 2014, <https://www.rfc-editor.org/info/rfc7407>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8343] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[SCHEMA-MOUNT] Bjorklund, M. and L. Lhotka, «YANG Schema Mount», Work in Progress, draft-ietf-netmod-schema-mount-08, October 2017.

[YANG-NIs] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, «YANG Model for Network Instances», Work in Progress, draft-ietf-rtgwg-ni-model-11, March 2018.

[YANG-Routing] Lhotka, L., Lindem, A., and Y. Qu, «A YANG Data Model for Routing Management (NMDA Version)», Work in Progress, draft-ietf-netmod-rfc8022bis-114, January 2018.

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

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com

Lou Berger (редактор)

LabN Consulting, L.L.C.

Email: lberger@labn.net


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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3XML Path Language — язык путей XML.

4Работа завершена и опубликована в RFC 8349. Прим. перев.