logo
адресация сетей

Ipx Адреса

Соответствие IPX и IPv6 адресов показано ниже на рис. 4.22:

Рис. 4. 22

Провайдерские глобальные уникаст-адреса

Глобальный уникаст-адрес провайдера имеет назначение, описанное в [ALLOC]. Исходное назначение этих уникаст-адресов аналогично функции IPv4 адресов в схеме CIDR [см. CIDR]. Глобальный IPv6 уникаст-адрес провайдера имеет формат, отображенный ниже на рис. 4.23

Рис. 4. 23 . Глобальный адрес провайдера

Старшая часть адреса предназначена для определения того, кто определяет часть адреса провайдера, подписчика и т.д.

Идентификатор регистрации определяет регистратора, который задает провайдерскую часть адреса. Термин "префикс регистрации" относится к старшей части адреса, включая поле идентификатор регистрации (ID).

Идентификатор провайдера задает специфического провайдера, который определяет часть адреса подписчика. Термин "префикс провайдера" относится к старшей части адреса включая идентификатора провайдера.

Идентификатор подписчика позволяет разделить подписчиков, подключенных к одному и тому же провайдеру. Термин "префикс подписчика" относится к старшей части адреса, включая идентификатор подписчика.

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

Локальные уникаст-адреса IPv6

Существует два типа уникастных адресов локального использования. Имеется локальные адреса сети и канала. Локальный адрес канала предназначен для работы с одним каналом, а локальный адрес сети - с одной локальной сетью (site). Локальный IPv6 уникаст-адрес канала имеет формат, отображенный ниже на рис. 4.24:

Рис. 4. 2 4. Локальный адрес канала

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

Рис. 4. 25 . Локальный адрес сети

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

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

Эникаст-адреса

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

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

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

Заметим, что в худшем случае префикс P эникастной группы (anycast set) может быть нулевым, т.e., члены группы могут не иметь никакой топологической локальности. В этом случае эникастный адрес должен объявляться как отдельная маршрутная единица (separate routing entry) по всему Интернет, что представляет собой серьезное ограничение, так как число таких "глобальных" эникастных адресов не может быть большим.

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

Существует ограниченный опыт широкого применения эникастных Интернет адресов, некоторые возможные осложнения и трудности рассмотрены в [anycst]. Имеются следующие ограничения при использовании эникастных IPv6 адресов:

Эникастный адрес не может использоваться в качестве адреса отправителя в ipv6 пакете.

Эникастный адрес не может быть приписан хост IPv6, таким образом, он может принадлежать только маршрутизатору.

Необходимые эникаст-адреса

Эникаст-адрес маршрутизатора субсети предопределен и имеет формат, отображенный на рис. 4.26:

Рис. 4. 26

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

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

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

Мультикаст-адреса

Мультикастинг-адрес IPv6 является идентификатором для группы узлов. Узел может принадлежать к любому числу мультикастинг групп. Мультикастинг-адреса имеют следующий формат (рис. 4.27):

Pис. 4.27

11111111 в начале адреса идентифицирует адрес, как мультикатинг-адрес.

Рис. 4. 28

Старшие 3 флага зарезервированы и должны быть обнулены.

t = 0 указывает на то, что адрес является стандартным ("well-known") мультикастным, официально выделенным для глобального использования в Интернет.

T = 1 указывает, что данный мультикастинг-адрес присвоен временно ("transient").

Поле scope представляет собой 4-битовый код мультикастинга, предназначенный для определения предельной области действия мультикастинг-группы. Допустимые значения:

0 зарезервировано

1 Область действия ограничена локальным узлом

2 Область действия ограничена локальным каналом

3 (не определено)

4 (не определено)

5 Область действия ограничена локальной сетью

6 (не определено)

7 (не определено)

8 Область действия ограничена локальной организацией

9 (не определено)

A (не определено)

B (не определено)

C (не определено)

D (не определено)

E глобальные пределы (global scope)

F зарезервировано

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

Значение постоянно присвоенного мультикастинг-адреса не зависит от значения поля scope. Например, если "NTP servers group" присвоен постоянный мультикастинг адрес с идентификатором группы 43 (hex), тогда:

ff01:0:0:0:0:0:0:43 означает, что все ntp серверы одного и того же узла рассматриваются как отправители.

FF02:0:0:0:0:0:0:43 означает, что все NTP серверы работают с тем же каналом, что и отправитель.

FF05:0:0:0:0:0:0:43 означает, что все NTP серверы принадлежат той же сети, что и отправитель.

FF0E:0:0:0:0:0:0:43 означает, что все NTP серверы находятся в Интернет.

Непостоянно выделенные мультикаст-адреса имеют значение только в пределах данного ограничения (scope). Например, группа, определенная непостоянным локальным мультикаст-адресом FF15:0:0:0:0:0:0:43, не имеет никакого смысла для другой локальной сети или непостоянной группы, использующей тот же групповой идентификатор с другим scope, или для постоянной группы с тем же групповым ID.

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

Предопределенные мультикаст-адреса

Приведенные ниже мультикаст-адреса являются зарезервированными (предопределенными):

ff00:0:0:0:0:0:0:0

FF01:0:0:0:0:0:0:0

FF02:0:0:0:0:0:0:0

FF03:0:0:0:0:0:0:0

FF04:0:0:0:0:0:0:0

FF05:0:0:0:0:0:0:0

FF06:0:0:0:0:0:0:0

FF07:0:0:0:0:0:0:0

FF08:0:0:0:0:0:0:0

FF09:0:0:0:0:0:0:0

FF0A:0:0:0:0:0:0:0

FF0B:0:0:0:0:0:0:0

FF0C:0:0:0:0:0:0:0

FF0D:0:0:0:0:0:0:0

FF0E:0:0:0:0:0:0:0

FF0F:0:0:0:0:0:0:0

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

Адреса для обращения ко всем узлам:

FF01:0:0:0:0:0:0:1

FF02:0:0:0:0:0:0:1

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

Адреса всех маршрутизаторов:

FF01:0:0:0:0:0:0:2

FF02:0:0:0:0:0:0:2

Приведенные выше мультикаст-адреса идентифицируют группу всех IPv6 маршрутизаторов в пределах области 1 (локальные узлы) или 2 (связанные локально узлы).

DHCP server/relay-agent: FF02:0:0:0:0:0:0:C

Приведенные выше мультикастинг-адреса идентифицируют группу всех IPv6 DHCP серверов и транзитных агентов в пределах области (scope) 2 (локальный канал).

Адрес активного узла (solicited-node): FF02:0:0:0:0:1:xxxx:xxxx

Приведенный выше мультикаст-адрес вычислен как функция уникастного и эникастного адресов узла. Мультикаст-адрес активного узла (solicited-node) сформирован из младших 32 бит адреса (уникастного или эникастного) добавлением 96 битного префикса FF02:0:0:0:0:1. В результате получен мультикастинг адрес, охватывающий интервал:

ff02:0:0:0:0:1:0000:0000

до

FF02:0:0:0:0:1:FFFF:FFFF

Например, код мультикаст-адреса активного узла (solicited node), соответствующий IPv6 адресу 4037::01:800:200E:8C6C, равен FF02::1:200E:8C6C. IPv6 адреса, которые отличаются только старшими разрядами, например, из-за множественных старших префиксов, соответствующих разным провайдерам, будут совпадать с адресом активного узла, что сокращает число мультикаст-групп, к которым узел должен присоединиться.

Необходимые адреса узлов

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

Её локальный адрес канала для каждого из интерфейсов

Выделенные уникаст-адреса

Адрес обратной связи

Мультикастинг-адрес для обращения ко всем узлам

Мультикастинг-адрес активного узла (solicited-node multicast address) для каждого из приписанных ей уникаст и эникастных адресов

Мультикаст-адреса всех групп, к которым принадлежит хост.

Маршрутизатор должен распознавать следующие адреса (as identifying itself):

Его локальный адрес канала для каждого из интерфейсов

Выделенные уникаст-адреса

Адрес обратной связи

Эникастные адреса маршрутизатора субсети для каналов, где он имеет интерфейсы.

Все другие эникастные адреса, которые использовались при маршрутизации.

Мультикастинг-адрес для обращения ко всем узлам

Мультикастинг-адрес для обращения ко всем маршрутизаторам

Мультикаст-адрес активного узла (solicited-node multicast address) для каждого приписанного ему уникаст и эникастного адресов.

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

Приложение должно предопределить только следующие адресные префиксы:

Не специфицированный адрес

Адрес обратной связи

Мультикаст-префикс (ff)

Локально используемые префиксы (link-local и site-local)

Предопределенные мультикаст-адреса

Префиксы, совместимые с IPv4

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

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

Однако, на широкое распространение новой версии IP потребуется несколько лет, поэтому в книге все примеры приводятся в схеме адресации IPv 4.

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

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

Чтобы придать этому направлению солидность, рядом разработчиков было создано Инициативное объединение по групповой IP-адресации. Список его членов включает всех основных производителей инфраструктурных сетевых компонентов (Bay Networks, Cabletron Systems, Cisco Systems, Intel и 3Com) и операционных систем (Hewlett-Packard, Microsoft, Silicon Graphics, Sun Microsystems и большинство остальных производителей ПО Unix), а также ряд других.

Метод многоадресатной рассылки IP является очень перспективным. Назначение метода многоадресатной рассылки состоит в уменьшении потребности в пропускной способности. В отличие от одноадресатных сообщений, передаваемых на отдельный хост, или широковещательных сообщений, которые принимаются всеми хостами, многоадресатные сообщения передаются отдельной группе хостов. Такой метод передачи данных является исключительно удобным в той ситуации, когда пользователи многих хостов одновременно запрашивают получение одних и тех же данных (например, потоковой видеопередачи). При использовании для этой цели широковещательных сообщений передаваемые пакеты пришлось бы обрабатывать на всех хостах и они заполнили бы все сегменты, напрасно расходуя пропускную способность и процессорное время. Кроме того, широковещательная рассылка может применяться только в локальных сетях. С другой стороны, при использовании одноадресатной рассылки пакет обрабатывается только указанным хостом, поэтому если одни и те же данные должны поступить на несколько хостов, то необходимо отправить такое же количество одинаковых пакетов; при этом бесполезно расходуется пропускная способность. При использовании многоадресатной рассылки передается только один пакет, но этот пакет принимается и обрабатывается всеми компьютерами той группы, для которой он предназначен. Схема использования многоадресатной рассылки показана на рис. 4.29.

Если бы в этом примере потоковая видеопередача осуществлялась по каналам распределенной сети с помощью одноадресатной рассылки, то пришлось бы отправлять отдельный поток данных на каждый хост, а это слишком расточительно. Если в данном случае требуется 128 Кбит/с для передачи каждого потока, то доставка информации на 100 хостов потребует общей пропускной способности 12 Мбит/с. Чтобы лишний раз подчеркнуть, почему эти расходы являются неоправданными, рассмотрим следующую ситуацию. Предположим, что все сотрудники компании смотрят в прямом эфире выступление своего старшего руководителя. Должна ли в таком случае передаваться на каждый компьютер отдельная версия этого выступления? К счастью, ответ на этот вопрос является отрицательным, и поток информации может одновременно доставляться на все компьютеры с помощью многоадресатной рассылки, что позволяет сократить потребность в пропускной способности.

Рис. 4.29 Пример применения многоадресатной рассылки

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

Групповая IP-адресация возможна при наличии трех компонентов, а именно: поддержки трансляции с третьего на второй уровень, динамического контроля принадлежности к группе и групповой маршрутизации.

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

Принципы организации многоадресатной рассылки

Основной принцип организации многоадресатной рассылки является весьма несложным. Хосты присоединяются к одной или нескольким многоадресатным группам с помощью межсетевого протокола управления группами ( Internet Group Management Protocol — IGMP ). Эти группы определяют, какой именно сеанс многоадресатного трафика им требуется (например, одна из видеопередач в прямом эфире). Любой хост, который присоединился к группе, начинает использовать многоадресатный адрес этой группы и принимает любой трафик, предназначенный для группы. Хосты могут присоединяться к группам или выходить из них динамически, поэтому состав членов группы постоянно меняется. Маршрутизаторы следят за составом группы и предпринимают попытки сформировать пути к членам многоадресатных групп, не содержащие циклов. При этом основное внимание уделяется тому, чтобы была исключена вероятность не­нужного дублирования пакетов. Программное обеспечение протокола IGMP следит также за тем, чтобы при отсутствии в какой-либо сети хостов, принадлежащих некоторой многоадресатной группе, была прекращена передача в эту сеть многоадресатных пакетов. Говорят, что при этом сеть отсекается от многоадресатной передачи.

Клиентская поддержка IGMP должна быть встроена в TCP/IP-стек вашего хоста (это требование выполнено в стеках Microsoft для Windows). Администратору, который готовит свою систему к внедрению новых мультимедийных коллективных приложений, в первую очередь следует поинтересоваться, обеспечивает ли предлагаемое ПО поддержку IGMP. Маршрутизаторы также должны поддерживать IGMP; большинство из них (от наиболее известных фирм) обеспечивают эту поддержку. Насчет коммутаторов поговорим чуть ниже.

Для передачи многочисленным маршрутизаторам, расположенным вдоль пути многоалресатной рассылки, информации о том, какие существуют многоадресатные группы и какие оптимальные пути могут применяться для передачи данных в эти группы, предназначены такие протоколы многоадресатной маршрутизации, как DVMRP ( Distance Vector Multicast Routing Protocol — протокол дистанционно-векторной маршрутизации трафика многоадресатной рассылки), MOSPF ( Multicast Open Shortest Path First — открытый протокол SPF многоадресатной рассылки) и PIM ( Protocol Independent Multicast — независимый от протокола метод многоадресатной рассылки). После поступления пакета в локальную сеть получателя может быть выполнена его лавинная рассылка по всем хостам, если в сети установлен коммутатор уровня 2 без средств поддержки многоадресатной рассылки, или выполнено перенаправление пакета только хостам, участвующим в группе, если используется коммутатор Cisco уровня 2 с поддержкой CGMP .

Протокол CGMP ( Cisco Group Management Protocol — протокол Cisco управления группами) используется коммутаторами Cisco уровня 2 для предотвращения лавинообразной рассылки многоадресатного трафика по всем сегментам. Поскольку IGMP — это протокол уровня 3, коммутаторы уровня 2 не могут использовать протокол IGMP для получения информации о хостах многоадресатной группы. Поэтому информация о составе многоадресатной группы передается на коммутаторы маршрутизаторами с помощью протокола CGMP . Это позволяет коммутаторам с поддержкой многоадресатной рассылки передавать многоадресатные пакеты только хостам, участвующим в группе.

Групповая адресация

Для сетевых протоколов необходимо отображение сетевого IP-адреса третьего уровня (согласно модели OSI) в аппаратный адрес второго уровня, в частности в MAC-адрес.

Для правильной организации функционирования многоадресатной рассылки предусмотрен целый ряд дополнений к протоколу IP и технологиям канального уровня. В частности, для обеспечения многоадресатной рассылки по локальной сети в программное обеспечение Ethernet необходимо включить дополнительные функции. Как правило, программное обеспечение Ethernet на компьютере принимает фрейм, только если заданный в нем МАС-адрес совпадает с МАС-адресом компьютера или представляет собой широковещательный МАС-адрес. А для обеспечения многоадресатной рассылки должен поддерживаться адрес нового типа — многоадресатный адрес. Этот адрес начинается с шестнадцатеричных цифр 01-00-5Е и заканчивается числом, соответствующим последним 23 битам IP -адреса многоадресатной группы. Следует отметить, что при использовании многоадресатной рассылки собственные адреса хостов не имеют значения. Хосты получают адрес, соответствующий многоадресатной группе и используют этот адрес.

IP -адреса, применяемые при многоадресатной рассылке, представляют собой адреса класса D . Некоторые адреса класса D зарезервированы, а диапазон от 226.0.0.0 до 231.255.255.255 формально не зарезервирован и может использоваться всеми. Каждый из них может быть рассмотрен в виде "канала" идентификации группы хостов, "заинтересованных" в получении конкретной информации одного и того же содержания. Например, сетевой администратор может направить видеоновости на групповой адрес 229.15.15.30, а видеоконференцию — на групповой адрес 229.15.15.31.

Последние 23 бита многоадресатного IP -адреса преобразуются в последние 23 бита многоадресатного МАС-адреса. Такое преобразование позволяет легко связать друг с другом многоадресатные МАС-адреса и IP -адреса.

На рабочих станциях должны быть установлены TCP/IP-стеки, поддерживающие групповую IP-адресацию и "понимающие" значение этого класса IP-адресов, а также позволяющие программировать ваш сетевой адаптер так, чтобы он правильно воспринимал запрашиваемые групповые адреса. Большинство TCP/IP-стеков (но не все) поддерживают групповую адресацию. Так, стеки Windows, как и некоторые TCP/IP-стеки ряда поставщиков ПО для Unix, поддерживают групповую адресацию. TCP/IP-стеки третьих фирм могут не поддерживать ее. Поэтому обязательно выясните, поддерживает ли ваш стек групповую адресацию. Кроме того, фактически все адаптеры Ethernet могут программироваться так, чтобы "слушать" несколько MAC-адресов, в частности свой собственный адрес, а также широковещательные MAC-адреса Ethernet.

Сетевые адаптеры Ethernet, идеально подходящие для использования в режиме групповой IP-адресации, должны допускать программирование TCP/IP-стека на несколько дополнительных МАС-адресов, благодаря чему компьютер может "слушать" не весь диапазон MAC-адресов, а только несколько групп одновременно. Таким образом, центральный процессор компьютера не тратит время на исключение "нежелательных" пакетов. Сами по себе сетевые адаптеры могут предоставлять такую возможность, однако из-за некачественных NDIS- или ODI-драйверов она может быть не реализована.

Динамический контроль принадлежности к группе

Одно из привлекательных свойств групповой IP-адресации — прохождение группового трафика только в тех подсетях, где он активно запрашивается одним или несколькими хостами. Перед передачей потока групповых сообщений в подсеть маршрутизатор "должен убедиться", что компьютеры данной подсети хотят получать его. Используя протокол управления группами Интернет (IGMP, RFC 1112), компьютеры динамически сообщают групповому маршрутизатору о том, в каких именно групповых сеансах они хотели бы участвовать. Если ни один из хостов данной подсети не зарегистрировался для участия в групповом сеансе через IGMP, трафик, переданный на этот групповой адрес, не направляется в данную подсеть, и тем самым экономится пропускная способность.

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

5 Адресация межхостового уровня

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

Для начала рассмотрим основы протоколов транспортного уровня.

5.1 Основы протоколов TCP и UDP

На транспортном уровне в Интернет работают протоколы UDP (без установления соединения) и TCP (с установлением соединения). Это два принципиально разных подхода к передаче данных. В обоих случаях и передатчик и приемник имеют индивидуальные IP-адреса и порты. Но в случае TCP они ассоциируются в соединители (socket) - две пары IP-адрес-порт и прием/передача в рамках одной сессии происходит по схеме точка-точка. Для UDP же допускается возможность передачи одновременно нескольким приемникам (мультикастинг) и прием данных от нескольких передатчиков в рамках одной и той же сессии. Протокол TCP используется для поточной передачи данных, при которой доставка гарантируется на протокольном уровне. Это обеспечивается обязательным подтверждением получения каждого пакета TCP. Напротив, протокол UDP не требует подтверждения получения. В этом случае, как правило, исключается также и фрагментация пакетов, так как пакеты при схеме без установления соединения никак не связаны между собой. По этим причинам UDP в основном служит для передачи мультимедийных данных, где важнее своевременность, а не надежность доставки. Протокол TCP используется там, где важна надежная, безошибочная доставка информации (файловый обмен, передача почтовых сообщений и WEB-технология).

Схема без установления соединения привлекательна также тем, что позволяет при передаче данных от исходного источника к большому числу приемников минимизировать общий трафик. Если бы для этой цели использовался протокол TCP, то при N приемниках надо было бы сформировать N виртуальных каналов и транспортировать N идентичных пакетов (рис. 5.1). В случае UDP от передатчика до точки разветвления передается только один пакет, что уменьшает загрузку данного участка в N раз (рис. 5.2). Причем аналогичная экономия может быть реализована и по пути к очередной точке разветвления (смотри описание протокола мультикастинг-

маршрутизации PIM).

Рис.5.1

Рис. 5.2.

В примере на рисунке 5.2 на участке 1 снижение трафика по сравнению с традиционным методом передачи данных происходит в 8 раз, на участке 2 - в 4 раза, а на сегментах 3 - в два раза.