[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
PCN                                                              K. Chan
Internet-Draft                                           Nortel Networks
Intended status: Informational                                 A. Charny
Expires: April 25, 2007                                    Cisco Systems
                                                              P. Eardley
                                                             BT Research
                                                        October 22, 2006


             Pre-Congestion Notification Problem Statement
                  draft-chan-pcn-problem-statement-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 25, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   DiffServ mechanisms have been developed to support Quality of Service
   (QoS).  However, the level of assurance that can be provided with
   DiffServ without substantial over-provisioning is limited.  Pre-
   Congestion Notification (PCN) investigates the use of per-flow
   admission control to provide the required service guarantees for the



Chan, et al.             Expires April 25, 2007                 [Page 1]


Internet-Draft                  Document                    October 2006


   admitted traffic.  While admission control will protect the QoS under
   normal operating conditions, an additional flow pre-emption mechanism
   is necessary in the times of heavy congestion (e.g. caused by route
   changes due to link or node failure).

   This document provides a problem statement on the addition of flow
   admission control and flow pre-emption functionality to a DiffServ
   network, in particular for the support of real time services such as
   voice and video.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Architecture and Deployment Scenarios  . . . . . . . . . . . .  5
     2.1.  Functional Architecture  . . . . . . . . . . . . . . . . .  6
     2.2.  Notion of Trust  . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Deployment Scenarios . . . . . . . . . . . . . . . . . . .  7
   3.  Standards  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Assumptions and Constraints on Problem Scope . . . . . . . . .  9
     4.1.  Assumption 1: Controlled Environment . . . . . . . . . . .  9
     4.2.  Assumption 2: Many Flows and Additional Load . . . . . . . 10
     4.3.  Assumption 3: Real-Time Applications . . . . . . . . . . . 10
   5.  Open Design Issues . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Implications  . . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 17



















Chan, et al.             Expires April 25, 2007                 [Page 2]


Internet-Draft                  Document                    October 2006


1.  Introduction

1.1.  Motivation

   IP networks were initially designed to perform per IP packet
   forwarding treatment without discrimination.  With the increased use
   of the IP network by applications with different transport functional
   requirement, the notion of Quality of Service (QoS) was introduced
   [19].

   DiffServ [10] introduced differentiated per packet forwarding
   treatment to provide QoS: some packets are served at a higher
   scheduling priority than others.  Diffserv Service Classes [18]
   categorises various DiffServ traffic and recommends how they can be
   used for packets from applications with different transport
   requirements.  For instance there are Telephony and Real-time
   Interactive service classes.  Applications like these need low loss,
   low delay and low jitter.  A suitable Per Hop Behavior (PHB) is
   Expedited Forwarding (EF) [16], which works by assuring that packets
   (usually) encounter very short or empty queues.  Each router is
   allocated a certain amount of bandwidth for the EF PHB, for instance.
   Excess packets are dropped and delayed, thus leading to poorer QoS
   for an end user running an application like voice-over-IP.  Even if
   average traffic levels are known, due to traffic variations the level
   of assurance that can be provided with DiffServ without substantial
   over-provisioning is limited.

   To help ensure that the average traffic loads remain within the
   allocated bandwidth limits, the DiffServ Architecture [10] introduces
   the idea of policing the amount of traffic in a class as it enters
   the network.  The acceptable traffic level is described by a traffic
   conditioning agreement (TCA).  However, in practice, TCAs police the
   aggregate traffic in a class at the network ingress, and for
   scalability reasons typically includes traffic to different
   destinations.  As a result, TCA's do not guarantee that EF aggregate
   at any given node in the network does not exceed the allocated
   capacity [21], and so don't ensure that a particular end user's QoS
   is guaranteed.  Also, in practice TCAs are static and so require
   accurate and/or conservative prediction of the traffic matrix.

   To cope with the issue of exceeding bandwidth allocation to EF on
   some links, in practice a policer or shaper is assumed to be
   installed at the interior nodes as well.  However, shaping or
   policing traffic causes excess packets be dropped and delayed, thus
   leading to poorer QoS for an end user running an application like
   voice-over-IP.  Even if average traffic levels remain within the
   allocated bandwidth limits, traffic variations may limit the level of
   assurance that can be provided with DiffServ without substantial



Chan, et al.             Expires April 25, 2007                 [Page 3]


Internet-Draft                  Document                    October 2006


   over-provisioning.

   These factors motivate us to work on per flow admission control for a
   DiffServ network, and in particular on measurement-based admission
   control, ie new flow requests are blocked dynamically in response to
   actual (incipient) congestion on a router within the DiffServ
   network.

   However, despite flow admission control, sometimes there can be heavy
   congestion - for example caused by link or node failure that
   effectively reduces the network's capacity.  The default option is
   that the QoS of all flows is degraded.  However, by pre-empting some
   flows the QoS of the remaining flows can be protected.  The work
   reported in [7] indicates that in the context where calls have
   different recongizable precedence levels (e.g. in the context of
   military/emergency calls [20]), this problem can be partially
   addressed by dropping lower-precedence calls preferentially while
   protecting higher precedence calls.  However, as it was shown in [6],
   the need to pre-empt some flows of a given precedence level, while
   protecting the QoS of the rest of the flows of this precedence level
   remains.

   This motivates us to work on per flow pre-emption for a DiffServ
   network, and in particular on measurement-based pre-emption, ie
   existing flows are dropped dynamically in response to actual
   congestion on a router within the DiffServ network.

   Explicit Congestion Notification (ECN) [15] introduced the idea of a
   router indicating that it is congested by changing the header of
   packets ("marking" them).  However, ECN in RFC3168 [15] is designed
   for TCP applications.  This motivates us to develop the concept for
   real-time applications.  A router "PCN-marks" packets as an early
   warning of its incipient congestion ("pre-congestion").  These
   markings are then used by the admission control and pre-emption
   mechanisms.

   The rest of this document discusses our proposed goals, assumptions
   and some functional architecture directions.

1.2.  Goals

   From the functional standpoint, the goal of the proposed PCN approach
   is twofold:

   o  Flow Admission Control: block admission of new flows as soon as
      signs of incipient congestion are detected, to prevent congestion
      / overload.




Chan, et al.             Expires April 25, 2007                 [Page 4]


Internet-Draft                  Document                    October 2006


   o  Flow Pre-emption: If traffic exceeds the desired/allocated
      capacity (e.g. due to a failure), pre-empt sufficient flows so
      that the QoS of the remaining flows is protected.

   The following are proposed as design goals:

   o  The PCN-enabled packet forwarding network should be simple,
      scalable and robust

   o  Compatibility with other traffic (i.e. a proposed solution should
      work well when non-PCN traffic is also present in the network)

   o  Support of different types of real-time traffic (eg should work
      well with CBR and VBR voice and video sources)

   o  Reaction time of the mechanisms should be commensurate with the
      desired application-level requirements (e.g. a pre-emption
      mechanism needs to pre-empt flows before significant QoS issues
      are experienced by all real-time traffic, and before a user hangs
      up)

   o  Compatibility with different precedence levels of real-time
      applications (e.g. preferential treatment of higher precedence
      calls over lower precedence calls, MLPP [20].


2.  Architecture and Deployment Scenarios

   The above goals point to a high-level approach where functionality is
   split between:

   o  Nodes in the PCN-enabled network, which monitor their own state of
      (pre) congestion and mark packets if appropriate

   o  Nodes at the edge of the PCN-enabled network, which control
      admission of new flows and pre-emption of existing flows, based on
      information from nodes in the network.  This information is in the
      form of the marked packets and not explicit signalling messages.

   The aim of this split is to keep the bulk of the network simple,
   scalable and robust, whilst confining policy, application-level and
   security interactions to the edge of the PCN network.

   Section 2.1 provides a high-level description of the functional
   architecture, and Section 2.2 considers some possible deployment
   scenarios.





Chan, et al.             Expires April 25, 2007                 [Page 5]


Internet-Draft                  Document                    October 2006


2.1.  Functional Architecture

   Figure 1 shows a schematic diagram of the high-level functional
   architecture:

                         +------------------------------------+
                         |            PCN-Region              |
                         +------+       +------+       +------+
                         |      |       |      |       |      |
                         |PEN A | ----> |PIN A | ----> |PEN B |
                         |      |       |      |       |      |
                         +------+       +------+       +------+
                         |                                    |
                         +------------------------------------+


                Figure 1: PCN-based Functional Architecture

   The terms are defined as follows:

   PCN-Region:

         A DiffServ region of the Internet running PCN, that is the PCN-
         based mechanisms are used to decide whether to admit a new flow
         to the DiffServ region and whether to pre-empt an existing
         flow.  All traffic enters/leaves the PCN-Region through a PCN
         End Node.  Please note that the PCN-Region is also defined by
         the Diffserv Service Class [18] that is subject to the PCN
         mechanisms.

   PCN Interior Node (PIN) (function):

         The PCN Interior Node is an "on-path" function.  It performs
         traffic metering and PCN-marking: the function that enables a
         network element to give an early warning of its own incipient
         congestion ("pre-congestion") on one of its interfaces, ie
         traffic is above a certain level, by marking, e.g. changing the
         header of packet(s).

   PCN End Node (PEN) (function):

         The PCN End Node is an "on-path" function.  The PCN End Node is
         where the PCN Region ends.  It indicates the significance of
         the PCN packet marking which terminates at this functional
         node.  This functional description does not imply which
         physical device will implement this function (e.g., edge
         router, media gateway or end-host).  This "on-path" function
         performs the detection of PCN-marks: the function that monitors



Chan, et al.             Expires April 25, 2007                 [Page 6]


Internet-Draft                  Document                    October 2006


         PCN-marking to obtain on-path congestion information as
         signaled through PCN-marking by PCN-enabled Interior Nodes.
         For PCN's purpose, these actions may include but not be limited
         to:

         +  Make Flow Admission Control and/or Flow Pre-emption
            decisions.

         +  Signalling the PCN information to others for making the Flow
            Admission Control and/or Flow Pre-emption decisions.

         +  Perform measurement of marked packets across multiple IP
            packets of a flow to derive network information for a flow
            that a single packet can not provide.

         +  Perform measurement of marked packets across multiple IP
            flows to derive additional network information.

2.2.  Notion of Trust

   With the above Functional Architecture, there exists a notion of
   trust between the different functional elements:

   o  PENs trusting PINs to provide the correct network information.

   o  PINs trusting PENs that admission control and pre-emption will be
      administered correctly so the PINs will not be over-whelmed with
      traffic.

   o  Users/Applications trusting the PENs that they will provide
      dependable informations for taking application actions.

   o  PENs trusting other PENs that when one PEN performs its task of
      flow admission control, other PENs will also perform their flow
      admission control actions.  So that the "good citizens" does not
      get penelized.

   We discuss some notion of trust further in section 4.1 Assumption 1:
   Controlled Environment and in section 6 Security Implications.

2.3.  Deployment Scenarios

   The previous section describes the functional architecture.  The
   association of these functions to physical devices may depend on the
   deployment scenario.  We make some general comments about the
   physical devices where the functions above will typically reside:





Chan, et al.             Expires April 25, 2007                 [Page 7]


Internet-Draft                  Document                    October 2006


   o  The PCN Interior Node function typically resides in a network
      element like a router or a switch where packet forwarding is
      handled.

   o  The PCN End Node function typically resides in a router, but may
      also be on a host or a proxy.  It is typically the closest PCN-
      enabled device to the user.

   Operators of networks will want to use the PCN functions (and
   standards) in various arrangements, for instance depending on how
   they are performing admission control outside the PCN-region, their
   goals beyond those in Section 1.2, and assumptions in addition to
   those in Section 4.

   Hence we shall work on several deployment scenarios.  Initially we
   have the following possibilities in mind:

   o  IntServ over DiffServ [14], the DiffServ region is PCN-enabled.
      This is described in CL Architecture [2].

   o  SIP-controlled Admission and Pre-emption: trusted SIP endpoints
      (gateway or host) perform application flow admission and flow pre-
      emption, based on network information provided by PCN marking.
      This is described in SIP Controlled Admission and Preemption [4].

   o  Pseudowire: PCN may be used as a congestion avoidance mechanism
      for end-user deployed pseudowires (collaborate with the PWE3 WG in
      investigation of this possibility).


3.  Standards

   To solve the PCN functionality described above, we will work on
   developing a standard for each of the following problems:

   o  How should the measurement of pre-congestion be done at the PINs?
      For determining when an interior node should mark a packet in
      order to give early warning of its own congestion?  Should there
      be a standardized algorithm?  Or just the required behavior should
      be standardized?

   o  How should such a mark be encoded by the PINs in a packet (in the
      ECN and/or DSCP fields)?

   o  How should these markings (at packet granularity) be interpreted
      by the PENs for making flow admission control and flow pre-emption
      decisions (at flow granularity)?




Chan, et al.             Expires April 25, 2007                 [Page 8]


Internet-Draft                  Document                    October 2006


   Initial work addressing these questions has been reported to the IETF
   in CL Architecture [2], RT ECN [1], NSIS RMD [5].  Note that other
   options are possible.

   One of the key questions that need to be answered in the context of
   standardisation is, what level of detail of standardisation is
   appropriate for the first bullet?  For example, should PCN be
   specified as an algorithm relating the probability of PCN-marking a
   packet to (some specific description of the) traffic level?  Or
   something more detailed (e.g. implementation specifics) or less
   detailed (describe the behaviour in more general terms than an
   algorithm).  We want flexibility, but also want to be sure that
   different standards-compliant implementations will work together.

   A similar issue arises for the third bullet.  Additionally, it might
   be possible to specify more than one way of reacting to the PCN-
   markings.  On the plus side, different reaction behaviours may be
   more suited to different deployment scenarios.  But this could
   require coordination of the PCN End Nodes for a particular PCN-
   region, so they agreed to use the same reaction behaviour.

   On the second bullet, CL PHB [3] has some options for how to do the
   encoding, focussed on use of the ECN field, and an initial analysis
   of their pros and cons.  Another possibility is to use the DSCP
   field, as in NSIS RMD [5], or a combination of the two.  The WG will
   study the trade-offs between different encoding options.


4.  Assumptions and Constraints on Problem Scope

   In order to make rapid progress, initially we will restrict the
   problem space in several ways.  NOTE: Subsequent re-chartering may
   investigate solutions for when some of these restrictions are not in
   place.  The working assumption is that the standards developed in the
   initial phase should not need to be modified to satisfy the solutions
   for when these restrictions are removed.

4.1.  Assumption 1: Controlled Environment

   We assume that the PCN-enabled Internet Region is a controlled
   environment, i.e. all the interior and end nodes of the region run
   PCN and trust each other.

   There are several reasons for proposing this assumption:

   o  The PCN-Region has to be fully encircled by a ring of PCN End
      Nodes, otherwise packets could enter the PCN-Region without being
      subject to admission control, which would potentially destroy the



Chan, et al.             Expires April 25, 2007                 [Page 9]


Internet-Draft                  Document                    October 2006


      QoS of existing flows.

   o  Similarly, a PCN End Node has to trust that all the interior
      routers are doing PCN-marking.  A non-PCN router won't be able to
      alert that it's suffering pre-congestion, which potentially would
      lead to too many calls being admitted (or too few being pre-
      empted).  Worse, a rogue router could perform attacks such as
      marking all packets so that no flows were admitted.

   One way of assuring the above two points is that the entire PCN-
   region is run by a single operator.  Another possibility is that
   there are several operators but they trust each other to a sufficient
   level.  Please note that this restriction applies to packets in the
   traffic class that is subject to the PCN mechanisms.

4.2.  Assumption 2: Many Flows and Additional Load

   We assume that there are many flows on any bottleneck link in the
   PCN-enabled region.

   Measurement-based admission control assumes that the past is a
   reasonable reflection of the future: the network conditions are
   measured at the time of a new flow request, however the actual
   network performance must be OK during the call some time later.

   One issue is that if there are only a few variable rate flows, then
   the aggregate traffic level may vary a lot, perhaps enough to cause
   some packets to get dropped.  If there are many flows then the
   aggregate traffic level should be statistically smoothed.  How many
   flows is enough depends on a number of things such as the variation
   in each flow's rate, the total PCN bandwidth, and the size of the
   "safety margin" between the traffic level at which we start PCN-
   marking and at which packets are dropped.

4.3.  Assumption 3: Real-Time Applications

   We assume that packets come from real time applications generating
   inelastic traffic like voice and video requiring low delay, jitter
   and packet loss, i.e. as defined by the Controlled Load Service [9].

   This assumption is to help focus the effort where it looks like PCN
   would be most useful, ie the sorts of applications where per flow QoS
   is a known requirement.  For instance, the impact of this assumption
   would be to guide simulations work.  NOTE: PCN should be readily
   extendible to other applications like ones that typically use Assured
   Forwarding [12].





Chan, et al.             Expires April 25, 2007                [Page 10]


Internet-Draft                  Document                    October 2006


5.  Open Design Issues

   Whilst working on the general issues of flow admission control and
   flow pre-emption, we have found several issues that proved hard to
   solve.  They are briefly documented here - further details are in
   [2].  In general they seem to be characteristics of most measurement-
   based admission control schemes, but some may not be relevant to
   particular deployment scenarios.  From the perspective of this
   problem statement, besides just noting the issue the PCN WG could:

   o  Upgrade the issue, so it's added to the "Goals" section earlier,
      or to the "Assumptions" section as appropriate

   o  Downgrade the issue, either because it isn't that important or
      because it's better dealt with outside the PCN solution

   o  Wait and see, ie as the PCN solution is developed assess how much
      extra complexity solving the issue would add

   The comments below are about admission control, but generally a
   similar issue arises for flow pre-emption.

   ECMP (Equal Cost Multi-Path) Routing:

         In order to decide whether to admit a new flow, the CL
         Architecture [2] scheme determines what the ingress and egress
         PENs would be and measures the current level of PCN-marking
         between them (Congestion-Level-Estimate).  If routers in the
         PCN-region run ECMP, then traffic between a particular pair of
         PENs may follow several different paths.  The problem is that
         if just one of the paths is congested such that packets are
         being PCN-marked, then the Congestion-Level-Estimate measured
         by the egress PEN will be diluted by unmarked packets from
         other non-congested paths.

   Bi-Directional Sessions:

         CL Architecture [2] describes a flow admission control
         mechanism.  However, from the application perspective, for a
         bi-directional session the two flows should be admitted as a
         pair - for instance a bi-directional voice call only makes
         sense if flows in both directions are admitted.

   Global Coordination:

         CL Architecture [2] makes its admission decision based on PCN-
         markings between a particular pair of PENs.  Decisions about
         flows through a different pair of PENs are made independently.



Chan, et al.             Expires April 25, 2007                [Page 11]


Internet-Draft                  Document                    October 2006


         However, one can imagine network topologies and traffic
         matrices where from a global perspective it would be better to
         make a coordinated decision across all the pairs of PENs for
         the whole PCN-region.  For example, to block (or even pre-empt)
         flows on one PEN pair so that more important flows through a
         different pair could be admitted.

   Aggregate Traffic Characteristics:

         Even when the number of flows is stable, the traffic level
         through the PCN-region will vary because the sources vary their
         traffic rates.  The CL Architecture [2] mechanism works best
         when there's "some" variability in the total traffic level at a
         router's interface (ie in the aggregate traffic from all
         sources).  Too much variation means that a router may (at one
         moment) not be doing any PCN-marking and then (at another
         moment) be overloaded, ie drop packets.  This makes it hard to
         tune the admission control scheme to stop admitting new flows
         at the right time.  However, too little variation can also be a
         problem.  For example, if all the sources are constant bit rate
         and are synchronised, then the total traffic level at a
         router's interface could be (almost) at its capacity and all
         packets could still be serviced instantly.  However, admitting
         one more flow could tip the router over its capacity, so its
         queue grew indefinitely until it had to drop packets.  "Some"
         traffic variation means that as the traffic level nears the
         capacity limit, some packets are PCN-marked but there's still
         enough capacity to cope with the traffic fluctuations.  Hence
         new flows can be blocked and packets are never dropped.

   Speed of Reaction:

         The CL Architecture [2] mechanism has a limited speed of
         reaction: if a big burst of admission requests occurs in a very
         short space of time (eg prompted by a televote), they could all
         get admitted before enough PCN-marks are seen to block new
         flows.  In other words, any additional load offered within the
         reaction time of the mechanism mustn't move the CL-Region
         directly from no congestion to overload.


6.  Security Implications

   Packets from normal precedence and higher precedence sessions [20]
   aren't distinguishable by PCN Interior Nodes.  This prevents an
   attacker specifically targeting, in the data plane, higher precedence
   packets (perhaps for DoS or for eavesdropping).  However, PCN End
   Nodes can access this information to help decide whether to admit or



Chan, et al.             Expires April 25, 2007                [Page 12]


Internet-Draft                  Document                    October 2006


   pre-empt a flow.  The separation of network information provided by
   the Interior Nodes and the precedence information at the PCN End
   Nodes allows simpler, easier and better focused security enforcement.

   PCN End Nodes police packets to ensure a flow sticks within its
   agreed limit.  This is similar to the existing IntServ behaviour.
   Between them the PCN End Nodes must fully encircle the PCN-Region,
   otherwise packets could enter the PCN-Region without being subject to
   admission control, which would potentially destroy the QoS of
   existing flows.

   It is assumed that all the Interior Nodes and PCN End Nodes run PCN
   and trust each other (ie the PCN-enabled Internet Region is a
   controlled environment).  For instance a non-PCN router wouldn't be
   able to alert that it's suffering pre-congestion, which potentially
   would lead to too many calls being admitted (or too few being pre-
   empted).  Worse, a rogue router could perform attacks such as marking
   all packets so that no flows were admitted.

   So security requirements are focussed at specific parts of the PCN-
   Region:

      The PCN End Nodes become the trust points.  The degree of trust
      required depends on the kinds of decisions it has to make and the
      kinds of information it needs to make them.  For example when the
      PCN End Node needs to know the contents of the sessions for making
      the decisions, when the contents are highly classified, the
      security requirements for the PCN End Nodes involved will also
      need to be high.

      PCN-marking by the Interior Nodes along the packet forwarding path
      needs to be trusted, because the PCN End Nodes rely on this
      information.


7.  IANA Considerations

   To be completed.


8.  Acknowledgements

   To be completed.


9.  Informative References

   [1]   Babiarz, J., "Congestion Notification Process for Real-Time



Chan, et al.             Expires April 25, 2007                [Page 13]


Internet-Draft                  Document                    October 2006


         Traffic", draft-babiarz-tsvwg-rtecn-05 (work in progress),
         October 2005.

   [2]   Briscoe, B., "An edge-to-edge Deployment Model for Pre-
         Congestion Notification: Admission  Control over a DiffServ
         Region", draft-briscoe-tsvwg-cl-architecture-03 (work in
         progress), June 2006.

   [3]   Briscoe, B., "Pre-Congestion Notification marking",
         draft-briscoe-tsvwg-cl-phb-03 (work in progress), October 2006.

   [4]   Babiarz, J., "SIP Controlled Admission and Preemption",
         draft-babiarz-pcn-sip-cap-00 (work in progress), October 2006.

   [5]   Bader, A., "RMD-QOSM - The Resource Management in Diffserv QOS
         Model", draft-ietf-nsis-rmd-08 (work in progress),
         October 2006.

   [6]   Baker, F. and J. Polk, "MLEF Without Capacity Admission Does
         Not Satisfy MLPP Requirements",
         draft-ietf-tsvwg-mlef-concerns-00 (work in progress),
         February 2005.

   [7]   Silverman, S., "Multi-Level Expedited Forwarding Per Hop
         Behavior (MLEF PHB)", draft-silverman-tsvwg-mlefphb-03 (work in
         progress), October 2005.

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

   [9]   Wroclawski, J., "Specification of the Controlled-Load Network
         Element Service", RFC 2211, September 1997.

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

   [11]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
         Weiss, "An Architecture for Differentiated Services", RFC 2475,
         December 1998.

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

   [13]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
         McManus, "Requirements for Traffic Engineering Over MPLS",
         RFC 2702, September 1999.




Chan, et al.             Expires April 25, 2007                [Page 14]


Internet-Draft                  Document                    October 2006


   [14]  Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
         Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
         Felstaine, "A Framework for Integrated Services Operation over
         Diffserv Networks", RFC 2998, November 2000.

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

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

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

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

   [19]  "Supporting Real-Time Applications in an Integrated Services
         Packet Network: Architecture and Mechanisms", Proceedings of
         SIGCOMM '92 at Baltimore MD, August 1992.

   [20]  "Multilevel Precedence and Pre-emption Service (MLPP)", ITU-T
         Recommendation I.255.3, 1990.

   [21]  "Economics and Scalability of QoS Solutions", BT Technology
         Journal Vol 23 No 2, April 2005.

   [22]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
         Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
         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.













Chan, et al.             Expires April 25, 2007                [Page 15]


Internet-Draft                  Document                    October 2006


Authors' Addresses

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

   Email: khchan@nortel.com


   Anna Charny
   Cisco Systems
   14164 Massachusetts Ave
   Boxborough, MA  01719
   USA

   Email: acharny@cisco.com


   Philip Eardley
   BT Research
   B54/77, Sirius House Adastral Park Martlesham Heath
   Ipswich, Suffolk  IP5 3RE
   United Kingdom

   Email: philip.eardley@bt.com
























Chan, et al.             Expires April 25, 2007                [Page 16]


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
   ietf-ipr@ietf.org.


Acknowledgment

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





Chan, et al.             Expires April 25, 2007                [Page 17]