Network Working Group C. DeSanti Request for Comments: 4625 K. McCloghrie Category: Standards Track Cisco Systems S. Kode Consultant S. Gai Retired September 2006
Fibre Channel Routing Information MIB
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol.
DeSanti, et al. Standards Track [Page 1]
RFC 4625 FC Routing Information MIB September 2006
Table of Contents
1. Introduction ....................................................3 2. The Internet-Standard Management Framework ......................3 3. Short Overview of Fibre Channel .................................3 3.1. Introduction ...............................................3 3.2. Routing Protocols ..........................................4 3.3. Virtual Fabrics ............................................4 4. Relationship to Other MIBs ......................................5 5. MIB Overview ....................................................5 5.1. Fibre Channel Management Instance ..........................5 5.2. Switch Index ...............................................6 5.3. Fabric Index ...............................................6 5.4. The t11FcRouteGroup Group ..................................6 5.5. The t11FcRouteTable's INDEX ................................6 6. The T11-FC-ROUTE-MIB Module .....................................7 7. Acknowledgements ...............................................17 8. IANA Considerations ............................................17 9. Security Considerations ........................................17 10. Normative References ..........................................19 11. Informative References ........................................20
DeSanti, et al. Standards Track [Page 2]
RFC 4625 FC Routing Information MIB September 2006
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Routing Table for routing within a Fabric. Managed objects specific to particular routing protocols, such as the Fabric Shortest Path First (FSPF) protocol [FC-SW-4], are not specified in this MIB module.
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 RFC 2119 [RFC2119].
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [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, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher-level protocols, such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others.
Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port
DeSanti, et al. Standards Track [Page 3]
RFC 4625 FC Routing Information MIB September 2006
is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A switch port, which is interconnected to another switch port via an Inter-Switch Link (ISL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a switch; a B_Port provides a subset of E_Port functionality.
Many Fibre Channel components, including the fabric, each node, and most ports, have globally-unique names. These globally-unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS]. WWNs are expected to be persistent across agent and unit resets.
Fibre Channel frames contain 24-bit address identifiers that identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. When a fabric is in use, the FC address identifiers are dynamic and are assigned by a switch. Each octet of a 24-bit address represents a level in an address hierarchy, a Domain_ID being the highest level of the hierarchy.
The routing of frames within the Fabric is normally based on the standard routing protocol, called the Fabric Shortest Path First (FSPF) protocol. The operation of FSPF (or of any other routing protocol) allows a switch to generate and maintain its own routing table of how to forward frames it receives; i.e., a table in which to look up the destination address of a received frame in order to determine the best link by which to forward that frame towards its destination.
The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4] (which replaces the previous revision, [FC-SW-3]). [FC-SW-4] carries forward the existing specification for the operation of a single Fabric in a physical infrastructure, augmenting it with the definition of Virtual Fabrics and with the specification of how multiple Virtual Fabrics can operate within one (or more) physical infrastructures. The use of Virtual Fabrics provides for each frame to be tagged in its header to indicate which one of several Virtual Fabrics that frame is being transmitted on. All frames entering a particular "Core Switch" [FC-SW-4] (i.e., a physical switch) on the same Virtual Fabric are processed by the same "Virtual Switch" within that Core switch.
DeSanti, et al. Standards Track [Page 4]
RFC 4625 FC Routing Information MIB September 2006
The first standardized MIB for Fibre Channel [RFC2837] was focussed on Fibre Channel switches. It is being replaced by the more generic Fibre Channel Management MIB [FC-MGMT], which defines basic information for Fibre Channel hosts and switches, including extensions to the standard IF-MIB [RFC2863] for Fibre Channel interfaces.
This MIB extends beyond [FC-MGMT] to cover the routing of traffic within a Fabric of a Fibre Channel network. The standard routing protocol for Fibre Channel is FSPF [FC-SW-4]. Another MIB [RFC4626] specifies management information specific to FSPF. This MIB contains routing information that is independent of FSPF (i.e., it would still apply even if a routing protocol other than FSPF were in use in the network).
This MIB imports some common Textual Conventions from T11-TC-MIB, defined in [RFC4439].
This MIB module provides the means for monitoring the operation of, and configuring some parameters of, one or more instances of the FSPF protocol. (Note that there are no definitions in this MIB module of "managed actions" that can be invoked via SNMP.)
A Fibre Channel management instance is defined in [FC-MGMT] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent with multiple AgentX [RFC2741] sub-agents, each sub-agent implementing a different Fibre Channel management instance.
The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [FC-MGMT] as the index value that uniquely identifies each Fibre Channel management instance within the same SNMP context ([RFC3411], Section 3.3.1).
DeSanti, et al. Standards Track [Page 5]
RFC 4625 FC Routing Information MIB September 2006
The FC-MGMT-MIB [FC-MGMT] defines the fcmSwitchTable as a table of information about Fibre Channel switches that are managed by Fibre Channel management instances. Each Fibre Channel management instance can manage one or more Fibre Channel switches. The Switch Index, fcmSwitchIndex, is IMPORTed from the FC-MGMT-MIB as the index value that uniquely identifies a Fibre Channel switch among those (one or more) managed by the same Fibre Channel management instance.
Whether operating on a physical Fabric (i.e., without Virtual Fabrics) or within a Virtual Fabric, the operation of FSPF within a Fabric is identical. Therefore, this MIB defines all Fabric-related information in tables that are INDEX-ed by an arbitrary integer, named a "Fabric Index", the syntax of which is IMPORTed from the T11-TC-MIB. When a device is connected to a single physical Fabric, without use of any virtual Fabrics, the value of this Fabric Index will always be 1. In an environment of multiple virtual and/or physical Fabrics, this index provides a means to distinguish one Fabric from another.
It is quite possible, and may even be likely, that a Fibre Channel switch will have ports connected to multiple virtual and/or physical Fabrics. Thus, in order to simplify a management protocol query concerning all the Fabrics to which a single switch is connected, fcmSwitchIndex will be listed before t11FcRouteFabricIndex when they both appear in the same INDEX clause.
This MIB contains one object group, the t11FcRouteGroup, which contains objects to allow the displaying and the configuring of routes in the Fibre Channel Routing tables for the locally managed switches.
It is normally valuable for a MIB table that contains routes to be ordered such that a management application is able to query the table based on some attribute, without having to read every row in the MIB table. This requires that the rows in the table be ordered according to such attributes, and thus that those attributes be represented by objects included in the table's INDEX clause. Examples of this can be seen in the ipCidrRouteTable [RFC2096] and, more recently, the inetCidrRouteTable in [RFC4292].
DeSanti, et al. Standards Track [Page 6]
RFC 4625 FC Routing Information MIB September 2006
While this useful feature results in an unusually large number (ten) of objects in the t11FcRouteTable's INDEX clause, all ten are either integers or strings of 3 (or zero) octet length, so the resulting OIDs are not unusually large. (Specifically, the aggregate number of sub-identifiers to be appended to an OBJECT-TYPE's OID, when naming an instance of an object in the t11FcRouteTable, is at most 22 sub- identifiers; i.e., less than the *minimum* number to be appended for the inetCidrRouteTable table.)
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] RowStatus, TimeStamp, StorageType FROM SNMPv2-TC -- [RFC2579] InterfaceIndex, InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] fcmInstanceIndex, fcmSwitchIndex, FcAddressIdOrZero, FcDomainIdOrZero FROM FC-MGMT-MIB -- [FC-MGMT] T11FabricIndex FROM T11-TC-MIB; -- [RFC4439]
t11FcRouteMIB MODULE-IDENTITY LAST-UPDATED "200608140000Z" ORGANIZATION "T11" CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Email: kzm@cisco.com" DESCRIPTION "The MIB module for configuring and displaying Fibre Channel Route Information.
Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4625; see the RFC itself for full legal notices." REVISION "200608140000Z"
DeSanti, et al. Standards Track [Page 7]
RFC 4625 FC Routing Information MIB September 2006
DESCRIPTION "Initial version of this MIB module, published as RFC4625."
-- -- Per-Fabric routing information -- t11FcRouteFabricTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcRouteFabricEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing Fibre Channel Routing information that is specific to a Fabric." ::= { t11FcRouteObjects 1 }
t11FcRouteFabricEntry OBJECT-TYPE SYNTAX T11FcRouteFabricEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains routing information specific to a particular Fabric on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcRouteFabricIndex } ::= { t11FcRouteFabricTable 1 }
t11FcRouteFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index value that uniquely identifies a particular Fabric.
In a Fabric conformant to FC-SW-3, only a single Fabric
DeSanti, et al. Standards Track [Page 8]
RFC 4625 FC Routing Information MIB September 2006
can operate within a physical infrastructure, and thus the value of this Fabric Index will always be 1.
In a Fabric conformant to FC-SW-4, multiple Virtual Fabrics can operate within one (or more) physical infrastructures. In such a case, index value is used to uniquely identify a particular Fabric within a physical infrastructure." ::= { t11FcRouteFabricEntry 1 }
t11FcRouteFabricLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent time when any corresponding row in the t11FcRouteTable was created, modified, or deleted. A corresponding row in the t11FcRouteTable is for the same management instance, the same switch, and same Fabric as the row in this table.
If no change has occurred since the last restart of the management system, then the value of this object is 0." ::= { t11FcRouteFabricEntry 2 }
-- -- Fibre Channel Routing table -- t11FcRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Fibre Channel Routing tables for the locally managed switches. This table lists all the routes that are configured in and/or computed by any local switch for any Fabric.
Such routes are used by a switch to forward frames (of user data) on a Fabric. The conceptual process is based on extracting the Destination Fibre Channel Address Identifier (D_ID) out of a received frame (of user data) and comparing it to each entry of this table that is applicable to the given switch and Fabric. Such comparison consists of first performing a logical-AND of the extracted D_ID with a mask (the value of t11FcRouteDestMask) and second comparing the result of that 'AND' operation to the value of t11FcRouteDestAddrId. A similar comparison is made of the Source Fibre Channel Address Identifier (S_ID) of a frame
DeSanti, et al. Standards Track [Page 9]
RFC 4625 FC Routing Information MIB September 2006
against the t11FcRouteSrcAddrId and t11FcRouteSrcMask values of an entry. If an entry's value of t11FcRouteInInterface is non-zero, then a further comparison determines if the frame was received on the appropriate interface. If all of these comparisons for a particular entry are successful, then that entry represents a potential route for forwarding the received frame.
For entries configured by a user, t11FcRouteProto has the value 'netmgmt'; only entries of this type can be deleted by the user." ::= { t11FcRouteObjects 2 }
t11FcRouteEntry OBJECT-TYPE SYNTAX T11FcRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains a route to a particular destination, possibly from a particular subset of source addresses, on a particular Fabric via a particular output interface and learned in a particular manner." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcRouteFabricIndex, t11FcRouteDestAddrId, t11FcRouteDestMask, t11FcRouteSrcAddrId, t11FcRouteSrcMask, t11FcRouteInInterface, t11FcRouteProto, t11FcRouteOutInterface } ::= { t11FcRouteTable 1 } T11FcRouteEntry ::= SEQUENCE { t11FcRouteDestAddrId FcAddressIdOrZero, t11FcRouteDestMask FcAddressIdOrZero, t11FcRouteSrcAddrId FcAddressIdOrZero, t11FcRouteSrcMask FcAddressIdOrZero, t11FcRouteInInterface InterfaceIndexOrZero, t11FcRouteProto INTEGER, t11FcRouteOutInterface InterfaceIndex, t11FcRouteDomainId FcDomainIdOrZero, t11FcRouteMetric Unsigned32, t11FcRouteType INTEGER, t11FcRouteIfDown INTEGER, t11FcRouteStorageType StorageType, t11FcRouteRowStatus RowStatus }
RFC 4625 FC Routing Information MIB September 2006
MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination Fibre Channel Address Identifier of this route. A zero-length string for this field is not allowed." ::= { t11FcRouteEntry 1 }
t11FcRouteDestMask OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mask to be logical-ANDed with a destination Fibre Channel Address Identifier before it is compared to the value in the t11FcRouteDestAddrId field. Allowed values are 255.255.255, 255.255.0, or 255.0.0. FSPF's definition generates routes to a Domain_ID, so the mask for all FSPF-generated routes is 255.0.0. The zero-length value has the same meaning as 0.0.0." ::= { t11FcRouteEntry 2 }
t11FcRouteSrcAddrId OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The source Fibre Channel Address Identifier of this route. Note that if this object and the corresponding instance of t11FcRouteSrcMask both have a value of 0.0.0, then this route matches all source addresses. The zero-length value has the same meaning as 0.0.0." ::= { t11FcRouteEntry 3 }
t11FcRouteSrcMask OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mask to be logical-ANDed with a source Fibre Channel Address Identifier before it is compared to the value in the t11FcRouteSrcAddrId field. Allowed values are 255.255.255, 255.255.0, 255.0.0, or 0.0.0. The zero-length value has the same meaning as 0.0.0." ::= { t11FcRouteEntry 4 }
RFC 4625 FC Routing Information MIB September 2006
MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the value of this object is non-zero, it is the value of ifIndex that identifies the local Fibre Channel interface through which a frame must have been received in order to match with this entry. If the value of this object is zero, the matching does not require that the frame be received on any specific interface." ::= { t11FcRouteEntry 5 }
t11FcRouteProto OBJECT-TYPE SYNTAX INTEGER { other(1), local(2), netmgmt(3), fspf(4) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mechanism via which this route was learned: other(1) - not specified local(2) - local interface netmgmt(3)- static route fspf(4) - Fibre Shortest Path First " ::= { t11FcRouteEntry 6 }
t11FcRouteOutInterface OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex that identifies the local Fibre Channel interface through which the next hop of this route is to be reached." ::= { t11FcRouteEntry 7 }
t11FcRouteDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The domain_ID of next hop switch.
This object can have a value of zero if the value
DeSanti, et al. Standards Track [Page 12]
RFC 4625 FC Routing Information MIB September 2006
of t11FcRouteProto is 'local'." ::= { t11FcRouteEntry 8 }
t11FcRouteMetric OBJECT-TYPE SYNTAX Unsigned32 (0..65536) MAX-ACCESS read-create STATUS current DESCRIPTION "The routing metric for this route.
The use of this object is dependent on t11FcRouteProto." ::= { t11FcRouteEntry 9 }
t11FcRouteType OBJECT-TYPE SYNTAX INTEGER { local(1), remote(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of route.
local(1) - a route for which the next Fibre Channel port is the final destination; remote(2) - a route for which the next Fibre Channel port is not the final destination." DEFVAL {local} ::= { t11FcRouteEntry 10 }
t11FcRouteIfDown OBJECT-TYPE SYNTAX INTEGER { remove(1), retain(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates what happens to this route when the output interface (given by the corresponding value of t11FcRouteOutInterface) is operationally 'down'. If this object's value is 'retain', the route is to be retained in this table. If this object's value is 'remove', the route is to be removed from this table." DEFVAL { retain } ::= { t11FcRouteEntry 11 }
DeSanti, et al. Standards Track [Page 13]
RFC 4625 FC Routing Information MIB September 2006
t11FcRouteStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { t11FcRouteEntry 12 }
t11FcRouteRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The only rows that can be deleted by setting this object to 'destroy' are those for which t11FcRouteProto has the value 'netmgmt'." ::= { t11FcRouteEntry 13 }
t11FcRouteCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the T11-FC-ROUTE-MIB. -- -- Note: The next four OBJECT clauses are for auxiliary objects, and the -- SMIv2 does not permit inclusion of objects that are not accessible -- in an OBJECT clause (see Sections 3.1 & 5.4.3 in STD 58, RFC 2580). -- Thus, these four clauses cannot be included below in the normal -- location for OBJECT clauses. -- -- OBJECT t11FcRouteSrcAddrId -- SYNTAX FcAddressIdOrZero (SIZE (0)) -- DESCRIPTION -- 'Support is not required for routes that -- match only a subset of possible source
DeSanti, et al. Standards Track [Page 14]
RFC 4625 FC Routing Information MIB September 2006
-- addresses.' -- -- OBJECT t11FcRouteSrcMask -- SYNTAX FcAddressIdOrZero (SIZE (0)) -- DESCRIPTION -- 'Support is not required for routes that -- match only a subset of possible source -- addresses.' -- -- OBJECT t11FcRouteDestMask -- DESCRIPTION -- 'Support is mandatory only for FSPF-generated -- routes. Since FSPF's definition generates -- routes to a Domain_ID, the mask for all -- FSPF-generated routes is 255.0.0. Thus, -- support is only required for 255.0.0.' -- -- OBJECT t11FcRouteInInterface -- SYNTAX InterfaceIndexOrZero (0) -- DESCRIPTION -- 'Support for routes specific to particular -- source interfaces is not required.' "
MODULE -- this module MANDATORY-GROUPS { t11FcRouteGroup }
OBJECT t11FcRouteIfDown MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT t11FcRouteDomainId MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT t11FcRouteMetric MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT t11FcRouteType MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT t11FcRouteStorageType
DeSanti, et al. Standards Track [Page 15]
RFC 4625 FC Routing Information MIB September 2006
MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT t11FcRouteRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required."
::= { t11FcRouteCompliances 1 } t11FcRouteGroup OBJECT-GROUP OBJECTS { t11FcRouteFabricLastChange, t11FcRouteDomainId, t11FcRouteMetric, t11FcRouteType, t11FcRouteIfDown, t11FcRouteStorageType, t11FcRouteRowStatus } STATUS current DESCRIPTION "A collection of objects for displaying and configuring routes." ::= { t11FcRouteGroups 1 }
END
DeSanti, et al. Standards Track [Page 16]
RFC 4625 FC Routing Information MIB September 2006
This document was originally developed and approved by the INCITS Task Group T11.5 (http://www.t11.org) as the SM-RTM project. We wish to acknowledge the contributions and comments from the INCITS Technical Committee T11, including the following:
T11 Chair: Robert Snively, Brocade T11 Vice Chair: Claudio DeSanti, Cisco Systems T11.5 Chair: Roger Cummings, Symantec T11.5 members, especially: Ken Hirata, Emulex Scott Kipp, McData Elizabeth G. Rodriguez, Dot Hill
The document was subsequently approved by the IETF's IMSS Working Group, chaired by David Black (EMC Corporation). We also wish to acknowledge Bert Wijnen (Lucent Technologies), the IETF Area Director, for his review of the document.
There are several management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These objects and their sensitivity/vulnerability are:
Such objects may be considered sensitive or vulnerable in some network environments. For example, the ability to change network topology or network speed may afford an attacker the ability to obtain better performance at the expense of other network users. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
DeSanti, et al. Standards Track [Page 17]
RFC 4625 FC Routing Information MIB September 2006
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. The objects and their sensitivity/vulnerability are: the write-able objects listed above plus one other:
t11FcRouteLastChangeTime -- the time of the last routing table change.
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 implementors 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 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.
DeSanti, et al. Standards Track [Page 18]
RFC 4625 FC Routing Information MIB September 2006
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC4439] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "Fibre Channel Fabric Address Manager MIB", RFC 4439, March 2006.
[RFC4626] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol", RFC 4626, September 2006.
[FC-FS] "Fibre Channel - Framing and Signaling (FC-FS)", ANSI INCITS 373-2003, April 2003.
[RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000.
[RFC2837] Teow, K., "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard", RFC 2837, May 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
RFC 4625 FC Routing Information MIB September 2006
Authors' Addresses
Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Phone: +1 408 853-9172 EMail: cds@cisco.com
Srini Kode Consultant
Phone: 408-348-5343 EMail: srinikode@yahoo.com
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
Phone: +1 408-526-5260 EMail: kzm@cisco.com
Silvano Gai Retired
DeSanti, et al. Standards Track [Page 21]
RFC 4625 FC Routing Information MIB September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).