RFC 2598 An Expedited Forwarding PHB

Please enter banners and links.

Network Working Group                                    V. Jacobson
Request for Comments: 2598                                K. Nichols
Category: Standards Track                              Cisco Systems
                                                           K. Poduri
                                                        Bay Networks
                                                           June 1999

PHB для ускоренной пересылки

An Expedited Forwarding PHB

PDF

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

В этом документе содержится проект стандартного протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа “Internet Official Protocol Standards” (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

Тезисы

Определение поэтапного режима пересылки (PHB¹) является важнейшей частью работы группы Diffserv. В этом документе описан PHB для ускоренной пересылки (EF²). Мы покажем общность этого PHB демонстрацией возможности его реализации с использованием разных механизмов и дадим пример использования для создания по крайней мере одного сервиса – VLL³. Приведен код, рекомендуемый для этого PHB.

Документ в формате pdf (на английском языке) доступен по ссылке ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf

1. Введение

Сетевые узлы, поддерживающие дифференцированное обслуживание для IP, используют код в заголовке IP для выбора поэтапного поведения (PHB), как специфического режима режима пересылки данного пакета [RFC2474, RFC2475]. В этом документе описан PHB для ускоренной пересылки (EF). EF PHB может использоваться для построения услуг с малыми задержками и их вариациями, а также с незначительной потерей пакетов в сквозном режиме через домены DS. Со стороны конечных точек такой сервис выглядит подобно соединению «точка-точка» или «виртуальной арендованной линии». Этот вид сервиса был также описан, как «надежное обслуживание» (Premium service) в [2BIT]. Потери, задержки и их вариации возникают при размещении трафика в очередях на пути через сеть. Следовательно, обеспечения малых потерь, задержек и их вариаций для некого агрегата трафика означает, что этот трафик не простаивает в очередях или находится там очень короткое время. Очереди возникают, когда скорость поступления трафика на узле (кратковременно) превышает скорость его дальнейшей отправки. Таким образом, сервис, который гарантирует отсутствие очередей для некого агрегата, эквивалентен такому ограничению скорости, при котором на каждом транзитном узле максимальная скорость прибытия пакетов данного агрегата будет меньше минимальной скорости их дальнейшей отправки.

Создание такого сервиса включает две части:

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

EF PHB обеспечивает первую часть сервиса. Для обеспечения второй части служат кондиционеры трафика на границе сети, описанные в [RFC2475].

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

В следующих параграфах приведено подробное описание EF PHB и даны примеры возможных реализаций. Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), следует (SHOULD), не следует (SHOULD NOT), возможно (MAY), в данном документе должны интерпретироваться в соответствии с [Bradner97].

2. Описание поэтапного режима ускоренной пересылки

EF PHB определяется, как трактовка пересылки для отдельного агрегата DS⁴, при которой скорость отправки пакетов данного агрегата DS с любого узла DS не меньше заданного значения. Следует обеспечивать гарантию заданной скорости отправки независимость от интенсивности остального трафика, пытающегося проходить через узел. Следует обеспечивать среднее значение скорости⁵ отправки не менее заданного значения (поведение в течение более коротких интервалов не задается осознанно). Заданное минимальное значение скорости должно быть настраиваемым сетевым администратором (с использованием любого, поддерживаемого узлом, механизма).

Если EF PHB реализуется с помощью механизма, который разрешает неограниченные преимущества перед другим трафиком (например, очереди с разным приоритетом), реализация должна включать те или иные меры по ограничению негативного влияния трафика EF на другой трафик (например, ограничение скорости с помощью метода token bucket). Трафик, превышающий заданный предел должен отбрасываться. Максимальная скорость EF и величина пиков (если это применимо) должны быть настраиваемыми сетевым администратором (с использованием любого, поддерживаемого узлом, механизма). Минимальная и максимальная скорость могут совпадать и задаваться в этом случае одним параметром.

В Приложении описано возможное применение данного PHB для организации сквозного сервиса.

2.2 Примеры механизмов для реализации EF PHB

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

Можно также использовать одну очередь из группы очередей, обслуживаемых планировщиком со взвешенным круговым обходом, где часть выходной полосы, отдаваемая для очереди EF, эквивалентна заданной скорости. Это можно реализовать, к примеру, с использованием одного PHB или совместимого с селекторами классов набора PHB [RFC2474].

Другой возможной реализацией является планировщик CBQ [CBQ], который отдает очереди EF приоритет вплоть до заданной скорости.

Все эти механизмы обеспечивают базовые свойства, требуемые для реализации EF PHB, хотя каждый из вариантов будет иметь дополнительные особенности поведения типа вариаций задержки для отдельных микропотоков. В приложении A.3 рассматриваются некоторые из таких различий.

2.3 Рекомендуемый код для данного PHB

Для EF PHB рекомендуется код 101110.

2.4 Изменяемость

Пакеты, маркированные для EF PHB, могут быть перемаркированы на границе домена DS только с использованием других кодов, удовлетворяющих EF PHB. Пакеты, маркированные для EF PHB, домену DS не следует перемещать (поднимать или опускать) в другие PHB.

2.5 Туннелирование

При туннелировании пакетов EF туннелирующие пакеты должны маркироваться, как EF.

2.6 Взаимодействие с другими PHB

При выполнении требований параграфа 2.1 на узле или в домене DS могут развертываться другие PHB или группы PHB.

3. Вопросы безопасности

Для защиты себя от атак на отказ служб (DoS⁶) периметр домена DS должен строго проверять для всех пакетов с маркировкой EF соответствие скорости согласованному со смежным восходящим доменом значению (скорость должна быть не больше значения, заданного для EF PHB). Пакеты, вызывающие превышение согласованной скорости должны отбрасываться. Если смежные домены не согласовали скорость EF, нисходящий домен должен использовать нулевое значение скорости (т. е., отбрасывать все пакеты с маркировкой EF)⁷.

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

4. Согласование с IANA

В этом документе выделяется один код 101110 из пула 1 (Pool 1) пространства кодов, определенного в [RFC2474].

5. Литература

[Bradner97] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2474] 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.

[RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, December 1998.

[2BIT] K. Nichols, V. Jacobson, and L. Zhang, “A Two-bit Differentiated Services Architecture for the Internet”, Work in Progress⁹, ftp://ftp.ee.lbl.gov/papers/dsarch.pdf

[CBQ] S. Floyd and V. Jacobson, “Link-sharing and Resource Management Models for Packet Networks”, IEEE/ACM Transactions on Networking, Vol. 3 no. 4, pp. 365-386, August 1995.

[RFC2415] Poduri, K. and K. Nichols, “Simulation Studies of Increased Initial TCP Window Size”, RFC 2415, September 1998.

[LCN] K. Nichols, “Improving Network Simulation with Feedback”, Proceedings of LCN ’98, October 1998.

6. Адреса авторов

Van Jacobson

Cisco Systems, Inc

170 W. Tasman Drive

San Jose, CA 95134-1706

EMail: [email protected]

 

Kathleen Nichols

Cisco Systems, Inc

170 W. Tasman Drive

San Jose, CA 95134-1706

EMail: [email protected]
Kedarnath Poduri

Bay Networks, Inc.

4401 Great America Parkway

Santa Clara, CA 95052-8185

EMail: [email protected]

---

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

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

[email protected]

Приложение A: Пример использования и опыт работы с EF PHB

A.1 Услуги VLL

Услуги VLL, называемые также приоритетным обслуживанием (Premium service) [2BIT] характеризуются пиковой полосой пропускания.

A.2 Опыт использования в ESNET

Прототип услуг VLL был развернут в опорной сети DOE ESNet с использованием очередей со взвешенным круговым обходом на базе маршрутизаторов Cisco серии 75xx для реализации EF PHB. Первые тесты были весьма успешными и продолжается работа по выводу сервиса на коммерческую эксплуатацию (см. ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf и ftp://ftp.ee.lbl.gov/talks/vj-i2qos-may98.pdf).

A.3 Результаты имитации

A.3.1 Вариации задержки

В параграфе 2.2 было отмечено, что для реализации EF PHB может использоваться множество механизмов. Простейшим вариантом является PQ¹⁰, где скорость поступления пакетов в очередь строго меньше скорости услуги¹¹. Поскольку задержки в очередях на пути доставки приводят к вариациям скорости, особенностью данного варианта является то, что микропотоки с маркировкой EF будут сталкиваться с незначительными вариациями скорости обслуживания. EF PHB не содержит явных требований к вариациям, но из определения ясно, что ожидаемые вариации для потока пакетов сервиса на основе EF PHB при использовании PQ будут меньше, нежели при обычной доставке¹². Были проведены эксперименты на макете для сравнения взвешенных очередей с циклической обработкой (WRR¹³) и PQ в плане вариаций. Эти два варианта были выбраны потому, что они представляют худший и лучший¹⁴ случай, соответственно, в плане возникновения вариаций и мы хотели предоставить разработчикам EF некие рекомендации по использованию WRR или аналогичных механизмов.

Экспериментальная сеть представляла собой модифицированный вариант стенда ns-2, описанного в [RFC2415] и [LCN]. Модули CBQ из состава ns-2 использовались в качестве базы для реализации приоритетной очереди м WRR. Топология модели включала шесть интервалов маршрутизации (hop) с уменьшающейся пропускной способностью в направлении одного узкого канала 1,5 Мбит/с (см. рисунок 6¹⁵). Отправители передают пакеты с маркировкой EF со средней скоростью, равной скорости услуги для них. Пакеты генерируются с разбросом ±10% в межпакетных интервалах относительно номинального значения для скорости услуги. Потоки отдельных источников объединялись в агрегат со скоростью 30% от полосы самого узкого канала (450 кбит/с). Для заполнения канала использовалась смесь пакетов FTP и HTTP. Каждый из источников пакетов EF генерировал пакеты одного размера 160 или 1500 байтов.

Хотя статистика представлена для потоков с одним размером пакетов, во всех экспериментах использовалась смесь коротких и длинных пакетов EF, поэтому очереди EF включали пакетов обоих размеров.

Определим вариации (jitter) как абсолютное значение разности между интервалами от поступления до отправки двух смежных пакетов (|(aj-dj) – (ai-di)|¹⁶). Для целевого потока в каждом эксперименте записывались значения вариаций для 50 и 90% пакетов, выраженные в процентах от скорости услуги EF, представленные в таблицах. Документ в формате pdf содержит также графики для вариаций.

Таблица 1: Зависимость вариаций от числа потоков EF

	1500 байтов		160 байтов
Число потоков EF	50%	90%	50%	90%
PQ (24)	1	5	17	43
2	11	47	96	513
4	12	35	100	278
8	10	25	96	126
24	18	47	96	143

В экспериментах сравнивались вариации для реализаций EF PHB на основе WRR и PQ. Оценивалось влияние различного выбора веса очередей WRR и числа очередей на вариации. Для WRR определено отношение скоростей обработка/прибытие как отношение скорости обслуживания для очереди EF (или минимальный расход очереди выходного канала) к пиковой скорости прибытия в очередь пакетов с маркировкой EF. Результат не будет стабильным, если вес WRR выбран для точного балансирования скоростей прибытия и отправки, поэтому используется минимальное отношение обслуживание/прибытие 1,03. В проведенных экспериментах это означает, что очередь EF получает не менее 31% выходных каналов. В экспериментах с WRR канал заполнялся до конца другим трафиком, как описано выше, с разделением трафика без маркировки EF между очередями, не относящимися к EF (из описания эксперимента должно быть ясно, что была предпринята попытка внести наибольшие вариации и не делается предположений, что такие установки и трафик отражают нормальную ситуацию).

Таблица 2: Зависимость вариаций от оношения скорости обработки и прибытия.

WRR	1500 байтов		160 байтов
Обработа/прибытие	50%	90%	50%	90%
PQ	1	3	17	43
1.03	14	27	100	178
1.30	7	21	65	113
1.50	5	13	57	104
1.70	5	13	57	100
2.00	5	13	57	104
3.00	5	13	57	100

В первой серии экспериментов использовалось минимальное отношение скоростей обслуживания/прибытия 1,06 и менялось число отдельных микропотоков, составляющих агрегат EF, от 2 до 36. Проведено сравнение полученных данных с результатами для PQ при 24 потоках. Сначала проверялся микропоток 1500-байтовых пакетов, передаваемых со скоростью услуги 56 кбит/с, а затем эксперимент повторялся для пакетов размером 160 байтов. Таблица 1 показывает значения вариаций для 50 и 90% пакетов (в процентах от времени передачи пакета при скорости услуги). Рисунок 1⁶ показывает графика для потока пакетов размером 1500 байтов, а рисунок 2 — для пакетов размером 160 байтов. Отметим, что «время пакета» размером 1500 байтов при скорости 56 кбит/с составляет 214 мсек, а для пакета в 160 байтов – 23 мсек. Вариации для больших пакетов редко превышают половину времени передачи пакета, хотя для мелких пакетов в большинстве случаев вариации не меньше времени передачи одного пакета. Следует принимать во внимание, что агрегат EF представляет собой смесь больших и мелких пакетов, поэтому короткие пакеты могут ожидать обработки длинных пакетов в очереди EF. PQ обеспечивает существенно меньшие вариации.

Далее исследовалось влияние роста отношения скоростей обслуживание/прибытие. Такой рост означает сокращение времени пребывания пакетов EF в очереди при сохранении полосы, доступной для других очередей. В этих экспериментах число потоков в агрегате EF было равно восьми, а общее число очередей – 5 (4 очереди для потоков без EF). Таблица 2 показывает результаты для потоков с размером пакетов 1500 и 160 байтов. Рисунок 3¹⁷ показывает графики для пакетов размером 1500 байтов, а рисунок 4 для пакетов размером 160 байтов. Performance gains leveled off at service-to-arrival ratios of 1.5. Отметим, что большие значения отношения скоростей обработки/прибытия не дают такой же производительности, как PQ, но в этом случае для 90% пакетов вариации не превышают время доставки даже для мелких пакетов.

Таблица 3: Зависимость вариаций от числа очередей на выходном интерфейсе

	1500 байтов
Число потоков EF	50%	90%
PQ (8)	1	3
2	7	21
4	7	21
6	8	22
8	10	23

Увеличение числа очередей на выходных интерфейсах может привести к росту вариаций времени обслуживания для пакетов EF, поэтому были проведены эксперименты с разным числом очередей на каждом выходном порту. Число потоков в агрегате было равно 8 и использовалось минимальное отношение скоростей обработки/прибытия 1,03. Результаты показаны на рисунке 5 и в таблице 3. Рисунок 5 включает также график для PQ с 8 потоками.

Видно, что в большинстве случаев вариации для WRR достаточно малы и могут быть дополнительно снижены выбором корректного соотношения между полосой очереди WRR на выходном канале и скоростью сервиса EF. Как было отмечено, WRR представляет собой худший случай, а PQ – лучший. Другие возможности включают WFQ или CBQ с фиксированным пределом скорости для очереди EF и предоставлением этой очереди приоритета по сравнению с другими очередями. Мы предполагаем, что это обеспечит производительность, близкую к PQ, хотя для проверки этого утверждения потребуются дополнительные эксперименты. Мы пока не исследовали систематически влияние числа интервалов маршрутизации, выделения для EF другой (не 30%) доли полосы канала и более сложной топологии. Приведенная здесь информация не является частью спецификации EF PHB и дана просто в качестве рекомендаций для разработчиков.

A.3.2 Сервис VLL

Таблица 4: Производительность FTP с использованием сервиса VLL

	Средняя скорость доставки (кбит/с)
Доля канала для EF (%)	Услуга	Арендованная линия	VLL
20	100	90	90
40	150	143	143
60	225	213	215

Мы использовали имитацию для проверки организации сервиса VLL на основе EF PHB. Проверялось сходство такого сервиса с арендованной линией, имеющей идентичную скорость. В этом эксперименте ни один пакет EF не был отброшен в сети и всегда достигалась нужная скорость для источников CBR¹⁸. Однако мы хотели увидеть, будет ли VLL вести себя «подобно проводам» для использующего сервис трафика TCP. Поэтому использовались долговременные соединения FTP на базе сервиса VLL. Таблица 4 показывает долю каждого канала, отданную для трафика EF (на каналах с меньшим числом микропотоков EF полоса была уже), скорость услуги VLL, средняя скорость для однотипной пары отправитель получатель, подключенной к полнодуплексному выделенному каналу со скоростью услуги и средняя скорость потоков VLL для каждого теста. Потери пакетов происходили только во входном буфере формовщика, но не в сети. Максимальная скорость не была достигнута в силу особенностей протокола TCP.

Полное заявление авторских прав

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Подтверждение

Финансирование функций RFC Editor обеспечивается Internet Society.