RFC: 1626
Оригинал: Default IP MTU for use over ATM AAL5
Другие версии: RFC 2225
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Сергей Кедров

От переводчика

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

Англоязы чные названия параметров будут переводиться, но использоваться далее в тексте как правило в первоначальном виде. Это объясняется тем, что вероятность встретить русскоязычные обозначения при настройке какого-либо устройства достаточно мала.

Кроме того, RFC 1626 является достаточно кратким документом, по сути дела сводящимся к утверждению того, что по умолчанию размер IP MTU при передаче через сети ATM составляет 9180 октетов.

Значение по умолчанию для IP MTU через ATM AAL 5.

Известно, что при передаче информации большими пакетами общая скорость передачи увеличивается. Это связано с тем, что в случае больших пакетов служебные данные (например, заголовок и окончание пакета ) занимают в процентном отношении меньше места. Активное сетевое оборудование, передающее данные, работает более производительно, поскольку сама передача пакетов много времени не занимает, время и вычислительные ресурсы занимаются на обработку служебной информации пакета — адресной, приоритетной, фильтрация и т. д. В то же время формирование чрезмерно больших пакетов в протоколе IP приводит к фрагментации и крайне нежелательна по различного рода причинам. Следовательно, необходимо найти золотую середину для максимального размера пакета данных. Широко используемый протокол NFS, например, по умолчанию использует размер пакета, равный 8192 байта. Учитывая заголовки RPC/XDR, UDP, IP и LLC, получаем цифру 8300 октета.

RFC 1626 ссылается на установленный в RFC 1209 IP MTU дл я передачи через сети SMDS, равный 91 80 октетов (RFC 1209 — Transmission of IP datagrams over the SMDS Service. D.M. Piscitello, J. Lawrence. Mar-01 — 1991. Format: TXT=25280 bytes) (Also STD0052) (Status: STANDARD)). Это отличается от тех же 8300, но является числом того же порядка. RFC 1626 отмечает, что нет никаких причин, по которым следовало бы уйти от размера MTU, принятого в сетях SMDS. Такая практика позволит передавать данные между сетями ATM и SMDS без излишней фрагментации и послужит делу совместимости.

Таким образом, по умолчанию в сетях ATM должен использоваться размер IP MTU, равный 9180 октетам. Все устройства или программы, поддерживающие RFC 1626, должны по умолчанию использовать именно этот размер MTU.

PVC

Устройства, работающие с PVC (Permanent Virtual Circuit) не поддерживают никакого протокола сигнализации. Такие устройства должны использовать по умолчанию размер IP MTU 9180 октетов. Устройства могут использовать иные значения в том случае, если эти «иные значения» сконфигурированы на обоих устройствах — участниках соединения.

SVC

При поддержке SVC (Switched Virtual Circuit) устройства должны попытаться согласовать используемый размер AAL CPCS-SDU с помощью используемого протокола сигнализации. Стандартный протокол сигнализации ATM использует два поля одного из IE (Information Element — Информационный элемент) для согласования размера MTU. Этот IE называется «AAL parameters» (параметры AAL). Первая часть — Forward Maximum CPCS-SDU Size (Максимальный размер CPCS-SDU в прямом направлении ) содержит размер, используемый при передаче данных от инициализирующей соединение стороны (calling part y) к стороне, принимающей вызов (called party). Вторая часть — Backward Maximum CPCS-SDU Size (Максимальный размер CPCS-SDU в обратном направлении) содержит размер, используемый при передаче данных от called party к calling party. Форум ATM устанавливает диапазон для этих значений от 1 до 65535, включительно. Обратите внимание, что описываемые IE могут отличаться друг от друга.

Даже в том случае, если вызывающая, или инициализирующая вызов сторона собирается использовать размер IP MTU по умолчанию, она все равно должна включать соответствующий IE «AAL parameters» в свое сообщение SETUP, и указывать в нем соответствующий размеры Maximum CPCS-SDU Size. Если вызывающая сторона собирается использовать значение, отличное от используемого по умолчанию, то она должна включить в IE «AAL parameters» тот размер, который она собирается использовать. Вызываемая, или принимающая вызов отвечает с использованием тех же элементов и идентификаторов в своем сообщении CONNECT.

В том случае, ес ли устройство получает сооб щение SETUP, т. е. является стороной, принимающей вызов, и сообщение SETUP содержит IE «AAL parameters», то она должна обрабатывать параметры Forward Maximum CPCS-SDU Size и Backward Maximum CPCS-SDU Size следующим образом:

  1. Если вызываемая сторона в состоянии поддерживать IP MTU, предложенное в сообщении SETUP, она должна включить IE «AAL parameters» в свое ответное сообщение. Поля Forward Maximum CPCS- SDU Size и Backward Maximum CPCS-SDU Size должны прис утствовать и содержать значения, эквивалентные принятым в сообщении SETUP.
  2. Если устройство хочет использовать размер, меньший чем предлагаемый, она должна установить соответствующие значения Maximum CPCS-SDU Size в IE «AAL parameters» в своем сообщении CONNECT.
  3. Если вызывающая сторона получает сообщение CONNECT, в котором отс утствует IE «AAL parameters», но при этом соответствующее сообщение SETUP такой элемент содержало, она должна сбросить соединение с установ кой причины «AAL Parameters cannot be supported» (Невозможна поддержка параметров AAL).
  4. Если одна из сторон получает сообщение STATUS с темой «Information Element Non-existent or Not Implemented» (IE не существует или не поддерживается) или «Access Information Discarded» (Информация доступа сброшена ), и при этом диагностическое поле будет указывать IE «AAL parameters», то она (сторона) должна сбросить соединение с установкой причины «AAL Parameters cannot be supported».
  5. Если одна из сторон получает CPCS-SDU с размером, превышающим согласованный, то она может или использовать IP-фрагментацию, или сбросить соединение с установкой причины «AAL Parameters cannot be supported». Данный случай должен быть выведен сетевым управлением сети ATM для дальнейшего анализа сетевым администратором (в логфайл занести, например).

Если вызываемая сторона некорректно помещает поля Forward Maximum CPCS-SDU Size и Backward Maximum CPCS-SDU Size в сообщение CONNECT, или устанавливает эти поля в некорректные значения, то вызывающая сторона в этом случае сбрасывает соединение с сообщением «Invalid Information Element Contents» (Неправильное содержимое информац ионного элемента).

Path MTU Discovery

Механизм Path MTU Discovery (RFC 1191) используется для уменьшения использования IP-фрагментации при передаче данных. Данный механизм в двух словах состоит в следующем.

Две IP-станции, перед тем, как передавать данные, определяют, какой минимальный размер MTU используется сетями, между ними находящимися. Используя минимальный размер MTU для передаваемых пакетов, станции гарантируют отс утствие фрагментации пакетов при передаче данных.

Поскольку сети ATM используют размер MTU, отличный от используемого в других сетях (Ethernet, FDDI, другие), соответственно использование Path MTU Discovery должно уч итываться в сетях ATM. RFC 1626 декларирует, что устройства, его поддерживающие, также должны поддерживать Path MTU Discovery, специфицированный в RFC 1192.

Ссылки

[RFC-791] J. Postel, «Протокол IP (Internet Protocol)», RFC 791, Сентябрь 1981.
[RFC-793] J. Postel, «Протокол управления передачей (TCP)», RFC 793, Сентябрь 1981.
[RFC-1122] Robert Braden, «Требования к хостам Internet - Коммуникационные уровни», RFC 1122, Октябрь 1989.
[RFC-1191] Jeffrey Mogul и Steve Deering, «Исследование MTU на пути следования сообщения», RFC 1191, Ноябрь 1990.
[RFC-1209] Piscitello, D., and J. Lawrence, «The Transmission of IP Datagrams over the SMDS Service», RFC 1209, Bell Communications Research, Март 1991.
[RFC-1435] Knowles, S., «IESG Advice from Experience with Path MTU Discovery», RFC-1435, IESG, Март 1993.
[RFC-1483] Heinanen, J., «Multiprotocol Encapsulation over ATM Adapatation Layer 5», RFC 1483, Telecom Finland, Июль 1993.
[RFC-1577] Laubach, M., «Classical IP and ARP over ATM», RFC 1577, Hewlett-Packard Laboratories, Январь 1994.
[ATMF93a] Breault, R., Grace, J., Jaeger, J., and L. Wojnaroski, Editors, «ATM Forum User Network Interface Specification», Version 3.0, Section 5.4.5.5, p. 194-200, 10 September 1993, ATM Forum.
[ATMF93b] Breault, R., Grace, J., Jaeger, J., and L. Wojnaroski, Editors, «ATM Forum User Network Interface Specification», Version 3.0, Section 5.3.1.7, p. 171-172, 10 September 1993, ATM Forum.
[ATMF93c] Breault, R., Grace, J., Jaeger, J., and L. Wojnaroski, Editors, «ATM Forum User Network Interface Specification», Version 3.0, Section 5.3.1.3, p. 168, 10 September 1993, ATM Forum.
[KM87] Kent C., and J. Mogul, «Fragmentation Considered Harmful», Proceedings of the ACM SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology, Август 1987.
"
2007 - 2022 © Русские переводы RFC, IETF, ISOC.