6.9.1 ‘Anonymous Login’ Convention
6.12 BMC Message Bridging
IPMI sequence number are two fields that a shared driver can used to identify and route messages to and from a given application.
• There is a 1:1 relationship between a user name and a session. I.e. different usernames cannot share the same session. However, multiple sessions can be activated using the same username.
• All sessions start off at User Level privilege. It is necessary to issue a Set Session Privilege to raise the operating privilege level before commands that required higher privilege can be executed. The maximum operating privilege for a session is determined by Privilege Limits that are set both for the user and for the overall channel. The more restrictive setting of the User Privilege Limit and the Channel Privilege Limit sets the maximum operating privilege available for a session.
• An Operator can optionally use the Get Channel Info and Get Session Info commands to retrieve the address of parties with open sessions and their present privilege level. This is to allow a remote console to coordinate with another remote console that already has an active session. This can be used to allow software to
coordinate access to the system. For example, one system
• An Administrator can force sessions on any channel to be terminated.
The BMC does not track requests and responses for messages to system software because the Receive Message Queue provides the channel and session information necessary to format the Send Message command to deliver the response. Similarly, system software is capable of tracking the channel and session information it used when generating a request. Thus, the ‘No Tracking’ option is used for Send Message commands from system software.
The responder then delivers its response message to BMC LUN 10b and the response gets routed to the Receive Message Queue. Conversely, if a channel wants to deliver a message to SMS, it sends the request message to BMC LUN 10b, and later SMS uses a Send Message command to return the response from BMC LUN 10b.
6.12.2 Send Message Command From System Interface
The operation of the Send Message command when issued via the System Interface is different than when the Send Message command is issued from other interfaces. This is because the IPMI System Interfaces were specified as always returning an immediate command response. In order to avoid tying up the System Interface waiting for a bridged response, a response to the Send Message command is returned as soon as the request is bridged to the target channel. This response only indicates that the Send Message command was executed. It is not the response to the bridged request.
Later, the response to the bridged request is received by the BMC and routed into the Receive Message Queue and it is retrieved using a Get Message command. For example, here are the typical steps involved in delivering a request from the System Interface to a device on the IPMB, and receiving a corresponding response:
1. System software formats a Send Message request that encapsulates information for the request to be placed on IPMB. The requester’s LUN in the data is set to 10b so when the response comes back, the BMC will place it in the Receive Message Queue. The encapsulated request is also given a sequence number by the system software. System software will use this number later, along with other fields, to match up the Receive Message Queue data with the original request.
2. System software delivers the Send Message request to the BMC via the System Interface.
3. The BMC returns an ‘OK’ response to the Send Message command, indicating that it has received the request and delivered it to the IPMB.
4. Sometime later, the target IPMB device delivers a response to the request. The response is sent back to the same requester’s LUN that was used in the request, 10b. The BMC routes message data received on 10b to the receive message queue, and also tags it with information such as the channel number that the message was received from.
5. System software detects that there is data in the Receive Message Queue. This is either done by polling for messages by periodically checking the SMS_ATN bit, or for interrupt driven implementations, getting an interrupt when SMS_ATN becomes set. Software then uses the Get Message Flags
command to discern whether the SMS_ATN condition was from getting data into the Receive Message Queue or some other event.
6. System software then issues a Get Message request. The response returns a message from the queue. If the data is for a response, software then checks the message fields, such as sequence number, channel number, CMD, etc., to see if the response matches up with an earlier request. In this example, software would be looking for a response to the request it had bridged onto IPMB. If the Receive Message Queue holds a request for system software, it processes it accordingly.
7. If software has not received a response by the timeout intervals specified for IPMB, it can retry the request. Also note that IPMB sequence numbers generally expire after 5 Seconds. This number comes from the sequence number expiration interval on IPMB. Software can generally discard requests that are more than 5 seconds old and re-use their sequence numbers.
If the target channel uses sessions, the Send Message command data will require a Session Handle value to select which session on the channel the message will be sent to. Software can use the Get Channel Info and Get
Channel Sessions commands to determine what channels are present and to obtain the Session Handle for a given session.
6.12.3 Send Message Command with Response Tracking
The Send Message command is used primarily to direct the BMC to act as a proxy that translates a message from one IPMI messaging protocol to another. The BMC formats the data for the target channel type and protocol and delivers it to the selected medium.
Media such as the IPMB do not include channel number and session information as part of their addressing information. As a result, request messages from another channel must be delivered as if they originated from the BMC itself.
If the bridged message is a request, it is necessary for the BMC to hold onto certain data, such as originating channel and session information, so that when the response message comes back it can reformat the response and forward it back to the originator of the request. The primary way the BMC accomplishes this is by assigning a unique sequence number to each request that it generates, and saving a set of information in a ‘Pending Bridged Response’ table that is later used to reformat and route a response back to the originator of the request.
The sequence number returned in the response is then used to look up who generated the original response, plus the saved formatting and addressing information. The BMC then reformats and delivers the response to the original requester and deletes the request from its list of ‘pending responses’. The Send Message command includes a parameter that directs the BMC to save translation information for and track outstanding request messages for the purpose of routing the response back to the originator of the Send Message command.
Note that, with the exception of messages to SMS, when the Send Message command is used to deliver a message to a given medium the message appears to have been originated by the BMC. This means that a controller on the IPMB can’t generically distinguish a bridged request from SMS from a bridged request from LAN.
Table 6-8, Message Bridging Mechanism by Source and Destination
Message Type and direction
Delivery Mechanism
BMC tracks pending responses Request or Response from System Interface to any other channel Send Message no Request or Response to System Interface from any other channel BMC LUN 10b no Request from any channel except System Interface to IPMB Send Message yes Response from IPMB to any channel except System Interface BMC LUN 00b yes Request from any channel (except System Interface) to PCI
Management Bus
Send Message yes Request from PCI Management bus to any channel except System
Interface
BMC LUN 00b yes
Request from Serial to LAN Send Message yes
Response LAN to Serial BMC LUN 00b yes
Request from LAN to Serial Send Message yes
Response from Serial to LAN BMC LUN 00b yes
6.12.4 Bridged Request Example
The example illustrates a Send Message command from LAN being used to deliver a request to IPMB.
Bridged requests to the IPMB can come from several different channels: LAN, serial/modem, and the ICMB.
The BMC uses the sequence number that it places on the bridged request to identify which channel and to which address on that channel the response is to go back to. It is therefore important for the BMC to ensure that unique sequence numbers are used for pending requests from the different channels. It is also important that sequence
IPMB is to track sequence numbers on a per responder basis. This can be kept in a table of ‘Pending Bridged Response’ info.
In order to get the response back to the LAN, the IPMB response must return the same sequence number that was passed in the request. (This is a basic rule of IPMI Messaging, so there’s nothing special about that requirement.) The management controller uses the sequence number to look up the channel type specific addressing, sequence number, and security information that it stored when the request was forwarded. For example, if the channel type is ‘LAN’ then the response message must be formatted up in an RMCP/UDP packet with the IP address of the requester, the sequence number passed in the original request, the appropriate security
‘key’ information, etc.
The following figure and steps present an example high-level design for handling a bridged request. Note that the example shows information that is generated and stored, but it does not show any particular code module that would perform that operation. That is, the choice of which functions are centralized, which are in a ‘LAN’
module, and which are in an ‘IPMB’ module (or whether you even have such modularity) is left to the implementer.
Figure 6-2, LAN to IPMB Bridged Request Example
Chk2 A
RqSeq/
RqLUN LUN=
17h*/ 00b*
Responder's Address (RsA) [BMC]
NetFn/
RsLUN
CMD = Send Message
Sensor Number RqSeq/
RqLUN
Seq # Allocator Ch1
Seq #s Ch 0 (IPMB) Seq #s
Channel
= 0 (IPMB) Chk1
A
Requester's Address
(RqA)
NetFn/RsLUN e.g. S/E, 00b Responder's
Address (RsA) e.g. 24h Session
ID (0047h)
CMD = Get Sensor
Reading
Destination Channel RqSeq#
0017h Source Channel Number
Ch 1 Session
ID Handle
3 AAh
Requester's Address /
SWID Destination
Channel Number
Ch 0 24h
Destination Channel Responder's
Address
500 Seq # Expiration
Chk2 B
Responder's Slave Addr.
(RsSA)
=24h NetFn/
RsLUN
=S/E, 00b
Sensor Number Chk1*
CMD = Get Sensor
Reading Chk2*
Source IP / MAC Address
0047h 2
3 4 ...
Src IP
& MAC Addr
3
1
4
5
Requester's Slave Addr (RqSA)
=20h*
(BMC)
2 LAN REQUEST
Requester's Address
(RqA) Chk1
B
RqSeq/
RqLUN
(RqA) Source Channel RqA
RqSeq/
RqLUN Source Channel RqSeq/
RqLUN
IPMB REQUEST
Get Sensor Reading Source Channel CMD Destination
Channel RsLUN
00b
Encapsulated data for IPMB Request
* BMC S th i d Fi ld
Internally Stored Info for tracking and formatting response back to requester
1. When the BMC receives the Send Message command with the ‘Bridged Request’ parameter bit set, it checks for an available entry in a Pending Bridged Response table and copies parameters from the request to be bridged.
When the response comes back, these parameters will be used to validate that the response matches the earlier request and to reformat the response for the originating channel. The bold outlined boxes represent parameters and data in the Send Message command that will ultimately be copied to the resulting request on the target channel (the IPMB in this example).
2. Any channel session information necessary to get the response back to the original requester will also need to be recorded. In this example, the BMC maintains a separate table of session information for the LAN channel. An offset into that table is used as a ‘handle’ for identifying the session information associated with the request.
This handle is used in the Pending Bridged Response table in lieu of copying all the session information. Note that with such an implementation, it is important to remember details such as invalidating and freeing any bridge table entry associated with that session if the session should get closed while responses are pending.
3. In this example, the BMC has a separate ‘Sequence Number Allocator’ routine that ensures that sequence numbers used in bridged requests are kept unique for a given channel. This is done so when the response comes back, the sequence number can be used to look up the corresponding request info entries from the Pending Bridged Response table.
4. Responses have a five second ‘sequence number expiration’ interval. If a response is not received by the expiration interval, the corresponding entry in the Pending Bridged Response entry is deleted and the sequence number associated with the request can be reused. The Seq # Expiration column in this example represents a possible implementation where the Seq # Expiration value is decremented nominally once every 10 ms. The entry is considered to be free when the number hits 0. Thus, in this example the Seq # Expiration field could be used both for tracking sequence number expiration as well as a mechanism for marking whether a table entry is available or not.
5. The BMC takes the indicated values and uses them to construct the bridged request. The request is a
combination of field values copied from the original Send Message command and values generated by the BMC.