RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior)

Опубликовано 11.03.2002 автором Nikolai Malykh 
Network Working Group                                       B. Davie
Request for Comments: 3246                                 A. Charny
Obsoletes: 2598                                  Cisco Systems, Inc.
Category: Standards Track                             J.C.R. Bennett
                                                            Motorola
                                                           K. Benson
                                                             Tellabs
                                                      J.Y. Le Boudec
                                                                EPFL
                                                         W. Courtney
                                                                 TRW
                                                           S. Davari
                                                          PMC-Sierra
                                                           V. Firoiu
                                                     Nortel Networks
                                                        D. Stiliadis
                                                 Lucent Technologies
                                                          March 2002

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

An Expedited Forwarding PHB (Per-Hop Behavior)

PDF

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

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

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

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

Аннотация

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

1. Введение

Сетевые узлы, поддерживающие дифференцированное обслуживание для IP, используют код в заголовке IP для выбора поэтапного поведения (PHB), как специфического режима режима пересылки данного пакета [3, 4]. В этом документе описан PHB для ускоренной пересылки (EF).

Задачей EF PHB является обеспечение «строительных блоков» для создания служб с малыми потерями и задержками, а также низкими вариациями задержки. Детали построения таких услуг выходят за пределы данной спецификации.

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

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

Отметим, что EF PHB определяет только поведение одного узла. Спецификация поведения множества узлов выходит за пределы данного документа. Такую информацию может предоставить спецификация поведения на уровне домена (PDB3) [7].

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

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [2].

1.1. Связь с RFC 2598

Этот документ является заменой RFC 2598 [1]. Основным отличием данного документа является добавление математического формализма для более точного определения предлагаемого режима. Полное обоснование приведено в документе [6].

2. Определение EF PHB

2.1. Интуитивное описание EF

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

  • Сложно определить временной масштаб для измерения R. При измерении в течение короткого интервала могут вноситься ошибки выборки, а при достаточно большом интервале могут возникать значительные вариации.
  • EF явно не удастся обслуживать со скоростью R, если нет ожидающих обслуживания пакетов EF, но определение извне факта наличия ожидающих выходной обработки пакетов EF может оказаться затруднительным. Например, пакет, попавший на маршрутизатор, но не переданный дальше, может ждать обслуживания или просто столкнуться с той или иной задержкой при обработке или передаче в маршрутизаторе.

Приведенное ниже формальное определение учитывает эти обстоятельства. Оно предполагает, что пакеты EF следует обслуживать со скоростью R или быстрее и отличает реальное время отправки каждого пакета от «идеального» времени отправки. Время отправки пакета определяется, как время, в которое последний бит пакета был передан с узла. «Идеальное» время отправки рассчитывается путем итераций.

В случае, когда пакет EF прибывает на устройство в тот момент, когда все предшествующие пакеты EF уже отправлены, идеальное время отправки раcсчитывается просто. Обслуживание пакета следует (в идеале) начинать сразу по прибытии, поэтому идеальное время отправки отличается от времени прибытия на идеальное время передачи пакета со скоростью R. Для пакета размером L_j передача со скоростью R займет время L_j/R (естественно, что реальный пакет обычно будет передаваться со скоростью среды после того, как его передача начнется реально, но мы рассчитываем здесь идеальное поведение, поэтому можно брать скорость R).

Если пакет EF прибывает на устройство, где имеются пакеты EF, ожидающие обслуживания, расчет идеального времени отправки усложняется. Здесь рассматриваются два случая. Если предыдущая (j-1) отправка произошла после идеального времени, считается, что планировщик работает «с опозданием». В этом случае идеальным временем начала обслуживания нового пакета является идеальное время отправки предыдущего (j-1) пакета или время прибытия нового пакета (большее из двух значений), поскольку нельзя предположить, что обслуживание пакета начнется до его прихода. Если предыдущий (j-1) пакет был отправлен раньше идеального времени, считается, что планировщик работает «с опережением». В этом случае обслуживание нового пакета следует начинать в момент реальной отправки предыдущего пакета.

Когда известно время начала обслуживания (в идеале) j-ого пакета, идеальное время отправки этого пакета будет на L_j/R секунд больше. Таким образом, мы можем выразить идеальное время отправки j-ого пакета через время прибытия этого пакета, реальное и идеальное время отправки предыдущего (j-1) пакета. Уравнения eq_1 и eq_2 в параграфе 2.2 показывают эти зависимости.

Несмотря на то, что исходное определение EF не обеспечивает никаких гарантий для задержки конкретного пакета EF, способ обеспечения таких гарантий может быть желателен. По этой причине уравнения параграфа 2.2 состоят из двух частей, связанных с «поведением агрегата» и «осведомленных об отдельном пакете»5. Уравнения для поведения агрегата (eq_1 и eq_2) просто описывают свойства сервиса, предоставляемого устройством агрегату трафика EF. «Осведомленные о пакетах» уравнения (eq_3 и eq_4) позволяют оценить границы задержки для отдельного пакета на основе операционного состояния устройства. Значимость этих двух наборов уравнений дополнительно рассматривается в параграфе 2.2. Отметим, что эти два набора уравнений обеспечивают два способа описания поведения одного устройства, а не два разных режима.

2.2. Определение формата EF PHB

Узел, поддерживающий EF на интерфейсе I с некоторой заданной скоростью R, должен удовлетворять следующим уравнениям:

d_j <= f_j + E_a for all j > 0 (eq_1)

где f_j определяется итеративно выражением

f_0 = 0, d_0 = 0
f_j = max(a_j, min(d_j-1, f_j-1)) + l_j/R, for all j > 0 (eq_2)

В этом определении:

  • d_j – время, когда последний бит j-ого пакета EF реально уходит с интерфейса I.

  • f_j – целевое время отправки j-ого пакета EF с интерфейса I – «идеальное» время, до которого последнему биту пакета следует покинуть узел.
  • a_j – время, когда последний бит j-ого пакета EF, направленного на выход I, реально прибыл на узел.
  • l_j – размер (в битах) j-ого пакета EF для отправки через I. l_j относится к дейтаграмме IP (заголовок IP и данные) и не включает дополнительных полей нижележащих (например, MAC) уровней.
  • R – заданная для EF скорость на выходе I (бит/сек).
  • E_a – временное отклонение для агрегата EF. Отметим, что E_a представляет худший вариант отклонения реального времени отправки пакета EF от идеального времени его отправки (т. е., E_a определяет верхнюю границу разности d_j – f_j для всех j).
  • d_0 и f_0 не указывают реальное время отправки пакета и используются исключительно для рекурсии. Начало отсчета времени следует выбирать таким образом, чтобы в начальный момент в системе не было пакетов EF.
  • При определении a_j и d_j «последний бит» пакета включает трейлер уровня 2, если тот присутствует, поскольку в общем случае пакет не может считаться готовым к пересылке, пока не будет получен трейлер.

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

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

В дополнение к сказанному, узел, поддерживающий EF на интерфейсе I с некоторой заданной скоростью R, должен удовлетворять следующим уравнениям:

D_j <= F_j + E_p for all j > 0 (eq_3)

где F_j определяется итеративно выражениями

F_0 = 0, D_0 = 0
F_j = max(A_j, min(D_j-1, F_j-1)) + L_j/R, for all j > 0 (eq_4)

В этом определении:

  • D_j – реальное время отправки отдельного пакета EF, который поступил на узел для передачи через интерфейс I в момент A_j (т. е., для данного пакета, который был j-ым пакетом EF, полученным через любой вход и предназначенным для интерфейса I, значение D_j указывает время, когда последний бит данного пакета реально покинул узел через интерфейс I).

  • F_j – целевое время отправки отдельного пакета EF, который прибыл на узел для отправки через интерфейс I в момент A_j.
  • A_j – время, когда последний бит j-ого пакета EF, предназначенного для отправки через интерфейс I, реально прибыл на узел.
  • L_j – размер (в битах) j-ого пакета EF, прибывающего на узел и предназначенного для отправки через интерфейс I. L_j измеряется для дейтаграммы IP (заголовок IP и данные) и не включает полей нижележащего (например, MAC) уровня.
  • R – заданная для EF скорость на выходном интерфейса I (бит/сек).
  • E_p – временное отклонение для агрегата EF. Отметим, что E_p представляет худший вариант отклонения реального времени отправки пакета EF от идеального времени его отправки (т. е., E_p определяет верхнюю границу разности D_j – F_j для всех j).
  • D_0 и F_0 не указывают реальное время отправки пакета и используются исключительно для рекурсии. Начало отсчета времени следует выбирать таким образом, чтобы в начальный момент в системе не было пакетов EF.
  • При определении A_j и D_j «последний бит» пакета включает трейлер уровня 2, если тот присутствует, поскольку в общем случае пакет не может считаться готовым к пересылке, пока не будет получен трейлер.

D_j и F_j указывают время отправки для j-ого пакет, что делает уравнения eq_3 и eq_4 «осведомленными о пакетах». В этом заключается существенное отличие данной пары уравнений от двух первых уравнений этого параграфа.

Поддерживающему EF узлу следует быть способным характеризоваться диапазоном поддерживаемых значений R для каждого интерфейса, при которых узел соответствует приведенным выше уравнения, и значением E_p для каждого интерфейса. Значение E_p может быть задано , как худший случай для всех возможных значения R, или выражено, как функция R. Может быть также задано «неопределенное» значение E_p. Обсуждение ситуаций, в которых значение E_p становится неопределенным, приведено в приложении и документе [6].

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

2.3. Параметры качества

E_a и E_p можно рассматривать как «параметры качества» устройства. Малое значение E_a означает, что устройство обслуживает агрегат EF достаточно однородно со скоростью R в течение сравнительно коротких интервалов7, а большое значение E_a говорит о том, что более склонный к пикам планировщик обеспечивает обслуживание агрегата EF со скоростью R только при измерении в течение достаточно продолжительного периода8. В устройстве с большим значением E_a отклонение от идеальной скорости R будет наблюдаться для большего числа пакетов, нежели в устройстве с меньшим значением E_a.

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

Отмечено, что факторы, ведущие к росту E_a, как отмечено выше, будут также увеличивать значение E_p, и значение E_p обычно не меньше, чем E_a. В заключение отметим, что E_a является мерой отклонения от идеального обслуживания агрегата EF при скорости R, а E_p служит мерой отклонения от идеального обслуживания и отличной от FIFO9 обработки пакетов в агрегате.

Дополнительное обсуждение этих вопросов содержится в Приложении и документе [6].

2.4. Задержки и вариации

На основе значения E_p и информации о границах для трафика EF, обеспечиваемых данным выходным интерфейсом, с учетом всех входных интерфейсов можно определить границы задержки и ее вариаций, которые будут характеризовать трафик EF, выходящий с узла через данный интерфейс. Граница задержки будет выражаться уравнением

D = B/R + E_p (eq_5)

где

  • R – заданная для сервиса EF скорость на выходном интерфейсе;

  • общая загрузка трафиком EF, направляемым в данный выходной интерфейс, суммируемая по всем входным интерфейсам ограничивается «корзиной маркеров10» глубиной B со скоростью выхода r <= R.

Поскольку минимальная задержка в устройстве близка к нулю, значение D задает также предел вариаций задержки. Для более точного определения пределов вариаций можно задать значение E_p для устройства в форме двух раздельных компонент

E_p = E_fixed + E_variable

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

2.5. Потери

Задачей EF PHB является построение сервиса с малым уровнем потери пакетов. Однако при достаточно высоком уровне трафика EF (включая неожиданно сильные пики на многих входных интерфейсах одновременно) любое устройство с конечной буферной емкостью будет вынуждено отбрасывать пакеты. Следовательно, требуется возможность проверки соответствия устройства требованиям EF даже в условиях потери пакетов. Это осуществляется путем выполнения проверки на соответствие уравнениям 1 — 4 в режиме «off-line». После наблюдения последовательности пакетов входящих на узел и уходящих с него, пакеты, которые не ушли с узла, считаются потерянными и удаляются из входного потока. Оставшиеся пакеты после этого считаются прибывшим потоком (a_j), а пакеты, покинувшие узел, – потоком отправки (d_j). Соответствие уравнениям может быть проверено путем учета лишь тех пакетов, которые успешно прошли через узел.

В плане обеспечения малых потерь для пакетов EF узел может характеризоваться рабочим диапазоном, в котором не возникает потерь пакетов EF в результате насыщения. Это можно задать с использованием token bucket при скорости r <= R и размере пиков B, как сумму трафика через все входы на данный выходной интерфейс, для которой еще не будут возникать потери.

При наличии потерь спецификация теряемых пакетов выходит за пределы данного документа. Однако для сохранившихся пакетов должны выполняться уравнения параграфа 2.2.

2.6. Нарушение порядка в микропотоке

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

2.7. Рекомендуемый код для PHB

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

2.8. Изменяемость

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

2.9. Туннелирование

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

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

Другие PHB и группы PHB могут быть развернуты на одном узле или в домене DS с EF PHB. Уравнения параграфа 2.2 должны выполняться для трафика EF независимо от объемов другого трафика через узел.

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

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

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

В дополнение к этому кондиционирование трафика на входе домена DS должно обеспечивать маркировку кодом DSCP, соответствующим EF PHB внутри домена, только пакетов, промаркированных извне для EF PHB. Такое поведение требуется в соответствии с архитектурой дифференцированного обслуживания [4] и защищает от атак на отказ служб и несанкционированного улучшения обслуживания с использованием кодов DSCP, которые не указаны в спецификации кондиционирования трафика на входном интерфейсе. Эти спецификации предоставляются для входного интерфейса и отображаются на EF внутри домена DS.

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

Данный документ выделяет одно значение кода (101110) из набора 1 в пространстве кодов, определенном в [3].

5. Благодарности

Этот документ является результатом совместной работы и дискуссий множества людей. В частности, Fred Baker, Angela Chiu, Chuck Kalmanek и K. K. Ramakrishnan внесли существенный вклад в создание нового определения EF. Множество полезных комментариев дал авторам John Wroclawski. Этот документ опирается в значительной степени на исходное определение EF PHB, подготовленное Jacobson, Nichols и Poduri. Значительное влияние оказала также работа группы EFRESOLVE в составе Armitage, Casati, Crowcroft, Halpern, Kumar, Schnizlein.

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

[1] Jacobson, V., Nichols, K. and K. Poduri, “An Expedited Forwarding PHB”, RFC 2598, June 1999.

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

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

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

[5] Black, D., “Differentiated Services and Tunnels”, RFC 2983, October 2000.

[6] Charny, A., Baker, F., Davie, B., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis, “Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)”, RFC 3247, March 2002.

[7] Nichols K. and B. Carpenter, “Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification”, RFC 3086, April 2001.

Приложение: Примеры реализации

Это приложение не является частью нормативной спецификации EF и включено в качестве информационной помощи для разработчиков.

Различные факторы реализации узла, поддерживающего EF, будут оказывать влияние на значения E_a и E_p. Эти факторы подробно рассматриваются в документе [6] с учетом выходных планировщиков и внутренних особенностей устройства.

Очереди с приоритетами считаются каноническим примером реализации EF. Устройство с «совершенной» буферизацией (например, сразу доставляющее пакеты в подходящую выходную очередь) и приоритетной очередью для трафика EF будет обеспечивать малые значения для E_a и E_p. Отметим, что основным фактором, влияющим на E_a, будет неспособность прервать уже начавшуюся к моменту прихода на выходной интерфейс пакета EF передачу не относящегося к EF пакет размером MTU, а также дополнительная задержка, которая может быть вызвана непрерываемыми очередями между приоритетной очередью и физическим интерфейсом. Влияние на E_p будет оказывать, прежде всего, число интерфейсов.

Другим примером реализации EF является взвешенный циклический планировщик. Такие реализации обычно не способны поддерживать для R значение скорости среды, поскольку максимальная скорость обслуживания трафика EF при наличии конкурирующего трафика будет зависеть от числа и веса остальных очередей. Более того, очевидно, что такие реализации имеют более высокое значение E_a по сравнению с реализациями на основе приоритетных очередей, поскольку при прочих равных циклический планировщик будет расходовать время на обслуживание других (не EF) очередей.

Можно реализовать алгоритмы иерархического планирования (например, отличные от FIFO) для субпотоков агрегата EF, где агрегат EF в целом будет обслуживаться с высоким приоритетом или наибольшим весом в планировщике верхнего уровня. Такой алгоритм может, например, обеспечивать планирование на уровне входов или микропотоков в агрегате EF. Поскольку такие алгоритмы ведут к отличному от FIFO режиму обслуживания внутри агрегата EF, значение E_p для таких алгоритмов может оказаться выше, чем для других реализаций. Для некоторых планировщиков такого типа может оказаться затруднительным обеспечение значимой границы E_p, которая будет обеспечиваться при любой картине трафика, и, таким образом, может оказаться более приемлемым «неопределенное» значение.

Следует отметить, что для домена Diffserv приемлемо сосуществование множества экземпляров EF. Каждый экземпляр следует характеризовать уравнениями из параграфа 2.2 данной спецификации. Влияние множества экземпляров EF на значения параметров E_a и E_p каждого экземпляра будет существенно зависеть от реализации экземпляров. Например, в многоуровневом планировщике с приоритетами экземпляр EF, который не имеет высшего приоритета, может сталкиваться со сравнительно продолжительными периодами отсутствия обслуживания в то время, как экземпляры EF с высшим приоритетом будут обслуживаться. Это может приводить к существенному росту значений E_a и E_p. Напротив, при использовании планировщика типа WFQ каждый экземпляр EF будет представлен очередью, обслуживаемой с некоторой заданной скоростью, и значения E_a и E_p не будут значительно отличаться от варианта с использованием единственного экземпляра EF.

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

Bruce Davie

Cisco Systems, Inc.

300 Apollo Drive

Chelmsford, MA, 01824

EMail: bsd@cisco.com

Anna Charny

Cisco Systems

300 Apollo Drive

Chelmsford, MA 01824

EMail: acharny@cisco.com

Jon Bennett

Motorola

3 Highwood Drive East

Tewksbury, MA 01876

EMail: jcrb@motorola.com

Kent Benson

Tellabs Research Center

3740 Edison Lake Parkway #101

Mishawaka, IN 46545

EMail: Kent.Benson@tellabs.com

Jean-Yves Le Boudec

ICA-EPFL, INN

Ecublens, CH-1015

Lausanne-EPFL, Switzerland

EMail: jean-yves.leboudec@epfl.ch

Bill Courtney

TRW

Bldg. 201/3702

One Space Park

Redondo Beach, CA 90278

EMail: bill.courtney@trw.com

Shahram Davari

PMC-Sierra Inc

411 Legget Drive

Ottawa, ON K2K 3C9, Canada

EMail: shahram_davari@pmc-sierra.com

Victor Firoiu

Nortel Networks

600 Tech Park

Billerica, MA 01821

EMail: vfiroiu@nortelnetworks.com

Dimitrios Stiliadis

Lucent Technologies

101 Crawfords Corner Road

Holmdel, NJ 07733

EMail: stiliadi@bell-labs.com

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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (2002). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

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

1Per-hop behavior.

2Expedited Forwarding.

3Per-Domain Behavior.

4Differentiated Services – дифференцированное обслуживание. Прим. перев.

5В оригинале «packet-identity-aware». Прим. перев.

6В оригинале «random tie-breaking method». Прим. перев.

7«Мгновенная» скорость обслуживания соответствует заданному значению R. Прим. перев.

8Значению R соответствует только средняя скорость обслуживания агрегата. Прим. перев.

9First In, First Out – обслуживание в порядке поступления. Прим. перев.

10Token bucket.

11Denial of service attack.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.