Layer 1 traditionally has been neglected. In the ARRL 7th Computer
Networking Conference papers of October 1, 1988, N7CL posted an article:
"Can we Continue to Ignore Level One? While Eric's article dealt with TNC
DCD improvements he makes the following point:
"For some reason which I cannot fathom, there has been a great reluctance to
specify or even to provide guidelines for the various level 1 issues in the
amateur packet radio system. This reluctance traces back all the way to the
very early days of packet radio development. I find this situation very
strange indeed since if level 1 isn't working, all the other levels of the
protocol which everyone seems eager to specify down to the last bit position
are all irrelevant."
Perhaps it is would be worthwhile to obtain a library of the ARRL CNC's as
they contain a wealth of information and history on packet development over
the years. For instance in the 7th CNC alone, the table of contents reads:
A Duplex Packet Radio Repeater Approach to Layer One Efficiency, Part Two.
Formal Description to Estelle of AX.25
International Code Designator for Amateur Radio
Amateur Framing Protocol
A routing Agent for TCP/IP: RFC Implemented for the KA9Q Internet Protocol
Package
Recommended Power and Antenna Height Guidelines for LAN's and WAN's
A Totally Awesome High-Speed Packet Radio I/O Interface for the IBM PC
XT/AT/386 and Macintosh II Computers
AMSAT's MICROSAT/PACSAT Program
The DSP Project Update
Digital Radio Networks and Spectrum Management
Where is My High-Speed RF Part II
Proposed AX.25 Level 2 version 2.0 Changes
Transmission of IP Datagrams over NET/ROM Networks
More and Faster Bits: A Look at Packet Radio's Future
Can We Continue to Ignore Level One
Finger - A User Information Lookup Service
Big Sky Telegraph and Other Tales
International Routing Designators
AX.25 Packet Radio Communications Using Meteor Scatter Propagation
The AMSAT/TAPR DSP 1 Project: Hardware Design
MICROSAT Project - Flight CPU Hardware
RADIX 95: Binary to Text Data Conversion for Packet Radio
Amateur TCP/IP: An Update
Cellular Area Coverage Transport Networks
9600 Baud Packet Radio Modem Design
ARES/DATA: A Packet-Radio Database for Emergency Communications
PACSAT Software
Overview of ARRL Digital Committee Proposals for Enhancing the AX.25
Protocols into Revision 2.1
Introducing System Description Language for AX.25 and Related Protocols
AX.25 Data Link State Machine
AX.25 Link Multiplexor State Machine
Simplex Physical Layer State Machine
A Brief Note Proposing Non-Aloha Access Techniques for PACSATs
The UoSat-D Packet Communications Experiment
Apologies for taking up space with this, but a library of CNCs 'could'
prevent folks from reinventing the wheel. The TAPR web page has further
information on contents and ordering.
73 de Jack
-----Original Message-----
From: Tim Salo <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, September 30, 1999 9:33 AM
Subject: Re: AX.25 Layer 1
>> Date: Thu, 30 Sep 1999 17:28:20 +0300 (EEST)
>> From: Tomi Manninen <[EMAIL PROTECTED]>
>> Subject: Re: AX.25 Layer 1
>>
>> That's I believe because there is no such definitive source available. As
>> I said very little if anything is specified in the AX.25 specs when it
>> comes to layer 1.
>
>o I believe that it is appropriate for the AX.25 spec to focus on
> link layer issues and 1) remain silent on physical layer issues,
> and 2) operate independent of what ever media people choose to use.
>
>o I _think_ the 1200 bps "standard" is the Bell 103 spec (or one of
> the Bell modem specs). I would have to go look stuff up to be
> sure...
>
>> Tim said HDLC bit stuffing etc is a layer 2 issue, where does one
actually
>> draw the line between physical layer and link layer?
>
>A reasonable question. A few thoughts follow, without the benefit of
>a lot of thought or looking anything up.
>
>o One answer is that bit stuffing is motivated by the need for AX.25
> to delimit frames, (i.e., to be assured of unambiguously finding
> flags), not by the need of the underlying transmission techniques
> for a certain density of ones or zeros.
>
>o Another answer is that if something is required for use with all
> media, it is probably a link layer issue. Again, according to the
> spec, bit stuffing is required by AX.25 for all media.
>
>o Of course, the division between the physical layer and the link
> layer changes over time. Generally, the physical layer is
> responsible for finding the bits (encoding and decoding the bits)
> and the link layer is responsible for finding the frames in the
> stream of bits (flags and bit stuffing). (I suppose the
> responsibility for finding the characters is sometimes the
> responsibility of the physical layer, [e.g., async, and I think
> SONET] and sometimes the responsibility of the link layer, [e.g.,
> HDLC]). But, if the physical layer had some mechanism to delimit
> frames, then one could argue that finding the frames is a
> physical layer issue and therefore the link layer doesn't need to,
> for example, have flags and bit stuffing. Ethernet is an
> example of a physical layer that delimits frames. I wouldn't
> use flags and bit stuffing if I were shipping AX.25 frames over
> Ethernet. Which goes to show how hard it is to write good
> protocol specs and why we have zillions of sub-layers rather than
> the standard seven layers.
>
>-tjs
>
