doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3260.txt b/doc/rfc/rfc3260.txt
new file mode 100644
index 0000000..db29e6c
--- /dev/null
+++ b/doc/rfc/rfc3260.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                        D. Grossman
+Request for Comments: 3260                                Motorola, Inc.
+Updates: 2474, 2475, 2597                                     April 2002
+Category: Informational
+
+
+            New Terminology and Clarifications for Diffserv
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This memo captures Diffserv working group agreements concerning new
+   and improved terminology, and provides minor technical
+   clarifications.  It is intended to update RFC 2474, RFC 2475 and RFC
+   2597.  When RFCs 2474 and 2597 advance on the standards track, and
+   RFC 2475 is updated, it is intended that the revisions in this memo
+   will be incorporated, and that this memo will be obsoleted by the new
+   RFCs.
+
+1.  Introduction
+
+   As the Diffserv work has evolved, there have been several cases where
+   terminology has needed to be created or the definitions in Diffserv
+   standards track RFCs have needed to be refined.  Some minor technical
+   clarifications were also found to be needed.  This memo was created
+   to capture group agreements, rather than attempting to revise the
+   base RFCs and recycle them at proposed standard.  It updates in part
+   RFC 2474, RFC 2475 and RFC 2597.  RFC 2598 has been obsoleted by RFC
+   3246, and clarifications agreed by the group were incorporated in
+   that revision.
+
+2. Terminology Related to Service Level Agreements (SLAs)
+
+   The Diffserv Architecture [2] uses the term "Service Level Agreement"
+   (SLA) to describe the "service contract... that specifies the
+   forwarding service a customer should receive".  The SLA may include
+   traffic conditioning rules which (at least in part) constitute a
+   Traffic Conditioning Agreement (TCA).  A TCA is "an agreement
+
+
+
+
+Grossman                     Informational                      [Page 1]
+
+RFC 3260    New Terminology and Clarifications for Diffserv   April 2002
+
+
+   specifying classifier rules and any corresponding traffic profiles
+   and metering, marking, discarding and/or shaping rules which are to
+   apply...."
+
+   As work progressed in Diffserv (as well as in the Policy WG [6]), it
+   came to be believed that the notion of an "agreement" implied
+   considerations that were of a pricing, contractual or other business
+   nature, as well as those that were strictly technical.  There also
+   could be other technical considerations in such an agreement (e.g.,
+   service availability) which are not addressed by Diffserv.  It was
+   therefore agreed that the notions of SLAs and TCAs would be taken to
+   represent the broader context, and that new terminology would be used
+   to describe those elements of service and traffic conditioning that
+   are addressed by Diffserv.
+
+      -  A Service Level Specification (SLS) is a set of parameters and
+         their values which together define the service offered to a
+         traffic stream by a DS domain.
+
+      -  A Traffic Conditioning Specification (TCS) is a set of
+         parameters and their values which together specify a set of
+         classifier rules and a traffic profile.  A TCS is an integral
+         element of an SLS.
+
+   Note that the definition of "Traffic stream" is unchanged from RFC
+   2475.  A traffic stream can be an individual microflow or a group of
+   microflows (i.e., in a source or destination DS domain) or it can be
+   a BA.  Thus, an SLS may apply in the source or destination DS domain
+   to a single microflow or group of microflows, as well as to a BA in
+   any DS domain.
+
+   Also note that the definition of a "Service Provisioning Policy" is
+   unchanged from RFC 2475.  RFC 2475 defines a "Service Provisioning
+   Policy as "a policy which defines how traffic conditioners are
+   configured on DS boundary nodes and how traffic streams are mapped to
+   DS behavior aggregates to achieve a range of services."  According to
+   one definition given in RFC 3198 [6], a policy is "...a set of rules
+   to administer, manage, and control access to network resources".
+   Therefore, the relationship between an SLS and a service provisioning
+   policy is that the latter is, in part, the set of rules that express
+   the parameters and range of values that may be in the former.
+
+   Further note that this definition is more restrictive than that in
+   RFC 3198.
+
+
+
+
+
+
+
+Grossman                     Informational                      [Page 2]
+
+RFC 3260    New Terminology and Clarifications for Diffserv   April 2002
+
+
+3. Usage of PHB Group
+
+   RFC 2475 defines a Per-hop behavior (PHB) group to be:
+
+      "a set of one or more PHBs that can only be meaningfully specified
+      and implemented simultaneously, due to a common constraint
+      applying to all PHBs in the set such as a queue servicing or queue
+      management policy.  A PHB group provides a service building block
+      that allows a set of related forwarding behaviors to be specified
+      together (e.g., four dropping priorities).  A single PHB is a
+      special case of a PHB group."
+
+   One standards track PHB Group is defined in RFC 2597 [3], "Assured
+   Forwarding PHB Group".  Assured Forwarding (AF) is a type of
+   forwarding behavior with some assigned level of queuing resources and
+   three drop precedences.  An AF PHB Group consists of three PHBs, and
+   uses three Diffserv Codepoints (DSCPs).
+
+   RFC 2597 defines twelve DSCPs, corresponding to four independent AF
+   classes.  The AF classes are referred to as AF1x, AF2x, AF3x, and
+   AF4x (where 'x' is 1, 2, or 3 to represent drop precedence).  Each AF
+   class is one instance of an AF PHB Group.
+
+   There has been confusion expressed that RFC 2597 refers to all four
+   AF classes with their three drop precedences as being part of a
+   single PHB Group.  However, since each AF class operates entirely
+   independently of the others, (and thus there is no common constraint
+   among AF classes as there is among drop precedences within an AF
+   class) this usage is inconsistent with RFC 2475.  The inconsistency
+   exists for historical reasons and will be removed in future revisions
+   of the AF specification.  It should now be understood that AF is a
+   _type_ of PHB group, and each AF class is an _instance_ of the AF
+   type.
+
+   Authors of new PHB specifications should be careful to adhere to the
+   RFC 2475 definition of PHB Group.  RFC 2475 does not prohibit new PHB
+   specifications from assigning enough DSCPs to represent multiple
+   independent instances of their PHB Group.  However, such a set of
+   DSCPs must not be referred to as a single PHB Group.
+
+4. Definition of the DS Field
+
+   Diffserv uses six bits of the IPV4 or IPV6 header to convey the
+   Diffserv Codepoint (DSCP), which selects a PHB.  RFC 2474 attempts to
+   rename the TOS octet of the IPV4 header, and Traffic Class octet of
+   the IPV6 header, respectively, to the DS field.  The DS Field has a
+   six bit Diffserv Codepoint and two "currently unused" bits.
+
+
+
+
+Grossman                     Informational                      [Page 3]
+
+RFC 3260    New Terminology and Clarifications for Diffserv   April 2002
+
+
+   It has been pointed out that this leads to inconsistencies and
+   ambiguities.  In particular, the "Currently Unused" (CU) bits of the
+   DS Field have not been assigned to Diffserv, and subsequent to the
+   publication of RFC 2474, they were assigned for explicit congestion
+   notification, as defined in RFC 3168 [4].  In the current text, a
+   DSCP is, depending on context, either an encoding which selects a PHB
+   or a sub-field in the DS field which contains that encoding.
+
+   The present text is also inconsistent with BCP 37, IANA Allocation
+   Guidelines for Values in the Internet Protocol and Related Headers
+   [5].  The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class
+   field are superseded by the 6 bit DS field and a 2 bit CU field.  The
+   IANA allocates values in the DS field following the IANA
+   considerations section in RFC 2474, as clarified in section 8 of this
+   memo.
+
+   The consensus of the DiffServ working group is that BCP 37 correctly
+   restates the structure of the former TOS and traffic class fields.
+
+   Therefore, for use in future documents, including the next update to
+   RFC 2474, the following definitions should apply:
+
+      -  the Differentiated Services Field (DSField) is the six most
+         significant bits of the (former) IPV4 TOS octet or the (former)
+         IPV6 Traffic Class octet.
+
+      -  the Differentiated Services Codepoint (DSCP) is a value which
+         is encoded in the DS field, and which each DS Node MUST use to
+         select the PHB which is to be experienced by each packet it
+         forwards.
+
+   The two least significant bits of the IPV4 TOS octet and the IPV6
+   Traffic Class octet are not used by Diffserv.
+
+   When RFC 2474 is updated, consideration should be given to changing
+   the designation "currently unused (CU)" to "explicit congestion
+   notification (ECN)" and referencing RFC 3168 (or its successor).
+
+   The update should also reference BCP 37.
+
+5. Ordered Aggregates and PHB Scheduling Classes
+
+   Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to
+   the realization that a concept was needed in Diffserv to capture the
+   notion of a set of BAs with a common ordering constraint.  This
+   presently applies to AF behavior aggregates, since a DS node may not
+   reorder packets of the same microflow if they belong to the same AF
+   class.  This would, for example, prevent an MPLS LSR, which was also
+
+
+
+Grossman                     Informational                      [Page 4]
+
+RFC 3260    New Terminology and Clarifications for Diffserv   April 2002
+
+
+   a DS node, from discriminating between packets of an AF Behavior
+   Aggregate (BA) based on drop precedence and forwarding packets of the
+   same AF class but different drop precedence over different LSPs.  The
+   following new terms are defined.
+
+      PHB Scheduling Class: A PHB group for which a common constraint is
+      that, ordering of at least those packets belonging to the same
+      microflow must be preserved.
+
+      Ordered Aggregate (OA): A set of Behavior Aggregates that share an
+      ordering constraint.  The set of PHBs that are applied to this set
+      of Behavior Aggregates constitutes a PHB scheduling class.
+
+6. Unknown/Improperly Mapped DSCPs
+
+   Several implementors have pointed out ambiguities or conflicts in the
+   Diffserv RFCs concerning behavior when a DS-node receives a packet
+   with a DSCP which it does not understand.
+
+   RFC 2475 states:
+      "Ingress nodes must condition all other inbound traffic to ensure
+      that the DS codepoints are acceptable; packets found to have
+      unacceptable codepoints must either be discarded or must have
+      their DS codepoints modified to acceptable values before being
+      forwarded.  For example, an ingress node receiving traffic from a
+      domain with which no enhanced service agreement exists may reset
+      the DS codepoint to the Default PHB codepoint [DSFIELD]."
+
+   On the other hand, RFC 2474 states:
+      "Packets received with an unrecognized codepoint SHOULD be
+      forwarded as if they were marked for the Default behavior (see
+      Sec. 4), and their codepoints should not be changed."
+
+   RFC 2474 is principally concerned with DS-interior nodes.  However,
+   this behavior could also be performed in DS-ingress nodes AFTER the
+   traffic conditioning required by RFC 2475 (in which case, an
+   unrecognized DSCP would occur only in the case of misconfiguration).
+   If a packet arrives with a DSCP that hadn't been explicitly mapped to
+   a particular PHB, it should be treated the same way as a packet
+   marked for Default.  The alternatives were to assign it another PHB,
+   which could result in misallocation of provisioned resources, or to
+   drop it.  Those are the only alternatives within the framework of RFC
+   2474.  Neither alternative was considered desirable.  There has been
+   discussion of a PHB which receives worse service than the default;
+   this might be a better alternative.  Hence the imperative was
+   "SHOULD" rather than "SHALL".
+
+
+
+
+
+Grossman                     Informational                      [Page 5]
+
+RFC 3260    New Terminology and Clarifications for Diffserv   April 2002
+
+
+   The intent of RFC 2475 clearly concerns DS-ingress nodes, or more
+   precisely, the ingress traffic conditioning function.  This is
+   another context where the "SHOULD" in RFC 2474 provides the
+   flexibility to do what the group intended.  Such tortured readings
+   are not desirable.
+
+   Therefore, the statement in RFC 2474 will be clarified to indicate
+   that it is not intended to apply at the ingress traffic conditioning
+   function at a DS-ingress node, and cross reference RFC 2475 for that
+   case.
+
+   There was a similar issue, which manifested itself with the first
+   incarnation of Expedited Forwarding (EF).  RFC 2598 states:
+
+      To protect itself against denial of service attacks, the edge of a
+      DS domain MUST strictly police all EF marked packets to a rate
+      negotiated with the adjacent upstream domain.  (This rate must be
+      <= the EF PHB configured rate.)  Packets in excess of the
+      negotiated rate MUST be dropped.  If two adjacent domains have not
+      negotiated an EF rate, the downstream domain MUST use 0 as the
+      rate (i.e., drop all EF marked packets).
+
+   The problem arose in the case of misconfiguration or routing
+   problems.  An egress DS-node at the edge of one DS-domain forwards
+   packets to an ingress DS-node at the edge of another DS domain.
+   These packets are marked with a DSCP that the egress node understands
+   to map to EF, but which the ingress node does not recognize.  The
+   statement in RFC 2475 would appear to apply to this case.  RFC 3246
+   [7] clarifies this point.
+
+7. No Backward Compatibility With RFC 1349
+
+   At least one implementor has expressed confusion about the
+   relationship of the DSField, as defined in RFC 2474, to the use of
+   the TOS bits, as described in RFC 1349.  The RFC 1349 usage was
+   intended to interact with OSPF extensions in RFC 1247.  These were
+   never widely deployed and thus removed by standards action when STD
+   54, RFC 2328, was published.  The processing of the TOS bits is
+   described as a requirement in RFC 1812 [8], RFC 1122 [9] and RFC 1123
+   [10].  RFC 2474 states:
+
+      "No attempt is made to maintain backwards compatibility with the
+      "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791].",
+
+
+
+
+
+
+
+
+Grossman                     Informational                      [Page 6]
+
+RFC 3260    New Terminology and Clarifications for Diffserv   April 2002
+
+
+   In addition, RFC 2474 obsoletes RFC 1349 by IESG action.  For
+   completeness, when RFC 2474 is updated, the sentence should read:
+
+      "No attempt is made to maintain backwards compatibility with the
+      "DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in
+      [RFC791] and [RFC1349].  This implies that TOS bit processing as
+      described in [RFC1812], [RFC1122] and [RFC1123] is also obsoleted
+      by this memo.  Also see [RFC2780]."
+
+8. IANA Considerations
+
+   IANA has requested clarification of a point in RFC 2474, concerning
+   registration of experimental/local use DSCPs.  When RFC 2474 is
+   revised, the following should be added to Section 6:
+
+      IANA is requested to maintain a registry of RECOMMENDED DSCP
+      values assigned by standards action.  EXP/LU values are not to be
+      registered.
+
+9. Summary of Pending Changes
+
+   The following standards track and informational RFCs are expected to
+   be updated to reflect the agreements captured in this memo.  It is
+   intended that these updates occur when each standards track RFC
+   progresses to Draft Standard (or if some issue arises that forces
+   recycling at Proposed).  RFC 2475 is expected to be updated at about
+   the same time as RFC 2474.  Those updates will also obsolete this
+   memo.
+
+      RFC 2474: revise definition of DS field.  Clarify that the
+      suggested default forwarding in the event of an unrecognized DSCP
+      is not intended to apply to ingress conditioning in DS-ingress
+      nodes.  Clarify effects on RFC 1349 and RFC 1812.  Clarify that
+      only RECOMMENDED DSCPs assigned by standards action are to be
+      registered by IANA.
+
+      RFC 2475: revise definition of DS field.  Add SLS and TCS
+      definitions.  Update body of document to use SLS and TCS
+      appropriately.  Add definitions of PHB scheduling class and
+      ordered aggregate.
+
+      RFC 2497: revise to reflect understanding that, AF classes are
+      instances of the AF PHB group, and are not collectively a PHB
+      group.
+
+
+
+
+
+
+
+Grossman                     Informational                      [Page 7]
+
+RFC 3260    New Terminology and Clarifications for Diffserv   April 2002
+
+
+   In addition, RFC 3246 [7] has added a reference to RFC 2475 in the
+   security considerations section to cover the case of a DS egress node
+   receiving an unrecognized DSCP which maps to EF in the DS ingress
+   node.
+
+10. Security Considerations
+
+   Security considerations are addressed in RFC 2475.
+
+Acknowledgements
+
+   This memo captures agreements of the Diffserv working group.  Many
+   individuals contributed to the discussions on the Diffserv list and
+   in the meetings.  The Diffserv chairs were Brian Carpenter and Kathie
+   Nichols.  Among many who participated actively in these discussions
+   were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim,
+   Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John
+   Schnizlein, Francois Le Faucheur, and Fred Baker.  Mike Ayers, Mike
+   Heard and Andrea Westerinen provided valuable editorial comments.
+
+Normative References
+
+   [1]  Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
+        the Differentiated Services Field (DS Field) in the IPv4 and
+        IPv6 Headers", RFC 2474, December 1998.
+
+   [2]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
+        Weiss, "An Architecture for Differentiated Services", RFC 2475,
+        December 1998.
+
+   [3]  Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski, "Assured
+        Forwarding PHB Group", RFC 2597, June 1999.
+
+   [4]  Ramakrishnan, K., Floyd, S. and D. Black "The Addition of
+        Explicit Congestion Notification (ECN) to IP", RFC 3168,
+        September 2001.
+
+   [5]  Bradner, S. and V. Paxon, "IANA Allocation Guidelines for Values
+        in the Internet Protocol and Related Headers", BCP 37, RFC2780,
+        March 2000.
+
+   [6]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
+        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
+        Waldbusser, "Terminology for Policy-Based Management", RFC 3198,
+        November 2001.
+
+
+
+
+
+
+Grossman                     Informational                      [Page 8]
+
+RFC 3260    New Terminology and Clarifications for Diffserv   April 2002
+
+
+   [7]  Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K.,
+        Le Boudec, J., Chiu, A., Courtney, W., Cavari, S., Firoiu, V.,
+        Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An Expedited
+        Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
+
+   [8]  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
+        June 1995.
+
+   [9]  Braden, R., "Requirements for Internet Hosts -- Communications
+        Layers", STD 3, RFC 1122, October 1989.
+
+   [10] Braden, R., "Requirements for Internet Hosts -- Application and
+        Support", STD 3, RFC 1123, October 1989.
+
+Author's Address
+
+   Dan Grossman
+   Motorola, Inc.
+   20 Cabot Blvd.
+   Mansfield, MA 02048
+
+   EMail: dan@dma.isg.mot.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Grossman                     Informational                      [Page 9]
+
+RFC 3260    New Terminology and Clarifications for Diffserv   April 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Grossman                     Informational                     [Page 10]
+