5. Сетевой уровень 
Основное назначение сетевого уровня состоит в получении пакетов от всех источников и передача их по назначению. Передача по назначению может состоять из нескольких этапов, потребовать нескольких маршрутизаторов. Это, согласитесь, более сложная задача, чем у канального уровня - передать кадр с одного конца провода на другой. 
Для реализации своего назначения сетевой уровень  должен знать топологию транспортной подсети и выбрать подходящий путь в ней. Выбирая маршрут, он должен позаботиться, чтобы этот маршрут не привел к перегрузкам некоторых линий и маршрутизаторов. Наконец, если источник и получатель принадлежат разным сетям, то задача сетевого уровня, принимая во внимание различия между этими сетями, обеспечить корректную передачу данных из одной сети в другую. 
5.1. Проблемы построения сетевого уровня 
Сервис сетевого уровня разрабатывался в следующих целях: 
Сервис должен быть независимым от технологии передачи, используемой в среде передачи данных. 
Транспортный уровень должен быть независим от числа узлов, типа и топологии транспортной подсети. 
Адрес на сетевом уровне, доступный на транспортном уровне, должен иметь унифицированную форму по всей сети. 
Разработчик сетевого уровня свободен в выборе сервиса сетевого уровня. Однако эта свобода выливается в жестокие баталии. Основной их причиной является вопрос: должен ли сетевой уровень быть ориентированным на соединения или нет? 
5.1.1. Ориентация на соединение 
Представители лагеря Internet считают, что задача сетевого уровня - передвигать биты туда-сюда и ничего более. С их точки зрения транспортная среда ненадежна по определению, вне зависимости от того, как она построена. Поэтому хосты должны восполнять изъяны транспортной среды, т.е. контролировать ошибки и управлять потоками. 
Отсюда следует, что сервис на сетевом уровне не должен быть ориентирован на соединения, с примитивами типа SEND_PACKET, RECEIVE_PACKET. Никакой проверки упорядоченности пакетов, управления потоком, перегрузками здесь не должно быть. Это все должны делать хосты. Каждый пакет должен нести полный адрес назначения, поскольку пакеты отправляются абсолютно независимо. 
Представители другого лагеря - телефонные компании, основываясь на своем столетнем опыте эксплуатации телефонных сетей, считают, что сетевой уровень должен быть надежным и ориентированным на соединения. С их точки зрения соединения должны обладать следующими свойствами: 
Прежде чем передача начнется, передающая сторона должна установить соединение с равнозначной сущностью на принимающей стороне. При этом ей должен быть сообщен специальный идентификатор, который используется в течение всей передачи. 
Когда соединение установлено, два процесса начинают переговоры о параметрах, качестве и стоимости предоставляемого сервиса. 
Передача происходит в двух направлениях, а пакеты посылаются в определенном порядке. 
Управление потоком предоставляется автоматически, чтобы избежать переполнения на противоположной стороне. 
Другие возможности, такие как гарантированная доставка, явное подтверждение доставки, приоритетные пакеты являются необязательными. Как мы уже отмечали в главе 1, сервис, не ориентированный на соединение, подобен обычной почте, а ориентированный на соединение - телефонной системе. 
Спор между сторонниками сервиса с соединениями и без соединений - это, по существу, спор о том, где поместить основную вычислительную сложность. Сервис, ориентированный на соединение, предполагает, что эта сложность приходится на сетевой уровень, т.е. на транспортную среду. Сервис без соединений - на транспортный уровень, а стало быть - на хост. Защитники сервиса без соединения говорят, что стоимость вычислительных средств падает, а их мощность растет, так что нет причин не нагрузить хост. В то же время подсеть - это всеобщая инвестиция, и часто модернизировать подсеть вряд ли будет возможно. Так что она должна оставаться неизменной как можно дольше. Кроме этого, для многих приложений скорость доставки важнее, чем ее аккуратность. 
Сторонники сервиса, ориентированного на соединение, считают, что большинство пользователей не хотят гонять сложные транспортные протоколы на своих машинах. То, что им надо, так это надежный сервис, а таковой могут предоставить соединения на сетевом уровне. Более того, многие приложения, такие как передача звука и изображения в реальном масштабе времени, легче связывать с соединениями на сетевом уровне, чем с сетевым уровнем без соединений. 
Так каким же должен быть сетевой уровень - надежным, ориентированным на соединения, или ненадежным без соединений? Два ответа на этот вопрос предоставляют Internet и ATM. В Internet сетевой уровень действует без соединений и предполагается ненадежным. В АТМ - с соединениями и надежный. 
Естественный вопрос: как Internet работает над АТМ? Сначала на уровне АТМ устанавливается соединение между источником и получателем, а потом над этим соединением работает TCP/IP, как это показано на рисунке 5-1. Однако здесь очень много избыточности и ненужного дублирования. Так, например, АТМ-уровень гарантирует, что пакеты доставляются точно в том порядке, в каком они отправлялись источником, тем не менее, на уровне ТСР происходит проверка последовательности пакетов и переупорядочение в соответствии с RFC 1577. 
Рисунок 5-1. Работа TCP/IP над АТМ 
 




5.1.2. Внутренняя организация сетевого уровня 
С точки зрения внутренней организации сетевой уровень делится на ориентированный на соединения и без соединений. В первом случае соединение называют виртуальным каналом, по аналогии с физическим каналом в телефонных сетях. Во втором случае о пакетах говорят как о дейтаграммах, по аналогии с телеграммами. 
Идея виртуального канала – избежать маршрутизации для каждого пакета. Маршрут устанавливается один раз при установлении виртуального канала между отправителем и получателем и в дальнейшем не меняется до тех пор, пока передача не закончится. Подсеть запоминает выбранный маршрут. После окончания передачи, когда соединение разрывается, виртуальный канал уничтожается. 
При подходе без соединения каждый пакет маршрутизируется независимо. Разные пакеты могут следовать разными маршрутами. Продвижение по разным маршрутам может требовать разное время. Вследствие такой организации подсеть более надежна, способна гибко реагировать на ошибки и перегрузки. Позже мы вернемся к обсуждению всех pro и contra этих двух подходов. 
Каждый маршрутизатор в сети, ориентированной на виртуальные каналы, должен помнить, какие каналы проходят через него. У каждого маршрутизатора есть таблица виртуальных каналов. Каждый пакет должен иметь дополнительное поле, где хранится номер виртуального канала. Когда пакет приходит к маршрутизатору, то, зная линию, по которой он пришел, и номер виртуального канала, указанный в пакете, по таблице маршрутизатор устанавливает, по какой линии надо отправить пакет далее. 
При установлении соединения номер виртуального канала выбирается из числа неиспользуемых в данный момент на данной машине. Так как каждая машина выбирает номер канала независимо, то этот номер имеет лишь локальное значение. Заметим, что каждый процесс должен указать ожидаемое время освобождения виртуального канала. В противном случае возникнут проблемы с принятием решения при освобождении виртуального канала: может быть, одна из машин на маршруте «зависла». 
Итак, при использовании виртуальных каналов транспортной среде предстоит немало работы. В случае дейтаграмм никакой таблицы виртуальных каналов в каждом маршрутизаторе иметь не надо. Вместо этого у них есть таблица, в которой указано, какую линию надо использовать, чтобы доставить пакет по тому или иному адресу. Такая таблица нужна и при виртуальных каналах, когда устанавливается соединение. 
У каждой дейтаграммы должен быть полный адрес доставки. В больших сетях этот адрес может быть достаточно большим (десятки байт). Когда пакет поступает, маршрутизатор по таблице и адресу определяет, по какой линии надо отправить эту дейтаграмму, и посылает ее туда. 
  
   

  

  
   

  

5.1.3. Сравнение транспортных сред с виртуальными каналами и с дейтаграммами 
Результаты сравнения подсетей этих двух видов собраны в таблице 5-2. Выбор той или иной внутренней организации транспортной среды требует определенного компромисса. Так, например, использование виртуального канала избавляет от необходимости прописывать в каждом пакете длинный адрес доставки. Однако в то же время это предполагает затраты памяти у маршрутизатора на хранение таблиц. Так что здесь явный компромисс между пропускной способностью и памятью маршрутизатора. 
Таблица 5-2. Сравнение подсетей с виртуальными каналами и дейтаграммами 
Признак 
Подсеть с дейтаграммами 
Подсеть с виртуальными каналами 
Настройка канала 
Не нужна. 
Необходима. 
Адресация 
Каждый пакет содержит полный адрес источника и получателя. 
Каждый пакет содержит короткий номер ВК. 
Информация о состоянии подсети 
Подсеть не располагает информацией о состоянии подсети. 
Каждый ВК требует таблицу состояния подсети. 
Выбор маршрута 
Каждый пакет доставляется независимо. 
Маршрут выбирается после установления ВК; все пакеты направляются по этому маршруту. 
Влияние сбоя маршрутизатора 
Никакого, за исключением случая, когда во время сбоя теряются пакеты. 
Все ВК, проходящие через такой маршрутизатор, обрываются. 
Контроль перегрузок 
Сложный 
Простой, если заранее будет выделено достаточно буферов для каждого ВК 
Другим компромиссом является время установки соединения в сравнении с временем на разбор адреса доставки. В подсетях с виртуальными каналами требуется время на установление канала. Однако для один раз установленного канала не требуется больших усилий, чтобы направить по нему пакет. При дейтаграммном подходе надо выполнять каждый раз достаточно сложную процедуру, чтобы определить, куда посылать дейтаграмму. 
Виртуальные каналы имеют известные преимущества при борьбе с перегрузками, так как при установке виртуального канала можно заранее зарезервировать ресурсы. Начав передачу пакетов, можно быть уверенным, что необходимая пропускная способность и ресурсы маршрутизатора есть. Борьба с перегрузками при дейтаграммном подходе намного сложнее. 
Для систем обработки транзакций (кредитные карты, всякого рода покупки через сеть) накладные расходы на установление виртуального канала каждый раз были бы расточительны. Однако постоянные виртуальные соединения, устанавливаемые вручную на недели или месяцы, вполне оправданны. 
Виртуальные каналы слабо устойчивы к сбоям. Если при работе подсети хоть на какое-то время выйдут из строя маршрутизаторы, то все виртуальные каналы, проходящие через них, будут разрушены. В то же время при использовании дейтаграмм самое худшее, что произойдет при временном отказе маршрутизатора, - пропадут пакеты, находящиеся в это время в памяти маршрутизаторов. 
Следует подчеркнуть, что тип сервиса (с соединением или без) и внутренняя организация транспортной среды - виртуальные каналы или дейтаграммы - вопросы независимые. Теоретически возможны все четыре комбинации. Возможны сервис с соединением в дейтаграммных транспортных средах, когда надо обеспечить очень надежный сервис; сервис без соединения над виртуальными каналами - TCP/IP над АТМ. Примеры всех четырех случаев представлены на рисунке 5-3. 
Рисунок 5-3. Комбинации типов сервиса и организаций транспортных сред 
 
  
   

  

  
   

  

5.2. Алгоритмы маршрутизации 
Основной задачей сетевого уровня является маршрутизация пакетов. Пакеты маршрутизируются всегда, независимо от того, какую внутреннюю организацию имеет транспортная среда - с виртуальными каналами или дейтаграммную. Разница лишь в том, что в первом случае этот маршрут устанавливается один раз для всех пакетов, а во втором - для каждого пакета. В первом случае говорят иногда о маршрутизации сессии, потому что маршрут устанавливается на все время передачи данных пользователя, т.е. сессии. 
Алгоритм маршрутизации - часть программного обеспечения сетевого уровня. Он отвечает за определение, по какой линии отправлять пакет дальше. Вне зависимости от того, выбирается маршрут для сессии или для каждого пакета в отдельности, алгоритм маршрутизации должен обладать рядом свойств: корректностью, простотой, устойчивостью, стабильностью, справедливостью и оптимальностью. Если корректность и простота комментариев не требуют, то остальные свойства надо разъяснить. 
Алгоритм маршрутизации должен быть устойчивым, т.е. сохранять работоспособность независимо ни от каких сбоев или отказов в сети, изменений в ее топологии (отключение хостов, машин транспортной подсети, разрушения каналов и т.п). Алгоритм маршрутизации должен адаптироваться ко всем таким изменениям, не требуя перезагрузки сети или остановки абонентских машин. 
Стабильность алгоритма - также весьма важный фактор. Существуют алгоритмы маршрутизации, которые никогда не сходятся к какому-либо равновесному состоянию, как бы долго они ни работали. Это означает, что адаптация алгоритма к изменениям в конфигурации транспортной среды может оказаться весьма продолжительной. Более того, она может оказаться сколь угодно долгой. 
Справедливость значит, что все пакеты, вне зависимости от того, из какого канала они поступили, будут обслуживаться равномерно, никакому направлению не будет отдаваться предпочтение, для всех абонентов будет всегда выбираться оптимальный маршрут. Надо отметить, что справедливость и оптимальность часто могут вступать в противоречие друг с другом. На рисунке 5-4 приведен пример такого противоречия. Трафики между А-А', В-В', С-С' могут уже забить канал между Х-Х'. Поэтому вместо кратчайшего маршрута между Х и Х” надо будет выбирать какой-то другой маршрут. 
Рисунок 5-4. Конфликт между справедливостью и оптимальностью 
 
Прежде чем искать компромисс между оптимальностью и справедливостью, мы должны решить, что является критерием оптимизации. Один из возможных критериев - минимизация средней задержки пакета. Другой - максимизация пропускной способности сети. Однако эти критерии конфликтуют. Согласно теории массового обслуживания, если система с очередями функционирует близко к своему насыщению, то задержка в очереди увеличивается. Как компромисс, во многих сетях минимизируется число переходов между маршрутизаторами - один такой переход мы будем называть скачком (hop). Уменьшение числа скачков сокращает маршрут, а следовательно, сокращает задержку, а также минимизирует потребляемую пропускную способность при передаче пакета. 
Алгоритмы маршрутизации можно разбить на два больших класса: адаптивные и неадаптивные. Неадаптивные алгоритмы не принимают в расчет текущую загрузку сети и состояние топологии. Все возможные маршруты вычисляются заранее и загружаются в маршрутизаторы при загрузке сети. Такая маршрутизация называется статической маршрутизацией. 
Адаптивные алгоритмы, наоборот, определяют маршрут, исходя из текущей загрузки сети и топологии. Адаптивные алгоритмы различаются тем, где и как они получают информацию (локально от соседних маршрутизаторов или глобально от всех), когда они меняют маршрут (каждые Т секунд, когда меняется нагрузка, когда меняется топология), какая метрика используется при оптимизации (расстояние, число скачков, ожидаемое время передачи). 
  
   

  

  
   

  

5.2.1. Принцип оптимальности 
Прежде чем мы приступим к рассмотрению конкретных алгоритмов маршрутизации, сформулируем принцип оптимальности. Этот принцип утверждает, что если маршрутизатор J находится на оптимальном пути между маршрутизаторами I и K, то оптимальный маршрут между J и K принадлежит этому оптимальному пути. Это так, поскольку существование между J и K оптимального маршрута, отличного от части маршрута между I и K, противоречил бы утверждению об оптимальности маршрута между I и K. Дело в том, что если рассмотреть маршрут от I до К, как от I до J (назовем его S1) и от J до К (назовем его S2), то если между J и К есть маршрут лучше, чем S2, например S3, то маршрут S1S2 не может быть лучшим. Взяв конкатенацию маршрутов S1S3, мы получим лучший маршрут, чем маршрут S1S2. 
Следствием из принципа оптимальности является утверждение, что все маршруты к заданной точке сети образуют дерево с корнем в этой точке. Это дерево называется деревом захода, оно проиллюстрировано на рисунке 5-5. 
Рисунок 5-5. Дерево захода 
 
Поскольку дерево захода - это дерево, то там нет циклов, поэтому каждый пакет будет доставлен за конечное число шагов. На практике все может оказаться сложнее. Маршрутизаторы могут выходить из строя, и, наоборот, появляться новые, каналы могут выходить из строя, разные маршрутизаторы могут узнавать об этих изменениях в разное время и т.д. и т.п. 
  
   

  

  
   

  

5.2.2. Маршрутизация по наикратчайшему пути 
Наше изучение алгоритмов маршрутизации мы начнем со статического алгоритма, широко используемого на практике в силу его простоты. Идея этого алгоритма состоит в построении графа транспортной среды, где вершины - маршрутизаторы, а дуги - линии связи. Алгоритм находит для любой пары маршрутизаторов, а точнее абонентов, подключенных к этим маршрутизаторам, наикратчайший маршрут в этом графе. 
Проиллюстрируем идею алгоритма нахождения наикратчайшего пути на рисунке 5-6 (стрелками обозначены задействованные узлы). На дугах этого графа указаны веса, которые представляют расстояние между дугами. Расстояние можно измерять в переходах, а можно в километрах. Возможны и другие меры. Например, дуги графа могут быть размечены весами, величина которых равна средней задержке пакетов в соответствующем канале. В графе с такой разметкой наикратчайший путь - наибыстрейший путь, хотя он не обязательно имеет минимальное число переходов или километров. 
Рисунок 5-6. Расчет кратчайшего пути от А к B 
 
В общем случае веса на дугах могут быть функциями от расстояния, пропускной способности канала, среднего трафика, стоимости передачи, средней длины очереди в буфере маршрутизатора к данному каналу и других факторов. Изменяя весовую функцию, алгоритм будет вычислять наикратчайший путь в смысле заданной метрики. 
Известно несколько алгоритмов вычисления наикратчайшего пути в графе. Один из них предложил голландский математик Эдсгер Дейкстра. Идею этого алгоритма можно описать так. Все вершины в графе, смежные исходной вершине, помечают расстоянием (оно указано в скобках) до исходной вершины. Изначально никаких путей не известно и все вершины помечены бесконечностью. По мере работы алгоритма и нахождения путей, метки могут меняться. Метки могут быть двух видов: либо пробными, либо постоянными. Изначально все метки пробные. Когда обнаруживается, что метка представляет наикратчайший путь до исходной вершины, она превращается в постоянную метку и никогда более не меняется. 
На рисунке 5-6 показан процесс построения маршрута из А в D. Помечаем вершину А как постоянную (вершина, закрашенная черным цветом). Все вершины, смежные А, помечаем как временные (эти вершины не закрашены), а также указываем в метке их вершину, из которой мы апробировали данную вершину. Это позволит нам впоследствии изменить маршрут, если надо. Кроме этого, все вершины, смежные А, помечаем расстоянием от А до этой вершины. Из всех смежных вершин мы выберем ту, расстояние до которой самое короткое, и ее объявляем рабочей. Таким образом, мы выберем на первом шаге вершину В, а затем Е. 
Самое интересное возникнет на шаге (d). В соответствии с принципом наикратчайшего пути мы в качестве рабочей выберем вершину G. Теперь, на шаге (е), когда мы начнем искать вершины, смежные Н, то увидим, что путь F до Н короче, чем от G до Н. Поэтому на шаге (е) мы в качестве рабочей возьмем вершину F, а затем Н. На рисунке 5-7 дано описание алгоритма Дейкстры. Надо сделать оговорку, что этот алгоритм строит наикратчайший путь, начиная от точки доставки, а не от точки отправления. Поскольку граф не ориентированный, то это никакого влияния на построение пути не оказывает. 
Рисунок 5-7. Алгоритм Дейкстры 
 
  
   

  

  
   

  

5.2.3. Маршрутизация лавиной 
Другим примером статического алгоритма может служить следующий алгоритм: каждый поступающий пакет отправляют по всем имеющимся линиям, за исключением той, по которой он поступил. Ясно, что если ничем не ограничить число повторно генерируемых пакетов, то их число может расти неограниченно. Время жизни пакета ограничивают областью его распространения. Для этого в заголовке каждого изначально генерируемого пакета устанавливается счетчик переходов. При каждой пересылке этот счетчик уменьшается на единицу. Когда он достигает нуля, пакет сбрасывается и далее не посылается. В качестве начального значения счетчика выбирают наихудший случай, например, диаметр транспортной подсети. 
Другим приемом, ограничивающим рост числа дублируемых пакетов, является отслеживание на каждом маршрутизаторе тех пакетов, которые через него однажды уже проходили. Такие пакеты сбрасываются и больше не пересылаются. Для этого каждый маршрутизатор, получая пакет непосредственно от абонентской машины, помечает его надлежащим числом. В свою очередь, каждый маршрутизатор ведет список номеров, сгенерированных другим маршрутизатором. Если поступивший пакет уже есть в списке, то этот пакет сбрасывается. Для предотвращения безграничного роста списка вводят ограничительную константу k. Считается, что все номера, начиная с k и далее, уже встречались. 
Несмотря на кажущуюся неуклюжесть, этот алгоритм применяется, например, в распределенных базах данных, когда надо параллельно обновить данные во всех базах одновременно. Этот алгоритм всегда находит наикратчайший маршрут за самое короткое время, поскольку все возможные пути просматриваются параллельно. 
  
   

  

  
   

  

5.2.5. Маршрутизация по вектору расстояния 
Все современные транспортные подсети используют динамическую маршрутизацию, а не статическую. Один из наиболее популярных алгоритмов - маршрутизация по вектору расстояния. Этот алгоритм построен на идеях алгоритмов нахождения кратчайшего пути Беллмана-Форда и алгоритма Форда-Фолкерсона, определяющего максимальный поток в графе. Он изначально использовался в сети ARPA и используется по сей день в протоколе RIP (Routing IP). Оба эти алгоритма можно посмотреть в T.H. Cormen, C.E. Leiserson, R.L. Rivest Introduction to Algorithms. MIT Press, 1990. Он используется в сетях Novell, AppleTalk, маршрутизаторах Cisco. 
Алгоритм маршрутизации по вектору расстояния устроен следующим образом: у каждого маршрутизатора в транспортной подсети есть таблица расстояний до каждого маршрутизатора, принадлежащего подсети. Периодически маршрутизатор обменивается такой информацией со своими соседями и обновляет информацию в своей таблице. Каждый элемент таблицы состоит из двух полей: первое - номер канала, по которому надо отправлять пакеты, чтобы достичь нужного места, второе - величина задержки до места назначения. Величина задержки может быть измерена в разных единицах: числе переходов, миллисекундах, длине очереди на канале и т.д. Фактически в протоколе использовалась версия алгоритма, где эту задержку определяли не на основе пропускной способности канала, а на основе длины очереди к каналу. 
Каждые Т секунд маршрутизатор шлет своим соседям свой вектор задержек до всех маршрутизаторов в подсети. В свою очередь, он получает такие же вектора от своих соседей. Кроме этого, он постоянно замеряет задержки до своих соседей. Поэтому, имея вектора расстояний от соседей и зная расстояние до них, маршрутизатор всегда может вычислить кратчайший маршрут до определенного места в транспортной среде. 
Рассмотрим пример на рисунке 5-10. На рисунке 5-10 (а) показана подсеть. На рисунке 5-10 (b) показаны вектора, которые  маршрутизатор J получил от своих соседей, и его замеры задержек до них. Там же показана итоговая таблица маршрутизации, которую J вычислит на основании этой информации. 
Рисунок 5-10. Маршрутизация по вектору расстояния 
 
Рассмотрим, как маршрутизатор J с помощью этой таблицы вычислит маршрут до G. J знает, что он может достичь А за 8 мсек., А объявляет, что от него до G 18 мсек. Таким образом, J может достичь G за 26 мсек. через A. Аналогично можно подсчитать, что достичь G через I, H и K можно за 41 (31+10), 18 (6+12) и 37 (31+6) мсек. соответственно. Наилучшее значение – 18, поэтому это и есть наилучший маршрут. 
  
   

  

  
   

  

5.2.5.1. Проблема счетчика до бесконечности 
Алгоритм маршрутизации по вектору расстояния теоретически работает хорошо, но у него есть один недостаток: он очень медленно реагирует на разрушения каналов в транспортной среде. Информация о появлении хорошего маршрута в подсети распространяется более или менее быстро, а вот данные о потере, разрушении какого-то маршрута распространяются не столь быстро. 
Рассмотрим пример на рисунке 5-11 (а). В нем показана линейная транспортная среда. Пусть изначально маршрутизатор А не работал. Поэтому у всех маршрутизаторов в подсети расстояние до него было равно ?. Пусть в какой-то момент времени А был включен. По истечении определенного времени маршрутизаторы начнут обмениваться векторами, и В узнает об А. Еще через один обмен векторами об А узнает С, и т.д. Таким образом, информация о новом маршруте будет распространяться линейно шаг за шагом, за каждый обмен векторами. Если самый длинный маршрут в подсети имеет длину N, то потребуется N обменов векторами, пока информация о новом маршруте дойдет до самого удаленного узла в подсети. 
Рисунок 5-11. Проблема счетчика до бесконечности 
 
Теперь рассмотрим обратную ситуацию на рисунке 5-11(b). Здесь изначально все маршрутизаторы и каналы были работоспособны. Пусть в какой-то момент времени канал между А и В оказался разрушен. В перестает видеть А, но С говорит В: «Не беспокойся, у меня есть маршрут до А». При этом В не подозревает, что маршрут от С до А идет через него же. Маршрутизаторы D и Е своих таблиц не меняют. Их расстояния до А на единицу больше, чем у С. На втором обмене С увидит, что оба его соседа достигают А за 3 единицы. С выбирает одного некоторым случайным образом, увеличив значение 3 на единицу. Плохая весть будет распространяться медленно, пока счетчики задержек не примут значения бесконечности для данной сети. Только после этого станет ясно, что А не достижим ни через С, ни через D, ни через Е. Сколько времени на это потребуется, зависит от конкретного значения бесконечности в данной подсети. 
  
   

  

  
   

  

5.2.5.2. Разделение направлений (Split Horizon Hack) 
Одним из решений этой проблемы является следующий прием. Алгоритм работает так, как было описано, но при передаче вектора по линии, по которой направляются пакеты для маршрутизатора Х, т.е. по которой достижим маршрутизатор Х, расстояние до Х указывается как бесконечность. Если теперь рассмотреть то, как будет работать подсеть на рисунке 5-11(b), то там проблем возникать не будет. Действительно, когда А «упадет», при первом же обмене В это обнаружит, но С также будет слать В вектор, согласно которому А не достижимо (?). На следующем обмене С увидит, что А недостижим из обоих его соседей, и также отметит его как недостижимый узел. 
Однако и в алгоритме разделения направлений есть «дыры». Рассмотрим подсеть на рисунке 5-12. Если линия между С и D будет разрушена, то С сообщит об этом А и В. Однако А знает, что у В есть маршрут до D, а В знает, что такой маршрут есть и у А. И опять мы «сваливаемся» в проблему бесконечного счетчика. 
Рисунок 5-12. Случай, при котором разделение направлений не помогает 
 
  
   

  

  
   

  

5.2.6. Маршрутизация по состоянию канала 
Алгоритм маршрутизации по вектору расстояний использовался в сети ARPANET до 1979 года, после чего он был заменен. Тому было две основных причины. Первая - пропускная способность канала никак не учитывалась, поскольку основной мерой задержки была длина очереди. Пока основная масса каналов имела пропускную способность 56 Кбит/сек., это было не страшно. Однако, когда появились каналы на 230 Кбит/сек. и 1,5 Мбит/сек., это стало недостатком. Вторая проблема – медленная сходимость алгоритма при изменениях. По этим причинам был создан новый алгоритм маршрутизации по состоянию канала. 
Основная идея построения этого алгоритма проста и состоит из пяти основных шагов: 
1.Определить своих соседей и их сетевые адреса. 
2.Измерить задержку или оценить затраты на передачу до каждого соседа. 
3.Сформировать пакет, где указаны все данные, полученные на шаге 2. 
4.Послать этот пакет всем другим маршрутизаторам. 
5.Вычислить наикратчайший маршрут до каждого маршрутизатора. 
Топология и все задержки оцениваются экспериментально и сообщаются всем узлам. После этого можно использовать, например, алгоритм Дейкстры для вычисления наикратчайшего маршрута. Теперь рассмотрим подробнее эти пять шагов. 
  
   

  

  
   

  

5.2.6.1. Определение соседей 
При загрузке маршрутизатор прежде всего определяет, кто его соседи. Для этого он рассылает по всем своим линиям точка-точка специальный пакет HELLO. В ответ все маршрутизаторы отвечают, указывая свое уникальное имя. Имя маршрутизатора должно быть уникальным в сети, чтобы избежать неоднозначностей. Если же два и более маршрутизатора соединены одним каналом, как на рисунке 5-13 (а), то этот канал в графе связей представляют отдельным, искусственным узлом (рисунок 5-13 (b)). 
Рисунок 5-13. Определение соседей 
 
  
   

  

  
   

  

5.2.6.2. Оценка затрат 
Оценка затрат до каждого соседа происходит с помощью другого специального пакета EСHO. Это пакет рассылается всем соседям, при этом   замеряется задержка от момента отправки этого пакета до момента его возвращения. Все, кто получает такой пакет, обязаны отвечать незамедлительно. Такие замеры делают несколько раз и вычисляют среднее значение. Таким образом, длина очереди к каналу не учитывается. 
Здесь есть одна тонкость: учитывать загрузку в канале или нет? Если учитывать, то задержку надо замерять от момента поступления пакета в очередь к каналу. Если не учитывать, то от момента, когда пакет достиг головы очереди. Есть доводы, как в пользу учета нагрузки, так и против такого учета. Учитывая нагрузку, мы можем выбирать между двумя и более каналами с одинаковой пропускной способностью, получая лучшую производительность. Однако можно привести примеры, когда ее учет вызывает проблемы. Например, рассмотрим рисунок 5-13 (с). Здесь два одинаковых по производительности канала CF и EI соединяют две сети. Если на одном из них нагрузка меньше, то предпочтительнее будет другой, что через некоторое время приведет к его перегрузке и предпочтительнее должен стать первый. Если нагрузка не учитывается, то этой проблемы не возникает. 
Рисунок 5-13 (с). Определение затрат 
 
  
   

  

  
   

  

5.2.6.3. Формирование пакета состояния канала 
После того как измерения выполнены, можно сформировать пакет о состоянии каналов. На рисунке 5-14 показаны пакеты для примера сети. В пакете указаны: отправитель, последовательное число, возраст (назначение этих полей станет ясно позднее), список соседей и задержки до них. Формирование таких пакетов не вызывает проблем. Основной вопрос - когда их формировать? Периодически, с каким-то интервалом, или по особому событию, когда в транспортной подсети произошли какие-то существенные изменения? 
Рисунок 5-14. Формирование пакетов состояния канала 
 
  
   

  

  
   

  

5.2.6.4. Распространение пакетов состояния каналов 
Наиболее хитрая часть этого алгоритма – как надежно распространить пакеты о состоянии каналов (СК-пакеты)? Как только СК-пакет получен и включен в работу, маршрутизатор будет его использовать при определении маршрута. При неудачном распространении СК-пакетов разные маршрутизаторы могут получить разное представление о топологии транспортной среды, что может приводить к возникновению циклов, недостижимых машин и другим проблемам. 
Сначала рассмотрим базовый алгоритм, потом некоторые его усовершенствования. СК-пакеты распространяются методом лавины, т.е. СК-пакет рассылается всем соседям, те, в свою очередь, своим соседям, и т.д. Однако, чтобы не потерять контроль и не вызвать неограниченное дублирование СК-пакетов, каждый маршрутизатор ведет счетчик последовательных номеров СК-пакетов, которые он сгенерировал. Все маршрутизаторы запоминают пары «маршрутизатор, последовательное число», которые они уже встречали среди полученных СК-пакетов. Если поступивший СК-пакет содержит пару, которая еще не встречалась маршрутизатору, то он отправляет этот СК-пакет всем своим соседям, за исключением того, от которого он его получил. Если он уже встречал такой пакет, то пакет сбрасывается и никуда не дублируется. 
У этого алгоритма есть несколько проблем, но все они разрешимые. Первая: размер поля последовательных номеров пакетов. Если оно будет недостаточно длинное, то его переполнение приведет к повтору номеров, что, в свою очередь, приведет к некорректной работе всего алгоритма. Решением является достаточно большое поле, например, 32-разрядное. При таком поле, если обмен СК-пакетами происходит раз в секунду, то потребуется 137 лет, чтобы возникло переполнение. 
Вторая проблема: если маршрутизатор «упал» по какой-либо причине и потерял последовательность использованных последовательных номеров, то неясно, как ее восстановить. 
Третья – если в результате передачи возникнет ошибка в одном бите, например, вместо 4 получим пакет с номером 65540, то все пакеты с 5 по 65540 будут сбрасываться как устаревшие, поскольку текущий номер - 65540. 
Для решения этих проблем используется поле «возраст» СК-пакета. Там устанавливается некоторая величина, которая уменьшается периодически на единицу каждую секунду. Когда она достигнет нуля, пакет сбрасывается. 
В целях сокращения числа рассылаемых СК-пакетов, когда такой пакет поступает, его не сразу дублируют и отправляют. Сначала его помещают в специальную область задержки. Там он находится некоторое время. Если за это время придет другой пакет от того же источника, то пакеты сравниваются. Если нет различий между ними, то вновь пришедший сбрасывается, если есть, то последний пришедший дублируется и отправляется другим, а первый сбрасывается. Все СК-пакеты передаются с уведомлением. 
Структура данных, используемая маршрутизатором В из примера на рисунке 5-14 (a), показана на рисунке 5-15. Каждая строка в этой таблице соответствует последнему поступившему, но не до конца обработанному СК-пакету. В этой таблице для каждой линии маршрутизатора В указано в виде флага, был ли соответствующий СК-пакет отправлен и подтвержден. Флаг отправления означает, что соответствующий СК-пакет должен быть послан по указанной линии. Флаг уведомления указывает на то, что по соответствующей линии должно прийти подтверждение. 
Рисунок 5-15. Буфер пакетов для маршрутизатора В из рисунка 5-14 
 
На рисунке 5-15 СК-пакет от А прибыл и должен быть переслан в С и F и подтвержден по А. Аналогичная ситуация с СК-пакетом от F. Существенно отличная ситуация с СК-пакетом от Е. От Е поступило два пакета. Один - по маршруту ЕАВ, другой – по маршруту EFB. Следовательно, СК-пакет должен быт послан только к С, а вот уведомления должны быть посланы и А, и F. Наличие дубликатов СК-пакетов легко распознать по состоянию флагов отправки. 
  
   

  

  
   

  

5.2.6.5. Вычисление нового пути 
Когда маршрутизатор получил полный комплект СК-пакетов, он может построить топологию транспортной среды и, например, локально запустить алгоритм Дейкстры для вычисления наикратчайшего пути. 
В системе, где есть n маршрутизаторов с k линий у каждого, каждый маршрутизатор должен иметь достаточно памяти, чтобы хранить необходимую информацию о сети. При больших n эта величина может стать существенной. Кроме этого, в сетях, где число маршрутизаторов достигает десятков или сотен тысяч, проблемы, вызванные сбоем одного из них, могут оказаться весьма серьезными. Например, если из-за сбоя в маршрутизаторе послан неправильный СК-пакет или неправильно оценено состояние канала, то в дальнейшем это может привести к проблемам. 
Маршрутизация по состоянию каналов широко используется в реальных сетях. Например, в протоколе OSPF, который мы будем подробно рассматривать позже. 
Другим важным примером может служить протокол IS-IS, который был изначально предложен фирмой DEC, а позже адаптирован ISO. IS-IS широко используется в Интернете. Поскольку OSPF появился позже IS-IS, он вобрал в себя все усовершенствования, сделанные для IS-IS. Основное различие между ними в том, что IS-IS может работать с разными протоколами сетевого уровня, что делает его весьма привлекательным при маршрутизации между разнотипными сетями, чего не может делать OSPF. 
  
   

  

  
   

  

5.2.7. Иерархическая маршрутизация 
По мере роста транспортной среды размер таблиц, т.е. затраты памяти, время процессора на обработку этих таблиц, пропускная способность каналов, затрачиваемая на передачу служебной информации, может превысить разумные пределы. Таким образом, дальнейший рост сети, когда каждый маршрутизатор знает все о каждом другом маршрутизаторе, будет невозможен. Решение этой проблемы – иерархия сетей, подобно иерархии коммутаторов в телефонной сети. 
На рисунке 5-16 (а) приведен пример сети с двухуровневой иерархией из пяти регионов. Здесь каждый из регионов соединен с двумя другими. На рисунке 5-16 (b) показана полная таблица маршрутизации для маршрутизатора 1А без иерархии. На рисунке 5-16 (с) – та же таблица при двухуровневой иерархии. Нетрудно видеть, что таблица маршрутизации во втором случае резко сократилась. 
Рисунок 5-16. Иерархическая маршрутизация 
 
Однако за эту экономию приходится платить эффективностью маршрутизации. Например, наилучший маршрут от 1А к 5С проходит через регион 2, однако в данном случае он пройдет через регион 3, поскольку большинство машин в регионе 5 действительно эффективнее достигнуть через регион 3. 
При построении иерархии возникает сразу несколько вопросов. Один из них: сколько уровней должно быть в иерархии при заданном размере сети? Например, если наша транспортная среда содержит 920 маршрутизаторов, то без иерархии таблица каждого будет иметь 920 строк. Если транспортную среду разбить на 40 регионов, то размер таблиц будет равен 23 строки для маршрутизации внутри региона плюс 40 для маршрутизации между регионами. Если использовать трехуровневую иерархию и объединить регионы в кластеры, то при 5 кластерах, по 8 регионов с 23 маршрутизаторами в каждом у таблицы будет 23 входа для внутрикластерной маршрутизации, плюс 7 входов для межкластерной, плюс 5 входов для межрегиональной маршрутизации. Итого 35 входов. 
Клейнрок и Камоун показали, что оптимальное число уровней иерархии в транспортной среде при N узлах будет равняться lnN, при e*lnN строках в таблице маршрутизатора. 
  
   

  

  
   

  

5.2.8. Маршрутизация для мобильного узла 
Миллионы людей в наши дни путешествуют, находятся в командировках. Многим из них просто необходимо иметь доступ к своей электронной почте, файловой системе. Так мы приходим к проблеме мобильного узла, которую мы уже отмечали. Это относительно новая проблема, но, несмотря на это, она стоит довольно остро. 
На рисунке 5-17 показана модель WAN с мобильным узлом. Всех пользователей мы можем разделить на две большие группы. Стационарные - это большая группа, их компьютеры подключены к сети стационарными средствами (проводами, кабелями) и редко меняют свое место положение. Другая группа постоянно меняет свое местоположение и стремится поддерживать связь с сетью. Этих пользователей мы будем называть мобильными. 
Рисунок 5-17. Модель WAN с мобильным узлом 
 
Предполагается, что в сети каждый пользователь имеет постоянное домашнее местоположение, которое никогда не меняется. Проблема маршрутизации в этих условиях заключается в том, чтобы посылать пакеты мобильному пользователю через его домашнее местоположение. При этом то, где находится сам пользователь, не имеет значения. Вся WAN на рисунке 5-17 разбивается на области. В каждой области есть агент визитеров, который знает о всех мобильных пользователях в своей области. В свою очередь, в каждой области есть домашний агент, который знает обо всех стационарных пользователях в своей области, которые в настоящий момент путешествуют. 
Как только мобильный узел подключается к местной, локальной сети, он регистрируется у агента визитеров. Эта процедура примерно выглядит так: 
1.Периодически агент визитеров рассылает по своей области пакет, где указано местоположение этого агента и его адрес. Если мобильный узел, подключившись к сети, долго не видит такого пакета, он рассылает свой пакет с просьбой агенту визитеров объявить свои координаты. 
2.Мобильный узел регистрируется у агента визитеров, указывая свое текущее местоположение, домашнее местоположение и определенную информацию, связанную с безопасностью передаваемых данных. 
3.Агент визитеров обращается через сеть к домашнему агенту домашнего местоположения визитера, указывая, что один из его пользователей сейчас находится в его области, передавая конфиденциальную информацию, которая должна убедить домашнего агента, что это действительно его пользователь пытается соединиться с ним. 
4.Домашний агент изучает конфиденциальные данные, время связи. Если эти данные соответствуют той информации, что есть у домашнего агента об этом пользователе, он дает добро на связь. 
5.Агент визитеров, получив подтверждение от домашнего агента, заносит данные о мобильном узле в свои таблицы и регистрирует его. 
В идеале пользователь, покидая область визита, должен закрыть свою временную регистрацию. Однако, как правило, закончив сеанс связи, пользователь просто выключает свой компьютер и все. Поэтому, если по прошествии некоторого времени пользователь не объявился вновь, агент визитеров считает его покинувшим область. 
Рассмотрим теперь, что происходит, когда кто-то посылает сообщения мобильному узлу (рисунок 5-18). Пакет поступает на адрес домашнего местоположения пользователя, где его перехватывает домашний агент. Домашний агент инкапсулирует этот пакет в свой пакет, который он отправляет по адресу агента визитеров той области, откуда последний раз был сеанс связи с пользователем. Одновременно с этим домашний агент посылает сообщение отправителю пакета, чтобы он все последующие пакеты мобильному узлу инкапсулировал в сообщениях, направляемых по адресу агента визитеров. Такой механизм инкапсулирования одних пакетов в другие называется туннелированием, и мы его подробно рассмотрим позднее. 
Рисунок 5-18. Маршрутизация пакетов для мобильных пользователей 
 
Здесь мы обрисовали лишь в общих чертах основную схему работы. Конкретных схем существует множество, которые различаются разными аспектами. Прежде всего тем, как распределяется работа между маршрутизаторами и хостами, какой уровень в стеке протоколов хоста отвечает за реализацию соответствующих протоколов. Во-вторых, есть схемы, где маршрутизаторы запоминают информацию о местонахождения мобильных узлов и могут вмешиваться в диалог между агентом визитеров и домашним агентом, по-разному маршрутизируя трафик. В некоторых схемах мобильный узел получает некоторый уникальный адрес, в других это адрес агента, который отвечает за маршрутизацию всего трафика мобильных узлов. Кроме этого, схемы различаются разным уровнем безопасности передаваемой информации. 
  
   

  

  
   

  

5.2.9. Маршрутизация при вещании 
В некоторых приложениях возникает потребность переслать одно и то же сообщение всем машинам. Например, прогноз погоды, биржевые сводки, новости и т.д. Такой режим передачи называется вещанием. Есть несколько способов реализации такого режима. 
Первый способ: источник знает, кому надо послать, и генерирует столько сообщений, сколько получателей. Это одно из самых плохих решений. Оно не требует никаких специальных средств, однако весьма накладно. Тратится не только пропускная способность каналов, но и память – ведь где-то кому-то надо хранить весь лист рассылки. 
Метод лавины – другое решение. Однако, как мы уже видели, он затратен для каналов «точка-точка». Он слишком сильно расходует пропускную способность. 
Третий подход – маршрутизация множественной доставки. Здесь каждый пакет должен иметь либо лист рассылки, либо карту рассылки. Каждый маршрутизатор, получив такой пакет, отправляет и дублирует его в соответствии с картой рассылки. 
Четвертый подход основан на использовании дерева захода, либо любого другого подходящего дерева связей. Дерево захода позволяет избежать циклов и ненужного дублирования пакетов. Каждый маршрутизатор дублирует пакет вдоль линий, соответствующих дереву захода, кроме той, по которой пакет пришел. В этом подходе очень рационально используется пропускная способность каналов, генерируется абсолютный минимум пакетов при рассылке. Однако каждый маршрутизатор где-то должен иметь дерево захода, соответствующее случаю. 
Пятый подход основан на неявном использовании дерева связей. Когда пакет поступает, маршрутизатор проверяет: если он поступил по линии, которая используется для отправления пакетов источнику вещательного пакета, то вещательный пакет дублируется и рассылается по всем линиям, кроме той, по которой пакет пришел. Если нет, то он сбрасывается. 
Этот метод называется пересылкой вдоль обратного пути. На рисунке 5-19 показан пример работы этого алгоритма. На рисунке 5-19 (a) показана топология транспортной среды. На рисунке 5-19 (b) показано дерево захода для вершины I, часть (c) показывает, как работает этот алгоритм. Сначала в вершине I было сгенерировано и разослано 4 пакета. Во всех четырех вершинах (F, H, J, N), куда поступили эти пакеты, они поступили с предпочтительного для I направления. Из восьми пакетов, сгенерированных на следующем этапе, дереву захода только пять поступили по предпочтительному для I направлению. На третьем этапе из шести сгенерированных пакетов только три поступили по предпочтительному направлению (G, D, N поступили дубликаты). После того, как пять этапов пройдены и сгенерированы 23 пакета, рассылка прекращается. Достоинством этого метода является простота и легкость в реализации. 
Рисунок 5-19. Пересылка вдоль обратного пути (а) Подсеть; (b) Связующее дерево; (с) Дерево, построенное методом пересылки вдоль обратного пути 
 
  
   

  

  
   

  

5.2.10. Маршрутизация при групповой передаче 
Этот вид передачи используют, когда надо обеспечить взаимодействие группы взаимосвязанных процессов, разбросанных по сети. Такие ситуации часто встречаются в распределенных базах данных. Если группа велика по сравнению с размерами сети, то можно воспользоваться методами вещания. Однако если ее размер мал относительно размера всей сети, то такой подход будет неэкономичен. Кроме того, если рассылаемая в группе информация конфиденциальная, то алгоритмы вещания не подходят. Этот вид маршрутизации называют групповой маршрутизацией. 
В случае обмена информации в группе, кроме алгоритма групповой маршрутизации, нужны алгоритмы управления группой, которые должны обеспечивать средства для реконфигурации группы: включение новых членов, удаление старых и т.п. Однако эти проблемы не затрагивают алгоритм групповой маршрутизации, поэтому мы их здесь рассматривать не будем. 
Алгоритм групповой маршрутизации, как правило, основан на дереве связей. Каждый маршрутизатор в транспортной среде вычисляет дерево связей, охватывающее все другие маршрутизаторы. На рисунке 5-20 (а) приведен пример транспортной среды, состоящей из двух групп (их номера указаны у вершин). Некоторые вершины принадлежат как группе 1, так и группе 2. На рисунке 5-20 (b) показано дерево связей для самой левой вершины. Когда процесс посылает групповой пакет, первый же маршрутизатор обрезает свое дерево связей, убирая из него все связи, которые не ведут в вершины, не являющиеся членами группы. На рисунке 5-20 (с) показано сокращенное дерево связей для группы 1. На рисунке 5-20 (d) дано сокращенное дерево связей для группы 2. 
Рисунок 5-20. Групповая маршрутизация 
 
Для обрезания дерева связей используются разные алгоритмы. Наиболее простой основан на применении алгоритма маршрутизации на основе состоянии канала. В этом случае каждый маршрутизатор имеет полную конфигурацию транспортной среды. Сокращение дерева связей начинается от вершин – членов группы и разворачивается в сторону корня, удаляя все маршрутизаторы, которые не ведут к членам группы. Существуют и другие подходы. 
  
   

  

  
   

  

5.3. Алгоритмы управления перегрузками 
Когда в транспортной среде находится в одно и тоже время слишком много пакетов, ее производительность начинает падать. На рисунке 5-21 показано явление перегрузки. Когда число пакетов, отправляемых абонентскими машинами в сеть, пропорционально возможностям сети, то число посланных пакетов пропорционально числу доставленных пакетов. Однако если число пакетов, поступающих в сеть, становится слишком большим, они начинают пропадать. При перегрузке сети может случиться, что доставка пакетов практически прекратится. 
Рисунок 5-21. Перегрузка 
 
Перегрузка может возникнуть в силу нескольких причин. Например, если сразу несколько потоков, поступающих по нескольким входным линиям, устремятся на одну и ту же выходную линию. Очередь на этой линии может расти бесконечно, и пакеты начнут посылаться повторно, так как они слишком долго будут находиться в очереди. Если буфер маршрутизатора переполнится, то пакеты начнут теряться. Увеличение памяти в этом случае вряд ли исправит положение. Пакеты долго будут находиться в памяти, и отправители начнут их дублировать. 
Перегрузки могут случаться и из-за недостаточной скорости процессора. Если процессор будет не в состоянии справиться своевременно с рутинными задачами (размещения пакета в буфере, корректировка таблиц и т.п.), то даже при наличии линий с достаточной пропускной способностью очередь будет расти. Аналогичная картина может случиться при быстром процессоре, но медленном канале и наоборот. Таким образом, источник проблемы - несбалансированность производительности компонентов системы. 
Перегрузки имеют тенденцию к самостоятельному росту и ухудшению ситуации. Если у маршрутизатора не хватает памяти буфера, то он начинает сбрасывать пакеты. Отправитель, не получая пакеты, начинает их повторять снова и снова, усугубляя положения получателя. 
Надо различать управление перегрузками сети и управление потоком. Перегрузка - это глобальная проблема в сети. Управление перегрузками - это такая организация потоков в транспортной среде, при которой потоки соответствуют пропускной способности подсети и не превышают ее. Это глобальная проблема в сети, затрагивающая поведение всех хостов и всех маршрутизаторов. 
Управление потоком возникает между парой взаимодействующих машин. Это локальная проблема, касающаяся двух взаимодействующих машин. Ее решение гарантирует, что быстрый отправитель сообщений не «завалит» нерасторопного получателя. Здесь яркими примерами могут быть: один быстрый компьютер передает файл в 1 Гб более медленному компьютеру через сеть с пропускной способностью 1 Тбит/сек. со скоростью 1 Гбит/сек. Ясно, что здесь не будет перегрузки, хотя быстрый компьютер может создать такой поток пакетов, что он захлестнет медленный. В тоже время, если в сети с линиями на 1 Мбит/сек. и 1000 компьютеров хотя бы половина машин начнет передавать файлы со скоростью 100 Кбит/сек. другой половине, то ясно, что перегрузки не избежать. 
Часто управление перегрузкой и управление потоком путают из-за того, что и там и там применяют одинаковые приемы, например, направляют источникам специальные пакеты, тормозящие нарастание потоков. 
  
   

  

  
   

  

5.3.1. Основные принципы управления перегрузками 
В терминологии теории управления все методы управления перегрузками в сетях можно разбить на две большие группы: с открытым контуром управления и закрытым контуром управления. Методы с открытым контуром предполагают, что все продумано и предусмотрено заранее в конструкции системы, и если нагрузка находится в заданных пределах, то перегрузки не происходит. Если же нагрузка начинает превышать определенные пределы, то заранее известно, когда и где начнется сброс пакетов, в каких точках сети начнется перепланировка ресурсов, и т.п. Главное, что все эти меры будут приниматься вне зависимости от текущего состояния сети. 
Решения, основанные на закрытом контуре, используют обратную связь. Эти решения включают три этапа: 
Наблюдение за системой для определения, где и когда началась перегрузка 
Передача данных туда, где будут предприняты надлежащие меры 
Перестройка функционирования системы для устранения проблемы 
При наблюдении за системой используются разные метрики для определения перегрузки. Основными среди них являются: 
процент пакетов, сброшенных из-за нехватки памяти в буферах 
средняя длина очередей в системе 
число пакетов, для которых наступил time_out и для которых были сделаны повторные передачи 
средняя задержка пакета при доставке и среднее отклонение задержки при доставке пакета 
Следующий шаг при использовании обратной связи - передать информацию о перегрузке туда, где что-то может быть сделано, чтобы исправить положение. Например, маршрутизатор, обнаруживший перегрузку, может направить сообщение о перегрузке всем источникам сообщений. Ясно, что это увеличит нагрузку в сети, причем именно в тот момент, когда это менее всего желательно. Однако есть и другие возможности. Например, в каждом пакете зарезервировать специальный бит перегрузки, и если какой-то маршрутизатор обнаружил перегрузку, то он устанавливает этот бит, тем самым сообщая другим о ней (вспомним структуру кадра во Frame Relay). 
Другое решение напоминает прием, используемый некоторыми радиостанциями: направлять несколько автомашин по дорогам, чтобы обнаруживать пробки, а затем сообщать о них по радиоканалам, предупреждая другие машины, призывая их пользоваться объездными путями. По аналогии с этим решением в сети рассылаются специальные пробные пакеты, которые проверяют нагрузку, и если где-то обнаружена перегрузка, то о ней сообщается всем и происходит перенаправление пакетов так, чтобы обогнуть перегруженные участки. 
Алгоритмы управления перегрузками подразделяются, как мы уже сказали, на решения с открытым и решения с закрытым контуром. Решения с открытым контуром, в свою очередь, делятся на две группы: воздействующие на источники и воздействующие на получателей. Решения с закрытым контуром - с явной обратной связью и неявной обратной связью. Явная обратная связь предполагает, что источнику посылается специальный пакет, который информирует его о перегрузке. Неявная обратная связь основана на том, что источник сам определяет факт перегрузки на основе своих локальных наблюдений за трафиком, например, по величине задержки на поступление уведомления о доставке пакета. 
Появление перегрузки означает, что нагрузка превысила, возможно временно, ресурсы системы или некоторой ее части. Есть два выхода из этого положения: увеличить ресурсы и сократить нагрузку. Увеличить ресурсы чаще всего невозможно. Тогда остается только сокращение нагрузки. Для этого есть несколько способов: отказать некоторым пользователям в сервисе, ухудшить сервис всем или некоторым пользователям, заставить пользователей планировать свои потоки определенным образом. 
  
   

  

  
   

  

5.3.2. Методы, предотвращающие перегрузки 
Рассмотрение методов, предотвращающих перегрузки, начнем с методов для систем с открытым контуром. Эти методы ориентированы на минимизацию перегрузок при первых признаках их проявлений, а не на борьбу с перегрузками, когда они уже случились. Основные факторы, влияющие на перегрузки на канальном, сетевом и транспортном уровнях, перечислены в таблице 5-22. 
Таблица 5-22. Факторы, влияющие на перегрузки 
Уровень 
Факторы 
Транспортный 
Повторная передача 
Порядок передачи бит 
Уведомления 
Управление потоком 
Значение timeout 
Сетевой 
Виртуальные каналы vs. дейтаграммы внутри подсети 
Очередность пакетов и сервисы 
Сброс пакета 
Алгоритм маршрутизации 
Управление временем жизни пакетов 
Канальный 
Повторная передача 
Порядок передачи бит 
Уведомления 
Управление потоком 
Начнем с канального уровня. Вызвать перегрузку может повторная пересылка кадров. Если у источника сообщений часто возникает time_out и он начинает повторно передавать пакет, то тем самым он лишь усугубляет положение. Близко к этому фактору стоит нарушение порядка следования пакетов при передаче. Если получатель часто сбрасывает пакеты, поступившие не в надлежащем порядке от источника, то их повторная передача будет также усугублять перегрузку. 
Организация рассылки уведомлений также влияет на перегрузку. Если уведомление происходит немедленно и специальными пакетами, то это увеличивает трафик и следовательно может привести к перегрузкам. Если для уведомления используются пакеты с сообщениями (прием piggybacking), то возможны time_out из-за отсутствия уведомлений вовремя и, как следствие, повторные пересылки пакетов, что может привести к перегрузкам. В то же время жесткая схема управления потоком (небольшое окно) сдерживает нарастание трафика и предотвращает появление перегрузок. 
На сетевом уровне выбор схемы работы - с виртуальными соединениями или дейтаграммами - влияет на появление перегрузок. На этом уровне большинство методов борьбы с перегрузками ориентированы на виртуальные соединения. Методы управления очередями, организация очередей: одна общая на входе или одна общая на выходе; по одной на каждую входную линию или на каждую выходную; по одной очереди на каждую входную и выходную - все это влияет на появление перегрузок. Выбор метода сброса пакетов также влияет на перегрузки. 
Правильная маршрутизация, равномерно использующая каналы в транспортной среде, позволяет избежать перегрузки. Методы, регулирующие время жизни пакета в сети, также влияют на образование перегрузок. Если пакет долго блуждает в сети, прежде чем будет принято решение о его сбросе, то это плохо, так как увеличивает трафик и может привести к перегрузке. Если поторопиться, то преждевременный сброс пакета может привести к повторным передачам, что опять-таки увеличит нагрузку. 
На транспортном уровне возникают те же самые проблемы, что и на канальном, однако определить величину time_out намного сложнее. Дело в том, что оценить время передачи через СПД много сложнее, чем время передачи по каналу «точка-точка» между двумя маршрутизаторами. Если оно будет слишком большим, то это снизит вероятность перегрузки, но повлияет на производительность из-за длительного ожидания поступления пакета. Если сделать его коротким, то появятся лишние пакеты. 
  
   

  

  
   

  

5.3.3. Формирование трафика 
Одной из основных причин перегрузки является нерегулярный, взрывообразный трафик в сети. Если бы он был равномерным, то перегрузок можно было бы избежать. Один из методов с открытым контуром, часто используемым особенно в АТМ-сетях, - метод формирования трафика (shaping - т.е. придание формы), когда скорость передачи пакетов контролируется и регулируется. 
Формирование трафика регулирует среднюю скорость передачи данных так, чтобы сделать его по возможности гладким. Следует обратить внимание, что протокол скользящего окна, который мы рассматривали при изучении канального уровня, лишь регулирует объем данных, передаваемых за один раз, но не скорость передачи. Здесь же речь идет именно о скорости передачи. Когда виртуальное соединение устанавливается, то пользователь договаривается с транспортной средой о форме трафика. Если пользователь обеспечивает договоренную форму трафика, то транспортная среда обеспечивает ему доставку трафика с определенной скоростью. Для таких приложений, как передача видео- и аудиоданных в реальном времени, это очень важно. Здесь уместно вспомнить организацию работы СПД Frame Relay. 
Когда пользователь и транспортная среда договариваются о форме трафика, то они приходят к соглашению не только о форме трафика, но также и о том, что произойдет, если эта форма будет нарушена пользователем. Это соглашение называется соглашением о трафике. Использование техники формирования трафика и соглашения о трафике легче всего реализовать при использовании виртуальных соединений, чем в случае дейтаграмм. В случае дейтаграмм эти идеи могут быть применены к соединениям на транспортном уровне. 
  
   

  

  
   

  

5.3.3.1. Алгоритм текущего ведра 
Идея этого алгоритма показана на рисунке 5-23 (а). Ведро может наполняться с любой скоростью, но вытекать из него вода будет со строго определенной скоростью. Если вода будет поступать слишком быстро, то ее часть будет переливаться через края и пропадать. Скорость истечения воды из ведра зависит только от размера отверстия в днище. 
Рисунок 5-23. Алгоритм текущего ведра 
 
Этот прием можно применить и к пакетам, как показано на рисунке 5-23 (b). Каждая станция, подключенная к сети, имеет подобие текущего ведра в своем интерфейсе. Не важно, сколько процессов посылает пакеты в сеть. Если буфер переполнен, то пакеты будут сбрасываться в соответствии с соглашением о трафике. Это не что иное, как сервер с постоянной скоростью обслуживания. 
В качестве регулятора скорости поступления пакетов можно использовать системные часы. В этом случае устанавливается предел числа пакетов, которые процесс может направить в сеть за один промежуток времени. Этот прием дает хорошие результаты, когда пакеты имеют фиксированную длину, как в АТМ. В случае пакетов переменной длины это соглашение ограничивает количество байтов, направляемых в сеть. Например, если разрешается за один промежуток послать 2048 байт, то это может быть два пакета по 1024 или 4 пакета по 512 байт. Если же пакет больше чем 2048, например, 2560 байт, то он должен ждать следующего временного промежутка. 
Рисунок 5-24. Алгоритм текущего ведра со счетчиком байтов 
 
На рисунке 5-24 дан пример использования алгоритма текущего ведра со счетчиком байтов. Если имеется буфер С на 1 Мбит и скорость истечения равна 2 Мбит/сек., то при всплеске в 1 Мбит в течение 40 мсек. мы легко справимся с таким трафиком. При этих условиях даже не важно, с какой скоростью будут поступать этот 1 Мбит, главное чтобы этот всплеск не растянулся более чем на 500 мсек. На рисунке 5-24 (c) - (f) показана работа алгоритма текущего ведра при разных скоростях входного потока. 
  
   

  

  
   

  

5.3.3.2. Алгоритм ведра с маркерами 
Алгоритм текущего ведра позволяет сгладить трафик, убрать нерегулярность. Однако в целом ряде приложений бывает полезно разрешить, при всплеске трафика и наличии необходимых ресурсов, ускорить на некоторое время передачу пакетов в сеть. Один из алгоритмов, позволяющих это сделать, - алгоритм ведра с маркерами. Рисунок 5-25 иллюстрирует этот алгоритм. Идея его заключается в том, что вместе с пакетами в ведро поступают маркеры. Пакеты из ведра уходят в сеть только при наличии соответствующего количества маркеров. Таким образом, можно накапливать маркеры и кратковременно ускорять передачу пакетов в сеть. 
Рисунок 5-25. Алгоритм ведра с маркерами 
 
Другое отличие алгоритма ведра с маркером - при переполнении буфера хосту будет временно запрещено передавать пакеты. Здесь опять существуют разные варианты в зависимости от длины пакетов, правила работы со счетчиком маркеров и т.д. Для реализации алгоритма ведра с маркерами нужна лишь переменная, значение которой увеличивается каждые ?Т сек. и уменьшается с каждым посланным пакетом. В случае пакетов переменной длины значение этой переменной увеличивается на k байтов каждые ?Т сек. и уменьшается на длину каждого посланного пакета. Нетрудно рассчитать длительность всплеска при передаче на основе уравнения 
C + ? S = MS 
где С – объем буфера, S – длительность всплеска, ? – скорость поступления маркера, М – максимальная скорость «вытекания» данных. 
Таким образом, S = C/(M - ?). 
Рисунок 5-24 (d-f) иллюстрирует эту функцию для случая С = 250 Кбит, М = 25 Мбит/сек. и ? = 2 Мбит/сек. 
  
   

  

  
   

  

5.3.4. Спецификация потока 
Формирование трафика эффективно тогда, когда отправитель, получатель и среда передачи заранее договорились о форме трафика. Это соглашение называется спецификацией потока. Она представляет собой структуру данных, которая определяет как форму выходного трафика, так и качество сервиса, необходимого приложению. Эта спецификация применима как к пакетам, передаваемым по виртуальным каналам, так и к дейтаграммам. 
В таблице 5-26 показан пример спецификации потока. Левый столбец определяет характеристики выходного потока. Правый определяет то, что приложение ожидает от СПД-среды. 
Таблица 5-26. Пример спецификации потока 
Характеристики выходного потока 
Желаемый сервис 
Максимальный размер пакета (байт) 
Чувствительность к потерям (байт) 
Пропускная способность ведра с маркерами (байт/сек.) 
Интервал между потерями (мксек.) 
Размер ведра с маркерами (байт) 
Чувствительность к потерям пакетов (пакеты) 
Максимальная скорость передачи (байт/сек.) 
Минимальная задержка (мксек.) 

Максимальное различие в задержке (мксек.) 

Качество гарантии 
  
   

  

  
   

  

5.3.5. Управление перегрузками в сетях с виртуальными каналами 
До сих пор мы рассматривали методы управления перегрузками, основанные на открытом контуре. Это значит, что данные методы скорее стараются предотвратить появление перегрузок, чем, обнаружив перегрузку, принять меры к ее устранению. Здесь мы рассмотрим только один метод устранения уже возникшей перегрузки в сетях с виртуальными каналами - динамический контроль доступа. В последующих двух разделах мы рассмотрим приемы для управления перегрузками, применимые в любых СПД-средах. 
Прием, который широко используется, чтобы сдержать уже возникшую перегрузку и не дать положению ухудшиться - это контроль на входе. Идея очень проста - если обнаружена перегрузка, то все, что способствует увеличению трафика, запрещено. Прежде всего, запрещается создание новых виртуальных соединений. Таким образом, запрещается создание новых соединений на транспортном уровне. Этот метод хотя и грубоват, но прост в реализации и хорошо апробирован в телефонных сетях. 
Другой подход разрешает установку новых виртуальных соединений, но только при наличии не перегруженных маршрутов, т.е. таких маршрутов, которые не пересекаются с перегруженными участками, даже если такие маршруты далеко не оптимальны. Рисунок 5-27 иллюстрирует этот подход. 
Рисунок 5-27. (а) Участок сети с перегрузкой; (b) Измененный участок сети без перегрузки с виртуальным каналом АВ 
 
Третий подход уже упоминался: хост и транспортная среда договариваются перед установкой виртуального соединения о форме трафика, объеме передаваемых данных, качестве сервиса и т.п. После этого транспортная среда резервирует необходимое количество ресурсов, необходимых ей для выполнения этих соглашений. Это резервирование может происходить постоянно, а может быть сделано только при возникновении перегрузок. Плата за резервирование - неоптимальное использование пропускной способности каналов. 
  
   

  

  
   

  

5.3.6. Подавляющие пакеты 
Теперь рассмотрим приемы, используемые как в средах с виртуальными каналами, так и в средах с дейтаграммами. Каждый маршрутизатор может контролировать степень загрузки своих выходных линий и другие ресурсы. Например, он может периодически вычислять степень загруженности своих выходных линий. Всякий раз, когда степень загруженности при очередном вычислении оказывается выше некоторого порога, эта линия переводится в состояние предупреждения. Каждый пакет, маршрутизируемый через такую линию, вызывает генерацию подавляющего пакета, направляемого отправителю маршрутизируемого пакета. При этом в пакете отправителя проставляется определенный разряд, предотвращающий генерацию подавляющих пакетов другими маршрутизаторами в дальнейшем. 
Когда отправитель получает подавляющий пакет, он сокращает интенсивность своего трафика на определенную величину. Поскольку пакеты, направляемые одному и тому же получателю, могут маршрутизироваться по-разному, то отправитель вправе ожидать несколько подавляющих пакетов. В течение определенного времени отправитель будет игнорировать подавляющие пакеты, поступающие с направления получателя. По истечении этого периода времени отправитель ожидает появления подавляющих пакетов в течение следующего интервала. Если появился хоть один подавляющий пакет, то линия перегружена и отправитель ждет. Если в течение очередного интервала не поступило ни одного подавляющего пакета, то отправитель может увеличить интенсивность трафика. 
Существует много вариантов этого алгоритма. Так, например, можно использовать не только загруженность линии, но и длину очереди, заполненность буфера и параметры спецификации трафика. 
У методов на основе подавляющих пакетов есть один недостаток. Если есть несколько отправителей, работающих через одну и ту же выходную линию, то при определенных условиях маршрутизатор всем им пошлет подавляющие пакеты. Однако, так как отправители независимы, то один, например, сократит трафик значительно, тогда как другие лишь незначительно. Это приведет к несправедливому использованию пропускной способности канала между ними. 
Для предотвращения такой ситуации был предложен алгоритм справедливого чередования. Суть его состоит в том, что для каждого отправителя у выходной линии строится своя очередь. Отправка пакетов из этих очередей происходит по кругу. Поэтому, если кто-то из отправителей незначительно сократит трафик, то это лишь увеличит скорость роста его очереди. 
И у этого алгоритма есть недостаток: если один отправитель использует длинные пакеты, а другой - короткие, то последний получит меньшую долю пропускной способности линии. Для борьбы с этой несправедливостью в алгоритм обслуживания очередей вносят модификацию: пакеты из очередей передаются побайтно, а не весь пакет сразу. Этот подход иллюстрирует рисунок 5-28. 
Рисунок 5-28. (а) Маршрутизатор с очередью из пяти пакетов для линии О; (b) Время передачи для каждого пакета 
 
Другие модификации алгоритма чередования связаны с установкой приоритетов между очередями, что дает большую гибкость в обслуживании отправителей. Так, если есть очереди для сервера и для клиента, то естественно обслуживать очередь сервера быстрее. 
Представленные здесь алгоритмы с подавляющими пакетами плохо работают в высокоскоростных сетях и на больших расстояниях. Дело в том, что пока подавляющий пакет дойдет до отправителя, пройдет много времени и отправитель успеет «напихать» в сеть много пакетов. Для исправления этой ситуации была предложена его модификация – алгоритм с подавлением по скачкам. Суть его в том, что как только обнаружится перегрузка на выходной линии и маршрутизатор отправит подавляющий пакет, то ближайший маршрутизатор, получивший этот подавляющий пакет, сократит трафик к маршрутизатору, пославшему подавляющий пакет. И так скачок за скачком трафик будет быстро падать. Естественно, этот прием увеличит нагрузку на буфера маршрутизаторов, сокращающих трафик, но обеспечит быструю реакцию на возникающую перегрузку. На рисунке 5-29 дан пример алгоритма с подавлением скачками. На этом рисунке хорошо видно, что, применяя технику подавляющих пакетов «в лоб», мы достигнем сокращения нагрузки за 7 скачков (а). Техника подавляющих пакетов по скачкам позволяет добиться того же самого эффекта за пять скачков (b). 
Рисунок 5-29. Алгоритм с подавлением скачками 
 
  
   

  

  
   

  

5.3.7. Сброс нагрузки 
Когда ни один из упомянутых выше приемов не срабатывает, маршрутизатор может применить «тяжелую артиллерию» – сброс нагрузки. Было бы слишком примитивно предполагать, что маршрутизатор, при возникновении перегрузки просто начинает сбрасывать пакеты. Идея метода и его название пришли из области передачи электроэнергии. Там при возникновении перегрузок в сети, начинают отключать отдельные группы потребителей, чтобы сохранить работоспособность системы. 
Маршрутизатор может сбрасывать пакеты, исходя из информации о приложении, пославшем эти пакеты. Если, например, передается файл, то старые пакеты, т.е. расположенные ближе к концу файла, сбрасывать лучше, поскольку приложение может потребовать перепослать все пакеты, начиная с пропущенного пакета. В этом случае, чем старее пакет, тем меньше придется перепосылать. Есть приложения, для которых все наоборот. Лучше сбрасывать новые пакеты, т.е. ближе к началу передачи, чем старые. 
В общем случае подход на основе сброса нагрузки предполагает определенное взаимодействие между приложением и маршрутизатором. Например, при передаче изображений в целях компрессии сначала посылают всю картинку, а потом лишь ее изменения. Ясно, что потеря одного из изменений лишь ухудшит изображение на некоторое время, в то время, как потеря картинки будет означать потерю изображения вовсе. Для обеспечения такого взаимодействия с приложением вводят приоритеты среди пакетов. Это позволяет маршрутизатору минимизировать потери для приложения, когда маршрутизатор вынужден сбрасывать пакеты. 
Для того, чтобы приложение не злоупотребляло приоритетными пакетами, можно увязать приоритет пакетов с величиной оплаты за трафик. Чем больше приоритетных пакетов, тем выше стоимость передачи. Приоритеты можно использовать также в целях формирования трафика. Например, при использовании алгоритма ведра с маркерами, если пакет пришел, а маркеров нет, можно применить прием, когда пакет все же будет передан, но низким приоритетом. 
Приоритеты используются, например, в протоколах Frame Relay. Пока величина трафика находится в заранее оговоренных пределах, все пакеты идут с определенным приоритетом. При пиковых нагрузках, превосходящих номинальную величину, приоритеты пакетов начинают падать в зависимости от времени. Если увеличение размера трафика продолжается недопустимо долго, то вскоре приоритеты пакетов достигнут минимума, и при первых же признаках перегрузки их начнут сбрасывать. 
  
   

  

  
   

  

5.3.8. Управление перегрузками при групповой передаче 
Все алгоритмы управления перегрузками, которые мы до сих пор рассматривали, относились к случаю, когда был один источник и один получатель. В этом разделе мы рассмотрим случай управления нагрузкой при групповой передаче, т.е. когда есть несколько источников и несколько получателей. Примером могут служить системы кабельного телевидения. Например, в системе может быть несколько источников телепередач (станций вещания), и зрители могут по желанию переключаться с одной станции на другую. Аналогичная ситуация может иметь место в системе видеоконференций, когда слушатели могут переключаться с одной конференции на другую. 
Во многих подобных приложениях группы могут возникать и изменяться по составу динамически. В этих условиях прием, когда источник сообщений резервирует заранее необходимые для передачи ресурсы, не работает эффективно. Источнику сообщений придется при каждом изменении группы генерировать дерево связей. В случае кабельного телевидения, когда группы содержат миллионы зрителей, такой подход не годится. 
Одно из возможных решений для подобных случаев было предложено в 1993 году – это RSVP-протокол (Resource reSerVation Protocol – протокол резервирования ресурсов). Он позволяет нескольким отправителям передавать сообщения группам получателей, отдельным получателям переходить из группы в группу, оптимизировать использование пропускной способности каналов, избегая перегрузок. 
В простейшей форме этот протокол для групповой маршрутизации использует дерево связей так, как мы уже рассматривали ранее. Каждой группе приписана группа адресов.  При отправке пакета отправитель помещает в него весь список адресов группы. После этого стандартный алгоритм групповой маршрутизации строит дерево связей, покрывающее все адреса группы. Собственно маршрутизация не является частью RSVP. 
Чтобы понять действие алгоритма RSVP, рассмотрим пример. На рисунке 5-30 (а) показана сеть. Пусть 1 и 2 – групповые отправители, а 3, 4 и 5 – групповые получатели. То, что множество отправителей и получателей не пересекаются, сделано для простоты. Дерево связей для групповой рассылке от 1 дано на рисунке 5-30 (b), а от 2 – на рисунке 5-30 (c). 
Рисунок 5-30. Групповая передача 
 
Чтобы избежать перегрузок, любой получатель в группе шлет надлежащему отправителю резервирующее сообщение. Это сообщение с помощью алгоритма пересылки вдоль обратного пути, рассмотренного в разделе 5.2.9, движется к отправителю и вызывает резервирование необходимой пропускной способности на каждом узле, через который оно проходит. Если при прохождении очередного узла ему не удается зарезервировать необходимую пропускную способность, то получателю направляется отказ в установлении соединения. 
Рисунок 5-31. Управление перегрузками при групповой передаче 
 
На рисунке 5-31 (а) показан путь резервирования между получателем 3 и отправителем 1. Как только канал между ними установлен, получатель 3 может получать поток пакетов от 1. Рассмотрим теперь, что произойдет, если получатель 3 захочет также получать данные от отправителя 2. Для этого резервирующее сообщение проложит второй путь, показанный на рисунке 5-31 (b). Предположим теперь, что получатель 5 также захотел подключиться к отправителю 2 (рисунок 5-31 (с)). Он запустит резервирующее сообщение, которое свободно пройдет до узла Н, а там будет обнаружено, что ранее уже были зарезервированы ресурсы для доставки трафика от узла 2 до узла Н. Здесь возможны нюансы. Например, если требования к качеству сервиса у 5 и 3 разное, то резервироваться ресурсы будут по максимуму. Кроме этого, при резервировании получатель может указывать не только несколько источников, от которых он хотел бы получать информацию, но также то, является ли создаваемый канал временным (вплоть до того, на какое время он создается), или он должен долго оставаться открытым. Маршрутизаторы могут использовать эту информацию для оптимизации планирования ресурсов, в особенности при разделении каких-либо ресурсов между несколькими получателями. Благодаря такой стратегии этот протокол может поддерживать динамику внутри групп. 
  
   

  

  
   

  

5.4. Межсетевое взаимодействие 
До сих пор мы предполагали, что соединения возникают в рамках однородной среды передачи. Теперь мы перейдем к рассмотрению случаев, когда соединение возникает между СПД-средами с разной архитектурой. 
Существование разных сетей - явление временное, или оно отражает некоторые объективные тенденции? Хотя Unix работает с TCP/IP, тем не менее, существует SNA от IBM, NCP/IPX от Novel, AppleTalk и т.д. 
Безусловно, будут появляться новые технологии, стандарты, устройства и программное обеспечение, их реализующее. Все эти инновации надо будет как-то связывать с существующими сетями. 
Рисунок 5-32. Межсетевое взаимодействие 
 
На рисунке 5-32 показаны различные сценарии соединений между сетями. 
1.LAN-LAN: научный сотрудник передает файл в рамках локальной сети кампуса. 
2.LAN-WAN: научный сотрудник посылает письмо коллеге. 
3.WAN-WAN: два гуманитария обмениваются мнениями. 
4.LAN-WAN-LAN: научные сотрудники разных университетов общаются между собой. 
Название средства, соединяющего сети между собой, зависит от того, на каком уровне это происходит. 
1.Уровень 1: репитер копирует биты из одного кабельного сегмента в другой. 
2.Уровень 2: мост передает пакеты канального уровня из одной ЛВС в другую. 
3.Уровень 3: мультипротокольный маршрутизатор передает пакеты между сетями с разной архитектурой. 
4.Уровень 4: транспортный шлюз соединяет байтовые потоки на транспортном уровне. 
5.Над уровнем 4: прикладной шлюз соединяет приложения в разных сетях. 
Напомним, что термин «шлюз» мы используем для обозначения устройства, соединяющего сети с разной архитектурой. 
Репитер - устройство, обеспечивающее усиление и очистку сигнала. На МАС-уровне трансивер обеспечивает передачу сигнала в пределах 500 метров. Репитер обеспечивает передачу на 2,5 км. 
Мост способен хранить и маршрутизировать пакеты на канальном уровне. Он получает канальный пакет целиком и решает, по какой линии его передать дальше. 
Мультипротокольные маршрутизаторы функционально примерно то же самое, что и мосты, но работают на сетевом уровне. Они получают пакеты сетевого уровня и определяют, куда их передать. Однако при этом разные каналы могут принадлежать разным сетям, использующим разные протокольные стеки. Поэтому мультипротокольному маршрутизатору, кроме задачи маршрутизации, приходится решать и задачу сопряжения форматов пакетов на сетевом уровне в сетях с разной архитектурой. 
На рисунке 5-33 показаны разные схемы включения шлюза. 
Рисунок 5-33. Схемы включения шлюза: (а) Полный шлюз между двумя WAN; (b) Полный шлюз между LAN и WAN; (c) Два полушлюза 
 
  
   

  

  
   

  

5.4.1. Чем различаются сети 
В таблице 5-34 перечислены основные различия, которые могут встречаться на сетевом уровне. Эти различия усложняют межсетевое взаимодействие. 
Таблица 5-34. Различия сетей на сетевом уровне 
Признак 
Возможные значения 
Предоставляемый сервис 
Ориентированные vs. неориентированные на соединение 
Протоколы 
IP, IPX, CLNP, AppleTalk, DECnet и т.д. 
Адресация 
Прямая (802) vs. иерархическая 
Групповое вещание 
Есть/нет (также транслирование) 
Размер пакетов 
У каждой сети свой максимальный размер 
Качество сервиса 
Есть/нет; много различных видов 
Действия в случае ошибок 
Надежная, упорядоченная или неупорядоченная доставка 
Управление потоком 
«Скользящее окно», регулирование скорости, другие способы или неуправляемый поток 
Управление перегрузками 
Протокол «текущего ведра», подавляющие пакеты и т.д. 
Безопасность 
Правила защиты информации, шифрование и т.д. 
Параметры 
Разные значения тайм-аута, характеристики потока и т.д. 
Оплата 
За время соединения, за количество пакетов, побайтно или без оплаты 
Когда пакет, отправленный из одной сети, должен пройти несколько разных сетей, прежде чем достичь нужную сеть, приходится решать множество проблем, возникающих на интерфейсах между сетями. Например, если пакеты были отправлены по виртуальному соединению, а одна из транзитных сетей не поддерживает такие соединения, то порядок следования пакетов может быть нарушен, к чему ни отправитель, ни получатель могут быть не готовы. Также может потребоваться согласование функциональности протоколов на одноименных уровнях. Если функциональность одного протокола не может быть выражена в терминах функциональности другого, то такое согласование может оказаться невозможным. Проблемы могут возникнуть с адресацией при переходе из одной сети в другую, групповой рассылкой и т.д. 
Много проблем доставляет различие в максимальной длине пакетов, используемой в разных сетях. Другим источником трудностей является различие в качестве услуг в разных сетях. Например, когда надо передать пакет из сети, поддерживающей ограничение на время передачи пакета, через сеть, где нет никаких гарантий на максимальную величину задержки пакета при передаче. 
В разных сетях по-разному решаются вопросы управления перегрузками и потоками, обнаружения и исправления ошибок, что также может служить источником проблем. 
  
   

  

  
   

  

5.4.2. Сопряжение виртуальных каналов 
Есть два общих приема для межсетевого взаимодействия: сопряжение, ориентированное на соединения подсетей с виртуальными каналами, и взаимодействие подсетей через дейтаграммы. На рисунке 5-35 показана модель сопряжения виртуальных каналов. Абонентская машина одной сети устанавливает виртуальное соединение не только внутри своей сети, но и в другой сети, вплоть до получателя. Внутри своей сети соединение прокладывается по правилам этой сети вплоть до мультипротокольного маршрутизатора, ближайшего к сети получателя. Затем от этого маршрутизатора до получателя - по правилам сети получателя. (Рассмотреть прохождение пакетов вдоль соединения.) 
Рисунок 5-35. Межсетевое взаимодействие с использованием сопряжения виртуальных каналов 
 
На рисунке показано решение с использованием полного шлюза. Однако такое же решение возможно и с полушлюзом. Это решение хорошо работает для сетей с примерно одинаковыми характеристиками. 
Достоинства сопряжения виртуальных каналов: буферы можно резервировать заранее, порядок пакетов сохраняется, проще управлять повторной передачей из-за задержки, короткие заголовки пакетов. 
Недостатки сопряжения виртуальных каналов: хранение таблицы сопряжения, сложности в изменении маршрута при перегрузках, требование высокой надежности маршрутизаторов вдоль сопряжения. 
  
   

  

  
   

  

5.4.3. Межсетевое взаимодействие без соединений 
На рисунке 5-36 показано решение на основе соединения сетей на уровне дейтаграмм. При этом подходе единственный сервис, который сетевой уровень предоставляет транспортному – «впрыскивание» дейтаграмм в транспортную среду. Дальше приходиться надеяться на удачу. Такое сопряжение сетей возможно, если соединяемые транспортные среды используют одни и те же или очень близкие сетевые протоколы. Вспомним проблемы мостов между подуровнями 802.х. 
Рисунок 5-36. Межсетевое взаимодействие без соединений 
 
Проблемы возникают с адресацией. Различия в адресации могут быть столь велики, что сопряжение станет невозможным. Например, в ТСР/IP используется 32-разрядный адрес, а в OSI - десятичный номер, подобный телефонному. Выход - распространять каждую адресацию на все машины в мире. Однако, очевидно, что такой подход не работает. 
Другой выход - создать универсальный пакет, который понимали бы разные сети, - тоже не работает. Всех уговорить признать один формат как универсальный невозможно. 
Основное достоинство дейтаграммного подхода - он может использоваться между сетями, которые не поддерживают виртуальных соединений. Число таких сетей весьма велико. 
  
   

  

  
   

  

5.4.4. Туннелирование 
В общем случае проблема межсетевого соединения весьма сложна. Однако есть достаточно распространенный случай, для которого есть решение. Это соединение двух одинаковых сетей через третью. Например, так, как показано на рисунке 5-37. Решение проблемы межсетевого соединения в этом случае дает применение техники туннелирования. Рисунок 5-38 разъясняет прием туннелирования на примере автомобиля. Суть этого приема состоит в том, что пакет из одной сети упаковывается в кадр промежуточной сети. Затем он передается через промежуточную сеть на канальном уровне. При достижении кадром сети назначения кадр распаковывается, пакет передается на сетевой уровень и движется дальше. 
Рисунок 5-37. Транспортировка пакета методом туннелирования 
 
Рисунок 5-38. Транспортировка автомобиля через туннель под Ла-Маншем 
 
  
   

  

  
   

  

5.4.5. Межсетевая маршрутизация 
Маршрутизация на межсетевом уровне происходит примерно так же, как на сетевом, но с некоторыми дополнительными сложностями. Рассмотрим пример на рисунке 5-39. На этом рисунке шесть мультипротокольных маршрутизаторов соединяют пять сетей. 
Рисунок 5-39. Пример межсетевой маршрутизации 
 
Имея граф соединений этих маршрутизаторов между собой, можно применять уже известные нам алгоритмы маршрутизации: по вектору расстояния или по состоянию канала. Так мы приходим к двум уровням маршрутизации: внутреннему межшлюзовому протоколу и внешнему межшлюзовому протоколу. Поскольку каждая сеть в определенном смысле автономна, то для нее часто используют термин - автономная система. 
Главная сложность, отличающая внутрисетевую маршрутизацию от межсетевой - государственные границы. Здесь возникают различия в законах разных стран, различия в оплате трафика, принятые на территориях разных стран, и т.д. 
  
   

  

  
   

  

5.4.6. Фрагментация 
В каждой сети есть свой максимальный размер пакетов. Это ограничение имеет несколько причин: 
1.Аппаратура (например, максимальный TDM-слот) 
2.Операционная система (все буфера по 512 байтов) 
3.Протоколы (например, размер поля длины пакета) 
4.Совместимость с некоторыми национальными и международными стандартами 
5.Стремление сократить ошибку, вызываемую повторной передачей 
6.Желание предотвратить длительный захват канала одним пакетом 
Максимальный размер пакета колеблется от 48 байтов в АТМ-сети до 65515 байтов в IP-сети (у протоколов более высоких уровней он еще больше). 
Очевидно, первая же проблема возникает при попытке передать большой пакет через сеть, у которой максимальный размер пакета меньше. Одно из решений - проложить маршрут для таких пакетов так, чтобы избежать подобной ситуации. Однако что делать, в такой сети расположен получатель? 
Единственное решение - разрешить шлюзу разбивать пакет на фрагменты и отправлять каждый фрагмент независимо. В этом случае возникает проблема сборки фрагментов. 
Есть два подхода к тому, как это осуществлять. Первый - делать фрагменты столь малыми, что любая сеть на их пути будет прозрачна для них. Это решение показано на рисунке 5-40 (а). Когда поступает большой пакет, его разбивают на малые и все пакеты отправляют на один и тот же выходной шлюз, где они собираются снова в большой пакет. 
Рисунок 5-40. Фрагментация пакетов 
 
В такой фрагментации есть трудности: как узнать, что все фрагменты достигли выходного шлюза, как выбирать маршрут для фрагментов, накладные расходы на разбиение и сборку пакета из фрагментов. 
Другой подход - разбив пакет на фрагменты, рассматривать каждый из них как обычный пакет. Это решение показано на рисунке 5-40 (b). Сборка фрагментов происходит только в узле назначения. Однако при таком подходе каждый хост должен уметь собирать пакеты из фрагментов. 
На рисунке 5-41 показана фрагментация в случае, если размер элементарного фрагмента данных равен 1 байту. 
Рисунок 5-41. Фрагментация: (а) Исходный пакет, содержащий 10 байтов данных; (b) Фрагменты после прохождения сети с максимальным размером пакета, равным 8 байтам; (с) Фрагменты после прохождения через шлюз с размером 5 

  
   

  

5.4.7. Firewall 
Способность любого компьютера соединяться, где бы он ни был, с любым другим компьютером - благо для пользователя, но сущее наказание для службы безопасности любой организации. Здесь, кроме угрозы потери информации, есть угроза притока всякой гадости типа вирусов, червей и прочих цифровых паразитов. Позднее мы о них поговорим подробнее. Надо заметить, что, согласно результатам исследований, 50% опасности таится вне сети, а 50% - внутри, среди сотрудников. 
Итак, нужен механизм, который бы различал «чистые» биты от «нечистых». Один способ - шифровать данные. Так поступают при передаче данных. Со способами шифрования мы познакомимся позднее. Но шифрование бессильно против вирусов, хакеров и прочей нечисти. Одним из средств борьбы с ними служат брандмауеры (firewall). 
Барьер - современная форма крепостного рва. Компания может иметь сколь угодно сложную сеть, объединяющую много локальных сетей. Однако весь трафик в сеть и из этой сети направляется только через один шлюз, где происходит проверка пакета на соответствие определенным требованиям. Если пакет не удовлетворяет этим требованиям, то он не допускается в сеть или из нее. На рисунке 5-42 показана организация брандмауера. 
Рисунок 5-42. Устройство брандмауера 
 
Барьер состоит из двух маршрутизаторов, фильтрующих пакеты, и шлюза приложений. Фильтры содержат таблицы сайтов, от которых можно принимать и которым можно передавать пакеты. Шлюз приложений ориентирован на конкретные приложения. Пример -  шлюз для электронной почты. Этот шлюз анализирует поле данных и принимает решение, сбросить пакет или нет. Набор таких шлюзов полностью зависит от политики информационной безопасности конкретной организации. Чаще всего это шлюз электронной почты и WWW. 
  
   

  

  
   

  

5.5. Сетевой уровень в Интернете 
Интернет представляет собой объединение подсетей, которые называются автономными системами. Автономные системы – это подсеть, охватывающая единую территорию, находящаяся под единым административным управлением и имеющая единую политику маршрутизации по отношению ко всем остальным сетям. В Интернете нет какой-либо регулярной, специально предусмотренной структуры подсетей. Он образован из соединения большого числа подсетей, среди которых можно выделить несколько остовых (backbone). К этим остовым сетям подключены региональные сети, к которым подключены локальные сети организаций. На рисунке 5-43 показана схема соединения таких остовых сетей. 
Рисунок 5-43. Интернет как сеть множества сетей 
 
Соединяет все автономные системы вместе IP-протокол. В отличие от других протоколов сетевого уровня, этот протокол с самого начала создавался для объединения сетей. Его целью было наилучшим образом передавать дейтаграммы от одной машины к другой, где бы эти машины ни находились. 
Как мы уже отмечали, подсеть в Интернете реализует сервис без соединений и работает следующим образом. Транспортный уровень получает поток данных и делит их на дейтаграммы. Дейтаграммы могут быть от 64К до 1500 байт. Они передаются через подсети в Интернет и, если необходимо, делятся на более короткие. Когда все дейтаграммы достигают места назначения, они собираются в исходные дейтаграммы на сетевом уровне и передаются на транспортный уровень, где и восстанавливается исходный поток данных. 
  
   

  

  
   

  

5.5.1. IP-протокол 
На рисунке 5-44 показан заголовок IP-пакета (дейтаграммы). Он имеет обязательную часть размером 20 байт и может быть расширен до 60. Дейтаграмму передают, начиная с поля Version. 
Рисунок 5-44. Заголовок IP 
 
Version - указывает версию протокола. 
IHL - длина заголовка в 32-разрядных словах (минимум 5, максимум 15, что соответствует 60 байтам). 
Type of service - вид необходимого сервиса. Здесь возможны различные комбинации скорости и надежности: например, передача голоса, аккуратная доставка строки битов, файла и т.п. 
Identification - позволяет отличать фрагменты одной и той же дейтаграммы. 
DF – признак управления фрагментацией. Если он равен 1, то фрагментация невозможна. 
Total length - указывает общую длину дейтаграммы, включая заголовок и поле данных. Максимальная длина 65535 байт. 
Identification – указывает, какой дейтаграмме принадлежит очередной поступивший фрагмент. Все фрагменты одной дейтаграммы имеют в этом поле одно и то же значение. 
MF – содержит единицу только у последнего фрагмента дейтаграммы. Это поле позволяет отличить последний фрагмент от всех остальных. 
Fragment offset – указывает, где в дейтаграмме располагается данный фрагмент. Длина всех фрагментов, кроме последнего, должна быть кратна 8 байтам. Поскольку поле имеет 13 разрядов, то на одну дейтаграмму максимально может быть 8192 фрагментов. 
Time to live – время жизни пакета. Максимальное значение этого поля - 255, измеряется в секундах. Очень часто здесь используется счетчик скачков. 
Protocol - показывает, какому процессу на транспортном уровне передать собранную дейтаграмму (TCP, UDP и т.д.). 
Header checksum - контрольная сумма, которая охватывает только заголовок. 
Source address, Destination address – идентифицируют машину отправителя и получателя в сети. 
Options - предусмотрено для расширения возможностей протокола. Оно делится, в свою очередь, на следующие поля: 
Security – указывает уровень секретности передаваемой информации. Маршрутизатор может на основании значения этого поля запретить определенные маршруты, например, если они пролегают через ненадежные регионы. 
Strict source routing – здесь указан полный маршрут в виде списка IP-адресов. Это поле используется в алгоритме маршрутизации от источника, а также в критических ситуациях, например, когда таблица маршрутизации по какой-то причине оказалась испорченной. 
Loose source routing – список маршрутизаторов, через которые фрагмент обязан пройти. Он может пройти и через другие маршрутизаторы, но данные обязательно должны принадлежать его маршруту. 
Record route – указывает маршрутизаторам на необходимость заносить в поле свои адреса. Это позволяет проследить, как шел фрагмент. 
Time stamp – вместе с предыдущим полем указывает маршрутизаторам на необходимость записывать не только свои адреса, но и время, когда фрагмент проходил через них. Это поле очень полезно при отладке алгоритмов маршрутизации. 
  
   

  
 
  
   

  

  
   

  

5.5.2. IP-адресация 
Каждая машина в Интернете имеет уникальный IP-адрес. Он состоит из адреса сети и адреса машины в этой сети. Все IP-адреса имеют длину 32 разряда. На рисунке 5-45 показаны форматы IP-адресов. Если машина подключена к нескольким сетям, то в каждой сети у нее будет свой IP-адрес. 
Рисунок 5-45. Форматы IP-адресов 
 
Все адреса разделяются на классы. Всего есть пять классов адресов: А, B, C, D, E. Классы A позволяет адресовать до 126 сетей по 16 миллионов машин в каждой, B - 16382 сетей по 64К машин, C - 2 миллиона сетей по 256 машин, D - предназначены для групповой передачи, Е - зарезервированы для развития. Адреса выделяет только организация NIC - Network Information Center. Несколько адресов, показанных на рисунке 5-46, имеют специальное назначение. Адрес из одних нулей используется при загрузке машины. 
Рисунок 5-46. Специальные IP-адреса 
 
  
   

  

  
   

  

5.5.3. Подсети 
Все машины одной сети должны иметь одинаковый номер сети в своем адресе. Это приводит к целому ряду проблем. По мере роста сети приходиться менять класс адреса. Появление новых адресов приводит к проблеме модификации таблиц маршрутизации и распространению информации о новых адресах повсюду. Перенос машины из одной сети в другую требует изменения маршрутизации. Эти изменения происходят не сразу, и пока они не будут выполнены, все сообщения пойдут по старому адресу. 
Решением этих проблем является разделение сети на части, которые извне видны как единое целое, но внутри каждая часть имеет свой адрес. Эти части называются подсети. Мы уже отмечали в главе 1, что термин подсеть в Интернете имеет особый смысл. Итак, подсеть - это часть сети, невидимая извне. Изменение адреса подсети или введение новой подсети не требует обращения в NIC или изменений какой-либо глобальной базы данных. На рисунке 5-47 показано разбиение сети класса В на подсети. 
Рисунок 5-47. Разбиение подсети класса В 
 
Чтобы понять, как используется адрес подсети, надо проследить, как маршрутизатор использует IP-адрес. Есть две таблицы: некоторое количество IP-адресов вида «сеть, 0» и некоторое количество IP-адресов вида «эта_сеть, адрес машины». Первая показывает, как достичь интересующей сети. Вторая - как достичь узла внутри сети. Когда поступает IP-пакет, маршрутизатор ищет его адрес доставки в таблице маршрутизации. Если этот адрес – адрес другой сети, то пакет передают дальше тому маршрутизатору, который отвечает за связь с этой сетью. Если это адрес в локальной сети, то маршрутизатор направляет пакет прямо по месту назначения. Если адреса нет в таблице, то маршрутизатор направляет пакет специально выделенному по умолчанию маршрутизатору, который должен разобраться с этим случаем с помощью более подробной таблицы. Из этого описания видно, что алгоритм маршрутизации имеет дело только с сетями или локальными машинами, а не с парами «сеть, узел». Такая организация алгоритма позволяет существенно сократить размер таблиц в маршрутизаторах. 
С появлением подсети структура адресов меняется. Теперь записи в таблице имеют форму «эта_сеть, подсеть, 0» и «эта_сеть, эта_подсеть, машина». Таким образом, маршрутизатор подсети в данной локальной сети знает, как достичь любой подсети в данной локальной сети и как найти конкретную машину в своей подсети. Все что ему нужно – это знать маску подсети. С помощью логической операции «&» маршрутизатор выделяет адрес подсети с помощью маски, показанной на рисунке 5-47. По своим таблицам он определяет, как достичь нужной подсети или (если это локальная подсеть данного маршрутизатора) как достичь конкретной машины. 
  
   

  

  
   

  

5.5.4. Протоколы управления межсетевым взаимодействием 
В Интернете, кроме IP-протокола, который используется для передачи данных, есть несколько протоколов управления, используемых на сетевом уровне, таких как ICMP, ARP, RARP, BOOTP, которые мы рассмотрим последовательно. 
  
   

  

  
   

  

5.5.4.1. Internet Control Message Protocol 
Управление функционированием Интернета происходит через маршрутизаторы с помощью протокола ICMP (RFC 792). Этот протокол обеспечивает доставку сообщений любой машине, имеющей IP-адрес (хосту), от маршрутизаторов и других хостов в сети. Этот протокол обеспечивает обратную связь при возникновении проблем при передаче. Он выявляет и рассылает сообщения о десятках событий, наиболее важные из них показаны в таблице 5-48. 
Таблица 5-48. Основные типы сообщений ICMP 
Тип сообщений 
Описание 
Destination unreachable (Назначение недостижимо) 
Пакет не может быть доставлен 
Time exceeded (Время истекло) 
Время жизни достигло "0" 
Parameter problem (Проблемы с параметрами) 
Недопустимое поле заголовка 
Source quench (Источник отключен) 
Подавляющий пакет 
Redirect (Перенаправление) 
Объясните маршрутизатору, где он находится 
Echo request (Запрос отклика) 
Спросите машину, работает ли она 
Echo reply (Ответ на запрос) 
Да, машина работает. 
Timestamp request (Запрос с временной меткой) 
То же, что Echo request, только с временной меткой 
Timestamp reply (Ответ с временной меткой) 
То же, что Echo reply, только с временной меткой 
Протокол ICMP использует протокол IP и доставка его дейтаграмм не более надежна, чем любой IP-дейтаграммы в сети. Сообщение destination unreachable покрывает множество случаев: от случая, когда маршрутизатор не знает, как достигнуть нужной подсети или хоста, до случая, когда дейтаграмма при доставке должна быть фрагментирована, но установлен флаг, который запрещает это делать. 
Сообщение time exceeded посылает маршрутизатор, если он обнаружил дейтаграмму с истекшим времени жизни. Хост генерирует такое сообщение, если он не успел завершить сборку дейтаграммы до истечения времени ее жизни. 
Синтаксические или семантические ошибки в заголовке IP-дейтаграммы вызывают появление сообщения parameter problem. 
Сообщение source quench обеспечивает средство управления потоком. Маршрутизатор или хост-получатель высылает этот пакет хосту-отправителю, если необходимо понизить скорость передачи. Сообщения этого типа будут генерироваться до тех пор, пока скорость поступления дейтаграмм от отправителя не достигнет нужной хосту-получателю величины. Это сообщение система может использовать для предотвращения перегрузки. Оно возникает всякий раз, когда маршрутизатор вынужден сбросить дейтаграмму из-за переполнения своего буфера. 
Сообщение redirect позволяет маршрутизатору отправить рекомендацию о лучшем маршруте и впредь посылать дейтаграммы с определенным адресом через другой маршрутизатор. 
Сообщения echo request и echo reply обеспечивают механизм проверки работоспособности объектов в сети. Получатель сообщения echo request обязан ответить сообщением echo reply, причем с теми же параметрами, что и в echo request. 
Сообщения timestamp request и timestamp reply обеспечивают механизм для измерения и изменения параметров временной задержки в Интернете. Этот механизм необходим, например, для работы алгоритма маршрутизации по состоянию канала. 
  
   

  

  
   

  

5.5.4.2. Address Resolution Protocol – протокол определения адреса 
Хотя каждая машина в Интернете имеет уникальный IP адрес, и даже не один, но при передаче пакета через сеть от этого мало пользы, так как канальный уровень не понимает IP адресов. Как правило, машина подключена к ЛВС через сетевую карту, которая понимает только ЛВС адреса канального уровня, например, Ethernet-адрес. Этот адрес имеет 48 разрядов. Сетевая карта знает только такие адреса и ничего об 32-разрядных IP. 
Как отобразить 32-разрядный IP-адрес в адреса канального уровня, например, Ethernet-адрес? Для объяснения воспользуемся рисунком 5-49. 
Рисунок 5-49. Три объединенных сети класса С: две Ethernet-сети и кольцо FDDI 
 
Когда машина 1 посылает сообщение машине 2, то через DNS (Domain Name Service – службу имен домена – это приложение мы будем рассматривать в главе 7) определяется IP-адрес места назначения. Далее, для отображения IP-адреса в Ethernet-адрес, в подсеть посылается запрос, у кого такой IP-адрес. Машина с указанным адресом шлет ответ. Протокол, который реализует рассылку запросов и сбор ответов - ARP-протокол. Практически каждая машина в Интернете использует этот протокол. 
Теперь рассмотрим случай, когда обращение идет в другую сеть. Здесь два решения - есть определенный маршрутизатор, который принимает все сообщения, адресованные определенной сети или группе адресов - proxy ARP. Этот маршрутизатор знает, как найти адресуемую машину. Другое решение - выделенный маршрутизатор, который управляет маршрутизацией удаленного трафика. Машина определяет, что обращение идет в удаленную сеть, и шлет сообщение на этот маршрутизатор. 
  
   

  

  
   

  

5.5.4.3. Reverse Address Resolution Protocol (RARP) – обратный протокол определения адреса 
Иногда возникает обратная проблема - известен Ethernet-адрес, но какой IP-адрес ему соответствует? Эта проблема возникает, например, при удаленной загрузке бездисковой станции. Как эта станция определит свой и соседние IP-адреса? 
Станция посылает запрос к RARP-серверу: "Мой Ethernet-адрес такой то, кто знает соответствующий IP-адрес?" RARP-сервер отлавливает такие запросы и шлет ответ. 
У этого протокола есть один существенный недостаток – пакеты с одним и тем же запросом рассылаются всем, что увеличивает накладные расходы. Для устранения этого недостатка был предложен протокол BOOTP. В отличие от RARP, BOOTP использует UDP-сообщения, которые рассылаются только маршрутизаторам. Этот протокол также используется в бездисковых станциях, у которых в памяти прошит IP-адрес выделенного маршрутизатора. 
  
   

  

  
   

  

5.5.5. OSPF - внутренний протокол маршрутизации шлюзов 
Интернет состоит из сетей, управляемых разными организациями. Каждая такая сеть использует внутри свои алгоритмы маршрутизации и управления и называется автономной системой. Наличие стандартов позволяет преодолеть различия во внутренней организации автономных систем и обеспечить их совместное функционирование. Алгоритмы маршрутизации, применяемые внутри АС, называются внутренними протоколами шлюзов. Алгоритмы маршрутизации, применяемые для маршрутизации между АС, называются внешними протоколами шлюзов. 
Изначально в качестве внутреннего протокола шлюзов использовался протокол по вектору расстояния (RIP). Этот протокол работал хорошо, пока автономная система была небольшой. Однако по мере роста АС он начинал работать все хуже и хуже. Проблемы «счетчика до бесконечности» и медленная сходимость не получили удовлетворительного решения. В 1979 году он был замещен протоколом маршрутизации по состоянию каналов. В 1988 году инженерный комитет Internet принял решение о разработке нового алгоритма маршрутизации. Этот алгоритм, названный OSPF - Open Shortest Path First, стал стандартом в 1990 году (RFC 1247). 
  
   

  

  
   

  

5.5.5.1. Требования к протоколу 
На основе имеющегося опыта был составлен длинный список требований к протоколу. Прежде всего, алгоритм должен быть опубликован в открытой литературе (отсюда «open»). Во-вторых, он не должен быть собственностью какой-либо компании. В-третьих, он должен уметь работать с разными метриками: расстоянием, пропускной способностью, задержкой и т.п. Он должен быть динамическим, т.е. реагировать на изменении в топологии сети автоматически и быстро. 
В-четвертых, он должен поддерживать разные виды сервиса, поддерживать маршрутизацию для трафика в реальном времени одним способом, а для других типов трафика - другим. В IP-пакете есть поле Type of service, которое не использовалось существующими в то время протоколами. 
В-пятых, он должен обеспечивать балансировку нагрузки и при необходимости разделять потоки по разным каналам. Все предыдущие протоколы использовали только один канал - наилучший. 
В-шестых, он должен поддерживать иерархию. К 1988 году Интернет стал столь большим, что ни один маршрутизатор был уже не в состоянии хранить всю топологию. Поэтому новый протокол должен быть сконструирован так, чтобы по нему мог бы работать не один маршрутизатор. 
В-седьмых, должна быть усилена безопасность маршрутизаторов для защиты от студентов, которые развлекались тем, что подсовывали маршрутизаторам неверную информацию о маршрутах. Наконец, надо было позаботиться о том, чтобы позволить маршрутизаторам общаться с помощью туннелирования. 
  
   

  

  
   

  

5.5.5.2. Виды соединений и сетей в OSPF 
OSPF поддерживает три вида соединений и сетей: 
1.Точка-точка между двумя маршрутизаторами 
2.Сети с множественным доступом и вещанием (большинство ЛВС) 
3.Сети с множественным доступом без вещания (например, региональные сети с коммутацией пакетов) 
На рисунке 5-50 (a) показаны все три вида сетей. Отметим, что хосты не играют никакой роли в OSPF. OSPF абстрагируется от конкретных сетей, маршрутизаторов и хостов в форме ориентированного графа, каждая дуга в котором имеет вес, представляющий собой задержку, расстояние и т.п. В этом графе находится кратчайший путь на основе весов дуг. Последовательный канал между узлами представляют две дуги, которые могут иметь разный вес. Сеть с множественным доступом представляет узел, соединенный с маршрутизаторами этой сети дугами с весом 0, часто опускаемыми на рисунках. На рисунке 5-50 (b) показан такой граф. 
Рисунок 5-50. Три вида сетей в OSPF и их представление в виде графа 
 
Многие АС сами по себе представляют большие сети. OSPF позволяет разбивать их на области, где каждая область - это либо сеть, либо последовательность сетей. Области не пересекаются. Есть маршрутизаторы, которые не принадлежат никакой области. Область - обобщение понятия подсети. Вне области ее топология не видна. 
Каждая АС имеет остовую область, называемую «областью 0». Все области АС соединяются с остовой, возможно через туннелирование. Поэтому можно из одной области попасть в другую через остовую область. Туннель представлен в графе дугой с весом. Любой маршрутизатор, соединенный с двумя или более областями, - часть остовой области. Как и в других областях, топология остовой области не видна извне. 
Внутри области у каждого маршрутизатора одинаковая база данных состояний каналов и одинаковый алгоритм наикратчайшего пути. Задача маршрутизатора - вычислить наикратчайший путь до другого маршрутизатора этой области, включая маршрутизатор, соединенный с остовой областью. Маршрутизатор, соединенный с двумя областями, должен иметь две базы данных и выполнять два алгоритма наикратчайшего пути независимо. 
Чтобы поддерживать разные типы сервисов, OSPF использует несколько графов, один с разметкой относительно задержки, другой - относительно пропускной способности, третий - относительно надежности. Хотя все три требуют соответствующих вычислений, но зато мы получаем три маршрута, оптимизированных по задержке, пропускной способности и надежности. 
Во время функционирования возникают три вида маршрутов: внутри области, между областями и между АС. Внутри области вычислить маршрут просто - им будет наикратчайший до маршрутизатора получателя. Маршрутизация между областями всегда выполняется в три этапа: от источника до остовой области, от остовой до области назначения, внутри области назначения. Этот алгоритм навязывает звездообразную топологию OSPF: остовая область – центр, ось, остальные области – лучи, спицы. Пакеты маршрутизируются без изменений, как есть, за исключением случая, когда область получателя соединена с остовой областью туннелем. Рисунок 5-51 показывает эти три вида маршрутов. 
Рисунок 5-51. Связи внутри области, между областями и между разными АС 
 
  
   

  

  
   

  

5.5.5.3. Маршрутизаторы в OSPF 
OSPF различает четыре класса маршрутизаторов: 
1.Внутренний, целиком внутри одной области 
2.Пограничный, соединяющий несколько областей 
3.Остовый, принадлежащий остовой области 
4.Пограничный, соединенный с маршрутизаторами других АС 
Эти классы могут пересекаться. Например, все пограничные маршрутизаторы – остовые; маршрутизатор из остовой области, но не на ее границе - внутренний. Примеры этих классов маршрутизаторов показаны на рисунке 5–51. 
Когда маршрутизатор загружается, он рассылает сообщение «Hello» всем своим соседям - на линиях «точка-точка», группам маршрутизаторов в ЛВС с множественным доступом, чтобы получить информацию о своем окружении. 
В OSPF маршрутизаторы обмениваются данными не со своими соседями, а со смежными маршрутизаторами. Это не одно и то же. Маршрутизатор не общается со всеми маршрутизаторами, например, внутри ЛВС, а лишь с тем, который объявлен выделенным маршрутизатором. Этот выделенный маршрутизатор смежен всем другим. У выделенного маршрутизатора есть дублер, который имеет ту же информацию, что и основной. 
Периодически в ходе нормальной работы каждый маршрутизатор рассылает всем своим смежным маршрутизаторам сообщение LINK STATE UPDATE. В этом сообщении он передает информацию о состоянии своих линий и их стоимости в разных метриках для базы данных топологии соединений. Это сообщение в целях надежности идет с подтверждением. Каждое такое сообщение имеет номер, который позволяет определить, несет ли пришедшее сообщение новую информацию по сравнению с той, что есть в его базе, или старую. Маршрутизаторы рассылают эти сообщения, когда у них появляются новые линии, разрушаются старые или меняется стоимость линии. 
DATABASE DESCRIPTION – сообщение, содержащее состояние всех каналов в базе данных отправителя. Сравнивая свои значения с теми, что у отправителя, получатель может определить, у кого наиболее свежая информация. 
Используя сообщение LINK STATE REQUEST, маршрутизатор может в любой момент запросить информацию о любой линии у другого маршрутизатора. Наиболее свежая информация распространяется другим. Все сообщения передаются как IP-пакеты. Все типы сообщений показаны в таблице 5-52. 
Таблица 5-52. Типы OSPF-сообщений 
Тип сообщений 
Описание 
Hello (Приветствую) 
Используется, чтобы получить информацию о соседях. 
Link state update (Обновление состояния канала) 
Предоставляет соседям стоимости отправителя. 
Link state ack (Подтверждение состояния канала) 
Подтверждает обновление состояния канала. 
Database description (Описание базы данных) 
Объявляет, какие обновления есть у отправителя. 
Link state request (Запрос о состоянии канала) 
Запрашивает информацию у партнера. 
Маршрутизаторы в остовой области делают все, что было описано выше, а также обмениваются информацией с пограничными маршрутизаторами, чтобы уметь вычислять наилучший маршрут от любого маршрутизатора остовой области до любого другого маршрутизатора. 
  
   

  

  
   

  

5.5.6. BGP - внешний протокол маршрутизации шлюзов 
Для маршрутизации между АС используется BGP - протокол пограничных шлюзов. Его предшественником был протокол EGP. Однако с ростом Интернета протокол EGP перестал удовлетворять требованиям к протоколу внешней маршрутизации. Основное отличие BGP от OSPF проистекает из различия в целях. При маршрутизации внутри АС основная цель - наикратчайший маршрут. При маршрутизации между АС надо учитывать также ряд условий, вызванных политикой конкретной АС. 
Например, какая-то АС может не допускать маршрутизацию через себя ни для какой другой АС (у них нет другого кратчайшего пути - это ваши проблемы); может разрешать лишь определенным. Типичными примерами таких ограничений могут быть: 
1.Трафик не должен проходить через определенные АС. 
2.Маршрут, начинающийся в министерстве обороны России, никогда не должен проходить через Чечню. 
3.Трафик через Украину может проходить, только если нет другого маршрута. 
4.Трафик из IBM никогда не должен проходить через АС Microsoft. 
Такие правила вручную вводятся в каждый BGP-маршрутизатор. С точки зрения BGP-маршрутизатора весь мир состоит из BGP-маршрутизаторов, соединенных между собой. Два BGP-маршрутизатора соединены, если у них есть общая сеть. Сети делятся на три категории по степени интереса направления трафика через сеть. Первая - тупиковые сети, они никуда не ведут. У них только одна точка соединения в BGP-графом. Они не могут использоваться для транзита. Сети с множественными соединениями могут использоваться для транзита, если допускают его. Транзитные сети предназначены для транзита трафика, возможно с некоторыми ограничениями. 
Два BGP-маршрутизатора взаимодействуют через TCP-соединение. Это обеспечивает надежность передачи информации и скрывает все подробности от сетей, через которые она проходит. 
BGP - это протокол на основе вектора расстояний. Однако вместо стоимости для каждого места в сети он хранит конкретный маршрут. Своим соседям он передает не вектор расстояний, а те маршруты, которые он использует. На рисунке 5-53 показан пример. 
Рисунок 5-53. (а) Сеть из BGP-маршрутизаторов; (b) Информация, получаемая F 
 
BGP-протокол легко решает проблему «счета до бесконечности». Предположим, что маршрутизатор G или линия FG отказали. Тогда F получит от своих соседей три оставшихся маршрута до D. Поскольку маршруты IFGCD и EFGCD проходят через F, то он их отбросит и воспользуется FBCD. 
Определение BGP-протокола дано в RFC 1654 и RFC 1268. 
  
   

  

  
   

  

5.5.7. Групповая адресация в Интернете 
Обычно в IP-сетях один отправитель взаимодействует с одним получателем. Однако в ряде приложений бывает полезным одно и то же сообщение передать сразу нескольким получателям. Примеры: поддержка обновления данных в реплицируемых базах данных, передача биржевой информации сразу нескольким брокерам, поддержка телеконференций. 
В IP-сетях групповая адресация поддерживается с помощью адресов класса D, в нем 28 разрядов для адресации группы, т.е. можно адресовать 250 миллионов групп. При передаче сообщения группе делается все возможное, чтобы каждый член группы получил сообщение, однако это не гарантируется. 
Поддерживается два типа групповых адресов: постоянные и временные. Примеры постоянных групповых адресов: 
224.0.0.1 - все системы в данной ЛВС. 
224.0.0.2 - все маршрутизаторы в данной ЛВС. 
224.0.0.5 - все OSPF-маршрутизаторы в данной ЛВС. 
224.0.0.6 - все выделенные OSPF-маршрутизаторы в данной ЛВС. 
Временные группы должны создаваться специальным образом и специальным образом удаляться. Каждый процесс на машине может запросить аппаратуру присоединиться к определенной группе или покинуть ее. Когда последний процесс на машине покинет группу, то эта группа более не представлена на этом хосте. Каждый хост следит, какие группы на нем представлены. 
Групповая адресация реализуется специальным групповым маршрутизатором, который может размещаться отдельно от обычного маршрутизатора. Раз в минуту каждый групповой маршрутизатор рассылает через канальный уровень запрос всем хостам ЛВС указать, каким группам принадлежат их процессы. Эти запросы и ответы на них регулируются IGMP-протоколом (Internet Group Management Protocol), который очень похож на ICMP. Он описан в RFC 1112. 
  
   

  

  
   

  

5.5.9. CIDR - бесклассовая маршрутизация внутри домена 
Популярность Интернета обернулась против него. Не стало хватать адресов. В 1987 году считалось, что 100 000 сетей - это очень много и что это число будет достигнуто не скоро. Оно было превзойдено в 1996 году. Проблема в том, что адреса выделяются классами. Многие организации не используют всего диапазона адресов, выделенного им класса. 
Класс В, наиболее часто используемый, слишком велик для многих организаций. На основе имеющегося опыта видно, что было бы неплохо, если бы класс С имел не 256 машин, а 1024. 
Другая проблема - взрывообразный рост таблиц маршрутизации. Маршрутизатор не должен знать о каждой машине в сети, но должен знать о каждой сети. На сегодня выделено полмиллиона адресов класса С, следовательно, в таблице маршрутизации должно быть не менее полумиллиона элементов, каждый из которых показывает, как достичь той или иной сети. 
Кроме этого, многие из алгоритмов маршрутизации требуют, чтобы маршрутизаторы периодически обменивались своими таблицами. Чем больше эти таблицы, тем больше шансов, что при передаче они будут повреждены и переданы не верно. 
Выход - увеличение иерархии интернет-адресов. Указывать страну, область, город, район, машину. Однако 32 бит не хватит. Кроме того, Лихтенштейн, например, будет иметь столько же адресов, сколько и США. 
Таким образом, каждое решение несет свои проблемы. В настоящее время широко распространяется решение на основе протокола CIDR, описанного в RFC 1519. Его идея основана на том, что на сегодня не использовано более 2 миллионов сетей класса С, поэтому по запросу организации можно выделять несколько последовательных сетей класса С, так чтобы покрыть требуемое число машин. Например, если организация заявляет 2000 машин, можно выделить ей 8 последовательных сетей класса С, что даст 2048 машин. 
В соответствии с этим были изменены правила определения места для адресов класса С. Мир был поделен на четыре зоны, и каждой зоне выделена часть адресов класса С. 
1.194.0.0.0 - 195.255.255.255 - Европа 
2.198.0.0.0 - 199.255.255.255 - Северная Америка 
3.200.0.0.0 - 201.255.255.255 - Центральная и Южная Америка 
4.202.0.0.0 - 203.255.255.255 - Азия и Тихий Океан 
Таким образом, каждый регион получил 32 миллиона адресов для раздачи, а 320 миллионов адресов класса С с 204.0.0.0. по 223.255.255.255 зарезервированы на будущее. Это существенно упростило работу с таблицами маршрутизации. Например, любой маршрутизатор, получив адрес в диапазоне 194.0.0.0 по 195.255.255.255 знает, что его надо переслать одному из европейских маршрутизаторов. 
  
   

  

  
   

  

5.5.10. IPv6 
Появление новой версии протокола IP (IPv6, в настоящее время используется IPv4) обусловлено целым рядом причин. Одна из основных - стремительный рост всемирной сети Интернет. Фундаментальным принципом построения сетей на основе протокола IP, необходимым для правильной маршрутизации и доставки пакетов, является уникальность сетевых адресов, т.е. каждый IP-адрес может принадлежать только одному устройству. На сегодняшний день остались невыделенными около 1 400 000 000 адресов из возможных 4 294 967 296, то есть примерно 30%, чего должно хватить на несколько лет, а может быть и более. Дефицит адресов пока выражается в основном в том, что, по выражению одного из сетевых гуру, адрес класса A не смог бы получить и сам Господь Бог. Таких адресов может существовать всего 128 (формат: 0, адрес сети - 7 бит, адрес хоста - 24 бита), но каждый из них содержит 16 777 216 адресов. Однако появившиеся в последнее время новые устройства для доступа в Интернет и развитие цифрового телевидения, которое собирается превратить каждый телевизор в интернет-устройство, могут быстро исчерпать имеющиеся запасы неиспользованных адресов. 
Если в компьютерных сетях для выхода в Интернет могут применяться технологии типа NAT (Network Address Translation, — преобразование сетевого адреса), при которой для взаимодействия с окружающей средой используется всего несколько уникальных адресов, предоставляемых, возможно, провайдером, а внутри локальной сети адресация может быть достаточно произвольной, то для сетевого телевизора этот способ не подходит, так как каждому устройству требуется свой уникальный адрес. 
Рисунок 5-54. Заголовок пакета IPv6 
 
Кроме всего прочего, новые возможности предъявляют к протоколам сетевого уровня, каковым является IP, совершенно новые требования в части легкости получения и смены адресов, полностью автоматического конфигурирования (представьте себе домохозяйку, настраивающую DNS своего телевизора). Если новый протокол не появится своевременно, то фирмы-провайдеры начнут внедрять свои собственные, что может привести к невозможности гарантированного соединения «всех со всеми». Открытый протокол, удовлетворяющий требованиям необходимого адресного пространства, легкости конфигурирования и маршрутизации, способный работать совместно с имеющимся IPv4, поможет сохранить способность к соединению между собой любых устройств, поддерживающих IP, при наличии новых возможностей, которые основаны на анализе использования IPv4. 
Кроме того, остается еще одна проблема: уникальность адреса вовсе не означает, что устройство будет правильно функционировать. Адреса нужны в первую очередь не для того, чтобы «всех пересчитать», а для правильной маршрутизации при доставке пакетов. Таким образом, для беспрепятственного роста Интернета необходимо не только наличие свободных адресов, но и определенная методика их выделения, позволяющая решить проблему масштабируемости. Сведение к минимуму накладных расходов на маршрутизацию является сегодня одной из основных проблем, и ее важность будет возрастать в дальнейшем по мере роста Сети. Просто присвоить устройству адрес недостаточно, необходимо еще обеспечить условия для правильной маршрутизации с минимальными накладными расходами. 
Рисунок 5-55. Заголовок пакета IPv4 (для сравнения) 
 
В настоящее время только одна известная технология, а именно, иерархическая маршрутизация, позволяет за счет приемлемых технических издержек обеспечить доставку пакетов в сети размерами с Интернет. Технология иерархической маршрутизации заключается в разбиении всей сети на более мелкие подсети, маршрутизация в которых производится самостоятельно. Подсети, в свою очередь, могут разбиваться на еще более мелкие, и т.д. В результате образуется древовидная структура, причем в качестве узлов выступают маршрутизаторы, а в качестве листьев - оконечные устройства-хосты. Путь, который проделывает пакет, передаваемый от одного листа до другого, может быть длиннее, чем при иной топологии, но зато он всегда может быть рассчитан с наименьшими издержками. Некоторую аналогию можно провести с телефонными номерами — первым идет код страны, за ним код города, а затем собственно номер, состоящий, в свою очередь, из кода АТС и собственно номера абонента. 
История нового протокола восходит к концу 1992 года. Именно тогда IETF (Internet Engineering Task Force — рабочая группа по технической поддержке Интернет) приступила к анализу данных, необходимых для разработки нового протокола IP. К концу 1994 года был утвержден рекомендательный стандарт и разработаны все необходимые для реализации протокола вспомогательные стандарты и документы. 
IPv6 является новой версией старого протокола, разработанной таким образом, чтобы обеспечить совместимость и «мягкий» переход, не приуроченный к конкретной дате и не требующий одновременных действий всех участников. По некоторым прогнозам, совместное существование двух протоколов будет продолжаться до десяти и более лет. Учитывая то обстоятельство, что среди выделенных типов адресов IPv6 имеется специальный тип адреса, эмулирующий адрес IPv4, можно ожидать относительно спокойного перехода, не сопровождающегося крупными неудобствами и неприятностями. Фактически на одном компьютере могут работать оба протокола, каждый из которых подключается по мере необходимости. 
Рисунок 5-56. Provider-Based Unicast Address - адресация единственного абонента, основанная на адресе провайдера 
 
Однако использование старых адресов не является выходом из положения, поэтому протокол IPv6 предусматривает специальные возможности по присвоению новых адресов и их замене без вмешательства (или при минимальном вмешательстве) персонала. Для этого предусмотрена привязка к компьютеру не IP-адреса, а интерфейса. Сам же интерфейс может иметь несколько адресов, принадлежащих к трем категориям: действительный, прошлый, недействительный. При замене адреса «на лету» новый адрес становится действительным, а старый — прошлым. Все вновь осуществляемые соединения производятся при помощи действительного адреса, но уже имеющиеся продолжаются по прошлому адресу. Через некоторое время, которое может быть выбрано достаточно большим, чтобы гарантировать полный разрыв всех соединений по прошлому адресу, он переходит в категорию недействительных. Таким образом, практически гарантируется автоматическая замена адреса без участия персонала. Для полностью гарантированной автоматической замены адреса потребовалось бы внесение изменений в протоколы TCP и UDP, которые не входят в состав IP. 
Замена адресов осуществляется двумя способами — явным и неявным. Явный способ использует соответствующим образом доработанный протокол DHCP. Неявный способ не требует наличия сервера DHCP, а использует адрес подсети, получаемый от соседей и мостов. В качестве адреса хоста используется просто MAC-адрес хоста, т.е. адрес, используемый на канальном уровне. Этот способ, при всем своем изяществе, по понятным причинам не может присваивать адреса, совместимые с IPv4, и поэтому в переходный период его применение будет ограничено. К сожалению, механизм выделения новых адресов не затрагивает таких аспектов, как обновление базы данных DNS, адресов серверов DNS, конфигурации маршрутизаторов и фильтров, а также тех приложений «клиент-сервер», которые используют привязку к адресу, что делает полную замену адресов локальной сети не менее трудоемким мероприятием, чем при применении IPv4. 
Рисунок 5-57. Локальные адреса для использования в пределах сегмента (вверху) и локальной сети (внизу) 
 
Протокол IPv6 предполагает также значительные улучшения при работе в локальной сети. Единый протокол NDP (Neighbor Discovery Protocol - протокол распознавания соседей) заменяет используемые в IPv4 протоколы ARP, ICMP и значительно расширяет их функциональные возможности. Вместо широковещательных пакетов канального уровня протокола ARP используются групповые сообщения (multicast), то есть адресованные всем членам подсети, причем не на канальном, а на сетевом уровне, что должно значительно снизить широковещательный трафик, являющийся бичом локальных сетей Ethernet. Усовершенствованы функции протокола ICMP, что облегчает работу разных подсетей в одном физическом сегменте. Включен механизм распознавания неисправных маршрутизаторов, что позволяет повысить устойчивость к сбоям оборудования. В дополнение к имевшимся ранее двум типам адресации - Unicast и Multicast (доставке уникальному получателю или группе получателей) - добавлен третий, Anycast, при котором осуществляется доставка любому получателю из группы. 
Существенное отличие нового протокола от старого заключается в том, что длина адресной части составляет 128 бит — в четыре раза больше, чем 32 бита у IPv4. Чтобы представить эту величину, достаточно сказать, что на каждом квадратном метре поверхности суши и моря можно разместить примерно 6,7х1023 адресов. Из заголовка пакета IP изъяты как некоторые неиспользуемые поля, что позволило сократить издержки, связанные с их обработкой, и уменьшить размер заголовка (он длиннее, чем у IPv4, всего в два раза, несмотря на учетверенный размер адресной части). 
Рисунок 5-58. Адреса, построенные на основе IPv4: (а) Совместимый; (b) Для устройств, не поддерживающих IPv6 
 

На рисунке 5-59 показана структура заголовка пакета в формате Ipv6. 
Рисунок 5-59. Заголовок пакета IPv6 

 
Первым идет четырехбитное поле Version (Версия), его значение равно 6. Следующее поле - Priority (Приоритет) - длиной 8 бит используется для установки приоритета пакета. Приоритет увеличивается с ростом значения этого поля. Значения 0...7 используются для пакетов, время доставки которых не лимитировано, например, значение 1 рекомендуется использовать для новостей, 2 — для почты, 7 — для служебного трафика (SNMP, маршрутизирующие протоколы). Значения 8...15 используются для пакетов, задержка доставки которых нежелательна, например аудио и видео в реальном времени. Далее следует поле Traffic Class, первоначально называвшееся «Flow Label», длиной 20 бит. Оно служит для идентификации последовательности пакетов. Его значение присваивается при помощи генератора случайных чисел и имеет одинаковую величину у всех пакетов данной последовательности. Следующее поле - Payload Length - содержит размер данных, следующих за заголовком, в байтах и имеет длину 16 бит. Следом расположено поле Next Header, идентичное по назначению полю Protocol протокола IPv4 и использующее те же значения. Восьмибитное поле Hop Limit аналогично по назначению полю Time to Live. Оно устанавливается источником согласно разумным предположениям о длине маршрута, а затем уменьшается на 1 при каждом прохождении через маршрутизатор. При снижении значения поля до нуля пакет снимается, как «заблудившийся». Последними идут поля адресов источника и приемника длиной 128 бит (16 байт) каждое. Адреса в стандарте IPv6 имеют более сложную структуру, чем в предыдущем, при этом используются префиксы разной длины (они показаны в таблице 1). 
Таблица 1. 
Назначение        Префикс 
Зарезервировано     0000 0000 
Зарезервировано для адресов NSAP  0000 001 
Зарезервировано для адресов IPX  0000 010 
Provider-Based Unicast Address    010 
Зарезервировано для     100 
Neutral-Interconnect-Based Unicast Addresses 
Link Local Use Addresses    1111 1110 10 
Site Local Use Addresses    1111 1110 11 
Multicast Addresses     1111 1111 
В настоящее время для непосредственного использования предназначено около 15% адресов, остальные 85% зарезервированы для распределения в будущем. 
Специальные типы адресов предназначаются для более гибкого использования. Provider-Based Unicast Address (Выделяемый провайдером уникальный адрес) служит для глобальной связи. Он состоит из префикса 010, Registry Id, идентифицирующего организацию, зарегистрировавшую провайдера; Provider Id, идентифицирующего провайдера; Subscriber Id, идентифицирующего организацию-клиента, и собственно адреса. Адреса для локального использования (Link Local Use и Site Local Use) предназначены для применения внутри одного сегмента или одной организации, т.е. пакеты с такими адресами не маршрутизируются за границы текущего сегмента или локальной сети соответственно. Они могут быть использованы, например, при автоматическом присвоении адресов. Для выхода в глобальную сеть может быть использована подстановка адресов по типу NAT. Если под заполнители-нули выделено достаточно места, то организация, ранее не имевшая соединения с Интернетом, может легко провести замену адресов на глобальные путем конкатенации REGISTRY. 
Рисунок 5-60. Адресация группы абонентов (Multicast Address) 
 

ID + PROVIDER ID + SUBSCRIBER ID и локального адреса. К специальным типам адресов также относятся адреса, совместимые с IPv4. Первый тип относится к «совместимым» адресам, которые предназначены для туннелирования пакетов IPv6 через существующую инфраструктуру IPv4. Второй тип адресов отображает на IPv6 подмножество адресов IPv4 для тех устройств, которые не поддерживают новый протокол. 
Широковещательный адрес благодаря использованию полей Flags и Scope может также использоваться более гибко. В четырехбитном поле Flags пока используется только младший бит для указания, является ли данный адрес постоянным и выделенным соответствующими организациями, ответственными за выдачу адресов, или используется единовременно. Поле Scope используется для ограничения области распространения широковещательных пакетов. Значения этого поля приведены в таблице 2. 
Таблица 2. 
Значение Scope Область распространения пакета 
0      Зарезервировано 
1      Внутри узла 
2      Внутри сегмента 
5      Внутри локальной сети 
8      Внутри организации 
0Eh      Глобальная 
0Fh      Зарезервировано 
При рассмотрении возможностей, предоставляемых новым протоколом, может возникнуть вопрос, а зачем он все-таки нужен? Большинство функций либо уже имеются в IPv4, либо могут быть реализованы путем доработки соответствующих протоколов. Так, автоматическое выделение адресов производится при помощи протокола DHCP, адресный барьер преодолевается при помощи протокола NAT и т.д. и т.п. Однако разработка всех необходимых заплаток для протокола IPv4 потребовала бы не меньших (а то и больших) усилий, чем создание нового протокола «с чистого листа». Разумеется, лист был не совсем чистым, поскольку вопросы совместимости и совместной работы обоих протоколов имелись в виду с самого начала проектирования. В конце концов, Интернет все равно пришел бы к кризису дефицита адресов, так что заблаговременная разработка и постепенное внедрение протокола IPv6 были более чем уместны. 
Для реализации перехода на новый протокол образовалась неформальная некоммерческая организация «6bone», включающая в себя более 100 организаций, в основном, сетевых провайдеров и университетов. Главная задача организации - создание инфраструктуры, позволяющей транспортировать пакеты стандарта IPv6 по всей сети Интернет. Как и существующая сегодня инфраструктура IPv4, она будет состоять из большого количества провайдеров и локальных сетей, объединенных в единую Сеть. В настоящее время в состав 6bone входят представители 41 страны, от США, Англии и Японии до Камеруна и Казахстана. 
Необходимость создания такой инфраструктуры объясняется прежде всего тем, что без широкомасштабного тестирования и готовой инфраструктуры (или ее подобия) коммерческие провайдеры (и потребители, занимающиеся, в отличие от университетов, не исследованиями, а бизнесом) вряд ли будут охотно внедрять новый протокол. Таким образом, задачей сети 6bone не является организация параллельной инфраструктуры, а, скорее, тестирование и отработка методик взаимодействия «клиент-провайдер». 
Сама сеть 6bone состоит из островков-сетей, которые полностью поддерживают IPv6, соединенных виртуальными туннелями. Эти сети работают на установленном у провайдеров оборудовании, которое используется и в коммерческих целях. Согласно существующему в настоящее время мнению, организация 6bone будет существовать до тех пор, пока будет актуальна ее основная цель - популяризация протокола IPv6. 
Заключение 
Итак, сетевой уровень обеспечивает услуги для транспортного уровня. Он может использовать как виртуальные соединения, так и дейтаграммы. В любом случае основной его задачей является маршрутизация сообщений от отправителя до получателя. В случае виртуальных соединений маршрут прокладывается, когда устанавливается соединение, и все пакеты соединения следуют одним маршрутом. В случае дейтаграмм каждый пакет маршрутизируется самостоятельно. 
В сетях используются разнообразные алгоритмы маршрутизации: статические алгоритмы, такие как наикратчайшего пути, лавинообразный, на основе потока. Динамические алгоритмы, такие как по вектору расстояния, по состоянию канала. Важными вопросами маршрутизации являются: 
Иерархическая маршрутизация 
Маршрутизация мобильного узла 
Маршрутизация при вещании 
Групповая маршрутизация 
Транспортная подсеть может оказаться перегруженной. Поэтому при ее создании особое внимание уделяется решениям, которые позволяют снизить вероятность перегрузки. Для этого используются методы формирования трафика, спецификации потока, резервирования пропускной способности. Если перегрузка все же возникла, применяются методы подавляющих пакетов, сброса нагрузки и другие. 
Организации транспортных подсетей могут существенно отличаться друг от друга. Поэтому когда их соединяют между собой, возникают дополнительные проблемы. Если сеть-отправитель и сеть-получатель одного типа, то можно использовать метод туннелирования пакетов. Если же они разные, то этот прием не подходит. Можно попробовать фрагментацию.