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]