GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2996

Network Working Group Y. Bernet Request for Comments: 2996 Microsoft Category: Standards Track November 2000

                  Format of the RSVP DCLASS Object

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

 Resource Reservation Protocol (RSVP) signaling may be used to request
 Quality of Service (QoS) services and enhance the manageability of
 application traffic's QoS in a differentiated service (diff-serv or
 DS) network.  When using RSVP with DS networks it is useful to be
 able to carry carry Differentiated Services Code Points (DSCPs) in
 RSVP message objects.  One example of this is the use of RSVP to
 arrange for the marking of packets with a particular DSCP upstream
 from the DS network's ingress point, at the sender or at a previous
 network's egress router.
 The DCLASS object is used to represent and carry DSCPs within RSVP
 messages.  This document specifies the format of the DCLASS object
 and briefly discusses its use.

1. Introduction

 This section describes the mechanics of using RSVP [RSVP] signaling
 and the DCLASS object for effecting admission control and applying
 QoS policy within a Differentiated Service network [DS].  It assumes
 standard RSVP senders and receivers, and a diff-serv network
 somewhere in the path between sender and receiver.  At least one RSVP
 aware network element resides in the diff-serv network.  This network
 element may be a policy enforcement point (PEP) [RAP] or may simply
 act as an admission control agent for the network, admitting or
 denying resource requests based on the availability of resources.  In
 either case, this network element interacts with RSVP messages
 arriving from outside the DS network, accepting resource requests

Bernet Standards Track [Page 1] RFC 2996 Format of the RSVP DCLASS Object November 2000

 from RSVP-aware senders and receivers, and conveying the DS network's
 admission control and resource allocation decisions to the higher-
 level RSVP.  The network element is typically a router and will be
 considered to be so for the purpose of this document.  This model is
 described fully in [INTDIFF].

1.1 Use of the DCLASS Object to Carry Upstream Packet Marking

 Information
 A principal usage of the DCLASS object is to carry DSCP information
 between a DS network and upstream nodes that may wish to mark packets
 with DSCP values.  Briefly, the sender composes a standard RSVP PATH
 message and sends it towards the receiver.  At some point the PATH
 message reaches the DS network.  The PATH message traverses one or
 more network elements that are PEPs and/or admission control agents
 for the diff-serv network.  These elements install appropriate state
 and forward the PATH message towards the receiver.  If admission
 control is successful downstream of the diff-serv network, then a
 RESV message will arrive from the direction of the receiver.  As this
 message arrives at the PEPs and/or admission control agents that are
 RSVP enabled, each of these network elements must make a decision
 regarding the admissibility of the signaled flow to the diff-serv
 network.
 If the network element determines that the request represented by the
 PATH and RESV messages is admissible to the diff-serv network, the
 appropriate diff-serv service level (or behavior aggregate) for the
 traffic represented in the RSVP request is determined.  Next, a
 decision is made to mark arriving data packets for this traffic
 locally using MF classification, or to request upstream marking of
 the packets with the appropriate DSCP(s).  This upstream marking
 could occur anywhere before the DS network's ingress point.  Two
 likely candidates are the originating sender and the egress boundary
 router of some upstream (DS or non-DS) network.  The decision about
 where the RSVP request's packets should be marked can be made by
 agreement or through a negotiation protocol; the details are outside
 the scope of this document.
 If the packets for this RSVP request are to be marked upstream,
 information about the DSCP(s) to use must be conveyed from the RSVP-
 aware network element to the upstream marking point.  This
 information is conveyed with the DCLASS object.  To do this, the
 network element adds a DCLASS object containing one or more DSCPs
 corresponding to the behavior aggregate, to the RESV message.  The
 RESV message is then sent upstream towards the RSVP sender.
 If the network element determines that the RSVP request is not
 admissible to the diff-serv network, it sends a RESV error message

Bernet Standards Track [Page 2] RFC 2996 Format of the RSVP DCLASS Object November 2000

 towards the receiver.  No DCLASS is required.

1.1 Additional Uses of the DCLASS Object

 The DCLASS object is intended to be a general tool for conveying DSCP
 information in RSVP messages.  This may be useful in a number of
 situations.  We give one further example here as motivation.
 In this example, we assume that the decision about the appropriate
 behavior aggregate for a RSVP-mediated traffic flow is made at the DS
 network egress router (or a related Policy Decision Point) by
 observing RSVP PATH and RESV messages and other necessary
 information.  However, the actual packet marking must be done at the
 ingress of the network. The DCLASS object can be used to carry the
 needed marking information between egress and ingress routers.

2. Format of the DCLASS Object

 The DCLASS object has the following format:
          0       |       1       |       2       |       3
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Length (>= 8)            |   C-Num (225) |      1        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Unused                               | 1st DSCP  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Unused                               | 2nd DSCP  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Unused                               | . . . .   |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The first word contains the standard RSVP object header (the Class
 Num for the DCLASS object is 225).  The length field indicates the
 total object length in bytes.  The object header is followed by one
 or more 32-bit words, each containing a DSCP in the six high-order
 bits of the least significant byte.  The length field in the object
 header indicates the number of DSCPs included in the object.
 Specifically, the number of DCLASS objects present is equal to
 (Length - 4) / 4.
 The network may return multiple DSCPs in the DCLASS object in order
 to enable the host to discriminate sub-flows within a behavior
 aggregate. For example, in the case of the AF PHB group [AF], the
 network may return the DSCPs 001010, 001100, and 001110 corresponding
 to increasing levels of drop precedence within Class 1 of the AF PHB
 group.  Note that this document makes no statements regarding the
 significance of the order of the returned DSCPs.  Further
 interpretation of DSCP sets is dependent on the specific service

Bernet Standards Track [Page 3] RFC 2996 Format of the RSVP DCLASS Object November 2000

 requested by the host and is beyond the scope of this document.
 Note that the Class-Num for the DCLASS object is chosen from the
 space of unknown class objects that should be ignored and forwarded
 by nodes that do not recognize it.  This is to assure maximal
 backward compatibility.

3. Admission Control Functionality

 From a black-box perspective, admission control and policy
 functionality amounts to the decision whether to accept or reject a
 request and the determination of the DSCPs that should be used for
 the corresponding traffic.  The specific details of admission control
 are beyond the scope of this document.  In general the admission
 control decision is based both on resource availability and on
 policies regarding the use of resources in the diff-serv network.
 The admission control decision made by RSVP aware network elements
 represents both considerations.
 In order to decide whether the RSVP request is admissible in terms of
 resource availability, one or more network elements within or at the
 boundary of the diff-serv network must understand the impact that
 admission would have on specific diff-serv resources, as well as the
 availability of these resources along the relevant data path in the
 diff-serv network.
 In order to decide whether the RSVP request is admissible in terms of
 policy, the network element may use identity objects describing users
 and/or applications that may be included in the request.  The router
 may act as a PEP/PDP and use data from a policy database or directory
 to aid in this decision.
 See Appendix A for a simple mechanism for configurable resource based
 admission control.

4. Security Considerations

 The DCLASS object conveys information that can be used to request
 enhanced QoS from a DS network, so inappropriate modification of the
 object could allow traffic flows to obtain a higher or lower level of
 QoS than appropriate.  Particularly, modification of a DCLASS object
 by a third party inserted between the DS network ingress node and the
 upstream marker constitutes a possible denial of service attack.
 This attack is subtle because it is possible to reduce the received
 QoS to an unacceptably low level without completely cutting off data
 flow, making the attack harder to detect.
 The possibility of raising the received level of QoS by inappropriate

Bernet Standards Track [Page 4] RFC 2996 Format of the RSVP DCLASS Object November 2000

 modification of the DCLASS object is less significant because it a
 subclass of a larger class of attacks that must already be detected
 by the system.  Protection must already be in place to prevent a host
 raising its received level of QoS by simply guessing "good" DSCP's
 and marking packets accordingly.  If this protection is at the
 boundary of the DS network, it will detect inappropriate marking of
 arriving packets caused by modified DCLASS objects as well.  If,
 however, the protection function as well as the marking function has
 been pushed upstream (perhaps to a trusted third party or
 intermediate node), correct transmission of the DCLASS object must be
 ensured to prevent a possible theft of service attack.
 Simple observation of the DCLASS object in a RSVP message raises
 several issues which may be seen as security concerns.  Correlation
 of observed DCLASS object values with RSVP requests or MF
 classification parameters allows the observer to determine that
 different flows are receiving different levels of QoS, which may be
 knowledge that should be protected in some environments.  Similarly,
 observation of the DCLASS object can allow the observer to determine
 that a single flow's QoS has been promoted or demoted, which may
 signal significant events in the life of that flow's application or
 user.  Finally, observation of the DCLASS object may reveal
 information about the internal operations of a DS network that could
 be useful to observers interested in theft-of-services attacks.

5. References

 [INTDIFF]  Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
            Speer, M., Braden, R., Davie, B. and J. Wroclawski, "A
            Framework for Integrated Services Operation over Diffserv
            Networks", RFC 2998, November 2000.
 [DS]       Blake, S., Carlson, M., Davies, D., Wang, Z. and W. Weiss,
            "An Architecture for Differentiated Services", RFC 2475,
            December 1998.
 [RSVP]     Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
            Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
            Functional Specification", RFC 2205, September 1997.
 [RAP]      Yavatkar, R., Pendarakis, D. and R. Guerin,  "A Framework
            for Policy Based Admission Control", RFC 2753, January
            2000.
 [AF]       Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
            "Assured Forwarding PHB Group", RFC 2597, June 1999.

Bernet Standards Track [Page 5] RFC 2996 Format of the RSVP DCLASS Object November 2000

6. Acknowledgments

 Thanks to Fred Baker and Carol Iturralde for reviewing this document.
 Thanks to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee for
 input.

7. Author's Address

 Yoram Bernet
 Microsoft
 One Microsoft Way,
 Redmond, WA 98052
 Phone: (425) 936-9568
 EMail: yoramb@microsoft.com

Bernet Standards Track [Page 6] RFC 2996 Format of the RSVP DCLASS Object November 2000

Appendix A - Simple Configurable Resource Based Admission Control

 Routers may use quite sophisticated mechanisms in making the
 admission control decision, including policy considerations, various
 intra-domain signaling protocols, results of traffic monitoring and
 so on.  It is recommended that the following basic functionality be
 provided to enable simple resource based admission control in the
 absence of more sophisticated mechanisms.  This functionality can be
 used with configurable, standalone routers.  It applies to standard
 RSVP/Intserv requests.  This minimal functionality assumes only a
 single DSCP is included in the DCLASS object, but may readily be
 extended to support multiple DSCPs.
 It must be possible to configure two tables in the router.  These are
 described below.

A.1 Service Type to DSCP Mapping

 One table provides a mapping from the intserv service-type specified
 in the RSVP request to a DSCP that can be used to obtain a
 corresponding service in the diff-serv network.  This table contains
 a row for each intserv service type for which a mapping is available.
 Each row has the following format:
    Intserv service type : DSCP
 The table would typically contain at least three rows; one for
 Guaranteed service, one for Controlled Load service and one for Best-
 Effort service.  (The best-effort service will typically map to DSCP
 000000, but may be overridden).  It should be possible to add rows
 for as-yet-undefined service types.
 This table allows the network administrator to statically configure a
 DSCP that the router will return in the DCLASS object for an admitted
 RSVP request.  In general, more sophisticated and likely more dynamic
 mechanisms may be used to determine the DSCP to be returned in the
 DCLASS object.  Also, it is likely that a real mapping for some
 services would use more than one DSCP, with the DSCP depending on the
 invocation parameters of a specific service request.  In this case,
 these mechanisms may override or replace the static table based
 mapping described here.

A.2 Quantitative Resource Availability

 Standard intserv requests are quantitative in nature.  They include
 token bucket parameters describing the resources required by the
 traffic for which admission is requested.  The second table enables
 the network administrator to statically configure quantitative

Bernet Standards Track [Page 7] RFC 2996 Format of the RSVP DCLASS Object November 2000

 parameters to be used by the router when making an admission control
 decision for quantitative service requests.  Each row in this table
 has the following form:
    DSCP : Token bucket profile
 The first column specifies those DSCPs for which quantitative
 admission control is applied.  The second column specifies the token
 bucket parameters which represent the total resources available in
 the diff-serv network to accommodate traffic in the service class
 specified by the DSCP.

Bernet Standards Track [Page 8] RFC 2996 Format of the RSVP DCLASS Object November 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.

Bernet Standards Track [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2996.txt · Last modified: 2000/11/14 23:29 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki