| |
EA2CMN > AX25 29.09.94 06:34l 217 Lines 7913 Bytes #-11689 (0) @ EU
BID : 41772_EA2CMN
Read: DJ9SS DH5MBP DB9CP DL2NAT DK9OS DL1GJI DG6MAY DG2MNF DG1MTG GUEST
Subj: AX.25 Doc : Part 1/9
Path: DB0KCP<DB0AAB<DB0LNA<DB0RGB<DB0LAN<DB0ABH<DB0SRS<DB0SIF<DB0AIS<DB0HOM<
F6KVE<F6KLZ<F6CBL<F6KDC<F1HAQ<F6FBB<F5JGK<EB2CYQ<EA2CMO<EA2CMN
Sent: 940927/1428Z @:EA2CMN.EAZ.ESP.EU #:41772 [Zaragoza] Bid:41772_EA2CMN FBB5
De : EA2CMN@EA2CMN.EAZ.ESP.EU
A : AX25@EU
AX25.DOC PART 1/9
AX.25 Amateur Packet-Radio Link-Layer Protocol
Version 2.0 October 1984
2. AX.25 Link-Layer Protocol Specification
2.1 Scope and Field of Operation
In order to provide a mechanism for the reliable
transport of data between two signaling terminals, it is
necessary to define a protocol that can accept and deliver data
over a variety of types of communications links. The AX.25 Link-
Layer Protocol is designed to provide this service, independent
of any other level that may or may not exist.
This protocol conforms to ISO Recommendations 3309, 4335
(including DAD 1&2) and 6256 high-level data link control (HDLC)
and uses some terminology found in these documents. It also
conforms with ANSI X3.66, which describes ADCCP, balanced mode.
This protocol follows, in principle, the CCITT X.25
Recommendation, with the exception of an extended address field
and the addition of the Unnumbered Information (UI) frame. It
also follows the principles of CCITT Recommendation Q.921 (LAPD)
in the use of multiple links, distinguished by the address field,
on a single shared channel.
As defined, this protocol will work equally well in
either half- or full-duplex Amateur Radio environments.
This protocol has been designed to work equally well for
direct connections between two individual amateur packet-radio
stations or an individual station and a multiport controller.
This protocol allows for the establishment of more than
one link-layer connection per device, if the device is so
capable.
This protocol does not prohibit self-connections. A
self-connection is considered to be when a device establishes a
link to itself using its own address for both the source and
destination of the frame.
Most link-layer protocols assume that one primary (or
master) device (generally called a DCE, or data circuit-
terminating equipment) is connected to one or more secondary (or
slave) device(s) (usually called a DTE, or data terminating
equipment). This type of unbalanced operation is not practical
in a shared-RF Amateur Radio environment. Instead, AX.25 assumes
that both ends of the link are of the same class, thereby
eliminating the two different classes of devices. The term DXE
is used in this protocol specification to describe the balanced
type of device found in amateur packet radio.
2.2 Frame Structure
Link layer packet radio transmissions are sent in small
blocks of data, called frames. Each frame is made up of several
smaller groups, called fields. Fig.1 shows the three basic types
of frames. Note that the first bit to be transmitted is on the
left side.
First
Bit Sent
Flag Address Control FCS Flag
01111110 112/560 Bits 8 Bits 16 Bits 01111110
Fig. 1A -- U and S frame construction
First
Bit Sent
Flag Address Control PID Info. FCS Flag
01111110 112/560 Bits 8 Bits 8 Bits N*8 Bits 16 Bits 01111110
Fig. 1B -- Information frame construction
Each field is made up of an integral number of octets (or
bytes), and serves a specific function as outlined below.
2.2.1 Flag Field
The flag field is one octet long. Since the flag is used
to delimit frames, it occurs at both the beginning and end of
each frame. Two frames may share one flag, which would denote
the end of the first frame, and the start of the next frame. A
flag consists of a zero followed by six ones followed by another
zero, or 01111110 (7E hex). As a result of bit stuffing (see
2.2.6, below), this sequence is not allowed to occur anywhere
else inside a complete frame.
2.2.2 Address Field
The address field is used to identify both the source of
the frame and its destination. In addition, the address field
contains the command/response information and faciities for
level 2 repeater operation.
The encodng of the address field is described in 2.2.13.
2.2.3 Control Field
The control field is used to identify the type of frame
being passed and control several attributes of the level 2
connection. It is one octet in length, and its encoding is
discussed in 2.3.2.1, below.
2.2.4 PID Field
The Protocol Identifier (PID) field shall appear in
information frames (I and UI) only. It identifies what kind of
layer 3 protocol, if any, is in use.
The PID itself is not included as part of the octet count
of the information field. The encoding of the PID is as follows:
M L
S S
B B
yy01yyyy AX.25 layer 3 implemented.
yy10yyyy AX.25 layer 3 implemented.
11001100 Internet Protocol datagram layer 3 implemented.
11001101 Address resolution protocol layer 3 implemented.
11110000 No layer 3 implemented.
11111111 Escape character. Next octet contains more Level 3
protocol information.
Where:
A y indicates all combinations used.
Note:
All forms of yy11yyyy and yy00yyyy other than those
listed above are reserved at this time for future level 3
protocols. The assignment of these formats is up to amateur
agreement. It is recommended that the creators of level 3
protocols contact the ARRL Ad Hoc Committee on Digital
Communications for suggested encodings.
2.2.5 Information Field
The information field is used to convey user data from
one end of the link to the other. I fields are allowed in only
three types of frames: the I frame, the UI frame, and the FRMR
frame. The I field can be up to 256 octets long, and shall
contain an integral number of octets. These constraints apply
prior to the insertion of zero bits as specified in 2.2.6, below.
Any information in the I field shall be passed along the link
transparently, except for the zero-bit insertion (see 2.2.6)
necessary to prevent flags from accidentally appearing in the I
field.
2.2.6 Bit Stuffing
In order to assure that the flag bit sequence mentioned
above doesn't appear accidentally anywhere else in a frame, the
sending station shall monitor the bit sequence for a group of
five or more contiguous one bits. Any time five contiguous one
bits are sent the sending station shall insert a zero bit after
the first one bit. During frame reception, any time five
contiguous one bits are received, a zero bit immediately
following five one bits shall be discarded.
2.2.7 Frame-Check Sequence
The frame-check sequence (FCS) is a sixteen-bit number
calculated by both the sender and receiver of a frame. It is
used to insure that the frame was not corrupted by the medium
used to get the frame from the sender to the receiver. It shall
be calculated in accordance with ISO 3309 (HDLC) Recommendations.
2.2.8 Order of Bit Transmission
With the exception of the FCS field, all fields of an
AX.25 frame shall be sent with each octet's least-significant bit
first. The FCS shall be sent most-significant bit first.
2.2.9 Invalid Frames
Any frame consisting of less than 136 bits (including the
opening and closing flags), not bounded by opening and closing
flags, or not octet aligned (an integral number of octets), shall
be considered an invalid frame by the link layer. See also
2.4.4.4, below.
END AX25.DOC PART 1/9
----------------------
73's Nacho EA2CMN @EA2CMN.EAZ.ESP.EU
[27-Sep-1994 15:27]
Read previous mail | Read next mail
| |
