Протоколы маршрутизации Internet

Эти АС с позиций маршрутизации называются также «регионами» (domains). Внутри АС используются протоколы внутрирегиональной маршрутизации (Interior Gateway Protocols - IGP), а между АС - протоколы межрегиональной маршрутизации (Exterior Gateway Protocols - EGP). Первый межрегиональный протокол, продолжающий в ограниченном масштабе использоваться в Internet и сейчас, получил то же название, что и весь класс протоколов - EGP. Во избежание терминологической путаницы в некоторых источниках класс межрегиональных протоколов называют «межсистемными» (inter-AS) протоколами маршрутизации.

Общий класс устройств, выполняющих функции продвижения маршрутизируемой информации, в начальных документах Internet (примерно до 1985 года) назывался «шлюзами» (gateways), однако в последние годы термин «шлюзы» стали относить только к устройствам продвижения информации прикладного уровня, а соответствующие устройства для информации сетевого уровня получили название «маршрутизаторы» (routers); для соответствующих устройств продвижения информации второго уровня (звена данных) изначально используется термин «мосты» (bridges), заимствованный из терминологии по взаимосвязи локальных сетей.

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

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

Протоколы маршрутизации устанавливают маршруты (т. е. распространяют информацию о маршрутах) в направлении противоположном продвижению датаграмм или сообщений по этим маршрутам. Для устранения терминологической путаницы в RFC 1476 и др. предложено ввести следующие понятия:

• отправитель (source) - отправитель датаграммы;
• получатель (destination) - место назначения датаграммы;
• источник (origin) - пункт первоначальной отправки маршрутной информации в регион;
• адресат (target) - пункт назначения маршрутной информации, откуда передаются датаграммы.

То есть в одном сеансе маршрутизации понятие «отравитель» относится к тому же объекту, что и «адресат», а понятие «получатель» к тому же объекту, что и «источник». Следует, однако, заметить, что эта терминология выдерживается не во всех (в том числе последних) документах Internet.

При изложении на русском языке концепций Internet, в частности, вопросов маршрутизации, приходится иногда сталкиваться с терминологическими проблемами. Примером тому может служить понятие host, введенное впервые IBM в сочетании host computer и изначально переводимое на русский язык как «центральная ЭВМ» или «центральный компьютер». Однако в контексте маршрутизации понятие host имеет несколько иной смысл, означающий конечного отправителя или получателя данных, в качестве которого могут быть и самый простой персональный компьютер и даже обычный дисплей или принтер, что делает непригодными для обозначения этого понятия ни один из указанных русских эквивалентов.

Очень удачными в этом плане представляются два простых понятия, используемые в стандартах ISO по протоколам маршрутизации: 1) end system - ES (оконечная система - ОС), под которой понимается то, что в Internet (в концепции маршрутизации) называют host, и 2) intermediate system - IS (промежуточная система - ПС) - общий термин для маршрутизаторов, шлюзов, мостов, коммутационных, ретрансляционных и другого вида устройств продвижения маршрутизируемой информации.

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

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

Методы маршрутизации

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

В свое время Internet создавалась как иерархическая архитектура, представляющая собой совокупность образующих ее магистральных (backbone), региональных (regional), городских (metropolitan) и кустовых (campus) регионов. Некоторые регионы были транзитными, но большинство «тупиковыми» (stub). Сегодня большинство регионов осуществляют взаимосвязи друг с другом через прямые или косвенные связи, по меньшей мере, с одним магистральным регионом. Однако некоторые регионы желают иметь непосредственные связи со своими наиболее предпочтительными партнерами. Следовательно, Internet должна обладать свойствами как иерархической, так и смешанной связности.

В разрабатываемых стратегиях маршрутизации необходимо учитывать также появление «суперрегионов» (superdomain) и конфедераций регионов маршрутизации (routing domain confederations).

В задачах маршрутизации (индивидуальной и групповой) выделяются две различные но взаимосвязанные задачи:

1) определение и установление маршрутов между регионами сети и распространение по установленным маршрутам маршрутной информации. Эта задача определяется стратегией маршрутизации (policy routing);

2) продвижение по установленным маршрутам сообщений от региона - отправителя к региону - получателю.

В первой задаче широкое применение получили два алгоритма: вектор дистанций (distance vector) и состояние каналов (link state), во второй - два других алгоритма: постадийная маршрутизация (hop-by-hop routing) и маршрутизация отправителем (source specified routing). Рассмотрим кратко каждый из этих алгоритмов.

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

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

Маршрутизирующий объект может хранить несколько маршрутов к одному получателю с различными характеристиками. Для различения этих маршрутов маршрутизирующий объект использует информацию о качестве услуг (QOS - Quolity of Service), предоставляемую транзитными стратегиями. (Передача информации о QoS определена в RFC 2676). При генерации маршрута каждый получатель сообщения оценивает приемлемость соответствующего маршрута и определяет набор соседних регионов, которым следует направить сообщения. Для приемлемости маршрута необходимо, чтобы маршрут соответствовал, по меньшей мере, одной транзитной стратегии каждого региона и, по меньшей мере, одной стратегии отправителя хотя бы одного региона в Internet. Для этого каждый регион должен обеспечить другим регионам доступ к своим стратегиям отправителя. Маршрутизирующий объект аннулирует любое сообщение вектора дистанций, которое не удовлетворяет этим условиям.

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

Алгоритм «вектор дистанций» имеет следующие недостатки.

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

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

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

В то же время из двух упомянутых алгоритмов маршрутизации только «вектор дистанций» охватывает дипазон от локальной сети (где действенность алгоритма подтвердил протокол RIP - см. RIP - Routing Information Protocol) до крупной межрегиональной стратегии маршрутизации, где число звеньев и стратегий превышает способности каждого маршрутизатора отображать всю сеть.

Алгоритм групповой маршрутизации «вектор дистанций» рассматривается в DVMRP - Distance Vector Multicast Routing Protocol.

Алгоритм «состояние каналов» основан на алгоритме кратчайшего пути Дийкстра. В последнее время он нашел достаточно широкое применение в Internet и OSI. Этот алгоритм позволяет сосредоточить вычисление отдельного маршрута в одном объекте маршрутизации - отправителе маршрута.

Каждый объект региона отправителя генерирует сообщение «состояние каналов», содержащее информацию о своем регионе, в том числе о наборе применимых им транзитных стратегий, о его связности со смежными регионами, и распространяет эти сообщения по соседним регионам. Каждый получатель такого сообщения запоминает маршрутную информацию в так называемой базе данных состояний каналов (link state database) и также распространяет ее по соседним регионам. Основываясь на совокупности сообщений «состояние каналов», полученных от других регионов, на транзитных стратегиях и стратегии отправителя своего региона, маршрутизирующий объект конструирует и выбирает стратегические маршруты из своего региона к другим регионам сети.

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

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

К достоинствам алгоритма «состояние каналов» можно отнести следующее.

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

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

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

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

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

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

Метода «маршрутизация отправителем» имеет следующие преимущества:

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

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

Групповая модель услуг IP была определена в конце 80-х годов и тогда же были созданы алгоритмы, которые позволяли хостам произвольно подключаться к группе и отключаться от нее. При групповой маршрутизации каждая группа адресатов представлена одним IP-адресом класса D. Датаграмма IP, переданная группе, доставляется каждому члену группы с теми же качественными показателями, что и при индивидуальной маршрутизации. Передатчик датаграммы не обязательно должен входить в группу маршрутизации и может находиться в другом регионе. Семантика членства группы маршрутизации IP определена в STD 5/RFC 1112.

Все ранее разработанные алгоритмы групповой маршрутизации строили деревья доставки с корнем у отправителя (source-based trees) при наличии одного дерева на каждую подсеть отправителя. Позже были разработаны алгоритмы (RFC 2189 и RFC 2201), строившие «дерево с центром», коллективно используемое всеми отправителями и получателями группы.

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

Все протоколы групповой маршрутизации используют IGMP - протокол, определенный в RFC 2236 и действующий между хостами и групповым(и) маршрутизатором(ами), относящимися к одной и той же подсети.

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

Совсем недавно, в RFC 2622, имеющем статус предложения по стандарту (Proposed Standard) определен язык спецификаци и стратегии маршрутизации (RPSL - Routing Policy Specification Language), который позволяет сетевому оператору определять стратегии маршрутизации на различных уровнях иерархии Internet, например, на уровне автономной системы RPSL построен таким образом, что вид глобальной стратегии маршрутизации может содержаться в одной коллективно поддерживаемой распределенной базе данных, обеспечивая целостность маршрутизации Internet. Из описания стратегии маршрутизации одной АС, описания маршрутизатора, интерфейсов и партнеров маршрутизатора может быть построена конфигурация конкретного маршрута. Язык RPSL является объектно ориентированным, то есть объекты содержат части информации по стратегии и административному управлению. Эти объекты регистрируются полномочными организациями в Регистре маршрутизации Internet (Internet Routing Registry, IRR). RPSL заменил действующий язык стратегий маршрутизации, известный под названием RIPE-181, определенный в RFC 1786, сняв многие ограничения последнего и обеспечив возможности расширения путем добавления новых протоколов и протокольных функций.

ПРОТОКОЛЫ МАРШРУТИЗАЦИИ

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

BGP - Border Gateway Protocol

Протокол BGP заменил и усовершенствовал прежний Exterior Gateway Protocols (EGP) (RFC 904/STD 18), переведя его в категорию «исторических». В настоящее время в стадии проектов стандартов, статус «избирательного применения» сохраняется версия 3 (BGP3) (RFC 1269) и вводится новая версия 4 (BGP4) (RFC 1657, 1771 и 1772) этого протокола. Кроме того, в стадии предложений по стандарту избирательного статуса разрабатываются дополнения к BGP4 по объединениям атрибутов (RFC 1997) и по мультипротокольному расширению, MBGP (RFC 2283 и 2545). Имеется также несколько экспериментальных расширений протокола (RFC 1965, 1966) и ряд документов информационного статуса.

BGP-4 - это протокол маршрутизации между АС, созданный для использования в больших сетях типа Internet или в очень крупных и территориально распределенных корпоративных сетях. Информация для сети включает полный перечень АС, через который должен пройти трафик для достижения данной сети. При использовании BGP АС объявляет соседним АС только те маршруты, которые она сама использует. Это правило отражает подход постадийной (hop-by-hop) маршрутизации, используемый в общем случае во всей современной Internet. Некоторые стратегии не могут использовать этот подход и требуют форсирования маршрутизатора со стороны отправителя. Например, BGP не позволяет одной АС передавать трафик соседней АС, если трафик первой имеет маршрут, отличный от трафика, выдаваемого соседней АС. С другой стороны, BGP может поддерживать любую стратегию, соответствующую подходу постадийной маршрутизации.

Протокол BGP способен обнаруживать зацикливания маршрутизации и имеет гибкие возможности определения стратегии маршрутизации и агрегатирования маршрутов, т.е. логического объединения следующих подряд сетей IP в одну «суперсеть» (агрегат), что позволяет значительно сокращать размеры таблиц маршрутизации. Основы агрегатирования маршрутов в Internet описаны в RFC 2519.

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

Сообщения BGP состоят из пар «номер сети»/«путь АС». Путь АС состоит из последовательности АС, через которые необходимо пройти, чтобы достичь данную сеть. Эти сообщения посылаются по протоколу ТСР.

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

Метрика BGP, называемая весом, указывает на степень предпочтительности данного пути. Как правило, вес присваивается администратором сети в процессе конфигурации. Степень предпочтительности может зависеть также от множества других параметров, таких как количество промежуточных АС, тип соединения (по степени стабильности, скорости, надежности) и т.п.

Несмотря на то, что BGP был разработан для маршрутизации между автономными системами, его версия IBGP может применятся для маршрутизации и в пределах одной автономной системы. Два соседних маршрутизатора, осуществляющие маршрутизацию между автономными системами, должны быть в общем случае подключены к одной физической сети, хотя имеется возможность объявлять соседями и не подсоединенные напрямую друг к другу маршрутизаторы (Next Hop BGP). Маршрутизаторы BGP, находящиеся в пределах одной АС, обмениваются информацией о наличии у них однозначного соответствия в маршрутизации по отношению к внешним АС и о том, какой из них обслуживает маршрутизацию с каждой из АС, известных обоим.

RIP - Routing Information Protocol

Версия 2 протокола передачи маршрутной информации RIP заменила и усовершенствовала версию 1 этого протокола (RFC 1058/STD 34), переведя ее в категорию «исторических». Версия RIP v2 определена в стадии проектов стандартов, статус «избирательного применения» (RFC 1722, 1723 и 1724). Кроме того, в стадии предложений по стандарту избирательного статуса разрабатывается ряд дополнений к RIP v2 (RFC 2080, 2082 и 2091). Имеется также несколько документов информационной стадии разработки.

RIP относится к протоколам IGP и использует алгоритм «вектора дистанций». Для передачи информации RIP использует транспорт UDP (порт 520).

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

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

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

И хотя RIP не предназначен для выполнения роли EGP, он иногда используется для маршрутизации между АС.

Центральные компьютеры (хосты) могут также использовать RIP как протокол распознавания маршрутизаторов. Такие компьютеры просматривают («слушают») проходящий трафик RIP и используют извлекаемую из него информацию распознавания маршрутов для принятия решения о выборе конкретного маршрутизатора для использования в качестве первой стадии.

К недостаткам RIP следует отнести.

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

2. При отключении сети маршрутизаторы не получают об этом своевременной информации.

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

И хотя новые более совершенные протоколы OSPF и IS-IS в целом превосходят RIP, в небольших сетях он имеет ряд преимуществ, обеспечивая там меньшую перегрузку с точки зрения используемой полосы пропускания и времени административного управления. RIP очень легко реализовать особенно в сравнении с новейшими IGP и затраты на него быстро окупаются.

Сообщение RIP содержит минимум маршрутной информации и большой объем свободного места, принадлежащего отправителю.

Кроме того, реализаций RIP гораздо больше, чем, например, комбинированного использования OSPF и IS-IS OSI. Ожидается, что использование RIP продолжится еще в течение нескольких лет.

OSPF - Open Shortest Path First

К настоящему времени протокол выбора кратчайшего пути OSPF определен стандартом избирательного статуса в RFC 2328/STD 54. Ряд дополнений и расширений протокола определен в проекте стандарта (RFC 1850), в нескольких предложениях по стандарту (RFC 1403, 1584, 1587, 1793) и документах экспериментальной стадии разработки (RFC 1765, 2154). Имеется также ряд информационных документов по OSPF. Положение о применимости OSPF приведено в RFC 1370.

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

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

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

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

OSPF обеспечивает:

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

Групповая (multicast) версия OSPF — MOSPF (RFC 1584) позволяет продвигать в пределах региона как групповые, так и индивидуальные пакеты IP. Маршрутизаторы MOSPF могут быть расположены вместе с OSPF в одном регионе маршрутизации и продвигать индивидуально адресуемые пакеты.

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

RAP - Internet Route Access Protocol

Протокол доступа к маршрутам RAP определен пока в единственном документе RFC 1476 и имеет экспериментальную стадию разработки.

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

Протокол RAP работает по TCP, порт 38, открывая с партнером симметричное соединение TCP между портами RAP каждой системы. Таким образом, между любой парой партнеров существует только одно соединение RAP.

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

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

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

Если RAP использует IPv7 [RFC 1475], адресуемую внутри АС, он действует по обеим версиям сетей IPv4 и IPv7 и коллективно использует маршрутную информацию между ними. Маршрутизатор IPv4 может только активизировать и распространять маршруты, которые определены в пределах локального административного региона, загружая подмножество адресов IP v4 в локальную базу данных продвижения IP.

DVMRP - Distance Vector Multicast Routing Protocol

Протокол групповой маршрутизации, работающий по алгоритму «вектор дистанций», DVMPR, определен в единственном документе RFC 1075 (1988 г.), который до настоящего времени сохраняет экспериментальную стадию разработки.

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

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

Для обмена датаграммами DVMRP использует протокол IGMP.

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

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

Чтобы данные проходили через сети, которые не обеспечивают групповой маршрутизации, был разработан специальный механизм, получивший название «туннельное прохождение» (tunneling). Туннельное прохождение - это метод передачи датаграмм между маршрутизаторами, разделенными шлюзами, которые не обеспечивают групповой маршрутизации. Этот механизм действует как виртуальная сеть между двумя маршрутизаторами, где «туннели» рассматриваются как переходное транспортное средство (transitional hack).

Туннельное прохождение выполняется со слабо инкапсулированной обычной групповой датаграммой. «Слабая (weakly) инкапсуляция» использует два специальных элемента IP, называемые «свободный маршрут отправителя» (loose source route). (Эта форма инкапсуляции предпочтительнее «строгой» инкапсуляции, т. е. предпочитающей инкапсуляцию всего нового заголовка IP, поскольку здесь оконечным пунктам «туннели» не требуется знать емкость буферов сборки друг друга.) «Туннель» имеет локальный оконечный пункт, удаленный оконечный пункт, метрику и связанное с ней пороговое значение. Маршрутизаторы на каждом конце туннели должны лишь согласовывать локальные и удаленные оконечные пункты. Поскольку многие промежуточные шлюзы между оконечными пунктами туннели неизвестны, то необходимы дополнительные исследования для определения подходящих метрик и пороговых значений.

Алгоритм групповой маршрутизации «вектор дистанций» (Distance-Vector Multicast Algorithm) строит дерево групповой доставки, используя вариант метода «продвижение по обратному пути» (Reverse-Path Forwarding). Этот метод состоит в следующем. Когда групповой маршрутизатор принимает групповой пакет данных, то если этот пакет поступает по интерфейсу, используемому для достижения отправителя пакета, пакет продвигается по всем исходящим интерфейсам за исключением лиственных подсетей, не имеющих подключенных объектов. («Лиственная» подсеть - это подсеть, которая не использует маршрутизатор для достижения отправителя группового пакета.) Если пакет данных поступает по каналу, отличному от того, который должен использоваться для достижения отправителя, пакет аннулируется.

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

Отправитель и получатель сообщения усечения должны поместить в кэш-память пару на время существования информации усечения, кратное минутам. Если только информация усечения маршрутизатора не обновлена получением нового сообщения усечения для до истечения «времени существования», эта информация удаляется, позволяя данным снова протекать по ветви. Состояние, которое истекает таким образом, называется «мягким состоянием» (soft state). Маршрутизаторы, которые не ведут к членам группы, могут подвергнуться перегрузкам состояния, обусловленных сообщениями усечения. При групповом распространении, которое потенциально должно обеспечивать многие тысячи активных групп, каждая из которых может быть рассредоточенно распределена, этот метод явно не в масштабе.

VRRP - Virtual Router Redundancy Protocol

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

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

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

Использование статически конфигурируемого маршрута по умолчанию минимизирует нагрузку оконечного хоста на создание конфигурации и обеспечивается, пожалуй, каждой реализацией IP. Предполагается, что этот режим работы найдет широкое применение с развитием протоколов динамической конфигурации со стороны хост [DHCP], которые обычно обеспечивают конфигурацию для IP адресов оконечных хостов и маршрутизаторов по умолчанию. Но использование этого метода создает проблему, называемую «единственный пункт неисправностей» (single point of failure). Потеря маршрутизатора по умолчанию может привести к катастрофическим результатам, изолировав все те оконечные хосты, которые неспособны обнаружить любой доступный альтернативный путь.

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

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

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

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

Первичный IP адрес - IP адрес, выбранный из набора адресов реального интерфейса. Алгоритм возможной выборки должен всегда выбирать первый адрес. Объявления VRRP всегда передаются с использованием первичного IP адреса как адреса отправителя IP -пакета

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

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

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

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

Резервирование (backup) IP адресов - это основная функция VRRP. Выбирая главный виртуальный маршрутизатор и дополнительные функции, протокол должен стремиться:

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

VRRP выполняет функцию, аналогичную протоколу Hot Standby Router Protocol (HSRP) фирмы Cisco Systems и протоколу IP Standby Protocol фирмы Digital Equipment Inc.

Разработанная версия VRRP предназначена для работы только с маршрутизаторами IPv4. При появлении необходимости в аналогичных функциях в среде IPv6 должна быть разработана отдельная спецификация.

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

Таблица демонстрирует о степень важности, которую придает Управляющий совет по архитектуре Internet (IAB) тому или иному классу протоколов. Следует, однако, заметить, что если большая часть протоколов передачи файлов, протоколов и опций Telnet была разработана в 70-е, 80-е годы, то по трем другим видам протоколов основная масса документов была издана в 90-е годы.

Об основных проблемах маршрутизации в Internet, которые тесно связаны с проблемами адресации, предложенных и реализуемых способах их решения подробно изложено в [2].

Литература

1. Николай Михайловский, Владимир Щербо «Протоколы и стандарты Internet: достижения и проблемы» Открытые системы, N2, 1999, с. 33 - 38
2. Владимир Щербо «Проблемы адресации в Internet» Data Communications, Russuian edition, N 3(9) 1999, с. 63 - 69