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]