doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc2996.txt b/doc/rfc/rfc2996.txt
new file mode 100644
index 0000000..3db54f4
--- /dev/null
+++ b/doc/rfc/rfc2996.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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]
+