As per Relevance of the word framework, we have this rfc below:
Network Working Group R.
Request for Comments: 1932 D.
Category: Informational AT&T Bell
C.
April 1996
IP over ATM: A Framework
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The discussions of the IP over ATM working group over the
several years have produced a diverse set of proposals, some of
are no longer under active consideration. A categorization
provided for the purpose of focusing discussion on the
proposals for IP over ATM deemed of primary interest by the IP
ATM working group. The intent of this framework is to help
the differences between proposals and identify common features
order to promote convergence to a smaller and more
compatible set of standards. In summary, it is hoped that
document, in classifying ATM approaches and issues will help to
the IP over ATM working group's direction
1.
The IP over ATM Working Group of the Internet Engineering Task
(IETF) is chartered to develop standards for routing and
IP packets over ATM sub-networks. This document provides
classification/taxonomy of IP over ATM options and issues and
describes various proposals in these terms
The remainder of this memorandum is organized as follows
o Section 2 defines several terms relating to networking
internetworking
o Section 3 discusses the parameters for a taxonomy of
different ATM models under discussion
o Section 4 discusses the options for low level encapsulation
Cole, Shur & Villamizar Informational [Page 1]
RFC 1932 IP over ATM: A Framework Document April 1996
o Section 5 discusses tradeoffs between connection oriented
connectionless approaches
o Section 6 discusses the various means of providing
connections across IP subnet boundaries
o Section 7 discusses the proposal to extend IP routing to
accommodate direct connections across IP subnet boundaries
o Section 8 identifies several prominent IP over ATM proposals
have been discussed within the IP over ATM Working Group
their relationship to the framework described in this document
o Section 9 addresses the relationship between the
developed in the IP over ATM and related working groups and
various models discussed
2. Definitions and
We define several terms
A Host or End System: A host delivers/receives IP packets to/
other systems, but does not relay IP packets
A Router or Intermediate System: A router delivers/receives
packets to/from other systems, and relays IP packets
systems
IP Subnet: In an IP subnet, all members of the subnet are able
transmit packets to all other members of the subnet directly
without forwarding by intermediate entities. No two
members are considered closer in the IP topology than any other
From an IP routing and IP forwarding standpoint a subnet
atomic, though there may be repeaters, hubs, bridges, or
between the physical interfaces of subnet members
Bridged IP Subnet: A bridged IP subnet is one in which two
more physically disjoint media are made to appear as a single
subnet. There are two basic types of bridging, media
control (MAC) level, and proxy ARP (see section 6).
A Broadcast Subnet: A broadcast network supports an
number of hosts and routers and additionally is capable
transmitting a single IP packet to all of these systems
A Multicast Capable Subnet: A multicast capable subnet
a facility to send a packet which reaches a subset of
destinations on the subnet. Multicast setup may be
Cole, Shur & Villamizar Informational [Page 2]
RFC 1932 IP over ATM: A Framework Document April 1996
initiated, or leaf initiated. ATM UNI 3.0 [4] and UNI 3.1
support only sender initiated while IP supports leaf
join. UNI 4.0 will support leaf initiated join
A Non-Broadcast Multiple Access (NBMA) Subnet: An NBMA
an arbitrary number of hosts and routers but does
natively support a convenient multi-destination
transmission facility, as does a broadcast or multicast
subnetwork
An End-to-End path: An end-to-end path consists of two hosts
can communicate with one another over an arbitrary number
routers and subnets
An internetwork: An internetwork (small "i") is the
of networks, often of various different media and lower
encapsulations, to form an integrated larger network
communication between any of the hosts on any of the
networks. The Internet (big "I") is a specific well
global concatenation of (over 40,000 at the time of writing
component networks
IP forwarding: IP forwarding is the process of receiving a
and using a very low overhead decision process determining
to handle the packet. The packet may be delivered
(for example, management traffic) or forwarded externally.
traffic that is forwarded externally, the IP forwarding
also determines which interface the packet should be sent out on
and if necessary, either removes one media layer
and replaces it with another, or modifies certain fields in
media layer encapsulation
IP routing: IP routing is the exchange of information that
place in order to have available the information necessary
make a correct IP forwarding decision
IP address resolution: A quasi-static mapping exists between
address on the local IP subnet and media address on the
subnet. This mapping is known as IP address resolution
An address resolution protocol (ARP) is a protocol
address resolution
In order to support end-to-end connectivity, two techniques are used
One involves allowing direct connectivity across classic IP
boundaries supported by certain NBMA media, which includes ATM.
other involves IP routing and IP forwarding. In essence, the
technique is extending IP address resolution beyond the boundaries
the IP subnet, while the latter is interconnecting IP subnets
Cole, Shur & Villamizar Informational [Page 3]
RFC 1932 IP over ATM: A Framework Document April 1996
Large internetworks, and in particular the Internet, are unlikely
be composed of a single media, or a star topology, with a
media at the center. Within a large network supporting a
media, typically any large NBMA such as ATM, IP routing and
forwarding must always be accommodated if the internetwork is
than the NBMA, particularly if there are multiple points
interconnection with the NBMA and/or redundant,
interconnections
Routing information exchange in a very large internetwork can
quite dynamic due to the high probability that some network
are changing state. The address resolution space consumption
resource consumption due to state change, or maintenance of
information is rarely a problem in classic IP subnets. It can
a problem in large bridged networks or in proposals that attempt
extend address resolution beyond the IP subnet. Scaling
of address resolution and routing proposals, with respect to
information and state change, must be considered
3. Parameters Common to IP Over ATM
In some discussion of IP over ATM distinctions have made
local area networks (LANs), and wide area networks (WANs) that do
necessarily hold. The distinction between a LAN, MAN and WAN is
matter of geographic dispersion. Geographic dispersion
performance due to increased propagation delay
LANs are used for network interconnections at the the major
traffic interconnect sites. Such LANs have multiple
authorities, currently exclusively support routers providing
to multihomed internets, currently rely on PVCs and static
resolution, and rely heavily on IP routing. Such a
differs from the typical LANs used to interconnect computers
corporate or campus environments, and emphasizes the point that
characterization of LANs do not necessarily hold. Similarly,
such as those under consideration by numerous large IP providers,
not conform to prior characterizations of ATM WANs in that they
a single administrative authority and a small number of
aggregating large flows of traffic onto single PVCs and rely on
routers to avoid forming congestion bottlenecks within ATM
The following characteristics of the IP over ATM internetwork may
independent of geographic dispersion (LAN, MAN, or WAN).
o The size of the IP over ATM internetwork (number of nodes).
o The size of ATM IP subnets (LIS) in the ATM Internetwork
Cole, Shur & Villamizar Informational [Page 4]
RFC 1932 IP over ATM: A Framework Document April 1996
o Single IP subnet vs multiple IP subnet ATM internetworks
o Single or multiple administrative authority
o Presence of routers providing transit to multihomed internets
o The presence or absence of dynamic address resolution
o The presence or absence of an IP routing protocol
IP over ATM should therefore be characterized by
o Encapsulations below the IP level
o Degree to which a connection oriented lower level is
and utilized
o Type of address resolution at the IP subnet level (static
dynamic).
o Degree to which address resolution is extended beyond the
subnet boundary
o The type of routing (if any) supported above the IP level
ATM-specific attributes of particular importance include
o The different types of services provided by the ATM
Layers (AAL). These specify the Quality-of-Service,
connection-mode, etc. The models discussed within this
assume an underlying connection-oriented service
o The type of virtual circuits used, i.e., PVCs versus SVCs.
PVC environment requires the use of either static tables
ATM-to-IP address mapping or the use of inverse ARP, while
SVC environment requires ARP functionality to be provided
o The type of support for multicast services. If point-to-
services only are available, then a server for IP multicast
required. If point-to-multipoint services are available,
IP multicast can be supported via meshes of point-to-
connections (although use of a server may be necessary due
limits on the number of multipoint VCs able to be supported or
maintain the leaf initiated join semantics).
o The presence of logical link identifiers (VPI/VCIs) and
various information element (IE) encodings within the ATM
signaling specification, i.e., the ATM Forum UNI version 3.1.
Cole, Shur & Villamizar Informational [Page 5]
RFC 1932 IP over ATM: A Framework Document April 1996
This allows a VC originator to specify a range of "layer
entities as the destination "AAL User". The AAL
do not prohibit any particular "layer X" from
directly to a local AAL service. Taken together these
imply a range of methods for encapsulation of upper
protocols over ATM. For example, while LLC/SNAP encapsulation
one approach (the default), it is also possible to bind
circuits to higher level entities in the TCP/IP protocol stack
Some examples of the latter are single VC per protocol binding
TULIP, and TUNIC, discussed further in Section 4.
o The number and type of ATM administrative domains/networks,
type of addressing used within an administrative domain/network
In particular, in the single domain/network case, all
systems may be safely assumed to be using a single
addressing format, while in the multiple domain case,
stations may not all be using the same common format
with corresponding implications on address resolution. (
Appendix A for a discussion of some of the issues that
when multiple ATM address formats are used in the same
IP subnet (LIS).) Also security/authentication is much more of
concern in the multiple domain case
IP over ATM proposals do not universally accept that IP routing
an ATM network is required. Certain proposals rely on the
assumptions
o The widespread deployment of ATM within premises-based networks
private wide-area networks and public networks,
o The definition of interfaces, signaling and routing
among private ATM networks
The above assumptions amount to ubiquitous deployment of a
ATM fabric which serves as the hub of a star topology around
all other media is attached. There has been a great deal
discussion over when, if ever, this will be a realistic
for very large internetworks, such as the Internet. Advocates
such approaches point out that even if these are not relevant to
large internetworks such as the Internet, there may be a place
such models in smaller internetworks, such as corporate networks
The NHRP protocol (Section 8.2), not necessarily specific to ATM
would be particularly appropriate for the case of ubiquitous
deployment. NHRP supports the establishment of direct
across IP subnets in the ATM domain. The use of NHRP does
require ubiquitous ATM deployment, but currently imposes
constraints to avoid routing loops (see Section 7). Section 8.2
Cole, Shur & Villamizar Informational [Page 6]
RFC 1932 IP over ATM: A Framework Document April 1996
describes NHRP in greater detail
The Peer Model assumes that internetwork layer addresses can
mapped onto ATM addresses and vice versa, and that
information between ATM routing and internetwork layer routing can
exchanged. This approach has limited applicability unless
deployment of ATM holds. The peer model is described in Section 8.4.
The Integrated Model proposes a routing solution supporting
exchange of routing information between ATM routing and higher
routing. This provides timely external routing information
the ATM routing and provides transit of external routing
through the ATM routing between external routing domains.
proposals may better support a possibly lengthy transition
which assumptions of ubiquitous ATM access do not hold.
Integrated Model is described in Section 8.5.
The Multiprotocol over ATM (MPOA) Sub-Working Group was formed by
ATM Forum to provide multiprotocol support over ATM. The MPOA
is at an early stage at the time of this writing. An MPOA
document has been drafted, which provides terminology for
discussion of the architecture. This document is available from
FTP server ftp.atmforum.com in pub/contributions as the file atm95-
0824.ps or atm95-0824.txt
4. Encapsulations and Lower Layer
Data encapsulation, and the identification of VC endpoints
constitute two important issues that are somewhat orthogonal to
issues of network topology and routing. The relationship
these two issues is also a potential sources of confusion.
conventional LAN technologies the 'encapsulation' wrapped around
packet of data typically defines the (de)multiplexing path
source and destination nodes (e.g. the Ethertype field of
Ethernet packet). Choice of the protocol endpoint within
packet's destination node is essentially carried 'in-band'.
As the multiplexing is pushed towards ATM and away from LLC/
mechanism, a greater burden will be placed upon the call setup
teardown capacity of the ATM network. This may result in
questions being raised regarding the scalability of these lower
multiplexing options
With the ATM Forum UNI version 3.1 service the choice of
within a destination node is made 'out of band' - during the
Setup phase. This is quite independent of any in-band
mechanisms that may be in use. The B-LLI Information Element
Layer 2 or Layer 3 entities to be specified as a VC's endpoint.
Cole, Shur & Villamizar Informational [Page 7]
RFC 1932 IP over ATM: A Framework Document April 1996
faced with an incoming SETUP message the Called Party will
locally for an AAL User that claims to provide the service of
layer specified in the B-LLI. If one is found then the VC will
accepted (assuming other conditions such as QoS requirements are
met).
An obvious approach for IP environments is to simply specify
Internet Protocol layer as the VCs endpoint, and place IP
into AAL--SDUs for transmission. This is termed 'VC multiplexing'
'Null Encapsulation', because it involves terminating a VC (
an AAL instance) directly on a layer 3 endpoint. However,
approach has limitations in environments that need to
multiple layer 3 protocols between the same two ATM level endpoints
Each pair of layer 3 protocol entities that wish to exchange
require their own VC
Cole, Shur & Villamizar Informational [Page 8]
RFC 1932 IP over ATM: A Framework Document April 1996
RFC-1483 [6] notes that VC multiplexing is possible, but focuses
describing an alternative termed 'LLC/SNAP Encapsulation'.
allows any set of protocols that may be uniquely identified by
LLC/SNAP header to be multiplexed onto a single VC. Figure 1
how this works for IP packets - the first 3 bytes indicate that
payload is a Routed Non-ISO PDU, and the Organizationally
Identifier (OUI) of 0x00-00-00 indicates that the Protocol
(PID) is derived from the EtherType associated with IP
(0x800). ARP packets are multiplexed onto a VC by using a PID
0x806 instead of 0x800.
.---------------.
: :
: IP Packet :
: :
---------------
: :
: :
8 byte header V
.-------------.-------------.------------.---------------.
: : : : :
: : : : Encapsulated :
: 0xAA-AA-03 : 0x00-00-00 : 0x08-00 : Payload :
: : : : :
-------------^-------------^------------^---------------
: : : :
: (LLC) (OUI) (PID) : : :
V V V
.----------------------------------------------------------.
: :
: AAL SDU :
: :
----------------------------------------------------------
Figure 1: IP packet encapsulated in an AAL5
Cole, Shur & Villamizar Informational [Page 9]
RFC 1932 IP over ATM: A Framework Document April 1996
.----------. .----------. .---------. .----------.
: : : : : : : :
: IP : : ARP : :AppleTalk: : etc... :
: : : : : : : :
---------- ---------- --------- ----------
^ : ^ : ^ : ^ :
: : : : : : : :
: V : V : V :
.-----------------------------------------------------------.
: :
: 0x800 0x806 0x809 other :
: :
: Instance of layer using LLC/SNAP header to :
: perform multiplexing/demultiplexing :
: :
-----------------------------------------------------------
^ :
: :
:
.------------------.
: :
: Instance of AAL5 :
: terminating :
: one VCC :
: :
------------------
Figure 2: LLC/SNAP encapsulation allows more than
IP or ARP per VC
Whatever layer terminates a VC carrying LLC/SNAP encapsulated
must know how to parse the AAL--SDUs in order to retrieve
packets. The recently approved signalling standards for IP over
are more explicit, noting that the default SETUP message used
establish IP over ATM VCs must carry a B-LLI specifying an ISO 8802/2
Layer 2 (LLC) entity as each VCs endpoint. More significantly,
is no information carried within the SETUP message about the
of the layer 3 protocol that originated the request - until
packets begin arriving the terminating LLC entity cannot know
one or more higher layers are packet destinations
Taken together, this means that hosts require a protocol entity
register with the host's local UNI 3.1 management layer as being
LLC entity, and this same entity must know how to handle and
LLC/SNAP encapsulated packets. The LLC entity will also
mechanisms for attaching to higher layer protocols such as IP
ARP. Figure 2 attempts to show this, and also highlights the
that such an LLC entity might support many more than just IP and ARP
Cole, Shur & Villamizar Informational [Page 10]
RFC 1932 IP over ATM: A Framework Document April 1996
In fact the combination of RFC 1483 LLC/SNAP encapsulation,
entities terminating VCs, and suitable choice of LLC/SNAP values,
go a long way towards providing an integrated approach to
multiprotocol networks over ATM
The processes of actually establishing AAL Users, and
them to the local UNI 3.1 management layers, are still undefined
are likely to be very dependent on operating system environments
Two encapsulations have been discussed within the IP over ATM
group which differ from those given in RFC-1483 [6]. These have
characteristic of largely or totally eliminating IP header overhead
These models were discussed in the July 1993 IETF meeting
Amsterdam, but have not been fully defined by the working group
TULIP and TUNIC assume single hop reachability between IP entities
Following name resolution, address resolution, and SVC signaling,
implicit binding is established between entities in the two hosts
In this case full IP headers (and in particular source
destination addresses) are not required in each data packet
o The first model is "TCP and UDP over Lightweight IP" (TULIP
in which only the IP protocol field is carried in each packet
everything else being bound at call set-up time. In
case the implicit binding is between the IP entities in
host. Since there is no further routing problem once the
is established, since AAL5 can indicate packet size,
fragmentation cannot occur, and since ATM signaling will
exception conditions, the absence of all other IP header
and of ICMP should not be an issue. Entry to TULIP mode
occur as the last stage in SVC signaling, by a simple
to the encapsulation negotiation described in RFC-1755 [10].
TULIP changes nothing in the abstract architecture of the
model, since each host or router still has an IP address which
resolved to an ATM address. It simply uses the point-to-
property of VCs to allow the elimination of some per-
overhead. The use of TULIP could in principle be negotiated on
per-SVC basis or configured on a per-PVC basis
o The second model is "TCP and UDP over a Nonexistent
Connection" (TUNIC). In this case no network-layer
is carried in each packet, everything being bound at
circuit set-up time. The implicit binding is between
applications using either TCP or UDP directly over AAL5 on
dedicated VC. If this can be achieved, the IP protocol field
no useful dynamic function. However, in order to achieve
between two applications, the use of a well-known port
Cole, Shur & Villamizar Informational [Page 11]
RFC 1932 IP over ATM: A Framework Document April 1996
in classical IP or in TULIP mode may be necessary during
set-up. This is a subject for further study and would
significant extensions to the use of SVC signaling described
RFC-1755 [10].
Encapsulation In setup message
-------------+--------------------------+------------------------
SNAP/LLC _ nothing _ source and
_ _ address,
_ _ family, protocol,
_ _
NULL encaps _ protocol family _ source and
_ _ address, protocol,
_ _
TULIP _ source and destination _ protocol,
_ address, protocol family _
_ _
TUNIC - A _ source and destination _
_ address, protocol family _
_ protocol _
_ _
TUNIC - B _ source and destination _
_ address, protocol family _
_ protocol, ports _
Table 1: Summary of Encapsulation
TULIP/TUNIC can be presented as being on one end of a continuum
the SNAP/LLC encapsulation, with various forms of null
somewhere in the middle. The continuum is simply a matter of how
is moved from in-stream demultiplexing to call setup demultiplexing
The various encapsulation types are presented in Table 1.
Encapsulations such as TULIP and TUNIC make assumptions with regard
the desirability to support connection oriented flow. The
between connection oriented and connectionless are discussed in
5.
Cole, Shur & Villamizar Informational [Page 12]
RFC 1932 IP over ATM: A Framework Document April 1996
5. Connection Oriented and Connectionless
The connection oriented and connectionless approaches each
advantages and disadvantages. In the past, strong advocates of
connection oriented and pure connectionless architectures have
intensely. IP over ATM does not need to be purely connectionless
purely connection oriented
APPLICATION Pure Connection Oriented
----------------+-------------------------------------------------
General _ Always set up a
_
Short Duration _ Set up a VC. Either hold the packet during
UDP (DNS) _ setup or drop it and await a retransmission
_ Teardown on a timer basis
_
Short Duration _ Set up a VC. Either hold packet(s) during
TCP (SMTP) _ setup or drop them and await retransmission
_ Teardown on detection of FIN-ACK or on a
_ basis
_
Elastic (TCP) _ Set up a VC same as above. No clear method
Bulk Transfer _ set QoS parameters has emerged
_
Real Time _ Set up a VC. QoS parameters are assumed
(audio, video) _ precede traffic in RSVP or be carried in
_ form within the traffic itself
Table 2: Connection Oriented vs. Connectionless - a) a
connection oriented
ATM with basic AAL 5 service is connection oriented. The IP
above ATM is connectionless. On top of IP much of the traffic
supported by TCP, a reliable end-to-end connection oriented protocol
A fundamental question is to what degree is it beneficial to
different flows above IP into separate connections below IP. There
a broad spectrum of opinion on this
As stated in section 4, at one end of the spectrum, IP would
highly connectionless and set up single VCs between routers which
adjacent on an IP subnet and for which there was active traffic flow
All traffic between the such routers would be multiplexed on a
ATM VC. At the other end of the spectrum, a separate ATM VC would
created for each identifiable flow. For every unique TCP or
address and port pair encountered a new VC would be required. Part
the intensity of early arguments has been over failure to
that there is a middle ground
Cole, Shur & Villamizar Informational [Page 13]
RFC 1932 IP over ATM: A Framework Document April 1996
ATM offers QoS and traffic management capabilities that are
suited for certain types of services. It may be advantageous to
separate ATM VC for such services. Other IP services such as DNS,
ill suited for connection oriented delivery, due to their normal
short duration (typically one packet in each direction).
duration transactions, even many using TCP, may also be poorly
for a connection oriented model due to setup and state overhead.
QoS and traffic management capabilities may be poorly suited
elastic traffic
APPLICATION Middle
----------------+-------------------------------------------------
General _ Use RSVP or other indication which
_ indicate a VC is needed and what QoS
_ are appropriate
_
Short Duration _ Forward hop by hop. RSVP is unlikely to
UDP (DNS) _ this type of traffic
_
Short Duration _ Forward hop by hop unless RSVP
TCP (SMTP) _ otherwise. RSVP is unlikely to precede
_ type of traffic
_
Elastic (TCP) _ By default hop by hop forwarding is used
Bulk Transfer _ However, RSVP information, local
_ about TCP port number usage, or a
_ implemented method for passing QoS
_ from the application to the IP/ATM driver
_ allow/suggest the establishment of direct VCs
_
Real Time _ Forward hop by hop unless RSVP
(audio, video) _ otherwise. RSVP will indicate QoS requirements
_ It is assumed RSVP will generally be used
_ this case. A local decision can be made as
_ whether the QoS is better served by a
_ VC
Table 3: Connection Oriented vs. Connectionless - b) a middle
Cole, Shur & Villamizar Informational [Page 14]
RFC 1932 IP over ATM: A Framework Document April 1996
APPLICATION Pure Connectionless
----------------+-------------------------------------------------
General _ Always forward hop by hop. Use
_ algorithms implemented at the IP layer
_ support reservations such as those specified
_ RSVP
_
Short Duration _ Forward hop by hop
UDP (DNS) _
_
Short Duration _ Forward hop by hop
TCP (SMTP) _
_
Elastic (TCP) _ Forward hop by hop. Assume ability of TCP
Bulk Transfer _ share bandwidth (within a VBR VC) works as
_ or better than ATM traffic management
_
Real Time _ Forward hop by hop. Assume that
(audio, video) _ algorithms at the IP level can be designed
_ work with sufficiently good
_ (e.g., due to support for
_ reservation).
Table 4: Connection Oriented vs. Connectionless - c) a
connectionless
Work in progress is addressing how QoS requirements might
expressed and how the local decisions might be made as to
those requirements are best and/or most cost effectively
using ATM or IP capabilities. Table 2, Table 3, and Table 4
typical treatment of various types of traffic using a pure
oriented approach, middle ground approach, and pure
approach
The above qualitative description of connection oriented
connectionless service serve only as examples to illustrate
approaches. Work in the area of an integrated service model, QoS
resource reservation are related to but outside the scope of the
over ATM Work Group. This work falls under the Integrated
Work Group (int-serv) and Reservation Protocol Work Group (rsvp),
will ultimately determine when direct connections will
established. The IP over ATM Work Group can make more rapid
if concentrating solely on how direct connections are established
Cole, Shur & Villamizar Informational [Page 15]
RFC 1932 IP over ATM: A Framework Document April 1996
6. Crossing IP Subnet
A single IP subnet will not scale well to a large size.
which extend the size of an IP subnet in other media include
layer bridging, and proxy ARP bridging
MAC layer bridging alone does not scale well. Protocols such as
rely on the media broadcast to exchange address
information. Most bridges improve scaling characteristics
capturing ARP packets and retaining the content, and distributing
information among bridging peers. The ARP information gathered
ARP replies is broadcast only where explicit ARP requests are made
This technique is known as proxy ARP
Proxy ARP bridging improves scaling by reducing broadcast traffic
but still suffers scaling problems. If the bridged IP subnet is
of a larger internetwork, a routing protocol is required to
what destinations are beyond the IP subnet unless a
configured default route is used. A default route is only
to a very simple topology with respect to the larger internet
creates a single point of failure. Because internets of
size create scaling problems for routing protocols, the
networks of such large internets are often partitioned into areas
autonomous systems or routing domains, and routing confederacies
The scaling limits of the simple IP subnet require a large network
be partitioned into smaller IP subnets. For NBMA media like ATM
there are advantages to creating direct connections across the
underlying NBMA network. This leads to the need to create
connections across IP subnet boundaries
Cole, Shur & Villamizar Informational [Page 16]
RFC 1932 IP over ATM: A Framework Document April 1996
.----------.
---------< Non-ATM :
.-------. / /-< Subnet >-\
:Sub-ES >--/ : ---------- :
------- : :
: :
.--^---. .--^---.
:Router: :Router
-v-v-- -v-v--
: : : :
.--------. : : .--------. : : .--------.
.-------. : >-/ \-< >-/ \-< : .-------.
:Sub-ES :---: Subnet :-----: Subnet :-----: Subnet :---:Sub-ES :
------- : : : : : : -------
-------- ---v---- --------
:
.--^----.
:Sub-ES :
-------
Figure 3: A configuration with both ATM-based and non-ATM
subnets
For example, figure 3 shows an end-to-end configuration consisting
four components, three of which are ATM technology based, while
fourth is a standard IP subnet based on non-ATM technology. End
systems (either hosts or routers) attached to the ATM-based
may communicate either using the Classical IP model or directly
ATM (subject to policy constraints). Such nodes may
directly at the IP level without necessarily needing an
router, even if end-systems do not share a common IP-level
prefix. Communication with end-systems on the non-ATM-
Classical IP subnet takes place via a router, following the
IP model (see Section 8.1 below).
Many of the problems and issues associated with creating such
connections across subnet boundaries were originally being
in the IETF's IPLPDN working group and the IP over ATM working group
This area is now being addressed in the Routing over Large
working group. Examples of work performed in the IPLPDN
group include short-cut routing (proposed by P. Tsuchiya)
directed ARP RFC-1433 [5] over SMDS networks. The ROLC working
has produced the distributed ARP server architectures and the
Address Resolution Protocol (NARP) [7]. The Next Hop
Protocol (NHRP) is still work in progress, though the ROLC WG
considering advancing the current document. Questions/
specifically related to defining a capability to cross IP
boundaries include
Cole, Shur & Villamizar Informational [Page 17]
RFC 1932 IP over ATM: A Framework Document April 1996
o How can routing be optimized across multiple logical IP
over both a common ATM based and a non-ATM based infrastructure
For example, in Figure 3, there are two gateways/routers
the non-ATM subnet and the ATM subnets. The optimal
from end-systems on any ATM-based subnet to the non ATM-
subnet is a function of the routing state information of the
routers
o How to incorporate policy routing constraints
o What is the proper coupling between routing and
resolution particularly with respect to off-subnet communication
o What are the local procedures to be followed by hosts
routers
o Routing between hosts not sharing a common IP-level (or L3)
network prefix, but able to be directly connected at the
media level
o Defining the details for an efficient address
architecture including defining the procedures to be followed
clients and servers (see RFC-1433 [5], RFC-1735 [7] and NHRP).
o How to identify the need for and accommodate special purpose
for control or routing and high bandwidth data transfers
For ATM (unlike other NBMA media), an additional complexity
supporting IP routing over these ATM internets lies in
multiplicity of address formats in UNI 3.0 [4]. NSAP modeled
formats only are supported on "private ATM" networks, while either 1)
E.164 only, 2) NSAP modeled formats only, or 3) both are supported
"public ATM" networks. Further, while both the E.164 and
modeled address formats are to be considered as network points
attachment, it seems that E.164 only networks are to be considered
subordinate to "private networks", in some sense. This leads to
confusion in defining an ARP mechanism in supporting all
of end-to-end scenarios (refer to the discussion in Appendix A on
possible scenarios to be supported by ARP).
7. Extensions to IP
RFC-1620 [3] describes the problems and issues associated with
connections across IP subnet boundaries in greater detail, as well
possible solution approaches. The ROLC WG has identified
routing loop problems that can occur if protocols which
information critical to path vector routing protocol loop
are used to accomplish direct connections across IP
Cole, Shur & Villamizar Informational [Page 18]
RFC 1932 IP over ATM: A Framework Document April 1996
boundaries
The problems may arise when a destination network which is not on
NBMA network is reachable via different routers attached to the
network. This problem occurs with proposals that attempt to
reachability information, but do not carry full path attributes (
path vector routing) needed for inter-AS path suppression, or
metrics (for distance vector or link state routing even if
vector routing is not used) for intra-AS routing
For example, the NHRP protocol may be used to support
establishment of direct connections across subnetwork boundaries
NHRP assumes that routers do run routing protocols (intra and/
inter domain) and/or static routing. NHRP further assumes
forwarding tables constructed by these protocols result in a
state loop-free forwarding. Note that these two assumptions do
impose any additional requirements on routers, beyond what
required in the absence of NHRP
NHRP runs in addition to routing protocols, and provides
information that allows the elimination of multiple IP hops (
multiple IP hops result from the forwarding tables constructed by
routing protocols) when traversing an NBMA network. The IPATM
ROLC WGs have both expended considerable effort in discussing
coming to understand these limitations
It is well-known that truncating path information in Path
protocols (e.g., BGP) or losing metric information in Distance
protocols (e.g., RIP) could result in persistent forwarding loops
These loops could occur without ATM and without NHRP
The combination of NHRP and static routing alone cannot be used
some topologies where some of the destinations are served by
routers on the NBMA. The combination of NHRP and an intra-AS
protocol that does not carry inter-AS routing path attributes
cannot be used in some topologies in which the NBMA will
inter-AS transit connectivity to destinations from other AS served
multiple routers on the NBMA
Figure 4 provides an example of the routing loops that may be
in these circumstances. The example illustrates how the use of
in the environment where forwarding loops could exist even
NHRP (due to either truncated path information or loss of
information) would still produce forwarding loops
There are many potential scenarios for routing loops. An example
given in Figure 4. It is possible to produce a simpler example
a loop can form. The example in Figure 4 illustrates a loop
Cole, Shur & Villamizar Informational [Page 19]
RFC 1932 IP over ATM: A Framework Document April 1996
will persist even if the protocol on the NBMA supports redirects
can invalidate any route which changes in any way, but does
support the communication of full metrics or path attributes
.----. .----.
: H1 >----< S1 : Notes
---- vvvv H#n == host #
/ : \ R#n == router #
/ : \ S#n == subnet #
/------/ : \
: : \ S2 to R3
.--^---. .----. .-^--.
: : : R4 : : R6 :
: NBMA : --v- --v- See the text
: : : : details of
-v--v- = = looping
: \ = SLOW = and
: .-^--. = LINK =
: : R2 : = =
: --v- : :
: : .--^-. .--^-.
.-^--. : : R5 : : R7 :
: R8 : : --v- --v
--v- \ : :
: \ / :
\ .-^^-. .--^-.
\ : S2 : : S4 :
\ --v- --v
\ \ /
\ \ /
\ .^--^.
\ : R3 : path before the break
\ -v-- H1->S1->R1->NBMA->R2->S2->R3->H
\ /
.----. .-^^-. path after the break
: H2 >---< S3 : H1->S1->R1->NBMA->R2->S2->R5->R4->S
---- ---- \------<--the-loop--<-------/
Figure 4: A Routing Loop Due to Lost PV Routing Attributes
In the example in Figure 4, Host 1 is sending traffic toward Host 2.
In practice, host routes would not be used, so the destination
the purpose of routing would be Subnet 3. The traffic travels by
of Router 1 which establishes a "cut-through" SVC to the NBMA next
hop, shown here as Router 2. Router 2 forwards traffic destined
Subnet 3 through Subnet 2 to Router 3. Traffic from Host 1
then reach Host 2.
Cole, Shur & Villamizar Informational [Page 20]
RFC 1932 IP over ATM: A Framework Document April 1996
Router 1's cut-through routing implementation caches an
between Host 2's IP address (or more likely all of Subnet 3)
Router 2's NBMA address. While the cut-through SVC is still up,
1 fails. Router 5 loses it's preferred route through Router 3
must direct traffic in the other direction. Router 2 loses a
through Router 3, but picks up an alternate route through Router 5.
Router 1 is still directing traffic toward Router 2 and advertising
means of reaching Subnet 3 to Subnet 1. Router 5 and Router 2
see a route, creating a loop
This loop would not form if path information normally carried
interdomain routing protocols such as BGP and IDRP were
across the NBMA. Router 2 would reject the initial route from
5 due to the path information. When Router 2 declares the route
Subnet 3 unreachable, Router 1 withdraws the route from routing
Subnet 1, leaving the route through Router 4, which would then
Router 5, and would reach Router 2 through both Router 1 and
5. Similarly, a link state protocol would not form such a loop
Two proposals for breaking this form of routing loop have
discussed. Redirect in this example would have no effect,
Router 2 still has a route, just has different path attributes.
second proposal is that is that when a route changes in any way,
advertising NBMA cut-through router invalidates the advertisement
some time period. This is similar to the notion of Poison Reverse
distance vector routing protocols. In this example, Router 2
eventually readvertise a route since a route through Router 6 exists
When Router 1 discovers this route, it will advertise it to Subnet 1
and form the loop. Without path information, Router 1
distinguish between a loop and restoration of normal service
the link L1.
The loop in Figure 4 can be prevented by configuring Router 4
Router 5 to refuse to use the reverse path. This would break
connectivity through Router 8 if L1 and L3 failed. The loop can
be broken by configuring Router 2 to refuse to use the path
Router 5 unless it could not reach the NBMA. Special configuration
Router 2 would work as long as Router 2 was not distanced from
3 and Router 5 by additional subnets such that it could not
which path was in use. If Subnet 1 is in a different AS or RD
Subnet 2 or Subnet 4, then the decision at Router 2 could be based
path information
Cole, Shur & Villamizar Informational [Page 21]
RFC 1932 IP over ATM: A Framework Document April 1996
.--------. .--------.
: Router : : Router :
--v-v--- ---v-v--
: : : :
.--------. .--------. : : .--------. : : .--------. .--------.
: Sub-ES :---: Subnet :-/ \-: Subnet :-/ \-: Subnet :---: Sub-ES :
-------- -------- -------- -------- --------
Figure 5: The Classical IP model as a concatenation of three
ATM IP subnets
In order for loops to be prevented by special configuration at
NBMA border router, that router would need to know all paths
could lead back to the NBMA. The same argument that
configuration could overcome loss of path information was posed
favor of retaining the use of the EGP protocol defined in the
historic RFC-904 [11]. This turned out to be unmanageable,
routing problems occurring when topology was changed elsewhere
8. IP Over ATM
8.1 The Classical IP
The Classical IP Model was suggested at the Spring 1993 IETF
[8] and retains the classical IP subnet architecture. This
simply consists of cascading instances of IP subnets with IP-
(or L3) routers at IP subnet borders. An example realization of
model consists of a concatenation of three IP subnets. This is
in Figure 5. Forwarding IP packets over this Classical IP model
straight forward using already well established routing
and protocols
SVC-based ATM IP subnets are simplified in that they
o limit the number of hosts which must be directly connected at
given time to those that may actually exchange traffic
o The ATM network is capable of setting up connections
any pair of hosts. Consistent with the standard IP
algorithm [2] connectivity to the "outside" world is
only through a router, which may provide firewall
if so desired
o The IP subnet supports an efficient mechanism for
resolution
Issues addressed by the IP Over ATM Working Group, and some of
resolutions, for this model are
Cole, Shur & Villamizar Informational [Page 22]
RFC 1932 IP over ATM: A Framework Document April 1996
o Methods of encapsulation and multiplexing. This issue
addressed in RFC-1483 [6], in which two methods of
are defined, an LLC/SNAP and a per-VC multiplexing option
o The definition of an address resolution server (defined
RFC-1577).
o Defining the default MTU size. This issue is addressed
RFC-1626 [1] which proposes the use of the MTU
protocol (RFC-1191 [9]).
o Support for IP multicasting. In the summer of 1994, work
on the issue of supporting IP multicasting over the SVC
model. The proposal for IP multicasting is currently defined
a set of IP over ATM WG Works in Progress, referred to
as the IPMC documents. In order to support IP multicasting
ATM subnet must either support point-to- multipoint SVCs,
multicast servers, or both
o Defining interim SVC parameters, such as QoS parameters
time-out values
o Signaling and negotiations of parameters such as MTU
and method of encapsulation. RFC-1755 [10] describes
implementation agreement for routers signaling the ATM
to establish SVCs initially based upon the ATM Forum's
version 3.0 specification [4], and eventually to be
upon the ATM Forum's UNI version 3.1 and later specifications
Topics addressed in RFC-1755 include (but are not limited to
VC management procedures, e.g., when to time-out SVCs,
parameters, service classes, explicit setup message formats
various encapsulation methods, node (host or router) to
negotiations, etc
RFC-1577 is also applicable to PVC-based subnets. Full mesh
connectivity is required
For more information see RFC-1577 [8].
8.2 The ROLC NHRP
The Next Hop Resolution Protocol (NHRP), currently a work in
defined by the Routing Over Large Clouds Working Group (ROLC),
performs address resolution to accomplish direct connections
IP subnet boundaries. NHRP can supplement RFC-1577 ARP. There
been recent discussion of replacing RFC-1577 ARP with NHRP. NHRP
also perform a proxy address resolution to provide the address of
border router serving a destination off of the NBMA which is
Cole, Shur & Villamizar Informational [Page 23]
RFC 1932 IP over ATM: A Framework Document April 1996
served by a single router on the NBMA. NHRP as currently
cannot be used in this way to support addresses learned from
for which the same destinations may be heard at other routers
without the risk of creating persistent routing loops
8.3 "Conventional"
The "Conventional Model" assumes that a router can relay IP
cell by cell, with the VPI/VCI identifying a flow between
routers rather than a flow between a pair of nodes. A
advantage can be provided if cell interleaving from multiple
packets is allowed. Interleaving frames within the same VCI
an ATM AAL such as AAL3/4 rather than AAL5. Cell forwarding
accomplished through a higher level mapping, above the ATM VCI layer
The conventional model is not under consideration by the IP/ATM WG
The COLIP WG has been formed to develop protocols based on
conventional model
8.4 The Peer
The Peer Model places IP routers/gateways on an addressing peer
with corresponding entities in an ATM cloud (where the ATM cloud
consist of a set of ATM networks, inter-connected via UNI or P-
interfaces). ATM network entities and the attached IP hosts
routers exchange call routing information on a peer basis
algorithmically mapping IP addressing into the NSAP space.
the ATM cloud, ATM network level addressing (NSAP-style),
routing and packet formats are used
In the Peer Model no provision is made for selection of primary
and use of alternate paths in the event of primary path failure
reaching multihomed non-ATM destinations. This will limit
topologies for which the peer model alone is applicable to only
topologies in which non-ATM networks are singly homed, or where
of backup connectivity is not an issue. The Peer Model may be
to avoid the need for an address resolution protocol and in a proxy
ARP mode for stub networks, in conjunction with other
suitable to handle multihomed destinations
During the discussions of the IP over ATM working group, it was
that the problems with the end-to-end peer model were much
than any other model, and had more unresolved technical issues
While encouraging interested individuals/companies to research
area, it was not an initial priority of the working group to
these issues. The ATM Forum Network Layer Multiprotocol
Group has reached a similar conclusion
Cole, Shur & Villamizar Informational [Page 24]
RFC 1932 IP over ATM: A Framework Document April 1996
8.5 The PNNI and the Integrated
The Integrated model (proposed and under study within
Multiprotocol group of ATM Forum) considers a single routing
to be used for both IP and for ATM. A single routing
exchange is used to distribute topological information. The
computation used to calculate routes for IP will take into
the topology, including link and node characteristics, of both the
and ATM networks and calculates an optimal route for IP packets
the combined topology
The PNNI is a hierarchical link state routing protocol with
link metrics providing various available QoS parameters given
loading. Call route selection takes into account QoS requirements
Hysteresis is built into link metric readvertisements in order
avoid computational overload and topological hierarchy serves
subdivide and summarize complex topologies, helping to
computational requirements
Integrated Routing is a proposal to use PNNI routing as an IP
protocol. There are several sets of technical issues that need to
addressed, including the interaction of multiple routing protocols
adaptation of PNNI to broadcast media, support for NHRP, and others
These are being investigated. However, the ATM Forum MPOA group
not currently performing this investigation. Concerned
are, with an expectation of bringing the work to the ATM Forum
the IETF
PNNI has provisions for carrying uninterpreted information.
not yet defined, a compatible extension of the base PNNI could
used to carry external routing attributes and avoid the routing
problems described in Section 7.
Cole, Shur & Villamizar Informational [Page 25]
RFC 1932 IP over ATM: A Framework Document April 1996
++++++++++++++++++++++++++++++++++++++++++
+ .------------. .------------. +
.---------. + .-: :-. .-: :-. +
: Host or >-+-< : Single ATM : >--< : Single ATM : >-+-----\
: Router : + : : Domain : : : : Domain : : + :
--------- + -: :- -: :- + .---^----.
+ ------------ ------------ + : Router :
+ .------------. + ---v----
.---------. + .-: :-. + :
: Host or >-+- ... ... --< : Single ATM : >-+-----/
: Router : + : : Domain : : +
--------- + ATM Cloud -: :- +
+ ------------ +
++++++++++++++++++++++++++++++++++++++++++
Note: IS within ATM cloud are ATM
Figure 6: The ATM transition model assuming the presence of
or routers between the ATM networks and the ATM peer networks
8.6 Transition
Finally, it is useful to consider transition models, lying
between the Classical IP Models and the Peer and Integrated Models
Some possible architectures for transition models have been
by Fong Liaw. Others are possible, for example Figure 6 showing
Classical IP transition model which assumes the presence of
between ATM networks and ATM Peer networks
Some of the models described in the prior sections, most notably
Integrated Model, anticipate the need for mixed environment
complex routing topologies. These inherently support
(possibly with an indefinite transition period). Models
provide no transition support are primarily of interest to
deployments which make exclusive, or near exclusive use of ATM
deployments capable of wholesale replacement of existing networks
willing to retain only non-ATM stub networks
For some models, most notably the Peer Model, the ability to
to a large non-ATM or mixed internetwork is infeasible
routing support at a higher level, or at best may
interconnection topology constraints (for example: single point
attachment and a static default route). If a particular
requires routing support at a higher level a large deployment
need to be subdivided to provide scalability at the higher level
which for some models degenerates back to the Classical model
Cole, Shur & Villamizar Informational [Page 26]
RFC 1932 IP over ATM: A Framework Document April 1996
9. Application of the Working Group's and Related
The IP Over ATM Working Group has generated several Works in
and RFCs. This section identifies the relationship of these
other related documents to the various IP Over ATM Models
in this document. The documents and RFCs produced to date are
following references, RFC-1483 [6], RFC-1577 [8], RFC-1626 [1], RFC
1755 [10] and the IPMC documents. The ROLC WG has produced the
document. Table 5 gives a summary of these documents and
relationship to the various IP Over ATM Models
This memo is the direct result of the numerous discussions of the
over ATM Working Group of the Internet Engineering Task Force.
authors also had the benefit of several private discussions with H
Nguyen of AT&T Bell Laboratories. Brian Carpenter of CERN was
enough to contribute the TULIP and TUNIC sections to this memo
Grenville Armitage of Bellcore was kind enough to contribute
sections on VC binding, encapsulations and the use of B-
information elements to signal such bindings. The text of Appendix
was pirated liberally from Anthony Alles' of Cisco posting on the
over ATM discussion list (and modified at the authors' discretion).
M. Ohta provided a description of the Conventional Model (again
the authors modified at their discretion). This memo also
benefitted from numerous suggestions from John T. Amenyo of ANS,
Halpern of Newbridge, and Andy Malis of Ascom-Timplex. Yakov
of Cisco provided valuable comments leading to the clarification
normal loop free NHRP operation and the potential for routing
problems only with the improper use of NHRP
Documents
----------------+-------------------------------------------------
RFC-1483 _ How to identify/label
_ packet/frame-based protocols multiplexed
_ ATM AAL5. Applies to any model dealing with
_ over ATM AAL5.
_
RFC-1577 _ Model for transporting IP and ARP over ATM AAL
_ in an IP subnet where all nodes share a
_ IP network prefix. Includes ARP server/Inv-
_ packet formats and procedures for SVC/
_ subnets
_
RFC-1626 _ Specifies default IP MTU size to be used
_ ATM AAL5. Requires use of PATH MTU discovery
_ Applies to any model dealing with IP over
_ AAL
Cole, Shur & Villamizar Informational [Page 27]
RFC 1932 IP over ATM: A Framework Document April 1996
_
RFC-1755 _ Defines how implementations of IP over
_ should use ATM call control
_ procedures, and recommends values of
_ and optional IEs focusing particularly on
_ Classical IP model
_
IPMC _ Defines how to support IP multicast in
_ IP model using either (or both) meshes
_ point-to-multipoint ATM VCs, or
_ server(s). IPMC is work in progress
_
NHRP _ Describes a protocol that can be used by
_ and routers to determine the NBMA next
_ address of a destination in "
_ connectivity
_ of the sending node. If the destination is
_ connected to the NBMA fabric, the IP and
_ addresses of preferred egress points
_ returned. NHRP is work in progress (ROLC WG).
Table 5: Summary of WG
[1] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626,
Naval Research Laboratory, May 1994.
[2] Braden, R., and J. Postel, "Requirements for Internet Gateways",
STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.
[3] Braden, R., Postel, J., and Y. Rekhter, "Internet
Extensions for Shared Media", RFC 1620, USC/Information
Institute, IBM Research, May 1994.
[4] ATM Forum, "ATM User-Network Interface Specification",
Hall, September 1993.
[5] Garrett, J., Hagan, J., and J. Wong, "Directed ARP", RFC 1433,
AT&T Bell Labs, University of Pennsylvania, March 1993.
[6] Heinanen, J., "Multiprotocol Encapsulation over ATM
Layer 5", RFC 1483, Telecom Finland, July 1993.
[7] Heinanen, J., and R. Govindan, "NBMA Address Resolution
(NARP)", RFC 1735, Telecom Finland, USC/Information
Institute, December 1994.
Cole, Shur & Villamizar Informational [Page 28]
RFC 1932 IP over ATM: A Framework Document April 1996
[8] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
Hewlett-Packard Laboratories, January 1994.
[9] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
DECWRL, Stanford University, November 1990.
[10] Perez, M., Liaw, F., Grossman, D., Mankin, A., and A. Hoffman
"ATM signalling support for IP over ATM", RFC 1755,
USC/Information Sciences Institute, FORE Systems, Inc.,
Codex, Ascom Timeplex, Inc., January 1995.
[11] Mills, D., "Exterior Gateway Protocol Formal Specification",
STD 18, RFC 904, BBN, April 1984.
A Potential Interworking Scenarios to be Supported by
The architectural model of the VC routing protocol, being defined
the Private Network-to-Network Interface (P-NNI) working group of
ATM Forum, categorizes ATM networks into two types
o Those that participate in the VC routing protocols and use
modeled addresses UNI 3.0 [4] (referred to as private networks
for short),
o Those that do not participate in the VC routing protocol
Typically, but possibly not in all cases, public ATM
that use native mode E.164 addresses UNI 3