IPMB接口的请求和应答协议

l Request / Response Protocol （请求/应答协议）

IPMB使用“请求——应答”协议，发送一条请求消息给一个智能设备，该设备会返回一个独立的应答消息。任何传输协议都是有限制的，IPMB总线直接支持有15个内部节点的系统，系统应用应该努力减轻总线的占用时间，例如，每秒钟少于6条消息，这样做，可以确保节点可以成功在要求的重试次数内抢占总线。

请求消息和应答消息都是通过I2C总线的“主写”（Master Write）模式传输的，也就是说，一条请求消息是从一个作为I2C主端（Master）的节点发出，被一个作为I2C从端（slave）的节点接收；对应的应答消息是从一个作为I2C主端的应答设备（ responding intelligent device）发出，被一个作为I2C从端的请求发起者接收。

请求消息的一个重要性质是要能够指导应答消息能够准确返回给请求者，请求者在请求消息里提供它的Requester‘s Slave Address （rqSA）和Requester’s LUN （rqLUN）来引导应答返回请求者。

每个应答者的接口协议都定义了一些支持的命令字，应答者在这个特定的域位置必须提供至少一个命令字，任何其他和命令域相关的参数字节必须紧跟着第一个字节。应用程序向一个节点发送请求消息，必须能够通过解析命令域来识别应答。

有效的请求是指使用节点支持的命令的cmd号、netFn号和LUN并且能够通过数据完整性计算的请求消息，所有有效请求必须提供相应的应答。对这一要求的例外就是当节点接收到请求时正在处理一个命令，或者在等待另一个节点的应答。这时候节点可以选择用NAK通知请求方，也可以封装一个包含C0h完成码的应答消息来告诉请求方节点忙。

IPMB不要求对消息进行列队处理，也就是说接口是单线的，节点一旦接到某个节点的请求会清除所有等待发送到该节点的应答消息。但是桥节点除外。如果节点接收到请求包的数据checksum不对，将直接丢弃该数据包。

1、如何区分请求消息和应答消息：

请求消息和应答消息的网络功能号（network functions）不同，请求消息使用的是偶数，应答消息用的是奇数的网络功能号。由于有可能同时存在不止一条请求消息，那么区分一个应答消息到底是对应那一个请求就非常重要了。这是通过下列机制来实现的：

1、应答消息中包含Responder’s Slave Address （rsSA） 和 Responder’s LUN （rsLUN），这回告诉请求者（Requester）应答是从哪里来的。

2、请求消息中的命令域（Command （cmd） field）也包含在应答消息里面，这可以让请求者核实应答是针对具体那一个请求的。

3、请求消息中的序列号（Seq）也会包含在应答消息中，这可以使请求者核实应答是针对那一次请求的。

2、丢失应答消息由下面的机制来处理：

1、请求方超时等待应答。

2、请求方重试并超时等待知道超过超时次数限制。

3、请求方可以发送“Get Device ID”命令来看看应答方是否仍在工作，如果有应答，则发送“Warm Reset”命令来将其IPMB通信接口返回到一个可知的状态，如果没有应答，则可以认为应答方已经死掉。

IPMB接口使用序列号域来区分从发的请求消息，但是当请求方重启，就有可能产生和上一次发送的序列号相同的请求消息来，例如序列号刚超界，或者是刚刚只发送了一条消息。为了避免这些，我们使用序列号期满机制，当接收端接收到同一个节点的序列号相同但超过了序列号期满间隔就被看做是一条新的请求消息。

3、 Response Time-outs（应答超时）

请求方不可能认为所有的请求都会有应答，有可能在某种情况下应答方可能不会提供应答消息。这时候，请求方就要实现超时等待机制。

4、 Unexpected Request Messages（不希望的请求消息）

请求消息和应答消息不是自动成对传输的，在一个请求消息和应答消息的间隔，允许其他的总线传输，因此，节点必须容忍意外请求发生。例如，节点A发送请求消息给节点B，A正在等待应答的时候，自己可能会接到来自节点C的请求，节点A有多种方式来处理，第一，节点A可以接受并处理它，这是最可取的方法；如果不可以做到这一点，节点可以选择丢弃这个意外消息。

另外，任何应答消息如果没等待的请求有与之匹配的话，将被丢弃。任何希望得到的应答消息如果corrupted或者不遵从协议的话，也将被丢弃。

l Link Layer Addressing（链路层处理）

1、Connection Header（链路数据头）

这是一种链路层和网络层结合的数据头，成功传输该数据头就会在节点间建立连接，为传输后面的消息主体的字节准备好通路，下图为链路数据头的格式：

链路数据头包含一个7位的从地址，之后的一位是I2C读写位，由于IPMB协议只使用I2C的主写模式，所以这个读写位一直是0。这个字节之后的是网络功能号（）和LUN字节，和一个checksum字节。如果这个checksum不对，节点可以拒绝接收后面的数据。

2、Message Transaction Formats（消息传输格式）

IPMB点对点传输，数据包包含IPMB connection headers、command、和data字节。如下图所示：

3、除此之外，链路层还要处理一下对非智能设备的读写问题。

l Design Objectives（设计目标）

协议的基本设计符合下列目标和原则：

（1）、设计能在处理能力有限和RAM和ROM资源有限的微处理器运行的应用。

（2）、展现高度对称性，例如：对节点的访问方法要和节点的具体应用相独立。

（3）、展现高度的相似性，例如机架寻址自然要和基本的I2C寻址一致。

（4）、桥接功能的处理和存储负担最小化。

（5）、展现清晰的功能层次，例如：消息数据不要差杂有协议数据，不同方面的协议数据也要相应的保持独立。

l Protocol Use of I2C Services（协议对I2C服务的使用）

IPMB总线协议中I2C是用作媒介和物理层的。协议严格按照下列条件使用I2C服务：

1、只使用主写模式（Master Write）（I2C从地址的R/W位一直是0）。

2、不使用10_bit寻址。

3、每次传输只用一个从地址。

4、不使用repeated starts，repeated starts是I2C协议为了在传输的过程中改变总线方向而定义的。由于IPMB协议只用到主写模式，所以就不需要repeated starts 了，不过在非IPMB协议的设备中还是要继续使用repeated starts 的。

5、I2C的通知机制（ACK bit）只表示字节被从端接收，不能保证接收的数据的完整性和正确性。