Главная страница
Навигация по странице:

  • Рис. 18.16. Разделяемое дерево протокола PIM-SM

  • Порядок следования этапов не фиксирован. Например, источники группового вещания могут начать

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

  • Этап 2 — регистрация источника с построением дерева кратчайшего пути

  • Система адресации протокола IPv6

  • 1 В августе 1998 года были приняты пересмотренные версии группы стандартов, определяющих как общую архитектуру протокола IPv6 (RFC 2460), так и его отдельные аспекты, например, систему

  • Главной целью изменения системы адресации было не механическое увеличение адресного про­ странства, а повышения эффективности работы стека TCP/IP в целом.

  • Учебник для вузов в. Олифер Н. Олифер Компьютерные Принципы, технологии, протоколы


    Скачать 22.28 Mb.
    НазваниеУчебник для вузов в. Олифер Н. Олифер Компьютерные Принципы, технологии, протоколы
    АнкорOlifer_V_G__Olifer_N_A_-_Kompyuternye_seti_-_2010.pdf
    Дата12.03.2017
    Размер22.28 Mb.
    Формат файлаpdf
    Имя файлаOlifer_V_G__Olifer_N_A_-_Kompyuternye_seti_-_2010.pdf
    ТипУчебник
    #3698
    страница67 из 99
    1   ...   63   64   65   66   67   68   69   70   ...   99
    636
    Глава 18. Дополнительные функции маршрутизаторов ІР-сетей
    Главной особенностью протокола PIM-SM является то, что он рассчитан на работу в раз­
    ряженном режиме, то есть он посылает групповые пакеты только по явному запросу по­
    лучателя. Для доставки данных каждой конкретной группе получателей протокол PIM-SM строит одно разделяемое дерево, общее для всех источников этой группы (рис. 18.16).
    Рис. 18.16. Разделяемое дерево протокола PIM-SM
    Вершина разделяемого дерева не может располагаться в источнике, так как источников может быть несколько. В качестве вершины разделяемого дерева используется специ­
    ально выделенный для этой цели маршрутизатор, выполняющий функции точки встречи
    (RP). Все маршрутизаторы в пределах домена PIM-SM должны обладать согласованной информацией о расположении точки встречи. Различные группы могут иметь как одну и ту же, так и разные точки встречи.
    Самым распространенным и возможно самым простым способом конфигурирования локальных (в пределах одного домена PIM-SM) точек встречи является назначение их
    статически среди множества маршрутизаторов данного домена. Этб приводит к весьма определенной конфигурации и позволяет в дальнейшем легче находить ошибки, чем при других подходах.
    Для получателей каждой конкретной группы и источников, вещающих на эту группу, марш­
    рутизатор точки встречи является посредником, который связывает их между собой.
    Процесс доставки протоколом PIM-SM группового трафика от источника к получателям, принадлежащим некоторой группе, может быть представлен трехэтапным:
    1. Построение разделяемого дерева с вершиной в точке встречи, которое описывает пути доставки групповых пакетов между точкой встречи и членами данной группы. Это де­
    рево называют также деревом точки встречи (Rendezvous Point Tree, RPT).

    Групповое вещание
    637
    2. Построение дерева кратчайшего пути (Shortest Path Tree, SPT), которое будет достав­
    лять пакеты между источником данной группы и точкой встречи.
    3. Построение набора SPT-деревьев, которые ради повышения эффективности будут использованы для доставки пакетов непосредственно между источником и каждым из получателей группы.
    ПРИМЕЧАНИЕ--------------------------------------------------------------------------------------------------
    Порядок следования этапов не фиксирован. Например, источники группового вещания могут начать
    передачу до того, как появятся слушатели, заинтересованные в этом трафике, или дерево кратчайшего
    пути между источником и его слушателями может уже быть построенным, когда будет сделан новый
    запрос на присоединение к группе.
    Рассмотрим работу протокола PIM-SM на простом примере. На рис. 18.17 показана одно­
    доменная сеть, в которой прртокол PIM-SM устанавливает связь между одним получате­
    лем Л и одним источником 5. Будем считать, что работа сети соответствует модели ASM
    (групповое вещание из любого источника), на всех узлах сети развернут протокол IGMP и все маршрутизаторы поддерживают протокол PIM-SM. Будем считать также, что точка встречи сконфигурирована статически: и источники, и получатели знают индивидуальный адрес точки встречи, роль которой в этой сети играет маршрутизатор D. Для оповещения узлов сети об адресе точке встречи имеется стандартный протокол автоматического опо­
    вещения, называемый протоколом загрузки.
    В
    Этап 1 — построение разделяемого RPT-дерева от получателя к точке встречи. Когда раз­
    деляемое дерево уже построено, трафик группового вещания передается от точки встречи

    638
    Глава 18. Дополнительные функции маршрутизаторов ІР-сетей в направлении заинтересованных получателей. Однако процесс построения разделяемого дерева движется в обратном направлении — от получателей к точке встречи на основе по­
    шагового (hop-by-hop) подхода.
    Итак, пусть хост Л решает присоединиться к группе G, по этой причине он посылает IGMP- сообщениё отчета о членстве, содержащее адрес группы G, в локальную сеть, к которой он подключен. Это сообщение будет получено маршрутизатором С, через который данная локальная сеть подключена к другим сетям.
    Маршрутизатор С, получив от хоста А это IGMP-сообщение, посылает сообщение про­
    токола PIM-SM о присоединении (join) на индивидуальный адрес маршрутизатора Д выполняющего функции точки встречи. Это сообщение продвигается обычным образом на основе таблиц маршрутизации, построенных любыми протоколами маршрутизации. На всех промежуточных маршрутизаторах, расположенных вдоль пути от хоста-получателя к точке встречи, фиксируется состояние продвижения для данной группы. Каждый марш­
    рутизатор добавляет интерфейс, принявший сообщение протокола PIM-SM о присоедине­
    нии, к своему списку интерфейсов, через которые заинтересованным получателям может быть доставлен трафик группы, упомянутой в сообщении. В результате для данной группы формируется разделяемое дерево, и его корнем является точка встречи.
    В нашем примере на данном этапе нет активных источников, поэтому данные группового вещания еще не поступают к точке встречи (см. рис 18.17).
    Этап 2 — построение SPT-дерева от источника к точке встречи. Когда источник S стано­
    вится активным и начинает посылать пакеты с групповым адресом в свою локальную сеть, маршрутизатор F, к которому эта сеть непосредственно подключена, замечает, что источ­
    ник 5 стал источником группового вещания. Маршрутизатор F посылает РІМ-сообщение о регистрации (register) на индивидуальный адрес точки встречи (маршрутизатора D).
    При этом сообщение о регистрации инкапсулируется в пакет группового вещания от ис­
    точника S (рис. 18.18).
    Когда маршрутизатор D (точка встречи) получает сообщение о регистрации, он реагирует на это двумя действиями. Во-первых, он продвигает инкапсулированные данные группо­
    вого вещания по разделяемому дереву (RPT) от точки встречи до получателя, во-вторых, посылает РІМ-сообщение о присоединении назад по направлению к источнику с тем, чтобы создать дерево кратчайшего пути (SPT). Это сообщение передается от одного марш­
    рутизатора к другому, при этом информация о присоединении к группе фиксируется на соответствующих интерфейсах.
    Как только дерево кратчайшего пути от источника к точке встречи построено, маршрути­
    затор D начинает получать по две копии каждого пакета группового вещания. Одна копия приходит от источника 5 по вновь созданному кратчайшему пути, другая — от маршрути­
    затора F, который, продолжая реагировать на выявленную активность источника 5, снова посылает сообщение о регистрации, в котором в инкапсулированном виде содержится вторая копия группового пакета. Когда маршрутизатор точки встречи распознает эту си­
    туацию, он посылает маршрутизатору F сообщение с требованием прекратить регистрацию
    (register stop). Получив это сообщение для данной пары источник-группа, маршрутизатор F прекращает генерировать сообщения о регистрации и инкапсулировать в них групповые пакеты источника1. Вместо этого он начинает посылать их в исходном виде с групповым
    1 В дальнейшем маршрутизатор время от времени продолжит посылать одиночные сообщения о ре­
    гистрации до тех пор, пока источник остается активным.

    Групповое вещание
    639
    адресом, так как к этому моменту источник уже присоединился к дереву группы, и это присоединение зафиксировано на нужных маршрутизаторах.
    В
    Рис. 18.18.
    Этап 2 — регистрация источника с построением дерева кратчайшего пути
    Таким образом, поток данных группового вещания от источника S начинает передаваться по SPT-дереву до точки встречи, а затем далее от точки встречи по разделяемому дереву ко всем заинтересованным получателям (в том числе на маршрутизатор С, к которому подключен хост Л).
    Этап 3 — построение дерева кратчайшего пути от источника к получателю. Когда маршрутизатор С получает первый групповой пакет, он узнает из его заголовка 1Р-адрес отправителя, каковым в данном случае является источник S. На основании этого адреса маршрутизатор С пытается построить дерево кратчайшего пути непосредственно от ис­
    точника до самого себя. В нашем примере кратчайший путь — это путь через маршру­
    тизатор В. Маршрутизатор С посылает сообщение о присоединении маршрутизатору В, который затем, в свою очередь, посылает сообщение о присоединении маршрутизатору F.
    При этом каждый из них фиксирует интерфейс, на который он будет направлять пакеты да данной группы.
    Теперь, когда дерево кратчайшего пути для пары (источник 5, получатель Л) построено, маршрутизаторы F, В и С «ачинают продвигать пакеты группового вещания вдоль него.
    Когда пакеты начинают прибывать на маршрутизатор С, он обнаруживает по две копии каждого пакета — одна приходит по новому кратчайшему пути через маршрутизатор Б, другая по разделяемому дереву от маршрутизатора D. Чтобы прекратить дублирование, маршрутизатор С посылает PIM-сообщение об отсечении точки встречи (маршрутизато­
    ру D), который отсекает источник от разделяемого RPT-дерева (рис. 18.19).

    640
    Глава 18. Дополнительные функции маршрутизаторов ІР-сет
    В
    Рис. 18.19.
    Этап 3 — построение дерева кратчайшего пути от источника к получателю
    С этого момента маршрутизатор С получает только по одной копии каждого пакета от и точника 5 через свое отдельное дерево кратчайшего пути и передает его в локальную сет в которой находится получатель.
    Для упрощения мы описали случай, когда в сети имеется только одна точка встречи и с здается только одно разделяемое дерево. Однако технология допускает наличие в сет нескольких точек встречи. Решение о том, сколько в сети должно быть точек встречи и к; их расположить, составляет предмет планирования сети и протоколом PIM не опред ляется.
    Информацию об иерархическом подходе к орга­
    низации группового вещания вы можете найти на сайте
    www.olifer.co.uk
    в разделе «Междоменное групповое вещание».
    IPv6 как развитие стека TCP/IP
    В начале 90-х годов стек протоколов TC P/IP столкнулся с серьезными проблемами. Имеї но в это время началось активное промышленное использование Интернета: переход к m строению сетей предприятий на основе транспорта Интернета, применение веб-технолог* для доступа к корпоративной информации, ведение электронной коммерции через И] тернет, внедрение Интернета в индустрию развлечений (распространение видеофильмо звукозаписей, интерактивные игры).

    IPv6 как развитие стека TCP/IP
    641
    Все это привело к резкому росту числа узлов сети (в начале 90-х годов новый узел в Ин­
    тернете появлялся каждые 30 секунд), изменению характера трафика и ужесточению требований, предъявляемых к качеству обслуживания сетью ее пользователей.
    Сообщество Интернета, а вслед за ним и весь телекоммуникационный мир, начали ре­
    шать новые задачи путем создания новых протоколов для стека TCP/IP, таких как про­
    токол резервирования ресурсов (RSVP), защищенный протокол IP (IPSec), протокол коммутации меток (MPLS) и т. п. Однако ведущим специалистам было ясно, что только за счет добавления новых протоколов технологию T C P/IP развивать нельзя — нужно решиться на модернизацию сердцевины стека, протокола IP Некоторые проблемы нель­
    зя было решить без изменения формата IP-пакета и логики обработки полей заголов­
    ка IP-пакетов. Наиболее очевидной проблемой такого рода была проблема дефицита
    ІР-адресов, которую невозможно снять, не расширив размер полей адресов источника и приемника.
    Критике стала все чаще подвергаться масштабируемость маршрутизации. Дело в том, что быстрый рост сети вызвал перегрузку маршрутизаторов, которые должны уже сегодня об­
    рабатывать в своих таблицах маршрутизации информацию о нескольких десятках тысяч номеров сетей, да еще решать некоторые вспомогательные задачи, такие, например, как фрагментация пакетов. Некоторые из предлагаемых решений данной проблемы также требовали внесения изменений в протокол IP.
    Наряду с добавлением новых функций непосредственно в протокол IP, необходимо было обеспечить его тесное взаимодействие с новыми протоколами — членами стека TCP/IP, что также требовало добавления в заголовок IP новых полей, обработку которых осуществляли бы эти протоколы. Например, для работы RSVP было желательно введение в заголовок
    IP-поля метки потока, а для протокола IPSec — специальных полей для передачи данных, поддерживающих его функции обеспечения безопасности.
    В результате сообщество Интернета после достаточно долгого обсуждения решило под­
    вергнуть протокол IP серьезной переработке1, выбрав в качестве основных целей модер­
    низации:
    □ создание масштабируемой схемы адресации;
    □ сокращение объема работы, выполняемой маршрутизаторами;
    □ предоставление гарантий качества транспортных услуг;
    □ обеспечение защиты данных, передаваемых по сети.
    Система адресации протокола IPv6
    Новая (шестая) версия протокола IP (IPv6) внесла существенные изменения в систему адресации. Прежде всего, это коснулось увеличения разрядности адреса: вместо 4 байт
    IP-адреса в версии IPv4 в новой версии под адрес отведено 16 байт. Это дает возможность пронумеровать огромное количество узлов:
    340 282 366 920 938 463 463 374 607 431 762 211 456.
    1 В августе 1998 года были приняты пересмотренные версии группы стандартов, определяющих как
    общую архитектуру протокола IPv6 (RFC 2460), так и его отдельные аспекты, например, систему
    адресации (RFC 4291).

    642
    Глава 18. Дополнительные функции маршрутизаторов ІР-сетей
    Масштаб этого числа иллюстрирует, например, такой факт: если разделить это теоре­
    тически возможное количество ІР-адресов между всеми жителями Земли (а их сегодня примерно 6 миллиардов), то на каждого из них придется невообразимо, если не сказать бессмысленно большое количество ІР-адресов — 5,7 х 1028! Очевидно, что такое значи­
    тельное увеличение длины адреса было сделано не только и даже не столько для снятия проблемы дефицита адресов.
    Главной целью изменения системы адресации было не механическое увеличение адресного про­
    странства, а повышения эффективности работы стека TCP/IP в целом.
    Вместо прежних двух уровней иерархии адреса (номер сети и номер узла) в IPv6 имеется
    4 уровня, из которых три уровня используются для идентификации сетей, а один — для идентификации узлов сети. В новой версии не поддерживаются классы адресов (А, В, С,
    D, Е), но широко используется технология CIDR. Благодаря этому, а также усовершен­
    ствованной системе групповой адресации и введению адресов нового типа IPv6 позволяет
    снизишь затраты на маршрутизацию.
    Произошли и чисто внешние изменения — разработчики стандарта предложили исполь­
    зовать вместо десятичной шестнадцатеричную форму записи IP-адреса. Каждые четыре шестнадцатеричные цифры отделяются друг от друга двоеточием. Вот как, например, может выглядеть адрес IPv6: FEDC:0A98:0:0:0:0:7654:3210. Для сетей, поддерживающих обе версии протокола (IPv4 и IPv6), разрешается задействовать для младших 4 байтов традиционную для IPv4 десятичную запись: 0:0:0:0:0:FFFF:129.144.52.38.
    В новой версии IPv6 предусмотрено три основных типа адресов: индивидуальные адреса, групповые адреса и адреса произвольной рассылки. Мы уже обсуждали назначение этих типов адресов ранее. Тип адреса определяется значением нескольких старших битов адре­
    са, которые названы префиксом формата. Индивидуальные адреса делятся на несколько подтипов.
    Основным подтипом индивидуального адреса является глобальный агрегируемый уни­
    кальный адрес. Такие адреса могут агрегироваться для упрощения маршрутизации. В от­
    личие от уникальных адресов узлов версии IPv4, которые состоят из двух полей — номера сети и номера узла, — глобальные агрегируемые уникальные адреса IPv6 имеют более сложную структуру, включающую шесть полей (рис. 18.20).
    3
    13
    8
    24
    16
    64
    FP
    TLA
    NLA
    SLA
    Идентификатор
    интерфейса
    Рис. 18.20. Структура глобального агрегируемого уникального адреса в пакете IPv6
    □ Префикс формата (Format Prefix, FP) для этого типа адресов имеет размер 3 бита и значение 001.
    □ Поле TLA (Top-Level Aggregation, TLA) предназначено для идентификации сетей са­
    мых крупных поставщиков услуг. Конкретное значение этого поля представляет собой общую часть адресов, которыми располагает данный поставщик услуг. Сравнительно небольшое количество разрядов, отведенных под это поле (13), выбрано специально для ограничения размера таблиц маршрутизации в магистральных маршрутизаторах

    IPv6 как развитие стека TCP/IP
    643
    самого верхнего уровня Интернета. Это поле позволяет перенумеровать 8196 сетей поставщиков услуг верхнего уровня, а значит, число записей, описывающих маршру­
    ты между этими сетями, также будет ограничено значением 8196, что ускорит работу магистральных маршрутизаторов. Следующие 8 разрядов зарезервированы на будущее для расширения при необходимости поля TLA.
    □ Поле NLA (Next-Level Aggregation, NLA) предназначено для нумерации сетей средних и мелких поставщиков услуг. Значительный размер поля NLA позволяет путем агреги­
    рования адресов отразить многоуровневую иерархию поставщиков услуг.
    □ Поле SLA (Site-Level Aggregation, SLA) предназначено для адресации подсетей от­
    дельного абонента, например подсетей одной корпоративной сети.
    □ Идентификатор интерфейса является аналогом номера узла в IPv4. Отличием версии
    IPv6 является то, что в общем случае идентификатор интерфейса просто совпадает с его
    локальнымаппаратным) адресом, а не представляет собой произвольно назначенный администратором номер узла. Идентификатор интерфейса имеет длину 64 бита, что позволяет поместить туда МАС-адрес (48 бит), адрес конечного узла ATM (48 бит) или номер виртуального соединения ATM (до 28 бит), а также, вероятно, даст возможность использовать локальные адреса технологий, которые могут появиться в будущем. Такой подход делает ненужным протокол ARP, поскольку процедура отображения 1Р-адреса на локальный адрес становится тривиальной — она сводится к простому отбрасыванию старшей части адреса. Кроме того, в большинстве случаев отпадает необходимость
    ручного конфигурирования конечных узлов, так как младшую часть адреса — идентифи­
    катор интерфейса — узел узнает от аппаратуры (сетевого адаптера и т. п.), а старшую — номер подсети — ему сообщает маршрутизатор.
    Рассмотрим пример (рис. 18.21). Пусть клиент получил от поставщика ус луг пул адресов
    IPv6, определяемый префиксом 20:0А:00:С9:74:05/48. Поскольку первые три бита этого числа равны 001, это — глобальный агрегируемый уникальный адрес.
    1   ...   63   64   65   66   67   68   69   70   ...   99


    написать администратору сайта