Yakov Rekhter
Cisco Systems
Dilip Kandlur
T.J. Watson Research Center, IBM Corp.
November 1995
Address Prefix Region and its application to Switched Data Link Subnetworks
<draft-ietf-rolc-apr-01.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 IP architecture assumes that each Data Link subnetwork is labeled
with a single IP subnet number. A pair of hosts with the same subnet
number communicate directly (with no routers); a pair of hosts with
different subnet numbers always communicate through one or more
routers. As indicated in RFC1620, these assumptions may be too
restrictive for large data networks, and specifically for networks
based on switched virtual circuit (SVC) based technologies (e.g. ATM,
Frame Relay, X.25), as these assumptions impose constraints on
communication among hosts and routers through a network, which in
turn may preclude full utilization of the capabilities provided by
the underlying SVC-based Data Link subnetwork. This document
describes extensions to the IP architecture that relaxes these
constraints, thus enabling the full utilization of the services
provided by SVC-based Data Link subnetworks.
1 Background
The following briefly recaptures the concept of the IP Subnet. The
Expiration Date May 1996 [Page 1]
INTERNET DRAFT November 1995
topology is assumed to be composed of links (Data Link subnetworks)
interconnected via routers. An IP address of a host with an
interface attached to a particular link is a tuple <subnet address
prefix, host number>, where host number is unique within the subnet
address prefix. 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 resolves IP address to Link Layer address
(e.g. by using ARP), 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 with a common subnet address prefix are assumed to be
attached to a common link (subnetwork), and thus communicate with
each other directly, without any routers - "local";
hosts with different subnet address prefixes are assumed to be
attached to different links (subnetworks), and thus communicate
with each other only through routers - "remote".
A typical example of applying the IP subnet architecture to an SVC-
based Data Link subnetwork is "Classical IP and ARP over ATM"
(RFC1577). 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; for
destinations outside its LIS the host must forward packets through a
router. It is important to stress that 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 Motivations
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 generate a large volume of packets (e.g.
Expiration Date May 1996 [Page 2]
INTERNET DRAFT November 1995
video-conferencing).
SVC-based Data Link subnetworks offer certain unique capabilities
that are not present in other (non-SVC) subnetworks (e.g. Ethernet,
Token Ring). The ability to dynamically establish and tear-down SVCs
between communicating entities attached to an SVC-based Data Link
subnetwork enables the dynamic dedication and redistribution of
certain communication resources (e.g. bandwidth) among the entities.
This dedication and redistribution of resources could be accomplished
by relying solely on the mechanism(s) provided by the Data Link
layer.
The unique capabilities provided by SVC-based Data Link subnetworks
do not come "for free". The mechanisms that provide dedication and
redistribution of resources have certain overhead (e.g. the time
needed to establish an SVC, resources associated with maintaining a
state for an SVC). There may also be a monetary cost associated with
establishing and maintaining an SVC. Therefore, it is very important
to be cognizant of such an overhead and to carefully balance the
benefits provided by the mechanisms against the overhead introduced
by such mechanisms.
One of the key issues for using SVC-based Data Link subnetworks in
the TCP/IP environment is the issue of switched virtual circuit (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
(on a common Data Link subnetwork) 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 with respect to the ability to efficiently
exploit capabilities provided by the underlying Data Link layer.
The traditional IP subnet model is too restrictive for flexible and
adaptive use of SVC-based Data Link subnetworks - the use of a
subnetwork is driven by information completely unrelated to the
characteristics of individual applications. To illustrate the
problem consider "Classical IP and ARP over ATM" (RFC1577). 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 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, and has no relation to the nature of the
applications that generated these packets.
3 QoS/Traffic Driven "Local/Remote" Decision
To exploit the capabilities provided by SVC-based Data Link
Expiration Date May 1996 [Page 3]
INTERNET DRAFT November 1995
subnetworks we propose to allow SVC management to be controlled by
applications (through an appropriate API), and more specifically by
the QoS and/or traffic 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 communication among the
applications in the second category may rely on the router-based
infrastructure (for example, one could hardly imagine establishing an
SVC just to perform a single DNS query). The connection (an SVC)
from a host to its first-hop router would then serve as a shared
connection for many applications running on the host. This should
apply to any pair of hosts connected to a common SVC- based Data Link
subnetwork, irrespective of the hosts' IP addresses. Prudent use of
the router-based infrastructure reduces unnecessary load on the SVC-
based infrastructure, and at the same time will eliminate the
overhead (e.g., delay and/or cost) 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 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 SVC-based Data
Link environment this decision should be driven by the applications
(through an appropriate API), and specifically by their QoS and/or
traffic requirements and/or cost factors. For example, for a pair of
hosts, A and B, both on a common switched Data Link subnetwork, an
application running on a host A should be able to specify whether it
desires a direct SVC (direct 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 other cases (the default behavior) A
should be able to deliver packets to B through one or more IP routers
("remote" decision). The default behavior also covers the case where
an application may desire a direct SVC (direct connectivity), but
such connectivity is unavailable (e.g. hosts are on different Data
Link subnetworks).
The ability of a host to establish an SVC to a peer on a common
switched Data Link subnetwork is predicated on its knowledge of the
Link Layer 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
Link Layer 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 Data Link subnetworks, or may be on a common Data Link
subnetwork that is partitioned. If a host can not establish an SVC,
the host may default (depending on the application) to sending data
through routers.
Expiration Date May 1996 [Page 4]
INTERNET DRAFT November 1995
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).
In the case when applications direct a "local" outcome, depending on
the nature of the applications, a pair of hosts should be able to
either multiplex packets from 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.
To summarize, the "local/remote" decision may not be time invariant,
may depend on factors other than the addresses of the source and the
destination, and may involve either shared or dedicated SVCs.
4 Address Prefix Region (APR)
To provide flexible and adaptive use of SVC-based Data Link
subnetworks we propose to replace the concept of a Logical IP Subnet
(LIS) with the concept of an Address Prefix Region (APR).
An Address Prefix Region (APR) is a set of routers and hosts that
meet all of the following properties:
An APR must be fully contained within a single Data Link
subnetwork, but a single Data Link subnetwork may include one or
more APRs.
Every element in the set (either a host or a router) can establish
direct communication (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 be aggregated into a single IP address prefix; each
element in the set knows the prefix.
Expiration Date May 1996 [Page 5]
INTERNET DRAFT November 1995
All routers in the set advertise direct reachability to all the
hosts in the set - any router in the set is one (1) IP hop away
from any host in the set.
From the point of view of address assignment an APR is identical to a
LIS. The major difference between the two is the impact on the
"local/remote" decision. Since formation of an APR should have no
impact on the outcome of the "local/remote" decision made by the
hosts within the APR, it allows the decoupling of the "local/remote"
decision from the information provided by the IP addresses.
For the purpose of IP unicast forwarding the role of the APR 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 Data
Link subnetwork, or (b) destinations for applications that don't
justify an SVC. An APR would identify for a given set of hosts the
set of routers that these hosts can use as their first/last hop
(first-hop/last-hop routers). At the same time, a host within a
given APR is not restricted to use only the routers within its APR as
its first-hop/last-hop routers. The host could use any router,
whether in the same or in a different APR as the host, as its first-
hop/last-hop router, provided that the router is on the same Data
Link subnetwork as the host. Procedures by which a host could find
such routers are outside the scope of this document.
For the purpose of IP layer broadcasts an APR provides a mechanism
that is identical to the subnet directed broadcast. An IP packet is
destined to all the elements of an APR if the destination address in
the packet is equal to the IP address prefix of the APR. We shall
refer to such a broadcast as an APR Directed Broadcast.
An APR may have more than one router for redundancy. To select among
several routers a host may use information provided by the Data Link
layer (SVC teardown) as an indication of a "dead" router. Likewise,
for a given router an APR would identify the set of hosts for which
the router should serve as the last hop router.
The APR could be used to implement administrative constraints on
connectivity at the network (IP) layer.
Finally, the APR may also be used to facilitate association of
elements within an APR with various network layer servers (e.g. ARP
Server, Multicast Server, etc...). Details of such an association are
outside the scope of this document.
4.1 Host Modifications
For an application whose QoS and/or traffic requirements could
benefit from a direct SVC (direct connectivity), the host should
Expiration Date May 1996 [Page 6]
INTERNET DRAFT November 1995
attempt to establish an SVC, irrespective of the source and
destination addresses. If such a connection can not be established,
the host should forward data through a router that is reachable (at
the Data Link layer) from the host (e.g. such a router may be one of
the routers of the APR the host is in, or may be some other router on
the same Data Link subnetwork as the host). For all other
applications the host may forward data through one of the routers of
the APR (as defined in this document) the host is in.
4.2 Router Modifications
When a router associated with a given APR (as defined in this
document) receives an IP packet from a host in the APR that is
destined to another host in the same APR, the router should forward
the packet (if possible), and refrain from sending an ICMP Redirect
message to the originating host.
5 Conclusions
Different approaches to SVC-based Data Link subnetworks used by
TCP/IP yield substantially different results with respect to the
ability of TCP/IP applications to efficiently exploit the
functionality provided by such subnetworks. For example, in the case
of ATM both LAN Emulation [LANE] 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 the full utilization of the
functionality that ATM is expected to provide.
It appears that any model that does not allow SVC management under
control of applications, and specifically their QoS and/or traffic
requirements is likely to curtail efficient use of SVC-based Data
Link subnetworks. Enabling direct connectivity for applications that
could benefit from the functionality provided by SVC-based Data Link
subnetworks, while relying on routers for other applications, could
facilitate exploration of the capabilities provided by the
subnetworks.
While this document does not define any specific coupling between
various QoS, traffic characteristics and other parameters, and SVC
management, it is important to stress that efforts towards
standardization of various QoS, traffic characteristics, and other
parameters than an application could use (through an appropriate API)
to influence SVC management are essential for flexible and adaptive
use of SVC-based Data Link subnetworks.
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 to the
Expiration Date May 1996 [Page 7]
INTERNET DRAFT November 1995
environment proposed in this document.
The proposed model utilizes the SVC-based infrastructure for the
applications that could benefit from the capabilities supported
within such an infrastructure, 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 document 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.
The concept of APR proposed in this document could be also applicable
in a non-SVC based environment.
6 Security Considerations
Security issues are not discussed in this document.
7 Acknowledgements
The authors would like to thank Joel Halpern (NewBridge), Allison
Mankin (ISI), Tony Li (cisco Systems), Andrew Smith (BayNetworks),
and Curtis Villamizar (ANS) for their review and comments.
Appendix: Transition for ATM-based subnetworks
Given that the LIS model outlined in RFC1577 is now being implemented
by several vendors, it is instructive to consider how the
architecture proposed in this document could be phased into the
environment that supports RFC1577 in a backward compatible fashion.
The APR model implies that packets among hosts within a common APR
may traverse through a router associated with the APR. 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 APRs, as it requires the router to be configured with as
many subnets as there are hosts in the APR. A better long-term
solution is to configure the router to suppress the generation of
ICMP Redirect messages.
Expiration Date May 1996 [Page 8]
INTERNET DRAFT November 1995
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 an APR
since it provides them with direct SVCs. A host could start with
this default behavior and provide direct SVCs to destinations outside
the APR 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 APR behavior.
References
[LANE] "LAN Emulation over ATM specification- version 1", ATM Forum,
Feb.95.
[Postel 81] Postel, J., Sunshine, C., Cohen, D., "The ARPA Internet
Protocol", Computer Networks, 5, pp. 261-271, 1983.
[RFC792] Postel, J., "Internet Control Message Protocol- DARPA
Internet Program Protocol Specification", STD 5, RFC 792, ISI,
September 1981.
[RFC1122] Braden, R., Editor, "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, USC/ISI, October 1989.
[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.
14 Authors' Address
Yakov Rekhter
Cisco Systems
170 West Tasman Drive,
San Jose, CA 95134-1706
Phone: (914) 528-0090
email: yakov@cisco.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 May 1996 [Page 9]
INTERNET DRAFT November 1995
Expiration Date May 1996 [Page 10]
