3. Рекомендации по заданию поведения на этапе
Базовые требования по спецификации поведения на этапах приведены в [RFC2474]. В этом разделе требования детализируются путем описания дополнительных рекомендаций относительно спецификаций для PHB и групп. Это сделано, прежде всего, для обечпечения согласованности реализаций. Прежде, чем группа PHB будет предложена для стандартизации, следует выполнить эти рекомендации подобающим образом, что обеспечит целостность архитектуры.
G.1: Стандарт PHB должен задавать рекомендуемое значение кода DS, выбранное из пространства, зарезервированного для стандартных отображений [RFC2474]. Рекомендуемые коды распределяются IANA. Предложение PHB может рекомендовать временный код из пространства EXP/LU для использования в междоменных экспериментах. Определение PHB для пакетов не должно требовать использования полей заголовка, отличных от DS.
G.2: В спецификацию каждой предлагаемой новой группы PHB следует включать обзор поведения и цель предлагаемого поведения. В обзор следует включать описание проблем(ы), для решения которых предназначена данная группа PHB, а также базовые концепции, связанные с группой PHB. В эти концепции следует включать по крайней мере описание поведения очередей, отбрасывания пакетов, выбора выходного канала. В конце обзора следует включить спецификацию метода, посредством которого группа PHB решает проблемы, указанные в описании.
G.3: В спецификации группы PHB следует указывать число отдельных PHB в группе. При задании множества PHB следует четко описать взаимодействие между всеми PHB в группе и ограничения при таком взаимодействии. В качестве примера укажем, что спецификация должна рассматривать возможность повышения вероятности изменения порядка следования пакетов в микропотоке в результате маркировки этих пакетов для разных PHB в группе.
G.4: Когда корректное функционирование группы PHB зависит от ограничений (таких, как ограничения в обеспечении), в определение PHB следует включать описание поведения в случае нарушения таких ограничений. Более того, если нужны такие действия, как отбрасывание пакетов или смена порядка, эти действия следует оговаривать явно.
G.5: Группа PHB может быть специфицирована для локального использования в домене с целью обеспечения специфической для данного домена функциональности или услуг. В этом случае спецификация PHB полезна для предоставления производителям согласованного определения группы PHB. Однако любые группы PHB, определенные для локального применения, не следует стандартизовать, что не препятствует их публикации в виде информационных RFC. Напротив, группы PHB, предназначенные для общего пользования, должны строго следовать процессу стандартизации. Следовательно, все предложения PHB должны содержать сведения о локальном или глобальном использовании группы.
Понятно, что группы PHB могут разрабатываться для обеспечения услуг между хостами, краевыми узлами сетей WAN и/или краевыми узлами доменов. Термин «сквозной» (end-to-end) в определении PHB следует трактовать как «между хостами» (host-to-host).
Группы PHB могут определяться и развертываться локально внутри доменов для экспериментов или в рабочем режиме. К таким группам не предъявляется требование публикации документов, но для этих групп PHB следует использовать коды DS из пулов EXP/LU, определенных в [RFC2474].
G.6: Возможны случаи, когда пакеты, помеченные для PHB в группе, могут быть перемаркированы для выбора другого PHB в той же группе, Такая перемаркировка может осуществляться внутри домена или для пакетов, проходящих через границу домена. Обычно замена PHB обусловлена одной из трех причин:
Коды, связанные с группой PHB, предназначены для передачи информации о состоянии сети.
Существуют ситуации, когда от PHB требуется повышение или снижение уровня приоритета для пакета (это предполагает некое ранжирование PHB внутри группы).
Граница между доменами не покрывается SLA. К этом случае код/PHB для выбора при прохождении через пограничный канал определяется локальной политикой восходящего домена.
В спецификации PHB следует четко указывать обстоятельства, при которых пакеты, помеченные для PHB в группе, можно или следует изменить (например, повысить или снизить приоритет) для отнесения к другому PHB в той же группе. Если изменение PHB для пакета нежелательно, в спецификации следует четко описать риски, связанные со сменой PHB. Возможным риском, связанным с заменой для пакета PHB (внутри группы или на другую группу PHB), является изменение порядка следования пакетов в микропотоке. PHB в группе могут переносить некоторую семантику взаимодействия между хостами, краевыми узлами WAN или доменов и дублирование этой семантики при перемаркировке пакетов для выбора иного PHB может оказаться затруднительным.
Для некоторых групп PHB может оказаться желательным отражение смены состояния путем перемаркировки пакетов для задания другого PHB в той же группе. Если группа PHB разработана для отражения состояний сети, определение PHB должно подобающим образом описывать связи между PHB и состояниями, которые они отражают. Более того, если эти PHB ограничены операциями по пересылке, которые может выполнять узел, эти ограничения могут быть описаны, как действия, которые узлу следует или необходимо выполнять.
G.7: В спецификацию группы PHB следует добавить раздел, определяющий включение туннелирования в свойства группы PHB. В этом разделе следует описать использование группы PHB из внешнего заголовка, когда исходное поле DS из внутреннего заголовка инкапсулировано в туннель. Также в этом разделе следует рассмотреть возможные изменения, которые могут выполняться по отношению к внутреннему заголовку на выходе туннеля, когда становятся доступными коды как из внешнего, так и из внутреннего заголовка (см. параграф 6.2).
G.8: Очевидно, что процесс спецификации групп PHB является инкрементным по своей природе. Когда предлагается новая группа PHB, следует документировать ее понятные взаимодействия с ранее определенными группами PHB. Создаваемая группа PHB может быть совсем новой или являться расширением какой-либо из существующих групп PHB. Если группа PHB полностью независима от всех или некоторых существующих спецификаций PHB, в спецификацию такой группы PHB следует включать раздел, описывающий сосуществование новой группы PHB с ранее стандартизованными группами PHB. Например, такой раздел может указывать возможность изменения порядка следования пакетов в микропотоке для пакетов, промаркированных кодами, которые связаны с двумя разными группами PHB. Если одновременная работа двух (или более) разных групп PHB на одном узле невозможна или может причинять вред, этот факт следует указывать в спецификации. Если одновременная работа двух (или более) разных групп PHB требует некого специфического режима, когда пакеты, маркированные для PHB из этих разных групп будут одновременно обрабатываться узлом, такое поведение должно быть отражено в спецификации.
Следует принимать меры против возникновения цикличности в определениях групп PHB.
Если предлагаемая группа PHB является расширением существующей группы, в спецификацию группы PHB следует включать раздел, описывающей взаимодействие этого расширения с расширяемым режимом. Если расширение изменяет или сужает определение режима тем или иным способом, этот факт следует указывать явно.
G.9: В каждую спецификацию PHB следует включать раздел, описывающий минимальные требования к реализациям, соответствующим данной спецификации. Такой раздел предназначен для того, чтобы разработчики могли понимать, какие функции должны быть реализованы и какие могут служить расширением, дозволенным спецификацией. Этот раздел может быть представлен в виде правил, таблиц, псевдокода или тестов.
G.10: В спецификацию PHB следует включать раздел, рассматривающий вопросы защиты режима. В этот раздел следует включать обсуждение перемаркировки кодов во внутреннем заголовке на выходе туннеля и воздействие этой перемаркировки на желаемый режим пересылки.
В этот раздел также следует включать обсуждение вопроса возможности использования предлагаемой группы PHB для атак на службы, атак на нарушение сервисных контрактов и снижение уровня обслуживания. Наконец, в этом разделе следует обсудить возможные методы детектирования атак, имеющие отношение к предлагаемому режиму.
G.11: В спецификацию PHB следует включать раздел, описывающий вопросы настройки и управления, способные влиять на работу PHB и служб, которые могут использоваться PHB.
G.12: Настоятельно рекомендуется включать в спецификацию приложение, описывающее влияние предлагаемого поведения на существующий и возможный сервис, включая (но не ограничиваясь) услуги, связанные с пользователями, устройствами, доменами или сквозной сервис. Настоятельно рекомендуется также включать в приложение раздел, описывающий верификацию услуг со стороны пользователей, устройств и/или доменов.
G.13: В каждую спецификацию PHB рекомендуется включать приложение, содержащее руководство по выбору PHB для пакетов, которые пересылаются в домены, не поддерживающие данную группу PHB.
G.14: В каждую спецификацию PHB рекомендуется включать приложение, которое рассматривает влияние предлагаемой группы PHB на существующие протоколы вышележащих уровней. При некоторых обстоятельствах PHB может разрешать изменения в протоколах вышележащих уровней, способные повышать или снижать полезность предлагаемой группы PHB.
G.15: В каждую спецификацию PHB рекомендуется включать приложение, которое рекомендует отображения на механизмы QoS канального уровня для поддержки желаемого режима PHB в сетях с разделяемой и коммутируемой на канальном уровне средой. Выбор наиболее подходящего отображения между PHB и механизмами QoS канального уровня зависит от множества факторов, которые выходят за пределы данного документа, однако в спецификации следует привести некоторые рекомендации по выбору такого отображения.