doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc1937.txt b/doc/rfc/rfc1937.txt
new file mode 100644
index 0000000..68154e4
--- /dev/null
+++ b/doc/rfc/rfc1937.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         Y. Rekhter
+Request for Comments: 1937                                 Cisco Systems
+Category: Informational                                       D. Kandlur
+                                  T.J. Watson Research Center, IBM Corp.
+                                                                May 1996
+
+
+  "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+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.  The
+   restrictions 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
+   topology is assumed to be composed of hosts and routers
+   interconnected via links (Data Link subnetworks).  An IP address of a
+   host with an interface attached to a particular link is a tuple
+   <prefix length, 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, or not.  This referred to
+   as the "local/remote" decision. The outcome of the "local/remote"
+   decision is based on (a) the destination address, and (b) the address
+   and the prefix length associated with the the local interfaces.  If
+   the outcome is "local", then the host resolves the IP address to a
+   Link Layer address (e.g. by using ARP), and then sends the packet
+
+
+
+Rekhter & Kandlur            Informational                      [Page 1]
+
+RFC 1937        Forwarding in Switched Data Link Subnets        May 1996
+
+
+   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 destination address
+   and the address and prefix lengths associated with the local
+   interfaces.
+
+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.
+   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
+
+
+
+Rekhter & Kandlur            Informational                      [Page 2]
+
+RFC 1937        Forwarding in Switched Data Link Subnets        May 1996
+
+
+   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" forwarding decision, and consequently the SVC
+   management, 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
+
+   Consider a host attached to an SVC-based Data Link subnetwork, and
+   assume that the "local/remote" decision the host could make is not
+   constrained by the IP subnet model. When such a host needs to send a
+   packet to a destination, the host might consider any of the following
+   options:
+
+
+
+
+Rekhter & Kandlur            Informational                      [Page 3]
+
+RFC 1937        Forwarding in Switched Data Link Subnets        May 1996
+
+
+      Use a best-effort SVC to the first hop router.
+
+      Use an SVC to the first hop router dedicated to a particular type
+      of service (ie: predictive real time).
+
+      Use a dedicated SVC to the first hop router.
+
+      Use a best-effort SVC to a router closer to the destination than
+      the first hop router.
+
+      Use an SVC to a router closer to the destination than the first
+      hop router dedicated to a particular type of service.
+
+      Use a dedicated SVC to a router closer to the destination than the
+      first hop router.
+
+      Use a best-effort SVC directly to the destination (if the
+      destination is on the same Data Link subnetwork as the host).
+
+      Use an SVC directly to the destination dedicated to a particular
+      type of service (if the destination is on the same Data Link
+      subnetwork as the host).
+
+      Use a dedicated SVC directly to the destination (if the
+      destination is on the same Data Link subnetwork as the host).
+
+   In the above we observe that the forwarding decision at the host is
+   more flexible than the "local/remote" decision of the IP subnet
+   model. We also observe that the host's forwarding decision may take
+   into account QoS and/or traffic requirements of the applications
+   and/or cost factors associated with establishing and maintaining a
+   VC, and thus improve the overall SVC management. Therefore, removing
+   constraints imposed by the IP subnet model is an important step
+   towards better SVC management.
+
+3.1 Extending the scope of possible "local" outcomes
+
+   A source may have an SVC (either dedicated or shared) to a
+   destination if both the source and the destination are on a common
+   Data Link subnetwork. The ability to create and use the SVC (either
+   dedicated or shared) is completely decoupled from the source and
+   destination IP addresses, but is instead coupled to the QoS and/or
+   traffic characteristics of the application. In other words, the
+   ability to establish a direct VC (either dedicated or shared) between
+   a pair of hosts on a common Data Link subnetwork has nothing to do
+   with the IP addresses of the hosts. In contrast with the IP subnet
+   model (or the LIS mode), the "local" outcome becomes divorced from
+   the addressing information.
+
+
+
+Rekhter & Kandlur            Informational                      [Page 4]
+
+RFC 1937        Forwarding in Switched Data Link Subnets        May 1996
+
+
+3.2 Allowing the "remote" outcome where applicable
+
+   A source may go through one or more routers to reach a destination if
+   either (a) the destination is not on the same Data Link subnetwork as
+   the source, or (b) the destination is on the same Data Link
+   subnetwork as the source, but the QoS and/or traffic requirements of
+   the application on the source do not justify a direct (either
+   dedicated or shared) VC.
+
+   When the destination is not on the same Data Link subnetwork as the
+   source, the source may select between either (a) using its first-hop
+   (default) router, or (b) establishing a "shortcut" to a router closer
+   to the destination than the first-hop router.  The source should be
+   able to select between these two choices irrespective of the source
+   and destination IP addresses.
+
+   When the destination is on the same Data Link subnetwork as the
+   source, but the QoS and/or traffic requirements do not justify a
+   direct VC, the source should be able to go through a router
+   irrespective of the source and destination IP addresses.
+
+   In contrast with the IP subnet model (or the LIS model) the "remote"
+   outcome, and its particular option (first-hop router versus router
+   closer to the destination than the first-hop router), becomes
+   decoupled from the addressing information.
+
+3.3 Sufficient conditions for direct connectivity
+
+   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 or an intermediate point closer to the
+   destination.  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.
+
+3.4 Some of the implications
+
+   Since the "local/remote" decision would depend on factors other than
+   the addresses of the source and the destination, a pair of hosts may
+   simultaneously be using two different means to reach each other,
+   forwarding traffic for applications with different QoS/and or traffic
+   characteristics differently.
+
+
+
+
+Rekhter & Kandlur            Informational                      [Page 5]
+
+RFC 1937        Forwarding in Switched Data Link Subnets        May 1996
+
+
+3.5 Address assignment
+
+   It is expected that if the total number of hosts and routers on a
+   common SVC-based Data Link subnetwork is sufficiently large, then the
+   hosts and routers could be partitioned into groups, called Local
+   Addressing Groups (LAGs). Each LAG would have hosts and routers. The
+   routers within a LAG would act as the first-hop routers for the hosts
+   in the LAG. If the total number of hosts and routers is not large,
+   then all these hosts and routers could form a single LAG. Criteria
+   for determining LAG sizes are outside the scope of this document.
+
+   To provide scalable routing each LAG should be given an IP address
+   prefix, and elements within the LAG should be assigned addresses out
+   of this prefix. The routers in a LAG would then advertise (via
+   appropriate routing protocols) routes to the prefix associated with
+   the LAG. These routes would be advertised as "directly reachable"
+   (with metric 0). Thus, routers within a LAG would act as the last-hop
+   routers for the hosts within the LAG.
+
+4. 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
+   alone are likely to be inadequate for the full utilization of ATM.
+
+   It appears that any model that does not allow SVC management based on
+   QoS and/or traffic requirements will preempt the full use of SVC-
+   based Data Link subnetworks.  Enabling more direct connectivity for
+   applications that could benefit from the functionality provided by
+   SVC-based Data Link subnetworks, while relying on strict hop by hop
+   paths for other applications, could facilitate exploration of the
+   capabilities provided by these 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.
+
+
+
+
+
+
+Rekhter & Kandlur            Informational                      [Page 6]
+
+RFC 1937        Forwarding in Switched Data Link Subnets        May 1996
+
+
+   The proposed model utilizes the SVC-based infrastructure for the
+   applications that could benefit from the capabilities supported
+   within such an infrastructure, and takes advantage of 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.
+
+5. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+6. 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.
+
+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, R., 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Kandlur            Informational                      [Page 7]
+
+RFC 1937        Forwarding in Switched Data Link Subnets        May 1996
+
+
+14.  Authors' Addresses
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Kandlur            Informational                      [Page 8]
+