summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5813.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5813.txt')
-rw-r--r--doc/rfc/rfc5813.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5813.txt b/doc/rfc/rfc5813.txt
new file mode 100644
index 0000000..b979d95
--- /dev/null
+++ b/doc/rfc/rfc5813.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Haas
+Request for Comments: 5813 IBM
+Category: Standards Track March 2010
+ISSN: 2070-1721
+
+
+ Forwarding and Control Element Separation (ForCES) MIB
+
+Abstract
+
+ This memo defines a Management Information Base (MIB) module for use
+ with network management protocols in the Internet community. In
+ particular, it defines managed objects for the Forwarding and Control
+ Element Separation (ForCES) Network Element (NE).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5813.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+Haas Standards Track [Page 1]
+
+RFC 5813 ForCES MIB March 2010
+
+
+Table of Contents
+
+ 1. The Internet-Standard Management Framework ......................2
+ 2. Introduction ....................................................2
+ 3. Requirements Notation ...........................................3
+ 4. ForCES MIB Overview .............................................3
+ 5. ForCES MIB Definition ...........................................4
+ 6. Associations Kept in the MIB ...................................13
+ 7. Support for Multiple CEs and FEs ...............................14
+ 8. Security Considerations ........................................14
+ 9. IANA Considerations ............................................15
+ 10. References ....................................................15
+ 10.1. Normative References .....................................15
+ 10.2. Informative References ...................................16
+ Appendix A. Acknowledgments ......................................17
+
+1. The Internet-Standard Management Framework
+
+ For a detailed overview of the documents that describe the current
+ Internet-Standard Management Framework, please refer to section 7 of
+ [RFC3410].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. MIB objects are generally
+ accessed through the Simple Network Management Protocol (SNMP).
+ Objects in the MIB are defined using the mechanisms defined in the
+ Structure of Management Information (SMI). This memo specifies a MIB
+ module that is compliant to the SMIv2, which is described in STD 58,
+ [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580].
+
+2. Introduction
+
+ The ForCES MIB module is a read-only MIB module that captures
+ information related to the ForCES protocol ([RFC3654], [RFC3746],
+ [FORCES-APP], and [RFC5810]).
+
+ The ForCES MIB module does not include information that is specified
+ in other MIB modules, such as packet counters for interfaces, etc.
+
+ More specifically, the information in the ForCES MIB module relative
+ to associations (between Control Elements and Forwarding Elements)
+ that are in the UP state includes:
+
+ o identifiers of the elements in the association,
+
+ o configuration parameters of the association, and
+
+ o statistics of the association.
+
+
+
+Haas Standards Track [Page 2]
+
+RFC 5813 ForCES MIB March 2010
+
+
+3. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+4. ForCES MIB Overview
+
+ The MIB module contains the latest ForCES protocol version supported
+ by the Control Element (CE) (forcesLatestProtocolVersionSupported).
+ Note that the CE must also allow interaction with Forwarding Elements
+ (FEs) supporting earlier versions.
+
+ For each association identified by the pair CE ID and FE ID, the
+ following associated information is provided by the MIB module as an
+ entry (forcesAssociationEntry) in the association table
+ (forcesAssociationTable):
+
+ o Version number of the ForCES protocol running in this association
+ (forcesAssociationRunningProtocolVersion).
+
+ o Time when the association entered the UP state
+ (forcesAssociationTimeUp).
+
+ o Time when the association left the UP state
+ (forcesAssociationTimeDown). Note that this is only used for
+ notification purposes as the association is removed from the MIB
+ immediately after it leaves the UP state.
+
+ o Number of ForCES Heartbeat messages sent from the CE
+ (forcesAssociationHBMsgSent) and received by the CE
+ (forcesAssociationHBMsgReceived) since the association entered the
+ UP state.
+
+ o Number of operational ForCES messages sent from the CE
+ (forcesAssociationOperMsgSent) and received by the CE
+ (forcesAssociationOperMsgReceived) since the association entered
+ the UP state. Only messages other than Heartbeat, Association
+ Setup, Association Setup Response, and Association Teardown are
+ counted.
+
+ Finally, the MIB module defines the following notifications:
+
+ o Whenever an association enters the UP state, a notification
+ (forcesAssociationEntryUp) is issued containing the version of the
+ ForCES protocol running. CE ID and FE ID are concatenated to form
+ the table index, hence they appear in the OID of the ForCES-
+ protocol running-version object. Optionally, a notification
+
+
+
+Haas Standards Track [Page 3]
+
+RFC 5813 ForCES MIB March 2010
+
+
+ (forcesAssociationEntryUpStats) can instead be issued with all
+ associated information for this association, except
+ forcesAssociationTimeDown.
+
+ o Whenever an association leaves the UP state, a notification
+ (forcesAssociationEntryDown) is issued containing the version of
+ the ForCES protocol running. Optionally, a notification
+ (forcesAssociationEntryDownStats) can instead be issued with all
+ associated information for this association. The reason is that
+ the association and all its associated information will be removed
+ from the MIB immediately after this notification has been issued.
+
+5. ForCES MIB Definition
+
+ FORCES-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
+ mib-2, Integer32
+ FROM SNMPv2-SMI
+
+ TEXTUAL-CONVENTION, TimeStamp
+ FROM SNMPv2-TC
+
+ MODULE-COMPLIANCE, OBJECT-GROUP,
+ NOTIFICATION-GROUP
+ FROM SNMPv2-CONF
+
+ ZeroBasedCounter32
+ FROM RMON2-MIB;
+
+ forcesMib MODULE-IDENTITY
+ LAST-UPDATED "201003100000Z" -- March 10, 2010
+ ORGANIZATION "IETF Forwarding and Control Element
+ Separation (ForCES) Working Group"
+ CONTACT-INFO
+ "WG Charter:
+ http://www.ietf.org/html.charters/forces-charter.html
+
+ Mailing lists:
+ General Discussion: forces@ietf.org
+ To Subscribe:
+ https://www.ietf.org/mailman/listinfo/forces
+
+ Chairs: Patrick Droz
+ Email: dro@zurich.ibm.com
+ Jamal Hadi Salim
+ Email: hadi@mojatatu.com
+
+
+
+Haas Standards Track [Page 4]
+
+RFC 5813 ForCES MIB March 2010
+
+
+ Editor: Robert Haas
+ IBM
+ Email: rha@zurich.ibm.com"
+ DESCRIPTION
+ "This MIB module contains managed object definitions
+ for the ForCES Protocol.
+
+ Copyright (c) 2010 IETF Trust and the persons identified
+ as authors of the code. All rights reserved.
+
+ Redistribution and use in source and binary forms, with
+ or without modification, is permitted pursuant to, and
+ subject to the license terms contained in, the
+ Simplified BSD License set forth in Section 4.c of the
+ IETF Trust's Legal Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info).
+
+ This version of this MIB module is part of RFC 5813;
+ see the RFC itself for full legal notices."
+ REVISION "201003100000Z" -- March 10, 2010
+ DESCRIPTION
+ "Initial version, published as RFC 5813."
+ ::= { mib-2 187 }
+
+ --****************************************************************
+
+ forcesMibNotifications OBJECT IDENTIFIER ::= { forcesMib 0 }
+ forcesMibObjects OBJECT IDENTIFIER ::= { forcesMib 1 }
+ forcesMibConformance OBJECT IDENTIFIER ::= { forcesMib 2 }
+
+ ForcesID ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "The ForCES identifier is a 4-octet quantity."
+ SYNTAX OCTET STRING (SIZE (4))
+
+ ForcesProtocolVersion ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "d"
+ STATUS current
+ DESCRIPTION
+ "ForCES protocol version number.
+ The version numbers used are defined in the
+ specifications of the respective protocol:
+ 1 - ForCESv1, RFC 5810."
+ SYNTAX Integer32 (1..255)
+
+
+
+
+
+
+Haas Standards Track [Page 5]
+
+RFC 5813 ForCES MIB March 2010
+
+
+-- Notifications
+
+ forcesAssociationEntryUp NOTIFICATION-TYPE
+ OBJECTS {
+ forcesAssociationRunningProtocolVersion
+ }
+ STATUS current
+ DESCRIPTION
+ "This notification is generated as soon
+ as an association enters the UP state.
+ Note that these notifications are not
+ throttled as the CE itself should
+ throttle the setup of associations."
+ ::= { forcesMibNotifications 1 }
+
+ forcesAssociationEntryDown NOTIFICATION-TYPE
+ OBJECTS {
+ forcesAssociationRunningProtocolVersion
+ }
+ STATUS current
+ DESCRIPTION
+ "This notification is generated as soon
+ as an association leaves the UP state.
+ Note that these notifications are not
+ throttled as the CE itself should
+ throttle the setup of associations."
+ ::= { forcesMibNotifications 2 }
+
+ forcesAssociationEntryUpStats NOTIFICATION-TYPE
+ OBJECTS {
+ forcesAssociationRunningProtocolVersion,
+ forcesAssociationTimeUp
+ }
+ STATUS current
+ DESCRIPTION
+ "This notification is generated as soon
+ as an association enters the UP state.
+ Note that these notifications are not
+ throttled as the CE itself should
+ throttle the setup of associations."
+ ::= { forcesMibNotifications 3 }
+
+
+
+
+
+
+
+
+
+
+Haas Standards Track [Page 6]
+
+RFC 5813 ForCES MIB March 2010
+
+
+ forcesAssociationEntryDownStats NOTIFICATION-TYPE
+ OBJECTS {
+ forcesAssociationRunningProtocolVersion,
+ forcesAssociationTimeUp,
+ forcesAssociationTimeDown,
+ forcesAssociationHBMsgSent,
+ forcesAssociationHBMsgReceived,
+ forcesAssociationOperMsgSent,
+ forcesAssociationOperMsgReceived,
+ forcesAssociationCounterDiscontinuityTime
+ }
+ STATUS current
+ DESCRIPTION
+ "This notification is generated as soon
+ as an association leaves the UP state.
+ Note that these notifications are not
+ throttled as the CE itself should
+ throttle the setup of associations."
+ ::= { forcesMibNotifications 4 }
+
+-- Objects
+
+ forcesLatestProtocolVersionSupported OBJECT-TYPE
+ SYNTAX ForcesProtocolVersion
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The ForCES protocol version supported by the CE.
+ The current protocol version is 1.
+ Note that the CE must also allow interaction
+ with FEs supporting earlier versions."
+ ::= { forcesMibObjects 1 }
+
+ forcesAssociations OBJECT IDENTIFIER ::= { forcesMibObjects 2 }
+
+ forcesAssociationTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF ForcesAssociationEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The (conceptual) table of associations."
+ ::= { forcesAssociations 1 }
+
+
+
+
+
+
+
+
+
+Haas Standards Track [Page 7]
+
+RFC 5813 ForCES MIB March 2010
+
+
+ forcesAssociationEntry OBJECT-TYPE
+ SYNTAX ForcesAssociationEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A (conceptual) entry for one association."
+ INDEX { forcesAssociationCEID, forcesAssociationFEID }
+ ::= { forcesAssociationTable 1 }
+
+ ForcesAssociationEntry ::= SEQUENCE {
+ forcesAssociationCEID ForcesID,
+ forcesAssociationFEID ForcesID,
+
+ forcesAssociationRunningProtocolVersion
+ ForcesProtocolVersion,
+
+ forcesAssociationTimeUp TimeStamp,
+ forcesAssociationTimeDown TimeStamp,
+
+ forcesAssociationHBMsgSent ZeroBasedCounter32,
+ forcesAssociationHBMsgReceived ZeroBasedCounter32,
+ forcesAssociationOperMsgSent ZeroBasedCounter32,
+ forcesAssociationOperMsgReceived ZeroBasedCounter32,
+ forcesAssociationCounterDiscontinuityTime TimeStamp
+ }
+
+ forcesAssociationCEID OBJECT-TYPE
+ SYNTAX ForcesID
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The ForCES ID of the CE."
+ ::= { forcesAssociationEntry 1 }
+
+ forcesAssociationFEID OBJECT-TYPE
+ SYNTAX ForcesID
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The ForCES ID of the FE."
+ ::= { forcesAssociationEntry 2 }
+
+
+
+
+
+
+
+
+
+
+Haas Standards Track [Page 8]
+
+RFC 5813 ForCES MIB March 2010
+
+
+ forcesAssociationRunningProtocolVersion OBJECT-TYPE
+ SYNTAX ForcesProtocolVersion
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The current ForCES protocol version used in
+ this association.
+ The current protocol version is 1."
+ ::= { forcesAssociationEntry 3 }
+
+ forcesAssociationTimeUp OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime at the time this
+ association entered the UP state.
+ If this association started prior to the last
+ initialization of the network subsystem, then
+ this object contains a zero value.
+ This object allows to uniquely identify
+ associations with the same CE and FE IDs."
+ ::= { forcesAssociationEntry 4 }
+
+ forcesAssociationTimeDown OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS accessible-for-notify
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime at the time this
+ association left the UP state."
+ ::= { forcesAssociationEntry 5 }
+
+ forcesAssociationHBMsgSent OBJECT-TYPE
+ SYNTAX ZeroBasedCounter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter of how many Heartbeat messages have
+ been sent by the CE on this association
+ since the association entered the UP state.
+ Discontinuities in the value of this counter
+ can occur at reinitialization of the management
+ system, and at other times as indicated by the
+ value of forcesAssociationCounterDiscontinuityTime."
+ ::= { forcesAssociationEntry 6 }
+
+
+
+
+
+Haas Standards Track [Page 9]
+
+RFC 5813 ForCES MIB March 2010
+
+
+ forcesAssociationHBMsgReceived OBJECT-TYPE
+ SYNTAX ZeroBasedCounter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter of how many Heartbeat messages
+ have been received by the CE on this association
+ since the association entered the UP state.
+ Discontinuities in the value of this counter
+ can occur at reinitialization of the management
+ system, and at other times as indicated by the
+ value of forcesAssociationCounterDiscontinuityTime."
+ ::= { forcesAssociationEntry 7 }
+
+ forcesAssociationOperMsgSent OBJECT-TYPE
+ SYNTAX ZeroBasedCounter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter of how many messages other than
+ Heartbeat (i.e., Config and Query)
+ have been sent by the CE on this association
+ since the association entered the UP state.
+ Discontinuities in the value of this counter
+ can occur at reinitialization of the management
+ system, and at other times as indicated by the
+ value of forcesAssociationCounterDiscontinuityTime."
+ ::= { forcesAssociationEntry 8 }
+
+ forcesAssociationOperMsgReceived OBJECT-TYPE
+ SYNTAX ZeroBasedCounter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter of how many messages other than
+ Heartbeat (i.e., Config response, Query response,
+ event notification, and packet redirect)
+ have been received by the CE on this association
+ since the association entered the UP state.
+ Discontinuities in the value of this counter
+ can occur at reinitialization of the management
+ system, and at other times as indicated by the
+ value of forcesAssociationCounterDiscontinuityTime."
+ ::= { forcesAssociationEntry 9 }
+
+
+
+
+
+
+
+Haas Standards Track [Page 10]
+
+RFC 5813 ForCES MIB March 2010
+
+
+ forcesAssociationCounterDiscontinuityTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime on the most recent occasion
+ at which any one or more of this association's
+ counters suffered a discontinuity. The relevant
+ counters are the specific instances associated with
+ this association of any ZeroBasedCounter32 object
+ contained in the forcesAssociationTable. If no
+ such discontinuities have occurred since the last
+ reinitialization of the local management subsystem,
+ then this object contains a zero value."
+ ::= { forcesAssociationEntry 10 }
+
+-- Conformance
+
+ forcesMibCompliances OBJECT IDENTIFIER
+ ::= { forcesMibConformance 1 }
+ forcesMibGroups OBJECT IDENTIFIER
+ ::= { forcesMibConformance 2 }
+
+-- Compliance statements
+
+ forcesMibCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for routers running
+ ForCES and implementing the ForCES MIB."
+ MODULE -- this module
+ MANDATORY-GROUPS { forcesMibGroup, forcesNotificationGroup }
+
+ GROUP forcesNotificationStatsGroup
+ DESCRIPTION
+ "Implementation of this group is recommended."
+
+ GROUP forcesStatsGroup
+ DESCRIPTION
+ "Implementation of this group is recommended."
+
+ ::= { forcesMibCompliances 1 }
+
+
+
+
+
+
+
+
+
+Haas Standards Track [Page 11]
+
+RFC 5813 ForCES MIB March 2010
+
+
+-- Units of conformance
+
+ forcesNotificationGroup NOTIFICATION-GROUP
+ NOTIFICATIONS { forcesAssociationEntryUp,
+ forcesAssociationEntryDown
+ }
+ STATUS current
+ DESCRIPTION
+ "A collection of notifications for signaling
+ important ForCES events."
+ ::= { forcesMibGroups 1 }
+
+ forcesMibGroup OBJECT-GROUP
+ OBJECTS { forcesLatestProtocolVersionSupported,
+ forcesAssociationRunningProtocolVersion
+ }
+ STATUS current
+ DESCRIPTION
+ "A collection of objects to support management
+ of ForCES routers."
+ ::= { forcesMibGroups 2 }
+
+ forcesNotificationStatsGroup NOTIFICATION-GROUP
+ NOTIFICATIONS { forcesAssociationEntryUpStats,
+ forcesAssociationEntryDownStats
+ }
+ STATUS current
+ DESCRIPTION
+ "A collection of optional notifications for
+ signaling important ForCES events including
+ statistics."
+ ::= { forcesMibGroups 3 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haas Standards Track [Page 12]
+
+RFC 5813 ForCES MIB March 2010
+
+
+ forcesStatsGroup OBJECT-GROUP
+ OBJECTS { forcesAssociationTimeUp,
+ forcesAssociationTimeDown,
+ forcesAssociationHBMsgSent,
+ forcesAssociationHBMsgReceived,
+ forcesAssociationOperMsgSent,
+ forcesAssociationOperMsgReceived,
+ forcesAssociationCounterDiscontinuityTime
+ }
+ STATUS current
+ DESCRIPTION
+ "A collection of optional objects to provide
+ extra information about the associations.
+ There is no protocol reason to keep such
+ information, but these objects can be very
+ useful in debugging connectivity problems."
+ ::= { forcesMibGroups 4}
+
+ END
+
+6. Associations Kept in the MIB
+
+ Associations enter the UP state as soon as the CE has sent to the FE
+ an Association Setup Response message containing a successful
+ Association Setup Result. Only associations that are UP are
+ reflected in this MIB module.
+
+ Associations are removed from the MIB module as soon as they leave
+ the UP state, i.e., if the CE has not received any message (Heartbeat
+ or other protocol message) from the FE within a given time period or
+ if an Association Teardown message has been sent by the CE.
+
+ Statistics counters are initialized to zero when the association is
+ created. If the same association goes down and comes back up, the
+ counters will reset and the discontinuity can be discovered by
+ checking the discontinuity timestamp. In addition, the time-up
+ timestamp in the association allows to distinguish new associations
+ from past ones with the same index. Note that the optional down
+ notification contains the statistics with the final values of the
+ statistics counters.
+
+
+
+
+
+
+
+
+
+
+
+Haas Standards Track [Page 13]
+
+RFC 5813 ForCES MIB March 2010
+
+
+7. Support for Multiple CEs and FEs
+
+ An NE consists of one or more FEs and one or more CEs. Where there
+ is a single CE, that CE will have knowledge of all the associations
+ in the NE and so can provide the information necessary to support the
+ managed objects defined in this MIB module. Where there is more than
+ one CE, information about the associations may be distributed among
+ the CEs. Whether each CE implements the managed objects for the
+ associations of which it is aware or whether the CEs cooperate to
+ present the appearance of a single set of managed objects for all the
+ associations in the NE is outside the scope of this document.
+
+8. Security Considerations
+
+ There are no management objects defined in this MIB module that have
+ a MAX-ACCESS clause of read-write and/or read-create. So, if this
+ MIB module is implemented correctly, then there is no risk that an
+ intruder can alter or create any management objects of this MIB
+ module via direct SNMP SET operations.
+
+ Some of the readable objects in this MIB module (i.e., objects with a
+ MAX-ACCESS other than not-accessible) may be considered sensitive or
+ vulnerable in some network environments. It is thus important to
+ control even GET and/or NOTIFY access to these objects and possibly
+ to even encrypt the values of these objects when sending them over
+ the network via SNMP. These are the tables and objects and their
+ sensitivity/vulnerability:
+
+ o Objects in the forcesMibGroup are protocol versions. They are
+ neither sensitive nor vulnerable.
+
+ o Objects in the forcesStatsGroup are statistics. They are neither
+ sensitive nor vulnerable.
+
+ SNMP versions prior to SNMPv3 did not include adequate security.
+ Even if the network itself is secure (for example by using IPsec),
+ even then, there is no control as to who on the secure network is
+ allowed to access and GET/SET (read/change/create/delete) the objects
+ in this MIB module.
+
+ It is RECOMMENDED that implementers consider the security features as
+ provided by the SNMPv3 framework (see [RFC3410], section 8),
+ including full support for the SNMPv3 cryptographic mechanisms (for
+ authentication and privacy).
+
+ Further, deployment of SNMP versions prior to SNMPv3 is NOT
+ RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
+ enable cryptographic security. It is then a customer/operator
+
+
+
+Haas Standards Track [Page 14]
+
+RFC 5813 ForCES MIB March 2010
+
+
+ responsibility to ensure that the SNMP entity giving access to an
+ instance of this MIB module is properly configured to give access to
+ the objects only to those principals (users) that have legitimate
+ rights to indeed GET or SET (change/create/delete) them.
+
+9. IANA Considerations
+
+ The MIB module in this document uses the following IANA-assigned
+ OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
+
+ Descriptor OBJECT IDENTIFIER value
+ ---------- -----------------------
+
+ forcesMIB { mib-2 187 }
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Structure of Management Information
+ Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
+
+ [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Textual Conventions for SMIv2",
+ STD 58, RFC 2579, April 1999.
+
+ [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+ "Conformance Statements for SMIv2", STD 58, RFC 2580,
+ April 1999.
+
+ [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed.,
+ Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and
+ J. Halpern, "Forwarding and Control Element Separation
+ (ForCES) Protocol Specification", RFC 5810, March 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haas Standards Track [Page 15]
+
+RFC 5813 ForCES MIB March 2010
+
+
+10.2. Informative References
+
+ [FORCES-APP]
+ Crouch, A., Khosravi, H., Doria, A., Wang, X., and K.
+ Ogawa, "ForCES Applicability Statement", Work in Progress,
+ February 2010.
+
+ [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+ "Introduction and Applicability Statements for
+ Internet-Standard Management Framework", RFC 3410,
+ December 2002.
+
+ [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
+ of IP Control and Forwarding", RFC 3654, November 2003.
+
+ [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
+ "Forwarding and Control Element Separation (ForCES)
+ Framework", RFC 3746, April 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haas Standards Track [Page 16]
+
+RFC 5813 ForCES MIB March 2010
+
+
+Appendix A. Acknowledgments
+
+ The author gratefully acknowledges the contributions of Spencer
+ Dawkins, Jinrong Fenggen, John Flick, Xiaoyi Guo, Joel Halpern, Tom
+ Petch, Jamal Hadi Salim, and Bert Wijnen.
+
+Author's Address
+
+ Robert Haas
+ IBM
+ Saeumerstrasse 4
+ Rueschlikon 8803
+ CH
+
+ EMail: rha@zurich.ibm.com
+ URI: http://www.zurich.ibm.com/~rha
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haas Standards Track [Page 17]
+