IPMB接口的請求和應(yīng)答協(xié)議

l Request / Response Protocol （請求/應(yīng)答協(xié)議）

IPMB使用“請求——應(yīng)答”協(xié)議，發(fā)送一條請求消息給一個智能設(shè)備，該設(shè)備會返回一個獨立的應(yīng)答消息。任何傳輸協(xié)議都是有限制的，IPMB總線直接支持有15個內(nèi)部節(jié)點的系統(tǒng)，系統(tǒng)應(yīng)用應(yīng)該努力減輕總線的占用時間，例如，每秒鐘少于6條消息，這樣做，可以確保節(jié)點可以成功在要求的重試次數(shù)內(nèi)搶占總線。

請求消息和應(yīng)答消息都是通過I2C總線的“主寫”（Master Write）模式傳輸?shù)?，也就是說，一條請求消息是從一個作為I2C主端（Master）的節(jié)點發(fā)出，被一個作為I2C從端（slave）的節(jié)點接收；對應(yīng)的應(yīng)答消息是從一個作為I2C主端的應(yīng)答設(shè)備（ responding intelligent device）發(fā)出，被一個作為I2C從端的請求發(fā)起者接收。

請求消息的一個重要性質(zhì)是要能夠指導(dǎo)應(yīng)答消息能夠準確返回給請求者，請求者在請求消息里提供它的Requester‘s Slave Address （rqSA）和Requester’s LUN （rqLUN）來引導(dǎo)應(yīng)答返回請求者。

每個應(yīng)答者的接口協(xié)議都定義了一些支持的命令字，應(yīng)答者在這個特定的域位置必須提供至少一個命令字，任何其他和命令域相關(guān)的參數(shù)字節(jié)必須緊跟著第一個字節(jié)。應(yīng)用程序向一個節(jié)點發(fā)送請求消息，必須能夠通過解析命令域來識別應(yīng)答。

有效的請求是指使用節(jié)點支持的命令的cmd號、netFn號和LUN并且能夠通過數(shù)據(jù)完整性計算的請求消息，所有有效請求必須提供相應(yīng)的應(yīng)答。對這一要求的例外就是當節(jié)點接收到請求時正在處理一個命令，或者在等待另一個節(jié)點的應(yīng)答。這時候節(jié)點可以選擇用NAK通知請求方，也可以封裝一個包含C0h完成碼的應(yīng)答消息來告訴請求方節(jié)點忙。

IPMB不要求對消息進行列隊處理，也就是說接口是單線的，節(jié)點一旦接到某個節(jié)點的請求會清除所有等待發(fā)送到該節(jié)點的應(yīng)答消息。但是橋節(jié)點除外。如果節(jié)點接收到請求包的數(shù)據(jù)checksum不對，將直接丟棄該數(shù)據(jù)包。

1、如何區(qū)分請求消息和應(yīng)答消息：

請求消息和應(yīng)答消息的網(wǎng)絡(luò)功能號（network functions）不同，請求消息使用的是偶數(shù)，應(yīng)答消息用的是奇數(shù)的網(wǎng)絡(luò)功能號。由于有可能同時存在不止一條請求消息，那么區(qū)分一個應(yīng)答消息到底是對應(yīng)那一個請求就非常重要了。這是通過下列機制來實現(xiàn)的：

1、應(yīng)答消息中包含Responder’s Slave Address （rsSA） 和 Responder’s LUN （rsLUN），這回告訴請求者（Requester）應(yīng)答是從哪里來的。

2、請求消息中的命令域（Command （cmd） field）也包含在應(yīng)答消息里面，這可以讓請求者核實應(yīng)答是針對具體那一個請求的。

3、請求消息中的序列號（Seq）也會包含在應(yīng)答消息中，這可以使請求者核實應(yīng)答是針對那一次請求的。

2、丟失應(yīng)答消息由下面的機制來處理：

1、請求方超時等待應(yīng)答。

2、請求方重試并超時等待知道超過超時次數(shù)限制。

3、請求方可以發(fā)送“Get Device ID”命令來看看應(yīng)答方是否仍在工作，如果有應(yīng)答，則發(fā)送“Warm Reset”命令來將其IPMB通信接口返回到一個可知的狀態(tài)，如果沒有應(yīng)答，則可以認為應(yīng)答方已經(jīng)死掉。

IPMB接口使用序列號域來區(qū)分從發(fā)的請求消息，但是當請求方重啟，就有可能產(chǎn)生和上一次發(fā)送的序列號相同的請求消息來，例如序列號剛超界，或者是剛剛只發(fā)送了一條消息。為了避免這些，我們使用序列號期滿機制，當接收端接收到同一個節(jié)點的序列號相同但超過了序列號期滿間隔就被看做是一條新的請求消息。

3、 Response Time-outs（應(yīng)答超時）

請求方不可能認為所有的請求都會有應(yīng)答，有可能在某種情況下應(yīng)答方可能不會提供應(yīng)答消息。這時候，請求方就要實現(xiàn)超時等待機制。

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

請求消息和應(yīng)答消息不是自動成對傳輸?shù)?，在一個請求消息和應(yīng)答消息的間隔，允許其他的總線傳輸，因此，節(jié)點必須容忍意外請求發(fā)生。例如，節(jié)點A發(fā)送請求消息給節(jié)點B，A正在等待應(yīng)答的時候，自己可能會接到來自節(jié)點C的請求，節(jié)點A有多種方式來處理，第一，節(jié)點A可以接受并處理它，這是最可取的方法；如果不可以做到這一點，節(jié)點可以選擇丟棄這個意外消息。

另外，任何應(yīng)答消息如果沒等待的請求有與之匹配的話，將被丟棄。任何希望得到的應(yīng)答消息如果corrupted或者不遵從協(xié)議的話，也將被丟棄。

l Link Layer Addressing（鏈路層處理）

1、Connection Header（鏈路數(shù)據(jù)頭）

這是一種鏈路層和網(wǎng)絡(luò)層結(jié)合的數(shù)據(jù)頭，成功傳輸該數(shù)據(jù)頭就會在節(jié)點間建立連接，為傳輸后面的消息主體的字節(jié)準備好通路，下圖為鏈路數(shù)據(jù)頭的格式：

鏈路數(shù)據(jù)頭包含一個7位的從地址，之后的一位是I2C讀寫位，由于IPMB協(xié)議只使用I2C的主寫模式，所以這個讀寫位一直是0。這個字節(jié)之后的是網(wǎng)絡(luò)功能號（）和LUN字節(jié)，和一個checksum字節(jié)。如果這個checksum不對，節(jié)點可以拒絕接收后面的數(shù)據(jù)。

2、Message Transaction Formats（消息傳輸格式）

IPMB點對點傳輸，數(shù)據(jù)包包含IPMB connection headers、command、和data字節(jié)。如下圖所示：

3、除此之外，鏈路層還要處理一下對非智能設(shè)備的讀寫問題。

l Design Objectives（設(shè)計目標）

協(xié)議的基本設(shè)計符合下列目標和原則：

（1）、設(shè)計能在處理能力有限和RAM和ROM資源有限的微處理器運行的應(yīng)用。

（2）、展現(xiàn)高度對稱性，例如：對節(jié)點的訪問方法要和節(jié)點的具體應(yīng)用相獨立。

（3）、展現(xiàn)高度的相似性，例如機架尋址自然要和基本的I2C尋址一致。

（4）、橋接功能的處理和存儲負擔最小化。

（5）、展現(xiàn)清晰的功能層次，例如：消息數(shù)據(jù)不要差雜有協(xié)議數(shù)據(jù)，不同方面的協(xié)議數(shù)據(jù)也要相應(yīng)的保持獨立。

l Protocol Use of I2C Services（協(xié)議對I2C服務(wù)的使用）

IPMB總線協(xié)議中I2C是用作媒介和物理層的。協(xié)議嚴格按照下列條件使用I2C服務(wù)：

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

2、不使用10_bit尋址。

3、每次傳輸只用一個從地址。

4、不使用repeated starts，repeated starts是I2C協(xié)議為了在傳輸?shù)倪^程中改變總線方向而定義的。由于IPMB協(xié)議只用到主寫模式，所以就不需要repeated starts 了，不過在非IPMB協(xié)議的設(shè)備中還是要繼續(xù)使用repeated starts 的。

5、I2C的通知機制（ACK bit）只表示字節(jié)被從端接收，不能保證接收的數(shù)據(jù)的完整性和正確性。