Передача 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 года. Цель введения этого ме­ханизма состоит в минимизации фрагментации на промежуточных узлах.