home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1371.txt < prev    next >
Text File  |  1996-05-07  |  19KB  |  299 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                  P. Gross, Editor Request for Comments: 1371                              IETF/IESG Chair                                                            October 1992 
  8.  
  9.                Choosing a "Common IGP" for the IP Internet                  (The IESG's Recommendation to the IAB) 
  10.  
  11. Status of this Memo 
  12.  
  13.    This memo provides information for the Internet community.  It does    not specify an Internet standard.  Distribution of this memo is    unlimited. 
  14.  
  15. Special Note 
  16.  
  17.    This document was originally prepared as an Internet Engineering    Steering Group (IESG) recommendation to the Internet Architecture    Board (IAB) in mid-summer 1991, reaching the current version by the    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 to    publish this along with the recent OSPF Applicability Statement [11]    to help establish context and motivation. 
  18.  
  19. Abstract 
  20.  
  21.    This memo presents motivation, rationale and other surrounding    background information leading to the IESG's recommendation to the    IAB for a single "common IGP" for the IP portions of the Internet. 
  22.  
  23.    In this memo, the term "common IGP" is defined, the need for a common    IGP is explained, the relation of this issue to other ongoing    Internet Engineering Task Force (IETF) routing protocol development    is provided, and the relation of this issue to the goal for multi-    protocol integration in the Internet is explored. 
  24.  
  25.    Finally, a specific IGP is recommended as the "common IGP" for IP    portions of the Internet -- the Open Shortest Path First (OSPF)    routing protocol. 
  26.  
  27.    The goal of this recommendation is for all vendors of Internet IP    routers to make OSPF available as one of the IGP's provided with    their routers. 
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  IESG                                                            [Page 1] 
  36.  RFC 1371                Choosing a "Common IGP"             October 1992 
  37.  
  38.  Table of Contents 
  39.  
  40.    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 
  41.  
  42. 1. Background 
  43.  
  44.    There is a pressing need for a high functionality non-proprietary    "common" Interior Gateway Protocol (IGP) for the TCP/IP protocol    family.  An IGP is the routing protocol used within a single    administrative domain (commonly referred to as an "Autonomous System"    (AS). 
  45.  
  46.    By "common", we simply mean a protocol that is ubiquitously available    from all router vendors (as in "in common").  Users and network    operators have expressed a strong need for routers from different    vendors to have the capablity to interoperate within an AS through    use of a common IGP. 
  47.  
  48.    Note:  Routing between AS's is handled by a different type of routing    protocol, called an "Exterior Gateway Protocol" ("an EGP", of which    the Border Gateway Protocol [2] and "The Exterior Gateway Protocol"    [3] are examples.)  The issues of routing between AS's using "an" EGP    is not considered in this memo. 
  49.  
  50.    There are two IGPs in the Internet standards track capable of routing    IP traffic -- Open Shortest Path First (OSPF) [4] and Integrated IS-    IS [5] (based on the OSI IS-IS). These two protocols are both modern    "link state" routing protocols, based on the Dijkstra algorithm.    There has been substantial interaction and cooperation among the    engineers involved in each effort, and the protocols share some    similar features. 
  51.  
  52.    However, there are a number of technical design differences.  Most    noteably, OSPF has been designed solely for support of the Internet    Protocol (IP), while Integrated IS-IS has been designed to support    both IP and the OSI Connectionless Network Layer Protocol (CLNP) 
  53.  
  54.  
  55.  
  56. IESG                                                            [Page 2] 
  57.  RFC 1371                Choosing a "Common IGP"             October 1992 
  58.  
  59.     simultaneously. 
  60.  
  61. 2. Multiple Internet Standard Routing Protocols Possible 
  62.  
  63.    The Internet architecture makes a distinction between "Interior    Gateway Protocols (IGPs)" and "Exterior Gateway Protocols (EGPs)".    IGPs are routing protocols used within an Autonomous System (AS), and    EGPs are routing protocols used between different AS's. 
  64.  
  65.    Therefore, the Internet architecture supports the use and    standardization of multiple IGP routing protocols.  For example, it    is perfectly reasonable for one standard routing protocol to be used    within one AS; while a second standard routing protocol is used    within a second AS; at the same time that a non-standard proprietary    routing protocol is used within a third AS. 
  66.  
  67.    The primary purpose for making standards is to allow    interoperability.  Setting a protocol standard in the Internet says,    in effect, "if you wish to use this protocol, you should do it as    specified in the standard so that you can interoperate with others    who also wish to use this protocol."  It is important to understand    that simply specifying a standard does not, by itself, designate a    requirement to use the standard.  It is merely meant to allow    interoperability among those who choose to follow the standard. 
  68.  
  69.    Therefore, it is reasonable for both OSPF and Integrated IS-IS to be    progressed through the Internet Standards process as appropriate    (based on the criteria specified in [6]).  In addition, it is    possible that other IGPs may be developed and standardized in the    future. 
  70.  
  71. 3. A Common IGP 
  72.  
  73.    Although the Internet architecture allows for multiple standard IGP    routing protocols, interoperability of router products from different    vendors within a single AS would be greatly facilitated if a single    "common" IGP were available from all router vendors.  Designating a    single common IGP would have the goal of enabling multi-vendor router    interoperation with a modern high functionality routing protocol. 
  74.  
  75.    However, designating a common IGP does not mandate the use of that    IGP, nor would it be meant to discourage the use of other IGPs in    situations where there may be sound technical reasons to do so. 
  76.  
  77. 4. Impact of Multi-protocol Topology and Integrated IP/CLNP Routing 
  78.  
  79.    There are topology considerations which will affect the designation    of a "common" Internet IGP. 
  80.  
  81.  
  82.  
  83. IESG                                                            [Page 3] 
  84.  RFC 1371                Choosing a "Common IGP"             October 1992 
  85.  
  86.     The Internet requires support for a wide variety of protocol suites.    If we consider only IP and OSI CLNP, then the Internet is expected to    contain: 
  87.  
  88.    1. Pure IP AS's (in which IP is used but OSI CLNP is not used); 
  89.  
  90.    2. Pure CLNP AS's (in which CLNP is used but IP is not used); 
  91.  
  92.    3. Dual IP/CLNP ASs, with a common topology (i.e., all links and       routers in the AS support IP and CLNP, and a single common       topology is used for both protocol suites); 
  93.  
  94.    4. Dual, overlapping IP/CLNP ASs with differing topologies (i.e.,       some links are dual, while some are IP-only and some are       CLNP-only, resulting in different topologies for IP routing and       CLNP routing). 
  95.  
  96.    For (1), (i.e., a pure IP environment) any IGP capable of routing IP    traffic could be used (e.g., OSPF or Integrated IS-IS). 
  97.  
  98.    For (2), (i.e., a pure CLNP environment) any IGP capable of routing    CLNP traffic could be used (e.g., OSI IS-IS or Integrated IS-IS). 
  99.  
  100.    For (3), (i.e., routing environments in which both IP and CLNP are    present in a common topology) there are two possibilities for managing    routing: 
  101.  
  102.    1. Separate routing protocols could be used for each supported       protocol suite.  For example, OSPF may be used for calculating       routes for IP traffic and OSI IS-IS may be used for calculating       routes for OSI traffic.  Or Integrated IS-IS could be used for       calculating routes for IP traffic and OSI IS-IS could be used       for calculating routes for CLNP traffic. 
  103.  
  104.       This approach of using separate routing protocols and management       for each supported protocol family has come to be known as "Ships       in the Night" because the two routing protocols share the       hardware/software resources of the router without ever actually       interacting on a protocol level. 
  105.  
  106.    2. "Integrated routing" could be used, in which a single routing       protocol is used for both IP and CLNP.  At this time, Integrated       IS-IS is the only choice for "integrated routing". 
  107.  
  108.    For (4), (i.e., routing environments in which both IP and CLNP are    present but in an overlapping different topology) separate routing    protocols are required for the IP and CLNP environments (i.e., "Ships    in the Night").  This is equivalent to two separates cases of (1) and 
  109.  
  110.  
  111.  
  112. IESG                                                            [Page 4] 
  113.  RFC 1371                Choosing a "Common IGP"             October 1992 
  114.  
  115.     (2), but it is pointed out here as a separate case for completeness. 
  116.  
  117. 5. Commitment to both IP and CLNP 
  118.  
  119.    The IAB/IETF are committed to a timely introduction of OSI into the    Internet.  In recognition of this commitment, the IETF has an entire    area devoted to OSI integration. 
  120.  
  121.    However, while this introduction is taking place, it is essential    that existing services based on IP be continued.  Furthermore, IESG    also feels that even after more widespread introduction of CLNP, IP    and CLNP will continue to coexist in the Internet for quite some    time.  This view is consistent with the IAB goal of a multi-protocol    Internet. 
  122.  
  123.    Therefore, the IESG has a strong commitment to the continued support    for IP throughout the Internet.  Maintenance of this IP support    requires selection of a common IGP suitable for support of IP, and    requires that this selection be based on operational experience. 
  124.  
  125. 6. Some History 
  126.  
  127.    In February 1990, the IESG recommended that the question of    designating a "common" IGP be postponed until more information was    available from each protocol.  More than a year has now passed since    the IESG's recommendation.  There have been significant advancements    in specification, implementation, and operational experience with    each protocol.  It is now reasonable to re-open the consideration of    designating a "common IGP". 
  128.  
  129.    At the March 1991 meeting of the IETF, the IETF Routing Area Director    presented a set of criteria for the advancement of routing protocols    through the Internet standards process [6].  More information    regarding the IAB Internet Standards process can be found in [1]. 
  130.  
  131.    Also, at the March 1991 meeting of the IETF, the OSPF Working Group    requested that OSPF be considered for advancement to Draft Internet    Standard.  The OSPF WG submitted four documents to the IETF to    support its request: 
  132.  
  133.    o a revised protocol specification to update [4]; 
  134.  
  135.    o an SNMP Management Information Base (MIB); 
  136.  
  137.    o two technical reports giving a technical analysis and operational      experience with OSPF.  These reports follow the format recommended      in [6]. 
  138.  
  139.  
  140.  
  141.  IESG                                                            [Page 5] 
  142.  RFC 1371                Choosing a "Common IGP"             October 1992 
  143.  
  144.     These four documents have now been published as [7, 8, 9, 10]    respectively. 
  145.  
  146.    In summary for OSPF: 
  147.  
  148.    o all features of OSPF have tested (although not all features have      been used in operation), 
  149.  
  150.    o OSPF has been shown to operate well in several operational      networks containing between 10 and 30 routers, 
  151.  
  152.    o interoperation among routers from multiple vendors has been      demonstrated at organized "bakeoffs". 
  153.  
  154.    In May 1991, the IAB approved the IETF/IESG recommendation to advance    OSPF to Draft Internet Standard. 
  155.  
  156.    Integrated IS-IS, as specified in [5], is currently a Proposed    Internet Standard.  In July 1991, the status of Integrated IS-IS is    as follows: 
  157.  
  158.    o There are several separate implementations of integrated      IS-IS under development, 
  159.  
  160.    o Integrated IS-IS has worked well in several multi-area operational      networks, one containing between 20 and 30 routers, 
  161.  
  162.    o These recent operational results have not yet been fully      documented.  Documentation, showing satisfaction of the criteria      given in [6] for advancing routing protocols, will be submitted      to the IESG when Integrated IS-IS is submitted for Draft Internet      Standard status. 
  163.  
  164. 7. IESG Recommendations 
  165.  
  166. 7.1 Regarding the Common IGP for the IP Internet 
  167.  
  168.    Based on the available operational experience and the pressing need    for a high functionality IGP for the IP protocol family, the IESG    recommends that OSPF be designated as the common IGP for the IP    portions of the Internet.  To help ensure that this IGP is available    to all users, the IESG recommends that the IETF Router Requirements    Working Group specify OSPF as "MUST IMPLEMENT" in the document    "Requirements for Internet IP Routers". 
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176. IESG                                                            [Page 6] 
  177.  RFC 1371                Choosing a "Common IGP"             October 1992 
  178.  
  179.  7.2 Regarding Integrated Routing 
  180.  
  181.    As mentioned above, the IESG is commited to multiprotocol    environments, and expects usage of OSI CLNP to increase in the    Internet over time. 
  182.  
  183.    However, at this time, the IESG is not prepared to take a position    regarding the preference of either "Ships in the Night" or Integrated    routing for such mixed routing environments.  At this time, the    "Ships in the Night" approach is most widely used in the Internet.    Integrated routing has the potential advantage of reducing resource    utilization.  However, additional operational experience is needed    before any potential advantages can be fully evaluated. 
  184.  
  185.    Therefore, the IESG wishes to encourage implementation of Integrated    IS-IS so that a reasonable position can be determined based on    operational experience.  All implementers of Integrated IS-IS are    encouraged to coordinate their activity with the IETF IS-IS Working    Group, which is actively collecting information on such experience. 
  186.  
  187. 7.3 Limits of the Recommendation 
  188.  
  189.    It is useful to recognize the limits of this recommendation.  This    recommendation does not take a position on any of the following    issues: 
  190.  
  191.    1. What IGP (if any) users should run inside an AS. Users are free to       run any IGP they wish inside an AS. 
  192.  
  193.    2. What IGP is technically superior, or has greater operational       utility. 
  194.  
  195.    3. What IGP any vendor should recommend to its users for any specific       environment. 
  196.  
  197.    4. What IGP should be used within a CLNP-only environment. 
  198.  
  199.    Again, this recommendation is meant to designate one modern high    functionality IGP that should be implemented by all vendors of    routers for the IP portion of the Internet.  This will enable routers    from vendors who follow this recommendation to interoperate within a    single IP Autonomous System. 
  200.  
  201.    It is not our intent to discourage the use of other routing protocols    in situations where there may be sound technical reasons to do so.    Therefore, developers of Internet routers are free to implement, and    network operators are free to use, other Internet standard routing    protocols, or proprietary non-Internet-standard routing protocols, as 
  202.  
  203.  
  204.  
  205. IESG                                                            [Page 7] 
  206.  RFC 1371                Choosing a "Common IGP"             October 1992 
  207.  
  208.     they wish. 
  209.  
  210. 8.  References 
  211.  
  212.    [1] Internet Activities Board, "The Internet Standards Process", RFC        1310, IAB, March 1992. 
  213.  
  214.    [2] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-        3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM        Corp., October 1991. 
  215.  
  216.    [3] Mills, D., "Exterior Gateway Protocol Formal Specification", STD        18, RFC 904, UDEL, April 1984. 
  217.  
  218.    [4] Moy, J., "OSPF Specification", RFC 1131 (Superceded by [7]),        Proteon, October 1989. 
  219.  
  220.    [5] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual        Environments", RFC 1195, DEC, December 1990. 
  221.  
  222.    [6] Hinden, R., "Criteria for Standardizing Internet Routing        Protocols", RFC 1264, BBN, October 1991. 
  223.  
  224.    [7] Moy, J., "OSPF Version 2", RFC 1247, Proteon, July 1991. 
  225.  
  226.    [8] Baker, F., and R. Coltun, "OSPF Version 2 Management Information        Base", RFC 1253, ACC, Computer Science Center, August 1991. 
  227.  
  228.    [9] Moy, J., "Experience with the OSPF Protocol", RFC 1246, Proteon,        July 1991. 
  229.  
  230.   [10] Moy, J., "OSPF Protocol Analysis", RFC 1245, Proteon, July 1991. 
  231.  
  232.   [11] Internet Architecture Board, "Applicability Statement for OSPF",        RFC 1370, IAB, October 1992. 
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  IESG                                                            [Page 8] 
  249.  RFC 1371                Choosing a "Common IGP"             October 1992 
  250.  
  251.  9. Security Considerations 
  252.  
  253.    Security issues are not discussed in this memo. 
  254.  
  255. 10. Author's Address 
  256.  
  257.    Phillip Gross, IESG Chair    Advanced Network & Services    100 Clearbrook Road    Elmsford, NY 
  258.  
  259.    Phone: 914-789-5300    EMail: pgross@ans.net 
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  IESG                                                            [Page 9] 
  298.  
  299.