draft-ietf-ospf-atm-02.txt   draft-ietf-ospf-atm-03.txt 
Internet Engineering Task Force T. Przygienda/P. Droz/R. Internet Engineering Task Force OSPF WG
Haas Internet Draft T. Przygienda/P. Droz/R. Haas
INTERNET DRAFT Bell draft-ietf-ospf-atm-03.txt Siara / IBM / IBM
Labs/IBM August 24, 1999
15 June Expires: February 24, 2000
1999
OSPF over ATM and Proxy PAR OSPF over ATM and Proxy PAR
<draft-ietf-ospf-atm-02.txt>
Status of This Memo Status of this memo
This document is an Internet Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet Drafts are working all provisions of Section 10 of RFC2026.
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 Internet-Drafts are working documents of the Internet Engineering Task
months. Internet Drafts may be updated, replaced, or obsoleted by Force (IETF), its areas, and its working groups. Note that other groups
other documents at any time. It is not appropriate to use Internet may also distribute working documents as Internet-Drafts.
Drafts as reference material, or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
Abstract Abstract
This draft specifes for OSPF implementors and users mechanisms This draft specifes for OSPF implementors and users mechanisms describ¡
describing how the protocol operates in ATM networks over PVC and ing how the protocol operates in ATM networks over PVC and SVC meshes
SVC meshes with the presence of Proxy PAR. These recommendations with the presence of Proxy PAR. These recommendations do not require any
do not require any protocol changes and allow for simpler, more protocol changes and allow for simpler, more efficient and cost-effec¡
efficient and cost-effective network designs. It is recommended that tive network designs. It is recommended that OSPF implementations should
OSPF implementations should be able to support logical interfaces, be able to support logical interfaces, each consisting of one or more
each consisting of one or more virtual circuits and used either virtual circuits and used either as numbered logical point-to-point
as numbered logical point-to-point links (one VC), logical NBMA links (one VC), logical NBMA networks (more than one VC) or point-to-
networks (more than one VC) or point-to-multipoint networks (more multipoint networks (more than one VC), where a solution simulating
than one VC), where a solution simulating broadcast interfaces is broadcast interfaces is not appropriate. PAR can help to distribute
not appropriate. PAR can help to distribute across the ATM cloud across the ATM cloud configuration set-up and changes of such interfaces
configuration set-up and changes of such interfaces when OSPF capable when OSPF capable routers are (re-)configured. Proxy-PAR can in turn be
routers are (re-)configured. Proxy-PAR can in turn be used to used to exchange this information between the ATM cloud and the routers
exchange this information between the ATM cloud and the routers
connected to it. connected to it.
Internet Draft OSPF over ATM and Proxy PAR 15 June 1 Introduction
1999
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 [Dro99 ]. A more complete overview of Proxy PAR than in January 1999 [1]. A more complete overview of Proxy PAR than in the
the section below is given in [PD99 ].
1.1. Introduction to Proxy PAR
Proxy PAR [Dro99 ] is an extension allowing for different ATM section below is given in [2].
attached devices (like routers) to interact with PAR capable switches
and query information about non-ATM services without executing
PAR themselves. The Proxy PAR client side in the ATM attached
device is much simpler in terms of implementation complexity and
memory requirements than a complete PAR protocol stack (which
includes the full PNNI [AF96b ] protocol stack) and should allow
easy implementation in e.g. existing IP routers. Additionnaly,
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 [AF96a ] 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 protocol in itself does not specify how the distributed service 1.1 Introduction to Proxy PAR
registration and data delivered to the client is supposed to be
driving other protocols so e.g. OSPF routers finding themselves
through Proxy PAR could use this information in a Classical IP over
ATM [ML98 ] 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. 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 at the IETF as well, e.g. [Col98 ].
And 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 [Dav99a , Dav99b , Dav99c ].
1.1.1. Proxy PAR Scopes Proxy PAR [1] is an extension allowing for different ATM attached
devices (like routers) to interact with PAR capable switches and query
information about non-ATM services without executing PAR themselves. The
Proxy PAR client side in the ATM attached device is much simpler in
terms of implementation complexity and memory requirements than a com¡
plete PAR protocol stack (which includes the full PNNI [3] protocol
stack) and should allow easy implementation in e.g. existing IP routers.
Additionnaly, 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 [4] 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.
Any Proxy PAR registration is carried only within a defined scope The protocol in itself does not specify how the distributed service reg¡
that is set during registration and is equivalent to the PNNI routing istration and data delivered to the client is supposed to be driving
level. Since no assumptions except scope values can be made about other protocols so e.g. OSPF routers finding themselves through Proxy
the information distributed (e.g. IP addresses bound to NSAPs PAR could use this information in a Classical IP over ATM [5] fashion,
forming a full mesh of point-to-point connections to interact with each
other to simulate broadcast interfaces. For the same purpose LANE [6] or
MARS [7] could be used. 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 at the IETF as well,
e.g. [8]. And 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 [9,10,11].
Przygienda, Droz, Haas Expires 15 December 1999 [Page 1.1.1 Proxy PAR Scopes
2]
Internet Draft OSPF over ATM and Proxy PAR 15 June Any Proxy PAR registration is carried only within a defined scope that
1999 is set during registration and is equivalent to the PNNI routing level.
Since no assumptions except scope values can be made about the informa¡
tion 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. More
details on the usage of scope can be found in [2].
are not assumed to be aligned with them in any respect such as 1.2 Introduction to OSPF
encapsulation or functional mapping), registration information cannot
be summarized. This makes a careful handling of scopes necessary to
preserve the scalability. More details on the usage of scope can be
found in [PD99 ].
1.2. Introduction to OSPF OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP)
and described in [12] from which most of the following paragraphs has
been taken almost literally. OSPF distributes routing information
OSPF (Open Shortest Path First) is an Interior Gateway Protocol between routers belonging to a single Autonomous System. The OSPF proto¡
(IGP) and described in [Moy98 ] from which most of the following col is based on link-state or SPF technology. It was developed by the
paragraphs has been taken almost literally. OSPF distributes routing OSPF working group of the Internet Engineering Task Force. It has been
information between routers belonging to a single Autonomous System. designed expressly for the TCP/IP internet environment, including
The OSPF protocol is based on link-state or SPF technology. It was explicit support for IP subnetting, and the tagging of externally-
developed by the OSPF working group of the Internet Engineering derived routing information. OSPF also utilizes IP multicast when send¡
Task Force. It has been designed expressly for the TCP/IP internet ing/receiving the updates. In addition, much work has been done to pro¡
environment, including explicit support for IP subnetting, and duce a protocol that responds quickly to topology changes, yet involves
the tagging of externally-derived routing information. OSPF also small amounts of routing protocol traffic.
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 To cope with the needs of NBMA and demand circuits capable networks such
such as Frame Relay or X.25, [Moy95 ] has been made available that as Frame Relay or X.25, [13] has been made available that standardizes
standardizes extensions to the protocol allowing for efficient extensions to the protocol allowing for efficient operation over on-
operation over on-demand circuits. 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 ¸ Point-to-point networks: A network that joins a single pair of
of routers. Point- to-point networks can either be numbered routers. Point- to-point networks can either be numbered or
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 attached routers, together with the capability to address a sin¡
a single physical message to all of the attached routers gle physical message to all of the attached routers (broadcast).
(broadcast). Neighboring routers are discovered dynamically on Neighboring routers are discovered dynamically on these networks
these networks using the OSPF Hello Protocol. The Hello Protocol using the OSPF Hello Protocol. The Hello Protocol itself takes
itself takes advantage of the broadcast capability. The protocol advantage of the broadcast capability. The protocol makes further
makes further use of multicast capabilities, if they exist. An use of multicast capabilities, if they exist. An Ethernet is an
Ethernet is an example of a broadcast network. example of a broadcast network.
Przygienda, Droz, Haas Expires 15 December 1999 [Page
3]
Internet Draft OSPF over ATM and Proxy PAR 15 June
1999
- Non-broadcast networks: Networks supporting many (more than ¸ Non-broadcast networks: Networks supporting many (more than two)
two) attached routers, but having no broadcast capability. attached routers, but having no broadcast capability. Neighboring
Neighboring routers are maintained on these nets using routers are maintained on these nets using OSPF's Hello Protocol.
OSPF's Hello Protocol. However, due to the lack of broadcast However, due to the lack of broadcast capability, some configura¡
capability, some configuration information is necessary for the tion information is necessary for the correct operation of the
correct operation of the Hello Protocol. On these networks, OSPF Hello Protocol. On these networks, OSPF protocol packets that are
protocol packets that are normally multicast need to be sent to normally multicast need to be sent to each neighboring router, in
each neighboring router, in turn. An X.25 Public Data Network turn. An X.25 Public Data Network (PDN) is an example of a non-
(PDN) is an example of a non-broadcast network. 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 a
collection of point-to-point links. Non-broadcast networks are collection of point-to-point links. Non-broadcast networks are
referred to as NBMA networks or Point-to-MultiPoint networks, referred to as NBMA networks or Point-to-MultiPoint networks,
depending on OSPF's mode of operation over the network. 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 Contrary to broadcast-simulation based solutions such as LANE [6] or
[AF95 ] or Classical IP over ATM [ML98 ], this document elaborates Classical IP over ATM [5], this document elaborates on how to handle
on how to handle virtual OSPF interfaces over ATM such as virtual OSPF interfaces over ATM such as NBMA, point-to-multipoint or
NBMA, point-to-multipoint or point-to-point and allow for their point-to-point and allow for their auto-configuration in presence of
auto-configuration in presence of Proxy PAR. One advantage is the Proxy PAR. One advantage is the circumvention of server solutions that
circumvention of server solutions that often present single points of often present single points of failure or hold large amounts of configu¡
failure or hold large amounts of configuration information. ration information.
The other main benefit is the possibility to execute OSPF on top The other main benefit is the possibility to execute OSPF on top of NBMA
of NBMA and point-to-multpoint ATM networks, and still benefit from and point-to-multpoint ATM networks, and still benefit from the auto¡
the automatic discovery of OSPF neighbors. As opposed to broadcast matic discovery of OSPF neighbors. As opposed to broadcast networks,
networks, broadcast-simulation based networks (like LANE or Classical IP broadcast-simulation based networks (like LANE or Classical IP over
over ATM), and point-to-point networks, where an OSPF router dynamically ATM), and point-to-point networks, where an OSPF router dynamically dis¡
discovers its neighbors by sending Hello packets to the AllSPFRouters covers its neighbors by sending Hello packets to the AllSPFRouters mul¡
multicast address, this is not the case on NBMA and point-to-multipoint ticast address, this is not the case on NBMA and point-to-multipoint
networks. On NBMA networks, the list of all other attached routers to networks. On NBMA networks, the list of all other attached routers to
the same NBMA network has to be manually configured or discovered by the same NBMA network has to be manually configured or discovered by
some other means: Proxy PAR allows to automate this configuration. some other means: Proxy PAR allows to automate this configuration. Also
Also on point-to-multipoint networks, the set of routers that are on point-to-multipoint networks, the set of routers that are directly
directly reachable must be configured: it can be dynamically discovered reachable can be either manually configured or dynamically discovered by
by Proxy PAR or through mechanisms like Inverse ATMARP. In an ATM Proxy PAR or through mechanisms like Inverse ATMARP. In an ATM network,
network, (see 8.2 in [ML98 ]) Inverse ATMARP can be used to discover the (see 8.2 in [5]) Inverse ATMARP can be used to discover the IP address
of the router at the remote end of a given PVC, whether or not its ATM
Przygienda, Droz, Haas Expires 15 December 1999 [Page address is known. But Inverse ATMARP does not return for instance
4] whether the remote router is running OSPF, as opposed to Proxy PAR.
Internet Draft OSPF over ATM and Proxy PAR 15 June
1999
IP address of the router at the remote end of a given PVC, whether or Parallel to [14] that describes the recommended operation of OSPF over
not its ATM address is known. But Inverse ATMARP does not return for Frame Relay networks, a similar model is assumed where the underlying
instance whether the remote router is running OSPF, as opposed to Proxy ATM network can be used to model single VCs as point-to-point interfaces
PAR. or collections of VCs as non-broadcast interfaces, whether 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-multipoint), VPN ID (the Virtual Private Network to
which interface belongs), address and mask. Layer 2 specific configura¡
tion 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 sub¡
nets or even multiple VPNs. In contrary to layer 2 and IP addressing
Parallel to [dR94 ] that describes the recommended operation of information, when running Proxy PAR, most of the OSPF information needed
OSPF over Frame Relay networks, a similar model is assumed where to operate such a logical interface does not have to be configured into
the underlying ATM network can be used to model single VCs as routers statically but can be provided through Proxy PAR queries. This
point-to-point interfaces or collections of VCs as non-broadcast allows for much more dynamic configuration of VC meshes in OSPF environ¡
interfaces, whether in NBMA or point-to-multipoint mode. Such ments than e.g. in Frame Relay solutions.
a VC or collection of VCs is called a logical interface and
specified through its type (either point-to-point, NBMA or
point-to-multipoint), VPN ID (the Virtual Private Network to which
interface belongs), 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 VPNs. In contrary to layer 2
and IP addressing information, when running Proxy PAR, most of the
OSPF information needed to operate such a logical interface 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.
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, within
the scope specified in the query. This can be used for instance when the scope specified in the query. This can be used for instance when the
the IP addressing information has not been configured. IP addressing information has not been configured.
2.2. Configuration of OSPF interfaces 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
Przygienda, Droz, Haas Expires 15 December 1999 [Page
5]
Internet Draft OSPF over ATM and Proxy PAR 15 June 2.2 Configuration of OSPF interfaces with Proxy PAR
1999
prolonged periods of time. The different interactions are described 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 inter¡
face 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. over¡
ride or complement information derived from a Proxy PAR client. Addi¡
tionally, OSPF extensions to handle on-demand circuits [13] can be used
to allow for graceful tearing down of VCs not carrying any OSPF traffic
over prolonged periods of time. The different interactions are described
in sections 2.2.1, 2.2.2 and 2.2.3. in sections 2.2.1, 2.2.2 and 2.2.3.
Even after autoconfiguration of interfaces has been provided, the Even after autoconfiguration of interfaces has been provided, the prob¡
problem of VC setups in an ATM network is unsolved since none of the lem of VC setups in an ATM network is unsolved since none of the nor¡
normally used mechanisms such as Classical IP [ML98 ] or LANE [AF95 ] mally used mechanisms such as Classical IP [5] or LANE [6] are assumed
are assumed to be present. Section 2.5 describes the behavior of to be present. Section 2.5 describes the behavior of OSPF routers neces¡
OSPF routers necessary to allow for router connectivity. sary to allow for router connectivity.
2.2.1. Autoconfiguration of Non-Broadcast Multiple-Access (NMBA) 2.2.1 Autoconfiguration of Non-Broadcast Multiple-Access (NMBA) Inter¡
Interfaces faces
Proxy PAR allows to autoconfigure the list of all routers residing on Proxy PAR allows to autoconfigure the list of all routers residing on
the same IP network in the same VPN by simply querying the Proxy PAR the same IP network in the same VPN by simply querying the Proxy PAR
server. Each router can easily obtain the list of all OSPF routers server. Each router can easily obtain the list of all OSPF routers on
on the same subnet with their router priorities and corresponding the same subnet with their router priorities and corresponding ATM
ATM addresses. This is the precondition for OSPF to work properly addresses. This is the precondition for OSPF to work properly across
across such logical NBMA interfaces. Note that this memberlist, when such logical NBMA interfaces. Note that this memberlist, when learned
learned through Proxy PAR queries, can dynamically change with PNNI through Proxy PAR queries, can dynamically change with PNNI (in)stabil¡
(in)stability and general ATM network behavior. It maybe preferable ity and general ATM network behavior. It maybe preferable for an imple¡
for an implementation to withdraw list membership (de-register mentation to withdraw list membership (de-register itself as an OSPF
itself as an OSPF router) e.g. much slower than detect new members router) e.g. much slower than detect new members (done by querying).
(done by querying). Relying on OSPF mechanism to discover lack of Relying on OSPF mechanism to discover lack of reachability in the over¡
reachability in the overlaying logical IP network could alleviate the laying logical IP network could alleviate the risk of thrashing DR
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 ] 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.
Traditionally, router configuration for a NBMA network provides elections and excessive information flooding. Once the DR registration
the list of all neighboring routers to allow for proper protocol is completed and the router has not been elected DR or BDR, an implemen¡
operation. For stability purposes, the user may choose to provide a tation of [13] can ignore the fact that all routers on the specific NBMA
list of neighbors through such static means but additionally enable subnet are available in its configuration since it only needs to main¡
the operation of Proxy PAR protocol to complete the list. It is left tain VCs to the DR and BDR. Note that this information can serve other
to specific router implementations whether the manual configuration purposes, like for the forwarding of data packets (see section 2.4).
is used in addition to the information provided by Proxy PAR, used
as filter of the dynamic information or whether a concurrent mode
of operation is prohibited. In any case it should be obvious that
allowing for more flexibility may facilitate operation but provides
more possibilities for misconfiguration as well.
Przygienda, Droz, Haas Expires 15 December 1999 [Page
6]
Internet Draft OSPF over ATM and Proxy PAR 15 June Traditionally, router configuration for a NBMA network provides the list
1999 of all neighboring routers to allow for proper protocol operation. For
stability purposes, the user may choose to provide a list of neighbors
through such static means but additionally enable the operation of Proxy
PAR protocol to complete the list. It is left to specific router imple¡
mentations whether the manual configuration is used in addition to the
information provided by Proxy PAR, used as filter of the dynamic infor¡
mation or whether a concurrent mode of operation is prohibited. In any
case it should be obvious that allowing for more flexibility may facili¡
tate 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 Point-to-Multipoint interfaces in ATM networks only make sense if no VCs
no VCs can be dynamically set up since an SVC-capable ATM network can be dynamically set up since an SVC-capable ATM network normally pre¡
normally presents a NBMA cloud to OSPF. This is e.g. the case if sents a NBMA cloud to OSPF. This is e.g. the case if OSPF executes over
OSPF executes over a network composed of a partial PVC or SPVC mesh a network composed of a partial PVC or SPVC mesh or pre-determined SVC
or pre-determined SVC meshes. Such a network could be modeled using meshes. Such a network could be modeled using the point-to-multipoint
the point-to-multipoint OSPF interface and the neighbor detection OSPF interface and the neighbor detection could be provided by Proxy PAR
could be provided by Proxy PAR or other means. In the Proxy PAR case or other means. In the Proxy PAR case the router queries for all OSPF
the router queries for all OSPF routers on the same network in the routers on the same network in the same VPN but it installs in the
same VPN but it installs in the interface configuration only routers interface configuration only routers that are already reachable through
that are already reachable through existing PVCs. The underlying existing PVCs. The underlying assumption is that a router knows the
assumption is that a router knows the remote ATM address of a PVC remote ATM address of a PVC and can compare it with appropriate Proxy
and can compare it with appropriate Proxy PAR registrations. If the PAR registrations. If the remote ATM address of the PVC is unknown, it
remote ATM address of the PVC is unknown, it can be discovered by can be discovered by mechanisms like Inverse ARP [15].
mechanisms like Inverse ARP [TB99 ].
Proxy PAR provides a true OSPF neighbor detection mechanism, whereas Proxy PAR provides a true OSPF neighbor detection mechanism, whereas a
a mechanism like Inverse ARP only returns addresses of directly mechanism like Inverse ARP only returns addresses of directly reachable
reachable routers (which are not necessarily running OSPF), in the routers (which are not necessarily running OSPF), in the point-to-multi¡
point-to-multipoint environment. 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 OSPF point-to-point links do not necessarily have an IP address assigned
assigned and even when having one, the mask is undefined. As a and even when having one, the mask is undefined. As a precondition to
precondition to successfully register a service with Proxy PAR, IP successfully register a service with Proxy PAR, IP address and mask is
address and mask is required. Therefore, if a router desires to use required. Therefore, if a router desires to use Proxy PAR to advertise
Proxy PAR to advertise the local end of a point-to-point link to the the local end of a point-to-point link to the router it intends to form
router it intends to form an adjacency with, an IP address has to an adjacency with, an IP address has to be provided and a netmask set or
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.
Sending multicast Hello packets on the point-to-point links allows a default of 255.255.255.252 (this gives as the default case a subnet
to automatically discover OSPF neighbors. On the other hand, using with 2 routers on it) assumed. To allow the discovery of the remote end
Proxy PAR instead avoids sending Hello messages to routers which are not of the interface, IP address of the remote side has to be provided and a
necessarily running OSPF. netmask set or a default of 255.255.255.252 assumed. Obviously the dis¡
Przygienda, Droz, Haas Expires 15 December 1999 [Page covery can only be successfull when both sides of the interface are con¡
7] figured 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.
Internet Draft OSPF over ATM and Proxy PAR 15 June Sending multicast Hello packets on the point-to-point links allows to
1999 automatically discover OSPF neighbors. On the other hand, using Proxy
PAR instead avoids sending Hello messages to routers which are not nec¡
essarily 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 [dR94 ] using unnumbered point-to-point For reasons given already in [14] using unnumbered point-to-point inter¡
interfaces with Proxy PAR is not a very attractive alternative faces with Proxy PAR is not a very attractive alternative since the lack
since the lack of an IP address prevents efficient registration and of an IP address prevents efficient registration and retrieval of con¡
retrieval of configuration information. Relying on the numbering figuration information. Relying on the numbering method based on MIB
method based on MIB entries generates conflicts with the dynamic entries generates conflicts with the dynamic nature of creation of such
nature of creation of such entries and is beyond the scope of this entries and is beyond the scope of this work.
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, To allow other routers to discover an OSPF interface automatically, the
the IP address, mask, Area ID, interface type and router priority IP address, mask, Area ID, interface type and router priority informa¡
information given must be registered with the Proxy PAR server at an tion given must be registered with the Proxy PAR server at an appropri¡
appropriate scope. A change in any of these parameters has to force ate scope. A change in any of these parameters has to force a reregis¡
a reregistration with Proxy PAR. tration with Proxy PAR.
It should be emphasized here that since the registration information It should be emphasized here that since the registration information can
can be used by other routers to resolve IP addresses against NSAPs as be used by other routers to resolve IP addresses against NSAPs as
explained in section 2.4 already, whole IP address of the router must explained in section 2.4, whole IP address of the router must be regis¡
be registered. It is not enough to just indicate the subnet up to tered. It is not enough to just indicate the subnet up to the mask
the mask length but all address bits must be provided. length but 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 For an NBMA interface the appropriate parameters are available and can
can be registered through Proxy PAR without further complications. 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 case of a point-to-multipoint interface the router registers its
information in the same fashion as in the NBMA case except that the information in the same fashion as in the NBMA case except that the
interface type is modified accordingly. 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 case of point-to-point numbered interfaces the address mask is not
specified in the OSPF configuration. If the router has to use Proxy specified in the OSPF configuration. If the router has to use Proxy PAR
PAR to advertise its capability, a mask must be defined or a default to advertise its capability, a mask must be defined or a default value
value of 255.255.255.254 used. of 255.255.255.252 used.
Przygienda, Droz, Haas Expires 15 December 1999 [Page
8]
Internet Draft OSPF over ATM and Proxy PAR 15 June 2.3.4 Registration of Unnumbered Point-to-Point Interfaces
1999
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.
Due to the lack of a configured IP address and difficulties generated 2.4 IP address to NSAP Resolution Using Proxy PAR
by this fact as described earlier, registration of unnumbered
point-to-point interfaces is not covered in this document.
2.4. IP address to NSAP Resolution Using Proxy PAR As a byproduct of Proxy PAR presence, an OSPF implementation could use
the information in registrations for the resolution of IP addresses to
ATM NSAPs on a subnet without having to use static data or mechanisms
such as ATMARP [5]. This again should allow for drastic simplification
of number of mechanisms involved in operation of OSPF over ATM to pro¡
vide an IP overlay.
As a byproduct of Proxy PAR presence, an OSPF implementation could In a system perspective, the OSPF component, the Proxy PAR client, the
use the information in registrations for the resolution of IP IP to NSAP address resolution table, and the ATM circuit manager can be
addresses to ATM NSAPs on a subnet without having to use static data depicted as in Figure 1. Figure 1 shows an example of components inter¡
or mechanisms such as ATMARP [ML98 ]. This again should allow for actions triggered by the result of a Proxy PAR query from the Proxy PAR
drastic simplification of number of mechanisms involved in operation client.
of OSPF over ATM to provide an IP overlay.
2.5. Connection Setup Mechanisms 2.5 Connection Setup Mechanisms
This sections describes OSPF behavior in an ATM network under This sections describes OSPF behavior in an ATM network under different
different assumptions in terms of signaling capabilities and preset assumptions in terms of signaling capabilities and preset connectivity.
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 In environments where only partial PVCs (or SPVCs) meshes are available
available and modeled as point-to-multipoint interfaces, the routers and modeled as point-to-multipoint interfaces, the routers see reachable
see reachable routers through autodiscovery provided by Proxy PAR. routers through autodiscovery provided by Proxy PAR. This leads to
This leads to expected OSPF behavior. In cases where a full mesh of expected OSPF behavior. In cases where a full mesh of PVCs is present,
PVCs is present, such a network should preferably be modeled as NBMA. such a network should preferably be modeled as NBMA. Note that in such a
case, PVCs failures will translate into not so obvious routing failures.
2.5.2. OSPF in SVC Environments 2.5.2 OSPF in SVC Environments
In SVC-capable environments the routers can initiate VCs after having In SVC-capable environments the routers can initiate VCs after having
discovered the appropriate neighbors, preferably driven by the need discovered the appropriate neighbors, preferably driven by the need to
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 | OSPF |<-------------------|Proxy PAR|<---(Proxy PAR query)
detects that the VC initiated by the other side is bidirectional, it |__________| notify | client |
is free to close its own VC and use the detected one. ^ neighbor changes |_________|
| |
Observe that this behavior operates correctly in case OSPF over send and | | maintain Proxy PAR
Demand Circuits extensions are used [Moy95 ] over SVC capable receive | | entries in table
interfaces. OSPF msg | |
| |
Przygienda, Droz, Haas Expires 15 December 1999 [Page | |
9] ____V____ ____V_____
| ATM | | |
| circuit |-------------------->|IP to NSAP|
| manager | check | table |
|_________| IP to NSAP bindings |__________|
Internet Draft OSPF over ATM and Proxy PAR 15 June Figure 1: System perspective of typical components interactions
1999
+ + + + + +
| +---+ | | | +---+ | |
+--+ |---|RTA|---| +-------+ | +--+ +--+ |---|RTA|---| +-------+ | +--+
|H1|---| +---+ | | ATM | |---|H2| |H1|---| +---+ | | ATM | |---|H2|
+--+ | | +---+ | Cloud | +---+ | +--+ +--+ | | +---+ | Cloud | +---+ | +--+
|LAN Y |---|RTB|-------------|RTC|---| |LAN Y |---|RTB|-------------|RTC|---|
+ | +---+ | PPAR | +---+ | + | +---+ | PPAR | +---+ |
+ +-------+ + + +-------+ +
Figure 1: Simple Topology with Router B and Router C operating across
NBMA ATM interfaces with Proxy PAR
The existence of VCs used for OSPF exchanges is orthogonal to the Figure 2: Simple Topology with Router B and Router C operating
number and type of VCs the router chooses to use within the logical across NBMA ATM interfaces with Proxy PAR
interface to forward data to other routers. OSPF implementations are
free to use any of these VCs (1) to send packets if their endpoints
are adequate and must accept hello packets arriving on any of the VCs
belonging to the logical interface even if OSPF operating on such an
interface is not aware of their existence. An OSPF implementation
may not accept or close connections being initiated by another router
that has either not been discovered by Proxy PAR or whose Proxy PAR
registration is indicating that it is not adjacent.
As an example consider the topology in figure 2.5.2 where router send data such as Hello-packets. This can lead to race conditions where
RTB and RTC are connected to a common ATM cloud offering Proxy PAR both sides can open a VC simultaneously. It is generally desirable to
services. Assuming that RTB's OSPF implementation is aware of SVCs avoid wasting this valuable resource: if the router with lower Router ID
initiated on the interface and RTC only makes minimal use of Proxy detects that the VC initiated by the other side is bidirectional, it is
PAR information the following sequence could develop illustrating free to close its own VC and use the detected one. Note that this either
some of the cases described above:
1. RTC and RTB register with ATM cloud as Proxy PAR capable and requires the OSPF implementation to be aware of the VCs used to send and
discover each other as adjacent OSPF routers. receive Hello messages, or the component responsible of managing VCs to
be aware of the usage of particular VCs.
2. RTB sends a hello which forces it to establish a SVC connection Observe that this behavior operates correctly in case OSPF over Demand
to RTC. 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
1. in case they are aware of their existence delaying the sending of the first OSPF Hello from the router with the
lower Router ID, by an amount of time larger than the interval between
the queries from the Proxy PAR client to the server. Chances are that
the router with the higher Router ID opens the VC (or use an already
existing VC) and sends the OSPF Hello first, if its interval between
queries is smaller than the Hello delay of the router with the lower
Router ID. Since this interval can vary depending on particular needs
and implementations, the race conditions described above can still be
expected to happen, albeit presumably less often.
Przygienda, Droz, Haas Expires 15 December 1999 [Page The existence of VCs used for OSPF exchanges is orthogonal to the number
10] 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 (in case they are aware of their existence) to send
packets if their endpoints are adequate and must accept hello packets
arriving on any of the VCs belonging to the logical interface even if
OSPF operating on such an interface is not aware of their existence. An
OSPF implementation may ignore connections being initiated by another
router that has not been discovered by Proxy PAR. The OSPF implementa¡
tion will anyway ignore a neighbor whose Proxy PAR registration indi¡
cates that it is not adjacent.
Internet Draft OSPF over ATM and Proxy PAR 15 June As an example consider the topology in Figure 2 where router RTB and RTC
1999 are connected to a common ATM cloud offering Proxy PAR services. Assum¡
ing that RTB's OSPF implementation is aware of SVCs initiated on the
interface and RTC only makes minimal use of Proxy PAR information the
following sequence could develop illustrating some of the cases
described above:
3. RTC sends a hello to RTB but disregards the already existing VC 1. RTC and RTB register with ATM cloud as Proxy PAR capable and
and establishes a new VC to RTB to deliver the packet. discover each other as adjacent OSPF routers.
2. RTB sends a hello which forces it to establish a SVC connec¡
tion to RTC.
3. RTC sends a hello to RTB but disregards the already existing
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 bi-directional VC and assuming here that RTC's
OSPF Id is higher, closes the VC originated in step 2. OSPF Id 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 it using the newly
establish data SVC. RTC must accept the hello despite the minimal establish data SVC. RTC must accept the hello despite the min¡
implementation. imal implementation.
3. Acknowledgments 3 Acknowledgments
Comments and contributions from several sources, especially Rob Comments and contributions from several sources, especially Rob Coltun,
Coltun, Doug Dykeman and John Moy are included in this work. Doug Dykeman, John Moy and Alex Zinin are included in this work.
4. Security Consideration 4 Security Consideration
Several aspects are to be considered when talking about security of Several aspects are to be considered when talking about security of
operating OSPF over ATM and/or Proxy PAR. The security of registered operating OSPF over ATM and/or Proxy PAR. The security of registered
information handed to the ATM cloud must be guaranteed by the underlying information handed to the ATM cloud must be guaranteed by the underlying
PNNI protocol. Extensions to PNNI are available and given their PNNI protocol. Extensions to PNNI are available and given their imple¡
implementation spoofing of registrations and/or denial-of-service issues mentation spoofing of registrations and/or denial-of-service issues can
can be addressed [PB97 ]. The registration itself through proxy PAR is be addressed [16]. The registration itself through proxy PAR is not
not secured and appropriate mechanisms are for further study. However, secured and appropriate mechanisms are for further study. However, even
even if the security at the ATM layer is not guaranteed, OSPF security if the security at the ATM layer is not guaranteed, OSPF security mecha¡
mechanisms can be used to verify that detected neighbors are authorized nisms can be used to verify that detected neighbors are authorized to
to interact with the entity discovering them. interact with the entity discovering them.
References
[AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum 5 Bibliography
af-lane-0021.000, January 1995.
[AF96a] ATM-Forum. Interim Local Management Interface (ILMI) [1] P. Droz, "PNNI Augmented Routing (PAR) Version 1.0." ATM Forum af-
Specification 4.0. ATM Forum 95-0417R8, June 1996. ra-0104.000, January 1999.
[AF96b] ATM-Forum. Private Network-Network Interface Specification [2] T. P. P. Droz, "Proxy PAR." Internet Draft draft-ietf-ion-proxypar-
Version 1.0. ATM Forum af-pnni-0055.000, March 1996. arch-01, February 1999.
Przygienda, Droz, Haas Expires 15 December 1999 [Page [3] ATM-Forum, "Private Network-Network Interface Specification Version
11] 1.0." ATM Forum af-pnni-0055.000, March 1996.
Internet Draft OSPF over ATM and Proxy PAR 15 June [4] ATM-Forum, "Interim Local Management Interface (ILMI) Specification
1999 4.0." ATM Forum 95-0417R8, June 1996.
[Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based [5] J. H. M. Laubach, "Classical IP and ARP over ATM, RFC 2225." Inter¡
ATM networks, RFC 2022. Internet Engineering Task Force, net Engineering Task Force, April 1998.
November 1996.
[Col98] R. Coltun. The OSPF Opaque LSA Option, RFC 2370. Internet [6] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-0021.000,
Engineering Task Force, July 1998. January 1995.
[Dav99a] M. Davison. ILMI-Based Server Discovery for ATMARP, RFC [7] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM net¡
2601. Internet Engineering Task Force, June 1999. works, RFC 2022." Internet Engineering Task Force, November 1996.
[Dav99b] M. Davison. ILMI-Based Server Discovery for MARS, RFC 2602. [8] R. Coltun, "The OSPF Opaque LSA Option, RFC 2370." Internet Engi¡
Internet Engineering Task Force, June 1999. neering Task Force, July 1998.
[Dav99c] M. Davison. ILMI-Based Server Discovery for NHRP, RFC 2603. [9] M. Davison, "ILMI-Based Server Discovery for ATMARP, RFC 2601."
Internet Engineering Task Force, June 1999. Internet Engineering Task Force, June 1999.
[dR94] O. deSouza and M. Rodrigues. Guidelines for Running OSPF [10] M. Davison, "ILMI-Based Server Discovery for MARS, RFC 2602."
Over Frame Relay Networks, RFC 1586. Internet Engineering Internet Engineering Task Force, June 1999.
Task Force, March 1994.
[Dro99] P. Droz. PNNI Augmented Routing (PAR) Version 1.0. ATM
Forum af-ra-0104.000, January 1999.
[ML98] J. Halpern M. Laubach. Classical IP and ARP over ATM, RFC
2225. Internet Engineering Task Force, April 1998.
[Moy95] J. Moy. Extending OSPF to Support Demand Circuits, RFC
1793. Internet Engineering Task Force, April 1995.
[Moy98] J. Moy. OSPF Version 2 - RFC 2328. Internet Engineering [11] M. Davison, "ILMI-Based Server Discovery for NHRP, RFC 2603."
Task Force, April 1998. Internet Engineering Task Force, June 1999.
[PB97] T. Przygienda and C. Bullard. Baseline Text for PNNI Peer [12] J. Moy, "OSPF Version 2 - RFC 2328." Internet Engineering Task
Authentication and Cryptographic Data Integrity. ATM Forum Force, April 1998.
97-0472, July 1997.
[PD99] T. Przygienda P. Droz. Proxy PAR. Internet Draft [13] J. Moy, "Extending OSPF to Support Demand Circuits, RFC 1793."
draft-ietf-ion-proxypar-arch-01, February 1999. Internet Engineering Task Force, April 1995.
[TB99] A. Malis T. Bradley, C. Brown. Inverse Address Resolution [14] O. deSouza and M. Rodrigues, "Guidelines for Running OSPF Over
Protocol, RFC 2390. Internet Engineering Task Force, Frame Relay Networks, RFC 1586." Internet Engineering Task Force, March
September 1999. 1994.
Przygienda, Droz, Haas Expires 15 December 1999 [Page [15] A. M. T. Bradley, C. Brown, "Inverse Address Resolution Protocol,
12] RFC 2390." Internet Engineering Task Force, September 1999.
Internet Draft OSPF over ATM and Proxy PAR 15 June [16] T. Przygienda and C. Bullard, "Baseline Text for PNNI Peer Authen¡
1999 tication and Cryptographic Data Integrity." ATM Forum 97-0472, July
1997.
Authors' Addresses Authors' Addresses
Tony Przygienda Tony Przygienda
Bell Labs, Lucent Technologies Siara Systems
101 Crawfords Corner Road 300 Ferguson Drive
Holmdel, NJ 07733-3030 Mountain View
prz@dnrc.bell-labs.com California 94043
prz@siara.com
Patrick Droz Patrick Droz
IBM Research Division IBM Research Division
Saumerstrasse 4 Saumerstrasse 4
8803 Ruschlikon 8803 Ruschlikon
Switzerland Switzerland
dro@zurich.ibm.com dro@zurich.ibm.com
Robert Haas Robert Haas
IBM Research Division IBM Research Division
Saumerstrasse 4 Saumerstrasse 4
8803 Ruschlikon 8803 Ruschlikon
Switzerland Switzerland
rha@zurich.ibm.com rha@zurich.ibm.com
Przygienda, Droz, Haas Expires 15 December 1999 [Page
13]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/