Network Working Group Yacine El Mghazli Internet Draft Olivier Marce Expires: December 2002 Alcatel July 2002 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 policy of Active IP Networks (AN) based on Extensible Routers (ER). 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, Marce Expires December 2002 [Page 1] Internet Draft COPS client-type for Active Networks July 2002 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 1. Introduction....................................................3 2. Glossary........................................................4 3. Terminology.....................................................4 4. Generic model of an AN policy enforcement scheme................5 5. An client-type specific information.............................5 5.1. Common Header, Client-Type....................................6 5.2. COPS messages content.........................................6 5.2.1 Request messages (REQ).......................................6 5.2.2 Decision messages (DEC)......................................6 5.2.3 Report messages (RPT)........................................6 6. COPS-PR usage of the AN client-type.............................6 7. Active Networks Policy Information..............................7 7.1. AN-PIB overview...............................................7 7.1.1. Capabilities Group..........................................7 7.1.2. Policy Group................................................8 7.2. AN PIB definition.............................................9 8. IANA Considerations............................................17 9. Security Considerations........................................18 10. References....................................................18 11. Acknowledgments...............................................19 12. Authors' Information..........................................19 13. Full Copyright Statement......................................20 El Mghazli, Marce Expires December 2002 [Page 2] Internet Draft COPS client-type for Active Networks July 2002 1. Introduction Active Networks proposes 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 service providers the ability to customize or create dynamically new network services or protocols as well as to deploy them into the network infrastructure at runtime. The Active Networking concept allows application specific computation to be performed within the network, moving from the end systems to inside network, and getting access to inner network specific available information. For achieving an Active IP Network, several flavors of Active Nodes or Routers have been proposed. At one end of the spectrum, the Programmable or Configurable Router offers to management entities a set of well-defined Application Programming Interface (API) which allow to finely tune its behavior. This is for example the IEEE P1520 approach [P1520]. At the other end, the Active Packet Routers are a kind of software shell designated to execute the code carried into Active Packets [APKT]. In this approach, each packet contains its own routing algorithm and any other needed algorithm to provide the expected services. Between these two extreme concepts, the Extensible Router approach proposes to have a router software architecture which supports the addition or replacement of software modules. In this document, an Active Network is considered to be composed of Extensible Routers. An Extensible Router contains one or more Execution Environment (EE) where the code of the software module is executed. The same EE can be used for the execution of both the additional software modules and the legacy router software. Nevertheless, it is expected that a clear and safe separation of the execution of code between the legacy part and the extensible part is better achieved by the use of a one or more specialized EE for the additional modules. The triggering of the addition or the update of software modules can be done in different ways [AN-OPT][ANEP]. In this document, the considered solution is based on the embedding of a reference to the software module to be added or updated in a packet which needs to be specifically processed by an Extensible Router. The instantiation of the software module is a downloadable code, which is located in a code repository or elsewhere. When the Extensible Router receives a packet with software module reference, it downloads it if needed, and initiate its execution, feeding the received packet as input of the execution. The other packets with same software module reference will be processed by the same instantiation. Then, users and service providers request for software module update to design the desired network behavior. El Mghazli, Marce Expires December 2002 [Page 3] Internet Draft COPS client-type for Active Networks July 2002 Since users or third party are able to take advantage of network computing resource, there is the need both for admission control of packets with software module reference in order to prevent from any incorrect or forbidden emission of such packets which would flood or attack Extensible Routers, and to allocate resources to the execution of the software module. The actual enforcement of AN Policy is based upon the restriction of usage of the network computing resource at compliant edge routers, and the provisioning of needed computing resources into the Extensible Routers. The agreement reached by both the customer and the network SP offering Extensible Router features in terms of computing resource usage rights must be reflected in the edge 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. This document focuses on the provisioning of the AN policy, and does not care about the way this provisioning is triggered, for example by a manager, or by any kind of signaling or even when a packet with software module reference starting a flow is received. In this last case, the Extensible Router should outsource the decision of acceptance. These specific mechanims will be further described in a separate document. 2. Glossary AN Active Network PEP Policy Enforcement Point PDP Policy Decision Point COPS Common Open Policy Service PIB Policy Information Base PRC PRovisioning Class PRI PRovisioning Instance EE Execution Environment ER Extensible Router 3. 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]. El Mghazli, Marce Expires December 2002 [Page 4] Internet Draft COPS client-type for Active Networks July 2002 4. Generic model of an AN policy enforcement scheme To achieve AN Policy enforcement, the customers MUST declare to the SP the software modules they intend to use and the computing resources they need to use these software modules. The enforcement of an Extensible Router policy is based upon the use of an AN policy server (PDP) that sends AN-related information (allowed module references and reserved computing resources) to the PEP embedded in the Extensible Router. Following the framework for policy-based admission control [FRWK], the PDP provides the Extensible Router (PEP) with process-able code corresponding to the software module, and it allocates computing resources for 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-related information is conveyed between the PDP and the PEP 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 AN 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. 5. 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. El Mghazli, Marce Expires December 2002 [Page 5] Internet Draft COPS client-type for Active Networks July 2002 5.1. Common Header, Client-Type The AN COPS client type must be registered with IANA. 5.2. COPS Message Content 5.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, executable installed codes and computing capabilities. It means that the PEP describes its own available computing resources in order to let 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]). 5.2.2. Decision messages (DEC) DEC messages typically consist in "install" and/or "remove" Decisions. They contain the address where to retrieve from and the Id of code to be executed, associated with filters in order to identify a specific user IP to be processed flow, as well as the 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 are given in section 7. 5.2.3. Report messages (RPT) The Report messages allow the PEP to indicate to the PDP that a particular set of AN policy provisioning instances have been successfully or unsuccessfully installed or removed. Note that the AN related RPT messages containing report of type "Accounting" are carrying statistical information related to the usage of the Extensible Router computing resource. This statistical information MAY be used by the PDP to possibly modify the resource allocation. 6. COPS-PR usage of the AN client-type El Mghazli, Marce Expires December 2002 [Page 6] Internet Draft COPS client-type for Active Networks July 2002 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. 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. The Extensible Router specific computing resources will be conveyed in specific (PRID, EPD) bindings in the REQ message as well. This information describes the capability of the Extensible Router for executing the code of the requested software modules. 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 execute a code in the node, with the appropriate computing resources, and on the allowed flows of packets. 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. 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. 7. Active Networks Policy Information Base 7.1. AN-PIB Overview 7.1.1 Capabilities Group This group contains the description of the capabilities of the Extensible Router. This information is sent to the PDP when the connection is initiated. Based on this, the PDP decides of the policy to apply. El Mghazli, Marce Expires December 2002 [Page 7] Internet Draft COPS client-type for Active Networks July 2002 This group is intentionaly restricted to a single table, with the objective to be further completed in a next version of the draft. Execution Environments Capabilities Table This table describes the Execution Environments, and the supported APIs for each EE that the Extensible Router supports. This is used by the PDP to select the correct code that the router will download. It uses the same ID for EE and APIs than those used in the Policy Group. 7.1.2 Policy Group This group describes the policy to apply by the PEP. Function Table This table contains identification of the codes to execute on the node. A function is the execution of one instance of a code (i.e. a given code can give birth to different functions). In the PIB, a function is associated with an Execution Environment (EE) id. This allows the Extensible Router to start the execution of the code into the corresponding EE. The function is also associated with a Group of Function id which allows to set common parameters to different functions. This is for example the case, when the computing resources are allocated based on the id of the sender of the packets with reference. In this case, all the codes executed on behalf of a given user will be allocated to the same computing resources. APIs Table When executed into the node, a code can request to get access to the legacy routing system of the router. This is done through a set of APIs. The COPS-AN allows to restrict the APIs offered to a function. The API are uniquely identified in the name space of the EE id. Their identification is under the responsibility of the EE provider. Flows table When a code is executed, it is allowed to take as input a set of flows of packets, and to generate other flows of packets. The authorized flows are defined thanks to the COPS Framework flows definitions. This is related to the input and the output of the application only, and not to the setting up of filters (which is done thanks to APIs). Resources table El Mghazli, Marce Expires December 2002 [Page 8] Internet Draft COPS client-type for Active Networks July 2002 This describes the amount of computing resources allocated to the execution of a code. The considered parameters in this version are the number of Mbytes of allocated memory to the application, the maximum numbers of CPU cycles and times that the applications must not exceed, and the maximum number of bytes per second that the application is allowed to output. 7.2. AN-PIB definition AN-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, Integer32, MODULE-IDENTITY, MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib, TEXTUAL-CONVENTION FROM COPS-PR-SPPI InstanceId, TagId, TagReferenceId, ReferenceId FROM COPS-PR-SPPI-TC InetAddress, InetAddressType FROM INET-ADDRESS-MIB; anPolicyPib MODULE-IDENTITY SUBJECT-CATEGORIES { an(tbd) } -- AN COPS Client Type -- to be assigned by IANA LAST-UPDATED "200206201800Z" ORGANIZATION "IETF" CONTACT-INFO " Yacine El Mghazli Alcatel R&I Route de Nozay F-91460 Marcoussis - FRANCE Phone: +33 1 69 63 41 87 Email: yacine.el_mghazli@alcatel.fr Olivier Marce Alcatel Route de Nozay F-91460 Marcoussis - FRANCE Phone : +33 1 69 63 41 67 Email : Olivier.Marce@alcatel.fr" DESCRIPTION "The PIB module containing a set of provisioning classes that describe active networks policies. It includes general classes that may be extended by other PIB specifications as well as a set of PIB classes related to ANs." REVISION "200206201800Z" DESCRIPTION "Initial version, published as RFC xxxx." ::= { pib xxx } -- xxx to be assigned by IANA -- AN specific Textual Conventions. El Mghazli, Marce Expires December 2002 [Page 9] Internet Draft COPS client-type for Active Networks July 2002 -- AN PIB module anCapabilityClasses OBJECT IDENTIFIER ::= { anPolicyPib 1 } anPolicyClasses OBJECT IDENTIFIER ::= { anPolicyPib 2 } anFeedbackClasses OBJECT IDENTIFIER ::= { anPolicyPib 3 } anPibConformance OBJECT IDENTIFIER ::= { anPolicyPib 4 } -- AN Capabilities -- -- AN Execution Capabilities -- anExecCapsTable OBJECT-TYPE SYNTAX SEQUENCE OF AnExecCapsEntry PIB-ACCESS notify STATUS current DESCRIPTION "This class represents the execution capabilities of a Extensible Router (ER)." ::= { anCapabilityClasses 1 } anExecCapsEntry OBJECT-TYPE SYNTAX AnExecCapsEntry STATUS current DESCRIPTION "An instance of the anExecCaps class. It uses the same ID for EE and APIs than in the Policy Group." PIB-INDEX { anExecCapsPrid } ::= { anExecCapsTable 1 } anExecCapsEntry ::= SEQUENCE { anExecCapsPrid InstanceId, anExecCapsEeId Integer, anExecCapsApiId Integer } anExecCapsPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the class." ::= { anExecCapsEntry 1 } anExecCapsEeId OBJECT-TYPE El Mghazli, Marce Expires December 2002 [Page 10] Internet Draft COPS client-type for Active Networks July 2002 SYNTAX Integer STATUS current DESCRIPTION "This attribute uniquely identify an EE supported by the ER. This must be registered to the ANANA." ::= { anExecCapsEntry 2 } anExecCapsApiId OBJECT-TYPE SYNTAX Integer STATUS current DESCRIPTION "This attribute uniquely identifies an API supported by an EE. This value is meaningful and unique in the EE namespace only." ::= { anExecCapsEntry 3 } -- AN Policy Classes -- -- AN Function Table -- anFunctionTable OBJECT-TYPE SYNTAX SEQUENCE OF AnFunctionEntry PIB-ACCESS install STATUS current DESCRIPTION "This class contains the configuration parameters related to an active application" ::= { anPolicyClasses 1 } anFunctionEntry OBJECT-TYPE SYNTAX AnFunctionEntry STATUS current DESCRIPTION "Each entry in the Function table represents an active application" PIB-INDEX { anFunctionPrid } UNIQUENESS { anFunctionId, anFunctionEeId, anFunctionResId } ::= { anFunctionTable 1 } anFunctionEntry ::= SEQUENCE { anFunctionPrid InstanceId, anFunctionId TagReferenceId, anFunctionEeId Integer, anFunctionResId TagId, anFunctionCodeServerAddr InetAddress, anFunctionCodeServerAddrType InetAddressType, anFunctionCodeId Integer } El Mghazli, Marce Expires December 2002 [Page 11] Internet Draft COPS client-type for Active Networks July 2002 anFunctionPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the class." ::= { anFunctionEntry 1 } anFunctionId OBJECT-TYPE SYNTAX TagReferenceId PIB-TAG { anApiEntry } STATUS current DESCRIPTION "." ::= { anFunctionEntry 2 } anFunctionEeId OBJECT-TYPE SYNTAX Integer STATUS current DESCRIPTION "This attribute uniquely identify the EE is required to support the Active Application. This must be registered to the ANANA." ::= { anFunctionEntry 3 } anFunctionResId OBJECT-TYPE SYNTAX TagId STATUS current DESCRIPTION "This attribute uniquely identifies the Active Application group, which this application is member of." ::= { anFunctionEntry 4 } anFunctionCodeServerAddr OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "This is the IP address of the server from where the Extensible Router is allowed to download the executable code." ::= { anFunctionEntry 5 } anFunctionCodeServerAddrType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "This is the IP address type of the server. " ::= { anFunctionEntry 6 } anFunctionCodeId OBJECT-TYPE SYNTAX Integer STATUS current El Mghazli, Marce Expires December 2002 [Page 12] Internet Draft COPS client-type for Active Networks July 2002 DESCRIPTION "This is the ID of the code that the Extensible Router is allowed to download from the Code Server. This ID has a local meaning" ::= { anFunctionEntry 7 } -- -- AN API Table -- anApiTable OBJECT-TYPE SYNTAX SEQUENCE OF AnApiEntry PIB-ACCESS install STATUS current DESCRIPTION "This class contains a list of APIs requested by each active aplication." ::= { anPolicyClasses 2 } anApiEntry OBJECT-TYPE SYNTAX AnApiEntry STATUS current DESCRIPTION "An entry of this table is created for each API supported by an active application." PIB-INDEX { anApiPrid } ::= { anApiTable 1 } anApiEntry ::= SEQUENCE { anApiPrid InstanceId, anApiId Integer, anApiFunctionId TagId } anApiPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the class." ::= { anApiEntry 1 } anApiId OBJECT-TYPE SYNTAX Integer STATUS current DESCRIPTION "This attribute uniquely identifies an API. This value is meaningful and unique in the application EE ID namespace only." ::= { anApiEntry 2 } anApiFunctionId OBJECT-TYPE SYNTAX TagId El Mghazli, Marce Expires December 2002 [Page 13] Internet Draft COPS client-type for Active Networks July 2002 STATUS current DESCRIPTION "This attribute identifies which active application is associated to this API." ::= { anApiEntry 3 } -- -- AN Flow Table -- anFlowTable OBJECT-TYPE SYNTAX SEQUENCE OF AnFlowEntry PIB-ACCESS install STATUS current DESCRIPTION "This class contains a list of flow descriptors associated with an active application." ::= { anPolicyClasses 3 } anFlowEntry OBJECT-TYPE SYNTAX AnFlowEntry STATUS current DESCRIPTION "An entry in this table is created for each flow filtered/generated by an active application." PIB-INDEX { anFlowPrid } EXTENDS { frwkIpFilterEntry } ::= { anFlowTable 1 } anFlowEntry ::= SEQUENCE { anFlowFunctionId TagId, anFlowType Integer } anFlowFunctionId OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES { anFunctionEntry } STATUS current DESCRIPTION "This attribute identifies which active application is associated to this flow." ::= { anFlowEntry 1 } anFlowType OBJECT-TYPE SYNTAX Integer { filtered (0), generated (1) } STATUS current DESCRIPTION "Either a flow generated (0) or filtered (1) by the active application" ::= { anFlowEntry 2 } El Mghazli, Marce Expires December 2002 [Page 14] Internet Draft COPS client-type for Active Networks July 2002 -- -- AN Resource Table -- anResourceTable OBJECT-TYPE SYNTAX SEQUENCE OF AnResourceEntry PIB-ACCESS install STATUS current DESCRIPTION "This class describes the resource allocated to a set of active aplications." ::= { anPolicyClasses 4 } anResourceEntry OBJECT-TYPE SYNTAX AnResourceEntry STATUS current DESCRIPTION "An entry in this table is created by the provider for every RESOURCE capable of supporting AN." PIB-INDEX { anResourcePrid } UNIQUENESS { anResourceId } ::= { anResourceTable 1 } anResourceEntry ::= SEQUENCE { anResourcePrid InstanceId, anResourceId TagReferenceId, anResourceMem Integer, anResourceCycles Integer, anResourceMaxLife Integer, anResourceOutBw Integer } anResourcePrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the class." ::= { anResourceEntry 1 } anResourceId OBJECT-TYPE SYNTAX TagReferenceId PIB-TAG { anFunctionResId } STATUS current DESCRIPTION "This attribute uniquely identifies the set of active applications for which the resource are allocated." ::= { anResourceEntry 2 } anResourceMem OBJECT-TYPE SYNTAX Integer STATUS current DESCRIPTION El Mghazli, Marce Expires December 2002 [Page 15] Internet Draft COPS client-type for Active Networks July 2002 "This attribute is the number of MBytes of memory required by the Application." ::= { anResourceEntry 3 } anResourceCycles OBJECT-TYPE SYNTAX Integer STATUS current DESCRIPTION "This attribute is the number of CPU cycles that the Active Application is not able to exceed." ::= { anResourceEntry 4 } anResourceMaxLife OBJECT-TYPE SYNTAX Integer STATUS current DESCRIPTION "This attribute represents the maximum time (in milliseconds) an AA can run." ::= { anResourceEntry 5 } anResourceOutBw OBJECT-TYPE SYNTAX Integer STATUS current DESCRIPTION "This attribute is the maximum number of bytes per seconds that an AA can output." ::= { anResourceEntry 6 } -- AN Feedback Classes --tbd -- Conformance Section anPibCompliances OBJECT IDENTIFIER ::= { anPibConformance 1 } anPibGroups OBJECT IDENTIFIER ::= { anPibConformance 2 } anPibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the AN Policy PIB." MODULE -- this module MANDATORY-GROUPS { anPibFunctionGroup, anPibApiGroup, anPibFlowGroup, anPibResourceGroup } ::= { anPibCompliances 1 } El Mghazli, Marce Expires December 2002 [Page 16] Internet Draft COPS client-type for Active Networks July 2002 anPibFunctionGroup OBJECT-GROUP OBJECTS { anFunctionId, anFunctionEeId, anFunctionResId, anFunctionCodeServerAddr, anFunctionCodeServerAddrType, anFunctionCodeId } STATUS current DESCRIPTION "The Function Group defines the PIB Objects that describe an active application." ::= { anPibGroups 1 } anPibApiGroup OBJECT-GROUP OBJECTS { anApiId, anApiFunctionId } STATUS current DESCRIPTION "The Api Group defines the PIB Objects that describe an API supported by an active application." ::= { anPibGroups 2 } anPibFlowGroup OBJECT-GROUP OBJECTS { anFlowFunctionId, anFlowType } STATUS current DESCRIPTION "The Flow Group defines the PIB Objects that describe a flow." ::= { anPibGroups 3 } anPibResourceGroup OBJECT-GROUP OBJECTS { anResourceId, anResourceMem, anResourceCycles, anResourceMaxLife, anResourceOutBw } STATUS current DESCRIPTION "The Resource Group defines the PIB objects that describe a resource set." ::= { anPibGroups 4 } END 8. IANA Considerations El Mghazli, Marce Expires December 2002 [Page 17] Internet Draft COPS client-type for Active Networks July 2002 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]. 9. 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 within IP networks. As such, it introduces no new security issues over the COPS protocol itself, or its usage for policy provisioning. Security issues are raised by the Active Network concept which offers computing resources to network users and service providers. The use of COPS AN addresses this issue, by allowing network SP to control the use of the network computing resources and the amount of resources allowed to the applications, and to provide the code to be executed in each nodes. 10. 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. [IANA] Alvestrand H., Narten T., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. El Mghazli, Marce Expires December 2002 [Page 18] Internet Draft COPS client-type for Active Networks July 2002 [P1520] Proposed IEEE Standard for Application Programming Interfaces for Networks, http://www.ieee-pin.org/ [APKT] Jonathan T. Moore. "Practical Active Packets," Ph.D. Dissertation Proposal, University of Pennsylvania, February 2001 11. Acknowledgements Special thanks to N.Charton, Z.Zidane, D.Galand. 12. Authors' addresses Yacine El Mghazli Alcatel Route de Nozay F-91460 Marcoussis France Phone : +33 1 69 63 41 87 Email : yacine.el_mghazli@alcatel.fr Olivier Marce Alcatel Route de Nozay F-91460 Marcoussis France Phone : +33 1 69 63 41 67 Email : Olivier.Marce@alcatel.fr 13. 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 El Mghazli, Marce Expires December 2002 [Page 19] Internet Draft COPS client-type for Active Networks July 2002 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, Marce Expires December 2002 [Page 20]