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]