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]
