Network Working Group J. Heinanen
Request for Comments: 2597 Telia Finland
Category: Standards Track F. Baker
Cisco Systems
W. Weiss
Lucent Technologies
J. Wroclawski
MIT LCS
June 1999
Группа PHB для гарантированной пересылки
Assured Forwarding PHB Group
Статус документа
В этом документе содержится проект стандартного протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (1999). All Rights Reserved.
Аннотация
В этом документе определена группа PHB1 общего назначения для дифференцированного обслуживания (DS2) [Blake], называемого гарантированной пересылкой (AF3). Группа AF обеспечивает доставку пакетов IP с использованием 4 классов AF с независимой пересылкой. В каждом классе AF пакету IP может быть присвоен один из трех уровней предпочтения при отбрасывании. Узел DS не меняет порядок пакетов IP в микропотоке, если эти пакеты относятся к одному классу AF.
1. Обзор и назначение группы
Существует потребность в ускоренной пересылке пакетов IP через Internet. Обычно компании используют Internet для соединения географически распределенных сайтов и хотят, чтобы пакеты IP в их intranet-сети пересылались с высокой вероятностью, пока агрегат трафика от каждого сайта не превышает скорости обслуживания для этого сайта (профиль). Желательно обеспечить сайту возможность передачи избыточного трафика с пониманием того, что выходящий за пределы профиля подписки трафик не будет доставляться со столь же высокой вероятностью, как трафик в рамках подписки. Важно также обеспечить сохранение порядка пакетов в одном микропотоке, как определено в [Nichols], независимо от того, является ли этот трафик избыточным.
Группа AF PHB для провайдерского домена DS означает специальный уровень гарантий пересылки пакетов IP из пользовательского домена DS. Определены 4 класса AF и для каждого класса на каждом узле DS выделяется некоторый объем ресурсов пересылки (буферная емкость и полоса пропускания). Пакеты IP для которых хочется использовать услуги группы AF PHB относятся пользовательским или провайдерским доменом DS к одному или нескольким классам AF в соответствии с желаемым набором услуг. Дополнительную информацию об этой возможности и путях ее использования можно найти в работе [Clark].
Внутри каждого класса AF пакеты IP маркируются (пользовательским или провайдерским доменом DS) одним из трех возможных уровней предпочтения при отбрасывании. При возникновении перегрузок (насыщения) этот уровень определяет относительную важность пакета в рамках класса AF. Перегруженный узел DS пытается защитить пакеты с меньшим значением уровня, отбрасывая пакеты с большими значениями.
На узле DS уровень гарантии пересылки пакета IP зависит от (1) объема ресурсов пересылки, выделенных для класса AF данного пакета, (2) текущей загрузки данного класса AF и (при наличии перегрузки для класса) от (3) уровня предпочтений при отбрасывании.
Например, если действия по кондиционированию трафика на входе в провайдерский домен DS обеспечивают для класса AF на узлах DS незначительную загрузку пакетами с наименьшим уровнем приоритета и отсутствие перегрузки для двух оставшихся уровней, данный класс AF будет обеспечивать высокий уровень гарантий пересылки для пакетов в рамках профиля подписки (маркированных с низшим уровнем приоритета отбрасывания) и два уровня гарантий пересылки для избыточного трафика.
В этом документе описывается группа AF PHB. От узлов DS не требуется обязательной поддержки данной группы PHB, но если поддерживающий DS узел заявляет реализацию группы AF PHB, он должен соответствовать данной спецификации.
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [Bradner].
2. Группа AF PHB
Группа AF PHB обеспечивает пересылку пакетов IP с использованием N независимых классов AF. Врамках каждого класса AF пакетам IP присваивается один из M различных уровней предпочтения при отбрасывании. Пакет IP, относящийся к AF-классу i с уровнем предпочтительного отбрасывания j, маркируется в AF кодом AFij, где 1 <= i <= N и 1 <= j <= M. В настоящее время для общего использования определены 4 (N=4) класса с тремя (M=3) уровнями предпочтений при отбрасывании в каждом из классов. Для локального применения могут определяться дополнительные классы AF и уровни приоритета отбрасывания.
Узлам DS следует реализовать все 4 класса AF общего пользования. Пакеты каждого из классов AF должны пересылаться независимо от пакетов других классов (т. е., для узлов DS недопустимо агрегирование классов AF).
Узел DS должен выделять (настраиваемое) минимальное количество ресурсов пересылки (буферная емкость и полоса каналов) для каждого реализованного класса AF. Каждый класс следует обслуживать так, чтобы обеспечивалась заданная в конфигурации скорость (полоса) как на коротких, так и на продолжительных интервалах времени.
Для класса AF может также настраиваться выделение дополнительных ресурсов сверх заданного минимума при наличии свободных ресурсов, которые не требуются для других классов AF и групп PHB. В этом документе не регламентируется выделение дополнительных ресурсов, но реализации должны указывать используемый алгоритм их выделения и способы параметризации для него.
В рамках класса AF для узла DS недопустима меньшая вероятность пересылки пакетов IP с уровнем предпочтительного отбрасывания p, нежели пакетов с уровнем q, если p < q. Отметим, что это требование может выполняться без реорганизации очередей и отбрасывания пакетов, уже помещенных в очередь.
В каждом классе AF узел DS должен воспринимать все три кода приоритета отбрасывания и обеспечивать по крайней мере два разных уровня вероятности потерь. В некоторых сетях (в частности, в сетях предприятий), где перегрузки редки и кратковременны для узла DS может оказаться разумной поддержка лишь двух разных уровней вероятности потерь на класс AF. Такое решение может быть достаточным для некоторых сетей, однако следует поддерживать три разных уровня вероятности потерь для доменов DS, где перегрузки достаточно часты.
Если узел DS поддерживает лишь два разных уровня вероятности потерь для AF-класса x, коду AFx1 должна соответствовать минимальная вероятность потерь, а кодам AFx2 и AFx3 — более высокая.
Для узла DS недопустимо изменение порядка следования пакетов AF в одном микропотоке, когда они относятся к одному классу AF, независимо от приоритетности их отбрасывания. Временных требований (задержки и их вариации) для пересылки пакетов AF не задается.
Отношения между классами AF и другими PHB описаны в разделе 7.
Группа AF PHB может использоваться для реализации сквозного или междоменного сервиса.
3. Действия по кондиционированию трафика
Домен DS может контролировать на своем краю объем трафика AF входящего в домен или существующего в нем для различных уровней приоритета отбрасывания. Такие действия по кондиционированию могут включать формирование трафика, отбрасывание пакетов, изменение приоритета отбрасывания для пакетов, присвоение пакетам других классов AF. Однако при кондиционировании трафика недопустимо изменение порядка пакетов в одном микропотоке.
4. Очереди и отбрасывание пакетов
В этом разделе рассматривается поведение очередей и механизмов отбрасывания для группы AF PHB. Другие аспекты поведения группы PHB рассмотрены в разделе 2.
Реализации AF должны пытаться минимизировать долговременные перегрузки для каждого класса, разрешая короткие перегрузки в результате всплесков трафика. Это требует наличия алгоритма активного управления очередями. Примером такого алгоритма может служить RED4 [Floyd]. Данные документ не задает какой-либо конкретный алгоритм, но требует соблюдения некоторых параметров.
Реализация AF должна детектировать продолжительные перегрузки в рамках каждого класса и реагировать на них отбрасыванием пакетов, при этом кратковременные перегрузки (всплески трафика) должны обрабатываться с помощью очередей. Это предполагает наличие функции сглаживания или фильтрации, которая отслеживает мгновенный уровень перегрузки и рассчитывает сглаженное значение, которое используется алгоритмом отбрасывания для выбора отбрасываемых пакетов.
Алгоритм отбрасывания должен быть нечувствительным к кратковременным изменениям картины трафика в микропотоках, использующих класс AF. Т. е., потоки с различающимися кратковременными всплесками трафика, но совпадающие по средней скорости передачи пакетов, должны иметь одинаковую вероятность отбрасывания пакетов. Одним из способов решения такой задачи является использование случайных значений в функции отбрасывания.
Алгоритм отбрасывания должен одинаково трактовать все пакеты в рамках одного класса и уровня предпочтений. Это предполагает, что при данном уровне насыщения доля отбрасываемых пакетов отдельного микропотока в рамках одного уровня предпочтения будет пропорциональная доле этого потока в общем объеме трафика с тем же уровнем предпочтения.
Индикация перегрузки для конечных узлов и, таким образом, доля отбрасываемых пакетов для каждого уровня предпочтений при возникновении перегрузки, должна изменяться постепенно, а не резко, чтобы система в целом могла сохранять устойчивое состояние. Один из способов реализации этого (RED) использует два (настраиваемых) пороговых уровня перегрузки. Пока уровень перегрузки не достигает нижнего порога, пакеты с соответствующим уровнем предпочтения не отбрасываются. Если уровень перегрузки находится в интервале между двумя пороговыми значениями, пакеты отбрасываются с линейным ростом вероятности отбрасывания (от 0 при нижнем пороге до заданного в конфигурации значения при верхнем). После превышения верхнего порога пакеты с соответствующим уровнем предпочтения отбрасываются полностью (100%).
Для обеспечения возможности использования AF PHB в разных операционных средах параметры алгоритма отбрасывания должны быть настраиваемыми независимо для каждого уровня предпочтений и каждого класса AF.
В рамках указанных выше ограничений данная спецификация может применяться для разных вариантов политики отбрасывания. Несогласованные политики отбрасывания пакетов приведут к рассогласованию семантики сквозного обслуживания (end-to-end service) и будут ограничивать область применения AF PHB в средах с разнородным оборудованием. По мере обретения опыта новые версии этого документа смогут определять конкретные аспекты желаемого поведения.
5. Туннелирование
При туннелировании пакетов AF для PHB туннелируемых пакетов недопустимо снижение уровня гарантий пересылки туннелируемых пакетов AF или изменение порядка следования пакетов AF в рамках одного микропотока.
6. Рекомендуемые коды
Ниже приведены рекомендуемые значения кодов для четырех классов AF общего назначения. Эти коды не пересекаются с какими-либо из групп PHB общего назначения.
Рекомендуются следующие значения кодов AF: AF11 = ‘001010’, AF12 = ‘001100’, AF13 = ‘001110’, AF21 = ‘010010’, AF22 = ‘010100’, AF23 = ‘010110’, AF31 = ‘011010’, AF32 = ‘011100’, AF33 = ‘011110’, AF41 = ‘100010’, AF42 = ‘100100’ и AF43 = ‘100110’. В таблице значения кодов указаны по классам и уровню предпочтений при отбрасывании.
Класс 1 Класс 2 Класс 3 Класс 4 +----------+----------+----------+----------+ Low Drop Prec | 001010 | 010010 | 011010 | 100010 | Medium Drop Prec | 001100 | 010100 | 011100 | 100100 | High Drop Prec | 001110 | 010110 | 011110 | 100110 | +----------+----------+----------+----------+
7. Взаимодействие с другими группами PHB
Рекомендованное выше отображение кодов AF не конфликтует ни с локальным пространством кодов, ни к кодами Class Selector, рекомендованными в [Nichols]. Режимы PHB, выбираемые с помощью кодов Class Selector, могут, таким образом, сосуществовать с группой AF PHB и сохранять поведение при пересылке и отношения, которые были определены. В частности, код Default PHB (000000) может по прежнему использоваться для трафика best effort. Аналогично, код 11×000 можно продолжать использовать для трафика сетевого управления.
Группа AF PHB вместе с действиями по кондиционированию трафика на периметре, ограничивающими объем трафика некой (в общем случае разной) долей выделенных для каждого класса AF ресурсов, может служить для реализации поведения, предполагаемого Class Selector PHB. В таких случаях внутри домена DS часть или все коды Class Selector могут использоваться, как псевдонимы кодов AF.
В дополнение к Class Selector PHB и другие группы PHB могут сосуществовать с группой AF PHB внутри одного домена DS. Однако для любой реализации группы AF PHB следует документировать перечисленные ниже аспекты:
(a) Какие иные группы PHB (если они есть) могут перенимать ресурсы, выделенные каждому классу AF PHB. Такой «переход» ресурсов недопустим при нормальной работе, но может подходить для некоторых нестандартных ситуаций (например, код 11×000 может перенимать ресурсы пересылки AF для обеспечения преимущества необычно высокому трафику сетевого управления, когда в этом возникает необходимость).
(b) Как «избыточные» ресурсы распределяются между AF PHB и другими реализованными группами PHB. Например, после выделения минимальных ресурсов для каждого класса AF оставшиеся ресурсы могут быть поровну распределены между классами AF и Default PHB. Другим вариантом может служить выделение всех оставшихся ресурсов для пересылки избыточного трафика AF с предоставлением ресурсов для Default PHB только после удовлетворения всех запросов AF.
Данный документ не задает каких-либо конкретных отношений между AF PHB и другими реализованными группами PHB; требуется лишь документировать такие отношения. Реализации могут делать такие отношения настраиваемыми с помощью конфигурационных параметров. Предполагается, что такой уровень конфигурационной гибкости будет представлять ценность для многих сетевых администраторов.
8. Влияние на безопасность
Для защиты самого себя от атак на отказ служб (DoS) провайдеру домена DS следует ограничивать входящий в домен трафик в соответствии с профилями подписки. Для защиты канала в пользовательский домен DS от атак на службы провайдеру домена DS следует предоставлять пользовательскому домену DS возможность выделения ресурсов канала для пакетов AF. Если условия обслуживания требуют ограничивать трафик, помеченный кодами AF, по таким атрибутам, как адреса отправителей или получателей, ответственность за проверку таких атрибутов ложится на входной узел сети.
Другие вопросы безопасности рассмотрены в [Blake] и [Nichols].
9. Права интеллектуальной собственности
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, consult the online list of claimed rights.
10. Согласование с IANA
В этом документе выделены два значения кодов (раздел 6) из пула Pool 1 в пространстве кодов, заданном в [Nichols].
Приложение. Примеры сервиса
Группу AF PHB можно использовать, например, для реализации так называемого Олимпийского (Olympic) сервиса с тремя классами обслуживания — золото, серебро, бронза. Пакеты распределяются между этими тремя классами так, чтобы «золотым» пакетам обеспечивалась более высокая вероятность своевременной пересылки по сравнению с «серебряными». Аналогичное соотношение обеспечивается между «серебряными» и «бронзовыми» пакетами. При желании пакеты внутри каждого класса могут быть дополнительно поделены по уровням предпочтений при отбрасывании.
Бронзовый, серебряный и золотой классы будут отображаться на классы AF 1, 2 и 3. Аналогично, низкий, средний и высокий уровень предпочтения при отбрасывании будут отображаться на уровни AF предпочтений при отбрасывании 1, 2 и 3.
Приоритет при отбрасывании может присваиваться, например, с помощью ограничителя трафика (leaky bucket traffic policer), использующего в качестве параметров частоту и размер пакетов, на основе которых задаются два пороговых значения для согласованного (committed burst size) и избыточного уровня (excess burst size). Пакеты получают низкий уровень приоритета, если превышен порог избыточного трафика, средний — при трафике между согласованным и избыточным и высший при трафике ниже согласованного. Может также потребоваться установка верхней границы для трафика с высоким приоритетом из пользовательского домена DS с целью предотвращения ситуаций, когда поток недоставляемого трафика с высоким приоритетом из одного пользовательского домена DS будет препятствовать потокам потенциально доставляемых высокоприоритетных пакетов из других доменов.
Другим способом установки приоритета при отбрасывании может служить ограничение пользовательского трафика сервиса Olympic заданным уровнем с равномерным распределением между всеми уровнями приоритета отбрасывания. Это обеспечит пропорциональное распределение полосы в моменты перегрузок в предположении, что для заказчиков с высокоскоростными микропотоками заданы большие значения пиковой скорости.
Группа AF PHB может также оказаться полезной при реализации сервиса с малыми потерями и задержками на основе классов AF с избыточностью, если максимальная скорость поступления пакетов данного класса заранее известна на каждом узле DS. Однако спецификация требуемых для этого служб контроля доступа выходит за рамки данного документа. Если низкий уровень потерь не требуется обеспечивать, сервис с малыми задержками можно реализовать без организации избыточности путем установки низкого максимального порога для буферного пространства, доступного данному классу AF.
Литература
[Blake] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. And W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, December 1998.
[Bradner] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[Clark] Clark, D. and Fang, W., Explicit Allocation of Best Effort Packet Delivery Service. IEEE/ACM Transactions on Networking, Volume 6, Number 4, August 1998, pp. 362-373.
[Floyd] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume 1, Number 4, August 1993, pp. 397-413.
[Nichols] Nichols, K., Blake, S., Baker, F. and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, December 1998.
Адреса авторов
Juha Heinanen
Telia Finland
Myyrmaentie 2
01600 Vantaa, Finland
EMail: jh@telia.fi
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
EMail: fred@cisco.com
Walter Weiss
Lucent Technologies
300 Baker Avenue, Suite 100,
Concord, MA 01742-2168
EMail: wweiss@lucent.com
John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139
EMail: jtw@lcs.mit.edu
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The Internet Society (1999). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.
Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Подтверждение
Финансирование функций RFC Editor обеспечивается Internet Society.
1Per-Hop-Behavior — режим поведения на этапах пересылки.
2Differentiated Services.
3Assured Forwarding.
4Random Early Drop — произвольное упреждающее отбрасывание.
