Протоколы 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>
<ipv4-address>
<address-prefix>
<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. |
Применение двух операторов диапазона последовательно является ошибкой (напр. 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>
<date> |
Дата представляется в виде восьми десятичных цифр вида YYYYMMDD, где YYYY отображает год, MM представляет месяц (01 - 12) и DD характеризует день месяца (01 - 31). Все даты, если не определено что-то иное, задаются в стандарте UTC. Например, 07 июля 1938 представляется в виде 19380707. |
<email-address> |
описано в RFC-822 [10]. |
<dns-name> |
описано в RFC-1034 [17]. | /TR>
<nic-handle> |
представляет собой уникальный идентификатор, используемый при маршрутизации, присвоении адресов и т.д. для того, чтобы обеспечить однозначную ссылку на контактную информацию. Классы person и role связывают указатели NIC с действительными именами людей и контактной информацией. |
<free-form> |
представляет собой последовательность ASCII-символов. |
<X-name> |
является именем объекта типа X. То есть <mntner-name> является именем объекта mntner. |
<registry-name> |
является именем регистратора IRR. |
Описание атрибута может содержать комментарий. Комментарий может размещаться где угодно в определении объекта, он начинается с символа "#" и завершается первым же символом перехода на новую строку.
Целые числа могут задаваться:
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 | опционный, многозначный |
| <email-address> | обязательный, многозначный |
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 |
3.3. Класс role
Класс role подобен объекту person. Однако вместо описания человека он описывает роль, которую выполняет один или несколько человек. Примеры включают в себя консультационные пункты, центры сетевого мониторинга, системных администраторов и т.д. Объект role особенно полезен, так как человек, выполняющий роль, может быть заменен, а сама роль остается неизменной.
Атрибуты класса role показаны на рис. .5. Атрибуты лиц nic-hdl и классы role используют совместно одно и то же пространство имен. Атрибут trouble объекта role может содержать дополнительную контактную информацию, которая может быть использована при возникновении проблемы в любом объекте, который ссылается на данный объект role. На рис. .6 показан пример объекта role.
Рис. .5. Атрибуты класса role
| role: | RIPE NCC Operations |
| 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 |
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 |
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> | опционный, многозначный |
На рис. .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 |
Атрибут 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
Рис. .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-".
Рис. .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 неявно определяют маршрутные наборы). Например: |
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'. Например |
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 |
Атрибут 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-".
Рис. .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 |
В следующем примере 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 } |
(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 | опционный, многозначный |
6.1. Атрибут import: Спецификация политики импорта
В RPSL политика импорта определяется двумя выражениями импортной политики. Каждое выражение импортной политики специфицируется с помощью атрибута import. Атрибут import имеет следующий синтаксис:
| import: | from <peering-1> [action <action-1>] . . . |
| from <peering-N> [action <action-N>] | |
| accept <filter> |
Например
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 } |
aut-num: AS1
| import: | from AS2 action pref = 1; |
| from AS3 action pref = 2; | |
| accept AS4 |
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 |
6.2. Атрибут export: Спецификация экспортной политики
Аналогично выражение экспортной политики специфицируется с помощью атрибута export. Атрибут export имеет следующий синтаксис:
| export: | to <peering-1> [action <action-1>] |
| . . . | |
| to <peering-N> [action <action-N>] | |
| announce <filter> |
Например
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>]
export: [protocol <protocol-1>] [into <protocol-2>]
Этот синтаксис используется там, где при описании политики других протоколов маршрутизации могут использоваться спецификации опционных протоколов, или для введения маршрутов одного протокола в другой протокол, или для многопротокольной маршрутной политики. Корректные имена протоколов определены в словаре. <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
В следующем примере, 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
Это не ошибка, хотя такая запись определенно не желательна. Чтобы убрать неопределенность, используется действие (action), соответствующее первой спецификации партнерства. То есть маршруты воспринимаются с предпочтением, равным 2. Это правило называется правилом порядка спецификаций.
Рассмотрим пример:
aut-num: AS1
где обе спецификации партнерства перекрывают маршруты 1.1.1.1-1.1.1.2, хотя вторая спецификация более специфична. Здесь также используется правило порядка спецификаций, выполняется только действие (action) "pref = 2". В действительности, вторая пара пиринговых действий бесполезна, так как первая пара пиринговых действий покрывает действие второй. Если требуется политика, при которой эти маршруты воспринимались данным пирингом с предпочтением 1 и с предпочтением 2 для всех остальных пирингов, пользователь должен специфицировать следующее:
aut-num: AS1
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
Рассмотрим два пиринга с 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> |
Семантика для оператора 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}; } |
Так как AS226 находится в as-foo и 128.9.0.0/16 заключен в 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; } |
| 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; } |
| 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; } |
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 | См. описание в тексте | опционный, многозначный |
Атрибут rp-attribute имеет следующий синтаксис:
| rp-attribute: | |
| <method-1>(<type-1-1>, ..., <type-1-N1> [, "..."]) | |
| ... | |
| <method-M>(<type-M-1>, ..., <type-M-NM> [, "..."]) |
Рис. .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 |
| rtr_set_name | |
| as_number | filter_set_name |
| peering_set_name |
За целочисленными и действительными предопределенными типами могут следовать младшие или старшие секции, которые позволяют специфицировать набор допустимых значений аргумента. Спецификация диапазона является опционной. Для представления целых действительных значений и символьных строк используется нотация языка Си (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> [,"..."]) |
7.1. Исходный словарь RPSL, пример действий политики и фильтры
dictionary: RPSL
rp-attribute: # меньшие значения соответствуют более высокому предпочтению pref
rp-attribute: # атрибут BGP multi_exit_discriminator
rp-attribute: # атрибут предпочтения места назначения BGP (dpa)
rp-attribute: # атрибут BGP aspath
typedef: # значение community в RPSL равно:
typedef: # список значений community { 40, no_export, 3561:70 }
rp-attribute: # атрибут BGP community
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 в их оповещения о маршрутах. |
as-set: AS3561:AS-PEERS
members: AS2, AS3
aut-num: AS3561
Рис. .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
Рис. .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>] |
| 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} |
Атрибут inject определяет, какие маршрутизаторы выполняют объединение, и когда они это делают. Синтаксис атрибута показан ниже:
| inject: | [at <router-expression>] ... |
| [action <action>] | |
| [upon <condition>] |
Все маршрутизаторы в <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 показаны два примера. В первом случае, объединение вводится в два маршрутизатора, каждый из которых устанавливает атрибут прохода 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 показан пример взаимодействия. При рассмотрении маршрутных объектов следует произвести обмен более специфическими префиксами 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. Заметим, что это рекурсивное определение.
Рис. .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 |
В следующем примере, маршрутизатор 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> |
Вместо одиночного партнера с помощью форм <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.
