本节书摘来异步社区《IP多播网络的设计与部署（第1卷）》一书中的第1章，第1.5节，作者：【美】Beau Williamson，更多章节内容可以访问云栖社区“异步社区”公众号查看
1.5 Internet的多播主干（MBone）
IP多播网络的设计与部署（第1卷）
Internet的多播主干（MBone）是一个Internet路由器和主机相互连接，并能转发IP多播流量的小型子网。
注意
这里说的“小型子网”，是指IP多播流量不会流到Internet中的每一个点（仅此而已）。IP多播的初学者经常错误地认为，只要他们接入到了Internet中，他们就能够接收IP多播流量。他们觉得，只要在他们的Internet网关路由器上开启IP多播路由功能，或者在他们的PC上增加某些特定的应用，就可以通过拨号Internet服务提供商接收MBone多播会话。不幸的是，事情并非如此，在下面的章节中将会了解到这一点。
下面几节讲述了几个不同的MBone会话示例、BMone的历史，以及MBone现在与将来的体系结构。
1.5.1 MBone会话
MBone上最受欢迎的一个会话是NASA航天飞机任务的音频/视频多播。其他一些有趣的甚至有时相当异乎寻常的多媒体内容也会在BMone上广播。例如，有些个人设置了宠物相机（pet-cam）来广播他们的宠物视频。例如，有个工程师在家里设置了宠物相机，并使位于他办公室的工作站一直收听这个视频多播，这样，他就能够监视他的宠物猫最近的手术恢复情况。
在另一个例子中，有人在广播CNN现场转播的O.J.Simpson判决。该多媒体多播一度曾经有超过350人进行收听。其他的媒体事件也曾经在MBone上进行过多播。在1994年，一场滚石乐队的音乐会从DEC系统研究中心通过MBone进行多播。有趣的是，在音乐会开始前半个小时，摇滚乐队Severe Tire Damage（该乐队的一些成员是Internet工程师）开始传输他们现场表演的音乐的音频和视频。Severe Tire Damage对他们的表演时间进行了控制，以便在滚石乐队的音乐会开始前，他们的表演刚刚结束。因此，滚石乐队的音乐会由MBone宣布开幕。
除了受欢迎的NASA航天飞机发射和不定期的摇滚音乐会之外，各种各样的会议和研讨会也经常通过MBone进行多播。在我无法外出旅行的那段时间（当时我正处于膝盖微创手术的恢复期），通过我的Cisco 1600路由器和连接到Cisco企业网络的ISDN线路，我当时就在家里收听IETF音频和视频多播。这使得我可以赶上某些有兴趣参加的关键的IETF会话（这些会话碰巧必须利用IP多播进行）。
这些事件对MBone连接性的迅速增长起到了巨大的推动作用，越来越多的Internet用户开始加入到MBone中来。尽管前面列举的例子要比其他事情（你能相信，有人一度对多盏不同的熔岩灯进行视频多播吗？）有趣，但是MBone上的商业多播和私有多播正逐渐成为新的Internet体验的一部分。
1.5.2 MBone历史
在20世纪90年代初，几位研究团体的成员向美国国防部高级研究计划署（DARPA）—当时Internet的主管部门抱怨，Internet已经成为了产业网络，已经不能再用于进行新网络技术的研究和实验。结果，美国政府搭建了DARPA试验床网络（DARTNet），这给研究人员提供了一块网络场地，以便研究人员特使和评估新的工具和技术，而不会对产业Internet造成影响。
最初，DARTNet由连接不同站点的T1线路组成，这些站点包括Xerox PARC、Lawrence Berkeley实验室、SRI、ISI、BBN、MIT和Delaware大学，它们用运行routed的SUN SPARC工作站作为单播路由程序（daemon），并用运行mrouted的SPARC工作站作为多播路由程序。因此，在所有的站点上，DARTNet天生就支持IP多播。这使得美国范围内位于不同DARTNet站点的研究人员之间的每周音频会议在不久之后正常实施。
在1992年初期，IETF计划3月份在加州的圣地亚哥举行下一次会议。遗憾的是，其中一位DARTNet研究人员不能来圣地亚哥出息IETF的这次会议，她因此向同事表达了失望之情。其他几位DARTNet研究人员，包括Steve Deering和Steve Casner在内，决定对ITEF的这次会议进行音频多播（这不仅允许他们的同事通过DARTNet网络参与IETF会议，而且也使得研究人员对Internet上的IP多播的概念进行进一步测试）。
Steve Deering和Steve Casner志愿负责把会议的音频馈入到借来的SUN SPARC工作站上，该工作站位于圣地亚哥的IETF。为了将多播音频返回DARTNet，在IETF的SPARC工作站和DARTNet骨干网之间配置了一条DVMRP隧道。参与该IETF音频多播的邀请，以及如何使用DVMRP隧道（该隧道穿越Internet返回到DARTNet骨干网）配置SUN SPARC工作站的信息也提前发送到美国、澳大利亚、瑞典和英格兰的多个Internet研究组织。有些站点对该邀请做出了回应，并设置了通往DARTNet骨干网的隧道。就这样，IETF的第一次音频多播通过Internet被传播到世界各地。
注意
在一次IETF全体会议期间，Steve Deering和Steve Casner将SPARC工作站的音频输出传送到房间内的公共广播系统中。全体会议的与会人员被告知，这次会议正在通过Internet进行音频多播，并被发送到美国、澳大利亚、瑞典和英格兰的多个地方。在会议发言人致辞的时候，他给通过多播听众提出了一个问题。随即，位于澳大利亚的一位多播参与人员的声音通过公共广播系统传了进来，而且声音响亮（那时的Internet没有现在这么拥挤）。该参与者回答了发言人的问题！于是，通过Internet上的IP多播来开展多媒体会议的时代从此到来。
1992年3月底，IETF会议结束时，通往DARTNet的DVMRP隧道被拆除，DARTNet也恢复正常。但是，音频多播是如此成功，ITEF决定在下次会议时同时采用音频和视频多播。邀请再次发送到了Internet上的更多站点，而且DVMRP隧道再次在这些站点和DARTNet骨干网之间建立。与3月份在圣地亚哥的IETF多播一样，夏天在华盛顿D.C.举行的ITEF对全世界的参与者而言，也是一次成功的音频和视频多播。
现在，人们开始见识到IP多播的强大功能。DARTNet的网络管理员和其他参与站点的网络人员决定保留DVMRP隧道，供在Internet上持续进行的多媒体会议使用。这些最初的隧道站点，以及作为最初的多播核心网络使用的DARTNet，不久之后被称为MBone。
1.5.3 今天的MBone体系结构
从1992年3月，最初只有少量的站点连接到DARTNet多播核心开始（通过DVMRP隧道和运行mrouted的SUN SPARC工作站），MBone一直稳定增长。图1-7所示为过去的5～6年期间，在MBone上通告的路由平均数量。
在本书写作之时，MBone上通告的平均DVMRP路由数量已经迅速接近于7000条。尽管与20世纪90年代初期的100条左右的路由相比，这个数值是一个非常大的增长，但是要知道，同一时期在Internet上通告的单播路由前缀的总量也才5000条。显然，在整个Internet支持IP多播之前，我们还有很长的路要走。
尽管MBone中的路由数量有了显著增长，但是今天的ＭBone体系结构自从1992年建立以来就一直没有重大的变化。DVMRP路由仍然在DVMRP隧道网络上的MBone路由器之间交换，除了几个例外。不幸的是，DVMRP从来没有被设计为域间多播路由协议，也不能扩展Internet的规模（原因是，作为一个基于距离向量的路由协议，DVMRP的最大跳数为32，而网络的直径肯定不会大于32！）。显然，要么需要一个新的协议，要么需要一个新的MBone体系结构，或者既需要一个新的协议，也需要一个新的MBone体系结构，才能使得Internet多播流量像Internet单播流量那样普遍存在。
由于最初的MBone创建于1992年，而且使用运行mrouted的UNIX主机作为MBone路由器，因此运行mrouted的MBone路由器的百分比一直缓慢下降。表1-1所示为路由器的代码版本以及运行相应代码版本的主机（路由器）数量的统计数据（统计于本书编写期间）。一般而言，版本号大于等于10的是Cisco交换机来交换DVMRP路由，而版本号小于10的则是基于UNIX的多播路由的主机。该表清晰地显示出，已有50%以上的MBone迁移到了基于商用的路由器平台上。
自从最早的MBone于1992年创建并且使用运行mrouted UNIX主机作为MBone路由器以来，运行多播路由的MBone路由器百分比一直逐步下降。表1-1统计了（取自这本书编写期间）路由器的版本代码以及运行这些实际版本的主机（路由器）数。通常，版本号大于等于10.0是基于多播路由的UNIX主机。本表清楚地显示有超过50%的MBone已经迁移到商用的路由器平台。
1.5.4 明天的MBone体系结构
在本书写作之际，为了使得IP多播扩展到Internet的所有点上，针对新协议和体系结构的设计正在如火如荼地进行。正在开发之中的新域间多播路由协议以及转发算法允许Internet服务提供商对多播对等体（peering）执行所需的控制和流量管理，从而确保了服务提供商在提供可靠的多播服务的同时，不会对已有的单播服务产生显著影响。第17章将涉及这些正在开发过程中的工作。
除了新的域间多播路由协议之外，也有必要使用动态多播地址分配来支持新的多播体系结构，以及仔细管理有限的IP多播地址空间（要对这些技术有一个粗浅了解，请参见第17章）。
不但必须要解决域间多播路由的技术问题，占据当今Internet最大份额的ISP也必须开发财务和记账模型，以便将IP多播作为一项服务提供给它们的客户。是让发送者支付费用来获取发送多播流量的功能呢（如前面的ACME例子中那样），还是想要接收多播内容的客户来支付费用呢？当将来有一天，在Internet举行的多对多的多媒体会议屡见不鲜时，很有可能得需要双方都来支付费用了。再次强调，定义财务和商业模型的复杂过程不亚于解决路由问题的过程。该定义过程将在后面讲解。
