RFC: 2427
Оригинал: Multiprotocol Interconnect over Frame Relay
Предыдущие версии: RFC 1294, RFC 1490
Категория: Стандарт Интернета
Дата публикации:
Авторы: ,
Перевод: Николай Малых

Значения 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 (шестн.)
500x0C21
600x0CC1
700x1061
800x1401

Официальные сведения о соотношениях между 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 (это имитирует широковещательную рассылку).

2007 - 2017 © Русские переводы RFC, IETF, ISOC.