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]