summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1937.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1937.txt')
-rw-r--r--doc/rfc/rfc1937.txt451
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]
+