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 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.
++++++++++++++++++++++++++++++++++++++++++
+ .------------. .------------. +
.---------. + .-: :-. .-: :-. +
: Host or >-+-< : Single ATM : >--< : Single ATM : >-+-----\
: Router : + : : Domain : : : : Domain : : + :
--------- + -: :- -: :- + .---^----.
+ ------------ ------------ + : Router :
+ .------------. + ---v----
.---------. + .-: :-. + :
: Host or >-+- ... ... --< : Single ATM : >-+-----/
: Router : + : : Domain : : +
--------- + ATM Cloud -: :- +
+ ------------ +
++++++++++++++++++++++++++++++++++++++++++
Note: IS within ATM cloud are ATM IS
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.
9. Application of the Working Group's and Related Documents
The IP Over ATM Working Group has generated several Works in Progress
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 documents and RFCs produced to date are the
following references, RFC-1483 [6], RFC-1577 [8], RFC-1626 [1], RFC-
1755 [10] and the IPMC documents. The ROLC WG has produced the NHRP
document. Table 5 gives a summary of these documents and their
relationship to the various IP Over ATM Models.
Acknowledgments
This memo 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 memo.
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 memo also has
benefitted from numerous suggestions from John T. Amenyo of ANS, Joel
Halpern of Newbridge, and Andy Malis of Ascom-Timplex. Yakov Rekhter
of Cisco provided valuable comments leading to the clarification of
normal loop free NHRP operation and the potential for routing loop
problems only with the improper use of NHRP.
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 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. NHRP is work in progress (ROLC WG).
Table 5: Summary of WG Documents
References
[1] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC1626,
Naval Research Laboratory, May 1994.
[2] Braden, R., and J. Postel, "Requirements for Internet Gateways",
STD 4, RFC1009, USC/Information Sciences Institute, June 1987.
[3] Braden, R., Postel, J., and Y. Rekhter, "Internet Architecture
Extensions for Shared Media", RFC1620, USC/Information Sciences
Institute, IBM Research, May 1994.
[4] ATM Forum, "ATM User-Network Interface Specification", Prentice
Hall, September 1993.
[5] Garrett, J., Hagan, J., and J. Wong, "Directed ARP", RFC1433,
AT&T Bell Labs, University of Pennsylvania, March 1993.
[6] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC1483, Telecom Finland, July 1993.
[7] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol
(NARP)", RFC1735, Telecom Finland, USC/Information Sciences
Institute, December 1994.
[8] Laubach, M., "Classical IP and ARP over ATM", RFC1577,
Hewlett-Packard Laboratories, January 1994.
[9] Mogul, J., and S. Deering, "Path MTU Discovery", RFC1191,
DECWRL, Stanford University, November 1990.
[10] Perez, M., Liaw, F., Grossman, D., Mankin, A., and A. Hoffman,
"ATM signalling support for IP over ATM", RFC1755,
USC/Information Sciences Institute, FORE Systems, Inc., Motorola
Codex, Ascom Timeplex, Inc., January 1995.
[11] Mills, D., "Exterior Gateway Protocol Formal Specification",
STD 18, RFC904, BBN, 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.
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,
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.
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
Fax: (908) 949-5775
EMail: d.shur@att.com
Curtis Villamizar
ANS
100 Clearbrook Road
Elmsford, NY 10523
EMail: curtis@ans.net