idnits 2.17.1 draft-ietf-forces-mib-01.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 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 382. ** 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 20, 2006) is 6580 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 20, 2006 5 Expires: October 22, 2006 7 ForCES MIB 8 draft-ietf-forces-mib-01 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 22, 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 . . . . . . . . . . . . . . . . . . . 8 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 57 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 Intellectual Property and Copyright Statements . . . . . . . . . . 11 61 1. Requirements notation 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 2. Introduction 69 The ForCES MIB is a primarily read-only MIB that captures information 70 related to the ForCES protocol ([RFC3654] and [RFC3746]). This 71 includes state information about the associations between CE(s) and 72 FE(s) in the NE. 74 The ForCES MIB does not include information that is specified in 75 other MIBs, such as packet counters for interfaces, etc. 77 More specifically, the information in the ForCES MIB relative to 78 associations includes: 80 o identifiers of the elements in the association, 82 o state of the association, 84 o configuration parameters of the association, and 86 o statistics of the association. 88 3. Design of the ForCES MIB 90 In an NE composed of one or more FEs and a single CE, the CE is 91 clearly aware of all associations and hence can provide this 92 information in a single ForCES MIB. In contrast, in an NE composed 93 of more than one CE, such association information is distributed and 94 hence more than one ForCES MIB may be necessary, unless this 95 information is aggregated into a single ForCES MIB by some means 96 beyond the scope of this document. Nevertheless, the ForCES MIB 97 design is compatible with both the single-CE and the multiple-CE 98 case. 100 4. Association State 102 Association state as shown in the MIB is considered from the CE's 103 point of view: 105 o An association is in the DOWN state if the CE has not received any 106 message (heartbeat or other protocol message) from the FE within a 107 given time period or if an Association Teardown message has been 108 sent by the CE. 110 o An association is in the ESTABLISHING state as long as no message 111 has been received from the FE after the CE has sent a positive 112 Association Setup Response message. 114 o An association is in the UP state in all other cases. 116 Note that it is left to the implementers to choose how long entries 117 of associations in the DOWN state remain in the MIB until they are 118 removed, if at all. 120 5. ForCES MIB Definition 122 For each association identified by the pair CE ID and FE ID, the 123 following information is provided by the MIB: 125 o Current state of the association: 127 * DOWN: the CE(s) indicated by the CE ID and FE(s) indicated by 128 the FE ID are not associated. 130 * ESTABLISHING: transient state until the association has been 131 established. See Section 4 above for details. 133 * UP: the CE(s) indicated by the CE ID and FE(s) indicated by the 134 FE ID are associated. 136 o Time when the association attained the UP state. 138 o Time when the association appeared in the MIB. 140 o Number of transitions to ESTABLISHING state since the association 141 appeared in the MIB. 143 o Number of transitions to UP state since the association appeared 144 in the MIB. 146 o Number of ForCES messages sent/received since the association 147 attained the UP state. 149 FORCES-MIB DEFINITIONS ::= BEGIN 150 IMPORTS 151 OBJECT-TYPE, MODULE-IDENTITY, 152 Integer32, Counter32, Unsigned32 153 FROM SNMPv2-SMI 155 TEXTUAL-CONVENTION, RowStatus, TimeInterval, TimeStamp 156 FROM SNMPv2-TC; 158 forcesMIB MODULE-IDENTITY 159 LAST-UPDATED "200604201200Z" -- Apr 20, 2006 160 ORGANIZATION "Forwarding and Control Element Separation 161 (ForCES) Working Group" 162 CONTACT-INFO 163 "Robert Haas (rha@zurich.ibm.com), IBM" 164 DESCRIPTION 165 "Initial version, published as RFC yyyy. This MIB 166 contains managed object definitions for the ForCES 167 Protocol." 168 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 169 ::= { mib-2 XXX } 170 -- RFC Ed.: replace XXX with IANA-assigned number & remove this note 172 --**************************************************************** 173 ForcesID ::= TEXTUAL-CONVENTION 174 STATUS current 175 DESCRIPTION 176 "The ForCES identifier is a four octet quantity." 177 SYNTAX OCTET STRING (SIZE (4)) 179 ForcesAssociationState ::= TEXTUAL-CONVENTION 180 STATUS current 181 DESCRIPTION 182 "The value down(1) indicates that the current state 183 of the association is down. 184 establishing(2) indicates that the association is 185 in the process of being set up. 186 up(3) indicates that the association is up." 187 SYNTAX INTEGER { 188 down(1), 189 establishing(2), 190 up(3) 191 } 193 forcesAssociations OBJECT IDENTIFIER ::= { forcesMIB 1 } 195 forcesAssociationTable OBJECT-TYPE 196 SYNTAX SEQUENCE OF ForcesAssociationEntry 197 MAX-ACCESS not-accessible 198 STATUS current 199 DESCRIPTION 200 "The (conceptual) table of associations." 202 ::= { forcesAssociations 1 } 204 forcesAssociationEntry OBJECT-TYPE 205 SYNTAX ForcesAssociationEntry 206 MAX-ACCESS not-accessible 207 STATUS current 208 DESCRIPTION 209 "A (conceptual) entry for one association." 210 INDEX { forcesAssociationCEID, forcesAssociationFEID } 211 ::= { forcesAssociationTable 1 } 213 ForcesAssociationEntry ::= SEQUENCE { 214 forcesAssociationCEID ForcesID, 215 forcesAssociationFEID ForcesID, 216 forcesAssociationState ForcesAssociationState, 217 forcesAssociationUptime TimeStamp, 218 forcesAssociationCreated TimeStamp, 219 forcesAssociationTransitionsEstablishing Counter32, 220 forcesAssociationTransitionsUp Counter32, 221 forcesAssociationMsgSent Counter32, 222 forcesAssociationMsgReceived Counter32 223 } 225 forcesAssociationCEID OBJECT-TYPE 226 SYNTAX ForcesID 227 MAX-ACCESS read-only 228 STATUS current 229 DESCRIPTION 230 "The ForCES ID of the CE." 231 ::= { forcesAssociationEntry 1 } 233 forcesAssociationFEID OBJECT-TYPE 234 SYNTAX ForcesID 235 MAX-ACCESS read-only 236 STATUS current 237 DESCRIPTION 238 "The ForCES ID of the FE." 239 ::= { forcesAssociationEntry 2 } 241 forcesAssociationState OBJECT-TYPE 242 SYNTAX ForcesAssociationState 243 MAX-ACCESS read-only 244 STATUS current 245 DESCRIPTION 246 "The current operational state of the association 247 described by this row of the table." 248 ::= { forcesAssociationEntry 3 } 250 forcesAssociationUptime OBJECT-TYPE 251 SYNTAX TimeStamp 252 MAX-ACCESS read-only 253 STATUS current 254 DESCRIPTION 255 "The time when this association came up." 256 ::= { forcesAssociationEntry 4 } 258 forcesAssociationCreated OBJECT-TYPE 259 SYNTAX TimeStamp 260 MAX-ACCESS read-only 261 STATUS current 262 DESCRIPTION 263 "The time when this entry in the table was 264 created for this association." 265 ::= { forcesAssociationEntry 5 } 267 forcesAssociationTransitionsEstablishing OBJECT-TYPE 268 SYNTAX Counter32 269 MAX-ACCESS read-only 270 STATUS current 271 DESCRIPTION 272 "A counter of how many times this association 273 state changed from down to establishing." 274 ::= { forcesAssociationEntry 6} 276 forcesAssociationTransitionsUp OBJECT-TYPE 277 SYNTAX Counter32 278 MAX-ACCESS read-only 279 STATUS current 280 DESCRIPTION 281 "A counter of how many times this association 282 state changed from establishing to up." 283 ::= { forcesAssociationEntry 7} 285 forcesAssociationMsgSent OBJECT-TYPE 286 SYNTAX Counter32 287 MAX-ACCESS read-only 288 STATUS current 289 DESCRIPTION 290 "A counter of how many messages have been sent 291 on this association since it is up." 292 ::= { forcesAssociationEntry 8} 294 forcesAssociationMsgReceived OBJECT-TYPE 295 SYNTAX Counter32 296 MAX-ACCESS read-only 297 STATUS current 298 DESCRIPTION 299 "A counter of how many messages have been received 300 on this association since it is up." 301 ::= { forcesAssociationEntry 9} 303 END 305 6. Security Considerations 307 Some of the readable objects in this MIB module may be considered 308 sensitive or vulnerable in some network environment. 310 SNMP versions prior to SNMPv3 did not include adequate security. 311 Even if the network itself is secure (for example by using IPSec), 312 even then, there is no control as to who on the secure network is 313 allowed to access and GET/SET (read/change/create/delete) the objects 314 in this MIB module. 316 It is RECOMMENDED that implementers consider the security features as 317 provided by the SNMPv3 framework (see [RFC3410], section 8), 318 including full support for the SNMPv3 cryptographic mechanisms (for 319 authentication and privacy). 321 Further, deployment of SNMP versions prior to SNMPv3 is NOT 322 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 323 enable cryptographic security. It is then a customer/operator 324 responsibility to ensure that the SNMP entity giving access to an 325 instance of this MIB module is properly configured to give access to 326 the objects only to those principals (users) that have legitimate 327 rights to indeed GET or SET (change/create/delete) them. 329 7. IANA Considerations 331 IANA will need to assign a number to this MIB. 333 8. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 339 "Introduction and Applicability Statements for Internet- 340 Standard Management Framework", RFC 3410, December 2002. 342 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 343 of IP Control and Forwarding", RFC 3654, November 2003. 345 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 346 "Forwarding and Control Element Separation (ForCES) 347 Framework", RFC 3746, April 2004. 349 Author's Address 351 Robert Haas 352 IBM 353 Saeumerstrasse 4 354 Rueschlikon 8803 355 CH 357 Email: rha@zurich.ibm.com 358 URI: http://www.zurich.ibm.com/~rha 360 Intellectual Property Statement 362 The IETF takes no position regarding the validity or scope of any 363 Intellectual Property Rights or other rights that might be claimed to 364 pertain to the implementation or use of the technology described in 365 this document or the extent to which any license under such rights 366 might or might not be available; nor does it represent that it has 367 made any independent effort to identify any such rights. Information 368 on the procedures with respect to rights in RFC documents can be 369 found in BCP 78 and BCP 79. 371 Copies of IPR disclosures made to the IETF Secretariat and any 372 assurances of licenses to be made available, or the result of an 373 attempt made to obtain a general license or permission for the use of 374 such proprietary rights by implementers or users of this 375 specification can be obtained from the IETF on-line IPR repository at 376 http://www.ietf.org/ipr. 378 The IETF invites any interested party to bring to its attention any 379 copyrights, patents or patent applications, or other proprietary 380 rights that may cover technology that may be required to implement 381 this standard. Please address the information to the IETF at 382 ietf-ipr@ietf.org. 384 Disclaimer of Validity 386 This document and the information contained herein are provided on an 387 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 388 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 389 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 390 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 391 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 392 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 394 Copyright Statement 396 Copyright (C) The Internet Society (2006). This document is subject 397 to the rights, licenses and restrictions contained in BCP 78, and 398 except as set forth therein, the authors retain all their rights. 400 Acknowledgment 402 Funding for the RFC Editor function is currently provided by the 403 Internet Society.