Протокол ip поверх atm

Стек протоколов TCP/IP хорошо знаком сетевым специалистам. Но с появлени­ем ATM возник вопрос: «Не отказаться ли полностью от TCP/IP и не взять ли на вооружение ATM?» Жизнь показала, что правильнее всего — объединить до­стоинства этих двух технологий.

За прошедшее время стек TCP/IP не только не утратил своей популярности, но и с каждым годом завоевывает все новые позиции. Основные причины успеха TCP/IP заключаются в доступности его спецификаций и открытости архитекту­ры. TCP/IP поддерживается практически всеми операционными системами и сетевыми продуктами. Другого своего конкурента, протокол IPX компании No­vell, TCP/IP превосходит по масштабируемости, так как TCP/IP одинаково хорошо работает как в небольших сетях с несколькими пользователями, так и в крупных сетях масштаба предприятия.

К сожалению, из-за того, что стандарт на протокол TCP/IP разработан доста­точно давно, он не может удовлетворить все современные требования, например передачу видеоинформации в реальном времени, так как не поддерживает резер­вирование части полосы пропускания. Правила обработки информации в прото­коле TCP/IP одинаковы для всех приложений, будь то электронная почта или видеоконференции. В любом случае данные имеют одинаковый приоритет при обработке и передаются с одной и той же скоростью — несмотря на то, что, очевидно, данные последнего приложения более приоритетны. Кроме того, про­токол не учитывает, что для передачи информации критичной к задержкам, соответствующие пакеты должны пересылаться в строго определенной последо­вательности и в первую очередь.

Технология ATM имеет значительные преимущества по сравнению с про­токолом IP: благодаря ориентации на установление логического соединения между абонентами она гарантирует эффективную и устойчивую работу и тем самым идеально подходит для передачи по сети аудио- и видеоинформации. Протокол IP целесообразно интегрировать с ATM только в том случае, если большинство компьютеров в организации не подключены напрямую к сети ATM. Такая ситуация в настоящее время типична, так как ATM, в основном, применяется для построения магистрали, связывающей отдельные локальные сети организации.

Поиском решения упомянутых проблем протокола IP занимаются рабочие группы IETF, но пройдет некоторое время до принятия соответствующих стан­дартов. В любом случае протокол TCP/IP и его модернизации будут широко применяться в сетях с ATM.

Передача ip-Дейтаграмм по сети atm

Для выработки стандартов, описывающих механизм функционирования прото­кола IP в сетях ATM, была сформирована рабочая группа ION (Internetworking Over ATM) комитета IETF. Прежде всего были стандартизованы методы пере­дачи пакетов сетевого уровня через соединения ATM, а также способы муль­типлексирования этих пакетов при работе с одним соединением. При приеме пакетов различных типов получатель должен иметь возможность определить тип переданного — возможно, с применением мультиплексирования — пакета и то, какому приложению его следует передать. Следовательно, пакет должен иметь префикс с необходимыми для демультиплексирования полями.

Для поддержки мультиплексирования/демультиплексирования пакетов сущест­вуют два метода, определенных в документе RFC 1483 (Multiprotocol Encapsu­lation over ATM Adaptation Layer 5), июль 1993 года.

Согласно первому методу пакеты различных протоколов передаются через одно соединение с добавлением к ним стандартного заголовка LLC/SNAP. Па­кеты с добавленным заголовком LLC/SNAP инкапсулируются в кадры уровня адаптации ATM (AAL5). На рис. 16.1 показан общий механизм формирования и передачи пакетов протоколов сетевого уровня через виртуальное соединение.

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

Заголовок LLC/SNAP имеет длину 8 байт и состоит из трех полей: LLC (Lo­gical Link Control) (3 байта), OUI (Organizationally Unique Identifier) (3 байта) и PID (Protocol Identifier) (2 байта) (рис. 16.2). Именно последнее поле исполь­зуется для идентификации протокола. Например, значение 0х0800 указывает на то, что передаются дейтаграммы IP, значение 0х0806 указывает на передачу слу­жебного сообщения протокола ARP и т. д. Полный список значений этого поля можно найти в документе RFC 1700.

Структура заголовка LLC/SNAP позволяет передавать данные нескольких протоколов сетевого уровня через одно виртуальное соединение, что уменьшает количество требующихся соединений, хотя при этом вносится избыточность в размере 8 байт на кадр уровня адаптации. Данный метод используется по умол­чанию в классическом IP для ATM (см. ниже).

Второй метод, описанный в документе RFC 1483, называется мультиплек­сированием виртуальных соединений (multiplexing VC) или нулевой инкапсуля­цией (Null encapsulation). Согласно этому методу, через соединение передаются данные только одного протокола, и тип протокола явно указывается при уста­новлении соединения. В результате не требуются мультиплексирование и иденти­фикация протокола. Такой метод может использоваться там, где осуществляется прямое взаимодействие между приложениями, в обход протоколов нижних уровней. При этом взаимодействие устройств, находящихся за границами сети ATM, становится невозможным. Кроме того, в многопротокольных сетях такой метод требует установления множества виртуальных соединений, что не всегда приемлемо.

Рабочая группа ION также определила размер максимальной единицы пере­дачи (MTU) для сетей ATM (RFC 1626, май 1994 года). Некоторые приложе­ния, например NFS (Network File System), лучше работают с большим MTU. Для повышения производительности желательно уменьшить количество фраг­ментации дейтаграмм IP. В документе RFC 1209 размер MTU определен равным 9180 байт для SMDS (Switched Multi-Megalit Data Service) — коммутируемой службы передачи данных, обеспечивающей передачу по стандарту IEEE 802.6. Данное значение признано приемлемым и для сетей ATM.

Как указано в документе RFC 1626, два клиента, поддерживающие протокол TCP/IP и связанные между собой постоянным виртуальным соединением, до­лжны использовать MTU с размером 9180 байт, если они заранее не определили меньшее или большее значение. В случае использования коммутируемого вир­туального соединения клиенты будут договариваться о размере MTU во время установления этого соединения. Отправитель может указать значение MTU по умолчанию или другое значение в служебном сообщении, посылаемом при уста­новлении соединения. Получатель может принять это значение или указать меньшее в ответном сообщении.

Отправитель и получатель могут также договориться об использовании MTU, превышающего заданный по умолчанию, если они согласятся с фрагментацией посылаемых данных. Существует метод, который позволяет определить макси­мально возможное значение MTU на пути передачи. Для этого устройства (рабочие станции, маршрутизаторы и т. д.) должны поддерживать механизм, описанный в документе RFC 1191 в ноябре 1994 года. Цель введения этого ме­ханизма состоит в минимизации фрагментации на промежуточных узлах.