Протоколы Internet

         

Язык описания маршрутной политики RPSL


4.4.11.8 Язык описания маршрутной политики RPSL

Семенов Ю.А. (ГНЦ ИТЭФ)

1. Введение

Язык описания маршрутной политики RPSL (Routing Policy Specification Language) позволяет оператору сети специфицировать маршрутную политику на различных уровнях иерархии Интернет, например, на уровне автономных систем (AS). Так что низкоуровневые конфигурации маршрутизаторов могут генерироваться на основании спецификаций RPSL. Язык RPSL является расширяемым и не препятствует внедрению новых протоколов маршрутизации.

Язык RPSL призван заменить язык спецификации маршрутной политики, используемый в настоящее время и описанный в документах RIPE-181 [6] или RFC-1786 [7]. RIPE-81 [8] был первым языком, использованным в Интернет для спецификации маршрутных политик. В процессе использования RIPE-181 стало понятно, что некоторые политики не могут быть специфицированы и необходим более совершенный язык.

Язык RPSL был сконструирован так, чтобы описание всей политики маршрутизации записывалось в одну распределенную базу данных, улучшая целостность маршрутизации в Интернет. RPSL не является языком конфигурации маршрутизатора. Язык RPSL сформирован так, чтобы конфигурация маршрутизатора осуществлялась на основе описания маршрутной политики автономной системы (класс aut-num) в сочетании с описанием маршрутизатора (класс inet-rtr), которое предоставляет идентификатор маршрутизатора, номер автономной системы, описания интерфейсов и партнеров маршрутизатора. Эти данные используются совместно с глобальной базой данных карты автономных систем (класс as-set), и информацией об автономных системах отправителях и о маршрутных префиксах (классы route и route-set).

Язык RPSL является объектно-ориентированным, то есть, объекты содержат блоки описания политики и административную информацию. Эти объекты регистрируются в IRR (Internet Routing Registry) авторизованными организациями. О IRR смотри [1, 17, 4].

Далее рассматриваются классы, которые используются для определения различных политик и административных объектов. Класс "mntner" определяет средства, предназначенные для добавления, уничтожения и модификации набора объектов. Классы "person" и "role" описывают технический и административный персонал, с которым можно установить контакт. Автономные системы (AS) специфицируются с помощью класса "aut-num". Маршруты специфицируются посредством класса "route". Наборы объектов могут быть определены с помощью классов "as-set", "route-set", "filter-set", "peering-set" и "rtr-set". Класс "dictionary" предоставляет возможность расширения возможностей языка. Класс "inet-rtr" используется для спецификации маршрутизаторов. Многие из этих классов были определены ранее, смотри [6, 13, 16, 12, 5].


2. Имена, зарезервированные слова и представления RPSL



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

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

Многие объекты в RPSL имеют имя. <object-name> составляется из букв, чисел, а также символов подчеркивания ("_") и дефисов ("-"), первым символов всегда должна быть буква, а последним символом - буква или цифра. Следующие слова зарезервированы в RPSL, и не могут использоваться в качестве имен:

any as-any rs-any peeras

and or not



atomic from to at action accept announce except refine

networks into inbound outbound

Имена, начинающиеся с определенных префиксов зарезервированы для определенных типов объектов. Имена, начинающиеся с "as-" зарезервированы для имен автономных систем. Имена, начинающиеся с "rs-" зарезервированы для набора имен маршрутов. Имена, начинающиеся с "rtrs-" зарезервированы для набора имен маршрутизаторов. Имена, начинающиеся с "fltr-" зарезервированы для набора имен фильтров. Имена, начинающиеся с "prng-" зарезервированы для набора имен партнеров.



<as-number>

Номер AS x представляется в виде строки "ASx". То есть автономная система 226 характеризуется с помощью AS226.

<ipv4-address>

Адрес IPv4 характеризуется последовательностью из четырех целых чисел, лежащих в диапазоне от 0 до 255, разделенные символом точка ".". Например, 192.148.166.48.

<address-prefix>

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

192.224.128.5/32, 192.148.0.0/16, 0.0.0.0/0. Следующие адресные префиксы являются неверными: 0/0, 192.10/16, так как 0 или 192.10 не являются строками, содержащими четыре целые числа.



<address-prefix-range>

Диапазоном адресных префиксов является адресный префикс, за которым следует опционный оператор диапазона. Операторами диапазона являются:


^-

оператор значений “больше, исключая”. Он служит для выделения адресных префиксов больше указанного, но исключая пограничное значение префикса. Например, 128.9.0.0/16^- содержит все префиксы больше 128.9.0.0/16, исключая значение 128.9.0.0/16.


^+

оператор значений “больше, включая”. Он служит для выделения адресных префиксов больше указанного, включая пограничное значение префикса. Например, 5.0.0.0/8^+ содержит все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8.


^n

где n целое, выделяет из адресного префикса все значения с длиной n. Например, 30.0.0.0/8^16 содержит все префиксы более 30.0.0.0/8, которые имеют длину 16, такие как 30.9.0.0/16.
^n-m где n и m целые числа, выделяет из адресного префикса все значения с длинами в интервале от n до m. Например, 30.0.0.0/8^24-32 содержит все значения из префикса 30.0.0.0/8, которые имеют длины в интервале 24-32, такие как 30.9.9.96/28.
Операторы диапазона могут применяться для наборов адресных префиксов. Например, для набора маршрутов rs-foo, rs-foo^+ (определенный ниже) содержит все специфические данные о префиксах в rs-foo.

Применение двух операторов диапазона последовательно является ошибкой (напр. 30.0.0.0/8^24-28^+ - ошибка). Однако оператор диапазона может быть применен к набору адресных префиксов, содержащий диапазоны адресных префиксов (напр. {30.0.0.0/8^24-28}^27-30 не является ошибкой). В этом случае, внешний оператор ^n-m располагается над внутренним оператором ^k-l и становится оператором ^max(n,k)-m, если m больше или равно max(n,k), в противном случае префикс удаляется из набора. Заметим, что оператор ^n эквивалентен ^n-n. Префикс/l^+ эквивалентен префиксу prefix/l^l-32. Префикс/l^- эквивалентен префиксу prefix/l^(l+1)-32. Префикс {prefix/l^n-m}^+ эквивалентен префиксу {prefix/l^n-32}, а префикс {prefix/l^n-m}^- эквивалентен префиксу {prefix/l^(n+1)-32}. Например,

{128.9.0.0/16^+}^- == {128.9.0.0/16^-}
{128.9.0.0/16^-}^+ == {128.9.0.0/16^-}
{128.9.0.0/16^17}^24 == {128.9.0.0/16^24}
{128.9.0.0/16^20-24}^26-28 == {128.9.0.0/16^26-28}
{128.9.0.0/16^20-24}^22-28 == {128.9.0.0/16^22-28}
{128.9.0.0/16^20-24}^18-28 == {128.9.0.0/16^20-28}
{128.9.0.0/16^20-24}^18-22 == {128.9.0.0/16^20-22}
{128.9.0.0/16^20-24}^18-19 == {}
<


/p> /TR>


<date>

Дата представляется в виде восьми десятичных цифр вида YYYYMMDD, где YYYY отображает год, MM представляет месяц (01 - 12) и DD характеризует день месяца (01 - 31). Все даты, если не определено что-то иное, задаются в стандарте UTC. Например, 07 июля 1938 представляется в виде 19380707.


<email-address>

описано в RFC-822 [10].


<dns-name>

описано в RFC-1034 [17].


<nic-handle>

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


<free-form>

представляет собой последовательность ASCII-символов.


<X-name>

является именем объекта типа X. То есть <mntner-name> является именем объекта mntner.


<registry-name>

является именем регистратора IRR.
Значением атрибута может быть также список одного из этих типов. Элементы списка отделяются друг от друга запятыми. Например, "AS1, AS2, AS3, AS4". Заметим, что значение-список ортогонально многозначности. Многозначный атрибут имеет более одного значения, каждое из которых может быть, а может и не быть списком. С другой стороны однозначный атрибут может иметь значение-список. Объект RPSL текстуально представляется в виде списка пар атрибут-значение. Каждая пара атрибут-значение записывается на отдельной строке. Имя атрибута начинается с колонки 0 и завершается двоеточием. Далее следует значение атрибута. Атрибут, который имеет то же имя, что и класс объекта должен быть специфицирован раньше. Представление объекта завершается пустой строкой. Значение атрибута может занимать несколько строк, для этого очередная строка должна начинаться с символа пробел, табулятор или знак плюс ('+'). Символ "+" для строки продолжения позволяет значениям атрибута содержать пустые строки. Порядок размещения пар атрибут-значение является существенным.



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

Целые числа могут задаваться:

  • в нотации языка программирования C (напр. 1, 12345),


  • в виде последовательности четырех одно-октетных целых чисел (в диапазоне 0-255), разделенных символом точка "." (например, 1.1.1.0, 255.255.0.0), в этом случае 4-октетное целое образуется объединением этих однооктетных целых чисел, начиная с наиболее значимых,


  • в виде двух 2-октетных целых чисел (в диапазоне 0 - 65535), разделенных символом двоеточие ":" (например, 3561:70, 3582:10), в этом случае 4-октетное целое число образуется путем объединения всех октетов в порядке их значимости.




  • 3. Контактная информация



    Классы mntner, person и role, а также атрибуты admin-c, tech-c, mnt-by, changed и всех классов характеризуют контактную информацию. Класс mntner специфицирует также аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать другие объекты. Эти классы не специфицируют маршрутную политику и каждый реестр может иметь различные или дополнительные требования. В документе "Routing Policy System Security" [20] описана модель аутентификации и авторизации.



    3.1. Класс mntner



    Класс mntner специфицирует аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать объекты RPSL. Провайдер прежде чем создавать RPSL-объект, должен создать объект mntner. Атрибуты класса mntner показаны на рис. .1. Класс mntner описан в [13].

    Атрибут mntner является обязательным и выполняет функцию ключа класса. Его значение – имя RPSL. Атрибут auth специфицирует схему, которая будет использоваться для идентификации и аутентификации запросов актуализации. Атрибут имеет следующий синтаксис:

    auth: <scheme-id> <auth-info>

    Например, auth: NONE

    Атрибут Значение Тип
    Mntner <object-name> обязательный, однозначный, ключ класса
    Descry <free-form> обязательный, однозначный
    Auth Смотри описание в тексте обязательный, многозначный
    upd-to <email-address> обязательный, многозначный
    mnt-nfy <email-address> опционный, многозначный
    tech-c <nic-handle> обязательный, многозначный
    admin-c <nic-handle> опционный, многозначный
    remarks <free-form> опционный, многозначный
    notify <email-address> опционный, многозначный
    mnt-by список <mntner-name> обязательный, многозначный
    changed <email-address> <date> обязательный, многозначный
    source <registry-name> обязательный, однозначный
    <


    /p> Рис. .1. Атрибуты класса mntner

    auth: CRYPT-PW dhjsdfhruewf

    auth: MAIL-FROM .*@ripe\.net

    В настоящее время для <scheme-id> определены значения: NONE, MAIL-FROM, PGP-KEY и CRYPT-PW. <auth-info> представляет дополнительную информацию, необходимую для конкретной схемы: в случае MAIL-FROM, это регулярное выражение, соответствующее корректному электронному почтовому адресу. В случае CRYPT-PW, это пароль в крипто-формате UNIX. В случае PGP-KEY, это указатель на объект key-certif [22], содержащий открытый ключ PGP-пользователя. Если специфицировано несколько атрибутов auth, запрос эксплуатационный актуализации, удовлетворяющий любому из них, будет аутентифицирован.

    Атрибут upd-to представляет собой электронный почтовый адрес. При неавторизованной попытке актуализации объекта, по этому адресу будет послано сообщение. Атрибут mnt-nfy также представляет собой почтовый адрес. При добавлении, изменении или удалении объекта по этому адресу посылается уведомляющее сообщение.

    Атрибут descr является коротким текстовым описанием объекта, выполненным в произвольной форме. Атрибут tech-c представляет собой контактный дескриптор NIC. Он используется при возникновении технических проблем, например, при неверной конфигурации. Атрибут admin-c представляет собой административный контактный дескриптор NIC. Атрибут remarks представляет собой текстовый комментарий или разъяснение. Атрибут notify представляет собой электронный адрес, куда следует отправлять уведомление об изменении этого объекта. Атрибут mnt-by является списком имен объектов mntner. Атрибут changed определяет, кто последний раз изменял данный объект, и когда это изменение было произведено. Его синтаксис имеет следующий формат:

    changed:

    Например

    changed: johndoe@terabit-labs.nn 19900401

    <email-address> идентифицирует человека, который внес последние изменения. <YYYYMMDD> представляет собой дату изменения. Атрибут source специфицирует реестр, где объект зарегистрирован. На рис. .2 показан пример объекта mntner. В этом примере использован криптографический формат UNIX для паролей аутентификации.

    mntner: RIPE-NCC-MNT
    descr: RIPE-NCC Maintainer
    admin-c: DK58
    tech-c: OPS4-RIPE
    upd-to: ops@ripe.net
    mnt-nfy: ops-fyi@ripe.net
    auth: CRYPT-PW lz1A7/JnfkTtI
    mnt-by: RIPE-NCC-MNT
    changed: ripe-dbm@ripe.net 19970820
    source: RIPE
    <


    /p> Рис. 2. Пример объекта mntner.

    Атрибуты descr, tech-c, admin-c, remarks, notify, mnt-by, changed и source являются атрибутами всех классов RPSL. Их синтаксис, семантика, а также статус mandatory (обязательный), optional (опционный), multi-valued (многозначный), или однозначный те же что и для всех классов RPSL. Единственным исключением является атрибут admin-c, который является обязательным для класса aut-num.



    3.2. Класс person



    Класс person используется для описания информации о людях. Хотя он не описывает маршрутную политику, его описание здесь приводится, так как многие объекты политики делают ссылки на конкретных людей. Класс person был впервые описан в [15].

    Атрибуты класса person представлены на рис. .3 Атрибут person представляет собой полное имя человека. Атрибуты phone и fax-no имеют следующий синтаксис:

    phone: +<country-code> <city> <subscriber> [ext. <extension>]

    Например:

    phone: +31 20 12334676

    Атрибут Значение Тип
    Person <free-form> обязательный, однозначный
    nic-hdl <nic-handle> обязательный, однозначный, ключ класса
    address <free-form> обязательный, многозначный
    phone См. описание в тексте обязательный, многозначный
    fax-no То же что и phone опционный, многозначный
    e-mail <email-address> обязательный, многозначный
    Рис. .3: Атрибуты класса person

    phone: +44 123 987654 ext. 4711

    На рис. .4 приведен пример объекта person.

    person: Daniel Karrenberg
    address: RIPE Network Coordination Centre (NCC)
    address: Singel 258
    address: NL-1016 AB Amsterdam
    address: Netherlands
    phone: +31 20 535 4444
    fax-no: +31 20 535 4445
    e-mail: Daniel.Karrenberg@ripe.net
    nic-hdl: DK58
    changed: Daniel.Karrenberg@ripe.net 19970616
    source: RIPE
    Рис. .4. Пример объекта person.



    3.3. Класс role



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



    Атрибуты класса role показаны на рис. .5. Атрибуты лиц nic-hdl и классы role используют совместно одно и то же пространство имен. Атрибут trouble объекта role может содержать дополнительную контактную информацию, которая может быть использована при возникновении проблемы в любом объекте, который ссылается на данный объект role. На рис. .6 показан пример объекта role.

    Атрибут

    Значение

    Тип

    Role

    <free-form>

    обязательный, однозначный

    nic-hdl

    <nic-handle>

    обязательный, однозначный, ключ класса

    trouble

    <free-form>

    опционный, многозначный

    address

    <free-form>

    обязательный, многозначный

    phone

    see description in text

    обязательный, многозначный

    fax-no

    same as phone

    опционный, многозначный

    e-mail

    <email-address>

    обязательный, многозначный

    Рис. .5. Атрибуты класса role

    role: RIPE NCC Operations
    trouble:

    address: Singel 258
    address: 1016 AB Amsterdam
    address: The Netherlands
    phone: +31 20 535 4444
    fax-no: +31 20 545 4445
    e-mail: ops@ripe.net
    admin-c: CO19-RIPE
    tech-c: RW488-RIPE
    tech-c: JLSD1-RIPE
    nic-hdl: OPS4-RIPE
    notify: ops@ripe.net
    changed: roderik@ripe.net 19970926
    source: RIPE
    Рис. .6. Пример объекта role.



    4. Класс route



    Каждый маршрут interAS (называемый также междоменным маршрутом), начинающийся в AS, специфицируется с помощью объекта route. Атрибуты класса route представлены на рис. .7. Атрибут route представляет собой адресный префикс маршрута, а атрибут origin является номером AS, где этот маршрут начинается. Пара атрибутов route и origin являются ключом класса.

    На рис. .8 представлены примеры четырех объектов route. Заметим, что последние два объекта route имеют один и тот же адресный префикс 128.8.0.0/16. Однако они являются различными объектами route, так как они начинаются в разных AS (то есть они имеют разные ключи).



    Атрибут



    Значение



    Тип

    Route <address-prefix> обязательный, однозначный, ключ класса
    Origin <as-number> обязательный, однозначный, ключ класса
    member-of список <route-set-names>

    см. раздел 5
    опционный, многозначный
    Inject см. раздел 8 опционный, многозначный
    Components см. раздел 8 опционный, однозначный
    aggr-bndry см. раздел 8 опционный, однозначный
    aggr-mtd см. раздел 8 опционный, однозначный
    export-comps см. раздел 8 опционный, однозначный
    holes см. раздел 8 опционный, многозначный
    <


    /p> Рис. 7: Атрибуты класса route

    route: 128.9.0.0/16
    origin: AS226
    route: 128.99.0.0/16
    origin: AS226
    route: 128.8.0.0/16
    origin: AS1
    route: 128.8.0.0/16
    origin: AS2
    Рис. .8. Объекты Route



    5. Классы Set



    При спецификации политики часто полезно определить наборы объектов. Для этих целей определены классы as-set, route-set, rtr-set, filter-set, and peering-set. Эти классы определяют именованный набор. Члены этих наборов могут быть специфицированы непосредственно путем перечисления их в определении набора, или косвенно, имея ссылки членов-объектов на имена наборов. Допускается применение обоих методов.

    Имя набора является словом rpsl со следующими ограничениями. Все имена as-set начинаются с префикса "as-". Все имена route-set начинаются с префикса "rs-". Все наборы имен rtr-set начинаются с префикса "rtrs-". Все имена filter-set начинаются с префикса "fltr-". Все имена peering-set начинаются с префикса "prng-". Например, as-foo является корректным именем as-set.

    Имена наборов могут быть иерархическими. Имя иерархического набора представляет собой последовательность имен наборов и номеров AS, разделенных символом двоеточие ":". По крайней мере, одна компонента такого имени должна быть действительным именем набора (то есть начинается с одного из префиксов). Все компоненты имени набора иерархического имени должны иметь один и тот же тип. Например, следующие имена корректны: AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2, RS-EXCEPTIONS:RS-BOGUS.

    Целью имени иерархического набора является выделение определенного пространства имен, так что администратор набора X1 управляет всем набором нижележащих имен, то есть X1:...:Xn-1. Таким образом, набор объектов с именем X1:...:Xn-1:Xn может быть создан администратором объекта с именем X1:...:Xn-1. То есть, только администратор AS1 может создать набор с именем AS1:AS-FOO. Только администратор AS1:AS-FOO может создать набор с именем AS1:AS-FOO:AS-BAR.





    5.1. Класс as-set



    Атрибуты класса as-set показан на рис. .9. Атрибут as- set определяет имя набора. Он является именем RPSL, которое начинается с "as-". Атрибут members перечисляет членов набора. Атрибут members является списком AS, или других имен as-set.



    Атрибут



    Значение



    Тип

    as-set <object-name> обязательный, однозначный, ключ класса
    members список <as-numbers> или опционный, многозначный
    Mbrs-by-ref список <mntner-names> опционный, многозначный
    Рис. .9. Атрибуты класса as-set

    На рис. .10 представлены два объекта as-set. Набор as-foo содержит две AS, в частности AS1 и AS2. Набор as-bar содержит членов набора as-foo и AS3, т.е. он содержит AS1, AS2, AS3. Набор as-empty не содержит членов.

    as-set: as-foo as-set: as-bar as-set: as-empty
    members: AS1, AS2 members: AS3, as-foo  
    Рис. .10. Объекты as-set.

    Атрибут mbrs-by-ref представляет собой список имен администраторов (maintainer) или ключевое слово ANY. Если используется этот атрибут, набор AS включает также автономные системы, чьи объекты aut-num зарегистрированы одним из этих администраторов и чей атрибут member-of относится к имени этого набора AS. Если значение атрибута mbrs-by-ref равно ANY, любой объект AS, относящийся к набору, является членом этого набора. Если атрибут mbrs-by-ref пропущен, только AS, перечисленные в атрибуте members, являются членами набора.

    as-set: as-foo

    members: AS1, AS2

    mbrs-by-ref: MNTR-ME

    Aut-num: AS3

    Aut-num: AS4

    member-of: as-foo

    member-of: as-foo

    mnt-by: MNTR-ME

    mnt-by: MNTR-OTHER

    Рис. .11. Объекты as-set.

    На рис. .11 представлен пример объекта as-set, который использует атрибут mbrs-by-ref. Набор set as-foo

    содержит AS1, AS2 и AS3. AS4 не является членом набора as-foo не смотря на то, что объект aut-num ссылается на as-foo. Это происходит потому, что MNTR-OTHER отсутствует в списке атрибута as-foo mbrs-by-ref.



    5.2. Класс route-set



    Атрибуты класса route-set показаны на рис. .12. Атрибут route-set определяет имя набора. Он является именем RPSL, которое начинается с "rs-". Атрибут members перечисляет членов набора. Атрибут members представляет собой список адресных префиксов или других имен route-set. Заметим, что, класс route-set является набором префиксов маршрутов, а не маршрутных объектов RPSL.



    Атрибут



    Значение



    Тип

    route-set <object-name> обязательный, однозначный, ключ класса
    members список <address-prefix-range> или <route-set-name> или <route-set-name><range-operator> опционный, многозначный
    Mbrs-by-ref список <mntner-names> опционный, многозначный
    <


    /p> Рис. .12. Атрибуты класса route-set

    На рис. . 13 приведены некоторые примеры объектов route-set. Набор rs-foo содержит два адресных префикса, в частности 128.9.0.0/16 и 128.9.0.0/24. Набор rs-bar содержит члены набора rs-foo и адресный префикс 128.7.0.0/16.

    За адресным префиксом или именем route-set в атрибуте members может опционно следовать оператор диапазона. Например, следующий набор:

    route-set: rs-foo

    members: 128.9.0.0/16, 128.9.0.0/24

    route-set: rs-bar

    members: 128.7.0.0/16, rs-foo

    Рис. .13. Объекты route-set

    route-set: rs-bar

    members: 5.0.0.0/8^+, 30.0.0.0/8^24-32, rs-foo^+

    содержат все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8, все префиксы больше 30.0.0.0/8, чья длина лежит в пределах 24 – 32, такие как 30.9.9.96/28, и все префиксы больше префиксов из маршрутного набора rs-foo.

    Атрибут mbrs-by-ref представляет собой список имен администраторов и может содержать ключевое слово ANY. Если используется этот атрибут, маршрутный набор включает также префиксы, чьи маршрутные объекты зарегистрированы одним из администраторов, и чей атрибут member-of указывает на имя этого маршрутного набора. Если значение атрибута mbrs-by-ref равно ANY, любой объект, связанный с именем маршрутного набора, является его членом. Если атрибут mbrs-by-ref отсутствует, только адресные префиксы, перечисленные в атрибуте members, являются членами этого набора.

    route-set: rs-foo

    mbrs-by-ref: MNTR-ME, MNTR-YOU

    route-set: rs-bar

    members: 128.7.0.0/16

    mbrs-by-ref: MNTR-YOU

    route: 128.9.0.0/16

    origin: AS1

    member-of: rs-foo

    mnt-by: MNTR-ME

    route: 128.8.0.0/16

    origin: AS2

    member-of: rs-foo, rs-bar

    mnt-by: MNTR-YOU

    Рис. .14. Объекты route-set.

    На рис. 14 представлен пример объектов route-set, которые используют атрибут mbrs-by-ref. Набор rs-foo содержит два адресных префикса, в частности 128.8.0.0/16 и 128.9.0.0/16, так как маршрутные объекты для 128.8.0.0/16 и 128.9.0.0/16 отнесены к набору имен rs-foo в их атрибуте member-of. Набор rs-bar содержит адресные префиксы 128.7.0.0/16 и 128.8.0.0/16. Маршрут 128.7.0.0/16 представлен явно в атрибуте members rs-bar, а маршрутный объект для 128.8.0.0/16 связан с именем набора rs-bar в атрибуте member-of. Заметим, что если адресный префикс представлен в атрибуте маршрутного набора members, он является членом этого маршрутного набора. Маршрутный объект, соответствующий этому адресному префиксу не должен содержать атрибут member-of, относящийся к имени этого набора. Атрибут маршрутного класса member-of является дополнительным механизмом для косвенной спецификации членов набора.





    5.3. Объекты предопределенных наборов



    В этом контексте, который предполагает набор маршрутов (например, атрибут members класса route-set), номер автономной системы ASx определяет набор маршрутов, который исходит из Asx, а as-set AS-X определяет набор маршрутов, которые исходят из автономной системы AS-X. Маршрут p считается начинающимся в ASx, если существует маршрутный объект для p с ASx в качестве значения атрибута origin. Например, на рис. .15, набор маршрутов rs-special содержит маршруты 128.9.0.0/16, AS1 и AS2, а также маршруты автономных систем набора AS-FOO.

    route-set: rs-special

    members: 128.9.0.0/16, AS1, AS2, AS-FOO

    Рис. .15. Использование номеров AS и маршрутных наборов.

    Набор rs-any содержит все маршруты, зарегистрированные в IRR. Набор as-any содержит все AS, зарегистрированные в IRR.



    5.4. Класс Filters и filter-set



    Атрибуты класса filter-set представлены на рис. 16. Объект filter-set определяет набор маршрутов, которые соответствуют этому фильтру. Атрибут filter-set определяет имя фильтра. Он является именем RPSL, которое начинается с "fltr-".

    Атрибут

    Значение

    Тип

    filter-set

    <object-name>

    обязательный, однозначный, ключ класса

    filter

    <filter>

    обязательный, однозначный

    Рис. .16. Атрибуты класса filter

    filter-set: fltr-foo

    filter: { 5.0.0.0/8, 6.0.0.0/8 }

    filter-set: fltr-bar

    filter: (AS1 or fltr-foo) and

    Рис. .17. Объекты filter-set.

    Атрибут filter определяет фильтр политики для данного набора. Фильтр политики является логическим выражением, которое в случае приложения к набору маршрутов в качестве результата возвращает субнабор этих маршрутов. Считается, что фильтр политики соответствует возвращенному субнабору. Фильтр политики может соответствовать маршрутам, использующим любой атрибут BGP-прохода, такой как адресный префикс места назначения (или NLRI), AS-path, или атрибуты community.

    Фильтры политики могут составляться путем использования операторов AND, OR и NOT. Ниже представленные фильтры политики могут использоваться для селекции субнабора маршрутов:



    ANY

    Ключевое слово ANY соответствует всем маршрутам.


    Address-Prefix Set

    Это список адресных префиксов, заключенных в фигурные скобки '{' и '}'. Фильтр политики соответствует набору маршрутов, чей адресный префикс места назначения содержится в этом наборе. Например:
    <


    /p> { 0.0.0.0/0 }

    { 128.9.0.0/16, 128.8.0.0/16, 128.7.128.0/17, 5.0.0.0/8 }

    { }

    За адресным префиксом может опционно следовать оператор диапазона (то есть

    { 5.0.0.0/8^+, 128.9.0.0/16^-, 30.0.0.0/8^16, 30.0.0.0/8^24-32 }

    содержит все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8, все префиксы больше 128.9.0.0/16, исключая 128.9.0.0/16, все префиксы больше 30.0.0.0/8, которые имеют длину 16, такие как 30.9.0.0/16, и все префиксы больше 30.0.0.0/8, которые имеют длину в диапазоне 24 – 32, такие как 30.9.9.96/28.



    Route Set Name

    Имя набора маршрутов соответствует набору маршрутов, которые являются членами набора. Имя набора маршрутов может быть именем объекта route-set, номером AS или именем объекта as-set (номера AS и имена as-set неявно определяют маршрутные наборы). Например:
    aut-num: AS1

    import: from AS2 accept AS2

    import: from AS2 accept AS-FOO

    import: from AS2 accept RS-FOO

    Ключевое слово PeerAS может использоваться вместо номера AS партнера. PeerAS является особенно полезным, когда партнерство охарактеризовано с помощью AS-выражения. Например:

    as-set: AS-FOO

    members: AS2, AS3

    aut-num: AS1

    import: from AS-FOO accept PeerAS

    то же самое, что и:

    aut-num: AS1

    import: from AS2 accept AS2

    import: from AS3 accept AS3

    За именем набора маршрутов может также следовать один из операторов '^-', '^+', например, { 5.0.0.0/8, 6.0.0.0/8 }^+ эквивалентно { 5.0.0.0/8^+, 6.0.0.0/8^+ } и AS1^- эквивалентно всем адресным префиксам, соответствующим маршрутам, исходящим из AS1.



    Регулярные выражения для проходов AS

    .

    Регулярное выражение AS-path может использоваться в качестве фильтра политики путем заключения его в угловые скобки `'. Фильтр политики AS-path соответствует набору маршрутов, который проходит через последовательность AS, которая согласуется с регулярным выражением AS-path. Маршрутизатор может проверить это, используя атрибут AS_PATH в протоколе BGP [19], или атрибут RD_PATH в протоколе IDRP [18].

    Регулярное выражение формируется следующим образом:



    ASN

    где ASN является номером AS. ASN соответствует AS-path, который имеет длину равную 1 и содержит корректный номер AS (например, регулярное выражение AS-path AS1 соответствует AS-path "1"). Вместо номера AS-партнера может использоваться ключевое слово PeerAS.


    AS-set

    где AS-set является именем набора AS. AS-set соответствует AS-проходам, которые согласуются с одним из AS в AS-set.


    .

    соответствует AS-path, который согласуется с любым номером AS.


    [...]

    является набором номеров AS. Это выражение соответствует AS-path, согласующимся со списком номеров AS, записанных в скобках. Номера AS в наборе отделяются друг от друга пробелом или символом TAB (white space). Если между двумя номерами AS использован символ `-', в набор включаются все AS из этого диапазона. Если в список включено имя as-set, в набор войдут все номера AS as-set.


    [^...]

    является дополнением набора AS. Это выражение соответствует любому AS-path, который не соответствует набору номеров AS из приведенного набора.


    ^

    Соответствует пустой строке в начале AS-path.


    $

    Соответствует пустой строке в конце AS-path.
    <


    /p> Далее описываются операторы регулярных выражений. Эти операторы выполняются слева направо.



    Унарные постфиксные операторы * + ? {m} {m,n} {m,}



    Для регулярных выражений A, запись A* соответствует нулю или более использований A. A+ соответствует одному или более использованию A. A? соответствует нулю или одному использованию A. A{m} соответствует m использованиям A. A{m,n} соответствует от m до n использованиям A/, A{m,} соответствует m или более использованиям A. Например, [AS1 AS2]{2} соответствует AS1 AS1, AS1 AS2, AS2 AS1 и AS2 AS2.



    Унарные постфиксные операторы ~* ~+ ~{m} ~{m,n} ~{m,}



    Эти операторы имеют аналогичную функциональность, что и соответствующие операторы, перечисленные выше, но все включения регулярного выражения должны соответствовать одному образцу. Например, [AS1 AS2]~{2} соответствует AS1 AS1 и AS2 AS2, но не соответствует AS1 AS2 и AS2 AS1.



    Двоичный оператор объединения

    .

    Это неявный оператор, он вставляется между двумя регулярными выражениями A и B, когда не специфицирован другой оператор. Полученное выражение A B соответствует AS-path, если A соответствует некоторому префиксу AS-path, а B соответствует остальной части AS-path.



    Двоичный альтернативный оператор |



    Для регулярных выражений A и B, A | B соответствует любому AS-path, который соответствует A или B.

    Для изменения порядка действий, предусмотренного по умолчанию, можно использовать скобки. Для улучшения читаемости могут использоваться WS (пробел или символ TAB). Ниже приведены примеры фильтров AS-path:

    <^AS1>

    <^AS1 AS2 AS3$>

    <^AS1 .* AS2$>.

    Первый пример соответствует любому маршруту, чей AS-path содержит AS3, второй соответствует маршрутам, чьи AS-path начинаются с AS1, третий соответствует маршрутам, чьи AS-path заканчиваются AS2, четвертый соответствует маршрутам, чьи AS-path в точности равны "1 2 3", а пятый соответствует маршрутам, чьи AS-path начинаются в AS1 и заканчиваются в AS2 с любым числом промежуточных AS между ними.



    Составные фильтры политики

    .



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

    NOT Дан фильтр политики x, NOT x соответствует набору маршрутов, которые не соответствуют x. Таким образом он представляет отрицание фильтра политики x.
    AND Даны два фильтра политики x и y, x AND y соответствует пересечению множеств маршрутов, которые соответствуют как фильтру x так и фильтру y.
    OR Даны два фильтра политики x и y, x OR y соответствует объединению множеств маршрутов, которые соответствуют фильтру x или фильтру y. Заметим, что оператор OR может быть неявным, то есть `x y' эквивалентно `x OR y'. Например
    NOT {128.9.0.0/16, 128.8.0.0/16}

    AS226 AS227 OR AS228

    AS226 AND NOT {128.9.0.0/16}

    AS226 AND {0.0.0.0/0^0-18}

    Первый пример соответствует любому маршруту кроме 128.9.0.0/16 и 128.8.0.0/16. Второй пример соответствует маршрутам AS226, AS227 и AS228. Третий пример соответствует маршрутам AS226, исключая 128.9.0.0/16. Четвертый пример соответствует маршрутам AS226, чья длина не больше 18.

    Атрибуты фильтров политики могут использоваться для сравнения значения других атрибутов. Атрибуты, чьи значения могут применяться в фильтрах политики, специфицированы в словаре RPSL. Пример использования атрибута BGP community приведен ниже:

    aut-num: AS1

    export: to AS2 announce AS1 AND NOT community(NO_EXPORT)

    Фильтры, использующие атрибуты маршрутной политики, определенные в словаре, вычисляются до выполнения операторов AND, OR и NOT.



    Имя набора фильтров.

    Имя набора фильтров отвечает набору маршрутов, которые соответствуют их атрибуту фильтра. Заметим, что атрибут фильтра набора может рекурсивно связан с другими именами наборов фильтров. Например на рис. .17, fltr-foo соответствует {5.0.0.0/8, 6.0.0.0/8} и fltr-bar соответствует маршрутам AS1 или { 5.0.0.0/8, 6.0.0.0/8 }, если их путь содержит AS2.


    5.5. Класс rtr-set



    Атрибуты класса rtr-set представлены на рис. .18. Атрибут rtr-set определяет имя набора. Он является словом RPSL, которое начинается с "rtrs-". Атрибут members перечисляет членов набора. Атрибут members представляет собой список имен inet-rtr, ipv4_addresses или других имен rtr-set.



    Атрибут



    Значение



    Тип

    rtr-set <object-name> обязательный, однозначный, ключ класса
    members список <inet-rtr-names> или <rtr-set-names> или <ipv4_addresses> опционный, многозначный
    mbrsbyref список <mntnernames> опционный, многозначный
    <


    /p> Рис. .18. Атрибуты класса rtr-set

    На рис. .19 представлены два объекта rtr-set. Набор rtrs-foo содержит два маршрутизатора, в частности rtr1.isp.net и rtr2.isp.net. Набор rtrs-bar содержит членов набора rtrs-foo и rtr3.isp.net, то есть он содержит rtr1.isp.net, rtr2.isp.net, rtr3.isp.net.

    rtr-set: rtrs-foo rtr-set: rtrs-bar
    members: rtr1.isp.net, rtr2.isp.net members: rtr3.isp.net, rtrs-foo
    Рис. .19. Объекты rtr-set.

    Атрибут mbrs-by- ref содержит список имен администраторов (maintainer) или ключевое слово ANY. Если использован этот атрибут, набор маршрутизаторов включает также маршрутизаторы, чьи объекты inet-rtr зарегистрированы одним из этих администраторов и чей атрибут member-of согласуется с именем этого набора маршрутизаторов. Если значение атрибута mbrs-by-ref равно ANY, любой объект inet-rtr соотносящийся набору маршрутизаторов, является членом этого набора. Если атрибут mbrs-by-ref отсутствует, только маршрутизаторы перечисленные в атрибуте members, являются членами набора.

    rtr-set: rtrs-foo

    members: rtr1.isp.net, rtr2.isp.net

    mbrs-by-ref: MNTR-ME

    inet-rtr: rtr3.isp.net

    local-as: as1

    ifaddr: 1.1.1.1 masklen 30

    member-of: rtrs-foo

    mnt-by: MNTR-ME

    Рис. .20. Объекты rtr-set.

    На рис. 20 представлен пример объекта rtr-set, который использует атрибут mbrs-by-ref. Набор rtrs-foo содержит rtr1.isp.net, rtr2.isp.net и rtr3.isp.net.



    5.6. Партнерство и класс peering-set



    Атрибуты класса peering-set представлены на рис. .21. Объект peering-set определяет набор партнеров, который перечислен в его партнерских атрибутах (peering). Атрибут peering-set определяет имя набора. Он является именем RPSL, которое начинается с "prng-".

    Атрибут

    Значение

    Тип

    peering-set

    <object-name>

    обязательный, однозначный, ключ класса

    peering

    <peering>

    обязательный, многозначный

    Рис. .21. Атрибуты класса filter

    Атрибут peering определяет партнеров, которые могут быть использованы для импорта или экспорта маршрутных данных.



    Рис. .22. Пример топологии, состоящий из трех AS: AS1, AS2 и AS3, двух точек обмена: EX1 и EX2 и шести маршрутизаторов (IP[R1]= 1.1.1.1, IP[R2]= 2.2.2.1, IP[R3]= 1.1.1.2, IP[R4]= 1.1.1.3, IP[R5]= 2.2.2.2, IP[R6]= 2.2.2.3).



    При описании партнерства используется топология, показанная на рис. .22. В этой топологии имеется три автономные системы, AS1, AS2, and AS3; две точки обмена, EX1 и EX2, и шесть маршрутизаторов (R1-R6). Маршрутизаторы соединены с точками обмена. То есть, 1.1.1.1, 1.1.1.2 и 1.1.1.3 являются партнерами друг для друга, а 2.2.2.1, 2.2.2.2 и 2.2.2.3 – также партнеры друг для друга.

    Синтаксис спецификации партнерства:

    <as-expression> [<router-expression-1>] [at <router-expression-2>] | <peering-set-name>

    где <as-expression> является выражением для номеров AS и наборов AS, использующих операторы AND, OR и EXCEPT, а выражения <router-expression-1> и <router-expression-2> являются функциями IP-адресов маршрутизаторов, имен inet-rtr, и имен rtr-set, использующих операторы AND, OR и EXCEPT. Двоичный оператор "EXCEPT" семантически эквивалентен комбинации "AND NOT". То есть "(AS1 OR AS2) EXCEPT AS2" эквивалентно "AS1".

    Эта форма идентифицирует всех партнеров между любым локальным маршрутизатором в <router-expression-2> и любыми маршрутизаторами в <router-expression-1> в автономных системах из <as-expression>. Если <router-expression-2> не специфицировано, это по умолчанию предполагает, что все маршрутизаторы локальной AS связаны с AS из <as-expression>.

    Если используется <peering-set-name>, партеры перечислены в соответствующем объекте peering-set. Заметим, что объекты peering-set могут быть рекурсивными.

    Возможны также многие специальные формы этой общей спецификации партнеров. Ниже приведенные примеры иллюстрируют наиболее общие случаи с использованием атрибута import класса aut-num. В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2.

    (1) aut-num: AS1

    import: from AS2 1.1.1.2 at 1.1.1.1 accept { 128.9.0.0/16 }

    В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3.

    (2) aut-num: AS1

    import: from AS2 at 1.1.1.1 accept { 128.9.0.0/16 }



    В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3, а 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2.

    (3) aut-num: AS1

    import: from AS2 accept { 128.9.0.0/16 }

    В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3.

    (4) as-set: AS-FOO

    members: AS2, AS3

    aut-num: AS1

    import: from ASFOO
    at 9.9.9.1 accept { 128.9.0.0/16 }

    В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3, а 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3.

    (5) aut-num: AS1

    import: from AS-FOO accept { 128.9.0.0/16 }
    В следующем примере AS1 импортирует 128.9.0.0/16 из AS3 через маршрутизатор 9.9.9.1

    (6) aut-num: AS1

    import: from AS-FOO and not AS2 at not 1.1.1.1 accept { 128.9.0.0/16 }

    Это связано с тем, что "AS-FOO and not AS2" эквивалентно AS3 и "not 1.1.1.1" эквивалентно 9.9.9.1.

    В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3.

    (7) peering-set: prng-bar peering: AS1 at 9.9.9.1

    peering-set: prng-foo

    peering: prng-bar

    peering: AS2 at 9.9.9.1

    aut-num: AS1

    import: from prng-foo accept { 128.9.0.0/16 }



    6. Класс aut-num



    Маршрутная политика специфицируется с использованием класса aut-num. Атрибуты класса aut-num представлены на рис. .23. Значение атрибута aut-num равно номеру AS, описанной данным объектом. Атрибут as-name является символическим именем (в рамках синтаксиса имен RPSL) AS. Импорт, экспорт и маршрутная политика по умолчанию AS специфицируются, используя атрибуты import, export и default, соответственно.



    Атрибут



    Значение



    Тип

    aut-num <as-number> обязательный, однозначный, ключ класса
    as-name <object-name> обязательный, однозначный
    member-of Список <as-set-names> опционный, многозначный
    import См. раздел 6.1 опционный, многозначный
    export См. раздел 6.2 опционный, многозначный
    default См. раздел 6.5 опционный, многозначный
    Рис. .23. Атрибуты класса aut-num



    6.1. Атрибут import: Спецификация политики импорта





    В RPSL политика импорта определяется двумя выражениями импортной политики. Каждое выражение импортной политики специфицируется с помощью атрибута import. Атрибут import имеет следующий синтаксис:

    import: from <peering-1> [action <action-1>] . . .
      from <peering-N> [action <action-N>]
      accept <filter>
    Спецификация действия является опционной. Семантика атрибута import выглядит следующим образом: набор маршрутов, который соответствует <filter> импортируется от всех партнеров в <peerings>, в то время как импортируемые маршруты <peering-M>, <>ction-M> реализуются.

    Например

    aut-num: AS1

    import: from AS2 action pref = 1; accept { 128.9.0.0/16 }

    Этот пример утверждает, что маршрут 128.9.0.0/16 воспринят от AS2 с предпочтением 1. Далее рассматривается спецификация действий (action).



    6.1.1. Спецификация действия (Action)



    Действия политики в RPSL устанавливают или модифицируют атрибуты маршрутов, таких как предпочтение маршрута, добавляет атрибут BGP community или устанавливает атрибут MULTI-EXIT-DISCRIMINATOR. Действия политики могут также инструктировать маршрутизаторы по выполнению специальных операций, таких как гашение осцилляций маршрутов.

    Атрибуты маршрутной политики, чьи значения могут быть модифицированы посредством действий политики, специфицированы в словаре RPSL. Каждое действие при записи в RPSL завершаются символом точка с запятой (';'). Имеется возможность формировать составные действия политики путем последовательного их перечисления. В этом случае действия выполняются в порядке слева направо. Например,

    aut-num: AS1

    import: from AS2 action pref = 10; med = 0; community.append(10250, 3561:10);

      accept { 128.9.0.0/16 }
    устанавливает pref = 0, med = 0, и затем добавляет 10250 и 3561:10 к атрибуту прохода community BGP. Атрибут pref является инверсным по отношению к атрибуту local-pref (т.e. local-pref == 65535 - pref). Маршрут с атрибутом local-pref всегда предпочтительнее, чем без него.



    aut-num: AS1

    import: from AS2 action pref = 1;
    from AS3 action pref = 2;
    accept AS4
    Выше приведенный пример утверждает, что маршруты AS4 получены от AS2 с предпочтением 1 и от AS3 с предпочтением 2 (маршруты с более низкими предпочтениями имеют больший приоритет, чем с большими значениями).

    aut-num: AS1

    import: from AS2 1.1.1.2 at 1.1.1.1 action pref = 1;
    from AS2 action pref = 2;
    accept AS4  
    Выше приведенный пример утверждает, что маршруты AS4 получены от AS2 для направления 1.1.1.1-1.1.1.2 с предпочтением 1, а для любого другого направления от AS2 с предпочтением 2.



    6.2. Атрибут export: Спецификация экспортной политики



    Аналогично выражение экспортной политики специфицируется с помощью атрибута export. Атрибут export имеет следующий синтаксис:

    export: to <peering-1> [action <action-1>]
    . . .
    to <peering-N> [action <action-N>]
    announce <filter>
    Спецификация действия является опционной. Семантика атрибута export выглядит следующим образом: набор маршрутов, который соответствует <filter> пересылается всем партнерам, специфицированным в <peerings>, в то время как экспортируемые маршруты из <peering-M>, <action-M> реализуются.

    Например

    aut-num: AS1

    export: to AS2 action med = 5; community .= { 70 }; announce AS4

    В этом примере, маршруты AS4 объявляются автономной системе AS2 со значением атрибута med, равным 5 и атрибута community = 70.

    Пример:

    aut-num: AS1

    export: to AS-FOO announce ANY

    В этом примере, AS1 объявляет все свои маршруты автономным системам AS из набора AS-FOO.



    6.3. Другие маршрутные протоколы, мультипротокольные маршрутные протоколы и обмен маршрутами между протоколами



    Более сложный синтаксис атрибутов import и export выглядит следующим образом:

    import: [protocol <protocol-1>] [into <protocol-2>]

    from <peering-1> [action <action-1>]

    . . .

    from <peering-N> [action <action-N>]

    accept <filter>



    export: [protocol <protocol-1>] [into <protocol-2>]

    to <peering-1> [action <action-1>]

    . . .

    to <peering-N> [action <action-N>]

    announce <filter>

    Этот синтаксис используется там, где при описании политики других протоколов маршрутизации могут использоваться спецификации опционных протоколов, или для введения маршрутов одного протокола в другой протокол, или для многопротокольной маршрутной политики. Корректные имена протоколов определены в словаре. <protocol-1> является именем протокола, чьими маршрутами производится обмен. <protocol-2> представляет собой имя протокола, который принимает данные об этих маршрутах. Как <protocol-1> так и <protocol-2> являются протоколами по умолчанию для IEGP (Internet Exterior Gateway Protocol), в настоящее время его функцию выполняет BGP. В последующем примере все маршруты interAS передаются протоколу RIP.

    aut-num: AS1

    import: from AS2 accept AS2

    export: protocol BGP4 into RIP to AS1 announce ANY

    В следующем примере, AS1 воспринимает маршруты AS2, включая любые адресные префиксы больше префиксов маршрутов AS2, но не передает эти дополнительные префиксы протоколу OSPF.

    aut-num: AS1

    import: from AS2 accept AS2^+

    export: protocol BGP4 into OSPF to AS1 announce AS2

    В следующем примере, AS1 передает свои статические маршруты (маршруты, которые являются членами набора AS1:RS-STATIC-ROUTES) маршрутному протоколу interAS и дважды добавляет AS1 к своему маршрутному набору AS.

    aut-num: AS1

    import:

    protocol STATIC into BGP4 from AS1 action aspath.prepend(AS1, AS1);

    accept AS1:RS-STATIC-ROUTES

    В следующем примере, AS1 воспринимает другой набор уникастных маршрутов для реверсивной мультикастной переадресации из AS2:

    aut-num: AS1

    import: from AS2 accept AS2

    import: protocol IDMR

    from AS2 accept AS2:RS-RPF-ROUTES



    6.4. Разрешение неопределенности



    Допускается, чтобы один и тот же обмен (peering) был описан в более чем одной спецификации партнерства в пределах выражения политики. Например:



    aut-num: AS1

    import:

    from AS2 1.1.1.2 at 1.1.1.1 action pref = 2;

    from AS2 1.1.1.2 at 1.1.1.1 action pref = 1;

    accept AS4

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

    Рассмотрим пример:

    aut-num: AS1

    import:

    from AS2 action pref = 2;

    from AS2 1.1.1.2 at 1.1.1.1 action pref = 1; dpa = 5;

    accept AS4

    где обе спецификации партнерства перекрывают маршруты 1.1.1.1-1.1.1.2, хотя вторая спецификация более специфична. Здесь также используется правило порядка спецификаций, выполняется только действие (action) "pref = 2". В действительности, вторая пара пиринговых действий бесполезна, так как первая пара пиринговых действий покрывает действие второй. Если требуется политика, при которой эти маршруты воспринимались данным пирингом с предпочтением 1 и с предпочтением 2 для всех остальных пирингов, пользователь должен специфицировать следующее:

    aut-num: AS1

    import:

    from AS2 1.1.1.2 at 1.1.1.1

    action pref = 1; dpa = 5;

    from AS2

    action pref = 2;

    accept AS4

      Допускается также, чтобы более чем одно выражение политики покрывало один и тот же набор маршрутов в рамках одного пиринга. Например:

    aut-num: AS1

    import: from AS2 action pref = 2; accept AS4

    import: from AS2 action pref = 1; accept AS4

    В этом случае, также используется правило порядка спецификаций. То есть маршруты AS4 от AS2 воспринимаются с предпочтением 2. Если фильтры перекрываются, но не тождественны:

    aut-num: AS1

    import: from AS2 action pref = 2; accept AS4

    import: from AS2 action pref = 1; accept AS4 OR AS5

    маршруты AS4 воспринимаются от AS2 с предпочтением 2 и, тем не менее, маршруты AS5 также воспринимаются, но с предпочтением 1.

    Ниже приведено общее правило порядка спецификации для разработчиков программ RPSL. Рассмотрим два расширения политики:



    aut-num: AS1

    import: from peerings-1 action action-1 accept filter-1

    import: from peerings-2 action action-2 accept filter-2

    Вышеприведенные выражения политики эквивалентны следующим трем выражениям, где нет неопределенности:

    aut-num: AS1

    import: from peerings-1 action action-1 accept filter-1

    import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1

    import: from peerings-4 action action-2 accept filter-2

    где peerings-3 – это набор маршрутов, которые покрываются как peerings-1, так и peerings-2, а peerings-4 – набор маршрутов, которые покрываются peerings-2, но не покрываются peerings-1 ("filter-2 AND NOT filter-1" соответствует маршрутам, которые согласуются с filter-2, но не с filter-1).

    Пример:

    aut-num: AS1

    import:

    from AS2 1.1.1.2 at 1.1.1.1

    action pref = 2;

    accept {128.9.0.0/16}

    import:

    from AS2

    action pref = 1;

    accept {128.9.0.0/16, 75.0.0.0/8}

    Рассмотрим два пиринга с AS2, 1.1.1.1-1.1.1.2 и 9.9.9.1- 2.2.2.2. Оба выражения политики покрывают 1.1.1.1-1.1.1.2. Для этого пиринга, маршрут 128.9.0.0/16 воспринимается с предпочтением 2, а маршрут 75.0.0.0/8 воспринимается с предпочтением 1. Пиринг 9.9.9.1-2.2.2.2 покрывается только вторым выражением политики. Следовательно, как маршрут 128.9.0.0/16 так и маршрут 75.0.0.0/8 воспринимаются с предпочтением 1 пирингом 9.9.9.1-2.2.2.2. Заметим, что аналогичное правило разрешения неопределенности применимо к выражениям политики по умолчанию и экспортной политики (рассылка маршрутной информации).



    6.5. Атрибут default. Спецификация политики по умолчанию



    Политика маршрутизации по умолчанию специфицируется с помощью атрибута default. Атрибут default имеет следующий синтаксис:

    default: to <peering> [action <action>] [networks <filter>]

    Спецификации <action> и <filter> являются опционными. Семантика выглядит следующим образом: Спецификация <peering> указывает на AS (и маршрутизатор, если он имеется) по умолчанию; спецификация <action>, если присутствует, указывает на различные атрибуты конфигурации по умолчанию. Например, относительное предпочтение, если определено несколько маршрутов по умолчанию; а спецификация <filter>, если имеется, является фильтром политики. Маршрутизатор использует политику по умолчанию, если он получает от партнера маршруты, которые удовлетворяют требованиям фильтра <filter>.



    В следующем примере, AS1 маршрутизируется по умолчанию через AS2.

    aut-num: AS1

    default: to AS2

    В следующем примере, марштутизатор 1.1.1.1 в AS1 маршрутизуется по умолчанию через 1.1.1.2 в AS2.

    aut-num: AS1

    default: to AS2 1.1.1.2 at 1.1.1.1

    В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и AS3, но предпочитает AS2, а не AS3.

    aut-num: AS1

    default: to AS2 action pref = 1;

    default: to AS3 action pref = 2;

    В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и использует 128.9.0.0/16 в качестве сети по умолчанию.

    aut-num: AS1

    default: to AS2 networks { 128.9.0.0/16 }



    6.6. Спецификация структурированной политики



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

    <import-factor> ::= from <peering-1> [action <action-1>]
    . . .
    from <peering-N> [action <action-N>]
    accept <filter>;
    <import-term> ::= <import-factor> |
    LEFT-BRACE
    <import-factor>
    . . .
    <import-factor>
    RIGHT-BRACE
    <import-expression> ::= <import-term> |
    <import-term> EXCEPT <import-expression> |
    <import-term> REFINE <import-expression>  
    import: [protocol <protocol1>] [into <protocol2>]
    <import-expression>
    В конце <import-factor> должна быть точка с запятой. Если спецификация политики не структурирована эта точка с запятой является опционной. Синтаксис и семантика для <import-factor> определена в разделе 6.1. <import-term> представляет собой либо последовательность <import-factor>, заключенную в фигурные скобки, либо один <import-factor>. Семантика <import-term> заключается в объединении <import-factor> с использованием правила порядка спецификаций. <import-expression> представляет собой либо один <import-term>, либо <import-term>, за которым следуют ключевые слова "except" и "refine", с завершающим <import-expression>. Заметим, что данное определение допускает вложенные выражения. Следовательно, могут существовать исключения к исключениям, уточнения к уточнениям или даже уточнения к исключениям и т.д.



    Семантика для оператора except имеет вид. Результатом операции исключения является еще один член <import-term>. Результирующий набор политики содержит описание политики правой стороны, но его фильтры модифицированы так, что остаются только маршруты, соответствующие левой стороне. Политика левой стороны, в конце концов, включается, а ее фильтры модифицируются так, чтобы исключить маршруты, соответствующие левой стороне. Заметим, что фильтры модифицированы во время этого процесса, но действия скопированы один к одному. При нескольких уровнях вложения операции (принять или уточнить) выполняются справа налево.

    Рассмотрим следующий пример:

    import: from AS1 action pref = 1; accept as-foo;
    except {
    from AS2 action pref = 2; accept AS226;
    except {
    from AS3 action pref = 3; accept {128.9.0.0/16};
    }

    }

    где маршрут 128.9.0.0/16 порождается AS226, а AS226 является членом набора AS as-foo. В этом примере, маршрут 128.9.0.0/16 воспринят от AS3, любой другой маршрут (не 128.9.0.0/16) порожденный AS226 воспринимается от AS2, и любые другие маршруты AS из as-foo получены от AS1. Можно прийти к тому же заключению, используя алгебраические выкладки, определенные выше. Рассмотрим спецификацию внутреннего исключения:

    from AS2 action pref = 2; accept AS226;

    except { from AS3 action pref = 3; accept {128.9.0.0/16};}

    Эквивалентно

    { from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};

    from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};}

    Следовательно, исходное выражение эквивалентно:

    import: from AS1 action pref = 1; accept as-foo;
    except { from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};
    from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; }
    который эквивалентен

    import:

    { from AS3 action pref = 3;

    accept as-foo AND AS226 AND {128.9.0.0/16};

    from AS2 action pref = 2;

    accept as-foo AND AS226 AND NOT {128.9.0.0/16};

    from AS1 action pref = 1;

    accept as-foo AND NOT

    (AS226 AND NOT {128.9.0.0/16} OR AS226 AND {128.9.0.0/16}); }



    Так как AS226 находится в as-foo и 128.9.0.0/16 заключен в AS226, выражение упрощается:

    import:

    {

    from AS3 action pref = 3; accept {128.9.0.0/16};

    from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};

    from AS1 action pref = 1; accept as-foo AND NOT AS226;

    }

    В случае оператора refine, результирующий набор формируется с помощью декартова произведения для двух сторон следующим образом. Для каждой политики l левой стороны и для каждой политики r правой стороны, пиринг результирующей политики является пересечением множеств пирингов r и l. Фильтр результирующей политики соответствует пересечению фильтров l и r. Действие результирующей политики есть действие l, за которым следует действие r. Если общие пиринги отсутствуют, или если множество пересечения фильтров является пустым, результирующая политика не формируется. Рассмотрим следующий пример:

    import: { from AS-ANY action pref = 1; accept community(3560:10);
    from AS-ANY action pref = 2; accept community(3560:20);
    } refine { from AS1 accept AS1;
    from AS2 accept AS2;
    from AS3 accept AS3; }
    Здесь любому маршруту с community 3560:10 присваивается предпочтение 1 а любому маршруту с community 3560:20 присваивается предпочтение 2 вне зависимости от того, откуда они импортированы. Однако только маршруты AS1 импортированы из AS1, и только маршруты AS2 импортированы из AS2, и только маршруты AS3 импортированы из AS3, ни один маршрут не импортирован из каких-либо других AS. К тому же заключению можно прийти, используя алгебраические методы, описанные выше. То есть, это пример эквивалентен:

    import: {
    from AS1 action pref = 1; accept community(3560:10) AND AS1;
    from AS1 action pref = 2; accept community(3560:20) AND AS1;
    from AS2 action pref = 1; accept community(3560:10) AND AS2;
    from AS2 action pref = 2; accept community(3560:20) AND AS2;
    from AS3 action pref = 1; accept community(3560:10) AND AS3;
    from AS3 action pref = 2; accept community(3560:20) AND AS3; }
    <


    /p> Рассмотрим следующий пример:

    import: {
    from AS-ANY action med = 0; accept {0.0.0.0/0^0-18};
      } refine {
    from AS1 at 1.1.1.1 action pref = 1; accept AS1;
    from AS1 action pref = 2; accept AS1; }
    где воспринимаются только маршруты с длиной от 0 до 18, а значение med сделано равным 0, для того чтобы блокировать влияние med на все пиринги. Кроме того, из AS1 импортируются только маршруты AS1, а маршруты автономной системы AS1, импортированные от 1.1.1.1, предпочтительнее других пирингов. Это эквивалентно:

    import: {
    from AS1 at 1.1.1.1 action med=0; pref=1;
      accept {0.0.0.0/0^0-18} AND AS1;
    from AS1 action med=0; pref=2;
      accept {0.0.0.0/0^0-18} AND AS1; }
    Описанный выше синтаксис и семантика применима также к структурированным описаниям экспортной политики с ключевым словом "from", замененным на "to", а "accept" – на "announce".



    7. Класс dictionary



    Класс dictionary обеспечивает расширяемость для RPSL. Объекты словаря определяют атрибуты маршрутной политики, типы и маршрутные протоколы. Атрибуты маршрутной политики, впредь называемые rp-атрибутами, могут соответствовать действительным протокольным атрибутам, таким как атрибуты пути BGP (напр., community, dpa и AS-path), или они могут соответствовать особенностям маршрутизатора (напр., гашение осцилляций маршрутов в BGP). Когда вводятся новые протоколы, новые протокольные атрибуты, или новые возможности миршрутизатора, объект словаря актуализуется, с тем чтобы ввести соответствующее описание rp-атрибута или протокола.

    rp-атрибут относится к абстрактному классу, то есть представление данных не доступно. Вместо этого, доступ к ним определяется методом доступа. Например, rp-атрибут для BGP-атрибута AS-path называется aspath, и он имеет метод доступа, называемый prepend,

    который вставляет дополнительные номера AS в атрибуты AS-path. Методы доступа могут воспринимать аргументы. Аргументы строго типофицируются. Например, метод prepend воспринимает номера AS в качестве аргументов.



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

    Ниже рассматривается синтаксис и семантика класса dictionary. Это описание не существенно для понимания объектов dictionary (но оно существенно для их создания).

    Атрибуты класса dictionary представлены на рис. .24. Атрибут dictionary является именем объекта словаря, подчиняющимся правилам присвоения имен в RPSL. Может существовать много объектов словаря, однако имеется только один стандартный объект "RPSL". Все средства используют этот словарь по умолчанию.



    Атрибут



    Значение



    Тип

    Dictionary <object-name> обязательный, однозначный, ключ класса
    rp-attribute См. описание в тексте опционный, многозначный
    typedef См. описание в тексте опционный, многозначный
    protocol См. описание в тексте опционный, многозначный
    Рис. .24. Атрибуты класса dictionary

    Атрибут rp-attribute имеет следующий синтаксис:

    rp-attribute:
    <method-1>(<type-1-1>, ..., <type-1-N1> [, "..."])
    ...
    <method-M>(<type-M-1>, ..., <type-M-NM> [, "..."])
    где <name> является именем rp-атрибута, а <method-i> является названием метода доступа для rp-атрибута, требующего Ni аргументов, где j-ый аргумент имеет тип <type-i-j>. Название метода является либо именем RPSL, либо одним из операторов, определенных на рис. .25. Операторные методы за исключением operator() и operator[] могут воспринимать только один аргумент.

    operator=

    operator==

    operator<<=

    operator<

    operator>>=

    operator>

    operator+=

    operator>=

    operator-=

    operator<=

    operator*=

    operator!=

    operator/=

    operator()

    operator.=

    operator[]



    Рис. .25. Операторы

    Атрибут rp- attribute может иметь много методов, определенных для него. Некоторые из методов могут даже иметь то же самое имя, в этом случае их аргументы должны относиться к другому типу. Если список аргументов завершается "...", метод может воспринять переменное число аргументов. В этом случае, действительные аргументы после N-го аргумента имеют тип <type-N>.

    Аргумента строго типофицированы. <type> в RPSL является либо предопределенным, типом union, списочным, либо определенным в словаре. Предопределенные типы перечислены на рис. .26.

    integer[lower, upper] ipv4_address
    real[lower, upper] address_prefix
    enum[name, name, ...] address_prefix_range
    string dns_name
    Boolean filter
    rpsl_word as_set_name
    free_text route_set_name
    email rtr_set_name
    as_number filter_set_name
      peering_set_name
    Рис. .26. Предопределенные типы аргументов

    За целочисленными и действительными предопределенными типами могут следовать младшие или старшие секции, которые позволяют специфицировать набор допустимых значений аргумента. Спецификация диапазона является опционной. Для представления целых действительных значений и символьных строк используется нотация языка Си (ANSI). За типом enum следует список имен RPSL, которые являются значениями данного типа. Булев тип может принимать значение true или false. as_number, ipv4_address, address_prefix и dns_name типы имеют те же значения, что типы фильтра (раздел 2) и фильтры политики (раздел 6). Значения фильтра следует помещать в скобки.

    Синтаксис типа union имеет следующий вид:

    union <type-1>, ... , <type-N>

    где <type-i> является типом RPSL. Тип union может иметь тип в интервале от <type-1> до <type-N>.

    Синтаксис списочного типа приведен ниже:

    list [<min_elems>:<max_elems>] of <type>

    В этом случае элементы списка представляют <type>, а список содержит по крайней мере <min_elems> элементов, но не больше чем <max_elems>>. Размер спецификации является опционным. Если спецификация отсутствует, то никаких регламентаций на число элементов в списке не накладывается. Значение списочного типа представляется в виде последовательности элементов, разделенных символом запятой "," и заключенных в фигурные скобки "{" и "}". Атрибут typedef в словаре определяет именованный тип следующим образом:



    typedef: <name> <type>

    где <name> - имя типа <type>. Атрибут typedef является особенно полезным, когда тип не является предопределенным (напр., список объединений [union], список списков и т.д.). Атрибут класса словаря protocol определяет протокол и набор параметров пиринга для этого протокола, которые используются в классе inet-rtr (раздел 9). Его синтаксис представлен ниже:

    protocol: <name>
    MANDATORY | OPTIONAL <parameter-1>(
    <type-1-N1> [,"..."])
    ...
    MANDATORY | OPTIONAL <parameter-M>( <type-M-1>,...,
    <type-M-NM> [,"..."])
    где представляет собой имя протокола, MANDATORY и OPTIONAL являются ключевыми словами, а <parameter-i> - пиринг-параметр протокола, использующий Ni аргументов. Синтаксис и семантика аргументов та же, что и для rp-атрибута. Если используется ключевое слово MANDATORY, параметр является обязательным и должен быть специфицирован для каждого пиринга этого протокола. Если применено ключевое слово OPTIONAL, параметр может быть опущен.



    7.1. Исходный словарь RPSL, пример действий политики и фильтры



    dictionary: RPSL

    rp-attribute: # меньшие значения соответствуют более высокому предпочтению pref

    operator=(integer[0, 65535])

    rp-attribute: # атрибут BGP multi_exit_discriminator

    med

    # установить med равным 10: med = 10;

    # установить med метрике IGP: med = igp_cost;

    operator=(union integer[0, 65535], enum[igp_cost])

    rp-attribute: # атрибут предпочтения места назначения BGP (dpa)

    dpa

    operator=(integer[0, 65535])

    rp-attribute: # атрибут BGP aspath

    aspath

    # prepends AS numbers from last to first order

    prepend(as_number, ...)

    typedef: # значение community в RPSL равно:

    # - 4-байтовому целому (ok to use 3561:70 notation)

    # - internet, no_export, no_advertise (смотри RFC-1997)

    community_elm union

    integer[1, 4294967295],

    enum[internet, no_export, no_advertise],

    typedef: # список значений community { 40, no_export, 3561:70 }



    community_list list of community_elm

    rp-attribute: # атрибут BGP community

    community

    # set to a list of communities

    operator=(community_list)

    # добавить значения community

    operator.=(community_list)

    append(community_elm, ...)

    # удалить значения community

    delete(community_elm, ...)

    # фильтр: true если содержится одно из значений community

    contains(community_elm, ...)

    # shortcut to contains: community(no_export, 3561:70)

    operator()(community_elm, ...)

    # сравнение равенства, независящее от порядка

    operator==(community_list)

    rp-attribute:

    # следующий маршрутизатор в статическом маршруте next-hop

      # установить равным 7.7.7.7: next-hop = 7.7.7.7;

    # установить собственный адрес маршрутизатора: next-hop = self;

      operator=(union ipv4_address, enum[self])

    rp-attribute:

    # цена статического маршрута cost

    operator=(integer[0, 65535])

    protocol:

    BGP4

      # номер AS маршрутизатора партнера

      MANDATORY asno(as_number)

      # разрешить гашение осцилляций маршрута

      OPTIONAL flap_damp()

      OPTIONAL flap_damp(integer[0,65535],

      # penalty per flap

      integer[0,65535],

      # penalty value for supression

      integer[0,65535],

      # penalty value for reuse

      integer[0,65535],

      # halflife in secs when up

      integer[0,65535],

      # halflife in secs when down

      integer[0,65535])

      # максимальный штраф

    protocol: OSPF

    protocol: RIP

    protocol: IGRP

    protocol: IS-IS

    protocol: STATIC

    protocol: RIPng

    protocol: DVMRP

    protocol: PIM-DM

    protocol: PIM-SM

    protocol: CBT

    protocol: MOSPF

    Рис. .27. Словарь RPSL

    На рис. .27 показан исходный словарь RPSL. Он имеет семь rp-атрибутов: pref для присвоения локального предпочтения воспринимаемым маршрутам; med для присвоения значения атрибуту MULTI_EXIT_DISCRIMINATOR BGP; dpa для присвоения значения атрибуту DPA BGP; aspath для присвоения значения атрибуту AS_PATH BGP; community для присвоения или проверки значения атрибута community BGP; next-hop для назначения следующих маршрутизаторов в случае статических маршрутов; cost для назначения цены статических маршрутов. Словарь определяет два типа: community_elm и community_list. Тип community_elm является либо 4-байтовым целым числом без знака, либо одним из ключевых слов Интернет, no_export или no_advertise. Целое число может быть специфицировано с помощью двух 2-байтовых чисел, разделенных двоеточием ":", чтобы разделить пространство кода community так, чтобы провайдер мог использовать номер AS первых двух байт, и определить семантику выбора последних двух байт.



    Исходный словарь (рис. .27) определяет только опции для BGP (Border Gateway Protocol): asno и flap_damp. Обязательная опция asno является номером AS партнера-маршрутизатора. Опция flap_damp инструктирует маршрутизатор гасить осцилляции маршрутов [21], при импортировании маршрутов от маршрутизатора-партнера. Она может быть специфицирована с или без параметров. Если параметры опущены, принимаются значения по умолчанию:

    flap_damp(1000, 2000, 750, 900, 900, 20000)

    То есть, назначается штраф 1000 для каждого переключения маршрута, маршрут закрывается, когда штраф достигает 2000. Штраф снижается вдвое после 15 минут стабильного режима вне зависимости оттого открыт путь или нет. Закрытый маршрут используется вновь, когда штраф падает ниже 750. Максимальный штраф маршрута может достигать 20,000 (т.e. максимальное время закрытия маршрута после стабилизации ситуации составляет около 75 минут).

    Действия политики и фильтров, использующих rp-атрибуты

    Синтаксис действия политики или фильтра, использующего rp-атрибут x выглядит следующим образом:

    x.method(arguments)

    x "op" argument

    где method представляет собой метод, а "op" – метод оператора rp-атрибута x. Если метод оператора используется при спецификации составного фильтра политики, он определяется раньше, чем операторы составных фильтров политики (т.e. AND, OR, NOT или оператор). rp-атрибуту pref может быть присвоено положительное целое число следующим образом:

    pref = 10;

    rp-атрибуту med может быть присвоено положительное целое число или слово "igp_cost" следующим образом:

    med = 0;

    med = igp_cost;

    rp-атрибуту dpa может быть присвоено положительное целое число следующим образом:

    dpa = 100;

    Значением атрибута community BGP является список, который состоит из 4-байтовых целых чисел, каждое их которых характеризует "community". Следующие примеры демонстрируют, как добавлять новые значения community к этому rp-атрибуту:

    community .= { 100 };

    community .= { NO_EXPORT };

    community .= { 3561:10 };



    В последнем случае, 4- байтовое целое число, сформированное так, что наиболее значимые два байта равны 3561, а менее значимые два байта равны 10. Следующие примеры показывают, как удалять элементы из rp-атрибута community:

    community.delete(100, NO_EXPORT, 3561:10);

    Фильтры, которые используют rp-атрибут community могут быть определены, как это показано в следующем примере:

    community.contains(100, NO_EXPORT, 3561:10);

    community(100, NO_EXPORT, 3561:10); # shortcut

    rp-атрибуту community может быть присвоено значение, соответствующее списку community следующим образом:

    community = {100, NO_EXPORT, 3561:10, 200};

    community = {};

    В этом первом случае, rp-атрибут community содержит значения (communities) 100, NO_EXPORT, 3561:10 и 200. В последнем случае, rp-атрибут community обнулен. rp-атрибут community может быть сравнен со списком communities следующим образом:

    community == {100, NO_EXPORT, 3561:10, 200}; # точное соответствие

    Чтобы повлиять на выбор маршрута, rp-атрибут BGP as_path может быть сделан длиннее путем предварительной прописи номеров AS следующим образом:

    aspath.prepend(AS1);

    aspath.prepend(AS1, AS1, AS1);

    Следующие примеры некорректны:

    med = -50; # -50 лежит вне диапазона
    med = igp; # igp не является одним из значений enum
    med.assign(10); # заданный метод не определен
    community.append(AS3561:20); # первый аргумент должен быть равен 3561. На рис. .28 показан более продвинутый пример, использующий rp-атрибут community. В этом примере, AS3561 базирует свое предпочтение при выборе маршрута на атрибуте community. Другие AS могут апосредовано влиять на выбор маршрутов AS3561 путем включения соответствующих значений communities в их оповещения о маршрутах.
    aut-num: AS1

    export:

    to AS2 action community.={3561:90};

    to AS3 action community.={3561:80};

    announce AS1

    as-set: AS3561:AS-PEERS

    members: AS2, AS3

    aut-num: AS3561

    import:

    from AS3561:AS-PEERS

    action pref = 10;

    accept community(3561:90)

    import:

    from AS3561:AS-PEERS



    action pref = 20;

    accept community(3561:80)

    import:

    from AS3561:AS-PEERS

    action pref = 20;

    accept community(3561:70)

    import:

    from AS3561:AS-PEERS

    action pref = 0;

    accept ANY

    Рис. .28. Пример политики с использованием rp-атрибута community.



    8. Класс Advanced route

    8.1. Спецификация агрегатных маршрутов



    Атрибуты components, aggr-bndry, aggr-mtd, export-comps, inject и holes используются для спецификации агрегатных маршрутов [11]. Объект route специфицирует агрегатный маршрут, если специфицирован любой из этих атрибутов за исключением inject. Атрибут origin для агрегатного маршрута производит объединение маршрутов на базе AS. Здесь термин "aggregate" используется в отношении генерируемого маршрута, термин "component" относится к маршрутам, использованным для формирования атрибута объединения (aggregate) path, а термин "more specifics" относится к любому маршруту, который более специфичен для объединения, вне зависимости от того, используется ли он при формировании атрибутов path. Атрибут components определяет, какой из составляющих маршрутов используется для формирования объединения. Его синтаксис выглядит следующим образом:

    components: [ATOMIC] [[<filter>] [protocol <protocol> <filter> ...]]

    где <protocol> представляет собой имя протокола маршрутизации, такого как BGP4, OSPF или RIP (допустимые значения определяются словарем), а <filter> - выражение политики. Маршруты, соотносятся с одним из этих фильтров и получены с помощью соответствующего протокола, используются для формирования объединения (aggregate). Если <protocol> опущен, по умолчанию предполагается любой протокол. <filter> неявно содержит термин "AND" с более специфическими префиксами объединения, так что выбираются только маршруты компоненты. Если используется ключевое слово ATOMIC, объединение выполнено на уровне атомов [11]. Если атрибут components пропущен, используются все более специфичные префиксы без ключевого слова ATOMIC.



    route: 128.8.0.0/15

    origin: AS1

    components: <^AS2>

    route: 128.8.0.0/15

    origin: AS1

    components:

    protocol BGP4 {128.8.0.0/16^+}

    protocol OSPF {128.9.0.0/16^+}

    Рис. .29. Два объекта агрегатных маршрутов.

    На рис. 29 показаны два объекта route. В первом примере объединяются более специфические префиксы 128.8.0.0/15 с проходами, начинающимися с AS2. Во втором примере агрегатированы некоторые маршруты, полученные от BGP и некоторые маршруты, полученные из OSPF.

    Атрибут aggr-bndry является AS-выражением для номеров и наборов (см. раздел 5.6). Результат определяет набор AS, который задает границу объединения (aggregation). Если атрибут aggr-bndry опущен, исходная AS является единственной границей объединения. За пределами границы объединения экспортируется только это объединение, а более специфичные префиксы передаваться не могут. Однако в пределах границы, более специфичные префиксы также могут пересылаться.

    Атрибут aggr-mtd определяет то, как формируется объединение. Его синтаксис показан ниже:

    aggr-mtd: inbound
    | outbound [<as-expression>]
    где <as-expression> - выражение для номеров AS и наборов (см. раздел 5.6). Если <as-expression> опущено, по умолчанию предполагается AS-ANY. Если специфицировано экспортное объединение, более специфические префиксы будут присутствовать в пределах AS, а объединение будет сформировано перед отправкой на всех inter-AS границах с AS в <as-expression>, за исключением AS, которые находятся на границе объединения. Если специфицировано импортное объединение, объединение формируется на всех границах inter-AS прежде чем переносить маршруты в агрегатор AS. Заметим, что <as-expression> не может быть специфицировано с использованием импортного объединения. Если атрибут aggr-mtd опущен, он не выполняет функции "outbound AS-ANY".

    route: 128.8.0.0/15 route: 128.8.0.0/15
    origin: AS1 origin: AS2
    components: {128.8.0.0/15^-} components: {128.8.0.0/15^-}
    aggr-bndry: AS1 OR AS2 aggr-bndry: AS1 OR AS2
    aggr-mtd: outbound AS-ANY aggr-mtd: outbound AS-ANY
    <


    /p> Рис. .30. Пример экспортного объединения большого числа AS.

    На рис. 30 показан пример экспортного объединения. В этом примере, AS1 и AS2 представляют собой объединение и оповещают окружающий мир только о менее специфических префиксах 128.8.0.0/15, обмениваясь друг с другом более специфическими префиксами. Эта форма объединения полезна, когда некоторые компоненты находятся внутри AS1, а некоторые в AS2.

    Когда агрегатируется набор маршрутов, предполагается экспортировать только агрегатные маршруты и блокировать экспорт более специфичных префиксов вне границы объединения, чтобы удовлетворить определенной политике и топологическим ограничениям (напр., компонента со многими интерфейсами (multi-homed)) часто необходимо экспортировать некоторые компоненты. Атрибут export-comps эквивалентен фильтру RPSL, который соответствует более специфичным префиксам. Если этот атрибут опущен, более специфические префиксы не экспортируются за пределы границы объединения. Заметим, что, фильтр export-comps содержит неявный оператор "AND" по отношению более специфичным префиксам объединения.

    На рис. 31 показан пример экспортного объединения. В этом примере, более специфические префиксы 128.8.8.0/24 экспортируются из AS1 в дополнение к объединению. Это полезно, когда 128.8.8.0/24 является многопортовым узлом, связанным с другими AS.

    route: 128.8.0.0/15
    origin: AS1
    components: {128.8.0.0/15^-}
    aggr-mtd: outbound AS-ANY
    export-comps: {128.8.8.0/24}
    Рис. .31. Экспортное объединение с исключениями.

    Атрибут inject определяет, какие маршрутизаторы выполняют объединение, и когда они это делают. Синтаксис атрибута показан ниже:

    inject: [at <router-expression>] ...
    [action <action>]
    [upon <condition>]
    где <action> - спецификация действия (см. раздел 6.1.1), <condition> - булево выражение, описанное ниже, <router-expression> описано в разделе 5.6.

    Все маршрутизаторы в <router-expression> и в агрегаторе (объединении) AS выполняют агрегацию. Если <router-expression> не специфицировано, все маршрутизаторы внутри агрегатора AS выполняют агрегацию. Спецификация <action> может установить атрибуты path объединения (aggregate), например, определить предпочтения для объединения.



    Так как условие является булевым выражением, объединение создается, если и только если это условие истинно. <condition> - булево выражение, использующее логические операторы AND и OR (т.e. оператор NOT не разрешен):

    HAVE-COMPONENTS { список префиксов }

    EXCLUDE { список префиксов }

    STATIC

    Список префиксов в HAVE-COMPONENTS может состоять из более специфических префиксов объединения. Список может также включать диапазоны префиксов (т.e. использование операторов ^-, ^+, ^n, и ^n-m). В этом случае, по крайней мере, один префикс из каждого диапазона префиксов должен присутствовать в каждой маршрутной таблице, для того чтобы условие было выполнено. Список префиксов в EXCLUDE может быть произвольным. Условие выполняется, когда ни один из перечисленных префиксов не содержится в маршрутной таблице. Список может содержать диапазоны префиксов, а ни один префикс из этого диапазона не должен присутствовать в маршрутной таблице. Ключевое слово static всегда предполагается равным true.

    route: 128.8.0.0/15
    origin: AS1
    components: {128.8.0.0/15^-}
    aggr-mtd: outbound AS-ANY
    inject: at 1.1.1.1 action dpa = 100;
    inject: at 1.1.1.2 action dpa = 110;
    route: 128.8.0.0/15
    origin: AS1
    components: {128.8.0.0/15^-}
    aggr-mtd: outbound AS-ANY
    inject: upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16}
    holes: 128.8.8.0/24
    Рис. .32. Примеры инжекции.

    На рис. 32 показаны два примера. В первом случае, объединение вводится в два маршрутизатора, каждый из которых устанавливает атрибут прохода dpa по-разному. Во втором случае, объединение формируется только если в маршрутной таблице присутствуют как 128.8.0.0/16 так и 128.9.0.0/16, в отличие от первого случая, когда присутствия лишь одного из них достаточно для ввода (injection).

    Атрибут holes перечисляет компоненты адресных префиксов, которые не достижимы через агрегатный маршрут (возможно, что часть адресного пространства не распределена). Атрибут holes полезен для диагностических целей. На рис. .32, второй пример имеет дырку, в частности 128.8.8.0/24. Это может быть связано с тем, что клиент менял провайдера и брал для этой цели эту часть адресного пространства.





    8.1.1. Взаимодействие с политикой в классе aut-num



    О сформированном объединении другие AS оповещаются только в случае, когда экспортная политика AS позволяет передавать объединения маршрутов. Когда объединение сформировано, более специфические префиксы запрещены для экспорта за исключением AS в aggr-bndry и компонент в export-comps.

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

    route: 128.8.0.0/16
    origin: AS1
    route: 128.9.0.0/16
    origin: AS1
    route: 128.8.0.0/15
    origin: AS1
    aggr-bndry: AS1 or AS2 or AS3
    aggr-mtd: outbound AS3 or AS4 or AS5
    components: {128.8.0.0/16, 128.9.0.0/16}
    inject: upon HAVE-COMPONENTS {128.9.0.0/16, 128.8.0.0/16}
    aut-num: AS1
    export: to AS2 announce AS1
    export: to AS3 announce AS1 and not {128.9.0.0/16}
    export: to AS4 announce AS1
    export: to AS5 announce AS1
    export: to AS6 announce AS1
    Рис. .33. Взаимодействие с политикой в классе aut-num.

    На рис. 33 показан пример взаимодействия. При рассмотрении маршрутных объектов следует произвести обмен более специфическими префиксами 128.8.0.0/16 и 128.9.0.0/16 между AS1, AS2 и AS3 (граница объединения).

    Экспортное объединение выполнено для AS4 и AS5, но не для AS3, так как AS3 находится на границе объединения. Объект aut-num допускает экспортирование обоих компонентов в AS2, и только компонент 128.8.0.0/16 в AS3. Объединение может быть сформировано, если присутствуют все компоненты. В данном случае только об этом объединении оповещены AS4 и AS5. Однако, если одна из компонент не доступна, объединение не может быть создано, и любая из доступных компонент или более специфический префикс будет экспортирован в AS4 и AS5. Вне зависимости от того, выполнено объединение или нет, только более специфические префиксы будут экспортированы в AS6.



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



    8.1.2. Разрешение неопределенности для перекрывающихся объединений



    Когда специфицированы несколько маршрутных объединений и они перекрываются, т.e. один менее специфичен чем другой, тогда сначала определяются более а затем менее специфичные. Когда для партнера осуществляется экспортное объединение (outbound aggregation), объединение и компоненты, перечисленные в атрибуте export-comps, доступны для генерации следующих менее специфичных объединений. Компоненты, которые не специфицированы в атрибуте export-comps, являются недоступными. Маршрут экспортируем в AS, если это наименее специфическое объединение, экспортируемое в эту автономную систему или маршрут упомянут в атрибуте export-comps. Заметим, что это рекурсивное определение.

    route:

    128.8.0.0/15

    origin:

    AS1

    aggr-bndry:

    AS1 or AS2

    aggr-mtd:

    outbound

    inject:

    upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16}

    route:

    128.10.0.0/15

    origin:

    AS1

    aggr-bndry:

    AS1 or AS3

    aggr-mtd:

    outbound

    inject:

    upon HAVE-COMPONENTS {128.10.0.0/16, 128.11.0.0/16}

    export-comps:

    {128.11.0.0/16}

    route:

    128.8.0.0/14

    origin:

    AS1

    aggr-bndry:

    AS1 or AS2 or AS3

    aggr-mtd:

    outbound

    inject:

    upon HAVE-COMPONENTS {128.8.0.0/15, 128.10.0.0/15}

    export-comps:

    {128.10.0.0/15}

    Рис. .34. Перекрывающиеся объединения.

    На рис. 34, AS1 вместе с AS2 объединяют 128.8.0.0/16 и 128.9.0.0/16 в 128.8.0.0/15. Вместе с AS3, AS1 объединяет 128.10.0.0/16 и 128.11.0.0/16 в 128.10.0.0/15. Но все вместе они объединяют эти четыре маршрута в 128.8.0.0/14. Предполагая все четыре компоненты доступными, маршрутизатор в AS1 для внешней AS, скажем AS4, сначала сгенерирует 128.8.0.0/15 и 128.10.0.0/15. Это сделает 128.8.0.0/15, 128.10.0.0/15 и его исключение 128.11.0.0/16 доступным для генерации 128.8.0.0/14. Маршрутизатор из этих трех маршрутов будет затем генерировать 128.8.0.0/14. Следовательно, для AS4, 128.8.0.0/14 и его исключение, 128.10.0.0/15 и его исключение 128.11.0.0/16 станут экспортируемыми.



    Для AS2, маршрутизатор в AS1 сгенерирует только 128.10.0.0/15. Следовательно, 128.10.0.0/15 и его исключение 128.11.0.0/ 16 станут экспортируемыми. Заметим, что 128.8.0.0/16 и 128.9.0.0/16 являются также экспортируемыми, так как они не участвуют в объединении, допускающем экспорт в AS2. Аналогично, для AS3, маршрутизатор в AS1 будет генерировать только 128.8.0.0/15. В этом случае 128.8.0.0/15, 128.10.0.0/16, 128.11.0.0/16 могут экспортироваться.



    8.2. Спецификация статических маршрутов



    Атрибут inject может служить для спецификации статических маршрутов, используя "upon static" в качестве условия:

    inject: [at <routerexpression>] ...
    [action <action>]
    upon static
    В этом случае маршрутизатор в <router-expression> выполняет <action> и вводит маршрут в статическую маршрутную систему interAS. <action> может установить определенные маршрутные атрибуты, такие как next-hop router или cost.

    В следующем примере, маршрутизатор 1.1.1.1 вводит маршрут 128.7.0.0/16. Маршрутизаторы следующего шага (в этом примере, имеется два маршрутизатора “следующего шага”) для этого маршрута имеют адреса 1.1.1.2 и 1.1.1.3, а маршрут имеет цену 10 для 1.1.1.2 и 20 для 1.1.1.3.

    route: 128.7.0.0/16

    origin: AS1

    inject: at 1.1.1.1 action next-hop = 1.1.1.2; cost = 10; upon static

    inject: at 1.1.1.1 action next-hop = 1.1.1.3; cost = 20; upon static



    9. Класс inet-rtr



    Маршрутизаторы специфицируются с использованием класса inet-rtr. Атрибуты класса inet-rtr показаны на рис. 35. Атрибут inet-rtr представляет собой допустимое имя DNS описанного маршрутизатора. Каждый атрибут alias, если он присутствует, является каноническим именем DNS для маршрутизатора. Атрибут local-as специфицирует номер AS, которой управляет данный маршрутизатор.



    Атрибут



    Значение



    Тип

    inet-rtr <dns-name> обязательный, однозначный, ключ класса
    alias <dns-name> опционный, многозначный
    local-as <as-number> обязательный, однозначный
    ifaddr См. описание в тексте обязательный, многозначный
    peer См. описание в тексте опционный, многозначный
    member-of список <rtr-set-names> опционный, многозначный
    <


    /p> Рис. .35. Атрибуты класса inet-rtr

    Значение атрибута ifaddr имеет следующий синтаксис:

    <ipv4-address> masklen <integer>> [action <action>]

    IP-адрес и длина маски являются обязательными для каждого интерфейса. Опционно можно специфицировать действие (action), которое позволяет установить другие параметры этого интерфейса.

    На рис. .36 предложен пример объекта inet-rtr. Имя маршрутизатора "amsterdam.ripe.net". "amsterdam1.ripe.net" является каноническим именем для маршрутизатора. Маршрутизатор соединен с четырьмя сетями. Их IP-адреса и длины масок специфицированы в атрибутах ifaddr.

    inet-rtr: Amsterdam.ripe.net

    alias: amsterdam1.ripe.net

    local-as: AS3333

    ifaddr: 192.87.45.190 masklen 24

    ifaddr: 192.87.4.28 masklen 24

    ifaddr: 193.0.0.222 masklen 27

    ifaddr: 193.0.0.158 masklen 27

    peer: BGP4 192.87.45.195 asno(AS3334), flap_damp()

    Рис. .36. Объекты inet-rtr

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

    <protocol> <ipv4address> <options>
    | <protocol> <inet-rtr-name> <options>
    | <protocol> <rtr-set-name> <options>
    | <protocol> <peering-set-name> <options>
    где <protocol> - имя протокола, <ipv4-address> - IP-адрес маршрутизатора партнера, а <options> - список опций пиринга для <protocol>. Элементы списка разделяются запятыми. Вместо IP-адресов партнеров, может использоваться его inet-rtr-name. Допустимые имена протоколов и атрибуты определены в словаре (см. раздел 7). В выше приведенном примере, маршрутизатор имеет BGP-пиринг с маршрутизатором 192.87.45.195 в AS3334. Он включает подавление осцилляций маршрута, когда импортирует маршруты из этого маршрутизатора.

    Вместо одиночного партнера с помощью форм <rtr-set-name> и <peering-set-name> может быть специфицирована группа партнеров. Если использована форма <peering-set- name>, то включаются только пиринги из соответствующего набора данного маршрутизатора. На рис. .37 показан пример объекта inet-rtr с пиринг-группами.



    rtr-set: rtrs-ibgp-peers

    members: 1.1.1.1, 2.2.2.2, 3.3.3.3

    peering-set: prng-ebgp-peers

    peering: AS3334 192.87.45.195

    peering: AS3335 192.87.45.196

    inet-rtr: Amsterdam.ripe.net

    alias: amsterdam1.ripe.net

    local-as: AS3333

    ifaddr: 192.87.45.190 masklen 24

    ifaddr: 192.87.4.28 masklen 24

    ifaddr: 193.0.0.222 masklen 27

    ifaddr: 193.0.0.158 masklen 27

    peer: BGP4 rtrs-ibgp-peers asno(AS3333), flap_damp()

    peer: BGP4 prng-ebgp-peers asno(PeerAS), flap_damp()

    Рис. .37. Объект inet-rtr с пиринг-группами



    10. Расширение RPSL



    Практика работы с языками описания маршрутной политики (PRDB [2], RIPE-81 [8], and RIPE-181 [7]) показывает, что язык описания должен быть расширяемым. Новые маршрутные протоколы или новые особенности существующих протоколов могут быть легко описаны, с помощью класса dictionary RPSL. Могут быть добавлены новые классы или новые атрибуты существующих классов.

    Класс dictionary является первичным механизмом расширения RPSL. Объекты словаря определяют атрибуты маршрутной политики, типы и протоколы маршрутизации.

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

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

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



    Введение новых атрибутов рекомендуется, когда у существующего класса появляются новые черты. Например, класс RPSL route расширяет возможности препроцессора RIPE-181 путем введения нескольких новых атрибутов, которые разрешают агрегатирование и спецификации статических маршрутов.

    Новые классы могут добавляться к RPSL для записи новых типов данных, характеризующих политику. Так как любое средство запрашивает IRR только о классах, которые ему известны, проблемы совместимости возникнуть просто не может.

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



    Ссылки



    [1] Internet routing registry. procedures. http://www.ra.net/RADB.tools.docs/, http://www.ripe.net/db/doc.html.
    [2] Nsfnet policy routing database (prdb). Maintained by MERIT Network Inc., Ann Arbor, Michigan. Contents available from nic.merit.edu.:/nsfnet/announced.networks /nets.tag.now by anonymous ftp.
    [3] Alaettinouglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra, M. and C. Villamizer, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.
    [4] C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of routing policy specification language (rpsl) on the internet. Work in Progress.
    [5] T. Bates. Specifying an `internet router' in the routing registry. Technical Report RIPE-122, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
    [6] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation of ip routing policies in a routing registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
    [7] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M. and J. Yu, " Representation of IP Routing Policies in a Routing Registry", RFC-1786, March 1995.
    [8] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. Representation of ip routing policies in the ripe database. Technical Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993.
    [9] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC-1997, August 1996.
    [10] Crocker, D., "Standard for ARPA Internet Text Messages", STD 11, RFC-822, August 1982.
    [11] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC-1519, September 1993.
    [12] D. Karrenberg and T. Bates. Description of inter-as networks in the ripe routing registry. Technical Report RIPE-104, RIPE, RIPE NCC, Amsterdam, Netherlands, December 1993.
    [13] D. Karrenberg and M. Terpstra. Authorisation and notification of changes in the ripe database. Technical Report ripe-120, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
    [14] B. W. Kernighan and D. M. Ritchie. The C Programming Language. Prentice-Hall, 1978.
    [15] A. Lord and M. Terpstra. Ripe database template for networks and persons. Technical Report ripe-119, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
    [16] A. M. R. Magee. Ripe ncc database documentation. Technical Report RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997.
    [17] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC-1034, November 1987.
    [18] Y. Rekhter. Inter-domain routing protocol (idrp). Journal of Internetworking Research and Experience, 4:61--80, 1993.
    [19] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC-1771, March 1995.
    [20] C. Villamizar, C. Alaettinouglu, D. Meyer, S. Murphy, and C. Orange. Routing policy system security", Work in Progress.
    [21] Villamizar, C., Chandra, R. and R. Govindan, "BGP Route Flap Damping", RFC-2439, November 1998.
    [22] J. Zsako, "PGP authentication for ripe database updates", Work in Progress.
    <


    /p>

    B. Грамматические правила



    Ниже рассмотрены формальные грамматические правила RPSL. Основные типы данных определены в разделе 2. Правила записаны с использованием входного языка грамматического разбора GNU Bison.

    //**** базовые атрибуты *********************************************

    changed_attribute: ATTR_CHANGED TKN_EMAIL TKN_INT

    //**** класс aut-num *************************************************

    //// as_expression /////////////////////////////////////////////////////

    opt_as_expression: | as_expression

    as_expression: as_expression OP_OR as_expression_term | as_expression_term

    as_expression_term: as_expression_term OP_AND as_expression_factor

    | as_expression_term KEYW_EXCEPT as_expression_factor | as_expression_factor

    as_expression_factor: '(' as_expression ')' | as_expression_operand

    as_expression_operand: TKN_ASNO | TKN_ASNAME

    //// router_expression /////////////////////////////////////////////////

    opt_router_expression: | router_expression

    opt_router_expression_with_at: | KEYW_AT router_expression

    router_expression: router_expression OP_OR router_expression_term | router_expression_term

    router_expression_term: router_expression_term OP_AND router_expression_factor

    | router_expression_term KEYW_EXCEPT router_expression_factor | router_expression_factor

    router_expression_factor: '(' router_expression ')' | router_expression_operand

    router_expression_operand: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME

    //// пиринг ///////////////////////////////////////////////////////////

    peering: as_expression opt_router_expression opt_router_expression_with_at

    | TKN_PRNGNAME

    //// действие ////////////////////////////////////////////////////////////

    opt_action: | KEYW_ACTION action

    action: single_action | action single_action

    single_action: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')' ';'

    | TKN_RP_ATTR TKN_OPERATOR list_item ';' | TKN_RP_ATTR '(' generic_list ')' ';'

    | TKN_RP_ATTR '[' generic_list ']' ';' | ';'

    //// фильтр ////////////////////////////////////////////////////////////

    filter: filter OP_OR filter_term | filter filter_term %prec OP_OR | filter_term



    filter_term : filter_term OP_AND filter_factor | filter_factor

    filter_factor : OP_NOT filter_factor | '(' filter ')' | filter_operand

    filter_operand: KEYW_ANY | '' | filter_rp_attribute | TKN_FLTRNAME

    | filter_prefix

    filter_prefix: filter_prefix_operand OP_MS | filter_prefix_operand

    filter_prefix_operand: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | TKN_RSNAME

    | '{' opt_filter_prefix_list '}'

    opt_filter_prefix_list: | filter_prefix_list

    filter_prefix_list: filter_prefix_list_prefix | filter_prefix_list ',' filter_prefix_list_prefix

    filter_prefix_list_prefix: TKN_PRFXV4 | TKN_PRFXV4RNG

    filter_aspath: filter_aspath '|' filter_aspath_term | filter_aspath_term

    filter_aspath_term: filter_aspath_term filter_aspath_closure | filter_aspath_closure

    filter_aspath_closure: filter_aspath_closure '*' | filter_aspath_closure '?' | filter_aspath_closure '+'

    | filter_aspath_factor

    filter_aspath_factor: '^' | '$' | '(' filter_aspath ')' | filter_aspath_no

    filter_aspath_no: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | '.' | '[' filter_aspath_range ']'

    | '[' '^' filter_aspath_range ']'

    filter_aspath_range: | filter_aspath_range TKN_ASNO | filter_aspath_range KEYW_PEERAS

    | filter_aspath_range '.' | filter_aspath_range TKN_ASNO '-' TKN_ASNO

    | filter_aspath_range TKN_ASNAME

    filter_rp_attribute: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')'

    | TKN_RP_ATTR TKN_OPERATOR list_item | TKN_RP_ATTR '(' generic_list ')'

    | TKN_RP_ATTR '[' generic_list ']'

    //// пара пиринг-действий ///////////////////////////////////////////////

    import_peering_action_list: KEYW_FROM peering opt_action

    | import_peering_action_list KEYW_FROM peering opt_action

    export_peering_action_list: KEYW_TO peering opt_action

    | export_peering_action_list KEYW_TO peering opt_action

    //// фактор import/export //////////////////////////////////////////////

    import_factor: import_peering_action_list KEYW_ACCEPT filter

    import_factor_list: import_factor ';' | import_factor_list import_factor ';'

    export_factor: export_peering_action_list KEYW_ANNOUNCE filter



    export_factor_list: export_factor ';' | export_factor_list export_factor ';'

    //// термин import/export ////////////////////////////////////////////////

    import_term: import_factor ';' | '{' import_factor_list '}'

    export_term: export_factor ';' | '{' export_factor_list '}'

    //// выражение import/export //////////////////////////////////////////

    import_expression: import_term | import_term KEYW_REFINE import_expression

    | import_term KEYW_EXCEPT import_expression

    export_expression: export_term | export_term KEYW_REFINE export_expression

    | export_term KEYW_EXCEPT export_expression

    //// протокол ///////////////////////////////////////////////////////////

    opt_protocol_from: | KEYW_PROTOCOL tkn_word

    opt_protocol_into: | KEYW_INTO tkn_word

    //**** атрибуты import/export ****************************************

    import_attribute: ATTR_IMPORT

    | ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor

    export_attribute: ATTR_EXPORT

    | ATTR_EXPORT opt_protocol_from opt_protocol_into export_factor

    opt_default_filter: | KEYW_NETWORKS filter

    default_attribute: ATTR_DEFAULT KEYW_TO peering

    filter_attribute: ATTR_FILTER filter

    peering_attribute: ATTR_PEERING peering

    //**** класс inet-rtr **************************************************

    ifaddr_attribute: ATTR_IFADDR TKN_IPV4 KEYW_MASKLEN TKN_INT opt_action

    //// атрибут peer ////////////////////////////////////////////////////

    opt_peer_options: | peer_options

    peer_options: peer_option | peer_options ',' peer_option

    peer_option: tkn_word '(' generic_list ')'

    peer_id: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME | TKN_PRNGNAME

    peer_attribute: ATTR_PEER tkn_word peer_id opt_peer_options

    //**** класс route *****************************************************

    aggr_bndry_attribute: ATTR_AGGR_BNDRY as_expression

    aggr_mtd_attribute: ATTR_AGGR_MTD KEYW_INBOUND

    | ATTR_AGGR_MTD KEYW_OUTBOUND opt_as_expression

    //// атрибут inject //////////////////////////////////////////////////

    opt_inject_expression: | KEYW_UPON inject_expression



    inject_expression: inject_expression OP_OR inject_expression_term | inject_expression_term

    inject_expression_term: inject_expression_term OP_AND inject_expression_factor

    | inject_expression_factor

    inject_expression_factor: '(' inject_expression ')' | inject_expression_operand

    inject_expression_operand: KEYW_STATIC

    | KEYW_HAVE_COMPONENTS '{' opt_filter_prefix_list '}'

    | KEYW_EXCLUDE '{' opt_filter_prefix_list '}'

    inject_attribute: ATTR_INJECT opt_router_expression_with_at opt_action opt_inject_expression

    //// атрибут components //////////////////////////////////////////////

    opt_atomic: | KEYW_ATOMIC

    components_list: | filter | components_list KEYW_PROTOCOL tkn_word filter

    components_attribute: ATTR_COMPONENTS opt_atomic components_list

    //**** набор маршрутов *****************************************************

    opt_rs_members_list: /* пустой список */

    | rs_members_list

    rs_members_list: rs_member | rs_members_list ',' rs_member

    rs_member: TKN_ASNO | TKN_ASNO OP_MS | TKN_ASNAME | TKN_ASNAME OP_MS

    | TKN_RSNAME | TKN_RSNAME OP_MS | TKN_PRFXV4 | TKN_PRFXV4RNG

    rs_members_attribute: ATTR_RS_MEMBERS opt_rs_members_list

    //**** словарь ******************************************************

    rpattr_attribute: ATTR_RP_ATTR TKN_WORD methods

    | ATTR_RP_ATTR TKN_RP_ATTR methods

    methods: method | methods method

    method: TKN_WORD '(' ')' | TKN_WORD '(' typedef_type_list ')'

    | TKN_WORD '(' typedef_type_list ',' TKN_3DOTS ')'

    | KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ')'

    | KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ',' TKN_3DOTS ')'

    //// атрибут typedef ////////////////////////////////////////////////

    typedef_attribute: ATTR_TYPEDEF TKN_WORD typedef_type

    typedef_type_list: typedef_type | typedef_type_list ',' typedef_type

    typedef_type: KEYW_UNION typedef_type_list | KEYW_RANGE KEYW_OF typedef_type

    | TKN_WORD | TKN_WORD '[' TKN_INT ',' TKN_INT ']'

    | TKN_WORD '[' TKN_REAL ',' TKN_REAL ']' | TKN_WORD '[' enum_list ']'

    | KEYW_LIST '[' TKN_INT ':' TKN_INT ']' KEYW_OF typedef_type



    | KEYW_LIST KEYW_OF typedef_type

    enum_list: tkn_word | enum_list ',' tkn_word

    //// атрибут protocol ////////////////////////////////////////////////

    protocol_attribute: ATTR_PROTOCOL tkn_word protocol_options

    protocol_options: | protocol_options protocol_option

    protocol_option: KEYW_MANDATORY method | KEYW_OPTIONAL method

    //**** Описания лексем *********************************************

    //// макросы flex, используемые при определении лексем /////////////////////////////

    INT [[:digit:]]+

    SINT [+-]?{INT}

    REAL [+-]?{INT}?\.{INT}({WS}*E{WS}*[+-]?{INT})?

    NAME [[:alpha:]]([[:alnum:]_-]*[[:alnum:]])?

    ASNO AS{INT}

    ASNAME AS-[[:alnum:]_-]*[[:alnum:]]

    RSNAME RS-[[:alnum:]_-]*[[:alnum:]]

    RTRSNAME RTRS-[[:alnum:]_-]*[[:alnum:]]

    PRNGNAME PRNG-[[:alnum:]_-]*[[:alnum:]]

    FLTRNAME FLTR-[[:alnum:]_-]*[[:alnum:]]

    IPV4 [0-9]+(\.[0-9]+){3,3}

    PRFXV4 {IPV4}\/[0-9]+

    PRFXV4RNG {PRFXV4}("^+"|"^-"|"^"{INT}|"^"{INT}-{INT})

    ENAMECHAR [^()<>,;:\\\"\.[\] \t\r]

    ENAME ({ENAMECHAR}+(\.{ENAMECHAR}+)*\.?)|(\"[^\"@\\\r\n]+\")

    DNAME [[:alnum:]_-]+

    //// Определения лексем >////////////////////////////////////////////////

    TKN_INT {SINT}

    TKN_INT {INT}:{INT} if each {INT} is two octets

    TKN_INT {INT}.{INT}.{INT}.{INT} if each {INT} is one octet

    TKN_REAL {REAL}

    TKN_STRING То же самое что и в языке СИ

    TKN_IPV4 {IPV4}

    TKN_PRFXV4 {PRFXV4}

    TKN_PRFXV4RNG {PRFXV4RNG}

    TKN_ASNO {ASNO}

    TKN_ASNAME (({ASNO}|peeras|{ASNAME}):)*{ASNAME}\

    (:({ASNO}|peeras|{ASNAME}))*

    TKN_RSNAME (({ASNO}|peeras|{RSNAME}):)*{RSNAME}\

    (:({ASNO}|peeras|{RSNAME}))*

    TKN_RTRSNAME (({ASNO}|peeras|{RTRSNAME}):)*{RTRSNAME}\

    (:({ASNO}|peeras|{RTRSNAME}))*

    TKN_PRNGNAME (({ASNO}|peeras|{PRNGNAME}):)*{PRNGNAME}\

    (:({ASNO}|peeras|{PRNGNAME}))*

    TKN_FLTRNAME (({ASNO}|peeras|{FLTRNAME}):)*{FLTRNAME}\

    (:({ASNO}|peeras|{FLTRNAME}))*

    TKN_BOOLEAN true|false

    TKN_RP_ATTR {NAME} if defined in dictionary

    TKN_WORD {NAME}

    TKN_DNS {DNAME}("."{DNAME})+

    TKN_EMAIL {ENAME}@({DNAME}("."{DNAME})+|{IPV4})

    Документ RFC-2280 [3] содержит раннюю версию языка RPSL.


    Содержание раздела