Diffserv Control Plane Elements (DCPEl) Strawman
post to mailing list: dcpel@ietf.org
information at: https://www1.ietf.org/mailman/listinfo/dcpel
Goals:
It's been some time since the Diffserv forwarding path elements were
standardized. At that time, the approach was to get the mechanisms
deployed in routers so that approaches to service creation and control
plane could be attempted. Before closing, the Diffserv WG defined
the concept of Per-Domain Behaviors (PDBs) in RFC 3086, but left the
approach to controling PDBs open.
Now Diffserv forwarding elements are available in most routers and
are in use to create services in some networks. A variety of approaches
are being used for control and management of Diffserv but there appears
to be some commonality. A possible path for IETF work is to enumerate
and classify the common elements and to work toward some best common
practices. Additionally, it may be useful to present specifications
for a range of diffserv control plane elements using common interfaces.
The major issues to deploying Diffserv-based services are primarily
operational. The deployment must be cost-effective, be secured against
vulnerabilities and not become a vehicle for denial of service attacks.
Standardization should result in existing toolsets being either expanded
to cover more needed functionality or to interact with other tools.
A standardization effort should cover how to secure the architecture
to mitigate vulnerabilities. Standards for a control plane QoS agent
for routers may be useful. A desired outcome of IETF efforts is to
make multiple products available to network operators, obviating the
time and personnel expense of individual solutions. The end goal is
to enable more services, both for network customers and for control
of the network, without taxing personnel.
The starting point for a BoF is to look at what's out there, determine
if there is indeed some uniformity of approach useful as a starting
point, and determine what's missing.
The intial focus would be the intradomain control plane moving to
interdomain or AS under same provider and finally to interprovider
or interoperator.
Proposed itinerary
- Present the goal of a possible WG through presentation of a strawman
enumeration of common elements of all Diffserv CPs. This may include
examples, commercial and research, of diffserv control planes or elements
thereof.
- Discussion of whether these (some) elements need standardization or
better if options presented in informationals or not at all. Do the
strawman common elements hold up, if this is useful, which might require
standardization - are these the right elements? require standardization?
useful to have set of standards? Best proprietary?
- Is categorization of the capabilities of diffserv forwarding path
mechanisms also needed?
- Is there other IETF work that applies?
- Close with checking for consensus on WG goals, different goals, no
WG?
Strawman elements
- Network state / resource map - include path control approaches or
path awareness (databases), query language
- "server" / allocator / QoS service
- Control and configuration of edge (CP to edge devices)
- Provisioning approaches / set up
- signaling/messaging protocol(s) - host/user/originator to CP and interdomain
CP communication
- performance monitoring
- policy repository - DB, query language, etc
- authentication of requesters - credentials, certificates, etc
- a QoS agent for routers - setting FP elements in response to CP messages
Example Products and Projects Useful for Diffserv Control
- Operax
- Allot
- Grid approach to BB, authentication
- Intelliden
- IPsum, PacketDesign
- Telcordia BB
- PacketCable
- Cariden
Example Service Products Using Diffserv Control
File translated from
TEX
by
TTH,
version 3.70.
On 28 Sep 2005, 23:01.