As per Relevance of the word notification, we have this rfc below:
Network Working Group K.
Request for Comments: 1105 cisco
Y.
T.J. Watson Research Center, IBM Corp
June 1989
A Border Gateway Protocol (BGP
Status of this
This RFC outlines a specific approach for the exchange of
reachability information between Autonomous Systems
At the time of this writing, the Border Gateway
implementations exist for cisco routers as well as for the
Nodal Switching Systems. A public domain version for "gated"
currently being implemented
Distribution of this memo is unlimited
1.
The Border Gateway Protocol (BGP) is an inter-autonomous
routing protocol. It is built on experience gained with EGP
defined in RFC 904 [1] and EGP usage in the NSFNET Backbone
described in RFC 1092 [2] and RFC 1093 [3].
The primary function of a BGP speaking system is to exchange
reachability information with other BGP systems. This
reachability information includes information on the
systems (AS's) that traffic must transit to reach these networks
This information is sufficient to construct a graph of
connectivity from which routing loops may be pruned and
decisions at an AS level may be enforced
BGP runs over a reliable transport level protocol. This
the need to implement explicit update fragmentation, retransmission
acknowledgement, and sequencing. Any authentication scheme used
the transport protocol may be used in addition to BGP's
authentication mechanisms
The initial BGP implementation is based on TCP [4], however
reliable transport may be used. A message passing protocol such
VMTP [5] might be more natural for BGP. TCP will be used, however
since it is present in virtually all commercial routers and hosts
In the following descriptions the phrase "transport
connection" can be understood to refer to a TCP connection. BGP
TCP port 179 for establishing its connections
Lougheed & Rekhter [Page 1]
RFC 1105 BGP June 1989
2. Summary of
Two hosts form a transport protocol connection between one another
They exchange messages to open and confirm the connection parameters
The initial data flow is the entire BGP routing table.
updates are sent as the routing tables change. Keepalive
are sent periodically to ensure the liveness of the connection
Notification messages are sent in response to errors or
conditions. If a connection encounters an error condition,
notification message is sent and the connection is optionally closed
The hosts executing the Border Gateway Protocol need not be routers
A non-routing host could exchange routing information with
via EGP or even an interior routing protocol. That non-routing
could then use BGP to exchange routing information with a
gateway in another autonomous system. The implications
applications of this architecture are for further study
If a particular AS has more than one BGP gateway, then all
gateways should have a consistent view of routing. A consistent
of the interior routes of the autonomous system is provided by
intra-AS routing protocol. A consistent view of the routes
to the AS may be provided in a variety of ways. One way is to
the BGP protocol to exchange routing information between the
gateways within a single AS. In this case, in order to
consist routing information, these gateways MUST have direct
sessions with each other (the BGP sessions should form a
graph). Note that this requirement does not imply that all
gateways within a single AS must have direct links to each other
other methods may be used to ensure consistent routing information
3. Message
This section describes message formats and actions to be taken
errors are detected while processing these messages
Messages are sent over a reliable transport protocol connection.
message is processed after it is entirely received. The
message size is 1024 bytes. All implementations are required
support this maximum message size. The smallest message that may
sent consists of a BGP header without a data portion, or 8 bytes
The phrase "the BGP connection is closed" means that the
protocol connection has been closed and that all resources for
BGP connection have been deallocated. Routing table
associated with the remote peer are marked as invalid.
information is passed to other BGP peers before being deleted
the system
Lougheed & Rekhter [Page 2]
RFC 1105 BGP June 1989
3.1 Message Header
Each message has a fixed size header. There may or may not be a
portion following the header, depending on the message type.
layout of these fields is shown below
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Marker | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Marker: 16
The Marker field is 16 bits of all ones. This field is used
mark the start of a message. If the first two bytes of a
are not all ones then we have a synchronization error and the
connection should be closed after sending a notification
with opcode 5 (connection not synchronized). No notification
is sent
Length: 16
The Length field is 16 bits. It is the total length of
message, incluluding header, in bytes. If an illegal length
encountered (more than 1024 bytes or less than 8 bytes),
notification message with opcode 6 (bad message length) and
data bytes of the bad length should be sent and the BGP
closed
Version: 8
The Version field is 8 bits of protocol version number.
current BGP version number is 1. If a bad version number
found, a notification message with opcode 8 (bad version number
should be sent and the BGP connection closed. The bad
number should be included in one byte of notification data
Type: 8
The Type field is 8 bits of message type code. The following
codes are defined
Lougheed & Rekhter [Page 3]
RFC 1105 BGP June 1989
1 -
2 -
3 -
4 -
5 - OPEN
If an unrecognized type value is found, a notification
with opcode 7 (bad type code) and data consisting of the byte
type field in question should be sent and the BGP
closed
Hold Timer: 16 bits
This field contains the number of seconds that may elapse
receiving a BGP KEEPALIVE or BGP UPDATE message from our BGP
before we declare an error and close the BGP connection
3.2 OPEN Message
After a transport protocol connection is established, the
message sent by either side is an OPEN message. If the OPEN
is acceptable, an OPEN CONFIRM message confirming the OPEN is
back. Once the OPEN is confirmed, UPDATE, KEEPALIVE,
NOTIFICATION messages may be exchanged
In addition to the fixed size BGP header, the OPEN message
the following fields
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System | Link Type | Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
My Autonomous System: 16
This field is our 16 bit autonomous system number. If there is
problem with this field, a notification message with opcode 9
(invalid AS field) should be sent and the BGP connection closed
No notification data is sent
Link Type: 8
The Link Type field is a single octet containing one of
Lougheed & Rekhter [Page 4]
RFC 1105 BGP June 1989
following codes defining our position in the AS graph relative
our peer
0 -
1 -
2 -
3 - H-
UP indicates the peer is higher in the AS hierarchy,
indicates lower, and H-LINK indicates at the same level.
indicates that the peer is another BGP speaking host in
autonomous system. INTERNAL links are used to keep AS
information consistent with an AS with multiple border gateways
If the Link Type field is unacceptable, a notification
with opcode 1 (link type error in open) and data consisting of
expected link type should be sent and the BGP connection closed
The acceptable values for the Link Type fields of two BGP
are discussed below
Authentication Code: 8
The Authentication Code field is an octet whose value
the authentication mechanism being used. A value of
indicates no BGP authentication. Note that a
authentication mechanism may be used in establishing the
level connection. If the authentication code is not recognized,
notification message with opcode 2 (unknown authentication code
and no data is sent and the BGP connection is closed
Authentication Data: variable
The Authentication Data field is a variable length
containing authentication data. If the value of
Code field is zero, the Authentication Data field has zero length
If authentication fails, a notification message with opcode 3
(authentication failure) and no data is sent and the
connection is closed
3.3 OPEN CONFIRM Message
An OPEN CONFIRM message is sent after receiving an OPEN message
This completes the BGP connection setup. UPDATE, NOTIFICATION,
KEEPALIVE messages may now be exchanged
An OPEN CONFIRM message consists of a BGP header with an OPEN
type code. There is no data in an OPEN CONFIRM message
Lougheed & Rekhter [Page 5]
RFC 1105 BGP June 1989
3.4 UPDATE Message
UPDATE messages are used to transfer routing information between
peers. The information in the UPDATE packet can be used to
a graph describing the relationships of the various
systems. By applying rules to be discussed, routing
loops and some other anomalies may be detected and removed from
inter-AS routing
Whenever an error in a UPDATE message is detected, a
message is sent with opcode 4 (bad update), a two byte
describing the nature of the problem, and a data field consisting
as much of the UPDATE message data portion as possible.
messages have the following format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS count | Direction | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repeat (Direction, AS Number) pairs AS count times |
/ /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Net Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| repeat (Network, Metric) pairs Net Count times |
/ /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gateway: 32 bits
The Gateway field is the address of a gateway that has routes
the Internet networks listed in the rest of the UPDATE message
This gateway MUST belong to the same AS as the BGP peer
advertises it. If there is a problem with the gateway field,
notification message with subcode 6 (invalid gateway field)
sent
Lougheed & Rekhter [Page 6]
RFC 1105 BGP June 1989
AS count: 8 bits
This field is the count of Direction and AS Number pairs in
UPDATE message. If an incorrect AS count field is detected
subcode 1 (invalid AS count) is specified in the
message
Direction: 8
The Direction field is an octet containing the direction taken
the routing information when exiting the AS defined by
succeeding AS Number field. The following values are defined
1 - UP (went up a link in the graph
2 - DOWN (went down a link in the graph
3 - H_LINK (horizontal link in the graph
4 - EGP_LINK (EGP derived information
5 - INCOMPLETE (incomplete information
There is a special provision to pass exterior learned (non-BGP
routes over BGP. If an EGP learned route is passed over BGP,
the Direction field is set to EGP-LINK and the AS Number field
set to the AS number of the EGP peer that advertised this route
All other exterior-learned routes (non-BGP and non-EGP) may
passed by setting AS Number field to zero and Direction field
INCOMPLETE. If the direction code is not recognized,
notification message with subcode 2 (invalid direction code)
sent
AS Number: 16
This field is the AS number that transmitted the
information. If there is a problem with this AS number,
notification message with subcode 3 (invalid autonomous system)
sent
Net Count: 16 bits
The Net Count field is the number of Metric and Network
pairs which follow this field. If there is a problem with
field, a notification with subcode 7 (invalid net count field)
sent
Network: 32
The Network field is four bytes of Internet network number.
there is a problem with the network field, a notification
with subcode 8 (invalid network field) is sent
Lougheed & Rekhter [Page 7]
RFC 1105 BGP June 1989
Metric: 16
The Metric field is 16 bits of an unspecified metric. BGP
are comparable ONLY if routes have exactly the same AS path.
metric of all ones indicates the network is unreachable. In
other cases the metric field is MEANINGLESS and MUST BE IGNORED
There are no illegal metric values
3.5 NOTIFICATION Message
NOTIFICATION messages are sent when an error condition is detected
The BGP connection is closed shortly after sending the
message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opcode: 16
The Opcode field describes the type of NOTIFICATION.
following opcodes have been defined
1 (*) - link type error in open. Data is one byte of
link type
2 (*) - unknown authentication code. No data
3 (*) - authentication failure. No data
4 - update error. See below for data description
5 (*) - connection out of sync. No data
6 (*) - invalid message length. Data is two bytes
bad length
7 (*) - invalid message type. Data is one byte of
message type
8 (*) - invalid version number. Data is one byte
bad version
9 (*) - invalid AS field in OPEN. No data
10 (*) - BGP Cease. No data
The starred opcodes in the list above are considered fatal
and cause transport connection termination
The update error (opcode 4) has as data 16 bits of
followed by the last UPDATE message in question. After
subcode comes as much of the data portion of the UPDATE
Lougheed & Rekhter [Page 8]
RFC 1105 BGP June 1989
question as possible. The following subcodes are defined
1 - invalid AS
2 - invalid direction
3 - invalid autonomous
4 - EGP_LINK or INCOMPLETE_LINK link type at other
the end of the AS path
5 - routing
6 - invalid gateway
7 - invalid Net Count
8 - invalid network
Data:
The Data field contains zero or more bytes of data to be used
diagnosing the reason for the NOTIFICATION. The contents of
Data field depend upon the opcode. See the opcode
above for more details
3.6 KEEPALIVE Message
BGP does not use any transport protocol based keepalive mechanism
determine if peers are reachable. Instead KEEPALIVE messages
exchanged between peers often enough as not to cause the hold
(as advertised in the BGP header) to expire. A reasonable
frequency of KEEPALIVE exchange would be one third of the Hold
interval
As soon as the Hold Time associated with BGP peer has expired,
BGP connection is closed and BGP deallocates all resources
with this peer
The KEEPALIVE message is a BGP header without any data
4. BGP Finite State machine
This section specifies BGP operation in terms of a Finite
Machine (FSM). Following is a brief summary and overview of
operations by state as determined by this FSM. A condensed
of the BGP FSM is found in Appendix 1.
Initially BGP is in the BGP_Idle state
BGP_Idle state
In this state BGP refuses all incoming BGP connections.
resources are allocated to the BGP neighbor. In response to
Start event (initiated by either system or operator) the
Lougheed & Rekhter [Page 9]
RFC 1105 BGP June 1989
system initializes all BGP resources and changes its state
BGP_Active
BGP_Active state
In this state BGP is trying to acquire a BGP neighbor by opening
transport protocol connection. If the transport protocol
fails (for example, retransmission timeout), BGP stays in
BGP_Active state
Otherwise, the local system sends an OPEN message to its peer
and changes its state to BGP_OpenSent. Since the hold time of
peer is still undetermined, the hold time is initialized to
large value
In response to the Stop event (initiated by either system
operator) the local system releases all BGP resources and
its state to BGP_Idle
BGP_OpenSent state
In this state BGP waits for an OPEN message from its peer.
an OPEN message is received, all fields are checked
correctness. If the initial BGP header checking detects an error
BGP deallocates all resources associated with this peer
returns to the BGP_Active state. Otherwise, the Link Type
Authentication Code, and Authentication Data fields are
for correctness
If the link type is incorrect, a NOTIFICATION message with
1 (link type error in open) is sent. The following combination
link type fields are correct; all other combinations are invalid
Our view Peer
UP
DOWN
INTERNAL
H-LINK H-
If the link between two peers is INTERNAL, then AS number of
peers must be the same. Otherwise, a NOTIFICATION message
opcode 1 (link type error in open) is sent
If both peers have the same AS number and the link type
these peers is not INTERNAL, then a NOTIFICATION message
opcode 1 (link type error in open) is sent
If the value of the Authentication Code field is zero,
Lougheed & Rekhter [Page 10]
RFC 1105 BGP June 1989
information in the Authentication Data field (if present)
ignored. If the Authentication Code field is non-zero it
checked for known authentication codes. If authentication code
unknown, then the BGP NOTIFICATION message with opcode 2 (
authentication code) is sent
If the Authentication Code value is non-zero, then
corresponding authentication procedure is invoked. The
values are a zero Authentication Code and no Authentication Data
If any of the above tests detect an error, the local system
the BGP connection and changes its state to BGP_Idle
If there are no errors in the BGP OPEN message, BGP sends an
CONFIRM message and goes into the BGP_OpenConfirm state. At
point the hold timer which was originally set to some
large value (see above) is replaced with the value indicated
the OPEN message
If disconnect notification is received from the
transport protocol or if the hold time expires, the local
closes the BGP connection and changes its state to BGP_Idle
BGP_OpenConfirm state
In this state BGP waits for an OPEN CONFIRM message. As soon
this message is received, BGP changes its state
BGP_Established. If the hold timer expires before an OPEN
message is received, the local system closes the BGP
and changes its state to BGP_Idle
BGP_Established state
In the BGP_Established state BGP can exchange UPDATE
NOTIFICATION, and KEEPALIVE messages with its peer
If disconnect notification is received from the
transport protocol or if the hold time expires, the local
closes the BGP connection and changes its state to BGP_Idle
In response to the Stop event initiated by either the system
operator, the local system sends a NOTIFICATION message
opcode 10 (BGP Cease), closes the BGP connection, and changes
state to BGP_Idle
Lougheed & Rekhter [Page 11]
RFC 1105 BGP June 1989
5. UPDATE Message
A BGP UPDATE message may be received only in the BGP_
state. When a BGP UPDATE message is received, each field is
for validity. When a NOTIFICATION message is sent regarding
UPDATE, the opcode is always 4 (update error), the subcode depends
the type of error, and the rest of the data field is as much
possible of the data portion of the UPDATE that caused the error
If the Gateway field is incorrect, a BGP NOTIFICATION message is
with subcode 6 (invalid gateway field). All information in
UPDATE message is discarded
If the AS Count field is less than or equal to zero, a
NOTIFICATION is sent with subcode 1 (invalid AS count). Otherwise
the complete AS path is extracted and checked as described below
If one of the Direction fields in the AS route list is not defined,
BGP NOTIFICATION message is with subcode 2 (invalid direction code).
If one of the AS Number fields in the AS route list is incorrect,
BGP NOTIFICATION message is sent with subcode 3 (invalid
system).
If either a EGP_LINK or a INCOMPLETE_LINK link type occurs at
than the end of the AS path, a BGP NOTIFICATION message is sent
subcode 4 (EGP_LINK or INCOMPLETE_LINK link type at other than
end of the AS path list).
If none of the above tests failed, the full AS route is checked
AS loops
AS loop detection is done by scanning the full AS route and
that each AS in this route occurs only once. If an AS loop
detected, a BGP NOTIFICATION message is sent with subcode 5 (
loop).
If any of the above errors are detected, no further processing
done. Otherwise, the complete AS path is correct and the rest of
UPDATE message is processed
If the Net Count field is incorrect, a BGP NOTIFICATION message
sent with subcode 7 (invalid Net Count field).
Each network and metric pair listed in the BGP UPDATE message
checked for a valid network number. If the Network field
incorrect, a BGP Notification message is sent with subcode 8 (
network field). No checking is done on the metric field. It is
Lougheed & Rekhter [Page 12]
RFC 1105 BGP June 1989
to a particular implementation to decide whether to
processing or terminate it upon the first incorrect network
If the network, its complete AS path, and the gateway are correct
then the route is compared with other routes to the same network.
the new route is better than the current one, then it is flooded
other BGP peers as follows
- If the BGP UPDATE was received over the INTERNAL link, it is
propagated over any other INTERNAL link. This restriction
due to the fact that all BGP gateways within a single
form a completely connected graph (see above).
- Before sending a BGP UPDATE message over the non-INTERNAL links
check the AS path to insure that doing so would not cause
routing loop. The BGP UPDATE message is then propagated (
to the local policy restrictions) over any of the non-
link of a routing loop would not result
- If the BGP UPDATE message is propagated over a non-INTERNAL link
then the current AS number and link type of the link over
it is going to be propagated is prepended to the full AS
and the AS count field is incremented by 1. If the BGP
message is propagated over an INTERNAL link, then the full
path passed unmodified and the AS count stays the same.
Gateway field is replaced with the sender's own address
6.
We would like to express our thanks to Len Bosack (cisco Systems),
Jeff Honig (Cornell University) and all members of the IWG task
for their contributions to this document
Lougheed & Rekhter [Page 13]
RFC 1105 BGP June 1989
Appendix 1
BGP FSM State Transitions and Actions
This Appendix discusses the transitions between states in the BGP
in response to BGP events. The following is the list of these
and events
BGP States
1 - BGP_
2 - BGP_
3 - BGP_
4 - BGP_
5 - BGP_
BGP Events
1 - BGP
2 - BGP Transport connection
3 - BGP Transport connection
4 - BGP Transport connection open
5 - Receive OPEN
6 - Receive OPEN CONFIRM
7 - Receive KEEPALIVE
8 - Receive UPDATE
9 - Receive NOTIFICATION
10 - Holdtime timer
11 - KeepAlive timer
12 - Receive CEASE
13 - BGP
The following table describes the state transitions of the BGP
and the actions triggered by these transitions
Lougheed & Rekhter [Page 14]
RFC 1105 BGP June 1989
Event Actions Message Sent Next
--------------------------------------------------------------------
BGP_Idle (1)
1 Initialize resources none 2
BGP_Active (2)
2 Initialize resources OPEN 3
4 none none 2
13 Release resources none 1
BGP_OpenSent(3)
3 none none 1
5 Process OPEN is OK OPEN CONFIRM 4
Process OPEN Message failed NOTIFICATION 1
11 Restart KeepAlive timer KEEPALIVE 3
13 Release resources none 1
BGP_OpenConfirm (4)
6 Complete initialization none 5
3 none none 1
10 Close transport connection none 1
11 Restart KeepAlive timer KEEPALIVE 4
13 Release resources none 1
BGP_Established (5)
7 Process KEEPALIVE none 5
8 Process UPDATE is OK UPDATE 5
Process UPDATE failed NOTIFICATION 5
9 Process NOTIFICATION none 5
10 Close transport connection none 1
11 Restart KeepAlive timer KEEPALIVE 5
12 Close transport connection NOTIFICATION 1
13 Release resources none 1
--------------------------------------------------------------------
All other state-event combinations are considered fatal errors
cause the termination of the BGP transport connection (if necessary
and a transition to the BGP_Idle state
Lougheed & Rekhter [Page 15]
RFC 1105 BGP June 1989
The following is a condensed version of the above state
table
Events|BGP_Idle BGP_Active BGP_OpenSent BGP_OpenConfirm BGP_
| (1) | (2) | (3) | (4) | (5)
|-------------------------------------------------------------
1 | 2 | | | |
| | | | |
2 | | 3 | | |
| | | | |
3 | | | 1 | 1 |
| | | | |
4 | | 2 | | |
| | | | |
5 | | | 4 or 1 | |
| | | | |
6 | | | | 5 |
| | | | |
7 | | | | | 5
| | | | |
8 | | | | | 5
| | | | |
9 | | | | | 5
| | | | |
10 | | | | 1 | 1
| | | | |
11 | | | 3 | 4 | 5
| | | | |
12 | | | | | 1
| | | | |
13 | | 1 | 1 | 1 | 1
| | | | |
--------------------------------------------------------------
Lougheed & Rekhter [Page 16]
RFC 1105 BGP June 1989
[1] Mills, D., "Exterior Gateway Protocol Formal Specification",
904, BBN, April 1984.
[2] Rekhter, Y., "EGP and Policy Based Routing in the New
Backbone", RFC 1092, T. J. Watson Research Center, February 1989.
[3] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
MERIT/NSFNET Project, February 1989.
[4] Postel, J., "Transmission Control Protocol - DARPA
Program Protocol Specification", RFC 793, DARPA, September 1981.
[5] Cheriton, D., "VMTP: Versatile Message Transaction Protocol",
1045, Stanford University, February 1988.
Authors'
Kirk
cisco Systems, Inc
1360 Willow Road, Suite 201
Menlo Park, CA 94025
Phone: (415) 326-1941
Email: LOUGHEED@MATHOM.CISCO.
Jacob
T.J. Watson Research
IBM
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
Email: YAKOV@IBM.
Lougheed & Rekhter [Page 17]
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
