Comment # 30
on bug 9427
from Guy Harris
(In reply to comment #27)
> Next is to check the format of IETF Frame-Relay.
Frame Relay is specified by ITU-T Recommendations, not by the IETF. See ITU-T
Recommendation Q.922:
http://www.itu.int/rec/T-REC-Q.922-199202-I/en
What the IETF specifies is a way to transmit IP packets, and packets for other
protools, *over* Frame Relay:
https://tools.ietf.org/html/rfc1490
See
https://en.wikipedia.org/wiki/Frame_Relay#Protocol_data_unit
for some information about Frame Relay packets. That section starts with:
Each Frame Relay Protocol data unit (PDU) consists of the following fields:
1. Flag Field. The flag is used to perform high-level data link
synchronization which indicates the beginning and end of the frame with the
unique pattern 01111110. To ensure that the 01111110 pattern does not appear
somewhere inside the frame, bit stuffing and destuffing procedures are used.
"bit stuffing and destuffing" links to
https://en.wikipedia.org/wiki/Bit_stuffing
which gives more details.
That's what I'm referring to when I speak of "HDLC bit-stuffing or
byte-stuffing". It actually dates back to SDLC:
https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control
which was the basis for HDLC:
https://en.wikipedia.org/wiki/High-Level_Data_Link_Control
which was the basis for several link-layer protocols, such as X.25's layer 2
protocol, LAPB:
https://en.wikipedia.org/wiki/LAPB
and ISDN's LAPD layer-2 protocol for the D channel:
https://en.wikipedia.org/wiki/Link_Access_Procedures,_D_channel
and also influenced the IEEE 802.2 protocol:
https://en.wikipedia.org/wiki/IEEE_802.2
and PPP:
https://en.wikipedia.org/wiki/Point-to-point_protocol
PPP separates the "framing" part of HDLC from the "packet header" part; PPP
specifies a header that looks similar to the address field/control field HDLC
header, and also specifies "PPP in HDLC-like framing", which uses HDLC's
framing, doing either bit-stuffing or byte-stuffing, to delimit PPP packets in
a bit or byte stream.
Frame Relay *also* uses HDLC's framing, but doesn't use HDLC's header; instead,
it uses headers that include an address field but *not* a control field.
> However, may I suggest the next development step be to simply decode to the
> Frame-Relay level by following the boundaries of the T1 slots/channels
> Guisyus indicated.
You may suggest it, but, when Frame Relay is carried over a bit stream like a
T1, the Frame Relay frame boundaries are, as far as I know, denoted by
HDLC-like framing; they have, as far as I know, *nothing* to do with
fixed-length T1 frames, in which case you cannot, in fact, decode Frame Relay
packets by following the boundaries of T1 frames.
You must, instead, take those frames, and process the bits in them, detecting
framing flags (a bit sequence of 01111110), removing the 0 bits stuffed into
the bits of the Frame Relay frame (in order to allow a Frame Relay frame to
contain an octet with the value 0x7E, every time there are 5 1's in the bit
sequence of a frame, a 0 bit is inserted), and taking the data between two
framing flags, once the extra 0 bits are removed, and hand them to the Frame
Relay dissector.
You are receiving this mail because:
- You are watching all bug changes.