As per Relevance of the word flooding, we have this rfc below:
Network Working Group R.
Request for Comments: 2370 FORE
See Also: 2328 July 1998
Category: Standards
The OSPF Opaque LSA
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
Table Of
1.0 Abstract ................................................. 1
2.0 Overview ................................................. 2
2.1 Organization Of This Document ............................ 2
2.2 Acknowledgments .......................................... 3
3.0 The Opaque LSA ........................................... 3
3.1 Flooding Opaque LSAs ..................................... 4
3.2 Modifications To The Neighbor State Machine .............. 5
4.0 Protocol Data Structures ................................. 6
4.1 Additions To The OSPF Neighbor Structure ................. 6
5.0 Management Considerations ................................ 7
6.0 Security Considerations .................................. 9
7.0 IANA Considerations ...................................... 10
8.0 References ............................................... 10
9.0 Author's Information ..................................... 11
Appendix A: OSPF Data Formats ................................ 12
A.1 The Options Field ........................................ 12
A.2 The Opaque LSA ........................................... 13
Appendix B: Full Copyright Statment .......................... 15
1.0
This memo defines enhancements to the OSPF protocol to support a
class of link-state advertisements (LSA) called Opaque LSAs.
LSAs provide a generalized mechanism to allow for the
extensibility of OSPF. Opaque LSAs consist of a standard LSA
followed by application-specific information. The information
Coltun Standards Track [Page 1]
RFC 2370 The OSPF Opaque LSA Option July 1998
may be used directly by OSPF or by other applications. Standard
link-state database flooding mechanisms are used to distribute
LSAs to all or some limited portion of the OSPF topology
2.0
Over the last several years the OSPF routing protocol [OSPF] has
widely deployed throughout the Internet. As a result of
deployment and the evolution of networking technology, OSPF has
extended to support many options; this evolution will
continue
This memo defines enhancements to the OSPF protocol to support a
class of link-state advertisements (LSA) called Opaque LSAs.
LSAs provide a generalized mechanism to allow for the
extensibility of OSPF. The information contained in Opaque LSAs
be used directly by OSPF or indirectly by some application wishing
distribute information throughout the OSPF domain. For example,
OSPF LSA may be used by routers to distribute IP to link-
address resolution information (see [ARA] for more information).
exact use of Opaque LSAs is beyond the scope of this memo
Opaque LSAs consist of a standard LSA header followed by a 32-
qaligned application-specific information field. Like any other LSA
the Opaque LSA uses the link-state database distribution
for flooding this information throughout the topology. The link
state type field of the Opaque LSA identifies the LSA's range
topological distribution. This range is referred to as the
Scope
It is envisioned that an implementation of the Opaque option
an application interface for 1) encapsulating application-
information in a specific Opaque type, 2) sending and
application-specific information, and 3) if required, informing
application of the change in validity of previously
information when topological changes are detected
2.1 Organization Of This
This document first defines the three types of Opaque LSAs
by a description of OSPF packet processing. The packet
sections include modifications to the flooding procedure and to
neighbor state machine. Appendix A then gives the packet formats
Coltun Standards Track [Page 2]
RFC 2370 The OSPF Opaque LSA Option July 1998
2.2
The author would like to thank Dennis Ferguson, Acee Lindem,
Moy, Sandra Murphy, Man-Kit Yeung, Zhaohui "Jeffrey" Zhang and
rest of the OSPF Working Group for the ideas and support they
given to this project
3.0 The Opaque
Opaque LSAs are types 9, 10 and 11 link-state advertisements.
LSAs consist of a standard LSA header followed by a 32-bit
application-specific information field. Standard link-state
flooding mechanisms are used for distribution of Opaque LSAs.
range of topological distribution (i.e., the flooding scope) of
Opaque LSA is identified by its link-state type. This
documents the flooding of Opaque LSAs
The flooding scope associated with each Opaque link-state type
defined as follows
o Link-state type 9 denotes a link-local scope. Type-9
LSAs are not flooded beyond the local (sub)network
o Link-state type 10 denotes an area-local scope. Type-10
LSAs are not flooded beyond the borders of their associated area
o Link-state type 11 denotes that the LSA is flooded
the Autonomous System (AS). The flooding scope of type-11
LSAs are equivalent to the flooding scope of AS-external (type-5)
LSAs. Specifically type-11 Opaque LSAs are 1) flooded
all transit areas, 2) not flooded into stub areas from
backbone and 3) not originated by routers into their
stub areas. As with type-5 LSAs, if a type-11 Opaque LSA
received in a stub area from a neighboring router within
stub area the LSA is rejected
The link-state ID of the Opaque LSA is divided into an Opaque
field (the first 8 bits) and a type-specific ID (the remaining 24
bits). The packet format of the Opaque LSA is given in Appendix A
Section 7.0 describes Opaque type allocation and assignment
The responsibility for proper handling of the Opaque LSA's
scope is placed on both the sender and receiver of the LSA.
receiver must always store a valid received Opaque LSA in its link
state database. The receiver must not accept Opaque LSAs
violate the flooding scope (e.g., a type-11 (domain-wide) Opaque
is not accepted in a stub area). The flooding scope effects both
Coltun Standards Track [Page 3]
RFC 2370 The OSPF Opaque LSA Option July 1998
synchronization of the link-state database and the
procedure
The following describes the modifications to these procedures
are necessary to insure conformance to the Opaque LSA's
Rules
3.1 Flooding Opaque
The flooding of Opaque LSAs must follow the rules of Flooding
as specified in this section. Section 13 of [OSPF] describes
OSPF flooding procedure. The following describes the Opaque LSA'
type-specific flooding restrictions
o If the Opaque LSA is type 9 (the flooding scope is link-local
and the interface that the LSA was received on is not the same
the target interface (e.g., the interface associated with
particular target neighbor), the Opaque LSA must not be
out that interface (or to that neighbor). An
should keepk track of the IP interface associated with
Opaque LSA having a link-local flooding scope
o If the Opaque LSA is type 10 (the flooding scope is area-local
and the area associated with Opaque LSA (upon reception) is
the same as the area associated with the target interface,
Opaque LSA must not be flooded out the interface.
implementation should keep track of the OSPF area
with each Opaque LSA having an area-local flooding scope
o If the Opaque LSA is type 11 (the LSA is flooded throughout
AS) and the target interface is associated with a stub area
Opaque LSA must not be flooded out the interface. A type-11
Opaque LSA that is received on an interface associated with
stub area must be discarded and not acknowledged (
neighboring router has flooded the LSA in error).
When opaque-capable routers and non-opaque-capable OSPF routers
mixed together in a routing domain, the Opaque LSAs are not
to the non-opaque-capable routers. As a general design principle
optional OSPF advertisements are only flooded to those routers
understand them
An opaque-capable router learns of its neighbor's opaque
at the beginning of the "Database Exchange Process" (see Section 10.6
of [OSPF], receiving Database Description packets from a neighbor
state ExStart). A neighbor is opaque-capable if and only if it
the O-bit in the Options field of its Database Description packets
the O-bit is not set in packets other than Database
Coltun Standards Track [Page 4]
RFC 2370 The OSPF Opaque LSA Option July 1998
packets. Then, in the next step of the Database Exchange process
Opaque LSAs are included in the Database summary list that is sent
the neighbor (see Sections 3.2 below and 10.3 of [OSPF]) if and
if the neighbor is opaque capable
When flooding Opaque-LSAs to adjacent neighbors, a opaque-
router looks at the neighbor's opaque capability. Opaque LSAs
only flooded to opaque-capable neighbors. To be more precise,
Section 13.3 of [OSPF], Opaque LSAs are only placed on the link-
retransmission lists of opaque-capable neighbors. However, when
ing Link State Update packets as multicasts, a non-opaque-
neighbor may (inadvertently) receive Opaque LSAs. The non-opaque
capable router will then simply discard the LSA (see Section 13
[OSPF], receiving LSAs having unknown LS types).
3.2 Modifications To The Neighbor State
The state machine as it exists in section 10.3 of [OSPF]
unchanged except for the action associated with State: ExStart
Event: NegotiationDone which is where the Database summary list
built. To incorporate the Opaque LSA in OSPF this action is
to the following
State(s):
Event:
New state:
Action: The router must list the contents of its entire
link-state database in the neighbor Database
list. The area link-state database consists of
Router LSAs, Network LSAs, Summary LSAs and types 9
10 Opaque LSAs contained in the area structure,
with AS External and type-11 Opaque LSAs contained
the global structure. AS External and type-11
LSAs are omitted from a virtual neighbor's
summary list. AS External LSAs and type-11 Opaque
are omitted from the Database summary list if the
has been configured as a stub area (see Section 3.6
[OSPF]).
Type-9 Opaque LSAs are omitted from the Database
list if the interface associated with the neighbor
not the interface associated with the Opaque LSA (
noted upon reception).
Coltun Standards Track [Page 5]
RFC 2370 The OSPF Opaque LSA Option July 1998
Any advertisement whose age is equal to MaxAge
omitted from the Database summary list. It is
added to the neighbor's link-state retransmission list
A summary of the Database summary list will be sent
the neighbor in Database Description packets.
Database Description Packet has a DD sequence number
and is explicitly acknowledged. Only one
Description Packet is allowed to be outstanding at
one time. For more detail on the sending and
of Database Description packets, see Sections 10.6
10.8 of [OSPF].
4.0 Protocol Data
The Opaque option is described herein in terms of its operation
various protocol data structures. These data structures are
for explanatory uses only, and are not intended to constrain
implementation. In addition to the data structures listed below,
specification references the various data structures (e.g.,
neighbors) defined in [OSPF].
In an OSPF router, the following item is added to the list of
OSPF data structures described in Section 5 of [OSPF]:
o Opaque capability. Indicates whether the router is running
Opaque option (i.e., capable of storing Opaque LSAs). Such
router will continue to inter-operate with non-opaque-
OSPF routers
4.1 Additions To The OSPF Neighbor
The OSPF neighbor structure is defined in Section 10 of [OSPF].
an opaque-capable router, the following items are added to the
neighbor structure
o Neighbor Options. This field was already defined in the
specification. However, in opaque-capable routers there is a
option which indicates the neighbor's Opaque capability. This
option is learned in the Database Exchange process
reception of the neighbor's Database Description packets,
determines whether Opaque LSAs are flooded to the neighbor. For
more detailed explanation of the flooding of the Opaque LSA
section 3 of this document
Coltun Standards Track [Page 6]
RFC 2370 The OSPF Opaque LSA Option July 1998
5.0 Management
This section identifies the current OSPF MIB [OSPFMIB]
that are applicable to the Opaque option and lists the
management information which is required for its support
Opaque LSAs are types 9, 10 and 11 link-state advertisements.
link-state ID of the Opaque LSA is divided into an Opaque type
(the first 8 bits) and a type-specific ID (the remaining 24 bits).
The packet format of the Opaque LSA is given in Appendix A.
range of topological distribution (i.e., the flooding scope) of
Opaque LSA is identified by its link-state type
o Link-State type 9 Opaque LSAs have a link-local scope. Type-9
Opaque LSAs are flooded on a single local (sub)network but
not flooded beyond the local (sub)network
o Link-state type 10 Opaque LSAs have an area-local scope. Type-10
Opaque LSAs are flooded throughout a single area but are
flooded beyond the borders of the associated area
o Link-state type 11 Opaque LSAs have an Autonomous-System-
scope. The flooding scope of type-11 LSAs are equivalent to
flooding scope of AS-external (type-5) LSAs
The OSPF MIB provides a number of objects that can be used to
and monitor an OSPF router's Link-State Database. The ones that
relevant to the Opaque option are as follows
The ospfGeneralGroup defines two objects for keeping track of
originated and newly received LSAs (ospfOriginateNewLsas
ospfRxNewLsas respectively).
The OSPF MIB defines a set of optional traps. The
trap signifies that a new LSA has been originated by a router
the ospfMaxAgeLsa trap signifies that one of the LSAs in
router's link-state database has aged to MaxAge
The ospfAreaTable describes the configured parameters
cumulative statistics of the router's attached areas. This
includes a count of the number of LSAs contained in the area'
link-state database (ospfAreaLsaCount), and a sum of the LSA's
checksums contained in this area (ospfAreaLsaCksumSum). This
can be used to determine if there has been a change in a router'
link-state database, and to compare the link-state database of
routers
Coltun Standards Track [Page 7]
RFC 2370 The OSPF Opaque LSA Option July 1998
The ospfLsdbTable describes the OSPF Process's link-state
(excluding AS-external LSAs). Entries in this table are
with an Area ID, a link-state type, a link-state ID and
originating router's Router ID
The management objects that are needed to support the Opaque
are as follows
An Opaque-option-enabled object is needed to indicate if the
option is enabled on the router
The origination and reception of new Opaque LSAs should
reflected in the counters ospfOriginateNewLsas and
(inclusive for types 9, 10 and 11 Opaque LSAs).
If the OSPF trap option is supported, the origination of new
LSAs and purging of MaxAge Opaque LSAs should be reflected in
ospfOriginateLsa and ospfMaxAgeLsa traps (inclusive for types 9, 10
and 11 Opaque LSAs).
The number of type-10 Opaque LSAs should be reflected
ospfAreaLsaCount; the checksums of type-10 Opaque LSAs should
included in ospfAreaLsaChksumSum
Type-10 Opaque LSAs should be included in the ospfLsdbTable.
that this table does not include a method of examining the
type field (in the Opaque option this is a sub-field of the link
state ID).
Up until now, LSAs have not had a link-local scope so there is
method of requesting the number of, or examining the LSAs that
associated with a specific OSPF interface. A new group
management objects are required to support type-9 Opaque LSAs
These objects should include a count of type-9 Opaque LSAs,
checksum sum and a table for displaying the link-state database
type-9 Opaque LSAs on a per-interface basis. Entries in this
should be indexed with an Area ID, interface's IP address,
type, link-state ID and the originating router's Router ID
Prior to the introduction of type-11 Opaque LSAs, AS-
(type-5) LSAs have been the only link-state types which have
Autonomous-System-wide scope. A new group of objects are
to support type-11 Opaque LSAs. These objects should include
count of type-11 Opaque LSAs, a type-11 checksum sum and a
for displaying the type-11 link-state database. Entries in
table should be indexed with the Opaque type, link-state ID and
Coltun Standards Track [Page 8]
RFC 2370 The OSPF Opaque LSA Option July 1998
originating router's Router ID. The type-11 link-state
table will allow type-11 LSAs to be displayed once for the
rather than once in each non-stub area
6.0 Security
There are two types of issues that need be addressed when looking
protecting routing protocols from misconfigurations and
attacks. The first is authentication and certification of
protocol information. The second is denial of service
resulting from repetitive origination of the same
advertisement or origination a large number of
advertisements resulting in database overflow. Note that both
these concerns exist independently of a router's support for
Opaque option
To address the authentication concerns, OSPF protocol exchanges
authenticated. OSPF supports multiple types of authentication;
type of authentication in use can be configured on a per
segment basis. One of OSPF's authentication types, namely
Cryptographic authentication option, is believed to be secure
passive attacks and provide significant protection against
attacks. When using the Cryptographic authentication option,
router appends a "message digest" to its transmitted OSPF packets
Receivers then use the shared secret key and received digest
verify that each received OSPF packet is authentic
The quality of the security provided by the
authentication option depends completely on the strength of
message digest algorithm (MD5 is currently the only message
algorithm specified), the strength of the key being used, and
correct implementation of the security mechanism in all
OSPF implementations. It also requires that all parties maintain
secrecy of the shared secret key. None of the standard
authentication types provide confidentiality. Nor do they
against traffic analysis. For more information on the standard
security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF].
[DIGI] describes the extensions to OSPF required to add
signature authentication to Link State data and to provide
certification mechanism for router data. [DIGI] also describes
added LSA processing and key management as well as a method
migration from, or co-existence with, standard OSPF V2.
Repetitive origination of advertisements are addressed by OSPF
mandating a limit on the frequency that new instances of
particular LSA can be originated and accepted during the
procedure. The frequency at which new LSA instances may
Coltun Standards Track [Page 9]
RFC 2370 The OSPF Opaque LSA Option July 1998
originated is set equal to once every MinLSInterval seconds,
value is 5 seconds (see Section 12.4 of [OSPF]). The frequency
which new LSA instances are accepted during flooding is once
MinLSArrival seconds, whose value is set to 1 (see Section 13,
Appendix B and G.5 of [OSPF]).
Proper operation of the OSPF protocol requires that all OSPF
maintain an identical copy of the OSPF link-state database. However
when the size of the link-state database becomes very large,
routers may be unable to keep the entire database due to
shortages; we term this "database overflow". When database
is anticipated, the routers with limited resources can
accommodated by configuring OSPF stub areas and NSSAs. [OVERFLOW
details a way of gracefully handling unanticipated
overflows
7.0 IANA
Opaque types are maintained by the IANA. Extensions to OSPF
require a new Opaque type must be reviewed by the OSPF working group
In the event that the OSPF working group has disbanded the
shall be performed by a recommended Designated Expert
Following the policies outlined in [IANA], Opaque type values in
range of 0-127 are allocated through an IETF Consensus action
Opaque type values in the range of 128-255 are reserved for
and experimental use
8.0
[ARA] Coltun, R., and J. Heinanen, "The OSPF Address
Advertisement Option", Work in Progress
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits",
1793, April 1995.
[DIGI] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Signatures", RFC 2154, June 1997.
[IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", Work in Progress
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
1994.
Coltun Standards Track [Page 10]
RFC 2370 The OSPF Opaque LSA Option July 1998
[NSSA] Coltun, R., and V. Fuller, "The OSPF NSSA Option", RFC 1587,
March 1994.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFMIB] Baker, F., and R. Coltun, "OSPF Version 2
Information Base", RFC 1850, November 1995.
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765,
March 1995.
9.0 Author's
Rob
FORE
Phone: (703) 245-4543
EMail: rcoltun@fore.
Coltun Standards Track [Page 11]
RFC 2370 The OSPF Opaque LSA Option July 1998
Appendix A: OSPF Data
This appendix describes the format of the Options Field followed
the packet format of the Opaque LSA
A.1 The Options
The OSPF Options field is present in OSPF Hello packets,
Description packets and all link-state advertisements. The
field enables OSPF routers to support (or not support)
capabilities, and to communicate their capability level to other
routers. Through this mechanism routers of differing capabilities
be mixed within an OSPF routing domain
When used in Hello packets, the Options field allows a router
reject a neighbor because of a capability mismatch. Alternatively
when capabilities are exchanged in Database Description packets
router can choose not to forward certain link-state advertisements
a neighbor because of its reduced functionality. Lastly,
capabilities in link-state advertisements allows routers to
traffic around reduced functionality routers by excluding them
parts of the routing table calculation
Six bits of the OSPF Options field have been assigned, although
the O-bit is described completely by this memo. Each bit
described briefly below. Routers should reset (i.e., clear
unrecognized bits in the Options field when sending Hello packets
Database Description packets and when originating link-
advertisements. Conversely, routers encountering unrecognized
bits in received Hello Packets, Database Description packets
link-state advertisements should ignore the capability and
the packet/advertisement normally
+------------------------------------+
| * | O | DC | EA | N/P | MC | E | * |
+------------------------------------+
The Options
E-
This bit describes the way AS-external-LSAs are flooded,
described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF].
MC-
This bit describes whether IP multicast datagrams are
according to the specifications in [MOSPF].
Coltun Standards Track [Page 12]
RFC 2370 The OSPF Opaque LSA Option July 1998
N/P-
This bit describes the handling of Type-7 LSAs, as specified
[NSSA].
DC-
This bit describes the router's handling of demand circuits,
specified in [DEMD].
EA-
This bit describes the router's willingness to receive
forward External-Attributes-LSAs, as specified in [EAL].
O-
This bit describes the router's willingness to receive
forward Opaque-LSAs as specified in this document
A.2 The Opaque
Opaque LSAs are Type 9, 10 and 11 link-state advertisements.
advertisements may be used directly by OSPF or indirectly by
application wishing to distribute information throughout the
domain. The function of the Opaque LSA option is to provide
future extensibility of OSPF
Opaque LSAs contain some number of octets (of application-
data) padded to 32-bit alignment. Like any other LSA, the Opaque
uses the link-state database distribution mechanism for flooding
information throughout the topology. However, the Opaque LSA has
flooding scope associated with it so that the scope of flooding
be link-local (type 9), area-local (type 10) or the entire
routing domain (type 11). Section 3 of this document describes
flooding procedures for the Opaque LSA
Coltun Standards Track [Page 13]
RFC 2370 The OSPF Opaque LSA Option July 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9, 10 or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| ... |
Link-State
The link-state type of the Opaque LSA identifies the LSA's range
topological distribution. This range is referred to as the
Scope. The following explains the flooding scope of each of
link-state types
o A value of 9 denotes a link-local scope. Opaque LSAs with
link-local scope are not flooded beyond the local (sub)network
o A value of 10 denotes an area-local scope. Opaque LSAs with
area-local scope are not flooded beyond the area that they
originated into
o A value of 11 denotes that the LSA is flooded throughout
Autonomous System (e.g., has the same scope as type-5 LSAs).
Opaque LSAs with AS-wide scope are not flooded into stub areas
Syntax Of The Opaque LSA's Link-State
The link-state ID of the Opaque LSA is divided into an Opaque
field (the first 8 bits) and an Opaque ID (the remaining 24 bits).
See section 7.0 of this document for a description of Opaque
allocation and assignment
Coltun Standards Track [Page 14]
RFC 2370 The OSPF Opaque LSA Option July 1998
Appendix B. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Coltun Standards Track [Page 15]
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
