home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1000s / rfc1092.txt < prev    next >
Text File  |  1989-02-26  |  12KB  |  283 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         J. Rekhter
  8. Request for Comments: 1092                  T. J. Watson Research Center
  9.                                                            February 1989
  10.  
  11.  
  12.         EGP and Policy Based Routing in the New NSFNET Backbone
  13.  
  14. Status of this Memo
  15.  
  16.    This memo discusses implementation decisions for routing issues in
  17.    the NSFNET, especially in the NSFNET Backbone.  Of special concern is
  18.    the restriction of routing information to advertize the best route as
  19.    established by a policy decision.  Distribution of this memo is
  20.    unlimited.
  21.  
  22. Introduction
  23.  
  24.    The NSFNET backbone routes packets between the Regionals Networks to
  25.    which it is connected, (i.e., the packets arriving at a backbone
  26.    entry node are routed to an exit node).  How they travel through the
  27.    network is determined by two components:
  28.  
  29.      the NSFNET backbone routing protocol/algorithm, and
  30.  
  31.      additional information about the externally connected networks.
  32.  
  33.    This paper is concerned with how reachability information between the
  34.    external networks and the NSFNET backbone is exchanged so that
  35.    packets can be routed to the correct destination by using a
  36.    reasonable path.
  37.  
  38. EGP as reachability protocol
  39.  
  40.    The EGP (Exterior Gateway Protocol) routing method will be used to
  41.    exchange reachability information between the NSFNET backbone and the
  42.    regional networks.
  43.  
  44.    There are several problems with using EGP as a reachability protocol
  45.    for routing in a meshed environment.  Some EGP components require
  46.    further definitions for the NSFNET backbone - regional network
  47.    interactions.  It should be noted that the use of EGP is only viewed
  48.    as an interim measure until better inter autonomous system protocols
  49.    are defined and widely deployed for gateways used by regional
  50.    networks.
  51.  
  52.    The following is a list of some EGP problems and issues:
  53.  
  54.       The EGP model assumes an engineered spanning tree topology,
  55.  
  56.  
  57.  
  58. Rekhter                                                         [Page 1]
  59.  
  60. RFC 1092            IP EGP and Policy Based Routing        February 1989
  61.  
  62.  
  63.       however, the NSFNET (due to the presence of backdoor routes) does
  64.       not fit into this model.  In the NSFNET the same network may be
  65.       advertized as reachable by more than one regional network.
  66.       Besides the fact that the overall NSFNET does not fit into a
  67.       spanning tree model there are serious concerns with the concept
  68.       of the "core" (central to the EGP) and its obvious deficiencies.
  69.  
  70.       While EGP is going to isolate intra-Regional routing from the
  71.       intra-NSFNET-Backbone routing, it does not address the issue of
  72.       false information which may be supplied by regional networks.
  73.       EGP by itself does not protect a particular network from unwanted
  74.       and unsolicited representation by some regional network.  As an
  75.       example, if network N1 is reachable through regional network R1
  76.       as well as through regional network R2, EGP has no provisions to
  77.       specify one of these paths as a primary and one as a secondary,
  78.       since there is not generally accepted interpretation of EGP
  79.       metrics today.  Also, there is nothing in EGP which can prevent one
  80.       or more regional networks from advertizing other networks (in
  81.       particular, networks which belong to other regional networks) as
  82.       reachable with zero distance.  This could result in the creation
  83.       of a "black hole" or at least in suboptimal IP routing.
  84.  
  85.       EGP by itself has no provisions to guarantee that routes through
  86.       the NSFNET Backbone will be preferred over routes through the
  87.       backdoor routers or vice versa.
  88.  
  89. Policy Based Routing
  90.  
  91.    Looking at the problems listed above the appearance of the new
  92.    factors like autonomy and mutual trust becomes obvious.  While trying
  93.    to achieve the routing functionality required for the new NSFNET
  94.    backbone we should realize that one of our primary concerns has to be
  95.    the accommodation of those new factors.
  96.  
  97.    This means that some kind of a rudimentary Policy Based Routing
  98.    method becomes imperative.  We would like to emphasize, however, that
  99.    we are not talking about complete Policy Based Routing, but that we
  100.    are rather concerned about supporting a minimum subset of a policy
  101.    functionality to be an initial solution to the above mentioned
  102.    problems.  This requires support and cooperation between the
  103.    management of each of the networks connected to the NSFNET backbone.
  104.  
  105.    We need to support the ability of a particular network N, which
  106.    belongs to one of the regional networks, to establish a bilateral
  107.    agreement with one or more regional networks of the type "network N
  108.    can be reached via one or more regional networks (RN1, RN2, ...
  109.    RNx)".  This allows each network to select one or more
  110.    representatives at the regional network level.  Once this agreement
  111.  
  112.  
  113.  
  114. Rekhter                                                         [Page 2]
  115.  
  116. RFC 1092            IP EGP and Policy Based Routing        February 1989
  117.  
  118.  
  119.    is established the information will be available to:
  120.  
  121.      The network which initiated the agreement.
  122.  
  123.      The management of the regional network(s) with whom this
  124.      agreement has been established.
  125.  
  126.      The NSFNET backbone Network Operation Center where it will be
  127.      entered into the Routing Policy Data Base which will be available
  128.      through the NSFNET information services.
  129.  
  130.    Supporting multiple routes to the NSFNET core requires the guarantee
  131.    that for a certain network N, no regional network other than the
  132.    one(s) selected by N, will advertize N as reachable, which
  133.    necessitates that the NSFNET core will ignore unauthorized
  134.    advertisements for network N.
  135.  
  136. EGP and Rudimentary Policy Based Routing
  137.  
  138.    Each network which belongs to the NSFNET will select a specific
  139.    regional network as its primary representative to the NSFNET core by
  140.    bilateral agreement with the management of same regional network as
  141.    well as the NSFNET backbone management.  The same network can
  142.    furthermore select an arbitrary number of other regional networks as
  143.    their secondary, tertiary, etc., representative by establishing
  144.    bilateral agreements with the management of the corresponding
  145.    regional networks as well as the NSFNET backbone management.
  146.  
  147.    Reachability information supplied by each regional network will be
  148.    distributed to all other NSS nodes of the NSFNET Backbone.  We would
  149.    like to emphasize that we are not going to flood EGP packets
  150.    internally within the backbone, but to rather use the learned
  151.    information for the interior gateway protocol, which uses the ANSI
  152.    IS-IS protocol.
  153.  
  154.    The implementation allows for a defined regional network to advertize
  155.    a particular leaf network in the EGP NR packets with a distance of
  156.    zero.  Secondary representatives may advertize the same network with
  157.    distance one or higher.  If the path through the primary regional
  158.    representative is available all secondary paths will be ignored.  If
  159.    the path through the primary regional representative goes down (which
  160.    will be discovered via the EGP NR information), the next path with
  161.    the lowest available EGP metric will be used.
  162.  
  163.    We will also be able to detect and report unsolicited
  164.    representations.  This will be done by examining (on a periodic
  165.    basis) all reachability information obtained via EGP.  The result
  166.    will be compared against the Routing Policy Data Base which will hold
  167.  
  168.  
  169.  
  170. Rekhter                                                         [Page 3]
  171.  
  172. RFC 1092            IP EGP and Policy Based Routing        February 1989
  173.  
  174.  
  175.    information about all bilateral agreements between networks and their
  176.    regional representatives.  Any mismatch will cause an alarm to the
  177.    Network Operations Center.  For example, network N established a
  178.    bilateral agreement with the regional network R1 electing it as its
  179.    primary representative. The EGP NR record received from the regional
  180.    network R5 advertizes the network N as reachable with distance zero.
  181.    By comparing the Routing Policy Data Base entry for the network N
  182.    with the EGP NR record a mismatch will be detected and an alarm is
  183.    forwarded to the Network Operation Center.
  184.  
  185.    Since the whole scheme is based on a combination of the network
  186.    number and the autonomous system number, to allow for further
  187.    verification, it is also important to insure the correctness of the
  188.    autonomous system numbers as advertized by the regionals networks to
  189.    the NSFNET core.
  190.  
  191.    The autonomous system number validation for each regional network
  192.    will be performed at the NSS which connects the particular leaf
  193.    network to the NSFNET backbone.  All discrepancies wil be reported to
  194.    the Network Operations Center.
  195.  
  196.    The NSFNET backbone will be considered as a separate Autonomous
  197.    System with its own autonomous system number.
  198.  
  199. Backbone versus Backdoor Routes
  200.  
  201.    There are instances where regional networks prefer paths through some
  202.    backdoor route over paths through the NSFNET backbone.  Therefore,
  203.    the reachability information advertized by the NSFNET core to the
  204.    regional networks (via EGP NR records) will always use a fixed metric
  205.    of 128 for all routes.  This may aid to encourage traffic to flow
  206.    through backdoors, if desired and available.
  207.  
  208.    The regional networks can use a variety of techniques to determine
  209.    how they route traffic for any particular network at their own
  210.    option.
  211.  
  212. What do we expect from the Regional Networks
  213.  
  214.    Each regional network should get its own Autonomous System number.
  215.  
  216.    The connection between regional networks to NSFNET backbone will be
  217.    done via EGP.  It is the responsibility of the regional backbone to
  218.    provide an EGP functionality via the attachment to the E-PSP
  219.    dedicated to the regional network.
  220.  
  221.    The EGP functionality may require a translation of network numbers in
  222.    and out of the regional network.  In any case, the NSFNET backbone
  223.  
  224.  
  225.  
  226. Rekhter                                                         [Page 4]
  227.  
  228. RFC 1092            IP EGP and Policy Based Routing        February 1989
  229.  
  230.  
  231.    expects individual network numbers of the leaf networks of the
  232.    regional network, as long as they should be advertised, and will
  233.    announce individual networks known to the NSFNET core to the regional
  234.    network.
  235.  
  236.    The EGP support should includes the ability to configure EGP metrics
  237.    from some statically definable configuration table.  If the EGP
  238.    metrics cannot be defined or if they are not fixed the metric
  239.    determination will be done by the NSFNET backbone routers, as taken
  240.    from their databases, themselves.  In that case, it is the
  241.    responsibility of the regional network to provide the NSFNET backbone
  242.    management with the metric data to allow for proper use of metrics.
  243.  
  244.    We also expect each regional network to handle all bilateral
  245.    agreements with its leaf networks regarding Policy Based Routing and
  246.    supply a copy of those agreements to the NSFNET backbone management.
  247.  
  248. Acknowledgements
  249.  
  250.    I would like to express my thanks to Barry Appelman (T.J. Watson
  251.    Research Center, IBM Corp.) and Hans-Werner Braun (Merit) for their
  252.    contributions to this document.
  253.  
  254. Author's Address
  255.  
  256.    Jacob Rekhter
  257.    T.J. Watson Research Center
  258.    IBM Corporation
  259.    P.O. Box 218
  260.    Yorktown Heights, NY 10598
  261.  
  262.    Phone: (914) 945-3896
  263.  
  264.    Email: YAKOV@IBM.COM
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Rekhter                                                         [Page 5]
  283.