Сетевой уровень может столкнуться с проблемами при попытке переадресации пакета, поэтому ему нужен способ сообщить об этой проблеме.
Сетевой уровень находится в уникальном неудобном положении, когда это происходит, поскольку обычный метод отчетности (возврат значения статуса в программу более высокого уровня, запросившую эту операцию) может быть недоступен. Промежуточный маршрутизатор получает пакет с канального уровня ниже, и ожидается, что он будет пересылать этот пакет через другой канальный уровень. Даже если в маршрутизаторе есть более высокий уровень, этот уровень, вероятно, не заинтересован в этом пакете. Вместо этого, субъектом, которому нужно услышать о проблеме, скорее всего, будет программа верхнего уровня, которая создала пакет, и эта программа может быть расположена в нескольких шагах от другого компьютера. Даже сетевому уровню на адресе назначения может понадобиться сообщить оригинальному отправителю о чем-то, например, об отсутствии обработчика верхнего уровня для типа end-to-end, который был указан отправителем. Очевидно, что нужно послать сигнал организации, которая должна знать о проблеме. Обычный метод заключается в том, что сетевой уровень маршрутизатора создает новый пакет на месте и отправляет его обратно на адрес источника, указанный в проблемном пакете. Сообщение в этом новом пакете сообщает подробности проблемы, используя стандартный протокол сообщения об ошибках. При такой конструкции ожидается, что отправитель пакета более высокого уровня будет прослушивать не только ответы, но и сообщения протокола сообщения об ошибках. Ниже приведены некоторые типичные отчеты об ошибках:
- Буферы маршрутизатора были заполнены, поэтому пакет пришлось отбрасывать.
- Буферы маршрутизатора полностью перестают посылать столько пакетов.
- Часть целевого адреса с идентификатором региона не существует.
- Идентификатор узла части целевого адреса не существует.
- Идентификатор типа конца не был распознан.
- Пакет больше, чем максимальная единица передачи по следующему каналу связи.
- Пакетный предел прыжка превышен.
Кроме того, копия заголовка обреченного пакета попадает в поле данных сообщения об ошибке, чтобы получатель мог сопоставить его с выдающимся SEND запросом.
Можно предположить, что маршрутизатор посылает сообщение об ошибке при отбраковке пакета, полученного с неправильной контрольной суммой. Эта идея не так хороша, как кажется, потому что поврежденный пакет может содержать искаженную информацию заголовка, и в этом случае сообщение об ошибке может быть отправлено в неправильное или даже несуществующее место. После того, как пакет идентифицирован как содержащий неизвестные повреждения, не стоит предпринимать какие-либо действия, зависящие от его содержимого.
Протокол сообщения об ошибках на сетевом уровне немного необычен. Сообщение об ошибке появляется на сетевом уровне, но передается на сквозной уровень. Поскольку он пересекает слои, это может рассматриваться как нарушение (в незначительной степени) обычного разделения слоев: у нас есть программа сетевого уровня, готовящая сквозной заголовок и вставляющая сквозные данные; строгая доктрина уровня настаивает, чтобы сетевой уровень не касался ничего, кроме заголовков сетевого уровня.
Протокол сообщения об ошибках обычно определяется как наиболее эффективный, а не как протокол, требующий героических усилий для передачи сообщения. Есть две причины, по которым такое проектное решение имеет смысл. Во-первых, внедрение более надежного протокола добавляет достаточное количество механизмов: таймеры, хранение копий сообщений в случае необходимости их повторной передачи и наблюдение за получением подтверждения. Сетевой уровень обычно не оборудован для выполнения ни одной из этих функций, и невыполнение этих функций сводит к минимуму нарушение разделения уровней. Во-вторых, сообщения об ошибках можно рассматривать как подсказки, которые позволяют создателю пакета быстрее обнаружить проблему. Если сообщение об ошибке теряется, создатель должен, так или иначе, в конечном итоге обнаружить проблему каким-либо другим способом, возможно, после отсчета времени, повторной отправки первоначального пакета и получения сообщения об ошибке при повторной попытке.
Хорошим примером наиболее эффективной работы протокола отчетности об ошибках является то, что обычно не отправлять сообщения об ошибках о каждом отбракованном пакете; если перегрузка приводит к увеличению количества выбракованных пакетов, то это как раз неподходящее время для увеличения загрузки сети путем отправки многих уведомлений "Я отбраковал ваш пакет". Однако отправка нескольких таких уведомлений может помочь предупредить источники, наводняющие сеть, о том, что им необходимо отступить.
Основная идея протокола сообщения об ошибках может быть использована для других коммуникаций с сетевым уровнем любого участника сети и обратно. Например, Интернет имеет протокол под названием ICMP (Internet control message protocol), который включает в себя сообщение эхо-запроса (также известное как "ping", по аналогии с активными сонарными системами подводных лодок). Если конечный узел посылает эхо-запрос любому участнику сети, будь то переадресатор пакетов или другой конечный узел, ожидается, что сетевой уровень этого участника немедленно ответит, отправив данные сообщения обратно отправителю в сообщении эхо-ответа. Сообщения эхо-запроса/ответа широко используются для определения того, действительно ли участник готов к работе или нет. Они также иногда используются для оценки перегруженности сети путем измерения времени до получения ответа.
Еще один полезный отчет об ошибке сети - "Превышение предела прыжка". Для обеспечения защиты от циклов пересылки пакет может содержать поле ограничения прыжка, которое уменьшается маршрутизатором в каждом пакете, который он пересылает. Если маршрутизатор обнаруживает, что поле предела перехода содержит ноль, он выбрасывает пакет, а также отправляет обратно сообщение, содержащее отчет об ошибке. Сообщение об ошибке "Предел прыжка превышен" обеспечивает обратную связь с создателем, например, он мог выбрать слишком маленький предел прыжка для конфигурации сети. Сообщение об ошибке "Превышение предела перехода" также может быть использовано интересным образом для определения местонахождения проблем сети: отправьте тестовое сообщение (обычно называемое зондом) на удаленный адрес назначения, но с пределом перехода, установленным на 1. этот зонд заставит первый маршрутизатор, который увидит его, отправить назад сообщение "Превышение предела перехода", чей адрес источника идентифицирует этот первый маршрутизатор. Повторите эксперимент, отправив зонды с пределом перехода 2, 3 и т.д. Каждый ответ будет показывать сетевой адрес следующего маршрутизатора по текущему пути между источником и получателем. Кроме того, время, необходимое для возврата ответа, дает приблизительное представление о нагрузке на сеть между источником и маршрутизатором. Таким образом, можно проследить текущий путь через сеть до адреса назначения и определить точки заторов.
Другим способом использования протокола сообщения об ошибках является отправка на сквозной уровень серии датчиков для изучения наименьшего максимального количества передающего устройства (MTU), расположенного на текущем пути между ним и другой точкой сетевого подключения. Сначала он посылает пакет самого большого размера, который есть в виду у приложения. Если этот датчик выдаст ответ на ошибку "MTU превысил", он вдвое уменьшит размер пакета и повторит попытку. Продолжающийся двоичный поиск быстро вернется домой в самом маленьком MTU на этом пути. Эта процедура известна как обнаружение MTU.
