As per Relevance of the word announce, we have this rfc below:
Network Working Group J.
Request for Comments: 1133 H-W.
Merit Computer
November 1989
Routing between the NSFNET and the
Status of this
This document is a case study of the implementation of
between the NSFNET and the DDN components (the MILNET and
ARPANET). We hope that it can be used to expand
interconnection of other Administrative Domains. We would
discussion and suggestions about the methods employed for
interconnections. No standards are specified in this memo
Distribution of this memo is unlimited
1. Definitions for this
The NSFNET is the backbone network of the National
Foundation's computer network infrastructure. It
multiple autonomously administered mid-level networks, which in
connect autonomously administered networks of campuses and
centers. The NSFNET connects to multiple peer networks consisting
national network infrastructures of other federal agencies. One
these peer networks is the Defense Data Network (DDN) which, for
sake of this discussion, should be viewed as the combination of
DoD's MILNET and ARPANET component networks, both of which
national in scope
It should be pointed out that network announcements in one
result in traffic the other direction, e.g., a network
via a specific interconnection between the NSFNET to the DDN
in packet traffic via the same interconnection between the DDN to
NSFNET
2. NSFNET/DDN routing until mid '89
Until mid-1989, the NSFNET and the DDN were connected via a
intermediate routers which in turn were connected to the ARPANET
These routers exchanged network reachability information via
Exterior Gateway Protocol (EGP) with the NSFNET nodes as well as
the DDN Mailbridges. In the context of network routing
Mailbridges can be viewed as route servers, which exchange
network reachability information via EGP while using a
protocol to exchange routing information among themselves
Currently, there are three Mailbridges at east coast locations
Yu & Braun [Page 1]
RFC 1133 Routing between the NSFNET and the DDN November 1989
three Mailbridges at west coast locations. Besides functioning
route servers the Mailbridges also provide for connectivity, i.e
packet switching, between the ARPANET and the MILNET
The intermediate systems between the NSFNET and the ARPANET
under separate administrative control, typically by a NSFNET mid
level network
For a period of time, the traffic between the NSFNET and the DDN
carried by three ARPANET gateways. These ARPANET gateways were
the administrative control of a NSFNET mid-level network or
site and had direct connections to both a NSFNET NSS and an
PSN. These routers had simultaneous EGP sessions with a NSFNET
as well as a DDN Mailbridge. This resulted in making them
as packet switches between the two peer networks. As network
were established packets were switched between the NSFNET and
DDN
The NSFNET used three NSFNET/ARPANET gateways which had been
by three different sites for redundancy purposes. Those three
were initially at Cornell University, the University of
(UC), and Merit. When the ARPANET connections at Cornell
and the University of Illinois (UC) were terminated, a similar
was introduced at the Pittsburgh Supercomputer Center and at the
von Neumann Supercomputer Center which, together with the
connection, allowed for continued redundancy
As described in RFC1092 and RFC1093, NSFNET routing is controlled
a distributed policy routing database that controls the
and distribution of routing information. This control also
to the NSFNET/ARPANET gateways
2.1 Inbound announcement -- Routes announced from the DDN to
In the case of the three NSFNET/ARPANET gateways, each of
associated NSSs accepted the DDN routes at a different metric.
route with the lowest metric then was favored for the traffic
the specific DDN network, but had that specific gateway to the
experienced problems with loss of routing information, one of
redundant gateways would take over and carry the load as a
path. Assuming consistent DDN routing information at any of
three gateways, as received from the Mailbridges, only a
NSFNET/ARPANET gateway was used at a given time for traffic from
NSFNET towards the DDN, with two further gateways standing by as
backups. The metric for network announcements from the DDN to
NSFNET was coordinated by the Merit/NSFNET project
Yu & Braun [Page 2]
RFC 1133 Routing between the NSFNET and the DDN November 1989
2.2 Outbound announcement -- Routes announced from the NSFNET to
Each NSS involved with NSFNET/DDN routing had an EGP peer
with the NSFNET/ARPANET gateway. Via EGP it announced a certain
of NSFNET connected networks, again, as controlled by the
policy routing database, to its peer. The NSFNET/ARPANET
then redistributed the networks it had learned from the NSS to
DDN via a separate EGP session. Each of the NSFNET/ARPANET
used a separate Autonomous System number to communicate
information with the DDN. Also these Autonomous System numbers
not the same as the NSFNET backbone uses to communicate with
attached client networks. The NSFNET/ARPANET gateways used
Autonomous System number of the local network. The metrics
announcing network numbers to the DDN Mailbridges were set
to the requests of the mid-level network of which the
individual network was a client. Mid-level network also
the specific NSFNET/ARPANET gateway used, including primary/
selection. These primary/secondary selections among
NSFNET/ARPANET gateways allowed for redundancy, while the
of network announcements was modulated by the metric used for
announcements to the DDN from the NSFNET/ARPANET gateways. Some
the selection decisions were based on reliability of a
gateway or congestion expected in a specific PSN that connected
the NSFNET/ARPANET gateway
2.3 Administrative
From an administrative point of view, the NSFNET/ARPANET
were administered by the institution to which the gateway belonged
This has never been a real problem due to the excellent
received from all the involved sites
3. NSFNET/DDN routing via attached
During the first half of 1989 a new means of
between the NSFNET and the DDN was designed and implemented
Ethernet adapters were installed in two of the Mailbridges,
previously just connected the MILNET and the ARPANET, allowing
direct interface to NSFNET nodes. Of these two Mailbridges one
located on the west coast at NASA-Ames located at Moffett Field, CA
and the other one is located on the east coast at Mitre in Reston
VA. With this direct interconnection it became possible for
NSFNET to exchange routing information directly with the DDN
servers, without a gateway operated by a mid-level network in
middle. This also eliminated the need to traverse the ARPANET
order to reach MILNET sites. It furthermore allows the
Communication Agency as well as the National Science Foundation
Yu & Braun [Page 3]
RFC 1133 Routing between the NSFNET and the DDN November 1989
exercise control over the interconnection on a need basis, e.g.,
connectivity can now be easily disabled from either site at times
tighter network security concerns
3.1 Inbound announcement -- Routes announced from the DDN to
The routing setup for the direct Mailbridge connections is
different, as compared to the previously used NSFNET/
gateways. Instead of a single NSFNET/ARPANET gateway carrying
the traffic from the DDN to the NSFNET at any moment,
distribution of network numbers is now split between the
Mailbridges. This results in a distributed load, with
network numbers always preferring a particular Mailbridge
normal operating circumstances. In the case of an outage at one
the Mailbridge connections, the other one fully takes over the
for all the involved network numbers. For this setup, the two
links are known as two different Autonomous System numbers by
NSFNET. The routes learned via the NASA-Ames Mailbridges are part
the Autonomous System 164 which is also the Autonomous System
which the Mailbridges are using by themselves during the EGP session
In the case of the EGP sessions with the Mitre Mailbridge, the DDN
internal Autonomous System number of 164 is overwritten with
different Autonomous System number (in this case 184) and the
learned via the Mitre Mailbridge will therefore become part
Autonomous System 184 within the NSFNET
The NSFNET-inbound routing is controlled by the distributed
routing database. In particular, the network number is
against a list of legitimate networks, and a metric is
with an authorized network number for a particular site.
example, both NSSs in Palo Alto and College Park learn net 10 (
ARPANET network number) from the Mailbridges they are connected
and have EGP sessions. The Palo Alto NSS will accept Net 10 with
metric of 10, while the College Park NSS will accept the same
number with a metric of 12. Therefore, traffic destinated to net 10
will prefer the path via the Palo Alto NSS and the NASA-
Mailbridge. If the connection via the NASA-Ames Mailbridge is
functioning, the traffic will be re-routed via the Mailbridge link
Mitre. Each of the two NSS accepts half of the network routes
EGP from its co- located Mailbridge at a lower metric and the
half at a higher metric. The half with the lower metric at the
Alto NSS will be the same set which uses a higher metric at
College Park NSS and vice versa
There are at least three different possibilities about how the
could select a path to a DDN network via a specific Mailbridge, i.e.,
the one at NASA-Ames versus the one at Mitre
Yu & Braun [Page 4]
RFC 1133 Routing between the NSFNET and the DDN November 1989
1. Assign a primary path for all DDN networks to a
Mailbridge and use the other purely as a backup path
2. Distribute the DDN networks randomly across the
Mailbridges
3. Let the DDN administration inform the NSFNET which
on the DDN are closer to a specific Mailbridge so that
particular Mailbridge would accept these networks at a
metric. The second Mailbridge would then function as a
path. From a NSFNET point of view, this would mean treating
DDN like other NSFNET peer networks such as the NASA
network (NSN) or DOE's Energy Science Network (ESNET).
We are currently using alternative (2) as an interim solution.
this time, the DDN administration is having discussions with
about moving to alternative (3), which would allow them control
how the DDN networks would be treated in the NSFNET
3.2 Outbound announcement -- Routes announced from the NSFNET to
The selection of metrics for announcements of NSFNET networks to
DDN is controlled by the NSFNET. The criteria for the
decisions is based on distances between the NSS, which introduces
specific network into the NSFNET, and either one of the NSSs that
a co-located Mailbridge. In this context, the distance
into the hop count between NSSs in the NSFNET backbone. For example
the Princeton NSS is currently one hop away from the NSS co-
with the Mitre Mailbridge, but is three hops away from the NSS
the NASA-Ames Mailbridge. Therefore, in the case of networks
primary paths via the Princeton NSS, the Mitre Mailbridge
receive the announcements for those networks at a lower metric
the NASA-Ames Mailbridge. This means that the traffic from the
to networks connected to the Princeton NSS will be routed through
Mailbridge at Mitre to the College Park NSS and then through
Princeton NSS to its final destination. This will guarantee
traffic entering the NSFNET from the DDN will take the shortest
to its NSFNET destination under normal operating conditions
3.3 Administrative
Any of the networks connected via the NSFNET can be provided with
connectivity to the DDN via the NSFNET upon request from the mid
level network through which the specific network is connected
For networks that do not have a DDN connection other than via NSFNET
the NSFNET will announce the nets via one of the Mailbridges with
Yu & Braun [Page 5]
RFC 1133 Routing between the NSFNET and the DDN November 1989
low metric to create a primary path (e.g., metric "1") and via
second Mailbridge as a secondary path (e.g., metric "3").
networks that have their own DDN connection and wish to use
NSFNET as a backup connection to DDN, the NSFNET will announce
networks via the two Mailbridges at higher metrics
The mid-level networks need to make a specific request if they
client networks to be announced to the DDN via the NSFNET.
requests need to state whether this would be a primary connection
the specific networks. If the request is for a fallback connection
it needs to state the existing metrics in use for announcements
the network to the DDN
4. Shortcomings of the current NSFNET/DDN interconnection
The current setup makes full use of the two Mailbridges that
to the NSFNET directly, with regard to redundancy and load sharing
However, with regard to performance optimization, such as
propagation delay between source/destination pairs located
disjoint peer networks, there are some shortcomings.
shortcomings are not easy to overcome because of the limitations
the current architecture. However, it is a worthwhile topic
discussion to aid future improvements
To make the discussion easier, the following assumptions
terminology will be used
The NSFNET is viewed as a cloud and so is the DDN. The two
two connections, one at east coast and one at west coast
mb-east -- the Mailbridge at
mb-west -- the Mailbridge at
NSS-east -- the NSS egp peer with mb-
NSS-west -- the NSS egp peer with mb-
DDN.east-net -- networks connected to DDN and physically closer
mb-
DDN.west-net -- networks connected to DDN and physically closer
mb-
NSF.east-net -- networks connected to NSFNET and physically
to NSS-
NSF.west-net -- networks connected to NSFNET and physically
Yu & Braun [Page 6]
RFC 1133 Routing between the NSFNET and the DDN November 1989
to NSS-
The traffic between NSFNET<->DDN will fall into the
patterns
a) NSF.east-net <-> DDN.east-net
NSF.west-net <-> DDN.west-
b) NSF.east-net <-> DDN.west-net
NSF.west-net <-> DDN.east-
The ideal traffic path for a) and b) should be as follows
For traffic pattern a
NSF.east-net<-->NSS.east<-->mb-east<-->DDN.east-
NSF.west-net<-->NSS.west<-->mb-west<-->DDN.west-
For traffic pattern b
NSF.east-net-*->NSS.west-->mb-west-->DDN.west-net-**->mb-
|
NSF.east-net<--NSS-
NSF.west-net-*->NSS.east-->mb-east-->DDN.east-net-**->mb-
|
NSF.west-net<--NSS-
Note
-*-> is used to indicate traffic transcontinentally
the NSFNET
-**-> is used to indicate traffic transcontinentally
the DDN
The traffic for a) will transcontinentally traverse NEITHER
NSFNET backbone, NOR the DDN backbone
The traffic for b) will transcontinentally traverse NSFNET
and DDN once and only once for each
Yu & Braun [Page 7]
RFC 1133 Routing between the NSFNET and the DDN November 1989
For the current set up
The traffic path for pattern a) would have chances
transcontinentally traverse both NSFNET and DDN
The traffic path for pattern b) would have chances
transcontinentally traverse the DDN in both directions
To achieve the ideal traffic path it requires the NSFNET to
(3) as stated above, i.e., to treat the DDN like other NSFNET peer
mid-level networks. As mentioned before, discussions between
and DDN people are underway and the DDN is considering providing
NSFNET with the required information to accomplish the outlined
in the near future
At such time as this is accomplished, it will reduce the
of packet traffic unnecessarily traversing national backbones
One of the best ways to optimize the traffic between two
networks, not necessary limited to the NSFNET and the DDN, is to
to avoid letting traffic traverse a backbone with a
slower speed and/or a backbone with a significantly larger
network. For example, in the case of traffic between the NSFNET
the DDN, the NSFNET has a T1 backbone and a maximum diameter of
hops, while the DDN is a relatively slow network running largely
56Kbps. In this case the overall performance would be better
traffic would traverse the DDN as little as possible, i.e.,
the traffic has to reach a destination network outside of the DDN,
should find the closest Mailbridge to exit the DDN
The current architecture employed for DDN routing is not able
accomplish this. Firstly, the technology is designed based on a
model. It does not expect a single network to be announced
multiple places. An example for multiple announcements could be
NSSs announcing a single network number to the two Mailbridges
their different locations. Secondly, the way all the
Mailbridges exchange routing information among themselves is done
a protocol similar to EGP, and the information is then
via EGP to the DDN-external networks. In this case the
distance information and locations of network numbers is lost
neither the Mailbridges nor the external gateways will be able to
path optimization based on physical distance and/or
delay. This is not easy to change, as in the DDN the link
routing information is decoupled from the IP level routing, i.e.,
IP level routing has no information about topology of the
infrastructure. Thus, even if an external gateway to a DDN
were to learn a particular network route from two Mailbridges,
would not be able to favor one over the other DDN exit point based
Yu & Braun [Page 8]
RFC 1133 Routing between the NSFNET and the DDN November 1989
the distance to the respective Mailbridge
5.
While recent changes in the interconnection architecture between
NSFNET and DDN peer networks have resulted in significant
and reliability improvements, there are still possibilities
further improvements and rationalization of this inter-peer
routing. However, to accomplish this it would most likely
significant architectural changes within the DDN
6.
[1] Rekhter, Y., "EGP and Policy Based Routing in the New
Backbone", RFC 1092, IBM Research, February 1989.
[2] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
Merit/NSFNET Project, February 1989.
[3] Collins, M., and R. Nitzan, "ESNET Routing", DRAFT Version 1.0,
LLNL, May 1989.
[4] Braun, H-W., "Models of Policy Based Routing," RFC 1104,
Merit/NSFNET Project, February 1989.
Security
Security issues are not addressed in this memo
Authors'
Jessica (Jie Yun)
Merit Computer
1075 Beal
Ann Arbor, Michigan 48109
Telephone: 313 936-2655
Fax: 313 747-3745
EMail: jyy@merit.
Hans-Werner
Merit Computer
1075 Beal
Ann Arbor, Michigan 48109
Telephone: 313 763-4897
Fax: 313 747-3745
EMail: hwb@merit.
Yu & Braun [Page 9]
RFC 1133 Routing between the NSFNET and the DDN November 1989
Yu & Braun [Page 10]
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
