Internet DRAFT - draft-mendes-dcpel-requirements
draft-mendes-dcpel-requirements
Network Working Group P. Mendes
Internet-Draft DoCoMo Euro-Labs
Expires: July 17, 2006 K. Nichols
Pollere LLC
January 13, 2006
Requirements for DiffServ Control Plane Elements
draft-mendes-dcpel-requirements-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 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a set of requirements for a DiffServ Control
plane. It defines requirements for operations within and between
network domains, as well as a set of assumptions.
Mendes & Nichols Expires July 17, 2006 [Page 1]
Internet-Draft Requirements for DCPEL January 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 3
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Architecture and Design . . . . . . . . . . . . . . . . . 6
5.2. Intra-domain Control . . . . . . . . . . . . . . . . . . . 7
5.3. Inter-domain Control . . . . . . . . . . . . . . . . . . . 8
5.4. Distributed Control . . . . . . . . . . . . . . . . . . . 9
5.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Mendes & Nichols Expires July 17, 2006 [Page 2]
Internet-Draft Requirements for DCPEL January 2006
1. Introduction
This document is the product of initial discussions aiming to shape
the definition of DiffServ Control Plane Elements (DCPEL) in the
IETF. It defines requirements for operations within and between
network domains, following the work presented in [I-D.nichols-dcpel-
strawman-arch] and in [RFC2638] and [RFC3086].
To derive requirements for signaling it is necessary to have an idea
of the scope within which they are applicable. Therefore, a
statement about the problem to be solved is presented, as well as a
set assumptions and exclusions. Moreover, a list of scenarios where
a DCPEL solution could be applied is briefly described, in order to
sustain and test the identified set of requirements.
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 [RFC2119].
2. Terminology
TBD
(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. Problem Statement and Scope
The Internet control plane enables packet routing between networks,
which makes it suitable to provide best-effort data transport between
an increasing number of end-hosts. Regarding data traffic that has
extra quality requirements, more advanced features are needed to
control QoS between end-hosts.
The Diffserv ([RFC2474], [RFC2475] and [RFC3086]) architecture can be
separated into the differentiated treatment given to packets in the
forwarding path and the task of configuring these forwarding path
components to allocate QoS according to policy and availability. The
IETF Diffserv WG described the forwarding path architecture in detail
and specified some specific forwarding path elements.
Diffserv forwarding path elements are now available in most current
routers and are used in many networks. Although these features have
proven useful to a number of network operators, a barrier to more
widespread use has been the lack of a common specification for the
Mendes & Nichols Expires July 17, 2006 [Page 3]
Internet-Draft Requirements for DCPEL January 2006
Diffserv control plane (to automatically configure the forwarding
path elements in response to network status and operational requests)
and example uses in Diffserv domains. Another major barrier to the
deployment of end-to-end QoS in heterogeneous environments is the
lack of an automatic and dynamic approach to control QoS agreements
between network domains.
The need to address these issues will increase as we move toward more
dynamic topologies with multi-homed hosts and networks.
Confronting these barriers and with the perspective of more
challenging future scenarios, there is a clear need to control
DiffServ networks and to provide a context for internetworking
Diffserv. The development of a control plane for DiffServ networks
should address several intra-domain and inter-domain problems.
The following are examples of intra-domain issues:
o The need to reflect high-level policies, together with their usage
in different roles (customer, provider, transit).
o The number of triggers for the DPCEL logic may be significant,
e.g., intra-domain monitor, and inter-domain triggers (offer,
request, query).
o The enforcement of QoS requests which may need to be held in the
future and possible in specific time intervals.
o Dynamic reaction of the Diffserv dimensioning to both changes in
QoS needs (signaled or dictated by network management) and changes
in network topology and conditions.
o Control of PDBs to unicast as well as multicast traffic, as well
as consideration about asymmetric routing.
The following are examples of problems posed to an inter-domain
control solution:
o There is no standard interface between heterogeneous domains.
o Relationship of PDBs on different networks may not be 1-to-1.
o Handling several SLSs, which may have been negotiated to be used
over different time scales.
o Limited functionality, not supporting, for instance, the
cooperation between networks.
Mendes & Nichols Expires July 17, 2006 [Page 4]
Internet-Draft Requirements for DCPEL January 2006
o No interface with end-to-end probing mechanisms able to check the
level of QoS assurances provided by a chain of SLSs
o A security framework that prevents interdomain cooperation on QoS
to become a vector for attacks
o A framework that permits export of required performance metrics
while permitting network operators to keep network internals
sufficiently opaque.
4. Assumptions
o A domain may operate with one of three possible roles: a) as a
provider, offering agreements about QoS reachability; b) as a
customer, negotiating access to offered SLSs; c) both as a
customer and as a provider. This means that DifffServ domains
have bi-lateral relationships.
o A specific intra-domain control plane solution will have
dependencies on the particular forwarding path of that domain and
more than one solution can fit the set of identified requirements.
This argues for a focus on the common Diffserv control plane
elements and presentation of some illustrative architectures.
o Inter-domain control is performed between externally identifiable
network elements in adjacent networks, although data exchange
resultant from possible agreements may follow distinct inter-
network paths (e.g. in multi-connected networks). Hence, inter-
network control is decoupled from the forwarding path.
o The inter-domain control plane requires only the existence of
relationships of limited trust with adjacent domains, unlike
schemes that require the setting of flow specifications in routers
throughout an end-to-end path.
o Although not all networks will be DiffServ, all of them will
interact based on the same inter-domain control interface. For
instance, backbone networks may be over-provisioned, but they will
still offer and negotiate QoS agreements with their neighbors.
o Existing protocols (such as HTTP, COPS, SNMP, RSVP, and NSIS)
should be analyzed against the set of requirements for intra-
domain and inter-domain operations. Some options or new
functionalities may need to be added to selected protocols and
this could likely be accomplished within the IETF WGs related to
those protocols.
Mendes & Nichols Expires July 17, 2006 [Page 5]
Internet-Draft Requirements for DCPEL January 2006
o A DiffServ Control Plane has two types of elements: network-wide
control agents that may perform operations over the entire network
domain or subsets of the domain that are larger than one router;
local control agents that are limited to control of a single
network element like an edge or an interior router.
o Different domains may implement different PDBs, which are mapped
by means of a SLS between both networks. As some packets may be
encrypted when traveling between domains, the available packet
fields for edge computation may be only tunnel source, tunnel
destination, DSCP, SPI, and MAC level information. Hence, the
identifier of SLS should be encoded in the DSCP field though the
receiving network may use additional available packet fields (and
other information such as MAC address and input port) to identify
the sender at ingress.
o Configurations of the control plane do not happen at forwarding
speeds and may indeed take place over long time periods. Even an
extremely dynamic configuration will not cause updates at
forwarding speeds (i.e., per-packet).
o Networks will be heterogeneous, and end-hosts as well as some
access networks, such as trains, vessels, or planes, may be
mobile.
o Traffic may be unicast or multicast.
o Most of the routes in the Internet will still be asymmetric
(either intra-domain or inter-domain routes).
5. Requirements
5.1. Architecture and Design
o A control plane must be configurable, secure and monitorable. It
will encompass network elements that may produce configuration
messages based on information about policies, and on information
about the network state.
o Network elements will differ in complexity, allowing an extra
degree of flexibility in a framework where interfaces and
functionalities are well understood.
o Must be modular, which means a clear identification of the set of
operations and the required interfaces between them.
Mendes & Nichols Expires July 17, 2006 [Page 6]
Internet-Draft Requirements for DCPEL January 2006
o Must provide a clear distinction between inter-domain operations
and intra-domain operations. Sections Section 5.2 and Section 5.3
provide a set of requirements for intra-domain and inter-domain
operations, respectively.
o A domain's Diffserv control plane may be distributed over
different network-elements in a coordinated manner, in a way
similar to network routing. A set of requirements for the
distribution of operations is presented in section Section 5.4.
o An arachitecture should enable the provision of an end-to-end
guarantee over a path of interconnected DiffServ domains. The
resultant QoS levels will depend on the functionality of each
domain and the QoS levels offered and negotiated agreements with
its peers. (Extra requirements on the operation of DiffServ
network may be identified after analyzing scenarios with multi-
connected domains).
5.2. Intra-domain Control
o A Diffserv Control Plane (DCP) must present a common intra-domain
interface, allowing network elements to coordinate their actions,
independently of the degree of control distribution. This
interface can by defined by messages sent over protocols such as
COPS, SNMP, or the NSIS protocol suite.
o The DCP controls a set of PDBs that are provisioned on a domain
considering local policies, network characteristics including PHB
mechanisms available, and the set of agreements with adjacent
networks and attached hosts.
o The DCP handles requests to admit traffic fstreams to these
existing PDBs. Policy information specific to a requester, or
other general policies must be checked to determine if the request
can be accepted. This admission control operation may be
performed at local network elements at the edge or in a network-
wide agent.
o Allocations may be characterized by ingress, egress, PDB type,
DSCP, overall validity, periods of time over which this allocation
must be performed, and information about the identity of the user
requesting this allocation.
o The DCP monitors selected network control and state information,
either directly or indirectly.
o Intra-domain operations must be supported by a list of policies
and rules, as well as a group of databases. The latter should
Mendes & Nichols Expires July 17, 2006 [Page 7]
Internet-Draft Requirements for DCPEL January 2006
provide information about the state of the network, most likely
collected by monitoring operations. Some intra-domain operations
may also need to access databases related to inter-domain control,
namely the set of established and available agreements.
o The DiffServ control plane must support allocation of PDBs to
multicast flows, taking into account that intra-domain routing may
be asymmetric.
o In meshed networks, the allocation of requests to PDBs should
react to cases of link failure, or decrease of available quality
level (due for instance to the malfunctioning of some network
elements).
o Changes in allocations may be performed based on the priority of
the allocations, or other measure of efficacy defined by policies.
o Should support mobile end-hosts and networks, which requires
automatic adjustment of intra-domain configurations.
5.3. Inter-domain Control
o A common inter-domain interface must be available, allowing the
QoS set-up of inter-domain traffic streams while hiding intra-
domain characteristics from inter-network operations. This
interface can be implemented by the definition of messages on top
of protocols (or modification of protocols) such as the NSIS
protocol suite, SIP, or protocols based on HTTP. To allow easier
parsing and more flexibility in setting security actions, such
messages may be defined in a language like XML.
o The inter-domain interface should be independent from the
specifics of the intra-domain control plane.
o Communication over a common inter-domain interface must be made
based on a well-understood information model for SLSs. This model
should allow the definition of different degrees of SLSs, from
per-flow, more suitable for end-hosts or small networks, to per-
aggregate, more suitable for large networks. It should also allow
the identification of the SLS validity and a set of time periods
over each the SLS must be available (activated), besides the
information about the QoS characteristics. To allow for extra
flexibility, the information model should be defined in an
extendable language such as XML.
o Each domain must have a set of policies to coordinate its
activities as provider, customer, of customer-provider of SLSs,
and must keep information about established and available/offered
Mendes & Nichols Expires July 17, 2006 [Page 8]
Internet-Draft Requirements for DCPEL January 2006
agreements. This information may be associated with the identity
of the user or network offering or requesting SLSs.
o The inter-domain interface must allow network domains to offer,
request/negotiate, and monitor agreements/SLSs. Policy
information specific to the requester, or other general policies
must be checked to determine if the requested agreement can the
accepted.
o Each domain must ensure that the data packets it sends are in
conformity with the established agreement or risk of having
packets dropped. Packets should be re-marked from the internal
PDB identifier to the inter-domain SLS identifier if needed. At
the provider side, packets may be re-marked from the SLS
identifier to its internal PDB.
o A DS network or end-host should be able to receive information
about the nature of QoS assurances available to a specific
destination network from the attached access network, either upon
attachment or through queries.
o End-to-end signaling may be used to check the available guarantees
in a chain of DiffServ domains. In some domains, this signaling
may check that a suitable agreement is in place, in others the
signaling may 'ask' for the 'activation' of a specific agreement
(assuming that agreements are already negotiated but they are
associated to another time period, for instance), or it may ask
for the negotiation of a specific agreement.
o Should support mobile end-hosts and networks, which requires
automatic adjustment of inter-domain agreements.
5.4. Distributed Control
o The DCP should be externally identified by a well-known address,
Independently of the degree to which the specific DCP
implementation is distributed.
o The externally well-known address may represent a real or a
virtual entity, depending on the degree of distribution of the
DCP.
o Intra-domain control may be implemented by a single network-wide
agent, or by a group of local agents. The distribution of control
over a set of local-agents may depend on the characteristics of
the network, such as network speed and amount of computational
resources at the edges. An example of distributed control would
be to have a well-known agent responsible for the inter-domain
Mendes & Nichols Expires July 17, 2006 [Page 9]
Internet-Draft Requirements for DCPEL January 2006
control and for the configuration of the appropriate ingress agent
(agent near or collocated with an ingress router), including
informing the ingress agent about an authorized request for a
traffic stream to receive a particular PDB. Based on this
information, the ingress agent sets up an allocation record and
uses an available intra-domain protocol to configure ingress
traffic conditioners and notify the suitable egress agent.
o Each agent may have its own database, query needed information
among neighbor agents or fetch it from a well-know agent.
o Pools of resources may be controlled by a network-wide agent or
may be distributed among local-agents. In the former case, local-
agents may request extra resources from a network-wide agent. In
the latter case, local-agent may probe the network, instead of
relying only on its local pool of resources, in order to increase
resource usage. Moreover, if resource control is delegated to
local-agents, there must be a mechanism to coordinate actions
among local-agents.
5.5. Performance
o The intra-domain control plane must scale with the number of
available PDBs, number of requests, and number of distinct ingress
Diffserv traffic streams to be tracked.
o The intra-domain control plane should react fast enough to changes
in the domain topology, provisioning and failure of control
elements.
o The inter-domain control plane must scale with the number of
networks, available SLSs and number of requests. This may require
some kind of aggregation mechanism.
o The inter-domain control plane should react fast enough to changes
in the inter-domain topology, provisioning of inter-domain links,
and available/offered agreements.
o Distribution of control may be required to increase reliability,
to avoid control bottlenecks, to reduce latency of operations, or
to increase local autonomy.
5.6. Security
o Agreements between domains must be set-up via a secure
association.
Mendes & Nichols Expires July 17, 2006 [Page 10]
Internet-Draft Requirements for DCPEL January 2006
o There may be a trust relationship between domains, providing a
Customer with assurances about the fulfillment of established
agreements. If some trust relationship does not exist, there
should be a probing mechanism allowing a domain to check if an
established SLS is being fulfilled.
o In each domain, only a well-known element can configure edge
agents via a secure association.
o Authentication may be a part of the DCP, or may be an accessible
external functionality.
6. Security Considerations
The general security considerations of [RFC2474] and [RFC2475] apply.
Extra security considerations are given in section Section 5.6.
7. Acknowledgments
The authors would like to thank to all the people involved in the
initial discussion that have been happening in the DCPEL mailing
list.
8. Appendix
TBD: possible scenarios may be:
o Static scenario
o Multi-homed networks
o Mobile terminals
o Mobile Networks
o Multi-network connection
o Interaction with non-DiffServ networks.
9. References
[I-D.nichols-dcpel-strawman-arch]
Nichols, K., "A Strawman Architecture for Diffserv Control
Plane Elements", draft-nichols-dcpel-strawman-arch-00
Mendes & Nichols Expires July 17, 2006 [Page 11]
Internet-Draft Requirements for DCPEL January 2006
(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
Services", RFC 2475, December 1998.
[RFC2638] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
RFC 2638, July 1999.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, April 2001.
Mendes & Nichols Expires July 17, 2006 [Page 12]
Internet-Draft Requirements for DCPEL January 2006
Authors' Addresses
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
Mendes & Nichols Expires July 17, 2006 [Page 13]
Internet-Draft Requirements for 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.
Mendes & Nichols Expires July 17, 2006 [Page 14]
