Добавил:
sergeevpavel0406@mail.ru СОВА Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Информатика в техническом университете / Информатика в техническом университете. Телекоммуникации и сети

.pdf
Скачиваний:
136
Добавлен:
06.03.2018
Размер:
23.39 Mб
Скачать

5. Сетевые протоколы

Таблица 5.4. Основныетипы кадров LAPP

1 Формат 1

Комацца

1-кадры Информация

1 Ответ 1

Описание

Используется в режиме с подтверждением для пе­

-редачи нумерованных кадров, содержащих информа­ ционные поля с сообщениями верхних уровней.

S-кадры

К приему готов

К приему

Используется для з^казания готовности встречной

(RR)

готов

стороны к приему 1-кадра или для подтверждения

 

 

 

(RR)

ранее полученных 1-кадров

 

К приему не

К приему

Используется для указания неготовности

 

готов (RNR)

не готов

встречной стороны к приему 1-кадра

 

 

(RNR)

 

 

Отказ/переспрос

Отказ/пе­

Используется для запроса повторной передачи

 

(REJ)

респрос

 

1-кадра

 

 

(REJ)

 

U-кадры

Ненумерованная

Используется в режиме передачи без подтверж- 1

информация (UI)

дения

-Отключе­ но (DM)

Установка

 

Используется для начальной усгановки режима с

1

расширенного

-

подтверждением

 

асинхронного ба­

 

 

лансного режима

 

 

 

(SABME)

 

 

 

 

Отказ

 

 

-

кадра

 

 

 

(FRMR)

 

 

Разъединение

Используется для прекращения режима с подт-

1

(DISC)

верждением

 

"

Ненуме­

Используется для подтверждения приема комацд

 

рованное

 

установки режима, например, SABME, DISC

 

подт­

 

 

вержде­

 

 

ние (UA)1

 

Рассмотрим эти типы несколько подробнее.

Информационный кадр (1-кадр) - с его помощью организуют передачу ин­ формации сетевого уровня между терминалом пользователя и сетью. Этот кадр содержит информационное поле, в котором помещено сообщение сетевого уров­ ня. Поле управления 1-кадра содержит порядковый номер передачи (N/S), ко­ торый увеличивается на 1 (по модулю 128) для каждого передаваемого кадра. При подтверждении приема 1-кадров в поле управления вводится порядковый номер приема (N/R).

330

5.4. Протоколы IVуровня стека TCP/IP

Управляющий кадр (S-кадр) необходим для поддержки функций управления потоком и запроса повторной передачи. S-кадры не имеют информационного поля. Например, если сеть временно не в состоянии принимать 1-кадры, пользо­ вателю посылается S-кадр «к приему не готов» (RNR). Когда сеть снова мо­ жет принимать 1-кадры, она передает другой S-кадр - «к приему готов» (RR). S-кадр также можно использовать для подтверждения в этом случае он содер­ жит порядковый номер приема, а не передачи.

Управляющие кадры передают как командные или как кадры ответа. Ненумерованный кадр (U-кадр). Среди ненумерованных кадров имеется

кадр ненумерованной информации (UI), единственный, содержащий информа­ ционное поле и несущий сообщение сетевого уровня. U-кадры используют для передачи информации в режиме без подтверждения и некоторых администра­ тивных директив. Чтобы транслировать сообщение ко всем терминалам, под­ ключенным к шине S-интерфейса, станция передает кадр UI с TEI = 127. Поле управления U-кадров не содержит порядковых номеров.

Информационное поле предусмотрено в кадрах только некоторьпс типов. В нем заключена информация сетевого уровня, сформированная одной системой, например, терминалом пользователя, которую необходимо передать другой си­ стеме, например сети. Информационное поле может быть пропущено, если кадр не имеет отношения к конкретной коммутируемой связи (например, в управля­ ющих кадрах, S-формат). Если кадр относится к канальному уровню и сетевой уровень не участвует в его формировании, соответствующая информация вклю­ чается в поле управления.

Биты P/F (poll/final) поля управления идентифицируют группу кадров (см. табл. 5.4), что также заимствовано из спецификаций протокола HDLC. Путем установки в «1» бита Р в командном кадре функции LAPD на одном конце звена данных указьюают функциям LAPD на противоположном конце звена на необходимость ответа управляющим или ненумерованным кадром. Кадр отве­ та с F = 1 указьюает, что он передается в ответ на принятый командный кадр со значением Р = 1. Оставшиеся биты байта 4 идентифицируют конкретный тип кадра в пределах группы.

Передача с подтверждением. Этот способ используют для передачи ин­ формационных кадров только в соединениях звена данных, имеющих конфигу­ рацию «точка-точка». Он обеспечивает исправление ошибок путем повтор­ ной передачи и доставку не содержащих ошибок сообщений в порядке очередности.

Поле управления информационного кадра имеет подполя «номер передачи» N(S) и «номер приема» N(R). Эти подполя аналогичны одноименным полям в HDLC. Протокол LAPD присваивает по модулю 128 возрастающие порядко­ вые номера передачи N(S) последовательно передаваемым информационным кадрам. Он также записывает передаваемые кадры в буфер повторной переда­ чи и хранит их в буфере до получения положительного подтверждения их приема.

331

1-кадр N(S)=7

Ошибка

 

 

 

 

 

^1

REJ-кадр N(R)=6

 

 

1-кадр N(S)=6

 

'Л'

 

 

1-кадр N(S)=7

 

Л1

5. Сетевые протоколы

Терминал

 

Сеть

1-кадр N(S)=5

 

'^

 

 

PI

1-кадр N(S)=6

V

J

W'

114

. Кадр принят без j оигабок !

I Кадр отброшен гфи | j проверке ошибок j

I Кадр отброшен ipn • j проверке очередности j

IПовторная передача, | t принято I

(Повторная передача,! [ принято I

Рис. 5.6. Исправление ошибок в информационном кадре

Рассмотрим передачу информационных кадров с исправлением ошибок от терминала к сети (рис. 5.6). Все поступающие в сеть кадры проверяются на наличие ошибок, а затем в свободных от ошибок информащюнных кадрах про­ веряется порядковый номер. Если значение N(S) вьппе (по модулю 128) на еди­ ницу чем N(S) последнего принятого информационного кадра, новый кадр счи­ тается следующим по порядку и поэтому принимается, а его информационное поле пересьшается конкретной функции сетевого уровня. После этого сеть под­ тверждает прием информационного кадра своим исходящим кадром с номе­ ром приема N(R), значение которого на единицу больше (по модулю 128), чем значение N(S) в последнем принятом информационном кадре.

Предположим, что последний принятый информационный кадр имел номер N(S) = 5 и что информационный кадр с номером N(S) = 6 передан с ошибкой, в результате которой отбракован функциями LAPD на стороне сети. Следующий информационный кадр с N(S) = 7 успешно проходит проверку на ошибки, но поступает в сеть с нарушением очередности и отбрасывается ею при проверке порядка следования. Тогда сеть передает кадр отказа (КЕТ) с номером N(R) = 6, который запрашивает повторную передачу информационных кадров из буфера повторной передачи терминала, начиная с кадра с N(S) = 6. Сетевая сторона продолжает отбрасьшать информационные кадры при проверке их на порядок следования, пока не примет повторно переданный кадр с номером N(S) = 6.

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

332

5.4. Протоколы IVуровня стека TCP/IP

значением N(S) (числом переданных кадров I) и значением N(R) (числом под­ твержденных кадров I) превысит параметр, обозначаемый к Значение Л уста­ навливается в соответствии со спецификой использования звена и скоростью передачи в нем: к=\- для сигнализации базового доступа BRA при скорости Л-канала 16 кбит/с, к = Ъ - для пакетной передачи при скорости 16 1^ит/с, к = 7 - для сигнализации первичного доступа PRA при скорости /)-канала

64кбит/с.

Два потока сообщений от терминала к сети и в обратном направлеьши для

соединения «точка-точка» независимы друг от друга и от потоков сообщений в других соединениях «точка-точка» в том же /)-канале. В /^-канале с п соеди­ нениями типа «точка-точка» могут присутствовать 2п независимых последо­ вательностей N(S)/N(R).

Процедура подтверждаемой передачи информации (рис. 5.7). Рассмот­ рим случай, когда необходимо начать передачу информации уровня 3 от терми­ нала пользователя к сети. Инициатором данной процедуры является уровень 3 на стороне пользователя, который выдает примитив запроса соединения DLESTABLISH. По этому запросу уровень 2 на стороне пользователя форми­ рует управляющий кадр установки расширенного асинхронного балансного ре­ жима (SABME - Set Asynchronous Balanced Mode Extended). Кадр SABME пересылается к сети через уровень 1. При получении кадра SABME уровнем 2 на стороне сети проверяются условия, необходимые для установки режима подтверждаемой передачи информации (например, чтобы убедиться, что соот-

Запрос соединения

i

Терминал

Сеть

 

^

SABME

II

 

от уровня 3

j

Индикация

Подтверждение

 

 

Ненумерованное

Г"!

запроса

 

 

 

установления

 

NJ U

подтверждение

 

соединения для

 

 

уровня 3

 

 

 

соединения для

 

^

 

 

 

уровня 3

 

 

1-кадр

Л

Индикация

 

 

 

Запрос передачи

i

 

данных для

 

 

 

данных от уровня 3

j

 

1-кадр или «готов к приему»

 

уровня 3

Индикация данных

 

K~JL'

или «не готов к приему»

 

 

для уровня 3,

 

 

 

 

управление потоком

 

 

 

 

DJSC

 

Индикация

на уровне 2

 

 

 

 

у\

 

"ЛГ

освобождения

Запрос

 

 

 

Ненумерованное

для уровня 3

освобождения от

 

 

уровня 3

 

L^

подтверждение

 

 

 

 

V

 

 

 

/ 1

Подтерждение освобождения для уровня 3

Рис. 5.7. Процедура подтверждаемой передачи

333

5. Сетевые протоколы

ветствующее оборудование доступно). Если все условия вьшолнены, уровень 2 на стороне сети посылает уровню 3 примитив индикации запроса соединения, чтобы указать, что устанавливается режим подтверждаемой передачи инфор­ мации. Средствами уровня 2 сеть возвращает пользователю ненумерованное подтверждение. При получении этого подтверждения терминалом пользовате­ ля на уровень 3 передается примитив подтверждения установления соедине­ ния, указывающий, что можно начинать подтверждаемую передачу информа­ ции. Теперь между пользователем и сетью можно осуществить передачу информации с помощью 1-кадров.

Эта информация направляется уровнем 3 к уровню 2 в примитиве запроса передачи данных DLDATA. Данные помещаются в информационное поле 1-кадра и передаются от пользователя к сети через уровень 1. При получении уровнем 2 на стороне сети 1-кадра данные извлекаются из информационного поля и передаются к уровню 3 в примитиве индикации приема данных. В зави­ симости от содержимого полученного 1-кадра сеть посылает в ответ пользова­ телю либо 1-кадр, либо управляющий кадр готовности к приему. Оба кадра содержат подтверждение, что 1-кадр от пользователя был успешно принят.

Каждый 1-кадр содержит в поле управления порядковые номера передачи и приема. Процедура обнаружения потерь работает в обоих направлениях. В ка­ честве примера на рис. 5.6 бьша рассмотрена передача необходимого сетево­ му уровню числа информационных кадров, включая передачу кадров 5, 6 и 7. Когда обмен 1-кадрами, показанный на рис. 5.6, заканчивается, происходит посьшка команды разъединения DISC, за которой следует ответ DM, подтверж­ дающий разъединение. На рис. 5.7 уровень 3 на стороне пользователя отправ­ ляет уровню 2 примитив запроса освобождения DLJRELEASE, а уровень 2 формирует кадр разъединения, который передается через уровень 1 уровню 2 на стороне сети. При получении кадра разъединения уровнем 2 на стороне сети уровню 3 вьщается примитив индикации освобождения, а пользователю воз­ вращается кадр ненумерованного подтверждения. При получении кадра нену­ мерованного подтверждения уровнем 2 на стороне пользователя уровню 3 вы­ дается примитив подтверждения освобождения для завершения процедуры освобождения.

Передача неподтверждаемых сообщений. Управляющие кадры S и не­ нумерованные кадры и не содержат подполя N(S). Они принимаются получа­ телем, если получены без ошибок, и на них не отправляется подтверждение. Управляющие кадры содержат поле N(R) для подтверждения принятых информационньпс кадров.

Ненумерованные информационные кадры UI не содержат ни поля N(S), ни поля N(R), поскольку они передаются в вещательном режиме с TEI = 127, а возможность координировать порядковые номера передачи и приема для груп­ повых функций во всех терминалах, подключенных к одному S-интерфейсу, от­ сутствует.

Процедура неподтверждаемой передачи информации. Рассмотрим случай, когда необходима передача информации от функций уровня 3 на сторо-

334

5.4. Протоколы IVуровня стека TCP/IP

не сети к функциям уровня 3 в терминале пользователя. Функции уровня 3 на стороне сети передают к уровню 2 примитив запроса передачи данных без подтверждения DL_UNIT DATA. Уровень 2 формирует кадр ненумерованной информации (UI - Unnumbered Information), содержащий в информационном поле информацию, которую надо передать. Этот кадр и передается через уро­ вень 1 к функциям уровня 2 в терминале пользователя. Если необходима веща­ тельная (циркулярная) передача кадра всем терминалам, TEI в адресном поле присваивается значение 127. Если же обращение происходит к одному опреде­ ленному терминалу, т.е. необходим режим «точка-точка», тогда TEI присваи­ вается значение от О до 126, совпадающее с TEI, назначенным для этого тер­ минала, например, TEI = 7. При получении кадра UI терминалом пользователя информация, содержащаяся в информационном поле, доставляется из уровня 2 в уровень 3 с помощью примитива индикации приема данных без подтвержде­ ния.

При такой неподтверждаемой передаче информации в уровне 2 отсутствует процедура защиты от опшбок. Следовательно, решение о логическом восста­ новлении кадра в случае его потери или искажения возложено на функции уровня 3.

Рассмотрим подробнее использование управляющих кадров: кадр готовно­ сти к приему RR, сообщающий о готовности принимать информационные кад­ ры; кадр неготовности к приему RNR, сообщающий о том, что принимать ин­ формационные кадры временно нельзя, но прием управляющих кадров возможен; кадр отказа REJ, указывающий, что поступивший информационный кадр от­ брошен. На рис. 5.8 показаны несколько примеров, которые иллюстрируют ис­ пользование битов C/R, Р и F.

Терминал

Сеть

1-кадр [C/R=0, Р=0, N(S), N(R)] REJ-кадр [C/R=l, Р=0, N(R)=M] I-кадр [C/R=0, P=0, N(S)=M, N(R)]

I-кадр [C/R=<), P=0, N(S), N(R)] КЕТ-кадр [C/R=l, P=l, N(R)=M]

RR или RNR-кадр [C/R=l, F=l, N(R)] I-кадр [C/R=0, P=0, N(S)=M, N(R)]

RNR-Kaflp [C/R=l, P=0, N(R)]

RR или RNR-кадр [C/R=0, P=1, N(R)]

RR-кадр [C/R=0, F=1, N(R)=M]

Рис. 5.8. Примеры процедур контроля звена передачи данных

335

5. Сетевые протоколы

На рис. 5.8, а уровень 2 на стороне сети получил информационный кадр с нарушением порядка очередности и отбрасывает его с помощью команды REJ, в которой бит Р имеет значение О (подтверждения не требуется). N(R) = М указывает, что последний принятый информационный кадр имел N(S) = М - 1. Терминал повторяет передачу информационных кадров из своего буфера по­ вторной передачи, начиная с кадра, для которого N(S) = М.

На рис. 5.8, б рассмотрена та же ситуация, за исключением того, что в командном кадре REJ бит Р =1. Этим передается указание терминалу пользо­ вателя подтвердить кадр. Терминал пользователя сначала передает кадр от­ вета RR или RNR (C/R = 1, F = 1), а затем начинает повторную передачу ин­ формационных кадров.

На рис. 5.8, в сетевая сторона указьюает с помощью командного кадра RNR, что она не может принимать информационные кадры. Сторона пользователя приостанавливает передачу информационных кадров и запускает таймер. Если терминал получает кадр RR до срабатывания таймера, то он возобновляет передачу или повторную передачу информационных кадров. Если таймер сра­ ботал, а кадр RR не получен, терминал пользователя передает кадр команды (C/R = 1) с Р = 1. Этим дается указание сетевой стороне передать, в свою очередь, командный кадр. В данном примере сетевая сторона отвечает кад­ ром RR, указывая, что она готова снова принимать информационные кадры и что номер последнего принятого кадра N(S) = М - 1. Затем сторона терминала возобновляет передачу информационных кадров, начиная ее кадром с номером N(S) = М. Если ответом сетевой стороны будет кадр RNR, то сторона пользо­ вателя перезапустит свой таймер и снова будет ожидать кадр RR. Если сете­ вая сторона остается неготовой к приему после нескольких срабатываний тай­ мера, то сторона пользователя передает решение вопроса в более высокую инстанцию - к соответствующей функции сетевого уровня.

Процедуры управления TEI. Для протокола LAPD определены процеду­ ры управлершя TEI, т. е. процедуры его назначения, контроля и отмены. Для соединений «точка-точка» в терминале запоминается «свой» TEI и проверяет­ ся TEI в поле адреса принимаемых кадров, чтобы определить, не предназна­ чен ли кадр этому терминалу. Терминал также вводит свой TEI в адресные поля передаваемьпс им кадров.

Терминалы (ТЕ) подразделяются на терминалы с неавтоматическим и ав­ томатическим механизмом назначения TEI. ТЕ первого типа ориентированы на длительное подключение к одной цифровой абонентской линии, с постоянно активным физическим уровнем. Эти терминалы имеют ряд переключателей, положение которых определяет значение TEI. Переключатели устанавливает технический персонал при инсталляции ТЕ, и их положение не меняется, пока ТЕ подключен к этой цифровой абонентской линии. ТЕ такого типа имеют зна­ чения от О до 63.

336

5.4. Протоколы IVуровня стека TCP/IP

Автоматическое присвоение

8

7

6

5

4

3

2

1

TEI применяется в тех случаях,

1 0

| о

| о

| о

1 1

1 1

1 1

1 1 1

когда используются процедуры ак-

 

Идентификатор управления

Байт1

тивизации/деактивизации физичес­

 

 

 

Ссылочный

 

 

Байт 2

кого уровня интерфейса «пользова­

 

 

 

номер (Ri)

 

 

БайтЗ

тель-сеть» (при деактивизации

 

 

 

 

 

 

 

Тип сообщения

 

Байт 4

физического уровня TEI сбрасьша-

 

 

 

ется) или когда терминальное обо­

 

РЬцщкатор действия (Ai)

 

1 1Байт 5

рудование работает непостоянно.

 

 

 

 

 

 

 

 

Мешггь значение TEI вручную при

''"^- ^'^^ Сообщение управления TEI

каждом перемещении неудобно, поэтому для мобильных ТЕ применяется ав­ томатическое назначение TEI (в диапазоне 64-126), а также его проверка и отмена, для чего и используются упомянутые выше процедуры управления TEL Этими процедурами предусмотрены сообщения следующих типов:

Запрос ID. Сообщение передается мобильным ТЕ, когда необходимо, что­ бы сеть назначила для него TEI.

ID назначен. Это ответ сети на запрос ID. Он содержит назначенный TEI. Отказ в назначении ID. Это ответ сети, отвергающий запрос ID. Запрос проверки ID. Это команда от сети для проверки назначенного зна­

чения TEI.

Ответ проверки ID. Это ответ мобильного ТЕ на запрос-проверки ID. Отмена ID. Эта команда передается от сети к ТЕ, чтобы отменить назна­

ченный ранее TEL

Все сообщения передаются в кадрах UI с SAPI = 63. Информацио1шое поле кадров UI показано на рис. 5.9. Код в байте 1 указьгоает, что это сообщение управления TEI. Код типа сообщения находится в байте 4 (табл. 5.5). Сообще­ ние содержит параметры Ri (ссылочный номер) и Ai (индикатор действия).

Таблица 5,5. Коды типа сообщения

Тип сообщения

Направление

Код типа

Ссылочный

Индикатор

 

ТЕ сеть

сообщения

номер Ri

действия Ai

Запрос ID

\

0000 0001

0-65535

127

^

ID назначен

 

 

 

^

0000 0010

 

64-126

 

V

 

 

 

Отказ в значении ID

^

00000011

 

64-127

 

V

 

 

 

Запрос проверки ID

^

0000 0100

 

0-127

Ответ проверки ID

 

0000 0101

0-65535

0-126

Отмена ID

 

00000110

 

0-127

Верификация ID

^

00000111

 

0-126

 

 

 

 

337

Терминал

Сеть

Терминал

Запросвдентификатора(Ri, Ai)

Запрос проверки иденгафикатора (Ri, Ai)

идентификатор назначен (Ri, Ai)

 

>

К—

 

5. Сетевые протоколы

или

Ответ проверки идентификатора (Ri, Ai)

отказ в назначении

<

ндентификатора (Ri, Ai)

 

а

Рис. 5.10. Процедура управления TEI: а - назначение; б - проверка

Процедура назначения TEI дает возможность оборудова1шю пользователя, имеющему категорию «мобильный», получить от сети номер TEI, который можно использовать при последующих соединениях. Процедура назначения показана на рис. 5.10, а. Когда мобильный ТЕ подсоединяется к S-интерфейсу, он авто­ матически посылает запрос Ш. Поскольку терминальное оборудование не имеет TEI, то, чтобы идентифицировать себя, оно генерирует произвольный ссылоч­ ный номер (Ri). ТЕ может запросить сеть назначить для него конкретный TEI, указав этот TEI в поле Ai, или оставить право выбора TEI за сетью, поместив вэтополе Ai= 127.

Для каждой цифровой абонентской линии сеть поддерживает список мобиль­ ных TEI в диапазоне 64-126. При получении от некоторого S-интерфейса со­ общения «запрос ID» сеть обращается к соответствующему списку. Если она может назначить TEI, то по данной шине S-интерфейса в вещательном режиме передается сообщение «ГО назначен», в котором значение Ri копируется из сообщения «запросГО»,а назначенный ТЕХ помещается в поле Ai. Все ТЕ, подключенные к этой S-пшне, проверяют сообщение, но только ТЕ, который послал запрос, опознает свое Ri и воспринимает назначенный TEI. Такая про­ цедура позволяет двум или более ТЕ, подключенным к одной и той же S-шине, посылать запросыГОодновременно.

Если сеть не может удовлетворить запросГОиз-за того, что запрошенный TEI уже есть в списке назначенных для данного интерфейса или из-за того, что все TEI в диапазоне 64 - 126 уже назначены, она передает по S-шине этого интерфейса в вещательном режиме сообщение «отказ в назначенииГО»,снова копируя Ri из принятого запроса. После этого ТЕ информирует своего пользо­ вателя о том, что его запрос на назначение TEI бьш отвергнут.

Процедура проверки ТЕХ позволяет сети проконтролировать список мобиль­ ных ТЕХ, назначенных для конкретного интерфейса (рис. 5.10, б). Сеть переда­ ет этому интерфейсу в вещательном режиме сообщение «запрос проверки ГО», поместив в поле Ai проверяемый ТЕХ, а в поле Ri - нулевое значение. При этом сеть запускает таймер на 200 мс. Если среди подключенных к данному интер­ фейсу найдется ТЕ, имеющий ТЕХ, который совпадает с Ai, он отвечает сооб­ щением «ответ проверкиГО»,содержащим произвольно выбранное Ri и приня­ тое Ai.

338

5.4.Протоколы IVуровня стека TCP/IP

Внормальных условиях сеть принимает до срабатывания таймера одно сообщение «ответ проверки Ш», что указывает на наличие единственного ТЕ

сданным TEL Если таймер сработал, а ответ не получен, сеть повторяет зап­ рос проверки Ш и перезапускает таймер. Если таймер снова срабатьюает до получения ответа, сеть считает, что данный TEI больше не используется, уда­ ляет его из списка TEI, назначенных для данного интерфейса, и составляет отчет для обслуживающего персонала.

Вслучае получения сетью более одного ответа на «Запрос проверки Ш», это означает, что один и тот же TEI ошибочно присвоен более чем одному ТЕ. В этом случае сеть передает в вещательном режиме команду «отмена Ш» с указанием в поле Ai отменяемого TEI. Те терминалы, TEI которых согласуют­ ся с Ai, прекращают передачу и прием кадров и уведомляют своего пользова­ теля об отмене TEI. Если сеть решает, что значение TEI должно быть отмене­ но, вызывается процедура отмены. Сеть формирует кадр, содержащий тип сообщения и поле индикатора действия, где помещается значение TEI, которое должно быть отменено. Для уменьшения риска потери такой кадр посьшается дважды.

Протокол SLIP

Протокол SLIP (Serial Line IP) стал первым промышленным стандартом де-факто, который позволил устройствам, соединенным последовательным низ­ коскоростным интерфейсом связи, работать по протоколам TCP/IP. Этот Intemet-протокол разрешает в качестве линий связи использовать обьгшые те­ лефонные линии.

Протокол бьш создан в начале 80-х годов и согласно RFC-1055 впервые бьш включен в качестве средства доступа к ПР-сети в пакет фирмы 3COM - UNET. В 1984 г протокол SLIP бьш встроен Риком Адамсом (Rick Adams) в операци­ онную систему 4.2 Berkley Unix. Позднее SLIP бьш поддержан в других верси­ ях Unix и реализован в программном обеспечении для ПК.

Ввиду своей функциональной простоты, SLIP использовался и используется в основном на коммутируемых линиях связи, которые не характерны для от­ ветственных и скоростных сетевых соединений. Тем не менее, коммутируе­ мый канал отличается от некоммутируемого только более низким качеством и необходимостью выполнять процедуру вызова абонента, поэтому SLIP вполне применим и на вьщеленных каналах.

Протокол SLIP вьшолняет единственную функцию - он позволяет в потоке бит, которые поступают по выделенному (или коммутируемому) каналу, рас­ познать начало и конец IP-пакета. Другие протоколы сетевого уровня SLIP не поддерживает.

Программное обеспечение, реализующее работу с протоколом SLIP, прини­ мает символы, приходящие с устройства последовательной передачи данных (модема, последовательного порта и т. д.); рассматривает и толкует их как составляющие IP-пакета; укладьшает полученные данные в полнокровный нор­ мальный IP-пакет и передает этот пакет далее ~ соответствующей програм-

339