Энциклопедия сетевых протоколов | от Николая Малых

RFC 2822 Internet Message Format

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

Заменен RFC 5322

Рубрика: RFC | Оставить комментарий

RFC 3081 Mapping the BEEP Core onto TCP

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

Network Working Group                                            M. Rose
Request for Comments: 3081                        Invisible Worlds, Inc.
Category: Standards Track                                     March 2001

Отображение ядра BEEP на TCP

Mapping the BEEP Core onto TCP

PDF

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

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

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

Аннотация

В этом документе описано, как сессия BEEP¹ отображается в одно соединение TCP (Transmission Control Protocol).

1. Введение

Этот документ описывает, как сессия BEEP [1] отображается в одно соединение TCP [2]. Требования к отображениям заданы в параграфе 2.5 документа [1].

2. Управление сессиями

Отображение поддержки сессий BEEP на услуги TCP достаточно прямолинейно.

Сессия BEEP организуется, когда создано соединение TCP между двумя партнерами BEEP:

узел BEEP, задавший пассивный вызов TCP OPEN, называется «слушателем»;
узел BEEP, задавший активный вызов TCP OPEN, называется «инициатором».

Одновременный вызов TCP OPEN² приведет к тому, что оба партнера BEEP будут считать себя инициаторами и не смогут организовать ни одного канала. Поэтому основанные на протоколе BEEP службы должны быть устроены так, что одновременных вызовов TCP OPEN не возникает.

Если оба партнера согласны освободить (завершить) сеанс BEEP (см. параграф 2.4 в [1]), узел передавший отклик ok, незамедлительно вызывает TCP CLOSE. При получении отклика другой партнер также незамедлительно вызывает TCP CLOSE.

Сессия BEEP прерывается при вызове любым из партнеров TCP ABORT и последующем разрыве соединения TCP.

3. Обмен сообщениями

Отображение обменов BEEP на услуги TCP менее прямолинейно.

Гарантированная отправка и получение обеспечиваются вызовами SEND и RECEIVE протокола TCP, это обеспечивает также упорядоченную доставку сообщений в одном канале.

TCP обеспечивает управление потоком данных в соединении, но при использовании в одной сессии BEEP множества каналов протокол BEEP должен обеспечить механизм для предотвращения «заторов» в соединении. Для этого BEEP использует механизм, принятый в TCP, — управление потоком данных на основе окон, когда каждый канал использует скользящее окно, показывающее число октетов данных, которые можно передать до следующего разрешения.

3.1 Управление потоком данных

Напомним из параграфа 2.2.1.2 документа [1], что каждый октет данных, переданный в каждом направлении канала имеет порядковый номер. Нумерация октетов данных в кадрах выполняется последовательно от начала поля данных (payload).

Пространство порядковых номеров конечно, хотя и весьма велико, — от 0 до 4294967295 (2³² — 1). Конечность пространства номеров приводит к использованию арифметики с модулем 2³² и при достижении максимального значения 2³² — 1 отсчет номеров продолжается с 0. Арифметика порядковых номеров описана в разделах 2 — 5 документа [3].

3.1.1 Создание канала

При создании канала первый октет данных в первом кадре получает номер 0, а начальный размер окна устанавливается равным 4096 октетам. После создания канала узлы BEEP могут менять размер окна путем передачи кадров SEQ (3.1.3 Обработка кадров SEQ).

Если узел BEEP запросили создать канала, но он не может выделить для этого канала хотя бы 4096 октетов, узел должен отвергнуть создание канала, как указано в параграфе 2.3.1.2 документа [1]. Аналогично, если в процессе организации сессии BEEP «слушатель» BEEP не может выделить хотя бы 4096 октетов для канала 0, он должен возвратить негативный отклик, как указано в параграфе 2.4 документа [1], вместо передачи сообщения greeting.

3.1.2 Передача сообщений

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

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

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

3.1.3 Обработка кадров SEQ

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

ABNF [4] для кадров SEQ имеет вид:

      seq        = "SEQ" SP channel SP ackno SP window CR LF
      ackno      = seqno
      window     = size
      ; channel, seqno и size определены в параграфе 2.2.1 документа [1].

Кадр SEQ имеет три параметра:

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

Для разделения компонент служит одиночный символ пробела (десятичный код 32). Кадр SEQ завершается парой символов CRLF.

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

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

Ключом к успеху управления потоком данных в BEEP является баланс между производительностью и беспристрастностью:

большие сообщения следует сегментировать в кадры, не превышающие 2/3 от согласованного максимального размера сегмента TCP;
кадры разных каналов, готовые к передаче, следует выбирать «по кругу»;
каждый раз при получении кадра следует отправлять кадр SEQ, если размер окна составляет не менее половины доступного для канала буферного пространства;
если транспортный протокол представляет узлу BEEP множество кадров одновременно, можно передать один общий кадра SEQ.

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

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

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

Реализациям следует также соблюдать рекомендации соответствующих разделов RFC1122 [5], относящиеся к управлению потоками данных (и принимать во внимание, что повтор передачи не применим для этого документа, хотя он и взаимодействует с управлением потоками данных TCP). Например, в параграфе 4.2.2.16 документа RFC1122 [5] сказано: «Получателям TCP не рекомендуется отсекать часть окна (т. е., перемещать правый край окна влево),» — а затем рассматривается влияние этого правила на неподтвержденные данные. В контексте отображения BEEP на одно соединение TCP следует реализовать лишь относящиеся к управлению потоком данных части.

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

Вопросы безопасности рассмотрены в разделе 9 документа [1].

Литература

[1] Rose, M., «The Blocks Extensible Exchange Protocol Core», RFC 3080, March 2001.

[2] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[3] Elz, R. and R. Bush, «Serial Number Arithmetic», RFC 1982, August 1996.

[4] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.

[5] Braden, R., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

Адрес автора

Marshall T. Rose

Invisible Worlds, Inc.

1179 North McDowell Boulevard

Petaluma, CA 94954-6559

Phone: +1 707 789 3700

EMail: mrose@invisible.net

URI: http://invisible.net/

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

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

nmalykh@gmail.com

Приложение A. Благодарности

Автор благодарен участникам работы Dave Crocker, Steve Harris, Eliot Lear, Keith McCloghrie, Craig Partridge, Vernon Schryver и Joe Touch. В частности, Dave Crocker внес полезные предложения о природе управления потоком данных для отображения.

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

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

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

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

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

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

1Blocks Extensible Exchange Protocol — расширяемый протокол обмена блоками.

2С учетом предыдущего абзаца корректней было бы написать «Одновременный активный вызов TCP OPEN …». Прим. перев.

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

RFC 3080 The Blocks Extensible Exchange Protocol Core

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

Network Working Group                                            M. Rose
Request For Comments: 3080                        Invisible Worlds, Inc.
Category: Standards Track                                     March 2001

Ядро расширяемого протокола обмена блоками (BEEP)

The Blocks Extensible Exchange Protocol Core

PDF

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

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

Аннотация

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

1. Введение

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

Ядро BEEP включает механизм кадрирования, обеспечивающий одновременный и независимый обмен сообщениями между узлами-партнерами. Сообщения включают произвольное содержимое MIME [1], но обычно являются текстовыми (структурированными на основе XML [2]).

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

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

профиль транспортной защиты TLS [3];
семейство профилей SASL [4].

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

2. Ядро BEEP

Сессия BEEP отображается на базовый (нижележащий) транспортный сервис. Отдельный набор документов описывает реализацию сеансов BEEP на основе конкретных транспортных протоколов. Например, в документе [5] описано отображение сессии BEEP в одно соединение TCP [6].

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

Использование канала делится на два этапа (категории).

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

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

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

2.1. Роли

Хотя протокол BEEP относится к числу одноранговых (peer-to-peer), удобно помечать каждого узла в контексте выполняемой этим узлом в данный момент роли.

При организации сессии BEEP узел, ожидающий новых соединений играет роль «слушателя», а другой узел, который организует соединение со слушателем, — роль «инициатора». Ниже в примерах они обозначены L: и I:, соответственно.
Узел BEEP, начинающий обмен, считается клиентом, другой узел — сервером. В последующих примерах они обозначаются C: и S:, соответственно.

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

2.1.1. Стили обмена

BEEP поддерживает три стиля обмена.

MSG/RPY — клиент передает сообщение MSG с запросом к серверу выполнить некую задачу. Сервер выполняет запрос и передает сообщение RPY (позитивный отклик).

MSG/ERR — клиент передает сообщение MSG с запросом к серверу выполнить некую задачу. Сервер не выполняет задачу и передает сообщение ERR (негативный отклик).

MSG/ANS — клиент передает серверу сообщение MSG, сервер в процессе выполнения задачи может (но не обязан) ответить сообщением ANS (возможно, несколькими), а по завершении отвечает сообщением NUL, которое говорит о выполнении запроса.

Первые два варианта называются обменами «один к одному», третий — «один ко многим».

2.2. Сообщения и кадры

Сообщения структурируются в соответствии с правилами MIME и каждое сообщение может начинаться с entity-headers (см. раздел 3 в [1]). Если entity-headers отсутствует или имеется только часть, по умолчанию используются:

Content-Type — application/octet-stream;
Content-Transfer-Encoding — binary.

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

Каждый кадр состоит из заголовка, данных (payload) и трейлера. Заголовок и трейлер представляются печатными строками ASCII и завершаются парой символов CRLF. Между заголовком и трейлером помещается (возможно пустая) последовательность октетов данных.

Например, приведенное ниже сообщение содержится в одном кадре, где 120 октетов данных занимают 5 строк (каждая строка завершается парой символов CRLF).

       C: MSG 0 1 . 52 120
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/SASL/OTP' />
       C: </start>
       C: END

Еще раз отметим, что в этом примере сообщение представлено в одном кадре.

2.2.1. Синтаксис кадра

ABNF [7] для кадра имеет вид:

   frame      = data / mapping

   data       = header payload trailer

   header     = msg / rpy / err / ans / nul

   msg        = "MSG" SP common          CR LF
   rpy        = "RPY" SP common          CR LF
   ans        = "ANS" SP common SP ansno CR LF
   err        = "ERR" SP common          CR LF
   nul        = "NUL" SP common          CR LF

   common     = channel SP msgno SP more SP seqno SP size
   channel    = 0..2147483647
   msgno      = 0..2147483647
   more       = "." / "*"
   seqno      = 0..4294967295
   size       = 0..2147483647
   ansno      = 0..2147483647

   payload    = *OCTET

   trailer    = "END" CR LF

   mapping    = ;; каждое транспортное отображение может определять свои кадры

2.2.1.1. Заголовок кадра

Заголовок кадра состоит из трехсимвольной последовательности (MSG, RPY, ERR, ANS или NUL), за которой могут следовать параметры. В качестве разделителей используются одиночные символы пробела (десятичный код 32, » «). Завершается заголовок парой символов CRLF.

Номер канала (channel) должен быть целым числом из диапазона 0 — 2147483647.

Номер сообщения (msgno) должен быть целым числом из диапазона 0 — 2147483647 и должен отличаться от номеров всех других сообщений MSG в том же канале, для которых отклик еще не получен полностью.

Индикатором продолжения (more) может содержать символ звездочки (десятичный код 42) или точки (десятичный код 46) и показывает является ли этот кадр последним для сообщения:

* — за этим кадром следует по крайней мере еще один кадр данного сообщения;

. — последний кадр сообщения.

Порядковый номер (seqno) должен быть целым числом из диапазона 0 — 4294967295 и указывает порядковый номер первого октета данных (payload) для соответствующего канала (2.2.1.2. Данные кадра).

Размер данных (size) должен указываться целым числом из диапазона 0 — 2147483647 и показывает точное число октетов данных (без учета заголовка и трейлера).

Отметим, что кадр может не включать данных, как показано ниже.

       S: RPY 0 1 * 287 20
       S:     ...
       S:     ...
       S: END
       S: RPY 0 1 . 307 0
       S: END

Номер ответа (ansno) должен быть целым числом из диапазона 0 — 2147483647² и должен отличаться от номеров других ответов на обрабатываемое сообщение.

Имеется два типа кадров — данные (data) и отображения (mapping). Каждое транспортное отображение (2.5. Транспортные отображения) может определять свои кадры. Например, в документе [5] определен кадр SEQ. В оставшейся части этого параграфа рассматриваются кадры данных.

Когда сообщение сегментируется и передается в нескольких кадрах, эти кадры должны передаваться последовательно без промежуточных кадров с другими сообщениями в том же канале. Однако есть два исключения — во-первых, не накладывается ограничений на чередование с кадрами для других каналов, во-вторых, при обмене one-to-many одновременно может обрабатываться множество запросов. Следовательно, кадры для сообщений ANS могут чередоваться в одном канале, а для их сортировки используются номера ответов, как показано ниже.

       S: ANS 1 0 * 0 20 0
       S:     ...
       S:     ...
       S: END
       S: ANS 1 0 * 20 20 1
       S:     ...
       S:     ...
       S: END
       S: ANS 1 0 . 40 10 0
       S:     ...
       S: END

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

Существует несколько признаков некорректных кадров:

заголовок не начинается с MSG, RPY, ERR, ANS или NUL;
параметры в заголовке не могут быть определены или являются непригодными (например, синтаксически некорректны);
значение номера канала не указывает существующий канал;
заголовок начинается с MSG, а номер сообщения указывает на сообщение MSG, которое было принято полностью, но отклик не был полностью передан;
заголовок не начинается с MSG и указан номер сообщения, для которого отклик уже получен полностью;
заголовок не начинается с MSG и указан номер сообщения, которое никогда не передавалось (за исключением организации сеанса, 2.3.1.1. Сообщение Greeting);
заголовок начинается с MSG, RPY, ERR или ANS и указан номер сообщения, для которого был получен по меньшей мере один кадр, а трехсимвольные последовательности в начале кадра и полученного непосредственно перед этим сообщением кадра не совпадают;
заголовок начинается с NUL и указан номер сообщения для которого был получен по меньшей мере еще один кадр, а в заголовке непосредственно предшествующего тип кадра указано значение, отличное от ANS;
индикатор продолжения в предыдущем кадре этого канала имеет значение * (есть еще кадры), а номер сообщения в нем отличается от номера в текущем кадре;
значение порядкового номера не соответствует ожидаемому для связанного канала (2.2.1.2. Данные кадра);
заголовок начинается с NUL, а индикатор продолжения имеет значение * (есть еще кадры) или размер данных отличается от 0.

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

2.2.1.2. Данные кадра

Данные (payload) кадра представляют собой последовательность октетов (возможно, пустую).

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

Доступное пространство порядковых номеров конечно и представляет собой диапазон значений от 0 до 4294967295 (2³² — 1). По причине конечных размеров пространства работа с порядковыми номерами выполняется на основе модуля 2³² и при достижении максимального номера отсчет продолжается с 0. Арифметика порядковых номеров рассмотрена в разделах 2 — 5 работы [8].

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

2.2.1.3. Трейлер кадра

Трейлером кадра служит строка END, за которой следует пара символов CRLF.

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

2.2.2. Семантика кадров

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

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

Организация этих данных описана в шаблоне регистрации профиля (5. Регистрационные шаблоны).

2.2.2.1. Некорректно сформированные сообщения

При определении поведения профиля шаблон должен задавать отклики на сообщения MSG некорректной формы. Например, профиль управления каналом передает негативный отклик, включающий сообщение об ошибке (2.3.1.5. Сообщение Error ).

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

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

2.3. Управление каналом

В момент организации сессии BEEP определен лишь канал 0, используемый для управления. В параграфе 6.1. Управление каналом BEEP приведена регистрация профиля для управления каналами BEEP.

Управление каналом позволяет каждому узлу BEEP анонсировать поддерживаемые им профили (2.3.1.1. Сообщение Greeting), привязать один из экземпляров этих профилей к каналу (2.3.1.2. Сообщение Start), а впоследствии закрыть все каналы и сессию BEEP (2.3.1.3. Сообщение Close).

Узлам BEEP следует поддерживать не менее 257 одновременных каналов.

2.3.1. Семантика сообщений

2.3.1.1. Сообщение Greeting

При организации сессии BEEP каждый из узлов указывает свои возможности, незамедлительно передавая позитивный отклик с номером сообщения 0, содержащий элемент greeting.

       L: <ожидание входящего соединения>
       I: <организация соединения>
       L: RPY 0 0 . 0 110
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/TLS' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END

Из этого примера можно предположить, что узел BEEP в роли инициатора ждет от «слушателя» BEEP его «поздравления» (greeting), однако это лишь «артефакт» представления и на практике оба партнера могут передавать свои отклики одновременно.

Элемент greeting имеет два необязательных атрибута (features и localize) и может (не обязательно) включать элементы profile — по одному для каждого поддерживаемого партнером-сервером профиля.

При наличии атрибута features он содержит один или множество маркеров функций (feature token), каждый из которых указывает дополнительную возможность профиля управления каналом, поддерживаемого узлом BEEP.
При наличии атрибута localize он включает один или множество маркеров языка (language token), определенных в работе [9], каждый из которых указывает желаемый язык, который удаленный партнер будет использовать при генерации текстовых сообщений для элементов close и error (маркеры упорядочиваются по снижению уровня предпочтения).
Каждый элемент profile внутри элемента greeting указывает профиль и, в отличие от элементов profile внутри элемента start, может не включать инициализационного сообщения.

Регистрационные шаблоны для необязательных функций определены в параграфе 5.2. Шаблон регистрации функции

2.3.1.2. Сообщение Start

Когда узел BEEP желает организовать канал, он передает элемент start через канал 0.

       C: MSG 0 1 . 52 120
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/SASL/OTP' />
       C: </start>
       C: END

Элемент start имеет атрибут number, необязательный атрибут serverName и один или множество элементов profile.

Атрибут number указывает номер канала (от 1 до 2147483647), используемый для идентификации канала в будущих сообщениях.
Атрибут serverName (произвольная строка) указывает желаемое имя сервера для этой сессии BEEP.
Каждый элемент profile, содержащийся в элементе start, имеет атрибут uri, необязательный атрибут encoding и произвольные символы в качестве содержимого:

атрибут uri достоверно указывает профиль;
при наличии атрибута encoding он показывает, представлено ли содержимое элемента profile в форме строки base64;
при наличии содержимого элемента profile оно должно быть не больше 4K октетов и задает инициализационное сообщение при создании канала.

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

Атрибут serverName для первого элемента start, успешно принятого узлом BEEP, сохраняет значимость на протяжении всей сессии BEEP. Узел BEEP решает, будет ли он работать в качестве указанного serverName и при отказе передает элемент error в негативном отклике.

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

При создании канала значение serverName из первого «успешного» элемента start просматривается на предмет наличия конфигурационных данных, например желаемого сертификата сервера при старте транспортного профиля TLS (3.1. Профиль транспортной защиты TLS).

Пример успешного создания канала показан ниже.

       C: MSG 0 1 . 52 178
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/SASL/OTP' />
       C:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       C: </start>
       C: END
       S: RPY 0 1 . 221 87
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/SASL/OTP' />
       S: END

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

       C: MSG 0 1 . 52 120
       C: Content-Type: application/beep+xml
       C:
       C: <start number='2'>
       C:    <profile uri='http://iana.org/beep/SASL/OTP' />
       C: </start>
       C: END
       S: ERR 0 1 . 221 127
       S: Content-Type: application/beep+xml
       S:
       S: <error code='501'>number attribute
       S: in &lt;start&gt; element must be odd-valued</error>
       S: END

В заключение приведем пример с обменом инициализационными сообщениями в процессе создания канала.

       C: MSG 0 1 . 52 158
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/TLS'>
       C:        <![CDATA[<ready />]]>
       C:    </profile>
       C: </start>
       C: END
       S: RPY 0 1 . 110 121
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/TLS'>
       S:     <![CDATA[<proceed />]]>
       S: </profile>
       S: END

2.3.1.3. Сообщение Close

Узел BEEP, желающий закрыть канал, передает элемент close через канал 0.

       C: MSG 0 2 . 235 71
       C: Content-Type: application/beep+xml
       C:
       C: <close number='1' code='200' />
       C: END

Элемент close имеет атрибуты number и code, необязательный атрибут xml:lang и необязательный текст для диагностики в качестве своего содержимого.

Атрибут number указывает номер закрываемого канала.
Атрибут code содержит трехзначный числовой код отклика, имеющий смысл для программ (8. Коды откликов).
Атрибут xml:lang указывает язык содержимого элемента (значение предлагается, но не задается в качестве обязательного атрибутом localize в элементе greeting, переданном удаленным партнером BEEP).
Текстовое сообщение (может включать много строк) имеет значимость для разработчиков, администраторов и, возможно, пользователей, но не для программ.

Отметим, что при наличии диагностического текста атрибут xml:lang не указывается лишь в том случае, когда используется язык, указанный первым удаленным партнером BEEP.

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

Узел BEEP может передать сообщение close для канала, когда все сообщения MSG, переданные им в этот канал, были подтверждены (подтверждением служит первый кадр, принятый узлом BEEP, который отправил сообщение MSG).

После передачи сообщения close этот узел BEEP должен прекратить передачу каких-либо сообщений MSG через закрываемый канал, пока не будет получен отклик на сообщение close (сообщение error с отказом от закрытия канала или сообщение ok, говорящее о начале процедуры закрытия).

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

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

В иных случаях до восприятия запроса на закрытие канала и передачи позитивного отклика ok этот узел должен:

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

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

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

       C: MSG 0 2 . 235 71
       C: Content-Type: application/beep+xml
       C:
       C: <close number='1' code='200' />
       C: END
       S: RPY 0 2 . 392 46
       S: Content-Type: application/beep+xml
       S:
       S: <ok />
       S: END

Отказ при закрытии канала может иметь вид:

       C: MSG 0 2 . 235 71
       C: Content-Type: application/beep+xml
       C:
       C: <close number='1' code='200' />
       C: END
       S: ERR 0 2 . 392 79
       S: Content-Type: application/beep+xml
       S:
       S: <error code='550'>still working</error>
       S: END

2.3.1.4. Сообщение OK

Когда узел BEEP согласен закрыть канал (или завершить сессию BEEP), он передает элемент ok в позитивном отклике.

Элемент ok не включает атрибутов или содержимого.

2.3.1.5. Сообщение Error

Когда узел BEEP отвергает создание канала, он передает элемент error в негативном отклике.

       I: MSG 0 1 . 52 115
       I: Content-Type: application/beep+xml
       I:
       I: <start number='2'>
       I:    <profile uri='http://iana.org/beep/FOO' />
       I: </start>
       I: END
       L: ERR 0 1 . 221 105
       L: Content-Type: application/beep+xml
       L:
       L: <error code='550'>all requested profiles are
       L: unsupported</error>
       L: END

Элемент error имеет атрибут code, необязательный атрибут xml:lang и необязательное текстовое поле в качестве содержимого.

Атрибут code содержит трехзначный числовой код отклика, имеющий смысл для программ (8. Коды откликов).
Атрибут xml:lang указывает язык содержимого элемента (значение предлагается, но не задается в качестве обязательного атрибутом localize в элементе greeting, переданном удаленным партнером BEEP).
Текстовое сообщение (может включать много строк) имеет значимость для разработчиков, администраторов и, возможно, пользователей, но не для программ.

В дополнение к сказанному узел BEEP передает элемент error всякий раз, когда:

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

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

2.4. Организация и завершение сессии

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

       L: <ожидание входящего соединения>
       I: <создание соединения>
       L: RPY 0 0 . 0 110
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/TLS' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END

Если же узел, выступающий в роли слушателя, не доступен, он передает негативный отклик, как показано ниже.

       L: <ожидание входящего соединения>
       I: <создание соединения>
       L: ERR 0 0 . 0 60
       L: Content-Type: application/beep+xml
       L:
       L: <error code='421' />
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END
       I: <закрытие соединения>
       L: <закрытие соединения>
       L: <ожидание следующего соединения>

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

Отметим, что в обоих примерах инициатор BEEP ждет, когда слушатель BEEP передаст greeting, но это лишь способ представления 0 — на практике оба партнера BEEP передают свои отклики одновременно.

Узел BEEP, желающий завершить сессию BEEP, передает элемент close с нулевым значением атрибута number в канал 0. Другой узел BEEP указывает свое согласие передачей элемента ok в позитивном отклике, как показано ниже.

       C: MSG 0 1 . 52 60
       C: Content-Type: application/beep+xml
       C:
       C: <close code='200' />
       C: END
       S: RPY 0 1 . 264 46
       S: Content-Type: application/beep+xml
       S:
       S: <ok />
       S: END
       I: <закрытие соединения>
       L: <закрытие соединения>
       L: <ожидание следующего соединения>

Если партнер не хочет закрывать сессию BEEP, обмен может выглядеть иначе:

       C: MSG 0 1 . 52 60
       C: Content-Type: application/beep+xml
       C:
       C: <close code='200' />
       C: END
       S: ERR 0 1 . 264 79
       S: Content-Type: application/beep+xml
       S:
       S: <error code='550'>still working</error>
       S: END

Если завершение сеанса отвергнуто, сессию BEEP, по возможности, не следует прерывать.

2.5. Транспортные отображения

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

2.5.1. Управление сессией

Сессии BEEP работают на основе соединений (connection-oriented). Документ по отображению должен определять:

как организуется сеанс BEEP;
как узел BEEP указывает себя в роли слушателя;
как узел BEEP указывает себя в роли инициатора;
как сессия BEEP освобождается;
как сессия BEEP разрывается (завершается).

2.5.2. Обмен сообщениями

Сессии BEEP работают на основе сообщений. Документ по отображению должен определять:

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

2.6. Асинхронное взаимодействие

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

2.6.1. Внутри одного канала

Узел BEEP, выступающий в роли клиента, может передать множество сообщений MSG в один канал, не ожидая приема соответствующих откликов. Это позволяет создать конвейерную обработку сообщений в рамках одного канала.

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

Отметим, что при обмене «один со многими» (2.1.1. Стили обмена) откликом на сообщение MSG могут (не обязательно) служить сообщения ANS, за которыми следует сообщение NUL. При таком стиле обмена составляющие отклик сообщения ANS могут чередоваться. Когда сервер BEEP указывает завершение отклика путем генерации сообщения NUL, он может начать обработку следующего сообщения MSG, полученного по этому каналу.

2.6.2. Между разными каналами

Узел BEEP в роли клиента может передать множество сообщений MSG по разным каналам, не дожидаясь получения соответствующих откликов. Каналы работают независимо (в параллель).

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

2.6.3. Упреждающие отклики

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

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

2.6.4. Взаимовлияние сообщений

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

2.7. Поведение равноправных узлов

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

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

Например, два приведенных ниже сообщения

       I: MSG 0 1 . 52 120
       I: Content-Type: application/beep+xml
       I:
       I: <start number='1'>
       I:    <profile uri='http://iana.org/beep/SASL/OTP' />
       I: </start>
       I: END
       L: MSG 0 1 . 221 116
       L: Content-Type: application/beep+xml
       L:
       L: <start number='2'>
       L:    <profile uri='http://iana.org/beep/APEX' />
       L: </start>
       L: END

указывают на разные сообщения в канале 0.

3. Транспортная безопасность

Когда сессия BEEP организована, данные передаются в открытом виде (plaintext) без защиты конфиденциальности. Соответственно, транспортная безопасность BEEP достигается использованием профиля начальной настройки.

Данный документ определяет один профиль:

профиль транспортной защиты TLS на основе протокола TLS версии 1 [3].

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

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

Узел BEEP может выбирать разные варианты greeting с учетом используемой защиты конфиденциальности. Например,

       L: <ожидание входящего соединения>
       I: <организация соединения>
       L: RPY 0 0 . 0 110
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/TLS' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END
       I: MSG 0 1 . 52 158
       I: Content-Type: application/beep+xml
       I:
       I: <start number='1'>
       I:    <profile uri='http://iana.org/beep/TLS'>
       I:        <![CDATA[<ready />]]>
       I:    </profile>
       I: </start>
       I: END
       L: RPY 0 1 . 110 121
       L: Content-Type: application/beep+xml
       L:
       L: <profile uri='http://iana.org/beep/TLS'>
       L:     <![CDATA[<proceed />]]>
       L: </profile>
       L: END

… успешное согласование транспортной защиты …

       L: RPY 0 0 . 0 221
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       L:    <profile uri='http://iana.org/beep/SASL/OTP' />
       L:    <profile uri='http://iana.org/beep/APEX' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END

Конечно, не все узлы BEEP должны быть такими целеустремленными:

       L: <ожидание входящего соединения>
       I: <организация соединения>
       L: RPY 0 0 . 0 268
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       L:    <profile uri='http://iana.org/beep/SASL/OTP' />
       L:    <profile uri='http://iana.org/beep/APEX' />
       L:    <profile uri='http://iana.org/beep/TLS' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END
       I: MSG 0 1 . 52 158
       I: Content-Type: application/beep+xml
       I:
       I: <start number='1'>
       I:    <profile uri='http://iana.org/beep/TLS'>
       I:        <![CDATA[<ready />]]>
       I:    </profile>
       I: </start>
       I: END
       L: RPY 0 1 . 268 121
       L: Content-Type: application/beep+xml
       L:
       L: <profile uri='http://iana.org/beep/TLS'>
       L:     <![CDATA[<proceed />]]>
       L: </profile>
       L: END

… отказ при согласовании транспортной защиты …

       L: RPY 0 0 . 0 268
       L: Content-Type: application/beep+xml
       L:
       L: <greeting>
       L:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       L:    <profile uri='http://iana.org/beep/SASL/OTP' />
       L:    <profile uri='http://iana.org/beep/APEX' />
       L:    <profile uri='http://iana.org/beep/TLS' />
       L: </greeting>
       L: END
       I: RPY 0 0 . 0 52
       I: Content-Type: application/beep+xml
       I:
       I: <greeting />
       I: END

3.1. Профиль транспортной защиты TLS

Регистрация данного профиля описана в параграфе 6.2.

3.1.1. Идентификации и инициализация профиля

Профиль транспортной защиты TLS идентифицируется как

       http://iana.org/beep/TLS

в элементе profile в процессе создания канала.

В процессе организации канала соответствующий элемент profile внутри элемента start может содержать элемент ready. Если канал создан, перед отправкой соответствующего отклика узел BEEP обрабатывает элемент ready и включает результат в отклик, как показано ниже.

       C: MSG 0 1 . 52 158
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/TLS'>
       C:        <![CDATA[<ready />]]>
       C:    </profile>
       C: </start>
       C: END
       S: RPY 0 1 . 110 121
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/TLS'>
       S:     <![CDATA[<proceed />]]>
       S: </profile>
       S: END

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

       C: MSG 0 1 . 52 173
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/TLS'>
       C:        <![CDATA[<ready version="oops" />]]>
       C:    </profile>
       C: </start>
       C: END
       S: RPY 0 1 . 110 193
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/TLS'>
       S:     <![CDATA[<error code='501'>version attribute
       S: poorly formed in &lt;ready&gt; element</error>]]>
       S: </profile>
       S: END

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

3.1.2. Синтаксис сообщений

В параграфе 7.2 определены сообщения, используемые профилем транспортной защиты TLS.

3.1.3. Семантика сообщений

3.1.3.1. Сообщение Ready

Элемент ready имеет необязательный атрибут version и не включает содержимого:

элемент version указывает наиболее старую версию TLS, принимаемую для использования.

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

3.1.3.2. Сообщение Proceed

Элемент proceed не имеет атрибутов и содержимого, он передается в качестве отклика на элемент ready.

Когда узел BEEP получает элемент ready, ему недопустимо передавать какой-либо трафик базовому транспорту до генерации соответствующего отклика³. Если узел BEEP решил принять предложенную транспортную защиту, он неявно закрывает все каналы (включая канал 0), передает элемент proceed и ждет завершения процесса согласования защиты на транспортном уровне.

Когда узел BEEP получает элемент proceed в отклике на свой элемент ready, он неявно закрывает все каналы (включая канал 0) и незамедлительно начинает процесс согласования защиты на транспортом уровне.

4. Аутентификация пользователей

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

Этот документ определяет семейство профилей, основанных на механизмах SASL:

каждый механизм из реестра IANA SASL [15] имеет соответствующий профиль.

На двухсторонней основе могут определяться и развертываться другие профили.

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

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

4.1. Семейство профилей SASL

Регистрация для этого профиля представлена в параграфе 6.3.

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

В разделе 4 спецификации SASL [4] требуется предоставление в определении протокола указанной ниже информации:

Имя службы. beep

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

Последовательность обмена. Вызовы (запросы) и отклики передаются в элементах blob. Атрибут status элемента blob используется сервером для индикации успешного завершения обмена, а клиентом — для прерывания обмена. Сервер указывает отказ при обмене передачей элемента error.

Согласование уровня защиты. В начале согласования уровня защиты все каналы (включая канал 0) сессии BEEP закрываются. Следовательно, при завершении процесса согласования, независимо от результата, оба партнера BEEP передают новые сообщения greeting.

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

Использование отождествления для предоставления полномочий. Это отождествление доступно для всех каналов в течение всего срока действия сессии BEEP.

4.1.1. Идентификация и инициализация профиля

Каждый механизм SASL, зарегистрированный IANA, включается в список

       http://iana.org/beep/SASL/mechanism

где mechanism указывает имя, присвоенное этому механизму агентством IANA.

Отметим, что в процессе создания канала узел BEEP может предлагать удаленному партнеру множество профилей, как показано ниже.

       C: MSG 0 1 . 52 178
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
       C:    <profile uri='http://iana.org/beep/SASL/OTP' />
       C: </start>
       C: END
       S: RPY 0 1 . 221 87
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/SASL/OTP' />
       S: END

В процессе создания канала соответствующий элемент profile в элементе BEEP start может содержать элемент blob. Отметим, что возможно создание канала и отказ инкапсуляции. Например,

       C: MSG 0 1 . 52 183
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/SASL/OTP'>
       C:        <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
       C:    </profile>
       C: </start>
       C: END
       S: RPY 0 1 . 221 178
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/SASL/OTP'>
       S:     <![CDATA[<error code='534'>authentication mechanism is
       S: too weak</error>]]>
       S: </profile>
       S: END

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

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

       C: MSG 0 1 . 52 183
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/SASL/OTP'>
       C:        <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
       C:    </profile>
       C: </start>
       C: END
       S: RPY 0 1 . 221 171
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/SASL/OTP'>
       S:    <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
                                                              </blob>]]>
       S: </profile>
       S: END

Отметим, что в этом примере предполагается, что элемент blob в отклике сервера имеет появляется в двух строках — это особенность представления. Фактически используется одна строка.

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

       C: MSG 1 0 . 0 97
       C: Content-Type: application/beep+xml
       C:
       C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
       C: END
       S: RPY 1 0 . 0 66
       S: Content-Type: application/beep+xml
       S:
       S: <blob status='complete' />
       S: END

Клиент может, естественно, прервать процесс проверки подлинности, передав <blob status=’abort’ />.

Кроме того, сервер может отвергнуть отклик клиента. Например,

       C: MSG 1 0 . 0 97
       C: Content-Type: application/beep+xml
       C:
       C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
       C: END
       S: ERR 1 0 . 0 60
       S: Content-Type: application/beep+xml
       S:
       S: <error code='535' />
       S: END

В зависимости от механизма SASL элемент инициализации может передаваться в одном направлении при создании канала. Например,

       C: MSG 0 1 . 52 125
       C: Content-Type: application/beep+xml
       C:
       C: <start number='1'>
       C:    <profile uri='http://iana.org/beep/SASL/CRAM-MD5' />
       C: </start>
       C: END
       S: RPY 0 1 . 221 185
       S: Content-Type: application/beep+xml
       S:
       S: <profile uri='http://iana.org/beep/SASL/CRAM-MD5'>
       S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
                                                     jaS5uZXQ+</blob>]]>
       S: </profile>
       S: END

4.1.2. Синтаксис сообщений

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

Отметим, что в результате использования в SASL множества механизмов обмена двоичными данными, содержимое элемента blob всегда представляется в форме строк base64.

4.1.3. Семантика сообщений

Элемент blob имеет необязательный атрибут status, содержащий произвольные октеты:

при наличии атрибута status они может принимать одно из трех значений:

abort используется клиентом для индикации прерывания процесса проверки подлинности;

complete и используется сервером для индикации успешного завершения обмена;

continue используется любой из сторон в остальных случаях.

В заключение отметим, что механизм EXTERNAL в SASL работает с «внешними службами аутентификации», которые могут обеспечиваться одним из описанные ниже способов:

в соединении профиль будет использоваться транспортной защиты, способный предоставлять данные аутентификации (см., например, параграф 3.1);
базовое соединение обеспечивает сетевую службу, способную выполнить строгую проверку подлинности (например, IPSec [12]);
локально определенные услуги защиты.

Для успешной аутентификации должны быть выполнены два условия:

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

5. Регистрационные шаблоны

5.1. Шаблон регистрации профиля

При регистрации профиля предоставляется перечисленная ниже информация.

Идентификация профиля: задает идентификатор URI [10], полномочно указывающий этот профиль.

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

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

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

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

Сообщения в обмене «один со многими»: задает типы данных, которые могут присутствовать в обмене «один-к-одному».

Синтаксис сообщений: задает синтаксис типов данных для обмена в этом профиле.

Семантика сообщений: задает семантику типов данных для обмена в этом профиле.

Контактные данные: задает почтовые и электронные данные для связи с автором профиля.

5.2. Шаблон регистрации функции

При регистрации функции для профиля канала управления предоставляется следующая информация:

Идентификация функции: указывает строку идентификатора функции (если функция регистрируется в IANA, идентификатор должен начинаться с x-);

Семантика функции: указывает семантику функции;

Контактные данные: задает почтовые и электронные данные для связи с автором профиля.

6. Исходные регистрации

6.1. Управление каналом BEEP

Идентификация профиля: не применимо.

Сообщения при организации канала: не применимо.

Сообщения а начале обмена «один к одному»: «start» или «close».

Сообщения в позитивных откликах: «greeting», «profile» или «ok».

Сообщения в негативных откликах: «error».

Сообщения в обмене «один со многими»: нет.

Синтаксис сообщений: см. параграф 7.1.

Семантика сообщений: см. параграф 2.3.1.

Контактные данные: см. раздел «Адрес автора» в этом документе.

6.2. Профиль транспортной защиты TLS

Идентификация профиля: http://iana.org/beep/TLS.

Сообщения при организации канала: «ready».

Сообщения а начале обмена «один к одному»: «ready».

Сообщения в позитивных откликах: «proceed».

Сообщения в негативных откликах: «error».

Сообщения в обмене «один со многими»: нет.

Синтаксис сообщений: см. параграф 7.2.

Семантика сообщений: см. параграф 3.1.3.

Контактные данные: см. раздел «Адрес автора» в этом документе.

6.3. Семейство профилей SASL

Идентификация профиля: http://iana.org/beep/SASL/mechanism, где mechanism указывает маркер, зарегистрированный IANA.

Сообщения при организации канала: «blob».

Сообщения а начале обмена «один к одному»: «blob».

Сообщения в позитивных откликах: «blob».

Сообщения в негативных откликах: «error».

Сообщения в обмене «один со многими»: нет.

Синтаксис сообщений: см. параграф 7.3.

Семантика сообщений: см. параграф 4.1.3.

Контактные данные: см. раздел «Адрес автора» в этом документе.

6.4. application/beep+xml

Тип MIME media: application.

Субтип MIME: beep+xml.

Требуемые параметры: нет.

Дополнительные параметры: кодировка (по умолчанию UTF-8 [13]).

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

Вопросы безопасности: Нет, однако любой профиль BEEP, использующий этот тип среды (носителя), должен описывать связанные с ним проблемы безопасности.

Вопросы взаимодействия: не применимо.

Опубликованная спецификация: Этот тип является подмножеством спецификации XML 1.0 [2] с двумя исключениями.
Во-первых, не может присутствовать ссылок, на элементы отличающихся от 5 предопределенных базовых («&», «<», «>», «'», and «"») и числовых.
Во-вторых, не могут применяться декларации XML (например, <?xml version=»1.0″ ?>) или DOCTYPE (например, <!DOCTYPE …>). Поэтому в случае использования кодировки, отличающейся от UTF-8, должен применяться параметр charset.
Все остальные инструкции XML 1.0 (например, блоки CDATA, инструкции обработки и т. п.) разрешены.

Приложения, которые могут использовать этот тип: Любой профиль BEEP, применяющий подмножество XML 1.0.

Дополнительная информация: нет.

Контакты для получения дополнительной информации: см. раздел «Адрес автора» в этом документе.

Предусмотренное использование: ограниченное применение.

Автор или контролер изменений: IESG.

7. Определения типов документов (DTD)

7.1. Управление каналами BEEP

   <!--
     DTD для управления каналами BEEP от 2000-10-29
     См. это DTD по ссылке:

       <!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN"
                  "http://xml.resource.org/profiles/BEEP/beep.dtd"> 
       %BEEP;
     -->

   <!--
     Типы данных DTD:
           элемент       синтаксис/ссылка     пример
           =======       ================     =======
       номер канала
           CHAN          1..2147483647        1

       полномочная идентификация профиля
           URI          [RFC-2396]      http://invisible.net/ 

       один или несколько маркеров возможностей, разделенных пробелами
           FTRS         NMTOKENS              "magic"

       тег языка
           LANG         [RFC-1766]      "en", "en-US" и т. п.

       Необязательные теги языков
           LOCS         NMTOKENS              "en-US"

       3-значный код отклика
           XYZ           [1-5][0-9][0-9]      500
   -->

   <!ENTITY % CHAN       "CDATA">
   <!ENTITY % URI        "CDATA">
   <!ENTITY % FTRS       "NMTOKENS">
   <!ENTITY % LANG       "NMTOKEN">
   <!ENTITY % LOCS       "NMTOKEN">
   <!ENTITY % XYZ        "CDATA">

   <!--
     Сообщения BEEP, передаваемые как application/beep+xml

        роль       MSG         RPY         ERR
       =======     ===         ===         ===
       I и L                   greeting    error

       I или L     start       profile     error

       I или L     close       ok          error
     -->

   <!ELEMENT greeting    (profile)*>
   <!ATTLIST greeting
             features    %FTRS;            #IMPLIED
             localize    %LOCS;            "i-default">

   <!ELEMENT start       (profile)+>
   <!ATTLIST start
             number      %CHAN;             #REQUIRED
             serverName  CDATA              #IMPLIED>

   <!-- элемент profile пуст, если содержится в greeting -->
   <!ELEMENT profile     (#PCDATA)>
   <!ATTLIST profile
             uri         %URI;              #REQUIRED
             encoding    (none|base64)      "none">

   <!ELEMENT close       (#PCDATA)>
   <!ATTLIST close
             number      %CHAN;             "0"
             code        %XYZ;              #REQUIRED
             xml:lang    %LANG;             #IMPLIED>

   <!ELEMENT ok          EMPTY>

   <!ELEMENT error       (#PCDATA)>
   <!ATTLIST error
             code        %XYZ;              #REQUIRED
             xml:lang    %LANG;             #IMPLIED>

7.2. Профиль транспортной защиты TLS

   <!--
     DTD для профиля TLS Transport Security от 2000-09-04

     Для ссылки на это DTD служит:

       <!ENTITY % TLS PUBLIC "-//IETF//DTD TLS//EN"
                  "http://xml.resource.org/profiles/TLS/tls.dtd">
       %TLS;
     -->

   <!--
     Сообщения TLS, передаваемые как application/beep+xml

        роль       MSG         RPY         ERR
       ======      ===         ===         ===
       I или L     ready       proceed     error
     -->

   <!ELEMENT ready       EMPTY>
   <!ATTLIST ready
             version     CDATA              "1">

   <!ELEMENT proceed     EMPTY>

7.3. Семейство профилей SASL

   <!--
     DTD для семейства профилей SASL от 2000-09-04

     Для ссылки на это DTD служит:

       <!ENTITY % SASL PUBLIC "-//IETF//DTD SASL//EN"
                  "http://xml.resource.org/profiles/sasl/sasl.dtd">
       %SASL;
     -->

   <!--
     Сообщения SASL, передаваемые как application/beep+xml

        роль       MSG         RPY         ERR
       ======      ===         ===         ===
       I или L     blob        blob        error
     -->

   <!ELEMENT blob        (#PCDATA)>
   <!ATTLIST blob
             xml:space   (default|preserve)
                                           "preserve"
             status      (abort|complete|continue)
                                            "continue">

8. Коды откликов

Код	Значение
200	Успех.
421	Сервис не доступен.
450	Запрошенная операция не выполнена (например, блокировка уже существует).
451	Запрошенная операция прервана (например, локальная ошибка при обработке).
454	Временный отказ при проверке подлинности.
500	Синтаксическая ошибка (например, некорректный формат XML).
501	Синтаксическая ошибка в параметрах (например, недействительный XML).
504	Параметр не реализован.
530	Требуется аутентификация.
534	Недостаточно механизма проверки подлинности (например, слишком слабый).
535	Отказ при проверке подлинности.
537	Действие не разрешено для пользователя.
538	Механизм проверки подлинности требует шифрования.
550	Запрошенная операция не выполнена (например, недоступны запрошенные профили).
553	Непригодный параметр.
554	Отказ транзакции (например, нарушение правил).

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

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

При использовании одного из профилей SASL следует принять во внимание раздел 9 в [4], где рассмотрены вопросы безопасности.
При использовании транспортной защиты TLS (или согласованном уровне защиты SASL) следует принимать во внимание описанные ниже аспекты.
1. Посредник MITM⁴ может удалить связанные с защитой профили из приветствия BEEP или создать негативный отклик для элемента ready профиля транспортной защиты TLS. Узел BEEP можно настроить на отказ от обработки без приемлемого уровня защиты.
2. MITM-посредник может вынудить к принятию наиболее слабого шифра. Узлам BEEP следует поддерживать возможность настройки для отказа от слабых шифров.
3. MITM-посредник может может изменить любой протокольный обмен до успешного согласования. После согласования узел BEEP должен отбрасывать ранее кэшированную информацию о сессии BEEP.
Поскольку разные шифронаборы TLS обеспечивают разную степень защиты, администраторам следует аккуратно выбирать предлагаемые шифры.

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

Литература

[1] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, November 1996.

[2] World Wide Web Consortium, «Extensible Markup Language (XML) 1.0», W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.

[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. And P. Kocher, «The TLS Protocol Version 1.0», RFC 2246, January 1999.

[4] Myers, J., «Simple Authentication and Security Layer (SASL)», RFC 2222, October 1997.

[5] Rose, M., «Mapping the BEEP Core onto TCP», RFC 3081, March 2001.

[6] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[7] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.

[8] Elz, R. and R. Bush, «Serial Number Arithmetic», RFC 1982, August 1996.

[9] Alvestrand, H., «Tags for the Identification of Languages», RFC BCP 47, RFC 3066, January 2001.

[10] Berners-Lee, T., Fielding, R. and L. Masinter, «Uniform Resource Identifiers (URI): Generic Syntax», RFC 2396⁵, August 1998.

[11] Newman, C., «The One-Time-Password SASL Mechanism», RFC 2444, October 1998.

[12] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 2401⁶, November 1998.

[13] Yergeau, F., «UTF-8, a transformation format of ISO 10646», RFC 2279, January 1998.

[14] Linn, J., «Generic Security Service Application Program Interface, Version 2», RFC 2078⁷, January 1997.

[15] <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms>

Адрес автора

Marshall T. Rose

Invisible Worlds, Inc.

1179 North McDowell Boulevard

Petaluma, CA 94954-6559

Phone: +1 707 789 3700

EMail: mrose@invisible.net

URI: http://invisible.net/

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

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

nmalykh@gmail.com

Приложение A. Благодарности

Автор благодарен за вклад в работу David Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston Franklin, Marco Gazzetta, Danny Goodman, Steve Harris, Robert Herriot, Ken Hirsch, Greg Hudson, Ben Laurie, Carl Malamud, Michael Mealling, Keith McCloghrie, Paul Mockapetris, RL ‘Bob’ Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch, Paul Vixie, Gabe Wachob, Daniel Woods и James Woodyatt. В частности, Dave Crocker внес важные предложения по природе сегментации в механизме кадрирования.

Приложение B. Взаимодействие с IANA

Агентство IANA зарегистрировало beep в качестве имени службы GSSAPI [14], как указано в параграфе 4.1.

IANA поддерживает списки:

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

Для каждого списка IESG отвечает за выделение эксперта (designated expert) для рецензирования спецификации до включения в реестры IANA. Разработчики не стандартизуемых профилей и функций управления каналом BEEP могут запросить комментарии к своим предложениям через список рассылки bxxpwg@invisible.net.

Агентство IANA выполнило регистрации, указанные в параграфах 6.2 и 6.3. Рекомендуется использовать префикс IANA в URI и включать в эти URI соответствующие регистрации.

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

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

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

1Blocks Extensible Exchange Protocol — расширяемый протокол обмена блоками.

2В оригинале ошибочно указано значение 4294967295. См. https://www.rfc-editor.org/errata_search.php?eid=992. Прим. перев.

3С учетом последнего предложения параграфа 3.1.3.1 корректней было бы сказать: «Когда узел BEEP начал обработку элемента ready …» Прим. перев.

4Man-in-the-middle — человек посередине.

5Этот документ заменен RFC 3986. Прим. перев.

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

7Этот документ заменен RFC 2743. Прим. перев.

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

RFC 3065 Autonomous System Confederations for BGP

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

Network Working Group                                      P. Traina
Request for Comments: 3065                    Juniper Networks, Inc.
Obsoletes: 1965                                         D. McPherson
Category: Standards Track                       Amber Networks, Inc.
                                                          J. Scudder
                                                 Cisco Systems, Inc.
                                                       February 2001

Конфедерации автономных систем в BGP

Autonomous System Confederations for BGP

PDF

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

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

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

Аннотация

Протокол BGP (Border Gateway Protocol) представляет собой протокол маршрутизации между автономными системами, разработанный для сетей TCP/IP (Transmission Control Protocol/Internet Protocol). BGP требует, чтобы все узлы BGP в одной автономной системе (AS) были связаны между собой (fully meshed — «каждый с каждым»). Это требование порождает серьезные проблемы масштабирования, отмеченные в многочисленных документах.

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

1. Спецификация требований

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

2. Введение

В соответствии со спецификацией протокол BGP требует², чтобы каждый узел BGP в AS имел соединения со всеми другими узлами BGP в этой автономной системе. Результатом этого является необходимость поддержки каждым узлом BGP (в автономной системе с числом узлов n) n*(n-1)/2 уникальных сессий IBGP. Это требование «полносвязности» создает проблемы масштабирования для AS с большим числом узлов IBGP, обычным для многих современных сетей.

Эта проблема масштабирования описана во множестве документов и существует целый ряд предложений по ослаблению проблемы [3,5]. В этом документе предлагается дополнительный способ ослабления проблемы полносвязности, известный как Autonomous System Confederations for BGP или просто BGP Confederations³. Можно также сказать, что конфедерации BGP могут повышать эффективность управления политикой маршрутизации.

Этот документ является пересмотром RFC 1965 [4] и включает редакторские правки, разъяснения и корректировки, основанные на опыте развертывания конфедераций BGP. Изменения по сравнению с упомянутым документом перечислены в Приложении A.

3. Термины и определения

AS Confederation

Группа автономных систем, анонсируемых с общим номером AS узлам BGP, не входящим в данную конфедерацию.

AS Confederation Identifier

Видимый снаружи номер автономной системы, идентифицирующий конфедерацию в целом.

Member-AS

Автономная система, включенная в данную конфедерацию AS.

Member-AS Number

Номер автономной системы, видимый только членам данной конфедерации BGP.

4. Обсуждение

Может оказаться полезным деление автономных систем с большим числом узлов BGP на более мелкие домены в целях управления политикой маршрутизации с помощью данных, содержащихся в атрибуте BGP AS_PATH. Например, можно рассматривать все узлы BGP в неком географическом регионе как единый объект. Кроме потенциального повышения уровня контроля за политикой маршрутизации (если не используются методы типа описанного здесь или в документе [5]) спецификация протокола [1] требует, чтобы все узлы BGP одной автономной системы организовали полносвязную (full mesh) систему соединений TCP со всеми другими узлами для обмена внешней маршрутной информацией. В автономных системах число внутридоменных соединений, которые должен поддерживать каждый граничный маршрутизатор, может становиться весьма значительным.

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

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

И, наконец, деление больших AS может привести к неоправданному увеличению размера упорядоченной части атрибута AS_PATH. Некоторые распространенные реализации BGP могут использовать число “интервалов между AS” (AS hop) до данного адресата, как часть критерия выбора пути. Хотя такой метод определения предпочтительного маршрута не является оптимальным, при нехватке других данных он обеспечивает разумное поведение “по умолчанию”, широко используемое в сети Internet. Следовательно, деление автономной системы на отдельные фрагменты может оказать существенное влияние на уровень оптимальности маршрутизации пакетов через Internet.

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

5. Расширение AS_CONFED для типа сегмента

В действующей спецификации BGP сказано, что атрибут AS_PATH является общеизвестным обязательным атрибутом, состоящим из последовательности сегментов пути (AS path segment). Каждый сегмент пути представляется триплетом <path segment type, path segment length, path segment value>.

В соответствии с [1] тип сегмента пути задается однооктетным полем, для которого определены следующие значения:

Значение	Имя	Описание
1	AS_SET	Неупорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE.
2	AS_SEQUENCE	Упорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE.

В настоящем документе определены два дополнительных типа сегментов пути:

Значение	Имя	Описание
3	AS_CONFED_SEQUENCE	Упорядоченный набор номеров Member AS в локальной конфедерации, через которые передается сообщение UPDATE.
4	AS_CONFED_SET	Неупорядоченный набор номеров Member AS в локальной конфедерации, через которые передается сообщение UPDATE.

6. Принцип работы

Член конфедерации BGP будет использовать свое значение AS Confederation ID во всех транзакциях с партнерами, которые не являются членами данной конфедерации. Этот идентификатор конфедерации рассматривается как видимый извне номер AS, этот номер используется в сообщениях OPEN и анонсируется в атрибуте AS_PATH.

Член конфедерации BGP будет использовать свое значение Member AS Number во всех транзакциях с партнерами, входящими в данную конфедерацию.

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

Узлу BGP, получившему атрибут AS_PATH с сегментами AS_CONFED_SEQUENCE или AS_CONFED_SET, содержащими его Member AS Number, следует трактовать путь так же, как это делается для путей, содержащих номер AS данного узла.

6.1. Правила изменения AS_PATH

Параграф 5.1.2 документа [1] заменяется приведенным ниже текстом:

Когда узел BGP распространяет маршрут, который был получен в сообщении UPDATE от другого узла BGP, ему следует изменить атрибут AS_PATH с учетом размещения узла BGP, которому передается маршрут:

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

1. если первый сегмент AS_PATH имеет тип AS_CONFED_SEQUENCE, локальной системе следует поместить свой номер AS как последний элемент списка (в крайнюю левую позицию).
2. если первый сегмент AS_PATH имеет тип, отличный от AS_CONFED_SEQUENCE, локальной системе следует поместить новый сегмент типа AS_CONFED_SEQUENCE в путь AS_PATH, включив свой идентификатор конфедерации в этот сегмент.

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

если первый сегмент AS_PATH имеет тип AS_CONFED_SEQUENCE, данный сегмент и все непосредственно следующие за ним сегменты типа AS_CONFED_SET или AS_CONFED_SEQUENCE удаляются из атрибута AS_PATH и после этого для атрибута выполняется этап 2 или 3 (см. ниже).
Если первый оставшийся сегмент AS_PATH имеет тип AS_SEQUENCE, локальной системе следует поместить свой идентификатор конфедерации в качестве последнего элемента (в крайнюю левую позицию).
Если после удаления сегментов AS_CONFED_SET/AS_CONFED_SEQUENCE не остается других сегментов пути или первый сегмент оставшейся части AS_PATH имеет тип AS_SET, локальной системе следует включить (prepend) в атрибут AS_PATH новый сегмент типа AS_SEQUENCE, указав в нем свой идентификатор конфедерации.

1. Когда узел BGP является источником маршрута, этому узлу следует:

включать пустой атрибут AS_PATH во все сообщения UPDATE, передаваемые узлам BGP в Member AS Number (пустой атрибут AS_PATH содержит нулевое значение в поле размера);
включать свой Member AS Number в сегмент AS_CONFED_SEQUENCE атрибута AS_PATH всех сообщений UPDATE, передаваемых узлам BGP в соседних AS, являющихся членами конфедерации (т. е., значение Member AS Number исходного отправителя будет единственным элементом атрибута AS_PATH);
включать номер AS своей конфедерации в сегмент AS_SEQUENCE атрибута AS_PATH всех сообщений UPDATE, передаваемых узлам BGP в соседних AS, которые не являются членами данной конфедерации; в этом случае номер AS конфедерации будет единственным элементом атрибута AS_PATH.

7. Общие вопросы администрирования

Вполне разумно в рамках конфедерации использовать единое администрирование и информацию IGP.

Узлам BGP следует разрешить анонсирование без изменения атрибутов NEXT_HOP и MULTI_EXIT_DISCRIMINATOR (MED) партнерам из соседних AS, входящих в ту же конфедерацию. В дополнение к этому отменяется ограничение на передачу атрибута LOCAL_PREFERENCE партнерам из соседних AS своей конфедерации. Критерии выбора пути для информации, полученной от членов конфедерации, должны быть такими же, какие указаны для партнеров из своей автономной системы в спецификации [1].

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

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

Любой узел BGP, не поддерживающий эти расширения, будет генерировать сообщение NOTIFICATION с кодом ошибки UPDATE Message Error и субкодом Malformed AS_PATH.

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

9. Развертывание конфедераций

Конфедерации BGP широко распространены в сети Internet уже много лет и поддерживаются множеством производителей.

Некорректная настройка конфедерации BGP может приводить к ненужному дублированию маршрутной информации внутри AS. Такое дублирование будет отнимать системные ресурсы, приводить к ненужным переключениям маршрутов (flap) и увеличивать задержку схождения (convergence).

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

В дополнение к этому конфедерации (как и рефлекторы маршрутов), исключая из рассмотрения информацию о доступности в различных точках конфедерации, могут вызывать постоянные осцилляции между маршрутами-кандидатами при использовании правил “развязывания узлов” (tie breaking), требуемых спецификацией BGP [1]. Следует с осторожностью относиться к выбору значений MED и правилам tie breaking для предотвращения проблем.

Одним из способов предотвращения проблем является установка для метрики inter-Member-AS IGP⁴ значения большего, нежели для метрики intra-Member-AS IGP⁵, и/или использование иных правил tie breaking для предотвращения выбора маршрутов BGP на основе несравнимых MED.

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

Это расширение не оказывает влияния на вопросы безопасности протокола BGP, рассмотренные в документе [6].

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

Общая концепция конфедераций BGP была заимствована из Routing Domain Confederations для IDRP [2]. Часть вводного текста этого документа была заимствована из [5].

Авторы выражают свою признательность Bruce Cole из Juniper Networks за информацию о реализации и анализ ограничений расширения протокола, описанного в данном документе и работе [5]. Мы также благодарим Srihari Ramachandra из Cisco Systems, Inc. за комментарии.

Авторы также выражают свою признательность Ravi Chandra и Yakov Rekhter за конструктивные и полезные замечания в процессе работы с ранними версиями этого документа.

12. Литература

[1] Rekhter, Y. and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, March 1995.

[2] Kunzinger, C., Editor, «Inter-Domain Routing Protocol», ISO/IEC 10747, October 1993.

[3] Haskin, D., «A BGP/IDRP Route Server alternative to a full mesh routing», RFC 1863, October 1995.

[4] Traina, P. «Autonomous System Confederations for BGP», RFC 1965, June 1996.

[5] Bates, T., Chandra, R. and E. Chen, «BGP Route Reflection An Alternative to Full Mesh IBGP», RFC 2796, April 2000.

[6] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

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

Paul Traina

Juniper Networks, Inc.

1194 N. Mathilda Ave.

Sunnyvale, CA 94089 USA

Phone: +1 408 745-2000

EMail: pst+confed@juniper.net

Danny McPherson

Amber Networks, Inc.

48664 Milmont Drive

Fremont, CA 94538

Phone: +1 510.687.5226

EMail: danny@ambernetworks.com

John G. Scudder

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134

Phone: +1 734.669.8800

EMail: jgs@cisco.com

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

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

nmalykh@protokols.ru

Приложение A: Сравнение с RFC 1965

Наиболее важным отличием от [4]⁸ является замена значений AS_CONFED_SEQUENCE(4) и AS_CONFED_SET(3) на значения, определенные в параграфе «Расширение AS_CONFED для типа сегмента». Причина этой замены обусловлена тем, что в начальных реализациях, которые достаточно широко распространены, были использованы значения, поменянные местами по сравнению с [4] и такое использование продолжалось в последующих реализациях. Для обеспечения интероперабельности и совместимости с имеющимися реализациями значения в данном документе были поменяны местами.

Параграф «Проблемы совместимости⁹» был исключен, а вопросы из этого параграфа рассмотрены в других частях данного документа. Были также исключены упоминания иерархических конфедераций. Термин Routing Domain Identifier был заменен термином Member AS Number.

Наконец, был расширен параграф «Развертывание конфедераций» и в него были внесены некоторые редакторские правки.

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

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

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

1Этот документ устарел и заменен RFC 5065. Прим. перев.

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

3Конфедерации автономных систем для BGP или просто BGP-конфедерации

4Протокол внутренней маршрутизации между членами конфедерации.

5Протокол внутренней маршрутизации для входящих в конфедерацию AS.

8В оригинале эта ссылка ошибочно указывает на документ [1]. Прим. перев.

9Compatibility Discussion.

Рубрика: RFC | Оставить комментарий

RFC 3042 Enhancing TCP’s Loss Recovery Using Limited Transmit

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

Network Working Group                                      M. Allman
Request for Comments: 3042                              NASA GRC/BBN
Category: Standards Track                            H. Balakrishnan
                                                                 MIT
                                                            S. Floyd
                                                               ACIRI
                                                        January 2001

Эффективное восстановление TCP после потерь с использованием ограниченной передачи

Enhancing TCP’s Loss Recovery Using Limited Transmit

PDF

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

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

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

Аннотация

Этот документ предлагает новый механизм TCP¹, который может использоваться для более эффективного восстановления при потере сегментов, когда окно насыщения для соединения достаточно мало или теряется множество сегментов из одного окна передачи. Алгоритм «ограниченной передачи²» вызывается для отправки нового сегмента данных в ответ на первый из каждой пары дубликатов подтверждений, полученной отправителем. Передача этих сегментов повышает вероятность того, что TCP сможет выполнить восстановление после потери одного сегмента с помощью алгоритма ускоренного повтора передачи без дорогостоящего ожидания тайм-аута для повтора. Ограниченная передача может использоваться вместе с механизмом селективных подтверждений TCP SACK³ или независимо от него.

1. Введение

Многие исследователи отмечали, что стратегии восстановления TCP при потере пакетов работают недостаточно хорошо, когда окно насыщения на стороне отправителя TCP мало. Это может происходить, например, по причине передачи ограниченного объема данных, в результате ограничений, вносимых анонсируемым получателем окном, или в силу ограничений, обусловленных механизмом сквозного контроля насыщения при работе через канал с малым значением произведения полоса*задержка [Riz96,Mor97,BPS+98,Bal98,LK98]. Когда TCP детектирует отсутствие сегмента, протокол переходит в фазу восстановления с использованием одного из двух методов. В первом методе если подтверждение (ACK) для данного сегмента не получено в течение некого интервала времени, возникает тайм-аут повтора передачи и сегмент отправляется заново [RFC793,PA00]. Второй метод (алгоритм ускоренного повтора⁴) повторяет передачу сегмента при получении отправителем трех дубликатов ACK [Jac88,RFC2581]. Однако в результате того, что передача дубликатов получателем может быть вызвана также нарушением порядка следования пакетов в Internet, получатель TCP дожидается получения трех дубликатов ACK, чтобы попытаться отличить потерю сегмента от нарушения порядка доставки. В фазе восстановления может использоваться множество методов для повторной передачи потерянных сегментов, включая восстановление на основе процедуры замедленного старта или ускоренного восстановления Fast Recovery [RFC2581], NewReno [RFC2582] или восстановления на базе селективных подтверждений (SACK) [RFC2018,FF96].

Тайм-аут повторной передачи TCP (RTO⁵) определяется на основе измерения времени кругового обхода (RTT⁶) между отправителем и получателем в соответствии со спецификацией [PA00]. Для предотвращения ненужных повторов передачи сегментов, которые были задержаны, но не потеряны, в качестве минимального значения RTO выбрана 1 секунда. Следовательно, это позволяет отправителю TCP детектировать и восстанавливать состояние при потере множества сегментов без продолжительного ожидания в состоянии бездействия. Однако при недостаточном количестве сегментов ACK, принятых от получателя, алгоритм Fast Retransmit не включается — такая ситуация возникает при малом размере окна насыщения или потере большого числа сегментов в одном окне. В качестве примера рассмотрим окно насыщения (cwnd) размером 3 сегмента. Если один сегмент будет отброшен в сети, отправитель будет получать не более двух дубликатов ACK. Поскольку для включения механизма ускоренного повтора требуется три дубликата ACK, повтор передачи отброшенного в сети пакета будет осуществляться по тайм-ауту.

В работе [BPS+97] показано, что около 56% повторов передачи от загруженных web-серверов происходит по тайм-ауту RTO и только 44% обрабатывается механизмом Fast Retransmit. Кроме того, лишь 4% повторов по тайм-ауту RTO можно избежать при использовании SACK, который тоже не позволяет четко различать потери и нарушение порядка доставки. Использование метода, описанного в этом документе и работе [Bal98], позволяет избежать 25% повторов по тайм-ауту RTO.

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

1.1. Уровни требований

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

2. Алгоритм ограниченной передачи

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

анонсируемое получателем окно позволяет передать сегмент;
объем остающихся в сети данных не будет превышать размер окна насыщения + 2 сегмента (иными словами, отправитель может передать не более 2 сегментов сверх размера окна насыщения cwnd).

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

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

Механизм ограниченной передачи позволяет контролировать насыщение по принципу «консервации пакетов» [Jac88]. Каждый первый из пары дубликатов ACK показывает, что сегмент покинул сеть. Более того, отправитель еще не принял решения о том, что сегмент был отброшен и, следовательно, не имеет причин для предположения о некорректности текущего состояния контроля насыщения. Следовательно, передача сегментов не будет отклонением от духа принципов контроля насыщения TCP.

В работе [BPS99] показано, что нарушение порядка доставки в сети не является редким событием. В соответствии с [RFC2581] первые два дубликата ACK, полученные отправителем, не вызывают передачи повтора. Это приводит к всплеску передачи сегментов при получении новых подтверждений вслед за нарушением порядка доставки. При использовании механизма ограниченной передачи пакеты данных будут передаваться в сеть по прибытии сегментов ACK и, следовательно, пиков возникать не будет.

Примечание. Механизм Limited Transmit реализован в имитаторе сети [NS]. Желающие исследовать этот механизм могут воспользоваться для этого имитатором, включив опцию singledup_ для нужного соединения TCP.

3. Связанные работы

Развертывание механизмов явного уведомления о перегрузке (ECN⁷) [Flo94,RFC2481] может принести пользу для соединений с малым размером окна насыщения [SA00]. ECN обеспечивает метод индикации перегрузки конечным хостам без отбрасывания сегментов. Хотя некоторые сегменты все же могут теряться, ECN может повысить эффективность работы TCP при малом размере окна насыщения, поскольку отправитель может избежать многократного использования механизмов ускоренного повтора и повтора по тайм-ауту, которые потребовались бы для детектирования отброшенных сегментов [SA00].

Когда трафик с поддержкой ECN конкурирует с трафиком TCP без ECN, для трафика ECN можно получить рост пропускной способности до 30% по сравнению с трафиком без ECN. Для передачи больших объемов данных относительный рост производительности в результате использования ECN увеличивается если в среднем каждый поток имеет 3-4 остающихся в сети пакета для каждого периода кругового обхода [ZQ00]. Это может служить хорошей оценкой влияния на производительность потока механизма ограниченной передачи, поскольку ECN и Limited Transmit снижают влияние тайм-аута повтора на сигнализацию перегрузки.

Алгоритм контроля насыщения Rate-Halving⁸ [MSML99] использует одну из форм ограниченной передачи, отправляя сегмент данных на каждый второй дубликат ACK, полученный отправителем. Алгоритм отделяет решение вопросов «что» и «когда» передавать. Однако, подобно Limited Transmit, этот алгоритм всегда будет передавать новый сегмент данных в ответ на получение отправителей второго дубликата ACK.

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

Дополнительное влияние на безопасность в результате использования описанных в документе приложений на текущий уровень безопасности TCP является минимальным. Потенциальной проблемой является возможность нарушения работы сквозного контроля насыщения с помощью «ложных» дубликатов ACK, которые на самом деле не подтверждают поступление данных на приемную сторону TCP. Ложные дубликаты ACK могут возникать в результате дублирования подтвреждений в сети или некорректного поведения получателей TCP, которые передают ложные сегменты ACK для обхода системы сквозного контроля насыщения [SCWA99,RFC2581].

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

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

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

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

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

Bill Fenner, Jamshid Mahdavi и рабочая группа Transport Area предоставили множество полезных откликов на ранние версии этого документа.

Литература

[Bal98] Hari Balakrishnan. Challenges to Reliable Data Transport over Heterogeneous Wireless Networks. Ph.D. Thesis, University of California at Berkeley, August 1998.

[BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan, Mark Stemm, and Randy Katz. TCP Behavior of a Busy Web Server: Analysis and Improvements. Technical Report UCB/CSD-97-966, August 1997. Available from http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps. (Опубликовано также в Proc. IEEE INFOCOM Conf., San Francisco, CA, March 1998.)

[BPS99] Jon Bennett, Craig Partridge, Nicholas Shectman. Packet Reordering is Not Pathological Network Behavior. IEEE/ACM Transactions on Networking, December 1999.

[FF96] Kevin Fall, Sally Floyd. Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. ACM Computer Communication Review, July 1996.

[Flo94] Sally Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, October 1994.

[Jac88] Van Jacobson. Congestion Avoidance and Control. ACM SIGCOMM 1988.

[LK98] Dong Lin, H.T. Kung. TCP Fast Recovery Strategies: Analysis and Improvements. Proceedings of InfoCom, March 1998.

[MSML99] Matt Mathis, Jeff Semke, Jamshid Mahdavi, Kevin Lahey. The Rate Halving Algorithm, 1999. URL: http://www.psc.edu/networking/rate_halving.html.

[Mor97] Robert Morris. TCP Behavior with Many Flows. Proceedings of the Fifth IEEE International Conference on Network Protocols. October 1997.

[NS] Имитатор сети Ns. URL: http://www.isi.edu/nsnam/.

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

[Riz96] Luigi Rizzo. Issues in the Implementation of Selective Acknowledgments for TCP. January, 1996. URL: http://www.iet.unipi.it/~luigi/selack.ps

[SA00] Hadi Salim, J. and U. Ahmed, «Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks», RFC 2884, July 2000.

[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, Tom Anderson. TCP Congestion Control with a Misbehaving Receiver. ACM Computer Communications Review, October 1999.

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, «TCP Selective Acknowledgement Options», RFC 2018, October 1996.

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

[RFC2481] Ramakrishnan, K. and S. Floyd, «A Proposal to Add Explicit Congestion Notification (ECN) to IP», RFC 2481, January 1999.

[RFC2581] Allman, M., Paxson, V. and W. Stevens, «TCP Congestion Control», RFC 2581, April 1999.

[RFC2582] Floyd, S. and T. Henderson, «The NewReno Modification to TCP’s Fast Recovery Algorithm», RFC 2582, April 1999.

[ZQ00] Yin Zhang and Lili Qiu, Understanding the End-to-End Performance Impact of RED in a Heterogeneous Environment, Cornell CS Technical Report 2000-1802, July 2000. URL http://www.cs.cornell.edu/yzhang/papers.htm.

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

Mark Allman

NASA Glenn Research Center/BBN Technologies

Lewis Field

21000 Brookpark Rd. MS 54-5

Cleveland, OH 44135

Phone: +1-216-433-6586

Fax: +1-216-433-8705

EMail: mallman@grc.nasa.gov

http://roland.grc.nasa.gov/~mallman

Hari Balakrishnan

Laboratory for Computer Science

545 Technology Square

Massachusetts Institute of Technology

Cambridge, MA 02139

EMail: hari@lcs.mit.edu

http://nms.lcs.mit.edu/~hari/

Sally Floyd

AT&T Center for Internet Research at ICSI (ACIRI)

1947 Center St, Suite 600

Berkeley, CA 94704

Phone: +1-510-666-2989

EMail: floyd@aciri.org

http://www.aciri.org/floyd/

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

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

nmalykh@protokols.ru

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

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

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

1Transmission Control Protocol — протокол управления передачей.

2Limited Transmit.

3Selective acknowledgment.

4Fast Retransmit.

5Retransmission timeout.

6Round-trip time.

7Explicit Congestion Notification.

8«Ополовинивание» скорости передачи.

Рубрика: RFC | Оставить комментарий

RFC 3032 MPLS Label Stack Encoding

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

Network Working Group                                       E. Rosen
Request for Comments: 3032                                 D. Tappan
Category: Standards Track                                G. Fedorkow
                                                 Cisco Systems, Inc.
                                                          Y. Rekhter
                                                    Juniper Networks
                                                        D. Farinacci
                                                               T. Li
                                              Procket Networks, Inc.
                                                            A. Conta
                                              TranSwitch Corporation
                                                        January 2001

Представление стека меток MPLS

MPLS Label Stack Encoding

PDF

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

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

Аннотация

Для многопротокольной коммутации по меткам (MPLS¹) [1] требуется набор процедур добавления в пакеты сетевого уровня «стека меток», превращающего такие пакеты в «помеченные». Маршрутизаторы, поддерживающие MPLS, называют LSR². Для передачи помеченных пакетов через определенный канал маршрутизатор LSR должен поддерживать метод кодирования меток, позволяющий из данного стека меток и пакета сетевого уровня создавать помеченный пакет. В этом документе описаны процедуры кодирования, используемые LSR для передачи пакетов в каналы PPP³, ЛВС и, возможно, в каналы других типов. На некоторых типах каналов передачи данных верхняя метка стека⁴ может кодироваться по-иному, но для остальной части стека меток должны использоваться методы кодирования, описанные в настоящем документе. В документе также приведены правила и процедуры обработки различных полей стека меток.

1. Введение

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

В этом документе описаны процедуры кодирования, используемые LSR для передачи пакетов в каналы PPP и ЛВС. Описанные здесь методы кодирования могут быть полезны и для других типов каналов.

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

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

1.1. Уровни требований

2. Стек меток

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Элемент
|                 Label                 | Exp |S|     TTL       | стека
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ меток

Label — значение метки (20 битов)

Exp — для экспериментов (3 бита)

S — дно стека (1 бит)

TTL — время жизни (8 битов)

Рисунок 1: Элемент стека меток

Стек меток кодируется, как последовательность элементов стека, каждый из которых представ-ляется 4 октетами, как показано на рисунке 1.

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

Каждый элемент стека состоит из 4 полей:

Дно стека (S)Этот бит устанавливается для последней записи в стеке меток (дно стека) и имеет нулевое значение для остальных элементов стека.
Время жизни (TTL)Это 8-битовое поле используется для указания времени жизни. Обработка поля описана в параграфе 2.4.
Для экспериментовЭто 3-битовое поле зарезервировано для экспериментального использования.
Значение меткиЭто 20-битовое поле содержит собственно метку.

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

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

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

Для меток имеется несколько зарезервированных значений:

Нулевое значение представляет IPv4 Explicit NULL Label⁵. Это значение допустимо только на дне стека меток и показывает, что метка должна быть вытолкнута из стека, а пересылка должна осуществляться на основе заголовка IPv4.
Значение 1 представляет Router Alert Label. Такая метка может находиться в любом месте стека, за исключением дна. При получении пакета с такой меткой наверху стека, пакет передается для обработки локальным программам. Реальная пересылка такого пакета определяется по следующей метке в стеке. Однако, если пакет пересылается дальше, метка Router Alert должна быть помещена на вершину стека до пересылки пакета. Использование этой метки осуществляется аналогично опции Router Alert в заголовках пакетов IP [5]. Поскольку такая метка не может находиться на дне стека, она не связывается с каким-либо протоколом сетевого уровня.
Значение 2 представляет IPv6 Explicit NULL Label. Это значение допустимо только на дне стека меток и показывает, что метка должна быть вытолкнута из стека, а пересылка должна осуществляться на основе заголовка IPv6.
Значение 3 представляет неявную пустую метку (Implicit NULL Label). Такую метку LSR может выделить и распространять, но эта метка никогда не появляется в инкапсуляции. Когда LSR выполняет операцию замены метки и новым значением является Implicit NULL, маршрутизатор LSR будет просто выталкивать метку из стека вместо ее замены пустой меткой. Хотя это значение никогда не используется при инкапсуляции, оно требуется для протокола распространения меток и по этой причине зарезервировано.
Значения 4-15 являются резервными.

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

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

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

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

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

2.3. Генерация сообщений ICMP для помеченных пакетов IP

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

LSR должен иметь возможность определения принадлежности конкретного помеченного пакета к протоколу IP;
LSR должен иметь возможность маршрутизации пакетов по адресу отправителя исходного пакета IP.

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

2.3.1. Туннелирование через транзитный домен маршрутизации

Предположим, что MPLS используется для туннелирования данных через транзитный маршрутный домен, где информация о внешних маршрутах не передается внутренним маршрутизаторам домена. Например, внутренние маршрутизаторы могут работать на основе протокола OSPF и знать лишь о доступности адресатов в своем домене OSPF. Домен может включать несколько граничных маршрутизаторов АС (ASBR⁷), которые связаны между собой по протоколу BGP. Однако в этом примере маршруты от BGP не передаются в OSPF, а на маршрутизаторах LSR, которые не относятся к числу ASBR, не используется протокол BGP.

В приведенном примере только маршрутизаторы ASBR будут знать путь к источнику того или иного пакета. Если внутреннему маршрутизатору нужно отправить сообщение ICMP отправителю пакета IP, он не будет знать, как следует маршрутизировать сообщение ICMP.

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

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

2.3.2. Туннелирование приватных адресов через публичные сети

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

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

Этот метод очень полезен для доставки ICMP-сообщений «Time Exceeded» или «Destination Unreachable because fragmentation needed and DF set».

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

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

2.4. Обработка поля TTL

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

Входящее значение TTL для помеченного пакета определяется, как значение поля TTL в верхней метке стека при получении пакета.

Исходящим значением TTL для помеченного пакета является большее из двух значений:

уменьшенное на 1 входящее значение TTL;
0.

2.4.2. Независимые от протокола правила

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

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

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

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

2.4.3. Правила для протокола IP

Определим значение поля IP TTL, как значение поля IPv4 TTL или поля IPv6 Hop Limit в зависимости от версии IP.

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

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

Известно, что во многих случаях сетевые администраторы предпочитают декрементировать значение IPv4 TTL один раз в процессе прохождения через домен MPLS вместо декрементирования IPv4 TTL на число интервалов LSP в данном домене.

2.4.4. Преобразование типа инкапсуляции

Иногда LSR может получать пакет через интерфейс, управляемый коммутацией по меткам (например, LC-ATM⁹ [9]), и этот пакет нужно будет передать через канал PPP или ЛВС. В этом случае входящий пакет не будет инкапсулирован в соответствии с данной спецификацией, но исходящий должен инкапсулироваться в соответствии с этой спецификацией.

В таких случаях значение «входящего TTL» определяется процедурами, используемыми для передачи помеченных пакетов (например, для интерфейсов LC-ATM) и обработка TTL выполняется в соответствии с приведенным выше описанием.

Иногда LSR может получать пакет через канал PPP или ЛВС и этот пакет нужно будет передать через интерфейс типа LC-ATM. В таких случаях входящий пакет использует инкапсуляцию, описанную в данном документе, но исходящий пакет должен инкапсулироваться иначе. Процедура передачи «исходящего TTL» будет определяться процедурами передачи помеченных пакетов через соответствующий интерфейс (например, LC-ATM).

3. Фрагментация и определение Path MTU

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

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

В этом разделе рассматриваются правила обработки помеченных пакетов избыточного размера. В частности, приведены правила, при выполнении которых хосты, реализующие процедуры Path MTU Discovery [4], и хосты IPv6 [7,8] смогут генерировать дейтаграммы IP, не требующие фрагментации даже в случае добавления к ним меток при передаче через сеть.

В общем случае хосты IPv4, не использующие Path MTU Discovery [4], передают дейтаграммы IP, которые содержат не более 576 байтов. Однако на большинстве современных каналов передачи данных значение MTU достигает 1500 и более байтов, поэтому вероятность фрагментирования таких дейтаграмм даже при добавлении к ним меток очень мала.

Некоторые хосты, не поддерживающие Path MTU Discovery [4], будут генерировать дейтаграммы IP, содержащие 1500 байтов, в которых IP-адреса отправителя и получателя относятся к одной подсети. Такие дейтаграммы не будут проходить через маршрутизаторы и, следовательно, не фрагментируются.

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

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

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

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

Frame Payload — данные кадра

Содержимое кадра канального уровня без заголовков и трейлеров канального уровня (например, заголовков MAC, LLC, 802.1Q, PPP, контрольных сумм кадра и т. п.).

Когда кадр передает непомеченную IP-дейтаграмму, Frame Payload представляет собой просто саму дейтаграмму IP. Если в кадре содержится помеченная дейтаграмма, Frame Payload будет включать стек меток и саму дейтаграмму IP.

Conventional Maximum Frame Payload Size — согласованный максимальный размер данных кадра

Максимальный размер Frame Payload, допускаемый стандартами канального уровня. Например, Conventional Maximum Frame Payload Size для сетей Ethernet составляет 1500 байтов.

True Maximum Frame Payload Size — истинный максимальный размер данных кадра

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

Для сетей Ethernet и 802.3 предполагается, что True Maximum Frame Payload Size на 4-8 байтов превышает Conventional Maximum Frame Payload Size (пока заголовки 802.1Q и 802.1p отсутствуют и ни один из таких заголовков не может быть добавлен коммутатором или мостом, через который пакет передается на следующий интервал). Например, предполагается, что большая часть оборудования Ethernet может корректно передавать и принимать кадры с размером данных 1504, а возможно и 1508 байтов, пока заголовок кадра Ethernet не включает полей 802.1Q или 802.1p.

На каналах PPP значение True Maximum Frame Payload Size виртуально может быть неограниченным.

Effective Maximum Frame Payload Size for Labeled Packets — эффективный максимальный размер данных кадра для помеченных пакетов

Значение Conventional Maximum Frame Payload Size или True Maximum Frame Payload Size, в зависимости от возможностей оборудования передачи данных и используемого размера заголовков канального уровня.

Initially Labeled IP Datagram — первоначально помечаемая дейтаграмма IP

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

Previously Labeled IP Datagram — ранее помеченная дейтаграмма IP

Дейтаграмма IP, которая уже была помечена до ее получения LSR.

3.2. Максимальный размер первоначально помечаемых дейтаграмм IP

Каждому LSR, который способен
принимать непомеченные дейтаграммы IP;
добавлять стек меток к дейтаграмме;
пересылать полученный в результате пакет с меткой,

следует поддерживать конфигурационный параметр Maximum Initially Labeled IP Datagram Size, который может принимать неотрицательные значения.

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

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

получена дейтаграмма IP без метки;
бит DF¹⁰ в заголовке дейтаграммы IP не установлен;
дейтаграмму нужно пометить до ее пересылки;
размер дейтаграммы (без добавляемой метки) превосходит значение параметра,

то выполняются следующие действия:

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

Например, при установке для параметра значения 1488, все непомеченные дейтаграммы IP, содержащие более 1488 байтов будут фрагментироваться перед добавлением метки. Каждый фрагмент в этом случае может без дополнительной фрагментации передавать 1500 байтов данных на канальном уровне даже при размещении в стеке 3 меток.

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

Отметим, что установка этого параметра не оказывает влияния на обработку дейтаграмм IP с установленным флагом DF, следовательно, этот параметр не оказывает влияния на параметры фрагментации, установленные с помощью Path MTU discovery.

3.3. Когда помеченная дейтаграмма IP слишком велика?

Помеченная дейтаграмма IP, размер которой превышает Conventional Maximum Frame Payload Size для канального уровня, в который пакет будет пересылаться, может трактоваться, как «слишком большая».

Помеченная дейтаграмма IP, размер которой превышает True Maximum Frame Payload Size для канального уровня, через который она будет пересылаться, должна трактоваться, как «слишком большая».

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

3.4. Обработка помеченных дейтаграмм IPv4 избыточного размера

Если помеченная дейтаграмма IPv4 «слишком велика» и в заголовке IP не установлен флаг DF, LSR может отбросить дейтаграмму без уведомления.

Отметим, что отбрасывание таких дейтаграмм является осмысленной процедурой лишь в том случае, когда установлено ненулевое значение параметра Maximum Initially Labeled IP Datagram Size на каждом LSR в сети, который способен добавлять стек меток в непомеченные дейтаграммы IP.

Если LSR принимает решение не отбрасывать помеченную дейтаграмму IPv4 избыточного размера или в этой дейтаграмме установлен флаг DF, маршрутизатор должен использовать приведенный ниже алгоритм:

«Вырезать» элементы стека меток для получения дейтаграммы IP.
Пусть N — число байтов в стеке меток (число меток в стеке, умноженное на 4).
Если в дейтаграмме IP не установлен флаг запрета фрагментирования в заголовке IP, нужно:

1. разбить дейтаграмму на фрагменты, каждый из которых должен быть по крайней мере на N байтов меньше эффективного максимума размера данных кадра (Effective Maximum Frame Payload Size);
2. присоединить к каждому фрагменту спереди тот же заголовок с метками, который имела исходная дейтаграмма до фрагментирования;
3. переслать все фрагменты.

Если в заголовке дейтаграммы IP установлен флаг запрета фрагментирования:

1. недопустимо пересылать дейтаграмму;
2. нужно создать сообщение ICMP Destination Unreachable:

1. 1. установить в поле Code [3] этого сообщения значение Fragmentation Required and DF Set;
  2. установить в качестве значения поля Next-Hop MTU [4] разницу между значением эффективного максимума размера данных в кадре и N;

1. по возможности, передать сообщение ICMP Destination Unreachable отправителю отброшенной дейтаграммы.

3.5. Обработка помеченных дейтаграмм IPv6 избыточного размера

Для обработки дейтаграмм IPv6 избыточного размера LSR должен использовать описанный ниже алгоритм.

«Вырезать» элементы стека меток для получения дейтаграммы IP.
Пусть N — число байтов в стеке меток (число меток в стеке, умноженное на 4).
Если дейтаграмма IP содержит более 1280 байтов (без учета стека меток) или не содержит заголовка фрагмента, нужно:

1. создать сообщение ICMP Packet Too Big и установить в нем для поля Next-Hop MTU значение разницы между эффективным максимумом размера данных в кадре и N;
2. по возможности, передать сообщение ICMP Packet Too Big отправителю отброшенной дейтаграммы;
3. отбросить помеченную дейтаграмму IPv6.

Если размер дейтаграммы IP не превышает 1280 октетов и она имеет заголовок фрагмента, нужно:

1. разбить дейтаграмму на фрагменты, каждый из которых должен быть по крайней мере на N байтов меньше эффективного максимума размера данных в кадре;
2. присоединить к каждому фрагменту спереди тот же заголовок с метками, который имела исходная дейтаграмма до фрагментирования;
3. переслать все фрагменты.

Сборка фрагментов будет осуществляться получателем.

3.6. Взаимодействие с Path MTU Discovery

Описанные выше процедуры обработки дейтаграмм избыточного размера с установленным флагом запрета фрагментирования DF оказывают влияние на процедуры Path MTU Discovery, описанные в RFC 1191 [4]. Хосты, использующие эти процедуры, будут получать значение MTU, которое достаточно мало и позволяет поместить в дейтаграмму n¹¹ меток без возникновения необходимости фрагментирования дейтаграммы.

Иными словами, дейтаграммы от хостов, использующих Path MTU Discovery никогда не потребуется фрагментировать в результате необходимости добавления заголовка меток или добавления меток в существующий заголовок (обычно дейтаграммы от хостов, использующих Path MTU Discovery имеют флаг DF и, следовательно, не могут фрагментироваться).

Отметим, что Path MTU Discovery будет корректно работать только при наличии в точке, где возникает необходимость фрагментирования, помеченной дейтаграммы IP, есть возможность генерации и передачи отправителю исходной дейтаграммы сообщения ICMP Destination Unreachable (см. 2.3. Генерация сообщений ICMP для помеченных пакетов IP).

Если нет возможности пересылки сообщения ICMP в «туннеле» MPLS по адресу отправителя пакета, а конфигурация сети позволяет LSR на передающей стороне туннеля принимать пакеты, которые должны пройти сквозь туннель, но слишком велики для туннелирования без фрагментации:

LSR на передающей стороне туннеля должен иметь возможность определения MTU для туннеля в целом. Это можно сделать путем передачи пакетов через туннель на приемную сторону и выполнения для этих пакетов процедуры Path MTU Discovery.
Когда передающей стороне требуется передать в туннель пакет с установленным флагом DF и размером, превышающим значение MTU для туннеля, передающая сторона туннеля должна передать отправителю пакета сообщение ICMP Destination Unreachable с кодом Fragmentation Required and DF Set и значением поля Next-Hop MTU, установленным, как сказано выше.

4. Передача помеченных пакетов по каналам PPP

Протокол PPP¹² [6] обеспечивает стандартный метод транспортировки дейтаграмм разных протоколов по каналам «точка-точка». PPP определяет расширяемый протокол управления каналом LCP¹³ и предлагает семейство протоколов управления сетью NCP¹⁴ для организации и настройки конфигурации различных протоколов сетевого уровня.

В этом параграфе определен протокол управления сетью для организации и настройки коммутации по меткам через PPP.

4.1. Введение

PPP включает три основных компоненты:

метод инкапсуляции дейтаграмм различных протоколов;
протокол LCP для организации, настройки параметров и тестирования соединений канального уровня;
семейство протоколов NCP для организации и настройки различных протоколов сетевого уровня.

Для организации соединения через канал «точка-точка» каждая сторона канала PPP должна сначала передать пакеты LCP для настройки и тестирования канала данных. После организации канала и согласования опций, как требует LCP, протокол PPP должен передать пакеты MPLS Control Protocol для того, чтобы разрешить передачу помеченных пакетов. После перехода протокола MPLS Control в состояние Opened можно передавать через канал пакеты с метками.

Канал будет сохранять коммуникационные настройки, пока не будет явно закрыт с помощью пакета протокола управления LCP или MPLS Control или в результате некого внешнего события (например, по тайм-ауту или в результате действий сетевого администратора).

4.2. Протокол PPP NCP для MPLS

Протокол MPLSCP¹⁵ отвечает за разрешение и запрет коммутации по меткам на канале PPP. Он использует такой же механизм обмена сообщениями, как в протоколе LCP. Обмен пакетами MPLSCP не допускается, пока PPP не достигнет фазы Network-Layer Protocol. Полученные до этого момента пакеты MPLSCP следует отбрасывать без уведомления.

Ниже перечислены отличия протокола MPLSCP от LCP [6].

Изменение кадровПакет может использовать любые изменения базового формата кадров, которые были согласованы в фазе Link Establishment.
Поле протокола канального уровняВ поле PPP Information может инкапсулироваться единственный пакет MPLSCP. Поле PPP Protocol в этом случае содержит шестнадцатеричное значение 8281 (MPLSCP¹⁶).
Поле Code

Используются только значения кодов от 1 до 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack и Code-Reject). Остальные коды следует трактовать, как нераспознанные, и передавать в ответ Code-Reject.
Тайм-ауты
Обмен пакетами MPLSCP не допускается, пока PPP не перейдет в фазу Network-Layer Protocol. Реализациям следует быть готовыми к ожиданию завершения фаз Authentication и Link Quality Determination прежде, чем прервать ожидание Configure-Ack или другого отклика. Предполагается, что реализация будет прерывать ожидание только после вмешательства пользователя или по истечении заданного в конфигурации времени.
Типы конфигурационных опцийНет.

4.3. Передача помеченных пакетов

До начала обмена помеченными пакетами PPP должен достичь фазы Network-Layer Protocol, а MPLSCP — состояния Opened.

В поле PPP Information инкапсулируется единственный помеченный пакет и поле PPP Protocol содержит шестнадцатеричное значение 0281 (MPLS Unicast) или 0283 (MPLS Multicast). Максимальный размер пакета с меткой, передаваемого по каналу PPP, совпадает с максимальным размером поля Information для пакетов, инкапсулируемых в PPP.

Формат самого поля Information для пакетов с метками определен в разделе 2.

Отметим, что для пакетов с метками выделены два кода — один для индивидуальной адресации, другой — для групповой. Как только протокол MPLSCP достигнет состояния Opened, через канал PPP можно будет передавать помеченные пакеты как с индивидуальной, так и с групповой адресацией.

4.4. Конфигурационные опции MPLSCP

Протокол не имеет конфигурационных опций.

5. Передача помеченных пакетов через ЛВС

В каждом кадре передается единственный пакет с меткой.

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

Шестнадцатеричное значение ethertype = 8847 используется для индикации кадров с пакетами MPLS c индивидуальной адресацией.

Шестнадцатеричное значение ethertype = 8848 используется для индикации кадров с пакетами MPLS c групповой адресацией.

Эти значение ethertype могут использоваться с инкапсуляцией Ethernet или 802.3 LLC/SNAP для передачи помеченных пакетов. Процедура выбора конкретного типа инкапсуляции выходит на пределы этого документа.

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

Значение меток от 0 до 15, включительно, используются для специальных целей, указанных в этом документе или заданных позднее агентством IANA.

В этом документе значения меток от 0 до 3 описаны в параграфе 2.1.

Значения меток от 4 до 15 выделяются агентством IANA по согласованию с IETF (IETF Consensus).

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

Описанная здесь инкапсуляция MPLS не вызывает новых проблем в плане безопасности, которых уже не было отмечено в архитектуре MPLS [1] или протокола сетевого уровня, используемого для инкапсуляции.

Существует две унаследованных от архитектуры MPLS проблемы безопасности, которые следует отметить здесь:

Некоторые маршрутизаторы могут поддерживать процедуры защиты, зависящие от положения заголовка сетевого уровня относительно заголовка канального уровня. Такие процедуры не будут работать при использовании инкапсуляции MPLS, поскольку при этом применяются заголовки переменного размера.
Значение метки MPLS определяется соглашением между LSR, помещающим метку в стек (label writer), и LSR, который интерпретирует эту метку (label reader). Однако в стеке меток не содержится информации, позволяющей идентифицировать создателя конкретной метки. Если помеченные пакеты принимаются от недоверенного источника, это может привести к нарушению картины маршрутизации.

8. Интеллектуальная собственность

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

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

Eric C. Rosen

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA, 01824

EMail: erosen@cisco.com

Dan Tappan

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA, 01824

EMail: tappan@cisco.com

Yakov Rekhter

Juniper Networks

1194 N. Mathilda Avenue

Sunnyvale, CA 94089

EMail: yakov@juniper.net

Guy Fedorkow

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA, 01824

EMail: fedorkow@cisco.com

Dino Farinacci

Procket Networks, Inc.

3910 Freedom Circle, Ste. 102A

Santa Clara, CA 95054

EMail: dino@procket.com

Tony Li

Procket Networks, Inc.

3910 Freedom Circle, Ste. 102A

Santa Clara, CA 95054

EMail: tli@procket.com

Alex Conta

TranSwitch Corporation

3 Enterprise Drive

Shelton, CT, 06484

EMail: aconta@txc.com

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

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

nmalykh@protokols.ru

10. Литература

[1] Rosen, E., Viswanathan, A., and 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. and 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. and S. Deering, «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 1885, December 1995.

[8] McCann, J., Deering, S. and J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, August 1996.

[9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. and G. Swallow, «MPLS Using LDP and ATM VC Switching», RFC 3035, January 2001.

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

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

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

1Multi-Protocol Label Switching

2Label Switching Router

3Point-to-Point Protocol

4Иное кодирование может использоваться для двух верхних меток стека. Прим. перев.

5Явная пустая (нулевая) метка IPv4.

6Эта метка в дальнейшем будет в стеке последней (нижней). Прим. перев.

7Autonomous System Border Router.

8Это заявление не вполне соответствует требованиям параграфа 3.2.2 RFC 1122, где сказано, что сообщения ICMP недопустимо передавать в ответ на сообщения ICMP об ошибках. Однако в контексте этого документа проблем не возникает, поскольку речь здесь идет именно о сообщениях ICMP об ошибках. Прим. перев.

9Label switching controlled ATM.

10Флаг запрета фрагментирования. Прим. перев.

11Число меток, которые могут быть помещены в дейтаграмму на пути доставки.

12Point-to-Point Protocol.

13Link Control Protocol.

14Network Control Protocol.

15MPLS Control Protocol.

16В исходном документе ошибочно указано «MPLS». Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 3031 Multiprotocol Label Switching Architecture

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

Network Working Group                                       E. Rosen
Request for Comments: 3031                       Cisco Systems, Inc.
Category: Standards Track                             A. Viswanathan
                                              Force10 Networks, Inc.
                                                           R. Callon
                                              Juniper Networks, Inc.
                                                        January 2001

Архитектура MPLS

Multiprotocol Label Switching Architecture

PDF

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

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

Аннотация

В этом документе приведена спецификация архитектуры многопротокольной коммутации пакетов по меткам (MPLS¹).

Оглавление

Исключено в версии HTML.

1. Соглашение

2. Введение в MPLS

В этом документе приведена спецификация архитектуры многопротокольной коммутации по меткам (MPLS).

Отметим, что использование MPLS для групповой адресации требует дополнительного исследования.

2.1. Обзор

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

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

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

В MPLS отнесение пакета к определенному классу FEC происходит однократно при входе пакета в сеть. FEC, к которому отнесен пакет, кодируется коротким целым числом фиксированного размера, которое называют меткой. При пересылке пакета на следующий интервал метка передается вместе с пакетом (т. е. пакет «помечается» до пересылки).

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

В парадигме пересылки MPLS после того, как пакет отнесен к FEC, дальнейшего анализа заголовка на следующих маршрутизаторах не требуется — вся пересылка осуществляется по меткам. Это дает ряд преимуществ по сравнению с традиционной пересылкой на сетевом уровне.

MPLS-пересылка может выполняться коммутаторами, которые умеют просматривать и менять метки, но не способны анализировать заголовки сетевого уровня или не могут обеспечить достаточной производительности при таком анализе.
Поскольку пакет связывается с классом FEC на входе в сеть, маршрутизаторы на входе могут использовать для классификации пакетов любую информацию из этих пакетов, даже если эти данные не относятся к заголовку сетевого уровня. Например, пакеты, приходящие на разные порты, могут быть отнесены к разным FEC. При традиционной же пересылке может рассматриваться только информация из заголовков сетевого уровня.
Пакет, входящий в сеть через определенный маршрутизатор, может классифицироваться иначе, чем такой же пакет, входящий через другой маршрутизатор. В результате легко реализуется пересылка в зависимости от точки входа в сеть. Такое решение невозможно при традиционной пересылке, поскольку информация о точке входа в сеть не передается с пакетом.
Процедуры классификации пакетов по FEC могут усложняться и совершенствоваться без какого-либо влияния на маршрутизаторы, выполняющие пересылку помеченных пакетов.
Иногда желательно отправить пакет по конкретному маршруту, который явно выбирается до или на этапе входа пакета в сеть, вместо использования обычного алгоритма динамической маршрутизации при передаче пакета через сеть. Это можно сделать в форме правил или средствами организации трафика³. При традиционной пересылке такой маршрут потребуется поместить в заголовок и передавать вместе с пакетом (source routing). В MPLS вместо задания маршрута может использоваться метка, которая будет представлять маршрут, что позволяет избавиться от явной передачи маршрута в заголовке пакета.

Некоторые маршрутизаторы анализируют в пакетах заголовок сетевого уровня не только для выбора следующего интервала, но и для определения «предпочтительности» или класса обслуживания пакета. После такого определения маршрутизаторы могут использовать разные пороги отбрасывания или дисциплины очередей для различных пакетов. MPLS разрешает (но не требует) влияние уровня предпочтения или класса обслуживания на выбор маршрута, который обычно определяется меткой. В таких случаях можно говорить, что метка определяется комбинацией FEC и уровня предпочтения или класса обслуживания.

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

Маршрутизаторы, поддерживающие MPLS, называют маршрутизаторами с коммутацией по меткам или LSR⁴.

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

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

DLCI

Метка, используемая в сетях Frame Relay для идентификации устройств (соединений).

forwarding equivalence class — класс эквивалентной пересылки

Группа пакетов IP, которые пересылаются единообразно (например, по одному пути с однотипным обслуживанием).

frame merge — слияние кадров

Слияние меток, применяемое в средах на основе передачи кадров для того, чтобы не возникало проблем «чередования» ячеек.

label — метка

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

label merging — слияние меток

Замена множества входящих меток для определенного FEC одной исходящей меткой.

label swap — переключение меток

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

label swapping — переключение меток

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

label switched hop — интервал коммутации по меткам

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

label switched path — путь с коммутацией по меткам

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

label switching router — маршрутизатор с коммутацией по меткам

Узел MPLS, способный пересылать обычные пакеты L3.

layer 2 — уровень 2

Уровень протокола, лежащий ниже уровня 3 (который, следовательно, обеспечивает сервис, используемый уровнем 3). Пересылка при ее осуществлении путем коммутации коротких меток фиксированного размера, происходит на уровне 2, независимо от того, будут проверяться ATM VPI/VCI, DLCI или метки MPLS.

layer 3 — уровень 3

Уровень протокола, на котором работает IP и связанные с ним протоколы маршрутизации.

link layer

Синоним layer 2.

loop detection — обнаружение петель

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

loop prevention — предотвращение петель

Метод работы с петлями, при котором данные никогда не передаются через петлю.

label stack — стек меток

Упорядоченный набор меток.

merge point — точка слияния

Узел, на котором происходит слияние меток.

MPLS domain — домен MPLS

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

MPLS edge node — краевой узел MPLS

Узел MPLS, который соединяет домен MPLS с узлом, находящимся за пределами домена, по причине того, что на нем не работает MPLS или данный узел относится к другому домену. Отметим, что если LSR имеет соседний хост, на котором не работает MPLS, данный LSR будет краевым узлом MPLS.

MPLS egress node — выходной узел MPLS

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

MPLS ingress node — входной узел MPLS

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

MPLS label — метка MPLS

Метка, которая передается в пакете для представления FEC.

MPLS node — узел MPLS

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

MultiProtocol Label Switching

Рабочая группа IETF и связанная с этой группой деятельность.

network layer — сетевой уровень

Синоним уровня 3.

stack — стек

Синоним стека меток.

switched path — путь коммутации

Синоним пути с коммутацией по меткам.

virtual circuit — виртуальное устройство

Устройство (канал) в основанной на прямых соединениях технологии уровня 2 (например, ATM или Frame Relay), требующее поддержки некой информации о состоянии этого устройства в коммутаторах уровня 2.

VC merge — слияние виртуальных устройств

Слияние меток, при котором метка MPLS переносится в поле ATM VCI (или поля VPI/VCI), что позволяет объединять множество VC в одно виртуальное устройство (VC).

VP merge — слияние виртуальных путей

Слияние меток, при котором метка MPLS переносится в поле ATM VPI, что позволяет объединять множество VP в один виртуальный путь (VP). В этом случае две ячейки будут иметь одно значение VCI лишь при их происхождении от одного узла. Это позволяет распределять ячейки из различных источников по разным VCI.

VPI/VCI — идентификатор виртуального пути/виртуального устройства

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

2.3. Используемые сокращения

ATM Asynchronous Transfer Mode — асинхронный режим передачи.

BGP Border Gateway Protocol — протокол граничного шлюза.

DLCI Data Link Circuit Identifier — идентификатор соединения на канальном уровне.

FEC Forwarding Equivalence Class — класс эквивалентной пересылки.

FTN FEC to NHLFE Map — отображение FEC на NHLFE.

IGP Interior Gateway Protocol — протокол внутреннего шлюза.

ILM Incoming Label Map — отображение входящих меток.

IP Internet Protocol — протокол Internet (IP).

LDP Label Distribution Protocol — протокол распространения меток.

L2 Layer 2 — уровень 2.

L3 Layer 3 — уровень 3.

LSP Label Switched Path — путь с коммутацией по меткам.

LSR Label Switching Router — маршрутизатор с коммутацией по меткам.

MPLS MultiProtocol Label Switching — многопротокольная коммутация по меткам.

NHLFE Next Hop Label Forwarding Entry — запись для следующего интервала пересылки по меткам.

SVC Switched Virtual Circuit — коммутируемое виртуальное устройство (канал).

SVP Switched Virtual Path — коммутируемый виртуальный путь.

TTL Time-To-Live — время жизни.

VC Virtual Circuit — виртуальное устройство (канал).

VCI Virtual Circuit Identifier — идентификатор виртуального устройства.

VP Virtual Path — виртуальный путь.

VPI Virtual Path Identifier — идентификатор виртуального пути.

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

Идеи и текст этого документа были собраны из множества источников и полученных от читателей комментариев. Мы благодарим Rick Boivie, Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan, и George Swallow за их идеи и вклад в подготовку документа.

3. Основы MPLS

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

3.1. Метки

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

В общем случае пакет связывается с FEC на основе (полностью или частично) адреса получателя. Однако метка никогда не является представлением этого адреса.

Если маршрутизаторы Ru и Rd являются LSR, они могут договориться между собой, что Ru при передаче пакетов Rd будет маркировать их меткой L тогда и только тогда, когда эти пакеты относятся к некому FEC-классу F. Согласуется «связка» метки L с классом F для пакетов, передаваемых от Ru к Rd. В результате такого соглашения L становится исходящей меткой маршрутизатора Ru для представления класса F и входящей меткой для представления этого класса на маршрутизаторе Rd.

Отметим, что L не обязательно представляет класс F для каких-либо пакетов, кроме тех, которые будут передаваться от Ru к Rd. L — произвольное значение, связь которого с классом F является локальной для пары маршрутизаторов Ru и Rd.

Когда выше мы писали «пакет, передаваемый от Ru к Rd», мы не предполагали, что источником пакета является Ru или конечным получателем является Rd. Пакеты, о которых мы говорим, обычно являются транзитными для обоих LSR.

Иногда маршрутизатору Rd трудно или невозможно сказать для принятого пакета с меткой L, что эта метка была помещена в пакет маршрутизатором Ru, а не другим LSR (обычно это происходит в тех случаях, когда Ru и Rd не являются прямыми соседями). В таких случаях Rd должен быть уверен, что отображение классов FEC на метки является взаимно-однозначным, т. е. для Rd недопустимо соглашаться с тем, что Ru1 будет отображать метку L на класс F1, если он уже согласился с тем, что Ru2 уже связал метку L с другим классом F2, в том случае, когда Rd не может надежно отличить пакеты с меткой L, полученные от Ru1, и пакеты с такой же меткой от Ru2.

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

3.2. Восходящий и нисходящий LSR

Предположим, что маршрутизаторы Ru и Rd согласовали связывание метки L с FEC-классом F для пакетов, передаваемых от Ru к Rd. В этом случае относительно такой связи маршрутизатор Ru будет «восходящим LSR⁵», а Rd — «нисходящим LSR⁶».

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

3.3. Помеченный пакет

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

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

В архитектуре MPLS решение о связывании конкретной метки L с определенным FEC-классом F принимается LSR, который является нисходящим относительно данной связки. Нисходящий LSR информирует о созданной связи восходящий LSR. Таким образом метки распределяются нисходящими узлами и распространяются в направлении от нисходящего маршрутизатора к восходящему.

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

3.5. Атрибуты привязки меток

Конкретное связывание метки L с классом F, распространяемое маршрутизатором Rd маршрутизатору Ru, может иметь некие «атрибуты». Если Ru, действуя как нисходящий LSR, также распространяет связывание метки с FEC-классом F, при некоторых условиях от него может потребоваться также распространение соответствующего атрибута, полученного от Rd.

3.6. Протокол распространения меток

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

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

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

Для архитектуры недопустимо предположение о существовании единственного протокола распространения меток. Фактически может быть стандартизовано множество таких протоколов. Существующие протоколы могут расширяться путем добавления в них поддержки распространения меток (см., например, [MPLS-BGP], [MPLS-RSVP-TUNNELS]). Могут также разрабатываться новые протоколы именно для распространения меток (см., например, [MPLS-LDP], [MPLS-CR-LDP].

В этом документе аббревиатура LDP будет использоваться преимущественно для обозначения протокола, определенного в [MPLS-LDP].

3.7. Распространение меток по запросам и без запроса

Архитектура MPLS позволяет LSR явно запрашивать от следующего интервала информацию о метке для конкретного класса FEC. Такой механизм называется «нисходящим распространением меток по запросу».

Архитектура MPLS допускает также распространение маршрутизаторами LSR информации о связках без явного запроса такой информации. Такой механизм называется «незапрошенным распространением».

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

3.8. Режимы удерживания меток

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

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

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

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

3.9. Стек меток

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

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

Пакеты без меток можно рассматривать, как пакеты с пустым стеком меток (т. е., стеком глубиной 0).

Если стек меток имеет глубину m, нижнюю метку будем называть меткой уровня 1, расположенную непосредственно над ней — меткой уровня 2 (если такая метка присутствует), а верхняя метка будет иметь уровень m.

Эффективность использования стека меток станет понятной при обсуждении туннелей LSP и иерархии MPLS (см. параграф 3.27. Туннели и иерархия).

3.10. NHLFE

При пересылке помеченных пакетов используется элемент NHLFE, содержащий:

следующий интервал для пересылки пакета;
операцию, выполняемую над стеком меток, в качестве каковой может использоваться:

1. замена верхней метки в стеке заданной новой меткой;
2. выталкивание метки из стека;
3. замена верхней метки в стеке заданной новой меткой и включение в стек одной или множества новых меток.

NHLFE может также включать:

1. инкапсуляцию канального уровня для использования при передаче пакета;
2. способ представления стека меток при передаче пакета;
3. другую информацию, которая может потребоваться для корректной обработки пакета.

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

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

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

3.11. ILM

ILM отображают входящие метки на NHLFE. Это отображение используется при пересылке помеченных пакетов.

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

3.12. Отображение FEC на NHLFE (FTN)

FTN отображает каждый класс FEC на множество NHLFE. Такие отображения используются при пересылке пакетов, которые были получены без меток, но должны быть помечены до пересылки.

Если FTN отображает метку на множество NHLFE, содержащее более одного элемента, до пересылки пакета должен быть выбран единственный элемент из такого множества. Процедуры выбора элемента из множества выходят за рамки документа. Наличие FTN-отображения FEC⁹ на множество, содержащее более одного NHLFE может быть полезно, например, в тех случаях, когда желательно распределить нагрузку между множеством равноценных путей.

3.13. Замена меток

Замена меток (Label swapping) представляет собой использование перечисленных ниже процедур при пересылке пакета.

Для пересылки помеченного пакета LSR смотрит метку в стеке и с помощью ILM отображает эту метку на NHLFE. Используя данные NHLFE, маршрутизатор определяет, куда следует пересылать пакет, и выполняет требуемые операции над стеком меток пакета. Новый стек меток помещается в пакет и после этого выполняется пересылка.
При пересылке пакета без метки LSR анализирует заголовок сетевого уровня для отнесения пакета к тому или иному классу FEC. С помощью FTN маршрутизатор отображает пакет на NHLFE. Используя данные NHLFE, маршрутизатор определяет, куда следует пересылать пакет, и выполняет требуемые операции над стеком меток пакета (выталкивание метки из стека в этом случае будет некорректной операцией). Новый стек меток помещается в пакет и после этого выполняется пересылка.

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

3.14. Зона действия и актуальность меток

LSR-маршрутизатор Rd может связать метку L1 с FEC-классом F и сообщить об этой связке своему партнеру по распространению меток Ru1. Маршрутизатор Rd может также связать метку L2 с FEC-классом F и распространить информацию об этой связке другому партнеру Ru2. Выполнение для таких случаев условия L1 == L2 не задается архитектурой и определяется локально.

Данный LSR-маршрутизатор Rd может связать метку L с FEC-классом F1 и распространить информацию об этой связке своему партнеру Ru1. Маршрутизатор Rd может также связать метку L с классом F2 и распространить информацию об этой связке другому партнеру Ru2. Если (и только в этом случае) RD может определить при получении пакета с верхней меткой L, отправлен этот пакет маршрутизатором RU1 или маршрутизатором RU2, то архитектура не требует выполнения условия F1 == F2. В таких случаях мы будем говорить, что Rd распространяет маршрутизаторам Ru1 и Ru2 разные пространства меток.

В общем случае Rd может определить, получен пакет с верхней меткой L от маршрутизатора Ru1 или маршрутизатора Ru2 только при выполнении обоих приведенных ниже условий.

Ru1 и Ru2 исчерпывают число партнеров, которым Rd распространил информацию о связывании метки L.
Каждый из маршрутизаторов Ru1 и Ru2 подключен к Rd через интерфейс «точка-точка».

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

Если некий LSR Rd подключен к другому LSR Ru через два интерфейса «точка-точка», Rd может распространять маршрутизатору Ru информацию о привязке метки L к FEC-классу F1, а также о привязке этой метки к классу F2 (F1 != F2) тогда и только тогда, когда каждая из привязок относится лишь к пакетам, которые Ru передает Rd только через один из интерфейсов. В остальных случаях маршрутизатору Rd недопустимо распространять Ru связывание одной метки с двумя разными классами FEC.

Этот запрет сохраняется и в тех случаях, когда привязки осуществляются на разных «уровнях иерархии». В MPLS не вводится нотации, обеспечивающей разные пространства меток для разных уровней иерархии, — при интерпретации метки она рассматривается независимо от уровня иерархии.

Возникает вопрос о возможности для LSR использовать множество пространств меток для платформы или множество пространств для интерфейса на одном интерфейсе. Архитектура не запрещает такого использования. Однако в таких случаях LSR должен обеспечивать некий (зависящий от архитектуры) способ определения принадлежности входящих меток к тому или иному пространству. Например, [MPLS-SHIM] задает использование разных пространств меток для индивидуальной (unicast) и групповой (multicast) адресации, а для определения принадлежности метки к тому или иному пространству служат коды канального уровня.

3.15. LSP, LSP Ingress, LSP Egress

Путь с коммутацией по меткам (LSP) уровня m для пакета P представляет последовательность маршрутизаторов

<R1, …, Rn>,

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

R1 — LSP Ingress¹⁰ — маршрутизатор LSR, который помещает метку в стек P, увеличивая глубину стека до m.
Для всех i от 1 до n (1<i<n) пакет P имеет стек меток глубиной m при получении этого пакета маршрутизатором LSR Ri.
Ни в какой момент передачи P от R1 до R[n-1] глубина стека меток не становится меньше m.
Для всех i от 1 до n (1<i<n) маршрутизатор Ri передает P маршрутизатору R[i+1] с помощью MPLS, т. е. используя верхнюю метку стека (метку уровня m) в качестве индекса ILM.
Если при любом i от 1 до n (1<i<n) система S получает и пересылает P после того, как пакет P был передан Ri, но до того, как P был принят R[i+1] (например, Ri и R[i+1] могут быть соединены через коммутируемую на канальном уровне подсеть, а S является одним из коммутаторов), решение системы S о пересылке пакета принимается без использования метки уровня m или информации из заголовка сетевого уровня. Это можно осуществить двумя путями:

1. решение о пересылке принимается без использования стека меток или заголовков сетевого уровня;
2. решение принимается на основе стека меток, в который были помещены дополнительные метки (например, на основе метки уровня m+k, где k>0).

Иными словами, мы можем говорить о LSP уровня m для пакета P, как о последовательности маршрутизаторов, которая:

начинается с маршрутизатора LSR, помещающего метку на уровень m (LSP Ingress);
состоит из промежуточных маршрутизаторов LSR, принимающих решение о пересылке по метке уровня m;
заканчивается маршрутизатором (LSP Egress¹¹), принимающим решение о пересылке по метке уровня m-k (где k>0) или традиционным способом без использования процедур MPLS.

Следствием этого (или, возможно, допущением) является то, что при присвоении маршрутизатором LSR метки ранее помеченному пакету, нужно быть уверенным в том, что новая метка соответствует классу FEC, для которого в качестве LSP Egress служит LSR, присвоивший метку, ставшую второй в стеке.

Будем называть последовательность LSR «LSP для FEC-класса F», если эта цепочка представляет собой LSP уровня m для некого пакета P, когда метка уровня m в пакете P является меткой, соответствующей FEC—классу F.

Рассмотрим набор узлов, которые могут быть входами LSP для FEC-класса F. Тогда существует LSP для FEC-класса F, который начинается на каждом из таких узлов. Если эти LSP имеют общий выход, можно рассматривать набор таких LSP, как дерево, корнем которого является LSP Egress¹². Мы можем, таким образом, говорить о дереве LSP для конкретного FEC-класса F.

3.16. «Выталкивание» на предпоследнем интервале

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

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

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

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

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

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

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

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

код может быть существенно упрощен, если не требуется многократного просмотра;
код может базироваться на «временном бюджете», предполагающем единственный просмотр.

Фактически, при выталкивании метки из стека узел LSP Egress может даже не быть LSR.

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

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

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

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

3.17. Следующий интервал LSP

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

LSP Next Hop для конкретного FEC является следующий интервал, выбранный по записи NHLFE, которая индексируется меткой, соответствующей данному FEC.

Отметим, что LSP Next Hop может отличаться от следующего интервала, который будет выбран алгоритмом маршрутизации на основе заголовка сетевого уровня. Для последнего далее будет использоваться термин «следующий интервал L3».

3.18. Некорректные входящие метки

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

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

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

3.19. Независимое и упорядоченное управление LSP

Некоторые классы FEC соответствуют адресным префиксам, распространяемым с использованием алгоритма динамической маршрутизации. Организация LSP для таких FEC может быть выполнена двумя способами — Independent LSP Control (независимое управление) или Ordered LSP Control (упорядоченное управление).

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

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

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

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

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

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

3.20. Агрегирование

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

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

Для данного набора FEC, являющегося агрегируемым в один класс FEC, можно (a) агрегировать множество классов с один FEC, (b) агрегировать их во множество классов FEC или (c) не использовать агрегирования. Таким образом, можно говорить о детализации агрегирования, которая может быть грубой (случай a) и тонкой (случай b¹⁴).

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

При использовании независимого режима возможны ситуации, когда два смежных LSR-маршрутизатора Ru и Rd будут по разному агрегировать один и тот же набор FEC.

Если Ru задает более тонкую детализацию, нежели Rd, проблем возникать не будет, поскольку Ru распространяет для данного набора FEC больше меток, чем Rd. Это означает, что для передачи соответствующих пакетов от Ru к Rd, будет выполняться отображение n меток на m меток и n > m. Ru может отозвать набор из n распространенных им меток и потом распространить набор из m меток в соответствии с детализацией Rd. Это не требуется для обеспечения корректной работы, но несколько снижает число меток, распространяемых Ru (маршрутизатор Ru не получает каких-либо преимуществ в результате распространения большего числа меток). Решение вопроса о снижении числа распространяемых меток принимается локально.

Если Ru использует более грубую детализацию по сравнению с Rd (т. е., Rd распространяет для набора FEC n меток, а Ru — m и n > m), возникает два варианта:

Принять более тонкую детализацию Rd. Для этого требуется отозвать m распространенных меток и распространить n. Этот вариант является предпочтительным.
Можно просто отобразить m меток на подмножество из n меток маршрутизатора Rd, если ясно, что маршрутизация в результате не изменится. Предположим, что Ru использует одну метку для всего трафика, который требуется передать через некий выходной узел LSR, а Rd связывает с таким трафиком множество разных меток в зависимости от индивидуальных получателей пакетов. Если Ru знает адрес выходного маршрутизатора и Rd связывает метку с классом FEC, который идентифицирует этот адрес, Ru может просто использовать соответствующую метку.

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

3.21. Выбор маршрута

Выбором маршрута будем называть метод, используемый при определении LSP для конкретного FEC. Рассматриваемая архитектура MPLS поддерживает два варианта выбора маршрута — (1) поэтапная маршрутизация и (2) явное задание маршрута.

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

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

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

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

Процедуры использования заданных явно (строго или нестрого) маршрутов выходят за рамки этого документа.

3.22. Отсутствие исходящей метки

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

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

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

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

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

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

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

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

Способ обслуживания TTL может существенно зависеть от того, передаются значения меток MPLS в специфическом для MPLS shim-заголовке [MPLS-SHIM] или в заголовке канального уровня (как в ATM [MPLS-ATM] или Frame Relay [MPLS-FRMRLY]).

Если метка помещается в shim-заголовок между заголовками канального и сетевого уровня, этот дополнительный заголовок должен иметь поле TTL, в которое изначально следует помещать значение поля TTL из заголовка сетевого уровня, а в дальнейшем это значение следует уменьшать на 1 на каждом интервале LSR, копируя измененное значение в заголовок сетевого уровня на выходе LSP.

Если метка размещается в заголовке канального уровня (например, поле VPI/VCI в заголовке ATM AAL5) и помеченные пакеты пересылаются коммутатором L2 (например, ATM), а сам канальный уровень (как в случае ATM) не имеет поля TTL, значение времени жизни невозможно изменить на каждом интервале LSR. Сегмент LSP, состоящий из последовательности LSR, не способных декрементировать значение TTL, будем называть «сегментом LSP без поддержки TTL».

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

Иногда на входе в сегмент LSP без поддержки TTL можно определить, что время жизни пакета истечет до того, как он покинет данный сегмент. В таких случаях для маршрутизатора LSR на входе сегмента без поддержки TTL недопустимо коммутировать пакет. Это означает, что требуется разработать специальные процедуры для поддержки трассировки (например, пакеты трассировки могут пересылаться с использованием традиционной парадигмы поэтапной пересылки).

3.24. Контроль петель

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

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

Даже при наличии доступа к буферу потребуются те или иные способы детектирования петель, которые превышают допустимый размер. В дополнение к этому даже в тех случаях, когда поле TTL и независимая буферизация для каждого VC обеспечивают предотвращение негативного влияния петель, желательно иметь механизм предотвращения организации LSP с петлями. Все LSR, которые могут быть присоединены к сегментам LSP без поддержки TTL, должны, следовательно, поддерживать общий метод обнаружения петель. Однако использование механизмов предотвращения петель является необязательным. Методы детектирования петель описаны в [MPLS-ATM] и [MPLS-LDP].

3.25. Представление меток

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

3.25.1. Специальное оборудование и программы MPLS

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

После базовой инкапсуляции MPLS будет использоваться обычная инкапсуляция в протокол канального уровня.

Спецификация базовой инкапсуляции MPLS дана в [MPLS-SHIM].

3.25.2. Коммутаторы ATM в качестве LSR

Отмечено, что процедуры пересылки MPLS похожи на те, что используются традиционными системами с «переключением по меткам» типа коммутаторов ATM. Коммутаторы ATM используют идентификатор входного порта и входящие значения VPI/VCI в качестве индекса для таблицы кросс-соединений, из которой определяется номер выходного порта и исходящие значения VPI/VCI. Следовательно, при размещении одной или множества меток непосредственно в полях, доступных традиционным коммутаторам, последние можно путем обновления программных компонент превратить в LSR. Будем называть такие устройства ATM-LSR.

Имеется три очевидных способа кодирования меток в заголовке ячеек ATM (предполагается адаптация AAL5).

Кодирование SVC.

Используется поле VPI/VCI для кодирования метки, находящейся на вершине стека. Этот способ может применяться в любых сетях. При таком кодировании каждый путь LSP реализуется в форме ATM SVC, а протоколом распространения меток служит протокол сигнализации ATM. При таком кодировании меток устройства ATM-LSR не способны выполнять операций по вталкиванию и выталкиванию меток из стека.
Кодирование SVP.

Используется поле VPI для кодирования верхней метки стека и поле VCI — для второй метки. Этот метод дает некоторые преимущества в сравнении с предыдущим, поскольку он позволяет использовать принятую в ATM коммутацию VP. В результате LSP реализуются как ATM SVP, а в качестве протокола распространения меток служит сигнальный протокол ATM.

Однако такой метод в ряде случаев не может использоваться. Если сеть ATM включает виртуальный путь через сегмент без поддержки MPLS, поле VPI может оказаться недоступным для использования в MPLS.

При использовании этого метода представления меток ATM-LSR на выходе VP может выполнять операцию выталкивания метки из стека.
Кодирование SVP Multipoint.

Используется поле VPI для кодирования верхней метки стека, часть поля VCI для кодирования второй метки (если та имеется), а оставшаяся часть VCI идентифицирует вход LSP. При использовании этого метода традиционные возможности коммутации виртуальных путей ATM могут применяться для организации VP «точка-многоточка». Ячейки из разных пакетов будут содержать разные значения VCI. Как будет показано в параграфе 3.26, это позволяет выполнять слияние меток без возникновения проблемы чередования ячеек в коммутаторах ATM с поддержкой VP «точка-многоточка», но без поддержки слияния VC.

Этот метод зависит от возможности присваивания 16-битовых значений VCI на каждом коммутаторе, чтобы одно значение VCI не назначалось двумя разными коммутаторами ATM. Если каждый коммутатор может выделить адекватное количество таких значений, можно применять поле VCI для второй метки в стеке.

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

3.25.3. Взаимодействие методов кодирования

Если <R1, R2, R3> представляет собой сегмент LSP, возможны случаи, когда R1 будет использовать при передаче пакета P маршрутизатору R2 некий метод кодирования, но R2 будет передавать пакет P маршрутизатору R3 с использованием иного варианта. В общем случае архитектура MPLS поддерживает LSP с разными вариантами кодирования меток на разных интервалах пути. Следовательно, обсуждение процедур обработки пакетов происходит в абстрактных терминах работы со стеком меток пакета. При получении помеченного пакета LSR должен декодировать пакет для определения текущего стека меток, после чего маршрутизатор должен обработать стек для определения нового стека и закодировать этот новый стек с использованием подходящего метода до передачи пакета на следующий интервал.

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

Естественно, сеть MPLS может содержать набор коммутаторов ATM, работающих в качестве LSR, а другие LSR могут работать с shim-заголовками MPLS. В таких сетях могут присутствовать LSR, имеющие одновременно интерфейсы ATM и MPLS Shim. Это является одним из примеров LSR с различными методами кодирования меток на разных интервалах. Такие LSR могут принимать закодированные в ATM метки на входном интерфейсе и преобразовывать их с использованием базовой инкапсуляции на выходном интерфейсе.

3.26. Слияние меток

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

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

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

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

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

Архитектура MPLS допускает работу маршрутизаторов как со слиянием меток, так и без слияния, Это требует организации корректного взаимодействия между LSR с поддержкой слияния меток и без таковой. Решение этого вопроса различается для сред, основанных на передаче дейтаграмм, и среды ATM. Этот вопрос требует дополнительного рассмотрения.

3.26.1. LSR, не поддерживающие слияния меток

Процедуры пересылки в MPLS очень похожи на процедуры пересылки, используемые в ATM и Frame Relay, — элемент данных поступает на узел, его метка (VPI/VCI или DLCI) отыскивается в таблице кросс-соединений, по результатам просмотра выбирается выходной порт и меняется значение метки. На практике такая же технология может использоваться для пересылки MPLS — протокол распространения меток может служить в качестве протокола сигнализации для создания таблиц кросс-соединений.

К сожалению, упомянутые технологии не всегда поддерживают слияние меток. В ATM слияние меток может приводить к перемешиванию ячеек, относящихся к разным пакетам. Если такое перемешивание происходит, процедура сборки пакета становится невозможной. Некоторые коммутаторы Frame Relay используют коммутацию ячеек на системной шине (backplane). Такие коммутаторы не поддерживают слияния меток по той же причине — ячейки, относящиеся к разным пакетам, могут перемешиваться, делая сборку пакетов невозможной.

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

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

3.26.2. Метки для LSR с поддержкой и без поддержки слияния меток

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

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

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

Применимость слияния меток к LSP с явно заданной маршрутизацией требует дальнейшего изучения.

3.26.3. Слияние меток в коммутаторах ATM

3.26.3.1. Методы предотвращения перемешивания ячеек

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

Слияние VP с использованием кодирования SVP Multipoint.

При использовании слияния VP множество виртуальных путей объединяются в один VP, но пакеты из разных источников в едином пути разделяются путем использования разных значений VCI.
Слияние VC.

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

Слияние VP обеспечивает преимущество за счет совместимости с большинством реализаций коммутаторов ATM. Это делает использование слияния VP наиболее подходящим методом для развертывания в существующих сетях. В отличие от слияния VC, слияние VP не вносит какой-либо задержки в точках слияния и не предъявляет дополнительных требований к буферам. Недостатком этого метода является необходимость поддержки пространства VCI для каждого VP. Реализация такой поддержки возможна множеством способов и для выбора конкретных путей требуется дополнительное исследование.

Противоречие между совместимостью с существующими сетями и сложностью/расширяемостью протоколов приводит к желательности поддержки в MPLS слияния VP и VC. Для реализации такой поддержки каждому коммутатору ATM, участвующему в MPLS, нужно знать, выполняют ли его непосредственные соседи слияние и какой метод (слияние VP или VC) они используют.

3.26.3.2. Взаимодействие — слияние VC, слияние VP, без слияния

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

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

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

Поэтому для поддержки всех вариантов (VP, VC и без слияния) требуется разрешить восходящим узлам запрашивать комбинацию (возможно пустую) идентификаторов VC (состоящих из VPI/VCI), а множество (возможно пустое) VP (идентифицируемых VPI), каждый из которых содержит заданное число VC (идентифицируемых набором VCI, значимых для данного VP). Узлы со слиянием VP будут запрашивать один VP с содержащимися в нем VCI для порождаемого данным узлом трафика (если таковой имеется), а также VCI для каждого VC, запрашиваемого в соответствии с приведенным выше описанием (независимо от того, является ли VC частью запрошенного VP). Узел со слиянием VC будет запрашивать только один набор VPI/VCI (поскольку он может объединять весь восходящий трафик в один VC). Узлы без поддержки слияния меток будут передавать все запросы, как описано выше, а также запрашивать один набор VPI/VCI для трафика, генерируемого данным узлом (при наличии такого трафика).

3.27. Туннели и иерархия

Иногда маршрутизатор Ru предпринимает явные действия по доставке некого пакета другому маршрутизатору Rd, хотя Ru и Rd не являются последовательными маршрутизаторами на поэтапном (hop-by-hop) пути для данного пакета и Rd не является конечным получателем. Это может осуществляться, например, путем инкапсуляции данного пакета в другой пакет сетевого уровня, в котором адресом получателя является адрес Rd. Такая инкапсуляция создает туннель от Ru к Rd. Будем называть все пакеты, которые проходят через такие туннели, туннелируемыми пакетами.

3.27.1. Туннель с поэтапной маршрутизацией

Если туннелируемый пакет следует поэтапным путем от Ru к Rd, будем называть это «туннелем с поэтапной маршрутизацией¹⁷», передающей стороной которого является Ru, а приемной — Rd.

3.27.2. Явно маршрутизируемый туннель

Если туннелируемый пакет проходит от Ru к Rd по пути, отличному от поэтапного, будем называть это «туннелем с явной маршрутизацией¹⁸», начальной точкой которого является Ru, а конечной — Rd. Например, можно передавать пакеты через туннель с явной маршрутизацией путем инкапсуляции этих пакетов в пакеты с явной маршрутизацией (source routed).

3.27.3. Туннели LSP

Можно реализовать туннель как LSP и использовать коммутацию по меткам взамен инкапсуляции на сетевом уровне для доставки пакета через такой туннель. Туннель может быть LSP <R1, …, Rn>, где R1 — передающая сторона туннеля, а Rn — приемная. Такой туннель будем называть «туннелем LSP».

Множество пакетов, передаваемых через туннель LSP, представляет класс FEC и каждый маршрутизатор LSR в туннеле должен присваивать метку данному FEC (т. е. присваивать метку туннелю). Критерии отнесения конкретных пакетов к туннелю задаются локально на передающей стороне туннеля. Для отправки пакета в туннель передающая сторона помещает метку туннеля в стек меток и передает пакет на следующий интервал туннеля.

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

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

Туннель LSP с явной маршрутизацией представляет собой туннель LSP, на основе LSP с явной маршрутизацией.

3.27.4. Иерархия — туннели 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. После этого он вталкивает в стек новую метку. Эта метка уровня 2 имеет значение, которое понятно маршрутизатору R21. В маршрутизаторах R21, R22, R23 коммутация осуществляется по меткам уровня 2. Маршрутизатор R23, который является предпоследним интервалом туннеля R2-R3, выталкивает метку из стека до пересылки пакета маршрутизатору R3. Когда R3 видит пакет P, последний имеет только метку уровня 1, показывающую, как выйти из туннеля. Поскольку R3 является предпоследним интервалом для LSP уровня 1, он выталкивает метку из стека и маршрутизатор R4 получает P без метки.

Механизм стека меток позволяет организовать туннелирование LSP с произвольным уровнем вложенности.

3.27.5. Партнерство и иерархия при распространении меток

Предположим, что пакет P проходит по LSP уровня 1 <R1, R2, R3, R4>, а участок пути от R2 до R3 является LSP уровня 2 <R2, R21, R22, R3>. С точки зрения LSP уровня 2 партнером R2 по распространению меток является R21. С точки зрения LSP уровня 1 партнерами R2 по распространению меток являются R1 и R3. Партнеры по распространению меток могут присутствовать на каждом уровне иерархии. Способы использования этой иерархии будут рассматриваться в параграфах 4.6 и 4.7. Отметим, что в приведенном примере R2 и R21 должны быть IGP-соседями, а от R2 и R3 этого не требуется.

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

Архитектура MPLS поддерживает два способа распространения меток на разных уровнях иерархии — явное и неявное партнерство.

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

Явное партнерство (Explicit Peering).

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

Примеры использования явного партнерства приведены в параграфах 4.2.1 и 4.6.
Неявное партнерство (Implicit Peering).

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

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

Примеры использования неявного партнерства приведены в параграфе 4.3.

3.28. Транспорт LDP

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

Единственным способом достижения указанных целей является использование на транспортном уровне протокола TCP, как это предложено в [MPLS-LDP] и [MPLS-BGP].

3.29. Почему используется множество LDP?

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

3.29.1. BGP и LDP

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

Например, протокол BGP распространяет такие маршруты и если узлу BGP нужно также распространять метки своим партнерам по BGP, использование протокола BGP для распространения меток (см. [MPLS-BGP]) обеспечивает множество преимуществ. В частности, это дает возможность использовать для распространения меток рефлекторы BGP, что обеспечивает существенное повышение уровня расширяемости по сравнению с использованием LDP для распространения меток между узлами BGP.

3.29.2. Метки для RSVP Flowspec

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

3.29.3. Метки для явно маршрутизируемых LSP

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

Возможны два варианта решения этой задачи:

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

Первый вариант привел к разработке протокола [MPLS-RSVP-TUNNELS], второй — [MPLS-CR-LDP].

3.30. Групповая адресация

Это тема для исследования в будущем.

4. Некоторые приложения MPLS

4.1. MPLS и трафик с поэтапной маршрутизацией

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

4.1.1. Метки для адресных префиксов

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

Отметим, что пакет P может быть отнесен к классу FEC F, а FEC может указываться префиксом X даже в тех случаях, когда адрес получателя пакета P не соответствует префиксу X.

4.1.2. Распространение меток для адресных префиксов

4.1.2.1. Партнеры по распространению меток для адресного префикса

LSR-маршрутизаторы R1 и R2 считаются партнерами по распространению меток для префикса X тогда и только тогда, когда выполняется одно из перечисленных условий.

Маршрут R1 к X является маршрутом, полученным через конкретный интерфейс от конкретного экземпляра определенного протокола IGP, и R2 является соседом R1 для данного экземпляра этого IGP.
Маршрут R1 к X является маршрутом, полученным неким экземпляром алгоритма маршрутизации A1, этот маршрут распространяется в экземпляре алгоритма маршрутизации A2 и R2 является соседом R1 для данного экземпляра A2.
R1 является приемной стороной туннеля LSP, организованного в другом LSP, R2 является передающей стороной этого туннеля, R1 и R2 участвуют в одном экземпляре IGP и находятся в одной области IGP (если IGP имеет области), а маршрут R1 к X получен от данного экземпляра IGP или распространяется маршрутизатором R1 в данный экземпляр IGP.
Маршрут R1 к X является маршрутом, полученным по протоколу BGP, и R2 — BGP-партнер R1.

В общем случае приведенные правила гарантируют, что при распространении маршрута к некому адресному префиксу по протоколу IGP партнеры по распространению меток для этого префикса являются соседями IGP. Если маршрут к некому адресному префиксу передаются по протоколу BGP, партнеры по распространению меток для данного префикса являются партнерами BGP. В других случаях туннелирования LSP конечные точки туннеля являются партнерами по распространению меток.

4.1.2.2. Распространение меток

Чтобы использовать MPLS для пересылки пакетов поэтапным маршрутом, соответствующим произвольному адресному префиксу, маршрутизатор LSR должен:

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

Существует также одно обстоятельство, когда LSR должен распространять информацию о связывании меток для адресного префикса, даже если этот LSR не связывал данную метку с этим префиксом:
если R1 использует BGP для распространения маршрута к X, называя некий другой LSR R2 следующим интервалом (BGP Next Hop) для X, и если R1 знает, что R2 выделил метку L для префикса X, тогда R1 должен распространять информацию о связывании L и X всем партнерам BGP, которым он передает данный маршрут.

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

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

4.1.3. Использование поэтапного пути в качестве LSP

Если поэтапный путь, которому должен следовать пакет P имеет вид <R1, …, Rn>, то <R1, …, Rn> может быть LSP при выполнении двух условий.

Существует такой префикс X, что для всех i, 1<=i<n, X имеет максимальное соответствие с адресом получателя P в таблице маршрутизатора Ri.
Для всех 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 может помечаться как коммутируемый (Switched), пока он не достигнет маршрутизатора R2. Поскольку R2 выполняет агрегирование маршрутов, он должен выполнить алгоритм поиска лучшего соответствия, чтобы определить класс FEC для пакета P.

4.1.4. LSP Egress и LSP Proxy Egress

LSR R рассматривается, как выходной (LSP Egress) маршрутизатор для префикса X тогда и только тогда, когда выполняется любое из приведенных ниже условий.

R имеет адрес Y, такой, что X является в таблице R префиксом с максимальным соответствием адресу Y.
R содержит в таблице маршрутизации один или множество адресных префиксов Y, для которых X является начальной подстрокой Y, но в маршрутизаторе R значение «LSP previous hops¹⁹» для X не содержит префиксов Y (т. е., R является точкой деагрегирования для адресного префикса X).

LSR R1 рассматривается, как «LSP Proxy Egress» для адресного префикса X тогда и только тогда, когда выполняется одно из условий:

следующим интервалом на R1 для X будет R2, а маршрутизаторы R1 и R2 не являются партнерами по распространению меток применительно к X (возможно по той причине, что R2 не поддерживает MPLS);
R1 настроен на работу в качестве LSP Proxy Egress для X.

Определение LSP позволяет в качестве LSP Egress использовать маршрутизаторы, не поддерживающие MPLS. В этом случае предпоследним узлом LSP является Proxy Egress.

4.1.5. Неявная NULL-метка

Implicit NULL представляет собой метку специального назначения, которую LSR может связать с адресным префиксом. Если LSR Ru из своего отображения ILM определяет, что помеченный пакет P необходимо переслать маршрутизатору Rd, но Rd распространяет для соответствующего адресного префикса метку Implicit NULL, то вместо замены верхней метки в стеке Ru просто выталкивает метку из стека и пересылает пакет Rd.

LSR Rd распространяет связывание метки Implicit NULL с адресным префиксом X маршрутизатору LSR Ru только при выполнении всех перечисленных ниже условий.

Правила параграфа 4.1.2 показывают, что Rd распространяет маршрутизатору Ru привязку метки для X.
Rd знает, что Ru может поддерживать метки Implicit NULL (т. е. может выталкивать метку из стека).
Rd является LSP Egress (не Proxy Egress) для X.

Это заставляет предпоследний LSR на пути LSP выталкивать метку из стека. Это вполне приемлемо — если LSP Egress является MPLS Egress для X, то в случае невыталкивания предпоследним LSR метки из стека маршрутизатору LSP Egress потребуется найти метку, вытолкнуть метку из стека и только после этого искать метку (или адрес L3, если в стеке не осталось меток) следующего интервала. Заставляя предпоследний LSR выталкивать метку из стека, LSP Egress экономит усилия, поскольку в противном случае ему пришлось бы просматривать две метки для принятия решения о пересылке.

Однако если предпоследний LSR является коммутатором ATM, он может не иметь возможности вытолкнуть метку из стека. Следовательно, связывание метки Implicit NULL может распространяться только в направлении LSR, которые могут поддерживать такую функцию.

Если предпоследний LSR на пути LSP для адресного префикса X представляет собой LSP Proxy Egress, он просто ведет себя как в случае распространения маршрутизатором LSP Egress метки Implicit NULL для префикса X.

4.1.6. Опция Egress-Targeted Label Assignment

Возможны ситуации, когда LSP Ingress Ri знает, что пакеты нескольких классов FEC должны следовать по одному пути LSP, завершающемуся, скажем, на маршрутизаторе LSP Egress Re. В таких случаях корректная маршрутизация может быть обеспечена при использовании одной метки для всех таких классов FEC и не требуется выделять отдельную метку для каждого FEC. При выполнении обоих приведенных ниже условий:

адрес LSR Re присутствует в таблице маршрутизации, как «маршрут к хосту»;
Ri имеет возможность определить, что Re является выходом LSP для всех пакетов данного множества FEC

Ri может связать одну метку со всеми FEC из данного множества. Это называется «нацеленным на выход связыванием меток».

LSR Ri может определить, что LSR Re является LSP Egress для всех пакетов конкретного FEC несколькими способами.

Если в сети используется алгоритм маршрутизации по состоянию каналов и все узлы области поддерживают MPLS, алгоритм маршрутизации предоставляет Ri достаточный объем информации для определения маршрутизаторов, через которые пакеты данного класса FEC должны покинуть домен или область маршрутизации.
Если в сети используется протокол BGP, маршрутизатор Ri имеет возможность определить, что пакеты определенного класса FEC должны покидать сеть через некий конкретный маршрутизатор, который является следующим интервалом (BGP Next Hop) для данного FEC.
Можно использовать протокол распространения меток для передачи информации о том, какие адресные префиксы «подключены» к какому из выходных LSR. Преимущество этого метода заключается в его независимости от наличия маршрутизации по состоянию каналов.

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

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

Если конкретный маршрутизатор LSR не является LSP Egress для некого набора адресных префиксов, этому маршрутизатору следует выделять метки для адресных префиксов так же, как это делает его следующий интервал в LSP для этих префиксов. Пусть Rd является следующим интервалом LSP для Ru по отношению к префиксам X1 и X2. Если Rd выделяет одну метку для X1 и X2, Ru следует поступать так же. Если же Rd выделяет для X1 и X2 разные метки, Ru тоже следует делать так.

Предположим в качестве примера, что нужно по умолчанию выделять нацеленные на выход метки, но для префиксов, имеющих множество возможных выходов LSP (т. е. для тех префиксов, которые являются многодомными), требуются другие метки. Можно настроить все LSR на выделение по умолчанию нацеленных на выход меток, а потом настроить часть LSR на выделение других меток для многодомных адресных префиксов. Для конкретного многодомного префикса X дополнительная настройка потребуется лишь в тех маршрутизаторах, которые являются LSP Egress или LSP Proxy Egress для префикса X.

Важно отметить, что в случае, когда Ru и Rd являются смежными LSR на пути LSP для префиксов X1 и X2, пересылка будет оставаться корректной, если Ru выделяет для X1 и X2 разные метки, а Rd использует одну метку для обоих префиксов. Это лишь означает, что Rd²⁰ будет отображать разные входные метки на одну выходную метку (обычный случай).

Аналогично, если Rd выделяет разные метки для X1 и X2, а Ru выделяет для обоих одну метку, соответствующую адресу его LSP Egress или Proxy Egress, пересылка будет выполняться корректно. Ru будет просто отображать входящую метку на выделенную Rd метку для адреса LSP Egress.

4.2. MPLS и явно маршрутизируемые LSP

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

4.2.1. Явно маршрутизируемые туннели LSP

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

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

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

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

4.3. Стеки меток и неявное партнерство

Предположим, что некий LSR Re является LSP Proxy Egress для 10 адресных префиксов и каждый из этих префиксов доступен через свой интерфейс.

Можно выделить одну метку для всех 10 адресных префиксов. Тогда Re будет LSP для всех 10 префиксов. Это гарантирует, что пакеты для всех 10 префиксов будут доставляться Re. Однако Re в этом случае должен будет просматривать адреса сетевого уровня для каждого пакета, чтобы выбрать корректный интерфейс для пересылки этого пакета.

Можно для каждого интерфейса выделить свою метку. Тогда Re для 10 адресных префиксов будет играть роль LSP Proxy Egress. Это избавляет Re от необходимости просмотра адресов сетевого уровня для пересылки пакетов. Однако в результате будет использоваться значительное число меток.

Третий вариант заключается в связывании всех 10 адресных префиксов с одной меткой уровня 1 (которая также связана с адресом самого LSR) и последующем связывании каждого префикса со своей меткой уровня 2. Метки уровня 2 будут трактоваться, как атрибут привязки метки на уровне 1, который мы будем называть атрибутом стека. Мы вводим следующие правила.

Пусть LSR Ru изначально помечает пакет без метки. Если максимальное соответствие адресу получателя дает префикс X, следующим интервалом LSP для Ru и префикса X является маршрутизатор Rd и Rd распространяет для Ru привязку метки L1 к префиксу X с атрибутом стека L2, то:

1. Ru должен втолкнуть сначала L2, а потом L1 в стек меток пакета и после этого переслать пакет Rd;
2. когда Ru передает привязку метки к префиксу X своим партнерам по распространению меток, он должен включать L2, как атрибут стека;
3. всякий раз при изменении атрибута стека (возможно в результате смены на Ru следующего интервала LSP для префикса X) Ru должен распространять новый атрибут стека.

Несмотря на то, что значение метки, связанной с X, может различаться на каждом интервале LSP, значение атрибута стека устанавливается LSP Proxy Egress и передается неизменным.

Таким образом, LSP Proxy Egress для X становится неявным партнером с каждым другим LSR в области маршрутизации или домене. В этом случае явное партнерство было бы слишком громоздким, поскольку вело бы к существенному росту числа партнеров.

4.4. MPLS и маршрутизация по множеству путей

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

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

4.5. Деревья LSP в качестве элементов «точка-многоточка»

Рассмотрим пакеты P1 и P2, каждый из которых имеет адрес получателя, для которого максимальное соответствие, проходящее через некий маршрутный домен, обеспечивает префикс X. Предположим, что поэтапный путь для P1 имеет вид <R1, R2, R3>, а для пакета P2 — <R4, R2, R3>. Далее предположим, что R3 связывает метку L3 с префиксом X и распространяет эту связку маршрутизатору R2. Маршрутизатор R2 привязывает метку L2 к префиксу X и распространяет эту привязку обоим маршрутизаторам R1 и R4. Когда R2 получает пакет P1, входящей меткой является L2. Маршрутизатор R2 будет переписывать L2 на L3 и передавать пакет P1 маршрутизатору R3. Когда R2 получает пакет P2, входящей меткой также будет L2. Маршрутизатор R2 снова заменит L2 на L3 и отправит пакет P2 маршрутизатору R3.

Отметим, что при прохождении пакетов P1 и P2 от R2 к R3, они содержат одинаковые метки и с точки зрения MPLS являются неразличимыми. Таким образом, вместо того, чтобы говорить о двух разных LSP — <R1, R2, R3> и <R4, R2, R3>, мы будем говорить об одном дереве LSP (Multipoint-to-Point LSP Tree), которое обозначим <{R1, R4}, R2, R3>.

Это создает сложности при использовании традиционных коммутаторов ATM в качестве LSR. Поскольку такие коммутаторы не поддерживают многоточечных соединений, требуются процедуры, обеспечивающие реализацию каждого LSP, как VC «точка-точка». Однако при использовании коммутаторов ATM, поддерживающих VC «точка-многоточка», LSP более эффективно реализуются как VC «точка-многоточка». Кроме того, при возможности использования SVP Multipoint Encoding (см. параграф 3.25.2) LSP можно реализовать как SVP «точка-многоточка».

4.6. Туннели LSP между граничными маршрутизаторами BGP

Рассмотрим автономную систему A, которая передает транзитный трафик между другими автономными системами. AS²¹ A будет иметь множество граничных маршрутизаторов BGP, соединенных между собой по протоколу BGP для распространения маршрутов BGP. Во многих таких случаях желательно избежать распространения маршрутов BGP тем устройствам, которые не относятся к числу граничных маршрутизаторов BGP. Если такое распространение удается предотвратить, нагрузка по распространению маршрутов на этих маршрутизаторах существенно снизится. Однако требуется принять ряд мер по обеспечению гарантий доставки транзитного трафика между граничными маршрутизаторами через внутренние маршрутизаторы.

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

Каждый граничный маршрутизатор BGP распространяет всем остальным граничным маршрутизаторам BGP в своей AS метку для каждого адресного префикса, который он распространяет этому маршрутизатору по BGP.
IGP²² для AS поддерживают хост-маршруты к каждому граничному маршрутизатору BGP. Каждый внутренний маршрутизатор распространяет свои метки для этих хост-маршрутов каждому из своих соседей по IGP.
Предположим, что:

1. граничный маршрутизатор BGP B1 получает непомеченный пакет P;
2. адресный префикс X в таблице маршрутизации B1 обеспечивает максимальное соответствие адресу получателя P;
3. маршрут к X является маршрутом BGP;
4. следующим интервалом BGP для префикса X является B2;
5. B2 связывает метку L1 с префиксом X и распространяет информацию об этом маршрутизатору B1;
6. следующим интервалом IGP для адреса маршрутизатора B2 является маршрутизатор I1;
7. адрес B2 имеется в таблицах внутренней маршрутизации B1 и I1, как маршрут к хосту;
8. I1 связывает метку L2 с адресом B2 и распространяет информацию об этом маршрутизатору B1.

Тогда перед отправкой пакета P маршрутизатору I1 граничный маршрутизатор B1 должен создать стек меток для P, втолкнуть в него метку L1, а затем — метку L2.

Предположим, что граничный маршрутизатор BGP B1 получает помеченный пакет P с верхней меткой стека, соответствующей адресному префиксу X, к которому ведет маршрут BGP, и условия 3b, 3c, 3d и 3e выполнены. Тогда перед отправкой пакета P маршрутизатору I1 граничный маршрутизатор B1 должен заменить верхнюю метку стека на L1, а потом поместить в стек метку L2.

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

Эти процедуры по сути дела создают поэтапно маршрутизируемый туннель LSP между граничными устройствами BGP.

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

Иногда можно создать поэтапно маршрутизируемые туннели LSP между граничными маршрутизаторами BGP, относящимися к разным AS. Предположим, что B1 и B2 находятся в AS1, а B3 является EBGP-соседом B2, расположенным в AS2. Также предположим, что B2 и B3 относятся к некой сети, которая является общей для обеих AS (демилитаризованная зона). В этом случае туннель LSP может быть организован напрямую между B1 и B3 как показано ниже.

B3 распространяет маршруты B2 (используя EBGP), возможно связывая метки с адресными префиксами.
B2 распространяет далее эти маршруты B1 (с помощью IBGP), показывая, что следующим интервалом BGP для каждого из таких маршрутов является B3. Если B3 связал с адресными префиксами метки, B2 будет передавать этим метки B1 без изменения.
IGP автономной системы AS1 имеет хост-маршрут для B3.

4.7. Другие применения туннелей LSP с поэтапной маршрутизацией

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

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

4.8. MPLS и групповая адресация

Групповая адресация реализуется путем построения multicast-деревьев. Дерево, вдоль которого должен передаваться конкретный пакет с групповым адресом, зависит в общем случае от адресов отправителя и получателя в пакете. Когда тот или иной LSR является узлом некого multicast-дерева, он связывает с этим деревом метку. Информация о такой привязке распространяется родительскому узлу multicast-дерева (если узел подключен к ЛВС и в этой ЛВС есть другие узлы такого типа, информация о привязке распространяется также этим узлам, что позволяет родителю обойтись одной меткой при пересылке пакетов с групповой адресацией всем дочерним объектам в ЛВС).

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

5. Процедуры поэтапного распространения меток

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

5.1. Процедуры анонсирования и использования меток

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

Нисходящий LSR должен выполнять процедуры:

Distribution (распространение);
Withdrawal (отзыв).

Восходящий LSR должен выполнять процедуры:

Request (запрос);
NotAvailable (недоступно);
Release (освобождение);
labelUse (использование метки).

Архитектура MPLS поддерживает несколько вариантов каждой процедуры. Однако архитектура не поддерживает всех возможных комбинаций вариантов. Набор поддерживаемых комбинаций будет описан в параграфе 5.2 при обсуждении вопросов взаимодействия.

5.1.1. Нисходящий LSR — процедура Distribution

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

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

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

5.1.1.1. PushUnconditional — безусловное выталкивание

Предположим, что Rd является LSR и выполняются условия:

X является адресным префиксом в таблице маршрутизации Rd;
Ru является партнером Rd по распространению меток применительно к префиксу X.

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

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

5.1.1.2. PushConditional — условное выталкивание

Предположим, что Rd является LSR и выполняются условия:

X является адресным префиксом в таблице маршрутизации Rd;
Ru является партнером Rd по распространению меток применительно к префиксу X;
Rd является LSP Egress или LSP Proxy Egress для префикса X или следующим интервалом сетевого уровня для этого префикса в Rd является маршрутизатор Rn, отличный от Ru, связавший метку с префиксом X и распространяющий информацию об этом маршрутизатору Rd.

При выполнении всех условий Rd следует связать метку с X и распространить информацию об этом Ru.

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

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

5.1.1.3. PulledUnconditional — безусловное втягивание

Предположим, что Rd является LSR и выполняются условия:

X является адресным префиксом в таблице маршрутизации Rd;
Ru является партнером Rd по распространению меток применительно к префиксу X;
Ru явно запрашивает у Rd привязку метки к префиксу X и распространение информации об этом Ru.

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

Если Rd уже распространил информацию о метке для префикса X маршрутизатору Ru и получает новый запрос от Ru для привязки метки к префиксу X, он будет привязывать вторую метку и распространять информацию об этом Ru. Первая метка остается действующей.

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

5.1.1.4. PulledConditional — условное втягивание

Предположим, что Rd является LSR и выполняются условия:

X является адресным префиксом в таблице маршрутизации Rd;
Ru является партнером Rd по распространению меток применительно к префиксу X;
Ru явно запрашивает у Rd привязку метки к префиксу X и распространение информации об этом Ru;
Rd является LSP Egress или LSP Proxy Egress для префикса X или следующим интервалом сетевого уровня для этого префикса в Rd является маршрутизатор Rn, отличный от Ru, связавший метку с префиксом X и распространяющий информацию об этом маршрутизатору Rd.

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

Если единственным не выполненным условием является то, что Rn еще не предоставил метку Rd, маршрутизатор Rd должен задержать ответ Ru до получения нужной информации от Rn.

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

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

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

5.1.2. Восходящий LSR — процедура Request

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

5.1.2.1. RequestNever — никогда не запрашивать

Запросы не выполняются никогда. Это полезно в тех случаях, когда нисходящий LSR использует процедуру PushConditional или PushUnconditional, но бесполезно при использовании нисходящим LSR процедуры PulledUnconditional или PulledConditional.

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

5.1.2.2. RequestWhenNeeded — запрашивать при необходимости

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

Эта процедура применяется LSR в случаях использования консервативного режима удержания меток.

5.1.2.3. RequestOnRequest — запрашивать по запросу

Запрос выдается в ответ на получение запроса в дополнение к запросам при возникновении необходимости (как описано в параграфе 5.1.2.2). Если Ru не может быть входом LSP, он может выдавать запрос только при получении запроса от восходящего узла.

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

Эта процедура используется LSR которые выполняют нисходящее распространение по запросу, но не поддерживают слияния меток (например, ATM-LSR, не поддерживающие слияния VC).

5.1.3. Восходящий LSR — процедура NotAvailable

Если Ru и Rd являются восходящим и нисходящим партнерами по распространению меток для префикса X, соответственно, Rd является следующим интервалом L3 маршрутизатора Ru для префикса X и Ru запрашивает привязку метки для X у Rd, но Rd отвечает о невозможности привязки в данный момент, поскольку у него нет следующего интервала для X, процедура NotAvailable определяет действия Ru. Существует два возможных варианта поведения Ru.

5.1.3.1. RequestRetry — повторять запрос

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

5.1.3.2. RequestNoRetry — не повторять запрос

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

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

5.1.4. Восходящий LSR — процедура Release

Предположим, что Rd является LSR, связавшим метку с префиксом X и распространяющим эту привязку LSR Ru. Если Rd не является следующим интервалом L3 маршрутизатора Ru для префикса X или перестал быть таковым, Ru не будет использовать эту метку. Процедура Release задает действия Ru в таких ситуациях. Возможны два варианта поведения Ru.

5.1.4.1. ReleaseOnChange — освобождать при изменении

Ru следует освободить метку и информировать об этом Rd. Эта процедура используется для реализации консервативного режима удержания меток.

5.1.4.2. NoReleaseOnChange — не освобождать при изменении

Ru следует поддерживать привязку, что позволит незамедлительно начать использование метки, если Rd позднее станет следующим интервалом L3 для префикса X. Эта процедура используется для реализации либерального режима удержания меток.

5.1.5. Восходящий LSR — процедура labelUse

Предположим, что Ru — LSR, который получает привязку метки L для префикса X от LSR Rd и Ru является восходящим по отношению к Rd для префикса X, а фактически Rd является следующим интервалом L3 маршрутизатора Ru для префикса X.

Ru будет использовать привязку метки, если Rd является следующим интервалом L3 маршрутизатора Ru для префикса X. Если на момент получения привязки Ru маршрутизатор Rd не является следующим интервалом L3 маршрутизатора Ru для X, Ru не использует полученную привязку. Однако Ru может начать использование привязки позднее, когда Rd станет следующим интервалом L3 маршрутизатора Ru для префикса X.

Процедура labelUse определяет использование маршрутизатором Ru привязки, полученной от Rd.

Существует два варианта поведения Ru.

5.1.5.1. UseImmediate — использовать сразу

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

5.1.5.2. UseIfLoopNotDetected — использовать при отсутствии петель

Эта процедура совпадает с UseImmediate, пока Ru не видит петли в LSP. При обнаружении петли Ru прекратит использование метки L для пересылки пакетов маршрутизатору Rd.

Эта процедура применяется при использовании детектирования петель.

Использование будет продолжаться до изменения следующего интервала для X или прекращения петли.

5.1.6. Нисходящий LSR — процедура Withdraw

Для этого случая имеется единственная процедура.

Когда LSR Rd решает разорвать связь между меткой L и адресным префиксом X, информация об этом должна быть распространена всем LSR, которым отправлена информация о привязке.

Требуется, чтобы информация о разрыве привязки L к префиксу X распространялась Rd маршрутизатору Ru до того, как Rd распространит Ru новую привязку метки L к любому другому префиксу Y (X != Y). Если Ru получит новую привязку L к Y до того, как узнает о разрыве связи между L и X и от Ru к Rd будут в течение некоторого времени идти пакеты, соответствующие префиксам X и Y, маршрутизатор Ru будет помечать этой меткой как пакеты, соответствующие X, так и пакеты, соответствующие Y.

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

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

5.2. Схемы MPLS — поддерживаемые комбинации процедур

Рассмотрим два LSR — Ru и Rd, которые являются партнерами по распространению меток применительно к некому набору адресных префиксов. Ru является восходящим партнером, Rd — нисходящим.

Схема MPLS, управляющая взаимодействием Ru и Rd, может описана в форме квинтета процедур — <Distribution, Request, NotAvailable, Release, labelUse> (поскольку процедура Withdraw имеет единственный вариант, она не включена в квинтет). Символ * в квинтете является заменителем, вместо которого может быть подставлена любая процедура соответствующей категории, обозначение N/A говорит о том, что процедура соответствующей категории не требуется.

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

5.2.1. Схемы для LSR с поддержкой слияния меток

Если Ru и Rd являются партнерами по распространению меток и оба поддерживают слияние меток, должна использоваться одна из приведенных здесь схем.

<PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate>

Это нисходящее распространение незапрошенных меток с независимым управлением в либеральном режиме удержания без детектирования петель.
<PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>

Это нисходящее распространение незапрошенных меток с независимым управлением в либеральном режиме удержания с детектированием петель.
<PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange, *>

Это нисходящее распространение незапрошенных меток с упорядоченным (со стороны выхода) управлением в консервативном режиме удержания. Детектирование петель является необязательным.
<PushConditional, RequestNever, N/A, NoReleaseOnChange, *>

Это нисходящее распространение незапрошенных меток с упорядоченным (со стороны выхода) управлением в либеральном режиме удержания. Детектирование петель является необязательным.
<PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>

Это нисходящее распространение меток по запросам с упорядоченным (инициируется со стороны входа) управлением в консервативном режиме удержания. Детектирование петель является необязательным.
<PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate>

Это нисходящее распространение меток по запросам с независимым управлением в консервативном режиме удержания без детектирования петель.
<PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected>

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

5.2.2. Схемы для LSR, не поддерживающих слияния меток

Предположим, что R1, R2, R3 и R4 — коммутаторы ATM, которые не поддерживают слияния меток, но используются в качестве LSR. Предположим также, что поэтапный путь L3 для адресного префикса X имеет вид <R1, R2, R3, R4> и пакеты, адресованные X, могут войти в сеть только через эти LSR. Поскольку здесь нет поддержки режимов «точка-многоточка», LSP должны быть реализованы, как VC «точка-точка», что требует наличия трех таких VC для префикса X — <R1, R2, R3, R4>, <R2, R3, R4> и <R3, R4>.

Следовательно, если R1 и R2 являются партнерами MPLS и оба являются LSR, реализованными на стандартном коммутационном оборудовании ATM (т. е., без подавления перемешивания ячеек) или не способны поддерживать слияние меток по иной причине, схема MPLS, используемая при взаимодействии между R1 и R2, должна быть одной из перечисленных ниже.

<PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>

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

Использование процедуры RequestOnRequest будет заставлять R4 распространять три метки для префикса X маршрутизатору R3, который будет распространять 2 метки для X маршрутизатору R2, а R2 будет распространять одну метку для X маршрутизатору R1.
<PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate>

Это нисходящее распространение меток по запросам с независимым управлением в консервативном режиме удержания без детектирования петель.
<PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>

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

5.2.3. Вопросы взаимодействия

Легко видеть, что некоторые из квинтетов не дают жизнеспособных схем MPLS. Например,

<PulledUnconditional, RequestNever, *, *, *>

<PulledConditional, RequestNever, *, *, *>

В этих вариантах нисходящий LSR Rd распространяет привязки меток восходящему LSR Ru только по запросам последнего, но Ru никогда не делает таких запросов. Очевидно, что такая схема нежизнеспособна, поскольку она не обеспечивает подобающего распространения привязок меток.
<*, RequestNever, *, *, ReleaseOnChange>

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

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

Каждая сторона должна указать, поддерживает ли она слияние меток.
Если Rd не поддерживает слияния меток, он должен выбрать процедуру PulledUnconditional или PulledConditional. При выборе Rd процедуры PulledConditional, Ru будет вынужден использовать процедуру RequestRetry.

В случаях, когда нисходящий LSR не поддерживает слияния меток, его предпочтения имеют более высокий приоритет при выборе схемы MPLS.
Если Ru не поддерживает слияния меток, а Rd поддерживает, маршрутизатор Ru должен выбрать процедуру RequestRetry или RequestNoRetry. Это заставляет Rd использовать процедуру PulledConditional или PulledUnConditional, соответственно.

Т. е. если только один из LSR не поддерживает слияния меток, его предпочтения имеют более высокий приоритет при выборе схемы MPLS.
Если Ru и Rd поддерживают слияние меток, выбор между либеральным и консервативным режимом удержания меток остается за маршрутизатором Ru, т. е. Ru выбирает использование процедуры RequestWhenNeeded/ReleaseOnChange (консервативный режим) или RequestNever/NoReleaseOnChange (либеральный режим). Однако выбор между push и pull, а также между conditional и unconditional остается за Rd. Если Ru выбирает либеральный режим удержания меток, Rd может выбрать процедуру PushUnconditional или PushConditional. Если Ru выбирает консервативный режим удержания меток, Rd может выбрать процедуру PushConditional, PulledConditional или PulledUnconditional.

Приведенные варианты выбора совместно определяют используемую схему MPLS.

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

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

Смысл метки MPLS определяется соглашением между LSR, помещающим метку в стек (label writer), и LSR, который интерпретирует эту метку (label reader). Если помеченный пакет получен из источника, к которому нет доверия, или некая входящая метка принята от LSR, которому метки не распространяются, использование такой метки может приводить к утрате легитимности маршрутизации.

7. Интеллектуальная собственность

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

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

Eric C. Rosen

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA, 01824

EMail: erosen@cisco.com

Arun Viswanathan

Force10 Networks, Inc.

1440 McCarthy Blvd.

Milpitas, CA 95035-7438

EMail: arun@force10networks.com

Ross Callon

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, CA 94089 USA

EMail: rcallon@juniper.net

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

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

nmalykh@protokols.ru

9. Литература

[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, «MPLS using LDP and ATM VC Switching», RFC 3035, January 2001.

[MPLS-BGP] «Carrying Label Information in BGP-4», Rekhter, Rosen, Work in Progress²³.

[MPLS-CR-LDP] «Constraint-Based LSP Setup using LDP», Jamoussi, Editor, Work in Progress²⁴.

[MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, «Use of Label Switching on Frame Relay Networks Specification», RFC 3034, January 2001.

[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, «LDP Specification», RFC 3036 ²⁵, January 2001.

[MPLS-RSVP-TUNNELS] «Extensions to RSVP for LSP Tunnels», Awduche, Berger, Gan, Li, Swallow, Srinvasan, Work in Progress²⁶.

[MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G., Farinacci, D. and A. Conta, «MPLS Label Stack Encoding», RFC 3032, January 2001.

[MPLS-TRFENG] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M. and J. McManus, «Requirements for Traffic Engineering Over MPLS», RFC 2702, September 1999.

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

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

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

1Multiprotocol Label Switching.

2Forwarding Equivalence Class

3Traffic Engineering.

4Label Switching Router.

5Upstream LSR.

6Downstream LSR.

7Метка, помещенная в стек первой, извлекается из него последней и наоборот.

8В стеке. Прим. перев.

9В оригинале ошибочно указано «label» вместо «FEC». См. http://www.rfc-editor.org/errata_search.php?eid=2992

10Вход пути

11Выход пути.

12Поскольку данные проходят через это дерево в направлении корня, будем называть это дерево «множество в один» — multipoint-to-point tree.

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

14В оригинале ошибочно указано (c). См. http://www.rfc-editor.org/errata_search.php?eid=3171

15Hop by hop routed LSP.

16Time To Live.

17Hop-by-Hop Routed Tunnel.

18Explicitly Routed Tunnel.

19Предыдущие интервалы LSP.

20В оригинале ошибочно указано R1. См. http://www.rfc-editor.org/errata_search.php?rfc=3031. Прим. перев.

21Autonomous System.

22Протокол внутренней маршрутизации.

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

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

25Этот документ устарел и заменен RFC 5036. Прим. перев.

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

Рубрика: RFC | Оставить комментарий

RFC 3022 Traditional IP Network Address Translator (Traditional NAT)

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

Network Working Group                                   P. Srisuresh
Request for Comments: 3022                          Jasmine Networks
Obsoletes: 1631                                           K. Egevang
Category: Informational                            Intel Corporation
                                                        January 2001

Традиционная трансляция сетевых адресов IP (NAT)

Traditional IP Network Address Translator (Traditional NAT)

PDF

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

Этот документ содержит информацию для сообщества Internet и не определяет каких-либо стандартов. Документ может распространяться свободно.

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

Предисловие

Описанная в этом документе работа NAT расширяет возможности трансляции адресов, описанные в RFC 1631 и включает новый тип сетевых адресов, а также трансляцию портов TCP/UDP. Кроме того, документ вносит исправления в алгоритм корректировки контрольных сумм, опубликованный в RFC 1631, а также включает обсуждение работы NAT и возможные ограничения.

Аннотация

Базовая трансляция сетевых адресов или Basic NAT¹ представляет собой метод отображения адресов IP из одной группы в другую, прозрачного для конечных пользователей. Трансляция сетевых адресов и номеров портов или NAPT² — метод, с помощью которого множество сетевых адресов и соответствующих портов TCP/UDP (Transmission Control Protocol/User Datagram Protocol) преобразуется в один сетевой адрес и номер порта TCP/UDP. Оба метода вместе называют традиционной трансляцией адресов. NAT обеспечивает механизм подключения областей с приватными адресами к внешним областям, в которых используются уникальные в глобальном масштабе зарегистрированные адреса.

1. Введение

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

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

Базовая трансляция во многих случаях (за исключением ситуаций, указанных в [NAT-TERM] и главе 6 данного документа) может обеспечивать доступ пользователей из частной сети во внешние сети, а также доступ извне к некоторым локальным хостам. Организациям, в которых сеть используется для решения внутренних задач, а доступ во внешние сети требуется нерегулярно, такая схема будет весьма удобна.

Многие пользователи SOHO³ и удаленные сотрудники используют в своих офисах множество узлов с приложениями TCP/UDP, но имеют лишь один адрес IP, выделенный их маршрутизатору провайдером для доступа во внешнюю сеть. Эта постоянно растущая группа пользователей с удаленным доступом может применить метод трансляции NAPT, который позволяет множеству узлов из локальной сети одновременно получить доступ во внешние сети с использованием единственного адреса IP, выделенного для их маршрутизатора.

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

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

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

Определения терминов «Address Realm⁵», «Transparent Routing⁶», «TU Port» (порт TU⁷), «ALG» и др., используемых в данном документе, можно найти в [NAT-TERM].

2. Обзор традиционной трансляции NAT

Описанная в этом документе работа системы трансляции адресов относится к Traditional NAT. Существуют и другие варианты NAT, которые в этом документе не рассматриваются. Традиционная трансляция обеспечивает в большинстве случаев внутренним хостам частных сетей прозрачный доступ во внешнюю сеть. При традиционной трансляции сессии являются односторонними⁸ и направлены наружу из частной сети. Организация сессий в противоположном направлении может быть разрешена в качестве исключения с использованием статического отображения адресов для избранных хостов. Традиционная трансляция имеет два варианта — Basic NAT и NAPT. Базовая трансляция обеспечивает преобразование только для адресов, а NAPT позволяет транслировать адреса IP и идентификаторы транспортного уровня (такие, как номера портов TCP/UDP или ICMP query ID).

            \ | /                      .                                          /
+--------------------------+  WAN      .          +-----------------------------+/
|Региональный маршрутизатор|----------------------|Оконечный маршрутизатор с NAT|---
+--------------------------+           .          +-----------------------------+\
                                       .                       |                  \
                                       .                       | ЛВС
                                       .                ---------------
                             Оконечный маршрутизатор

Рисунок 1: Традиционная конфигурация NAT

Если явно не указано иное, термины NAT и трансляция адресов в этом документе относятся к традиционной трансляции, а именно NAPT и Basic NAT. Для выполнения трансляции могут использоваться только оконечные граничные маршрутизаторы, как показано на рисунке 1.

2.1 Обзор базовой трансляции

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

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

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

В примере, показанном на рисунке 2, оконечные домены A и B используют блок приватных адресов класса A 10.0.0.0/8 [RFC 1918]. Системе NAT домена A выделен блок адресов класса C 198.76.29.0/24, а в домене B — блок 198.76.28.0/24. Адреса блоков класса C являются уникальными в глобальном масштабе и другие устройства NAT не могут их использовать.

Когда хост домена A с адресом 10.33.96.5 хочет передать пакет хосту домена B с адресом 10.81.13.22, он использует в качестве адреса получателя уникальное в глобальном масштабе значение 198.76.28.4 и передает пакет своему основному маршрутизатору. Этот маршрутизатор имеет статический маршрут в сеть 198.76.0.0 и пакет пересылается в WAN-канал. Однако до того, как пакет будет передан, NAT преобразует адрес отправителя 10.33.96.5 в заголовке IP в уникальный адрес 198.76.29.7. Аналогично происходит преобразование адресов для пакетов IP, передаваемых в обратном направлении.

Отметим, что трансляция не требует внесения изменений на хостах или маршрутизаторах. Например, для хоста домена A хостом из домена B будет использоваться адрес 198.76.28.4. Трансляция адресов в большинстве случаев прозрачна для конечных хостов. Естественно, что приведенный пример очень прост. Эта схема трансляции имеет множество спорных моментов, которые требуется исследовать.

                                \ | /
                    +--------------------------+
                    |Региональный маршрутизатор|
                    +--------------------------+
                        WAN |          | WAN
                            |          |
        Stub A .............|....  ....|............ Stub B
                            |          |
           {s=198.76.29.7,^ |          | v{s=198.76.29.7,
            d=198.76.28.4}^ |          | v d=198.76.28.4}
+-----------------------------+      +-----------------------------+
|Оконечный маршрутизатор с NAT|      |Оконечный маршрутизатор с NAT|
+-----------------------------+      +-----------------------------+
                     |                        |
                     | ЛВС                ЛВС |
               -------------            -------------
                        |                  |
       {s=10.33.96.5, ^ |                  | v{s=198.76.29.7,
       d=198.76.28.4}^ +--+              +--+ v d=10.81.13.22}
                       |--|              |--|
                      /____\            /____\
                    10.33.96.5       10.81.13.22

Рисунок 2: Основы работы Basic NAT

2.2. Обзор NAPT

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

                          \ | /
                +------------------------+
                |Маршрутизатор провайдера|
                +------------------------+
                        WAN |
                            |
        Stub A .............|....
                            |
^{s=138.76.28.4,sport=1024, | v{s=138.76.29.7, sport = 23,
^ d=138.76.29.7,dport=23}   | v d=138.76.28.4, dport = 1024}
            +------------------------------+
            |Оконечный маршрутизатор с NAPT|
            +------------------------------+
                   |
                   | ЛВС
--------------------------------------------
   | ^{s=10.0.0.10,sport=3017,        | v{s=138.76.29.7, sport=23,
   | ^ d=138.76.29.7,dport=23}        | v d=10.0.0.10, dport=3017}
   |                                  |
 +--+      +--+                     +--+
 |--|      |--|                     |--|
/____\    /____\                   /____\
10.0.0.1 10.0.0.2      .....     10.0.0.10

Рисунок 3: Работа NAPT

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

В показанном на рисунке 3 примере внутри оконечной сети A используется блок адресов класса A 10.0.0.0/8. WAN-интерфейсу граничного маршрутизатора сети провайдером присвоен IP-адрес 138.76.28.4.

Когда хост сети A с адресом 10.0.0.10 передает пакет telnet хосту 138.76.29.7, он указывает публичный адрес получателя 138.76.29.7 и отправляет пакет основному маршрутизатору. Маршрутизатор имеет статический маршрут в сеть 138.76.0.0/16 и пересылает пакет в канал WAN. Однако до пересылки пакета NAPT транслирует адрес отправителя 10.0.0.10 и номер порта TCP 3017 в заголовках IP и TCP, используя публичный адрес 138.76.28.4 и уникальное значение номера порта TCP (скажем, 1024). Для обратных пакетов происходит похожее преобразование адреса и номера порта TCP в IP-адрес локального хоста и номер целевого порта TCP. Отметим снова, что не требуется вносить какие-либо изменения на хостах или маршрутизаторах. Трансляция совершенно прозрачна.

В описанном варианте поддерживаются только сеансы TCP/UDP, организованные из локальной сети. Однако для некоторых служб (таких, как DNS) требуется обеспечить доступ извне. Могут существовать также иные службы, к которым организация хочет предоставить внешний доступ. Можно статически настроить на граничном маршрутизаторе отображение общеизвестных номеров портов TU [RFC 1700] на адреса конкретных хостов локальной сети.

В дополнение к сессиям TCP/UDP маршрутизатор NAPT может также обеспечивать мониторинг сообщений ICMP, за исключением типа REDIRECT. Запросы ICMP транслируются подобно пакетам TCP/UDP и поле идентификатора в заголовке сообщения ICMP будет уникально отображаться в идентификатор запроса для зарегистрированного адреса IP. Поле идентификатора в заголовках сообщений ICMP устанавливается отправителем и возвращается неизменным в отклике на запрос. Следовательно, пара (локальный адрес IP, локальный идентификатор ICMP) отображается в пару (публичный адрес IP, выделенное значение идентификатора ICMP) маршрутизатором NAPT и обеспечивает уникальную идентификацию всех типов сообщений ICMP от любого из локальных хостов. Изменение сообщений ICMP об ошибках рассматриваемое ниже, включает модификацию данных ICMP, а также заголовков IP и ICMP.

В конфигурациях NAPT, где зарегистрированный адрес IP совпадает с IP-адресом WAN-интерфейса оконечного маршрутизатора, этот маршрутизатор должен отличать сессии TCP, UDP или ICMP, организованные им самим от сессий, организованных узлами внутренней сети. Все входящие сессии (включая TCP, UDP и ICMP) предполагаются адресованными маршрутизатору NAT, как конечной точке, если целевой порт не отображен статически на адрес того или иного узла локальной сети.

Сессии, отличные от TCP, UDP и ICMP, просто не поддерживаются для локальных узлов, обслуживаемых маршрутизатором NAPT.

3.0. Фазы трансляции для сеанса

Фазы традиционной трансляции NAT совпадают с описанными в [NAT-TERM]. В следующих параграфах рассматриваются специфические аспекты традиционной трансляции.

3.1. Привязка адреса

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

В случае NAPT множество приватных адресов отображается на один публичный адрес и привязка будет осуществляться между парами (приватный адрес, приватный порт TU) и парами (публичный адрес, выделенный порт TU). Как и для Basic NAT эта привязка определяется при организации первой исходящей сессии для пары (приватный адрес, приватный порт TU) со стороны хоста локальной сети. Хотя это и не является общепринятым, возможна организация приложением на хосте локальной сети множества одновременных сессий для одной пары (приватный адрес, приватный порт TU). В таких случаях для этой пары (приватный адрес, приватный порт TU) может использоваться одна привязка для всех пакетов, относящихся к сессиям для данной пары с этого хоста.

3.2. Просмотр и трансляция адреса

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

3.3. Удаление привязки адреса

Когда последняя сессия для адреса или пары (адрес, порт TU) завершается, привязка может быть ликвидирована.

4.0. Преобразование пакетов

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

4.1. Манипуляции с заголовками IP, TCP, UDP и ICMP

В модели Basic NAT требуется изменять заголовок IP в каждом пакете. Модификация включает адрес IP (адрес отправителя для исходящих пакетов и адрес получателя для входящих) и контрольную сумму IP.

Для сессий TCP ([TCP]) и UDP ([UDP]) также требуется изменять контрольную сумму в заголовках TCP/UDP. Это связано с тем, что контрольная сумма TCP/UDP учитывает псевдозаголовок, содержащий IP-адреса отправителя и получателя. Исключением являются случаи когда контрольная сумма заголовка UDP имеет значение 0 — в этом случае поле контрольной суммы не меняется. Для пакетов ICMP Query ([ICMP]) не требуется вносить изменений в заголовок ICMP, поскольку контрольная сумма в заголовке ICMP не учитывает адресов IP.

В модели NAPT изменение заголовка IP похоже на случай Basic NAT. Для сессий TCP/UDP изменяется также номер порта TU (порт отправителя для исходящих пакетов и порт получателя для входящих) в заголовке TCP/UDP. Заголовок ICMP в пакетах ICMP также требуется изменять для корректировки значения идентификатора запроса и контрольной суммы заголовка ICMP. Идентификатор запроса хоста внутренней сети в исходящих пакетах должен заменяться на присвоенный при трансляции идентификатор, а для входящих откликов должно выполняться обратное преобразование. Контрольная сумма заголовка ICMP должна корректироваться с учетом трансляции Query ID.

4.2. Корректировка контрольной суммы

Преобразования NAT выполняются для каждого пакета и могут приводить к значительным расходам вычислительных ресурсов при необходимости корректировки одной или нескольких контрольных сумм в дополнение к простой замене полей. К счастью существует приведенный ниже алгоритм, делающий корректировку контрольных сумм заголовков IP, TCP, UDP и ICMP очень простой и эффективной. Поскольку все эти заголовки используют арифметику дополнения до 1, достаточно рассчитать разность между адресами до и после трансляции и добавить полученное значение к контрольной сумме. Приведенный ниже алгоритм применим только для случаев четного смещения (т. е., поле optr должно начинаться с четного октета от начала заголовка) и четной длины (т. е., поля olen и nlen должны иметь четные значения). Ниже приведен вариант реализации алгоритма на языке C.

void checksumadjust(unsigned char *chksum, unsigned char *optr, int olen, unsigned char *nptr, int nlen)
/* Допущения: unsigned char имеет размер 8 битов, long - 32 бита.
- chksum указывает контрольную сумму пакета
- optr указывает старые данные в пакете
- nptr указывает новые данные в пакете
*/
{
   long x, old, new;
   x=chksum[0]*256+chksum[1];
   x=~x & 0xFFFF;
   while (olen)
   {
      old=optr[0]*256+optr[1]; optr+=2;
      x-=old & 0xffff;
      if (x<=0) { x--; x&=0xffff; }
      olen-=2;
   }
   while (nlen)
   {
      new=nptr[0]*256+nptr[1]; nptr+=2;
      x+=new & 0xffff;
      if (x & 0x10000) { x++; x&=0xffff; }
      nlen-=2;
   }
   x=~x & 0xFFFF;
   chksum[0]=x/256; chksum[1]=x & 0xff;
}

4.3. Изменение сообщений ICMP об ошибках

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

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

Для случая NAPT, если пакет IP, вложенный в сообщение ICMP, является пакетом TCP, UDP или ICMP Query, потребуется также изменить номер порта TU в заголовке TCP/UDP или поле Query Identifier в заголовке ICMP Query.

В заключение нужно изменить заголовок IP пакета, содержащего сообщение ICMP.

4.4. Поддержка FTP

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

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

Для случая Basic NAT преобразование данных FTP ограничивается трансляцией между приватными и публичными адресами (кодируются пооктетно в ASCII). Для случая NAPT требуется также трансляция октетов, задающих номер порта TCP (в коде ASCII) и следующих за октетами адреса.

4.5 Поддержка DNS

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

4.6. Обработка опций IP

Дейтаграммы IP с любыми из опций Record Route, Strict Source Route и Loose Source Route будут включать запись использования адресов IP промежуточных маршрутизаторов. Промежуточный маршрутизатор NAT может отказаться от поддержки таких опций или оставлять нетранслированные адреса при обработке опций. Результатом сохранения нетранслированных адресов в опциях будет раскрытие внутренних адресов сети в пакетах с опциями заданной отправителем маршрутизации. Это не создает, по сути, дополнительного риска, поскольку предполагается, что каждый маршрутизатор просматривается только маршрутизатором следующего интервала (next hop router).

5. Разное

5.1. Деление адресов на приватные и публичные

Для описанной в документе работы NAT необходимо разделить пространство адресов IP на две части — приватные адреса, используемые внутри оконечного домена, и публичные адреса с глобальной доступностью. Любой конкретный адрес должен относится к числу приватных или публичных. Области приватных и публичных адресов не перекрываются.

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

5.2. Рекомендации по выбору приватных адресов

[RFC 1918] содержит рекомендации по выделению адресного пространства для частных сетей. Агентство IANA¹⁰ выделило для этих целей 3 блока адресов IP — 10.0.0.0/8, 172.16.0.0/12, и 192.168.0.0/16. В нотации без использования CIDR первый блок представляет собой одну сеть класса A, второй – 16 последовательных сетей класса B, а третий – 256 последовательных сетей класса C.

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

5.3. Маршрутизация через NAT

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

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

5.4. Переключение с Basic NAT на NAPT

В Basic NAT, когда число узлов внутренней сети превышает число доступных для трансляции публичных адресов (например, внутренняя сеть класса B отображается в публичный блок класса C) внешний доступ к некоторым хостам внутренней сети может быть внезапно нарушен после того, как будет использован весь доступный блок публичных адресов. Это очень неудобно и вносит существенные ограничения. Таких ситуаций можно избежать, разрешая маршрутизатору с Basic NAT переключаться в режим NAPT после того, как будет исчерпан весь блок публичных адресов. Это обеспечит постоянный доступ извне к хостам внутренней сети, сохраняя возможность доступа из частной сети ко внешним ресурсам для большинства приложений. Отметим, однако, что некоторые приложения, работающие через Basic NAT, могут быть внезапно прерваны в результате переключения на трансляцию NAPT.

6.0. Ограничения NAT

[NAT-TERM] описывает ограничения, присущие всем вариантам NAT, без особой детализации. Ниже приводится более подробное описание ограничений, присущий традиционной трансляции NAT.

6.1. Безопасность и сохранность тайны

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

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

6.2. Отклики ARP на транслированные публичные адреса интерфейсов ЛВС

Трансляция NAT должна использоваться только на граничных маршрутизаторах оконечных доменов. В примерах, иллюстрирующих Basic NAT и NAPT, поддерживался WAN-канал к внешнему маршрутизатору (т. е., к маршрутизатору сервис-провайдера) от маршрутизатора NAT. Однако, если канал WAN заменить соединением через ЛВС и часть или все публичные адреса, используемые для отображения NAT будут относиться к той же подсети IP, что и сегмент ЛВС, ожидается, что маршрутизатор NAT будет поддерживать ARP для диапазона адресов, относящегося к той же подсети. В варианте Basic NAT маршрутизатор должен отвечать на запросы ARP для отображенных с помощью NAT публичных адресов своим адресом MAC. Если маршрутизатор NAT не отвечает на такие запросы, они останутся безответными, поскольку в сети нет других узлов, которые могли бы на них ответить.

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

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

Авторы считают, что подключения к сервис-провайдеру через ЛВС не являются широко распространенными¹¹. Однако производители могут быть заинтересованы в поддержке для таких случаев функций proxy ARP.

6.3. Трансляция исходящих фрагментов TCP/UDP в NAPT

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

7.0. Современные реализации

Доступно множество коммерческих реализаций трансляции адресов, которые соответствуют описанию NAT в данном документе. Открытая ОС Linux содержит реализацию NAT, называемую «IP masquerade». Открытая ОС FreeBSD содержит реализацию NAPT, работающую как демон. Отметим, что исходный код Linux распространяется по лицензии GNU, а программы FreeBSD – по лицензии UC Berkeley.

Программы для Linux и FreeBSD являются бесплатными и вы можете купить компакт-диск с любой из этих программ за весьма разумную цену. Можно также просто загрузить последний вариант программы со множества серверов FTP.

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

Вопросы безопасности, рассмотренные в [NAT-TERM] для всех вариантов NAT, применимы к традиционной трансляции NAT.

Литература

[NAT-TERM] Srisuresh, P. and M. Holdrege, «IP Network Address Translator (NAT) Terminology and Considerations», RFC 2663, August 1999.

[RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

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

[RFC 1122] Braden, R., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC 1123] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

[RFC 1812] Baker, F., «Requirements for IP Version 4 Routers», RFC 1812, June 1995.

[FTP] Postel, J. and J. Reynolds, «FILE TRANSFER PROTOCOL (FTP)», STD 9, RFC 959, October 1985.

[TCP] Defense Advanced Research Projects Agency Information Processing Techniques Office, «TRANSMISSION CONTROL PROTOCOL (TCP) SPECIFICATION», STD 7, RFC 793, September 1981.

[ICMP] Postel, J., «INTERNET CONTROL MESSAGE (ICMP) SPECIFICATION», STD 5, RFC 792, September 1981.

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

[RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, «IPv4 Address Behaviour Today», RFC 2101, February 1997.

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

Pyda Srisuresh

Jasmine Networks, Inc.

3061 Zanker Road, Suite B

San Jose, CA 95134

U.S.A.

Phone: (408) 895-5032

EMail: srisuresh@yahoo.com

Kjeld Borch Egevang

Intel Denmark ApS

Phone: +45 44886556

Fax: +45 44886051

EMail: kjeld.egevang@intel.com

http://www.freeyellow.com/members/kbe

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

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

nmalykh@protokols.ru

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

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

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

1Basic Network Address Translation.

2Network Address Port Translation.

3Small Office, Home Office – небольшой офис, домашний офис.

4Application specific gateway – Специализированный шлюз для приложения.

5Область действия адресов.

6Прозрачная маршрутизация.

7В [NAT-TERM] термин “порт TU” определен, как порт TCP/UDP, связанный с адресом IP. Прим. перев.

8В оригинале – “Uni-directional”. Имеется в виду не направление передачи пакетов, а направление организации соединений. Т. е., в данном случае можно организовать соединения с внешними хостами по инициативе внутренних, но не наоборот. Прим. перев.

9В оригинале — “globally valid network address” — корректные в глобальном масштабе адреса. Будем для краткости называть их публичными. Прим. перев.

10Internet Assigned Numbers Authority – агентство по распределению значений в Internet.

11В настоящее время ситуация изменилась и такие подключения распространены достаточно широко. Прим. перев.

13В соответствии с RFC 3232 документ «Assigned Numbers» утратил статус стандарта. Выделенные значения доступны в настоящее время на сайте http://www.iana.org/numbers.html. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links

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

Network Working Group                                      A. Retana
Request for Comments: 3021                                  R. White
Category: Standards Track                              Cisco Systems
                                                           V. Fuller
                                                 GTE Internetworking
                                                        D. McPherson
                                                      Amber Networks
                                                       December 2000

Использование префиксов размером 31 бит на каналах «точка-точка» в IPv4

Using 31-Bit Prefixes on IPv4 Point-to-Point Links

PDF

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

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

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

Аннотация

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

1. Введение и мотивация

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

более жесткие требования по распределению адресов, предъявляемые IANA и региональными регистраторами [RFC2050];
использование трансляторов сетевых адресов (NAT¹), позволяющее использовать небольшое число адресов, соответствующих требованиям IANA, для большего числа устройств, топологически расположенных за устройством NAT [RFC1631];
развертывание новых протоколов Internet с увеличенным размером адресного пространства; один из таких протоколов (IPv6 [RFC2460]) прошел требуемые процедуры IETF, но еще недостаточно широко поддерживается оборудованием; на развертывание этого протокола потребуется многолетний переходный период.

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

Одним из таких вариантов (незначительного) повышения эффективности будет изменение адресации на каналах «точка-точка». Одним из вариантов экономии адресов на таких соединениях служит использование безадресных интерфейсов на каналах «точка-точка» в некоторых частях Internet. Хотя такой подход может казаться решением проблемы, он создает множество новых проблем и, в частности, усложняет управление безадресными каналами и доступ к маршрутизаторам через такие каналы, существенно осложняет обслуживание и поиск неполадок для таких каналов, а также не имеет должной стандартизации [RFC1812].

В настоящее время для подсетей Internet не применяются маски размером более 30 битов (в большинстве случаев), а это ведет к расходу на каждое соединение 4 адресов — два адреса для хостов, адрес сети (все нули) и широковещательный адрес (все единицы). Для соединений «точка-точка», где может быть только две конечных точки и любой пакет, передаваемый в канал, адресуется расположенному на другой стороне канала устройству, такой подход к распределению адресов не обеспечивает эффективного использования адресного пространства.

Другим вариантом является использование на обоих концах канала адресов хостов². Этот вариант обеспечивает такую же экономию адресного пространства, как при использовании масок подсети размером 31 бит, но его можно применять только на каналах с инкапсуляцией PPP [RFC1332]. Использование адресов хостов позволяет на каждой стороне соединения задавать адреса IP из разных сетей, что усложняет управление каналами и сетями.

Этот документ базируется на идее сохранения пространства IP для адресации каналов «точка-точка» (за счет использования масок подсетей размером более 30 битов) в обеспечением управляемости и максимального соответствия стандартам. Существуют документы [RFC950], в которых уже рекомендуется по возможности использовать для нумерации хостов поле размером 1 бит.

Увидеть экономию адресного пространства в результате реализации предлагаемого изменения легко — для каждого соединения «точка-точка» в сетях будет расходоваться 2 адреса вместо четырех. В масштабах сети с 500 каналами «точка-точка» будет сэкономлено 1000 адресов, что эквивалентно 4 сетям класса C.

2. Префиксы размером 31 бит

В этом разделе рассматривается возможное влияние использования префиксов /31 для каналов «точка-точка» на маршрутизацию и работу Internet. Приведенные здесь соображения отражены в разделе 3.

В этом документе адрес IP интерпретируется, как пара

<Номер сети><Номер хоста>

где <Номер хоста> представляет собой немаскируемую часть адреса. Размер этого поля следует устанавливать не менее 1 бита. В последующем рассмотрении предполагается, что система маршрутизации поддерживает бесклассовую маршрутизацию CIDR в соответствии с [RFC1519].

2.1. Адресация

Если для канала «точка-точка» используется маска размером 31 бит, для поля <Номер хоста> остается только 1 бит. Следовательно, в такой подсети могут существовать только два адреса

{<Номер сети>, 0} и {<Номер сети>, -1}

Эти адреса исторически связаны с номером сети и широковещательным адресом (см. параграф 2.2). Для каналов «точка-точка» такие адреса должны интерпретироваться, как адреса хостов.

2.2. Широковещательные и сетевые адреса

Существует несколько признанных типов широковещательных адресов для сегментов IP [RFC1812]

направленное широковещание
```
{<Номер сети>, -1}
{<Номер сети>, 0}
```
Форма {<Номер сети>, 0} является устаревшим вариантом для направленного широковещания, но может до сих пор применяться на старых хостах.
локальное для канала (ограниченное) широковещание
```
{-1, -1}
{0, 0}
```
Форма {0, 0} является устаревшим вариантом ограниченного широковещания, но может до сих пор применяться на старых хостах.

При использовании префиксов размером 31 бит остается только два адреса (см. параграф 2.1), что не позволяет использовать направленное широковещание для соединения (см. параграф 2.2.1). Для всего широковещательного трафика на каналах «точка-точка» с маской подсети /31 должно применяться ограниченное широковещание.

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

Назначение этого документа состоит в обсуждении применимости и использования для каналов «точка-точка» префиксов размером 31 бит. Влияние (если таковое есть) на другие типы интерфейсов здесь не рассматривается.

2.2.1. Направленное широковещание

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

Как указано в разделе 6, потеря функциональности направленного широковещания может на самом деле давать побочный позитивный эффект в виде некоторого повышения устойчивости сети к некоторым классам DoS-атак [RFC2644, SMURF].

2.3. Влияние на протоколы маршрутизации

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

3. Рекомендации

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

3.1. Requirements for Internet Hosts — Communication Layers [RFC1122]

Пункт 3.2.1.3 (e) заменяется приведенным ниже текстом³:

(e) { <Номер сети>, <Номер подсети>, -1 }

Направленное широковещание для заданной подсети. Такой адрес недопустимо использовать в качестве адреса получателя за исключением тех случаев, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской.

Добавляется новый пункт 3.2.1.3 (h):

(h) { <Номер сети>, <Номер подсети>, 0 }

Номер подсети. Этот адрес не следует использовать в качестве адреса отправителя за исключением ситуаций, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской. Для других типов каналов пакеты с таким адресом получателя следует отбрасывать без уведомления. Если такие пакеты не отбрасываются, они должны трактоваться, как широковещательные пакеты IP [RFC1812].

3.2. Assigned Numbers [RFC1700]

Пункт (e) раздела «Специальные адреса» во «Введении» заменяется приведенным ниже текстом:

(e) {<Номер сети>, <Номер подсети>, -1}

Направленное широковещание для заданной подсети. Может использоваться только в качестве адреса получателя. Аднако в случаях, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской, этот адрес может указываться и для отправителя.

3.3. Requirements for IP Version 4 Routers [RFC1812]

Пункт 4.2.2.11 (d) заменяется приведенным ниже текстом:

(d) { <Префикс сети>, -1 }

Направленное широковещание — широковещательные пакеты для указанного сетевого префикса. Такой адрес недопустимо использовать в качестве адреса получателя за исключением тех случаев, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской. Маршрутизатор может генерировать пакеты Network Directed Broadcast. Маршрутизатор может иметь конфигурационную опцию, позволяющую ему принимать пакеты направленного широковещания, однако по умолчанию эта опция должна быть отключена и, таким образом, маршрутизатору недопустимо принимать пакеты Network Directed Broadcast, пока это явно не задано в конфигурации.

Приведенный выше текст включает обновления, внесенные [RFC2644].

Добавляется новый пункт 4.2.2.11 (f):

(f) { <Номер сети>, <Номер подсети>, 0 }

Номер подсети. Такой адрес не следует использовать в качестве адреса отправителя за исключением тех случаев, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской. Для других типов каналов пакеты с таким адресом в поле получателя следует отбрасывать без уведомления. Если такие пакеты не отбрасываются, они должны трактоваться, как широковещательные пакеты IP.

В параграфе 4.2.3.1 пункты (1), (2) и (4) заменяются приведенным ниже текстом:

(1) Должны трактоваться, как широковещательные пакеты IP все пакеты, направленные по адресу 255.255.255.255 или { <Префикс сети>, -1 }.

На каналах «точка-точка» с маской размером 31 бит, пакеты, направленные по адресу { <Префикс сети>, -1 }, соответствующему одной из конечных точек этого канала, должны трактоваться, как направленные маршрутизатору, на котором установлен этот адрес.

(2) Следует отбрасывать без уведомления (т. е., даже без доставки даже работающим на маршрутизаторе приложениям) все пакеты, направленные по адресу 0.0.0.0 или { <Префикс сети>, 0 }. Если такие пакеты не отбрасываются, они должны трактоваться, как широковещательные пакеты IP (см. параграф 5.3.5). Может использоваться конфигурационная опция, позволяющая принимать такие пакеты. По умолчанию следует устанавливать для этой опции отбрасывание пакетов.

На каналах «точка-точка» с маской размером 31 бит, пакеты, направленные по адресу { <Префикс сети>, 0 }, соответствующему одной из конечных точек этого канала, должны трактоваться, как направленные маршрутизатору, на котором установлен этот адрес.

(4) Не следует генерировать дейтаграммы, направленные по адресу 0.0.0.0 или {<Префикс сети>, 0 }. Может использоваться конфигурационная опция, позволяющая генерировать такие пакеты (вместо использования подходящего формата широковещания). По умолчанию для опции следует использовать значение, не позволяющее генерировать такие пакеты.

На каналах «точка-точка» с маской размером 31 бит в конфигурации следует разрешать генерацию дейтаграмм, направленных по адресу { <Префикс сети>, 0 }.

В параграф 4.3.3.9 добавляется приведенный ниже текст:

Широковещательный адрес 255.255.255.255 должен использоваться для широковещательных откликов Address Mask Reply на каналах «точка-точка» с маской подсети размером 31 бит.

4. Опыт применения

Представленные в этом документе рекомендации были реализованы несколькими производителями маршрутизаторов в бета-версиях программ. Реализации были протестированы по крайней мере тремя ISP с положительными результатами (т. е., без возникновения проблем). Тестирование проводилось с протоколами маршрутизации OSPF, IS-IS, BGP и EIGRP.

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

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

Целью этого документа является рассмотрение применимости и вопросов использования префиксов /31 на каналах «точка-точка». Влияние таких префиксов (если оно есть) на каналы иных типов не рассматривалось. Отметим, что каналы «точка-точка», в которых только одна из сторон поддерживает префиксы размером 31 бит, могут работать некорректно.

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

С учетом существования различных типов атак на службы (DoS) в Internet вопросы безопасности требуют серьезного внимания. Использование масок подсетей /31 в магистральных сетях Internet будет сниэать число каналов, подверженных влиянию DoS, основанных на репликации пакетов за счет использования направленного широковещания [RFC2644, SMURF].

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

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

Авторы документа не заявляют каких-либо претензий в части оригинальности описанных здесь идей. Наряду с другими людьми, авторы выражают свою признательность Алексу Зинину (Alex Zinin) за полученные от него комментарии и многочисленным участникам тестирования сетей /31 в лабораториях и сетях.

8. Литература

[RFC950] Mogul, J. and J. Postel, «Internet Standard Subnetting Procedure», STD 5, RFC 950, August 1985.

[RFC1122] Braden, R., «Requirements for Internet Hosts – Communication Layers», STD 3, RFC 1122, October 1989.

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

[RFC1519] Fuller, V., Li, T., Yu, J. and K. Varadhan, «Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy», RFC 1519, September 1993.

[RFC1631] Egevang, K. and P. Francis, «The IP Network Address Translator (NAT)», RFC 1631, May 1994.

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

[RFC1812] Baker, F., «Requirements for IP Version 4 Routers», RFC 1812, June 1995.

[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, «Internet Registry IP Allocation Guidelines», BCP 12, RFC 2050, November 1996.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[RFC2644] Senie, D., «Changing the Default for Directed Broadcasts in Routers», BCP 34, RFC 2644, August 1999.

[SMURF] Huegen, C., «The Latest in Denial of Service Attacks: ‘Smurfing’: Description and Information to Minimize Effects», URL: http://users.quadrunner.com/chuegen/smurf.cgi

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

Alvaro Retana

Cisco Systems, Inc.

7025 Kit Creek Rd.

Research Triangle Park, NC 27709

EMail: aretana@cisco.com

Russ White

Cisco Systems, Inc.

7025 Kit Creek Rd.

Research Triangle Park, NC 27709

EMail: riw@cisco.com

Vince Fuller

GTE Internetworking

3801 E. Bayshore Rd.

Palo Alto, CA, 94303

EMail: vaf@valinor.barrnet.net

Danny McPherson

Amber Networks

2465 Augustine Drive

Santa Clara, CA 95054

EMail: danny@ambernetworks.com

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

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

nmalykh@protokols.ru

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

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

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

1Network Address Translator.

2С маской /32. Прим. перев.

3В имеющийся на сайте перевод этого документа внесены соответствующие изменения. Прим. перев.

5В соответствии с RFC 3232 этот документ утратил силу и заменен базой данных, доступной по ссылке www.ietf.org/numbers/. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 3007 Secure Domain Name System (DNS) Dynamic Update

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

Network Working Group                                      B. Wellington
Request for Comments: 3007                                       Nominum
Updates: 2535, 2136                                        November 2000
Obsoletes: 2137
Category: Standards Track

Secure Domain Name System (DNS) Dynamic Update

Защищённое динамическое обновление DNS

PDF

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

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

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

Аннотация

Этот документ предлагает метод защищённого динамического обновления для системы доменных имён (Domain Name System или DNS). Описываемый метод предполагается гибким и полезным, а также не требует значительных изменений протокола. Проверка подлинности сообщений об обновлении отделена от последующей проверки данных с помощью DNSSEC. Защищённое взаимодействие основано на аутентифицированных запросах и транзакциях для проверки полномочий.

1. Введение

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

Предполагается будет знакомство читателя с системой DNS [RFC1034, RFC1035] и её динамическим обновлением [RFC2136]. Кроме того, рекомендуется ознакомиться с защитными расширениями DNS [RFC2535], защитой транзакций SIG(0) [RFC2535, RFC2931] и TSIG [RFC2845].

Документ частично обновляет RFC 2535 (параграф 3.1.2) и RFC 2136. Документ отменяет RFC 2137, предоставляя другой вариант защищённых динамических обновлений.

1.1. Обзор динамического обновления DNS

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

1.2. Обзор защиты транзакций DNS

Обмен сообщениями DNS с записями TSIG [RFC2845] или SIG(0) [RFC2535, RFC2931] позволяет двум субъектам DNS проверить подлинность запросов и откликов DNS, передаваемых между ними. Код аутентификации сообщения TSIG MAC (message authentication code) выводится из общего секрета, а SIG(0) создаётся из секретного ключа, открытый ключ для которого хранится в DNS. В обоих случаях запись подпись или MAC включается как финальная запись о ресурсе в сообщении DNS. Хэш-значения на основе ключа, применяемые в TSIG недороги в плане расчёта и проверки. Шифрование с открытым ключом, применяемое в SIG(0), лучше расширяется, поскольку открытые ключи хранятся в DNS.

1.3. Сравнение аутентификации данных и сообщений

Аутентификация на основе сообщений с использованием TSIG или SIG(0) обеспечивает защиту всего сообщения с помощью одной подписи и одной проверки, которая в случае TSIG является сравнительно недорогими созданием и проверкой MAC. Для запросов обновления подпись может определять на основе политики или согласования ключей полномочия на подачу запросов.

Записи DNSSEC SIG можно применять для защиты целостности отдельных RR или RRset в сообщении DNS с полномочиями владельца зоны. Однако это не обеспечивает должной защиты запросов динамического обновления.

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

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

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

В разделе обновления запроса обновления подпись запросов на добавление RRset не вызывает сложностей и может постоянно применяться для защиты данных, как указано в [RFC2535]. Однако при удалении RRset для SIG не будет данных.

1.4. Подписи данных и сообщений

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

Основная польза ключей хоста и пользователя применительно к DNSSEC заключается в проверке подлинности сообщений, включая динамические обновления. Ключи хоста и пользователя могут применяться для создания записей SIG(0) с целью аутентификации обновлений, а также могут использоваться в процессе TKEY [RFC2930] для генерации общих секретов TSIG. В обоих случаях записи SIG, созданные с не относящимися к зоне ключами, не будут применяться в процессе проверки DNSSEC, пока этого не требует локальная политика.

Проверка подлинности данных при их представлении в DNS включает лишь ключи DNSSEC для зоны и созданные с этими ключами подписи.

1.5. Поле signatory

В параграфе 3.1.2 [RFC2535] поле signatory для ключа определено как 4 финальных бита поля флагов, но значение поля не задано. В соответствии с обновлением [RFC2535] в этом поле записей KEY следует устанавливать значение 0, которое должно игнорироваться.

2. Проверка подлинности

Подписи TSIG или SIG(0) должны включаться во все сообщения динамического обновления. Это позволяет серверу достоверно определить источник сообщения. При использовании аутентификации SIG(0) отправителем (владельцем) будет владелец записи KEY RR, послужившей для создания SIG(0). Если сообщение содержит подпись TSIG, созданную с помощью заданного статически общего секрета, владелец будет тем же, что и для общего секрета или производным от него. Если сообщение содержит подпись TSIG, созданную с помощью динамического общего секрета, владельцем будет тот, кто аутентифицировал процесс TKEY, если же процесс не был аутентифицирован, сведений о владельце не будет и соответствующий общий секрет TSIG недопустимо применять для защищённых динамических обновлений.

Подписи SIG(0) не следует генерировать с ключами зон, поскольку транзакцию инициирует хост или пользователь, а не зона.

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

При отказе обновления из-за его подписания с несанкционированным ключом сервер должен указать ошибку, вернув сообщение RCODE REFUSED. Другие ошибки TSIG, SIG(0) или динамического обновления возвращаются в соответствии со спецификацией протокола.

3. Политика

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

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

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

3.1. Стандартные правила

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

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

3.1.1. Пользовательские типы

Пользовательскими считаются все типы, кроме SOA, NS, SIG и NXT. Записи SOA и NS не следует изменять обычным пользователям, поскольку эти типы создают или изменяют точки делегирования. Добавление записей SIG может приводить к атакам, создающим дополнительную нагрузку на распознаватели, а удаление SIG для зоны может приводить к дополнительной нагрузке на сервер. Отметим, что доступ к этим записям обычных пользователей не запрещён, но не рекомендуется.

Динамическим обновлениям недопустимо создавать, изменять или удалять записи NXT, поскольку их обновление может приводить к нестабильности протокола. Это является обновлением RFC 2136.

Вопросы, связанные с обновлением записей KEY рассматриваются в разделе 5.

3.2. Дополнительные правила

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

4. Взаимодействие с DNSSEC

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

4.1. Добавление SIG

Полномочный запрос может включать записи SIG в каждом RRset. Поскольку записи SIG (кроме SIG(0)) недопустимо применять для проверки подлинности сообщений обновления, такие записи не требуются. Если участник уполномочен обновлять записи SIG и в обновлении имеются такие записи, они добавляются без проверки. Сервер может проверять записи SIG и отбрасывать SIG с истекшим сроком действия.

4.2. Удаление SIG

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

4.3. Неявные обновления SIG

Если обновляемая зона защищена, набор RRset, затронутый обновлением, по завершении обновления должен быть подписан в соответствии с политикой зоны. Для этого обычно требуется создать одну или несколько записей SIG с одним или разными ключами зоны, закрытые компоненты которых должны быть доступны через сеть (online) [RFC3008].

При обновлении содержимого RRset сервер может удалять связанные записи SIG, поскольку они станут недействительными.

4.4. Воздействие на зону

При внесении каких-либо изменений сервер должен (если необходимо) создавать новую запись SOA и новые записи NXT, подписывая их с соответствующими ключами зоны. Изменения записей NXT путём защищённого динамического обновления явно запрещены. Обновления SOA разрешаются, поскольку поддержка параметров SOA выходит за рамки протокола DNS.

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

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

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

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

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

Harald Alvestrand

Donald Eastlake

Olafur Gudmundsson

Andreas Gustafsson

Bob Halley

Stuart Kwan

Ed Lewis

7. Литература

[RFC1034] Mockapetris, P., «Domain Names — Concepts and Facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain Names — Implementation and Specification», STD 13, RFC 1035, November 1987.

[RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, «Dynamic Updates in the Domain Name System», RFC 2136, April 1997.

[RFC2137] Eastlake, D., «Secure Domain Name System Dynamic Update», RFC 2137, April 1997.

[RFC2535] Eastlake, G., «Domain Name System Security Extensions», RFC 2535, March 1999.

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, «Secret Key Transaction Signatures for DNS (TSIG)», RFC 2845, May 2000.

[RFC2930] Eastlake, D., «Secret Key Establishment for DNS (TKEY RR)», RFC 2930, September 2000.

[RFC2931] Eastlake, D., «DNS Request and Transaction Signatures (SIG(0)s)», RFC 2931, September 2000.

[RFC3008] Wellington, B., «Domain Name System Security (DNSSEC) Signing Authority», RFC 3008, November 2000.

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

Brian Wellington

Nominum, Inc.

950 Charter Street

Redwood City, CA 94063

Phone: +1 650 381 6022

EMail: Brian.Wellington@nominum.com

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

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

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

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

nmalykh@protokols.ru

Рубрика: RFC | Оставить комментарий