A Standard for the Transmission of IP Datagrams on [Archive] - Glock Talk

PDA

View Full Version : A Standard for the Transmission of IP Datagrams on


Blitzer
05-11-2009, 14:18
[RFCs/IDs (http://tools.ietf.org/html/)] [Plain (http://tools.ietf.org/rfc/rfc1149.txt)]

Updated by: 2549 (http://tools.ietf.org/html/rfc2549) EXPERIMENTAL

Network Working Group D. Waitzman
Request for Comments: 1149 BBN STC
1 April 1990




A Standard for the Transmission of IP Datagrams on Avian Carriers


Status of this Memo


This memo describes an experimental method for the encapsulation of
IP datagrams in avian carriers. This specification is primarily
useful in Metropolitan Area Networks. This is an experimental, not
recommended standard. Distribution of this memo is unlimited.


Overview and Rational


Avian carriers can provide high delay, low throughput, and low
altitude service. The connection topology is limited to a single
point-to-point path for each carrier, used with standard carriers,
but many carriers can be used without significant interference with
each other, outside of early spring. This is because of the 3D ether
space available to the carriers, in contrast to the 1D ether used by
IEEE802.3. The carriers have an intrinsic collision avoidance
system, which increases availability. Unlike some network
technologies, such as packet radio, communication is not limited to
line-of-sight distance. Connection oriented service is available in
some cities, usually based upon a central hub topology.


Frame Format


The IP datagram is printed, on a small scroll of paper, in
hexadecimal, with each octet separated by whitestuff and blackstuff.
The scroll of paper is wrapped around one leg of the avian carrier.
A band of duct tape is used to secure the datagram's edges. The
bandwidth is limited to the leg length. The MTU is variable, and
paradoxically, generally increases with increased carrier age. A
typical MTU is 256 milligrams. Some datagram padding may be needed.


Upon receipt, the duct tape is removed and the paper copy of the
datagram is optically scanned into a electronically transmittable
form.


Discussion


Multiple types of service can be provided with a prioritized pecking
order. An additional property is built-in worm detection and
eradication. Because IP only guarantees best effort delivery, loss
of a carrier can be tolerated. With time, the carriers are self-






Waitzman [Page 1]

RFC 1149 (http://tools.ietf.org/html/rfc1149) IP Datagrams on Avian Carriers 1 April 1990




regenerating. While broadcasting is not specified, storms can cause
data loss. There is persistent delivery retry, until the carrier
drops. Audit trails are automatically generated, and can often be
found on logs and cable trays.


Security Considerations


Security is not generally a problem in normal operation, but special
measures must be taken (such as data encryption) when avian carriers
are used in a tactical environment.


Author's Address


David Waitzman
BBN Systems and Technologies Corporation
BBN Labs Division
10 Moulton Street
Cambridge, MA 02238


Phone: (617) 873-4323


:rofl: :supergrin:
(dwaitzman@BBN.COM)

noway
05-12-2009, 18:47
Man, I'm converting my 1GIG and 10GIG links to Avian carrier. My only concern would be virus exposure. I heard they have weakness with bird flu ;)

kc8ykd
05-12-2009, 23:30
http://tools.ietf.org/html/rfc4824

Network Working Group J. Hofmueller, Ed.
Request for Comments: 4824 A. Bachmann, Ed.
Category: Informational IO. zmoelnig, Ed.
1 April 2007



The Transmission of IP Datagrams


over the Semaphore Flag Signaling System (SFSS)


Status of This Memo

This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.

Copyright Notice

Copyright (C) The IETF Trust (2007).

Abstract

This document specifies a method for encapsulating and transmitting
IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS).

Table of Contents

1. Introduction ....................................................2
2. Definitions .....................................................2
3. Protocol Discussion .............................................3
3.1. IP-SFS Frame Description ...................................3
3.2. SFS Coding .................................................4
3.3. IP-SFS Data Signals ........................................5
3.4. IP-SFS Control Signals .....................................6
3.5. Protocol Limitations .......................................7
3.6. Implementation Limitations .................................7
4. Interface Discussion ............................................7
4.1. Data Link Control ..........................................8
4.2. Establishing a Connection ..................................8
4.3. State Idle .................................................8
4.4. Session Initiation .........................................8
4.5. State Transmitting .........................................9
4.6. State Receiving ...........................................10
4.7. Terminating a Connection ..................................11
4.8. Further Remarks ...........................................11
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
7. References .....................................................12




Hofmueller, et al. Informational [Page 1]


RFC 4824 IP over SFSS April 2007


1. Introduction


This document specifies IP-SFS, a method for the encapsulation and
transmission of IPv4/IPv6 packets over the Semaphore Flag Signaling
System (SFSS). The SFSS is an internationally recognized alphabetic
communication system based upon the waving of a pair of hand-held
flags [JCroft, Wikipedia]. Under the SFSS, each alphabetic character
or control signal is indicated by a particular flag pattern, called a
Semaphore Flag Signal (SFS).

IP-SFS provides reliable transmission of IP datagrams over a half-
duplex channel between two interfaces. At the physical layer, SFSS
uses optical transmission, normally through the atmosphere using
solar illumination and line-of-sight photonics. A control protocol
(Section 4) allows each interface to contend for transmission on the
common channel.

This specification defines only unicast transmission. Broadcast is
theoretically possible, but there are some physical restrictions on
channel direction dispersion. This is a topic for future study.

The diagram in Figure 1 illustrates the place of the SFSS in the
Internet protocol hierarchy.

+-----+ +-----+ +-----+
| TCP | | UDP | ... | | Host Layer
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Internet Layer
+-------------------------------+
|
+-------------------------------+
| SFSS | Link Layer
+-------------------------------+

Figure 1: Protocol Relationships

MavsX
05-13-2009, 05:25
hahaha