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

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          R. Hinden Request for Comments: 1264                                           BBN                                                             October 1991 
  8.  
  9.                      Internet Engineering Task Force            Internet Routing Protocol Standardization Criteria 
  10.  
  11. Status of this Memo 
  12.  
  13.    This informational RFC presents procedures for creating and    documenting Internet standards on routing protocols.  These    procedures have been established by the Internet Activities Board    (IAB) in consultation with the Internet Engineering Steering Group    (IESG).  Distribution of this memo is unlimited. 
  14.  
  15. 1.0  Introduction 
  16.  
  17.    The IAB and the IESG have evolved a three-stage Internet    standardization process.  This process is explained in the "IAB    Official Protocol Standards", published as an RFC several times a    year (the current version is RFC 1250). 
  18.  
  19.    In brief, the three stages of Internet standardization are Proposed    (which requires a well written, openly reviewed specification), Draft    (which requires Proposed status, multiple implementations and some    operational experience), and full Internet Standard (which requires    Draft status and more extensive operational experience).  The IAB and    IESG are currently developing a more detailed explanation of the    process, which will be available as an RFC. 
  20.  
  21.    The purpose of this document is to provide more specific guidance for    the advancement of routing protocols.  All levels of the    standardization process are covered. 
  22.  
  23.    There are currently two types of routing protocol in the Internet.    These are Interior Gateway Protocols (IGP) sometimes called Intra-    Domain Routing Protocols and Exterior Gateway Protocols (EGP)    sometimes called Inter-Domain Routing Protocols.  This document uses    the terms IGP and EGP. 
  24.  
  25. 2.0 Motivation 
  26.  
  27.    The motivation for these requirements two-fold.  The first is to    reduce the risk that there will be serious technical problems with a    routing protocol after it reaches Draft Standard.  The second is to    insure that the new routing protocol will support the continued    growth of the Internet. 
  28.  
  29.  
  30.  
  31. Hinden                                                          [Page 1] 
  32.  RFC 1264               Routing Protocol Criteria            October 1991 
  33.  
  34.     Routing protocols are complex, widely distributed, real-time    algorithms.  They are difficult to implement and to test.  Even    though a protocol may work in one environment with one    implementation, that does not ensure that it will work in a different    environment with multiple vendors.  A routing protocol may work well    within a range of topologies and number of networks and routers, but    may fail when an unforeseen limit is reached.  The result is that    even with considerable operational experience, it is hard to    guarantee that the protocol is mature enough for widespread    deployment. 
  35.  
  36.    The Internet is currently growing at an exponential rate.  Routing    protocols and the management of internet addressing are key elements    in the successful operation the Internet.  It is important that new    routing protocols be designed to support this rapid growth. 
  37.  
  38. 3.0 General Requirements 
  39.  
  40.    1) Documents specifying the Protocol and its Usage.  This may be       one or more documents.  The specifications for the routing       protocol must be well written such that independent,       interoperable implementations can be developed solely based on       the specification.  For example, it should be possible to       develop an interoperable implementation without consulting the       original developers of the routing protocol. 
  41.  
  42.    2) A Management Information Base (MIB) must be written for the       protocol.  Routing protocols, like all other internet protocols,       need a MIB defined so they can be remotely managed. 
  43.  
  44.    3) A security architecture of the protocol must be defined.  The       security architecture must include mechanisms for authenticating       routing messages and may include other forms of protection. 
  45.  
  46.    4) Generally, a number of interoperable implementations must       exist.  At least two must be written independently. 
  47.  
  48.    5) There must be evidence that all features of the protocol have       been tested, running between at least two implementations.  This       must include that all of the security features have been       demonstrated to operate, and that the mechanisms defined in the       protocol actually provide the intended protection. 
  49.  
  50.    6) There must be operational experience with the routing       protocol.  The level of operational experience required is       dependent on which level of standardization is requested.  All       significant features of the protocol must be exercised.  In the       case of an Interior Gateway Protocol (IGP), both interior and 
  51.  
  52.  
  53.  
  54. Hinden                                                          [Page 2] 
  55.  RFC 1264               Routing Protocol Criteria            October 1991 
  56.  
  57.        exterior routes must be carried (unless another mechanism is       provided for the exterior routes).  In the case of a Exterior       Gateway Protocol (EGP), it must carry the full complement of       exterior routes. 
  58.  
  59.    7) Two reports must be submitted to the IESG via the Routing Area       Director.  The first report must document how requirements 1)       through 6) of this document have been satisfied.  It must       include: 
  60.  
  61.       - Implementation experience. 
  62.  
  63.       - Reference to the MIB for the protocol. 
  64.  
  65.       - Description of the authentication mechanisms in the protocol. 
  66.  
  67.       - List of implementations including origin of code. 
  68.  
  69.       - Test scenarios and test results showing that all features of the         protocols have been tested. 
  70.  
  71.       - Description of operational experience.  This must include         topology, environment, time and duration, implementations         involved, and overall results and conclusions gained from the         operational experience. 
  72.  
  73.    The second report must summarize the key features of the protocol and    analyze how the protocol will perform and scale in the Internet.  The    intent of this requirement is to understand the boundary conditions    of the routing protocol.  The new routing protocol must be compared    with the existing routing protocols (e.g., RIP, EGP, etc.) as    appropriate.  The report should answer several questions: 
  74.  
  75.       - What are the key features and algorithms of the protocol? 
  76.  
  77.       - How much link bandwidth, router memory and router CPU cycles         does the protocol consume under normal conditions? 
  78.  
  79.       - For these metrics, how does the usage scale as the routing         environment grows?  This should include topologies at least an         order of magnitude larger than the current environment. 
  80.  
  81.       - What are the limits of the protocol for these metrics? (I.e.,         when will the routing protocol break?) 
  82.  
  83.       - For what environments is the protocol well suited, and for what         is it not suitable? 
  84.  
  85.  
  86.  
  87.  Hinden                                                          [Page 3] 
  88.  RFC 1264               Routing Protocol Criteria            October 1991 
  89.  
  90.     The IESG will forward to the IAB its recommendation for advancement    of the new routing protocol based on its evaluation of protocol    specifications and these reports. 
  91.  
  92. 4.0 Requirements for Proposed Standard 
  93.  
  94.    1) Documents specifying the Protocol and its Usage.  The       specification for the routing protocol must be well written such       that independent, interoperable implementations can be developed       solely based on the specification.  For example, it should be       possible to develop an interoperable implementation without       consulting the original developers of the routing protocol. 
  95.  
  96.    2) A Management Information Base (MIB) must be written for the       protocol.  The MIB does not need to submitted for Proposed       Standard at the same time as the routing protocol, but must be       at least an Internet Draft. 
  97.  
  98.    3) The security architecture of the protocol must be set forth       explicitly.  The security architecture must include mechanisms for       authenticating routing messages and may include other forms of       protection. 
  99.  
  100.    4) One or more implementations must exist. 
  101.  
  102.    5) There must be evidence that the major features of the protocol       have been tested. 
  103.  
  104.    6) No operational experience is required for the routing protocol       at this stage in the standardization process. 
  105.  
  106.    7) A report must be submitted to the IESG via the Routing Area       Director.  The report must document the key features of the       protocol and describe how requirements 1) through 5) have been       satisfied.  It must include: 
  107.  
  108.       - What are the key features and algorithms of the protocol? 
  109.  
  110.       - For what environments is the protocol well suited, and for what         is it not suitable? 
  111.  
  112.       - Description of the authentication mechanisms in the protocol. 
  113.  
  114.       - Reference to the MIB for the protocol. 
  115.  
  116.       - Implementation experience. 
  117.  
  118.       - List of implementations including origin of code. 
  119.  
  120.  
  121.  
  122. Hinden                                                          [Page 4] 
  123.  RFC 1264               Routing Protocol Criteria            October 1991 
  124.  
  125.        - Test scenarios and test results showing that the major features         of the protocols have been tested. 
  126.  
  127.    The IESG will forward to the IAB its recommendation for advancement    of the new routing protocol to Proposed Standard based on its    evaluation of protocol specifications and this reports. 
  128.  
  129. 5.0 Requirements for Draft Standard 
  130.  
  131.    1) Revisions to the Protocol and Usage documents showing changes and       clarifications made based on experience gained in the time       between when the protocol was made a Proposed Standard and it       being submitted for Draft Standard.  The revised documents should       include a section summarizing the changes made. 
  132.  
  133.    2) The Management Information Base (MIB) must be at the Proposed       Standard level of standardization. 
  134.  
  135.    3) Two or more interoperable implementations must exist.  At least       two must be written independently. 
  136.  
  137.    4) There must be evidence that all features of the protocol have       been tested, running between at least two implementations.  This       must include that all of the security features have been       demonstrated to operate, and that the mechanisms defined in the       protocol actually provide the intended protection. 
  138.  
  139.    5) There must be significant operational experience.  This must       include running in a moderate number routers configured in a       moderately complex topology, and must be part of the operational       Internet.  All significant features of the protocol must be       exercised.  In the case of an Interior Gateway Protocol (IGP),       both interior and exterior routes must be carried (unless another       mechanism is provided for the exterior routes).  In the case of       a Exterior Gateway Protocol (EGP), it must carry the full       complement of exterior routes. 
  140.  
  141.    6) Two reports must be submitted to the IESG via the Routing Area       Director.  The first report must document how requirements 1)       through 5) of this document have been satisfied.  It must include: 
  142.  
  143.       - Reference to the MIB for the protocol. 
  144.  
  145.       - Description of the authentication mechanisms in the protocol. 
  146.  
  147.       - List of implementations including origin of code. 
  148.  
  149.       - Implementation experience. 
  150.  
  151.  
  152.  
  153. Hinden                                                          [Page 5] 
  154.  RFC 1264               Routing Protocol Criteria            October 1991 
  155.  
  156.        - Test scenarios and test results showing that all features of the         protocols have been tested. 
  157.  
  158.       - Description of operational experience.  This must include         topology, environment, time and duration, implementations         involved, and overall results and conclusions gained from the         operational experience. 
  159.  
  160.    The second report must summarize the key features of the protocol and    analyze how the protocol will perform and scale in the Internet.  The    intent of this requirement is to understand the boundary conditions    of the routing protocol.  The new routing protocol must be compared    with the existing routing protocols (e.g., RIP, EGP, etc.) as    appropriate.  The report should answer several questions: 
  161.  
  162.       - What are the key features and algorithms of the protocol? 
  163.  
  164.       - How much link bandwidth, router memory and router CPU cycles         does the protocol consume under normal conditions? 
  165.  
  166.       - For these metrics, how does the usage scale as the routing         environment grows?  This should include topologies at least an         order of magnitude larger than the current environment. 
  167.  
  168.       - What are the limits of the protocol for these metrics? (I.e.,         when will the routing protocol break?) 
  169.  
  170.       - For what environments is the protocol well suited, and for what         is it not suitable? 
  171.  
  172.    The IESG will forward to the IAB its recommendation for advancement    of the new routing protocol to Draft Standard based on its evaluation    of protocol specifications and these reports. 
  173.  
  174. 6.0 Requirements for Standard 
  175.  
  176.    1) Revisions to the Protocol and Usage documents showing changes and       clarifications made based on experience gained in the time between       when the protocol was made a Draft Standard and it being submitted       for Standard.  The changes should be to clarify the protocol       or provide guidance in its implementation.  No significant changes       can be made to the protocol at this stage.  The revised documents       should include a section summarizing the changes made. 
  177.  
  178.    2) The Management Information Base (MIB) must be submitted for       Standard at the same time as the routing protocol. 
  179.  
  180.    3) Three or more interoperable implementations must exist.  At least 
  181.  
  182.  
  183.  
  184. Hinden                                                          [Page 6] 
  185.  RFC 1264               Routing Protocol Criteria            October 1991 
  186.  
  187.        two must be written independently. 
  188.  
  189.    4) There must be evidence that all features of the protocol have been       tested, running between at least two independently written       implementations.  This must include that all of the security       features have been demonstrated to operate, and that the mechanisms       defined in the protocol actually provide the intended protection. 
  190.  
  191.    5) There must be significant operational experience.  This must       include running in a large number routers configured in a complex       topology, and must be part of the operational Internet.  The       operational experience must include multi-vendor operation.  All       significant features of the protocol must be exercised.  In the       case of an Interior Gateway Protocol (IGP), both interior and       exterior routes must be carried (unless another mechanism is       provided for the exterior routes).  In the case of a Exterior       Gateway Protocol (EGP), it must carry the full complement of       exterior routes. 
  192.  
  193.    6) Two reports must be submitted to the IESG via the Routing Area       Director.  The first report must document how requirements 1)       through 5) of this document have been satisfied.  It must include: 
  194.  
  195.       - Reference to the MIB for the protocol. 
  196.  
  197.       - Description of the authentication mechanisms in the protocol. 
  198.  
  199.       - List of implementations including origin of code. 
  200.  
  201.       - Implementation experience. 
  202.  
  203.       - Test scenarios and test results showing that all features of the         protocols have been tested. 
  204.  
  205.       - Description of operational experience.  This must include         topology, environment, time and duration, implementations         involved, and overall results and conclusions gained from the         operational experience. 
  206.  
  207.    The second report should be a revision to the report prepared when    the protocol was submitted for Draft Standard.  It must describe the    additional knowledge and understanding gained in the time between    when the protocol was made a Draft standard and when it was submitted    for Standard. 
  208.  
  209.    The IESG will forward to the IAB its recommendation for advancement    of the new routing protocol to Standard based on its evaluation of    protocol specifications and these reports. 
  210.  
  211.  
  212.  
  213. Hinden                                                          [Page 7] 
  214.  RFC 1264               Routing Protocol Criteria            October 1991 
  215.  
  216.  Security Considerations 
  217.  
  218.    Security issues are not discussed in this memo. 
  219.  
  220. Author's Address 
  221.  
  222.    Robert M. Hinden    Bolt Beranek and Newman, Inc.    50 Moulton Street    Cambridge, MA 02138 
  223.  
  224.    Phone: (617) 873-3757 
  225.  
  226.    EMail: hinden@bbn.com 
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264. Hinden                                                          [Page 8] 
  265.  
  266.