Протокол 1смр
Протокол обмена управляющими сообщениями ICMP (Internet Control Message Protocol) описан в документе RFC 792. Этот протокол является вспомогательным в стеке TCP/IP. Протокол ICMP позволяет маршрутизатору сообщать конечной станции об ошибках или нештатных ситуациях, с которыми он столкнулся при передаче IP-дейтаграммы от этой станции. Тем не менее, протокол должен рассматриваться в качестве неотъемлемой части протокола IP и должен включаться в каждую его реализацию.
Сообщения ICMP передаются по сети в поле данных IP-дейтаграммы. Конечным получателем сообщений ICMP является модуль ICMP, входящий в состав программного обеспечения поддержки IP. Если ICMP определит, что ошибка была вызвана протоколом более высокого уровня или прикладной программой, он сообщит об этом соответствующему модулю, который связан с источником возникновения ошибки.
Протокол ICMP посылает два вида сообщений: управляющие сообщения и сообщения об ошибках. Эти сообщения могут быть посланы как на другие маршрутизаторы, так и на конечные станции. Протокол ICMP позволяет драйверам IP на разных устройствах обмениваться друг с другом управляющими и информационными сообщениями.
Протокол ICMP служит для сообщения об ошибках, но не для исправления ошибок. Отправитель сам должен определить источник ошибки и предпринять меры к устранению ошибок. При этом протокол ICMP не может использоваться для передачи сообщений об ошибках промежуточным устройствам. Это связано с тем, что IP-дейтаграмма содержит поля адреса отправителя и получателя не включает адресную информацию о промежуточных устройствах на маршруте движения по сети. Поэтому, когда IP-дейтаграмма приходит к одному из промежуточных маршрутизаторов, нельзя узнать, какой путь она прошла. Если маршрутизатор обнаружит ошибки, он не сможет узнать, какие промежуточные устройства обрабатывали эту IP-дейтаграмму, и поэтому не сможет сформировать сообщение об ошибке для передачи его промежуточным устройствам. Однако дейтаграмма не будет просто уничтожена. Маршрутизатор, используя протокол 1СМР, отошлет сообщение об ошибке отправителю для принятия обходимых мер по ее устранению.
Для транспортировки сообщений ICMP используется протокол IP, поскольку для достижения конечной станции сообщению может понадобиться пересечь несколько физических сетей. Поэтому адресация на физическом уровне невозможна. Дейтаграммы, несущие сообщение ICMP, маршрутизируются точно же, как и дейтаграммы с информацией для пользователей. Поэтому сообщения ICMP могут быть утеряны или удалены. Кроме того, сообщения об ошибках занимают определенную полосу пропускания сети.
Сообщения ICMP требуют двух уровней инкапсуляции. На рис. 6.9 показана схема инкапсуляции сообщений ICMP в IP-дейтаграмму.
Сообщения ICMP начинаются с трех одинаковых полей:
«Тип»,
«Код»,
«Контрольная сумма».
Кроме того, сообщения ICMP всегда включают заголовок и первые 64 бита данных дейтаграммы, вызвавшей ошибку. Это делается для более точного определения источника ошибок, так как у всех протоколов высокого уровня с TCP/IP критическая информация закодирована как раз в первых 64 битах.
Поле «Тип» (длиной 8 байт) определяет смысл сообщения и его формат (табл. 6.5).
Сообщения «Ответ на эхо» и «Запрос эха» (типы 0, 8) помогают сетевым администраторам и пользователям идентифицировать возникающие в проблемы. Эти сообщения очень часто используются при отладке сети. За эха и ответ на него применяются для проверки достижимости получателя дейтаграммы и его способности отвечать на запросы. Так как эхо переда в IP-дейтаграммах, то успешный прием ответа свидетельствует о том, что основные части транспортной системы работоспособны, то есть: маршрутизация выполняется, все промежуточные маршрутизаторы функционируют, получатель активен и работает корректно, программное обеспечение протоколов IP и ICMP выполняет свои функции. Во многих системах программа, которую пользователи используют для запроса эха, называется ping. На рис. 6.10 показан пример работы программы ping, входящей в стек протоколов Microsoft TCP/IP.
Таблица 6.5. Значения поля «Тип»
Значение поля
| Тип сообщения ICMP
|
0
| Ответ на эхо
|
3
| Получатель недостижим
|
4
| Подавление источника
|
5
| Изменение маршрута(переназначение)
|
8
| Запрос эха
|
11
| Время жизни дейтаграммы истекло
|
12
| Ошибка параметра
|
13
| Запрос временной метки
|
14 | Передача временной метки
|
17
| Запрос маски адреса
|
18
| Ответ на запрос маски адреса
|
На рис. 6.11 показан формат сообщений запроса эха и ответа на него.
С:\ping ds.internic.net
Pinging ds.internic.net [192.20.239.132] with 32 bytes of data:
Reply from 192.20.239.132: bytes=32 time=101ms TTL=243
Reply from 192.20.239.132: bytes=32 time=100ms TTL=243
Reply from 192.20.239.132: bytes=32 time=120ms TTL=243
Reply from 192.20.239.132: bytes=32 time=120ms TTL=243
Рис. 6.10. Пример работы программы ping
Тип - 8 или 0 (8 бит)
| Код - 0 (8 бит) | Контрольная сумма (16 бит)
|
Идентификатор (16 бит)
| Номер (16 бит)
| |
Необязательные данные
| ||
… |
Рис. 6.11. Формат сообщения запроса эха и ответа на него
Поле «Необязательные данные» имеет переменную длину и содержит данные, которые необходимо вернуть отправителю. Поля «Идентификатор» и «Номер» используются отправителем для проверки соответствия между запросом и ответом. Поле «Тип» определяет, является ли сообщение запросом (8) или ответом (0).
Сообщение «Получатель недостижим» (тип 3) посылается маршрутизатором, если он не может доставить IP-дейтаграмму по назначению. На рис. 6.12 показан формат этого сообщения.
Тип - 3 | Код - 0-12 | Контрольная сумма (16 бит) |
Не используется (должно быть равно 0) (32 бита) | ||
IP-заголовок и первые 64 бита исходной дейтаграммы | ||
… |
Рис. 6.12. Формат сообщения «Получатель недостижим»
Это сообщение содержит поле «Код», которое показывает, почему IP-дейтаграмму не удается доставить получателю (табл. 6.6).
Таблица 6.6. Причины невозможности доставки (поле «Код»)
Значение поля
| Причина
|
0
| Сеть недостижима
|
1
| Устройство недостижимо
|
2
| Протокол недостижим
|
3
| Порт недостижим
|
4
| Требуется фрагментация ,
|
5
| Сбой в маршрутизации при отправлении
|
6
| Сеть назначения неизвестна ,
|
7
| Устройство назначения неизвестно
|
8
| Отправитель изолирован
|
9
| Взаимодействие с сетью назначения административно запрещено
|
10
| Взаимодействие с устройством назначения административно запрещено
|
11
| Сеть недостижима из-за требований к классу обслуживания
|
12
| Устройство недостижимо из-за требований к классу обслуживания
|
Получатель дейтаграммы может быть недостижим по следующим причинам:
оборудование временно неработоспособно,
указан несуществующий адрес получателя,
маршрутизатор не имеет маршрута передачи,
сеть недостижима из-за чрезмерной удаленности и т. д.
В этом списке перечислены общие, наиболее часто встречающиеся причины по которым невозможно доставить информацию получателю.
Сообщение о подавлении источника (тип 4) требует от источника уменьшения скорости передачи дейтаграмм. Если дейтаграммы приходят на маршрутизатор быстрее, чем он успевает их обрабатывать, он временно ставит их в очередь (помещает в буфер). При полном заполнении буфера маршрутизатор будет вынужден удалять прибывающие дейтаграммы. В этом случае маршрутизатор посылает сообщение ICMP о подавлении источника. Сообщения посылаются при каждом удалении дейтаграммы. Отправитель дейтаграмм будет снижать скорость передачи до тех пор, пока к нему не перестанут поступать данные сообщения. На рис. 6.13 показан формат сообщений о подавлении источника.
Тип—4
| Код—0
| Контрольная сумма (16 бит)
|
Не используется (должно быть равно 0) (32 бита)
| ||
IP-заголовок и первые 64 бита исходной дейтаграммы
| ||
… |
Рис. 6.13. Формат сообщения «Подавление источника»
Сообщение ICMP об изменении маршрута (тип 5) посылается маршрутизатором в том случае, если отправитель дейтаграмм использует неоптимальный маршрут к получателю или при изменении топологии сети. При этом изменения в топологии могут быть постоянными (например, при добавлении новой подсети) или временными (например, при ремонте оборудования). Маршрутизатор также возвращает отправителю исходную дейтаграмму. Этот механизм позволяет отправителю не знать в начале работы ничего, кроме адреса одного маршрутизатора в сети. Этот маршрутизатор будет возвращать сообщение ICMP об изменении маршрута всякий раз, когда будет обнаружен более оптимальный путь к получателю. Эти данные заносятся в таблицу маршрутизации отправителя. Сообщения об изменении маршрута используются при взаимодействии между маршрутизатором и отправителем дейтаграмм в одной физической сети. На рис. 6.14 показан формат сообщения об изменении маршрута.
Тип - 5
| Код - 0-3 | Контрольная сумма (16 бит) |
IP-адрес рекомендуемого маршрутизатора (32 бита)
| ||
IP-заголовок и первые 64 бита исходной дейтаграммы
| ||
… |
Рис. 6.14. Формат сообщения «Изменение маршрута»
Каждое сообщение содержит 32-битовое поле «IP-адрес рекомендуемого маршрутизатора». Это поле содержит адрес маршрутизатора, который впредь должен использовать отправитель при отправке дейтаграмм по исходному IP-адресу. Поле «IP-заголовок и первые 64 бита исходной дейтаграммы» содержит заголовок IP и первые 64 бита дейтаграммы, которая вызвала сообщение ICMP. Отправитель из этой дейтаграммы выделяет адрес устройства, которое либо находится на неоптимальном маршруте, либо временно не работает. Поле «Код» в сообщении об изменении маршрута указывает более конкретную причину, которая привела к появлению этого сообщения (табл. 6.7). Например, код 0 означает недоступность участка сети, код 1 — недоступность устройства, коды 2 и 3 — невозможность предоставления сервиса и т. д.
Таблица 6.7. Поле «Код» в сообщениях «Изменение маршрута»
Значение поля
| Смысл сообщения
|
0
| Переадресация дейтаграммы для сети
|
1
| Переадресация дейтаграммы для устройства
|
2
| Переадресация дейтаграммы для типа сервиса и сети
|
3
| Переадресация дейтаграммы для типа сервиса и устройства
|
Сообщение ICMP «Время жизни дейтаграммы истекло» (тип 11) посылается отправителю при обнулении счетчика времени жизни дейтаграммы или при превышении времени ожидания формирования фрагментов дейтаграммы. Такие сообщения возникают при слишком длинном пути до получателя дейтаграммы, когда времени жизни дейтаграммы не хватает для прохождения всего пути. На рис. 6.15 показан формат сообщения о превышении времени.
Тип—11
| Код— 0-1
| Контрольная сумма (16 бит)
|
Не используется (должно быть равно 0)
| ||
Заголовок IP и первые 64 бита исходной дейтаграммы
| ||
… |
Рис. 6.15. Формат сообщения «Время жизни дейтаграммы истекло»
Поле «Код» объясняет причину возникновения сообщения (табл. 6.8).
Таблица 6.8. Поле «Код» в сообщениях «Время жизни дейтаграммы истекло»
Значение поля
| Смысл сообщения
|
0
| Время жизни дейтаграммы истекло
|
1
| Истекло время ожидания фрагмента при сборке
|
Сообщение ICMP «Ошибка параметра» (тип 12) посылается маршрутизатором при обнаружении неправильного параметра в заголовке, что не позволяет завершить обработку дейтаграммы. При этом дейтаграмма уничтожается. Одной из причин возникновения этих сообщений могут быть неправильные аргументы в поле «Опции» заголовка IP-дейтаграммы. Сообщение посылается только в том случае, если ошибка приводит к ликвидации дейтаграммы. На рис. 6.16 показан формат сообщения «Ошибка параметра».
Поле «Указатель» необходимо для идентификации ошибочного байта в дейтаграмме.
Сообщения ICMP «Запрос временной метки» (тип 13) и «Передача временной метки» (тип 14) необходимы для синхронизации часов в распределенной системе. Стек протоколов TCP/IP включает несколько протоколов, которые используются для синхронизации часов. Протокол ICMP предоставляет самый простой способ. Одно из устройств в сети посылает сообщение «Запрос временной метки» и ждет, пока другое устройство вернет в ответ текущее значение времени. На рис. 6.17 показан формат сообщений временных меток.
Тип - 12 | Код - 0-1 | Контрольная сумма (16 бит)
| |
Указатель (8 бит)
| Не используется (должно быть равно 0)
| ||
IP-заголовок и первые 64 бита исходной дейтаграммы
| |||
… |
Рис. 6.16. Формат сообщения «Ошибка параметра»
Тип - 13 или 14 | Код- 0
| Контрольная сумма (16 бит)
|
Идентификатор (16 бит)
| Номер (16 бит)
| |
IP-заголовок и первые 64 бита исходной дейтаграммы (32 бита)
| ||
Временная метка отправителя (32 бита)
| ||
Временная метка приема (32 бита)
| ||
Временная метка передачи (32 бита)
|
Рис. 6.17. Формат сообщений запроса и передачи временной метки
Поле «Тип» идентифицирует сообщение как запрос (13) или ответ (14). Поля «Идентификатор» и «Номер» используются источником для установления связи между ответами и запросами. Поле «Временная метка отправителя» — это время, которое зафиксировал отправитель непосредственно перед посылкой сообщения. Поле «Временная метка приема» содержит время, когда исходное сообщение дошло до получателя. Поле «Временная метка передачи» хранит время, когда получатель ответил на сообщение. Временные метки имеют размер 32 бита; в них записано время в миллисекундах, прошедшее после полуночи по Гринвичу. Получив эти метки, отправитель может вычислить время передачи по сети и разницу между своими часами и удаленными и выполнить синхронизацию своих часов. На практике бывает трудно точно оценить время передачи по сети. Поэтому для получения точной оценки потребуется выполнить множество измерений и усреднить их. Сообщение «Запрос маски адреса» (тип 17) необходимо для интерпретации адреса, а именно, для определения того, какие биты 32-битного IP-адреса соответствуют номеру сети, а какие — номеру устройства в ети. В ответ на сообщение передается 32-битная величина, называемая маской подсети. Ответ передается через сообщение «Передача маски адреса» (тип 18). Запрос может посылаться напрямую, если известен адрес маршрутизатора, или широковещательно. На рис. 6.18 показан формат сообщений запроса маски адреса и ответа на него.
Тип - 17 или 18 | Код(0) | Контрольная сумма (16 бит)
|
Идентификатор (16 бит)
| Номер (16 бит)
| |
Маска адреса (32 бита)
|
Рис. 6.18. Формат сообшений запроса и передачи маски адреса
Поле «Тип» в сообщении указывает, является ли сообщение запросом (17) или ответом (18). В поле «Маска адреса» помещается ответ на запрос.
- Максим Кульгин Технологии корпоративных сетей. Энциклопедия
- Часть I основы корпоративных сетей.
- 1. Базовые сетевые технологии
- Соединения и каналы
- Технологии b-isdn и atm
- Технология Frame Relay
- Технология isdn
- Плезиохронная и синхронная цифровые иерархии
- Технология sonet
- Технология smds
- Технология Ethernet
- Дальнейшее развитие технологии Ethernet
- Технология 100vg-AnyLan
- 2. Методология построения корпоративной сети
- Сравнение современных технологий передачи данных
- Требования к сети
- Архитектура сети
- Магистраль на базе коммутации ячеек
- Маршрутизация
- Коммутация
- Выделение маршрутов
- Сетевые шаблоны
- Сетевой шаблон глобальной сети
- Сетевой шаблон городской сети
- Шаблон городской сети с технологией sonet/sdh
- Шаблон городской сети с передачей atm поверх sonet/sdh
- Шаблон городской сети, как расширенной локальной сети
- Сетевой шаблон центрального офиса
- Реализация доступа и магистрали
- Критерии выбора технологии
- 3. Качество обслуживания в современных сетях
- Характеристики трафика
- Трафик разных приложений
- Качество обслуживания «на самоокупаемости»
- Обзор технологий качества обслуживания
- Обеспечение перекрывающей пропускной способности
- Приоритетные очереди в маршрутизаторах
- Протокол резервирования ресурсов
- Установление приоритетов в виртуальных сетях
- Качество обслуживания в сетях Frame Relay
- Качество обслуживания в сетях atm
- Рекомендации
- 4. Модель и уровни osi
- Эталонная модель osi
- Протоколы и интерфейсы
- Уровни модели osi Физический уровень
- Канальный уровень
- Сетевой уровень
- Транспортный уровень
- Сеансовый уровень
- Уровень представления
- Прикладной уровень
- Назначение уровней модели osi
- 5. Основные типы сетевых устройств
- Витая пара
- Коаксиальный кабель
- Оптоволоконный кабель
- Сетевые адаптеры
- Концентраторы
- Коммутаторы
- Коммутация «на лету»
- Коммутация с буферизацией
- Бесфрагментная коммутация
- Дополнительные функции коммутаторов
- Протокол stp
- Протокол stp и виртуальные сети
- Протокол stp: заключение
- Маршрутизаторы
- Брандмауэры
- Часть II стек протоколов тср/ip
- 6. Ip и другие протоколы нижнего уровня
- Протокол ip
- Протокол arp
- Протокол 1смр
- Протокол udp
- Протокол rtp
- Адресная схема протокола ip
- 7. Протокол tcp
- Формат заголовка
- Состояние системы
- Блок управления передачей
- Установление и закрытие соединений
- Плавающее окно
- Пропускная способность
- Контроль за перегрузками
- Управление потоком данных
- Политики отправки и приема сегментов
- Таймер повторной передачи
- Адаптивный таймер повторной передачи
- Узкие места в сети
- Протокол tcp в сетях atm
- 8. Маршрутицазия протокола ip
- Автономные системы
- Подсети
- Маска подсети
- Протокол rip
- Маска подсети переменной длины
- 9. Протоколы маршрутизации Протокол ospf
- Протоколы igrp и eigrp
- Протоколы политики маршрутизации egp и bgp
- Протокол igmp
- Алгоритмы построения дерева доставки
- Магистраль mbone
- Протоколы групповой маршрутизации Протокол dvmrp
- Протокол mospf
- Протокол рiм
- Бесклассовая междоменная маршрутизация
- Часть III Технология atm
- 10. Введение в технологию атм
- Появление atm
- Форум atm
- Основные компоненты atm
- Уровни atm
- Уровень адаптации atm
- Уровень atm
- Физический уровень
- Прямая передача ячеек
- Использование транспортных кадров
- Использование plcp
- Интерфейсы atm
- Мультиплексирование в сетях atm
- Инверсное мультиплексирование
- Безопасность в сетях atm
- Сигнализация atm
- 11. Основы технологии атм Соединения atm
- Сети без установления соединения
- Сети с установлением соединения
- Виртуальные соединения в сетях atm
- Типы виртуальных соединений
- Виртуальные пути и виртуальные каналы
- Установление соединений atm
- Ячейки atm
- Сети с передачей ячеек
- Формат ячеек atm
- Ячейки формата uni
- Ячейки формата nn1
- Подготовка ячеек к передаче
- Уровень адаптации aal1
- Уровень адаптации aal3/4
- Уровень адаптации aal5
- Адресация atm
- Адрес dcc aesa
- Адреса icd и е.164 aesa
- Управление адресами
- 12. Коммутация и маршрутизация в атм Коммутаторы atm
- Архитектура коммутаторов atm
- Интеграционные функции коммутаторов
- Управляемость
- Маршрутизация в atm
- Протокол маршрутизации запросов pnni
- Протокол сигнализации pnni
- Качество обслуживания
- Протокол tcp
- Протокол udp
- Резервирование ресурсов и протоколы управления потоком данных
- Организация очередей в маршрутизаторе
- Метод явного контроля скорости
- 14. Интегрированные и дифференцированные услуги Качество обслуживания
- Интегрированные услуги
- Сервисные уровни обслуживания
- Сервисное управление нагрузкой
- Гарантируемое обслуживание
- Протокол резервирования ресурсов rsvp
- Стили резервирования
- Развитие сетей с is
- Дифференцированные услуги
- Архитектура системы с предоставлением ds
- Граничные устройства домена ds
- Внутренние устройства домена ds
- Выходные домены
- Использование протокола rsvp в сетях с ds
- 15. Управление трафиком в атм
- Трафик-контракт
- Параметры трафика
- Категории сервиса
- Связь механизмов управления трафиком
- Контроль за установлением соединения
- Контроль за использованием полосы пропускания
- Формирование трафика
- Контроль потока abr
- Контроль приоритетов
- Организация очередей в коммутаторах
- Реализация очередей для службы ubr
- Реализация очередей для службы abr
- Методы отбрасывания пакетов
- Адаптивное управление буферами в коммутаторах
- 16. Интеграция с атм
- Протокол ip поверх atm
- Передача ip-Дейтаграмм по сети atm
- Взаимодействие устройств в одной логической подсети
- Групповая доставка информации в сети atm
- Взаимодействие устройств в разных логических подсетях
- Протокол nhrp
- Оценка потерь при работе протокола ip поверх atm
- Передача ip-дейтаграмм в кадрах sonet
- Технология эмуляции локальной сети — lane
- Концепция lane
- Технология мроа
- Клиент мроа
- Сервер мроа
- Взаимодействие технологий мроа и nhrp
- Масштабируемость в глобальных сетях
- Технология Tag Switching фирмы Cisco
- Технология aris фирмы ibm
- Технология mpls комитета ietf
- Перспективные разработки. Рекомендации
- Взаимодействие технологий atm и Frame Relay
- 17. Интеграция маршрутизации и коммуникации
- Общие вопросы выбора технологий
- Коммутирующие маршрутизаторы
- Коммутация третьего уровня в atm
- Технологии фирм Ipsilon и Toshiba
- Технология FastIp фирмы 3Com
- Технология NetFlow фирмы Cisco
- Технология SecureFast фирмы Cabletron
- Технология Multiprotocol Switched Services фирмы ibm
- 18. Мультимедиа в сети
- Передача видеоинформации
- Технические требования к передаче видеоинформации в сетях atm
- Некоторые рекомендации по созданию сетей atm с видео
- Передача голоса
- Часть V Приложения
- 1. Стандарты стека протоколов tcp/ip
- 2. Порты протоколов tcp и udp
- 3. Выделение ip - подсетей
- 4. Теория очередей и расчет параметров сети
- 5. Организации по стандартизации
- 6 Список фирм - членов Форума атм
- 7. Спецификации Форума атм
- 8. Список терминов
- 9. Список литературы Основная литература
- Дополнительная литература Технология atm и протокол ip поверх atm
- Технология качества обслуживания
- Система ip-адресаиии
- Некоторые ресурсы Internet
- Алфавитный указатель
- Оглавление
- Часть I 3
- Часть II 109
- Часть III Технология atm 207
- Часть IV 269
- Часть V Приложения 402