Многоцелевое расширение почты Интернет

         

Класс 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-fooas-set: as-baras-set: as-empty
members: AS1, AS2members: 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: AS3Aut-num: AS4
member-of: as-foomember-of: as-foo
mnt-by: MNTR-MEmnt-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> обязательный, однозначный, ключ классаrp-attributeСм. описание в текстеопционный, многозначныйtypedefСм. описание в текстеопционный, многозначныйprotocolСм. описание в текстеопционный, многозначный
Рис. .24. Атрибуты класса dictionary

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

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

operator=operator==
operator<<=operator<
operator>>=operator>
operator+=operator>=
operator-=operator<=
operator*=operator!=
operator/=operator()
operator.=operator[]
Рис. .25. Операторы

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

Аргумента строго типофицированы. <type> в RPSL является либо предопределенным, типом union, списочным, либо определенным в словаре. Предопределенные типы перечислены на рис. .26.
integer[lower, upper]ipv4_address
real[lower, upper]address_prefix
enum[name, name, ...]address_prefix_range
stringdns_name
Booleanfilter
rpsl_wordas_set_name
free_textroute_set_name
emailrtr_set_name
as_numberfilter_set_name
peering_set_name
Рис. .26. Предопределенные типы аргументов

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

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

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

Синтаксис списочного типа приведен ниже:
list [<min_elems>:<max_elems>] of <type>

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

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


Класс 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
где ASN является номером AS. ASN соответствует AS-path, который имеет длину равную 1 и содержит корректный номер AS (например, регулярное выражение AS-path AS1 соответствует AS-path "1"). Вместо номера AS-партнера может использоваться ключевое слово PeerAS.AS-setгде AS-set является именем набора AS. AS-set соответствует AS-проходам, которые согласуются с одним из AS в AS-set..соответствует AS-path, который согласуется с любым номером AS.[...]является набором номеров AS. Это выражение соответствует AS-path, согласующимся со списком номеров AS, записанных в скобках. Номера AS в наборе отделяются друг от друга пробелом или символом TAB (white space). Если между двумя номерами AS использован символ `-', в набор включаются все AS из этого диапазона. Если в список включено имя as-set, в набор войдут все номера AS as-set.[^...]является дополнением набора AS. Это выражение соответствует любому AS-path, который не соответствует набору номеров AS из приведенного набора.^Соответствует пустой строке в начале AS-path.$Соответствует пустой строке в конце AS-path.
Далее описываются операторы регулярных выражений. Эти операторы выполняются слева направо.

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

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

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

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

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

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

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

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

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


<^AS1>

<^AS1 AS2 AS3$>
<^AS1 .* AS2$>.

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

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

Последующие операторы могут использоваться при формировании составных фильтров политики.
NOT
Дан фильтр политики x, NOT x соответствует набору маршрутов, которые не соответствуют x. Таким образом он представляет отрицание фильтра политики x.ANDДаны два фильтра политики x и y, x AND y соответствует пересечению множеств маршрутов, которые соответствуют как фильтру x так и фильтру y.ORДаны два фильтра политики x и y, x OR y соответствует объединению множеств маршрутов, которые соответствуют фильтру x или фильтру y. Заметим, что оператор OR может быть неявным, то есть `x y' эквивалентно `x OR y'. Например
NOT {128.9.0.0/16, 128.8.0.0/16}
AS226 AS227 OR AS228
AS226 AND NOT {128.9.0.0/16}
AS226 AND {0.0.0.0/0^0-18}

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

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

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

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


Класс 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опционный, многозначный
e-mail<email-address>обязательный, многозначный

Рис. .3: Атрибуты класса person

phone: +44 123 987654 ext. 4711

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

person:Daniel Karrenberg
address:RIPE Network Coordination Centre (NCC)
address:Singel 258
address:NL-1016 AB Amsterdam
address:Netherlands
phone:+31 20 535 4444
fax-no:+31 20 535 4445
e-mail:Daniel.Karrenberg@ripe.net
nic-hdl:DK58
changed:Daniel.Karrenberg@ripe.net 19970616
source:RIPE

Рис. .4. Пример объекта person.



Класс 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>обязательный, многозначный
phonesee description in textобязательный, многозначный
fax-nosame as phoneопционный, многозначный
e-mail<email-address>обязательный, многозначный

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

role:RIPE NCC Operations

trouble:

address:Singel 258
address:1016 AB Amsterdam
address:The Netherlands
phone:+31 20 535 4444
fax-no:+31 20 545 4445
e-mail:ops@ripe.net
admin-c:CO19-RIPE
tech-c:RW488-RIPE
tech-c:JLSD1-RIPE
nic-hdl:OPS4-RIPE
notify:ops@ripe.net
changed:roderik@ripe.net 19970926
source:RIPE

Рис. .6. Пример объекта role.



Класс route


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

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

АтрибутЗначениеТип
Route<address-prefix>обязательный, однозначный, ключ класса
Origin<as-number>обязательный, однозначный, ключ класса
member-of

список <route-set-names>
см. раздел 5опционный, многозначныйInjectсм. раздел 8опционный, многозначныйComponentsсм. раздел 8опционный, однозначныйaggr-bndryсм. раздел 8опционный, однозначныйaggr-mtdсм. раздел 8опционный, однозначныйexport-compsсм. раздел 8опционный, однозначныйholesсм. раздел 8опционный, многозначныйРис. 7: Атрибуты класса route

route:128.9.0.0/16
origin:AS226
route:128.99.0.0/16
origin:AS226
route:128.8.0.0/16
origin:AS1
route:128.8.0.0/16
origin:AS2

Рис. .8. Объекты Route



Класс 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-foortr-set: rtrs-bar
members: rtr1.isp.net, rtr2.isp.netmembers: 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".) (2) 8-битовое шестнадцатеричное число 20 (напр., ISO-8859-1 SPACE) может быть представлено как "_" (знак подчеркивания, ASCII 95.). (Этот символ может не пройти через некоторые почтовые шлюзы, но его использование существенно улучшает читаемость "Q"-кодированных данных в почтовых системах, которые поддерживают этот вид кодирования). Заметим, что "_" всегда представляется шестнадцатеричным кодом 20, даже если символ пробел (SPACE) занимает другую кодовую позицию в используемом символьном наборе.(3)8-битовые значения, которые соответствуют печатным ASCII-символам, отличным от "=", "?" и "_", могут быть представлены самими собой. Об ограничениях см. раздел 5. В частности, SP и HT не должны представляться самими собой в пределах кодировочных слов.



Кодирование информации 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].

Код

ошибкиЗначение24Проблема маршрутизации

Этот код ошибки имеет следующие глобально определенные значения субкодов ошибок:

1 Bad EXPLICIT_ROUTE object (плохой объект EXPLICIT_ROUTE)2Bad strict node (плохой строгий узел)3Bad loose node (плохой свободный узел)4Bad initial subobject (плохой исходный субобъект)5No route available toward destination (нет маршрута до адресата)6Unacceptable label value (неприемлемое значение метки)7RRO indicated routing loops (обнаружены петли маршрута)8MPLS being negotiated, but a non-RSVP-capable router stands in the path (Согласовывался MPLS, но на пути оказался маршрутизатор без поддержки RSVP)9MPLS label allocation failure (Ошибка присвоения метки MPLS)10Unsupported L3PID ( Неподдерживаемый L3PID)25Notify Error (Внимание)

Этот код ошибки имеет следующие глобально определенные значения субкодов ошибок:

1RRO слишком велик для MTU2RRO Notification (уведомление)3Tunnel locally repaired (туннель восстановлен локально)



Коды ошибок для Diff-Serv


В процедурах, описанных выше, некоторые ошибки должны объявляться Diff-Serv Error. Значение кода Diff-Serv Error равно 27. Ниже представлены коды ошибок для Diff-Serv:

КодТип ошибки1Нестандартный объект DIFFSERV 2Неподдерживаемый PHB 3Некорректное соответствие EXP<-->PHB 4Неподдерживаемое PSC 5Неудача выделения ресурсов на каждый LSP

Коды ошибок для ERO и RRO


При обработке, описанной выше, определенные ошибки должны быть объявлены как " Routing Problem" или "Notify" (проблема маршрутизации или внимание). Значение кода ошибки "Routing Problem" равно 24; значение кода "Notify" равно 25. Определены следующие значения ошибок для кода ошибки Routing Problem:

ЗначениеОшибка:1Bad EXPLICIT_ROUTE object (плохой объект EXPLICIT_ROUTE)2Bad strict node (плохой жесткий узел)3Bad loose node (плохой свободный узел)4Bad initial subobject (плохой исходный субобъект)5No route available toward destination (нет пути до адресата)6Unacceptable label value (неприемлемое значение метки)7RRO indicated routing loops (RRO указывает на наличие петли)8MPLS being negotiated, but a non-RSVP-capable router stands in the path (согласовывался MPLS, но на пути стоит маршрутизатор без поддержки RSVP)9MPLS label allocation failure (ошибка присвоения MPLS метки)10Unsupported L3PID (не поддерживаемый L3PID)

Для кода ошибки Notify, 16 бит значения поля ошибки имеет вид:

ss00 cccc cccc cccc

Старшие биты определены при коде ошибки 1. (Смотри [1]). Когда ss = 00, определены следующие субкоды:

1 RRO для MTU слишком велико

2 RRO уведомление

3 Туннель локально восстановлен



Комбинации режимов запуска и рассылки меток


В таблице 2 приведены допустимые комбинации методов рассылки меток и запуска формирования LSP, которые были обсуждены в предыдущих разделах. (X) означает, что комбинация допустима, если LSR поддерживает смешанную переадресацию L2/L3.

Таблица 2. Допустимые комбинации методов запуска и рассылки меток

 Метка запрашивается LSR-UpLSR-Dn upstream unsolicited downstream on demand downstream unsolicited upstream on demand Request Driven (входные сообщения) X X    Request Driven (выходные сообщения)     X X Topology Driven X X X XTraffic Driven X X (X) (X)

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)Все типы среды должны иметь корректно сформированные имена типа и субтипов. Все имена типов должны быть определены стандартным образом. Все имена субтипов должны быть уникальными, должны соответствовать грамматике MIME и содержать корректный префикс дера (3)Типы, регистрируемые в рамках частного дерева, должны быть снабжены спецификацией формата, или указателем на такую спецификацию. (4) Любые соображения по безопасности должны отражать объективную ситуацию и быть корректными. IANA не проводит экспертизу, но откровенно некомпетентные материалы отбрасываются.

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) (Возможное применение) Author/Change controller:(Автор/ответственный)
Сюда может быть добавлена любая другая информация на усмотрение автора.

Коммуникация


Протокол 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", которые именовались как "расширения производителя", теперь называются просто "опции".

012345678910111213141516171819202122232425262728293031
op (1)htype (1)hlen (1)Шаги (1)
xid (4)
secs (2)Флаги (2)
ciaddr (4)
yiaddr (4)
siaddr (4)
chaddr (4)

chaddr (16) sname (64) Файл (128)Опции (длина переменная)Рис. 1. Формат сообщения DHCP

DHCP определяет новую опцию 'client identifier', которая используется для прямой передачи идентификатора клиента DHCP серверу. Это изменение исключает перегрузку поля 'chaddr' в сообщениях BOOTP, где 'chaddr' используется как в качестве аппаратного адреса для пересылки сообщений откликов BOOTP, так и в качестве идентификатора клиента. Идентификатор клиента представляет собой непрозрачный ключ, который не должен интерпретироваться сервером; например, идентификатор клиента может содержать аппаратный адрес, идентичный тому, который лежит в поле 'chaddr', или он может содержать другой идентификатор типа, такой как DNS-имя. Идентификатор клиента, выбранный DHCP клиентом, должен быть уникальным для субсети, к которой он подключен. Если клиент использует идентификатор клиента в одном сообщении, он должен использовать тот же идентификатор во всех последующих сообщениях, чтобы гарантировать корректную идентификацию клиента всеми серверами. DHCP определяет поле 'siaddr' как адрес сервера для использования во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле 'siaddr', если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции 'server identifier'. Назначения полей заголовка представлены в таблице 1.

Таблица 1. Описание полей сообщения DHCP

ПолеБайтОписание
op1Код операции сообщения / тип сообщения.
1= BOOTREQUEST, 2 = BOOTREPLY
htype1Тип аппаратного адреса, смотри раздел ARP в RFC "Assigned Numbers"; например, '1' для 10 мегабитного Ethernet.
Hlen1Длина аппаратного адреса (например, '6' для 10 мегабитного Ethernet).
Шаги1Клиент устанавливает это поле равным нулю, поле используется опционно агентами транспортировки, когда загрузка осуществляется через посредника.
Xid4ID-транзакции, случайное число, выбираемое клиентом, и используемое как клиентом, так и сервером для установления соответствия между запросами и откликами.
Secs2

Заполняется клиентом, число секунд с момента начала запроса адреса или рестарта процесса.Флаги2Флаги (смотри рис. 2).Ciaddr4IP-адрес клиента заполняется только в случае, если клиент находится в состоянии BOUND, RENEW или REBINDING и может реагировать на запросы ARP.Yiadd4IP-адрес следующего сервера, используемого в процессе загрузки; присылается сервером в DHCPOFFER, DHCPACK.Giaddr4IP-адрес агента транспортировки, используется когда загрузка осуществляется через посредника.Chaddr16Аппаратный адрес клиента.Sname64Опционное имя ЭВМ-сервера, строка завершается нулем.Файл128Имя файла загрузки (Boot-файла), строка завершается нулем; имя "generic" или нуль в DHCPDISCOVER, полное описание прохода в DHCPOFFER.ОпцииvarПоле опционных параметров.Поле опции имеет переменную длину. Клиент DHCP должен быть готов получать DHCP-сообщения с полем 'опции' длиной, по крайней мере, 312 октетов. Это требование подразумевает, что DHCP-клиент должен быть готов получать сообщения длиной до 576 октетов. DHCP-клиенты могут согласовать применение более длинных DHCP-сообщений с помощью опции 'maximum DHCP message size'. Поле options может быть еще расширено в полях 'файл' и 'sname'.

В случае, когда клиент использует 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 показан формат поля флаги.

0123456789101112131415

B MBZB: флаг BROADCAST
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-серверам, которые размещены за пределами данной физической субсети.2.Каждый сервер может откликнуться сообщением DHCPOFFER, которое содержит сетевой адрес в поле 'yiaddr' (и другие конфигурационные параметры в опциях DHCP). Серверы не должны резервировать предлагаемый сетевой адрес, хотя протокол будет работать более эффективно, если сервер избегает присвоения предлагаемого сетевого адреса другому клиенту. При выделении нового адреса, серверы должны проверять, чтобы предлагаемый сетевой адрес не использовался где-то еще; например, сервер может протестировать предлагаемый адрес с помощью эхо-запроса ICMP. Серверы должны быть реализованы так, чтобы сетевые администраторы могли выбрать желательные тесты для вновь выделяемых адресов. Сервер отправляет клиенту сообщение DHCPOFFER, используя, если необходимо транспортные средства BOOTP.Таблица 2: Сообщения 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.5.Клиент получает сообщение DHCPACK, содержащее конфигурационные параметры. Клиент должен выполнить окончательную проверку параметров (например, запустить ARP для выделенного сетевого адреса), и фиксировать длительность предоставления конфигурационных параметров, прописанную в сообщении DHCPACK. Клиент окончательно сконфигурирован. Если клиент обнаруживает, что адрес уже используется (например, с помощью ARP), он должен послать серверу сообщение DHCPDECLINE и повторно запустить процесс конфигурации. Клиент должен подождать как минимум 10 секунд, прежде чем заново начинать конфигурационную процедуру, чтобы избежать возникновения лишнего сетевого трафика. Если клиент получает сообщение DHCPNAK message, клиент перезапускает конфигурационный процесс.Клиент реализует таймаут и повторно посылает сообщение DHCPREQUEST, если клиент не получает ни сообщения DHCPACK ни DHCPNAK. Клиент повторно посылает DHCPREQUEST согласно алгоритму повторной пересылки, описанному в разделе 4.1. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго; например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно послать сообщение DHCPREQUEST четыре раза, при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент не получает ни сообщения DHCPACK ни DHCPNAK после применения алгоритма повторной пересылки, клиент возвращается в исходное состояние и перезапускает процесс инициализации. Клиент должен уведомить пользователя о том, что процесс инициализации не прошел и делается повторная попытка.

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

Текущий адрес клиента, как это записано в текущем блоке параметров клиента, в противном случаеoПредшествующий адрес клиента, как это записано в текущем блоке параметров клиента (срок действия которого истек или использование которого прекратилось), если этот адрес находится в пуле доступных адресов сервера, в противном случаеoАдрес запрошенный в опции 'Запрошенный IP-адрес', если адрес корректен и еще не присвоен, в противном случаеoНовый адрес, полученный из пула свободных адресов; адрес выбирается с учетом субсети, откуда получено сообщение (если 'giaddr' = 0) или с учетом адреса агента транспортировки, который доставил сообщение (когда 'giaddr' не равен 0).Как это описано в разделе 4.2, сервер может, по административным причинам, присвоить адрес отличный от запрошенного, или может повторно использовать адрес для конкретного клиента, даже если имеются свободные адреса.

Заметим, что в некоторых сетевых архитектурах (например, в Интернет с более чем одной IP-субсетью, сопряженной с физическим сетевым сегментом), DHCP-клиенту должен быть присвоен адрес из другой субсети, а не адрес, записанный в 'giaddr'. Таким образом, DHCP не требует, чтобы клиенту был присвоен адрес из субсети 'giaddr'. Сервер волен выбрать какую-то другую субсеть. Механизм выбора IP-адреса находится вне пределов данной спецификации.

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

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

Таблица 3. Поля и опции, используемые DHCP-серверами

ПолеDHCPOFFERDHCPACKDHCPNAK
'op'BOOTREPLYBOOTREPLYBOOTREPLY
'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) не должен Использование полей 'файл'/'sname' может может не должен Тип сообщения DHCP DHCPOFFER DHCPACKDHCPNAK   Список параметров не должен не должен не должен Сообщение должен должен должен Идентификатор клиента не должен не должен может Идентификатор Vendor class может может может Идентификатор сервера должен должен должен Макс. размер сообщения не должен не должен не должен Все прочие может может не должен
Раз сетевой адрес и конфигурационный набор параметров определены, сервер формирует сообщение DHCPOFFER с предлагаемыми конфигурационными параметрами. Для всех DHCP-серверов важно прислать одни и те же параметры (с единственно возможным исключением - новым предлагаемым сетевым адресом), что гарантирует предсказуемое поведение клиента вне зависимости от того, какой из серверов он выберет. Конфигурация параметров должна быть выбрана согласно следующим правилам, представленным ниже. Сетевой администратор ответственен за конфигурацию всех DHCP-серверов, что гарантирует однородность откликов этих серверов. Сервер должен прислать клиенту:

oСетевой адрес клиента, как это определено правилами приведенными выше,
oВремя действия клиентского набора, как это определено правилами из данного раздела,
o
Параметры, запрошенные клиентом, согласно следующим правилам:- Если в сервере явно задано значение параметра по умолчанию, сервер должен включить это значение в соответствующую опцию поля 'option', в противном случае- Если сервер распознает параметр, как параметр, определенный в документе Host Requirements, сервер должен включить его значение по умолчанию (как это рекомендуется в документе Host Requirements), в соответствующую опцию в поле 'option', в противном случае- Сервер не должен присылать значение этого параметра Сервер должен предоставить столько запрошенных параметров, сколько возможно, должен опустить любые параметры, которые не может предоставить. Сервер должен включить каждый запрошенный параметр только один раз, если только не разрешено обратного в опциях DHCP и в документе Vendor Extensions BOOTP.

oЛюбые параметры из существующего набора, которые отличаются от значений по умолчанию документа Host Requirements,
oЛюбые параметры, специфичные для клиента (как это с пецифицировано в содержимом 'chaddr' или 'client identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором,
oЛюбые параметры специфичные для этого класса клиента (как это идентифицировано в опции 'vendor class identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором;
oПараметры со значениями, неравными величинам по умолчанию для клиентской субсети.
Сервер может прислать 'vendor class identifier', использованный чтобы определить параметры в сообщении DHCPOFFER, чтобы помочь клиенту решить, какой выбрать DHCPOFFER. Сервер вводит поле 'xid' из сообщения DHCPDISCOVER в поле 'xid' сообщения DHCPOFFER и посылает клиенту, приславшему запрос, сообщение DHCPOFFER.


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