[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 02 03 04 05 06 07 08 draft-ietf-tsvwg-diffserv-intercon

TSVWG                                                       R. Geib, Ed.
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                         February 25, 2013
Expires: August 29, 2013


             DiffServ interconnection classes and practice
                 draft-geib-tsvwg-diffserv-intercon-02

Abstract

   This document proposes a limited set of interconnection QoS PHBs and
   PHB groups.  It further introduces some DiffServ deployment aspects.
   The proposals made here should be integrated into a revised version
   of RFC5127.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 29, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Geib                     Expires August 29, 2013                [Page 1]


Internet-Draft              Abbreviated Title              February 2013


   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  An Interconnection class and codepoint scheme  . . . . . . . .  5
   4.  Consolidation of QoS standards by the interconnection
       codepoint scheme . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  MPLS, Ethernet and IP Precedence for aggregated classes  . . .  8
   6.  QoS class name selection . . . . . . . . . . . . . . . . . . .  9
   7.  Allow for DiffServ extendability on MPLS and Ethernet level  . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     11.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Change log  . . . . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12



















Geib                     Expires August 29, 2013                [Page 2]


Internet-Draft              Abbreviated Title              February 2013


1.  Introduction

   This draft proposes a DiffServ interconnection class and codepoint
   scheme.  At least one party of an interconnection often is a network
   provider.  Aggregated DiffServ classes are often deployed within
   provider networks.  To respect this, this draft also contains
   concepts and current practice relevant for a revised version of
   RFC5127 [RFC5127].  Its main purpose is to be considered as an input
   for the latter task.

   DiffServ sees deployment in many networks for the time being.  As
   described in the introduction of the draft diffserv problem statement
   [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking of
   packets at domain boundaries is a DiffServ feature.  This draft
   proposes a set of standard QoS classes and codepoints at
   interconnection points to which and from which locally used classes
   and codepoints should be mapped.  Such a scheme simplifies
   interconnection negotiations and ensures that end to end class
   properties remain roughly the same, even if codepoints change.

   The proposed Interconnection class and codepoint scheme tries to
   reflect and consolidate related DiffServ and QoS standardisation
   efforts outside of the IETF, namely MEF, GSMA and ITU.

   IP Precedence has been depricated when DiffServ was standardised.  It
   is common practice today however to copy the DSCPs "IP Precedence
   Bits" into MPLS TC or Ethernet P-Bits, whenever possible.  This is
   reflected by the DiffServ codepoint definitions of AF and EF.  This
   practice and it's limits deserve to be documented and disussed
   briefly.

   The draft further adds proposes a philosophy how to add or pick
   aggregated DiffServ classes.  The set of available router and traffic
   management tools to configure and operate DiffServ classes is
   limited.  This should be reflected by class definitions.  These may
   in the end be more related to transport properties than to
   application requirements.  Please interpret transport properties as
   "congestion aware" and "not congestion aware" rather then TCP or UDP.

   Finally, this draft proposes to leave some MPLS TC codepoint space to
   allow for future DiffServ extensions like ECN/PCN and domain internal
   classes (network management traffic is a good example for the
   latter).  An example for an internal PHB may be CS6, which some
   operators to protect their ntework internal routing and / or
   management traffic.  This PHB may not be available to transport
   customer signaling and management traffic.  It IETF is interested in
   this work, a later version may expand on internal PHBs and
   codepoints.



Geib                     Expires August 29, 2013                [Page 3]


Internet-Draft              Abbreviated Title              February 2013


   In addition to the standardisation activities which triggered this
   work, other authors published RFCs or drafts which may benefit from
   an interconnection class- and codepoint scheme.  RFC 5160 suggests
   Meta-QoS-Classes to enable deployment of standardised end to end QoS
   classes [RFC5160].  The authors agree that the proposed
   interconnection class- and codepoint scheme as well as the idea of
   standardised end to end.  Hence RFC 5160 and this work complement
   each other.  Work on BGP Class of Service Interconnection signaled by
   BGP [I-D.knoll-idr-cos-interconnect] is beyond the the scope of this
   draft.  Should the basic transport and class properties of end to end
   QoS utilising DiffServ based interconnection as proposed by this
   draft be standardised, work on signaled access to QoS classes may be
   of interest.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Terminology

   This draft tries to re-use exitsing terminology.  It further tries to
   indicate, where duplicate terminology may exist.

   Class   A class is a set of one or more PHBs.  If a class consists of
           a set of PHBs and these obey to an ordering constraint.  In
           that sense, a class is a single AF class (e.g. AF4 consisting
           of AF41, AF41 and AF43) [RFC2597].  A class is a PHB group
           [RFC2575] and a PHB scheduling class [RFC3260].  On IP level
           all DSCPs sharing the same IP precedence value belong to a
           single class.  A class may consist of one or more PHBs.  A
           single class uses forwarding resources, which are independent
           of the forwarding rseources of any other class.  Different
           classes must not be aggregated.

   PHB     A single Per Hop Behaviour [RFC2575] is identified by a
           single DSCP on IP layer.

   Many DiffServ related RFCs introduce new terminolgy duplicating the
   existing one.  The above references are incomplete and refer to the
   early DiffServ RFCs only.  Stopping terminology duplication may
   simplify discussion.

   The following current practice issues relate to the concept of the
   DiffServ interconnection class propsal rather than to terminology.
   They serve as additional motivation of this activity:



Geib                     Expires August 29, 2013                [Page 4]


Internet-Draft              Abbreviated Title              February 2013


   o  Abstract class names like "EF" are preferrential over those being
      close to an application, like "Voice".  Unfortunately, non QoS
      experts can't handle abstract class names.  Hence and usually
      sooner than later, classes are named for applications or groups of
      them.  One consequence however is, that people tend to combine
      application group class names and SLA parameters.  Based on an
      application specific name and some worst case performance numbers
      on a paper, they often decide that their application needs a
      separate new QoS class.

   o  Worse than that, but very present in practice, is the class
      abstraction level which is preferred by those dealing with QoS (as
      experts or non experts): the DSCPs or the IP precedence values.
      These are the commodity abstractions applied for QoS classes.
      Most of these persons have fixed class to codepoint mappings in
      their minds, which they can't easily adapt on a per customer or
      interconnection partner basis.

   While these issues aren't to be solved by IETF (QoS experts could and
   should of course teach staff to use proper Diffserv terminology and
   concepts), a simple and comprehensible QoS interconnection class
   scheme also is helpful in this area.


3.  An Interconnection class and codepoint scheme

   DiffServ deployments mostly follow loose class specification schemes
   (often one or two AF classes, EF and Best Effort).  Especially DSCP
   assignment for the AF classes varies between deployments.  Basic AF
   class definitions are often similar however.  This is in line with
   the DiffServ architecture.  This document doesn't propose to change
   that.

   Interconnecting parties face the problem of matching classes to be
   interconnected and then to agree on codepoint mapping.  As stated by
   draft diffserv prolebm statement
   [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking is a
   standard behaviour at interconnection interfaces.  This draft propses
   a set of 4 QoS classes with a set of well defined DSCPs and IP-
   Precedence values as interconnection class and codepoint scheme.  A
   sending party remarks DSCPs from internal schemes to the
   Interconnection codepoints.  The receiving party remarks IP-
   Precedence and or DSCPs to their internal scheme.  Thus the
   interconnection codepoint scheme fully complies with the DiffServ
   architecture.  Such an interconnection class and codepoint scheme was
   introduced by ITU-T [Y.1566] (there also includuing Ethernet).  It is
   specified to a higher level of detail in this document.




Geib                     Expires August 29, 2013                [Page 5]


Internet-Draft              Abbreviated Title              February 2013


   At first glance, this looks like an additional effort.  But there are
   obvious benefits: each party sending or receiving traffic has to
   specify the mapping from or to the interconnection class and
   codepoint scheme only once.  Without it, this is to be negotiated per
   interconnection party individually.  Further, end-to-end QoS in terms
   of traffic being classified for the same class in all passed domains
   is likely to result if an interconnection codepoint scheme is used.
   It is not necessarily resulting from individual per network mapping
   negotiations.

   The standards and deployments known to the author of this draft are
   limited to 4 DiffServ classes at interconnection points (or
   less).Draft RFC 4597 update [I-D.polk-tsvwg-rfc4594-update]doesn't
   seem to generally contradict to this, as it proposes to standardise
   "many services classes, not all will be used in each network at any
   period of time."  Some more good reasons fovour working with 4
   DiffServ interconnection classes for now:

   o  There should be a coding reserve for interconnection classes,
      leaving space for future standards, for bilateral agreements and
      for carrier internal classes.

   o  MPLS and Ethernet support only 8 PHBs, classes or ECN indications.
      Assignment of codepoints for whatever purpose must be well thought
      through.  Limiting interconnection QoS to four classes is MPLS and
      Ethernet friendly in that sense.

   o  Migrations from one codepoint scheme to another may require spare
      QoS codepoints.


4.  Consolidation of QoS standards by the interconnection codepoint
    scheme

   The interconnection class and codepoint scheme proposed by Y.1566
   also tries to consolidate related DiffServ and QoS standardisation
   efforts outside of the IETF [Y.1566].  The interconnection class and
   codepoint scheme may be a suitable approach to consolidate these
   standards.  MEF 23.1 specifies 3 aggregated classes, consuming up to
   5 codepoints on Ethernet layer (EF, AF3 and AF1 and Best Effort) and
   6 PHBs [MEF23.1].  MEF aggregates AF1 and Default PHB in a single
   class.  This is not recommended for interconnection, as it is not in
   line with RFC 2597 (which requires separate forwarding resources for
   each AF class and doesn't forsee aggregation of Default PHB and an AF
   class).

   GSMA IR.34 proposes four classes, EF, AF4, another AF class and Best
   Effort with 7 PHBs in sum [IR.34].  IR.34 specifies an "Interactive"



Geib                     Expires August 29, 2013                [Page 6]


Internet-Draft              Abbreviated Title              February 2013


   class consisting of 3 PHBs with fifferent drop priorities.  IR.34
   specfies the PHBS AF31, AF21 and AF11 for this Interactive class.
   This definitely breaks RFC 2597.  The interconnection class and
   codepoint scheme supports the Interactive class but assigns AF3 with
   PHBs AF31, AF32 and AF33.

   If IETF picks up this draft, it may be a good idea to inform MEF and
   GSMA about conflicts of their standards with DiffServ and suggest
   joint activities to improve the situation.  Information on
   interworkings with MEF 23 and GSMA IR.34 with the interconnection QoS
   scheme could be given by a later version of this draft.

   The classes to be supported at interconnection interfaces are
   specified by Y.1566 as:

   Class Priority:  EF, expecting the figures of merit describing the
           PHB to be in the range of low single digit milliseconds.  See
           [RFC3246].

   Bulk inelastic:  Optimised for low loss, low delay, low jitter at
           high bandwidth.  Traffic load in this class must be
           controlled, e.g. by application servers.  One example could
           be flow admission control.  There may be infrequent
           retransmissions requested by the application layer to
           mitigate low levels of packet losses.  Discard of packets
           through active queue management should be avoided in this
           class.  Congestion in this class may result in bursty packet
           loss.  If used to carry multimedia traffic, it is recommended
           to carry audio and video traffic in a single PHB.  All of
           these properties influence the buffer design.

   Assured:  This class may be optimised to transport traffic without
           bandwidth requirements.  It aims onVery low loss at high
           bandwidths.  Retransmissions after losses characterise the
           class and influence the buffer design.  Active queue
           management with probabilistic dropping may be deployed.

   Default:  Default.  This class may be optimised to transport traffic
           without bandwidth requirements.  Retransmissions after losses
           characterise the class and influence the buffer design.
           Active queue management with probabilistic dropping may be
           deployed.

   Note that other DiffServ related standards trim down class
   requirements to SLA parameters.  To quote e.g RFC 4594-update, "A
   "service class" represents a similar set of traffic characteristics
   for delay, loss, and jitter as packets traverse routers in a
   network."  This draft adds traffic conditioning properties



Geib                     Expires August 29, 2013                [Page 7]


Internet-Draft              Abbreviated Title              February 2013


   corresponding to expected transport layer characteristics as a key
   factor to a class definition: the desired class performance like
   delay, jitter and worst case loss are met only if conditioning and
   and transport properties meet the ones described by the class
   definition.  This is not to say, the other standards ignore
   conditioner properties.  They are e.g. a core part of RFC 4594-
   update.  They do not directly refer to tranport protocol properties,
   as most existing QoS standards prefer the approach of assigning QoS
   classes to applications or application sets.  This may result in
   undesirable class mappings, if an e.g.  IP TV application demanding
   low loss is matched to a class whose low loss guarantees depend on
   AQM mechanisms.

   Y.1566 does not recommend all PHBs to be supported at an
   interconnection interface.  This information is added by this draft.
   At interconnection points, the following PHBs should be accepted
   between interconnected parties:

   Class:  PHB (one or more)

   Class Priority:  EF

   Bulk inelastic:  AF41 (AF42 and AF43 are reserved for extension)

   Assured:  AF31, AF32 and AF33

   Default:  Default

   Class names (and property specification) are picked from Y.1566.
   PHBs to the level of detail introduced here are not part of Y.1566.


5.  MPLS, Ethernet and IP Precedence for aggregated classes

   IP Precedence has been depricated when DiffServ was standardised.
   Ethernet and MPLS support 3 bit codepoint fields to differntiate
   service quality.  Mapping of the IP precedence to these 3 Bit fields
   has been a configuration restriction in the early days of DiffServ.
   The concept of paying attention to the three most significant bits of
   a DSCP has however been part of Diffserv from start on (EF's IP
   Precedence is 5, that of AF4 is 4 and so on).  The interconnection
   class and codepoint scheme respects this in different ways:

   o  it allows to classify four interconnection classes based on IP
      precedence.

   o  It supports a single PHB group (AF3), which may be mapped to up to
      three different MPLS TC's or Ethernet P-Bits.  Note that this



Geib                     Expires August 29, 2013                [Page 8]


Internet-Draft              Abbreviated Title              February 2013


      draft doesn's favour or recommend doing that, but it is possible.
      The author isn't aware of deployed service offers with 3 different
      drop levels in a single class.

   This is of course no requirement to depricate any DSCP to MPLS TC or
   Ethernet P-Bit mapping functionality.  This functionality is very
   important as well.


6.  QoS class name selection

   This is more of an informational discussion, proposed best practice,
   and mainly relates to human behviour (including QoS experts) rather
   than technical issues.  Above the human preference for conceivable
   class names has been mentioned.  Network engineers (including the
   former Diffserv WG authors) recommend to avoid application related
   QoS class names.  Focus should be put on class properties.  But these
   can be irritating again, as just looking at SLA parameters like
   Delay, Jitter and packet loss don't tell the reader, which
   conditioning and transport properties guideed the class engineering
   assumptions resulted in the conditioning of a class.  A router
   produces QoS with a scheduling mechanism, a settable queue depth and
   optional active queue management (including ECN), and may be a
   policer.  Some kind of resource management may be present (also in
   Diffserv domains).  It's beyond the imagination of the author how one
   would engineer more than half a dozen classes with distinguishable
   properties with this set of tools.

   There's no perfect solution to the problem, as conditioning
   configurations are not comprehensible to most readers, even if they
   were communicated (they are operational secrets of course).  There
   are (or should be) engineering assumptions, when designing QoS
   conditioners.  But they closer relate to layer 3 or layer 4 level
   properties than to specific applications.  In general, an application
   responds to congestion by reducing traffic, or it ignores congestion.
   Active queue management doesn't help to avoid congestion in the
   latter case, only resource management does.  EF may be a special
   case.  If the EF traffic is not responsive to congestion, and packets
   are assumed to be short, rather small jitter values can be reached if
   enginieering ensures that the packet arrival rate never exceeds the
   transmision rate of that queue (see RFC 3246 [RFC3246]).  There's
   other non congestion-responsive traffic, for which the EF engineering
   assumptions may not fit.  So conditioning) like bulk inelastic is
   reasonable.

   Active queue management may be deployed for QoS classes, which are
   designed to transport traffic responding to congestion by traffic
   reduction.



Geib                     Expires August 29, 2013                [Page 9]


Internet-Draft              Abbreviated Title              February 2013


   The class names of this document follow Y.1566.  TCP_optimised and
   especially UDP_optimised are inappropriate as clas names, as some UDP
   based application are or may be expected to become TCP friendly.


7.  Allow for DiffServ extendability on MPLS and Ethernet level

   Any aggregated Diffserv deployment faces codepoint depletion issues
   rather soon, if deployed on MPLS or Ethernet.  Coding space should be
   left for new features, like ECN, PCN or Conex.  In addition to
   carrying customer traffic, internal routing and network management
   traffic may be protected by using a separate class.  Offering
   interconnection with up to four classes and 4 - 6 MPLS TC's (or
   Ethernet P-bits) to that respect is probably at least a fair
   compromise.


8.  Acknowledgements

   David Black gave many helpful comments to this work.  Al Morton and
   Sebastien Jobert provided feedback on many aspects during private
   discussions.  Brian Carpenter, Mohamed Boucadair and Thomas Knoll
   helped adding awareness of further potentially related work.


9.  IANA Considerations

   This memo includes no request to IANA.


10.  Security Considerations

   This document does not introduce new features, it describes how to
   use existing ones.  The security section of RFC 4597 [RFC4597]
   applies.


11.  References

11.1.  Normative References

   [RFC2575]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
              Access Control Model (VACM) for the Simple Network
              Management Protocol (SNMP)", RFC 2575, April 1999.

   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597, June 1999.




Geib                     Expires August 29, 2013               [Page 10]


Internet-Draft              Abbreviated Title              February 2013


   [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
              J., Courtney, W., Davari, S., Firoiu, V., and D.
              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
              Behavior)", RFC 3246, March 2002.

   [RFC3260]  Grossman, D., "New Terminology and Clarifications for
              Diffserv", RFC 3260, April 2002.

   [min_ref]  authSurName, authInitials., "Minimal Reference", 2006.

11.2.  Informative References

   [I-D.knoll-idr-cos-interconnect]
              Knoll, T., "BGP Class of Service Interconnection",
              draft-knoll-idr-cos-interconnect-09 (work in progress),
              November 2012.

   [I-D.polk-tsvwg-diffserv-stds-problem-statement]
              Polk, J., "The Problem Statement for the Standard
              Configuration of DiffServ Service Classes",
              draft-polk-tsvwg-diffserv-stds-problem-statement-00 (work
              in progress), July 2012.

   [I-D.polk-tsvwg-rfc4594-update]
              Polk, J., "Standard Configuration of DiffServ Service
              Classes", draft-polk-tsvwg-rfc4594-update-02 (work in
              progress), October 2012.

   [IR.34]    GSMA Association, "IR.34 Inter-Service Provider IP
              Backbone Guidelines Version 7.0", GSMA,  GSMA IR.34 http:/
              /www.gsma.com/newsroom/wp-content/uploads/2012/03/
              ir.34.pdf, 2012.

   [MEF23.1]  MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet
              Class of Service Phase 2", MEF,  MEF23.1 http://
              metroethernetforum.org/PDF_Documents/
              technical-specifications/MEF_23.1.pdf, 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4597]  Even, R. and N. Ismail, "Conferencing Scenarios",
              RFC 4597, August 2006.

   [RFC5127]  Chan, K., Babiarz, J., and F. Baker, "Aggregation of
              Diffserv Service Classes", RFC 5127, February 2008.

   [RFC5160]  Levis, P. and M. Boucadair, "Considerations of Provider-



Geib                     Expires August 29, 2013               [Page 11]


Internet-Draft              Abbreviated Title              February 2013


              to-Provider Agreements for Internet-Scale Quality of
              Service (QoS)", RFC 5160, March 2008.

   [Y.1566]   ITU-T, "Quality of service mapping and interconnection
              between Ethernet, IP and multiprotocol label switching
              networks", ITU,
               http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012.


Appendix A.  Change log

   00 to 01  Added terminology and references.  Added details and
           information to interconnection class and codepoint scheme.
           Editorial changes.

   01 to 02  Added some references regarding rekated work.  Clarified
           class definitions.  Further editorial improvements.


Author's Address

   Ruediger Geib (editor)
   Deutsche Telekom
   Heinrich Hertz Str. 3-7
   Darmstdadt,   64297
   Germany

   Phone: +49 6151 5812747
   Email: Ruediger.Geib@telekom.de






















Geib                     Expires August 29, 2013               [Page 12]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/