Формат сообщений Path

Сообщения Path имеют следующий формат:

<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[<EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[<SESSION_ATTRIBUTE> ]
[<DIFFSERV> ]
[<POLICY_DATA> ... ]
[<sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[<ADSPEC> ]
[<RECORD_ROUTE> ]

Формат сообщений RSVP, связанных с Diff-Serv

В данном документе определен один новый объект RSVP: DIFFSERV. Подробное описание этого объекта представлено ниже. Этот новый объект применим к сообщениям Path. Данная спецификация определяет только использование объекта DIFFSERV в сообщениях Path, предназначенных для установления туннелей LSP в соответствии [RSVP_MPLS_TE], и, таким образом, содержащих объект Session с C-Type равным LSP_TUNNEL_IPv4 и объект LABEL_REQUEST.

Ограничения, определенные в [RSVP_MPLS_TE] для поддержки установления туннелей LSP с помощью RSVP, применимы для формирования туннелей LSP, поддерживающих Diff-Serv: например, поддерживаются только уникастные LSP, а мультикастные будут рассмотрены позднее.

Этот новый объект DIFFSERV является опционным с точки зрения RSVP, для того чтобы реализации RSVP, несвязанные с формированием MPLS LSP не должны поддерживать этот объект.

Объект DIFFSERV является опционным для поддержки туннелей LSP, как это определено в [RSVP_MPLS_TE]. LSR, способный поддерживать Diff-Serv E-LSP, использующий предварительно сконфигурированные таблицы EXP<-->PHB в согласии с этой спецификацией может поддерживать объект DIFFSERV. LSR, способный поддерживать Diff-Serv E-LSP, использующий согласованную таблицу EXP<-->PHB, в согласии с этой спецификацией должен поддерживать объект DIFFSERV. LSR, способный поддерживать Diff-Serv L-LSP, в согласии с этой спецификацией должен поддерживать объект DIFFSERV.

Форматы, относящиеся к меткам

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

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

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

Форматы сообщений RSVP

В этом разделе описаны форматы сообщений RSVP. Там где они отличаются, форматы для однонаправленных LSP представлены отдельно от двунаправленных LSP. MESSAGE_ID и сопряженные объекты определены в [RFC2961]. Формат сообщения Path представлен ниже:

<Path Message> ::= <Common Header> [ <INTEGRITY> ]

[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]

[ <MESSAGE_ID> ]

<TIME_VALUES>

[ <EXPLICIT_ROUTE>]

<LABEL_REQUEST>

[ <PROTECTION>]

[ <LABEL_SET>... ]

[ <SESSION_ATTRIBUTE>]

[ <NOTIFY_REQUEST>]

[ <ADMIN_STATUS>]

[ <POLICY_DATA>... ]

Формат дескриптора отправителя для однонаправленного LSP имеет вид:

[ <ADSPEC>]

[ <RECORD_ROUTE>]

[ <SUGGESTED_LABEL>]

[ <RECOVERY_LABEL> ]

Формат дескриптора отправителя для двунаправленного LSP имеет вид:

[ <ADSPEC>]

[ <RECORD_ROUTE>]

[ <SUGGESTED_LABEL>]

[ <RECOVERY_LABEL>]

<UPSTREAM_LABEL>

Формат сообщения PathErr имеет вид:

<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]

[ [<MESSAGE_ID_ACK>| <MESSAGE_ID_NACK>] ... ]

[ <MESSAGE_ID>]

[ <ACCEPTABLE_LABEL_SET>... ]

[ <POLICY_DATA>... ]

Формат сообщения Resv имеет вид:

<Resv Message> ::= <Common Header> [ <INTEGRITY> ]

[ [<MESSAGE_ID_ACK>| <MESSAGE_ID_NACK>] ... ]

[ <MESSAGE_ID>]

<TIME_VALUES>

[ <RESV_CONFIRM>] [ <SCOPE> ]

[ <NOTIFY_REQUEST>]

[ <ADMIN_STATUS>]

[ <POLICY_DATA>... ]

<flow descriptor list> в данном документе не модифицировался.

Формат сообщения ResvErr имеет вид:

<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]

[[<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]

[<MESSAGE_ID> ]

<ERROR_SPEC> [ <SCOPE> ]

[<ACCEPTABLE_LABEL_SET> ... ]

[<POLICY_DATA> ... ]

Формат модифицированного сообщения Hello имеет вид:

[<RESTART_CAP> ]

Форматы сообщений, связанные с LSP туннелями

Пять новых объектов определено в данном разделе:

Имя объектаПрименимые RSVP-сообщенияLABEL_REQUESTPathLABELResvEXPLICIT_ROUTEPathRECORD_ROUTEPath, ResvSESSION_ATTRIBUTEPath

Новые C-типы присваиваются также объектам SESSION, SENDER_TEMPLATE и FILTER_SPEC.

Подробные описания новых объектов представлены в последующих разделах. Все новые объекты являются с точки зрения RSVP опционными. Реализация может выбрать поддержку некоторого субнабора объектов. Однако объекты LABEL_REQUEST и LABEL в рамках данного документа являются обязательными.

Объекты LABEL и RECORD_ROUTE являются специфическими для отправителя. В сообщениях Resv они должны появляться после FILTER_SPEC и до любой последующей спецификации FILTER_SPEC.

Относительное положение объектов EXPLICIT_ROUTE, LABEL_REQUEST и SESSION_ATTRIBUTE является лишь рекомендацией. Порядок размещения этих объектов не важно, так что программная реализация должна быть готова воспринимать объекты в любом порядке.

Форматы специфических объектов COPS

Все объекты имеют один и тот же формат; каждый объект состоит из одного или более 32-битных слов с 4-октетным заголовком. Формат показан на рисунке:

0	1	2	3
Длина (октеты)		C-Num	C-Type
(Содержимое объекта)

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

Обычно, C-Num идентифицирует класс информации в объекте, а C-тип идентифицирует субтип или версию информации, содержащейся в объекте.

C-num: 8 бит

1	Дескриптор (Handle)
2	Контекст
3	Входной интерфейс
4	Выходной интерфейс
5	Код причины
6	Решение
7	LPDP решение
8	Ошибка
9	Специфические данные клиента
10	Таймер Keep-Alive
11	Идентификация PEP
12	Тип отчета
13	Адрес переадресации PDP
14	Последний PDP-адрес
15	Таймер аккоунтинга
16	Целостность сообщения

C-type: 8 бит. Значения, определенные для C-num.

Формирование таблицы PHB-->Encaps для исходящего E-LSP

В этом разделе определено, как устанавливается соответствие PHB-->Encaps в контексте Diff-Serv для исходящего E-LSP, для того чтобы сформировать данные Diff-Serv на уровне инкапсуляции.

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

-->

E. Rosen. RFC-2547, March 1999 (Перевод Семенова Ю.А.)

Аннотация

Описан метод, с помощью которого, например, сервис провайдер на IP опорной сети, может организовать для клиентов частные виртуальные сети (VPN). MPLS (мультипротокольная коммутация пакетов по меткам - Multiprotocol Label Switching) используется для переадресации пакетов по опорной сети, а BGP (Border Gateway Protocol) служит для прокладки маршрутов через опорную сеть. Главной целью метода является поддержка внешних опорных IP сетей, предлагающих услуги корпоративным сетям. Это делается достаточно просто для предприятия, сохраняя гибкость и масштабируемость для сервис провайдеров. Данная технология может быть также использована, чтобы формировать VPN , которая сама предоставляет IP-услуги клиентам.

1. Введение

1.1. Частные виртуальные сети

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

Субнаборы, которые создаются, являются "Частными виртуальными сетями" (VPN). Два сайта имеют IP коннективность через опорную сеть, только если существует VPN, которая содержит в себе оба эти сайта. Два сайта, которые не имеют общих VPN, не имеют связи через опорную сеть.

Если все сайты в VPN принадлежат одной и той же компании, VPN является корпоративной "интранет". Если разные сайты в VPN принадлежат различным компаниям, VPN считается "экстранетом". Сайт может состоять в более чем одной VPN, например, интранет и несколько экстранетов. Будем рассматривать интранеты и экстранеты, как VPN. Вообще, при использовании термина VPN в дальнейшем не будет делаться различия между интранетами и экстранетами.

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

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

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

1.2. Оконечные устройства

Предполагается, что на каждом сайте имеется одно или более оконечное устройство клиента CE (Customer Edge), каждое из которых подключено через какой-то канал (например, PPP, ATM, Ethernet, Frame Relay, GRE-туннель, и т.д.) к одному или более оконечному маршрутизатору провайдера PE (Provider Edge).

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

Будем говорить, что PE-маршрутизатор подключен к определенной VPN, если он подключен к оконечному устройству CE, которое находится в VPN. Аналогично, будем считать, что маршрутизатор PE подключен к определенному сайту, если он подсоединен к устройству CE, которое находится в пределах этого сайта. Когда в качестве CE выступает маршрутизатор, он является маршрутным партнером PE, к которому подключен, но не является маршрутным партнером CE-маршрутизаторов в других сайтах. Маршрутизаторы в различных сайтах непосредственно не обмениваются маршрутной информацией. В действительности, они даже могут не знать о существовании друг друга (за исключением случая, когда это необходимо из соображений безопасности, смотри раздел 9). Как следствие, очень большие VPN (т.e., VPN с большим числом сайтов) хорошо поддерживаются, в то же время маршрутные стратегии каждого индивидуального сайта существенно упрощаются.

Важно сохранять четкие административные границы между SP и их клиентами [4]. Маршрутизаторы PE и P должны администрироваться SP, а клиенты SP не должны иметь доступа к их управлению. Устройства CE должны управляться клиентом (если только клиент не заключил соглашение с SP).

1.3. VPN с перекрывающимися адресными пространствами

1.4. VPN с разными маршрутами до одной и той же системы

Хотя сайт может находиться в нескольких VPN, не обязательно маршрут к данной системе в сайте будет тем же, что для всех прочих VPN. Предположим, например, что имеется интранет, состоящий из сайтов A, B и C, а также экстранет, включающий в себя A, B, C и “чужой" сайт D. Будем считать, что сайт A является сервером, и мы хотим предоставить клиентам из B, C или D доступ к этому серверу. Предположим также, что сайт B является файерволом. Мы хотим, чтобы весь трафик из сайта D к серверу проходил через файервол, так что может контролироваться доступ трафика из экстранета. Однако мы не хотим, чтобы трафик от C проходил через firewall на пути к серверу, поскольку это трафик интранет.

Это означает, что нужно конфигурировать два маршрута к серверу. Один маршрут, используемый сайтами B и C, организует трафик к сайту A. Второй маршрут, используемый сайтом D, формирует трафик через firewall сайта B. Если firewall позволяет проходить трафику, он затем рассматривается как трафик, приходящий из сайта B, и следует маршрутом до узла A.

1.5. Таблицы переадресации в PE

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

1.6. Маршрутизаторы опорной сети SP

Опорная сеть SP состоит из PE-маршрутизаторов, а также их других маршрутизаторов (P-маршрутизаторы), которые не подключены к CE устройствам.

Если каждый маршрутизатор в опорной сети SP должен поддерживать маршрутную информацию для всех VPN, поддерживаемых SP, такая модель будет иметь серьезные проблемы с масштабируемостью. Число поддерживаемых сайтов, будет лимитировано объемом маршрутной информации, хранимой одним маршрутизатором. Важно, следовательно, потребовать, чтобы маршрутная информация о конкретном VPN присутствовала только в тех PE-маршрутизаторах, которые соединены с этой VPN. В частности, P-маршрутизаторы не должны иметь какой-либо маршрутной информации о любых VPN.

VPN может пользоваться услугами нескольких сервис-провайдеров. Предполагается, что когда путь между PE-маршрутизаторами пересекает границу между сетями SP, это делается согласно пиринговому соглашению, в рамках которого существует договоренность между двумя провайдерами. В частности, каждый провайдер должен доверять друг другу пересылку только корректной маршрутной информации, и передавать ее, в помеченных (в значении MPLS [9]) пакетах, только если эти пакеты были помечены отправителями, достойными доверия. Предполагается, что для маршрутов, коммутируемых по меткам, разрешается пересекать границы между сервис провайдерами.

2. Сайты и CE

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

CE-устройства всегда рассматриваются принадлежащими одному сайту (хотя как мы это увидим, сайт может состоять из множества "виртуальных сайтов"). Сайт, однако, может принадлежать многим VPN.

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

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

3. Таблицы переадресации сайта в PE

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

Как заполняются таблицы переадресации сайтов?

В качестве примера, пусть PE1, PE2 и PE3 являются PE-маршрутизаторами, и пусть CE1, CE2 и CE3 являются CE-маршрутизаторами. Предположим, что PE1 узнает, от CE1 маршруты, которые достижимы в сайте CE1. Если PE2 и PE3 подключены соответственно к CE2 и CE3 и имеется VPN V, содержащая CE1, CE2 и CE3, тогда PE1 использует BGP для посылки маршрутной информации PE2 и PE3, которую он получил от CE1. PE2 и PE3 используют эти маршруты для заполнения таблиц переадресации, которые ассоциируются ими с сайтами CE2 и CE3, соответственно. Маршруты из сайтов, которые находятся вне VPN V, не заносятся в эти таблицы, поэтому пакеты от CE2 или CE3 не могут быть посланы сайтам, которые не принадлежат VPN V.

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

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

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

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

(a) метка в верхней позиции стека действительно прислана маршрутизатором опорной сети в устройство не опорной сети, и

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

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

3.1. Виртуальные сайты

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

В качестве альтернативы можно разделить интерфейс на несколько субинтерфейсов, (в частности, если интерфейс следует стандарту Frame Relay или ATM), и ассоциировать пакет с VPN на основе суб-интерфейса, через который он вошел. Можно также просто использовать отдельный интерфейс для каждого виртуального сайта. В любом случае, для одного сайта нужен только один CE-маршрутизатор, даже в случае большого числа виртуальных сайтов. Конечно, если хочется, можно использовать разные маршрутизаторы CE для каждого виртуального сайта.

Заметим, что во всех случаях, механизмы, как и политика для управления того, какой трафик пропускать и для какого VPN, находится в руках клиента.

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

Эти схемы не требуют от CE поддержки MPLS. Раздел 8 содержит краткое описание того, как CE может поддерживать большое число виртуальных сайтов, если оно не поддерживает MPLS.

4. Распределение маршрутов VPN посредством BGP

Маршрутизаторы PE используют BGP для рассылки маршрутов между VPN (точнее, для вынуждения VPN обмениваться маршрутами между собой).

Отправитель BGP может анонсировать и разослать маршрут для данного адресного префикса. Каждая VPN может иметь свое адресное пространство, это означает, что некоторые адреса могут использоваться в любом числе VPN, где в каждой VPN адрес соотносится с разной системой. Отсюда следует, что нужно позволить BGP инсталлировать и рассылать по несколько маршрутов для одного IP-адресного префикса. Более того, нужно гарантировать, что для определения того, какой маршрут из списка, предоставленного BGP, может использовать сайт и какой из них будет прописан в таблице переадресации, служит политика.

4.1. Адресное семейство VPN-IPv4

Мультипротокольное расширение BGP [3] позволяет этому протоколу работать со многими "адресными семействами". Введем обозначение "VPN-IPv4 address family". Адрес VPN-IPv4 имеет 12-байт и начинается с 8 байт идентификатора маршрута RD (Route Distinguisher) и завершается четырьмя байтами адреса IPv4. Если две VPN используют один и тот же адресный префикс IPv4, PE транслирует их в уникальный адресный префикс VPN-IPv4. Это гарантирует, что в случае использования одного и того же адреса в двух разных VPN, будет возможно установить два совершенно разных маршрута до этого адреса по одному для каждого VPN.

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

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

RD структурированы так, что каждый сервис-провайдер может администрировать свою зону нумерации (т.e., может выполнить свои собственные присвоения для RD), не конфликтуя с RD, присвоенными другими сервис-провайдерами. RD состоит из двухбайтного поля типа, поля администратора и поля присвоенного номера. Значение поля типа определяет длины двух других полей, а также семантику поля администратор. Поле администратор идентифицирует систему присвоения номеров (assigned number authority), а поле присвоенного номера несет в себе число, которое служит для идентификации этой системы. Например, может существовать RD, чье поле администратор содержит ASN (Autonomous System number), и чье поле номера (4-байта) содержит число, присвоенное SP, которому этот код ASN присвоен IANA. Для RD выбрана такая структура, для того, чтобы гарантировать, что SP, который предоставляет услуги опорной сети, может всегда сформировать уникальный RD, когда это потребуется. Однако данная структура не предоставляет никакой семантики. Когда BGP сравнивает два таких адресных префикса, он полностью игнорирует структуру. Если субполя администратор и присвоенный номер адреса VPN-IPv4 установлены равными нулю, считается, что адрес VPN-IPv4 имеет то же значение, что и глобально уникальный адрес IPv4. В частности, этот VPN-IPv4 адрес и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как совместимые. Во всех других случаях, адрес VPN-IPv4 и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как несовместимые.

Данная таблица переадресации сайта будет иметь только один маршрут VPN-IPv4 для любого заданного адресного префикса IPv4. Когда место назначения пакета соответствует маршруту VPN-IPv4, это соответствие касается только IPv4-части.

PE должен быть сконфигурирован так, чтобы установить соответствие между маршрутами, ведущими к конкретному CE, и их RD. PE может быть сконфигурирован так, чтобы установить соответствие между всеми маршрутами, ведущими к одному CE и имеющими данный RD. Он может быть сконфигурирован и так, чтобы установить соответствие между разными маршрутами, имеющими различные RD даже если они ведут к одному и тому же CE.

4.2. Управление рассылкой маршрутов

В данном разделе, обсуждается способ управления рассылкой маршрутов VPN-IPv4.

4.2.1. Атрибут Target VPN

Каждая таблица переадресации соответствует одному или более атрибутам "Target VPN". Когда маршрут VPN-IPv4 сформирован маршрутизатором PE, он ассоциируется с одним или более атрибутами " Target VPN". Они рассматриваются протоколом BGP как атрибуты маршрута.

Любой маршрут, ассоциированный с Target VPN T должен рассылаться каждому маршрутизатору PE, который имеет таблицу переадресации, ассоциированную с Target VPN T. Когда такой маршрут получен PE-маршрутизатором, он пригоден для инсталляции в каждой из таблиц переадресации PE, которая ассоциируется с Target VPN T. (Будет ли этот маршрут инсталлирован, зависит от процесса принятия решений BGP). По существу, атрибут Target VPN идентифицирует набор сайтов. Ассоциация конкретного атрибута Target VPN с маршрутом позволяет поместить маршрут в таблицу переадресации, которая используется для маршрутизации трафика, приходящего от соответствующих сайтов.

Имеется набор Target VPN, которые маршрутизатор PE подключает к маршруту, полученному из сайта S. Имеется набор Target VPN, которые маршрутизатор PE использует для определения, будет ли маршрут, полученный от другого маршрутизатора PE, помещен в таблицу переадресации, ассоциированную с сайтом S. Эти два набора различны, и не должны быть идентичны.

Функции, выполняемые атрибутом Target VPN, сходны с осуществляемыми атрибутом BGP Communities Attribute. Однако формат последнего не является адекватным, так как он позволяет только двухбайтовое пространство для нумерации. Самым простым решением является расширение пространства нумерации атрибута BGP Communities. Должно быть также возможно структурировать формат, аналогично тому, как это описано для RD (смотри раздел 4.1), так что поле тип определит длину поля администратор, а оставшаяся часть атрибута является номером из пространства нумерации администратора.

Когда BGP маршрутизатор получил два маршрута до одного и того же префикса VPN-IPv4, он выбирает один, согласно BGP правилам предпочтения маршрутов.

Заметим, что маршрут может иметь только один RD, но он может иметь несколько Target VPN. В BGP масштабируемость улучшается, если имеется один маршрут с несколькими атрибутами. Можно пренебречь атрибутом Target VPN, создавая больше маршрутов (т.e., используя большее число RD), но тогда свойства масштабируемости окажутся менее привлекательными.

Как PE определяет, какой из атрибутов Target VPN, ассоциировать с данным маршрутом? Существует большое число различных способов. PE может быть сконфигурирован так, чтобы ассоциировать все маршруты, которые ведут к определенному сайту, с некоторым заданным Target VPN. Или PE может быть сконфигурирован так, чтобы определенные маршруты, вели к конкретномусайту с одним Target VPN, а к другому с другим. Или CE-маршрутизатор, когда он рассылает маршруты (смотри раздел 6), можно специфицировать один или более Target VPN для каждого маршрута. Последний метод перемещает управление механизмом, используемым для реализации политики VPN от SP к клиенту. Если используется этот метод, может быть желательным, чтобы PE удалил любую Target VPN, которая согласно его собственной конфигурации, не допустима, и/или добавил некоторую Target VPN, которая согласно его конфигурации является обязательной. Более точно было бы называть этот атрибут " Route Target" вместо "VPN Target".

4.2.2. Расылка маршрутов между PE посредством BGP

Если два сайта VPN подключены к PE, которые размещены в одной автономной системе, PE могут рассылать маршруты VPN-IPv4 друг другу посредством соединения IBGP.

Если два сайта VPN находятся в разных автономных системах (например, из-за того, что они соединены с разными SP), тогда PE-маршрутизатор будет вынужден использовать маршрутизатор IBGP для перераспределения VPN-IPv4 маршрутов в маршрутизатор ASBR (Autonomous System Border Router), или в маршрутизатор-рефлектор, клиентом которого является ASBR. ASBR будет вынужден использовать EBGP, чтобы перераспределить эти маршруты в ASBR из другой AS. Это позволяет соединить различные сайты VPN различным сервис-провайдерам.Однако маршруты VPN-IPv4 должны восприниматься только соединениями EBGP в точках пирингового обмена. Маршруты VPN-IPv4 не должны никогда рассылаться и восприниматься общедоступным Интернет.

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

Когда маршрутизатор PE рассылает маршрут VPN-IPv4 через BGP, он использует свой собственный адрес в качестве " BGP next hop". Он также определяет и рассылает метки MPLS. (Существенно, что маршрутизаторы PE рассылают не VPN-IPv4 маршруты, а маркированные маршруты VPN-IPv4. [8]) Когда PE обрабатывает пакет, который имеет эту метку на вершине стека, PE очистит стек, и пошлет пакет непосредственно сайту, от которого ведет маршрут. Это обычно означает, что он посылает пакет маршрутизатору CE, от которого он узнал о маршруте. Метка может также определить инкапсуляцию данных в канале.

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

Заметим, что метка MPLS, которая рассылается таким способом, может использоваться, только если существует маркированный путь между маршрутизатором, его сформировавшим, и BGP-маршрутизатором на следующем шаге. Здесь не делается никакого предположения об используемой процедуре установления маркированного пути (процедура setup). Он может быть сформирован предварительно, или установлен, когда нужный маршрут будет инсталлирован. Это может быть оптимальный маршрут ("best effort"), или это может быть маршрут созданный в результате процедуры формирования трафика (traffic engineered). Между конкретным маршрутизатором PE и его BGP агентом следующего шага для конкретного маршрута может быть один или несколько LSP, возможно с разными характеристиками QoS.

Доступны все обычные методы использования отражателей маршрутов [2] для улучшения масштабируемости, например, иерархии отражателей маршрутов. Если используются отражатели маршрута, нет нужды иметь отражатель маршрутов, который знает все VPN-IPv4 маршруты для всех VPN, поддерживаемых опорной сетью. Можно иметь отдельные отражатели маршрута, которые не взаимодействуют друг с другом, каждый из которых поддерживает субнабор общего набора VPN.

Если данный маршрутизатор PE не подключен ни к одной Target VPN данного маршрута, он не должен получать этот маршрут. Другие PE или рефлекторы маршрута, которые посылают ему маршруты должны использовать внешние фильтры, чтобы избежать рассылки ненужных маршрутов. Конечно, если маршрутизатор PE получает маршрут через BGP, а данный PE не подключен к какой-либо target VPN маршрута, PE должен применить к этому маршруту внутреннюю фильтрацию, ни анонсируя и не пересылая его.

Маршрутизатор, который не подключен к какой-либо VPN, т.e., P-маршрутизатор, вообще никогда не анонсирует какие-либо маршруты VPN-IPv4.

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

4.2.3. Атрибут VPN of Origin

Маршрут VPN-IPv4 может быть опционно ассоциирован с атрибутом VPN of Origin. Это атрибут уникально идентифицирует набор сайтов и идентифицирует соответствующий маршрут, как пришедший из одного из сайтов этого набора. Типичным применением этого атрибута может быть идентификация предприятия, которое владеет сайтом, куда ведет маршрут, он может также идентифицировать интранет сайта. Однако возможны и другие применения. Этот атрибут может быть представлен как расширение атрибута BGP communities.

В ситуации, в которой необходимо идентифицировать источник маршрута, используется именно этот атрибут, а не RD. Этот атрибут может использоваться при формировании VPN, как это описано ниже.

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

Путем соответствующей установки атрибутов Target VPN и VPN of Origin, можно сконструировать VPN самого разного типа.

Предположим, что нужно создать замкнутую группу пользователей CUG (Closed User Group), которая содержит определенный набор сайтов. Это может быть сделано путем формирования определенного атрибута Target VPN для CUG. Значение этого атрибута затем должно быть ассоциировано с таблицами переадресации сайта для каждого сайта в CUG, оно должно быть связано с каждым маршрутом, полученным от сайта в CUG. Любой маршрут, который имеет этот атрибут Target VPN, должен быть перераспределен так, чтобы достичь каждого маршрутизатора PE, подключенного к одному из сайтов.

В качестве альтернативы, предположим, что желательно по какой-то причине создать VPN типа "hub and spoke" (ось и спица). Это может быть сделано путем использования двух значений атрибута Target, один со значением " Hub" а другой со значением "Spoke". Затем маршруты от spokes могут быть посланы hub, не вызывая посылки маршрутов в обратном направлении.

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

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

5. Переадресация в опорной сети

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

Маршрутизаторы PE (и ASBR, которые перераспределяют адреса VPN-IPv4) должны ввести адресные префиксы /32 для самих себя в таблицы маршрутизации опорной сети. Это позволяет MPLS, в каждом узле опорной сети присвоить метку, соответствующую маршруту к каждому маршрутизатору PE. (Определенные процедуры для установления коммутации меток в опорной сети могут не требовать присутствия адресного префикса /32.)

Когда PE получает пакет от CE-устройства, он выбирает определенную таблицу переадресации сайта, в которой ищется адрес места назначения пакета. Предположим, что такой адрес найден. Если пакет адресован устройству CE, подключенному к тому же самому PE, пакет посылается непосредственно устройству CE.

Если пакет адресован не устройству CE, подключенному к тому же PE, важен "BGP Next Hop" пакета, а также метка, которую этот BGP следующего шага присвоил адресу места назначения пакета. Эта метка укладывается в стек меток пакета. Затем PE ищет маршрут IGP до BGP следующего шага, и таким образом определяет маршрутизатор следующего шага IGP, а также метку, приписанную адресу маршрутизатора следующего шага BGP. Эта метка заносится на верх стека меток пакета, а пакет затем переадресуется к маршрутизатору следующего шага IGP. (Если BGP следующего шага является тем же что и для IGP, вторая метка может не извлекаться из стека).

В этой точке MPLS будет транспортировать пакет через опорную сеть и в соответствующее CE-устройство. То есть, все решения о переадресации в P- и PE-маршрутизаторах принимаются на уровне MPLS, а IP-заголовки пакетов не анализируются повторно до тех пор, пока они не достигнут устройства CE. Оконечный маршрутизатор PE прежде чем посылать пакет устройству CE, извлекает из стека MPLS очередную метку, таким образом, устройство CE получит обычный IP-пакет.

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

Заметим, что двухуровневая маркировка делает возможным увод всех маршрутов VPN от маршрутизаторов P, а это в свою очередь важно для гарантии масштабируемости модели. Опорная сеть не должна иметь маршрутов к CE (только к PE).

6. Как PE узнают о маршрутах от CE

Маршрутизаторы PE, которые подключены к какой-то VPN, должны знать адреса для каждого сайта из данного VPN.

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

PE транслирует эти адреса в адреса VPN-IPv4, используя сконфигурированный RD. PE далее рассматривает эти маршруты в качестве входной информации протокола BGP. Ни при каких обстоятельствах маршруты из сайта не должны уходить в IGP опорной сети.

Какой из методов рассылки маршрутов PE/CE возможен, зависит от того, является ли конкретное устройство CE "транзитным VPN" или нет. "Транзитная VPN" – это сеть, которая содержит маршрутизатор, получающий маршруты от "третей стороны" (т.e., от маршрутизатора, который находится вне VPN, но не является PE-маршрутизатором), и который перераспределяет эти маршруты в маршрутизатор PE. VPN, которая не является транзитной VPN, представляет собой "частичную VPN". Подавляющее большинство VPN, включая практически все корпоративные сети, следует считать такими. Возможные механизмы рассылки PE/CE:

1. Может использоваться статическая маршрутизация (т.e., конфигурация).

2. PE и CE-маршрутизаторы могут быть RIP-партнерами, а CE может использовать RIP, чтобы сообщить маршрутизатору PE набор адресных префиксов, которые достижимы для сайта CE. Когда RIP сконфигурирован в CE, следует позаботиться о том, чтобы адресные префиксы от других сайтов (т. e., адресные префиксы, полученные маршрутизатором CE от маршрутизатора PE) никогда не анонсировались PE. Точнее, если маршрутизатор PE, скажем PE1, получает VPN-IPv4 маршрут R1, и в результате посылает маршрут IPv4 R2 в CE, R2 не должен быть послан назад из сайта CE в маршрутизатор PE, скажем PE2, (где PE1 и PE2 может быть тем же маршрутизатором или разными маршрутизаторами), если только PE2 не ставит в соответствие R2 и маршрут VPN-IPv4, который отличается от (т.e., содержит другой RD) R1.

3. Маршрутизаторы PE и CE могут быть партнерами OSPF. В этом случае, сайт должен быть единой областью OSPF, CE должно быть ABR для этой области, а PE должно быть ABR, который находится вне области. Кроме того, PE не должен анонсировать никакие связи маршрутизатора кроме тех, что существуют до CE, размещенном в том же сайте. (Этот метод должен использоваться только в частичных VPN.)

4. Маршрутизаторы PE и CE могут быть партнерами BGP, а маршрутизатор CE может использовать BGP (В частности, EBGP, чтобы уведомить маршрутизатор PE о наборе адресных префиксов, которые находятся в сайте маршрутизатора CE. (Эта технология может использоваться в частичных или транзитных VPN).

С чисто технической точки зрения это далеко не совершенная методика:

a) В отличии от альтернатив IGP, это не требует от PE запускать несколько запросов алгоритму маршрутизации, для того чтобы взаимодействовать с несколькими CE.

b) BGP сконструирован как раз для решения таких задач: пересылки маршрутной информации между системами, управляемыми разными администраторами.

c) Если сайт содержит "BGP backdoors", т.e., маршрутизаторы с BGP-соединениями с маршрутизаторами, отличными от PE-маршрутизаторов, эта процедура будет работать корректно при любых обстоятельствах. Другие процедуры могут работать или нет, в зависимости от конкретных обстоятельств.

d) Использование BGP упрощает для CE передачу атрибутов маршрутов PE. Например, CE может предложить определенный Target для каждого маршрута, из числа атрибутов Target, которые авторизованы PE для присвоения маршруту.

С другой стороны, использование BGP вероятно является чем-то новым для CE администраторов, за исключением случая, когда клиент сам является Интернет сервис-провайдером. Если сайт не является транзитной VPN, он не должен иметь уникальный ASN (Autonomous System Number). Каждый CE, чей сайт не является транзитной VPN, может использовать один и тот же ASN. Значение может быть взято из частного ASN-пространства, оно будет ликвидировано PE. Маршрутные петли предотвращаются путем использования атрибута Site of Origin (см. ниже).

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

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

Прежде чем PE сможет передать VPN-IPv4 маршрут, узнанный от сайта, он должен присвоить ему определенный атрибут. Существует три таких атрибута:

- Исходный сайт (Site of Origin)

Этот атрибут однозначно идентифицирует сайт, от которого маршрутизатор PE узнал о маршруте. Всем маршрутам, полученным от определенного сайта, должен быть присвоен один и тот же атрибут Site of Origin, даже если сайт имеет несколько соединений с одним PE, или соединен с несколькими PE. Определенные атрибуты Site of Origin должны использоваться с определенными сайтами. Этот атрибут может быть представлен как атрибут extended BGP communities (раздел 4.2.1).

- VPN of Origin

Смотри раздел 4.2.1.

- Target VPN

Смотри раздел 4.2.1.

7. Как CE узнает маршруты от PE

В данном разделе мы предполагаем, что устройством CE является маршрутизатор. Вообще, PE может послать любой маршрут в CE, который PE поместил в таблицу переадресации, которую он использует для маршрутизации пакетов из CE. Существует одно исключение: если атрибут маршрута Site of Origin идентифицирует конкретный сайт, такой маршрут не должен никогда посылаться какому-либо CE этого сайта.

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

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

8. Если CE поддерживает MPLS?

В случае, когда CE поддерживает MPLS, и хочет импортировать весь набор маршрутов из своего VPN, PE может разослать метку для каждого такого маршрута. Когда PE получает пакет от CE с такой меткой, он (a) замещает эту метку соответствующей меткой, которую он получил через BGP, и (b) заносит метку в стек поверх метки, соответствующей BGP следующего шага для заданного маршрута.

8.1. Виртуальные сайты

Если рассылка маршрутов CE/PE выполнена через BGP, CE может использовать MPLS, чтобы осуществить поддержку большого числа сайтов. CE может сам содержать отдельную таблицу переадресации для каждого виртуального сайта, которую он заполняет, как это указано атрибутом Origin and Target VPN маршрутов, получаемых им от PE. Если CE получает от PE полный набор маршрутов, PE не будет должен просматривать адреса пакетов, полученных от CE. В качестве альтернативы PE может в некоторых случаях посылать CE отдельный (помеченный) маршрут по умолчанию для каждого VPN. Затем, когда PE получает помеченный пакет от CE, он узнает, какую таблицу переадресации следует просматривать. Метка, помещенная в пакет CE, будет идентифицировать только виртуальный сайт, от которого пакет пришел.

8.2. Представление ISP VPN в качестве части VPN

Если определенная VPN является в действительности ISP, но ее маршрутизаторы CE поддерживают MPLS, тогда VPN может рассматриваться как частичная VPN. Маршрутизаторы CE и PE должны только обмениваться маршрутами, которые являются внутренними по отношению к VPN. Маршрутизатор PE отправит маршрутизатору CE метку для каждого из этих маршрутов. Маршрутизаторы в других сайтах VPN могут тогда стать партнерами BGP. Когда маршрутизатор CE просматривает адрес назначения пакета, маршрутный поиск всегда возвращает внутренний адрес, обычно адрес BGP следующего шага. CE помечает пакеты соответствующим образом и посылает их к PE.

9. Безопасность

a) Помеченные пакеты не воспринимаются маршрутизаторами опорной сети, если они пришли из источников не внушающих доверия, если только не известно, что такие пакеты покинут опорную сеть до того как будут проанализированы IP-заголовки или какие-либо метки в стеке, и

b) помеченные маршруты VPN-IPv4 не воспринимаются, если они пришли из источников не внушающих доверия, безопасность предоставляемая этой архитектурой виртуально идентична той, которая реализуется опорными сетями VPN Frame Relay или ATM.

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

Использование MPLS позволяет также расширить зону действия VPN на несколько SP вне какой-либо зависимости от междоменной рассылки маршрутной информации.

Для пользователя VPN возможно также обеспечить себя повышенной безопасностью путем применения туннельного режима IPSEC [5].

Пользователи VPN, чувствительные к проблемам безопасности, могут требовать гарантии того, что некоторые или все пакеты, которые проходят через опорную сеть, были аутентифицированы и/или зашифрованы. Стандартный путь получения такого режима заключается в создании "безопасного туннеля" для каждой пары маршрутизаторов CE в VPN, используя туннельный режим IPSEC.

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

Способ достижения этого предложен в [6]. Каждый маршрут VPN может иметь атрибут, который идентифицирует следующий маршрутизатор CE, через который пройдет путь. Если эта информация предоставлена всем маршрутизаторам CE в VPN, может использоваться стандартный туннельный режим IPSEC.

Если CE и PE являются BGP-партнерами, естественно представить эту информацию в виде атрибута BGP.

Каждый CE, который должен использовать IPSEC, должен быть так сконфигурирован, чтобы запретить посылку небезопасного трафика по любому из оговоренных адресов. Это блокирует посылку небезопасного трафика CE, если по какой-то причине ему не удалось получить необходимую информацию.

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

9.2. Многокомпонентные безопасные ассоциации

Вместо построения безопасного туннеля между каждой парой маршрутизаторов CE, может оказаться более привлекательным сформировать одну безопасную ассоциацию с большим числом участников. В такой ассоциации, все маршрутизаторы CE, которые находятся в конкретной VPN, будут иметь идентичные параметры безопасности (например, некоторый ключ, определенный алгоритм и т.д.). Тогда устройство CE не должно будет знать, какое CE должно получать данные следующим, оно должно знать какой сети VPN предназначена эта информация. CE, которое принадлежит нескольким VPN, может использовать различные параметры безопасности для каждой из них, таким образом защищая, например, пакеты интранет от попадания в экстранет. Для такой схемы не может быть применен стандартный туннельный режим IPSEC, так как здесь нет способа заполнить поле IP-адреса места назначения внешнего заголовка. Однако когда MPLS используется для переадресации, реальной необходимости этого не существует; маршрутизатор PE может использовать MPLS, чтобы ввести пакет в конечную точку туннеля, даже не зная его IP-адреса; он только должен отслеживать IP-адреса места назначения внутреннего заголовка.

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

Другим преимуществом является то, что исключена необходимость внешнего IP-заголовка, так как инкапсуляция MPLS берет на себя эту функцию.

10. Качество обслуживания

Качество обслуживания (QoS) является ключевым компонентом любой системы VPN. В MPLS/BGP VPN, существующие возможности L3 QoS могут быть применены к помеченным пакетам посредством использования "экспериментальных" битов в промежуточном заголовке [10], или, в случае применения в качестве опорной сети ATM, за счет использования QoS-возможностей самой сети ATM. Управление трафиком, обсуждаемое в работе [1], также применимо к сетям VPN MPLS/BGP. Управление трафиком, если это желательно, может использоваться даже для установления LSP с конкретными параметрами QoS между определенными парами сайтов. Когда MPLS/BGP VPN охватывает нескольких SP, может быть применена архитектура, описанная в [7]. SP может реализовать либо intserv или diffserv возможности конкретной сети VPN.

11. Масштабируемость

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

(a) PE-маршрутизаторов,

(b) BGP отражателей маршрута,

(c) P-маршрутизаторов (которые являются либо PE-маршрутизаторами, либо рефлекторами маршрута), и в случае мульти-провайдерской VPN,

(d) ASBR.

P-маршрутизаторы не поддерживают никакие VPN маршруты. Для того чтобы правильно маршрутизовать VPN трафик, P-маршрутизаторы должны поддерживать только маршруты до PE-маршрутизаторов и ASBR. Использование двух уровней пометки позволяет увести маршруты VPN от P-маршрутизаторов.

Маршрутизатор PE поддерживает VPN маршруты, но только для тех VPN, с которыми связан непосредственно.

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

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

12. Ссылки

[1] Awduche, Berger, Gan, Li, Swallow, and Srinavasan, "Extensions to RSVP for LSP Tunnels", Work in Progress.

[2] Bates, T. and R. Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.

[3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998.

[4] Gleeson, Heinanen, and Armitage, "A Framework for IP Based Virtual Private Networks", Work in Progress.

[5] Kent and Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[6] Li, "CPE based VPNs using MPLS", October 1998, Work in Progress.

[7] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC2430, October 1998.

[8] Rekhter and Rosen, "Carrying Label Information in BGP4", Work in Progress.

[9] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", Work in Progress.

[10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", Work in Progress.

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

-->

E. Rosen, RFC-3032, MPLS Label Stack Encoding

Аннотация

"Многопротокольная коммутация меток (MPLS)" [1] требует наличия набора процедур для пакетов со стеком меток (помеченных пакетов). Маршрутизаторы, которые поддерживают MPLS, называются LSR (Label Switching Routers). Для того чтобы переслать помеченный пакет по конкретному каналу, LSR должен поддерживать систему представления стека меток и обработки пакетов сетевого уровня. В данном документе специфицирована система представления стека меток, используемая LSR, для того чтобы передавать помеченные пакеты по каналам PPP (Point-to-Point Protocol), по каналам данных LAN, и возможно по другим каналам. В других каналах кодирование может быть иным, но представление стека меток должно быть стандартным. Здесь также специфицируются правила и процедуры для обработки различных полей записей в стеке меток.

1. Введение

"Многопротокольная коммутация меток (MPLS)" [1] требует набора процедур для дополнения пакетов сетевого уровня "стеком меток", таким образом превращая их в помеченные пакеты. Маршрутизаторы, которые поддерживают протокол MPLS, называются LSR (Label Switching Routers). Для того чтобы передать помеченный пакет по определенному каналу, LSR должен поддерживать методику кодирования, и анализа помеченных пакетов. Данный документ специфицирует кодирование, используемое LSR, для того чтобы передать помеченный пакет по каналу данных PPP и LAN. Специфицированная кодировка может быть применена и в других каналах данных.

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

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

2. Стек меток

2.1. Кодирование стека меток

Стек меток представляет собой последовательность записей. Каждая запись в стек имеет длину 4 октета. Формат такой записи показан на рис. 1.

Рис. 1. Формат записи стека меток

Запись стека меток размещается после заголовка канального уровня, и перед заголовком сетевого уровня (например, между Ethernet- и IP-заголовком). Верх стека записывается первым, а дно - последним. Сетевой заголовок следует сразу вслед за записью стека меток с битом S=1. Каждая запись стека меток содержит в себе следующие поля:

1. Дно стека (S)

Этот бит устанавливается равным 1 для последней записи в стеке меток (т.e., для дна стека), и нулю для всех прочих записей.

Замечание переводчика. Следует заметить, что данный формат меток не является единственно возможным (я здесь не имею в виду ATM или FR). В IP-телефонии, например, предлагается использовать метку, которая содержит (слева-направо) код 0х8100, за которым идет 3-битовое поле приоритета (0-7) и идентификатор VPN (0-4095). Смотри журнал LANline N10, 2002, стр 140).

2. Время жизни (TTL)

Это 8-битовое поле служит для представления значения времени жизни пакета. Обработка этого поля описана в разделе 2.4.

3. Экспериментальное поле

Это 3-битовое поле зарезервировано для экспериментальных целей (QoS).

4. Значение метки

Это 20-битовое поле несет в себе код метки.

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

a) следующий шаг, куда должен быть переадресован пакет;

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

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

i. Значение 0 представляет "IPv4 Explicit NULL Label". Это значение метки является единственно допустимым для дна стека меток. Оно указывает, что стек должен быть очищен, и переадресация пакета должна основываться на IPv4-заголовке.

ii. Значение 1 представляет "Router Alert Label". Это значение метки является легальным в любом месте стека меток за исключением дна. Когда полученный пакет содержит такую метку на вершине стека, он доставлен локальному модулю для обработки. Действительная переадресация пакета определяется меткой, в его стеке. Однако, если пакет переадресуется дальше, еще до переадресации в стек должна быть занесена метка Router Alert. Использование этой метки сходно с применением опции "Router Alert" в IP-пакетах [5]. Так как эта метка не может лежать на дне стека, она не ассоциируется с определенным протоколом сетевого уровня.

iii. Значение 2 представляет "IPv6 Explicit NULL Label". Это значение метки является единственно допустимым для записи на дне стека. Оно указывает, что стек должен быть очищен, а переадресация пакетов должна после этого основываться на заголовке IPv6.

iv. Значение 3 представляет "Implicit NULL Label". Это метка, которую LSR может присваивать и рассылать, но которая в действительности никогда не используется при инкапсуляции. Когда LSR замещает метку на верху стека на новую, и эта новая метка является "Implicit NULL", LSR очистит стек вместо того, чтобы осуществить замену. Хотя это значение не может появиться при инкапсуляции, оно должно быть специфицировано в протоколе рассылки меток, так что значение может считаться зарезервированным.

v. Значения 4-15 зарезервированы.

2.2. Определение протокола сетевого уровня

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

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

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

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

2.3. Генерация ICMP-сообщений для помеченных пакетов
В разделах 2.4 и 3 обсуждаются ситуации, в которых желательно формировать ICMP-сообщения для помеченных IP-пакетов. Для того чтобы конкретный LSR мог формировать и посылать ICMP пакеты отправителям IP-пакетов, должны выполняться два условия:
1. Данный LSR должен быть способен определить, что конкретный помеченный пакет является IP-пакетом.
2. Данный LSR должен быть способен проложить путь до места назначения IP-пакета.
Условие 1 обсуждается в разделе 2.2. В следующих двух подразделах обсуждается условие 2. Однако встречаются ситуации, когда условие 2 совсем не выполняется, и в этих случаях невозможно сформировать сообщение ICMP.

2.3.1. Туннелирование через транзитную область маршрутизации
Предположим, что MPLS используется для организации туннеля через транзитную область маршрутизации, где данные о внешних маршрутах не попадает к внутренним маршрутизаторам. Например, внутренние маршрутизаторы работают с протоколом OSPF, и могут только знать, как достичь объектов в пределах зоны OSPF. Домен может содержать несколько пограничных маршрутизаторов автономной системы ASBR (Autonomous System Border Routers), которые взаимодействуют друг с другом с помощью BGP. Однако в этом примере маршруты от BGP не рассылаются OSPF, и LSR, которые не являются ASBR, поддерживают BGP.
В этом примере, только ASBR будет знать, как проложить маршрут до отправителя некоторого произвольного пакета. Если внутренний маршрутизатор должен послать сообщение ICMP отправителю IP-пакета, он не будет знать как маршрутизовать это ICMP-сообщение.
Одним из решений является занесение ASBR маршрута по умолчанию в IGP. Это бы гарантировало то, что любой непомеченный пакет, который должен выйти из домена (такой как ICMP-пакет), попадет в маршрутизатор, который имеет полную маршрутную информацию. Маршрутизаторы с полной маршрутной информацией будет помечать пакеты, прежде чем их послать через транзитную область, так что использование маршрутов по умолчанию в пределах транзитного домена не приводило к образованию циклических путей.
Это решение работает только для пакетов, которые имеют глобально уникальные адреса, и для сетей, в которых все ASBR имеют полную маршрутную информацию. В следующем подразделе описывается решение, которое работает, когда эти условия не выполняются.

2.3.2. Туннелирование частных адресов через общедоступную опорную сеть
В некоторых случаях, когда MPLS используется для туннелирования через домен маршрутизации, может быть вообще невозможно проложить путь до адреса отправителя фрагментированных пакетов. Такая ситуация возникла бы, например, если IP-адреса в пакетах были частными адресами (т.e., не были глобально уникальными), и MPLS использовался для туннелирования таких пакетов через общедоступную опорную сеть. Маршруты по умолчанию в ASBR не будет работать в таких условиях.
В этих условиях, для того чтобы послать ICMP-сообщение отправителю пакета, можно копировать стек меток исходного пакета в ICMP-сообщение, и затем осуществить коммутацию по меткам для ICMP-пакета. Это заставит сообщение двигаться в направлении места назначения исходного пакета, а не его отправителя. Если только сообщение не является коммутируемым по меткам на всем пути до ЭВМ назначения, оно завершит путь непомеченным в маршрутизаторе, который знает путь до отправителя исходного пакета, отсюда сообщение будет послано в правильном направлении.
Эта технология может быть весьма полезной, если ICMP-сообщением является "Time Exceeded" (время истекло) или "Destination Unreachable because fragmentation needed and DF set" (место назначение недостижимо из-за необходимости фрагментации и DF=1).
При копировании стека меток из исходного пакета в сообщение ICMP, значения меток должны копироваться точно, но значения TTL должны устанавливаться равными величине, размещенной в IP-заголовке ICMP-сообщения. Это значение TTL должно быть достаточным, чтобы позволить кружной маршрут, которому должен следовать ICMP-сообщение.
Заметим, что если истечение TTL сопряжено с наличием петли маршрута, тогда в случае использования этой техники, ICMP-сообщение может циклить. Так как сообщение ICMP никогда не посылается в ответ на ICMP-пакет, и так как многие реализации ограничивают частоту посылки ICMP-сообщений, проблем это создать не должно.

2.4. Обработка поля времени жизни
2.4.1. Определения
"Входное TTL" помеченного пакета по определению должно равняться значению поля TTL в записи наверху стека меток на момент получения пакета. "Выходное TTL" помеченного пакета по определению должно равняться большему из:
a) входное значение TTL минус один,
b) нуль.

2.4.2. Протокольно независимые правила
Если выходное TTL помеченного пакета =0, тогда помеченный пакет не должен более переадресовываться и пакет следует далее непомеченным. Время жизни пакета в сети считается истекшим. В зависимости от значения метки в стеке, пакет может быть просто отброшен, или он может быть передан сетевому слою для обработки ошибки (например, для генерации ICMP сообщения об ошибке, смотри раздел 2.3).
Когда помеченный пакет переадресуется, поле TTL записи наверху стека меток должно быть установлено равным выходному значению TTL.
Заметим, что выходное значение TTL является функцией входного значения TTL, и зависит оттого, были ли перед этим в стек занесены или извлечены какие то метки до переадресации пакета. Значения поля TTL в записях, за исключением верхней, никакого влияния не оказывают.

2.4.3. Правила, зависящие от IP
Мы определяем поле "IP TTL" равным величине поля IPv4 TTL, или значению поля IPv6 Hop Limit, в зависимости оттого, что используется.
Когда IP-пакет помечен впервые, поле TTL в стеке должно быть установлено равным значению поля IP TTL.
Когда все метки извлекаются из стека, и он оказывается пустым, значение поля IP TTL должно быть замещено величиной выходного TTL, как это определено выше. В случае IPv4 это потребует также корректировки контрольной суммы IP заголовка.
Признается, что могут существовать ситуации, когда сетевая администрация предпочитает декрементировать IPv4 TTL на 1 при прохождении через домен MPLS, вместо того чтобы декрементировать IPv4 TTL на число LSR в домене.

2.4.4. Преобразование различных инкапсуляций
Иногда LSR может получить помеченный пакет через, например, интерфейс ATM (LC-ATM) [9], и должен будет послать его через PPP или LAN. Тогда входной пакет будет получен без инкапсуляции, описанной в данном документе, а будет послан уже с применением такой инкапсуляции.
В этом случае значение "входное TTL" определяется процедурами обработки помеченных пакетов, например, в интерфейсе LC-ATM. Обработка TTL будет тогда происходить так, как это описано выше. Иногда LSR может получить помеченный пакет через канал PPP или LAN, и должен его послать на выход через интерфейс LC-ATM. Тогда входной пакет будет принят с использованием инкапсуляции, описанной в данном документе, а выходной пакет послан с привлечением иной инкапсуляции. В этом случае процедура формирования значения "выходного TTL" определяется процедурами, применяемыми к помеченным пакетам, например, в интерфейсах LC-ATM.

3. Фрагментация и определение MTU пути
Поскольку возможно получение непомеченной IP-дейтограммы, которая слишком велика, чтобы быть передана в выходной канал, имеется возможность получения помеченного пакета, который также невозможно передать по этой причине на выход.
Возможно также, что полученный пакет (помеченный или нет), который первоначально был достаточно мал для передачи через канал, становится слишком большим, получив одну или более меток. При коммутации меток, пакет может расти в размере, если в его стек заносятся дополнительные метки. Таким образом, если получен помеченный пакет с 1500-байтовым полем данных, и в него записана дополнительная метка, переадресовать нужно будет пакет с размером 1504-байта.
В этом разделе специфицируются правила обработки помеченных пакетов, которые являются "слишком большими". В частности, речь идет о правилах, которые гарантируют, что ЭВМ, использующие определение MTU пути [4], и ЭВМ, работающие с IPv6 [7,8], будут способны формировать IP-дейтограммы, которые не нуждаются в фрагментации, даже если эти дейтограммы получили дополнительные метки при прохождении через сеть.
Вообще, ЭВМ IPv4, которые не используют определение MTU пути [4], посылают IP-дейтограммы, содержащие не более 576 байт. Так как большинство используемых MTU равняются 1500 байт или больше, вероятность того, что такие дейтограммы будут нуждаться в фрагментации, даже если они помечены, весьма мала.
Некоторые ЭВМ, которые не используют определение MTU пути [4], формируют IP-дейтограммы, содержащие 1500 байт. Поскольку IP-адреса отправителя и получателя в одной и той же субсети, эти дейтограммы не проходят через маршрутизаторы, и, следовательно, не будут фрагментироваться
Если же IP-адрес отправителя и получателя находятся в разных автономных системах, это единственный случай, когда имеется риск фрагментации при пометке пакета.
В этом документе специфицированы процедуры, которые позволяют конфигурировать сеть так, что большие дейтограммы от ЭВМ, не использующих определение MTU пути, фрагментируются только раз, когда они впервые помечены. Эти процедуры делают возможным избежать фрагментации пакетов, которые уже помечены.

3.1. Терминология
Что касается конкретного канала данных, можно использовать следующие термины:
- Поле данных кадра:
Содержимое поля данных кадра, исключая любые заголовки и поля завершения кадра (например, MAC-заголовки, LLC-заголовки, 802.1Q-заголовки, PPP-заголовки, контрольные суммы, и т.д.).
Когда кадр несет в себе непомеченную IP-дейтограмму, поле данных кадра представляет собой саму IP-дейтограмму. Когда кадр несет в себе помеченную IP-дейтограмму, поле данных кадра состоит из записей стека меток и IP-дейтограммы.
- Обычный максимальный размер поля данных кадра:
Максимальный размер поля данных кадра определяется стандартами канала данных. Например, обычный максимальный размер поля данных кадра для Ethernet равен 1500 байтов.
- Истинный максимальный размер поля данных кадра:
Максимальный размер поля данных кадра, который можно послать и получить через интерфейс канала данных.
Для сетей Ethernet и 802.3, считается, что истинный максимальный размер поля данных кадра на 4-8 байта больше обычного максимального размера поля данных (поскольку ни переключатель, ни бридж не могут увеличить размер заголовка в процессе транспортировки пакета до следующего узла сети). Например, считается, что большинство оборудования Ethernet может принимать и посылать пакеты, содержащие, по крайней мере, 1504 или даже 1508 байт, поскольку заголовок Ethernet не имеет полей 802.1Q или 802.1p. В каналах PPP, истинный максимальный размер поля данных кадра может быть неограниченным.
- Эффективный максимальный размер поля данных для помеченных кадров:
Это либо обычный максимальный размер поля данных кадра или истинный максимальный размер поля данных кадра, в зависимости от возможностей оборудования канала и размера заголовка канального уровня.
- Первично помеченная IP-дейтограмма:
Предположим, что непомеченная IP-дейтограмма получена конкретным LSR, и что LSR вводит метку в стек перед тем, как переадресовать эту дейтограмму. Такая дейтограмма будет называться первично помеченной в этом LSR IP-дейтограммой.
- Ранее помеченная IP-дейтограмма:
IP-дейтограмма, которая уже была помечена до того, как была получена конкретным LSR.

3.2. Максимальный исходный размер помеченной IP-дейтограммы
Каждый LSR, который способен
a) получать непомеченные IP-дейтограммы,
b) добавлять метки в стек дейтограммы, и
c) переадресовывать полученный в результате помеченный пакет,
должен поддерживать конфигурационный параметр, называемый "максимальный размер первично помеченной IP-дейтограммы", который может быть установлен неотрицательным. Если этот конфигурационный параметр установлен равным нулю, он ни на что не влияет. Если он имеет положительное значение, то он используется следующим образом. Если:
a) получена непомеченная IP-дейтограмма, и
b) эта дейтограмма имеет в заголовке бит DF=0, и
c) дейтограмма перед переадресацией должна быть помечена, и
d) размер дейтограммы (до пометки) превышает значение данного параметра, тогда
a)     Дейтограмма должна быть разделена на фрагменты с размером не больше, чем указано в данном параметре, и
b)     Каждый фрагмент должен быть помечен и после этого переадресован.
Например, если этот конфигурационный параметр установлен равным 1488, тогда любая непомеченная IP дейтограмма, содержащая более 1488 байт, будет фрагментирована до выполнения пометки. Каждый фрагмент будет способен передавать через канал 1500 байт, без последующей фрагментации, даже если в стек будет занесено до трех меток.
Другими словами, установка этого параметра не равным нулю, позволяет исключить фрагментацию уже помеченных IP пакетов, но это может вызвать иногда фрагментацию первично помеченных IP-дейтограмм, когда это совсем не нужно.
Заметим, что установка этого параметра не влияет на обработку IP-дейтограмм, которые содержат бит DF=1, следовательно, установка этого параметра не влияет на результат определения MTU пути.

3.3. Когда помеченная IP-дейтограмма слишком велика?
Помеченная IP-дейтограмма, чей размер превышает обычный максимальный размер поля данных канала, может рассматриваться как "слишком большая".
Помеченная IP-дейтограмма, чей размер превышает истинный максимальный размер поля данных кадра канала, через который она должна переадресоваться, считается "слишком большой".
Помеченная IP-дейтограмма, которая не является "слишком большой" должна передаваться без фрагментации.

3.4. Обработка помеченных дейтограмм Ipv4, которые слишком длинны
Если помеченная IPv4 дейтограмма "слишком велика", и бит DF в IP заголовке =1, тогда LSR может отбросить дейтограмму.
Заметим, что отбрасывание таких дейтограмм является разумным, только если "Максимальный размер первично помеченной IP-дейтограммы" установлен равным ненулевому значению во всех LSR сети, способных добавлять метки в стек непомеченных IP-дейтограмм.
Если LSR решает не отбрасывать помеченные IPv4-дейтограммы, которые слишком велики, или если в дейтограмме флаг DF=1, тогда должен быть выполнена следующая последовательность операций:
1. Удалить записи в стеке, чтобы получить IP-дейтограмму.
2. Пусть N равно числу байт в стеке (т.e, число записей в стеке меток, умноженное на 4).
3. Если IP-дейтограмма содержит в IP заголовке бит "Don't Fragment" =0:
a.      Разбить ее на фрагменты, каждый из которых должен иметь размер, по крайней мере, на N байт меньше, чем эффективный максимальный размер поля данных кадра.
b.      Преобразовать каждый фрагмент, снабдив его заголовком, который имела исходная дейтограмма.
c.      Переадресовать фрагменты.
4. Если IP-дейтограмма содержит в IP заголовке бит "Don't Fragment" =1:
a.      Дейтограмма не должна переадресовываться.
b.      Сформировать ICMP-сообщение “Адресат недостижим”:
i.            Установить значение поля [3] равным "Fragmentation Required and DF Set",
ii.         Установить значение поля Next-Hop MTU [4] равным разности между эффективным максимальным размером поля данных кадра и величиной N
c.      Если возможно, послать ICMP-сообщение “Адресат недостижим” отправителю отброшенной дейтограммы.

3.5. Обработка помеченных дейтограмм IPv6, которые слишком длинны
Чтобы обработать помеченную IPv6-дейтограмму, которая слишком велика, LSR должен реализовать следующий алгоритм:
1. Удалить записи в стеке, чтобы получить IP-дейтограмму.
2. Пусть N равно числу байт в стеке (т.e, число записей в стеке меток, умноженное на 4).
3. Если IP-дейтограмма содержит более 1280 байтов (не считая записи стека меток), или, если она не содержит заголовка фрагмента, тогда:
a.      Сформировать ICMP-сообщение “Too Big Message”, и установить значение поля Next-Hop MTU равным разности между эффективным максимальным размером поля данных кадра и величиной N.
b.      Если возможно, послать отправителю дейтограммы ICMP-сообщение “Too Big Message”.
c.      Отбросить помеченную IPv6-дейтограмму.
4. Если IP-дейтограмма не длиннее 1280 октетов, и содержит заголовок фрагмента, тогда
a.      Преобразовать ее в фрагменты, каждый из которых должен быть по крайней на N байт меньше, чем эффективный максимальный размер поля данных кадра.
b.      Снабдить каждый фрагмент тем же помеченным заголовком, который имела исходная дейтограмма.
c.      Переадресовать фрагменты.
Восстановление сообщения из фрагментов осуществляется конечным получателем.

3.6. Реализация с учетом определения MTU пути
Описанные выше процедуры обработки дейтограмм, которые имеют в заголовке бит DF=1, но являются "слишком большими", связаны с процедурами определения MTU пути RFC 1191 [4]. ЭВМ, которые используют эти процедуры, определят MTU, который достаточно мал, чтобы позволить занесение в дейтограмму n маркеров, без необходимости фрагментации. Здесь n равно числу меток, заносимых на используемом пути через домен.
Другими словами, дейтограммы от ЭВМ, которые используют определение MTU пути, никогда не потребуют фрагментации из-за занесения меток в заголовок. Заметим, что дейтограммы от ЭВМ, использующих определение MTU пути, имеют бит DF=1, и таким образом не могут быть фрагментированы в любом случае.
Отметим также, что определение MTU пути будет работать корректно, только если в точке, где может потребоваться фрагментация помеченной IP-дейтограммы, возможна посылка отправителю ICMP сообщения “Destination Unreachable”. Смотри раздел 2.3. Если невозможна посылка отправителю слишком большой дейтограммы ICMP-сообщения из MPLS "туннеля", но конфигурация сети предоставляет возможность LSR конца туннеля получать слишком большие пакеты, которые должны проходить через туннель, тогда:
- LSR на передающем конце туннеля должен уметь определять MTU туннеля в целом. Он может это сделать путем посылки пакетов через туннель в направлении его приемной части, и выполняя процедуру определения MTU пути для этих пакетов.
- Всякий раз, когда передающий конец туннеля должен посылать пакет в туннель, и этот пакет имеет DF=1, а его длина превышает значение MTU туннеля, передающий конец должен послать ICMP-сообщение “Destination Unreachable” узлу, приславшему пакет с кодом "Fragmentation Required and DF Set ", и полем Next-Hop MTU установленным так, как показано выше.

4. Передача помеченных пакетов через PPP
Протокол PPP (Point-to-Point Protocol) [6] предоставляет стандартный метод транспортировки многопротокольных дейтограмм через каналы точка-точка. PPP определяет расширяемый протокол управления каналом и предлагает семейство протоколов управления сетью для установления и конфигурации различных протоколов сетевого уровня.
В этом разделе определен протокол управления сетью для установления и конфигурации коммутации меток в канале PPP.

4.1. Введение
PPP содержит три основные компонента:
1. Метод инкапсуляции мультипротокольных дейтограмм.
2. Протокол управления каналом LCP (Link Control Protocol ) установления, конфигурации и тестирования канала.
3. Семейство протоколов управления сетью для установления и конфигурирования различных протоколов сетевого уровня.
Для того чтобы установить связь через канал точка-точка, каждый конец PPP канала должен сначала послать LCP-пакеты, чтобы сконфигурировать и протестировать канал. После того как канал установлен и согласованы опционные возможности, как это требует LCP, PPP должен послать пакеты "MPLS Control Protocol", чтобы разрешить посылку помеченных пакетов. Как только "MPLS Control Protocol" оказался открыт, можно посылать помеченные пакеты через канал. Канал будет оставаться сконфигурирован для коммуникаций, пока управляющие протокольные пакеты LCP или MPLS его не закроют, или пока не произойдет какое-то внешнее событие (сработает таймер пассивности или не вмешается сетевой администратор).

4.2. Протокол управления PPP для MPLS
Протокол управления MPLS (MPLSCP) отвечает за разрешение/запрещение использования коммутации меток в канале PPP. Он использует тот же механизм обмена, что и протокол управления каналом LCP (Link Control Protocol). Пакеты MPLSCP не могут пересылаться до тех пор, пока PPP не достигнет фазы протокола сетевого уровня. Пакеты MPLSCP, полученные до достижения этой фазы, должны просто отбрасываться.
Протокол управления MPLS тождественен протоколу управления каналом [6] за следующими исключениями:
1. Модификации кадра
Пакет может использовать любые модификации базового формата кадра, которые были согласованы на фазе установления канала.

2. Поле протокола канального уровня
В информационное поле пакета PPP вкладывается только один пакет MPLSCP, где поле протокола PPP содержит шестнадцатеричный код 8281 (MPLS).

3. Поле кода
Используются только коды от 1 до 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack и Code-Reject). Прочие коды должны рассматриваться как нераспознанные и приводить к Code-Rejects.

4. Таймауты
Пакеты MPLSCP не могут пересылаться, пока PPP не достигнет фазы протокола сетевого уровня. Реализация должна быть готова ждать окончания аутентификации и определения качества канала, прежде чем наступит таймаут в ожидании Configure-Ack или других откликов.

4.3. Посылка помеченных пакетов
Прежде чем какие-либо пакеты будут посланы, PPP должен достичь фазы протокола сетевого уровня, и управляющий протокол MPLS должен стать активным (состояние Opened).
В информационное поле пакета PPP вкладывается только один помеченный пакет, где поле протокола PPP содержит шестнадцатеричные значения кода тип 0281 (MPLS Unicast) или 0283 (MPLS Multicast). Максимальная длина помеченного пакета, переданного через канал PPP, та же что и максимальная длина информационного поля инкапсулированного пакета PPP.
Заметим, что определены два кода для помеченных пакетов, один для мультикастных и один для уникастных. Как только MPLSCP переходит в рабочее состояние (Opened), по каналу PPP могут посылаться как мультикаст, так и уникаст-пакеты.

5. Пересылка помеченных пакетов в среде LAN
В каждом кадре транспортируется только один помеченный пакет. Записи стека меток размещаются непосредственно после заголовка сетевого уровня, а сразу за ними следует заголовок канального уровня, включая, например, любые заголовки 802.1Q, которые только могут существовать.
Шестнадцатеричный код Ethertype 8847 используется для индикации того, что кадр содержит уникастный MPLS-пакет. Шестнадцатеричный код Ethertype 8848 служит для указания того, что кадр содержит MPLS-пакет.
Эти значения Ethertype могут быть использованы либо при Ethernet-инкапсуляции, либо при инкапсуляции 802.3 LLC/SNAP для транспортировки помеченных пакетов. Процедура выбора одной из этих инкапсуляций находится вне пределов рассмотрения данного документа.

6. Соображения IANA
Значения меток 0-15 включительно имеют специальное назначение, как это определено в данном документе, или как позднее будет задано IANA. В этом документе, значения меток 0-3 специфицированы в разделе 2.1. Значения меток 4-15 могут быть определены IANA, на основе согласия с IETF.

7. Соображения безопасности
Инкапсуляция MPLS, которая специфицирована здесь, не предполагает какой-либо дополнительной безопасности, помимо той, что заложена в архитектуре MPLS [1] или в структуре протокола сетевого уровня.
Существует два соображения безопасности, следующие из архитектуры MPLS и рассматриваемые здесь:
- Некоторые маршрутизаторы могут реализовать процедуры безопасности, которые зависят от заголовка сетевого уровня, положение которого фиксировано по отношению к заголовку канального уровня. Эти процедуры не будут работать, когда используется MPLS-инкапсуляция, так как эта инкапсуляция имеет варьируемый размер.
- Метка MPLS имеет силу в результате соглашения между LSR, который заносит метку в стек ("автор метки"), и LSR, который интерпретирует эту метку ("читатель метки"). Однако стек меток не предлагает никаких средств определения того, кто является автором конкретной метки. Если помеченные пакеты восприняты от ненадежных источников, результатом может стать то, что пакеты будут маршрутизированы незаконным образом.

8. Библиография
[1] Rosen, E., Viswanathan, A., и R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[4] Mogul, J. и S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[7] Conta, A. и S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, December 1995.
[8] McCann, J., Deering, S. и J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. и G. Swallow, "MPLS Using LDP и ATM VC Switching", RFC 3035, January 2001.

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

Статусные коды, определенные в данной версии протокола LDP:

Код статуса

Статусные
данные

Заголовок раздела

Успех	0	0x00000000	TLV статуса
Плохой идентификатор LDP	1	0x00000001	Events Signaled by ... (События, сигнализируемые ...)
Плохая версия протокола	1	0x00000002	Events Signaled by ... (События, сигнализируемые ...)
Неверная длина PDU	1	0x00000003	Events Signaled by ... (События, сигнализируемые ...)
Неизвестный тип сообщения	0	0x00000004	Events Signaled by ... (События, сигнализируемые ...)
Неверная длина сообщения	1	0x00000005	Events Signaled by ...
Неизвестное TLV	0	0x00000006	Events Signaled by ...
Неверная длина TLV	1	0x00000007	Events Signaled by ...
Неверный формат значения TLV	1	0x00000008	Events Signaled by ...
Истекло время удержания	1	0x00000009	Events Signaled by ...
Shutdown	1	0x0000000A	Events Signaled by ...
Обнаружена петля	0	0x0000000B	Обнаружение петли
Неизвестный FEC	0	0x0000000C	Процедуры FEC
Нет маршрута	0	0x0000000D	Label Request Mess ... (Сообщение запроса метки)
Нет ресурсов для метки	0	0x0000000E	Label Request Mess ...
Ресурсы для метки/доступны	0	0x0000000F	Label Request Mess ...
Session Rejected/No Hello	1	0x00000010	Инициализация сессии
Session Rejected/Parameters Advertisement Mode	1	0x00000011	Инициализация сессии
Session Rejected/Parameters Max PDU Length	1	0x00000012	Инициализация сессии
Session Rejected/Parameters Label Range	1	0x00000013	Инициализация сессии
Истекло время таймера KeepAlive	1	0x00000014	Events Signaled by ...
Запрос метки аннулирован	0	0x00000015	Label Request Abort ... (Ликвидация запроса метки)
Отсутствуют параметры сообщения	0	0x00000016	Events Signaled by ...
Не поддерживаемое семейство адресов	0	0x00000017	Процедуры FEC Address Message Proc ...
Session Rejected/Bad KeepAlive Time	1	0x00000018	Инициализация сессии
Внутренняя ошибка	1	0x00000019	Events Signaled by ...

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

-->

D. Awduche, Requirements for Traffic Engineering Over MPLS, RFC-2702

1.0. Введение

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

Одним из наиболее важных применений MPLS будет управление трафиком. Важность этого приложения является уже широко признанной (смотри [1,2,3]).

Этот документ ориентирован исключительно на управление трафиком (Traffic Engineering) в рамках MPLS. Главной целью является рассмотрение требований управления трафиком в больших опорных сетях Интернет. Описаны базовые возможности и функциональности, которым должна соответствовать реализация MPLS.

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

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

2.0. Управление трафиком

В этом разделе описываются базовые функции управления трафиком в автономной системе современного Интернет. Рассмотрены ограничения IGP с точки зрения управления трафиком и ресурсами. В этом разделе обосновываются требования, предъявляемые к MPLS.

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

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

2.1. Объективные характеристики управления трафиком

Ключевые характеристики, сопряженные с управлением трафиком, могут относиться к следующим категориям:

1. ориентированные на трафик или

2. ориентированные на ресурсы.

Задачи, ориентированные на управление трафиком, включают в себя аспекты улучшения QoS информационных потоков. В модели “оптимальных усилий” для Интернет-сервиса ключевая задача управления трафиком включает в себя: минимизацию потерь пакетов и задержек, оптимизацию пропускной способности и согласование наилучшего уровня услуг. В данной модели минимизация вероятности потери пакетов является наиболее важным аспектом. Статистически заданные характеристики трафика (такие как разброс времени доставки пакетов, вероятность потери и максимальное время доставки) становятся важными в грядущих дифференцированных услугах Интернет. Одним из подходов решения таких проблем является оптимизация использования всех имеющихся ресурсов сети. В частности, желательно гарантировать, чтобы субнаборы сетевых ресурсов не были перегружены, в то время как аналогичные ресурсы на альтернативных маршрутах недогружены. Полоса пропускания является критическим ресурсом современных сетей. Следовательно, центральной функцией управления трафиком является эффективное управление пропускной способностью.

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

1. Когда сетевых ресурсов недостаточно или они не соответствуют существующей загрузке.

2. Когда потоки трафика неэффективно распределены по имеющимся ресурсам.

Первый тип проблем перегрузки может быть решен путем:

(i) расширения ресурса, или

(ii) применением классических средств управления перегрузкой, или

(iii) сочетанием этих подходов. Классическое управление перегрузкой пытается регулировать уровень потребности, снижая его до имеющегося в распоряжении уровня ресурсов. Классическое управление перегрузкой включает в себя: ограничение потока, управление шириной окна для потока, управление очередями в маршрутизаторе, диспетчеризацию и т.д. (смотри [8]).

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

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

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

2.2. Управление трафиком и ресурсами

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

В идеале управляющие действия должны включать:

1. Модификацию параметров управления трафиком,

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

3. Модификацию атрибутов и констант, связанных с ресурсами.

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

2.3. Ограничения механизмов управления IGP

В этом подразделе рассматриваются некоторые хорошо известные ограничения современных IGP с точки зрения управления трафиком.

Возможности управления, предлагаемые существующими внутренними протоколами маршрутизации шлюзов Интернет, не соответствуют требованиям управления трафиком. Это делает трудным актуализировать эффективные политики, предназначенные для решения проблем совершенствования работы сети. Действительно, IGP, базирующиеся на алгоритмах кратчайшего пути, вносят заметный вклад в проблемы перегрузки в автономных системах Интернет. Алгоритмы SPF базируются на простой аддитивной метрике. Эти протоколы управляются топологией, так что полоса пропускания и параметры трафика не являются факторами, рассматриваемыми в процессе принятия маршрутных решений. Следовательно, перегрузка часто происходит, когда:

1. кратчайшие пути нескольких потоков трафика объединяются в каких-то каналах или интерфейсах маршрутизатора, или

2. данный трафик потока маршрутизирован через канал или интерфейс маршрутизатора, который не имеет достаточной полосы пропускания.

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

Популярным подходом преодоления недостатков современных IGP является использование модели наложений, таких как IP поверх ATM или IP поверх frame relay. Модель наложений расширяет пространство для маневра, делая возможным произвольные виртуальные топологии, накладываемые поверх реальной физической сети. Виртуальная топология формируется из виртуальных каналов, которые проявляются как физические каналы в протоколах маршрутизации IGP. Модель наложений предоставляет дополнительные важные услуги для поддержания управления трафиком и ресурсами, включая: (1) маршрутизацию, базирующуюся на ограничениях в рамках VC, (2) поддержку административно конфигурируемых VC-путей, (3) сжатие маршрута, (4) функции управления доступом, (5) формирование трафика и функции реализации политики при управлении трафиком, и (6) надзор за VC. Эти возможности допускают реализацию самых разных политик в сфере управления трафиком. Например, виртуальные каналы могут легко перемаршрутизироваться, чтобы перенаправить трафик в менее загруженные каналы.

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

3.0. MPLS и управление трафиком

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

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

Концепция каналов передачи данных MPLS используется достаточно широко в данном документе. Согласно Li и Rekhter [3], канал передачи данных представляет собой объединение потоков данных одного и того же класса, которые следуют маршруту с коммутацией пакетов по меткам. Канал передачи данных представляет собой абстракцию трафика, с которой могут быть ассоциированы определенные характеристики. Полезно рассматривать каналы передачи данных как объекты, которые можно маршрутизировать, то есть, путь, по которому переносятся данные, может меняться. С этой точки зрения, каналы передачи данных подобны виртуальным каналам в сетях ATM и Frame Relay. Важно, однако, подчеркнуть, что существует фундаментальное отличие между каналом передачи данных и путем. LSP представляет собой спецификацию пути с коммутацией по меткам, через который проходит трафик. На практике, термины LSP и канал передачи данных часто используются синонимично.

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

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

(2) LSP могут поддерживаться эффективно,

(3) Каналы передачи данных могут быть смоделированы и поставлены в соответствие LSP,

(4) Набор атрибутов может быть ассоциирован с каналами передачи данных, которые регулируют их рабочие характеристики,

(5) Набор атрибутов может быть ассоциирован с ресурсами, которые ограничивают положение LSP и каналов передачи данных,

(6) MPLS позволяет как агрегацию так и дисагрегацию трафика, в то время как классическая переадресация на основе IP-адреса места назначения допускает только агрегацию,

(7) Относительно легко интегрировать "маршрутизацию на основе ограничений" в рамках MPLS,

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

Кроме того, через механизм коммутации меток MPLS позволяет наложить на современную модель маршрутизации Интернет квазиканальную коммутацию. Многие существующие предложения для управления трафиком посредством MPLS концентрируются на возможности формирования LSP. Хотя такая возможность является фундаментальной для управления трафиком, этого реально недостаточно.

3.1. Наведенный MPLS-граф

В данном подразделе вводится концепция "наведенного MPLS-графа", которая является центральной при управлении трафиком в сфере MPLS. Наведенный MPLS-граф аналогичен виртуальной топологии в модели наложений. Он логически проектируется на физическую сеть путем выбора LSP для каналов транспортировки трафика.

Наведенный MPLS-граф состоит из набора LSR, которые представляют собой узлы графа, и набора LSP, которые предоставляют логические соединение точка-точка между указанными LSR, и, следовательно, служат в качестве каналов наведенного графа. Имеется возможность сформировать иерархический наведенный MPLS-граф, базирующийся на концепции стеков меток (смотри [1]).

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

Пусть G = (V, E, c) является графом, отражающим физическую топологию сети. Здесь, V – набор узлов сети и E – набор каналов; то есть, для v и w из V, объект (v,w) содержится в E, если v и w являются непосредственно связанными в рамках G. Параметр "c" представляет собой набор емкостей и других ограничений, сопряженных с E и V. Мы будем рассматривать G как "основу" сетевой топологии.

Пусть H = (U, F, d) является наведенным MPLS-графом, где U является субнабором V, представляющим набор LSR в сети, или более точно набор LSR, которые являются конечными точками, по крайней мере, одного LSP. Здесь, F представляет собой набор LSP, так что для x и y из U, объект (x, y) находится в F, если существует LSP с x и y в качестве конечных точек. Параметр "d" представляет собой набор требований и ограничений, ассоциированных с F. Очевидно, H является ориентированным графом. Можно видеть, что H зависит от переходных характеристик G.

3.2. Фундаментальные проблемы управления трафиком в MPLS

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

- Первая проблема касается того, как определять соответствие пакетов определенному классу FEC (Forwarding Equivalence Class).

- Вторая проблема касается того, как определять соответствие FEC и каналов передачи данных.

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

Данный документ не касается первых двух перечисленных проблем (хотя они весьма важны). Вместо этого, остальная часть документа посвящена возможностям, которые позволяют третей функции осуществлять эффективную и надежную работу сетей. Установление соответствия между наведенным MPLS-графом (H) и базовой топологией сети (G) является достаточно важной проблемой.

4.0. Расширенные возможности управления трафиком с помощью MPLS

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

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

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

2. Набор атрибутов, связанных с ресурсами, которые ограничивают размещение пути информационных потоков. Они могут рассматриваться также как топологические ограничения.

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

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

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

5.0. Атрибуты и характеристики канала передачи данных

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

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

- В одноклассной модели обслуживания, такой как современный Интернет, канал передачи данных может включать в себя все потоки между входным LSR и выходным LSR.

- Каналы передачи данных являются маршрутизируемыми объектами (аналогично ATM VC).

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

- Каналы передачи данных являются однонаправленными.

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

Имеется два пункта особой важности: (1) параметризация каналов передачи данных и (2) положение маршрута и правила управления каналом передачи данных.

5.1. Двунаправленные каналы передачи данных

Хотя каналы передачи данных (traffic trunks) являются концептуально однонаправленными, во многих практических контекстах, полезно одновременно анализировать два канала передачи данных с идентичными конечными точками, но с разным направлением потоков. Два канала передачи данных логически связаны друг с другом. Один канал, называемый прямым, транспортирует трафик от исходного узла к узлу места назначения. Другой канал, называемый обратным, транспортирует трафик от узла места назначения к исходному узлу. Объединение двух таких каналов называется двунаправленным каналом передачи данных BTT (bidirectional traffic trunk), если выполняются следующие два условия:

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

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

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

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

5.2. Базовые операции для канала передачи данных

Базовые операции в канале передачи данных, важные для целей управления трафиком перечислены ниже.

- Установить (Establish): создать канал передачи данных.

- Активировать (Activate): запустить информационный обмен через канал передачи данных. Установление и активизация канала передачи данных логически не связанные события. Они могут, однако, быть реализованы в рамках одной операции.

- Деактивировать (Deactivate): Останавливать информационный поток через канал передачи данных.

- Модифицировать атрибуты (Modify Attributes): Изменить атрибуты канала передачи данных.

- Сменить маршрут (Reroute): Изменить маршрут канала передачи данных. Это может быть сделано административно или автоматически с помощью базовых протоколов.

- Ликвидировать (Destroy): Ликвидировать канал передачи данных и уведомить об имеющихся ресурсах. К таким ресурсам относится пространство меток и, возможно, дополнительная полоса пропускания.

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

5.3. Мониторирование аккоунтинга и работы

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

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

5.4. Базовые атрибуты управления трафиком каналов передачи данных

Атрибут канала передачи данных является параметром, который влияет на рабочие характеристики канала.

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

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

- Атрибуты параметров трафика

- Атрибуты управления и выбора пути

- Атрибут приоритета

- Атрибут приоритетной подмены (Preemption)

- Атрибут устойчивости (Resilience)

- Атрибут политики (Policing)

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

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

5.5. Атрибуты параметров трафика

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

5.6. Атрибуты управления и выбора пути

Атрибуты управления и выбора пути определяют правила выбора пути канала передачи данных, а также правила работы с маршрутами, которые уже существуют.

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

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

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

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

5.6.1. Административно специфицированные маршруты

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

Атрибут "path preference rule" (правило предпочтения пути) должно быть ассоциировано с административно специфицированными путями. Атрибут “правила предпочтения пути” представляет собой двоичную переменную, которая указывает, является ли административно сконфигурированный путь “обязательным” или нет.

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

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

5.6.2. Иерархия предпочтений для мультимаршрутов

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

5.6.3. Атрибуты сродства классов ресурсов (Resource Class Affinity)

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

<resource-class, affinity>; <resource-class, affinity>;

Параметр resource-class идентифицирует класс ресурса, для которого определено соотношение сродства в отношении канала передачи данных. Параметр affinity указывает на соотношение сродства; то есть, включены или исключены члены класса ресурсов в путь канала передачи данных. В частности, параметр affinity может быть двоичной величиной, которая принимает одно из следующих значений: (1) явное включение, и (2) явное исключение.

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

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

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

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

1. Для прямого включения, перед началом вычисления пути удалить все ресурсы, не принадлежащие специфицированным классам.

2. Для прямого исключения перед началом вычисления пути, удалить все ресурсы, принадлежащие специфицированным классам.

5.6.4. Атрибут адаптивности

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

Атрибут адаптивности (adaptivity) является частью блока параметров пути, ассоциированного с каналом передачи данных. Атрибут адаптивности, ассоциированный с каналом передачи данных, указывает на то, является ли канал субъектом реоптимизации. То есть, атрибут адаптивности представляет собой двоичную переменную, которая принимает одно из следующих значений: (1) разрешить реоптимизацию и (2) запретить реоптимизацию.

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

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

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

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

5.6.5. Распределение нагрузки в параллельных каналах передачи данных

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

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

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

5.7. Атрибут приоритета

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

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

5.8. Атрибут Preemption

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

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

Атрибут preemption может использоваться для спецификации четырех режимов приоритетного замещения для канала передачи данных: (1) замещающий объект активирован (preemptor enabled), (2) non-preemptor, (3) допускающий подмену и (4) не допускающий подмены. Канал передачи данных, где разрешено приоритетное замещение (preemptor enabled) может заменять каналы с более низким приоритетом, признанные, как приемлемые для замены. Канал передачи, специфицированный, как не подлежащий подмене, не может быть замещен каким-либо иным каналом, вне зависимости от их относительных приоритетов. Канал передачи данных, допускающий замещение, может быть замещен другим каналом с более высоким приоритетом, который имеет атрибут preemptor enabled.

Достаточно просто понять, что некоторые режимы замещения являются взаимно исключающими. Используя схему нумерации, описанную выше, можно назвать допустимые комбинации режимов для канала передачи данных: (1, 3), (1, 4), (2, 3) и (2, 4). Комбинация (2, 4) является режимом по умолчанию.

Канал передачи данных, скажем "A", может заместить другой канал, скажем "B", только если все следующие пять условий будут выполнены:

(i) "A" имеет относительно более высокий приоритет, чем "B",

(ii) "A" претендует на ресурс, используемый "B",

(iii) ресурс не может одновременно поддерживать "A" и "B",

(iv) "A" может быть приемником, и

(v) "B" допускает подмену.

Атрибут preemption не рассматривается, как обязательный атрибут современной модели обслуживания в Интернет (best effort service), хотя и является полезным. Однако, в сценарии с дифференциальными услугами, необходимость подмены становится очевидной. Более того, в появляющихся архитектурах оптического Интернет, где функции защиты и восстановления, чтобы уменьшить цену, могут быть перенесены с оптического уровня на информационные сетевые элементы (такие как гигабитные и терабитные маршрутизаторы с коммутацией по меткам), стратегии приоритетного замещения могут использоваться для сокращения времени восстановления канала в условиях сбоев.

5.9. Атрибут устойчивости (Resilience)

Атрибут resilience определяет поведение канала передачи данных в случае возникновения ошибок. То есть, когда ошибка происходит на пути, через который проходит канал. При таких обстоятельствах должны быть рассмотрены следующие проблемы: (1) детектирование ошибки, (2) уведомление об ошибке, (3) восстановление после сбоя. Очевидно, реализация MPLS должна содержать механизмы для решения всех этих задач.

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

1. Не нужно изменять маршрут канала передачи данных (traffic trunk). Например, схема живучести может уже существовать и быть реализована за счет альтернативного механизма, который гарантирует непрерывность обслуживания в случае сбоя без необходимости изменения маршрута канала передачи данных. Примером такой альтернативной схемы (конечно существует и много других), является ситуация, когда между двумя узлами имеется несколько параллельных каналов, и в случае отказа одного LSP, его трафик будет перераспределен между остальными LSP согласно некоторой заданной политике.

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

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

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

"Базовый" атрибут resilience указывает на процедуру восстановления, которая должна быть запущена для данного канала, при возникновении отказа. В частности, "базовый" атрибут resilience является двоичной переменной, которая определяет, будет ли данный канал изменять маршрут, если сегмент его пути выдал отказ. "Расширенный" атрибут resilience может использоваться для подробной спецификации действий в случае сценария отказа. Например, расширенный атрибут resilience может специфицировать набор альтернативных путей, которые следует использовать в случае отказа, а также правил, которые управляют относительным предпочтением для каждого специфицированного пути. Атрибуты resilience обеспечивают тесное взаимодействие между MPLS и маршрутизацией.

5.10 Атрибут Policing

Атрибут policing определяет действия, которые следует предпринять в рамках базовых протоколов, когда канал передачи данных становится нерабочим. То есть, когда какие-то параметры канала отклонились за оговоренные пределы. Вообще, атрибуты policing могут указывать, является ли неуправляемый канал передачи данных лимитированным по полосе пропускания, или он просто переадресуется без каких-либо действий, учитывающих местную политику. Если используется политика, тогда для реализации таких функций могут использоваться адаптации алгоритмов, таких как ATM GCRA [11].

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

Следовательно, с точки зрения управления трафиком необходимо иметь возможность административно разрешать и запрещать использование политики для каждого канала передачи данных (traffic trun).

6.0. Атрибуты ресурсов

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

6.1. Максимально выделяемая доля (Maximum Allocation Multiplie)

Максимально выделяемая доля MAM (maximum allocation multiplier) ресурса является административно задаваемым атрибутом, который определяет долю ресурса, доступную для канала передачи данных. Этот атрибут используется в основном для распределения полосы пропускания. Однако он может быть применен также для резервирования ресурсов LSR. Концепция MAM аналогична концепции параметров подписки и резервирования в сетях frame relay и ATM.

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

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

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

6.2. Атрибут класса ресурса

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

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

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

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

3. Ограничения положения каналов передачи данных для заданного субнабора ресурсов.

4. Реализации обобщенного включения/исключения политик.

5. Реализации политики ограничения локальности трафика. То есть, политики, которая ищет способы размещения трафика в пределах оговоренных топологических областей сети.

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

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

7.0. Маршрутизация, базирующаяся на ограничениях

В этом разделе обсуждается вопросы, связанные с маршрутизацией, основанной на ограничениях, используемой в доменах MPLS. В современной терминологии, маршрутизация, основанная на ограничениях, часто называется "QoS маршрутизацией", смотри [5,6,7,10].

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

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

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

- Атрибуты, связанные с каналами передачи данных (traffic trunks).

- Атрибуты, связанные с ресурсами.

- Другую информацию, характеризующую состояние топологии сети.

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

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

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

7.1 Базовые характеристики маршрутизации на основе ограничений

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

Вообще, известно, что проблема маршрутизации на основе ограничений трудно разрешима для большинства реалистичных ограничений. Однако, на практике для нахождения приемлемого пути, если он существует, может использоваться очень простая хорошо известная эвристика (смотри, например, [9]):

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

- Затем, для оставшегося графа связей запускается алгоритм поиска кратчайшего пути.

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

7.2 Соображения реализации

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

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

1. Путем расширения существующих IGP протоколов, таких как OSPF и IS-IS для поддержки маршрутизации на основе ограничений. Прилагаются усилия для решения этой задачи в отношении протокола OSPF (смотри [5,7]).

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

Рис. 1. Процесс маршрутизации, базирующийся на ограничениях, на уровне 3 LSR

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

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

- Механизмы работы с топологической статусной информацией.

- Взаимодействие между процессами маршрутизации на основе ограничений и процессами традиционных IGP.

- Механизмы выполнения требований адаптивности каналов передачи данных.

- Механизмы выполнение требований устойчивости и живучести каналов передачи данных.

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

8.0. Заключение

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

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

9.0. Библиография

[1] Rosen, E., Viswanathan, A. и R. Callon, "A Proposed Architecture for MPLS", Work in Progress.

[2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G. и A. Viswanathan, "A Framework for Multiprotocol Label Switching", Work in Progress.

[3] Li, T. и Y. Rekhter, "Provider Architecture for Differentiated Services и Traffic Engineering (PASTE)", RFC 2430, October 1998.

[4] Rekhter, Y., Davie, B., Katz, D., Rosen, E. и G. Swallow, "Cisco Systems' Tag Switching Architecture - Overview", RFC 2105, February 1997.

[5] Zhang, Z., Sanchez, C., Salkewicz, B. и E. Crawley "Quality of Service Extensions to OSPF", Work in Progress.

[6] Crawley, E., Nair, F., Rajagopalan, B. и H. Sandick, "A Framework for QoS Based Routing in the Интернет", RFC 2386, August 1998.

[7] Guerin, R., Kamat, S., Orda, A., Przygienda, T. и D. Williams, "QoS Routing Mechanisms и OSPF Extensions", RFC 2676, August 1999.

[8] C. Yang и A. Reddy, "A Taxonomy for Congestion Control Algorithms in Packet Switching Networks," IEEE Network Magazine, Volume 9, Number 5, July/August 1995.

[9] W. Lee, M. Hluchyi, и P. Humblet, "Routing Subject to Quality of Service Constraints in Integrated Communication Networks,"IEEE Network, July 1995, pp 46-55.

[10] ATM Forum, "Traffic Management Specification: Version 4.0" April 1996.

Характеристики существующих протоколов

Выше перечисленные характеристики суммированы в таблице 1 для неполного списка существующих мультикастных протоколов маршрутизации: DVMRP [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER], SSM [HOLB], SM [PERL].

Таблица 1.Систематика протоколов маршрутизации для IP-мультикастинга

<![if !supportEmptyParas]> <![endif]>DVMRPMOSPFCBTPIM-DMPIM-SMSSMSMАгрегация нет нет нет нет нет нет нетFlood & Prune да нет нет да нет нет опцияTree Type Отправитель Отправитель Совмещение Отправитель оба Отправитель СовмещениеСостояние сосуществования нет нет нет нет да нет нетНаправления - - 2 - 1 1 2Инкапсуляция нет нет да нет да нет даБез циклов нет нет нет нет нет нет нет

Из таблицы 1 можно видеть, например, что DVMRP использует большое число меток, когда дерево Flood & Prune L3 проектируется на дерево L2. Более того, так как DVMRP использует деревья отправителя, он не сталкивается с проблемой объединения, когда используется коммутация по меткам. Таблица может быть интерпретирована аналогичным образом для других протоколов.

Хотя MPLS является мультипротокольным как

Хотя MPLS является мультипротокольным как для L3, так и L2, на практике IP рассматривается в качестве единственного протокола для L3. MPLS может работать поверх нескольких технологий L2 (PPP/Sonet, Ethernet, ATM, FR и т.д.).

Когда переключение на основе меток переносится на уровень L2 (например, в качестве метки используются поля VPI/VCI), внимание фокусируется в основном на ATM [DAVI]. ATM предлагает высокие переключающие возможности и доступность обеспечения QoS, но в контексте имеет ряд ограничений, которые описаны в [DAVI]. Аналогичные соображения представлены для случая Frame Relay на уровне L2 в [CONT]. Ограничения можно суммировать как:

Ограниченное пространство меток: стандартизованное или реализованное число бит метки может быть мало (например, область VPI/VCI, пространство DLCI), ограничивая число LSP, которое может быть сформировано.Объединение: некоторые технологии или реализации L2 не поддерживают соединения многоточка-точка и/или многоточка-многоточка, блокируя объединение LSP.TTL: технологии L2 не поддерживают функцию TTL-декрементации.

Все три ограничения могут оказать сильное влияние на реализацию мультикастинга в MPLS.

Когда базовый MPLS будет разработан эти ограничения исчезнут. Более того, для каналов PPP и Ethernet может быть использована одна и та же метка для уникастного и мультикастного LSP, так как для уникастного и мультикастного определены разные коды EtherTypes [ROSE].

Идентификация интерфейса

В традиционном MPLS имеется неявная ассоциация каналов управления и данных. Когда имеет место такая ассоциация, не требуется никакой дополнительной или специальной информации, чтобы связать формирование определенного LSP с заданным каналом данных.

В случаях, где нет явной ассоциации каналов данных и управления, необходимо передавать дополнительную информацию, чтобы идентифицировать определенный канал данных, который требует управления. GMPLS поддерживает явную идентификацию канала данных, предоставляя ID интерфейса. GMPLS допускает использование нескольких схем идентификации интерфейсов, включая адреса IPv4 или IPv6, индексы интерфейсов (смотри [MPLS-UNNUM]) и составные интерфейсы (установленные посредством конфигурирования или протокола, такого как [LMP]). Во всех случаях выбор информационного интерфейса индицируется вышестоящим узлом с помощью адресов и идентификаторов.

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

Идентификация сбойного интерфейса

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

Идентификаторы LDP

Идентификатор LDP представляет собой 6-октетный код, используемый для идентификации пространства меток LSR. Первые четыре октета идентифицируют LSR и должны быть глобально уникальными, такими как 32-битный идентификатор маршрутизатора, присвоенный LSR. Последние два октета идентифицируют специфическое пространство меток LSR. Последние два октета идентификаторов LDP для ориентированного на платформу пространства меток всегда равны нулю. В данном документе используется следующее представление идентификаторов LDP:

напр., lsr 171:0, lsr19:2.

Заметим, что LSR, который управляет и анонсирует несколько пространств меток, использует различные идентификаторы LDP для каждого пространства меток.

Ситуация, где LSR требует анонсировать более одного пространства меток и, следовательно, использует более одного идентификатора LDP, реализуется, когда LSR имеет более одного АТМ-канала до партнера (и работает с пространством меток интерфейса). Другая ситуация возникает, когда LSR имеет два канала до партнера, один из которых работает через Ethernet (и использует пространство меток, ориентированное на платформу), а другой реализован через ATM.

Идентификаторы LDP и адреса следующего шага

LSR сохраняет полученные метки в информационной базе данных меток LIB (Label Information Base). При работе в режиме Downstream Unsolicited, запись в LIB для адресного префикса ассоциирует набор пар (идентификатор LDP, метка) с префиксом, по одной записи для пары партнеров, анонсирующих метку для префикса.

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

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

Чтобы LSR мог установить соответствие между идентификаторами партнеров LDP и их адресами, LSR передают свои адреса, используя сообщения Address и Withdraw Address (отзыв адреса).

LSR посылает сообщение Address, чтобы предоставить свой адрес партнеру. LSR посылает сообщение Withdraw Address, чтобы отозвать адрес, присланный ранее партнеру.

Иерархия

За счет механизма стека меток, MPLS позволяет вложенное LSP-туннелирование с любой глубиной вложения. Видно, что с таким вложением, операция push для уровня N+1 осуществляется последующим (или тем же) LSR по отношению LSR, выполняющим push для уровня N, в то время как команда pop уровня N+1 выполняется на предыдущем (или том же) LSR по отношению к LSR, выполняющим pop уровня N. Для заданного уровня N LSP, входной LSR, выполняющий push, и LSR, выполняющий pop (предпоследний LSR или конец LSP), должен работать в рамках той же модели туннеля (т.е., труба, короткая труба или однородная модель). Однако не существует ограничений для совместимых моделей туннелирования разных уровней, так что для LSP на различных уровнях могут использоваться разные модели туннелирования. Иерархия операций проиллюстрирована ниже (рис. 7) для случая двух уровней туннелей:

(1) Модель туннеля 1
(2) Модель туннеля 2
Рис. 7.

Туннельная модель 2 может быть той же, но может и отличаться от модели 1. Для заданного LSP уровня N, LSR должен определить входное PHB и занести информацию Diff-Serv, как это описано в разделе 2.6.2, 2.6.2.1 и 2.6.3 согласно модели туннелирования уровня N LSP и вне зависимости от туннельной модели других уровней LSP.

Иерархия и партнерство в рассылке меток

Предположим, что пакет P транспортируется на уровне 1 LSP <R1, R 2, R3, R4>, и при транспортировке из R2 в R3 движется по LSP уровня 2 <R2, R21, R22, R3>. С точки зрения LSP уровня 2, партером рассылки меток R2 является R21. С точки зрения LSP уровня 1, партерами рассылки меток R2 являются R1 и R3. Могут существовать партеры обмена метками на каждом уровне иерархии. В разделах 3.6 и 3.7 рассмотрены некоторые способы реализации этой иерархии. Заметим, что в этом примере R2 и R21 должны быть IGP-соседями, но R2 и R3 не обязательно ими являются.

Когда два LSR являются соседними IGP, мы называем их "локальными партнерам рассылки меток". Когда два LSR могут быть партнерами рассылки меток, но не являются соседними IGP, мы называем их "удаленными партнерами распределения меток". В выше приведенном примере R2 и R21 являются локальными партнерами рассылки меток, а R2 и R3 являются удаленными партнерами рассылки меток.

Архитектура MPLS поддерживает два способа рассылки меток на различных уровнях иерархии: явное и неявное партнерство (Peering).

Рассылка меток (пиринг) осуществляется путем обмена протокольными сообщениями, которые адресованы партнеру. Возможен обмен метками и с удаленным партнером. Это возможно одним из двух путей:

1. Явное партнерство

При явном партнерстве, метки пересылаются партнеру в протокольных сообщениях так же, как это делается при локальном обмене. Эта методика наиболее полезна, когда число удаленных партнеров мало, или число ассоциаций высокого уровня велико, или удаленные партнеры обмена метками размещены в удаленных областях или доменах. Конечно, может быть нужно знать, какие метки следует послать какому партнеру; это рассмотрено в разделе 3.1.2. Примеры использования явного партнерства представлены в разделе 3.2.1 и 3.6.

2. Неявное партнерство

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

Эта техника наиболее полезна, когда число удаленных партнеров обмена метками велико. Неявное партнерство не требует сетки партнеров n-квадрат, чтобы разослать метки удаленным партнерам, так как имеется подстраховка за счет локального обмена информацией. Однако неявное партнерство требует, чтобы промежуточные узлы запоминали информацию, в которой они могут быть заинтересованы. Пример использования неявного партнерства можно найти в разделе 3.3.

Иерархия: LSP туннели в LSP

Рассмотрим LSP <R1, R2, R3, R4>. Предположим, что R1 получил непомеченный пакет P, и заносит метку в его стек, чтобы пакет следовал заданным путем (путь шаг-за-шагом). Предположим далее, что R2 и R3 не являются непосредственно связанными, но они являются виртуальными соседями, так как представляют собой конечные точки LSP-туннеля. Итак, действительная последовательность LSR, через которые проходит P, соответствует <R1, R2, R21, R22, R23, R3, R4>. Когда P транспортируется из R1 в R2, он имеет глубину стека равную 1. R2, коммутирующий метки, определяет, что P должен войти в туннель. R2 сначала замещает входную метку меткой, имеющей смысл для R3. Затем он заносит метку в стек. Эта метка второго уровня имеет значение, понятное R21. Коммутация осуществляется для метки на уровне 2 устройствами R21, R22, R23. R23, который является предпоследним узлом в туннеле R2-R3, удаляет метку из стека до того, как будет выполнена переадресация пакета в R3. Когда R3 видит пакет P, P имеет только метку уровня 1, и покидает туннель. Так как R3 является предпоследним шагом P в LSP, он удаляет метку из стека, а R4 получает P непомеченным. Механизм стека меток допускает любую глубину вложения LSP-туннелей.

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

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

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

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

any as-any rs-any peeras
and or not
atomic from to at action accept announce except refine
networks into inbound outbound

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

<as-number>	Номер AS x представляется в виде строки "ASx". То есть автономная система 226 характеризуется с помощью AS226.
<ipv4-address>	Адрес IPv4 характеризуется последовательностью из четырех целых чисел, лежащих в диапазоне от 0 до 255, разделенные символом точка ".". Например, 192.148.166.48.
<address-prefix>	Адресный префикс представляет собой IPv4-адрес, за которым следует символ косой черты "/" и без пробела целое число, лежащее в диапазоне 0-32. Примерами адресных префиксов могут служить:

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

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

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

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

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

<date>	Дата представляется в виде восьми десятичных цифр вида YYYYMMDD, где YYYY отображает год, MM представляет месяц (01 - 12) и DD характеризует день месяца (01 - 31). Все даты, если не определено что-то иное, задаются в стандарте UTC. Например, 07 июля 1938 представляется в виде 19380707.
<email-address>	описано в RFC-822 [10].
<dns-name>	описано в RFC-1034 [17].
<nic-handle>	представляет собой уникальный идентификатор, используемый при маршрутизации, присвоении адресов и т.д. для того, чтобы обеспечить однозначную ссылку на контактную информацию. Классы person и role связывают указатели NIC с действительными именами людей и контактной информацией.
<free-form>	представляет собой последовательность ASCII-символов.
<X-name>	является именем объекта типа X. То есть <mntner-name> является именем объекта mntner.
<registry-name>	является именем регистратора IRR.

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

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

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

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

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

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

Информация административного состояния

Административная статусная информация транспортируется в новом объекте/TLV. Эта информация используется в настоящее время двумя способами. В первом информация характеризует административное состояние, сопряженное с определенным LSP. В таком применении, административная статусная информация отображает состояние LSP. Индикация состояния включает в себя "up" или "down", если система находится в режиме тестирования, и если маршрут ликвидируется. Действия, предпринимаемые узлом, базируются на локальных статусных характеристиках. Примером действия, которое может быть предпринято, является запрет уведомления о сигнале тревоги, когда LSP находится в состоянии "down" или в тестовом режиме, или сообщение уведомления о тревоге, связанное с соединением, имеющем приоритет равный или меньше чем "Non service affecting" (не влияет на обслуживание).

Во втором способе использование административной статусной информации, может означать запрос установления состояния LSP. Эта информация всегда относится к входному узлу, который обрабатывает запрос. Подробности смотри в [RFC3473] и [RFC3472]. Использование административной статусной информации для конкретного LSP является опционным.

Информация о полосе пропускания

Информация о полосе пропускания может быть также согласована на фазе формирования канала E-LSP и L-LSP, например, для целей управления трафиком, используя параметры трафика TLV, как это описано в [MPLS CR LDP].

Информационные ссылки

[GMPLS-RTG]		Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress.
[GMPLS-SONET]		Ashwood-Smith, P., et al., "GMPLS - SONET/SDH Specifics", Work in Progress.
[LMP]		Lang, et al., "Link Management Protocol", Work in Progress.
[MPLS-BUNDLE]		Kompella, K., Rekhter, Y. и L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[MPLS-HIERARCHY]		Kompella, K. и Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[RFC2026]		Bradner, S., "The Internet Standards Process --Revision 3," BCP 9, RFC 2026, October 1996.
[RFC2434]		Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998./td>
[RFC3031]		Rosen, E., Viswanathan, A. и R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001.

[BCP26]		Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[MPLS-HIERARCHY]		Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[PAN-RESTART]		Pan, P., et. al., "Graceful Restart Mechanism for RSVP-TE", Work in Progress.
[RFC2026]		Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

Информирование о событиях с помощью сообщений уведомления

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

Инициализация и выделение сетевого адреса

Клиент начинает работу в состоянии INIT и формирует сообщение DHCPDISCOVER. Клиент должен ждать случайное время в интервале 1-10 секунд, для того чтобы десинхронизовать процессы при запуске DHCP. Клиент устанавливает 'ciaddr' равным 0x00000000. Клиент может запросить специфические параметры путем включения опции 'parameter request list'. Клиент может предложить сетевой адрес и/или время действия набора параметров путем включения опций 'запрошенный IP-адрес' и 'IP-address lease time'. Клиент должен включить его аппаратный адрес в поле 'chaddr', если это необходимо для доставки DHCP-откликов. Клиент может включить уникальный идентификатор в опцию 'client identifier', как это описано в разделе 4.2. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включать этот список во все последующие сообщения.

Клиент генерирует и записывает случайный идентификатор транзакции, вставляет этот идентификатор в поле 'xid'. Клиент записывает свое локальное время для использования позднее при вычислении времени пригодности набора конфигурационных параметров. Клиент затем посылает широковещательно DHCPDISCOVER по локальному аппаратному адресу 0xffffffff, по широковещательному IP-адресу и UDP-порту 'DHCP-сервера'.

Если 'xid' приходящего сообщения DHCPOFFER не согласуется с 'xid' последнего сообщения DHCPDISCOVER, сообщение DHCPOFFER должно молча игнорироваться. Любое приходящее сообщение DHCPACK должно молча игнорироваться.

Клиент собирает сообщения DHCPOFFER за определенный период времени, выбирает одно сообщение DHCPOFFER из числа приходящих сообщений DHCPOFFER (например, первое сообщение DHCPOFFER или сообщение DHCPOFFER от сервера, используемого ранее) и извлекает адрес сервера из опции 'server identifier' сообщения DHCPOFFER. Время, в течение которого клиент собирает сообщения, и механизм, используемый для выбора одного DHCPOFFER зависит от конкретной реализации.

Таблица 5. Поля и опции, используемые клиентами DHCP

Поле

DHCPDISCOVER
DHCPINFORM DHCPREQUEST DHCPDECLINE,
DHCPRELEASE 'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST 'htype' Из RFC"Assigned Numbers" 'hlen' Длина аппаратного адреса в октетах 'шаги' 0 0 0 'xid' выбрано клиентом 'xid' из сообщения сервера DHCPOFFER выбрано клиентом 'secs' 0 или число сек с момента, когда HCP-процесс запущен 0 или число сек со времени, когдаDHCP- процесс запущен 0 'флаги' Устанавливает 'BROADCAST'-флаг, если клиент требует широковещательного отклика Устанавливает 'BROADCAST' флаг, если клиент требует широковещательного отклика 0 'ciaddr' 0 (DHCPDISCOVER) сетевой адрес клиента(DHCPINFORM) 0 или сетевой адрес клиента (BOUND/RENEW/REBIND) 0 (DHCPDECLINE) сетевой адрес клиента (DHCPRELEASE) 'yiaddr' 0 0 0 'siaddr' 0 0 0 'giaddr' 0 0 0 'chaddr' аппаратный адрес клиента аппаратный адрес клиента аппаратный адрес клиента 'sname' опции, если указано в 'sname/file' опция; иначе не используется опции, если указано в 'sname/file' опция; иначе не используется (не используется) 'файл' опции, если указано в 'sname/file' опция; иначе не используется опции, если указано в 'sname/file' опция; иначе не используется (не используется) 'опции' опции опции (не используется)

Опция

DHCPDISCOVER
DHCPINFORM DHCPREQUEST DHCPDECLINE,
DHCPRELEASE Requested IP-address Может (DISCOVER)
не должен (INFORM) Должен (в SELECTING или INIT-REBOOT)
не должен (в BOUND или RENEWING) Должен (DHCPDECLINE),
не должен (DHCPRELEASE) IP-address lease time Может (DISCOVER)
не должен (INFORM) Может Не должен Использование полей 'file'/'sname' Может Может Может Тип сообщения DHCP DHCPDISCOVER/ DHCPINFORM DHCPREQUEST DHCPDECLINE/ DHCPRELEASE Идентификатор клиента Может Может Может Vendor class identifier Может Может Не должен Идентификатор сервера Не должен Должен (после SELECTING)

Не должен (после INIT-REBOOT, BOUND, RENEWING или REBINDING) Должен Parameter request list Может Может Не должен Maximum message size Может Может Не должен Message Не следует Не следует Следует Site-specific Может Может Не должен Прочие Может Может Не должен Если параметры приемлемы, клиент записывает адрес сервера, который предоставляет параметры из поля 'server identifier' и посылает этот адрес в поле 'server identifier' широковещательного сообщения DHCPREQUEST. Раз от сервера пришло сообщение DHCPACK, клиент инициализирован и переходит в состояние BOUND. Сообщение DHCPREQUEST содержит тот же 'xid' что и сообщение DHCPOFFER. Клиент записывает время истечения действия конфигурационного набора как сумму времени, когда был послан исходный запрос и длительности действия конфигурационного набора из сообщения DHCPACK. Клиент должен выполнить проверку предложенного адреса, чтобы убедиться, что адрес не используется. Например, если клиент находится в сети, которая поддерживает ARP, клиент может послать запрос ARP для предложенного адреса. При посылке широковещательного ARP-запроса для предлагаемого адреса, клиент должен записать туда, как отправитель, свой аппаратный адрес, и 0 в качестве IP-адреса отправителя, чтобы исключить конфликт с ARP-кэшами в других ЭВМ той же субсети. Если оказалось, что сетевой адрес используется, клиент должен послать серверу сообщение DHCPDECLINE. Клиент должен широковещательно послать ARP-отклик, чтобы уведомить о новом IP-адресе клиента и удалить устаревшие записи из ARP-кэша ЭВМ, размещенных в той же субсети.

Инициализация машины состояний

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

Таблица переходов между состояниями при инициализации сессии

Состояние

Событие

Новое состояние
NON EXISTENT	Сессия TCP-соединения установлена		INITIALIZED
INITIALIZED	Передача сообщения инициализации (Активная роль)	OPENSENT
	Получение приемлемого сообщения инициализации. (Пассивная роль)	OPENREC
	Действие: Передача сообщения инициализации и KeepAlive
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: Передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPENREC	Получение сообщения KeepAlive	OPERATIONAL
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: Передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPENSENT	Получение приемлемого сообщения инициализации	OPENREC
	Действие: Передача сообщения KeepAlive
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: Передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPERATIONAL		Получение сообщения Shutdown	NON EXISTENT
	Действие: передача сообщения Shutdown и закрытие транспортного соединения
		Получение других сообщений LDP	OPERATIONAL
	Таймаут	NON EXISTENT
		Действие: Передача сообщения завершения и закрытие транспортного соединения

Инициализация PEP

Спустя некоторое время после установления соединения между PEP и удаленным PDP, после согласования условий обеспечения безопасности (если это требуется), PEP пошлет удаленному PDP одно или более сообщение Client-Open, по одному для каждого поддерживаемого PEP типов клиента. Сообщение Client-Open должно содержать адрес последнего PDP, с которым PEP хранит полный набор решений. Если не поступило ни одного решения от предыдущего PDP, объект LastPDPAddr не должен быть включен в сообщение Client-Open (смотри раздел 2.5). Каждое сообщение Client-Open должно, по крайней мере, содержать общий заголовок, указывающий на один тип клиента, который поддерживает PEP. Удаленный PDP откликнется сообщениями Client-Accept для каждого типа клиента, запрошенного PEP и поддерживаемого PDP.

Если какой-то конкретный тип клиента не поддерживается PDP, PDP будет реагировать с помощью Client-Close, специфицируя неподдерживаемый тип клиента, и возможно предлагая альтернативный PDP-адрес и номер порта. В противном случае, PDP пошлет Client-Accept, специфицируя временную выдержку между сообщениями keep-alive, а PEP может начать посылку запросов PDP.

Инициализация при известном сетевом адресе

Клиент начинает работу в состоянии INIT-REBOOT и посылает сообщение DHCPREQUEST. Клиент должен вставить свой сетевой адрес в опцию 'requested IP-адрес' сообщения DHCPREQUEST. Клиент может запросить специфические конфигурационные параметры, включив опцию 'parameter request list'. Клиент генерирует и записывает случайный идентификатор транзакции и заносит этот идентификатор в поле 'xid'. Клиент записывает свое локальное время для последующего использования при вычислении времени истечения пригодности конфигурационного набора параметров. Клиент не должен включать 'server identifier' в сообщение DHCPREQUEST. Клиент затем широковещательно посылает DHCP-серверу сообщение DHCPREQUEST с использованием аппаратного широковещательного адреса и UDP-порта.

Раз от какого-то сервера пришло сообщение DHCPACK с полем 'xid' согласующимся с тем, которое содержится в сообщении клиента DHCPREQUEST, клиент инициализирован и он переходит в состояние BOUND. Клиент записывает время истечения годности конфигурационного набора параметров, которое равно сумме времени, когда было послано сообщение DHCPREQUEST и длительности пригодности конфигурационного набора, взятого из сообщения DHCPACK.

Инициализация при сетевом адресе заданном извне

Клиент посылает сообщение DHCPINFORM, клиент может запросить специфические конфигурационные параметры путем включения их в опцию 'parameter request list'. Клиент генерирует и записывает случайный идентификатор транзакции и вводит его в поле 'xid'. Клиент помещает свой сетевой адрес в поле 'ciaddr'. Клиенту не следует запрашивать параметры времени действия конфигурационного набора.

Клиент посылает уникастное сообщение DHCPINFORM DHCP-серверу, если он знает адрес сервера, в противном случае он посылает это сообщение широковещательно. Сообщения DHCPINFORM должны быть направлены 'DHCP-серверу ' через UDP-порт.

Раз от любого из серверов получено сообщение DHCPACK с полем 'xid', согласующимся с тем, что содержалось в сообщении клиента DHCPINFORM, клиент инициализирован.

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

Инициализация сессии

После того как LSR1 и LSR2 установят транспортное соединение, они согласуют параметры сессии путем обмена сообщениями инициализации LDP. Согласуемые параметры включают в себя версию протокола, метод рассылки меток, значения таймера, диапазоны VPI/VCI для управляемого метками ATM, диапазоны DLCI для управляемого метками Frame Relay и т.д..

Успешное согласование завершается установлением LDP-сессии между LSR1 и LSR2 для анонсирования пространств меток LSR1:a и LSR2:b. Далее описана инициализация сессии с точки зрения LSR1.

После того как соединение установлено, если LSR1 играет активную роль, он начинает согласование параметров сессии путем посылки LSR2 сообщения инициализации. Если LSR1 пассивен, он ждет, пока LSR2 не инициализирует согласование параметров.

Вообще, когда существует несколько каналов между LSR1 и LSR2 и несколько пространств меток, которые им нужно анонсировать, пассивный LSR не может знать, какое пространство меток следует анонсировать через вновь установленное TCP-соединение, до тех пор пока не получит сообщение инициализации. Сообщение инициализации содержит в себе идентификатор LDP для пространства меток отправителя (активный LSR) и идентификатор LDP для пространства меток получателя (пассивный LSR).

Ожидая сообщение инициализации от своего партнера, пассивный LSR может согласовать пространство меток, которое должно анонсироваться партнером (как это определено идентификатором LDP в заголовке PDU сообщения инициализации), с сопредельностью Hello, сформированной при обмене сообщениями Hello.

1. Когда LSR1 играет пассивную роль:

Если LSR1 получает сообщение инициализации, он пытается согласовать идентификатор LDP, содержащийся в PDU сообщения, с сопредельностью Hello.

Если подходящая Hello сопредельность имеется, она характеризует локальное пространство меток для данной сессии.

Далее LSR1 проверяет, являются ли приемлемыми предложенные в сообщении параметры сессии. Если да, LSR1 откликается сообщением инициализации с параметрами, которые он намерен использовать, и сообщением KeepAlive, чтобы сообщить о приемлемости параметров LSR2. Если параметры не приемлемы, LSR1 откликается сообщением об ошибке Session Rejected/Parameters и закрывает TCP-соединение.

Если LSR1 не может найти подходящую сопредельность Hello (Hello adjacency), он посылает сообщение об ошибке Session Rejected/No Hello Error и закрывает TCP-соединение.

Если в ответ на сообщение инициализации LSR1 получает KeepAlive, сессия с точки зрения LSR1 является рабочей.

Если LSR1 получает сообщение об ошибке, LSR2 отклоняет предложенную сессию и LSR1 закрывает TCP-соединение.

2. Когда LSR1 играет активную роль:

Если LSR1 получает сообщение об ошибке, LSR2 отвергает предложенную сессию, а LSR1 закрывает TCP-соединение.

Если LSR1 получает сообщение инициализации, он проверяет, приемлемы ли параметры сессии. Если да, то откликается сообщением KeepAlive. Если параметры сессии не приемлемы, LSR1 посылает сообщение об ошибке Session Rejected/Parameters и закрывает соединение.

Если LSR1 получает сообщение KeepAlive, LSR2 воспринял предложенные им параметры сессии.

Когда LSR1 получил как приемлемое сообщение инициализации, так и сообщение KeepAlive, сессия с точки зрения LSR1 работоспособна.

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

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

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

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

Из-за асимметричной природы установления сессии, реконфигурация пассивного LSR пройдет незаметно для активного LSR. В разделе "Сообщение Hello" описан опционный механизм, который может использовать LSR, чтобы сигнализировать потенциальным LDP-партнерам, что он был реконфигурирован.

Инкапсулированные мультикастинг данные

Отправители однонаправленных совмещенных деревьев и отправители, не являющиеся узлами двунаправленных совмещенных деревьев, инкапсулируют данные на пути к корневому узлу. Данные затем декапсулируются в корневом узле. Инкапсуляция и декапсуляция мультикастных данных осуществляется на уровне L3.

Таким образом, в случае инкапсуляции/декапсуляции путь может вообще не совпадать с LSP: трафик не может быть ни переадресован на L2 через интерфейс Register DRsend (инкапсуляция), ни попасть в корневой узел на L2 (декапсуляция).

Замечания Если LSR поддерживает смешанную L2/L3 переадресацию (раздел 4), трафик (S,G) в DRsend может переадресовываться на L2 через любой выходной интерфейс, отличный от Register. Инкапсулированный трафик может выиграть от использования переключения по меткам.Если корневой узел решает присоединиться к отправителю (чтобы избежать инкапсуляции/декапсуляции), может быть сформирован LSP точка-точка (S,G).

IntServ и RSVP

RSVP может использоваться для формирования мультикастных деревьев с заданным QoS. Важным следствием использования мультикастинга является проблема, как связать парадигму 'гетерогенных получателей' с уровнем L2 (заметим, что эта задача не решена и в IP). Этот предмет серьезно обсуждается в [CRAW]. Прагматическими подходами являются модель ограниченной гетерогенности, которая допускает уровень услуг “максимальных усилий” (best effort) и один уровень QoS (например, QoS, предложенный отправителем в сообщении RSVP Path) и гомогенная модель, которая допускает только один уровень QoS.

Первый поход приводит к формированию полных деревьев для каждого класса услуг. Отправитель должен послать свой трафик в сеть дважды (например, 1 в дерево “максимальных усилий” и 1 - в дерево QoS). В обоих деревьях может использоваться коммутация по меткам.

При втором подходе конструируется одно дерево и пользователи услуги “максимальных усилий” подключаются к дереву QoS. Если ветви, созданные для пользователей “максимальных усилий” не используют коммутацию по меткам, (таким образом, следуя шаг-за-шагом вдоль LSP), мультикастный QoS-трафик должен следовать этим LSP по умолчанию. Эта функция может быть предоставлена системой смешанной переадресации L2/L3, описанной в разделе 4. Если она недоступна, объединение необходимо, чтобы избежать возврата на L3 в QoS LSP.

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

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

operator=(integer[0, 65535])

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

	med
	# установить med равным 10: med = 10;
	# установить med метрике IGP: med = igp_cost;
	operator=(union integer[0, 65535], enum[igp_cost])

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

	dpa
	operator=(integer[0, 65535])

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

	aspath
	# prepends AS numbers from last to first order
	prepend(as_number, ...)

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

	# - 4-байтовому целому (ok to use 3561:70 notation)
	# - internet, no_export, no_advertise (смотри RFC-1997)
	community_elm union
	integer[1, 4294967295],
	enum[internet, no_export, no_advertise],

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

community_list list of community_elm

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

	community
	# set to a list of communities
	operator=(community_list)
	# добавить значения community
	operator.=(community_list)
	append(community_elm, ...)
	# удалить значения community
	delete(community_elm, ...)
	# фильтр: true если содержится одно из значений community
	contains(community_elm, ...)
	# shortcut to contains: community(no_export, 3561:70)
	operator()(community_elm, ...)
	# сравнение равенства, независящее от порядка
	operator==(community_list)
rp-attribute:			# следующий маршрутизатор в статическом маршруте next-hop
	# установить равным 7.7.7.7: next-hop = 7.7.7.7;
	# установить собственный адрес маршрутизатора: next-hop = self;
	operator=(union ipv4_address, enum[self])
rp-attribute:		# цена статического маршрута cost

		operator=(integer[0, 65535])
protocol:		BGP4
	# номер AS маршрутизатора партнера
	MANDATORY asno(as_number)
	# разрешить гашение осцилляций маршрута
	OPTIONAL flap_damp()
	OPTIONAL flap_damp(integer[0,65535],
			# penalty per flap
			integer[0,65535],
			# penalty value for supression
			integer[0,65535],
			# penalty value for reuse
			integer[0,65535],
			# halflife in secs when up
			integer[0,65535],
			# halflife in secs when down
			integer[0,65535])
			# максимальный штраф

protocol: OSPF
protocol: RIP
protocol: IGRP
protocol: IS-IS
protocol: STATIC
protocol: RIPng
protocol: DVMRP
protocol: PIM-DM
protocol: PIM-SM
protocol: CBT
protocol: MOSPF

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

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

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

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

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

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

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

x.method(arguments)
x "op" argument

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

pref = 10;

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

med = 0;
med = igp_cost;

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

dpa = 100;

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

community .= { 100 };
community .= { NO_EXPORT };
community .= { 3561:10 };

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

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

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

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

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

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

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

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

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

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

aspath.prepend(AS1);
aspath.prepend(AS1, AS1, AS1);

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

med = -50;	# -50 лежит вне диапазона
med = igp;	# igp не является одним из значений enum
med.assign(10);	# заданный метод не определен
community.append(AS3561:20);

# первый аргумент должен быть равен 3561. На рис. .28 показан более продвинутый пример, использующий rp-атрибут community. В этом примере, AS3561 базирует свое предпочтение при выборе маршрута на атрибуте community. Другие AS могут апосредовано влиять на выбор маршрутов AS3561 путем включения соответствующих значений communities в их оповещения о маршрутах.

aut-num: AS1

export:	to AS2 action community.={3561:90};
	to AS3 action community.={3561:80};
	announce AS1

as-set: AS3561:AS-PEERS
members: AS2, AS3

aut-num: AS3561

import:	from AS3561:AS-PEERS
	action pref = 10;
	accept community(3561:90)
import:	from AS3561:AS-PEERS
	action pref = 20;
	accept community(3561:80)
import:	from AS3561:AS-PEERS
	action pref = 20;
	accept community(3561:70)
import:	from AS3561:AS-PEERS
	action pref = 0;
	accept ANY

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

Использование дескриптора клиента (Client Handle)

Дескриптор клиента служит для идентификации уникального состояния запроса для каждого из типов клиента для одного PEP. Дескрипторы клиента выбираются PEP и являются недоступными для PDP. PDP просто использует дескриптор запроса, чтобы однозначно идентифицировать состояние запроса для конкретного типа клиента, для конкретного TCP-соединения, и тем самым связать его решения с соответствующим запросом. Дескрипторы клиента инициализируются в сообщениях запроса и используются в последующих сообщениях запроса, решения и отчета для ссылки на то же состояние запроса. Когда PEP готов удалить состояние локального запроса, он посылает сообщение удаления (delete) PDP для соответствующего дескриптора клиента. Дескрипторы, относящиеся к различным состояниям запроса, должны быть уникальны в рамках контекста конкретного TCP-соединения и типа клиента.

Использование классов трафика ATM и механизмы управления трафиком

Применение "категорий услуг ATM" специфицированных форумом ATM, "ATM Transfer Capabilities", определенных союзом ITU-T или поставщиком специфических классов трафика ATM находятся вне области рассмотрения данным документом. Единственным требованием для совместимых реализаций является общность принципов переадресации на основе ВА для L-LSP в среде ATM LSR Diff-Serv.

Так как имеется только один бит (CLP) для кодирования PHB приоритета отбрасывания в каналах ATM, в ATM LSR поддерживается только два разных уровня приоритета отбрасывания. В разделах 4.2.2 и 4.4.2 определено, как три уровня приоритета отбрасывания AFn OA ставятся в соответствие двум уровням приоритетов отбрасывания в ATM. Это соответствие находится в согласии с требованиями, специфицированными [DIFF_AF] для случая, когда поддерживается только два уровня приоритетов отбрасывания.

Чтобы избежать отбрасывания части пакетов, в ATM-LSR следует разрешать механизмы отбрасывания типа EPD (Early Packet Discard) (смотри [ATMF_TM]) для всех PHB, описанных в данном документе.

Использование кодировочных слов в заголовках сообщений

'encoded-word' может появиться в заголовке сообщения или в заголовке тела секции в соответствии со следующими правилами:

(1)

'encoded-word' может заменить текстовую лексему (как это определено в RFC-822) в любом из полей заголовка Subject или Comments, в любом поле расширения заголовка, или любом поле секции тела MIME, для которого поле тела определено как '*text'. 'encoded-word' может также появиться в любом поле сообщения или секции тела, определенном пользователем ("X-"). Обычный ASCII-текст и 'кодировочные слова' могут появляться совместно в пределах одного и того же поля заголовка. Однако 'кодировочное слово', появляющееся в поле заголовка, определенное как '*text', должно быть отделено от любого смежного 'encoded-word' или 'текста' с помощью LWS (HT|SP|CRLF).

(2)

'encoded-word' может появляться внутри 'комментария', ограниченного "(" и ")", т.е., там, где допустим 'ctext'. Более точно, ABNF-определение (RFC-822) для 'comment' следует скорректировать как:

comment = "(" *(ctext | quoted-pair | comment | encoded-word) ")"

"Q"-кодированное 'encoded-word', которое появляется в комментарии не должно содержать символов "(", ")" или ". 'Кодировочное слово', появляющееся в комментарии должно отделяться от смежного 'encoded-word' или 'ctext' с помощью LWS.

Важно заметить, что комментарии распознаются только внутри структурированных полей тела. В полях, чьи тела определены как '*text', "(" и ")" обрабатываются как обычные символы, а не как разделители комментариев, и применимо правило (1) этой секции. (См. RFC-822, секции 3.1.2 и 3.1.3)

(3)

В качестве замены для объекта 'word' во 'фразе', например, перед адресом в заголовке From, To или Cc. ABNF-определение для 'phrase' RFC-822 приобретает вид:
phrase = 1*( encoded-word / word)

В этом случае набор символов, который можно использовать с "Q"-кодированным 'encoded-word' ограничивается до: > ASCII-буква верхнего и нижнего регистров, десятичные цифры, "!", "*", "+", "-", "/", "=" и "_" (ASCII 95.)<. 'Кодировочное слово', которое появляется внутри 'фразы', должно быть отделено от любого смежного 'слова', 'текста' или специального символа ('special') посредством LWS. Это единственные места, где может появиться 'encoded-word'. В частности:

+ 'encoded-word' не должно появляться в любой части 'addr-spec'.
+ 'encoded-word' не должно появляться в пределах 'quoted-string'.
+ 'encoded-word' не должно использоваться в поле заголовка Received.
+ 'encoded-word' не должно использоваться в параметре MIME поля Content-Type или Content-Disposition, или в любом структурированном поле тела, за исключением 'comment' или 'phrase'.

'Кодированный текст' не должен продолжаться от одного 'encoded-word' к другому. Это предполагает, что секция кодированного текста 'B-encoded-word' будет иметь длину кратную 4 символам; для 'Q-encoded-word', за любым символом "=", который появляется в секции кодированного текста, следуют две шестнадцатеричные цифры.

Каждое 'encoded-word' должно кодировать полное число октетов. 'Кодированный текст' в каждом 'encoded-word' должен быть хорошо оформлен согласно специфицированному кодированию. 'Кодированный текст' не может продолжаться в следующем 'encoded-word'. (Например, "=?charset?Q?=?= =?charset?Q?AB?=" было бы нелегальным, так как два шестнадцатеричные числа "AB" должны следовать за "=" в одном и том же 'encoded-word'.)

Каждое 'encoded-word' представлять собой целое число символов. Многооктетные символы не могут расщепляться между смежными 'кодировочными словами'.

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

Использование этих методов для кодирования нетекстовых данных (напр., изображения или голоса) в данном документе не определено. Применение 'кодировочных слов' для представления строк ASCII-символов допустимо, но не рекомендуется.

LDP использует опцию подписи TCP MD5 следующим образом:

Использование подписи MD5 для TCP соединений является конфигурируемой опцией LSR.

LSR, который использует опцию подписи MD5, конфигурируется с привлечением пароля (совместно используемый секретный ключ) для каждого потенциального партнера LDP.

LSR использует алгоритм MD5, как это специфицировано в [RFC2385], чтобы вычислить дайджест MD5 для TCP сегмента, посылаемого партнеру. При этом вычислении используется пароль партнера и сам TCP сегмент.

Когда LSR получает TCP сегмент с дайджестом MD5, он проверяет сегмент, вычисляя дайджест MD5 (используя свою запись пароля) и сравнивает вычисленный дайджест с полученным. Если сравнение неудачно, сегмент отбрасывается, а отклик отправителю не посылается.

LSR игнорирует сообщения LDP Hello от любого LSR, для которого не был сконфигурирован пароль. Это гарантирует, что LSR устанавливает TCP соединение только с LSR, для которого пароль был задан.

Использование маршрутов шаг-за-шагом в качестве LSP

Если путь шаг-за-шагом, которому пакет P должен следовать, характеризуется <R1, ..., Rn >, тогда < R1, ..., Rn> может быть LSP до тех пор пока:

1. Существует один адресный префикс X , такой, что для всех i, 1<=i<n , X является наилучшим соответствием в маршрутной таблице Ri для адреса места назначения P ;

2. Для всех i, 1<i <n, Ri установил соответствие метки и X и разослал эту метку всем R[i-1].

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

Предположим, например, что пакет P, с адресом места назначения 10.2.153.178 должен двигаться от R1 к R2 и далее к R3. Предположим также, что R2 анонсирует адресный префикс 10.2/16 для R1, но R3 анонсирует 10.2.153/23, 10.2.154/23 и 10.2/16 до R2. То есть, R2 анонсирует "агрегатный маршрут" для R1. В этой ситуации, пакет P может быть коммутируемым по метке до тех пор, пока он не достигнет R2, но так как R2 осуществил агрегатирование маршрутов, он должен запустит алгоритм поиска наилучшего соответствия, чтобы найти FEC для P.

Использование параметров трафика Frame Relay и механизмов управления трафиком

Использование параметров трафика Frame Relay, как это специфицировано ITU-T и Frame Relay-Forum или поставщиком специфических механизмов управления трафиком Frame Relay находятся за пределами рассмотрения данным документом. Единственным требованием для совместимости реализаций является то, что механизм переадресации, определяемый BA, вдоль L-LSP Frame Relay LSR должен быть совместимым с соответствующими спецификациями Diff-Serv PHB. Так как имеется только один бит (DE) для кодирования значения PHB приоритета отбрасывания в каналах Frame Relay, такие LSR поддерживают только два уровня приоритета отбрасывания. В разделах 4.2.3 и 4.4.3 определено, как три уровня приоритета отбрасывания AFn OA ставятся в соответствие этим двум уровням в Frame Relay. Это соответствие находится в согласии с требованиями специфицированными в [DIFF_AF] для случая, когда поддерживаются только два уровня приоритета отбрасывания.

Использование широковещательной и уникастной адресации

DHCP-клиент широковещательно посылает сообщения DHCPDISCOVER, DHCPREQUEST и DHCPINFORM, если только клиент не знает адреса DHCP-сервера. Клиент посылает сообщения DHCPRELEASE серверу уникастно. Так как клиент отказывается использовать IP-адрес, предоставленный сервером, он посылает сообщения DHCPDECLINE широковещательно.

Когда DHCP-клиент знает адрес DHCP-сервера, в состоянии INIT или REBOOTING, клиент может использовать адрес, записанный в DHCPDISCOVER или DHCPREQUEST, а не широковещательный IP-адрес. Клиент может также использовать уникастную адресацию при посылке сообщений DHCPINFORM известному DHCP-серверу. Если клиент не получает отклика на DHCP-сообщение, посланное по IP-адресу известного DHCP-сервера, DHCP-клиент переходит на широковещательную адресацию.

Использование сообщения Hello

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

Узел периодически генерирует сообщение Hello, содержащее объект HELLO REQUEST, для каждого соседа, чей статус должен быть отслежен. Периодичность определяется значением hello_interval. Это значение может конфигурироваться для каждого соседа. Значение по умолчанию равно 5 мсек.

При генерации сообщения, содержащего объект HELLO REQUEST, отправитель заносит в поле Src_Instance значение его атрибута для каждого из соседей. Эта величина не должна изменяться в процессе обмена сообщениями Hello с соответствующими соседями. Отправитель заносит также в поле Dst_Instance значение Src_Instance, полученное от соседа последним. Для ссылки, назовем эту переменную Neighbor_Src_Instance. Если от соседа ничего не получено или узел считает связь с соседом потерянной, значение Neighbor_Src_Instance устанавливается равным нулю (0). Генерация сообщения следует подавить, когда объект HELLO REQUEST был получен от узла адресата в пределах интервала hello_interval.

Получив сообщение, содержащее объект HELLO REQUEST, адресат должен сформировать сообщение Hello, содержащее объект HELLO ACK. Получателю также следует проверить, что сосед активен. Это делается путем сравнения значения поля атрибута отправителя Src_Instance со значением, полученным ранее. Если значение Neighbor_Src_Instance равно нулю, а поле Src_Instance не равно нулю, значение Neighbor_Src_Instance обновляется. Если значения отличаются или поле Src_Instance равно нулю, тогда узел должен считать связь с соседом разорванной.

Получатель объекта HELLO REQUEST должен также проверить, что сосед возвращает назад значение атрибута получателя. Это делается путем сравнения полученного значения поля Dst_Instance с Src_Instance, посланным соседу последним. Если сосед продолжает рассылать неверное ненулевое значение после заданного числа временных интервалов, тогда узел считает соседа отключенным.

Получив сообщение, содержащее объект HELLO ACK, адресат должен проверить, что сосед активен. Это делается путем сравнения значения поля отправителя Src_Instance со значением, полученным до этого. Если значение Neighbor_Src_Instance равно нулю, а Src_Instance не равно нулю, величина Neighbor_Src_Instance обновляется. Если значения отличаются или поле Src_Instance не равно нулю, тогда узел должен считать связь с соседом оборванной.

Получатель объекта HELLO ACK должен также проверить, что сосед возвращает назад значение атрибута получателя. Если сосед рассылает неверное значение в поле Dst_Instance, тогда узел должен считать связь с соседом оборванной.

Если не получено от соседа никакого значения атрибута, через посредство объектов REQUEST или ACK, за оговоренное число hello_intervals, тогда узел должен предположить, что он не может связаться с соседом. Значение по умолчанию для этого числа равно 3.5.

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

Извлечение предпоследнего шага

Заметим, что согласно определениям из раздела 2.15, если <R1, ..., Rn> является LSP уровня m для пакета P, P может быть передан от R[n-1] к Rn с глубиной стека меток m-1. То есть, может быть выполнена операция pop для стека меток в предпоследнем LSR LSP, а не в выходном LSP.

С архитектурной точки зрения это вполне приемлемо. Целью метки уровня m является доставка пакета в Rn. Раз R[n-1] решил послать пакет Rn, метка не имеет более значения и не должна далее транспортироваться.

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

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

- это предпоследний шаг, и

- какой узел является следующим.

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

Создание в программе коммутации меток "fastpath" может существенно помочь, если известно, что требуется лишь один просмотр метки:

Явная и неявная рассылки меток

Помимо режимов явной рассылки меток (которые используют сигнальный протокол), [ACHA] предлагается метод неявной рассылки меток, использующий неизвестные метки. Этот метод имеет все преимущества выделения меток “вверх по течению” и является, вероятно, самым быстродействующим способом анонсирования меток для запуска формирования LSP трафиком.

Неявная рассылка меток не применима, если ассоциация FEC-метка была анонсирована до прихода трафика, например, явная маршрутизация (т.е. если в пакете нет всей необходимой информации, чтобы идентифицировать FEC). Явная рассылка меток допускает предварительное установление LSP (до прихода данных) по топологии или по запросу.

Ссылки

[ACHA] A. Acharya, R. Dighe и F. Ansari, "IP Switching Over Fast ATM Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE Globecom '97.

[ADAM] A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast Version 2 Dense Mode Specification", Work In Progress.

[ANDE] Andersson, L., Doolan, P., Feldman, N., Fredette, A. и R. Thomas, "LDP Specification", RFC 3036, January 2001.

[AWDU] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. yes"> и V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

[BALL] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.

[CONT] Conta, D., Doolan, P. и A. Malis, "Use of Label Switching on Frame Relay Networks", RFC 3034, January 2001.

[CRAW] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M. и J. Krawczyk, "A Framework for Integrated Services и RSVP over ATM", RFC 2382, August 1998.

[DAVI] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. и P. Doolan, "MPLS using LDP и ATM VC switching", RFC 3035, January 2001.

[DEER] Deering, S., Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Handley, M., Jacobson, V., Liu, C., Sharma, P. и L Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.

[FARI] D. Farinacci, Y. Rekhter, E. Rosen и T. Qian, "Using PIM to Distribute MPLS Labels for Multicast Routes", Work In Progress.

[FENN] Fenner, W., "Internet Group Management Protocol, IGMP, Version 2", RFC 2236, November 1997.

[GARR] Garrett, M. и M. Borden, "Interoperation of Controlled-Load Service и Guaranteed Service with ATM", RFC 2381, August 1998.

[HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work In Progress.

[MOY] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.

[NAGA] Nagami, K., Demizu, N., Esaki, H., Katsube, Y. и P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001.

[PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, "Simple Multicast", Work In Progress.

[PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work In Progress.

[PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", IEEE/ACM Transactions on Networking 5(5), pp. 601-615.

[ROSE] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. и A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.

Явное управление по меткам

ERO (Explicit Route Object) метки и субобъекты RRO (Record Route Object) определены для поддержки явного управления метками. Заметим, что субобъект RRO метки определен в [RFC3209] и расширен для поддержки двунаправленных LSP.

Экспериментальные расширения LDP

LDP поддержка экспериментирования подобна поддержке частных расширений производителя со следующими отличиями:

диапазон кодов тип 0x3F00 0x3FFF зарезервирован для экспериментальных TLV.

диапазон кодов тип сообщения 0x3F00 - 0x3FFF зарезервирован для экспериментальных сообщений.

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

Экспериментальные TLV и сообщения используют поле экспериментального ID вместо поля ID производителя. Поле ID эксперимента используется с полем тип сообщения, чтобы специфицировать интерпретацию экспериментального TLV или сообщения. Администрирование экспериментальных ID находится в сфере ответственности экспериментаторов.

Экспериментальные значения типа среды

Значение типа среды, начинающееся с символов "X-" представляет собой частное значение, предназначенное для применения системами, которые согласились между собой работать в таком режиме. Любой формат, не являющийся стандартным, должен иметь имя, начинающееся с префикса "X-", а утвержденные стандартные имена никогда не начинаются с "X-".

Вообще, использование "X-" для типов верхнего уровня категорически не рекомендуется. Разработчики должны придумывать субтипы существующих типов. Во многих случаях субтип "application" будет более уместен, чем новый тип верхнего уровня.

Приложение A -- обзор грамматики

Данное приложение содержит все синтаксические конструкции, описанные в разделе MIME. Сама по себе данная грамматика не может считаться полной. Она базируется на нескольких правилах, определенных в документе RFC 822. Если какой-то термин не определен, его значение предполагается заданным в RFC 822. Сами правила RFC 822 здесь не представлены.

boundary := 0*69 bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"
body-part := <"сообщение" как это определено в RFC-822, со всеми опционными полями заголовка, не начинающимися со специфицированных дефис-границ, и без разделителей в пределах тела сообщения. Заметим, что семантика секции отличается от семантики сообщения, как это описано в тексте.>

close-delimiter := delimiter "--"
dash-boundary := "--" boundary

boundary берется из значения пограничного параметра из поля Content-Type.

delimiter := CRLF dash-boundary
discard-text := *(*text CRLF); Может игнорироваться или отбрасываться.
encapsulation := delimiter transport-padding CRLF body-part
epilogue := discard-text
multipart-body := [preamble CRLF]

	Dash-boundary transport-padding CRLF
	body-part *encapsulation
	close-delimiter transport-padding
	[CRLF epilogue]

preamble := discard-text
transport-padding := *LWSP-char
; Отправители не должны генерировать транспортных заполнителей не нулевой
; длины, но получатели должны уметь обрабатывать заполнители, добавленные в
; сообщение при транспортировке.

III. Расширения для заголовков сообщений с не-ASCII текстом

В этом разделе описывается техника кодирования не-ASCII-текста в различных частях заголовка сообщения RFC-822 [2].

Подобно тому, как это рассказано в первом разделе описания MIME, методика сконструирована так, чтобы допустить использование не-ASCII символов в заголовках сообщения так, чтобы даже специфические) удаляют некоторые поля заголовков, сохраняя другие, (b) меняет содержимое адресов в полях To или Cc, (c) меняют вертикальный порядок размещения полей заголовка. Кроме того, некоторые почтовые программы не всегда способны корректно интерпретировать заголовки сообщений, в которых встречаются некоторые редко используемые рекомендации документа RFC 822, например, символы обратной косой черты для выделения специальных символов типа "<", "," или ":".

Расширения, описанные здесь, не базируются на редко используемых возможностях RFC-822. Вместо этого, определенные последовательности "обычных" печатных ASCII символов (известных как "encoded-words" - кодировочные слова) зарезервированы для использования в качестве кодированных данных. Синтаксис кодированных слов таков, что они вряд ли могут появиться в нормальном тексте заголовков сообщений. Более того, символы, используемые в кодировочных словах, не могут иметь специального назначения в контексте, где появляются эти слова.

Вообще, "encoded-word>" представляет собой последовательность печатных ASCII-символов, которая начинается с "=?", завершается "?=" и имеет два "?" между ними. Оно специфицирует символьный набор и метод кодирования, а также включает в себя оригинальный текст в виде графических ASCII-символов, созданный согласно правилам данного метода кодирования.

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

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

Данный документ в заметной мере базируется на нотации и терминах RFC-822 и RFC-2045. В частности, синтаксис для ABNF, используемый здесь, определен в RFC-822. Среди терминов, определенных в RFC-822 и использованных в данном документе: 'addr-spec' (спецификация адреса), 'атом', 'CHAR', 'комментарий', 'CTL', 'ctext', 'linear-white-space' (HT| SP|CRLF), 'фраза', 'quoted-pair', 'закавыченная строка', 'пробел' и 'слово'. Успешная реализация расширения этого протокола требует тщательного внимания к определениям этих терминов в RFC-822.

Когда в данном документе встречается термин "ASCII", он относится к "7-битовому стандарту, ANSI X3.4-1986. Имя этого символьного набора в MIME "US-ASCII".

Качество обслуживания QoS

QoS связана с возможностью сети предоставить клиенту необходимый ему уровень услуг в условиях работы поверх сетей с самыми разнообразными технологиями, включая Frame Relay, ATM, Ethernet, сети 802.1, SONET, и маршрутизуемые IP-сети.

QoS представляет собой собрание технологий, которые позволяют приложениям запрашивать и получать предсказуемый уровень услуг с точки зрения пропускной способности, временного разброса задержки откликa, а также общей задержки доставки данных. В частности, QoS подразумевает улучшение параметров или достижение большей предсказуемости предоставляемых услуг. Это достигается следующими методами: Поддержкой определенной полосы пропускания. Сокращением вероятности потери кадров. Исключением или управляемостью сетевых перегрузок. Возможностью конфигурирования сетевого трафика. Установкой количественных характеристик трафика по пути через сеть.

IEFT определяет для QoS следующие две архитектуры: Интегрированные услуги (IntServ)Дифференцированные услуги (DiffServ)

IntServ для явного задания уровня услуги (QoS) использует протокол RSVP. Это делается путем уведомления об этом требовании всех узлов вдоль пути обмена. Если все сетевые устройства вдоль пути могут предоставить запрошенную полосу, резервирование завершается успешно (смотри документ RFC-1633 [2]).

DiffServ, вместо того чтобы уведомлять о требованиях приложения, использует в IP-заголовке DiffServ Code Point (DSCP), чтобы указать требуемые уровни QoS. Cisco IOS® Software Release 12.1(5)T вводит совместимость маршрутизаторов Cisco c DiffServ (см. [15-16]). DSCP размещается в поле TOS IP-пакета. В таблице 3 представлены различные виды использования QoS.

Таблица 3.

Протокольная группаПротоколСсылка

VIP-Distributed WFQ

http://www.cisco.com/en/US/tech/tk543/tk544/tk96/tech_protocol_home.html

http://www.cisco.com/en/US/tech/tk543/tk760/tk185/tech_protocol_home.html
Frame Relay DE bit

ATM CLP bit

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

L2 QoS предполагает следующее:

1. Управление входными очередями: когда кадр приходит на вход порта, он может быть отнесен к одной из нескольких очередей, ассоциированных с портом, прежде чем он будет направлен на один из выходных портов. Обычно, несколько очередей используются тогда, когда различные информационные потоки требуют различных уровней услуг или минимизации задержки. Например, IP мультимедиа требует минимизации задержки, в отличие от передачи данных в FTP, WWW, email, Telnet, и т.д.

2. Классификация: процесс классификации включает просмотр различных полей в заголовке Ethernet L2, а также полей IP-заголовка (уровень 3 - L3) и заголовков TCP/UDP (уровень 4 - L4), чтобы обеспечить определенный уровень услуг при коммутации пакетов.

3. Политика: осуществление политики является процессом анализа кадра Ethernet, чтобы определить, не будет ли превышен заданный уровень трафика за определенный интервал времени (обычно, это время является внутренним параметром переключателя). Если кадр создает ситуацию, при которой трафик превысит заданный уровень, он будет отброшен. Или значение CoS (Class of Service) может быть понижено.

4. Перепись: процесс переписи предоставляет возможность переключателю модифицировать CoS в заголовке или ToS (Type of Service) в IPv4-заголовке. Следует учесть, что заголовок Ethernet 802.3 поля CoS не имеет (именно эта версия стандарта наиболее распространена в РФ).

5. Управление выходными очередями: после процесса перезаписи переключатель поместит кадр Ethernet, в выходную очередь для последующей коммутации. Переключатель выполнит управление буфером так, чтобы не произошло переполнение. Это обычно осуществляется с помощью алгоритма RED (Random Early Discard), когда некоторые кадры случайным образом удаляются из очереди. Weighted RE (WRED) является директивой RED (используемой некоторыми модулями семейства Catalyst 6000), где значения CoS анализируются с целью определения того, какие кадры следует отбросить. Когда буферы окажутся заполнены до определенного уровня, кадры с низким уровнем приоритета отбрасываются, в очереди сохраняются только высокоприоритетные кадры.

Каноническая модель кодирования

Процесс формирования объекта MIME можно смоделировать в виде цепочки последовательных шагов. Заметим, что эти шаги сходны с используемыми в PEM [RFC-1421] и реализуются для каждого "внутреннего" уровня тела сообщения.

(1)	Создание локальной формы.

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

(2)	Преобразование в каноническую форму.

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

Например, в случае чистого текста, данные должны преобразовываться с использованием поддерживаемого символьного набора, а строки должны завершаться CRLF, как этого требует RFC-822. Заметьте, что ограничения на длины строк, налагаемые RFC-822, игнорируются, если на следующем шаге выполняется кодирование с использованием base64 или закавыченных строк печатных символов.

(3)	Применение транспортного кодирования.

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

(4)	Вставление в объект.

Закодированное тело вкладывается в объект MIME, снабженный соответствующими заголовками. Объект затем вкладывается в объект более высокого уровня, если это требуется.

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

(1)

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

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

Content-type: text/foo; charset=bar
Content-Transfer-Encoding: base64

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

Некоторые проблемы вызывают почтовые системы, которые для обозначения перехода на новую строку используют нечто отличное от CRLF, принятого в стандарте RFC-822. Важно отметить, что эти форматы не являются каноническими RFC-822/MIME. Заметим также, что форматы, где вместо последовательности CRLF заносится, например, LF не способны представлять сообщения MIME, содержащие двоичные данные с октетами LF, которые не являются частью последовательности CRLF.

Приложение A. Сложный пример составного сообщения

Данное сообщение содержит пять частей, которые должны быть отображены последовательно: - два вводных объекта чистого текста, встроенное составное сообщение, объект типа text/enriched и завершающее инкапсулированное текстовое сообщение с символьным набором не ASCII типа. Встроенное составное сообщение в свою очередь содержит два объекта, которые должны отображаться в параллель, изображение и звуковой фрагмент.

MIME-Version: 1.0
From: Nathaniel Borenstein
To: Ned Freed
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example(составной пример)
Content-Type: multipart/mixed;boundary=unique-boundary-1

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

--unique-boundary-1
... Здесь размещается некоторый текст ...

[Заметим, что пробел между границей и началом текста в этой части означает, что не было никаких заголовков и данный текст представлен в символьном наборе US-ASCII.]

--unique-boundary-1
Content-type: text/plain; charset=US-ASCII

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

--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2

--unique-boundary-2
Content-Type: audio/basic

Content-Transfer-Encoding: base64
... здесь размещаются одноканальные аудио данные, полученные при частоте стробирования 8 кГц, представленные с использованием m-преобразования, и закодированные с привлечением base64 ...

--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
... здесь размещается изображение, закодированное с привлечением base64 ...
--unique-boundary-2--
--unique-boundary-1
Content-type: text/enriched

This is enriched.
как определено в RFC-1896
Isn't it
cool?
-unique-boundary-1
Content-Type: message/RFC-822
From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
Additional text in ISO-8859-1 goes here ...
--unique-boundary-1--

Ссылки

[ATK]

Borenstein, Nathaniel S., Multimedia Applications Development with the Andrew Toolkit, PrenticeHall, 1990. [ISO-2022]International Standard -- Information Processing -- Character Code Structure and Extension Techniques, ISO/IEC 2022:1994, 4th ed. [ISO-8859]International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets
- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed.
- Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed.
- Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed.
- Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed.
- Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st ed.
- Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed.
- Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.
- Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed.
- Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st ed. International Standard -- Information Technology -- 8-bit Single-Byte Coded Graphic Character Sets
>- Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992, 1st ed. [ISO-646]International Standard -- Information Technology - ISO 7-bit Coded Character Set for Information Interchange, ISO 646:1991, 3rd ed.. [JPEG]JPEG Draft Standard ISO 10918-1 CD. [MPEG]Video Coding Draft Standard ISO 11172 CD, ISO IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May, 1991. [PCM]CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code Modulation (PCM) of Voice Frequencies", Geneva, 1972. [POSTSCRIPT]Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, 1985. [POSTSCRIPT2]Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, Second Ed., 1990. [RFC-783]Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, MIT, June 1981. [RFC-821]Postel, J.B., "Simple Mail Transfer Protocol", STD-10, RFC-821, USC/Information Sciences Institute, August 1982. [RFC-822]Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC-822, UDEL, August 1982. [RFC-934]Rose, M. and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC-934, Delaware and NMA, January 1985. [RFC-959]Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC-959, USC/Information Sciences Institute, October 1985. [RFC-1049]Sirbu, M., "Content-Type Header Field for Internet Messages", RFC-1049, CMU, March 1988. [RFC-1154]Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC-1154, Prime Computer, Inc., April 1990. [RFC-1341]Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC-1341, Bellcore, Innosoft, June 1992. [RFC-1342]Moore, K., "Representation of Non-Ascii Text in Internet Message Headers", RFC-1342, University of Tennessee, June 1992. [RFC-1344]Borenstein, N., "Implications of MIME for Internet Mail Gateways", RFC-1344, Bellcore, June 1992. [RFC-1345]Simonsen, K., "Character Mnemonics & Character Sets", RFC-1345, Rationel Almen Planlaegning, June 1992. [RFC-1421]Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encryption and Authentication Procedures", RFC-1421, IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1422]Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management", RFC-1422, IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1423]Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1424]Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV -- Key Certification and Related Services", IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1521]Borenstein, N., and Freed, N., "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC-1521, Bellcore, Innosoft, September, 1993. [RFC-1522]Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC-1522, University of Tennessee, September 1993. [RFC-1524]Borenstein, N., "A User Agent Configuration Mechanism for Multimedia Mail Format Information", RFC-1524, Bellcore, September 1993. [RFC-1543]Postel, J., "Instructions to RFC Authors", RFC-1543, USC/Information Sciences Institute, October 1993. [RFC-1556]Nussbacher, H., "Handling of Bi-directional Texts in MIME", RFC-1556, Israeli Inter-University Computer Center, December 1993. [RFC-1590]Postel, J., "Media Type Registration Procedure", RFC-1590, USC/Information Sciences Institute, March 1994. [RFC-1602]Internet Architecture Board, Internet Engineering Steering Group, Huitema, C., Gross, P., "The Internet Standards Process -- Revision 2", March 1994. [RFC-1652]Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., Stefferud, E., and Crocker, D., "SMTP Service Extension for 8bit-MIME transport", RFC-1652, United Nations University, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, March 1994. [RFC-1700]Reynolds, J. and J. Postel, "Assigned Numbers", STD-2, RFC-1700, USC/Information Sciences Institute, October 1994. [RFC-1741]Faltstrom, P., Crocker, D., and Fair, E., "MIME Content Type for BinHex Encoded Files", December 1994. [RFC-1896]Resnick, P., and A. Walker, "The text/enriched MIME Content-type", RFC-1896, February, 1996. [RFC-2045]Freed, N., and and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, Innosoft, First Virtual Holdings, November 1996. [RFC-2046]Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC-2046, Innosoft, First Virtual Holdings, November 1996. [RFC-2047]Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-ASCII Text in Internet Message Headers", RFC-2047, University of Tennessee, November 1996. [RFC-2048]Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC-2048, Innosoft, MCI, ISI, November 1996. [RFC-2049]Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC-2049 (this document), Innosoft, First Virtual Holdings, November 1996. [US-ASCII]Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. [X400]Schicker, Pietro, "Message Handling Systems, X.400", Message Handling Systems and Distributed Applications, E. Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41.

Keep-Alive (KA) PEP -> PDP, PDP -> PEP

Сообщение keep-alive должно передаваться PEP в пределах периода, определенного минимальным значением выдержки KA-таймера, которая определяется в сообщениях CAT для данного соединения. Сообщение KA должно генерироваться случайным образом в пределах между 1/4 и 3/4 этого минимального интервала KA-таймера. Когда PDP получает сообщение keep-alive от PEP, он должен откликнуться таким же сообщением, адресованным PEP. Это сообщение обеспечивает подтверждение для каждой из сторон того, что соединение функционирует даже в случае, когда нет никаких других сообщений.

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

<Keep-Alive> ::= <Common Header>
[<Integrity>]

Как клиент, так и сервер могут предполагать, что TCP-соединение недостаточно для типа клиента с минимальным значением времени (специфицировано в сообщении CAT), если не зарегистрировано никакой телекоммуникационной активности в течение периода времени, превосходящего выдержку таймера. При этом PEP предполагает, что удаленный PDP или соединение не работает и PEP должен пытаться использовать альтернативный/запасной PDP.

Класс Advanced route 8.Спецификация агрегатных маршрутов

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

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

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

route: 128.8.0.0/15
origin: AS1
components: <^AS2>
route: 128.8.0.0/15
origin: AS1

components:	protocol BGP4 {128.8.0.0/16^+}
	protocol OSPF {128.9.0.0/16^+}

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

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

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

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

aggr-mtd:	inbound
	\| outbound [<as-expression>]

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

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

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

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

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

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

route:	128.8.0.0/15
origin:	AS1
components:	{128.8.0.0/15^-}
aggr-mtd:	outbound AS-ANY
export-comps:	{128.8.8.0/24}

Рис. .31. Экспортное объединение с исключениями.

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

inject:	[at <router-expression>] ...
	[action <action>]
	[upon <condition>]

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

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

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

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

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

route:	128.8.0.0/15
origin:	AS1
components:	{128.8.0.0/15^-}
aggr-mtd:	outbound AS-ANY
inject:	at 1.1.1.1 action dpa = 100;
inject:	at 1.1.1.2 action dpa = 110;
route:	128.8.0.0/15
origin:	AS1
components:	{128.8.0.0/15^-}
aggr-mtd:	outbound AS-ANY
inject:	upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16}
holes:	128.8.8.0/24

Рис. .32. Примеры инжекции.

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

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