home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-ospf-atm-00.txt < prev    next >
Text File  |  1997-10-31  |  21KB  |  513 lines
  1.  
  2.  
  3.  
  4. Internet Engineering Task Force                    T. Przygienda/P. Droz
  5. INTERNET DRAFT                                                  Fore/IBM
  6.                                                          30 October 1997
  7.  
  8.  
  9.                       OSPF over ATM and Proxy PAR
  10.                       <draft-ietf-ospf-atm-00.txt>
  11.  
  12.  
  13. Status of This Memo
  14.  
  15.    This document is an Internet Draft, and can be found as
  16.    draft-ietf-ospf-atm-00.txt in any standard internet drafts
  17.    repository.  Internet Drafts are working documents of the Internet
  18.    Engineering Task Force (IETF), its Areas, and its Working Groups.
  19.    Note that other groups may also distribute working documents as
  20.    Internet Drafts.
  21.  
  22.    Internet Drafts are draft documents valid for a maximum of six
  23.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  24.    other documents at any time.  It is not appropriate to use Internet
  25.    Drafts as reference material, or to cite them other than as a
  26.    ``working draft'' or ``work in progress.''
  27.  
  28.    Please check the I-D abstract listing contained in each Internet
  29.    Draft directory to learn the current status of this or any other
  30.    Internet Draft.
  31.  
  32.  
  33. Abstract
  34.  
  35.    This draft specifes for OSPF implementors and users mechanisms
  36.    describing how the protocol operates in ATM networks over PVC and SVC
  37.    meshes with the presence of Proxy PAR. These recommendations do not
  38.    require any protocol changes and allow for simpler, more efficient
  39.    and cost- effective network designs.  It is recommended that OSPF
  40.    implementations should be able to support logical interfaces, each
  41.    consisting of one or more virtual circuits and used as numbered
  42.    logical point-to-point links (one VC) or logical NBMA networks (more
  43.    than one VC) where a solution simulating broadcast interfaces is not
  44.    appropriate.  Proxy PAR can help to distribute configuration changes
  45.    of such interfaces when OSPF capable routers are reconfigured on the
  46.    ATM cloud.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Przygienda, Droz               Expires 5 May 1998               [Page 1]
  54.  
  55. Internet Draft        OSPF over ATM and Proxy PAR        30 October 1997
  56.  
  57.  
  58. 1. Introduction
  59.  
  60. 1.1. Introduction to Proxy PAR
  61.  
  62.    Proxy PAR [CPS96, PD97] is an extension allowing for different ATM
  63.    attached devices to interact with PAR capable switches and obtain
  64.    information about non-ATM services without executing PAR [Ca96] which
  65.    is an extension of PNNI [AF96b] themselves.  The client side is much
  66.    simpler in terms of implementation complexity and memory requirements
  67.    than a complete PAR stack and should allow for easy implementation in
  68.    e.g.  existing IP routers.  Additionally, clients can use Proxy PAR
  69.    to register different non-ATM services and protocols they support.
  70.    Proxy PAR has consciously not been included as part of ILMI due to
  71.    the complexity of PAR information passed in the protocol and the
  72.    fact that it is intended for integration of non-ATM protocols and
  73.    services only.  A device executing Proxy PAR does not necessarily
  74.    need to execute ILMI or UNI signaling although this normally will be
  75.    the case.  The context or reference model is therefore aligned with
  76.    the one included in [AF96a].
  77.  
  78.    The protocol in itself does not specify how the distributed service
  79.    registration and data delivered to the client is supposed to be
  80.    driving other protocols so OSPF routers finding themselves through
  81.    proxy PAR could use this information in e.g.  RFC1577 [Lau94]
  82.    fashion, forming a full mesh of point- to-point connections to
  83.    interact with each other to simulate broadcast interfaces.  For the
  84.    same purpose LANE [AF95] or MARS [Arm96] could be used.  Contrary
  85.    to such solutions, this RFC elaborates on how to handle virtual
  86.    OSPF interfaces over ATM such as NBMA, point-to-multipoint or
  87.    point-to-point and allow for their auto-configuration in presence of
  88.    Proxy PAR. One advantage is the circumvention of server solutions
  89.    that often present single points of failure or hold large amounts of
  90.    configuration information.  The other main benefit is the possibility
  91.    to execute OSPF on top of partially meshed VC topologies.
  92.  
  93.    As a by-product, Proxy PAR could provide the ATM address resolution
  94.    for IP attached devices but such resolution can be achieved by other
  95.    protocols under specification in IETF as well, e.g.  [CH97a, CH97b].
  96.    Last but not least, it should be mentioned here that the protocol
  97.    coexists with and complements the ongoing work in IETF on server
  98.    detection via ILMI extensions [Dav97] and opaque LSAs [CH97a, CH97b].
  99.  
  100.  
  101.  
  102.  
  103.  
  104. Przygienda, Droz               Expires 5 May 1998               [Page 2]
  105.  
  106. Internet Draft        OSPF over ATM and Proxy PAR        30 October 1997
  107.  
  108.  
  109. 1.1.1. Proxy PAR scopes
  110.  
  111.    Any Proxy PAR registration is carried only within a defined scope
  112.    that is set during registration and is equivalent to the PNNI routing
  113.    level.  Since no assumptions except scope values can be made about
  114.    the information distributed (e.g.  IP addresses bound to NSAPs
  115.    are not assumed to be aligned with them in any respect such as
  116.    encapsulation or functional mapping), registration information cannot
  117.    be summarized.  This makes a careful handling of scopes necessary to
  118.    preserve the scalability.
  119.  
  120.  
  121. 1.2. Introduction to OSPF
  122.  
  123.    OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP)
  124.    and described in [Moy94, Moy97] from which most of the following
  125.    paragraphs has been taken almost literally.  OSPF distributes routing
  126.    information between routers belonging to a single Autonomous System.
  127.    The OSPF protocol is based on link-state or SPF technology.  It was
  128.    developed by the OSPF working group of the Internet Engineering
  129.    Task Force.  It has been designed expressly for the TCP/IP internet
  130.    environment, including explicit support for IP subnetting, and
  131.    the tagging of externally-derived routing information.  OSPF also
  132.    utilizes IP multicast when sending/receiving the updates.  In
  133.    addition, much work has been done to produce a protocol that responds
  134.    quickly to topology changes, yet involves small amounts of routing
  135.    protocol traffic.
  136.  
  137.    To cope with the needs of NBMA and demand circuits capable networks
  138.    such as Frame Relay or X.25, [Moy95] has been made available that
  139.    standardizes extensions to the protocol allowing for efficient
  140.    operation over on-demand circuits.
  141.  
  142.    OSPF supports three types of networks today:
  143.  
  144.     -  Point-to-point networks:  A network that joins a single pair
  145.        of routers.  Point- to-point networks can either be numbered
  146.        or unnumbered in the latter case the interfaces do not have IP
  147.        addresses nor masks.  Even when numbered, both sides of the link
  148.        do not have to agree on the IP subnet.
  149.  
  150.     -  Broadcast networks:  Networks supporting many (more than two)
  151.        attached routers, together with the capability to address
  152.        a single physical message to all of the attached routers
  153.  
  154.  
  155. Przygienda, Droz               Expires 5 May 1998               [Page 3]
  156.  
  157. Internet Draft        OSPF over ATM and Proxy PAR        30 October 1997
  158.  
  159.  
  160.        (broadcast).  Neighboring routers are discovered dynamically
  161.        on these nets using OSPF's Hello Protocol.  The Hello Protocol
  162.        itself takes advantage of the broadcast capability.  The protocol
  163.        makes further use of multicast capabilities, if they exist.  An
  164.        Ethernet is an example of a broadcast network.
  165.  
  166.     -  Non-broadcast networks:  Networks supporting many (more than
  167.        two) attached routers, but having no broadcast capability.
  168.        Neighboring routers are maintained on these nets using
  169.        OSPF's Hello Protocol.  However, due to the lack of broadcast
  170.        capability, some configuration information is necessary for the
  171.        correct operation of the Hello Protocol.  On these networks, OSPF
  172.        protocol packets that are normally multicast need to be sent to
  173.        each neighboring router, in turn.  An X.25 Public Data Network
  174.        (PDN) is an example of a non-broadcast network.
  175.  
  176.        OSPF runs in one of two modes over non-broadcast networks.  The
  177.        first mode, called non-broadcast multi-access (NBMA), simulates
  178.        the operation of OSPF on a broadcast network.  The second mode,
  179.        called Point-to-MultiPoint, treats the non-broadcast network as a
  180.        collection of point-to-point links.  Non-broadcast networks are
  181.        referred to as NBMA networks or Point-to-MultiPoint networks,
  182.        depending on OSPF's mode of operation over the network.
  183.  
  184.  
  185. 2. OSPF over ATM
  186.  
  187. 2.1. Model
  188.  
  189.    Parallel to [dR94] that describes the recommended operation of
  190.    OSPF over Frame Relay networks, a similar model is assumed where
  191.    the underlying ATM network can be used to model single VCs as
  192.    point-to-point interfaces or collections of VCs can be accessed as an
  193.    non-broadcast interface in NBMA or point-to-multipoint mode.  Such a
  194.    VC or collection of VCs is called a logical interface and specified
  195.    through its type (either point-to-point, NBMA or point-to-point),
  196.    IP instance (presenting an incarnation of IP with its own address
  197.    spaces), address and mask.  Layer 2 specific configuration such as
  198.    address resolution method, class and quality of service of used
  199.    circuits and other must be also included.  As logical consequence
  200.    thereof, a single, physical interface could encompass multiple IP
  201.    subnets or even multiple, independent IP instances.  In contrary to
  202.    layer 2 and IP addressing information, when running Proxy PAR, most
  203.    of the OPSF information needed to operate such a logical interface
  204.  
  205.  
  206. Przygienda, Droz               Expires 5 May 1998               [Page 4]
  207.  
  208. Internet Draft        OSPF over ATM and Proxy PAR        30 October 1997
  209.  
  210.  
  211.    does not have to be configured into routers statically but can be
  212.    provided through Proxy PAR queries.  This allows for much more
  213.    dynamic configuration of VC meshes in OSPF environments than e.g.  in
  214.    Frame Relay solutions.
  215.  
  216.  
  217. 2.2. OSPF Configuration Interaction with Proxy PAR
  218.  
  219.    To achieve the goal of simplification of VC mesh reconfiguration,
  220.    Proxy PAR allows the router to learn automatically most of the
  221.    configuration that has to be provided to OSPF. Non-broadcast
  222.    and point-to-point interface information can be learned across
  223.    an ATM cloud as described in the ongoing sections.  It is up to
  224.    the implementation to possibly allow for a mixture of Proxy PAR
  225.    autoconfiguration and manual configuration of neighbor information.
  226.    Moreover, manual configuration could e.g.  override or complement
  227.    information derived from a proxy PAR client.  Additionally, OSPF
  228.    extensions to handle on-demand circuits [Moy95] can be used to allow
  229.    for graceful tearing down of VCs not carrying any OSPF traffic over
  230.    prolonged periods of time.
  231.  
  232.    Even after autoconfiguration of interfaces has been provided, the
  233.    problem of VC setups in an ATM network is unsolved since none of the
  234.    normally used mechanisms such as RFC1577 [Lau94] or LANE [AF95] are
  235.    assumed to be present.  Section 2.3 describes the behavior of OSPF
  236.    routers to allow for router connectivity necessary.
  237.  
  238.  
  239. 2.2.1. Autoconfiguration of non-broadcast interfaces
  240.  
  241.    Proxy PAR allows to autoconfigure the list of all routers residing
  242.    on the same IP network in the same IP instance by simply querying
  243.    the Proxy PAR server.  Each router can easily obtain the list of
  244.    all OSPF routers on the same subnet with their router priorities
  245.    and ATM address bindings.  This is the precondition for OSPF to
  246.    work properly across such logical NBMA interfaces.  Note that the
  247.    memberlist, when learned through Proxy PAR queries, can dynamically
  248.    change with PNNI (in)stability and general ATM network behavior.  It
  249.    maybe preferable for an implementation to withdraw list membership
  250.    e.g.  much slower than detect new members.  Relying on OSPF mechanism
  251.    to discover lack of reachability in the overlaying logical IP network
  252.    could alleviate the risk of thrashing DR elections and excessive
  253.    information flooding.  Once the DR registration is completed and the
  254.    router has not been elected DR or BDR, an implementation of [Moy95]
  255.  
  256.  
  257. Przygienda, Droz               Expires 5 May 1998               [Page 5]
  258.  
  259. Internet Draft        OSPF over ATM and Proxy PAR        30 October 1997
  260.  
  261.  
  262.    can ignore the fact that all routers on the specific NBMA subnet are
  263.    available in its configuration since it only needs to maintain VCs to
  264.    the DR and BDR.
  265.  
  266.  
  267. 2.2.2. Autoconfiguration of point-to-multipoint interfaces
  268.  
  269.    Point-to-Multipoint interfaces in ATM networks only make sense if
  270.    no VCs can be dynamically set up since an SVC-capable ATM network
  271.    normally presents a NBMA cloud.  This is e.g.  the case if the
  272.    intended use of the network is only to execute OSPF in presence of a
  273.    partial PVC or SPVC mesh.  Such a collection could be modeled using
  274.    the point-to-multipoint OSPF interface and the neighbor detection
  275.    could be provided by Proxy PAR or other means.  In Proxy PAR case
  276.    the router queries for all OSPF routers on the same network in the
  277.    same IP instance but it installs in the interface configuration
  278.    only routers that are already reachable through preset PVCs.  The
  279.    underlying assumption is that a router understands the remote NSAP of
  280.    a PVC and can compare it with appropriate Proxy PAR registrations.
  281.    If the remote NSAP of the PVC is unknown, alternative autodiscovery
  282.    mechanisms have to be used e.g.  inverse ARP [BB92].
  283.  
  284.  
  285. 2.2.3. Autoconfiguration of numbered point-to-point interfaces
  286.  
  287.    OSPF point-to-point links do not necessarily have an IP address
  288.    assigned and even when having one, the mask is undefined.  As a
  289.    precondition to successfully register a service with Proxy PAR, IP
  290.    address and mask is required.  Therefore, if a router desires to use
  291.    Proxy PAR to advertise the local end of a point-to- point link to the
  292.    router it intends to form an adjacency with, an IP address has to
  293.    be provided and a netmask set or a default of 255.255.255.254 (this
  294.    gives as the default case a subnet with 2 routers on it) assumed.  To
  295.    allow the discovery of the remote end of the interface, IP address
  296.    of the remote side has to be provided and a netmask set or a default
  297.    of 255.255.255.254 assumed.  Obviously the discovery can only be
  298.    successfull when both sides of the interface are configured with the
  299.    same network mask and are within the same IP network.  The situation
  300.    where more than two possible neighbors are discovered through
  301.    queries and the interface type is set to point-to-point presents a
  302.    configuration error.
  303.  
  304.  
  305.  
  306.  
  307.  
  308. Przygienda, Droz               Expires 5 May 1998               [Page 6]
  309.  
  310. Internet Draft        OSPF over ATM and Proxy PAR        30 October 1997
  311.  
  312.  
  313. 2.2.4. Autoconfiguration of unnumbered point-to-point interfaces
  314.  
  315.    For reasons given already in [dR94] using unnumbered point-to-point
  316.    interfaces with Proxy PAR is not a very attractive alternative
  317.    since the lack of an IP address prevents efficient registration and
  318.    retrieval of configuration information.  Relying on the numbering
  319.    method based on MIB entries generates conflicts with the dynamic
  320.    nature of creation of such entries and is beyond the scope of this
  321.    work.
  322.  
  323.  
  324. 2.3. Proxy PAR Interaction with OSPF Configuration
  325.  
  326.    To allow other routers to discover an OSPF interface automatically,
  327.    the IP address, mask, Area ID, interface type and router priority
  328.    information given must be registered with the Proxy PAR server at an
  329.    appropriate scope.  A change in any of these parameters has to force
  330.    a reregistration with Proxy PAR.
  331.  
  332.  
  333. 2.3.1. Registration of non-broadcast interfaces
  334.  
  335.    For an NBMA interface the appropriate parameters are available and
  336.    can be registered through Proxy PAR without further complications.
  337.  
  338.  
  339. 2.3.2. Registration of point-to-multipoint interfaces
  340.  
  341.    In case of a point-to-multipoint interface the router registers its
  342.    information in the same fashion as in the NBMA case except that the
  343.    interface type is modified accordingly.
  344.  
  345.  
  346. 2.3.3. Registration of point-to-point interfaces
  347.  
  348.    In case of point-to-point numbered interfaces the address mask is not
  349.    specified in the OSPF configuration.  If the router has to use Proxy
  350.    PAR to advertise its capability, a mask must be defined or a default
  351.    value of 255.255.255.254 used.
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359. Przygienda, Droz               Expires 5 May 1998               [Page 7]
  360.  
  361. Internet Draft        OSPF over ATM and Proxy PAR        30 October 1997
  362.  
  363.  
  364. 2.3.4. Registration of unnumbered point-to-point interfaces
  365.  
  366.    Due to the lack of a configured IP address and difficulties generated
  367.    by this fact as described earlier, registration of unnumbered
  368.    point-to-point interfaces is not covered in this document.
  369.  
  370.  
  371. 2.4. Connection setup mechanisms
  372.  
  373.    This sections describes OSPF behavior in an ATM network under
  374.    different assumptions in terms of signaling capabilities and preset
  375.    connectivity.
  376.  
  377.  
  378. 2.4.1. OSPF in PVC environments
  379.  
  380.    In environments where only partial PVCs (or SPVCs) meshes are
  381.    available and modeled as point-to-multipoint interfaces, the routers
  382.    see reachable routers through autodiscovery provided by Proxy PAR.
  383.    This leads to expected OSPF behavior.  In cases where a full mesh of
  384.    PVCs is present, such an interface should preferably be modeled as
  385.    broadcast and Proxy PAR discovery should be superfluous.
  386.  
  387.  
  388. 2.4.2. OSPF in SVC environments
  389.  
  390.    In SVC-capable environments the routers can initiate VCs after having
  391.    discovered the appropriate neighbors, preferably driven by the need
  392.    to send data such as Hello-packets.  Since this can lead to race
  393.    conditions where both sides can open a VC and it is desirable to
  394.    minimize this valuable resource, if the router with lower Router ID
  395.    detects that the VC initiated by the other side is bidirectional, it
  396.    is free to close its own VC and use the detected one.  The existence
  397.    of VCs used for OSPF exchanges is orthogonal to the number and type
  398.    of VCs the router chooses to use within the logical interface to
  399.    forward data to other routers.  OSPF implementations are free to use
  400.    any of these VCs to send packets if their endpoints are adequate and
  401.    must accept hello packets arriving on any of the VCs belonging to the
  402.    logical interface.
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410. Przygienda, Droz               Expires 5 May 1998               [Page 8]
  411.  
  412. Internet Draft        OSPF over ATM and Proxy PAR        30 October 1997
  413.  
  414.  
  415. 3. Acknowledgments
  416.  
  417.    Comments and contributions from several sources, especially Rob
  418.    Coltun and John Moy are included in this work.
  419.  
  420.  
  421. 4. Security Consideration
  422.  
  423.    Security issues are not discussed in this memo.
  424.  
  425.  
  426.  
  427. References
  428.  
  429.    [AF95]  ATM-Forum.  LAN Emulation over ATM 1.0.  ATM Forum
  430.            af-lane-0021.000, January 1995.
  431.  
  432.    [AF96a] ATM-Forum.  Interim Local Management Interface (ILMI)
  433.            Specification 4.0.  ATM Forum 95-0417R8, June 1996.
  434.  
  435.    [AF96b] ATM-Forum.  Private Network-Network Interface Specification
  436.            Version 1.0.  ATM Forum af-pnni-0055.000, March 1996.
  437.  
  438.    [Arm96] G. Armitage.  Support for Multicast over UNI 3.0/3.1 based
  439.            ATM Networks, RFC 2022.  Internet Engineering Task Force,
  440.            November 1996.
  441.  
  442.    [BB92]  T. Bradley and C. Brown.  Inverse Address Resolution
  443.            Protocol, RFC 1293.  Internet Engineering Task Force, January
  444.            1992.
  445.  
  446.    [Ca96]  R. Callon and al.  An Overview of Pnni Augmented Routing.
  447.            ATM Forum 96-0354, April 1996.
  448.  
  449.    [CH97a] R. Coltun and J. Heinanen.  Opaque LSA in OSPF.  Internet
  450.            Draft, 1997.
  451.  
  452.    [CH97b] R. Coltun and J. Heinanen.  The OSPF Address Resolution
  453.            Advertisement Option.  Internet Draft, 1997.
  454.  
  455.    [CPS96] R. Coltun, T. Przygienda, and S. Shew.  MIPAR: Minimal PNNI
  456.            Augmented Routing.  ATM Forum 96-0838, June 1996.
  457.  
  458.  
  459.  
  460.  
  461. Przygienda, Droz               Expires 5 May 1998               [Page 9]
  462.  
  463. Internet Draft        OSPF over ATM and Proxy PAR        30 October 1997
  464.  
  465.  
  466.    [Dav97] M. Davison.  Simple ILMI-Based Server Discovery.  Internet
  467.            Draft, 1997.
  468.  
  469.    [dR94]  O. deSouza and M. Rodrigues.  Guidelines for Running OSPF
  470.            Over Frame Relay Networks, RFC 1586.  Internet Engineering
  471.            Task Force, March 1994.
  472.  
  473.    [Lau94] M. Laubach.  Classical IP and ARP over ATM, RFC 1577.
  474.            Internet Engineering Task Force, January 1994.
  475.  
  476.    [Moy94] J. Moy.  OSPFv2, RFC 1583.  Internet Engineering Task Force,
  477.            March 1994.
  478.  
  479.    [Moy95] J. Moy.  Extending OSPF to Support Demand Circuits, RFC 1793.
  480.            Internet Engineering Task Force, April 1995.
  481.  
  482.    [Moy97] J. Moy.  OSPFv2, RFC 2178.  Internet Engineering Task Force,
  483.            July 1997.
  484.  
  485.    [PD97]  T. Przygienda and P. Droz.  Proxy PAR.  ATM Forum 97-0495,
  486.            97-0705, 97-0882, July 1997.
  487.  
  488.  
  489. Authors' Addresses
  490.  
  491.  
  492. Tony Przygienda
  493. FORE Systems
  494. 6905 Rockledge Drive
  495. Suite 800
  496. Bethesda, MD 20817
  497. prz@fore.com
  498.  
  499. Patrick Droz
  500. IBM Research Division
  501. Saumerstrasse 4
  502. 8803 Ruschlikon
  503. Switzerland
  504. dro@zurich.ibm.com
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512. Przygienda, Droz              Expires 5 May 1998               [Page 10]
  513.