Internet Engineering Task Force T. Przygienda/P. Droz
INTERNET DRAFT Fore/IBM
30 October 1997
OSPF over ATM and Proxy PAR
<draft-ietf-ospf-atm-00.txt>
Status of This Memo
This document is an Internet Draft, and can be found as
draft-ietf-ospf-atm-00.txt in any standard internet drafts
repository. Internet Drafts are working documents of the Internet
Engineering Task Force (IETF), its Areas, and its Working Groups.
Note that other groups may also distribute working documents as
Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material, or to cite them other than as a
``working draft'' or ``work in progress.''
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
This draft specifes for OSPF implementors and users mechanisms
describing how the protocol operates in ATM networks over PVC and SVC
meshes with the presence of Proxy PAR. These recommendations do not
require any protocol changes and allow for simpler, more efficient
and cost- effective network designs. It is recommended that OSPF
implementations should be able to support logical interfaces, each
consisting of one or more virtual circuits and used as numbered
logical point-to-point links (one VC) or logical NBMA networks (more
than one VC) where a solution simulating broadcast interfaces is not
appropriate. Proxy PAR can help to distribute configuration changes
of such interfaces when OSPF capable routers are reconfigured on the
ATM cloud.
Przygienda, Droz Expires 5 May 1998 [Page 1]
Internet Draft OSPF over ATM and Proxy PAR 30 October 1997
1. Introduction
1.1. Introduction to Proxy PAR
Proxy PAR [CPS96, PD97] is an extension allowing for different ATM
attached devices to interact with PAR capable switches and obtain
information about non-ATM services without executing PAR [Ca96] which
is an extension of PNNI [AF96b] themselves. The client side is much
simpler in terms of implementation complexity and memory requirements
than a complete PAR stack and should allow for easy implementation in
e.g. existing IP routers. Additionally, clients can use Proxy PAR
to register different non-ATM services and protocols they support.
Proxy PAR has consciously not been included as part of ILMI due to
the complexity of PAR information passed in the protocol and the
fact that it is intended for integration of non-ATM protocols and
services only. A device executing Proxy PAR does not necessarily
need to execute ILMI or UNI signaling although this normally will be
the case. The context or reference model is therefore aligned with
the one included in [AF96a].
The protocol in itself does not specify how the distributed service
registration and data delivered to the client is supposed to be
driving other protocols so OSPF routers finding themselves through
proxy PAR could use this information in e.g. RFC1577 [Lau94]
fashion, forming a full mesh of point- to-point connections to
interact with each other to simulate broadcast interfaces. For the
same purpose LANE [AF95] or MARS [Arm96] could be used. Contrary
to such solutions, this RFC elaborates on how to handle virtual
OSPF interfaces over ATM such as NBMA, point-to-multipoint or
point-to-point and allow for their auto-configuration in presence of
Proxy PAR. One advantage is the circumvention of server solutions
that often present single points of failure or hold large amounts of
configuration information. The other main benefit is the possibility
to execute OSPF on top of partially meshed VC topologies.
As a by-product, Proxy PAR could provide the ATM address resolution
for IP attached devices but such resolution can be achieved by other
protocols under specification in IETF as well, e.g. [CH97a, CH97b].
Last but not least, it should be mentioned here that the protocol
coexists with and complements the ongoing work in IETF on server
detection via ILMI extensions [Dav97] and opaque LSAs [CH97a, CH97b].
Przygienda, Droz Expires 5 May 1998 [Page 2]
Internet Draft OSPF over ATM and Proxy PAR 30 October 1997
1.1.1. Proxy PAR scopes
Any Proxy PAR registration is carried only within a defined scope
that is set during registration and is equivalent to the PNNI routing
level. Since no assumptions except scope values can be made about
the information distributed (e.g. IP addresses bound to NSAPs
are not assumed to be aligned with them in any respect such as
encapsulation or functional mapping), registration information cannot
be summarized. This makes a careful handling of scopes necessary to
preserve the scalability.
1.2. Introduction to OSPF
OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP)
and described in [Moy94, Moy97] from which most of the following
paragraphs has been taken almost literally. OSPF distributes routing
information between routers belonging to a single Autonomous System.
The OSPF protocol is based on link-state or SPF technology. It was
developed by the OSPF working group of the Internet Engineering
Task Force. It has been designed expressly for the TCP/IP internet
environment, including explicit support for IP subnetting, and
the tagging of externally-derived routing information. OSPF also
utilizes IP multicast when sending/receiving the updates. In
addition, much work has been done to produce a protocol that responds
quickly to topology changes, yet involves small amounts of routing
protocol traffic.
To cope with the needs of NBMA and demand circuits capable networks
such as Frame Relay or X.25, [Moy95] has been made available that
standardizes extensions to the protocol allowing for efficient
operation over on-demand circuits.
OSPF supports three types of networks today:
- Point-to-point networks: A network that joins a single pair
of routers. Point- to-point networks can either be numbered
or unnumbered in the latter case the interfaces do not have IP
addresses nor masks. Even when numbered, both sides of the link
do not have to agree on the IP subnet.
- Broadcast networks: Networks supporting many (more than two)
attached routers, together with the capability to address
a single physical message to all of the attached routers
Przygienda, Droz Expires 5 May 1998 [Page 3]
Internet Draft OSPF over ATM and Proxy PAR 30 October 1997
(broadcast). Neighboring routers are discovered dynamically
on these nets using OSPF's Hello Protocol. The Hello Protocol
itself takes advantage of the broadcast capability. The protocol
makes further use of multicast capabilities, if they exist. An
Ethernet is an example of a broadcast network.
- Non-broadcast networks: Networks supporting many (more than
two) attached routers, but having no broadcast capability.
Neighboring routers are maintained on these nets using
OSPF's Hello Protocol. However, due to the lack of broadcast
capability, some configuration information is necessary for the
correct operation of the Hello Protocol. On these networks, OSPF
protocol packets that are normally multicast need to be sent to
each neighboring router, in turn. An X.25 Public Data Network
(PDN) is an example of a non-broadcast network.
OSPF runs in one of two modes over non-broadcast networks. The
first mode, called non-broadcast multi-access (NBMA), simulates
the operation of OSPF on a broadcast network. The second mode,
called Point-to-MultiPoint, treats the non-broadcast network as a
collection of point-to-point links. Non-broadcast networks are
referred to as NBMA networks or Point-to-MultiPoint networks,
depending on OSPF's mode of operation over the network.
2. OSPF over ATM
2.1. Model
Parallel to [dR94] that describes the recommended operation of
OSPF over Frame Relay networks, a similar model is assumed where
the underlying ATM network can be used to model single VCs as
point-to-point interfaces or collections of VCs can be accessed as an
non-broadcast interface in NBMA or point-to-multipoint mode. Such a
VC or collection of VCs is called a logical interface and specified
through its type (either point-to-point, NBMA or point-to-point),
IP instance (presenting an incarnation of IP with its own address
spaces), address and mask. Layer 2 specific configuration such as
address resolution method, class and quality of service of used
circuits and other must be also included. As logical consequence
thereof, a single, physical interface could encompass multiple IP
subnets or even multiple, independent IP instances. In contrary to
layer 2 and IP addressing information, when running Proxy PAR, most
of the OPSF information needed to operate such a logical interface
Przygienda, Droz Expires 5 May 1998 [Page 4]
Internet Draft OSPF over ATM and Proxy PAR 30 October 1997
does not have to be configured into routers statically but can be
provided through Proxy PAR queries. This allows for much more
dynamic configuration of VC meshes in OSPF environments than e.g. in
Frame Relay solutions.
2.2. OSPF Configuration Interaction with Proxy PAR
To achieve the goal of simplification of VC mesh reconfiguration,
Proxy PAR allows the router to learn automatically most of the
configuration that has to be provided to OSPF. Non-broadcast
and point-to-point interface information can be learned across
an ATM cloud as described in the ongoing sections. It is up to
the implementation to possibly allow for a mixture of Proxy PAR
autoconfiguration and manual configuration of neighbor information.
Moreover, manual configuration could e.g. override or complement
information derived from a proxy PAR client. Additionally, OSPF
extensions to handle on-demand circuits [Moy95] can be used to allow
for graceful tearing down of VCs not carrying any OSPF traffic over
prolonged periods of time.
Even after autoconfiguration of interfaces has been provided, the
problem of VC setups in an ATM network is unsolved since none of the
normally used mechanisms such as RFC1577 [Lau94] or LANE [AF95] are
assumed to be present. Section 2.3 describes the behavior of OSPF
routers to allow for router connectivity necessary.
2.2.1. Autoconfiguration of non-broadcast interfaces
Proxy PAR allows to autoconfigure the list of all routers residing
on the same IP network in the same IP instance by simply querying
the Proxy PAR server. Each router can easily obtain the list of
all OSPF routers on the same subnet with their router priorities
and ATM address bindings. This is the precondition for OSPF to
work properly across such logical NBMA interfaces. Note that the
memberlist, when learned through Proxy PAR queries, can dynamically
change with PNNI (in)stability and general ATM network behavior. It
maybe preferable for an implementation to withdraw list membership
e.g. much slower than detect new members. Relying on OSPF mechanism
to discover lack of reachability in the overlaying logical IP network
could alleviate the risk of thrashing DR elections and excessive
information flooding. Once the DR registration is completed and the
router has not been elected DR or BDR, an implementation of [Moy95]
Przygienda, Droz Expires 5 May 1998 [Page 5]
Internet Draft OSPF over ATM and Proxy PAR 30 October 1997
can ignore the fact that all routers on the specific NBMA subnet are
available in its configuration since it only needs to maintain VCs to
the DR and BDR.
2.2.2. Autoconfiguration of point-to-multipoint interfaces
Point-to-Multipoint interfaces in ATM networks only make sense if
no VCs can be dynamically set up since an SVC-capable ATM network
normally presents a NBMA cloud. This is e.g. the case if the
intended use of the network is only to execute OSPF in presence of a
partial PVC or SPVC mesh. Such a collection could be modeled using
the point-to-multipoint OSPF interface and the neighbor detection
could be provided by Proxy PAR or other means. In Proxy PAR case
the router queries for all OSPF routers on the same network in the
same IP instance but it installs in the interface configuration
only routers that are already reachable through preset PVCs. The
underlying assumption is that a router understands the remote NSAP of
a PVC and can compare it with appropriate Proxy PAR registrations.
If the remote NSAP of the PVC is unknown, alternative autodiscovery
mechanisms have to be used e.g. inverse ARP [BB92].
2.2.3. Autoconfiguration of numbered point-to-point interfaces
OSPF point-to-point links do not necessarily have an IP address
assigned and even when having one, the mask is undefined. As a
precondition to successfully register a service with Proxy PAR, IP
address and mask is required. Therefore, if a router desires to use
Proxy PAR to advertise the local end of a point-to- point link to the
router it intends to form an adjacency with, an IP address has to
be provided and a netmask set or a default of 255.255.255.254 (this
gives as the default case a subnet with 2 routers on it) assumed. To
allow the discovery of the remote end of the interface, IP address
of the remote side has to be provided and a netmask set or a default
of 255.255.255.254 assumed. Obviously the discovery can only be
successfull when both sides of the interface are configured with the
same network mask and are within the same IP network. The situation
where more than two possible neighbors are discovered through
queries and the interface type is set to point-to-point presents a
configuration error.
Przygienda, Droz Expires 5 May 1998 [Page 6]
Internet Draft OSPF over ATM and Proxy PAR 30 October 1997
2.2.4. Autoconfiguration of unnumbered point-to-point interfaces
For reasons given already in [dR94] using unnumbered point-to-point
interfaces with Proxy PAR is not a very attractive alternative
since the lack of an IP address prevents efficient registration and
retrieval of configuration information. Relying on the numbering
method based on MIB entries generates conflicts with the dynamic
nature of creation of such entries and is beyond the scope of this
work.
2.3. Proxy PAR Interaction with OSPF Configuration
To allow other routers to discover an OSPF interface automatically,
the IP address, mask, Area ID, interface type and router priority
information given must be registered with the Proxy PAR server at an
appropriate scope. A change in any of these parameters has to force
a reregistration with Proxy PAR.
2.3.1. Registration of non-broadcast interfaces
For an NBMA interface the appropriate parameters are available and
can be registered through Proxy PAR without further complications.
2.3.2. Registration of point-to-multipoint interfaces
In case of a point-to-multipoint interface the router registers its
information in the same fashion as in the NBMA case except that the
interface type is modified accordingly.
2.3.3. Registration of point-to-point interfaces
In case of point-to-point numbered interfaces the address mask is not
specified in the OSPF configuration. If the router has to use Proxy
PAR to advertise its capability, a mask must be defined or a default
value of 255.255.255.254 used.
Przygienda, Droz Expires 5 May 1998 [Page 7]
Internet Draft OSPF over ATM and Proxy PAR 30 October 1997
2.3.4. Registration of unnumbered point-to-point interfaces
Due to the lack of a configured IP address and difficulties generated
by this fact as described earlier, registration of unnumbered
point-to-point interfaces is not covered in this document.
2.4. Connection setup mechanisms
This sections describes OSPF behavior in an ATM network under
different assumptions in terms of signaling capabilities and preset
connectivity.
2.4.1. OSPF in PVC environments
In environments where only partial PVCs (or SPVCs) meshes are
available and modeled as point-to-multipoint interfaces, the routers
see reachable routers through autodiscovery provided by Proxy PAR.
This leads to expected OSPF behavior. In cases where a full mesh of
PVCs is present, such an interface should preferably be modeled as
broadcast and Proxy PAR discovery should be superfluous.
2.4.2. OSPF in SVC environments
In SVC-capable environments the routers can initiate VCs after having
discovered the appropriate neighbors, preferably driven by the need
to send data such as Hello-packets. Since this can lead to race
conditions where both sides can open a VC and it is desirable to
minimize this valuable resource, if the router with lower Router ID
detects that the VC initiated by the other side is bidirectional, it
is free to close its own VC and use the detected one. The existence
of VCs used for OSPF exchanges is orthogonal to the number and type
of VCs the router chooses to use within the logical interface to
forward data to other routers. OSPF implementations are free to use
any of these VCs to send packets if their endpoints are adequate and
must accept hello packets arriving on any of the VCs belonging to the
logical interface.
Przygienda, Droz Expires 5 May 1998 [Page 8]
Internet Draft OSPF over ATM and Proxy PAR 30 October 1997
3. Acknowledgments
Comments and contributions from several sources, especially Rob
Coltun and John Moy are included in this work.
4. Security Consideration
Security issues are not discussed in this memo.
References
[AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum
af-lane-0021.000, January 1995.
[AF96a] ATM-Forum. Interim Local Management Interface (ILMI)
Specification 4.0. ATM Forum 95-0417R8, June 1996.
[AF96b] ATM-Forum. Private Network-Network Interface Specification
Version 1.0. ATM Forum af-pnni-0055.000, March 1996.
[Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based
ATM Networks, RFC 2022. Internet Engineering Task Force,
November 1996.
[BB92] T. Bradley and C. Brown. Inverse Address Resolution
Protocol, RFC 1293. Internet Engineering Task Force, January
1992.
[Ca96] R. Callon and al. An Overview of Pnni Augmented Routing.
ATM Forum 96-0354, April 1996.
[CH97a] R. Coltun and J. Heinanen. Opaque LSA in OSPF. Internet
Draft, 1997.
[CH97b] R. Coltun and J. Heinanen. The OSPF Address Resolution
Advertisement Option. Internet Draft, 1997.
[CPS96] R. Coltun, T. Przygienda, and S. Shew. MIPAR: Minimal PNNI
Augmented Routing. ATM Forum 96-0838, June 1996.
Przygienda, Droz Expires 5 May 1998 [Page 9]
Internet Draft OSPF over ATM and Proxy PAR 30 October 1997
[Dav97] M. Davison. Simple ILMI-Based Server Discovery. Internet
Draft, 1997.
[dR94] O. deSouza and M. Rodrigues. Guidelines for Running OSPF
Over Frame Relay Networks, RFC 1586. Internet Engineering
Task Force, March 1994.
[Lau94] M. Laubach. Classical IP and ARP over ATM, RFC 1577.
Internet Engineering Task Force, January 1994.
[Moy94] J. Moy. OSPFv2, RFC 1583. Internet Engineering Task Force,
March 1994.
[Moy95] J. Moy. Extending OSPF to Support Demand Circuits, RFC 1793.
Internet Engineering Task Force, April 1995.
[Moy97] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force,
July 1997.
[PD97] T. Przygienda and P. Droz. Proxy PAR. ATM Forum 97-0495,
97-0705, 97-0882, July 1997.
Authors' Addresses
Tony Przygienda
FORE Systems
6905 Rockledge Drive
Suite 800
Bethesda, MD 20817
prz@fore.com
Patrick Droz
IBM Research Division
Saumerstrasse 4
8803 Ruschlikon
Switzerland
dro@zurich.ibm.com
Przygienda, Droz Expires 5 May 1998 [Page 10]
