idnits 2.17.1 draft-ietf-snmpconf-diffpolicy-09.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 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 == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 22 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 973: '... It is RECOMMENDED that implementers...' RFC 2119 keyword, line 979: '... RECOMMENDED. Instead, deployment o...' RFC 2119 keyword, line 980: '...urity enabled is RECOMMENDED. It is t...' 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 (November 2003) is 7467 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3411' is defined on line 1100, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-snmpconf-pm-13 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Differentiated Services Configuration MIB November 2003 4 Internet Engineering Task Force H. Hazewinkel 5 INTERNET-DRAFT I.Net 6 Expires May 2004 D. Partain 7 Ericsson 8 November 2003 10 The Differentiated Services Configuration MIB 11 draft-ietf-snmpconf-diffpolicy-09.txt 12 November 2003 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This document is a product of the IETF's Configuration Management 36 with SNMP Working Group. Comments should be addressed to WG's 37 mailing list at snmpconf@snmp.com. The charter for the Working Group 38 may be found at http://www.ietf.org/html.charters/snmpconf- 39 charter.html 41 Distribution of this memo is unlimited. 43 Copyright Notice 45 Copyright (C) The Internet Society (2003). All Rights Reserved. 47 Abstract 49 This memo describes a MIB module that provides a conceptual layer 50 between high-level "network-wide" policy definitions that effect 51 configuration of the Differentiated Services (diffserv) subsystem and 52 the instance-specific information that would include such details as 53 the parameters for all the queues associated with each interface in a 54 system. This essentially provides an interface for configuring 55 differentiated services at a conceptually higher layer than that of 56 the Differentiated Services MIB. 58 Table of Contents 60 1 The Internet-Standard Management Framework ................... 4 61 2 Introduction ................................................. 4 62 3 Other Documents .............................................. 5 63 4 Relationship to other MIBs ................................... 5 64 4.1 The Policy-based Management MIB Module ..................... 5 65 4.2 The Differentiated Services MIB Module ..................... 5 66 5 The Differentiated Services Configuration MIB Module Design 67 ........................................................... 6 68 6 Template Cloning ............................................. 8 69 6.1 An Approach to Template Cloning ............................ 8 70 6.2 Example .................................................... 9 71 6.2.1 The Initial Situation .................................... 11 72 6.2.2 The Configuration Template ............................... 12 73 6.2.3 Applying the Template .................................... 14 74 6.2.4 Applying the Template Using SNMP Messages ................ 17 75 7 Managed Objects Definitions (MIB Module) ..................... 18 76 8 Security Considerations ...................................... 25 77 9 Acknowledgments .............................................. 26 78 10 Editors' Addresses .......................................... 26 79 11 Full Copyright Statement .................................... 26 80 12 Intellectual Property ....................................... 27 81 13 Informative References ...................................... 28 82 14 Normative References ........................................ 29 84 1. The Internet-Standard Management Framework 86 For a detailed overview of the documents that describe the current 87 Internet-Standard Management Framework, please refer to section 7 of 88 RFC 3410 [RFC3410]. 90 Managed objects are accessed via a virtual information store, termed 91 the Management Information Base or MIB. MIB objects are generally 92 accessed through the Simple Network Management Protocol (SNMP). 93 Objects in the MIB are defined using the mechanisms defined in the 94 Structure of Management Information (SMI). This memo specifies a MIB 95 module that is compliant to the SMIv2, which is described in STD 58, 96 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 97 [RFC2580]. 99 2. Introduction 101 This memo defines a MIB module that can be used to convey management 102 information about desired network-wide Differentiated Services based 103 policy behavior. This module is designed to integrate with the 104 Differentiated Services MIB module [RFC3289] in order to provide 105 template configurations for the Differentiated Services MIB module. 106 The MIB module defined in this memo (the DIFFSERV-CONFIG-MIB) may be 107 used in combination with the Policy-based Management MIB module 108 [PMMIBDR], but that is not a requirement. Without the Policy-based 109 Management MIB module, a management application must emulate behavior 110 provided by the Policy-based Management MIB using equivalent "low- 111 level" SNMP operations in normal manager/agent communication. 113 Together, this memo and [RFC3289] and [PMMIBDR] represent an instance 114 of an integrated architecture for both device-specific and network- 115 wide policy (configuration) management which is fully integrated with 116 the Internet Standard Management Framework. 118 The Differentiated Services MIB module [RFC3289] operates on a device 119 level. The MIB module in this memo, the DIFFSERV-CONFIG-MIB, creates 120 a coherent configuration management view as an umbrella over 121 [RFC3289]. That is, the DIFFSERV-CONFIG-MIB provides a conceptual 122 API for configuration of Differentiated Services parameters. Since 123 the Differentiated Services MIB module is able to maintain 124 configuration information, the DIFFSERV-CONFIG-MIB configuration API 125 consists only of configuration template information and the start of 126 the so-called functional datapath. 128 3. Other Documents 130 It is assumed that the reader is familiar with Differentiated 131 Services ([RFC2474] and [RFC2475]), the Policy-based Management MIB 132 ([PMMIBDR]) and "Configuring Networks and Devices With SNMP" 133 ([RFC3512]). These documents include all of the necessary 134 terminology for understanding this memo. Note, though, that use of 135 the MIB module in this memo does not require the use of [PMMIBDR]. 136 [RFC3512] also provides an example MIB module which may help in 137 understanding the relationship between DIFFSERV-CONFIG-MIB and the 138 Differentiated Services MIB in [RFC3289]. 140 4. Relationship to other MIBs 142 In this section we describe the relationship of this MIB module to 143 other MIB modules. The overall architecture used for policy 144 configuration management is described in [PMMIBDR]. 146 4.1. The Policy-based Management MIB Module 148 [PMMIBDR] defines a MIB module that enables policy-based 149 configuration management of infrastructure using the Internet 150 Standard Management Framework. The document includes a table for 151 configuring policies to be implemented, tables for storing the roles 152 of elements on a particular device, a table for representing the 153 capabilities of a device with respect to policy management, a table 154 for referencing elements affected by a policy, as well as other 155 infrastructure. There is no requirement that [PMMIBDR] be used in 156 conjunction with the MIB module defined in this memo. 158 See [PMMIBDR] for a full description of the policy-based 159 configuration framework it provides. 161 4.2. The Differentiated Services MIB Module 163 The Differentiated Services MIB module [RFC3289] provides a common 164 set of managed objects useful for configuring Differentiated Services 165 parameters on a Differentiated Services capable device. This is what 166 is referred to as instance-level configuration. It is the alteration 167 of the instance-level information in that MIB module which may be 168 done via the objects provided by the Differentiated Services 169 Configuration MIB module defined in this memo. 171 It is recognized that vendors may include additional managed objects 172 in their devices (via vendor-specific MIB modules) for configuring 173 Differentiated Services parameters. If a vendor chooses to use the 174 objects defined in this memo for configuration, the vendor should 175 provide additional managed objects in a similar approach as defined 176 for the Differentiated Services MIB module. 178 Since the managed objects of the Differentiated Services MIB 179 [RFC3289] are not directly associated with an instance (interface and 180 interface direction), the same managed objects can be used for 181 traffic treatment configuration templates in a Differentiated 182 Services capable device and can then be applied on multiple 183 instances. Therefore, the tables as defined in the Differentiated 184 Services MIB can directly be used for template configuration 185 purposes. Those tables are: 187 - diffServClfrTable 188 - diffServClfrElementTable 189 - diffServMultiFieldClfrTable 190 - diffServMeterTable 191 - diffServTBParamTable 192 - diffServActionTable 193 - diffServDscpMarkActTable 194 - diffServCountActTable 195 - diffServAlgDropTable 196 - diffServRandomDropTable 197 - diffServQTable 198 - diffServSchedulerTable 199 - diffServMinRateTable 200 - diffServMaxRateTable 202 Readers familiar with the Differentiated Services MIB will notice 203 that these are all templates. Only the diffServDataPathTable defines 204 a managed instance for Differentiated Services traffic treatment by 205 its indexes of the interface and its interface direction. This also 206 allows the tables mentioned above to be used as a configuration 207 template without defining anything directly related to a managed 208 instance. 210 5. The Differentiated Services Configuration MIB Module Design 212 The Differentiated Services Configuration MIB module (in this memo) 213 of the SNMP-based configuration management framework is positioned 214 between the Policy-based Management MIB module and the instance- 215 specific Differentiated Services MIB module as described above. 217 The MIB module found in this memo is designed to maintain 218 configuration templates for the Differentiated Services MIB [RFC3289] 219 module. The module only has a template table that describes a 220 Differentiated Services traffic treatment by providing the starting 221 pointer of the functional datapath. The templates represent a 222 specific configuration of traffic treatment in a functional datapath 223 of a Differentiated Services capable device. To avoid duplication of 224 managed objects, the actual templates defining the functional 225 datapath are defined in the Differentiated Services MIB module. 226 These are also used for the management of the instances. Therefore, 227 the implementation of the DIFFSERV-CONFIG-MIB module uses the tables 228 defined in the Differentiated Services MIB. As soon as a 229 configuration is made active via the POLICY-MANAGEMENT-MIB or using 230 normal SNMP operations, the configuration defined within this MIB 231 module will be instantiated in the DIFFSERV-MIB. 233 Note that this is a conceptual process. That is, the configuration 234 may not actually go through an API available in the subsystem which 235 implements the DIFFSERV-MIB module. However, configuration via the 236 DIFFSERV-CONFIG-MIB module will alter the same instrumentation as the 237 DIFFSERV-MIB module whether it does it via the DIFFSERV-MIB module or 238 not. 240 The Differentiated Services Configuration MIB module only needs to 241 define a starting point of a traffic treatment configuration 242 template. This table is similar to the diffServDataPathTable 243 [RFC3289]. However, it has a semantic difference in that the 244 diffServDataPathTable is associated with an instance (interface and 245 interface direction), whereas the diffServConfigTable in this memo is 246 not. 248 Unlike most MIB modules, changes to the managed objects in this MIB 249 module do not cause a change in the external/traffic behavior of the 250 device. This MIB module is used to set up per-hop-behavior 251 configurations. As soon as configurations are made active via the 252 POLICY-MANAGEMENT-MIB or SNMP operations, the configurations defined 253 within this MIB module will be instantiated in the DIFFSERV-MIB. 255 The only table in this MIB module is the diffServConfigTable, which 256 provides managed objects for registering traffic treatment 257 configurations used in differentiated services. The sole purpose of 258 this table is to provide the starting point for a traffic treatment 259 configuration template. The traffic treatment itself is performed by 260 functional datapath elements [RFC3289]. 262 6. Template Cloning 264 The concept of the DIFFSERV-CONFIG-MIB is based on having traffic 265 treatment configuration templates. The templates provide a set of 266 configuration values that provide a particular behavior, such as 267 Expedited Forwarding traffic treatment, in the functional datapath. 268 The template (or functional datapath) is similar to a linked list 269 from a starting point and each (functional datapath) element is 270 connected to the next element via a so-called the element. 272 The moment a template is activated (instantiated) on an interface and 273 its interface direction, the template needs to be copied/cloned, so 274 that the template remains as a template. Note that the template is 275 logically "locked" through the cloning process. That is, the 276 template cannot be changed part way through the cloning process. 277 With the exception of the indices, the cloned template will be 278 identical to the source template. 280 A literal copy/clone of the template would not be possible, since the 281 same indexes inside the element tables cannot be re-used. The 282 instantiation process must therefore generate a new index for each 283 element. As a result of this, the 'NEXT' pointers also need to be 284 updated. Otherwise, those will point to the template. 286 6.1. An Approach to Template Cloning 288 What should a system containing Differentiated Services capabilities 289 and Differentiated Services configuration capabilities do 290 conceptually at the moment a template is activated on an interface? 291 The following approach should not be considered implementation 292 guidelines, but rather a conceptual explanation of what should be 293 done. 295 1) Get the index of the template to be activated 296 2) Get RowPointer (current) from 297 diffServConfigStart.index 298 of the diffServConfigTable 299 3) Check if RowPointer (current) exists 300 4) Logically "lock" the entry pointed to by RowPointer so 301 that its values are not changed part way through the 302 cloning process. 304 5) Copy/Clone the entry pointed to by RowPointer 305 a) Get a new index for the entry 306 b) Configure the new entry with the values 307 of the entry to be cloned 308 c) Update the NEXT pointer with a new RowPointer 309 that pointed to the previous entry that was copied 310 part of this template 311 6) Store RowPointer of cloned entry as previous 312 7) Get the RowPointer of the next element in the template 313 as current 314 8) If current RowPointer does not equal zeroDotZero go to 4 315 9) "Unlock" the entry pointed to by RowPointer 317 If a configuration/template is activated via a means other than a 318 direct SNMP SET request, such as via the Policy-based Management MIB, 319 the handling of the activation and potential error response code must 320 be provided via that mechanism. If a configuration/template is 321 activated using SNMP SET requests, an accurate error response value 322 must be returned. For example, if a configuration/template has 323 inconsistent values, the SNMP SET should return an the configuration 324 is already finished is not of direct influence, since the SNMP SET 325 response must be accurate. On systems where the activation may take 326 a long time, a response may be given prior to completion, but extra 327 mechanisms must be provided to detect any errors. 329 6.2. Example 331 This section provides an example of the process described in the 332 previous section. This example will show a Differentiated Services 333 capable incoming (ingress) interface that only counts the traffic 334 stream. Then, with the policy-based configuration concept as defined 335 in this document and in [PMMIBDR], a traffic marking configuration 336 will be applied. The example will walk the reader through all of the 337 steps involved in this process. Again, the use of [PMMIBDR] is 338 simply as an example and is not required. 340 NOTE WELL: For brevity and clarity, the example does not always 341 show the complete entry (row) of a table. The only objects shown 342 are those needed for creating the row pointers to the next 343 functional datapath element or needed to provide information about 344 the specific parameters of the functional datapath elements. The 345 column named 'INDEX' always defines the complete index as defined 346 for the associated entry. In some cases this is a combined index 347 of multiple components. Therefore, the names of the columns are 348 omitted. 350 Also note that the values Assured Forwarding and Expedited 351 Forwarding are abstracted as DSCP(AF) and DSCP(EF) (respectively) 352 or simply as AF and EF. For the actual values refer to [RFC3289]. 354 6.2.1. The Initial Situation 356 The initial configuration is the existing configuration of an ingress 357 interface. 359 +------------------------------------------------------------+ 360 | ingress functional datapath | 361 | +----------+ | 362 -->|----------->----------->| count |----------->----------->|--> 363 | +----------+ | 364 +------------------------------------------------------------+ 366 This figure depicts a simple traffic treatment functional datapath 367 for an ingress interface. The functional datapath only consists of a 368 count action. 370 Within the DIFFSERV-MIB this would be instantiated as follows. Note 371 that RowPointer objects must point to the first accessible columnar 372 object in the conceptual row. Thus, while perhaps more instructive 373 to use the index value for the RowPointer object's value (e.g., 374 diffServCountActId.1) in the example, it would nonetheless be 375 incorrect, and the first accessible columnar object has been used as 376 should be done (e.g., diffServCountActOctets.1). 378 diffServDataPathTable 379 +-----------------+-----------------------------+-- 380 | INDEX | diffServDataPathStart | 381 +-----------------+-----------------------------+-- 382 | ifIndex.ingress | diffServActionNext.1 | 383 +-----------------+-----------------------------+-- 385 diffServActionTable 386 +-------+--------------------+-------------------------+-- 387 | INDEX | diffServActionNext |diffServActionSpecific | 388 +-------+--------------------+-------------------------+-- 389 | 1 | 0.0 |diffServCountActOctets.1 | 390 +-------+--------------------+-------------------------+-- 392 diffServCountActTable 393 +-------+------------------------+-- 394 | INDEX | diffServCountActOctets | 395 +-------+------------------------+-- 396 | 1 | | 397 +-------+------------------------+-- 399 6.2.2. The Configuration Template 401 The following provides an example of a policy configuration in which 402 traffic is classified by a specific IP filter. That results in two 403 classifiers (1 for the IP filter and the match all). Both streams are 404 then metered, marked and counted. This is an example of usage on the 405 edge (an ingress interface) of a Differentiated Services domain that 406 wants to have Expedited Forwarding and Assured Forwarding marked 407 traffic within the Differentiated Services domain. 409 +------------------------------------------------------------+ 410 | ingress functional datapath | 411 | +------------+ +-------+ +---------+ +---------+ | 412 | | | | | | action: | | action: | | 413 -->|-->| classifier |-->| meter |-->| mark EF |-->| count |-->|-----> 414 | | match | | | | | | | | 415 | +------------+ +-------+ +---------+ +---------+ | 416 | | \ | 417 | | \ +---------+ | 418 | | \ | action: | |routing 419 | | * -->| dropper | |core 420 | | / | | | 421 | | / +---------+ | 422 | V / | 423 | +------------+ +-------+ +---------+ +---------+ | 424 | | | | | | action: | | action: | | 425 | | classifier |-->| meter |-->| mark AF |-->| count |-->|-----> 426 | | match all | | | | | | | | 427 | +------------+ +-------+ +---------+ +---------+ | 428 +------------------------------------------------------------+ 430 This figure depicts a policy configuration for ingress traffic 431 treatment in a Differentiated Services capable device. The 432 configuration is represented as follows in DIFFSERV-CONFIG-MIB module 433 and the DIFFSERV-MIB module. 435 Note that the original (existing) traffic treatment of 1) is also in 436 the tables of section 6.2.1. 438 Note also that in the diffServDscpMarkActTable that DSCP(EF) 439 represents the DSCP value for Expedited Forwarding and DSCP(AF) 440 represents the DSCP value for Assured Forwarding. 442 diffServConfigTable (in the MIB module in this memo) 443 +-------+-------------------------+---------------------------+-- 444 | INDEX | diffServConfigStart | diffServConfigDescr | 445 +-------+-------------------------+---------------------------+-- 446 | "foo" | diffServClfrStorage.1 | Example traffic treatment | 447 +-------+-------------------------+---------------------------+-- 449 diffServClfrTable 450 +-------+---------------------+--------------------+ 451 | INDEX | diffServClfrStorage | diffServClfrStatus | 452 +-------+---------------------+--------------------+ 453 | 1 | | | 454 +-------+---------------------+--------------------+ 456 diffServClfrElementTable (shares index with diffServClfrTable) 457 +-------+---------------------------+-------------------------------+-- 458 | INDEX | diffServClfrElementNext | diffServClfrElementPrecedence | 459 +-------+---------------------------+-------------------------------+-- 460 | 1.1 |diffServMeterSucceedNext.1 | 1 | 461 | 1.2 |diffServMeterSucceedNext.2 | 2 | 462 +-------+---------------------------+-------------------------------+-- 464 diffServMeterTable 465 +-------+--------------------------+-----------------------+-- 466 | INDEX | diffServMeterSucceedNext |diffServMeterFailNext | 467 +-------+--------------------------+-----------------------+-- 468 | 1 | diffServActionNext.2 | diffServAlgDropType.1 | 469 | 2 | diffServActionNext.3 | diffServAlgDropType.1 | 470 +-------+--------------------------+-----------------------+-- 472 diffServActionTable 473 +-------+----------------------+----------------------------+-- 474 | INDEX | diffServActionNext | diffServActionSpecific | 475 +-------+----------------------+----------------------------+-- 476 | 1 | 0.0 | diffServCountActOctets.1 | 477 | 2 | diffServActionNext.4 | diffServDscpMarkActDscp.EF | 478 | 3 | diffServActionNext.5 | diffServDscpMarkActDscp.AF | 479 | 4 | 0.0 | diffServCountActOctets.2 | 480 | 5 | 0.0 | diffServCountActOctets.3 | 481 +-------+----------------------+----------------------------+-- 482 diffServCountActTable 483 +-------+------------------------+-- 484 | INDEX | diffServCountActOctets | 485 +-------+------------------------+-- 486 | 1 | | 487 | 2 | | 488 | 3 | | 489 +-------+------------------------+-- 491 diffServAlgDropTable 492 +-------+---------------------+-------------------------+-- 493 | INDEX | diffServAlgDropType | diffServAlgDropSpecific | 494 +-------+---------------------+-------------------------+-- 495 | 1 | alwaysDrop(5) | 0.0 | 496 +-------+---------------------+-------------------------+-- 498 diffServDscpMarkActTable 499 +-------------------------+ 500 | diffServDscpMarkActDscp | 501 +-------------------------+ 502 | DSCP(EF) | 503 | DSCP(AF) | 504 +-------------------------+ 506 6.2.3. Applying the Template 508 Now we have the original ingress interface configuration and the 509 policy configuration we want to apply to the actual interface. 511 The example policy must provide to all interfaces used by system 512 administrators the required Differentiated Services traffic 513 treatment. The traffic treatment required is described in 6.2.2 514 above. 516 Therefore, we have the following example policy which is configured 517 via the POLICY-BASED-MANAGEMENT-MIB module (see [PMMIBDR]): 519 if ( roleMatch("Administrator") ) 520 then 521 /* 522 * The $0 gets the "element" returned from the previous 523 * statement. the .1 at the end is the ingress interface 524 * This sets, for example, diffServDataPathStart.3.1 to be 525 * "diffServConfigStart.3.f.o.o" if interface 3 has the role 526 * "Administrator". 527 */ 528 setVar("diffServDataPathStart.$0.1", 529 "diffServConfigStart.3.f.o.o", Oid) 531 For our purposes, we only apply this on the inbound (ingress) 532 direction on the interface. 534 Note that although object descriptors are used in this PolicyScript 535 example, the object identifiers must be used in the running script. 536 For more information on policies and their syntax refer to [PMMIBDR]. 538 The following tables of this section provide the cloned entries in 539 the tables of the DIFFSERV-MIB module. All tables may have columns 540 that contain contents or entry administration objects. Since these do 541 not determine a function datapath that are not added for clarity of 542 the cloning mechanism and space. 544 Note that the original (existing) traffic treatment of 6.2.1 and 545 6.2.2 are also in the tables. 547 diffServConfigTable 548 +-------+-------------------------+---------------------------+-- 549 | INDEX | diffServConfigStart | diffServConfigDescr | 550 +-------+-------------------------+---------------------------+-- 551 | "foo" | diffServClfrStorage.1 | Example traffic treatment | 552 +-------+-------------------------+---------------------------+-- 554 diffServDataPathTable 555 +-----------------+-----------------------------+-- 556 | INDEX | diffServDataPathStart | 557 +-----------------+-----------------------------+-- 558 | ifIndex.ingress | diffServActionNext.2 | 559 +-----------------+-----------------------------+-- 561 diffServClfrTable 562 +-------+---------------------+--------------------+ 563 | INDEX | diffServClfrStorage | diffServClfrStatus | 564 +-------+---------------------+--------------------+ 565 | 1 | | | 566 | 2 | | | 567 +-------+---------------------+--------------------+ 568 diffServClfrElementTable 569 +-------+----------------------------+-------------------------------+-- 570 | INDEX | diffServClfrElementNext | diffServClfrElementPrecedence | 571 +-------+----------------------------+-------------------------------+-- 572 | 1.1 | diffServMeterSucceedNext.1 | 1 | 573 | 1.2 | diffServMeterSucceedNext.2 | 2 | 574 | 2.3 | diffServMeterSucceedNext.3 | 1 | 575 | 2.4 | diffServMeterSucceedNext.4 | 2 | 576 +-------+----------------------------+-------------------------------+-- 578 diffServMeterTable 579 +-------+--------------------------+-----------------------+-- 580 | INDEX | diffServMeterSucceedNext | diffServMeterFailNext | 581 +-------+--------------------------+-----------------------+-- 582 | 1 | diffServActionNext.2 | diffServAlgDropType.1 | 583 | 2 | diffServActionNext.3 | diffServAlgDropType.1 | 584 | 3 | diffServActionNext.6 | diffServAlgDropType.2 | 585 | 4 | diffServActionNext.7 | diffServAlgDropType.2 | 586 +-------+--------------------------+-----------------------+-- 588 diffServActionTable 589 +-------+----------------------+----------------------------+-- 590 | INDEX | diffServActionNext | diffServActionSpecific | 591 +-------+----------------------+----------------------------+-- 592 | 1 | 0.0 | diffServCountActOctets.1 | 593 | 2 | diffServActionNext.4 | diffServDscpMarkActDscp.EF | 594 | 3 | diffServActionNext.5 | diffServDscpMarkActDscp.AF | 595 | 4 | 0.0 | diffServCountActOctets.2 | 596 | 5 | 0.0 | diffServCountActOctets.3 | 597 | 6 | diffServActionNext.8 | diffServDscpMarkActDscp.EF | 598 | 7 | diffServActionNext.9 | diffServDscpMarkActDscp.AF | 599 | 8 | 0.0 | diffServCountActOctets.4 | 600 | 9 | 0.0 | diffServCountActOctets.5 | 601 +-------+----------------------+----------------------------+-- 603 diffServCountActTable 604 +-------+------------------------+-- 605 | INDEX | diffServActCountOctets | 606 +-------+------------------------+-- 607 | 1 | | 608 | 2 | | 609 | 3 | | 610 | 4 | | 611 | 5 | | 612 +-------+------------------------+-- 613 diffServAlgDropTable 614 +-------+---------------------+-------------------------+-- 615 | INDEX | diffServAlgDropType | diffServAlgDropSpecific | 616 +-------+---------------------+-------------------------+-- 617 | 1 | alwaysDrop(5) | 0.0 | 618 +-------+---------------------+-------------------------+-- 620 diffServDscpMarkActTable 621 +-------------------------+ 622 | diffServDscpMarkActDscp | 623 +-------------------------+ 624 | DSCP(EF) | 625 | DSCP(AF) | 626 +-------------------------+ 628 As one can see in the example, the main elements from which a 629 functional datapath are constructed are duplicated/copied/cloned. 630 That process is needed in order to preserve the policy configuration 631 for reuse at a later time. 633 It is up to the SNMP agent to keep track of which network interfaces 634 are under policy control and which policy rules are being used. This 635 avoids duplication of policy enforcement. How the agent does this is 636 an implementation issue. 638 One can see that the old functional datapath configurations stay in 639 the MIB module tables. It is up to the SNMP agent implementation to 640 decide whether to delete stale entries or keep them. Garbage 641 collection of stale entries is an implementation issue. 643 6.2.4. Applying the Template Using SNMP Messages 645 In this section the above example is explained by using SNMP 646 communication between the SNMP "manager" and the SNMP "agent". 648 In order to apply the the template to all interfaces that have a role 649 match of "Administrator" the SNMP manager must have a list of the 650 roles of the interface. This means the SNMP manager must do an SNMP- 651 SET for all those interfaces. This is expressed in the following 652 pseudo code function. 654 set_template_if_administrator_interface( 655 , 656 ) { 657 template_oid = SNMP-GET("diffServConfigStart."); 658 foreach interface () { 659 if (interface.role == "Administrator") { 660 SNMP-SET("diffServDataPathStart.$interface.1", 661 Oid, template_oid); 662 } 663 } 664 } 666 For example, on a system with 3 interfaces, the following list would 667 be known to the manager. The first value indicates the interface 668 number (ifIndex) and the second value is its role. 669 interface_list IF_LIST = { 670 { 1, ... , "Administrator", ... }, 671 { 2, ... , "User", ... }, 672 { 3, ... , "Administrator", ... } } 674 This will result in the communication between a manager and agent of 675 1 SNMP-GET and 2 SNMP-SETs: 676 - SNMP-GET("diffServConfigStart.3.f.o.o") 677 - SNMP-SET("diffServDataPathStart.1.1", Oid, "diffServActionNext.1") 678 - SNMP-SET("diffServDataPathStart.3.1", Oid, "diffServActionNext.1") 680 7. Managed Objects Definitions (MIB Module) 682 DIFFSERV-CONFIG-MIB DEFINITIONS ::= BEGIN 683 IMPORTS 685 OBJECT-TYPE, MODULE-IDENTITY, zeroDotZero, mib-2 686 FROM SNMPv2-SMI 688 RowStatus, StorageType, RowPointer, DateAndTime 689 FROM SNMPv2-TC 691 MODULE-COMPLIANCE, OBJECT-GROUP 692 FROM SNMPv2-CONF 694 SnmpAdminString 695 FROM SNMP-FRAMEWORK-MIB; 697 diffServConfigMib MODULE-IDENTITY 698 LAST-UPDATED "200311240000Z" -- 24 November 2003 699 ORGANIZATION "SNMPCONF WG" 700 CONTACT-INFO 701 "SNMPCONF Working Group 702 http://www.ietf.org/html.charters/snmpconf-charter.html 703 WG mailing list: snmpconf@snmp.com 705 Editors: 706 Harrie Hazewinkel 707 I.Net 708 v. Darwin, 85 709 20019 - Settimo Milanese (MI), Italy 710 EMail: harrie@inet.it 712 David Partain 713 Ericsson AB 714 P.O. Box 1248 715 SE-581 12 Linkoping 716 Sweden 717 E-mail: David.Partain@ericsson.com" 718 DESCRIPTION 719 "This MIB module contains differentiated services 720 specific managed objects to perform higher-level 721 configuration management. This MIB allows policies 722 to use 'templates' to instantiate Differentiated 723 Services functional datapath configurations to 724 be assigned (associated with an interface and 725 direction) when a policy is activated. 727 Copyright (C) The Internet Society (2003). This version 728 of this MIB module is part of RFC yyyy; see the RFC 729 itself for full legal notices." 730 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 731 REVISION "200311240000Z" -- 24 November 2003 732 DESCRIPTION 733 "Initial version publish as RFC yyyy" 734 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 735 ::= { mib-2 xxx } 736 -- RFC Ed.: replace xxx with IANA-assigned number & remove this note 738 diffServConfigMIBObjects OBJECT IDENTIFIER ::= { diffServConfigMib 1 } 739 diffServConfigMIBConformance OBJECT IDENTIFIER ::= { diffServConfigMib 2 } 741 -- 742 -- The Differentiated Services configuration objects 743 -- 745 diffServConfigTable OBJECT-TYPE 746 SYNTAX SEQUENCE OF DiffServConfigEntry 747 MAX-ACCESS not-accessible 748 STATUS current 749 DESCRIPTION 750 "A table which defines the various per-hop-behaviors 751 for which the system has default 'templates'." 752 ::= { diffServConfigMIBObjects 2 } 754 diffServConfigEntry OBJECT-TYPE 755 SYNTAX DiffServConfigEntry 756 MAX-ACCESS not-accessible 757 STATUS current 758 DESCRIPTION 759 "An entry defining a per-hop-behavior. Each entry in 760 this table combines the various parameters (entries) 761 into a specific per-hop-behavior. Entries in this 762 table might be defined by a vendor (pre-configured) 763 or defined by a management application." 764 INDEX { diffServConfigId } 765 ::= { diffServConfigTable 1 } 767 DiffServConfigEntry ::= SEQUENCE { 768 diffServConfigId SnmpAdminString, 769 diffServConfigDescr SnmpAdminString, 770 diffServConfigOwner SnmpAdminString, 771 diffServConfigLastChange DateAndTime, 772 diffServConfigStart RowPointer, 773 diffServConfigStorage StorageType, 774 diffServConfigStatus RowStatus 775 } 777 diffServConfigId OBJECT-TYPE 778 SYNTAX SnmpAdminString (SIZE(1..116)) 779 MAX-ACCESS not-accessible 780 STATUS current 781 DESCRIPTION 782 "A unique id for the per-hop-behavior policy for at 783 least the SNMP agent. For ease of administration the 784 value may be unique within an administrative domain, 785 but this is not required. 787 The range of up to 116 octets is chosen to stay within 788 the SMI limit of 128 sub-identifiers in an object 789 identifier." 790 ::= { diffServConfigEntry 1 } 792 diffServConfigDescr OBJECT-TYPE 793 SYNTAX SnmpAdminString 794 MAX-ACCESS read-create 795 STATUS current 796 DESCRIPTION 797 "A human-readable description to identify this defined 798 per-hop-behavior. Note that this is an SnmpAdminString, 799 which permits UTF-8 strings. An administratively assigned 800 identifier for a template that would be unique within 801 an administrative domain. It is up to the management 802 applications to agree how these are assigned within the 803 administrative domain. Once a description, such as 804 'EF' is assigned, that has a certain set of parameters 805 that achieve 'EF' from box to box, so management 806 application code or Script code can easily scan 807 the table to find the proper template and then easily 808 assign it." 809 ::= { diffServConfigEntry 2 } 811 diffServConfigOwner OBJECT-TYPE 812 SYNTAX SnmpAdminString 813 MAX-ACCESS read-create 814 STATUS current 815 DESCRIPTION 816 "The owner who created this entry." 817 ::= { diffServConfigEntry 3 } 819 diffServConfigLastChange OBJECT-TYPE 820 SYNTAX DateAndTime 821 MAX-ACCESS read-only 822 STATUS current 823 DESCRIPTION 824 "The date and time when this entry was last changed." 825 ::= { diffServConfigEntry 4 } 827 diffServConfigStart OBJECT-TYPE 828 SYNTAX RowPointer 829 MAX-ACCESS read-create 830 STATUS current 831 DESCRIPTION 832 "The pointer to a functional datapath configuration template as 833 set up in the DIFFSERV-MIB. This RowPointer should 834 point to an instance of one of: 835 diffServClfrEntry 836 diffServMeterEntry 837 diffServActionEntry 838 diffServAlgDropEntry 839 diffServQEntry 841 A value of zeroDotZero in this attribute indicates no 842 further Diffserv treatment is performed on traffic of 843 this functional datapath. This also means that the 844 template described by this row is not defined. 846 If the row pointed to does not exist, the treatment 847 is as if this attribute contains a value of zeroDotZero." 848 REFERENCE 849 "Differentiated Services MIB module" 850 DEFVAL { zeroDotZero } 851 ::= { diffServConfigEntry 5 } 853 diffServConfigStorage OBJECT-TYPE 854 SYNTAX StorageType 855 MAX-ACCESS read-create 856 STATUS current 857 DESCRIPTION 858 "The type of storage used for this row. 860 Since an entry in this tables serves as a starting 861 point for a configuration, it is recommended that 862 all entries comprising the configuration started by 863 diffServConfigStart follow the storage type of this 864 entry. Otherwise, after agent reboots a configuration 865 may differ. It may very well be that the agent is 866 not capable of detecting such changes and therefore, 867 the management application should verify the correct 868 configuration after a reboot. Rows with a StorageType 869 of 'permanent' do not need to allow write access to 870 any of the columnar objects in that row." 871 DEFVAL { nonVolatile } 872 ::= { diffServConfigEntry 6 } 874 diffServConfigStatus OBJECT-TYPE 875 SYNTAX RowStatus 876 MAX-ACCESS read-create 877 STATUS current 878 DESCRIPTION 879 "RowStatus object used for creation and deletion of 880 rows in this table. All writable objects in this row 881 may be modified at any time." 882 DEFVAL { notInService } 883 ::= { diffServConfigEntry 7 } 885 -- 886 -- MIB Compliance statements. 887 -- 889 diffServConfigMIBCompliances 890 OBJECT IDENTIFIER ::= { diffServConfigMIBConformance 1 } 891 diffServConfigMIBGroups 892 OBJECT IDENTIFIER ::= { diffServConfigMIBConformance 2 } 894 diffServConfigMIBFullCompliance MODULE-COMPLIANCE 895 STATUS current 896 DESCRIPTION 897 "The full compliance for this MIB module. 899 For this compliance level the 'diffServMIBFullCompliance' 900 must be met, since this MIB module depends on it in order 901 to provide the configuration entries. 902 " 903 MODULE -- This module 904 MANDATORY-GROUPS { diffServConfigMIBConfigGroup } 906 OBJECT diffServConfigStatus 907 SYNTAX RowStatus { active(1) } 908 WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } 909 DESCRIPTION 910 "Support for createAndWait and notInService is not required." 912 ::= { diffServConfigMIBCompliances 1 } 914 diffServConfigMIBConfigGroup OBJECT-GROUP 915 OBJECTS { diffServConfigDescr, 916 diffServConfigOwner, 917 diffServConfigLastChange, 918 diffServConfigStart, 919 diffServConfigStorage, 920 diffServConfigStatus 921 } 922 STATUS current 923 DESCRIPTION 924 "The per-hop-behavior Group defines the MIB objects that 925 describe the configuration template for the per-hop-behavior." 926 ::= { diffServConfigMIBGroups 1 } 927 END 929 8. Security Considerations 931 There are a number of management objects defined in this MIB module 932 with a MAX-ACCESS clause of read-write and/or read-create. Such 933 objects may be considered sensitive or vulnerable in some network 934 environments. The support for SET operations in a non-secure 935 environment without proper protection can have a negative effect on 936 network operations. These managed objects are: 938 - The diffServConfigDescr, diffServConfigOwner and 939 diffServConfigStatus are not security sensitive since these 940 three object do not affect any direct operational behavior 941 of a diffserv capable device. 943 - Unauthorized change of the diffServConfigStart could lead 944 to a different configuration and the 'changed' configuration 945 could lead to different traffic treatment for the diffserv 946 capable device than desired. 948 - Unauthorized change of the diffServConfigStorage could lead 949 to unknown behavior of the diffserv capable device after 950 a reboot of the SNMP agent. This may be caused by 'not 951 having saved changes of the configuration' or unavailable 952 configurations. 954 In addition, the managed objects of the DIFFSERV-MIB are also 955 security sensitive, since unauthorized changes may cause 956 configuration changes. For more detail, refer to [RFC3289]. 958 Allowing read access to objects in this MIB module is generally not 959 considered sensitive, as read access only provides information that a 960 template exists. This is due to the fact that the managed objects 961 that actually instantiate the template are in the DIFFSERV-MIB 962 [RFC3289]. However, in environments where the template description 963 (diffServConfigDescr) or owner (diffServConfigOwner) is considered 964 sensitive information, appropriate access control should be exercised 965 for these objects. 967 SNMP versions prior to SNMPv3 did not include adequate security. 968 Even if the network itself is secure (for example by using IPSec), 969 there is no control as to who on the secure network is allowed to 970 access and GET/SET (read/change/create/delete) the objects in this 971 MIB module. 973 It is RECOMMENDED that implementers consider the security features as 974 provided by the SNMPv3 framework (see [RFC3410], section 8), 975 including full support for the SNMPv3 cryptographic mechanisms (for 976 authentication and privacy). 978 Further, deployment of SNMP versions prior to SNMPv3 is NOT 979 RECOMMENDED. Instead, deployment of SNMPv3 with cryptographic 980 security enabled is RECOMMENDED. It is then a customer/operator 981 responsibility to ensure that the SNMP entity giving access to an 982 instance of this MIB module is properly configured to give access to 983 the objects only to those principals (users) that have legitimate 984 rights to GET or SET (change/create/delete) them. 986 9. Acknowledgments 988 The editors gratefully acknowledge the significant contributions to 989 this work made by several members of both the SNMPCONF and DiffServ 990 working groups. 992 10. Editors' Addresses 994 Harrie Hazewinkel 995 I.Net 996 v. Darwin, 85 997 20019 - Settimo Milanese (MI), Italy 998 EMail: harrie@inet.it 1000 David Partain 1001 Ericsson AB 1002 P.O. Box 1248 1003 SE-581 12 Linkoping 1004 Sweden 1005 EMail: David.Partain@ericsson.com 1007 11. Full Copyright Statement 1009 Copyright (C) The Internet Society (2003). All Rights Reserved. 1011 This document and translations of it may be copied and furnished to 1012 others, and derivative works that comment on or otherwise explain it 1013 or assist in its implementation may be prepared, copied, published 1014 and distributed, in whole or in part, without restriction of any 1015 kind, provided that the above copyright notice and this paragraph are 1016 included on all such copies and derivative works. However, this 1017 document itself may not be modified in any way, such as by removing 1018 the copyright notice or references to the Internet Society or other 1019 Internet organizations, except as needed for the purpose of 1020 developing Internet standards in which case the procedures for 1021 copyrights defined in the Internet Standards process must be 1022 followed, or as required to translate it into languages other than 1023 English. 1025 The limited permissions granted above are perpetual and will not be 1026 revoked by the Internet Society or its successors or assigns. 1028 This document and the information contained herein is provided on an 1029 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1030 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1031 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1032 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1033 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1035 12. Intellectual Property 1037 The IETF takes no position regarding the validity or scope of any 1038 intellectual property or other rights that might be claimed to 1039 pertain to the implementation or use of the technology described in 1040 this document or the extent to which any license under such rights 1041 might or might not be available; neither does it represent that it 1042 has made any effort to identify any such rights. Information on the 1043 IETF's procedures with respect to rights in standards-track and 1044 standards-related documentation can be found in BCP-11. Copies of 1045 claims of rights made available for publication and any assurances of 1046 licenses to be made available, or the result of an attempt made to 1047 obtain a general license or permission for the use of such 1048 proprietary rights by implementors or users of this specification can 1049 be obtained from the IETF Secretariat. 1051 The IETF invites any interested party to bring to its attention any 1052 copyrights, patents or patent applications, or other proprietary 1053 rights which may cover technology that may be required to practice 1054 this standard. Please address the information to the IETF Executive 1055 Director. 1057 13. Informative References 1059 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1060 "Introduction and Applicability Statements for Internet- 1061 Standard Management Framework", RFC 3410, December 2002. 1063 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1064 "Definition of the Differentiated Services Field 1065 (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, 1066 December 1998. 1068 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., 1069 Wang, Z., and W. Weiss, "An Architecture for 1070 Differentiated Services", RFC 2475, December 1998. 1072 [RFC3512] MacFaden M., Partain D., Saperia J., and W. Tackabury, 1073 "Configuring Networks and Devices with Simple Network 1074 Management Protocol (SNMP)," RFC 3512, April 2003. 1076 [PMMIBDR] Waldbusser, S., J. Saperia, and T. Hongal, 1077 "Policy-based Management MIB", 1078 draft-ietf-snmpconf-pm-13.txt, Work in Progress, 1079 March 2003. 1081 14. Normative References 1083 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1084 Rose, M. and S. Waldbusser, "Structure of Management 1085 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1086 1999. 1088 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1089 Rose, M. and S. Waldbusser, "Textual Conventions for 1090 SMIv2", STD 58, RFC 2579, April 1999. 1092 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1093 Rose, M. and S. Waldbusser, "Conformance Statements for 1094 SMIv2", STD 58, RFC 2580, April 1999. 1096 [RFC3289] Baker, F., K. Chan, and A. Smith, "Management 1097 Information Base for the Differentiated Services 1098 Architecture", RFC 3289, May 2002. 1100 [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture 1101 for Describing Simple Network Management Protocol (SNMP) 1102 Management Frameworks", STD 62, RFC 3411, December 2002.