Адрес канального уровня уникальным образом идентифицирует каждое физическое соединение сетевого устройства с сетью. Адреса канального уровня иногда называются физическими или аппаратными адресами. Обычно они образуют неиерархическое адресное пространство, задаются для каждого устройства заранее и, как правило, жестко. Оконечные системы имеют обычно только одно физическое сетевое соединение и, стало быть, только один адрес канального уровня. Маршрутизаторы и другие устройства, поддерживающие межсетевой обмен, обычно имеют несколько физических сетевых соединений и несколько адресов канального уровня.
Адреса подуровня управления доступом к среде передачи (MAC) являют-I ся подмножеством адресов канального уровня. Адреса MAC идентифицируют сетевые устройства в LAN, реализующие подуровень IEEE MAC канального уровня. Как большинство адресов канального уровня, адреса MAC являются уникальными для каждого интерфейса LAN. Адреса MAC имеют 48 битов в длину и выражаются с помощью 12 шестнадцатеричных цифр: первые шесть шестнадцатеричных цифр являются идентификацией производителя (или кодом поставщика), называемым уникальным идентификатором организации (OUI). Эти шесть цифр устанавливаются IEEE. Последние шесть шестнадцатеричных цифр являются серийным номером интерфейса или другим значением, администрируемым определенным поставщиком. Адреса MAC иногда называются аппаратными или "зашитыми" адресами (Burned-in Address, BIA), так как они выжжены в постоянной памяти (ROM) и копируются в оперативную память (RAM), когда инициализируется плата интерфейса.
Адресация на сетевом уровне
Адрес сетевого уровня идентифицирует устройство сетевого уровня эталонной модели OSI. Сетевые адреса существуют обычно в иерархическом адресном пространстве. Иногда их называют виртуальными или логическими адресами. Отношение сетевого адреса с устройством является логическим и нефиксированным. Обычно адрес основывается либо на характеристиках физической сети (устройство находится в определенном сетевом сегменте), или на логическом объединении, которое не имеет физической основы (устройство является частью зоны AppleTalk). Оконечным системам требуется один адрес сетевого уровня для каждого протокола сетевого уровня, который они поддерживают. (Это предполагает, что устройство имеет только одно физическое сетевое соединение.) Маршрутизаторы и другие устройства, поддерживающие межсетевой обмен, требуют один адрес сетевого уровня на каждое физическое соединение для каждого поддерживаемого протокола сетевого уровня. Например, маршрутизатор с тремя интерфейсами, каждый из которых поддерживает одновременно AppleTalk, TCP/IP и OSI, должен иметь три адреса сетевого уровня для каждого интерфейса. Поэтому маршрутизатор имеет девять адресов сетевого уровня.
Функции межсетевого обмена сетевого уровня отвечают за выбор лучшего маршрута передачи пакетов в сети, создание сетевых адресов и коммуникационных маршрутов.
Маршрутизаторы используют протокол маршрутизации для обмена служебной информацией между собой, используют маршрутизируемый протокол для передачи пакетов пользователя, настраивают и поддерживают таблицы маршрутизации, находят сети, адаптируют изменения межсетевой топологии, используют адрес из двух частей и ограничивают распространение широковещательных рассылок.
Службы WAN
Х.25 Протокол Х.25 первоначально был разработан в 1970-х гг. для предоставления неинтеллектуальному терминалу соединения WAN через общедоступные сети данных (PDN — public data network). Однако благодаря своей гибкости и надежности он стал международным стандартом для пересылки данных через PDN.
Ориентированный на соединение интерфейс сети коммутации пакетов (PSN) предоставляет контроль ошибок и гарантированную доставку пакетов с помощью коммутируемых или виртуальных цепей. Благодаря своей надежности он используется для приложений, которые требуют надежной передачи. Маршрутизатор будет соединяться с ассемблером/дизассемблером пакетов (PAD) в сети Х.25. PAD отвечает за разбиение сообщений на пакеты и соответствующую их адресацию.
Спецификация Х.25 соответствует физическому, канальному и сетевому уровням модели OSI. Однако, так как спецификация Х.25 предшествовала модели OSI, названия уровней отличаются. Например, физический уровень называется Х.21 и определяет электрические и физические интерфейсы, которые могут использоваться. Второй уровень называется протоколом сбалансированной процедуры доступа к каналу (LAPB, Link Access Procedure Balanced), который заботится о создании кадра, управлении потоком и контроле ошибок. Уровень пакета соответствует сетевому уровню и отвечает за настройку и адресацию виртуальной цепи.
Frame Relay Отраслевой стандартный коммутируемый Протокол Frame Relay действует на канальном уровне. Он обрабатывает множество виртуальных каналов с помощью инкапсуляции HDLC между соединенными устройствами. Frame Relay использует высококачественную цифровую технику, делая методы контроля ошибок и управления потоком ненужными. Поэтому он является более эффективным и быстрым, чем протокол Х.25, в качестве замены которого он чаще всего рассматривается. Используя упрощенное кадрирование без исправления ошибок, Frame Relay может очень быстро посылать информацию своего уровня. Первоначально он зарождался как протокол для работы с интерфейсами ISDN, поэтому был разработан как независимый протокол.
Внутри Frame Relay коммутация PDN реализуется с помощью статистического метода мультиплексирования, а не с помощью временного разделения. При статистическом мультиплексировании доступные цепи формируются из устройств, которые в данный момент ничему не поставлены в соответствие. В связи с этими динамическими характеристиками сети реального времени, которые пульсируют по своей природе, являются идеальными кандидатами для Frame Relay.
Управление каналом осуществляется с помощью интерфейса локального управления (Local Management Interface, LMI). LMI отвечает за создание постоянного виртуального канала (PVC, Permanent Virtual Circuit) и мониторинг PVC. Так как цифровые каналы менее подвержены ошибкам, Frame Relay использует только алгоритм CRC для обнаружения плохих данных, но не использует никакого механизма для их исправления. Для управления потоком в канале Frame Relay полагается на верхние протоколы.
РРР является семейством протоколов, которые предоставляют мульти-протокольную инкапсуляцию, протокол контроля линии (LCP) для создания, конфигурирования и тестирования соединения канала данных, и семейство протоколов управления сетью (NCP) для создания и конфигурирования протоколов различных сетевых уровней.
Как можно видеть на рис, РРР устанавливает флаг как 0х7Е (01111110), чтобы указать начало и конец кадра РРР. В последовательных кадрах РРР будет задан только один символ флага. Поле адреса используется для адресации пакета для узла места назначения. В двухточечной линии связи узел назначения адресовать не нужно. Поэтому в РРР поле адреса задается как OxFF, т.е. как адрес широковещания.
В среде HDLC контрольное поле используется для функции подтверждения и упорядочивания уровня канала данных; однако в РРР контрольное поле задано как 0x03 для указания кадра ненумерованной информации (UI). Это то же самое, что и бит, который задается в методах кадрирования Ethernet.
Поле протокола имеет два байта и используется для идентификации протокола в полезной нагрузке РРР. Если поле задано как 0x00-21, то оно указывает на дейтаграмму IP. Контрольная последовательность кадра (FCS) является двухбайтовой CRC, аналогичной тому, что используется для инкапсуляции Ethernet.
Как и SLIP, РРР имеет метод, предотвращающий появление символа флага в середине данных. В синхронной линии связи, такой как ISDN, используется заполнение битами для вставки дополнительных битов, чтобы отметить, когда появляется символ флага. Закодированное представление байтов может содержать более 8 битов, но дополнительные биты добавляются и удаляются аппаратурой синхронной линии связи.
РРР использует также заполнение символами (подобно SLIP) на асинхронных линиях для предотвращения появления флага внутри кадра РРР. Если символ 0х7Е появляется в исходной дейтаграмме IP, то он заменяется строкой символов 0x7D-5D. Если символ ESC (0x7D) возникает в исходной дейтаграмме, то он заменяется последовательностью 0x7D-5D снова в 0x7D.
Символы меньше 0x20 также модифицируются, чтобы последовательные драйверы не интерпретировали их как управляющие символы, посылая 0x7D, а затем исходный символ с дополненным шестым битом.
Максимальная получаемая единица данных (MRU) равна 1500 байтам.
РРТР Протокол РРТР является способом взять существующий кадр РРР и инкапсулировать его через межсетевой обмен IP. РРТР позволяет создать в Интернете защищенные виртуальные частные сети (VPN). РРТР может использоваться независимо от того, поддерживает VPN провайдер услуг Интернета (ISP) или нет. Требуется только сервер, поддерживающий РРТР, и клиент, который может создать соединение РРТР. ,
Инкапсуляция кадров РРР реализуется с помощью протокола инкапсуляции базовой маршрутизации (GRE), который использует ID протокола IP, равный 47 (0x2F). Для использования его с РРТР протокол GRE был усовершенствован, чтобы предоставить поле подтверждения.
Как показано на рис. 1.15, кадр РРТР имеет заголовок среды и заголовок IP, прежде чем добраться до заголовка GRE. После заголовка GRE следует заголовок РРР, а затем полезная нагрузка РРР.
Заголовок GRE начинается с двух байтов для флагов. Эти флаги указывают, присутствует ли полезная нагрузка GRE и номера последовательности и подтверждения. Поле типа протокола содержит значение Ethernet, которое соответствует РРР (0х88-0В). Длина полезной нагрузки равна размеру полезной нагрузки GRE в байтах. Идентификатор (ID) вызова является информацией идентификации сеанса для этого пакета РРТР, за которым следуют номера последовательности и номер подтверждения — самый большой номер последовательности, полученный посылающим узлом этого сеанса. Номер последовательности используется для управления потоком, а не для повторной передачи потерянных кадров РРТР.
Процедура создания соединений использует флаг управления синхронизацией (SYN) и включает обмен тремя сообщениями. Этот обмен был назван трехходовым квитированием. Соединение инициируется при встрече прибывающего сегмента, содержащего SYN, и ожидающего входа TCN, которые создаются командой пользователя OPEN. Соответствие локального и внешнего сокетов определяет, когда соединение было инициировано. Соединение становится "установленным", когда номера последовательности синхронизированы в обоих направлениях. Очистка соединения также включает обмен сегментами, несущими в этом случае управляющий флаг FIN.
Протокол не делает никаких ограничений на повторное использование определенного соединения. Соединение определяется парой сокетов. Новые экземпляры соединения будут называться инкарнациями соединения. При этом возникает проблема: "Как TCP идентифицирует сегменты дубликаты из предыдущих инкарнаций соединения?" Эта проблема становится очевидной, если соединение открывается и закрывается в быстрой последовательности или прерывается в связи с нехваткой памяти, а затем восстанавл ивается.
Чтобы избежать путаницы, необходимо воспрепятствовать использованию сегментов из одной инкарнации соединения, в то время как те же самые номера последовательности от предыдущей инкарнации могут по-прежнему присутствовать в сети. Мы хотим гарантировать это, даже если TCP прерывает работу и теряет всю информацию о номерах последовательности, которые он использует. Когда создается новое соединение, используется генератор начального порядкового номера (ISN), который выбирает новый 32- разрядный ISN. Генератор связан с 32-битными часами (возможно, фиктивными), младший бит которых увеличивается каждые четыре миллисекунды. Таким образом, ISN циклически повторяется примерно каждые 4,55 часов. Так как мы предполагаем, что сегменты будут оставаться в сети не дольше, чем максимальное время жизни сегмента (MSL), и что MSL меньше 4,55 часов, то можно считать, что ISN будет уникальным.
Для каждого соединения существует номер посылаемой последовательности и номер получаемой последовательности. Начальный номер посылаемой последовательности (ISS) выбирается посылающим данные TCP, а начальный номер принимаемой последовательности (1RS) узнается во время процедуры создания соединения. Чтобы соединение было установлено или инициализировано, два TCP должны синхронизировать друг с другом начальные номера последовательностей. Это делается при обмене устанавливающими соединение сегментами, несущими управляющий бит, называемый "SYN" (от слова синхронизация), и начальные номера последовательностей. В качестве сокращения сегменты, переносящие бит SYN, также называются "SYN". Следовательно, решение требует подходящего механизма для выбора начального номера последовательности и небольшого привлечения квитирования для обмена ISN.
Синхронизация требует, чтобы каждая сторона посылала свой собственный начальный номер последовательности и получала подтверждение от другой стороны. Каждая сторона должна также получить начальный номер последовательности другой стороны и послать об этом подтверждение.
1. А —> В SYN мой номер последовательности X
2. А <—- В АСК ваш номер последовательности X
3. А <-- В SYN мой номер последовательности Y
4. А —> В АСК ваш номер последовательности Y
Так как шаги 2 и 3 обычно объединяются в одном сообщении, то последовательность называется трехходовым квитированием. На рис. 2.3 показано, как это выглядит в реальной жизни.
Трехходовое квитирование необходимо в связи с тем, что номера последовательности не связаны с глобальными часами сети, и TCP может иметь другие механизмы для выбора ISN. Получатель первого SYN не может узнать, является ли сегмент задержавшимся старым или нет, если он не помнит последний номер последовательности, использованный соединением (что не всегда возможно). Поэтому он должен запросить отправителя проверить, что TCP не создал сегмент, несущий номер последовательности, который может дублироваться старым сегментом, остающимся в сети. TCP должен оставаться спокойным в течение максимального периода жизни (MSL), прежде чем присваивать какие-либо номера последовательности при запуске или восстановлении после ошибки, при которой память используемых номеров последовательности была стерта. Для этой спецификации MSL задается равным двум минутам. Это инженерный выбор, который может быть изменен, если опыт покажет такую необходимость. Отметим, что если TCP повторно инициализирован, но сохранил в памяти номера последовательности, ему вообще не нужно ждать, он должен лишь использовать номера последовательности, превышающие использованные ранее.
Во всех состояниях, кроме SYN-SENT, все сегменты сброса (RST) контролируются проверкой их полей SEQ. Сброс будет признан действительным, если его номер последовательности находится в пределах окна. В состоянии SYN-SENT (RST получен в ответ на начальный SYN) RST является приемлемым, если поле АСК подтверждает SYN.
Получатель RST сначала проверяет его, а затем изменяет состояние. Если получатель был в состоянии LISTEN, то он его игнорирует. Если получатель был в состоянии SYN-RECErVED, а ранее — в состоянии LISTEN, то получатель возвращается в состояние LISTEN; иначе получатель прерывает соединение и переходит в состояние CLOSED. Если получатель был в другом состоянии, он прерывает соединение, уведомляет пользователя и переходит в состояние CLOSED. Закрытие соединения (CLOSE) является операцией, означающей: "У меня больше нет данных для пересылки". Понятие закрытия дуплексного соединения часто неверно интерпретируется, так как может быть не очевидно, как интерпретировать получающую сторону соединения. Мы выбрали одностороннюю интерпретацию CLOSE. Пользователи, которые делают CLOSE, могут продолжать RECEIVE (получать), пока они не получат сообщение о том, что другая сторона также CLOSED (закрыта). Таким образом, программа могла бы инициировать несколько команд SEND (послать) после команды CLOSE (закрыть), и затем продолжить получать, пока не будет получен сигнал, что команда RECEIVE (получить) не сработала, так как другая сторона закрылась (CLOSED). Мы предполагаем, что TCP будет сигнализировать пользователю, даже если нет никаких ожидающих RECEIVE и другая сторона закрыта, поэтому пользователь сможет аккуратно завершить свою работу. TCP надежно доставит все буферы, посланные до того, как соединение было закрыто, поэтому пользователю, который не ожидает возврата никаких данных, необходимо только подождать сообщения, что соединение успешно закрыто, следовательно, все его данные были получены TCP местом назначения. Пользователи должны продолжать считывание соединений, которые они закрыли для отправки, пока TCP не сообщит об отсутствии данных. Рассмотрим три существующих сценария:
1. Закрытие инициирует пользователь, приказывая TCP закрыть соединение.
2. Закрытие инициирует удаленный TCP, посылая управляющий сигнал FIN.
3. Оба пользователя закрывают соединение одновременно.
Сценарий 1: локальный пользователь инициирует закрытие
В этом случае может быть создан сегмент FIN и помещен в очередь исходящих сегментов. Никакие другие команды SEND пользователя TCP не принимает и входит в состояние FIN-WAIT-1. В этом состоянии допускаются команды RECEIVE (получить). Все сегменты, предшествующие и включающие FIN, будут посылаться повторно, пока не будет подтверждено их получение. Когда другой TCP подтвердит FIN и пошлет свою собственную команду FIN, первый TCP может подтвердить (АСК) этот FIN. Отметим, что TCP, получающий FIN, будет подтверждать (АСК), но не посылать свой собственный FIN, пока его пользователь также не закроет соединение.
Сценарий 2: TCP получает FIN из сети
Если из сети прибывает не вынужденный FIN, то получающий TCP может подтвердить его и сообщить пользователю, что соединение закрывается. Пользователь ответит командой CLOSE, затем TCP может послать FIN другому TCP после отправки всех оставшихся данных. Затем TCP ожидает, пока его собственный FIN не будет подтвержден, после чего удаляет соединение. Если подтверждение АСК не поступает после периода ожидания пользователя, соединение прерывается и об этом сообщается пользователю.
Сценарий 3: оба пользователя закрывают соединение одновременно
Одновременное закрытие пользователями на обоих концах соединения вызывает обмен сегментами FIN. Когда все сегменты, предшествующие FIN, обработаны и подтверждены, каждый TCP может подтвердить полученный FIN. После получения этих АСК оба удалят соединение.
