Network Working Group                                      J. Postel
Request for Comments: 1042                               J. Reynolds
                                                                 ISI
Взамен: RFC 948                                         Февраль 1988

 

Стандарт передачи дейтаграмм IP в сетях IEEE 802

A Standard for the Transmission of IP Datagrams over IEEE 802 Networks

PDF

Статус документа

Этот документ описывает стандартный метод инкапсуляции дейтаграмм IP [1] и протокол преобразования адресов ARP (Address Resolution Protocol) [2] в сетях IEEE 802. Документ задает стандартный протокол для сообщества Internet. Документ можно распространять без ограничений.

Благодарности

Этот документ не удалось бы создать без участия Дрю Перкинса (Drew Perkins) из университета Карнеги-Мэллона, Джэйкоба Рехтера (Jacob Rekhter) из Исследовательского центра T.J. Watson (корпорация IBM) и Джозефа Симино (Joseph Cimmino) из университета штата Мэриленд.

Введение

Целью этой спецификации является обеспечение совместимости и интероперабельности различных реализаций передачи дейтаграмм IP и запросов/откликов ARP¹. Для достижения этой цели в некоторых случаях может потребоваться ограничение использования IP и ARP требованиями конкретного стандарта IEEE 802.

Спецификации IEEE 802 задают группу стандартов для локальных сетей (LAN или ЛВС) на физическом и канальном (Data Link) уровнях эталонной модели ISO/OSI. Были определены несколько спецификаций для физического уровня (802.3, 802.4, и 802.5) [3,4,5] и одна спецификация (802.2) канального уровня [6]. Стандарты физического уровня IEEE определяют физический уровень и подуровень управления доступом к среде (MAC) канального уровня ISO/OSI. Стандарт канального уровня 802.2 описывает подуровень управления логическим каналом ISO/OSI.

В этом документе описано использование IP и ARP для трех типов сетей. В настоящее время не требуется согласования IP и ARP для всех трех типов сетей – достаточно согласованности внутри каждого из этих типов. Ситуация, однако, может измениться в будущем по мере разработки новых стандартов IEEE 802 и пересмотра существующих стандартов для обеспечения взаимодействия на канальном уровне.

Целью данного документа является описание использования IP и ARP, которое позволило бы обеспечить:

1. взаимодействие всего оборудования, использующего IP или ARP в сетях 802.3;

2. взаимодействие всего оборудования, использующего IP или ARP в сетях 802.4;

3. взаимодействие всего оборудования, использующего IP или ARP в сетях 802.5.

Задачей IP является обеспечение взаимодействия компьютеров, подключенных к различным сетям, когда эти сети соединены между собой с помощью шлюзов IP [8]. Использование прозрачных мостов IEEE 802.1 для взаимодействия между различными сетями описано не полностью, поскольку разработка стандарта еще не завершена².

Описание

Сети IEEE 802 могут использоваться как IP-сети любого класса (A, B или C). Такие системы используют два поля LSAP³ заголовка LLC точно так же, как ARPANET использует поле link. Кроме того, существует расширение заголовка LLC, называемое SNAP⁴.

Дейтаграммы IP передаются в сети IEEE 802 с инкапсуляцией в канальный уровень 802.2 LLC и SNAP, а также физические уровни 802.3, 802.4 или 802.5. SNAP используется с полем Organization Code, показывающим, что следующие 16 битов задают код EtherType (см. Assigned Numbers [7]).

Обычно весь обмен данными происходит с использованием 802.2 типа 1. Системы одной сети IEEE 802 (по согласованию) могут использовать 802.2 типа 2 после проверки поддержки этого типа на обоих узлах. Такое согласование обеспечивается за счет механизма 802.2 XID. Однако в настоящее время рекомендуется использовать тип 1 и этот тип должен поддерживаться во всех реализациях. В дальнейшем данная спецификация предполагает использование типа 1.

Сети IEEE 802 могут использовать адреса размером 16 или 48 битов. Данная спецификация позволяет применять адреса любого из этих размеров в данной сети IEEE 802.

Отметим, что стандарт 802.3⁵ допускает скорости передачи от 1 до 20 Мбит/с, 802.4 задает скорости 1, 5, и 10 Мбит/с, а 802.5 – 1 и 4 Мбит/с. Типичными значениями скорости являются 10 Мбит/с для 802.3 и 802.4, 4 Мбит/с – для 802.5. Однако спецификация передачи дейтаграмм IP не зависит от скорости передачи данных.

Формат заголовка

   ...--------+--------+--------+
              MAC Header        |                        802.{3/4/5} MAC
   ...--------+--------+--------+

   +--------+--------+--------+
   | DSAP=K1| SSAP=K1| Control|                                802.2 LLC
   +--------+--------+--------+

   +--------+--------+---------+--------+--------+
   |Protocol Id bkb Org Code=K2|    EtherType    |            802.2 SNAP
   +--------+--------+---------+--------+--------+

Общий размер заголовков LLC и SNAP составляет 8 октетов, что обеспечивает выравнивание служебной информации протокола 802.2 по удобной границе.

Значение K1 равно 170 (десятичное), K2 = 0 (нуль), а поле Control имеет значение 3 (беззнаковое целое).

Отображение адресов

Отображение 32-битовых адресов Internet на 16/48-битовые адреса IEEE 802 должно выполняться с помощью динамической процедуры обнаружения адресов ARP [2].

Адреса Internet произвольным образом распределяются между сетями Internet. Каждая реализация хоста должна знать Internet-адрес хоста и отвечать на запросы ARP. При необходимости также должен использоваться протокол ARP для преобразования адресов Internet в адреса IEEE 802.

Детали ARP

Протокол ARP поддерживает несколько полей, задающих параметры использования для любого конкретного контекста [2].

 

Поле	Размер (бит)	Название
hrd	16	Hardware Type – тип оборудования
pro	16	Protocol Type – тип протокола
hln	8	Число октетов каждого аппаратного адреса
pln	8	Число октетов каждого протокольного адреса
op	16	Код операции

 

Код типа оборудования для сетей IEEE 802 (всех типов) имеет значение 6 (см. [7], стр. 16), код типа протокола для IP равен 2048 (см. [7], стр. 14). Число октетов в аппаратном адресе составляет 2 или 6 для 16-разрядных и 48-разрядных адресов IEEE 802, соответственно. Размер протокольного адреса (для IP) равен 4. В качестве кода операции используется значение 1 (запросы) или 2 (отклики).

Широковещательные адреса

Широковещательные адреса Internet (адреса, в которых связанная с хостом часть содержит только 1) должны отображаться в широковещательные адреса IEEE 802 (только единицы), как указано в работе [8] (стр. 14).

Использование трейлеров

Некоторые версии Unix 4.x BSD используют иной метод инкапсуляции для обеспечения более высокой производительности при работе с архитектурой виртуальной памяти VAX. Системы одной сети IEEE 802 могут (по согласованию) использовать этот формат для обмена данными между собой. Подробное описание трейлерной инкапсуляции можно найти в работе [9]. Однако все хосты должны поддерживать стандартный метод инкапсуляции (без использования трейлеров).

Порядок битов

Как описано в Приложении B к спецификации протокола IP [1], дейтаграммы IP передаются через сети IEEE 802 в виде последовательности 8-битовых байтов. Используемый для передачи порядок битов называется «big-endian» [11].

Максимальный передаваемый блок (MTU)

Размеры максимального передаваемого блока (MTU) отличаются в разных типах сетей IEEE 802. Ниже рассмотрены значения MTU для всех типов сетей IEEE 802. Однако, в каждой конкретной сети все хосты должны использовать одинаковое значение MTU. В дальнейшем термины максимальный размер пакета (maximum packet size) и максимальный передаваемый блок (maximum transmission unit) используются как синонимы.

Формат кадров и уровень MAC

Для всех типов оборудования

IP-дейтаграммы и запросы/отклики ARP передаются в стандартном формате 802.2 LLC Type 1 Unnumbered Information (код управления 3) с полями DSAP и SSAP в заголовке 802.2, имеющими значение 170, и выделенным глобально значением SAP для поля SNAP [6]. 24-битовое поле Organization Code для SNAP имеет значение 0, а оставшиеся 16 битов содержат EtherType в соответствии с Assigned Numbers [7] (IP = 2048, ARP = 2054).

Для пакетов IEEE 802 может ограничиваться минимальный размер. При необходимости поле данных должно заполняться нулями для выполнения требований IEEE 802 в части минимального размера пакетов. Заполнение не является частью дейтаграммы IP и не учитывается полем размера в заголовке IP.

С целью обеспечения совместимости (и общности) для дейтаграмм IP устанавливается минимальный размер 28 октетов – 20 (минимальный размер заголовка IP) + 8 (заголовки LLC и SNAP) = 28 (не включая заголовок MAC).

Минимальный размер пакетов ARP составляет 24 октета – 16⁶ (ARP с 2-октетными аппаратными адресами и 4-октетными протокольными адресами) + 8 (заголовки LLC и SNAP) = 24 (не включая заголовок MAC).

В типичной ситуации размер пакетов ARP составляет 32 октета – 24⁷ (ARP с 6-октетными аппаратными адресами и 4-октетными протокольными адресами) + 8 (заголовки LLC и SNAP) = 32 (не включая заголовок MAC).

Для пакетов IEEE 802 могут задаваться ограничения максимального размера. Каждая реализация должна поддерживать пакеты максимального размера.

Для совместимости максимальные размеры пакетов, используемых с дейтаграммами IP и запросами/откликами ARP, должны соответствовать требованиям конкретной сети.

Реализации шлюзов должны быть способны воспринимать пакеты максимального размера⁸ и (при необходимости) фрагментировать их.

Реализации хостов должны быть способны воспринимать пакеты максимального размера, однако хост не должен передавать дейтаграмм, размер которых превышает 576 октетов, если с получателем явно не согласован иной размер. Хост может передать свои предпочтения в части ограничения размеров для приложений TCP с помощью опции TCP Maximum Segment Size [10].

Дейтаграммы в сетях IEEE 802 могут по размерам превышать общий для Internet максимальный размер пакетов (576 октетов). Хосты, подключенные к сети IEEE 802, должны принимать это во внимание при передаче дейтаграмм другим хостам, которые не входят в данную сеть IEEE 802. Может оказаться целесообразным снизить размер передаваемых дейтаграмм во избежание излишней фрагментации на промежуточных шлюзах (см. работу [10]).

IEEE 802.2

Пока не требуется поддерживать IP и ARP, все реализации должны поддерживать стандартный сервис IEEE 802.2 Class I. Это требует поддержки команд UI (Unnumbered Information), а также команд и откликов XID (eXchange IDentification) и TEST.

При получении команды XID или TEST должен возвращаться соответствующий отклик с перестановкой адресов отправителя и получателя в полях DSAP и SSAP.

При отклике на команду XID или TEST должно сохраняться значение бита poll/final (т. е. при получении команды с установленным битом poll/final должен передаваться отклик с битом poll/final).

Команды и отклики XID используют поле управления LLC = 175 (десятичное) при отсутствии бита poll и 191 (десятичное) при установленном флаге poll (см. Приложение).

Команды и отклики TEST используют для поля управления LLC значение 227 (десятичное) при отсутствии флага poll и 243 (десятичное) при установленном бите poll (см. Приложение).

Кадры команд идентифицируются старшим битом адреса SSAP (0), для кадров откликов старший бит адреса SSAP имеет значение 1.

Кадры откликов XID должны включать информационное поле 802.2 XID Information (129.1.0), указывающее сервис класса I (connectionless – без организации соединений), называемый также типом 1.

Кадры откликов TEST должны отражать (echo) информационное поле, полученное в кадре команды TEST.

IEEE 802.3

Для обозначения различных реализаций физического уровня IEEE 802.3 используется запись в виде трех полей – первое поле указывает скорость (Мбит/с), второе – тип модуляции (среду) и третья – максимальную протяженность сегмента⁹ (в сотнях метров, округленно). Например, 10BASE5 обозначает скорость передачи 10 Мбит/с в среде baseband при максимальной протяженности сегмента 500 метров (это соответствует исходной спецификации сетей Ethernet).

Заголовок MAC содержит 6 (2) октетов адреса отправителя, 6 (2) октетов адреса получателя и 2-октетное поле размера. Трейлер MAC содержит 4 октета контрольной суммы FCS (Frame Check Sequence), увеличивая общий размер до 18 (10) октетов.

Минимальный размер пакетов IEEE 802.3 зависит от скорости среды и для сетей 10BASE5 802.3 составляет 64 октета.

Максимальный размер пакетов в сетях IEEE 802.3 также зависит от скорости среды. Для сетей 10BASE5 802.3 максимальный размер пакетов составляет 1518 октетов, включая все поля между адресом отправителя и FCS (с учетом и этих полей).

Такое ограничение позволяет передавать дейтаграммы IP размером 1492 октета (с учетом заголовка IP) – 1518 – 18 (заголовок и трейлер MAC) – 8 (заголовок LLC и SNAP). Отметим, что значение 1492 отличается от принятого для сетей Ethernet значения MTU (1500).

IEEE 802.4

Заголовок MAC содержит 1 октет управления кадром, 6 (2) октетов адреса отправителя и 6 (2) октетов адреса получателя. Трейлер MAC содержит 4 октета контрольной суммы FCS), увеличивая общую длину до 17 (9) октетов.

В сетях IEEE 802.4 минимальный размер пакетов не задается.

Максимальный размер пакетов для сетей IEEE 802.4 составляет 8191 октет, включая все поля между адресом отправителя и FCS (с учетом и этих полей). Это позволяет передавать дейтаграммы IP размером 8166 октетов (с учетом заголовка IP) – 8191 – 17 (заголовок и трейлер MAC) – 8 (заголовок LLC и SNAP).

IEEE 802.5

Текущий стандарт для Token Ring – IEEE 802.5-1985 – описывает сети на базе одного кольца. Однако в большинстве реализаций 802.5 обеспечивается поддержка множества колец с использованием маршрутизации пакетов отправителем (source-routing) на уровне MAC. Существует дополнение (Draft Addendum) к спецификации IEEE 802.5 (Enhancement for Multi-Ring Networks – расширение для сетей с множеством колец), пытающееся стандартизировать такие расширения. К сожалению, последний вариант предварительного стандарта (10 ноября 1987) продолжает оставаться в таком статусе. Более того, эта спецификация достаточно сильно отличается от имеющихся реализаций. Поэтому существующие реализации 802.5 [13] описаны в спецификациях, но не делается попыток разработки новых вариантов стандарта.

Заголовок MAC содержит 1 октет управления доступом, 6 (2) октетов адреса отправителя, 6 (2) октетов адреса получателя и (для сетей с множеством колец) до 18 октетов RIF (Routing Information Field – поле маршрутной информации). Трейлер MAC содержит 4 октета FCS, увеличивая размер до 18 (10) – 36 (28) октетов. После FCS размещается дополнительный октет состояния кадра.

Поддержка множества колец

Присутствие поля RIF указывается старшим (MSB) битом адреса отправителя, называемым RII (Routing Information Indicator – индикатор маршрутной информации). Если RII = 0, поле RIF отсутствует, RII = 1 говорит о наличии поля RIF. Хотя RII входит в поле адреса отправителя, этот бит не является частью адреса MAC-уровня. Старший бит адреса получателя служит индикатором индивидуального/группового адреса (установка бита говорит о групповом адресе). При реализации следует принимать во внимание состояние бита RII на момент передачи адреса отправителя другим уровням, поскольку возможна трактовка этого бита как части адреса.

Поле RIF содержит 2-октетное поле управления маршрутизацией RC, за которым может следовать до 8 двухоктетных полей RD (Route-Designator – обозначение маршрута). Поле RC для широковещательных кадров all-routes (по всем маршрутам) имеет вид¹⁰

                         0                   1
                         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |  B  |   LTH   |D|  LF |   r   |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B – индикатор широковещания, 3 бита

Индикаторы Broadcast используются для того, чтобы показать желаемую маршрутизацию для отдельных кадров. Кадр может маршрутизироваться через один указанный путь, через любой не повторяющийся маршрут в сети с множеством колец или через один маршрут, определенный алгоритмом spanning tree так, что кадр появляется в каждом кольце ровно один раз. Для этих типов маршрутизации используются следующие двоичные значения:

000 – без широковещания (указанный маршрут);

100 – широковещание во все маршруты (глобальное);

110 – широковещание для одного маршрута (ограниченное);

Все прочие значения этого поля зарезервированы для использования в будущем.

LTH – размер, 5 битов

Биты Length используются для указания размера поля RI (маршрутная информация) с учетом полей RC и RD. Допускаются только четные значения от 2 до 30 (включительно).

D – направление, 1 бит

Бит D определяет порядок полей RD – если D = 1, поле обозначения маршрута задается в обратном порядке.

LF – наибольший кадр, 3 бита

Биты LF задают максимальное значение MTU, поддерживаемое всеми мостами по указанному маршруту. Все широковещательные кадры для множества колец должны передаваться со значением этого поля не меньше поддерживаемого MTU. Используются приведенные в таблице обозначения.

LF (двоичное)	MAC MTU	IP MTU
000	552	508
001	1064	1020
010	2088	2044
011	4136	4092
100	8232	8188

Остальные значения зарезервированы для использования в будущем.

Получатель должен сравнить принятое значение LF с MTU. Если LF не меньше MTU, каких-либо операций не требуется, в противном случае кадр отвергается.

При LF < MTU возможны три различных варианта. Первым (в соответствии с данной спецификацией) является отказ от кадра, второй вариант предполагает снижение MTU для всех хостов до значения LF, третий использует специальное значение MTU для обменивающихся информацией хостов на базе принятого значения LF.

r – резерв: 4 бита

Эти биты зарезервированы для использования в будущем. На передающей стороне эти биты устанавливаются в 0, а на приемной должны игнорироваться.

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

В сетях IEEE 802.5 не устанавливается минимального размера пакетов.

Максимальный размер пакетов IEEE 802.5 определяется на основе максимального времени, в течение которого хост может удерживать маркер. Это время зависит от множества факторов, включая скорость передачи и число хостов в кольце. Определение максимального размера пакетов дополнительно осложняется при использовании множества колец, соединенных мостами.

Для времени удержания маркера 9 мсек и скорости 4 Мбит/с, максимальный размер пакетов будет составлять 4508 с учетом всех октетов между полем управления доступом и FCS (включая эти поля). Это позволяет передавать дейтаграммы IP размером 4464 октета (с учетом заголовка IP) – 4508 – 36 (заголовок MAC и трейлер с 18 октетами RIF) – 8 (заголовок LLC и SNAP).

Однако, в некоторых реализациях размер пакетов ограничен значением 2046 октетов (2002 для IP). Поэтому для всех реализаций рекомендуется поддержка пакетов IP размером не менее 2002 октетов.

По согласованию мосты source routing, используемые в сетях 802.5 с множеством колец, могут не поддерживать пакеты, размер которых превышает 8232 октета. С учетом заголовков и трейлеров MAC (36 октетов) и заголовков LLC+SNAP (8 октетов) дейтаграммы IP (с учетом заголовка IP) не будут превышать размер в 8188 октетов.

Мост source routing, соединяющий два кольца, можно настроить на ограничение размера пакетов значением 552 октета. С учетом заголовка и трейлера MAC (36 октетов) и заголовка LLC+SNAP (8 октетов) размер дейтаграмм IP (с учетом заголовка IP) не будет превышать 508 октетов. Это меньше принятого по умолчанию значения IP MTU (576 октетов) и может привести к существенному снижению производительности за счет избыточного фрагментирования дейтаграмм. От реализаций не требуется поддержка MTU меньше 576 октетов, но должна приниматься во внимание возможность такого ограничения на уровне конфигурационных параметров.

Сети IEEE 802.5 поддерживают три различных типа широковещания. Широковещательные пакеты All-Stations передаются без RIF или с индикатором Broadcast = 0 и без RD, такие пакеты копируются однократно всеми станциями локального кольца. Широковещательные пакеты All-Routes передаются с соответствующим индикатором Broadcast и приводят к созданию множества копий по числу не совпадающих маршрутов, по которым пакет может быть передан в заданное кольцо. Широковещательные пакеты Single-Route приводят к получению одной копии кадра всеми станциями сети с множеством колец.

Процедура динамического обнаружения адресов использует широковещательную передачу запросов ARP. Для снижения числа широковещательных пакетов во все кольца желательно (хотя и не обязательно) передавать запрос ARP сначала в форме широковещательного пакета All-Stations, без поля RIF. Если широковещательные пакеты All-Stations (локальное кольцо) не поддерживаются или передача такого запроса не дает результата по истечении разумного времени, следует передать запрос ARP в форме широковещательного пакета All-Routes или Single-Route с пустым полем RIF (маршрут не обозначен). Пакеты All-Routes являются предпочтительными, поскольку это повышает устойчивость к отказам. В среде с множественными мостами и избыточными путями широковещательные пакеты All-Routes позволяют работать с использованием алгоритма spanning-tree при сбоях в мостах. Однако, могут применяться и пакеты Single-Route, если для IP и ARP должны использоваться однотипные форматы широковещания.

При получении запроса или отклика ARP все реализации должны понимать кадры без поля RIF (локальное кольцо) и с пустым полем RIF (также из локального кольца). Если реализация поддерживает source routing для множества колец, непустые RIF сохраняются для будущих передач хостам, отправившим исходный запрос или отклик ARP. Если source routing не поддерживается, все пакеты с непустым полем RIF должны игнорироваться. Это правило будет обеспечивать интероперабельность для всех реализаций в одном кольце независимо от поддержки расширения для множества колец.

При передаче запроса ARP с помощью широковещательного пакета All-Routes возможно получение множества копий в результате пересылки запроса через несколько мостов. Однако, такие копии придут по разным маршрутам и будут различаться полями RIF. Реализация ARP в таком контексте должна выбрать одну из копий для использования, игнорируя прочие. Существует три варианта стратегии для таких случаев: (1) взять первый пакет, игнорируя остальные (т. е. при наличии записи в кэше ARP она не будет изменяться), (2) взять последний запрос (т. е. всегда обновлять кэш ARP по последнему сообщению ARP) или (3) взять пакет, доставленный кратчайшим путем (т. е. обновить запись в кэше ARP, если новое сообщение доставлено по более короткому маршруту). Поскольку выбор стратегии не влияет на интероперабельность, окончательное решение остается за разработчиками. Получатель запроса ARP должен передать отклик ARP как сообщение точка-точка, используя RIF.

Информация RIF должна сохраняться отдельно от таблицы ARP. Т. е., в принципе существует таблица ARP для отображения адресов IP на 48-битовые адреса IEEE 802 и таблица RIF для отображения этих адресов на маршруты IEEE 802.5 source route (при необходимости). Для практической реализации может оказаться более удобным совместное хранение информации ARP и RIF.

Совместное хранение информации может ускорить доступ при ее использовании. С другой стороны, при реализации для всех типов сетей IEEE 802 может расходоваться значительное количество памяти для кэша ARP при резервировании в каждой записи этого кэша места для информации RIF.

Широковещательные дейтаграммы IP должны передаваться с использованием широковещательных кадров 802.5 single-route. В отличие от ARP, широковещательные кадры All-Routes являются нежелательными для IP. Получение множества копий широковещательных пакетов IP будет приводить к нежелательным эффектам для многих протоколов, использующих IP. Как и для случая ARP при получении пакета IP все реализации должны понимать кадры без RIF и с пустым полем RIF.

Поскольку современный аппаратный интерфейс допускает только один групповой адрес, а функциональные адреса не являются уникальными в глобальном масштабе, IP и ARP не используют эти возможности. Более того, сети типа IBM 802.5 поддерживают для пользовательского определения лишь 31 функциональный адрес.

Предпочтения IP должны отображаться на приоритеты 802.5. Все пакеты IP и ARP должны передаваться с принятым по умолчанию уровнем приоритета 802.5 (это значение равно 3).

После передачи пакета 802.5 обеспечивает индикацию невозможности скопировать кадр или распознать адрес. Эти индикаторы могут использоваться для обнаружения и исправления ошибок. Если установлен бит невозможности копирования кадра при отсутствии флага не распознанного адреса, это говорит о насыщении для получателя. Предполагается (но не требуется), что хост должен повторить передачу таких пакетов несколько (до 4) раз или пока не закончится состояние перегрузки. Если установлен бит не распознанного адреса, возможны три варианта реализации: (1) игнорировать ошибку и передать пакет заново, (2) возвратить сообщение ICMP destination unreachable отправителю пакета или (3) удалить запись ARP, которая была использована для передачи пакета и передать новый запрос ARP для адреса получателя. Последний вариант является предпочтительным, поскольку он обеспечивает более эффективное решение проблем при сбое моста или маршрутизатора на первом интервале или при смене аппаратных адресов.

Взаимодействие с Ethernet

Возможно использовать протокол канального уровня Ethernet [12] в одной физической среде с протоколом канального уровня IEEE 802.3. Подключенный к физической среде компьютер может принимать из сети оба типа пакетов (Ethernet и 802.3). Если компьютер воспринимает оба типа пакетов, он должен сохранять информацию об использовании протоколов канального уровня другими компьютерами в сети и передавать им пакеты в соответствующем формате.

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

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

Отметим, что MTU для Ethernet разрешает дейтаграммы IP размером в 1500 октетов, а MTU для сетей 802.3 допускает для дейтаграмм IP размер не более 1492 октетов.

Приложение. Числовые значения

IEEE указывает в своих спецификациях для передачи битов порядок little-endian (сначала младший бит). Для протоколов Internet в документах указывается порядок big-endian (сначала старший бит). Это различие может привести к недоразумениям при трактовке числовых значений. В таблице указаны соответствия для некоторых важных значений.

Число	IEEE		Internet
	16	2	2	10
UI Op Code	C0	11000000	00000011	3
SAP for SNAP	55	01010101	10101010	170
XID	F5	11110101	10101111	175
XID	FD	11111101	10111111	191
TEST	C7	11000111	11100011	227
TEST	CF	11001111	11110011	243
Info	818000			129.1.0

Литература

[1] Postel, J., “Internet Protocol”, RFC-791, USC/Information Sciences Institute, September 1981.

[2] Plummer, D., “An Ethernet Address Resolution Protocol – or – Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware”, RFC-826, MIT, November 1982.

[3] IEEE, “IEEE Standards for Local Area Networks: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications”¹¹, IEEE, New York, New York, 1985.

[4] IEEE, “IEEE Standards for Local Area Networks: Token-Passing Bus Access Method and Physical Layer Specification”¹, IEEE, New York, New York, 1985.

[5] IEEE, “IEEE Standards for Local Area Networks: Token Ring Access Method and Physical Layer Specifications”¹, IEEE, New York, New York, 1985.

[6] IEEE, “IEEE Standards for Local Area Networks: Logical Link Control”¹², IEEE, New York, New York, 1985.

[7] Reynolds, J.K., and J. Postel, “Assigned Numbers”, RFC-1010¹³, USC/Information Sciences Institute, May 1987.

[8] Braden, R., and J. Postel, “Requirements for Internet Gateways”, RFC-1009¹⁴, USC/Information Sciences Institute, June 1987.

[9] Leffler, S., and M. Karels, “Trailer Encapsulations”, RFC-893, University of California at Berkeley, April 1984.

[10] Postel, J., “The TCP Maximum Segment Size Option and Related Topics”, RFC-879, USC/Information Sciences Institute, November 1983.

[11] Cohen, D., “On Holy Wars and a Plea for Peace”, Computer, IEEE, October 1981.

[12] D-I-X, “The Ethernet – A Local Area Network: Data Link Layer and Physical Layer Specifications”, Digital, Intel, and Xerox, November 1982.

[13] IBM, “Token-Ring Network Architecture Reference”, Second Edition, SC30-3374-01, August 1987.

Перевод на русский язык

Николай Малых

nmalykh@gmail.com