idnits 2.17.1 draft-haas-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 49. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. 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 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.) ** 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 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 (December 2005) is 6700 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: 'RFC 3654' is mentioned on line 107, but not defined == Missing Reference: 'RFC 3746' is mentioned on line 121, but not defined -- Looks like a reference, but probably isn't: '7' on line 119 -- Looks like a reference, but probably isn't: '5' on line 119 -- Looks like a reference, but probably isn't: '2' on line 123 -- Looks like a reference, but probably isn't: '6' on line 130 == Unused Reference: 'RFC3654' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'RFC3746' is defined on line 397, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 ** Downref: Normative reference to an Informational RFC: RFC 3410 Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ForCES MIB December 7, 2005 3 ForCES 4 Internet Draft R. Haas 5 Document: draft-haas-forces-mib-02.txt IBM 6 Expires: June 7, 2006 December 2005 8 ForCES MIB 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 6 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 June 7, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 This document is subject to the rights, licenses and restrictions 40 contained in BCP 78, and except as set forth therein, the authors 41 retain all their rights. 43 This document and the information contained herein are provided on 44 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 45 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 46 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 47 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 48 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 49 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 51 Abstract 53 This memo defines a Management Information Base (MIB) for use with 54 network management protocols in the Internet community. In 55 particular, it defines a MIB for the Forwarding and Control Element 56 Separation (ForCES) Network Element (NE). The ForCES working group 57 is defining a protocol to allow a Control Element (CE) to control the 58 behavior of a Forwarding Element (FE). 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC-2119 [RFC2119]. 66 Table of Contents 68 1. Introduction...................................................2 69 2. Design of ForCES MIB...........................................4 70 3. Association State..............................................4 71 4. MIB Definition.................................................4 72 Security Considerations...........................................8 73 References........................................................9 74 Acknowledgments...................................................9 75 Author's Addresses................................................9 77 1. Introduction 79 The ForCES MIB is a primarily read-only MIB that captures information 80 related to the ForCES protocol. This includes state information about 81 the associations between CE(s) and FE(s) in the NE. 83 The ForCES MIB does not include information that is specified in 84 other MIBs, such as packet counters for interfaces, etc. 86 More specifically , the information in the ForCES MIB relative to 87 associations includes: 89 - identifiers of the elements in the association 90 - state of the association 91 - configuration parameters of the association 92 - statistics of the association 94 The relevant references from the ForCES requirements and architecture 95 documents are repeated below: 97 From the ForCES requirements RFC [RFC 3654], Section 4, point 4: 99 A NE MUST support the appearance of a single functional device. For 100 example, in a router, the TTL of the packet should be decremented 101 only once as it traverses the NE regardless of how many FEs through 102 which it passes. However, external entities (e.g., FE managers and 103 CE managers) MAY have direct access to individual ForCES protocol 104 elements for providing information to transition them from the pre- 105 association to post-association phase. 107 And [RFC 3654], Section 4, point 14: 109 1. The ability for a management tool (e.g., SNMP) to be used to 110 read(but not change) the state of FE SHOULD NOT be precluded. 111 2. It MUST NOT be possible for management tools (e.g., SNMP, etc) 112 to change the state of a FE in a manner that affects overall NE 113 behavior without the CE being notified. 115 According to the ForCES architecture RFC [RFC 3746], Section 3.3: 117 CE managers may be physically and logically separate entities that 118 configure the CE with FE information via such mechanisms as COPS-PR 119 [7] or SNMP [5]. 121 and [RFC 3746], Section 5.7: 123 RFC 1812 [2] also dictates that "Routers MUST be manageable by 124 SNMP". In general, for the post-association phase, most external 125 management tasks (including SNMP) should be done through 126 interaction with the CE in order to support the appearance of a 127 single functional device. Therefore, it is recommended that an SNMP 128 agent be implemented by CEs and that the SNMP messages received by 129 FEs be redirected to their CEs. AgentX framework defined in RFC 130 2741 ([6]) may be applied here such that CEs act in the role of 131 master agent to process SNMP protocol messages while FEs act in the 132 role of subagent to provide access to the MIB objects residing on 133 FEs. AgentX protocol messages between the master agent (CE) and 134 the subagent (FE) are encapsulated and transported via ForCES, just 135 like data packets from any other application layer protocols. 137 2. Design of ForCES MIB 139 In an NE composed of one or more FEs and a single CE, the CE is 140 clearly aware of all associations and hence can provide this 141 information in a single ForCES MIB. In contrast, in an NE composed of 142 more than one CE, such association information is distributed and 143 hence more than one ForCES MIB may be necessary, unless this 144 information is aggregated into a single ForCES MIB by some means 145 beyond the scope of this document. Nevertheless, the ForCES MIB 146 design is compatible with both the single-CE and the multiple-CE 147 case. 149 3. Association State 151 Association state as shown in the MIB is considered from the CE's 152 point of view: 153 - An association is in the DOWN state if the CE has not received any 154 message (heartbeat or other protocol message) from the FE within a 155 given time period or if an Association Teardown message has been 156 sent by the CE. 157 - An association is in the ESTABLISHING state as long as no message 158 has been received from the FE after the CE has sent a positive 159 Association Setup Response message. 160 - An association is in the UP state in all other cases. 162 Note that it is left to the implementers to choose how long entries 163 of associations in the DOWN state remain in the MIB until they are 164 removed, if at all. 166 The ForCES protocol may be used by the CE to query the FE Protocol 167 LFB about some of the configuration parameters. However, such queries 168 may obviously be issued only when the association is in the UP state. 169 Hence any MIB value that corresponds to such a parameter can only be 170 considered valid as long as the association is in the UP state. 171 [Note: there is no such parameter in the MIB at this time] 173 [Note: Should the MIB indicate whether associations have been 174 rejected ? Can this be a weakness exploited by DDoS if the MIB lists 175 all such rejected associations ?] 177 4. ForCES MIB Definition 179 For each association identified by the pair CE ID and FE ID, the 180 following information is provided by the MIB: 182 - Current state of the association: 184 DOWN: the CE(s) indicated by the CE ID and FE(s) indicated by the 185 FE ID are not associated. 187 ESTABLISHING: transient state until the association has been 188 established. See Section 3 above for details. 190 UP: the CE(s) indicated by the CE ID and FE(s) indicated by the FE 191 ID are associated. 193 Association statistics: 195 - Time when the association attained the UP state. 197 - Time when the association appeared in the MIB. 199 - Number of transitions to ESTABLISHING state since the association 200 appeared in the MIB. 202 - Number of transitions to UP state since the association appeared in 203 the MIB. 205 - Number of ForCES messages sent/received since the association 206 attained the UP state. 208 FORCES-MIB DEFINITIONS ::= BEGIN 210 IMPORTS 211 OBJECT-TYPE, MODULE-IDENTITY, 212 Integer32, Counter32, Unsigned32 213 FROM SNMPv2-SMI 215 TEXTUAL-CONVENTION, RowStatus, TimeInterval, TimeStamp 216 FROM SNMPv2-TC; 218 forcesMIB MODULE-IDENTITY 219 LAST-UPDATED "200512071200Z" -- Dec 7, 2005 220 ORGANIZATION "Forwarding and Control Element Separation 221 (ForCES) Working Group" 222 CONTACT-INFO 223 "Robert Haas (rha@zurich.ibm.com), IBM" 224 DESCRIPTION 225 "Initial version, published as RFC yyyy. This MIB 226 contains managed object definitions for the ForCES 227 Protocol." 228 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 229 ::= { mib-2 XXX } 230 -- RFC Ed.: replace XXX with IANA-assigned number & remove this note 232 --**************************************************************** 233 ForcesID ::= TEXTUAL-CONVENTION 234 STATUS current 235 DESCRIPTION 236 "The ForCES identifier is a four octet quantity." 237 SYNTAX OCTET STRING (SIZE (4)) 239 ForcesAssociationState ::= TEXTUAL-CONVENTION 240 STATUS current 241 DESCRIPTION 242 "The value down(1) indicates that the current state of 243 the association is down. establishing(2) indicates 244 that the association is in the process of being set 245 up. up(3) indicates that the association is up." 246 SYNTAX INTEGER { 247 down(1), 248 establishing(2), 249 up(3) 250 } 252 forcesAssociations OBJECT IDENTIFIER ::= { forcesMIB 1 } 254 forcesAssociationTable OBJECT-TYPE 255 SYNTAX SEQUENCE OF ForcesAssociationEntry 256 MAX-ACCESS not-accessible 257 STATUS current 258 DESCRIPTION 259 "The (conceptual) table of associations." 261 ::= { forcesAssociations 1 } 263 forcesAssociationEntry OBJECT-TYPE 264 SYNTAX ForcesAssociationEntry 265 MAX-ACCESS not-accessible 266 STATUS current 267 DESCRIPTION 268 "A (conceptual) entry for one association." 269 INDEX { forcesAssociationCEID, forcesAssociationFEID } 270 ::= { forcesAssociationTable 1 } 272 ForcesAssociationEntry ::= SEQUENCE { 273 forcesAssociationCEID ForcesID, 274 forcesAssociationFEID ForcesID, 275 forcesAssociationState ForcesAssociationState, 276 forcesAssociationUptime TimeStamp, 277 forcesAssociationCreated TimeStamp, 278 forcesAssociationTransitionsEstablishing Counter32, 279 forcesAssociationTransitionsUp Counter32, 280 forcesAssociationMsgSent Counter32, 281 forcesAssociationMsgReceived Counter32 282 } 284 forcesAssociationCEID OBJECT-TYPE 285 SYNTAX ForcesID 286 MAX-ACCESS read-only 287 STATUS current 288 DESCRIPTION 289 "The ForCES ID of the CE." 290 ::= { forcesAssociationEntry 1 } 292 forcesAssociationFEID OBJECT-TYPE 293 SYNTAX ForcesID 294 MAX-ACCESS read-only 295 STATUS current 296 DESCRIPTION 297 "The ForCES ID of the FE." 298 ::= { forcesAssociationEntry 2 } 300 forcesAssociationState OBJECT-TYPE 301 SYNTAX ForcesAssociationState 302 MAX-ACCESS read-only 303 STATUS current 304 DESCRIPTION 305 "The current operational state of the association 306 described by this row of the table." 307 ::= { forcesAssociationEntry 3 } 309 forcesAssociationUptime OBJECT-TYPE 310 SYNTAX TimeStamp 311 MAX-ACCESS read-only 312 STATUS current 313 DESCRIPTION 314 "The time when this association came up." 315 ::= { forcesAssociationEntry 4 } 317 forcesAssociationCreated OBJECT-TYPE 318 SYNTAX TimeStamp 319 MAX-ACCESS read-only 320 STATUS current 321 DESCRIPTION 322 "The time when this entry in the table was 323 created for this association." 325 ::= { forcesAssociationEntry 5 } 327 forcesAssociationTransitionsEstablishing OBJECT-TYPE 328 SYNTAX Counter32 329 MAX-ACCESS read-only 330 STATUS current 331 DESCRIPTION 332 "A counter of how many times this association 333 state changed from down to establishing." 334 ::= { forcesAssociationEntry 6} 336 forcesAssociationTransitionsUp OBJECT-TYPE 337 SYNTAX Counter32 338 MAX-ACCESS read-only 339 STATUS current 340 DESCRIPTION 341 "A counter of how many times this association 342 state changed from establishing to up." 343 ::= { forcesAssociationEntry 7} 345 forcesAssociationMsgSent OBJECT-TYPE 346 SYNTAX Counter32 347 MAX-ACCESS read-only 348 STATUS current 349 DESCRIPTION 350 "A counter of how many messages have been sent on 351 this association since it is up." 352 ::= { forcesAssociationEntry 8} 354 forcesAssociationMsgReceived OBJECT-TYPE 355 SYNTAX Counter32 356 MAX-ACCESS read-only 357 STATUS current 358 DESCRIPTION 359 "A counter of how many messages have been received on 360 this association since it is up." 361 ::= { forcesAssociationEntry 9} 363 END 365 Security Considerations 367 Some of the readable objects in this MIB module may be considered 368 sensitive or vulnerable in some network environment. 370 SNMP versions prior to SNMPv3 did not include adequate security. 371 Even if the network itself is secure (for example by using IPSec), 372 even then, there is no control as to who on the secure network is 373 allowed to access and GET/SET (read/change/create/delete) the objects 374 in this MIB module. 376 It is RECOMMENDED that implementers consider the security features as 377 provided by the SNMPv3 framework (see [RFC3410], section 8), 378 including full support for the SNMPv3 cryptographic mechanisms (for 379 authentication and privacy). 381 Further, deployment of SNMP versions prior to SNMPv3 is NOT 382 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 383 enable cryptographic security. It is then a customer/operator 384 responsibility to ensure that the SNMP entity giving access to an 385 instance of this MIB module is properly configured to give access to 386 the objects only to those principals (users) that have legitimate 387 rights to indeed GET or SET (change/create/delete) them. 389 References 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirements Levels", BCP 14, RFC 2119, March 1997. 394 [RFC3654] Khosravi, H,, and Anderson, T., "Requirements for 395 Separation of IP Control and Forwarding", RFC 3654, November 2003. 397 [RFC3746] Yang, L., Dantu, R., Anderson, T., Gopal, R., "Forwarding 398 and Control Element Separation (ForCES) Framework", RFC 3746, April 399 2004. 401 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 402 "Introduction and Applicability Statements for Internet- Standard 403 Management Framework", RFC 3410, December 2002. 405 Acknowledgments 407 The author wants to acknowledge the comments of the members of the 408 ForCES working group. 410 Author's Addresses 412 Robert Haas 413 IBM Research 414 Zurich Research Lab 415 Saeumerstrasse 4 416 8803 Rueschlikon 417 Switzerland 418 Email: rha@zurich.ibm.com