В облаке MPLS маршруты определяются
В облаке MPLS маршруты определяются протоколом уровня L3. Чтобы улучшить рабочие характеристики сети эти маршруты могут быть преобразованы в пути уровня L2. Кроме этого, MPLS предлагает средства улучшения сетевых услуг, такие как QoS/CoS, управление трафиком и т.д.
Существующие уникастные протоколы маршрутизации формируют некоторый (оптимальный) кратчайший путь для определенной пары отправитель-получатель. Заметим, что уникастные протоколы могут работать по-разному в случае путей с эквивалентной метрикой. Для мультикастинга оптимальное решение (минимальная цена соединения N узлов) предполагает вычисление дерева Штайнера (Steiner). К сожалению, ни один современный мультикастный протокол маршрутизации не может сформировать такого дерева. Разные мультикастные протоколы формируют различные деревья.
Обсуждение в данном документе концентрируется на протоколах внутридоменной мультикастинг маршрутизации.
Документ RFC 822, который прослужил без малого 20 лет, регламентировал работу лишь с текстовыми сообщениями (передача аудио- видео- или графических сообщений в нем не рассматривалась). Но даже в случае чисто текстовых документов возникали проблемы при работе с языковыми наборами, требующими символов, которые отсутствуют в US-ASCII.
Одним из существенных ограничений традиционной электронной почты, базирующейся на RFC 821-822, является установка предельного размера строки (1000 7-битовых US-ASCII символов). Это вынуждало пользователей конвертировать текст различными методами в последовательность US-ASCII-кодов (например, процедура uuencode или преобразование в коды Base-64).
Существенные проблемы возникали при почтовом обмене между узлами, поддерживающими протоколы RFC 822 и X.400. Протокол X.400 [X400] определяет механизм включения нетекстовых материалов в почтовые сообщения. Существующие протоколы согласования работы X.400 и RFC 822 предполагают, что X.400 осуществляет преобразование нетекстовых вставок в формат IA5Text, или такие сообщения просто выбрасываются. Отправитель сообщения часто не знает о возможностях получателя, что может привести к тому, что последний, получив сообщения, попросту не сможет его прочесть. Таким образом, нужен механизм согласования возможностей отправителя и получателя на начальной стадии их взаимодействия до начала передачи тела сообщения.
В протоколе MIME регламентируется следующее:
Поле заголовка MIME-Version, которое характеризует версию протокола и позволяет почтовым агентам согласовать свои возможности и исключить конфликты с устаревшим программным обеспечением.
Поле заголовка Content-Type, которое используется для спецификации типа среды и субтипа данных в теле сообщения, а также для описания канонической формы этих данных.
Поле заголовка Content-Transfer-Encoding, которое может использоваться для задания типа преобразования.
Два дополнительные поля заголовка, предусмотренные для уточнения описания данных в теле сообщения (Content-ID и Content-Description).
Современные протоколы Интернет с самого начала создавались таким образом, чтобы их было легко расширить или модернизировать. В частности, MIME [RFC-2045] является открытой системой, допускающей введение новых типов объектов, символьных наборов и методов доступа без изменения базового протокола. Однако необходим процесс регистрации, чтобы гарантировать, что набор таких значений соответствует стандарту и может использоваться в общедоступных сетях.
Здесь рассматриваются процедуры регистрации, которые осуществляются через IANA (Internet Assigned Numbers Authority), центральной инстанции для решения этих проблем.
Процесс регистрации для типов среды был первоначально определен в контексте асинхронной почтовой среды Интернет. В этой почтовой среде существует необходимость ограничить число возможных типов среды, чтобы увеличить вероятность успешного взаимодействия с удаленной почтовой системой, когда ее возможности заранее не известны.
В разделе 2.9 описания архитектуры MPLS [2] протокол рассылки меток определен как набор процедур, с помощью которых один маршрутизатор LSR (Label Switched Router) информирует другие о значении меток, используемых для переадресации трафика между ними и через них. Архитектура MPLS не предполагает существования единственного протокола рассылки меток. Данная статья представляет собой спецификацию расширения протокола RSVP для формирования маршрутов (LSP) с коммутацией по меткам в MPLS-сетях.
Несколько новых особенностей, описанных здесь, мотивировались требованиями управления трафиком в рамках MPLS (смотри [3]). В частности, расширенный протокол RSVP поддерживает реализацию явной прокладки LSP, с или без резервирования ресурсов. Он также поддерживает плавное изменение маршрута LSP, установление приоритетов и обнаружение циклических путей.
LSP, сформированные RSVP, могут использоваться для транспортировки потоков трафика ("Traffic Trunks"), как это описано в [3]. Два LSP между отправителем и получателем могут образовывать единый поток трафика. Наоборот несколько потоков трафика могут транспортироваться одним LSP, если бы, например, LSP могли предоставлять несколько классов услуг. Применимость этих расширений обсуждается в [10].
Так как трафик, который проходит по маршруту с коммутацией меток, определен меткой, заданной входным узлом LSP, эти маршруты могут рассматриваться как туннели, обеспечивающие связь между обычной IP-маршрутизацией и механизмами отбора (фильтрации). Когда LSP используется так, мы называем их LSP-туннелями.
LSP-туннели допускают реализацию различных политик оптимизации работы сети. Например, LSP-туннели могут обходить автоматически или вручную точки отказов в сети, области перегрузок или узкие места. Более того, несколько параллельных LSP-туннелей могут быть проложено между двумя узлами, и трафик между этими узлами может быть направлен через эти LSP-туннели согласно местной политике маршрутизации. Хотя предполагается, что управление трафиком (то есть, оптимизация рабочих характеристик сети) является важным приложением этой спецификации, расширенный протокол RSVP может быть использован в более широком контексте.
Целью данной статьи является описание использования RSVP для формирования LSP-туннелей. Предполагается полностью описать все объекты, форматы пакетов и процедуры, необходимые для реализации совместимых реализаций. Определено несколько объектов, которые улучшают управление и диагностику LSP-туннелей. В статье обсуждаются также средства быстрого детектирования отказа узлов посредством нового сообщения HELLO.
Все объекты и сообщения, обсуждаемые в данной статье, являются опционными по отношению RSVP. В данной статье обсуждается ситуация, когда определенный объект не поддерживается конкретным узлом.
В области MPLS [MPLS_ARCH], когда поток данных проходит по общему пути, маршрут с коммутацией по меткам LSP (Label Switched Path) может быть сформирован с привлечением сигнальных протоколов MPLS. Во входном маршрутизаторе с коммутацией по меткам LSR (Label Switch Router), каждому пакету присваивается метка, и он передается далее “вниз по течению”. В каждом LSR вдоль LSP, метки используются для определения следующего шага переадресации пакета.
При предоставлении дифференцированных услуг Diff-Serv (Differentiated Service) [DIFF_ARCH] все IP-пакеты, проходящие через канал и требующие того же уровня Diff-Serv, образуют ансамбль BA (Behavior Aggregate). Во входном узле области Diff-Serv, пакеты классифицируются и помечаются с помощью кода DSCP (Diff-Serv Code Point), который соответствует их ансамблю BA. В каждом промежуточном узле, DSCP используется для определения пошагового поведения PHB (Per Hop Behavior), которое задает последовательность обработки и, в некоторых случаях, вероятность отбрасывания пакетов.
В данном документе рассмотрена схема поддержки ансамблей ВА Diff-Serv, чье PHB-поведение определено (в [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) для сетей MPLS. Данная схема основана на использовании комбинации двух типов LSP:
- LSP, которые могут транспортировать несколько ансамблей ВА, так что поле EXP заголовка MPLS передает LSR характер PHB, которое следует применить к пакету.
- LSP, которые транспортируют только один ансамбль ВА, так что обработка пакетов в LSR целиком определяется значением их метки, приоритет отбрасывания пакета задается полем EXP заголовка MPLS или на уровне инкапсуляции канала специфическим механизмом отбрасывания (ATM, Frame Relay, 802.1).
Как указано в [DIFF_HEADER], сервис провайдеры не должны использовать одни и те же механизмы узла или конфигурации для дифференциации услуг внутри сети, и свободно могут конфигурировать параметры узла любым способом, который подходит для них и соответствует объективным условиям управления трафиком. Таким образом, предложение, рассмотренное в данном документе, предоставляет сервис провайдерам достаточную свободу того, как осуществлять маршрутизацию для разных классов услуг Diff-Serv или как управлять трафиком в пределах их области ответственности (например, разделить классы услуг, поддерживаемые через разные LSP и маршрутизируемые независимо, и классы услуг поддерживаемые одним LSP и маршрутизируемые вместе).
Так как протокол MPLS ориентирован на маршрут, он может в потенциале обеспечить большее быстродействие и более предсказуемые возможности защиты и восстановления при изменениях топологии, которые обычны для IP-систем, маршрутизируемых пошагово. В данном документе мы называем это "MPLS защитой". Хотя такие возможности и связанные с ними механизмы находятся за пределами данной спецификации, отмечается, что они могут предложить разные уровни защиты для различных LSP. Так как рассмотренное здесь решение позволяет сервис провайдеру выбрать то, как следует установить соответствие между классами обслуживания Diff-Serv и LSP, оно предоставляет определенную гибкость в выборе уровня защиты для различных классов услуг Diff-Serv (например, некоторые классы услуг могут поддерживаться LSP, обеспечивающими такую защиту, другие LSP могут не предлагать такой защиты).
Более того, решение, предлагаемое в данном документе, позволяет сохранять пространство меток и уменьшает объем обменов, сопряженных с процедурами set-up/tear-down, прибегая, где возможно, к использованию нескольких LSP для заданного FEC (Forwarding Equivalent Class) [MPLS_ARCH].
Эта спецификация позволяет поддерживать в рамках сетей MPLS дифференциальные услуги как для IPv4, так и IPv6.
Схема, описанная в данном документе, не препятствует использованию битов поля EXP для поддержки явного уведомления о перегрузке ECN (Explicit Congestion Notification) совместно с Diff-Serv в рамках MPLS. Однако способы поддержки ECN в среде MPLS в данной статье не рассматриваются.
Архитектура протокола MPLS [RFC3031] была определена для переадресации пакетов на основе меток. В этой архитектуре предполагается, что маршрутизаторы LSR способны (a) распознавать границы пакетов или ячеек, и (b) могут обрабатывать заголовки пакетов (для LSR, способных распознавать границы пакетов) или заголовки ячеек (для LSR, способных распознавать границы ячеек).
Исходная архитектура теперь распространена на LSR, которые не могут распознавать ни границы пакетов, ни границы ячеек, и, следовательно, не могут переадресовать данные на основе информации, содержащейся в заголовках пакетов или ячеек. Такие LSR в частности включают в себя приборы, где решение о переадресации принимается на основе временного домена, длины волны или номера физического порта.
Подобные LSR, или точнее интерфейсы LSR, могут быть отнесены к следующим классам:
Интерфейсы, которые распознают границы пакетов/ячеек и могут переадресовать данные с учетом содержимого заголовка пакета/ячейки. Примерами могут служить интерфейсы маршрутизаторов, которые переадресуют данные на основе содержимого промежуточных заголовков, интерфейсы ATM-LSR, которые переадресуют данные на основе VPI/VCI ATM. Такие интерфейсы считаются способными коммутировать пакеты (PSC - Packet-Switch Capable).
Интерфейсы, которыеи переадресуют данные на основе циклических временных доменов. Примером такого интерфейса является соединение SONET/SDH. Такие интерфейсы считаются мультиплексирующими по времени (TDM).
Интерфейсы, которые переадресуют данные на основе длины волны, на которой данные получены. Примером такого интерфейса является оптические коммутаторы, которые работают на уровне отдельных длин волн. Такие интерфейсы считаются l -переключателями LSC (Lambda Switch Capable).
Интерфейсы, которые переадресуют данные на основе положения данных в реальном физическом пространстве. Примером такого интерфейса является оптическое подключение, которое работает на уровне одного (или нескольких) волокон. Такие интерфейсы считаются оптическими переключателями FSC (Fiber-Switch Capable).
Протокол обобщенного MPLS раздвигает его применимость с поддержки пакетных интерфейсов (PSC) и коммутации до поддержки трех новых классов интерфейсов и коммутации:TDM (Time-Division Multiplex - мультиплексирование по времени), l-коммутатор (LSC) и волоконный коммутатор (FSC). Функциональное описание расширений MPLS, необходимых для поддержки новых классов интерфейсов и коммутации сделано в [RFC3471]. Этот документ рассматривает специфические форматы RSVP-TE и механизмы, необходимые для поддержки всех четырех классов интерфейсов.
[RFC3471] следует рассматривать как составную часть этого документа. В этом документе определены также возможности RSVP-TE, для поддержки быстрого уведомления об отказах, смотри разделы 4.2 и 4.3.
Язык описания маршрутной политики RPSL (Routing Policy Specification Language) позволяет оператору сети специфицировать маршрутную политику на различных уровнях иерархии Интернет, например, на уровне автономных систем (AS). Так что низкоуровневые конфигурации маршрутизаторов могут генерироваться на основании спецификаций RPSL. Язык RPSL является расширяемым и не препятствует внедрению новых протоколов маршрутизации.
Язык RPSL призван заменить язык спецификации маршрутной политики, используемый в настоящее время и описанный в документах RIPE-181 [6] или RFC-1786 [7]. RIPE-81 [8] был первым языком, использованным в Интернет для спецификации маршрутных политик. В процессе использования RIPE-181 стало понятно, что некоторые политики не могут быть специфицированы и необходим более совершенный язык.
Язык RPSL был сконструирован так, чтобы описание всей политики маршрутизации записывалось в одну распределенную базу данных, улучшая целостность маршрутизации в Интернет. RPSL не является языком конфигурации маршрутизатора. Язык RPSL сформирован так, чтобы конфигурация маршрутизатора осуществлялась на основе описания маршрутной политики автономной системы (класс aut-num) в сочетании с описанием маршрутизатора (класс inet-rtr), которое предоставляет идентификатор маршрутизатора, номер автономной системы, описания интерфейсов и партнеров маршрутизатора. Эти данные используются совместно с глобальной базой данных карты автономных систем (класс as-set), и информацией об автономных системах отправителях и о маршрутных префиксах (классы route и route-set).
Язык RPSL является объектно-ориентированным, то есть, объекты содержат блоки описания политики и административную информацию. Эти объекты регистрируются в IRR (Internet Routing Registry) авторизованными организациями. О IRR смотри [1, 17, 4].
Далее рассматриваются классы, которые используются для определения различных политик и административных объектов. Класс "mntner" определяет средства, предназначенные для добавления, уничтожения и модификации набора объектов. Классы "person" и "role" описывают технический и административный персонал, с которым можно установить контакт. Автономные системы (AS) специфицируются с помощью класса "aut-num". Маршруты специфицируются посредством класса "route". Наборы объектов могут быть определены с помощью классов "as-set", "route-set", "filter-set", "peering-set" и "rtr-set". Класс "dictionary" предоставляет возможность расширения возможностей языка. Класс "inet-rtr" используется для спецификации маршрутизаторов. Многие из этих классов были определены ранее, смотри [6, 13, 16, 12, 5].
