draft-ietf-ospf-atm-03.txt   rfc2844.txt 
Internet Engineering Task Force OSPF WG
Internet Draft T. Przygienda/P. Droz/R. Haas
draft-ietf-ospf-atm-03.txt Siara / IBM / IBM
August 24, 1999
Expires: February 24, 2000
OSPF over ATM and Proxy PAR Network Working Group T. Przygienda
Request for Comments: 2844 Siara
Category: Experimental P. Droz
R. Haas
IBM
May 2000
Status of this memo OSPF over ATM and Proxy-PAR
This document is an Internet-Draft and is in full conformance with Status of this Memo
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task This memo defines an Experimental Protocol for the Internet
Force (IETF), its areas, and its working groups. Note that other groups community. It does not specify an Internet standard of any kind.
may also distribute working documents as Internet-Drafts. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This draft specifes for OSPF implementors and users mechanisms describ This memo specifies, for OSPF implementors and users, mechanisms
ing how the protocol operates in ATM networks over PVC and SVC meshes describing how the protocol operates in ATM networks over PVC and SVC
with the presence of Proxy PAR. These recommendations do not require any meshes with the presence of Proxy-PAR. These recommendations require
protocol changes and allow for simpler, more efficient and cost-effec no protocol changes and allow simpler, more efficient and cost-
tive network designs. It is recommended that OSPF implementations should effective network designs. It is recommended that OSPF
be able to support logical interfaces, each consisting of one or more implementations should be able to support logical interfaces, each
virtual circuits and used either as numbered logical point-to-point consisting of one or more virtual circuits and used either as
links (one VC), logical NBMA networks (more than one VC) or point-to- numbered logical point-to-point links (one VC), logical NBMA networks
multipoint networks (more than one VC), where a solution simulating (more than one VC) or Point-to-MultiPoint networks (more than one
broadcast interfaces is not appropriate. PAR can help to distribute VC), where a solution simulating broadcast interfaces is not
across the ATM cloud configuration set-up and changes of such interfaces appropriate. PAR can help distribute across the ATM cloud
when OSPF capable routers are (re-)configured. Proxy-PAR can in turn be configuration setup and changes of such interfaces when OSPF capable
used to exchange this information between the ATM cloud and the routers routers are (re-)configured. Proxy-PAR can in turn be used to
connected to it. exchange this information between the ATM cloud and the routers
connected to it.
1 Introduction 1 Introduction
Proxy-PAR and PAR have been accepted as standards by the ATM Forum in Proxy-PAR and PAR have been accepted as standards by the ATM Forum in
January 1999 [1]. A more complete overview of Proxy PAR than in the January 1999 [1]. A more complete overview of Proxy-PAR than in the
section below is given in [2]. section below is given in [2].
1.1 Introduction to Proxy PAR 1.1 Introduction to Proxy-PAR
Proxy PAR [1] is an extension allowing for different ATM attached Proxy-PAR [1] is an extension that allows different ATM attached
devices (like routers) to interact with PAR capable switches and query devices (like routers) to interact with PAR-capable switches and to
information about non-ATM services without executing PAR themselves. The query information about non-ATM services without executing PAR
Proxy PAR client side in the ATM attached device is much simpler in themselves. The Proxy-PAR client side in the ATM attached device is
terms of implementation complexity and memory requirements than a com much simpler in terms of implementation complexity and memory
plete PAR protocol stack (which includes the full PNNI [3] protocol requirements than a complete PAR protocol stack (which includes the
stack) and should allow easy implementation in e.g. existing IP routers. full PNNI [3] protocol stack) and should allow easy implementation,
Additionnaly, clients can use Proxy PAR to register different non-ATM e.g. in existing IP routers. In addition, clients can use Proxy-PAR
services and protocols they support. Proxy PAR has consciously not been to register the various non-ATM services and protocols they support.
included as part of ILMI [4] due to the complexity of PAR information Proxy PAR has consciously been omitted as part of ILMI [4] due to the
passed in the protocol and the fact that it is intended for integration complexity of PAR information passed in the protocol and the fact
of non-ATM protocols and services only. A device executing Proxy PAR that it is intended for integration of non-ATM protocols and services
does not necessarily need to execute ILMI or UNI signaling, although only. A device that executes Proxy-PAR does not necessarily need to
this normally will be the case. execute ILMI or UNI signaling, although this normally will be the
case.
The protocol in itself does not specify how the distributed service reg The protocol in itself does not specify how the distributed service
istration and data delivered to the client is supposed to be driving registration and data delivered to the client is supposed to drive
other protocols so e.g. OSPF routers finding themselves through Proxy other protocols. Hence OSPF routers, for instance, that find
PAR could use this information in a Classical IP over ATM [5] fashion, themselves through Proxy-PAR could use this information in a
forming a full mesh of point-to-point connections to interact with each Classical IP and ARP over ATM [5] fashion, forming a full mesh of
other to simulate broadcast interfaces. For the same purpose LANE [6] or point-to-point connections to interact with each other to simulate
MARS [7] could be used. As a by-product, Proxy PAR could provide the ATM broadcast interfaces. For the same purpose, LANE [6] or MARS [7]
address resolution for IP attached devices but such resolution can be could be used. As a byproduct, Proxy-PAR could provide the ATM
achieved by other protocols under specification at the IETF as well, address resolution for IP-attached devices, but such resolution can
e.g. [8]. And last but not least, it should be mentioned here that the be achieved by other protocols under specification at the IETF as
protocol coexists with and complements the ongoing work in IETF on well, e.g. [8]. Last but not least, it should be mentioned here that
server detection via ILMI extensions [9,10,11]. the protocol coexists with and complements the ongoing work in IETF
on server detection via ILMI extensions [9,10,11].
1.1.1 Proxy PAR Scopes 1.1.1 Proxy-PAR Scopes
Any Proxy PAR registration is carried only within a defined scope that Any information registered through Proxy-PAR is flooded only within a
is set during registration and is equivalent to the PNNI routing level. defined scope that is established during registration and is
Since no assumptions except scope values can be made about the informa equivalent to the PNNI routing level. As no assumption can be made
tion distributed (e.g. IP addresses bound to NSAPs are not assumed to be about the information distributed (e.g. IP addresses bound to NSAPs
aligned with them in any respect such as encapsulation or functional are not assumed to be aligned with them in any respect such as
mapping), registration information cannot be summarized. This makes a encapsulation or functional mapping), it cannot be summarized. This
careful handling of scopes necessary to preserve the scalability. More makes a careful handling of scopes necessary to preserve the
details on the usage of scope can be found in [2]. scalability. More details on the usage of scope can be found in [2].
1.2 Introduction to OSPF 1.2 Introduction to OSPF
OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP) OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP)
and described in [12] from which most of the following paragraphs has and described in [12] from which most of the following paragraphs has
been taken almost literally. OSPF distributes routing information been taken almost literally. OSPF distributes routing information
between routers belonging to a single Autonomous System. The OSPF proto between routers belonging to a single Autonomous System. The OSPF
col is based on link-state or SPF technology. It was developed by the protocol is based on link-state or SPF technology. It was developed
OSPF working group of the Internet Engineering Task Force. It has been by the OSPF working group of the Internet Engineering Task Force. It
designed expressly for the TCP/IP internet environment, including has been designed expressly for the TCP/IP internet environment,
explicit support for IP subnetting, and the tagging of externally- including explicit support for IP subnetting, and the tagging of
derived routing information. OSPF also utilizes IP multicast when send externally-derived routing information. OSPF also utilizes IP
ing/receiving the updates. In addition, much work has been done to pro multicast when sending/receiving the updates. In addition, much work
duce a protocol that responds quickly to topology changes, yet involves has been done to produce a protocol that responds quickly to topology
small amounts of routing protocol traffic. changes, yet involves small amounts of routing protocol traffic.
To cope with the needs of NBMA and demand circuits capable networks such To cope with the needs of NBMA and demand-circuit-capable networks
as Frame Relay or X.25, [13] has been made available that standardizes such as Frame Relay or X.25, [13] has been made available. It
extensions to the protocol allowing for efficient operation over on- standardizes extensions to the protocol that allow efficient
demand circuits. operation over on-demand circuits.
OSPF supports three types of networks today: OSPF supports three types of networks today:
Point-to-point networks: A network that joins a single pair of + Point-to-point networks: A network that joins a single pair of
routers. Point- to-point networks can either be numbered or routers. Point-to-point networks can either be numbered or
unnumbered in the latter case the interfaces do not have IP unnumbered. In the latter case the interfaces do not have IP
addresses nor masks. Even when numbered, both sides of the link addresses nor masks. Even when numbered, both sides of the link
do not have to agree on the IP subnet. do not have to agree on the IP subnet.
Broadcast networks: Networks supporting many (more than two) + Broadcast networks: Networks supporting many (more than two)
attached routers, together with the capability to address a sin attached routers, together with the capability of addressing a
gle physical message to all of the attached routers (broadcast). single physical message to all of the attached routers
Neighboring routers are discovered dynamically on these networks (broadcast). Neighboring routers are discovered dynamically on
using the OSPF Hello Protocol. The Hello Protocol itself takes these networks using the OSPF Hello Protocol. The Hello
advantage of the broadcast capability. The protocol makes further Protocol itself takes advantage of the broadcast capability.
use of multicast capabilities, if they exist. An Ethernet is an The protocol makes further use of multicast capabilities, if
example of a broadcast network. they exist. An Ethernet is an example of a broadcast network.
Non-broadcast networks: Networks supporting many (more than two) + Non-broadcast networks: Networks supporting many (more than
attached routers, but having no broadcast capability. Neighboring two) attached routers, but having no broadcast capability.
routers are maintained on these nets using OSPF's Hello Protocol. Neighboring routers are maintained on these nets using OSPF's
However, due to the lack of broadcast capability, some configura Hello Protocol. However, due to the lack of broadcast
tion information is necessary for the correct operation of the capability, some configuration information is necessary for the
Hello Protocol. On these networks, OSPF protocol packets that are correct operation of the Hello Protocol. On these networks,
normally multicast need to be sent to each neighboring router, in OSPF protocol packets that are normally multicast need to be
turn. An X.25 Public Data Network (PDN) is an example of a non- sent to each neighboring router, in turn. An X.25 Public Data
broadcast network. Network (PDN) is an example of a non-broadcast network.
OSPF runs in one of two modes over non-broadcast networks. The OSPF runs in one of two modes over non-broadcast networks. The
first mode, called non-broadcast multi-access (NBMA), simulates first mode, called non-broadcast multi-access (NBMA), simulates
the operation of OSPF on a broadcast network. The second mode, the operation of OSPF on a broadcast network. The second mode,
called Point-to-MultiPoint, treats the non-broadcast network as a called Point-to-MultiPoint, treats the non-broadcast network as
collection of point-to-point links. Non-broadcast networks are a collection of point-to-point links. Non-broadcast networks
referred to as NBMA networks or Point-to-MultiPoint networks, are referred to as NBMA networks or Point-to-MultiPoint
depending on OSPF's mode of operation over the network. networks, depending on OSPF's mode of operation over the
network.
2 OSPF over ATM 2 OSPF over ATM
2.1 Model 2.1 Model
Contrary to broadcast-simulation based solutions such as LANE [6] or Contrary to broadcast-simulation-based solutions such as LANE [6] or
Classical IP over ATM [5], this document elaborates on how to handle Classical IP and ARP over ATM [5], this document elaborates on how to
virtual OSPF interfaces over ATM such as NBMA, point-to-multipoint or handle virtual OSPF interfaces over ATM such as NBMA, Point-to-
point-to-point and allow for their auto-configuration in presence of MultiPoint or point-to-point and allow for their auto-configuration
Proxy PAR. One advantage is the circumvention of server solutions that in the presence of Proxy-PAR. One advantage is the circumvention of
often present single points of failure or hold large amounts of configu server solutions that often present single points of failure or hold
ration information. large amounts of configuration information.
The other main benefit is the possibility to execute OSPF on top of NBMA The other main benefit is the capability of executing OSPF on top of
and point-to-multpoint ATM networks, and still benefit from the auto NBMA and Point-to-MultiPoint ATM networks, and still benefit from the
matic discovery of OSPF neighbors. As opposed to broadcast networks, automatic discovery of OSPF neighbors. As opposed to broadcast
broadcast-simulation based networks (like LANE or Classical IP over networks, broadcast-simulation-based networks (such as LANE or
ATM), and point-to-point networks, where an OSPF router dynamically dis Classical IP and ARP over ATM), and point-to-point networks, where an
covers its neighbors by sending Hello packets to the AllSPFRouters mul OSPF router dynamically discovers its neighbors by sending Hello
ticast address, this is not the case on NBMA and point-to-multipoint packets to the All-SPFRouters multicast address, this is not the case
networks. On NBMA networks, the list of all other attached routers to on NBMA and Point-to-MultiPoint networks. On NBMA networks, the list
the same NBMA network has to be manually configured or discovered by of all other attached routers to the same NBMA network has to be
some other means: Proxy PAR allows to automate this configuration. Also manually configured or discovered by some other means: Proxy-PAR
on point-to-multipoint networks, the set of routers that are directly allows this configuration to be automated. Also on Point-to-
reachable can be either manually configured or dynamically discovered by MultiPoint networks, the set of routers that are directly reachable
Proxy PAR or through mechanisms like Inverse ATMARP. In an ATM network, can either be manually configured or dynamically discovered by
(see 8.2 in [5]) Inverse ATMARP can be used to discover the IP address Proxy-PAR or mechanisms such as Inverse ATMARP. In an ATM network,
of the router at the remote end of a given PVC, whether or not its ATM (see 8.2 in [5]) Inverse ATMARP can be used to discover the IP
address is known. But Inverse ATMARP does not return for instance address of the router at the remote end of a given PVC, whether or
whether the remote router is running OSPF, as opposed to Proxy PAR. not its ATM address is known. But Inverse ATMARP does not return, for
instance, whether the remote router is running OSPF, unlike Proxy-
PAR.
Parallel to [14] that describes the recommended operation of OSPF over Parallel to [14], which describes the recommended operation of OSPF
Frame Relay networks, a similar model is assumed where the underlying over Frame Relay networks, a similar model is assumed where the
ATM network can be used to model single VCs as point-to-point interfaces underlying ATM network can be used to model single VCs as point-to-
or collections of VCs as non-broadcast interfaces, whether in NBMA or point interfaces or collections of VCs as non-broadcast interfaces,
point-to-multipoint mode. Such a VC or collection of VCs is called a whether in NBMA or Point-to-MultiPoint mode. Such a VC or collection
logical interface and specified through its type (either point-to-point, of VCs is called a logical interface and specified through its type
NBMA or point-to-multipoint), VPN ID (the Virtual Private Network to (either point-to-point, NBMA or Point-to-MultiPoint), VPN ID (the
which interface belongs), address and mask. Layer 2 specific configura Virtual Private Network to which the interface belongs), address and
tion such as address resolution method, class and quality of service of mask. Layer 2 specific configurations such as the address resolution
used circuits and other must be also included. As logical consequence method, class and quality of service of circuits used, and others,
thereof, a single, physical interface could encompass multiple IP sub must also be included. As a logical consequence thereof, a single,
nets or even multiple VPNs. In contrary to layer 2 and IP addressing physical interface could encompass multiple IP subnets or even
information, when running Proxy PAR, most of the OSPF information needed multiple VPNs. Contrary to layer 2 and IP addressing information,
to operate such a logical interface does not have to be configured into when running Proxy-PAR, most of the OSPF information needed to
routers statically but can be provided through Proxy PAR queries. This operate such a logical interface does not have to be configured into
allows for much more dynamic configuration of VC meshes in OSPF environ routers statically but can be provided through Proxy-PAR queries.
ments than e.g. in Frame Relay solutions. This allows much more dynamic configuration of VC meshes in OSPF
environments than, for example, Frame Relay solutions do.
Proxy PAR queries can also be issued with a subnet address set to Proxy-PAR queries can also be issued with a subnet address set to
0.0.0.0, instead of a specific subnet address. This type of query 0.0.0.0, instead of a specific subnet address. This type of query
returns information on all OSPF routers available in all subnets, within returns information on all OSPF routers available in all subnets
the scope specified in the query. This can be used for instance when the within the scope specified in the query. This can be used for
IP addressing information has not been configured. instance when the IP addressing information has not been configured.
2.2 Configuration of OSPF interfaces with Proxy PAR 2.2 Configuration of OSPF interfaces with Proxy-PAR
To achieve the goal of simplification of VC mesh reconfiguration, Proxy To achieve the goal of simplification of VC mesh reconfiguration,
PAR allows the router to learn automatically most of the configuration Proxy-PAR allows the router to learn automatically most of the
that has to be provided to OSPF. Non-broadcast and point-to-point inter configuration that has to be provided to OSPF. Non-broadcast and
face information can be learned across an ATM cloud as described in the point-to-point interface information can be learned across an ATM
ongoing sections. It is up to the implementation to possibly allow for a cloud as described in the ongoing sections. It is up to the
mixture of Proxy PAR autoconfiguration and manual configuration of implementation to possibly allow for a mixture of Proxy-PAR
neighbor information. Moreover, manual configuration could e.g. over autoconfiguration and manual configuration of neighbor information.
ride or complement information derived from a Proxy PAR client. Addi Moreover, manual configuration could, for instance, override or
tionally, OSPF extensions to handle on-demand circuits [13] can be used complement information derived from a Proxy-PAR client. In addition,
to allow for graceful tearing down of VCs not carrying any OSPF traffic OSPF extensions to handle on-demand circuits [13] can be used to
over prolonged periods of time. The different interactions are described allow the graceful tearing down of VCs not carrying any OSPF traffic
in sections 2.2.1, 2.2.2 and 2.2.3. over prolonged periods of time. The various interactions are
described in sections 2.2.1, 2.2.2 and 2.2.3.
Even after autoconfiguration of interfaces has been provided, the prob Even after autoconfiguration of interfaces has been provided, the
lem of VC setups in an ATM network is unsolved since none of the nor problem of VC setups in an ATM network is unsolved because none of
mally used mechanisms such as Classical IP [5] or LANE [6] are assumed the normally used mechanisms such as Classical IP and ARP over ATM
to be present. Section 2.5 describes the behavior of OSPF routers neces [5] or LANE [6] are assumed to be present. Section 2.5 describes the
sary to allow for router connectivity. behavior of OSPF routers necessary to allow for router connectivity.
2.2.1 Autoconfiguration of Non-Broadcast Multiple-Access (NMBA) Inter 2.2.1 Autoconfiguration of Non-Broadcast Multiple-Access (NMBA)
faces Interfaces
Proxy PAR allows to autoconfigure the list of all routers residing on Proxy-PAR allows the autoconfiguation of the list of all routers
the same IP network in the same VPN by simply querying the Proxy PAR residing on the same IP network in the same VPN by simply querying
server. Each router can easily obtain the list of all OSPF routers on the Proxy-PAR server. Each router can easily obtain the list of all
the same subnet with their router priorities and corresponding ATM OSPF routers on the same subnet with their router priorities and
addresses. This is the precondition for OSPF to work properly across corresponding ATM addresses. This is the precondition for OSPF to
such logical NBMA interfaces. Note that this memberlist, when learned work properly across such logical NBMA interfaces. Note that this
through Proxy PAR queries, can dynamically change with PNNI (in)stabil member list, when learned through Proxy-PAR queries, can dynamically
ity and general ATM network behavior. It maybe preferable for an imple change with PNNI (in)stability and general ATM network behavior.
mentation to withdraw list membership (de-register itself as an OSPF Relying on an OSPF mechanism to discover a lack of reachability in
router) e.g. much slower than detect new members (done by querying). the overlaying logical IP network could alleviate the risk of
Relying on OSPF mechanism to discover lack of reachability in the over thrashing DR elections and excessive information flooding. Once the
laying logical IP network could alleviate the risk of thrashing DR DR election has been completed and the router has not been elected DR
elections and excessive information flooding. Once the DR registration or BDR, an implementation of [13] can ignore the fact that all
is completed and the router has not been elected DR or BDR, an implemen routers on the specific NBMA subnet are available in its
tation of [13] can ignore the fact that all routers on the specific NBMA configuration because it only needs to maintain VCs to the DR and
subnet are available in its configuration since it only needs to main BDR. Note that this information can serve other purposes, such as the
tain VCs to the DR and BDR. Note that this information can serve other forwarding of data packets (see section 2.4).
purposes, like for the forwarding of data packets (see section 2.4).
Traditionally, router configuration for a NBMA network provides the list Traditionally, router configuration for a NBMA network provides the
of all neighboring routers to allow for proper protocol operation. For list of all neighboring routers to allow for proper protocol
stability purposes, the user may choose to provide a list of neighbors operation. For stability purposes, the user may choose to provide a
through such static means but additionally enable the operation of Proxy list of neighbors through such static means but also enable the
PAR protocol to complete the list. It is left to specific router imple operation of Proxy-PAR protocol to complete the list. It is left up
mentations whether the manual configuration is used in addition to the to specific router implementations to determine whether to use the
information provided by Proxy PAR, used as filter of the dynamic infor manual configuration in addition to the information provided by
mation or whether a concurrent mode of operation is prohibited. In any Proxy-PAR, to use the manual configuration to filter dynamic
case it should be obvious that allowing for more flexibility may facili information, or whether a concurrent mode of operation is prohibited.
tate operation but provides more possibilities for misconfiguration as In any case it should be obvious that allowing for more flexibility
well. may facilitate operation but provides more possibilities for
misconfiguration as well.
2.2.2 Autoconfiguration of Point-to-Multipoint Interfaces 2.2.2 Autoconfiguration of Point-to-MultiPoint Interfaces
Point-to-Multipoint interfaces in ATM networks only make sense if no VCs Point-to-MultiPoint interfaces in ATM networks only make sense if no
can be dynamically set up since an SVC-capable ATM network normally pre VCs can be set up dynamically because an SVC-capable ATM network
sents a NBMA cloud to OSPF. This is e.g. the case if OSPF executes over normally presents a NBMA cloud to OSPF. This is for example the case
a network composed of a partial PVC or SPVC mesh or pre-determined SVC if OSPF executes over a network composed of a partial PVC or SPVC
meshes. Such a network could be modeled using the point-to-multipoint mesh or predetermined SVC meshes. Such a network could be modeled
OSPF interface and the neighbor detection could be provided by Proxy PAR using the Point-to-MultiPoint OSPF interface and the neighbor
or other means. In the Proxy PAR case the router queries for all OSPF detection could be provided by Proxy-PAR or other means. In the
routers on the same network in the same VPN but it installs in the Proxy-PAR case the router queries for all OSPF routers on the same
interface configuration only routers that are already reachable through network in the same VPN but it installs in the interface
existing PVCs. The underlying assumption is that a router knows the configuration only routers that are already reachable through
remote ATM address of a PVC and can compare it with appropriate Proxy existing PVCs. The underlying assumption is that a router knows the
PAR registrations. If the remote ATM address of the PVC is unknown, it remote ATM address of a PVC and can compare it with appropriate
can be discovered by mechanisms like Inverse ARP [15]. Proxy-PAR registrations. If the remote ATM address of the PVC is
unknown, it can be discovered by such mechanisms as Inverse ARP [15].
Proxy PAR provides a true OSPF neighbor detection mechanism, whereas a Proxy-PAR provides a true OSPF neighbor detection mechanism, whereas
mechanism like Inverse ARP only returns addresses of directly reachable a mechanism like Inverse ARP only returns addresses of directly
routers (which are not necessarily running OSPF), in the point-to-multi reachable routers (which are not necessarily running OSPF), in the
point environment. Point-to-Multi-Point environment.
2.2.3 Autoconfiguration of Numbered Point-to-Point Interfaces 2.2.3 Autoconfiguration of Numbered Point-to-Point Interfaces
OSPF point-to-point links do not necessarily have an IP address assigned OSPF point-to-point links do not necessarily have an IP address
and even when having one, the mask is undefined. As a precondition to assigned and even if they do, the mask is undefined. As a
successfully register a service with Proxy PAR, IP address and mask is precondition to successfully register a service with Proxy-PAR, an IP
required. Therefore, if a router desires to use Proxy PAR to advertise address and a mask are required. Therefore, if a router desires to
the local end of a point-to-point link to the router it intends to form use Proxy-PAR to advertise the local end of a point-to-point link to
an adjacency with, an IP address has to be provided and a netmask set or the router with which it intends to form an adjacency, an IP address
a default of 255.255.255.252 (this gives as the default case a subnet has to be provided as well as a netmask set or a default of
with 2 routers on it) assumed. To allow the discovery of the remote end 255.255.255.252 (this gives as the default case a subnet with two
of the interface, IP address of the remote side has to be provided and a routers on it) assumed. To allow the discovery of the remote end of
netmask set or a default of 255.255.255.252 assumed. Obviously the dis the interface, IP address of the remote side has to be provided and a
covery can only be successfull when both sides of the interface are con netmask set or a default of 255.255.255.252 assumed. Obviously the
figured with the same network mask and are within the same IP network. discovery can only be successful when both sides of the interface are
The situation where more than two possible neighbors are discovered configured with the same network mask and are within the same IP
through queries and the interface type is set to point-to-point presents network. The situation where more than two possible neighbors are
a configuration error. discovered through queries and the interface type is set to point-
to-point presents a configuration error.
Sending multicast Hello packets on the point-to-point links allows to Sending multicast Hello packets on the point-to-point links allows
automatically discover OSPF neighbors. On the other hand, using Proxy OSPF neighbors to be discovered automatically. On the other hand,
PAR instead avoids sending Hello messages to routers which are not nec using Proxy-PAR instead avoids sending Hello messages to routers that
essarily running OSPF. are not necessarily running OSPF.
2.2.4 Autoconfiguration of Unnumbered Point-to-Point Interfaces 2.2.4 Autoconfiguration of Unnumbered Point-to-Point Interfaces
For reasons given already in [14] using unnumbered point-to-point inter For reasons given in [14], the use of unnumbered point-to-point
faces with Proxy PAR is not a very attractive alternative since the lack interfaces with Proxy-PAR is not a very attractive alternative
of an IP address prevents efficient registration and retrieval of con because the lack of an IP address prevents efficient registration and
figuration information. Relying on the numbering method based on MIB retrieval of configuration information. Relying on the numbering
entries generates conflicts with the dynamic nature of creation of such method based on MIB entries generates conflicts with the dynamic
entries and is beyond the scope of this work. nature of creation of such entries and is beyond the scope of this
work.
2.3 Registration of OSPF interfaces with Proxy PAR 2.3 Registration of OSPF interfaces with Proxy-PAR
To allow other routers to discover an OSPF interface automatically, the To allow other routers to discover an OSPF interface automatically,
IP address, mask, Area ID, interface type and router priority informa the IP address, mask, Area ID, interface type and router priority
tion given must be registered with the Proxy PAR server at an appropri information given must be registered with the Proxy-PAR server at an
ate scope. A change in any of these parameters has to force a reregis appropriate scope. A change in any of these parameters has to force a
tration with Proxy PAR. reregistration with Proxy-PAR.
It should be emphasized here that since the registration information can It should be emphasized here that because the registration
be used by other routers to resolve IP addresses against NSAPs as information can be used by other routers to resolve IP addresses
explained in section 2.4, whole IP address of the router must be regis against NSAPs as explained in section 2.4, the entire IP address of
tered. It is not enough to just indicate the subnet up to the mask the router must be registered. It is not sufficient to indicate the
length but all address bits must be provided. subnet up to the mask length; all address bits must be provided.
2.3.1 Registration of Non-Broadcast Multiple-Access Interfaces 2.3.1 Registration of Non-Broadcast Multiple-Access Interfaces
For an NBMA interface the appropriate parameters are available and can For an NBMA interface the appropriate parameters are available and
be registered through Proxy PAR without further complications. can be registered through Proxy-PAR without further complications.
2.3.2 Registration of Point-to-Multipoint Interfaces 2.3.2 Registration of Point-to-Multipoint Interfaces
In case of a point-to-multipoint interface the router registers its In the case of a Point-to-MultiPoint interface the router registers
information in the same fashion as in the NBMA case except that the its information in the same fashion as in the NBMA case, except that
interface type is modified accordingly. the interface type is modified accordingly.
2.3.3 Registration of Numbered Point-to-Point Interfaces 2.3.3 Registration of Numbered Point-to-Point Interfaces
In case of point-to-point numbered interfaces the address mask is not In the case of point-to-point numbered interfaces the address mask is
specified in the OSPF configuration. If the router has to use Proxy PAR not specified in the OSPF configuration. If the router has to use
to advertise its capability, a mask must be defined or a default value Proxy-PAR to advertise its capability, a mask must be defined or a
of 255.255.255.252 used. default value of 255.255.255.252 used.
2.3.4 Registration of Unnumbered Point-to-Point Interfaces 2.3.4 Registration of Unnumbered Point-to-Point Interfaces
Due to the lack of a configured IP address and difficulties generated by Owing to the lack of a configured IP address and difficulties
this fact as described earlier, registration of unnumbered point-to- generated by this fact as described earlier, registration of
point interfaces is not covered in this document. unnumbered point-to-point interfaces is not covered in this document.
2.4 IP address to NSAP Resolution Using Proxy PAR 2.4 IP address to NSAP Resolution Using Proxy-PAR
As a byproduct of Proxy PAR presence, an OSPF implementation could use As a byproduct of Proxy-PAR presence, an OSPF implementation could
the information in registrations for the resolution of IP addresses to use the information in registrations for the resolution of IP
ATM NSAPs on a subnet without having to use static data or mechanisms addresses to ATM NSAPs on a subnet without having to use static data
such as ATMARP [5]. This again should allow for drastic simplification or mechanisms such as ATMARP [5]. This again should allow a drastic
of number of mechanisms involved in operation of OSPF over ATM to pro simplification of the number of mechanisms involved in operating OSPF
vide an IP overlay. over ATM to provide an IP overlay.
In a system perspective, the OSPF component, the Proxy PAR client, the From a system perspective, the OSPF component, the Proxy-PAR client,
IP to NSAP address resolution table, and the ATM circuit manager can be the IP to NSAP address resolution table, and the ATM circuit manager
depicted as in Figure 1. Figure 1 shows an example of components inter can be depicted as in Figure 1. Figure 1 shows an example of
actions triggered by the result of a Proxy PAR query from the Proxy PAR component interactions triggered by a Proxy-PAR query from the
client. Proxy-PAR client.
2.5 Connection Setup Mechanisms 2.5 Connection Setup Mechanisms
This sections describes OSPF behavior in an ATM network under different This section describes the OSPF behavior in an ATM network under
assumptions in terms of signaling capabilities and preset connectivity. various assumptions in terms of signaling capabilities and preset
connectivity.
2.5.1 OSPF in PVC Environments 2.5.1 OSPF in PVC Environments
In environments where only partial PVCs (or SPVCs) meshes are available In environments where only partial PVCs (or SPVCs) meshes are
and modeled as point-to-multipoint interfaces, the routers see reachable available and modeled as Point-to-MultiPoint interfaces, the routers
routers through autodiscovery provided by Proxy PAR. This leads to see reachable routers through autodiscovery provided by Proxy-PAR.
expected OSPF behavior. In cases where a full mesh of PVCs is present, This leads to expected OSPF behavior. In cases where a full mesh of
such a network should preferably be modeled as NBMA. Note that in such a PVCs is present, such a network should preferably be modeled as NBMA.
case, PVCs failures will translate into not so obvious routing failures. Note that in such a case, PVCs failures will translate into not-so-
obvious routing failures.
2.5.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
__________ _________ __________ _________
| | | | | | | |
| OSPF |<-------------------|Proxy PAR|<---(Proxy PAR query) | OSPF |<-------------------|Proxy-PAR|<---(Proxy-PAR query)
|__________| notify | client | |__________| notify | client |
^ neighbor changes |_________| ^ neighbor changes |_________|
| | | |
send and | | maintain Proxy PAR send and | | maintain Proxy-PAR
receive | | entries in table receive | | entries in table
OSPF msg | | OSPF msg | |
| | | |
| | | |
____V____ ____V_____ ____V____ ____V_____
| ATM | | | | ATM | | |
| circuit |-------------------->|IP to NSAP| | circuit |-------------------->|IP to NSAP|
| manager | check | table | | manager | check | table |
|_________| IP to NSAP bindings |__________| |_________| IP to NSAP bindings |__________|
Figure 1: System perspective of typical components interactions Figure 1: System perspective of typical components interactions.
2.5.2 OSPF in SVC Environments
+ + + + + +
| +---+ | | | +---+ | |
+--+ |---|RTA|---| +-------+ | +--+ +--+ |---|RTA|---| +-------+ | +--+
|H1|---| +---+ | | ATM | |---|H2| |H1|---| +---+ | | ATM | |---|H2|
+--+ | | +---+ | Cloud | +---+ | +--+ +--+ | | +---+ | Cloud | +---+ | +--+
|LAN Y |---|RTB|-------------|RTC|---| |LAN Y |---|RTB|-------------|RTC|---|
+ | +---+ | PPAR | +---+ | + | +---+ | PPAR | +---+ |
+ +-------+ + + +-------+ +
Figure 2: Simple Topology with Router B and Router C operating Figure 2: Simple topology with Router B and Router C operating
across NBMA ATM interfaces with Proxy PAR across NBMA ATM interfaces with Proxy-PAR.
send data such as Hello-packets. This can lead to race conditions where In SVC-capable environments the routers can initiate VCs after having
both sides can open a VC simultaneously. It is generally desirable to discovered the appropriate neighbors, preferably driven by the need
avoid wasting this valuable resource: if the router with lower Router ID to send data such as Hello packets. This can lead to race conditions
detects that the VC initiated by the other side is bidirectional, it is where both sides can open a VC simultaneously. It is generally
free to close its own VC and use the detected one. Note that this either desirable to avoid wasting this valuable resource: if the router with
requires the OSPF implementation to be aware of the VCs used to send and lower IP address (i.e., the IP address of the OSPF interface
receive Hello messages, or the component responsible of managing VCs to registered with Proxy-PAR) detects that the VC initiated by the other
be aware of the usage of particular VCs. side is bidirectional, it is free to close its own VC and use the
detected one. Note that this either requires the OSPF implementation
to be aware of the VCs used to send and receive Hello messages, or
the component responsible of managing VCs to be aware of the usage of
particular VCs.
Observe that this behavior operates correctly in case OSPF over Demand Observe that this behavior operates correctly in case OSPF over
Circuits extensions are used [13] over SVC capable interfaces. Demand Circuits extensions are used [13] over SVC capable interfaces.
It is possible to avoid most of the time the set-up of redundant VCs by Most of the time, it is possible to avoid the setup of redundant VCs
delaying the sending of the first OSPF Hello from the router with the by delaying the sending of the first OSPF Hello from the router with
lower Router ID, by an amount of time larger than the interval between the lower IP address by an amout of time greater than the interval
the queries from the Proxy PAR client to the server. Chances are that between the queries from the Proxy-PAR client to the server. Chances
the router with the higher Router ID opens the VC (or use an already are that the router with the higher IP address opens the VC (or use
existing VC) and sends the OSPF Hello first, if its interval between an already existing VC) and sends the OSPF Hello first if its
queries is smaller than the Hello delay of the router with the lower interval between queries is shorter than the Hello delay of the
Router ID. Since this interval can vary depending on particular needs router with the lower IP address. As this interval can vary depending
and implementations, the race conditions described above can still be on particular needs and implementations, the race conditions
expected to happen, albeit presumably less often. described above can still be expected to happen, albeit presumably
less often.
The existence of VCs used for OSPF exchanges is orthogonal to the number The existence of VCs used for OSPF exchanges is orthogonal to the
and type of VCs the router chooses to use within the logical interface number and type of VCs the router chooses to use within the logical
to forward data to other routers. OSPF implementations are free to use interface to forward data to other routers. OSPF implementations are
any of these VCs (in case they are aware of their existence) to send free to use any of these VCs (in case they are aware of their
packets if their endpoints are adequate and must accept hello packets existence) to send packets if their end points are adequate and must
arriving on any of the VCs belonging to the logical interface even if accept Hello packets arriving on any of the VCs belonging to the
OSPF operating on such an interface is not aware of their existence. An logical interface even if OSPF operating on such an interface is not
OSPF implementation may ignore connections being initiated by another aware of their existence. An OSPF implementation may ignore
router that has not been discovered by Proxy PAR. The OSPF implementa connections being initiated by another router that has not been
tion will anyway ignore a neighbor whose Proxy PAR registration indi discovered by Proxy-PAR. In any case, the OSPF implementation will
cates that it is not adjacent. ignore a neighbor whose Proxy-PAR registration indicates that it is
not adjacent.
As an example consider the topology in Figure 2 where router RTB and RTC As an example consider the topology in Figure 2 where router RTB and
are connected to a common ATM cloud offering Proxy PAR services. Assum RTC are connected to a common ATM cloud offering Proxy-PAR services.
ing that RTB's OSPF implementation is aware of SVCs initiated on the Assuming that RTB's OSPF implementation is aware of SVCs initiated on
interface and RTC only makes minimal use of Proxy PAR information the the interface and that RTC only makes minimal use of Proxy-PAR
following sequence could develop illustrating some of the cases information, the following sequence could develop, illustrating some
described above: of the cases described above:
1. RTC and RTB register with ATM cloud as Proxy PAR capable and 1. RTC and RTB register with ATM cloud as Proxy-PAR capable and
discover each other as adjacent OSPF routers. discover each other as adjacent OSPF routers.
2. RTB sends a hello which forces it to establish a SVC connec 2. RTB sends a Hello, which forces it to establish a SVC
tion to RTC. connection to RTC.
3. RTC sends a hello to RTB but disregards the already existing 3. RTC sends a Hello to RTB, but disregards the already existing
VC and establishes a new VC to RTB to deliver the packet. VC and establishes a new VC to RTB to deliver the packet.
4. RTB sees a new bi-directional VC and assuming here that RTC's 4. RTB sees a new bidirectional VC and, assuming here that RTC's
OSPF Id is higher, closes the VC originated in step 2. IP address is higher, closes the VC originated in step 2.
5. Host H1 sends data to H2 and RTB establishes a new data SVC 5. Host H1 sends data to H2 and RTB establishes a new data SVC
between itself and RTC. between itself and RTC.
6. RTB sends a Hello to RTC and decides to do it using the newly 6. RTB sends a Hello to RTC and decides to do so using the newly
establish data SVC. RTC must accept the hello despite the min establish data SVC. RTC must accept the Hello despite the
imal implementation. minimal implementation.
3 Acknowledgments 3 Acknowledgments
Comments and contributions from several sources, especially Rob Coltun, Comments and contributions from several sources, especially Rob
Doug Dykeman, John Moy and Alex Zinin are included in this work. Coltun, Doug Dykeman, John Moy and Alex Zinin are included in this
work.
4 Security Consideration 4 Security Considerations
Several aspects are to be considered when talking about security of Several aspects are to be considered in the context of the security
operating OSPF over ATM and/or Proxy PAR. The security of registered of operating OSPF over ATM and/or Proxy-PAR. The security of
information handed to the ATM cloud must be guaranteed by the underlying registered information handed to the ATM cloud must be guaranteed by
PNNI protocol. Extensions to PNNI are available and given their imple the underlying PNNI protocol. The registration itself through Proxy-
mentation spoofing of registrations and/or denial-of-service issues can PAR is not secured, and are thus appropriate mechanisms for further
be addressed [16]. The registration itself through proxy PAR is not study. However, even if the security at the ATM layer is not
secured and appropriate mechanisms are for further study. However, even guaranteed, OSPF security mechanisms can be used to verify that
if the security at the ATM layer is not guaranteed, OSPF security mecha detected neighbors are authorized to interact with the entity
nisms can be used to verify that detected neighbors are authorized to discovering them.
interact with the entity discovering them.
5 Bibliography 5 Bibliography
[1] P. Droz, "PNNI Augmented Routing (PAR) Version 1.0." ATM Forum af- [1] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0." ATM
ra-0104.000, January 1999. Forum af-ra-0104.000, January 1999.
[2] T. P. P. Droz, "Proxy PAR." Internet Draft draft-ietf-ion-proxypar-
arch-01, February 1999.
[3] ATM-Forum, "Private Network-Network Interface Specification Version [2] Droz, P. and T. Przygienda, "Proxy-PAR", RFC 2843, May 2000.
1.0." ATM Forum af-pnni-0055.000, March 1996.
[4] ATM-Forum, "Interim Local Management Interface (ILMI) Specification [3] ATM-Forum, "Private Network-Network Interface Specification
4.0." ATM Forum 95-0417R8, June 1996. Version 1.0." ATM Forum af-pnni-0055.000, March 1996.
[5] J. H. M. Laubach, "Classical IP and ARP over ATM, RFC 2225." Inter [4] ATM-Forum, "Interim Local Management Interface, (ILMI)
net Engineering Task Force, April 1998. Specification 4.0." ATM Forum af-ilmi-0065.000, September 1996.
[6] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-0021.000, [5] Laubach, J., "Classical IP and ARP over ATM", RFC 2225, April
January 1995. 1998.
[7] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM net [6] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-
works, RFC 2022." Internet Engineering Task Force, November 1996. 0021.000, January 1995.
[8] R. Coltun, "The OSPF Opaque LSA Option, RFC 2370." Internet Engi [7] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
neering Task Force, July 1998. Networks", RFC 2022, November 1996.
[9] M. Davison, "ILMI-Based Server Discovery for ATMARP, RFC 2601." [8] Coltun, R., "The OSPF Opaque LSA Option", RFC 2328, July 1998.
Internet Engineering Task Force, June 1999.
[10] M. Davison, "ILMI-Based Server Discovery for MARS, RFC 2602." [9] Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601,
Internet Engineering Task Force, June 1999. June 1999.
[11] M. Davison, "ILMI-Based Server Discovery for NHRP, RFC 2603." [10] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602,
Internet Engineering Task Force, June 1999. June 1999.
[12] J. Moy, "OSPF Version 2 - RFC 2328." Internet Engineering Task [11] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603,
Force, April 1998. June 1999.
[13] J. Moy, "Extending OSPF to Support Demand Circuits, RFC 1793." [12] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
Internet Engineering Task Force, April 1995.
[14] O. deSouza and M. Rodrigues, "Guidelines for Running OSPF Over [13] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
Frame Relay Networks, RFC 1586." Internet Engineering Task Force, March April 1995.
1994.
[15] A. M. T. Bradley, C. Brown, "Inverse Address Resolution Protocol, [14] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over
RFC 2390." Internet Engineering Task Force, September 1999. Frame Relay Networks", RFC 1586, March 1994.
[16] T. Przygienda and C. Bullard, "Baseline Text for PNNI Peer Authen [15] Bradley, A. and C. Brown, "Inverse Address Resolution Protocol",
tication and Cryptographic Data Integrity." ATM Forum 97-0472, July RFC 2390, September 1999.
1997.
Authors' Addresses Authors' Addresses
Tony Przygienda Tony Przygienda
Siara Systems Siara Systems Incorporated
300 Ferguson Drive 1195 Borregas Avenue
Mountain View Sunnyvale, CA 94089
California 94043 USA
prz@siara.com
Patrick Droz EMail: prz@siara.com
IBM Research Division
Saumerstrasse 4 Patrick Droz
8803 Ruschlikon IBM Research
Switzerland Zurich Research Laboratory
dro@zurich.ibm.com Saumerstrasse 4
Robert Haas 8803 Ruschlikon
IBM Research Division Switzerland
Saumerstrasse 4
8803 Ruschlikon EMail: dro@zurich.ibm.com
Switzerland
rha@zurich.ibm.com Robert Haas
IBM Research
Zurich Research Laboratory
Saumerstrasse 4
8803 Ruschlikon
Switzerland
EMail: rha@zurich.ibm.com
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 85 change blocks. 
409 lines changed or deleted 415 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/