[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03 04 05 06 RFC 1932

Internet Engineering Task Force                             R. G. Cole
INTERNET-DRAFT                                              D. H. Shur
draft-ietf-ipatm-framework-doc-06               AT&T Bell Laboratories
                                                         C. Villamizar
                                                                   ANS
                                                       October 2, 1995


                  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.



Abstract


The discussions of the IP over ATM working group over the last several
years have produced  a diverse  set of  proposals, some  of which  are
no longer under active  consideration.   A categorization is  provided
for the  purpose  of  focusing  discussion on  the  various  proposals
for IP  over  ATM  deemed of  primary  interest  by the  IP  over  ATM
working group.  The  intent of this framework  is to help clarify  the
differences between proposals and identify common features in order to
promote convergence to a smaller  and more mutually compatible set  of
standards.  In summary, it is hoped that this document, in classifying
ATM approaches and issues will help  to focus the IP over  ATM working
group's direction.


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


1 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.  This document  provides
a classification/taxonomy of IP over  ATM options and issues and  then
describes various proposals in these terms.

The remainder of this memorandum is organized as follows:


  o Section  2  defines  several  terms  relating  to  networking  and
    internetworking.

  o Section  3  discusses  the  parameters   for  a  taxonomy  of  the
    different ATM models under discussion.

  o Section 4 discusses the options for low level encapsulation.

  o Section  5  discusses tradeoffs  between connection  oriented  and
    connectionless approaches.

  o Section  6  discusses  the  various   means  of  providing  direct
    connections across IP subnet boundaries.

  o Section  7 discusses the proposal to  extend IP routing to  better
    accommodate direct connections across IP subnet boundaries.

  o Section 8 identifies several prominent  IP over ATM proposals that
    have  been discussed  within the  IP  over ATM  Working Group  and
    their relationship to the framework described in this document.

  o Section  9  addresses  the   relationship  between  the  documents
    developed in  the IP over ATM  and related working groups and  the
    various models discussed.



2 Definitions and Terminology


We define several terms:


 A Host  or End System:   A host delivers/receives IP packets  to/from
    other systems, but does not relay IP packets.

 A  Router or  Intermediate  System:   A router  delivers/receives  IP
    packets  to/from  other  systems,  and  relays  IP  packets  among
    systems.

Cole, Shur, Villamizar         Expires  April 2, 1996         [Page 2]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


 IP Subnet:   In an IP subnet, all  members of the subnet are  able to
    transmit  packets to  all other  members of  the subnet  directly,
    without  forwarding  by intermediate  entities.    No  two  subnet
    members are  considered closer in the IP topology than  any other.
    From  an  IP routing  and IP  forwarding  standpoint a  subnet  is
    atomic, though there may be  repeaters, hubs, bridges, or switches
    between the physical interfaces of subnet members.

 Bridged  IP Subnet:   A  bridged IP  subnet is  one in  which two  or
    more physically  disjoint media are made to appear as a  single IP
    subnet.    There are  two basic  types of  bridging, media  access
    control (MAC) level, and proxy ARP (see section  6).

 A  Broadcast  Subnet:   A  broadcast  network supports  an  arbitrary
    number  of  hosts  and  routers and  additionally  is  capable  of
    transmitting a single IP packet to all of these systems.

 A  Multicast Capable  Subnet:   A multicast  capable subnet  supports
    a  facility  to  send a  packet  which  reaches a  subset  of  the
    destinations  on  the subnet.     Multicast setup  may  be  sender
    initiated,  or  leaf initiated.    ATM  UNI 3.0  [4]  and UNI  3.1
    support  only sender  initiated while IP  supports leaf  initiated
    join.  UNI 4.0 will support leaf initiated join.

 A  Non-Broadcast Multiple  Access (NBMA)  Subnet:   An NBMA  supports
    an   arbitrary  number  of   hosts  and   routers  but  does   not
    natively  support  a convenient  multi-destination  connectionless
    transmission  facility, as does  a broadcast or multicast  capable
    subnetwork.

 An End-to-End path:   An end-to-end path consists of two  hosts which
    can  communicate with  one  another over  an  arbitrary number  of
    routers and subnets.

 An internetwork:  An internetwork (small  ``i'') is the concatenation
    of  networks, often  of various  different media  and lower  level
    encapsulations,  to form an  integrated larger network  supporting
    communication  between any of  the hosts on  any of the  component
    networks.    The Internet  (big ``I'')  is a  specific well  known
    global  concatenation of  (over  40,000 at  the  time of  writing)
    component networks.

 IP forwarding:   IP forwarding is  the process of receiving a  packet
    and  using a very  low overhead  decision process determining  how
    to  handle  the packet.    The  packet  may be  delivered  locally
    (for  example, management traffic) or  forwarded externally.   For
    traffic  that is forwarded externally,  the IP forwarding  process
    also determines which interface the packet  should be sent out on,
    and  if necessary,  either removes one  media layer  encapsulation
    and replaces  it with another,  or modifies certain fields in  the
    media layer encapsulation.

Cole, Shur, Villamizar         Expires  April 2, 1996         [Page 3]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


 IP routing:   IP routing  is the exchange  of information that  takes
    place  in order  to have  available the  information necessary  to
    make a correct IP forwarding decision.

 IP  address resolution:   A  quasi-static mapping  exists between  IP
    address  on the local  IP subnet  and media  address on the  local
    subnet.     This  mapping  is  known  as  IP  address  resolution.
    An  address resolution  protocol (ARP)  is  a protocol  supporting
    address resolution.


In order to support end-to-end connectivity, two techniques  are used.
One involves  allowing direct  connectivity across  classic IP  subnet
boundaries supported by  certain NBMA media,  which includes ATM.  The
other involves IP routing and IP  forwarding.  In essence,  the former
technique is extending IP address resolution beyond the  boundaries of
the IP subnet, while the latter is interconnecting IP subnets.

Large internetworks, and in particular  the Internet, are unlikely  to
be composed of a single media, or a star topology, with a single media
at the center.    Within a  large network supporting  a common  media,
typically any large  NBMA such as  ATM, IP  routing and IP  forwarding
must always be  accommodated if  the internetwork is  larger than  the
NBMA, particularly  if there  are multiple  points of  interconnection
with the NBMA and/or redundant, diverse interconnections.

Routing information exchange in a very large internetwork can be quite
dynamic due to  the high  probability that some  network elements  are
changing state.  The address resolution space consumption and resource
consumption due to state change,  or maintenance of state  information
is rarely a problem in classic IP subnets.  It can become a problem in
large bridged networks or in proposals that attempt to  extend address
resolution beyond  the  IP subnet.     Scaling properties  of  address
resolution and routing  proposals, with  respect to state  information
and state change, must be considered.



3 Parameters Common to IP Over ATM Proposals


In some  discussion of  IP  over ATM  distinctions have  made  between
local area  networks (LANs),  and wide  area networks  (WANs) that  do
not necessarily hold.    The distinction  between a LAN,  MAN and  WAN
is a matter of geographic  dispersion.  Geographic dispersion  affects
performance due to increased propagation delay.

LANs are used for network  interconnections at the the major  Internet
traffic interconnect sites.   Such  LANs have multiple  administrative
authorities, currently exclusively  support routers providing  transit
to multihomed internets,  currently rely  on PVCs  and static  address

Cole, Shur, Villamizar         Expires  April 2, 1996         [Page 4]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


resolution, and  rely heavily on  IP routing.    Such a  configuration
differs from  the  typical  LANs  used to  interconnect  computers  in
corporate or campus environments, and emphasizes the point  that prior
characterization of LANs  do not  necessarily hold.   Similarly,  WANs
such as  those under  consideration by  numerous  large IP  providers,
do not conform  to prior characterizations  of ATM  WANs in that  they
have a single  administrative authority  and a small  number of  nodes
aggregating large flows  of traffic onto  single PVCs  and rely on  IP
routers to avoid forming congestion bottlenecks within ATM.

The following characteristics of the  IP over ATM internetwork may  be
independent of geographic dispersion (LAN, MAN, or WAN).


  o The size of the IP over ATM internetwork (number of nodes).

  o The size of ATM IP subnets (LIS) in the ATM Internetwork.

  o Single IP subnet vs multiple IP subnet ATM internetworks.

  o Single or multiple administrative authority.

  o Presence of routers providing transit to multihomed internets.

  o The presence or absence of dynamic address resolution.

  o The presence or absence of an IP routing protocol.


IP over ATM should therefore be characterized by:


  o Encapsulations below the IP level.

  o Degree  to which a  connection oriented  lower level is  available
    and utilized.

  o Type  of address  resolution at  the  IP subnet  level (static  or
    dynamic).

  o Degree  to which  address  resolution is  extended  beyond the  IP
    subnet boundary.

  o The type of routing (if any) supported above the IP level.



ATM-specific attributes of particular importance include:


  o The  different types of  services provided  by the ATM  Adaptation

Cole, Shur, Villamizar         Expires  April 2, 1996         [Page 5]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


    Layers   (AAL).   These  specify   the   Quality-of-Service,   the
    connection-mode, etc.   The models discussed within  this document
    assume an underlying connection-oriented service.

  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 or to
    maintain the leaf initiated join semantics).

  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
    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 Section 4.

  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.


IP over ATM proposals do  not universally accept that IP  routing over
an ATM network is required.   Certain proposals rely on  the following
assumptions:


  o The widespread  deployment of ATM within  premises-based networks,
    private wide-area networks and public networks, and

Cole, Shur, Villamizar         Expires  April 2, 1996         [Page 6]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


  o The  definition of  interfaces,  signaling and  routing  protocols
    among private ATM networks.


The above assumptions  amount to ubiquitous  deployment of a  seamless
ATM fabric which  serves as the  hub of a  star topology around  which
all other  media  is  attached.    There  has  been a  great  deal  of
discussion over when, if ever, this will be a realistic assumption for
very large internetworks,  such as the  Internet.   Advocates of  such
approaches point out that even if these are not relevant to very large
internetworks such as  the Internet,  there may  be a  place for  such
models in smaller internetworks, such as corporate networks.

The NHRP  protocol (Section  8.2), not  necessarily  specific to  ATM,
would be  particularly  appropriate for  the  case of  ubiquitous  ATM
deployment.   NHRP supports  the establishment  of direct  connections
across IP subnets in the ATM domain.  The use of NHRP does not require
ubiquitous ATM deployment, but currently imposes  topology constraints
to avoid routing loops (see Section 7).  Section 8.2 describes NHRP in
greater detail.

The Peer Model assumes that internetwork layer addresses can be mapped
onto ATM addresses and vice  versa, and that reachability  information
between ATM routing and internetwork  layer routing can be  exchanged.
This approach has limited  applicability unless ubiquitous  deployment
of ATM holds.  The peer model is described in Section 8.4.

The  Integrated  Model  proposes  a  routing  solution  supporting  an
exchange of routing information between  ATM routing and higher  level
routing.   This provides  timely external  routing information  within
the ATM routing and provides  transit of external routing  information
through the  ATM  routing between  external  routing  domains.    Such
proposals may  better support  a  possibly lengthy  transition  during
which assumptions  of  ubiquitous  ATM  access  do  not  hold.     The
Integrated Model is described in Section 8.5.

The Multiprotocol  over ATM  (MPOA) Sub-Working  Group  was formed  by
the ATM  Forum to  provide multiprotocol  support over  ATM. The  MPOA
effort is at  an early stage  at the time  of this writing.   An  MPOA
baseline document  has been  drafted, which  provides terminology  for
further discussion of the  architecture.   This document is  available
from the FTP server ftp.atmforum.com in pub/contributions as  the file
atm95-0824.ps or atm95-0824.txt.



4 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

Cole, Shur, Villamizar         Expires  April 2, 1996         [Page 7]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


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  network.    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).

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 [6]  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 1  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

Cole, Shur, Villamizar         Expires  April 2, 1996         [Page 8]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995




















           Figure 1:  IP packet encapsulated in an AAL5 SDU


(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.

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 2 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 a long
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  [6].     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.

TULIP and TUNIC  assume single hop  reachability between IP  entities.
Following name resolution, address  resolution, and SVC signaling,  an

Cole, Shur, Villamizar         Expires  April 2, 1996         [Page 9]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995




















Figure 2:  LLC/SNAP encapsulation allows more than just IP  or ARP per
VC.


implicit binding is established between entities in the two hosts.  In
this case full IP  headers (and in  particular source and  destination
addresses) are not required in each data packet.


  o The  first model is  ``TCP and UDP  over Lightweight IP''  (TULIP)
    in  which only the  IP protocol field is  carried in each  packet,
    everything  else  being  bound at  call  set-up  time.    In  this
    case  the implicit  binding is  between  the IP  entities in  each
    host.  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 [10].

    TULIP  changes nothing  in  the abstract  architecture  of the  IP
    model, since each host or router 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


Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 10]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


    Encapsulation   In setup message            Demultiplexing
    -------------+--------------------------+------------------------
    SNAP/LLC     _ nothing                  _ source and destination
                 _                          _ address, protocol
                 _                          _ family, protocol, ports
                 _                          _
    NULL encaps  _ protocol family          _ source and destination
                 _                          _ address, protocol, ports
                 _                          _
    TULIP        _ source and destination   _ protocol, ports
                 _ address, protocol family _
                 _                          _
    TUNIC - A    _ source and destination   _ ports
                 _ address, protocol family _
                 _ protocol                 _
                 _                          _
    TUNIC - B    _ source and destination   _ nothing
                 _ address, protocol family _
                 _ protocol, ports          _



               Table 1:  Summary of Encapsulation Types

    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 [10].



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 1.

Encapsulations such as  TULIP and TUNIC  make assumptions with  regard
to the  desirability  to  support  connection  oriented  flow.     The
tradeoffs between connection oriented and connectionless are discussed
in Section 5.






Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 11]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


5 Connection Oriented and Connectionless Tradeoffs


The connection  oriented  and  connectionless  approaches  each  offer
advantages and disadvantages.  In  the past, strong advocates  of pure
connection oriented and pure connectionless architectures  have argued
intensely.  IP over ATM  does not need to be purely  connectionless or
purely connection oriented.

ATM with basic AAL  5 service is  connection oriented.   The IP  layer
above ATM is  connectionless.   On top of  IP much  of the traffic  is
supported by TCP, a reliable end-to-end connection  oriented protocol.
A fundamental  question is  to what  degree is  it  beneficial to  map
different flows above IP into separate connections below IP.  There is
a broad spectrum of opinion on this.

As stated in section 4,  at one end of  the spectrum, IP would  remain
highly connectionless and set up single VCs between routers  which are
adjacent on an IP subnet and for which there was  active traffic flow.
All traffic between the such routers would be multiplexed on  a single
ATM VC. At  the other end  of the  spectrum, a  separate ATM VC  would
be created for each identifiable  flow.  For  every unique TCP or  UDP
address and port pair encountered a new VC would be required.  Part of
the intensity of early  arguments has been  over failure to  recognize
that there is a middle ground.

ATM offers  QoS  and traffic  management  capabilities that  are  well
suited for certain types of services.   It may be advantageous  to use
separate ATM VC for  such services.   Other IP  services such as  DNS,
are ill suited for connection  oriented delivery, due to  their normal
very short duration (typically one  packet in each direction).   Short
duration transactions, even many using TCP, may also be  poorly suited
for a  connection oriented  model  due to  setup and  state  overhead.
ATM QoS and traffic management  capabilities may be poorly suited  for
elastic traffic.

Work in progress is addressing how QoS requirements might be expressed
and how  the  local  decisions  might  be made  as  to  whether  those
requirements are best and/or most cost effectively  accomplished using
ATM or  IP capabilities.    Table 2,  Table 3,  and  Table 4  describe
typical treatment of various types of traffic using a  pure connection
oriented approach,  middle ground  approach,  and pure  connectionless
approach.

The  above   qualitative  description   of   connection  oriented   vs
connectionless service serve only as examples to  illustrate differing
approaches.   Work in  the area of  an integrated  service model,  QoS
and resource  reservation are  related  to but  outside the  scope  of
the IP over  ATM Work  Group.   This work  falls under the  Integrated
Services Work  Group (int-serv)  and Reservation  Protocol Work  Group
(rsvp), and will ultimately determine when direct connections  will be

Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 12]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


    APPLICATION       Pure Connection Oriented Approach
    ----------------+-------------------------------------------------
    General         _ Always set up a VC
                    _
    Short Duration  _ Set up a VC.  Either hold the packet during VC
    UDP (DNS)       _ setup or drop it and await a retransmission.
                    _ Teardown on a timer basis.
                    _
    Short Duration  _ Set up a VC.  Either hold packet(s) during VC
    TCP (SMTP)      _ setup or drop them and await retransmission.
                    _ Teardown on detection of FIN-ACK or on a timer
                    _ basis.
                    _
    Elastic (TCP)   _ Set up a VC same as above.  No clear method to
    Bulk Transfer   _ set QoS parameters has emerged.
                    _
    Real Time       _ Set up a VC.  QoS parameters are assumed to
    (audio, video)  _ precede traffic in RSVP or be carried in some
                    _ form within the traffic itself.



Table 2:    Connection  Oriented vs.     Connectionless -  a)  a  pure
connection oriented approach

established.  The IP over ATM Work Group can make  more rapid progress
if concentrating solely on how direct connections are established.



6 Crossing IP Subnet Boundaries


A single IP subnet will  not scale well to  a large size.   Techniques
which extend the size of an IP subnet in other media include MAC layer
bridging, and proxy ARP bridging.

MAC layer  bridging  alone  does  not  scale well.     Protocols  such
as ARP  rely on  the media  broadcast to  exchange address  resolution
information.     Most  bridges  improve  scaling   characteristics  by
capturing ARP packets and retaining the content, and  distributing the
information among bridging peers.   The ARP information gathered  from
ARP replies is broadcast  only where explicit  ARP requests are  made.
This technique is known as proxy ARP.

Proxy ARP bridging improves scaling by reducing broadcast traffic, but
still suffers scaling problems.  If the bridged IP subnet is part of a
larger internetwork, a routing  protocol is required to indicate  what
destinations are beyond the IP  subnet unless a statically  configured
default route is used.  A  default route is only applicable to  a very


Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 13]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995












    APPLICATION       Middle Ground
    ----------------+-------------------------------------------------
    General         _ Use RSVP or other indication which clearly
                    _ indicate a VC is needed and what QoS parameters
                    _ are appropriate.
                    _
    Short Duration  _ Forward hop by hop.  RSVP is unlikely to precede
    UDP (DNS)       _ this type of traffic.
                    _
    Short Duration  _ Forward hop by hop unless RSVP indicates
    TCP (SMTP)      _ otherwise.  RSVP is unlikely to precede this
                    _ type of traffic.
                    _
    Elastic (TCP)   _ By default hop by hop forwarding is used.
    Bulk Transfer   _ However, RSVP information, local configuration
                    _ about TCP port number usage, or a locally
                    _ implemented method for passing QoS information
                    _ from the application to the IP/ATM driver may
                    _ allow/suggest the establishment of direct VCs.
                    _
    Real Time       _ Forward hop by hop unless RSVP indicates
    (audio, video)  _ otherwise.  RSVP will indicate QoS requirements.
                    _ It is assumed RSVP will generally be used for
                    _ this case.  A local decision can be made as to
                       _ whether the  QoS is better served by  a sepa-
rate VC.



Table 3:  Connection Oriented vs.  Connectionless - b) a middle ground
approach











Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 14]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995














    APPLICATION       Pure Connectionless Approach
    ----------------+-------------------------------------------------
    General         _ Always forward hop by hop.  Use queueing
                    _ algorithms implemented at the IP layer to
                    _ support reservations such as those specified by
                    _ RSVP.
                    _
    Short Duration  _ Forward hop by hop.
    UDP (DNS)       _
                    _
    Short Duration  _ Forward hop by hop.
    TCP (SMTP)      _
                    _
    Elastic (TCP)   _ Forward hop by hop.  Assume ability of TCP to
    Bulk Transfer   _ share bandwidth (within a VBR VC) works as well
                    _ or better than ATM traffic management.
                    _
    Real Time       _ Forward hop by hop.  Assume that queueing
    (audio, video)  _ algorithms at the IP level can be designed to
                    _ work with sufficiently good performance
                               _  (e.g., due  to  support for  predic-
tive reservation).



Table 4:    Connection  Oriented vs.     Connectionless -  c)  a  pure
connectionless approach













Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 15]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


simple topology  with respect  to the  larger internet  and creates  a
single point of failure.   Because  internets of enormous size  create
scaling problems for routing protocols, the component networks of such
large internets are often  partitioned into areas, autonomous  systems
or routing domains, and routing confederacies.

The scaling limits of the simple IP subnet require a  large network to
be partitioned into  smaller IP  subnets.   For NBMA  media like  ATM,
there are advantages to creating direct connections across  the entire
underlying NBMA network.    This leads  to the need  to create  direct
connections across IP subnet boundaries.

For example,  figure 3  shows an  end-to-end configuration  consisting
of four components,  three of  which are ATM  technology based,  while
the fourth  is  a standard  IP  subnet  based on  non-ATM  technology.
End-systems (either  hosts  or  routers)  attached  to  the  ATM-based
networks may  communicate  either  using  the Classical  IP  model  or
directly via ATM  (subject to  policy constraints).    Such nodes  may
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 (see Section 8.1 below).

Many of the problems and  issues associated with creating such  direct
connections across subnet boundaries  were originally being  addressed
in the IETF's IPLPDN working group and the IP over  ATM working group.
This area is  now being  addressed in  the Routing  over Large  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 [5]  over SMDS  networks.   The ROLC  working group  has
produced the distributed ARP server architectures and the NBMA Address
Resolution Protocol  (NARP) [7].    The Next  Hop Resolution  Protocol
(NHRP) is still work  in progress, though  the ROLC WG is  considering
advancing the current draft.  Questions/issues specifically related to
defining a capability to cross IP subnet boundaries include:


  o How  can routing be optimized  across multiple logical IP  subnets
    over both  a common ATM based and a non-ATM  based infrastructure.
    For example,  in Figure 3, there are two  gateways/routers between
    the  non-ATM  subnet  and the  ATM  subnets.    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
    routers.

  o How to incorporate policy routing constraints.

  o What   is  the  proper  coupling   between  routing  and   address
    resolution particularly with respect to off-subnet communication.


Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 16]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995



















Figure 3:   A  configuration  with both  ATM-based and  non-ATM  based
subnets.


  o What  are  the  local  procedures to  be  followed  by  hosts  and
    routers.

  o Routing  between  hosts not  sharing  a  common IP-level  (or  L3)
    network  prefix, but  able to  be directly connected  at the  NBMA
    media 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 [5], RFC--1735 [7] and NHRP).

  o How to identify the need for  and accommodate special purpose SVCs
    for control or routing and high bandwidth data transfers.


For ATM  (unlike  other  NBMA  media),  an  additional  complexity  in
supporting  IP  routing   over  these  ATM   internets  lies  in   the
multiplicity of address formats in UNI 3.0 [4].   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  network points  of
attachment, it seems  that E.164  only networks are  to be  considered
as subordinate to  ``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).




Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 17]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995

























     Figure 4:  A Routing Loop Due to Lost PV Routing Attributes.


7 Extensions to IP Routing


RFC--1620 [3] describes the problems and issues associated with direct
connections across IP subnet boundaries in greater detail, as  well as
possible solution approaches.   The ROLC WG has identified  persistent
routing  loop  problems  that  can  occur  if  protocols   which  lose
information critical to path vector routing protocol  loop suppression
are used to accomplish direct connections across IP subnet boundaries.
The problems may arise when a destination network which is  not on the
NBMA network is reachable via  different routers attached to the  NBMA
network.   This problem occurs  with proposals  that attempt to  carry
reachability information, but do  not carry full path attributes  (for
path vector routing)  needed for  inter-AS path  suppression, or  full
metrics (for distance vector or link state routing even if path vector
routing is not used) for intra-AS routing.

There are many  potential scenarios  for routing  loops.   An  example
is given in Figure  4.   It is possible  to produce a simpler  example
where a loop can  form.   The example in  Figure 4 illustrates a  loop
which will persist even if the protocol on the NBMA supports redirects
or can invalidate  any route which  changes in any  way, but does  not
support the communication of full metrics or path attributes.



Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 18]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


In the example in Figure 4,  Host 1 is sending traffic toward  Host 2.
In practice, host  routes would not  be used,  so the destination  for
the purpose of  routing would  be Subnet 3.    The traffic travels  by
way of Router 1  which establishes a  ``cut-through'' SVC to the  NBMA
next-hop, shown here as Router 2.  Router 2  forwards traffic destined
for Subnet 3 through Subnet 2 to Router 3.  Traffic from  Host 1 would
then reach Host 2.

Router 1's cut-through  routing implementation  caches an  association
between Host  2's IP  address (or  more likely  all of  Subnet 3)  and
Router 2's  NBMA address.    While the  cut-through SVC  is still  up,
Link 1 fails.   Router 5 loses it's  preferred route through Router  3
and must  direct traffic  in  the other  direction.    Router 2  loses
a route through  Router 3,  but picks  up an  alternate route  through
Router 5.   Router 1 is  still directing traffic  toward Router 2  and
advertising a means of reaching  Subnet 3 to Subnet  1.  Router 5  and
Router 2 will see a route, creating a loop.

This loop  would not  form  if path  information normally  carried  by
interdomain routing  protocols  such as  BGP  and IDRP  were  retained
across the NBMA. Router 2 would reject the initial route from Router 5
due to the  path information.   When  Router 2  declares the route  to
Subnet 3 unreachable,  Router 1  withdraws the route  from routing  at
Subnet 1, leaving the route  through Router 4, which would  then reach
Router 5, and would reach Router 2 through both Router 1 and Router 5.
Similarly, a link state protocol would not form such a loop.

Two proposals  for  breaking  this  form of  routing  loop  have  been
discussed.   Redirect  in this  example would  have no  effect,  since
Router 2 still has  a route, just  has different path  attributes.   A
second proposal is that is that  when a route changes in any  way, the
advertising NBMA cut-through router invalidates the  advertisement for
some time period.   This is  similar to the  notion of Poison  Reverse
in distance  vector routing  protocols.   In  this example,  Router  2
would eventually readvertise a  route since a  route through Router  6
exists.  When Router 1  discovers this route, it will advertise  it to
Subnet 1 and form the loop.  Without path information, Router 1 cannot
distinguish between a loop and  restoration of normal service  through
the link L1.

The loop  in Figure  4 can  be prevented  by configuring  Router 4  or
Router 5 to refuse to use the  reverse path.  This would  break backup
connectivity through Router 8 if L1 and L3 failed.  The  loop can also
be broken by configuring  Router 2 to refuse  to use the path  through
Router 5 unless  it could  not reach the  NBMA. Special  configuration
of Router 2  would work  as long as  Router 2  was not distanced  from
Router 3 and  Router 5 by  additional subnets such  that it could  not
determine which path was in use.  If Subnet 1 is in a  different AS or
RD than Subnet 2 or Subnet 4,  then the decision at Router 2  could be
based on path information.


Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 19]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995










Figure 5:  The Classical IP model as a concatenation of three separate
ATM IP subnets.


In order  for  loops  to  be prevented  by  special  configuration  at
the NBMA  border router,  that router  would  need to  know all  paths
that could  lead back  to the  NBMA. The  same  argument that  special
configuration could overcome  loss of  path information  was posed  in
favor of retaining  the use  of the  EGP protocol defined  in the  now
historic RFC--904 [11].    This turned  out to  be unmanageable,  with
routing problems occurring when topology was changed elsewhere.



8 IP Over ATM Proposals


8.1 The Classical IP Model


The Classical IP Model was  suggested at the Spring 1993  IETF meeting
[8] and retains  the classical  IP subnet  architecture.   This  model
simply consists of cascading instances of IP subnets with IP-level (or
L3) routers at  IP subnet  borders.   An example  realization of  this
model consists of a concatenation of three IP subnets.   This is shown
in Figure 5.   Forwarding IP packets over  this Classical IP model  is
straight forward using already well established routing techniques and
protocols.

SVC-based ATM IP subnets are simplified in that they:


  o limit the number of hosts which  must be directly connected at any
    given time to those that may actually exchange traffic.

  o The  ATM network  is  capable of  setting  up connections  between
    any  pair of  hosts.    Consistent with  the  standard IP  routing
    algorithm  [2] connectivity to the  ``outside'' world is  achieved
    only  through a router,  which may provide firewall  functionality
    if so desired.

  o The  IP  subnet  supports  an   efficient  mechanism  for  address


Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 20]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


    resolution.


Issues addressed by  the IP Over  ATM Working Group,  and some of  the
resolutions, for this model are:


  o Methods  of  encapsulation  and  multiplexing.     This  issue  is
    addressed in RFC--1483 [6], in  which two methods of encapsulation
    are defined, an LLC/SNAP and a per-VC multiplexing option.

  o The  definition  of  an  address  resolution  server  (defined  in
    RFC--1577).

  o Defining  the  default MTU  size.    This  issue is  addressed  in
    RFC--1626  [1]  which  proposes  the  use  of  the  MTU  discovery
    protocol (RFC--1191 [9]).

  o Support for  IP multicasting.  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 currently  defined by
    a set of IP over ATM  WG Internet Drafts, referred to collectively
    as  the IPMC  drafts.   In order  to support  IP multicasting  the
    ATM  subnet  must either  support  point-to- multipoint  SVCs,  or
    multicast servers, or both.

  o Defining  interim  SVC  parameters,  such as  QoS  parameters  and
    time-out values.

  o Signaling  and  negotiations  of  parameters   such  as  MTU  size
    and  method  of  encapsulation.     RFC--1755  [10]  describes  an
    implementation  agreement for  routers signaling  the ATM  network
    to  establish  SVCs  initially  based upon  the  ATM  Forum's  UNI
    version  3.0  specification  [4],   and  eventually  to  be  based
    upon  the ATM Forum's  UNI version  3.1 and later  specifications.
    Topics  addressed in RFC--1755  include (but  are not limited  to)
    VC  management  procedures,  e.g.,  when  to  time-out  SVCs,  QOS
    parameters,  service classes, explicit  setup message formats  for
    various  encapsulation  methods, node  (host  or router)  to  node
    negotiations, etc.


RFC-1577 is  also applicable  to PVC-based  subnets.    Full mesh  PVC
connectivity is required.

For more information see RFC--1577 [8].






Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 21]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


8.2 The ROLC NHRP Model


The Next Hop  Resolution Protocol  (NHRP), currently  a draft  defined
by the  Routing  Over  Large  Clouds Working  Group  (ROLC),  performs
address resolution to accomplish  direct connections across IP  subnet
boundaries.  NHRP can supplement RFC--1577 ARP. There has  been recent
discussion of replacing RFC--1577 ARP with NHRP. NHRP can also perform
a proxy address resolution to provide the address of the border router
serving a  destination off  of  the NBMA  which is  only  served by  a
single router on the  NBMA. NHRP as  currently defined cannot be  used
in this way to  support addresses learned  from routers for which  the
same destinations may be heard at  other routers, without the  risk of
creating persistent routing loops.


8.3 ``Conventional'' Model


The ``Conventional Model'' assumes that a router can relay  IP packets
cell by cell,  with the  VPI/VCI identifying a  flow between  adjacent
routers rather  than a  flow  between a  pair  of nodes.    A  latency
advantage can  be  provided  if  cell interleaving  from  multiple  IP
packets is allowed.  Interleaving frames within the same  VCI requires
an ATM  AAL such  as AAL3/4  rather than  AAL5.    Cell forwarding  is
accomplished through a higher level mapping, above the ATM VCI layer.

The conventional model is  not under consideration  by the IP/ATM  WG.
The COLIP  WG  has been  formed  to  develop protocols  based  on  the
conventional model.



8.4 The Peer Model


The Peer Model places IP routers/gateways on an addressing  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).   ATM network  entities and  the attached IP  hosts
or routers  exchange  call routing  information  on  a peer  basis  by
algorithmically mapping IP addressing into the NSAP space.  Within the
ATM cloud, ATM network level addressing (NSAP-style), call routing and
packet formats are used.

In the Peer Model no provision  is made for selection of  primary path
and use  of alternate  paths  in the  event  of primary  path  failure
in reaching  multihomed non-ATM  destinations.   This  will limit  the
topologies for which the peer model alone is applicable to  only those
topologies in which non-ATM networks  are singly homed, or  where loss
of backup connectivity is not an issue.  The Peer Model may be used to

Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 22]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


avoid the need for an  address resolution protocol and in  a proxy-ARP
mode for stub networks, in conjunction with other  mechanisms suitable
to handle multihomed destinations.

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
was not an  initial priority  of the  working group  to address  these
issues.  The ATM  Forum Network Layer Multiprotocol Working  Group has
reached a similar conclusion.


8.5 The PNNI and the Integrated Models


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.

The PNNI is a hierarchical  link state routing protocol with  multiple
link metrics providing various available QoS parameters  given current
loading.  Call  route selection takes  into account QoS  requirements.
Hysteresis  is  built  into  link  metric  readvertisements  in  order
to avoid  computational  overload  and  topological  hierarchy  serves
to subdivide  and  summarize  complex  topologies,  helping  to  bound
computational requirements.

Integrated Routing is a proposal to use PNNI routing as  an IP routing
protocol.  There are several sets of technical issues that  need to be
addressed, including the  interaction of  multiple routing  protocols,
adaptation of PNNI to broadcast  media, support for NHRP,  and others.
These are being investigated.   However, the  ATM Forum MPOA group  is
not currently performing  this investigation.   Concerned  individuals
are, with an expectation of bringing the work to the ATM Forum and the
IETF.

PNNI has provisions for carrying uninterpreted information.  While not
yet defined, a compatible extension of the base PNNI could  be used to
carry external routing attributes and avoid the routing  loop problems
described in Section 7.






Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 23]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995
















Figure 6:  The ATM transition model assuming the presence  of gateways
or routers between the ATM networks and the ATM peer networks.


8.6 Transition Models


Finally, it is useful to  consider transition models, lying  somewhere
between the Classical IP  Models and the  Peer and Integrated  Models.
Some possible architectures for transition models have  been suggested
by Fong Liaw.   Others are  possible, for example  Figure 6 showing  a
Classical IP transition model which  assumes the presence of  gateways
between ATM networks and ATM Peer networks.

Some of  the models  described  in the  prior sections,  most  notably
the Integrated Model, anticipate  the need for mixed environment  with
complex routing  topologies.    These  inherently  support  transition
(possibly with an indefinite transition period).  Models which provide
no transition support  are primarily  of interest  to new  deployments
which make  exclusive, or  near exclusive  use of  ATM or  deployments
capable of wholesale  replacement of existing  networks or willing  to
retain only non-ATM stub networks.

For some models, most  notably the Peer  Model, the ability to  attach
to a large non-ATM or mixed internetwork is infeasible without routing
support at  a  higher  level,  or  at best  may  pose  interconnection
topology constraints (for example:   single point of attachment and  a
static default route).  If a particular model requires routing support
at a  higher level  a  large deployment  will  need to  be  subdivided
to provide  scalability at  the higher  level, which  for some  models
degenerates back to the Classical model.







Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 24]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


9 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  [6], RFC--1577  [8],  RFC--1626 [1],  RFC--1755
[10] and the IPMC drafts.   The ROLC  WG has produced the NHRP  draft.
Table 5 gives a summary  of these documents and their  relationship to
the various IP Over ATM Models.


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 was 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).
M. Ohta provided a description of the Conventional Model  (again which
the authors  modified at  their  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



David H. Shur
AT&T Bell Laboratories
101 Crawfords Corner Road, Rm. 1F-338
Holmdel, NJ 07733
Phone: (908) 949-6719

Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 25]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995







    Documents         Summary
    ----------------+-------------------------------------------------
    RFC-1483        _ How to identify/label multiple
                    _ packet/frame-based protocols multiplexed over
                    _ ATM AAL5. Applies to any model dealing with IP
                    _ over ATM AAL5.
                    _
    RFC-1577        _ Model for transporting IP and ARP over ATM AAL5
                    _ in an IP subnet where all nodes share a common
                    _ IP network prefix.  Includes ARP server/Inv-ARP
                    _ packet formats and procedures for SVC/PVC
                    _ subnets.
                    _
    RFC-1626        _ 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.
                    _
    IPMC            _ 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).  IPMC is work in progress.
                    _
    NHRP            _ Describes a protocol that can be used by hosts
                    _ and routers to determine the NBMA next hop
                                          _  address  of   a  destina-
tion 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.  NHRP is work in progress (ROLC WG).



                  Table 5:  Summary of WG Documents






Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 26]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


Fax: (908) 949-5775
Email: d.shur@att.com


Curtis Villamizar
ANS
100 Clearbrook Road
Elmsford, NY 10523
Email: curtis@ans.net



References


 [1] R.  Atkinson.  Default IP  MTU for  use  over ATM  AAL5.  Request
     for Comments  (Experimental) RFC 1626, Internet  Engineering Task
     Force, May 1994.

 [2] R.  Braden and  J. Postel.  Requirements  for Internet  gateways.
     Request for  Comments (Standard)  RFC 1009, Internet  Engineering
     Task Force, June 1987. Obsoletes RFC-985.

 [3] 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.

 [4] ATM  Forum. ATM  User-Network Interface  Specification.  Prentice
     Hall, September 1993.

 [5] J.  Garrett,  J.  Hagan,  and  J.  Wong.  Directed  ARP.  Request
     for Comments  (Experimental) RFC 1433, Internet  Engineering Task
     Force, March 1993.

 [6] J.  Heinanen.  Multiprotocol  Encapsulation over  ATM  Adaptation
     Layer  5.  Request for  Comments  (Proposed Standard)  RFC  1483,
     Internet Engineering Task Force, July 1993.

 [7] J.  Heinanen and R.  Govindan. NBMA  Address Resolution  Protocol
     (NARP).  Request for Comments  (Experimental) RFC 1735,  Internet
     Engineering Task Force, December 1994.

 [8] M. Laubach.  Classical IP and ARP over ATM. Request  for Comments
     (Proposed Standard)  RFC 1577,  Internet Engineering Task  Force,
     January 1994.

 [9] J.  Mogul  and  S.  Deering.  Path  MTU  discovery.  Request  for
     Comments  (Draft Standard)  RFC 1191,  Internet Engineering  Task
     Force, November 1990.

[10] M.  Perez, F.  Liaw,  D. Grossman,  A.  Mankin,  and A.  Hoffman.

Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 27]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


     ATM  signalling support  for IP  over ATM.  Request for  Comments
     (Informational)  RFC  1755,   Internet  Engineering  Task  Force,
     January 1995.

[11] International Telegraph  and D. Mills. Exterior  Gateway Protocol
     formal specification.  Request for Comments (Historical)  STD 18,
     RFC 904, Internet Engineering Task Force, April 1984.



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 [4]  (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 [4] 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:


  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  [4], is  the responsibility  of ingress switch  to the  public
    network.



Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 28]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


  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  [4],
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.



  o Public  network  host  to  Public  network  host,  no  intervening
    private network:  In this case,  clearly the Q.2931 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,

Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 29]


INTERNET-DRAFT    IP over ATM: A Framework Document    October 2, 1995


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.
















































Cole, Shur, Villamizar        Expires  April 2, 1996         [Page 30]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/