Класс 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.
Класс 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
Класс 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>
Рис. .24. Атрибуты класса dictionary
Атрибут rp-attribute имеет следующий синтаксис:
| rp-attribute: | |
| <method-1>(<type-1-1>, ..., <type-1-N1> [, "..."]) | |
| ... | |
| <method-M>(<type-M-1>, ..., <type-M-NM> [, "..."]) |
| operator= | operator== |
| operator<<= | operator< |
| operator>>= | operator> |
| operator+= | operator>= |
| operator-= | operator<= |
| operator*= | operator!= |
| operator/= | operator() |
| operator.= | operator[] |
Атрибут 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-1>,..., |
| <type-1-N1> [,"..."]) | |
| ... | |
| MANDATORY | OPTIONAL <parameter-M>( | <type-M-1>,..., |
| <type-M-NM> [,"..."]) |
Класс 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 |
Это список адресных префиксов, заключенных в фигурные скобки '{' и '}'. Фильтр политики соответствует набору маршрутов, чей адресный префикс места назначения содержится в этом наборе. Например:
{ 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 |
Далее описываются операторы регулярных выражений. Эти операторы выполняются слева направо.
Унарные постфиксные операторы * + ? {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 |
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.
| Имя набора фильтров. |
Класс 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> | опционный, многозначный |
Рис. .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 с пиринг-группами
Класс 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> | обязательный, однозначный |
Рис. .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 |
Рис. 2. Пример объекта mntner.
Атрибуты descr, tech-c, admin-c, remarks, notify, mnt-by, changed и source являются атрибутами всех классов RPSL. Их синтаксис, семантика, а также статус mandatory (обязательный), optional (опционный), multi-valued (многозначный), или однозначный те же что и для всех классов RPSL. Единственным исключением является атрибут admin-c, который является обязательным для класса aut-num.
Класс 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> | обязательный, многозначный |
Рис. .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.
Класс 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 | опционный, многозначный |
| <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.
Класс 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
| 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
Класс 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> | опционный, многозначный |
Рис. .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 является дополнительным механизмом для косвенной спецификации членов набора.
Класс 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> | опционный, многозначный |
Рис. .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.
Классы 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.
Классы услуг
Данная статья не определяет типа запросов интегрированных услуг, однако реализации должны поддерживать услугу контролируемой нагрузки (Controlled-Load service) [4] и нулевую услугу (Null Service) [16].
Кодирование
Первоначально легальными значениями кодирования являются "Q" и "B". Эти кодировки описаны ниже. Кодирование "Q" рекомендуется для использования, когда большинство символов, которые нужно преобразовать, представлены в наборе ASCII; в противном случае, следует использовать "B"-кодирование. Несмортя ни на что программа, читающая почту, которая воспринимает кодировочные слова, должна быть способна обрабатывать любые кодировки для любых символьных наборов, которые она поддерживает.
В кодированном тексте может использоваться только субнабор печатных ASCII-символов. Символы SP и HT не допустимы, чтобы начало и конец кодировочного слова были выделены однозначно. Символ "?" используется в “кодировочном слове” для разделения различных частей этого слова друг от друга. По этой причине "?" не может появляться в секциях “кодировочного слова”. Другие символы могут также оказаться нелегальными в определенном контексте. Например, 'encoded-word' во 'фразе', предшествующей адресу в поле заголовка From не может содержать какие-либо специальные символы ("specials"), определенные в RFC-822. Наконец, некоторые другие символы также недопустимы в определенных контекстах, это связано с необходимостью обеспечить надежность пересылки сообщений через почтовые шлюзы.
"B"-кодирование автоматически отвечает этим требованиям. "Q"-кодирование допускает использование широкого перечня печатных символов в некритических позициях заголовка сообщения (например, в Subject), с ограниченным списком символов, допустимых в других полях.
4.1. "B"-кодирование
"B"-кодирование идентично "BASE64", описанному RFC-2045.
4.2. "Q"-кодирование
"Q"-кодирование подобно закавыченным строкам печатных символов ("Quoted-Printable"), описанным в RFC-2045. Оно создано, для того чтобы позволить читать текст, содержащему по большей части ASCII-символы, а алфавитно-цифровом терминале без декодирования.
| (1) |
Любой 8-битовый код может быть представлен с помощью символа "=", за которым следуют два шестнадцатеричных числа. Например, если бы используемый символьный набор был ISO-8859-1, символ "=" кодировался как "=3D", а пробел (SP) как "=20". (Для шестнадцатеричных чисел следует использовать верхний регистр "A" - "F".)
Кодирование информации Diff-Serv для слоя инкапсуляции исходящего E-LSP
В этом разделе рассмотрено, как заносить информацию Diff-Serv на уровне инкапсуляции MPLS для заданной метки, соответствующей исходящему E-LSP. Это требует, чтобы набор соответствий PHB-->Encaps формировался так, как это определено в разделе 3.4.
LSR сначала определяет набор соответствий PHB-->Encaps в контексте Diff-Serv, сопряженном с соответствующей меткой в NHLFE.
Кодирование информации Diff-Serv на уровне инкапсуляции
Эта фаза определяет, как заполняются поля, которые несут в себе информацию Diff-Serv в транспортируемых пакетах (например, MPLS поле EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority).
В данном разделе определено, как кодировать информацию Diff-Serv на уровне инкапсуляции MPLS для метки, соответствующей исходящему L-LSP. Это требует, чтобы набор PHB-->Encaps заполнялся, как это определено в разделе 4.4.
LSR сначала определяет набор PHB-->Encaps для контекста Diff-Serv, ассоциированного с соответствующей меткой в NHLFE и затем осуществляет соответствующее кодирование, как это специфицировано в разделах 3.5.1, 3.5.2, 3.5.3 и 3.5.4.
Кодирование информации Diff-Serv в транспортируемом IP-заголовке
Для записи информации Diff-Serv в IP заголовок передаваемого пакета, программа работает также как и в случае маршрутизатора, не поддерживающего MPLS IP Diff-Serv и заносит DSCP выходного PHB в поле DS.
В разделе 2.6 подробно описано, когда осуществляется запись Diff-Serv информации в IP заголовок в зависимости от поддерживаемого режима туннелирования Diff-Serv.
Кодирование информации Diff-Serv в поле передаваемой метки
В разделах 3.5 и 4.5 подробно описано, как следует выполнять кодирование информации Diff-Serv в транспортируемом стеке меток и/или инкапсулируемые данные MPLS, в зависимости от типа выходного LSP и инкапсуляции MPLS.
В разделе 2.6 описано, в какой записи стека меток следует записывать Diff-Serv данные в зависимости от поддерживаемой модели туннелирования.
Кодирование меток
Для того чтобы передавать стек меток вместе с пакетом, необходимо определить его конкретную структуру. Архитектура поддерживает несколько различных структур. Выбор структуры стека зависит от конкретного типа оборудования, используемого для переадресации пакетов.
2.25.1. MPLS-специфичное оборудование и/или программное обеспечение
Если для переадресации помеченных пакетов используется MPLS-специфичное оборудование и/или программы, наиболее очевидным способом представления стека меток является определение нового протокола, который будет использоваться в пределах прослойки между заголовками канального и сетевого уровней. Эта прокладка могла бы реально быть инкапсуляцией пакетов сетевого уровня. Она является протокольно независимой, такой, чтобы использоваться для инкапсуляции любого сетевого уровня. Следовательно, мы будем называть это как "общая MPLS-инкапсуляция".
MPLS-инкапсуляция будет в свою очередь инкапсулирована с привлечением протокола канального уровня. Общая MPLS-инкапсуляция специфицирована в [MPLS-SHIM].
Кодирование полосы
Кодирование частотного диапазона выполняется в объектах SENDER_TSPEC и FLOWSPEC. Определения значений, используемых для специальных сигнальных типов, смотри в [RFC3471]. Эти величины устанавливаются в поле Peak Data Rate (пиковая скорость передачи данных) объектов Int-Serv, смотри [RFC2210].
Кодирование полосы пропускания
Кодирование полосы пропускания осуществляется 32 битовым числом в формате IEEE для чисел с плавающей запятой (измеряется в байтах в сек). Для беспакетных LSP, полезно определить дискретные величины, чтобы идентифицировать полосу LSP. Некоторые типичные значения для запрошенной полосы перечислены ниже. Дополнительные значения будут определяться по мере необходимости. Значения кодов полосы ассоциируются с протоколами, смотри [RFC3473] и [RFC3472].
|
Тип сигнала |
Скорость обмена |
Значение (байт/сек) (IEEE плавающий формат) | |||
|
DS0 |
0.064 Mbps (Мбит/с) |
0x45FA0000 | |||
|
DS1 |
1.544 Mbps |
0x483C7A00 | |||
|
E1 |
2.048 Mbps |
0x487A0000 | |||
|
DS2 |
6.312 Mbps |
0x4940A080 | |||
|
E2 |
8.448 Mbps |
0x4980E800 | |||
|
Ethernet |
10.00 Mbps |
0x49989680 | |||
|
E3 |
34.368 Mbps |
0x4A831A80 | |||
|
DS3 |
44.736 Mbps |
0x4AAAA780 | |||
|
STS-1 |
51.84 Mbps |
0x4AC5C100 | |||
|
Fast Ethernet |
100.00 Mbps |
0x4B3EBC20 | |||
|
E4 |
139.264 Mbps |
0x4B84D000 | |||
|
FC-0 133M |
0x4B7DAD68 | ||||
|
OC-3 FC-0/STM-1 |
155.52 Mbps |
0x4B9450C0 | |||
|
FC-0 266M |
0x4BFDAD68 | ||||
|
FC-0 531M |
0x4C7D3356 | ||||
|
OC-12/STM-4 |
622.08 Mbps |
0x4C9450C0 | |||
|
GigE |
1000.00 Mbps |
0x4CEE6B28 | |||
|
FC-0 1062M |
0x4CFD3356 | ||||
|
OC-48/STM-16 |
2488.32 Mbps |
0x4D9450C0 | |||
|
OC-192/STM-64 |
9953.28 Mbps |
0x4E9450C0 | |||
|
10GigE-LAN |
10000.00 Mbps |
0x4E9502F9 | |||
|
OC-768/STM-256 |
39813.12 Mbps |
0x4F9450C0 |
Кодирование TLV для универсальных параметров
Существует несколько параметров, используемых более чем одним LDP сообщением. Кодирование TLV для этих совместно используемых параметров специфицировано в следующем разделе.
Кодирование TLV (тип-длина-значение)
LDP использует для кодирования информации, транспортируемой в LDP сообщениях, схему TLV (Type-Length-Value = тип-длина-значение).
LDP TLV кодируется как 2-октетное поле, которое использует 14 бит для спецификации типа и 2 бита для спецификации поведения, когда LSR не распознает поле тип, далее следуют 2 октета поля длины, поле значение имеет переменную длину.
U бит
Бит неизвестного TLV. При получении неизвестного TLV, если U=0, отправителю сообщения следует послать предупреждение, а сообщение должно быть проигнорировано; если U=1, неизвестное TLV молча игнорируется, а остальное сообщение обрабатывается, как будто неизвестного TLV нет.
F бит
Бит переадресации неизвестного TLV. Этот бит используется лишь в случае U=1 и сообщение LDP, содержащее неизвестный TLV, нужно переадресовать. Если F=0, неизвестный TLV не переадресуется вместе содержащим его сообщением; если F=1, неизвестный TLV переадресуется.
Тип
Определяет, как следует интерпретировать поле значение.
Длина
Специфицирует длину поля значение в октетах.
Значение
Строка октетов с длиной, определяемой полем длина, где закодирована информация согласно с содержимым поля тип.
Заметим, что не существует требований по выравниванию для первого октета TLV. Заметим также, что само поле значение может содержать TLV. То есть, TLV могут вкладываться друг в друга.
Схема кодирования TLV является общей. В принципе, все, что появляется в LDP PDU, может быть закодировано как TLV. Эта спецификация не использует всю универсальность схемы TLV. Она не используется там, где ее универсальность не нужна и где ее применение привело бы к большим не использованным полям. Это обычно места, где тип кодируемого значения известен, например, по его положению в сообщении или, когда длина значения фиксирована или просто известна.
Некоторые TLV, определенные для LDP аналогичны некоторым другим. Например, существует TLV общей метки, TLV метки ATM, и TLV Frame Relay; смотри разделы "TLV общей метки", "TLV метки ATM", и "TLV Frame Relay".
Спецификация присваивает значения типа TLV, таким как TLV метки, из смежного блока 16-битового пространства TLV типа.
Коды классов и C-типы
|
Номер класса |
Имя класса | ||
|
1 |
SESSION |
Типы классов или C-типы:
7 LSP туннель IPv4
8 LSP туннель IPv6
10 FILTER_SPEC
Типы классов или C-типы:
7 LSP туннель IPv4
8 LSP туннель IPv6
11 SENDER_TEMPLATE
Типы классов или C-типы:
7 LSP туннель IPv4
8 LSP туннель IPv6
16 RSVP_LABEL
Типы классов или C-типы:
1 Тип 1 Label
19 LABEL_REQUEST
Типы классов или C-типы:
1 Without Label Range
2 With ATM Label Range
3 With Frame Relay Label Range
20 EXPLICIT_ROUTE
Типы классов или C-типы:
1 Тип 1 Explicit Route
21 ROUTE_RECORD
Типы классов или C-типы:
1 Тип 1 Route Record
22 HELLO
Типы классов или C-типы:
1 Запрос
2 Отклик
207 SESSION_ATTRIBUTE
Типы классов или C-типы:
1 LSP_TUNNEL_RA
7 LSP туннель
7.3. Коды ошибок и глобально определенные субкоды ошибок
Ниже приведен список, расширяющий перечень кодов и значений ошибок, которые определены в [RFC2205].
Код
ошибки
Этот код ошибки имеет следующие глобально определенные значения субкодов ошибок:
1
Этот код ошибки имеет следующие глобально определенные значения субкодов ошибок:
1
Коды ошибок для Diff-Serv
В процедурах, описанных выше, некоторые ошибки должны объявляться Diff-Serv Error. Значение кода Diff-Serv Error равно 27. Ниже представлены коды ошибок для Diff-Serv:
Код
Коды ошибок для ERO и RRO
При обработке, описанной выше, определенные ошибки должны быть объявлены как " Routing Problem" или "Notify" (проблема маршрутизации или внимание). Значение кода ошибки "Routing Problem" равно 24; значение кода "Notify" равно 25. Определены следующие значения ошибок для кода ошибки Routing Problem:
Значение
Для кода ошибки Notify, 16 бит значения поля ошибки имеет вид:
ss00 cccc cccc cccc
Старшие биты определены при коде ошибки 1. (Смотри [1]). Когда ss = 00, определены следующие субкоды:
1 RRO для MTU слишком велико
2 RRO уведомление
3 Туннель локально восстановлен
Комбинации режимов запуска и рассылки меток
В таблице 2 приведены допустимые комбинации методов рассылки меток и запуска формирования LSP, которые были обсуждены в предыдущих разделах. (X) означает, что комбинация допустима, если LSR поддерживает смешанную переадресацию L2/L3.
Таблица 2. Допустимые комбинации методов запуска и рассылки меток
6. Перенос меток (Piggy-backing)
На рис. 9 (outgoing case) можно видеть, что вместо отправки двух отдельных сообщений, анонсирование метки может осуществляться посредством существующих управляющих сообщений. Для мультикастинга имеется два кандидата для транспортировки (piggy-back): Мультикастные маршрутные сообщения: протоколы, такие как PIM-SM и CBT, имеют сообщения Join, которые могут нести в себе мэппинг меток. Этот подход описан в [FARI]. Когда установлены различные протоколы для мультикастинг-маршрутизации, должны быть определены расширения для каждого из этих протоколов. Сообщения Resv RSVP: объект расширения мэппинга меток для RSVP, также применим в мультикастинге (предложено в [AWDU]).
За и против транспортировки меток с привлечением мультикаст маршрутных сообщений рассматриваются ниже. Такой вид транспортировки имеет следующие преимущества: Если анонсирование меток осуществляется мультикаст маршрутными сообщениями, тогда рассылка маршрутов и меток оказываются синхронизованными. Это исключает сложные ситуации типа "что я должен делать с меткой, если у меня пока нет подходящего рекорда в маршрутной таблице?". Это также минимизирует интервал между установлением мультикаст-маршрута и ассоциацией метки и маршрута. Число управляющих сообщений, необходимое для поддержания анонсирования меток, помимо используемых для осуществления мультикастной маршрутизации, равно нулю.
Можно отметить следующие недостатки такого типа транспортировки: В некоторых протоколах нет сообщений, с помощью которых можно доставлять сообщения о метках. Для таких протоколов предлагается [FARI] добавить периодически рассылаемые сообщения, которые сильно влияют на работу мультикастинг маршрутного протокола и сводят на нет выгоды совмещенной транспортировки (piggy-backing). Второе решение проблемы сосуществования состояний (смотри 3.4) не может быть применено в сочетании с совмещенной транспортировкой (с piggy-backing). Совмещенная транспортировка требует расширения мультикастного протокола маршрутизации, и следовательно становится менее привлекательной, если анонсирование меток требует поддержки нескольких мультикастных протоколов маршрутизации. Совмещенная транспортировка предполагает режим рассылки меток Downstream Unsolicited, это исключает несколько методов запуска процесса формирования LSP (смотри таблицу 2). LDP обычно работает поверх TCP, предполагая надежный обмен между узлами-партнерами. Совмещенная транспортировка сообщений о метках часто замещает надежный обмен на периодическую рассылку анонсирований меток. Из-за этого периодического анонсирования меток управляющий трафик (в байтах) увеличится. Если необходим механизм оповещения VCID [NAGA], он может быть реализован путем посылки сообщений LDP bind через вновь сформированный виртуальный канал VC. Для этого необходимо лишь одно сообщение. Такой метод не может комбинироваться с совмещенной транспортировкой, так как маршрутные сообщения посылаются до того как будет сформирован VC. Таким образом, необходим дополнительный диалоговый обмен, сокращающий выгоды совмещенной транспортировки.
Совмещенная транспортировка является лишь одним возможным компонентом мультикастного решения для.
Комментарии по поводу регистрации типа среды
Комментарии по поводу регистрации типа среды могут быть направлены членам сообщества IANA. Эти комментарии будут переданы "хозяину" типа среды. Комментаторы могут потребовать, чтобы их замечания были присовокуплены к материалам регистрации данного типа среды и, если IANA одобрит это, такая процедура будет произведена.
2.5. Расположение списка зарегистрированных типов среды
Материалы регистрации типа среды доступны через анонимный FTP сервер , а все зарегистрированные типы среды будут перечислены в периодически обновляемом документе "Assigned Numbers" RFC [в настоящее время STD-2, RFC-1700]. Описания типа среды и другие материалы могут быть также опубликованы в виде информационных RFC путем посылки документа по адресу "rfc-editor@isi.edu" [RFC-1543].
2.6. Процедура регистрации типа среды в IANA
IANA регистрирует типы среды, принадлежащие дереву IETF. Частные типы и типы среды производителя регистрируются IANA автоматически и без формального обсуждения, если выполнены следующие условия:
| (1) |
Типы среды должен функционировать как истинный формат среды. В частности, символьный набор или транспортное кодирование не могут быть зарегистрированы в качестве типа среды.
2.7. Управление изменением
Раз тип среды опубликован IANA, автор может потребовать изменения его описания. Запрос изменения оформляется также как и сама регистрация:
| (1) | Рассылка пересмотренной заявки регистрации через подписной лист ietftypes. |
| (2) | Ожидание в течение двух недель комментариев. |
| (3) | Публикация после формального обсуждения IANA, если это необходимо. |
Изменения следует делать лишь при
Изменения следует делать лишь при обнаружении серьезных упущений или ошибок в опубликованной спецификации.
Владелец типа содержимого может передать ответственность за него другому лицу или организации, проинформировав об этом IANA и список рассылки ietf-типов. Это может быть сделано без обсуждения.
IESG может переадресовать ответственность за определенный тип среды. Наиболее общим случаем является разрешение изменений в описании типа среды в ситуации, когда автор исходного документа умер, эмигрировал или стал недоступен и не может внести изменения крайне важные для сообщества пользователей.
Регистрации типа среды не могут быть аннулированы. Типы среды, которые не используются более, объявляются устаревшими (OBSOLETE) путем изменения их поля "intended use" (область применения). Такие типы среды будет помечены соответствующим образом и в списках, публикуемых IANA.
2.8. Регистрационный шаблон
To: ietf-types@iana.org
Subject: Registration of MIME media type XXX/YYY(Регистрация типа среды MIME)
| MIME media type name: | (Имя типа среды MIME) |
| MIME subtype name: | (Имя субтипа среды MIME) |
| Required parameters: | (Необходимые параметры) |
| Optional parameters: | (Опционные параметры) |
| Encoding considerations: | (Соображения по кодированию) |
| Security considerations: | (Соображения безопасности) |
| Interoperability considerations: | (Соображения совместимости) |
| Published specification: | (Опубликованная спецификация) |
| Applications which use this media type: | (Приложения, использующие данный тип среды) |
| Additional information: | (Дополнительная информация) |
| Magic number(s): | (Магические числа) |
| File extension(s): | (Расширение имени файла) |
| Macintosh File Type Code(s): | (Код типа файла Macintosh) |
| Person & email address to contact for further information: | (Контактный адрес) |
Intended usage:
(Одно из COMMON, LIMITED USE
или OBSOLETE)
Сюда может быть добавлена любая другая информация на усмотрение автора.
Коммуникация
Протокол COPS использует одно устойчивое TCP соединение между PEP и удаленным PDP. Реализация PDP на сервере должна прослушивать стандартный номер TCP-порта (COPS=3288 [IANA]). PEP ответственен за инициативу TCP-соединения с PDP. Положение удаленного PDP может быть сконфигурировано или получено с помощью механизма локации услуг [SRVLOC].
Если один PEP может поддерживать несколько типов клиентов, он может посылать соответствующее число сообщений Client-Open, адресованных PDP, через одно или более TCP-соединений. Аналогично, PDP с заданным адресом и номером порта может поддерживать один или более типов клиента. Для заданного набора поддерживаемых типов клиентов PDP может в каждом конкретном случае независимо воспринять или отвергнуть любой тип клиента. Если тип клиента отвергнут, PDP может перенаправить PEP на альтернативный PDP-адрес и TCP-порт для данного типа клиента через COPS. Различные TCP-порты могут использоваться для перенаправления PEP на другие программные реализации PDP, работающие на том же сервере.
Один PEP может сформировать соединения с несколькими PDP. Это может происходить, когда физически различные PDP поддерживают разные типы клиентов (как это показано на рис.).
Рис. .2. Пример с несколькими PDP.
Когда TCP-соединение разорвано, PDP ожидает, что необработанное состояние запроса, соответствующее обмену запрос/решение, будет удалено. Когда PEP регистрирует потерю соединения из-за таймаута, он должен послать сообщение Client-Close каждому открытому типу клиенту, содержащему объект <Error>, который указывает на код ошибки "Communication Failure". Кроме того, PEP должен постоянно пытаться контактировать с первичным PDP или, если не удается, с любым известным запасным PDP. В частности PEP должен проверить все доступные PDP, с которыми он был сконфигурирован до того, как он сможет установить соединение. Если PEP соединен с запасным PDP, а первичный PDP становится доступным, запасной PDP является ответственным за переадресацию PEP на первичный PDP (через сообщение <Client-Close>, содержащее объект <PDPRedirAddr>, идентифицирующий первичный PDP для каждого из типов клиента). В разделе 2.5 рассмотрены детали синхронизации PEP и PDP.
Коммутация по длине волны
Специальным случаем l -коммутации является переключение по диапазонам длин волн. Волновой диапазон представляет собой набор смежных длин волн, которые могут быть все вместе переключены на новый волновой диапазон. По причине оптимизации для оптического коммутатора может быть желательно переключать несколько длин волн одним блоком. Это может уменьшить искажение для индивидуальных длин волн и позволить более плотное их размещение индивидуальных. Метка волнового диапазона определена для поддержки этого специального случая.
Переключение волновых диапазонов вводит естественно другой уровень иерархии меток и волновой диапазон, как таковой рассматривается также как и все другие метки высокого уровня.
Поскольку это касается протоколов MPLS, нет большой разницы между меткой диапазона длин волн и меткой длины волны за исключением того, что семантически диапазон длин волн может быть поделен между несколькими метками, ответственными за мультиплексирование, например, по времени.
Конец LSP и прокси конец LSP
LSR R считается конечным LSR LSP для адресного префикса X, если и только если выполнено одно из следующих условий:
1. R имеет адрес Y, такой что X является адресным префиксом в маршрутной таблице R, который наилучшим образом соответствует Y, или
2. R содержит в своей маршрутной таблице один или более адресных префиксов Y, таких что X является подходящей начальной субстрокой Y, но "предыдущие шаги LSP" R для X не содержат никакого адресного префикса Y. То есть, R является "точкой ликвидации агрегатирования" для адресного префикса X .
LSR R1 считается "прокси концом LSP" LSR для адресного префикса X, если и только если:
1. Следующим шагом R1 для X служит R 2, а R1 и R2 не являются партнерами по рассылке меток с точки зрения X (возможно потому, что R2 не поддерживает MPLS), или
2. R1 был сконфигурирован, чтобы работать в качестве прокси конца LSP для X
Определение LSP позволяет концу LSP быть узлом, который не поддерживает MPLS. В этом случае предпоследний узел в LSP является прокси выходным.
Конфиденциальность
LDP не предоставляет механизма защиты конфиденциальности при рассылке меток. Требования секретности протоколов рассылки меток полностью идентичны требованиям к протоколам, рассылающим маршрутную информацию. Путем обеспечения механизма гарантии аутентичности и целостности информации своих сообщений LDP, гарантирует уровень секретности, который, по крайней мере, также хорош, как и уровень безопасности традиционных маршрутных протоколов.
Можно спорить о том, что рассылка меток требует конфиденциальности, чтобы противостоять угрозе фальсификации меток. Однако конфиденциальность не защитит против фальсификации меток, так как пакеты несут их в открытом виде. Более того, атаки фальсификации меток могут осуществляться без знания FEC сопряженного с меткой.
Чтобы избежать атак фальсификации меток, необходимо гарантировать то, что пакеты помечены LSR, достойными доверия, и что о метках, вставленных в пакеты, корректно проинформированы заинтересованные LSR.
Консервативный режим сохранения метки
В режиме Downstream Unsolicited, анонсирование меток всем маршрутизаторам может осуществляться всеми партнерами LSR. При использовании консервативного сохранения меток, анонсированные метки сохраняются, только если они будут использоваться для переадресации пакетов (т.e., если они получены от корректного следующего узла маршрута). При работе в режиме Downstream on Demand LSR будет запрашивать метку только у LSR следующего шага согласно действующей маршрутизации. Так как режим Downstream on Demand
в основном используется, когда сохранение меток желательно (напр., ATM коммутатор с ограниченной зоной коммутаций), он обычно используется в режиме консервативного сохранения меток.
Главное преимущество консервативного режима заключается в том, что только метки, используемые для переадресации данных, выделяются и поддерживаются. Это особенно важно в LSR, где пространство меток существенным образом ограничено, как это имеет место в ATM коммутаторах. Недостатком консервативного режима является то, что если для заданного адресата маршрутизация меняет следующий шаг, должна быть получена новая метка, прежде чем пакет будет переадресовываться.
Контактная информация
Классы mntner, person и role, а также атрибуты admin-c, tech-c, mnt-by, changed и всех классов характеризуют контактную информацию. Класс mntner специфицирует также аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать другие объекты. Эти классы не специфицируют маршрутную политику и каждый реестр может иметь различные или дополнительные требования. В документе "Routing Policy System Security" [20] описана модель аутентификации и авторизации.
Контроль петель
В non-TTL LSP сегменте, по определению, TTL не может использоваться для предотвращения петель маршрута. Важность контроля циклических путей зависит от конкретного оборудования, используемого для реализации LSR-функций в пределах non-TTL LSP сегмента.
Предположим, например, что для коммутационных целей в MPLS используются ATM-переключатели, с метками, транспортируемыми в поле VPI/VCI. Так как ATM коммутаторы не могут декрементировать TTL, здесь нет защиты против появления циклических маршрутов. Если оборудование ATM способно обеспечить хороший доступ к буферному пулу для входящих ячеек, имеющих разные значения полей VPI/VCI, петли не могут иметь негативного эффекта на остальной трафик. Если оборудование ATM не может обеспечить хороший доступ к буферам, тогда переходные петли могут вызвать серьезную деградацию эксплуатационных характеристик LSR.
Даже если может быть обеспечен хороший доступ к буферу, целесообразно иметь некоторые средства детектирования петель, которые имеют длину больше определенной. Кроме того, даже когда TTL и/или справедливая организация очередей в виртуальных каналах предоставляет возможности для сохранения петель, может быть желательно, где возможно избегать установления LSP с петлями. Все LSR, которые могут быть связаны с сегментами non-TTL LSP будут должны поддерживать общую методику детектирования петель; однако, использование детектирования петель является опционным. Методика детектирования петель специфицирована в [MPLS-ATM] и [MPLS-LDP].
Краткий обзор протокола
С точки зрения клиента, DHCP является расширением механизма BOOTP. Такая схема позволяет существующим BOOTP-клиентам успешно сотрудничать с DHCP-серверами без необходимости изменения стартовой программы клиента. В RFC-1542 [2] детализировано взаимодействие между BOOTP- и DHCP-клиентами и серверами [9]. Имеется несколько новых, опционных операций, которые оптимизируют взаимодействие между DHCP-клиентами и серверами (смотри разделы 3 и 4).
На рис. .1 представлен формат сообщения DHCP, а в таблице 1 перечислены поля этого сообщения. Числа в скобках указывают размер каждого из полей в октетах.
Существует два принципиальных отличия между DHCP и BOOTP. Во-первых, DHCP определяет механизмы, через которые клиентам на определенное время могут быть присвоены сетевые адреса, позволяя последовательное присвоение сетевого адреса различным клиентам. Во-вторых, DHCP предоставляет механизм, который позволяет клиенту получить все необходимые им для работы конфигурационные параметры.
DHCP вводит небольшое изменение в терминологию, имеющее целью прояснить значение одного из полей. Поле "vendor extensions" в BOOTP переименовано в поле "опции" в DHCP. Аналогично, помеченные информационные элементы, использованные в поле BOOTP "vendor extensions", которые именовались как "расширения производителя", теперь называются просто "опции".
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| op (1) | htype (1) | hlen (1) | Шаги (1) | ||||||||||||||||||||||||||||
| xid (4) | |||||||||||||||||||||||||||||||
| secs (2) | Флаги (2) | ||||||||||||||||||||||||||||||
| ciaddr (4) | |||||||||||||||||||||||||||||||
| yiaddr (4) | |||||||||||||||||||||||||||||||
| siaddr (4) | |||||||||||||||||||||||||||||||
| chaddr (4) | |||||||||||||||||||||||||||||||
chaddr (16)
DHCP определяет новую опцию 'client identifier', которая используется для прямой передачи идентификатора клиента DHCP серверу. Это изменение исключает перегрузку поля 'chaddr' в сообщениях BOOTP, где 'chaddr' используется как в качестве аппаратного адреса для пересылки сообщений откликов BOOTP, так и в качестве идентификатора клиента. Идентификатор клиента представляет собой непрозрачный ключ, который не должен интерпретироваться сервером; например, идентификатор клиента может содержать аппаратный адрес, идентичный тому, который лежит в поле 'chaddr', или он может содержать другой идентификатор типа, такой как DNS-имя. Идентификатор клиента, выбранный DHCP клиентом, должен быть уникальным для субсети, к которой он подключен. Если клиент использует идентификатор клиента в одном сообщении, он должен использовать тот же идентификатор во всех последующих сообщениях, чтобы гарантировать корректную идентификацию клиента всеми серверами. DHCP определяет поле 'siaddr' как адрес сервера для использования во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле 'siaddr', если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции 'server identifier'. Назначения полей заголовка представлены в таблице 1.
Таблица 1. Описание полей сообщения DHCP
| Поле | Байт | Описание |
| op | 1 | Код операции сообщения / тип сообщения. |
| 1 | = BOOTREQUEST, 2 = BOOTREPLY | |
| htype | 1 | Тип аппаратного адреса, смотри раздел ARP в RFC "Assigned Numbers"; например, '1' для 10 мегабитного Ethernet. |
| Hlen | 1 | Длина аппаратного адреса (например, '6' для 10 мегабитного Ethernet). |
| Шаги | 1 | Клиент устанавливает это поле равным нулю, поле используется опционно агентами транспортировки, когда загрузка осуществляется через посредника. |
| Xid | 4 | ID-транзакции, случайное число, выбираемое клиентом, и используемое как клиентом, так и сервером для установления соответствия между запросами и откликами. |
| Secs | 2 |
Заполняется клиентом, число секунд с момента начала запроса адреса или рестарта процесса.
В случае, когда клиент использует DHCP для начальной конфигурации (прежде чем программа клиента TCP/IP полностью сконфигурирована), DHCP требует использования клиентского программного обеспечения TCP/IP в вольной интерпретации RFC-1122. Программа TCP/IP должна принять и передать IP-уровню любой IP-пакет, доставленный по аппаратному адресу клиента, до того как IP-адрес будет сконфигурирован; DHCP-серверы и агенты транспортировки BOOTP могут быть неспособны доставить DHCP-сообщения клиентам, которые не могут принимать уникастные дейтограммы, до того, как программа TCP/IP сконфигурирована должным образом.
Для того чтобы работать с клиентами, которые не могут воспринимать уникастные IP-дейтограммы до того, как будет сконфигурирована программа TCP/IP, DHCP использует поле 'флаги' [21]. Самый левый бит определен как флаг BROADCAST (B). Остающиеся биты поля флаги зарезервированы на будущее. Они должны быть установлены равными нулю клиентами и игнорироваться серверами и агентами транспортировки. На рис. 2 показан формат поля флаги.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
B
MBZ: должно быть равно нулю (must be zero; зарезервировано на будущее)
Рис. .2: Формат поля 'флаги'
2.1. Основные конфигурационные параметры
Первым видом сервиса, предоставляемого DHCP, является запоминание сетевых параметров для клиента. Модель DHCP памяти характеризуется записями ключ - значение для каждого клиента, где ключ представляет собой некоторый уникальный идентификатор (например, номер IP-субсети и уникальный идентификатор в пределах субсети), а значение содержит набор конфигурационного параметров клиента.
Например, ключ может представлять собой пару (номер IP-субсети, аппаратный адрес), чтобы допустить повторное или даже одновременное применение одних и тех же аппаратных адресов в различных субсетях. Заметим, что должен быть определен тип "аппаратного адреса" с тем, чтобы можно было решить проблему возможного дублирования при изменении порядка бит в случае смешения типов оборудования. В качестве альтернативы, ключ может представлять собой пару (номер IP-субсети, имя ЭВМ), позволяя серверу присвоить параметры DHCP-клиенту, который переместился в другую субсеть или сменил свой аппаратный адрес (возможно из-за выхода из строя и замены сетевого интерфейса). Протокол определяет то, что ключ представляет собой (номер IP-субсети, аппаратный адрес), если только клиент не прелагает идентификатор в явном виде, используя опцию 'client identifier'. Клиент может запросить DHCP-сервис, чтобы получить свои конфигурационные параметры. Интерфейс клиента к депозитарию конфигурационных параметров реализуется с помощью протокольных сообщений запроса и откликов серверов, несущих в себе конфигурационные параметры.
2.2. Динамическое выделение сетевых адресов
Вторым видом сервиса, предоставляемым DHCP, является временное или постоянное выделение клиенту сетевого (IP) адреса. Основной механизм для динамического присвоения сетевых адресов достаточно прост: клиент запрашивает использование адреса на определенный период времени. Механизм выделения адреса (ассоциация DHCP-серверов) гарантирует, что адрес в течение оговоренного времени не будет использован для других целей, и пытается прислать тот же сетевой адрес всякий раз, когда клиент его запрашивает. Клиент может расширить это время последующими запросами. Клиент может послать серверу сообщение об освобождении адреса, когда клиент более не нуждается в этом адресе. Клиент может запросить постоянное присвоение адреса, потребовав бесконечное значение времени выделения адреса. Даже при "постоянном" выделении адресов, сервер может определить большой, но не бесконечный срок аренды адреса, чтобы позволить детектирование факта, что клиент перестал работать.
При некоторых обстоятельствах может оказаться необходимым повторно присваивать сетевые адреса из-за отсутствия свободных адресов. При таких условиях, механизм выделения будет повторно присваивать адреса, чье время действительности истекло. Сервер должен использовать информацию, которая доступна в конфигурационном депозитарии, чтобы выбрать адрес, который может быть использован повторно. Например, сервер может выбрать последний из присвоенных адресов. В качестве проверки совместимости сервер должен проверить повторно используемые адреса, прежде чем их повторно пускать в оборот. Это может быть, например, контроль посредством ICMP эхо-запроса, а клиент должен проверить вновь полученный адрес, например, посредством ARP.
3. Протокол клиент-сервер
DHCP использует формат сообщение BOOTP, определенный в RFC-951 и представленный в таблице 1 и на рис. 1. Поле 'op' каждого сообщения DHCP, посланного клиентом серверу, содержит BOOTREQUEST. В поле 'op' DHCP-сообщения, посланного сервером клиенту, заносится BOOTREPLY.
Первые 4 октета поля 'опции' сообщения DHCP содержат (десятичные) коды 99, 130, 83 и 99, соответственно (это те же коды (magic cookie), что определены в RFC-1497 [17]). Остальная часть поля 'опции' состоит из списка помеченных параметров, которые называются "опции". Все "vendor extensions" перечисленные в RFC-1497, являются также опциями DHCP. Документ RFC-1533 предоставляет полный набор опций, определенных для использования с DHCP.
Несколько опций уже определено. Одной из них является опция "DHCP message type", которая должна включаться во все DHCP-сообщения. Эта опция определяет тип DHCP-сообщения. Дополнительные опции могут допускаться, требоваться или не разрешаться в зависимости от типа DHCP-сообщения.
В рамках данного документа, DHCP-сообщения, которые содержат опцию 'тип сообщения DHCP' будут восприниматься согласно типу сообщения; например, сообщение DHCP с типом опции равным 1 будет восприниматься как сообщение "DHCPDISCOVER".
3.1. Взаимодействие клиента и сервера при выделении сетевого адреса
Ниже рассматривается протокольный обмен между клиентом и сервером DHCP-сообщениями, описанными в таблице 2. Временная диаграмма на рис. 3 демонстрирует типичную схему взаимодействия клиента и сервера. Если клиент уже знает свой адрес, некоторые шаги могут быть опущены; такое упрошенное взаимодействие описано в разделе 3.2.
| 1. |
Клиент широковещательно пересылает сообщение DHCPDISCOVER по локальной физической субсети. Сообщение DHCPDISCOVER может включать опции, которые предлагают значения для сетевого адреса и длительности его использования. Агент транспортировки BOOTP может передать сообщение DHCP-серверам, которые размещены за пределами данной физической субсети.
| Сообщение | Использование |
| DHCPDISCOVER | Клиент посылает сообщение широковещательно, чтобы обнаружить доступный сервер. |
| DHCPOFFER | Посылается сервером клиенту в ответ на сообщение DHCPDISCOVER и содержит предложение по конфигурационным параметрам. |
| DHCPREQUEST | Сообщение клиента серверу либо (a) запрашивающее параметры от одного сервера и неявно отвергающее предложения других серверов, (b) подтверждающее корректность ранее присвоенного адреса после, например, перезагрузки системы, или (c) запрос расширения времени жизни конкретного сетевого адреса. |
| DHCPACK | Посылается сервером клиенту и содержит конфигурационные параметры, включая присвоенный сетевой адрес. |
| DHCPNAK | Посылается сервером клиенту, сообщая о том, что сетевой адрес не корректен (например, клиент переместился в новую субсеть), или время использования адреса клиентом истекло |
| DHCPDECLINE | Клиент и сервер обнаружили, что сетевой адрес уже используется. |
| DHCPRELEASE | Посылается клиентом серверу с целью отказа от сетевого адреса и аннулирует оставшееся время действия адреса. |
| DHCPINFORM | Посылается клиентом серверу с просьбой о локальных конфигурационных параметрах; клиент уже имеет полученный извне сетевой адрес. |
Рис. 3. Временная диаграмма обмена сообщениями между DHCP-клиентом и сервером в ходе присвоения нового сетевого адреса
3. Клиент получает одно или более сообщений DHCPOFFER от одного или более серверов. Клиент может предпочесть дождаться нескольких откликов. Клиент выбирает один сервер, которому пошлет запрос конфигурационных параметров, согласно предложению, содержащемуся в сообщении DHCPOFFER. Клиент широковещательно отправляет сообщение DHCPREQUEST, которое должно содержать опцию 'server identifier', чтобы указать, какой сервер им выбран, и которое может включать в себя другие опции, специфицирующие желательные конфигурационные значения. Опция 'requested IP-адрес' в сообщении сервера DHCPOFFER должна содержать значение 'yiaddr'. Сообщение DHCPREQUEST посылается широковещательно агентами транспортировки DHCP/BOOTP. Для того чтобы быть уверенным, что любой агент транспортировки BOOTP направляет сообщение DHCPREQUEST тому же набору DHCP-серверов, которые получили исходное сообщение DHCPDISCOVER, сообщение DHCPREQUEST должно использовать то же значение поля 'secs' заголовка DHCP-сообщения и должно посылаться по тому же широковещательному IP-адресу, что и оригинальное сообщение DHCPDISCOVER. Клиент реализует таймаут и повторно посылает сообщение DHCPDISCOVER, если не получает сообщений DHCPOFFER.
| 4. |
Серверы получают широковещательное сообщение DHCPREQUEST от клиента. Серверы, не выбранные сообщением DHCPREQUEST, используют сообщение как уведомления о том, что клиент отверг предложение сервера. Сервер, выбранный сообщением DHCPREQUEST, осуществляет запись конфигурационного набора клиента в постоянную память и реагирует сообщением DHCPACK, содержащим конфигурационные параметры для клиента, приславшего запрос. Комбинация 'client identifier' или 'chaddr' и присвоенного сетевого адреса представляет собой уникальный идентификатор для времени действия адреса клиента и используется клиентом и сервером для идентификации этого времени в любом DHCP-сообщения. Любые конфигурационные параметры в сообщении DHCPACK не должны конфликтовать с параметрами из сообщения DHCPOFFER, на которое клиент откликается. Сервер не должен проверять предложенный сетевой адрес. В поле 'yiaddr' сообщений DHCPACK записывается выбранный сетевой адрес.
Если выбранный сервер не может адекватно реагировать на сообщение DHCPREQUEST (например, запрошенный сетевой адрес уже выделен), сервер должен реагировать посылкой сообщения DHCPNAK.
Сервер должен пометить адрес, предложенный клиенту в сообщении DHCPOFFER, как доступный, если сервер не получил от клиента никакого сообщения DHCPREQUEST.
| 6. | Клиент может решить отказаться от аренды сетевого адреса путем посылки серверу сообщения DHCPRELEASE. Клиент идентифицирует набор параметров, от которого он отказывается, с помощью своего идентификатора, или 'chaddr' и сетевого адреса в сообщении DHCPRELEASE. Если клиент использовал идентификатор клиента, когда он получил набор конфигурационных параметров, клиент должен использовать тот же идентификатор клиента (client identifier) в сообщении DHCPRELEASE. |
3.2. Взаимодействие клиента и сервера при повторном использовании ранее выделенных сетевых адресов
Если клиент помнит и желает использовать выделенный ранее сетевой адрес, он может опустить некоторые шаги, рассмотренные в предыдущем разделе. Временная диаграмма на рис. 4 показывает типовое взаимодействие клиента и сервера в случае повторного использования старого сетевого адреса.
| 1. | Клиент широковещательно рассылает по локальной субсети сообщение DHCPREQUEST. Сообщение включает в себя сетевой адрес клиента в опции 'requested IP-адрес'. Раз клиент не получил свой сетевой адрес, он не должен заполнять поле 'ciaddr'. Агенты транспортировки BOOTP передают сообщение DHCP-серверам за пределами данной субсети. Если клиент использует 'client identifier' для получения своего адреса, клиент должен использовать тот же 'client identifier' в сообщении DHCPREQUEST. |
| 2. | Серверы, которые знают конфигурационные параметры клиента, откликаются сообщением DHCPACK. Серверы не должны проверять, используется ли уже сетевой адрес клиента; клиент может реагировать посылкой запроса эхо ICMP. |
Рис. .4. Временная диаграмма обмена сообщениями между DHCP-клиентов и сервером при повторном присвоении ранее использованного сетевого адреса
Если запрос клиента не корректен (например, клиент переместился в другую субсеть), серверы должны реагировать посылкой клиенту сообщения DHCPNAK. Серверы не должны откликаться, если их информация не абсолютно надежна. Например, сервер, который идентифицирует запрос для набора параметров, который принадлежит другому серверу, и имеет истекший срок действия, сервер не должен реагировать сообщением DHCPNAK, если только серверы не используют явно механизм поддержания когерентности.
Если 'giaddr' в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент может не иметь правильного сетевого адреса или сетевой маски, и клиент может не отвечать на ARP-запрос. В противном случае, сервер должен послать сообщение DHCPNAK по IP-адресу транспортного агента BOOTP, записанного в 'giaddr'. Транспортный агент, в свою очередь, переадресует сообщение непосредственно по аппаратному адресу клиента, так что DHCPNAK будет доставлен, даже если клиент переместился в другую сеть.
| 3. | Клиент получает сообщение DHCPACK, содержащее конфигурационные параметры. Клиент выполняет окончательную проверку параметров (как в разделе 3.1), и отмечает время действия конфигурации, специфицированное в сообщении DHCPACK. Значение времени действия неявно задается 'client identifier' или 'chaddr' и сетевым адресом. С этого момента клиент считается сконфигурированным. |
Если клиент обнаруживает, что IP-адрес в сообщении DHCPACK уже использован, клиент должен послать сообщение DHCPDECLINE серверу и повторно запустить процесс конфигурации, послав запрос на новый сетевой адрес. Это действие соответствует переходу клиента в состояние INIT на диаграмме состояния DHCP, которая описана в разделе 4.4.
Если клиент получает сообщение DHCPNAK, он не может повторно использовать свой запомненный сетевой адрес. Он должен вместо этого запросить новый адрес путем повторного запуска конфигурационного процесса. Это действие соответствует переходу клиента в состояние INIT на диаграмме состояния DHCP.
Клиент выполняет таймаут и повторно посылает сообщение DHCPREQUEST. Если клиент не получает ни сообщения DHCPACK, ни DHCPNAK, клиент, согласно алгоритму из раздела 4.1, повторно посылает сообщение DHCPREQUEST. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго. Например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно передать сообщение DHCPREQUEST четыре раза при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент после повторной пересылки не получил ни сообщения DHCPACK, ни DHCPNAK, он может решить использовать присвоенный ранее сетевой адрес и конфигурационные параметры вплоть до истечения срока их действия. Это соответствует переходу в состояние BOUND на диаграмме состояний клиента, показанной на рис. 5.
| 4. | Клиент может решить отказаться от сетевого адреса путем посылки серверу сообщения DHCPRELEASE. Клиент идентифицирует набор параметров, от которого он отказывается, с помощью 'идентификатора клиента', или 'chaddr' и сетевого адреса в сообщении DHCPRELEASE. |
Заметим, что в случае, когда клиент сохраняет свой сетевой адрес локально, при корректном прерывании сессии (shutdown) он не должен отказываться от конфигурационного набора. Только в случае, когда клиенту нужно отказаться от конфигурационного набора, например, клиент намеривается перейти в другую субсеть, он будет должен послать сообщение DHCPRELEASE.
3.3. Интерпретация и представление значений времени
Клиент получает сетевой адрес на определенный период времени (который может быть бесконечным). В данном протоколе время измеряется в секундах. Значение времени 0xffffffff зарезервировано для обозначения бесконечности.
Так как клиент и сервер могут не иметь синхронизованных часов, значения времени в DHCP-сообщения являются относительными, и должны интерпретироваться с учетом показаний локальных часов клиента. Время измеряется в секундах и представляется в виде 32-битных кодов без знака. Это позволяет описывать относительные интервалы времени от 0 до примерно 100 лет, что вполне приемлемо для целей протокола DHCP.
Алгоритм интерпретации времени действия конфигурационного набора, представленный в предыдущем параграфе, предполагает, что часы клиента и сервера стабильны относительно друг друга. Если имеется относительный дрейф этих часов, сервер может считать время действия конфигурационного набора исчерпанным, а клиент - нет. Чтобы компенсировать такого рода эффект, сервер может послать клиенту значение времени действия короче того, которое он записывает в свою базу данных.
3.4. Получение параметров при внешне заданных адресах
Если клиент получил сетевой адрес каким-то другим образом (например, при ручной конфигурации), он может использовать запрос-сообщение DHCPINFORM, чтобы получить другие локальные конфигурационные параметры. Серверы, получив сообщение DHCPINFORM, формируют сообщение DHCPACK с любыми конфигурационными параметрами, приемлемыми для клиента. При этом сетевой адрес не присваивается, не проверяется существующий набор параметров, не заполняется 'yiaddr' и не задаются параметры времени действия конфигурационного набора. Серверы должны послать ответ DHCPACK по уникастному адресу, заданному в поле 'ciaddr' сообщения DHCPINFORM.
Сервер в целях совместимости должен проверить сетевой адрес в сообщении DHCPINFORM, но не должен проверять существующее значение времени действия конфигурационного набора. Сервер формирует сообщение DHCPACK, содержащее конфигурационные параметры для клиента, приславшего запрос, и посылает сообщение DHCPACK непосредственно клиенту.
3.5. Параметры клиента в DHCP
Не все клиенты требуют инициализации всех параметров, перечисленных в приложении A. Используются два способа сокращения числа параметров, пересылаемых от сервера клиенту. 1. Большинство параметров имеет значения по умолчанию, определенные в Host Requirements RFC; если клиент не получил параметров от сервера, которые переписывают значения по умолчанию, клиент использует эти значения. 2. В своем исходном сообщении DHCPDISCOVER или DHCPREQUEST, клиент может предоставить серверу список специфических параметров, которые ему нужны. Если клиент включает список параметров в сообщение DHCPDISCOVER, он должен включать этот список в любое последующее сообщение DHCPREQUEST.
Клиент должен включить опцию 'maximum DHCP message size', чтобы позволить серверу знать, максимальный размер его DHCP-сообщений. Параметры, присланные в ответ клиенту, могут иметь размер больший, чем выделено для опций в сообщении DHCP. В этом случае, два дополнительных опционных флага (которые должны присутствовать в поле 'опции' сообщения) индицируют, что для опций должны использоваться поля 'file' и 'sname'.
Клиент может проинформировать сервер о том, в каких конфигурационных параметрах заинтересован клиент, включив опцию 'parameter request list'.
Кроме того, клиент может предложить значения для сетевого адреса и времени его действия в сообщении DHCPDISCOVER. Клиент может включить опцию 'requested IP-адрес', чтобы предложить конкретное значение IP-адреса, которое он хотел бы получить, и может включить опцию 'IP-адрес lease time', чтобы предложить предпочтительное значение времени действия конфигурационного набора. Другие опции, представляющие рекомендации по конфигурационным параметрам, допустимы в сообщении DHCPDISCOVER или DHCPREQUEST. Однако дополнительные опции могут игнорироваться серверами, и разные серверы могут прислать различные отклики на одни и те же опции. Опция 'requested IP-адрес' должна заноситься только в сообщение DHCPREQUEST, когда клиент проверяет конфигурационные параметры, полученные ранее. Клиент заполняет поле 'ciaddr', только когда он имеет корректный IP-адрес в состояниях BOUND, RENEWING или REBINDING.
Если сервер получает сообщение DHCPREQUEST с некорректным 'запрошенным IP-адресом', он должен прислать клиенту сообщение DHCPNAK и может уведомить о проблеме системного администратора. Сервер может включить код ошибки в опцию сообщения.
3.6. Применение DHCP для клиентов с несколькими интерфейсами
Клиент с несколькими сетевыми интерфейсами должен использовать DHCP для получения конфигурационных параметров через каждый из интерфейсов независимо.
3.7. Когда клиентам следует использовать DHCP?
Клиент должен использовать DHCP для нового запроса или верификации своего IP-адреса и сетевых параметров всякий раз, когда локальные конфигурационные параметры изменились; например, во время перезагрузки системы или после сетевого разрыва, так как локальная сетевая конфигурация может измениться без информирования об этом клиента или пользователя.
Если клиент знает предыдущий сетевой адрес и не может контактировать с локальным DHCP-сервером, клиент может продолжать использовать предыдущий сетевой адрес до тех пор, пока время действия адреса не истечет. Если время действия исчерпано до того, как клиент смог контактировать с DHCP-сервером, клиент должен немедленно прекратить использование текущего сетевого адреса и может проинформировать о данной проблеме локального пользователя.
4. Спецификация протокола DHCP для системы клиент-сервер
В этом разделе, мы предполагаем, что DHCP-сервер имеет блок сетевых адресов, из которого он может удовлетворять запросы. Каждый сервер поддерживает базу данных присвоенных адресов и времен их действия.
4.1. Формирование и посылка сообщений DHCP
Клиенты и серверы DHCP конструируют DHCP-сообщения путем заполнения полей в секции сообщения с фиксированным форматом и присоединяя помеченные информационные элементы переменной длины в секции опций. Область опций включает в себя 4-октетную секцию 'magic cookie' (которая описана в разделе 3), за которой следуют собственно опции. Последняя опция должна быть всегда опцией 'end'.
DHCP использует в качестве транспортного протокола UDP. DHCP-сообщения от клиента к серверу посылаются через порт DHCP-сервера (67), а DHCP-сообщения от сервера к клиенту посылаются через порт DHCP-клиента (68). Сервер с несколькими сетевыми адресами (например, ЭВМ с несколькими сетевыми интерфейсами) может использовать для передачи исходящего DHCP-сообщения любой из своих сетевых адресов.
Поле 'server identifier' используется как для идентификации DHCP-сервера в DHCP-сообщении, так и в качестве адреса места назначения при передаче информации от клиента серверу. Сервер с несколькими сетевыми адресами должен быть готов воспринимать любой из своих сетевых адресов в качестве идентификатора в DHCP-сообщении. Чтобы адаптироваться к потенциально не полной сетевой коннективности, сервер должен выбрать адрес в качестве 'server identifier', который по информации сервера доступен со стороны клиента. Например, если DHCP-сервер и DHCP-клиент подключены к одной субсети (т.e., поле 'giaddr' в сообщении от клиента равно нулю), сервер должен выбрать свой IP-адрес, используемый для передачи в пределах субсети в качестве 'server identifier'. Если сервер использует несколько IP-адресов в субсети, он может воспользоваться любым таким адресом. Если сервер получил сообщение через DHCP-агента доставки, сервер должен в качестве 'server identifier' выбрать адрес интерфейса, через который получено сообщение, (если только сервер не имеет других, лучших идей по поводу такого выбора). DHCP-клиенты должны использовать IP-адрес, переданный через опцию 'server identifier', для любого уникастного запроса, адресованного DHCP-серверу.
Сообщения DHCP посылаются клиентом широковещательно, до тех пор пока он не получит свой IP-адрес, адрес поля отправителя в IP-заголовке при этом должно быть равно нулю.
Если поле 'giaddr' в DHCP-сообщении клиента не равно нулю, сервер посылает любой отклик в порт 'DHCP server' агента транспортировки BOOTP, чей адрес указан в 'giaddr'. Если поле 'giaddr' равно нулю, а поле 'ciaddr' не равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по уникастному адресу, записанному в поле 'ciaddr'. Если 'giaddr' равно нулю и 'ciaddr' равно нулю, а бит broadcast =1, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по адресу 0xffffffff. Если бит broadcast =1 и 'giaddr' равно нулю и 'ciaddr' равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по аппаратному адресу клиента и адресу 'yiaddr'. Во всех случаях, когда 'giaddr' равно нулю, сервер широковещательно посылает любое сообщение DHCPNAK по адресу 0xffffffff.
Если опции в DHCP-сообщении распространяются на поля 'sname' и 'файл', в поле 'опции' должна появиться опция 'option overload', со значением 1, 2 или 3, как это специфицировано в RFC-1533. Если в поле 'опции' присутствует опция 'option overload', опции в этом поле должны завершаться опцией 'end', и могут содержать один или более опций 'pad' (заполнитель). Опции в полях 'sname' и 'файл' (если их применение индицировано опцией 'options overload') должны начинаться с первого октета поля, завершаться опцией 'end', и за ними для заполнения пространства до конца поля должны следовать опции 'pad'. Любая индивидуальная опция в полях 'опции', 'sname' и 'файл' должна полностью умещаться в поле. Опции в поле 'options' должны интерпретироваться первыми, так чтобы любая 'option overload' могла быть воспринята. Поле 'файл' должно интерпретироваться следующим (если опция 'option overload' указывает, что поле 'файл' содержит опции DHCP), за ним должно следовать поле 'sname'.
Значения, передаваемые в метку 'option' могут превосходить по длине 255 октетов, выделенных на одну опцию (например, список маршрутизаторов опции 'router' [21]). Опции могут появляться только раз, если только явно не указано обратного. Клиент присоединяет значения кратных опций к общему списку параметров для конфигурации.
Клиенты DHCP ответственны за доставку всех сообщений. Клиент должен адаптировать стратегию повторных передач, которая включает в себя экспоненциальный алгоритм вычисления псевдослучайных задержек между повторными пересылками. Задержки между повторными пересылками должны быть выбраны так, чтобы предоставить достаточно времени для ответов сервера с учетом условия связи между клиентом и сервером. Например, в сети 10Mбит/c Ethernet, задержка перед первой повторной посылкой должна быть случайным образом равномерно распределенной при среднем значении 4 секунды. Задержка следующей (второй) ретрансмиссии должна быть также случайной и составлять 8 секунд. Значения последовательных повторных передач должны при каждой последующей попытке удваиваться. Максимальное значение равно 64 секунд. Клиент может обеспечить для пользователя индикацию попыток повторной передачи.
Поле 'xid' используется клиентом для установления соответствия между приходящим DHCP-сообщением и отправленного ранее запросом. DHCP-клиент должен выбрать 'xid так чтобы минимизировать вероятность получения идентичных 'xid' разными клиентами. Например, клиент может выбирать разные, случайные начальные 'xid' каждый раз, когда клиент перезагружается, а далее использует инкрементацию этого значения при последующих передачах вплоть до следующей перезагрузки. Выбор нового 'xid' для каждой последующей повторной передачи относится на усмотрение конкретной программной реализации. Клиент может решить повторно использовать то же самое значение 'xid' или выбрать новый 'xid' для передачи каждого сообщения.
В норме, DHCP-серверы и агенты доставки BOOTP пытаются доставить сообщения DHCPOFFER, DHCPACK и DHCPNAK непосредственно клиенту, используя уникастную адресацию. IP-адрес места назначения (в IP-заголовке) равен адресу 'yiaddr', а адрес связного уровня равен 'chaddr'. К сожалению, некоторые реализации клиентов не могут получать уникастные IP-дейтограммы до тех пор, пока приложение не будет сконфигурировано и клиент не получит корректный IP-адрес (это ведет к тупику, когда IP-адрес не может быть получен клиентом до тех пор, пока в результате конфигурационного процесса он этот самый адрес не получит).
Клиент, который не может получать уникастные IP-дейтограммы, пока его протокольная программа не сконфигурирована, должен установить бит BROADCAST=1 в поле флагов в любом сообщении DHCPDISCOVER или DHCPREQUEST, которые клиент посылает. Бит BROADCAST укажет, что DHCP-сервер и агент транспортировки BOOTP должны посылать клиенту сообщения широковещательно. Клиент, который может получать уникастные IP-дейтограммы до того как его программа сконфигурирована, должен сделать бит BROADCAST равным 0.
Сервер или агент доставки, посылающие или передающие DHCP-сообщение непосредственно DHCP-клиенту (т.e., не агенту транспортировки, указанному в поле 'giaddr'), должны анализировать бит BROADCAST поля 'флаги'. Если этот бит равен 1, DHCP-сообщение должно быть послано как широковещательное по адресу 0xffffffff. Если бит BROADCAST равен 0, сообщение должно быть послано по уникастному IP-адресу указанному в поле 'yiaddr'. Если уникастная транспортировка невозможна, сообщение может быть послано по широковещательному адресу 0xffffffff.
4.2. Административное управление сервером DHCP
DHCP-серверы не обязаны откликаться на каждое сообщение DHCPDISCOVER и DHCPREQUEST, которое они получают. Например, сетевой администратор с целью сохранения строгого контроля за клиентами, подключенными к сети, может захотеть сконфигурировать DHCP-серверы так, чтобы они реагировали только на клиентов, которые были зарегистрированы ранее с помощью некоторого внешнего механизма. Спецификация DHCP описывает только взаимодействие между клиентами и серверами, когда они хотят этого; описание административного контроля со стороны системного администратора находится вне пределов данной спецификации. Специальные реализации DHCP-серверов могут включать в себя любые механизмы административного контроля.
При некоторых условиях, DHCP-сервер будет должен проанализировать значения опций vendor class, включенные в сообщения DHCPDISCOVER или DHCPREQUEST с тем, чтобы определить корректные параметры для конкретного клиента.
DHCP-сервер должен использовать некоторый уникальный идентификатор, для того чтобы установить соответствие между клиентом и его набором конфигурационных параметров. Клиент может решить выдать идентификатор с помощью опции 'client identifier'. Если клиент предоставляет 'client identifier', он должен использовать его во всех последующих сообщениях, а сервер должен использовать этот идентификатор для распознавания клиента. Если клиент не предоставляет опцию 'client identifier', сервер должен для идентификации клиента использовать содержимое поля 'chaddr'. Для клиента DHCP весьма важно использовать уникальный идентификатор в пределах субсети, к которой он подключен согласно опции 'client identifier'. Использование 'chaddr' в качестве уникального идентификатора клиента может вызвать непредсказуемые результаты, так как такой идентификатор может быть ассоциирован с аппаратным интерфейсом, который может быть передан новому клиенту. Чтобы избежать непредсказуемых изменений сетевого адреса клиента (из-за переноса аппаратного интерфейса) некоторые узлы могут использовать в качестве идентификатора клиента серийный номер производителя. Сетевые узлы могут также использовать в качестве идентификатора клиента DNS-имя.
Клиенты DHCP вольны использовать любую стратегию при выборе DHCP-сервера из числа тех, список которых клиент получает в сообщении DHCPOFFER. Реализация клиента должна предоставлять для пользователя механизм выбора значений 'vendor class identifier'.
4.3. Поведение сервера DHCP
DHCP-сервер обрабатывает приходящие от клиента DHCP-сообщения на основе текущего состояния набора конфигурирующих параметров клиента. DHCP-сервер может получать от клиента следующие сообщения:
o DHCPDISCOVER
o DHCPREQUEST
o DHCPDECLINE
o DHCPRELEASE
o DHCPINFORM
В таблице 3 рассмотрено использование полей и опций в DHCP-сообщении сервера.
4.3.1. Сообщение DHCPDISCOVER
Когда сервер получает от клиента сообщение DHCPDISCOVER, он выбирает сетевой адрес для клиента, приславшего запрос. Если нет свободного адреса, сервер может проинформировать о проблеме системного администратора. Если адрес доступен, новый адрес должен быть выбран следующим образом:
| o |
Текущий адрес клиента, как это записано в текущем блоке параметров клиента, в противном случае
Заметим, что в некоторых сетевых архитектурах (например, в Интернет с более чем одной IP-субсетью, сопряженной с физическим сетевым сегментом), DHCP-клиенту должен быть присвоен адрес из другой субсети, а не адрес, записанный в 'giaddr'. Таким образом, DHCP не требует, чтобы клиенту был присвоен адрес из субсети 'giaddr'. Сервер волен выбрать какую-то другую субсеть. Механизм выбора IP-адреса находится вне пределов данной спецификации.
Если это не требуется для корректной работы DHCP, сервер не должен повторно использовать выбранный сетевой адрес, прежде чем клиент пришлет сообщение серверу DHCPOFFER. Сервер может решить записать этот адрес, как предложенный клиенту. Он должен также выбрать время действия конфигурационного набора, согласно следующим правилам:
| o | Если клиент не запросил специальный конфигурационный набор в сообщении DHCPDISCOVER и клиент уже имеет сетевой адрес, сервер присылает значение времени действия, ранее присвоенное данному адресу (заметим, что клиент должен явно запросить установления времени действия набора, чтобы переписать значение, ассоциированное с данным адресом), в противном случае |
| o | Если клиент не запросил определенное значение времени действия конфигурационного набора в сообщении DHCPDISCOVER и клиент не имеет сетевого адреса, сервер присваивает времени действия набора местное значение по умолчанию, в противном случае |
| o | Если клиент запросил специальный конфигурационный набор параметров в сообщении DHCPDISCOVER (вне зависимости оттого, имел ли он уже сетевой адрес), сервер может либо предоставить запрошенный набор (если это согласуется с местной политикой) или выбрать другой набор. |
Таблица 3. Поля и опции, используемые DHCP-серверами
| Поле | DHCPOFFER | DHCPACK | DHCPNAK |
| 'op' | BOOTREPLY | BOOTREPLY | BOOTREPLY |
| 'htype' | Из RFC "Assigned Numbers" | ||
| 'hlen' | Длина аппаратного адреса в октетах | ||
| 'hops' | 0 | 0 | 0 |
| 'xid' | 'xid' из сообщения клиента DHCPDISCOVER | 'xid' из сообщения клиента DHCPREQUEST | 'xid' из сообщения клиента DHCPREQUEST |
| 'secs' | 0 | 0 | 0 |
| 'ciaddr' | 0 | 'ciaddr' из DHCPREQUEST или 0 | 0 |
| 'yiaddr' | IP-адрес предложенный клиенту | IP-адрес присвоенный клиенту | 0 |
| 'siaddr' | IP-адрес следующего сервера загрузки | IP-адрес следующего сервера загрузки | 0 |
| 'flags' | 'flags' из сообщения клиента DHCPDISCOVER | флаги' из сообщения клиента DHCPREQUEST | 'flags' из сообщения клиента DHCPREQUEST |
| 'giaddr' | 'giaddr' из сообщения клиента DHCPDISCOVER | 'giaddr' из сообщения клиента DHCPREQUEST | 'giaddr' >из сообщения клиента DHCPREQUEST |
| 'chaddr' | 'chaddr' из сообщения клиента DHCPDISCOVER | 'chaddr' из сообщения клиента DHCPREQUEST | 'chaddr' из сообщения клиента DHCPREQUEST |
| 'sname' |
Имя ЭВМ сервера
или опции
или опции
имя или опции
имя или опции
| Опция | DHCPOFFER | DHCPACK | DHCPNAK |
| Запрошенный IP-адрес | не должен | не должен | не должен |
| IP-адрес lease time | должен |
должен (DHCPREQUEST)
не должен (DHCPINFORM)
Раз сетевой адрес и конфигурационный набор параметров определены, сервер формирует сообщение DHCPOFFER с предлагаемыми конфигурационными параметрами. Для всех DHCP-серверов важно прислать одни и те же параметры (с единственно возможным исключением - новым предлагаемым сетевым адресом), что гарантирует предсказуемое поведение клиента вне зависимости от того, какой из серверов он выберет. Конфигурация параметров должна быть выбрана согласно следующим правилам, представленным ниже. Сетевой администратор ответственен за конфигурацию всех DHCP-серверов, что гарантирует однородность откликов этих серверов. Сервер должен прислать клиенту:
| o | Сетевой адрес клиента, как это определено правилами приведенными выше, |
| o | Время действия клиентского набора, как это определено правилами из данного раздела, |
| o |
| o | Любые параметры из существующего набора, которые отличаются от значений по умолчанию документа Host Requirements, |
| o | Любые параметры, специфичные для клиента (как это с пецифицировано в содержимом 'chaddr' или 'client identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором, |
| o | Любые параметры специфичные для этого класса клиента (как это идентифицировано в опции 'vendor class identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором; |
| o | Параметры со значениями, неравными величинам по умолчанию для клиентской субсети. |
Label-Only-Inferred-PSC LSP (L-LSP)
Отдельный LSP может быть сформирован для одиночной пары <FEC, OA>. Для таких LSP, PSC определяется явно в момент формирования метки, так что после этого LSR может определить PSC исключительно на основании значения метки. В случае, когда используется встроенный заголовок, приоритет отбрасывания, который следует применить LSR к пакету, определяется содержимым MPLS заголовка с помощью поля EXP. Когда вставной заголовок не используется (например, MPLS поверх ATM), приоритет отбрасывания определяется для LSR полями заголовка канального уровня (например, ATM CLP).
Мы называем такие LSP - "Label-Only-Inferred-PSC LSP" (L-LSP), так как PSC может быть целиком определен из метки без привлечения какой-либо иной информации (например, не обращая внимания на значение поля EXP). Детальное описание работы L-LSP представлено в разделе 4.
LDP партнеры
Два LSR, которые используют LDP для обмена информацией о соответствии метка-FEC, называются "LDP партнерами", между которыми реализуется "LDP сессия". LDP сессия позволяет каждому партнеру познакомиться с соответствием меток друг у друга; т.e., протокол является двунаправленным.
LDP PDU
Каждый LDP PDU представляет собой LDP заголовок, за которым следует одно или более LDP сообщений. LDP заголовок имеет формат:
Версия
Двухоктетное целое число без знака, содержащее код номера версии протокола. Данный документ описывает версию протокола LDP 1.
Длина PDU
Двухоктетное целое число, специфицирующее общую длину PDU в октетах, исключая поля версии и длины PDU.
Максимально допустимая длина PDU согласуется, когда инициализируется сессия LDP. До завершения согласования максимально допустимая длина равна 4096 байтов.
Идентификатор LDP
Шестиоктетное поле, которое однозначно идентифицирует пространство меток LSR-отправителя, для которого это PDU используется. Первые четыре октета идентифицируют LSR и должны быть глобально уникальными. Это должен быть 32-битовый Id маршрутизатора, присвоенный LSR и используемый также для идентификации при детектировании петель в векторах пути. Последние два октета идентифицируют пространство меток заданного LSR. Для пространства меток, ориентированного на платформу, эти два октета должны равняться нулю.
Заметим, что не существует требований по выравниванию для первого октета LDP PDU.
LDP сессии между LSR, соединенными не напрямую
В некоторых ситуациях могут быть желательны сессии LDP между LSR, которые не связаны непосредственно на канальном уровне.
Например, рассмотрим приложение управления трафиком, где LSRa посылает трафик, отвечающий определенным критериям, через определенный LSP к LSRb, а не осуществляет традиционную маршрутизацию.
Путь между LSRa и LSRb будет включать один или более промежуточных LSR ( LSR1,...LSRn). LDP-сессия между LSRa и LSRb позволит LSRb пометить трафик, пребывающий в LSP из LSRa, путем предоставления LSRb средств анонсирования меток маршрутизатору LSRa.
В этой ситуации LSRa будет использовать две метки для коммутации трафика через LSP к LSRb: метка, полученная от LSR1, служит для переадресации трафика вдоль LSP от LSRa к LSRb; а метка, полученная от LSRb, позволяет LSRb помечать и коммутировать трафик, поступающий из LSP.
LSRa сначала добавляет метку, полученную во время LDP-сессии от LSRb, в стек меток пакета (либо путем замены метки на верху стека меток, если пакет пришел помеченным, или путем выполнения операции push (занесение в стек), если пакет пришел непомеченным. Далее, он заносит в стек метку для LSP, полученную от LSR1.
LDP-сообщения, сопряженные с Diff-Serv 6.3.Сообщение запроса метки
Формат сообщения запроса метки приведен ниже, это сообщение имеет опционное поле Diff-Serv TLV:
Рис. 13.
LDP транспорт
Для сессий LDP использует TCP, как надежную транспортную среду. Когда нужно несколько LDP сессий между двумя LSR, реализуется по одной TCP-сессии для каждой LDP сессии.
LSP следующего шага
LSP Next Hop для определенного помеченного пакета в конкретном LSR является LSR, который представляет следующий шаг пути, как это выбрано записью NHLFE, использованной для переадресации пакета. LSP Next Hop для определенного FEC является следующим шагом пути, как это выбрано записью NHLFE, индексированной меткой, которая соответствует этому FEC.
Заметим, что LSP следующего шага может отличаться от того, который был бы выбран алгоритмом маршрутизации сетевого уровня. Мы будем использовать термин "следующий шаг L3", когда будем иметь в виду такой маршрут.
LSP-туннели, маршрутизируемые явно
В некоторых ситуациях сетевые администраторы могут захотеть переадресовывать определенные классы трафика по определенным специфицированным заранее маршрутам, где эти пути отличаются от маршрутов шаг-за-шагом, по которым шел трафик первоначально. Это может быть сделано для поддержки политики маршрутизации, или для управления трафиком (ТЕ). Явный маршрут может быть сконфигурирован, или он может быть определен динамически посредством, например, маршрутизации на основе ограничений.
MPLS позволяет выполнить это легко посредством LSP–туннелей, маршрутизированных явно. Для этого необходимо:
1. Средства отбора пакетов, которые должны быть посланы в LSP-туннель, маршрутизированный явно;
2. Средства формирования маршрутизированного явно LSP-туннеля;
3. Средства, гарантирующие, что пакеты, посланные в туннель, не будут переадресованы принимающей стороной туннеля в направлении передающей стороны (отсутствие петель).
Если передающий конец туннеля хочет поместить помеченный пакет в туннель, он должен сначала заменить метку на вершине стека меткой, присланной принимающей стороной туннеля. Затем он должен ввести в стек метку, которая соответствует самому туннелю и прислана маршрутизатором следующего шага в туннеле. Чтобы разрешить это, концы туннеля должны быть явными партнерами по обмену метками. Ассоциации меток, которыми они должны обменяться не представляют интереса для LSR в туннеле.
LSP-туннелирование между пограничными BGP маршрутизаторами
Рассмотрим случай автономной системы A, которая пропускает трафик между другими автономными системами. Автономная система A будет иметь несколько пограничных маршрутизаторов BGP, и сеть BGP соединений между ними, через которые пересылаются BGP маршруты. Во многих таких случаях желательно избежать рассылки BGP-маршрутов маршрутизаторам, которые не являются пограничными. Если этого можно избежать, нагрузка по рассылке маршрутов этих маршрутизаторов существенно сокращается. Однако должны быть некоторые средства, гарантирующие, что транзитный трафик будет доставляться от одного BGP-маршрутизатора к другому с помощью внутренних маршрутизаторов.
Это может быть легко сделано с помощью туннелей LSP. Предположим, что BGP маршруты рассылаются только пограничным BGP-маршрутизаторам, а не внутренними маршрутизаторами, которые расположены по пути. LSP-туннели могут использоваться следующим образом:
1. Каждый пограничный маршрутизатор BGP посылает каждому другому пограничному маршрутизатору BGP в пределах автономной системы метку для каждого адресного префикса, которую он пересылает в рамках протокола BGP.
2. IGP для автономной системы поддерживает маршрут для каждого BGP-маршрутизатора. Каждый внутренний маршрутизатор рассылает свои метки для этих маршрутов каждому своему IGP-соседу.
3. Предположим, что:
a) Пограничный маршрутизатор BGP B1 получает непомеченный пакет P.
b) Адресный префикс X в маршрутной таблице B1 является наилучшим соответствием для адреса места назначения пакета P.
c) Маршрут до X является маршрутом BGP.
d) Следующим шагом BGP для X является B2.
e) B2 имеет ассоциацию метки L1 и X, и посылает эту ассоциацию в B1.
f) Следующий шаг IGP для адреса B2 является I1.
g) Адрес B2 содержится в маршрутных таблицах B1 и I1 IGP, а
h) I1 связывает метку L2 с адресом B2 и посылает эту ассоциацию B1.
Далее прежде чем послать пакет P в I1, B 1 должен сформировать стек меток для P, затем заносит туда метку L1, а на верх стека записывает L2.
4. Предположим, что пограничный BGP маршрутизатор B1 получает помеченный пакет P, где на верху стека размещена метка, соответствующая адресному префиксу X маршрута, и что условия 3b, 3c, 3d и 3e все выполнены. Тогда прежде чем посылать пакет P в I1, B1 должен заменить метку на верху стека на метку L1, и затем записать в стек метку L2.
Эти процедуры эффективно формируют LSP-туннель, маршрутизированный шаг-за-шагом, между пограничными маршрутизаторами BGP.
Так как пограничные BGP-маршрутизаторы обмениваются ассоциациями меток для адресных префиксов, которые неизвестны IGP, маршрутизаторы BGP должны стать партнерами по явному обмену метками.
Иногда можно сформировать LSP-туннель, маршрутизированный шаг-за-шагом, между двумя пограничными маршрутизаторами BGP, даже если они не принадлежат общей автономной системе. Предположим, например, что B1 и B2 находятся в AS1. Предположим также, что B3 является EBGP-соседом B2, и находится в AS2. Наконец, предположим, что B2 и B3 находятся в некоторой сети, которая является общей для обеих автономных систем ("демилитаризованная зона"). В этом случае LSP-туннель может быть сформирован непосредственно между B1 и B3 следующим образом:
· B3 посылает маршруты B2 (используя EBGP), опционно присваивая метки адресным префиксам;
· B2 перераспределяет маршруты к B1 (используя IBGP), указывая, что следующим шагом BGP для каждого такого маршрута является B3. Если B3 присвоил метки адресным префиксам, B2 передает эти метки далее без изменений вплоть до B1.
· IGP автономной системы AS1 имеет host route для B3.
LSP управление: Ordered против Independent
Некоторые FEC соответствуют адресным префиксам, которые рассылаются алгоритмом динамической маршрутизации. Начальная установка LSP для этих FEC может быть выполнена двумя способами: независимым управлением LSP (Independent LSP Control) или упорядоченным управлением LSP (Ordered LSP Control).
В независимом управлении LSP, каждый LSR, учитывая, что он распознает определенный FEC, принимает независимое решение об ассоциации метки с FEC и рассылает эту ассоциацию своим партнерам. Это соответствует способу, реализуемому традиционной маршрутизацией IP-дейтограмм. Каждый узел принимает независимое решение относительно того, как обрабатывать конкретный пакет, и полагается на алгоритм маршрутизации. При упорядоченном управлении LSP, LSR только связывает метки с определенным FEC, если он является выходным LSR для данного FEC, или если он уже получил ассоциацию метки с FEC из узла следующего шага.
Если хочется гарантировать, чтобы трафик в конкретном FEC следовал пути с некоторыми специфицированными свойствами (например, чтобы трафик не пересекал один и тот же узел дважды, чтобы для трафика были выделены определенные ресурсы, чтобы трафик следовал определенному пути и т.д.) должен использоваться упорядоченное управление. При независимом управлении, некоторые LSR могут начать коммутацию трафика по меткам в FEC, до того как LSP полностью сконфигурирован, и таким образом часть трафика в FEC может следовать пути, который не имеет специфицированных свойств. Упорядоченное управление должно также использоваться, если распознавание FEC является следствием конфигурирования соответствующего LSP. Упорядоченное конфигурирование LSP может быть инициировано входным или выходным узлом.
Упорядоченное и независимое управление полностью совместимы. Однако если только не все LSR в LSP используют упорядоченное управление, результирующее влияние на поведение сети более существенно, чем в случае независимого управления, так как нельзя быть уверенным, что LSP не будет использован до того, как будет полностью сконфигурирован.
Эта архитектура позволяет сделать выбор между независимым и упорядоченным управлением исключительно местной проблемой. Так как взаимодействуют два метода, данный LSR должен поддерживать один или другой метод. Вообще говоря, выбор независимого или упорядоченного управления не оказывает какого-либо эффекта на механизмы коммутации пакетов, базирующиеся на метках.
Маршрут с коммутацией меток (LSP), входной и выходной LSP
"Маршрут с коммутацией меток (LSP) уровня m" для определенного пакета P является последовательностью маршрутизаторов <R1, ..., Rn> со следующими свойствами:
1. R1, "вход LSP", является LSR, который вносит метку в стек пакета P, в результате формируется стек глубиной m;
2. Для всех i, 1<i<n, P (когда он приходит в LSR Ri) имеет стек меток глубиной m;
3. Никогда за время передачи P от R1 к R[n-1] глубина стека не будет меньше m;
4. Для всех i, 1<i<n: Ri передает P в R[i+1] посредством MPLS, т.e., путем использования метки в верхней позиции стека (метка уровня m) в качестве индекса в ILM;
5. Для всех i, 1<i<n: если система S получает и переадресует P, после того как P передан Ri, но до того как P получен R[i+1] (например, Ri и R[i+1] могут быть соединены через коммутируемую субсеть, и S может быть одним из переключателей информационного канала), далее решение переадресации S не базируется на метке уровня m, или на основе заголовка сетевого уровня. Это может быть, так как:
a) решение не основано на содержимом стека или заголовка сетевого уровня;
b) решение основано на содержимом стека, куда положены другие метки (т.e., на метке уровня m+k, где k>0).
Другими словами, мы можем описать уровень m LSP для пакета P, как последовательность маршрутизаторов:
1. Которая начинается с LSR ("вход LSP "), заносящий метку на уровень m.
2. Все маршрутизаторы, чьи промежуточные LSR, принимают решение о переадресации согласно метке на уровне m.
3. Которая завершается (в "выходном LSP"), когда решение переадресации делается на основе коммутации меток на уровне m-k, где k>0, или когда решение переадресации делается "традиционно", посредством не-MPLS процедур.
Следствием (или, пожалуй, предпосылкой) этого является то, что, когда бы LSR ни занес метку в стек уже помеченного пакета, он должен быть уверен, что новая метка соответствует FEC, чьим выходом LSP служит LSR, который сформировал метку, которая сейчас является второй в стеке. Мы будем называть последовательность LSR "LSP для определенного FEC F", если он является LSP уровня m для заданного пакета P, когда уровень метки P соответствует FEC F.
Рассмотрим набор узлов, которые могут быть входными LSP-узлами для FEC F. Тогда существует LSP для FEC F, который начинается с каждого из этих узлов. Если некоторое число этих LSP имеет идентичный выходной LSP, тогда можно рассматривать набор таких LSP как дерево, чьим корнем является выходной LSP. (Так как данные переносятся вдоль этого дерева по направлению к корню, эта структура может быть названа деревом мультиточка-точка). Мы можем, таким образом, говорить о "дереве LSP" для определенного FEC F.
Метка восстановления
Объект Recovery_Label используется в процессе восстановления узла после отказа. Формат объекта Recovery_Label идентичен формату обобщенной метки. Объект Recovery_Label использует номер класса 34 (в форме 0bbbbbbb) и C-тип предлагаемой метки.
Метки
Метка является коротким идентификатором фиксированной длины, который используется для идентификации FEC. Метка, которая вложена в определенный пакет, представляет класс переадресации FEC (Forwarding Equivalence Class), к которому данный пакет приписан. Обобщая, можно сказать, что пакет приписан FEC, базирующемуся частично или целиком на его адресе места назначения сетевого уровня. Однако кодировка метки никогда не совпадает c этим адресом.
Если Ru и Rd являются LSR, они могут договориться о том, что когда Ru передает пакет Rd, Ru снабжает пакет меткой с кодом L, если и только если пакет принадлежит определенному классу FEC F. То есть, они могут согласовать соответствие между меткой L и F для пакетов, транспортируемых от Ru к Rd. В результате такого соглашения L становится выходной меткой Ru, представляющей FEC F, а L становится входной меткой Rd.
Заметим, что L не обязательно представляет FEC F для любого пакета, посланного не Ru и адресованного не Rd. L имеет произвольное значение, чья связь F с Ru и Rd является локальной.
Когда говорится, что пакеты посланы из Ru в Rd, это не означает, что пакеты сформированы в Ru или, что местом назначения является Rd. Скорее, мы подразумеваем, что пересылаемые пакеты поступают в один или оба LSR.
Иногда может оказаться трудно или даже невозможно для Rd сообщить о прибывающих пакетах с меткой L, помещенной в пакет Ru, а не каким-то другим LSR. (Это обычно происходит, когда Ru и Rd не являются соседями). В таких случаях Rd должен убедиться, что имеет место соответствие межу меткой и FEC. То есть, Rd не должен соглашаться на ассоциацию L и FEC F1, в то время как с другим LSR Ru2 согласовано соответствие L с другим FEC F2, если только Rd не может при получении пакетов с меткой L всегда оповещать, вложена ли в пакет метка Ru1 или Ru2. Гарантия однозначной интерпретации меток находится в зоне ответственности LSR.
Метки длины волны и порта
Некоторые конфигурации переключения волокон FSC и l -переключение LSC используют несколько каналов/соединений, контролируемых одним управляющим каналом. В таких случаях метка ассоциируется с информационным каналом, используемым в LSP. Заметим, что этот случай не тождественен варианту применения [MPLS-BUNDLE]. Метка в случае работы с коммутацией портов и длин волн имеет длину 32 бита.
Метка :32 бит
Указывает на порт/волокно или длину волны, которая должна использоваться, с позиции отправителя объекта TLV. Значения, используемые в этом поле, имеют значение только для соседей, и получатель может оказаться вынужден преобразовать полученное значение. Значения могут конфигурироваться или динамически определяться с помощью протокола [LMP].
