Internet DRAFT - draft-vandenberghe-dcpel-basics

draft-vandenberghe-dcpel-basics






Network Working Group                                  S. Van den Berghe
Internet-Draft                                   Ghent University - IBBT
Expires: July 16, 2006                                         P. Mendes
                                      DoCoMo Communications Laboratories
                                                             Europe GmbH
                                                              K. Nichols
                                                             Pollere LLC
                                                        January 12, 2006


          DiffServ Control Plane: Problem Statement and Scope
                     draft-vandenberghe-dcpel-basics-00

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 July 16, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document provides a problem statement and scope boundaries to be
   used as input to the proposed Diffserv Control Plane Elements (DCPEL)
   BOF.  The goal of DCPEL is to provide a standard framework for the
   DiffServ Control Plane (DCP), service definition information models



Van den Berghe, et al.    Expires July 16, 2006                 [Page 1]

Internet-Draft                    DCPEL                     January 2006


   and protocol interworking guidelines for the operation of a single
   DiffServ domain in the context of an end-to-end (differentiated)
   service offering that comprises multiple such domains.  In addition
   to the views of the authors, this document has been influenced by the
   discussions of a group that included operators, integrators, vendors,
   and researchers that met in November of 2005.

Requirements Language

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  DCPEL Role . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  High-level View  . . . . . . . . . . . . . . . . . . . . .  7
       4.1.1.  Intradomain  . . . . . . . . . . . . . . . . . . . . .  9
       4.1.2.  Interdomain  . . . . . . . . . . . . . . . . . . . . . 10
       4.1.3.  Proposed Starting Point  . . . . . . . . . . . . . . . 11
     4.2.  Proposed DCPEL Milestones  . . . . . . . . . . . . . . . . 13
     4.3.  Possible Relation with Other Work  . . . . . . . . . . . . 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17



















Van den Berghe, et al.    Expires July 16, 2006                 [Page 2]

Internet-Draft                    DCPEL                     January 2006


1.  Introduction

   

   Diffserv (see RFC 2474, 2475, and 3086) is a model for delivering IP
   QoS in which the differentiated treatment given to packets in the
   forwarding path is separated from the control plane tasks.  The
   control plane has the job of responding to requests to configure
   these forwarding path components to allocate resources according to
   policy and availability.  Requests can originate internal or external
   to the Diffserv domain and can come from users, network operations,
   or network management.  The Diffserv WG described the forwarding path
   architecture in detail and specified some specific forwarding path
   elements.  The WG decided that the definition of a general control
   plane should be deferred to a future time, following deployment of
   the forwarding path features. A Diffserv control plane (DCP)
   includes entities that can produce configuration messages based on
   information about policy and the state of the network and in response
   to authorized requests.  The information can be detailed or simple,
   can be obtained in a variety of ways and may include explicit
   requests made to the control plane and requiring a response in real-
   time. A control plane must be configurable, secure, and
   monitorable.

   We are proposing that an IETF WG be chartered to work on the DiffServ
   Control Plane Elements needed to realize a DCP.  The goal of DCPEL is
   to provide a standard framework for the DiffServ control plane.  In
   addition to the views of the authors, discussion on the
   dcpel@ietf.org mail list and draft-nichols-dcpel-strawman-arch-00,
   this document has been influenced by the discussions of a group that
   included operators, integrators, vendors, and researchers in November
   of 2005 (see Acknowledgements).  This document is intended as a
   problem statement for the proposed WG which can be discussed on the
   mailing list (dcpel@ietf.org) in order to create a proposed charter.

   The major problem we plan to address is the lack of an accepted
   architectural framework for Diffserv Control Planes (DCPs).
   Differentiated services are enabled by applying rules at network
   domain edges to create traffic aggregates distinguished by particular
   DSCPs which are coupled to specific forwarding path treatments within
   the DS domain.  The now-closed Diffserv WG specified an architecture
   that explicity separated the forwarding path from the control plane
   of its IP QoS and concentrated on standards for node-level mechanisms
   in the forwarding path (see [RFC2474], [RFC2475]).  These mechanisms
   include classifiers to select packets for traffic aggregates,
   policers and shapers to condition the traffic aggregate, and the per-
   hop behaviors implemented by queuing and scheduling.  Per-Domain
   Behaviors (PDBs) were specified in [RFC3086] to define how to use



Van den Berghe, et al.    Expires July 16, 2006                 [Page 3]

Internet-Draft                    DCPEL                     January 2006


   those forwarding path components to compose traffic aggregates that
   receive particular treatments across single DS domains that can be
   characterized by metrics.

   The DiffServ forwarding elements are now widely available in routers
   and are in use in a number of both provider and enterprise networks.
   However, the individual deployments can be quite different and are
   statically configured (i.e., changes to allocations of differentiated
   services must be made by operators).  Statically configured PDBs with
   fixed criteria for admitted traffic streams do not allow for reaction
   or adjustment to different intra-domain network conditions, policies,
   or inter-domain relationships.  A useful DCP will monitor network
   conditions and have interfaces with policy rule databases.  It is
   expected that such network monitoring would be through interfaces to
   the collection of network performance metrics such as connectivity,
   packet loss, packet latencies across the network, etc.  A DCP may
   need to respond to requests that can be evaluated against network
   policies and conditions to result in changed configurations.  The
   time necessary to respond to such requests could be on the order of
   the time to set up a voice call, but specific values would be
   explored by a DCPEL WG.

   To move beyond simple static diffserv deployments, a common framework
   is needed to operationally ensure that the differentiated services an
   operator intends are those enabled.  The approach should make use of
   the diffserv forwarding path elements to implement the network
   operator's objectives as represented in policy rules.  In developing
   a DCP framework, we note that operators want to differentiate traffic
   for a wide range of sometimes dissimilar goals which include, but are
   not limited to, improved quality of service (QoS) for some traffic.
   Thus, it's important to keep in mind that when the term QoS is used
   in this document, it covers the larger set of "DifS" or
   differentiated services that can be applied to traffic streams to
   differentiate them in any feasible and desirable way.  For example,
   the approach of allowing some packets to transit a network only when
   the bandwidth is unused (e.g., [RFC3662]) and the practice of
   completely disallowing some types of traffic.  "DifS" can be applied
   to any administratively significant subsets of packet traffic
   including microflows, traffic streams, traffic aggregates that follow
   a unique path across a domain, and traffic aggregates with multiple
   ingress and egress points.

   A DCP architectural framework must be developed with the awareness
   that there can be no "one size fits all" solution.  Taking a path
   analogous to that of DiffServ in the forwarding path, we propose
   specification of the distinct component elements that can be used to
   construct a DCP, development of the general framework of such a DCP,
   and descriptions of a small number of example DCPs that can be built



Van den Berghe, et al.    Expires July 16, 2006                 [Page 4]

Internet-Draft                    DCPEL                     January 2006


   under the framework and with the elements.  A common architectural
   framework for DCPs would permit the development of a rich set of
   products to complement those available in the forwarding path and the
   deployment of interoperable IP QoS.  Other IETF WGs and other
   standards bodies have worked on some of the elements needed for a
   DCP, specifically the definition of protocols and performance metrics
   for services.  This prior work should be used as a starting point
   when possible and only discarded or modified if necessary.

   The process of requesting a level of service from a network and of
   providing it must not expose the internals of the network.  This has
   been a clear and consistent message from service providers from the
   views expressed at the FDIFFS BoF held in April 1997 before the
   Diffserv WG was formed (www3.ietf.org/proceedings/97apr/97apr-final/
   xrtft122.htm) to those expressed by providers at our November 2005
   meeting.  Once a common framework exists, two or three possible
   options within that framework should be developed and a network
   operator might choose to be public about what option is being
   employed.


2.  Definitions

   This draft uses definitions from RFCs 2474, 2475, and 3086, some of
   which are repeated here for easy reference.

   o  Differentiated Services Domain: a contiguous portion of the
      Internet over which a consistent set of differentiated services
      policies are administered in a coordinated fashion.  A
      differentiated services domain can represent different
      administrative domains or autonomous systems, different trust
      regions, different network technologies (e.g., cell/frame), hosts
      and routers, etc.  Also DS domain.

   o  Behavior Aggregate: a collection of packets with the same
      codepoint crossing a link in a particular direction.

   o  Microflow: a single instance of an application-to-application flow
      of packets which is identified by source address, destination
      address, protocol id, and source port, destination port (where
      applicable).

   o  Traffic stream: An administratively significant set of one or more
      microflows which traverse a path segment.  A traffic stream may
      consist of the set of active microflows which are selected by a
      particular classifier.





Van den Berghe, et al.    Expires July 16, 2006                 [Page 5]

Internet-Draft                    DCPEL                     January 2006


   o  Per-hop Behavior (PHB): a description of the externally observable
      forwarding treatment applied at a differentiated services-
      compliant node to a behavior aggregate.

   o  Mechanism: [2475] A specific algorithm or operation (e.g.,
      queueing discipline) that is realized in a node to implement a set
      of one or more per-hop behaviors [To which we add] or one or more
      Diffserv control plane elments.

   o  Traffic Aggregate: a collection of packets with a codepoint that
      maps to the same PHB, usually in a DS domain or some subset of a
      DS domain.  A traffic aggregate marked for the foo PHB is referred
      to as the "foo traffic aggregate" or "foo aggregate"
      interchangeably.  This generalizes the concept of Behavior
      Aggregate from a link to a network.

   o  Per-Domain Behavior (PDB): the expected treatment that an
      identifiable or target group of packets will receive from "edge-
      to-edge" of a DS domain.  (Also PDB.)  A particular PHB (or, if
      applicable, list of PHBs) and traffic conditioning requirements
      are associated with each PDB.

   o  A Service Level Specification (SLS) is a set of parameters and
      their values which together define the service offered to a
      traffic stream by a DS domain.  It is expected to include specific
      values or bounds for PDB parameters.

   New definitions:

   o  Differentiated Services Control Plane (DCP): Short-term changes in
      the QoS goals for a DS domain are implemented by changing only the
      configuration of the edge behaviors (e.g., classifiers and
      conditioners) without necessarily reconfiguring the behavior of
      interior network nodes.  A DiffServ Control Plane (DCP) is
      responsible for handling requests to make such changes and for
      implementing them.

   o  DiffServ Control Plane Elements (DCPEL): The modular components,
      implemented by appropriate mechanisms, that make up a DCP.  A
      request-handling mechanism could be a DCPEL.

   (Note this document uses the term "QoS" to denote that a set of
   measures can be attached to a designated subset of packet traffic and
   the measures are expected to be ensured using Diffserv mechanisms.)


3.  Requirements




Van den Berghe, et al.    Expires July 16, 2006                 [Page 6]

Internet-Draft                    DCPEL                     January 2006


   An initial take on the DCPEL requirements can be found in
   draft-mendes-dcpel-requirements-00.txt.  Development and publication
   of requirements should be a work item of a DCPEL WG, if chartered.


4.  DCPEL Role

   Building on the definitions, this section gives background for a
   proposed role for a DCPEL working group.  We use DCP to denote a
   generic DiffServ control plane and DCPEL architecture or framework to
   denote a product of the proposed BoF/WG.

4.1.  High-level View

   A DCP architectural framework should allow for automatic adjustment
   of the allocation of PDBs in response to network state changes (e.g.
   link status), policy database changes, or specific requests for
   resource allocations.  Since DS domain operators have a wide range of
   operational goals, the framework should be constructed from a set of
   well-defined modular components.  The DCP should be realized within a
   framework that permits variation (capabilities may cover a wide
   spectrum) but utilizes common elements that can be specified and
   perhaps standardized.  Following the specification of this
   intradomain DCP, a standard interdomain interface to the DCP is
   needed.  The interdomain interface should be independent from
   specifics of the intradomain DCP.

























Van den Berghe, et al.    Expires July 16, 2006                 [Page 7]

Internet-Draft                    DCPEL                     January 2006


                    +-DCP-----------------------------+
                    |                                 |
                    | +---------------+  +-----+      |
                    | |Domain Policies|  | AAA |      |
                    | +--------||-----+  +-----+      |
                    |          ||          ||         |
                    |    +-----||----------|+         |
   QoS Announce(*) <=====|                  |=========> QoS Announce (*)
   QoS Request  ========>|                  |=========> QoS Request
   QoS Response <========|        DCP       |<========= QoS Response
   QoS Query(*) ========>|                  |=========> QoS Query(*)
   QoS Status   <========|                  |<========= QoS Status
                    |    +----||------------+         |
                    |         ||          ||          |
                    | +-------||------+ +-||--------+ |
                    | | Enforcement   | | Monitoring| |
                    | +---------------+ +-----------+ |
                    |                                 |
                    +---------------------------------+
   (*) optional message
                   Figure 1: DCP Architectural Framework

   Figure 1 illustrates a strawman DCP architecture, showing protocol
   message interactions.  Several modes of operations can be defined for
   a DCP based on this coarse overview.  A DCP can be centralized or
   distributed, its enforcement can be centralized, distributed, or
   signaled and several bindings to external protocols can be made.  The
   specific architecture of the different components in Figure 1 are
   seen as topics for discussion for a DCPEL BoF.  Components

   o  DCP: contains the necessary rules and logic to respond to
      requests, changes in network state, and changes in domain policies
      with a configuration of the domain (primarily diffserv edge
      mechanisms) that meets the operational goals

   o  Enforcement: ensures that packets are matched with their correct
      forwarding path treatment.  In a DS domain, usually done by
      configuring edge mechanisms.  A protocol is needed to implement
      the configuration of the forwarding path (e.g., COPS, CLI).

   o  Monitoring: in order to adjust configurations, evaluate ability to
      respond to requests, record delivered commitments, etc., the DCP
      needs access to a wide range of information about the operational
      conditions of its network.  DCPEL will not work on developing
      monitoring tools, but rather on defining what types of network
      status are needed and on how this can be communicated to the DCP.
      This may stimulate work in other IETF WGs or by vendors.




Van den Berghe, et al.    Expires July 16, 2006                 [Page 8]

Internet-Draft                    DCPEL                     January 2006


   o  Domain Policies: the rules that determine who gets access to
      certain differentiated services and under what conditions.  A DCP
      must either contain these or have access to them, perhaps a
      combination.

   o  AAA: A DCP must have access to the AAA information for a domain in
      order to authenticate and authorize requests and for accounting,
      if part of the domain.

   A first message sequence for the creation of a QoS session might be:

   o  An external protocol/mechanism sends a QoS query to a DCP.

   o  The DCP combines this with internal policies, state of the network
      (e.g. obtained through monitoring) and sends a QoS response.

   o  The external protocol/mechanism can confirm this offer in an
      actual QoS request.

   o  DCP enforcement configures its Diffserv domain to support the
      service.  The domain might also interact with other domains in a
      similar way to propagate the QoS session setup.

   o  At regular intervals, or on demand the DCP can send status
      information on the actual service that was delivered.

   An alternative message sequence is:

   o  The DCP announces its available services.

   o  A client protocol/mechanism requests a service.

   o  The DCP accepts/rejects this request in a response message.
      Again, part of this process might involve interactions with other
      domains.

   o  At regular intervals, or on demand the DCP can send status
      information on the actual service that was delivered.

   These two sequences give the semantics of possible message exchanges
   with a DCP within a DS domain.  Defining the message sequence and
   protocol state machine is expected to be part of the discussions in a
   DCPEL BoF.

4.1.1.  Intradomain

   The intradomain DCP is responsible for responding to requests of its
   DS Domain.  For this it needs to manage the state of a DS session



Van den Berghe, et al.    Expires July 16, 2006                 [Page 9]

Internet-Draft                    DCPEL                     January 2006


   (i.e. a request for a specific DS allocation over a time period).
   Such a DS Session may be initiated, modified and terminated by any
   authorized party.  These sessions may be established by external
   protocols.

   DCP enforcement can be done in three different ways:

   o  Managed: a domain-wide resource broker service can manage the
      configuration of the DS domain.  Signaling or messaging is
      directed at the service.

   o  Signaled: signaling protocols such as NSIS or RSVP(-TE) can be
      used to distribute a configuration across a domain between the two
      (or more) involved borders of the DS domain.  The signaling must
      include coordination of the involved edge routers and availability
      of the desired resources internally.  A DCP would interact with
      the signaling through a QoS Agent in the router (as shown in
      figure 1 of [RFC3290]).

   o  Hybrid: a resource broker service can pre-provision a
      configuration in the DS domain, which is in turn managed
      distributively by the two (or more) involved borders of the DCPEL
      domain.

   DCPEL will not enforce any of these specific approaches, but its
   framework will provide the information models necessary to support
   them.  There must be a non-path-specific option.

   A DS domain's behavior with respect to the outside world is driven by
   the domain policies.  Through these policies a wide set of domain
   services can be defined, based on both performance-related (e.g.
   delay) and external parameters (e.g. time-of-day).

4.1.2.  Interdomain

   Although definition of an interdomain QoS signaling protocol is
   considered as future work for the proposed DCPEL WG, the intradomain
   DCP framework needs to fit into a future interdomain scenario.  A DCP
   framework should have an interface for creating DS sessions with
   peering DS domains, though intiailly this will be unused and
   incompletely specified.  Thus the DCPEL architecture should provide
   interfaces with interdomain QoS signaling and an information model
   that is applicable across these interfaces to represent the DS
   capabilities ("services") available in a domain.  This does not imply
   all DS domains will be required to offer DS capabilities that are
   identical.





Van den Berghe, et al.    Expires July 16, 2006                [Page 10]

Internet-Draft                    DCPEL                     January 2006


             7 DCPEL Services -> 4 DCPEL Services
                        6 PDBs-> 2 PDBs
                    +--------+  +--------+
   QoS Request  ===>| DCPEL  |=>| DCPEL  |=>...
   QoS Response <===| Domain |<=| Domain |<=...
   QoS Status   <===|   A    |<=|   B    |<=...
                    +--------+  +--------+
      Figure 2: Inter-Domain DCPEL Scenario

   The above figure shows a small interdomain scenario.  Domain A has 7
   Differentiated Services offerings which are implemented by 6 PDBs
   defined on Domain A. For inter-domain operation with Domain B, these
   are mapped to the 4 DifS defined by Domain B. As part of inter-domain
   operation, DSCP field treatment must be considered.  One option is to
   have an agreement that preserves the upstream domain's DSCP, either
   by tunneling the packets or by mapping and re-mapping.  In the
   absence of any other agreement, the DSCP may be rewritten (following
   RFC2475), which must be taken into account in the construction of
   interdomain services.

4.1.3.  Proposed Starting Point

   This section came directly from discussions in the November 2005
   meeting.

   The acknowleged "big problem" is having common notions of the
   differentiated services that are provided and a few examples of how
   to achieve these.  Other significant concerns are moving toward end-
   to-end services and method(s) for applications to interact with the
   DCP (e.g., to make requests).  A suitable framework must allow for
   the communication of critical items, but not expose network internals
   beyond the borders.  Given the clear desire to hide what's done in
   individual networks (both for proprietary reasons and for scale and
   composability), look at what we can expose.  The following were
   proposed:

   o  a general framework for describing requests

   o  service descriptions that are technology independent

   o  PDBs

   o  a list of network metrics required or desired by the DCP

   A major issue of a possible DCPEL BoF/WG is to discover whether the
   IETF community can agree to a higher level service model.  We propose
   evaluating the ITU-T service classes from Y.1541 as a starting point
   for a service description framework; focusing on the NSIS work on a



Van den Berghe, et al.    Expires July 16, 2006                [Page 11]

Internet-Draft                    DCPEL                     January 2006


   QSPEC [I-D.ietf-nsis-qspec] to carry SLS parameters between requestor
   and DCP.  Since the NSIS QoS NSLP is a path-oriented RSVP approach, a
   more suitable protocol may develop through collaboration with the
   NSIS WG.  A possible additional product for a DCPEL WG is PDBs that
   could implement these service classes.

   DCPEL will need to consider the kinds of network status that is
   needed to be used as feedback to the DCP.  The development of
   monitoring tools and techniques to supply this status is not expected
   to take place in the DCPEL WG, but the enumeration of the needed and
   useful network status information may stimulate work in other areas.
   The sort of network metrics that may be needed include: jitter,
   latency, packet loss, and queue statistics.  We can anticipate the
   DCP needing feedback that can be:

   o  local, i.e., from a single network node (e.g. a router)

   o  domain wide

   o  sub-domain, traffic aggregate, or other administratively useful
      designation within a domain

   o  intradomain or border feedback

   o  end-to-end status

   The IPPM WG has published a number of metrics that should be useful
   in quantifying the performance of PDBs and the general status of the
   network.  These should be useful for at least some of the metrics
   needed.

   It is not a goal of this effort to define application interaction
   with differentiated services mechanisms, so the best approach at
   present is to follow the specifications for SIP-QoS interaction
   outlined in [RFC3312].  At best, this solves the problem, at worst,
   it is a good placeholder for a later interface or interfaces.

   To understand the number of distinct differentiated services that may
   need to be exposed, note that current deployments use 2-3 queues in
   the backbone and the thinking is this could go to 5 or 6 in the
   future.  Operational complexity is expected to keep this limited.
   More commercially visible services might be defined, but the interior
   treatments will be limited.  Since different PDBs might use the same
   interior queues (with different edge treatments) and multiple
   externally advertised services might use the same PDB (e.g., subject
   to different policy constraints), this suggests the task can be quite
   managable.




Van den Berghe, et al.    Expires July 16, 2006                [Page 12]

Internet-Draft                    DCPEL                     January 2006


4.2.  Proposed DCPEL Milestones

   o  Define requirements for architecture, protocols and information
      models.

   o  Define overall architecture (DCP functionality, DCP architectural
      framework, DCP interworking with external mechanisms, etc.).

   o  Define DCP service information models and service framework
      (additions to QSPEC or something else).

   o  Define a set of DCP enforcement architectures and mechanisms (i.e.
      single-domain DCP implementations) that satisf the framework.

   o  Define interworking of a DS domain (and its DCP) with NSIS, RFC
      3312 and other related protocols.

4.3.  Possible Relation with Other Work

      NSIS: may be useful as both an external signaling protocol and by
      DCPEL enforcement element:



      *  Use of path-decoupled signaling between domains.

      *  Use of path-coupled signaling inside a domain between pairs of
         ingress-egress for allocation of PDBs (reallocation of resource
         pool, for instance).

      NSIS QSPEC: may be used to define QoS parameters.

      IPPM: does metric definition (including composing individual
      measurement to an end-to-end, or cloud-wide, metric useful for
      announcing DCPEL services).

      COPS, Netconf, SNMP: possible protocols for DCP enforcement
      element

      SIP: alternative external protocol binding that can manage QoS
      Sessions.

      SIP: binding to actual VoIP call setups through RFC3312.

      XACML: possible specification of the policies; service description
      and decision logic.





Van den Berghe, et al.    Expires July 16, 2006                [Page 13]

Internet-Draft                    DCPEL                     January 2006


      Diameter QoS Application: authenticates QoS requests (http://
      www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-03.txt)


5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


6.  Security Considerations

   This document aims at defining the scope of a DiffServ Control Plane
   for a proposed DCPEL BoF thus has no security considerations.  Lots
   of security issues will need to be handled in the DCPEL architectural
   and protocol documents.


7.  Acknowledgements

   Participants in the November meeting made valuable contributions
   toward clarifying what's needed in the Diffserv Control Plane.  Any
   errors or misinterpretations are those of the editors.  We wish to
   thank Larry Dunn, Robert Hancock, Anshul Kantawak, Amit Kulkari,
   Roman Krzanowski, John Kenney, Dilip Gokhalg, Eric Brendel, Zhutao
   Cheng, Hannes Tschofenig, Andres Pashalides, Rene Barrios, Jeff
   Pulliam, and Dave McDysan.  In addition, Robert Hancock, John Kenney,
   Roman Krzanowski, and Jeff Pulliam provided some needed wordsmithing
   suggestions.

8.  Normative References

   [I-D.ietf-nsis-qspec]
              Ash, J., "QoS-NSLP QSPEC Template",
              draft-ietf-nsis-qspec-07 (work in progress), October 2005.

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

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

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated



Van den Berghe, et al.    Expires July 16, 2006                [Page 14]

Internet-Draft                    DCPEL                     January 2006


              Services", RFC 2475, December 1998.

   [RFC3086]  Nichols, K. and B. Carpenter, "Definition of
              Differentiated Services Per Domain Behaviors and Rules for
              their Specification", RFC 3086, April 2001.

   [RFC3290]  Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
              Informal Management Model for Diffserv Routers", RFC 3290,
              May 2002.

   [RFC3312]  Camarillo, G., Marshall, W., and J. Rosenberg,
              "Integration of Resource Management and Session Initiation
              Protocol (SIP)", RFC 3312, October 2002.

   [RFC3662]  Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
              Per-Domain Behavior (PDB) for Differentiated Services",
              RFC 3662, December 2003.


































Van den Berghe, et al.    Expires July 16, 2006                [Page 15]

Internet-Draft                    DCPEL                     January 2006


Authors' Addresses

   Steven Van den Berghe
   Ghent University - IBBT
   G. Crommenlaan 8 bus 201
   Gent  9050
   Belgium

   Phone: +32 9 331 49 73
   Email: steven.vandenberghe@intec.ugent.be


   Paulo Mendes
   DoCoMo Communications Laboratories Europe GmbH
   Landsberger Strasse 312
   Munich  80687
   Germany

   Phone: +49 89 56824 226
   Email: mendes@docomolab-euro.com
   URI:   http://www.docomolab-euro.com/


   Kathleen Nichols
   Pollere LLC
   325M Sharon Park Drive #214
   Menlo Park, CA  94025
   USA

   Email: nichols@pollere.com





















Van den Berghe, et al.    Expires July 16, 2006                [Page 16]

Internet-Draft                    DCPEL                     January 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Van den Berghe, et al.    Expires July 16, 2006                [Page 17]