Internet Draft
INTERNET DRAFT M. Ohta
draft-ohta-ip-over-atm-02.txt Tokyo Institute of Technology
H. Esaki
K. Nagami
Toshiba Corporation
March 1995
Conventional IP over ATM
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.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
Abstract
The possibility to construct a conventional model to transfer IP over
ATM is studied.
The model contains concepts of subnet, bridges, routers, broadcast
and so on, all of which are familiar with the model of IP over
Ethernet.
Still, the model allows QoS assured seamless internetwork level (not
link level) ATM connection which can be directly supported by
existing ATM hardware. That is, new communication model with resource
reservation such as RSVP or STII can be supported efficiently.
Introduction
This memo describes a framework of transmitting IP packets over
existing ATM hardware without assuming any change to the existing
model of transmitting IP over other media.
ATM is a good candidate of the platform for very high speed QoS
Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 1]
INTERNET DRAFT Conventional IP over ATM March 1995
(Quality of Services [RSVP, STII]) assured link layer. But, unlike
enthusiastic ATM lovers, the Author does not think ATM will rule the
world. On the other hand, the Author believes IP will rule the
world, at which time ATM based equipments must cooperate with other
media such as Ethernet or something like Ethernet.
To make the cooperation smooth, it is better if the model of IP over
ATM is no different from the model of IP over Ethernet.
Thus, unlike the model of "Classical IP and ARP over ATM" [CLIP],
which is modified, non-classical IP technology over PDN-like,
classical, ATM, the conventional model trys to keep IP as classical
and conventional as possible.
The conventional model is designed so that existing ATM hardware can
be used as is.
Framework difference between the Classical and the Conventional Model
The purpose of IP over ATM is to relay data between hosts cell by
cell. If a quality requirement is not so severe, routers may relay
data packet by packet. But to assure low delay, high throughput
communication, cell by cell relaying is strongly desirable.
The basic difference between the Classical and the Conventional Model
is whether it is assumed that a router can relay data cell by cell or
not.
The classical model is constructed as follows:
A router can not relay data cell by cell.
To relay data between hosts cell by cell, both hosts must be
placed in a single link layer.
To scale the network, it is necessary to place all the hosts in
the world in a single link layer.
As the link layer of ATM is purely connection oriented, cell by
cell relaying must be connection oriented.
In such a large link layer, broadcasting is impossible.
ARP, DHCP and other protocols must be redesigned not to use
broadcast.
If packet relaying routers are tolerated, LIS (logical IP subnet)
model connected by the routers is possible, which is useful for
Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 2]
INTERNET DRAFT Conventional IP over ATM March 1995
connectionless communication but may waste resource by not using
the optimal path.
But, as shown in the section "Connection Oriented QoS Assured
Communication over ATM" of this memo, if a proper reservation, or a
connection setup, is done in advance, it is perfectly possible to
have a router which relays data cell by cell.
Thus, the conventional model is constructed as follows:
With a proper reservation, a router can relay data cell by cell.
To relay data between hosts cell by cell, both hosts may be
connected by multiple routers.
To scale the network, it is possible to place routers between
hosts not to make a single link layer so large.
As the reservation is required, cell by cell relaying must be
connection oriented.
In such a small link layer, broadcasting is perfectly possible.
The resulting model is no different from that of the existing
Internet, including broadcasting ARP, DHCP and other protocols.
If packet relaying routers are tolerated, routers may relay data
packet by packet without any prior reservation, which is useful
for connectionless communication and is as efficient as the
existing Internet for path optimization.
Overview of the WAN/LAN model of the Conventional IP
While other models of IP over ATM [CLIP, IPATM] assumes PDN like ATM
WAN, which somewhat affects ATM LAN model and is a lot different from
Ethernet LAN, the conventional model assumes no fundamental
difference between Ethernet LAN, ATM LAN and ATM WAN.
It seems to the Author that there is common misunderstanding of many
ATM experts that cell-by-cell relaying can only be performed at link
layer, which make thier model unnatural. The last section shows how
internetwork layer cell-by-cell relaying is possible.
Just as the current IP LAN over Ethernet and IP WAN are fundamentally
same, ATM LAN and ATM WAN of the model are fundamentally same.
That is, just as the current T3 backbone, the WAN model of this memo
is constructed by leased lines directly connecting IP routers, which
Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 3]
INTERNET DRAFT Conventional IP over ATM March 1995
directly support IP protocols including routing. Routing packets
will be propagated by WAN operators as maintenance packets. When IP
rules the world and WAN is IP, there is no cloud. So, ROLC (Routing
over Large Cloud) [ROLC] technology is not necessary. See [SMAI] for
more details.
With the conventional model, just as Ethernet equipments, ATM
switches are classified into routers or bridges (or brouters, maybe).
whose roles are no different from those of Ethernet equipments.
Bridges are link layer entity which connect several physical layers.
Bridges copy the incoming packets to all of the output ports without
trying to optimize the path. If a bridge is a learning bridge and
knows to which interface the destination is attached, unnecessary
copying can be suppressed. If a link level topology contains a loop,
bridges should support spanning tree algorithm to avoid packets
copied infinitely along the loop.
Routers are internetwork layer entity which connect several data link
layers. Routers relay packets beyond (sub-)networks. Routers
exchange routing information and maintains routing tables.
Logically, each packet is relayed to the optimal interface by looking
up the routing table. Actually, some cache or bypass is often used
to minimize the routing delay of complex table looking up.
It is not the business of bridges to choose the best path to the
destination. Doing so will make the link level layer as complex as
the conventional link and internetwork layers added together, which
is the destruction of layering. So, to operate a network with a lot
of hosts and some amount of redundant pathes, the network should be
divided into several link layers connected by routers to make use of
the bandwidth of redundant pathes. It is impractical to have a
single link layer containing a lot of hosts.
As PVC based network needs a lot of link level static configuration,
it is difficult to manage and unrealistic for the network with more
than hundreds of hosts. As exemplified with broadcast storm, wrong
static setting at link level is often fatal. With ATM, if link layer
configuration is wrong, cells may loop. It should be noted that on
point-to-point links such as ATM, looping of cells is equally harmful
as broadcasted looping on multiple access media for the consumed
bandwidth of the link. That is, though looping on a single physical
link does not affect other physical links, single link layer looping
affect several physical links. To make the matter worse, as ATM has
no link level hop count, looping will continue forever. So, PVC ATM
is not considered in this memo.
Communication over ATM in the Link Layer
Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 4]
INTERNET DRAFT Conventional IP over ATM March 1995
As the conventional model is properly layered, the internetwork layer
of the conventional model can cooperate with any link layer which can
cooperate with the model of IP over Ethernet or any other medium.
Especially, a link layer of classical model with NBMA ARP or even a
link layer with pure PVC may co-operate with the internetwork layer
of the conventional model.
But, as cell by cell relaying over routers is possible, it is much
better to construct a broadcast-capable ATM link layer than modifying
a lot of existing broadcast-based protocols not to use broadcast.
This section discusses the possibility to have such a link layer.
Unless a link layer is made of a single physical layer, it is
beneficial for bridges to maintain some amount of connection
information.
With Ethernet, without learning bridges, all the packets are copied
to all the physical layers. With learning bridges, as a packet is
relayed by bridges, bridges learn from which interfaces the packet is
received, which is equivalent to the path setup to the source of the
packet. If two hosts exchange packets, a soft connection between the
hosts are established as the state of learning bridges.
With ATM, things can be no different, though additional support for
more rigid connection may present. Such a rigid connection is
necessary and useful to assure QoS. If QoS is not necessary, link
layer communication may be just like that of Ethernet. To do so, an
AAL containing the MAC addresses of the sender and the receiver in
the first cell is necessary. ATM bridges then peek into the first
cell and learn that the sender is located toward the incoming
interface of the cell. Then, if the receiver's location is not
learned, cells are broadcasted. Unfortunately, the scheme can not be
supported efficiently by the current hardware. Alternative way is to
use broadcasted ARP [EARP] followed by signaling to establish SVC
between a pair of hosts.
As for broadcast, at a physical layer, there is no such thing as NBMA
(Non-Broadcast Multi-Access). Regardless of whether the layer is
point-to-point or multiple-access, everything a sender sends is
received by all the hosts connected to the layer.
So, it is not surprising that a link layer attempt to throw way the
physical layer property results in serious loss of information
necessitating some static configuration [ROLC]. Thus, the
conventional wisdom of the conventional IP is to support broadcast at
the link layer. It should be noted that, with conventional IP, the
Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 5]
INTERNET DRAFT Conventional IP over ATM March 1995
size of a well-managed link layer is not so large. So, excessive
amount of copying of a broadcast packet does not occur.
Ethernet bridges copies broadcast packets to all the interfaces (on
the spanning tree). ATM bridges can also do so. Most of existing
ATM switches have efficient hardware mechanism of such copying to
support point-to-multipoint connections.
Moreover, broadcast is the only way to communicate with neighbors
without prior knowledge of neighbor's addresses. For example, one of
the goals of DHCP (Dynamic Host Configuration Protocol) to make hand
configuration completely unnecessary, can not be achieved without
broadcast.
So, there seems to be no reason not to have broadcast with ATM.
This memo merely describe a possible architecture of IP over ATM and
does not attempt to propose any standard. So, the detailed mechanism
on broadcast with ATM is not discussed further.
Conventional Communication over ATM in a Internetwork Layer
The conventional communication, that is communication that does not
assume connectivity, is no different from that of the existing IP, of
course. Communication within a link layer is performed as described
in the previous section. Communication beyond link layers is
performed by first communicating to a router. Routers exchange
routing information and forward packets decrementing TTL by one or
more toward the next hop routers. No further explanation is
necessary nor given.
Though it is possible to reduce hop counts by having ATM connections
between non-adjacent routers, it is beyond the scope of the
conventional model and not discussed in this memo.
Connection Oriented QoS Assured Communication over ATM
The goal of connection oriented communication is to provide end-end
IP connection. Such a connection is necessary to have QoS-assured
communication.
Unlike other models of IP over ATM, the model in this memo assumes
QoS-assured communication over not only ATM but also other types of
media.
The model, in general, is not so different from that of the previous
section, though seamless optimization is possible for communication
between ATM link layers.
Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 6]
INTERNET DRAFT Conventional IP over ATM March 1995
It is assumed that QoS reservation protocol within a link layer is
present and is preformed by hosts (including routers) attached to the
layer. How it will be is not addressed in this memo.
Communication within a link layer can directly use the link layer QoS
reservation protocol and needs no special care.
Communication beyond link layers is performed by first establishing
QoS assured connection to a neighbor router. Routers then
establishes the QoS connection using the link level reservation
protocol to the next hop router until the destination is reached.
Some processing power of routers should also be reserved.
After the connection is established, packets are forwarded through
the QoS assured link layer connection.
As there can be multiple QoS assured connection between the source
and the destination, some identifier other than source/destination
addresses is necessary to uniquely identify a connection.
A single identifier, called flow ID, could be used along the
connection. The pair of the source address and the flow ID uniquely
identifies the connection.
In general, QoS assured communication can be routed to an appropriate
next hop link layer connection by flow ID.
That is:
1) a packet arrives at a router
2) packet's flow ID and source address are checked and the next
hop is determined
3) packet's TTL is decremented by 1 (or more)
4) unless the router is the destination, the packet is forwarded
the above scheme assumes nothing ATM specific and applicable to all
the QoS assured media such as a fixed speed dedicated link, FDDI II
or switched Ethernet.
If both incoming and outgoing interfaces are ATM, packets are
reassembled at step 1) and re-celled at step 4), which means certain
amount of delay and certain amount of processing overhead and is not
so desirable.
Optimization is possible by making use of the fact that flow ID is
Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 7]
INTERNET DRAFT Conventional IP over ATM March 1995
not necessary at step 2). That is, if some information to identify
flow locally at each interface is provideed, it is enough to
determine the next link layer connection. With ATM, VCI/VPI is such
locally unique identifier. Moreover, ATM equipments have efficient
hardware mechanism to forward cells based on VCI/VPI of incoming
cells.
So, if both the incoming and outgoing interface are ATM, the
following cell-by-cell scheme works:
1) a cell arrives at a router
2) cell's VCI/VPI/incoming_interface is checked and the next hop
VCI/VPI/outgoing_interface is determined by hardware
3) unless the router is the destination, the cell is forwarded
It is assumed that information used at the step 2) is provided during
the connection establishment.
Thus, if ATM hosts communicate purely over ATM routers, a seamless
single ATM link is established between them. It should be noted
that, though many think ATM connection is considered to be at the
link layer, the above seamless connection on ATM routers is at the
internetwork layer. So, all the internetwork layer property such as
the selection of the best path is naturally available.
Seamlessness, here, should considered to be something like lower
level caching. Whether some ATM equipment forward information cell by
cell or packet by packet is merely an internal implementation detail,
which does not affect the classification on whether the equipment is
considered to be a bridge or a router.
The problem of the scheme above is that TTL of the packet is not
decremented at all. If ATM routers recognize AAL and can decrement
TTL by hardware, it's OK. But, currently, they can't.
As the number of routers along the seamless path is known in advance,
packets with insufficient TTL may be dropped at the starting point of
the seamless link.
The TTL issue never be an issue in practice, unless the path itself
is setup to form a loop, in which case no models of IP over ATM with
seamless connection can function, anyway. Resource reservation
protocols should be designed to make the formation of the loop
completely unlikely. The lack of link level TTL makes the looping
serious issue. It might be necessary in the future to design a new
AAL that supports cell-wise or packet-wise TTL supported by hardware.
Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 8]
INTERNET DRAFT Conventional IP over ATM March 1995
References
[CLIP] M. Laubach, "Classical IP and ARP over ATM", RFC1577, January
1994.
[EARP] D. Plummer, "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD37, RFC826,
November 1982.
[IPATM] An Internet Draft may be available (J. Heinanen, R. Govindan,
"IP over ATM: A Framework Document", ).
[ROLC] An Internet Draft may be available (J. Heinanen, R. Govindan,
"NBMA Next Hop Resolution Protocol (NHRP)", ).
[RSVP] An Internet Draft may be available (L. Zhang, R. Braden, D.
Estrin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", ).
[SMAI] An Internet Draft may be available (M. Ohta, "Shared Media
Architecture for the Internet", ).
[STII] C. Topolcic, "Experimental Internet Stream Protocol, Version 2
(ST-II)", RFC1190, October 1990.
Acknowledgements
This memo is a result of discussion in TNG (The Next Generation)
working group of JAIN consortium. Many ATM experts in Japan
including Masayuki Murata of Osaka University, Kenji Fujisawa of
SONY, Yuichiroh Nozue of Sumitomo Electric Industries and Akira Chugo
of Fujitsu have contributed to the discussion. Interested parties
are encouraged to read the original discussion (available as
ftp.jain.ad.jp:pub/archive/tng-wg in Japanese with ISO-2022-JP
encoding).
Security Considerations
Unlike the classical model, the conventional model does not change
the architecture of the Internet, including but not limited to, the
security architecture.
Thus, all the existing and upcoming security architecture for the
Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 9]
INTERNET DRAFT Conventional IP over ATM March 1995
Internet will work and all the existing and upcoming security holes
of the Internet will remain unclosed.
Authors' Addresses
Masataka Ohta
Computer Center
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku
Tokyo 152, JAPAN
Phone: +81-3-5499-7084
Fax: +81-3-3729-1940
EMail: mohta@cc.titech.ac.jp
Hiroshi Esaki
R&D Center, Toshiba Corporation
1 Komukai-Toshiba-cho, Saiwai-ku
Kawasaki 210, JAPAN
Phone: +81-44-549-2238
Fax: +81-44-549-2262
EMail: hiroshi@csl.rdc.toshiba.co.jp
Ken-ichi Nagami
R&D Center, Toshiba Corporation
1 Komukai-Toshiba-cho, Saiwai-ku
Kawasaki 210, JAPAN
Phone: +81-44-549-2238
Fax: +81-44-549-2262
EMail: nagami@csl.rdc.toshiba.co.jp
Comments may also be directed to:
TNG Working Group
JAIN Consortium
EMail: tng-wg@jain.ad.jp
Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 10]