rfc2746.txt

RFC 的详细文档！

   The mechanisms described above are useful for unicast tunnels.
   Unicast tunnels provide logical point-to-point links in the IP
   infrastructure, though they may encapsulate and carry either unicast
   or multicast traffic between those points.







Terzis, et al.              Standards Track                    [Page 19]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


   Two other types of tunnels may be imagined.  The first of these is a
   "multicast" tunnel.  In this type of tunnel, packets arriving at an
   entry point are encapsulated and transported (multicast) to -all- of
   the exit points.  This sort of tunnel might prove useful for
   implementing a hierarchical multicast distribution network, or for
   emulating efficiently some portion of a native multicast distribution
   tree.

   A second possible type of tunnel is the "multipoint" tunnel. In this
   type of tunnel, packets arriving at an entry point are normally
   encapsulated and transported to -one- of the exit points, according
   to some route selection algorithm.

   This type of tunnel differs from all previous types in that the '
   shape' of the usual data distribution path does not match the 'shape'
   of the tunnel.  The topology of the tunnel does not by itself define
   the data transmission function that the tunnel performs.  Instead,
   the tunnel becomes a way to express some shared property of the set
   of connected tunnel endpoints.  For example, the "tunnel" may be used
   to create and embed a logical shared broadcast network within some
   larger network.  In this case the tunnel endpoints are the nodes
   connected to the logical shared broadcast network.  Data traffic may
   be unicast between two such nodes, broadcast to all connected nodes,
   or multicast between some subset of the connected nodes.  The tunnel
   itself is used to define a domain in which to manage routing and
   resource management - essentially a virtual private network.

   Note that while a VPN of this form can always be implemented using a
   multicast tunnel to emulate the broadcast medium, this approach will
   be very inefficient in the case of wide area VPNs, and a multipoint
   tunnel with appropriate control mechanisms will be preferable.

   The following paragraphs provide some brief commentary on the use of
   RSVP in these situations. Future versions of this note will provide
   more concrete details and specifications.

   Using RSVP to provide resource management over a multicast tunnel is
   relatively straightforward. As in the unicast case, one or more RSVP
   sessions may be used, and end-to-end RSVP sessions may be mapped onto
   tunnel RSVP sessions on a many-to-one or one-to-one basis. Unlike the
   unicast, case, however, the mapping is complicated by RSVP's
   heterogeneity semantics. If different receivers have made different
   reservation requests, it may be that the RESV messages arriving at
   the tunnel would logically map the receiver's requests to different
   tunnel sessions. Since the data can actually be placed into only one
   session, the choice of session must be reconciled (merged) to select
   the one that will meet the needs of all applications. This requires a
   relatively simple extension to the session mapping mechanism.



Terzis, et al.              Standards Track                    [Page 20]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


   Use of RSVP to support multipoint tunnels is somewhat more difficult.
   In this case, the goal is to give the tunnel as a whole a specific
   level of resources. For example, we may wish to emulate a "logical
   shared 10 megabit Ethernet" rather than a "logical shared Ethernet".
   However, the problem is complicated by the fact that in this type of
   tunnel the data does not always go to all tunnel endpoints. This
   implies that we cannot use the destination address of the
   encapsulated packets as part of the packet classification filter,
   because the destination address will vary for different packets
   within the tunnel.

   This implies the need for an extension to current RSVP session
   semantics in which the Session ID (destination IP address) is used
   -only- to identify the session state within network nodes, but is not
   used to classify packets.  Other than this, the use of RSVP for
   multipoint tunnels follows that of multicast tunnels. A multicast
   group is created to represent the set of nodes that are tunnel
   endpoints, and one or more tunnel RSVP sessions are created to
   reserve resources for the encapsulated packets. In the case of a
   tunnel implementing a simple VPN, it is most likely that there will
   be one session to reserve resources for the whole VPN. Each tunnel
   endpoint will participate both as a source of PATH messages and a
   source of (FF or SE) RESV messages for this single session,
   effectively creating a single shared reservation for the entire
   logical shared medium. Tunnel endpoints MUST NOT make wildcard
   reservations over multipoint tunnels.

9.  Extensions to the RSVP/Routing Interface

   The RSVP specification [RFC2205] states that through the RSVP/Routing
   Interface, the RSVP daemon must be able to learn the list of local
   interfaces along with their IP addresses. In the RSVP Tunnels case,
   the RSVP daemon needs also to learn which of the local interface(s)
   is (are) IP-in-IP tunnel(s) having the capabilities described here.
   The RSVP daemon can acquire this information, either by directly
   querying the underlying network and physical layers or by using any
   existing interface between RSVP and the routing protocol properly
   extended to provide this information.













Terzis, et al.              Standards Track                    [Page 21]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


10.  Security Considerations

   The introduction of RSVP Tunnels raises no new security issues other
   than those associated with the use of RSVP and tunnels. Regarding
   RSVP, the major issue is the need to control and authenticate access
   to enhanced qualities of service. This requirement is discussed
   further in [RFC2205]. [RSVPCRYPTO] describes the mechanism used to
   protect the integrity of RSVP messages carrying the information
   described here.  The security issues associated with IP-in-IP tunnels
   are discussed in [IPINIP4] and [IPV6GEN].

11.  IANA Considerations

   IANA should assign a Class number for the NODE_CHAR object defined in
   Section 3.3.2. This number should be in the 10bbbbbb range. The
   suggested value is 128.

12.  Acknowledgments

   We thank Bob Braden for his insightful comments that helped us to
   produce this updated version of the document.

13.  References

   [ESP]        Atkinson, R., "IP Encapsulating Security Payload (ESP)",
                RFC 1827, August 1995.

   [IP4INIP4]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
                October 1996.

   [IPV6GEN]    Conta, A. and S. Deering, "Generic Packet Tunneling in
                IPv6 Specification", RFC 2473, December 1998.

   [MINENC]     Perkins, C., "Minimal Encapsulation within IP", RFC
                2004, October 1996.

   [RFC1701]    Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
                Routing Encapsulation (GRE)", RFC 1701, October 1994.

   [RFC1702]    Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
                Routing Encapsulation over IPv4 Networks", RFC 1702,
                October 1994.

   [RFC1933]    Gilligan, R. and E. Nordmark, "Transition Mechanisms for
                IPv6 Hosts and Routers", RFC 1933, April 1996.






Terzis, et al.              Standards Track                    [Page 22]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


   [RFC2210]    Wroclawski, J., "The Use of RSVP with IETF Integrated
                Services", RFC 2210, September 1997.

   [RFC2211]    Wroclawski, J., "Specification of the Controlled-Load
                Network Element Service", RFC 2211, September 1997.

   [RFC2212]    Shenker, S., Partridge, C. and R. Guerin, "Specification
                of the Guaranteed Quality of Service", RFC 2212,
                September 1997.

   [RFC2205]    Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
                Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
                1 Functional Specification", RFC 2205, September 1997.

   [RSVPESP]    Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
                Data Flows", RFC 2207, September 1997.

   [RSVPCRYPTO] Baker, F., Lindell, B. and M. Talwar, "RSVP
                Cryptographic Authentication", RFC 2747, January 2000.
































Terzis, et al.              Standards Track                    [Page 23]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


14.  Authors' Addresses

   John Krawczyk
   ArrowPoint Communications
   50 Nagog Park
   Acton, MA 01720

   Phone: [phone]
   EMail:  [e-mail]


   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Lixia Zhang
   UCLA
   4531G Boelter Hall
   Los Angeles, CA  90095

   Phone: [phone]
   EMail: [e-mail]


   Andreas Terzis
   UCLA
   4677 Boelter Hall
   Los Angeles, CA 90095

   Phone: [phone]
   EMail: [e-mail]














Terzis, et al.              Standards Track                    [Page 24]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


15.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Terzis, et al.              Standards Track                    [Page 25]