RFC 8309 Service Models Explained

Internet Engineering Task Force (IETF)                             Q. Wu
Request for Comments: 8309                                        W. Liu
Category: Informational                              Huawei Technologies
ISSN: 2070-1721                                                A. Farrel
                                                        Juniper Networks
                                                            January 2018

Service Models Explained

Разъяснение моделей сервиса

PDF

Аннотация

В IETF¹ выпущено множество модулей на языке моделирования YANG. Большинство этих модулей служит для создания моделей данных, описывающих устройства или неделимые функции.

Небольшое число модулей YANG определяет модели сервиса (например, модель L3SM², разработанная группой L3SM и опубликованная в RFC 8049).

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

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

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

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

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

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

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

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

1. Введение

В последние годы было написано множество модулей на языке моделирования [RFC6020] для настройки и мониторинга. Многие из таких модулей служат для настройки конфигурации на уровне устройств (например, [RFC7223]) или управления неделимыми (монолитными) функциями или экземплярами протоколов (например, [RFC7407]).

[RFC7950] различает «модель данных», которая определяет представление данных и доступ к ним, и «модуль YANG», определяющий иерархии узлов схемы для создания автономного и компилируемого блока определений и включений. YANG собирает модели данных в структурированные модули для простоты использования.

В контексте программно-определяемых сетей (SDN⁴) [RFC7149] [RFC7426] модули данных YANG могут применяться на интерфейсе между контроллером и сетевыми устройствами, а также между сетевыми оркестраторами и контроллерами. Может также применяться иерархия таких компонентов с «супер-контроллерами», доменными контроллерами и контроллерами устройств, обменивающимися данными и инструкциями с помощью модулей YANG.

Был интерес к использованию YANG для определения и документирования моделей данных, описывающих сервис переносимым способом, который не зависит от использующего модель оператора, например, модель L3SM [RFC8049]. Такие модели могут применяться в ручных и даже бумажных процессах запроса с постепенным переходом к механизмам IT. В конечном итоге они могут применяться в интерактивных, программно-управляемых динамических системах, а также стать частью систем SDN.

В этом документе разъясняется область действия и назначение моделей сервиса в рамках IETF (и не выходящих за эти рамки), а также описаны способы применения этих моделей сетевыми операторами. В документе также разъяснено, чем не являются модели сервиса и рассеяны некоторые распространенные заблуждения.

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

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

Другая работа по классификации модулей YANG опубликована в [RFC8199], где приведены важные для этого документа ссылки, а также используется термин «модуль сервиса» (service module). В параграфе 6.1 приведено сравнение использования терминов в документах.

2. Термины и концепции

Читателям следует внимательно ознакомиться с описанием и классификацией модулей YANG в документе [RFC8199].

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

Network Operator – сетевой оператор

Этим термином обозначают компанию, которая владеет и эксплуатирует одну или множество сетей, обеспечивающих доступ в Internet и/или другие услуги.

Customer – абонент, клиент

Этот термин обозначает сторону, покупающую услуги (в том числе, подключение) у сетевого оператора. В контексте этого документа абонентом обычно считается компания, у которой имеется свой сеть или вычислительная платформа и которой нужно подключиться к Internet или соединить свои сайты. У такого клиента может быть корпоративная сеть или ЦОД⁵. Иногда этот термин применяют к отдельным лицам таких компаний, которые заключают договор на покупку услуг сетевого оператора. Описываемый здесь клиент ведет деятельность независимо от сетевого оператора, но некоторые компании могут выступать в качестве внутренних клиентов, например, пакетная сеть IP/MPLS может быть клиентом оптической транспортной сети.

Service – сервис, услуга

Сетевой оператор предоставляет клиенту одну или множество услуг. Услугой в контексте этого документа (иногда применяется термин сетевая услуга) называется та или иная форма связности сайтов клиента с Internet или соединения сайтов клиента через сеть оператора и Internet. Однако следует различать параметры, описывающие услугу, включенную с модель обслуживания клиентов (см. определение ниже), и соглашение об уровне обслуживания (SLA⁶), как указано в разделе 5 и параграфе 7.2.

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

В этом документе различаются услуги, предоставляемые клиентам (т. е. услуги на интерфейсе между клиентом и оператором), и услуги, реализуемые в сети (см. [RFC8199]). Это различие рассмотрено в разделе 6.

Читатели могут также обратиться к [RFC7297], где имеется пример характеризации услуг связности IP.

Data Model – модель данных

Концепции информационной модели (IM) и модели данных (DM) описаны в [RFC3444]. Этот документ определяет модель данных, сопоставляя ее с IM, как описано ниже.

Основная цель IM состоит в моделировании управляемых объектов на концептуальном уровне, независимо от конкретных реализаций и протоколов , служащих для передачи данных. Уровень конкретизации (деталей) определенных в IM абстракций зависит от задач разработчиков модели. Для максимального упрощения устройства в IM следует скрывать все протоколы и детали реализации. Другой важной чертой IM является определение связей между управляемыми объектами. Модели DM, напротив, определяются с низким уровнем абстракции и включают многие детали. Они предназначены для разработчиков и включают зависимые от протоколов конструкции.

Как отмечено в разделе 1, термины модель данных и модуль YANG здесь применяются, как указано в [RFC7950].

Service Model – модель сервиса

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

Customer Service Model – модель обслуживания клиентов

Модель обслуживания клиентов применяется для описания сервиса, предлагаемого или предоставляемого клиенту сетевым оператором, как показано на рисунке 1. Она может использоваться человеком (через пользовательский интерфейс, такой как GUI, web-форма, CLI) или программой для настройки или запроса сервиса, который может предоставляться людям (через систему выполнения заказов) или программным компонентам. Такие модели иногда называют моделями сервиса [RFC8049]. Модель обслуживания клиентов выражается в модуле YANG как основной набор параметров, который является общим для сетевых операторов, а дополнительные возможности, зависящие от конкретного сетевого оператора, определяются расширениями или дополнениями к модулю. За исключением случаев, когда детали технологии напрямую относятся к клиенту (например, инкапсуляция или механизмы доступа), модели обслуживания клиентов не зависят от технологии и абонент не влияет (и не знает) на устройство сервиса у оператора.

Примером, где такие детали имеют отношение к клиенту, является случай, где эти детали описывают поведение или взаимодействие на интерфейсе между оборудованием клиентского сайта (его часто называют Customer Edge или CE) и оборудованием оператора (обычно называют Provider Edge или PE).

Service Delivery Model – модель предоставления услуг

Модель предоставления услуг используется сетевым оператором для определения и управления способом организации сервиса в сети. Она может использоваться человеком (например, со станции управления) или программой для инструктирования компонент сети. Модули YANG, представляющие такие модели, иногда называют модулями YANG для сетевых услуг [RFC8199] и они применяются «внешними системами», такими как системы поддержки операций (OSS⁷). Модуль предоставления услуг выражается как базовый набор параметров, общий для разных типов сетей и технологий. Дополнительные свойства конкретной конфигурации оборудования определенного производителя или фирменных протоколов определяются в расширениях или дополнениях к модулю. Модули предоставления услуг включают модули для конкретных технологий.

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

3. Использование моделей сервиса

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

Язык описания модели определяется ее разработчиком. IETF применяет язык YANG, определенный в [RFC6020].

Кодирование и протокол обмена данными модели между клиентом и оператором зависит от развертывания и реализации. В IETF стандартизованы протоколы NETCONF [RFC6241] и RESTCONF [RFC8040] для взаимодействия «по проводу» между программными компонентами с использованием данных в формате XML или JSON. Однако размещенные вместе программные компоненты могут применять внутренний API, а системы, взаимодействующие с людьми, могут использовать web-формы и даже бумажные документы. При прямом взаимодействии с людьми интерфейсные операции могут быть реализованы через бизнес-практику, которая может вносить ошибки, что повышает значимость автоматизированных, детерминированных интерфейсов.

 --------------        Модель         ----------------------
|              |обслуживания абонента|                      |
|   Абонент    | <-----------------> |   Сетевой оператор   |
|              |                     |                      |
 --------------                       ----------------------

Рисунок 1. Модель обслуживания, применяемая на интерфейсе между абонентом и оператором.

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

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

3.1. Практические вопросы

Практичность моделей обслуживания клиентов обсуждалась неоднократно. Были высказаны предположения о наличии у сетевых операторов радикально разных бизнес-моделей и широкого спектра коммерческих предложений, что делает нецелесообразной разработку общей модели обслуживания клиентов. Однако L3SM [RFC8049] является результатом соглашения многих людей, работающих у операторов, и предлагает общее ядро опций сервиса, которое можно дополнить в соответствии с потребностями конкретного оператора.

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

4. Модели сервиса в контексте SDN

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

                ------------------
               |                  |
               |   Координатор    |
               |                  |
               .------------------.
              .          :         .
             .           :          .
  ------------     ------------     ------------
 |            |   |            |   |            |
 | Контроллер |   | Контроллер |   | Контроллер |
 |            |   |            |   |            |
  ------------     ------------     ------------
     :              .       .               :
     :             .         .              :
     :            .           .             :
 ---------     ---------   ---------     ---------
| Элемент |   | Элемент | | Элемент |   | Элемент |
|  сети   |   |  сети   | |  сети   |   |  сети   |
 ---------     ---------   ---------     ---------

Рисунок 2. Пример архитектуры SDN.

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

Одним из вариантов реализации такого отображения служит разделение координации сети и услуг, как показано на рисунке 3.

                                             Модель
                        ------------------ обслужив.  ----------
                       |                  | клиентов |          |
                       |   Координатор    |<-------->| Абонент  |
                       |      услуг       |    (a)   |          |
                       |                  |           ----------
                        ------------------
                           .          .
                          .            .        (b)   -----------
                         . (b)          .      ......|  BSS/OSS  |
                        .                .     :     |приложений |
                       .                  .    :      -----------
                      . Модель предоставл. .   :
                      .       услуг        .   :
             ------------------    ------------------
            |                  |  |                  |
            |   Координатор    |  |   Координатор    |
            |      сети        |  |      сети        |
            |                  |  |                  |
            .------------------    ------------------.
           .         :                       :        .
          .          : Модель конфигурации   :         .
          .          :        сети           :         .
  ------------     ------------     ------------    ------------
 |            |   |            |   |            |  |            |
 | Контроллер |   | Контроллер |   | Контроллер |  | Контроллер |
 |            |   |            |   |            |  |            |
  ------------     ------------     ------------    ------------
     :              .       .                 :            :
     :             .         .      Модель    :            :
     :            .           . конфигурации  :            :
     :            .           .  устройства   :            :
 ---------     ---------   ---------     ---------      ---------
| Элемент |   | Элемент | | Элемент |   | Элемент |    | Элемент |
|  сети   |   |  сети   | |  сети   |   |  сети   |    |  сети   |
 ---------     ---------   ---------     ---------      ---------

Рисунок 3. Пример архитектуры SDN с координатором услуг.

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

Перечисленные ниже примеры иллюстрируют разделение компонент управления, которые представляют «сервисный интерфейс», имеющийся во многих вариантах расширенной архитектуры SDN.

• На рисунке 1 в [RFC7426] показано разделение прикладного уровня, уровня абстракции сетевых служб (NSAL⁸) и уровня управления. Сервисный интерфейс размещается между NSAL и уровнем управления.

• На рисунке 1 в [RFC7491] показан интерфейс между координатором службы приложений и контроллером основанных на приложениях сетевых операций.

• На рисунке 1 в [RFC8199] показан интерфейс из OSS или BSS⁹, выраженный в модулях YANG для сетевого сервиса.

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

5. Возможные причины путаницы

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

• Обсуждаемые услуги являются услугами связи, которые сетевые операторы предоставляют своим клиентам. Услуги обеспечиваются путем манипуляций с ресурсами сети оператора. Это полностью отличается от подхода «нечто как услуга» (например, хранилище как услуга или SaaS¹⁰), где сервис-провайдер предлагает доступ к услуге с добавленной стоимостью, которая предоставляется в определенном месте сети с использованием других ресурсов (вычисления, хранилище …), которые сами не являются частью сети. Путаница возникает не только из-за использования в обоих случаях слова «услуга», но и в результате того, что операторы могут предлагать своим клиентам оба типа услуг.

• Работа сети обычно выходит за рамки обсуждения услуг между оператором и клиентом. Это значит, что модель обслуживания клиентов не раскрывает им способы предоставления услуг оператором, детали технологии или ресурсы, используемые для предоставления услуги (все это может считаться уязвимым в плане безопасности). Например, в простом случае подключения по виртуальному каналу «точка-точка», создаваемому с помощью туннеля (например, псевдопровод MPLS) оператор не раскрывает пути туннеля через сеть. Конечно, это не мешает оператору принимать пожелания клиента (например, избегать прохождения через определенную страну) или раскрывать конкретные детали (например, те, которые можно обнаружить путем трассировки маршрута), но это не относится к стандартным свойствам услуги, описываемым моделью обслуживания клиентов.

• Оператор может применять дополнительные модели данных (модели предоставления услуг), которые помогают описать способ реализации услуги в сети. Эти модели могут применяться на интерфейсе между координаторами сервиса и сети, как показано на рисунке 3, и могут включать многие фрагменты информации из модели обслуживания клиентов вместе с параметрами протоколов и данными конфигурации устройств. В [RFC8199] такие модели данных названы сервисными моделями и обозначены как «модули YANG для сетевых услуг» (см. сравнение в параграфе 6.1). Важно, чтобы координатор услуг мог отобразить модель обслуживания клиентов на эти модели предоставления услуг, но это разные модели.

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

• SLA в значительной мере перекрываются с определениями услуг, представленными в моделях обслуживания клиентов. Например, запросы определенной пропускной способности могут присутствовать в модели обслуживания клиентов, а соглашение о предоставлении услуг является представлением описания услуги в модели обслуживания клиентов. Однако SLA обычно включают ряд тонких деталей о возможности, способах и частоте изменения услуг. SLA также связаны с коммерческими условиями, штрафами и т. п., поэтому они слабо подходят для стандартизации. Как и в коммерческих условиях, ожидается, что некоторые операторы будут развивать стандартные модели обслуживания клиентов для включения параметров SLA, используя свою работу или в зависимости от материалов стандартизации этих тем, на это выходит за рамки моделей обслуживания клиентов, разрабатываемых в IETF.

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

6. Связь с другими работами

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

6.1. Сравнение с моделями сетевого сервиса

Как отмечено выше, в [RFC8199] приведена классификация модулей YANG. Документ вводит термин «модуль YANG для сетевого сервиса», указывающий тип модулей, которые «описывают конфигурацию, данные состояния, операции и уведомления абстрактного представления сервиса, реализованного в одном или множестве элементов сети». Эти модули служат для построения моделей предоставления услуг, описываемых в этом документе, т. е. они являются модулями, применяемыми на интерфейсе между координатором услуг или OSS/BSS и координатором сети, как показано на рисунке 3.

Рисунок 1 из [RFC8199] можно изменить, чтобы сделать более четким и включить дополнительный пример модуля YANG для сетевых услуг, как показано на рисунке 4. Как можно видеть, верхний уровень классификации модулей собирает те, которые служат для поддержки операций и бизнеса. Они могут применяться системами OSS или BSS, а координатор сервиса может быть частью OSS/BSS или отдельной компонентой. Этот верхний уровень на рисунке разделен на модули обслуживания клиентов, служащие для описания услуг, и другие модули, которые описывают дополнительные функции OSS/BSS, такие как счета на оплату и SLA.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Модули YANG для поддержки операций и бизнеса

 +-----------------------+     +-----------------------+
 |                       |     |                       |
 |    Модули YANG для    |     |  Другие модули YANG   |
 | клиентского сервиса   |     |     для поддержки     |
 |                       |     |  операций и бизнеса   |
 |  +------+   +------+  |     |                       |
 |  |      |   |      |  |     |                       |
 |  | L2SM |   | L3SM |  |     |                       |
 |  |      |   |      |  |     |                       |
 |  +------+   +------+  |     |                       |
 |                       |     |                       |
 +-----------------------+     +-----------------------+

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Модули YANG для сетевого сервиса

+------------+  +-------------+  +-------------+  +-------------+
|            |  |             |  |             |  |             |
|  - L2VPN   |  |   - L2VPN   |  |    EVPN     |  |    L3VPN    |
|  - VPWS    |  |   - VPLS    |  |             |  |             |
|            |  |             |  |             |  |             |
+------------+  +-------------+  +-------------+  +-------------+

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Модули YANG для элементов сети

 +------------+  +------------+  +-------------+  +------------+
 |            |  |            |  |             |  |            |
 |    MPLS    |  |    BGP     |  | IPv4 / IPv6 |  |  Ethernet  |
 |            |  |            |  |             |  |            |
 +------------+  +------------+  +-------------+  +------------+

EVPN - Виртуальная частная сеть Ethernet 
L2SM - Модель услуг L2 VPN
L2VPN - Сеть L2 VPN
L3SM - Модель услуг L3 VPN
L3VPN - Сеть L3 VPN
VPLS - услуги виртуальной частной ЛВС
VPWS - услуги виртуального частного провода

Рисунок 4. Уровни абстракции модуля YANG, показывающие модули клиентского сервиса.

6.2. Модели предоставления услуг и элементов сети

Ряд рабочих групп IETF разрабатывает модули YANG, связанные с услугами. Эти модели ориентированы на способы настройки оператором протоколов и устройств своей сети для предоставления услуг. Некоторые из таких моделей классифицированы как модели предоставления сетевых услуг (их еще называют моделями предоставления услуг или моделями настройки сети в зависимости от уровня, где они представлены), а другие включают детали, связанные с настройкой конкретных элементов и классифицируются как модели элементов сети (модели устройств).

Ниже приведены примеры таких моделей.

• [BGP-L3VPN-YANG] определяет модуль YANG, который может служить для настройки и поддержки BGP L3VPN.

• [L2VPN-YANG] описывает модель данных, которую предполагается использовать в инструментах управления, работающих у операторов, для поддержки и мониторинга сетевых ресурсов, которые применяются для предоставления услуг L2VPN.

• [EVPN-YANG] определяет модули YANG для предоставления услуг Ethernet VPN.

6.3. Модель обслуживания клиентов

Несколько инициатив в рамках IETF связаны с разработкой моделей обслуживания клиентов. L3SM представляет услугу L3VPN для клиента в соответствии с описанием оператора. На рисунке 5, заимствованном из [RFC8049], показано, что L3SM является моделью обслуживания клиентов, как описано в этом документе.

    Модель    |
    L3VPN-SVC |
              |
           +------------------+         +-----+
           |    Координация   | < --- > | OSS |
           +------------------+         +-----+
              |            |
      +----------------+   |
      |Менеджер конфиг.|   |
      +----------------+   |
              |            |
              | Netconf/CLI ...
              |            |
+------------------------------------------------+
                     Сеть

Рисунок 5. Архитектура сервиса L3SM.

Модель услуг L2 VPN (L2SM) определена в [L2VPN-SERVICE].

Использование этой модели показано на рисунке 6, который воспроизводит рисунок 5 из этого документа. Как можно видеть, L2SM является моделью обслуживания клиентов, как описано в этом документе.

    ------------------------------------
   | Запрашивающий обслуживание клиента |
    ------------------------------------
        |
Модель  |
услуг   |
L2VPN   |
        |
      -----------------------
     |   Координатор услуг   |
      -----------------------
        |
        |     Модель              +-------------+
        |  предоставления +------>|   BSS/OSS   |
        |     услуг       |       | приложений  |
        |                 V       +-------------+
      -----------------------
     |   Координация сети    |
      -----------------------
         |            |
 +----------------+   |
 |менеджер конфиг.|   |
 +----------------+   |  Модели
         |            |  устройств
         |            |
--------------------------------------------
                        Сеть

Рисунок 6. Архитектура сервиса L2SM.

6.4. Архитектура MEF

Форум MEF (MEF) разработал архитектуру для администрирования и эксплуатации сетей. Она документирована как эталонная архитектура «координации жизненного цикла услуги» (LSO¹¹) и показана на рисунке 2 в [MEF-55].

Работа MEF охватывает все аспекты LSO, включая счета, SLA, управление заказами и жизненным циклом. Работы IETF по моделям сервиса обычно не столь широки и предлагают небольшой, самодостаточный модуль YANG для услуги. Это не отменяет ни один из подходов и лишь показывает их различие.

7. Другие концепции

В этом разделе представлены некоторые расширенные концепции.

7.1. Независимость от технологии

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

Ниже приведены два пример.

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

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

7.2. Связь с правилами

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

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

Как в случае коммерческих условий и SLA (раздел 5), предполагается, что некоторые операторы будут развивать стандартные модели обслуживания клиентов для включения параметров политики, используя свою работу или результаты работы по созданию моделей для политики в рамках IETF или других организаций по стандартизации.

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

7.3. Возможности конкретного оператора

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

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

7.4. Поддержка множества услуг

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

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

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

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

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

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

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

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

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

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

Документ целиком посвящен вопросам, связанным с управлением сетями и услугами.

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

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

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

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

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

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

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

[RFC3444] Pras, A. and J. Schoenwaelder, “On the Difference between Information Models and Data Models”, RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.

[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>.

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

[BGP-L3VPN-YANG] Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. Wen, “Yang Data Model for BGP/MPLS L3 VPNs”, Work in Progress, draft-dhjain-bess-bgp-l3vpn-yang-02, August 2016.

[EVPN-YANG] Brissette, P., Sajassi, A., Shah, H., Li, Z., Tiruveedhula, K., Hussain, I., and J. Rabadan, “Yang Data Model for EVPN”, Work in Progress, draft-ietf-bess-evpn-yang-03¹³, October 2017.

[L2VPN-SERVICE] Wen, B., Fioccola, G., Xie, C., and L. Jalil, “A YANG Data Model for L2VPN Service Delivery”, Work in Progress, draft-ietf-l2sm-l2vpn-service-model-04¹⁴, October 2017.

[L2VPN-YANG] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., and K. Tiruveedhula, “YANG Data Model for MPLS-based L2VPN”, Work in Progress, draft-ietf-bess-l2vpn-yang-07¹⁵, October 2017.

[MEF-55] MEF Forum, “Lifecycle Service Orchestration (LSO): Reference Architecture and Framework”, Service Operations Specification MEF 55, March 2016.

[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>.

[RFC7149] Boucadair, M. and C. Jacquenet, “Software-Defined Networking: A Perspective from within a Service Provider Environment”, RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.

[RFC7223] Bjorklund, M., “A YANG Data Model for Interface Management”, RFC 7223, DOI 10.17487/RFC7223, May 2014, <https://www.rfc-editor.org/info/rfc7223>.

[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, “IP Connectivity Provisioning Profile (CPP)”, RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>.

[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>.

[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, “Software-Defined Networking (SDN): Layers and Architecture Terminology”, RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.

[RFC7491] King, D. and A. Farrel, “A PCE-Based Architecture for Application-Based Network Operations”, RFC 7491, DOI 10.17487/RFC7491, March 2015, <https://www.rfc-editor.org/info/rfc7491>.

[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>.

[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, “YANG Data Model for L3VPN Service Delivery”, RFC 8049, DOI 10.17487/RFC8049, February 2017, <https://www.rfc-editor.org/info/rfc8049>.

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

Спасибо Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert Sparks, Tom Petch, David Sinicrope и Deborah Brungard за рецензии и комментарии.

Спасибо Dean Bogdanovic, Tianran Zhou и Carl Moberg за помощь в координации с [RFC8199].

Большое спасибо Jerry Bonner, обнаружившему мелкую, но важную опечатку в одном слове.

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

Qin Wu

Huawei Technologies

Email: bill.wu@huawei.com

Will Liu

Huawei Technologies

Email: liushucheng@huawei.com

Adrian Farrel

Juniper Networks

Email: afarrel@juniper.net

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

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

nmalykh@protokols.ru