home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1520 < prev    next >
Text File  |  1993-09-24  |  20KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         Y. Rekhter
  8. Request for Comments: 1520        T.J. Watson Research Center, IBM Corp.
  9. Category: Informational                                      C. Topolcic
  10.                                                                     CNRI
  11.                                                           September 1993
  12.  
  13.  
  14.        Exchanging Routing Information Across Provider Boundaries
  15.                         in the CIDR Environment
  16.  
  17. Status of this Memo
  18.  
  19.    This memo provides information for the Internet community.  It does
  20.    not specify an Internet standard.  Distribution of this memo is
  21.    unlimited.
  22.  
  23. 1.  Introduction
  24.  
  25.    Classless Inter-Domain Routing (CIDR) has been adopted as a solution
  26.    to the scaling problem in the Internet. The overall CIDR architecture
  27.    is described in [1]. The architecture for IP address assignment with
  28.    CIDR is covered in [2] and [3]. The inter-domain routing protocols
  29.    that are capable of supporting CIDR are covered in [4], [5], and [6].
  30.  
  31.    The purpose of this document is twofold. First, it describes various
  32.    alternatives for exchanging inter-domain routing information across
  33.    domain boundaries, where one of the peering domain is CIDR-capable
  34.    and another is not.  Second, it addresses the implications of running
  35.    CIDR-capable inter-domain routing protocols (e.g., BGP-4, IDRP) on
  36.    intra-domain routing.
  37.  
  38.    This document is not intended to cover all the cases (either real or
  39.    imaginable). Rather, it focuses on what are viewed to be the most
  40.    common cases.  We expect that individual service providers will use
  41.    this document as guidelines in establishing their specific
  42.    operational plans for the transition to CIDR.
  43.  
  44.    The concepts of "network service provider" and "network service
  45.    subscriber" were introduced in [3]. For the sake of brevity, we will
  46.    use the term "provider"  or "service provider" here to mean either
  47.    "network service provider" or "network service subscriber", since for
  48.    the most part, the distinction is not important to this discussion.
  49.    Furthermore, we use the same terms to refer to the network and to the
  50.    organization that operates the network. We feel that the context
  51.    makes it amply clear whether we are talking about hardware or people,
  52.    and defining different terms would only make this paper harder to
  53.    read.
  54.  
  55.  
  56.  
  57.  
  58. Rekhter & Topolcic                                              [Page 1]
  59.  
  60. RFC 1520           CIDR Provider Information Exchange     September 1993
  61.  
  62.  
  63.    This document defines a CIDR-capable provider as the provider that
  64.    can perform correct IP packet forwarding (both internally and to
  65.    other adjacent providers) when the inter-domain routing information
  66.    acquired by the provider is expressed solely in terms of IP address
  67.    prefixes (with no distinction between A/B/C class of addresses).
  68.  
  69.    This document defines CIDR-capable forwarding as the ability of a
  70.    router to maintain its forwarding table and to perform correct
  71.    forwarding of IP packets without making any assumptions about the
  72.    class of IP addresses.
  73.  
  74.    This document defines CIDR reachability information as reachability
  75.    information that may violate any assumptions about the class of IP
  76.    addresses. For instance, a contiguous block of class C networks
  77.    expressed as a single IP address prefix constitutes CIDR reachability
  78.    information.
  79.  
  80. 2.  Taxonomy of Service Providers
  81.  
  82.    For the purpose of this document we partition all service providers
  83.    into the following categories, based on the type and volume of
  84.    inter-domain routing information a provider needs to acquire in order
  85.    to meet its service requirements:
  86.  
  87.       - Requirements imposed on a service provider preclude it from
  88.         using Default inter-domain route(s) -- we'll refer to such a
  89.         pqrovider as a Type 1 provider.
  90.  
  91.       - Requirements imposed on a service provider allow it to rely on
  92.         using one or more Default routes for inter-domain routing, but
  93.         this information must be supplemented by requiring the provider
  94.         to acquire a large percentage of total Internet routing
  95.         information -- we'll refer to such a provider as a Type 2
  96.         provider.
  97.  
  98.       - Requirements imposed on a service provider allow it to rely on
  99.         using one or more Default routes for inter-domain routing;
  100.         however, to meet its service requirements the provider must
  101.         supplement Default route(s) by acquiring a small percentage of
  102.         total Internet routing information -- we'll refer to such a
  103.         provider as a Type 3 provider.
  104.  
  105.       - Requirements imposed on a service provider allow it to rely
  106.         solely on using one or more Default routes for inter-domain
  107.         routing; no other inter-domain routing information need to be
  108.         acquired -- we'll refer to such a provider as a Type 4 provider.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Rekhter & Topolcic                                              [Page 2]
  115.  
  116. RFC 1520           CIDR Provider Information Exchange     September 1993
  117.  
  118.  
  119. 3.  Assumptions on Deployment of CIDR in the Internet
  120.  
  121.    The document assumes that the CIDR deployment in the Internet will
  122.    proceed as a three phase process.
  123.  
  124.    In the first phase all the major service providers will become CIDR-
  125.    capable. Specifically, all the providers that can't rely on using
  126.    Default route(s) for inter-domain routing (Type 1 providers) are
  127.    expected to deploy BGP-4 and transition to CIDR during this phase. It
  128.    is expected that CIDR reachability information will first appear in
  129.    the Internet upon transition of all Type 1 service providers to CIDR.
  130.  
  131.    The second phase will commence upon completion of the first phase.
  132.    During the second phase other service providers that are connected to
  133.    the service providers that were transitioned to CIDR during the first
  134.    phase will become CIDR-capable.  Specifically, during the second
  135.    phase it is expected that most of the providers that need to acquire
  136.    a large percentage of the total Internet routing information (Type 2
  137.    provider) will become CIDR-capable.  In addition, during the second
  138.    phase some of the Type 3 providers may become CIDR-capable as well.
  139.    This plan was agreed to by a number of major providers [8]. NSFNET's
  140.    steps to implement this plan are described in [9].
  141.  
  142.    Finally, during the third phase the rest of the Type 3 providers and
  143.    most of the Type 4 providers will transition to CIDR.
  144.  
  145.    It is expected that the duration of the first phase will be
  146.    significantly shorter than duration of the second phase.  Likewise,
  147.    the duration of the second phase is expected to be shorter than the
  148.    duration of the third phase.
  149.  
  150.    This document addresses the need for service providers to exchange
  151.    inter-domain routing information during the second and third phases
  152.    of this deployment. During these phases, some providers will be
  153.    CIDR-capable, and others will not. Hence this document considers
  154.    routing exchanges where one of the peers is CIDR-capable and the
  155.    other is CIDR-incapable.
  156.  
  157. 4.  Implications of CIDR on Interior Routing
  158.  
  159.    A CIDR-capable service provider can use the following two techniques
  160.    to distribute exterior routing information to all of its routers
  161.    (both interior and border):
  162.  
  163.       - utilize internal BGP/IDRP between all the routers
  164.  
  165.       - use CIDR-capable IGPs (e.g., OSPF, IS-IS, RIP2)
  166.  
  167.  
  168.  
  169.  
  170. Rekhter & Topolcic                                              [Page 3]
  171.  
  172. RFC 1520           CIDR Provider Information Exchange     September 1993
  173.  
  174.  
  175.    The first technique doesn't impose any addition requirements on the
  176.    IGP within the provider. Additional information on implementing the
  177.    first option is presented in [5] (see Section A.2.4).
  178.  
  179.    The second technique allows the provider to reduce the utilization of
  180.    internal BGP/IDRP, but imposes specific requirements on the intra-
  181.    domain routing. It also requires the ability to inject inter-domain
  182.    routing information (acquired either via BGP or IDRP) into the
  183.    intra-domain routing. Additional details on implementing the second
  184.    option are provided in [7]. It is not expected that all the features
  185.    enumerated in [7] will be widely needed. Therefore, it would be
  186.    highly desirable to prioritize the features.
  187.  
  188.    Note that both of these techniques imply that all the routers within
  189.    a CIDR-capable service provider need to be capable of CIDR-based
  190.    forwarding.
  191.  
  192.    Discussion of which of the two techniques should be preferred is
  193.    outside the scope of this document.
  194.  
  195. 5.  Exchanging Inter-Domain Routing Information
  196.  
  197.    At each phase during the transition to CIDR one of the essential
  198.    aspects of the Internet operations will be the exchange of inter-
  199.    domain routing information between CIDR-capable providers and CIDR-
  200.    incapable provider.
  201.  
  202.    When exchanging inter-domain routing information between a CIDR-
  203.    capable provider and a CIDR-incapable provider, it is of utmost
  204.    importance to take into account the view each side wants the other to
  205.    present. This view has two distinct aspects:
  206.  
  207.       - the type of routing information exchanged (i.e., Default route,
  208.         traditional (non-CIDR) reachability information, CIDR
  209.         reachability information)
  210.  
  211.       - routing information processing each side needs to do to maintain
  212.         these views (e.g., ability to perform aggregation, ability to
  213.         perform controlled de-aggregation)
  214.  
  215.    The exchange of inter-domain routing information is expected to be
  216.    controlled by bilateral agreements between the directly connected
  217.    service providers. Consequently, the views each side wants of the
  218.    other are expected to form an essential component of such agreements.
  219.  
  220.    To facilitate troubleshooting and problem isolation, the bilateral
  221.    agreements should be made accessible to other providers.  One way to
  222.    accomplish this is by placing them in a generally accessible
  223.  
  224.  
  225.  
  226. Rekhter & Topolcic                                              [Page 4]
  227.  
  228. RFC 1520           CIDR Provider Information Exchange     September 1993
  229.  
  230.  
  231.    database. The details of how this can be implemented are outside the
  232.    scope of this document. A possible way to accomplish this is
  233.    described in [9].
  234.  
  235.    Since the exchange of inter-domain routing information across
  236.    provider boundaries occurs on a per peer basis, a border router is
  237.    expected to provide necessary mechanisms (e.g., configuration) that
  238.    will control exchange and processing of this information on a per
  239.    peer basis.
  240.  
  241.    In the following sections we describe possible scenarios for
  242.    exchanging inter-domain routing information. It is always assumed
  243.    that one side is CIDR-capable and the other is not.
  244.  
  245. 5.1  Exchanging Inter-Domain Routing Information between CIDR-capable
  246.      providers and CIDR-incapable Type 2 (default with large proportion
  247.      of explicit routes) providers
  248.  
  249.    We expect the border router(s) within a CIDR-capable provider to be
  250.    capable of aggregating inter-domain routing information they receive
  251.    from a CIDR-incapable Type 2 provider.  The aggregation is expected
  252.    to be governed and controlled via a bilateral agreement.
  253.    Specifically, the CIDR capable provider is expected to aggregate only
  254.    the information the other side (the CIDR-incapable provider)
  255.    requests. In other words, the aggregation shall be done by the CIDR-
  256.    capable provider (the receiver) and only when agreed to by the CIDR-
  257.    incapable provider (the sender).
  258.  
  259.    Passing inter-domain routing information from a CIDR-capable provider
  260.    to a CIDR-incapable Type 2 provider will require an agreement between
  261.    the two that would cover the following items:
  262.  
  263.       - under what conditions the CIDR-capable provider can pass an
  264.         inter-domain Default route to the CIDR-incapable provider
  265.  
  266.       - exchange of specific non-CIDR reachability information
  267.  
  268.       - controlled de-aggregation of CIDR reachability information
  269.  
  270.    Agreements that cover the first two items are already implemented
  271.    within the Internet. Thus, the only additional factor introduced by
  272.    CIDR is controlled de-aggregation. A CIDR-capable provider may decide
  273.    not to de-aggregate any CIDR reachability information, or to de-
  274.    aggregate some or all of the CIDR reachability information.
  275.  
  276.    If a CIDR-capable provider does not de-aggregate CIDR reachability
  277.    information, then its non-CIDR Type 2 peer can obtain reachability
  278.    information from it either as non-CIDR reachability information
  279.  
  280.  
  281.  
  282. Rekhter & Topolcic                                              [Page 5]
  283.  
  284. RFC 1520           CIDR Provider Information Exchange     September 1993
  285.  
  286.  
  287.    (explicit Class A/B/C network advertisement) or as an inter-domain
  288.    Default route.  Since most of the current reachability information in
  289.    the Internet is non-CIDR, a Type 2 provider would be able to acquire
  290.    this information as explicit Class A/B/C network advertisements from
  291.    the CIDR-capable provider, as it does now.  Further, it is expected
  292.    that at least on a temporary basis (until the completion of the
  293.    second phase of the transition) in a majority of cases, Type 2
  294.    providers should be able to use an inter-domain Default route
  295.    (acquired from the CIDR-capable provider) as a way of dealing with
  296.    forwarding to destinations covered by CIDR reachability information.
  297.  
  298.    Thus, it is expected that most of the cases involving a CIDR-capable
  299.    Type 2 provider and a CIDR-capable provider that does not perform
  300.    de-aggregation could be addressed by a combination of exchanging
  301.    specific non-CIDR reachability information and an inter-domain
  302.    Default route. Any inconvenience to a CIDR-incapable provider due to
  303.    the use of an inter-domain Default route will be removed once the
  304.    provider transitions to CIDR.
  305.  
  306.    On the other hand, a CIDR-capable provider may decide to perform
  307.    controlled de-aggregation of CIDR reachability information.
  308.    Additional information on performing controlled de-aggregation can be
  309.    found in [5] (Section 8).  Special care must be taken when de-
  310.    aggregating CIDR reachability information carried by a route with the
  311.    ATOMIC_AGGREGATE path attribute.  It is worth while pointing out that
  312.    due to the nature of Type 2 provider (it needs to acquire a large
  313.    percentage of total inter-domain routing information) it is expected
  314.    that the controlled de-aggregation would result in substantial
  315.    configuration at the border router that performs the de-aggregation.
  316.  
  317. 5.2  Exchanging Inter-Domain Routing Information between CIDR-capable
  318.      providers and CIDR-incapable Type 3 (Default with few explicit
  319.      routes) providers
  320.  
  321.    In this case, as in the case described in Section 5.1, it is expected
  322.    that a border router in a CIDR-capable provider would be able to
  323.    aggregate routing information it receives from a CIDR-incapable Type
  324.    3 provider. The aggregation is expected to be governed and controlled
  325.    via a bilateral agreement.  Specifically, the CIDR capable provider
  326.    is expected to aggregate only the information the CIDR-incapable
  327.    provider requests.
  328.  
  329.    The only difference between this case and the case described in
  330.    Section 5.1 is the fact that a CIDR-incapable provider requires just
  331.    a small percentage of total inter-domain routing information. If this
  332.    information falls into a non-CIDR category, then a Type 3 provider
  333.    would be able to acquire it from a CIDR-capable provider. If this is
  334.    CIDR reachability information, then in a majority of cases it is
  335.  
  336.  
  337.  
  338. Rekhter & Topolcic                                              [Page 6]
  339.  
  340. RFC 1520           CIDR Provider Information Exchange     September 1993
  341.  
  342.  
  343.    expected that forwarding to destinations covered by this information
  344.    could be handled via an inter-domain Default route.
  345.  
  346.    It is still expected that a border router in a CIDR-capable provider
  347.    would be able to aggregate routing information it receives from a
  348.    CIDR-incapable Type 3 provider. The aggregation is expected to be
  349.    governed and controlled via a bilateral agreement.  Specifically, the
  350.    CIDR capable provider is expected to aggregate only the information
  351.    the other side (the CIDR-incapable provider) requests.
  352.  
  353. 5.3  Exchanging Inter-Domain Routing Information between CIDR-capable
  354.      providers and CIDR-incapable Type 4 (Default only) providers
  355.  
  356.    Again, it is still expected that a border router in a CIDR-capable
  357.    provider would be able to aggregate routing information it receives
  358.    from a CIDR-incapable Type 4 provider. The aggregation is expected to
  359.    be governed and controlled via a bilateral agreement.  Specifically,
  360.    the CIDR capable provider is expected to aggregate only the
  361.    information the CIDR-incapable provider requests.
  362.  
  363.    The only difference between this case and the case described in
  364.    Section 5.1 is the fact that CIDR-incapable provider would not
  365.    require any inter-domain routing information, other than the Default
  366.    inter-domain route. Therefore, controlled de-aggregation of CIDR
  367.    reachability information is not an issue.
  368.  
  369. 6. Conclusions
  370.  
  371.    It is expected that the reduction in the global volume of routing
  372.    information will begin immediately upon completion of the first phase
  373.    of the transition to CIDR. The second phase will allow simpler
  374.    bilateral arrangements between connected service providers by
  375.    shifting the responsibility for routing information aggregation
  376.    towards the parties that are better suitable for it, and by
  377.    significantly reducing the need for routing information de-
  378.    aggregation. Thus, most of the gain achieved during the second phase
  379.    will come from simplifying bilateral agreements. The third phase it
  380.    intended to complete the goals and objectives of the second phase.
  381.  
  382. 7.  Acknowledgments
  383.  
  384.    This document was largely stimulated by the discussion that took
  385.    place during the Merit/NSFNET Regional Tech Meeting in Boulder,
  386.    January 21-22, 1993.  We would like specifically acknowledge
  387.    contributions by Peter Ford (Los Alamos National Laboratory), Elise
  388.    Gerich (NSFNET/Merit), Susan Hares (NSFNET/Merit), Mark Knopper
  389.    (NSFNET/Merit), Bill Manning (Sesquinet/Rice University), and John
  390.    Scudder (NSFNET/Merit).
  391.  
  392.  
  393.  
  394. Rekhter & Topolcic                                              [Page 7]
  395.  
  396. RFC 1520           CIDR Provider Information Exchange     September 1993
  397.  
  398.  
  399. 8.  References
  400.  
  401.    [1] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
  402.        Domain Routing (CIDR): An Address Assignment and Aggregation
  403.        Strategy", RFC 1519, BARRNet, cisco, Merit, and OARnet, September
  404.        1993.
  405.  
  406.    [2] Gerich, E., "Guidelines for Management of IP Address Space", RFC
  407.        1466, Merit, May 1993.
  408.  
  409.    [3] Rekhter, Y., and T. Li, "An Architecture for IP Address
  410.        Allocation with CIDR", RFC 1518, T.J. Watson Research Center, IBM
  411.        Corp., cisco Systems, September 1993.
  412.  
  413.    [4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
  414.        Work in Progress, June 1993.
  415.  
  416.    [5] Rekhter, Y., and P. Gross, "Application of the Border Gateway
  417.        Protocol in the Internet", Work in Progress, September 1992.
  418.  
  419.    [6] Hares, S., "IDRP for IP", Work in Progress, March 1993.
  420.  
  421.    [7] Varadhan, K., "BGP4 OSPF Interaction", Work in Progress, March
  422.        1993.
  423.  
  424.    [8] Topolcic, C., "Notes on BGP-4/CIDR Coordination Meeting of 11
  425.        March 93", Informal Notes, March 1993.
  426.  
  427.    [9] Knopper, M., "Aggregation Support in the NSFNET Policy Routing
  428.        Database", RFC 1482, Merit, June 1993.
  429.  
  430. 9.  Security Considerations
  431.  
  432.        Security issues are not discussed in this memo.
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Rekhter & Topolcic                                              [Page 8]
  451.  
  452. RFC 1520           CIDR Provider Information Exchange     September 1993
  453.  
  454.  
  455. 10.  Authors' Addresses
  456.  
  457.        Yakov Rekhter
  458.        T.J. Watson Research Center, IBM Corporation
  459.        P.O. Box 218
  460.        Yorktown Heights, NY 10598
  461.  
  462.        Phone: (914) 945-3896
  463.        EMail: yakov@watson.ibm.com
  464.  
  465.  
  466.        Claudio Topolcic
  467.        Corporation for National Research Initiatives
  468.        1895 Preston White Drive, Suite 100
  469.        Suite 100
  470.        Reston, VA 22091
  471.  
  472.        Phone: (703) 620-8990
  473.        EMail: topolcic@CNRI.Reston.VA.US
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Rekhter & Topolcic                                              [Page 9]
  507.  
  508.