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]