RFC-1042               A Standard for the Transmission of IP Datagrams over IEEE 802 Networks                        1988
Network Working Group                                                                                                                  J. Postel
Request for Comments: 1042                                                                                                J. Reynolds
ISI Взамен: RFC-948                                                                                                                        Февраль 1988
Стандарт передачи дейтаграмм IP в сетях IEEE 802 Статус документа
Этот документ описывает стандартный метод инкапсуляции дейтаграмм 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 для обеспечения интероперабельности между различными сетями описано не полностью, поскольку разработка стандарта еще не завершена1.
Описание
Сети IEEE 802 могут использоваться как IP-сети любого класса (A, B или C). Такие системы используют два поля LSAP (Link
Service Access Point - точка доступа к сервису канального уровня) заголовка LLC точно так же, как ARPANET использует поле
link. Кроме того, существует расширение заголовка LLC, называемое SNAP (Sub-Network Access Protocol - протокол доступа к
подсети).
Дейтаграммы 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.32 допускает скорости передачи от 1 до 20 Мбит/с, 802.4 задает скорости 1, 5, и 10 Мбит/с, а 802.5 -
1 и 4 Мбит/с. Типичными значениями скорости являются 10 Мбит/с для 802.3 и 802.4, 4 Мбит/с - для 802.5. Однако
спецификация передачи дейтаграмм IP не зависит от скорости передачи данных.
заголовка
MAC                                                                                                             802.{3/4/5} MAC
DSAP=K1           SSAP=K1             Control                                                                                                     802.2 LLC
Protocol ID или Org Code=K2                                  EtherType                                                      802.2 SNAP
Общий размер заголовков LLC и SNAP составляет 8 октетов, что обеспечивает выравнивание служебной информации
протокола 802.2 по удобной границе.
Значение K1 равно 170 (десятичное), K2 = 0 (нуль), а поле Control имеет значение 3 (беззнаковое целое).
Отображение 32-битовых адресов Internet в 16/48-битовые адреса IEEE 802 должно выполняться с помощью динамической
1    Сейчас этот стандарт ужепринят и широко используется.Прим. перев.
2    Современные редакции стандартов разрешают использование более высоких скоростей.Прим. перев.
Перевод на русский язык Н. Малых                                            1                                                               http://rfc.com.ru
RFC-1042
A Standard for the Transmission of IP Datagrams over IEEE 802 Networks
1988
процедуры обнаружения адресов ARP (Address Resolution Protocol - протокол преобразования адресов) [2]. Адреса Internet произвольным образом распределяются между сетями Internet. Каждая реализация хоста должна знать Internet-адрес хоста и отвечать на запросы ARP. При необходимости также должен использоваться протокол ARP для преобразования адресов Internet в адреса IEEE 802.
Детали ARP
Протокол ARP поддерживает несколько полей, задающих параметры использования для любого конкретного контекста [2]:
(бит)
Hardware Type Protocol Type -
hrd pro hln pln op
16 16
8 8 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]. Однако все хосты должны поддерживать стандартный метод инкапсуляции (без использования трейлеров).
Как описано в приложении Appendix 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 октета - 163 (ARP с 2-октетными аппаратными адресами и 4-октетными протокольными адресами) + 8 (заголовки LLC и SNAP) = 24 (не включая заголовок MAC).
В типичной ситуации размер пакетов ARP составляет 32 октета - 244 (ARP с 6-октетными аппаратными адресами и 4-октетными протокольными адресами) + 8 (заголовки LLC и SNAP) = 32 (не включая заголовок MAC).
Для пакетов IEEE 802 могут задаваться ограничения максимального размера. Каждая реализация должна поддерживать пакеты максимального размера.
Для совместимости максимальные размеры пакетов, используемых с дейтаграммами IP и запросами/откликами ARP должны соответствовать требованиям конкретной сети.
Реализации шлюзов должны быть способны воспринимать пакеты максимального размера5 и (при необходимости) фрагментировать их.
Реализации хостов должны быть способны воспринимать пакеты максимального размера, однако хост не должен передавать дейтаграмм, размер которых превышает 576 октетов, если с получателем явно не согласован иной размер. Хост может передать свои предпочтения в части ограничения размеров для приложений TCP с помощью опции TCP Maximum Segment Size [10]. Дейтаграммы в сетях IEEE 802 могут по размерам превышать общий для Internet максимальный размер пакетов (576 октетов). Хосты, подключенные к сети IEEE 802, должны принимать это во внимание при передаче дейтаграмм другим хостам, которые не входят в данную сеть IEEE 802. Может оказаться целесообразным снизить размер передаваемых дейтаграмм во избежание излишней фрагментации на промежуточных шлюзах (см. работу [10]).
3    В оригинале ошибочно указано значение 20. Прим. перев.
4    В оригинале ошибочно указано значение 28. Прим. перев.
5    Для каждой подключенной сети. Прим. перев.
Перевод на русский язык Н. Малых
2
RFC-1042               A Standard for the Transmission of IP Datagrams over IEEE 802 Networks                        1988
IEEE 802.2
Пока не требуется поддерживать IP и ARP, все реализации должны поддерживать стандартный сервис IEEE 802.2 Class I. Это
требует поддержки команд UI (Unnumbered Information), а также команд и откликов XID (eXchange IDentification) и TEST.
При получении команды XID или TEST должен возвращаться соответствующий отклик с перестановкой адресов отправителя и
получателя в полях DSAP и SSAP.
При отклике на команду XID или a 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 используется запись в виде 3 полей - первое поле указывает скорость (Мбит/с), второе - тип модуляции (среду) и третья - максимальную протяженность сегмента6 (в сотнях метров, округленно). Например, 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 (по всем маршрутам) имеет вид7:
01 012345678 90123 4 5 B                  LTH            D LF                 r
B - индикатор широковещания: 3 бита
Индикаторы Broadcast используются для того, чтобы показать желаемую маршрутизацию для отдельных кадров. Кадр может маршрутизироваться через один указанный путь, через любой неповторяющийся маршрут в сети с множеством колец или через один маршрут, определенный алгоритмом spanning tree так, что кадр появляется в каждом кольце ровно один раз. Для этих типов маршрутизации используются следующие двоичные значения:
6    Сейчас толькование этого обозначения расширено и появились новые обозначения, не включающие максимальную протяженность сегмента (например, 10BaseTX). Прим. перев.
7    Каждое число во второй строке представляет один бит.
Перевод на русский язык Н. Малых                                            3                                                               http://rfc.com.ru
RFC-1042                 A Standard for the Transmission of IP Datagrams over IEEE 802 Networks                           1988
000 - без широковещания (указанный маршрут) 100 - широковещание во все маршруты (глобальное) 110 - широковещание для одного маршрута (ограниченное) Все прочие значения этого поля зарезервированы для использования в будущем.
LTH
размер:
Биты Length используются для указания размера поля RI (маршрутная информация) с учетом полей RC и RD. Допускаются только четные значения от 2 до 30 (включительно).
D - направление: 1 бит
Бит D определяет порядок полей RD - если D = 1, поле обозначения маршрута задается в обратном порядке.
LF - наибольший кадр: 3 бита
Биты LF задают максимальное значение MTU, поддерживаемое всеми мостами по указанному маршруту. Все широковещательные кадры для множества колец должны передаваться со значением этого поля не меньше поддерживаемого MTU. Используются следующие обозначения:
LF (двоичное) 000
MAC MTU 552
IP MTU 508
001
1064
1020
_______010
011-
2088 4136
2044 4092
100
8232
8188
Остальные значения зарезервированы для использования в будущем.
Получатель должен сравнить принятое значение LF с MTU. Если LF DMTU, каких-либо операций не требуется, в противном
случае кадр отвергается.
При 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 не
Перевод на русский язык Н. Малых                                           4                                                               http://rfc.com.ru
RFC-1042               A Standard for the Transmission of IP Datagrams over IEEE 802 Networks                        1988
поддерживается, все пакеты с непустым полем RIF должны игнорироваться. Это правило будет обеспечивать
интероперабельность для всех реализаций в одном кольце независимо от поддержки расширения для множества колец.
При передаче запроса ARP с помощью широковещательного пакета all-routes возможно получение множества копий в
результате пересылки запроса через несколько мостов. Однако, такие копии придут по разным маршрутам и будут различаться
полями RIF. Реализация ARP в таком контексте должна выбрать одну из копий для использования, игнорируя прочие.
Существует три варианта стратегии для таких случаев: (1) взять первый пакет, игнорируя остальные (т. е. при наличии записи в
кэше ARP она не будет изменяться), (2) взять последний запрос (т. е. всегда обновлять кэш ARP по последнему сообщению
ARP) или (3) взять пакет, доставленный кратчайшим путем (т. е. обновить запись в кэше ARP, если новое сообщение
доставлено по более короткому маршруту). Поскольку выбор стратегии не влияет на интероперабельность, окончательное
решение остается за разработчиками. Получатель запроса ARP должен передать отклик ARP как сообщение точка-точка,
используя RIF.
Информация RIF должна сохраняться отдельно от таблицы ARP. Т. е., в принципе существует таблица ARP для отображения
адресов IP в 48-битовые адреса 802 и таблица RIF для отображения этих адресов в маршруты 802.5 source routes (при
необходимости). Для практической реализации может оказаться более удобным совместное хранение информации ARP и RIF.
Совместное хранение информации может ускорить доступ при ее использовании. С другой стороны, при реализации для всех
типов сетей 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 r SNAP
CO 55 F5 FD C7
11 GGOOOO
00000011-
3
SAP fo
01 01 01 01
1 01 01 01 0
170
XID
1111 Q1 Q1
1 o1o1111..
1 75
XID
191
TEST
11 000111
111 00011-
227
TEST
CF
11 GO1111
11110011...
243
Info
81 6000
1 29.1 Ю
Литература
[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                                                               http://rfc.com.ru
RFC-1042               A Standard for the Transmission of IP Datagrams over IEEE 802 Networks                        1988
[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-10108, USC/Information Sciences Institute, May 1987.
[8] Braden, R., and J. Postel, "Requirements for Internet Gateways", RFC-10099, 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.
8    Этот документ периодически обновляется. Современная версия представлена в RFC-1700. Прим. перев.
9    Этот документ в настоящее время утратил силу и заменене RFC-1812. Прим. перев.
Перевод на русский язык Н. Малых                                            6                                                               http://rfc.com.ru
Нежные и чувственные индивидуалки покажут вам все свои умения.