О документе
Рабочая группа сети P. Karn, ред.
Запрос комментариев: 3819 Qualcomm
BCP: 89 C. Bormann
Категория: Лучшая современная практика Universitaet Bremen TZI
G. Fairhurst
University of Aberdeen
D. Grossman
Motorola, Inc.
R. Ludwig
Ericsson Research
J. Mahdavi
Novell
G. Montenegro
Sun Microsystems Laboratories, Europe
J. Touch
USC/ISI
L. Wood
Cisco Systems
Июль 2004
Рекомендации для разработчиков интернет-подсетей
1. Введение и обзор
IP, интернет-протокол [RFC791] [RFC2460], является основным
протоколом Интернета. IP определяет простую сеть с коммутацией
пакетов «без установления соединения». Успех Интернета в значительной
мере объясняется простотой IP, «сквозным принципом» [SRC81], на
котором основан Интернет, и обусловленной этим простотой переноса IP
по широкому разнообразию подсетей, которые не обязательно
проектировались с учётом IP. Подсетью называется любая сеть,
работающая непосредственно ниже уровня IP для соединения двух или
более систем, использующих IP (то есть конечных узлов или
маршрутизаторов). В простейшей форме это может быть прямое соединение
между IP-системами (например, посредством отрезка кабеля или
беспроводной среды).
В этом документе подсеть определяется как сеть уровня 2, то есть
сеть, которая не полагается на службы IP-маршрутизаторов для
пересылки пакетов между частями подсети. Однако IP-маршрутизаторы
могут выполнять мостовую передачу кадров на уровне 2 между частями
подсети. Иногда удобно объединить группу таких подсетей в одну
логическую подсеть. Протоколы IP-маршрутизации (например, OSPF,
IS-IS и PIM) можно настроить для поддержки такого объединения, но
обычно они представляют подсеть уровня 3, а не подсеть уровня 2. Это
также может приводить к тому, что конкретный пакет несколько раз
проходит по одной и той же подсети уровня 2 через промежуточный шлюз
уровня 3 (маршрутизатор). Поскольку такое объединение требует
компонентов уровня 3, связанные с ним вопросы выходят за рамки этого
документа.
Однако, хотя многие подсети переносят IP, они не обязательно делают
это с максимальной эффективностью, минимальной сложностью или
стоимостью, а также не обязательно реализуют определённые функции,
позволяющие эффективно поддерживать новые, приобретающие всё большую
важность функции Интернета, такие как многоадресная передача или
качество обслуживания.
В условиях взрывного роста Интернета IP-пакеты составляют всё более
значительную долю трафика, переносимого телекоммуникационными сетями
мира. Поэтому имеет смысл оптимизировать как существующие, так и
новые технологии подсетей для IP настолько, насколько это возможно.
Оптимизация подсети для IP включает три взаимодополняющих
соображения:
1. Предоставление функциональности, достаточной для переноса IP.
2. Устранение ненужных функций, которые увеличивают стоимость или
сложность.
3. Выбор параметров подсети, максимизирующих производительность
интернет-протоколов.
Поскольку IP настолько прост, соображение 2 представляет большую
проблему, чем соображение 1. Иными словами, разработчики подсетей
совершают гораздо больше ошибок действия, чем ошибок бездействия.
Однако некоторые усовершенствования функций Интернета, такие как
многоадресная передача и качество обслуживания, существенно выигрывают
от поддержки, предоставляемой нижележащими подсетями сверх той,
которая необходима для переноса «традиционного» одноадресного IP с
доставкой по мере возможности.
Важным соображением при эффективном проектировании любой многоуровневой
сети связи является выбор подходящего уровня или уровней для
реализации заданной функции. Этот вопрос впервые был рассмотрен в
основополагающей статье «End-to-End Arguments in System Design»
[SRC81]. В этой статье утверждалось, что многие функции могут быть
корректно реализованы *только* сквозным образом, то есть на высших
уровнях протокола, вне подсети. К этим функциям относятся обеспечение
надёжной доставки данных и использование криптографии для обеспечения
конфиденциальности и целостности сообщений.
Такие функции нельзя предоставить исключительно путём объединения
служб на каждом участке; дублирование этих функций на нижних уровнях
протокола (то есть внутри подсети) может быть излишне избыточным или
даже вредным для стоимости и производительности.
Однако частичное дублирование функциональности на нижнем уровне
*иногда* может быть оправдано соображениями производительности,
безопасности или доступности. Примеры включают повторную передачу на
канальном уровне для повышения производительности необычно подверженного
потерям канала, например мобильного радиоканала, шифрование на уровне
канала, предназначенное для противодействия анализу трафика, а также
резервные линии передачи для повышения доступности, увеличения
пропускной способности или гарантирования производительности для
определённых классов трафика. Дублирование функций протокола следует
выполнять только с пониманием последствий на уровне системы, включая
возможные взаимодействия с механизмами верхних уровней.
Первоначальная архитектура Интернета находилась под влиянием сквозного
принципа [SRC81] и, по нашему мнению, была одной из причин успеха
Интернета.
Остальная часть этого документа рассматривает различные вопросы
проектирования подсетей, которые авторы считают значимыми для
эффективной поддержки IP.
2. Максимальные единицы передачи (MTU) и IP-фрагментация
Пакеты IPv4 (дейтаграммы) различаются по размеру: от 20 байтов
(размер одного только заголовка IPv4) до максимума в 65535 байтов.
Подсети не обязаны поддерживать IP-пакеты максимального размера
(64KB), поскольку IP предоставляет схему, разбивающую пакеты,
слишком большие для данной подсети, на фрагменты, которые передаются
как независимые IP-пакеты и собираются вновь в пункте назначения.
Максимальный размер пакета, поддерживаемый подсетью, известен как её
максимальная единица передачи (MTU).
Подсети могут, но не обязаны, указывать длину каждого переносимого ими
пакета. Одним из примеров является Ethernet с широко используемым
заголовком DIX [DIX82] (а не IEEE 802.3 [IEEE8023]), в котором
отсутствует поле длины для указания фактической длины данных, когда
пакет дополняется до минимального размера в 60 байтов. Это не является
проблемой для несжатого IP, поскольку каждый IP-пакет содержит
собственное поле длины.
Однако если используется необязательное сжатие заголовка [RFC1144]
[RFC2507] [RFC2508] [RFC3095], необходимо, чтобы формирование кадров
канала указывало длину кадра, поскольку она нужна для восстановления
исходного заголовка.
В IP версии 4 (версии, ныне широко применяемой) фрагментация может
происходить либо на отправляющем узле, либо в промежуточном
маршрутизаторе, а фрагменты при необходимости могут дополнительно
фрагментироваться на последующих маршрутизаторах.
В IP версии 6 [RFC2460] фрагментация может происходить только на
отправляющем узле; она не может происходить в маршрутизаторе
(именуемая в этом документе «фрагментацией маршрутизатором»).
И IPv4, и IPv6 предоставляют процедуру «обнаружения MTU пути»
[RFC1191] [RFC1435] [RFC1981], которая позволяет отправляющему узлу
избежать фрагментации, обнаруживая минимальный MTU вдоль заданного
пути и соответственно уменьшая размеры своих пакетов. Эта процедура
необязательна в IPv4 и IPv6.
Обнаружение MTU пути широко развёрнуто, но иногда сталкивается с
проблемами. Некоторые маршрутизаторы не генерируют сообщения ICMP,
передающие отправителю информацию о MTU пути, а иногда сообщения ICMP
блокируются чрезмерно ограничительными межсетевыми экранами. Результатом
может быть «чёрная дыра MTU пути» [RFC2923] [RFC1435].
Процедура обнаружения MTU пути, сохранение чёрных дыр MTU пути и
исключение фрагментации маршрутизатором из IPv6 отражают консенсус
технического сообщества Интернета в том, что фрагментации
маршрутизатором лучше избегать. Это требует, чтобы подсети поддерживали
MTU «разумно» большого размера. Все конечные узлы IPv4 обязаны
принимать и собирать вновь IP-пакеты размером 576 байтов [RFC791], но
столь малое значение было бы явно неэффективным. Поскольку IPv6 не
предусматривает фрагментацию маршрутизаторами, [RFC2460] определяет
больший минимальный MTU в 1280 байтов. Любая подсеть с внутренней
полезной нагрузкой пакета менее 1280 байтов должна реализовать
механизм, выполняющий фрагментацию и повторную сборку IP-пакетов в
кадры подсети и из кадров подсети, если она должна поддерживать IPv6.
Если подсеть не может непосредственно поддерживать «разумный» MTU
собственными механизмами формирования кадров, ей следует внутренне
фрагментировать пакеты. То есть ей следует прозрачно разбивать
IP-пакеты на внутренние элементы данных и собирать их вновь на другом
конце подсети.
Остаётся вопрос о том, какой MTU является «разумным». Ethernet (10 и
100 Мбит/с) имеет MTU 1500 байтов, и вследствие повсеместного
распространения Ethernet немногие интернет-пути в настоящее время
имеют MTU больше этого значения. Это существенно ограничивает
полезность более крупных MTU, предоставляемых другими подсетями. В то
же время более крупные MTU становятся всё более желательными в
высокоскоростных подсетях для уменьшения накладных расходов на
обработку каждого пакета в хост-компьютерах, и разработчикам
рекомендуется предоставлять их, даже если они могут быть неприменимы,
когда Ethernet также находится на пути.
Различные схемы «туннелирования», такие как GRE [RFC2784] или IP Security в туннельном режиме [RFC2406], рассматривают IP как подсеть для IP. Поскольку туннелирование добавляет накладные расходы заголовков, оно может вызвать фрагментацию, даже когда по обе стороны хоста, выполняющего инкапсуляцию IPsec, используются одни и те же физические подсети (например, Ethernet). Туннелирование усложнило предотвращение фрагментации маршрутизаторами и увеличило частоту появления чёрных дыр MTU пути [RFC2401] [RFC2923]. Более крупные MTU подсети могут помочь смягчить эту проблему.
2.1. Выбор MTU в медленных сетях
В медленных сетях передача пакета наибольшего возможного размера может занимать значительное время. Это известно как задержка канализации или сериализации. Общее интерактивное время отклика от конца до конца не должно превышать общеизвестный предел, связанный с человеческими факторами, в 100–200 мс. Оно включает все источники задержки: задержку электромагнитного распространения, задержку в очереди, задержку сериализации и время накопления и пересылки, то есть время передачи пакета со скоростью канала.
При низких скоростях канала задержки накопления и пересылки могут преобладать в общей задержке от конца до конца; на них, в свою очередь, непосредственно влияет размер максимальной единицы передачи (MTU). Даже если интерактивному пакету назначен более высокий приоритет в очереди, ему может потребоваться дождаться завершения передачи большого пакета массовой передачи данных. Эта наихудшая задержка ожидания может быть задана надлежащим выбором MTU.
Например, если MTU установлена в 1500 байтов, пакет размером с MTU будет передаваться около 8 миллисекунд по каналу T1 (1.536 Мб/с). Но если скорость канала составляет 19.2 кб/с, время передачи становится равным 625 мс — значительно выше нашего предела в 100–200 мс. MTU размером 256 байтов уменьшила бы эту задержку до немногим более 100 мс. Однако следует соблюдать осторожность, чтобы не уменьшать MTU чрезмерно, поскольку это увеличит накладные расходы заголовков и вызовет частую фрагментацию маршрутизаторами (если не используется обнаружение MTU пути). Вероятно, именно так будет при многоадресной рассылке, где обнаружение MTU пути неэффективно.
Один из способов ограничить задержку для интерактивного трафика, не устанавливая малую MTU, — назначить этому трафику приоритет и вытеснять (прерывать)
передачу пакета с более низким приоритетом, когда в очереди появляется пакет с более высоким приоритетом. Однако ресурсы канала, использованные для передачи прерванного пакета, теряются, и общая пропускная способность уменьшится.
Другой способ ограничить задержку — реализовать схему мультиплексирования канального уровня, допускающую одновременное нахождение нескольких пакетов в процессе передачи, при этом приоритет передачи предоставляется сегментам IP-пакетов с более высоким приоритетом. Для каналов, использующих протокол Point-To-Point Protocol (PPP) [RFC1661], такую возможность предоставляет многоканальная связь нескольких классов [RFC2686] [RFC2687] [RFC2689].
ATM (асинхронный режим передачи), в котором SNDU фрагментируются и чередуются между меньшими 53-байтовыми ячейками ATM, является ещё одним примером этого метода. Однако ATM обычно используется на высокоскоростных каналах, где задержки накопления и пересылки уже минимальны, и он вносит значительное увеличение накладных расходов (~9%) вследствие добавления 5-байтовых накладных расходов ячейки к каждой 48-байтовой ячейке ATM.
Третий пример — Data-Over-Cable Service Interface Specification (DOCSIS) с типичной восходящей пропускной способностью 2.56 Мб/с или 5.12 Мб/с. Чтобы уменьшить влияние MTU размером 1500 байтов в DOCSIS 1.0 [DOCSIS1], в DOCSIS 1.1 [DOCSIS2] определён механизм фрагментации канального уровня. Для обеспечения совместимости с установленной базой DOCSIS 1.1 должна быть обратно совместима с кабельными модемами DOCSIS 1.0, которые обычно не поддерживают фрагментацию. При совместном существовании DOCSIS 1.0 и DOCSIS 1.1 нефрагментированные большие пакеты данных от кабельных модемов DOCSIS 1.0 могут влиять на качество обслуживания голосовых пакетов от кабельных модемов DOCSIS 1.1. В этом случае в [DOCSIS3] показано, что использование алгоритмов распределения полосы пропускания может смягчить этот эффект.
Подводя итог, при проектировании подсети существует фундаментальный компромисс между эффективностью и задержкой, и разработчику следует помнить об этом компромиссе.
3. Кадрирование в ориентированных на соединение подсетях
IP требует, чтобы подсети отмечали начало и конец каждого асинхронного IP-пакета переменной длины. Вот некоторые примеры каналов и подсетей, которые не предоставляют этого как внутренне присущее свойство:
1. выделенные линии, передающие синхронный поток битов;
2. B-каналы ISDN, передающие синхронный поток октетов;
3. телефонные модемы коммутируемого доступа, передающие асинхронный поток октетов;
и
4. сети Asynchronous Transfer Mode (ATM), передающие асинхронный поток «ячеек» фиксированного размера.
Интернет-сообщество определило методы кадровой синхронизации пакетов для всех этих подсетей. Point-To-Point Protocol (PPP) [RFC1661], использующий вариант HDLC, применим к битово-синхронным, октетно-синхронным и октетно-асинхронным каналам (то есть к примерам 1–3 выше). PPP является одним из предпочтительных методов кадровой синхронизации для IP, поскольку большое число систем взаимодействует с PPP. ATM имеет собственные методы кадровой синхронизации, описанные в [RFC2684] [RFC2364].
На высоких скоростях подсети следует предоставлять кадрированный интерфейс, способный переносить асинхронные IP-дейтаграммы переменной длины. Максимальный размер пакета, поддерживаемый этим интерфейсом, рассмотрен выше в разделе MTU/Fragmentation. Подсеть может реализовать эту возможность любым удобным способом.
Границы IP-пакетов не обязаны совпадать с какими-либо механизмами кадровой синхронизации или синхронизации, внутренними для подсети. Когда подсеть реализует единицы данных переменного размера, наиболее прямой подход состоит в помещении ровно одного IP-пакета в каждую единицу данных подсети (SNDU) и в использовании уже существующей способности подсети определять границы SNDU также для определения границ IP-пакетов. Хорошим примером является Ethernet. Однако некоторые подсети имеют SNDU одного или нескольких фиксированных размеров, определяемых соображениями коммутации, прямого исправления ошибок и/или чередования. Примеры таких подсетей включают ATM, с единственным размером полезной нагрузки ячейки в 48 октетов плюс 5-октетный заголовок, и цифровую сотовую связь IS-95, с двумя «наборами скоростей» по четыре фиксированных размера кадров в каждом, которые могут выбираться на границах 20 миллисекунд.
Поскольку IP-пакеты имеют переменную длину, они не обязательно могут поместиться в целое кратное число SNDU фиксированного размера. Для преобразования IP-пакетов в SNDU с одновременной отметкой границы между каждым IP-пакетом некоторым способом необходим «уровень адаптации».
Существует несколько подходов к этой проблеме. Первый заключается в кодировании каждого IP-пакета в одну или несколько SNDU, причём ни одна SNDU не содержит частей более чем одного IP-пакета, и дополнении последней SNDU пакета по мере необходимости. Биты в управляющем заголовке, добавляемом к каждой SNDU, указывают, какое место сегмент данных занимает в IP-пакете. Если подсеть предоставляет упорядоченную доставку не более одного раза, заголовок может быть таким простым, как пара битов, указывающих, является ли SNDU первой и/или последней в IP-пакете. В качестве альтернативы для подсетей, которые не изменяют порядок фрагментов SNDU, можно было бы помечать только последнюю SNDU пакета, поскольку это неявно
указывало бы следующую SNDU как первую в новом IP-пакете. Схема AAL5 (ATM Adaptation Layer 5), используемая с ATM, является примером этого подхода, хотя она добавляет и другие возможности, включая поле длины полезной нагрузки и CRC полезной нагрузки.
В AAL5 ATM User-User Indication, которая кодируется в поле Payload Type ячейки ATM, указывает последнюю ячейку пакета. Трейлер пакета расположен в конце SNDU и содержит длину пакета и CRC.
Другой метод кадровой синхронизации состоит во вставке накладных данных для каждого сегмента, указывающих наличие опции сегмента. Когда опция присутствует, она содержит указатель на конец пакета. Это отличается от AAL5 тем, что допускает следование другого пакета в пределах того же сегмента. MPEG-2 Transport Streams [EN301192] [ISO13818] поддерживают этот стиль фрагментации и могут либо использовать дополнение (ограничивая каждый пакет транспортного потока MPEG переносом только части одного IP-пакета), либо разрешать начало второго IP-пакета в том же пакете Transport Stream (без дополнения).
Третий подход заключается во вставке специальной последовательности флагов в поток данных между каждыми IP-пакетами и упаковке результирующего потока данных в SNDU безотносительно границ SNDU. Это может иметь последствия при утрате кадров. Последовательность флагов также может дополнять неиспользуемое пространство в конце SNDU. Если специальный флаг появляется в пользовательских данных, он экранируется альтернативной последовательностью (обычно длиннее флага), чтобы избежать ошибочного истолкования в качестве флага. Все схемы кадровой синхронизации на основе HDLC, используемые в PPP, являются примерами этого подхода.
Все три схемы адаптации добавляют накладные расходы; их величина зависит от распределения размеров IP-пакетов, размера (размеров) SNDU и, в подходах, подобных HDLC, от содержимого IP-пакета (поскольку последовательности, подобные флагам, возникающие в пакете, должны экранироваться, что увеличивает их размер). Разработчик также должен сопоставить сложность реализации и производительность при выборе и проектировании уровня адаптации.
4. Ориентированные на соединение подсети
IP не имеет понятия «соединение»; это чисто протокол без установления соединения. Когда соединение требуется приложению, оно обычно предоставляется TCP [RFC793], Transmission Control Protocol, работающим поверх IP на сквозной основе.
Ориентированные на соединение подсети могут использоваться (и широко используются) для переноса IP, но часто со значительной сложностью. Подсети, состоящие из небольшого числа узлов, могут просто открывать постоянное соединение между каждой парой узлов. Это часто делается с ATM. Однако число соединений увеличивается пропорционально квадрату числа узлов, поэтому это
явно непрактично для больших подсетей. Поэтому для управления соединениями необходим «промежуточный» уровень между IP и подсетью. Это одна из наиболее распространённых функций подуровня Subnetwork Dependent Convergence Function (SNDCF) между IP и подсетью.
SNDCF обычно открывают соединения подсети по необходимости, когда IP-пакет поставлен в очередь на передачу, и закрывают их по истечении тайм-аута бездействия. Между соединениями подсети и любыми соединениями, которые могут существовать на более высоких уровнях (например, TCP), нет связи.
Поскольку интернет-трафик обычно является импульсным и ориентированным на транзакции, часто трудно выбрать оптимальный тайм-аут бездействия. Если тайм-аут слишком короткий, соединения подсети быстро открываются и закрываются, возможно, чрезмерно нагружая систему управления соединениями подсети (особенно если она была разработана для времени удержания вызовов голосового трафика). Если тайм-аут слишком долгий, соединения подсети значительную часть времени бездействуют, растрачивая любые ресурсы, выделенные им подсетью.
Чисто подсети без установления соединения (такие как Ethernet), не имеющие состояния и динамически совместно использующие ресурсы, оптимальны для поддержки IP с негарантированной доставкой, который не имеет состояния и динамически совместно использует ресурсы. Ориентированные на соединение пакетные сети (такие как ATM и Frame Relay), которые имеют состояние и динамически совместно используют ресурсы, менее оптимальны, поскольку IP с негарантированной доставкой не получает выгоды от накладных расходов на создание и поддержание состояния. Ориентированные на соединение сети с коммутацией каналов (включая PSTN и ISDN) имеют состояние и статически выделяют ресурсы для вызова и поэтому требуют накладных расходов на создание и поддержание состояния, но не получают выгоды от эффективности статистического мультиплексирования совместного использования пропускной способности, присущей IP.
В любом случае, если для поддержки IP используется SNDCF, открывающая и закрывающая соединения подсети, следует позаботиться о том, чтобы обработка соединений в подсети могла справляться с относительно короткими временами удержания.
5. Широковещание и обнаружение
Подсети подразделяются на две категории: двухточечные и совместно используемые. Двухточечная подсеть имеет ровно два оконечных компонента (хоста или маршрутизатора); совместно используемый канал имеет более двух оконечных компонентов, используя либо среду, изначально поддерживающую широковещание (например, Ethernet, радио), либо уровень коммутации, скрытый от сетевого уровня (например, коммутируемый Ethernet, Myrinet [MYR95], ATM). Коммутируемые подсети обрабатывают широковещание путём копирования широковещательных пакетов, предоставляя каждому интерфейсу, поддерживающему одну или несколько систем (хостов или маршрутизаторов), копию каждого пакета.
Несколько интернет-протоколов для IPv4 используют возможности широковещания, включая поиск адресов канального уровня (ARP), автоматическую конфигурацию (RARP, BOOTP, DHCP) и маршрутизацию (RIP).
Отсутствие возможности широковещательной передачи может ухудшать производительность этих протоколов или делать их неработоспособными (например, DHCP). Поиск адреса канального уровня, подобный ARP, может обеспечиваться централизованной базой данных, но ценой потенциально более высокой задержки ответа и необходимости для узлов явно знать адрес сервера ARP. Совместно используемые каналы следует оснащать поддержкой нативной широковещательной передачи в подсети на канальном уровне.
Соответствующий набор протоколов IPv6 использует многоадресную рассылку (см. следующий раздел) вместо широковещательной передачи для обеспечения сходных функций с улучшенной масштабируемостью в крупных сетях.
6. Многоадресная рассылка
Модель Интернета включает «многоадресную рассылку», при которой IP-пакеты отправляются всем участникам группы многоадресной рассылки [RFC1112] [RFC3376] [RFC2710]. Многоадресная рассылка является опцией в IPv4, но стандартной возможностью IPv6. В настоящее время многоадресная рассылка IPv4 используется приложениями для мультимедиа, телеконференций, игр и распространения файлов (web, совместный обмен между равноправными узлами), а также некоторыми ключевыми сетевыми протоколами и протоколами хостов (например, RIPv2, OSPF, NTP). IPv6 дополнительно полагается на многоадресную рассылку для конфигурирования сети (автоконфигурации, подобной DHCP) и обнаружения адресов канального уровня [RFC2461] (заменяя ARP). В случае IPv6 это может позволять автоконфигурации и обнаружению адресов распространяться через маршрутизаторы, тогда как службы IPv4 на основе широковещательной передачи не могут этого без специальной поддержки маршрутизатора [RFC1812].
IP-маршрутизаторы с поддержкой многоадресной рассылки организуют каждую группу многоадресной рассылки в остовное дерево и маршрутизируют многоадресные пакеты, создавая копии каждого многоадресного пакета и пересылая эти копии на каждый выходной интерфейс, включающий по меньшей мере одного расположенного ниже по потоку участника группы многоадресной рассылки.
Многоадресная рассылка значительно эффективнее, когда подсеть явно поддерживает её. Например, маршрутизатору, ретранслирующему многоадресный пакет в сегмент Ethernet, достаточно отправить только одну копию пакета независимо от того, сколько участников группы многоадресной рассылки подключено к сегменту. Без нативной поддержки многоадресной рассылки маршрутизаторам и коммутаторам на совместно используемых каналах потребовалось бы использовать широковещательную передачу с программными фильтрами, так что каждый отправленный многоадресный пакет создавал бы программные накладные расходы для каждого узла в подсети, даже если узел не является участником группы многоадресной рассылки. В качестве альтернативы маршрутизатор передавал бы отдельную копию каждому участнику группы многоадресной рассылки в сегменте, как это делается в коммутируемых подсетях без возможности многоадресной рассылки.
Подсети, использующие совместно используемые каналы (например, радио-LAN, Ethernet), особенно подходят для нативной многоадресной рассылки, и их проектировщикам следует прилагать все усилия для её поддержки. Это предполагает выделение участка собственного адресного пространства подсети для многоадресной рассылки. В таких сетях многоадресная рассылка в основном представляет собой широковещательную передачу в среде передачи с фильтрами получателей уровня 2.
Интерфейсы подсети также необходимо проектировать так, чтобы они принимали пакеты, адресованные некоторому числу многоадресных адресов, в дополнение к одноадресным пакетам, адресованным непосредственно им. Число многоадресных адресов, которое должен поддерживать хост, зависит от требований соответствующего хоста; по меньшей мере несколько десятков удовлетворят большинству текущих потребностей.
В низкоскоростных сетях функцию распознавания многоадресных адресов можно без труда реализовать в программном обеспечении хоста, но в высокоскоростных сетях её следует реализовать в аппаратном обеспечении подсети. Это аппаратное обеспечение не обязательно должно быть полным; например, многие интерфейсы Ethernet реализуют функцию «хеширования», при которой IP-уровень получает весь трафик многоадресной (и одноадресной) рассылки, на который подписан соответствующий хост, плюс некоторую малую долю трафика многоадресной рассылки, на который хост не подписан. Затем программное обеспечение хоста/маршрутизатора должно отбрасывать нежелательные пакеты, прошедшие фильтр многоадресных адресов уровня 2 [RFC1112].
Нет необходимости в однозначном соответствии между многоадресным адресом уровня 2 и IP-адресом многоадресной рассылки. Перекрытие адресов может значительно ухудшить способность аппаратного фильтра многоадресных адресов получателя к фильтрации. Подсети, поддерживающей только широковещательную передачу, следует использовать эту службу для многоадресной рассылки и должна полагаться на программную фильтрацию.
Коммутируемые подсети также должны предоставлять механизм копирования многоадресных пакетов, обеспечивающий, что пакеты достигают по меньшей мере всех участников группы многоадресной рассылки. Один из вариантов — «затопление» многоадресных пакетов тем же способом, что и широковещательных. Это может приводить к ненужным передачам по некоторым каналам подсети (в частности, на коммутаторах Ethernet, не учитывающих многоадресную рассылку). Поэтому некоторые подсети позволяют таблицам фильтров многоадресной рассылки управлять тем, какие каналы получают пакеты, принадлежащие определённой группе. Для автоматической настройки этого требуется доступ к информации об участии в группах уровня 3 (например, IGMP [RFC3376] или MLD [RFC2710]). В настоящее время существуют различные варианты реализации для предоставления узлу подсети списка отображений многоадресных адресов на порты/интерфейсы. В них применяется ряд подходов, включая сигнализацию от конечных хостов (например, IEEE 802 GARP/GMRP [802.1p]), сигнализацию от коммутаторов (например, CGMP [CGMP] и RGMP [RFC3488]), перехват и проксирование IP-пакетов об участии в группах (например, прокси IGMP/MLD [MAGMA-PROXY]), а также предоставление устройствам уровня 2 возможности отслеживать/инспектировать/заглядывать в заголовки пересылаемых протоколов уровня 3 (например,
IGMP, MLD, PIM), чтобы они могли выводить участие в группах многоадресной рассылки уровня 3 [MAGMA-SNOOP]. Эти подходы различаются по сложности, гибкости и способности поддерживать новые протоколы.
7. Подсети с предоставлением полосы пропускания по запросу (BoD)
Некоторые подсети позволяют нескольким узлам подсети эффективно совместно использовать канал, динамически назначая возможности передачи. Возможности передачи запрашиваются узлом подсети, когда у него есть пакеты для отправки. Подсеть планирует и предоставляет возможности передачи, достаточные для того, чтобы передающий узел подсети мог отправить один или несколько пакетов (либо фрагментов пакетов). Мы называем такие подсети подсетями с предоставлением полосы пропускания по запросу (Bandwidth on Demand, BoD). Примеры подсетей BoD включают спутниковые и наземные беспроводные сети Demand Assignment Multiple Access (DAMA), режим функции координации точек (PCF) IEEE 802.11 и DOCSIS. Сеть с установлением соединения (такая как PSTN, ATM или Frame Relay) резервирует ресурсы в значительно большем временном масштабе и поэтому не является подсетью BoD в нашей таксономии.
Параметры проектирования для BoD сходны с параметрами в подсетях с установлением соединения, хотя реализации могут значительно различаться. В BoD пользователь обычно запрашивает доступ к совместно используемому каналу на некоторую продолжительность. Доступ может быть выделен на период времени с определённой скоростью, для определённого числа пакетов или до тех пор, пока пользователь не освободит канал. Доступ может координироваться через центральный управляющий объект или распределённым алгоритмом между пользователями. Примеры ресурса, который может совместно использоваться, включают наземный беспроводной переход, восходящий канал в системе кабельного телевидения, спутниковый канал «земля—спутник» и сквозной спутниковый канал.
Подсети BoD с большой задержкой создают проблемы, сходные с подсетями с установлением соединения, при прогнозировании трафика. В то время как подсети с установлением соединения держат незанятые каналы открытыми в ожидании поступления новых данных, подсети BoD запрашивают доступ к каналу на основе заполненности буфера (или ожидаемой заполненности буфера) на отправляющем порту. Вероятно, будет получена низкая производительность, если отправитель не предвидит дополнительный трафик, поступающий на этот порт за время, необходимое для предоставления запроса на передачу. Рекомендуется, чтобы алгоритм имел возможность продлевать удержание канала для данных, поступивших после формирования исходного запроса (это может быть сделано путём включения новых запросов в пользовательские данные).
Доступно большое разнообразие протоколов BoD. Однако было проведено сравнительно мало всесторонних исследований взаимодействий между механизмами BoD и производительностью протоколов Интернета. Имеются исследования некоторых конкретных механизмов (например, [AR02]). Одним из изученных вопросов является таймер повторной передачи TCP [KY02]. BoD
системы могут вызывать ложные тайм-ауты при переходе с относительно высокой скорости передачи данных на относительно низкую скорость передачи данных. В этом случае переданным TCP данным требуется больше времени для прохождения через сеть, чем предсказано вычисленным отправителем TCP тайм-аутом повторной передачи. Поэтому отправитель TCP склонен преждевременно повторно отправлять сегмент.
8. Надёжность и контроль ошибок
В архитектуре Интернета окончательная ответственность за восстановление после ошибок лежит на конечных точках [SRC81]. Интернет может иногда отбрасывать, повреждать, дублировать или изменять порядок пакетов, и транспортный протокол (например, TCP) или приложение (например, если UDP используется в качестве транспортного протокола) должны восстанавливаться после этих ошибок сквозным образом [RFC3155]. Поэтому восстановление после ошибок в подсети оправдано лишь в той мере, в какой оно может улучшить общую производительность. Важно понимать, что подсеть может зайти слишком далеко в стремлении предоставлять службы восстановления после ошибок в среде Интернета. Надёжности подсети следует быть «лёгкой», то есть ей достаточно быть «достаточно хорошей», *а не* совершенной.
В этом разделе мы обсуждаем, как анализировать характеристики подсети, чтобы определить, что является «достаточно хорошим». Приведённое ниже обсуждение сосредоточено на TCP, который является наиболее широко используемым транспортным протоколом в Интернете. Широко распространено мнение (и это заявленная цель IETF), что транспортным протоколам, отличным от TCP, следует стремиться быть «дружественными к TCP» и иметь многие из тех же характеристик производительности. Таким образом, приведённое ниже обсуждение должно быть применимо даже к частям Интернета, где TCP может не быть преобладающим протоколом.
8.1. TCP в сравнении с повторной передачей на канальном уровне
Восстановление после ошибок включает создание и передачу избыточной информации, вычисленной на основе пользовательских данных. В зависимости от того, какой объём избыточной информации отправляется и как он формируется, получатель может использовать её для надёжного обнаружения ошибок передачи, исправления до некоторого максимального числа ошибок передачи либо для того и другого. Общий подход известен как кодирование для контроля ошибок, или ECC.
Использование ECC для обнаружения ошибок передачи, чтобы можно было запрашивать повторные передачи (будем надеяться, без ошибок), широко известно как «ARQ» (Automatic Repeat Request).
Когда доступно достаточно информации ECC, позволяющей получателю исправлять некоторые ошибки передачи без повторной передачи, этот подход известен как прямое исправление ошибок (Forward Error Correction, FEC). Из-за большей сложности требуемого ECC и необходимости адаптировать его проектирование к характеристикам конкретного модема и канала FEC
традиционно реализовывался в специализированном аппаратном обеспечении, являющемся неотъемлемой частью модема. Фактически это делает его частью физического уровня.
В отличие от ARQ, FEC до 1990-х годов редко использовался для телекоммуникаций вне космических каналов. Сейчас он почти повсеместно применяется в телефонных, кабельных и DSL-модемах, цифровых спутниковых каналах и цифровых мобильных телефонах. FEC также широко используется в оптических и магнитных носителях данных, где «повторные передачи» невозможны.
Некоторые системы используют гибридные комбинации ARQ, расположенного поверх FEC; один из примеров — модемы коммутируемого доступа V.90 (в восходящем направлении) с контролем ошибок V.42. Большинство ошибок исправляются кодом с решётчатой структурой (FEC) внутри модема V.90, а большинство оставшихся ошибок обнаруживаются и исправляются механизмами ARQ в V.42.
В настоящее время ведётся работа по применению FEC выше физического уровня, главным образом в связи с надёжной многоадресной рассылкой [RFC3048] [RFC3450-RFC3453], где традиционные механизмы ARQ неэффективны или трудны в реализации. Однако в этом обсуждении мы будем предполагать, что при наличии FEC он реализован на физическом уровне.
В зависимости от уровня, на котором он реализован, контроль ошибок может работать сквозным образом или на более коротком участке, таком как отдельный канал. TCP является важнейшим примером сквозного протокола, использующего стратегию ARQ.
Многие протоколы канального уровня используют ARQ, обычно некоторый вариант HDLC [ISO3309]. Примеры включают канальный уровень X.25, протокол AX.25, используемый в любительской пакетной радиосвязи, беспроводные LAN 802.11 и надёжный канальный уровень, определённый в IEEE 802.2.
Только сквозное восстановление после ошибок может обеспечить надёжную службу для приложения (см. раздел 8). Однако некоторые подсети (например, многие беспроводные каналы) также имеют восстановление после ошибок на канальном уровне как средство повышения производительности [RFC3366]. Например, многие сотовые каналы имеют малые размеры физических кадров (< 100 байт) и относительно высокую частоту потери кадров. Опора исключительно на сквозное восстановление после ошибок явно может приводить к ухудшению производительности, поскольку повторные передачи по сквозному пути принимаются значительно дольше, чем при использовании повторных передач канального уровня. Таким образом, восстановление после ошибок на канальном уровне часто может повысить сквозную производительность. В результате восстановление на канальном и сквозном уровнях часто сосуществуют; это может приводить к возможности неэффективных взаимодействий между протоколами ARQ двух уровней.
Эта межуровневая «конкуренция» может приводить к следующей
расточительной ситуации. Когда канальный уровень повторно передаёт
(части) пакета, задержка канала на некоторое время увеличивается.
Поскольку TCP основывает свой
тайм-аут повторной передачи на предыдущих измерениях суммарной
сквозной задержки, включая задержку рассматриваемого канала, это
внезапное увеличение задержки может вызвать ненужную повторную
передачу TCP пакета, который канальный уровень всё ещё повторно
передаёт. Такие ложные сквозные повторные передачи создают ненужную
нагрузку и уменьшают сквозную пропускную способность. В результате
канальный уровень может даже одновременно иметь несколько копий
одного и того же пакета в одной очереди канала. В общем случае можно
сказать, что конкурирующее восстановление после ошибок вызвано
внутренним контуром управления (восстановлением после ошибок
канального уровня), реагирующим на тот же сигнал, что и внешний
контур управления (сквозным восстановлением после ошибок), без какой-
либо координации между контурами. Обратите внимание, что это касается
исключительно эффективности; TCP продолжает обеспечивать надёжную
сквозную доставку по таким каналам.
В связи с этим возникает вопрос, насколько настойчивым следует быть
отправителю канального уровня при выполнении повторной передачи
[RFC3366]. Мы определяем настойчивость ARQ канального уровня (LL) как
максимальное время, в течение которого конкретный канал будет
пытаться передать пакет, прежде чем его можно будет отбросить. Это
намеренно упрощённое определение ничего не говорит о максимальном
числе повторных передач, стратегиях повторной передачи, размерах
очередей, дисциплинах обслуживания очередей, задержках передачи и
тому подобном. Причина, по которой мы используем термин
«настойчивость LL ARQ» вместо термина наподобие «максимальное время
удержания пакета на канальном уровне», состоит в том, что определение
тесно связано с восстановлением после ошибок канального уровня.
Например, на каналах, реализующих прямолинейные стратегии
восстановления после ошибок, настойчивость LL ARQ часто будет
соответствовать максимальному числу повторных передач, разрешённых
для каждого кадра канального уровня.
Для канальных уровней, которые не различают или не могут различать
потоки (например, из-за шифрования сетевого уровня), настойчивость
LL ARQ следует делать небольшой. Это позволяет избежать каких-либо
вредных воздействий или ухудшения производительности вследствие
неизбирательно высокой настойчивости. Подробное обсуждение этих
вопросов приведено в [RFC3366].
Однако, когда канальный уровень может идентифицировать отдельные
потоки и применять ARQ избирательно [LKJK02], настойчивость ARQ
канала следует делать высокой для потока, использующего надёжные
одноадресные транспортные протоколы (например, TCP), и она должна
быть низкой для всех остальных потоков. Установка настойчивости ARQ
канала выше, чем наибольшая недоступность канала, позволяет TCP
быстро восстановить передачу, не дожидаясь истечения тайм-аута
повторной передачи. В целом это улучшает производительность TCP при
временных недоступностях. Однако чрезмерно высокая настойчивость
может быть невыгодна; может быть желателен практический верхний
предел в 30-60 секунд. Реализация таких схем остаётся предметом
исследований. (См. также следующий раздел «Восстановление после
недоступности подсети».)
У многих разработчиков подсетей есть возможности снизить вероятность
потери пакетов, например с помощью FEC, ARQ и перемежения, ценой
увеличения задержки. Производительность TCP улучшается при снижении
потерь, но ухудшается при увеличении сквозной задержки, поэтому важно
найти надлежащий баланс посредством анализа и моделирования.
8.2. Восстановление после недоступности подсети
Некоторые типы подсетей, особенно мобильные радиосети, подвержены
частым временным недоступностям. Например, активный пользователь
сотовой передачи данных может въехать или войти в область (такую как
туннель), находящуюся вне зоны действия любой базовой станции. Ни
один пакет не будет успешно доставлен, пока пользователь не вернётся
в область с покрытием.
В настоящее время протоколы Интернета не предоставляют стандартного
способа для подсети явно уведомить протокол верхнего уровня (например,
TCP), что она испытывает недоступность, а не серьёзную перегрузку.
В этих обстоятельствах TCP после каждой неуспешной повторной
передачи будет ждать ещё дольше, прежде чем попытаться снова; таков
его алгоритм «экспоненциальной отсрочки». Кроме того, TCP не обнаружит,
что недоступность подсети закончилась, до своей следующей попытки
повторной передачи. Если TCP увеличил отсрочку, это может занять
некоторое время. Это может привести к крайне низкой производительности
TCP в таких подсетях.
Поэтому весьма желательно, чтобы подверженная недоступностям подсеть
не отбрасывала пакеты молча во время недоступности. В идеале подсети
следует определить интерфейс со следующим более высоким уровнем (то
есть IP), позволяющий ей отклонять пакеты во время недоступности
и автоматически запрашивать у IP новые пакеты, когда она снова сможет
их доставлять. Если она не может этого сделать, то подсети следует
удерживать по меньшей мере некоторые из пакетов, которые она принимает
во время недоступности, и пытаться доставить их, когда недоступность
закончится. Когда пакеты отбрасываются, IP следует уведомлять, чтобы
могли быть отправлены соответствующие сообщения ICMP.
Обратите внимание, что *не* обязательно полностью избегать отбрасывания
пакетов во время недоступности. Цель удержания пакета во время
недоступности — либо в подсети, либо на уровне IP — состоит в том,
чтобы его последующая доставка неявно уведомила TCP, что подсеть снова
работоспособна. Это предназначено для повышения производительности,
а не для обеспечения надёжности — надёжность, как обсуждалось ранее,
может быть обеспечена только на сквозной основе.
Достаточно удерживать таким образом лишь несколько пакетов на
соединение TCP, включая ACK, чтобы после возобновления потока
отправитель TCP восстановился от дополнительных потерь [RFC3366].
Поскольку для IP или уровня подсети просмотр заголовков TCP был бы
нарушением уровневой архитектуры (и, возможно, снижением
производительности) — и в любом случае был бы невозможен при
использовании шифрования IPsec [RFC2401] — IP или уровни подсети могли
бы разумно выбирать в качестве параметра проектирования некоторое
небольшое число пакетов, которые будут сохраняться во время
недоступности.
8.3. CRC, контрольные суммы и обнаружение ошибок
Протоколы TCP [RFC793], UDP [RFC768], ICMP и IPv4 [RFC791] все
используют один и тот же простой 16-битный алгоритм контрольной суммы
с дополнением до единицы [RFC1071] для обнаружения повреждённых
пакетов. Контрольная сумма заголовка IPv4 защищает только заголовок
IPv4, тогда как контрольные суммы TCP, ICMP и UDP обеспечивают
сквозное обнаружение ошибок как для псевдозаголовка транспорта
(включая информацию сетевого и транспортного уровней), так и для
данных полезной нагрузки транспорта. Защита данных необязательна для
приложений, использующих UDP [RFC768] для IPv4, но обязательна для
IPv6.
Контрольная сумма Интернета не очень сильна с точки зрения теории
кодирования, но её легко вычислять программно, и различные предложения
заменить контрольные суммы Интернета более сильными контрольными
суммами потерпели неудачу. Однако известно, что необнаруженные ошибки
могут возникать и действительно возникают в пакетах, полученных
конечными хостами [SP2000].
Для снижения затрат на обработку IPv6 не имеет контрольной суммы
заголовка IP. Конечный хост обнаруживает «важные» ошибки в заголовке
IP, такие как доставка пакета не тому получателю. Это делается путём
включения IP-адресов источника и назначения (псевдозаголовка) в
вычисление контрольной суммы в заголовке TCP или UDP — практика,
уже выполняемая в IPv4. Ошибки в других полях заголовка IPv6 могут
остаться необнаруженными в сети; это считалось разумной ценой за
значительное сокращение обработки, требуемой каждым маршрутизатором,
и предполагалось, что подсети будут использовать надёжный канальный
CRC.
Один из способов обеспечить дополнительную защиту заголовка IPv4 или
IPv6 — использовать службы аутентификации и целостности пакетов
протокола IP Security (IPsec) [RFC2401]. Однако для разработчика
подсети это может быть недоступным вариантом.
Большинство подсетей реализуют обнаружение ошибок непосредственно над
физическим уровнем. Пакеты, повреждённые при передаче, обнаруживаются
и отбрасываются до доставки на уровень IP. 16-битная циклическая
проверка избыточности (CRC) обычно является минимумом для обнаружения
ошибок. Она существенно более устойчива к большинству шаблонов ошибок,
чем 16-битная контрольная сумма Интернета. Обратите внимание, что
свойства обнаружения ошибок конкретного кода CRC ухудшаются с
увеличением размера кадра. Point-to-Point Protocol [RFC1662] требует
поддержки 16-битного CRC
для каждого кадра канала, с 32-битным CRC в качестве варианта. (PPP
часто используется совместно с модемом коммутируемого доступа, который
обеспечивает собственное управление ошибками.) Другие подсети, включая
802.3/Ethernet, AAL5/ATM, FDDI, Token Ring и PPP поверх SONET/SDH, все
используют 32-битный CRC. Многие подсети также могут использовать
другие механизмы для усиления способности канального CRC обнаруживать
ошибки (например, FEC в модемах коммутируемого доступа, каналах
мобильной радиосвязи и спутниковых каналах).
Поэтому любой новой подсети, предназначенной для переноса IP, следует
обеспечивать обнаружение ошибок для каждого IP-пакета, по меньшей мере
столь же сильное, как 32-битный CRC, указанный в [ISO3309]. Хотя это
позволит достичь очень низкой частоты необнаруженных ошибок пакетов,
вызванных ошибками передачи, оно не позволит (и не обязано позволить)
достичь очень низкой частоты потерь пакетов, поскольку протоколы
Интернета лучше приспособлены для обработки потерянных пакетов, чем
повреждённых пакетов [SRC81].
Повреждение пакетов также может быть и действительно вызывается
ошибками в аппаратном и программном обеспечении хостов и
маршрутизаторов. Даже если бы каждая подсеть реализовала надёжное
обнаружение ошибок, всё равно существенно необходимо, чтобы на
принимающем конечном хосте использовались сквозные контрольные суммы
[SP2000].
Разработчикам сложных подсетей, состоящих из внутренних каналов и
коммутаторов пакетов, следует рассмотреть реализацию обнаружения
ошибок от границы до границы, охватывающего весь SNDU (или IP-пакет).
CRC генерировался бы в точке входа в подсеть и проверялся в конечной
точке выхода. Это может использоваться вместо обнаружения ошибок на
интерфейсе к каждому физическому каналу или в сочетании с ним.
Проверка от границы до границы имеет существенное преимущество:
защищает от ошибок, внесённых в любом месте внутри подсети, а не
только в её каналах передачи. Примеры этого подхода включают способ,
которым CRC-32 Ethernet обрабатывается мостами LAN [802.1D]. ATM AAL5
[ITU-I363] также использует CRC-32 от границы до границы.
Некоторые конкретные приложения могут быть терпимы к остаточным
ошибкам в данных, которыми они обмениваются, но удаление канального
CRC может подвергнуть сеть нежелательному увеличению необнаруженных
ошибок в заголовках IP и транспорта. Приложениям также может требоваться
высокий уровень защиты от ошибок для управляющей информации, которой
обмениваются протоколы, действующие выше транспортного уровня. Один
пример — голосовой кодек, устойчивый к битовым ошибкам в образцах речи.
Чтобы такие механизмы работали, принимающее приложение должно быть
способно переносить получение повреждённых данных. Это также требует,
чтобы приложение использовало механизм для сигнализации о допустимости
повреждения полезной нагрузки и для указания охвата (заголовков и
данных), который должен быть защищён CRC подсети. Протокол UDP-Lite
[RFC3828] является первым транспортным протоколом Интернета на пути
стандартизации, поддерживающим частичную защиту полезной нагрузки.
Получение повреждённых данных произвольными
протоколами приложений несёт серьёзную опасность того, что подсеть
доставит данные с ошибками, которые останутся необнаруженными
приложением и вследствие этого повредят передаваемые данные [SRC81].
8.4. Как работает TCP
Одна из функций TCP — управление перегрузкой Интернета на основе
конечных хостов. Это критически важная часть общей стабильности
Интернета, поэтому важно, чтобы разработчики канального уровня
понимали алгоритмы управления перегрузкой TCP.
TCP предполагает, что на наиболее абстрактном уровне сеть состоит из
каналов и очередей. Очереди обеспечивают выходную буферизацию на
каналах, которые временно перегружены. Они сглаживают мгновенные
всплески трафика, чтобы он соответствовал пропускной способности
канала. Когда спрос превышает ёмкость канала достаточно долго, чтобы
заполнить очередь, пакеты необходимо отбрасывать. Традиционное действие
отбрасывания самого последнего пакета («отбрасывание хвоста») более не
рекомендуется [RFC2309] [RFC2914], но всё ещё широко практикуется.
TCP использует нумерацию последовательностей и подтверждения (ACK) на
сквозной основе, чтобы обеспечивать надёжную упорядоченную доставку.
Подтверждения TCP являются накопительными, то есть каждое неявно
подтверждает каждый сегмент, полученный к этому моменту. Если получен
пакет с неожиданным номером последовательности, поле ACK в пакетах,
возвращаемых получателем, перестанет увеличиваться. Используя
необязательное усовершенствование, TCP может отправлять выборочные
подтверждения (SACK) [RFC2018], чтобы указать, какие сегменты прибыли
к получателю.
Поскольку наиболее распространённой причиной потери пакетов является
перегрузка, TCP рассматривает потерю пакета как признак потенциальной
перегрузки Интернета на пути между конечными узлами TCP. Это происходит
автоматически, и подсети не требуется ничего знать об IP или TCP. Узел
подсети просто отбрасывает пакеты всякий раз, когда вынужден это делать,
хотя некоторые стратегии отбрасывания пакетов (например, RED) более
справедливы по отношению к конкурирующим потокам, чем другие.
TCP восстанавливается после потерь пакетов двумя различными способами.
Наиболее важный механизм — тайм-аут повторной передачи. Если ACK не
поступает по прошествии некоторого периода времени, TCP повторно передаёт
самый старый неподтверждённый пакет. Воспринимая это как указание на то,
что сеть перегружена, TCP ожидает подтверждения повторной передачи, прежде
чем продолжить, и постепенно увеличивает число пакетов в полёте, пока
тайм-аут не произойдёт снова.
Тайм-аут повторной передачи может налагать существенный штраф на
производительность, поскольку отправитель бездействует в течение интервала
тайм-аута и после тайм-аута начинает заново с окном перегрузки в один
сегмент TCP.
Чтобы обеспечить более быстрое восстановление после случайной потери
пакета при передаче большого объёма данных, была введена альтернативная
схема, известная как «быстрое восстановление» ("fast recovery") [RFC2581]
[RFC2582] [RFC2914] [TCPF98].
Быстрое восстановление опирается на тот факт, что при потере одного
пакета при передаче большого объёма данных получатель продолжает возвращать
для последующих пакетов данных ACK, которые фактически не подтверждают
никаких вновь полученных данных. Они известны как «дублирующие
подтверждения» ("duplicate acknowledgments") или «dupacks». Отправляющий
TCP может использовать dupacks как указание на потерю пакета и повторно
передать его, не дожидаясь тайм-аута. Dupacks фактически образуют
отрицательное подтверждение (NAK) для номера последовательности пакета в
поле подтверждения. TCP ожидает, пока не будет получено определённое число
dupacks (в настоящее время 3), прежде чем предположить, что произошла
потеря; это помогает избежать ненужной повторной передачи при доставке не
по порядку.
Метод, называемый «явным уведомлением о перегрузке» (Explicit Congestion
Notification, ECN) [RFC3168], позволяет маршрутизаторам непосредственно
сигнализировать узлам о перегрузке без отбрасывания пакетов. Это делается
установкой бита в заголовке IP. Поскольку поддержка ECN, вероятно, останется
необязательной, отсутствие бита ECN *никогда* не должно интерпретироваться
как отсутствие перегрузки. Поэтому в обозримом будущем TCP должен
интерпретировать потерянный пакет как сигнал перегрузки.
Алгоритм TCP «предотвращения перегрузки» ("congestion avoidance")
[RFC2581] поддерживает окно перегрузки (cwnd), управляющее объёмом данных,
который TCP может иметь в полёте в любой момент. Уменьшение cwnd уменьшает
общую полосу пропускания, получаемую соединением; аналогично, увеличение
cwnd повышает производительность вплоть до предела доступной ёмкости.
TCP исследует доступную ёмкость сети, первоначально устанавливая cwnd в
один или два пакета, а затем увеличивая cwnd на один пакет для каждого ACK,
возвращённого получателем. Это механизм TCP «медленного старта» ("slow
start"). Когда обнаруживается потеря пакета (или о перегрузке сигнализируют
другие механизмы), cwnd сбрасывается до единицы, и процесс медленного старта
повторяется, пока cwnd не достигнет половины своего предыдущего значения до
сброса. Cwnd продолжает увеличиваться после этой точки, но с гораздо меньшей
скоростью, чем прежде. Если дальнейших потерь не происходит, cwnd в
конечном итоге достигнет размера окна, объявленного получателем.
Это алгоритм «аддитивное увеличение, мультипликативное уменьшение»
(Additive Increase, Multiplicative Decrease, AIMD). Резкое уменьшение cwnd
в ответ на перегрузку обеспечивает стабильность сети; алгоритм AIMD также
обеспечивает справедливость между длительно работающими TCP-соединениями,
использующими один и тот же путь.
8.5. Характеристики производительности TCP
Предостережение
Здесь мы представляем современное понимание производительности TCP,
соответствующее «современному уровню техники». Этот анализ пытается
охарактеризовать производительность TCP-соединений на линиях связи с
различными характеристиками.
Разработчики линий связи могут пожелать использовать методы из этого
раздела для прогнозирования производительности, которой TCP/IP может
достичь при новом проекте канального уровня. Такой анализ приветствуется.
Поскольку это относительно новый анализ, а теория основана на
однопоточных TCP-соединениях в «идеальных» условиях, следует признать,
что результаты такого анализа могут отличаться от фактической
производительности в Интернете. Сказав это, мы сделали всё возможное,
чтобы предоставить разработчикам полезную информацию для получения точного
представления о возможностях и ограничениях TCP в различных условиях.
8.5.1. Формулы
Производительность алгоритма предотвращения перегрузки TCP AIMD была
широко проанализирована. Текущая наилучшая формула для производительности
конкретных алгоритмов, используемых Reno TCP (то есть TCP, определённого в
[RFC2581]), приведена Padhye и др. [PFTK98]. Эта формула имеет вид:
MSS
BW = --------------------------------------------------------
RTT*sqrt(1.33*p) + RTO*p*[1+32*p^2]*min[1,3*sqrt(.75*p)]
где
BW — максимальный TCP throughout, достижимый отдельным
TCP-потоком
MSS — размер сегмента TCP, используемый соединением
RTT — время кругового обхода TCP-соединения от конца до конца
RTO — тайм-аут пакета (основанный на RTT)
p — доля потерь пакетов на пути
(то есть .01 при 1% потерь пакетов)
Следует отметить, что скорость линий связи, составляющих путь в Интернете,
явно не фигурирует в этой формуле. Попытка передавать быстрее самой
медленной линии на пути вызывает рост очереди у передатчика, обслуживающего
узкое место. Это увеличивает RTT, что, в свою очередь, уменьшает
достижимую пропускную способность.
В настоящее время это считается наилучшей приближённой формулой для
производительности Reno TCP. Обычно далее эту формулу упрощают, предполагая,
что RTO приблизительно равно 5*RTT.
TCP постоянно совершенствуется. Более простая формула, задающая верхнюю
границу производительности любого алгоритма AIMD, который, вероятно, будет
реализован в TCP в будущем, была выведена Ott и др. [MSMO97].
MSS 1
BW = C --- -------
RTT sqrt(p)
где C равно 0.93.
8.5.2. Допущения
Обе формулы предполагают, что окно приёма TCP не ограничивает
производительность соединения. Поскольку окно приёма полностью определяется
конечными узлами, мы предполагаем, что узлы будут максимизировать
объявляемое окно приёма для максимизации производительности своей сети.
Обе эти формулы допускают, что BW становится бесконечным, если потерь нет.
Однако путь в Интернете будет отбрасывать пакеты в очередях в узких местах,
если нагрузка слишком высока. Поэтому полностью свободная от потерь сеть
TCP/IP никогда не может существовать (если только сеть не используется
недостаточно).
Используемое RTT является средним арифметическим, включая задержки в
очередях.
Формулы предназначены для одного TCP-соединения. Если путь переносит много
TCP-соединений, каждое из них будет независимо следовать приведённым выше
формулам.
Формулы предполагают длительно работающие TCP-соединения. Для соединений,
которые чрезвычайно коротки (<10 пакетов) и не теряют ни одного пакета,
производительность определяется алгоритмом медленного старта TCP. Для
соединений средней длины, в которых в среднем теряются лишь несколько
сегментов, производительность одного соединения фактически будет немного
лучше, чем заданная приведёнными выше формулами.
Различие между приведёнными выше простой и сложной формулами состоит в том,
что сложная формула учитывает эффекты тайм-аутов повторной передачи TCP.
При очень низких уровнях потерь пакетов (значительно менее 1%) тайм-ауты
вряд ли произойдут, и формулы дают очень похожие результаты. При более
высоких потерях пакетов (1% и выше) сложная формула даёт более точную оценку
производительности (которая всегда будет значительно ниже результата простой
формулы).
Следует отметить, что эти формулы перестают работать по мере приближения p
к 100%.
8.5.3. Анализ влияния канального уровня на производительность TCP
Рассмотрим следующий пример:
Разработчик изобретает новый беспроводной канальный уровень, который в
среднем теряет 1% IP-пакетов. Канальный уровень поддерживает пакеты до
1040 байтов и имеет одностороннюю задержку 20 мс.
Если бы эта линия использовалась на пути в Интернете со временем кругового
обхода более 80 мс, верхняя граница могла бы быть вычислена следующим
образом:
Для MSS используйте 1000 байтов, чтобы исключить 40 байтов минимальных
заголовков IPv4 и TCP.
Для RTT используйте 120 мс (80 мс для части Интернета плюс по 20 мс в
каждом направлении для новой беспроводной линии).
Для p используйте .01. Для C предположите 1.
Простая формула даёт:
BW = (1000 * 8 bits) / (.120 sec * sqrt(.01)) = 666 kbit/sec
Более сложная формула даёт:
BW = 402.9 kbit/sec
Если бы это была беспроводная LAN 2 Мбит/с, разработчики могли бы быть
несколько разочарованы.
Некоторые наблюдения о производительности:
1. Мы предположили, что потери пакетов на канальном уровне
интерпретируются TCP как перегрузка. Это «факт жизни», который
необходимо принять.
2. Все уравнения производительности TCP выражены через потери пакетов,
но многие разработчики подсетей мыслят в терминах коэффициента битовых
ошибок. *Если* битовые ошибки канала независимы, то вероятность
повреждения пакета равна:
p = 1 - ([1 - BER]^[FRAME_SIZE*8])
Здесь предполагается, что FRAME_SIZE выражен в байтах, а "^" обозначает
возведение в степень. Он включает пользовательские данные и все
заголовки (TCP,IP и подсети). (Примечание: этот анализ предполагает, что
подсеть не выполняет ARQ или прозрачную фрагментацию [RFC3366].) Если
неравенство
BER * [FRAME_SIZE*8] << 1
выполняется, вероятность потери пакета p можно аппроксимировать как:
p = BER * [FRAME_SIZE*8]
Эти уравнения можно использовать для применения BER к приведённым выше
уравнениям производительности.
Следует отметить, что FRAME_SIZE может меняться от одного пакета к
следующему. Малые пакеты (такие как TCP acks), как правило, имеют
меньшую вероятность ошибки пакета, чем, например, TCP-пакет, несущий
один MSS (максимальный размер сегмента) пользовательских данных. Можно
ожидать, что поток малых TCP acks будет немного надёжнее потока более
крупных сегментов данных TCP.
Стоит повторить, что приведённый выше анализ предполагает статистическую
независимость битовых ошибок. Поскольку это неверно для многих реальных
линий связи, наше вычисление p фактически является верхней границей, а
не точной вероятностью потери пакета.
Существует много причин, почему битовые ошибки на реальных линиях не
независимы. На многие радиолинии влияют замирания распространения или
помехи, сохраняющиеся в течение многих битовых интервалов. Кроме того,
линии с прямым исправлением ошибок (Forward Error Correction, FEC), как
правило, имеют очень неоднородные распределения битовых ошибок, которые
зависят от типа FEC, но в целом неисправленные ошибки обычно возникают
пачками, даже когда ошибки символов канала независимы. Во всех таких
случаях наше вычисление p по BER может устанавливать лишь верхний предел
для доли потерь пакетов.
Если распределение ошибок при схеме FEC известно, можно было бы
применить тот же тип анализа, что и выше, используя правильную функцию
распределения для BER. Однако в этих случаях с FEC более вероятно, что
для определения фактической доли потерь пакетов потребуются эмпирические
методы.
3. Следует отметить, что размер пакета играет важную роль. Если
характеристики потерь подсети таковы, что большие пакеты имеют ту же
вероятность потери, что и меньшие пакеты, то большие пакеты обеспечат
улучшенную производительность.
4. Мы выбрали конкретное RTT, которое могло бы встретиться на
широкозонном маршруте Интернета в пределах США. Важно признать, что в
Интернете наблюдаются разнообразные значения RTT.
Например, RTT обычно составляет менее 10 мс в среде проводной LAN при
обмене данными с локальным узлом. Международные соединения могут иметь
RTT 200 мс или более. Модемы и другие линии с низкой пропускной
способностью могут добавлять значительную задержку из-за длительного
времени передачи (последовательной передачи) пакетов.
Линии через геостационарные спутники-ретрансляторы имеют односторонние
задержки, обусловленные скоростью света, около 250 мс: минимум 125 мс
задержки распространения до спутника и 125 мс вниз. Ожидается, что RTT
сквозного TCP-соединения, включающего такую линию, будет больше 250 мс.
Очереди на сильно перегруженных линиях могут накапливаться, увеличивая
RTT. Наконец, виртуальные частные сети (VPN) и другие формы шифрования
и туннелирования могут добавлять значительную сквозную задержку к
сетевым соединениям.
9. Соображения качества обслуживания (QoS)
В целом признаётся, что для поддержки мультимедиа реального времени,
телефонии с качеством, сравнимым с качеством телефонной сети, и
других критически важных для производительности приложений необходимы
конкретные гарантии обслуживания. Предоставление таких гарантий
качества обслуживания в Интернете является активной областью
исследований и стандартизации. IETF не пришла к единой модели
обслуживания, набору услуг или единому механизму, который обеспечивал
бы полезные для приложений гарантии и мог масштабироваться до
Интернета. В самом деле, у IETF нет единого определения качества
обслуживания. [RFC2990] отражает текущее понимание проблем,
возникающих при разработке архитектуры QoS для Интернета.
В настоящее время существуют два архитектурных подхода к
предоставлению механизмов поддержки QoS в Интернете.
Интегрированные службы IP (Intserv) [RFC1633] предоставляют
детализированные гарантии обслуживания отдельным потокам. Потоки
идентифицируются спецификацией потока (flowspec), которая создаёт
хранящую состояние связь между отдельными пакетами путём сопоставления
полей в заголовке пакета. Для потока резервируется пропускная
способность, а на маршрутизаторах вдоль пути устанавливаются
соответствующие средства кондиционирования трафика и планирования.
Протокол резервирования (ReSerVation Protocol, RSVP) [RFC2205]
[RFC2210] обычно, но не обязательно, используется для установки
состояния QoS потока. Intserv определяет две службы в дополнение к
службе Default (best effort).
1. Служба с гарантированным обслуживанием (Guaranteed Service, GS)
[RFC2212] предоставляет строгие верхние границы задержки потокам,
соответствующим спецификации трафика (TSpec). Она использует
модель потока жидкости для связи TSpec и зарезервированной
пропускной способности (RSpec) с переменной задержкой.
Несоответствующие пакеты пересылаются по принципу best effort.
2. Служба контролируемой нагрузки (Controlled Load Service, CLS)
[RFC2211] предоставляет потокам, соответствующим TSpec, задержку
и потери пакетов, эквивалентные таковым в ненагруженной сети, но
без строгих границ. Несоответствующие пакеты пересылаются по
принципу best effort.
Intserv требует установки информации о состоянии в каждом участвующем
маршрутизаторе. Гарантии производительности не могут быть
предоставлены, если это состояние отсутствует в каждом маршрутизаторе
вдоль пути. Считается, что это, наряду с обработкой RSVP и
необходимостью учёта на основе использования, создаёт проблемы
масштабируемости, особенно в ядре Интернета [RFC2208].
Дифференцированные службы IP (Diffserv) [RFC2475] предоставляют
«набор инструментов», предлагающий грубозернистое управление
агрегатами потоков. Diffserv сам по себе *не* предоставляет гарантий
QoS, но может использоваться для построения служб с гарантиями QoS в
пределах домена Diffserv. Diffserv пытается решить проблемы
масштабирования, связанные с Intserv, требуя учёта состояния только на
границе домена Diffserv. На границе пакеты классифицируются по
потокам, а потоки подвергаются кондиционированию (маркировке, контролю
или сглаживанию) в соответствии со спецификацией кондиционирования
трафика (TCS). В заголовке каждого пакета устанавливается Diffserv Codepoint
(DSCP), идентифицирующий поведение на каждом переходе (PHB). DSCP
переносится в поле DS, охватывая шесть бит бывшего байта
Type-of-Service (ToS) [RFC791] заголовка IP [RFC2474]. PHB обозначает
поведение пересылки, применяемое к пакету в каждом узле домена
Diffserv. Хотя с каждым PHB связан «рекомендуемый» DSCP, отображения
DSCP в PHB определяются DS-доменом. Фактически с одним и тем же PHB
может быть связано несколько DSCP. В настоящее время Diffserv
определяет три PHB.
1. PHB селектора класса [RFC2474] заменяет поле приоритета IP
бывшего байта ToS. Он предоставляет относительные приоритеты
пересылки.
2. PHB ускоренной пересылки (Expedited Forwarding, EF) [RFC3246]
[RFC3248] гарантирует, что пакеты будут иметь чётко определённую
минимальную скорость отправки, которая, если не превышена,
обеспечивает, что связанные очереди коротки или пусты. EF
предназначен для поддержки служб, предлагающих жёстко ограниченные
потери, задержку и джиттер задержки.
3. Группа PHB гарантированной пересылки (Assured Forwarding, AF)
[RFC2597] предлагает различные уровни гарантии пересылки для
каждого агрегированного потока пакетов. Каждой группе AF
независимо выделяются ресурсы пересылки. Пакеты маркируются одним
из трёх приоритетов отбрасывания; пакеты с наивысшим приоритетом
отбрасывания отбрасываются с меньшей вероятностью, чем пакеты,
маркированные наименьшим приоритетом отбрасывания. DSCP
рекомендуются для четырёх независимых групп AF, хотя DS-домен
может иметь большее или меньшее число групп AF.
Текущая работа в IETF рассматривает способы поддержки Intserv с
помощью Diffserv. Существует мнение (например, выраженное в
[RFC2990]), что такой подход позволит отдельным потокам получать
гарантии обслуживания и масштабироваться до глобального Интернета.
Гарантии QoS, которые может предложить уровень IP, являются
результатом двух факторов:
1. объединения гарантий QoS, предлагаемых подсетями вдоль пути
потока. Это подразумевает, что подсеть может пожелать предложить
уровню IP несколько служб (с различными гарантиями QoS), после
чего он сможет определить, какие потоки используют какую службу
подсети. Иными словами, поведение пересылки в подсети должно быть
«подсказано» поведением пересылки (службой или PHB) на уровне IP;
и
2. работы набора взаимодействующих механизмов, таких как
резервирование пропускной способности и контроль допуска,
управление политиками, классификация трафика, кондиционирование
трафика (маркировка, контроль и/или сглаживание), избирательное
отбрасывание, постановка в очередь и планирование. Обратите
внимание, что поддержка QoS в подсетях может потребовать
аналогичных механизмов, особенно когда эти подсети являются
подсетями общей топологии (например, ATM, frame relay или MPLS)
либо подсетями с разделяемой средой.
Многие проектировщики подсетей сталкиваются с неизбежными компромиссами
между задержкой, пропускной способностью, надёжностью и стоимостью.
Другие подсети имеют параметры, управляющие пропускной способностью,
внутренним состоянием соединений и тому подобным. Поэтому следующие
возможности подсети могут быть желательными, хотя некоторые из них
могут быть тривиальными или несущественными, если подсеть представляет
собой выделенную двухточечную линию.
1. Подсети следует обладать возможностью резервировать пропускную
способность для соединения или потока и соответственно
планировать пакеты.
2. Резервирования пропускной способности следует основывать на
модели корзины с одним или двумя маркерами в зависимости от того,
предназначена ли служба для поддержки трафика с постоянной
скоростью или всплескового трафика.
3. Если соединение или поток в данный момент не использует свою
зарезервированную пропускную способность, неиспользуемую пропускную
способность следует делать доступной другим потокам.
4. Пакеты, превышающие согласованную скорость соединения или потока,
следует пересылать по принципу best effort или отбрасывать в
зависимости от службы, предлагаемой подсетью уровню IP.
5. Если подсеть содержит механизмы контроля ошибок (повторную
передачу и/или FEC), следует обеспечить возможность уровню IP
влиять на присущие компромиссы между неисправленными ошибками,
потерями пакетов и задержкой. Эти возможности на границе служб
подсеть/уровень IP соответствуют выбору большего или меньшего
контроля ошибок и/или выбору конкретных механизмов контроля ошибок
внутри подсети.
6. Уровню подсети следует знать и быть способным сообщать уровню IP,
какую фиксированную задержку и джиттер задержки он предлагает для
потока или соединения. Если используется модель Intserv, компонент
джиттера задержки, возможно, лучше всего выражать в терминах модели
TSpec/RSpec, описанной в [RFC2212].
7. Поддержка селекторов класса Diffserv [RFC2474] предполагает, что
подсеть может рассмотреть механизмы, поддерживающие приоритеты.
10. Справедливость против производительности
Проектировщикам подсетей следует осознавать компромиссы между
справедливостью и эффективностью, присущие многим алгоритмам
планирования передачи. Например, многие локальные сети используют
протоколы конкуренции для разрешения доступа к общему каналу передачи.
Эти протоколы создают накладные расходы. Хотя ограничение объёма
данных, который узел подсети может передать за цикл конкуренции,
помогает обеспечить своевременный доступ к каналу для каждого узла
подсети, оно также увеличивает накладные расходы конкуренции на единицу
переданных данных.
В некоторых сетях мобильной радиосвязи ёмкость ограничена помехами,
которые, в свою очередь, зависят от средней мощности передатчика.
Некоторым приёмникам может требоваться значительно большая мощность
передатчика (создающая больше помех и потребляющая большую ёмкость
канала), чем другим.
В каждом случае разработчик алгоритма планирования должен
сбалансировать конкурирующие цели: предоставить справедливую долю
ёмкости каждому узлу подсети при одновременной максимизации общей
ёмкости сети. Один из подходов к балансированию производительности и
справедливости изложен в [ES00].
11. Характеристики задержки
Отправитель TCP основывает свой тайм-аут повторной передачи (RTO) на
измерениях задержки кругового обхода, испытанной предыдущими пакетами.
Это позволяет TCP автоматически адаптироваться к чрезвычайно широкому
диапазону задержек, встречающихся в Интернете. Рекомендуемые алгоритмы
описаны в [RFC2988]. Оценки таймера повторной передачи TCP можно найти
в [AP99] и [LS00].
Эти алгоритмы моделируют задержку вдоль пути Интернета как нормально
распределённую случайную величину с медленно изменяющимися средним
значением и стандартным отклонением. TCP оценивает эти два параметра,
экспоненциально сглаживая отдельные измерения задержки, и устанавливает
RTO равным оценённой средней задержке плюс некоторое фиксированное
число стандартных отклонений. (Алгоритм фактически использует среднее
отклонение как приближение стандартного отклонения, поскольку его
легче вычислять.)
Цель состоит в вычислении RTO, достаточно малого для обнаружения
потерь пакетов и восстановления после них, при минимизации ненужных
(«ложных») повторных передач, когда пакеты неожиданно задерживаются,
но не теряются. Хотя эти цели противоречат друг другу, алгоритм
работает хорошо, когда дисперсия задержки вдоль пути Интернета низка
либо частота потерь пакетов низка.
Если дисперсия задержки на пути высока, TCP устанавливает RTO, намного
превышающий среднее значение измеренных задержек. Если частота потерь
пакетов низка, большой RTO имеет малое значение, поскольку тайм-ауты
возникают лишь редко. И наоборот, если дисперсия задержки на пути
низка, TCP быстро восстанавливается после потерянных пакетов; снова
алгоритм работает хорошо. Однако, когда и дисперсия задержки, и частота
потерь пакетов высоки, эти алгоритмы работают плохо, особенно когда
средняя задержка также высока.
Поскольку TCP использует возвращающиеся подтверждения как «часы» для
определения времени передачи дополнительных данных, чрезмерно высокие
задержки (даже если дисперсия задержки низка) также влияют на
способность TCP полностью использовать высокоскоростной канал
передачи. Это также замедляет восстановление потерянных пакетов, даже
когда дисперсия задержки мала.
Поэтому проектировщикам подсетей следует минимизировать все три
параметра (задержку, дисперсию задержки и потери пакетов) настолько,
насколько возможно.
Во многих подсетях эти параметры по своей природе конфликтуют. Например,
на канале мобильной радиосвязи проектировщик подсети может использовать
повторную передачу (ARQ) и/или прямую коррекцию ошибок (FEC), чтобы
находить компромисс между задержкой, дисперсией задержки и потерями
пакетов в попытке улучшить производительность TCP. Хотя ARQ увеличивает
дисперсию задержки, FEC этого не делает. Однако FEC (особенно в
сочетании с перемежением) часто увеличивает среднюю задержку, даже на
хороших каналах, где повторные передачи ARQ не нужны и ARQ не увеличил
бы ни задержку, ни дисперсию задержки.
Компромиссы между этими механизмами контроля ошибок и их взаимодействия
с TCP могут быть весьма сложными и являются предметом многочисленных
продолжающихся исследований. Поэтому мы рекомендуем, чтобы
проектировщики подсетей обеспечивали как можно большую гибкость при
реализации этих механизмов и предоставляли доступ к ним, как обсуждалось
выше в разделе о качестве обслуживания.
12. Асимметрия пропускной способности
Некоторые подсети могут предоставлять асимметричную пропускную
способность (либо вызывать у потоков пакетов TCP асимметрию ёмкости),
и набор интернет-протоколов в целом всё равно будет работать хорошо.
Однако существует случай, когда такой сценарий снижает
производительность TCP. Поскольку сегменты данных TCP «тактуются»
возвращающимися подтверждениями, отправители TCP ограничены скоростью,
с которой могут возвращаться ACK [BPK98]. Поэтому, когда отношение
доступной ёмкости пути Интернета, несущего данные, к пропускной
способности обратного пути подтверждений слишком велико, медленное
возвращение ACK непосредственно влияет на производительность. Поскольку
ACK обычно меньше сегментов данных, TCP может переносить некоторую
асимметрию, но, как общее правило, проектировщикам подсетей следует
осознавать, что подсети со значительной асимметрией могут приводить к
снижению производительности, если не предпринимаются вопросы для её
смягчения [RFC3449].
Было выявлено несколько стратегий уменьшения воздействия асимметрии сетевого пути между двумя конечными TCP-узлами, например [RFC3449]. Эти методы пытаются сократить число ACK, передаваемых по обратному пути (каналу с низкой пропускной способностью), за счёт изменений в конечном узле (конечных узлах) и/или изменения пересылки пакетов подсетью. Хотя эти решения могут смягчить проблемы производительности, вызванные асимметричными подсетями, они сопряжены с затратами и могут иметь другие последствия. Более полное обсуждение стратегий и их последствий приведено в [RFC3449].
13. Буферизация, управление потоком и перегрузкой
Многие подсети включают несколько каналов с различными потребностями в передаче трафика и, возможно, различными скоростями передачи. На каждом канале должна быть система очередей, включающая буферизацию, планирование и возможность отбрасывать избыточные пакеты подсети. Эти очереди также могут быть частью схемы управления потоком или управления перегрузкой подсети.
Для целей данного обсуждения мы говорим о пакетах независимо от того, относятся ли они к полному IP-пакету или кадру подсети. В каждой очереди пакет испытывает задержку, зависящую от конкурирующего трафика и дисциплины планирования, и подвергается действию локальной политики отбрасывания.
Некоторые подсети могут иметь механизмы управления потоком или перегрузкой в дополнение к отбрасыванию пакетов. Такие механизмы могут работать с компонентами на уровне подсети, такими как планировщики, формирователи или отбрасыватели, и могут влиять на работу IP-пересылателей на границах подсети. Однако, за исключением Explicit Congestion Notification [RFC3168] (рассматриваемого ниже), у IP нет способа передавать TCP явные сигналы перегрузки или управления потоком.
TCP-трафик, особенно агрегированный TCP-трафик, имеет всплесковый характер. В результате мгновенная глубина очередей может резко изменяться даже в номинально стабильных сетях. Для оптимальной производительности пакеты следует отбрасывать контролируемым образом, а не только тогда, когда буферное пространство недоступно. Какой объём буферного пространства следует предоставлять, всё ещё является предметом дискуссий, но в качестве практического правила каждому узлу следует иметь достаточно буферной памяти, чтобы хранить объём данных, равный одному произведению link_bandwidth*link_delay, для каждого TCP-соединения, совместно использующего канал.
Это часто трудно оценить, поскольку это зависит от параметров, находящихся вне контроля или знания подсети. Узлы Интернета обычно не реализуют политики контроля допуска и не могут ограничивать число TCP-соединений, использующих их. В общем случае разумно ошибаться в пользу слишком большой, а не слишком малой буферизации. Подсетям также может быть полезно включать механизмы, измеряющие задержки распространения, чтобы содействовать расчётам размеров буферов.
В исследовательском сообществе существует приблизительный консенсус в том, что активное управление очередями важно для повышения справедливости, использования канала и пропускной способности [RFC2309]. Хотя существуют вопросы и сомнения относительно эффективности активного управления очередями (например, [MBDL99]), оно широко считается улучшением по сравнению с политиками отбрасывания в конце очереди (tail-drop).
Одной из форм активного управления очередями является алгоритм Random Early Detection (RED) [RED93], семейство связанных алгоритмов. В одной версии RED поддерживается экспоненциально взвешенное скользящее среднее глубины очереди:
Когда эта средняя глубина очереди находится между максимальным порогом max_th и минимальным порогом min_th, вероятность отбрасывания пакетов пропорциональна величине, на которую средняя глубина очереди превышает min_th.
Когда эта средняя глубина очереди равна max_th, вероятность отбрасывания равна настраиваемому параметру max_p.
Когда эта средняя глубина очереди больше max_th, пакеты всегда отбрасываются.
В литературе представлены многочисленные варианты RED, а также другие алгоритмы активного управления очередями, которые заявляют различные преимущества перед RED [GM02].
При использовании алгоритма активного управления очередями отброшенные пакеты становятся сигналом обратной связи, побуждающим TCP в конечных узлах к более подходящему поведению при перегрузке. Рандомизация отбрасывания имеет тенденцию нарушать наблюдаемую склонность TCP-окон, принадлежащих различным TCP-соединениям, синхронизироваться вследствие коррелированных отбрасываний; кроме того, она обеспечивает некоторую степень справедливости для тех соединений, которые правильно реализуют предотвращение перегрузки TCP. Ещё одно важное свойство алгоритмов активного управления очередями состоит в том, что они пытаются поддерживать небольшую среднюю глубину очередей, одновременно допуская большие кратковременные всплески.
Поскольку TCP не знает и не интересуется тем, происходит ли потеря пакетов вследствие перегрузки на уровне IP или в подсети, подсетям, выполняющим постановку в очередь и отбрасывание, может быть целесообразно рассмотреть реализацию некоторой формы активного управления очередями. Это особенно верно, если большие агрегаты TCP-соединений, вероятно, будут совместно использовать одну и ту же очередь. Однако активное управление очередями может быть менее эффективным в случае множества очередей, обслуживающих меньшие агрегаты TCP-соединений, например в ATM-коммутаторе, реализующем постановку в очередь для каждого VC.
Следует отметить, что производительность алгоритмов активного управления очередями чрезвычайно чувствительна к настройкам конфигурируемых параметров, а также к таким факторам, как RTT [MBB00] [FB00].
Некоторые подсети, в особенности ATM, выполняют сегментацию и повторную сборку на границах подсети. При разработке политик отбрасывания здесь следует проявлять осторожность. Если подсеть отбрасывает фрагмент IP-пакета, то оставшиеся фрагменты становятся непроизводительной нагрузкой на подсеть, которая может заметно ухудшить сквозную производительность [RF95]. Поэтому подсети следует пытаться отбрасывать эти дополнительные фрагменты всякий раз, когда один из них необходимо отбросить. Если IP-пакет уже был частично переслан, когда отбрасывание становится необходимым, то следует также отбросить каждый оставшийся фрагмент, кроме того, который обозначает конец IP-пакета. Для ATM-подсетей это, в частности, означает использование Early Packet Discard и Partial Packet Discard [ATMFTM].
Некоторые подсети включают механизмы управления потоком, которые фактически требуют, чтобы скорость потоков трафика формировалась при входе в подсеть. Одним из примеров такого механизма подсети является категория обслуживания ATM Available Bit
rate (ABR) [ATMFTM]. Такие механизмы управления потоком делают подсеть почти без потерь, перенося перегрузку в IP-маршрутизаторы на границах подсети. В таком случае в этих маршрутизаторах необходимы адекватные буферизация и политики отбрасывания для работы с подсетью, которая представляется имеющей изменяющуюся пропускную способность. Вопрос о наличии пользы от такого рода управления потоком является спорным; существует множество имитационных и аналитических исследований, поддерживающих обе точки зрения. По-видимому, среди проблем, приводящих к столь различным результатам, — чувствительность к параметрам ABR, использование двоичной, а не явной обратной связи о скорости, использование (или неиспользование) постановки в очередь для каждого VC и конкретные алгоритмы ATM-коммутатора, выбранные для исследования. Согласно отдельным свидетельствам, некоторые крупные сети, использовавшие IP поверх ABR для передачи TCP-трафика, заявляли об успехе, но не публиковали результатов.
Другим возможным подходом к управлению потоком в подсети было бы применение семантики TCP Explicit Congestion Notification (ECN) [RFC3168] посредством использования явных индикаторов перегрузки в кадрах подсети. Маршрутизаторы на границах подсети вместо формирования устанавливали бы бит явной перегрузки в тех IP-пакетах, которые получены в кадрах подсети с индикацией ECN. Узлам в подсети необходимо было бы реализовать протокол активного управления очередями, который помечает кадры подсети вместо их отбрасывания.
В настоящее время ECN является предлагаемым стандартом, но ещё не получил широкого развёртывания.
14. Сжатие
Сжатие данных приложений — это функция, которой в подсети обычно можно пренебречь. Конечные точки обычно имеют больше ресурсов CPU и памяти для выполнения алгоритма сжатия и лучше понимают, что именно сжимается. Сквозное сжатие приносит пользу каждому сетевому элементу на пути, тогда как сжатие на уровне подсети по определению приносит пользу только одной подсети.
Данные, передаваемые на уровень подсети, могут уже быть в сжатом формате (например, файл JPEG), сжаты на уровне приложения (например, необязательное сжатие "gzip", "compress" и "deflate" в HTTP/1.1 [RFC2616]) или сжаты на уровне IP (IP Payload Compression Protocol [RFC3173] поддерживает DEFLATE [RFC2394] и LZS [RFC2395]). Сжатие на границах подсети не приносит пользы ни в одном из этих случаев.
Подсеть также может обрабатывать данные, зашифрованные приложением (OpenPGP [RFC2440] или S/MIME [RFC2633]), непосредственно над TCP (SSL, TLS [RFC2246]) или непосредственно над IP (IPsec ESP [RFC2406]).
Шифры генерируют битовые потоки с высокой энтропией, лишённые каких-либо шаблонов, которые мог бы использовать алгоритм сжатия.
Однако многие данные всё ещё передаются по Интернету несжатыми, поэтому сжатие в подсети может быть полезно. Любой алгоритм сжатия в подсети не должен расширять несжимаемые данные, например данные, уже сжатые или зашифрованные.
Мы настоятельно рекомендуем, чтобы подсети, работающие на низкой скорости или с малыми MTU, сжимали заголовки IP и транспортного уровня (TCP и UDP), используя несколько схем сжатия заголовков, разработанных в IETF [RFC3150]. Несжатый 40-байтовый заголовок TCP/IP передаётся примерно за 33 миллисекунды при 9600 бит/с. Сжатие заголовков TCP/IP "VJ" [RFC1144] сжимает большинство заголовков до 3–5 байтов, сокращая время передачи до нескольких миллисекунд на коммутируемых модемных линиях. Это особенно полезно для малых чувствительных к задержке пакетов в интерактивных сеансах.
Аналогично схемы сжатия RTP, такие как CRTP [RFC2508] и ROHC [RFC3095], сжимают большинство заголовков IP/UDP/RTP до 1–4 байтов. Получаемая экономия особенно значительна, когда аудиопакеты поддерживаются малыми, чтобы минимизировать задержку накопления и пересылки.
Разработчикам следует учитывать влияние частоты ошибок подсети на производительность сжатия заголовков. TCP обычно восстанавливается после потерянных пакетов, повторно передавая только те пакеты, которые были действительно потеряны; пакеты, корректно прибывающие после потери пакета, сохраняются в очереди переупорядочивания и не нуждаются в повторной передаче. Однако при сжатии заголовков VJ TCP/IP [RFC1144] получатель не может явно уведомить отправителя о повреждении данных и последующей потере синхронизации между компрессором и декомпрессором. Вместо этого он полагается на повторную передачу TCP для повторной синхронизации декомпрессора. После потери пакета декомпрессор должен отбрасывать каждый последующий пакет, даже если подсеть не допускает дальнейших ошибок, пока отправляющий TCP не выполнит повторную передачу для повторной синхронизации декомпрессора. Этот эффект может существенно усилить влияние потерь пакетов в подсети, если окно отправляющего TCP велико, как это часто бывает на пути с большим произведением bandwidth*delay [LRKOJ99].
Альтернативные схемы сжатия заголовков, такие как описанные в [RFC2507], включают явный запрос повторной передачи несжатого пакета, позволяющий повторно синхронизировать декомпрессор, не ожидая повторной передачи TCP. Однако эти схемы ещё не получили широкого применения.
Обе схемы сжатия заголовков TCP не сжимают широко используемые параметры TCP, такие как выборочные подтверждения (SACK). Обе не сжимают TCP-трафик, использующий явное уведомление о перегрузке
(ECN). В рабочей группе IETF ROHC ведётся работа по устранению этих недостатков в схеме сжатия заголовков ROHC для TCP [RFC3095] [RFC3096].
Частота ошибок подсети также важна для сжатия заголовков RTP. CRTP использует дельта-кодирование, поэтому потеря пакета на канале вызывает неопределённость относительно последующих пакетов, которые часто необходимо отбрасывать, пока декомпрессор не уведомит компрессор, а компрессор не передаст информацию для повторной синхронизации. Обычно это занимает немного больше времени, чем время двустороннего прохождения по сквозному пути. Для каналов, сочетающих значительные частоты ошибок с задержками, требующими одновременного нахождения в передаче нескольких пакетов, это приводит к значительному распространению ошибок, то есть к последующим потерям, вызванным первоначальной потерей.
Для каналов одновременно с высокой задержкой (несколько пакетов типичного RTP-потока находятся в передаче) и подверженных ошибкам RTP ROHC предоставляет более устойчивый способ сжатия заголовков RTP ценой большей сложности компрессора и декомпрессора. Например, в пределах речевого отрезка обычно только продолжительные потери (в зависимости от выбранного режима) 12–64 пакетов вызывают распространение ошибок.
15. Переупорядочивание пакетов
Архитектура Интернета не гарантирует, что пакеты прибудут в том же порядке, в котором они были первоначально переданы; транспортные протоколы, такие как TCP, должны это учитывать.
Однако переупорядочение всё же сопряжено с издержками для TCP в его
нынешнем определении. Поскольку TCP возвращает совокупное подтверждение
(ACK), указывающее последний поступивший сегмент в правильном порядке,
сегменты, поступившие не по порядку, заставляют TCP-приёмник передавать
дублирующее подтверждение. Когда TCP-отправитель замечает три
дублирующих подтверждения, он предполагает, что сегмент был отброшен
сетью, и использует алгоритм быстрой повторной передачи [Jac90] [RFC2581]
для повторной отправки сегмента. Кроме того, окно перегрузки уменьшается
вдвое, что фактически вдвое снижает скорость отправки TCP. Если
подсеть существенно переупорядочивает сегменты так, что создаются три
дублирующих ACK, TCP-отправитель без необходимости уменьшает окно
перегрузки, и производительность ухудшается.
Переупорядочение пакетов часто происходит в частях Интернета, и его,
по-видимому, трудно или невозможно устранить [BPS99]. По этой причине
начались исследования по улучшению поведения TCP при переупорядочении
пакетов [LK00] [BA02].
В [BPS99] приводятся причины, по которым устранение переупорядочения
может быть даже нежелательным. Существуют ситуации, в которых при
разрешении переупорядочения можно уменьшить среднюю задержку пакетов,
повысить эффективность канала и/или улучшить надёжность. Примеры
включают некоторые высокоскоростные коммутаторы внутри магистральной
сети Интернета и параллельные каналы, используемые на многих путях
Интернета для распределения нагрузки и резервирования.
Это предполагает, что разработчикам подсетей следует стараться избегать
переупорядочения пакетов всегда, когда это возможно, но не если это
снижает эффективность, ухудшает надёжность или увеличивает среднюю
задержку пакетов.
Следует отметить, что каждая схема сжатия заголовков, в настоящее время
стандартизированная для Интернета, требует доставки пакетов в правильном
порядке по каналу между компрессором и декомпрессором. PPP часто
используется для переноса сжатых пакетов TCP/IP; поскольку он изначально
был разработан для двухточечных и коммутируемых каналов, предполагается,
что он обеспечивает доставку в правильном порядке. По этой причине
разработчики подсетей, предоставляющие интерфейсы PPP для VPN и других
более сложных подсетей, также должны поддерживать доставку кадров PPP в
правильном порядке.
16. Мобильность
Пользователи Интернета становятся всё более мобильными. Многие узлы
Интернета являются не только портативными компьютерами, но и карманные
органайзеры и мобильные встраиваемые системы также становятся узлами в
Интернете. Эти узлы со временем могут подключаться ко многим различным
точкам доступа в Интернете и ожидают, что это будет в значительной
степени прозрачно для их деятельности. За исключением случаев, когда они
вообще не подключены к Интернету, и различий в производительности, когда
они подключены, они ожидают, что всё будет «просто работать» независимо
от их текущей точки подключения к Интернету или технологии локальной
подсети.
Изменение точки подключения хоста к Интернету включает один или несколько
из следующих шагов.
Во-первых, если использование локальной подсети ограничено, учётные
данные пользователя должны быть проверены и доступ предоставлен.
Существует множество способов сделать это. Тривиальным примером могло бы
быть «интернет-кафе», которое за плату предоставляет физический доступ к
подсети. Подсети могут реализовывать собственные технические средства
контроля доступа; одним из примеров является IEEE 802.11 Wireless
Equivalent Privacy [IEEE80211]. Обычной практикой является соглашение
между операторами сотовой связи и поставщиками интернет-услуг (ISP) об
обслуживании пользователей друг друга; RADIUS [RFC2865] является
стандартным методом обмена информацией об авторизации между ISP.
Во-вторых, хост, возможно, придётся перенастроить с параметрами IP,
подходящими для локальной подсети. Обычно это включает настройку
IP-адреса, маршрутизатора по умолчанию и серверов системы доменных имён
(DNS).
В сетях множественного доступа для этой цели почти повсеместно
используется Dynamic Host Configuration Protocol (DHCP) [RFC2131]. На
каналах PPP эти функции выполняются IP Control Protocol (IPCP) [RFC1332].
В-третьих, трафик, предназначенный мобильному хосту, должен
маршрутизироваться к его текущему местоположению. Эта функция роуминга
является наиболее распространённым значением термина «мобильность в
Интернете».
Мобильность в Интернете может обеспечиваться на любом из нескольких
уровней стека протоколов Интернета, и продолжается обсуждение того, какой
из них является наиболее подходящим и эффективным. Мобильность уже
является свойством некоторых протоколов прикладного уровня; Post Office
Protocol (POP) [RFC1939] и Internet Message Access Protocol (IMAP)
[RFC3501] были созданы специально для обеспечения мобильности при
получении электронной почты.
Мобильность также может обеспечиваться на уровне IP [RFC3344]. Этот
механизм обеспечивает большую прозрачность, а именно IP-адреса, которые
остаются неизменными при перемещении узлов, но ценой потенциально
значительных накладных расходов сети и увеличенной задержки из-за
задействованных неоптимальной маршрутизации сети и туннелирования.
Некоторые подсети могут предоставлять внутреннюю мобильность, прозрачную
для IP, как свойство собственных внутренних механизмов маршрутизации. В
той мере, в какой это упрощает маршрутизацию на уровне IP, уменьшает
потребность в таких механизмах, как Mobile IP, или использует механизмы,
уникальные для подсети, это в целом желательно. Это особенно верно, когда
подсеть охватывает относительно небольшую географическую область, а
пользователи быстро перемещаются между точками подключения внутри этой
области. Примеры схем внутренней мобильности включают коммутацию Ethernet
и внутрисистемную передачу обслуживания в сотовой телефонии.
Однако если подсеть физически велика и подключается к другим частям
Интернета в нескольких географических точках, следует позаботиться об
оптимизации глобальной маршрутизации пакетов между узлами во внешнем
Интернете и узлами в подсети. Обычно это делается с помощью стратегий
маршрутизации «ближайший выход». Поскольку данная подсеть может не знать
фактическое физическое местоположение назначения в другой подсети, она
просто маршрутизирует пакеты, направленные в другую подсеть, к ближайшему
маршрутизатору между этими двумя подсетями. Это предполагает некоторое
знание IP-адресации и маршрутизации внутри подсети. Подсеть может
пожелать использовать маршрутизацию IP внутри себя для глобальной
маршрутизации и ограничить специфичную для подсети маршрутизацию
географически ограниченными областями, где последствия неоптимальной
маршрутизации минимизированы.
17. Маршрутизация
Подсети, соединяющие более двух систем, должны предоставлять собственные
внутренние механизмы пересылки уровня 2, неявно (например, широковещание)
либо явно (например, коммутацией). Поскольку маршрутизация является
основной функцией уровня Интернета, естественно возникает вопрос о
взаимодействии между маршрутизацией на уровне Интернета и маршрутизацией
в подсети, а также о правильном распределении функций между ними.
Подсети уровня 2 могут быть двухточечными, соединяющими две системы, или
многоточечными. Многоточечные подсети могут быть широковещательными
(например, со средой общего доступа либо эмулируемые) или
нешироковещательными. В целом IP рассматривает многоточечные подсети как
широковещательные, при этом Ethernet со средой общего доступа является
каноническим (и историческим) примером, а двухточечные подсети — как
вырожденный случай. Нешироковещательным подсетям могут потребоваться
дополнительные механизмы, например выше IP на уровне маршрутизации
[RFC2328].
IP не осведомлён о топологии уровня подсети. В частности, изменение
конфигурации путей подсети не отслеживается уровнем IP. На IP влияет
только то, может ли он отправлять/принимать пакеты, отправленные удалённо
подключённым системам через интерфейс подсети (то есть достижимость от
одного маршрутизатора до другого). IP далее считает, что подсети в
значительной степени статичны — что как их состав, так и существование
стабильны в масштабах времени маршрутизации (десятки секунд); изменения
этого рассматриваются как повторное предоставление ресурсов, а не как
маршрутизация.
Функциональность маршрутизации в подсети связана с адресацией в этой
подсети. Разрешение адресов на каналах подсети требуется для пересылки
пакетов IP через каналы (например, ARP для IPv4 или ND для IPv6). Прямое
взаимодействие между маршрутизацией подсети и маршрутизацией IP
маловероятно. Если широковещание предоставляется или явно эмулируется,
разрешение адресов может использоваться непосредственно; если оно не
предоставляется, маршрутизация канального уровня может взаимодействовать
с протоколом разрешения, например с Next-Hop Resolution Protocol
[RFC2322], чтобы предоставить возможности разрешения адресов, зависящие
от контекста.
Маршрутизация подсети может либо дополнять, либо конкурировать с
маршрутизацией IP. Она дополняет IP, когда подсеть инкапсулирует свою
внутреннюю маршрутизацию и последствия этой маршрутизации не видны на
уровне IP. Однако если разные пути в подсети имеют характеристики,
влияющие на маршрутизацию IP, это может влиять на сходимость маршрутизации
IP или даже препятствовать ей.
Протоколы маршрутизации обычно считают подсети уровня 2, то есть с
масками подсети и без промежуточных IP-переходов, имеющими единообразные
метрики маршрутизации до всех участников. Маршрутизация может нарушиться,
когда характеристики канала не соответствуют метрике маршрутизации, в
данном случае, например, когда некоторые пары участников имеют разные
характеристики пути. Рассмотрим виртуальную подсеть Ethernet, включающую
как близко расположенные системы (с задержкой менее миллисекунды), так и
удалённые системы (с задержкой в сотни миллисекунд). Представление этой
группы как одной подсети означает, что некоторые протоколы маршрутизации
будут предполагать, что все пары имеют одинаковую задержку и что эта
задержка мала. Поскольку это не так, построенные таблицы маршрутизации
могут быть неоптимальными или даже не сойтись.
Когда подсеть используется для транзита между набором маршрутизаторов,
она обычно предоставляет эквивалент полной сетки двухточечных каналов.
Простота внутренней структуры подсети может использоваться (например,
через NHRP [RFC2332]) для сокращения размера таблиц разрешения адресов,
но обмены маршрутной информацией продолжат отражать полную сетку, которую
они эмулируют. В целом подсети не следует использовать в качестве
транзита между набором маршрутизаторов, если протоколы маршрутизации
нарушились бы при использовании полной сетки эквивалентных двухточечных
каналов.
Некоторые подсети имеют специальные свойства, позволяющие использовать
более эффективные или отзывчивые механизмы маршрутизации, которые нельзя
реализовать в IP из-за необходимости его универсальности. Одним из
примеров является алгоритм самообучающегося моста, широко используемый в
сетях Ethernet. Обучающиеся мосты выполняют пересылку подсети уровня 2,
избегая необходимости динамической маршрутизации на каждом переходе
подсети. Другим примером является механизм «передачи обслуживания» в
сетях сотовой телефонии, в частности схема «мягкой передачи обслуживания»
в IS-95 CDMA.
Следует избегать подсетей, охватывающих большие географические области
или включающих каналы с сильно различающимися возможностями. Маршрутизация
IP обычно считает все многоточечные подсети эквивалентными локальному
каналу со средой общего доступа с единообразными метриками между любой
парой систем и игнорирует внутреннюю топологию подсети. Если подсеть
отклоняется от этого предположения, разработчики подсети обязаны
предоставить компенсирующие механизмы. Невыполнение этого может повлиять
на масштабируемость и сходимость маршрутизации IP, как отмечалось выше.
Разработчику подсети, который решает реализовать внутреннюю маршрутизацию,
следует рассмотреть, оправдан ли специальный алгоритм маршрутизации или
может оказаться достаточным существующий алгоритм или протокол
маршрутизации Интернета. Разработчику следует рассмотреть, принято ли это
решение для уменьшения размера таблицы разрешения адресов (что возможно,
но требует дополнительной поддержки протокола) или предпринимается
попытка уменьшить сложность таблицы маршрутизации. Последнее может быть
лучше достигнуто путём разделения подсети, физически или логически, и
использования протоколов сетевого уровня для поддержки разделения
(например, AS в BGP). Протоколы и алгоритмы маршрутизации
могут быть печально известны своей тонкостью, сложностью и трудностью
правильной реализации. Многих усилий можно избежать, если существующие
протоколы или реализации можно легко повторно использовать.
18. Вопросы безопасности
Безопасность стала высоким приоритетом при проектировании и эксплуатации
Интернета. Интернет огромен, и бесчисленное множество организаций и лиц
владеют и эксплуатируют его различные компоненты. Сформировался консенсус
относительно того, что можно назвать «принципом размещения безопасности»:
механизм безопасности наиболее эффективен, когда он размещён как можно
ближе к защищаемому им активу и находится под непосредственным контролем
владельца этого актива.
Следствием этого принципа является то, что сквозная безопасность
(например, конфиденциальность, аутентификация, целостность и контроль
доступа) не может быть обеспечена механизмами безопасности подсети.
Сквозные механизмы безопасности не только гораздо теснее связаны с
активами конечного пользователя, которые они защищают, но и значительно
более всеобъемлющи. Например, сквозные механизмы безопасности закрывают
пробелы, которые могут возникать при последовательном соединении в иных
отношениях хороших механизмов подсети. Это важное применение сквозного
принципа [SRC81].
Ряд механизмов безопасности, которые могут использоваться между конечными точками, уже развёрнуты в Интернете и применяются всё шире. Наиболее важны Secure Sockets Layer (SSL) [SSL2] [SSL3] и TLS [RFC2246], преимущественно используемые для защиты электронной торговли в Интернете; Pretty Good Privacy (PGP) [RFC1991] и S/MIME [RFCs-2630-2634], преимущественно используемые для защиты и аутентификации электронной почты и распространяемого программного обеспечения; Secure Shell (SSH), используемый для безопасного удалённого доступа и передачи файлов; а также IPsec [RFC2401] — механизм шифрования и аутентификации общего назначения, располагающийся непосредственно над IP и пригодный для использования любым IP-приложением. (IPsec фактически может использоваться либо между конечными точками, либо между шлюзами безопасности, не включающими одну или обе конечные системы.)
Тем не менее механизмы безопасности между конечными точками применяются не настолько широко, как могло бы быть желательно. Однако группа не смогла достичь консенсуса относительно того, следует ли активно поощрять разработчиков подсетей реализовывать механизмы защиты пользовательских данных.
Ясный консенсус рабочей группы заключался в том, что механизмы безопасности подсети, особенно слабые или реализованные неправильно [BGW01], могут фактически быть контрпродуктивными. Аргумент состоит в том, что механизмы безопасности подсети могут создавать у конечных пользователей ложное ощущение безопасности, уменьшать стимул к развёртыванию эффективных механизмов между конечными точками
и поощрять «рискованные» способы использования Интернета, которые не применялись бы, если бы пользователи понимали неотъемлемые ограничения механизмов безопасности подсети.
Другая точка зрения поощряет безопасность подсети, исходя из принципа, что она лучше ситуации по умолчанию, которая слишком часто вообще не предусматривает никакой безопасности. Пользователи особенно уязвимых подсетей (такие как потребители, имеющие домашние беспроводные сети и/или доступ в Интернет через общую среду передачи) часто контролируют не более одной конечной точки — обычно клиента — и потому не могут обеспечить использование механизмов между конечными точками. Однако безопасность подсети может быть полностью достаточной для защиты малоценных активов от наиболее вероятных угроз. В любом случае механизмы подсети не исключают использования механизмов между конечными точками, которые обычно применяются для защиты высокоценных активов. Эта точка зрения признаёт, что многие политики безопасности неявно предполагают, что весь путь между конечными точками состоит из последовательности соединённых звеньев, номинально защищённых физически. То есть эти политики предполагают, что все конечные точки всех звеньев заслуживают доверия и что атакующим трудно получить доступ к физической среде. Для удовлетворения предположений таких политик необходимы явные механизмы для звеньев (особенно звеньев с общей средой передачи), не имеющих физической защиты. Таково, например, обоснование Wired Equivalent Privacy (WEP) в стандарте беспроводных LAN IEEE 802.11 [IEEE80211] и Baseline Privacy Interface в стандартах передачи данных по кабельным телевизионным сетям DOCSIS [DOCSIS1] [DOCSIS2].
Поэтому мы рекомендуем разработчикам подсетей, которые выбирают реализацию механизмов безопасности для защиты пользовательских данных, быть настолько откровенными, насколько возможно, в отношении деталей таких механизмов безопасности и неотъемлемых ограничений даже наиболее защищённых механизмов при их реализации в подсети, а не между конечными точками.
В соответствии с «принципом размещения» существует ясный консенсус относительно другой роли безопасности подсети: защиты самой подсети. Возможные угрозы активам подсети включают хищение услуг и отказ в обслуживании; подсети с общей средой передачи, как правило, особенно уязвимы для таких атак. В некоторых случаях механизмы, защищающие активы подсети, также могут улучшить (но не могут гарантировать) безопасность между конечными точками.
Подсеть может предоставлять одну службу безопасности, которая поможет решить общую проблему Интернета: безопасности подсети следует предоставлять механизм аутентификации источника кадра подсети. Эта функция отсутствует в некоторых современных протоколах, например при использовании ARP [RFC826] для связывания адреса IPv4 с MAC-адресом. IPv6 Neighbor Discovery (ND) [RFC2461] выполняет аналогичную функцию.
У этого механизма разрешения адресов имеются хорошо известные недостатки безопасности [Wilbur89]. Однако включение аутентификации источника кадра подсети позволит обеспечить защищённый адрес подсети.
Другая потенциальная роль безопасности подсети — защита пользователей от анализа трафика, то есть выявления взаимодействующих сторон и определения схем и объёмов их обмена данными, даже когда фактическое содержимое защищено сильными механизмами безопасности между конечными точками. Безопасность нижнего уровня может быть более эффективной против анализа трафика благодаря присущей ей способности агрегировать коммуникации множества сторон, совместно использующих одни и те же физические средства, одновременно скрывая информацию протоколов более высокого уровня, которая указывает конкретные конечные точки, например IP-адреса и номера портов TCP/UDP.
Однако анализ трафика — общеизвестно тонкая и трудная для понимания и отражения угроза, значительно более сложная, чем угрозы конфиденциальности и целостности. Поэтому мы настоятельно призываем к крайней осторожности при проектировании механизмов безопасности подсети, специально предназначенных для противодействия анализу трафика.
Разработчики подсетей должны помнить, что проектирование и реализация средств безопасности трудны [Schneier00]. В [Schneier95] описаны протоколы и алгоритмы, которые считаются хорошо изученными и предположительно надёжными.
Некачественный процесс проектирования, тонкие ошибки проектирования и дефектная реализация могут приводить к вопиющим уязвимостям. В последние годы в ряде стандартов подсетей были выявлены проблемы. Ниже приведены примеры допущенных ошибок:
1. Использование слабых и непроверенных алгоритмов [Crypto9912] [BGW01]. По различным причинам были выбраны алгоритмы с тонкими недостатками, делавшими их уязвимыми к различным атакам.
2. Использование «безопасности через сокрытие» [Schneier00] [Crypto9912]. Одна распространённая ошибка состоит в предположении, что сохранение криптографических алгоритмов в тайне делает их безопаснее. Это интуитивно, но неверно. Полное публичное раскрытие на ранней стадии процесса проектирования привлекает экспертную оценку знающих криптографов. Выявление недостатков в ходе такой оценки намного перевешивает любую воображаемую выгоду от принуждения атакующих к обратной разработке алгоритмов безопасности.
3. Включение лазеек [Schneier00] [Crypto9912]. Лазейки — это недостатки, тайно оставленные в алгоритме, чтобы позволить его взломать. Это может быть сделано для восстановления утраченных ключей или для предоставления скрытого доступа государственным органам. Лазейки могут быть обнаружены и использованы злоумышленниками.
4. Передача паролей или иной идентифицирующей информации открытым текстом. В течение многих лет аналоговые сотовые телефоны можно было клонировать и использовать для хищения услуг. Клонировщики лишь прослушивали протоколы регистрации, в которых всё передавалось открытым текстом.
5. Ключи, общие для всех систем в подсети [BGW01].
6. Неправильное использование надёжного механизма. Например [BGW01], один стандарт подсети включает вектор инициализации, который плохо спроектирован и плохо специфицирован. Решительный атакующий может легко восстановить несколько шифротекстов, зашифрованных одним и тем же ключевым потоком, и выполнить статистические атаки для их расшифровки.
7. Передаваемая открытым текстом идентифицирующая информация, которую можно сопоставить с отдельным идентифицируемым устройством. Это создаёт уязвимость для атак, направленных на это устройство (или его владельца).
8. Невозможность обновлять и отзывать общую секретную информацию.
9. Недостаточная длина ключа.
10. Неспособность противодействовать атакам «человек посередине», например с помощью взаимной аутентификации.
11. Неспособность предоставить форму обнаружения повторной передачи, например для предотвращения принятия получателем пакетов от атакующего, который лишь повторно посылает ранее захваченный сетевой трафик.
12. Неспособность предоставить механизмы целостности при предоставлении схем конфиденциальности [Bel98].
Этот список далеко не исчерпывающий. Проблем проектирования трудно избежать, но экспертная оценка обычно неоценима для их предотвращения.
Кроме того, хорошо спроектированные протоколы безопасности могут быть скомпрометированы дефектами реализации. Примеры таких дефектов включают использование предсказуемых псевдослучайных чисел [RFC1750], уязвимость к атакам переполнения буфера вследствие небезопасного использования некоторых системных вызовов ввода-вывода [WFBA2000] и непреднамеренное раскрытие секретных данных.
19. Участники
Этот документ представляет консенсус членов рабочей группы IETF Performance Implications of Link Characteristics (PILC).
Этот документ не был бы возможен без вклада большого числа людей из рабочей группы Performance Implications of Link Characteristics. В частности, следующие люди внесли значительный вклад в текст, редактирование и рекомендации для этого документа: Mark Allman выполнил окончательное редактирование для завершения этого документа. Carsten Bormann предоставил текст об устойчивом сжатии заголовков. Gorry Fairhurst предоставил текст по вопросам широковещательной и многоадресной передачи, маршрутизации и множество ценных замечаний по всему документу. Aaron Falk предоставил текст о выделении пропускной способности по требованию. Dan Grossman предоставил текст по многим аспектам документа. Reiner Ludwig выполнил тщательную проверку документа и предоставил текст о сравнении повторной передачи TCP и повторной передачи на канальном уровне. Jamshid Mahdavi предоставил текст о расчётах производительности TCP. Saverio Mascolo предоставил отзыв о документе. Gabriel Montenegro предоставил отзыв о документе. Marie-Jose Montpetit предоставила текст о выделении пропускной способности по требованию. Joe Touch предоставил текст о многоадресной передаче, широковещательной передаче и маршрутизации, а Lloyd Wood предоставил множество ценных замечаний к версиям документа.
20. Информативные ссылки
Ссылки вида RFCnnnn являются документами Internet Request for Comments (RFC), доступными в Интернете по адресу www.rfc-editor.org.
[802.1D] Information Technology Telecommunications and
information exchange between systems Local and
metropolitan area networks, Common specifications Media
access control (MAC) bridges, IEEE 802.1D, 1998. ISO
15802-3.
[802.1p] IEEE, 802.1p, Standard for Local and Metropolitan Area
Networks - Supplement to Media Access Control (MAC)
Bridges: Traffic Class Expediting and Multicast.
[AP99] Allman, M. and V. Paxson, On Estimating End-to-End
Network Path Properties, In Proceedings of ACM SIGCOMM
99.
[AR02] Acar, G. and C. Rosenberg, Weighted Fair Bandwidth-on-
Demand (WFBoD) for Geo-Stationary Satellite Networks
with On-Board Processing, Computer Networks, 39(1),
2002.
[ATMFTM] The ATM Forum, "Traffic Management Specification,
Version 4.0", April 1996, document af-tm-0056.000.
http://www.atmforum.com/
[BA02] Blanton, E. and M. Allman, On Making TCP More Robust to
Packet Reordering. ACM Computer Communication Review,
32(1), January 2002.
[Bel98] Bellovin, S., "Cryptography and the Internet", in
Proceedings of CRYPTO '98, August 1998.
http://www.research.att.com/~smb/papers/inet-crypto.pdf
[BGW01] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
Mobile Communications: The Insecurity of 802.11," In
Proceedings of ACM MobiCom, July 2001.
[BPK98] Balakrishnan, H., Padmanabhan, V. and R. Katz. "The
Effects of Asymmetry on TCP Performance." ACM Mobile
Networks and Applications (MONET), 1998.
[BPS99] Bennet,, J.C.R., Partridge, C. and N. Shectman, "Packet
Reordering is Not Pathological Network Behavior",
IEEE/ACM Transactions on Networking, Vol. 7, No. 6,
December 1999.
[CGMP] Farinacci D., Tweedly A. and T. Speakman, "Cisco Group
Management Protocol (CGMP)", 1996/1997.
ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[Crypto9912] Schneier, B., "European Cellular Encryption Algorithms"
Crypto-Gram, December 15, 1999.
http://www.counterpane.com
[DIX82] Digital Equipment Corp, Intel Corp, Xerox Corp,
Ethernet Local Area Network Specification Version 2.0,
November 1982.
[DOCSIS1] Data-Over-Cable Service Interface Specifications, Radio
Frequency Interface Specification 1.0, SP-RFI-I05-
991105, November 1999, Cable Television Laboratories,
Inc.
[DOCSIS2] Data-Over-Cable Service Interface Specifications, Radio
Frequency Interface Specification 1.1, SP-RFIv1.1-I05-
000714, July 2000, Cable Television Laboratories, Inc.
[DOCSIS3] Lai, W.S., "DOCSIS-Based Cable Networks: Impact of
Large Data Packets on Upstream Capacity", 14th ITC
Specialists Seminar on Access Networks and Systems,
Barcelona, Spain, April 25-27, 2001.
[EN301192] ETSI, European Broadcasting Union, Digital Video
Broadcasting (DVB); DVB Specification for Data
Broadcasting, European Standard (Telecommunications
Series) EN 301 192 v1.2.1(1999-06).
[ES00] Eckhardt, D. and P. Steenkiste, "Effort-limited Fair
(ELF) Scheduling for Wireless Networks, Proceedings of
IEEE Infocom 2000.
[FB00] Firoiu V. and M. Borden, "A Study of Active Queue
Management for Congestion Control", должно быть
опубликовано в Infocom 2000.
[GM02] Grieco1, L. and S. Mascolo, "TCP Westwood and Easy RED
to Improve Fairness in High-Speed Networks",
Proceedings of the 7th International Workshop on
Protocols for High-Speed Networks, April 2002.
[IEEE8023] IEEE 802.3 CSMA/CD Access Method.
http://standards.ieee.org/
[IEEE80211] IEEE 802.11 Wireless LAN standard.
http://standards.ieee.org/
[ISO3309] ISO/IEC 3309:1991(E), "Information Technology -
Telecommunications and information exchange between
systems - High-level data link control (HDLC)
procedures - Frame structure", International
Organization For Standardization, Fourth edition 1991-
06-01.
[ISO13818] ISO/IEC, ISO/IEC 13818-1:2000(E) Information
Technology - Generic coding of moving pictures and
associated audio information: Systems, Second edition,
2000-12-01 International Organization for
Standardization and International Electrotechnical
Commission.
[ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification
Type AAL5, International Standards Organisation (ISO),
1996.
[Jac90] Jacobson, V., Modified TCP Congestion Avoidance
Algorithm. Электронное письмо в список рассылки
end2end-interest, апрель 1990.
ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt
[KY02] Khafizov, F. and M. Yavuz, Running TCP Over IS-2000,
Proceedings of IEEE ICC, 2002.
[LK00] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making
TCP Robust Against Spurious Retransmissions", ACM
Computer Communication Review, Vol. 30, No. 1, January
2000.
[LKJK02] Ludwig, R., Konrad, A., Joseph, A. D. and R. H. Katz,
"Optimizing the End-to-End Performance of Reliable
Flows over Wireless Links", Kluwer/ACM Wireless
Networks Journal, Vol. 8, Nos. 2/3, pp. 289-299,
March-May 2002.
[LRKOJ99] Ludwig, R., Rathonyi, B., Konrad, A., Oden, K. and A.
Joseph, Multi-Layer Tracing of TCP over a Reliable
Wireless Link, стр. 144-154, в Proceedings of ACM
SIGMETRICS 99.
[LS00] Ludwig, R. and K. Sklower, The Eifel Retransmission
Timer, ACM Computer Communication Review, Vol. 30, No.
3, July 2000.
[MAGMA-PROXY] Fenner, B., He, H., Haberman, B. and H. Sandick,
"IGMP/MLD-based Multicast Forwarding ("IGMP/MLD
Proxying")", В работе.
[MAGMA-SNOOP] Christensen, M., Kimball, K. and F. Solensky,
"Considerations for IGMP and MLD Snooping Switches",
В работе.
[MBB00] May, M., Bonald, T. and J-C. Bolot, "Analytic
Evaluation of RED Performance", INFOCOM 2000.
[MBDL99] May, M., Bolot, J., Diot, C. and B. Lyles, "Reasons not
to deploy RED", Proc. of 7th. International Workshop on
Quality of Service (IWQoS'99), June 1999.
[MSMO97] Mathis, M., Semke, J., Mahdavi, J. and T. Ott, "The
Macroscopic Behavior of the TCP Congestion Avoidance
Algorithm", Computer Communication Review, Vol. 27,
number 3, July 1997.
[MYR95] Boden, N., Cohen, D., Felderman, R., Kulawik, A.,
Seitz, C., et al. MYRINET: A Gigabit per Second Local
Area Network, IEEE-Micro, Vol. 15, No.1, February 1995,
pp. 29-36.
[PFTK98] Padhye, J., Firoiu, V., Towsley, D. and J. Kurose,
"Modeling TCP Throughput: a Simple Model and its
Empirical Validation", UMASS CMPSCI Tech Report TR98-
008, Feb. 1998.
[RED93] Floyd, S. and V. Jacobson, "Random Early Detection
gateways for Congestion Avoidance", IEEE/ACM
Transactions in Networking, Vol. 1 No. 4, August 1993.
http://www.aciri.org/floyd/papers/red/red.html
[RF95] Romanow, A. and S. Floyd, "Dynamics of TCP Traffic over
ATM Networks". IEEE Journal of Selected Areas in
Communication, Vol.13 No. 4, May 1995, p. 633-641.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC826] Plummer, D.C., "Ethernet Address Resolution Protocol:
Or converting network protocol addresses to 48-bit
Ethernet address for transmission on Ethernet
hardware", STD 37, RFC 826, November 1982.
[RFC1071] Braden, R., Borman, D. and C. Partridge, "Computing the
Internet checksum", RFC 1071, September 1988.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD
5, RFC 1112, August 1989.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC
1191, November 1990.
[RFC1332] McGregor, C., "The PPP Internet Protocol Control
Protocol (IPCP)", RFC 1332, May 1992.
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC1662] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51,
RFC 1662, July 1994.
[RFC1750] Eastlake 3rd, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, October
1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O`Dell,
M., Romanow, A., Weinrib, A. and L. Zhang, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Applicability
Statement Some Guidelines on Deployment", RFC 2208,
September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C. and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L.,
Ramakrishnan, K., Shenker, S., Wroclawski, J. and L.
Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April
1998.
[RFC2322] van den Hout, K., Koopal, A. and R. van Mook,
"Management of IP numbers by peg-dhcp", RFC 2322, 1
April 1998.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N.
Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)",
RFC 2332, April 1998.
[RFC2364] Gross, G., Kaycee, M., Li, A., Malis, A. and J.
Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE",
RFC 2394, December 1998.
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression
Using LZS", RFC 2395, December 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[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] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, February
1999.
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification
to TCP's Fast Recovery Algorithm", RFC 2582, April
1999.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate
Handling", RFC 2632, June 1999.
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol
Encapsulation over ATM Adaptation Layer 5", RFC 2684,
September 1999.
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link
PPP", RFC 2686, September 1999.
[RFC2687] Bormann, C., "PPP in a Real-time Oriented HDLC-like
Framing", RFC 2687, September 1999.
[RFC2689] Bormann, C., "Providing Integrated Services over Low-
bitrate Links", RFC 2689, September 1999.
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC
2784, March 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture",
RFC 2990, November 2000.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S. and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001.
[RFC3095] Bormann, C., Ed., Burmeister, C., Degermark, M.,
Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R.,
Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki,
A., Svanbro, K., Wiebke, T., Yoshimura, T. and H.
Zheng, "RObust Header Compression (ROHC): Framework
and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[RFC3096] Degermark, M., Ed., "Requirements for robust IP/UDP/RTP
header compression", RFC 3096, July 2001.
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret,
"End-to-end Performance Implications of Slow Links",
BCP 48, RFC 3150, July 2001.
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and
N. Vaidya, "End-to-end Performance Implications of
Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3173] Shacham, A., Monsour, B., Pereira, R. and M. Thomas,
"IP Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3248] Armitage, G., Carpenter, B., Casati, A., Crowcroft, J.,
Halpern, J., Kumar, B. and J. Schnizlein, "A Delay
Bound alternative revision of RFC 2598", RFC 3248,
March 2002.
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
3344, August 2002.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
August 2002.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.
Sooriyabandara, "TCP Performance Implications of
Network Path Asymmetry", BCP 69, RFC 3449, December
2002.
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L.,
Handley, M. and J. Crowcroft, "Layered Coding Transport
(LCT) Building Block", RFC 3451, December 2002.
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
Handley, M. and J. Crowcroft, "Forward Error Correction
(FEC) Building Block", RFC 3452, December 2002.
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
Handley, M. and J. Crowcroft, "The Use of Forward Error
Correction (FEC) in Reliable Multicast", RFC 3453,
December 2002.
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group
Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
Ed. and G. Fairhurst, Ed., "The User Datagram Protocol
(UDP)-Lite Protocol", RFC 3828, June 2004.
[Schneier95] Schneier, B., Applied Cryptography: Protocols,
Algorithms and Source Code in C (John Wiley and Sons,
October 1995).
[Schneier00] Schneier, B., Secrets and Lies: Digital Security in a
Networked World (John Wiley and Sons, August 2000).
[SP2000] Stone, J. and C. Partridge, "When the CRC and TCP
Checksum Disagree", ACM SIGCOMM, September 2000.
http://www.acm.org/sigcomm/sigcomm2000/conf/
paper/sigcomm2000-9-1.pdf
[SRC81] Saltzer, J., Reed D. and D. Clark, "End-to-End
Arguments in System Design". Second International
Conference on Distributed Computing Systems (April,
1981) pages 509-512. Published with minor changes in
ACM Transactions in Computer Systems 2, 4, November,
1984, pages 277-288. Reprinted in Craig Partridge,
editor Innovations in internetworking. Artech House,
Norwood, MA, 1988, pages 195-206. ISBN 0-89006-337-0.
[SSL2] Hickman, K., "The SSL Protocol", Netscape
Communications Corp., Feb 9, 1995.
[SSL3] Frier, A., Karlton, P. and P. Kocher, "The SSL 3.0
Protocol", Netscape Communications Corp., Nov 18, 1996.
[TCPF98] Lin, D. and H.T. Kung, "TCP Fast Recovery Strategies:
Analysis and Improvements", IEEE Infocom, March 1998.
http://www.eecs.harvard.edu/networking/papers/infocom-
tcp-final-198.pdf
[WFBA2000] Wagner, D., Foster, J., Brewer, E. and A. Aiken, "A
First Step Toward Automated Detection of Buffer Overrun
Vulnerabilities", Proceedings of NDSS2000.
http://www.isoc.org/isoc/conferences/ndss/
2000/proceedings/039.pdf
[Wilbur89] Wilbur, Steve R., Jon Crowcroft, and Yuko Murayama.
"MAC layer Security Measures in Local Area Networks",
Local Area Network Security, Workshop LANSEC '89
Proceedings, Springer-Verlag, April 1989, pp. 53-64.
21. Адреса участников
Aaron Falk
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, CA 90292
Телефон: 310-448-9327
Электронная почта: falk@isi.edu
Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica,
Politecnico di Bari Via Orabona 4, 70125 Bari, Italy
Телефон: +39 080 596 3621
Электронная почта: mascolo@poliba.it
URL: http://www-dee.poliba.it/dee-web/Personale/mascolo.html
Marie-Jose Montpetit
MJMontpetit.com
Электронная почта: marie@mjmontpetit.com
22. Адреса авторов
Phil Karn, редактор
Qualcomm 5775 Morehouse Drive
San Diego CA 92121
Телефон: 858 587 1121
Электронная почта: karn@qualcomm.com
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
D-28334 Bremen, Germany
Телефон: +49 421 218 7024
Факс: +49 421 218 7000
Электронная почта: cabo@tzi.org
Godred (Gorry) Fairhurst
Department of Engineering, University of Aberdeen,
Aberdeen, AB24 3UE, United Kingdom
Электронная почта: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry
Dan Grossman
Motorola, Inc.
111 Locke Drive
Marlboro, MA 01752
Электронная почта: Dan.Grossman@motorola.com
Reiner Ludwig
Ericsson Research
Ericsson Allee
1 52134 Herzogenrath, Germany
Телефон: +49 2407 575 719
Электронная почта: Reiner.Ludwig@ericsson.com
Jamshid Mahdavi
Novell, Inc.
Электронная почта: jmahdavi@earthlink.net
Gabriel Montenegro
Sun Microsystems Laboratories, Europe
180, Avenue de l'Europe
38334 Saint Ismier CEDEX
France
Электронная почта: gab@sun.com
Joe Touch
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey CA 90292
Телефон: 310 448 9151
Электронная почта: touch@isi.edu
URL: http://www.isi.edu/touch
Lloyd Wood
Cisco Systems
9 New Square Park, Bedfont Lakes
Feltham TW14 8HA
United Kingdom
Телефон: +44 (0)20 8824 4236
Электронная почта: lwood@cisco.com
URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/
23. Полное заявление об авторских правах
Авторское право (C) The Internet Society (2004). Этот документ
регулируется правами, лицензиями и ограничениями, содержащимися в BCP 78,
и, за исключением предусмотренного в нём, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются на условиях
"КАК ЕСТЬ", И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ ИЛИ
КОТОРОЙ СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), THE INTERNET SOCIETY И THE
INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ
ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО,
ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО
ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ
ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.