Псевдозаголовок протоколов UDP и TCP. Управляющий протокол iсмp. Протоколы канального уровня для выделенных линий.

Псевдозаголовок протоколов UDP и TCP

Как сказано выше, при передаче данных от нижележащего межсетевого уровня на транспортный уровень в заголовки UDP-дейтаграмм и TCP-сегментов включается псевдозаголовок, который располагается перед основным заголовком транспортного уровня. Таким образом, блок данных транспортного уровня (UDP-дейтаграмма или TCP-сегмент) будет содержать (рис.4.64,а):

· псевдозаголовок длиной 12 байт или 3 32-разрядных слова;

· заголовок длиной 8 байт для UDP-дейтаграммы или 20 и более байт для ТСР-сегмента;

· данные.

Псевдозаголовок, формат которого показан на рис.4.64,б, содержит:

· IP-адрес отправителя;

· IP-адрес получателя;

· нулевое поле, не используемое и заполненное нулями;

· поле «Протокол», содержащее номер протокола транспортного уровня: 17 для протокола UDP и 6 для протокола ТСР;

· длина UDP-дейтаграммы или ТСР-сегмента.

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

Узел-отправитель при формировании ТСР-сегмента рассчитывает контрольную сумму сегмента с учётом псевдозаголовка. Однако при передаче по сети псевдозаголовок не включается в сегмент, что позволяет уменьшить накладные расходы и, соответственно, повысить эффективную скорость передачи пользовательских данных. В узле-получателе протокол IP формирует псевдозаголовок и вставляет его в поступивший сегмент и передаёт транспортному уровню.

Управляющий протокол IСМP

Internet Control Message Protocol (ICMP) – протокол межсетевых управляющих сообщений предназначен для выявления и обработки нештатных событий (например, потеря пакета), заключающейся в определении типа ошибки, формировании сообщения о ней и передаче этого сообщения приложению, сформировавшему пакет.

К основным функциям протокола ICMP относятся:

· обмен тестовыми сообщениями для выяснения наличия и активности узлов сети;

· анализ достижимости узла-получателя и сброс пакетов, направляемых к недостижимым узлам;

· изменение маршрутов;

· уничтожение пакетов с истекшим временем жизни;

· синхронизация времени в узлах сети;

· управление потоком путем регулирования частоты посылки пакетов узлами-источниками.

Основные типы ICMP-сообщений:

· «адресат недоступен» – пакет не может быть доставлен;

· «время истекло» – время жизни пакета достигло нуля;

· «проблема с параметром» – ошибка в поле заголовка;

· «переадресовать» – научить маршрутизатор;

· «запрос отклика» – запрос: жив ли компьютер?;

· «отклик» – да, жив.

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

ICMP-пакеты инкапсулируются в IP пакеты. ICMP является неотъемлемой частью IP, но при этом не делает протокол IP средством надёжной доставки сообщений. Для этих целей существует протокол TCP.

Протоколы канального уровня для выделенных линий должны:

· обеспечивать надежную передачу;

· предоставлять возможность управления потоком кадров для предотвращения переполнения соседних узлов.

Протоколы канального уровня:

· SLIP;

· протоколы семейства HDLC;

· РРР.

Протокол SLIP. Протоколы семейства HDLC.

Протокол SLIP

SLIP (Serial Line IP) – первый стандарт для протоколов TCP/IP, который может использоваться как для коммутируемых, так и для выделенных каналов ввиду простоты. SLIP поддерживается только протоколом сетевого уровня IP.

Основная и единственная функция протокола SLIP – распознавание начала и конца IP-пакета в потоке бит. Для этого в качестве границ IP-пакета используется специальный символ END (шестнадцатеричный код – С016).

Если в IP-пакете встречается код С016, то используется процедура байт-стаффинга (рис.4.66), заключающаяся в следующем. Код С016 заменяется на коды DB16 и DC16, а код DB16 заменяется на DB16 и DD16.

· отсутствие возможности обмениваться адресной информацией;

· использование только IP-пакетов в качестве содержимого SLIP-пакета;

· отсутствие процедур обнаружения и коррекции ошибок.

Протоколы семейства HDLC

HDLC (High-level Data Link Control Procedure) – высокоуровневый протокол управления каналом – стандарт ISO для выделенных линий.

Представляет собой семейство протоколов LAP (Link Access Protocol), включающее следующие протоколы:

· LAP-B – для сетей X.25 (B – Balanced);

· LAP-D – для сетей ISDN (D – D-channel);

· LAP-M – для модемов (M – Modem);

· LAP-F – для сетей Frame Relay (F – Frame Relay).

HDLC относится к бит-ориентированным протоколам и использует кадр, формат которого показан на рис.4.67.

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

Поле Адрес имеет длину 1 или 2 байта и при наличии нескольких узлов-приёмников используется для идентификации конкретного узла, а в двухточечном соединении – для того, чтобы отличить команды от ответов, а также для указания направления передачи кадра по интерфейсу «пользователь – сеть».

Поле Данные может быть любой длины и содержать пакеты протоколов вышележащих уровней. Это поле может отсутствовать в управляющих кадрах и некоторых ненумерованных кадрах.

Поле КС (контрольная сумма) содержит остаток избыточной циклической суммы, вычисленной с помощью полиномов типа CRC.

Поле У (управление) имеет длину 1 или 2 байта и содержит служебную информацию. Структура и содержимое этого поля зависят от типа передаваемого HDLC-кадра. Существуют 3 типа HDLC-кадров, различающиеся содержимым поля У (управление), показанного на рис.4.68:

· информационные кадры длиной 1 или 2 байта (рис.4.68,а), предназначенные для передачи данных пользователя;

· управляющие или супервизорные кадры длиной 1 или 2 байта (рис.4.68,б), предназначенные для передачи команд и ответов в процессе установленного логического соединения;

· ненумерованные кадры длиной 1 байт (рис.4.68,в), предназначенные для установления и разрыва логического соединения, а также информирования об ошибках.

Тип кадра определяется первыми битами поля управления: 0 – информационный кадр; 10 – управляющий кадр; 11 – ненумерованный кадр.

Протокол HDLC для обеспечения надёжности передачи данных использует механизм скользящего окна, ширина которого составляет:

· 7 кадров при длине поля управления в 1 байт;

· 127 кадров при длине поля управления в 2 байта.

Для реализации механизма скользящего окна в информационном кадре предусмотрено 2 поля:

· поле N(S), содержащее порядковый номер передаваемого кадра;

· поле N(R), содержащее номер очередного ожидаемого кадра.

Наличие этих двух полей связано с реализацией дуплексной передачи данных, а их длина определяет ширину окна в 7 (при длине 3 бита) или 127 (при длине 7 бит) кадров.

Бит P/F (Poll/Final – Опрос/Финал) используется для указания промежуточного (P) или последнего передаваемого (F) кадра. В некоторых случаях этот бит может использоваться для указания другому узлу о необходимости передать управляющий кадр, не ожидая попутного потока данных.

Управляющие кадры могут быть 4-х типов, которые различаются значением поля Type:

· Type=0 – подтверждение (RESEIVE READY – к приёму готов) – передаёт в поле N(R) номер следующего ожидаемого кадра и используется при отсутствии попутного потока данных для передачи подтверждения;

· Type=1 – отрицательное подтверждение (REJECT – отказ) – передаёт в поле N(R) номер неверно полученного кадра, начиная с которого узел-отправитель должен повторить передачу кадров;

· Type=2 – отказ (RESEIVE NOT READY – к приёму не готов) – означает, что в узле-получателе возникли проблемы, не позволяющие принимать кадры (например, переполнена буферная память) и, соответственно, узел-отправитель должен приостановить передачу кадров, при этом в поле N(R) указывается номер кадра, начиная с которого узел-отправитель в дальнейшем (после устранения причины приостановки приёма кадров) должен будет повторить передачу кадров;

· Type=3 – выборочное подтверждение (SELECTIVE REJECT – выборочный отказ) – передаёт в поле N(R) номер только того кадра, передачу которого узел-отправитель должен повторить.

Ненумерованные кадры применяются в основном для служебных целей, но могут переносить и данные, когда требуется ненадёжный не требующий соединения сервис. Поля Type и Modifier определяют типы и модификации команд, используемых двумя узлами на этапе установления соединения. Примерами таких команд могут служить:

· запрос на установление соединения с использованием двухбайтовых полей управления для информационных и управляющих кадров: SABME (Set Asynchronous Balanced Mode Extended – установить асинхронный сбалансированный расширенный режим);

· подтверждение установления или разрыва соединения: UA (Unnumbered Acknowledgment – ненумерованная положительная квитанция);

· запрос на разрыв соединения: REST (Resetting connection – сброс соединения).

Одна из основных функций протоколов семейства HDLC – восстановление искаженных и потерянных кадров (уменьшение вероятности искажения бита – BER с 10-3 – 10-4 до 10-9). Для современных каналов высокого качества, обеспечивающих значение BER=10-8 – 10-9, использование протоколов семейства HDLC на уровне моста или маршрутизатора становится нецелесообразным.