Network Working Group Yacine El Mghazli Internet Draft Olivier Marce Document: draft-yacine-cops-an-00.txt Alcatel Category: Experimental June 2001 Expires: December 2001 COPS client-type for Active Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [STD]. 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. Abstract This draft specifies a COPS (Common Open Policy Service, [COPS]) client-type designed for the enforcement of Active IP Networks (AN) policies. The usage of this AN COPS client-type is based upon the activation of the COPS protocol for policy provisioning purposes (COPS-PR, [COPS-PR]). El Mghazli et al. Experimental - Expires December 2001 [Page 1] Internet Draft COPS client-type for Active Networks Jun. 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 1. Introduction....................................................3 2. Terminology.....................................................4 3. Generic model of an AN policy enforcement scheme................4 4. An client-type specific information.............................5 4.1. Common Header, Client-Type....................................5 4.2. COPS messages content.........................................5 4.2.1 Request messages (REQ).......................................5 4.2.2 Decision messages (DEC)......................................5 4.2.3 Report messages (RPT)........................................6 5. COPS-PR usage of the AN client-type.............................6 6. Warning.........................................................7 7. IANA Considerations.............................................7 8. Security Considerations.........................................7 9. References......................................................7 10. Author Information and Acknowledgment..........................8 11. Full Copyright Statement.......................................8 El Mghazli et al. Experimental - Expires December 2001 [Page 2] Internet Draft COPS client-type for Active Networks Jun. 2001 1. Introduction Active networks presents a new paradigm for network service and protocol design. Based on fast growing software technologies, active network architecture provides an open programmable platform that offers users and applications the ability to customize or create new network services and protocols dynamically and to deploy them on the network infrastructure at runtime. The active networking concept offers a new perception of a network as a giant computing machine for communications. It is a network that allows application specific computation to be performed within the network. In effect, application specific processing that used to be done at end systems can be moved to execute inside the network. An active packet network is programmed through packets that contain programs or references. Those packets are called active packets. Users and applications employ active packets to describe, provision, and tailor network resources to design the desired network behaviour. An active IP network is composed of active routers. Since users are able to take advantage of network computing resource, there is a need for active packets admission control in order to prevent from any incorrect or forbidden emission of active packets which would flood or attack active routers. Within the context of this document, an active packet contains reference to downloadable code, located in a code repository or elsewhere. The actual enforcement of AN Policy is based upon the restricted usage of the network computing resource at active edge routers. The agreement reached by both the customer and the active network SP in terms of computing resource usage rights must be reflected in these nodes. From this standpoint, the COPS protocol and its usage for the support of Policy Provisioning is one of the ongoing specification effort of the Resource Allocation Protocol (rap) Working Group of the IETF that should help service providers in dynamically enforcing AN policy. To provide the edge router with the above-mentioned information, one possibility is to use the COPS protocol and its usage for policy provisioning. To do so, a new COPS client-type is specified, the Active Network client-type, and this specification effort is the purpose of this draft. The active packets can be sent prior to the flow containing the data to be processed ([ANEP]), or the data packets can be set active ([AN- OPT]. In both cases, when a PEP receives an active packet, it should outsource the decision of acceptance. This specific mechanism will be further described in a separate document. This document focuses on the provisioning of the AN policy, and does El Mghazli et al. Experimental - Expires December 2001 [Page 3] Internet Draft COPS client-type for Active Networks Jun. 2001 not care about the way this provisioning is triggered, for example by a manager, or by any kind of signalisation or even when an active packet starting a flow is received. The scope of this document is the active IP networks, and related layer 3 nodes only. It is not related at all to the policy provisioning for transmission devices. This document is organized into the following sections: - Section 3 introduces the generic architecture, - Section 4 describes the contents of the COPS messages that MUST include the AN client-type specific information, - Section 5 defines the usage of the AN client-type, including its mode of operation with the PDP (Policy Decision Point, [FRWK]) with whom a COPS communication has been established, - Finally, sections 7 and 8 introduce IANA and some security considerations, respectively. 2. Terminology 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 [KEY]. 3. Generic model of an AN policy enforcement scheme To achieve AN Policy enforcement, the customers must declare to the SP the active code they intend to use and the computing resources they need to process the corresponding code. The enforcement of an Active networks policy is based upon the use of an AN policy server (PDP) that sends AN-related information (allowed references and reserved computing resources) to the PEP embedded in the active router. Following the framework for policy-based admission control [FRWK], the PDP provides the active router (PEP) with references towards process-able code for a specific user, and it allocates computing resources the execution of referenced code. The AN client-type is specified by the PEP to the PDP, and is unique for the area covered by the Active Networks policy, so that the PEP can treat all the COPS client-types it supports as non-overlapping and independent namespaces. The AN specific information in the router is stored and maintained in the AN Policy Information Base ([AN-PIB]), which will be accessed by the PDP to retrieve and update these data whenever necessary. The AN-related information is conveyed between the PDP and the PEP El Mghazli et al. Experimental - Expires December 2001 [Page 4] Internet Draft COPS client-type for Active Networks Jun. 2001 thanks to the establishment of a COPS-PR connection between these two entities. The COPS-PR protocol assumes a named data structure (the PIB), in order to identify the type and purpose of the policy information that is sent by the PDP to the PEP for the provisioning of a given policy. Within the context of this draft, the data structure of the PIB refers to Active Networks policy that is therefore described in the PIB as a specific PIB, namely the AN-PIB. AN-PRCs are instantiated as multiple PRIs (Policy Rule Instance), each of which being identified by Policy Rule Instance Identifier (PRID). A given PRI specifies the data content carried in the COPS-PR (AN client-type specific) objects. An AN PRI typically contains a value for each attribute that has been defined for the AN PRC, for example the reference to the code to be executed and the allocated computing resources. 4. AN client-type specific information This section describes the formalism that is specific to the use of an AN client-type, given that only the COPS messages that require an AN client-type specific definition are described in this section, i.e. the other COPS messages to be exchanged between a PEP that supports the AN client-type and a PDP, and which do not need to carry AN client-type specific information are those described in the corresponding [COPS] and [COPS-PR] documents, without any further elaboration. 4.1. Common Header, Client-Type The AN COPS client type must be registered with IANA. 4.2. COPS Message Content 4.2.1. Request messages (REQ) The REQ message is sent by the PEP with an AN client-type to issue a configuration request to the PDP, as specified in the COPS Context Object. The REQ message includes the current configuration information related to the enforcement of an Active Networks policy. In the context of Active Networks, this information consists in previously installed policies and computing capabilities. It means that the PEP describes its own available computing resources in order for the PDP to provision the router accordingly. As usual, such configuration information is encoded from the AN-PIB according to the ClientSI format that is defined for the Named ClientSI object of the REQ message ([COPS-PR]). El Mghazli et al. Experimental - Expires December 2001 [Page 5] Internet Draft COPS client-type for Active Networks Jun. 2001 4.2.2. Decision messages (DEC) DEC messages typically consist in "install" and/or "remove" Decisions. They contain references towards downloadable code associated with filters in order to identify a specific user IP active flow, as well as allocated computing resources. Such information is encoded from the PIB according to the Decision format that is defined for the Named Decision Data object of the DEC message ([COPS-PR]). The details of the references and computing resources allocations is given in [AN-PIB]. 4.2.3. Report messages (RPT) The Report message allow the PEP to indicate to the PDP that a particular set of AN policy provisioning instances have been successfully or unsuccessfully installed/removed. Note that the AN related RPT messages containing report of type "Accounting" are carrying statistical information related to the usage of the active router computing resource. This statistical information MAY be used by the PDP to possibly modify the resource allocation. 5. COPS-PR usage of the AN client-type This section describes the provisioning of an AN policy enforcement. As mentioned in section 1, the manner the provisioning is triggered is not considered in this document. The Active Network paradigm is based on the assumption that the activation is carried in the data link, following the same path than data, and activating the traversed nodes. It is clear that the provisioning should be triggered by the active packets. After having opened a COPS connection with the PDP, the PEP sends a REQ message to the PDP that will contain a Client Handle. The Client Handle is used to identify a specific request state associated to the AN client-type supported by the PEP. The REQ message will contain a "Configuration Request" context object. This REQ message will also carry the named client specific information -- including the (default) configuration information, as described in section 4.2.1.of the draft. By "default" configuration information, it must be understood the default values that have been instantiated in the AN-PIB. El Mghazli et al. Experimental - Expires December 2001 [Page 6] Internet Draft COPS client-type for Active Networks Jun. 2001 The active node specific computing resources will be conveyed in specific (PRID, EPD) bindings in the REQ message as well. Upon receipt of the REQ message, the PDP will send back a DEC message towards the PEP. This DEC message will carry AN Named Decision Data object that will convey all the appropriate installation/removal of (PRID, EPD), as described in section 4.2.2 of this draft. One of the basic goals of this named Decision objects consist in allowing/making such a user to use such a reference to download a code in the node. Upon receipt of a DEC message, the PEP and the AN client-type it supports will (try to) enforce the corresponding AN decisions by installing the named AN policy data (e.g. to assign a metric value to a recently-installed interface). Then, the PEP will notify the PDP about the actual enforcement of the named AN policy decision data, by sending the appropriate RPT message back to the PDP. The RPT message MAY also carry the "Accounting" report-type, as described in section 5.2.3.of this draft. 6. Warning The Active Networks domain is emerging today and there is no adopted solution yet. Firstly, the concerns of this draft is restricted to a single way to trigger an active behavior of a network. There are other means to realize it and subsequently other means to apply policy on Active Networks. One could simply outsource a AN specific signalisation, like today RSVP messages are outsourced for admission control purposes. Secondly, even in the restricted context of this draft, specifications can slightly evolve and the AN COPS client-type would have to follow these changes. 7. IANA Considerations Section 4.1.of this draft has identified a need for the assignment of a specific number that will uniquely identify the AN client-type in every COPS message to be exchanged between a PEP and a PDP. This value SHOULD be chosen in the range of 0x8000 - 0xFFFF,according to a First Come First Served policy, as mentioned in both [COPS] and [IANA]. 8. Security Considerations This draft specifies a new client-type that will make use of the COPS protocol for the provisioning and the enforcement of AN policies El Mghazli et al. Experimental - Expires December 2001 [Page 7] Internet Draft COPS client-type for Active Networks Jun. 2001 within IP networks. As such, it introduces no new security issues over the COPS protocol itself, or its usage for policy provisioning. 9. References [STD] Bradner S.,"The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [COPS] Boyle J., Cohen R., Durham D., Herzog S., Raja R., Sastry A., "The COPS (Common Open Policy Service) Protocol", RFC 2748, Proposed Standard, January 2000. [COPS-PR] Ho Chan K., Durham D., Gai S., Herzog S., McLoghrie K., Reichmeyer F., Seligson J., Smith A., Yavatkar R., "COPS Usage for Policy Provisioning (COPS-PR)", RFC3084, March 2001. [FRWK] Yavatkar R., Pendarakis D., Guerin R., "A Framework for Policy-Based Admission Control", RFC 2753, January 2000. [ANEP] D. Scott Alexander, Bob Braden, Carl A. Gunter, Alden W. Jackson, Angelos D. Keromytis, Gary J. Minden, David Wetherall, "Active Networks Encapsulation Protocol", July 1997. [AN-OPT] David J. Wetherall, David L. Tennenhouse, "The Active IP option", September 1996. [KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [AN-PIB] , "An Active Networks Policy Information Base", Work in Progress. [IANA] Alvestrand H., Narten T., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 10. Author Information and Aknowledgement Yacine El Mghazli Alcatel R&I VIPeR Project Route de Nozay F-91460 Marcoussis France Phone : +33 1 69 63 41 87 Email : yacine.el_mghazli@ms.alcatel.fr El Mghazli et al. Experimental - Expires December 2001 [Page 8] Internet Draft COPS client-type for Active Networks Jun. 2001 Olivier Marce Alcatel R&I Active Networks Seed Project Route de Nozay F-91460 Marcoussis France Phone : +33 1 69 63 41 67 Email : olivier.marce@ms.alcatel.fr Special thanks to Nathalie Charton & Damien Galand. 11. Full Copyright Statement Copyright(C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. El Mghazli et al. Experimental - Expires December 2001 [Page 9]