Subject: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr

From: Dave McDysan <[email-masked]>
Date: Thu, 11 Jan 2007 14:57:59 -0500

Resending these comments. I did not receive a copy via the tsvwg mailing
list and it was not in the archives.

Dave

-----Original Message-----
From: Dave McDysan [mailto:[email-masked]] 
Sent: Tuesday, January 02, 2007 11:03 AM
To: 'Magnus Westerlund'; 'tsvwg'
Cc: 'Fred Baker'; 'Kwok-Ho Chan'; [email-masked]'
Subject: Review of draft-ietf-tsvwg-diffserv-class-aggr

As requested, here is my review of the subject draft.

Within Verizon and draft work in the MPLS FR ATM Alliance (MFA) we are using
RFC 4594 and ITU-T Y.1541 in our definitions of Diffserv, PW and native MPLS
deployments. An RFC that gave some guidance and a baseline for how to map
these various services to treatment aggregates as defined by MPLS EXP bits
would be extremely useful for internal use as well as use in specifying
network interconnections. These comments are based upon a review of the
various deployed and proposed uses of EXP bits within Verizon, experience on
negogiating interconnects with other service providers, work within the MFA
and the results of MIT Interprovider QoS workshops, as summarized in the
following: 
http://cfp.mit.edu/resources/papers/Interprovider%20QoS%20MIT_CFP_WP_9_14_06
.pdf

Suggest that in section 1, Introduction that the draft explicitly state the
assumption that all traffic is IP and marked with a particular set of DSCP
values, as described in RFC 4594. 

In some cases cited below bullet 5 in section 3, overview of service class
aggregation,  the traffic carried may not be IP (e.g., TDM, FR, ATM or
Ethernet over pseudowire, VPLS). Section 2, Terminology, references RFC 3270
definitions of E-LSP and L-LSP, which include the concept of a Forwarding
Equivalency Class (FEC). I suggest that either the scope of this draft
should be constrained to only IP and these other applications be mentioned
as out of scope, or else more text regarding handling of non-IP applications
needs to be added. For example, there could be an IP FEC and a non-IP FEC
for use with E-LSP or L-LSP from RFC 3270.

Suggest that the authors add some text to section 4.1.,  Mapping Service
Classes into Four Treatment Aggregates, explaining why those chose 4 instead
of 3 or 5 treatment aggregates. From section 1, " Note that in a given
domain, we may recommend that the supported service classes be aggregated
into forwarding treatment aggregates;   however, this does not mean all
service classes need to be supported and hence not all forwarding treatment
aggregates need to be supported." This text implies specification of a
maximum set of treatment aggregates, and a means to map these to a minimum
set. Is the intent of this draft to specify the minimum or maximum set?

In Figure 1, Treatment Aggregate and Service Class Performance Requirements,
I think that broadcast video is not Real-Time. Also, in enterprise VPNs, we
have distinguished Telephony/Signaling from Mulitmedia conferencing in
treatment aggregates in deployed networks. 

Section 4.1.1.  Network Control Treatment Aggregate. We view network control
as an IP-only service class, not subject to (MPLS) treatment aggregation.
Although some VPN service providers have proposed extending this service
class across an interconnect to their networks, we have convinced them that
they should map customer network control traffic (e.g., BGP, or IGP
information for an RFC 4364 VPN) or their own network control class to some
other behavior or treatment aggregate. 

Suggest that the draft add some text indicating that network control traffic
is for internal use to a network. For example, Section 4.2.1 of RFC 4274
could be cited: "The Network Control precedence designation is intended to
be used within a network only.  The actual use and control of that
designation is up to each network. [RFC791]" 

4.1.2.  Real Time Treatment Aggregate. As mentioned above, current and
planned deployments break out telephony/signaling from multimedia
conferencing and broadcast video. If the draft is proposing that the
real-time treatment aggregate (as defined in 1994 from RFC 1633) is part of
a minimum treatment aggregate set, then it should state this. I would like
to see mention of a larger treatment aggregate set that at least splits out
telephony/signaling from multimedia conferencing and broadcast video. 

4.1.3.  Assured Elastic Treatment Aggregate. Personally, I think that the
indication of loss probability in a treatment aggregate is a good idea.
However, some deployments and plans do not use this. Also, this means using
up to an additional bit in the limited 3-bit MPLS EXP field. Suggest that
the draft state that indicating the loss probability is highly desirable,
but may not be part of the minimum set of treatment aggregates that a
network segment may implement (see section 1).

4.1.4.  Elastic Treatment Aggregate. Personally, I think that the indication
of loss probability in a treatment aggregate is a good idea. However, some
deployments and plans do not use this. Also, this means using up to an
additional bit in the limited 3-bit MPLS EXP field. Suggest that the draft
state that indicating the loss probability is highly desirable, but may not
be part of the minimum set of treatment aggregates that a network segment
may implement (see section 1).

5.  Using MPLS for Treatment Aggregates, first paragraph. As mentioned
above, suggest that the authors clarify whether this is the maximum or
minimum set of treatment aggregates as described in section 1 that are
recommended.

This section is where the most significant issues exist.

5.1.  Network Control Treatment Aggregate with E-LSP

In discussions with internal users as well as discussions in the MFA, there
is not much support for using a set of MPLS EXP bits for network control.
Looking at the description for network control from RFC 4594, it appears
that most of these uses would be IP only and not be subject to MPLS
encapsulation. The one exception we discussed is how to handle network
control DSCP marked packets from BGP IP MPLS VPN customers. This could be
done using the proposed "110" codepoint in Figure 3, but another method
would be for the service provider to map customer network control traffic to
some other treatment aggregate (e.g., assured elastic). Suggest that the
network control treatment aggregate usage with MPLS EXP bit marking be more
clearly stated in the draft. Also, suggest that the network control
treatment aggregate be part of the maximum treatment aggregate set.

5.2.  Real Time Treatment Aggregate with E-LSP

As mentioned above, this differs from uses within Verizon, the MIT QoS
Interprovider workshop and discussions in the MFA. The MPLS EXP bit values
of "101" are used in at least these contexts to indicate only
telephony/signaling for EF/CS5. This is the most significant difference
between the draft and other publications and industry work. Also we have
assigned the AF4x DSCP for multimedia conferencing as MPLS EXP "100," and
also treat broadcast video as another RFC 3270 FEC.

In order to resolve this comment, suggest that the draft define a minimum
subset of the "real-time" treatment aggregate and mention that some network
segments (see section 1) may define a larger set along the lines of what I
mention above.

Sections 5.3 (5.4) Assured Elastic (Elastic) Treatment Aggregate with E-LSP 

These MPLS EXP code points (without the loss probability bit encoding) are
what is used in several VPN and public IP networks. 

Section 5 - Additional comments

If the scope decision of this document is to expand to non-IP applications,
then additional text on handling Pseudowires with client services having
their own QoS definitions, VPLS and other potential uses of MPLS would need
to be added. My recommendation would be to keep this document focused on the
IP applications, and if anyone is interested then another document that
covered non-IP applications could be drafted.

6.  Treatment Aggregates and Inter-Provider Relationships

Suggest addition of a reference to the MIT QoS Interprovider white paper
mentioned above. After much discussion, the service providers involved in
this effort were only able to agree on a minimum set of two treatment
aggregates.

Also suggest addition of a reference to the Feb 2006 ITU-T Y.1541. Appendix
VI defines a minimum set of three QoS classes and a mapping to (sets of)
IETF DSCP values as follows:

Y.1221            Associated    Y.1541
Transfer          Diffserv      QoS
Capability        PHBs          Class(es)
------------      ----------    --------
Best Effort       Default       5

Delay-Sensitive   AF            2,3,4
Statistical BW

Dedicated         EF            0,1
Bandwidth  

(If you don't have ITU access, you can get up to three free ITU-T documents
per Email address by going to www.itu.int and going to the purchase page and
entering your email address.)

Many international providers look to the ITU-T for guidance, and that would
be the focus on many of our network provider interconnection uses of
treatment aggregates and MPLS EXP bit markings. Therefore, at least some
mention of a similar minimum subset of aggregations proposed by the ITU-T in
this document would be valuable. Finally, I note that if network control is
removed from the minimum subset in this draft, then the above set from ITU-T
Y.1541 Appendix VI is equivalent in terms of number of treatment aggregates
and a high-level mapping of service capabilities. 

Regards,

Dave

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, December 07, 2006 10:32 AM
> To: tsvwg
> Subject: [Tsvwg] Need for volunteers for reviewing 
> draft-ietf-tsvwg-diffserv-class-aggr
> 
> Hi,
> 
> To make progress we need some reviewers to read and comment on 
> "Aggregation of DiffServ Service Classes":
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class-ag
> gr-01.txt
> 
> We chairs don't think we can proceed with this draft until we seen 
> some confirming reviews from the WG participants. So please volunteer.
> 
> If you are willing to do this review please indicate so to us chairs.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> 
> 
>

---

From: "Nguyen, An P CIV NCS NC2" <[email-masked]>
Date: Thu, 11 Jan 2007 15:52:59 -0500

Classification:  UNCLASSIFIED 
Caveats: NONE

Dave,

Just a question for verification: Does dedicated bandwidth in the Y.1221
column below mean fixed connectivity?

Thanks,

An

----------------------------------------------- 

Suggest addition of a reference to the MIT QoS Interprovider white paper
mentioned above. After much discussion, the service providers involved
in this effort were only able to agree on a minimum set of two treatment
aggregates.

Also suggest addition of a reference to the Feb 2006 ITU-T Y.1541.
Appendix VI defines a minimum set of three QoS classes and a mapping to
(sets of) IETF DSCP values as follows:

Y.1221            Associated    Y.1541
Transfer          Diffserv      QoS

Delay-Sensitive   AF            2,3,4
Statistical BW

Dedicated         EF            0,1
Bandwidth  

Dave

> IETF Transport Area Director & TSVWG Chair

Classification:  UNCLASSIFIED 
Caveats: NONE

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 11 Jan 2007 16:44:02 -0500

Dave:
Thank you very much for the detail comments.
I will need some time to go through them carefully and address them 
appropriately.
Thanks!
-- Kwok --

---

From: Bruce Davie <[email-masked]>
Date: Thu, 11 Jan 2007 17:33:26 -0500

I too send comments that never made it to the archive.

Here they are again.

Bruce

	From: 	  [email-masked]
	Subject: 	Review of draft-ietf-tsvwg-diffserv-class-aggr
	Date: 	December 21, 2006 11:20:33 AM EST
	To: 	  [email-masked]
	Cc: 	  [email-masked]

As Magnus requested, I have reviewed draft-ietf-tsvwg-diffserv-class- 
aggr-01.txt

My line by line comments are below, prefaced by [BD]

My top level comments are as follows:

1. The main contribution of this draft can be summarized very  
briefly: you can aggregate different classes of traffic into bigger  
classes that get the same treatment as long as that treatment is good  
enough to meet the needs of the most stringent class.

2. A second contribution is to observe that if you do aggregate, it  
would be nice to preserve markings such that de-aggregation can be  
performed later.

3. Beyond that, the document makes a lot of specific recommendations  
about precisely how you should aggregate in both IP and MPLS  
networks. My concern with this aspect of the document is that there  
are essentially an infinite number of valid ways to aggregate  
traffic. For example, one of the most popular is to give all traffic  
in the core of an over-provisioned network the same treatment - so- 
called "best effort" treatment, but actually it is a treatment that  
is so good that even the most stringent class of traffic gets  
adequate service. This approach to aggregation goes unmentioned in  
the document, as does the fact that many other options are valid.

At a minimum, this document should be revised to make it clear that  
it is describing ONE possible approach out of many more that are  
possible. Since it is being progressed by the TSVWG, statements that  
begin "we recommend..." should probably be rewritten to be of the  
form "A possible option is..." A great deal of effort went into  
writing the DiffServ standards in such a way that operators and  
vendors would not be overly constrained. A set of recommendations  
from the TSVWG, even in an informational RFC, to the effect that  
there is only one valid way to run a Diffserv network, does not seem  
like something we want to produce.

Bruce
--------

TSVWG                                                            K. Chan
Internet-Draft                                                J. Babiarz
Intended status: Informational                           Nortel Networks
Expires: April 23, 2007                                         F. Baker
                                                            Cisco  
Systems
                                                         October 20,  
2006

                 Aggregation of DiffServ Service Classes
                 draft-ietf-tsvwg-diffserv-class-aggr-01

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

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

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

    This Internet-Draft will expire on April 23, 2007.

Copyright Notice

    Copyright (C) The Internet Society (2006).

Abstract

    In the core of a high capacity network, service differentiation is
    still needed to support applications' utilization of the network.
    Applications with similar traffic characteristics and performance
    requirements are mapped into diffserv service classes based on end-
    to-end behavior requirements of the applications as indicated by
    Diffserv Service Classes [5].  However, some network segments may be

Chan, et al.             Expires April 23, 2007                 [Page 1]
Internet-Draft                  Document                    October 2006

    configured in such a way that a single forwarding treatment may
    satisfy the traffic characteristics and performance requirements of
    two or more service classes.  In these cases, it may be desirable to
    aggregate two or more Diffserv Service Classes [5] into a single
    forwarding treatment.  This document provides guidelines for the
    aggregation of Diffserv Service Classes [5] into forwarding
    treatments.

Table of Contents

    1.   
Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
      1.1.  Requirements  
Notation  . . . . . . . . . . . . . . . . . .  4
    2.   
Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.  Overview of Service Class  
Aggregation  . . . . . . . . . . . .  5
    4.  Service Classes to Treatment Aggregate  
Mapping . . . . . . . .  6
      4.1.  Mapping Service Classes into Four Treatment  
Aggregates . .  6
        4.1.1.  Network Control Treatment  
Aggregate  . . . . . . . . .  8
        4.1.2.  Real Time Treatment  
Aggregate  . . . . . . . . . . . .  9
        4.1.3.  Assured Elastic Treatment  
Aggregate  . . . . . . . . .  9
        4.1.4.  Elastic Treatment  
Aggregate  . . . . . . . . . . . . . 10
    5.  Using MPLS for Treatment  
Aggregates  . . . . . . . . . . . . . 11
      5.1.  Network Control Treatment Aggregate with E- 
LSP . . . . . . 13
      5.2.  Real Time Treatment Aggregate with E- 
LSP . . . . . . . . . 13
      5.3.  Assured Elastic Treatment Aggregate with E- 
LSP . . . . . . 13
      5.4.  Elastic Treatment Aggregate with E- 
LSP . . . . . . . . . . 13
      5.5.  Treatment Aggregates and L- 
LSP . . . . . . . . . . . . . . 14
    6.  Treatment Aggregates and Inter-Provider  
Relationships  . . . . 14
    7.  Security  
Considerations  . . . . . . . . . . . . . . . . . . . 14
    8.  IANA  
Considerations  . . . . . . . . . . . . . . . . . . . . . 15
    9.   
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
    10.  
References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
      10.1. Normative  
References . . . . . . . . . . . . . . . . . . . 15
      10.2. Informative  
References . . . . . . . . . . . . . . . . . . 16
    Authors'  
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
    Intellectual Property and Copyright  
Statements . . . . . . . . . . 18

Chan, et al.             Expires April 23, 2007                 [Page 2]
Internet-Draft                  Document                    October 2006

1.  Introduction

    In the core of a high capacity network, it is common for the network
    to be engineered in such a way that a major link, switch, or router
    can fail and the result will be a routed network that still meets
    ambient SLAs.  The implication of this is that there is sufficient
    capacity on any given link such that all SLAs sold can be
    simultaneously supported at their respective maximum rates, and that
    this remains true after re-routing (either IP re-routing or MPLS
    protection-mode switching) has occurred.

    Over-provisioning is generally considered to meet the  
requirements of
    all traffic without further QoS treatment, and in the general case
    that is true in high capacity backbones.  However, as the process of
    network convergence continues, and with the increasing speed of the
    access networks, certain services still have issues.  Delay, jitter,
    and occasional loss are perfectly acceptable for elastic
    applications.  However, sub-second surges that occur in the best-
    designed of networks [14] affect real-time applications.  Moreover,
    DOS loads, worms, and network disruptions such as that of 11
    September 2001 affect routing [15].  Our objective is to prevent
    disruption to routing (which in turn affects all services), and
    jitter-sensitive services that may be revenue-bearing.

[BD] It took me a long time to understand the above sentence. It  
could be read to mean that an objective of the draft is to
prevent jitter sensitive services, which is probably not the intent.  
Also, I think the comment about preventing disruption to routing  
relates to the desire to protect network control traffic from loss,  
so perhaps you should say that (since there are lots of ways that  
routing may get disrupted that are outside the scope of this draft).

    The document "Diffserv Service Classes" [5] defines the basic
    diffserv classes from the points of view of the application  
requiring
    specific end-to-end behaviors from the network.  The service classes
    are differentiated based on the traffic-payload's tolerance to  
packet
    loss, delay, and delay variation (jitter).  Different degrees of
    these criterions form the foundation for supporting the needs of

[BD] criterions -> criteria, or even better "Different values of  
these metrics form..."

    real-time and elastic traffic.  The "Diffserv Service Classes" [5]
    document also provides recommendations for the treatment method of
    these service classes.  But, at some network segments of the end-to-
    end path, the number of levels of network treatment differentiation
    may be less than the number of service classes that the network
    segment needs to support.  In such a situation, that network segment
    may use the same treatment to support more than one service class.
    In this document we provide guidelines on how multiple service
    classes may be aggregated into a forwarding treatment aggregate.
    Note that in a given domain, we may recommend that the supported
    service classes be aggregated into forwarding treatment aggregates;
    however, this does not mean all service classes need to be supported
    and hence not all forwarding treatment aggregates need to be
    supported.  Which service classes and which forwarding treatment
    aggregates are supported by a domain is up to the domain
    administration and may be influenced by business reasons.

    In this document, we've provided:

Chan, et al.             Expires April 23, 2007                 [Page 3]
Internet-Draft                  Document                    October 2006

    o  definitions for terminology we use in this document,

    o  requirements for performing this aggregation,

    o  an example of performing this aggregation over MPLS using E-LSP.

    The treatment aggregate recommendations are designed to aggregate  
the
    service classes [5] in such a manner as to protect real-time traffic
    and routing, on the assumption that real-time sessions are protected
    from each other by admission at the edge.

    An example of aggregation over MPLS networks using E-LSP, EXP
    Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to
    realize the treatment aggregates is provided.  Note that the MPLS
    E-LSP is just an example; this document does not exclude the use of
    other methods.

1.1.  Requirements Notation

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

2.  Terminology

    This document assumes the reader is familiar with the terms used in
    differentiated services.  This document provides the definitions for
    new terms introduced by this document and referencing information  
for
    existing none differentiated services terms defined in existing  
RFCs.

    For new terms introduced by this document, we provide the definition
    here:

    o  Treatment Aggregate.  This term is used here to indicate the
       aggregate of DiffServ service classes.  This is different from
       Behavior Aggregate and Traffic Aggregate because Treatment
       Aggregate is only concerned with the treatment of the aggregated
       traffic.  It does not concern itself with how the aggregated
       traffic is marked, and hence does not put a restriction on the
       aggregated traffic having a single diffserv codepoint that have a
       single PHB.

    For terms from existing RFCs, we provide the reference to the
    appropriate section of the relevant RFC that contain the definition:

    o  Real-Time and Elastic Applications and their traffic.  Section  
3.1
       of RFC 1633 [6].

Chan, et al.             Expires April 23, 2007                 [Page 4]
Internet-Draft                  Document                    October 2006

    o  Diffserv Service Class.  Section 1.3 of
       draft-ietf-tsvwg-diffserv-service-classes-02.txt [5].

    o  MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label  
Switched
       Path (LSP).  Section 1.2 of RFC 3270 [8].

    o  MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label
       Switched Path (LSP).  Section 1.3 of RFC 3270 [8].

3.  Overview of Service Class Aggregation

    In diffserv domains where less granular traffic treatment
    differentiation is provided, aggregation of the different service
    classes [5] may be required.

    These aggregations have the following requirements:

[BD] I don't understand where these requirements come from.

    1.  The end-to-end network performance characteristic required by  
the
        application must be supported.  This performance characteristic
        is represented by the use of Diffserv Service Classes [5].

    2.  The treatment aggregate must exhibit the strictest  
requirement of
        its member service classes.

    3.  The treatment aggregate should only contain member service
        classes with similar traffic characteristic and performance
        requirements.

[BD] Why? Isn't it OK to aggregate wildly different service classes and
give them all treatment that is a good as the most stringent
requirements of any class?

    4.  The notion of the individual end-to-end service classes must not
        be destroyed when aggregation is performed.  Each domain along
        the end-to-end path may perform aggregation differently,  
based on
        the original end-to-end service classes.  We recommend an easy
        way to accomplish this by not altering the DSCP used to indicate
        the end-to-end service class.  But some administrative domains
        may require the use of their own marking; when this is needed,
        the original end-to-end service class indication must be  
restored
        upon exiting such administrative domains.

[BD] You seem to have strayed away from stating requirements when you
start recommending how to mark the DSCP. I *think* that what you are
trying to say is that the information about which service class
belongs to should not be lost during aggregation; such information
loss would occur, for example, if several different classes were
remarked to a common DSCP value.

    5.  Each treatment aggregate has limited resources, hence traffic
        conditioning and/or admission control must be performed for each
        service class aggregated into the treatment aggregate.

[BD] Where is this requirement from? Are you saying that it's not
possible to aggregate traffic with also performing admission control
or traffic conditioning? Many SPs would disagree.

    with the following suggestions:

    1.  The treatment aggregate and assigned resources may consider
        historical traffic patterns and the variability of these
        patterns.  For example, a point-point service (e.g., pseudowire)

Chan, et al.             Expires April 23, 2007                 [Page 5]
Internet-Draft                  Document                    October 2006

        may have a very predictable pattern, while a multipoint service
        (e.g., VPLS) may have a much less predictable pattern.  Even the
        traffic patterns within the Internet may vary widely.

    2.  In addition to Diffserv, other controls are available to
        influence the traffic level offered to a particular traffic
        aggregate.  These include adjustment of routing metrics,  
usage of
        MPLS-based traffic engineering techniques.

4.  Service Classes to Treatment Aggregate Mapping

    The service class and DSCP selection in "Diffserv Service Classes"
    [5] has been defined to allow, in many instances, mapping of two or
    possibly more service classes into a single forwarding treatment
    aggregate.  Notice that there is a relationship/trade-off between
    link speed, queue depth, delay, and jitter.

[BD] The preceding sentence should also mention link utilization.

The degree of
    aggregation and hence the number of treatment aggregates will depend
    on whether the speed of the links and scheduler behavior, being used
    to implement the aggregation, can minimize the affects of mixing
    traffic with different packet sizes and transmit rates on queue
    depth.  And their impacts on loss, delay, and jitter.  A general
    rule-of-thumb is that higher link speeds allow for more aggregation/
    smaller number of treatment aggregates.

[BD] That rule of thumb seems to be incorrect if a link is run at 100%
utilization. A more useful rule of thumb might take utilization into
accoutn.

4.1.  Mapping Service Classes into Four Treatment Aggregates

[BD] It is probably worth mentioning that this is just an example and
    that more or fewer treatment aggregates may be required.

    This section explains one way of performing this aggregation by  
using
    four treatment aggregates.  The use of four treatment aggregates
    assumes that the resources allocated to each treatment aggregate is
    sufficient to honor the required behavior of each service class [5]
    in each of the four treatment aggregates.  We use the performance
    requirement (tolerance to loss, delay, and jitter) from the
    application/end-user as a guide on how to map the service classes
    into treatment aggregates.  We have also used Section 3.1 of RFC  
1633
    [6] to provide us with guidance on the definition of Real-Time and
    Elastic applications.  An overview of the mapping between service
    classes and the four treatment aggregates is provided by Figure 1,
    with the mapping being based on performance requirements.  In Figure
    1, the right side columns of "Service Class", "Tolerance to Loss/
    Delay/Jitter" are from Figure 2 of Diffserv Service Classes [5].

    It is recommended that certain service classes be mapped into
    specific treatment aggregates.  But this does not mean that all the
    service classes recommended for that treatment aggregate need to be
    supported.  Hence, for a given domain, a treatment aggregate may
    contain only a subset of the service classes recommended in this
    document, they being the service classes supported by that  
domain.  A

Chan, et al.             Expires April 23, 2007                 [Page 6]
Internet-Draft                  Document                    October 2006

    domain's treatment of non-supported service classes should be based
    on the domain's local policy.  This local policy may be  
influenced by
    its agreement with its customers.  Such treatment may use the  
Elastic
    Treatment Aggregate, dropping the packets, or some other
    arrangements.

   ---------------------------------------------------------------------
|Treatment |    Tolerance to    ||Service Class  |    Tolerance to    |
|Aggregate | Loss |Delay |Jitter||               | Loss |Delay |Jitter|
|==========+======+======+======++===============+======+======+======|
| Network  | Low  | Low  | Yes  || Network       |  Low |  Low | Yes  |
| Control  |      |      |      || Control       |      |      |      |
|==========+======+======+======++===============+======+======+======|
| Real     | Very | Very | Very ||  Telephony    | VLow | VLow | VLow |
| Time     | Low  | Low  | Low  ||---------------+------+------+------|
|          |      |      |      ||   Signaling   | Low  | Low  | Yes  |
|          |      |      |      ||---------------+------+------+------|
|          |      |      |      ||  Multimedia   |Low - | Very | Low  |
|          |      |      |      || Conferencing  |Medium| Low  |      |
|          |      |      |      ||---------------+------+------+------|
|          |      |      |      ||   Real-time   | Low  | Very | Low  |
|          |      |      |      ||  Interactive  |      | Low  |      |
|          |      |      |      ||---------------+------+------+------|
|          |      |      |      ||   Broadcast   | Very |Medium| Low  |
|          |      |      |      ||     Video     | Low  |      |      |
|==========+======+======+======++===============+======+======+======|
| Assured  | Low  |Low - | Yes  ||  Multimedia   |Low - |Medium| Yes  |
| Elastic  |      |Medium|      ||   Streaming   |Medium|      |      |
|          |      |      |      ||---------------+------+------+------|
|          |      |      |      ||  Low Latency  | Low  |Low - | Yes  |
|          |      |      |      ||      Data     |      |Medium|      |
|          |      |      |      ||---------------+------+------+------|
|          |      |      |      ||      OAM      | Low  |Medium| Yes  |
|          |      |      |      ||---------------+------+------+------|
|          |      |      |      ||High Throughput| Low  |Medium| Yes  |
|          |      |      |      ||      Data     |      |- High|      |
|==========+======+======+======++===============+======+======+======|
| Elastic  |  Not Specified     ||   Standard    |  Not Specified     |
|          |      |      |      ||---------------+------+------+------|
|          |      |      |      || Low Priority  | High | High | Yes  |
|          |      |      |      ||      Data     |      |      |      |
   ---------------------------------------------------------------------

         Figure 1: Treatment Aggregate and Service Class Performance
                                Requirements

    As we are recommending to preserve the notion of the individual end-
    to-end service classes, we also recommend that the original DSCP

Chan, et al.             Expires April 23, 2007                 [Page 7]
Internet-Draft                  Document                    October 2006

    field marking not be changed when treatment aggregates are used.
    Instead, classifiers that select packets based on the contents of  
the
    DSCP field should be used to direct packets from the member DiffServ
    Service Classes into the queue that handles each of the treatment
    aggregates, without remarking the DSCP field of the packets.   
This is
    summarized in Figure 2, which shows the behavior each Treatment
    Aggregate should have, and the DSCP field marking of the packets  
that
    should be classified into each of the treatment aggregates.

     ------------------------------------------------------------
    |Treatment |Treatment || DSCP                                |
    |Aggregate |Aggregate ||                                     |
    |          |Behavior  ||                                     |
    |==========+==========++=====================================|
    | Network  | CS       || CS6                                 |
    | Control  |(RFC 2474)||                                     |
    |==========+==========++=====================================|
    | Real     | EF       || EF, CS5, AF41, AF42, AF43, CS4, CS3 |
    | Time     |(RFC 3246)||                                     |
    |==========+==========++=====================================|
    | Assured  | AF       || CS2, AF31, AF21, AF11               |
    | Elastic  |(RFC 2597)||-------------------------------------|
    |          |          || AF32, AF22, AF12                    |
    |          |          ||-------------------------------------|
    |          |          || AF33, AF23, AF13                    |
    |==========+==========++=====================================|
    | Elastic  | Default  || Default, (CS0)                      |
    |          |(RFC 2474)||-------------------------------------|
    |          |          || CS1                                 |
     ------------------------------------------------------------

                   Figure 2: Treatment Aggregate Behavior

4.1.1.  Network Control Treatment Aggregate

    The Network Control Treatment Aggregate aggregates all service
    classes that are functionally necessary for the survival of a  
network
    during a DOS attack or other high traffic load interval.  The theory
    is that whatever else is true, the network must protect itself.   
This
    includes the traffic that "Diffserv Service Classes" [5]
    characterizes as being included in the Network Control Service  
Class.

    The DSCPs of the original service class remain an important
    consideration and should be preserved during aggregation.   
Traffic in
    the Network Control treatment aggregate should be carried in a  
common
    queue or class with a PHB as described in RFC 2474 [4] section
    4.2.2.2.  This treatment aggregate should have a lower  
probability of
    packet loss, bearing a relatively deep target mean queue depth (min-

Chan, et al.             Expires April 23, 2007                 [Page 8]
Internet-Draft                  Document                    October 2006

    threshold if RED is being used).

4.1.2.  Real Time Treatment Aggregate

    The Real Time Treatment Aggregate aggregates all real-time
    (inelastic) service classes.  The theory is that real-time  
traffic is
    admitted under some model and controlled by a SLA managed at the  
edge
    of the network prior to aggregation.  As such, there is a  
predictable
    and enforceable upper bound on the traffic that can enter such a
    queue, and to provide predictable variation in delay it must be
    protected from bursts of elastic traffic.  The predictability of
    traffic level may be based upon admission control for a well known
    community of interest (e.g., a point-point service) and/or based  
upon
    historical measurements.

    This treatment aggregate may include the following service classes
    from the Diffserv Service Classes [5], in addition to other locally
    defined classes: Telephony, Signaling, Multimedia Conferencing,  
Real-
    time Interactive, Broadcast Video.

    Traffic in each service class that is going to be aggregated into  
the
    treatment aggregate should be conditioned prior to aggregation.  It
    is recommended that per service class admission control  
procedures be
    used followed by per service class policing so that any individual
    service class does not generate more than what it is allowed.
    Furthermore, additional admission control and policing may be  
used on
    the sum of all service classes aggregated.

    The DSCPs of the original service classes remain an important
    consideration and should be preserved during aggregation.  Traffic
    bearing these DSCPs is carried in a common queue or class with a PHB
    as described in RFC 3246 [11] and RFC 3247 [12].

4.1.3.  Assured Elastic Treatment Aggregate

    The Assured Elastic Treatment Aggregate aggregates all elastic
    traffic that uses the Assured Forwarding model as described in RFC
    2597 [10].  The premise of such a service is that a SLA is  
negotiated
    which includes a "committed rate" and the ability to exceed that  
rate
    (and perhaps a second "excess rate") in exchange for a higher
    probability of loss using AQM [9] or ECN flagging [13] for the
    portion of traffic deemed to be in excess.

    This treatment aggregate may include the following service classes
    from the Diffserv Service Classes [5], in addition to other locally
    defined classes: Multimedia Streaming, Low Latency Data, OAM, High
    Throughput Data.

Chan, et al.             Expires April 23, 2007                 [Page 9]
Internet-Draft                  Document                    October 2006

    The DSCP values belonging to the AF PHB group of the original  
service
    classes remain an important consideration and should be preserved
    during aggregation.  This treatment aggregate should maintain the AF
    PHB group marking of the original packet.  For example, AF3x marked
    packets should remain AF3x marked within this treatment aggregate.
    Traffic bearing these DSCPs is carried in a common queue or class
    with a PHB as described in RFC 2597 [10].  In effect, appropriate
    target rate thresholds have been applied at the edge, dividing
    traffic into AFn1 (committed, for any value of n), AFn2, and AFn3
    (excess).  The service should be engineered so that AFn1 marked
    packet flows have sufficient bandwidth in the network to provide  
high
    assurance of delivery.  Since the traffic is elastic and responds
    dynamically to packet loss, Active Queue Management [9] should be
    used primarily to reduce the forwarding rate to the minimum assured
    rate at congestion points.  The probability of loss of AFn1 traffic
    must not exceed the probability of loss of AFn2 traffic, which in
    turn must not exceed the probability of loss of AFn3 traffic.

    If RED [9] is used as an AQM algorithm, the min-threshold  
specifies a
    target queue depth for each of AFn1, AFn2, AFn3, and the max-
    threshold specifies the queue depth above which all traffic with  
such
    a DSCP is dropped or ECN marked.  Thus, in this Treatment Aggregate,
    the following inequalities should hold in queue configurations:

    o  min-threshold AFn3 < max-threshold AFn3

    o  max-threshold AFn3 <= min-threshold AFn2

    o  min-threshold AFn2 < max-threshold AFn2

    o  max-threshold AFn2 <= min-threshold AFn1

    o  min-threshold AFn1 < max-threshold AFn1

    o  max-threshold AFn1 <= memory assigned to the queue

    Note: This configuration tends to drop AFn3 traffic before AFn2 and
    AFn2 before AFn1.  Many other AQM algorithms exist and are used;  
they
    should be configured to achieve a similar result.

[BD] This particular set of configuration rules seems reasonable but
    many other reasonable possibilities also exist. The existence of
    other valid options should be made clear.

4.1.4.  Elastic Treatment Aggregate

    The Elastic Treatment Aggregate aggregates all remaining elastic
    traffic.  The premise of such a service is that there is no  
intrinsic
    SLA differentiation of traffic, but that AQM [9] or ECN flagging  
[13]
    is appropriate for such traffic.

    This treatment aggregate may include the following service classes

Chan, et al.             Expires April 23, 2007                [Page 10]
Internet-Draft                  Document                    October 2006

    from the Diffserv Service Classes [5], in addition to other locally
    defined classes: Standard, Low Priority Data.

    The DSCPs of the original service classes remain an important
    consideration and should be preserved during aggregation.  Traffic
    bearing these DSCPs is carried in a common queue or class with a PHB
    as described in RFC 2474 [4] section 4.1: A Default PHB.  The AQM
    thresholds for Elastic traffic MAY be separately set, so that Low
    Priority Data traffic is dropped before Standard traffic, but  
this is
    not a requirement.

5.  Using MPLS for Treatment Aggregates

    RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS Support of
    DiffServ [8] provide a very good background on this topic.  This
    document provides an example of using the E-LSP, EXP Inferred PHB
    Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS
    Support of DiffServ [8] for realizing the Treatment Aggregates.

    When Treatment Aggregates are represented in MPLS using EXP Inferred
    PSC LSP, we recommend the following usage of the MPLS EXP field for
    Treatment Aggregates.

[BD] I'm not sure the TSVWG wants to publish a document that
"recommends" a particular mapping of PHBs to MPLS EXP values. It seems
to be that, like many other parts of this document, it would be better
to say "here is one way of doing things; many other valid approaches
exist"

Chan, et al.             Expires April 23, 2007                [Page 11]
Internet-Draft                  Document                    October 2006

     -------------------------------------------
    |Treatment || MPLS ||  DSCP   |   DSCP      |
    |Aggregate || EXP  ||  name   |   value     |
    |==========++======++=========|=============|
    | Network  || 110  ||  CS6    |   110000    |
    | Control  ||      ||         |             |
    |==========++======++=========|=============|
    | Real     || 100  ||  EF     |   101110    |
    | Time     ||      ||---------|-------------|
    |          ||      ||  CS5    |   101000    |
    |          ||      ||---------|-------------|
    |          ||      ||AF41,AF42|100010,100100|
    |          ||      ||  AF43   |   100110    |
    |          ||      ||---------|-------------|
    |          ||      ||  CS4    |   100000    |
    |          ||      ||---------|-------------|
    |          ||      ||  CS3    |   011000    |
    |==========++======++=========|=============|
    | Assured  || 010* ||  CS2    |   010000    |
    | Elastic  ||      ||  AF31   |   011010    |
    |          ||      ||  AF21   |   010010    |
    |          ||      ||  AF11   |   001010    |
    |          ||------||---------|-------------|
    |          || 011* ||  AF32   |   011100    |
    |          ||      ||  AF22   |   010100    |
    |          ||      ||  AF12   |   001100    |
    |          ||      ||  AF33   |   011110    |
    |          ||      ||  AF23   |   010110    |
    |          ||      ||  AF13   |   001110    |
    |==========++======++=========|=============|
    | Elastic  || 000* || Default |   000000    |
    |          ||      || (CS0)   |             |
    |          ||------||---------|-------------|
    |          || 001* ||  CS1    |   001000    |
     -------------------------------------------

           Figure 3: Treatment Aggregate and MPLS EXP Field Usage

    Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, the
    usage of 010 or 011 (000 or 001) as EXP field value depends on the
    drop probability.  Packets in the LSP with EXP field of 011 (001)
    have a higher probability of being dropped than packets with an EXP
    field of 010 (000).

    The above table indicates the recommended usage of EXP fields for
    Treatment Aggregates.  Because many deployments of MPLS are on a per
    domain basis, each domain has total control of its EXP usage and  
each
    domain may use a different EXP field allocation for the domain's

Chan, et al.             Expires April 23, 2007                [Page 12]
Internet-Draft                  Document                    October 2006

    supported Treatment Aggregates.

    The usage of E-LSP for Network Control Treatment Aggregate needs to
    adhere to the recommendations indicated in section 4.1.1 of this
    document and section 3.2 of "Diffserv Service Classes" [5].
    Reinforcing these recommendations, there should be no drop  
precedence
    associated with the MPLS PSC used for Network Control Treatment
    Aggregate because dropping of Network Control Treatment Aggregate
    traffic should be prevented.

    In addition to the recommendations provided in section 4.1.2 of this
    document and in member service classes' sections of "Diffserv  
Service
    Classes" [5], we want to indicate that Real Time Treatment Aggregate
    traffic should not be dropped, as some of the applications whose
    traffic is carried in the Real Time Treatment Aggregate do not react
    well to dropped packets.  As indicated in section 4.1.2 of this
    document, admission control should be performed on each Service  
Class
    contributing to the Real Time Treatment Aggregate to prevent packet
    loss due to insufficient resources allocated to Real Time Treatment
    Aggregate.  Further, admission control and policing may also be
    applied on the sum of all traffic aggregated into this treatment
    aggregate.

5.3.  Assured Elastic Treatment Aggregate with E-LSP

    EXP field markings of 010 and 011 are used for the Assured Elastic
    Treatment Aggregate.  The two encodings are used to provide two
    levels of drop precedence indications, with 010 encoded traffic
    having a lower probability of being dropped than 011 encoded  
traffic.
    This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP
    010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011.

5.4.  Elastic Treatment Aggregate with E-LSP

    EXP field markings of 000 and 001 are used for the Elastic Treatment
    Aggregate.  The two encodings are used to provide two levels of drop
    precedence indications, with 000 encoded traffic having a lower
    probability of being dropped than 001 encoded traffic.  This  
provides
    for the mapping of Default/CS0 into 000; and CS1 into 001.  Notice
    that with this mapping, during congestion, CS1 marked traffic may be
    starved.

Chan, et al.             Expires April 23, 2007                [Page 13]
Internet-Draft                  Document                    October 2006

5.5.  Treatment Aggregates and L-LSP

    Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC  
per
    LSP, the support of each Treatment Aggregate is on a per LSP basis.
    This document does not further specify any additional recommendation
    (beyond what has been indicated in section 4 of this document) for
    Treatment Aggregate to L-LSP mapping, leaving this to each  
individual
    MPLS domain administrations.

    When Treatment Aggregates are used at provider boundaries, we
    recommend that the Inter-Provider Relationship be based on Diffserv
    Service Classes [5].  This allows the admission control into each
    Treatment Aggregate of a provider domain to be based on the  
admission
    control of traffic into the supported Service Classes, as indicated
    by the discussion in section 4 of this document.

    If the Inter-Provider Relationship needs to be based on Treatment
    Aggregates specified by this document, then the exact Treatment
    Aggregate content and representation must be agreed to by the  
peering
    providers.

7.  Security Considerations

    This document discusses the policy of using Differentiated Services
    and its service classes.  If implemented as described, it should
    require that the network do nothing that the network has not already
    allowed.  If that is the case, no new security issues should arise
    from the use of such a policy.

    It is possible for the policy to be applied incorrectly, or for a
    wrong policy to be applied in the network for the defined
    aggregation.  In that case, a policy issue exists that the network
    must detect, assess, and deal with.  This is a known security issue
    in any network dependent on policy-directed behavior.

    A well known flaw appears when bandwidth is reserved or enabled  
for a
    service (for example, voice transport) and another service or an
    attacking traffic stream uses it.  This possibility is inherent in
    DiffServ technology, which depends on appropriate packet markings.
    When bandwidth reservation or a priority queuing system is used in a
    vulnerable network, the use of authentication and flow admission is
    recommended.  To the best of the authors' knowledge, there is no
    known technical way to respond to or act upon a data stream that has
    been admitted for service but that it is not intended for

Chan, et al.             Expires April 23, 2007                [Page 14]
Internet-Draft                  Document                    October 2006

    authenticated use.

8.  IANA Considerations

    This document does not request any IANA considerations.

9.  Acknowledgements

    This document has benefited from discussions with numerous people,
    especially Shane Amante, Brian Carpenter, and Dave McDysan.  It has
    also benefited from detailed reviews by David Black and Marvin Krym.

10.  References

10.1.  Normative References

    [1]   Postel, J., "Internet Protocol", STD 5, RFC 791,
          September 1981.

    [2]   Bradner, S., "The Internet Standards Process -- Revision 3",
          BCP 9, RFC 2026, October 1996.

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

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

    [5]   Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines
          for DiffServ Service Classes", RFC 4594, August 2006.

    [6]   Braden, B., Clark, D., and S. Shenker, "Integrated Services in
          the Internet Architecture: an Overview", RFC 1633, June 1994.

    [7]   Black, D., "Differentiated Services and Tunnels", RFC 2983,
          October 2000.

    [8]   Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
          Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol
          Label Switching (MPLS) Support of Differentiated Services",
          RFC 3270, May 2002.

    [9]   Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
          Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,

Chan, et al.             Expires April 23, 2007                [Page 15]
Internet-Draft                  Document                    October 2006

          C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,
          J., and L. Zhang, "Recommendations on Queue Management and
          Congestion Avoidance in the Internet", RFC 2309, April 1998.

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

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

    [12]  Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
          Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
          Ramakrishnan, "Supplemental Information for the New Definition
          of the EF PHB (Expedited Forwarding Per-Hop Behavior)",
          RFC 3247, March 2002.

    [13]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
          Explicit Congestion Notification (ECN) to IP", RFC 3168,
          September 2001.

10.2.  Informative References

    [14]  Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot,
          "Analysis of Point-To-Point Packet Delay in an Operational
          Network", INFOCOMM 2004, March 2004,
          <http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.

    [15]  Ogielski, A. and J. Cowie, "Internet Routing Behavior on  
9/11",
          March 2002, <http://www.renesys.com/tech/presentations/pdf/
          renesys-030502-NRC-911.pdf>.

Authors' Addresses

    Kwok Ho Chan
    Nortel Networks
    600 Technology Park Drive
    Billerica, MA  01821
    US

    Phone: +1-978-288-8175
    Fax:   +1-978-288-8700
    Email: [email-masked]

Chan, et al.             Expires April 23, 2007                [Page 16]
Internet-Draft                  Document                    October 2006

    Jozef Z. Babiarz
    Nortel Networks
    3500 Carling Avenue
    Ottawa, Ont.  K2H 8E9
    Canada

    Phone: +1-613-763-6098
    Fax:   +1-613-768-2231
    Email: [email-masked]

    Fred Baker
    Cisco Systems
    1121 Via Del Rey
    Santa Barbara, CA  93117
    US

    Phone: +1-408-526-4257
    Fax:   +1-413-473-2403
    Email: [email-masked]

Chan, et al.             Expires April 23, 2007                [Page 17]
Internet-Draft                  Document                    October 2006

Full Copyright Statement

    Copyright (C) The Internet Society (2006).

    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights.

    This document and the information contained herein are provided  
on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE  
REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be  
claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.   
Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the  
use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR  
repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    [email-masked].

Acknowledgment

    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).

Chan, et al.             Expires April 23, 2007                [Page 18]

---

From: "Dickinson, Fil" <[email-masked]>
Date: Fri, 12 Jan 2007 10:31:11 +1100

Hi Bruce.
I may be misinterpeting your last point but I do not agree with it.
I think we do need a "recommendation" on an approach to diffserv class
aggregation. I agree that it should not be "to the effect that there is
only one valid way to run a Diffserv network", but see a need for a
defined recommended approach. 
I think this is necessary so that service providers can refer to a
documented approach by a recognised standards body when designing their
own networks, agreeing interprovider implementations with peers and
dealing with inter-vendor interpretations of diffserv class aggregation.

-----Original Message-----
From: Bruce Davie [mailto:[email-masked]] 
Sent: Friday, 12 January 2007 9:33 AM
To: tsvwg
Cc: Magnus Westerlund
Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr

Here they are again.

Bruce

	From: 	  [email-masked]

3. Beyond that, the document makes a lot of specific recommendations
about precisely how you should aggregate in both IP and MPLS networks.
My concern with this aspect of the document is that there are
essentially an infinite number of valid ways to aggregate traffic. For
example, one of the most popular is to give all traffic in the core of
an over-provisioned network the same treatment - so- called "best
effort" treatment, but actually it is a treatment that is so good that
even the most stringent class of traffic gets adequate service. This
approach to aggregation goes unmentioned in the document, as does the
fact that many other options are valid.

At a minimum, this document should be revised to make it clear that it
is describing ONE possible approach out of many more that are possible.
Since it is being progressed by the TSVWG, statements that begin "we
recommend..." should probably be rewritten to be of the form "A possible
option is..." A great deal of effort went into writing the DiffServ
standards in such a way that operators and vendors would not be overly
constrained. A set of recommendations from the TSVWG, even in an
informational RFC, to the effect that there is only one valid way to run
a Diffserv network, does not seem like something we want to produce.

Bruce
--------

TSVWG                                                            K. Chan

Status of this Memo

Copyright Notice

Abstract

Table of Contents

    1.   
Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
      1.1.  Requirements
Notation  . . . . . . . . . . . . . . . . . .  4
    2.   
Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.  Overview of Service Class
Aggregation  . . . . . . . . . . . .  5
    4.  Service Classes to Treatment Aggregate Mapping . . . . . . . .
6
      4.1.  Mapping Service Classes into Four Treatment Aggregates . .
6
        4.1.1.  Network Control Treatment Aggregate  . . . . . . . . .
8
        4.1.2.  Real Time Treatment
Aggregate  . . . . . . . . . . . .  9
        4.1.3.  Assured Elastic Treatment Aggregate  . . . . . . . . .
9
        4.1.4.  Elastic Treatment
Aggregate  . . . . . . . . . . . . . 10
    5.  Using MPLS for Treatment
Aggregates  . . . . . . . . . . . . . 11
      5.1.  Network Control Treatment Aggregate with E- LSP . . . . . .
13
      5.2.  Real Time Treatment Aggregate with E- LSP . . . . . . . . .
13
      5.3.  Assured Elastic Treatment Aggregate with E- LSP . . . . . .
13
      5.4.  Elastic Treatment Aggregate with E- LSP . . . . . . . . . .
13
      5.5.  Treatment Aggregates and L- LSP . . . . . . . . . . . . . .
14
    6.  Treatment Aggregates and Inter-Provider Relationships  . . . .
14
    7.  Security
Considerations  . . . . . . . . . . . . . . . . . . . 14
    8.  IANA
Considerations  . . . . . . . . . . . . . . . . . . . . . 15
    9.   
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
    10.  
References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
      10.1. Normative
References . . . . . . . . . . . . . . . . . . . 15
      10.2. Informative
References . . . . . . . . . . . . . . . . . . 16
    Authors'  
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
    Intellectual Property and Copyright Statements . . . . . . . . . .
18

1.  Introduction

    Over-provisioning is generally considered to meet the requirements
of

[BD] It took me a long time to understand the above sentence. It could
be read to mean that an objective of the draft is to prevent jitter
sensitive services, which is probably not the intent.  
Also, I think the comment about preventing disruption to routing relates
to the desire to protect network control traffic from loss, so perhaps
you should say that (since there are lots of ways that routing may get
disrupted that are outside the scope of this draft).

[BD] criterions -> criteria, or even better "Different values of these
metrics form..."

2.  Terminology

    2.  The treatment aggregate must exhibit the strictest requirement
of
        its member service classes.

        the end-to-end path may perform aggregation differently, based
on

[BD] You seem to have strayed away from stating requirements when you
start recommending how to mark the DSCP. I *think* that what you are
trying to say is that the information about which service class belongs
to should not be lost during aggregation; such information loss would
occur, for example, if several different classes were remarked to a
common DSCP value.

[BD] Where is this requirement from? Are you saying that it's not
possible to aggregate traffic with also performing admission control or
traffic conditioning? Many SPs would disagree.

    2.  In addition to Diffserv, other controls are available to
        influence the traffic level offered to a particular traffic
        aggregate.  These include adjustment of routing metrics, usage
of
        MPLS-based traffic engineering techniques.

The degree of

    document, they being the service classes supported by that domain.
A

    domain's treatment of non-supported service classes should be based
    on the domain's local policy.  This local policy may be influenced
by
    its agreement with its customers.  Such treatment may use the
Elastic
    Treatment Aggregate, dropping the packets, or some other
    arrangements.

    4.2.2.2.  This treatment aggregate should have a lower probability
of

    (inelastic) service classes.  The theory is that real-time traffic
is

    Traffic in each service class that is going to be aggregated into
the
    treatment aggregate should be conditioned prior to aggregation.  It
    is recommended that per service class admission control procedures
be
    used followed by per service class policing so that any individual
    service class does not generate more than what it is allowed.
    Furthermore, additional admission control and policing may be used
on
    the sum of all service classes aggregated.

    If RED [9] is used as an AQM algorithm, the min-threshold specifies
a

    Priority Data traffic is dropped before Standard traffic, but this
is
    not a requirement.

    A well known flaw appears when bandwidth is reserved or enabled for
a

    authenticated use.

8.  IANA Considerations

9.  Acknowledgements

10.  References

Authors' Addresses

    Kwok Ho Chan
    Nortel Networks

    Phone: +1-978-288-8175
    Fax:   +1-978-288-8700
    Email: [email-masked]

    Jozef Z. Babiarz
    Nortel Networks
    3500 Carling Avenue
    Ottawa, Ont.  K2H 8E9
    Canada

    Phone: +1-613-763-6098
    Fax:   +1-613-768-2231

    Fred Baker
    Cisco Systems
    1121 Via Del Rey
    Santa Barbara, CA  93117
    US

    Phone: +1-408-526-4257
    Fax:   +1-413-473-2403
    Email: [email-masked]

Full Copyright Statement

    This document and the information contained herein are provided on
an

Intellectual Property

    Intellectual Property Rights or other rights that might be claimed
to

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use
of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository
at
    http://www.ietf.org/ipr.

Acknowledgment

---

From: Fred Baker <[email-masked]>
Date: Fri, 12 Jan 2007 04:54:36 +0100

I'll ask you the same question I just asked Dave. Given that we  
update to reflect Bruce's comments, do you think this draft is going  
in a direction that is beneficial to Telstra? It sounds like "yes",  
but I'd like to hear the statement made.

On Jan 12, 2007, at 12:31 AM, Dickinson, Fil wrote:

> TSVWG                                                            K.  
> Chan
> Internet-Draft                                                J.  
> Babiarz
> LSP . . . . . .
> LSP . . . . . . . . .
> LSP . . . . . .
> relates
> belongs
> |          |      |      |      ||      Data     |      |       
> |      |
> specifies

---

From: "Dickinson, Fil" <[email-masked]>
Date: Fri, 12 Jan 2007 15:41:58 +1100

Hi Fred,
Although I work at Telstra, I do not represent Telstra. My opinion is
that of an engineer in the ISP community.

Yes, I am very supportive of the direction this draft is heading. I
think that it will provide much needed guidance, clarity and a
recognised standards reference from which to operate, whilst still
allowing the flexibility of each domain to implement what is applicable
to its business.

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Friday, 12 January 2007 2:55 PM
To: Dickinson, Fil
Cc: Bruce Davie; tsvwg; Magnus Westerlund
Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr

On Jan 12, 2007, at 12:31 AM, Dickinson, Fil wrote:

> Medium|      |

---

From: Fred Baker <[email-masked]>
Date: Fri, 12 Jan 2007 00:05:51 -0500

That is pretty much the position we all are in - none of us speak for  
our companies in a corporate sense, but we know what our companies  
need. I'm here to meet the needs, as no doubt you are as well.

Thanks.

On Jan 11, 2007, at 11:41 PM, Dickinson, Fil wrote:

>> networks.
>> Mapping . . . . . . . .
>> Aggregates . .
>> Relationships  . . . .
>> requirements
>> could
>> these
>> requirement
>> based
>> usage
>> domain.
>> influenced
>> probability
>> traffic
>> procedures
>> used
>> Traffic
>> Traffic
>> this
>> claimed
>> use
>> repository

---

From: Dave McDysan <[email-masked]>
Date: Fri, 12 Jan 2007 08:41:38 -0500

An,

Here is the description from Y.1221

6.1.1 Description
The Dedicated Bandwidth (DBW) transfer capability is intended to support
applications with
stringent delay requirements. It aims to support the guaranteed and timely
delivery of IP packets
along the end-to-end path of the network.
The DBW transfer capability strives for compatibility with the Guaranteed
Service [RFC 2212] and
the end-to-end services based on the Expedited Forwarding per-hop behaviour
[RFC 2598].

BTW, according to an IUT-T attendee in my company "Free public online access
to in-force ITU-T Recommendations is being provided by the ITU on a trial
basis from January 2007 until September 2007 to promote dissemination and
usage of ITU-T Recommendations.  PDF versions of ITU-T Recommendations are
available via the ITU web site
(http://www.itu.int/ITU-T/publications/recs.html). "

More details are in the recommendation, and it is now free for the next 8
months.

Dave

> From: Nguyen, An P CIV NCS NC2 [mailto:[email-masked]] 
> Sent: Thursday, January 11, 2007 3:53 PM
> To: Dave McDysan
> Cc: tsvwg; Nguyen, An P CIV NCS NC2
> Subject: RE: [Tsvwg] FW: Review of 
> draft-ietf-tsvwg-diffserv-class-aggr (UNCLASSIFIED)
> 
> Just a question for verification: Does dedicated bandwidth in 
> the Y.1221 column below mean fixed connectivity?
> 
> Thanks,
> 
> An
> 
> Suggest addition of a reference to the MIT QoS Interprovider 
> white paper mentioned above. After much discussion, the 
> service providers involved in this effort were only able to 
> agree on a minimum set of two treatment aggregates.
> 
> Appendix VI defines a minimum set of three QoS classes and a 
> mapping to (sets of) IETF DSCP values as follows:
> 
> Y.1221            Associated    Y.1541
> Transfer          Diffserv      QoS