Примитивы DLPI

Примитивы DLPI

Как и в случае предоставления транспортных услуг, обмен данными между пользователем и поставщиком происходит в виде сообщений, несущих примитивы DLPI. Ниже рассмотрены некоторые из этих примитивов, относящиеся к режиму передачи без предварительного установления связи и без подтверждения. Именно такой режим обычно используется в традиционных локальных сетях.

Несмотря на то что рассматриваемая услуга не предусматривает установления связи, фактической передаче данных предшествует обмен примитивами для инициализации потока и подключения его к поставщику услуг уровня канала данных. Во-первых, пользователь должен создать точку доступа к поставщику услуг, для чего необходимо произвести операцию связывания. Во-вторых, в случае использования поставщика услуг второго типа (style 2), пользователь также должен подключиться к требуемой PPA. Наконец, пользователю может потребоваться произвести ряд действий, включающих получение информации о созданном потоке, регистрацию специфического группового адреса для потока или включение режима отсутствия фильтрации кадров, при котором пользователь сможет получать копии всех пакетов, полученных поставщиком услуг.[94]

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

Итак, приведем некоторые управляющие сообщения DLPI, используемые в режиме без предварительного установления связи и без подтверждения. В табл. 6.12 приведено их краткое описание.

Таблица 6.12. Примитивы DLPI

Примитив DLPI Тип сообщения Значение DL_BIND_REQ M_PROTO Запрос на связывание. Этот примитив инициируется пользователем услуг и запрашивает связывание потока с точкой доступа и его активизацию. Следует иметь в виду, что активным считается поток, для которого поставщик услуг может передавать или принимать пакеты данных. Таким образом, PPA, ассоциированная с данным потоком, должна быть инициализирована до завершения обработки запроса на связывание (другими словами, поставщик гарантирует, что при получении пользователем подтверждения связывания DL_BIND_ACK инициализация PPA завершилась успешно. Сообщение состоит из одного блока M_PROTO, который содержит значение адреса SAP, тип услуги и ряд других параметров, обсуждение которых выходит за рамки данной книги. DL_BIND_ACK M_PCPROTO Подтверждение получения запроса на связывание. Этот примитив отправляется пользователю услуг и означает, что поток был связан с адресом SAP и был активизирован. Сообщение состоит из одного блока M_PCPROTO, в частности, содержащего значение адреса SAP. DL_ATTACH_REQ M_PROTO Запрос на подключение к PPA. Этот примитив инициируется пользователем услуг уровня канала данных и запрашивает у поставщика ассоциацию потока с указанной PPA. Этот запрос является необходимым для поставщика второго типа (style 2) для указания физической среды, по которой будут передаваться данные. Сообщение состоит из одного блока M_PROTO, в котором пользователь передает значение идентификатора PPA. Формат этого идентификатора определяется поставщиком. Пользователь должен указать, как минимум, физическую среду передачи. Для сетей, где несколько независимых каналов передачи мультиплексируются в одном физическом носителе, идентификатор также должен содержать информацию о конкретном канале передачи данных. Примером технологий, обеспечивающих такое мультиплексирование являются ISDN (каналы В и D) и ATM (коммутируемые и постоянные виртуальные каналы — SVC и PVC). DL_INFO_REQ M_PCPROTO Запрос на получение параметров потока. Этот примитив служит для запроса пользователем значений размеров различных параметров потока, активизированного поставщиком DLPI, а также информации о текущем состоянии интерфейса. Сообщение состоит из одного блока M_PCPROTO. DL_INFO_ACK M_PCPROTO Параметры транспортного протокола. Этот примитив служит для передачи пользователю ранее запрошенных с помощью DL_INFO_REQ параметров. Сообщение состоит из одного блока M_PCPROTO, содержащего информацию, часть из которой приведена ниже: dl_max_sdu — определяет максимальное число октетов данных пользователя, которое может быть передано в одном кадре. (Максимальный размер SDU поставщика услуг.) dl_min_sdu — определяет минимальный размер SDU. dl_addr_length — определяет максимальную длину адреса DLSAP поставщика. Этот адрес, помимо адреса SAP может также включать физический адрес интерфейса и ряд других полей (иерархический адрес). dl_addr_offset — указывает смещение адреса DLSAP в блоке M_PCPROTO. dl_mac_type — указывает тип среды передачи, поддерживаемой потоком DLPI. См. значение поля mac_type структуры DL_sap_t ранее в этой главе. dl_current_state — указывает текущее состояние потока. dl_service_mode — определяет тип услуги, обеспечиваемой потоком DLPI. dl_provider_style — определяет тип поставщика услуг (style 1 или style 2). dl_brdcst_addr_length — определяет размер физического широковещательного адреса. dl_brdcsr_addr_offset — указывает смещение значения адреса DLSAP в блоке M_PCPROTO. DL_UNITDATA_REQ M_PROTO Запрос на передачу данных. Этот примитив применим только для услуг уровня канала данных без предварительного установления связи и отправляется пользователем услуг в качестве запроса на передачу кадра. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих данные пользователя. Блок M_PROTO содержит значения размера адресов и сам адрес получателя кадра, а также приоритет из диапазона, определенного поставщиком. DL_UNITDATA_IND M_PROTO Индикация получения данных. Этот примитив применим только для услуг уровня канала данных без предварительного установления связи и указывает пользователю, что поставщиком услуг получен кадр от удаленного узла. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих данные пользователя. Блок M_PROTO содержит значения адресов отправителя и получателя кадра. DL_OK_ACK M_PCPROTO Положительное подтверждение. Этот примитив сообщает пользователю услуг уровня канала данных, что предшествующий примитив, инициированный им, был успешно принят поставщиком услуг. Примитив DL_OK_ACK передается только для примитивов, нуждающихся в подтверждении. DL_ERROR_ACK M_PCPROTO Сообщение об ошибке. Этот примитив сообщает пользователю услуг, что последний примитив, инициированный им, вызвал ошибку. Получение этого примитива может рассматриваться как отрицательное подтверждение, свидетельствующее, что никаких действий, связанных с ошибочным примитивом, не было предпринято. Сообщение состоит из одного блока M_PCPROTO, содержащего тип примитива, вызвавшего ошибку, код DLPI и, если возможно, код системной ошибки UNIX. DL_UDERROR_IND M_PROTO Сообщение об ошибке кадра. Этот примитив применим только для услуг уровня канала данных без предварительного установления связи и указывает пользователю, что его запрос на передачу DL_UNITDATA_REQ вызвал ошибку и не может быть выполнен. Сообщение состоит из одного блока M_PROTO, содержащего размер адреса и сам адрес получателя, а также код ошибки.

Данный текст является ознакомительным фрагментом.