BMC_IPMI_v2.0_会话_桥接_Session

最新推荐文章于 2024-09-23 16:59:13 发布

Init_Xu_Bro

最新推荐文章于 2024-09-23 16:59:13 发布

阅读量846

点赞数 22

文章标签：服务器网络 linux

本文链接：https://blog.csdn.net/2201_75345766/article/details/141068266

版权

十一、System Interface Discovery and Multiple Interfaces系统中接口发现和多接口处理

十二、IPMI Sessions IPMI会话

12.1、 Session-less Connections无会话连接

12.2 Single-session Connections 单会话连接

12.3 Multi-session Connections 多会话连接

12.6 Summary of Connection Characteristics 连接特性总结

12.7 IPMI v1.5 Session Activation and IPMI Challenge-Response v1.5版本中会话激活和IPMI挑战-响应机制

12.8 IPMI v1.5 Session Sequence Numbers v1.5版本中会话序列号

12.9 IPMI v1.5 Session Sequence Number Handling v1.5版本中会话序列号处理

12.10 v1.5综合

12.10.1 IPMI v1.5 入站会话序列号跟踪和处理

12.10.2 IPMI v1.5 乱序数据包处理

12.10.3 IPMI v1.5 出站会话序列号跟踪和处理

12.10.4总结

12.11 IPMI v2.0 RMCP+ Session Sequence Number Handling v2.0 RMCP+（带加号的远程管理控制协议）会话序列号处理

12.12 IPMI v2.0 RMCP+ Sliding Window v2.0 RMCP+（带加号的远程管理控制协议）中滑动窗口机制

12.13 Session Inactivity Timeouts 会话不活动超时

12.14 Avoiding ‘Slot Stealing’避免会话槽盗用

12.15 Additional Session Specifications and Characteristics 会话的附加规范和说明

十三、BMC Message Bridging BMC消息桥接

13.1 BMC LUN 10b Routing BMC LUN（逻辑单元号）10b路由

13.2 Send Message Command From System Interface 通过系统接口发送消息命令

13.3 Send Message Command with Response Tracking 发送消息命令和响应跟踪

13.4 Bridged Request Example 桥接请求示例

十四、Message Size & Private Bus Transaction Size Requirements 不同接口到BMC（和IPMI管理控制器的消息大小和私有总线事务大小要求

十一、System Interface Discovery and Multiple Interfaces系统中接口发现和多接口处理

多系统接口：一个BMC（基板管理控制器）设备可能提供多个系统接口，但只有一个管理控制器可以是“活跃”的，提供系统的BMC功能。在“分区”系统中，每个分区只能有一个活跃的BMC。
响应Get Device ID命令：只有活跃的BMC的系统接口被允许响应“获取设备ID”命令。如果存在其他未使用的BMC设备，它们不应响应此命令。
驱动程序选择接口：当系统接口可用时，驱动程序可以选择它希望使用的接口类型。驱动程序在系统运行期间不应切换系统接口，否则可能会产生意外结果。
命令的一致性：在多个接口到BMC的情况下，“获取设备ID”命令需要正确执行，但其他命令则不一定。一旦驱动程序选择使用某个接口，所有超出“获取设备ID”的命令都应该发送到该接口。
更改接口选择：如果需要更改系统接口的选择，应进行热或冷重置，以确保系统可以重新初始化BMC操作。
运行时驱动程序支持IPMI系统接口的建议顺序：
- PCI上的BMC：如果可用，驱动程序应优先使用通过操作系统本地支持的PCI上的BMC。附录C2 - 在PCI上定位IPMI系统接口，总结了IPMI系统接口的PCI类代码。
- ACPI中的系统接口：如果PCI上没有所需的接口，或者操作系统对PCI的支持不可用，下一步应使用附录C3中描述的ACPI控制方法查找ACPI中描述的系统接口。
- SPMI表：如果操作环境不包括支持执行ACPI控制方法的机制，则应通过ACPI描述表机制查找SPMI（服务处理器管理接口）表中描述的系统接口。附录C2 - 在PCI上定位IPMI系统接口，描述了SPMI表。SPMI表支持提供多个系统接口的BMC，因此可以有多个SPMI表实例。
- SMBIOS类型38表：如果SPMI表不存在，驱动程序应查找SMBIOS类型38表（见附录C1 - 通过SM BIOS表定位IPMI系统接口），并使用那里描述的接口。与SPMI表不同，类型38记录只允许有一个实例，因此驱动程序不需要查找其他接口。
- 固定默认I/O地址：最后，驱动程序应查找SMIC、KCS和BT接口的固定默认I/O地址。有关这些接口的地址，请参阅各个接口的单独部分。
SPMI表的多实例：由于SPMI表支持多个系统接口，因此可能存在多个SPMI表实例。
SMBIOS类型38表的唯一性：与SPMI表不同，SMBIOS类型38记录只允许有一个实例，因此驱动程序不需要查找其他接口。
固定I/O地址：对于SMIC、KCS和BT接口，驱动程序应查找这些接口的固定默认I/O地址。

十二、IPMI Sessions IPMI会话

会话建立：通过建立一个会话来完成对BMC（基板管理控制器）的认证IPMI通信。一旦会话建立，它由一个会话ID标识。
会话ID：会话ID可以被看作是一个句柄，它标识了使用LAN（局域网）或串行/调制解调器连接的特定远程用户与BMC之间的连接。
多会话支持：规范支持与BMC建立多个活跃会话。建议BMC实现至少支持四个同时会话。这个数字在LAN和串行/调制解调器接口之间共享。
LAN上的多会话：规范还允许LAN上的一个给定端点（通过IP地址标识）对BMC打开多个会话。这种能力被允许是为了让一个单一的系统作为代理，为其他系统提供BMC LAN会话。它不是为了让一个系统利用这个规定为该系统单独使用而对BMC打开多个会话。
会话分类：IPMI消息连接到BMC符合以下三种分类之一：
- 无会话（Session-less）：某些IPMI消息不需要建立会话，它们可以在没有会话ID的情况下发送和接收。
- 单会话（Single-session）：某些通信只需要一个会话，一旦会话建立，所有的消息都在这个会话中交换，直到会话结束。
- 多会话（Multi-session）：更复杂的通信可能需要多个并发会话，允许不同的任务或用户同时与BMC交互。
代理使用案例：允许LAN端点打开多个会话的能力，旨在让一个系统能够代表其他系统提供BMC访问，例如在一个大型部署或集群环境中。
资源和安全考虑：虽然支持多会话，但BMC实现需要考虑到资源管理和安全措施，以避免资源耗尽或未授权访问。
实现建议：建议至少支持四个同时会话是一个最佳实践，旨在平衡性能和资源消耗，同时提供足够的并发性以满足大多数使用场景。

12.1、 Session-less Connections无会话连接

1. **无会话连接的定义**：无会话连接是一种未经认证的连接。进行IPMI消息传递时不需要“用户登录”。
2. **无会话连接的例子**：
    - **系统接口**：某些系统接口可能允许无会话连接，这意味着用户可以直接发送和接收消息，而不需要先通过身份验证。
    - **IPMB（智能平台管理总线）**：IPMB是一种内部总线，用于在系统组件之间传输IPMI消息，它也可以支持无会话连接。
3. **会话基础连接的特殊案例**：即使在支持会话基础消息传递的接口上，也可能发生无会话连接的特殊案例。会话基础连接允许某些命令在“会话之外”被接受和响应。
4. **会话之外的命令处理**：
    - 当命令在会话之外发送时，通道在处理这些命令时实际上是以无会话方式操作的。
    - 这些命令在消息中与会话特定的字段有固定值。例如，当“获取通道认证能力”命令通过LAN通道在会话之外发送时，它在IPMI会话头中将Session ID设置为NULL，并将认证类型设置为NONE。
5. **会话头中的字段**：在会话之外处理的命令需要在会话头中具有特定的固定值，以便被接受和处理。
6. **会话内和会话外的命令**：
    - 某些命令不仅可以在会话之外被接受，也可以在会话的上下文中被接受。
    - 如果命令在会话的上下文中被接受，则它们必须在会话头中具有有效的Session ID等信息，才能被接受。
7. **无会话连接的灵活性**：这种机制提供了灵活性，允许某些命令在不需要建立会话的情况下被处理，从而简化了某些操作。
8. **安全性考虑**：尽管无会话连接提供了便利性，但它们不提供与会话基础连接相同的安全级别。因此，通常建议仅在必要时使用无会话连接，并确保适当的安全措施到位。

12.2 Single-session Connections 单会话连接

1. **单会话连接的定义**：*单会话连接在进行IPMI消息传递之前有一个用户认证阶段*。这通过使用“获取会话挑战”（Get Session Challenge）和“激活会话”（Activate Session）命令来完成。
2. **用户认证阶段**：
    - **获取会话挑战**：这是一个IPMI命令，用于开始认证过程。*BMC发送一个随机生成的挑战码给请求者，请求者需要使用这个挑战码来生成一个响应。*
    - **激活会话**：*请求者使用自己的密码和挑战码生成一个响应，并将此响应发送回BMC以完成认证。如果认证成功，会话被激活。*
3. **物理安全链接**：单会话连接适用于物理上安全的链接。这意味着连接是通过一个受信任的、物理上安全的通道进行的，例如直接连接到服务器的控制台端口。
4. **数据包签名**：由于单会话连接适用于物理安全的环境，因此单独的数据包不需要进行数字签名。数字签名通常用于增强安全性，但在物理安全的环境中，这种额外的安全措施可能不是必需的。
5. **串行/调制解调器基本模式**：这是单会话连接的一个例子。在这种模式下，用户通过串行或调制解调器连接到BMC，并通过上述认证过程建立会话。
6. **会话管理**：一旦会话被激活，用户就可以在该会话的上下文中发送和接收IPMI消息，直到会话结束。**会话的结束可以由用户显式地关闭连接，或者由于超时或其他原因自动结束。**
7. **安全性与便利性的平衡**：单会话连接提供了一个简单的认证机制，适用于那些不需要高安全性的场景。它允许用户在不需要为每个单独的数据包进行签名的情况下，通过一个安全的物理连接进行通信。

12.3 Multi-session Connections 多会话连接

1. **多会话连接的定义**：多会话连接不仅包含用户认证阶段，而且还支持多个交织的会话（多个用户）同时进行通信。
2. **共享介质的通信**：多会话连接设计用于支持在共享介质上进行通信，例如LAN（局域网），在这种介质上可能同时存在IPMI和非IPMI流量。
3. **认证保护**：为了支持多个会话并防止绕过认证的尝试（例如重放攻击），多会话数据包除了IPMI消息之外还有一个会话头。会话头携带了识别特定会话的信息，以及其他字段，如会话序列号和认证类型字段。
4. **会话头的作用**：
    - **会话识别**：会话头包含信息以识别消息属于哪个特定的会话。
    - **会话序列号**：用于跟踪消息的顺序，帮助检测和防止重放攻击。
    - **认证类型**：指示用于认证会话的机制。
5. **多会话连接的例子**：
    - **LAN连接**：局域网连接是多会话IPMI消息连接的一个例子，允许多个用户通过同一网络接口与BMC通信。
    - **PPP模式连接**：点对点协议（PPP）模式连接也是支持多会话的IPMI连接的一个例子。
6. **安全性**：多会话连接提供了增强的安全性，通过会话头中的认证和序列号机制，确保通信的安全性和数据的完整性。
7. **灵活性**：多会话连接允许多个用户同时与BMC进行交互，每个用户都有自己的会话，这提供了更高的灵活性和并发性。
8. **适用于复杂环境**：由于多会话连接能够处理多个交织的会话，并且提供了额外的安全措施，因此它适用于可能存在复杂通信需求和安全要求的环境。

### 12.4 Per-Message and User Level Authentication Disables多会话连接的按消息和用户级别认证禁用选项
  1. **多会话连接的认证**：在多会话连接中，除了一些特定的“会前”命令（如“获取通道认证能力”和“获取会话挑战”）之外，每个数据包通常都需要进行认证。
  2. **信任的连接介质**：在某些情况下，即使允许多个用户会话，连接介质也被认为是可信的。在会话激活后，对每个数据包进行认证的计算开销可能并不必要。
  3. **性能改进选项**：在认为连接是安全的环境下，有两种选项可以禁用认证以提高性能：
      - **禁用按消息认证（Per-Message Authentication）**：如果禁用了按消息认证，那么唯一需要认证的数据包就是激活会话请求和响应的数据包。会话激活后，其余数据包将被接受，认证类型设置为NONE。
      - **禁用用户级别认证（User Level Authentication）**：如果禁用了用户级别认证，那么用户级别的消息将被接受，即使认证类型设置为NONE。
  4. **性能提升的方式**：
      - **减少传输字节**：当认证类型为NONE时，数据包中不提供认证代码（签名），这样可以减少传输的字节。
      - **减少认证算法运行**：不需要运行认证算法，从而减少计算开销。
  5. **用户级别命令的认证**：在许多情况下，用户级别的命令是否经过认证并不会引起太多关注，因为用户权限允许检索状态，但不能用来执行如平台重置或更改平台配置等操作。
  6. **BMC对认证数据包的验证**：无论是否禁用了按消息认证或用户级别认证，BMC始终会验证它接收到的任何经过认证的数据包（认证类型不是NONE）。如果签名无效，或者认证类型与激活会话时协商的认证类型不匹配，经过认证的数据包将被静默丢弃。
  7. **远程控制台软件的认证消息传递**：为了允许远程控制台软件通过发送消息命令将认证消息传递到接收消息队列，必须保持对认证数据包的验证。
  8. **配置禁用选项**：按消息认证和用户级别认证的禁用选项都通过“设置通道访问”（Set Channel Access）命令进行配置。

### 12.5 Link Authentication 
  1. **链路认证的定义**：链路认证是在建立与BMC通信链路的过程中应用的认证协议。例如，点对点协议（PPP）支持PAP（密码认证协议）和CHAP（挑战握手认证协议）等作为链路建立的一部分。
  2. **全局特性**：链路认证是与通道的连接模式相关联的全局特性。
  3. **启用与禁用**：链路认证通过串行/调制解调器配置参数来启用或禁用。
  4. **用户识别**：当启用链路认证时，需要确定一个或多个用户，作为链路的用户名（对等ID）和密码信息的来源。这可以通过在“设置通道访问”（Set Channel Access）命令中设置“启用用户进行链路认证”（Enable User for Link Authentication）位来实现。
  5. **物理安全连接**：对于物理上安全的连接，这些“链路认证”协议可能是唯一被认为足够用于认证用户的手段。
  6. **BMC对链路认证的支持**：BMC支持使用常见的PPP认证算法来启用PPP的链路认证。
  7. **性能提升**：如果启用了链路认证，就可能使用“按消息认证禁用”（Per-Message Authentication Disable）和“用户级别认证禁用”（User Level Authentication Disable）选项来提高性能。
  8. **认证方式的结合**：在某些情况下，链路认证可以与IPMI的会话认证结合使用，以提供更强的安全性保障。一旦链路层的认证通过，IPMI层可以利用这一认证结果来简化或禁用后续的认证过程。
  9. **安全性与性能的平衡**：链路认证提供了一种在确保安全性的同时优化性能的方法。在物理连接安全的情况下，可以减少对每个消息的认证需求，从而减少计算开销和数据包大小。

12.6 Summary of Connection Characteristics 连接特性总结

12.7 IPMI v1.5 Session Activation and IPMI Challenge-Response v1.5版本中会话激活和IPMI挑战-响应机制

会话激活的必要性：在进行一般的IPMI消息传递之前，必须先激活会话。对于IPMI v1.5，激活会话的基本机制是通过一组IPMI命令来执行“IPMI挑战-响应”过程。
IPMI v2.0的会话建立机制：IPMI v2.0增加了使用RMCP+（带认证的密钥交换协议，RAKP）作为会话建立机制。更多信息可以参考第13.3节和第13.15节。
IPMI挑战-响应过程：涉及三个IPMI命令：
- 获取通道认证能力（Get Channel Authentication Capabilities）：此命令用于获取BMC支持的认证类型。
- 获取会话挑战（Get Session Challenge）：此命令用于选择BMC支持的认证类型，并获取一个随机生成的挑战字符串。
- 激活会话（Activate Session）：此命令用于通过认证信息激活会话。
命令的执行顺序：
1. 远程控制台向BMC发送“获取通道认证能力请求”。
2. BMC返回“获取通道认证能力响应”，包含它支持的认证类型。
3. 远程控制台发送“获取会话挑战请求”，选择要使用的认证类型和用户名。
4. BMC查找与用户名关联的用户信息，如果用户存在且允许通过给定通道访问，则返回包含随机生成的挑战字符串和临时会话ID的“获取会话挑战响应”。
5. 远程控制台发送“激活会话请求”，包含临时会话ID和基于所选认证类型的认证信息。
6. BMC使用临时会话ID查找用户信息，验证数据包签名或密码是否正确。如果是，BMC返回“激活会话响应”，提供会话ID用于会话的其余部分。
认证信息：在“激活会话请求”中，远程控制台需要提供基于所选认证类型的认证信息。例如，LAN数据包通常包括使用认证算法运行的签名，而串行/调制解调器连接可能只传递简单的明文密码。
会话序列：对于多会话连接，激活会话请求中还会传递BMC发送数据包到远程控制台时使用的起始出站会话序列。同样，激活会话响应中也会传递远程控制台发送数据包到BMC时使用的起始入站会话序列。
会话认证的后续处理：从这一点开始，会话中各个数据包是否需要认证取决于诸如每个用户认证和用户级别认证参数的设置。更多信息可以参考6.12.4节。
图6-1会话激活：提供了一个会话激活的流程图，展示了远程控制台和被管理系统（BMC）之间的交互步骤。

12.8 IPMI v1.5 Session Sequence Numbers v1.5版本中会话序列号

1. **会话序列号的定义**：会话序列号是一个32位的无符号值。
2. **序列号的用途**：
    - 会话序列号不用于匹配IPMI请求和响应。这是由IPMI序列（Seq）字段或特定有效载荷中的类似字段来完成的。
    - 发送者在每次传输数据包时都会递增会话序列号，即使传输的内容的有效载荷是“重试”的请求。
3. **序列号的生成和跟踪**：会话序列号是按会话生成和跟踪的。也就是说，每个会话都有独立的序列号集合和序列号处理方式。
4. **序列号的应用范围**：序列号仅适用于在IPMI会话上下文中传输的数据包。某些IPMI命令和协议消息是在“会话之外”被接受的。
5. **会话外的序列号**：当在会话之外发送这些命令或协议消息时，这些数据包的序列号字段始终设置为0000_0000h。
6. **序列号的独立性**：每个会话的序列号是独立的，这意味着不同会话的序列号不会相互影响，每个会话的序列号从1开始递增，直到达到最大值后再循环。
7. **序列号的重要性**：虽然序列号不用于匹配请求和响应，但它们在会话管理中起着重要作用，特别是在多会话连接中，序列号有助于确保数据包的顺序和完整性。
8. **序列号的递增规则**：发送者必须为每个传输的数据包递增序列号，无论数据包的内容是否为重复的请求。

12.9 IPMI v1.5 Session Sequence Number Handling v1.5版本中会话序列号处理

会话序列号的类型：在IPMI v1.5会话中，有两种会话序列号：入站会话序列号（Inbound Session Sequence Number）和出站会话序列号（Outbound Session Sequence Number）。
方向的定义：入站和出站方向是相对于BMC（基板管理控制器）来定义的。入站消息是从远程控制台到BMC的，而出站消息是从BMC到远程控制台的。
序列号的使用：
- 入站消息使用入站会话序列号。
- 出站消息使用出站会话序列号。
序列号的独立性：入站和出站序列号独立更新和跟踪，并且每个会话都是唯一的。由于进入的数据包和出去的数据包数量通常会有所不同，入站和出站序列号不会始终保持同步。
序列号的起始值选择：BMC和远程控制台独立选择它们接收消息的起始会话序列号。通常，这是通过使用随机数来完成的，以进一步降低重放攻击的可能性。
序列号的设置：
- 远程控制台在发送第一个激活会话（Activate Session）命令时，设置出站会话序列号的起始值。
- 远程控制台必须为它发送给BMC的每个后续消息将入站会话序列号增加一（1）。
激活会话响应：激活会话响应是第一个经过认证的出站（BMC到远程控制台）消息。这个响应消息使用远程控制台在之前的激活会话命令请求中传递的初始出站会话序列号值。
序列号的递增：
- BMC必须为每个后续的出站消息将出站会话序列号增加一（1）。
序列号的重要性：会话序列号的使用有助于维护会话的完整性和安全性，确保数据包的顺序，并降低重放攻击的风险。
序列号的随机起始值：使用随机数作为序列号的起始值是一种安全措施，可以使得会话更难被预测和攻击。

12.10 v1.5综合

12.10.1 IPMI v1.5 入站会话序列号跟踪和处理

序列号递增要求：BMC（基板管理控制器）至少需要跟踪入站序列号是否在递增。
序列号差异处理：
- 如果接收到的序列号与最后一个接收值相差8个计数或更多，BMC应静默丢弃该数据包。
- 实现可以包含一个专有配置选项，允许更大的序列号差异，但必须能够恢复到标准+8的差异。
会话终止选项：如果BMC接收到的序列号与最后一个接收值相差超过8个计数的多个序列号，实现可以选择终止会话。
重复数据包处理：对于具有良好数据完整性检查和签名的有效数据包，如果其入站序列号与早期数据包的序列号相同，则视为重复数据包，并静默丢弃（即使消息内容不同）。

12.10.2 IPMI v1.5 乱序数据包处理

避免会话关闭：为了避免因接收到乱序数据包而关闭会话，BMC必须实现以下两种选项之一：
- 选项1：提前八计数（或更大）窗口（推荐）：
  - 跟踪已接收的序列号，这些序列号比最高接收序列号少8个计数。
  - 同时接受序列号比最后接收序列号大8个计数以内的数据包，并将该序列号设置为接收到的最高序列号的新值。
  - 此选项在附录A - 先前序列号跟踪中进行了说明。
- 选项2：丢弃序列号低于最后有效值的数据包：
  - 此选项比选项1简单，但不推荐使用，除非由于资源限制，因为任何乱序数据包都将要求远程控制台超时并重传。
序列号回绕考虑：对于两种选项，都必须考虑序列号回绕。当序列号从FFFF_FFFFh前进到0000_0000h时，FFFF_FFFFh代表较小的序列号。

12.10.3 IPMI v1.5 出站会话序列号跟踪和处理

远程控制台的责任：远程控制台需要以与BMC处理入站会话序列号相同的方式处理出站会话序列号。
乱序数据包处理：远程控制台不应使用选项2（丢弃序列号低于最后有效值的数据包）作为处理乱序数据包的手段。

12.10.4总结

入站序列号：BMC需要跟踪入站序列号的递增，并在序列号差异过大时丢弃数据包或可能终止会话。
出站序列号：远程控制台需要以类似的方式跟踪出站序列号，但不应使用选项2处理乱序数据包。
乱序数据包：BMC可以通过提前八计数窗口或丢弃低于最后有效值的序列号数据包来处理乱序数据包，但前者更推荐使用。

12.11 IPMI v2.0 RMCP+ Session Sequence Number Handling v2.0 RMCP+（带加号的远程管理控制协议）会话序列号处理

会话序列号的两组：在IPMI v2.0 RMCP+会话中，对于给定的会话，有两组会话序列号。一组用于认证（签名）的数据包，另一组用于未经认证的数据包。
序列号的独立更新和跟踪：认证数据包的入站和出站序列号独立于未经认证数据包的入站和出站序列号进行更新和跟踪。
序列号的用途：IPMI v2.0 RMCP+会话序列号用于拒绝可能被网络复制或故意重放的数据包。
序列号的初始化和递增：
- 每个会话的序列号在会话创建时初始化为零，并在出站处理每个数据包的开始时递增一。
- 也就是说，第一个传输的数据包的序列号是“1”，而不是0。
序列号递增规则：无论数据包的有效载荷是“重试”还是新内容，发送方传输的每个数据包都会使序列号递增。
序列号违规处理：在基于序列号丢弃数据包时，任何具有非法、重复或超出范围序列号的数据包都可以在不必首先验证数据包完整性数据（AuthCode）签名的情况下被丢弃。
数据包接受流程：在接受数据包时，BMC（基板管理控制器）必须在接收数据包序列号之前应用任何数据包完整性和认证代码检查。
安全性和完整性：序列号机制有助于确保数据包的顺序和完整性，防止未经授权的重放攻击，并提高网络通信的安全性。
序列号的独立性：由于认证和未经认证的数据包使用不同的序列号集合，这允许BMC更细致地控制和管理不同类型的数据包流。

12.12 IPMI v2.0 RMCP+ Sliding Window v2.0 RMCP+（带加号的远程管理控制协议）中滑动窗口机制

滑动窗口机制：IPMI v2.0 RMCP+ 使用“滑动窗口”来跟踪接收到的数据包的序列号。这种机制用于拒绝那些序列号与最近接受的数据包的序列号明显不符的数据包，同时允许一定数量的乱序数据包被接受。
滑动窗口的大小：滑动窗口的大小为32计数。这意味着，如果数据包的序列号在最近接受的最高序列号的+15或-16计数范围内，这些数据包将被接受。
序列号的接受条件：
- 数据包的序列号必须在滑动窗口内，即在最近接受的最高序列号的+15计数范围内。
- 数据包的序列号必须不在滑动窗口的-16计数范围内，即不比最近接受的最高序列号低16个计数。
- 数据包的序列号不能是之前已经接收过的重复序列号。
拒绝明显乱序的数据包：滑动窗口机制有助于拒绝那些序列号明显超出预期范围的数据包，这可能是由于网络错误或重放攻击引起的。
允许一定数量的乱序数据包：通过设置滑动窗口，系统可以容忍一定程度的乱序，允许一些序列号稍低或稍高的数据包被接受，从而提高通信的灵活性和鲁棒性。
序列号的递增：每当BMC接受一个数据包时，滑动窗口的最高序列号将更新为该数据包的序列号，窗口随之滑动。
数据包的重复检测：除了序列号的顺序外，系统还需要检查数据包是否为重复数据包。如果数据包的序列号与之前接收过的序列号相同，即使序列号在滑动窗口内，该数据包也会被静默丢弃。

12.13 Session Inactivity Timeouts 会话不活动超时

会话自动关闭：如果在指定的时间间隔内没有收到新的有效消息，会话将自动关闭。要恢复会话，必须重新进行身份验证。
保持会话开启：远程控制台可以选择使用“激活会话”命令在不活动期间保持会话开启。
防止无限期保持连接：为了防止有人尝试猜测不同的密码来激活会话而无限期地保持电话连接，只有活动会话才能阻止会话不活动超时到期。
BMC监控不活动：BMC仅在连接切换到BMC时监控不活动。关闭会话并不总是等同于挂断调制解调器连接。
串行/调制解调器会话：串行/调制解调器会话在连接切换到系统时也会自动关闭，但电话连接仍然保持活跃。只有当串行连接路由到BMC时，由于不活动超时而关闭会话，BMC才会终止电话连接。
超时和容差值：超时和容差值由管理控制器（BMC）指定，BMC将超时并关闭会话。系统软件应该考虑这个容差，以及由于媒体传输时间等引起的任何额外延迟。
配置参数：实现可以提供一个选项，允许通过给定通道类型的配置参数中的参数来配置超时。
默认会话不活动超时间隔：表格提供了不同会话类型的默认超时间隔和容差值：
- LAN：60秒，容差±3秒
- 直接连接模式串行：60秒，容差±3秒
- 调制解调器模式串行：60秒，容差±3秒
- 不活动超时间隔在与BMC建立连接或切换到BMC时开始。如果串行连接路由到BMC时发生不活动超时，则会终止电话连接。
配置超时：实现可以允许通过配置参数来配置超时，以便根据特定需求调整超时设置。

12.14 Avoiding ‘Slot Stealing’避免会话槽盗用

会话槽盗用问题：如果有人意外或恶意地“认领”了所有的会话槽，可能会导致锁定对BMC（基板管理控制器）的访问。例如，一个出错的程序可能不断重复发送“获取会话挑战”（Get Session Challenge）命令，而没有成功激活会话，导致用于跟踪待处理会话的所有可用资源被耗尽。
推荐机制：强烈建议实现一种机制来保护会话槽，防止上述情况发生。
可能的解决方案：一种可能的解决方案是使用LRU（最近最少使用）算法，该算法会丢弃最旧的有待处理“激活会话”（Activate Session）的会话ID。这样，唯一能够“永久”占用槽位的方法是通过激活并维护所有会话槽的会话。
LRU算法的作用：LRU算法确保最长时间未使用的会话ID被丢弃，从而为新会话腾出空间。这可以防止恶意软件或错误程序通过不断请求会话挑战而不完成会话激活来耗尽所有会话槽。
微小改进：对LRU算法的一个微小改进可能是在返回“获取会话挑战”命令的响应时引入几秒钟的延迟。这为表现良好的应用程序提供了机会，在出错软件再次发出另一个“获取会话挑战”之前，获取挑战并返回“激活会话”命令。
改进的目标：这种改进主要针对那些在再次发出请求之前等待“获取会话挑战”响应的出错应用程序。通过引入延迟，可以减少这类应用程序对会话槽的不必要占用。
安全性和资源管理：通过这些措施，可以提高系统的安全性，并有效管理会话资源，防止资源被滥用或耗尽，确保BMC可以被合法用户正常访问。

12.15 Additional Session Specifications and Characteristics 会话的附加规范和说明

同时会话支持：
- 至少应在给定通道上支持四个同时会话。
会话自动关闭：
- 默认情况下，如果在会话不活动超时间隔内没有检测到有效活动，或者连接或链路被终止，则会话将自动关闭。
- 有效活动定义为在连接路由到BMC时，接收到该会话的有效IPMI消息。
待处理桥接请求：
- 对于每个需要BMC跟踪待处理响应的桥接接口，至少应支持四个待处理桥接请求。
同时打开会话数量：
- 典型的BMC预期只允许少量同时打开的会话（大约四到八个）。因此，远程控制台应用程序应尽可能避免激活多个会话，以便其他远程控制台也能获得访问。
激活会话命令：
- 激活会话命令将返回一个完成代码，指示请求是否因BMC当前忙于其他打开的会话而被拒绝。
单IP地址的多个会话：
- 规范允许从单个IP地址激活多个会话。允许多个会话的主要原因是允许系统充当代理代理，为连接到它的远程控制台提供BMC访问，而不是直接连接到BMC。
多个应用程序的访问：
- 多个会话不应用于支持IP地址背后的多个应用程序的访问。如果多个应用程序需要访问给定系统上的BMC，一个单一的驱动程序或“中间件”应协调该访问，并尽可能使用单个会话。IPMI软件ID和IPMI序列号是共享驱动程序可以用来识别和路由消息到给定应用程序的两个字段。
用户名与会话的关系：
- 用户名和会话之间有1:1的关系。即不同的用户名不能共享同一个会话。然而，可以使用相同的用户名激活多个会话。
会话权限级别：
- 所有会话从用户级别权限开始。在执行需要更高权限的命令之前，需要发出设置会话权限命令以提高操作权限级别。会话的最大操作权限由用户和整个通道设置的权限限制确定。用户权限限制和通道权限限制中的较严格设置确定了会话可用的最大操作权限。
获取通道信息和会话信息：
- 操作员可以选择使用获取通道信息和获取会话信息命令检索具有打开会话的方的地址及其当前权限级别。这允许一个远程控制台与已经拥有活动会话的另一个远程控制台协调。这可以用来允许软件协调对系统的访问。例如，如果在控制台“A”上运行的管理软件希望远程重置给定系统，它可以先查看另一个控制台是否具有要重置的系统的活动会话。然后，它可以使用获取通道信息和获取会话信息命令中的信息，直接向另一个控制台发送消息，通知其待处理的重置。
管理员强制终止会话：
- 管理员可以强制终止任何通道上的会话。

十三、BMC Message Bridging BMC消息桥接

消息桥接机制*：BMC消息桥接提供了一种在不同媒体之间路由IPMI消息的机制****。桥接仅指定用于在不同通道之间传递消息，而不是用于在同一通道上的两个会话之间传递消息。***
IPMI 1.0和1.5的桥接*：*
- 在IPMI 1.0中，桥接主要指定用于提供系统接口（SMS）和IPMB（智能平台管理总线）之间的访问。
- 在IPMI 1.5中，这些机制已经扩展，以支持在连接到BMC的任何IPMI消息媒体上激活连接/会话之间的IPMI消息传递。
桥接消息的三种机制*：根据消息的目标，有三种机制用于将消息桥接到连接到BMC的不同媒体：*
- BMC LUN 10b*：*用于将消息传递到系统接口。BMC自动将通过LUN 10b接收到的任何消息路由到接收消息队列。
- 系统接口的发送消息命令*：*用于将消息传递到其他通道，如IPMB。消息在通道上显示，就像它们来自BMC LUN 10b一样。因此，如果消息是请求消息，响应将发送到BMC LUN 10b，BMC将自动将响应放入接收消息队列中以供检索。系统软件负责将响应与原始请求匹配，因此使用发送消息命令中的“无跟踪”设置。
- 带响应跟踪的发送消息命令*：这种格式的发送消息命令用于桥接请求消息到除系统接口是源或目的地之外的所有其他通道的响应跟踪。*
消息桥接的操作和使用*：*
- 后续部分将提供有关这些桥接机制的操作和使用的额外信息。
系统软件的责任*：系统软件需要匹配响应与原始请求，这通常通过在发送消息命令中使用“无跟踪”设置来实现。*
消息路由的自动化*：BMC负责自动路由消息到正确的接收队列或通道，确保消息能够在不同的IPMI消息媒体之间正确传递。*

13.1 BMC LUN 10b Routing BMC LUN（逻辑单元号）10b路由

BMC LUN 10b的特殊用途：由于发送到SMS（系统管理软件）的消息总是被路由到接收消息队列，通常不使用发送消息命令来向SMS发送消息。相反，SMS的消息通过BMC SMS LUN 10b传递。
自动重格式化和路由：BMC自动将任何地址为LUN 10b的消息重新格式化，并将其放入接收消息队列，供SMS使用获取消息命令检索。
发送请求到SMS：向SMS发送请求只需要将命令格式化，使其地址为BMC LUN 10b。SMS可以从接收消息队列中检索请求，提取发送者的地址和通道信息，然后使用发送消息命令来传递响应。
BMC不跟踪请求和响应：BMC不为发送到系统软件的消息跟踪请求和响应，因为接收消息队列提供了格式化发送消息命令以传递响应所需的通道和会话信息。同样，系统软件能够跟踪它在生成请求时使用的通道和会话信息。
“无跟踪”选项的使用：由于系统软件能够处理通道和会话信息，因此在系统软件的发送消息命令中使用“无跟踪”选项。
响应消息的传递：响应者将其响应消息传递到BMC LUN 10b，然后响应被路由到接收消息队列。相反，如果一个通道想要向SMS传递消息，它将请求消息发送到BMC LUN 10b，之后SMS使用发送消息命令从BMC LUN 10b返回响应。
简化的消息传递流程：这种机制简化了消息传递流程，因为BMC处理了消息的路由和重格式化，而SMS只需要从接收消息队列中检索消息，并使用发送消息命令返回响应。
消息传递的自动化：BMC的自动化消息处理确保了消息能够在不同的通道和SMS之间正确传递，减少了手动干预的需要。

13.2 Send Message Command From System Interface 通过系统接口发送消息命令

系统接口的特殊性：当通过系统接口发出发送消息命令时，其操作与其他接口发出该命令时不同。这是因为IPMI系统接口总是被指定为立即返回命令响应。
避免等待桥接响应：为了避免系统接口因等待桥接响应而被占用，发送消息命令的响应会在请求被桥接到目标通道后立即返回。这个响应仅表明发送消息命令已被执行，而不是桥接请求的响应。
桥接请求的响应获取：桥接请求的响应后来由BMC接收，并被路由到接收消息队列，然后使用获取消息命令检索。
向IPMB设备发送请求的步骤：
- 系统软件格式化一个发送消息请求，该请求封装了要放置在IPMB上的信息。请求者LUN设置为10b，以便响应返回时，BMC将其放入接收消息队列。
- 系统软件将封装的请求赋予一个序列号，稍后将使用此序列号和其他字段来匹配接收消息队列数据与原始请求。
- 系统软件通过系统接口将发送消息请求传递给BMC。
- BMC返回发送消息命令的“OK”响应，表明它已接收请求并将其传递到IPMB。
- 稍后，目标IPMB设备对请求作出响应。响应被发送回请求中使用的同一个请求者LUN，即10b。BMC将接收到的10b上的消息数据路由到接收消息队列，并标记有诸如接收消息的通道号等信息。
- 系统软件检测到接收消息队列中有数据，这可以通过轮询消息或在SMS_ATN位被设置时触发中断来完成。然后软件使用获取消息标志命令来判断SMS_ATN条件是由接收消息队列中的数据引起还是其他事件。
- 系统软件随后发出获取消息请求。响应返回队列中的消息。如果是响应数据，软件会检查消息字段（如序列号、通道号、命令等），以查看响应是否与早期请求匹配。在这个例子中，软件将寻找它已桥接到IPMB的请求的响应。如果接收消息队列包含针对系统软件的请求，软件将相应地处理它。
- 如果软件在IPMB指定的超时间隔内未收到响应，它可以重试请求。注意，IPMB序列号通常在5秒后过期。这个数字来自IPMB上的序列号过期间隔。软件通常可以丢弃超过5秒的请求，并重用它们的序列号。
会话的使用：如果目标通道使用会话，发送消息命令数据将需要一个会话句柄值来选择通道上的哪个会话将发送消息。软件可以使用获取通道信息和获取会话信息命令来确定存在的通道，并获取给定会话的会话句柄。
消息匹配：系统软件负责匹配发送和接收的消息，确保响应与请求相对应。
超时和重试机制：如果未在指定的超时间隔内收到响应，系统软件可以重新发送请求，并注意序列号的过期机制。

13.3 Send Message Command with Response Tracking 发送消息命令和响应跟踪

发送消息命令的用途：发送消息命令主要用于指导BMC（基板管理控制器）充当代理，将消息从一种IPMI消息协议转换为另一种。
BMC的代理作用：BMC负责为目标通道类型和协议格式化数据，并将消息传递到选定的介质。
不同媒体的地址信息：某些媒体（如IPMB，智能平台管理总线）在其地址信息中不包括通道号和会话信息。因此，来自另一通道的请求消息必须作为似乎源自BMC本身来传递。
请求消息的桥接：如果桥接的消息是一个请求，BMC需要保留某些数据，如原始通道和会话信息，以便当响应消息返回时，它可以重新格式化响应，并将响应转发回请求的发起者。
序列号和挂起响应表：BMC通过为每个生成的请求分配一个唯一的序列号，并在“挂起桥接响应”表中保存一组信息来实现这一点。这些信息稍后用于重新格式化并路由响应回请求的发起者。
响应的查找和转发：返回的序列号用于查找谁生成了原始响应，以及保存的格式化和寻址信息。然后，BMC重新格式化并交付响应给原始请求者，并从其“挂起响应”列表中删除请求。
发送消息命令的参数：发送消息命令包括一个参数，指导BMC保存翻译信息，并跟踪未完成的请求消息，以便将响应路由回发送消息命令的发起者。
消息来源的区分：除了向SMS（系统管理软件）发送消息外，当使用发送消息命令向给定介质传递消息时，该消息看起来是由BMC发起的。这意味着IPMB上的控制器不能通用地区分来自SMS的桥接请求和来自LAN（局域网）的桥接请求。
消息桥接机制表：表格提供了基于消息来源和目的地的消息桥接机制的概述，包括BMC是否跟踪挂起的响应。
不同通道间的消息传递：表格中列出了不同通道间请求或响应的消息传递机制，以及BMC是否跟踪这些消息。

13.4 Bridged Request Example 桥接请求示例

桥接请求来源：可以来自LAN、串行/调制解调器和ICMB（智能机箱管理总线）等多个不同通道的桥接请求。
序列号的重要性：BMC使用它放置在桥接请求上的序列号来识别哪个通道以及该通道上的哪个地址应对响应消息。因此，BMC需要确保为来自不同通道的待处理请求使用唯一的序列号，并且对于给定响应者的连续请求，序列号也应该是唯一的。
管理序列号：一种管理IPMB序列号的方法是按响应者分别跟踪序列号，这可以保存在“挂起桥接响应”信息表中。
响应返回：为了将响应返回给LAN，IPMB响应必须返回与请求中传递的相同的序列号。这是IPMI消息传递的基本规则。
响应消息的格式化：管理控制器使用序列号查找存储在转发请求时的特定通道类型的地址、序列号和安全信息。例如，如果通道类型是“LAN”，那么响应消息必须使用请求者的IP地址、原始请求中传递的序列号、适当的安全“密钥”信息等，格式化为RMCP/UDP数据包。
发送消息命令的响应：当通过发送消息命令（来自系统接口之外的源通道）桥接请求消息到另一个通道时，BMC会立即返回发送消息命令本身的响应。与此同时，请求从发送消息命令中提取出来，并转发到指定的目标通道。
跟踪数据：发送消息命令必须配置为指导BMC跟踪请求中的数据，以便当来自目标设备的响应返回时，BMC能够将响应回传到传递原始发送消息命令到BMC的通道。
响应格式化：当目标的响应返回时，BMC使用跟踪信息为给定通道格式化响应。对于发起发送消息命令的方来说，响应将显示为如果由BMC直接执行封装请求一样，即它将看起来像是一个异步生成的响应消息。
示例场景：假设已经将获取设备ID命令封装在发送消息命令中，从LAN通道定向到IPMB。BMC将立即通过LAN发送发送消息命令的响应。BMC将提取封装的获取设备ID消息内容，并将其格式化为IPMB的获取设备ID请求。IPMB上的目标设备以IPMB格式的获取设备ID响应消息响应。BMC利用在发出发送消息命令时存储的跟踪信息，并使用它来创建LAN格式的获取设备ID响应。
响应地址信息：响应中的响应者地址信息可以是BMC的地址，也可以是IPMB上目标请求的设备的地址，具体取决于BMC实现的选择。
桥接请求处理的高级设计示例：以下图示和步骤展示了处理桥接请求的高级设计示例。示例显示了生成和存储的信息，但没有显示执行该操作的特定代码模块。
挂起桥接响应表：当BMC接收到带有“桥接请求”参数位设置的发送消息命令时，它检查挂起桥接响应表中的可用条目，并将请求桥接的参数复制到其中。当响应返回时，这些参数将用于验证响应是否与早期请求匹配，并为原始通道重新格式化响应。
会话信息记录：任何必要的通道会话信息也需要被记录，以便将响应返回给原始请求者。在本例中，BMC为LAN通道维护一个单独的会话信息表。该表的偏移量用作标识与请求相关联的会话信息的“句柄”。
序列号分配器：BMC有一个单独的“序列号分配器”例程，确保在桥接请求中使用的序列号对于给定通道保持唯一。
序列号过期间隔：响应有一个五秒的“序列号过期”间隔。如果在过期间隔内未收到响应，挂起桥接响应表中的相应条目将被删除，与请求关联的序列号可以被重用。
构造桥接请求：BMC采用指示值构造桥接请求。该请求是原始发送消息命令中复制的字段值和BMC生成的值的组合。

十四、Message Size & Private Bus Transaction Size Requirements 不同接口到BMC（和IPMI管理控制器的消息大小和私有总线事务大小要求

消息大小和事务大小要求：表格总结了到BMC和IPMI管理控制器的各种接口的消息大小和事务大小要求。IPMI消息大小包括接口所需的任何IPMI级地址和数据完整性信息。
IPMB消息长度：IPMB消息长度包括请求者和响应者地址信息、序列号和校验和。消息大小不包括用于在给定媒体上传输IPMI消息的额外封装、数据转义或框架。
非桥接消息的最大长度：IPMB标准非桥接消息的最大消息长度规定为32字节，包括从机地址。这为典型的IPMI消息设定了上限。
桥接消息的例外：为了支持桥接，主读写（Master Write-Read）和发送消息（Send Message）命令允许超过IPMB上的32字节最大事务。
KCS/SMIC接口：
- 输入要求：至少需要40字节的IPMI消息。
- 输出要求：至少需要38字节的IPMI消息。
BT接口：
- 输入要求：至少需要42字节的IPMI消息（包括BT接口的“长度”字节）。BT接口除了KCS和SMIC接口使用的字段外，还有长度和序列号字段，这增加了消息大小支持要求的两个字节。
- 输出要求：至少需要40字节的IPMI消息（包括BT接口的“长度”字节）。
IPMB接口：
- 输入要求：至少需要32字节的IPMI消息（包括从机地址）。
- 推荐：至少36字节的总线事务（包括从机地址），以支持OEM选项，允许BMC成为SMBus 2.0块写入带PEC协议的目标。
- 输出要求：至少需要36字节的总线事务（包括从机地址），以允许BMC能够访问使用SMBus 2.0块写入带PEC协议的从设备。
SMBus 2.0接口：
- 输入要求：至少需要36字节的总线事务（包括从机地址），以允许BMC成为SMBus 2.0块写入带PEC协议的目标。
- 输出要求：至少需要36字节（包括从机地址），以允许BMC生成SMBus 2.0块写入带PEC协议的事务。
私有总线：
- 输入推荐：如果私有总线实现为物理I2C或SMBus，至少需要34字节的总线事务。这支持访问使用SMBus 2.0块读取协议的从设备（此计数不包括任何从机地址，因为对于此类事务，从机地址是由管理控制器输出的，而不是输入到管理控制器的）。
- 输出要求：23字节。仅当控制器指示它有一个私有总线，其中包括通过主读写命令可访问的FRU SEEPROM时，才需要此要求。必须支持等同于作为32字节IPMB消息传递的最大主读写命令的主读写命令。
LAN/PPP接口：
- 输入要求：至少需要45字节的IPMI消息内容。IPMI LAN和PPP接口必须接受包含IPMI消息的RMCP数据包，允许远程控制台提交主读写消息以执行SMBus 2.0块写入协议事务。
- 输出要求：至少需要42字节的IPMI消息内容。IPMI LAN和PPP接口必须支持传递包含IPMI消息的RMCP数据包，允许BMC返回主读写消息的响应，该消息返回来自SMBus 2.0块读取协议事务的数据。