home *** CD-ROM | disk | FTP | other *** search
/ A Beginner's Guide to the Internet / INTERNET.ISO / text / rfc / rfc1586.txt < prev    next >
Encoding:
Text File  |  1996-03-03  |  14.9 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         O. deSouza
  8. Request for Comments: 1586                                  M. Rodrigues
  9. Category: Informational                           AT&T Bell Laboratories
  10.                                                               March 1994
  11.  
  12.  
  13.                       Guidelines for Running OSPF
  14.                        Over Frame Relay Networks
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This memo specifies guidelines for implementors and users of the Open
  25.    Shortest Path First (OSPF) routing protocol to bring about
  26.    improvements in how the protocol runs over frame relay networks.  We
  27.    show how to configure frame relay interfaces in a way that obviates
  28.    the "full-mesh" connectivity required by current OSPF
  29.    implementations. This allows for simpler, more economic network
  30.    designs.  These guidelines do not require any protocol changes; they
  31.    only provide recommendations for how OSPF should be implemented and
  32.    configured to use frame relay networks efficiently.
  33.  
  34. Acknowledgements
  35.  
  36.    This memo is the result of work done in the OSPF Working Group of the
  37.    IETF.  Comments and contributions from several sources, especially
  38.    Fred Baker of ACC, John Moy of Proteon, and Bala Rajagopalan of AT&T
  39.    Bell Laboratories are included in this work.
  40.  
  41. 1.  Introduction
  42.  
  43.    A frame relay (FR) network provides virtual circuits (VCs) to
  44.    interconnect attached devices. Each VC is uniquely identified at each
  45.    FR interface by a Data Link Connection Identifier (DLCI).  RFC 1294
  46.    specifies the encapsulation of multiprotocol traffic over FR [1].
  47.    The devices on a FR network may either be fully interconnected with a
  48.    "mesh" of VCs, or partially interconnected.  OSPF characterizes FR
  49.    networks as non-broadcast multiple access (NBMA) because they can
  50.    support more than two attached routers, but do not have a broadcast
  51.    capability [2].  Under the NBMA model, the physical FR interface on a
  52.    router corresponds to a single OSPF interface through which the
  53.    router is connected to one or more neighbors on the FR network; all
  54.    the neighboring routers must also be directly connected to each other
  55.  
  56.  
  57.  
  58. deSouza & Rodrigues                                             [Page 1]
  59.  
  60. RFC 1586                 OSPF over Frame Relay                March 1994
  61.  
  62.  
  63.    over the FR network.  Hence OSPF implementations that use the NBMA
  64.    model for FR do not work when the routers are partially
  65.    interconnected.  Further, the topological representation of a
  66.    multiple access network has each attached router bi-directionally
  67.    connected to the network vertex with a single link metric assigned to
  68.    the edge directed into the vertex.
  69.  
  70.    We see that the NBMA model becomes more restrictive as the number of
  71.    routers connected to the network increases. First, the number of VCs
  72.    required for full-mesh connectivity increases quadratically with the
  73.    number of routers. Public FR services typically offer performance
  74.    guarantees for each VC provisioned by the service. This means that
  75.    real physical resources in the FR network are devoted to each VC, and
  76.    for this the customer eventually pays. The expense for full-mesh
  77.    connectivity thus grows quadratically with the number of
  78.    interconnected routers.  We need to build OSPF implementations that
  79.    allow for partial connectivity over FR.  Second, using a single link
  80.    metric (per TOS) for the FR interface does not allow OSPF to weigh
  81.    some VCs more heavily than others according to the performance
  82.    characteristics of each connection. To make efficient use of the FR
  83.    network resources, it should be possible to assign different link
  84.    metrics to different VCs.
  85.  
  86.    These limitations of the current OSPF model for FR become more severe
  87.    as the network size increases, and render FR technology less cost
  88.    effective than it could be for large networks. We propose solutions
  89.    to these problems that do not increase complexity by much and do not
  90.    require any changes to the OSPF protocol.
  91.  
  92. 2.  Summary of Recommendations
  93.  
  94.    We propose expanding the general view of an OSPF interface to account
  95.    for its functional type (point-to-point, broadcast, NBMA) rather than
  96.    its physical type. In most instances, the physical network can only
  97.    serve one function and can only be defined as one type of OSPF
  98.    interface. For multiplexed interfaces such as FR however, logical
  99.    connections between routers can serve different functions. Hence one
  100.    VC on a FR interface can be viewed distintly from other VCs on the
  101.    same physical interface.  The solution requires that OSPF be able to
  102.    support logical interfaces (networks) as well as physical interfaces.
  103.    Each logical network can be either point-to-point, that is, a single
  104.    VC, or NBMA, that is, a collection of VCs.  It is not necessary to
  105.    define new interface types for logical networks, since the operation
  106.    of the protocol over logical point-to-point networks and logical NBMA
  107.    networks remains the same as for the corresponding physical networks.
  108.    For instance, logical point-to-point links could be numbered or
  109.    unnumbered.  It is only necessary for implementations to provide the
  110.    hooks that give users the ability to configure an individual VC as a
  111.  
  112.  
  113.  
  114. deSouza & Rodrigues                                             [Page 2]
  115.  
  116. RFC 1586                 OSPF over Frame Relay                March 1994
  117.  
  118.  
  119.    logical point-to-point network or a collection of VCs as a logical
  120.    NBMA network.
  121.  
  122.    The NBMA model does provide some economy in OSPF protocol processing
  123.    and overhead and is the recommended mode of operation for small
  124.    homogeneous networks. Other than the Designated Router (DR) and the
  125.    backup Designated Router (BDR), each router maintains only two
  126.    adjacencies, one each with the DR and BDR, regardless of the size of
  127.    the NBMA network.  When FR VCs are configured as point-to-point
  128.    links, a router would have many more adjacencies to maintain,
  129.    resulting in increased protocol overhead. If all VCs were to have
  130.    comparable performance characteristics as well, there may not be
  131.    compelling reasons to assign a different link metric to each VC.
  132.  
  133. 3.  Implementing OSPF over FR
  134.  
  135.    We recommend that OSPF router implementations be built so that
  136.    administrators can configure network layer interfaces that consist of
  137.    one or more FR VCs within a single physical interface.  Each logical
  138.    network interface could then be configured as the appropriate type of
  139.    OSPF interface, that is, point-to-point for a single VC, or NBMA for
  140.    a collection of VCs.  This capability would allow a router to belong
  141.    to one or more distinct IP subnets on a single physical FR interface.
  142.    Thus, it is necessary that the router be able to support multiple IP
  143.    addresses on a single physical FR interface.  As with physical NBMA
  144.    networks, logical NBMA networks must be full-mesh connected. While
  145.    logical point-to-point links can be either numbered or unnumbered, we
  146.    show that it is easier to implement routers to handle numbered
  147.    logical point-to-point links.
  148.  
  149. 3.1  Numbered Logical Interfaces
  150.  
  151.    The router administrator should be able to configure numbered logical
  152.    interfaces over FR as follows:
  153.  
  154.      STEP 1: Configure the physical interface specifying relevant
  155.              parameters such as the slot, connector, and port numbers,
  156.              physical frame format, encoding, and clock mode. In its
  157.              internal interface MIB [3], the router should create a new
  158.              ifEntry in the ifTable, assign the physical interface an
  159.              ifIndex, and increment the ifNumber by one.
  160.  
  161.      STEP 2: Configure the data-link layer over the interface,
  162.              specifying frame relay as the encapsulation method.
  163.              Parameters such as the DLCI encoding type and length,
  164.              maximum frame size, management interface (Annex D, LMI),
  165.              and address resolution procedure (manual, inverse ARP). If
  166.              a management interface is not supported, FR VCs must be
  167.  
  168.  
  169.  
  170. deSouza & Rodrigues                                             [Page 3]
  171.  
  172. RFC 1586                 OSPF over Frame Relay                March 1994
  173.  
  174.  
  175.              configured manually.
  176.  
  177.      STEP 3: Configure the IP network layer for the interface by
  178.              specifying the number of logical interfaces and the IP
  179.              address and subnet mask for each numbered logical
  180.              interface. Specify the VCs (by DLCI) associated with each
  181.              logical network interface if there is more than one.  If an
  182.              address resolution protocol such as  Inverse ARP [4] is
  183.              being used, it should suffice to specify a list of IP
  184.              addresses for the FR interface and have Inverse ARP create
  185.              the DLCI-IP address binding.
  186.  
  187.      STEP 4: Configure OSPF to run over each logical interface as
  188.              appropriate, specifying the necessary interface parameters
  189.              such as area ID, link metric, protocol timers and
  190.              intervals, DR priority, and list of neighbors (for the DR).
  191.              OSPF interfaces consisting of one VC can be treated as
  192.              point-to-point links while multi-VC OSPF interfaces are
  193.              treated as NBMA subnets. In its internal OSPF MIB [5], the
  194.              router should create additional entries in the ospfIfTable
  195.              each with the appropriate ospfIfType (nbma or
  196.              pointTopoint).
  197.  
  198. 3.2  Unnumbered Point-to-Point Logical Interfaces
  199.  
  200.    OSPF uses the IP address to instance each numbered interface.
  201.    However, since an unnumbered point-to-point link does not have an IP
  202.    address, the ifIndex from the interface MIB is used instead [5].
  203.    This is straightforward for a physical point-to-point network, since
  204.    the ifIndex is assigned when the interface is configured.  Logical
  205.    interfaces over FR however, do not have distinct and unique values
  206.    for ifIndex. To allow OSPF to instance unnumbered logical point-to-
  207.    point links, it is necessary to assign each such link a unique
  208.    ifIndex in STEP 3 above. This could lead to some confusion in the
  209.    interfaces table since a new ifTable entry would have to be created
  210.    for each logical point-to-point link. This type of departure from the
  211.    standard practice of creating interface table entries only for
  212.    physical interfaces could be viewed as an unnecessary complication.
  213.  
  214.    Alternatively, it is possible to build a private MIB that contains
  215.    data structures to instance unnumbered logical links. However, making
  216.    recommendations for the structure and use of such a private MIB is
  217.    beyond the scope of this work.  Even if unnumbered point-to-point
  218.    logical links were implemented in this manner, it would still be
  219.    necessary to allow a FR interface to be configured with multiple IP
  220.    addresses when a router is connected to multiple NBMA subnets through
  221.    a single physical interface.  Hence, while it is possible to define
  222.    unnumbered logical point-to-point links in OSPF, we find this
  223.  
  224.  
  225.  
  226. deSouza & Rodrigues                                             [Page 4]
  227.  
  228. RFC 1586                 OSPF over Frame Relay                March 1994
  229.  
  230.  
  231.    alternative less attractive than using numbered logical point-to-
  232.    point links.
  233.  
  234. 4.  Using OSPF over FR
  235.  
  236.    The ability to configure distinct logical interfaces over FR gives
  237.    users a great deal of flexibility in designing FR networks for use
  238.    with OSPF. Because routers can be partially interconnected over FR,
  239.    it is possible to design networks more cost-effectively than before.
  240.    The issues to consider are the price/cost structure for VCs (fixed,
  241.    distance-sensitive, banded) and ports, performance guarantees
  242.    provided, traffic distribution (local, long-haul), and protocol
  243.    efficiency. We have mentioned that the NBMA model provides some
  244.    economy in OSPF protocol processing and overhead and is recommended
  245.    for small homogeneous networks. In general, users should configure
  246.    their networks to contain several small "NBMA clusters," which are in
  247.    turn interconnected by long-haul VCs. The best choices for the number
  248.    of routers in each cluster and the size of the long-haul logical
  249.    point-to-point links depends on the factors mentioned above. If it is
  250.    necessary to architect a more "flat" network, the ability to assign
  251.    different link metrics to different (groups of) VCs allows for
  252.    greater efficiency in using FR resources since VCs with better
  253.    performance characteristics (throughput, delay) could be assigned
  254.    lower link metrics.
  255.  
  256. 5.  Conclusion
  257.  
  258.    We have specified guidelines for OSPF implementors and users to bring
  259.    about improvements in how the protocol runs over frame relay
  260.    networks. These recommendations do not require any protocol changes
  261.    and allow for simpler, more efficient and cost-effective network
  262.    designs. We recommend that OSPF implementations be able to support
  263.    logical interfaces, each consisting of one or more virtual circuits
  264.    and used as numbered logical point-to-point links (one VC) or logical
  265.    NBMA networks (more than one VC). The current NBMA model for frame
  266.    relay should continue to be used for small homogeneous networks
  267.    consisting of a few routers.
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. deSouza & Rodrigues                                             [Page 5]
  283.  
  284. RFC 1586                 OSPF over Frame Relay                March 1994
  285.  
  286.  
  287. 6.  References
  288.  
  289.    [1] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect
  290.        over Frame Relay", RFC 1294, Wellfleet Communications, Inc., BBN
  291.        Communications, January 1992.
  292.  
  293.    [2] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
  294.  
  295.    [3] McCloghrie, K., and M. Rose, Editors, "Management Information
  296.        Base for Network Management of TCP/IP-based Internets: MIB-II",
  297.        STD 17, RFC 1213, Hughes LAN Systems, Inc., Performance Systems
  298.        International, March 1991.
  299.  
  300.    [4] Bradley, T., and C. Brown, "Inverse Address Resolution Protocol",
  301.        RFC 1293, Wellfleet Communications, Inc., January 1992.
  302.  
  303.    [5] Baker, F.,  and R. Coltun, "OSPF Version 2 Management Information
  304.        Base", RFC 1253, ACC, Computer Science Center, August 1991.
  305.  
  306. Security Considerations
  307.  
  308.    Security issues are not discussed in this memo.
  309.  
  310. 7.  Authors' Addresses
  311.  
  312.    Osmund S. deSouza
  313.    AT&T Bell Laboratories
  314.    Room 1K-606
  315.    101 Crawfords Corner Road
  316.    Holmdel, NJ 07733
  317.  
  318.    Phone: (908) 949-1393
  319.    EMail: osmund.desouza@att.com
  320.  
  321.  
  322.    Manoel A. Rodrigues
  323.    Room 1K-608
  324.    AT&T Bell Laboratories
  325.    101 Crawfords Corner Road
  326.    Holmdel, NJ 07733
  327.  
  328.    Phone: (908) 949-4655
  329.    EMail: manoel.rodrigues@att.com
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. deSouza & Rodrigues                                             [Page 6]
  339.  
  340.