idnits 2.17.1 draft-ietf-rap-sppi-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (14 July 2000) is 8686 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'APPLICATION 7' is mentioned on line 268, but not defined == Missing Reference: 'APPLICATION 8' is mentioned on line 272, but not defined -- Looks like a reference, but probably isn't: '2' on line 1205 -- No information found for draft-ietf-rap-cops-pr - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'COPS-PR' ** Obsolete normative reference: RFC 2573 (ref. 'APPL') (Obsoleted by RFC 3413) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. McCloghrie 3 Internet Draft M. Fine 4 Cisco Systems 5 J. Seligson 6 K. Chan 7 Nortel Networks 8 S. Hahn 9 R. Sahita 10 Intel 11 A. Smith 12 No Affiliation 13 F. Reichmeyer 14 IPHighway 16 14 July 2000 18 Structure of Policy Provisioning Information (SPPI) 20 draft-ietf-rap-sppi-01.txt 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with all 25 provisions of Section 10 of RFC2026. Internet-Drafts are working 26 documents of the Internet Engineering Task Force (IETF), its areas, and 27 its working groups. Note that other groups may also distribute working 28 documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference material 33 or to cite them other than as ``work in progress.'' 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 43 Copyright (C) The Internet Society (2000). All Rights Reserved. 45 Draft SPPI July 2000 47 1. Introduction 49 RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] 50 describes how the COPS protocol is used to provide for the outsourcing 51 of policy decisions for RSVP. Another usage of the COPS protocol, for 52 the provisioning of policy, is introduced in [COPS-PR]. In this 53 provisioning model, the policy information is viewed as a collection of 54 Policy Rule Classes and Policy Rule Instances residing in a virtual 55 information store, termed the Policy Information Base (PIB). 56 Collections of related Policy Rule Classes are defined in a PIB module. 57 PIB modules are written using an adapted subset of SNMP's Structure of 58 Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this 59 document, the Structure of Policy Provisioning Information (SPPI), to 60 define that adapted subset. 62 1.1. Change Log 64 This log to be removed as and when this draft is published as an RFC. 66 1.1.1. Changes made in version published on 13 July 2000 68 - included definition of the TEXTUAL-CONVENTION macro in the SPPI's 69 ASN.1 module so that TC's in PIBs can use data types not present in the 70 SMI. 72 - renamed the CLIENT-TYPES clause to be the SUBJECT-CATEGORIES clause in 73 order to be more generic. 75 - renamed the POLICY-ACCESS clause to be the PIB-ACCESS clause for 76 consistency. Added an extra parameter on the PIB-ACCESS clause for use 77 as the sub-identifier for a RowStatus column when converting to a MIB. 79 - added new clauses: EXTENDS, PIB-INDEX, PIB-REFERENCES, PIB-TAG, and 80 PIB-MODULES. 82 - renamed the MIN-ACCESS clause to be the PIB-MIN-ACCESS clause. 84 - created a new PIB module to contain the TC's defined in the SPPI. 86 - defined new TC's: Prid, PolicyTagId, PolicyTagReference. 88 - added Appendix with example usage of PIB-REFERENCE and PIB-TAG. 90 - added detail on carrying an INSTALL-ERROR in COPS-PR messages. 92 Draft SPPI July 2000 94 2. Use of the SMI 96 The SPPI and PIB modules are based on SNMP's SMI and MIB modules, which 97 use an adapted subset of the ASN.1 data definition language [ASN1]. The 98 decision to base the definition of PIB modules on this format allows for 99 the leveraging of the community's knowledge, experience and tools of the 100 SMI and MIB modules. 102 2.1. Terminology Translation 104 The SMI uses the term "managed objects" to refer to object types, both 105 tabular types with descriptors such as xxxTable and xxxEntry, as well as 106 scalar and columnar object types. The SPPI does not use the term 107 "object" so as to avoid confusion with COPS protocol objects. Instead, 108 the SPPI uses the term Policy Rule Class (PRC) for the table and row 109 definitions (the xxxTable and xxxEntry objects, respectively), and 110 Policy Rule Instance (PRI) for an instantiation of a row definition. 111 For a columnar object of a table definition, the SPPI uses the term 112 "attribute" of a Policy Rule Class. (The SPPI does not support the 113 equivalent of the SMI's scalar objects.) 115 2.2. Overview 117 SNMP's SMI is divided into five parts: module definitions, object 118 definitions, notification definitions [SMI], textual convention 119 definitions [TC] and conformance definitions [CONF]. 121 - The SMI's MODULE-IDENTITY macro is used to convey the semantics of 122 a MIB module. The SPPI uses this macro to convey the semantics of 123 a PIB module. 125 - The SMI's OBJECT-TYPE macro is used to convey the syntax and 126 semantics of managed objects. The SPPI uses this macro to convey 127 the syntax and semantics of PRCs and their attributes. 129 - The SMI's notification definitions are not used (at this time) by 130 the SPPI. 132 - The SMI's TEXTUAL CONVENTION macro allows new data types to be 133 defined. The SPPI uses this macro to define new data types having 134 particular syntax and semantics which is common to several 135 attributes of one of more PRCs. 137 - The SMI's conformance definitions define several macros: the 138 OBJECT-GROUP macro, the NOTIFICATION-GROUP macro, the MODULE- 140 Draft SPPI July 2000 142 COMPLIANCE macro and the AGENT-CAPABILITIES macro. The SPPI uses 143 the OBJECT-GROUP and MODULE-COMPLIANCE macros to specify acceptable 144 lower-bounds of implementation of the attributes of PRCs, and 145 thereby indirectly, acceptable lower-bounds of implementation of 146 the PRCs themselves. The NOTIFICATION-GROUP macro is not used (at 147 this time) by the SPPI. Potential usage by the SPPI of the AGENT- 148 CAPABILITIES macro is for further study. 150 3. Structure of this Specification 152 The SMI is specified in terms of an ASN.1 definition together with 153 descriptive text for each element introduced in that ASN.1 definition. 154 This document specifies the SPPI via a modified ASN.1 definition (which 155 imports those definitions which are unchanged from the SMI), together 156 with descriptive text for only those elements in the SPPI's ASN.1 157 definition which have differences from the SMI's. For elements in the 158 ASN.1 definition which have no descriptive text in this specification, 159 the reader is referred to the SMI's descriptive text for that element. 161 Draft SPPI July 2000 163 4. Definitions 165 COPS-PR-SPPI DEFINITIONS ::= BEGIN 167 IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, Integer32, 168 IpAddress, Unsigned32, TimeTicks 169 FROM SNMPv2-SMI; 171 -- definitions for PIB modules 173 MODULE-IDENTITY MACRO ::= 174 BEGIN 175 TYPE NOTATION ::= 176 SubjectPart -- new 177 "LAST-UPDATED" value(Update ExtUTCTime) 178 "ORGANIZATION" Text 179 "CONTACT-INFO" Text 180 "DESCRIPTION" Text 181 RevisionPart 182 PibModulesPart -- new 184 VALUE NOTATION ::= 185 value(VALUE OBJECT IDENTIFIER) 187 SubjectPart ::= -- new 188 "SUBJECT-CATEGORY" "{" Categories "}" 189 Categories ::= -- new 190 CategoryIDs 191 | "all" 192 CategoryIDs ::= -- new 193 CategoryID 194 | CategoryIDs "," CategoryID 195 CategoryID ::= -- new 196 identifier "(" number ")" 198 RevisionPart ::= 199 Revisions 200 | empty 201 Revisions ::= 202 Revision 203 | Revisions Revision 204 Revision ::= 205 "REVISION" value(Update ExtUTCTime) 206 "DESCRIPTION" Text 208 Draft SPPI July 2000 210 PibModulesPart ::= -- new 211 PIB-MODULES "{" PibModules "}" 212 PibModules ::= 213 PibModule 214 | PibModules "," PibModule 215 PibModule ::= -- module name of a PIB Module 216 value(OBJECT IDENTIFIER) 218 Text ::= value(IA5String) 219 END 221 -- syntax of attributes 223 -- the "base types" defined here are: 224 -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER 225 -- 6 application-defined types: Integer32, IpAddress, Unsigned32, 226 -- TimeTicks, Integer64 and Unsigned64 228 ObjectSyntax ::= 229 CHOICE { 230 simple 231 SimpleSyntax, 233 -- note that SEQUENCEs for table and row definitions 234 -- are not mentioned here... 236 application-wide 237 ApplicationSyntax 238 } 240 -- application-wide types 242 ApplicationSyntax ::= 243 CHOICE { 244 ipAddress-value 245 IpAddress, 247 timeticks-value 248 TimeTicks, 250 unsigned-integer-value 251 Unsigned32, 253 large-integer-value -- new 254 Integer64 256 Draft SPPI July 2000 258 large-unsigned-integer-value -- new 259 Unsigned64, 260 } 262 -- indistinguishable from INTEGER, but never needs more than 263 -- 32-bits for a two's complement representation 264 Integer32 ::= 265 INTEGER (-2147483648..2147483647) 267 Integer64 ::= 268 [APPLICATION 7] 269 IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) 271 Unsigned64 272 [APPLICATION 8] 273 IMPLICIT INTEGER (0..18446744073709551615) 275 -- definition for Policy Rule Classes and their attributes 276 -- (differences from the SMI are noted in the ASN.1 comments) 278 OBJECT-TYPE MACRO ::= 279 BEGIN 280 TYPE NOTATION ::= 281 "SYNTAX" Syntax 282 UnitsPart 283 "PIB-ACCESS" AccessPart -- modified 284 PibReferencesPart -- new 285 PibTagPart -- new 286 "STATUS" Status 287 "DESCRIPTION" Text 288 ErrorsPart -- new 289 ReferPart 290 IndexPart 291 PibIndexPart -- new 292 UniquePart -- new 293 DefValPart 295 VALUE NOTATION ::= 296 value(VALUE ObjectName) 298 Syntax ::= -- Must be one of the following: 299 -- a base type (or its refinement), 300 -- a textual convention (or its refinement), or 301 -- a BITS pseudo-type 303 Draft SPPI July 2000 305 type 306 | "BITS" "{" NamedBits "}" 308 NamedBits ::= NamedBit 309 | NamedBits "," NamedBit 311 NamedBit ::= identifier "(" number ")" -- number is nonnegative 313 UnitsPart ::= 314 "UNITS" Text 315 | empty 317 AccessPart ::= -- new 318 Access 319 | Access "," number -- number is positive 321 Access ::= -- modified 322 "install" 323 | "notify" 324 | "install-notify" 326 Status ::= 327 "current" 328 | "deprecated" 329 | "obsolete" 331 ErrorsPart ::= -- new 332 "INSTALL-ERRORS" "{" Errors "}" 333 | empty 335 Errors ::= -- new 336 Error 337 | Errors "," Error 338 Error ::= -- new 339 identifier "(" number ")" 341 ReferPart ::= 342 "REFERENCE" Text 343 | empty 345 IndexPart ::= 346 "INDEX" "{" Index "}" -- modified 347 | "AUGMENTS" "{" Entry "}" 348 | "EXTENDS" "{" Entry "}" -- new 349 | empty 351 Draft SPPI July 2000 353 Index ::= 354 -- the correspondent OBJECT-TYPE invocation 355 value(ObjectName) 356 Entry ::= 357 -- use the INDEX value of the 358 -- correspondent OBJECT-TYPE invocation 359 value(ObjectName) 360 PibIndexPart ::= -- new 361 "PIB-INDEX" "{" Index "}" 362 | empty 364 PibReferencesPart ::= 365 -- for use with PolicyReferenceId TC 366 "PIB-REFERENCES" "{" Entry "}" 367 | empty 369 PibTagPart ::= 370 -- for use with "PolicyTagReference" TC 371 "PIB-TAG" "{" Attr "}" 372 | empty 374 Attr ::= -- specifies an attribute 375 value(ObjectName) 377 UniquePart ::= -- new 378 "UNIQUENESS" "{" UniqueTypes "}" 379 UniqueTypes ::= 380 UniqueType 381 | UniqueTypes "," UniqueType 382 | empty 383 UniqueType ::= 384 -- the correspondent OBJECT-TYPE invocation 385 value(ObjectName) 387 DefValPart ::= "DEFVAL" "{" Defvalue "}" 388 | empty 390 Defvalue ::= -- must be valid for the type specified in 391 -- SYNTAX clause of same OBJECT-TYPE macro 392 value(ObjectSyntax) 393 | "{" BitsValue "}" 395 BitsValue ::= BitNames 396 | empty 398 Draft SPPI July 2000 400 BitNames ::= BitName 401 | BitNames "," BitName 403 BitName ::= identifier 405 Text ::= value(IA5String) 406 END 408 -- definitions for compliance statements 410 MODULE-COMPLIANCE MACRO ::= 411 BEGIN 412 TYPE NOTATION ::= 413 "STATUS" Status 414 "DESCRIPTION" Text 415 ReferPart 416 ModulePart 418 VALUE NOTATION ::= 419 value(VALUE OBJECT IDENTIFIER) 421 Status ::= 422 "current" 423 | "deprecated" 424 | "obsolete" 426 ReferPart ::= 427 "REFERENCE" Text 428 | empty 430 ModulePart ::= 431 Modules 432 Modules ::= 433 Module 434 | Modules Module 435 Module ::= 436 -- name of module -- 437 "MODULE" ModuleName 438 MandatoryPart 439 CompliancePart 441 ModuleName ::= 442 -- identifier must start with uppercase letter 443 identifier ModuleIdentifier 445 Draft SPPI July 2000 447 -- must not be empty unless contained 448 -- in MIB Module 449 | empty 450 ModuleIdentifier ::= 451 value(OBJECT IDENTIFIER) 452 | empty 454 MandatoryPart ::= 455 "MANDATORY-GROUPS" "{" Groups "}" 456 | empty 458 Groups ::= 459 Group 460 | Groups "," Group 461 Group ::= 462 value(OBJECT IDENTIFIER) 464 CompliancePart ::= 465 Compliances 466 | empty 468 Compliances ::= 469 Compliance 470 | Compliances Compliance 471 Compliance ::= 472 ComplianceGroup 473 | Object 475 ComplianceGroup ::= 476 "GROUP" value(OBJECT IDENTIFIER) 477 "DESCRIPTION" Text 479 Object ::= 480 "OBJECT" value(ObjectName) 481 InstallSyntaxPart -- modified 482 AccessPart 483 "DESCRIPTION" Text 485 -- must be a refinement for object's SYNTAX clause 486 InstallSyntaxPart ::= "SYNTAX" Syntax 487 | empty 489 Syntax ::= -- Must be one of the following: 490 -- a base type (or its refinement), 491 -- a textual convention (or its refinement), or 493 Draft SPPI July 2000 495 -- a BITS pseudo-type 496 type 497 | "BITS" "{" NamedBits "}" 499 NamedBits ::= NamedBit 500 | NamedBits "," NamedBit 502 NamedBit ::= identifier "(" number ")" -- number is nonnegative 504 AccessPart ::= 505 "PIB-MIN-ACCESS" Access -- modified 506 | empty 507 Access ::= -- modified 508 "not-accessible" 509 | "install" 510 | "notify" 511 | "install-notify" 513 -- a character string as defined in [2] 514 Text ::= value(IA5String) 515 END 517 -- definition of textual conventions 519 TEXTUAL-CONVENTION MACRO ::= 520 BEGIN 521 TYPE NOTATION ::= 522 DisplayPart 523 "STATUS" Status 524 "DESCRIPTION" Text 525 ReferPart 526 "SYNTAX" Syntax 528 VALUE NOTATION ::= 529 value(VALUE Syntax) -- adapted ASN.1 531 DisplayPart ::= 532 "DISPLAY-HINT" Text 533 | empty 535 Status ::= 536 "current" 537 | "deprecated" 538 | "obsolete" 540 Draft SPPI July 2000 542 ReferPart ::= 543 "REFERENCE" Text 544 | empty 546 -- a character string as defined in [2] 547 Text ::= value(IA5String) 549 Syntax ::= -- Must be one of the following: 550 -- a base type (or its refinement), or 551 -- a BITS pseudo-type 552 type 553 | "BITS" "{" NamedBits "}" 555 NamedBits ::= NamedBit 556 | NamedBits "," NamedBit 558 NamedBit ::= identifier "(" number ")" -- number is nonnegative 560 END 562 END 563 Draft SPPI July 2000 565 COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN 567 IMPORTS Unsigned32, Integer32 FROM SNMPv2-SMI 568 MODULE-IDENTITY, TEXTUAL-CONVENTION FROM COPS-PR-SPPI; 570 copsPrSppiTc MODULE-IDENTITY 571 SUBJECT-CATEGORIES { all } 572 LAST-UPDATED "200003101800Z" 573 ORGANIZATION "IETF DIFFSERV WG" 574 CONTACT-INFO " 575 Keith McCloghrie 576 Cisco Systems, Inc. 577 170 West Tasman Drive, 578 San Jose, CA 95134-1706 USA 579 Phone: +1 408 526 5260 580 Email: kzm@cisco.com 582 Ravi Sahita 583 Intel 584 2111 NE 25th Avenue 585 Hillsboro, OR 97124 USA 586 Phone: +1 503 264 8231 587 Email: ravi.sahita@intel.com 588 " 589 DESCRIPTION 590 "The PIB module containing a set of Textual Conventions 591 which have general applicability to many/most PIB modules." 592 ::= { tbd } 594 PolicyInstanceId ::= TEXTUAL-CONVENTION 595 STATUS current 596 DESCRIPTION 597 "The textual convention for use by an attribute which is used 598 as the instance-identifying index of a PRC, i.e., an attribute 599 named in a PIB-INDEX clause (or INDEX clause, if a PIB-INDEX 600 clause is absent). The value of an attribute with this 601 syntax is always greater than zero. 603 PRIs of the same PRC need not have contiguous values for their 604 instance-identifying attribute." 605 SYNTAX Unsigned32 (1..4294967295) 607 Draft SPPI July 2000 609 PolicyReferenceId ::= TEXTUAL-CONVENTION 610 STATUS current 611 DESCRIPTION 612 "A textual convention for use by an attribute which is used as 613 a pointer in order to reference an instance of a particular 614 PRC. An attribute with this syntax must not be used in a 615 PIB-INDEX clause (or INDEX clause, if a PIB-INDEX clause is 616 absent), and its description must specify the particular 617 PRC to which the referenced PRI will belong. 619 For an attribute of this type, the referenced PRI must exist. 620 Furthermore, it is an error to try to delete a PRI that is 621 referenced by another instance without first deleting/modifying 622 the referencing instance. 624 The definition of an attribute with this syntax can permit the 625 attribute to have a value of zero to indicate that it is not 626 currently pointing to an PRI." 627 SYNTAX Unsigned32 629 Prid ::= TEXTUAL-CONVENTION 630 STATUS current 631 DESCRIPTION 632 "Represents a pointer to a PRI, i.e,. to an instance of a 633 PRC. The value is the OID name of the PRC's row definition, 634 appended with one sub-identifier containing the value of the 635 PolicyInstanceId value for the referenced instance." 636 SYNTAX OBJECT IDENTIFIER 638 PolicyTagId ::= TEXTUAL-CONVENTION 639 STATUS current 640 DESCRIPTION 641 "Represents a tag value, such that all instances of a 642 particular PRC having the same tag value form a tag list. 643 A tag list is identified by the tag value shared by all 644 instances in that tag list." 645 SYNTAX Integer32 647 PolicyTagReference ::= TEXTUAL-CONVENTION 648 STATUS current 649 DESCRIPTION 650 "Represents a reference to a tag list of instances of a 651 particular PRC. The particular PRC must have an attribute 652 with the syntax of PolicyTagId. The tag list consists of 653 all instances which have the same value of the PolicyTagId 655 Draft SPPI July 2000 657 attribute. Reference to the tag list is via the attribute 658 with the syntax of PolicyTagReference containing the tag 659 value which identifies the tag list." 660 SYNTAX Integer32 662 END 663 Draft SPPI July 2000 665 5. PIB Modules 667 The names of all standard PIB modules must be unique (but different 668 versions of the same module should have the same name). Developers of 669 enterprise PIB modules are encouraged to choose names for their modules 670 that will have a low probability of colliding with standard or other 671 enterprise modules. 673 The first line of a PIB module is: 675 PIB-MODULE-NAME PIB-DEFINITIONS ::= BEGIN 677 where PIB-MODULE-NAME is the module name. 679 Like the SMI, additional ASN.1 macros must not be defined in PIB 680 modules. 682 5.1. Importing Definitions 684 Like the SMI, a PIB module which needs to reference an external 685 definition, must use the IMPORTS statement to identify both the 686 descriptor and the module in which the descriptor is defined, where a 687 module is identified by its ASN.1 module name. 689 In particular, a PIB module may import from COPS-PR-SPPI (defined in 690 this document), and from other PIB modules. A PIB module may also 691 import OID assignments from MIB modules, as well as textual convention 692 definitions providing that their underlying syntax is supported by the 693 SPPI. However, the following must not be included in an IMPORTS 694 statement: 695 - named types defined by ASN.1 itself, specifically: INTEGER, OCTET 696 STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type, 697 - the BITS construct. 699 For each ASN.1 macro that a PIB uses, it must import that macro's 700 definition from the appropriate module, as follows: 702 - MODULE-IDENTITY, OBJECT-TYPE, TEXTUAL-CONVENTION and MODULE-COMPLIANCE 703 from COPS-PR-SPPI 705 - OBJECT-IDENTITY from SNMPv2-SMI 707 - OBJECT-GROUP from SNMPv2-CONF 708 Draft SPPI July 2000 710 5.2. Reserved Keywords 712 In addition to the reserved keywords listed in the SMI, the following 713 must not be used as descriptors or module names: 715 INSTALL-ERRORS Integer64 PIB-MIN-ACCESS PIB-ACCESS 716 SUBJECT-CATEGORIES UNIQUENESS Unsigned64 718 6. Naming Hierarchy 720 The SPPI uses the same OBJECT IDENTIFIER naming hierarchy as the SMI. 721 That is, OIDs are typically assigned to PIB modules from the subtree 722 administered by the Internet Assigned Numbers Authority (IANA). 723 However, like the SMI, the SPPI does not prohibit the definition of PRCs 724 in other portions of the OID tree. 726 7. Mapping of the MODULE-IDENTITY macro 728 7.1. Mapping of the SUBJECT-CATEGORIES clause 730 The SUBJECT-CATEGORIES clause, which must be present, identifies a 731 particular category of Policy data for which this PIB module defines 732 policy information. For use with the COPS-PR protocol, the individual 733 subject categories are mapped to COPS Client Types [COPS-PR]. The 734 subject categories are identified either: 736 - via the keyword "all", indicating the PIB module defines policy 737 information relevant for all subject categories (and thus, all COPS 738 Client Types), or 740 - a list of named-number enumerations, where each number identifies a 741 subject category, and is mapped to the Client Type which is 742 identified by that same number in the COPS protocol. At present 743 time, no more than one named-number enumeration should be 744 specified. 746 When a PIB module applies to multiple subject categories, that PIB 747 module exists in multiple virtual information stores, one for each 748 Client-Type. 750 Draft SPPI July 2000 752 7.2. Mapping of the PIB-MODULES clause 754 The PIB-MODULES clause, which must be present if this PIB module 755 references any other PIB modules, identifies by module name each 756 referenced PIB module. For example, PIB modules referenced by an 757 IMPORTS or in a MODULE-CONFORMANCE should be identified in this clause. 758 This information is used by the algorithmic conversion of a PIB to a MIB 759 (see Appendix A). 761 8. Mapping of the OBJECT-TYPE macro 763 The SPPI requires that all attribute definitions be contained within a 764 PRC, i.e., within a table definition. 766 8.1. Mapping of the SYNTAX clause 768 The SYNTAX clause, which must be present within the definition of an 769 attribute, defines the abstract data structure of that attribute. The 770 data structure must be one of the following: a base type, the BITS 771 construct, or a textual convention. 773 The SYNTAX clause must also be present for the table and row definitions 774 of a PRC, and in this case must be a SEQUENCE OF or SEQUENCE (see 775 section 8.1.7 below). 777 The base types are an extended subset of the SMI's base types: 779 - built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER, 781 - application-defined types: Integer32, IpAddress, Unsigned32, 782 TimeTicks, Integer64 and Unsigned64. 784 A textual convention is a newly-defined type defined as a sub-type of a 785 base type [TC]. The value of an attribute whose syntax is defined using 786 a textual convention is encoded "on-the-wire" according to the textual 787 convention's underlying base type. 789 Note that the set of base types has been chosen so as to provide 790 sufficient variety of on-the-wire encodings for attribute values; base 791 types should contain a minimum of semantics. Semantics should, to the 792 extent possible, be incorporated into a data type through the use of a 793 textual convention. Thus, the IpAddress and TimeTicks data types should 794 really be defined as textual conventions because they contain semantics. 795 However, they are defined here as base types so as to avoid confusion 796 with the SMI which defines them as base types. 798 Draft SPPI July 2000 800 The differences from the SMI in the semantics of ObjectSyntax are now 801 described. 803 8.1.1. Counter32 805 The Counter32 type is not supported by the SPPI. 807 8.1.2. Gauge32 809 The Gauge32 type is not supported by the SPPI. 811 8.1.3. Opaque 813 The Opaque type is not supported by the SPPI. 815 8.1.4. Counter64 817 The Counter64 type is not supported by the SPPI. 819 8.1.5. Integer64 821 The Integer64 type represents integer-valued information between -2^63 822 and 2^63-1 inclusive (-9223372036854775808 to 9223372036854775807 823 decimal). While Integer64 may be sub-typed to be more constrained, if 824 the constraint results in all possible values being contained in the 825 range (-2147483648..2147483647), then the Integer32 type must be used 826 instead of Integer64. 828 8.1.6. Unsigned64 830 The Integer64 type represents integer-valued information between -2^63 831 and 2^63-1 inclusive (0 to 18446744073709551615 decimal). While 832 Unsigned64 may be sub-typed to be more constrained, if the constraint 833 results in all possible values being contained in the range 834 (0..4294967295), then the Unsigned32 type must be used instead of 835 Unsigned64. 837 8.1.7. Policy Rule Classes 839 The policy operations (on PIBs) supported by the SPPI apply exclusively 840 to PRCs. Each PRC is modelled as a tabular structure, i.e., a table. 841 Each instance of a particular PRC has the same set of attributes. The 842 set of attributes which belong to every instance of a particular PRC is 843 modelled as a row in the table. This model is formalized by using the 844 OBJECT-TYPE macro to define both: 846 Draft SPPI July 2000 848 - the PRC as a whole, called the table definition, and 850 - the characteristics of every instance of a particular PRC, called 851 the row definition. 853 In the table definition, the SYNTAX clause has the form: 855 SEQUENCE OF 857 where refers to the SEQUENCE type of its attribute 858 definitions. In the row definition, the SYNTAX clause has the form: 860 862 where is a SEQUENCE type defined as follows: 864 ::= SEQUENCE { , ... , } 866 where there is one for each attribute, and each is of the 867 form: 869 871 where is the descriptor naming an attribute, and 872 has the value of that attribute's SYNTAX clause, except that both sub- 873 typing information and the named values for enumerated integers or the 874 named bits for the BITS construct, are omitted from . 876 8.2. Mapping of the MAX-ACCESS clause 878 The MAX-ACCESS clause is not supported by the SPPI. 880 8.3. Mapping of the PIB-ACCESS clause 882 The PIB-ACCESS clause must be present for a PRC's table definition, and 883 must not be present for any other OBJECT-TYPE definition. The PIB- 884 ACCESS clause defines what kind of access is appropriate for the PRC. 885 The PIB-ACCESS clause also optionally provides a number which is used in 886 the algorithmic conversion of a PIB to a MIB (see Appendix A). 888 - the value "install" is used to indicate a PRC which a PDP can 889 install in the PEP as policy information. 891 - the value "notify" is used to indicate a PRC for which the PEP must 892 notify the PDP of all its instances and attribute values of that 894 Draft SPPI July 2000 896 PRC. 898 - the value "install-notify" is used to indicate the uncommon type of 899 PRC which has both characteristics: "install" and "notify". 901 8.4. Mapping of the INSTALL-ERRORS clause 903 The INSTALL-ERRORS clause, which may optionally be present for a PRC's 904 table definition, and must be absent otherwise, lists one or more 905 potential reasons for rejecting an install or a removal of an instance 906 of the PRC. Each reason consists of a named-number enumeration, where 907 the number represents a PRC-specific error-code to be used in a COPS 908 protocol message, as the Sub-Error Code, with the Error-Code set to 909 priSpecificError (see [COPS-PR]). The semantics of each named-number 910 enumeration should be described in the PRC's DESCRIPTION clause. 912 The numbers listed in an INSTALL-ERRORS must be greater than zero and 913 less than 65536. If this clause is not present, an install/remove can 914 still fail, but no PRC-specific error is available to be reported. 916 8.5. Mapping of the INDEX clause 918 The INDEX clause, which must be present for a row definition (unless an 919 AUGMENTS or an EXTENDS clause is present instead), and must be absent 920 otherwise, defines identification information for instances of the PRC 921 (unless a PIB-INDEX clause is also present, see below). 923 If a PIB-INDEX clause is absent for the same row definition, then a 924 PRC's INDEX clause includes exactly one descriptor. This descriptor 925 specifies an attribute (typically, but not necessarily of the same PRC) 926 which is used to identify an instance of that PRC. The syntax of this 927 attribute is required to be PolicyInstanceId (a textual convention with 928 an underlying syntax of Unsigned32), and it has no semantics other than 929 its use in identifying the PRC instance. The OBJECT IDENTIFIER which 930 identifies an instance of a PRC is formed by appending one sub- 931 identifier to the OID which identifies that PRC's row definition. The 932 value of the additional sub-identifier is that instance's value of the 933 attribute specified in the INDEX clause. 935 If a PIB-INDEX clause is present for the same row definition, then the 936 INDEX clause can contain any number of attributes, and is used only by 937 the algorithmic conversion of a PIB to a MIB (see Appendix A). 939 Note that SPPI does not permit use of the IMPLIED keyword. 941 Draft SPPI July 2000 943 8.6. Mapping of the PIB-INDEX clause 945 The PIB-INDEX clause, which is optionally present if an INDEX clause is 946 present, and must be absent otherwise, defines identification 947 information for instances of the PRC. 949 If present, a PRC's PIB-INDEX clause includes exactly one descriptor. 950 This descriptor specifies an attribute (typically, but not necessarily 951 of the same PRC) which is used to identify an instance of that PRC. The 952 syntax of this attribute is required to be PolicyInstanceId (a textual 953 convention with an underlying syntax of Unsigned32), and it has no 954 semantics other than its use in identifying the PRC instance. 956 The OBJECT IDENTIFIER which identifies an instance of a PRC is formed by 957 appending one sub-identifier to the OID which identifies that PRC's row 958 definition. The value of the additional sub-identifier is that 959 instance's value of the attribute specified in the PIB-INDEX clause. 961 8.7. Mapping of the AUGMENTS clause 963 The AUGMENTS clause, which must not be present except in row 964 definitions, is an alternative to the INDEX clause and the EXTENDS 965 clause. Every row definition has exactly one of: an INDEX clause, an 966 AUGMENTS clause, or an EXTENDS clause. 968 A row definition which has an INDEX clause is called a base row 969 definition. A row definition which has an AUGMENTS clause is called a 970 row augmentation, where the AUGMENTS clause names the base row 971 definition which is augmented by this row augmentation. (Thus, a row 972 augmentation cannot itself be augmented.) 974 A PRC whose row definition is a row augmentation is called an augmenting 975 PRC. Instances of an augmenting PRC are identified according to the 976 PIB-INDEX clause (or INDEX clause, if PIB-INDEX is absent) of the base 977 row definition named in the AUGMENTS clause. Further, instances of an 978 augmenting PRC exist according to the same semantics as instances of the 979 PRC which it augments. As such, when an instance of a PRC is installed 980 or removed, an instance of every PRC which augments it is also installed 981 or removed (for more details, see [COPS-PR]). 983 8.8. Mapping of the EXTENDS clause 985 The EXTENDS clause, which must not be present except in row definitions, 986 is an alternative to the INDEX clause and the AUGMENTS clause. Every 987 row definition has exactly one of: an INDEX clause, an AUGMENTS clause, 988 Draft SPPI July 2000 990 or an EXTENDS clause. 992 A row definition which has an EXTENDS clause is called a sparse row 993 augmentation, where the EXTENDS clause names the row definition which is 994 sparsely-augmented by this sparse row augmentation. The sparsely- 995 augmented row can be a base row definition, or another sparse row 996 augmentation. 998 A PRC whose row definition is a sparse row augmentation is called a 999 sparsely augmenting PRC. Instances of a sparsely augmenting PRC are 1000 identified according to the EXTENDS clause or the PIB-INDEX clause (or 1001 INDEX clause, if PIB-INDEX is absent) of the row definition named in the 1002 sparsely augmenting PRC's EXTENDS clause. 1004 An instance of a sparsely augmenting PRC can not exist unless a 1005 corresponding instance of the PRC which it sparsely augments exists. As 1006 such, when an instance of a PRC is removed, an instance of any PRC which 1007 sparsely augments it is also removed. 1009 8.8.1. Relation between INDEX, AUGMENTS and EXTENDS clauses 1011 When defining instance identification information for a PRC: 1013 - If there is a one-to-one correspondence between instances of this 1014 PRC and instances of an existing PRC, then the AUGMENTS clause 1015 should be used. 1017 - Otherwise, if there is a sparse relationship between instances of 1018 this PRC and instances of an existing PRC, then an EXTENDS clause 1019 should be used. 1021 - Otherwise, an INDEX or PIB-INDEX clause should be used which names 1022 its own PolicyInstanceId attribute. 1024 8.9. Mapping of the UNIQUENESS clause 1026 The UNIQUENESS clause, which must be present for any row definition 1027 which has an INDEX clause, and must be absent otherwise, lists a set of 1028 zero or more of the PRC's attributes, for which no two instances of the 1029 PRC can have the same set of values. The specified set of attributes 1030 provide a necessary and sufficient set of values by which to identify an 1031 instance of this PRC. The attribute contained in the PIB-INDEX clause 1032 (or INDEX clause, if a PIB-INDEX clause is absent) may not be present in 1033 Draft SPPI July 2000 1035 the UNIQUENESS clause. By definition, an attribute may not appear more 1036 than once in a UNIQUENESS clause. A UNIQUENESS clause containing zero 1037 attributes indicates that it's possible for two instances of the PRC to 1038 have identical values for all attributes except, of course, for the one 1039 named in the PIB-INDEX clause (or INDEX clause, if a PIB-INDEX clause is 1040 absent). 1042 8.10. Mapping of the PIB-REFERENCES clause 1044 The PIB-REFERENCES clause, which must be present for any attribute which 1045 has the SYNTAX of PolicyReferenceId, and must be absent otherwise, names 1046 the PRC, an instance of which is referenced by the PolicyReferenceId 1047 attribute. For example usages of the PIB-REFERENCE clause, see Appendix 1048 B. 1050 8.11. Mapping of the PIB-TAG clause 1052 The PIB-TAG clause, which must be present for an attribute which has the 1053 SYNTAX PolicyTagReference, and must be absent otherwise, is used 1054 indicate that this attribute references a "tag list" of instances of 1055 another PRC. Such a tag list (similar in concept to the usage of the 1056 same term in [APPL]) is formed by all instances of the other PRC which 1057 have the same (tag) value of a particular attribute of that other PRC. 1058 The particular attribute of the other PRC, which must have the SYNTAX 1059 PolicyTagId, is named in the PIB-TAG clause. For an example usage of 1060 the PIB-TAG clause, see Appendix B. 1062 Draft SPPI July 2000 1064 9. Mapping of the OBJECT-IDENTITY macro 1066 The SMI's ASN.1 macro, OBJECT-IDENTITY [SMI], is used in PIB modules to 1067 define information about an OBJECT IDENTIFIER assignment. 1069 10. Textual Conventions 1071 When designing a PIB module, it is often useful to define new data types 1072 similar to those defined in the SPPI. In comparison to a type defined 1073 in the SPPI, each of these new types has a different name, a similar 1074 syntax, and specific semantics. These newly defined types are termed 1075 textual conventions, and are used for the convenience of humans reading 1076 the PIB module. 1078 Attributes defined using a textual convention are always encoded by 1079 means of the rules that define their underlying type. The TEXTUAL- 1080 CONVENTION (see below) is used in PIB modules to define the syntax and 1081 semantics of a textual convention. 1083 11. Mapping of the OBJECT-GROUP macro 1085 For conformance purposes, it is useful to define a conformance group as 1086 a collection of related PRCs and their attributes. The SPPI uses the 1087 SMI's OBJECT-GROUP macro as the means to directly define the collection 1088 of attributes which belong to a conformance group. Since each attribute 1089 included in the collection belongs to a PRC, the collection of related 1090 PRCs which belong to a conformance group is also specified (indirectly) 1091 as the set of PRCs to which the included attributes belong. 1093 11.1. Mapping of the OBJECTS clause 1095 The OBJECTS clause, which must be present, is used to specify each 1096 attribute contained in the conformance group. Each of the specified 1097 attributes must be defined in the same PIB module as the OBJECT-GROUP 1098 macro appears. 1100 It is required that every attribute defined in a PIB module be contained 1101 in at least one conformance group. This avoids the common error of 1102 adding a new attribute to a module and forgetting to add the new 1103 attribute to a group. 1105 Draft SPPI July 2000 1107 12. Mapping of the MODULE-COMPLIANCE macro 1109 The MODULE-COMPLIANCE macro is used to convey a minimum set of 1110 requirements with respect to implementation of one or more PIB modules. 1112 A requirement on all "standard" PIB modules is that a corresponding 1113 MODULE-COMPLIANCE specification is also defined, either in the same 1114 module or in a companion module. 1116 12.1. Mapping of the MODULE clause 1118 The MODULE clause, which must be present, is repeatedly used to name 1119 each PIB module for which compliance requirements are being specified. 1120 Each PIB module is named by its module name, and optionally, by its 1121 associated OBJECT IDENTIFIER as well. The module name can be omitted 1122 when the MODULE-COMPLIANCE invocation occurs inside a PIB module, to 1123 refer to the encompassing PIB module. 1125 12.1.1. Mapping of the MANDATORY-GROUPS clause 1127 The MANDATORY-GROUPS clause, which need not be present, names the one or 1128 more conformance groups within the correspondent PIB module which are 1129 unconditionally mandatory for implementation. If an agent claims 1130 compliance to the PIB module, then it must implement each and every 1131 attribute (and therefore the PRCs to which they belong) within each 1132 conformance group listed. 1134 12.1.2. Mapping of the GROUP clause 1136 The GROUP clause, which need not be present, is repeatedly used to name 1137 each conformance group which is conditionally mandatory for compliance 1138 to the PIB module. The GROUP clause can also be used to name 1139 unconditionally optional groups. A group named in a GROUP clause must 1140 be absent from the correspondent MANDATORY-GROUPS clause. 1142 Conditionally mandatory groups include those which are mandatory only if 1143 a particular protocol is implemented, or only if another group is 1144 implemented. A GROUP clause's DESCRIPTION specifies the conditions 1145 under which the group is conditionally mandatory. 1147 A group which is named in neither a MANDATORY-GROUPS clause nor a GROUP 1148 clause, is unconditionally optional for compliance to the PIB module. 1150 Draft SPPI July 2000 1152 12.1.3. Mapping of the OBJECT clause 1154 The OBJECT clause, which need not be present, is repeatedly used to 1155 specify each attribute for which compliance has a refined requirement 1156 with respect to the PIB module definition. The attribute must be 1157 present in one of the conformance groups named in the correspondent 1158 MANDATORY-GROUPS clause or GROUP clauses. 1160 By definition, each attribute specified in an OBJECT clause follows a 1161 MODULE clause which names the PIB module in which that attribute is 1162 defined. Therefore, the use of an IMPORTS statement, to specify from 1163 where such attributes are imported, is redundant and is not required in 1164 a PIB module. 1166 12.1.3.1. Mapping of the SYNTAX clause 1168 The SYNTAX clause, which need not be present, is used to provide a 1169 refined SYNTAX for the attribute named in the correspondent OBJECT 1170 clause. The refined syntax is the minimum level of support needed for 1171 this attribute in order to be compliant. 1173 12.1.3.2. Mapping of the WRITE-SYNTAX clause 1175 The WRITE-SYNTAX clause is not supported by the SPPI. 1177 12.1.3.3. Mapping of the PIB-MIN-ACCESS clause 1179 The PIB-MIN-ACCESS clause, which need not be present, is used to define 1180 the minimal level of access for the attribute named in the correspondent 1181 OBJECT clause. If this clause is absent, the minimal level of access is 1182 the same as the maximal level specified in the PIB-ACCESS clause of the 1183 correspondent invocation of the OBJECT-TYPE macro. If present, this 1184 clause must specify a subset of the access specified in the 1185 correspondent PIB-ACCESS clause, where: "install" is a subset of 1186 "install-notify", "notify" is a subset of "install-notify", and "not- 1187 accessible" is a subset of all other values. 1189 An implementation is compliant if the level of access it provides is the 1190 same or a superset of the minimal level in the MODULE-COMPLIANCE macro 1191 and the same or a subset of the maximal level in the PIB-ACCESS clause. 1193 Draft SPPI July 2000 1195 13. Mapping of the TEXTUAL-CONVENTION macro 1197 The TEXTUAL-CONVENTION macro is used to convey the syntax and semantics 1198 associated with a textual convention. It should be noted that the 1199 expansion of the TEXTUAL-CONVENTION macro is something which 1200 conceptually happens during implementation and not during run-time. 1202 The name of a textual convention must consist of one or more letters or 1203 digits, with the initial character being an upper case letter. The name 1204 must not conflict with any of the reserved words listed in section 3.7 1205 of [2], should not consist of all upper case letters, and shall not 1206 exceed 64 characters in length. (However, names longer than 32 1207 characters are not recommended.) The hyphen is not allowed in the name 1208 of a textual convention (except for use in information modules converted 1209 from SMIv1 which allowed hyphens in ASN.1 type assignments). Further, 1210 all names used for the textual conventions defined in all "standard" PIB 1211 modules shall be unique. 1213 13.1. Mapping of the SYNTAX clause 1215 The SYNTAX clause, which must be present, defines abstract data 1216 structure corresponding to the textual convention. The data structure 1217 must be one of the following: a base type (see the SYNTAX clause of an 1218 OBJECT-TYPE macro), or the BITS construct. Note that this means that 1219 the SYNTAX clause of a Textual Convention can not refer to a previously 1220 defined Textual Convention. 1222 13.1.1. Sub-typing of Textual Conventions 1224 The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in the 1225 same way as the SYNTAX clause of an OBJECT-TYPE macro. 1227 Draft SPPI July 2000 1229 14. Extending a PIB Module 1231 The SMI's rules for extending an information module are augmented with 1232 the following rules: 1234 14.1. OBJECT-TYPE Definitions 1236 An invocation of the OBJECT-TYPE macro may also be revised in any of the 1237 following ways: 1239 - An INSTALL-ERRORS clause may be added or an existing INSTALL-ERRORS 1240 clause have additional errors defined. 1242 - Additional named-number enumerations may be added to a SUBJECT- 1243 CATEGORIES clause. 1245 Draft SPPI July 2000 1247 15. Appendix A: Mapping a PIB to a MIB 1249 Since the SPPI is modelled on the SMI, a PIB can be easily and 1250 algorithmically mapped into a MIB. This mapping is achieved by means of 1251 the following rules: 1253 - Modify the module's module name by appending "-MIB" to the name. 1255 - Replace the keyword PIB-DEFINITIONS with the keyword DEFINITIONS. 1257 - Modify the module names of all external references to PIB modules 1258 (as identified in the PIB-MODULES clause) by appending "-MIB" to 1259 each such module name. 1261 - Delete all of the following clauses: PIB-MODULES, PIB-ACCESS, PIB- 1262 INDEX, PIB-REFERENCES, PIB-TAG, UNIQUENESS, INSTALL-ERRORS, and 1263 SUBJECT-CATEGORIES. 1265 - Change all PIB-MIN-ACCESS clauses to MIN-ACCESS clauses, modifying 1266 "install" and "install-notify" to "read-create", and "notify" to 1267 "read-only". 1269 - Add a MAX-ACCESS clause for each OBJECT-TYPE. For each table 1270 definition and row definition, the MAX-ACCESS is "not-accessible". 1271 For each attribute that is in the INDEX clause, the MAX-ACCESS is 1272 "not-accessible". For the remaining attributes, the MAX-ACCESS is 1273 "read-create". 1275 - Add a columnar attribute of type RowStatus with name status. The 1276 optional number provided by the PIB-ACCESS clause is used as the 1277 OID for this columnar attribute. If no number is provided by the 1278 PIB-ACCESS clause, then the default number 1 is used. 1280 - Modify any SYNTAX clause which has a base data type which is not 1281 allowed in the SMI to be an OCTET STRING of the relevant size. 1282 Specifically, both Integer64 and Unsigned64 are mapped to OCTET 1283 STRING (SIZE(8)). 1285 (Note that the mapping of Integer64 and Unsigned64 to OCTET STRINGs is a 1286 compromise, which is considered superior to both 1288 - omitting them from the conversion, and 1290 - mapping them to Counter64, which not only has problems representing 1291 negative numbers, but also has unwanted counter semantics.) 1293 Draft SPPI July 2000 1295 16. Appendix B: Example usage of PIB-REFERENCE and PIB-TAG clauses 1297 The following example demonstrates the use of the PIB-REFERENCE and PIB- 1298 TAG clauses. 1300 In this example, the PIB-REFERENCE clause is used by the 1301 qosIfDscpMapQueue attribute to indicate the PRC of which it references 1302 an instance, and similarly, by the qosIfDscpMapThresh attribute. 1304 The qosIfDscpMapTable PRC has an instance for each DSCP of a particular 1305 "map", but there is no PRC defined for a map itself; rather, a map 1306 consists of all instances of qosIfDscpMapTable which have the same value 1307 of qosIfDscpMapMapId. That is, a tag list is formed by all instances of 1308 qosIfDscpMapTable which have the same value of qosIfDscpMapMapId. This 1309 tag list is referenced by the attribute qosIfDscpAssignDscpMap, and its 1310 use of the PIB-TAG clause indicates this. 1312 qosIfDscpAssignTable OBJECT-TYPE 1313 SYNTAX SEQUENCE OF QosIfDscpAssignEntry 1314 PIB-ACCESS install 1315 STATUS current 1316 DESCRIPTION " " 1317 ::= { qosIfParameters 9 } 1319 qosIfDscpAssignEntry OBJECT-TYPE 1320 SYNTAX QosIfDscpAssignEntry 1321 STATUS current 1322 DESCRIPTION 1323 "An instance of the qosIfDscpAssign class." 1324 INDEX { qosIfDscpAssignPrid } 1325 UNIQUENESS { qosIfDscpAssignName, qosIfDscpAssignRoles } 1326 ::= { qosIfDscpAssignTable 1 } 1328 QosIfDscpAssignEntry ::= SEQUENCE { 1329 qosIfDscpAssignPrid PolicyInstanceId, 1330 qosIfDscpAssignName SnmpAdminString, 1331 qosIfDscpAssignRoles RoleCombination, 1332 qosIfDscpAssignDscpMap PolicyTagReference 1333 } 1335 qosIfDscpAssignDscpMap OBJECT-TYPE 1336 SYNTAX PolicyTagReference 1337 PIB-TAG qosIfDscpMapMapId -- attribute defined below 1338 STATUS current 1339 DESCRIPTION 1341 Draft SPPI July 2000 1343 "The DSCP map which is applied to interfaces of type 1344 qosIfDscpAssignName which have a role combination of 1345 qosIfDscpAssignRoles." 1346 ::= { qosIfDscpAssignEntry 3 } 1348 -- 1349 -- DSCP to Queue and Threshold Mapping Table 1350 -- 1352 qosIfDscpMapTable OBJECT-TYPE 1353 SYNTAX SEQUENCE OF QosIfDscpMapEntry 1354 PIB-ACCESS install 1355 STATUS current 1356 DESCRIPTION 1357 "Assigns DSCP values to queues and thresholds for an arbitrary 1358 DSCP map. This map can then be assigned to various interface 1359 and role combination pairs." 1360 ::= { qosIfParameters 10 } 1362 qosIfDscpMapEntry OBJECT-TYPE 1363 SYNTAX QosIfDscpMapEntry 1364 STATUS current 1365 DESCRIPTION 1366 "An instance of the qosIfDscpMap class." 1367 INDEX { qosIfDscpMapPrid } 1368 UNIQUENESS { qosIfDscpMapMapId, qosIfDscpMapDscp } 1369 ::= { qosIfDscpMapTable 1 } 1371 QosIfDscpMapEntry ::= SEQUENCE { 1372 qosIfDscpMapPrid PolicyInstanceId, 1373 qosIfDscpMapMapId INTEGER, 1374 qosIfDscpMapDscp Dscp, 1375 qosIfDscpMapQueue PolicyReferenceId, 1376 qosIfDscpMapThresh PolicyReferenceId 1377 } 1379 qosIfDscpMapMapId OBJECT-TYPE 1380 SYNTAX PolicyTagId 1381 STATUS current 1382 DESCRIPTION 1383 "An integer that identifies the DSCP map to which this PRI 1384 belongs." 1385 ::= { qosIfDscpMapEntry 2 } 1387 qosIfDscpMapQueue OBJECT-TYPE 1388 Draft SPPI July 2000 1390 SYNTAX PolicyReferenceId 1391 PIB-REFERENCE qosIfQueueTable 1392 STATUS current 1393 DESCRIPTION 1394 "This attribute maps the DSCP specified by qosIfDscpMapDscp to 1395 the queue identified by qosIfQueuePrid in qosIfQueueTable. 1396 For a given DSCP map, all the queues must belong to a single 1397 queue set." 1398 ::= { qosIfDscpMapEntry 4 } 1400 qosIfDscpMapThresh OBJECT-TYPE 1401 SYNTAX PolicyReferenceId 1402 PIB-REFERENCE qosIfThresholdTable 1403 STATUS current 1404 DESCRIPTION 1405 "This attribute maps the DSCP specified by qosIfDscpMapDscp to 1406 the threshold identified by qosIfThresholdId in 1407 qosIfThresholdTable. The threshold set to which this 1408 threshold belongs must be assigned to the queue specified by 1409 qosIfDscpMapQueue." 1410 ::= { qosIfDscpMapEntry 5 } 1412 Draft SPPI July 2000 1414 17. Security Considerations 1416 This document defines a language with which to define policy 1417 information. The language itself has no security impact on the 1418 Internet. 1420 18. Authors' Addresses 1422 Keith McCloghrie 1423 Cisco Systems, Inc. 1424 170 West Tasman Drive 1425 San Jose, CA 95134-1706 USA 1426 Phone: +1 408 526 5260 1427 Email: kzm@cisco.com 1429 Michael Fine 1430 Cisco Systems, Inc. 1431 170 West Tasman Drive 1432 San Jose, CA 95134-1706 USA 1433 Phone: +1 408 527 8218 1434 Email: mfine@cisco.com 1436 John Seligson 1437 Nortel Networks, Inc. 1438 4401 Great America Parkway 1439 Santa Clara, CA 95054 USA 1440 Phone: +1 408 495 2992 1441 Email: jseligso@nortelnetworks.com 1443 Kwok Ho Chan 1444 Nortel Networks, Inc. 1445 600 Technology Park Drive 1446 Billerica, MA 01821 USA 1447 Phone: +1 978 288 8175 1448 Email: khchan@nortelnetworks.com 1450 Scott Hahn 1451 Intel 1452 2111 NE 25th Avenue 1453 Hillsboro, OR 97124 USA 1454 Phone: +1 503 264 8231 1455 Email: scott.hahn@intel.com 1457 Draft SPPI July 2000 1459 Ravi Sahita 1460 Intel 1461 2111 NE 25th Avenue 1462 Hillsboro, OR 97124 USA 1463 Phone: +1 503 264 8231 1464 Email: ravi.sahita@intel.com 1466 Andrew Smith 1467 Fax: +1 415 345 1827 1468 Email: ah_smith@pacbell.net 1470 Francis Reichmeyer 1471 IPHighway Inc. 1472 Parker Plaza, 16th Floor 1473 400 Kelby St, Fort-Lee, NJ 07024 USA 1474 Phone: (201) 585-0800 1475 Email: FranR@iphighway.com 1477 19. References 1479 [COPS] 1480 Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. 1481 Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748, 1482 January 2000. 1484 [COPS-RSVP] 1485 Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. 1486 Sastry, " COPS usage for RSVP", RFC 2749, January 2000. 1488 [COPS-PR] 1489 Reichmeyer, F., Herzog, S., Chan, K., Durham, D., Yavatkar, R. 1490 Gai, S., McCloghrie, K. and A. Smith, "COPS Usage for Policy 1491 Provisioning" Internet Draft, draft-ietf-rap-cops-pr-03.txt, July 1492 2000. 1494 [SMI] 1495 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1496 and S. Waldbusser. "Structure of Management Information Version 2 1497 (SMIv2)", RFC 2578, April 1999. 1499 [TC] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1500 and S. Waldbusser. "Textual Conventions for SMIv2", RFC 2579, 1501 April 1999. 1503 Draft SPPI July 2000 1505 [CONF] 1506 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1507 and S. Waldbusser. "Conformance Statements for SMIv2", RFC 2580, 1508 April 1999. 1510 [APPL] 1511 Levi, D., Meyer, P., and B. Stewart, "SNMP Applications", RFC 2573, 1512 April 1999. 1514 [ASN1] 1515 Information processing systems -- Open Systems Interconnection -- 1516 Specification of Abstract Syntax Notation One (ASN.1), 1517 International Organization for Standardization. International 1518 Standard 8824, December 1987. 1520 Draft SPPI July 2000 1522 20. Full Copyright Statement 1524 Copyright (C) The Internet Society (1999). All Rights Reserved. 1526 This document and translations of it may be copied and furnished to 1527 others, and derivative works that comment on or otherwise explain it or 1528 assist in its implementation may be prepared, copied, published and 1529 distributed, in whole or in part, without restriction of any kind, 1530 provided that the above copyright notice and this paragraph are included 1531 on all such copies and derivative works. However, this document itself 1532 may not be modified in any way, such as by removing the copyright notice 1533 or references to the Internet Society or other Internet organizations, 1534 except as needed for the purpose of developing Internet standards in 1535 which case the procedures for copyrights defined in the Internet 1536 Standards process must be followed, or as required to translate it into 1537 languages other than English. 1539 The limited permissions granted above are perpetual and will not be 1540 revoked by the Internet Society or its successors or assigns. 1542 This document and the information contained herein is provided on an "AS 1543 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1544 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1545 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1546 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1547 FITNESS FOR A PARTICULAR PURPOSE." 1548 Draft SPPI July 2000 1550 Table of Contents 1552 1 Introduction .................................................... 2 1553 1.1 Change Log .................................................... 2 1554 1.1.1 Changes made in version published on 13 July 2000 ........... 2 1555 2 Use of the SMI .................................................. 3 1556 2.1 Terminology Translation ....................................... 3 1557 2.2 Overview ...................................................... 3 1558 3 Structure of this Specification ................................. 4 1559 4 Definitions ..................................................... 5 1560 5 PIB Modules ..................................................... 17 1561 5.1 Importing Definitions ......................................... 17 1562 5.2 Reserved Keywords ............................................. 18 1563 6 Naming Hierarchy ................................................ 18 1564 7 Mapping of the MODULE-IDENTITY macro ............................ 18 1565 7.1 Mapping of the SUBJECT-CATEGORIES clause ...................... 18 1566 7.2 Mapping of the PIB-MODULES clause ............................. 19 1567 8 Mapping of the OBJECT-TYPE macro ................................ 19 1568 8.1 Mapping of the SYNTAX clause .................................. 19 1569 8.1.1 Counter32 ................................................... 20 1570 8.1.2 Gauge32 ..................................................... 20 1571 8.1.3 Opaque ...................................................... 20 1572 8.1.4 Counter64 ................................................... 20 1573 8.1.5 Integer64 ................................................... 20 1574 8.1.6 Unsigned64 .................................................. 20 1575 8.1.7 Policy Rule Classes ......................................... 20 1576 8.2 Mapping of the MAX-ACCESS clause .............................. 21 1577 8.3 Mapping of the PIB-ACCESS clause .............................. 21 1578 8.4 Mapping of the INSTALL-ERRORS clause .......................... 22 1579 8.5 Mapping of the INDEX clause ................................... 22 1580 8.6 Mapping of the PIB-INDEX clause ............................... 23 1581 8.7 Mapping of the AUGMENTS clause ................................ 23 1582 8.8 Mapping of the EXTENDS clause ................................. 23 1583 8.8.1 Relation between INDEX, AUGMENTS and EXTENDS clauses ........ 24 1584 8.9 Mapping of the UNIQUENESS clause .............................. 24 1585 8.10 Mapping of the PIB-REFERENCES clause ......................... 25 1586 8.11 Mapping of the PIB-TAG clause ................................ 25 1587 9 Mapping of the OBJECT-IDENTITY macro ............................ 26 1588 10 Textual Conventions ............................................ 26 1589 11 Mapping of the OBJECT-GROUP macro .............................. 26 1590 11.1 Mapping of the OBJECTS clause ................................ 26 1591 12 Mapping of the MODULE-COMPLIANCE macro ......................... 27 1592 12.1 Mapping of the MODULE clause ................................. 27 1593 12.1.1 Mapping of the MANDATORY-GROUPS clause ..................... 27 1594 Draft SPPI July 2000 1596 12.1.2 Mapping of the GROUP clause ................................ 27 1597 12.1.3 Mapping of the OBJECT clause ............................... 28 1598 12.1.3.1 Mapping of the SYNTAX clause ............................. 28 1599 12.1.3.2 Mapping of the WRITE-SYNTAX clause ....................... 28 1600 12.1.3.3 Mapping of the PIB-MIN-ACCESS clause ..................... 28 1601 13 Mapping of the TEXTUAL-CONVENTION macro ........................ 29 1602 13.1 Mapping of the SYNTAX clause ................................. 29 1603 13.1.1 Sub-typing of Textual Conventions .......................... 29 1604 14 Extending a PIB Module ......................................... 30 1605 14.1 OBJECT-TYPE Definitions ...................................... 30 1606 15 Appendix A: Mapping a PIB to a MIB ............................. 31 1607 16 Appendix B: Example usage of PIB-REFERENCE and PIB-TAG claus- 1608 es ........................................................... 32 1609 17 Security Considerations ........................................ 35 1610 18 Authors' Addresses ............................................. 35 1611 19 References ..................................................... 36 1612 20 Full Copyright Statement ....................................... 38