MTG中IPv6组播的互通

IPv6组播的相关概念我们在之前的文章中已经讲述不少了。那么现在我们在来说一下MTG中的IPv6组播的作用。首先我们会举出一个视频会的具体实例，来帮助大家理解MTG的工作流程，之后是对IPv6组播路由的配置进行说明。

MTG的工作流程

下面以一视频会议为例说明MTG的工作流程?

IPv4中两名参与者F1和F2,IPv6中也有两名参与者S1和S2?其中F1为会议的组织者?所有参与者都运行会话描述协议(SDR)或类似SAP的监听器获取会话信息?

MTG的IPv4和IPv6地址分别为202.112.25.214和3FFE:3206:1000::19D6?同时将MTG配置为IPv6组播指定路由器?

参与者F1首先向224.2.127.254:9875公告会议信息,通知其他会议参与者使用224.5.5.5作为会话地址,并同时向IPv4发送视频/音频流?

参与者F2通过SDR直接收到该SAP公告,并启动组播会议工具?此时F1和F2可以进行会话?

当SAP公告到达MTG,MP4将其转交至MT,MT对其进行报头转换,源地址转换为MTG的固定IPv6地址3FFE:3206:1000::19D6,宿地址为FF0E:0::2:7FFE?并调用应用层回调函数解析出组播会话地址224.5.5.5,然后从AM取得对应的IPv6地址FF1E::224.5.5.5,在应用层上对其携带的信息进行修改?MT再将已转换的SAP报文转交给MP6,将之发送到IPv6网络?SAP第一次到达时,AM会更新映射表?

参与者S1和参与者S2收到SAP公告之后,发起MLD成员报告?MP6收到MLD报告之后,转交给MT,MT将MLD报告转换成IGMP成员报告,通过MP4向IPv4发送成员关系报告,并加入224.5.5.5组?至此,4个参与者均加入组播会话?

MP4接收到参与者F1发出的IPv4组播报文,并转交给MT,MT对其进行报头转换,源地址转换为MTG的固定IPv6地址3FFE:3206:1000::19D6,宿地址224.5.5.5转换为对应的IPv6地址FF1E::224.5.5.5,再经由MP6组播给参与者S1和参与者S2?MP6接收到参与者S1和参与者S2发出的IPv6组播报文,并转交给MT,MT对其进行报头转换,源地址转换为MTG的固定IPv4地址202.112.25.214,宿地址FF1E::224.5.5.5转换为对应的IPv4地址224.5.5.5,再经由MP4组播给参与者F1和参与者F2?当参与者S1和参与者S2都退出时,MP4不再向MT转交该组组播报文?

当不使用SAP时,会话地址202.5.5.5必须通过人工传达或Web公布等方法告之所有会议参与者?管理员或者被授权的终端用户通过SNMP外部接口注册202.5.5.5组播组,并取得IPv6映射地址FF1E::224.5.5.5?IPv6用户使用FF1E::224.5.5.5地址加入组播会话?

要使IPv4主机与IPv6主机进行组播通信,必须做诸如转发器(在传输层)或网关(在网络层)之类的协议转换工作?

MTG在实现网关基本功能的基础上,对网关作了一定程度的改进?网关对IPv4组播的组成员及源的有效期不敏感的问题,可以通过使MTG同时成为IPv4的组播路由器,而使MTG具有获知组成员状态的能力;对于网关中IPv4只能访问给定前缀的IPv6组,从MTG模型结构可以看出,在附加前缀的基础上,通过可管理的静态地址映射,消除了IPv4对IPv6的访问限制?

MTG还对网关方案未曾具体涉及的问题进行了探讨?根据标准草案RFC2365,加入对不同协议间组播管理域的映射;通过SNMP接口和扩展MIB,将网关的管理标准化?另外在底层实现上,MTG采用了逐级细化的处理流程,增加了可配置的网关的拥塞控制策略和报文调度策略,可根据QoS和流量控制要求对高速缓存中的报文进行可控调度?

使用MTG,可以有效实现IPv4-IPv6组播互通?