📄 rfc2427.txt
字号:
DLCI (decimal) Q.922 address (hex)
50 0x0C21
60 0x0CC1
70 0x1061
80 0x1401
For authoritative description of the correlation between DLCI and
Q.922 [1] addresses, the reader should consult that specification.
A summary of the correlation is included here for convenience. The
translation between DLCI and Q.922 address is based on a two byte
address length using the Q.922 encoding format. The format is:
8 7 6 5 4 3 2 1
+------------------------+---+--+
| DLCI (high order) |C/R|EA|
+--------------+----+----+---+--+
| DLCI (lower) |FECN|BECN|DE |EA|
+--------------+----+----+---+--+
For ARP and its variants, the FECN, BECN, C/R and DE bits are
assumed to be 0.
When an ARP message reaches a destination, all hardware addresses
will be invalid. The address found in the frame header will,
however, be correct. Though it does violate the purity of layering,
Frame Relay may use the address in the header as the sender hardware
address. It should also be noted that the target hardware address,
in both ARP request and reply, will also be invalid. This should not
cause problems since ARP does not rely on these fields and in fact,
an implementation may zero fill or ignore the target hardware address
field entirely.
As an example of how this address replacement scheme may work, refer
to figure 1. If station A (protocol address pA) wished to resolve
the address of station B (protocol address pB), it would format an
ARP request with the following values:
ARP request from A
ar$op 1 (request)
ar$sha unknown
ar$spa pA
ar$tha undefined
ar$tpa pB
Brown & Malis Standards Track [Page 18]
RFC 2427 Multiprotocol over Frame Relay September 1998
Because station A will not have a source address associated with it,
the source hardware address field is not valid. Therefore, when the
ARP packet is received, it must extract the correct address from the
Frame Relay header and place it in the source hardware address field.
This way, the ARP request from A will become:
ARP request from A as modified by B
ar$op 1 (request)
ar$sha 0x1061 (DLCI 70) from Frame Relay header
ar$spa pA
ar$tha undefined
ar$tpa pB
Station B's ARP will then be able to store station A's protocol
address and Q.922 address association correctly. Next, station B
will form a reply message. Many implementations simply place the
source addresses from the ARP request into the target addresses and
then fills in the source addresses with its addresses. In this case,
the ARP response would be:
ARP response from B
ar$op 2 (response)
ar$sha unknown
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA
Again, the source hardware address is unknown and when the response
is received, station A will extract the address from the Frame Relay
header and place it in the source hardware address field. Therefore,
the response will become:
ARP response from B as modified by A
ar$op 2 (response)
ar$sha 0x0C21 (DLCI 50)
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA
Station A will now correctly recognize station B having protocol
address pB associated with Q.922 address 0x0C21 (DLCI 50).
Reverse ARP (RARP) [8] works in exactly the same way. Still using
figure 1, if we assume station C is an address server, the following
RARP exchanges will occur:
Brown & Malis Standards Track [Page 19]
RFC 2427 Multiprotocol over Frame Relay September 1998
RARP request from A RARP request as modified by 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
Station C will then look up the protocol address corresponding to
Q.922 address 0x1401 (DLCI 80) and send the RARP response.
RARP response from C RARP response as modified by 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
This means that the Frame Relay interface must only intervene in the
processing of incoming packets.
In the absence of suitable multicast, ARP may still be implemented.
To do this, the end station simply sends a copy of the ARP request
through each relevant DLC, thereby simulating a broadcast.
The use of multicast addresses in a Frame Relay environment, as
specified by [19], is presently being considered by Frame Relay
providers. In time, multicast addressing may become useful in
sending ARP requests and other "broadcast" messages.
Because of the inefficiencies of emulating broadcasting in a Frame
Relay environment, a new address resolution variation was developed.
It is called Inverse ARP [11] and describes a method for resolving a
protocol address when the hardware address is already known. In
Frame Relay's case, the known hardware address is the DLCI. Support
for Inverse ARP is not required to implement this specification, but
it has proven useful for Frame Relay interface autoconfiguration.
See [11] for its description and an example of its use with Frame
Relay.
Stations must be able to map more than one IP address in the same IP
subnet (CIDR address prefix) to a particular DLCI on a Frame Relay
interface. This need arises from applications such as remote access,
where servers must act as ARP proxies for many dial-in clients, each
assigned a unique IP address while sharing bandwidth on the same DLC.
The dynamic nature of such applications result in frequent address
association changes with no affect on the DLC's status as reported by
Frame Relay PVC Status Signaling.
Brown & Malis Standards Track [Page 20]
RFC 2427 Multiprotocol over Frame Relay September 1998
As with any other interface that utilizes ARP, stations may learn the
associations between IP addresses and DLCIs by processing unsolicited
("gratuitous") ARP requests that arrive on the DLC. If one station
(perhaps a terminal server or remote access server) wishes to inform
its peer station on the other end of a Frame Relay DLC of a new
association between an IP address and that PVC, it should send an
unsolicited ARP request with the source IP address equal to the
destination IP address, and both set to the new IP address being used
on the DLC. This allows a station to "announce" new client
connections on a particular DLCI. The receiving station must store
the new association, and remove any old existing association, if
necessary, from any other DLCI on the interface.
7. IP over Frame Relay
Internet Protocol [9] (IP) datagrams sent over a Frame Relay network
conform to the encapsulation described previously. Within this
context, IP could be encapsulated in two different ways.
1. NLPID value indicating IP
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | NLPID 0xCC |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
Brown & Malis Standards Track [Page 21]
RFC 2427 Multiprotocol over Frame Relay September 1998
2. NLPID value indicating SNAP
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID 0x80 | | SNAP Header
+-----------------------+ OUI = 0x00-00-00 + Indicating
| | IP
+-----------------------+-----------------------+
| PID 0x0800 |
+-----------------------+-----------------------+
| IP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
Although both of these encapsulations are supported under the given
definitions, it is advantageous to select only one method as the
appropriate mechanism for encapsulating IP data. Therefore, IP data
shall be encapsulated using the NLPID value of 0xCC indicating IP as
shown in option 1 above. This (option 1) is more efficient in
transmission (48 fewer bits), and is consistent with the
encapsulation of IP in X.25.
8. Other Protocols over Frame Relay
As with IP encapsulation, there are alternate ways to transmit
various protocols within the scope of this definition. To eliminate
the conflicts, the SNAP encapsulation is only used if no NLPID value
is defined for the given protocol.
As an example of how this works, ISO CLNP has a NLPID defined (0x81).
Therefore, the NLPID field will indicate ISO CLNP and the data packet
will follow immediately. The frame would be as follows:
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | NLPID 0x81 (CLNP) |
+----------------------+----------------------+
| remainder of CLNP packet |
| . |
| . |
+---------------------------------------------+
Brown & Malis Standards Track [Page 22]
RFC 2427 Multiprotocol over Frame Relay September 1998
In this example, the NLPID is used to identify the data packet as
CLNP. It is also considered part of the CLNP packet and as such, the
NLPID should not be removed before being sent to the upper layers for
processing. The NLPID is not duplicated.
Other protocols, such as IPX, do not have a NLPID value defined. As
mentioned above, IPX would be encapsulated using the SNAP header. In
this case, the frame would be as follows:
+---------------------------------------------+
| Q.922 Address |
+----------------------+----------------------+
| Control (UI) 0x03 | pad 0x00 |
+----------------------+----------------------+
| NLPID 0x80 (SNAP) | OUI - 0x00 00 00 |
+----------------------+ |
| |
+---------------------------------------------+
| PID 0x8137 |
+---------------------------------------------+
| IPX packet |
| . |
| . |
+---------------------------------------------+
9. Bridging Model for Frame Relay
The model for bridging in a Frame Relay network is identical to the
model for remote bridging as described in IEEE P802.1g "Remote MAC
Bridging" [13] and supports the concept of "Virtual Ports". Remote
bridges with LAN ports receive and transmit MAC frames to and from
the LANs to which they are attached. They may also receive and
transmit MAC frames through virtual ports to and from other remote
bridges. A virtual port may represent an abstraction of a remote
bridge's point of access to one, two or more other remote bridges.
Remote Bridges are statically configured as members of a remote
bridge group by management. All members of a remote bridge group are
connected by one or more virtual ports. The set of remote MAC bridges
in a remote bridge group provides actual or *potential* MAC layer
interconnection between a set of LANs and other remote bridge groups
to which the remote bridges attach.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -