rfc2815.txt

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

   best effort service will set the "break bit" described in
   [RSVPINTSERV].

5.  Merging of RSVP/SBM objects

   Where reservations that use the SBM protocol's TCLASS object [SBM]
   need to be merged, an algorithm needs to be defined that is
   consistent with the mappings to individual user_priority values in
   use in the Layer-2 cloud.  A merged reservation must receive at least
   as good a service as the best of the component reservations.

   There is no single merging rule that can prevent all of the following
   side-effects:

   *  If a merger were to demote the existing branch of the flow into a
      higher-delay traffic class then this is a denial of service to the
      existing flow which would likely receive worse service than
      before.

   *  If a merger were to promote the existing branch of the flow into a
      new, lower-delay, traffic class, this might then suffer either
      admission control failures or may cost more in some sense than the
      already-admitted flow. This can also be considered as a denial-
      of-service attack.

   *  Promotion of the new branch may lead to rejection of the request
      because it has been re-assigned to a traffic class that has not
      enough resources to accommodate it.

   Therefore, such a merger is declared to be illegal and the usual SBM
   admission control failure rules are applied. Traffic class selection
   is performed based on the TSpec information. When the first RESV for



Seaman, et al.              Standards Track                    [Page 12]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


   a flow arrives, a traffic class is chosen based on the request, an
   SBM TCLASS object is inserted into the message and admission control
   for that traffic class is done by the SBM. Reservation succeeds or
   fails as usual.

   When a second RESV for the same flow arrives at a different egress
   point of the Layer-2 cloud the process starts to repeat. Eventually
   the SBM-augmented RESV may hit a switch with an existing reservation
   in place for the flow i.e., an L2 branch point for the flow. If so,
   the traffic class chosen for the second reservation is checked
   against the first. If they are the same, the RESV requests are merged
   and passed on towards the sender(s).

   If the second TCLASS would have been different, an RSVP/SBM ResvErr
   error is returned to the Layer-3 device that launched the second RESV
   request into the Layer-2 cloud. This device will then pass on the
   ResvErr to the original requester according to RSVP rules. Detailed
   processing rules are specified in [SBM].

6.  Applicability of these service mappings

   Switches using layer-2-only standards (e.g., 802.1D-1990, 802.1D-
   1998) need to inter-operate with routers and layer-3 switches. Wide
   deployment of such 802.1D-1998 switches will occur in a number of
   roles in the network: "desktop switches" provide dedicated 10/100
   Mbps links to end stations and high speed core switches often act as
   central campus switching points for layer-3 devices. Layer-2 devices
   will have to operate in all of the following scenarios:

   *  every device along a network path is layer-3 capable and intrusive
      into the full data stream

   *  only the edge devices are pure layer-2

   *  every alternate device lacks layer-3 functionality

   *  most devices lack layer-3 functionality except for some key
      control points such as router firewalls, for example.

      Where int-serv flows pass through equipment which does not support
      Integrated Services or 802.1D traffic management and which places
      all packets through the same queuing and overload-dropping paths,
      it is obvious that some of a flow's desired service parameters
      become more difficult to support. In particular, the two
      integrated service classes studied here, Controlled Load and
      Guaranteed Service, both assume that flows will be policed and
      kept "insulated" from misbehaving other flows or from best effort
      traffic during their passage through the network. This cannot be



Seaman, et al.              Standards Track                    [Page 13]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


      done within an IEEE 802 network using devices with the default
      user_priority function; in this case policing must be approximated
      at the network edges.

      In addition, in order to provide a Guaranteed Service, *all*
      switching elements along the path must participate in special
      treatment for packets in such flows: where there is a "break" in
      guaranteed service, all bets are off. Thus, a network path that
      includes even a single switch transmitting onto a shared or half-
      duplex LAN segment is unlikely to be able to provide a very good
      approximation to Guaranteed Service. For Controlled Load service,
      the requirements on the switches and link types are less stringent
      although it is still necessary to provide differential queuing and
      buffering in switches for CL flows over best effort in order to
      approximate CL service. Note that users receive indication of such
      breaks in the path through the "break bits" described in y
      [RSVPINTSERV]. These bits must be correctly set when IEEE 802
      devices that cannot provide a specific service exist in a network.

      Other approaches might be to pass more information between
      switches about the capabilities of their neighbours and to route
      around non-QoS-capable switches: such methods are for further
      study. And of course the easiest solution of all is to upgrade
      links and switches to higher capacities.

7.  References

   [802.1D-ORIG] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993

   [802.1D]      "Information technology - Telecommunications and
                 information exchange between systems - Local and
                 metropolitan area networks - Common specifications -
                 Part 3: Media Access Control (MAC) Bridges:  Revision.
                 This is a revision of ISO/IEC 10038: 1993, 802.1j-1992
                 and 802.6k-1992. It incorporates P802.11c, P802.1p and
                 P802.12e."  ISO/IEC 15802-3:1998"

   [INTSERV]     Braden, R., Clark, D. and S. Shenker, "Integrated
                 Services in the Internet Architecture: an Overview",
                 RFC 1633, June 1994.

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

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




Seaman, et al.              Standards Track                    [Page 14]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


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

   [802.1Q]      ANSI/IEEE Standard 802.1Q-1998, "IEEE Standards for
                 Local and Metropolitan Area Networks: Virtual Bridged
                 Local Area Networks", 1998.

   [GENCHAR]     Shenker, S., and J. Wroclawski, "General
                 Characterization Parameters for Integrated Service
                 Network Elements", RFC 2215, September 1997.

   [IS802FRAME]  Ghanwani, A., Pace, W., Srinivasan, V., Smith, A. and
                 M. Seaman, "A Framework for Providing Integrated
                 Services Over Shared and Switched LAN Technologies",
                 RFC 2816, May 2000.

   [SBM]         Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M.
                 Speer, "SBM (Subnet Bandwidth Manager): A Protocol for
                 Admission Control over IEEE 802-style Networks", RFC
                 2814, May 2000.

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

   [PROCESS]     Bradner, S., "The Internet Standards Process --
                 Revision 3", BCP 9, RFC 2026, October 1996.

8.  Security Considerations

   Any use of QoS requires examination of security considerations
   because it leaves the possibility open for denial of service or theft
   of service attacks. This document introduces no new security issues
   on top of those discussed in the companion ISSLL documents
   [IS802FRAME] and [SBM].  Any use of these service mappings assumes
   that all requests for service are authenticated appropriately.

9.  Acknowledgments

   This document draws heavily on the work of the ISSLL WG of the IETF
   and the IEEE P802.1 Interworking Task Group.










Seaman, et al.              Standards Track                    [Page 15]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


10.  Authors' Addresses

   Mick Seaman
   Telseon
   480 S. California Ave
   Palo Alto, CA 94306
   USA

   Email: [e-mail]


   Andrew Smith
   Extreme Networks
   3585 Monroe St.
   Santa Clara, CA 95051
   USA

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


   Eric Crawley
   Unisphere Solutions
   5 Carlisle Rd.
   Westford, MA 01886

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


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

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













Seaman, et al.              Standards Track                    [Page 16]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


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.



















Seaman, et al.              Standards Track                    [Page 17]