RFC: 1122
Оригинал: Requirements for Internet Hosts - Communication Layers
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых

2. Канальный уровень

2.1 Введение

Для всех систем Internet — хостов и маршрутизаторов — предъявляются одинаковые требования к протоколам канального уровня.

Эти требования подробно рассмотрены в главе 3 документа «Требования к маршрутизаторам» [RFC1009] и дополнены в настоящем документе.

2.2 Общие вопросы

Не рассматриваются.

2.3 Частные вопросы

2.3.1 Согласование трейлерного протокола

Для инкапсуляции на канальном уровне может использоваться трейлерный протокол (trailer protocol) [RFC893], но использование такого протокола должно быть согласовано обеими системами (хосты или маршрутизаторы), взаимодействующими на канальном уровне с применением трейлеров. Если системы не могут согласовать трейлерный протокол динамически (для каждого получателя), принятая по умолчанию конфигурация должна запрещать использование трейлеров.

  • Обсуждение:
  • Трейлерный протокол представляет собой метод инкапсуляции на канальном уровне, обеспечивающий перекомпоновку (rearrange) пакетов, передаваемых в физическую сеть. В некоторых случаях трейлеры повышают производительность протоколов верхних уровней за счет снижения объема копируемых данных. Протоколы верхних уровней не знают об использовании трейлеров, но приемник и передатчик пакетов должны понимать, какой протокол используется для инкапсуляции.

    Некорректное использование трейлеров может привести к серьезной путанице. С использованием трейлеров инкапсулируются только пакеты с заданным набором атрибутов и обычно этому требованию удовлетворяет лишь малая часть передаваемых пакетов. Таким образом, если одна система будет использовать трейлеры, а другая не будет, часть пакетов будет «улетать в черную дыру», а остальные будут доставляться нормально.

  • Реализация
  • В сетях Ethernet пакеты, инкапсулируемые с трейлерами, используют различные типы Ethernet [RFC893] и согласование трейлера выполняется одновременно с использованием протокола ARP для определения адреса получателя. Обмен пакетами ARP для определения адреса осуществляется обычным способом, но хост, согласующий трейлер, будет передавать дополнительный отклик ARP (trailer ARP reply), указывающий тип трейлерного протокола инкапсуляции в формате обычного отклика ARP. Если хост, настроенный на использование трейлеров, получает отклик ARP с типом трейлера от удаленной машины, он может добавить ее в список систем, поддерживающих трейлеры (например, пометив соответствующую запись в кэше ARP).

    Хосты, желающие использовать трейлерную инкапсуляцию передают отклик trailer ARP всякий раз при завершении нормального обмена ARP для IP-адреса. Таким образом, хост, получивший запрос ARP для своего IP-адреса, будет передавать отклик trailer ARP в дополнение к нормальному отклику IP ARP; хост, передавший запрос IP ARP, будет передавать отклик trailer ARP при получении отклика на запрос IP ARP. При таком способе как запрашивающий, так и отвечающий хост в процессе обмена пакетами IP ARP может запросить использование трейлерной инкапсуляции.

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

Страница 15 из 86

2007 - 2022 © Русские переводы RFC, IETF, ISOC.