一(yī)、概述      上一(yī)篇講述了bitmap的(de)端口表示方法，也講了單播隻用常規方法表示的(de)原因，故我們隻需要對多播的(de)轉發表進行(xíng)相應的(de)定制和(hé)處理(lǐ)即可(kě)。單播和(hé)多播的(de)地(dì)址區分也已在上篇文章(zhāng)中交待清楚，本篇重點講述如(rú)何處理(lǐ)多播數據。 二、多播表定義      根據前篇分析，多播表的(de)定義隻是将其端口号字段的(de)表述進行(xíng)了重定義。故多播表的(de)定義隻需要将單播表複制一(yī)份即可(kě)，隻是在處理(lǐ)多播數據時，對端口字段的(de)使用有(yǒu)些不一(yī)樣。

struct table_port_mac *obx_mc_mac_tbl = NULL;/*定義多播MAC轉發表對象為(wèi)空指針，将在main函數中初始地(dì)址*/
/*為(wèi)多手播MAC轉發表分配內(nèi)存，并初始數據為(wèi)0*/
obx_mc_mac_tbl = (struct table_port_mac *)malloc(sizeof(struct table_port_mac));
memset(obx_mc_mac_tbl,0,sizeof(struct table_port_mac));

三、組播協議      本交換機(jī)原型中，我們僅支持IGMP v3版本，故隻對該版本協議進行(xíng)解析處理(lǐ)，對組播的(de)入組與退組處理(lǐ)隻需要處理(lǐ)IGMPv3 的(de)Report分組協議即可(kě)。
     解析IGMP協議我們需要關心的(de)分組字段如(rú)下：
     1）IGMP的(de)組播IP地(dì)址為(wèi)224.0.0.22，多播MAC為(wèi)：01:00:5E:00:00:16      2）以太網幀類型為(wèi)IPv4(0x0800)      3）IP協議号為(wèi)IGMP(0x2)      4）IGMP協議的(de)type字段為(wèi)0x22(V3 report)      相關的(de)協議數據結構定義在以下幾個系統頭文件中，将其添加到代碼頭部。

#include /*ethhdr*/
#include /*iphdr*/
#include /*igmvp_report*/

四、代碼修改      1）多播解析      多播首先判斷MAC地(dì)址的(de)第1字節的(de)最低(dī)位，分離(lí)出多播分組，然後再精确篩選出組播入組與退組的(de)通告消息。

if(pkt->data[0]&0x1)//MC MAC
{
u64 igmpv3_dmac = 0x1600005E0001;
if(!ether_addr_equal(pkt->data,(u8 *)&igmpv3_dmac)) //IGMP
{
struct ethhdr *eth = (struct ethhdr *)pkt->data;
struct iphdr *ip = (struct iphdr *)(eth+1);
int oft = 0;
if(eth->h_proto = htons(0x0800) && ip->protocol == IPPROTO_IGMP)
{
oft = sizeof(*eth) + ip->ihl * sizeof(int);
igmpv3_report(pkt->um.inport,pkt->data+oft);
}
}
}

     2）多播學(xué)習      精确篩選出IGMP的(de)Report分組後，便可(kě)根據協議字段區分是入組消息或是退組消息。該步最核心的(de)一(yī)步是要将IGMP中的(de)組播IP地(dì)址轉換為(wèi)多播MAC，并将該MAC消息學(xué)習到多播MAC轉發表中。多播MAC的(de)轉換規則有(yǒu)明确的(de)定義要求，簡言之就是MAC地(dì)址由三部分組成：高(gāo)24位固定為(wèi)01:00:5E，第23位為(wèi)0，低(dī)23位為(wèi)組播IP的(de)低(dī)23位。

void igmpv3_report(u8 inport,u8 *igmp)
{
struct igmpv3_report *g3r = (struct igmpv3_report *)igmp;
if(g3r->type == IGMPV3_HOST_MEMBERSHIP_REPORT)/*IGMPv3_REPORT*/
{
u8 mc_mac[MAC_LEN] = {0x01,00,0x5E};
u8 *mcip = NULL;
int k = 0;
for(;kngrec);k++)
{
mcip = (u8 *)&g3r->grec[k].grec_mca;
memcpy(&mc_mac[3],&mcip[1],3);/*僅複制後3字節數據*/
mc_mac[3] &= 0x7F;/*将第23bit置0*/
join_leave_mc_mac(inport,mc_mac,g3r->grec[k].grec_type);
}
}
}

     多播MAC的(de)學(xué)習過程封裝在join_leave_mc_mac函數中，其核心操作方法與單播MAC的(de)學(xué)習過程類似，隻是在對端口号的(de)處理(lǐ)不同。

if(type == IGMPV3_CHANGE_TO_EXCLUDE)/*入組*/
{
obx_mc_mac_tbl->row[i].port |= 1<<>
}
else/*退組*/
{
obx_mc_mac_tbl->row[i].port &= ~ (1<<>
}

     3）多播查表      多播的(de)查表與單播完全一(yī)緻，隻是查表的(de)對象換成多播表，這兩個查表過程可(kě)以代碼優化成一(yī)個功能函數。      4）多播輸出      多播的(de)輸出端口信息存儲在返回值的(de)每個bit位上，故需要根據輸出端口的(de)bit位是否為(wèi)1來作為(wèi)分組輸出判斷依據。單播和(hé)多播的(de)統一(yī)輸出函數如(rú)下：

void output(u8 outtype,int outport,struct fast_packet *pkt)
{
if(outtype == UC)
{
pkt->um.outport = outport;
pkt_send_normal(pkt,pkt->um.len);
}
else
{
int i = 0;
for(;i<>
{
if(pkt->um.inport != i && (outport & (1< 0)
{
pkt->um.outport = i;
pkt_send_normal(pkt,pkt->um.len);
}
}
}
}

     一(yī)定要記得，底層API的(de)輸出端口号是常規表示方法，在多播輸出時的(de)端口号應該是變量i的(de)值。 五、總結與下一(yī)步      1）确定協議支持      硬件适合做(zuò)簡單、确定的(de)事情，軟件适合做(zuò)靈活多變的(de)事情。故若在硬件中支持組播的(de)加入和(hé)退出，簡單實現就是支持确定性的(de)IGMPv3協議的(de)Report功能，硬件可(kě)以不像軟件一(yī)下逐層解析協議，可(kě)以直接将對應幾個位置的(de)數據都取出來之後一(yī)次判斷，符合要求的(de)消息即可(kě)繼續完成後續功能。硬件不如(rú)軟件靈活，對每一(yī)種确定協議的(de)支持都需要确定的(de)邏輯支撐，所以對于比較複雜的(de)協議交互，一(yī)般在要設備中加入輕量級的(de)CPU進行(xíng)處理(lǐ)。一(yī)般像确定的(de)組播協議可(kě)以放到FPGA實現，而生成樹協議不适合FPGA實現。      2）MAC表的(de)老化      老化簡單來說就是删除長(cháng)時間不使用的(de)表項，把空間留出來給新的(de)MAC地(dì)址使用。老化是為(wèi)了解決MAC地(dì)址數量大于轉發表空間容量的(de)問題。若有(yǒu)些MAC地(dì)址使用一(yī)段時間之後，就一(yī)直不再使用或關機(jī)，則交換機(jī)無需再保留其在MAC轉發表中。若不删除，則會導緻新的(de)MAC表找不到存儲空間，導緻大量的(de)數據轉化為(wèi)泛洪發送，對整個網絡來說是災難性的(de)，不可(kě)容忍的(de)。當然，不計成本的(de)擴大存儲容量更是不可(kě)取的(de)。故MAC表的(de)老化是十分必要的(de)，下篇主要內(nèi)容講述MAC表老化。 六、結語       歡迎您和(hé)學(xué)生們加入FAST開源項目群溝通與探讨，一(yī)起體驗不一(yī)樣的(de)系統設計過程。請先加微信号15116127200後邀請入群。