📄 rfc1490.txt
字号:
| | +-----------+-----------+
| | | first m bytes of |
| large IP datagram | ... | IP datagram |
| | | |
| | +-----------+-----------+
| | | FCS |
| | +-----------+-----------+
| |
| | +-----------+-----------+
| | | Q.922 Address |
| | +-----------+-----------+
| | | Ctrl 0x03 | pad 0x00 |
+-----------+-----------+ +-----------+-----------+
|NLPID 0x80 | OUI 0x00 |
+-----------+-----------+
| OUI 0x80-C2 |
+-----------+-----------+
| PID 0x00-0D |
+-----------+-----------+
| sequence number n |
+-+------+--+-----------+
|1| RSVD |offset (m/32) |
+-+------+--+-----------+
| remainder of IP |
| datagram |
+-----------+-----------+
| FCS |
+-----------+-----------+
Fragments must be sent in order starting with a zero offset and
ending with the final fragment. These fragments must not be
Bradley, Brown & Malis [Page 18]
RFC 1490 Multiprotocol over Frame Relay July 1993
interrupted with other packets or information intended for the same
DLC. An end station must be able to re-assemble up to 2K octets and
is suggested to support up to 8K octet re-assembly. If at any time
during this re-assembly process, a fragment is corrupted or a
fragment is missing, the entire message is dropped. The upper layer
protocol is responsible for any retransmission in this case. Note
that there is no reassembly timer, nor is one needed. This is
because the Frame Relay service is required to deliver frames in
order.
This fragmentation algorithm is not intended to reliably handle all
possible failure conditions. As with IP fragmentation, there is a
small possibility of reassembly error and delivery of an erroneous
packet. Inclusion of a higher layer checksum greatly reduces this
risk.
7. Address Resolution
There are situations in which a Frame Relay station may wish to
dynamically resolve a protocol address. Address resolution may be
accomplished using the standard Address Resolution Protocol (ARP) [6]
encapsulated within a SNAP encoded Frame Relay packet as follows:
+-----------------------+-----------------------+
| Q.922 Address |
+-----------------------+-----------------------+
| Control (UI) 0x03 | pad 0x00 |
+-----------------------+-----------------------+
| NLPID = 0x80 | | SNAP Header
+-----------------------+ OUI = 0x00-00-00 + Indicating
| | ARP
+-----------------------+-----------------------+
| PID = 0x0806 |
+-----------------------+-----------------------+
| ARP packet |
| . |
| . |
| . |
+-----------------------+-----------------------+
Where the ARP packet has the following format and values:
Data:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type
ar$hln 8 bits Octet length of hardware address (n)
Bradley, Brown & Malis [Page 19]
RFC 1490 Multiprotocol over Frame Relay July 1993
ar$pln 8 bits Octet length of protocol address (m)
ar$op 16 bits Operation code (request or reply)
ar$sha noctets source hardware address
ar$spa moctets source protocol address
ar$tha noctets target hardware address
ar$tpa moctets target protocol address
ar$hrd - assigned to Frame Relay is 15 decimal
(0x000F) [7].
ar$pro - see assigned numbers for protocol ID number for
the protocol using ARP. (IP is 0x0800).
ar$hln - length in bytes of the address field (2, 3, or 4)
ar$pln - protocol address length is dependent on the
protocol (ar$pro) (for IP ar$pln is 4).
ar$op - 1 for request and 2 for reply.
ar$sha - Q.922 source hardware address, with C/R, FECN,
BECN, and DE set to zero.
ar$tha - Q.922 target hardware address, with C/R, FECN,
BECN, and DE set to zero.
Because DLCIs within most Frame Relay networks have only local
significance, an end station will not have a specific DLCI assigned
to itself. Therefore, such a station does not have an address to put
into the ARP request or reply. Fortunately, the Frame Relay network
does provide a method for obtaining the correct DLCIs. The solution
proposed for the locally addressed Frame Relay network below will
work equally well for a network where DLCIs have global significance.
The DLCI carried within the Frame Relay header is modified as it
traverses the network. When the packet arrives at its destination,
the DLCI has been set to the value that, from the standpoint of the
receiving station, corresponds to the sending station. For example,
in figure 1 below, if station A were to send a message to station B,
it would place DLCI 50 in the Frame Relay header. When station B
received this message, however, the DLCI would have been modified by
the network and would appear to B as DLCI 70.
Bradley, Brown & Malis [Page 20]
RFC 1490 Multiprotocol over Frame Relay July 1993
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame Relay
~~~~~~~~~~~~~~~~ network
80
|
+-----+
| |
| C |
| |
+-----+
Figure 1
Lines between stations represent data link connections (DLCs).
The numbers indicate the local DLCI associated with each
connection.
DLCI to Q.922 Address Table for Figure 1
DLCI (decimal) Q.922 address (hex)
50 0x0C21
60 0x0CC1
70 0x1061
80 0x1401
If you know about frame relay, you should understand the
correlation between DLCI and Q.922 address. For the uninitiated,
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
Bradley, Brown & Malis [Page 21]
RFC 1490 Multiprotocol over Frame Relay July 1993
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
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
Bradley, Brown & Malis [Page 22]
RFC 1490 Multiprotocol over Frame Relay July 1993
Again, the source hardware address is unknown and when the request 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] will work in exactly the same way. Still
using figure 1, if we assume station C is an address server, the
following RARP exchanges will occur:
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 is
presently under study by Frame Relay providers. At such time that
the issues surrounding multicasting are resolved, multicast
Bradley, Brown & Malis [Page 23]
RFC 1490 Multiprotocol over Frame Relay July 1993
addressing may become useful in sending ARP requests and other
"broadcast" messages.
Because of the inefficiencies of 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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -