One document matched: draft-rekhter-ip-atm-architecture-00.txt
- 1 -
Yakov Rekhter
T.J. Watson Research Center, IBM Corp.
Dilip Kandlur
T.J. Watson Research Center, IBM Corp.
January 1995
IP Architecture Extensions for ATM
<draft-rekhter-ip-atm-architecture.txt>
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 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
Abstract
The original IP architecture assumes that each Data Link subnetwork
is labeled with a single IP network number. As indicated in RFC1620,
this assumption may be violated for large data networks, including
ATM-based networks. The architecture works even when this assumption
is violated, but it imposes constraints on communication among hosts
and routers through an ATM-based network, which in turn may preclude
full utilization of ATM capabilities. This document describes
extensions to the IP architecture that relaxes these constraints,
thus enabling the full utilization of the services provided by ATM.
1. Introduction
The following briefly recaptures the concept of the IP Subnet. The
Internet architecture is based on the "Catenet model" [Postel:81].
The topology is assumed to be composed of links (Data Link
Expiration Date July 1995 [Page 1]
- 2 -
subnetworks) interconnected via routers. Each link has a globally
unique number. An IP address of a host with an interface attached to
a particular link is a tuple <link number, host number>, where host
number is unique within the link. When a host needs to send an IP
packet to a destination, the host needs to determine whether the
destination address identifies an interface that is connected to one
of the links the host is attached to ("local" decision), or not
("remote" decision). The outcome of the "local/remote" decision is
based on (a) the source address, (b) the destination address, and (c)
the subnet mask associated with the source address. If the outcome
is "local", then the host uses ARP to determine the destination's MAC
address, and then sends the packet directly to that destination
(using the Link layer services). If the outcome is "remote", then
the host uses one of its first-hop routers (thus relying on the
services provided by IP routing).
To summarize, two of the important attributes of the IP subnet model
are:
- hosts attached to a common link communicate with each other
directly, without any routers -- "local"
- hosts attached to different links communicate with each other
only through routers -- "remote"
RFC1577 provides support for ATM deployment that follows the
traditional IP subnet model and introduces the notion of a Logical IP
Subnetwork (LIS). The consequence of this model is that a host is
required to setup an ATM SVC to any host within its LIS, and it must
forward packets to destinations outside its LIS through a router.
This "local/remote" decision is based solely on the information
carried by the source and destination addresses and the subnet mask
associated with the source address.
2. QoS Driven "Local/Remote" Decision
The diversity of TCP/IP applications results in a wide range of
traffic characteristics. Some applications last for a very short
time and generate only a small number of packets between a pair of
communicating hosts (e.g. ping, DNS). Other applications have a short
lifetime, but generate a relatively large volume of packets (e.g.
FTP). There are also applications that have a relatively long
lifetime, but generate relatively few packets (e.g. Telnet).
Finally, we anticipate the emergence of applications that have a
relatively long lifetime and and generate a large volume of packets
(e.g. video-conferencing).
Expiration Date July 1995 [Page 2]
- 3 -
One of the key issues for ATM in the TCP/IP environment is the issue
of switched virtual connection (SVC) management. This includes SVC
establishment and tear-down, class of service specification, and SVC
sharing. At one end of the spectrum one could require SVC
establishment between communicating entities for any application. At
the other end of the spectrum, one could require communicating
entities to always go through a router, regardless of the
application. Given the diversity of TCP/IP applications, either
extreme is likely to yield a suboptimal solution.
The "classical" IP over ATM model (as specified in RFC1577) provides
a poor match for flexible and adaptive use of the ATM fabric -- the
use is not driven by the characteristics of individual applications.
RFC1577 provides support for ATM deployment that follows the
traditional IP subnet model, and introduces the notion of a Logical
IP Subnetwork (LIS). The consequence of this model is that a host is
required to setup an ATM SVC to any host within its LIS, and it must
forward packets to destinations outside its LIS through a router.
This "local/remote" decision is based solely on the information
carried in the source and destination addresses and the subnet mask
associated with the source address.
We propose to allow SVC management to be directly controlled by
applications, and more specifically by the QoS requirements of the
applications. It is apparent that while the service requirements of
some IP applications could justify the establishment of a dedicated
SVC (e.g. applications that require high bandwidth and/or network
resource reservations), other applications could be served with a
shared connection. To reduce the overhead associated with the
establishment and maintenance of SVCs, as well as to improve
performance of short-lived applications, we propose that applications
in the second category should rely on the router-based infrastructure
(for example, one could hardly imagine establishing an SVC just to
perform a single DNS query). The connection to the router would then
serve as a shared connection for many applications. This should
apply to any pair of hosts connected to a common ATM fabric,
irrespective of hosts' IP addresses. Prudent use of the router-based
infrastructure reduces unnecessary load on the ATM infrastructure,
and at the same time will eliminate delay associated with SVC
establishment, thus benefiting both the network and the applications.
We propose certain modifications to the existing IP model in order to
support both the applications with QoS requirements that could
justify a dedicated SVC, and applications that would rely on the
router-based infrastructure. While in the conventional ("classical")
IP environment the "local/remote" decision is based on the
information provided by the IP addresses, we propose that in the ATM
environment this decision should be driven solely by the applications
and their QoS requirements, (rather than by the information carried
in the addresses). For example, an application running on a host A
should be able to specify whether it desires a direct ATM
Expiration Date July 1995 [Page 3]
- 4 -
connectivity to its peer on a host B ("local" decision), and in this
case an SVC will be established (if possible) between A and B; in all
other cases (the default behavior) packets from A to B will traverse
through one or more IP routers ("remote" decision). The default
behavior also covers the case where an application may desire a
direct ATM connectivity, but such connectivity is unavailable (e.g.
hosts are on different fabrics).
The ability of a host to establish an SVC to a peer is predicated on
its knowledge of the ATM MAC address of the peer. This document
assumes the existence of mechanism(s) that can provide the host with
this information. Some of the possible alternatives are NHRP, ARP, or
static configuration; other alternatives are not precluded. The
ability to acquire the ATM MAC address of the peer should not be
viewed as an indication that the host and the peer can establish an
SVC -- the two may be on different ATM networks, or may be on a
common ATM network that is partitioned. If a host can not establish
an SVC, the host may default (depending on the application) to
sending data through routers.
One important implication of this proposal is that in contrast with
the conventional IP environment, the "local/remote" decision may no
longer be time invariant. While at one moment a pair of hosts (e.g. A
and B) may have an SVC between them (e.g. when there is a video-
conference running between the hosts) and thus will be viewed as
"local" to each other, at some later point in time communication
between exactly the same pair of hosts (e.g. A and B) will be done
through one or more routers (after the video-conference ends, and
someone would decide to run ping) and thus will viewed as "remote".
In addition to being time dependent, the "local/remote" decision may
yield both "local" and "remote" outcome simultaneously. This is
because a set of hosts may concurrently run multiple applications,
where some of these applications could justify an SVC establishment
(thus resulting in a "local" outcome), while others will rely on
router-based infrastructure (thus resulting in a "remote" outcome).
Even if when applications yields "local" outcome, depending on the
nature of the applications a pair of hosts should be able to either
multiplex several applications over a single SVC, or establish
dedicated SVCs on a per application basis or both. In the case where
an SVC is shared among several applications care must be taken to
ensure fair sharing of the resources provided by the SVC. For
example, while it may be acceptable to share a single SVC for
multiple FTP sessions between a pair of hosts, sharing an SVC for an
FTP session and a video-conference is likely to be more problematic.
Expiration Date July 1995 [Page 4]
- 5 -
2. Redefining the LIS Concept
To provide flexible and adaptive use of ATM we proposed to redefine
the concept and semantics of a LIS. If we are to completely decouple
the "local/remote" decision from the information provided by the IP
addresses, and base it solely on the applications, it follows that
formation of a LIS should have no impact on the outcome of the
"local/remote" decision made by the hosts within the LIS. The new
role of the LIS is to act as a mechanism to associate a set of hosts
with one or more routers that these hosts could use to establish
connectivity (reachability) with (a) destinations that are not on a
common fabric, or (b) destinations for applications that don't
justify an SVC. A LIS would identify for a given set of hosts the set
of routers that these hosts can use as their first hop (first-hop
routers). A LIS may have more than one router for redundancy. To
select among several routers a host may use ATM information (SVC
teardown) as an indication of a "dead" router. Likewise, for a given
router a LIS would identify the set of hosts for which the router
should serve as the last hop router. The LIS could also serve as a
useful migration tool from the current environment, as it provides
backward compatibility for hosts that support only the "classic" IP
over ATM model, while allowing the intermix of these hosts with
modified hosts that support application driven "local/remote"
decision. Finally, the LIS could be used to implement administrative
constraints on connectivity at the network (IP) layer.
Hence, our new model for a LIS can be formally defined by the
following properties:
- A LIS is a set of routers and hosts
- Every element in the set (either a host or a router) can
establish an SVC with every other element in the set
- IP addresses of the hosts in the set are assigned in such a way
that they can aggregated into a small number of IP address
prefixes
- All routers in the set advertise direct reachability to all the
hosts in the set -- any router in the set is 1 IP hop away from
any host in the set
2.1 Host Modifications
A host implementation should allow SVC management to be placed under
control of applications (and be controlled by the QoS requirements of
the applications).
Expiration Date July 1995 [Page 5]
- 6 -
For an application whose QoS requirements could benefit from a direct
ATM connectivity, the host should attempt to establish the ATM
connection, irrespective of the source and destination addresses. If
such a connection can not be established, the host should (under the
control of the application) forward data through a router that is
reachable (at the ATM layer) from the host (e.g. such a router may be
one of the routers of the LIS the host is in). For all other
applications the host should forward data through one of the routers
of the LIS (as defined in this document) the host is in.
Application controlled SVC management could benefit if the
information related to the top level application end points is
carried in the ATM Setup messages. Such information could be carried
by the B-HLI IE (information element), as described in RFC1755.
2.2 Router Modifications
When a router associated with a given LIS (as defined in this
document) receives an IP packet from a host in the LIS that is
destined to another host in the same LIS, the router should forward
the packet (if possible), and refrain from sending an ICMP Redirect
message to the originating host.
3. Transition
Given that the LIS model outlined in RFC1577 is now being implemented
by several vendors, it is instructive to consider how the
architecture lroposed in this document could be phased into the
environment that supports RFC1577 in a backward compatible fashion.
The new LIS model implies that packets among hosts within a common
LIS may traverse through a router associated with the LIS.
Typically, such forwarding would result in the generation of ICMP
Redirect messages from the router to the source. As a first step,
the new host may be configured to quietly ignore these messages. It
should also be possible to eliminate Redirect messages by specifying
multiple subnets per interface of a router, so that while every host
would have a subnet in common with the router, no two hosts attached
to the router will be on a common subnet. This approach may not scale
to large LISs, as it requires the router to be configured with as
many subnets as there are hosts in the LIS. A better long-term
solution is to configure the router to suppress the generation of
ICMP Redirect messages.
Another dimension to be considered is that of a phased migration of
applications within a host. As mentioned before, the RFC1577 LIS
concept can benefit existing applications communicating within a LIS
Expiration Date July 1995 [Page 6]
- 7 -
since it provides them with direct SVCs. A host could start with
this default behavior and provide direct SVCs to destinations outside
the LIS only upon application (QoS) request. At a suitable time,
when more applications become ATM aware and can explicitly request
SVCs, the host can transition to the new LIS behavior.
4. Conclusions
Different approaches to ATM deployment yield quite different results
with respect to the ability of TCP/IP applications to fully exploit
ATM functionality.
Both LAN Emulation and "classical" IP over ATM (RFC1577) localize
host changes below the IP layer, and therefore may be good first
steps in the ATM deployment. However, these approaches are likely to
be inadequate for full utilization of functionality that ATM is
expected to provide. It seems that any model that doesn't allow SVC
management under direct control of applications (QoS) is likely to
curtail efficient use of ATM. Enabling direct connectivity for
applications that could benefit from ATM, while relying on routers
for other applications, could facilitate exploration of ATM
capabilities.
Essential to the deployment of the proposed approach is to develop
migration strategies that would provide graceful transition based on
small incremental changes from the current environment (either LAN
Emulation or "classical" IP over ATM) to the environment proposed in
this document.
The proposed model utilizes the ATM infrastructure for the
applications that could benefit from ATM capabilities, and creates a
router-based overlay for all other applications. As such it provides
a balanced mix of router-based and switch-based infrastructures,
where the balance could be determined by the applications
requirements.
The approach proposed in this paper combines switch-based
infrastructure with router-based overlay and uses each for that which
it is best suited: switch-based infrastructure for applications that
can justify an SVC establishment; router-based overlay for all other
applications.
5 Security Considerations
Security issues are not discussed in this document.
Expiration Date July 1995 [Page 7]
- 8 -
6 Acknowledgements
The authors would like to thank Joel Halpern (NewBridge) and Allison
Mankin (ISI) for their review and comments.
7 References
[NHRP] Katz, D., Piscitello, D., "NBMA Next Hop Resolution Protocol
(NHRP)", draft-ietf-rolc-nhrp-03.txt, November 1994.
[Postel 81] Postel, J., Sunshine, C., Cohen, D., "The ARPA Internet
Protocol", Computer Networks, 5, pp. 261-271, 1983.
[RFC1577] Laubach, M., "Classical IP and ARP over ATM", January 1994.
[RFC1620] Braden, B., Postel, J., Rekhter, Y., Internet Architecture
Extensions for Shared Media", May 1994.
[RFC1755] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E.,
Malis, A., "ATM Signalling Support for IP over ATM", January 1995.
7 Authors' Address
Yakov Rekhter
T.J. Watson Research Center IBM Corporation
P.O. Box 704
Yorktown Heights, NY 10598
Phone: (914) 784-7361
email: yakov@watson.ibm.com
Dilip Kandlur
T.J. Watson Research Center IBM Corporation
P.O. Box 704
Yorktown Heights, NY 10598
Phone: (914) 784-7722
email: kandlur@watson.ibm.com
Expiration Date July 1995 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-21 19:50:22 |