Перевод RFC 1626

MTU протокола IP при передаче через ATM AAL5

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

Автор RFC 1626: R. Atkinson, Naval Research Laboratory. Дата RFC - май 1994.

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

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

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

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

Значение по умолчанию для IP MTU через A T M A A L 5 .

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

RFC 1626 ссылается на установленный в RFC 1209 IP MTU для передачи через сети SMDS, равный 9180 октетов (RFC1209 - 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.

http://rfc.com.ru

2 < MTU протокола IP при передаче через ATM AAL5

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 party) к стороне, принимающей вызов (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» (Неправильное содержимое информационного элемента).

2000, RFC 1626 Kedrov Sergey http://rfc.com.ru

Связанные документы. > 3

Path MTU Discovery

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

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

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

Связанные документы.

На сервере rfc.com.ru вы также можете найти следующие документы по обсуждаемой тематике: Мультипротокольная инкапсуляция через AAL5 (основанное на RFC 1483) IP и ARP через ATM (основанное на RFC 1577)

2000, RFC 1577 Kedrov Sergey http://rfc.com.ru

krkn.me, dolor | mega sb darknet, tor url link | Слив шкодниц еще на сайте.


	На главную
	MTU протокола IP при передаче через ATM AAL5

	Данный документ содержит описание использующегося в сетях ATM MTU протокола IP, основанное на RFC 1626. Автор RFC 1626: R. Atkinson, Naval Research Laboratory. Дата RFC - май 1994. От переводчика Данный документ не является попыткой изложить материал в удобоваримом виде, т. е. таким образом, чтобы его было удобно читать и понимать неспециалисту. Такая обработка не проводилась. Документ является, если так можно выразиться, литературным переводом первоисточника. Последовательность изложения материала и терминология по возможности сохранены. В то же время некоторые организационные данные (не относящиеся к собственно описанию) не включены в данный документ. Желающие получить эти данные могут обратиться к оригиналу. Англоязычные названия параметров будут переводиться, но использоваться далее в тексте как правило в первоначальном виде. Это объясняется тем, что вероятность встретить русскоязычные обозначения при настройке какого-либо устройства достаточно мала. Кроме того, RFC 1626 является достаточно кратким документом, по сути дела сводящимся к утверждению тог, что по умолчанию размер IP MTU при передаче через сети ATM составляет 9180 октетов. Значение по умолчанию для IP MTU через A T M A A L 5 . Известно, что при передаче информации большими пакетами общая скорость передачи увеличивается. Это связано с тем, что в случае больших пакетов служебные данные (например, заголовок и окончание пакета) занимают в процентном отношении меньше места. Активное сетевое оборудование, передающее данные, работает более производительно, поскольку сама передача пакетов много времени не занимает, время и вычислительные ресурсы занимаются на обработку служебной информации пакета – адресной, приоритетной, фильтрация и т. д. В то же время формирование чрезмерно больших пакетов в протоколе IP приводит к фрагментации и крайне нежелательна по различного рода причинам. Следовательно, необходимо найти золотую середину для максимального размера пакета данных. Широко используемый протокол NFS, например, по умолчанию использует размер пакета, равный 8192 байта. Учитывая заголовки RPC/XDR, UDP, IP и LLC, получаем цифру 8300 октета. RFC 1626 ссылается на установленный в RFC 1209 IP MTU для передачи через сети SMDS, равный 9180 октетов (RFC1209 - 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.

	http://rfc.com.ru



	2 < MTU протокола IP при передаче через ATM AAL5

	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 party) к стороне, принимающей вызов (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» (Неправильное содержимое информационного элемента).

	2000, RFC 1626 Kedrov Sergey http://rfc.com.ru



	Связанные документы. > 3

	Path MTU Discovery Механизм Path MTU Discovery (Иследование MTU маршрута) используется для уменьшения использования IP-фрагментации при передаче данных (RFC 1191). Данный механизм в двух словах состоит в следующем. Две IP-станции, перед тем, как передавать данные, определяют, какой минимальный размер MTU используется сетями, между ними находящимися. Используя минимальный размер MTU для передаваемых пакетов, станции гарантируют отсутствие фрагментации пакетов при передаче данных. Поскольку сети ATM используют размер MTU, отличный от используемого в других сетях (Ethernet, FDDI, другие), соответственно использование Path MTU Discovery должно учитываться в сетях ATM. RFC 1626 декларирует, что устройства, его поддерживающие, также должны поддерживать Path MTU Discovery, специфицированный в RFC 1192. Связанные документы. На сервере rfc.com.ru вы также можете найти следующие документы по обсуждаемой тематике: Мультипротокольная инкапсуляция через AAL5 (основанное на RFC 1483) IP и ARP через ATM (основанное на RFC 1577)

	2000, RFC 1577 Kedrov Sergey http://rfc.com.ru
	krkn.me, dolor \| mega sb darknet, tor url link \| Слив шкодниц еще на сайте.