FutureNet Documentation (LONG!) Part 2

[damin@wariat.org (Greg Boehnlein)]

_______________________________________________________________________________

FutureNET Network Protocol Specifications                              01/12/93
Part Two

Written by Joshua M. Thompson
Copyright (c) 1990-93 by Joshua M. Thompson.  All rights reserved

**PRELIMINARY DRAFT**  Specifications are subject to change.
_______________________________________________________________________________


IX. The Session Layer

	A. The Session Manager

	B. FutureNET Data Stream Protocol

X. The Presentation Layer

	A. The Electronic Mail Manager

The Electronic Mail Manager manages the transmission and reception of
electronic mail over the FutureNET.

A complete description of the Electronic Mail Manager and FutureNET mail in
general can be found in the the _FutureNET_Electronic_Mail_Specifications_.

	B. The Conference Manager

The Conferencing Manager manages the transmission and reception of conferencing
messages on the FutureNET.

A complete description of the Conferencing Manager and FutureNET conferencing
in general can be found in the _FutureNET_Conferencing_Specifications_.

	C. The Remote Filing Manager

The Remote Filing Manager manages the transmission and reception of files over
the FutureNET.

A complete description of the Remote Filing Manager can be found in the
_FutureNET_Remote_Filing_Protocol_Specifications_.

XI. The Application Layer

	A. The Name Manager

		1. Overview

The Name Manager allows for the assignment of more descriptive names to the
somewhat cryptic combinations of numbers that make up FutureNET addresses.

The name space recognized by the Name Manager is identical in form to the
Internet domain name space, and in fact is itself an Internet domain.  In this
scheme, we divide the entire internet into domains, and give each domain a
name.  Domains can be further subdivided if desired.  The entire structure is
best visualized as a tree:

				(root)
				/    \
			       /      \
			     ORG      EDU
			    /   \    /   \
			 FVNET  ..  ..    UMICH
			/     \		 /     \
		     CORENET OGGNET    UMD	...
		    /
		CHIBA

(incidently, this tree represents in part the real domain tree of the Internet)

To form the address of a site, you start at with the site name at the bottom of
the tree.  As you pass through nodes while moving towards the root, append that
node's name to the final address, seperated by a period.  The root is implied
and should not be made part of the address.  For example, the address of Chiba
City is "chiba.corenet.fvnet.org".

Note that the there is an imposed limit of 255 children for a given node.  This
limit reduces the complexity of the treea and also makes it easier to manage
the tree, since even a full node will fit comfortably into a memory are of
about 0.5K.

In addition to the name tree, the Name Manager also manages another set of
data structures : the NAME TABLES.  The name tables are organized by network
number and site number; given these two numbers, they will return the domain-
style address of that site.

The function of the Name Manager, therefore, is to manage these structures.
This includes the addition, deletion, and modification of the entries.  It also
includes searching these structures to obtain requested information.

		2. Storage Formats

The storage format used to store the name tree and name tables is not defined
in this document; instead, the decision is left up to the individual
implementations of the Name Manager.

		3. Updating the Name Tree and Name Tables

Updates to the name tree and name tables are transmitted over the network as
FDP datagrams with a client ID of $0103 [Name Manager Packet].  Each datagram
consists of one or more update commands.

An update command may be of one of five types : add node, delete node,
move node, modify existing node, or modify table entry.  Commands consist of
lines of Ascii text (with the high bit clear), terminated by carriage returns
(hex $0D). The first line of the command is the command type; the remaining
lines, if present, are data specific to that command.

Add Node Command:

line 1 : Should be "A" for (A)dd node
line 2 : Full name of the new node in standard dot-seperated address format.
         All nodes specified here except the first (the farthest from the
         root of the tree) must already exist.
line 3 : Site number to assign to this node.  Combined with line 4, this line
         provides an address for a machine handling traffic for this node and
         (possibly) any sites under it.
line 4 : Network number to assign to this node.
line 5 : Node type.  Should be "S" for standard or "R" for router; see below.

Delete Node Command:

line 1 : Should be "D" for (D)elete node.
line 2 : Full name of the node to delete.  Any children attached to this node
         should be deleted as well.

Move Node Command:

line 1 : Should be "M" for (M)ove node.
line 2 : Full name of node to move.  Any children attached to this node are
         moved as well (that is, the entire branch of the tree is transferred.)
line 3 : Name of parent node to which this node should be attached.  The move
         will make the node being moved a child of the node specified here.

Edit Node Command:

line 1 : Should be "E" for (E)dit node.
line 2 : Full name of node to edit.
line 3 : New site number for this node or 0 to leave unchanged.
line 4 : New network number for this node or 0 to leave unchanged.
line 5 : New node type or * to leave unchanged.

Modify Table Command:

line 1 : Should be "T" for (T)able modify.
line 2 : New name for this table entry (blank line deletes entry)
line 3 : Site number of table entry.
line 4 : Network number of table entry.

The "node type" indicates whether or not the node is the router for a domain.
Domain routers will receive traffic for any address within that domain, not
just traffic matching the domain name exactly.  Therefore, if the node called
"mynode.fvnet.org" is marked as a router, then it will not only receive traffic
for "mynode.fvnet.org", but also for nodes such as "mynode2.mynode.fvnet.org",
because the latter node is within the domain handled by the former node.

Whenever possible, an exact match is used over a matching router.  Thus, in the
above example, if "mynode2.mynode.fvnet.org" was in the node tree, that entry
would be used; otherwise, the entry for "mynode.fvnet.org" would be used since
it is a router matching that domain.

Router nodes provide support for mail gateways.  A foreign network can be
assigned a router node in the node tree, and any mail to any sites in that
domain will be sent to the gateway site, without having to keep a list of
all the foreign network's sites in the node tree.

		4. Using the name tree and name table

When looking up a name in the tree, parse the address from right to left
to obtain the path from the root node to the destination node.  If part of the
address is not in the tree, than the previous part of the address must be a
router node (in which case the router node site is the destination).  If the
full address is in the tree, the final address must be a router or leaf node.

Using the name tables is very straightforward indexing task.  The combination
of the site number and network number are the index into the tables, and the
data at that index is the name of the site.  Since the index is four bytes
long, it is generally more feasible to break the tables up into multiple files,
one for each network.