[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-yacine-cops-an-00.txt
Hello all,
Please find herewith a new ID describing a new COPS client type for active
networks.
Thanks,
Yacine
--
Title : COPS client-type for Active Networks
Author(s) : Y. El Mghazli, O. Marce
Filename : draft-yacine-cops-an-00.txt
Pages : 9
Date : 13-Jul-01
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]).
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yacine-cops-an-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-yacine-cops-an-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-yacine-cops-an-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
-- Yacine El Mghazli
----------------------------------------------------------------------
Alcatel R&I
Software and Services Strategic Program - VIPeR
Marcoussis, France
Tel +33 1 6963 4187
Fax +33 1 6963 1169
yacine.el_mghazli@ms.alcatel.fr
----------------------------------------------------------------------
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]