RFC 3344 IP Mobility Support for IPv4

Опубликовано 11.08.2002 автором Nikolai Malykh

Network Working Group                                    C. Perkins, Ed.
Request for Comments: 3344                         Nokia Research Center
Obsoletes: 3220                                              August 2002
Category: Standards Track

Поддержка IP Mobility для IPv4

IP Mobility Support for IPv4

PDF

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

Данный документ содержит спецификацию стандартного протокола Internet, предложенного сообществу Internet, и является приглашением к дискуссии в целях развития этого протокола. Сведения о текущем состоянии стандартизации протокола вы найдете в документе Internet Official Protocol Standards (STD 1). Документ можно распространять без ограничений.

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

Аннотация

Этот документ описывает расширение протокола, позволяющее прозрачно маршрутизировать дейтаграммы IP мобильным узлам в Internet. Каждый мобильный узел идентифицируется его домашним адресом, независимо от текущей точки подключения к Internet. Находящийся за пределами домашней сети мобильный узел имеет адрес обслуживания (care-of address), который обеспечивает информацию о текущей точке подключения к Internet. Протокол предусматривает регистрацию адреса обслуживания на домашнем агенте. Этот агент отправляет адресованные мобильному узлу дейтаграммы через туннель на адрес обслуживания. После прибытия дейтаграммы на удаленную сторону туннеля она передается мобильному узлу.

1. Введение

В IP версии 4 предполагается, что IP-адрес узла уникально идентифицирует точку подключения данного узла к сети Internet. Следовательно, узел должен размещаться в сети, указанной его адресом IP, чтобы получать адресованные ему пакеты. В противном случае дейтаграммы просто не дойдут до узла. Чтобы узлы могли менять точки подключения без потери возможности связи в настоящее время используется обычно один из перечисленных механизмов:

узел меняет адрес в соответствии с точкой подключения;
специфические маршруты к хостам распространяются через систему маршрутизации Internet.

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

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

Различия между этой обновленной спецификацией Mobile IP и предшествующими спецификациями (см. [33, 32, 34, 43, 8]) подробно рассмотрены в Приложении G.

1.1. Протокольные требования

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

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

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

1.2. Цели

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

1.3. Допущения

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

Этот протокол исходит из допущения, что мобильные узлы не меняют точку своего подключения к Internet чаще 1 раза в секунду.

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

1.4. Применимость

Расширение Mobile IP предназначено для обеспечения мобильным узлам возможности перехода из одной сети IP в другую. Оно одинаково подходит как для однородных, так и для разнородных сетевых сред. Т. е., Mobile IP упрощает как переход узла из одного сегмента Ethernet в другой, так и переключение из сети Ethernet в беспроводную сеть, если IP-адрес мобильного узла при таких перемещениях не меняется.

Можно рассматривать Mobile IP как решение задачи управления мобильностью на макроуровне. Для управления мобильностью на «микроуровне» (например, переключение между беспроводными точками доступа в движении) это решение подходит не столь хорошо. Если мобильный узел не просто переключается из одной сети IP в другую, а движется в процессе такого «переключения», механизмы поддержки мобильности на канальном уровне (переход из одной сети в другую — link-layer handoff) могут обеспечивать более быстрое переключение и меньшие издержки, нежели Mobile IP.

1.5. Новые архитектурные элементы

Mobile IP добавляет ряд новых функциональных элементов, перечисленных ниже.

Mobile Node — мобильный узел

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

Home Agent — домашний агент

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

Foreign Agent — внешний агент

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

Мобильный узел имеет с домашней сети адрес IP с продолжительным сроком действия. Этот домашний адрес администрируется так же, как «постоянные» адреса IP на стационарных хостах. Когда мобильное устройство отключается от домашней сети и подключается к другой, оно получает «адрес обслуживания» (care-of address), который связывается с мобильным узлом и указывает его текущую точку подключения. Мобильный узел использует свой домашний адрес в качестве адреса отправителя всех передаваемых им дейтаграмм IP, за исключением описанных в этом документе дейтаграмм, служащих для некоторых функций управления (см. параграф 3.6.1.1).

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

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

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

Authorization-enabling extension — расширение для поддержки проверки полномочий

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

В этом документе все случаи использования поддерживающего проверку полномочий расширения относятся к аутентификационным расширениям, которые разрешают восприятие сообщения Registration Request домашним агентом. Использование дополнительных протокольных структур, не описанных в данном документе, может оказаться возможным для мобильного узла с целью обеспечить его регистрацию на домашнем агенте с помощью элемента аутентификации в сети, который приемлем для домашнего агента (см., например, RFC 2794 [6]).

Agent Advertisement — анонсирование агента

Сообщение-анонс, созданное путем присоединения к маршрутным анонсам специального расширения [10].

Authentication — аутентификация

Процесс проверки (с использованием криптографических методов для всех приложений в данной спецификации) идентификации источника сообщения.

Care-of Address — адрес обслуживания

Точка завершения туннеля в направлении мобильного узла для пересылаемых такому узлу дейтаграмм в случае его подключения за пределами домашней сети. Протокол может использовать два разных типа адресов обслуживания: foreign agent care-of address представляет собой адрес внешнего агента, на котором регистрируется мобильный узел, а co-located care-of address (совмещенный адрес) — полученный извне локальный адрес, который мобильный узел связывает с одним из своих интерфейсов.

Correspondent Node — узел-корреспондент

Партнер, с которым взаимодействует мобильный узел. Это может быть стационарный или мобильный узел.

Foreign Network — чужая сеть

Любая сеть, не являющаяся домашней для мобильного узла.

Gratuitous ARP — беспричинный пакет

Пакет ARP, передаваемый узлом для того, чтобы побудить другие узлу к обновлению их кэша ARP [45] (см. параграф 4.6).

Home Address — домашний адрес ARP

Адрес IP, предоставленный мобильному узлу для использования в течение достаточно долгого срока. Этот адрес не зависит от точки подключения мобильного узла к сети Internet.

Home Network — домашняя сеть

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

Link — канал, соединение

Элемент или среда, через которые узлы взаимодействуют на канальном уровне. Располагается под сетевым уровнем.

Link-Layer Address — адрес канального уровня

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

Mobility Agent — агент мобильности

Домашний или внешний агент.

Mobility Binding — мобильная привязка

Связывание домашнего адреса с адресом обслуживания вкупе со временем существования такой привязки.

Mobility Security Association — защищенная мобильная связь

Набор защитных средств (контекстов) между парой узлов, который может быть применен к сообщениям протокола Mobile IP между этими узлами. Каждый контекст указывает алгоритм и режим аутентификации (параграф 5.1), секрет (разделяемый ключ или подходящая пара из закрытого и открытого ключей), а также стиль защиты от использования повторов (параграф 5.7).

Node — узел

Хост или маршрутизатор.

Nonce

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

Security Parameter Index (SPI) — индекс параметров защиты

Индекс, идентифицирующий контекст защиты между парой узлов из числа контекстов, доступных в Mobility Security Association. Значения SPI от 0 до 255 являются резервными, недопустимо использовать их для Mobility SA.

Tunnel — туннель

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

Virtual Network — виртуальная сеть

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

Visited Network — посещенная сеть

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

Visitor List — список посетителей

Список мобильных узлов, посетивших внешний агент.

1.7. Обзор протокола

Ниже перечислены службы, определенные для Mobile IP.

Agent Discovery — обнаружение агента

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

Registration — регистрация

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

silently discard — отбрасывание без уведомления

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

Ниже кратко описаны операции протокола Mobile IP.

Агенты мобильности (т. е., домашние и внешние агенты) анонсируют свое присутствие с помощью сообщений Agent Advertisement (раздел 2). Мобильный узел может запросить сообщение Agent Advertisement от любого локально подключенного агента мобильности с помощью отправки сообщения Agent Solicitation.
Мобильный узел получает эти сообщения Agent Advertisement и определяет подключен он к домашней или чужой сети.
Когда мобильный узел определяет свое подключение к домашней сети, он не использует службы мобильности. При возвращении в домашнюю сеть после регистрации в какой-либо чужой сети мобильный узел заново регистрируется на домашнем агенте, обмениваясь с ним сообщениями Registration Request и Registration Reply.
Когда мобильный узел определяет, что он подключен к чужой сети, он получает от этой сети адрес обслуживания. Этот адрес может быть определен из анонсов внешнего агента (адрес внешнего агента) или с помощью того или иного внешнего механизма типа DHCP [13] (совмещенный адрес обслуживания).
Работающий за пределами домашней сети мобильный узел регистрирует адрес обслуживания на своем домашнем агенте, обмениваясь с ним сообщениями Registration Request и Registration Reply (возможно через внешнего агента — см. раздел 3).
Дейтаграммы, передаваемые на домашний адрес мобильного узла, перехватываются домашним агентом, туннелируются на адрес обслуживания мобильного узла, принимаются в конечной точке этого туннеля (внешний агент или сам мобильный узел) и доставляются мобильному узлу (параграф 4.2.3).
В обратном направлении дейтаграммы от мобильного узла обычно доставляются получателям с использованием стандартных механизмов маршрутизации IP (не обязательно через домашнего агента).

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

Mobile IP предлагает два варианта получения адреса обслуживания:

Адрес внешнего агента (foreign agent care-of address) — это адрес обслуживания, предоставляемый внешним агентом в его сообщениях Agent Advertisement. В этом случае адресом обслуживания является IP-адрес внешнего агента. В этом режиме внешний агент является конечной точкой туннеля и при получении туннелированных дейтаграмм он декапсулирует их и доставляет вложенные дейтаграммы мобильному узлу. Этот режим получения адреса является предпочтительным, поскольку он позволяет множеству мобильных узлов пользоваться одним адресом обслуживания, что весьма важно в условиях дефицита адресов IPv4.
Совмещенный адрес (co-located care-of address) — это адрес обслуживания, получаемый мобильным узлом, как локальный адрес IP с помощью тех или иных внешних механизмов. Полученный адрес мобильный узел связывает с одним из своих интерфейсов. Адрес может выделяться динамически (например, через DHCP [13]) или статически на все время присутствия мобильного узла в чужой сети. Конкретные способы предоставления локальных адресов мобильным узлам для использования в качестве адресов обслуживания выходят за рамки этого документа. При использовании совмещенного адреса обслуживания мобильный узел является конечной точкой туннеля и сам выполняет декапсуляцию туннелируемых дейтаграмм.

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

Важно различать адрес обслуживания и функции внешнего агента. Адрес обслуживания просто задает конечную точку туннеля. Это может быть и адрес внешнего агента (foreign agent care-of address), но может быть и адресом, временно полученным мобильным узлом (co-located care-of address). Внешний агент, с другой стороны, является агентом мобильности, обслуживающим мобильны узлы. Дополнительная информация приведена в параграфах 3.7 и 4.2.2.

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

           2) Дейтаграмма перехватывается  3) Дейтаграмма 
              домашним агентом и              детуннелируется 
              туннелируется на адрес          и доставляется
              обслуживания.                   Мобильному узлу.

                +-----+          +-------+         +------+
                |домаш| =======> |внешний| ------> |мобил.|
                |агент|          | агент | <------ | узел |
                +-----+          +-------+         +------+
1) Дейтаграмма    /|\         /
   для мобильного  |        /   4) Для переданных мобильным 
   узла приходит   |      /        узлом используется обычная
   в домашнюю сеть |    /          маршрутизация IP. На рисунке
   обычным путем.  |  |_           внешний агент является для   
                 +----+            мобильного узла маршрутизатором
                 |хост|            по умолчанию.                
                 +----+

Рисунок 1. Работа Mobile IPv4.

Домашний агент должен быть способен перехватывать дейтаграммы, направленные любому из зарегистрированных им мобильных узлов. Использование посредника и механизмов ARP, описанных в параграфе 4.6, позволяет выполнить это требование, если домашний агент имеет интерфейс в сеть (канал), указанную домашним адресом мобильного узла. При ином расположении домашнего агента относительно домашнего местоположения мобильных узлов могут применяться иные механизмы для перехвата пакетов, адресованных на домашние адреса мобильных узлов. Рассмотрение этих вариантов выходит за рамки данного документа.

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

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

1.8. Расширяемость протокола и формата сообщений

Mobile IP определяет набор управляющих сообщений, передаваемых по протоколу UDP [37] через порт 434. В данном документе определены два типа сообщений:

1 Registration Request (запрос регистрации)

3 Registration Reply (регистрационный отклик)

Актуальные значения для типов сообщений Mobile IP указаны в документе Assigned Numbers¹ [40].

Кроме того для обнаружения агентов (Agent Discovery) Mobile IP использует сообщения Router Advertisement и Router Solicitation, определенные для ICMP Router Discovery [10].

Mobile IP определяет общий механизм расширения (Extension), позволяющий передавать дополнительную информацию в управляющих сообщениях Mobile IP и сообщениях ICMP Router Discovery. Некоторые расширения представляются в формате TLV², описанном в параграфе 1.9.

Расширения позволяют передавать в каждой дейтаграмме переменный объем информации. Завершение списка расширений указывается полем общего размера дейтаграммы IP.

В Mobile IP используется два набора номерных пространств для значения Extension Type:

Первый набор включает расширения, которые могут включаться только в управляющие сообщения Mobile IP (передаются по протоколу UDP через порт 434). В этом документе определены три типа расширений для управляющих сообщений Mobile IP:

32 Mobile-Home Authentication;

33 Mobile-Foreign Authentication;

34 Foreign-Home Authentication.
Второй набор включает расширения, которые могут включаться только в сообщения ICMP Router Discovery [10]. Данный документ определяет три типа таки расширений:

0 One-byte Padding (однобайтовое заполнение, без полей Length и Data);

16 Mobility Agent Advertisement (анонс мобильного агента);

19 Prefix-Lengths (размеры префиксов).

Каждое расширение подробно будет описано ниже. Актуальные значения Extension Type можно найти в свежей версии Assigned Numbers [40].

По причине разделения (ортогональности) этих множеств в будущем номера типов для расширений из разных множеств могут совпадать. Это не создаст проблем, поскольку одни расширения могут применяться только в управляющих сообщениях Mobile IP, а другие — только в сообщениях ICMP Router Discovery.

Поле типа в структуре расширения Mobile IP может поддерживать до 255 (пропускаемых и непропускаемых) уникально идентифицируемых расширений. Когда расширение из любого набора со значением типа от 0 до 127 не распознается, сообщение с таким расширением должно отбрасываться без уведомления. Если не распознается расширение со значением типа от 128 до 255, это конкретное расширение игнорируется, но остальные расширения и данные сообщения должны обрабатываться. Поле Length в Extension используется для пропуска поля Data при поиске следующего расширения.

Пока для типов расширений не используется дополнительная структура, новые разработки или дополнения к Mobile IP могут потребовать столько расширений, что доступного для типов расширения пространства окажется не достаточно. Для решения этой проблемы предложены две новых структуры расширения. Некоторые типы расширений можно агрегировать, используя подтипы для точной идентификации (например, это возможно для расширений Generic Authentication Keys [35]). Во многих случаях это позволяет снизить скорость добавления новых значений для поля типа.

Поскольку новые структуры повышают эффективность использования пространства типов расширений, рекомендуется для новых расширений Mobile IP следовать одному из двух предложенных форматов, если возможна группировка связанных расширений.

В последующих параграфах более подробно рассмотрены три разных структуры для расширений Mobile IP:

простой формат;
длинный формат;
короткий формат.

1.9. Формат TLV для расширений Mobile IP

Для расширений, определенных в этом документе применяется формат TLV, показанный на рисунке 2. Поскольку эта простая структура не обеспечивает повышения эффективности использования пространства типов расширений, для новых расширений Mobile IP рекомендуется использовать один из новых форматов, описанных в параграфах 1.10 и 1.11, если расширения поддерживают группировку.

 0                   1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|     Type      |    Length     |    Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 2: Формат TLV для расширений Mobile IPv4

Type

Указывает конкретный тип расширения.

Length

Указывает размер поля данных расширения в байтах. Размер не учитывает два байта полей Type и Length.

Data

Связанные с расширением данные, формат и размер которых определяется значениями полей Type и Length.

1.10. Длинный формат расширения

Этот формат применим для непропускаемых расширений, которые могут содержать более 256 данных.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |  Sub-Type     |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Data      .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Type

Поле типа, описывающее набор однотипных расширений.

Sub-Type

Уникальный номер каждого элемента в группе расширений.

Length

Размер поля данных расширения в байтах. 4 октета полей Type, Length и Sub-Type в размере не учитываются.

Data

Данные, связанные с конкретным подтипом расширения. Структура данных в этой спецификации не задается.

16-битовое поле размера позволяет данным расширения превышать размер 256 байтов.

1.11. Короткий формат расширения

Этот формат совместим с пропускаемыми расширениями, которые определены в параграфе 1.9, но не применим с расширениями, включающими более 256 байтов данных (для них используется формат, описанный в параграфе 1.10).

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |    Sub-Type   |    Data ....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Короткий формат требует присутствия в начале расширения перечисленных ниже полей.

Type

Поле типа, описывающее набор однотипных расширений.

Sub-Type

Уникальный номер каждого элемента в группе расширений.

Length

8-битовое целое число без знака, которое показывает размер расширения без учета полей Type и Length (1 + размер поля Data).

Data

Данные, связанные с конкретным подтипом расширения. Структура данных в этой спецификации не задается.

2. Обнаружение агента

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

Mobile IP расширяет механизм Router Discovery [10] для использования в целях обнаружения агента. Сообщения Agent Advertisement формируются путем включения расширений Mobility Agent Advertisement в сообщения ICMP Router Advertisement (параграф 2.1). Сообщение Agent Solicitation идентично ICMP Router Solicitation, за исключением того, что должно устанавливаться IP TTL = 1 (параграф 2.2). В этом разделе рассматриваются форматы сообщений и процедуры, с помощью которых мобильные узлы в кооперации с домашними и внешними агентами реализуют механизм Agent Discovery.

Сообщения Agent Advertisement и Agent Solicitation могут не требоваться для канальных уровней, где такая функциональность уже присутствует. Метод организации мобильным узлом соединений с потенциальными агентами на канальном уровне выходит за рамки данного документа (см. Приложение B). Описанные ниже процедуры предполагают наличие такого соединения на канальном уровне.

Для сообщений Agent Advertisement и Agent Solicitation не требуется аутентификации. Они могут быть аутентифицированы с помощью IP Authentication Header [22], но это не связано с описываемыми здесь сообщениями. Дополнительная спецификация процедур аутентификации сообщений Advertisement и Solicitation выходит за рамки данного документа.

2.1. Анонсы агента

Сообщения Agent Advertisement передаются в канал агентом мобильности для анонсирования своих услуг. Мобильные узлы используют эти анонсы для определения своей текущей точки подключения к Internet. Agent Advertisement представляет собой сообщение ICMP Router Advertisement, в которое добавлено расширение Mobility Agent Advertisement (параграф 2.1.1) и могут быть также добавлены расширения Prefix-Lengths (параграф 2.1.2), One-byte Padding (параграф 2.1.3) и другие расширения, которые будут добавлены в будущем.

В сообщении Agent Advertisement поля ICMP Router Advertisement должны соответствовать перечисленным ниже дополнительным требованиям.

Поля канального уровня

Destination Address

Адрес получатель на канальном уровне в индивидуальном сообщении Agent Advertisement должен совпадать с канальным адресом отправителя в сообщении Agent Solicitation, вызвавшем Advertisement.
Поля IP

TTL

Во всех сообщениях Agent Advertisement должно устанавливаться TTL = 1.

Destination Address

Как указано в [10] для сообщений ICMP Router Discovery, IP-адрес получателя группового сообщения Agent Advertisement должен быть 224.0.0.1 (все системы на канале) [11] или 255.255.255.255 (ограниченное широковещание). Широковещательный адрес подсети (subnet-directed broadcast) вида <prefix>.<-1> использовать не допустимо, поскольку мобильным узлам обычно не известен префикс чужой сети. Если сообщение Agent Advertisement передается индивидуально мобильному узлу, в качестве Destination Address следует использовать домашний IP-адрес мобильного узла.
Поля ICMP

Code

Поле Code в анонсах агентов интерпретируется следующим образом:

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

16 — агент мобильности не маршрутизирует трафик общего назначения. Однако все внешние агенты должны (как минимум) пересылать используемому по умолчанию все дейтаграммы, полученные от зарегистрированного мобильного узла (параграф 4.2.2).

Lifetime

Максимальное время, в течение которого сообщение Advertisement считается корректным при отсутствии других анонсов.

Router Address(es)

Адреса, которые могут присутствовать в этой части Agent Advertisement, рассмотрены в параграфе 2.3.1.

Num Addrs

Число адресов маршрутизаторов, анонсируемых в этом сообщении. Отметим, что в сообщении Agent Advertisement число адресов маршрутизаторов, заданных в ICMP Router Advertisement, может быть нулевым. Дополнительная информация приведена в параграфе 2.3.1.

При периодической передаче интервал между сообщениями Agent Advertisement следует делать не более 1/3 от анонсируемого значения Lifetime в заголовке ICMP. Этот интервал может быть короче 1/3 анонсируемого значения Lifetime. Это позволяет мобильному узлу не удалять агента из своего списка подходящих агентов даже при пропуске трех анонсов подряд. Реальное время передачи каждого анонса следует менять на случайную величину [10] для предотвращения синхронизации и последующих конфликтов с анонсами от других агентов (или с анонсами Router Advertisement от других маршрутизаторов). Отметим, что это поле не связано с полем Registration Lifetime в определенном ниже расширении Mobility Agent Advertisement.

2.1.1. Расширение для анонсов мобильного агента

Расширение Mobility Agent Advertisement использует поля анонса ICMP Router Advertisement. Это расширение служит для индикации того, что сообщение ICMP Router Advertisement является также анонсом агента (Agent Advertisement), переданным мобильным агентом. Формат Mobility Agent Advertisement Extension показан ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Registration Lifetime      |R|B|H|F|M|G|r|T|   reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                необязательные Care-of Address                 |
   |                              ...                              |

Type

Length

(6 + 4*N), где 6 учитывает число байтов в полях Sequence Number, Registration Lifetime, флагах и резервных битах, а N задает число анонсируемых адресов обслуживания.

Sequence Number

Число сообщений Agent Advertisement, переданных с момента инициализации агента (см. параграф 2.3.2).

Registration Lifetime

Максимальное время жизни (в секундах), которое этот агент будет принимать в запросах Registration. 0xffff задает бесконечное время. Это поле не связано с полем Lifetime в части ICMP Router Advertisement анонсов агента.

Требуется регистрация. Регистрация на данном (или другом на том же канале) внешнем агенте требуется даже при использовании совмещенного адреса обслуживания.

Занят. Внешний агент не принимает регистрацию для дополнительных мобильных узлов.

Домашний агент. Предлагает услуги домашнего агента на канале, в который передан анонс Agent Advertisement.

Внешний агент. Предлагает услуги внешнего агента на канале, в который передан анонс Agent Advertisement.

Минимальная инкапсуляция. Агент принимает туннелированные дейтаграммы с минимальной инкапсуляцией [34].

Инкапсуляция GRE. Агент принимает туннелированные дейтаграммы с инкапсуляцией GRE [16].

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

Внешний агент поддерживает обратное туннелирование [27].

reserved

0 при передаче, игнорируется на приемной стороне.

Care-of Address(es)

Анонсированный адрес (адреса) внешнего агента, обеспечиваемый этим агентом. Сообщение Agent Advertisement должно включать хотя бы один адрес обслуживания, если установлен бит F. Число представленных адресов обслуживания определяется значением поля Length в расширении.

Домашний агент должен быть постоянно готов к обслуживанию мобильных узлов, для которых он служит домашним агентом. Внешний агент может оказаться перегруженным и не будет способен обслуживать дополнительные узлы. В таких случаях он должен продолжать передачу сообщений Agent Advertisement, чтобы зарегистрированные мобильные узлы знали, что агент работает и продолжает их обслуживание. Внешний агент может указать свою чрезмерную загрузку (too busy), чтобы позволить регистрацию новых мобильных узлов, устанавливая бит B в своих сообщениях Agent Advertisement. В анонсах агента недопустимо устанавливать одновременно биты B и F. Кроме того, один из битов F или H должен быть установлен во всех передаваемых сообщениях Agent Advertisement.

Если внешний агент требует регистрации даже для мобильных узлов с совмещенным адресом обслуживания, он устанавливает бит R. Поскольку этот флаг применим только для внешних агентов, не допускается установка R при сброшенном флаге F.

2.1.2. Расширение Prefix-Lengths

Расширение Prefix-Lengths может следовать за расширением Mobility Agent Advertisement. Оно служит для индикации числа битов в сетевом префиксе для каждого адреса Router Address в списке ICMP Router Advertisement сообщения Agent Advertisement. Отметим, что размер префикса не относится к адресам обслуживания в расширении Mobility Agent Advertisement. Формат расширения Prefix-Lengths показан ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Prefix Length |      ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

19 (Prefix-Lengths Extension)

Length

N, где N — значение (возможно 0) поля Num Addrs в части ICMP Router Advertisement анонса Agent Advertisement.

Prefix Length

Число старших битов, определяющих номер сети для соответствующего Router Address в ICMP Router Advertisement данного сообщения. Размер префикса для каждого Router Address представляется отдельным байтом в порядке следования полей Router Address в ICMP Router Advertisement.

В параграфе 2.4.2 рассмотрено, как с помощью расширения Prefix-Lengths мобильный узел может определить факт своего перемещения в другую сеть. Детали использования расширения приведены в Приложении E.

2.1.3. Расширение для однобайтового заполнения

Некоторым реализациям протокола IP нужно заполнение сообщений ICMP для выравнивания по четному размеру. Если размер ICMP в анонсе Agent Advertisement нечетный, может использоваться данное расширение для увеличения размера до четного. Отметим, что это расширение не относится к числу расширений общего назначения для выравнивания различных полей Agent Advertisement. В анонсы Agent Advertisement не следует включать более одного расширения One-byte Padding Extension и при наличии этого расширения его следует размещать последним в Agent Advertisement.

Отметим, что в отличии от других расширений, используемых Mobile IP, расширение One-byte Padding Extension представляется одним байтом без полей Length и Data. Формат расширения One-byte Padding показан ниже.

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |     Type      |
   +-+-+-+-+-+-+-+-+

Type

0 (One-byte Padding Extension)

2.2. Сообщение Agent Solicitation

Сообщение Agent Solicitation идентично ICMP Router Solicitation, но поле IP TTL должно иметь значение 1.

2.3. Внешний агент и домашний агент

Любой агент мобильности, который не может быть обнаружен протоколом канального уровня,, должен передавать анонсы Agent Advertisement. Анонсам, которые могут быть обнаружены протоколом канального уровня, следует также реализовать Agent Advertisement. Однако анонсы не требуется передавать за исключениям ситуаций, когда политика сайта требует регистрации (установлен бит R), или в качестве отклика на конкретное сообщение Agent Solicitation. Все агенты мобильности должны обрабатывать полученные пакеты, направленные в группу Mobile-Agents по адресу 224.0.0.11. Мобильный узел может отправлять сообщения Agent Solicitation по адресу 224.0.0.11. Все агентам мобильности следует отвечать на сообщения Agent Solicitation.

Одни и те же процедуры, параметры по умолчанию и константы используются в сообщениях Agent Advertisement и сообщениях Agent Solicitation, как указано для ICMP Router Discovery в [10], за исключением перечисленного ниже.

Агент мобильности должен ограничивать скорость передачи широковещательных и групповых сообщений Agent Advertisement; максимальную скорость следует выбирать так, чтобы анонсы не отнимали значительную часть пропускной способности сети;
мобильному агенту, получившему Router Solicitation, недопустимо требовать, чтобы в поле IP Source Address был указан адрес соседа (т. е., соответствовал подсети, связанной с одним из адресов интерфейса, через который пришло сообщение).
Агент мобильности может быть настроен на передачу сообщений Agent Advertisement только в ответ на сообщения Agent Solicitation.

Если домашняя сеть не является виртуальной, домашний агент для любого мобильного узла следует размещать на канале, идентифицируемом домашним адресом мобильного узла, а передаваемые домашним агентом в этот канал сообщения Agent Advertisement должны иметь флаг H. Благодаря этому, мобильный узел в своей домашней сети может определить, что он находится дома. В любых сообщениях Agent Advertisement, передаваемых домашним агентом в другие каналы, к которым он подключен (если агент мобильности обслуживает более одного канала), недопустимо устанавливать бит H, если этот агент не является домашним и для данного канала (для других мобильных узлов). Агент мобильности может использовать разные установки для битов R, H и F на каждом сетевом интерфейсе.

Если домашняя сеть является виртуальной, она не имеет физической реализации, внешней по отношению к домашнему агенту. В этом случае нет физического сетевого соединения, в которое передаются сообщения Agent Advertisement, анонсирующие домашний агент. Мобильные пользователи, для которых такая сеть является домашней, всегда трактуются, как находящиеся дома.

В конкретной подсети все агенты мобильности должны включать расширение Prefix-Lengths Extension или все они должны отказаться от его использования. Иными словами, недопустимо использование данного расширения одними агентами в подсети, тогда как другие агенты в той же подсети не будут его включать. В противном случае один из алгоритмов детектирования перемещений для мобильных узлов не будет работать корректно (параграф 2.4.2).

2.3.1. Анонсируемые адреса маршрутизатора

Часть ICMP Router Advertisement анонса Agent Advertisement может включать один или множество адресов маршрутизаторов. Агенту следует помещать в анонс только свои собственные адреса (если они есть). Независимо от наличия его адреса в поле Router Address, внешний агент должен маршрутизировать дейтаграммы, полученные от зарегистрированных мобильных узлов (параграф 4.2.2).

2.3.2. Порядковые номера

Порядковые номера в Agent Advertisement лежат в диапазоне от 0 до 0xffff. После загрузки агент должен использовать в первом анонсе номер 0. В каждом последующем анонсе номер должен увеличиваться на 1, за исключением того, что после номера 0xffff должен следовать номер 256. Это позволяет мобильному узлу различать ситуации, когда порядковый номер меняется в результате перезагрузки агента или по причине достижения верхнего передела.

2.4. Мобильный узел

Каждый мобильный узел должен поддерживать сообщения Agent Solicitation. Ходатайства следует передавать лишь при отсутствии анонсов Agent Advertisement, если адрес обслуживания еще не был определен через протокол канального уровня или иным способом. Мобильный узел использует те же процедуры, значения по умолчанию и константы для Agent Solicitation, что указаны для сообщений ICMP Router Solicitation в [10], за исключением того, что мобильный узел может ходатайствовать более часто, чем 1 раз в 3 секунды, а не подключенный к внешнему агенту мобильный узел может передавать больше запросов, чем задает MAX_SOLICITATIONS.

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

Пока продолжается поиск агента мобильному узлу недопустимо повышать скорость передачи ходатайств, если он не имеет подтверждения своего перехода на другой канал. После регистрации мобильному узлу также следует повысить скорость передачи ходатайств при начале поиска нового агента для регистрации. При увеличении скорость может достигнуть максимального значения, но она должна ограничиваться, как указано выше. Для всех случаев рекомендуемые интервалы отправки ходатайств являются номинальными значениями. Мобильные узлы должны вносить случайные изменений в эти номинальные интервалы, как указано для ICMP Router Discovery [10].

Мобильные узлы должны обрабатывать полученные анонсы Agent Advertisement. Мобильный узел может отличить сообщение Agent Advertisement от других применений сообщения ICMP Router Advertisement, проверяя число анонсируемых адресов и поле IP Total Length. Если общий размер IP показывает, что сообщение ICMP длиннее, чем требуется для указанного числа анонсируемых адресов, остальные данные интерпретируются как одно или несколько расширений. Наличие расширения Mobility Agent Advertisement Extension идентифицирует сообщение, как анонс Agent Advertisement.

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

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

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

2.4.1. Требование регистрации

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

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

2.4.2. Детектирование перемещений

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

2.4.2.1. Алгоритм 1

Первый метод детектирования перемещений основан на использовании поля Lifetime в основном теле части ICMP Router Advertisement сообщения Agent Advertisement. Мобильному узлу следует сохранять значение, полученное в анонсах Agent Advertisement до истечения времени Lifetime. Если мобильный узел не получает другого анонса от того же агента в течение времени, заданного Lifetime, ему следует считать, что контакт с агентом потерян. Если мобильный узел при этом получил сообщение Agent Advertisement от другого агента, для которого время Lifetime еще не истекло, он может незамедлительно попытаться зарегистрироваться у этого агента. В противном случае мобильному узлу следует предпринять попытку обнаружения нового агента для регистрации.

2.4.2.2. Алгоритм 2

Во втором методе используются сетевые префиксы. В некоторых случаях мобильные узлы могут использовать расширение Prefix-Lengths для определения принадлежности недавно полученного анонса Agent Advertisement к той же подсети, из которой взят адрес обслуживания мобильного узла. Если префиксы различаются, мобильный узел может предполагать свое перемещение. Если мобильный узел в данный момент пользуется адресом внешнего агента, ему не следует применять этот метод детектирования перемещений, если в анонсах нового и текущего агентов не присутствует расширение Prefix-Lengths. Аналогично при использовании мобильным узлом совмещенного адреса обслуживания узлу не следует применять этот метод, если новый агент не включает расширение Prefix-Lengths в свои анонсы или мобильному узлу не известен сетевой префикс для своего текущего совмещенного адреса обслуживания. При завершении срока текущей регистрации, если данный метод говорит о перемещении мобильного узла, данный узел может зарегистрироваться на внешнем агенте, передавшем новое сообщение Agent Advertisement с другим сетевым префиксом. Недопустимо в таких случаях регистрироваться с использованием сообщения Agent Advertisement, для которого истек срок, заданный полем Lifetime.

2.4.3. Возвращение в домашнюю сеть

Мобильный узел может обнаружить свой возврат в домашнюю сеть при получении анонса Agent Advertisement от своего домашнего агента. В этом случае мобильному узлу следует отменить регистрацию на своем домашнем агенте (раздел 3). Перед попыткой дерегистрации мобильному узлу следует настроить свою таблицу маршрутизации на домашнюю сеть (параграф 4.2.1). Кроме того, если домашняя сеть использует ARP [36], мобильный узел должен выполнить процедуры, описанные в параграфе 4.6 применительно к ARP, proxy ARP и gratuitous (беспричинный) ARP.

2.4.4. Порядковые номера

Если мобильный узел обнаруживает два последовательных значения порядковых номеров в сообщениях Agent Advertisement от внешнего агента, где он зарегистрирован, и второй номер меньше первого и лежит в диапазоне от 0 до 255, данному узлу следует зарегистрироваться заново. Если второе значение меньше первого, но не меньше 256, мобильному узлу следует считать, что нумерация достигла максимума (0xffff) и пошла на следующий круг. Повторная регистрация в этом случае не требуется (параграф 2.3).

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

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

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

В регистрационной процедуре поддерживается ряд опциональных возможностей, доступных мобильному узлу:

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

3.1. Обзор регистрации

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

если мобильный узел регистрирует адрес внешнего агента, он должен делать это через данного агента;
если мобильный узел использует совмещенный адрес обслуживания и получил анонс Agent Advertisement от внешнего агента на канале, где он использует данный адрес обслуживания, мобильному узлу следует регистрироваться через данный внешний агент (или другой внешний агент на данном канале), если в полученном анонсе был установлен бит R;
в остальных случаях при использовании совмещенного адреса обслуживания мобильный узел должен регистрироваться непосредственно на своем домашнем агенте;
если мобильный узел вернулся в свою домашнюю сеть, он должен регистрироваться непосредственно на своем домашнем агенте.

Обе процедуры регистрации включают обмен сообщениями Registration Request и Registration Reply (параграфы 3.3 и 3.4). При регистрации через внешний агент процедура требует использования четырех сообщений:

мобильный узел передает Registration Request подходящему внешнему агенту для начала процесса;
внешний агент обрабатывает запрос и транслирует его домашнему агенту;
домашний агент передает Registration Reply внешнему агенту, принимая или отвергая полученный запрос;
внешний агент обрабатывает Registration Reply и транслирует его мобильному узлу для информирования того о результате рассмотрения запроса.

При регистрации непосредственно на домашнем агенте процедура требует двух сообщений:

мобильный узел передает Registration Request домашнему агенту;
домашний агент передает мобильному узлу Registration Reply, принимая или отвергая запрос.

Регистрационные сообщения, определенные в параграфах 3.3 и 3.4, используют протокол UDP³ [37]. В заголовок следует включать отличную от нуля контрольную сумму UDP, а получатель должен проверять эту сумму. Получателям следует воспринимать пакеты с нулевой контрольной суммой UDP. Поведение мобильного узла и домашнего агента в части восприятия пакетов с нулевым значением контрольной суммы UDP следует согласовывать в рамках связи Mobility Security Association между сторонами.

3.2. Аутентификация

Каждый мобильный узел, домашний и внешний агент должны обеспечивать поддержку связей Mobility Security Association для мобильных узлов, индексируемых по их SPI и адресам IP. Для мобильного узла должна использоваться индексация по его домашнему адресу. Требования по поддержке алгоритмов аутентификации приведены в параграфе 5.1. Регистрационные сообщения между мобильным узлом и его домашним агентом должны аутентифицироваться с поддерживающим проверку полномочий расширением (см., например, Mobile-Home Authentication Extension в параграфе 3.5.2). Это расширение должно быть первым аутентификационным расширением. В сообщение могут добавляться другие расширения, специфичные для внешнего агента, после того, как аутентификация завершится.

3.3. Запрос регистрации

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

Поля IP

Source Address — обычно адрес интерфейса, с которого передается сообщение.

Destination Address — обычно адрес домашнего или внешнего агента.

Дополнительная информация приведена в параграфах 3.6.1.1 и 3.7.2.2.

Поля UDP

Source Port — переменное.

Destination Port — 434.

Заголовок UDP, следующий за полями Mobile IP, показан ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |S|B|D|M|G|r|T|x|          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

Type

1 (Registration Request)

Одновременные (Simultaneous) привязки. Если бит S установлен, мобильный узел запрашивает у домашнего агента сохранение имеющихся привязок мобильности, как описано в параграфе 3.6.1.2.

Широковещательные (Broadcast) дейтаграммы. Установленный бит B показывает запрос мобильного узла к домашнему агенту на пересылку в туннель всех широковещательных дейтаграмм из домашней сети, как описано в параграфе 4.3.

Декапсуляция (Decapsulation) мобильным узлом. Установленный флаг D показывает, что мобильный узел желает самостоятельно декапсулировать дейтаграммы, направленные по адресу обслуживания. Это говорит об использовании мобильным узлом совмещенного адреса обслуживания.

Минимальная (Minimal) инкапсуляция. Установленный бит M означает, что домашний агент использует минимальную инкапсуляцию [34] для туннелируемых мобильному узлу дейтаграмм.

Инкапсуляция GRE. Установленный бит G говорит о том, что мобильный узел запрашивает у своего домашнего агента использование инкапсуляции GRE [16] для туннелируемых мобильному узлу дейтаграмм.

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

Запрошено обратное туннелирование (см. [27]).

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

Lifetime

Число секунд, остающихся до завершения срока действия регистрации. Нулевое значение указывает запрос отмены регистрации, значение 0xffff показывает неограниченный срок регистрации.

Home Address

IP-адрес мобильного узла.

Home Agent

IP-адрес домашнего агента мобильного узла.

Care-of Address

IP-адрес точки завершения туннеля (к мобильному узлу).

Identification

Extensions

За фиксированной частью Registration Request может следовать одно или несколько расширений, описанных в параграфе 3.5. В запросы должно включаться расширение для проверки полномочий. Порядок, в котором должны следовать расширения при их включении в запросы регистрации описан в параграфах 3.6.1.3 и 3.7.2.2.

3.4. Регистрационный отклик

Агент мобильности обычно возвращает сообщение Registration Reply мобильному узлу, передавшему Registration Request. Если мобильный узел запрашивает обслуживание у внешнего агента, этот агент обычно получает отклик от домашнего агента этого мобильного узла и пересылает его мобильному узлу. Отклики содержат коды, требуемые для информирования мобильного узла о состоянии его запроса и выделенном домашним агенте сроке регистрации, который может оказаться меньше запрошенного.

Внешнему агенту недопустимо увеличивать значение Lifetime, указанное мобильным узлом в сообщении Registration Request, поскольку поле Lifetime учитывается аутентификационным расширением, которое включает проверку полномочий на домашнем агенте. Такие расширения содержат аутентификационные данные, которые внешний агент не может корректно рассчитать. Домашнему агенту также недопустимо увеличивать значение Lifetime, указанное мобильным узлом в Registration Request, поскольку это может привести к выходу срока регистрации за пределы максимального значения Registration Lifetime, разрешаемого вешним агентом. Если значение Lifetime в полученном сообщении Registration Reply превышает значение в отправленном сообщении Registration Request, должно использоваться значение Lifetime из запроса. Если значение Lifetime в отклике меньше значения этого поля в запросе, должно использоваться значение Lifetime из сообщения Registration Reply.

Поля IP

Source Address — обычно копируется из поля Destination Address сообщения Registration Request, на которое агент отвечает. Дополнительная информация приведена в параграфах 3.7.2.3 и 3.8.3.1.

Destination Address — копируется из поля Source Address сообщения Registration Request, на которое агент отвечает.

Поля UDP

Source Port — переменный.

Destination Port — копируется из поля UDP Source Port соответствующего запроса (параграф 3.7.1).

Заголовок UDP, следующий за полями Mobile IP, показан ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

Type

3 (Registration Reply)

Code

Значение, показывающее результат обработки Registration Request. Значения кодов приведены ниже.

Lifetime

Если поле Code говорит, что регистрация была воспринята, в поле Lifetime указывается число секунд, оставшихся до завершения срока регистрации. Нулевое значение указывает отмену регистрации мобильного узла, значение 0xffff показывает неограниченный срок регистрации. Если значение Code говорит об отказе в регистрации, содержимое поля Lifetime не задается и должно игнорироваться при получении.

Home Address

IP-адрес мобильного узла.

Home Agent

IP-адрес домашнего агента мобильного узла.

Identification

64-битовое число, создаваемое мобильным узлом и служащее для сопоставления запросов и откликов на них, а также защиту от атак с повторным использованием регистрационных сообщений. Значение определяется значением поля Identification из сообщения Registration Request от мобильного узла и стилем защиты от повторного использования пакетов в контексте защиты между мобильным узлом и домашним агентом (определяется Mobility Security Association и значением SPI в разрешающем проверку полномочий расширении). См. параграфы 5.4 и 5.7.

Extensions

За фиксированной частью запроса Registration Request может следовать одно или несколько расширений, описанных в параграфе 3.5. Разрешающее проверку полномочий расширение должно включаться во все регистрационные отклики, возвращаемые домашним агентом. Правила размещения расширений в откликах приведены в параграфах 3.7.2.2 и 3.8.3.3.

Ниже приведены значения, определенные для поля Code.

Успешная регистрация

0 регистрация принята;

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

Регистрация отвергнута внешним агентом

64 причина отказа не указана;

65 административный запрет;

66 недостаточно ресурсов;

67 отказ при аутентификации мобильного узла;

68 отказ при аутентификации домашнего агента;

69 запрошенное значение Lifetime слишком велико;

70 некорректный формат сообщения Request;

71 некорректный формат сообщения Reply;

72 запрошенная инкапсуляция не поддерживается;

73 резерв (не используется);

77 недопустимый адрес обслуживания;

78 тайм-аут при регистрации;

80 домашняя сеть недоступна (получена ошибка ICMP);

81 хост домашнего агента недоступен (получена ошибка ICMP);

82 порт домашнего агента недоступен (получена ошибка ICMP);

88 домашний агент недоступен (получена другая ошибка ICMP).

Регистрация отвергнута домашним агентом

128 причина не указана;

129 административный запрет;

130 недостаточно ресурсов;

131 отказ при аутентификации мобильного узла;

132 отказ при аутентификации внешнего агента;

133 несоответствие Identification;

134 некорректный формат сообщения Request;

135 слишком много одновременных привязок мобильности;

136 не известен адрес домашнего агента.

Актуальные значения кодов приведены в свежей редакции документа Assigned Numbers [40].

3.5. Регистрационные расширения

3.5.1. Расчет значений аутентификационного расширения

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

данные UDP (т. е., данные Registration Request или Registration Reply);
все предшествующие расширения целиком;
поля Type, Length и SPI данного расширения.

По умолчанию используется алгоритм HMAC-MD5 [23] для расчета 128-битовой цифровой подписи регистрационного сообщения. При расчете HMAC учитываются следующие данные:

данные UDP (т. е., данные Registration Request или Registration Reply);
все предшествующие расширения целиком;
поля Type, Length и SPI данного расширения.

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

Индекс параметров защиты (SPI⁴) в любом аутентификационном расширении определяет контекст защиты, который применяется для расчета значения Authenticator и должен использоваться получателем для проверки принятого значения. В частности, SPI выбирает алгоритм и режим аутентификации (параграф 5.1), а также секрет (разделяемый ключ или подходящую пару из открытого и закрытого ключей), применяемый при расчете значения Authenticator. Для обеспечения совместимости реализаций Mobile IP каждая реализация должна быть способна связать любое значение SPI с любым поддерживаемым алгоритмом и режимом аутентификации. Кроме того, все реализации Mobile IP должны поддерживать используемый по умолчанию алгоритм аутентификации HMAC-MD5, указанный выше.

3.5.2. Расширение Mobile-Home Authentication

Во всех сообщениях Registration Request, а также генерируемых домашним агентом сообщениях Registration Reply должно присутствовать в точности одно разрешающее аутентификацию расширение. Mobile-Home Authentication Extension всегда является разрешающим аутентификацию расширением для описанных в этом документе регистрационных сообщений. Это требование обусловлено необходимостью предотвращения проблем [2], возникающих в результате неконтролируемого распространения удаленных перенаправлений в Internet. Местоположение разрешающего аутентификацию расширения указывает окончание аутентифицируемых данных.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

4 + число байтов в поле Authenticator.

SPI

Индекс параметров защиты (4 байта). Неразбираемый идентификатор (см. параграф 1.6).

Authenticator

(переменный размер) (см. параграф 3.5.1.)

3.5.3. Расширение Mobile-Foreign Authentication

Это расширение может включаться в регистрационные запросы и отклики при существовании между мобильным узлом и внешним агентом защищенной связи. Требования поддержки для кодов аутентификации сообщений описаны в параграфе 5.1.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

4 + число байтов в поле Authenticator.

SPI

Индекс параметров защиты (4 байта). Неразбираемый идентификатор (см. параграф 1.6).

Authenticator

(переменный размер) (см. параграф 3.5.1.)

3.5.4. Расширение Foreign-Home Authentication

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

4 + число байтов в поле Authenticator.

SPI

Индекс параметров защиты (4 байта). Неразбираемый идентификатор (см. параграф 1.6).

Authenticator

(переменный размер) (см. параграф 3.5.1.)

3.6. Мобильные узлы

На мобильном узле должна быть (статически или динамически) задана маска сети и Mobility Security Association для каждого из его домашних агентов. В дополнение к этому на мобильном узле может быть установлен домашний адрес и IP-адреса одного или нескольких домашних агентов. Если этого не сделано, мобильный узел может определить адрес домашнего агента, используя процедуры, описанные в параграфе 3.6.1.2.

Если на мобильном узле не настроен домашний адрес, он может использовать расширение Mobile Node Network Access (NAI) [6] для самоидентификации и установить в поле Home Address сообщения Registration Request значение 0.0.0.0. В таких случаях мобильный узел должен быть способен присвоить себе домашний адрес после извлечения нужной информации из сообщения Registration Reply от домашнего агента.

Для каждой ожидающей регистрации мобильный узел поддерживает следующую информацию:

адрес канального уровня внешнего агента, которому было отправлено сообщение Registration Request (если такой адрес имеется),
IP Destination Address из сообщения Registration Request,
адрес обслуживания, используемый при регистрации,
значение Identification, переданное при регистрации,
запрошенное изначально значение Lifetime,
оставшееся время Lifetime для ожидающей регистрации.

Мобильному узлу следует инициировать регистрацию при обнаружении смены своего подключения к сети. Методы, с помощью которых мобильный узел может это обнаружить, описаны в параграфе 2.4.2. При выходе мобильного узла из домашней сети сообщение Registration Request от такого узла позволяет домашнему агенту создать или изменить для этого узла привязку мобильности. Для находящегося в домашней сети мобильного узла такое сообщение позволяет домашнему агенту удалить существующие мобильные привязки для этого узла. В домашней сети мобильный узел работает без использования функций мобильности.

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

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

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

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

3.6.1. Отправка регистрационных запросов

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

3.6.1.1. Поля IP

В этом параграфе описаны правила, в соответствии с которыми мобильные узлы заполняют поля заголовков IP для сообщений Registration Request.

IP Source

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

IP Destination

Когда мобильный узел нашел агента, на котором зарегистрирован тем или иным способом, не сообщающим IP-адрес агента (например, на канальном уровне), должен указываться адрес получателя All Mobility Agents (224.0.0.11). В этом случае мобильный узел должен использовать индивидуальный адрес канального уровня для доставки дейтаграммы нужному агенту.
Когда при регистрации у внешнего агента, должен указываться его адрес, взятый из поля IP source соответствующего анонса Agent Advertisement. Это может оказаться адресом, который не анонсируется в качестве адреса обслуживания в Agent Advertisement. Кроме того, при передаче этого сообщения Registration Request мобильный узел должен использовать адрес получателя на канальном уровне, взятый из соответствующего поля анонса Agent Advertisement, где был найден IP-адрес внешнего агента.
Когда мобильный узел регистрируется напрямую у своего домашнего агента и знает его (индивидуальный) адрес IP, это адрес должен указываться в поле IP Destination.
Если мобильный узел напрямую регистрируется у домашнего агента, но не знает его адреса IP, он может использовать динамическое преобразование для автоматического определения нужного адреса IP (параграф 3.6.1.2). В этом случае в поле IP Destination помещается широковещательный адрес (subnet-directed) домашней сети мобильного узла. Такой адрес недопустимо использовать в качестве адреса получателя, если мобильный узел регистрируется через внешний агент, хотя этот адрес можно указывать в теле сообщения Registration Request при такой регистрации.

IP TTL

В поле IP TTL должно указываться значение 1, если в качестве адреса получателя используется All Mobility Agents, как указано выше. В остальных случаях задается подходящее значение в соответствии с обычной практикой IP [38].

3.6.1.2. Поля регистрационного запроса

В этом параграфе представлены специфические правила, в соответствии с которыми мобильные узлы устанавливают значения полей в фиксированной части сообщений Registration Request.

Мобильный узел может установить бит S для того, чтобы запросить у домашнего агента поддержку предыдущих привязок мобильности. Без этого домашний агент будет удалять все прежние привязки, заменяя их новой привязкой, которая задана в Registration Request. Множество одновременных привязок полезно в тех случаях, когда мобильный узел, использующий хотя бы одну беспроводную сеть, перемещается в области покрытия обслуживаемой несколькими внешними агентами. IP явно разрешает дублирование дейтаграмм. Если домашний агент разрешает множественные привязки, он будет туннелировать копии каждой прибывающей дейтаграммы на все адреса обслуживания и мобильный узел будет получать множество таких копий.

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

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

Установленный бит D показывает, что мобильный узел будет самостоятельно декапсулировать все дейтаграммы, туннелированные на этот адрес обслуживания (совмещенный). В этом случае для пересылки мобильному узлу полученных широковещательных дейтаграмм домашний агент должен туннелировать их на адрес обслуживания. Мобильный узел детуннелирует такие дейтаграммы так же, как он делает это с дейтаграммами, адресованными непосредственно ему.
Сброшенный бит D показывает, что мобильный узел использует для обслуживания адрес внешнего агента, который будет декапсулировать дейтаграммы до их пересылки мобильному узлу. В этом случае для пересылки полученных широковещательных дейтаграмм мобильному узлу домашний агент должен инкапсулировать их в unicast-дейтаграммы, направленные по домашнему адресу мобильного узла, а потом должен туннелировать их на адрес обслуживания мобильного узла.

После декапсуляции внешним агентом внутренняя дейтаграмма будет обычной (unicast) дейтаграммой IP, адресованной мобильному узлу, что показывает внешнему агенту направление ее пересылки. Доставка ее мобильному узлу осуществляется так же, как доставляются тому обычные дейтаграммы. Мобильному узлу недопустимо декапсулировать вложенные широковещательные дейтаграммы и недопустимо для их пересылки мобильному узлу использовать локальное широковещание. Мобильный узел должен декапсулировать широковещательную дейтаграмму самостоятельно. Следовательно, для мобильного узла в таких случаях недопустима установка бита B в Registration Request, если он не способен декапсулировать дейтаграммы.

Мобильный узел может запрашивать дополнительные формы инкапсуляции, устанавливая бит M и/или G, но только в тех случаях, когда он самостоятельно декапсулирует дейтаграммы (использует совмещенный адрес обслуживания) или внешний агент указал поддержку этих форм инкапсуляции, установив соответствующие биты в расширении Mobility Agent Advertisement анонса Agent Advertisement, полученного мобильным узлом. В остальных случаях для мобильного узла установка этих битов недопустима.

Выбор значения поля Lifetime показан ниже:

Если мобильный узел регистрируется с внешним агентом, значение поля Lifetime не следует делать больше значения поля Registration Lifetime в сообщении Agent Advertisement, полученном от внешнего агента. Когда метод определения адреса обслуживания не включает Lifetime, может использоваться принятое по умолчанию значение ICMP Router Advertisement Lifetime (1800 секунд).
Мобильный узел может попросить домашнего агента удалить конкретную привязку мобильности, отправив тому сообщение Registration Request с адресом обслуживания этой привязки и Lifetime = 0 (параграф 3.8.2).
Аналогично с помощью Lifetime = 0 мобильный узел может отменить регистрацию всех адресов обслуживания при возвращении в домашнюю сеть.

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

В поле Home Agent должен указываться адрес домашнего агента мобильного узла, если этот адрес известен. В противном случае мобильный узел может использовать динамическое определение адреса домашнего агента. Для этого мобильный узел должен установить в поле Home Agent широковещательный адрес subnet-directed своей домашней сети. Каждый домашний агент, получив сообщение Registration Request с широковещательным адресом получателя, должен отвергнуть регистрацию мобильного узла, которому следует возвратить сообщение Registration Reply, показывающее индивидуальный адрес IP для использования при последующей попытке регистрации.

В поле Care-of Address должен указываться конкретный адрес обслуживания, который мобильный узел хочет (де)регистрировать. Если мобильный узел хочет отменить регистрацию всех своих адресом обслуживания, он должен указать в этом поле свой домашний адрес.

Мобильный узел выбирает значение поля Identification в зависимости от способа защиты от повторного использования пакетов, который применяется для его домашнего агента. Это является частью защищенной мобильной связи между мобильным узлом и его домашним агентом. Метод расчета поля Identification описан в параграфе 5.7.

3.6.1.3. Расширения

В этом параграфе описан порядок всех обязательных и необязательных расширений, которые мобильный узел добавляет в конце сообщения Registration Request. Расширения должны указываться в приведенном ниже порядке.

После заголовка IP следует заголовок UDP, а за ним фиксированная часть Registration Request, после которой
могут присутствовать какие-либо, не связанные с аутентификацией расширения, которые могут использоваться домашним агентом (и могут оказаться полезны внешнему агенту), а за ними
разрешающее аутентификацию расширение, после которого
могут присутствовать любые, не относящиеся к аутентификации расширения, используемые только внешним агентом, а затем
может следовать расширение Mobile-Foreign Authentication.

Отметим, что элементы a) и c) должны присутствовать в каждом сообщении Registration Request от мобильного узла. Элементы b), d) и e) не обязательны. Однако элемент e) должен включаться в сообщения при использовании мобильным узлом и внешним агентом общей защищенной связи.

3.6.2. Получение регистрационных откликов

Сообщения Registration Reply мобильный узел получает в ответ на свои сообщения Registration Request. Отклики при регистрации обычно делятся на три категории:

запрос был принят;
запрос был отклонен внешним агентом;
регистрация была отвергнута домашним агентом.
В оставшейся части этого раздела рассматривается обработка мобильным узлом сообщений Registration Reply каждой из трех категорий.

3.6.2.1. Проверка применимости

Отклики Registration Reply с ненулевой некорректной контрольной суммой UDP должны отбрасываться без уведомления.

Кроме того, 32 младших бита поля Identification в Registration Reply должны сравниваться с 32 младшими битами поля Identification в последнем сообщении Registration Request, отправленном отвечающему агенту. При несоответствии отклик должен отбрасываться без уведомления.

В дополнение к этому сообщения Registration Reply должны проверяться на предмет наличия разрешающего аутентификацию расширения. Для всех сообщений Registration Reply, содержащих Status Code с кодом статуса от домашнего агента, мобильный узел должен проверять наличие разрешающего аутентификацию расширения и действовать с соответствии со значением поля Code в отклике. Правила приведены ниже.

Если мобильный узел и внешний агент используют защищенную связь Mobility Security Association, в отклике Registration Reply должно присутствовать в точности одно расширение Mobile-Foreign Authentication и мобильный узел должен проверить значение Authenticator в этом расширении. Если расширения Mobile-Foreign Authentication не найдено, присутствует несколько таких расширений или значение Authenticator неприемлемо, мобильный узел должен отбросить отклик без уведомления (следует также сделать запись в системном журнале о нарушении безопасности).
Если поле Code указывает, что обслуживание было отвергнуто домашним агентом или регистрация была воспринята им, в сообщении Registration Reply должно присутствовать в точности одно расширение Mobile-Home Authentication и мобильный узел должен проверить значение Authenticator в этом расширении. Если отклик был создан домашним агентом, но расширения Mobile-Home Authentication в нем не найдено, присутствует несколько таких расширений или значение Authenticator неприемлемо, мобильный узел должен отбросить отклик без уведомления (следует также сделать запись в системном журнале о нарушении безопасности).

Если значение Code говорит об отказе при аутентификации со стороны домашнего или внешнего агента, вполне возможно наличие ошибок в полях Authenticator сообщения Registration Reply. Это может произойти, например, при некорректной настройке совместно используемого мобильным узлом и домашним агентом секрета. Мобильному узлу следует занести в системный журнал запись о нарушении безопасности.

3.6.2.2. Регистрационный запрос принят

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

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

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

3.6.2.3. Регистрационный запрос отвергнут

Если поле Code показывает, что запрос на обслуживание был отвергнут, мобильному узлу следует занести в системный журнал запись об ошибке. В некоторых случаях мобильный узел может решить проблему сам. К таким случаям относятся:

Code 69: (отвергнуто внешним агентом, запрошенное значение Lifetime слишком велико)

В этом случае поле Lifetime в сообщении Registration Reply будет показывать максимальное значение Lifetime, которое внешний агент согласен принимать в сообщениях Registration Request. Мобильный узел может повторить попытку регистрации у того же внешнего агента, установив для поля Lifetime в сообщении Registration Request значение, которое должно быть не больше указанного в отклике времени.

Code 133: (отвергнуто домашним агентом, несоответствие Identification)

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

Code 136: (отвергнуто домашним агентом, неизвестный адрес домашнего агента)

Этот код может возвращаться домашним агентом в тех случаях, когда мобильный узел определяет адрес домашнего агента динамически, как описано в параграфах 3.6.1.1 и 3.6.1.2. В таких случаях поле Home Agent в отклике будет содержать индивидуальный IP-адрес передающего отклик домашнего агента. Мобильный узел может повторить попытку регистрации, указав полученный адрес в последующем сообщении Registration Request. Кроме того, мобильному узлу следует до новой попытки регистрации настроить параметры, используемые для расчета поля Identification с учетом значений соответствующих полей из полученного сообщения Registration Reply.

3.6.3. Повтор передачи при регистрации

При отсутствии отклика Registration Reply в течение достаточно продолжительного времени, возможна повторная передача сообщения Registration Request. При использовании временных меток для каждого повтора используется новое значение Identification и каждое сообщение, по сути, является новой регистрацией. При использовании маркеров nonce запросы передаются повторно без изменений и повтор не учитывается, как новая регистрация (параграф 5.7). За счет этого повторная передача не будет требовать от домашнего агента повторной синхронизации с мобильным узлом за счет использования другого маркера nonce, как происходит в случае потери исходного сообщения Registration Request (с меньшей вероятностью, Registration Reply) в сети.

Максимальное время до повтора передачи Registration Request следует делать не больше значения Lifetime, указанного в Registration Request. Минимальный интервал до повтора следует делать достаточно большим, принимая во внимание размер сообщений — подойдет двойное время кругового обхода между мобильным узлом и домашним агентом, к которому добавлено по крайней мере 100 мсек на обработку сообщения перед откликом. Время кругового обхода для передачи домашнему агенту будет не меньше времени, требуемого для передачи сообщения через канал в текущей точке подключения мобильного узла. Некоторые устройства добавляют еще 200 мсек задержки при передаче домашнему агенту с учетом возможности наличия на пути спутникового канала. Минимальное время между повторами сообщений Registration Request недопустимо делать меньше 1 секунды. Каждый последующий интервал до повтора следует увеличивать по крайней мере вдвое по сравнению с предыдущим, пока не будет достигнуто максимальное значение, рассмотренное выше.

3.7. Внешний агент

Роль внешнего агента в процессе регистрации Mobile IP в основном пассивна. Он транслирует регистрационные запросы между мобильными узлами и их домашними агентами и, в случае предоставления своего адреса для обслуживания мобильных клиентов, декапсулирует дейтаграммы для доставки мобильному узлу. Внешним агентам следует периодически отправлять сообщения Agent Advertisement для анонсирования своего присутствия, как описано в параграфе 2.3, если агент не может быть обнаружен средствами канального уровня.

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

3.7.1. Таблицы конфигурации и регистрации

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

адрес мобильного узла на канальном уровне;
домашний IP-адрес мобильного узла или его совмещенный адрес обслуживания (см. описание бита R в параграфе 2.1.1);
IP-адрес получателя (см. параграф 3.6.1.1);
UDP-порт источника;
адрес домашнего агента;
значение поля Identification;
запрошенное значение Lifetime;
остающееся время ожидающей или действующей регистрации.

Если в регистрационном указано нулевое значение Home Address, внешний агент должен следовать процедурам, описанным в RFC 2794 [6]. В частности, если внешний агент не может управлять записями для ожидающих сообщений Registration Request с нулевым значением Home Address, этот агент должен возвращать мобильному узлу сообщение Registration Reply с кодом NONZERO_HOMEADDR_REQD (см. [6]).

Конфигурация внешнего агента может ограничивать число ожидающих регистраций, которые она готова поддерживать (обычно 5). В этом случае внешнему агенту следует отвергать дополнительные попытки регистрации с кодом 66. Внешний агент может удалить любой регистрационный запрос, ожидающий более 7 секунд; в этом случае внешнему агенту следует отвергнуть запрос с кодом 78 (тайм-аут при регистрации).

Как любой узел в сети Internet, внешний агент может организовывать защищенные связи Mobility Security Association с другими узлами. При трансляции сообщений Registration Request от мобильного узла его домашнему агенту, если у внешнего агента имеется Mobility Security Association с этим домашним агентом, он должен добавлять в запрос расширение Foreign-Home Authentication. В таких случаях, когда сообщение Registration Reply включает отличное от 0 значение Lifetime, внешний агент должен проверить наличие требуемого расширения Foreign-Home Authentication в сообщении Registration Reply от домашнего агента (параграфы 3.3 и 3.4). Аналогично, при получении Registration Request от мобильного узла и наличии Mobility Security Association с этим узлом внешний агент должен проверить наличие требуемого расширения Mobile-Foreign Authentication в запросе и должен добавлять в отклики для этого узла расширение Mobile-Foreign Authentication.

3.7.2. Получение регистрационных запросов

Если внешний агент воспринимает сообщение Registration Request от мобильного узла, он убеждается в том, что указанный там домашний агент не подключен к какому-либо из сетевых интерфейсов внешнего агента. Если такого подключения не обнаружено, внешний агент должен транслировать запрос указанному домашнему агенту. В противном случае, если внешний агент отвергает запрос, он должен передать мобильному узлу сообщение Registration Reply с подходящим кодом отказа, но частота передачи таких сообщений не должна превышать 1 сообщения в секунду для данного мобильного узла. Этот вопрос более подробно рассматривается в последующих параграфах.

Если на одном из интерфейсов внешнего агента установлен адрес IP, который указан мобильным узлом в качестве адреса домашнего агента, внешнему агенту недопустимо пересылать такой запрос. Если внешний агент обслуживает мобильный узел в качестве домашнего агента, он должен следовать процедурам, описанным в параграфе 3.8.2. В противном случае (если внешний агент не обслуживает мобильный узел в качестве домашнего агента) внешний агент отвергает запрос с возвратом кода ошибки 136 (неизвестный адрес домашнего агента).

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

3.7.2.1. Проверка применимости

Сообщения Registration Request с некорректной, отличной от нуля контрольной суммой UDP должны отбрасываться без уведомления. Запросы с отличными от 0 резервными полями должны отвергаться с кодом 70 (некорректный формат запроса). Запросы со сброшенным флагом D и отличным от нуля полем Lifetime, указывающие адрес обслуживания, не являющийся адресом внешнего агента, должны отвергаться с кодом 77 (недопустимый адрес обслуживания).

В сообщениях Registration Request должна проверяться аутентификация. Если между мобильным узлом и внешним агентом имеется защищенная связь Mobility Security Association, в запросе должно присутствовать в точности одно расширение Mobile-Foreign Authentication и внешний агент должен проверять значение Authenticator в таком расширении. Если расширение не найдено, обнаружено несколько расширений или значение Authenticator не приемлемо, внешний агент должен отбросить запрос без уведомления. Следует также записать информацию о таком запросе в системный журнал. Внешнему агенту следует также передать мобильному узлу сообщение Registration Reply с кодом 67.

3.7.2.2. Пересылка применимых запросов домашнему агенту

Если внешний агент принимает регистрационный запрос мобильного узла, он должен транслировать этот запрос домашнему агенту данного узла, указанному в поле Home Agent сообщения Registration Request. Внешнему агенту недопустимо менять какие-либо поля, начиная с фиксированной части сообщения Registration Request и заканчивая Mobile-Home Authentication Extension (включая его) или другим аутентификационным расширением, представленным мобильным узлом в качестве разрешающего аутентификацию расширения для домашнего агента. В противном случае с высокой вероятностью аутентификация на домашнем агенте завершится отказом. Кроме того, внешний агент выполняет следующие операции:

должен обработать и удалить любые расширения, кроме предшествующих расширению, разрешающему проверку полномочий;
может добавить любое из своих не относящихся к аутентификации расширений для домашнего агента;
должен добавить в конце расширение Foreign-Home Authentication, если имеется защищенная связь с домашним агентом.

Поля заголовков IP и UDP в транслируемых сообщениях Registration Request должны устанавливаться в соответствии с приведенными ниже правилами.

IP Source Address

Адрес внешнего агента на интерфейсе, через который будет передано сообщение.

IP Destination Address

Копируется из поля Home Agent в сообщении Registration Request.

UDP Source Port

<переменный>

UDP Destination Port

434

После пересылки корректного сообщения Registration Request домашнему агенту внешний агент должен начать отсчет оставшегося времени для ожидающей регистрации со значения поля Lifetime в Registration Request. Если отсчет таймера завершится до получения приемлемого сообщения Registration Reply, внешний агент должен удалить запись для ожидающей регистрации из своего списка посетителей.

3.7.2.3. Отказы для недопустимых запросов

Если внешний агент по какой-либо причине отвергает регистрационный запрос мобильного узла, ему следует возвратить сообщение Registration Reply с подходящим кодом отказа. В таких случаях поля Home Address, Home Agent, и Identification копируются в сообщение Registration Reply из соответствующих полей Registration Request.

Если значение поля Reserved отлично от 0, внешний агент должен отвергнуть запрос и мобильному узлу следует отправить сообщение Registration Reply с кодом 70. Если запрос отвергается по причине слишком большого значения Lifetime в запросе, внешний агент устанавливает в поле Lifetime возвращаемого отклика максимальное значение срока регистрации, которое может быть принято для регистрационного запроса и помещает в поле Code значение 69. В остальных случаях значение Lifetime следует копировать из одноименного поля в запросе.

Ниже показаны значения, которые должны помещаться в поля заголовков IP и UDP для сообщений Registration Reply.

IP Source Address

Копируется из поля IP Destination Address сообщения Registration Request, если там не был указан адрес All Agents Multicast. В последнем случае должен использоваться адрес интерфейса внешнего агента, через который сообщение передается.

IP Destination Address

Если сообщение Registration Reply генерируется внешним агентом для отказа от регистрации мобильного узла и в поле Home Address регистрационного запроса указано значение, отличное от 0.0.0.0, значение поля IP Destination Address копируется из поля Home Address в сообщении Registration Request. В противном случае, если сообщение Registration Reply получено от домашнего агента и содержит отличное от 0.0.0.0 поле Home Address, значение IP Destination Address копируется из поля Home Address сообщения Registration Reply. В остальных случаях для поля IP Destination Address в Registration Reply устанавливается значение 255.255.255.255.

UDP Source Port

434

UDP Destination Port

Копируется из поля UDP Source Port регистрационного запроса.

3.7.3. Получение регистрационных откликов

Внешний агент обновляет свой список посетителей при получении приемлемого сообщения Registration Reply от домашнего агента. Полученное сообщение транслируется мобильному узлу. Более подробное описание этого приведено в последующих параграфах.

Если при трансляции сообщения Registration Request домашнему агенту внешний агент получает сообщение ICMP об ошибке вместо Registration Reply, тогда этому агенту следует отправить мобильному узлу сообщение Registration Reply с подходящим кодом отказа (домашний агент недоступен) из диапазона кодов 80-95. Создание сообщений Registration Reply описано в параграфе 3.7.2.3.

3.7.3.1. Проверка применимости

Сообщения Registration Reply с некорректно, отличной от 0 контрольной суммой UDP должны отбрасываться без уведомления.

При получении внешним агентом сообщения Registration Reply он должен просмотреть свой список посетителей на предмет ожидающих сообщений Registration Request с тем же домашним адресом мобильного узла, какой указан в полученном отклике. Если для этого адреса найдено множество записей и в сообщении Registration Reply имеется расширение Mobile Node NAI [2], внешний агент должен использовать NAI для устранения неоднозначности с ожидающими регистрационными запросами. Если соответствующего запроса в списке не найдено и сообщение Registration Reply не соответствует ни одному из ожидающих регистрационных запросов с нулевым домашним адресом мобильного узла (см. параграф 3.7.1), внешний агент должен отбросить отклик без уведомления. Отклики также должны отбрасываться без уведомления, если младшие 32 бита поля Identification не соответствуют таким же битам в запросе.

Должна также проверяться аутентификация в Registration Reply. Если между внешним и домашним агентом имеется защищенная связь Mobility Security Association, в сообщении должно присутствовать в точности одно расширение Foreign-Home Authentication и внешний агент должен проверять значение Authenticator в нем. Если расширения Foreign-Home Authentication не найдено, обнаружено несколько таких расширений или значение Authenticator неприемлемо, внешний агент должен отбросить отклик без уведомления и ему также следует сделать запись о нарушении безопасности в системный журнал. Внешний агент в этом случае должен также отвергать регистрацию мобильного узла, которому следует отправить сообщение Registration Reply с кодом 68.

3.7.3.2. Пересылка откликов мобильному узлу

Сообщения Registration Reply, прошедшие проверки из параграфа 3.8.2.1, транслируются мобильному узлу. Внешний агент в этом случае должен обновить свой список посетителей с учетом результата регистрационного запроса, указанного полем Code в отклике. Если код показывает восприятие запроса домашним агентом и значение поля Lifetime отлично от 0, внешнему агенту следует установить в поле Lifetime своего списка посетителей меньшее из:

значение поля Lifetime в сообщении Registration Reply;
максимально допускаемое внешним агентом значение Lifetime.

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

Внешнему агенту недопустимо менять какие-либо поля, начиная с фиксированной части Registration Reply и заканчивая расширением Mobile-Home Authentication (включительно). В противном случае на стороне мобильного узла с высокой вероятностью возникнет отказ аутентификации.

В дополнение к этому внешнему агенту следует выполнять перечисленные ниже процедуры:

он должен обработать и удалить все расширения, не относящиеся к аутентификационным;
он может добавить в конец свои, не относящиеся к аутентификации расширения, передающие информацию мобильному узлу;
он должен добавить в коней расширение Mobile-Foreign Authentication, если имеется защищенная связь Mobility Security Association с мобильным узлом.

Поля заголовков IP и UDP в транслируемых сообщениях Registration Reply устанавливаются в соответствии с правилами, приведенными в параграфе 3.7.2.3.

После пересылки приемлемого сообщения Registration Reply мобильному узлу внешний агент должен обновить для этой регистрации запись в списке посетителей. Если сообщение Registration Reply указывает восприятие регистрации домашним агентом, внешний агент устанавливает для таймера срока регистрации значение поля Lifetime из сообщения Registration Reply. В отличии от мобильного узла, отсчитывающего срок регистрации в соответствии с параграфом 3.6.2.2, внешний агент начинает свой отсчет с момента пересылки сообщения Registration Reply — это гарантирует, что отсчет срока регистрации на внешнем агенте не завершится раньше, нежели на мобильном узле. Если же сообщение Registration Reply показывает, что регистрация была отвергнута домашним агентом, внешний агент удаляет из списка посетителей запись для этой попытки регистрации.

3.8. Домашний агент

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

Домашнему агенту недопустимо передавать сообщения Registration Reply за исключением случаев ответа на сообщения Registration Request от мобильного узла. В частности, домашнему агенту недопустимо генерировать сообщения Registration Reply для индикации завершения срока регистрации (Lifetime).

3.8.1. Таблицы конфигурации и регистрации

На каждом домашнем агенте должен быть задан адрес IP и размер префикса для домашней сети. На домашнем агенте должна быть настроена защищенная связь Mobility Security Association с каждым уполномоченным мобильным узлом, который он обслуживает.

Когда домашний агент воспринимает корректное сообщение Registration Request от мобильного узла, который он обслуживает, этот агент должен создать или изменить для этого узла привязку мобильности, содержащую:

домашний адрес мобильного узла;
адрес обслуживания мобильного узла;
поле Identification из сообщения Registration Reply;
остающийся срок регистрации (Lifetime).

Домашний агент может предлагать динамическое выделение домашнего адреса мобильному узлу при получении от того сообщения Registration Request. Методы выделения динамических адресов выходят за рамки данного документа и рассмотрены в работе [6]. После того, как домашний агент свяжет с мобильным узлом домашний адрес, агент должен поместить этот адрес в поле Home Address сообщения Registration Reply.

Домашний агент может также поддерживать защищенные связи с разными внешними агентами. При получении сообщения Registration Request от внешнего агента, с которым имеется защищенная связь, домашний агент должен проверить значение Authenticator в обязательном расширении Foreign-Home Authentication данного сообщения, основываясь на своей защищенной связи. Аналогично, при передаче сообщения Registration Reply внешнему агенту, с которым домашний агент имеет защищенную связь, домашний агент должен включить в сообщение расширение Foreign-Home Authentication на основе этой защищенной связи.

3.8.2. Получение регистрационных запросов

Если домашний агент воспринимает входящее сообщение Registration Request, он должен обновить свою запись для привязки мобильности данного узла. В ответ следует отправить сообщение Registration Reply с подходящим кодом. В противном случае (домашний агент отвергает запрос) следует в большинстве случаев отправить сообщение Registration Reply с кодом, указывающим причину отказа в регистрации. Эта ситуация рассматривается более подробно в последующих параграфах. Если домашний агент не поддерживает широковещания (см. параграф 4.3), он должен игнорировать флаг B (не отвергая Registration Request).

3.8.2.1. Проверка применимости

Сообщения Registration Request с отличной от 0 и некорректной контрольной суммой UDP должны отбрасываться домашним агентом без уведомления отправителя.

Должна выполняться аутентификация сообщений Registration Request, включающая перечисленные ниже операции.

Домашний агент должен проверить наличие разрешающего аутентификацию расширения и провести указанную им аутентификацию. В сообщении Registration Request должно присутствовать в точности одно расширение, разрешающее аутентификацию, и домашний агент должен проверить значение Authenticator в этом расширении или убедиться, что оно проверено другим агентом, с которым у него имеется защищенная связь. Если разрешающего аутентификацию расширения нет или значение Authenticator не приемлемо, домашний агент должен отвергнуть регистрацию мобильного узла. Следует также отправить этому узлу сообщение Registration Reply с кодом 131. После этого домашний агент должен отбросить сообщение с запросом, о чем следует сделать запись в системном журнале.
Домашний агент должен проверять корректность поля Identification с использованием контекста, выбранного SPI в разрешающем аутентификацию расширении. Описание такой проверки приведено в параграфе 5.7. При некорректном значении поля домашний агент должен отвергнуть регистрационный запрос, а мобильному узлу следует отправить сообщение Registration Reply с кодом 133, включающее поле Identification, рассчитанное в соответствии с правилами параграфа 5.7. Домашний агент должен прекратить обработку регистрационного запроса, хотя следует сделать запись об ошибке в системный журнал.
Если у домашнего агента организована защищенная связь с внешним агентом, домашний агент должен проверить наличие подходящего расширения Foreign-Home Authentication. В этом случае в сообщении Registration Request должно присутствовать в точности одно расширение Foreign-Home Authentication и домашний агент должен проверить значение Authenticator в этом расширении. Если расширение Foreign-Home Authentication не найдено, указано несколько таких расширений или значение Authenticator не приемлемо, домашний агент должен отвергнуть регистрацию мобильного узла, которому следует вернуть сообщение Registration Reply с кодом 132. Домашний агент должен отбросить запрос, а в системный журнал следует внести запись о нарушении безопасности.

В дополнение к выполнению аутентификации для сообщений Registration Request домашний агент должен отвергать регистрационные запросы, которые отправлены по широковещательному адресу subnet-directed домашней сети (вместо индивидуального адреса домашнего агента). Домашний агент должен отбросить запрос, а мобильному узлу следует отправить сообщение Registration Reply с кодом 136. В этом случае Registration Reply будет содержать индивидуальный адрес домашнего агента, по которому мобильный узел может передать новое сообщение Registration Request.

Отметим, что некоторые маршрутизаторы меняют поле IP Destination Address в дейтаграммах с широковещательным адресом subnet-directed на 255.255.255.255 до их передачи в сеть адресата. В таких случаях домашний агент, который пытается «подобрать» запросы динамического обнаружения домашнего агента путем явной привязки к широковещательному адресу subnet-directed, не увидит таких пакетов. Разработчикам домашних агентов следует быть готовыми к приему пакетов, направленных по широковещательным адресам subnet-directed и 255.255.255.255, если они хотят поддерживать динамическое обнаружение домашнего агента.

3.8.2.2. Восприятие приемлемого запроса

Если сообщение Registration Request успешно прошло проверки, описанные в параграфе 3.8.2.1, и домашний агент может воспринять запрос на регистрацию, этот агент должен обновить свой список мобильных привязок для данного мобильного узла и должен вернуть этому узлу сообщение Registration Reply.

В этом случае сообщение Registration Reply будет включать код 0, если домашний агент поддерживает одновременные мобильные привязки, или 1, если такие привязки не поддерживаются. Описание построения регистрационных откликов дано в параграфе 3.8.3.

Домашний агент обновляет свою запись мобильной привязки для данного узла на основе полей сообщения Registration Request:

Если Lifetime = 0 и Care-of Address совпадает с домашним адресом мобильного узла, домашний агент удаляет для этого узла все записи из своего списка мобильных привязок, как будто мобильный узел попросил у домашнего агента прекратить обслуживание мобильности для него.
Если Lifetime = 0, а Care-of Address отличается от домашнего адреса мобильного узла, домашний агент удаляет из списка привязок мобильности только запись, содержащую указанный Care-of Address для данного мобильного узла. Все прочие активные записи для других адресов обслуживания останутся активными.
Если значение Lifetime отлично от 0, домашний агент добавляет в свой список мобильных привязок для данного мобильного узла значение Care-of Address из запроса. Если установлен бит S и домашний агент поддерживает одновременные мобильные привязки, имеющиеся в списке записи для этого узла сохраняются. В остальных случаях домашний агент удаляет из списка все имеющиеся для данного мобильного узла записи.

Во всех случаях домашний агент должен отправить сообщение Registration Reply источнику сообщения Registration Request, который на деле может быть не тем внешним агентом для чьего адреса обслуживания запрошена (де)регистрация. Если у домашнего агента есть защищенная связь с внешним агентом, для адреса которого запрошена отмена регистрации и этот агент отличается от того, который транслировал сообщение Registration Request, домашний агент может дополнительно передать сообщение Registration Reply внешнему агенту, чей адрес обслуживания дерегистрируется. Домашнему агенту недопустимо передавать такой отклик, если у него нет защищенной связи с внешним агентом. Если отклик не передается, срок действия записи в списке посетителей внешнего агента завершается естественным путем по истечении времени Lifetime.

Домашнему агенту недопустимо увеличивать значение Lifetime сверх указанного мобильным узлом в сообщении Registration Request. Однако запрос мобильным узлом значения Lifetime, превышающего то, которое позволяет домашний агент, не является ошибкой. В таком случае домашний агент просто уменьшает Lifetime до приемлемого значения и возвращает его в отклике Registration Reply. Значение Lifetime в сообщении Registration Reply информирует мобильный узел об установленном сроке регистрации, показывая тому, когда следует повторно зарегистрироваться для продолжения обслуживания. По истечении срока регистрации домашний агент должен удалить свою запись для данной регистрации из списка привязок мобильности.

Если сообщение Registration Request дублирует воспринятый текущий регистрационный запрос, недопустимо выделять срок регистрации, превышающий выданное ранее значение Lifetime. Сообщение Registration Request считается дубликатом при совпадении домашнего адреса, адреса обслуживания и поля Identification с такими же полями имеющейся регистрации.

Кроме того, если в домашней сети поддерживается ARP [36] и сообщение Registration Request просит у домашнего агента создать мобильную привязку для узла, который ранее такой привязки не имел (узел предполагался домашним), домашний агент должен следовать процедурам, описанным в параграфе 4.6, в части ARP, proxy ARP и беспричинный ARP. Если для мобильного узла есть предшествующая привязка, домашний агент должен по прежнему следовать правилам для proxy ARP из параграфа 4.6.

3.8.2.3. Отказ при недопустимом запросе

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

В этом разделе описано множество причин, по которым домашний агент может отвергнуть регистрационный запрос, и приведены коды, которые следует использовать в каждом случае. Построение откликов Registration Reply подробно описано в разделе 3.8.3.

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

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

3.8.3. Передача регистрационных откликов

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

3.8.3.1. Поля IP/UDP

В этом параграфе приведены правила, в соответствии с которыми домашний агент устанавливает значения полей заголовков IP и UDP в сообщениях Registration Reply.

IP Source Address

Копируется из поля IP Destination Address сообщения Registration Request, если там не указан групповой или широковещательный адрес. При групповом или широковещательном адресе в заголовке Registration Request в поле IP Source Address должен указываться (индивидуальный) IP-адрес домашнего агента.

IP Destination Address

Копируется из поля IP Source Address в сообщении Registration Request.

UDP Source Port

Копируется из поля UDP Destination Port в сообщении Registration Request.

UDP Destination Port

Копируется из поля UDP Source Port в сообщении Registration Request.

При передаче Registration Reply в ответ на Registration Request с запросом дерегистрации мобильного узла (Lifetime = 0 и Care-of Address совпадает с домашним адресом мобильного узла), в котором поле IP Source Address содержит домашний адрес мобильного узла (это обычный метод дерегистрации при возвращении в домашнюю сеть), в поле IP Destination Address передаваемого отклика указывается домашний адрес мобильного узла путем копирования поля IP Source Address из запроса.

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

3.8.3.2. Поля регистрационного отклика

В этом параграфе описаны конкретные правила, в соответствии с которыми домашний агент устанавливает значения полей в фиксированной части сообщений Registration Reply.

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

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

Если поле Home Address в сообщении Registration Request отлично от 0, оно должно копироваться в поле Home Address сообщения Registration Reply. В противном случае, если поле Home Address в Registration Request равно 0, как указано в параграфе 3.6, домашнему агенту следует определиться с выделением домашнего адреса для мобильного узла и поместить выбранный адрес в поле Home Address сообщения Registration Reply. Ситуации, когда мобильный узел представляется значением NAI вместо домашнего адреса IP, описаны в документе [6].

Если поле Home Agent в Registration Request содержит индивидуальный адрес домашнего агента, значение этого поля должно копироваться в поле Home Agent сообщения Registration Reply. В противном случае домашний агент должен установить в поле Home Agent сообщения Registration Reply свой индивидуальный адрес. В этом последнем случае домашний агент должен отвергнуть регистрацию с возвратом подходящего кода (например, 136) для предотвращения одновременной регистрации мобильного узла на нескольких домашних агентах.

3.8.3.3. Расширения

В этом параграфе описан порядок всех обязательных и необязательных расширений, которые мобильный узел добавляет в конце сообщения Registration Reply. Расширения должны указываться в приведенном ниже порядке.

После заголовка IP следует заголовок UDP, а за ним фиксированная часть Registration Reply, после которой
могут присутствовать какие-либо, не связанные с аутентификацией расширения, которые могут использоваться домашним агентом (и могут оказаться полезны внешнему агенту), а за ними
расширение Mobile-Home Authentication, после которого
могут присутствовать любые, не относящиеся к аутентификации расширения, используемые только внешним агентом, а затем
может следовать расширение Foreign-Home Authentication.

Отметим, что элементы a) и c) должны присутствовать в каждом сообщении Registration Reply от домашнего агента. Элементы b), d) и e) не обязательны. Однако элемент e) должен включаться в сообщения при использовании мобильным узлом и внешним агентом общей защищенной связи.

4. Вопросы маршрутизации

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

4.1. Типы инкапсуляции

Домашние и внешние агенты должны поддерживать туннелирование дейтаграмм с использованием инкапсуляции IP-in-IP [32]. Все мобильные узлы, использующие совмещенные адреса обслуживания, должны поддерживать прием дейтаграмм, туннелированных с использованием такой инкапсуляции IP-in-IP. Минимальная инкапсуляция [34] и GRE [16] также могут поддерживаться агентами мобильности и мобильными узлами в качестве опции. Использование этих дополнительных форм инкапсуляции по запросам мобильных узлов осуществляется по усмотрению домашнего агента.

4.2. Маршрутизация индивидуальных дейтаграмм

4.2.1. Мобильный узел

При подключении к домашней сети мобильный узел не использует услуг поддержки мобильности. Т. е., он работает так же, как все прочие (стационарные) хосты и маршрутизаторы. Метод выбора используемого по умолчанию маршрутизатора в домашней сети или при подключении к чужой сети и использовании совмещенного адреса обслуживания выходит за рамки данного документа. Одним из таких методов является ICMP Router Advertisement [10].

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

Если мобильный узел регистрируется с использованием адреса внешнего агента, он может применять этот адрес в качестве адреса первого маршрутизатора. MAC-адрес внешнего агента можно узнать из сообщения Agent Advertisement. В остальных случаях мобильный узел должен выбрать используемый по умолчанию маршрутизатор из числа Router Address, анонсируемых в разделе ICMP Router Advertisement сообщений Agent Advertisement.
Если мобильный узел регистрируется у домашнего агента, используя совмещенный адрес обслуживания, ему следует выбрать используемый по умолчанию маршрутизатор из числа анонсируемых в принятых им сообщениях ICMP Router Advertisement тот адрес, который будет соответствовать полученному извне адресу обслуживания и Router Address по префиксам. Если полученный мобильный узлом извне адрес обслуживания соответствует по префиксу адресу отправителя Agent Advertisement, мобильный узел может рассмотреть этот адрес при выборе маршрутизатора по умолчанию. Префикс сети может быть получен из Prefix-Lengths Extension в сообщении Router Advertisement (если оно используется). Префикс можно также получить с использованием иных механизмов, не рассматриваемых в данном документе.

При выходе из домашней сети мобильному узлу недопустимо передавать широковещательные пакеты ARP для определения MAC-адреса другого узла Internet. Таким образом, список (возможно пустой) Router Address из раздела ICMP Router Advertisement не принесет пользы при выборе маршрутизатора по умолчанию, если у мобильного узла нет возможности какого-либо метода, не включающего широковещания ARP, и не указывается в данном документе, как средство получения MAC-адреса одного из маршрутизаторов в списке. Аналогично, при отсутствии не заданных механизмов получения MAC-адресов чужой сети, мобильный узел должен игнорировать перенаправления на другие маршрутизаторы чужих сетей.

4.2.2. Внешний агент

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

Внешнему агенту недопустимо анонсировать другим маршрутизаторам в своем домене или другим мобильным узлам присутствие в его списке посетителей мобильного маршрутизатора (параграф 4.5) или мобильного узла.

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

Внешнему агенту недопустимо использовать широковещание ARP для определения MAC-адреса мобильного узла. Он может получить MAC-адрес, копируя данные из сообщений Agent Solicitation или Registration Request, передаваемых мобильным узлом. Для записей в кэше ARP с IP-адресами мобильных узлов недопустимо устанавливать время жизни меньше срока регистрации соответствующего узла в списке посетителей, если у внешнего агента нет способа обновления MAC-адреса, связанного с IP-адресом мобильного узла, без применения широковещания ARP.

Каждому внешнему агенту следует поддерживать функции, обязательные для реверсного туннелирования [27].

4.2.3. Домашний агент

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

Домашний агент должен проверять IP-адрес получателя во всех прибывающих дейтаграммах на предмет его соответствия какому-либо из мобильных узлов, находящихся за пределами домашней сети. При обнаружении пакета с таким адресом домашний агент туннелирует дейтаграммы на текущий адрес (адреса) обслуживания мобильного агента. Если домашний агент поддерживает множество одновременных привязок для мобильного узла, он туннелирует копии дейтаграммы по все адресам обслуживания мобильного узла из своего списка привязок. Если мобильный узел в данный момент не имеет привязки, домашнему агенту недопустимо пытаться перехватывать адресованные этому мобильному узлу дейтаграммы и, таким образом, он в общем случае не будет их получать. Однако, если домашний агент является также маршрутизатором, обслуживающим общий трафик IP, он может получать такие дейтаграммы для пересылки в домашнюю сеть. В этом случае домашний агент должен предполагать, что мобильный узел подключен к домашней сети и просто пересылать дейтаграммы напрямую в домашнюю сеть.

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

В параграфе 4.1 рассмотрены методы инкапсуляции, которые могут применяться для туннелирования. Узлам, реализующим туннелирование, следует также поддерживать механизм tunnel soft state [32], позволяющий возвращать из туннеля сообщения ICMP об ошибках отправителям вызвавших ошибку дейтаграмм.

Домашний агент должен декапсулировать адресованные ему пакеты, инкапсулированные мобильным узлом с целью сокрытия своего реального местоположения, как описано в параграфе 5.5. Эта функция требуется также для поддержки реверсного туннелирования [27].

Если время Lifetime для данной мобильной привязки завершается до того, как домашний агент получает другое подходящее сообщение Registration Request для данного мобильного узла, такая привязка удаляется из списка. Домашнему агенту недопустимо передавать какие-либо сообщения Registration Reply, основываясь лишь на том, что срок привязки мобильного узла истекает. Запись для мобильного узла в списке посетителей внешнего агента будет устаревать естественным путем, возможно в одно время с завершением срока действия мобильной привязки у домашнего агента. Когда срок действия мобильной привязки у домашнего агента завершается, этот агент должен удалить привязку, но он должен сохранять все остальные (с незавершенным сроком) привязки, которые имеются у него для мобильного узла.

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

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

4.3. Широковещательные дейтаграммы

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

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

4.4. Маршрутизация групповых дейтаграмм

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

Для получения группового трафика мобильный узел должен присоединиться к multicast-группе одним из двух способов. В первом варианте мобильный узел может присоединиться к группе через (локальный) групповой маршрутизатор сети, к которой он подключен. Этот вариант предполагает наличие группового маршрутизатора в чужой сети. Если мобильный узел использует совмещенный адрес обслуживания, ему следует указывать этот адрес в качестве адреса отправителя сообщений IGMP [11]. В противном случае он может использовать свой домашний адрес.

Кроме того, желающий получать групповой трафик мобильный узел может присоединиться к группе через двухсторонний туннель со своим домашним агентом (а предположении, что этот агент является групповым маршрутизатором). Мобильный узел туннелирует сообщения IGMP своему домашнему агенту, а тот пересылает групповые дейтаграммы в туннель к мобильному узлу. В туннелируемых домашнему агенту пакетах в качестве адреса отправителя следует указывать домашний IP-адрес мобильного узла.

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

Для мобильных узлов, желающих передавать дейтаграммы в multicast-группы также есть два варианта: (1) передача напрямую в чужую сеть или (2) передача через туннель к домашнему агенту. Поскольку групповая маршрутизация в общем случае зависит от IP-адреса отправителя, мобильный узел, напрямую передающий дейтаграммы в чужую сеть должен использовать в качестве IP-адреса отправителя совмещенный адрес обслуживания. Мобильный узел, использующий туннель к домашнему агенту, должен указывать свой домашний адрес в поле отправителя как групповой (внутренней), так и инкапсулированной (внешней) дейтаграммы. Для этого варианта домашний агент должен выполнять также функции группового маршрутизатора.

4.5. Мобильные маршрутизаторы

Мобильный узел может быть маршрутизатором, отвечающим за мобильность одной или множества сетей, которые перемещаются как единые объекты (возможно, на самолете, корабле, поезде, автомобиле, велосипеде или каяке). Узлы, подключенные к обслуживаемой мобильным маршрутизатором сети, сами по себе могут быть стационарными узлами или мобильными узлами или маршрутизаторами. В этом документе такие сети называются «мобильными сетями».

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

Переносный компьютер отключается от домашней сети и позднее подключается к сети на борту самолета. Этот компьютер использует Mobile IP для регистрации в чужой сети, используя для обслуживания адрес внешнего агента, найденный из сообщения Agent Advertisement от внешнего агента на борту самолета.
Сеть самолета сама по себе является мобильной. Предположим, что узел, являющийся бортовым внешним агентом, служит также используемым по умолчанию маршрутизатором, который соединяет бортовую сеть с сетью Internet. Когда самолет находится «дома», этот маршрутизатор подключается к некой стационарной сети в аэропорту, которая для этого маршрутизатора является домашней. Когда самолет находится в воздухе, маршрутизатор время от времени регистрируется через радиоканал на внешних агентах, расположенных на земле по маршруту полета. Домашний агент этого мобильного маршрутизатора располагается в стационарной сети «домашнего» аэропорта.
Некий узел-корреспондент отправляет дейтаграмму на переносный компьютер, адресуя ее на домашний адрес этого компьютера. Изначально эта дейтаграмма маршрутизируется в домашнюю сеть переносного компьютера.
Домашний агент переносного компьютера перехватывает дейтаграмму в домашней сети и туннелирует ее на адрес обслуживания переносного компьютера, которым в данном случае является адрес узла, служащего маршрутизатором и внешним агентом на борту самолета. Обычная маршрутизация IP будет направлять дейтаграмму в стационарную сеть авиакомпании.
Домашний агент бортового маршрутизатора и внешнего агента перехватывает дейтаграмму и туннелирует ее на текущий адрес обслуживания, которым в этом примере является некий внешний агент в наземной сети под самолетом. Исходная дейтаграмма будет инкапсулирована дважды — домашним агентом переносного компьютера и домашним агентом бортового маршрутизатора.
Внешний агент в наземной сети декапсулирует дейтаграмму, сохраняя инкапсуляцию домашнего агента переносного компьютера (внутреннюю) и получателем декапсулированной дейтаграммы будет адрес обслуживания переносного компьютера. Полученная в результате дейтаграмма будет передана по радиоканалу на борт самолета.
Внешний агент на борту декапсулирует дейтаграмму, извлекая из нее исходную дейтаграмму от узла-корреспондента, направленную по домашнему адресу переносного компьютера. Внешний агент бортовой сети самолета доставит эту дейтаграмму через бортовую сеть по адресу канального уровня в переносной компьютер.

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

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

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

4.6. ARP, Proxy ARP и беспричинный ARP

Использование ARP [36] требует специальных правил для корректной работы с мобильными и беспроводными узлами. Изложенные в этом параграфе требования применимы ко всем домашним сетям, где используется преобразование адресов ARP.

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

Proxy ARP [39] представляет собой отклик ARP, передаваемый узлом от имени другого узла, который не способен или не хочет сам отвечать на запросы ARP. Отправитель Proxy ARP меняет местами поля Sender и Target Protocol Address, как описано в [36], и подставляет некий заданный в конфигурации (обычно, свой) адрес канального уровня в поле Sender Hardware Address. Получатель такого отклика будет связывать указанный в нем адрес канального уровня с IP-адресом исходного искомого узла, что приведет к отправке в будущем адресованных целевому узлу пакетов на узел с указанным в отклике адресом канального уровня.
Беспричинный (Gratuitous) ARP [45] представляет собой пакет ARP, переданный узлом для того, чтобы спонтанно вызвать на других узлах обновление записи в их кэше ARP. Для беспричинного ARP могут использоваться пакеты ARP Request или ARP Reply. В любом случае в полях ARP Sender Protocol Address и ARP Target Protocol Address устанавливается IP-адрес, для которого нужно обновить запись, а в поле ARP Sender Hardware Address — адрес канального уровня, который следует указать в обновленной записи. При использовании пакетов ARP Reply в поле Target Hardware Address также устанавливается адрес канального уровня, для которого следует обновить запись в кэше (это поле не используется в пакетах ARP Request).

В любом случае для беспричинного ARP пакеты ARP должны передаваться, как локальные широковещательные пакеты на локальном канале. Как указано в [36], любой узел, получивший пакет ARP (Request или Reply), должен обновить свой локальный кэш ARP, взяв аппаратный и протокольный адрес из пакета ARP, если в кэше имеется запись для указанного в пакете адреса IP. Это требование в протоколе ARP применяется даже для пакетов ARP Request и пакетов ARP Reply, не соответствующих каким-либо отправленным этим узлом пакетам ARP Request [36].

Когда мобильный узел регистрируется в чужой сети, его домашний агент использует proxy ARP [39] для ответа на получаемые им сообщения ARP Request, в которых запрашивается адрес мобильного узла на канальном уровне. При получении ARP Request домашний агент должен проверить искомый адрес IP из запроса и, если этот адрес соответствует IP-адресу какого-либо из мобильных узлов, зарегистрировавших свои мобильные привязки, агент должен передать сообщение ARP Reply от имени этого мобильного узла. После смены адресов отправителя и получателя в пакете [39] домашний агент должен установить в качестве адреса отправителя на канальном уровне соответствующий адрес интерфейса, через который будет отправлен пакет Reply.

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

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

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

Пока мобильный узел находится за пределами домашней сети, ему недопустимо передавать какие-либо широковещательные сообщения ARP Request или ARP Reply. Более того, в этом случае ему недопустимо отвечать на сообщения ARP Request, в которых в качестве целевого указан его домашний адрес IP, если сообщение ARP Request не было направлено по индивидуальному адресу внешним агентом, на котором у мобильного узла имеется действующая регистрация. В последнем случае мобильный узел должен передавать индивидуальное сообщение ARP Reply этому внешнему агенту. Отметим, что мобильному узлу, использующему совмещенный адрес обслуживания при получении ARP Request, в котором целевым адресом IP указан его адрес обслуживания, следует отвечать на такой запрос. Отметим также, что при передаче Registration Request в чужую сеть мобильный узел может определить адрес внешнего агента на канальном уровне из полученного от этого агента сообщения Agent Advertisement без передачи широковещательного сообщения ARP Request.

Порядок применения рассмотренных выше требований по применению ARP, proxy ARP и беспричинных ARP относительно передачи и обработки мобильным узлом сообщений Registration Request и Registration Reply при выходе из домашней сети и возвращении в нее имеет важное значение для работы протокола.

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

Мобильный принимает решение о регистрации за пределами домашней сети (возможно в результате приема Agent Advertisement от внешнего агента и отсутствие свежих анонсов от домашнего агента).
Перед отправкой Registration Request отключает у себя обработку будущих сообщений ARP Request, которые могут запрашивать адрес канального уровня для его домашнего адреса, за исключением тех, которые нужны для взаимодействия с внешними агентами в чужой сети.
Мобильный узел передает Registration Request.
Когда домашний агент мобильного узла получает и воспринимает Registration Request, он отправляет беспричинный пакет ARP от имени мобильного узла и начинает использование proxy ARP для ответа на сообщения ARP Request, запрашивающие адрес канального уровня мобильного узла. В беспричинных пакетах ARP поле ARP Sender Hardware Address содержит адрес домашнего агента на канальном уровне. Если же домашний агент отвергает сообщение Registration Request, он не выполняет какой-либо обработки ARP (беспричинных или proxy).

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

Мобильный принимает решение о регистрации в домашней сети (возможно в результате приема Agent Advertisement от домашнего агента).
Перед отправкой Registration Request включает у себя обработку будущих сообщений ARP Request, которые могут запрашивать адрес канального уровня для его домашнего адреса.
Мобильный узел передает беспричинный пакет ARP, указывая в поле ARP Sender Hardware Address свой адрес канального уровня.
Мобильный узел передает Registration Request.
Когда домашний агент мобильного узла получает и воспринимает Registration Request, он прекращает использование proxy ARP для ответа на сообщения ARP Request с запросом адреса канального уровня для мобильного узла и передает беспричинный пакет ARP от имени мобильного узла, указывая в поле ARP Sender Hardware Address адрес канального уровня этого узла. Если домашний агент отвергает Registration Request, ему недопустимо вносить какие-либо изменения в обработку ARP (беспричинных или proxy) для этого узла. В этом последнем случае домашнему агенту следует вести себя, как будто мобильный узел не возвращался в домашнюю сеть и продолжать использование proxy ARP от имени мобильного узла.

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

Мобильные компьютерные среды могут очень существенно отличаться от обычных компьютерных сред. Во многих случаях для подключения мобильных узлов используются беспроводные соединения. Такие соединения потенциально уязвимы для пассивного перехвата, активных атак с использованием перехваченных ранее пакетов и других методов.

5.1. Коды аутентификации сообщений

Домашние агенты и мобильные узлы должны поддерживать аутентификацию. По умолчанию используется алгоритм HMAC-MD5 [23] с размером ключей 128 битов. Внешние агенты также должны поддерживать аутентификацию с использованием алгоритма HMAC-MD5 и ключами размером не меньше 128 битов, распространяемыми вручную. Должны поддерживаться ключи с произвольными двоичными значениями.

Защита данных и общего секрета на основе префикса и суффикса с использованием MD5 специалистами по криптографии признана уязвимой. В тех случаях, где требуется совместимость со старыми версиями Mobile IP, использующими этот режим, новым реализациям следует включать MD5 с ключом [41] в качестве дополнительного алгоритма аутентификации для использования при создании и проверке аутентификационных данных в регистрационных сообщениях Mobile IP (например, в расширениях, описанных в параграфах 3.5.2, 3.5.3, 3.5.4).

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

5.2. Вопросы безопасности, связанные с этим протоколом

Протокол регистрации, описанный в данном документе, обеспечивает туннелирование трафика мобильного узла на его адрес обслуживания. Такое туннелирование может создавать существенную уязвимость, если регистрация не была аутентифицирована. Удаленное перенаправление, выполняемое протоколом мобильной регистрации, порождает широко известную проблему безопасности в современной сети Internet, если при регистрации не применяется аутентификация сторон [2]. Более того, использование протокола преобразования адресов (ARP) без аутентификации позволяет организовать «кражу» трафика другими хостами. Использование Gratuitous ARP (параграф 4.6) снимает риски, связанные с применением ARP.

5.3. Управление ключами

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

5.4. Выбор случайных чисел

Стойкость любого механизма аутентификации зависит от ряда факторов, включая стойкость используемого алгоритма, защищенность и стойкость используемых ключей, а также качество конкретной реализации. Данная спецификация требует от реализаций использовать для аутентификации MD5 с ключом, но не исключает применения других алгоритмов и режимов. Для обеспечения эффективности MD5 с ключом 128-битовые ключи должны быть секретными (известными только уполномоченным сторонам) и псевдослучайными. При использовании nonce вкупе с защитой от повторного использования, значения nonce также должны выбираться с осторожностью. Eastlake и др. в работе [14] приводят более подробную информацию о создании псевдослучайных значений.

5.5. Конфиденциальность

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

5.6. Фильтрация на входе

Многие маршрутизаторы поддерживают политику безопасности на базе входной фильтрации (ingress filtering) [15], которая не позволяет пересылать пакеты с топологически некорректными адресами отправителей. В средах, где такая фильтрация вызывает проблемы, мобильные узлы могут использовать реверсное туннелирование [27] с использованием предоставленного внешним агентом адреса обслуживания в качестве Source Address. Пакеты мобильных узлов в таких туннелях будут нормально проходить через маршрутизаторы с входной фильтрацией, поскольку эти пакеты не будут с точки зрения топологии отличаться от пакетов узлов, не являющихся мобильными.

5.7. Защита от повторного использования для Registration Request

Поле Identification позволяет домашнему агенту убедиться в том, что регистрационное сообщение недавно создано мобильным узлом и не является повторно используемым атакующим сообщением, которое было перехвачено в предшествующей регистрации. В этом параграфе описаны два метода защиты от повторного использования — с помощью временных меток (обязательный) и с помощью nonce (необязательный). Все мобильные узлы и домашние агенты должны поддерживать защиту от повторов с помощью временных меток. Узлы могут также поддерживать защиту на основе nonce (см. Приложение A).

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

Для любого из используемых методов младшие 32 бита поля Identification должны копироваться из Registration Request в Registration Reply. Внешний агент использует эти биты (и домашний адрес мобильного узла) для сопоставления регистрационных запросов с откликами на них. Мобильный узел должен убедиться, что 32 младших бита поля идентификации в любом сообщении Registration Reply совпадают с аналогичными битами, переданными им в сообщении Registration Request.

В новом сообщении Registration Request недопустимо использовать значение Identification из непосредственно предшествовавшего ему запроса и не следует использовать одно и то же значение поля более одного раза в рамках одного защищенного контекста между мобильным узлом и домашним агентом. Разрешается повтор, описанный в параграфе 3.6.3.

5.7.1. Защита от повторного использования с помощью временных меток

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

При использовании временный меток мобильный узел должен помещать в поле Identification 64-битовое значение времени в формате NTP⁵ [26]. 32 младших бита в формате NTP представляют доли секунды и эти биты, которые недоступны для синхронизации через сеть, следует заполнять случайными значениями с использованием хорошего генератора случайных чисел. Следует отметить, что при использовании временных меток 64-битовое значение Identification в сообщении Registration Request от мобильного узла должно быть больше, нежели в предыдущем сообщении Registration Request, поскольку домашние агенты используют это поле также в качестве порядкового номера. Без использования такой нумерации возможны случаи, когда прибывший с задержкой дубликат более раннего регистрационного запроса (в пределах допустимого расхождения по времени) будет применен с нарушением порядка, ошибочно меняя текущий зарегистрированный адрес обслуживания мобильного узла.

При получении Registration Request с разрешающим аутентификацию расширением домашний агент должен проверить корректность поля Identification. Корректное значение временной метки в поле Identification должно быть достаточно близко к текущему времени по часам домашнего агента и должно быть больше воспринятых ранее для этого мобильного узла временных меток. Детали возможной рассинхронизации часов зависят от конкретной защищенной связи.

Если значение временной метки приемлемо, домашний агент копирует целиком поле Identification в сообщение Registration Reply и возвращает отклик мобильному узлу. В случае неприемлемого значения временной метки домашний агент копирует только младшие 32 бита в сообщение Registration Reply, а в старшие 32 бита помещает значение времени по своим часам. В этом случае домашний агент должен отвергнуть регистрацию, возвращая в сообщении Registration Reply код 133.

Как описано в параграфе 3.6.2.1, мобильный узел должен убедиться, что младшие 32 бита поля Identification в сообщении Registration Reply битам отвергнутого регистрационного запроса, прежде чем использовать старшие биты для корректировки своих часов.

5.7.2. Защита от повторного использования с помощью Nonce

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

Можно ожидать у домашних агентов наличия ресурсов, достаточных для расчета псевдослучайных значений [14]. Домашний агент помещает новое значение nonce в 32 старших бита поля Identification каждого сообщения Registration Reply. Младшие 32 бита поля Identification домашний агент копирует из сообщения Registration Request в идентичные биты сообщения Registration Reply. Мобильный узел, получая от домашнего агента аутентифицированное сообщение Registration Reply, сохраняет старшие 32 бита поля Identification для использования в качестве 32 старших битов поля идентификации в следующем сообщении Registration Request.

Мобильный узел отвечает за генерацию младших 32 битов поля Identification в каждом сообщении Registration Request. В идеальном варианте для этого следует использовать сгенерированные узлом случайные значения nonce. Однако допускается использование других методов, включая дублирование случайного значения, полученного от домашнего агента. Выбор метода определяется только самим мобильным узлом, поскольку именно он проверяет корректность значения в полученном отклике Registration Reply. Старшие и младшие 32-битовые компоненты поля Identification следует делать отличными от предыдущих значений. Домашний агент использует новое значение для старших битов, а мобильный узел — новое значение младших битов в каждом регистрационном сообщении. Внешний агент использует значение младших битов (и домашний адрес мобильного узла) для корректного сопоставления регистрационных откликов с ожидающими запросами (параграф 3.7.1).

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

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

Протокол Mobile IP задает несколько новых числовых пространств для использования в различных полях сообщений. Эти пространства включают:

Сообщения Mobile IP разных типов, передаваемые в порт UDP 434, как указано в параграфе 1.8.
Типы расширений для сообщений Registration Request и Registration Reply (см. параграфы 3.3 и 3.4, а также [27, 29, 6, 7, 12]).
Значения кодов (Code) для сообщений Registration Reply (см. параграф 3.4, а также [27, 29, 6, 7, 12]).
В Mobile IP определены сообщения Agent Solicitation и Agent Advertisement. Фактически они относятся к сообщениям Router Discovery [10], дополненным специфическими расширениями Mobile IP. Таким образом, для этих сообщений не требуется новое пространство имен, но нужно определить расширения для Router Discovery, как описано ниже в параграфе 6.2 (см. параграф 2.1 и работы [7, 12].

Дополнительные пространства значений для Mobile IP указаны в [7].

Информацию о выделении значений для Mobile IP взятых из внешних по отношению к данному документу спецификаций можно найти в реестрах IANA по ссылке http://www.iana.org/numbers.html. Открыв указанную ссылкой страницу, следует выбрать ссылку [M] в Directory of General Assigned Numbers и далее найти раздел Mobile IP Numbers.

6.1. Типы сообщений Mobile IP

Сообщения Mobile IP в соответствии с их определением передаются получателю в порт 434 (UDP или TCP). Пространство номеров для сообщений Mobile IP задано в параграфе 1.8. Одобрение новых номеров для сообщений выполняется по процедуре Expert Review и требует их спецификации [30]. Стандартизованные к настоящему времени типы сообщений указаны в таблице вместе с номерами параграфов, где они определены.

Тип	Название	Описание
1	Registration Request	3.3
3	Registration Reply	3.4

6.2. Расширения для RFC 1256 Router Advertisement

В RFC 1256 определены два типа сообщений ICMP — Router Advertisement и Router Solicitation. Mobile IP определяет пространство номеров для расширений Router Advertisement, которые могут использоваться протоколами, отличными от Mobile IP. Стандартизованные к настоящему времени расширения указаны в таблице вместе с параграфами, где эти расширения определены.

Тип	Название	Описание
0	One-byte Padding	2.1.3
16	Mobility Agent Advertisement	2.1.1
19	Prefix-Lengths	2.1.2

Одобрение новых номеров для расширений, используемых Mobile IP, выполняется по процедуре Expert Review и требует спецификации таких расширений [30].

6.3. Расширения для регистрационных сообщений Mobile IP

Сообщения Mobile IP, определенные в этом документе и перечисленные в параграфах 1.8 и 6.1, могут включать расширения. Расширения для сообщений Mobile IP используют общее пространство номеров, даже если расширения относятся к разным сообщениям Mobile IP. Пространство номеров для расширений Mobile IP задан в настоящем документе. Добавление расширений выполняется по процедуре Expert Review, для новых расширений нужны спецификации [30].

Тип	Название	Описание
0	One-byte Padding
32	Mobile-Home Authentication	3.5.2
33	Mobile-Foreign Authentication	3.5.3
34	Foreign-Home Authentication	3.5.4

6.4. Коды для регистрационных откликов Mobile IP

В сообщениях Mobile IP Registration Reply, описанных в параграфе 3.4, имеется поле Code. Пространство значений для кодов также определено в параграфе 3.4. Пространство значений Code структурировано по результатам обработки регистрационных запросов, как показано в таблице.

0-8	Коды успешного завершения
09-63	В настоящее время нет рекомендаций по распределению
64-127	Коды ошибок от внешнего агента
128-192	Коды ошибок от домашнего агента
193-255	В настоящее время нет рекомендаций по распределению

Выделение новых значений для кодов происходит по процедуре Expert Review [30].

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

Особая благодарность Steve Deering (Xerox PARC) вместе с Dan Duchamp и John Ioannidis (JI) (Columbia University) за формирование рабочей группы, руководство ею и значительный вклад в работу на ее начальном этапе. Ранние работы университета Columbia по Mobile IP опубликованы в [18, 19, 17].

Благодарим также Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon, Erik Nordmark, Basavaraj Patil и Phil Roberts за их вклад в работу группы в качестве председателей, а также за их полезные комментарии.

Спасибо активным участникам рабочей группы Mobile IP, особенно тем, кто готовил тексты документов, включая (в алфавитном порядке):

Ran Atkinson (Naval Research Lab),
Samita Chakrabarti (Sun Microsystems)
Ken Imboden (Candlestick Networks, Inc.)
Dave Johnson (Carnegie Mellon University),
Frank Kastenholz (FTP Software),
Anders Klemets (KTH),
Chip Maguire (KTH),
Alison Mankin (ISI)
Andrew Myles (Macquarie University),
Thomas Narten (IBM)
Al Quirt (Bell Northern Research),
Yakov Rekhter (IBM),
Fumio Teraoka (Sony),
Alper Yegin (NTT DoCoMo).

Спасибо Charlie Kunzinger и Bill Simpson — редакторам, подготовившим первый вариант этого документа, где были отражены дискуссии в рабочей группе. Значительная часть текста, добавленного в последние версии RFC 2002, обязана своим появлением Jim Solomon и Dave Johnson.

Спасибо Greg Minshall (Novell), Phil Karn (Qualcomm), Frank Kastenholz (FTP Software) и Pat Calhoun (Sun Microsystems) за их поддержку при организации встреч рабочей группы.

Параграфы 1.10 и 1.11, задающие спецификации новых форматов расширений для использования с агрегируемыми типами расширений, были включены из спецификации (Mobile IP Extensions Rationalization (MIER)), подготовленной:

Mohamed M.Khalil, Nortel Networks
Raja Narayanan, nVisible Networks
Haseeb Akhtar, Nortel Networks
Emad Qaddoura, Nortel Networks

Спасибо этим авторам, а также другим участникам работы по MIER, включая Basavaraj Patil, Pat Calhoun, Neil Justusson, N. Asokan и Jouni Malinen.

A. Патенты

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

IETF не придерживается какой-либо позиции в части применимости или сферы действия каких-либо прав интеллектуальной собственности или других прав, которые могут быть заявлены в части реализации или применения описанной в этом документе технологии, а также по вопросам лицензирования таких прав; не предпринимается также никаких усилий в части идентификации таких прав. Информацию о процедурах IETF, связанных с правами в проектах стандартов и связанных со стандартами документах можно найти в BCP-11. Копии заявлений о правах, доступных для публикации, и все заверения лицензий, которые должны быть доступными, а также результаты попыток получить общую лицензию или право на использование таких прав разработчиками или пользователями данной спецификации могут быть получены в секретариате IETF.

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

B. Канальный уровень

Мобильный узел может использовать механизмы канального уровня для принятия решения о смене своей точки подключения к сети. К таким индикаторам относятся состояние интерфейса (Down/Testing/Up) [24], смена «ячейки» или администрирования. Механизмы зависят от применяемой технологии канального уровня и выходят за рамки документа.

Протокол PPP [42] и его протокол управления IPCP [25] согласуют использование адресов IP. Мобильному узлу следует сначала попытаться использовать свой домашний адрес — в этом случае при подключении к домашней сети немаршрутизируемый канал будет работать корректно. Если домашний адрес не будет восприниматься партнером и мобильному узлу будет динамически выделен временный адрес IP, а данный мобильный узел способен работать с совмещенным адресом обслуживания, он может зарегистрировать полученный адрес в качестве совмещенного адреса обслуживания. Когда партнер задает свой адрес IP, недопустимо считать его адресом обслуживания на внешнем агенте или IP-адресом домашнего агента.

Расширения PPP для Mobile IP заданы в RFC 2290 [44]. В этом документе содержатся дополнительные сведения в части более эффективного присвоения адресов от PPP.

C. Вопросы, связанные с TCP

C.1. Таймеры TCP

При работе по каналам с большими задержками (например, SATCOM) или малой скоростью (например, радиоканалы) некоторые реализации TCP могут использовать недостаточно эффективные (нестандартные) значения тайм-аута повторной передачи. В таких случаях могут возникать тайм-ауты даже при корректной работе сети и канала просто в результате продолжительной задержки в используемой среде передачи. Это может приводить к отказам при организации и поддержке соединений TCP через такие каналы, а также приводить к ненужным повторам передачи, потребляющим доступную полосу канала. Разработчикам рекомендуется при реализации механизма тайм-аутов TCP следовать алгоритмам, описанным в 2988 [31]. Разработчикам систем, предназначенных для узкополосных каналов с большими задержками следует пользоваться рекомендациями RFC 2757 и RFC 2488 [28, 1]. Разработчикам мобильных узлов следует принимать во внимание возможность возникновения упомянутых здесь проблем.

C.2. Контроль насыщения TCP

Мобильные узлы зачастую используют среды с достаточно высокой частотой ошибок, что приводит к потере большого числа пакетов. Это приводит к возникновению конфликтов с механизмами контроля насыщения в современных реализациях [21]. Однако при отбрасывании пакетов реализация TCP на узле-корреспонденте будет, скорей всего, реагировать как на возникновение перегрузки и запускать механизмы замедленного старта (slow-start) [21], предназначенные для решения этой проблемы. Однако такие механизмы не подходят для каналов, которые сами по себе порождают множество ошибок, и на практике усиливает негативное воздействие от потери пакетов. Данная проблема была проанализирована Caceres и др. в работе [5]. Решения проблемы для методов обработки ошибок TCP, которые могут конфликтовать с механизмами контроля насыщения, рассмотрены в документах [3, 9] рабочей группы [pilc]. Хотя такие решения выходят за рамки данного документа, они показывают, что обеспечение прозрачной работы мобильных узлов включает механизмы, лежащие за пределами сетевого уровня. Проблемы, вызываемые большим числом ошибок в среде передачи, указывают на необходимость избегать решений с систематическим отбрасыванием пакетов, что следует принимать во внимание при выборе инженерных решений.

D. Примеры

В этом приложении приведены примеры сообщений Registration Request для нескольких типичных случаев.

D.1. Регистрация с адресом обслуживания от внешнего агента

Мобильный узел получает сообщение Agent Advertisement от внешнего агента и принимает решение зарегистрироваться у него с использованием анонсированного агентом адреса обслуживания. Мобильный узел желает использовать лишь инкапсуляцию IP-in-IP, ему не нужна поддержка широковещания и одновременные мобильные привязки:

Поля IP

Source Address = домашний адрес мобильного узла;

Destination Address = копируется адрес отправителя из сообщения Agent Advertisement;

Time to Live = 1.

Поля UDP

Source Port = <любой>;

Destination Port = 434;

Поля Registration Request

Type = 1;

S=0,B=0,D=0,M=0,G=0;

Lifetime = значение Registration Lifetime копируется из Mobility Agent Advertisement Extension сообщения Router Advertisement;

Home Address = домашний адрес мобильного узла;

Home Agent = IP-адрес домашнего агента мобильного узла;

Care-of Address = копируется из Mobility Agent Advertisement Extension сообщения Router Advertisement;

Identification = временная метка NTP или Nonce.

Расширения

Разрешающее проверку полномочий расширение (например, Mobile-Home Authentication Extension).

D.2. Регистрация с совмещенным адресом обслуживания

Мобильный узел подключается к чужой сети, где нет внешних агентов. Он получает адрес от сервера DHCP [13] для использования в качестве совмещенного адреса обслуживания. Мобильный узел поддерживает все формы инкапсуляции (IP-in-IP, минимальная, GRE), хочет получать копии широковещательных дейтаграмм из домашней сети и не требует одновременных привязок мобильности.

Поля IP

Source Address = адрес обслуживания, полученный от сервера DHCP;

Destination Address = IP-адрес домашнего агента;

Time to Live = 64.

Поля UDP

Source Port = <любой>;

Destination Port = 434.

Поля Registration Request

Type = 1;

S=0,B=1,D=1,M=1,G=1;

Lifetime = 1800 (секунд);

Home Address = домашний адрес мобильного узла;

Home Agent = IP-адрес домашнего агента мобильного узла;

Care-of Address = адрес обслуживания, полученный от сервера DHCP;

Identification = временная метка NTP или Nonce.

Расширения

Mobile-Home Authentication Extension.

D.3. Дерегистрация

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

Поля IP

Source Address = домашний адрес мобильного узла;

Destination Address = IP-адрес домашнего агента мобильного узла;

Time to Live = 1.

Поля UDP

Source Port = <любой>;

Destination Port = 434.

Поля Registration Request

Type = 1:

S=0,B=0,D=0,M=0,G=0;

Lifetime = 0;

Home Address = домашний адрес мобильного узла;

Home Agent = IP-адрес домашнего агента мобильного узла;

Care-of Address = домашний адрес мобильного узла;

Identification = временная метка NTP или Nonce.

Расширения

Разрешающее проверку полномочий расширение (например, Mobile-Home Authentication Extension).

E. Применимость расширения Prefix-Lengths

Расширение Prefix-Lengths следует с осторожностью применять в беспроводных сетях по причине неравномерности радиопокрытия. Эта неравномерность может приводить к тому, что два внешних агента, анонсирующие один и тот же префикс, будут предлагать мобильным узлам два разных соединения. Расширение Prefix-Lengths не следует включать в анонсы, передаваемые агентами в таких конфигурациях.

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

F. Вопросы совместимости

Этот документ является пересмотром RFC 2002 с целью повышения уровня совместимости решений путем устранения неоднозначностей. Реализации, которые выполняют аутентификацию в соответствии с новым, заданным более точно, алгоритмом, будут совместимы с более старыми реализациями, которые создают аутентификационные данные в соответствии с изначальными представлениями. Это было раньше основной причиной несовместимости.

Однако данная спецификация не включает новых функций, использование которых будет вызывать проблемы взаимодействия с более старыми реализациями. Все функции, указанные в RFC 2002 будут работать с новыми реализациями, за исключением сжатия V-J [20]. В приведенном ниже списке более подробно указаны возможные проблемы совместимости, которые могут возникать на узлах, соответствующих новой спецификации, при взаимодействии с реализациями RFC 2002.

клиент, ожидающий той или иной из ставших в новой спецификации обязательными функций (например, реверсного туннелирования) от внешнего агента, не будет сталкиваться с проблемами взаимодействия, если он принимает во внимание значение флага T;
мобильные узлы, использующие для идентификации самих себя расширение NAI, не смогут взаимодействовать со старыми агентами мобильности;
мобильные узлы, использующие нулевое значение для домашнего адреса и желающие получить свой домашний адрес в сообщении Registration Reply, не смогут взаимодействовать со старыми агентами мобильности;
мобильные узлы, пытающиеся аутентифицировать себя без использования расширения Mobile-Home, не смогут зарегистрироваться у своего домашнего агента.

Во всех указанных случаях отказоустойчивый и правильно настроенный мобильный узел с высокой вероятностью будет способен восстановить работу, выполнив подобающие действия при получении Registration Reply с кодом ошибки, указывающим причину отказа в регистрации. Например, если мобильный узел передает регистрационный запрос, который отвергается по причине указания в нем неприемлемого аутентификационного расширения, этот узел повторить попытку регистрации с использованием расширения Mobile-Home Authentication, поскольку внешний и/или домашний агент в этом случае не был настроен на использование других аутентификационых данных.

G. Отличия от RFC 2002

В этом приложении рассматриваются отличия исходной базовой спецификации Mobile IP (RFC 2002 и последующие документы), которые были внесены в процессе обновления спецификации Mobile IP.

G.1. Основные изменения

Спецификация для адреса Destination IP в сообщениях Registration Reply от внешнего агента для предотвращения возможности передачи IP-адреса 0.0.0.0.
Спецификация двух новых типов расширений Mobile IP в соответствии с идеями MIER.
Указано использование SPI аутентификационного расширения MN-HA, как части данных, к которым должен применяться алгоритм аутентификации.
Отказ от поддержки сжатия Van-Jacobson.
Указание, что внешние агенты могут передавать анонсы чаще одного раза в секунду при условии, что они не будут занимать слишком большую часть полосы локального канала. Для простоты принимается, что внешний агент может передавать анонсы с интервалом в 1/3 анонсируемого значения ICMP Lifetime.
Указание, что внешним агентам следует поддерживать реверсное туннелирование, а домашние агенты должны поддерживать декапсуляцию таких туннелей.
Изменены требования параграфа 3.6 для мобильных узлов с целью отражения определенной в RFC 2794 [6] возможности мобильного узла идентифицировать самого себя с использованием NAI и получить домашний адрес из сообщения Registration Reply.
В параграф 3.7.3.1 внесены изменения, в соответствии с которыми от внешнего агента не требуется отбрасывать сообщения Registration Reply, где поле Home Address не соответствует ни одному из ожидающих сообщений Registration Request.
Разрешена аутентификация регистрации с использованием защищенных связей между мобильным узлом и подходящим агентом аутентификации, приемлемым для домашнего агента. Определено расширение Authorization-enabling для аутентификации, которое делает регистрационное сообщение воспринимаемым для получателя. Это требуется в соответствии со спецификацией [6].
Задано обязательное использование HMAC-MD5 взамен режима MD5 prefix+suffix, указанного в RFC 2002.
Указано, что мобильному узлу следует брать первый адрес из упорядоченного списка, предложенного внешним агентом, и можно пробовать все последующие анонсированные адреса, если попытка регистрации была отвергнута внешним агентом.
Разъяснено, что агентам мобильности следует помещать только свой собственный адрес с начальный (не связанный с мобильностью) список маршрутизаторов в анонсах мобильности. RFC 2002 разрешал агентам мобильности анонсировать другие маршрутизаторы для использования по умолчанию.
Указано, что мобильный узел должен игнорировать резервные биты в сообщениях Agent Advertisement, не отбрасывая самих сообщений. В этом случае, определенные позднее биты не помешают мобильным узлам использовать анонсы, несмотря на наличие непонятных битов. Кроме того, внешние агенты могут устанавливать бит R для указания того, что они сами обрабатывают новые биты, вместо не понимающих эти биты агентов мобильности.
Указано, что внешний агент проверяет указанный адрес домашнего агента на предмет (не)принадлежности к какому-либо из интерфейсов внешнего агента до трансляции сообщения Registration Request. Если указанный адрес относится к одной из сетей внешнего агента и этот агент не является домашним для мобильного узла, запрос отвергается с возвратом кода 136 (неизвестный адрес домашнего агента).
Указано, что находящемуся вне домашней сети мобильному узлу недопустимо передавать широковещательные пакеты ARP для определения MAC-адреса другого узла Internet. Таким образом, список (возможно пустой) Router Address из компоненты ICMP Router Advertisement в сообщении бесполезен для выбора используемого по умолчанию маршрутизатора, если у мобильного узла нет какого-либо способа получить MAC-адрес одного из маршрутизаторов в этом списке без применения широковещательных пакетов. Аналогично, в отсутствие механизмов определения MAC-адресов в чужой сети мобильный узел должен игнорировать все другие маршрутизаторы в чужой сети.
Указано, что внешнему агенту недопустимо использовать широковещательные пакеты ARP для MAC-адреса мобильного узла в чужой сети. Он может получить этот адрес, копируя информацию из сообщения Agent Solicitation или Registration Request переданного мобильным узлом.
Указано, что запись в кэше ARP внешнего агента для IP-адреса мобильного узла недопустимо считать устаревшей, пока у внешнего агента нет какого-либо способа обновить связанный с IP-адресом мобильного узла MAC-адрес без использования широковещания ARP.
В конце параграфа 4.6 разъяснено, что домашнему агенту недопустимо как-то изменять способ выполнения им proxy ARP после того, как он отверг неприемлемый запрос на отмену регистрации.
В параграфе 4.2.3 указано, что многодомные домашние агенты должны использовать адрес, переданный мобильному узлу в поле Home Agent регистрационного отклика, должен использоваться в качестве адреса отправителя во внешнем заголовке IP инкапсулированных дейтаграмм.
Добавлен бит T в соответствующую позицию сообщений Registration Request (параграф 3.3).

G.2. Второстепенные изменения

Мобильным узлам разрешена обработка регистрационных откликов даже при отсутствии расширения Mobile-Home Authentication, если в отклике содержится код отказа от внешнего агента.
Указано, что внешний агент может задавать максимальное число ожидающих регистраций, которые он готов поддерживать (обычно 5). В этом случае агенту следует отвергать избыточные регистрации с возвратом кода 66. Внешний агент может удалять любые ожидающие сообщения Registration Request, ожидающие регистрации более 7 секунд; в этом случае агенту следует возвращать код 78 (тайм-аут при регистрации).
Ослаблено требование, по котором мобильный узел должен был использовать свой домашний адрес в поле отправителя в заголовке IP для групповых пакетов при участии мобильного узла в multicast-группе на маршрутизаторе чужой сети.
Отмечено, что агент мобильности может использовать разные наборы битов R, H и F для разных сетевых интерфейсов.
Термин «рекурсивное туннелирование» заменен термином «вложенное туннелирование».
Указано, что мобильный узел может использовать адрес отправителя из анонса агента в качестве маршрута по умолчанию.
Отмечено, что ключи с произвольными двоичными значениями должны поддерживаться для защищенных связей.
Указано, что в качестве значения по умолчанию можно выбирать 7 секунд для того, чтобы скомпенсировать рассогласование часов домашнего агента и мобильного узла при использовании временных меток для защиты от повторного использования. Дополнительно указано, что для этого параметра следует выбирать значение более 3 секунд.
Указано, что сообщения Registration Request с битом D=0, задающие адрес обслуживания, который не предлагается внешним агентом, должны отвергаться с возвратом кода 77 (неприемлемый адрес обслуживания).
Отмечено, что внешним агентам следует принимать во внимание свое максимальное значение при обработке полей Lifetime в сообщениях Registration Reply.
Отмечено, что домашний агент должен игнорировать бит B (а не отвергать сообщение Registration Request), если он не поддерживает широковещания.
Выяснение (не)возможности использования динамического обнаружения домашнего агента в случаях, когда маршрутизаторы меняют IP-адрес получателя дейтаграмм с широковещания в масштабе подсети (subnet-directed broadcast) на 255.255.255.255 до передачи дейтаграммы в подсеть получателя.
Разъяснено, что сообщение Agent Advertisement адресовано индивидуально мобильному узлу, конкретный домашний IP-адрес мобильного узла может использоваться в качестве IP-адреса получателя.
Включена ссылка на RFC 2290 с Приложением B, где рассмотрена работа с PPP.
Добавлен раздел согласование с IANA (IANA Considerations).
В параграфе 3.8.3 пояснено, что домашнему агенту следует организовать выбор домашнего адреса для мобильного узла в тех случаях, когда сообщение Registration Reply содержит нулевое значение Home Address.

G.3. Отличия от варианта 04 RFC2002bis

В этом параграфе перечислены отличия данной версии (…-06.txt) этого документа от предыдущей (…-04.txt). Параграф может быть удален редактором RFC.

отмечено, что следует рассмотреть использование HMAC-MD5 взамен режима «prefix+suffix» MD5, изначально заявленного в RFC 2002;
включена ссылка на RFC 2290 с Приложением B, где рассмотрена работа с PPP;
переписан раздел Согласование с IANA;
переписан раздел Обновления;
раздел Патенты (Patents) заменен в соответствии с RFC 2026;
обновлены цитаты.

H. Примеры сообщений

H.1. Пример формата ICMP Agent Advertisement

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Num Addrs   |Addr Entry Size|           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Router Address[1]                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Preference Level[1]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Router Address[2]                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Preference Level[2]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ....                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 16   |     Length    |      Sequence Number          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Registration Lifetime         |R|B|H|F|M|G|r|T|  reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Care-of Address[1]                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Care-of Address[2]                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         ....                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                   Необязательные расширения                   :
   :   ....                ......                      ......      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H.2. Пример формата Registration Request

После заголовка UDP следуют поля Mobile IP, как показано ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type = 1  |S|B|D|M|G|r|T|x|          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Необязательные расширения без аутентификации для HA ...    |
   |                     (переменный размер)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type =32   |      Length   |           SPI                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SPI (продолж.)       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   :         MN-HA Authenticator (переменный размер)               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :    Необязательные расширения без аутентификации для FA .......
   :    Необязательное расширение MN-FA Authentication  ...........
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H.3. Пример формата сообщения Registration Reply

После заголовка UDP следуют поля Mobile IP, как показано ниже.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 3    |     Code      |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Необязательные расширения без аутентификации для HA ...    |
   |                     (переменный размер)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type =32   |      Length   |           SPI                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SPI (продолж.)       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   :         MN-HA Authenticator (переменный размер)               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :    Необязательные расширения без аутентификации для FA .......
   :    Необязательное расширение MN-FA Authentication  ...........
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Литература

[1] Allman, M., Glover, D. and L. Sanchez, «Enhancing TCP Over Satellite Channels using Standard Mechanisms», BCP 28, RFC 2488, January 1999.

[2] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. ACM Computer Communications Review, 19(2), March 1989.

[3] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, «Performance Enhancing Proxies», RFC 3135, June 2001.

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

[5] Ramon Caceres and Liviu Iftode. Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments. IEEE Journal on Selected Areas in Communications, 13(5):850—857, June 1995.

[6] Calhoun P. and C. Perkins, «Mobile IP Network Access Identifier Extension for IPv4», RFC 2794, January 2000.

[7] Calhoun, P. and C. Perkins, «Mobile IP Foreign Agent Challenge/Response Extension», RFC 3012, December 2000.

[8] Cong, D., Hamlen, M. and C. Perkins, «The Definitions of Managed Objects for IP Mobility Support using SMIv2», RFC 2006, October 1996.

[9] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. Vaidya, «End-to-end Performance Implications of Links with Errors», BCP 50, RFC 3155, August 2001.

[10] Deering, S., «ICMP Router Discovery Messages», RFC 1256, September 1991.

[11] Deering, S., «Host Extensions for IP Multicasting», STD 5, RFC 1112, August 1989.

[12] Dommety, G. and K. Leung, «Mobile IP Vendor/Organization-Specific Extensions», RFC 3115, April 2001.

[13] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, March 1997.

[14] Eastlake, D., Crocker, S. and J. Schiller, «Randomness Recommendations for Security», RFC 1750, December 1994.

[15] Ferguson P. and D. Senie, «Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing», BCP 38, RFC 2827, May 2000.

[16] Hanks, S., Li, T., Farinacci, D. and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 1701, October 1994.

[17] J. Ioannidis. Protocols for Mobile Internetworking. PhD Dissertation — Columbia University in the City of New York, July 1993.

[18] John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr. IP-Based Protocols for Mobile Internetworking. In Proceedings of the SIGCOMM ’91 Conference: Communications Architectures & Protocols, pages 235—245, September 1991.

[19] John Ioannidis and Gerald Q. Maguire Jr. The Design and Implementation of a Mobile Internetworking Architecture. In Proceedings of the Winter USENIX Technical Conference, pages 489—500, January 1993.

[20] Jacobson, V., «Compressing TCP/IP headers for low-speed serial links», RFC 1144, February 1990.

[21] Jacobson, V., «Congestion Avoidance and Control. In Proceedings, SIGCOMM ’88 Workshop, pages 314—329. ACM Press, August 1988. Stanford, CA.

[22] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 2402, November 1998.

[23] Krawczyk, H., Bellare, M. and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[24] McCloghrie, K. and F. Kastenholz, «The Interfaces Group MIB», RFC 2863, June 2000.

[25] McGregor, G., «The PPP Internet Protocol Control Protocol (IPCP)», RFC 1332, May 1992.

[26] Mills, D., «Network Time Protocol (Version 3) Specification, Implementation», RFC 1305, March 1992.

[27] Montenegro, G., «Reverse Tunneling for Mobile IP (revised)», RFC 3024, January 2001.

[28] Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N. Vaidya, «Long Thin Networks», RFC 2757, January 2000.

[29] Montenegro, G. and V. Gupta, «Sun’s SKIP Firewall Traversal for Mobile IP», RFC 2356, June 1998.

[30] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», RFC 2434, October 1998.

[31] Paxson, V. and M. Allman, «Computing TCP’s Retransmission Timer», RFC 2988, November 2000.

[32] Perkins, C., «IP Encapsulation within IP», RFC 2003, October 1996.

[33] Perkins, C., «IP Mobility Support», RFC 2002, October 1996.

[34] Perkins, C., «Minimal Encapsulation within IP», RFC 2004, October 1996.

[35] Perkins, C. and P. Calhoun, «AAA Registration Keys for Mobile IP», Work in Progress⁷, July 2001.

[36] Plummer, D., «Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware», STD 37, RFC 826, November 1982.

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

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

[39] Postel, J., «Multi-LAN Address Resolution», RFC 925, October 1984.

[40] Reynolds, J. and J. Postel, «Assigned Numbers», STD 2, RFC 1700, October 1994.

[41] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, April 1992.

[42] Simpson, W., «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, July 1994.

[43] Solomon, J., «Applicability Statement for IP Mobility Support» RFC 2005, October 1996.

[44] Solomon J. and S. Glass, «Mobile-IPv4 Configuration Option for PPP IPCP», RFC 2290, February 1998.

[45] Stevens, W., «TCP/IP Illustrated, Volume 1: The Protocols» Addison-Wesley, Reading, Massachusetts, 1994.

Адреса авторов

Контактные данные рабочей группы приведены ниже.

Basavaraj Patil

Nokia

6000 Connection Dr.

Irving, TX. 75039

USA

Phone: +1 972-894-6709

EMail: Basavaraj.Patil@nokia.com

Phil Roberts

Megisto Corp. Suite 120

20251 Century Blvd

Germantown MD 20874

USA

Phone: +1 847-202-9314

EMail: PRoberts@MEGISTO.com

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

Charles E. Perkins

Communications Systems Lab

Nokia Research Center

313 Fairchild Drive

Mountain View, California 94043

USA

Phone: +1-650 625-2986

EMail: charliep@iprg.nokia.com

Fax: +1 650 625-2502

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

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

nmalykh@gmail.com

Полное заявление авторских прав

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1В настоящее время этот документ утратил силу. Информация о типах сообщений доступна по ссылке. Прим. перев.

2Type-Length-Value — тип-размер-значение.

3User Datagram Protocol — протокол пользовательских дейтаграмм.

4Security Parameter Index.

5Network Time Protocol — протокол сетевого времени.

6Этот документ признан устаревшим и заменен RFC 4302. Прим. перев.

7Работа завершена и опубликована в RFC 3957. Прим. перев.

8В соответствии с RFC 3232 этот документ утратил силу. Данные по номерам доступны по ссылке. Прим. перев.

Рубрика: RFC | Комментарии отключены

RFC 3339 Date and Time on the Internet: Timestamps

Опубликовано 20.07.2002 автором Nikolai Malykh

Network Working Group                                           G. Klyne
Request for Comments: 3339                        Clearswift Corporation
Category: Standards Track                                      C. Newman
                                                        Sun Microsystems
                                                               July 2002

Date and Time on the Internet: Timestamps

Метки даты и времени в Internet

PDF

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

В этом документе описан проект стандартного протокола Internet, предложенного сообществу Internet, документ служит приглашением к дискуссии в целях развития предложенного протокола. Текущее состояние стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.

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

Аннотация

Этот документ задаёт формат даты и времени для использования в протоколах Internet, который является профилем стандарта ISO 8601 для представления даты и времени по григорианскому календарю.

1. Введение

Форматы дат и времени вызывают много путаницы и проблем совместимости в Internet. В этом документе рассматриваются многие из таких проблем и приводятся рекомендации по улучшению согласованности и совместимости при использовании дат и времени в протоколах Internet.

Документ включает профиль Internet для использования стандарта ISO 8601 [ISO8601] при представлении дат и времени по григорианскому календарю.

Имеется много способов представления дат и времени в протоколах Internet, но в этом документе основное внимание удалено временным метках протокольных событий Internet. Это ведёт к указанным ниже последствиям.

Предполагается, что все даты и время относятся к «текущей эре» между годами 0000 и 9999.
Время указывается с учётом смещения (offset) относительно универсального скоординированного времени (Coordinated Universal Time или UTC). Это отличается от некоторых применений в приложениях планирования, где местное время и местоположение могут быть известны, но фактическая связь с UTC может зависеть от неизвестных или нераскрываемых действий политиков и администраторов. Время UTC, соответствующее 17:00 23 марта 2005 г. в Нью-Йорке, может зависеть от административного решения по использованию летнего времени (daylight savings time). Эта спецификация не рассматривает такие вопросы.
Временные метки могут указывать время введения UTC. Такие метки указываются универсальным временем, применявшимся в соответствующий период.
Дата и время указывают момент времени. Описание интервалов или периодов не рассматривается здесь.

2. Определения

UTC

Универсальное (всемирное) скоординированное время, поддерживаемое Международным бюро мер и весов (Bureau International des Poids et Mesures или BIPM).

second — секунда

Базовая единица измерения времени в системе СИ (International System of Units). Определена как продолжительность 9192631770 колебаний, поглощаемых или излучаемых атомами цезия-133 в основном состоянии, не нарушаемом внешними полями.

minute — минута

Период времени в 60 секунд. В параграфе 5.7 и Приложении D описан учёт високосных секунд в минутах.

hour — час

Период времени в 60 минут.

day — день (сутки)

Период времени в 24 часа.

leap year — високосный год

В григорианском календаре — год, включающий 366 дней. Високосными являются годы, кратные четырём, но не кратные 100, при этом годы, кратный 400, являются високосными.

ABNF

Расширенная форма Бэкуса-Наура — формат представления разрешённых строк в протоколе или языке, заданный в [ABNF].

Email Date/Time Format

Формат дат и времени, используемый в почте Internet в соответствии с RFC 2822 [IMAIL-UPDATE].

Internet Date/Time Format

Формат дат, заданный в разделе 5 этого документа.

Timestamp — метка времени

В этом документе указывает однозначное представление некого момента времени.

Суффикс, который применительно к времени означает нулевое смещение от UTC (00:00). Часто говорят Zulu из фонетического алфавита ICAO, где это представляет букву Z.

Дополнительные сведения о шкалах времени приведены в Приложении E к [NTP], разделе 3 в [ISO8601] и соответствующих документах ITU [ITU-R-TF].

3. Две цифры года

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

Протоколы Internet должны указывать год 4 цифрами.
Использовать 2 цифры для указания года не рекомендуется. При получении такого значения эго следует воспринимать лишь в тех случаях, когда некорректная интерпретация не приведёт к отказу протокола или обработки (например, при использовании для записи системного журнала или при отслеживании).
Возможно, что программа использующая для года две цифры, будет представлять даты после 1999 г. тремя цифрами. Это произойдёт, если программа просто вычитает из года значение 1900 и не проверяет количество цифр. Программы, желающие надёжно обрабатывать такие даты, могут добавлять 1900 к трём цифрам года.
Возможно, что программа использующая для года две цифры, будет представлять даты после 1999 г. как :0, :1, … :9, ;0, … Это будет происходить, если программа просто вычитает из года значение 1900 и и прибавляет десятилетие к символу US-ASCII 0. Программам, желающим надёжно обрабатывать такие даты, следует проверять нечисловые десятилетия и интерпретировать их должным образом.

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

4. Местное время

4.1. Универсальное скоординированное время (UTC)

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

4.2. Часовые пояса

Смещение местного времени относительно UTC часто даёт полезные сведения. Например, в электронной почте (RFC2822, [IMAIL-UPDATE]) смещение обеспечивает полезную эвристику для определения вероятности быстрого ответа. Попытки указывать смещение строками букв приводили к плохой совместимости [IMAIL], [HOST-REQ]. В результате документ RFC2822 [IMAIL-UPDATE] сделал цифровое смещение обязательным.

Смещение определяется вычитанием UTC из местного времени, поэтому эквивалент UTC можно получить вычитание смещения из местного времени. Например, 18:50:00-04:00 указывает то же время, что и 22:50:00Z. Здесь используется отрицательное смещение, обрабатываемое с учётом знака.

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

4.3. Преобразование неизвестных часовых поясов

Если известно время UTC, но неизвестно смещение локального времени, его можно представить в форме -00:00. Это семантически отличается от Z и +00:00, подразумевающих, что UTC является предпочтительной точкой отсчёта для указанного времени. В RFC2822 [IMAIL-UPDATE] описано аналогичное соглашение для электронной почты.

4.4. Неполное местное время

Множество устройств, подключённых к Internet используют часы с местным временем и не знают о UTC. Хотя в Internet существует традиция учитывать реальность при разработке спецификаций, это не должно препятствовать совместимости. Поскольку интерпретация неполного указания местного времени (без часового пояса) не будет работать в 23/24 планеты, проблемы совместимости из-за неполного указания местного времени считаются неприемлемыми для Internet. Системы с локальным временем, не знающие смещения от UTC и зависящие от синхронизации часов с другими системами Internet, должны применять механизм, обеспечивающий корректную синхронизацию с UTC. Некоторые из подходящих механизмов указаны ниже.

Использование протокола сетевого времени (Network Time Protocol) [NTP] для получения времени UTC.
Использование другого хоста в том же часовом поясе в качестве шлюза в Internet. Этот хост должен корректировать неполное местное время, передаваемое другим хостам.
Запрос у пользователя местного часового пояса и настроек сезонного времени.

5. Формат даты и времени

В этом разделе рассматриваются желаемые свойств дат и времени и задан профиль ISO 8601 для протоколов Internet.

5.1. Упорядочение

Если компоненты даты и времени упорядочены от менее точных к более точным, это обеспечивает полезность формата. Предположим, что часовые пояса дат и времени совпадают (например, UTC), выражены однотипными строками (например, везде Z или +00:00), а для времени используется одинаковой число цифр в дробной части секунд, значения даты и времени можно сортировать как обычные строки (например, с помощью функции strcmp() языка C) и в результате получать упорядоченные по времени последовательности. Если формат допускает необязательные знаки препинания или пробелы, это упорядочение может не работать¹.

5.2. Читаемость для человека

Удобочитаемость для человека оказалась важным свойством протоколов Internet. Понятные человеку протоколы существенно сокращают время отладки, поскольку в качестве клиента часто применяется telnet, а сетевые анализаторы не требуется менять для понимания протоколов. С другой стороны, читаемость для человека иногда ведёт к проблемам взаимодействия. Например, даты в формате 10/11/1996 совершенно не подходят для глобального обмена, поскольку интерпретация в разных странах отличается. Кроме того, формат дат из [IMAIL] ведёт к проблемам совместимости, когда людт предполагают, что разрешены любые строки текста, переводят трехбуквенные сокращения на другие языки или заменяют форматом, который проще создать (например, форматом, применяемым в функции C ctime). По этим причинам нужно соблюдать баланс между удобочитаемостью и совместимостью.

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

5.3. Редко применяемые опции

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

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

5.4. Избыточные сведения

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

5.5. Простота

Полный набор форматов даты и времени в ISO 8601 [ISO8601] достаточно сложен из-за попыток обеспечить разные и неполные представления. В Приложении A показана попытка преобразовать полный синтаксис ISO 8601 в ABNF. Протоколы Internet имеют иные требования и простота является важным параметром. Кроме того, для протоколов Internet обычно требуется полная спецификация данных для обеспечения совместимости. Поэтому полная грамматика ISO 8601 представляется слишком сложной для большинства протоколов Internet. В следующем параграфе задан профиль ISO 8601 для применения в Internet, являющийся подмножеством расширенного формата ISO 8601. Простота обеспечивается за счёт обязательности большинства полей и пунктуации.

5.6. Формат даты и времени в Internet

Приведённый ниже профиль дат ISO 8601 [ISO8601] следует использовать в новых протоколах Internet. Профиль указан с использованием нотации [ABNF].

Синтаксис создания full-time предназначен для протоколов, которые хотят передавать точные метки времени (например, для записи в журнал или упорядочения событий). Другие варианты (full-date, full-time, partial-time) могут применяться приложениями с соответствующими требованиями².

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 - месяц-год
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 с правилами для
                             ; високосных секунд
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-time       = full-date "T" full-time

Примечание. В соответствии с [ABNF] и ISO8601 симаолы T и Z в могут использоваться и в нижнем регистре (t, z).

Этот формат даты и времени может применяться в средах или контексте, где строчные и прописные буквы различаются (например, XML). Спецификации, применяющие этот формат в таких средах, могут дополнительно ограничивать синтаксис, чтобы с дате и времени всегда применялись заглавные буквы T и Z. Приложениям, создающим метки в таком формате, следует использовать заглавные буквы.

Примечание. ISO 8601 разделяет дату и время символом T. Приложения, использующие этот синтаксис могут для удобочитаемости указывать полную дату и полное время, разделённые другим символом (например, пробелом).

5.7. Ограничения

Элемент грамматики date-mday представляет номер дня в текущем месяце. Максимальные значения приведены ниже.

Номер месяца	Месяц	Максимальное значение date-mday
01	январь	31
02	февраль обычного года	28
02	февраль високосного года	29
03	март	31
04	апрель	30
05	май	31
06	июнь	30
07	июль	31
08	август	31
09	сентябрь	30
10	октябрь	31
11	ноябрь	30
12	декабрь	31

В приложении C приведён код C для определения високосных годов.

Элемент грамматики time-second может иметь значение 60 в конце месяца с високосной секундой, на сегодняшний день это июнь (XXXX-06-30T23:59:60Z) или December (XXXX-12-31T23:59:60Z) (см. Приложение D с таблицей добавления секунды). Возможно также вычитание високосной секунды и максимальное значение time-second составит 58. Во всех других случаях максимальное значение time-second составляет 59. Кроме того, в часовых поясах, отличных от Z, момент учёта високосной секунды сдвигается на величину смещения часового пояса (чтобы секунда учитывалась на всей планете одновременно).

Високосные секунды можно предсказать далеко в будущее. Международная служба вращения Земли (International Earth Rotation Service) публикует бюллетени [IERS], анонсирующие високосные секунды с предупреждением за несколько недель. Приложениям не следует создавать метки времени с учётом високовной секунды до её анонса.

Хотя ISO 8601 разрешает указывать для часа значение 24, этот профиль ISO 8601 разрешает лишь значения от 00 до 23 для снижения путаницы.

5.8. Примеры

Ниже приведены несколько примеров даты и времени в Internet.

      1985-04-12T23:20:50.52Z

Это представляет время 20 минут и 50,52 секунд после 23 часов 12 апреля 1985 г. в UTC.

      1996-12-19T16:39:57-08:00

Это представляет время 39 минут и 57 секунд после 16 часов 19 декабря 1996 г со смещением -08:00 от UTC (Pacific Standard Time). Эквивалентом служит 1996-12-20T00:39:57Z in UTC.

      1990-12-31T23:59:60Z

Это представляет високосную секунду, добавленную в конце 1990 г.

      1990-12-31T15:59:60-08:00

Это представляет ту же високосную секунду в часовом поясе Pacific Standard Time в 8 часах после UTC.

      1937-01-01T12:00:27.87+00:20

Это представляет тот же момент времени, что и полдень 1 января 1937 г. по времени Нидерландов. Стандартное время в Нидерландах по закону от 1 мая 1909 г. опережало UTC на 19 минут и 32,13 секунд вплоть до 30 июня 1937 г. Это время нельзя точно представить в формате HH:MM и метка использует ближайшее представимое смещение от UTC.

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

[ZELLER] Zeller, C., «Kalender-Formeln», Acta Mathematica, Vol. 9, Nov 1886.

[IMAIL] Crocker, D., «Standard for the Format of Arpa Internet Text Messages», STD 11, RFC 822, August 1982.

[IMAIL-UPDATE] Resnick, P., «Internet Message Format», RFC 2822, April 2001.

[ABNF] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.

[ISO8601] «Data elements and interchange formats — Information interchange — Representation of dates and times», ISO 8601:1988(E), International Organization for Standardization, June, 1988.

[ISO8601:2000] «Data elements and interchange formats — Information interchange — Representation of dates and times», ISO 8601:2000, International Organization for Standardization, December, 2000.

[HOST-REQ] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

[IERS] International Earth Rotation Service Bulletins, <http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletins.html>³.

[NTP] Mills, D, «Network Time Protocol (Version 3) Specification, Implementation and Analysis», RFC 1305, March 1992.

[ITU-R-TF] International Telecommunication Union Recommendations for Time Signals and Frequency Standards Emissions. <http://www.itu.ch/publications/itu-r/iturtf.htm>

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

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

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

Приложение A. ISO 8601 в представлении ABNF

Приведённая здесь информация основана на версии 1988 г. стандарта ISO 8601. В выпуске 2000 г. могут быть некоторые отличия.

ISO 8601 не задаёт формальную грамматику для определяемых форматов даты и времени. Попытка определить такую грамматику ISO 8601 представлена ниже. Это сделано лишь для информации и может содержать ошибки. Полномочным источником остаётся стандарт ISO 8601.

Отметим, что по причине неоднозначности ISO 8601 пришлось применить некоторые интерпретации. Во-первых, из ISO 8601 не ясно, допускается ли сочетание базового и расширенного формата. Приведённая здесь грамматика разрешает такое смешение⁴. Из ISO 8601 не ясно, допустимо ли значение часа 24 лишь в том случае, когда для минут и секунд установлены значения 0. Это предполагает возможность использовать для часа значение 24 в любом контексте. Применяются ограничения для date-mday из параграфа 5.7. В ISO 8601 сказано, что в некоторых случаях символ T можно пропускать. Описанная здесь грамматика требует использовать T для предотвращения неоднозначности. ISO 8601 требует (параграф 5.3.1.3), чтобы десятичное значение начиналось с 0, если оно меньше единицы⁵.

   date-century    = 2DIGIT  ; 00-99
   date-decade     =  DIGIT  ; 0-9
   date-subdecade  =  DIGIT  ; 0-9
   date-year       = date-decade date-subdecade
   date-fullyear   = date-century date-year
   date-month      = 2DIGIT  ; 01-12
   date-wday       =  DIGIT  ; 1-7  ; 1 - понедельник, 7 - воскресенье
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 месяц-год
   date-yday       = 3DIGIT  ; 001-365, 001-366 по годам
   date-week       = 2DIGIT  ; 01-52, 01-53 по году

   datepart-fullyear = [date-century] date-year ["-"]
   datepart-ptyear   = "-" [date-subdecade ["-"]]
   datepart-wkyear   = datepart-ptyear / datepart-fullyear

   dateopt-century   = "-" / date-century
   dateopt-fullyear  = "-" / datepart-fullyear
   dateopt-year      = "-" / (date-year ["-"])
   dateopt-month     = "-" / (date-month ["-"])
   dateopt-week      = "-" / (date-week ["-"])

   datespec-full     = datepart-fullyear date-month ["-"] date-mday
   datespec-year     = date-century / dateopt-century date-year
   datespec-month    = "-" dateopt-year date-month [["-"] date-mday]
   datespec-mday     = "--" dateopt-month date-mday
   datespec-week     = datepart-wkyear "W"
                       (date-week / dateopt-week date-wday)
   datespec-wday     = "---" date-wday
   datespec-yday     = dateopt-fullyear date-yday

   date              = datespec-full / datespec-year / datespec-month /
   datespec-mday / datespec-week / datespec-wday / datespec-yday

Время

   time-hour         = 2DIGIT ; 00-24
   time-minute       = 2DIGIT ; 00-59
   time-second       = 2DIGIT ; 00-58, 00-59, 00-60 с правилами для
                              ; високосных секунд
   time-fraction     = ("," / ".") 1*DIGIT
   time-numoffset    = ("+" / "-") time-hour [[":"] time-minute]
   time-zone         = "Z" / time-numoffset

   timeopt-hour      = "-" / (time-hour [":"])
   timeopt-minute    = "-" / (time-minute [":"])

   timespec-hour     = time-hour [[":"] time-minute [[":"] time-second]]
   timespec-minute   = timeopt-hour time-minute [[":"] time-second]
   timespec-second   = "-" timeopt-minute time-second
   timespec-base     = timespec-hour / timespec-minute / timespec-second

   time              = timespec-base [time-fraction] [time-zone]

   iso-date-time     = date "T" time

Продолжительность

   dur-second        = 1*DIGIT "S"
   dur-minute        = 1*DIGIT "M" [dur-second]
   dur-hour          = 1*DIGIT "H" [dur-minute]
   dur-time          = "T" (dur-hour / dur-minute / dur-second)
   dur-day           = 1*DIGIT "D"
   dur-week          = 1*DIGIT "W"
   dur-month         = 1*DIGIT "M" [dur-day]
   dur-year          = 1*DIGIT "Y" [dur-month]
   dur-date          = (dur-day / dur-month / dur-year) [dur-time]

   duration          = "P" (dur-date / dur-time / dur-week)

Периоды

   period-explicit   = iso-date-time "/" iso-date-time
   period-start      = iso-date-time "/" duration
   period-end        = duration "/" iso-date-time

   period            = period-explicit / period-start / period-end

Приложение B. Дни недели

Ниже приведён пример подпрограммы C, основанной на конгруэнтности Целлера (Zeller’s Congruence) [Zeller], которую можно использовать для определения для недели по дате после 0000-03-01.

   char *day_of_week(int day, int month, int year)
   {
      int cent;
      char *dayofweek[] = {
         "Sunday", "Monday", "Tuesday", "Wednesday",
         "Thursday", "Friday", "Saturday"
      };
      /* настройка месяцев, чтобы февраль был последним */
      month -= 2;
      if (month < 1) {
         month += 12;
         --year;
      }
      /* деление по векам */
      cent = year / 100;
      year %= 100;
      return (dayofweek[((26 * month - 2) / 10 + day + year
                        + year / 4 + cent / 4 + 5 * cent) % 7]);
   }

Приложение C. Високосные годы

Ниже приведён пример на C для определения високосных лет.

   /* Возвращает ненулевое значение для високосных лет. Год должен 
      указываться 4 цифрами.
    */
   int leap_year(int year)
   {
       return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
   }

Приложение D. Високосные секунды

Сведения о високосных секундах можно получить по ссылке <http://tycho.usno.navy.mil/leapsec.html>. В частности, так указано.

За решения по високосным секундам отвечает Международная служба вращения Земли (IERS). В соответствии с рекомендацией CCIR, предпочтение отдаётся последним числам декабря и июня затем — последним числам марта и сентября.

При необходимости високосная секунда добавляется в конце суток UTC и представляется меткой времени вида YYYY-MM-DDT23:59:60Z. Високосная секунда добавляется одновременно во всех часовых поясах, чтобы не нарушались их взаимосвязи. Примеры для високосных секунд приведены в параграфе 5.8.

Ниже приведена выдержка из таблицы Военно-морской обсерватории США (United States Naval Observatory), доступной по ссылке <ftp://maia.usno.navy.mil/ser7/tai-utc.dat>. В таблице указаны даты добавления високосных секунд и разница между стандартом времени TAI (не учитывает високосных секунд) и UTC после добавления високосной секунды.

Дата UTC	TAI — UTC после високосной секунды
1972-06-30	11
1972-12-31	12
1973-12-31	13
1974-12-31	14
1975-12-31	15
1976-12-31	16
1977-12-31	17
1978-12-31	18
1979-12-31	19
1981-06-30	20
1982-06-30	21
1983-06-30	22
1985-06-30	23
1987-12-31	24
1989-12-31	25
1990-12-31	26
1992-06-30	27
1993-06-30	28
1994-06-30	29
1995-12-31	30
1997-06-30	31
1998-12-31	32

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

Ned Freed, Neal McBurnett, David Keegel, Markus Kuhn, Paul Eggert и Robert Elz предоставили полезные советы для ранних вариантов документа. Спасибо участникам списка рассылки рабочей группы IETF Calendaring/Scheduling и списка рассылки по часовым поясам.

Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn внесли полезные предложения для окончательного документа. Paul Eggert сделал много аккуратных наблюдений относительно тонкостей високосных секунд и смещения часовых поясов. Dr John Stockton, Jutta Degener, Joe Abley, Dan Wing внесли правки и улучшения в ранние варианты документа.

Адреса авторов

Chris Newman

Sun Microsystems

1050 Lakes Drive, Suite 250

West Covina, CA 91790 USA

EMail: chris.newman@sun.com

Graham Klyne (редактор этого выпуска)

Clearswift Corporation

1310 Waterside

Arlington Business Park

Theale, Reading RG7 4SA

Phone: +44 11 8903 8903

Fax: +44 11 8903 9000

EMail: GK@ACM.ORG

Полное заявление авторских прав

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

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

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

nmalykh@protokols.ru

1В оригинале был иной текст. См. https://www.rfc-editor.org/errata/eid293. Прим. перев.

2В оригинале это предложение отсутствовало. См. https://www.rfc-editor.org/errata/eid5624. Прим. перев.

3В оригинале была указана ошибочная ссылка. См. https://www.rfc-editor.org/errata/eid3710. Прим. перев.

4В оригинале начало этого абзаца было иным. См. https://www.rfc-editor.org/errata/eid1584. Прим. перев.

5В оригинале здесь было ещё два предложения. См. https://www.rfc-editor.org/errata/eid4110. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 3272 Overview and Principles of Internet Traffic Engineering

Опубликовано 18.05.2002 автором Nikolai Malykh

Network Working Group                                         D. Awduche
Request for Comments: 3272                                Movaz Networks
Category: Informational                                          A. Chiu
                                                         Celion Networks
                                                              A. Elwalid
                                                              I. Widjaja
                                                     Lucent Technologies
                                                                 X. Xiao
                                                        Redback Networks
                                                                May 2002

PDF

Принципы организации трафика Internet

Overview and Principles of Internet Traffic Engineering

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

Этот документ содержит информацию для сообщества Internet и не определяет каких-либо стандартов. Документ может распространяться свободно.

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

Аннотация

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

1.0 Введение

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

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

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

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

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

1.1. Что такое организация трафика Internet?

Организация трафика Internet определяется, как аспект построения сети Internet, связанный с оценкой и оптимизацией производительности действующих сетей IP. Организация трафика включает применение технологических и научных принципов к измерению, описанию, моделированию и управлению трафиком Internet [RFC-2702, AWD2].

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

Важной целью формирования трафика Internet является обеспечение надежного функционирования сети [RFC-2702]. Надежность работы сети может быть достигнута за счет обеспечения механизмов, повышающих уровень целостности сети, а также ее устойчивость. Это ведет к минимизации уязвимости сети к отказам, связанным с ошибками, сбоями и повреждениями, возникающими в инфраструктуре.

Internet существует для передачи информации от узлов-источников к узлам-приемникам. В соответствии с этой задачей одной из наиболее важных функций Internet является маршрутизация трафика от входных узлов к выходным. Следовательно, наиболее значимой функцией формирования трафика Internet является контроль и оптимизация функций маршрутизации, чтобы направить трафик через сеть наиболее эффективным путем.

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

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

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

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

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

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

Таким образом, оптимизационные аспекты организации трафика могут рассматриваться с точки зрения управления. Аспект управления на арене организации трафика Internet может быть превентивным или реактивным. В превентивном варианте управляющая система организации трафика предпринимает упреждающие действия, чтобы избежать возникновения в будущем нежелательных состояний в сети. Могут также приниматься меры по индуцированию более желательных состояний в будущем. В реактивном варианте система управления корректно и, возможно, адаптивно реагирует на происходящие в сети события.

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

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

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

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

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

Оценка производительности в практическом контексте работающей сети может оказаться достаточно сложной. Для упрощения анализа может использоваться множество методов, включаю абстракцию, декомпозицию и аппроксимацию. Например, концептуальные упрощения типа эффективной полосы или эффективного буфера [Elwalid] могут использоваться при аппроксимации поведения узла на уровне пакетов или анализе на уровне соединения. Использование при анализе моделей очередей и схем аппроксимации на основе асимптотического разложения и декомпозиции могут дополнительно упростить ситуацию и сделать результаты анализа более понятными. В частности, новый набор концепций, известный, как сетевые вычисления [CRUZ], и основанный на детерминированных границах, может упростить анализ сети по сравнению со случаем использования классических стохастических методов. При использовании аналитических методов следует осторожно выбирать модели, чтобы они достаточно точно отражали соответствующие характеристики моделируемых сетевых элементов.

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

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

1.2. Рассматриваемые вопросы

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

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

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

Хотя документ сконцентрирован на рассмотрении внутридоменного трафика, в разделе 7.0 дается обзор организации междоменного трафика. Организация междоменного трафика Internet имеет очень важное значение для производительности инфраструктуры Internet в целом.

В документе (там, где это возможно) даются ссылки на связанные с темой документы IETF и других организаций.

1.3 Терминология

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

Baseline analysis — базовый анализ

Исследование, выполненное в качестве основы для сравнения с реальным поведением сети.

Busy hour — час с наибольшей нагрузкой

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

Bottleneck — узкое место (горлышко бутылки)

Элемент сети, для которого входная скорость превышает выходную.

Congestion — насыщение (перегрузка)

Состояние сетевого ресурса, при котором трафик для этого ресурса превышает его выходные возможности в данный момент.

Congestion avoidance — предотвращение насыщения

Модель контроля насыщения, которая пытается предотвратить возникновение перегрузок.

Congestion control — контроль насыщения

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

Constraint-based routing — принудительная (основанная на ограничениях) маршрутизация

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

Demand side congestion management — контроль насыщения со стороны потребителя

Схема контроля насыщения, в которой проблема перегрузки решается путем регулирования или кондиционирования предлагаемой нагрузки.

Effective bandwidth — эффективная полоса пропускания

Минимальная полоса, которая может быть выделена для потока или агрегата трафика, чтобы обеспечить приемлемое качество обслуживания для потока или агрегата трафика.

Egress traffic — выходной трафик

Трафик, выходящий из сети или элемента сети.

Hot-spot — горячая точка

Элемент сети или подсистема, находящиеся в состоянии насыщения.

Ingress traffic — входной трафик

Трафик, входящий в сеть или элемент сети.

Inter-domain traffic — междоменный трафик

Трафик, генерируемый в одной автономной системе и принимаемый в другой АС.

Loss network — сеть с потерями

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

Metric — метрика

Параметр, определенный в терминах стандартных единиц измерения.

Measurement Methodology — методология измерений

Повторяемая методика измерения, применяемая для одной или множества метрик.

Network Survivability — живучесть сети

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

Offline traffic engineering — внешняя организация трафика

Система организации трафика, находящаяся за пределами сети.

Online traffic engineering — внутренняя организация трафика

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

Performance measures — измерение производительности

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

Performance management — контроль производительности

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

Performance Metric — метрика производительности

Параметр производительности, определяемый в терминах стандартных единиц измерения.

Provisioning — обеспечение

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

QoS routing — маршрутизация на основе QoS

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

Service Level Agreement — соглашение об уровне обслуживания

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

Stability — стабильность

Эксплуатационное состояние, в котором сеть не осциллирует в деструктивной манере из одного режима в другой.

Supply side congestion management — контроль насыщения со стороны поставщика

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

Transit traffic — транзитный трафик

Трафик, адресат и отправитель которого находятся за пределами рассматриваемой сети.

Traffic characteristic — характеристики трафика

Описание временных изменений или атрибутов данного потока трафика или агрегата трафика.

Traffic engineering system — система организации трафика

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

Traffic flow — поток трафика

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

Traffic intensity — интенсивность (уровень) трафика

Мера нагрузки от трафика относительно емкости ресурсов для заданного периода времени. В классических телефонных системах интенсивность трафика измеряется в Эрлангах (Erlang).

Traffic matrix — матрица трафика

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

Traffic monitoring — мониторинг трафика

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

Traffic trunk — транк трафика

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

2.0 Основы

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

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

2.1 Контекст организации трафика Internet

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

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

Контекст организации трафика Internet и различные сценарии проблем рассматриваются в остальной части раздела.

2.2 Сетевой контекст

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

Концептуально, на базовом уровне абстракции сеть IP может быть представлена, как распределенная динамическая система, состоящая из (1) набора соединенных между собой ресурсов, обеспечивающих транспортировку трафика IP, с некоторыми ограничениями, (2) системы запросов, предлагающей нагрузку для доставки через сеть и (3) системы откликов, включающей сетевые процессы, протоколы и механизмы, которые способствуют перемещению трафика через сеть [см. также AWD2].

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

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

Современным сетям Internet присущи три важных характеристики: (1) предоставление услуг в реальном масштабе времени, (2) критическая важность и (3) быстро меняющаяся рабочая среда. Динамичность характеристик сетей IP отчасти можно объяснить изменениями спроса, взаимодействиями между различными протоколами и процессами, быстрыми изменениями инфраструктуры, требующие постоянного включения новых технологий и элементов, а также временные и постоянные повреждения в системах.

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

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

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

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

В Internet становится все больше разных классов трафика с разными требованиями по обслуживанию. Появление дифференцированных услуг [RFC-2475] дополнительно обостряет эти требования. Таким образом, пакеты могут группироваться в поведенческие агрегаты, каждому из которых будет присуще определенный набор характеристик поведения или параметров доставки. На практике требования по доставке конкретного множества пакетов могут выражаться явно или неявно. Два наиболее важных параметра доставки трафика связаны с ограничениями возможностей (capacity) и QoS.

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

2.3 Контекст проблемы

Существует фундаментальная проблема связанная с работой сети, описываемой простой моделью из предыдущего параграфа. В данном параграфе рассматривается контекст проблемы в связи с функцией построения трафика.

Идентификация, абстрагирование, представление и измерение параметров сети, относящихся к организации трафика, являются важными вопросами.

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

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

Еще один класс задач относится к характеристикам состояний сети и способам оценки производительности в разных условиях. Задача оценки производительности делится на две части. Один аспект проблемы связан с оценкой системного уровня производительности сети. Другой аспект относится к оценке производительности на уровне ресурсов и связан с оценкой продуктивности работы отдельных сетевых ресурсов. В этом документе характеристики системного уровня сети будем называть макро-состояниями, а характеристики уровня ресурсов — микро-состояниями. Характеристики системного уровня называют также вторичными (emergent), как отмечено выше. Следовательно, схемы организации трафика, имеющие дело с оптимизацией производительности на системном уровне, будут называться макро-TE, а схему, оптимизирующие на уровне отдельных ресурсов — микро-TE. В некоторых случаях производительность на системном уровне может быть выведена из характеристик на уровне ресурсов путем применения подходящих правил композиции в зависимости от интересующей метрики производительности.

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

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

2.3.1 Насыщение и его последствия

Насыщение (перегрузка) является одной из наиболее значимых проблем в контексте работы сетей IP. Насыщение сетевого элемента означает наличие на нем перегрузки в течение некоторого интервала времени. Перегрузка практически всегда приводит к ухудшению обслуживания конечных пользователей. Схемы контроля перегрузок могут включать политику сайтов-потребителей и сайтов-поставщиков. Политика потребителей может ограничивать доступ к перегруженным ресурсам и/или динамически регулировать запросы для преодоления перегрузки. Политика поставщиков может сужать или расширять пропускную способность для более эффективной передачи предлагаемого трафика. Такая политика может также перераспределять сетевые ресурсы путем перенаправления трафика в сетевой инфраструктуре. Перераспределение трафика и ресурсов служат для увеличения «эффективной пропускной способности» для потребителей.

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

2.4 Контекст решения

Контекст решения по организации трафика Internet включает анализ, оценку вариантов и выбор действия. Обычно контекст решения основан на представлениях о текущем или будущем состоянии сети и последующем принятии решения, которое может включать выбор наиболее предпочтительного из нескольких вариантов действий. Более конкретно, контекст решения требует оценки трафика, определения состояния сети и поиск решения по организации трафика, которое может формулироваться явно или неявно и может также включать управляющие воздействия. Такие воздействия могут включать манипуляции с параметрами маршрутизации, расширение «мощностей» и применение функций управления трафиком.

Ниже приведен список инструментов, применимых в контексте решения по организации трафика Internet.

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

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

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

Маршрутизация в сетях IP может административно контролироваться на разных уровнях абстракции, включая атрибуты BGP и изменение метрики IGP. Для ориентированных на пути технологий типа MPLS маршрутизация может дополнительно контролироваться путем изменения параметров организации трафика, параметров ресурсов и административных ограничений. В контексте MPLS путь с явной коммутацией по меткам (LSP) можно рассчитать и организовать разными способами: (1) вручную, (2) автоматически (online) с использованием основанного на ограничениях процесса маршрутизации, реализованного на маршрутизаторах с коммутацией по меткам или (3) автоматически (offline) с помощью основанных на ограничениях элементах маршрутизации во внешних системах поддержки организации трафика.

2.4.1 Решение проблемы перегрузок

Минимизация перегрузок является важным аспектом организации трафика Internet. В этом параграфе дается обзор основных вариантов решения проблемы перегрузок.

Вопросы контроля перегрузок можно разделить на несколько категорий (в работе [YARE95] схемы контроля перегрузок рассмотрены более подробно): (1) время реализации (быстро, средне, медленно), (2) реактивные и превентивные меры контроля и предотвращения перегрузок, (3) контроль на стороне поставщиков и потребителей. Эти аспекты более подробно рассматриваются в последующих параграфах.

Контроль перегрузок по продолжительности решений
- Долгосрочные решения (от недель до месяцев). Планирование сетевых мощностей на достаточно продолжительный срок основывается на оценках или предсказаниях потребностей в трафике и его распределении. Поскольку организация каналов и установка маршрутизаторов требует времени, обновления обычно длятся недели и месяцы, а иногда — годы.
- Среднесрочные решения (дни). Некоторые правила попадают в среднесрочную категорию. Примеры таких правил включают: (1) подстройку параметров IGP и/или BGP для маршрутизации трафика некоторых сегментов сети; (2) организацию и настройку некоторых явных путей с коммутацией по меткам (ER-LSP³) в сетях MPLS для отвода транков трафика за пределы перегруженных участков или перевода на предпочтительные пути; (3) перенастройка логической топологии сети с учетом пространственного распределения трафика (например, за счет использования на базовых уровнях ориентированных на пути технологий типа MPLS LSP, ATM PVC или группы оптических каналов). Многие из таких адаптивных схем основаны на системах измерения, осуществляющих мониторинг распределения трафика и загрузки сетевых ресурсов с передачей информации механизмам организации трафика. Механизмы и средства организации трафика могут быть распределенными или централизованными, а их структура может быть плоской или иерархической. Сравнительные метрики для распределенных и централизованных систем управления известны достаточно хорошо. Централизованные системы могут иметь глобальную область действия и обеспечивать более оптимальные решения. Однако такие системы менее отказоустойчивы по сравнению с распределенными схемами. Более того, используемая централизованной схемой информация может быть устаревшей и не соответствующей реальному состоянию сети. Рекомендации по выбору централизованной или распределенной схемы управления выходят за рамки данного документа. Этот выбор сетевые администраторы должны делать сами с учетом своих реальных потребностей.
- Краткосрочные решения (от пикосекунд до минут). Эта категория включает функции обработки на уровне пакетов и события со сроком действия порядка нескольких периодов кругового обхода. Сюда входят механизмы маршрутизаторов для активного и пассивного управления буферами. Эти механизмы служат для контроля перегрузок и/или информирования о них конечных систем, которые могут в результате адаптивно менять скорость передачи трафика в сеть. Одним из наиболее популярных (особенно для TCP) механизмов является RED⁴ [FLJA93], который предотвращает перегрузки путем контроля среднего размера очереди. Во время перегрузки (но до заполнения очереди) схема RED выбирает приходящие пакеты для «маркировки» в соответствии с вероятностным механизмом, принимающим во внимание средний размер очереди. Для маршрутизаторов, не использующий явных уведомлений о перегрузке (ECN⁵) (см., например, [FLOY94]), отмеченные пакеты могут просто отбрасываться для сигнализации перегрузки конечным системам. С другой стороны, если маршрутизатор поддерживает ECN, он может установить поле ECN в заголовке пакета. Были предложены варианты RED с поддержкой разных уровней предпочтения при отбрасывании в средах с множеством классов трафика [RFC-2597] (например, RIO⁶ и Weighted RED). Принято считать, что RED предотвращает перегрузки не хуже, чем управление очередями TD⁷ (отбрасывание прибывающих пакетов при заполнении очереди). Важно отметить, что RED снижает вероятность глобальной синхронизации и более беспристрастен к разным сессиям TCP. Однако сам по себе RED не может предотвратить перегрузок и не обеспечивает беспристрастности при наличии отправителей, не воспринимающих RED (например, трафик UDP и некоторые реализации с ошибками). Были предложены другие схемы повышения производительности и уровня беспристрастности в присутствии «безответственного» трафика. Некоторые из таких схем были предложены, как теоретические модели и не всегда доступны в существующих коммерческих системах. Двумя такими схемами являются LQD⁸ и RND⁹ [SLDC98].
Превентивные и реактивные меры
- Реактивный контроль перегрузок (восстановление) заключается в реагировании на возникшие проблемы с перегрузками. Большинство перечисленных выше долгосрочных и среднесрочных мер может быть отнесено к категории реактивных, особенно в тех случаях, когда политика основывается на мониторинге и идентификации возникающих перегрузок, включая соответствующие действия по облегчению ситуации.
- Превентивные (предсказание/предотвращение) меры ставят своей целью предотвращение перегрузок на основе оценок и прогнозов. Некоторые упомянутые выше долгосрочные и среднесрочные меры относятся к категории превентивных. Они не обязательно являются откликом на возникшие проблемы насыщения. Прогнозы потребностей в трафике и распределения нагрузки могут предотвратить возникновение перегрузок в будущем. Схемы, упомянутые в краткосрочных мерах (например, RED и варианты, ECN, LQD, и RND), могут служить для предотвращения перегрузок за счет отбрасывания или маркировки пакетов до того, как реальное переполнение очередей заставит отправителей TCP снижать скорость передачи.
Решения на стороне поставщиков и потребителей
- Меры контроля насыщения на стороне поставщика включают расширение эффективной полосы пропускания трафика. Это может быть достигнуто за счет повышения производительности. Другой вариант может обеспечиваться за счет оптимизации распределения трафика по сети. Например, может быть обеспечено повышение производительности за счет увеличения числа каналов и повышения их пропускной способности в соответствии с прогнозами роста трафика, а также оптимизация распределения трафика на основе прогнозов (с учетом бюджетных и других ограничений). Однако, если реальное распределение трафика не соответствует топологии, созданной при планировании производительности (например, ошибки в прогнозах или отсутствие соответствующих возможностей), трафик может отображаться на существующую топологию с использованием ориентированных на пути технологий (например, MPLS LSP или оптические каналы) для изменения логической топологии, а также с помощью иных механизмов перераспределения трафика.
- Меры контроля перегрузок на стороне потребителя также могут способствовать преодолению и предотвращению перегрузок. Например, некоторые из описанных выше краткосрочных мер (RED с вариантами, ECN, LQD, RND) а также правила и механизмы формирования трафика позволяют регулировать уровень загрузки. Одним из инструментов воздействия могут служить и тарифы. Однако сегодня тарифная политика на стороне потребителей практически не используется для контроля перегрузок в Internet.

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

2.5 Контекст реализации и эксплуатации

Операционный контекст организации трафика Internet характеризуется постоянными изменениями на разных уровнях абстракции. В контексте реализации требуется эффективное планирование, организация и исполнение. Аспекты планирования могут включать определение набора действий для достижения желаемых целей. Организация включает распределение ответственности за различные компоненты систем организации трафика и координацию действий по достижению целей TE. Исполнение включает оценку и состояния и корректировочные действия в целью поддержки желаемого состояния TE.

3.0 Модель процесса организации трафика

В этом разделе описывается общая модель процесса, которая захватывает практические аспекты верхних уровней организации трафика Internet в операционном контексте. Модель описывается как последовательность действий, которые организатор или, в более общем виде, система организации трафика должна предпринять для оптимизации производительности работающей сети (см. также [RFC-2702, AWD2]). Описываемая модель представляет широкую область действий для большинства методологий организации трафика, хотя детали такой организации могут меняться от сети к сети. Эта модель может также явно или неявно исполняться человеком и/или автоматически.

Модель процесса организации трафика является итеративной [AWD2]. 4 описанных ниже фазы модели процесса повторяются непрерывно.

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

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

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

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

3.1 Компоненты модели организации трафика

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

3.2 Измерения

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

При разработке системы измерения для поддержки организации трафика в сетях IP следует внимательно рассмотреть ряд вопросов. Почему нужно измерять именно в этом контексте? Какие параметры измеряются? Как следует проводить измерения? Где следует выполнять измерения? Когда следует выполнять измерения? Как часто следует измерять переменные при мониторинге? Какой уровень точности и надежности измерений желателен? Какой уровень точности и надежности измерений достижим реально? В какой степени измерительные средства могут оказывать влияние на сетевые компоненты и переменные? Какова приемлемая стоимость измерений? Ответы на эти вопросы определяют инструменты и методологию для любого контекста организации трафика.

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

Измерения в поддержку TE могут выполняться на разных уровнях абстракции. Например, можно выполнить измерения для определения характеристик на уровне пакетов, потоков, пользователей, агрегатов трафика, компонент или сети в целом.

3.3 Моделирование и анализ

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

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

В общем случае модели организации трафика Internet можно разделить на структурные и поведенческие. Структурные модели фокусируются на сети и ее компонентах. Поведенческие модели рассматривают динамику сети и ее загрузки. Моделирование организации трафика Internet может быть также формальным и неформальным.

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

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

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

3.4 Оптимизация

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

Как было отмечено выше, оптимизация производительности сети — это непрерывный процесс. Итерации этого процесса могут включать оптимизационные субпроцессы, выполняемые в реальном масштабе времени, а также субпроцессы планирования действий. Разница между оптимизацией в реальном масштабе времени и планированием заключается, прежде всего, во временном масштабе действий и возможности их дробления на более мелкие части. Одной из целей выполняемой в реальном масштабе времени оптимизации является контроль отображения и распределения трафика через существующую сетевую инфраструктуру для предотвращения и/или снижения уровня перегрузок, обеспечения удовлетворительного качества услуг и оптимизации использования ресурсов. Необходимость оптимизации в реальном масштабе времени обусловлена возможностью случайных инцидентов типа повреждения кабеля или резкого роста трафика, которые не зависят от качества организации сети. Такие инциденты могут вызывать перегрузки и другие проблемы в работе сети. Оптимизация в реальном масштабе времени должна решать такие проблемы в кратко- и среднесрочной перспективе (от микросекунд до минут и часов). Примерами такой оптимизации являются управление очередями, настройка метрики IGP/BGP, использование технологий типа MPLS с явными LSP для смены путей некоторых транков [XIAO].

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

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

Важным фактором оптимизации в реальном масштабе времени является стабильность работы сети и этот аспект рассматривается в данном документе неоднократно.

4.0 Исторический обзор и свежие разработки

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

4.1 Организация трафика в классических телефонных сетях

В этом параграфе представлен краткий обзор организации трафика в телефонных сетях, которые часто используются в качестве пути для пользовательского трафика между генерирующим и потребляющим данные узлами. Приведенное здесь описание темы достаточно кратко. Более подробные описания разных стратегий маршрутизации в телефонных сетях даны в книге G. Ash [ASH2].

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

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

В телефонных сетях используется три основных типа динамической маршрутизации — по времени, по состоянию (SDR¹⁰) и по событиям (EDR¹¹).

В маршрутизации по времени используются регулярные изменения картины трафика с течением времени (по дням недели и времени суток) для планирования таблиц маршрутизации. В маршрутизации по состояниям таблицы маршрутизации обновляются в соответствии с текущим состоянием сети (например, потребности в трафике, уровень загрузки и т. п.). В маршрутизации по событиям изменения маршрутов инициируются теми или иными событиями (например, перегрузка или блокировка линий) с использованием обучающихся моделей. Методы EDR являются адаптивными в реальном масштабе времени и не требуют наличия глобальной информации о состоянии, как в SDR. Примеры схем EDR включают DAR¹² от компании BT, STR¹³ от NTT и STT¹⁴ от AT&T.

Динамическая неиерархическая маршрутизация DNHR¹⁵ является примером динамической маршрутизации, реализованной в телефонной сети компании AT&T в 1980-е годы в качестве отклика на регулярные временные вариации загрузки. Зависящую от времени информацию в терминах нагрузки можно разделить по трем интервалам — сутки, неделя и год. Следовательно, для таблиц маршрутизации используется три предопределенных алгоритма. Алгоритм организации сети работает на длинных интервалах (год), тогда как алгоритм обслуживания запросов используется для недельных интервалов с целью подбора полосы каналов и таблиц маршрутизации для исправления ошибок годичного прогнозирования. Для коротких интервалов используется алгоритм маршрутизации, выполняющий в ограниченных масштабах тонкую настройку в соответствии с распределением трафика по времени суток. Годичные и недельные таблицы рассчитываются автономно (offline). Обычно для таких расчетов требуется расширенный поиск возможных маршрутов. С другой стороны, маршрутизация может потребовать расчетов в реальном масштабе времени (online) для обработки нетривиальных ситуаций (crankback). DNHR использует модель «двух каналов» (two-link), в которой путь может включать не более двух каналов. Алгоритм маршрутизации представляет упорядоченный список путей между исходным и целевым коммутатором. При возникновении перегрузки промежуточный коммутатор (на пути между исходным и целевым) будет передавать исходному коммутатору crankback-сигнал. По таком сигналу этот коммутатор будет выбирать следующий маршрут и так далее, пока имеются дополнительные маршруты.

4.2 Развитие организации трафика в сетях пакетной коммутации

В этом параграфе дается обзор предшествующих работ в части повышения производительности сетей передачи данных. Практическая оптимизация производительности сетей передачи данных началась с первых дней существования сети ARPANET. Вклад в работы по оптимизации производительности и дифференцированию услуг внесли и другие коммерческие сети типа SNA.

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

В терминах управления маршрутами сеть Internet использует распределенные протоколы для внутридоменной маршрутизации. Эти протоколы хорошо масштабируются и достаточно отказоустойчивы. Однако они основаны на простых алгоритмах выбора пути с весьма ограниченной функциональностью в части гибкости процесса выбора пути.

В следующих параграфах рассматривается развитие механизмов практической организации трафика в сетях IP и предшественники этих механизмов.

4.2.1 Адаптивная маршрутизация в ARPANET

На ранних этапах существования ARPANET стала ясной важность адаптивной маршрутизации, когда решения о выборе маршрута принимаются на основе текущего состояния сети [MCQ80]. В ранних моделях маршрутизации по минимальной задержке пакеты направлялись адресатам по пути, который обеспечивал минимальное оценочное время доставки. Каждый узел поддерживал таблицу задержек в сети, которые могли возникнуть при передаче пакета адресату по данному пути. Таблица минимальных задержек периодически рассылалась узлами их соседям. Распространялась также информация о кратчайшем пути (в интервалах пересылки — hop count).

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

4.2.2 Динамическая маршрутизация в Internet

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

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

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

Неадекватность системы внутренней маршрутизации Internet послужила одной из причин разработки ориентированных на пути технологий с явными маршрутами и поддержкой маршрутизации с учетом ограничения (типа MPLS).

4.2.3 Маршрутизация ToS

Маршрутизация с учетом типа обслуживания (ToS¹⁶) предполагает поддержку разных маршрутов к одному получателю, выбираемых в зависимости от значения поля ToS в заголовке пакетов IP [RFC-2474]. Классы ToS можно связать с малой задержкой или высокой пропускной способностью. С каждым каналов связывается множество значений «стоимости» и эти значения применяются при расчете маршрута для конкретного ToS. Для каждого значения ToS рассчитывается отдельное дерево с кратчайшим путем. Классическая маршрутизация на основе ToS сейчас считается устаревшей, поскольку соответствующее поле в заголовке IP было заменено полем Diffserv. Эффективная организация трафика при классической маршрутизации на основе ToS была сложна, поскольку для каждого класса по-прежнему использовался единственный кратчайший путь, что приводило к аномалиям распределения трафика через сети.

4.2.4 Множество равноценных путей

ECMP¹⁷ является другим методом, который пытается преодолеть неэффективность систем внутренней маршрутизации SPF¹⁸ [RFC-2328]. В классическом алгоритме SPF при наличии двух или более равноценных путей к адресату алгоритм выбирает один из них. В ECMP алгоритм был слегка изменен, чтобы при наличии между парой узлов двух или более равноценных кратчайших путей разрешить распределение трафика между равноценными путями. Распределение трафика обычно выполняется одним из двух способов — (1) циклический перебор путей на уровне пакетов или (2) выбор пути на уровне потоков с использованием хеширования адресов IP получателя и отправителя, а также других полей заголовка IP. Первая модель может приводить к нарушению порядка доставки пакетов, а вторая зависит от числа и распределения потоков. Распределение нагрузки на уровне потоков может приводить к непредсказуемым результатам в корпоративных сетях, где число потоков сравнительно мало и они более однородны (например, хеширование может создавать неоднородности), но в общем случае такое распределение более эффективно в магистральных сетях с большим числом и неоднородностью потоков трафика.

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

4.2.5 Маршрутизация Nimrod

Система Nimrod разработана для обеспечения маршрутизации в неоднородной среде Internet, когда приходится принимать во внимание множество ограничений [RFC-1992]. Важно отметить, что Nimrod представляет собой протокол маршрутизации на основе состояния каналов, который поддерживает ориентированную на пути пересылку пакетов. Протокол использует концепцию отображения сетевой связности и служб на разных уровнях абстракции. Обеспечиваются механизмы ограничения области распространения маршрутной информации.

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

4.3 Наложенные сети

В модели с наложением (Overlay) используется сеть виртуальных каналов (ATM, Frame Relay, WDM) для организации виртуальных соединений между маршрутизаторами, расположенными на краях облака виртуальных устройств. В этом режиме соединенные между собой виртуальным каналом два маршрутизатора видят себя соединенными напрямую, независимо от физического маршрута виртуального канала через сеть ATM, Frame Relay или WDM. Таким образом, модель с наложением отвязывает видимую маршрутизаторами логическую топологию от физической топологии сети ATM, Frame Relay или WDM. Наложенная сеть на базе ATM или Frame Relay позволяет администратору сети или программам управления реализовать концепции организации трафика для оптимизации пути за счет изменения конфигурации или соединений виртуальных устройств, чтобы менять путь передачи данных при возникновении в сети перегрузок на виртуальных каналах или неоптимальной работе физических соединений. В наложенной сети организация трафика используется также для организации связи между параметрами управления трафиком (например, PCR, SCR, MBS для ATM) технологии виртуальных устройств и реальным трафиком, проходящим через каждое устройство. Эти связи могут создаваться на основе известных или проектных профилях трафика, а также некоторых других факторов.

При наложении сети IP на ATM требуется управление двумя разными сетями с различными технологиями (IP и ATM), что усложняет и удорожает работу. В полносвязной модели с наложением каждый маршрутизатор соединен со всеми другими маршрутизаторами сети и число соединений между маршрутизаторами растет пропорционально квадрату числа маршрутизаторов. Некоторые проблемы модели с наложением рассмотрены в работе [AWD2].

4.4 Маршрутизация с учетом ограничений

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

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

Концепция основанной на ограничениях маршрутизации в контексте требований MPLS по организации трафика в сетях IP была изначально определена в [RFC-2702].

В отличие от маршрутизации на основе QoS (например, [RFC-2386] и [MA]), которая в общем случае решает вопросы маршрутизации отдельных потоков трафика на основе требований к качеству обслуживания (QoS) с учетом доступности сетевых ресурсов, маршрутизация на основе ограничений применима к агрегатам трафика наравне с потоками, а также может использовать различные типы ограничений, включая ограничения, обусловленные политикой.

4.5 Обзор других проектов IETF, связанных с организацией трафика

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

4.5.1 Интегрированные услуги

Рабочая группа IETF Integrated Services подготовила модель интегрированных услуг (Intserv). Эта модель требует резервирования ресурсов (таких, как пропускная способность и буферная емкость) для потоков трафика данного класса с целью обеспечения запрашиваемого для этого класса качества обслуживания. Модель интегрированных услуг включает дополнительные компоненты, сверх применяемых в обычной модели best-effort — к ним относятся классификаторы и планировщики пакетов, а также средства контроля допуска. Классификаторы пакетов служат для идентификации потоков, которым предоставляется определенный уровень обслуживания. Планировщик обеспечивает планирование обслуживания различных потоков трафика для выполнения требований QoS. Контроль допуска служит для определения маршрутизаторов, имеющих ресурсы, потребные для восприятия нового потока.

В модели Integrated Services были определены два типа сервиса — гарантированное обслуживание [RFC-2212] и контролируемая нагрузка (Controlled-load) [RFC-2211].

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

Сервис Controlled-load может применяться для адаптивных приложений, которые устойчивы к некоторой задержке, но чувствительны к перегрузкам в сети. Приложения этого типа обычно удовлетворительно работают в сетях со слабой загрузкой, но их работа существенно ухудшается при росте уровня загрузки в сети. Сервис Controlled-load был разработан для обеспечения обслуживания, близкого к обычному (best-effort) в условиях слабой загрузки сети, независимо от реальных условий в сети. Сервис Controlled-load описывается на качественном уровне в том смысле, что количественные параметры задержки или потерь для него не задаются.

Основной проблемой модели Integrated Services является масштабирование [RFC-2998], особенно в больших публичных сетях IP, где могут одновременно передаваться миллионы микро-потоков.

Важной особенностью модели Integrated Services является явная потребность в механизмах сигнализации для передачи запросов QoS от оконечных систем к маршрутизаторам [RFC-2753]. Протокол RSVP¹⁹ выполняет эти сигнальные функции и является важнейшей компонентой модели Integrated Services. Протокол RSVP рассмотрен ниже.

4.5.2 RSVP

RSVP представляет собой протокол сигнализации для состояний [RFC-2205]. Он поддерживает инициированное получателем резервирование ресурсов как для индивидуальных, так и для групповых потоков данных. RSVP разрабатывался в качестве сигнального протокола для модели интегрированного обслуживания с целью передачи запросов QoS от приложений в сеть для резервирования ресурсов в соответствии с требованиями QoS [RFC-2205].

В RSVP узел-источник или отправитель передает получателю сообщение PATH с теми же адресами отправителя и получателя, которые будут использоваться в генерируемом источником потоке данных. Сообщение PATH включает (1) заданную отправителем спецификацию Tspec с характеристиками трафика, (2) шаблон отправителя Template, задающий формат трафика, и (3) необязательную спецификацию Adspec, служащую для поддержки концепции «в один прием с анонсированием» (OPWA²⁰) [RFC-2205]. Все промежуточные маршрутизаторы на пути пересылают сообщение PATH на следующий интервал, определяемый протоколом маршрутизации. При получении сообщения PATH адресат отвечает на него сообщением RESV, включающим дескриптор потока, для которого запрашивается резервирование ресурсов. Сообщение RESV передается к источнику трафика по пути, обратному относительно пути передачи сообщения PATH. Каждый промежуточный маршрутизатор на пути может принять или отвергнуть резервирование ресурсов, запрошенное в сообщении RESV. Если запрос отвергается, соответствующий маршрутизатор передает получателю данных (отправителю сообщения) сообщение об ошибке и сигнальный процесс на этом завершается. Если запрос принят маршрутизатором, для потока выделяется запрошенная пропускная способность и буферная емкость, а на маршрутизаторе устанавливается соответствующее состояние для данного потока.

Одной из проблем исходной спецификации RSVP была масштабируемость. Это было связано с тем, что резервирование осуществлялось на уровне микропотоков, поэтому число состояний, поддерживаемых на элементах сети росло пропорционально числу микропотоков. Эти вопросы рассмотрены [RFC-2961].

Позднее протокол RSVP был изменен и расширен для снятия остроты проблемы масштабирования. В результате он стал универсальным протоколом сигнализации в Internet. Например, RSVP был расширен для резервирования ресурсов на уровне агрегатов потоков, организации явных путей с коммутацией по меткам MPLS, а также реализации иных сигнальных функций в Internet. Есть также множество предложений по снижению числа обновлений, которые требуется передавать для поддержки организованных сессий RSVP [RFC-2961].

В разработки, связанные с протоколом RSVP, вовлечено множество рабочих групп IETF, включая исходную группу RSVP, рабочие группы MPLS, Resource Allocation Protocol (протокол выделения ресурсов), Policy Framework.

4.5.3 Дифференцированные услуги

Целью работ по дифференцированным услугам (Diffserv²¹) под эгидой IETF была разработка масштабируемых механизмов разбиения трафика на поведенческие агрегаты и последующая дифференцированная трактовка каждого из таких агрегатов в плане обслуживания (в частности, выделения таких ресурсов, как пропускная способность и буферная емкость [RFC-2475]). Одним из основных мотивов разработок Diffserv была потребность в разработке дополнительных механизмов дифференциации трафика в Internet, которые позволят преодолеть проблемы масштабирования, присущие модели Intserv.

Рабочая группа IETF Diffserv определила поле Differentiated Services в заголовке IP (поле DS). Это поле включает 6 битов, которые раньше использовались в заголовках IP, как октет TOS (тип обслуживания). Поле DS служит для индикации условий пересылки, которые желательно обеспечить для пакета на транзитных узлах [RFC-2474]. Рабочая группа Diffserv также стандартизовала множество групп PHB) groups²². За счет использования PHB можно определить несколько классов обслуживания, для которых применяются дифференцированные параметры классификации, правил, формирования трафика и управления буферами.

Для конечных пользователей сетевых услуг получение дифференцированного обслуживания от ISP²³ может потребовать специального соглашения об обслуживании (SLA²⁴) с ISP. SLA может явно или неявно задавать условия кондиционирования трафика (TCA²⁵), которые определяют правила классификации, маркировки, отбрасывания и формования трафика.

Пакеты классифицируются на входе в сеть Diffserv и к ним могут также применяться некие правила и средства формирования трафика. При прохождении пакетов через границу между доменами Diffserv поле DS может изменяться в соответствии с соглашением между этими доменами.

Модель дифференцированных услуг позволяет поддерживать ограниченное число классов обслуживания, указываемых полем DS. Основным преимуществом модели Diffserv по сравнению с Intserv является масштабируемость. Ресурсы распределяются на уровне классов трафика и число поддерживаемых состояний, пропорциональное количеству классов, значительно меньше числа потоков данных от приложений.

Из предыдущего обсуждения должно быть понятно, что модель Diffserv управляет трафиком на уровне отдельного интервала пересылки. Модель управления Diffserv включает набор механизмов управления micro-TE. Для обеспечения требуемого качества обслуживания в сетях Diffserv требуются и другие функции построения трафика типа управления пропускной способностью сетей (включая управление маршрутизацией). Концепция PDB²⁶ была разработана для более эффективного понимания реализации дифференцированных услуг на уровне домена в целом [RFC-3086].

4.5.4 MPLS

MPLS представляет собой схему пересылки пакетов, включающую расширения традиционных протоколов уровня управления IP. MPLS расширяет модель маршрутизации Internet и повышает эффективность управления путями и пересылкой пакетов [RFC-3031].

На входе с домен MPLS маршрутизаторы LSR²⁷ разбивают пакеты IP по классам эквивалентной пересылки (FEC²⁸) на основе множества факторов, включая комбинацию данных из заголовка IP и локальную маршрутную информацию, поддерживаемую LSR. В соответствии с выбранным классом пересылки перед пакетом добавляется метка MPLS. В средах, отличных от ATM/FR, метка имеет размер 32 бита и включает 20-битовое поле метки, 3-битовое экспериментальное поле (ранее известное, как поле класса обслуживания или CoS²⁹), 1-битовый индикатор стека меток и 8-битовое поле TTL. В средах ATM и FR метка содержит информацию, представленную в поле VCI/VPI или DLCI. Поддерживающий MPLS маршрутизатор (LSR) проверяет поле метки и, возможно, экспериментальное поле для использования информации при выборе пути пересылки пакета.

LSR принимают решение о пересылке, используя метки из пакетов в качестве индекса для локальной таблицы NHLFE³⁰. Далее пакет обрабатывается в соответствии с NHLFE. Входящая метка при этом может быть заменена на исходящую, а пакет может быть скоммутирован в следующий LSR. Процесс коммутации по меткам очень похож на переключение по меткам (VCI/VPI) в сетях ATM. До того, как пакет покинет домен MPLS, метка MPLS может быть удалена. LSP³¹ представляет собой путь между входным LSR и выходным LSR, через который проходит помеченный пакет. Маршрут для явного LSP определяется входным узлом (инициатором) LSP. Для организации LSP в MPLS могут применяться сигнальные протоколы типа RSVP или LDP.

MPLS является очень мощной технологией для организации трафика Internet, поскольку она поддерживает явные LSP, позволяющие эффективно задавать основанную на ограничениях маршрутизацию в сетях IP [AWD2]. Требования по организации трафика с использованием MPLS описаны в [RFC-2702]. Расширения RSVP для поддержки явных LSP рассмотрены в [RFC-3209]. Расширение LDP (известное, как CR-LDP) для поддержки явных LSP представлено в [JAM].

4.5.5 Метрики производительности IP

Рабочая группа IETF IPPM³² подготовила набор стандартных метрик, которые могут применяться для мониторинга качества, производительности и надежности услуг Internet. Эти метрики могут использоваться операторами, конечными пользователями, независимыми группами тестирования и поставщиками услуг для лучшего понимания производительности и надежности Internet-компонент «облака», которое они используют или предоставляют в пользование [RFC-2330]. Критерии для метрик производительности, разработанных IPPM WG, описаны в [RFC-2330]. Примерами таких метрик являются потери пакетов на пути в одном направлении [RFC-2680], задержка на пути в одном направлении [RFC-2679], параметры связности между парой узлов [RFC-2678]. К другим метрикам относятся измерения второго порядка для задержек и потери пакетов.

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

4.5.6 Измерение потока

Рабочая группа IETF RTFM³³ подготовила архитектурный документ, определяющий метод задания потоков трафика и множество компонент для измерения параметров потока (измерители, считыватели результатов, управление) [RFC-2722]. Система измерения потоков позволяет измерять и анализировать потоки сетевого трафика с различными целями. Как отмечено в RFC 2722, система измерения потоков может быть очень полезна для (1) изучения поведения существующих сетей, (2) планирования развития и расширения сетей, (3) числового выражения производительности, (4) проверки качества сетевых услуг, (5) описания работы в сети для пользователей.

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

4.5.7 Контроль перегрузки на конечных точках

В [RFC-3124] предложен набор механизмов контроля насыщения, которые могут применяться в транспортных протоколах. Целью документа являлась также разработка механизмов для унификации контроля насыщения среди группы конечных точек с активными индивидуальными (unicast) соединениями (congestion group). Менеджер перегрузок непрерывно контролирует состояние пути для каждой из контролируемых им групп. Полученную информацию менеджер использует для передачи планировщикам инструкций по распределению пропускной способности в периоды возникновения перегрузок для данной группы.

4.6 Обзор действий ITU по части организации трафика

В этом параграфе приводится обзор предшествующих работ ITU-T по организации трафика в традиционных телекоммуникационных сетях.

Рекомендации ITU-T E.600 [ITU-E600], E.701 [ITU-E701] и E.801 [ITU-E801] посвящены вопросам организации трафика в традиционных телекоммуникационных сетях. E.600 определяет терминологию для описания концепций организации трафика, E.701 определяет эталонные соединения, уровень сервиса (GOS³⁴) и параметры трафика ISDN. В E.701 используется концепция эталонного соединения для идентификации типичных случаев различных типов соединений без описания специфики из реальной физической реализации. Как указано в E.600, «соединение представляет собой связывание ресурсов, обеспечиваемых средства коммуникаций между двумя или более устройствами, включенными в телекоммуникационную сеть или подключенными к ней.» E.600 также определяет «ресурс, как любое множество физически или концептуально идентифицируемых элементов телекоммуникационной сети, использование которых может быть однозначно определено» [ITU-E600]. Соединения могут быть разнотипными, поскольку число и тип используемых в них ресурсов может меняться.

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

Эталонные соединения обеспечивают основу для определения параметров уровней обслуживания (GoS), относящихся к организации трафика в модели ITU-T. Как определено в E.600, «GoS использует множество переменных организации трафика, которые позволяют обеспечить контроль адекватности группы ресурсов в конкретных условиях». Такими переменными GoS могут быть потери, тональные сигналы, задержки и т. п. Они важны для организации и эксплуатации сети, а также для спецификации производительности компонент.

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

В соответствии с E.600 набор параметров GoS должен выбираться и определяться на «сквозной» основе (end-to-end basis) для всех основных категорий сервиса, обеспечиваемых сетью, чтобы помочь поставщикам услуг в повышении эффективности сети. На основе выбранного набора эталонных соединений выделяются значения для выбранных параметров GoS в условиях нормальной и высокой загрузки сети. Затем эти «сквозные» значения GoS распределяются по отдельным компонентам ресурсов эталонных соединений.

4.7 Распределение информационного содержимого

В сети Internet преобладают взаимодействия «клиент-сервер», в частности для трафика Web (в будущем возможно доминирование более изощренных медиа-серверов). Расположение и производительность основных информационных серверов оказывают существенное влияние на картину трафика в Internet, а также на приемлемость качества обслуживания с точки зрения конечных пользователей.

Было разработано множество методов распределения и балансирования нагрузки для повышения производительности за счет использования «реплик» информационных серверов. Эти методы могут обеспечивать пространственное распределение трафика и улучшать динамические характеристики Internet за счет динамического распределения «зеркал» с учетом размещения клиентов, исходных серверов, относительной загрузки серверов, относительной загрузки разных сетей и их фрагментов. Такой процесс привязки распределенных серверов к клиентам называют Traffic Directing («режиссура» трафика). Процесс работает на уровне приложений.

Схемам Traffic Directing, распределяющим серверы по разным, географически распределенным местам, могут потребоваться опытные данные о производительности сети для принятия более эффективных решений. В будущем могут потребоваться сетевые измерительные системы для получения таких данных. Набор измеряемых параметров пока не определен.

При возникновении в сети перегрузок системам управления трафиком (Traffic Directing и Traffic Engineering) следует действовать согласованно. Этот вопрос требует дальнейшего изучения.

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

5.0 Классификация систем организации трафика

В этом разделе кратко рассмотрена систематизация моделей организации трафика. Систематизация может быть организована на основе стилей организации трафика и представлений, как показано в списке:

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

Эти системы классификации более подробно рассматриваются в последующих параграфах.

5.1 Организация трафика в зависимости от времени, состояний и событий

Методологии организации трафика можно классифицировать по управляющим факторам — время, состояния или события. Все рассматриваемые в этом документе схемы TE являются динамическими. Статическая организация трафика не предусматривает использования методологии или алгоритмов построения трафика.

В TE по времени используются сохраненные данные о периодических вариациях трафика (например, по времени суток) для предварительного программирования планов маршрутизации и других управляющих механизмов TE. В дополнение к этому могут учитываться подписки пользователей и проекции трафика. Заранее программируемые планы маршрутизации обычно меняются достаточно редко (например, посуточно). Алгоритмы управления по времени не пытаются адаптироваться к случайным изменениям сетевого трафика или сменам условий в сети. Примером такого алгоритма может служить глобальный централизованный оптимизатор, в котором входной информацией является матрица требований QoS для разных классов трафика, как описано в [MR99].

TE в зависимости от состояний адаптирует планы маршрутизации на основе текущего состояния сети. Текущее состояние обеспечивает дополнительные данные о вариациях реального трафика (например, отклонения от регулярных вариаций) которые невозможно предсказать с использованием усредненных временных зависимостей. Примером организации трафика по состояниям для сравнительно длинных интервалов времени является маршрутизация на основе ограничений. Примером систем организации трафика по состоянием для более коротких интервалов могут служить алгоритмы балансировки нагрузки, описанные в [MATE].

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

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

Методы TE на основе событий могут также применяться для выбора пути в TE. Эти методы отличаются от методов TE по времени и состоянию манерой выбора пути. Алгоритмы организации трафика являются адаптивными и распределенными по своей природе и обычно используют модели с обучением для поиска пути TE через сеть. Методы TE по состоянию обычно используют лавинную рассылку ALB³⁵ для выбора пути TE, а основанным на событиях методам TE не нужна рассылка ALB. Вместо этого обычно определяется доступная пропускная способность с использованием обучающихся моделей, как в методе STT³⁶. Лавинная рассылка ALB может быть ресурсоемкой, поскольку ей требуется полоса для рассылки LSA и процессорная мощность для обработки LSA, что может ограничивать размер области действия/автономной системы (AS³⁷). На основании моделирования можно предположить применение методов TE на основе событий для снижения издержек ALB без потери пропускной способности сети [ASH3].

5.2 Автономный и интерактивный расчет

Для организации трафика требуется расчет планов маршрутизации. Расчет может выполняться в автономном (offline) или интерактивном (online) режиме. Автономно вычисления могут выполняться для случаев, когда планы маршрутизации не требуется выполнять в реальном масштабе времени. Например, планы маршрутизации для прогноза, можно рассчитывать автономно. Обычно расчеты этого типа используются также при расширенном поиске в многомерном пространстве решений.

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

5.3 Централизованное и распределенное управление

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

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

5.4 Локальная и глобальная информация

Для алгоритмов организации трафика может потребоваться локальная или глобальная информация о состоянии сети.

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

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

5.5 Предписания и описания

Системы TE можно также разделить на предписывающие и описывающие.

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

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

5.6 Открытые и замкнутые циклы

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

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

5.7 Стратегия и тактика

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

Стратегическая организация трафика рассматривает вопросы TE с более организованных и систематизированных позиций, принимая во внимание среднесрочные и долгосрочные последствия тех или иных правил и действий.

6.0 Рекомендации по организации трафика Internet

В этом разделе даны рекомендации верхнего уровня для организации трафика в сети Internet. Эти рекомендации представлены в терминах общего назначения.

Рекомендации описывают возможности, требуемые для решения проблем в организации трафика и достижения целей организации трафика. В широком смысле эти рекомендации можно разделить на функциональные и нефункциональные.

Функциональные рекомендации по организации трафика Internet описывают функции, которые следует выполнять системам организации трафика. Эти функции нужны для достижения целей организации трафика путем решения проблем в его организации.

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

6.1 Базовые нефункциональные рекомендации

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

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

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

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

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

Стабильность (Stability) — очень важная характеристика систем организации трафика, реагирующих на изменения состояний сети. Методологии организации трафика в зависимости от состояния обычно должны находить компромисс между стабильностью и чувствительностью. При наличии конфликтующих требований настоятельно рекомендуется делать выбор в пользу стабильности (особенно в магистральных IP-сетях общего пользования).

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

Наблюдаемость (Visibility) — в системе TE должны обеспечиваться механизмы сбора статистики из сети и анализа этой статистики для контроля эффективности работы сети. Статистические данные — матрицы трафика, загрузка каналов, задержки, потеря пакетов и другие параметры производительности, которые могут быть определены по измеренным данным — могут служить индикаторами преобладающих в сети условий. Другим примером данных о состоянии, которые следует контролировать, является информация об имеющихся маршрутах (в контексте MPLS информация о маршрутах LSP ) и т. п.

Простота (Simplicity) — в общем случае система TE должна быть максимально простой. Важнейшим свойством систем TE является простота использования (т.е., ясный, удобный и интуитивно понятный пользовательский интерфейс). Простота пользовательского интерфейса совсем не означает использования в системе TE примитивных алгоритмов. При использовании сложных алгоритмов и внутренних структур эти сложности должны быть скрыты от сетевого администратора простым пользовательским интерфейсом.

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

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

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

6.2 Рекомендации по маршрутизации

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

Традиционные протоколы внутренней маршрутизации по кратчайшему пути (SPF³⁸) основаны на алгоритмах выбора кратчайшего пути через сеть и им присущи весьма ограниченные возможности управления в части организации трафика [RFC-2702, AWD2]. Ограничения этих протоколов рассмотрены ниже.

Общеизвестно, что протоколы SPF при выборе маршрута не принимают во внимание ограничения сетей и характеристики трафика. Например, по причине использования протоколами IGP кратчайших путей (на основе административно заданной метрики) пересылки трафика не обеспечивается возможность распределения нагрузки между неравноценными путями. Использование кратчайшего пути для пересылки трафика позволяет экономить ресурсы, но может вызывать ряд проблем: 1) если трафик от источника к адресату превышает пропускную способность канала на кратчайшем пути, на канале (и, следовательно, кратчайшем пути) возникает перегрузка, а более длинные пути между данной парой узлов при этом могут быть не загруженными; 2) кратчайшие пути для разных отправителей могут совпадать на некоторых каналах (если общий трафик от всех источников превысит возможности такого канала, возникает перегрузка). Проблемы могут также возникать в результате изменения трафика с течением времени, если маршрутная конфигурация не изменится достаточно быстро. Это приводит к тому, что топология сети и маршрутная конфигурация со временем становятся не оптимальными, что может приводить к возникновению постоянной перегрузки.
Поддержка множества равноценных путей (ECMP³⁹) в SPF IGP позволяет распределять трафик по нескольким равноценным путям между парами узлов. Однако ECMP пытается разделить трафик поровну между такими путями. В общем случае ECMP не поддерживает настраиваемого распределения нагрузки между равноценными путями. В результате загрузка путей может существенно различаться, поскольку пути могут использоваться также для трафика других узлов. В конечном итоге это может приводить к перегрузкам отдельных каналов.
Изменение метрики IGP для управления маршрутизацией трафика оказывает влияние на всю сеть. В результате могут возникать непредвиденные или нежелательные изменения картины трафика. Недавние работы, упомянутые в разделе 8.0 могут обеспечить более эффективный контроль [FT00, FT01].

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

Маршрутизация на базе ограничений желательна для развития архитектуры маршрутизации IP-сетей, особенно в сложных опорных сетях IP с комплексной топологией [RFC-2702]. В маршрутизации на основе ограничений маршруты рассчитываются с учетом выполнения требований, связанных с ограничениями. Ограничения могут применяться для пропускной способности, числа интервалов, задержек или средств административного управления правилами типа классов атрибутов для ресурсов [RFC-2702, RFC-2386]. Это позволяет выбирать маршруты, соответствующие заданному набору требований, на которые могут воздействовать сетевые или административные ограничения. Основанная на ограничениях маршрутизация хорошо работает с основанными на путях технологиями, которые поддерживают явную маршрутизацию (например, MPLS).

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

Требуется внести множество изменений в обычные протоколы IGP на основе состояния канала (такие, как OSPF и IS-IS), чтобы позволить им распространение дополнительной информации о состояниях, требуемой для маршрутизации на основе ограничений. Такие расширения для протокола OSPF были описаны в [KATZ], а для IS-IS — в [SMIT]. Важно отметить, что такие усовершенствования требуют распространения дополнительной информации в анонсах состояний каналов. В частности, дополнительно к основным данным о состоянии канала от усовершенствованного IGP требуется распространять топологическую информацию, требуемую для маршрутизации на основе ограничений. Такая дополнительная топологическая информация может включать атрибуты канала типа доступной для резервирования пропускной способности и атрибутов класса ресурсов (административно управляемое свойство канала). Концепция атрибутов класса ресурсов определена в [RFC-2702]. Дополнительная топологическая информация передается в новых TLV и суб-TLV протокола IS-IS или в Opaque LSA протокола OSPF [SMIT, KATZ].

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

В системах TE желательно также обеспечивать для подсистемы маршрутизации возможность настраиваемого распределения нагрузки между несколькими (равноценными или неравноценными) путями. Такая возможность позволяет администратору более гибко управлять распределением трафика через сеть. Это может оказаться весьма полезным для предотвращения или ослабления перегрузок в некоторых ситуациях. Примеры приведены в [XIAO].

Системам маршрутизации также следует поддерживать возможность контроля маршрутов для некого подмножества трафика без воздействия на маршрут остального трафика, если ресурсы это позволяют. Такая возможность обеспечивает более тонкий контроль за распределением трафика через сеть. Например, возможность переноса трафика некой пары отправитель-получатель с одного пути на другой без воздействия на остальной трафик позволяет перенести поток данных на маршрут с достаточным количеством ресурсов. Ориентированные на пути технологии (типа MPLS) изначально поддерживают такую возможность, как показано в [AWD2].

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

6.3 Рекомендации по отображению трафика

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

Важной особенностью функции отображения трафика является способность организовать множество путей между данными отправителем и получателем, а также возможность распределять трафик между парой узлом по некому множеству путей в соответствии с теми или иными правилами. Условием использования такой схемы является наличие гибких механизмов деления трафика и его распределения по разным «параллельным» путям. Эти требования были отмечены в [RFC-2702]. При распределении трафика по множеству параллельных путей рекомендуется принимать специальные меры по сохранению порядка доставки пакетов, относящихся к одному приложению (или микропотоку).

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

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

6.4 Рекомендации по измерению

Измерения играют важную роль для организации трафика, обсуждаемой в этом документе. Следует обеспечивать механизмы измерения и сбора статистики из сети для поддержки функций организации трафика. Для анализа собранной статистики могут потребоваться дополнительные средства. Работа механизмов анализа не должна негативно влиять на точность и целостность собранных данных. Механизмы сбора статистических данных должны быть масштабируемыми с учетом возможного расширения сети.

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

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

Собранная статистика трафика должна обеспечивать разумные и надежные индикаторы текущего состояния сети в краткосрочной ретроспективе. Некоторые элементы краткосрочной статистики могут отражать уровень загрузки или насыщения каналов. Примерами индикаторов перегрузки могут служить значительные задержки пакетов, высокий уровень потерь или значительная загрузка ресурсов. Примерами механизмов распространения статистических данных могут служить SNMP, зонды, FTP, анонсы состояния каналов IGP и т. п.

6.5 Жизнестойкость сети

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

Защита от отказов и средства восстановления стали доступными на многих уровнях в качестве сетевых технологий и продолжают совершенствоваться. В основании многоуровневого стека современные оптические сети поддерживают кольца и многосвязные топологии для быстрого восстановления на уровне длин волн, а также традиционные механизмы защиты. На уровне SONET/SDH средства обеспечения жизнестойкости включают автоматическое переключение (APS⁴⁰), а также кольцевые и многосвязные топологии с функциями «самолечения». Подобная функциональность обеспечивается и технологиями канального уровня типа ATM (в общем случае в более медленным восстановлением). На уровне IP традиционно применяется изменение маршрутов для восстановления при отказах каналов или узлов. Перемаршрутизация на уровне IP выполняется по истечении времени схождения маршрутов, которое может составлять секунды и даже минуты. Некоторые разработки в контексте MPLS обеспечивают восстановление на уровне IP до завершения схождения маршрутов [SHAR].

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

Недавно был предложен общий стек протоколов управляющего плана для MPLS и оптических транспортных сетей, названный Multi-protocol Lambda Switching [AWD1]. Новая парадигма мультипротокольной коммутации по длинам вол н будет поддерживать более изощренные возможности восстановления на оптическом уровне за счет многосвязности для архитектуры с передачей трафика IP по сетям с мультиплексированием по длине волны (WDM).

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

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

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

Ниже представлены некоторые общие рекомендации в части координации защиты и восстановления.

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

6.5.1 Живучесть сетей на базе MPLS

MPLS представляет собой развивающуюся технологию, которая расширяет возможности сетей IP в плане функциональности, свойств и услуг. Поскольку технология MPLS ориентирована на пути, она потенциально может обеспечить более быструю и предсказуемую защиту и восстановление по сравнению с традиционной поэтапной маршрутизацией IP. В этом параграфе рассмотрены некоторые базовые аспекты и рекомендации для сетей MPLS в части защиты и восстановления. Более полное рассмотрение вопросов восстановления на базе MPLS проведено в [SHAR].

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

Защита канала. Целью защиты канала является защита LSP от отказов на данном канале. При использовании защиты канала защитный путь или резервный (вторичный) LSP отсоединяется от пути рабочего (основного) LSP на конкретном канале, который требуется защитить. При отказе на защищенном канале рабочий LSP переключается на защитный в «голове» (head-end) отказавшего канала. Такой способ «локального ремонта» обеспечивает очень быстрое восстановление. Этот метод может хорошо подходить для ситуаций, когда некоторые элементы данного пути менее надежны по сравнению с другими.
Защита узла. Целью защиты узла является защита LSP в случае отказа на данном узле. При использовании защиты узла защитный LSP отсоединяется от рабочего LSP на данном защищаемом узле. Вторичный путь отсоединяется также от основного пути на всех каналах, связанных с защищаемым узлом. При отказе узла трафик переключается с рабочего LSP на резервный через систему защиты LSP на восходящем маршрутизаторе LSR, непосредственно подключенном к отказавшему узлу.
Защита пути. Целью защиты пути LSP является защита LSP от отказов в любой из точек этого пути. При использовании защиты пути защитный LSP полностью отсоединяется от рабочего LSP. Преимущество защиты пути заключается в том, что резервный путь защищает рабочий LSP от отказов на любом из узлов и каналов на пути, за исключением отказов, которые могут возникать на входном или выходном LSR, а также для связанных отказов, которые могут воздействовать одновременно на рабочий и резервный путь. Кроме того, благодаря сквозному характеру защиты пути, она может быть более эффективной в плане использования ресурсов по сравнению с защитой узлов или каналов. Однако защита пути в общем случае срабатывает медленней защиты узла или канала.
Защита сегмента. Домен MPLS может быть разделен на множество областей защиты, отказ в каждой из которых не распространяется за ее пределы. В тех случаях, когда LSP проходит множество областей защиты, используемого в каждой области механизма достаточно для защиты лежащего в этой области сегмента LSP. Защита сегментов в общем случае работает быстрее защиты пути, поскольку восстановление обычно выполняется ближе к точке отказа.

6.5.2 Варианты защиты

Другой вопрос связан с вариантами защиты. При описании этих вариантов используются обозначения m:n, где m указывает число защитных LSP, применяемых для защиты n работающих LSP. Возможные варианты приведены ниже.

1:1 — один работающий путь LSP защищается одним защитным/восстановительным LSP;
1:n — один защитный LSP используется для защиты/восстановления n рабочих LSP;
n:1 — для одного рабочего LSP защита/восстановление обеспечиваются n защитных LSP, возможно с настраиваемым распределением нагрузки между ними. При использовании более одного защитного LSP может оказаться желательным распределение трафика между такими LSP в случаях отказа на рабочем LSP для выполнения требований к транку трафика, связанному с рабочим LSP. Особенно полезно это может оказаться в тех случаях, когда нет возможности выбрать один защитный путь, который будет соответствовать требованиям к пропускной способности для основного LSP.
1+1 — трафик передается одновременно по рабочему и защитному LSP. В этом случае входной маршрутизатор LSR выбирает один из двух LSP на основе локального процесса обеспечения целостности трафика, который сравнивает трафик обоих путей LSP и обнаруживает несоответствия. Широкое распространение этого варианта в сетях IP маловероятно по причине неэффективности использования ресурсов. Однако доступность и дешевизна пропускной способности могут сделать этот вариант подходящим и эффективным решением для сетей IP.

6.6 Организация трафика в средах Diffserv

В этом параграфе приведен обзор функций организации трафика и рекомендации, применимые для сетей IP с поддержкой дифференцированных услуг (Diffserv⁴¹) [RFC-2475].

Растущие требования по поддержке множества классов трафика (таких, как best effort и mission critical data) в сети Internet заставляет сети IP дифференцировать трафик в соответствии с некоторыми критериями и предоставлять преимущества некоторым типам трафика. Множество потоков можно объединить в небольшое число поведенческих агрегатов на базе тех или иных критериев в терминах общих параметров производительности, вероятности потери пакетов, задержек и их вариаций или полей заголовков в пакетах IP.

По мере развития Diffserv и развертывания этой технологии в работающих сетях роль организации трафика становится критически важной для обеспечения контрактов SLA с данным классом обслуживания модели Diffserv. Классы обслуживания (CoS⁴²) могут поддерживаться в среде Diffserv путем конкатенации PHB⁴³ на пути маршрутизации использования механизмов обеспечения услуг и подобающей настройки краевой функциональности (классификация трафика, его маркировка, формование и применение правил). PHB представляет собой модель поведения при пересылке, которая применяется к пакетам на узлах DS (узлы, поддерживающие Diffserv). Нужное поведение обеспечивается за счет управления буферами и механизмами планирования обработки пакетов. В этом контексте относящимися к некому классу пакетами являются те пакеты, которые принадлежат к соответствующему агрегату упорядочения.

Организация трафика может служить дополнением к механизмам Diffserv для повышения эффективности использования сетевых ресурсов, но в общем случае не является обязательным элементом. При использовании организации трафика она может применяться интегрировано для всех классов обслуживания [RFC-3270] или независимо для каждого класса. Первый вариант служит для повышения эффективности распределения доступных сетевых ресурсов для агрегата трафика (см. [RFC-3270], где подробно описана организация трафика на уровне агрегатов). Второй вариант рассматривается ниже, поскольку он специфичен для сред Diffserv с так называемым построением трафика, понимающим Diffserv [DIFF_TE].

Для некоторых сетей Diffserv может оказаться желательным контроль производительности для некоторых классов трафика путем установки неких соотношений между вносимой каждым из классов долей трафика и размером сетевых ресурсов, выделяемых или обеспечиваемых для этого класса. Такие связи между запросами ресурсов и их выделением можно установить с использованием комбинаций, включающих, например, (1) механизмы организации трафика по классам, которые задают желаемую связь объема трафика данного класса с выделяемыми этому классу ресурсами, и (2) механизмы, которые динамически регулируют выделяемые для данного класса ресурсы в соответствии с объемом трафика данного класса.

Кроме того, может оказаться желательным ограничить влияние высокоприоритетного трафика на трафик со сравнительно низким приоритетом. Это может быть достигнуто, например, за счет контроля доли высокоприоритетного трафика, который маршрутизируется через данный канал. Другим способом является увеличение пропускной способности каналов до такой степени, которая позволит даже для трафика с низким приоритетом обеспечить нужное качество обслуживания. Когда соотношения трафика разных классов сильно меняются от маршрутизатора к маршрутизатору, для управления трафиком могут потребоваться дополнительные механизмы сверх традиционных протоколов маршрутизации IGP и построения трафика для разных классов. Вместо этого может потребоваться построение трафика и контроль маршрутизации непосредственно по классам обслуживания. Одним из путей решения этой задачи в доменах, поддерживающих одновременно MPLS и Diffserv, будет определение специфичных для класса LSP и отображение трафика каждого класса в один или множество соответствующих классу обслуживания LSP. После этого LSP, соответствующий данному классу обслуживания, можно маршрутизировать и защищать/восстанавливать по правилам, определяемым классом обслуживания.

Организация трафика по классам может потребовать распространения неких параметров классов. Отметим, что общепринято использование для некоторых классов общих агрегатных ограничений (например, требование к максимальной пропускной способности) без задания ограничений для каждого отдельного класса. Такие классы в этом случае можно группировать в class-type и распространять параметры per-class-type, что позволит повысить уровень масштабируемости. В рамках одного class-type можно организовать более эффективное использование пропускной способности. class-type представляет собой набор классов, удовлетворяющих двум условиям:

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

Примером class-type может служить класс с малыми потерями (low-loss class-type) включающий агрегаты упорядочивания (Ordering Aggregate) на базе AF1 и AF2 одновременно. Для такого class-type можно реализовать некие правила, в соответствии с которыми можно предоставить более высокий приоритет преемственности для трафика AF1 по сравнению с AF2 или наоборот.

Подробное описание требований по организации трафика с учетом Diffserv приведено в [DIFF-TE].

6.7 Управляемость сетей

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

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

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

7.0 Междоменное взаимодействие

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

Обмен трафиком между автономными системами в Internet происходит на основе протоколов внешней маршрутизации. В настоящее время стандартным протоколом этого типа для сети Internet является BGP [BGP4]. Этот протокол поддерживает множество атрибутов и возможностей (например, фильтрацию маршрутов), которые могут применяться для организации трафика между доменами. Более конкретно, BGP позволяет контролировать обмен трафиком и маршрутной информацией между автономными системами (AS⁴⁴) в Internet. BGP включает процесс последовательного принятия решений, в котором рассчитывается уровень предпочтения для разных маршрутов в заданную сеть. Ниже указаны два фундаментальных аспекта организации междоменного трафика с использованием BGP.

Распространение маршрутов (Route Redistribution) — контроль импорта и экспорта маршрутов между AS, а также контроль обмена маршрутами между BGP и другими протоколами внутри AS.
Выбор лучшего пути — определение лучшего из множества путей в данную сеть. Выбор лучшего пути выполняется процессом принятия решений BGP на основе упорядоченной процедуры, принимающей во внимание множество разных аспектов. В конечном счете выбор лучшего пути в BGP сводится к выбору предпочтительной точки выхода из AS в направлении сети адресата. На процесс выбора пути BGP может оказывать влияние воздействие на атрибуты, связанные с процессом принятия решений BGP. К таким атрибутам относятся NEXT-HOP, WEIGHT (фирменный атрибут Cisco, реализованный еще рядом производителей), LOCAL-PREFERENCE, AS-PATH, ROUTE-ORIGIN, MULTI-EXIT-DESCRIMINATOR (MED), IGP METRIC и др.

С помощью route-map обеспечивается гибкий в реализации комплекс правил BGP, основанных на заданных в конфигурации логических условиях. В частности route-map можно применять для контроля правил импорта и экспорта на входящих и исходящих маршрутах, правил обмена маршрутами между BGP и другими протоколами, а также для воздействия на процесс выбора лучшего пути за счет воздействия на связанные с процессом принятия решений BGP атрибутами. С помощью route-map, атрибутов BGP, списков доступа (access-list) и атрибутов Community можно создавать сложные логические выражения для различных типов правил.

При рассмотрении возможных стратегий междоменного построения трафика с BGP следует принимать во внимание, что точка выхода исходящего трафика может быть выбрана, тогда как точка входа внешнего трафика, получаемая от партнера по EBGP, обычно не может быть изменена без специальных действий, выполняемых вместе с этим партнером. Следовательно, каждой сети для реализации стратегии TE нужно обеспечить эффективную доставку трафика, исходящего от заказчика, в одну из точек соединения с партнером. Политики TE чаще всего основаны на стратегии поиска «ближайшего выхода», когда междоменный трафик направляется ближайшему внешнему партнеру в направлении целевой автономной системы. Большинство методов изменения точки входа трафика из сети партнера EBGP (несогласованные с партнером анонсы, добавление AS, передача MED) либо не эффективны, либо не приемлемы для партнерского сообщества.

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

Организация междоменного трафика в современной архитектуре Internet более сложна по сравнению с TE внутри домена. Причины этого являются и техническими и административными. Технический аспект связан с тем, что информация о топологии и состоянии каналов, полезная для более эффективного отображения трафика, не передается по протоколу BGP из одного домена в другой по причинам, связанным со стабильностью и масштабируемостью. В общем случае решение, которое хорошо работает в одном домене, может оказаться не подходящим для другого домена. Кроме того, обычно для любого домена не желательно влияние других доменов на организацию и маршрутизацию его внутреннего трафика.

Туннели MPLS TE (явные LSP) могут повышать уровень гибкости при выборе точек выхода для междоменной маршрутизации. Для этих целей могут применяться концепции абсолютной и относительной метрики. Идея заключается в том, что если определить атрибуты BGP таким образом, чтобы процесс принятия решения для выбора точки выхода междоменного трафика зависел от метрики IGP, то для некого междоменного трафика, направленного в данную партнерскую сеть, может быть сделана предпочтительной конкретная точка выхода путем организации туннеля TE между делающим выбор маршрутизатором и партнерской точкой с присвоением туннелю TE метрики, которая будет меньше «стоимости» IGP для других точек соединения с партнерами. Если партнер принимает и обрабатывает атрибуты MED, можно использовать подобную схему на основе туннели MPLS TE, когда та или иная точка выхода делается более предпочтительной путем установки для MED «стоимости» IGP, которая изменяется туннельной метрикой.

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

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

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

8.0 Обзор применения TE в сетях IP

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

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

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

Оптимизация производительности рабочей сети обычно представляет собой непрерывный процесс, в котором статистика трафика, параметры производительности, индикация неполадок постоянно собираются в сети. Собранные эмпирические данные анализируются и используются различными механизмами организации трафика. Инструменты анализа могут использоваться и в процессах TE, позволяя рассматривать различные варианты до изменения конфигурации работающей сети.

Традиционно внутридоменная организация трафика с IGP выполняется путем увеличения значений метрики OSPF или IS-IS для перегруженных каналов, пока трафик не будет в достаточно степени переведен на другие каналы. Этой модели присущи некоторые ограничения, описанные в параграфе 6.2. Недавно были предложены некоторые другие модели и инструменты организации внутридоменного трафика [RR94][FT00][FT01][WANG]. Эти модели и средства принимают на входе матрицу трафика, топологию и задачи увеличения производительности сети, а на выходе дают значения метрики для каналов, которые могут сопровождаться некими неравноценными отношениями для маршрутизаторов в отдельных ECMP. Эти новые модели открывают новые возможности для более систематизированной организации трафика внутри доменов с IGP.

Модель с перекрытием (IP over ATM или IP over Frame relay) является другим распространенным практическим вариантом [AWD2]. Методы IP over ATM уже не представляются предпочтительными по причине недавних успехов MPLS и расширения возможностей маршрутизирующего оборудования.

Развертывание MPLS для приложений организации трафика началось в сетях некоторых сервис-провайдеров. Одним из работающих вариантов является использование MPLS вместе с IGP (IS-IS-TE или OSPF-TE) с поддержкой расширений для организации трафика совместно с маршрутизацией на базе ограничений для явного расчета маршрутов и сигнальными протоколами (например, RSVP-TE или CRLDP) для организации LSP.

В современном контексте организации трафика MPLS сетевые администраторы могут задать и настроить атрибуты каналов и ресурсные ограничения типа максимальной резервируемой пропускной способности или атрибутов класса ресурсов для каналов (интерфейсов) в домене MPLS. Протокол на базе состояний каналов с поддержкой расширений TE (IS-IS-TE или OSPF-TE) будет служить для распространения информации о топологии сети а атрибутах каналов всем маршрутизаторам в области маршрутизации. Сетевые администраторы также указывают все LSP, которые начинаются на каждом маршрутизаторе. Для каждого LSP администраторы указывают целевой узел и атрибуты LSP, которые показывают требования, проверяемые при выборе пути. После этого каждый маршрутизатор будет использовать локальный процесс маршрутизации на основе ограничений при расчете явных путей для всех начинающихся на нем LSP. Далее используется сигнальный протокол для организации LSP. За счет выделения соответствующей пропускной способности для каналов и LSP обычно удается предотвратить или ослабить перегрузки, вызываемые неравномерным распределением трафика.

Используемые для организации трафика атрибуты пропускной способности LSP могут периодически меняться. Базовый подход заключается в том, что выделенная для LSP пропускная способность должна как-то соотноситься с потребностями в пропускной способности для трафика, который реально передается через этот LSP. Атрибут трафика для LSP может изменяться с учетом роста трафика и постоянных его смен. Если в результате какой-то неожиданности в сети возникает перегрузка, имеющиеся LSP можно перемаршрутизировать для облегчения ситуации или администратор может организовать новые LSP для переноса части трафика в эти пути. Резервируемая пропускная способность на перегруженных каналах также может быть уменьшена для форсирования перемаршрутизации некоторых LSP.

В домене MPLS матрицу трафика можно оценить по результатам мониторинга трафика в LSP. Такая статистика может использоваться с разными целями, включая планирование и оптимизацию сети. Текущий опыт показывает, что развернутые сети MPLS из сотен маршрутизаторов и тысяч LSP вполне реальны. Отметим в заключение, что опыт развертывания показывает высокую эффективность модели MPLS при организации трафика в сетях IP [XIAO].

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

Междоменная TE с BGP обычно начинается с размещения множества точек соединения с внешними партнерами в местах с высокой плотностью партнеров, находящихся вблизи точек генерации/потребления трафика в собственной сети, а также обеспечивающих невысокую стоимость размещения. В каждом регионе планеты обычно имеется несколько точек обмена трафиком, где организуются соединения между крупнейшими сетями региона. Некоторые проблемы выбора места, связанные с междоменной маршрутизацией, рассмотрены в [AWD5].

После того, как места соединений определены и нужные для этого устройства развернуты, принимается решение как лучше обрабатывать получаемые от партнера маршруты и как отправлять этому партнеру маршруты из своих сетей. Одним из способов организации исходящего трафика для сети с множеством партнеров EBGP является построение иерархии партнеров. Как правило, для всех партнеров устанавливается одно значение Local Preference и для пересылки трафика будут выбираться кратчайшие пути AS. Затем, путем замены входной метрики MED⁴⁵ метрикой BGP для маршрутов от разных партнеров, формируется иерархия. Например, для всех партнеров устанавливается Local Preference = 200, предпочтительным внутренним (private) партнерам присваивается метрика BGP 50, остальным внутренним партнерам — метрика BGP 100, а внешним (public) — метрика BGP 600. В качестве «предпочтительных» можно выбрать партнеров, имеющих достаточную емкость, чья база пользователей больше по сравнению с другими, соединения с которыми дешевле или для которых проще увеличить имеющуюся емкость. В сетях с невысокой загрузкой на периметре это работает достаточно хорошо. Эту же концепцию можно использовать для сетей с высокой загрузкой периметра, создав дополнительные уровни градации метрики BGP для более тонкого выбора точек выхода трафика в партнерские сети, с которыми имеется два соединения.

Если изменения ограничиваются заменой входной метрики MED на метрику BGP, изменяются лишь точки выхода для маршрутов с одинаковой длиной AS-Path (процесс принятия решений BGP рассматривает сначала Local Preference, затем длину AS-Path и только потом метрику BGP). Рассмотрим в качестве примера сеть с двумя точками выхода — A и B. Через каждого из партнеров проходит по 40% маршрутов Internet, а остальные 20% связаны с маршрутами пользователей, имеющих двойное подключение к A и B. Предположим, что для обоих партнеров установлено Local Preference = 200 и метрика BGP 100. Если канал к партнеру A окажется перегруженным, увеличение для него метрики BGP при сохранении Local Preference = 200 обеспечит для 20% общего числа маршрутов предпочтительное использование точки выхода через партнера B. Описанный выше вариант будет применяться в ситуациях, когда все точки выхода к данному партнеру перегружены и трафик нужно целиком отвести от данного партнера.

Когда перегружена только одна из множества имеющихся точек выхода к данному партнеру, нет необходимости полностью уводить трафик от этого партнера — достаточно лишь отвести его с перегруженного устройства. Это можно реализовать с помощью пассивных метрик IGP, фильтрации AS-path или фильтрации префиксов.

Время от времени могут требоваться более радикальные изменения — например при наличии «проблемного партнера», с которым трудно проводить обновления или связность с его сетью стоит слишком дорого. В таких случаях значение Local Preference для этого партнера можно уменьшить по сравнению с предпочтениями для других партнеров. Это будет эффективно снижать уровень трафика, передаваемого данному партнеру (наличие транзитных партнеров не рассматривается). Такие изменения будут влиять на большой объем трафика и к ним следует обращаться лишь в тех случаях, когда другие методы не дали желаемого результата.

Хотя это не вызывает проблем в региональных сетях, распространение партнерских маршрутов через сеть следует принимать во внимание, когда сеть участвует в партнерских отношениях глобального характера. Иногда в этом контексте на выбор политики BGP могут оказывать влияние деловые аспекты. Например, с точки зрения бизнеса может оказаться неосторожностью работа в глобальной сети и предоставление доступа к глобальной базе клиентов для небольшой сети из отдельной страны. Однако в целях обеспечения своим клиентам качественного сервиса в отдельном регионе хорошая связность может стать необходимостью и для небольших региональных (национальных) сетей. Это может быть достигнуто за счет создания групп (community) по периметру сети и распространения маршрутов с тегами нужных групп через глобальную сеть. Маршруты от локальных партнеров не будут распространяться в глобальную сеть, тогда как маршрутам от более крупных партнеров может быть разрешено свободное распространение через всю глобальную сеть. Путем реализации гибкой стратегии для групп (community) могут быть реализованы преимущества использования одного глобального номера АС (ASN⁴⁶) при сохранении преимуществ действующих региональных сетей. Другим вариантом может служить использование разных ASN в разных регионах в результате чего будет увеличиваться длина AS path для маршрутов, анонсируемых этим сервис-провайдером.

9.0 Заключение

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

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

Этот документ не порождает новых вопросов, связанных с безопасностью.

11.0 Благодарности

Авторы благодарят Jim Boyle за предложения в раздел рекомендаций, Francois Le Faucheur за предложения по аспектам Diffserv, Blaine Christian за предложения по измерениям, Gerald Ash за предложения по маршрутизации в телефонных сетях и текст о методах TE на основе событий, Steven Wright за предложения по управляемости сетей и Jonathan Aufderheide за предложения по TE между доменами с использованием BGP. Отдельная благодарность Randy Bush за предложения по классификации TE с учетом тактических и стратегических методов. Параграф «Обзор действий ITU по части организации трафика» был подготовлен на основе материала Waisum Lai. Полезные отклики и ссылки на связанные материалы были получены от J. Noel Chiappa. На финальном этапе работы были получены дополнительные комментарии от Glenn Grotefeld. В заключение авторы хотят поблагодарить Ed Kern, сопредседателя TEWG за поддержку и комментарии.

12.0 Литература

[ASH2] J. Ash, Dynamic Routing in Telecommunications Networks, McGraw Hill, 1998.

[ASH3] Ash, J., «TE & QoS Methods for IP-, ATM-, & TDM-Based Networks», Work in Progress, March 2001.

[AWD1] D. Awduche and Y. Rekhter, «Multiprocotol Lambda Switching: Combining MPLS Traffic Engineering Control with Optical Crossconnects», IEEE Communications Magazine, March 2001.

[AWD2] D. Awduche, «MPLS and Traffic Engineering in IP Networks», IEEE Communications Magazine, Dec. 1999.

[AWD5] D. Awduche et al, «An Approach to Optimal Peering Between Autonomous Systems in the Internet», International Conference on Computer Communications and Networks (ICCCN’98), Oct. 1998.

[CRUZ] R. L. Cruz, «A Calculus for Network Delay, Part II: Network Analysis», IEEE Transactions on Information Theory, vol. 37, pp. 132-141, 1991.

[DIFF-TE] Le Faucheur, F., Nadeau, T., Tatham, M., Telkamp, T., Cooper, D., Boyle, J., Lai, W., Fang, L., Ash, J., Hicks, P., Chui, A., Townsend, W. and D. Skalecki, «Requirements for support of Diff-Serv-aware MPLS Traffic Engineering», Work in Progress⁴⁷, May 2001.

[ELW95] A. Elwalid, D. Mitra and R.H. Wentworth, «A New Approach for Allocating Buffers and Bandwidth to Heterogeneous, Regulated Traffic in an ATM Node», IEEE IEEE Journal on Selected Areas in Communications, 13:6, pp. 1115-1127, Aug. 1995.

[FGLR] A. Feldmann, A. Greenberg, C. Lund, N. Reingold, and J. Rexford, «NetScope: Traffic Engineering for IP Networks», IEEE Network Magazine, 2000.

[FLJA93] S. Floyd and V. Jacobson, «Random Early Detection Gateways for Congestion Avoidance», IEEE/ACM Transactions on Networking, Vol. 1 Nov. 4., p. 387-413, Aug. 1993.

[FLOY94] S. Floyd, «TCP and Explicit Congestion Notification», ACM Computer Communication Review, V. 24, No. 5, p. 10-23, Oct. 1994.

[FT00] B. Fortz and M. Thorup, «Internet Traffic Engineering by Optimizing OSPF Weights», IEEE INFOCOM 2000, Mar. 2000.

[FT01] B. Fortz and M. Thorup, «Optimizing OSPF/IS-IS Weights in a Changing World», www.research.att.com/~mthorup/PAPERS/papers.html.

[HUSS87] B.R. Hurley, C.J.R. Seidl and W.F. Sewel, «A Survey of Dynamic Routing Methods for Circuit-Switched Traffic», IEEE Communication Magazine, Sep. 1987.

[ITU-E600] ITU-T Recommendation E.600, «Terms and Definitions of Traffic Engineering», Mar. 1993.

[ITU-E701] ITU-T Recommendation E.701, «Reference Connections for Traffic Engineering», Oct. 1993.

[ITU-E801] ITU-T Recommendation E.801, «Framework for Service Quality Agreement», Oct. 1996.

[JAM] Jamoussi, B., Editior, Andersson, L., Collon, R. and R. Dantu, «Constraint-Based LSP Setup using LDP», RFC 3212, January 2002.

[KATZ] Katz, D., Yeung, D. and K. Kompella, «Traffic Engineering Extensions to OSPF», Work in Progress⁴⁸, February 2001.

[LNO96] T. Lakshman, A. Neidhardt, and T. Ott, «The Drop from Front Strategy in TCP over ATM and its Interworking with other Control Features», Proc. INFOCOM’96, p. 1242-1250, 1996.

[MA] Q. Ma, «Quality of Service Routing in Integrated Services Networks», PhD Dissertation, CMU-CS-98-138, CMU, 1998.

[MATE] A. Elwalid, C. Jin, S. Low, and I. Widjaja, «MATE: MPLS Adaptive Traffic Engineering», Proc. INFOCOM’01, Apr. 2001.

[MCQ80] J.M. McQuillan, I. Richer, and E.C. Rosen, «The New Routing Algorithm for the ARPANET», IEEE. Trans. On Communications, vol. 28, no. 5, pp. 711-719, May 1980.

[MR99] D. Mitra and K.G. Ramakrishnan, «A Case Study of Multiservice, Multipriority Traffic Engineering Design for Data Networks», Proc. Globecom’99, Dec 1999.

[RFC-1458] Braudes, R. and S. Zabele, «Requirements for Multicast Protocols», RFC 1458, May 1993.

[RFC-1771] Rekhter, Y. and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771⁴⁹, March 1995.

[RFC-1812] Baker, F., «Requirements for IP Version 4 Routers», STD 4, RFC 1812, June 1995.

[RFC-1992] Castineyra, I., Chiappa, N. and M. Steenstrup, «The Nimrod Routing Architecture», RFC 1992, August 1996.

[RFC-1997] Chandra, R., Traina, P. and T. Li, «BGP Community Attributes», RFC 1997, August 1996.

[RFC-1998] Chen, E. and T. Bates, «An Application of the BGP Community Attribute in Multi-home Routing», RFC 1998, August 1996.

[RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, «Resource Reservation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, September 1997.

[RFC-2211] Wroclawski, J., «Specification of the Controlled-Load Network Element Service», RFC 2211, September 1997.

[RFC-2212] Shenker, S., Partridge, C. and R. Guerin, «Specification of Guaranteed Quality of Service», RFC 2212, September 1997.

[RFC-2215] Shenker, S. and J. Wroclawski, «General Characterization Parameters for Integrated Service Network Elements», RFC 2215, September 1997.

[RFC-2216] Shenker, S. and J. Wroclawski, «Network Element Service Specification Template», RFC 2216, September 1997.

[RFC-2328] Moy, J., «OSPF Version 2», STD 54, RFC 2328, July 1997.

[RFC-2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, May 1998.

[RFC-2386] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, «A Framework for QoS-based Routing in the Internet», RFC 2386, August 1998.

[RFC-2474] Nichols, K., Blake, S., Baker, F. and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[RFC-2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, December 1998.

[RFC-2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, «Assured Forwarding PHB Group», RFC 2597, June 1999.

[RFC-2678] Mahdavi, J. and V. Paxson, «IPPM Metrics for Measuring Connectivity», RFC 2678, September 1999.

[RFC-2679] Almes, G., Kalidindi, S. and M. Zekauskas, «A One-way Delay Metric for IPPM», RFC 2679, September 1999.

[RFC-2680] Almes, G., Kalidindi, S. and M. Zekauskas, «A One-way Packet Loss Metric for IPPM», RFC 2680, September 1999.

[RFC-2702] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M. and J. McManus, «Requirements for Traffic Engineering over MPLS», RFC 2702, September 1999.

[RFC-2722] Brownlee, N., Mills, C. and G. Ruth, «Traffic Flow Measurement: Architecture», RFC 2722, October 1999.

[RFC-2753] Yavatkar, R., Pendarakis, D. and R. Guerin, «A Framework for Policy-based Admission Control», RFC 2753, January 2000.

[RFC-2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, «RSVP Refresh Overhead Reduction Extensions», RFC 2961, April 2000.

[RFC-2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, «A Framework for Integrated Services Operation over Diffserv Networks», RFC 2998, November 2000.

[RFC-3031] Rosen, E., Viswanathan, A. and R. Callon, «Multiprotocol Label Switching Architecture», RFC 3031, January 2001.

[RFC-3086] Nichols, K. and B. Carpenter, «Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification», RFC 3086, April 2001.

[RFC-3124] Balakrishnan, H. and S. Seshan, «The Congestion Manager», RFC 3124, June 2001.

[RFC-3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, December 2001.

[RFC-3210] Awduche, D., Hannan, A. and X. Xiao, «Applicability Statement for Extensions to RSVP for LSP-Tunnels», RFC 3210, December 2001.

[RFC-3213] Ash, J., Girish, M., Gray, E., Jamoussi, B. and G. Wright, «Applicability Statement for CR-LDP», RFC 3213, January 2002.

[RFC-3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaahanen, P., Krishnan, R., Cheval, P. and J. Heinanen, «Multi-Protocol Label Switching (MPLS) Support of Differentiated Services», RFC 3270, April 2002.

[RR94] M.A. Rodrigues and K.G. Ramakrishnan, «Optimal Routing in Shortest Path Networks», ITS’94, Rio de Janeiro, Brazil.

[SHAR] Sharma, V., Crane, B., Owens, K., Huang, C., Hellstrand, F., Weil, J., Anderson, L., Jamoussi, B., Cain, B., Civanlar, S. and A. Chui, «Framework for MPLS Based Recovery», Work in Progress.

[SLDC98] B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury, «Design Considerations for Supporting TCP with Per-flow Queueing», Proc. INFOCOM’98, p. 299-306, 1998.

[SMIT] Smit, H. and T. Li, «IS-IS extensions for Traffic Engineering», Work in Progress⁵⁰.

[WANG] Y. Wang, Z. Wang, L. Zhang, «Internet traffic engineering without full mesh overlaying», Proceedings of INFOCOM’2001, April 2001.

[XIAO] X. Xiao, A. Hannan, B. Bailey, L. Ni, «Traffic Engineering with MPLS in the Internet», IEEE Network magazine, Mar. 2000.

[YARE95] C. Yang and A. Reddy, «A Taxonomy for Congestion Control Algorithms in Packet Switching Networks», IEEE Network Magazine, p. 34-45, 1995.

13.0 Адреса авторов

Daniel O. Awduche

Movaz Networks

7926 Jones Branch Drive, Suite 615

McLean, VA 22102

Phone: 703-298-5291

EMail: awduche@movaz.com

Angela Chiu

Celion Networks

1 Sheila Dr., Suite 2

Tinton Falls, NJ 07724

Phone: 732-747-9987

EMail: angela.chiu@celion.com

Anwar Elwalid

Lucent Technologies

Murray Hill, NJ 07974

Phone: 908 582-7589

EMail: anwar@lucent.com

Indra Widjaja

Bell Labs, Lucent Technologies

600 Mountain Avenue

Murray Hill, NJ 07974

Phone: 908 582-0435

EMail: iwidjaja@research.bell-labs.com

XiPeng Xiao

Redback Networks

300 Holger Way

San Jose, CA 95134

Phone: 408-750-5217

EMail: xipeng@redback.com

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

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

nmalykh@protokols.ru

14.0 Полное заявление авторских прав

Подтверждение

Финансирование функций RFC Editor обеспечивается Internet Society.

1Multi-protocol Lambda Switching.

2Configuration Management.

3Explicitly routed label switched path – явно маршрутизируемые пути с коммутацией по меткам.

4Random Early Detection — произвольное раннее обнаружение.

5Explicit congestion notification.

6RED with In and Out .

7Tail-Drop — «обрубание хвостов».

8Longest Queue Drop — отбрасывание длиннейшей очереди.

9Dynamic Soft Partitioning with Random Drop — мягкое динамическое деление с произвольным отбрасыванием.

10State-dependent routing – маршрутизация в зависимости от состояния.

11Event dependent routing — маршрутизация, определяемая событиями.

12Dynamic alternate routing – динамическое чередование маршрутов.

13State-and-time dependent routing — маршрутизация в зависимости от состояния и времени.

14Success-to-the-top.

15Dynamic non-hierarchical routing.

16Type-of-Service.

17Equal Cost Multi-Path — множество равноценных путей.

18Shortest Path First — сначала кратчайший путь.

19Resource Reservation Protocol — протокол резервирования ресурсов.

20One pass with advertising.

21Differentiated Services — дифференцированные услуги.

22Per-Hop Behavior — поведение на этапах пересылки.

23Internet Service Provider — поставщик услуг доступа в Internet.

24Service Level Agreement — соглашение об уровне обслуживания.

25Traffic Conditioning Agreement — соглашение о кондиционировании трафика.

26Per Domain Behavior — поведение на уровне домена.

27Label switching router — маршрутизатор с коммутацией по меткам.

28Forwarding equivalence clas

29Class-of-Service.

30Next hop label forwarding entry — запись для следующего интервала пересылки по меткам.

31Label Switched Path — путь с коммутацией по меткам.

32IP Performance Metrics — метрики производительности IP.

33Real Time Flow Measurement — измерение трафика в реальном масштабе времени.

34Grade of Service.

35Available-link-bandwidth — доступная полоса канала.

36Success-to-the-top — успех прежде всего.

37Autonomous system.

38Shortest path first — сначала кратчайший путь.

39Equal-Cost Multi-Path.

40Automatic Protection Switching — автоматическое защитное переключение.

41Differentiated Services.

42Class of service.

43Per-hop behavior — модель поведения на этапе (пересылки).

44Autonomous System.

45Multi-exit-discriminator metric — метрика выбора из множества выходов или метрика BGP. В документе используются оба термина.

46AS Number.

47Работа завершена и опубликована в RFC 3564. Прим. перев.

48Работа завершена и опубликована в RFC 3630. Прим. перев.

49Документ признан устаревшим и заменен RFC 4271. Прим. перев.

50Работа завершена и опубликована в RFC 3784. Прим. перев.

Рубрика: RFC, Измерения и тестирование | Комментарии отключены

RFC 3286 An Introduction to the Stream Control Transmission Protocol (SCTP)

Опубликовано 12.05.2002 автором Nikolai Malykh

Network Working Group                                         L. Ong
Request for Comments: 3286                         Ciena Corporation
Category: Informational                                    J. Yoakum
                                                     Nortel Networks
                                                            May 2002

Введение в SCTP

An Introduction to the Stream Control Transmission Protocol (SCTP)

PDF

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

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

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

Аннотация

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

1. Введение

SCTP представляет собой новый транспортный протокол для сетей IP, работающий на одном уровне с протоколами UDP² и TCP³ и обеспечивающий транспортные функции для различных приложений Internet. Протокол SCTP был одобрен IETF в качестве предварительного стандарта⁴ [1]. После выхода предварительного стандарта был обновлен алгоритм контроля ошибок [2]. Новые изменения протокола будут отражаться в поддерживаемом IETF списке RFC.

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

В отличие от TCP протокол SCTP обеспечивает множество функций, которые имеют важное значение для организации телефонной связи и в то же время могут обеспечивать ряд преимуществ для других приложений, которым требуется транспорт с высоким уровнем производительности и надежности. Первоначальное назначение протокола SCTP описано в работе [3].

2. Основные функции SCTP

SCTP представляет собой unicast-протокол⁶, который обеспечивает обмен данными между двумя конечными точками. Отметим, что каждая из этих точек может быть представлена более чем 1 адресом IP.

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

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

Скорость передачи по протоколу SCTP может адаптироваться подобно тому, как это происходит в TCP, – в зависимости от загрузки сети. Протокол SCTP может использоваться одновременно с TCP на общих каналах передачи данных.

3. Поддержка множества потоков в SCTP

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

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

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

Другим примером является возможность использования множества потоков для доставки multimedia-документов (например, web-страниц) в рамках одной сессии. Поскольку такие документы состоят из разнотипных объектов разных размеров, многопотоковая доставка таких компонент не требует строгой упорядоченности. Однако использование множества потоков при доставке существенно повышает для потребителей привлекательность сервиса.

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

Протокол SCTP поддерживает многопотоковую передачу за счет устранения зависимости между передачей и доставкой данных. В частности, каждый блок⁸ полезной информации типа DATA (данные) использует два набора порядковых номеров. Номер TSN⁹ управляет передачей сообщений и детектированием их потери, а пара “идентификатор потока Stream ID – номер SSN¹⁰” используется для управления порядком доставки потребителю полученных данных.

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

4. Поддержка многодомных хостов в SCTP

Другим важным качеством SCTP является поддержка многодомных хостов, позволяющая создавать конечные точки SCTP с множеством IP-адресов. Поддержка многодомных хостов повышает уровень “живучести” сессий в случаях возникновения сбоев в сети. В традиционных однодомных сеансах отказ в соединении с ЛВС может изолировать конечную точку, а сбой в работе магистральной сети может привести к временным проблемам на транспортном уровне, пока протокол маршрутизации IP не найдет пути в обход сбойного участка. При использовании многодомных узлов SCTP могут быть организованы резервные (избыточные) соединения с ЛВС и поддерживаются различные варианты преодоления сложностей, связанных с отказами в магистральных сетях. Использование адресов с различными префиксами может обеспечить автоматическую маршрутизацию пакетов к другому оператору. Можно использовать методы route-pinning или даже резервировать соединения с магистральными сетями, если обеспечивается контроль над сетевой архитектурой и протоколами.

Действующий вариант SCTP не поддерживает распределения нагрузки (load sharing), поэтому многодомные хосты обеспечивают лишь избыточность соединений для повышения уровня надежности. Один из адресов многодомного хоста указывается в качестве основного (primary) и используется как адрес получателя для всех блоков DATA при нормальной передаче. При передаче повторных блоков DATA используется один из дополнительных адресов с целью повышения вероятности доставки в конечную точку. При повторяющихся неоднократно повторах передачи принимается решение об отправке всех блоков DATA с использованием альтернативного адреса, пока системе мониторинга не удастся увидеть доступность основного адреса.

Для поддержки множества интерфейсов конечные точки SCTP обмениваются списками своих адресов в процессе создания ассоциации. Каждая из конечных точек должна быть способна принимать сообщения с любого адреса, связанного с удаленным партнером; на практике некоторые ОС могут использовать в пакетах циклический перебор адресов отправителя и в таких случаях прием пакетов с различных адресов является нормальной ситуацией. Для всего списка адресов конечной точки в данной сессии используется один номер порта.

Для повышения уровня безопасности требуется, чтобы некоторые отклики передавались по адресу, указанному в поле отправителя сообщения, вызвавшего отклик. Например, когда сервер получает блок INIT от клиента для инициирования SCTP-ассоциации, сервер всегда будет передавать блок INIT ACK по адресу отправителя в заголовке IP блока INIT.

5. Процедура создания ассоциаций SCTP

Процедура создания ассоциаций SCTP¹¹ состоит из 4 последовательных сообщений. Два последних сообщения стартовой последовательности могут включать блок DATA, поскольку эти сообщения передаются после того, как проверена корректность ассоциации. Для предотвращения некоторых типов атак на службы в стартовую последовательность встроен механизм cookie.

5.1 Механизм Cookie

Механизм cookie обеспечивает защиту от атак вслепую, когда атакующий генерирует множество блоков INIT с целью перегрузки сервера SCTP за счет расхода памяти и иных ресурсов, требуемых для обработки новых запросов INIT. Взамен выделения памяти для TCB¹² сервер создает параметр Cookie с информацией TCB, корректным временем жизни и сигнатурой для аутентификации. Этот параметр передается клиенту в сообщении INIT ACK. Поскольку сообщения INIT ACK всегда возвращаются по адресу отправителя запросов INIT, атакующий вслепую не будет получать Cookie. Легитимный клиент SCTP получит Cookie и вернет серверу блок COOKIE ECHO, по которому сервер SCTP может проверить корректность Cookie и использовать это значение для создания TCB. Поскольку параметр Cookie создается сервером и на сервере же проверяется, формат и секретный ключ Cookie знает только сервер и не возникает необходимости в передаче их через сеть клиенту.

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

5.2 INIT Collision Resolution

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

6. Функции обмена данными в SCTP

За обменом блоками DATA в SCTP следует процедура, подобная TCP ACK. Получение блока DATA подтверждается передачей блока SACK, который показывает не только диапазон принятых TSN¹³, но и некумулятивные номера TSN, указывающие пропуски в принятой последовательности TSN. Как и в процедурах TCP подтверждения SACK передаются с использованием метода delayed ack (обычно одно сообщение SACK на каждый полученный пакет с ограничением задержки между передачей сообщений SACK и увеличением задержки на 1 при получении каждого пакета с обнаруженным пропуском).

Алгоритмы управления трафиком и предотвращения насыщения¹⁴ соответствуют аналогичным алгоритмам TCP. Анонсируемый размер окна показывает емкость буфера на приемной стороне, а поддерживаемое для пути окно насыщения позволяет управлять пакетами “на лету”. Алгоритмы Congestion avoidance, Fast recovery и Fast retransmit¹⁵ встроены в протокольные процедуры в соответствии с RFC 2581. Единственным отличием является то, что конечные точки должны обеспечивать преобразование между количеством принятых/переданных байтов и номерами TSN, поскольку нумерация TSN осуществляется для транка в целом.

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

7. Завершение работы ассоциаций SCTP

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

Отметим, что протокол SCTP не поддерживает «полуоткрытых» соединений, которые могут возникать в TCP, когда одна сторона показывает другой отсутствие данных для передачи, а вторая сторона может неограниченно долго продолжать передачу данных. Протокол SCTP предполагает, что после начала процедуры shutdown обе стороны прекращают передачу новых данных через ассоциацию и требуется лишь обмен пакетами, подтверждающими прием отправленных ранее данных.

8. Формат сообщений SCTP

Сообщения SCTP включают общий заголовок, за которым следует один или несколько блоков (chunk), которые могут содержать данные или управляющую информацию. В заголовке указываются номера портов отправителя и получателя, что позволяет мультиплексировать различные ассоциации SCTP на одном адресе. 32-битовый тег верификации предотвращает возможность включения в ассоциацию SCTP устаревших или фальсифицированных сообщений, а 32-битовая контрольная сумма, рассчитанная на основе полиномиального алгоритма CRC-32c [2] служит для детектирования ошибок.

Каждый блок содержит поля типа, флагов, размера, а также значение. Управляющие блоки включают различные параметры и флаги, зависящие от типа блока. Блоки данных (DATA) включают флаг управления сегментацией и сборкой, а также параметры TSN, Stream ID, Stream Sequence Number и Payload Protocol Identifier.

Параметр Payload Protocol ID включен для обеспечения возможности расширения в новых версиях протокола. Если предположить, что функции идентификации протокола и мультиплексирования по портам в будущем перестанут играть столь важную роль, как сейчас, Payload Protocol ID будет обеспечивать идентификацию протоколов, передаваемых с помощью SCTP без использования номера порта.

Формат сообщений SCTP обеспечивает механизм связывания множества блоков данных и управления в одно сообщение для повышения эффективности транспорта. Использованием такой группировки (bundling) управляет приложение, поэтому группировка стартовой передачи невозможна. Связывание естественным образом осуществляется при повторе передачи блоков DATA в целях снижения вероятности насыщения.

9. Обработка ошибок

9.1 Повтор передачи

Повторная передача блоков DATA может быть обусловлена (a) тайм-аутом, определяемым таймером повтора (retransmission timer) или (b) получением SACK, показывающих что блок DATA не был получен адресатом. Для снижения вероятности насыщения повтор передачи блоков DATA ограничивается. Значение тайм-аута для повтора (RTO) устанавливается на основе оценки времени кругового обхода и уменьшается экспоненциально с ростом частоты потери сообщений.

Для активных ассоциаций с почти постоянным уровнем трафика DATA причиной повтора скорей всего будут сообщения SACK, а не тайм-аут. Для снижения вероятности ненужных повторов используется правило 4 SACK, в соответствии с которым повтор передачи происходит только по четвертому SACK, указывающему на пропуск блока данных. Это позволяет предотвратить повторы передачи, вызванные нарушением порядка доставки.

9.2 Сбой в пути

Поддерживается счетчик для числа повторов передачи по конкретному адресу получателя без подтверждения успешной доставки. Когда значение этого счетчика достигает заданного порога (конфигурационный параметр), адрес объявляется неактивным и протокол SCTP начинает использовать другой адрес для передачи блоков DATA.

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

Блоки Heartbeat передаются по неактивным адресам до тех пор, пока не будет получено сообщение Ack, говорящее о восстановлении активности адреса. Частота передачи блоков Heartbeat определяется значение RTO и дополнительной задержкой, которая позволяет передавать блоки Heartbeat без помех для пользовательского трафика.

9.3 Отказ в конечной точке

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

10. Интерфейс API

Спецификация протокола включает модель примитивов, используемых при обмене информацией между приложениями и уровнем SCTP. Эта модель является скорее информационным материалом, нежели формальной спецификацией API. Для упрощения переноса приложений TCP или UDP на протокол SCTP в спецификации определен интерфейс API на базе сокетов.

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

В дополнение к тегам верификации и механизму cookie протокол SCTP поддерживает интеграцию с механизмами шифрования и обеспечения целостности IPSec. Спецификация SCTP не определяет новых протоколов или процедур обеспечения безопасности.

Рассматриваются вопросы расширения IPSec для поддержки многодомных хостов. Ведутся работы по использованию TLS¹⁶ на основе протокола SCTP [4].

12. Расширения

Формат SCTP позволяет определять новые типы блоков (chunk), поля флагов и параметров для расширения возможностей протокола. Любое расширение должно базироваться на стандартном соглашении с IETF, следовательно фирменные расширения не поддерживаются протоколом.

Значения Chunk Type разбиты на 4 группы, чтобы позволить расширениям использовать предопределенные процедуры для откликов на нераспознанные типы блоков. Варианты откликов включают: отбрасывание пакета целиком, игнорирование блока, а также игнорирование с передачей отчета. Аналогичные предопределенные отклики поддерживаются и для неопознанных значений Parameter Type.

Значения Chunk Parameter Type используют независимые диапазоны для каждого Chunk Type. На практике значения, определенные в спецификации SCTP, скоординированы таким образом, что конкретный параметр будет использовать одинаковые

значения Chunk Parameter Type для всех Chunk Type. Необходимость такого выбора подтвердит практика использования протокола.

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

[1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, «Stream Control Transmission Protocol», RFC 2960, October 2000.

[2] Stewart, Sharp, et. al., «SCTP Checksum Change», Work in Progress¹⁸.

[3] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, «Framework Architecture for Signaling Transport», RFC 2719, October 1999.

[4] Jungmeier, Rescorla and Tuexen, «TLS Over SCTP», Work in Progress¹⁹.

14. Адреса авторов

Lyndon Ong

Ciena Corporation

10480 Ridgeview Drive

Cupertino, CA 95014

EMail: lyong@ciena.com

John Yoakum

Emerging Opportunities

Nortel Networks

EMail: yoakum@nortelnetworks.com

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

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

nmalykh@protokols.ru

15. Полное заявление авторских прав

Подтверждение

Финансирование функций RFC Editor в настоящее время обеспечивается Internet Society.

1Stream Control Transmission Protocol – протокол управления потоковой передачей.

2User Datagram Protocol – протокол пользовательских дейтаграмм.

3Transmission Control Protocol – протокол управления передачей.

4Proposed Standard – предложенных стандарт

5Прямой связи. Прим. перев.

6Т. е., протокол, не поддерживающий групповой адресации. Прим. перев.

7В английском языке для соединений SCTP используется термин association (ассоциация, связь). Прим. перев.

8В английском языке используется термин chunk. Прим. перев.

9Transmission Sequence Number – порядковый номер при передаче.

10Stream Sequence Number – порядковый номер потока.

11SCTP Initiation Procedure

12Transmission Control Block — блок управления передачей.

13 Transmission Sequence Number — порядковый номер при передаче.

14 Flow and Congestion Control

15 Предотвращение насыщения, ускоренное восстановление и ускоренный повтор передачи, соответственно.

16Transport Layer Security – защита на транспортном уровне.

18В настоящее время эта работа завершена и опубликована в RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change. Прим. перев.

19В настоящее время эта работа завершена и опубликована в RFC 3436 Transport Layer Security over Stream Control Transmission Protocol. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 3260 New Terminology and Clarifications for Diffserv

Опубликовано 11.04.2002 автором Nikolai Malykh

Network Working Group                                    D. Grossman
Request for Comments: 3260                            Motorola, Inc.
Updates: 2474, 2475, 2597                                 April 2002
Category: Informational

Новая терминология и разъяснения для Diffserv

New Terminology and Clarifications for Diffserv

PDF

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

Этот документ содержит информацию для сообщества Internet. Документ не задает каких-либо стандартов Internet. Допускается свободное распространение документа.

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

Аннотация

В этом документе собраны соглашения рабочей группы Diffserv, касающиеся новой и переработанной терминологии, а также обеспечивающие технические разъяснения. Задачей документа является обновление RFC 2474, RFC 2475 и RFC 2597. Предполагается, что при стандартизации RFC 2474 и RFC 2597, а также при обновлении RFC 2475 в новые документы будет включено содержимое данного документа, а сам он после этого утратит силу.

1. Введение

В процессе работы группы Diffserv стало ясно, что в некоторых случаях требуется ввести или уточнить термины и определения для проектов стандартов Diffserv. Кроме того, потребовались некоторые технические разъяснения. Этот документ был создан для публикации достигнутых группой соглашений по этим вопросам и не является попыткой пересмотра базовых RFC или повторного запуска процессов стандартизации. Документ частично обновляет RFC 2474, RFC 2475 и RFC 2597. RFC 2598 был отменен в RFC 3246 и достигнутые группой соглашения включены в новый документ.

2. Терминология, связанная с SLA

Архитектура Diffserv [2] использует термин SLA¹ для обозначения сервисных контрактов, которые задают условия пересылки пакетов пользователя. SLA может включать правила классификации трафика, которые (по крайней мере, частично) задают правила «кондиционирования» трафика (TCA²). TCA представляет собой соглашение, задающее правила классификации и соответствующие профили трафика, а также применимые правила метрики, маркировки, отбрасывания и/или «формования» (shaping) трафика.

В процессе работы группы Diffserv (а также в группе Policy [6]) стало понятно, что заключение «соглашения» означает рассмотрение такие аспектов, как цены, договоренности и иные вопросы бизнеса, а также некоторых сугубо технических аспектов. В таких соглашениях могут присутствовать другие технические параметры (например, доступность услуг), которые не являются предметом рассмотрения группы Diffserv. В результате было принято решение, что термины SLA и TCA будут использоваться для представления широкого контекста, а для описания элементов обслуживания и кондиционирования трафика, связанных с Diffserv, будет использоваться новая терминология.

Спецификация уровня обслуживания (SLS³) представляет собой набор параметров и их значений, которые совместно определяют сервис, предлагаемый для потока трафика доменом DS⁴.
Спецификация кондиционирования трафика (TCS⁵) представляет собой набор параметров и их значений, которые совместно задают набор правил классификации и профиль трафика. TCS является неотъемлемой частью SLS.

Отметим, что определение потока трафика не изменилось по сравнению с RFC 2475. Поток трафика может представлять собой отдельный микропоток или группу микропотоков (в домене DS отправителя или получателя), а также может быть BA⁶. Таким образом, SLS можно применять в домене DS отправителя или получателя для одного или группы микропотоков, а также для BA в любом домене DS.

Отметим также, что определение «политики предоставления услуг» (SPP⁷) не изменилось по сравнению с RFC 2475, где SPP были определены, как «политика, определяющая настройку кондиционеров трафика на граничных узлах DS о отображения потоков трафика на агрегаты поведения DS для обеспечения спектра услуг». Согласно определению, данному в RFC 3198 [6], политика представляет собой «набор правил для администрирования, управления и контроля доступа к сетевым ресурсам». Следовательно, связи между SLS и SPP заключается в том, что последняя является (отчасти) набором правил, выражающий параметры и диапазоны значений, которые могут использоваться первой.

Отметим, что это определение задает более жесткие ограничения по сравнению с определением в RFC 3198.

3. Использование групп PHB

RFC 2475 определяет группу PHB⁸ следующим образом:

«Набор из одного или множества PHB, которые могут выполняться только совместно вследствие общих ограничений, применяемых ко всем PHB данной группы (например, управления очередями). Группа PHB является базовым элементом архитектуры, позволяющим совместно реализовать несколько связанных режимов (например, четыре профиля отбрасывания пакетов). Одиночный PHB является частным случаем группы PHB».

Одна из «стандартных» групп PHB определена в RFC 2597 [3], Assured Forwarding PHB Group. AF⁹ представляет собой вариант режима пересылки с некоторым выделенным уровнем ресурсов очередей и тремя уровнями предпочтения при отбрасывании. Группа AF PHB Group включает три PHB и использует три кода DSCP¹⁰.

RFC 2597 определяет 12 кодов DSCP, соответствующих четырем независимым классам AF — AF1x, AF2x, AF3x и AF4x (где x может принимать значения 1, 2 или 3 для задания предпочтений при отбрасывании). Каждый класс AF имеет свой экземпляр группы AF PHB.

Может возникать путаница, связанная с тем, что в RFC 2597 все 4 класса AF с тремя уровнями предпочтения в каждом отнесены к одной группе PHB. Однако, поскольку каждый класс работает независимо от других (и, следовательно, не возникает общего ограничения для классов AF, как это наблюдается для уровней предпочтения при отбрасывании в одном классе AF), такое использование не согласуется с RFC 2475. Несогласованность обусловлена историческими причинами и будет устранена в новом варианте спецификации AF. Сейчас следует просто принять, что AF является типом группы PHB, а каждый класс AF является экземпляром типа AF.

Авторам новых спецификаций PHB следует быть аккуратными и придерживаться определения группы PHB в RFC 2475. RFC 2475 не запрещает новым спецификациям PHB выделять достаточное число кодов DSCP для представления множества независимых экземпляров группы PHB. Однако такой набор кодов DSCP не должен указывать на одну группу PHB.

4. Определение поля DS

Diffserv использует шесть битов в заголовке IPV4 или IPV6 для передачи кодов DSCP, которые выбирают PHB. В RFC 2474 была предпринята попытка переименовать октет TOS¹¹ заголовка IPV4 и октет Traffic Class заголовка IPV6 в поле DS. Это поле имеет шесть битов кода DS и два неиспользуемых бита.

Отмечено, что эта попытка привела к несогласованности и неоднозначности. В частности неиспользуемые биты (CU¹²) поля DS не были выделены для Diffserv и после публикации RFC 2474 эти биты были выделены для явной индикации насыщения (ECN¹³), определенной в RFC 3168 [4]. В настоящем документе в зависимости от контекста DSCP обозначает коды, которые служат для выбора PHB или часть поля DS, которая содержит эти коды.

Данный текст также не согласуется с BCP 37 (IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers) [5]. Поле типа обслуживания IPV4 (TOS) и поле класса трафика IPV6 были заменены 6-битовым полем DS и 2-битовым полем CU. Агентство IANA выделяет значения поля DS в соответствии с разделом «Согласование с IANA» в RFC 2474, как описано в разделе 8 данного документа.

По согласованному мнению рабочей группы DiffServ говорит, что BCP 37 корректно подтверждает структуру прежних поле TOS и класса трафика.

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

поле дифференцированного обслуживания (DS) занимает 6 старших битов (бывшего) октета IPV4 TOS и (бывшего) октета IPV6 Traffic Class;
код дифференцированного обслуживания (DSCP) представляет собой значение, кодируемое в поле DS, и каждый узел DS должен использовать это значение для выбора PHB, применяемого для каждого пересылаемого пакета.

Два младших бита октетов IPV4 TOS и IPV6 Traffic Class не используются Diffserv.

При обновлении RFC 2474 следует обратить внимание на замену CU на ECN со ссылкой на RFC 3168 (или его новый вариант).

Следует также обновить упоминание BCP 37.

5. Упорядоченные агрегаты и классы планирования PHB

Работа по поддержке Diffserv в маршрутизаторах MPLS (LSR¹⁴) привела к реализации концепции, которая была нужна в Diffserv для получения представления набора BA с общими ограничениями по сохранению порядка. Это применяется к агрегатам поведения AF, поскольку узел DS может не менять порядок пакетов микропотока, если они относятся к одному классу AF. Это будет, к примеру, предотвращать в маршрутизаторах MPLS LSR, являющихся узлами DS, дискриминирование пакетов агрегата поведения AF на основе предпочтений при отбрасывании и пересылки пакетов одного класса AF с разными предпочтениями по отбрасыванию через разные LSP. Определены новые термины.

Класс планирования PHB (PHB Scheduling Class) — группа PHB, для которой общее ограничение состоит в том, что порядок должен сохраняться по крайней мере для пакетов одного микропотока.

Упорядоченный агрегат (OA¹⁵) — набор BA с общими ограничениями по сохранению порядка. Набор PHB, которые применяются к этому набору BA, определеяет класс планирования PHB.

6. Неизвестные/некорректно отображенные DSCP

Несколько разработчиков отметили неоднозначности и конфликты в Diffserv RFC, касающиеся поведения узлов DS при получении пакетов с непонятным значением DSCP.

В RFC 2475 указано:

«Входные узлы должны кондиционировать весь остальной входящий трафик для обеспечения приемлемости кодов DS; пакеты с неприемлемыми кодами должны отбрасываться или значение кода DS должно меняться на приемлемое до пересылки пакета. Например, входной узел, получая трафик от домена, для которого нет соглашения об улучшенном обслуживании, может сбрасывать код DS в значение, принятое для Default PHB [DSFIELD].»

С другой стороны, в 2474 указано:

«Пакеты, полученные с неизвестным кодом, следует пересылать, как будто они помечены для принятого по умолчанию поведения (см. раздел 4), не меняя в них кода.»

RFC 2474 имеет дело в основном с внутренними узлами DS. Однако такой режим может также применяться на внутренних узлах DS после кондиционирования трафика, требуемого RFC 2475 (в этом случае нераспознаваемые DSCP могут появляться только в следствие некорректной конфигурации). Если приходит пакет со значением DSCP, которое явно не отображается на определенный PHB, это следует трактовать, как пакет, маркированный для принятой по умолчанию обработки. Альтернативой является выделение другого PHB, что может приводить к ошибочному выделению предоставляемых ресурсов или отбрасыванию пакета. Других вариантов в схеме RFC 2474 не возникает. Ни один из этих вариантов не представляется подходящим. Рассматривался вопрос PHB, получающего обслуживание хуже принятого по умолчанию — это может оказаться лучшим вариантом.

RFC 2475 явно посвящен входным узлам DS (точнее, функциям кондиционирования трафика на входных узлах). Это другой контекст, в котором употребление термина «следует» в RFC 2474 обеспечивает гибкость, для которой группа предназначена. Столь жесткое прочтение нежелательно.

Следовательно, утверждение в RFC 2474 разъясняется, чтобы показать, что оно не предназначено для применения к функции кондиционирования на входном узле DS и сослаться для этого случая на RFC 2475.

Аналогичный вопрос возникает при декларировании себя в качестве первой инкарнации EF¹⁶. В RFC 2598 указано:

«Для защиты себя от атак на отказ служб (DoS¹⁷) периметр домена DS должен строго проверять для всех пакетов с маркировкой EF соответствие скорости согласованному со смежным восходящим доменом значению (скорость должна быть не больше значения, заданного для EF PHB). Пакеты, вызывающие превышение согласованной скорости должны отбрасываться. Если смежные домены не согласовали скорость EF, нисходящий домен должен использовать нулевое значение скорости (т. е., отбрасывать все пакеты с маркировкой EF).»

Проблема возникает при некорректной конфигурации или в связи с проблемами маршрутизации. Выходной узел DS на краю домена DS пересылает пакеты входному узлу DS на краю другого домена DS. Эти пакеты маркируются значением DSCP, которое в понимании выходного узла отображается на EF, но входной узел не распознает. Утверждение RFC 2475 представляется применимым для этого случая. В RFC 3246 [7] содержатся разъяснения этого вопроса.

7. Несовместимость с RFC 1349

По крайней мере один разработчик обратил внимание на несоответствие поля DS, определенного в RFC 2474, использованию битов TOS, описанному в RFC 1349. Применение RFC 1349 было вызвано взаимодействием с расширениями OSPF из RFC 1247. Оно не получило широкого распространения и было исключено из процесса стандартизации при публикации STD 54, RFC 2328. Обработка битов TOS описана, как требования в RFC 1812 [8], RFC 1122 [9] и RFC 1123 [10]. В RFC 2474 указано:

«Здесь не предпринимается попыток обеспечить совместимость с DTR или битами TOS октета IPv4 TOS, определенного в [RFC791].»

Кроме того, RFC 2474 отменяет действие RFC 1349 по решению IESG. Для полноты при обновлении RFC 2474 приведенный выше фрагмент следует выразить иначе:

«Здесь не предпринимается попыток обеспечить совместимость с DTR/MBZ или битами TOS октета IPv4 TOS, как определено в [RFC791] и [RFC1349]. Это означает, что обработка битов TOS, описанная в [RFC1812], [RFC1122] и [RFC1123] также отменяется этим документом. См. также [RFC2780].»

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

В агентство IANA передан запрос на разъяснение RFC 2474 в части регистрации значений DSCP, предназначенных для экспериментов и локального применения. При пересмотре RFC 2474 в раздел 6 следует добавить приведенный ниже текст:

«У агентства IANA запрашивается поддержка реестра рекомендуемых значений DSCP, распределяемых путем стандартизации. Значения EXP/LU¹⁸ не регистрируются.»

9. Список ожидаемых изменений

Ниже приведен список RFC (проекты стандартов и информационные), которые следует обновить с учетом приведенных в этом документе соображений. Изменения следует внести, когда RFC с проектами стандартов будут переводиться в статус предварительных стандартов (Draft Standard) или при ином обновлении, если документы сохранят статус предложенного стандарта (Proposed). Предполагается, что RFC 2475 будет обновлен одновременно с RFC 2474. Внесение изменений приведет к утрате силы настоящим документом¹⁹.

RFC 2474 — пересмотр определения поля DS. Разъяснение того, что предложенная пересылка по умолчанию для нераспознанных значений DSCP не применима к входному кондиционированию на входных узлах DS. Разъяснение влияния на RFC 1349 и RFC 1812. Разъяснение того, что IANA регистрирует только рекомендуемые значения DSCP, распределяемые путем стандартизации.

RFC 2475 — пересмотр определения поля DS. Добавление определений SLS и TCS. Обновление текста по использованию SLS и TCS. Добавление определений класса планирования PHB и упорядоченного агрегата.

RFC 2497 — пересмотр с учетом того, что классы AF являются экземплярами группы AF PHB, а не представляют коллективно группу PHB.

Кроме того, в RFC 3246 [7] была добавлена ссылка на RFC 2475 (раздел «Вопросы безопасности») для случая, когда выходной узел DS получает нераспознанное значение DSCP, которое отображается на EF во входном узле DS.

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

Вопросы безопасности не рассматриваются в RFC 2475.

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

В этом документе используются результаты рабочей группы Diffserv. Множество людей приняло участие в дискуссиях рассылки Diffserv и на встречах. Руководителями группы Diffserv были Brian Carpenter и Kathie Nichols. Среди активных участников обсуждения были Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim, Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John Schnizlein, Francois Le Faucheur и Fred Baker. Mike Ayers, Mike Heard и Andrea Westerinen внесли существенные редакторские правки.

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

[1] Nichols, K., Blake, S., Baker, F. and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, December 1998.

[3] Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski, «Assured Forwarding PHB Group», RFC 2597, June 1999.

[4] Ramakrishnan, K., Floyd, S. and D. Black «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[5] Bradner, S. and V. Paxon, «IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers», BCP 37, RFC2780, March 2000.

[6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, «Terminology for Policy-Based Management», RFC 3198, November 2001.

[7] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Le Boudec, J., Chiu, A., Courtney, W., Cavari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, «An Expedited Forwarding PHB (Per-Hop Behavior)», RFC 3246, March 2002.

[8] Baker, F., «Requirements for IP Version 4 Routers», RFC 1812, June 1995.

[9] Braden, R., «Requirements for Internet Hosts — Communications Layers», STD 3, RFC 1122, October 1989.

[10] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

Адрес автора

Dan Grossman

Motorola, Inc.

20 Cabot Blvd.

Mansfield, MA 02048

EMail: dan@dma.isg.mot.com

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

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

nmalykh@protokols.ru

Полное заявление авторских прав

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Подтверждение

Финансирование функций RFC Editor в настоящее время обеспечивается Internet Society.

1Service Level Agreement — соглашение об уровне обслуживания.

2Traffic Conditioning Agreement.

3Service Level Specification.

4Differenciated Service — дифференцированное обслуживание. Прим. перев.

5Traffic Conditioning Specification.

6Behavior Aggregate — агрегат поведения. Прим. перев.

7Service Provisioning Policy.

8Per-hop behavior — поэтапное поведение.

9Assured Forwarding — гарантированная пересылка.

10Diffserv Codepoint.

11Type-of-Service — тип обслуживания.

12Currently Unused — в настоящее время не используются.

13Explicit congestion notification – явное уведомление о насыщении (перегрузке).

14Label Switched Router — маршрутизатор с коммутацией меток.

15Ordered Aggregate.

16Expedited Forwarding — ускоренная пересылка.

17Denial of service attack.

18Для экспериментального и локального использования.

19На начало 2009 г. этого не произошло. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 3251 Electricity over IP

Опубликовано 01.04.2002 автором Nikolai Malykh

Network Working Group                                 B. Rajagopalan
Request for Comments: 3251                             Tellium, Inc.
Category: Informational                                 1 April 2002

Передача электроэнергии по протоколу IP

Electricity over IP

PDF

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

Данный документ содержит информацию для сообщества Internet. Документ не определяет каких-либо стандартов Internet. Документ может распространяться свободно.

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

Аннотация

MPLampS (Mostly Pointless Lamp Switching – наиболее бессмысленная коммутация лампочек) представляет собой архитектуру передачи электроэнергии по протоколу IP (с использованием управляющего плана MPLS). Согласно исследования нашего маркетингового отдела MPLampS дает потенциальные возможности грандиозного снижения цен, упрощения распределения и использования электроэнергии, а также значительного повышения эффективности управления доставкой электроэнергии потребителям. Предпосылкой для создания этого документа послужили работы по таким вопросам, как передача трафика SONET/SDH по протоколу IP/MPLS (приносим свои извинения авторам). Читатели предыдущей работы наблюдали у себя помутнение разума (scratching their heads) и бормотание: «Что же дальше?». Настоящая работа дает ответ на этот вопрос.

Этот документ был написан, как открытый. Был сформирован специальный раздел «Sub-IP», который позволяет всем желающим равные возможности проведения работ, выходящих за пределы традиционных сетей IP, для написания сложных в понимании документов IETF. Многие, вероятно, будут удивлены появлением таких возможностей для достижения широкой известности. Конечной целью этой работы мы видим созданием стандарта «foo-over-MPLS» (или MPLS-управление для произвольных технологий), как наиболее подходящей основы для создания неисчислимого множества нереализуемых документов. Данный документ иллюстрирует ключевые компоненты, которые могут быть включены в любой документ «foo-over-MPLS» или использоваться в качестве заготовки для всех работ такого рода.

1. Используемые в документе соглашения

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

2. Требования к читателям документа

Во многих местах у читателей этого документа могут возникнуть вопросы типа: «А это имеет смысл?», «Такое возможно?», «Автор в своем уме?» Читатель должен подавить в себе эти неуместные вопросы и читать документ дальше. При условии выполнения этого требования от читателя не требуется никаких технических знаний для чтения этого документа. В некоторых случаях (включая данный документ) от читателя может требоваться отсутствие технических знаний.

3. Введение

Недавно мы обратили свое внимание на странный факт – в сетях распределения электроэнергии не используется протокол IP! После того, как закончился вызванный осознанием этого факта шок, мы осознали следующее:

Распределение электроэнергии базируется на некой устаревшей технологии, называемой Legacy Distribution System (унаследованная система распределения), которую далее для краткости будем обозначать как LDS.
Поскольку LDS не использует технологии Internet, это означает необходимость поддержки и администрирования двух разнотипных сетей (электрической и IP). В результате не может быть обеспечено требуемой эффективности, возрастают расходы и бюрократическая неразбериха (в результате этого могли возникнуть перебои с электроэнергией в Калифорнии; сейчас мы изучаем этот вопрос).
Вышесказанное означает, что должна использоваться единая технология (т. е., IP) для передачи электроэнергии и трафика Internet.
Перед началом работ в данной области нужно выпустить рабочие документы (Internet-Draft), пока это не успел сделать кто-то другой.
Эти рабочие документы могут использоваться для подготовки новых рабочих документов. обеспечивая нам (а так же CCAMP, MPLS и другим надежным и доверенным рабочим группам) занятость на многие годы.
Рабочие документы можно также разместить в разделе «white papers» на корпоративном сайте нашей компании, представив их как революционные идеи.

Эти соображения послужили основой для подготовки данного документа.

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

MPLampS: Mostly Pointless Lamp Switching (наиболее бессмысленная коммутация лампочек) – архитектура, предложенная в настоящем документе.

Lamp – конечная система в архитектуре MPLampS (это не соответствует определению IETF для конечных систем, но для нас такая мелочь не имеет значения).

LER: Low—voltage Electricity Receptor (низковольтный потребитель электроэнергии) – более изысканный эквивалент термина Lamp.

ES: Electricity source (источник электроэнергии) — генератор.

LSR: Load—Switching Router (маршрутизатор с коммутацией нагрузки) – устройство MPLampS используемое в ядре сети распределения электроэнергии.

LDS: Legacy Distribution System (унаследованная система распределения) – технология распределения электроэнергии, не обеспечивающая должного качества; MPLampS обеспечивает замену этой устаревшей технологии.

RSVP: Rather Screwed—up, but router Vendors Push it (пьяный бред, проталкиваемый производителями маршрутизаторов) – сигнальный протокол IP.

RSVP—TE: RSVP with Tariff Extensions (RSVP с тарифным расширением) – адаптация протокола RSVP для технологии MPLampS, предназначенная для использования в новой среде коммунальных услуг со сниженным влиянием государства.

CRLDP: for CRying out Loud, Don‘t do rsvP (для тех, кто громко кричит, но не выполняет RSVP) – еще один сигнальный протокол IP.

OSPF: Often Seizes—up in multiPle area conFigurations (часто заедающий в конфигурации с множеством областей) – иерархический протокол маршрутизации IP.

ISIS: It‘s not oSpf, yet It somehow Survives (это не OSPF, а какой-то пережиток) – еще один протокол маршрутизации.

OSPF-TE, ISIS-TE: OSPF и ISIS с расширением Tariff Extensions.

COPS: Policemen (полицейский) — люди, которые рыскают повсюду, пытаясь пресечь все попытки нарушения протокола Common Open Policy Service.

VPN: Voltage Protected Network (защищенная по напряжению сеть) — позволяет заказчикам с множеством сайтов получать электричество с пренебрежимо малыми флуктуациями напряжения в результате интерференции^¹ от других заказчиков.

SUB—IP: SUBstitute IP everywhere (протолкнуть IP повсюду) — попытки IETF протянуть свои руки в технические области за пределами традиционных сетей IP (например, MPLampS).

ITU: International Tariffed Utilities association — промышленная группа коммунальщиков, работа которой часто игнорируется IETF.

5. Фундаментальные основы

Мы обратили внимание на технологию распределения электроэнергии для получения базовых знаний в этой области. То, что мы узнали, изумило нас — скажем, возможность подачи напряжения 230V A/C в нашу ванну в то время, когда мы в ней находимся. Проще говоря, электричество генерируется и распределяется через огромное число LDS, в которых нет центрального маршрутизатора (LSR или иного)! Более того, управление устройствами в этой сети осуществляется главным образом вручную — люди просто крутят нужные колесики. После кратковременного удивления (каким образом такая сеть могла сохраниться в 21 веке) мы взяли карандаш и бумагу, чтобы разработать сценарий интеграции сетей LDS с проверенной технологией Internet. Исходными точками для такой интеграции являются следующие предпосылки:

IP-пакеты переносят электричество в дискретной цифровой форме.
Каждый пакет доставляет электроэнергию по назначению (т. е., устройству с заданным адресом IP) в соответствии с запросами потребителей.
MPLS-управление будет использоваться для коммутации пакетов в ядре LDS и краевых системах. Такая архитектура будет называться Mostly-Pointless Lamp Switching (наиболее тупая коммутация ламп или MPLampS).
Архитектурная модель MPLampS будет адаптирована как для моделей с перекрытием (overlay model), где потребляющие электричество устройства (будем называть их лампами — lamp) работают в различных плоскостях управления, так и для одноранговых (peer model) систем, в которых лампы и сеть распределения используют единый управляющий план.
Для организации путей передачи электричества в дерегулированной^² среде можно использовать протокол RSVP-TE (RSVP с тарифным расширением).
Для учета и контроля потребления электричества может использоваться протокол COPS.

После создания этой памятки нам стало значительно лучше и мы отметили следующие преимущества предложенной схемы:

Коммутаторы и трансформаторы в LDS можно заменить на LSR, создав новый сектор рынка маршрутизаторов.
Электроэнергию можно будет маршрутизировать в такие места, где еще нет электрических соединений и имеются только Internet-киоски^³ (например, деревни в Индии).
Инженеров-электриков можно будет заменить на высокооплачиваемых администраторов IP-сетей.
IETF сможет распространить свое влияние на многие технологические области со слабым государственным регулированием.

Ниже приведено туманное рассмотрение технических аспектов новой технологии.

6. Кодирование электричества

Схема DVE (Discrete Voltage Encoding — Дискретное Кодирование Электричества) описана стандартом ITU G.110/230V [2] и предназначена для цифрового кодирования электрических напряжений. Суть этой схемы кодирования состоит в том, что источники электричества ES (например, генераторы) подключаются к устройствам кодирования DV, которые представляют напряжение и ток в виде битовых потоков. Эти битовые потоки можно передавать в пакетах IP различным потребителям (будем называть их LER — Low-voltage Electricity Receptor — низковольтные потребители электричества) по запросам последних. В точке назначения декодер DV корректно выполняет обратное преобразование битового потока в напряжение и ток. Будет определено. где может использоваться протокол RTP (Real-time Transport Protocol — транспортировка в реальном масштабе времени) для обеспечения синхронизации и сквозного управления. Решение задачи подготовки рабочего документа для использования RTP мы оставляем нашим друзьям и коллегам.

7. Архитектура MPLampS

7.1 Обзор

В системах LDS для передачи электроэнергии на большие расстояния используется высокое напряжение. По мере передачи электроэнергии через локальную распределительную сеть в направлении потребителя напряжение поэтапно снижается и доставляется LER со стандартным значением (например, 110 или 220 В). Таким образом, LDS представляет собой иерархическую сеть. Это сразу же дает возможность использования расширений OSPF и ISIS для маршрутизации электричества в транспортной сети, но мы займемся изысканиями в этой важной области немного позже. Сейчас мы ограничим наше обсуждение вопросами управления потоком электроэнергии в распределительной сети на основе протокола IP с использованием архитектуры MPLampS.

В рамках MPLampS напряжение приравнивается метке (label). В распределительной сети каждый коммутационный элемент и трансформатор рассматривается как маршрутизатор с коммутацией нагрузки LSR (load-switching router). Каждый пакет IP, переносящий поток электричества, связывается с меткой, которая соответствует напряжению. Распределение электроэнергии в этом случае можно тривиально реализовать путем коммутации меток (напряжений) как потока электричества через распределительную сеть. Настройка конфигурации коммутационных элементов распределительной сети осуществляется с помощью протокола RSVP-TE, что позволяет предоставлять электроэнергию по запросу потребителей.

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

Пример: Включение лампы (Lamp)

Предполагается, что лампа управляется интеллектуальным устройством (например, (световым) коммутатором с управлением на основе MPLampS). with an MPLampS control plane). Включение лампы заставляет коммутатор передать запрос RSVP-TE (сообщение PATH с новыми объектами) для потока электричества. Такое сообщение PATH передается через сеть устройству ES. В ответ генерируется сообщение RESV, задающее отображение меток (label mapping) в маршрутизаторах LSR. После этого поток электричества начинает передаваться по созданному пути. Ожидается, что выполнение всего процесса будет занимать лишь несколько секунд и обеспечит архитектуре MPLampS заметное преимущество по сравнению с зажиганием свечи посредством отсыревших спичек.

7.2 Сравнение одноранговой (Peer) и оверлейной (Overlay) моделей

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

7.3 Маршрутизация в ядре сети

Приведенное выше описание иерархической системы распределения незамедлительно открывает возможность применения протоколов OSPF и ISIS с подходящими расширениями. Читатели могут быть уверены в том, что мы уже работаем над такими концепциями, как создание пакетов напряжений (voltage bundling), мультиобластные тарифные расширения, изолированные LSA и т. п. Детальные описания этих концепций будут представлены в будущих документах.

7.4 Сети с защитой по напряжению (VPN)

Технология VPN позволяет заказчикам, имеющим множество сайтов, гарантированно получать электричество с пренебрежимо малыми флуктуациями напряжения в результате интерференции^⁴ от других пользователей. Несомненно, кое-кто может доказывать, что вся архитектура MPLampS может «накрыться медным тазом», если не будет обеспечиваться поддержка VPN. Как бы то ни было, VPN не рассматриваются в данной работе, но заверяем читателей, что мы уделяем серьезное внимание подготовке нескольких документов по этому вопросу. В частности, поддержка BGP для VPN является сферой нашего пристального внимания.

8. Групповая адресация

Многократно отмечалась сильная пространственная и временная неоднородность запросов на электроэнергию. Исследовательская группа ITU Study Group 55 изучала этот феномен в течение 10 лет и подготовила предварительный отчет. В отчете отмечается, что включение лампы в одном доме обычно вызывает включение ламп в соседних домах в то же самое время (обычно в сумерки) [3]. Это наблюдение оказывает существенное влияние на масштабирование сигнальных механизмов. В частности, распределительная сеть должна быть способна обслуживать одновременно десятки тысяч запросов. Нагрузка на систему сигнализации может быть снижена за счет использования групповой доставки (multicast delivery). Говоря кратко, запрос на электричество от лампы не передается непосредственно к ES, а обслуживается первым LSR, который уже имеет путь к другой лампе.

Такое решение требует поддержки протоколов групповой маршрутизации вместе с разделяемым резервированием RSVP-TE и разработкой для MPLampS режима групповой пересылки (multicast forwarding). В настоящее время мы изучаем следующие протоколы групповой маршрутизации:

DVMRP: Discrete Voltage Multicast Routing Protocol (протокол групповой маршрутизации дискретных напряжений) — этот протокол работает на основе существующих протоколов маршрутизации напряжений, но некоторая опасность его заключается в том, что напряжение доставляется одновременно на все лампы при включении одной из них. Несомненно, что семантика коммутации весьма утомительна и надоедлива — все лампы периодически включаются и, следовательно, нет необходимости каждый раз выключать их вручную.

К другим протоколам, которые мы рассмотрим со временем, относятся CBT (Current-Based Tree – токовое ерево) и PIM (не относящаяся к делу групповая адресация). Вопрос, в котором мы кровно заинтересованы — это групповая адресация. Нам нравится поддержка систем распределения электричества различного масштаба — от ламп на одной рождественской елке до целого города. Нет нужды повторяться — мы напишем множество подробных документов, посвященных этим вопросам.

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

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

10. Заключение

Этот документ описывает мотивацию и высокий уровень концепций, положенных в основу MPLampS (Mostly Pointless Lamp Switching — наиболее бессмысленная коммутация ламп) — архитектуры передачи электроэнергии по протоколу IP. MPLampS использует DVE (дискретное кодирование напряжения) и управляющий план MPLS в распределительных сетях. Поскольку цель настоящего документа состоит в том, чтобы «застолбить место под солнцем», мы не приводим детального рассмотрения MPLampS. Множество будущих документов, к несчастью, будут пытаться обеспечить такие детали.

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

A. Malis, et al., «SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation», Internet Draft, Work in Progress.
International Tarriffed Utilities association draft standard, ITU G.110/230V, «Discrete Voltage Encoding», March, 1999.
International Tarriffed Utilities association technical report, ITU (SG-55) TR-432-2000, «Empirical Models for Energy Utilization», September, 2000.

12. Отречение

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

13. Адрес автора

Bala Rajagopalan

Tellium, Inc.

2 Crescent Place

Ocean Port, NJ 07757

Phone: 732-923-4237

EMail: braja@tellium.com

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

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

nmalykh@protokols.ru

14. Полное заявление авторских прав

Подтверждение

Поддержка функций RFC Editor в настоящее время обеспечивается Internet Society.

1 Разрушающего вредного воздействия. Прим. перев.

2 С ослабленным влиянием государства.Прим. перев.

3 Платные центры доступа в Internet. Прим. перев.

4 Разрушающего вредного воздействия. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior)

Опубликовано 11.03.2002 автором Nikolai Malykh

Network Working Group                                       B. Davie
Request for Comments: 3246                                 A. Charny
Obsoletes: 2598                                  Cisco Systems, Inc.
Category: Standards Track                             J.C.R. Bennett
                                                            Motorola
                                                           K. Benson
                                                             Tellabs
                                                      J.Y. Le Boudec
                                                                EPFL
                                                         W. Courtney
                                                                 TRW
                                                           S. Davari
                                                          PMC-Sierra
                                                           V. Firoiu
                                                     Nortel Networks
                                                        D. Stiliadis
                                                 Lucent Technologies
                                                          March 2002

PHB для ускоренной пересылки

An Expedited Forwarding PHB (Per-Hop Behavior)

PDF

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

В этом документе содержится проект стандартного протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться без ограничений.

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

Аннотация

В этом документе определяется поэтапный режим (PHB¹) называемый ускоренной пересылкой (EF²). PHB представляет собой базовый блок архитектуры дифференцированного обслуживания. Задачей EF является обеспечение базы для построения служб с малыми задержками и их вариациями, а также незначительной потерей пакетов, обеспечивающим обслуживание агрегатов EF с заданной скоростью. Данный документ отменяет действие RFC 2598.

1. Введение

Сетевые узлы, поддерживающие дифференцированное обслуживание для IP, используют код в заголовке IP для выбора поэтапного поведения (PHB), как специфического режима режима пересылки данного пакета [3, 4]. В этом документе описан PHB для ускоренной пересылки (EF).

Задачей EF PHB является обеспечение «строительных блоков» для создания служб с малыми потерями и задержками, а также низкими вариациями задержки. Детали построения таких услуг выходят за пределы данной спецификации.

Основной составляющей задержки в пакетных сетях является фиксированная задержка распространения сигналов (обусловленная конечной скоростью передачи сигналов в среде) в каналах глобальных сетей, а также задержки в очередях на коммутаторах и маршрутизаторах. Поскольку задержка распространения сигналов является фиксированным параметром сетевой топологии, задержки и их вариации минимизируются путем снижения задержек в очередях. Задачей EF PHB является реализация режима PHB, при котором соответствующим образом помеченные пакеты обычно попадают в короткие или пустые очереди. Более того, если очередь коротка по сравнению с размером выделенного для нее буфера, будет сведена к минимуму и потеря пакетов.

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

Отметим, что EF PHB определяет только поведение одного узла. Спецификация поведения множества узлов выходит за пределы данного документа. Такую информацию может предоставить спецификация поведения на уровне домена (PDB³) [7].

Когда совместимый с DS⁴ узел заявляет о поддержке EF PHB, реализация должна соответствовать приведенной в этом документе спецификации. Однако EF PHB может не являться частью архитектуры дифференцированного обслуживания, от узлов, совместимых с DS, не требуется поддержка EF PHB.

1.1. Связь с RFC 2598

Этот документ является заменой RFC 2598 [1]. Основным отличием данного документа является добавление математического формализма для более точного определения предлагаемого режима. Полное обоснование приведено в документе [6].

2. Определение EF PHB

2.1. Интуитивное описание EF

Интуитивно определить EF достаточно просто — скорость, с которой трафик EF обрабатывается на данном выходном интерфейсе должна быть не меньше заданной в конфигурации скорости R в течение подобающим образом определенного интервала, независимо от не относящегося к EF трафика через данный интерфейс. Однако при формализации этого интуитивного определения возникают две сложности:

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

Приведенное ниже формальное определение учитывает эти обстоятельства. Оно предполагает, что пакеты EF следует обслуживать со скоростью R или быстрее и отличает реальное время отправки каждого пакета от «идеального» времени отправки. Время отправки пакета определяется, как время, в которое последний бит пакета был передан с узла. «Идеальное» время отправки рассчитывается путем итераций.

В случае, когда пакет EF прибывает на устройство в тот момент, когда все предшествующие пакеты EF уже отправлены, идеальное время отправки раcсчитывается просто. Обслуживание пакета следует (в идеале) начинать сразу по прибытии, поэтому идеальное время отправки отличается от времени прибытия на идеальное время передачи пакета со скоростью R. Для пакета размером L_j передача со скоростью R займет время L_j/R (естественно, что реальный пакет обычно будет передаваться со скоростью среды после того, как его передача начнется реально, но мы рассчитываем здесь идеальное поведение, поэтому можно брать скорость R).

Если пакет EF прибывает на устройство, где имеются пакеты EF, ожидающие обслуживания, расчет идеального времени отправки усложняется. Здесь рассматриваются два случая. Если предыдущая (j-1) отправка произошла после идеального времени, считается, что планировщик работает «с опозданием». В этом случае идеальным временем начала обслуживания нового пакета является идеальное время отправки предыдущего (j-1) пакета или время прибытия нового пакета (большее из двух значений), поскольку нельзя предположить, что обслуживание пакета начнется до его прихода. Если предыдущий (j-1) пакет был отправлен раньше идеального времени, считается, что планировщик работает «с опережением». В этом случае обслуживание нового пакета следует начинать в момент реальной отправки предыдущего пакета.

Когда известно время начала обслуживания (в идеале) j-ого пакета, идеальное время отправки этого пакета будет на L_j/R секунд больше. Таким образом, мы можем выразить идеальное время отправки j-ого пакета через время прибытия этого пакета, реальное и идеальное время отправки предыдущего (j-1) пакета. Уравнения eq_1 и eq_2 в параграфе 2.2 показывают эти зависимости.

Несмотря на то, что исходное определение EF не обеспечивает никаких гарантий для задержки конкретного пакета EF, способ обеспечения таких гарантий может быть желателен. По этой причине уравнения параграфа 2.2 состоят из двух частей, связанных с «поведением агрегата» и «осведомленных об отдельном пакете»⁵. Уравнения для поведения агрегата (eq_1 и eq_2) просто описывают свойства сервиса, предоставляемого устройством агрегату трафика EF. «Осведомленные о пакетах» уравнения (eq_3 и eq_4) позволяют оценить границы задержки для отдельного пакета на основе операционного состояния устройства. Значимость этих двух наборов уравнений дополнительно рассматривается в параграфе 2.2. Отметим, что эти два набора уравнений обеспечивают два способа описания поведения одного устройства, а не два разных режима.

2.2. Определение формата EF PHB

Узел, поддерживающий EF на интерфейсе I с некоторой заданной скоростью R, должен удовлетворять следующим уравнениям:

d_j <= f_j + E_a for all j > 0 (eq_1)

где f_j определяется итеративно выражением

f_0 = 0, d_0 = 0
f_j = max(a_j, min(d_j-1, f_j-1)) + l_j/R, for all j > 0 (eq_2)

В этом определении:

d_j — время, когда последний бит j-ого пакета EF реально уходит с интерфейса I.
f_j — целевое время отправки j-ого пакета EF с интерфейса I — «идеальное» время, до которого последнему биту пакета следует покинуть узел.
a_j — время, когда последний бит j-ого пакета EF, направленного на выход I, реально прибыл на узел.
l_j — размер (в битах) j-ого пакета EF для отправки через I. l_j относится к дейтаграмме IP (заголовок IP и данные) и не включает дополнительных полей нижележащих (например, MAC) уровней.
R — заданная для EF скорость на выходе I (бит/сек).
E_a — временное отклонение для агрегата EF. Отметим, что E_a представляет худший вариант отклонения реального времени отправки пакета EF от идеального времени его отправки (т. е., E_a определяет верхнюю границу разности d_j — f_j для всех j).
d_0 и f_0 не указывают реальное время отправки пакета и используются исключительно для рекурсии. Начало отсчета времени следует выбирать таким образом, чтобы в начальный момент в системе не было пакетов EF.
При определении a_j и d_j «последний бит» пакета включает трейлер уровня 2, если тот присутствует, поскольку в общем случае пакет не может считаться готовым к пересылке, пока не будет получен трейлер.

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

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

В дополнение к сказанному, узел, поддерживающий EF на интерфейсе I с некоторой заданной скоростью R, должен удовлетворять следующим уравнениям:

D_j <= F_j + E_p for all j > 0 (eq_3)

где F_j определяется итеративно выражениями

F_0 = 0, D_0 = 0
F_j = max(A_j, min(D_j-1, F_j-1)) + L_j/R, for all j > 0 (eq_4)

В этом определении:

D_j — реальное время отправки отдельного пакета EF, который поступил на узел для передачи через интерфейс I в момент A_j (т. е., для данного пакета, который был j-ым пакетом EF, полученным через любой вход и предназначенным для интерфейса I, значение D_j указывает время, когда последний бит данного пакета реально покинул узел через интерфейс I).
F_j — целевое время отправки отдельного пакета EF, который прибыл на узел для отправки через интерфейс I в момент A_j.
A_j — время, когда последний бит j-ого пакета EF, предназначенного для отправки через интерфейс I, реально прибыл на узел.
L_j — размер (в битах) j-ого пакета EF, прибывающего на узел и предназначенного для отправки через интерфейс I. L_j измеряется для дейтаграммы IP (заголовок IP и данные) и не включает полей нижележащего (например, MAC) уровня.
R — заданная для EF скорость на выходном интерфейса I (бит/сек).
E_p — временное отклонение для агрегата EF. Отметим, что E_p представляет худший вариант отклонения реального времени отправки пакета EF от идеального времени его отправки (т. е., E_p определяет верхнюю границу разности D_j — F_j для всех j).
D_0 и F_0 не указывают реальное время отправки пакета и используются исключительно для рекурсии. Начало отсчета времени следует выбирать таким образом, чтобы в начальный момент в системе не было пакетов EF.
При определении A_j и D_j «последний бит» пакета включает трейлер уровня 2, если тот присутствует, поскольку в общем случае пакет не может считаться готовым к пересылке, пока не будет получен трейлер.

D_j и F_j указывают время отправки для j-ого пакет, что делает уравнения eq_3 и eq_4 «осведомленными о пакетах». В этом заключается существенное отличие данной пары уравнений от двух первых уравнений этого параграфа.

Поддерживающему EF узлу следует быть способным характеризоваться диапазоном поддерживаемых значений R для каждого интерфейса, при которых узел соответствует приведенным выше уравнения, и значением E_p для каждого интерфейса. Значение E_p может быть задано , как худший случай для всех возможных значения R, или выражено, как функция R. Может быть также задано «неопределенное» значение E_p. Обсуждение ситуаций, в которых значение E_p становится неопределенным, приведено в приложении и документе [6].

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

2.3. Параметры качества

E_a и E_p можно рассматривать как «параметры качества» устройства. Малое значение E_a означает, что устройство обслуживает агрегат EF достаточно однородно со скоростью R в течение сравнительно коротких интервалов⁷, а большое значение E_a говорит о том, что более склонный к пикам планировщик обеспечивает обслуживание агрегата EF со скоростью R только при измерении в течение достаточно продолжительного периода⁸. В устройстве с большим значением E_a отклонение от идеальной скорости R будет наблюдаться для большего числа пакетов, нежели в устройстве с меньшим значением E_a.

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

Отмечено, что факторы, ведущие к росту E_a, как отмечено выше, будут также увеличивать значение E_p, и значение E_p обычно не меньше, чем E_a. В заключение отметим, что E_a является мерой отклонения от идеального обслуживания агрегата EF при скорости R, а E_p служит мерой отклонения от идеального обслуживания и отличной от FIFO⁹ обработки пакетов в агрегате.

Дополнительное обсуждение этих вопросов содержится в Приложении и документе [6].

2.4. Задержки и вариации

На основе значения E_p и информации о границах для трафика EF, обеспечиваемых данным выходным интерфейсом, с учетом всех входных интерфейсов можно определить границы задержки и ее вариаций, которые будут характеризовать трафик EF, выходящий с узла через данный интерфейс. Граница задержки будет выражаться уравнением

D = B/R + E_p (eq_5)

где

R — заданная для сервиса EF скорость на выходном интерфейсе;
общая загрузка трафиком EF, направляемым в данный выходной интерфейс, суммируемая по всем входным интерфейсам ограничивается «корзиной маркеров¹⁰» глубиной B со скоростью выхода r <= R.

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

E_p = E_fixed + E_variable

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

2.5. Потери

Задачей EF PHB является построение сервиса с малым уровнем потери пакетов. Однако при достаточно высоком уровне трафика EF (включая неожиданно сильные пики на многих входных интерфейсах одновременно) любое устройство с конечной буферной емкостью будет вынуждено отбрасывать пакеты. Следовательно, требуется возможность проверки соответствия устройства требованиям EF даже в условиях потери пакетов. Это осуществляется путем выполнения проверки на соответствие уравнениям 1 — 4 в режиме «off-line». После наблюдения последовательности пакетов входящих на узел и уходящих с него, пакеты, которые не ушли с узла, считаются потерянными и удаляются из входного потока. Оставшиеся пакеты после этого считаются прибывшим потоком (a_j), а пакеты, покинувшие узел, — потоком отправки (d_j). Соответствие уравнениям может быть проверено путем учета лишь тех пакетов, которые успешно прошли через узел.

В плане обеспечения малых потерь для пакетов EF узел может характеризоваться рабочим диапазоном, в котором не возникает потерь пакетов EF в результате насыщения. Это можно задать с использованием token bucket при скорости r <= R и размере пиков B, как сумму трафика через все входы на данный выходной интерфейс, для которой еще не будут возникать потери.

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

2.6. Нарушение порядка в микропотоке

Для пакетов, относящихся к одному микропотоку агрегата EF, проходящего через устройство, не следует менять порядок следования при нормальной работе устройства.

2.7. Рекомендуемый код для PHB

Для EF PHB рекомендуется код 101110.

2.8. Изменяемость

Пакеты, помеченные для EF PHB, могут быть перемаркированы на границе домена DS только другими кодами, удовлетворяющими EF PHB. Домену DS не следует продвигать (или отодвигать) маркированные для EF PHB пакеты в другие PHB.

2.9. Туннелирование

При туннелировании пакетов EF инкапсулирующие пакеты следует маркировать как EF. Полное рассмотрение вопросов туннелирования приведено в документе [5].

2.10. Взаимодействие с другими PHB

Другие PHB и группы PHB могут быть развернуты на одном узле или в домене DS с EF PHB. Уравнения параграфа 2.2 должны выполняться для трафика EF независимо от объемов другого трафика через узел.

Если EF PHB реализуется с помощью механизма, который позволяет неограниченно воспринимать другой трафик (например, очереди с приоритетом), реализация должна обеспечивать какие-либо меры (например, ограничение на основе token bucket) по ограничению урона, который трафик EF может наносить остальному трафику. Максимальная скорость EF и максимальный размер пиков (если это применимо) должны быть настраиваемыми сетевым администратором (с использованием любого механизма, который поддерживает настойку конфигурации узла).

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

Для защиты себя от атак на отказ служб (DoS¹¹) периметру домена DS следует строго проверять для всех пакетов с маркировкой EF соответствие скорости согласованному со смежным восходящим доменом значению. Пакеты, вызывающие превышение согласованной скорости следует отбрасывать. Если смежные домены не согласовали скорость EF, нисходящему домену следует использовать нулевое значение скорости (т. е., отбрасывать все пакеты с маркировкой EF).

В дополнение к этому кондиционирование трафика на входе домена DS должно обеспечивать маркировку кодом DSCP, соответствующим EF PHB внутри домена, только пакетов, промаркированных извне для EF PHB. Такое поведение требуется в соответствии с архитектурой дифференцированного обслуживания [4] и защищает от атак на отказ служб и несанкционированного улучшения обслуживания с использованием кодов DSCP, которые не указаны в спецификации кондиционирования трафика на входном интерфейсе. Эти спецификации предоставляются для входного интерфейса и отображаются на EF внутри домена DS.

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

Данный документ выделяет одно значение кода (101110) из набора 1 в пространстве кодов, определенном в [3].

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

Этот документ является результатом совместной работы и дискуссий множества людей. В частности, Fred Baker, Angela Chiu, Chuck Kalmanek и K. K. Ramakrishnan внесли существенный вклад в создание нового определения EF. Множество полезных комментариев дал авторам John Wroclawski. Этот документ опирается в значительной степени на исходное определение EF PHB, подготовленное Jacobson, Nichols и Poduri. Значительное влияние оказала также работа группы EFRESOLVE в составе Armitage, Casati, Crowcroft, Halpern, Kumar, Schnizlein.

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

[1] Jacobson, V., Nichols, K. and K. Poduri, «An Expedited Forwarding PHB», RFC 2598, June 1999.

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

[3] Nichols, K., Blake, S., Baker, F. and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[4] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, December 1998.

[5] Black, D., «Differentiated Services and Tunnels», RFC 2983, October 2000.

[6] Charny, A., Baker, F., Davie, B., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis, «Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)», RFC 3247, March 2002.

[7] Nichols K. and B. Carpenter, «Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification», RFC 3086, April 2001.

Приложение: Примеры реализации

Это приложение не является частью нормативной спецификации EF и включено в качестве информационной помощи для разработчиков.

Различные факторы реализации узла, поддерживающего EF, будут оказывать влияние на значения E_a и E_p. Эти факторы подробно рассматриваются в документе [6] с учетом выходных планировщиков и внутренних особенностей устройства.

Очереди с приоритетами считаются каноническим примером реализации EF. Устройство с «совершенной» буферизацией (например, сразу доставляющее пакеты в подходящую выходную очередь) и приоритетной очередью для трафика EF будет обеспечивать малые значения для E_a и E_p. Отметим, что основным фактором, влияющим на E_a, будет неспособность прервать уже начавшуюся к моменту прихода на выходной интерфейс пакета EF передачу не относящегося к EF пакет размером MTU, а также дополнительная задержка, которая может быть вызвана непрерываемыми очередями между приоритетной очередью и физическим интерфейсом. Влияние на E_p будет оказывать, прежде всего, число интерфейсов.

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

Можно реализовать алгоритмы иерархического планирования (например, отличные от FIFO) для субпотоков агрегата EF, где агрегат EF в целом будет обслуживаться с высоким приоритетом или наибольшим весом в планировщике верхнего уровня. Такой алгоритм может, например, обеспечивать планирование на уровне входов или микропотоков в агрегате EF. Поскольку такие алгоритмы ведут к отличному от FIFO режиму обслуживания внутри агрегата EF, значение E_p для таких алгоритмов может оказаться выше, чем для других реализаций. Для некоторых планировщиков такого типа может оказаться затруднительным обеспечение значимой границы E_p, которая будет обеспечиваться при любой картине трафика, и, таким образом, может оказаться более приемлемым «неопределенное» значение.

Следует отметить, что для домена Diffserv приемлемо сосуществование множества экземпляров EF. Каждый экземпляр следует характеризовать уравнениями из параграфа 2.2 данной спецификации. Влияние множества экземпляров EF на значения параметров E_a и E_p каждого экземпляра будет существенно зависеть от реализации экземпляров. Например, в многоуровневом планировщике с приоритетами экземпляр EF, который не имеет высшего приоритета, может сталкиваться со сравнительно продолжительными периодами отсутствия обслуживания в то время, как экземпляры EF с высшим приоритетом будут обслуживаться. Это может приводить к существенному росту значений E_a и E_p. Напротив, при использовании планировщика типа WFQ каждый экземпляр EF будет представлен очередью, обслуживаемой с некоторой заданной скоростью, и значения E_a и E_p не будут значительно отличаться от варианта с использованием единственного экземпляра EF.

Адреса авторов

Bruce Davie

Cisco Systems, Inc.

300 Apollo Drive

Chelmsford, MA, 01824

EMail: bsd@cisco.com

Anna Charny

Cisco Systems

300 Apollo Drive

Chelmsford, MA 01824

EMail: acharny@cisco.com

Jon Bennett

Motorola

3 Highwood Drive East

Tewksbury, MA 01876

EMail: jcrb@motorola.com

Kent Benson

Tellabs Research Center

3740 Edison Lake Parkway #101

Mishawaka, IN 46545

EMail: Kent.Benson@tellabs.com

Jean-Yves Le Boudec

ICA-EPFL, INN

Ecublens, CH-1015

Lausanne-EPFL, Switzerland

EMail: jean-yves.leboudec@epfl.ch

Bill Courtney

TRW

Bldg. 201/3702

One Space Park

Redondo Beach, CA 90278

EMail: bill.courtney@trw.com

Shahram Davari

PMC-Sierra Inc

411 Legget Drive

Ottawa, ON K2K 3C9, Canada

EMail: shahram_davari@pmc-sierra.com

Victor Firoiu

Nortel Networks

600 Tech Park

Billerica, MA 01821

EMail: vfiroiu@nortelnetworks.com

Dimitrios Stiliadis

Lucent Technologies

101 Crawfords Corner Road

Holmdel, NJ 07733

EMail: stiliadi@bell-labs.com

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

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

nmalykh@gmail.com

Полное заявление авторских прав

Подтверждение

Финансирование функций RFC Editor обеспечивается Internet Society.

1Per-hop behavior.

2Expedited Forwarding.

3Per-Domain Behavior.

4Differentiated Services — дифференцированное обслуживание. Прим. перев.

5В оригинале «packet-identity-aware». Прим. перев.

6В оригинале «random tie-breaking method». Прим. перев.

7«Мгновенная» скорость обслуживания соответствует заданному значению R. Прим. перев.

8Значению R соответствует только средняя скорость обслуживания агрегата. Прим. перев.

9First In, First Out — обслуживание в порядке поступления. Прим. перев.

10Token bucket.

11Denial of service attack.

Рубрика: RFC | Оставить комментарий

RFC 3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)

Опубликовано 11.03.2002 автором Nikolai Malykh

Network Working Group                                          A. Charny
Request for Comments: 3247                           Cisco Systems, Inc.
Category: Informational                                   J.C.R. Bennett
                                                                Motorola
                                                               K. Benson
                                                                 Tellabs
                                                          J.Y. Le Boudec
                                                                    EPFL
                                                                 A. Chiu
                                                         Celion Networks
                                                             W. Courtney
                                                                     TRW
                                                               S. Davari
                                                              PMC-Sierra
                                                               V. Firoiu
                                                         Nortel Networks
                                                             C. Kalmanek
                                                           AT&T Research
                                                       K.K. Ramakrishnan
                                                      TeraOptic Networks
                                                              March 2002

Дополнение к новому определению режима ускоренной пересылки EF PHB

Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)

PDF

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

В этом документе представлена информация для сообщества Internet. Документ не задает каких-либо стандартов Internet и может распространяться свободно.

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

Аннотация

Этот документ появился в процессе подготовки разъяснений к RFC2598 An Expedited Forwarding PHB, который привел к публикации пересмотренной спецификации An Expedited Forwarding PHB¹. Основным назначением документа является дополнительное разъяснение пересмотренного определения режима EF и его свойств. В документе также даны дополнительные примеры реализации и некоторые рекомендации по расчету значений параметров нового определения для нескольких популярных архитектур планировщиков и маршрутизации.

1. Введение

Режим ускоренной поэтапной пересылки (EF PHB²) был разработан в качестве основы для организации сервиса с малыми потерями, задержками и вариациями задержек. Потенциальные возможности такого сервиса и, следовательно, EF PHB очень велики. В силу важности этого PHB, весьма важно сделать требования к пересылке и ее поведение для соответствующих EF узлов конкретными, измеримыми и однозначными.

К сожалению исходное определение EF PHB в RFC2598 [10] было недостаточно четким (см. Приложение A и документ [4]). Более точное определение дано в документе [6]. Данный документ предназначен для улучшения понимания свойств нового определения и обеспечивает дополнительную информацию, не включенную для краткости в текст документа [6].

Документ разделен на несколько частей. В разделе 2 воспроизведено сокращенное определение EF PHB из [6]. Приведено дополнительное обсуждение этого определения и описаны некоторые его свойства. В разделах 3 и 4 рассмотрены вопросы, связанные с потерями и задержками на уровне отдельных пакетов. В разделе 5 рассмотрено влияние известных архитектур планирования на критичные параметры нового определения. Обсуждается также влияние отклонения реальных устройств от идеальной модели с буферизацией на выходе на значения критичных параметров в определении.

2. Определение EF PHB

2.1. Формальное определение

Интуитивное разъяснение определения новой группы EF описано в [6]. Здесь дословно приводится формальное определение из [6].

      d_j <= f_j + E_a for all j > 0                             (eq_1)

где f_j определяется итеративно выражением

      f_0 = 0, d_0 = 0
      f_j = max(a_j, min(d_j-1, f_j-1)) + l_j/R,  for all j > 0  (eq_2)

В этом определении:

d_j — время, когда последний бит j-ого пакета EF реально уходит с интерфейса I.
f_j — целевое время отправки j-ого пакета EF с интерфейса I — «идеальное» время, до которого последнему биту пакета следует покинуть узел.
a_j — время, когда последний бит j-ого пакета EF, направленного на выход I, реально прибыл на узел.
l_j — размер (в битах) j-ого пакета EF для отправки через I. l_j относится к дейтаграмме IP (заголовок IP и данные) и не включает дополнительных полей нижележащих (например, MAC) уровней.
R — заданная для EF скорость на выходе I (бит/сек).
E_a — временное отклонение для агрегата EF. Отметим, что E_a представляет худший вариант отклонения реального времени отправки пакета EF от идеального времени его отправки (т. е., E_a определяет верхнюю границу разности d_j — f_j для всех j).
d_0 и f_0 не указывают реальное время отправки пакета и используются исключительно для рекурсии. Начало отсчета времени следует выбирать таким образом, чтобы в начальный момент в системе не было пакетов EF.
При определении a_j и d_j «последний бит» пакета включает трейлер уровня 2, если тот присутствует, поскольку в общем случае пакет не может считаться готовым к пересылке, пока не будет получен трейлер.

      D_j <= F_j + E_p for all j>0                                (eq_3)

где F_j определяется итеративно выражениями

      F_0 = 0, D_0 = 0
      F_j = max(A_j, min(D_j-1, F_j-1)) + L_j/R,  for all j > 0   (eq_4)

В этом определении:

D_j — реальное время отправки отдельного пакета EF, который поступил на узел для передачи через интерфейс I в момент A_j (т. е., для данного пакета, который был j-ым пакетом EF, полученным через любой вход и предназначенным для интерфейса I, значение D_j указывает время, когда последний бит данного пакета реально покинул узел через интерфейс I).
F_j — целевое время отправки отдельного пакета EF, который прибыл на узел для отправки через интерфейс I в момент A_j.
A_j — время, когда последний бит j-ого пакета EF, предназначенного для отправки через интерфейс I, реально прибыл на узел.
L_j — размер (в битах) j-ого пакета EF, прибывающего на узел и предназначенного для отправки через интерфейс I. L_j измеряется для дейтаграммы IP (заголовок IP и данные) и не включает полей нижележащего (например, MAC) уровня.
R — заданная для EF скорость на выходном интерфейса I (бит/сек).
E_p — временное отклонение для агрегата EF. Отметим, что E_p представляет худший вариант отклонения реального времени отправки пакета EF от идеального времени его отправки (т. е., E_p определяет верхнюю границу разности D_j — F_j для всех j).
D_0 и F_0 не указывают реальное время отправки пакета и используются исключительно для рекурсии. Начало отсчета времени следует выбирать таким образом, чтобы в начальный момент в системе не было пакетов EF.
При определении A_j и D_j «последний бит» пакета включает трейлер уровня 2, если тот присутствует, поскольку в общем случае пакет не может считаться готовым к пересылке, пока не будет получен трейлер.

D_j и F_j указывают время отправки для j-ого пакета, что делает уравнения eq_3 и eq_4 «осведомленными о пакетах». В этом заключается существенное отличие данной пары уравнений от двух первых уравнений этого параграфа.

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

В документе [6] приведены дополнительные рекомендации для узлов EF, в соответствии с которыми таким узлам не следует менять порядок пакетов в микропотоках.

Описанные в этом параграфе определения называют агрегатами и гарантиями масштабирования скорости с идентификацией пакетов (packet-identity-aware packet scale rate guarantee) [4],[2]. Другие варианты математической характеризации гарантий масштабирования скорости для пакетов приведены в Приложении B.

2.2. Связь с гарантией масштабирования скорости

Рассмотрим идеальное устройство с буферизацией EF FIFO на выходе. Для такого устройства i-й пакет на входе будет i-м также на выходе устройства. Следовательно, в рамках этой идеальной модели характеристики агрегирования «осведомленности о пакетах» будут идентичны и E_a = E_p. По этой причине в данном параграфе задержка будет обозначаться просто E.

Можно показать, что для такого идеального устройства определение параграфа 2.1 строже общеизвестной кривой «скорость-задержка» [2] в том смысле, что планировщик, удовлетворяющий определению EF, будет соответствовать и кривой «скорость-задержка». В результате все известные для кривой «скорость-задержка» свойства применимы и к измененному определению EF. Однако ниже будет показано, что определение из параграфа 2.1 лучше соответствует предназначению EF PHB, нежели кривая «скорость-задержка».

В работе [2] показано, что кривая «скорость-задержка» эквивалентна приведенному ниже определению кривой RLC⁴:

      D(j) <= F'(j) + E                                           (eq_5)

где

      F'(0)=0, F'(j)=max(a(j), F'(j-1))+ L(j)/R for all j>0       (eq_6)

Легко убедиться в том, что определение EF в параграфе 2.1 строже RLC, поскольку для всех j выполняется F'(j) >= F(j).

Легко видеть, что F'(j) в определении RLC соответствует времени j-го отправления, которое должно произойти при обслуживании агрегата EF с заданной скоростью R. В соответствии с общепринятой трактовкой, мы принимаем F'(j), как «время завершения исхода» при отправке j-го пакета.

Интуитивно понятный смысл кривой «скорость-задержка» для RLC заключается в том, любой пакет обслуживается не более чем на время E позже, чем он был бы обслужен в модели fluid.

Для RLC (и, следовательно, для более строгого определения EF) считается, что в любом интервале (0, t) агрегат EF приближается к желаемой скорости обслуживания R (пока имеется трафик, достаточный для удержания такой скорости). Разница между идеальным и реальным сервисом в этом интервале зависит от задержки E, которая, в свою очередь, зависит от реализации планировщика. При снижении E уменьшается и разница между заданной в конфигурации скоростью и реальной скоростью, обеспечиваемой планировщиком.

Хотя RLC гарантирует для агрегата EF желаемую скорость во всех интервалах (0, t) с точностью до указанной ошибки, тем не менее могут возникать значительные перерывы в обслуживании. Предположим, например, (большое число) N идентичных пакетов EF размера L приходит от разных интерфейсов в очередь EF при отсутствии трафика, не относящегося к EF. В этом случае любой сохраняющий работу (work-conserving) планировщик будет обслуживать все N пакетов со скоростью канала. Если последний пакет передан в момент NL/C, где C указывает пропускную способность выходного канала, F'(N) будет равно NL/R. То есть, планировщик работает не идеально, поскольку NL/C < NL/R для R < C. Предположим сейчас, что в момент NL/C приходит большое число пакетов, не относящихся к EF, за которыми следует один пакет EF. В этом случае планировщик может обоснованно задержать начало передачи пакета EF до момента F'(N+1) = (N+1)L/R + E — L/C. Это означает, что агрегат EF не будет обслуживаться совсем в интервале (NL/C, (N+1)L/R + E — L/C). Интервал этот может быть достаточно большим, если R существенно меньше C. По сути, агрегат EF может быть «наказан» прерыванием обслуживания за получение ускоренного по сравнению с заданным в конфигурации обслуживания в начале.

Новое определение EF смягчает эту проблему за счет введения в рекурсию элемента min(D(j-1), F(j-1)). Это, по сути, означает, что время завершения потока «сбрасывается», если пакет передается до «идеального» момента его отправки. Для случая этого случая при обслуживании агрегата EF в порядке FIFO предположим, что пакет приходит в момент t на сервер, соответствующий определению EF. Пакет тогда будет передан не позднее момента t + Q(t)/R + E, где Q(t) указывает размер очереди EF в момент t (с учетом рассматриваемого пакета) [4].

2.3. Необходимость двойной характеризации EF PHB

В более общем случае, когда выходной планировщик не обслуживает пакеты EF в порядке FIFO или переменная внутренняя задержка в устройстве меняет порядок следования пакетов, i-й пакет при доставке на данный выходной интерфейс может оказаться не i-м при передаче с этого интерфейса. В таких случаях агрегирование и идентификация пакетов уже не будут давать одинаковых результатов.

Определение агрегатного поведения можно рассматривать как действительно совокупную характеристику услуг, предоставляемых пакетам EF. В качестве аналогии рассмотрим «темный» резервуар, в который помещаются все поступающие пакеты. Планировщику разрешено случайным образом помечать пакеты в резервуаре, не зная порядка их поступления в резервуар. Совокупная часть определения измеряет точность выходной скорости, обеспечиваемой для агрегата EF в целом. Чем меньше E_a, тем более точна будет гарантия того, что резервуар сливается со скоростью не меньше заданной в конфигурации.

Отметим, что в этой аналогии с резервуаром пакеты агрегата EF могут произвольно менять порядок. Однако в определении EF PHB [6] явно требуется сохранение порядка пакетов внутри микропотока. Это требование ограничивает реализации планировщиков, что в примере с резервуаром будет требовать сохранения порядка выхода пакетов одного микропотока из резервуара, но позволяет менять порядок на уровне агрегата.

Отметим, что изменение порядка внутри агрегата при отсутствии нарушений порядка на уровне потока не обязательно говорит о «плохом» обслуживании. Рассмотрим, например, планировщик, который работает с 10 разными «потоками» EF, имеющими разные скорости. Знающий о потребностях в скорости планировщик может выбрать передачу пакета из более быстрого потока до передачи пакета из более медленного с целью снижения вариаций задержки на уровне потока. В частности, идеальный планировщик WFQ, осведомленный о «потоках» будет менять порядок внутри агрегата, поддерживая порядок и незначительные вариации задержки на уровне потока.

Интуитивно понятно, что для такого планировщика, а также для более простого планировщика FIFO «точность» скорости обслуживания имеет важнейшее значение для минимизации вариаций задержки на уровне «потока». Для оценки точности скорости обслуживания нужно определение определение с учетом идентификации пакетов.

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

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

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

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

В результате большое число E_p не обязательно служит мерилом качества реализации EF. Однако малое значение E_p показывает высокое качество реализации FIFO.

Поскольку E_p и E_a относятся к разным аспектам реализации EF, их следует рассматривать совместно для определения качества реализации.

3. Задержки по пакетам

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

3.1. Границы задержки на одном интервале

Если общий трафик, приходящий на выходной порт I со всех входов, ограничивается с помощью механизма leaky bucket⁵ с параметрами (R, B), где R указывает настроенную для I скорость, а B определяет размер «емкости» (величину пика), то задержка любого пакета, уходящего из I ограничена значением D_p, которое определяется уравнением

      D_p = B/R + E_p                                             (eq_7)

(см. Приложение B).

Поскольку границы задержек зависят от заданной в конфигурации скорости R и уровня всплесков трафика на входе B, желательно обеспечить видимость обоих параметров для пользователя устройства. Для PDB, желающего получить конкретные границы задержек может потребоваться ограничение задаваемой в конфигурации скорости и поддерживаемого уровня всплесков трафика. Уравнение (eq_7) обеспечивает возможность определения приемлемого рабочего диапазона для устройства с заданным E_p. Это может быть полезно также для ограничения общей нагрузки для заданного выхода некой скоростью R_1 < R (например, для ограничения сквозной задержки [5]). Важно понимать, что границы задержки в (eq_7) не зависят от R_1 несмотря на возможность настройки этого параметра. Может оказаться возможным более четкое задание границ за счет явного ограничения входной скорости, но ограничения (eq_7) не используют эту информацию.

3.2. Худший случай задержки на многоэтапном участке

Хотя PHB по своей природе определяет локальное поведение, в этом параграфе кратко рассматривается вопрос попакетной задержки при прохождении пакетов через несколько интервалов, реализующих EF PHB. С учетом границ задержки (eq_7) на одном интервале возникает соблазн предположить, что границы задержки при прохождении h интервалов будут определяться произведением h на значение (eq_7). Однако это не всегда верно, если B не представляет худший вариант входных пиков трафика на всех узлах сети.

К сожалению, определить такое наихудшее значение B — задача нетривиальная. Если EF PHB реализовано с использованием агрегатного планирования на основе классов, где все пакеты EF используют общий буфер FIFO, эффект накопления вариаций задержки (jitter) может приводить к росту пиков от интервала к интервалу. В частности, можно показать, без введения некоторых ограничений на использование EF даже при идеальной форме всех потоков EF на входе для любого значения задержки D можно создать сеть, где использование EF на любом канале ограничено так, что не превышает заданное значение, потоки не проходят через превышающее заданных порог число интервалов, но при этом все равно имеются пакеты, которые сталкиваются с задержкой, превышающей D [5]. Этот результат предполагает, что возможность ограничить наихудший вариант пиков трафика и результирующую сквозную задержку на пути через несколько интервалов может потребовать не только ограничения использования EF на всех каналах, но будет также вносить ограничения для глобальной топологии сети. Такие топологические ограничения потребуется задавать в определении любого PDB, создаваемого «поверх» EF PHB, если для такого PDB требуется строгое ограничение для худшего случая задержки.

4. Потеря пакетов

Любому устройству с конечным размером буферов может потребоваться отбрасывать пакеты при достаточно сильных пиках входного трафика. В плане реализации цели EF по снижению уровня потерь узел можно характеризовать рабочим диапазоном, в котором не будет происходить потерь EF по причине насыщения. Это можно задать как «переполняющуюся емкость» (token bucket) со скоростью r <= R и величиной пика B, которые могут быть восприняты от всех входов для данного выхода без возникновения потерь.

Однако, как было отмечено в предыдущем разделе, феномен накопления вариаций задержки в общем случае осложняет гарантии того, что входные пики никогда не выйдут за пределы заданного рабочего диапазона для внутренних узлов домена DiffServ. Гарантия отсутствия потерь при прохождении через множество интервалов может потребовать задания ограничений на топологию сети, которые выходят за рамки локального по сути определения PHB. Таким образом, должна быть возможность понять соответствует ли устройство определению EF даже при потере некоторых пакетов.

Это можно сделать с помощью отдельной (off-line) проверки выполнения уравнений (eq_1) — (eq_4). После наблюдения последовательности пакетов, приходящих на узел и уходящих с него, не ушедшие пакеты считаются потерянными и обычно удаляются из входного потока. Остальные пакеты составляют прибывший поток, а ушедшие с узла пакеты — ушедший поток. Соответствие уравнениям может быть, таким образом, проверено путем рассмотрения пакетов, благополучно прошедших через узел.

Отметим, что указание того, какие пакеты теряются в случае возникновения потерь, выходит за рамки определения EF PHB. Однако пакеты, которые не были потеряны, должны соответствовать уравнениям определения EF PHB в параграфе 2.1.

5. Вопросы реализации

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

Однако в маршрутизаторе могут возникать и другие задержки пакетов. Например, маршрутизатор может затратить некоторое время на обработку заголовка пакета перед его размещением в соответствующем выходном буфере. В другом случае маршрутизатор может включать буфер FIFO (называется очередью передачи в [7]), где пакет находится после выбора выходным планировщиком до момента передачи. В подобных случаях возникающая дополнительная задержка может быть учтена в параметрах задержки E_a и E_p.

Особого внимания требует реализация EF на маршрутизаторах с многоступенчатой матрицей коммутации. Пакет может сталкиваться с дополнительной задержкой по причине его конкуренции за ресурсы пересылки с другим трафиком в нескольких «точках конкуренции» коммутационного ядра. Задержка пакета EF может возникнуть еще до того, как он попадет к планировщику выходного канала и ее также следует учитывать. Маршрутизаторы с буферизацией на входе и на входе и выходе на основе перекрестной модели (crossbar) также могут потребовать изменения параметров задержки. Такие факторы, как коэффициент ускорения (speedup factor) и выбор алгоритмов перекрестного арбитража, могут существенно воздействовать на задержки.

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

Для учета этих соображений в данном разделе рассматриваются два упрощенных примера реализации. В первом случае идеальный узел с буферизацией на выходе принимает пакеты от входного интерфейса с незамедлительной доставкой их выходному планировщику. В этой модели свойства выходного планировщика полностью определяют значения параметров E_a и E_p. Будем рассматривать случай когда выходной планировщик реализует агрегатные очереди по классам, где все пакеты EF попадают в одну очередь. Мы рассмотрим значения E_a и E_p для разных широко распространенных планировщиков на основе класса.

Во втором примере рассматривается маршрутизатор, как «черный ящик» с известной границей переменной части задержки, которая может возникать с момента прибытия пакета на вход до момента доставки на соответствующий выход. Выходной планировщик предполагается агрегатным, где все пакеты EF используют одну очередь FIFO с известными значениями E_a(S)=E_p(S)=E(S). Эта модель является подходящей абстракцией для большого класса реальных маршрутизаторов.

5.1. Модель буферизованного выхода с EF FIFO

Как было отмечено выше, в этой модели E_a = E_p, поэтому мы будем опускать индексы, обозначая обе задержки E. В оставшейся части этого параграфа рассматриваются значения E для множества реализаций планировщиков.

5.1.1. Очередь со строгим, неупреждающим приоритетом

Строгий планировщик по приоритетам (Strict Priority), где все пакеты EF используют одну общую очередь FIFO, которая обслуживается строго с неупреждающим приоритетом по отношению к другим очередям, соответствует определению EF с параметром задержки E = MTU/C, где MTU указывает максимальный размер пакета, а C — скорость выходного канала.

5.1.2. WF2Q

Другим планировщиком, удовлетворяющим определению EF с малой задержкой, является WF2Q, описанный в [1]. Планировщик по классам WF2Q, в котором для всего трафика EF используется одна общая очередь с весом, соответствующим заданной в конфигурации скоростью агрегата EF, соответствует определению EF с параметром задержки E = MTU/C+MTU/R.

5.1.3. DRR

Для DRR⁶ [12] можно показать, что E будет расти пропорционально N*(r_max/r_min)*MTU, где r_min и r_max обозначают наименьшую и наибольшую из скоростей, выделенных для всех очередей в планировщике, а N — число очередей.

5.1.4. SFQ и SCFQ

Для беспристрастных очередей SFQ⁷ [9] и SCFQ⁸ [8] можно показать, что E будет расти пропорционально числу очередей в планировщике.

5.2. Маршрутизатор с внутренней задержкой и EF FIFO на выходе

В этом разделе мы рассмотрим маршрутизатор, в котором приходящий пакет может столкнуться с переменной задержкой D_v, верхняя граница которой составляет D (т. е., 0<=D_v<=D). На выходе все пакеты EF используют общую очередь одного класса. Планирование для очередей по классам выполняется планировщиком с известным значением E_p(S)=E(S), где E(S) соответствует модели в которой планировщик реализован как идеальное устройство с буферизацией на выходе.

В этом случае расчет E_p более сложен. Можно показать, что для таких устройств E_p = E(S)+2D+2B/R (см. [13]).

Вернемся к обсуждению раздела 3, где ограничение входных пиков B может оказаться непростым в обычной топологии. При отсутствии информации о границе B можно сказать, что E_p = E(S) + D*C_inp/R (см. [13]).

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

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

В этом информационном документе приведена дополнительная информация с целью улучшить понимание EF PHB, описанного в [6]. Документ не добавляет новых функций и в результате не создает новых проблем безопасности в дополнение к описанным в упомянутой спецификации.

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

J.C.R. Bennett and H. Zhang, «WF2Q: Worst-case Fair Weighted Fair Queuing», INFOCOM’96, March 1996.
J.-Y. Le Boudec, P. Thiran, «Network Calculus», Springer Verlag Lecture Notes in Computer Science volume 2050, June 2001 (available online at http://lcawww.epfl.ch).
Bradner, S., «Key Words for Use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.
J.C.R. Bennett, K. Benson, A. Charny, W. Courtney, J.Y. Le Boudec, «Delay Jitter Bounds and Packet Scale Rate Guarantee for Expedited Forwarding», Proc. Infocom 2001, April 2001.
A. Charny, J.-Y. Le Boudec «Delay Bounds in a Network with Aggregate Scheduling». Proc. of QoFIS’2000, September 25-26, 2000, Berlin, Germany.
Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis, «An Expedited Forwarding PHB (Per-Hop Behavior)», RFC 3246, March 2002.
T. Ferrari and P. F. Chimento, «A Measurement-Based Analysis of Expedited Forwarding PHB Mechanisms,» Eighth International Workshop on Quality of Service, Pittsburgh, PA, June 2000.
S.J. Golestani. «A Self-clocked Fair Queuing Scheme for Broad-band Applications». In Proceedings of IEEE INFOCOM’94, pages 636-646, Toronto, CA, April 1994.
P. Goyal, H.M. Vin, and H. Chen. «Start-time Fair Queuing: A Scheduling Algorithm for Integrated Services». In Proceedings of the ACM-SIGCOMM 96, pages 157-168, Palo Alto, CA, August 1996.
Jacobson, V., Nichols, K. and K. Poduri, «An Expedited Forwarding PHB», RFC 2598, June 1999.
Jacobson, V., Nichols, K. and K. Poduri, «The ‘Virtual Wire’ Behavior Aggregate», Work in Progress.
M. Shreedhar and G. Varghese. «Efficient Fair Queuing Using Deficit Round Robin». In Proceedings of SIGCOMM’95, pages 231-243, Boston, MA, September 1995.
Le Boudec, J.-Y., Charny, A. «Packet Scale Rate Guarantee for non-FIFO Nodes», Infocom 2002, New York, June 2002.

Приложение A. Сложности с определением RFC 2598 EF PHB

В работе [10] приведено определение EF PHB.

«EF PHB определяется, как трактовка пересылки для отдельного агрегата diffserv⁹, при которой скорость отправки пакетов данного агрегата с любого узла diffserv не меньше заданного значения. Следует обеспечивать гарантию заданной скорости отправки независимо от интенсивности остального трафика, пытающегося проходить через узел. Следует обеспечивать среднее значение скорости¹⁰ отправки не менее заданного значения.»

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

A.1 Синхронизированная пересылка

Рассмотрим поток, пересылаемый с маршрутизатора с заданной в EF скоростью R=C/2, где C — скорость выходной линии. На рисунке ниже E представляет собой пакет EF размера MTU, а x — пакет, не относящийся к EF, или неиспользуемую емкость (также размера MTU).

      E x E x E x E x E x E x...
       |-----|

Интервал между вертикальными линиями на рисунке составляет 3*MTU/C, что превышает MTU/(C/2), и является субъектом определения EF PHB. В течение этого интервала следовало бы переслать 3*MTU/2 битов агрегата EF, но пересылается только MTU битов. Хотя данную картину пересылки следует соответствующей спецификации при любой разумной интерпретации EF PHB, она формально не соответствует определению RFC 2598.

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

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

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

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

A.2 Внутренняя задержка в маршрутизаторе

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

Рассмотрим маршрутизатор с настроенной скоростью EF, равной R = C/2 как в предыдущем примере, и внутренней задержкой 3T (где T = MTU/C) между временем прихода пакета на маршрутизатор и временем, когда этот пакет становится первым в очереди на отправку в выходной канал. Задержку в маршрутизаторе могут вызывать такие события, как обработка заголовков, поиск маршрута и задержка в многоуровневой матрице коммутации. Предположим, что трафик EF поступает со стабильной скоростью (2/3)R = C/3. Временные параметры прохождения пакетов через маршрутизатор показаны ниже.

Номер пакета EF              1  2  3   4   5   6   ...
Прибытие (на маршрутизаторе) 0  3T 6T  9T  12T 15T ...
Прибытие (на планировщике)   3T 6T 9T  12T 15T 18T ...
Отправка                     4T 7T 10T 13T 16T 19T ...

И на сей раз выход не соответствует приведенному в RFC 2598 определению EF PHB. Как и в предыдущем примере причина заключается в том, что планировщик не может пересылать трафик EF быстрее, чем тот прибывает. Однако легко заметить, что наличие внутренней задержки обеспечивает постоянное присутствие пакетов в маршрутизаторе. Внешний наблюдатель может сделать правомерное заключение о том, что число поступивших на маршрутизатор пакетов EF всегда превышает число покинувших маршрутизатор пакетов EF хотя бы на 1, следовательно агрегат EF постоянно задерживается. Однако, несмотря на постоянную задержку агрегата EF, наблюдаемая выходная скорость никогда не становится существенно меньше заданной в конфигурации скорости.

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

Тем не менее, описанная здесь проблема имеет важное значение на практике. Большинство маршрутизаторов вносит некоторую внутреннюю задержку. Не предполагается, что производители, заявляющие совместимость с EF, будут объявлять также детали внутренних задержек в маршрутизаторах. Следовательно, наличие внутренних задержек может приводить к тому, что полностью соответствующая EF реализация будет демонстрировать поведение, представляющееся не совместимым, что явно нежелательно.

A.3 Максимальная скорость и обеспечение эффективности

Хорошо понятно, что с любым неупреждающим (non-preemptive) планировщиком заданная в соответствии с RFC 2598 скорость для агрегата EF не может превышать C/2 [11]. Это обусловлено тем, что пакет EF размера MTU может поступить в пустую очередь в момент t, когда началась обработка не относящегося к EF пакета размером MTU. Максимальное число битов EF, которые могут быть переданы в течение интервала [t, t + 2*MTU/C], равно MTU. Но если задана скорость R > C/2, размер этого интервала будет превышать MTU/R и для обеспечения соответствия маршрутизатор в течение этого интервала должен обрабатывать больше MTU битов EF. Следовательно R должно быть не более C/2.

Можно показать, что для отличных от PQ планировщиков (например, разных реализаций WFQ) максимальная задаваемая в конфигурации скорость может быть много меньше 50%. Например, для SCFQ [8] максимальная скорость не может превышать C/N, где N — число очередей в планировщике. Для WRR, отмеченного как соответствующий спецификации в параграфе 2.2 документа RFC 2598, это ограничение еще сильнее. Это обусловлено тем, что в этих планировщиках пакеты, прибывающие в пустую очередь EF, могут быть вынуждены ждать, пока будет обработано по одному (для SCFQ) или несколько (для WRR) пакету из каждой другой очереди.

Хотя часто предполагается, что заданная в конфигурации скорость трафика EF существенно ниже пропускной способности канала, требование, чтобы эта скорость никогда не была выше 50% от пропускной способности канала, представляется неоправданным ограничением. Например в полносвязной (full mesh) сети, где любой поток проходит от источника к получателю только через один канал, не видится разумных причин ограничивать скорость трафика EF значением 50% (или даже меньше для некоторых планировщиков) от пропускной способности канала.

Другим, возможно более ярким, примером является факт, что даже устройство TDM с выделенными временными интервалами не может быть настроено на пересылку трафика EF со скоростью больше 50% от скорости канала без нарушения RFC 2598 (пока весь канал не выделен для EF). Если заданная в конфигурации скорость EF превышает 50% (но меньше скорости канала), всегда будет присутствовать интервал больше MTU/R, в течение которого доступна будет скорость меньше заданной в конфигурации. Например, предположим, что задана скорость для агрегата EF в размере 2C/3. Тогда картина пересылки на устройстве TDM будет иметь вид

   E E x E E x E E x ...
      |---|

где лишь один пакет обслуживается в отмеченном интервале 2T = 2MTU/C. Но в соответствии с определением RFC 2598 маршрутизатор в течение этого интервала должен обработать не менее 4/3 MTU. Возможность заказать для трафика EF не более половины пропускной способности даже для линии TDM показывает искусственность и ненужность такого ограничения.

A.4 Нетривиальная природа сложностей

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

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

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

Ниже приведено предлагаемое определение с учетом этих двух изменений.

В течение любого интервала времени (t1, t2), в котором наблюдается непрерывная задержка трафика EF, должно быть обслужено не менее R(t2 — t1 — E) битов трафика EF, где R — заданная в конфигурации скорость для агрегата EF, а E — зависящий от реализации параметр задержки.

Условие «непрерывной задержки» (continuously backlogged) позволяет обойти сложности с нехваткой пакетов для пересылки, а добавление параметра задержки размером MTU/C решает проблему «синхронизации», отмеченную в параграфе A.1, а также снимает ограничение на задаваемую в конфигурации скорость EF.

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

Приложение B. Дополнительные характеристики гарантий масштабирования скорости

Доказательства некоторых оценок из этого документа представлены в работе [13]. В этих доказательствах используется алгебраическая характеризация определения агрегата, данного в уравнениях (eq_1) и (eq_2), а также определения осведомленности о пакетах, данного в уравнениях (eq_3) и (eq_4). Поскольку эта характеризация представляет самостоятельный интерес, она описана в данном приложении.

Теорема B1. Характеризация определения агрегата без f_n.

Рассмотрим систему, где пакеты получают номера 1, 2, … в порядке их поступления. Как в определении агрегата обозначим a_n время прихода пакета n, d_n — время его отправки и l_n — размер n-го пакета для отправки. Пусть d_0=0. Определение агрегата со скоростью R и задержкой E_a эквивалентно тому, что для всех n и всех 0<=j<= n-1 выполняется условие

      d_n <= E_a + d_j + (l_(j+1) + ... + l_n)/R                 (eq_b1)

или имеется некий номер j+1 <= k <= n, такой что

      d_n  <= E_a + a_k + (l_k + ... + l_n)/R                    (eq_b2)

Теорема B2. Характеризация определения осведомленности о пакетах без F_n.

Рассмотрим систему, где пакеты получают номера 1, 2, … в порядке их поступления. Как в определении осведомленности а пакетах обозначим A_n и D_n время прибытия и отправки пакета n, а L_n — размер этого пакета. Пусть D_0=0. Определение осведомленности о пакете для скорости R и задержки E_pэквивалентно тому, что для всех n и всех 0<=j<= n-1 выполняется условие

      D_n <= E_p + D_j + (L_{j+1} + ... + L_n)/R                 (eq_b3)

или имеется некий номер j+1 <= k <= n, такой что

      D_n  <= E_p + A_k + (L_k + ... + L_n)/R                    (eq_b4)

Доказательства обеих теорем можно найти в работе [13].

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

Этот документ не был бы написан без Fred Baker, Bruce Davie и Dimitrios Stiliadis. Их время, поддержка и содержательные комментарии неоценимы.

Адреса авторов

Anna Charny

Cisco Systems

300 Apollo Drive

Chelmsford, MA 01824

EMail: acharny@cisco.com

Jon Bennett

Motorola

3 Highwood Drive East

Tewksbury, MA 01876

EMail: jcrb@motorola.com

Kent Benson

Tellabs Research Center

3740 Edison Lake Parkway #101

Mishawaka, IN 46545

EMail: Kent.Benson@tellabs.com

Jean-Yves Le Boudec

ICA-EPFL, INN

Ecublens, CH-1015

Lausanne-EPFL, Switzerland

EMail: jean-yves.leboudec@epfl.ch

Angela Chiu

Celion Networks

1 Sheila Drive, Suite 2

Tinton Falls, NJ 07724

EMail: angela.chiu@celion.com

Bill Courtney

TRW

Bldg. 201/3702

One Space Park

Redondo Beach, CA 90278

EMail: bill.courtney@trw.com

Shahram Davari

PMC-Sierra Inc

411 Legget Drive

Ottawa, ON K2K 3C9, Canada

EMail: shahram_davari@pmc-sierra.com

Victor Firoiu

Nortel Networks

600 Tech Park

Billerica, MA 01821

EMail: vfiroiu@nortelnetworks.com

Charles Kalmanek

AT&T Labs-Research

180 Park Avenue, Room A113,

Florham Park NJ

EMail: crk@research.att.com

K.K. Ramakrishnan

TeraOptic Networks, Inc.

686 W. Maude Ave

Sunnyvale, CA 94086

EMail: kk@teraoptic.com

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

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

nmalykh@gmail.com

Полное заявление авторских прав

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Режим ускоренной пересылки.

2Expedited Forwarding Per-Hop Behavior.

3В оригинале «random tie-breaking method». Прим. перев.

4Rate Latency Curve — кривая зависимости между скоростью и задержкой.

5Переполняющаяся емкость.

6Deficit Round Robin.

7Start-Time Fair Queuing.

8Self-Clocked Fair Queuing.

9Differentiated Service — дифференцированное обслуживание. Прим. перев.

10При измерении за период не менее, чем потребуется для передачи в канал с такой скоростью пакетов размера MTU.

Рубрика: RFC | Комментарии отключены

RFC 3232 Assigned Numbers: RFC 1700 is Replaced by an On-line Database

Опубликовано 22.01.2002 автором Nikolai Malykh

Network Working Group                            J. Reynolds, Editor
Request for Comments: 3232                                RFC Editor
Obsoletes: 1700                                         January 2002
Category: Informational

PDF

Assigned Numbers: RFC 1700 is Replaced by an On-line Database

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

Этот документ содержит информацию для сообщества Internet и не задает каких-либо стандартов Internet. Документ может распространяться без ограничений.

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

Аннотация

Данный документ отменяет действие RFC 1700 (STD 2) Assigned Numbers, который содержал данные на октябрь 1994 по выделенным значениям параметров протоколов Internet.

Описание

С ноября 1977 по октябрь 1994 агентство IANA¹) периодически публиковало списки выделенных значений параметров протоколов Internet в RFC под названием Assigned Numbers. Последний такой документ RFC 1700 имеет статус стандарта Internet (STD 2).

С1994 года публикация такихRFC прерывается, а информация о выделенных значениях переносится в базу данных, доступную на сайте (в настоящее время, www.iana.org). Целью данного RFC является официальное уведомление об отмене RFC 1700 и переводе документа в статус Historic. RFC 1700 устарел, не полон и может содержать ошибки.

Авторы надеются, что публикация значений будет возобновлена новой организацией IANA.

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

Этот документ не воздействует на технические аспекты безопасности Internet.

Адрес автора

Joyce K. Reynolds

RFC Editor

4676 Admiralty Way

Marina del Rey, CA 90292

USA

EMail: rfc-editor@rfc-editor.org

Полное заявление авторских прав

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

Перевод на русский язык
Николай Малых
nmalykh@protokols.ru

1Internet Assigned Numbers Authority.

Рубрика: RFC | Оставить комментарий

RFC 3220 IP Mobility Support for IPv4

Опубликовано 05.01.2002 автором Nikolai Malykh

Network Working Group                                    C. Perkins, Ed.
Request for Comments: 3220                         Nokia Research Center
Obsoletes: 2002                                             January 2002
Category: Standards Track

PDF

Поддержка IP Mobility для IPv4

IP Mobility Support for IPv4

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

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

Аннотация

1. Введение

узел меняет адрес в соответствии с точкой подключения;
специфические маршруты к хостам распространяются через систему маршрутизации Internet.

1.1. Протокольные требования

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

1.2. Цели

1.3. Допущения

1.4. Применимость

1.5. Новые архитектурные элементы

Mobile IP добавляет ряд новых функциональных элементов, перечисленных ниже.

Mobile Node — мобильный узел

Home Agent — домашний агент

Foreign Agent — внешний агент

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

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

Authorization-enabling extension — расширение для поддержки проверки полномочий

Agent Advertisement — анонсирование агента

Сообщение-анонс, созданное путем присоединения к маршрутным анонсам специального расширения [10].

Authentication — аутентификация

Care-of Address — адрес обслуживания

Correspondent Node — узел-корреспондент

Партнер, с которым взаимодействует мобильный узел. Это может быть стационарный или мобильный узел.

Foreign Network — чужая сеть

Любая сеть, не являющаяся домашней для мобильного узла.

Gratuitous ARP — беспричинный пакет

Пакет ARP, передаваемый узлом для того, чтобы побудить другие узлу к обновлению их кэша ARP [45] (см. параграф 4.6).

Home Address — домашний адрес ARP

Home Network — домашняя сеть

Link — канал, соединение

Link-Layer Address — адрес канального уровня

Mobility Agent — агент мобильности

Домашний или внешний агент.

Mobility Binding — мобильная привязка

Связывание домашнего адреса с адресом обслуживания вкупе со временем существования такой привязки.

Mobility Security Association — защищенная мобильная связь

Node — узел

Хост или маршрутизатор.

Nonce

Security Parameter Index (SPI) — индекс параметров защиты

Tunnel — туннель

Virtual Network — виртуальная сеть

Visited Network — посещенная сеть

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

Visitor List — список посетителей

Список мобильных узлов, посетивших внешний агент.

1.7. Обзор протокола

Ниже перечислены службы, определенные для Mobile IP.

Agent Discovery — обнаружение агента

Registration — регистрация

silently discard — отбрасывание без уведомления

Ниже кратко описаны операции протокола Mobile IP.

Агенты мобильности (т. е., домашние и внешние агенты) анонсируют свое присутствие с помощью сообщений Agent Advertisement (раздел 2). Мобильный узел может запросить сообщение Agent Advertisement от любого локально подключенного агента мобильности с помощью отправки сообщения Agent Solicitation.
Мобильный узел получает эти сообщения Agent Advertisement и определяет подключен он к домашней или чужой сети.
Когда мобильный узел определяет свое подключение к домашней сети, он не использует службы мобильности. При возвращении в домашнюю сеть после регистрации в какой-либо чужой сети мобильный узел заново регистрируется на домашнем агенте, обмениваясь с ним сообщениями Registration Request и Registration Reply.
Когда мобильный узел определяет, что он подключен к чужой сети, он получает от этой сети адрес обслуживания. Этот адрес может быть определен из анонсов внешнего агента (адрес внешнего агента) или с помощью того или иного внешнего механизма типа DHCP [13] (совмещенный адрес обслуживания).
Работающий за пределами домашней сети мобильный узел регистрирует адрес обслуживания на своем домашнем агенте, обмениваясь с ним сообщениями Registration Request и Registration Reply (возможно через внешнего агента — см. раздел 3).
Дейтаграммы, передаваемые на домашний адрес мобильного узла, перехватываются домашним агентом, туннелируются на адрес обслуживания мобильного узла, принимаются в конечной точке этого туннеля (внешний агент или сам мобильный узел) и доставляются мобильному узлу (параграф 4.2.3).
В обратном направлении дейтаграммы от мобильного узла обычно доставляются получателям с использованием стандартных механизмов маршрутизации IP (не обязательно через домашнего агента).

Mobile IP предлагает два варианта получения адреса обслуживания:

Адрес внешнего агента (foreign agent care-of address) — это адрес обслуживания, предоставляемый внешним агентом в его сообщениях Agent Advertisement. В этом случае адресом обслуживания является IP-адрес внешнего агента. В этом режиме внешний агент является конечной точкой туннеля и при получении туннелированных дейтаграмм он декапсулирует их и доставляет вложенные дейтаграммы мобильному узлу. Этот режим получения адреса является предпочтительным, поскольку он позволяет множеству мобильных узлов пользоваться одним адресом обслуживания, что весьма важно в условиях дефицита адресов IPv4.
Совмещенный адрес (co-located care-of address) — это адрес обслуживания, получаемый мобильным узлом, как локальный адрес IP с помощью тех или иных внешних механизмов. Полученный адрес мобильный узел связывает с одним из своих интерфейсов. Адрес может выделяться динамически (например, через DHCP [13]) или статически на все время присутствия мобильного узла в чужой сети. Конкретные способы предоставления локальных адресов мобильным узлам для использования в качестве адресов обслуживания выходят за рамки этого документа. При использовании совмещенного адреса обслуживания мобильный узел является конечной точкой туннеля и сам выполняет декапсуляцию туннелируемых дейтаграмм.

           2) Дейтаграмма перехватывается  3) Дейтаграмма 
              домашним агентом и              детуннелируется 
              туннелируется на адрес          и доставляется
              обслуживания.                   Мобильному узлу.

                +-----+          +-------+         +------+
                |домаш| =======> |внешний| ------> |мобил.|
                |агент|          | агент | <------ | узел |
                +-----+          +-------+         +------+
1) Дейтаграмма    /|\         /
   для мобильного  |        /   4) Для переданных мобильным 
   узла приходит   |      /        узлом используется обычная
   в домашнюю сеть |    /          маршрутизация IP. На рисунке
   обычным путем.  |  |_           внешний агент является для   
                 +----+            мобильного узла маршрутизатором
                 |хост|            по умолчанию.                
                 +----+

Рисунок 1. Работа Mobile IPv4.

1.8. Расширяемость протокола и формата сообщений

1 Registration Request (запрос регистрации)

3 Registration Reply (регистрационный отклик)

Актуальные значения для типов сообщений Mobile IP указаны в документе Assigned Numbers¹ [40].

В Mobile IP используется два набора номерных пространств для значения Extension Type:

Первый набор включает расширения, которые могут включаться только в управляющие сообщения Mobile IP (передаются по протоколу UDP через порт 434). В этом документе определены три типа расширений для управляющих сообщений Mobile IP:

32 Mobile-Home Authentication;

33 Mobile-Foreign Authentication;

34 Foreign-Home Authentication.
Второй набор включает расширения, которые могут включаться только в сообщения ICMP Router Discovery [10]. Данный документ определяет три типа таки расширений:

0 One-byte Padding (однобайтовое заполнение, без полей Length и Data);

16 Mobility Agent Advertisement (анонс мобильного агента);

19 Prefix-Lengths (размеры префиксов).

В последующих параграфах более подробно рассмотрены три разных структуры для расширений Mobile IP:

простой формат;
длинный формат;
короткий формат.

1.9. Формат TLV для расширений Mobile IP

 0                   1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|     Type      |    Length     |    Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 2: Формат TLV для расширений Mobile IPv4

Type

Указывает конкретный тип расширения.

Length

Указывает размер поля данных расширения в байтах. Размер не учитывает два байта полей Type и Length.

Data

Связанные с расширением данные, формат и размер которых определяется значениями полей Type и Length.

1.10. Длинный формат расширения

Этот формат применим для непропускаемых расширений, которые могут содержать более 256 данных.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |  Sub-Type     |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Data      .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Type

Поле типа, описывающее набор однотипных расширений.

Sub-Type

Уникальный номер каждого элемента в группе расширений.

Length

Размер поля данных расширения в байтах. 4 октета полей Type, Length и Sub-Type в размере не учитываются.

Data

Данные, связанные с конкретным подтипом расширения. Структура данных в этой спецификации не задается.

16-битовое поле размера позволяет данным расширения превышать размер 256 байтов.

1.11. Короткий формат расширения

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |    Sub-Type   |    Data ....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Короткий формат требует присутствия в начале расширения перечисленных ниже полей.

Type

Поле типа, описывающее набор однотипных расширений.

Sub-Type

Уникальный номер каждого элемента в группе расширений.

Length

Data

Данные, связанные с конкретным подтипом расширения. Структура данных в этой спецификации не задается.

2. Обнаружение агента

2.1. Анонсы агента

Поля канального уровня

Destination Address

Адрес получатель на канальном уровне в индивидуальном сообщении Agent Advertisement должен совпадать с канальным адресом отправителя в сообщении Agent Solicitation, вызвавшем Advertisement.
Поля IP

TTL

Во всех сообщениях Agent Advertisement должно устанавливаться TTL = 1.

Destination Address

Как указано в [10] для сообщений ICMP Router Discovery, IP-адрес получателя группового сообщения Agent Advertisement должен быть 224.0.0.1 (все системы на канале) [11] или 255.255.255.255 (ограниченное широковещание). Широковещательный адрес подсети (subnet-directed broadcast) вида <prefix>.<-1> использовать не допустимо, поскольку мобильным узлам обычно не известен префикс чужой сети. Если сообщение Agent Advertisement передается индивидуально мобильному узлу, в качестве Destination Address следует использовать домашний IP-адрес мобильного узла.
- Поля ICMP
  
  Code
  
  Поле Code в анонсах агентов интерпретируется следующим образом:
  
  0 — агент мобильности обслуживает трафик общего назначения (т. е., действует в качестве маршрутизатора дейтаграмм IP не только мобильных узлов);
  
  16 — агент мобильности не маршрутизирует трафик общего назначения. Однако все внешние агенты должны (как минимум) пересылать используемому по умолчанию все дейтаграммы, полученные от зарегистрированного мобильного узла (параграф 4.2.2).
  
  Lifetime
  
  Максимальное время, в течение которого сообщение Advertisement считается корректным при отсутствии других анонсов.
  
  Router Address(es)
  
  Адреса, которые могут присутствовать в этой части Agent Advertisement, рассмотрены в параграфе 2.3.1.
  
  Num Addrs
  
  Число адресов маршрутизаторов, анонсируемых в этом сообщении. Отметим, что в сообщении Agent Advertisement число адресов маршрутизаторов, заданных в ICMP Router Advertisement, может быть нулевым. Дополнительная информация приведена в параграфе 2.3.1.

2.1.1. Расширение для анонсов мобильного агента

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Registration Lifetime      |R|B|H|F|M|G|r|T|   reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Care-of Addresses                        |
   |                              ...                              |

Type

Length

Sequence Number

Число сообщений Agent Advertisement, переданных с момента инициализации агента (см. параграф 2.3.2).

Registration Lifetime

Занят. Внешний агент не принимает регистрацию для дополнительных мобильных узлов.

Домашний агент. Предлагает услуги домашнего агента на канале, в который передан анонс Agent Advertisement.

Внешний агент. Предлагает услуги внешнего агента на канале, в который передан анонс Agent Advertisement.

Минимальная инкапсуляция. Агент принимает туннелированные дейтаграммы с минимальной инкапсуляцией [34].

Инкапсуляция GRE. Агент принимает туннелированные дейтаграммы с инкапсуляцией GRE [16].

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

Внешний агент поддерживает обратное туннелирование [27].

reserved

0 при передаче, игнорируется на приемной стороне.

Care-of Address(es)

2.1.2. Расширение Prefix-Lengths

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Prefix Length |      ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

19 (Prefix-Lengths Extension)

Length

N, где N — значение (возможно 0) поля Num Addrs в части ICMP Router Advertisement анонса Agent Advertisement.

Prefix Length

2.1.3. Расширение для однобайтового заполнения

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |     Type      |
   +-+-+-+-+-+-+-+-+

Type

0 (One-byte Padding Extension)

2.2. Сообщение Agent Solicitation

Сообщение Agent Solicitation идентично ICMP Router Solicitation, но поле IP TTL должно иметь значение 1.

2.3. Внешний агент и домашний агент

Агент мобильности должен ограничивать скорость передачи широковещательных и групповых сообщений Agent Advertisement; максимальную скорость следует выбирать так, чтобы анонсы не отнимали значительную часть пропускной способности сети;
мобильному агенту, получившему Router Solicitation, недопустимо требовать, чтобы в поле IP Source Address был указан адрес соседа (т. е., соответствовал подсети, связанной с одним из адресов интерфейса, через который пришло сообщение).
Агент мобильности может быть настроен на передачу сообщений Agent Advertisements только в ответ на сообщения Agent Solicitation.

2.3.1. Анонсируемые адреса маршрутизатора

Часть ICMP Router Advertisement анонса Agent Advertisement может включать один или множество адресов маршрутизаторов. Агенту следует помещать в анонс только свои собственные адреса (если они есть). Независимо от наличия его адреса в поле Router Addresses, внешний агент должен маршрутизировать дейтаграммы, полученные от зарегистрированных мобильных узлов (параграф 4.2.2).

2.3.2. Порядковые номера

2.4. Мобильный узел

2.4.1. Требование регистрации

2.4.2. Детектирование перемещений

2.4.2.1. Алгоритм 1

2.4.2.2. Алгоритм 2

2.4.3. Возвращение в домашнюю сеть

2.4.4. Порядковые номера

3. Регистрация

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

В регистрационной процедуре поддерживается ряд опциональных возможностей, доступных мобильному узлу:

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

3.1. Обзор регистрации

если мобильный узел регистрирует адрес внешнего агента, он должен делать это через данного агента;
если мобильный узел использует совмещенный адрес обслуживания и получил анонс Agent Advertisement от внешнего агента на канале, где он использует данный адрес обслуживания, мобильному узлу следует регистрироваться через данный внешний агент (или другой внешний агент на данном канале), если в полученном анонсе был установлен бит R;
в остальных случаях при использовании совмещенного адреса обслуживания мобильный узел должен регистрироваться непосредственно на своем домашнем агенте;
если мобильный узел вернулся в свою домашнюю сеть, он должен регистрироваться непосредственно на своем домашнем агенте.

мобильный узел передает Registration Request подходящему внешнему агенту для начала процесса;
внешний агент обрабатывает запрос и транслирует его домашнему агенту;
домашний агент передает Registration Reply внешнему агенту, принимая или отвергая полученный запрос;
внешний агент обрабатывает Registration Reply и транслирует его мобильному узлу для информирования того о результате рассмотрения запроса.

При регистрации непосредственно на домашнем агенте процедура требует двух сообщений:

мобильный узел передает Registration Request домашнему агенту;
домашний агент передает мобильному узлу Registration Reply, принимая или отвергая запрос.

Регистрационные сообщения, определенные в параграфах 3.3 и 3.4, используют протокол UDP³ [17]. В заголовок следует включать отличную от нуля контрольную сумму UDP, а получатель должен проверять эту сумму. Получателям следует воспринимать пакеты с нулевой контрольной суммой UDP. Поведение мобильного узла и домашнего агента в части восприятия пакетов с нулевым значением контрольной суммы UDP следует согласовывать в рамках связи Mobility Security Association между сторонами.

3.2. Аутентификация

3.3. Запрос регистрации

Поля IP

Source Address — обычно адрес интерфейса, с которого передается сообщение.

Destination Address — обычно адрес домашнего или внешнего агента.

Дополнительная информация приведена в параграфах 3.6.1.1 и 3.7.2.2.

Поля UDP

Source Port — переменное.

Destination Port — 434.

Заголовок UDP, следующий за полями Mobile IP, показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |S|B|D|M|G|r|T|x|          Lifetime             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Home Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Home Agent                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Care-of Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         Identification                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Расширения ...
+-+-+-+-+-+-+-+-

Type

1 (Registration Request)

Запрошено обратное туннелирование (см. [27]).

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

Lifetime

Home Address

IP-адрес мобильного узла.

Home Agent

IP-адрес домашнего агента мобильного узла.

Care-of Address

IP-адрес точки завершения туннеля (к мобильному узлу).

Identification

Расширения

За фиксированной частью запроса Registration Request может следовать одно или несколько расширений, описанных в параграфе 3.5. В запросы должно включаться расширение для проверки полномочий. Порядок, в котором должны следовать расширения при их включении в запросы регистрации описан в параграфах 3.6.1.3 и 3.7.2.2.

3.4. Регистрационный отклик

Поля IP

Destination Address — копируется из поля Source Address сообщения Registration Request, на которое агент отвечает.

Поля UDP

Source Port — переменный.

Destination Port — копируется из поля UDP Source Port соответствующего запроса (параграф 3.7.1).

Заголовок UDP, следующий за полями Mobile IP, показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |           Lifetime            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Home Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Home Agent                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         Identification                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-

Type

3 (Registration Reply)

Code

Значение, показывающее результат обработки Registration Request. Значения кодов приведены ниже.

Lifetime

Home Address

IP-адрес мобильного узла.

Home Agent

IP-адрес домашнего агента мобильного узла.

Identification

Extensions

Ниже приведены значения, определенные для поля Code.

Успешная регистрация

0 регистрация принята;

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

Регистрация отвергнута внешним агентом

64 причина отказа не указана;

65 административный запрет;

66 недостаточно ресурсов;

67 отказ при аутентификации мобильного узла;

68 отказ при аутентификации домашнего агента;

69 запрошенное значение Lifetime слишком велико;

70 некорректный формат сообщения Request;

71 некорректный формат сообщения Reply;

72 запрошенная инкапсуляция не поддерживается;

73 резерв (не используется);

77 недопустимый адрес обслуживания;

78 тайм-аут при регистрации;

80 домашняя сеть недоступна (получена ошибка ICMP);

81 хост домашнего агента недоступен (получена ошибка ICMP);

82 порт домашнего агента недоступен (получена ошибка ICMP);

88 домашний агент недоступен (получена другая ошибка ICMP).

Регистрация отвергнута домашним агентом

128 причина не указана;

129 административный запрет;

130 недостаточно ресурсов;

131 отказ при аутентификации мобильного узла;

132 отказ при аутентификации внешнего агента;

133 несоответствие Identification;

134 некорректный формат сообщения Request;

135 слишком много одновременных привязок мобильности;

136 не известен адрес домашнего агента.

Актуальные значения кодов приведены в свежей редакции документа Assigned Numbers [40].

3.5. Регистрационные расширения

3.5.1. Расчет значений аутентификационного расширения

данные UDP (т. е., данные Registration Request или Registration Reply);
все предшествующие расширения целиком;
поля Type, Length и SPI данного расширения.

данные UDP (т. е., данные Registration Request или Registration Reply);
все предшествующие расширения целиком;
поля Type, Length и SPI данного расширения.

3.5.2. Расширение Mobile-Home Authentication

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |         SPI  ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ... SPI (cont.)          |       Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

4 + число байтов в поле Authenticator.

SPI

Индекс параметров защиты (4 байта). Неразбираемый идентификатор (см. параграф 1.6).

Authenticator

(переменный размер) (см. параграф 3.5.1.)

3.5.3. Расширение Mobile-Foreign Authentication

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |         SPI  ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ... SPI (cont.)          |       Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

4 + число байтов в поле Authenticator.

SPI

Индекс параметров защиты (4 байта). Неразбираемый идентификатор (см. параграф 1.6).

Authenticator

(переменный размер) (см. параграф 3.5.1.)

3.5.4. Расширение Foreign-Home Authentication

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |         SPI  ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ... SPI (cont.)          |       Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

4 + число байтов в поле Authenticator.

SPI

Индекс параметров защиты (4 байта). Неразбираемый идентификатор (см. параграф 1.6).

Authenticator

(переменный размер) (см. параграф 3.5.1.)

3.6. Мобильные узлы

Если на мобильном узле не настроен домашний адрес, он может использовать расширение Mobile Node Network Access (NAI) [2] для самоидентификации и установить в поле Home Address сообщения Registration Request значение 0.0.0.0. В таких случаях мобильный узел должен быть способен присвоить себе домашний адрес после извлечения нужной информации из сообщения Registration Reply от домашнего агента.

Для каждой ожидающей регистрации мобильный узел поддерживает следующую информацию:

адрес канального уровня внешнего агента, которому было отправлено сообщение Registration Request (если такой адрес имеется),
IP Destination Address из сообщения Registration Request,
адрес обслуживания, используемый при регистрации,
значение Identification, переданное при регистрации,
запрошенное изначально значение Lifetime,
оставшееся время Lifetime для ожидающей регистрации.

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

3.6.1. Отправка регистрационных запросов

3.6.1.1. Поля IP

IP Source

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

IP Destination

Когда мобильный узел нашел агента, на котором зарегистрирован тем или иным способом, не сообщающим IP-адрес агента (например, на канальном уровне), должен указываться адрес получателя All Mobility Agents (224.0.0.11). В этом случае мобильный узел должен использовать индивидуальный адрес канального уровня для доставки дейтаграммы нужному агенту.
Когда при регистрации у внешнего агента, должен указываться его адрес, взятый из поля IP source соответствующего анонса Agent Advertisement. Это может оказаться адресом, который не анонсируется в качестве адреса обслуживания в Agent Advertisement. Кроме того, при передаче этого сообщения Registration Request мобильный узел должен использовать адрес получателя на канальном уровне, взятый из соответствующего поля анонса Agent Advertisement, где был найден IP-адрес внешнего агента.
Когда мобильный узел регистрируется напрямую у своего домашнего агента и знает его (индивидуальный) адрес IP, это адрес должен указываться в поле IP Destination.
Если мобильный узел напрямую регистрируется у домашнего агента, но не знает его адреса IP, он может использовать динамическое преобразование для автоматического определения нужного адреса IP (параграф 3.6.1.2). В этом случае в поле IP Destination помещается широковещательный адрес (subnet-directed) домашней сети мобильного узла. Такой адрес недопустимо использовать в качестве адреса получателя, если мобильный узел регистрируется через внешний агент, хотя этот адрес можно указывать в теле сообщения Registration Request при такой регистрации.

IP TTL

В поле IP TTL должно указываться значение 1, если в качестве адреса получателя используется All Mobility Agents, как указано выше. В остальных случаях задается подходящее значение в соответствии с обычной практикой IP [38].

3.6.1.2. Поля регистрационного запроса

Установленный бит D показывает, что мобильный узел будет самостоятельно декапсулировать все дейтаграммы, туннелированные на этот адрес обслуживания (совмещенный). В этом случае для пересылки мобильному узлу полученных широковещательных дейтаграмм домашний агент должен туннелировать их на адрес обслуживания. Мобильный узел детуннелирует такие дейтаграммы так же, как он делает это с дейтаграммами, адресованными непосредственно ему.
Сброшенный бит D показывает, что мобильный узел использует для обслуживания адрес внешнего агента, который будет декапсулировать дейтаграммы до их пересылки мобильному узлу. В этом случае для пересылки полученных широковещательных дейтаграмм мобильному узлу домашний агент должен инкапсулировать их в unicast-дейтаграммы, направленные по домашнему адресу мобильного узла, а потом должен туннелировать их на адрес обслуживания мобильного узла.

После декапсуляции внешним агентом внутренняя дейтаграмма будет обычной (unicast) дейтаграммой IP, адресованной мобильному узлу, что показывает внешнему агенту направление ее пересылки. Доставка ее мобильному узлу осуществляется так же, как доставляются тому обычные дейтаграммы. Мобильному узлу недопустимо декапсулировать вложенные широковещательные дейтаграммы и недопустимо для их пересылки мобильному узлу использовать локальное широковещание. Мобильный узел должен декапсулировать широковещательную дейтаграмму самостоятельно. Следовательно, для мобильного узла в таких случаях недопустима установка бита B в Registration Request, если он не способен декапсулировать дейтаграммы.

После заголовка IP следует заголовок UDP, а за ним фиксированная часть Registration Request, после которой
могут присутствовать какие-либо, не связанные с аутентификацией расширения, которые могут использоваться домашним агентом (и могут оказаться полезны внешнему агенту), а за ними
разрешающее аутентификацию расширение, после которого
могут присутствовать любые, не относящиеся к аутентификации расширения, используемые только внешним агентом, а затем
может следовать расширение Mobile-Foreign Authentication.

3.6.2. Получение регистрационных откликов

запрос был принят;
запрос был отклонен внешним агентом;
регистрация была отвергнута домашним агентом.

В оставшейся части этого раздела рассматривается обработка мобильным узлом сообщений Registration Reply каждой из трех категорий.

3.6.2.1. Проверка применимости

Отклики Registration Reply с ненулевой некорректной контрольной суммой UDP должны отбрасываться без уведомления.

Если мобильный узел и внешний агент используют защищенную связь Mobility Security Association, в отклике Registration Reply должно присутствовать в точности одно расширение Mobile-Foreign Authentication и мобильный узел должен проверить значение Authenticator в этом расширении. Если расширения Mobile-Foreign Authentication не найдено, присутствует несколько таких расширений или значение Authenticator неприемлемо, мобильный узел должен отбросить отклик без уведомления (следует также сделать запись в системном журнале о нарушении безопасности).
Если поле Code указывает, что обслуживание было отвергнуто домашним агентом или регистрация была воспринята им, в сообщении Registration Reply должно присутствовать в точности одно расширение Mobile-Home Authentication и мобильный узел должен проверить значение Authenticator в этом расширении. Если отклик был создан домашним агентом, но расширения Mobile-Home Authentication в нем не найдено, присутствует несколько таких расширений или значение Authenticator неприемлемо, мобильный узел должен отбросить отклик без уведомления (следует также сделать запись в системном журнале о нарушении безопасности).

3.6.2.2. Регистрационный запрос принят

3.6.2.3. Регистрационный запрос отвергнут

Code 69: (отвергнуто внешним агентом, запрошенное значение Lifetime слишком велико)

Code 133: (отвергнуто домашним агентом, несоответствие Identification)

Code 136: (отвергнуто домашним агентом, неизвестный адрес домашнего агента)

3.6.3. Повтор передачи при регистрации

3.7. Внешний агент

3.7.1. Таблицы конфигурации и регистрации

адрес мобильного узла на канальном уровне;
домашний IP-адрес мобильного узла или его совмещенный адрес обслуживания (см. описание бита R в параграфе 2.1.1);
IP-адрес получателя (см. параграф 3.6.1.1);
UDP-порт источника;
адрес домашнего агента;
значение поля Identification;
запрошенное значение Lifetime;
остающееся время ожидающей или действующей регистрации.

3.7.2. Получение регистрационных запросов

3.7.2.1. Проверка применимости

3.7.2.2. Пересылка применимых запросов домашнему агенту

должен обработать и удалить любые расширения, кроме предшествующих расширению, разрешающему проверку полномочий;
может добавить любое из своих не относящихся к аутентификации расширений для домашнего агента;
должен добавить в конце расширение Foreign-Home Authentication, если имеется защищенная связь с домашним агентом.

IP Source Address

Адрес внешнего агента на интерфейсе, через который будет передано сообщение.

IP Destination Address

Копируется из поля Home Agent в сообщении Registration Request.

UDP Source Port

<переменный>

UDP Destination Port

434

3.7.2.3. Отказы для недопустимых запросов

Ниже показаны значения, которые должны помещаться в поля заголовков IP и UDP для сообщений Registration Reply.

IP Source Address

IP Destination Address

UDP Source Port

434

UDP Destination Port

Копируется из поля UDP Source Port регистрационного запроса.

3.7.3. Получение регистрационных откликов

3.7.3.1. Проверка применимости

3.7.3.2. Пересылка откликов мобильному узлу

значение поля Lifetime в сообщении Registration Reply;
максимально допускаемое внешним агентом значение Lifetime.

В дополнение к этому внешнему агенту следует выполнять перечисленные ниже процедуры:

он должен обработать и удалить все расширения, не относящиеся к аутентификационным;
он может добавить в конец свои, не относящиеся к аутентификации расширения, передающие информацию мобильному узлу;
он должен добавить в коней расширение Mobile-Foreign Authentication, если имеется защищенная связь Mobility Security Association с мобильным узлом.

3.8. Домашний агент

3.8.1. Таблицы конфигурации и регистрации

домашний адрес мобильного узла;
адрес обслуживания мобильного узла;
поле Identification из сообщения Registration Reply;
остающийся срок регистрации (Lifetime).

3.8.2. Получение регистрационных запросов

3.8.2.1. Проверка применимости

Должна выполняться аутентификация сообщений Registration Request, включающая перечисленные ниже операции.

Домашний агент должен проверить наличие разрешающего аутентификацию расширения и провести указанную им аутентификацию. В сообщении Registration Request должно присутствовать в точности одно расширение, разрешающее аутентификацию, и домашний агент должен проверить значение Authenticator в этом расширении или убедиться, что оно проверено другим агентом, с которым у него имеется защищенная связь. Если разрешающего аутентификацию расширения нет или значение Authenticator не приемлемо, домашний агент должен отвергнуть регистрацию мобильного узла. Следует также отправить этому узлу сообщение Registration Reply с кодом 131. После этого домашний агент должен отбросить сообщение с запросом, о чем следует сделать запись в системном журнале.
Домашний агент должен проверять корректность поля Identification с использованием контекста, выбранного SPI в разрешающем аутентификацию расширении. Описание такой проверки приведено в параграфе 5.7. При некорректном значении поля домашний агент должен отвергнуть регистрационный запрос, а мобильному узлу следует отправить сообщение Registration Reply с кодом 133, включающее поле Identification, рассчитанное в соответствии с правилами параграфа 5.7. Домашний агент должен прекратить обработку регистрационного запроса, хотя следует сделать запись об ошибке в системный журнал.
Если у домашнего агента организована защищенная связь с внешним агентом, домашний агент должен проверить наличие подходящего расширения Foreign-Home Authentication. В этом случае в сообщении Registration Request должно присутствовать в точности одно расширение Foreign-Home Authentication и домашний агент должен проверить значение Authenticator в этом расширении. Если расширение Foreign-Home Authentication не найдено, указано несколько таких расширений или значение Authenticator не приемлемо, домашний агент должен отвергнуть регистрацию мобильного узла, которому следует вернуть сообщение Registration Reply с кодом 132. Домашний агент должен отбросить запрос, а в системный журнал следует внести запись о нарушении безопасности.

3.8.2.2. Восприятие приемлемого запроса

Если Lifetime = 0 и Care-of Address совпадает с домашним адресом мобильного узла, домашний агент удаляет для этого узла все записи из своего списка мобильных привязок, как будто мобильный узел попросил у домашнего агента прекратить обслуживание мобильности для него.
Если Lifetime = 0, а Care-of Address отличается от домашнего адреса мобильного узла, домашний агент удаляет из списка привязок мобильности только запись, содержащую указанный Care-of Address для данного мобильного узла. Все прочие активные записи для других адресов обслуживания останутся активными.
Если значение Lifetime отлично от 0, домашний агент добавляет в свой список мобильных привязок для данного мобильного узла значение Care-of Address из запроса. Если установлен бит S и домашний агент поддерживает одновременные мобильные привязки, имеющиеся в списке записи для этого узла сохраняются. В остальных случаях домашний агент удаляет из списка все имеющиеся для данного мобильного узла записи.

3.8.2.3. Отказ при недопустимом запросе

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

3.8.3. Передача регистрационных откликов

3.8.3.1. Поля IP/UDP

IP Source Address

IP Destination Address

Копируется из поля IP Source Address в сообщении Registration Request.

UDP Source Port

Копируется из поля UDP Destination Port в сообщении Registration Request.

UDP Destination Port

Копируется из поля UDP Source Port в сообщении Registration Request.

3.8.3.2. Поля регистрационного отклика

3.8.3.3. Расширения

После заголовка IP следует заголовок UDP, а за ним фиксированная часть Registration Reply, после которой
могут присутствовать какие-либо, не связанные с аутентификацией расширения, которые могут использоваться домашним агентом (и могут оказаться полезны внешнему агенту), а за ними
расширение Mobile-Home Authentication, после которого
могут присутствовать любые, не относящиеся к аутентификации расширения, используемые только внешним агентом, а затем
может следовать расширение Foreign-Home Authentication.

4. Вопросы маршрутизации

4.1. Типы инкапсуляции

4.2. Маршрутизация индивидуальных дейтаграмм

4.2.1. Мобильный узел

Если мобильный узел регистрируется с использованием адреса внешнего агента, он может применять этот адрес в качестве адреса первого маршрутизатора. MAC-адрес внешнего агента можно узнать из сообщения Agent Advertisement. В остальных случаях мобильный узел должен выбрать используемый по умолчанию маршрутизатор из числа Router Addresses, анонсируемых в разделе ICMP Router Advertisement сообщений Agent Advertisement.
Если мобильный узел регистрируется у домашнего агента, используя совмещенный адрес обслуживания, ему следует выбрать используемый по умолчанию маршрутизатор из числа анонсируемых в принятых им сообщениях ICMP Router Advertisement тот адрес, который будет соответствовать полученному извне адресу обслуживания и Router Address по префиксам. Если полученный мобильный узлом извне адрес обслуживания соответствует по префиксу адресу отправителя Agent Advertisement, мобильный узел может рассмотреть этот адрес при выборе маршрутизатора по умолчанию. Префикс сети может быть получен из Prefix-Lengths Extension в сообщении Router Advertisement (если оно используется). Префикс можно также получить с использованием иных механизмов, не рассматриваемых в данном документе.

4.2.2. Внешний агент

Каждому внешнему агенту следует поддерживать функции, обязательные для реверсного туннелирования [27].

4.2.3. Домашний агент

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

4.3. Широковещательные дейтаграммы

4.4. Маршрутизация групповых дейтаграмм

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

Переносный компьютер отключается от домашней сети и позднее подключается к сети на борту самолета. Этот компьютер использует Mobile IP для регистрации в чужой сети, используя для обслуживания адрес внешнего агента, найденный из сообщения Agent Advertisement от внешнего агента на борту самолета.
Сеть самолета сама по себе является мобильной. Предположим, что узел, являющийся бортовым внешним агентом, служит также используемым по умолчанию маршрутизатором, который соединяет бортовую сеть с сетью Internet. Когда самолет находится «дома», этот маршрутизатор подключается к некой стационарной сети в аэропорту, которая для этого маршрутизатора является домашней. Когда самолет находится в воздухе, маршрутизатор время от времени регистрируется через радиоканал на внешних агентах, расположенных на земле по маршруту полета. Домашний агент этого мобильного маршрутизатора располагается в стационарной сети «домашнего» аэропорта.
Некий узел-корреспондент отправляет дейтаграмму на переносный компьютер, адресуя ее на домашний адрес этого компьютера. Изначально эта дейтаграмма маршрутизируется в домашнюю сеть переносного компьютера.
Домашний агент переносного компьютера перехватывает дейтаграмму в домашней сети и туннелирует ее на адрес обслуживания переносного компьютера, которым в данном случае является адрес узла, служащего маршрутизатором и внешним агентом на борту самолета. Обычная маршрутизация IP будет направлять дейтаграмму в стационарную сеть авиакомпании.
Домашний агент бортового маршрутизатора и внешнего агента перехватывает дейтаграмму и туннелирует ее на текущий адрес обслуживания, которым в этом примере является некий внешний агент в наземной сети под самолетом. Исходная дейтаграмма будет инкапсулирована дважды — домашним агентом переносного компьютера и домашним агентом бортового маршрутизатора.
Внешний агент в наземной сети декапсулирует дейтаграмму, сохраняя инкапсуляцию домашнего агента переносного компьютера (внутреннюю) и получателем декапсулированной дейтаграммы будет адрес обслуживания переносного компьютера. Полученная в результате дейтаграмма будет передана по радиоканалу на борт самолета.
Внешний агент на борту декапсулирует дейтаграмму, извлекая из нее исходную дейтаграмму от узла-корреспондента, направленную по домашнему адресу переносного компьютера. Внешний агент бортовой сети самолета доставит эту дейтаграмму через бортовую сеть по адресу канального уровня в переносной компьютер.

4.6. ARP, Proxy ARP и Gratuitous ARP

Proxy ARP [39] представляет собой отклик ARP, передаваемый узлом от имени другого узла, который не способен или не хочет сам отвечать на запросы ARP. Отправитель Proxy ARP меняет местами поля Sender и Target Protocol Address, как описано в [36], и подставляет некий заданный в конфигурации (обычно, свой) адрес канального уровня в поле Sender Hardware Address. Получатель такого отклика будет связывать указанный в нем адрес канального уровня с IP-адресом исходного искомого узла, что приведет к отправке в будущем адресованных целевому узлу пакетов на узел с указанным в отклике адресом канального уровня.
Gratuitous ARP [45] представляет собой пакет ARP, переданный узлом для того, чтобы спонтанно вызвать на других узлах обновление записи в их кэше ARP. Для беспричинного ARP могут использоваться пакеты ARP Request или ARP Reply. В любом случае в полях ARP Sender Protocol Address и ARP Target Protocol Address устанавливается IP-адрес, для которого нужно обновить запись, а в поле ARP Sender Hardware Address — адрес канального уровня, который следует указать в обновленной записи. При использовании пакетов ARP Reply в поле Target Hardware Address также устанавливается адрес канального уровня, для которого следует обновить запись в кэше (это поле не используется в пакетах ARP Request).

В любом случае для беспричинного ARP пакеты ARP должны передаваться, как локальные широковещательные пакеты на локальном канале. Как указано в [36], любой узел, получивший пакет ARP (Request или Reply), должен обновить свой локальный кэш ARP, взяв аппаратный и протокольный адрес из пакета ARP, если в кэше имеется запись для указанного в пакете адреса IP. Это требование в протоколе ARP применяется даже для пакетов ARP Request и пакетов ARP Reply, не соответствующих каким-либо отправленным этим узлом пакетам ARP Request [36].

Мобильный принимает решение о регистрации за пределами домашней сети (возможно в результате приема Agent Advertisement от внешнего агента и отсутствие свежих анонсов от домашнего агента).
Перед отправкой Registration Request отключает у себя обработку будущих сообщений ARP Request, которые могут запрашивать адрес канального уровня для его домашнего адреса, за исключением тех, которые нужны для взаимодействия с внешними агентами в чужой сети.
Мобильный узел передает Registration Request.
Когда домашний агент мобильного узла получает и воспринимает Registration Request, он отправляет беспричинный пакет ARP от имени мобильного узла и начинает использование proxy ARP для ответа на сообщения ARP Request, запрашивающие адрес канального уровня мобильного узла. В беспричинных пакетах ARP поле ARP Sender Hardware Address содержит адрес домашнего агента на канальном уровне. Если же домашний агент отвергает сообщение Registration Request, он не выполняет какой-либо обработки ARP (беспричинных или proxy).

Мобильный принимает решение о регистрации в домашней сети (возможно в результате приема Agent Advertisement от домашнего агента).
Перед отправкой Registration Request включает у себя обработку будущих сообщений ARP Request, которые могут запрашивать адрес канального уровня для его домашнего адреса.
Мобильный узел передает беспричинный пакет ARP, указывая в поле ARP Sender Hardware Address свой адрес канального уровня.
Мобильный узел передает Registration Request.
Когда домашний агент мобильного узла получает и воспринимает Registration Request, он прекращает использование proxy ARP для ответа на сообщения ARP Request с запросом адреса канального уровня для мобильного узла и передает беспричинный пакет ARP от имени мобильного узла, указывая в поле ARP Sender Hardware Address адрес канального уровня этого узла. Если домашний агент отвергает Registration Request, ему недопустимо вносить какие-либо изменения в обработку ARP (беспричинных или proxy) для этого узла. В этом последнем случае домашнему агенту следует вести себя, как будто мобильный узел не возвращался в домашнюю сеть и продолжать использование proxy ARP от имени мобильного узла.

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

5.1. Коды аутентификации сообщений

5.2. Вопросы безопасности, связанные с этим протоколом

5.3. Управление ключами

5.4. Выбор случайных чисел

5.5. Конфиденциальность

5.6. Фильтрация на входе

5.7. Защита от повторного использования для Registration Request

5.7.1. Защита от повторного использования с помощью временных меток

5.7.2. Защита от повторного использования с помощью Nonce

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

Сообщения Mobile IP разных типов, передаваемые в порт UDP 434, как указано в параграфе 1.8.
Типы расширений для сообщений Registration Request и Registration Reply (см. параграфы 3.3 и 3.4, а также [27, 29, 6, 7, 12]).
Значения кодов (Code) для сообщений Registration Reply (см. параграф 3.4, а также [27, 29, 6, 7, 12]).
В Mobile IP определены сообщения Agent Solicitation и Agent Advertisement. Фактически они относятся к сообщениям Router Discovery [10], дополненным специфическими расширениями Mobile IP. Таким образом, для этих сообщений не требуется новое пространство имен, но нужно определить расширения для Router Discovery, как описано ниже в параграфе 6.2 (см. параграф 2.1 и работы [7, 12].

Дополнительные пространства значений для Mobile IP указаны в [7].

6.1. Типы сообщений Mobile IP

Тип	Название	Описание
1	Registration Request	3.3
3	Registration Reply	3.4

6.2. Расширения для RFC 1256 Router Advertisement

Тип	Название	Описание
0	One-byte Padding	2.1.3
16	Mobility Agent Advertisement	2.1.1
19	Prefix-Lengths	2.1.2

6.3. Расширения для регистрационных сообщений Mobile IP

Тип	Название	Описание
0	One-byte Padding
32	Mobile-Home Authentication	3.5.2
33	Mobile-Foreign Authentication	3.5.3
34	Foreign-Home Authentication	3.5.4

6.4. Коды для регистрационных откликов Mobile IP

0-8	Коды успешного завершения
09-63	В настоящее время нет рекомендаций по распределению
64-127	Коды ошибок от внешнего агента
128-192	Коды ошибок от домашнего агента
193-255	В настоящее время нет рекомендаций по распределению

Выделение новых значений для кодов происходит по процедуре Expert Review [30].

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

— Ran Atkinson (Naval Research Lab),

— Samita Chakrabarti (Sun Microsystems)

— Ken Imboden (Candlestick Networks, Inc.)

— Dave Johnson (Carnegie Mellon University),

— Frank Kastenholz (FTP Software),

— Anders Klemets (KTH),

— Chip Maguire (KTH),

— Alison Mankin (ISI)

— Andrew Myles (Macquarie University),

— Thomas Narten (IBM)

— Al Quirt (Bell Northern Research),

— Yakov Rekhter (IBM), and

— Fumio Teraoka (Sony).

— Alper Yegin (NTT DoCoMo)

— Mohamed M.Khalil, Nortel Networks

— Raja Narayanan, nVisible Networks

— Haseeb Akhtar, Nortel Networks

— Emad Qaddoura, Nortel Networks

A. Патенты

B. Канальный уровень

C. Вопросы TCP

C.1. Таймеры TCP

C.2. Контроль насыщения TCP

D. Примеры

В этом приложении приведены примеры сообщений Registration Request для нескольких типичных случаев.

D.1. Регистрация с адресом внешнего агента

Поля IP

Source Address = домашний адрес мобильного узла;

Destination Address = копируется адрес отправителя из сообщения Agent Advertisement;

Time to Live = 1.

Поля UDP

Source Port = <любой>;

Destination Port = 434;

Поля Registration Request

Type = 1;

S=0,B=0,D=0,M=0,G=0;

Lifetime = значение Registration Lifetime копируется из Mobility Agent Advertisement Extension сообщения Router Advertisement;

Home Address = домашний адрес мобильного узла;

Home Agent = IP-адрес домашнего агента мобильного узла;

Care-of Address = копируется из Mobility Agent Advertisement Extension сообщения Router Advertisement;

Identification = временная метка NTP или Nonce.

Расширения

Разрешающее проверку полномочий расширение (например, Mobile-Home Authentication Extension).

D.2. Регистрация с совмещенным адресом обслуживания

Поля IP

Source Address = адрес обслуживания, полученный от сервера DHCP;

Destination Address = IP-адрес домашнего агента;

Time to Live = 64.

Поля UDP

Source Port = <любой>;

Destination Port = 434.

Поля Registration Request

Type = 1;

S=0,B=1,D=1,M=1,G=1;

Lifetime = 1800 (секунд);

Home Address = домашний адрес мобильного узла;

Home Agent = IP-адрес домашнего агента мобильного узла;

Care-of Address = адрес обслуживания, полученный от сервера DHCP;

Identification = временная метка NTP или Nonce.

Расширения

Mobile-Home Authentication Extension.

D.3. Дерегистрация

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

Поля IP

Source Address = домашний адрес мобильного узла;

Destination Address = IP-адрес домашнего агента мобильного узла;

Time to Live = 1.

Поля UDP

Source Port = <любой>;

Destination Port = 434.

Поля Registration Request

Type = 1:

S=0,B=0,D=0,M=0,G=0;

Lifetime = 0;

Home Address = домашний адрес мобильного узла;

Home Agent = IP-адрес домашнего агента мобильного узла;

Care-of Address = домашний адрес мобильного узла;

Identification = временная метка NTP или Nonce.

Расширения

Разрешающее проверку полномочий расширение (например, Mobile-Home Authentication Extension).

E. Применимость расширения Prefix-Lengths

F. Вопросы совместимости

клиент, ожидающий той или иной из ставших в новой спецификации обязательными функций (например, реверсного туннелирования) от внешнего агента, не будет сталкиваться с проблемами взаимодействия, если он принимает во внимание значение флага T;
мобильные узлы, использующие для идентификации самих себя расширение NAI, не смогут взаимодействовать со старыми агентами мобильности;
мобильные узлы, использующие нулевое значение для домашнего адреса и желающие получить свой домашний адрес в сообщении Registration Reply, не смогут взаимодействовать со старыми агентами мобильности;
мобильные узлы, пытающиеся аутентифицировать себя без использования расширения Mobile-Home, не смогут зарегистрироваться у своего домашнего агента.

G. Отличия от RFC 2002

G.1. Основные изменения

Спецификация для адреса Destination IP в сообщениях Registration Reply от внешнего агента для предотвращения возможности передачи IP-адреса 0.0.0.0.
Спецификация двух новых типов расширений Mobile IP в соответствии с идеями MIER.
Указано использование SPI аутентификационного расширения MN-HA, как части данных, к которым должен применяться алгоритм аутентификации.
Отказ от поддержки сжатия Van-Jacobson.
Указано, что внешние агенты могут передавать анонсы чаще одного раза в секунду при условии, что они не будут занимать слишком большую часть полосы локального канала. Для простоты принимается, что внешний агент может передавать анонсы с интервалом в 1/3 анонсируемого значения ICMP Lifetime.
Указано, что внешним агентам следует поддерживать реверсное туннелирование, а домашние агенты должны поддерживать декапсуляцию таких туннелей.
Изменены требования параграфа 3.6 для мобильных узлов с целью отражения определенной в RFC 2794 [6] возможности мобильного узла идентифицировать самого себя с использованием NAI и получить домашний адрес из сообщения Registration Reply.
В параграф 3.7.3.1 внесены изменения, в соответствии с которыми от внешнего агента не требуется отбрасывать сообщения Registration Reply, где поле Home Address не соответствует ни одному из ожидающих сообщений Registration Request.
Разрешена аутентификация регистрации с использованием защищенных связей между мобильным узлом и подходящим агентом аутентификации, приемлемым для домашнего агента. Определено расширение Authorization-enabling для аутентификации, которое делает регистрационное сообщение воспринимаемым для получателя. Это требуется в соответствии со спецификацией [6].
Задано обязательное использование HMAC-MD5 взамен режима MD5 prefix+suffix, указанного в RFC 2002.
Указано, что мобильному узлу следует брать первый адрес из упорядоченного списка, предложенного внешним агентом, и можно пробовать все последующие анонсированные адреса, если попытка регистрации была отвергнута внешним агентом.
Разъяснено, что агентам мобильности следует помещать только свой собственный адрес с начальный (не связанный с мобильностью) список маршрутизаторов в анонсах мобильности. RFC 2002 разрешал агентам мобильности анонсировать другие маршрутизаторы для использования по умолчанию.
Указано, что мобильный узел должен игнорировать резервные биты в сообщениях Agent Advertisement, не отбрасывая самих сообщений. В этом случае, определенные позднее биты не помешают мобильным узлам использовать анонсы, несмотря на наличие непонятных битов. Кроме того, внешние агенты могут устанавливать бит R для указания того, что они сами обрабатывают новые биты, вместо не понимающих эти биты агентов мобильности.
Указано, что внешний агент проверяет указанный адрес домашнего агента на предмет (не)принадлежности к какому-либо из интерфейсов внешнего агента до трансляции сообщения Registration Request. Если указанный адрес относится к одной из сетей внешнего агента и этот агент не является домашним для мобильного узла, запрос отвергается с возвратом кода 136 (неизвестный адрес домашнего агента).
Указано, что находящемуся вне домашней сети мобильному узлу недопустимо передавать широковещательные пакеты ARP для определения MAC-адреса другого узла Internet. Таким образом, список (возможно пустой) Router Addresses из компоненты ICMP Router Advertisement в сообщении бесполезен для выбора используемого по умолчанию маршрутизатора, если у мобильного узла нет какого-либо способа получить MAC-адрес одного из маршрутизаторов в этом списке без применения широковещательных пакетов. Аналогично, в отсутствие механизмов определения MAC-адресов в чужой сети мобильный узел должен игнорировать все другие маршрутизаторы в чужой сети.
Указано, что внешнему агенту недопустимо использовать широковещательные пакеты ARP для MAC-адреса мобильного узла в чужой сети. Он может получить этот адрес, копируя информацию из сообщения Agent Solicitation или Registration Request переданного мобильным узлом.
Указано, что запись в кэше ARP внешнего агента для IP-адреса мобильного узла недопустимо считать устаревшей, пока у внешнего агента нет какого-либо способа обновить связанный с IP-адресом мобильного узла MAC-адрес без использования широковещания ARP.
В конце параграфа 4.6 разъяснено, что домашнему агенту недопустимо как-то изменять способ выполнения им proxy ARP после того, как он отверг неприемлемый запрос на отмену регистрации.
В параграфе 4.2.3 указано, что многодомные домашние агенты должны использовать адрес, переданный мобильному узлу в поле Home Agent регистрационного отклика, должен использоваться в качестве адреса отправителя во внешнем заголовке IP инкапсулированных дейтаграмм.
Добавлен бит T в соответствующую позицию сообщений Registration Request (параграф 3.3).

G.2. Второстепенные изменения

Мобильным узлам разрешена обработка регистрационных откликов даже при отсутствии расширения Mobile-Home Authentication, если в отклике содержится код отказа от внешнего агента.
Указано, что внешний агент может задавать максимальное число ожидающих регистраций, которые он готов поддерживать (обычно 5). В этом случае агенту следует отвергать избыточные регистрации с возвратом кода 66. Внешний агент может удалять любые ожидающие сообщения Registration Request, ожидающие регистрации более 7 секунд; в этом случае агенту следует возвращать код 78 (тайм-аут при регистрации).
Ослаблено требование, по котором мобильный узел должен был использовать свой домашний адрес в поле отправителя в заголовке IP для групповых пакетов при участии мобильного узла в multicast-группе на маршрутизаторе чужой сети.
Отмечено, что агент мобильности может использовать разные наборы битов R, H и F для разных сетевых интерфейсов.
Термин «рекурсивное туннелирование» заменен термином «вложенное туннелирование».
Указано, что мобильный узел может использовать адрес отправителя из анонса агента в качестве маршрута по умолчанию.
Отмечено, что ключи с произвольными двоичными значениями должны поддерживаться для защищенных связей.
Указано, что в качестве значения по умолчанию можно выбирать 7 секунд для того, чтобы скомпенсировать рассогласование часов домашнего агента и мобильного узла при использовании временных меток для защиты от повторного использования. Дополнительно указано, что для этого параметра следует выбирать значение более 3 секунд.
Указано, что сообщения Registration Request с битом D=0, задающие адрес обслуживания, который не предлагается внешним агентом, должны отвергаться с возвратом кода 77 (неприемлемый адрес обслуживания).
Отмечено, что внешним агентам следует принимать во внимание свое максимальное значение при обработке полей Lifetime в сообщениях Registration Reply.
Отмечено, что домашний агент должен игнорировать бит B (а не отвергать сообщение Registration Request), если он не поддерживает широковещания.
Разъяснено, что сообщение Agent Advertisement адресовано индивидуально мобильному узлу, конкретный домашний IP-адрес мобильного узла может использоваться в качестве IP-адреса получателя.
Включена ссылка на RFC 2290 с Приложением B, где рассмотрена работа с PPP.
Добавлен раздел согласование с IANA (IANA Considerations.
В параграфе 3.8.3 пояснено, что домашнему агенту следует организовать выбор домашнего адреса для мобильного узла в тех случаях, когда сообщение Registration Reply содержит нулевое значение Home Address.

G.3. Изменения по сравнению с ревизией 04 RFC2002bis

отмечено, что следует рассмотреть использование HMAC-MD5 взамен режима «prefix+suffix» MD5, изначально заявленного в RFC 2002;
включена ссылка на RFC 2290 с Приложением B, где рассмотрена работа с PPP;
переписан раздел Согласование с IANA;
переписан раздел Обновления;
раздел Патенты (Patents) заменен в соответствии с RFC 2026;
обновлены цитаты.

H. Примеры сообщений

H.1. Пример формата сообщения ICMP Agent Advertisement

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Num Addrs   |Addr Entry Size|           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Router Address[1]                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Preference Level[1]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Router Address[2]                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Preference Level[2]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ....                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 16   |     Length    |      Sequence Number          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Registration Lifetime         |R|B|H|F|M|G|r|T|  reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Care-of Address[1]                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Care-of Address[2]                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         ....                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                   Необязательные расширения                   :
   :   ....                ......                      ......      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H.2. Пример формата сообщения Registration Request

После заголовка UDP следуют поля Mobile IP, как показано ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type = 1  |S|B|D|M|G|r|T|x|          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Необязательные расширения без аутентификации для HA ...    |
   |                     (переменный размер)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type =32   |      Length   |           SPI                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SPI (продолж.)       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   :         MN-HA Authenticator (переменный размер)               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :    Необязательные расширения без аутентификации для FA .......
   :    Необязательное расширение MN-FA Authentication  ...........
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H.3. Пример формата сообщения Registration Reply

После заголовка UDP следуют поля Mobile IP, как показано ниже.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 3    |     Code      |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Необязательные расширения без аутентификации для HA ...    |
   |                     (переменный размер)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type =32   |      Length   |           SPI                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SPI (продолж.)       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   :         MN-HA Authenticator (переменный размер)               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :    Необязательные расширения без аутентификации для FA .......
   :    Необязательное расширение MN-FA Authentication  ...........
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Литература

[1] Allman, M., Glover, D. and L. Sanchez, «Enhancing TCP Over Satellite Channels using Standard Mechanisms», BCP 28, RFC 2488, January 1999.

[2] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. ACM Computer Communications Review, 19(2), March 1989.

[3] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, «Performance Enhancing Proxies», RFC 3135, June 2001.

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