📄 rfc1490.txt
字号:
Note that in bridge 802.6 PDUs, there is only one choice for the PID
value, since the presence of a CRC-32 is indicated by the CIB bit in
the header of the MAC frame.
The Common Protocol Data Unit (CPDU) Header and Trailer are conveyed
to allow pipelining at the egress bridge to an 802.6 subnetwork.
Specifically, the CPDU Header contains the BAsize field, which
contains the length of the PDU. If this field is not available to
the egress 802.6 bridge, then that bridge cannot begin to transmit
the segmented PDU until it has received the entire PDU, calculated
the length, and inserted the length into the BAsize field. If the
field is available, the egress 802.6 bridge can extract the length
from the BAsize field of the Common PDU Header, insert it into the
corresponding field of the first segment, and immediately transmit
the segment onto the 802.6 subnetwork. Thus, the bridge can begin
transmitting the 802.6 PDU before it has received the complete PDU.
One should note that the Common PDU Header and Trailer of the
encapsulated frame should not be simply copied to the outgoing 802.6
Bradley, Brown & Malis [Page 12]
RFC 1490 Multiprotocol over Frame Relay July 1993
subnetwork because the encapsulated BEtag value may conflict with the
previous BEtag value transmitted by that bridge.
Format of BPDU Frame
+-------------------------------+
| Q.922 Address |
+-------------------------------+
| Control 0x03 |
+-------------------------------+
| PAD 0x00 |
+-------------------------------+
| NLPID 0x80 |
+-------------------------------+
| OUI 0x00-80-C2 |
+-------------------------------+
| PID 0x00-0E |
+-------------------------------+
| |
| BPDU as defined by |
| 802.1(d) or 802.1(g)[12] |
| |
+-------------------------------+
4. Data Link Layer Parameter Negotiation
Frame Relay stations may choose to support the Exchange
Identification (XID) specified in Appendix III of Q.922 [1]. This
XID exchange allows the following parameters to be negotiated at the
initialization of a Frame Relay circuit: maximum frame size N201,
retransmission timer T200, and the maximum number of outstanding
Information (I) frames K.
A station may indicate its unwillingness to support acknowledged mode
multiple frame operation by specifying a value of zero for the
maximum window size, K.
If this exchange is not used, these values must be statically
configured by mutual agreement of Data Link Connection (DLC)
endpoints, or must be defaulted to the values specified in Section
5.9 of Q.922:
Bradley, Brown & Malis [Page 13]
RFC 1490 Multiprotocol over Frame Relay July 1993
N201: 260 octets
K: 3 for a 16 Kbps link,
7 for a 64 Kbps link,
32 for a 384 Kbps link,
40 for a 1.536 Mbps or above link
T200: 1.5 seconds [see Q.922 for further details]
If a station supporting XID receives an XID frame, it shall respond
with an XID response. In processing an XID, if the remote maximum
frame size is smaller than the local maximum, the local system shall
reduce the maximum size it uses over this DLC to the remotely
specified value. Note that this shall be done before generating a
response XID.
The following diagram describes the use of XID to specify non-use of
acknowledged mode multiple frame operation.
Bradley, Brown & Malis [Page 14]
RFC 1490 Multiprotocol over Frame Relay July 1993
Non-use of Acknowledged Mode Multiple Frame Operation
+---------------+
| Address | (2,3 or 4 octets)
| |
+---------------+
| Control 0xAF |
+---------------+
| format 0x82 |
+---------------+
| Group ID 0x80 |
+---------------+
| Group Length | (2 octets)
| 0x00-0E |
+---------------+
| 0x05 | PI = Frame Size (transmit)
+---------------+
| 0x02 | PL = 2
+---------------+
| Maximum | (2 octets)
| Frame Size |
+---------------+
| 0x06 | PI = Frame Size (receive)
+---------------+
| 0x02 | PL = 2
+---------------+
| Maximum | (2 octets)
| Frame Size |
+---------------+
| 0x07 | PI = Window Size
+---------------+
| 0x01 | PL = 1
+---------------+
| 0x00 |
+---------------+
| 0x09 | PI = Retransmission Timer
+---------------+
| 0x01 | PL = 1
+---------------+
| 0x00 |
+---------------+
| FCS | (2 octets)
| |
+---------------+
6. Fragmentation Issues
Fragmentation allows the exchange of packets that are greater than
the maximum frame size supported by the underlying network. In the
Bradley, Brown & Malis [Page 15]
RFC 1490 Multiprotocol over Frame Relay July 1993
case of Frame Relay, the network may support a maximum frame size as
small as 262 octets. Because of this small maximum size, it is
recommended, but not required, to support fragmentation and
reassembly.
Unlike IP fragmentation procedures, the scope of Frame Relay
fragmentation procedure is limited to the boundary (or DTEs) of the
Frame Relay network.
The general format of fragmented packets is the same as any other
encapsulated protocol. The most significant difference being that
the fragmented packet will contain the encapsulation header. That
is, a packet is first encapsulated (with the exception of the address
and control fields) as defined above. Large packets are then broken
up into frames appropriate for the given Frame Relay network and are
encapsulated using the Frame Relay fragmentation format. In this
way, a station receiving fragments may reassemble them and then put
the reassembled packet through the same processing path as a packet
that had not been fragmented.
Within Frame Relay fragments are encapsulated using the SNAP format
with an OUI of 0x00-80-C2 and a PID of 0x00-0D. Individual fragments
will, therefore, have the following format:
+---------------+---------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | pad 0x00 |
+---------------+---------------+
| NLPID 0x80 | OUI 0x00 |
+---------------+---------------+
| OUI 0x80-C2 |
+---------------+---------------+
| PID 0x00-0D |
+---------------+---------------+
| sequence number |
+-+-------+-----+---------------+
|F| RSVD |offset |
+-+-------+-----+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
| FCS |
+---------------+---------------+
The sequence field is a two octet identifier that is incremented
Bradley, Brown & Malis [Page 16]
RFC 1490 Multiprotocol over Frame Relay July 1993
every time a new complete message is fragmented. It allows detection
of lost frames and is set to a random value at initialization.
The reserved field is 4 bits long and is not currently defined. It
must be set to 0.
The final bit is a one bit field set to 1 on the last fragment and
set to 0 for all other fragments.
The offset field is an 11 bit value representing the logical offset
of this fragment in bytes divided by 32. The first fragment must have
an offset of zero.
The following figure shows how a large IP datagram is fragmented over
Frame Relay. In this example, the complete datagram is fragmented
into two Frame Relay frames.
Bradley, Brown & Malis [Page 17]
RFC 1490 Multiprotocol over Frame Relay July 1993
Frame Relay Fragmentation Example
+-----------+-----------+
| Q.922 Address |
+-----------+-----------+
| Ctrl 0x03 | pad 0x00 |
+-----------+-----------+
|NLPID 0x80 | OUI 0x00 |
+-----------+-----------+
| OUI 0x80-C2 |
+-----------+-----------+ +-----------+-----------+
|ctrl 0x03 |NLPID 0xCC | | PID 0x00-0D |
+-----------+-----------+ +-----------+-----------+
| | | sequence number n |
| | +-+------+--+-----------+
| | |0| RSVD |offset (0) |
| | +-+------+--+-----------+
| | | ctrl 0x03 |NLPID 0xCC |
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -