As per Relevance of the word integrated, we have this rfc below:
Network Working Group P. Gross,
Request for Comments: 1371 IETF/IESG
October 1992
Choosing a "Common IGP" for the IP
(The IESG's Recommendation to the IAB
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
Special
This document was originally prepared as an Internet
Steering Group (IESG) recommendation to the Internet
Board (IAB) in mid-summer 1991, reaching the current version by
date shown above. Although the document is now somewhat dated (e.g.,
CIDR and RIP II are not mentioned), the IESG felt it was important
publish this along with the recent OSPF Applicability Statement [11]
to help establish context and motivation
This memo presents motivation, rationale and other
background information leading to the IESG's recommendation to
IAB for a single "common IGP" for the IP portions of the Internet
In this memo, the term "common IGP" is defined, the need for a
IGP is explained, the relation of this issue to other
Internet Engineering Task Force (IETF) routing protocol
is provided, and the relation of this issue to the goal for multi
protocol integration in the Internet is explored
Finally, a specific IGP is recommended as the "common IGP" for
portions of the Internet -- the Open Shortest Path First (OSPF
routing protocol
The goal of this recommendation is for all vendors of Internet
routers to make OSPF available as one of the IGP's provided
their routers
IESG [Page 1]
RFC 1371 Choosing a "Common IGP" October 1992
Table of
1. Background .................................................... 2
2. Multiple Internet Standard Routing Protocols Possible ......... 3
3. A Common IGP .................................................. 3
4. Impact of Multi-protocol Topology and Integrated IP/CLNP Routing 3
5. Commitment to Both IP and CLNP ................................ 5
6. Some History .................................................. 5
7. IESG Recommendations .......................................... 6
7.1 Regarding the Common IGP for the IP Internet ................. 6
7.2 Regarding Integrated IP/CLNP Routing ......................... 7
7.3 Limits of the Common IGP Recommendation ...................... 7
8. References .................................................... 8
9. Security Considerations ....................................... 9
10. Author's Address ............................................. 9
1.
There is a pressing need for a high functionality non-
"common" Interior Gateway Protocol (IGP) for the TCP/IP
family. An IGP is the routing protocol used within a
administrative domain (commonly referred to as an "Autonomous System
(AS).
By "common", we simply mean a protocol that is ubiquitously
from all router vendors (as in "in common"). Users and
operators have expressed a strong need for routers from
vendors to have the capablity to interoperate within an AS
use of a common IGP
Note: Routing between AS's is handled by a different type of
protocol, called an "Exterior Gateway Protocol" ("an EGP", of
the Border Gateway Protocol [2] and "The Exterior Gateway Protocol
[3] are examples.) The issues of routing between AS's using "an"
is not considered in this memo
There are two IGPs in the Internet standards track capable of
IP traffic -- Open Shortest Path First (OSPF) [4] and Integrated IS
IS [5] (based on the OSI IS-IS). These two protocols are both
"link state" routing protocols, based on the Dijkstra algorithm
There has been substantial interaction and cooperation among
engineers involved in each effort, and the protocols share
similar features
However, there are a number of technical design differences.
noteably, OSPF has been designed solely for support of the
Protocol (IP), while Integrated IS-IS has been designed to
both IP and the OSI Connectionless Network Layer Protocol (CLNP
IESG [Page 2]
RFC 1371 Choosing a "Common IGP" October 1992
simultaneously
2. Multiple Internet Standard Routing Protocols
The Internet architecture makes a distinction between "
Gateway Protocols (IGPs)" and "Exterior Gateway Protocols (EGPs)".
IGPs are routing protocols used within an Autonomous System (AS),
EGPs are routing protocols used between different AS's
Therefore, the Internet architecture supports the use
standardization of multiple IGP routing protocols. For example,
is perfectly reasonable for one standard routing protocol to be
within one AS; while a second standard routing protocol is
within a second AS; at the same time that a non-standard
routing protocol is used within a third AS
The primary purpose for making standards is to
interoperability. Setting a protocol standard in the Internet says
in effect, "if you wish to use this protocol, you should do it
specified in the standard so that you can interoperate with
who also wish to use this protocol." It is important to
that simply specifying a standard does not, by itself, designate
requirement to use the standard. It is merely meant to
interoperability among those who choose to follow the standard
Therefore, it is reasonable for both OSPF and Integrated IS-IS to
progressed through the Internet Standards process as
(based on the criteria specified in [6]). In addition, it
possible that other IGPs may be developed and standardized in
future
3. A Common
Although the Internet architecture allows for multiple standard
routing protocols, interoperability of router products from
vendors within a single AS would be greatly facilitated if a
"common" IGP were available from all router vendors. Designating
single common IGP would have the goal of enabling multi-vendor
interoperation with a modern high functionality routing protocol
However, designating a common IGP does not mandate the use of
IGP, nor would it be meant to discourage the use of other IGPs
situations where there may be sound technical reasons to do so
4. Impact of Multi-protocol Topology and Integrated IP/CLNP
There are topology considerations which will affect the
of a "common" Internet IGP
IESG [Page 3]
RFC 1371 Choosing a "Common IGP" October 1992
The Internet requires support for a wide variety of protocol suites
If we consider only IP and OSI CLNP, then the Internet is expected
contain
1. Pure IP AS's (in which IP is used but OSI CLNP is not used);
2. Pure CLNP AS's (in which CLNP is used but IP is not used);
3. Dual IP/CLNP ASs, with a common topology (i.e., all links
routers in the AS support IP and CLNP, and a single
topology is used for both protocol suites);
4. Dual, overlapping IP/CLNP ASs with differing topologies (i.e.,
some links are dual, while some are IP-only and some
CLNP-only, resulting in different topologies for IP routing
CLNP routing).
For (1), (i.e., a pure IP environment) any IGP capable of routing
traffic could be used (e.g., OSPF or Integrated IS-IS).
For (2), (i.e., a pure CLNP environment) any IGP capable of
CLNP traffic could be used (e.g., OSI IS-IS or Integrated IS-IS).
For (3), (i.e., routing environments in which both IP and CLNP
present in a common topology) there are two possibilities for
routing
1. Separate routing protocols could be used for each
protocol suite. For example, OSPF may be used for
routes for IP traffic and OSI IS-IS may be used for
routes for OSI traffic. Or Integrated IS-IS could be used
calculating routes for IP traffic and OSI IS-IS could be
for calculating routes for CLNP traffic
This approach of using separate routing protocols and
for each supported protocol family has come to be known as "
in the Night" because the two routing protocols share
hardware/software resources of the router without ever
interacting on a protocol level
2. "Integrated routing" could be used, in which a single
protocol is used for both IP and CLNP. At this time,
IS-IS is the only choice for "integrated routing".
For (4), (i.e., routing environments in which both IP and CLNP
present but in an overlapping different topology) separate
protocols are required for the IP and CLNP environments (i.e., "
in the Night"). This is equivalent to two separates cases of (1)
IESG [Page 4]
RFC 1371 Choosing a "Common IGP" October 1992
(2), but it is pointed out here as a separate case for completeness
5. Commitment to both IP and
The IAB/IETF are committed to a timely introduction of OSI into
Internet. In recognition of this commitment, the IETF has an
area devoted to OSI integration
However, while this introduction is taking place, it is
that existing services based on IP be continued. Furthermore,
also feels that even after more widespread introduction of CLNP,
and CLNP will continue to coexist in the Internet for quite
time. This view is consistent with the IAB goal of a multi-
Internet
Therefore, the IESG has a strong commitment to the continued
for IP throughout the Internet. Maintenance of this IP
requires selection of a common IGP suitable for support of IP,
requires that this selection be based on operational experience
6. Some
In February 1990, the IESG recommended that the question
designating a "common" IGP be postponed until more information
available from each protocol. More than a year has now passed
the IESG's recommendation. There have been significant
in specification, implementation, and operational experience
each protocol. It is now reasonable to re-open the consideration
designating a "common IGP".
At the March 1991 meeting of the IETF, the IETF Routing Area
presented a set of criteria for the advancement of routing
through the Internet standards process [6]. More
regarding the IAB Internet Standards process can be found in [1].
Also, at the March 1991 meeting of the IETF, the OSPF Working
requested that OSPF be considered for advancement to Draft
Standard. The OSPF WG submitted four documents to the IETF
support its request
o a revised protocol specification to update [4];
o an SNMP Management Information Base (MIB);
o two technical reports giving a technical analysis and
experience with OSPF. These reports follow the format
in [6].
IESG [Page 5]
RFC 1371 Choosing a "Common IGP" October 1992
These four documents have now been published as [7, 8, 9, 10]
respectively
In summary for OSPF
o all features of OSPF have tested (although not all features
been used in operation),
o OSPF has been shown to operate well in several
networks containing between 10 and 30 routers
o interoperation among routers from multiple vendors has
demonstrated at organized "bakeoffs".
In May 1991, the IAB approved the IETF/IESG recommendation to
OSPF to Draft Internet Standard
Integrated IS-IS, as specified in [5], is currently a
Internet Standard. In July 1991, the status of Integrated IS-IS
as follows
o There are several separate implementations of
IS-IS under development
o Integrated IS-IS has worked well in several multi-area
networks, one containing between 20 and 30 routers
o These recent operational results have not yet been
documented. Documentation, showing satisfaction of the
given in [6] for advancing routing protocols, will be
to the IESG when Integrated IS-IS is submitted for Draft
Standard status
7. IESG
7.1 Regarding the Common IGP for the IP
Based on the available operational experience and the pressing
for a high functionality IGP for the IP protocol family, the
recommends that OSPF be designated as the common IGP for the
portions of the Internet. To help ensure that this IGP is
to all users, the IESG recommends that the IETF Router
Working Group specify OSPF as "MUST IMPLEMENT" in the
"Requirements for Internet IP Routers".
IESG [Page 6]
RFC 1371 Choosing a "Common IGP" October 1992
7.2 Regarding Integrated
As mentioned above, the IESG is commited to
environments, and expects usage of OSI CLNP to increase in
Internet over time
However, at this time, the IESG is not prepared to take a
regarding the preference of either "Ships in the Night" or
routing for such mixed routing environments. At this time,
"Ships in the Night" approach is most widely used in the Internet
Integrated routing has the potential advantage of reducing
utilization. However, additional operational experience is
before any potential advantages can be fully evaluated
Therefore, the IESG wishes to encourage implementation of
IS-IS so that a reasonable position can be determined based
operational experience. All implementers of Integrated IS-IS
encouraged to coordinate their activity with the IETF IS-IS
Group, which is actively collecting information on such experience
7.3 Limits of the
It is useful to recognize the limits of this recommendation.
recommendation does not take a position on any of the
issues
1. What IGP (if any) users should run inside an AS. Users are free
run any IGP they wish inside an AS
2. What IGP is technically superior, or has greater
utility
3. What IGP any vendor should recommend to its users for any
environment
4. What IGP should be used within a CLNP-only environment
Again, this recommendation is meant to designate one modern
functionality IGP that should be implemented by all vendors
routers for the IP portion of the Internet. This will enable
from vendors who follow this recommendation to interoperate within
single IP Autonomous System
It is not our intent to discourage the use of other routing
in situations where there may be sound technical reasons to do so
Therefore, developers of Internet routers are free to implement,
network operators are free to use, other Internet standard
protocols, or proprietary non-Internet-standard routing protocols,
IESG [Page 7]
RFC 1371 Choosing a "Common IGP" October 1992
they wish
8.
[1] Internet Activities Board, "The Internet Standards Process",
1310, IAB, March 1992.
[2] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP
3)", RFC 1267, cisco Systems, T.J. Watson Research Center,
Corp., October 1991.
[3] Mills, D., "Exterior Gateway Protocol Formal Specification",
18, RFC 904, UDEL, April 1984.
[4] Moy, J., "OSPF Specification", RFC 1131 (Superceded by [7]),
Proteon, October 1989.
[5] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Environments", RFC 1195, DEC, December 1990.
[6] Hinden, R., "Criteria for Standardizing Internet
Protocols", RFC 1264, BBN, October 1991.
[7] Moy, J., "OSPF Version 2", RFC 1247, Proteon, July 1991.
[8] Baker, F., and R. Coltun, "OSPF Version 2 Management
Base", RFC 1253, ACC, Computer Science Center, August 1991.
[9] Moy, J., "Experience with the OSPF Protocol", RFC 1246, Proteon
July 1991.
[10] Moy, J., "OSPF Protocol Analysis", RFC 1245, Proteon, July 1991.
[11] Internet Architecture Board, "Applicability Statement for OSPF",
RFC 1370, IAB, October 1992.
IESG [Page 8]
RFC 1371 Choosing a "Common IGP" October 1992
9. Security
Security issues are not discussed in this memo
10. Author's
Phillip Gross, IESG
Advanced Network &
100 Clearbrook
Elmsford,
Phone: 914-789-5300
EMail: pgross@ans.
IESG [Page 9]
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
