SA Methods and Attributes

SA Methods

Table 33-3 on page 925 lists the methods that may be specified when performing SA attribute accesses. Note that SA support for the SubnAdmGetBulk() and Subn AdmGetBulkResp() methods is optional (for more information, see the description of the ClassPortInfo.CapabilityMask bits in Table 33-4 on page 927).

Table 33-3. SA Methods

Method	Value	MultiPacket?	Required?	Description
SubnAdmGet()	01h	No	Yes	Read an attribute. The SA responds with a SubnAdmGetResp().
SubnAdmSet()	02h	No	Yes	Write to an attribute. The SA responds with a SubnAdmGetResp().
SubnAdmGetResp()	81h	No	Yes	The response to an attribute Get or Set.
SubnAdmInform(InformInfo)	10h	No	Yes	Request an event subscription. For more information, refer to “Event Subscription and Event Forwarding” on page 801.
SubnAdmInformResp(InformInfo)	90h	No	Yes	Reply to an event subscription request. For more information, refer to “Event Subscription and Event Forwarding” on page 801.
SubnAdmReport(Notice)	06h	No	Yes	When the SA receives a SubnTrap(Notice) from a device, it uses the SubnAdmReport(Notice) to deliver the event Notice to the subscriber. For more information, refer to “Event Subscription and Event Forwarding” on page 801.
SubnAdmReportResp(Notice)	86h	No	Yes	After receipt of a SubnAdmReport(Notice) from the SA, the subscriber responds to the SA with a SubnAdmReportResp(Notice). For more information, refer to “Event Subscription and Event Forwarding” on page 801.
SubnAdmGetTable()	12h	No	Yes	A request to read a table from the SA. For more information, refer to “Database Queries Using SubnAdmGetTable()” on page 945 and “Definition of a Table” on page 941.
SubnAdmGetTableResp()	92h	Yes	Yes	Upon receipt of a SubnAdmGetTable(), the SA responds with a SubnAdmGetTableResp() consisting of a series of one or more response packets containing the records. For more information, refer to “Database Queries Using SubnAdmGetTable()” on page 945.
SubnAdmGetBulk()	13h	No	No	Request from a SM for a dump (i.e., a mass read) of the entire SA database. It is optional whether or not the SA supports this operation. If it does not, a response MAD is returned with the Status field (refer to Table 27-2 on page 776) bit set indicating that “the specified Method is not supported.” If this method is supported, a series of one or more SubnAdm GetBulkResp() response packets are returned, and the data field of the first response packet contains the SAResponse attribute (see Table 33-4 on page 927 and “SAResponse” on page 974). For more information, refer to “Fetch Entire Database” on page 948.
SubnAdmGetBulkResp()	93h	Yes	No	Assuming that the SA supports the optional SubnAdmGetBulk() operation, the SA responds with a series of one or more SubnAdmGetBulkResp() response packets. For more information, refer to “Fetch Entire Database” on page 948.
SubnAdmConfig()	15h	Yes	Yes	Request to add, delete, or modify an entire SA table (rather than a single attribute record). It consists of a series of one or more SubnAdmConfig() request packets containing the records to be added, deleted, or modified in the target table. For more information, refer to “SubnAdmConfig() Operation” on page 941.
SubnAdmConfigResp()	95h	Yes	Yes	Upon receipt of each SubnAdmConfig() request packet, the SA responds with a SubnAdmConfigResp() response packet. For more information, refer to “SubnAdmConfig() Operation” on page 941.

SA Attributes

The SA attributes accessed via the SA are listed in Table 33-4 on this page. For the attributes shown as not required, the attribute description defines the circumstances under which each of them is supported. In addition, most of the attributes are defined as being Record Attributes. Each of these attributes is actually a record (i.e., a copy) containing the current contents of that attribute in a subnet device. “Record Attribute (RA)” on page 933 defines what an record attribute is.

The items in Table 33-4 on this page that are not RA's are actual SA attributes rather than copies (records) of other devices' attributes.

Table 33-4. SA Attributes

Name	Attribute ID	Required?	Record Attribute?	Description
GuidInfoRecord	0030h	No	Yes	During subnet configuration, the SM may assign additional GUIDs to a port. If it does, it creates a GuidInfoRecord for that port and records the GUIDs assigned (up to eight of them) in each of these records. See “GuidInfoRecord” on page 974 for more information.
ClassPortInfo	0001h	Yes	No	See Table 28-7 on page 794. The SA's ClassPortInfo attribute: Indicates whether or not the SA resides at the same location as the SM. If not, it provides the actual location of the SA in its Redirect attribute elements. Indicates the amount of time between the receipt of a request MAD and the transmission of the corresponding response MAD (or between the transmission of MADs in a multi-MAD sequence). See “Software Times Return of MAD Response” on page 781. The SA-specific CapabilityMask bits indicate the following: - Bit 8 is the IsSubnetOptionalRecords Supported bit. If = 1, the SA must support all of the attributes shown as optional in this table (except for MCGroupRecord and MCMemberRecord), and the SubnAdmGetBulk() and SubnAdmGetBulkResp() methods. This bit must not be used to indicate support for only some of those attributes/methods. - Bit 9 is the IsUDMulticastSupported bit. If = 1, the SA supports the MCGroupRecord and MCMemberRecord attributes.
Notice	0002h	Yes	No	When the SA receives a SubnTrap(Report) from a device, it uses the SubnAdmReport(Notice) to deliver the event Notice to the subscriber. For more information, refer to “Event Subscription and Event Forwarding” on page 801.
InformInfo	0003h	Yes	No	See the description of SubnAdmInform(InformInfo) and SubnAdmInformResp(InformInfo) in Table 33-3 on page 925.
NodeRecord	0011h	Yes	Yes	During configuration, the SM creates a NodeRecord entry for each device and records the contents of the device's NodeInfo and NodeDescription attributes in it. See “NodeRecord” on page 962.
PortInfoRecord	0012h	Yes	Yes	During configuration, the SM programs each port's PortInfo attribute and creates a record of each of these attributes in a PortInfoRecord. See “PortInfoRecord” on page 962.
SltoVlMapping TableRecord	0013h	Yes	Yes	The SM programs each port's SLtoVLMappingTable attribute and creates a record of each in a SltoVlMappingTableRecord. See “SLtoVLMappingTableRecord” on page 962.
SwitchRecord	0014h	No	Yes	During configuration, the SM programs each switch's SwitchInfo attribute and creates a record of each of them in a SwitchRecord. See “SwitchRecord” on page 962.
LinearForwardingTableRecord	0015h	No	Yes	During configuration, the SM programs each switch's LinearForwardingTable attribute and creates a record of each of them in a LinearForwardingTableRecord. See “LinearForwardingTableRecord” on page 964.
RandomForwardingTableRecord	0016h	No	Yes	During configuration, the SM programs each switch's RandomForwardingTable attribute and creates a record of each of them in a RandomForwardingTableRecord. See “RandomForwardingTableRecord” on page 964.
MulticastForwardingTableRecord	0017h	No	Yes	During configuration, the SM programs each switch's MulticastForwardingTable attribute and creates a record of each of them in a MulticastForwardingTableRecord. See “MulticastForwardingTableRecord” on page 964.
SMInfoRecord	0018h	No	Yes	During configuration, the Master SM may discover additional SMs in the subnet. It creates a separate SMInfoRecord for each of their SMInfo attributes. See “SMInfoRecord” on page 965.
InformRecord	00F3h	No	Yes	Each time that a subscriber submits a SubnAdmInform(InformInfo) to the SA, the SA creates a copy of the submitted InformInfo attribute in an InformRecord. See “InformRecord” on page 966.
NoticeRecord	00F4h	No	Yes	Each time that the SA receives a SubnTrap(Notice) from a device, it creates a NoticeRecord to contain the Notice attribute that was delivered. Also, each time that the SA performs a SubnGet(Notice) to obtain an event notice from a device that doesn't support traps, it creates a NoticeRecord to contain the Notice attribute obtained. See “NoticeRecord” on page 966.
LinkRecord	0020h	No	Yes	The specification is not very helpful regarding the LinkRecord. It says: “Link records are synthesized by the subnet administration to serve as informational topology data for management entities in need of such data.” See “LinkRecord” on page 967 for a description of this record's content.
ServiceRecord	0031h	Yes	Yes	Service records serve the purpose of first level or “bootstrap” advertisement of basic services that cannot be found prior to query of the SA. See “ServiceRecord” on page 967 for more information.
PartitionRecord	0033h	Yes	Yes	During configuration, the SM programs each port's P_KeyTable attribute and creates a record of each of them in a PartitionRecord. See “PartitionRecord” on page 966.
RangeRecord	0034h	Yes	Yes	Range records specify ranges of LIDs. They exist to allow avoidance of LID conflicts. See “RangeRecord” on page 969 for more information.
PathRecord	0035h	Yes	Yes	The PathRecord is used to request routing information between endnodes to create connections (and, perhaps, for other tasks). For more information, see “PathRecord” on page 975.
VLArbitrationRecord	0036h	Yes	Yes	During configuration, the SM programs each port's VLArbitrationTable attribute and creates a record of each of them in a VLArbitrationRecord. See “VLArbitrationRecord” on page 965.
MCGroupRecord	0037h	No	Yes	To create a multicast group, an entity can use either the SubnAdmConfig() or the optional SubnAdmSet() method to create a MCGroupRecord. See “MCGroupRecord” on page 969 for more information.
MCMemberRecord	0038h	No	Yes	To join a multicast group, an entity can use either the SubnAdmConfig() or the SubnAdmSet() method to create a MCMemberRecord. See “MCMemberRecord” on page 972 for more information.
SAResponse	8001h	No	No	When the SA is requested to supply the entire SA database using the SubnAdmGetBulk() request, the SA responds with a series of SubnAdmGetBulkResp() response MADs. The data field of the first response packet contains the SAResponse attribute that defines the content of the remaining stream of response MADs containing the database. See “SAResponse” on page 974 for more information.

Table 33-5. Method/Attribute Implementation Map

Method ==>	Get	Set	Inform	Report	GetTable	GetBulk
Attribute
ClassPortInfo	x
Notice				x
InformInfo			x
NodeRecord	x				x	x
PortInfoRecord	x				x	x
SLtoVLMappingTableRecord	x				x	x
SwitchRecord	x				x	x
LinearForwardingTableRecord					x	x
RandomForwardingTableRecord					x	x
MulticastForwardingTableRecord					x	x
VLArbitrationRecord					x	x
SMInfoRecord	x				x	x
InformRecord	x	x			x	x
NoticeRecord	x				x	x
LinkRecord	x				x	x
GUIDInfoRecord	x				x	x
ServiceRecord	x	x			x	x
PartitionRecord	x				x	x
RangeRecord	x	x			x	x
PathRecord	x				x
MCGroupRecord	x	x			x	x
MCMemberRecord	x	x			x	x
SAResponse						x

Record Attribute (RA)

Looking at Table 33-4 on page 927, it can be seen that all but four of the SA attributes are referred to as Record Attributes (RAs). The attributes referred to as RAs are all database records rather than actual attributes.

During subnet configuration, the SM accessed and, in many cases, programmed the SM attributes within the various devices in the subnet. In addition, the SM recorded the contents of those attributes in its SA database as records. Most of those attributes referred to as RAs are copies (records) of the actual device attributes. It should be noted, however, that some of the database records are not records of device attribute content. Rather, they are database records containing other useful information.

The four SA attributes that are not referred to as RAs are:

• ClassPortInfo. When read, delivers information about the SA itself.

• Notice. Issued by the SA in a SubnAdmReport(Notice) to deliver an event notification to a subscriber.

• InformInfo. Written to by a subscriber to request event notification.

• SAResponse. Supplied by the SA in the first response MAD during a Subn AdmGetBulkResp(). See “SAResponse” on page 974 for more information.

They are not RAs because they are not database records of device attributes. Rather, they are attributes related to the SA itself.

State and Configuration Records

Refer to Table 33-6 on this page. RAs are referred to as either State or Configuration RAs (it should be noted that some are classified as both State and Configuration RAs). These two classifications are defined in the following two subsections.

State RAs

Most of the RAs are State RAs. These records may queried but may not be edited. The SM may frequently update device attributes.

Configuration RAs

For the most part, those RAs noted as Configuration RAs are created and edited by external management entities (not the SA) via the SubnAdmSet() or Subn AdmConfig() operations. ServiceRecord is an exception in that the SA deletes a ServiceRecord when the service lease expires (see “ServiceRecord” on page 967 for more information).

When an external management entity modifies the SA database in some way, the change may require the SM to perform some device (attribute) reprogramming to reflect the change(s). For example, a change to a RangeRecord may cause the Master SM to update the RangeRecord on standby SMs.

Table 33-6. SA Attribute State versus Configuration Designation

Name	State?	Configuration?
ClassPortInfo	No	No
Notice	No	No
InformInfo	No	No
NodeRecord	Yes	No
PortInfoRecord	Yes	No
SltoVlMappingTableRecord	Yes	No
SwitchRecord	Yes	No
LinearForwardingTableRecord	Yes	No
RandomForwardingTableRecord	Yes	No
MulticastForwardingTableRecord	Yes	No
SMInfoRecord	Yes	No
InformRecord	Yes	Yes
NoticeRecord	Yes	No
LinkRecord	Yes	No
GuidInfoRecord	Yes	No
ServiceRecord	Yes	Yes
PartitionRecord	Yes	No
RangeRecord	Yes	Yes
PathRecord	Yes	No
VLArbitrationRecord	Yes	No
MCGroupRecord	Yes	Yes
MCMemberRecord	Yes	Yes
SAResponse	No	No