idnits 2.17.1 draft-ietf-forces-mib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 482. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (April 2006) is 6586 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) ** Downref: Normative reference to an Informational RFC: RFC 3410 ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Forwarding and Control Element R. Haas 3 Separation (forces) IBM 4 Internet-Draft April 2006 5 Expires: October 3, 2006 7 ForCES MIB 8 draft-ietf-forces-mib-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 3, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This memo defines a Management Information Base (MIB) for use with 42 network management protocols in the Internet community. In 43 particular, it defines a MIB for the Forwarding and Control Element 44 Separation (ForCES) Network Element (NE). The ForCES working group 45 is defining a protocol to allow a Control Element (CE) to control the 46 behavior of a Forwarding Element (FE). 48 Table of Contents 50 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Design of the ForCES MIB . . . . . . . . . . . . . . . . . . . 3 53 4. Association State . . . . . . . . . . . . . . . . . . . . . . 3 54 5. ForCES MIB Definition . . . . . . . . . . . . . . . . . . . . 4 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 57 8. Changes from Previous Draft Revisions . . . . . . . . . . . . 10 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 60 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 61 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 Intellectual Property and Copyright Statements . . . . . . . . . . 13 65 1. Requirements notation 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Introduction 73 The ForCES MIB is a primarily read-only MIB that captures information 74 related to the ForCES protocol ([RFC3654], [RFC3746], [forces- 75 applicability-draft] and [forces-protocol-draft]). 77 The ForCES MIB does not include information that is specified in 78 other MIBs, such as packet counters for interfaces, etc. 80 More specifically, the information in the ForCES MIB relative to 81 associations that are up includes: 83 o identifiers of the elements in the association, 85 o configuration parameters of the association, and 87 o statistics of the association. 89 3. Design of the ForCES MIB 91 In an NE composed of one or more FEs and a single CE, the CE is 92 clearly aware of all associations and hence can provide this 93 information in a single ForCES MIB. In contrast, in an NE composed 94 of more than one CE, such association information is distributed and 95 hence more than one ForCES MIB may be necessary, unless this 96 information is aggregated into a single ForCES MIB by some means 97 beyond the scope of this document. Nevertheless, the ForCES MIB 98 design is compatible with both the single-CE and the multiple-CE 99 case. 101 4. Association State 103 Only associations that are UP are shown in the MIB. Associations 104 enter the UP state as soon as the CE has sent to the FE an 105 Association Setup Response message containing a successful 106 Association Setup Result. 108 Associations are removed from the MIB as soon as they leave the UP 109 state, i.e., if the CE has not received any message (Heartbeat or 110 other protocol message) from the FE within a given time period or if 111 an Association Teardown message has been sent by the CE. 113 5. ForCES MIB Definition 115 The MIB contains the latest ForCES protocol version supported by the 116 CE. Note that the CE must also allow interaction with FEs supporting 117 earlier versions. 119 For each association identified by the pair CE ID and FE ID, the 120 following associated information is provided by the MIB: 122 o Version number of the ForCES protocol running in this association. 124 o Time when the association entered the UP state. 126 o Time when the association left the UP state. Note that this is 127 only used for notification purposes as the association is removed 128 from the MIB immediately after it leaves the UP state. 130 o Number of ForCES Heartbeat messages sent from the CE and received 131 by the CE since the association is UP. 133 o Number of other ForCES messages sent from the CE and received by 134 the CE since the association is UP. Only messages other than 135 Heartbeat, Association Setup, Association Setup Response, and 136 Association Teardown are counted. 138 Finally, the MIB defines the following notifications: 140 o Whenever an association enters the UP state, a notification is 141 issued containing the CE and FE IDs. 143 o Whenever an association leaves the UP state, a notification is 144 issued containing the CE and FE IDs as well as all other 145 associated information for this association. The reason is that 146 the association and all its associated information will be removed 147 from the MIB immediately after this notification has been issued. 149 FORCES-MIB DEFINITIONS ::= BEGIN 151 IMPORTS 152 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 153 Counter32 154 FROM SNMPv2-SMI 156 TEXTUAL-CONVENTION, TimeStamp 157 FROM SNMPv2-TC; 159 forcesMIB MODULE-IDENTITY 160 LAST-UPDATED "200606261200Z" -- Jun 26, 2006 161 ORGANIZATION "Forwarding and Control Element Separation 162 (ForCES) Working Group" 163 CONTACT-INFO 164 "Robert Haas (rha@zurich.ibm.com), IBM" 165 DESCRIPTION 166 "Initial version, published as RFC yyyy. This MIB 167 contains managed object definitions for the ForCES 168 Protocol." 169 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 170 ::= { mib-2 XXX } 171 -- RFC Ed.: replace XXX with IANA-assigned number & remove this note 173 --**************************************************************** 174 ForcesID ::= TEXTUAL-CONVENTION 175 STATUS current 176 DESCRIPTION 177 "The ForCES identifier is a four octet quantity." 178 SYNTAX OCTET STRING (SIZE (4)) 180 ForcesProtocolVersion ::= TEXTUAL-CONVENTION 181 STATUS current 182 DESCRIPTION 183 "ForCES protocol version number." 184 SYNTAX INTEGER (1..255) 186 forcesLatestProtocolVersionSupported OBJECT-TYPE 187 SYNTAX ForcesProtocolVersion 188 MAX-ACCESS read-only 189 STATUS current 190 DESCRIPTION 191 "The ForCES protocol version supported by the CE. 192 The current protocol version is 1. 193 Note that the CE must also allow interaction 194 with FEs supporting earlier versions." 195 ::= { forcesMIB 1 } 197 forcesAssociations OBJECT IDENTIFIER ::= { forcesMIB 2 } 199 forcesAssociationTable OBJECT-TYPE 200 SYNTAX SEQUENCE OF ForcesAssociationEntry 201 MAX-ACCESS not-accessible 202 STATUS current 203 DESCRIPTION 204 "The (conceptual) table of associations." 205 ::= { forcesAssociations 1 } 207 forcesAssociationEntry OBJECT-TYPE 208 SYNTAX ForcesAssociationEntry 209 MAX-ACCESS not-accessible 210 STATUS current 211 DESCRIPTION 212 "A (conceptual) entry for one association." 213 INDEX { forcesAssociationCEID, forcesAssociationFEID } 214 ::= { forcesAssociationTable 1 } 216 ForcesAssociationEntry ::= SEQUENCE { 217 forcesAssociationCEID ForcesID, 218 forcesAssociationFEID ForcesID, 220 forcesAssociationRunningProtocolVersion 221 ForcesProtocolVersion, 223 forcesAssociationTimeUp TimeStamp, 224 forcesAssociationTimeDown TimeStamp, 226 forcesAssociationHBMsgSent Counter32, 227 forcesAssociationHBMsgReceived Counter32, 228 forcesAssociationOtherMsgSent Counter32, 229 forcesAssociationOtherMsgReceived Counter32 } 231 forcesAssociationCEID OBJECT-TYPE 232 SYNTAX ForcesID 233 MAX-ACCESS read-only 234 STATUS current 235 DESCRIPTION 236 "The ForCES ID of the CE." 237 ::= { forcesAssociationEntry 1 } 239 forcesAssociationFEID OBJECT-TYPE 240 SYNTAX ForcesID 241 MAX-ACCESS read-only 242 STATUS current 243 DESCRIPTION 244 "The ForCES ID of the FE." 245 ::= { forcesAssociationEntry 2 } 247 forcesAssociationRunningProtocolVersion OBJECT-TYPE 248 SYNTAX ForcesProtocolVersion 249 MAX-ACCESS read-only 250 STATUS current 251 DESCRIPTION 252 "The current ForCES protocol version used in this 253 association. 254 The current protocol version is 1." 255 ::= { forcesAssociationEntry 3 } 257 forcesAssociationTimeUp OBJECT-TYPE 258 SYNTAX TimeStamp 259 MAX-ACCESS read-only 260 STATUS current 261 DESCRIPTION 262 "The value of sysUpTime at the time this 263 association entered the UP state. 264 If this association started prior to the last 265 initialization of the network subsystem, then 266 this object contains a zero value." 267 ::= { forcesAssociationEntry 4 } 269 forcesAssociationTimeDown OBJECT-TYPE 270 SYNTAX TimeStamp 271 MAX-ACCESS read-only 272 STATUS current 273 DESCRIPTION 274 "The value of sysUpTime at the time this 275 association left the UP state." 276 ::= { forcesAssociationEntry 5 } 278 forcesAssociationHBMsgSent OBJECT-TYPE 279 SYNTAX Counter32 280 MAX-ACCESS read-only 281 STATUS current 282 DESCRIPTION 283 "A counter of how many heartbeat messages have 284 have been sent by the CE on this association 285 since it is up. 286 If this association started prior to the last 287 initialization of the network subsystem, then 288 this object contains the value since the 289 initialization." 290 ::= { forcesAssociationEntry 6} 292 forcesAssociationHBMsgReceived OBJECT-TYPE 293 SYNTAX Counter32 294 MAX-ACCESS read-only 295 STATUS current 296 DESCRIPTION 297 "A counter of how many heartbeat messages 298 have been received by the CE on this association 299 since it is up. 300 If this association started prior to the last 301 initialization of the network subsystem, then 302 this object contains the value since the 303 initialization." 304 ::= { forcesAssociationEntry 7} 306 forcesAssociationOtherMsgSent OBJECT-TYPE 307 SYNTAX Counter32 308 MAX-ACCESS read-only 309 STATUS current 310 DESCRIPTION 311 "A counter of how many messages other than 312 heartbeat (i.e., config and query) 313 have been sent by the CE on this association 314 since it is up. 315 If this association started prior to the last 316 initialization of the network subsystem, then 317 this object contains the value since the 318 initialization." 319 ::= { forcesAssociationEntry 8} 321 forcesAssociationOtherMsgReceived OBJECT-TYPE 322 SYNTAX Counter32 323 MAX-ACCESS read-only 324 STATUS current 325 DESCRIPTION 326 "A counter of how many messages other than 327 heartbeat (i.e., config response, query response, 328 event notification, and packet redirect) 329 have been received by the CE on this association 330 since it is up. 331 If this association started prior to the last 332 initialization of the network subsystem, then 333 this object contains the value since the 334 initialization." 335 ::= { forcesAssociationEntry 9} 337 forcesAssociationEntryUp NOTIFICATION-TYPE 338 OBJECTS { 339 forcesAssociationCEID, 340 forcesAssociationFEID 341 } 342 STATUS current 343 DESCRIPTION 344 "This notification is generated when a 345 forcesAssociationEntry object is created." 346 ::= { forcesAssociations 2 } 348 forcesAssociationEntryDown NOTIFICATION-TYPE 349 OBJECTS { 350 forcesAssociationCEID, 351 forcesAssociationFEID, 352 forcesAssociationRunningProtocolVersion, 353 forcesAssociationTimeUp, 354 forcesAssociationTimeDown, 355 forcesAssociationHBMsgSent, 356 forcesAssociationHBMsgReceived, 357 forcesAssociationOtherMsgSent, 358 forcesAssociationOtherMsgReceived } 359 STATUS current 360 DESCRIPTION 361 "This notification is generated when a 362 forcesAssociationEntry object is destroyed." 363 ::= { forcesAssociations 3 } 365 END 367 6. Security Considerations 369 Some of the readable objects in this MIB module may be considered 370 sensitive or vulnerable in some network environment. 372 SNMP versions prior to SNMPv3 did not include adequate security. 373 Even if the network itself is secure (for example by using IPSec), 374 even then, there is no control as to who on the secure network is 375 allowed to access and GET/SET (read/change/create/delete) the objects 376 in this MIB module. 378 It is RECOMMENDED that implementers consider the security features as 379 provided by the SNMPv3 framework (see [RFC3410], section 8), 380 including full support for the SNMPv3 cryptographic mechanisms (for 381 authentication and privacy). 383 Further, deployment of SNMP versions prior to SNMPv3 is NOT 384 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 385 enable cryptographic security. It is then a customer/operator 386 responsibility to ensure that the SNMP entity giving access to an 387 instance of this MIB module is properly configured to give access to 388 the objects only to those principals (users) that have legitimate 389 rights to indeed GET or SET (change/create/delete) them. 391 7. IANA Considerations 393 IANA will need to assign a number to this MIB. 395 8. Changes from Previous Draft Revisions 397 Changes from draft-ietf-forces-mib-01. The changes are in response 398 to the Working Group Last Call: 400 o Addition of two traps/notifications to signal the associations 401 that enter or leave the UP state. 403 o Suppression of the DOWN and ESTABLISHING states. Only 404 associations in the UP state are kept in the table. 406 o Split of the Message counters into Heartbeat and other messages. 408 o Addition of the current running version of ForCES protocol for 409 each association in the UP state. 411 o Addition of the latest version of the ForCES protocol supported by 412 the CE. 414 9. References 416 9.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 421 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 422 "Introduction and Applicability Statements for Internet- 423 Standard Management Framework", RFC 3410, December 2002. 425 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 426 of IP Control and Forwarding", RFC 3654, November 2003. 428 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 429 "Forwarding and Control Element Separation (ForCES) 430 Framework", RFC 3746, April 2004. 432 [forces-protocol-draft] 433 Doria, A., Haas, R., Hadi Salim, J., Khosravi, H., and W. 434 Wang, "ForCES Protocol Specification", ID Document: 435 draft-ietf-forces-protocol-08.txt, March 2006. 437 9.2. Informative References 439 [forces-applicability-draft] 440 Crouch, A., Khosravi, H., Handley, M., and A. Doria, 441 "ForCES Applicability Statement", ID Document: 442 draft-ietf-forces-applicability-04.txt, February 2006. 444 Appendix A. Acknowledgments 446 The author gratefully acknowledges the contributions of: Jinrong 447 Fenggen, Xiaoyi Guo, and Jamal Hadi Salim. 449 Author's Address 451 Robert Haas 452 IBM 453 Saeumerstrasse 4 454 Rueschlikon 8803 455 CH 457 Email: rha@zurich.ibm.com 458 URI: http://www.zurich.ibm.com/~rha 460 Intellectual Property Statement 462 The IETF takes no position regarding the validity or scope of any 463 Intellectual Property Rights or other rights that might be claimed to 464 pertain to the implementation or use of the technology described in 465 this document or the extent to which any license under such rights 466 might or might not be available; nor does it represent that it has 467 made any independent effort to identify any such rights. Information 468 on the procedures with respect to rights in RFC documents can be 469 found in BCP 78 and BCP 79. 471 Copies of IPR disclosures made to the IETF Secretariat and any 472 assurances of licenses to be made available, or the result of an 473 attempt made to obtain a general license or permission for the use of 474 such proprietary rights by implementers or users of this 475 specification can be obtained from the IETF on-line IPR repository at 476 http://www.ietf.org/ipr. 478 The IETF invites any interested party to bring to its attention any 479 copyrights, patents or patent applications, or other proprietary 480 rights that may cover technology that may be required to implement 481 this standard. Please address the information to the IETF at 482 ietf-ipr@ietf.org. 484 Disclaimer of Validity 486 This document and the information contained herein are provided on an 487 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 488 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 489 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 490 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 491 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 492 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 494 Copyright Statement 496 Copyright (C) The Internet Society (2006). This document is subject 497 to the rights, licenses and restrictions contained in BCP 78, and 498 except as set forth therein, the authors retain all their rights. 500 Acknowledgment 502 Funding for the RFC Editor function is currently provided by the 503 Internet Society.