rfc1937.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 452 行 · 第 1/2 页


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:  [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]

































Rekhter & Kandlur            Informational                      [Page 8]