Internet DRAFT - draft-ietf-atm-framework-doc
draft-ietf-atm-framework-doc
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:55:47 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 19 Jan 1994 23:00:00 GMT
ETag: "2e9d8d-91df-2d3dbb70"
Accept-Ranges: bytes
Content-Length: 37343
Connection: close
Content-Type: text/plain
DRAFT IP over ATM: A Framework Document January 1994
Network Working Group Robert G. Cole
INTERNET DRAFT AT&T Bell Laboratories
Expires July 10, 1994 January 11, 1994
<draft-ietf-atm-framework-doc-00.txt>
IP over ATM: A Framework Document
Status of this Memo
This memo 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
This memo summarizes some of the discussions of the IP over ATM
working group over the last year. This summary is provided in the
form of a framework which categorizes the various ATM subnet models
and End- to-End models identified by the working group. The intent of
this framework is to help partition the efforts of the working group
to focus on smaller, more manageable aspects of IP over ATM. This is
deemed necessary due to the number of ATM subnet types being
discussed. The subnet models identified in this memo are:
o an SVC-based LAN ATM (LATM) subnet,
o a PVC-based WAN ATM (WATM) subnet, and
o an SVC-based WATM subnet.
The End-to-End models identified in this memo are:
o End-to-End Subnet Models, including
Cole [Page 1]
DRAFT IP over ATM: A Framework Document January 1994
- the Classical IP model,
- an SVC-based WATM subnet model, and
- lightweight subnet models, i.e. TUNIC and TULIP, and
o Peer Models.
2. Introduction
The IP over ATM Working Group of the Internet Engineering Task
Force (IETF) is chartered to develop stan dards for routing and
forwarding IP packets over ATM subnets. There are several
difficulties with this charter, as witnessed in the discussions
of this group over the last several years. First, asynchronous
transfer mode (ATM) technology is still in its development state.
Second, the flexibility of the technology, allows and in fact
encourages, viewing ATM as different subnet technologies, e.g., a
LAN, a WAN, an Internet, etc. Therefore, much of the discussions
of the IP over ATM WG have centered around not only how to carry
IP traffic over ATM but what is ATM. This memorandum attempts to
highlight some of these discussions and tries to cate gorize the
various ATM subnet architectures and End-to-End architectures
that have been proposed.
It is felt that to promote progress in the IP over ATM working
group, it is first necessary to come to some consensus on the
types of ATM subnets to be addressed. Then it will be possible to
focus attention of several subgroups to work the issues of
routing IP packets over these different ATM subnets. As this work
is proceed ing, parallel efforts in identifying issues to work in
the eventual end-to-end ATM models can be performed. It is
expected that defining IP routing over some ATM subnet types and
simpler end-to-end models can pro ceed at a quicker pace, while
there exist many fundamental architectural issues in defining
peer end-to-end models. Therefore, it is hoped that this
document, in classifying the subnet and end-to-end models, will
help in focusing the IP over ATM working group's direction over
the next several IETF meetings.
The remainder of this memorandum is organized as follows:
o Section4 presents several definitions of use in the later
sections,
o Section 5 discusses/identifies the various subnet models
proposed to date by the IP over ATM working group,
o Section 6 identifies several promising end-to-end networking
Cole [Page 2]
DRAFT IP over ATM: A Framework Document January 1994
configurations, and
o Section 7 contains conclusions.
3. PARAMETERS DEFINING SUBNET TECHNOLOGIES
Following ISO we define several terms [ISO 8473]:
o A Subnet is a connected communication network consisting of a
single networking technology. Subnets are further categorized
into broadcast and general topology subnetworks.
o A Broadcast Subnet `supports an arbitrary number of end systems
and intermediate systems and additionally is capable of
transmitting a single Subnetwork NPDU (SNPDU) to a subset of
these systems in response to a single send_unitdata request'.
o A General Topology Subnet `supports an arbitrary number of end
systems and intermediate systems but does not support a
convenient multi-destination connectionless transmission
facility, as does a broadcast subnetwork'. We will hereafter
interchangeably use the terms general topology subnet and Non-
Broadcast Multiple Access (NBMA) subnet.
o An End System `delivers Network Level Protocol Data Units
(NPDUs) to other systems and receives NPDUs from other systems,
but do not relay NPDUs.'
o An Intermediate System `delivers and receives NPDUs from other
systems, and relays NPDUs from other systems to other destination
systems.' They route to end systems within their own area and to
other intermediate systems when the destination is within another
area.
o An End-to-End path consists of two end systems which can
communicate with one another over an arbitrary number of
intermediate systems and subnets connecting the end and
intermediate systems.
From the perspective of the subnet, it sees no difference between
the end systems and intermediate systems. Therefore, we will
define a Subnet End Systems (Sub-ES) as a network level routing
entity connected to the subnet, whether it is actually an end or
intermediate system. Figure 1 shows two subnet end systems
connect ed over a single subnet. An IP-level (or L3 level) end-
to-end path can be considered as a concatenation of multiple IP-
Cole [Page 3]
DRAFT IP over ATM: A Framework Document January 1994
level (or L3) single hop paths.
Each subnet technology is characterized in terms of several
parameters. We have defined two subnet types, i.e. a broadcast
and a general topology, or NBMA, subnet. However, it is possible
to further specify subnet types within these broad categories.
Towards this end, we list here a few of the more relevant
parameters for the discussions to follow; this list is by no
means exhaustive.
They are:
o Routing and Addressing Capabilities,
o Topology and Geographic Support, e.g.,
- LAN versus WAN, and
- the number of stations supported,
o Transport Services, e.g.,
- Connection-Oriented Network Service (CONS) versus
Connectionless Network Service (CLNS), and
- Variable Bit Rate (VBR) versus Constant Bit Rate (CBR)
Services,
o Connection Functions, e.g.,
- Permanent Virtual Connection (PVC) or Switched Virtual
Connection (SVC), and
- point-to-point, multicast, or broadcast,
o Transmission Characteristics, e.g.,
- reliable versus unreliable (e.g., guaranteed delivery as in
X.25 or best effort as in Frame Relay),
- priorities, and
- qualities of service,
o Security Features, and
o Packet Parameters (e.g., max MTU size, etc.).
4. CLASSIFICATION OF ATM SUBNETS
Several ATM subnets have been discussed by the IP over ATM working
group. These range from the Broad band-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. Further, other
subnets are defined on ATM as overlay subnets, e.g. Frame Relay on
ATM.
Cole [Page 4]
DRAFT IP over ATM: A Framework Document January 1994
We identify and discuss here three possible ATM subnets; a LAN-ATM
(LATM) subnet, a PVC-based WAN- ATM (WATM) subnet, and a SVC-based
WATM subnet.
4.1 The LATM Subnet Model
The LAN-ATM (LATM) subnet is characterized as having a small number
of end systems, e.g., up to at most a few thousand, which:
o are directly connected,
o share a common IP-level (or L3) network prefix,
o support switched virtual connections (SVCs) as well as permanent
virtual connections (PVCs),
o support an efficient broadcast/multicast/connectionless server
for address resolution, and
o are part of a single working group, e.g. security is not an
issue. (Note: An assumption for the LATM is that all end systems
attached to the LATM are part of the same administrative domain
and that the ATM network will setup up connections between any
pair of end systems. Connectivity to the `outside' world is
achieved only through a router which will provide the firewall if
so desired.)
For end systems to forward packets over this subnet, many of the
mechanisms for forwarding IP packets over ethernet subnets apply and
are presented in [LAU 93]. Issues to be worked in defining IP over
the LATM sub net are:
o Defining the VPI/VCIs for address resolution, (Many internal
architectures are possible ranging from, possibly, a broadcast
capability to the existence of an ARP server reachable on the
identified VPI/VCI. It is the belief of the IP over ATM group
that the architecture of address resolution needs to be specified
and that the ARP server architecture is the desired option. The
APR server is specified in [LAU 93].)
o Defining the maximum MTU size, (This has been the subject of
considerable debate over the Internet this spring. This issue is
addressed in [ATK 93].)
o Methods of encapsulation and multiplexing, (This issue is
addressed in [HEI 93a].)
o Reliability of the ARP server mechanism defined in [LAU 93],
Cole [Page 5]
DRAFT IP over ATM: A Framework Document January 1994
o Support for IP multicasting,
o Defining SVC optimization techniques, e.g., timeout mechanisms,
o Negotiations of, e.g., MTU size, method of encapsulation, and
o Special purpose SVC for control/routing and high bandwidth data
transfers.
The majority of the work here is in defining the interface between
the Sub-ESs and the LATM, e.g., what VPI/ VCIs to be used to access
the ARP server [LAU 93], the method of encapsulation, the maximum MTU
sizes, signalling capabilities, etc. However, other work items
involve more internal architectural issues such as the architectures
for ARP services.
4.2 The PVC WATM Subnet Model
The PVC-based WATM is a general topology, or NBMA, subnet which is
further characterized as having a large number of end systems, e.g.,
up to at most a few tens of thousands, which:
o are not all directly connected,
o do not 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 are not part of a single working group, however security is not
an issue due to the permanent nature of the virtual connections.
For end systems to forward packets over this subnet, many of the
mechanisms defined for forwarding IP pack ets over Frame Relay
subnets apply, see [RFC 1490]. Issues to be worked in defining IP
over the LATM sub net are:
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] and [LAU 93].)
o Methods of encapsulation and multiplexing, (This issue is
addressed in [HEI 93a].)
o Defining the maximum MTU size, (This issue is addressed in [ATK
93].) and
Cole [Page 6]
DRAFT IP over ATM: A Framework Document January 1994
o Support for IP multicasting.
The majority of the work here is in specifying the Inv-ARP details
and in defining the MTU sizes supported.
4.3 The SVC WATM Subnet Model
The SVC-based WATM is a general topology, or NBMA, subnet which is
further characterized as having a 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 Maybe directly connected, due to the existence of SVCs,
o Do not share a common IP-level (or L3) network prefix,
o Support for multiple subnetwork point of attachment (SNPA)
address formats (four possible formats are allowed in [ATM
1993]),
o Support negotiations for, e.g., MTU size, methods of
encapsulation,
o Do not have to support an efficient broadcast/multicast
mechanism for address resolution,
o Are not part of a single working group and hence security is an
issue, and
o Are potentially billed for holding circuit holding time.
For end systems to forward packets over this subnet, many of the
problems which were being addressed in the IETF's IPLPDN working
group, the IP over ATM working group, and are now to be addressed in
the Rout ing over Large Clouds [HAL 93], are applicable. Examples of
work performed in the IPLPDN working group include short-cut routing
[TSU 93] and directed ARP [GAR 93] over SMDS subnets, and in the IP
over ATM working group include distributed ARP server architectures
in [HEI 93b]. Issues to be worked for the SVC WATM subnet include:
o Defining the details for an efficient address resolution
architecture, (Work in this area has been started, see [GAR 93],
and [HEI 93b].)
o Methods of encapsulation and multiplexing, (This issue is
Cole [Page 7]
DRAFT IP over ATM: A Framework Document January 1994
addressed in [HEI 93a].)
o Defining the default MTU size, (This issue is addressed in [ATK
93].)
o Defining security procedures,
o Routing between end systems not sharing a common IP-level (or
L3) network prefix, but attached to the same subnet,
o Support for IP multicasting,
o Defining SVC optimization techniques, e.g., timeout mechanisms,
o Negotiations of, e.g., MTU size, method of encapsulation, and
o Special purpose SVC for control/routing and high bandwidth data
transfers.
Whereas the first two subnets presented above, i.e. the LATM and
PVC-Based WATM, are more straight for ward in defining routing of IP
packets over these subnets, the SVC-Based WATM presents several hard
prob lems to be resolved prior to specifying IP routing over it.
Several of these issues are the focus of the new Routing over Large
Clouds working group formed in July 1993.
5. 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 cast out the
traditional subnet architectures in favor of ATM Internet models. We
categorize these different models in terms of wheth er the ATM
network and IP-level (or L3) routers are considered as peers, i.e.
they exchange routing informa tion, 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, where as the Peer Models pro pose a new way of IP
networking. 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.
Cole [Page 8]
DRAFT IP over ATM: A Framework Document January 1994
5.1 Subnet Models
Three end-to-end subnet models were identified at the Columbus
(March/Spring 1993) and Amsterdam (July/ Summer) IETF meetings of the
IP over ATM working group. These three models are
o The Classical IP Model,
o The SVC-based WATM subnet model, and
o Lightweight subnet models.
5.1.1 The Classical IP Model
The Classical IP Model was suggested at the Spring 1993 IETF meeting
[LAU 93]. This model simply con sists of cascading subnet models
discussed above 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 below. Once
the details of specifying routing and forwarding IP packets over the
compo nent 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 [ATM 1993],
o support a single default MTU size, and
o support a default LLC/SNAP encapsulation as specified in [HEI
93a].
For more information see [LAU 93].
5.1.2 The SVC-based WATM subnet
The SVC-based WATM subnet was discussed in Section 5.3. Here the
subnet supports a huge number of ESs in a dynamic SVC environment.
There are several problems to address to bring this end-to-end subnet
model to fruition. These include, but are not limited to, the
following:
o What are the appropriate architectures for address resolution,
and
o How can routing be optimized across multiple logical IP subnets
on a common ATM infrastructure, e.g. the short-cut routing
problem.
Cole [Page 9]
DRAFT IP over ATM: A Framework Document January 1994
The work on these problems may be worked separately from the near
term work on bringing the Classical IP model to fruition. Figure 3
shows an example of an SVC-based WATM subnet consisting of three
compo nents, two SVC LATM networks connected by a single PVC or SVC
WATM network. More complex ATM internets are envisioned and solutions
to networking over SVC-based WATM subnets must be able to support
these complex internets and their attending problems. Many of the
routing and other internetworking issues associated with this model
are now to be addressed in the newly formed Routing over Large Clouds
working group.
An additional complexity in supporting IP routing over these ATM
internets lies in the multiplicity of subnet work points of
attachment address formats in [ATM 93]. 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 sup ported 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 `private networks', in some sense. This leads to some
confusion in defining an ARP mecha nism 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).
5.1.3 Lightweight subnet models
Two further models can be identified which have the characteristic of
largely or totally eliminating IP header overheads. These models were
discussed in the July IETF meeting in Amsterdam. Given a single hop
config uration between Sub-ES as shown in Figure 1, they both assume
that following name resolution, address res olution, and SVC
signaling, an implicit binding is established between entities in the
two subnet ESs. 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 subnet 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.
TULIP changes nothing in the abstract architecture of the IP model,
since each subnet ES still has an IP address which is resolved to
Cole [Page 10]
DRAFT IP over ATM: A Framework Document January 1994
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.
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.
5.2 Peer Models
Peer Models are fundamentally characterized in that they place
routers/gateways and the ATM network on a peer basis. That is, the
ATM network and the attached ESs or ISs exchange routing information
on a peer ba sis, network level addressing is used across the ES or
IS and ATM interface. Discussions on peer models can be found in [LYO
92], [HEI 1992] and [LIA 93].
A rationale for this model is that due to the envisioned complexity
of future ATM networks, the routing com plexities will be similar to
routing over complex internets. Rather than building in redundancy in
routing com plexities at the network and subnetwork levels, perhaps
it is possible to imbed within the ATM network fabric IS
functionality. This is illustrated in Figure 4 below. Here the term
`Single ATM Domain' refers to a collec tion 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 IS is only
required during the connection set-up phase and is not in the path of
the data flow following the connection establishment.
There are issues to be worked for this Peer Model (see, e.g., [HEI
1992] and [LIA 93]), including:
o Defining a routing architecture which
- scales to the large size expected of the eventual ATM
network, and
- supports TOS routing, and
o Defining a functional architecture which
- scales to the large size expected of the eventual ATM
network,
Cole [Page 11]
DRAFT IP over ATM: A Framework Document January 1994
- 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
encour aging interested individuals/companies to research this area,
it was not a priority of the working group to ad dress these issues.
5.3 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 are presented in [LIA 93]. Others
are possi ble, for example Figure 5 showing a Classical IP transition
model which assumes the presence of gateways between ATM subnets and
ATM Peer networks. Other transition options are discussed in [LIA
93].
6. Range of Application of the Working Group's Documents
The IP Over ATM Working Group has generated several Internet-Drafts
or RFCs. This section identifies the relationship of these documents
to the various IP Over ATM Models identified in this document. The
Draft and RFCs produced to date are the following references, [HEI
1993b], [LAU 1993], and [ATK 1993]. The following table cross
references these application of these document to the various IP Over
ATM Models. An `x' in the column under a particular reference
indicates that the specifications in the reference applies to the
particular IP Over ATM Model.
Cole [Page 12]
DRAFT IP over ATM: A Framework Document January 1994
Table 1: Cross Reference of WG Documents and IP Over ATM Models
==================================================================
Models/References [HEI 1993b] [LAU 1993] [ATK 1993]
------------------------------------------------------------------
Subnet Models:
SVC-based LATM X X X
PVC-based LATM X X X
SVC-based WATM X X
End-to-End Models:
Classical IP X X X
SVC-based WATM X X X
TULIP X X
TUNIC
Peer X X
------------------------------------------------------------------
7. CONCLUSIONS
This document identifies several of the possible ATM subnet
technologies that have been bantered about at the meetings of the IP
over ATM working group at the IETF. In particular, an LAN-ATM (LATM),
a PVC- based WAN ATM (PVC-based WATM), and an SVC-based WAN ATM
(SVC-based WATM) are presented. Further, this document lists several
of the end-to-end IP over ATM architectures which have been discussed
and the distinguishing characteristics of each. End-to-end models
discussed include SVC-based WATM, light weight IP models, e.g., TULIP
and TUNIC models, and Peer models. It is proposed that the issues of
routing IP over ATM be broken out into issues relating separately to
the subnet and end-to-end models discussed in this document. Due to
the complexity of ATM technologies, in that they present multiple
faces, it is felt that the best way to make progress is to simplify
the work into more manage able steps.
7. 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
author 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. The
Cole [Page 13]
DRAFT IP over ATM: A Framework Document January 1994
text of Appendix A was pirated liberally from Anthony Alles' of HLS
posting on the IP over ATM discussion list (and modified at the
author's discretion). This draft also has benefitted from numerous
suggestions from John T. Amenyo of ANS.
8. 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 Inter face (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 [ATM 93] (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 [ATM 93] 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 [ATM 93], 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
Cole [Page 14]
DRAFT IP over ATM: A Framework Document January 1994
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 [ATM
93], Version 2.4 (passed by ballot recently to become Version
3.0), vis:
`A call originated on a Private UNI destined for an end system 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.93b requests would
use native E.164 address formats.
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 net work. 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.
Cole [Page 15]
DRAFT IP over ATM: A Framework Document January 1994
REFERENCES
[ATM 1993] ATM Forum, `ATM User-to-Network Interface (UNI)
Specification: Version 3.0', Sept. 1993.
[ATK 1993] R. Atkinson, `Default IP MTU for use over ATM Adaptation
Layer 5 (AAL 5)', IETF Network Working Group INTERNET DRAFT, 16
November 1993.
[GAR 1993] J. Garrett, `Directed ARP', IETF Network Working Group RFC
1433, March 1993.
[HAL 1993] J. Halpern, postings to the IP over ATM and Routing over
Large Clouds discussion lists.
[HEI 1993a] J. Heinanen and R. Govindan, `Next Hop Resolution
Protocol (NHRP)',IETF Routing over Large Clouds Working Group
INTERNET DRAFT, 15 October 1993.
[HEI 1993b] J. Heinanen, `Multiprotocol over Adaptation Type 5 on
ATM', IETF Network Working Group RFC 1483, July 1993.
[HEI 1992] J. Heinanen, `Routing and Addressing in ATM Networks',
private memorandum posted to the P over ATM Working Group, 27
November, 1992.
[ISO 8473] `Information technology - Telecommunications and
Information exchange between systems - In termediate system to
Intermediate system Intra-Domain routing information exchange
protocol for use in conjunction with the Protocol for providing
the Connectionless-mode Network Service (ISO 8473),' Inter
national Organization for Standardization, 1992.
[LAU 1993] M. Laubach, `Classical IP and ARP over ATM', IETF Network
Working Group INTERNET DRAFT, 14 October 1993.
[LIA 1993] F. Liaw, `IP over ATM: architecture, address translation,
and call control', IP over ATM Working Group INTERNET DRAFT, 21
March, 1993.
[LYO 1992] T. Lyon, F. Liaw, and A. Romanow, `Network Layer
Architecture for ATM Networks', private memorandum, 1992.
[RFC 1293] T. Bradley and C. Brown, `Inverse Address Resolution
Protocol', IETF Networking Working Group RFC 1293, January 1992.
Cole [Page 16]
DRAFT IP over ATM: A Framework Document January 1994
[RFC 1293] T. Bradley, C. Brown, and A. Malis, `Multiprotocol
Interconnect over Frame Relay', IETF Net working Working Group
RFC 1490, July 1993.
[TSU 1993] P. Tsuchiya, `Shortcut Routing: Discovery and Routing over
Large Public Data Networks', IETF Network Working Group INTERNET-
DRAFT, January 1993.
Author's Address
Robert G. Cole
AT&T Bell Laboratories
101 Crawfords Corner Road, Rm 1F-408
Holmdel, NJ 07733
Phone: 1-908-949-1950
FAX: 1-908-949-1726
EMail: rgc@qsun.att.com
Cole [Page 17]
