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）只表示字節被從端接收，不能保證接收的數據的完整性和正確性。