1. Групповая маршрутизация с общим деревом

Единое общее дерево

Дерево наименьшей стоимости для группы

Формирование дерева с центральным узлом

Условные обозначения:

Путь и порядок, в котором генерируются сообщения

2. Групповая маршрутизация с деревом у каждого отправителя

Алгоритм продвижения данных по обратным маршрутам(RPF - Reverse Path Forwarding)

Условные обозначения:

	Пакет пересылается дальше
	Пакет дальше не пересылается

Для отправителя S строится дерево для каждого из представителей этой группы Отправляется групповая дейтаграмма, каждый маршрутизатор, получивший это сообщение отправит его своим соседям. Маршрутизатор либо отправляет дальше, либо - нет (отправляет дальше в том случае, если информация поступила по кратчайшему пути.) 39.Групповая рассылка пакетов в сети Интернет. Протокол групповой маршрутизации IGMPv2. Формат IGMP-сообщений. Механизм переноса IGMP-сообщений.

Межсетевой протокол управления группами IGMP (Internet Group Management Protocol)RFC 2236, версия 2

Две составляющие групповой рассылки сетевого уровня: протокол IGMP и протоколы групповой маршрутизации

Формат IGMP-сообщения:

Типы сообщений протокола IGMP

Тип	Адрес группы	Описание
0x11	Отсутствует (ноль)	Запрос о членах всех групп
0x11	Используется	Запрос о членах определенной группы
0x16	Используется	Отчет о членах группы
0x17	Используется	Отключение от группы

Протоколы групповой рассылки:

• дистанционно-векторный протокол многоадресатной маршрутизации DVMRP;

• многоадресатное расширение протоколаOSPF (MOSPF);

Туннели для групповой рассылки Физическая топология

A, B, C - поддерживают групповую топологию. Остальные работают в режиме транзита (туннель)

Логическая топология

Итак, протокол IGMP отвечает за организацию механизма доставки пакетов с групповым адресом от группового маршрутизатора всем членам группы в подключенной к нему подсети, но не решает задачу доставки таких пакетов между соседними маршрутизаторами и через распределенную сеть. Пакеты эти формируются с помощью приложений верхнего уровня и используют для доставки транспортный протокол UDP. Реализовать же механизм доставки позволяют протоколы многоадресной маршрутизации, отвечающие за построение деревьев доставки и маршрутизацию пакетов. Дерево доставки - это по сути некоторое количество путей, выбираемых таким образом, чтобы пакеты с групповыми адресами доставлялись только тем хостам, которые хотят их получать. Алгоритмов формирования деревьев доставки существует достаточно много. Среди них можно отметить Flooding, Spanning Tree, Reverse Path Broadcasting, Truncated Reverse Path Broadcasting, Reverse Path Multicasting, Core-Based Tree. Некоторые из этих алгоритмов реализованы в наиболее распространенных протоколах многоадресной маршрутизации, таких как DVMRP, MOSPF, PIM[5]. Особенностью маршрутизаторов групповой передачи является то, что они при получении пакета создают его копию и отправляют ее всем членам группы в своей подсети. 40.Обеспечение качества обслуживания в IP-сетях. Критерии качества. В рамках работ МСЭ по стандартизации качества обслуживания в сетях IP предполагаются следующие этапы решения задачи обеспечения QoS для сетей, построенных на базе IP-ориентированных протоколов: • создание согласованного общего набора рабочих характеристик сетей IP и норм для него; • внедрение сетевых механизмов, которые будут обеспечивать заданные показатели качества обслуживания в конфигурации "терминал-терминал"; • вложение нормированных значений показателей качества обслуживания в протоколы сигнализации; • разработка архитектуры сетевых механизмов поддержки. В 2002 г. ИК 13 МСЭ-Т опубликовала два международных стандарта, которые отвечают первому из перечисленных этапов. Рекомендация МСЭ Y.1540 описывает стандартные сетевые характеристики для передачи пакетов в сетях IP. Рекомендация МСЭ Y.1541 [5] определяет нормы для параметров, определенных в Y.1540, между двумя граничными сетевыми интерфейсам – точками подключения оконечных терминальных устройств. Кроме того, в этой рекомендации специфицированы шесть классов качества обслуживания в зависимости от приложений. В Рекомендации Y.1540 рассматриваются следующие сетевые характеристики, как наиболее важные по степени их влияния на сквозное качество обслуживания (от источника до получателя), оцениваемое пользователем: • производительность сети; • надежность сети/сетевых элементов; • задержка; • вариация задержки (джиттер); • потери пакетов.

М еханизмы QoS в плоскости контроля

Управление допуском (Call Admission Control). Этот механизм контролирует новые заявки на пропуск трафика через сеть, определяя, может ли вновь поступающий трафик привести к перегрузке сети или к ухудшению уровня качества обслуживания для уже имеющегося в сети трафика. Обычно управление допуском построено на определенном наборе правил администрирования, контроля и управления сетевыми ресурсами.Эти правила могут быть специфицированы в соответствии с потребностями сетевого провайдера или базироваться на соглашении между провайдером и пользователем и включать в свой состав различные параметры QoS. Для удовлетворения требований определенных служб (например, при чрезвычайных обстоятельствах), соответствующему трафику может быть присвоен высший приоритет при доступе в сеть. Маршрутизация QoS (QoS routing) обеспечивает выбор пути, который удовлетворяет требованиям к качеству обслуживания для конкретного потока данных. Выбираемый путь может отличаться от кратчайшего пути. Процесс определения пути предполагает знание требований к качеству обслуживания со стороны потока данных и наличие информации о доступных сетевых ресурсах. В настоящее время предложено большое число возможных методов определения наилучшего пути по критерию QoS. Как правило, в вычислениях наилучшего пути в маршрутизации QoS учитывается либо одна сетевая характеристика, либо две (производительность и задержка, стоимость и производительность, стоимость и задержка и т. д.), с тем, чтобы сделать процесс вычислений приемлемым для инженерных расчетов.Резервирование ресурсов (Resource reservation). В целом, необходимым условием для обеспечения резервирования ресурсов является наличие ресурсов в сети. Резервирование ресурсов широко использовалось в сетях ATM при формировании постоянных виртуальных соединений. В IP-ориентированных сетях наиболее типичным механизмом резервирования является механизм, базирующийся на протоколе RSVP.Механизмы QoS в плоскости данных Управление буферами (Buffer management). Управление буферами (или очередями) состоит в управлении пакетами, стоящими в узлах в очереди на передачу. Основные задачи управления очередями – минимизация средней длины очереди при одновременном обеспечении высокого использования канала, а также справедливое распределение буферного пространства между различными потоками данных. Схемы управления очередями различаются, в основном, критерием, по которому отбрасываются пакеты, и местом в очереди, откуда производится сброс пакетов (начало или конец очереди). Наиболее простым критерием для сброса пакетов является достижение очередью определенного порога, называемого максимальной длиной очереди. Более распространены сегодня так называемые механизмы активного управления очередями. Типичным примером является алгоритм RED (Random Early Detection – раннее случайное обнаружение перегрузки). При использовании алгоритма RED поступающие в буфер пакеты сбрасываются на основании оценки средней длины очереди. Вероятность сброса пакетов растет с ростом средней длины очереди. Предотвращение перегрузок (Congestion avoidance). Механизмы предотвращения перегрузок поддерживают уровень нагрузки в сети ниже ее пропускной способности. Обычный способ предотвращения перегрузок состоит в уменьшении трафика, поступающего в сеть. Как правило, команда уменьшить трафик влияет, в первую очередь, на низкоприоритетные источники. Одним из примеров механизмов предотвращения перегрузок является механизм окна в протоколе TCP. Маркировка пакетов (Packet marking). Пакеты могут быть промаркированы в соответствии с определенным классом обслуживания. Маркировка обычно производится во входном пограничном узле, где в специальное поле заголовка (Type of Service в заголовке IP или DS-байт в заголовке DiffServ, см. ниже) вводится определенное значение. Кроме того, маркировка применяется для тех пакетов, которые могут быть удалены в случае перегрузки сети. Организация и планирование очередей (Queuing and scheduling). Цель механизмов этой группы – выбор пакетов для передачи из буфера в канал. Большинство дисциплин обслуживания (или планировщиков) основаны на схеме "первый пришел – первый обслуживается". Для обеспечения более гибких процедур вывода пакетов из очереди был предложен ряд схем, основанных на формировании нескольких очередей. Среди них, в первую очередь, необходимо назвать схемы приоритетного обслуживания. Другой пример гибкой организации очереди – механизм взвешенной справедливой буферизации (Weighted Fair Queuing, WFQ), когда ограниченная пропускная способность на выходе узла распределяется между несколькими потоками (очередями) в зависимости от требований к пропускной способности со стороны каждого потока. Еще одна схема организации очереди основана на классификации потоков по классу обслуживания (Class-Based Queuing, CBQ). Потоки классифицируются в соответствии с классами обслуживания и затем размещаются в буфере в различных очередях. Каждой очереди выделяется определенный процент выходной пропускной способности в зависимости от класса, и очереди обслуживаются по циклической схеме. Формирование трафика (Traffic shaping). Формирование или управление характеристиками трафика предполагает контроль скорости передачи пакетов и объема потоков, поступающих на вход сети. В результате прохождения через специальные формирующие буферы уменьшается пачечность исходного трафика, и его характеристики становятся более предсказуемыми. Известны два механизма обработки трафика – Leaky Bucket ("дырявое ведро") и Token Bucket ("ведро с жетонами"). Алгоритм Leaky Bucket регулирует скорость пакетов, покидающих узел. Независимо от скорости входного потока, скорость на выходе узла является величиной постоянной. Когда ведро переполняется, лишние пакеты сбрасываются. В противоположность этому, алгоритм Token Bucket не регулирует скорость на выходе узла и не сбрасывает пакеты. Скорость пакетов на выходе узла может быть такой же, как и на входе, если только в соответствующем накопителе ("ведре") есть жетоны. Жетоны генерируются с определенной скоростью и накапливаются в ведре. Алгоритм характеризуется двумя параметрами – скоростью генерации жетонов и размером памяти (размером "ведра") для них. Пакеты не могут покинуть узел, если в ведре нет жетонов. И наоборот, сразу пачка пакетов может покинуть узел, израсходовав соответствующее число жетонов. Правила обработки трафика (Traffic policing). Этот блок принимает решение о том, соответствует ли поступающий от транзитного узла к транзитному узлу трафик заранее согласованным правилам обработки или контрактам. Обычно несоответствующие пакеты отбрасываются. Отправители могут быть уведомлены об отброшенных пакетах и обнаруженных причинах, а также о соблюдении соответствия в будущем, обусловленного соглашениями SLA. Классификация трафика (Traffic classification). Классификация трафика может быть проведена на потоковом или пакетном уровне. На входе в сеть в узле доступа (пограничном маршрутизаторе) пакеты классифицируются для того, чтобы выделить пакеты одного потока, характеризуемого общими требованиями к качеству обслуживания. Затем трафик подвергается процедуре нормирования (механизм Traffic Conditioning). Нормирование трафика предполагает измерение его параметров и сравнение результатов с параметрами, оговоренным в контракте по трафику, известному как соглашение об уровне обслуживания (Service Level Agreement, SLA, см. ниже). Если условия SLA нарушаются, то часть пакетов может быть отброшена. Магистральные маршрутизаторы, составляющие ядро сети, обеспечивают пересылку пакетов в соответствии с требуемым уровнем QoS. Механизмы QoS в плоскости административного управления Измерения (Metering). Измерения обеспечивают контроль параметров трафика – например, скорость потока данных в сравнении с согласованной в SLA скоростью. По результатам измерений могут быть реализованы определенные процедуры – такие, как сброс пакетов и применение механизмов Leaky Bucket и Token Bucket. Заданные правила доставки (Policy). Под правилами доставки здесь понимается набор правил, используемых для контроля и административного управления доступом к сетевым ресурсам. На основе таких правил поставщики услуг могут осуществлять реализацию механизмов в плоскости управления и плоскости данных. Возможными применениями правил доставки являются маршрутизация по заданным правилам, фильтрация пакетов на основе заданных правил (маркировка или отбрасывание пакетов), регистрация заданных потоков, правила обработки, связанные с безопасностью. Восстановление трафика (Traffic restoration). Под восстановлением трафика в данной рекомендации понимается реакция сети, смягчающая последствия в условиях отказа. Восстановление трафика рассматривается на различных уровнях эталонной модели процессов. На физическом уровне при использовании SDH надежность обеспечивается автоматической защитной коммутацией. На канальном уровне транспортных сетей восстановление трафика обеспечивается специальными механизмами, развитыми для кольцевых и ячеистых структур. Соответствующие процедуры предусмотрены в технологии ATM. Восстановление на сетевом уровне (протокол IP) осуществляется с помощью технологии MPLS. Соглашение об уровне обслуживания (Service Level Agreement). Одним из основных понятий в концепции обеспечения требуемого уровня качества обслуживания в современных сетях является соглашение об уровне обслуживания. Первые SLA-контракты были разработаны в середине 90-х годов при предоставлении услуг передачи данных с использованием технологий Frame Relay, ATM и IP. Необходимость подобных контрактов была вызвана возрастающими требованиями к операторам со стороны клиентов, чей бизнес все больше зависел от надежной и своевременной передачи информации. Контракт SLA предполагает повышенную ответственность поставщика услуг, дисциплинирует его. В какой-то степени это дисциплинирует и заказчика, поскольку заключению соглашения предшествует этап анализа требований к уровню сервиса. 41.Методы борьбы с перегрузками на уровне TCP. Стратегия медленного старта.Плюсы и минусы этой стратегии. Существуют два параметра, используемые в алгоритмах управления перегрузками в TCP/IP, реализованных в протоколе TCP [3]: – rwnd (receiver window) – окно приемника – количество данных, которое приемник может принять подряд; – cwnd (congestion window) – окно перегрузки – ограничивает количество данных, которое источник может послать приемнику без подтверждения доставки. Параметр rwnd находится в поле заголовка сегмента TCP и сигнализирует о том, сколько места свободно в приемном буфере приемника. С его помощью приемник может управлять скоростью передачи данных источником. На базе этого параметра в TCP реализована функция управления потоком. Посредством изменения окна перегрузки количество переданных данных источником может варьироваться. Именно параметр cwnd реализует функцию управления перегрузкой в протоколе TCP. Среднюю пропускную способность соединения TCP можно приблизительно оценить по формуле: BW = cwnd * MSS / RTT, где BW – пропускная способность канала связи, MSS – максимальный размер сегмента, RTT – время возврата сегмента. Таким образом, с помощью управления окном перегрузки можно влиять на пропускную способность соединения. С помощью cwnd приемник также может управлять скоростью передачи источником, например, отбросив один из принятых сегментов TCP. Это вызовет уменьшение окна перегрузки, и источник будет посылать меньше данных без подтверждения. Так поступают некоторые алгоритмы управления трафиком. Медленный старт — часть стратегии управления перегрузкой сети, в TCP, протоколе передачи данных, используемого во многих интернет-приложениях. Медленный старт используется совместно с другими алгоритмами для того чтобы избежать отправки больше данных, чем сеть способна передать. Алгоритм определяется RFC 5681. Медленный старт — один из алгоритмов, который TCP использует для контроля над нагрузкой сети. Иногда его еще называют фазой экспоненциального роста.Во время фазы экспоненциального роста, алгоритм медленного старта работает за счет увеличения окна TCP каждый раз когда получено подтверждение, то есть увеличивает размер окна в зависимости от количества подтвержденных сегментов. Это происходит до тех пор, пока для какого-то сегмента не будет получено подтверждение или будет достигнуто какое-то заданное пороговое значение. Если происходит потеря, TCP предполагает что это связано с перегрузкой сети и принимает меры по сокращению нагрузки на сеть. Как только порог достигнут, TCP входит в фазу линейного роста (предотвращения перегрузки). В эту фазу окно увеличивается на один сегмент для каждого RTT (время распространения пакета туда и обратно). Это происходит до тех пор, пока случаются потери.Алгоритм медленного старта предполагает, что отсутствие подтверждения происходит вследствие перегрузки сети. Хотя это предположение приемлемо для многих сетей, сегменты могут быть потеряны и по другим причинам, например, плохое качество канала передачи данных на канальном уровне. Таким образом, алгоритм медленного старта может плохо работать в ситуациях со слабым приемом - таких, как беспроводные сети.Протокол медленного старта плохо подходит для короткоживущих соединений. Старые браузеры могут создавать много последовательных коротко живущих соединений с веб-сервером, и будет открывать и закрывать соединение для каждого запрашиваемого файла. Все это держало большинство подключений в режиме медленного старта, в результате которых было большое время отклика. Чтобы избежать этой проблемы, современные браузеры либо открывают несколько соединений одновременно или повторно используют одно соединение для всех файлов, запрошенных с конкретного веб-сервера. Тем не менее, соединения не могут быть повторно использованы для множества сторонних серверов, используемых веб-сайтами для реализации веб-рекламы, общих функций социальных сетей,[3] сценариев веб-аналитики. 42.Механизмы, обеспечивающие надежную доставку TCP-сегментов в сети Интернет. Т.к. сегменты могут быть потеряны в резуль- тате ошибок (например, ошибки в контрольной сумме) или перегрузки сети, то программа протокола TCP использует механизм повторной посыл- ки (по истечении определенного времени) с тем, чтобы убедиться в по- лучении каждого сегмента. В главе, посвященной номерам очередей, об- суждалось, как программа TCP в сегментах осуществляет проверку номе- ров очередей и номеров подтверждения на предмет их корректности.   Отправитель данных с помощью значения переменной SND.NXT отслежи- вает следующий номер в очереди, подлежащий отправке. Получатель дан- ных с помощью переменной RCV.NXT отслеживает следующий номер, прибы- тие которого он ожидает. В переменную SND.UNA отправитель данных по- мещает значение самого старого номера, который был отправлен, но еще не получил подтверждения. Если бы поток данных моментально иссяк, а все отправленные данные получили подтверждение, то тогда бы все эти при переменные содержали одинаковое значение.   Когда отправитель информации создает и посылает некий сегмент, он увеличивает значение переменной SND.NXT. Адресат по получении сегмен- та увеличивает значение переменной RCV.NXT и отправляет подтвержде- ние. Когда программа TCP, пославшая данные, получает подтверждение, она увеличивает значение SND.UNA. Разность в значениях этих перемен- ных является мерой, характеризующей задержку сегментов в сети. Вели- чина, на которую надо всякий раз осуществлять приращение значения этих переменных, является длиной поля данных в сегменте. Заметим, что поскольку соеднения находятся в состоянии ESTABLISHED, все сегменты, в дополнение к собственно данным, должны нести некую информацию о подтверждении ранее отправленных сегментов.   Запрос пользователя о закрытии соединения (CLOSE) подразумевает использование функции проталкивания, что осуществляется с помощью контрольного флага FIN приходящем сегменте                 Контрольное время повторной посылки                   Вследствие непостоянства сетей, составляющих единую объединенную систему, и большого числа клиентов, пользующихся услугами TCP соеди- нений, существует необходимость в динамическом определении контроль- ного времени повторной посылки. В качестве иллюстрации здесь приво- дится одна из процедур определения этого времени.      Пример процедуры измерения контрольного времени для повторной                              посылки сегментов                              Во-первых, измерьте время, прошедшее между посылкой октета дан-   ных, имеющего некий определенный номер в очереди, и получение под-   тверждения, указывающего наряду с другими и на этот номер (посыла-   емые сегменты не обязаны соответствовать полученным сегментам).   Измеренная временная задержка - это время обращения (Round Trip   Time - RTT). Следующий шаг - вычисление усредненного времени обра-   щения (Smoothed Round Trip Time - SRTT):               SRTT = (ALPHA * RSTT) + ( (1-ALPHA) * RTT)               Затем с помощью найденного значения определяется контрольное время   повторной посылки (Retransmission Timeout - RTO):            RTO = min[ UBOUND, max[ LBOUND, (BETA * SRTT) ]]           где UBOUND - верний предел контрольного времени (например, 1 мин),   LBOUND - нижний предел (например, 1 сек). ALPHA - фактор сглажива-   ния (например, от 0.8 до 0.9), а BETA - фактор изменения задержки   (например, от 1.3 до 2.0). 43.Оценка врмени оборота (двойного пробега). Причинами потери покетов могут являться ошибки, возникающие в заголовке IP, истечение времени жизни, переполнение буфера маршрутизатора и т.п. Во всех этих случаях отправляется сообщение ICMP. Время ожидания квитанции зависит от расстояния до получателя (от времени двойного пробега).
Существует 2 механиза определения времени двойного пробега:Тестирование сети и оценка в режиме пингования временной задержки на каждом сегменте. Затем осуществляется набор статистики и её обработка. Для определения времени ожидания квитанции к среднему времени задержки добавляются 4 среднеквадратических отклонения времени задержки от его математического ожидания. Именно за это время и должна придти квитанция. Если квитанция приходит после истечения таймера, передающая сторона считает пакет утерянным.Динамический способ определения таймера. Время двойного пробега определяется в процессе передачи. Первоначально передаются сегменты по одному в режиме РОС оЖ и определяется время пробега. Время таймера увеличивается до тех пор, пока квитанции не станут успевать приходить.К плюсам РОС ОЖ можно отнести простоту реализации. К минусам - непроизводительное использование пропускной способности и следовательно - низкая эффективная скорость ПД. 44.Метод борьбы с перегрузками по алгоритму Тахо (Tahoe). TCP-Tahoe

Алгоритм TCP-Tahoe является наиболее старым и широко распространенным [16]. Этот алгоритм был сформулирован Джакобсоном в 1988 году, некоторые коррекции были внесены в него позднее.

Если буфер переполнен, какое-то число сегментов будет потеряно. При этом может быть запущено несколько сценариев. Основной вариант - медленный старт, запускается в рамках классического алгоритма ТСР-Tahoe при потере сегмента и сопряженным с ним таймаутом (RTO) у отправителя, так как отправитель не получит сигнала подтверждения ACK для потерянного сегмента. Медленный старт предполагает установку окна перегрузки (CWND) равным 1, а порога медленного старта (ssthresh) равным половине значения CWND, при котором произошел таймаут. Сокращение CWND до единицы происходит потому, что отправитель не имеет никакой информации о состоянии сети. Далее после каждого подтверждения CWND_i+1 = CWND_i+1. Эта формула работает до тех пор, пока CWND не станет равным ssthresh. После этого рост CWND становится линейным (смотри формулу 1). Смысл этого алгоритма заключается в удержании значения CWND в области максимально возможных значений. По существу эта оптимизация осуществляется с помощью потери пакетов. Если потери пакетов не происходит, значение CWND достигает значения window по умолчанию, задаваемого при конфигурации ТСР-драйвера. На рис. 2 показана эволюция CWND при потере пакетов.

Рис. 2.

Значение таймаута вычисляется по формуле:

где s - средне-квадратичное отклонение среднего значения RTT.

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

Может возникнуть вопрос, почему при потере пакета CWND делается равным 1, а не CWND-1 или CWND/2? Ведь эффективность канала максимальна при наибольшем, возможном значении CWND. Если произошла потеря пакета из-за переполнения буфера, оптимальное значение CWND может быть выбрано лишь при исчерпывающем знании прогноза состояния виртуального канала. Постольку такая информация обычно недоступна, система переходит в режим освобождения буфера (CWND=1). Ведь если потеря была связана с началом сессии обмена с конкурирующим клиентом, операция CWND= CWND-1 проблему не решит. А потеря пакета вызовет таймаут и канал будет блокирован минимум на 1 секунду, что вызовет резкое падение скорости передачи.

Использование стартового значения CWND>1 может увеличить эффективность виртуального ТСР-канала. Стартовое значение CWND = 2*MSS представляется вполне разумным. Понятно, что в критических ситуациях CWND=1 должно быть непременно разрешено. На рис. 3 показана эволюция CWND (результат моделирования [3]) при двух последовательных медленных стартах (один из них может быть вызван случайной потерей сегмента). Отсюда видно, что случайные потери сильно понижают пропускную способность канала.

Рис. 3. Эволюция cwnd при двух медленных стартах

45.Борьба с перегрузками по алгоритму Рино (Renoe). Алгоритм TCP Reno имеет две фазы изменения размера окна: фаза медленного старта и фаза избегания перегрузки. Когда размер окна не превышает пороговую величину, передаю-щая сторона находится в фазе медленного старта, и размер окна растет экспоненциально.Исследование компьютерных программ при моделировании разных способов возбуждения колебаний позволяет определить точностные и частотные характеристики программ.Алгоритм TCP Reno имеет две фазы изменения размера окна: фаза медленного старта и фаза избегания перегрузки. Когда размер окна не превышает пороговую величину, передаю-щая сторона находится в фазе медленного старта, и размер окна растет экспоненциально.

Когда размер окна превышает пороговую величину, передающая сторона находится в фазе ухода от перегрузки, и размер окна перегрузки растет линейно. TCP Reno предусматривает выход из фазы медленного старта при получении трех дублирующих пакетов подтверждения АСК. «Досрочный» выход из фазы медленного старта называется ускоренным восстановлением. 46.Явное уведомление о перегрузках (предупреждение)(ECN-)

Комбинированный механизм управления перегрузками ECN

В 1994 году было предложено использовать новый механизм ECN

(Explicit Congestion Notification) – явное уведомление о перегрузке, в

первую очередь призванный управлять нагрузкой соединений TCP,

чувствительных к задержкам и потерям пакетов. При этом не используется

сброс пакета для подавления источника передачи данных в качестве

индикации перегрузки. В случае использования ECN передатчик должен

быть проинформирован о перегрузке заранее, то есть до ее наступления, а

не по факту самой перегрузки. Зачастую информацией о перегрузке в сети

обладают маршрутизаторы, работающие на 3-м уровне модели OSI, через

которые проходит поток данных соединения TCP. В связи с этим для

реализации ECN было необходимо использовать некоторые биты в IP-

заголовке. В 1999 году [6] было предложено добавить возможность

реализации ECN в IP-заголовок, а в 2001 году [7] реализация ECN была

дополнена и стандартизирована. На данный момент реализация ECN имеет

экспериментальный статус. ECN использует два бита (6 и 7) поля ToS

(Type of Service) – тип услуги:

– бит ECT (ECN-capable transport) – бит 6: источник устанавливает

значение бита в 1 для информирования приемника о том, что он

использует протокол TCP с поддержкой ENC;

– бит CE (congestion experienced) – бит 7: маршрутизатор

устанавливает значение бита в 1, информируя приемник о возникновении перегрузки.

Источник и приемник должны договориться о совместном

использовании механизма ECN при установке соединения, в результате

ECT-биты во всех последующих пакетах будут установлены в 1. В

результате каждый из маршрутизаторов на пути соединения будет

учитывать, что источник и приемник используют механизм ECN. При

возникновении перегрузки на любом из маршрутизаторов, он путем

установки значения СЕ-бита в 1 информирует приемник о перегрузке.

Приемник в свою очередь, получив от маршутизатора единичный СЕ-бит,

информирует источник о перегрузке путем посылки сегмента

подтверждения с установленным флагом ENC-Echo. Этот флаг

располагается в заголовке TCP и использует 9-й бит в поле reserved. После

получения сегмента с установленным флагом ENC-Echo источник

уменьшает значение размера окна перегрузки cwnd. Получение

информации о перегрузке источник индицирует путем посылки приемнику

сегмента с установленным флагом CWR (congestion window reduced) –

уменьшение размера окна перегрузки, для которого используется 8-й бит

поля reserved заголовка TCP. Таким образом, в механизме ECN

наблюдается совместное использование сетевого и транспортного уровней

модели OSI для управления перегрузкой – на сетевом уровне

сигнализируется перегрузка от маршрутизатора, а конечные устройства

используют сигнализацию с помощью обратной связи на транспортном

уровне.