Internet Engineering Task Force R. G. Cole and D. Shur
INTERNET-DRAFT AT&T Bell Laboratories
Expires August 17, 1995 February 17, 1995
<draft-ietf-atm-framework-doc-01.txt>
IP over ATM: A Framework Document
Status of this Memo
This document is an internet draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress". Please check the lid-abstracts.txt listing
contained in the internet-drafts shadow directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to
learn the current status of any Internet Draft.
1 Abstract
The discussions of the IP over ATM working group over the last
several years are summarized. The summary is provided in the form
of a framework which categorizes the various ATM subnet models and
End-to-End models identified and deemed of primary interest by the IP
over ATM working group. The intent of this framework was, and still
is, to help partition the efforts of the working group in order to
focus on smaller, more manageable aspects of IP over ATM. This is
necessary due to the number of ATM sub-networks and End-to-End types
being discussed. A second goal of this document is to serve as an
introduction to and overview of the area of IP and ATM interworking.
In summary, it is hoped that this document, in classifying the
sub-network and end-to-end models, has helped (and will continue to
help) in focusing the IP over ATM working group's direction.
The subnet models identified in this memo are:
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
o an SVC-based LAN ATM (LATM) subnet, and
o a PVC-based WAN ATM (WATM) subnet.
The end-to-end models identified in this memo are:
o the Classical IP model,
o Ohta's "Conventional" model,
o the SVC-based WATM (ROLC) model,
o the Integrated Model and
o the Peer Model.
2 Introduction
The IP over ATM Working Group of the Internet Engineering Task Force
(IETF) is chartered to develop standards for routing and forwarding IP
packets over ATM sub-networks. There are several difficulties with
this charter, as evidenced by the discussions of this group over the
last several years. Firstly, the work activity of the group has
depended on a technology (asynchronous transfer mode (ATM)) undergoing
ongoing development and definition. Secondly, the flexibility of
ATM, allows for and in fact encourages the technology to be used
in different network/subnetwork arrangements, e.g., a LAN, a WAN, an
Internet, etc. Therefore, much of the discussions of the IP over
ATM working group have centered around not only how to carry IP
traffic over ATM subnetworks, but what is the appropriate view of
ATM in the context of IP internetworking. This document attempts
to highlight some of these discussions and tries to categorize the
various ATM subnet architectures and end-to-end architectures that
have been proposed.
We first discuss the types of ATM subnets, and then the end-to-end
models to be addressed. An appropriately chosen classification/
taxonomy of the various ATM subnet and end-to-end models enables the
issues pertaining to particular models to be worked independently.
This allows progress to be made in defining IP routing over some ATM
subnet types and simpler end-to-end models, without having to resolve
fundamental architectural issues in other more complex or vaguely
defined models, e.g., peer end-to-end models. Furthermore, the
classifying of the subnet and end-to-end models and the enumeration of
the associated issues should help in focusing the IP over ATM working
group's future direction.
Cole, Shur Expires August 17, 1995 [Page 2]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
The remainder of this memorandum is organized as follows:
o Section 3 defines several terms relating to networking and
internetworking,
o Section 4 discusses the parameters for a taxonomy of the
different ATM subnet and end-to-end networking models to be
defined,
o Section 5 discusses/identifies the various subnet models proposed
to date by the IP over ATM working group,
o Section 6 identifies several prominent end-to-end networking
configurations,
o Section 7 addresses the relationship between the documents
developed in the IP over ATM working group and the various models
discussed, and
o Section 8 contains conclusions.
3 Definitions and Terminology
We define several terms:
A Host or End System (ES) delivers/receives IP packets to/from other
systems, but does not relay IP packets.
A Router or Intermediate System (IS) delivers/receives IP packets
to/from other systems, and relays IP Packets among systems. A
router may route packets to hosts within its own area and to
other routers when the destination is within another area.
A Subnet is a connected communication network consisting of a single
networking technology in which the hosts connected to the subnet
share a common IP level 3 network address. Subnets are further
categorized into broadcast and non-broadcast multiple access
subnetworks.
A Broadcast (Multicast) Subnet supports an arbitrary number of hosts
and routers and additionally is capable of transmitting a single
IP packet to all (a subset) of these systems.
A Non-Broadcast Multiple Access (NBMA) Subnet supports an arbitrary
number of hosts and routers but does not support a convenient
multi-destination connectionless transmission facility, as does a
Cole, Shur Expires August 17, 1995 [Page 3]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
Figure 1: A Single Hop configuration between Subnet End Systems
(Sub-ES) attached to the same subnet
broadcast subnetwork.
An End-to-End path consists of two hosts which can communicate with
one another over an arbitrary number of routers and subnets.
From the perspective of the subnet, in many cases there is no
difference between the hosts and routers. Therefore, we will define a
Subnet End System (Sub-ES) as a network level entity connected to the
subnet, either a host or router. Figure 1 shows two Sub End Systems
connected over a single subnet. An IP-level (or L3 level) end-to-end
path can be considered as a concatenation of multiple IP-level (or L3)
single hop paths.
A model of a subnet describes the key characteristics and operational
features of the subnet technology used in performing the functions
required of an IP subnet.
An end-to-end model describes the key aspects, structure and
operational features required to provide connectivity among a given
set of Sub-End-Systems, possibly located on different sub-networks.
Cole, Shur Expires August 17, 1995 [Page 4]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
4 ATM Aspects Affecting Subnet and End-to-End Models
4.1 ATM Parameters Defining Subnet Models
In general, each subnet technology may be characterized in terms
of many parameters. In the previous section, we have defined
two subnet types, i.e. a broadcast and a general topology,
or NBMA, subnet. It is possible to specify additional subnet
types beyond these broad categories. In this section we present
the major parameters/attributes for a taxonomy of the various ATM
subnet models discussed in the remainder of this document. The
parameters/attributes chosen correspond to those aspects of ATM
networks that, when overlaid with IP, and in order to provide standard
IP services, require interworking functionality to be provided or
particular ATM services to be selected. There are some attributes
which play an important role in network models in general (e.g.,
geographical dispersion, the number of nodes, the number of routers
present, etc.) that will not be explicitly highlighted in the
taxonomy below since they are not specific to ATM. However, as will be
seen in the following sections, the latter attributes do influence the
both subnet and end-to-end models.
The ATM-specific attributes considered are:
o The different types of services provided by the ATM Adaptation
Layers (AAL). These specify whether a connection oriented or a
connectionless service is provided, the Quality-of-Service, the
connection-mode, etc. The models discussed within this document
assume connection-oriented, best effort services over AAL Type 5.
o The type of virtual circuits used, i.e., PVCs versus SVCs. The
PVC environment requires the use of either static tables for
ATM-to-IP address mapping or the use of inverse ARP, while the
SVC environment requires ARP functionality to be provided.
o The type of support for multicast services. If point-to-point
services only are available, then a server for IP multicast is
required. If point-to-multipoint services are available, then
IP multicast can be supported via meshes of point-to-multipoint
connections (although use of a server may be necessary due to
limits on the number of multipoint VCs able to be supported).
o The presence of logical link identifiers (VPI/VCIs) and the
various information element (IE) encodings within the ATM SVC
signaling specification, i.e., the ATM Forum UNI version 3.1.
This allows a VC originator to specify a range of "layer"
entities as the destination "AAL User". The AAL specifications
Cole, Shur Expires August 17, 1995 [Page 5]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
do not prohibit any particular "layer X" from attaching directly
to a local AAL service. Taken together these points imply a
range of methods for encapsulation of upper layer protocols over
ATM. For example, while LLC/SNAP encapsulation is one approach
(the default), it is also possible to bind virtual 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 Appendix A.
o The number and type of ATM administrative domains/networks, and
type of addressing used within an administrative domain/network.
In particular, in the single domain/network case, all attached
systems may be safely assumed to be using a single common
addressing format, while in the multiple domain case, attached
stations may not all be using the same common format,
with corresponding implications on address resolution. (See
Appendix A for a discussion of some of the issues that arise
when multiple ATM address formats are used in the same logical
IP subnet (LIS).) Also security/authentication is much more of a
concern in the multiple domain case.
4.2 Aspects of ATM influencing End-to-end Models
The above discussion implies that within an ATM-based subnet
architected along traditional lines, significant questions/issues
arise. There are also aspects which are stimulating or reviving
the development of alternative end-to-end models that differ from the
traditional or "Classical IP" model. Two such aspects are:
o The assumption of widespread deployment of ATM within both
premises-based LANs and wide-area networks, and
o The definition of interfaces, signaling and routing protocols
among private ATM networks.
The ROLC model (not necessarily specific to ATM) would be particularly
appropriate to the case of ubiquitous ATM deployment. It preserves
routing control in the IP domain, but permits "short-cut" transport
in the ATM domain. In an environment with ATM-level routing
among private ATM-based networks, Peer Models allow the IP and ATM
routing protocols to interact as peers. The "integrated" model
allows IP-level routing protocols to obtain and utilize information
pertaining to ATM-level routing. These end-to-end models are
discussed in more detail in section 6.
Cole, Shur Expires August 17, 1995 [Page 6]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
5 Classification of ATM Subnets
Several ATM subnets have been discussed by the IP over ATM working
group. These range from the (wide-area) Broadband-Integrated Services
Digital Network (B-ISDN) subnet originally proposed and being defined
by inter-exchange carriers to Local ATM (LATM) subnets, currently
being defined by computer and LAN networking vendors. Furthermore,
other subnets are defined over ATM as overlay subnets, e.g. Frame
Relay over ATM, and 802.3 and 802.5 LANs over ATM, the latter being
developed through the LAN emulation activities in the ATM Forum.
In this document, we identify and discuss two ATM subnets: an
SVC-based LAN-ATM (LATM) subnet, and a PVC-based WAN-ATM (WATM)
subnet.
5.1 The SVC-based LATM Subnet Model
The SVC-based LAN-ATM (LATM) subnet is characterized as having a large
number of hosts, e.g., up to at most a few thousand (but typically
fewer). The main characteristics of and assumptions underlying this
subnet are listed below:
o Hosts
o are directly connected,
o share a common IP-level (or L3) network prefix,
o support switched virtual connections (SVCs),
o are part of a single administrative group, and security is not an
issue.
o The subnet supports an efficient mechanism for address
resolution,
o The ATM network is capable of setting up connections between any
pair of hosts.
o Consistent with the standard IP routing algorithm RFC--1009 [3]
connectivity to the "outside" world is achieved only through a
router, which may provide firewall functionality if so desired
o Billing for virtual circuit holding time, or any other usage
based measure is assumed to be not an issue.
Cole, Shur Expires August 17, 1995 [Page 7]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
For hosts to forward packets over this subnet, many of the mechanisms
for forwarding IP packets over ethernet subnets apply and are
presented in RFC--1577 [11]. Some of the issues that need to be
addressed for this model are:
o The definition of an address resolution server. (Many internal
architectures are possible ranging from a broadcast capability to
the existence of an ARP server. RFC--1577 [11] utilizes the ARP
server option, and also specifies administrative procedures.
o Defining the maximum MTU size, (This had been the subject
considerable debate over the Internet in the spring of 1993.
This issue is addressed in RFC--1626 [2].)
o Methods of encapsulation and multiplexing, (This was actually
the first issue addressed by the group. The group struggled
for a year between the LLC/SNAP encapsulation, supported over
the majority of subnet types, and the NLPID encapsulation, to
ease frame relay to ATM interworking. The LLC/SNAP, and a null
encapsulation, were decided upon and are discussed in RFC--1483
[8].)
o Reliability of the ARP server mechanism defined in RFC--1577
[11],
o Management and signalling of SVCs, such as
-- Defining SVC optimization techniques (e.g., time-out
mechanisms), and
-- Support for IP multicasting, and
-- Special purpose SVCs for control/routing and high bandwidth
data transfers.
Much effort has gone into defining the interface between the Sub-ESs
and the LATM, e.g., what VPI/VCIs to be used to access the ARP server,
ATM ARP message formats RFC--1577 [11], the method of encapsulation
RFC--1483 [8], the maximum MTU sizes RFC--1626 [2], signalling
capabilities RFC--1755 [13], etc. However, other work items have
consisted of internal architectural issues such as the architectures
for ARP multicast services.
As already mentioned, several of these issues have been substantially
resolved. RFC--1577 [11] defines an ARP server architecture for
the SVC-capable LATM model. RFC--1483 [8] defines two methods
of multiprotocol encapsulation, a default encapsulation based on
LLC/SNAP and another based upon a null encapsulation (supporting a
Cole, Shur Expires August 17, 1995 [Page 8]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
single, higher level protocol per ATM VCI). RFC--1626 [2] defines
the use of the MTU discovery protocol RFC--1191 [12] for ATM
subnetworks. RFC--1755 [13] describes an implementation agreement
for routers signaling the ATM subnet to establish SVCs initially
based upon the ATM Forum's UNI version 3.0 specification [14] and
eventually to be based upon the ATM Forum's UNI version 3.1 and
later specifications. Topics addressed in RFC--1755 [13] include
(but are not limited to) VC management procedures, e.g., when
to time-out SVCs, QOS parameters, service classes, explicit setup
message formats for various encapsulation methods, Sub-ES to Sub-ES
negotiations, etc. In the summer of 1994, work began on the issue
of supporting IP multicasting over the SVC LATM model. The proposal
for IP multicasting is found in IPMC [1]. In order to support IP
multicasting the ATM subnet must either support point-to-multipoint
SVCs, or multicast servers, or both.
Outstanding issues, not yet fully discussed, include security over
ATM SVC subnets (which would likely require the existence of a
user information element used to convey security and authentication
information), support for ATM QOS (although this should likely be
deferred until the meaning of the Flow ID in IPv6 is defined), and the
reliability of the ARP-server architecture.
5.2 The PVC-based WATM Subnet Model
The PVC-based WATM is a NBMA subnet which is further characterized as
having a moderate number of hosts, e.g., up to at most a few tens or
hundreds, which:
o are all directly connected,
o share a common IP-level (or L3) network prefix,
o support permanent virtual connections (PVCs),
o do not have to support an efficient broadcast/multicast/connectionless
server for address resolution, and
o may or may not be part of a single administrative group (however,
even if not part of the same administrative group, security
is not an issue due to the permanent nature of the virtual
connections).
For hosts to forward packets over this subnet, many of the mechanisms
defined for forwarding IP packets over Frame Relay subnets apply, see
RFC--1490 [6]. Specific issues are:
Cole, Shur Expires August 17, 1995 [Page 9]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
o Defining the details for an Inv-ARP like address resolution,
(Strictly, Inv-ARP is defined for general PVC-based NBMA subnets,
see RFC--1293 [5] and RFC--1577 [11].)
o Methods of encapsulation and multiplexing, (This issue is
addressed in RFC--1483 [8].)
o Defining the maximum MTU size, (This issue is addressed in
RFC--1626 [2].) and
o Support for IP multicasting.
The majority of the issues (except for multicasting) have been
addressed by the working group.
6 End-to-End Networking Configurations
Several end-to-end ATM configurations have been proposed, most
constructed by cascading gateways and different ATM subnet models.
Other more radical models have been proposed which replace the
traditional IP subnet architecture by an ATM Internet model. We
categorize these different models in terms of whether the ATM network
and IP-level (or L3) routers are considered as peers, i.e. they
exchange routing information, or not, i.e. the IP-level (or L3)
routers treat the ATM network as a lower-level subnet. We will refer
to these as Peer Models and Subnet Models, respectively, and discuss
each separately below.
Clearly the Subnet Models follow the traditional IP networking
architectures, whereas the Peer Models propose a new way of
internetworking. Due to this, the consensus of the group was that
the problems with the end-to-end peer models were much harder than
any of the other models, and had more unresolved technical issues.
While encouraging interested individuals/companies to research this
area, it was not the priority of the IP over ATM working group to
address these difficulties. More recently, discussions of peer models
have been revived in the ATM Forum's Network Layer Multiprotocol
sub-working group (see below). We now describe End-to-End models
starting with the Classical IP model, followed by the remaining models
ordered according to the degree of departure from the classical IP
architecture.
Cole, Shur Expires August 17, 1995 [Page 10]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
Figure 2: The Classical IP model as a concatenation of three separate
ATM subnets; two SVC LATM subnets and a single PVC WATM subnet.
6.1 The Classical IP Model
The Classical IP Model was suggested at the Spring 1993 IETF meeting
RFC--1577 [11] and retains the classical IP subnet architecture. This
model simply consists of cascading instances of the two subnet models
discussed in the previous section with IP-level (or L3) routers. A
example realization of this model consists of a concatenation of two
(simplified) LATMs and a PVC-based WATM subnet. This is shown in
Figure 2. Once the details of specifying routing and forwarding IP
packets over the component subnets are complete, routing IP packets
over this Classical IP model is straight forward. The LATMs are
simplified in that they:
o support a single subnetwork point of attachment (SNPA) address
format (four allowed address formats are specified in UNI 3.0
[14],
o support a single default MTU size, and
o support a default LLC/SNAP encapsulation as specified in
RFC--1483 [8].
For more information see RFC--1577 [11].
Cole, Shur Expires August 17, 1995 [Page 11]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
6.2 Ohta's "Conventional" Model
The conventional model is layered and has the same network layer
architecture as the standard IP model, hence it retains the IP
subnet architecture. At the link layer, all types of ATM subnets
are allowed. The basic difference between the Classical and the
"Conventional" model is whether it is assumed that a router can relay
IP packets cell by cell or not. Link layers are connected by
routers but, when the two link layers are ATM, the routers are capable
of forwarding cell-by-cell. This could provide a latency advantage
depending on whether cell interleaving from multiple IP packets is
allowed or not (e.g., an ATM AAL such as AAL3/4 would allow for
cell interleaving, while AAL5 would not). This cell forwarding is
accomplished through a higher level mapping, above the ATM VCI layer.
6.3 The SVC-based WATM Configuration (ROLC model)
The SVC-based WATM is a NBMA network which may be part of a larger
Internet, consisting of similar SVC-based WATM networks (which are
not inter-connected at the ATM level) as well as Classical IP style
subnets. While there is no particular restriction on the number
of end systems, it is believed that this model is most useful for
large number of end systems, e.g., up to at most a few hundreds of
thousands, which
o Support switched virtual connections (SVCs) as well as permanent
virtual connections (PVCs),
o May be directly connected, due to the existence of SVCs,
o Do not all necessarily share a common IP-level (or L3) network
prefix,
o Support multiple subnetwork point of attachment (SNPA) address
formats (four possible formats are allowed in UNI 3.0 [14]),
o Support negotiations for parameters such as MTU size, methods of
encapsulation,
o Does not support an efficient broadcast/multicast mechanism for
address resolution,
o Is not part of a single administrative group and hence security
is an issue, and
o May be billed for circuit holding time.
Cole, Shur Expires August 17, 1995 [Page 12]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
Figure 3: An SVC-based WATM configuration between End Systems which
in fact could be Hosts or Routers.
RFC--1620 [4] describes this and similar configurations in more
detail, as well as associated problems and possible solution
approaches. Figure 3 shows an example end-to-end configuration
consisting of four components, three of which are ATM-technology-
based, while the fourth is a standard IP subnetwork based on non-ATM
technology. Since end-systems (either hosts or routers) attached to
the ATM-based networks may communicate directly via ATM (subject to
policy constraints), in this model such nodes may also communicate
directly at the IP level without necessarily needing an intermediate
router, even if end-systems do not share a common IP-level network
prefix. Communication with end-systems on the non-ATM-based Classical
IP subnet takes place via a router, following the Classical IP model.
Many of the problems/issues associated with this configuration, which
were originally being addressed in the IETF's IPLPDN working group and
the IP over ATM working group, are now being addressed in the Routing
over Large Clouds working group. Examples of work performed
in the IPLPDN working group include short-cut routing (proposed by P.
Tsuchiya) and directed ARP RFC--1433 [7] over SMDS subnets, and in
the ROLC working group include distributed ARP server architectures
and next hop resolution protocols in RFC--1735 [9], and NHRP [10].
Questions/Issues to be worked for this configuration include:
o How can routing be optimized across multiple logical IP subnets
over both a common ATM based and a non-ATM based infrastructure.
E.g.in Figure 3, there are two gateways/routers between the
SVC-based WATM and the non-ATM subnet. The optimal path from
end-systems on any ATM-based subnet to the non ATM-based subnet
is a function of the routing state information of the two
Cole, Shur Expires August 17, 1995 [Page 13]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
routers.
o How to incorporate policy routing constraints,
o What is the proper coupling between routing and address
resolution aspects particularly with respect to off-subnet
communication,
o What are the local procedures to be followed by hosts and
routers.
o Routing between end systems not sharing a common IP-level (or L3)
network prefix, but able to be directly connected at the subnet
level,
o Defining the details for an efficient address resolution
architecture including defining the procedures to be followed by
clients and servers, (see RFC--1433 [7], RFC--1735 [9] and NHRP
[10].)
o Methods of encapsulation and multiplexing, (This issue is
addressed in RFC--1483 [8].)
o Defining the default MTU size, (This issue is addressed in
RFC--1626 [2].)
o Defining security procedures,
o Support for IP multicasting,
o Defining SVC optimization techniques, e.g., time-out mechanisms,
o Negotiations of, e.g., MTU size, method of encapsulation, and
o Special purpose SVCs for control/routing and high bandwidth data
transfers.
More complex ATM internets are envisioned (e.g., mesh connectivity
among private and public networks), and solutions to networking over
SVC-based WATM subnets must be able to support these complex internets
and their attending problems.
An additional complexity in supporting IP routing over these ATM
internets lies in the multiplicity of subnetwork points of attachment
address formats in UNI 3.0 [14]. NSAP modeled address formats only are
supported on "private ATM" networks, while either 1) E.164 only, 2)
NSAP modeled formats only, or 3) both are supported on "public ATM"
networks. Further, while both the E.164 and NSAP modeled address
formats are to be considered as subnetwork points of attachment, it
seems that E.164 only networks are to be considered as subordinate to
Cole, Shur Expires August 17, 1995 [Page 14]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
"private networks", in some sense. This leads to some confusion in
defining an ARP mechanism in supporting all combinations of end-to-end
scenarios (refer to the discussion in Appendix A on the possible
scenarios to be supported by ARP).
6.4 Integrated Model
The Classical IP model requires that IP routing be independent of
the details of connectivity in an ATM sub-network. If ATM routing
processes are present within the subnet, this implies that the user
needs to install and manage two independent routing hierarchies (one
for ATM, and one for IP). The Integrated model (proposed and under
study within the Multiprotocol group of ATM Forum) considers a single
routing protocol to be used for both IP and for ATM. A single routing
information exchange is used to distribute topological information.
The routing computation used to calculate routes for IP will take into
account the topology, including link and node characteristics, of both
the IP and ATM networks and calculates an optimal route for IP packets
over the combined topology.
Many issues exist with respect to the above proposal. While
the potential exists to compute "better" routes, overall routing
complexity (e.g., ensuring loop-free routing) is increased.
6.5 Peer Models
Peer Models place IP routers/gateways on a peer basis with
corresponding entities in an ATM cloud (where the ATM cloud may
consist of a set of ATM networks, inter-connected via UNI or P-NNI
interfaces). That is, ATM network entities and the attached IP hosts
or routers exchange call routing information on a peer basis. Within
the ATM cloud, ATM network level addressing (NSAP-style), call routing
and packet formats are used. Peer models are being discussed in the
Multiprotocol SWG of the ATM Forum.
A rationale for these models is that due to the envisioned complexity
of future ATM networks, the routing complexities will be similar to
routing over complex internets. Rather than building in redundancy
in routing complexities at the network and subnetwork levels, perhaps
it is possible to imbed within the ATM network fabric IS (router)
functionality. This is illustrated in Figure 4. Here the term
"Single ATM Domain" refers to a collection of ATM switches from a
single ATM switch vendor or a collection of ATM switches administered
by a single authority. The routing function of the ATM-IS is only
required during the connection set-up phase, and not in the data
transfer phase following the connection establishment.
Cole, Shur Expires August 17, 1995 [Page 15]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
Figure 4: The ATM Internet model imbeds within the ATM cloud
network level routing features which in essence peers with traditional
gateways or routers.
There are numerous issues to be worked for this Peer Model including:
o Defining a routing architecture which
-- scales to the large size expected of the eventual ATM
network, and
-- supports TOS routing and IP options, and
o Defining a functional architecture which
-- scales to the large size expected of the eventual ATM
network,
-- supports the current status of the ATM Forum's standards in
signalling, routing, etc., and
-- allows a transition from subnet models to peer models.
During the discussions of the IP over ATM working group, it was felt
that the problems with the end-to-end peer model were much harder than
any other model, and had more unresolved technical issues. While
encouraging interested individuals/companies to research this area, it
Cole, Shur Expires August 17, 1995 [Page 16]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
Figure 5: The ATM transition model assuming the presence of gateways
or routers between the ATM subnets and the ATM peer networks.
was not an initial priority of the working group to address these
issues. The ATM Forum Network Layer Multiprotocol Working Group is
discussing this model.
6.6 Transition Models
Finally, it is useful to consider transition models, lying somewhere
between the Classical IP Models and the Peer Models. Some possible
architectures for transition models have been suggested by Fong Liaw.
Others are possible, for example Figure 5 showing a Classical IP
transition model which assumes the presence of gateways between ATM
subnets and ATM Peer networks.
7 Application of the Working Group's and Related Documents
The IP Over ATM Working Group has generated several Internet-Drafts
and RFCs. This section identifies the relationship of these and other
related documents to the various IP Over ATM Models identified in this
document. The Drafts and RFCs produced to date are the following
references, RFC--1483 [8], RFC--1577 [11], RFC--1626 [2], RFC--1755
[13], IPMC [1] and NHRP [10]. Table 1 gives a summary of these
documents and their relationship to the various IP Over ATM Models.
Cole, Shur Expires August 17, 1995 [Page 17]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
Documents_|Summary______________________________________________________
RFC 1483 |How to identify/label multiple packet/frame-based proto-
|cols multiplexed over ATM AAL5. Applies to any model
|dealing with IP over ATMAAL5.
RFC1577 |Model for transporting IP and ARP over ATM AAL5 in a
|subnetwork where all nodes share a common IP network
|prefix. Includes ARP server/Inv-ARP packet formats and
|procedures for SVC/PVC subnets.
RFC1626 |Specifies default IP MTU size to be used with ATM AAL5.
|Requires use of PATH MTU discovery. Applies to any model
|dealing with IP over ATM AAL5.
RFC 1755 |Defines how implementations of IP over ATM should use ATM
|call control signaling procedures, and recommends values
|of mandatory and optional IEs focusing particularly on the
|Classical IP model.
ARM94 |Defines how to support IP multicast in Classical IP model
|using either (or both) meshes of point-to-multipoint ATM
|VCs, or multicast server(s).
KAT94 |Describes a protocol that can be used by hosts and routers
|to determine the NBMA next hop address of a destination
|in "NBMA connectivity" of the sending node. If the
|destination is not connected to the NBMA fabric, the
|IP and NBMA addresses of preferred egress points are
|returned. Applies to the ROLC model.
Table 1: Summary of WG Documents
Cole, Shur Expires August 17, 1995 [Page 18]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
8 Conclusions
This document describes two ATM-based subnet models, namely, an
SVC-based LATM (LATM) and a PVC-based WAN ATM (PVC-based WATM).
Furthermore, this document lists several of the end-to-end IP over
ATM architectures which have been discussed and the distinguishing
characteristics of each. The End-to-end models discussed include the
Classical IP model, Ohta's "Conventional" model, the ROLC model, the
Integrated Model, and Peer models. The major issues pertaining to the
various models have been listed, identifying which ones are largely
resolved, and which ones are as yet unresolved.
It is proposed that in general current or future IP over ATM subnet
or end-to-end models should be worked separately to simplify the work
into more manageable steps. On the other hand, where a common
functionality applies across many models (e.g., encapsulation), a
single activity focused on this subject spanning multiple models is
also a recommended approach.
Acknowledgments:
This draft is the direct result of the numerous discussions of the IP
over ATM Working Group of the Internet Engineering Task Force. The
authors also had the benefit of several private discussions with H.
Nguyen of AT&T Bell Laboratories. Brian Carpenter of CERN was kind
enough to contribute the TULIP and TUNIC sections to this draft.
Grenville Armitage of Bellcore and Curtis Villamizar of ANS were kind
enough to contribute the sections on VC binding, encapsulations and
the use of B-LLI information elements to signal such bindings. The
text of Appendix A was pirated liberally from Anthony Alles' of Cisco
posting on the IP over ATM discussion list (and modified at the
authors' discretion). This draft also has benefitted from numerous
suggestions from John T. Amenyo of ANS, Joel Halpern of Newbridge, and
Andy Malis of Ascom-Timplex.
Authors' Addresses:
Robert G. Cole
AT&T Bell Laboratories
101 Crawfords Corner Road, Rm. 3L-533
Holmdel, NJ 07733
Phone: (908) 949-1950
Fax: (908) 949-8887
Email: rgc@qsun.att.com
Cole, Shur Expires August 17, 1995 [Page 19]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
David Shur
AT&T Bell Laboratories
101 Crawfords Corner Road, Rm. 1F-338
Holmdel, NJ 07733
Phone: (908) 949-6719
Fax: (908) 949-5775
Email: d.shur@att.com
References
[1] G. Armitage. Support for multicast over uni 3.1 based
atm networks. Internet Draft (Work in Progress) draft-ietf-
ipatm-ipmc-04.txt, Internet Engineering Task Force, February
1995.
[2] R. Atkinson. Default IP MTU for use over ATM AAL5. Request
for Comments (Experimental) RFC 1626, Internet Engineering Task
Force, may 1994.
[3] R. Braden and J. Postel. Requirements for internet gateways.
Request for Comments (Standard) RFC 1009, Internet Engineering
Task Force, June 1987. Obsoletes RFC0985.
[4] R. Braden, J. Postel, and Y. Rekhter. Internet architecture ex-
tensions for shared media. Request for Comments (Informational)
RFC 1620, Internet Engineering Task Force, may 1994.
[5] T. Bradley and C. Brown. Inverse address resolution protocol.
Request for Comments (Proposed Standard) RFC 1293, Internet
Engineering Task Force, January 1992.
[6] T. Bradley, C. Brown, and A. Malis. Multiprotocol interconnect
over frame relay. Request for Comments (Draft Standard) RFC
1490, Internet Engineering Task Force, July 1993. Obsoletes
RFC1294.
[7] J. Garrett, J. Hagan, and J. Wong. Directed ARP. Request
for Comments (Experimental) RFC 1433, Internet Engineering Task
Force, March 1993.
[8] J. Heinanen. Multiprotocol encapsulation over ATM adaptation
layer 5. Request for Comments (Proposed Standard) RFC 1483,
Internet Engineering Task Force, July 1993.
[9] J. Heinanen and R. Govindan. Nbma address resolution protocol
(narp). Request for Comments (Experimental) RFC 1735, Internet
Engineering Task Force, December 1994.
Cole, Shur Expires August 17, 1995 [Page 20]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
[10] D. Katz and D. Piscitello. Nbma next hop resolution
protocol (nhrp). Internet Draft (Work in Progress) draft-ietf-
rolc-nhrp-03.txt, Internet Engineering Task Force, November
1994.
[11] M. Laubach. Classical IP and ARP over ATM. Request for Comments
(Proposed Standard) RFC 1577, Internet Engineering Task Force,
January 1994.
[12] J. Mogul and S. Deering. Path MTU discovery. Request for
Comments (Draft Standard) RFC 1191, Internet Engineering Task
Force, November 1990.
[13] M. Perez, F. Liaw, D. Grossman, A. Mankin, and A. Hoffman.
Atm signalling support for ip over atm. Request for Comments
(Informational) RFC 1755, Internet Engineering Task Force,
January 1995.
Stale References:
[14] ATM Forum, "ATM User-Network Interface Specification",
Version 3.0, PTR Prentice Hall, ISBN 0-13-225863-3, September 1993.
Appendix A: Potential Interworking Scenarios to be Supported by ARP
The architectural model of the VC routing protocol, being defined by
the Private Network-to-Network Interface (P-NNI) working group of the
ATM Forum, categorizes ATM networks into two types:
o Those that participate in the VC routing protocols and use NSAP
modeled addresses UNI 3.0 [14] (referred to as private networks,
for short), and
o Those that do not participate in the VC routing protocol.
Typically, but possibly not in all cases, public ATM networks
that use native mode E.164 addresses UNI 3.0 [14] will fall into
this later category.
The issue for ARP, then is to know what information must be returned
to allow such connectivity. Consider the following scenarios:
Cole, Shur Expires August 17, 1995 [Page 21]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
o Private host to Private Host, no intervening public transit
network(s): Clearly requires that ARP return only the NSAP
modeled address format of the end host.
o Private host to Private host, through intervening public
networks: In this case, the connection setup from host A to host
B must transit the public network(s). This requires that at
each ingress point to the public network that a routing decision
be made as to which is the correct egress point from that public
network to the next hop private ATM switch, and that the native
E.164 address of that egress point be found (finding this is a VC
routing problem, probably requiring configuration of the public
network links and connectivity information). ARP should return,
at least, the NSAP address of the endpoint in which case the
mapping of the NSAP addresses to the E.164 address, as specified
in [14], is the responsibility of ingress switch to the public
network.
o Private Network Host to Public Network Host: To get connectivity
between the public node and the private nodes requires the
same kind of routing information discussed above - namely, the
directly attached public network needs to know the (NSAP format)
ATM address of the private station, and the native E.164 address
of the egress point from the public network to that private
network (or to that of an intervening transit private network
etc.). There is some argument, that the ARP mechanism could
return this egress point native E.164 address, but this may
be considered inconsistent for ARP to return what to some is
clearly routing information, and to others is required signaling
information.
In the opposite direction, the private network node can use, and
should only get, the E.164 address of the directly attached public
node. What format should this information be carried in? This
question is clearly answered, by Note 9 of Annex A of UNI 3.0 [14],
Version 2.4 (passed by ballot recently to become Version 3.0), vis:
"A call originated on a Private UNI destined for an host which only
has a native (non-NSAP) E.164 address (i.e. a system directly
attached to a public network supporting the native E.164 format) will
code the Called Party number information element in the (NSAP) E.164
private ATM Address Format, with the RD, AREA, and ESI fields set to
zero. The Called Party Subaddress information element is not used."
Hence, in this case, ARP should return the E.164 address of the
public ATM station in NSAP format. This is essentially implying an
algorithmic resolution between the native E.164 and NSAP addresses of
directly attached public stations.
Cole, Shur Expires August 17, 1995 [Page 22]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
o Public network host to Public network host, no intervening
private network: In this case, clearly the Q.93b requests would
use native E.164 address formats.
o Public network host to Public network host, intervening private
network: same as the case immediately above, since getting
to and through the private network is a VC routing, not an
addressing issue.
So several issues arise for ARP in supporting arbitrary connections
between hosts on private and public network. One is how to
distinguish between E.164 address and E.164 encoded NSAP modeled
address. Another is what is the information to be supplied by ARP,
e.g., in the public to private scenario should ARP return only the
private NSAP modeled address or both an E.164 address, for a point of
attachment between the public and private networks, along with the
private NSAP modeled address.
Appendix B: Encapsulations and Lower Layer Identification:
Data encapsulation, and the identification of VC endpoints, constitute
two important issues that are somewhat orthogonal to the issues of
network topology and routing. The relationship between these two
issues is also a potential sources of confusion. In conventional
LAN technologies the 'encapsulation' wrapped around a packet of
data typically defines the (de)multiplexing path within source and
destination nodes (e.g. the Ethertype field of an Ethernet packet).
Choice of the protocol endpoint within the packet's destination node
is essentially carried 'in-band'.
As the multiplexing is pushed towards ATM and away from LLC/SNAP
mechanism, a greater burden will be placed upon the call setup and
teardown capacity of the ATM subnet. This may result in some
questions being raised regarding the scalability of these lower level
multiplexing options.
With the ATM Forum UNI version 3.1 service the choice of endpoint
within a destination node is made 'out of band' - during the Call
Setup phase. This is quite independent of any in-band encapsulation
mechanisms that may be in use. The B-LLI Information Element allows
Layer 2 or Layer 3 entities to be specified as a VC's endpoint. When
faced with an incoming SETUP message the Called Party will search
locally for an AAL User that claims to provide the service of the
layer specified in the B-LLI. If one is found then the VC will be
accepted (assuming other conditions such as QoS requirements are also
met).
Cole, Shur Expires August 17, 1995 [Page 23]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
Figure 6: AAL5 PDU is an encapsulated IP packet
An obvious approach for IP environments is to simply specify the
Internet Protocol layer as the VCs endpoint, and place IP packets into
AAL--SDUs for transmission. This is termed 'VC multiplexing' or 'Null
Encapsulation', because it involves terminating a VC (through an AAL
instance) directly on a layer 3 endpoint. However, this approach
has limitations in environments that need to support multiple layer 3
protocols between the same two ATM level endpoints. Each pair of
layer 3 protocol entities that wish to exchange packets require their
own VC.
RFC--1483 [8] notes that VC multiplexing is possible, but focuses
on describing an alternative termed 'LLC/SNAP Encapsulation'. This
allows any set of protocols that may be uniquely identified by an
LLC/SNAP header to be multiplexed onto a single VC. Figure 6 shows
how this works for IP packets - the first 3 bytes indicate that
the payload is a Routed Non-ISO PDU, and the Organizationally Unique
Identifier (OUI) of 0x00-00-00 indicates that the Protocol Identifier
(PID) is derived from the EtherType associated with IP packets
(0x800). ARP packets are multiplexed onto a VC by using a PID of
0x806 instead of 0x800.
Whatever layer terminates a VC carrying LLC/SNAP encapsulated traffic
must know how to parse the AAL--SDUs in order to retrieve the packets.
The recently approved signalling standards for IP over ATM are more
explicit, noting that the default SETUP message used to 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, there is no
information carried within the SETUP message about the identity of
the layer 3 protocol that originated the request - until the packets
begin arriving the terminating LLC entity cannot know which one or
more higher layers are packet destinations.
Cole, Shur Expires August 17, 1995 [Page 24]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
Figure 7: LLC/SNAP encapsulation allows more than just IP or ARP per
VC.
Taken together, this means that hosts require a protocol entity to
register with the host's local UNI 3.1 management layer as being an
LLC entity, and this same entity must know how to handle and generate
LLC/SNAP encapsulated packets. The LLC entity will also require
mechanisms for attaching to higher layer protocols such as IP and ARP.
Figure 7 attempts to show this, and also highlights the fact that
such an LLC entity might support many more than just IP and ARP. In
fact the combination of RFC 1483 LLC/SNAP encapsulation, LLC entities
terminating VCs, and suitable choice of LLC/SNAP values, can go along
way towards providing an integrated approach to building multiprotocol
networks over ATM.
The processes of actually establishing AAL Users, and identifying them
to the local UNI 3.1 management layers, are still undefined and are
likely to be very dependent on operating system environments.
Two encapsulations have been discussed within the IP over ATM working
group which differ from those given in RFC--1483 [8]. These
have the characteristic of largely or totally eliminating IP header
overhead. These models were discussed in the July 1993 IETF meeting
in Amsterdam, but have not been fully defined by the working group.
Given a single hop configuration between Sub-ES as shown in Figure 1
(in the main text above), they both assume that following name
resolution, address resolution, and SVC signaling, an implicit binding
is established between entities in the two Sub-ESes. In this case
full IP headers (and in particular source and destination addresses)
are not required in each data packet.
Cole, Shur Expires August 17, 1995 [Page 25]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
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 this case
the implicit binding is between the IP entities in each Sub-ES.
Since there is no further routing problem once the binding
is established, since AAL5 can indicate packet size, since
fragmentation cannot occur, and since ATM signaling will handle
exception conditions, the absence of all other IP header fields
and of ICMP should not be an issue. Entry to TULIP mode would
occur as the last stage in SVC signaling, by a simple extension
to the encapsulation negotiation described in RFC--1755 [13].
TULIP changes nothing in the abstract architecture of the IP
model, since each subnet ES still has an IP address which is
resolved to an ATM address. It simply uses the point-to-point
property of VCs to allow the elimination of some per-packet
overhead. The use of TULIP could in principle be negotiated on a
per-SVC basis or configured on a per-PVC basis.
o The second model is "TCP and UDP over a Nonexistent IP
Connection" (TUNIC). In this case no network-layer information is
carried in each packet, everything being bound at virtual circuit
set-up time. The implicit binding is between two applications
using either TCP or UDP directly over AAL5 on a dedicated VC. If
this can be achieved, the IP protocol field has no useful dynamic
function. However, in order to achieve binding between two
applications, the use of a well-known port number in classical
IP or in TULIP mode may be necessary during call set-up. This
is a subject for further study and would require significant
extensions to the use of SVC signaling described in RFC--1755
[13].
TULIP/TUNIC can be presented as being on one end of a continuum
opposite the SNAP/LLC encapsulation, with various forms of null
encapsulation somewhere in the middle. The continuum is simply a
matter of how much is moved from in-stream demultiplexing to call
setup demultiplexing. The various encapsulation types are presented
in Table 2.
Cole, Shur Expires August 17, 1995 [Page 26]
INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995
Encapsulation_Method_|In_setup_message_________|Demultiplexing___________
SNAP/LLC |nothing |source and destination
| |address, protocol family,
| |protocol, ports
NULL encapsulation |source and destination, |source and destination,
|protocol family |protocol, ports
TULIP |source and destination, |protocol
|protocol family |
TUNIC - A |source and destination, |ports
|protocol family, |
|protocol |
TUNIC - B |source and destination, |nothing
|protocol family, |
|protocol, ports |
Table 2: Summary of Encapsulation Types
Cole, Shur Expires August 17, 1995 [Page 27]