SMIng Working Group Harsha Hegde
Internet Draft Ravi Sahita
Expiration: January 2002 Intel
SMIng Mappings to COPS-PR
draft-ietf-sming-copspr-01.txt
July 2001
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Conventions used in this document
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 [KEYWORD].
Abstract
This memo presents an SMIng language extension that supports the
mapping of SMIng definitions of identities, classes, and their
attributes to dedicated definitions of nodes and tables for
application in the policy based management framework [RAP-FRWK]
using COPS-PR [COPS-PR].
[Page 1]
Internet Draft SMIng COPSPR Mapping July 2001
Table of Contents
Status of this Memo................................................1
Conventions used in this document..................................1
Abstract...........................................................1
2. Policy Based Management using COPS-PR...........................4
3. SMIng Data Type Mappings........................................5
3.1 ASN.1 Definitions..............................................6
4. Semantics of COPS-PR mappings...................................6
4.1. The copspr Extension Statement................................6
4.2. The oid Statement.............................................7
4.3. The clienttype Statement......................................7
4.4. The node Statement............................................7
4.4.1. The node's oid Statement....................................7
4.4.2. The node's represents Statement.............................7
4.4.3. The node's status Statement.................................8
4.4.4. The node's description Statement............................8
4.4.5. The node's reference Statement..............................8
4.4.6. Usage Example...............................................8
4.5. The prc Statement.............................................8
4.5.1. The prc's oid Statement.....................................9
4.5.2. The prc's anyindex Statement................................9
4.5.2.1. The pibindex Statement....................................9
4.5.2.2. The augments Statement....................................9
4.5.2.3. The extends Statement.....................................9
4.5.3. The prc's implements Statement..............................9
4.5.3.1. The implements' implobject Statement.....................10
4.5.3.1.1. The implobject's pibreference Statement................10
4.5.3.1.2. The implobject's pibtag Statement......................10
4.5.4. The prc's status Statement.................................10
4.5.5. The prc's description Statement............................11
4.5.6. The prc's reference Statement..............................11
4.5.7. The prc's pibaccess Statement..............................11
4.5.8. The prc's piberrors Statement..............................11
4.5.9. Usage Example..............................................12
4.6. The group Statement..........................................12
4.6.1. The group's oid Statement..................................12
4.6.2. The group's members Statement..............................12
4.6.3. The group's status Statement...............................12
4.6.4. The group's description Statement..........................13
4.6.5. The group's reference Statement............................13
4.6.6. Usage Example..............................................13
4.7. The compliance Statement.....................................13
4.7.1. The compliance's oid Statement.............................13
4.7.2. The compliance's status Statement..........................14
4.7.3. The compliance's description Statement.....................14
4.7.4. The compliance's reference Statement.......................14
4.7.5. The compliance's mandatory Statement.......................14
4.7.6. The compliance's optional Statement........................14
4.7.6.1. The optional's description Statement.....................15
4.7.7. The compliance's refine Statement..........................15
4.7.7.1. The refine's installtype Statement.......................15
4.7.7.2. The refine's pibminaccess Statement......................15
Hegde, Sahita Expires January 2002 [Page 2]
Internet Draft SMIng COPSPR Mapping July 2001
4.7.7.3. The refine's description Statement.......................16
4.7.8. Usage Example..............................................16
5. IETF-SMING-COPSPR-EXT..........................................16
6. IETF-SMING-COPSPR..............................................21
7. Security Considerations........................................24
8. Acknowledgements...............................................24
9. Authors' Addresses.............................................24
10. References....................................................24
Hegde, Sahita Expires January 2002 [Page 3]
Internet Draft SMIng COPSPR Mapping July 2001
1. Introduction
This memo presents an SMIng language extension that supports the
mapping of SMIng definitions of identities, classes, and their
attributes to dedicated definitions of nodes and tables for
application in the Policy Based Management framework [RAP-FRWK]
using COPS-PR [COPS-PR].
Section 2 introduces basics of the Policy Based Management using
COPS-PR.
Section 3 defines how SMIng data types are mapped to the data types
supported by the COPS-PR protocol. It introduces some new ASN.1
definitions, which are used to represent new SMIng base types such
as floats in the COPS-PR protocol.
Section 4 describes the semantics of the COPS-PR mapping extensions
for SMIng.
Section 5 presents the formal SMIng specification of the extension.
Section 6 contains a SMIng module that defines data types that are
specific to the COPS-PR mapping.
2. Policy Based Management using COPS-PR
COPS [COPS] is a query/response protocol that allows policy servers
to communicate policy decisions to network devices. A Policy server
is a PDP (Policy Decision Point) and a network device (policy
client) is a PEP (Policy Enforcement Point).
COPS supports two models for policy control: Outsourcing and
Configuration.
Outsourcing model addresses the kind of events at the PEP that
require an instantaneous policy decision. In the outsourcing model,
the PEP delegates responsibility to a PDP to make decisions on its
behalf.
In the configuration model, the PDP proactively provision the PDP
with the necessary policy information, so that decisions are made or
actions are taken right at the PEP. The provisioning may be
performed in bulk (e.g., entire router QoS configuration) or in
small portions (e.g., updating a access filter on a network device).
COPS Usage for Policy Provisioning (COPS-PR) protocol describes how
base COPS protocol is used for provisioning (configuration model).
In COPS-PR, policy requests describe the PEP and its configurable
parameters. If a change occurs in the parameters, an updated request
is sent. Decisions are not necessarily mapped directly to requests,
and are issued mostly when the PDP responds to external events or
PDP events such as policy updates.
Hegde, Sahita Expires January 2002 [Page 4]
Internet Draft SMIng COPSPR Mapping July 2001
The data carried by COPS-PR is in the form of a tree structured
information store known as Policy Information Base (PIB). The PIB is
a conceptual tree namespace of Provisioning Classes (PRCs) and
Provisioning Instances (PRIs). There may be multiple instances
(PRIs) of any PRC. The tree is shown in the figure below.
-------+-------+----------+---PRC--+--PRI
| | | +--PRI
| | |
| | +---PRC-----PRI
| |
| +---PRC--+--PRI
| +--PRI
| +--PRI
| +--PRI
| +--PRI
|
+---PRC---PRI
Figure 1: A PIB Definition Tree
PIB modules are written using an adapted subset of SNMP's Structure
of Management Information (SMI) [SMIV2]. This structure of Policy
Provisioning Information is defined in [SPPI].
3. SMIng Data Type Mappings
The SMIng base types are mapped to the COPS-PR base types according
to the following table:
SMIng Data Type COPS-PR Base Type Comments
--------------- ----------------- --------
OctetString OctetString
Pointer Prid/ReferenceId (1)
Integer32 Integer32
Unsigned32 Unsigned32
Integer64 Integer64
Unsigned64 Unsigned64
Float32 Float32 (2)
Float64 Float64 (2)
Float128 Float128 (2)
Enumeration Integer32
Bits OctetString
Counter32 Unsigned32 (3)
Counter64 Unsigned64 (3)
TimeTicks TimeTicks
IpAddress IpAddress
Opaque Opaque (4)
(1) Prid and ReferenceId (SPPI specific data types) are pointers to
a specific PRI (an instance of PRC). For more description see
Hegde, Sahita Expires January 2002 [Page 5]
Internet Draft SMIng COPSPR Mapping July 2001
section 6.
(2) This type is encoded according to the ASN.1 type with the same
name defined in Section 3.1. Please note that SPPI does not
have an opaque data type. This is a protocol mapping and COPS-PR
can carry the types defined in Section 3.1.
(3) Counters are mapped to their respective Unsigned Integer types.
(4) This type is encoded according to the ASN.1 type with the same
name defined in Section 3.1.Please note that SPPI does not have
an opaque data type.
3.1 ASN.1 Definitions
The ASN.1 [ASN1] type definitions below introduce data types that
are used to map new SMIng base types into the set of ASN.1 types
supported by the COPS-PR protocol.
IETF-SMING-COPSPR-MAPPING DEFINITIONS ::= BEGIN
Opaque ::=
[APPLICATION 4]
IMPLICIT OCTET STRING
Float32
[APPLICATION 12]
IMPLICIT OCTET STRING (SIZE (4))
Float64
[APPLICATION 13]
IMPLICIT OCTET STRING (SIZE (8))
Float128
[APPLICATION 14]
IMPLICIT OCTET STRING (SIZE (16))
END
The definitions of the floating-point types Float32, Float64 and
Float128 are consistent with the same definitions in [SNMP-MAP].
4. Semantics of COPS-PR mappings
All the statements in the COPS-PR mapping are explained in this
section. Please note that a majority of the statements are similar
to the statements that are in SMIng to SNMP mapping [SNMP-MAP] as
the SPPI definition for use in COPS-PR is very similar to SMI
definition for SNMP.
4.1. The copspr Extension Statement
Hegde, Sahita Expires January 2002 [Page 6]
Internet Draft SMIng COPSPR Mapping July 2001
The 'copspr' statement is the main statement of the COPS-PR mapping
specification. It gets one or two arguments: an optional lowercase
identifier that can specify a node that represents the module's
identity, and a mandatory statement block that contains all details
of COPS-PR mapping. A single SMIng module must not contain more than
one 'copspr' statement.
4.2. The oid Statement
The copspr's 'oid' statement, which must be present, if the 'copspr'
statement contains a module identifier and must be absent otherwise,
gets one argument that specifies the object identifier value that is
assigned to the module's identity node.
4.3. The clienttype Statement
The copspr's 'clienttype' statement, which must be present,
identifies one or more categories of provisioning data for which
this PIB module defines provisioning information. For use with the
COPS-PR protocol, the individual categories are mapped to COPS
Client Types [COPS-PR]. The categories are identified either:
- Via the keyword "all", indicating the PIB module defines
provisioning information relevant for all COPS client-types, or
- As a list of named-number enumerations, where each number, which
must be greater than zero, identifies a COPS client-type. The
namespace for these named numbers is global and therefore the labels
should be assigned consistently across PIB modules. At present
time, no more than one named-number enumeration should be specified.
4.4. The node Statement
The 'node' statement is used to name and describe a node in the
object identifier tree, without associating any class or attribute
information with this node. This may be useful to group definitions
in a sub-tree of related management information, or to uniquely
define a SMIng 'identity' to be referenced in attributes of type
Pointer. The 'node' statement gets two arguments: a lower-case node
identifier and a statement block that holds detailed node
information in an obligatory order.
See the 'nodeStatement' rule of the SMIng grammar (Section 5) for
the formal syntax of the 'node' statement.
4.4.1. The node's oid Statement
The node's 'oid' statement, which must be present, gets one
argument, which specifies the object identifier value that is
assigned to this node.
4.4.2. The node's represents Statement
Hegde, Sahita Expires January 2002 [Page 7]
Internet Draft SMIng COPSPR Mapping July 2001
The node's 'represents' statement, which need not be present, makes
this node represent an SMIng identity, so that objects of type
Pointer can reference that identity. The statement gets one argument
that specifies the identity name.
4.4.3. The node's status Statement
The node's 'status' statement, which need not be present, gets one
argument, which is used to specify whether this node definition is
current or historic. The value 'current' means that the definition
is current and valid. The value 'obsolete' means the definition is
obsolete and should not be implemented and/or can be removed if
previously implemented. While the value 'deprecated' also indicates
an obsolete definition, it permits new/continued implementation in
order to foster interoperability with older/existing
implementations.
If the 'status' statement is omitted, the status value 'current' is
implied.
4.4.4. The node's description Statement
The node's 'description' statement, which need not be present, gets
one argument, which is used to specify a high-level textual
description of this node.
It is RECOMMENDED to include all semantics and purposes of this
node.
4.4.5. The node's reference Statement
The node's 'reference' statement, which need not be present, gets
one argument, which is used to specify a textual cross-reference to
some other document, either another module which defines related
definitions, or some other document which provides additional
information relevant to this node.
4.4.6. Usage Example
node zeroDotZero {
oid 0.0;
represents IETF-SMING::null;
description "A value used for null identifiers.";
};
4.5. The prc Statement
The 'prc' statement is used to define the mapping of one or more
classes to a single COPS-PR PRC (PRovisioning Class). Provisioning
class instances are called PRIs. The 'prc' statement gets two
arguments: a lower-case PRC identifier and a statement block that
Hegde, Sahita Expires January 2002 [Page 8]
Internet Draft SMIng COPSPR Mapping July 2001
holds detailed mapping information of this PRC in an obligatory
order.
See the 'prcStatement' rule of the SMIng grammar (Section 5) for the
formal syntax of the 'prc' statement.
4.5.1. The prc's oid Statement
The prc's 'oid' statement, which must be present, gets one argument,
which specifies the object identifier value that is assigned to this
PRC.
4.5.2. The prc's anyindex Statement
The prc's 'anyindex' statement consists of three types of index
statement that define the type of the PRC. This statement must be
present and only one type of index is allowed in a PRC definition.
The three types of index statements are described below.
4.5.2.1. The pibindex Statement
The 'pibindex' statement is included in definition of a base PRC. It
takes one argument that identifies the attribute that is of type
'InstanceId'.
InstanceId identifies a particular instance of a PRC. InstanceId is
a typedef described in section 6. As every base PRC definition,
except one that uses augments or extends, must have an InstanceId
attribute, it is added as the first attribute of the base PRC.
Hence, it is not included in the SMIng COPS-PR mapping definition
below in section 5. A PRC that augments or extends will not have
this InstanceId.
4.5.2.2. The augments Statement
The 'augments' statement is included in definition of a augmented
PRC. This PRC definition augments a base PRC definition. It takes
one argument that identifies the class that it augments.
4.5.2.3. The extends Statement
The 'extends' statement is included in definition of a sparsely
augmented PRC. This PRC definition sparsely augments a base PRC
definition. It takes one argument that identifies the class that it
sparsely augments.
For more detailed explanation of usage of the above three index
statements, please see [SPPI].
4.5.3. The prc's implements Statement
The prc's 'implements' statement, which must be present at least
once, makes this PRC contain columnar objects that are defined by a
Hegde, Sahita Expires January 2002 [Page 9]
Internet Draft SMIng COPSPR Mapping July 2001
given class. It gets two arguments: the class being implemented and
a statement block that holds detailed information on the attributes
of that class being implemented in an obligatory order.
It is possible to apply multiple implements statements to a single
prc statement, each specifying a class. However, to add new
attributes (that are added after a revision) from a class that is
already implemented, it is possible to have multiple implements
statements specifying the same class. This is needed to preserve the
order of attributes existing prior to addition of the new
attributes.
4.5.3.1. The implements' implobject Statement
The 'implobject' statement, which must be present at least once,
adds the single attribute of the class as a columnar object in the
PRC. It gets one argument: the class attribute being implemented.
Optionally, the attribute can be qualified with either a
'pibreference' statement or 'pibtag' statement.
4.5.3.1.1. The implobject's pibreference Statement
The 'pibreference' statement, which need not be present, is used to
qualify the attribute as a 'ReferenceId'. For details about
ReferenceId, please see section 6. It gets one argument, which is
the name of the prc that is referenced by this pointer.
4.5.3.1.2. The implobject's pibtag Statement
The 'pibtag' statement, which need not be present, is used to
qualify the attribute as a 'TagReference'. For details about
TagReference, please see section 6. This statement gets one
argument, which is the name of the attribute in another class, which
MUST be of type 'TagId'. For details about TagId, please see section
6. Note that the SMIng currently does not support syntax to define
groups of instances of a class contained as an attribute in another
class. The TagId and TagReference semantics allow us to do that, and
this mapping includes that ability.
4.5.4. The prc's status Statement
The prc's 'status' statement, which need not be present, gets one
argument, which is used to specify whether this PRC definition is
current or historic. The value 'current' means that the definition
is current and valid. The value 'obsolete' means the definition is
obsolete and should not be implemented and/or can be removed if
previously implemented. While the value 'deprecated' also indicates
an obsolete definition, it permits new/continued implementation in
order to foster interoperability with older/existing
implementations.
PRCs SHOULD NOT be defined as 'current' if one or more of their
classes are 'deprecated' or 'obsolete'. Similarly, they SHOULD NOT
Hegde, Sahita Expires January 2002 [Page 10]
Internet Draft SMIng COPSPR Mapping July 2001
be defined as 'deprecated' if one or more of their classes are
'obsolete'. Nevertheless, subsequent revisions of used class
definition cannot be avoided, but SHOULD be taken into account in
subsequent revisions of the local module.
If the 'status' statement is omitted the status value 'current' is
implied.
4.5.5. The prc's description Statement
The prc's 'description' statement, which must be present, gets one
argument, which is used to specify a high-level textual description
of this PRC.
It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this PRC.
4.5.6. The prc's reference Statement
The prc's 'reference' statement, which need not be present, gets one
argument which is used to specify a textual cross-reference to some
other document, either another module which defines related
definitions, or some other document which provides additional
information relevant to this prc statement.
4.5.7. The prc's pibaccess Statement
The prc's 'pibaccess' statement, which must be present, defines what
kind of access is appropriate for the PRC. The value for the
pibaccess MUST be one of the following four choices:
- The value "install" is used to indicate a PRC, which a PDP can
install in the PEP as provisioning information.
- The value "notify" is used to indicate a PRC for which the PEP
must notify the PDP of all its instances and attribute values of
that PRC.
- The value "install-notify" is used to indicate the type
of PRC which has both characteristics: "install" and "notify".
- The value "report-only" is used to indicate a PRC which has
neither the "install" characteristic nor the "notify"
characteristic. However, instances of such a PRC may be included
in synchronous/asynchronous reports generated by the PEP.
(Note: PRCs having the "install" and/or "notify" characteristics
may also be included in reports generated by the PEP.)
4.5.8. The prc's piberrors Statement
The prc's 'piberrors' statement, which need not be present, lists
one or more potential reasons for rejecting an install or a removal
of an instance of the PRC. Each reason consists of a named-number
Hegde, Sahita Expires January 2002 [Page 11]
Internet Draft SMIng COPSPR Mapping July 2001
enumeration, where the number represents a PRC-specific error-code
to be used in a COPS protocol message, as the Sub-Error Code, with
the Error-Code set to priSpecificError (see [COPS-PR]). The
semantics of each named-number enumeration should be described in
the prc's description statement.
The numbers listed in 'piberrors' must be greater than zero and less
than 65536. If this clause is not present, an install/remove can
still fail, but no PRC-specific error is available to be reported.
4.5.9. Usage Example
prc filterTable {
oid filterClasses.1;
pibindex filterPrid;
implements Filter {
object name;
object packets;
object bytes;
};
description
"A generic filter PRC.";
};
Note that the 'filterPrid' is the PRC's instance identifier of type
'InstanceId', and is packaged as the first attribute.
4.6. The group Statement
The 'group' statement is used to define a group of arbitrary nodes
in the object identifier tree. It gets two arguments: a lower-case
group identifier and a statement block that holds detailed group
information in an obligatory order.
The primary application of groups are compliance statements.
See the 'groupStatement' rule of the SMIng grammar (Section 5) for
the formal syntax of the 'group' statement.
4.6.1. The group's oid Statement
The group's 'oid' statement, which must be present, gets one
argument which specifies the object identifier value that is
assigned to this group.
4.6.2. The group's members Statement
The group's 'members' statement, which must be present, gets one
argument which specifies the list of nodes by their identifiers to
be contained in this group. The list of nodes has to be comma-
separated and enclosed in parenthesis.
4.6.3. The group's status Statement
Hegde, Sahita Expires January 2002 [Page 12]
Internet Draft SMIng COPSPR Mapping July 2001
The group's 'status' statement, which need not be present, gets one
argument which is used to specify whether this group definition is
current or historic. The value 'current' means that the definition
is current and valid. The value 'obsolete' means the definition is
obsolete and the group should no longer be used. While the value
'deprecated' also indicates an obsolete definition, it permits
new/continued use of this group.
If the 'status' statement is omitted the status value 'current' is
implied.
4.6.4. The group's description Statement
The group's 'description' statement, which must be present, gets one
argument which is used to specify a high-level textual description
of this group. It is RECOMMENDED to include any relation to other
groups.
4.6.5. The group's reference Statement
The group's 'reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
groups, or some other document which provides additional information
relevant to this group.
4.6.6. Usage Example
group frwkPrcSupportGroup {
oid frwkBasePibGroups.1;
members (frwkPrcSupportSupportedPrc,
frwkPrcSupportSupportedAttrs,
frwkPrcSupportMaxPris);
description
"A collection of object from the frwkPrcSupportTable."
};
4.7. The compliance Statement
The 'compliance' statement is used to define a set of compliance
requirements. It gets two arguments: a lower-case compliance
identifier and a statement block that holds detailed compliance
information in an obligatory order.
See the 'complianceStatement' rule of the SMIng grammar (Section 5)
for the formal syntax of the 'compliance' statement.
4.7.1. The compliance's oid Statement
The compliance's 'oid' statement, which must be present, gets one
argument which specifies the object identifier value that is
assigned to this compliance statement.
Hegde, Sahita Expires January 2002 [Page 13]
Internet Draft SMIng COPSPR Mapping July 2001
4.7.2. The compliance's status Statement
The compliance's 'status' statement, which need not be present, gets
one argument which is used to specify whether this compliance
statement is current or historic. The value 'current' means that the
definition is current and valid. The value 'obsolete' means the
definition is obsolete and no longer specifies a valid definition of
conformance. While the value 'deprecated' also indicates an
obsolete definition, it permits new/continued use of the compliance
specification.
If the 'status' statement is omitted the status value 'current' is
implied.
4.7.3. The compliance's description Statement
The compliance's 'description' statement, which must be present,
gets one argument which is used to specify a high-level textual
description of this compliance statement.
4.7.4. The compliance's reference Statement
The compliance's 'reference' statement, which need not be present,
gets one argument which is used to specify a textual cross-reference
to some other document, either another module which defines related
compliance statements, or some other document which provides
additional information relevant to this compliance statement.
4.7.5. The compliance's mandatory Statement
The compliance's 'mandatory' statement, which need not be present,
gets one argument which is used to specify a comma-separated list of
one or more groups (Section 4.6) of objects and/or notifications
enclosed in parenthesis. These groups are unconditionally mandatory
for implementation.
If the PEP or PDP [RAP-FRWK] claims compliance to a PIB module then
it must implement each and every object within each group listed the
'mandatory' statement(s) of the compliance statement(s) of that
module.
4.7.6. The compliance's optional Statement
The compliance's 'optional' statement, which need not be present, is
repeatedly used to name each group which is conditionally mandatory
for compliance to the module. It can also be used to name
unconditionally optional groups. A group named in an 'optional'
statement MUST be absent from the correspondent 'mandatory'
statement. The 'optional' statement gets two arguments: a lower-case
group identifier and a statement block that holds detailed
compliance information on that group.
Hegde, Sahita Expires January 2002 [Page 14]
Internet Draft SMIng COPSPR Mapping July 2001
Conditionally mandatory groups include those which are mandatory
only if a particular protocol is implemented, or only if another
group is implemented. The 'description' statement specifies the
conditions under which the group is conditionally mandatory.
A group which is named in neither a 'mandatory' statement nor an
'optional' statement, is unconditionally optional for compliance to
the module.
See the 'optionalStatement' rule of the SMIng grammar (Section 5)
for the formal syntax of the 'optional' statement.
4.7.6.1. The optional's description Statement
The optional's 'description' statement, which must be present, gets
one argument which is used to specify a high-level textual
description of the conditions under which this group is
conditionally mandatory or unconditionally optional.
4.7.7. The compliance's refine Statement
The compliance's 'refine' statement, which need not be present, is
repeatedly used to specify each object for which compliance has a
refined requirement with respect to the module definition. The
object must be present in one of the conformance groups named in the
correspondent 'mandatory' or 'optional' statements. The 'refine'
statement gets two arguments: a lower-case identifier of an object
and a statement block that holds detailed refinement information on
that object.
See the 'refineStatement' rule of the SMIng grammar (Section 5) for
the formal syntax of the 'refine' statement.
4.7.7.1. The refine's installtype Statement
The refine's 'installtype' statement, which need not be present,
gets one argument that is used to provide a refined type for the
correspondent object. Type restrictions may be applied by appending
subtyping information according to the rules of the base type. See
[SMING] for SMIng base types and their type restrictions.
4.7.7.2. The refine's pibminaccess Statement
The refine's 'pibminaccess' statement, which need not be present,
gets one argument that is used to specify the minimal level of
access that the correspondent object must implement in the sense of
its original 'access' statement. Hence, the refine's 'access'
statement MUST NOT specify a greater level of access than is
specified in the correspondent object definition.
An implementation is compliant if the level of access it provides is
greater or equal to the minimal level in the refine's 'pibminaccess'
Hegde, Sahita Expires January 2002 [Page 15]
Internet Draft SMIng COPSPR Mapping July 2001
statement and less or equal to the maximal level in the object's
'pibminaccess' statement.
4.7.7.3. The refine's description Statement
The refine's 'description' statement, which must be present, gets
one argument which is used to specify a high-level textual
description of the refined compliance requirement.
4.7.8. Usage Example
compliance frwkBasePibCompliance {
oid frwkBasePibConformance.1;
description
"Describes the requirements for conformance to the Framework
PIB."
mandatory (frwkPrcSupportGroup,
frwkPibIncarnationGroup,
frwkDeviceIdGroup,
frwkCompLimitsGroup,
frwkIfCapSetGroup,
frwkIfCapSetRoleComboGroup);
refine frwkPibIncarnationLongevity {
pibminaccess notify;
description
"Install support is not required."
};
refine frwkPibIncarnationTtl{
pibminaccess notify;
description
"Install support is not required."
};
refine frwkPibIncarnationActive{
pibminaccess notify;
description
"Install support is not required."
};
};
5. IETF-SMING-COPSPR-EXT
The grammar of the COPS-PR mapping SMIng extension conforms to the
Augmented Backus-Naur Form (ABNF)[ABNF]. It is included in the abnf
statement of the COPS-PR SMIng extension definition in the IETF-
SMING-COPSPR-EXT module below.
module IETF-SMING-COPSPR-EXT {
organization "IETF Next Generation Structure of
Management Information Working Group (SMIng)";
contact "Harsha Hegde
Hegde, Sahita Expires January 2002 [Page 16]
Internet Draft SMIng COPSPR Mapping July 2001
JF3-206
2111 NE 25th Ave
Hillsboro, Oregon 97124
Phone: 503-264-1439
Email: shriharsha.hegde@intel.com
Ravi Sahita
JF3-206
2111 NE 25th Ave
Hillsboro, Oregon 97124
Phone: 503-712-1554
Email: ravi.sahita@intel.com ";
description "This module defines a SMIng extension to define
the mapping of SMIng definitions of identities,
classes, and their attributes to dedicated
definitions of nodes and tables for application
in the Policy Based Management framework using
COPS-PR."
revision {
date "2001-07-18";
description "Minor modifications to PRC statement.";
};
//
// COPS-PR extension statement
//
extension copspr {
description
"The copspr statement maps SMIng definitions to COPS-PR
conformant definitions.";
abnf "
;;
;; sming-copspr.abnf -- Grammar of COPS-PR mappings in ABNF
;; notation (RFC 2234).
;;
;; Copyright (C) The Internet Society (2001). All Rights Reserved.
;;
;;
;; Statement rules.
;;
copsprStatement = copsprKeyword *1(sep lcIdentifier) optsep
"{" stmtsep
*1(oidStatement stmtsep)
*1(clienttypeStatement stmtsep)
*(nodeStatement stmtsep)
*(prcStatement stmtsep)
*(groupStatement stmtsep)
*(complianceStatement stmtsep)
Hegde, Sahita Expires January 2002 [Page 17]
Internet Draft SMIng COPSPR Mapping July 2001
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
oidStatement = oidKeyword sep objectIdentifier optsep ";"
objectIdentifier = (qlcIdentifier / subid) *127("." subid)
subid = decimalNumber
clienttypeStatement = clienttypeKeyword optsep
"{" stmtsep
allKeyword /
categoryId *("," categoryId)
"}" optsep ";"
categoryId = identifier optsep "(" number ")"
nodeStatement = nodeKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
*1(representsStatement stmtsep)
*1(statusStatement stmtsep)
*1(descriptionStatement stmtsep)
*1(referenceStatement stmtsep)
"}" optsep ";"
representsStatement = representsKeyword sep
qucIdentifier optsep ";"
prcStatement = prcKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
anyIndexStatement stmtsep
1*(implementsStatement stmtsep)
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
pibaccessStatement stmtsep
*1(piberrorsStatement stmtsep)
"}" optsep ";"
anyIndexStatement = pibindexStatement /
augmentsStatement /
extendsStatement
pibindexStatement = pibindexKeyword sep qlcIdentifier
optsep ";"
augmentsStatement = augmentsKeyword sep qlcIdentifier
optsep ";"
Hegde, Sahita Expires January 2002 [Page 18]
Internet Draft SMIng COPSPR Mapping July 2001
extendsStatement = extendsKeyword sep qlcIdentifier
optsep ";"
implementsStatement = implementsKeyword sep identifier optsep
"{" stmtsep
1*(implobjectStatement stmtsep)
"}" optsep ";"
implobjectStatement = objectKeyword sep
attributeIdentifier
*1( optsep
"{" optsep
pibreferenceStatement optsep /
pibtagStatement optsep
"}"
)
optsep ";"
pibreferenceStatement = pibreferenceKeyword sep
lcIdentifier optsep ";"
pibtagStatement = pibtagKeyword sep
lcIdentifier optsep ";"
pibaccessStatement = pibaccessKeyword sep
pibaccess optsep *1("," number)
optsep ";"
pibaccess = installonlyKeyword /
notifyonlyKeyword /
installnotifyKeyword /
reportonlyKeyword
piberrorsStatement = installerrorsKeyword sep
"{" stmtsep
piberror optsep *("," piberror)
"}" optsep ";"
piberror = identifier optsep "(" number ")"
groupStatement = groupKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
membersStatement stmtsep
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
membersStatement = membersKeyword optsep "(" optsep
qlcIdentifierList optsep
")" optsep ";"
Hegde, Sahita Expires January 2002 [Page 19]
Internet Draft SMIng COPSPR Mapping July 2001
complianceStatement = complianceKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
*1(mandatoryStatement stmtsep)
*(optionalStatement stmtsep)
*(refineStatement stmtsep)
"}" optsep ";"
mandatoryStatement = mandatoryKeyword optsep "(" optsep
qlcIdentifierList optsep
")" optsep ";"
optionalStatement = optionalKeyword sep qlcIdentifier optsep
"{" stmtsep
descriptionStatement stmtsep
"}" optsep ";"
refineStatement = refineKeyword sep qlcIdentifier optsep "{"
*1(installtypeStatement stmtsep)
*1(pibminaccessStatement stmtsep)
descriptionStatement stmtsep
"}" optsep ";"
installtypeStatement = installtypeKeyword sep
(refinedBaseType / refinedType)
optsep ";"
pibminaccessStatement = pibminaccessKeyword sep pibminaccess
optsep ";"
pibminaccess = noaccessKeyword /
installKeyword /
notifyKeyword /
installnotifyKeyword
;;
;; Statement keywords.
;;
copsprKeyword = %x63 %x6f %x70 %x73 %x70 %x72
oidKeyword = %x6f %x69 %x64
clienttypeKeyword = %x63 %x6c %x69 %x65 %x6e %x74 %x74 %x79 %x70
%x65
allKeyWord = %x63 %x6c %x6c
nodeKeyword = %x6e %x6f %x64 %x65
representsKeyword = %x72 %x65 %x70 %x72 %x65 %x73 %x65 %x6e %x74
%x73
prcKeyword = %x70 %x72 %x63
implementsKeyword = %x69 %x6d %x70 %x6c %x65 %x6d %x65 %x6e %x74
%x73
Hegde, Sahita Expires January 2002 [Page 20]
Internet Draft SMIng COPSPR Mapping July 2001
objectKeyword = %x6f %x62 %x6a %x65 %x63 %x74
pibreferenceKeyword = %x70 %x69 %x62 %x72 %x65 %x66 %x65 %x72 %x65
%x6E %x63 %x65
pibtagKeyword = %x70 %x69 %x62 %x74 %x61 %x67
pibaccessKeyword = %x70 %x69 %x62 %x61 %x63 %x63 %x65 %x73 %x73
installonlyKeyword = %x69 %x6E %x73 %x74 %x61 %x6C %x6C %x6F %x6E
%x6C %x79
notifyonlyKeyword = %x6E %x6F %x74 %x69 %x66 %x79 %x6F %x6E %x6C
%x79
installnotifyKeyword= %x69 %x6E %x73 %x74 %x61 %x6C %x6C %x6E %x6F
%x74 %x69 %x66 %x79
reportonlyKeyword = %x72 %x65 %x70 %x6F %x72 %x74 %x6F %x6E %x6C
%x79
installerrorsKeyword= %x69 %x6E %x73 %x74 %x61 %x6C %x6C %x65 %x72
%x72 %x6F %x72 %x73
pibindexKeyword = %x70 %x69 %x62 %x69 %x6e %x64 %x65 %x78
augmentsKeyword = %x61 %x75 %x67 %x6d %x65 %x6e %x74 %x73
extendsKeyword = %x65 %x78 %x74 %x65 %x6e %x64 %x73
groupKeyword = %x67 %x72 %x6f %x75 %x70
membersKeyword = %x6d %x65 %x6d %x62 %x65 %x72 %x73
complianceKeyword = %x63 %x6f %x6d %x70 %x6c %x69 %x61 %x6e %x63
%x65
mandatoryKeyword = %x6d %x61 %x6e %x64 %x61 %x74 %x6f %x72 %x79
optionalKeyword = %x6f %x70 %x74 %x69 %x6f %x6e %x61 %x6c
refineKeyword = %x72 %x65 %x66 %x69 %x6e %x65
installtypeKeyword = %x69 %x6E %x73 %x74 %x61 %x6C %x6C %x74 %x79
%x70 %x65
pibminacessKeyword = %x70 %x69 %x62 %x6d %x69 %x6E %x61 %x63 %x63
%x65 %x73 %x73
noaccessKeyword = %x6E %x6f %x61 %x63 %x63 %x65 %x73 %x73
installKeyword = %x69 %x6E %x73 %x74 %x61 %x6C %x6C
notifyKeyword = %x6E %x6F %x74 %x69 %x66 %x79
;;
;; EOF
;;
";
};
};
6. IETF-SMING-COPSPR
module IETF-SMING-COPSPR {
organization "IETF Next Generation Structure of
Management Information Working Group (SMIng)";
contact "Harsha Hegde
Hegde, Sahita Expires January 2002 [Page 21]
Internet Draft SMIng COPSPR Mapping July 2001
JF3-206
2111 NE 25th Ave
Hillsboro, Oregon 97124
Phone: 503-264-1439
Email: shriharsha.hegde@intel.com
Ravi Sahita
JF3-206
2111 NE 25th Ave
Hillsboro, Oregon 97124
Phone: 503-712-1554
Email: ravi.sahita@intel.com ";
description "Core type definitions for the SMIng COPS-PR
mapping. These definitions are based on [SPPI]
definitions. They are specific to the COPS-PR
protocol and its naming system.";
revision {
date "2001-07-18";
description "No modifications to the initial version.";
};
typedef InstanceId {
type Unsigned32 (1..4294967295);
description
"The type for use by an attribute which is used as
the instance-identifying index of a PRC[COPS-PR], i.e.,
an attribute that MUST be added as the 'pibindex' to a
base PRC and it MUST be the first attribute of the PRC.
The value of an attribute with this syntax is always
greater than zero. PRIs[COPS-PR] of the same PRC need
not have contiguous values for their instance-
identifying attribute.";
reference
"[SPPI]";
};
typedef ReferenceId {
type Unsigned32;
description
"A typedef for use by an attribute which is used as a
pointer in order to reference an instance of a
particular PRC. An attribute with this syntax must not
be used in a pibindex statement, and the objects
pibreference statement must specify the particular PRC
to which the referenced PRI will belong. For an
attribute of this type, the referenced PRI must exist.
Furthermore, it is an error to try to delete a PRI that
is referenced by another instance without first
deleting/modifying the referencing instance. The
definition of an attribute with this syntax can permit
the attribute to have a value of zero to indicate that
Hegde, Sahita Expires January 2002 [Page 22]
Internet Draft SMIng COPSPR Mapping July 2001
it is not currently pointing to an PRI.";
reference
"[SPPI]. Also see definition of 'Prid'.";
};
typedef Prid {
type Pointer;
description
"Represents a pointer to a PRI, i.e,. to an instance of
a PRC. The value is the OID name of the PRC's row
definition, appended with one sub-identifier containing
the value of the InstanceId value for the referenced
instance. The definition of an attribute with this
syntax can permit the attribute to have a value of
'NULL' (0.0) to indicate that it is not currently
pointing to a PRI.";
reference
"[SPPI]. Also see definition of 'ReferenceId'.";
};
typedef TagId {
type Unsigned32 (1..4294967295);
description
"Represents a tag value, such that all instances of
aparticular PRC having the same tag value form a tag
list. A tag list is identified by the tag value shared
by all instances in that tag list.";
reference
"[SPPI]. Also see definition of 'TagReferenceId'.";
};
typedef TagReferenceId {
type Unsigned32;
description
"Represents a reference to a tag list of instances of a
particular PRC. The particular PRC must have an
attribute with the syntax of TagId. The tag list
consists of all instances which have the same value of
the TagId attribute. Reference to the tag list is via
the attribute with the syntax of TagReferenceId
containing the tag value which identifies the tag list.
The attribute of this type must use the pibtagstatement
to specify the attribute of type TagId in the PRC
containing the tagged list of instances. The attribute
can have a value zero if it is not currently pointing
to a tagged list.";
reference
"[SPPI]. Also see definition of 'TagId'.";
};
};
Hegde, Sahita Expires January 2002 [Page 23]
Internet Draft SMIng COPSPR Mapping July 2001
7. Security Considerations
This document presents an extension of the SMIng data definition
language that supports the mapping of SMIng data definitions so that
they can be used with the Policy Based Management framework using
COPS-PR. The language extension and the mapping itself have no
security impact on the Internet.
8. Acknowledgements
Since SPPI is very similar to SMIv2, some paragraphs and phrases are
directly taken from the SMIng mappings to SNMP Internet Draft [SNMP-
MAP]. Thanks to the authors of [SNMP-MAP].
9. Authors' Addresses
Harsha Hegde
JF3-206
2111 NE 25th Ave
Hillsboro, Oregon 97124
Phone: 503-264-1439
Email: shriharsha.hegde@intel.com
Ravi Sahita
JF3-206
2111 NE 25th Ave
Hillsboro, Oregon 97124
Phone: 503-712-1554
Email: ravi.sahita@intel.com
10. References
[SMING]
Strauss, F., Schoenwaelder, J., McCloghrie, K., "SMIng ûNext
Generation Structure of Management Information", draft-ietf-
sming-01.txt, March 2001.
[SNMP-MAP]
Strauss, F., Schoenwaelder, J., McCloghrie, K., "SMIng Mappings
to SNMP", draft-ietf-sming-snmp-01.txt, March 2001.
[SMIV2]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and Waldbusser, S., "Structure of Management Information
Version 2(SMIv2)", STD 58, RFC 2578, April 1999.
[RAP-FRWK]
R. Yavatkar, D. Pendarakis, "A Framework for Policy-based
Admission Control", RFC 2753, January 2000.
[COPS]
Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A.
Hegde, Sahita Expires January 2002 [Page 24]
Internet Draft SMIng COPSPR Mapping July 2001
Sastry, "The COPS (Common Open Policy Service) Protocol" RFC
2748, January 2000.
[COPS-PR]
D. Durham, K. McCloghrie, J. Seligson, K. Chan, S. Gai, S.
Herzog, A. Smith, R. Yavatkar, F. Reichmeyer., "COPS Usage for
Policy Provisioning (COPS-PR)" RFC 3084, March 2001.
[SPPI]
M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R.Sahita,
A. Smith, F. Reichmeyer., "Structure of Policy Provisioning
Information," draft-ietf-rap-sppi-07.txt, May 2001.
[ABNF]
Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ASN1]
Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, December 1987.
[KEYWORD]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
Hegde, Sahita Expires January 2002 [Page 25]
