[Mep-dev] Air Interface - Initial Call

[Timothy J. Salo]

> If you are interested in working on the air interface document for MEP, 
> let me know, and we will start to get organized and begin. 

A couple of general thoughts.

First, I think that there may be three important interfaces
in the MEP:

o MEP station-to-User device.  This  interface is important
   because it, perhaps more than anything, defines what the
   MEP is (and what it isn't).  This interface defines the
   boundary of the MEP.  And, arguably, the internal MEP
   interfaces shouldn't or needn't contain any functionality
   that doesn't, at least indirectly, support or isn't
   required by the MEP-to-user interface.

o MEP station-to-MEP repeater interface.  This might be
   the "air interface" that Michelle referenced.

o MEP station-to-MEP station interface.  I separate this
   from the station-to-repeater interface because I suspect
   that it might be quite a bit different than the
   station-to-repeater interface.  Also, this will help
   resolve my question as to whether supporting both
   station-to-repeater and station-to-station operations
   adds substantial complexity to the project.

I would probably keep these three interface specifications
as separate documents, in large part to make them easier to
maintain.

Second, each of these interfaces actually contains many
protocols.  I would document them all, although some of
them can simply be adopted by reference (e.g., Ethernet
physical and link protocols).  For example the
station-to-repeater interface might include the following
protocols:

o Physical-layer protocol
   - Frequency usage
   - modulation techniques
   - ...

o Media Access Control protocol
   - Note: I would separate this out because it may be
     fairly complicated and because it may be different
     in the station-to-repeater and the repeater-to-repeater
     interfaces.

o Link-layer protocol

o Network-layer protocols
   - IP
   - DHCP (or a manual address assignment strategy)
   - ARP (do you need to resolve IP addresses, or not?)

o Control plane protocols
   - I _think_ there will be a lot of these.  I am a big
     fan of figuring what they are in advance.
   - Station announcement protocol (announce presence of
     a station, its IP address, and its IP networks)
   - Repeater management protocols (unless you like driving
     to the repeater with a laptop for every change)
   - Bandwidth reservation protocol (e.g., RSVP), if you want
     big video streams to be able to reserve bandwidth.

I would make each one of these protocol layers a separate
document, both to make maintenance easier and because different
people will probably be working on them.

> If you have any examples of an air interface document, then dig them up 
> for reference and discussion. 

You might look at some of the IEEE 802 specifications, many of
which are available free online.  Perhaps, IEEE 802.15.4.

   http://www.ieee802.org/

I would also look at the Internet RFCs.  They are a dramatically
different approach to writing specifications.  (One that has
proven to be very effective, claims that specifications must
be long and highly formal to be real specifications
notwithstanding.)

http://www.rfc-editor.org/

RFC 791, which specifies IP, is only 45 pages of ASCII text.
(Of course, one has to implement lots of other specs, too.)

> The goal is to produce a quality air interface document ...

The IETF's definition of a "quality" specification is
one that will ensure that any implementations that follow
the specification will be assured to be able to interoperate.

-tjs