draft-ietf-rolc-apr-00.txt

["Andrew G. Malis" <[e-mail]>]

Please enter the following I-D as draft-ietf-rolc-apr-00.txt.

Thanks,
Andy Malis
Chair, ROLC WG

-------






                                                          Yakov Rekhter
                                                         Cisco  Systems
                                                          Dilip Kandlur
                                 T.J. Watson Research Center, IBM Corp.
                                                         September 1995


Address Prefix Region and its application to Switched Data Link Subnetworks
                      <draft-ietf-rolc-apr-00.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. A pair of hosts with the
   same network number communicate directly  (with no routers); a pair
   of hosts with different network numbers always communicate through
   one or more routers. As indicated in RFC1620, these assumptions may
   be violated for large data networks, and specifically for networks
   based on switched virtual circuit (SVC) based technologies (e.g. ATM,
   X.25).  The architecture works even when this assumption is violated,
   but it imposes 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. The document also specifies how the proposed extensions
   could be used for other types of subnetworks.







Expiration Date March 1996                                      [Page 1]





INTERNET DRAFT                                            September 1995


1  Background


   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
   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 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 network number are assumed to be attached to a
      common link (subnetwork), and thus communicate with each other
      directly, without any routers -- "local"

      hosts with different network numbers 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"
   (RFC1597).  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.  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.



Expiration Date March 1996                                      [Page 2]





INTERNET DRAFT                                            September 1995


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

   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 to dynamically dedicate and redistribute 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). 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
   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 provides a poor match for flexible
   and adaptive use of the 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" (RFC1597).  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 nothing to do with the nature of
   particular applications.








Expiration Date March 1996                                      [Page 3]





INTERNET DRAFT                                            September 1995


3  QoS/Traffic Driven "Local/Remote" Decision


   To exploit capabilities provided by the SVC-based Data Link
   subnetworks we propose to allow SVC management to be directly
   controlled by applications, 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 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 SVC-based Data Link subnetwork, irrespective of 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 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
   SVC-based Data Link environment this decision should be driven solely
   by the applications and their QoS and/or traffic 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 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 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 SVC (direct
   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 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. Only the actual
   SVC establishment is sufficient to enable direct communication. If a
   host can not establish an SVC, the host may default (depending on the



Expiration Date March 1996                                      [Page 4]





INTERNET DRAFT                                            September 1995


   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.


4  Address Prefix Region (APR)


   To provide flexible and adaptive use of SVC-based Data Link
   subnetworks we proposed to replace the concept of a traditional IP
   subnet with the concept of an Address Prefix Region (APR).

   An Address Prefix Region (APR) can be formally defined by the
   following properties:

      An APR is a set of routers and hosts

      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 aggregated into a single IP address prefix; each
      element in the set knows the prefix

      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





Expiration Date March 1996                                      [Page 5]





INTERNET DRAFT                                            September 1995


   From an address assignment point of view an APR is identical to a
   traditional IP subnet (and in this sense it is identical to a LIS).
   The major difference between the two is the impact on the
   "local/remote" decision.  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 an APR should have no impact on the outcome of the
   "local/remote" decision made by the hosts within the APR.

   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 fabric,
   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 hop (first-hop routers).

   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'll 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 serve as a useful migration tool from the current
   (traditional IP subnet model) environment, as it provides backward
   compatibility for hosts that support only the traditional IP subnet
   model (e.g. hosts that support only "classic" IP over ATM model),
   while allowing the intermix of these hosts with modified hosts that
   support application driven "local/remote" decision.

   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


   A host implementation should allow SVC management to be placed under
   control of applications (and be controlled by the QoS/traffic
   requirements of the applications).

   For an application whose QoS requirements could benefit from a direct
   SVC (direct connectivity), the host should attempt to establish an



Expiration Date March 1996                                      [Page 6]





INTERNET DRAFT                                            September 1995


   SVC, 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 Data Link layer) from the host (e.g. such a router may be one
   of the routers of the APR the host is in). For all other applications
   the host should forward data through one of the routers of the APR
   (as defined in this document) the host is in.

   For certain SVC-based Data Link technologies (e.g. ATM) application
   controlled SVC management could benefit if the information related to
   the top level application end points is carried in the SVC Setup
   messages. For example, in the case of ATM such information could be
   carried by the B-HLI IE (information element), as described in
   RFC1755.


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

   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,



Expiration Date March 1996                                      [Page 7]





INTERNET DRAFT                                            September 1995


   when more applications become ATM aware and can explicitly request
   SVCs, the host can transition to the APR behavior.



6 Conclusions


   Different approaches to SVC-based Data Link subnetworks use by TCP/IP
   yield quite 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
   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 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.

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


7 Security Considerations


   Security issues are not discussed in this document.





Expiration Date March 1996                                      [Page 8]





INTERNET DRAFT                                            September 1995


8 Acknowledgements


   The authors would like to thank Joel Halpern (NewBridge), Allison
   Mankin (ISI), and Tony Li (cisco Systems) for their review and
   comments.


9 References


   [NHRP]  Katz, D., Piscitello, D., "NBMA Next Hop Resolution Protocol
   (NHRP)", draft-ietf-rolc-nhrp-04.txt, May 1995.

   [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:  [phone]
   email:  [e-mail]

   Dilip Kandlur
   T.J. Watson Research Center IBM Corporation
   P.O. Box 704
   Yorktown Heights, NY 10598
   Phone:  [phone]
   email:  [e-mail]








Expiration Date March 1996                                      [Page 9]