As per Relevance of the word transport, we have this rfc below:
Network Working Group: M.
Request for Comments: 1707 Sunspot
Category: Informational R.
Lotus Development
October 1994
CATNIP: Common Architecture for the
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was submitted to the IETF IPng area in response to
1550 Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list
Executive
This paper describes a common architecture for the network
protocol. The Common Architecture for Next Generation
Protocol (CATNIP) provides a compressed form of the existing
layer protocols. Each compression is defined so that the
network protocol data units are identical in format. The fixed
of the compressed format is 16 bytes in length, and may often be
only part transmitted on the subnetwork
With some attention paid to details, it is possible for a
layer protocol (such as TCP) to operate properly with one end
using one network layer (e.g. IP version 4) and the other using
other network protocol, such as CLNP. Using the CATNIP definitions
all the existing transport layer protocols used on
network services will operate over any existing network
protocol
The CATNIP uses cache handles to provide both rapid identification
the next hop in high performance routing as well as abbreviation
the network header by permitting the addresses to be omitted when
valid cache handle is available. The fixed part of the network
header carries the cache handles
McGovern & Ullmann [Page 1]
RFC 1707 CATNIP October 1994
The cache handles are either provided by feedback from the
router in response to offered traffic, or explicitly provided as
of the establishment of a circuit or flow through the network.
used for flows, the handle is the locally significant
identifier
When used for circuits, the handle is the layer 3 peer-to-
logical channel identifier, and permits a full implementation
network-layer connection-oriented service if the routers along
path provide sufficient features. At the same time, the packet
of the connectionless service is retained, and hop by hop
addressed datagrams can be used at the same time. Any
model between the connection oriented and the connectionless
can thus be provided over cooperating routers
CATNIP
The first objective of the CATNIP is a practical recognition of
existing state of internetworking, and an understanding that
approach must encompass the entire problem. While it is common in
IP Internet to dismiss the ISO with various amusing phrases, it
hardly realistic. As the Internet moves into the realm of
real commercial infrastructure, for telephone, cable television,
the myriad other mundane uses, compliance with
standards is an imperative
The argument that the IETF need not (or should not) follow
ISO standards will not hold. The ISO is the legal
organization for the planet. Every other industry develops
follows ISO standards. There is (no longer) anything special
computer software or data networking
ISO convergence is both necessary and sufficient to
international acceptance and deployment of IPng. Non-convergence
effectively preclude deployment
The CATNIP integrates CLNP, IP, and IPX. The CATNIP design
for any of the transport layer protocols in use, for example TP4,
CLTP, TCP, UDP, IPX and SPX to run over any of the network
protocol formats: CLNP, IP (version 4), IPX, and the CATNIP
Incremental Infrastructure
The best use of the CATNIP is to begin to build a common
infrastructure. The routers and other components of the common
are able to use a single consistent addressing method, and
terms of reference for other aspects of the system
McGovern & Ullmann [Page 2]
RFC 1707 CATNIP October 1994
The CATNIP is designed to be incrementally deployable in the
sense: you can plop a CATNIP system down in place of any
network component and continue to operate normally with
reconfiguration. (Note: not "just a little". None at all. The
of "little changes" suggested by some proposals, and the
enormous amount of documentation, training, and administrative
then required, astounds the present authors.) The vendors do all
the work
There are also no external requirements; no "border routers",
requirement that administrators apply specific restrictions to
network designs, define special tables, or add things to the DNS
When the end users and administrators fully understand the
system, they will want to operate differently, but in no case
they be forced. Not even in small ways. Networks and end
organizations operate under sufficient constraints on deployment
systems anyway; they do not need a new network architecture adding
the difficulty
Typically deployment will occur as part of normal upgrade
of software, and due to the "swamping" of the existing base as
network grows. (When the Internet grows by a factor of 5, at
80% will then be "new" systems.) The users of the network may
take advantage of the new capabilities. Some of the
improvements will be automatic, others may require
administrative understanding to get to the best performance level
The CATNIP definitions provide stateless translation of
datagrams to and from CATNIP and, by implication, directly
the other network layer protocols. A CATNIP-capable
implementing the full set of definitions can interoperate with
existing protocol. Various subsets of the full capability may
provided by some vendors
No Address
Note that there is no "address translation" in the
specification. (While it may seem odd to state a negative objective
this is worth saying as people seem to assume the opposite.)
are no "mapping tables", no magic ways of digging translations out
the DNS or X.500, no routers looking up translations or asking
systems for them
Addresses are modified with a simple algorithmic mapping, a
that is no more than using specific prefixes for IP and
addresses. Not a large set of prefixes; one prefix. The
existing IP version 4 network is mapped with one prefix and the
global network with one other prefix. (The IP mapping does
McGovern & Ullmann [Page 3]
RFC 1707 CATNIP October 1994
for future assignment of other IANA/IPv4 domains that are
from the existing one.)
This means that there is no immediate effect on addresses embedded
higher level protocols
Higher level protocols not using the full form (those native to
and IPX) will eventually be extended to use the full addressing
extend their usability over all of the network layers
No Legacy
The CATNIP leaves no systems behind: with no reconfiguration,
system presently capable of IP, CLNP, or IPX retains at least
connectivity it has now. With some administrative changes (such
assigning IPX domain addresses to some CLNP hosts for example)
other systems, unmodified systems may gain significant connectivity
IPX systems with registered network numbers may gain the most
Limited
The CATNIP defines a common network layer packet format and
architecture. It intentionally does not specify ES-IS methods
routing, naming systems, autoconfiguration and other subjects
part of the core Internet wide architecture. The related problems
their (many) solutions are not within the scope of the
of the basic common network layer
Existing Addresses and Network
The Internet's version 4 numbering system has proven to be
flexible, (mostly) expandable, and simple. In short: it works
However, there are two problems. Neither was considered serious
the CATNIP was first developed in 1988 and 1989, but both are now
major concern
o The division into network, and then subnet, is insufficient
Almost all sites need a network assignment large enough
subnet. At the top of the hierarchy, there is a need to
administrative domains
o As bit-packing is done to accomplish the desired
structure, the 32-bit limit causes more and more aggravation
Another major addressing system used in open internetworking is
OSI method of specifying Network Service Access Points (NSAPs).
NSAP consists of an authority and format identifier, a
McGovern & Ullmann [Page 4]
RFC 1707 CATNIP October 1994
assigned to that authority, an address assigned by that authority
and a selector identifying the next layer (transport layer) protocol
This is actually a general multi-level hierarchy, often obscured
the details of specific profiles. (For example, CLNP doesn't
20 octet NSAPs, it allows any length. But various GOSIPs profile
NSAP as 20 octets, and IS-IS makes specific assumptions about
last 1-8 octets. And so on.)
The NSAP does not directly correspond to an IP address, as
selector in IP is separate from the address. The concept that
correspond is the NSAP less the selector, called the Network
Title or NET. (An unfortunate acronym, but one we will use to
repeating the full term.) The usual definition of NET is an NSAP
the selector set to 0; the NET used here omits the 0 selector
There is also a network numbering system used by IPX, a product
Novell, Inc. (referred to from here on as Novell) and other
making compatible software. While IPX is not yet well connected
a global network, it has a larger installed base than either of
other network layers
Network Layer
The network layer address looks like
+----------+----------+---------------+---------------+
| length | AFI | IDI ... | DSP ... |
+----------+----------+---------------+---------------+
The fields are named in the usual OSI terminology although that
to an oversupply of acronyms. Here are more detailed descriptions
each field
length: the number of bytes (octets) in the remainder of
address
AFI: the Authority and Format Identifier. A single
value, from a set of well-known values registered
ISO, that determines the semantics of the IDI
IDI: the Initial Domain Identifier, a number assigned by
authority named by the AFI, formatted according to
semantics implied by the AFI, that determines
authority for the remainder of the address
DSP: Domain Specific Part, an address assigned by
authority identified by the value of the IDI
McGovern & Ullmann [Page 5]
RFC 1707 CATNIP October 1994
Note that there are several levels of authority. ISO, for example
identifies (with the AFI) a set of numbering authorities (like X.121,
the numbering plan for the PSPDN, or E.164, the numbering plan
the telephone system). Each authority numbers a set of
or individuals or other entities. (For example, E.164
16172477959 to me as a telephone subscriber.)
The entity then is the authority for the remainder of the address.
can do what I please with the addresses starting with (AFI=E.164)
(IDI=16172477959). Note that this is a delegation of authority,
not an embedding of a data-link address (the telephone number) in
network layer address. The actual routing of the network
address has nothing to do with the authority numbering
The domain-specific part is variable length, and can be allocated
whatever way the authority identified by the AFI+IDI desires
Network Layer
The common architecture format for network layer datagrams
described below. The design is a balance between use on
performance networks and routers, and a desire to minimize the
of bits in the fixed header. Using the current state of
technology as a reference, the fixed header is all loaded into
registers on the first memory cycle, and it all fits within
operation bandwidth. The header leaves the remaining data aligned
the header size (128 bits); with 64 bit addresses present and
options it leaves the transport header 256 bit aligned
On very slow and low performance networks, the fixed header is
fairly small, and could be further compressed by methods similar
those used with IP version 4 on links that consider every
precious. In between, it fits nicely into ATM cells and
packets, leaving sufficient space for the transport header
application data
McGovern & Ullmann [Page 6]
RFC 1707 CATNIP October 1994
+---------------+---------------+-+-+-+-+-+-+-+-+---------------+
| NLPID (70) | Header Size |D|S|R|M|E| MBZ | Time to Live |
+---------------+---------------+-+-+-+-+-+-+-+-+---------------+
| Forward Cache Identifier |
+---------------------------------------------------------------+
| Datagram Length |
+---------------------------------------------------------------+
| Transport Protocol | Checksum |
+---------------------------------------------------------------+
| Destination Address ... |
+---------------------------------------------------------------+
| Source Address ... |
+---------------------------------------------------------------+
| Options ... |
+---------------------------------------------------------------+
NLPID: The first byte (the network layer protocol identifier in OSI
is an 8 bit constant 70 (hex). This corresponds to
Version 7.
Header Length: The header length is a 8-bit count of the number
32-bit words in the header. This allows the header
be up to 1020 bytes in length
Flags: This byte is a small set of flags determining the
header format and the processing semantics. The last three
are reserved, and must be set to zero. (Note that
corresponding bits in CLNP version 1 are 001, since this
is the version field. This may be useful.)
Destination Address Omitted: When the destination address
(DAO) flag is zero, the destination address is present as
in the datagram format diagram. When a datagram is sent
an FCI that identifies the destination and the DAO flag
set, the address does not appear in the datagram
Source Address Omitted: The source address omitted (SAO) flag is
when the source address is present in the datagram.
datagram is sent with an FCI that identifies the source and
SAO flag is set, the source address is omitted from
datagram
Report Fragmentation Done: When this bit (RFD) is set, an
router that fragments the datagram (because it is larger
the next subnetwork MTU) should report the event with an
Datagram Too Big message. (Unlike IP version 4, which uses
for MTU discovery, the RFD flag allows the fragmented
McGovern & Ullmann [Page 7]
RFC 1707 CATNIP October 1994
to be delivered.)
Mandatory Router Option: The mandatory router option (MRO)
indicates that routers forwarding the datagram must look at
network header options. If not set, an intermediate
should not look at the header options. (But it may anyway
this is a necessary consequence of transparent network
translation, which may occur anywhere.)
The destination host, or an intermediate router
translation, must look at the header options regardless
the setting of the MRO flag
A router doing fragmentation will normally only use the
flag in options to determine whether options should be
within the fragmentation code path. (It might also
and elide null options.) If the MRO flag is not set, the
may not act on an option even though it copies it
during fragmentation
If there are no options present, MRO should always be zero,
that routers can follow the no-option profile path in
implementation. (Remember that the presence of options
be divided from the header length, since the addresses
variable length.)
Error Report Suppression: The ERS flag is set to suppress the
of error reports by any system (whether host or router
receiving or forwarding the datagram. The system may log
error, increment network management counters, and take
similar action, but ICMP error messages or CNLP error
must not be sent
The ERS flag is normally set on ICMP messages and other
layer error reports. It does not suppress the normal
to ICMP queries or similar network layer queries (CNLP
request).
If both the RFD and ERS flags are set, the fragmentation
is sent. (This definition allows a larger range
possibilities than simply over-riding the RFD flag would;
sender not desiring this behavior can see to it that RFD
clear.)
Time To Live: The time to live is a 8-bit count, nominally in seconds
Each hop is required to decrement TTL by at least one. A
that holds a datagram for an unusual amount of time (more
2 seconds, a typical example being a wait for a
McGovern & Ullmann [Page 8]
RFC 1707 CATNIP October 1994
connection establishment) should subtract the entire
time in seconds (rounded upward) from the TTL
Forward Cache Identifier: Each datagram carries a 32 bit field,
"forward cache identifier", that is updated (if the
is available) at each hop. This field's value is derived
ICMP messages sent back by the next hop router, a
protocol (e.g., RAP), or some other method. The FCI is used
expedite routing decisions by preserving knowledge
possible between consecutive routers. It can also be used
make datagrams stay within reserved flows, circuits, and
host tunnels. If an FCI is not available, this field must
zero, the SAO and DAO flags must be clear, and both
and source addresses must appear in the datagram
Datagram Length: The 32-bit length of the entire datagram in octets
A datagram can therefore be up to 4294967295 bytes in
length. Particular networks normally impose lower limits
Transport Protocol: The transport layer protocol. For example, TCP
6.
Checksum: The checksum is a 16-bit checksum of the entire header
using the familiar algorithm used in IP version 4.
Destination: The destination address, a count byte followed by
destination NSAP with the zero selector omitted. This field
present only if the DAO flag is zero. If the count field is
3 modulo 4 (the destination is not an integral multiple
32-bit words) zero bytes are added to pad to the next
of 32 bits. These pad bytes are not required to be ignored
routers may rely on them being zero
Source: The source address, in the same format as the destination
Present only if the SAO flag is zero. The source is padded
the same way as destination to arrive at a 32-bit boundary
Options: Options may follow. They are variable length, and
32-bit aligned. If the MRO flag in the header is not set
routers will usually not look at or take action on any option
regardless of the setting of the class field
The multicast-enable option permits multicast forwarding of
CATNIP datagram on subnetworks that directly support media
multicasting. This is a vanishing species, even in 10 Mbps Ethernet
given the increasing prevalence of switching hubs. It also (
McGovern & Ullmann [Page 9]
RFC 1707 CATNIP October 1994
more usefully) permits a router to forward the datagram on
paths when a multicast routing algorithm has established such paths
There is no option data
Note that there is no special address space for multicasting in
CATNIP. Multicast destination addresses can be allocated anywhere
any administration or authority. This supports a number of
models of addressing. It does require that the transport
protocol know that the destination is multicast; this is desirable
any case. (For example, the transport will probably want to set
ERS flag.)
On an IEEE 802.x (ISO 8802.x) type media, the last 23 bits of
address (not including the 0 selector) are used in combination
the multicast group address assigned to the Internet to form
media address when forwarding a datagram with the multicast
option from a router to an attached network provided that
datagram was not received on that network with either multicast
broadcast media addressing. A host may send a multicast
either to the media multicast address (the IP catenet model,)
media unicast to a router which is expected to repeat it to
multicast address within the entire level I area or to repeat
to the appropriate end systems within the area on non-broadcast
(the more general CLNP model.)
Network Layer
The objective of translation is to be able to upgrade systems,
hosts and routers, in whatever order desired by their owners
Organizations must be able to upgrade any given system
reconfiguration or modification of any other, and existing hosts
be able to interoperate essentially forever. (Non-CATNIP routers
probably be effectively eliminated at some point, except where
exist in their own remote or isolated corners.)
Each CATNIP system, whether host or router, must be able to
adjacent systems in the topology that are (only) IP version 4, CLNP
or IPX and call the appropriate translation routine just
sending the datagram
OSI
The translation between CLNP and the CATNIP compressed form of
datagrams is the simplest case for CATNIP, since the addresses
the same and need not be extended. The resulting CATNIP datagrams
omit the source and destination addresses as explained previously
and may be mixed with uncompressed datagrams on the same
link. Alternatively, a subnetwork may operate entirely in the CATNIP
McGovern & Ullmann [Page 10]
RFC 1707 CATNIP October 1994
converting all transit traffic to CATNIP datagrams, even if FCIs
would make the compression effective are not available
Similarly, all network datagram formats with CATNIP mappings may
compressed into the common form, providing a uniform transit
service, with common routing protocols (such as IS-IS).
Internet
All existing version 4 numbers are defined as belonging to
Internet by using a new AFI, to be assigned to IANA by the ISO.
document uses 192 at present for clarity in examples; it is to
replaced with the assigned AFI. The AFI specifies that the IDI is
bytes long, containing an administrative domain number
The AD (Administrative Domain), identifies an administration
may be an international authority (such as the existing InterNIC),
national administration, or a large multi-organization (e.g.,
government). The idea is that there should not be more than a
hundred of these at first, and eventually thousands or tens
thousands at most
AD numbers are assigned by IANA. Initially, the only assignment
the number 0.0, assigned to the InterNIC, encompassing the
existing version 4 Internet
The mapping from/to version 4 IP addresses
+----------+----------+---------------+---------------------+
| length | AFI | IDI ... | DSP ... |
+----------+----------+---------------+---------------------+
| 7 | 192 | AD number | version 4 address |
+----------+----------+---------------+---------------------+
While the address (DSP) is initially always the 4 byte, version 4
address, it can be extended to arbitrary levels of subnetting
the existing Internet numbering plan. Hosts with DSPs longer than 4
bytes will not be able to interoperate with version 4 hosts
Novell
The Internetwork Packet Exchange protocol, developed by Novell
on the XNS protocol (Xerox Network System) has many of the
capabilities as the Internet and OSI protocols. At first look,
appears to confuse the network and transport layers, as IPX
both the network layer service and the user datagram service of
transport layer, while SPX (sequenced packet exchange) includes
IPX network layer and provides service similar to TCP or TP4.
McGovern & Ullmann [Page 11]
RFC 1707 CATNIP October 1994
turns out to be mostly a matter of the naming and ordering of
in the packets, rather than any architectural difference
IPX uses a 32-bit LAN network number, implicitly concatenated
the 48-bit MAC layer address to form an Internet address. Initially
the network numbers were not assigned by any central authority,
thus were not useful for inter-organizational traffic
substantial prior arrangement. There is now an authority
by Novell to assign unique 32-bit numbers and blocks of numbers
organizations that desire inter-organization networking with the
protocol
The Novell/IPX numbering plan uses an ICD, to be assigned,
designate an address as an IPX address. This means Novell uses
authority (AFI=47)(ICD=Novell) and delegates assignments of
following 32 bits
An IPX address in the common form looks like
+----------+----------+---------------+---------------------+
| length | AFI | IDI ... | DSP ... |
+----------+----------+---------------+---------------------+
| 13 | 47 (hex) | Novell ICD | network+MAC address |
+----------+----------+---------------+---------------------+
This will always be followed by two bytes of zero padding when
appears in a common network layer datagram. Note that the
numbers included in the native form IPX address are part of
transport layer
It may seem a little odd to describe the interaction with SIPP-16
(version 6 of IP) which is another proposed candidate for the
generation of network layer protocols. However, if SIPP-16
deployed, whether or not as the protocol of choice for replacement
IP version 4, there will then be four network protocols
accommodate. It is prudent to investigate how SIPP-16 could then
integrated into the common addressing plan and datagram format
SIPP-16 defines 128 bit addresses, which are included in the
addressing plan under the Internet AFI as AD number 0.1. It is
clear at this time what administration will hold the authority
the SIPP-16 numbering plan. This produces a 20 byte NSAPA, with
system ID field positioned exactly as expected by (e.g.) IS-IS
McGovern & Ullmann [Page 12]
RFC 1707 CATNIP October 1994
+----------+----------+---------------+---------------------+
| length | AFI | IDI ... | DSP ... |
+----------+----------+---------------+---------------------+
| 19 | 192 | AD (0.1) | SIPP-16 address |
+----------+----------+---------------+---------------------+
The SIPP-16 addressing method (the definition of the 128 bits)
not be described here
The SIPP proposal also includes an encapsulated-tunnel
called IPAE, to address some of the issues that are designed
CATNIP. The CATNIP direct translation does not use the SIPP-
packet formats. IPAE also specifies a "mapping table" for prefixes
This table is kept up-to-date by periodic FTP transfers from
"central site." The CATNIP definitions leave the problem of
selection when converting into SIPP firmly within the scope of
SIPP-IPAE proposal, and possible methods are not described here
In translating from SIPP (IPv6) to CATNIP (IPv7), the only
aspect is that SIPP defines some things that are normally
options to be "payloads" overloaded onto the transport
numbering space. Fortunately, the only one that need be
is fragmentation; a fragmented SIPP datagram may need to
reassembled prior to conversion. Other "payloads" such as
are ignored (translated verbatim) and will normally simply fail
achieve the desired effect
Translation to SIPP is simple, except for the difficult problem
inventing the "prefix" if an implementation wants to
translating Internet AD 0.0 numbers into the SIPP addressing domain
Internet
CATNIP addresses are represented in the DNS with the NSAP RR.
data in the resource record is the NSAP, including the zero
at the end. The zone file syntax for the data is a string
hexadecimal digits, with a period "." inserted between any two
where desired for readability. For example
The inverse (PTR) zone is .NSAP.INT, with the CATNIP
(reversed). That is, like .IN-ADDR.ARPA, but with .NSAP.INT instead
The nibbles are represented as hexadecimal digits
This respects the difference in actual authority: the IANA is
authority for the entire space rooted in .IN-ADDR.ARPA. in
version 4 Internet, while in the new Internet it holds the
only for 0.C.NSAP.INT. (Following the example of 192 as the
value.) The domain 0.0.0.0.0.C.NSAP.INT is to be delegated by IANA
McGovern & Ullmann [Page 13]
RFC 1707 CATNIP October 1994
the InterNIC. (Understanding that in present practice the InterNIC
the operator of the authoritative root.)
Security
The CATNIP design permits the direct use of the present proposals
network layer security being developed in the IPSEC WG of the IETF
There are a number of detailed requirements; the most relevant
that network layer datagram translation must not affect (
affect) the transport layers, since the TPDU is mostly
to the router. For example, the translation into IPX will only
if the port numbers are shadowed into the plaintext security header
[Chapin93] Chapin, L., and D. Piscitello, "Open
Networking", Addison-Wesley, Reading, Massachusetts
1993.
[Perlman92] Perlman, R., "Interconnections: Bridges and Routers
Addison-Wesley, Reading, Massachusetts, 1992.
[RFC791] Postel, J., Editor, "Internet Protocol -
Internet Program Protocol Specification", STD 5,
791 USC/Information Sciences Institute,
1981.
[RFC792] Postel, J., Editor, "Internet Control
Protocol - DARPA Internet Program
Specification", STD 5, RFC 792, USC/
Sciences Institute, September 1981.
[RFC793] Postel, J., Editor, "Transmission Control Protocol -
DARPA Internet Program Protocol Specification
STD 7, RFC 793, USC/Information Sciences Institute
September, 1981.
[RFC801] Postel, J., "NCP/TCP Transition Plan", RFC 801,
USC/Information Sciences Institute, November, 1981.
[RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery",
RFC 1191, DECWRL, Stanford University, November
1990.
[RFC1234] Provan, D., "Tunneling IPX Traffic Through
Networks", RFC 1234, Novell, Inc., June 1991.
McGovern & Ullmann [Page 14]
RFC 1707 CATNIP October 1994
[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc.,
July 1991.
[RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R.,
R. Hobby, "Towards the Future Internet Architecture",
RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December
1991.
[RFC1335] Wang, Z., and J. Crowcroft, "A Two-Tier
Structure for the Internet: A Solution to
Problem of Address Space Exhaustion", RFC 1335,
University College London, May 1992.
[RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan
"Supernetting: an Address Assignment and
Strategy", RFC 1338, BAARNet, cicso, Merit, OARnet
June 1992.
[RFC1347] Callon, R., "TCP and UDP with Bigger
(TUBA), A Simple Proposal for Internet
and Routing", RFC 1347, DEC, June 1992.
[RFC1466] Gerich, E., "Guidelines for Management of IP
Space", RFC 1466, Merit, May 1993.
[RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
Process Software Corporation, June 1993.
[RFC1476] Ullmann, R., "RAP: Internet Route Access Protocol",
RFC 1476, Process Software Corporation, June 1993.
[RFC1561] Piscitello, D., "Use of ISO CLNP in
Environments", RFC 1561, Core Competence,
1993.
McGovern & Ullmann [Page 15]
RFC 1707 CATNIP October 1994
Authors'
Michael
Sunspot
EMail: scrivner@world.std.
Robert
Lotus Development
1 Rogers
Cambridge, MA 02142
Phone: +1 617 693 1315
EMail: rullmann@crd.lotus.
McGovern & Ullmann [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
