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]