RFC 894 A Standard for the Transmission of IP Datagrams over Ethernet Networks

Network Working Group                                       Charles Hornig
Request for Comments: 894              Symbolics Cambridge Research Center
                                                                April 1984

PDF

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

A Standard for the Transmission of IP Datagrams over Ethernet Networks

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

В этом RFC описывается стандартный метод инкапсуляции дейтаграмм IP [1] в кадры Ethernet [2]. RFC содержит спецификацию стандарта для сообщества ARPAInternet.

Введение

Этот документ относится к сетям Ethernet (10 Мбит/с, 48-битовая адресация). Процедура передачи дейтаграмм IP в сетях Experimental Ethernet (3 Мбит/с, 8-битовая адресация) рассматривается в работе [3].

Формат кадров

Дейтаграммы IP передаются в стандартных кадрах Ethernet. Поле типа в заголовках кадров Ethernet должно содержать шестнадцатеричное значение 0800.

Поле данных кадра содержит заголовок IP, непосредственно за которым следуют данные IP.

Минимальная длина поля данных пакетов, передаваемых через сети Ethernet, составляет 46 октетов. При нехватке данных используется заполнение нулями до минимального размера кадра Ethernet. Заполнение не является частью пакета IP и не учитывается полем размера в заголовке IP.

Максимальный1 размер поля данных для пакетов, передаваемых через сети Ethernet, составляет 1500 октетов, поэтому размер дейтаграмм IP не должен превышать это значение при передаче через Ethernet. Рекомендуется в реализациях протоколов поддерживать пакеты полного размера. Реализации шлюзов должны быть готовы к восприятию пакетов полного размера и при необходимости фрагментировать пакеты. Если система не может принимать пакеты полного размера, такая система должна принять меры по предотвращению передачи таких пакетов другими системами (например, с помощью опции TCP Maximum Segment Size [4]).

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

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

Преобразование 32-битовых адресов Internet в 48-битовые адреса Ethernet можно выполнить несколькими способами в статическом или динамическом варианте.

Статическая таблица

Каждому хосту может быть предоставлена таблица всех остальных хостов локальной сети с их адресами Ethernet и Internet (IP).

Динамическое определение

Преобразование между 32-битовыми адресами Internet и 48-битовыми адресами Ethernet может быть выполнено на основе протокола ARP2 [5]. Адреса Internet в некоторых сетях распределяются «произвольно». Каждая реализация хоста должна знать свой адрес Internet и отвечать подобающим образом на запросы Ethernet ARP. При необходимости протокол ARP следует использовать и для преобразования адресов Internet в адреса Ethernet.

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

Широковещательный адрес Internet (адрес, в котором все биты номера хоста имеют значение 1) должен отображаться в широковещательный адрес Ethernet (шестнадцатеричное значение FFFFFFFFFFFF).

Настоятельно рекомендуется на практике использовать динамическое преобразование адресов на основе протокола ARP.

Трейлерные форматы

Некоторые версии Unix 4.2bsd используют иной метод инкапсуляции для повышения производительности архитектуры виртуальной памяти VAX. По согласованию системы одной ЛВС Ethernet могут использовать этот формат при обмене между собой.

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

Примечание. В настоящее время системы Unix 4.2bsd используют трейлеры всегда или не используют их совсем (для каждого интерфейса независимо) в зависимости от опций загрузки. Однако в будущем ситуация может измениться. Системы Unix 4.2bsd также используют нестандартное значение широковещательного адреса Internet (все биты номера имеют нулевое значение) и это также может измениться в будущем.

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

Как описано в Приложении B к спецификации протокола IP [1], дейтаграммы IP передаются через сети Ethernet в виде последовательностей 8-битовых байтов (октетов).

Литература

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

[2] «The Ethernet — A Local Area Network», Version 1.03, Digital Equipment Corporation, Intel Corporation, Xerox Corporation, September 1980.

[3] Postel, J., «A Standard for the Transmission of IP Datagrams over Experimental Ethernet Networks», RFC-895, USC/Information Sciences Institute, April 1984.

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

[5] Plummer, D., «An Ethernet Address Resolution Protocol», RFC-826, Symbolics Cambridge Research Center, November 1982.

[6] Leffler, S., and M. Karels, «Trailer Encapsulations», RFC-893, University of California at Berkeley, April 1984.


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

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

nmalykh@gmail.com

1В оригинале ошибочно сказано «минимальная». Прим. перев.

2Address Resolution Protocol — протокол преобразования адресов.

3Работа доступна по ссылке http://decnet.ipv7.net/docs/dundas/aa-k759b-tk.pdf. Прим. перев.

 




RFC 895 A Standard for the Transmission of IP Datagrams over Experimental Ethernet Networks

Network Working Group                                         Jon Postel
Request for Comments: 895                                            ISI
                                                              April 1984




Стандарт передачи дейтаграмм IP через экспериментальные сети Ethernet

A Standard for the Transmission of IP Datagrams over Experimental Ethernet Networks

PDF

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

Этот RFC задает стандартный метод инкапсуляции дейтаграмм протокола Internet (IP) [1] в сетях Experimental Ethernet [2]. Данный RFC задает стандартный протокол для сообщества ARPA Internet.

Введение

Этот документ применим для сетей Experimental Ethernet (3 Мбит/с, 8-битовый адрес). Процедура передачи дейтаграмм IP в сетях Ethernet (10 Мбит/с, 48-битовый адрес) описана в работе [3].

Формат кадра

Дейтаграммы IP передаются в стандартных кадрах Experimental Ethernet. Поле type в кадре Ethernet должно иметь значение 513 (восьмеричное значение 1001). Поле data содержит заголовок IP, непосредственно за которым следуют данные IP.

При необходимости поле data следует дополнять до минимального размера кадров Experimental Ethernet. Это заполнение не является частью пакета IP и не учитывается в поле length заголовка IP.

Максимальный размер дейтаграмм IP при передаче через сеть Experimental Ethernet составляет 1536 октетов. Реализациям настоятельно рекомендуется поддерживать пакеты полного размера. Реализации шлюзов должны быть готовы к восприятию полноразмерных пакетов и фрагментироанию их в случае необходимости. Если система не может получать пакеты полного размера, ей следует предпринять действия, предостерегающие других от отправки ей полноразмерных пакетов (например, с помощью опции TCP Maximum Segment Size [4]).

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

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

Отображение 32-битовых адресов Internet на 8-битовые адреса Experimental Ethernet можно выполнить несколькими способами.

Простейшим вариантом является использование восьми младших битов номера хоста из адреса Internet в качестве адреса Experimental Ethernet. Такой подход рекомендуется применять.

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

Широковещательный адрес Internet (адрес, в котором все биты номера хоста имеют значение 1) следует отображать на широковещательный адрес Experimental Ethernet (0).

Трейлерные форматы

Некоторые версии Unix 4.2bsd используют иной метод инкапсуляции для повышения производительности архитектуры виртуальной памяти VAX. По согласованию системы одной ЛВС Ethernet могут использовать этот формат при обмене между собой.

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

Примечание. В настоящее время системы Unix 4.2bsd используют трейлеры всегда или не используют их совсем (для каждого интерфейса независимо) в зависимости от опций загрузки. Однако в будущем ситуация может измениться. Системы Unix 4.2bsd также используют нестандартное значение широковещательного адреса Internet (все биты номера имеют нулевое значение) и это также может измениться в будущем.

Порядок байтов

Как описано в Приложении B к спецификации протокола IP [1], дейтаграммы IP передаются через сети Ethernet в виде последовательностей 8-битовых байтов (октетов).

Литература

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

[2] Metcalfe, R. and D. Boggs, «Ethernet: Distributed Packet Switching for Local Computer Networks»1, Communications of the ACM, V.19, N.7, pp 395-402, July 1976.

[3] Hornig, C., «A Standard for the Transmission of IP Datagrams over Ethernet Networks», RFC-894, Symbolics Cambridge Research Center, April 1984.

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

[5] Plummer, D., «An Ethernet Address Resolution Protocol», RFC-826, Symbolics Cambridge Research Center, November 1982.

[6] Leffler, S., and M. Karels, «Trailer Encapsulations», RFC-893, University of California at Berkeley, April 1984.


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

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

nmalykh@gmail.com

1Статья доступна по ссылке http://ethernethistory.typepad.com/papers/EthernetPaper.pdf. Прим. перев.




RFC 893 Trailer Encapsulations

Network Working Group                                  Samuel J. Leffler
Request for Comments: 893                              Michael J. Karels
                                    University of California at Berkeley
                                                              April 1984

Трейлерная инкапсуляция

Trailer Encapsulations

PDF

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

В этом RFC рассматриваются мотивы использования трейлерной инкапсуляции в локальных сетях и описана реализации такой инкапсуляции в разных средах. Документ служит лишь для информации и не является официальным стандартом сообщества ARPA Internet.

Введение

Трейлерная инкапсуляция представляет собой формат пакетов канального уровня, используемый в 4.2BSD UNIX (среди прочих). Трейлерная инкапсуляция или «трейлер» может генерироваться системой при некоторых обстоятельствах для минимизации числа и размера операций копирования в памяти (memory-to-memory), выполняемых принимающим хостом при обработке пакета данных. Трейлер является форматом пакетов исключительно канального уровня и невидим (при подобающей реализации) при обработке на вышележащих уровнях. В этой заметке описаны мотивы использования трейлерной инкапсуляции и формат пакетов, используемый в сетях 3 Mb/s Experimental Ethernet, 10 Mb/s Ethernet и сетях 10 Mb/s V2LNI с кольцевой топологией [1].

Трейлерную инкапсуляцию предложил Greg Chesson, а описанную здесь инкапсуляцию разработал Bill Joy.

Мотивация

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

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

Данные, передаваемые через сеть, легко сегментировать до подходящего размера, но пока информация заголовка протокола инкапсуляции не имеет фиксированного размера, выравнивание по границам страниц практически невозможно. Информация протокольного заголовка может существенно меняться в результате применения разных протоколов (каждый со своим заголовком) или тех или иных соглашений (например, при включении в заголовок дополнительной информации). Для обеспечения выравнивания по краю страницы информация заголовка, предшествующего данных, предназначенным получателю, должна быть сведена к фиксированному размеру — это нормально для канального уровня сети. С учетом всей (возможной) информации переменного размера в заголовке ее размещение после сегмента данных передающим хостом, позволит улучшить ситуацию и позволит принимающему хосту возможность выровнять данные по границе страницы. Это перемещение данных на канальном уровне для размещения заголовков переменного размера «в хвосте» было названо трейлерной инкапсуляцией.

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

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

  2. Издержки на прием данных с выравниванием по границе страниц должны быть совместимы с приемом без такого выравнивания. При слишком больших издержках на выравнивание экономия за счет копирования может сойти на нет.

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

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

Первое допущение известно достаточно хорошо и послужило мотивом для этого документа.

Была идея согласования применения трейлеров на уровне хоста с использованием протокола преобразования адресов ARP1 [2] (фактически дополняющего протокол), но в настоящее время все системы, использующие трейлеры, требуют от хостов разделяемой сетевой среды всегда воспринимать трейлеры или никогда их не передавать (последнее легко выполнимо во время загрузки 4.2BSD без изменения исходных кодов операционной системы).

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

По части третьего допущения предположим, что информация из трейлерного заголовка копируется без переотображения и рассмотрим в качестве примера издержки, связанные с заголовком в протоколах TCP/IP [3]. Если мы предположим, что заголовки протоколов TCP и IP являются частью данных заголовка переменного размера, минимальный трейлерный пакет (генерируемый системой VAX) будет иметь 512 байтов данных и более 40 байтов заголовков (в дополнение к трейлеру, описанному ниже). Хотя трейлерный заголовок может включать опции IP и/или TCP, это будет встречаться достаточно редко (можно ожидать, например, что большинство опции TCP будет включаться в начальный обмен соединения) и заголовок будет много меньше 512 байтов. Если сегмент данных больше, отношение уменьшается и ожидаемый эффект от снижения издержек копирования на приемной стороне будет расти. С учетом относительных издержек на операции копирования и манипуляции с отображением страниц памяти (включая аннулирование буфера трансляции) преимущество становится очевидным.

Четвертый вопрос на наш взгляд не является проблемой. В нашей реализации дополнительный код для поддержки трейлерной инкапсуляции составил около дюжины строк в каждом драйвере интерфейса канального уровня. Суммарное повышение производительности многократно превышает небольшие вложения в изменение программ.

Следует признать, что изменение формата пакетов на сетевом (и обычном канальном) уровне описываемым здесь способом заставляет принимающий хост буферизовать пакет целиком перед его обработкой. Умные реализации могут анализировать протокольные заголовки при получении пакета для определения реального размера (или типа пакета сетевого уровня) входящего сообщения. Это позволяет таким реализациям избежать выделения буферов максимального размера для входящих пакетов, которые потом могут быть признаны непригодными. Реализации, анализирующие формат сетевого уровня «на лету», нарушают принципы разделения по уровням, которые в течение некоторого времени провозглашаются для проектирования (но часто нарушаются в реализациях). Проблема отложенного распознавания типа канального уровня является разумным критицизмом. Однако в случае сетевого оборудования с поддержкой DMA2 пакет всегда принимается целиком до начала его обработки.

Форматы пакетов с трейлерной инкапсуляцией

В этом параграфе описывается формат канального уровня для пакетов, используемых в сетях 3 Mb/s Experimental Ethernet и 10 Mb/s Ethernet, а также кольцевых сетях 10 Mb/s V2LNI. Используемый в каждом из этих случаев формат отличается лишь значением поля типа (type) в заголовках локальной сети.

Формат трейлерного пакета показан на рисунке.


+----+-------------------------------------------------+----+
| LH |                     data                        | TH |
+----+-------------------------------------------------+----+
     ^                    (  ^  )                      ^

LH

Заголовок локальной сети (фиксированного размера). Для 10 Mb/s Ethernet это 16-байтовый заголовок Ethernet. Поле type в заголовке field показывает тип пакета (трейлер) и размер сегмента данных.

Для 10 Mb/s Ethernet поле type может принимать значения от 1001 до 1010 в шестнадцатеричном формате (от 4096 до 4112 в десятичном). Значение type рассчитывается как сумма шестнадцатеричного числа 1000 и числа 512-байтовых страниц данных. В одном трейлерном пакете может передаваться до 16 страниц данных (8192 байтов).

data

Данные пакета. Обычно это только данные, доставляемые принимающему процессу (т. е. они не содержат информации TCP и IP). Размер данных всегда кратен 512 байтам.

TH

Трейлер, представляющий собой комбинацию исходных протокольных заголовков и префикс трейлера с фиксированным размером, определяющий тип и размер данных. Формат трейлера показан ниже.

Символ ^ указывает границы страниц, на которых принимающий хост будет размещать свой входной буфер для оптимального выравнивания при получении трейлерного пакета. Функция приема канального уровня способна разместить трейлер, используя размер, указанный полем type в заголовке канального уровня. Предполагается, что эта функция отбросит заголовок канального уровня и префикс трейлера, а также отобразит сегмент данных на начало пакета для восстановления формата исходного заголовка сетевого уровня.

Формат трейлера


+----------------+----------------+------~...~----------+
|      TYPE      |  HEADER LENGTH |  ORIGINAL HEADER(S) |
+----------------+----------------+------~...~----------+

Type — 16 битов

Поле type представляет исходный тип канального уровня для передаваемого пакета. Это значение обычно помещается в заголовке канального уровня, если трейлер не создается.

Header length — 16 битов

Поле header length трейлерного сегмента данных, указывающее размер последующих данных заголовка в байтах.

Original headers — <переменный размер>

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

Заключение

Описана инкапсуляция канального уровня, которая обеспечивает выравнивание, требуемое для эффективного использования виртуальной памяти. Этот формат инкапсуляции применяется во многих системах и является стандартным для 4.2BSD UNIX. Инкапсуляция обеспечивает эффективный механизм, с помощью которого взаимодействующие хосты локальной сети могут получить существенный рост производительности. Использование этой инкапсуляции в настоящее требует однородного взаимодействия всех хостов сети и мы надеемся на возможность добавления на каждом хосте механизмов согласования, которые позволят хостам согласовать использование инкапсуляции в неоднородной среде.

Литература

[1] «The Ethernet — A Local Area Network»3, Version 1.0, Digital Equipment Corporation, Intel Corporation, Xerox Corporation, September 1980.

[2] Plummer, David C., «An Ethernet Address Resolution Protocol», RFC-826, Symbolics Cambridge Research Center, November 1982.

[3] Postel, J., «Internet Protocol», RFC-791, USC/Information Sciences Institute, September 1981.


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

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

nmalykh@gmail.com

1Address Resolution Protocol.

2Direct memory access — прямой доступ к памяти. Прим. перев.

3Доступна по ссылке http://decnet.ipv7.net/docs/dundas/aa-k759b-tk.pdf. Прим. перев.