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

TSVWG                                                       R. Geib, Ed.
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                          November 6, 2012
Expires: May 10, 2013

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

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 May 10, 2013.

Copyright Notice

   Copyright (c) 2012 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 May 10, 2013                  [Page 1]
Internet-Draft              Abbreviated Title              November 2012

   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 . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  An Interconnection class and codepoint scheme . . . . . . . . . 4
   4.  Consolidation of QoS standards by the interconnection
       codepoint scheme  . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  MPLS, Ethernet and IP Precedence for aggregated classes . . . . 6
   6.  QoS class name selection  . . . . . . . . . . . . . . . . . . . 6
   7.  Allow for DiffServ extendability on MPLS and Ethernet level . . 7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

Geib                      Expires May 10, 2013                  [Page 2]
Internet-Draft              Abbreviated Title              November 2012

1.  Introduction

   This draft deals 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 may be mapped.  Such a scheme simplifies
   interconnection negotiations and ensures that 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 proposals by which philosophy 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, which may in
   the end more strongly be related transport properties than
   application requirements.  Please read that "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)

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].

Geib                      Expires May 10, 2013                  [Page 3]
Internet-Draft              Abbreviated Title              November 2012

2.  Terminology

   A later version of this draft needs to be clearer on that.  The
   author prefers to talk of QoS classes.  PHB or PHB groups are not
   commonly used, although they are better defined.  An issue is, that
   PHB groups, which e.g. allow to offer two or more different drop
   levels (PHB's) within one PHB group , hardly saw commercial
   deployment.  This may change with more Ethernet services being
   offered.

   Some rather concept than terminology related real world issues are
   additional motivations of this activity:

   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 and often decide,
      based on a name and some numbers on a paper, that their
      application needs separate QoS class.

   o  Worse than that, but very present in real life, is the class
      abstraction level which is preferred by those dealing with QoS (as
      experts or non experts): the DSCPs or the IP precedence.  So DSCPs
      or IP Precedence values are the commodity real life abstractions
      applied for QoS classes.  Most of these persons hav fixed class to
      codepoint mappings in their minds, which they can't easily adapt
      on a per customer and 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 QoS interconnection scheme also is helpful in
   this area.  Those dealing with QoS on any level need to understand
   the interconnection classes and their codepoints, and they are able
   to deal with the mappings of those to their own networks class and
   codepoint scheme.  Simplicity is important, however.

3.  An Interconnection class and codepoint scheme

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

Geib                      Expires May 10, 2013                  [Page 4]
Internet-Draft              Abbreviated Title              November 2012

   Interconnecting parties usually 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 as
   interconnection codepoint scheme.  As the idea is that a sending
   party remarks DSCPs from internal schemes to the Interconnection
   codepoints and the receiving party remarks to their internal scheme,
   the interconnection codepoint scheme fully complies with the DiffServ
   architecture.

   While this may look like an additional step at first, 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
   once per interconnection party.  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,
   while it is not necessarily resulting from individual per network
   interconnection negotiations.

   The Interconnection scheme is supporting aggregated DiffServ classes,
   as proposed by RFC 5127 [RFC5127].  Note that draft RFC 4597 update
   [I-D.polk-tsvwg-rfc4594-update] doesn't expect any network to deploy
   all possible QoS classes (and proposes to standardise DSCPs for all
   while maintaining deployment of classes a network specific issue).
   RFC2597 does not allow to aggregate separate AF classes [RFC2597].
   Hence a low number of interconnection classes on aggregated level
   makes sense, as some codepoint space for carrier internal services
   and future features like ECN should be left also for aggregatd
   classes.  MPLS and Ethernet only support up to 8 QoS classes.  IP
   over Ethernet and / or MPLS is acommodity in todays operational
   environments, and inter layer QoS likely will be a commodity too.

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].  MEF 23.1 specifies 3
   aggregated classes, consuming up to 5 bit codepoints (EF, two AF
   classes and Best Effort) and 8 DSCPs [MEF23.1].  GSMA IR.34 proposes
   four aggregated DiffServ classes, EF, 2 AF and Best Effort with 7
   DSCPs (PHBs) in sum [IR.34].  Consolidation may be reached for EF,
   one AF class and Best Effort, meaning three aggregated or 5 DSCPs.
   Consolidation here aims on similar class definitions and DiffServ

Geib                      Expires May 10, 2013                  [Page 5]
Internet-Draft              Abbreviated Title              November 2012

   codepoints in all standards, MEF23.1, GSMA IR.34 and Y.1566.  This
   will again simplify product design and interconnection negotiations
   for customers and parties following these standards.

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 aggregated 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 the
      author 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 functionalities are 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 a few SLA numbers doesn't
   tell the reader, which engineering assumptions resulted in the
   scheduler configurations 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 presendt (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.

Geib                      Expires May 10, 2013                  [Page 6]
Internet-Draft              Abbreviated Title              November 2012

   There's no perfect solution to the problem, as scheduler
   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
   schedulers.  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 a second class with EF like properties
   (but a different engineering) may be present.

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

   The author couldn't yet find conceivable class names.  TCP_optimised
   and especially UDP_optimised are inappropriate, 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.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

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

Geib                      Expires May 10, 2013                  [Page 7]
Internet-Draft              Abbreviated Title              November 2012

10.  References

10.1.  Normative References

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

   [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.

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

10.2.  Informative References

   [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.

   [Y.1566]   ITU-T, "Quality of service mapping and interconnection
              between Ethernet, IP and multiprotocol label switching

Geib                      Expires May 10, 2013                  [Page 8]
Internet-Draft              Abbreviated Title              November 2012

              networks", ITU,  draft Y.QoSmap (now Y.61566)  https://
              datatracker.ietf.org/documents/LIAISON/
              liaison-2012-07-03-itu-t-sg-12-tsvwg-development-of-
              informative-codepoint-mapping-in-itu-t-study-group-12-
              attachment-1.zip, 2012.

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 May 10, 2013                  [Page 9]