RFC 5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols

Network Working Group                                        I. Chakeres
Request for Comments: 5498                                        CenGen
Category: Standards Track                                     March 2009

 

PDF

Значения, выделенные IANA для сетей MANET

IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols

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

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

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

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

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

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Тезисы

В документе рассмотрены несколько выделенных агентством IANA значений для использования в протоколах MANET1. К числу этих значений относятся номер порта UDP, номер протокола IP, групповой адрес для локального канала.

Оглавление

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

1. Введение

В этом документе приведены выделенные агентством IANA значения для использования одним или множеством протоколов, соответствующих [RFC5444]. Обязательными являются общепринятые значения для номера порта UDP, номера протокола IP и группового адреса для локального канала. Все интероперабельные протоколы, работающие с общепринятыми значениями, выделяемыми IANA, должны соответствовать [RFC5444]. В [RFC5444] описаны общие форматы, которые позволяют одному или множеству протоколов совместно использовать выделенные IANA значения, описанные в данном документе без возникновения неоднозначностей.

2. Используемые соглашения

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

3. Номер порта UDP

Маршрутизаторам MANET нужен общеизвестный номер порта UDP [IANA] для отправки и получения пакетов протоколов маршрутизации MANET. Для этого порта выбрано имя manet и номер UDP 269.

4. Номер протокола IP

Маршрутизаторам MANET нужен общеизвестный номер протокола IP [IANA] для отправки и получения пакетов протоколов маршрутизации MANET. Для этого протокола выбрано имя manet и номер IP 138.

5. Групповой адрес канального уровня для маршрутизаторов MANET

Маршрутизаторам MANET нужен общеизвестный групповой адрес link-local (LL) [RFC4291] для отправки и получения пакетов протоколов маршрутизации MANET. Для этого адреса выбрано имя LL-MANET-Routers.

Для IPv4 требуется общеизвестный адрес с зоной действия «локальный канал» (link-local). В качестве адреса LL-MANET-Routers выделено значение 224.0.0.109.

Для IPv6 требуется общеизвестный адрес с зоной действия «локальный канал» (link-local). В качестве адреса LL-MANET-Routers выделено значение FF02:0:0:0:0:0:0:6D.

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

В этом документе перечислены несколько выделяемых агентством IANA общепринятых значений для использования одним или множеством протоколов, соответствующих [RFC5444]. В частности, выделен номер порта UDP (Раздел 3), номер протокола IP (Раздел 4) и групповой адрес link-local (Раздел 5).

Действие 1:

Агентство IANA включает в реестр PORT NUMBERS (номера портов) запись

      sub-registry "WELL KNOWN PORT NUMBERS"
      Keyword Decimal Description     References
      ------- ------- -----------     ----------
      manet   269/udp MANET Protocols [RFC5498]

 

Действие 2:

Агентство IANA включает в реестр PROTOCOL NUMBERS (номера протоколов) запись

      sub-registry "WELL KNOWN PORT NUMBERS"
      Keyword Decimal Description     References
      ------- ------- -----------     ----------
      manet   138     MANET Protocols [RFC5498]

 

Действие 3:

Агентство IANA включает в реестр Internet Multicast Addresses (групповые адреса IP) запись

      sub-registry "224.0.0.0 - 224.0.0.255 (224.0.0/24) Local Network Control Block"
      224.0.0.109 LL-MANET-Routers   [RFC5498]

 

Действие 4:

Агентство IANA включает в реестр INTERNET PROTOCOL VERSION 6 MULTICAST ADDRESSES (групповые адреса IPv6) запись

      sub-registry "Fixed Scope Multicast Addresses"
      sub-sub-registry "Link-Local Scope"
      FF02:0:0:0:0:0:0:6D LL-MANET-Routers [RFC5498]

 

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

Этот документ лишь задает общепринятые значения для протоколов, соответствующих [RFC5444], и не содержится спецификации протоколов, передающих информацию через сеть. Каждый протокол, использующий описанные здесь значения, может иметь свои вопросы, связанные с безопасностью, но на эти вопросы не оказывает влияние применение описанных здесь значений, выделенных IANA.

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

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

Fred Templin, Bill Fenner, Alexandru Petrescu, Sam Weiler, Ross Callon и Lars Eggert внесли значительный вклад в подготовку этого документа.

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

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

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

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, «Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format», RFC 5444, February 2009.

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

[IANA] http://www.iana.org/

Адрес автора

Ian D Chakeres

CenGen

9250 Bendix Road North

Columbia MD 21045 USA

EMail: ian.chakeres@gmail.com

URI: http://www.ianchak.com/

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

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

nmalykh@gmail.com


1Mobile Ad hoc NETwork — мобильная сеть специального назначения.




RFC 5427 Textual Conventions for Syslog Management

Network Working Group                                           G. Keeni
Request for Comments: 5427                          Cyber Solutions Inc.
Category: Standards Track                                     March 2009

Текстовые соглашения для управления Syslog

Textual Conventions for Syslog Management

PDF

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

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

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

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

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

Этот документ может содержать материалы из документов IETF или участников IETF1, опубликованных или публично доступных до 10 ноября 2008 г. Лица, контролирующие авторские права на некоторые из таких материалов могли не предоставить IETF Trust прав на изменение таких материалов вне контекста стандартизации IETF2. Без получения соответствующей лицензии от лиц, контролирующих авторские права на такие материалы, этот документ не может быть изменен вне контекста стандартизации IETF, а также не могут открываться производные работы за пределами контекста стандартизации. Исключением является лишь форматирование документа для публикации в качестве RFC или перевод на другие языки.

Тезисы

Этот модуль MIB определяет текстовые соглашения для представления информации Facility и Severity, обычно используемой в сообщениях syslog. Цель заключается в том, чтобы сделать эти текстовые соглашения импортируемыми и применимыми в других модулях MIB, которым иначе пришлось бы определять свое представление.

Оглавление

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

 

1. Стандартная модель управления Internet

Подробный обзор документов, описывающих современную схему стандартного управления в Internet (Internet-Standard Management Framework), приведен в разделе 7 документа RFC 3410 [RFC3410].

Доступ к объектам управления выполняется через виртуальное информационное хранилище, называемое базой данных управления или MIB3. Доступ к объектам MIB обычно осуществляется по протоколу SNMP4. Объекты в MIB определяются с использованием механизмов, описанных в структуре SMI5. В этом документе описан модуль MIB, соответствующий спецификации SMIv2, описанной в STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] и STD 58, RFC 2580 [RFC2580].

2. Основы

Операционные системы, процесс и приложения, совокупно называемые далее «источники» (Facilities), генерируют сообщения, показывающие их состояние или происходящие события. Эти сообщения называют сообщениями syslog. В общем случае сообщения syslog наряду с другой информацией включают код, представляющий источник сообщения (Facility), и код, представляющий уровень важности сообщения (Severity). Коды Facility и Severity обычно используются для категоризации и отбора полученных сообщений при их обработке и отображении. Коды Facility полезны для отбора инициатора содержимого сообщений, но не всегда достаточно конкретны для четкой идентификации инициатора. Реализациям протокола syslog [RFC5424], содержащим структурированные элементы данных (SDE6), следует использовать эти SDE для определения элемента, служащего источником содержимого сообщения.

В этом документе определен набор текстовых соглашения (TC7), которые могут применяться для представления кодов Facility и Severity, обычно используемых в сообщениях syslog.

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

3. MIB для текстовых соглашений Syslog

   SYSLOG-TC-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, mib-2
                 FROM SNMPv2-SMI        -- [RFC2578]
       TEXTUAL-CONVENTION
                 FROM SNMPv2-TC;        -- [RFC2579]

   syslogTCMIB  MODULE-IDENTITY
       LAST-UPDATED "200903300000Z"     --  30 марта 2009 г.
       ORGANIZATION "IETF Syslog Working Group"
       CONTACT-INFO
       "                      Glenn Mansfield Keeni
                      Postal: Cyber Solutions Inc.
                              6-6-3, Minami Yoshinari
                              Aoba-ku, Sendai, Japan 989-3204.
                         Tel: +81-22-303-4012
                         Fax: +81-22-303-4015
                       EMail: glenn@cysols.com

         Support Group EMail: syslog@ietf.org
         "

       DESCRIPTION
           "Модуль MIB, содержащий текстовые соглашения для сообщений syslog.

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

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

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

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

            - Названия Internet Society, IETF, IETF а также названия других
              конкретных участников не могут использоваться для одобрения или
              продвижения продукции, основанной на этой программе, без
              предварительного письменного разрешения.

            THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
            CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
            WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
            WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
            PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
            OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
            INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
            (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
            GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
            BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
            LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
            (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
            OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
            POSSIBILITY OF SUCH DAMAGE.

            Эта версия данного модуля MIB является частью 5427;
            правовые аспекты полностью приведены в этом RFC.
           "

       REVISION "200903300000Z"     --  30 March 2009
       DESCRIPTION
           "Исходная версия, опубликованная в RFC 5427."

       ::= { mib-2 173 }

   -- -------------------------------------------------------------
   -- Текстовые соглашения
   -- -------------------------------------------------------------

   SyslogFacility  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "В этих текстовых соглашениях перечислены объекты (Facility), 
            являющиеся источниками сообщений syslog.

            Значения Facility в сообщениях syslog задаются кодами в форме
            десятичных чисел. Для интероперабельности и совместимости с
            более ранними версиями данный документ задает нормативное отображение
            между метками, представляющими значения Facility, и соответствующими
            числовыми кодами. Метки могут применяться, например, в пользовательских
            интерфейсах приложений SNMP.

            Метка зачастую семантически бессмысленна, поскольку неразумно пытаться
            перечислить все возможные варианты Facility, а для многих демонов и
            процессов нет явно выделенного кода или метки Facility. Например, нет
            метки Facility, соответствующей сервису HTTP. Реализации служб HTTP
            могут генерировать сообщения, например, с метками local7 или uucp.
            Это обычная практика, поскольку инициаторы, трансляторы и коллекторы 
            могут настраиваться на подобающую обработку таких ситуаций. Для повышения
            точности приложение может также включать структурированные данные APP-NAME.

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

            В частности, метки, соответствующие кодам Facility 4, 10, 13 и 14,
            и коду для метки cron, существенно различаются в разных операционных
            системах. Для того, чтобы различать метки, соответствующие кодам 9 и 15,
            метке cron2 был присвоен код 15. Приведенный список не является полным
            и могут существовать другие отличия, которые могут появляться и впредь.

            Указанное здесь отображение ДОЛЖНО использоваться в интерфейсе MIB, хотя
            для конкретных реализаций syslog могут применяться иные отображения в других
            интерфейсах сетевого управления.
           "
       REFERENCE "Протокол Syslog (RFC5424), таблица 1"
       SYNTAX  INTEGER
            {

              kern            (0), -- сообщения ядра
              user            (1), -- сообщения пользовательского уровня
              mail            (2), -- сообщения почтовой системы
              daemon          (3), -- сообщения системных демонов
              auth            (4), -- проверка полномочий
              syslog          (5), -- внутренние сообщения syslogd
              lpr             (6), -- сообщения подсистемы печати
              news            (7), -- сообщения подсистемы сетевых новостей
              uucp            (8), -- сообщения подсистемы UUCP
              cron            (9), -- сообщения демона часов
              authpriv        (10),-- сообщения системы защиты и проверки полномочий
              ftp             (11),-- сообщения демона ftp
              ntp             (12),-- сообщения подсистемы NTP
              audit           (13),-- сообщения аудита
              console         (14),-- консольные сообщения
              cron2           (15),-- сообщения демона часов
              local0          (16),
              local1          (17),
              local2          (18),
              local3          (19),
              local4          (20),
              local5          (21),
              local6          (22),
              local7          (23)
            }

   SyslogSeverity  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "В этих текстовых соглашениях перечислены уровни важности (Severity)
            сообщений syslog.

            Уровни Severity в сообщениях syslog указываются десятичными числами.
            Для интероперабельности и совместимости си совместимости с более
            ранними версиями данный документ задает нормативное отображение
            между метками, представляющими значения Severity и соответствующими
            числовыми кодами. Метки могут применяться, например, в пользовательских
            интерфейсах приложений SNMP.

            Метка зачастую семантически бессмысленна, поскольку неразумно пытаться
            перечислить все возможные варианты Severity, а критерии, используемые
            инициаторами syslog, исторически зависят от реализации.

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

            Например, приложение foobar может помечать сообщения как crit на 
            основе некого субъективного критерия. Оператор может настроить syslog на 
            пересылку сообщений, несмотря на то, что трактовка crit может различаться
            у разных инициаторов. Это обычная практика, поскольку инициаторы, 
            трансляторы и коллекторы могут настраиваться на подобающую обработку 
            таких ситуаций.
           "
       REFERENCE "Протокол Syslog (RFC5424): Таблица 2"
       SYNTAX  INTEGER
            {
              emerg           (0),  -- чрезвычайная ситуация, система не может использоваться
              alert           (1),  -- тревога, требуются незамедлительные действия
              crit            (2),  -- критическая ситуация
              err             (3),  -- ошибка
              warning         (4),  -- предупреждение
              notice          (5),  -- нормальная но важная ситуация (состояние)
              info            (6),  -- информационное сообщение
              debug           (7)   -- отладочное сообщение
            }
   END

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

Модуль не определяет каких-либо элементов управления, определены лишь текстовые соглашения, которые могут применяться другими модулями MIB для определения объектов управления. Значимые проблемы безопасности могут быть вызваны только модулями MIB, определяющими объекты управления. Следовательно, этот документ не оказывает влияния на безопасность Internet. Поскольку объекты, определенные с использованием описанных здесь TC, могут создавать проблемы безопасности, пользователям этих TC следует прочесть раздел «Вопросы безопасности» в [RFC5424].

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

Модули MIB в этом документе используют приведенное в таблице значение OBJECT IDENTIFIER, выделенное IANA и включенное в реестр SMI Numbers.

Дескриптор

Значение OBJECT IDENTIFIER

syslogTCMIB

{ mib-2 173 }

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

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

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

[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Textual Conventions for SMIv2», STD 58, RFC 2579, April 1999.

[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Conformance Statements for SMIv2», STD 58, RFC 2580, April 1999.

[RFC5424] Gerhards, R., «The Syslog Protocol», RFC 5424, March 2009.

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

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, «Introduction and Applicability Statements for Internet-Standard Management Framework», RFC 3410, December 2002.

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

Этот документ является результатом работы группы Syslog. Автор благодарит Chris Lonvick, David Harrington, Juergen Schoenwaelder и Pasi Eronen за их комментарии и предложения.

Адрес автора

Glenn Mansfield Keeni

Cyber Solutions Inc.

6-6-3 Minami Yoshinari

Aoba-ku, Sendai 989-3204

Japan

Phone: +81-22-303-4012

EMail: glenn@cysols.com

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

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

nmalykh@gmail.com

1В оригинале — IETF Contributions. Прим. перев.

2В оригинале — IETF Standards Process. Прим. перев.

3Management Information Base.

4Simple Network Management Protocol — простой протокол сетевого управления.

5Structure of Management Information — структура данных управления.

6Structured data element.

7Textual convention.




RFC 5426 Transmission of Syslog Messages over UDP

Network Working Group                                       A. Okmianski
Request for Comments: 5426                           Cisco Systems, Inc.
Category: Standards Track                                     March 2009

Передача сообщений Syslog по протоколу UDP

Transmission of Syslog Messages over UDP

PDF

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

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

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

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

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

Этот документ может содержать материалы из документов IETF или участников IETF1, опубликованных или публично доступных до 10 ноября 2008 г. Лица, контролирующие авторские права на некоторые из таких материалов могли не предоставить IETF Trust прав на изменение таких материалов вне контекста стандартизации IETF2. Без получения соответствующей лицензии от лиц, контролирующих авторские права на такие материалы, этот документ не может быть изменен вне контекста стандартизации IETF, а также не могут открываться производные работы за пределами контекста стандартизации. Исключением является лишь форматирование документа для публикации в качестве RFC или перевод на другие языки.

Тезисы

Этот документ описывает транспортировку сообщений syslog на основе протоколов UDP/IPv4 и UDP/IPv6. Многоуровневая архитектура syslog обеспечивает поддержку любого числа транспортных протоколов. Однако для обеспечения интероперабельности реализации протокола syslog должны поддерживать описанное здесь транспортное отображение.

Оглавление

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

1. Введение

В информационном RFC 3164 [8] описаны имеющиеся реализации протокола syslog. Там описан как формат сообщений syslog, так и их передача по протоколу UDP [1]. В последствии был предложен проект стандарта (Standards-Track) для протокола syslog в RFC 5424 [2].

RFC 5424 задает многоуровневую архитектуру, обеспечивающую поддержку любого числа транспортных отображений для передачи сообщений syslog. Данный документ описывает транспортное отображение UDP для протокола syslog.

Описанный в этом документе транспорт может применяться для передачи сообщений как через IPv4 [3], так и через IPv6 [4].

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

2. Соглашения об уровнях требований

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

3. Транспортный протокол

3.1. Одно сообщение на дейтаграмму

Каждая дейтаграмма UDP должна содержать только одно сообщение syslog, которое может быть полным или усеченным. Форматирование и отсечка сообщений должны соответствовать RFC 5424 [2]. Включать в дейтаграммы дополнительные данные недопустимо.

3.2. Размер сообщения

Это транспортное отображение поддерживает передачу сообщений syslog размером до 65535 октетов минус размер заголовка UDP. Этот предел основан на максимальном размере дейтаграмм UDP в 65535 октетов, заданном в RFC 768 [1]. Для IPv4 максимальный размер данных (payload) составляет 65535 минус размер заголовков UDP и IP, поскольку IPv4 имеет 16-битовое поле размера, которое учитывает и размер заголовков.

В IPv4 получатели syslog должны быть способны принимать дейтаграммы размером до 480 октетов, включительно, а в IPv6 получатели syslog должны быть способны принимать дейтаграммы размером до 1180, включительно. Всем получателям syslog следует поддерживать возможность приема дейтаграмм размером до 2048, включительно. Рекомендуется принимать и более крупные сообщения.

Приведенные выше ограничения и рекомендации создают базу для взаимодействия. Минимальный поддерживаемый размер определен на основе минимального значения MTU, которое должны поддерживать хосты Internet — 576 октетов для IPv4 [3] и 1280 октетов для IPv6 [4]. Дейтаграммы, соответствующие этим ограничениям, имеют наилучшие шансы доставки, поскольку для них заведомо не требуется фрагментирования.

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

Фрагментация может быть нежелательной, поскольку она повышает риск потери сообщения в результате потери единственного фрагмента. Протокол syslog не имеет механизма подтверждений и, следовательно, — эффективного способа организации повторной передачи. Это не позволяет использовать в syslog средства определения MTU для пути на уровне пакетизации [9]. если значение MTU в сети неизвестно заранее, лучшим выходом будет предположить минимальное значение в 480 октетов для IPv4 b 1180 для IPv6.

3.3. Порты источника и адресата

Получатели syslog должны поддерживать прием дейтаграмм через общеизвестный порт UDP 514, но могут настраиваться на другой порт-получатель. Отправители syslog должны адресовать дейтаграммы с сообщениями syslog в порт UDP 514, но могут быть настроены на работу через иной порт. Отправители syslog могут использовать любой порт отправителя UDP для передачи сообщений.

3.4. IP-адрес источника

IP-адрес отправителя в дейтаграммах UDP не следует трактовать как адрес хоста-инициатора сообщения syslog. Отправителем сообщения syslog может оказаться транслятор. Адрес инициатора содержится в самом сообщении syslog.

3.5. Структура UDP/IP

Каждая дейтаграмма UDP/IP, передаваемая транспортным отправителем, должна полностью соответствовать структуре, указанной в UDP RFC 768 [1] и IPv4 RFC 791 [3] или IPv6 RFC 2460 [4] в зависимости от используемого протокола.

3.6. Контрольные суммы UDP

Отправителям syslog недопустимо отключать контрольные суммы UDP. Отправителям IPv4 syslog следует использовать контрольные суммы UDP при передаче сообщений. Отметим, что RFC 2460 [4] требует использования контрольных сумм UDP при передаче дейтаграмм UDP по протоколу IPv6.

Получателям syslog недопустимо отключать контрольные суммы UDP. Получателям IPv4 syslog следует проверять контрольные суммы UDP, а также следует воспринимать сообщения syslog с нулевой контрольной суммой. Отметим, что RFC 2460 [4] требует использования контрольных сумм UDP при передаче по протоколу IPv6.

4. Вопросы надежности

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

4.1. Потеря дейтаграмм

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

4.2. Повреждение сообщений

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

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

Поскольку syslog может создавать неограниченный объем данных, передача этих данных по протоколу UDP в общем случае проблематична, поскольку в UDP нет механизмов контроля перегрузок. Механизмы, реагирующие на перегрузки снижением скорости передачи трафика и обеспечивающее беспристрастное разделение ресурсов между потоками, использующими общий путь, имеют очень важное значение для стабильной работы Internet [6]. Именно по этой причине транспорт TLS для syslog [7] требуется от всех реализаций и рекомендуется для общего применения.

Единственным вариантом, где для syslog может использоваться транспорт UDP в качестве альтернативы транспорту TLS, являются управляемые сети, в которых явно обеспечиваются пути для трафика UDP syslog с использованием механизмов организации трафика типа ограничения скорости или резервирования пропускной способности. Во всех прочих средах следует использовать транспорт TLS [7].

4.4. Порядок доставки

Транспорт IP, используемый протоколом UDP, не гарантирует упорядоченной доставки дейтаграмм. Временные метки в каждом сообщении syslog могут применяться для восстановления порядка. Однако это не поможет в тех случаях, когда в одном интервале отсчета времени создается множество сообщений, отправитель не может создавать временные метки или сообщения приходят от разных хостов, часы которых не синхронизированы. Порядок доставки сообщений syslog с использованием данного транспорта не следует использовать в качестве основы для восстановления абсолютного или относительного порядка событий на создавших сообщения syslog хостах.

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

Использовать данную спецификацию в незащищенных сетях не рекомендуется. Некоторые вопросы безопасности syslog рассмотрены в RFC 5424 [2]. В этом разделе рассмотрены конкретные вопросы безопасности при доставке сообщений syslog по протоколу UDP. Некоторые из отмеченных ниже проблем безопасности можно смягчить за счет применения IPsec в соответствии с RFC 4301 [10].

5.1. Проверка подлинности отправителя и подмена сообщений

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

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

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

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

5.2. Раскрытие сообщений

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

5.3. Повторное использование сообщений

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

5.4. Ненадежность доставка

Как было отмечено в разделе 4. Вопросы надежности, транспорт UDP не является надежным и пакеты с дейтаграммами сообщений syslog могут теряться в процессе передачи без уведомления об этом. Потеря одного или множества сообщений syslog может иметь последствия для безопасности. Администраторы могут не узнать о возникновении и развитии той или иной потенциально серьезной проблемы. Сообщения могут также перехватываться и отбрасываться злоумышленниками для сокрытия своей деятельности.

5.5. Приоритизация и дифференцирование сообщений

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

5.6. Отказ служб

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

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

Этот транспорт использует порт UDP 514 для syslog, как указано в реестре IANA для номеров портов.

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

Автор благодарит участников работы над документом: Chris Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova, Devin Kowatch, Richard Graveman и все другие люди, приславшие комментарии к разным версиям этого предложения.

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

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

[1] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

[2] Gerhards, R., «The Syslog Protocol», RFC 5424, March 2009.

[3] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[4] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

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

[6] Floyd, S., «Congestion Control Principles», BCP 41, RFC 2914, September 2000.

[7] Miao, F. and Y. Ma, «TLS Transport Mapping for Syslog», RFC 5425, March 2009.

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

[8] Lonvick, C., «The BSD Syslog Protocol», RFC 3164, August 2001.

[9] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[10] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.


Адрес автора

Anton Okmianski

Cisco Systems, Inc.

595 Burrard St., Suite 2123

Vancouver, BC V7X 1J1

Canada

Phone: +1-978-936-1612

EMail: aokmians@cisco.com


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

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

nmalykh@gmail.com

1В оригинале — IETF Contributions. Прим. перев.

2В оригинале — IETF Standards Process. Прим. перев.




RFC 5440 Path Computation Element (PCE) Communication Protocol (PCEP)

Network Working Group                                   JP. Vasseur, Ed.
Request for Comments: 5440                                 Cisco Systems
Category: Standards Track                               JL. Le Roux, Ed.
                                                          France Telecom
                                                              March 2009

Коммуникационный протокол PCE (PCEP)

Path Computation Element (PCE) Communication Protocol (PCEP)

PDF

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

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

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

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

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

Этот документ может содержать материалы из документов IETF или участников IETF, опубликованных или публично доступных до 10 ноября 2008 г. Лица, контролирующие авторские права на некоторые из таких материалов могли не предоставить IETF Trust прав на изменение таких материалов вне контекста стандартизации IETF. Без получения соответствующей лицензии от лиц, контролирующих авторские права на такие материалы, этот документ не может быть изменен вне контекста стандартизации IETF, а также не могут открываться производные работы за пределами контекста стандартизации. Исключением является лишь форматирование документа для публикации в качестве RFC или перевод на другие языки.

Тезисы

Этот документ задает протокол взаимодействия элементов расчета пути PCE (PCEP) для коммуникаций между клиентами PCC и PCE или между парой PCE. Такие взаимодействия включают запросы расчета пути и отклики на них, а также уведомления о конкретных состояниях, относящиеся к использованию PCE в контексте MPLS1 и организации трафика GMPLS2. Протокол PCEP разработан с учетом обеспечения гибкости и расширяемости для того, чтобы можно было легко добавлять сообщения и объекты, поэтому в будущем возможно определение новых требований.

Оглавление

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

1. Введение

В [RFC4655] описана мотивация и архитектура элемента расчета пути (PCE) на основе моделей расчета MPLS и GMPLS TE LSP. Модель позволяет отделить PCE от клиента расчета путей (PCC), а также разрешает кооперацию PCE. Для этого нужен коммуникационный протокол между PCC PCE, а также между PCE. В [RFC4657] приведены базовые требования к такому протоколу, включая требование использования единого протокола для коммуникаций между PCC и PCE, а также между PCE. Зависящие от приложений требования (например, для коммуникаций внутри области или автономной системы и т. п.) не включены в [RFC4657], но указно требование простой расширяемости протокола для удовлетворения требований, задаваемых документами для конкретных приложений. Примерами таких документов служат [RFC4927], [RFC5376] и [INTER-LAYER].

В этом документе описан протокол расчета элемента пути (PCEP3) для коммуникаций между PCC и PCE или между парой PCE в соответствии с [RFC4657]. Такие взаимодействия включают запросы расчета пути и отклики на эти запросы, а также уведомления о конкретных состояниях, связанных с использованием PCE в контексте организации трафика MPLS и GMPLS.

Протокол PCEP разработан с учетом гибкости и расширяемости для обеспечения простого добавления в будущем сообщений и объектов.

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

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

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

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

AS

Автономная система.

Explicit path — явный путь

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

IGP area — область IGP

Область OSPF или уровень IS-IS.

Inter-domain TE LSP — междоменный TE LSP

TE LSP, проходящий по меньшей мере через два разных домена, где домены могут быть областями IGP, автономными системами или суб-AS (конфедерация BGP).

PCC

Клиент расчета пути — любое клиентское приложение, запрашивающее расчет пути у PCE.

PCE

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

PCEP Peer

Элемент, участвующий в сессии PCEP (т. е. PCC или PCE).

TED

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

TE LSP

Путь с коммутацией по меткам и организацией трафика.

Strict/loose path

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

В этом документе при описании взаимодействия между PCE запрашивающий PCE играет роль PCC. Это позволяет сократить объем документа без потерь.

Формат сообщений в документе задается кодом Бэкуса-Наура (BNF), описанным в [RBNF].

3. Допущения

В [RFC4655] описаны разные типы PCE. Протокол PCEP не принимает каких-либо допущений и не вносит ограничений на природу PCE.

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

Не делается предположений о методах, применяемых PCC для обнаружения набора PCE (например, статическая настройка или динамическое детектирование), и алгоритмах выбора PCE. В [RFC4674] определен список требования для динамического обнаружения PCE, а основанные на IGP решения для этого указаны в [RFC5088] и [RFC5089].

4. Обзор архитектуры протокола (модель)

Целью этого раздела является описание модели PCEP в стиле [RFC4101]. Представлен архитектурный обзор (картина в целом) протокола, а детали описаны в последующих разделах.

4.1. Постановка задачи

Основанная на PCE архитектура расчета путей для MPLS и GMPLS TE LSP описана в [RFC4655]. При раздельном размещении PCC и PCE нужен протокол для их взаимодействия. PCEP является протоколом, разработанным специально для связи между PCC и PCE или между парой PCE в соответствии с [RFC4657] — PCC может применять PCEP для отправки запросов расчета пути одного или множества TE LSP элементу PCE, а тот может возвращать набор рассчитанных путей, если одни или несколько найденных путей отвечают заданному набору ограничений.

4.2. Обзор архитектуры протокола

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

Определено несколько типов сообщений PCEP, пересичленных ниже.

  • Open и Keepalive служат для организации и поддержки сессии PCEP, соответственно.

  • PCReq передается PCC элементу PCE для запроса расчета пути.

  • PCRep передается PCE клиенту PCC для ответа на запрос расчета пути. Сообщение может содержать набор рассчитанных путей, если запрос был выполнен, или отрицательный отклик в противном случае (этот отклик может указывать причины, по которым путь не был найден).

  • PCNtf передается от PCC к PCE или обратно для уведомления о конкретном событии.

  • PCErr передается при возникновении протокольной ошибки.

  • Close служит для завершения сессии PCEP.

Набор доступных PCE можно статически задать в конфигурации PCC или определять динамически. Механизмы обнаружения и выбора PCE выходят за рамки этого документа.

PCC может иметь сессии PCEP со множеством PCE, а PCE может иметь сессии PCEP со множеством PCC.

Каждое сообщение PCEP рассматривается как единый блок передачи и чередование частей сообщений недопустимо. Например, PCC, передавший сообщение PCReq и желающий закрыть сессию должен завершить отправку запроса и лишь после этого передавать сообщение Close.

4.2.1. Фаза инициализации

Фаза инициализации состоит из 2 последовательных этапов, схематически представленных на рисунке 1.

  1. Организация соединения TCP (3-этапное согласование) между PCC и PCE.

  2. Организация сессии PCEP через соединение TCP.

После организации соединения TCP клиент PCC и элемент PCE (партнеры PCEP) инициируют организацию сессии PCEP с согласованием различных параметров этой сессии. Параметры передаются в сообщениях Open и включают таймер Keepalive, DeadTimer, а также могут подробно указывать возможности и правила, задающие условия, при которых запросы расчета пути могут передаваться элементу PCE. Если при организации сессии PCEP возник отказ по причине несогласия партнеров PCEP по части параметров сессии или отсутствия ответа одного из партнеров в течение времени на организацию сессии, соединение TCP незамедлительно разрывается. Последующие попытки разрешены, но реализации следует использовать экспоненциально нарастающие интервалы между такими попытками.

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

Описания сообщений Open и Keepalive приведены в параграфах 6.2 и 6.3, соответственно.

+-+-+                 +-+-+
|PCC|                 |PCE|
+-+-+                 +-+-+
  |                     |
  | Сообщ. Open         |
  |--------             |
  |        \ Сообщ. Open|
  |         \  ---------|
  |          \/         |
  |          /\         |
  |         /  -------->|
  |        /            |
  |<------     Keepalive|
  |             --------|
  |Keepalive   /        |
  |--------   /         |
  |        \/           |
  |        /\           |
  |<------   ---------->|
  |                     |

Рисунок 1. Фаза инициализации PCEP (запускается PCC).


Отметим, что после организации сессии PCEP обмен сообщениями Keepalive не является обязательным.

4.2.2. Сообщения о сохранении активности

После организации сессии PCE или PCC может захотеть получать информацию о доступности своего партнера PCEP.

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

Для таких случаев в PCEP предусмотрен механизм информирования на основе таймеров Keepalive и DeadTimer, а также сообщений Keepalive.

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

Участники сессии PCEP запускают также DeadTimer, который сбрасывается при получении в сессии любого сообщения. Если в интервале DeadTimer не было получено ни одного сообщения, сессия считается «умершей».

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

Трафик сохранения активности в сессии может оказаться несбалансированным по причине разных требований сторон. Каждый из партнеров может указать в сообщении Open значения таймеров Keepalive (интервал отправки сообщений Keepalive при отсутствии другого трафика) и DeadTimer (т. е. интервал отсутствия трафика, после которого сессия считается «мертвой»), рекомендуемые для партнера. Стороны могут применять разные значения таймера Keepalive.

Минимальное значение таймера Keepalive составляет 1 секунду и указывается в секундах. Рекомендуется интервал 30 секунд. Таймер можно отменить, установив для него нулевое значение.

Для таймера DeadTimer рекомендуется устанавливать по умолчанию значение, превышающее в 4 раза значение таймера Keepalive у партнера. Это предотвращает перегрузку соединения TCP избыточными сообщениями Keepalive.

4.2.3. Запрос расчета пути от PCC к PCE

                  +-+-+                  +-+-+
                  |PCC|                  |PCE|
                  +-+-+                  +-+-+
1) Событие расчета  |                      |
   пути             |                      |
2) Выбор PCE        |                      |
3) Запрос расчета   |-- Сообщение PCReq -->|
   пути отправлен   |                      |
   выбранному PCE   |                      |

Рисунок 2. Запрос расчета пути.


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

Как только PCC выбрал элемент PCE, он передает тому запрос расчета пути (сообщение PCReq), содержащий различные объекты, задающие набор ограничений на расчет пути. Например, «рассчитать путь TE LSP от IP=x.y.z.t, до IP=x’.y’.z’.t’ с пропускной способностью B Мбит/с, приоритетом Setup/Holding=P, …» В дополнение PCC может указать важность запроса, задав для него приоритет. Каждый запрос однозначно указывается номером (request-id) и парой адресов PCC-PCE. Процесс схематически показан на рисунке 2. Отметим, что PCC может в любой момент отправить PCE множество запросов расчета путей.

Описание сообщения PCReq дано в параграфе 6.4.

4.2.4. Отклик на запрос расчета пути от PCE к PCC


+-+-+                  +-+-+
|PCC|                  |PCE|
+-+-+                  +-+-+
  |                      |
  |-- Сообщение PCReq -->|
  |                      |1) Получен запрос
  |                      |   расчета пути
  |                      |
  |                      |2) Пути рассчитаны
  |                      |   
  |                      |
  |                      |3) Рассчитанные пути
  |                      |   отправлены PCC
  |                      |
  |-- Сообщение PCRep -->|
  |  (позитивный отклик) |

Рисунок 3a. Успешный расчет пути.

+-+-+                  +-+-+
|PCC|                  |PCE|
+-+-+                  +-+-+
  |                      |
  |                      |
  |-- Сообщение PCReq -->|
  |                      |1) Получен запрос
  |                      |   расчета пути
  |                      |
  |                      |2) Удовлетворяющего запросу
  |                      |   пути не найдено
  |                      |
  |                      |3) Передается негативный отклик
  |                      |   клиент PCC (возможно, с
  |                      |   дополнительной информацией)
  |                      |   
  |-- Сообщение PCRep -->|
  |  (негативный отклик) |

Рисунок 3b. Неудачный расчет пути.


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

  • Позитивный (рисунок 3a) — PCE выполняет расчет пути, удовлетворяющего заданному набору ограничений. В этом случае PCE возвращает набор рассчитанных путей запрашивающему PCC. Отметим, что PCEP поддерживает возможность передачи запросов, которые дают множество путей (например, расчет набора путей с разными каналами).

  • Негативный (рисунок 3b) — не найдено пути, соответствующего заданным ограничениям. В этом случае PCE может указать набор ограничений, которые не удалось выполнить. При получении негативного отклика PCC может передать обновленный запрос или предпринять иные действия.

Сообщение PCRep описано в параграфе 6.5.

4.2.5. Уведомление

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

                    +-+-+                  +-+-+
                    |PCC|                  |PCE|
                    +-+-+                  +-+-+
1) Событие расчета    |                      |
   пути               |                      |
2) Выбор PCE          |                      |
3) Запрос расчета     |---Сообщение PCReq--->|
   пути X отправлен   |                      |4) Запрос расчета пути
   выбранному PCE     |                      |   помещен в очередь
                      |                      |
                      |                      |
                      |                      |5) PCE перегружен
                      |                      |
                      |                      |
                      |                      |6) Запрос расчета пути
                      |                      |   X отменен
                      |                      |
                      |<---Сообщение PCNtf---|

Рисунок 4. Пример передачи уведомления PCE (отказ) клиенту PCC.

                    +-+-+                  +-+-+
                    |PCC|                  |PCE|
                    +-+-+                  +-+-+
1) Событие расчета    |                      |
   пути               |                      |
2) Выбор PCE          |                      |
3) Запрос расчета     |---Сообщение PCReq--->|
   пути X отправлен   |                      |4) Запрос расчета пути
   выбранному PCE     |                      |   помещен в очередь
                      |                      |
                      |                      |
5) Запрос расчета     |                      |
   пути X отменен     |                      |
                      |---Сообщение PCNtf--->|
                      |                      |6) Запрос расчета пути
                      |                      |   X отменен

Рисунок 5. Пример передачи уведомления PCC (отмена) элементу PCE.


Описание сообщения PCNtf дано в параграфе 6.6.

4.2.6. Сообщение об ошибке

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

                   +-+-+                  +-+-+
                   |PCC|                  |PCE|
                   +-+-+                  +-+-+
1) Событие расчета   |                      |
   пути              |                      |
2) Выбор PCE         |                      |
3) Запрос расчета    |---Сообщение PCReq--->|
   пути X отправлен  |                      |4) Прием объекта с
   выбранному PCE    |                      |   некорректным форматом
                     |                      |
                     |                      |5) Запрос отброшен
                     |                      |
                     |<---Сообщение PCErr---|
                     |                      |

Рисунок 6. Пример сообщения об ошибке, переданного PCE клиенту PCC.


Сообщение PCErr описано в параграфе 6.7.

4.2.7. Разрыв сессии PCEP

Когда один из партнеров желает прервать сессию PCEP, он сначала передает сообщение Close, а затем разрывает соединение TCP. Если сессия прерывается PCE, клиент PCC сбрасывет все состояния, относящиеся к ожидающим запросам, которые были переданы этому PCE. Если сессию прерывает PCC, элемент PCE сбрасывет все ожидающие запросы от этого PCC, а также связанные с ним состояния. Сообщение Close может передаваться для завершения сессии PCEP лишь в том случае, когда такая сессия была организована. При разрыве соединения TCP сессия PCEP прерывается незамедлительно.

Сообщение Close описано в параграфе Section 6.8.

4.2.8. Краткосрочные и постоянные сессии PCEP

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

5. Транспортный протокол

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

6. Сообщения PCEP

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

В базовом заголовке каждого объекта PCEP определен флаг P (см. параграф 7.2). При установленном флаге объекта в сообщении PCReq элемент PCE должен принять во внимание данные объекта при расчете пути. Например, объект METRIC, определенный в параграфе 7.8, позволяет PCC задать границы приемлемой стоимости пути. Объект METRIC является необязательным, но PCC может установить флаг для принятия во внимание данных этого объекта. В этом случае, если ограничения не может быть учтено, PCE должен генерировать сообщение об ошибке.

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

6.1. Базовый заголовок

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |  Flags  |  Message-Type |       Message-Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Базовый заголовок сообщения PCEP.


Ver (Version — 3 бита)

Номер версии PCEP, 1 для текущей версии.

Flags (5 битов)

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

Message-Type (8 битов)

Определенные в настоящее время типы сообщений указаны в таблице.

Номер

Назначение

1

Open

2

Keepalive

3

Path Computation Request

4

Path Computation Reply

5

Notification

6

Error

7

Close

Message-Length (16 битов)

Общий размер сообщения PCEP с учетом базового заголовка (в байтах).

6.2. Сообщение Open

Сообщения Open передаются от PCC к PCE и от PCE к PCC для организации сессии PCEP. Поле Message-Type в базовом заголовке PCEP сообщения Open имеет значение 1.

После организации соедиения TCP первым сообщением от PCC к PCE или от PCE к PCC должно быть сообщение Open, как указано в приложении A.

Передача любого сообщения до Open должна вызывать протокольную ошибку с возвратом сообщения PCErr с Error-Type «PCEP session establishment failure» и Error-value «reception of an invalid Open message or a non Open message», а попытка организации сессии PCEP должна прерываться разрывом соединения TCP.

Сообщение Open служит для организации сессии между партнерами PCEP. На этапе организации сессии партнеры обмениваются некоторыми характеристиками сеанса. Если обе стороны принимают такие характеристики, сессия PCEP организуется. Формат сообщения Open приведен ниже.

   <Open Message>::= <Common Header>
                     <OPEN>

Сообщение Open должно включать в точности одир объект (параграф 7.3).

В объекте OPEN задаются характеристики сессии. После организации соединения TCP отправитель должен запустить таймер инициализации OpenWait, по истечении которого при отсутствии сообщения Open передается сообщение PCErr и соединение TCP освобождается (приложение A).

После передачи партнеру сообщения Open отправитель должен запустить таймер инициализации KeepWait, по истечении которого при отсутствии сообщения Keepalive или PCErr в случае несогласия с характеристиками сессии должно передавать сообщение PCErr, а соединение TCP должно быть освобождено (приложение A).

Таймеры OpenWait и KeepWait имеют фиксированное значение (1 минута).

При получении сообщения Open приемная сторона должна определить приемлемость предложенных характеристик сессии PCEP. Если принающий партнер не готов воспринять хотя бы одну из предложенных характеристик, он должен передать сообщение об ошибке. В это сообщение следует включить объект OPEN и для каждого неприемлемого параметра сессии следует указать в нем подходящее значение. Партнер PCEP может снова передать сообщение Open с другими характеристиками сессии. Если новое сообщение Open имеет такой же набор характеристик или новые характеристики остаются неприемлемыми, принимающая сторона должна передать сообщение об ошибке и незамедлительно разорвать соединение TCP. Описание сообщений об ошибках дано в параграфе 7.15. Последующие попытки разрешены, но реализации следует экспоненциально увеличивать интервал между повторами.

Если характеристики сессии PCEP устраивают, принимающий партнер должен передать сообщение Keepalive (параграф 6.3), которое служит подтверждением.

Сессия PCEP считается организованной, когда обе стороны получили от партнера PCEP сообщения Keepalive.

6.3. Сообщение Keepalive

Сообщения Keepalive передает PCC или PCE для подтверждения активности сессии. Keepalive служит также откликом на Open, подтверждающим прием сообщения и приемлемость характеристик сессии PCEP. Поле Message-Type в базовом заголовке PCEP сообщения Keepalive имеет значение 2. Сообщения Keepalive не включают объектов.

PCEP имеет свой механизм подтверждения активности сессии PCEP. Это требует задать частоту, с которой каждый из партнеров PCEP передает сообщения Keepalive. Партнеры могут выбрать разные значения частоты отправки сообщений. Значение DeadTimer определяет период, по истечении которого партнер считает сессию PCEP неактивной, если он не получил ни одного сообщения PCEP (Keepalive или другие сообщения), поэтому любое сообщение служит подтверждением активности сессии. Для таймеров DeadTimers пратнеры PCEP также не обязаны устанавливать одинаковые значения. Минимальное значение таймера Keepalive составляет 1 секунду. Реализациям следует внимательно учитывать влияние малых значений таймера Keepalive, поскольку они приводить к некорректной работе в периоды временной нестабильности сети.

Сообщения Keepalive передаются с частотой, заданной в объекте OPEN из сообщения Open, в соответствии с правилами, заданными в параграфе 7.3. Поскольку любое сообщение PCEP выступает в качестве Keepalive, реализация может передавать сообщения Keepalive с постоянными интервалами, независимо от других сообщений PCEP или определять время отправки Keepalive от последнего сообщения PCEP (не Keepalive).

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

Формат сообщения Keepalive показан ниже.

   <Keepalive Message>::= <Common Header>

6.4. Сообщение PCReq

Сообщение с запросом расчета пути (Path Computation Request или PCReq) передается клиентом PCC элементу PCE для запроса расчета пути. PCReq может содержать один или несколько запросов расчета пути. Поле Message-Type в базовом заголовке PCEP для сообщений PCReq имеет значение 3.

В сообщение PCReq должны включаться два обязательных объекта — RP и END-POINTS (раздел 7). Если одного или обоих объектов нет, PCE должен передать сообщение об ошибке клиенту PCC. Другие объекты не обязательны.

Формат сообщения PCReq показан ниже.

   <PCReq Message>::= <Common Header>
                      [<svec-list>]
                      <request-list>

где

      <svec-list>::=<SVEC>[<svec-list>]
      <request-list>::=<request>[<request-list>]

      <request>::= <RP>
                   <END-POINTS>
                   [<LSPA>]
                   [<BANDWIDTH>]
                   [<metric-list>]
                   [<RRO>[<BANDWIDTH>]]
                   [<IRO>]
                   [<LOAD-BALANCING>]

где

   <metric-list>::=<METRIC>[<metric-list>]

Объекты SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO и LOAD-BALANCING определены в разделе 7. Особый случай с двумя объектами BANDWIDTH рассмотрен в параграфе 7.7.

Реализация PCEP вольна обрабатывать полученные запросы в любом порядке. Например, запросы могут обрабатываться в порядке получения, переупорядочиваться в соответствии с локальной политикой или приоритетом, заданным в объекте RP (параграф 7.4.1) или обрабатываться параллельно.

6.5. Сообщение PCRep

Отклик PCEP с расчетом пути (Path Computation Reply или PCRep) передается PCE клиенту PCC в ответ на предшествующий запрос PCReq. Поле Message-Type в базовом заголовке PCEP сообщения PCRep имеет значение 4.

Протокол поддерживает связывание откликов на множество запросов расчета пути в одно сообщение PCRep. Если PCE получает несинхронизированные запросы расчета пути в одном или нескольких сообщениях PCReq от клиента PCC, он может объединить рассчитанные пути в одном сообщении PCRep для снижения нагрузки на уровень управления. Отметим, что оборотной стороной такого подхода является дополнительная задержка откликов на некоторые из запросов. PCE, получивший множество запросов в одном сообщении PCReq, может возвратить каждый рассчитанный путь в отдельном сообщении PCRep или вернуть все пути в одном PCRep. Соообщение PCRep может включать позитивные и негативные отклики.

Сообщение PCRep может включать набор рассчитанных путей, соответствующих одному запросу с распределением нагрузки (см. параграф 7.16) или множеству запросов от клиента PCC. Сообщение PCRep может также включать множество доступных путей, соответствующих одному запросу.

Сообщение PCRep должно включать по меньшей мере одие объект RP. Для каждого отклика, объединяемого в одно сообщение PCReq должен включаться объект RP, содержащий идентификатор запроса, идентичный одному из заданных в объекте RP соответствующего сообщения PCReq (см. определение объекта RP в параграфе 7.4).

Если запрос расчета пути выполнен (т. е. элемент PCE нашел путь, удовлетворяющий набору ограничений), в сообщение PCRep помещается набор рассчитанных путей, указанных объектами ERO4, определенными в параграфе 7.9. Ситуация с предоставлением множества путей в сообщении PCRep подробно рассмотрена в параграфе 7.13. Кроме того, при запросе PCC расчета набора путей с суммарной пропускной способностью через объект LOAD-BALANCING в сообщении PCReq, за объектом ERO каждого из рассчитанных путей следует объект BANDWIDTH, как указано в параграфе 7.16.

Если расчет пути не был выполнен, сообщение PCRep должно включать объект NO-PATH (параграф 7.5), который может содержать дополнительную информацию (например, причины отказа при расчете пути).

Формат сообщения PCRep показан ниже

   <PCRep Message> ::= <Common Header>
                       <response-list>

где

      <response-list>::=<response>[<response-list>]
      <response>::=<RP>
                  [<NO-PATH>]
                  [<attribute-list>]
                  [<path-list>]
      <path-list>::=<path>[<path-list>]

      <path>::= <ERO><attribute-list>

где

    <attribute-list>::=[<LSPA>]
                       [<BANDWIDTH>]
                       [<metric-list>]
                       [<IRO>]

    <metric-list>::=<METRIC>[<metric-list>]

6.6. Сообщение PCNtf

Уведомление PCEP (Notification или PCNtf) может передавать PCE или PCC для информирования о конкретном событии. Поле Message-Type в бащовом заголовке PCEP для соотщения PCNtf имеет значение 5.

В сообщении PCNtf должен присутствовать хотя ды один элемент NOTIFICATION и может быть несколько таких объектов для уведомления о нескольких событиях. Объект NOTIFICATION определен в параграфе 7.14. Сообщение PCNtf может включать объекты RP (параграф 7.4), когда уведомление относится к конкретному запросу расчета пути.

Сообщение PCNtf может передавать PCC или PCE в ответ на запрос или без запроса.

Формат сообщения PCNtf показан ниже.

   <PCNtf Message>::=<Common Header>
                     <notify-list>

   <notify-list>::=<notify> [<notify-list>]

   <notify>::= [<request-id-list>]
                <notification-list>

   <request-id-list>::=<RP>[<request-id-list>]

   <notification-list>::=<NOTIFICATION>[<notification-list>]

6.7. Сообщение PCErr

Сообщения PCEP об ошибках (Error или PCErr) передаются, если возникает протокольная ошибка или запрос не соответствует спецификации PCEP (например, получено сообщение с некорректным форматом, отсутствует обязательный объект, нарушены правила, получено неожиданное сообщение или указан неизвестный запрос). Поле Message-Type в базовом заголовке PCEP сообщения PCErr имеет значение 6.

Сообщение PCErr передается PCC или PCE в ответ на запрос или без запроса. При передаче сообщения PCErr в ответ на запрос, оно должно включать набор объектов RP, связанных с ожидающими запросами расчета пути, вызвавшими ошибки. В остальных случаях (передача без запроса) объекты RP не включаются в PCErr. Например, объект RP не включается в сообщение PCErr, когда возникает ошибка на этапе инициализации. Сообщение PCErr должно включать объект PCEP-ERROR, заданный для ошибки PCEP. Объект PCEP-ERROR определен в параграфе 7.15.

Формат сообщения PCErr показан ниже.

   <PCErr Message> ::= <Common Header>
                       ( <error-obj-list> [<Open>] ) | <error>
                       [<error-list>]

   <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]

   <error>::=[<request-id-list>]
              <error-obj-list>

   <request-id-list>::=<RP>[<request-id-list>]

   <error-list>::=<error>[<error-list>]

Процедура обработки сообщений PCErr описана в параграфе 7.15.

6.8. Сообщение Close

Сообщение Close передается PCC или PCE для завершения текущей сессии PCEP. Поле Message-Type в базовом заголовке PCEP для сообщения Close имеет значение 7. Формат сообщения Close показн ниже.

   <Close Message>::= <Common Header>
                      <CLOSE>

Сообщение Close должно содержать в точности один объект CLOSE (параграф 7.17). При наличии нескольких объектов CLOSE обрабатываться должен первый, а остальные игнорируются.

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

6.9. Прием неизвестных сообщений

Получившая неизвестное сообщение реализация PCEP должна передать сообщение PCErr с Error-value=2 (возможность не поддерживается).

Если PCC или PCE получает нераспознанные сообщения число не менее MAX-UNKNOWN-MESSAGES в минуту, он должен передать сообщение Close со значением «Reception of an unacceptable number of unknown PCEP message». PCC/PCE должен закрывать соединение TCP и недопустима передача других сообщений PCEP в данной сессии PCEP. Для MAX-UNKNOWN-MESSAGES рекомендуется значение 5.

7. Форматы объектов

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

7.1. Формат PCEP TLV

Объект PCEP может включать один или несколько необязательных блоков TLV.

Все PCEP TLV имеют показанный ниже формат.

   Type -   2 байта
   Length - 2 байта
   Value -  переменный размер

TLV объекта PCEP включает 2-байтовое поле типа, 2 байта размера TLV и поле значения.

Поле Length определяет размер поля значения в байтах. TLV дополняется для выравнивания по 4-байтовой границе. Заполнение не учитывается в поле Length (т. е. для 3-байтового значения поле размера будет содержать значение 3, а общий размер TLV составит 8 байтов).

Не распознанные TLV должны игнорироваться.

IANA оправляет пространством идентификаторов типа PCEP Object TLV, как описано в разделе 9.

7.2. Базовый заголовок объекта

Объект PCEP в сообщении PCEP содержит 1 или несколько 32-слов с базовым заголовком, показанным ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class  |   OT  |Res|P|I|   Object Length (bytes)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                        (тело объекта)                       //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Базовый заголовок объекта PCEP.


Object-Class (8 битов)

Указывает класс объекта PCEP.

OT (Object-Type — 4 бита)

Указывает тип объекта PCEP.

Значения поле Object-Class и Object-Type назначаются IANA.

Поля Object-Class и Object-Type однозначно указывают каждый объект PCEP.

Res flags (2 бита)

Резервное поле. Должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

P flag (Processing-Rule — 1 бит)

Флаг P позволяет PCC указать в сообщении PCReq, передаваемом PCE, нужно ли принимать объект во внимание при расчете пути или этот объект не обязательно учитывать. При установленном флаге P объект должен учитываться PCE, а при сброшенном флаге P элемент PCE может игнорировать объект.

I flag (Ignore — 1 бит)

Флаг I применяется PCE в сообщении PCRep для указания клиенту PCC, был ли обрабон необязательный объект. PCE может включть игнорируемый объект в отклик и установить флаг I для указания того, что он был проигнорирован. Сброшенный флаг указыват, что необязательный объект был обработан при расчете пути. Установка флага I для необязательных объектов является лишь информационной и может не применяться. Флаг I не имеет значения в сообщениях PCRep, когда был установлен флаг P в соответствующем запросе PCReq.

Если PCE не понимает объект с флагом P или понимает объект, но решает игнорировать его, все сообщение PCEP должно быть отвергнуто, а PCE должен передать сообщение PCErr с Error-Type=»Unknown Object» или «Not supported Object» вместе с соответствующим объектом RP. Отметим, что при включении в PCReq множества запросов отвергаться должны лишь неизвестные/нераспознанные объекты с установленным флагом P.

Object Length (16 битов)

Указывает общий размер объекта (с учетом заголовка) в байтах. Поле Object Length всегда должно быть кратно 4 и быть не меньше 4. Максимальный размер объекта составляет 65528 байтов.

7.3. Объект OPEN

Объект OPEN должен присутствовать в каждом сообщении Open и может включаться в сообщения PCErr. В сообщении должен быть лишь один объект OPEN.

Объект OPEN содержит набор полей для указания версии PCEP, частоты Keepalive, DeadTimer и идентификатора сессии PCEP, а также различных флагов. Объект может также включать набор TLV, служащих для передачи различных характеристик сессии, таких как возможности PCE, правила политики и т. п. TLV в настоящее время не определены.

OPEN Object-Class = 1.

OPEN Object-Type = 1.

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |   Flags |   Keepalive   |  DeadTimer    |      SID      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                   Необязательные TLV                        //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Формат объекта OPEN.


Ver (3 бита)

Версия PCEP (1 для текущей версии).

Flags (5 битов)

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

Keepalive (8 битов)

Максимальный интервал времени (в секундах) между двумя последовательными сообщениями PCEP, переданными отправителем этого сообщения. Минимальное значение Keepalive составляет 1 секунду. При установке значения 0 после организации сессии сообщения Keepalive больше не будут передаваться удаленному партнеру. Рекомендуемый интервал составляет 30 секунд.

DeadTimer (8 битов)

Интервал времени, по истечении которого узел PCEP будет считать сессию с отправителем сообщения Open бездействующей (down) при отсутствии сообщений PCEP. Для DeadTimer следует устанавливать значение 0 и оно должно игнорироваться при Keepalive = 0. Рекомендуется устанавливать для DeadTimer значение в 4 раза больше Keepalive.

Пример.

A передает партнеру B сообщение Open с Keepalive=10 и DeadTimer=40. Это означает, что A передает сообщения Keepalive (или иные сообщения PCEP) партнеру B каждые 10 секунд и B будет считать сессию PCEP с A бездействующей, если не получит от A сообщений в течение 40 секунд.

SID (PCEP session ID — 8 битов)

Целочисленный бесзнаковый идентификатор сессии PCEP. Значение SID должно инкрементироваться для каждой создаваемой сессии PCEP, значение следует увеличивать на 1 и при достижении максимума возвращаться к 0. Это служит для протоколирования и поиска неполадок.

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

В тело объекта OPEN могут включаться необязательные TLV для указания характеристик PCC или PCE. Спецификация таких TLV ыфходит за рамки документа.

В сообщении Open объект OPEN указывает предлагаемые характеристики сессии PCEP. При получении неприемлемых характеристик в фазе инициализации сессии принимающая сторона PCEP (PCE) может включить в сообщение PCErr объект OPEN с предложением приемлемых значений характеристик сессии.

7.4. Объект RP

Объект с параметрами запроса (RP — Request Parameters) должен включаться во все сообщения PCReq и PCRep и может присутствовать в сообщениях PCNtf и PCErr. Объект служит для задания характеристик запроса расчета пути.

Флаг P должен устанавливаться для объектов RP в сообщениях PCReq и PCRep и должен сбрасываться в сообщениях PCNtf и PCErr. Если объект RP получен с некорректным флагом P (см. выше), приемная сторона должна передать сообщение PCErr с Error-Type=10 и Error-value=1. Соответствующий запрос расчета пути должен отменяться элементом PCE без дополнительного уведомления.

7.4.1. Определение объекта

RP Object-Class = 2.

RP Object-Type = 1.

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Flags                    |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Request-ID-number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                  Необязательные TLV                         //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 10. Формат тела объекта RP.


Тело объекта RP имеет переменный размер и может включать дополнительные TLV (в настоящее время не определены).

Flags (32 бита)

Ниже перечислены определенные в настоящее время флаги.

Pri (Priority — 3 бита)

Поле Priority может служить запрашивающему PCC для указания элементу PCE приоритета запроса (от 1 до 7). Решение о выборе приоритета принимается локально, значение 0 должно устанавливаться, если приоритет не задается. Трактовка приоритета для запроса рсчета пути планировщиком PCE зависит от реализации и выходит за рамки этого документа. Отметим, что PCE не обязаны поддерживать поле приоритета, а для объектов RP клиентам PCC рекомендуется указывать приоритет 0. Если PCE не учитывает приоритет запросов, рекомендуется устанавливать приоритет 0 в объектах RP соответствующих сообщений PCRep, независимо от приоритета объекта RP в запросе PCReq. Большие значения соответствуют более высокому приоритету. Отметим, что согласованность значений приоритета для разных PCC должен обеспечивать администратор сети. Способность PCE поддерживать приоритизацию запросов может быть определена динамически клиентами PCC с помощью обнаружения возможностей PCE. Если это не анонсируется PCE, клиент PCC может установить желаемый приоритет и узнать о поддержке приоритизации запросов в PCE из поля Priority объекта RP в отклике PCRep. Если поле имеет значение 0, это указывает, что PCE не поддерживает приоритизацию запросов, т. е. указанные значения приоритета не учитываются.

R (Reoptimization — 1 бит)

Установленный флаг показывает, что запрашивающий PCC указывает, что запрос PCReq относится к повторной оптимизации имеющегося TE LSP. Для всех TE LSP кроме путей с нулевой пропускной способностью при установленном бите R объект RRO (параграф 7.10) должен включаться в сообщение PCReq для указания пути имеющегося TE LSP. Для этих TE LSP при установленном бите R имеющаяся пропускная способность TE LSP для повторной оптимизации должна быть представлена в объекте BANDWIDTH (параграф 7.7). Этот объект BANDWIDTH является дополнением к экземпляру объекта, служащего для описания желаемой полос LSP после повторной оптимизации. Для LSP с нулевой пропускной способностью объекты RRO и BANDWIDTH, указывающие характеристики имеющегося TE LSP, являются необязательными.

B (Bi-directional — 1 бит)

Установленный флаг показывает, что запрос PCC для расчета пути относится к двухстороннему TE LSP с одинаковыми требованиями по организации трафика для обоих направлений, включая «общую судьбу», защиту и восстановление, LSR, каналы TE и требования к ресурсам (например, к задержке и ее вариациям). При сброшенном флаге TE LSP является односторонним.

O (strict/loose — 1 бит)

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

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

Request-ID-number (32 бита)

Значение Request-ID-number комбинируется с IP-адресом отправителя aPCC и адресом PCE для однозначного указания контекста запроса на расчет пути. Request-ID-number позволяет однозначно различать ожидающие запросы, поэтому должно меняться (например, увеличиваться) при отправке каждого нового запроса PCE.

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

Если от PCE не получено отклика с расчетом пути (например, запрос был отброшен PCE по причине нехватки памяти), а PCC хочет повторить запрос, должно сохраняться прежнее значение Request-ID-number. При получении запроса на расчет пути от PCC с таким же значением Request-ID-number элементу PCE следует считать этот запрос новым. Реализация может кэшировать отклики на запросы расчета путей для ускоренной обработки повторов без двойного расчета (в случае отбрасывания или потери первого запроса). При получении отклика с расчетом пути от PCE с тем же Request-ID-number клиенту PCC следует отбрасывать отклик без уведомления.

Для разных запросов, отправляемых PCE, должны указываться разные Request-ID-number.

Одинаковые значения Request-ID-number могут применяться для запросов, передаваемых разным PCE. Отклик с расчетом пути будет однозначно определяться IP-адресом отвечающего PCE.

7.4.2. Обработка объекта RP

При получении PCReq без объекта RP элемент PCE должен передать сообщение PCErr запрашивающему PCC с Error-Type = «Required Object missing» и Error-value = «RP Object missing».

Если бит O объекта RP в сообщении PCReq сброшен и локальная политика PCE не предоставляет явных путей (например, из соображений конфиденциальности), должно передаваться сообщение PCErr с Error-Type = «Policy Violation» и Error-value = «O bit cleared»запрашивающему клиенту PCC, а ожидающий запрос расчета пути должен отбрасываться.

Когда установлен бит R объекта RP в сообщении PCReq, это указывает, что запрос расчета пути связан с повторной оптимизацией имеющегося TE LSP. В этом случает PCC должен также предоставить строгий/нестрогий путь включением объекта RRO в сообщение PCReq, чтобы избежать/ограничить двойной учет пропускной способности, если TE LSP имеет отличную от 0 полосу. Если PCC не запрашивает строгий путь (бит O установлен), посторная оптимизация по-прежнему может быть запрошена PCC, но это требует от PCE учета состояний (отслеживания ранее рассчитанного пути со связанным списком строгих интервалов) или возможности находить полный сегмент нужного пути. В дополнение к этому PCC должен информировать PCE о работающем пути и связанном с ним списке строгих интервалов в PCReq. Отсутствие RRO в PCReq для TE LSP с отличной от 0 полосой (установлен бит R в объекте RP) должно вызывать отправку сообщения PCErr с Error-Type = «Required Object Missing» и Error-value = «RRO Object missing for reoptimization».

Если PCC/PCE принимает сообщение PCRep/PCReq с объектом RP, указывающим неизвестный Request-ID-number, PCC/PCE должен передать сообщение PCErr с Error-Type=»Unknown request reference». Это служит для отладки. Если PCC/PCE получает сообщения PCRep/PCReq с неизвестными запросами со скоростью не меньше MAX-UNKNOWN-REQUESTS в минуту, PCC/PCE должен передать сообщение PCEP CLOSE со значением «Reception of an unacceptable number of unknown requests/replies». Рекомендуемое значение MAX-UNKNOWN-REQUESTS составляет 5. PCC/PCE должен закрыть соединение TCP и недопустима передача других сообщений PCEP в сессии PCEP.

Прием сообщения PCEP с объектом RP, имеющим Request-ID-number=0x00000000, должен трактоваться как неизвестный запрос.

7.5. Объект NO-PATH

Объект NO-PATH используется в сообщениях PCRep с откликом о неудаче запроса на расчет пути (PCE не удалось найти путь, соответствующий набору ограничений). Когда PCE не может найти соответствующий заданному в запросе набору ограничений, он должен включить объект NO-PATH в сообщение PCRep.

Имеется несколько категорий проблем, которые могут вести к негативному отклику. Например, цепочка PCE может быть разорвана (если в расчете участвует более одного PCE) или не найден соответствующий ограничениям путь. Поле NI (Nature of Issue — природа проблемы) в объекте NO-PATH служит для указания категории ошибки.

Если PCE поддерживает такую возможность, объект NO-PATH может включать NO-PATH-VECTOR TLV, определенный ниже, для предоставления дополнительной информации о причинах негативного отклика. Сообщение PCRep может также включать список объектов, которые указывают невыполненные ограничения. PCE может просто ответить набором объектов, вызвавших неудачу при расчете, а может указать предлагаемые значения, для которых путь можно найти (т. е. значения, отличающиеся от укаханных в запросе).

NO-PATH Object-Class = 3.

NO-PATH Object-Type = 1.

Формат тела объекта NO-PATH показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nature of Issue|C|          Flags              |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                  Необязательные TLV                         //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 11. Формат объекта NO-PATH.


NI — Nature of Issue (8 битов)

Поле NI служит для указания проблемы, вызвавшей негативный отклик. Определены два значения:

0 — не найдено пути, соответствующего заданному набору ограничений;

1 — цепочка PCE разорвана.

Поле NI может применяться PCC с различными целями:

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

Агентство IANA управляет пространством кодов NI, как описано в разделе 9.

Flags (16 битов)

В настоящее время определен один флаг:

C (1 бит)

При установленном флаге PCE указывает набор невыполненных ограничений (причины, по которым путь не был найден) в сообщении PCRep путем включения соответствующих объектов PCEP. При сброшенном флаге невыполненные ограничения не указываются. Флаг C не имеет значения и игнорируется, если NI отличается от 0x00.

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

Reserved (8 битов)

Резервное поле. Должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

Тело объекта NO-PATH имеет переменный размер и может содержать дополнительные TLV. Единственным определенным в настоящее время TLV является NO-PATH-VECTOR TLV, описанный ниже.

Пример

Рассмотрим PCC, передающий элементу PCE запрос расчета пути для TE LSP с пропускной способностью X Мбит/с. Предположим, что PCE не может найти пути, обеспечивающего X Мбит/с. В этом случае PCE должен включить в сообщение PCRep объект NO-PATH. Дополнительно PCE может включить исходный объект BANDWIDTH для указания причины отказа при расчете пути (в этом случае поле NI имеет значение 0x00 и флаг C установлен). Если элемент PCE поддерживает такую возможность, он может дополнительно включить объект BANDWIDTH и указать значение Y в поле bandwidth объекта BANDWIDTH (в этом случае устанавливается флаг C), где Y определяет возможную пропускную способность для TE LSP с заданными характеристиками (такими как приоритет организации и удержания, атрибут TE LSP, локальная защита и т. п.), который может быть рассчитан. Когда объект NO-PATH отсутствует в сообщении PCRep, это говорит о полном выполнении запроса расчета пути и соответствующие пути представляются в сообщении PCRep.

В объект NO-PATH можно включать необязательный NO-PATH-VECTOR TLV для предоставления дополнительной информации о причинах негативного отклика.

NO-PATH-VECTOR TLV соответствует формату PCEP TLV, определенному в параграфе 7.1, и содержит двухбайтовые поля типа и размера (значения), за которыми следует 32-битовое поле флагов.

   Тип - 1
   Размер - 4 байта
   Значение - 32-битовое поле флагов

Агентство IANA поддерживает пространство флагов для NO-PATH-VECTOR TLV (см. параграф 9).

В настоящее время определены 3 флага:

  • бит 31 — PCE в данный момент не доступен;

  • бит 30 — неизвестный адресат;

  • бит 29 — неизвестный источник.

7.6. Объект END-POINTS

Объект END-POINTS применяется в сообщении PCReq для указания IP-адресов отправителя и получателя в пути, для которого запрашивается расчет. Флаг P в объекте END-POINTS должен быть установлен. Если объект END-POINTS получен со сброшенным флагом P, принимающая сторона должна отправить сообщение PCErr с Error-Type=10 и Error-value=1. Соответствующий запрос расчета пути должен быть отвергнут PCE без дополнительного уведомления.

Отметим, что адреса отправителя и получателя в объекте END-POINTS могут соответствовать IP-адресам отправителя и получателя в TE LSP или сегменте пути. Определены два объекта END-POINTS (для IPv4 и IPv6).

END-POINTS Object-Class = 4.

END-POINTS Object-Type = 1 для IPv4 и 2 для IPv6.

Формат тела объекта END-POINTS для IPv4 (Object-Type=1) показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Адрес отправителя IPv4                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Адрес получателя IPv4                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 12. Формат тела объекта END-POINTS для IPv4.


Формат тела объекта END-POINTS для IPv6 (Object-Type=2) показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|             Адрес отправителя IPv6 (16 байтов)                |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|             Адрес получателя IPv6 (16 байтов)                 |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 13. Формат тела объекта END-POINTS для IPv6.


Тело объекта END-POINTS имеет фиксированный размер 8 байтов для IPv4 и 32 байта для IPv6.

При наличии нескольких объектов END-POINTS первый должен обрабатыватьяс, а остальные игнорироваться.

7.7. Объект BANDWIDTH

Объект BANDWIDTH служит для указания запрашиваемой пропускной способности TE LSP. Обозначение пропускной способности аналогично применяемому в сигнализации RSVP [RFC2205], [RFC3209], [RFC3473].

Если запрашиваемая пропускная способность равна 0, объект BANDWIDTH можно не включать, но при запросе отличной от 0 пропускной способности сообщение PCReq должно содержать объект BANDWIDTH.

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

Объект BANDWIDTH может передаваться в сообщениях PCReq и PCRep.

BANDWIDTH Object-Class = 5.

Определены два значения Object-Type для объекта BANDWIDTH:

  • запрос пропускной способности — BANDWIDTH Object-Type = 1.

  • пропускная способность для имеющегося TE LSP при повтроной оптимизации — BANDWIDTH Object-Type = 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Bandwidth                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Формат тела объекта BANDWIDTH.


Формат тела объекта BANDWIDTH показан ниже.

Bandwidth (32 бита)

Запрашмваемая пропускная способность, указанная 32-битовым значением с плавающей точкой в формате IEEE [IEEE.754.1985] в бит/с. Таблица часто применяемых значений приведена в параграфе 3.1.2 [RFC3471].

Тело объекта BANDWIDTH имеет фиксированный размер 4 байта.

7.8. Объект METRIC

Необязательный объект METRIC может применяться с разными целями.

В сообщение PCReq клиент PCC может включить один или несколько объектов METRIC.

  • Для указания метрики, которая должна быть оптимизирована алгоритмом расчета пути (метрика IGP или TE, число интервалов). В настоящее время определены три типа метрики — стоимость IGP, метрика TE (см. [RFC3785]) и число интервалов пересылки в TE LSP.

  • Для указания границ стоимости пути, которые недопустимо переходить для пути, считающегося приемлемым клиентом PCC.

В сообщение PCRep объект METRIC можно включать для указания стоимости рассчитанного пути. Он может также помещаться в PCRep с объектом NO-PATH для указания ограничения метрики, которые не были выполнены.

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

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

Отсутствие объекта METRIC должно восприниматься элементом PCE как запрос расчета пути без ограничения метрики.

METRIC Object-Class = 6.

METRIC Object-Type = 1.

Формат тела объекта METRIC показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved             |    Flags  |C|B|       T       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          metric-value                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 15. Формат тела объекта METRIC.


Тело объекта METRIC имеет фиксированный размер 8 байтов.

Reserved (16 битов)

Резервное поле. Должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

T (Type — 8 битов)

Задает тип метрики. В настоящее время определены 3 типа:

T=1 — метрика IGP;

T=2 — метрика TE;

T=3 — число интервалов пересылки (Hop Count).

Flags (8 битов)

В настоящее время определены 2 флага.

B (Bound — 1 бит) — при установке флага в сообщении PCReq поле metric-value указывает границу (максимум) для метрики пути, которая не должна превышаться, чтобы клиент PCC счел путь приемлемым. Метрика пути должна быть не больше значения, указанного полем metric-value. При сброшенном флаге B значение metric-value не используется в качестве ограничения метрики.

C (Computed Metric — 1 бит) — установка флага в сообщении PCReq указывает, что элемент PCE должен обеспечить указанное значение метрики рассчитанного пути (если найден соответствующий ограничениям путь)в сообщении PCRep.

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

Metric-value (32 бита)

Значение метрики представляется 32-битовым числом с плавающей точкой в формате IEEE (см. [IEEE.754.1985]).

В сообщении PCRep или PCReq для данного запроса (т. е. для данного RP) может присутствовать множество объектов METRIC. Для данного запроса должно присутствовать не более одного экземпляра объекта METRIC каждого типа с одинаковым флагом B. Если присутствует несколько экземпляров объекта METRIC с одинаковым флагом B, должен рассматриваться лишь первый из них, а прочие должны игнорироваться.

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

Объект METRIC, служащий для указания метрики, оптимизируемой при расчете пути, должен иметь сброшенный флаг B и подходящее значение флага C. Когда расчет пути связан с повтороной оптимизацией имеющегося TE LSP (в этом случае установлен флаг R объекта RP), реализация может установить в поле metric-value рассчитанное значение метрики для повторной оптимизации TE LSP по конкретному типу метрики.

Объект METRIC, служащий для ограничения, должен иметь установленный флаг B и подходящие значения флага C и поля metric-value.

В сообщении PCRep, если это разрешено политикой PCE, должно присутствовать не более 1 элемента METRIC, который указывает метрику рассчитанного пути, если флаг C был установлен в соответствующем объекте METRIC запроса на расчет пути (флаг B должен быть сброшен). Флаг C не имеет значения в сообщениях PCRep. Сообщение PCRep может включать дополнительные объекты METRIC, соответствующие границам, — в этом случае поле metric-value должно совпадать с соответствующей метрикой рассчитанного пути (флаг B должен быть установлен). Если не найдено пути, соответствующего ограничениям, объект METRIC может также включаться в сообщение PCRep с объектом NO-PATH для указания значения метрики, которое может быть обеспечено.

Пример

Если PCC передает элементу PCE запрос расчета пути, где оптимизируется метрика IGP, а метрика TE не должна превышать M, в сообщение PCReq помещаются 2 объекта METRIC:

  • первый объект METRIC с B=0, T=1, C=1, metric-value=0x0000;

  • второй объект METRIC с B=1, T=2, metric-value=M

Если путь, соответствующий заданным ограничениям, найден и политика не запрещает возвращать рассчитанную метрику, PCE помещает в отклик один объект METRIC с B=0, T=1 и metric-value с рассчитанной стоимостью пути IGP. В дополнение PCE может включть объект METRIC с B=1, T=2 и metric-value с рассчитанной стоимостью пути TE.

7.9. Объект ERO

Объект ERO служит для кодирования пути TE LSP через сеть. ERO передается в сообщении PCRep для представления TE LSP, если расчет пути был успешным.

Содержимое объекта идентично содержимому объекта RSVP-TE6 ERO7, определенного в [RFC3209], [RFC3473], [RFC3477]. Т. е. объект представляется последовательностью субобъектов и каждый из субобъектов RSVP-TE ERO, который уже определен или может быть определен в будущем для использования в RSVP-TE ERO, подходит для этого объекта.

Типы субобъектов PCEP ERO соответствуют типам RSVP-TE ERO.

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

ERO Object-Class = 7.

ERO Object-Type = 1.

7.10. Объект RRO

Объекты RRO передаются исключительно в сообщениях PCReq для информирования о маршруте TE LSP, для которого желательна повторная оптимизация.

Содержимое объекта идентично представлению объекта Route Record Object, определенного в [RFC3209], [RFC3473], [RFC3477]. Т. е. объект представляется последовательностью субобъектов и каждый из субобъектов RSVP-TE RRO, который уже определен или может быть определен в будущем для использования в RSVP-TE RRO, подходит для этого объекта.

Смысл всех субобъектов и полей данного объекта идентичен определенному для RSVP-TE RRO.

Типы субобъектов PCEP RRO соответствуют типам RSVP-TE RRO.

RRO Object-Class = 8.

RRO Object-Type = 1.

7.11. Объект LSPA

Необязательный объект LSPA (атрибуты LSP) задает различные атрибуты TE LSP, принимаемые во внимание PCE при расчете пути. Объект LSPA может включаться в сообщение PCReq или PCRep при неудаче расчета пути (в этом случае PCRep содержит также объект NO-PATH, а LSPA указывает ограничения, которые не выполнены). Большинство полей LSPA идентичны полям атрибута SESSION-ATTRIBUTE (C-Type = 7), определенного в [RFC3209] и [RFC4090]. Отсутствие объекта в сообщении PCReq говорит о том, что приоритет Setup и Holding имеет значение 0 и нет ограничений на сходство (affinity). Подробное описание сходства ресурсов приведено в параграфе 4.7.4 [RFC3209] .

LSPA Object-Class = 9.

LSPA Object-Types = 1.

Формат тела объекта LSPA показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Exclude-any                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Include-any                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Include-all                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Setup Prio   |  Holding Prio |     Flags   |L|   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                  Необязательные TLV                         //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 16. Формат тела объекта LSPA.


Setup Prio (Setup Priority — 8 битов)

Приоритет получения ресурсов для TE LSP от 0 до 7 (0 указывает высший приоритет). Setup Priority служит для определения возможности вытеснения одной сессии другой.

Holding Prio (Holding Priority — 8 битов)

Приоритет удержания ресурсов для TE LSP от 0 до 7 (0 указывает высший приоритет). Holding Priority служит для определения возможности вытеснения одной сессии другой.

Flags (8 битов)

Флаг L

Соответствует биту Local Protection Desired [RFC3209] объекта SESSION-ATTRIBUTE. Установка флага означает, что рассчитанный путь должен включать каналы, защищенные Fast Reroute, как определено в [RFC4090].

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

Reserved (8 битов)

Резервное поле. Должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

Отметим, что в будущем могут быть определены необязательные TLV для передачи дополнительных атрибутов TE LSP, таких как определенные в [RFC5420].

7.12. Объект IRO

Необязательный объект IRO8 может служить для указания того, что рассчитанный маршрут должен проходить через заданный набор сетевых элементов. IRO может включаться в сообщения PCReq и PCRep. При передаче в сообщении PCRep вместе с NO-PATH объект IRO указывает набор элементов, которые не позволили PCE найти путь.

IRO Object-Class = 10.

IRO Object-Type = 1.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                        (Sub-objects)                        //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 17. Формат тела объекта IRO.


Sub-objects

IRO образуется из субобъектов, идентичных определенным в [RFC3209], [RFC3473], [RFC3477].

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

Тип

Субобъект

1

Префикс IPv4.

2

Префикс IPv6.

4

Идентификатор безадресного интерфейса.

32

Номер автономной системы.

Бит L таких субобъектов не имеет значения в IRO.

7.13. Объект SVEC

7.13.1. Понятие зависимых и синхронизированных запросов расчета пути

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

Набор запросов называют несинхронизированным, если PCE может выполнить их последовательно и независимо.

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

Рассмотрим набор из N путей TE LSP, для которого PCC нужно передать запросы расчета пути элементу PCE. Первым решением является отправка N сообщений PCReq выбранному PCE. В этом случае запросы расчета пути не синхронизированы. Отметим, что PCC может передать N запросов в K элементов PCE для распределения нагрузки. Учитывая, что M запросов (M<N) передается определенному PCEi, как описано выше, эти M запросов могут быть переданы в форме последовательных сообщений PCReq, направленных PCEi, или собраны в одно сообщение PCReq (PCEP позволяет объединить несколько запросов расчета пути в одном сообщении PCReq). Тем не менее, даже при независимых запросах может оказаться желательным запросить у PCE синхронизированный расчет, что может вести к более оптимальным вычислениям и/или снижать вероятность блокировки в PCE без учета состояния. Иными словами, PCE не нужно вычислять соответствующие пути последовательно и независимо, а следует рассчитывать их «одновременно». Например, попытка «одновременно» рассчитать M путей TE LSP может позволить PCE повысить вероятность выполнения множества ограничений.

Рассмотрим 2 TE LSP, для которых запрашивается пропускная способность N1 и N2 Мбит/с с максимальной сквозной задержкой для каждого TE LSP в X мсек. Могут возникать ситуации, в которых расчет первого TE LSP независимо от второго TE LSP может приводить к невозможности выполнения ограничений задержки для второго TE LSP.

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

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

Зависимые расчеты пути обычно синхронизированы. Например, при запросе M разных путей несинхронизированные расчеты существенно повышают вероятность невыполнения всех запросов (иногда это называют «проблемой захвата»).

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

Набор независимых запросов расчета пути может быть синхронизированным или несинхронизированным.

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

PCEP поддерживает три режима:

  • пакет из набора независимых и несинхронизированных запросов расчета пути;

  • пакет из набора независимых и синхронизированных запросов расчета пути (требуется объект SVEC);

  • пакет из набора зависимых и синхронизированных запросов расчета пути (требуется объект SVEC).

7.13.2. Объект SVEC

В параграфе 7.13.1 рассмотрены обстоятельства, при которых может быть желательна или требоваться синхронизация набора запросов на расчет путей. Объект SVEC (Synchronization VECtor — вектор синхронизации) позволяет PCC запросить синхронизацию набора зависимых или независимых запросов. Необязательный объект SVEC может включаться в сообщения PCReq.

Целью объекта SVEC в сообщении PCReq является запрос синхронизации M запросов расчета путей. Объект SVEC имеет переменный размер и включает M запросов расчета пути, которые нужно синхронизировать. Каждый запрос однозначно указывается полем Request-ID-number в соответствующем объекте RP. Объект SVEC также включает набор флагов, задающих тип синхронизации.

SVEC Object-Class = 11.

SVEC Object-Type = 1.

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Reserved    |                   Flags                 |S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Request-ID-number #1                      |
//                                                             //
|                     Request-ID-number #M                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 18. Формат тела объекта SVEC.


Reserved (8 битов)

Резервное поле. Должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

Flags (24 бита)

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

L (Link diverse)

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

N (Node diverse)

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

S (SRLG diverse)

Установленный флаг указывает, что рассчитываемым путям, соответствующим запросам, заданным последующими объектами RP, недопустимо иметь общие SRLG9.

В случае набора из M синхронизированных независимых запросов биты L, N и S сбрасываются.

Не распределенные биты должны устанавливаться в 0 при передаче, а на приемной стороне должны игнорироваться.

Определенные выше флаги не исключают один другого.

7.13.3. Обработка объекта SVEC

Объект SVEC позволяет PCC задать список M запросов на расчет путей, которые должны быть синхронизированы с потенциальной зависимостью. Набор из M запросов расчета путей может быть передан в одном или множестве сообщений PCReq. В последнем случае рекомендуется реализовать в PCE локальный таймер (SyncTimer), активируемый при получении первого сообщения PCReq с объектом SVEC и по завершении отсчета таймера фиксировать протокольную ошибку, если не были получены все M запросов. Если PCE получает запрос расчета пути, который не может быть выполнен (например, в результате наличия в PCReq неподдерживаемого объекта с установленным битом P), PCE передает сообщение PCErr для этого запроса (см. параграф 7.2) и должен отменить весь набор связанных запросов, а также должен передать сообщение PCErr с Error-Type=»Synchronized path computation request missing».

Отметим, что такие сообщения PCReq могут также включать несинхронизированные запросы расчета пути. Например, сообщение PCReq может включать N синхронизированных запросов, относящихся к RP 1, …, RP N и указанных в объекте SVEC, а также другие запросы расчета путей, которые обрабатываются как обычно.

7.14. Объект NOTIFICATION

Объекты NOTIFICATION передаются только в сообщениях PCNtf от PCC к PCE или от PCE к PCC для информирования о событии.

NOTIFICATION Object-Class = 12.

NOTIFICATION Object-Type = 1.

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Reserved    |     Flags     |      NT       |     NV        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                  Необязательные TLV                         //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 19. Формат тела объекта NOTIFICATION.


Reserved (8 битов)

Резервное поле. Должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

Flags (8 битов)

Флаги в растоящее время не определены. Не распределенные биты должны устанавливаться в 0 при передаче, а на приемной стороне должны игнорироваться.

NT (Notification Type — 8 битов)

Notification-type указывает тип уведомления.

NV (Notification Value — 8 битов)

Notification-value обеспечивает дополнительную информацию, связанную с конкретным типом уведомления.

Значения Notification-type и Notification-value поддерживаются IANA.

Ниже перечислены определенные в настоящее время Notification-type и Notification-value.

  • Notification-type=1 — ожидающий запрос отменен

    • Notification-value=1 — клиент PCC отменил набор ожидающих запросов. Notification-type=1 с Notification-value=1 указывает, что PCC хочет информировать PCE об отмене набора ожидающих запросов. Такое событие может возникать в результате внешних условий, таких как получение отклика от другого PCE (если PCC передал нескольким PCE одни и те же запросы расчета путей), отказ сети, делающий запрос устаревшим, или иное локальное событие в PCC. Объект NOTIFICATION с Notification-type=1 и Notification-value=1 передается в сообщении PCNtf, передаваемом от PCC к PCE. Объект RP, соответствующий отмененному запросу, также должен включаться в сообщение PCNtf. Множество объектов RP может включаться в одно сообщение PCNtf и в этом случае уведомления применяется ко всем этим объектам. Если такое уведомление получено клиентом PCC от PCE, PCC должен отбросить уведомление без генерации ошибки.

    • Notification-value=2 — элемент PCE отменил набор ожидающих запросов. Notification-type=1 с Notification-value=2 указывает, что PCE хочет информировать PCC об отмене набора ожидающих запросов. Объект NOTIFICATION с Notification-type=1 и Notification-value=2 передается в сообщении PCNtf от PCE к PCC. Объект RP, соответствующий отмененному запросу, также должен включаться в сообщение PCNtf. Множество объектов RP может включаться в одно сообщение PCNtf и в этом случае уведомления применяется ко всем этим объектам. Если такое уведомление получено элементом PCE от PCC, PCE должен отбросить уведомление без генерации ошибки.

  • Notification-type=2 — перегрузка PCE

    • Notification-value=1 — Notification-type=2 с Notification-value=1 указывает клиенту PCC, что PCE в настоящее время перегружен. Если объекты RP не включены в сообщение PCNtf, не следует передавать PCE другие запросы, пока состояние перегрузки не закончится — остающиеся запросы будут обработаны. Если некоторые из ожидающих запросов не могут быть обработаны в результате перегрузки, PCE должен также включить в уведомление объекты RP, указывающие запросы, отмененные PCE. В таких случаях PCE не передает дополнительного сообщения PCNtf с Notification-type=1 и Notification-value=2, поскольку список отмененных запросов указывается соответствующими объектами RP. Если такое уведомление получено элементом PCE от PCC, PCE должен отбросить уведомление без генерации ошибки.

    • Реализации PCE следует использовать механизм с двумя порогами для определения состояния перегрузки применительно к конкретному ресурсу (например, CPU, память). Применение двух порогов позволит обеспечить гистерезис смены состояний «перегружен — не перегружен».

    • Дополнительно в объект NOTIFICATION может включаться OVERLOADED-DURATION TLV с указанием периода, в течение которого не следует передавать дополнительных запросов элементу PCE. По истечении этого периода PCE не считается перегруженным.

      OVERLOADED-DURATION TLV соответствует формату PCEP TLV, определенному в параграфе 7.1 и включает 2-байтовые поля типа и размера, за которыми следует 32-битовое поле значения.

      Type — 2

      Length — 4 байта

      Value — 32-битовое поле, указывающее оценку периода перегрузки PCE в секундах.

    • Notification-value=2 — Notification-type=2 с Notification-value=2 указывает, что PCE больше не перегружен и доступен для обработки новых запросов расчета пути. Реализации следует обеспечивать передачу элементом PCE такого уведомления каждому клиенту PCC, которому было отправлено сообщение Notification (с Notification-type=2, Notification-value=1), за исключением случаев, когда эти сообщения включали OVERLOADED-DURATION TLV и PCE хочет дождаться завершения указанного периода перед получением новых запросов. Если такое уведомление получено элементом PCE от PCC, PCE должен отбросить уведомление без генерации ошибки. Рекомендуется поддерживать в PCE ту или иную процедуру демпфирования уведомлений для предотвращения слишком частой смены состояний «перегрузка — отсутствие перегрузки». Например, реализация может использовать гистерезис с двухпороговым механизмом, вызывающим отправку сообщений о состоянии перегрузки. Кроме того, при значительной нестабильности ресурсов PCE следует применять дополнительные механизмы демпфирования (линейные или экспоненциальные) для снижения частоты уведомлений и предотвращения ненужных осцилляций.

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

7.15. Объект PCEP-ERROR

Объекты PCEP-ERROR передаются лишь в сообщениях PCErr для уведомления об ошибках PCEP.

PCEP-ERROR Object-Class = 13.

PCEP-ERROR Object-Type = 1.

Формат тела объекта PCEP-ERROR показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Reserved    |      Flags    |   Error-Type  |  Error-value  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                  Необязательные TLV                         //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 20. Формат тела объекта PCEP-ERROR.


Объект PCEP-ERROR используется для уведомления об ошибке PCEP и характеризуется полем Error-Type, указывающим тип ошибки, и полем Error-value с дополнительной информацией об ошибке конкретного типа. Значения Error-Type и Error-value поддерживаются IANA (см. раздел 9. Взаимодействие с IANA).

Reserved (8 битов)

Резервное поле. Должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

Flags (8 битов)

Флаги в растоящее время не определены. Не распределенные биты должны устанавливаться в 0 при передаче, а на приемной стороне должны игнорироваться.

Error-Type (8 битов)

Указывает класс ошибки.

Error-value (8 битов)

Обеспечивает дополнительную информацию об ошибке.

Объект PCEP-ERROR может включать дополнительные TLV с более подробной информацией об ошибке.

Сообщение PCErr может включать множество объектов PCEP-ERROR.

Для каждой ошибки PCEP определены значения Error-Type и Error-value, показанные ниже.

Error-Type

Error-value

Значение

1

Отказ при организации сессии PCEP.

1

Получение недействительного сообщения Open или отсутствие Open.

2

Сообщение Open не получено до завершения отсчета таймера OpenWait.

3

Неприемлемые или несогласуемые характеристики сессии.

4

Неприемлемые или несогласуемые характеристики сессии.

5

Получение второго сообщения Open с остающимися неприемлемыми характеристиками.

6

Получение сообщения PCErr, предлагающего неприемлемые характеристики сессии.

7

Не получено сообщения Keepalive или PCErr к моменту завершения отсчета KeepWait.

2

Возможность не поддерживается.

3

Неизвестный объект.

1

Нераспознанный класс объекта.

2

Нераспознанный тип объекта.

4

Неподдерживаемый объект.

1

Неподдерживаемый класс объекта.

2

Неподдерживаемый тип объекта.

5

Нарушение политики.

1

Установлен бит C в объекте METRIC (запрос отвергнут).

2

Установлен бит O в объекте RP (запрос отвергнут).

6

Отсутствует обязательный объект.

1

Отсутствует объект RP.

2

Отсутствует объект RRO для запроса повторной оптимизации (бит R в объекте RP установлен) при отличной от нуля пропускной способности.

3

Отсутствует объект END-POINTS.

7

Отсутствует запрос расчета синхронизированного пути.

8

Ссылка на неизвестный запрос.

9

Попытка организовать вторую сессию PCEP.

10

Получение недействительного объекта.

1

Получение объекта со сброшенным флагом P, когда спецификация требует установки флага.

Ниже приведены более подробные описания ошибок.

Error-Type=1

Отказ при организации сессии PCEP.

При получении некорректно сформированного сообщения принимающий узел PCEP должен передать сообщение PCErr с Error-Type=1 и Error-value=1.

Если не было принято сообщения Open до завершения отсчета таймера OpenWait, принимающий узел PCEP должен передать сообщение PCErr с Error-Type=1 и Error-value=2 (см. Приложение A).

Если одна или несколько характеристик сессии PCEP не приемлемы для получившего узла и не согласуемы, принимающий узел должен передать сообщение PCErr с Error-Type=1 и Error-value=3.

Если получено сообщение Open с неприемлемыми, но согласуемыми характеристиками сессии, принимающий узел PCEP должен передать сообщение PCErr с Error-Type-1 и Error-value=4 (см. параграф 6.2).

Если получено второе сообщение Open в сессии PCEP и характеристики сессии остаются неприемлемыми, принимающий узел PCEP должен передать сообщение PCErr с Error-Type-1 и Error-value=5 (см. параграф 6.2).

Если получено сообщение PCErr в фазе организации сессии PCEP, которая включает сообщение Open, предлагающее неприемлемые характеристики сесии, принимающий узел PCEP должен передать сообщение PCErr с Error-Type=1 и Error-value=6.

Если не было принято сообщения Keepalive или PCErr до завершения отсчета таймера KeepWait в фазе организации сессии PCEP, принимающий узел PCEP должен передать сообщение PCErr с Error-Type=1 и Error-value=7.

Error-Type=2

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

Error-Type=3 или Error-Type=4

Если получено сообщение PCEP с объектом PCEP (с флагом P), не распознанным или не поддерживаемым PCE, элемент PCE должен передать PCErr с объектом PCEP-ERROR (Error-Type=3 или 4, соответственно). Дополнительно PCE может включить в сообщение PCErr неизвестный или неподдерживаемый объект. Запрос расчета пути должен быть отменен PCE без дополнительного уведомления.

Error-Type=5

Если получен запрос расчета пути, не соответствующий политике, согласованной между PCC и PCE, элемент PCE должен передать сообщение PCErr с объектом PCEP-ERROR (Error-Type=5). Соответствующий запрос расчета пути должен быть отменен. Зависящие от политики TLV в объекте PCEP-ERROR могут быть определены в других документах для указания природы нарушения политики.

Error-Type=6

Если полученный запрос расчета пути не включает обязательного объекта, элемент PCE должен передать сообщение PCErr с объектом PCEP-ERROR (Error-Type=6). При отсутствии нескольких обязательных объектов сообщение PCErr должно включать объект PCEP-ERROR для каждого пропущенного объекта. Соответствующий запрос расчета пути должен быть отменен.

Error-Type=7

Если PCC передает синхронизированный запрос расчета путей элементу PCE, а PCE не получает всех запросов, указанных в соответствующем объекте SVEC по завершении отсчета SyncTimer (параграф 7.13.3), PCE должен передать сообщение PCErr с объектом PCEP-ERROR (Error-Type=7). Соответствующий синхронизированный расчет путей должен быть отменен. PCE рекомендуется включать в сообщение REQ-MISSING TLV (см. ниже), указывающие пропущенные запросы.

REQ-MISSING TLV соответствует формату PCEP TLV, определенному в параграфе 7.1 и включает 2-байтовые поля типа и размера, за которыми следует 4-байтовое поле значения.

Type — 3

Length — 4 байта

Value — 4 байта, указывающих Request-ID-number, соответствующий пропущенному запросу.

Error-Type=8

Если PCC получает сообщение PCRep, относящееся к неизвестному запрросу расчета пути, PCC должен передать сообщение PCErr с объектом PCEP-ERROR (Error-Type=8). Дополнительно PCC должен включить в сообщение PCErr неизвестный объект RP.

Error-Type=9

Если узел PCEP обнаруживает попытку партнера PCEP организовать вторую сессию PCEP, он должен передать сообщение PCErr с Error-Type=9 и Error-value=1. Существующая сессия PCEP должна сохраняться, а все последующие сообщения, относящиеся к попытке организации второй сессии PCEP, должны игнорироваться.

Error-Type=10

Если узел PCEP получает объект без флага P, но этот флаг должен быть установлен в соответствии с данной спецификацией, он должен передать сообщение PCErr с Error-Type=10 и Error-value=1.

7.16. Объект LOAD-BALANCING

Возникают ситуации, когда PCE не может найти TE LSP с пропускной способностью X, хотя такие требования могут быть выполнены путем организации набора TE LSP с суммарной пропускной способностью X. Таким образом, для PCC может быть полезным запрос набора TE LSP с суммарной пропускной способностью X Мбит/с, возможно с некоторым ограничением числа TE LSP и минимальной пропускной способности каждого TE LSP. Такие запросы выполняются с помощью вставки объекта LOAD-BALANCING в сообщение PCReq, передаваемое PCE.

Объект LOAD-BALANCING является необязательным.

LOAD-BALANCING Object-Class = 14.

LOAD-BALANCING Object-Type = 1.

Формат тела объекта LOAD-BALANCING показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Reserved            |     Flags     |     Max-LSP   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Min-Bandwidth                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 21. Формат тела объекта LOAD-BALANCING.


Reserved (16 битов)

Резервное поле. Должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

Flags (8 битов)

Флаги в растоящее время не определены. Поле Flags должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

Max-LSP (8 битов)

Максимальное число TE LSP в наборе.

Min-Bandwidth (32 бита)

Минимальная пропускная способность каждого TE LSP, представленная 32-битовым числом с плавающей точкой в формате IEEE (см. [IEEE.754.1985]), указывающим число битов в секунду.

Тело объекта LOAD-BALANCING имеет фиксированный размер 8 байтов.

Если PCC запрашивает расчет набора TE LSP с суммарной пропускной способностью X, максимальным числом TE LSP равным N и минимальной пропускной способностью каждого TE LSP равной B, он включает объект BANDWIDTH с пропускной способностью X и объект LOAD-BALANCING с Max-LSP и Min-Bandwidth со значениями N и B, соответственно.

7.17. Объект CLOSE

Объект CLOSE должен включаться в каждое сообщение Close и должен быть единственным объектом этого типа в сообщении Close. При получении сообщения Close с несколькими объектами CLOSE должен обрабатываться лишь первый такой объект, а остальные объекты CLOSE должны игнорироваться.

CLOSE Object-Class = 15.

CLOSE Object-Type = 1.

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved             |      Flags    |    Reason     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                  Необязательные TLV                         //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 22. Формат объекта CLOSE.


Reserved (16 битов)

Резервное поле. Должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

Flags (8 битов)

Флаги в растоящее время не определены. Поле Flags должно устанавливаться в 0 при передаче, а на приемной стороне должно игнорироваться.

Reason (8 битов)

Указывает причину закрытия сессии PCEP. Установка этого поля не обязательна. Пространством значений поля Reason управляет IANA. Определенные в настоящее время коды причин указаны ниже.

Код причины

Описание

1

Не представлено объяснения.

2

Завершен отсчет таймера DeadTimer.

3

Получено сообщение PCEP с некорректным форматом.

4

Получен неприемлемый номер неизвестного запроса или отклика.

5

Получен неприемлемый номер нераспознанного сообщения PCEP.

В тело объекта CLOSE могут включаться необязательные TLV. Спецификация таких TLV выходит за рамки документа.

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

Этот раздел следует рекомендациям [PCE-MANAGE].

8.1. Управление функциями и политикой

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

  • Локальные значения таймеров Keepalive и DeadTimer (т. е. параметры, передаваемые узлом PCEP в сообщении Open).

  • Максимальные приемлемые значения удаленных таймеров Keepalive и DeadTimer (т. е. параметры, получаемые от партнера в сообщении Open).

  • Разрешение и запрет согласования.

  • При разрешенном согласовании минимальные приемлемые значения таймеров Keepalive и DeadTimer, получаемые от партнера PCEP.

  • таймер SyncTimer.

  • Максимальное число сессий, которые могут быть организованы.

  • Таймер запросов — время, в течение которого PCC ждет отклика перед отправкой повторного запроса на расчет пути (возможно другому PCE).

  • MAX-UNKNOWN-REQUESTS.

  • MAX-UNKNOWN-MESSAGES.

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

  • IP-адрес партнера PCEP.

  • Роль узла PCEP — PCC, PCE или оба сразу.

  • Следует ли узлу PCEP организовывать сессию PCEP сразу или ждать инициативы партнера.

  • Параметры сессии PCEP, указанные выше, если они отличаются от принятных по умолчанию.

  • Набор правил PCEP, включая тип операций, разрешенных партнеру PCEP (например, расчет различных путей, синхронизация и т. п.).

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

8.2. Модели информации и данных

Модуль PCEP MIB определенный в [PCEP-MIB], описывает управляемые объекты для моделирования коммуникаций PCEP, включая:

  • конфигурацию и статус клиента PCEP;

  • конфигурацию и информацию узла PCEP;

  • конфигурацию и информацию сессии PCEP;

  • уведомления о смене состояния сессии PCEP.

8.3. Детектирование и мониторинг живучести

PCEP включает механизм keepalive для проверки живучести партнера PCEP и процедуру уведомления, позволяющую PCE сообщить о своей перегрузке клиентам PCC. Определены также процедуры мониторинга живучести и производительности данной цепочки PCE (в случае расчета пути несколькими PCE) [PCE-MONITOR].

8.4. Проверка корректности работы

Проверка корректности работы PCEP может быть выполнена путем мониторинга различных параметров. Реализациям PCEP следует поддерживать проверку перечисленных ниже параметров.

  • Время отклика (минимальное, среднее, максимальное) на уровне PCE.

  • Отказы сессий PCEP.

  • Продолжительность активного состояния сессии.

  • Число поврежденных сообщений.

  • Число отказов при расчетах.

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

Реализации PCEP следует записывать ошибки (например, поврежденные сообщения, нераспознанные объекты) в системный журнал.

8.5. Требования к другим протоколам и функциональным компонентам

PCEP не предъявляет новых требований к другим протоколам. Поскольку PCEP работает на базе транспорта TCP, для управления PCEP можно применять механизма управления TCP (такие как TCP MIB [RFC4022]).

Механизмы PCE Discovery ([RFC5088], [RFC5089]) могут влиять на работу PCEP. Для предотвращения частой организации и удаления сессий PCEP в результате высокой частоты обнаружения и потери PCE (Discoveries/Disappearances) рекомендуется применять то или иное демпфирование организации сессий PCEP.

8.6. Влияние на работу сети

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

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

Агентство IANA выделило значения протокольных параметров PCEP (сообщения, объекты, TLV).

Агентство IANA организовалор новый реестр верхнего уровня для всех кодов и субреестров PCEP.

Для каждого из новых реестров залана процедура IETF Consensus — новые значения выделяются с согласия IETF (см. [RFC5226]). В частности, новые значения выделяются через RFC, одобренные IESG. Обычно IESG запрашивает информацию о предполагаемых назначениях у соответствующи лиц (например, в рабочей группе, если она имеется).

9.1. Порт TCP

Для PCEP зарегистрирован порт TCP 4189.

9.2. Сообщения PCEP

Агентство IANA создало реестр для сообщений PCEP. Каждое сообщение PCEP имеет определенный тип.

Значение

Смысл

Документ

1

Open

Данный документ

2

Keepalive

Данный документ

3

Path Computation Request

Данный документ

4

Path Computation Reply

Данный документ

5

Notification

Данный документ

6

Error

Данный документ

7

Close

Данный документ

9.3. Объекты PCEP

Агентство IANA создало реестр объектов PCEP. Каждый объект PCEP имеет класс Object-Class и тип Object-Type.

Object-Class

Имя

Документ

1

OPEN, Object-Type = 1

Данный документ

2

RP, Object-Type = 1

Данный документ

3

NO-PATH, Object-Type = 1

Данный документ

4

END-POINTS, Object-Type = 1 — адрес IPv4, = 2 — адрес IPv6

Данный документ

5

BANDWIDTH, Object-Type = 1 — запрошенная полоса, = 2 — полоса имеющегося IPv6 TE LSP, для которого выполняется повторная оптимизация.

Данный документ

6

METRIC, Object-Type = 1

Данный документ

7

ERO, Object-Type = 1

Данный документ

8

RRO, Object-Type = 1

Данный документ

9

LSPA, Object-Type = 1

Данный документ

10

IRO, Object-Type = 1

Данный документ

11

SVEC, Object-Type = 1

Данный документ

12

NOTIFICATION, Object-Type = 1

Данный документ

13

PCEP-ERROR, Object-Type = 1

Данный документ

14

LOAD-BALANCING, Object-Type = 1

Данный документ

15

CLOSE, Object-Type = 1

Данный документ

9.4. Базовый заголовок сообщения PCEP

Агентство IANA создало реестр для поддержки поля Flag в базовом заголовке сообщений PCEP.

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

В настоящее время битов для базового заголовка сообщений PCEP не определено.

9.5. Поле флагов объекта OPEN

Агентство IANA создало реестр для поля Flag объекта OPEN.

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

В настоящее время биты флагов объекта OPEN не определены.

9.6. Объект RP

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

Определены несколько битов для поля флагов объекта RP, показанных ниже.

Бит

Описание

Документ

26

Строгий/нестрогий

Данный документ

27

Двухсторонний

Данный документ

28

Повторная оптимизация

Данный документ

29-31

Приоритет

Данный документ

9.7. Поле флагов объекта NO-PATH

Агентство IANA создало реестр для полей NI и Flag объекта NO-PATH.

Значение

Описание

Документ

0

Не найдено пути, соответствующего заданным ограничениям.

Данный документ

1

Цепочка PCE разорвана.

Данный документ

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

Определен один бит для поля флагов объекта NO-PATH.

Значение

Описание

Документ

0

Указаны невыполненные ограничения.

Данный документ

9.8. Объект METRIC

Агентство IANA создало реестр для полей T и Flag объекта METRIC.

Ниже приведены значения поля T.

Значение

Описание

Документ

1

Метрика IGP.

Данный документ

2

Метрика TE.

Данный документ

3

Число интервалов.

Данный документ

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

Определены несколько битов для поля флагов объекта METRIC, показанных ниже.

Бит

Описание

Документ

6

Рассчитанная метрика

Данный документ

7

Привязка (Bound)

Данный документ

9.9. Поле флагов объекта LSPA

Агентство IANA создало реестр для поля Flag объекта LSPA.

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

Определен один бит для поля флагов объекта LSPA.

Бит

Описание

Документ

7

Желательна локальная защита

Данный документ

9.10. Поле флагов объекта SVEC

Агентство IANA создало реестр для поля Flag объекта SVEC.

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

Определены 3 бита для поля флагов объекта SVEC, показанных ниже.

Бит

Описание

Документ

21

Различие SRLG

Данный документ

22

Различие узлов

Данный документ

23

Различие каналов

Данный документ

9.11. Объект NOTIFICATION

Агентство IANA создало реестр для полей Notification-type и Notification-value объекта NOTIFICATION и управляет пространством кодов.

Notification-type

Notification-value

Описание

Документ

1

Отмена ожидающего запроса

Данный документ

1

PCC отменил набор ожидающих запросов

2

PCE отменил набор ожидающих запросов

2

Перегрузка PCE

Данный документ

1

Насыщение PCE

2

PCE вышел из насыщения

Агентство IANA создало реестр для поля Flag объекта NOTIFICATION.

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

В настоящее время не определено битов поля Flag в объекте NOTIFICATION.

9.12. Объект PCEP-ERROR

Агентство IANA создало реестр для полей Error-Type и Error-value объекта PCEP-ERROR и поддерживает его.

Для каждой ошибки PCEP определены значения Error-Type и Error-value приведенные ниже.

Error-Type

Error-value

Описание

Документ

1

Отказ при организации сессии PCEP.

Данный документ

1

Прием недействительного сообщения Open или отсутствие Open.

2

Не получено сообщения Open до завершения отсчета таймера OpenWait.

3

Неприемлемые или несогласуемые характеристики сессии.

4

Неприемлемые, но согласуемые характеристики сессии.

5

Получение второго сообщения Open с неприемлемыми характеристиками.

6

Получение сообщения PCErr с неприемлемыми характеристиками сессии.

7

Не принято сообщений Keepalive или PCErr до завершения отсчета KeepWait.

8

Версия PCEP не поддерживается.

2

Возможность не поддерживается.

Данный документ

3

Неизвестный объект.

Данный документ

1

Нераспознанный класс объекта.

2

Нераспознанный тип объекта.

4

Неподдерживаемый объект.

Данный документ

1

Неподдерживаемый класс объекта.

2

Неподдерживаемый тип объекта.

5

Нарушение политики.

Данный документ

1

Установлен бит C в объекте METRIC (запрос отвергнут.

2

Сброшен бит O в объекте RP (запрос отвергнут.

6

Отсутствует обязательный объект.

Данный документ

1

Нет объекта RP.

2

Нет объекта RRO для запроса повторной оптимизации (бит R в RP установлен).

3

Нет объекта END-POINTS.

7

Отсутствует запрос синхронизированного расчета пути.

Данный документ

8

Ссылка на неизвестный запрос.

Данный документ

9

Попытка организовать вторую сессию PCEP.

Данный документ

10

Получение недействительного объекта.

Данный документ

1

Получение объекта со сброшенным флагом P, хотя данная спецификация требует его установки.

Агентство IANA создало реестр для поля Flag объекта PCEP-ERROR.

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

В настоящее время не определено битов поля Flag в объекте PCEP-ERROR.

9.13. Поле флагов объекта LOAD-BALANCING

Агентство IANA создало реестр для поля Flag объекта LOAD-BALANCING.

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

В настоящее время не определено битов поля Flag в объекте LOAD-BALANCING.

9.14. Объект CLOSE

Объект CLOSE должен присутствовать в каждом сообщении Close для указания причины разрыва сессии PCEP. Поле reason объекта CLOSE указывает причину разрыва сессии PCEP. Значения поля reason в объекте CLOSE поддерживаются IANA.

Код причины

Описание

1

Без объяснения.

2

Таймер DeadTimer.

3

Прием сообщения PCEP с некорректным форматом.

4

Получение неприемлемого числа неизвестных запросов или откликов.

5

Получение неприемлемого числа нераспознанных сообщений PCEP.

Агентство IANA создало реестр для поля Flag объекта CLOSE.

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • описание возможности;

  • RFC с определением.

В настоящее время не определено битов поля Flag в объекте CLOSE.

9.15. Индикаторы типов PCEP TLV

Агентство IANA создало реестр для PCEP TLV.

Код

Описание

Документ

1

NO-PATH-VECTOR TLV

Данный документ

2

OVERLOAD-DURATION TLV

Данный документ

3

REQ-MISSING TLV

Данный документ

9.16. NO-PATH-VECTOR TLV

IANA управляет пространством флагов, передаваемых в NO-PATH-VECTOR TLV, определенном в этом документе. Биты флагов нумеруются с 0, начиная со старшего бита.

Номера битов могут выделяться только по процедуре IETF Consensus. Для каждого бита отслеживается:

  • номер бита (отсчет с 0 для старшего бита);

  • флаг имени;

  • ссылка на документ.

Бит

Описание

Документ

31

PCE в данный момент недоступен

Данный документ

20

Неизвестный адресат

Данный документ

29

Неизвестный отправитель

Данный документ

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

10.1. Уязвимости

Атаки на PCEP могут нарушать работу активных сетей. Если отклики с рассчитанными путями изменить, это может привести к выбору неприемлемых LSP клиентами PCC. Эти LSP могут проходить через участки сети, где трафик подвергается исследованию или могут попадать в перегруженные или резервные каналы. Отклики с расчетами пути можно атаковать путем изменения сообщений PCRep, подмены PCE или изменения запросов PCReq, вынуждающего PCE выполнить расчет, отличающийся от изначально запрошенного.

Можно нарушить работу PCE с использованием различных DoS-атак10, которые могут вызвать перегрузку PCE, ведущую к замедлению откликов клиентам PCC до неприемлемых величин. Это может также приводить к неприемлемо долгому времени восстановления или задержкам организации LSP. В экстремальных случаях это может приводить даже к отказам от выполнения запросов.

Ниже перечислены некоторые атаки, которые могут быть организованы на протокол PCEP:

  • обман (подмена PCC или PCE);

  • слежка (перехват сообщений);

  • фальсификация;

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

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

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

В следующих параграфах рассматриваются механизмы защиты протокола PCEP от атак.

10.2. Методы защиты TCP

Во время написания этого документа TCP-MD5 [RFC2385] был единственным доступным механизмом защиты соединений TCP, на основе которых организуются сессии PCEP.

Как разъяснено в [RFC2385], применение MD5 связано с некоторыми ограничениями и не обеспечивает высокого уровня защиты, как считалось ранее. Реализации PCEP с поддержкой TCP-MD5 следует проектировать так, чтобы в будущих версиях можно было легко интегрировать более надежные методы и алгоритмы для защиты TCP.

Опция аутентификации TCP [TCP-AUTH] (TCP-AO11) задает новые процедуры защиты для TCP, но еще не разработана до конца. Поскольку считается, что [TCP-AUTH] будет обеспечивать существенно более надежную защиту для приложений, использующих TCP, разработчикам следует обновить свои реализации после выхода RFC для TCP-AO.

Реализации должны поддерживать TCP-MD5 и следует делать функцию защиты конфигурационной опцией.

Операторы должны учитывать, что некоторые развернутые реализации PCEP могут применять предварительные варианты [TCP-AUTH] и потребуется настройка политики защиты для безопасных коммуникаций между узлами PCEP с поддержкой TCP-AO и без нее.

Другим вариантом защиты транспорта TCP является протокол TLS12 [RFC5246]. Этот протокол обеспечивает защиту от прослушивания, искажения и подделки. Однако TLS не защищает сами соединения TCP, поскольку не применяется аутентификация заголовков TCP. Поэтому сохраняется уязвимость к атакам со сбросом TCP (от которых защищает TCP-MD5). Однако применение TLS требует спецификации инициирования протоколом PCEP согласования TLS и способа интерпретации сертификатов, передаваемых в TLS. Такая спецификация выходит за рамки документа, но может стать предметом будущей работы.

10.3. Аутентификация и защита целостности PCEP

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

Механизм TCP-MD5 [RFC2385], упомянутый выше, обеспечивает такую защиту с учетом проблем, отмеченных в [RFC2385] и [RFC4278]. Эти проблемы будут решаться с помощью [TCP-AUTH].

10.4. Конфиденциальность PCEP

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

Конфиденциальность PCEP можно обеспечить путем шифрования. TCP может работать через туннели IPsec [RFC4303] для обеспечения нужного шифрования. Отметим, что IPsec может также обеспечить контроль подлинности и целостности и тогда применение TCP-MD5 или TCP-AO не потребуется. Однако есть опасения по части сложности настройки и применения IPsec. Использование IPSec с PCEP выходит за рамки документа и может быть рассмотрено в отдельной работе.

10.5. Настройка ключей и обмен ими

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

Возможна настройка сеансовых ключей, но это может быть обременительно для операторов (а также для протокола BGP, как указано в [BGP-SEC]). При небольшом числе PCC и PCE в сети можно задать ключи вручную, но нужно учитывать уязвимости таких механизмов (например, конфигурационные ошибки, социальная психология и невнимательность оператора могут приводить к нарушению защиты). Кроме того, настроенные вручную ключи скорей всего будут обновляться более редко, что также повышает риск. При большом числе PCC и PCE на оператора ложится значительная нагрузка по настройке и поддержке, поскольку требуется настроить каждый PCC и PCE.

Другим вариантом является применение групповых ключей. Такой ключ известен всем членам домена доверия. Поскольку маршрутизаторы в области IGP или AS являются частью домена доверия [MPLS-SEC], групповой ключ PCEP может быть известен всем PCC и PCE в области IGP или AS. Использование групповых ключей существенно снижает нагрузку на оператора по настройке, обеспечивая защиту PCEP от атак извне. Однако следует отметить, что с ростом числа элементов возрастает и риск раскрытия (утечки) ключа.

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

Обнаружение PCE ([RFC5088] и [RFC5089]) является важным механизмом для развертывания PCEP в больших сетях. Этот механизм позволяет PCC обнаруживать наличие PCE в сети без необходимости настройки. Очевидно, что обнаруженные PCE не будут настроены и PCC не будет знать нужного для работы ключа. Решить эту проблему можно тремя способами, указанными ниже, с сохранением некоторых аспектов безопасности.

  • PCC могут применять групповой ключ, как указано выше.

  • PCC могут использовать тот или иной протокол защищенного обмена ключами с PCE (например, протокол Internet Key Exchange версии 2 — IKE [RFC4306]). Недостатком этого подхода является то, что не на всех маршрутизаторах поддерживается IKE и это может создать преграду для развертывания PCEP. Детали такого подхода выходят за рамки документа и могут быть рассмотрены в отдельной работе.

  • PCC могут использовать сервер ключей для получения ключа, позволяющего работать с PCE. Это лишь переносит проблему, поскольку связь PCC с сервером ключей также требуется защищать (например, с помощью Kerberos [RFC4120]), но обеспечивает некоторое (незначительное) преимущество в плане расширяемости, если PCC нужно знать ключи нескольких PCE, поскольку здесь достаточно знать лишь ключ сервера ключей. Отметим, что реализации серверов ключей в настоящее время очень ограничены. Детали такого подхода выходят за рамки документа и могут быть рассмотрены в отдельной работе.

Связи PCEP вероятно будут продолжительными даже при неоднократном закрытии и восстановлении сессий PCEP. Если протокольные отношения сохраняются долго или для большого числа взаимодействий, рекомендуется регулярная замена ключей, используемых партнерами [RFC4107]. Отметим, что TCP-MD5 не позволяет менять ключи без разрыва соединений TCP что будет приводить к необходимости перезапуска сессий PCEP. Это может создать проблему для PCEP. Отметим также, что планы внедрения TCP-AO [TCP-AUTH] позволяют менять ключи динамически для активного соединения TCP.

При использовании обмена ключами (например, IKE), сравнительно просто поддерживать динамический обмен ключами и применять его для PCEP.

Отметим, что управление по основному каналу для ключей TCP-AO [TCP-AUTH] в настоящее время не решено.

В [RFC3562] указаны некоторые проблемы управления ключами для защищенных соединений TCP.

10.6. Политика доступа

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

Элементам PCE следует поддерживать настраиваемую политику доступа. При использовании аутентификации контроль доступа можно обеспечить за счет настройки или обмена ключами, как описано в параграфе 10.5. Более простые правила можно настроить на PCE в форме списков доступа, содержащих IP-адреса легитимных PCC. Правила следует делать настраиваемыми, чтобы ограничить типы запросов, поддерживаемые для разных PCC.

Рекомендуется регистрировать нарушения политики доступа в системном журнале PCE и проверять этот журнал для обнаружения попыток атаковать PCE. Такие механизмы должны быть облегченными, чтобы нельзя было организовать с их помощью DoS-атаки (см. параграф 10.7).

10.7. Защита от DoS-атак

DoS-атаки могут быть организованы на уровне TCP или PCEP, т. е. PCE можно атаковать через TCP или в созданной сессии PCEP.

10.7.1. Защита от DoS-атак на TCP

PCEP может быть целью DoS-атак на TCP, таких как SYN-атаки, как и все протоколы, работающие на основе TCP. В спецификациях других протоколов этот вопрос достаточно изучен и PCEP может воспользоваться набранным опытом. Читателям рекомендуется обратиться, например, к спецификации протокола распространения меток LDP13 [RFC5036]. Для защиты от DoS-атак на TCP реализации PCEP могут поддерживать приведенные ниже методы.

  • PCEP использует один зарегистрированный порт для всех коммуникаций. PCE следует слушать соединения TCP только на портах, где ожидаются соединения.

  • PCE может реализовать список доступа для прямого отбрасывания (reject или discard) попыток соединения TCP от неуполномоченных PCC.

  • PCE не следует разрешать множество соединений TCP с одним PCC через зарегистрированный порт PCEP.

  • PCE может потребовать использования опции MD5 для всех соединений TCP и может отвергать (или отбрасывать) все попытки организации соединения без MD5. PCE недопустимо воспринимать SYN-пакеты с недействительной суммой MD5 для сегмента. Отметим однако, что применение MD5 требует от получателя использовать ресурсы CPU для расчета контрольной суммы до того, как он сможет принять решение об отбрасывании приемлемого по остальным параметрам сегмента SYN.

10.7.2. Формирование и правила на входе

Реализация PCEP может подвергаться DoS-атакам в легитимной сессии PCEP. Например, PCC может передавать очень большое число сообщений PCReq, перегружающих PCE или вызывающих постановку в очередь запросов от других PCC.

Отметим, что прямое использование поля Priority в объекте RP для приоритизации полученных запросов не обеспечивает какой-либо защиты, поскольку атакующий может установить для всех запросов высший приоритет.

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

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

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

Авторы благодарны Dave Oran, Dean Cheng, Jerry Ash, Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard Douville, Jon Parker, Martin German и Dennis Aristow за полезные предложения. Спасибо также Fabien Verhaeghe за полезные дискуссии и предложения. David McGrew и Brian Weis внесли важный вклад в раздел «Вопросы безопасности».

Ross Callon, Magnus Westerlund, Lars Eggert, Pasi Eronen, Tim Polk, Chris Newman и Russ Housley внесли существенные предложения в процессе обзора IESG.

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

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

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

[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, September 1997.

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

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, December 2001.

[RFC3473] Berger, L., «Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions», RFC 3473, January 2003.

[RFC3477] Kompella, K. and Y. Rekhter, «Signalling Unnumbered Links in Resource ReSerVation Protocol — Traffic Engineering (RSVP-TE)», RFC 3477, January 2003.

[RFC4090] Pan, P., Swallow, G., and A. Atlas, «Fast Reroute Extensions to RSVP-TE for LSP Tunnels», RFC 4090, May 2005.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

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

[BGP-SEC] Christian, B. and T. Tauber, «BGP Security Requirements», Work in Progress, November 2008.

[IEEE.754.1985] IEEE Standard 754, «Standard for Binary Floating-Point Arithmetic», August 1985.

[INTER-LAYER] Oki, E., Roux, J., Kumaki, K., Farrel, A., and T. Takeda, «PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering», Work in Progress, January 2009.

[MPLS-SEC] Fang, L. and M. Behringer, «Security Framework for MPLS and GMPLS Networks», Work in Progress, November 2008.

[PCE-MANAGE] Farrel, A., «Inclusion of Manageability Sections in PCE Working Group Drafts», Work in Progress14, January 2009.

[PCE-MONITOR] Vasseur, J., Roux, J., and Y. Ikejiri, «A set of monitoring tools for Path Computation Element based Architecture», Work in Progress15, November 2008.

[PCEP-MIB] Stephan, E. and K. Koushik, «PCE communication protocol (PCEP) Management Information Base», Work in Progress16, November 2008.

[RBNF] Farrel, A., «Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications», Work in Progress17, November 2008.

[RFC1321] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, April 1992.

[RFC3471] Berger, L., «Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description», RFC 3471, January 2003.

[RFC3562] Leech, M., «Key Management Considerations for the TCP MD5 Signature Option», RFC 3562, July 2003.

[RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, «Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric», BCP 87, RFC 3785, May 2004.

[RFC4022] Raghunarayan, R., «Management Information Base for the Transmission Control Protocol (TCP)», RFC 4022, March 2005.

[RFC4101] Rescorla, E. and IAB, «Writing Protocol Models», RFC 4101, June 2005.

[RFC4107] Bellovin, S. and R. Housley, «Guidelines for Cryptographic Key Management», BCP 107, RFC 4107, June 2005.

[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, «The Kerberos Network Authentication Service (V5)», RFC 4120, July 2005.

[RFC4278] Bellovin, S. and A. Zinin, «Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification», RFC 4278, January 2006.

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[RFC4306] Kaufman, C., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, «Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)», RFC 5420, February 2009.

[RFC4655] Farrel, A., Vasseur, J., and J. Ash, «A Path Computation Element (PCE)-Based Architecture», RFC 4655, August 2006.

[RFC4657] Ash, J. and J. Le Roux, «Path Computation Element (PCE) Communication Protocol Generic Requirements», RFC 4657, September 2006.

[RFC4674] Le Roux, J., «Requirements for Path Computation Element (PCE) Discovery», RFC 4674, October 2006.

[RFC4927] Le Roux, J., «Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering», RFC 4927, June 2007.

[RFC5036] Andersson, L., Minei, I., and B. Thomas, «LDP Specification», RFC 5036, October 2007.

[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, «OSPF Protocol Extensions for Path Computation Element (PCE) Discovery», RFC 5088, January 2008.

[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, «IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery», RFC 5089, January 2008.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, «Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)», RFC 5376, November 2008.

[TCP-AUTH] Touch, J., Mankin, A., and R. Bonica, «The TCP Authentication Option», Work in Progress18, November 2008.

Приложение A. Конечный автомат PCEP

В этом разделе описан конечный автомат PCEP FSM (finite state machine).

       +-+-+-+-+-+-+<------+
+------| SessionUP |<---+  |
|      +-+-+-+-+-+-+    |  |
|                       |  |
|   +->+-+-+-+-+-+-+    |  |
|   |  | KeepWait  |----+  |
|   +--|           |<---+  |
|+-----+-+-+-+-+-+-+    |  |
||          |           |  |
||          |           |  |
||          V           |  |
||  +->+-+-+-+-+-+-+----+  |
||  |  | OpenWait  |-------+
||  +--|           |<------+
||+----+-+-+-+-+-+-+<---+  |
|||         |           |  |
|||         |           |  |
|||         V           |  |
||| +->+-+-+-+-+-+-+    |  |
||| |  |TCPPending |----+  |
||| +--|           |       |
|||+---+-+-+-+-+-+-+<---+  |
||||        |           |  |
||||        |           |  |
||||        V           |  |
|||+--->+-+-+-+-+       |  |
||+---->| Idle  |-------+  |
|+----->|       |----------+
+------>+-+-+-+-+

Рисунок 23. Конечный атомат PCEP для клиента PCC.


Ниже перечислены переменные PCEP.

Connect

Таймер (в секундах) запускаемый после инициализации соединения TCP через зарегистрированный для PCEP порт TCP. Значение таймера Connect составляет 60 секунд.

ConnectRetry

Число попыток организации соединения TCP с партнером PCEP при возникновении отказов.

ConnectMaxRetry

Максимальное число попыток системы организовать соединение TCP через порт PCEP до перехода в состояние Idle. ConnectMaxRetry имеет значение 5.

OpenWait

Таймер, соответствующий времени, в течение которого узел PCEP будет ждать сообщения Open от партнера перед тем, как система освободит ресурсы PCEP и вернется в состояние Idle. Таймер OpenWait имеет фиксированное значение 60 секунд.

KeepWait

the timer that corresponds to the amount of time a PCEP peer will wait to receive a Keepalive or a PCErr message from the PCEP peer after the expiration of which the system releases the PCEP resource and goes back to the Idle state. The KeepWait timer has a fixed value of 60 seconds.

OpenRetry

Число повторов сообщений Open с неприемлемыми характеристиками сессии PCEP, воспринимаемых системой.

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

RemoteOK

Логическая переменная, устанавливаемая в 1 при получении системой приемлемого сообщения Open.

LocalOK

Логическая переменная, устанавливаемая в 1 при получении системой сообщения Keepalive, подтверждающего восприятие партнером отправленного ему сообщения Open.

Состояние Idle

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

Переменные инициализируются приведенными ниже значениями.

TCPRetry=0,

LocalOK=0,

RemoteOK=0,

OpenRetry=0.

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

  • инициирует соединение TCP с партнером PCEP;
  • запускает таймер Connect;
  • переходит в состояние TCPPending.

Если соединение TCP организовано, система при получении соединения TCP через зарегистрированный порт PCEP TCP:

  • передает сообщение Open;
  • запускает таймер OpenWait;
  • переходит в состояние OpenWait.

Если организация соединения завершилась отказом, система остается в состоянии Idle. Все другие события в состоянии Idle игнорируются.

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

Состояние TCPPending

При успешной организации соединения TCP система:

  • передает сообщение Open;
  • запускает таймер OpenWait;
  • переходит в состояние OpenWait.

При отказе организации соединения TCP (ошибка на этапе организации соединения TCP) или завершении отсчета таймера Connect:

  • если ConnectRetry = ConnectMaxRetry, система переходит в состояние Idle;
  • если ConnectRetry < ConnectMaxRetry, система:
    1. инициирует соединение TCP с партнером PCEP;
    2. инкрементирует переменную ConnectRetry;
    3. перезапускает таймер Connect;
    4. остается в состоянии TCPPending.

В ответ на остальные события система освобождает ресурсы PCEP, выделенные для данного партнера, и переходит в состояние Idle.

Состояние OpenWait

В состоянии OpenWait система ждет сообщения Open от партнера PCEP.

Если система получает сообщение Open от партнера PCEP до завершения отсчета таймера OpenWait, она сначала проверяет все свои сессии, находящиеся в состоянии OpenWait или KeepWait. Если сессия с этим партнером PCEP (тот же адрес IP) уже имеется, система выполняет процедуру устранения конфликтов:

  • если система инициировала текущую сессию и имеет меньший адрес IP, нежели партнер PCEP, система закрывает соединение TCP, освобождает ресурсы PCEP, выделенные для ожидающей сессии, и переходит в состояние Idle;
  • если система инициировала текущую сессию и имеет больший адрес IP, нежели партнер PCEP, система закрывает соединение TCP, освобождает ресурсы PCEP, выделенные для ожидающей сессии, и переходит в состояние Idle;
  • в остальных случаях система проверяет атрибуты сессии PCEP (частота Keepalive, DeadTimer и т. п.).

При обнаружении ошибки (например, некорректное сообщение Open, прием сообщения, отличного от Open, наличие двух объектов OPEN) PCEP генерирует уведомление об ошибке, а узел PCEP передает сообщение PCErr с Error-Type=1 и Error-value=1. Система освобождает ресурсы PCEP, выделенные для партнера PCEP, закрывает соединение TCP и переходит в состояние Idle.

Если ошибок не обнаружено, OpenRetry=1, но параметры сессии не приемлемы, узел PCEP передает сообщение PCErr с Error-Type=1 и Error-value=5, а система освобождает ресурсы PCEP, выделенные для этого партнера, и возвращается в состояние Idle.

Если ошибок не обнаружено и параметры сессии приемлемы для локальной системы, она:

  • передает сообщение Keepalive партнеру PCEP;
  • запускает таймер Keepalive;
  • устанавливает RemoteOK = 1.

Если LocalOK=1, система сбрасывает таймер OpenWait и переходит в состояние UP.

Если LocalOK=0, система сбрасывает таймер OpenWait, запускает таймер KeepWait и переходит в состояние KeepWait.

Если ошибок не обнаружено, но параметры сессии не приемлемы и не согласуемы, узел PCEP передает PCErr с Error-Type=1 и Error-value=3, а система освобождает ресурсы PCEP, выделенные для этого партнера, и возвращается в состояние Idle.

Если ошибок не обнаружено, OpenRetry=0, а параметры сессии (такие как период Keepalive или таймер DeadTimer) не приемлемы, но согласуемы, система:

  • инкрементирует OpenRetry;
  • передает сообщение PCErr с Error-Type=1 и Error-value=4, содержащее подходящие характеристики сессии;
  • если LocalOK=1, система перезапускает таймер OpenWait и остается в состоянии OpenWait;
  • если LocalOK=0, система сбрасываеь таймер OpenWait, запускает таймер KeepWait и переходит в состояние KeepWait.

Если не было получено сообщения Open до завершения отсчета таймера OpenWait, узел PCEP передает сообщение PCErr с Error-Type=1 и Error-value=2, система освобождает ресурсы PCEP, выделенные для этого партнера, закрывает соединение TCP и переходит в состояние Idle.

В ответ на все прочие события система освобождает ресурсы PCEP, выделенные для этого партнера, и переходит в состояние Idle.

Состояние KeepWait

В состоянии Keepwait система ждет от партнера PCEP сообщения Keepalive, подтверждающего сообщение Open, или сообщения PCErr в ответ на неприемлемые характеристики сессии PCEP, предложенные в сообщении Open.

При обнаружении ошибки (например, некорректное сообщение Keepalive) PCEP генерирует уведомление и узел PCEP передает сообщение PCErr с Error-Type=1 и Error-value=1. Система освобождает ресурсы PCEP, выделенные для этого партнера, закрывает соединение TCP и переходит в состояние Idle.

Если сообщение Keepalive принято до завершения отсчета таймера KeepWait, система устанавливает LocalOK=1 и

  • если RemoteOK=1, система сбрасывает таймер KeepWait и переходит в состояние UP;
  • если RemoteOK=0, система сбрасывает таймер KeepWait, запускает таймер OpenWait и переходит в состояние OpenWait.

Если получено сообщение PCErr до завершения отсчета атймера KeepWait:

  1. если предложенные значения не приемлемы, узел PCEP передает сообщение PCErr с Error-Type=1 и Error-value=6, а система освобождает ресурсы PCEP, выделенные для этого партнера, закрывает соединение TCP и переходит в состояние Idle;
  2. если предложенные значения приемлемы, система подстраивает характеристики сессии PCEP в соответствии с предложенными в PCErr значениями, перезапускает таймер KeepWait и передает сообщение Open. Если RemoteOK=1, система перезапускает таймер KeepWait и остается в состоянии KeepWait. Если RemoteOK=0, система сбрасывает таймер KeepWait, запускает таймер OpenWait и переходит в состояние OpenWait.

Если не было получено сообщения Keepalive или PCErr к моменту завершения отсчета таймера KeepWait, узел PCEP передает сообщение PCErr с Error-Type=1 и Error-value=7, а система освобождает ресурсы PCEP, выделенные для этого партнера, закрывает соединение TCP и переходит в состояние Idle.

В ответ на все прочие события система освобождает ресурсы PCEP, выделенные для этого партнера, и переходит в состояние Idle.

Состояние UP

В состоянии UP узел PCEP начинает обмен сообщениями PCEP в соответствии с характеристиками сессии.

По завершении отсчета таймера Keepalive система перезапускает таймер и передает сообщение Keepalive.

Если не было получено сообщений PCEP (Keepalive, PCReq, PCRep, PCNtf) от партнера PCEP до завершения отсчета DeadTimer, система прерывает сессию PCEP в соответствии с процедурой, определенной в параграфе 6.8, освобождает ресурсы PCEP, выделенные для партнера, закрывает соединение TCP и переходит в состояние Idle.

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

Если система обнаруживает попытку партнера PCEP организовать второе соединение TCP, она останавливает организацию этого соединения и передает сообщение PCErr с Error-Type=9.

При отказе соединения TCP система освобождает ресурсы PCEP, выделенные для партнера, закрывает соединение TCP и переходит в состояние Idle.

Приложение B. Переменные PCEP

Ниже перечислены конфигурационные переменные PCEP.

Таймер Keepalive

Минимальный интервал между последовательными сообщениями PCEP (Keepalive, PCReq, PCRep, PCNtf), передаваемыми партнеру PCEP. Рекомендуемое значение таймера Keepalive составляет 30 секунд.

DeadTimer

Интервал, по истечении которого узел PCEP считает сессию неработающей (down), если не было получено ни одного сообщения PCEP.

SyncTimer

Таймер, применяемый в случае синхронизированных запросов расчета путей с использованием объектов SVEC, определенных в параграфе 7.13.3. Рассмотрим случай, когда сообщение PCReq, принятое PCE, содержит объект SVEC, указывающий M синхронизированных запросов расчета путей. Если после завершения отсчета SyncTimer все M запросов расчета не были получены, возникает протокольная ошибка и элемент PCE должен отвергнуть все запросы расчета путей. Назначение SyncTimer состоит в предотвращении хранения не испозльзованных синхронизированных запросов, один из которых был по той или иной причине потерян (например, в результате некорректного поведения PCC). Таким образом, значение SyncTimer должно быть достаточно велико, чтобы отсчет таймера не завершался при нормальных условиях. Рекомендуемое значение SyncTimer составляет 60 секунд.

MAX-UNKNOWN-REQUESTS

Рекомендуемое значение — 5.

MAX-UNKNOWN-MESSAGES

Рекомендуемое значение — 5.

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

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

Arthi Ayyangar

Juniper Networks

1194 N. Mathilda Ave

Sunnyvale, CA 94089

USA

EMail: arthi@juniper.net

Adrian Farrel

Old Dog Consulting

Phone: +44 (0) 1978 860944

EMail: adrian@olddog.co.uk

Eiji Oki

NTT

Midori 3-9-11

Musashino, Tokyo, 180-8585

JAPAN

EMail: oki.eiji@lab.ntt.co.jp

Alia Atlas

British Telecom

EMail: akatlas@alum.mit.edu

Andrew Dolganow

Alcatel

600 March Road

Ottawa, ON K2K 2E6

CANADA

EMail: andrew.dolganow@alcatel.com

Yuichi Ikejiri

NTT Communications Corporation

1-1-6 Uchisaiwai-cho, Chiyoda-ku

Tokyo, 100-819

JAPAN

EMail: y.ikejiri@ntt.com

Kenji Kumaki

KDDI Corporation

Garden Air Tower Iidabashi, Chiyoda-ku,

Tokyo, 102-8460

JAPAN

EMail: ke-kumaki@kddi.com

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

JP Vasseur (редактор)

Cisco Systems

1414 Massachusetts Avenue

Boxborough, MA 01719

USA

EMail: jpv@cisco.com

JL Le Roux (редактор)

France Telecom

2, Avenue Pierre-Marzin

Lannion 22307

FRANCE

EMail: jeanlouis.leroux@orange-ftgroup.com


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

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

nmalykh@gmail.com

1Multiprotocol Label Switching — многопротокольная коммутация по меткам.

2Generalized MPLS Traffic Engineering — обобщенная многопротокольная коммутация по меткам.

3Path Computation Element Protocol.

4Explicit Route Object — объект с явным маршрутом.

5Type-length-value — тип, размер, значение.

6Resource Reservation Protocol Traffic Engineering Extensions — расширения организации трафика RSVP.

7Explicit Route Object — объект с явным маршрутом.

8Include Route Object — объект со включенным маршрутом.

9Shared Risk Link Group — группа каналов с общими рисками.

10Denial-of-service — отказ в обслуживании.

11TCP Authentication Option.

12Transport Layer Security — защита транспортного уровня.

13Label Distribution Protocol.

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

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

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

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

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




RFC 5425 Transport Layer Security (TLS) Transport Mapping for Syslog

Network Working Group                                       F. Miao, Ed.
Request for Comments: 5425                                    Y. Ma, Ed.
Category: Standards Track                            Huawei Technologies
                                                         J. Salowey, Ed.
                                                     Cisco Systems, Inc.
                                                              March 2009

Транспортное отображение TLS для Syslog

Transport Layer Security (TLS) Transport Mapping for Syslog

PDF

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

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

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

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

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

Этот документ может содержать материалы из документов IETF или участников IETF1, опубликованных или публично доступных до 10 ноября 2008 г. Лица, контролирующие авторские права на некоторые из таких материалов могли не предоставить IETF Trust прав на изменение таких материалов вне контекста стандартизации IETF2. Без получения соответствующей лицензии от лиц, контролирующих авторские права на такие материалы, этот документ не может быть изменен вне контекста стандартизации IETF, а также не могут открываться производные работы за пределами контекста стандартизации. Исключением является лишь форматирование документа для публикации в качестве RFC или перевод на другие языки.

Тезисы

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

Оглавление

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

1. Введение

В этом документе описано использование защиты транспортного уровня (TLS [RFC5246]) для обеспечения защиты соединений, служащих для транспортировки сообщений syslog. Описаны угрозы безопасности syslog и способы использования TLS для преодоления таких угроз.

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

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

  • «инициатор» (originator) генерирует содержимое для передачи в сообщениях syslog;

  • «коллектор» (collector) собирает содержимое сообщений syslog для дальнейшего анализа;

  • «транслятор» (relay) пересылает сообщения, воспринимает сообщения от инициатора или других трансляторов и передает их коллекторам или другим трансляторам;

  • «транспортный отправитель» (transport sender) передает сообщения syslog заданному транспортному протоколу;

  • «транспортный получатель» (transport receiver) принимает сообщения syslog от заданного транспортного протокола;

  • клиент TLS — приложение, которое может инициировать соединение TLS, передавая серверу Client Hello;

  • сервер TLS — приложение, которое может принимать сообщения Client Hello от клиентов и отвечать на низ сообщениями Server Hello.

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

2. Требования безопасности для Syslog

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

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

  • Маскировка. Неуполномоченный транспортный отправитель может передавать сообщения легитимному транспортному получателю или неуполномоченный транспортный получатель может попытаться обмануть легитимного траспортного отправителя с целью получения от того сообщений syslog.

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

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

Другая угроза описана ниже.

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

Ниже перечислены угрозы, которые считаются менее важными для syslog и не рассматриваются в этом документе.

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

  • анализ трафика.

3. Применение TLS для защиты Syslog

TLS можно использовать в качестве защищенного транспорта с учетом всех перечисленных выше основных угроз:

  • защита конфиденциальности для предотвращения раскрытия содержимого сообщений;

  • контроль целостности для предотвращения изменения сообщений в процесс пересылки;

  • аутентификация сервера или взаимная аутентификация для предотвращения маскировки.

Примечание. Этот транспорт (т. е., TLS) защищает syslog поэтапно (hop-by-hop) и не связан с содержимым сообщений syslog. В частности, подтвержденная идентификация транспортного отправителя (например, имя субъекта в сертификате) не обязательно относится к полю HOSTNAME в сообщении syslog. Если нужна проверка подлинности источника сообщений syslog, можно использовать [SYS-SIGN].

4. Элементы протокола

4.1. Выделение портов

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

Порт TCP с номером 6514 выделен для использования по умолчанию при передаче сообщений syslog через TLS в соответствии с данным документом.

4.2. Инициирование

Транспортному отправителю следует инициировать соединение с транспортным получателем, а затем передать TLS Client Hello для начала согласования TLS. После завершения согласования TLS транспортный отправитель может передать первое сообщение MAY.

TLS обычно использует сертификаты [RFC5280] для аутентификации партнеров. Разработчики должны поддерживать TLS 1.2 [RFC5246] и требуется также поддержка обязательного для реализации шифра TLS_RSA_WITH_AES_128_CBC_SHA. Предполагается применимость данного документа для будущих версий TLS и в таких случаях должны поддерживаться обязательные для реализации в соответствующей версии шифры.

4.2.1. Проверка подлинности на основе сертификатов

Транспортный отправитель syslog (клиент TLS) и транспортный получатель syslog (сервер TLS) должны поддерживать аутентификацию на основе сертификатов. Это включает проверку самого сертификата и наличия у партнера соответствующего секретного ключа. Последняя часть выполняется TLS. Для обеспечения взаимодействия между клиентами и серверами нужно реализовать перечисленные ниже методы проверки приемлемости сертификатов.

  • Проверка пути сертификации. Партнер TLS имеет одну или множество доверенных привязок (обычно сертификаты корневых УЦ4), которые позволяют ему проверить связь между именем субъекта и открытым ключом. Нужны дополнительные правила для проверки полномочий транспортного отправителя и получателя syslog (т. е., проверки наличия полномочий у указанного именем субъекта), которые описаны в разделе 5. Проверка пути сертификации выполняется в соответствии с определением [RFC5280]. Этот метод полезен при наличии инфраструктуры открытых ключей (PKI5).

  • Соответствие конечного элемента сертификата. В конфигурации транспортного отправителя и получателя имеется информация, требуемая для идентификации действительных сертификатов его уполномоченных партнеров. Сертификаты конечных элементов могут быть самоподписанными и в этом случае проверка пути сертификации не требуется. Реализации должны поддерживать отпечатки сертификатов (параграф 4.2.2) и могут разрешать другие форматы сертификатов конечных элементов типа сертификатов в DER-представлении. Этот метод служит дополнением к PKI, которое проще в развертывании и обеспечивает достаточный уровень защиты.

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

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

4.2.2. Отпечатки сертификатов

Реализации клиента и сервера должны делать отпечатки своих сертификатов (certificate fingerprint) доступными через интерфейс управления. Метки для алгоритмов берутся из текстовых имен хэш-функций, определенных в реестре IANA Hash Function Textual Names, выделенном в [RFC4572].

Механизм генерации отпечатков заключается в том, что берется хэш сертификата в DER-представлении с использованием криптостойкого алгоритма и результат преобразуется в разделенные двоеточиями шестнадцатеричные байты, каждый из которых представлен двумя символами ASCII в верхнем регистре. Когда значение отпечатка отображается или задается в конфигурации перед ним добавляется метка ASCII для хэш-функции, за которой следует двоеточие. Реализации должны поддерживать SHA-1 в качестве алгоритма хэширования и использовать для его идентификации метку sha-1. Размер хэш-значения SHA-1 составляет 20 байтов, а соответствующий отпечаток будет содержать 65 символов. Пример такого отпечатка приведен ниже.

      sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D

Для проверки хэш-значение извлекается из отпечатка и сравнивается с хэш-значением, рассчитанным для полученного сертификата.

4.2.3. Криптографический уровень

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

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

4.3. Передача данных

Все сообщения syslog должны передаваться как прикладные данные TLS (application data). Возможно помещать множество сообщений syslog в одну запись TLS или разделять одно сообщение syslog для передачи в нескольких записях TLS. Прикладные данные определяются приведенным ниже выражением ABNF [RFC5234].

   APPLICATION-DATA = 1*SYSLOG-FRAME
   SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
   MSG-LEN = NONZERO-DIGIT *DIGIT
   SP = %d32
   NONZERO-DIGIT = %d49-57
   DIGIT = %d48 / NONZERO-DIGIT
   SYSLOG-MSG определено в протоколе syslog [RFC5424].

4.3.1. Размер сообщения

Размер сообщения представляет собой значение счетчика октетов SYSLOG-MSG в SYSLOG-FRAME. Транспортный получатель должен использовать размер сообщения для определения его границы. Верхнего предела для размера сообщений не задается. Однако для обеспечения интероперабельности данная спецификация указывает, что транспортный получатель должен быть способен обрабатывать сообщения размером до 2048 октетов, включительно. Транспортным получателям следует поддерживать обработку сообщений размером до 8192 октетов, включительно.

4.4. Закрытие сессий

Транспортный отправитель должен закрывать соответствующее соединение TLS, если через него больше не планируется доставка сообщений syslog. Он должен передать сигнал TLS close_notify перед закрытием соединения. Транспортный отправитель (клиент TLS) может выбрать отказ от ожидания сигнала close_notify от транспортного получателя и просто закрыть соединение, что приводит к неполному закрытию на стороне транспортного получателя (сервер TLS). После того, как транспортный отправитель получит сигнал close_от транспортного получателя, он должен ответить сигналом close_notify, если у него еще нет информации о том, что соединение уже закрыто транспортным отправителем (например, закрытие соединения указал протокол TCP).

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

5. Правила безопасности

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

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

5.1. Проверка полномочий на основе сертификата конечного элемента

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

Реализации должны поддерживать указание уполномоченных партнеров с использованием отпечатков сертификатов, как описано в параграфах 4.2.1 и 4.2.2.

5.2. Проверки полномочий по имени субъекта

Реализации должны поддерживать проверку пути сертификации [RFC5280]. Кроме того, они должны поддерживать указание уполномоченных партнеров с использованием локально заданных имен хостов и проверку соответствия имен, как описано ниже.

  • Реализации должны поддерживать проверку локально заданных имен хостов значениям dNSName в полях расширения subjectAltName, следует также поддерживать проверку соответствия имени общей части отличительного имени субъекта.

  • Символ-шаблон * (ASCII 42) разрешается использовать в поле dNSName расширения subjectAltName (и общем имени, если оно служит для сохранения имени хоста), но лишь в самой левой (наименее значимой) метке DNS в данном значении. Этому шабблону соответствует любая первая слева метка DNS в имени сервера. Т. е., субъект *.example.com соответствует именам сервером a.example.com и b.example.com, но не соответствует example.com и a.b.example.com. Реализации должны поддерживать шаблоны в сертификатах, как указано выше, но могут включать конфигурационную опцию для запрета этого.

  • Локально заданные имена могут включать символы-шаблоны, соответствующие диапазону значений. Тип поддерживаемых шаблонов может быть более гибким, нежели разрешается в именах субъектов для обеспечения возможности поддержки разных правил для различных сред. Например, правило может разрешать проверку полномочий на основе «доверенного корня» (trust-root-based), где все свидетельства, выпущенные конкретным УЦ (CA), считаются полномочными.

  • Если локально заданные имена являются национальными доменными именами, соответствующие требованиям реализации должны преобразовывать такие имена в формат ACE6 для сравнения в соответствии с правилами раздела 7 в [RFC5280].

  • Реализации могут поддерживать сопоставление заданных локально адресов IP со значениями iPAddress в расширении subjectAltName. В этос случае заданные локально адреса IP преобразуются в строки октетов, как указано в параграфе 4.2.1.6 [RFC5280]. Полученная строка октетов проверяется на совпадение со значением iPAddress в расширении subjectAltName.

5.3. Неаутентифицированный транспортный отправитель

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

5.4. Неаутентифицированный транспортный получатель

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

5.5. Неаутентифицированный транспортный получатель и отправитель

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

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

В этом разделе описаны проблемы безопасности, дополняющие рассмотренные в [RFC5246].

6.1. Правила проверки подлинности и полномочий

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

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

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

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

6.2. Проверка имен

Политика проверки подлинности субъекта сертификата требует сравнения имени субъекта с заданными локально именами. Получение этих имен иными путями (типа запросов DNS) обычно неприемлема, поскольку открывает другие уязвимости защиты.

6.3. Надежность

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

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

7.1. Номер порта

Агентство IANA выделило порт TCP с номером 6514 и именем syslog-tls из диапазона Registered Port Numbers. Этот порт используется по умолчанию для передачи сообщений syslog через TLS, как определено в этом документе.

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

Авторы благодарят Eric Rescorla, Rainer Gerhards, Tom Petch, Anton Okmianski, Balazs Scheidler, Bert Wijnen, Martin Schuette, Chris Lonvick и членов рабочей группы syslog за их участие в дискуссиях. Авторы также признательны Balazs Scheidler, Tom Petch и другим людям за их информацию об угрозах для syslog. Авторы благодарят David Harrington за подробный анализ содержимого и грамматики документа, а также Pasi Eronen за его вклад в разделы по аутентификации и проверке полномочий.

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

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

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

[RFC5234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008.

[RFC5424] Gerhards, R., «The Syslog Protocol», RFC 5424, March 2009.

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

[RFC4572] Lennox, J., «Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)», RFC 4572, July 2006.

[SYS-SIGN] Kelsey, J., «Signed syslog Messages», Work in Progress7, October 2007.

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

Fuyou Miao (редактор)

Huawei Technologies

No. 3, Xinxi Rd

Shangdi Information Industry Base

Haidian District, Beijing 100085

P. R. China

Phone: +86 10 8288 2008

EMail: miaofy@huawei.com

URI: www.huawei.com

Yuzhi Ma (редактор)

Huawei Technologies

No. 3, Xinxi Rd

Shangdi Information Industry Base

Haidian District, Beijing 100085

P. R. China

Phone: +86 10 8288 2008

EMail: myz@huawei.com

URI: www.huawei.com

Joseph Salowey (редактор)

Cisco Systems, Inc.

2901 3rd. Ave

Seattle, WA 98121

USA

EMail: jsalowey@cisco.com


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

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

nmalykh@gmail.com


1В оригинале — IETF Contributions. Прим. перев.

2В оригинале — IETF Standards Process. Прим. перев.

3Transport Layer Security

4Удостоверяющий центр — CA (certification authority). Прим. перев.

5Public Key Infrastructure.

6ASCII Compatible Encoding — совместимое с ASCII представление.

7Работа завершена и опубликована в RFC 5848. Прим. перев.




RFC 5424 The Syslog Protocol

Network Working Group                                        R. Gerhards
Request for Comments: 5424                                  Adiscon GmbH
Obsoletes: 3164                                               March 2009
Category: Standards Track

Протокол Syslog

The Syslog Protocol

PDF

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

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

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

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

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

Этот документ может содержать материалы из документов IETF или участников IETF1, опубликованных или публично доступных до 10 ноября 2008 г. Лица, контролирующие авторские права на некоторые из таких материалов могли не предоставить IETF Trust прав на изменение таких материалов вне контекста стандартизации IETF2. Без получения соответствующей лицензии от лиц, контролирующих авторские права на такие материалы, этот документ не может быть изменен вне контекста стандартизации IETF, а также не могут открываться производные работы за пределами контекста стандартизации. Исключением является лишь форматирование документа для публикации в качестве RFC или перевод на другие языки.

Тезисы

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

Этот документ разрабатывался с учетом устройства традиционной системы syslog. Необходимость создания многоуровневой спецификации связана с тем, что для стандартизации надежных и безопасных расширения syslog остро не хватало документов типа Standards-Track и независимых от транспорта RFC. Без этого документа все прочие стандарты должны были бы определять свой формат пакетов syslog и механизм их доставки, что обязательно привело бы к проблемам совместимости. Многоуровневая архитектура обеспечивает прочную основу и позволяет за один раз создавать код для каждой функции syslog и вида транспорта.

Этот документ отменяет RFC 3164.

Оглавление

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

 

1. Введение

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

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

Документ не описывает форматов хранения сообщений syslog, поскольку это выходит за рамки протокола syslog и не требуется для интероперабельности.

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

Документ отменяет RFC 3164, который включал информацию о некоторых имеющихся реализациях протокола.

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

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

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

Syslog использует три уровня, перечисленных ниже.

  • «содержимое» (syslog content) — информация в сообщениях syslog;

  • «приложение» (syslog application) — генерация, интерпретация, маршрутизация и хранение сообщений syslog;

  • «транспорт» (syslog transport) — передача сообщений в «канал» и считывание из «канала».

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

  • «инициатор» (originator) генерирует содержимое для передачи в сообщениях syslog;

  • «коллектор» (collector) собирает содержимое сообщений syslog для дальнейшего анализа;

  • «транслятор» (relay) пересылает сообщения, воспринимает сообщения от инициатора или других трансляторов и передает их коллекторам или другим трансляторам;

  • «транспортный отправитель» (transport sender) передает сообщения syslog заданному транспортному протоколу;

  • «транспортный получатель» (transport receiver) принимает сообщения syslog от заданного транспортного протокола.

На рисунке 1 показаны уровни и роли.

 +---------------------+    +---------------------+
 |  содержимое         |    |  содержимое         |
 |---------------------|    |---------------------|
 |  приложение syslog  |    |  приложение syslog  | (инициатор,
 |                     |    |                     |  коллектор, транслятор)
 |---------------------|    |---------------------|
 |  транспорт syslog   |    |  транспорт syslog   | (транспортный отправитель,
 |                     |    |                     |  транспортный получатель)
 +---------------------+    +---------------------+
           ^                          ^
           |                          |
            --------------------------

Рисунок 1. Уровни Syslog


4. Базовые принципы

Ниже перечислены принципы, применяемые к коммуникациям syslog.

  • Протокол syslog не обеспечивает подтверждения доставки сообщений. Хотя некоторые виды транспорта могут сообщать о состоянии передачи, концептуально протокол syslog является симплексным (односторонним).

  • Инициаторы и трансляторы можно настроить на передачу одного и того же сообщения множеству коллекторов и/или трансляторов.

  • Инициатор, транслятор и коллектор могут функционально размещаться в одной системе.

4.1. Примеры развертывания

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

            +----------+         +---------+
            |Инициатор |---->----|Коллектор|
            +----------+         +---------+
            +----------+         +----------+         +---------+
            |Инициатор |---->----|Транслятор|---->----|Коллектор|
            +----------+         +----------+         +---------+
            +----------+     +----------+            +----------+     +---------+
            |Инициатор |-->--|Транслятор|-->--..-->--|Транслятор|-->--|Коллектор|
            +----------+     +----------+            +----------+     +---------+
            +----------+         +----------+         +---------+
            |Инициатор |---->----|Транслятор|---->----|Коллектор|
            |          |-+       +----------+         +---------+
            +----------+  \
                           \     +----------+         +---------+
                            +->--|Транслятор|---->----|Коллектор|
                                 +----------+         +---------+
            +----------+         +---------+
            |Инициатор |---->----|Коллектор|
            |          |-+       +---------+
            +----------+  \
                           \     +----------+         +---------+
                            +->--|Транслятор|---->----|Коллектор|
                                 +----------+         +---------+

            +----------+         +----------+            +---------+
            |Инициатор |---->----|Транслятор|---->-------|Коллектор|
            |          |-+       +----------+        +---|         |
            +----------+  \                         /    +---------+
                           \     +----------+      /
                            +->--|Транслятор|-->--/
                                 +----------+
            +----------+         +----------+                   +---------+
            |Инициатор |---->----|Транслятор|---->--------------|Коллектор|
            |          |-+       +----------+           +-------|         |
            +----------+  \                            /        +---------+
                           \     +------------+       /
                            \    |+----------+|      /
                             +->-||Транслятор||->---/
                                 |+----------||    /
                                 ||Инициатор ||->-/
                                 |+----------+|
                                 +------------+

Рисунок 2. Некоторые варианты развертывания syslog.

5. Протокол транспортного уровня

Этот документ не задает какой-либо протокол транспортного уровня. Вместо этого описывается формат сообщений syslog, независимый от транспорта. Транспортные протоколы syslog определяются в других документах. Один из вариантов транспорта определен в [RFC5426] и согласуется с традиционным транспортом UDP. Этот транспорт нужен для поддержки интероперабельности, поскольку протокол UDP исторически применялся для передачи сообщений syslog.

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

5.1. Минимальные требования к транспортному отображению

Все реализации данной спецификации должны поддерживать транспорт на основе TLS, как описано в [RFC5425].

Все реализациям также следует поддерживать основанный на протоколе UDP транспорт, как описано в [RFC5426].

Реализациям рекомендуется использовать транспорт на базе TLS.

6. Формат сообщений Syslog

В сообщениях syslog используются определения ABNF [RFC5234], перечисленные ниже.

      SYSLOG-MSG      = HEADER SP STRUCTURED-DATA [SP MSG]

      HEADER          = PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID
      PRI             = "<" PRIVAL ">"
      PRIVAL          = 1*3DIGIT ; диапазон 0 .. 191
      VERSION         = NONZERO-DIGIT 0*2DIGIT
      HOSTNAME        = NILVALUE / 1*255PRINTUSASCII

      APP-NAME        = NILVALUE / 1*48PRINTUSASCII
      PROCID          = NILVALUE / 1*128PRINTUSASCII
      MSGID           = NILVALUE / 1*32PRINTUSASCII

      TIMESTAMP       = NILVALUE / FULL-DATE "T" FULL-TIME
      FULL-DATE       = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY
      DATE-FULLYEAR   = 4DIGIT
      DATE-MONTH      = 2DIGIT  ; 01-12
      DATE-MDAY       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 в зависимости от месяца и года

      FULL-TIME       = PARTIAL-TIME TIME-OFFSET
      PARTIAL-TIME    = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND [TIME-SECFRAC]
      TIME-HOUR       = 2DIGIT  ; 00-23
      TIME-MINUTE     = 2DIGIT  ; 00-59
      TIME-SECOND     = 2DIGIT  ; 00-59
      TIME-SECFRAC    = "." 1*6DIGIT
      TIME-OFFSET     = "Z" / TIME-NUMOFFSET
      TIME-NUMOFFSET  = ("+" / "-") TIME-HOUR ":" TIME-MINUTE

      STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
      SD-ELEMENT      = "[" SD-ID *(SP SD-PARAM) "]"
      SD-PARAM        = PARAM-NAME "=" %d34 PARAM-VALUE %d34
      SD-ID           = SD-NAME
      PARAM-NAME      = SD-NAME
      PARAM-VALUE     = UTF-8-STRING ; для символов '"', '\' и ']' ДОЛЖНО использоваться
					    ; специальное представление	
      SD-NAME         = 1*32PRINTUSASCII ; кроме '=', SP, ']', %d34 (")

      MSG             = MSG-ANY / MSG-UTF8
      MSG-ANY         = *OCTET ; не начинается с BOM
      MSG-UTF8        = BOM UTF-8-STRING
      BOM             = %xEF.BB.BF
      UTF-8-STRING    = *OCTET ; строка UTF-8 в соответствии с RFC 3629

      OCTET           = %d00-255
      SP              = %d32
      PRINTUSASCII    = %d33-126
      NONZERO-DIGIT   = %d49-57
      DIGIT           = %d48 / NONZERO-DIGIT
      NILVALUE        = "-"

6.1. Размер сообщения

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

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

Если транспортный получатель отсекает часть сообщения, отбрасываться должна последняя часть сообщения (конец). Отсечка сообщения может вызвать повреждение кодировки UTF-8 или данных STRUCTURED-DATA. Транспортный получатель может отбросить такое сообщение или попытаться его обработать.

6.2. HEADER

В заголовке (HEADER) должен использоваться 7-битовый набор символов ASCII в 8-битовых полях, как описано в [RFC5234]. Код ASCII определен в USA Standard Code for Information Interchange [ANSI.X3-4.1968].

Формат заголовка должен обеспечивать некоторую совместимость со старыми системами BSD syslog (см. Приложение A.1).

6.2.1. PRI

В PRI должно быть от 3 до 5 символов, первый и последний из которых являются угловыми скобками. PRI начинается с левой скобки < (знак «меньше», %d60), за которым следует число и правая угловая скобка > (знак «больше», %d62). Число в угловых скобках называют приоритетом (Priority, PRIVAL) и представляет как источник (Facility), так и важность (Severity). Priority может включать от одной до трех десятичных цифр (ABNF DIGITS), которые могут принимать значения от %d48 (для 0) до %d57 (для 9).

Значения Facility и Severity не являются нормативными, но используются часто. Эти значения приведены ниже в таблице только для справки. Значения Facility должны относиться к диапазону от 0 до 23, включительно.

Таблица 1. Источники сообщений syslog

Код

Источник (значимость)

0

Сообщения ядра

1

Сообщения пользовательского уровня

2

Почтовая система

3

Системные службы (демоны)

4

Сообщения, связанные с защитой и предоставлением полномочий

5

Внутренние сообщения syslogd

6

Подсистема печати (line printer)

7

Подсистема сетевых новостей (network news)

8

Подсистема UUCP

9

Часы (демон)

10

Сообщения, связанные с защитой и предоставлением полномочий

11

Демон FTP

12

Подсистема NTP

13

Аудит (log audit)

14

Сигнал (log alert)

15

Часы (демон)

16

Локальное (local0)

17

Локальное (local1)

18

Локальное (local2)

19

Локальное (local3)

20

Локальное (local4)

21

Локальное (local5)

22

Локальное (local6)

23

Локальное (local7)

В каждом сообщении Priority также включает десятичные индикатор уровня важности (Severity). Значения важности и описания приведены в таблице. Severity должны относиться к диапазону от 0 до 7, включительно.

Таблица 2. Уровни важности сообщений syslog

Код

Уровень важности

0

Emergency — чрезвычайная ситуация, система не может использоваться

1

Alert — тревога, требуются незамедлительные действия

2

Critical — критическая ситуация

3

Error — ошибка

4

Warning — предупреждение

5

Замечание, нормальная но важная ситуация (состояние)

6

Informational — информационное сообщение

7

Debug — отладочное сообщение

Значение Priority рассчитывается по формуле 8 * Facility + Severity. Например, для сообщения ядра (Facility=0) с уровнем важности Emergency (Severity=0) будет Priority = 0. А для сообщения local4 (Facility=20) с уровнем важности Notice (Severity=5) мы получим Priority = 165. В PRI сообщения syslog эти значения будут указываться в виде <0> и <165>, соответственно. За угловой скобкой число 0 указывается только для случая Priority = 0, а в остальных случаях использовать символ в начале поля недопустимо.

6.2.2. VERSION

Поле VERSION указывает версию спецификации протокола syslog. Номер версии должен увеличиваться для любой новой спецификации, меняющей любую часть формата HEADER. К таким изменениям относятся добавление или удаление полей, а также изменение синтаксиса или семантики имеющихся полей. Данный документ устанавливает VERSION = 1. Значения VERSION выделяются агентством IANA (параграф 9.1) по процедуре Standards Action, описанной в [RFC5226].

6.2.3. TIMESTAMP

Поле TIMESTAMP содержит формализованную временную метку [RFC3339].

Хотя [RFC3339] разрешает множество вариантов синтаксиса, данный документ вносит дополнительные ограничения. Поле TIMESTAMP должно соответствовать приведенным ниже требованиям:

  • символы T и Z должны использовать верхний регистр (заглавные буквы);

  • использование символа T обязательно;

  • недопустимо использовать високосные секунды.

Инициатору следует включать TIME-SECFRAC, если это позволяют точность часов и производительность. Параметр timeQuality SD-ID, описанный в параграфе 7.1, позволяет инициатору задать точность и достоверность временных меток.

Приложения syslog должны использовать NILVALUE в качестве TIMESTAMP при неспособности syslog получить системное время.

6.2.3.1. Примеры

Пример 1

        1985-04-12T23:20:50.52Z

Это значение представляет время 20 минут 50,52 сек. после 23 часов 12 апреля 1985 года для часового пояса UTC.

Пример 2

        1985-04-12T19:20:50.52-04:00

Здесь представлен тот же момент, что в примере 1, но время указно для часового пояса US Eastern Standard Time (с учетом летнего времени).

Пример 3

        2003-10-11T22:14:15.003Z

Это значение представляет 11 октября 2003 года, 10:14:15 после полудня и 3 мсек. следующей секунды для часового пояса UTC. Временная метка обеспечивает миллисекундное разрешение. Создатель метки может иметь более высокое разрешение, но ограничение дробной части секунд тремя цифрами не позволяет задать время с большей точностью.

Пример 4

         2003-08-24T05:14:15.000003-07:00

Это значение представляет 24 августа 2003 года, 05:14:15 до полудня и 3 мксек. Следующей секунды. Микросекундное разрешение указывается дополнительными цифрами в TIME-SECFRAC. Метка относится к часовому поясу -7 по отношению к UTC. Такая метка может быть создана для часового пояса US Pacific в период действия летнего времени.

Пример 5 — неприемлемая метка TIMESTAMP

         2003-08-24T05:14:15.000000003-07:00

Эта метка похожа на показанную в примере 4, но TIME-SECFRAC указывает время в наносекундах. В результате размер TIME-SECFRAC превышает дозволенные 6 цифр, что делает метку неприемлемой.

6.2.4. HOSTNAME

Поле HOSTNAME указывает машину, котоая была исходным отправителем сообщения syslog.

В поле HOSTNAME следует включать имя хоста или полное доменное имя инициатора в формате, заданном STD 13 [RFC1034]. Этот формат в данном документе называется FQDN3.

На практике не все приложения syslog способны предоставлять FQDN. По этой причине в полях HOSTNAME могут указываться другие значения. В данном документе содержатся предложения по использованию других значений в таких ситуациях. Приложению syslog следует выбирать наиболее конкретное (специфичное) значение из числа представленных ниже в порядке снижения предпочтений (специфичности):

  1. FQDN;

  2. статический адрес IP;

  3. имя хоста (hostname);

  4. динамический адрес IP;

  5. NILVALUE.

При использовании адреса IPv4 он должен указываться в форме десятичных чисел, разделенных точками, как указано в STD 13 [RFC1035]. Если используется адрес IPv6, он должен указываться в корректном текстовом представлении, как описано в параграфе 2.2 [RFC4291].

Приложениям syslog следует использовать в поле HOSTNAME одно и то же имя, пока это возможно.

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

6.2.5. APP-NAME

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

Если приложение syslog не знает своего имени для APP-NAME или не может предоставить такую информацию, можно использовать NILVALUE. Устройство может оказаться не способным предоставить эту информацию в силу ограничений локальной политики, а также в результате недоступности информации или ее неприменимости к данному устройству.

Это поле может присваиваться оператором.

6.2.6. PROCID

Значения PROCID, включаемые в сообщения, не имеют переносимого (за пределы локальной системы) смысла и могут лишь в некоторых случаях показывать прерывание работы syslog. Поле не имеет какого-либо конкретного синтаксиса и семантики — оно зависит от реализации и/или оператора. При отсутствии идентификатора может указываться значение NILVALUE.

Поле PROCID часто применяется для указания имени или идентификатора процесса, связанного с системой syslog. При недоступности имени и идентификатора может указываться значение NILVALUE. На встраиваемых системах без идентификаторов процесса в ОС в качестве PROCID может служить идентификатор перезагрузки.

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

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

6.2.7. MSGID

В поле MSGID следует указывать тип сообщения. Например, межсетевой экран может указывать в поле MSGID значение TCPIN для входящего трафика TCP и TCPOUT для исходящего. Сообщения с одинаковыми полями MSGID должны отражать события с одинаковой семантикой. Само поле MSGID является текстовой строкой без дополнительной семантики и предназначено для фильтрации сообщений на трансляторах и коллекторах.

Если приложение syslog не может предоставить какого-либо значения для этого поля, следует использовать NILVALUE.

Это поле может присваиваться оператором.

6.3. STRUCTURED-DATA

Механизм STRUCTURED-DATA обеспечивает представление информации в четко определенном, легко читаемом и интерпретируемом формате. Имеется множество вариантов использования этого механизма. Например, с его помощью можно указать метаданные о сообщении syslog или специфическую для приложения информацию типа счетчиков трафика или адресов IP.

Структура STRUCTURED-DATA может содержать множество структурированных элементов данных, которые обозначаются далее SD-ELEMENT.

Если структура не содержит структурированных элементов данных, в поле STRUCTURED-DATA должно помещаться значение NILVALUE.

Данные в STRUCTURED-DATA должны представляться в 7-битовой кодировке ASCII, как описано в [RFC5234]. Коды ASCII определены с USA Standard Code for Information Interchange [ANSI.X3-4.1968]. Исключением является поле PARAM-VALUE (параграф 6.3.3), в котором должна использоваться кодировка UTF-8.

Коллектор может игнорировать некорректно сформированные элементы STRUCTURED-DATA, транслятор должен пересылать такие поля STRUCTURED-DATA в неизменном виде.

6.3.1. SD-ELEMENT

Элемент данных SD-ELEMENT состоит из имени и пар «имя — значение». Имя обозначается SD-ID, пары «имя — значение» — SD-PARAM.

6.3.2. SD-ID

Регистр символов в SD-ID принимается во внимание и эти поля служат уникальными идентификаторами типа и назначения SD-ELEMENT. В одном сообщении недопустимо наличие одинаковых SD-ID.

Для имен SD-ID используются два формата, описанных ниже.

  • Имена, не содержащие символа @ (ABNF %d64), зарезервированы для распределения по процедуре IETF Review, описанной в BCP26 [RFC5226]. Определенные к настоящему моменту имена описаны в разделе 7. Имена такого формата применимы лишь после регистрации в IANA. В зарегистрированных именах недопустимо наличие символов @ (ABNF %d64), = (ABNF %d61), ] (ABNF %d93), » (ABNF %d34), пробелов и символов управления (символы ASCII с кодами 127 и от 0 до 32).

  • Кто угодно может определить дополнительные SD-ID, используя формат name@<private enterprise number> (например, ourSDID@32473). Формат имени слева от символа @ не задается, однако эти имена должны представлять строки печатных символов US-ASCII и в них недопустимо включать символы @ (ABNF %d64), = (ABNF %d61), ] (ABNF %d93), » (ABNF %d34), пробелов и символы управления. Справа от символа @ должен указываться фирменный номер (private enterprise number), как описано в параграфе 7.2.2. В этом документе в качестве такого номера используется строка 32473. Это значение было выделено IANA для использования в качестве примеров в документации. Разработчики должны использовать выделенное им значение номера при создании локально расширяемых имен SD-ID.

6.3.3. SD-PARAM

Каждая структура SD-PARAM состоит из имени (PARAM-NAME) и значения (PARAM-VALUE).

Регистр символов в PARAM-NAME принимается во внимание. Агентство IANA контролирует выделение значений PARAM-NAME, за исключением имен в SD-ID, содержащих символ @. Область действия PARAM-NAME находится внутри конкретного SD-ID. Таким образом, одинаковые имена PARAM-NAME в разных SD-ID не совпадают.

Для поддержки разных языков в поле PARAM-VALUE должна применяться кодировка UTF-8. Приложение syslog может ввести любую корректную последовательность UTF-8. Приложения syslog должны воспринимать любые корректные последовательности UTF-8 в «кратчайшей форме». Недопустимы отказы по причине наличия в PARAM-VALUE управляющих символов. Приложение syslog может менять сообщения с управляющими символами (например, заменяя октеты со значением 0 (USASCII NUL) четырьмя символами #000). По причинам, описанным в параграфе 3.1 UNICODE TR36 [UNICODE-TR36], инициатор должен представлять сообщения в «кратчайшей форме» (shortest form), а коллекторам недопустимо интерпретировать сообщения, не имеющие «кратчайшей формы» (non-shortest form).

В PARAM-VALUE для символов » (ABNF %d34), \ (ABNF %d92) и ] (ABNF %d93) должно использоваться escape-представление, требуемое для предотвращения ошибок при разборе. Использование escape-представления для символа ] не является строго обязательным, но данная спецификация требует это для предотвращения ошибок при реализации приложений syslog. Для из этих трех символов должно использоваться представление \», \\ и \], соответственно. Escape-представление символа \ применяется для согласованности с другими частями сообщений syslog, а также с традиционными приложениями syslog.

Символ \, за которым не следует ни одного из указанных выше трех символов, рассматривается, как неприемлемая escape-последовательность. В таких случаях этот и следующий за ним символ должны трактоваться, как обычные символы. Таким образом, некорректная последовательность не изменяется.

SD-PARAM может неоднократно повторяться в одном SD-ELEMENT.

6.3.4. Контроль изменений

После определения SD-ID и PARAM-NAME менять синтаксис и семантику этих объектов недопустимо. Если нужно изменить существующий объект, должны создаваться новые SD-ID или PARAM-NAME , а старые сохраняться неизменными. К существующим SD-ID можно добавить необязательные (опциональные) PARAM-NAME.

6.3.5. Примеры

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

Пример 1 — корректно

           [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]

Этот пример показывает структурированный элемент данных с неконтролируемым IANA SD-ID типа exampleSDID@32473, имеющим три параметра.

Пример 2 — корректно

           [exampleSDID@32473 iut="3" eventSource="Application"
           eventID="1011"][examplePriority@32473 class="high"]

Аналогично примеру 1, но включает второй структурированный элемент данных, который следует сразу же за первым (без SP между ними).

Пример 3 — некорректно

           [exampleSDID@32473 iut="3" eventSource="Application"
           eventID="1011"] [examplePriority@32473 class="high"]

Этот пример похож на предыдущий, но включает небольшую ошибку — между двумя структрированными элементами данных имеется пропуск (]SP[). Это некорректно и приводит к тому, что поле STRUCTURED-DATA будет заканчиваться после первого элемента, а второй будет интерпретироваться, как часть поля MSG.

Пример 4 — некорректно

           [ exampleSDID@32473 iut="3" eventSource="Application"
           eventID="1011"][examplePriority@32473 class="high"]

Этот пример почти совпадает с примером 2, но включает другую ошибку — символ SP после начальной скобки. Структурированный элемент SD-ID должен следовать сразу же после открывающей скобки, поэтому наличие пропуска (SP) делает поле STRUCTURED-DATA неприемлемым. Приложение syslog может отбросить такое сообщение.

Пример 5 — корректно

           [sigSig ver="1" rsID="1234" ... signature="..."]

Пример 5 является корректным и показывает гипотетический SD-ID, выделенный IANA. Точки в этом примере применены для сокращения.

6.4. MSG

Компонента MSG содержит сообщение в свободной форме с информацией о событии.

В MSG следует использовать кодировку UNICODE в варианте UTF-8, как описано в [RFC3629]. Если приложение syslog не может представить MSG в Unicode, оно может воспользоваться любой другой кодировкой.

Приложениям syslog следует избегать включения октетов со значениями меньше 32 (диапазон символов управления традиционной кодировки US-ASCII за исключением DEL). Эти значения разрешены, но приложения syslog могут менять такие символы при получении. Например, они могут быть заменены escape-последовательностями (т. е., 0 может смениться на \0). Приложениям syslog не следует менять значения каких-либо иных октетов.

Если приложение syslog представляет MSG в кодировке UTF-8, строка должна начинаться с маски BOM5, которая для UTF-8 представляет собой ABNF %xEF.BB.BF. Приложение syslog должно использовать «кратчайшую форму» (shortest form) и может применять любые корректные последовательности UTF-8.

Если приложение syslog обрабатывает строку MSG, начинающуюся с BOM и MSG содержит UTF-8 не в кратчайшей форме, недопустимо интерпретировать MSG, как строку в кодировке UTF-8 по причинам, указанным в параграфе 3.1 [UNICODE-TR36]. Рекомендации для таких случаев приведены в Приложении A.8.

В соответствии с UNICODE TR36 [UNICODE-TR36] приложению syslog недопустимо интерпретировать сообщения, которые не имеют кратчай1шей формы. Им недопустимо также интерпретировать некорректные последовательности UTF-8.

6.5. Примеры

Ниже приведены примеры корректных сообщений syslog, сопровожденные описаниями. Примеры основаны на похожих примерах из [RFC3164] и могут быть знакомы читателям. Непечатаемая маска Unicode BOM в примерах обозначена последовательностью BOM.

Пример 1 — без STRUCTURED-DATA

        <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
        - BOM'su root' failed for lonvick on /dev/pts/8

В этом примере VERSION имеет значение 1, Facility — 4, а Severity — 2. Сообщение было создано 11 октября 2003 года в 10:14:15 после полудня по времени UTC, плюс 3 мсек следующей секунды. Сообщение исходит от хоста, который идентифицирует себя именем mymachine.example.com. Поле APP-NAME имеет значение su, PROCID не известно, а MSGID — ID47. Компонента MSG является строкой su root’ failed for lonvick… в кодировке UTF-8, указанной BOM. Структурированных данных в сообщении нет, это показано символом «-» в поле STRUCTURED-DATA.

Пример 2 — без STRUCTURED-DATA

         <165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1
         myproc 8710 - - %% It's time to make the do-nuts.

В этом примере VERSION снова имеет значение 1, Facility — 20, а Severity 5. Сообщение было создано 24 августа 2003 года в 5:14:15 до полудня по времени -7 часов относительно UTC, плюс 3 мксек следующей секунды. Поле HOSTNAME содержит адрес 192.0.2.1, поскольку приложение syslog не знает имени FQDN и указало вместо него один из адресов IPv4. Поле APP-NAME имеет значение myproc, а PROCID = 8710 (это может быть, например, UNIX PID). STRUCTURED-DATA нет в сообщении, что показано символом «-» в поле STRUCTURED-DATA. Идентификатора сообщения (MSGID) нет и это показано символом «-» в поле MSGID.

Текст сообщения %% It’s time to make the do-nuts. Не включает Unicode BOM и приложение syslog не знает кодировки компоненты MSG.

Пример 3 — со STRUCTURED-DATA

           <165>1 2003-10-11T22:14:15.003Z mymachine.example.com
           evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
           "Application" eventID="1011"] BOMAn application event log entry...

Этот пример создан на основе примера 1, однако в нем содержится структура STRUCTURED-DATA с одним элементом [exampleSDID@32473 iut=»3″ eventSource=»Application» eventID=»1011″]. Само сообщение (MSG) является строкой An application event log entry… в кодировке UTF-8, указанной BOM.

Пример 4 — только STRUCTURED-DATA

           <165>1 2003-10-11T22:14:15.003Z mymachine.example.com
           evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
           "Application" eventID="1011"][examplePriority@32473 class="high"]

Этот пример показывает сообщение со STRUCTURED-DATA, но без MSG. Такие сообщения допускаются.

7. Идентификаторы структурированных данных

В этом разделе описаны изначально зарегистрированные IANA значения SD-ID. Определение структурированных элементов данных приведено в параграфе 6.3. Все определенные здесь SD-ID являются необязательными (OPTIONAL).

Для некоторых из этих параметров указан максимальный размер значения в символах. В каждом из таких случаев приложение syslog должно быть готово получить указанное число символов в любом корректном варианте UTF-8. Поскольку один символ может занимать до 6 октетов, приложениям syslog рекомендуется быть готовыми принять до 6 октетов на символ.

7.1. timeQuality

Элемент timeQuality в SD-ID может использоваться инициатором для описания своего понимания системного времени. Этот SD-ID следует включать, если инициатор не имеет должной синхронизации с надежным внешним источником точного времени или не знает корректного часового пояса. Основным применением этого элемента структурированных данных является предоставления сведений об уровне доверия к значению TIMESTAMP (см. параграф 6.2.3). Все параметры этого элемента являются необязательными.

7.1.1. tzKnown

Параметр tzKnown показывает, известен ли инициатору часовой пояс. При известном часовом поясе должно указываться значение 1. Если информация о часовом поясе сомнительна, должно указываться значение 0. Если инициатор знает часовой пояс, но хочет указывать время в формате UTC, он должен указать значение 1 (часовой пояс известен).

7.1.2. isSynced

Параметр isSynced говорит о наличии синхронизации с надежным внешним источником синхронизации (например, по протоколу NTP). Если время инициатора синхронизировано, он должен указывать значение 1, в противном случае должно указываться значение 0.

7.1.3. syncAccuracy

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

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

7.1.4. Примеры

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

   [timeQuality tzKnown="0" isSynced="0"]

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

Ниже приведен пример сообщений от инициатора, знающего часовой пояс и синхронизированного от надежного внешнего источника.

   [timeQuality tzKnown="1" isSynced="1"]

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

   [timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"]

Разница между двумя предыдущими примерами заключается в том, что во втором случае инициатор предполагает, что его локальное время отклоняется от «истинного» не более, чем на 60 секунд. Таким образом, если инициатор указывает 9:00:00, это говорит, событие произошло не ранее 8:59:00 и не позднее 9:01:00.

7.2. origin

Элемент origin в SD-ID может служить для индикации инициатора сообщения syslog. Ниже описаны параметры элемента. Все эти параметры являются необязательными.

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

7.2.1. ip

Параметр ip указывает IP-адрес, известный инициатору в момент создания сообщения. Этот параметр должен содержать текстовое представление адреса IP, как описано в параграфе 6.2.4.

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

Если у инициатора множество адресов IP, он может включить в параметр ip один из таких адресов и может также указать множество параметров ip в одном элементе структурированных данных origin.

7.2.2. enterpriseId

Параметр enterpriseId должен содержать код SMI Network Management Private Enterprise Code, поддерживаемый IANA, с префиксом iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). Следующее за префиксом значение должно быть уникальным, а также должно быть зарегистрировано в IANA в соответствии с RFC 2578 [RFC2578]. Предприятия имеют полномочия выделять значения только в субдереве iso.org.dod.internet.private.enterprise.<private enterprise number>, выделенном IANA этому предприятию. Параметр enterpriseId должен содержать только значение из субдерева iso.org.dod.internet.private.enterprise.<private enterprise number>. В общем случае требуется лишь выделенный IANA номер (одно значение). Предприятие может использовать дополнительные субидентификаторы после выделенного предприятию номера. Такие субидентификаторы должны разделяться точками и представляться в десятичном формате. Примерм может служить номер 32473.1.2. Следует отметить, что идентификатор 32473.1.2 служит примером и применять его на практике недопустимо. Полный список актуальных номеров PEN6 поддерживается IANA.

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

7.2.3. software

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

Параметр software представляет собой строку. Недопустимо использовать в этой строке более 48 символов.

7.2.4. swVersion

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

Параметр swVersion представляет собой строку. Недопустимо использовать в этой строке более 32 символов.

7.2.5. Пример

Ниже приведен пример с указанием двух адресов IP.

   [origin ip="192.0.2.1" ip="192.0.2.129"]

В этом примере инициатор указывает наличие у него двух адресов IP — 192.0.2.1 и 192.0.2.129.

7.3. meta

Элемент meta в SD-ID может служить для предоставления мета-данных о сообщении. Параметры этого элемента описаны ниже, все параметры являются необязательными (OPTIONAL). При использовании элемента meta в SD-ID следует включить хотя бы один параметр.

7.3.1. sequenceId

Параметр sequenceId служит для отслеживания порядка, в котором инициатор отправляет сообщения транспорту syslog для передачи. Этот параметр является целым числом, для которого должно устанавливаться значение 1 при запуске функции syslog. Значение параметра должно увеличиваться для каждого последующего сообщения. Максимальное значение номера составляет 2147483647 и при достижении максимума следующее сообщение должно получать номер 1.

7.3.2. sysUpTime

Параметр sysUpTime может использоваться для включения в параметр SNMP sysUpTime в сообщении. Синтаксис и семантика параметра определены в [RFC3418].

Протокол syslog не поддерживает напрямую синтаксис SNMP INTEGER и значение должно представляться в десятичном формате (без десятичной точки) с использованием только символов 0, 1, 2, 3, 4, 5, 6, 7, 8 и 9.

Смысл параметра указан в RFC 3418, как «время (в сотых долях секунды) с момента, когда связанная с сетевым управленим часть системы была в последний раз реинициализирована». Это, естественно, относится к связанной с SNMP частью управления системой, которая может не совпадать с той частью системы управления, которая связана с syslog.

7.3.3. language

Параметр language может использоваться инициатором для указания естественного языка, применяемого в поле MSG. Если параметр используется, он должен содержать идентификатор языка, определенный в BCP 47 [RFC4646].

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

8.1. Кодировка UNICODE

Этот документ задает использование кодировки UTFдля полей PARAM-VALUE и MSG. С кодировкой UNICODE связано множество проблем безопасности. Всем разработчикам и операторам следует внимательно прочесть документ UNICODE TR36 [UNICODE-TR36] (UTR36), в котором рассмотрены эти проблемы. Данный документ защищает от технических проблем, описанных в UTR36, требуя применять «кратчайшую форму» (shortest form) кодирования для приложений syslog. Однако возможность путаницы, связанной с одинаковым изображением разных символов, сохраняется. Этот документ пытается минимизировать влияние данной проблемы, разрешая использовать UNICODE только там, где ожидаются и требуются локальные сценарии (script). Во всех прочих полях требуется использовать кодировку US-ASCII. Кроме того, поля PARAM-VALUE и MSG не следует рассматривать в качестве основного источника идентификационной информации и это позволит дополнительно снизить риск, связанный с одинаковым изображением разных символов.

8.2. Управляющие символы

Этот документ не вносит каких-либо обязательных для исполнения ограничений на содержимое MSG и PARAM-VALUE. Поэтому данные поля могут содержать символы управления, включая NUL.

В некоторых языках программирования (прежде всего, C и C++) символ NUL (ABNF %d00) традиционно применяется в качестве завершения строки. Большинство реализаций этих языков предполагают, что строка завершается первым NUL-символом. Это ограничение отражается прежде всего на использовании библиотек. Данное ограничение часто переносится на прикладные программы и языки сценариев, написанные с использованием упомянутых языков. Таким образом, символы NUL требуют внимательного отношения и аккуратной обработки. Атакующий может преднамеренно включить символы NUL для сокрытия расположенной после них информации. Некорректная обработка NUL-символов может также приводить к искажению контрольных сумм, передаваемых внутри сообщений.

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

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

Кроме того, атакующий может использовать недопустимые последовательности UTF-8 для вставки управляющих символов ASCII.

Данная спецификация разрешает приложениям syslog переформатировать полученные управляющие символы. Это обусловлено, в частности, значительными рисками, связанными с управляющими символами. Инициаторам следует принимать во внимание, что при использовании ими кодировок, отличных от ASCII и UTF8, получатель может «повредить» сообщение при попытке отфильтровать управляющие символы ASCII.

8.3. Отсечка сообщений

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

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

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

8.4. Повторное использование сообщений

В протоколе syslog нет механизмов детектирования повторного применения сообщений (replay). Атакующий может записать набор сообщений, показывающих нормальную работу машины. Позднее он может удалить данную машину из сети и отправить собранные сообщения syslog транслятору или коллектору. Даже с учетом поля TIMESTAMP в заголовке (HEADER) атакующий может записать пакеты и просто изменить временные метки в соответствии с текущим временем, а потом повторно передать сообщения. Администраторы могут не заметить ничего необычного в полученных сообщениях и ошибочно трактовать их получение как признак нормальной работы машины.

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

8.5. Гарантии доставки

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

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

Гарантированная доставка сообщений желательна не всегда. Гарантированная доставка означает необходимость блокировки инициатора или транслятора когда коллектор или транслятор не способен больше воспринимать сообщения. В некоторых операционных системах (Unix/Linux) инициатор или транслятор syslog работает в рамках системного процесса с высоким приоритетом (syslogd). Если это процесс блокируется, система в целом «зависает». То же самое будет наблюдаться при взаимной блокировке между syslogd и, например, сервером DNS.

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

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

Поскольку syslog может генерировать неограниченный объем данных, передача этих данных по протоколу UDP в общем случае проблематична по причине слабого контроля перегрузок в UDP. Механизмы контроля насыщения, которые реагируют на перегрузку снижением скорости передачи и обеспечивают беспристрастное распределение пропускной способности между потоками одного пути, играют важную роль в обеспечении стабильной работы Internet [RFC2914]. Этим объясняется то, что транспорт TLS для syslog требуется реализовать и этот траспорт рекомендуется для общего применения.

Единственным случаем, где транспорт UDP для syslog может служить альтернативно для транспорта TLS, являются управляемые сети в которых могут быть явно обеспечены пути для трафика UDP syslog с помощью механизмов организации трафика (traffic engineering) типа ограничения скорости или резервирования пропускной способности. Во всех других следах следует применять транспорт TLS.

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

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

8.7. Целостность сообщений

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

8.8. Просмотр сообщений

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

Для предотвращения этой проблемы операторам рекомендуется использовать защищенное транспортное отображение.

8.9. Неприемлемая конфигурация

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

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

8.10. Петли в пересылке

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

8.11. Вопросы загрузки

Сетевые администраторы должны найти время для оценки емкости коллектора syslog. Атакующий может организовать DoS-атаку7, заполняя дисковое пространство коллектора ложными сообщениями. Организация циклической перезаписи позволяет решить эту проблемы, но при этом администратор утратит возможность видеть достаточно старые8 записи.Транспортный получатель должен иметь сетевой интерфейс, способный принимать отправленные ему сообщения.

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

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

8.12. Отказ в обслуживании

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

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

9.1. VERSION

Агентство IANA создало реестр syslog Version Values значений VERSION, описанных в параграфе 6.2.2. Номера версий должны увеличиваться для каждой новой спецификации протокола syslog, в которой меняется какая-либо из частей заголовка (HEADER). Изменения включают добавление или удаление полей, а также смену синтаксиса или семантики имеющихся полей.

Значения VERSION должны регистрироваться в соответствии с процедурой Standards Action, как описано в [RFC5226]. Зарегистрированное IANA значение VERSION приведено в таблице 3.

Таблица 3. Зарегистрированное IANA значение VERSION

Версия

Формат

1

Определен в [RFC5424]

9.2. SD-ID

Агентство IANA создало реестр syslog Structured Data ID Values для идентификаторов структурированных данных (SD-ID) и связанных с ними значений PARAM-NAME, описанных в разделе 7.

Новые значения SD-ID и PARAM-NAME должны регистрироваться в соответствии с процедурой IETF Review, описанной в [RFC5226].

После определения SD-ID и SD-PARAM синтаксис и семантику этих объектов недопустимо менять. Если желательно изменить имеющиеся объекты, должны создаваться новые SD-ID или SD-PARAM, а прежние сохраняться неизменными.

Здесь даны предложения по локально расширяемым именам. Агентство IANA не будет регистрировать и контролировать имена, содержащие символ @ (ABNF %d64).

Зарегистрированные IANA значения SD-ID и PARAM-NAME приведены в таблице 4.

Таблица 4. Зарегистрированные IANA значения SD-ID и их PARAM-NAME

SD-ID

PARAM-NAME

Тип

timeQuality

OPTIONAL

tzKnown

OPTIONAL

isSynced

OPTIONAL

syncAccuracy

OPTIONAL

origin

OPTIONAL

ip

OPTIONAL

enterpriseId

OPTIONAL

software

OPTIONAL

swVersion

OPTIONAL

meta

OPTIONAL

sequenceId

OPTIONAL

sysUpTime

OPTIONAL

language

OPTIONAL

10. Рабочая группа

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

syslog@ietf.org

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

Chris Lonvick

Cisco Systems

EMail: clonvick@cisco.com

David Harrington

Huawei Technologies USA

EMail: dbharrington@comcast.net

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

Авторы благодарят Chris Lonvick, Jon Callas, Andrew Ross, Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado Colussi, Clement Mathieu, Didier Dalmasso и всех других людей, предоставивших свои комментарии к разным версиям этого предложения.

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

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

[ANSI.X3-4.1968] American National Standards Institute, «USA Code for Information Interchange», ANSI X3.4, 1968.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

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

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC2914] Floyd, S., «Congestion Control Principles», BCP 41, RFC 2914, September 2000.

[RFC3339] Klyne, G., Ed. and C. Newman, «Date and Time on the Internet: Timestamps», RFC 3339, July 2002.

[RFC3418] Presuhn, R., «Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3418, December 2002.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC4646] Phillips, A. and M. Davis, «Tags for Identifying Languages», BCP 47, RFC 4646, September 2006.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC5425] Fuyou, M., Yuzhi, M., and J. Salowey, «TLS Transport Mapping for Syslog», RFC 5425, March 2009.

[RFC5426] Okmianski, A., «Transmission of Syslog Messages over UDP», RFC 5426, March 2009.

[UNICODE-TR36] Davis, M. and M. Suignard, «UNICODE Security Considerations», July 2005.

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

[RFC3164] Lonvick, C., «The BSD Syslog Protocol», RFC 3164, August 2001.

Приложение A. Рекомендации для разработчиков

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

A.1. Отношения с BSD Syslog

Хотя приложения BSD syslog используются весьма широко, формат этой системы никогда не был стандартизован формально. Наблюдаемые форматы описаны в [RFC3164], относящемся к серии информационных (Informational RFC), и практика показывает наличие множества разных реализаций. Исследования в процессе создания этого документа показали, что у разных реализаций syslog на различных платформах очень мало общего. Единственное, на что все реализации согласны, — начинать сообщения с «<» PRIVAL «>». Во всем остальном унаследованные сообщения syslog не используют согласованного формата. По этой причине в RFC 3164 не описаны конкретные элементы сообщений syslog. В документе сказано, что любые сообщения, адресованные в порт syslog UDP, должны трактоваться как сообщения syslog, независимо от их формата и содержимого.

Данный документ сохраняет синтаксис и семантику значения PRI. Это позволит унаследованным реализациям syslog сохранить совместимость генерируемых сообщений syslog с данной спецификацией .

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

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

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

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

Часть MSG описана как TAG и CONTENT в RFC 3164. В данном документе MSG представляет собой то, что обозначено CONTENT в RFC 3164. TAG сейчас является частью заголовка, не представляя собой отдельного поля. Значение TAG разделено между полями APP-NAME, PROCID и MSGID. Это несколько отличается отличается от использования TAG, но в большинстве случаев обеспечивает ту же функциональность.

В RFC 3164 структурированные данные (STRUCTURED-DATA) не описаны. Если соответствующее этому документу сообщение, содержащее STRUCTURED-DATA, нужно преобразовать в соответствии с RFC 3164, STRUCTURED-DATA просто становится частью текста в свободном формате RFC 3164 CONTENT.

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

A.2. Размер сообщений

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

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

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

Разработчикам следует помнить о том, что размеры сообщений задаются в октетах. Может возникать весьма большая разница между числом символов в кодировке UTF-8 и числом соответствующих им октетов.

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

A.3. Значения важности

В этом разделе приведены рекомендации по использованию значений важности (Severity) описанных в параграфе 6.2.1.

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

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

A.4. Точность TIME-SECFRAC

Значение TIMESTAMP, описанное в параграфе 6.2.3, поддерживает доли секунд. Это служит основой для очень распространенной ошибки кодирования, когда удаляются начальные нули из дробной части секунд. Например, TIMESTAMP «2003-10-11T22:13:14.003» можно ошибочно записать в виде «2003-10-11T22:13:14.3». Это будет давать дробную часть в 300 мсек вместо исходных 3 мсек.

A.5. Регистр символов в именах

Имена используются в различных частях этого документа (например, для SD-ID и PARAM-NAME). В документе используется правило lower camel case9. Каждое имя начинается с маленькой буквы (нижний регистр), а каждое новое слово, встроенное в имя, начинается с заглавной буквы без использования дефиса или другого разделителя. Примером этого может служить timeQuality.

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

A.6. Приложения Syslog, не знающие времени

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

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

A.7. Замечания по timeQuality SD-ID

Рекомендуется по умолчанию использовать значение 0 для параметра tzKnown (параграф 7.1.1). Следует указывать значение 1 лишь в тех случаях, когда администратор указал в конфигурации конкретный часовой пояс. Можно использовать значение 1 по умолчанию, если операционная система предоставляет точную информацию о часовом поясе. Однако и в таких случаях администратору следует убедиться в корректности данных о часовом поясе.

Важно не порождать заблуждений о точности временных меток в timeQuality SD-ID ( параграф 7.1). Инициатору следует указывать только такую точность, в которой он уверен. В общем случае предполагается, что администратор может выяснить точность часов по конфигурации оператора. По умолчанию точность часов указывать не следует.

A.8. Кодировка UTF-8 и BOM

В этом документе указано, что информация SD-PARAMS всегда должна представляться в кодировке UTF-8. Использование других кодировок в разделе MSG (включая кодировку ASCIIPRINT) не разрешается для устройств, соответствующих данной спецификации. Здесь нужно рассмотреть два особых случая. Во-первых, соответствующие данной спецификации приложения syslog, могут оказаться не способны убедиться в том, что представленная инициатором информация использует кодировку UTF-8. Если нет возможности с уверенностью определить это, приложение syslog может выбрать отказ от включения BOM в MSG. Если приложение syslog имеет достоверное указание того, что содержимое сообщения представлено в кодировке UTF-8, ему следует включать BOM. В другом случае транслятор syslog может пересылать сообщения от устройств, которые не соответствуют данной спецификации. В этой ситуации устройство явно не будет включать BOM, пока не будет уверенности в том, что полученное сообщение использует кодировку UTF-8.

Адрес автора

Rainer Gerhards

Adiscon GmbH

Mozartstrasse 21

Grossrinderfeld, BW 97950

Germany

EMail: rgerhards@adiscon.com


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

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

nmalykh@gmail.com


1В оригинале — IETF Contributions. Прим. перев.

2В оригинале — IETF Standards Process. Прим. перев.

3Fully Qualified Domain Name — полное доменное имя.

4Mail transfer agent – агент передачи электронной почты.

5Unicode byte order mask – маска порядка байтов Unicode.

6Private Enterprise Numbers.

7Denial of Service — отказ в обслуживании.

8Больше продолжительности цикла. Прим. перев.

9Стиль верблюда.