Значения DLCI, содержащиеся в заголовках Frame Relay, изменяются при передаче кадров через сеть. Когда пакет приходит к получателю, идентификатор DLCI может не совпадать со значением, установленным передавшей пакет станцией. Например, когда станция A (рисунок 1) передает сообщение станции B, она будет устанавливать в заголовке Frame Relay значение DLCI=50. Когда станция B получит это сообщение, значение DLCI будет изменено сетью (в приведенном примере DLCI=70).
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <--- сеть Frame Relay
~~~~~~~~~~~~~~~~
80
|
+-----+
| |
| C |
| |
+-----+
Рисунок 1
Линии на рисунке 1 представляют виртуальные соединения (DLC), числа показывают локальные идентификаторы DLCI для каждого соединения.
Преобразование DLCI в адреса Q.922 для рисунка 1:
| DLCI (дес.) | адрес Q.922 (шестн.) |
| 50 | 0x0C21 |
| 60 | 0x0CC1 |
| 70 | 0x1061 |
| 80 | 0x1401 |
Официальные сведения о соотношениях между DLCI и адресами Q.922 следует искать в спецификации Q.922 [1]. Здесь мы лишь напомним о том, что преобразование между DLCI и адресами Q.922 основано на 2-байтовой длине адреса с использованием формата кодирования Q.922, показанного ниже.
8 7 6 5 4 3 2 1 +------------------------+---+--+ | DLCI (high order) |C/R|EA| +--------------+----+----+---+--+ | DLCI (lower) |FECN|BECN|DE |EA| +--------------+----+----+---+--+
Для ARP и вариантов этого протокола значения битовых полей FECN, BECN, C/R и DE предполагаются нулевыми.
Когда сообщение ARP приходит к адресату, все аппаратные адреса в нем являются некорректными. Однако, адреса, определенные из заголовков кадров, остаются верными. Хотя это и нарушает чистоту деления по уровням, Frame Relay может использовать адреса из заголовков в качестве аппаратных адресов отправителей. Следует отметить, что аппаратные адреса получателей в запросах и откликах ARP также являются некорректными. Это не должно вызывать сложностей, поскольку ARP не использует эти поля и, фактически, для них можно задавать нулевые значения или просто игнорировать.
В качестве примера работы схемы замены адресов снова рассмотрим рисунок 1. Если станция A (протокольный адрес pA) хочет преобразовать адрес станции B (протокольный адрес pB), она должна сформировать запрос ARP со следующими значениями:
Запрос ARP от станции A
ar$op 1 (запрос)
ar$sha неизвестен
ar$spa pA
ar$tha не определен
ar$tpa pB
Поскольку станция A не имеет связанного с ней адреса отправителя, поле аппаратного адреса отправителя является некорректным. Следовательно, при получении запроса ARP корректный аппаратный адрес должен быть определен из заголовка Frame Relay и помещен в поле аппаратного адреса отправителя. В результате этого запрос ARP принимает форму:
Запрос ARP от станции A после изменения станцией B
ar$op 1 (запрос)
ar$sha 0x1061 (DLCI 70) из заголовка Frame Relay
ar$spa pA
ar$tha не определен
ar$tpa pB
Протокол ARP на станции B может сейчас корректно сохранить протокольный адрес станции A и ее адрес Q.922 в таблице ARP. После этого станция B будет формировать отклик. Многие разработчики просто помещают адрес отправителя из запроса ARP в поле адреса получателя, а в поле адреса отправителя указывают свой адрес. В этом случае отклик ARP будет иметь вид:
Отклик ARP от станции B
ar$op 2 (отклик)
ar$sha неизвестен
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA
Аппаратный адрес отправителя по-прежнему остается неизвестным и при получении отклика станция A должна получить адрес из заголовка Frame Relay и поместить его в поле аппаратного адреса отправителя. После этой операции отклик имеет форму:
Отклик ARP от станции B после изменения его станцией A
ar$op 2 (отклик)
ar$sha 0x0C21 (DLCI 50)
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA
Станция A сейчас может корректно распознавать станцию B по ее протокольному адресу pB, связанному с адресом Q.922 — 0x0C21 (DLCI 50).
Обратное преобразование адресов (RARP) [RFC903] будет выполняться по аналогии с прямым. Возвращаясь к рисунку 1, предположим, что станция C является сервером адресов. В этом случае произойдет следующий обмен пакетами RARP:
RARP-запрос от A Запрос RARP после изменения станцией C
ar$op 3 (RARP request) ar$op 3 (RARP request)
ar$sha unknown ar$sha 0x1401 (DLCI 80)
ar$spa undefined ar$spa undefined
ar$tha 0x0CC1 (DLCI 60) ar$tha 0x0CC1 (DLCI 60)
ar$tpa pC ar$tpa pC
Станция C будет искать протокольный адрес, соответствующий адресу Q.922 0x1401 (DLCI 80), и передавать отклик RARP.
RARP-отклик от C Отклик RARP после изменения станцией A
ar$op 4 (RARP response) ar$op 4 (RARP response)
ar$sha unknown ar$sha 0x0CC1 (DLCI 60)
ar$spa pC ar$spa pC
ar$tha 0x1401 (DLCI 80) ar$tha 0x1401 (DLCI 80)
ar$tpa pA ar$tpa pA
Это означает, что интерфейс Frame Relay должен включаться только в обработку входящих пакетов. При отсутствии подходящего механизма групповой адресации (multicast) процедуру ARP все равно можно реализовать. Для решения этой задачи конечная станция просто должна передать копию запроса ARP с использованием всех имеющих отношение к делу DLC (это имитирует широковещательную рассылку).