第19章 网际多目标广播简介
***************************************************************************
19.1 多目标广播的概念
19.2 多目标广播所需要的环境
19.3 多目标广播树的概念
19.4 IP多目标广播的地址和主机组的管理
19.4.1 IP多目标广播的地址
19.4.2 网际主机组管理协议
14.4.3 接收端如何参与多目标广播
19.5 多目标广播路径选择简介
19.5.1 两种基本的路径选择法
19.5.2 密集型多目标广播路由协议
19.5.3 稀疏型多目标广播路由协议
19.5.4 协同工作
19.6 实时传输协议和实时控制协议
19.6.1 RTP简介
19.6.2 RTP信息包标题域
19.6.3 实时传输控制协议
19.6.4 实时流放协议
19.7 资源保留协议
19.7.1 RSVP协议简介
19.7.2 不同种类的接收器
19.7.3 接纳测试
19.7.4 路径消息练习与思考题参考文献和站点
***************************************************************************
进入20世纪90年代之后，组合声音、电视和数据流的多媒体网络应用的开发和研究迅速增加，近年来也不断有产品投入市场，用户也渴望得到服务质量好、服务费用低的产品，像电视会议、协同工作、远程教学、可视电话等等的多媒体网络应用都是非常受欢迎的应用。这些应用都是实时的交互应用，而且即使采用了很好的压缩技术，传输多媒体数据所需要的带宽也是巨大的。在实现这些令人兴奋的应用中，正在开发的网际多目标广播(IP multicast)技术将会并且正在起着越来越重要的作用。使用多目标广播技术不仅可以节省宝贵的网络资源(主要是带宽)和服务器资源，而且可以保证服务质量。
如同因特网上的其他应用技术一样，多目标广播的核心技术体现在各种各样的协议上。协议是技术的精华，是人类智慧的结晶。如果不带着问题去阅读协议是很枯燥的，如果要开发产品就要了解协议的思想，就要深入研究协议的细节，如果没有协议可遵循就自己制定和提交新的协议，让大家使用你提出的协议。为此，编者从2500多个RFC文件中挑选了与多目标广播关系最密切的RFC文件，列在本章的“参考文献和站点”中供感兴趣的读者进一步研究。
19.1 多目标广播的概念假设世界上有许多用户想在因特网上接收现场电视节目(例如现场体育比赛)，如何把它传送到世界各地？最直观的方法就是使用传统的IP寻址方法，每个信息包都使用一个唯一的IP地址，一次只给一个节点(即主机)传送，如图19-01所示，这种方法称为单目标传送(unicast)。如果使用单目标广播服务把相同内容的信息传输给N个目标站点，就须要传输N个拷贝，即要传输N次。
图19-01 单目标广播服务
使用这种方法有下列缺点：①浪费链路带宽，因为在链路上要传送多个相同的拷贝，②大大地加重了服务机的负担。一个比较好的方法是把消息一次性地同时传输给N个目标站点，如图19-02所示，这就叫做多目标广播(multicasting)，在因特网上广播就称为IP多目标广播(IP multicast)或者叫做网际多目标广播。
图19-02 多目标广播服务
多目标广播是真正的分布式信息传输服务，使用IP多目标广播可以大大减轻网络上出现的拥挤和服务器的负担，因此可用于声音和影视的实时广播，例如，因特网电话会议，因特网电视会议。
研究表明，要满足多目标广播的要求，只须在IP协议中增加支持多目标广播的路径安排(multicast routing)功能就可以。IP多目标广播路由协议(IP Multicast routing protocol)比较好地满足了在IP网络上实现多目标广播的功能。
19.2 多目标广播所需要的环境为支持IP多目标广播，发送端和接收端以及收发两端之间的网络设施都必需具备多目标广播功能，包括中间的路由器。对本地的IP多目标广播，主机节点所需要的环境是：
TCP/IP协议堆中可支持IP多目标广播。
软件支持网际主机组管理协议(Internet Group Management Protocol，IGMP)，这样就可以申请参加多目标广播组(multicast group)和接收多目标广播。
要有IP多目标广播应用软件，例如电视会议软件。
在LAN网络上运行或者评估多目标广播，只需要以上的环境就满足。在这个环境下，不需要路由器来为主机的适配器创建或者加入多目标广播组就可以与其他主机共享多目标广播数据。
在WAN网络上运行或者评估多目标广播就还需要：
在接收两端之间的所有路由器都具备多目标广播的功能。许多新的路由器都有这个功能，老的路由器也许需要升级和更新。
也许要能识别防火墙以便使多目标广播畅通。
多目标广播得到工业界的广泛支持，现在也有许多网络基础设施厂商提供支持多目标广播的软硬件，如路由器、交换机、TCP/IP堆、网络接口卡、桌面计算机操作系统和应用软件。
图19-03描述了运行多目标广播必需要有的部件。图中的交通方向是多目标广播数据包的方向，需要与主机组成员进行通信的消息和传输路径消息没有在图上表示。
图19-03 网际多目标广播环境[1]
19.3 多目标广播树的概念为了便于说明多目标广播技术中的问题，我们引入多目标广播树(multicast tree)或者叫做多目标广播跨越树(multicast spanning tree)的概念，用它来描述服务机(播送机)和接收机之间构成的播放与接收关系。服务机只向外传送一个信息包流，每当信息包到达多目标广播树中有多个分支的路由器时，路由器就为每个分支复制一个信息包。这样就减轻了服务机的负担，更有效地利用了网络资源。
图19-04说明多目标广播树的概念。图中S表示多目标广播的源端主机，R表示参加多目标广播的终端主机，MR(multicast-enabled router)表示具有多目标广播功能的路由器。注意，IP子网中有一处没有主机，表示对多目标广播没有任何兴趣的站点。
图19-04 多目标广播树的概念
网络将使用路由协议建立从源端到所有希望参加会话的接收端之间的多目标树，图19-05说明这种树的结构。网络建立多目标广播树的过程如下：
广播源把数据或者广播通知发送给所有路由器。
不想参加多目标广播的终端逆向发送一个删除消息。
删除没有成员的分支和不在最短路径树上的分支。
在广播源生成最短路径树。
使用联结和删除功能改变成员之间的关系现在至少有三种多目标广播路由协议：
距离矢量多目标路由协议(Distance Vector Multicast Routing Protocol，DVMRP)。
多目标广播开放最短路径优先协议(Multicast Open Shortest Path First，MOSPF)。
协议独立多目标广播(Protocol Independent Multicasting，PIM)。
图19-05 多目标广播树结构
19.4 IP多目标广播的地址和主机组的管理
19.4.1 IP多目标广播的地址大多数高层网络协议(high-level network protocol)，例如传输控制协议(Transfer Control Protocol，TCP)和用户数据包协议(User Datagram Protocol，UDP)仅提供单目标广播(unicast)传送服务，不能满足多目标广播的要求。为了提高网络资源的利用率和提高服务质量，1989年由施乐公司(Xerox)在帕洛阿尔托研究中心(Palo Alto Research Center，PARC)的Steve Deering提出了一种解决方案，就是使用IP地址中的D类地址来实现IP多目标广播(IP-Multicast)。这个解决方案是以RFC 1112的形式公布的。为了探索多目标广播的应用，1992年3月因特网工程特别工作组(Internet Engineering Task Force，IETF)召开的会议上采纳了一种称为“多目标广播骨干网MBone”的试验方案，1993年7月正式命名为MBone，是一种可在全球范围内传输电视的网络。
在因特网上多目标广播的广播源分散在世界各地，加入某一广播的所有计算机构成一个计算机组，称为主机组(host group)。一个主机组的成员是随时变动的，一台主机可以随时加入或者退出主机组，主机组成员的数目和所在的地理位置也不受限制，一台主机也可以属于几个主机组。IP多目标广播使用D类IP地址(Class D Internet Protocol addresses)，它的最高4位为1110就是用来指定多目标广播主机组群(multicast host groups)的地址。在网际协议地址(IP地址)的“点十进制”记法中，主机组的地址范围从224.0.0.0到239.255.255.255。主机组的地址划分为两种类型，一种称为永久性地址，另一种称为暂时性地址。地址的分配由因特网号码分配局(Internet Assigned Numbers Authority，IANA)掌握。例如，永久地址224.0.0.1称为“所有主机组(all-hosts group)”地址，它是用来与直接连接到网络上的所有IP多目标广播主机组进行通信的地址，而244.0.0.2是与LAN上的所有路由器进行通信的地址。244.0.0.0到244.0.0.255是为路由协议和其他用途保留的地址。其他的地址和地址范围用于应用软件，例如，244.0.13.000到244.0.13.255用于网络新闻(Net News)，这些保留的IP多目标广播地址列在RFC 1700中。广播发布或者叫做会话发布协议(Session Announcement Protocol)和会话说明协议(Session Description Protocol)—— RFC 2327草案描述了如何创建和检测MBone的会话地址/端口的分配。
发送给多目标广播主机组所有成员的数据包称为IP多目标广播数据包(IP Multicast Datagram)，这种数据包与单目标广播IP数据包相同。要发送IP多目标广播数据包时，发送端指定一个代表主机组的目标地址，使用与发送单目标数据包一样的操作“Send IP”来发送多目标广播数据包。
与发送IP多目标广播数据包比较，接收IP多目标广播数据包要复杂得多，尤其是在WAN上。为了接收数据包，用户主机上的应用软件需要在多目标广播主机组中申请成员资格。申请成员资格要与LAN上的路由器通信，如果需要的话还要与发送端和接收端之间的中间路由器进行通信。有了成员资格之后，接收端主机上的网络接口卡就可开始筛选具体的LAN网络硬件(数据链路层)的地址，这个地址是与新的多目标广播组地址相关联的。WAN路由器把请求的多目标广播数据包递送到LAN路由器，LAN路由器把接收端的主机地址转换成相关的硬件地址，然后使用这个地址创建消息(例如，以太网帧)。正在注意这些地址的接收主机的网络接口卡和网络驱动程序就把多目标广播消息传输给TCP/IP协议堆，由协议堆把广播消息变成用户应用程序的输入，例如电视播放器。
19.4.2 网际主机组管理协议如果LAN上多目标广播组的成员要接收来自远距离广播源的广播，多目标广播信息包就必需要通过路由器转发到LAN网上。多目标广播路由器通过使用网际主机组管理协议(Internet Group Management Protocol，IGMP)来查明直接附加到子网的主机组成员是否存在，它发送一个IGMP查询消息以获得主机组成员的情况。IGMP的详细内容可参看RFC 1112和RFC 2236。
网际主机组管理协议IGMP在IP上的执行过程与网际控制消息协议(Internet Control Messages Protocol，ICMP)的执行过程类似。IGMP消息封装在IP数据包(IP datagram)中，而数据包有两种类型：主机成员查询(Host Membership Query)数据包和主机成员报告(Host Membership Report)数据包，它们具有相同的如下固定格式。
Version
(bits 0-3)
Type
(bits 4-7)
Code
(bits 8-15)
Checksum
(bits 16-31)
Multicast Group Address (Class D)
为了确定在局域子网上的任何一台主机是否属于多目标广播组，每个子网上的路由器要周期性地向LAN上的所有终端主机发送一个主机成员查询(Host Membership Query)信息，要求它们汇报主机组群成员的情况。这个查询被送到所有主机组(网络地址＝224.0.0.1)，而每台主机都回送一个主机成员报告(Host Membership Report)信息，如图19-06所示，这样就可确定子网上的主机是否加入多目标广播组，从而确定是否要把多目标数据包送到这个子网。
图19-06 在LAN内的网际主机组成员协议(IGMP)消息[1]
19.4.3 接收端如何参与多目标广播多目标广播会话消息经常通过因特网广告通知接收端。广告使用应用层的广播会话说明协议(Session Description Protocol，SDP)来发布。这个协议发送广告的地址是224.2.2.2，UDP端口号是4000，这是一个特殊的多目标广播会话。发送的广告内容包括广播的名称、广播时间(active times)、媒体的类型(声音、电视、白板等等)和广播地址。任何有兴趣了解多目标广播的主机都可以参加这个特殊的多目标广播会话和接收这种广告。可用一台主机运行用户代理来收集广告并把广告摘要用图形方式向用户显示。第一个这样的用户代理叫做会话目录(Session Directory，SD)，是由LBL(Lawrence Berkeley Laboratories )的Van Jacobson开发的，它除了显示公告之外，也启动多目标应用程序和为任何一个新的多目标广播会话选择一个地址。
如何给多目标广播分配地址？当源端开始一个新的多目标广播时，SD就从多目标地址空间中随机地选择一个多目标广播地址。参加多目标广播的主机需要做两件事：①要立即给最近的路由器发送一个消息，告诉它参加多目标广播，发送这个消息是使用应用层的一个叫做网际主机组管理协议IGMP。②要设置IP进程去接收IP数据包，因为它在IP目标地址域中含有会话的多目标广播地址，当接收端退出多目标广播会话时，类似的进程也要设置。
19.5 多目标广播路径选择简介
19.5.1 两种基本的路径选择法多目标广播是从广播源向目标组连续发送信息的过程。多目标广播交通是经由跨越树(spanning tree)从广播源传送到机组中的所有接收主机。不同的IP多目标广播路由协议使用不同的技术来构造多目标广播跨越树(multicast spanning tree)。跨越树一经构造，多目标广播交通就在跨越树上穿越。
根据多目标广播组成员在整个网络上预期的分布情况，IP多目标广播路由选择(IP Multicast Routing)协议通常遵循下述两种基本假设来制定：
(1) 多目标广播组成员密布在整个网络上，也就是许多子网至少包含一个成员，并且带宽很充裕。根据这种假设制定的协议叫做密集型多目标广播路由协议(dense-mode multicast routing protocols)，它是依靠一种称为“流放(flooding)”技术来把信息传播到网络上的所有路由器。这个协议包含距离矢量多目标广播路由协议(Distance Vector Multicast Routing Protocol，DVMRP)、多目标广播开放式最短路径优先(Multicast Open Shortest Path First，MOSPF)协议和协议独立的多目标广播-密集型(Protocol-Independent Multicast - Dense Mode，PIM-DM)路由协议。
(2) 多目标广播组成员稀疏地分布在整个网络，并且未必有充裕的带宽可用。例如，多目标广播组成员跨越因特网上的许多地区就是属于这种情况。根据这种假设制定的协议叫做稀疏型多目标广播路由协议(Sparse-Mode Multicast Routing Protocols)。稀疏型并不意味多目标广播组的成员很少，而仅仅是指散布得很广。在这种情况下使用流放技术会浪费不该浪费的带宽，引起严重的性能问题。稀疏型多目标广播路由协议包括用几个核心路由器构造的核心基干树(Core Based Trees，CBT)协议和协议独立的多目标广播-稀疏型(Protocol-Independent Multicast- Sparse Mode，PIM-SM)路由协议。
19.5.2 密集型多目标广播路由协议
1,距离矢量多目标广播路由协议(DVMRP)
为支持多目标广播路径选择而开发的第一个协议叫做距离矢量多目标广播路由协议(Distance Vector Multicast Routing Protocol，DVMRP)。它已广泛用在MBone网络上，该协议在RFC 1075中有详细的描述。
DVMRP为每一个广播对(广播源和目标主机组)构造不同的广播发送树(distribution tree)。每棵发送树是最小跨越树(spanning tree)，这种树是指从树根上的广播源算起到作为树叶的所有接收多目标广播的主机构成的树。根据信息包在路径上的转发(hop)数，这种发送树提供在广播源到每个接收主机之间的最短路径。当广播源开始给多目标广播组传送信息时，使用“播送和剪除(broadcast and prune)”技术来构造发送树。
为简化对DVMRP的说明，假设网络上的所有路由器都支持DVMRP。DVMRP使用的方法是假设网络上的每台主机都是多目标广播组的一部分，在广播源子网上的路由器，也就是指定用来为子网上所有主机处理路径选择的路由器，首先向所有相邻的路由器传送多目标广播信息，然后每台路由器有选择地把广播信息发送到下游路由器，一直发送到所有多目标广播组的成员。
在生成跨越广播树期间有选择的转发工作过程如下。当路由器接收到一个多目标广播信息时，它就检查它的单目标广播路由表，以便确定返回到广播源的最短路径的接口。如果这个接口就是多目标广播信息到达的最短路径接口，路由器就在它内部的表中登录某些状态信息用来识别多目标广播组，并且把多目标广播消息转发到所有相邻的路由器。这种机制叫做反向路径转发(Reverse Path Forwarding)，它可确保在广播树上没有环路，而且广播树包含的路径(从广播源到所有接收主机之间的路径)是最短路径。这是DVMRP协议的基本部分。
协议中的剪除部分是用来剪除广播树的树枝，就是删除不参加多目标广播组的成员。IGMP协议运行在主机和与它们直接邻接的路由器之间，它用来维护路由器中的组员数据。当路由器确信没有主机属于多目标广播组时就向上游路由器发送一个剪除信息。毫无疑问，路由器也要修改路由表中的状态信息以反映那个分支已从这棵上剪除掉。这个过程一直到所有多余的分支被剪除掉为止。最后得到的是一棵最小跨越广播树。
DVMRP跨越广播树的构造如图19-07所示。一旦构造了跨越广播树，就可以使用它把多目标广播信息从广播源传送到多目标广播组的成员，而沿途上的路由器在通往广播组成员的接口上转发多目标广播信息。由于新的成员可在任何时候加入到广播组，而且由于新成员可能是在某一个被剪除的分支上加入，因此DVMRP就周期性地重新启动跨越广播树的构造进程。
在子网上密布有多目标广播组的情况下，DVMRP工作得很好。但多目标广播组稀疏分布在广域网上的情况下，周期性地广播行为会使网络的性能严重下降。使用DVMRP的另一个问题是，多目标广播路由状态信息的数量问题，因为所有路由器都必需为每个广播组(广播源和接收组)存放状态信息，这些信息是用来转发多目标广播消息的指定接口信息，或者是剪除状态信息，而且这些信息必需要存放在多目标广播路由器中。
图19-07 DVMRP跨越广播树的构造过程[1]
现在回过头来简要说说跨越树的构造过程。按照每个时间单元转发一次消息来划分
① 在第1次转发时，消息到达路由器MR1。
② 在第2次转发时，消息到达路由器MR2、3和4。
③ 在第3次转发时，消息到达路由器MR5、6和8，路由器MR3和4交换消息。
④ 在第4次转发时，消息到达路由器MR7。它认识到这是一个叶子路由器，而且在子网上没有广播组的成员，所以它就回送一个剪除消息给路由器MR6。路由器MR6回送一个剪除消息给路由器MR4。路由器MR3也回送一个剪除消息给路由器MR1。
最后生成的跨越树如图19-08所示。
图19-08 最后生成的跨越广播树[1]
2,多目标广播开放最短路径优先协议(MOSPF)
多目标广播开放最短路径优先协议(Multicast Open Shortest Path First，MOSPF)在RFC 1584中有详细的解释，开放最短路径优先协议(Open Shortest Path First，OSPF)是单目标广播路由协议，在RFC 1587中有详细的解释，它沿着最低成本路径邮递消息，而最低成本则使用链路状态(link-state)来衡量的。除了路径上的转发数之外，可能影响成本的网络性能参数包括：①负荷平衡信息，例如，对通信量小的链路，其成本就比较低，对交通量大的链路，其成本就比较高，这样做是为了平衡网络上的交通；②要求的服务质量，例如，对要求时延低的服务，其成本就比较高，对要求使用卫星链路的服务，其成本就比较高，等等。
MOSPF倾向于用在诸如由单个组织控制的网络上，MOSPF不能脱离OSPF来使用，需要与单目标路由协议联用。在使用OSPF/MOSPF协议的网络中，每个路由器都要维持整个网络的最新布局图，其链路状态信息就用来构造多目标广播树。
每台MOSPF路由器通过网际主机组管理协议(Internet Group Management Protocol，IGMP)周期性地收集多目标广播组成员的信息。这个信息连同上述的链路状态信息一起传送到这个路由域中所有的其他路由器。根据从邻接路由器接收到的信息，路由器将修改它们内部的链路状态信息。由于每个路由器都了解整个网络的布局，因此路由器就使用广播源作为树根、使用广播组的成员作为树叶来独立计算最低成本跨越广播树。由于所有路由器都周期性地共享链路状态信息，因此它们计算得到的广播树将完全相同。然而，由于MOSPF要周期性地在路由器之间传递链路状态信息，因此并不认为MOSPF很适合用于多目标广播。
MOSPF使用Dijkstra算法去计算最短路径树。对每个广播对(广播源和目标组)都要单独计算。为了减少计算量，当路由器接收到数据包流中的第一个数据包时才做这种计算。一旦计算出广播树，就把信息存储起来，为后来的数据包使用。广播树的构造计算过程如图19-09所示。
图19-09 MOSPF树的计算过程[1]
计算步骤如下：
① MR1计算的树：经由IGMP知道组的成员，因此就知道通往MR4的路径要经MR2，通往MR8的路径要经MR5，等等。
② MR2计算的树：确定通往MR4的路径是直接的，通往MR8的路径要经MR5；MR3计算的树：确定通往MR9的路径是直接的。
③ MR5计算的树：确定通往MR8的路径是直接的。
随便提及的是，这个计算过程是由多目标广播传输来激发的，也就是数据驱动(data driven)的方法；每台路由器接收到消息时就计算广播树，并可得到完全相同的广播树，然后使用广播树来转发广播内容。
3,协议独立多目标广播路由协议(PIM)
协议独立多目标广播(Protocol Independent Multicast，PIM)路由协议正在由因特网工程特别工作组(Internet Engineering Task Force，IETF)的一个工作小组开发。现在已有某些路由器产品中支持PIM协议。这个协议的目标是要开发一个标准的多目标广播路由协议，它不依赖于任何特殊的单目标广播路由协议提供的方法，用在因特网上可增减路由域数目的域间多目标广播的行程安排。PIM有两种运行模式：一种是为密集型分布的多目标广播组群，另一种是稀疏型分布的多目标广播组群。第一种方式叫做协议独立多目标广播-密集型(Protocol-Independent Multicast-Dense Mode，PIM-DM)路由协议，将在下面介绍。第二种叫做协议独立型多目标广播-稀疏型(Protocol Independent Multicast - Sparse Mode，PIM-SM)路由协议，将在“19.5.3 稀疏型多目标广播路由协议”中介绍。
协议独立型多目标广播-密集型(PIM-DM)路由协议与距离矢量多目标广播路由协议DVMRP 相类似，它们都使用反向路径多目标广播技术(Reverse Path Multicasting，RPM)来构造以广播源为树根的广播树(source-rooted distribution trees)。DVMRP和PIM-DM之间的主要差别是：PIM完全独立于单目标路由广播协议(unicast routing protocol )，而DVMRP则依赖单目标广播协议的机制，PIM-DM也比DVMRP简单。
PIM-DM是数据驱动型协议，它构造广播树的方法就像所有密集型路由协议(dense-mode routing protocols)那样。然而，由于PIM-DM独立于单目标广播路由协议，因此在最短路径接口上到达路由器的信息包被转发到所有下游接口，一直到达不必要的分岔树枝被剪除为止。如前所述，在构造广播树期间，DVMRP使用单目标广播协议专门提供的拓扑信息来转发消息，因此DVMRP就有更多的挑选余地。而PIM-DM协议的设计人员遵循的哲学是在协议的简单性和协议的独立性方面下功夫，甚至不惜增加信息包的开销。
19.5.3 稀疏型多目标广播路由协议前面介绍的路由协议都是依靠周期性地把消息流放到整个网络。在多目标广播组广泛分布在整个网络区域内或者带宽充裕的区域，使用这种方法是很有效的。但是，如果在因特网上有数千个小型会议同时召开的情况下，所有周期性的流放消息所构成的交通就很可能使因特网不堪承受。很明显，如果组员稀疏地分布在广阔地区，就需要使用不同的方法来使多目标广播交通限制在与组员相连接的链路上，稀疏型多目标广播路由协议(Sparse-Mode Multicast Routing Protocols)就是为此而开发的协议。
密集型需要使用数据驱动(data-driven)方法来构造多目标广播树，而稀疏型协议使用接收器启动(receiver-initiated)的方法来构造多媒体广播树，也就是仅当子网上有主机向特定多目标广播组申请成员资格时，路由器才去构造多目标广播树。下面介绍构造广播树的两种稀疏型多目标广播路由协议。
1,核心基干树(CBT)协议某些多目标广播应用，例如像分布式交互仿真(模拟)和分布式交互电视游戏这类应用，在单个多目标广播组中有很多主动的发送者。不像DVMRP或者MOSPF要为每个广播对(广播源和目标组)构造一个最短路径广播树，核心基干树(Core Based Tree，CBT)协议构造一棵由所有组员共享的树，整个组的多目标广播交通都在这棵相同的树上发送和接收，而不管它们的广播源。使用共享树可以明显节省在路由器中存储的多目标广播状态信息的数量。
一棵CBT共享树以一个路由器为核心来构造广播树，CBT共享树的构造过程如图19-10所示。如果要想加入这棵核心树，路由器就发送一个加入消息(join message)到核心路由器表示它准备加入核心树。当核心路由器接收到加入申请时，核心路由器给它返回一个确认消息，这样就形成一个树的分支。申请加入广播树时，加入消息不需要穿越到达核心路由器的所有线路。如果一个加入消息在到达核心路由器之前命中广播树上的一个路由器，这个路由器就会终止转发加入消息，并且回送一个确认消息，然后它就连接到了共享树上。
图19-10 CBT共享树[1]
某些版本的CBT路由协议支持使用多个核心路由器，因此负载平衡问题也就可以使用多个核心路由器来改善。
2,协议独立多目标广播-稀疏型协议(PIM-SM)
与CBT类似，协议独立多目标广播-稀疏型(Protocol-Independent Multicast - Sparse Mode，PIM-SM)路由协议用来限制多目标广播的交通只通向那些感兴趣接收广播的路由器。PIM-SM围绕一个称为会合点(rendezvous point)的路由器来构造多目标广播树。这个会合点所扮演的角色与CBT协议中的核心路由器所扮演的角色相同，但比CBT协议更灵活。用CBT路由协议构造的树总是组共享广播树(group-shared tree)，而使用PIM-SM协议构造广播树时既可构造组共享树，也可构造最短路径树(shortest-path tree)。
共享广播树比较容易构造，而且也减少了必需存储在路由器中的状态信息数。因此，如果多目标广播组是由大量的低数据率广播源组成，共享广播树应该可节省网络资源。然而，共享广播树会导致交通集中在核心路由器上或者在会合点上，当有大量的多目标广播交通出现时就会使用服务质量减低。共享广播树的另一个缺点是交通经常不能在最短路径上通行，如果多媒体网络应用对时延的要求很小，多目标广播交通就更需要在最短的路径上通行。PIM-SM的体系结构支持共享广播树和最短路径广播树。
PIM-SM协议最初构造一棵组共享广播树(group-shared tree)以支持多目标广播组，这是通过发送端(广播源)和接收端都连接到会合点来建立的，就像用CBT协议围绕核心树构造一棵共享树一样。在这种广播树建立之后路由器可向广播源发送一个PIM加入消息(PIM join message)，目的是把接收端与广播源的连接改接到最短路径树上，从广播源到接收端的最短路径一旦建立，通过会合点的无关分支就可以剪除，这个过程可用图19-11说明。此外，在单个多目标广播组中，对不同的广播源也可以选择不同类型的广播树。
图19-11 协议独立多目标广播-稀疏型广播树的构造过程[1]
协议独立多目标广播-稀疏型广播树的构造步骤如下：
① 广播源2( Source 2)在会合点上的多目标广播路由器RPt处登记。
② 接收端加入路由器RPt；现在是一个比较大的共享树。
③ 接收端接收来自广播源2的数据，然后发送一个明确的加入消息到广播源2，这样就构造了一条最短的路径。
19.5.4 协同工作不同类型的路由协议能够相互协同工作是人们所渴望的。现在有两种类型的协同工作需要考虑，一种是现存的单目标广播路由器和正在出现的具有多目标广播功能的路由器之间的协同工作，另一种是各种多目标广播路由方法之间的协同工作。
第一种类型的协同工作已经有应用实例。例如，DVMRP现在已经用在MBone上多目标广播的路径安排，使用一种方法来连接因特网上的“岛屿”。这种方法是使用IP单目标广播数据包改装(IP tunneling)技术来封装多目标广播数据包，这些岛屿是指具有多目标广播功能但被不支持IP多目标广播的链路所分隔的子网。此外，MOSPF设计在OSPF版本2的顶部，这样就可以把多目标广播的功能引入到OSPF版本2的路径选择域中。
第二种协同工作的问题PIM的设计人员正在忙于解决。既要解决在PIM-DM和PIM-SM之间能够协同工作，又要解决在PIM与其他多目标广播路径结构之间的协同工作。在密集型和稀疏型协议之间有一个基本的协同工作问题，密集型靠数据驱动来建立广播树，而稀疏型则依赖明确的加入请求来建立广播树。如果密集型广播组要与稀疏型广播组协同工作，例如要生成一个组，这个组稀疏地分布在广域网络上但密集地分布在单个子网上，这就必需要有一种机制，允许这个密集型组到达稀疏型组请求加入多目标广播。PIM设计人员提出的解决方案是让“边界路由器(border routers)”发送明确的加入信息到稀疏组。使用同样的方法也应该能够使PIM-SM与其他密集型协议协同工作，例如距离矢量多目标路由协议(Distance Vector Multicast Routing Protocol，DVMRP)。
19.6 实时传输协议和实时控制协议因特网一直主要用来提供可靠的数据传送服务，对数据的时延几乎没有什么限制。TCP/IP协议就是为这种类型的交通设计的，而且工作得很好。然而，像多目标广播这样的多媒体应用却具有不同的特性，因此就需要不同的协议来提供所需要的服务。例如，如果你在接收来自因特网的声音、电视或者要求时延很小的其他数据时，使用TCP/IP在实时播放过程中就可能会产生抖动或者是不能接受的抖动，使声音或者电视的质量明显下降。现在已经开发了并且继续开发许多协议来加强因特网的体系结构，从而改善像声音广播，电视广播和交换多媒体会议的应用。实时传输协议(Real-time Transport Protocol，RTP)，实时控制协议(Real-time Control Protocol，RTCP),资源保留协议(Resource Reservation Protocol，RSVP)和实时流放协议(Real-time Streaming Protocol，RTSP)就是为实时多媒体在网络上的应用而开发的协议。
19.6.1 RTP简介
RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。
RTP定义在RFC 1889中。信息包的结构包含广泛用于多媒体的若干个域，包括声音点播(audio-on-demand)、影视点播(video on demand)、因特网电话(Internet telephony)和电视会议(videoconferencing)。RTP的规格没有对声音和电视的压缩格式制定标准，它可以被用来传输普通格式的文件。例如，WAV或者GSM(Global System for Mobile communications)格式的声音、MPEG-1和MPEG-2的电视，也可以用来传输专有格式存储的声音和电视文件。
使用RTP协议的应用程序运行在RTP之上，而执行RTP的程序运行在UDP的上层，目的是为了使用UDP的端口号和检查和。如图19-12所示，RTP可以看成是传输层的子层。由多媒体应用程序生成的声音和电视数据块被封装在RTP信息包中，每个RTP信息包被封装在UDP消息段中，然后再封装在IP数据包中。
TCP/IP模型
应用层(application)
传输层
RTP
UDP
IP
数据链路层(data link)
物理层(physical)
图19-12 RTP是传输层上的协议
从应用开发人员的角度来看，可把RTP执行程序看成是应用程序的一部分，因为开发人员必需把RTP集成到应用程序中。在发送端，开发人员必需把执行RTP协议的程序写入到创建RTP信息包的应用程序中，然后应用程序把RTP信息包发送到UDP的套接接口(socket interface)，如图19-13所示；同样，在接收端，RTP信息包通过UDP套接接口输入到应用程序，因此开发人员必需把执行RTP协议的程序写入到从RTP信息包中抽出媒体数据的应用程序。
TCP/IP模型
应用层(application)
RTP
套接接口
UDP
IP
数据链路层(data link)
物理层(physical)
图19-13 RTP和UDP之间的接口
现以用RTP传输声音为例来说明它的工作过程。假设音源的声音是64 kb/s的PCM编码声音，并假设应用程序取20毫秒的编码数据为一个数据块(chunk)，即在一个数据块中有160个字节的声音数据。应用程序需要为这块声音数据添加RTP标题生成RTP信息包，这个标题包括声音数据的类型、顺序号和时间戳。然后RTP信息包被送到UDP套接接口，在那里再被封装在UDP信息包中。在接收端，应用程序从套接接口处接收RTP信息包，并从RTP信息包中抽出声音数据块，然后使用RTP信息包的标题域中的信息正确地译码和播放声音。
如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳，而是使用标准的RTP协议，应用程序就更容易与其他的网络应用程序配合运行，这是大家都希望的事情。例如，如果有两个不同的公司都在开发因特网电话软件，他们都把RTP合并到他们的产品中，这样就有希望：使用不同公司电话软件的用户之间能够进行通信。
这里需要强调的是，RTP本身不提供任何机制来确保把数据及时递送到接收端或者确保其他的服务质量，它也不担保在递送过程中不丢失信息包或者防止信息包的次序不被打乱。的确，RTP的封装只是在系统端才能看到，中间的路由器并不区分那个IP数据报是运载RTP信息包的。
RTP允许给每个媒体源分配一个单独的RTP信息包流，例如，摄像机或者麦克风。例如，有两个团体参与的电视会议，这就可能打开4个信息包流：两台摄像机传送电视流和两个麦克风传送声音流。然而，许多流行的编码技术，包括MPEG-1和MPEG-2在编码过程中都把声音和电视图像捆绑在一起以形成单一的数据流，一个方向就生成一个RTP信息包流。
RTP信息包没有被限制只可应用于单目标广播，它们也可以在一对多(one-to-many)的多目标广播树或者在多对多(many-to-many)的多目标广播树上传送。例如，多对多的多目标广播，在这种应用场合下，所有发送端通常都把他们的RTP信息包流发送到具有相同多目标广播地址的多目标广播树上。
19.6.2 RTP信息包标题域
RTP标题由4个信息包标题域和其他域组成：有效载荷类型(payload type)域，顺序号(sequence number)域，时间戳(timestamp)域和同步源标识符(Synchronization Source Identifier)域等。RTP信息包的标题域的结构如图19-14所示：
Payload
Type
(有效载荷类型)
Sequence Number
(顺序号)
Timestamp
(时间戳)
Synchronization Source Identifier
(同步源标识符)
Miscellaneous Fields
(其他)
图19-14 RTP信息包的标题域
1,有效载荷类型
RTP信息包中的有效载荷域(Payload Type Field)的长度为7位，因此RTP可支持128种不同的有效载荷类型。对于声音流，这个域用来指示声音使用的编码类型，例如PCM、自适应增量调制或线性预测编码等等。如果发送端在会话或者广播的中途决定改变编码方法，发送端可通过这个域来通知接收端。表19-01列出了目前RTP所能支持的声音有效载荷类型。
表19-01 目前RTP所能支持的声音有效载荷类型有效载荷号
声音类型
采样率(kHz)
数据率(kb/s)
0
PCM mu-law
8
64
1
1016
8
4.8
2
G.721
8
32
3
GSM
8
32
6
DVI
16
64
7
LPC
8
2.4
9
G.722
8
48～64
14
MPEG Audio
90
-
15
G.728
8
16
对电视流，有效载荷类型可以用来指示电视编码的类型，例如motion JPEG,MPEG-1，MPEG-2或者H.231等等。发送端也可以在会话或者期间随时改变电视的编码方法。表19-02列出了目前RTP所能支持的某些电视有效载荷类型。
表19-02 目前RTP所能支持的声音有效载荷类型有效载荷号
电视格式
26
Motion JPEG
28
-
31
H.261
32
MPEG-1 video
33
MPEG-2 video
2,顺序号顺序号(Sequence Number Field)域的长度为16位。每发送一个RTP信息包顺序号就加1，接收端可以用它来检查信息包是否有丢失以及按顺序号处理信息包。例如，接收端的应用程序接收到一个RTP信息包流，这个RTP信息包在顺序号86和89之间有一个间隔，接收端就知道信息包87和88已经丢失，并且采取措施来处理丢失的数据。
3,时间戳时间戳(Timestamp)域的长度为32字节。它反映RTP数据信息包中第一个字节的采样时刻(时间)。接收端可以利用这个时间戳来去除由网络引起的信息包的抖动，并且在接收端为播放提供同步功能。
4,同步源标识符
同步源标识符(Synchronization Source Identifier，SSRC)域的长度为32位。它用来标识RTP信息包流的起源，在RTP会话或者期间的每个信息包流都有一个清楚的SSRC。SSRC不是发送端的IP地址，而是在新的信息包流开始时源端随机分配的一个号码。
19.6.3 实时传输控制协议实时传输控制协议(Real-time Control Protocol，RTCP)也定义在1996年提出的RFC 1889中。多媒体网络应用把RTCP和RTP一起使用，尤其是在多目标广播中更具吸引力。当从一个或者多个发送端向多个接收端广播声音或者电视时，也就是在RTP会话期间，每个参与者周期性地向所有其他参与者发送RTCP控制信息包，如图19-15所示。RTCP用来监视服务质量和传送有关与会者的信息。对于RTP会话或者广播，通常使用单个多目标广播地址，属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址，通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。
图19-15 每个参与者周期性地发送RTCP控制信息包
RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据，而是封装发送端和/或者接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息对发送端、接收端或者网络管理员都是很有用的。RTCP规格没有指定应用程序应该使用这个反馈信息做什么，这完全取决于应用程序开发人员。例如，发送端可以根据反馈信息来修改传输速率，接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的，网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。
19.6.4 实时流放协议实时流放协议(Real-Time Streaming Protocol，RTSP)是一个刚开始开发的协议，它的设想描述在RFC 2326文件中。RTSP是应用级的实时流放协议，它主要目标是为单目标广播和多目标广播上的流式多媒体应用提供牢靠的播放性能，以及支持不同厂家提供的客户机和服务机之间的协同工作能力。
播放的数据流被分成许多信息包，信息包的大小很适用于客户机和服务器之间的带宽。当客户机已经接收到足够多的信息包之后，用户软件就可开始播放一个信息包，同时对另一个信息包解压缩和接收第三个信息包。这样用户就不需要把整个媒体文件从服务器上下载之后就可立即播放。广播源可以是现场的数据流也可以是存储的数据流。
RTSP协议想要提供控制多种应用数据传送的功能，提供一种选择传送通道的方法，例如UDP,TCP,IP多目标广播通道，以及提供一种基于RTP协议的递送方法。正在设计的RTSP将工作在RTP的上层，用来控制和传送实时的内容。
RTSP能够与资源保留协议一起使用，用来设置和管理保留带宽的流式会话或者广播。
19.7 资源保留协议当前因特网主要是为IP数据报提供最佳服务，而对吞吐率和时延不提供任何担保。为了改善声音和电视质量，这就非常渴望能够在因特网上为多媒体网络应用提供服务质量(quality of service，QoS) 有保证的服务。但是QoS保证需要一种机制，这种机制允许应用程序保留因特网上的资源。而新的因特网标准——资源保留协议(Resource Reservation Protocol，RSVP)就是一个允许应用程序保留资源的一种标准，它定义在RFC 2205中。
随便要指出的一点的是，当人们谈论因特网资源时，通常是指链路带宽和路由器的缓存。为了使谈论的内容更集中，本章假设“资源”这个词就是带宽的同义词，而RSVP则代表带宽保留协议(Bandwidth Reservation Protocol)。
19.7.1 RSVP协议简介执行RTCP协议的软件可用来提供服务质量的反馈信息，但仅用这个协议还不够，还须要有其他协议来为收发两端之间的会话或者广播及时传送数据和保证服务质量。资源保留设置协议RSVP就是为保证服务质量而开发的一种协议。
RSVP协议允许应用程序为它们的数据流保留带宽。主机根据数据流的特性使用这个协议向网络请求保留一个特定量的带宽，路由器也使用RSVP协议转发带宽请求。为了执行RSVP协议，在接收端、发送端和路由器中都必需要有执行RSVP协议的软件。RSVP的两个主要特性是：
① 保留多目标广播树上的带宽，单目标广播是一个特殊情况。
② 接收端导向，也就是接收端启动和维护资源的保留。
这两个特性可用图19-16说明。该图表示的是一个多目标广播树(multicast tree)，它的数据流向是从树的顶部到6个主机。虽然数据源来自发送端，但保留消息(reservation message)则发自接收端。当路由器向上给发送端转发保留消息时，路由器可以合并来自下面的保留消息。
图19-16 RSVP的特性
须要指出，RSVP标准没有指定网络如何为数据流保留资源，这个协议仅是允许应用程序提出保留必要的链路带宽的一个协议 。一旦提出要求保留资源，实际上是因特网上的路由器来为数据流保留带宽，让路由器接口来维护途经这个接口的各种数据流信息包。
19.7.2 不同种类的接收器我们知道，接入因特网的用户是多种多样的，有的使用28.8 kb/s速率接收数据，有的使用128 kb/s速率接收数据，而有的使用10 Mb/s甚至更高的速率接收数据。这里就出现一个问题，向这些接收数据速率不同的用户广播时，发送端到底应该使用什么样的数据流速率对外广播，使用28.8 kb/s还是使用10 Mb/s？如果使用28.8 kb/s广播，使用10 Mb/s的用户就可能会嫌质量太低；如果使用10 Mb/s广播，使用28.8 kb/s的用户就接收不到广播。
解决这个问题的一种方案是对声音或电视进行分层编码，每层的声音或电视的数据速率各不相同，以此来满足各种不同用户的要求。在广播时，发送端并不一定要知道接收端的数据接收速率，而只需要知道这些用户中使用的最大数据接收速率即可。发送端对声音或电视进行分层编码，并且把它们发送到广播树上，用户就根据自己的实际速率接收不同质量的广播。
[例19.1] 多目标实况广播假设有一场体育比赛要在因特网上进行实况转播，多目标广播地址已经在因特网上事先发布，并且假设从发送端到接收端的多目标广播树已经确立，如图19-17所示。此外，每个接收端的数据接收速率已经在图19-17上表示出，而且电视数据是按照接收端数据接收速率进行分层编码的。
图19-17 多目标实况广播举例
RSVP的工作过程大致如下。每个接收端逆向发送一个资源保留消息到多目标广播树，这个消息说明了接收端接收广播源的数据速率。当保留消息到达一个路由器时，路由器就调整它的信息包调度程序来保留带宽，然后把这个消息送到上游路由器。路由器逆向保留的带宽数量是根据下流的保留带宽的数量来确定的。在本例中，接收端R1，R2，R3和R4分别保留20 kb/s,120 kb/s,3 Mb/s和3 Mb/s，因此路由器D下面的接收端请求的最大速率为3 Mb/s。路由器D把保留消息发送给路由器B，请求路由器B在这两个路由器之间的链路上保留3 Mb/s的带宽，因为R3和R4观看同一个广播，因此不需要保留6 Mb/s的带宽。依此类推，路由器C请求路由器B在路由器B和路由器C之间的链路上保留100 kb/s的带宽。分层编码的数据流保证接收端R1的20 kb/s的数据流包含在100 kb/s数据流中。一旦路由器B接收到来自下面的路由器的保留消息之后就递送给它的调度程序，然后把新的保留消息递送给上一层的路由器A。这个消息要求在从路由器A到路由器B的链路上保留3 Mb/s的带宽，这是接收端要求保留的最大带宽。
从上面的分析可以看到，RSVP是接收端导向(receiver-oriented)的协议，也就是由接收数据流的终端提出资源保留请求。我们也注意到，每个路由器接收到的消息依次是从多目标广播树上的下流链路上发送来的，而且只有一个带宽保留消息。
[例19.2] 4人电视会议假设每人在自己的计算机屏幕上开有3个窗口观看其他3人的情况，按照路由协议在4台计算机之间建立多目标广播树，他们都使用3 Mb/s的速率来接收电视，如图19-18所示。在这个多目标广播树上的每条链路上，RSVP就要在一个方向保留9 Mb/s的带宽，而在其他方向上保留3 Mb/s的带宽。在这个例子中，RSVP不合并保留带宽，因为每个人都想接收来自其他3台计算机的数据流。
图19-18 4人电视会议
19.7.3 接纳测试由于路由器在链路上保留的带宽的数量不能超过链路本身的能力，因此每当路由器接收一个新的保留消息时，它必需首先判断多目标广播树上的下流链路是否可以容纳，这个过程称为接纳测试(admission test)。如果接纳测试失败，路由器就拒绝保留带宽，并且给请求保留带宽的接收端发送一个错误消息。
RSVP不定义和执行容纳测试，而是由路由器来承担这种测试。
19.7.4 路径消息前面我们只讨论了RSVP的带宽保留消息，这是从接收端发出并向发送端递送的带宽保留消息。另一个重要的RSVP消息叫做路径消息(RSVP path messages )，它与RSVP保留消息(RSVP reservation messages)相反，是从发送端发出并向接收端发送的消息。
发送路径消息的主要目的是要让路由器知道在那些链路上应该转发保留消息，尤其是在多目标广播树中从路由器A到路由器B发出的路径消息，这个消息中包含有路由器A的单目标广播IP地址。路由器B把这个地址放在路径状态表(path-state table)中，当它从下流节点接收到保留消息时，它就访问这张路径状态表，从而得知它应该向路由器A发送一个带宽保留消息。
路径消息也包含发送端的交通特性，它定义发送端将要生成的数据流的特性，这个消息可以用来预防带宽保留过多。
练习与思考题什么叫做单目标广播(unicast)和多目标广播(multicast)？什么叫做网际多目标广播(IP Multicast)？
多目标广播使用哪类地址？
对有兴趣的读者，试阅读并比较下列两个协议：
① 1997年的RFC 2236：B,Fenner,"Internet Group Management Protocol,Version 2".
② 1989年的RFC 1112：S,Deering,"Host extensions for IP multicasting"
对有兴趣的读者，阅读声音-电视传输工作组(Audio-Video Transport Working Group)编写的实时传输协议RTP和实时传输控制协议RTCP文件：
RFC 1889：H,Schulzrinne,S,Casner,R,Frederick,V,Jacobson,"RTP,A Transport Protocol for Real-Time Applications",01/25/1996.
并写出摘要。
参考文献和站点
http://www.ipmulticast.com (浏览日期：1999.1)
① Vicki Johnson and Marjory Johnson，How IP Multicast Works，1997
② Vicki Johnson and Marjory Johnson，IP Multicast Backgrounder，1997
③ Vicki Johnson and Marjory Johnson，Higher Level Protocols used with IP Multicast，1997
RFC 2435：L,Berc,B,Fenner,R,Frederick,S,McCanne,P,Stewart,"RTP Payload Format for JPEG-compressed Video",10/15/1998,(Obsoletes RFC2035)
RFC 2432：K,Dubray,"Terminology for IP Multicast Benchmarking",10/12/1998
RFC 2375：S,Deering,B,Hinden,"IPv6 Multicast Address Assignments",07/20/1998
RFC 2365：D,Meyer,"Administratively Scoped IP Multicast",07/02/1998
RFC 2337：D,Farinacci,D,Meyer,Y,Rekhter,"Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM",05/01/1998
RFC 2327：M,Handley,V,Jacobson,"SDP,Session Description Protocol",04/14/1998
RFC 2326：R,Lanphier,A,Rao,H,Schulzrinne,"Real Time Streaming Protocol (RTSP)",04/14/1998
RFC 2326：R,Lanphier,A,Rao,H,Schulzrinne,"Real Time Streaming Protocol (RTSP)",04/14/1998
RFC 2236：B,Fenner,"Internet Group Management Protocol,Version 2",11/11/1997,(Updates RFC1112)
RFC 2205：B,Braden,L,Zhang,S,Berson,S,Herzog,S,Jamin,"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification",10/01/1997
RFC 2201：T,Ballardie,"Core Based Trees (CBT) Multicast Routing Architecture",09/25/1997
RFC 2189：T,Ballardie,"Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --",09/25/1997
RFC 2147：D,Borman,"TCP and UDP over IPv6 Jumbograms",05/23/1997,(Updates RFC1883)
RFC 2090：A,Emberson,"TFTP Multicast Option",02/04/1997
RFC 1890：H,Schulzrinne,"RTP Profile for Audio and Video Conferences with Minimal Control",01/25/1996
RFC 1889：H,Schulzrinne,S,Casner,R,Frederick,V,Jacobson,"RTP,A Transport Protocol for Real-Time Applications",01/25/1996
RFC 1700：J,Reynolds,J,Postel,"ASSIGNED NUMBERS",10/20/1994,(Obsoletes RFC1340) (STD 2)
RFC 1587：R,Coltun,V,Fuller,"The OSPF NSSA Option",03/24/1994
RFC 1585：J,Moy,"MOSPF,Analysis and Experience",03/24/1994
RFC 1584：J,Moy,"Multicast Extensions to OSPF",03/24/1994
RFC 1469：T,Pusateri,"IP Multicast over Token-Ring Local Area Networks",06/17/1993
RFC 1458：R,Braudes,"Requirements for Multicast Protocols",05/26/1993.
RFC 1323：D,Borman,B,Braden,V,Jacobson,"TCP Extensions for High Performance",05/13/1992,(Obsoletes RFC1072) (Obsoletes RFC1185)
RFC 1301：A,Freier,"Multicast Transport Protocol",02/19/1992
RFC 1112：S,Deering,"Host extensions for IP multicasting",08/01/1989,(Obsoletes RFC1054) (Obsoletes RFC988) (Updated by RFC2236) (STD 5)
RFC 1075：S,Deering,C,Partridge,D,Waitzman,"Distance Vector Multicast Routing Protocol",11/01/1988
RFC 791：J,Postel,"Internet Protocol",09/01/1981,(Obsoletes RFC760) (Obsoleted by RFC1060)
***************************************************************************
19.1 多目标广播的概念
19.2 多目标广播所需要的环境
19.3 多目标广播树的概念
19.4 IP多目标广播的地址和主机组的管理
19.4.1 IP多目标广播的地址
19.4.2 网际主机组管理协议
14.4.3 接收端如何参与多目标广播
19.5 多目标广播路径选择简介
19.5.1 两种基本的路径选择法
19.5.2 密集型多目标广播路由协议
19.5.3 稀疏型多目标广播路由协议
19.5.4 协同工作
19.6 实时传输协议和实时控制协议
19.6.1 RTP简介
19.6.2 RTP信息包标题域
19.6.3 实时传输控制协议
19.6.4 实时流放协议
19.7 资源保留协议
19.7.1 RSVP协议简介
19.7.2 不同种类的接收器
19.7.3 接纳测试
19.7.4 路径消息练习与思考题参考文献和站点
***************************************************************************
进入20世纪90年代之后，组合声音、电视和数据流的多媒体网络应用的开发和研究迅速增加，近年来也不断有产品投入市场，用户也渴望得到服务质量好、服务费用低的产品，像电视会议、协同工作、远程教学、可视电话等等的多媒体网络应用都是非常受欢迎的应用。这些应用都是实时的交互应用，而且即使采用了很好的压缩技术，传输多媒体数据所需要的带宽也是巨大的。在实现这些令人兴奋的应用中，正在开发的网际多目标广播(IP multicast)技术将会并且正在起着越来越重要的作用。使用多目标广播技术不仅可以节省宝贵的网络资源(主要是带宽)和服务器资源，而且可以保证服务质量。
如同因特网上的其他应用技术一样，多目标广播的核心技术体现在各种各样的协议上。协议是技术的精华，是人类智慧的结晶。如果不带着问题去阅读协议是很枯燥的，如果要开发产品就要了解协议的思想，就要深入研究协议的细节，如果没有协议可遵循就自己制定和提交新的协议，让大家使用你提出的协议。为此，编者从2500多个RFC文件中挑选了与多目标广播关系最密切的RFC文件，列在本章的“参考文献和站点”中供感兴趣的读者进一步研究。
19.1 多目标广播的概念假设世界上有许多用户想在因特网上接收现场电视节目(例如现场体育比赛)，如何把它传送到世界各地？最直观的方法就是使用传统的IP寻址方法，每个信息包都使用一个唯一的IP地址，一次只给一个节点(即主机)传送，如图19-01所示，这种方法称为单目标传送(unicast)。如果使用单目标广播服务把相同内容的信息传输给N个目标站点，就须要传输N个拷贝，即要传输N次。
图19-01 单目标广播服务
使用这种方法有下列缺点：①浪费链路带宽，因为在链路上要传送多个相同的拷贝，②大大地加重了服务机的负担。一个比较好的方法是把消息一次性地同时传输给N个目标站点，如图19-02所示，这就叫做多目标广播(multicasting)，在因特网上广播就称为IP多目标广播(IP multicast)或者叫做网际多目标广播。
图19-02 多目标广播服务
多目标广播是真正的分布式信息传输服务，使用IP多目标广播可以大大减轻网络上出现的拥挤和服务器的负担，因此可用于声音和影视的实时广播，例如，因特网电话会议，因特网电视会议。
研究表明，要满足多目标广播的要求，只须在IP协议中增加支持多目标广播的路径安排(multicast routing)功能就可以。IP多目标广播路由协议(IP Multicast routing protocol)比较好地满足了在IP网络上实现多目标广播的功能。
19.2 多目标广播所需要的环境为支持IP多目标广播，发送端和接收端以及收发两端之间的网络设施都必需具备多目标广播功能，包括中间的路由器。对本地的IP多目标广播，主机节点所需要的环境是：
TCP/IP协议堆中可支持IP多目标广播。
软件支持网际主机组管理协议(Internet Group Management Protocol，IGMP)，这样就可以申请参加多目标广播组(multicast group)和接收多目标广播。
要有IP多目标广播应用软件，例如电视会议软件。
在LAN网络上运行或者评估多目标广播，只需要以上的环境就满足。在这个环境下，不需要路由器来为主机的适配器创建或者加入多目标广播组就可以与其他主机共享多目标广播数据。
在WAN网络上运行或者评估多目标广播就还需要：
在接收两端之间的所有路由器都具备多目标广播的功能。许多新的路由器都有这个功能，老的路由器也许需要升级和更新。
也许要能识别防火墙以便使多目标广播畅通。
多目标广播得到工业界的广泛支持，现在也有许多网络基础设施厂商提供支持多目标广播的软硬件，如路由器、交换机、TCP/IP堆、网络接口卡、桌面计算机操作系统和应用软件。
图19-03描述了运行多目标广播必需要有的部件。图中的交通方向是多目标广播数据包的方向，需要与主机组成员进行通信的消息和传输路径消息没有在图上表示。
图19-03 网际多目标广播环境[1]
19.3 多目标广播树的概念为了便于说明多目标广播技术中的问题，我们引入多目标广播树(multicast tree)或者叫做多目标广播跨越树(multicast spanning tree)的概念，用它来描述服务机(播送机)和接收机之间构成的播放与接收关系。服务机只向外传送一个信息包流，每当信息包到达多目标广播树中有多个分支的路由器时，路由器就为每个分支复制一个信息包。这样就减轻了服务机的负担，更有效地利用了网络资源。
图19-04说明多目标广播树的概念。图中S表示多目标广播的源端主机，R表示参加多目标广播的终端主机，MR(multicast-enabled router)表示具有多目标广播功能的路由器。注意，IP子网中有一处没有主机，表示对多目标广播没有任何兴趣的站点。
图19-04 多目标广播树的概念
网络将使用路由协议建立从源端到所有希望参加会话的接收端之间的多目标树，图19-05说明这种树的结构。网络建立多目标广播树的过程如下：
广播源把数据或者广播通知发送给所有路由器。
不想参加多目标广播的终端逆向发送一个删除消息。
删除没有成员的分支和不在最短路径树上的分支。
在广播源生成最短路径树。
使用联结和删除功能改变成员之间的关系现在至少有三种多目标广播路由协议：
距离矢量多目标路由协议(Distance Vector Multicast Routing Protocol，DVMRP)。
多目标广播开放最短路径优先协议(Multicast Open Shortest Path First，MOSPF)。
协议独立多目标广播(Protocol Independent Multicasting，PIM)。
图19-05 多目标广播树结构
19.4 IP多目标广播的地址和主机组的管理
19.4.1 IP多目标广播的地址大多数高层网络协议(high-level network protocol)，例如传输控制协议(Transfer Control Protocol，TCP)和用户数据包协议(User Datagram Protocol，UDP)仅提供单目标广播(unicast)传送服务，不能满足多目标广播的要求。为了提高网络资源的利用率和提高服务质量，1989年由施乐公司(Xerox)在帕洛阿尔托研究中心(Palo Alto Research Center，PARC)的Steve Deering提出了一种解决方案，就是使用IP地址中的D类地址来实现IP多目标广播(IP-Multicast)。这个解决方案是以RFC 1112的形式公布的。为了探索多目标广播的应用，1992年3月因特网工程特别工作组(Internet Engineering Task Force，IETF)召开的会议上采纳了一种称为“多目标广播骨干网MBone”的试验方案，1993年7月正式命名为MBone，是一种可在全球范围内传输电视的网络。
在因特网上多目标广播的广播源分散在世界各地，加入某一广播的所有计算机构成一个计算机组，称为主机组(host group)。一个主机组的成员是随时变动的，一台主机可以随时加入或者退出主机组，主机组成员的数目和所在的地理位置也不受限制，一台主机也可以属于几个主机组。IP多目标广播使用D类IP地址(Class D Internet Protocol addresses)，它的最高4位为1110就是用来指定多目标广播主机组群(multicast host groups)的地址。在网际协议地址(IP地址)的“点十进制”记法中，主机组的地址范围从224.0.0.0到239.255.255.255。主机组的地址划分为两种类型，一种称为永久性地址，另一种称为暂时性地址。地址的分配由因特网号码分配局(Internet Assigned Numbers Authority，IANA)掌握。例如，永久地址224.0.0.1称为“所有主机组(all-hosts group)”地址，它是用来与直接连接到网络上的所有IP多目标广播主机组进行通信的地址，而244.0.0.2是与LAN上的所有路由器进行通信的地址。244.0.0.0到244.0.0.255是为路由协议和其他用途保留的地址。其他的地址和地址范围用于应用软件，例如，244.0.13.000到244.0.13.255用于网络新闻(Net News)，这些保留的IP多目标广播地址列在RFC 1700中。广播发布或者叫做会话发布协议(Session Announcement Protocol)和会话说明协议(Session Description Protocol)—— RFC 2327草案描述了如何创建和检测MBone的会话地址/端口的分配。
发送给多目标广播主机组所有成员的数据包称为IP多目标广播数据包(IP Multicast Datagram)，这种数据包与单目标广播IP数据包相同。要发送IP多目标广播数据包时，发送端指定一个代表主机组的目标地址，使用与发送单目标数据包一样的操作“Send IP”来发送多目标广播数据包。
与发送IP多目标广播数据包比较，接收IP多目标广播数据包要复杂得多，尤其是在WAN上。为了接收数据包，用户主机上的应用软件需要在多目标广播主机组中申请成员资格。申请成员资格要与LAN上的路由器通信，如果需要的话还要与发送端和接收端之间的中间路由器进行通信。有了成员资格之后，接收端主机上的网络接口卡就可开始筛选具体的LAN网络硬件(数据链路层)的地址，这个地址是与新的多目标广播组地址相关联的。WAN路由器把请求的多目标广播数据包递送到LAN路由器，LAN路由器把接收端的主机地址转换成相关的硬件地址，然后使用这个地址创建消息(例如，以太网帧)。正在注意这些地址的接收主机的网络接口卡和网络驱动程序就把多目标广播消息传输给TCP/IP协议堆，由协议堆把广播消息变成用户应用程序的输入，例如电视播放器。
19.4.2 网际主机组管理协议如果LAN上多目标广播组的成员要接收来自远距离广播源的广播，多目标广播信息包就必需要通过路由器转发到LAN网上。多目标广播路由器通过使用网际主机组管理协议(Internet Group Management Protocol，IGMP)来查明直接附加到子网的主机组成员是否存在，它发送一个IGMP查询消息以获得主机组成员的情况。IGMP的详细内容可参看RFC 1112和RFC 2236。
网际主机组管理协议IGMP在IP上的执行过程与网际控制消息协议(Internet Control Messages Protocol，ICMP)的执行过程类似。IGMP消息封装在IP数据包(IP datagram)中，而数据包有两种类型：主机成员查询(Host Membership Query)数据包和主机成员报告(Host Membership Report)数据包，它们具有相同的如下固定格式。
Version
(bits 0-3)
Type
(bits 4-7)
Code
(bits 8-15)
Checksum
(bits 16-31)
Multicast Group Address (Class D)
为了确定在局域子网上的任何一台主机是否属于多目标广播组，每个子网上的路由器要周期性地向LAN上的所有终端主机发送一个主机成员查询(Host Membership Query)信息，要求它们汇报主机组群成员的情况。这个查询被送到所有主机组(网络地址＝224.0.0.1)，而每台主机都回送一个主机成员报告(Host Membership Report)信息，如图19-06所示，这样就可确定子网上的主机是否加入多目标广播组，从而确定是否要把多目标数据包送到这个子网。
图19-06 在LAN内的网际主机组成员协议(IGMP)消息[1]
19.4.3 接收端如何参与多目标广播多目标广播会话消息经常通过因特网广告通知接收端。广告使用应用层的广播会话说明协议(Session Description Protocol，SDP)来发布。这个协议发送广告的地址是224.2.2.2，UDP端口号是4000，这是一个特殊的多目标广播会话。发送的广告内容包括广播的名称、广播时间(active times)、媒体的类型(声音、电视、白板等等)和广播地址。任何有兴趣了解多目标广播的主机都可以参加这个特殊的多目标广播会话和接收这种广告。可用一台主机运行用户代理来收集广告并把广告摘要用图形方式向用户显示。第一个这样的用户代理叫做会话目录(Session Directory，SD)，是由LBL(Lawrence Berkeley Laboratories )的Van Jacobson开发的，它除了显示公告之外，也启动多目标应用程序和为任何一个新的多目标广播会话选择一个地址。
如何给多目标广播分配地址？当源端开始一个新的多目标广播时，SD就从多目标地址空间中随机地选择一个多目标广播地址。参加多目标广播的主机需要做两件事：①要立即给最近的路由器发送一个消息，告诉它参加多目标广播，发送这个消息是使用应用层的一个叫做网际主机组管理协议IGMP。②要设置IP进程去接收IP数据包，因为它在IP目标地址域中含有会话的多目标广播地址，当接收端退出多目标广播会话时，类似的进程也要设置。
19.5 多目标广播路径选择简介
19.5.1 两种基本的路径选择法多目标广播是从广播源向目标组连续发送信息的过程。多目标广播交通是经由跨越树(spanning tree)从广播源传送到机组中的所有接收主机。不同的IP多目标广播路由协议使用不同的技术来构造多目标广播跨越树(multicast spanning tree)。跨越树一经构造，多目标广播交通就在跨越树上穿越。
根据多目标广播组成员在整个网络上预期的分布情况，IP多目标广播路由选择(IP Multicast Routing)协议通常遵循下述两种基本假设来制定：
(1) 多目标广播组成员密布在整个网络上，也就是许多子网至少包含一个成员，并且带宽很充裕。根据这种假设制定的协议叫做密集型多目标广播路由协议(dense-mode multicast routing protocols)，它是依靠一种称为“流放(flooding)”技术来把信息传播到网络上的所有路由器。这个协议包含距离矢量多目标广播路由协议(Distance Vector Multicast Routing Protocol，DVMRP)、多目标广播开放式最短路径优先(Multicast Open Shortest Path First，MOSPF)协议和协议独立的多目标广播-密集型(Protocol-Independent Multicast - Dense Mode，PIM-DM)路由协议。
(2) 多目标广播组成员稀疏地分布在整个网络，并且未必有充裕的带宽可用。例如，多目标广播组成员跨越因特网上的许多地区就是属于这种情况。根据这种假设制定的协议叫做稀疏型多目标广播路由协议(Sparse-Mode Multicast Routing Protocols)。稀疏型并不意味多目标广播组的成员很少，而仅仅是指散布得很广。在这种情况下使用流放技术会浪费不该浪费的带宽，引起严重的性能问题。稀疏型多目标广播路由协议包括用几个核心路由器构造的核心基干树(Core Based Trees，CBT)协议和协议独立的多目标广播-稀疏型(Protocol-Independent Multicast- Sparse Mode，PIM-SM)路由协议。
19.5.2 密集型多目标广播路由协议
1,距离矢量多目标广播路由协议(DVMRP)
为支持多目标广播路径选择而开发的第一个协议叫做距离矢量多目标广播路由协议(Distance Vector Multicast Routing Protocol，DVMRP)。它已广泛用在MBone网络上，该协议在RFC 1075中有详细的描述。
DVMRP为每一个广播对(广播源和目标主机组)构造不同的广播发送树(distribution tree)。每棵发送树是最小跨越树(spanning tree)，这种树是指从树根上的广播源算起到作为树叶的所有接收多目标广播的主机构成的树。根据信息包在路径上的转发(hop)数，这种发送树提供在广播源到每个接收主机之间的最短路径。当广播源开始给多目标广播组传送信息时，使用“播送和剪除(broadcast and prune)”技术来构造发送树。
为简化对DVMRP的说明，假设网络上的所有路由器都支持DVMRP。DVMRP使用的方法是假设网络上的每台主机都是多目标广播组的一部分，在广播源子网上的路由器，也就是指定用来为子网上所有主机处理路径选择的路由器，首先向所有相邻的路由器传送多目标广播信息，然后每台路由器有选择地把广播信息发送到下游路由器，一直发送到所有多目标广播组的成员。
在生成跨越广播树期间有选择的转发工作过程如下。当路由器接收到一个多目标广播信息时，它就检查它的单目标广播路由表，以便确定返回到广播源的最短路径的接口。如果这个接口就是多目标广播信息到达的最短路径接口，路由器就在它内部的表中登录某些状态信息用来识别多目标广播组，并且把多目标广播消息转发到所有相邻的路由器。这种机制叫做反向路径转发(Reverse Path Forwarding)，它可确保在广播树上没有环路，而且广播树包含的路径(从广播源到所有接收主机之间的路径)是最短路径。这是DVMRP协议的基本部分。
协议中的剪除部分是用来剪除广播树的树枝，就是删除不参加多目标广播组的成员。IGMP协议运行在主机和与它们直接邻接的路由器之间，它用来维护路由器中的组员数据。当路由器确信没有主机属于多目标广播组时就向上游路由器发送一个剪除信息。毫无疑问，路由器也要修改路由表中的状态信息以反映那个分支已从这棵上剪除掉。这个过程一直到所有多余的分支被剪除掉为止。最后得到的是一棵最小跨越广播树。
DVMRP跨越广播树的构造如图19-07所示。一旦构造了跨越广播树，就可以使用它把多目标广播信息从广播源传送到多目标广播组的成员，而沿途上的路由器在通往广播组成员的接口上转发多目标广播信息。由于新的成员可在任何时候加入到广播组，而且由于新成员可能是在某一个被剪除的分支上加入，因此DVMRP就周期性地重新启动跨越广播树的构造进程。
在子网上密布有多目标广播组的情况下，DVMRP工作得很好。但多目标广播组稀疏分布在广域网上的情况下，周期性地广播行为会使网络的性能严重下降。使用DVMRP的另一个问题是，多目标广播路由状态信息的数量问题，因为所有路由器都必需为每个广播组(广播源和接收组)存放状态信息，这些信息是用来转发多目标广播消息的指定接口信息，或者是剪除状态信息，而且这些信息必需要存放在多目标广播路由器中。
图19-07 DVMRP跨越广播树的构造过程[1]
现在回过头来简要说说跨越树的构造过程。按照每个时间单元转发一次消息来划分
① 在第1次转发时，消息到达路由器MR1。
② 在第2次转发时，消息到达路由器MR2、3和4。
③ 在第3次转发时，消息到达路由器MR5、6和8，路由器MR3和4交换消息。
④ 在第4次转发时，消息到达路由器MR7。它认识到这是一个叶子路由器，而且在子网上没有广播组的成员，所以它就回送一个剪除消息给路由器MR6。路由器MR6回送一个剪除消息给路由器MR4。路由器MR3也回送一个剪除消息给路由器MR1。
最后生成的跨越树如图19-08所示。
图19-08 最后生成的跨越广播树[1]
2,多目标广播开放最短路径优先协议(MOSPF)
多目标广播开放最短路径优先协议(Multicast Open Shortest Path First，MOSPF)在RFC 1584中有详细的解释，开放最短路径优先协议(Open Shortest Path First，OSPF)是单目标广播路由协议，在RFC 1587中有详细的解释，它沿着最低成本路径邮递消息，而最低成本则使用链路状态(link-state)来衡量的。除了路径上的转发数之外，可能影响成本的网络性能参数包括：①负荷平衡信息，例如，对通信量小的链路，其成本就比较低，对交通量大的链路，其成本就比较高，这样做是为了平衡网络上的交通；②要求的服务质量，例如，对要求时延低的服务，其成本就比较高，对要求使用卫星链路的服务，其成本就比较高，等等。
MOSPF倾向于用在诸如由单个组织控制的网络上，MOSPF不能脱离OSPF来使用，需要与单目标路由协议联用。在使用OSPF/MOSPF协议的网络中，每个路由器都要维持整个网络的最新布局图，其链路状态信息就用来构造多目标广播树。
每台MOSPF路由器通过网际主机组管理协议(Internet Group Management Protocol，IGMP)周期性地收集多目标广播组成员的信息。这个信息连同上述的链路状态信息一起传送到这个路由域中所有的其他路由器。根据从邻接路由器接收到的信息，路由器将修改它们内部的链路状态信息。由于每个路由器都了解整个网络的布局，因此路由器就使用广播源作为树根、使用广播组的成员作为树叶来独立计算最低成本跨越广播树。由于所有路由器都周期性地共享链路状态信息，因此它们计算得到的广播树将完全相同。然而，由于MOSPF要周期性地在路由器之间传递链路状态信息，因此并不认为MOSPF很适合用于多目标广播。
MOSPF使用Dijkstra算法去计算最短路径树。对每个广播对(广播源和目标组)都要单独计算。为了减少计算量，当路由器接收到数据包流中的第一个数据包时才做这种计算。一旦计算出广播树，就把信息存储起来，为后来的数据包使用。广播树的构造计算过程如图19-09所示。
图19-09 MOSPF树的计算过程[1]
计算步骤如下：
① MR1计算的树：经由IGMP知道组的成员，因此就知道通往MR4的路径要经MR2，通往MR8的路径要经MR5，等等。
② MR2计算的树：确定通往MR4的路径是直接的，通往MR8的路径要经MR5；MR3计算的树：确定通往MR9的路径是直接的。
③ MR5计算的树：确定通往MR8的路径是直接的。
随便提及的是，这个计算过程是由多目标广播传输来激发的，也就是数据驱动(data driven)的方法；每台路由器接收到消息时就计算广播树，并可得到完全相同的广播树，然后使用广播树来转发广播内容。
3,协议独立多目标广播路由协议(PIM)
协议独立多目标广播(Protocol Independent Multicast，PIM)路由协议正在由因特网工程特别工作组(Internet Engineering Task Force，IETF)的一个工作小组开发。现在已有某些路由器产品中支持PIM协议。这个协议的目标是要开发一个标准的多目标广播路由协议，它不依赖于任何特殊的单目标广播路由协议提供的方法，用在因特网上可增减路由域数目的域间多目标广播的行程安排。PIM有两种运行模式：一种是为密集型分布的多目标广播组群，另一种是稀疏型分布的多目标广播组群。第一种方式叫做协议独立多目标广播-密集型(Protocol-Independent Multicast-Dense Mode，PIM-DM)路由协议，将在下面介绍。第二种叫做协议独立型多目标广播-稀疏型(Protocol Independent Multicast - Sparse Mode，PIM-SM)路由协议，将在“19.5.3 稀疏型多目标广播路由协议”中介绍。
协议独立型多目标广播-密集型(PIM-DM)路由协议与距离矢量多目标广播路由协议DVMRP 相类似，它们都使用反向路径多目标广播技术(Reverse Path Multicasting，RPM)来构造以广播源为树根的广播树(source-rooted distribution trees)。DVMRP和PIM-DM之间的主要差别是：PIM完全独立于单目标路由广播协议(unicast routing protocol )，而DVMRP则依赖单目标广播协议的机制，PIM-DM也比DVMRP简单。
PIM-DM是数据驱动型协议，它构造广播树的方法就像所有密集型路由协议(dense-mode routing protocols)那样。然而，由于PIM-DM独立于单目标广播路由协议，因此在最短路径接口上到达路由器的信息包被转发到所有下游接口，一直到达不必要的分岔树枝被剪除为止。如前所述，在构造广播树期间，DVMRP使用单目标广播协议专门提供的拓扑信息来转发消息，因此DVMRP就有更多的挑选余地。而PIM-DM协议的设计人员遵循的哲学是在协议的简单性和协议的独立性方面下功夫，甚至不惜增加信息包的开销。
19.5.3 稀疏型多目标广播路由协议前面介绍的路由协议都是依靠周期性地把消息流放到整个网络。在多目标广播组广泛分布在整个网络区域内或者带宽充裕的区域，使用这种方法是很有效的。但是，如果在因特网上有数千个小型会议同时召开的情况下，所有周期性的流放消息所构成的交通就很可能使因特网不堪承受。很明显，如果组员稀疏地分布在广阔地区，就需要使用不同的方法来使多目标广播交通限制在与组员相连接的链路上，稀疏型多目标广播路由协议(Sparse-Mode Multicast Routing Protocols)就是为此而开发的协议。
密集型需要使用数据驱动(data-driven)方法来构造多目标广播树，而稀疏型协议使用接收器启动(receiver-initiated)的方法来构造多媒体广播树，也就是仅当子网上有主机向特定多目标广播组申请成员资格时，路由器才去构造多目标广播树。下面介绍构造广播树的两种稀疏型多目标广播路由协议。
1,核心基干树(CBT)协议某些多目标广播应用，例如像分布式交互仿真(模拟)和分布式交互电视游戏这类应用，在单个多目标广播组中有很多主动的发送者。不像DVMRP或者MOSPF要为每个广播对(广播源和目标组)构造一个最短路径广播树，核心基干树(Core Based Tree，CBT)协议构造一棵由所有组员共享的树，整个组的多目标广播交通都在这棵相同的树上发送和接收，而不管它们的广播源。使用共享树可以明显节省在路由器中存储的多目标广播状态信息的数量。
一棵CBT共享树以一个路由器为核心来构造广播树，CBT共享树的构造过程如图19-10所示。如果要想加入这棵核心树，路由器就发送一个加入消息(join message)到核心路由器表示它准备加入核心树。当核心路由器接收到加入申请时，核心路由器给它返回一个确认消息，这样就形成一个树的分支。申请加入广播树时，加入消息不需要穿越到达核心路由器的所有线路。如果一个加入消息在到达核心路由器之前命中广播树上的一个路由器，这个路由器就会终止转发加入消息，并且回送一个确认消息，然后它就连接到了共享树上。
图19-10 CBT共享树[1]
某些版本的CBT路由协议支持使用多个核心路由器，因此负载平衡问题也就可以使用多个核心路由器来改善。
2,协议独立多目标广播-稀疏型协议(PIM-SM)
与CBT类似，协议独立多目标广播-稀疏型(Protocol-Independent Multicast - Sparse Mode，PIM-SM)路由协议用来限制多目标广播的交通只通向那些感兴趣接收广播的路由器。PIM-SM围绕一个称为会合点(rendezvous point)的路由器来构造多目标广播树。这个会合点所扮演的角色与CBT协议中的核心路由器所扮演的角色相同，但比CBT协议更灵活。用CBT路由协议构造的树总是组共享广播树(group-shared tree)，而使用PIM-SM协议构造广播树时既可构造组共享树，也可构造最短路径树(shortest-path tree)。
共享广播树比较容易构造，而且也减少了必需存储在路由器中的状态信息数。因此，如果多目标广播组是由大量的低数据率广播源组成，共享广播树应该可节省网络资源。然而，共享广播树会导致交通集中在核心路由器上或者在会合点上，当有大量的多目标广播交通出现时就会使用服务质量减低。共享广播树的另一个缺点是交通经常不能在最短路径上通行，如果多媒体网络应用对时延的要求很小，多目标广播交通就更需要在最短的路径上通行。PIM-SM的体系结构支持共享广播树和最短路径广播树。
PIM-SM协议最初构造一棵组共享广播树(group-shared tree)以支持多目标广播组，这是通过发送端(广播源)和接收端都连接到会合点来建立的，就像用CBT协议围绕核心树构造一棵共享树一样。在这种广播树建立之后路由器可向广播源发送一个PIM加入消息(PIM join message)，目的是把接收端与广播源的连接改接到最短路径树上，从广播源到接收端的最短路径一旦建立，通过会合点的无关分支就可以剪除，这个过程可用图19-11说明。此外，在单个多目标广播组中，对不同的广播源也可以选择不同类型的广播树。
图19-11 协议独立多目标广播-稀疏型广播树的构造过程[1]
协议独立多目标广播-稀疏型广播树的构造步骤如下：
① 广播源2( Source 2)在会合点上的多目标广播路由器RPt处登记。
② 接收端加入路由器RPt；现在是一个比较大的共享树。
③ 接收端接收来自广播源2的数据，然后发送一个明确的加入消息到广播源2，这样就构造了一条最短的路径。
19.5.4 协同工作不同类型的路由协议能够相互协同工作是人们所渴望的。现在有两种类型的协同工作需要考虑，一种是现存的单目标广播路由器和正在出现的具有多目标广播功能的路由器之间的协同工作，另一种是各种多目标广播路由方法之间的协同工作。
第一种类型的协同工作已经有应用实例。例如，DVMRP现在已经用在MBone上多目标广播的路径安排，使用一种方法来连接因特网上的“岛屿”。这种方法是使用IP单目标广播数据包改装(IP tunneling)技术来封装多目标广播数据包，这些岛屿是指具有多目标广播功能但被不支持IP多目标广播的链路所分隔的子网。此外，MOSPF设计在OSPF版本2的顶部，这样就可以把多目标广播的功能引入到OSPF版本2的路径选择域中。
第二种协同工作的问题PIM的设计人员正在忙于解决。既要解决在PIM-DM和PIM-SM之间能够协同工作，又要解决在PIM与其他多目标广播路径结构之间的协同工作。在密集型和稀疏型协议之间有一个基本的协同工作问题，密集型靠数据驱动来建立广播树，而稀疏型则依赖明确的加入请求来建立广播树。如果密集型广播组要与稀疏型广播组协同工作，例如要生成一个组，这个组稀疏地分布在广域网络上但密集地分布在单个子网上，这就必需要有一种机制，允许这个密集型组到达稀疏型组请求加入多目标广播。PIM设计人员提出的解决方案是让“边界路由器(border routers)”发送明确的加入信息到稀疏组。使用同样的方法也应该能够使PIM-SM与其他密集型协议协同工作，例如距离矢量多目标路由协议(Distance Vector Multicast Routing Protocol，DVMRP)。
19.6 实时传输协议和实时控制协议因特网一直主要用来提供可靠的数据传送服务，对数据的时延几乎没有什么限制。TCP/IP协议就是为这种类型的交通设计的，而且工作得很好。然而，像多目标广播这样的多媒体应用却具有不同的特性，因此就需要不同的协议来提供所需要的服务。例如，如果你在接收来自因特网的声音、电视或者要求时延很小的其他数据时，使用TCP/IP在实时播放过程中就可能会产生抖动或者是不能接受的抖动，使声音或者电视的质量明显下降。现在已经开发了并且继续开发许多协议来加强因特网的体系结构，从而改善像声音广播，电视广播和交换多媒体会议的应用。实时传输协议(Real-time Transport Protocol，RTP)，实时控制协议(Real-time Control Protocol，RTCP),资源保留协议(Resource Reservation Protocol，RSVP)和实时流放协议(Real-time Streaming Protocol，RTSP)就是为实时多媒体在网络上的应用而开发的协议。
19.6.1 RTP简介
RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。
RTP定义在RFC 1889中。信息包的结构包含广泛用于多媒体的若干个域，包括声音点播(audio-on-demand)、影视点播(video on demand)、因特网电话(Internet telephony)和电视会议(videoconferencing)。RTP的规格没有对声音和电视的压缩格式制定标准，它可以被用来传输普通格式的文件。例如，WAV或者GSM(Global System for Mobile communications)格式的声音、MPEG-1和MPEG-2的电视，也可以用来传输专有格式存储的声音和电视文件。
使用RTP协议的应用程序运行在RTP之上，而执行RTP的程序运行在UDP的上层，目的是为了使用UDP的端口号和检查和。如图19-12所示，RTP可以看成是传输层的子层。由多媒体应用程序生成的声音和电视数据块被封装在RTP信息包中，每个RTP信息包被封装在UDP消息段中，然后再封装在IP数据包中。
TCP/IP模型
应用层(application)
传输层
RTP
UDP
IP
数据链路层(data link)
物理层(physical)
图19-12 RTP是传输层上的协议
从应用开发人员的角度来看，可把RTP执行程序看成是应用程序的一部分，因为开发人员必需把RTP集成到应用程序中。在发送端，开发人员必需把执行RTP协议的程序写入到创建RTP信息包的应用程序中，然后应用程序把RTP信息包发送到UDP的套接接口(socket interface)，如图19-13所示；同样，在接收端，RTP信息包通过UDP套接接口输入到应用程序，因此开发人员必需把执行RTP协议的程序写入到从RTP信息包中抽出媒体数据的应用程序。
TCP/IP模型
应用层(application)
RTP
套接接口
UDP
IP
数据链路层(data link)
物理层(physical)
图19-13 RTP和UDP之间的接口
现以用RTP传输声音为例来说明它的工作过程。假设音源的声音是64 kb/s的PCM编码声音，并假设应用程序取20毫秒的编码数据为一个数据块(chunk)，即在一个数据块中有160个字节的声音数据。应用程序需要为这块声音数据添加RTP标题生成RTP信息包，这个标题包括声音数据的类型、顺序号和时间戳。然后RTP信息包被送到UDP套接接口，在那里再被封装在UDP信息包中。在接收端，应用程序从套接接口处接收RTP信息包，并从RTP信息包中抽出声音数据块，然后使用RTP信息包的标题域中的信息正确地译码和播放声音。
如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳，而是使用标准的RTP协议，应用程序就更容易与其他的网络应用程序配合运行，这是大家都希望的事情。例如，如果有两个不同的公司都在开发因特网电话软件，他们都把RTP合并到他们的产品中，这样就有希望：使用不同公司电话软件的用户之间能够进行通信。
这里需要强调的是，RTP本身不提供任何机制来确保把数据及时递送到接收端或者确保其他的服务质量，它也不担保在递送过程中不丢失信息包或者防止信息包的次序不被打乱。的确，RTP的封装只是在系统端才能看到，中间的路由器并不区分那个IP数据报是运载RTP信息包的。
RTP允许给每个媒体源分配一个单独的RTP信息包流，例如，摄像机或者麦克风。例如，有两个团体参与的电视会议，这就可能打开4个信息包流：两台摄像机传送电视流和两个麦克风传送声音流。然而，许多流行的编码技术，包括MPEG-1和MPEG-2在编码过程中都把声音和电视图像捆绑在一起以形成单一的数据流，一个方向就生成一个RTP信息包流。
RTP信息包没有被限制只可应用于单目标广播，它们也可以在一对多(one-to-many)的多目标广播树或者在多对多(many-to-many)的多目标广播树上传送。例如，多对多的多目标广播，在这种应用场合下，所有发送端通常都把他们的RTP信息包流发送到具有相同多目标广播地址的多目标广播树上。
19.6.2 RTP信息包标题域
RTP标题由4个信息包标题域和其他域组成：有效载荷类型(payload type)域，顺序号(sequence number)域，时间戳(timestamp)域和同步源标识符(Synchronization Source Identifier)域等。RTP信息包的标题域的结构如图19-14所示：
Payload
Type
(有效载荷类型)
Sequence Number
(顺序号)
Timestamp
(时间戳)
Synchronization Source Identifier
(同步源标识符)
Miscellaneous Fields
(其他)
图19-14 RTP信息包的标题域
1,有效载荷类型
RTP信息包中的有效载荷域(Payload Type Field)的长度为7位，因此RTP可支持128种不同的有效载荷类型。对于声音流，这个域用来指示声音使用的编码类型，例如PCM、自适应增量调制或线性预测编码等等。如果发送端在会话或者广播的中途决定改变编码方法，发送端可通过这个域来通知接收端。表19-01列出了目前RTP所能支持的声音有效载荷类型。
表19-01 目前RTP所能支持的声音有效载荷类型有效载荷号
声音类型
采样率(kHz)
数据率(kb/s)
0
PCM mu-law
8
64
1
1016
8
4.8
2
G.721
8
32
3
GSM
8
32
6
DVI
16
64
7
LPC
8
2.4
9
G.722
8
48～64
14
MPEG Audio
90
-
15
G.728
8
16
对电视流，有效载荷类型可以用来指示电视编码的类型，例如motion JPEG,MPEG-1，MPEG-2或者H.231等等。发送端也可以在会话或者期间随时改变电视的编码方法。表19-02列出了目前RTP所能支持的某些电视有效载荷类型。
表19-02 目前RTP所能支持的声音有效载荷类型有效载荷号
电视格式
26
Motion JPEG
28
-
31
H.261
32
MPEG-1 video
33
MPEG-2 video
2,顺序号顺序号(Sequence Number Field)域的长度为16位。每发送一个RTP信息包顺序号就加1，接收端可以用它来检查信息包是否有丢失以及按顺序号处理信息包。例如，接收端的应用程序接收到一个RTP信息包流，这个RTP信息包在顺序号86和89之间有一个间隔，接收端就知道信息包87和88已经丢失，并且采取措施来处理丢失的数据。
3,时间戳时间戳(Timestamp)域的长度为32字节。它反映RTP数据信息包中第一个字节的采样时刻(时间)。接收端可以利用这个时间戳来去除由网络引起的信息包的抖动，并且在接收端为播放提供同步功能。
4,同步源标识符
同步源标识符(Synchronization Source Identifier，SSRC)域的长度为32位。它用来标识RTP信息包流的起源，在RTP会话或者期间的每个信息包流都有一个清楚的SSRC。SSRC不是发送端的IP地址，而是在新的信息包流开始时源端随机分配的一个号码。
19.6.3 实时传输控制协议实时传输控制协议(Real-time Control Protocol，RTCP)也定义在1996年提出的RFC 1889中。多媒体网络应用把RTCP和RTP一起使用，尤其是在多目标广播中更具吸引力。当从一个或者多个发送端向多个接收端广播声音或者电视时，也就是在RTP会话期间，每个参与者周期性地向所有其他参与者发送RTCP控制信息包，如图19-15所示。RTCP用来监视服务质量和传送有关与会者的信息。对于RTP会话或者广播，通常使用单个多目标广播地址，属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址，通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。
图19-15 每个参与者周期性地发送RTCP控制信息包
RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据，而是封装发送端和/或者接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息对发送端、接收端或者网络管理员都是很有用的。RTCP规格没有指定应用程序应该使用这个反馈信息做什么，这完全取决于应用程序开发人员。例如，发送端可以根据反馈信息来修改传输速率，接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的，网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。
19.6.4 实时流放协议实时流放协议(Real-Time Streaming Protocol，RTSP)是一个刚开始开发的协议，它的设想描述在RFC 2326文件中。RTSP是应用级的实时流放协议，它主要目标是为单目标广播和多目标广播上的流式多媒体应用提供牢靠的播放性能，以及支持不同厂家提供的客户机和服务机之间的协同工作能力。
播放的数据流被分成许多信息包，信息包的大小很适用于客户机和服务器之间的带宽。当客户机已经接收到足够多的信息包之后，用户软件就可开始播放一个信息包，同时对另一个信息包解压缩和接收第三个信息包。这样用户就不需要把整个媒体文件从服务器上下载之后就可立即播放。广播源可以是现场的数据流也可以是存储的数据流。
RTSP协议想要提供控制多种应用数据传送的功能，提供一种选择传送通道的方法，例如UDP,TCP,IP多目标广播通道，以及提供一种基于RTP协议的递送方法。正在设计的RTSP将工作在RTP的上层，用来控制和传送实时的内容。
RTSP能够与资源保留协议一起使用，用来设置和管理保留带宽的流式会话或者广播。
19.7 资源保留协议当前因特网主要是为IP数据报提供最佳服务，而对吞吐率和时延不提供任何担保。为了改善声音和电视质量，这就非常渴望能够在因特网上为多媒体网络应用提供服务质量(quality of service，QoS) 有保证的服务。但是QoS保证需要一种机制，这种机制允许应用程序保留因特网上的资源。而新的因特网标准——资源保留协议(Resource Reservation Protocol，RSVP)就是一个允许应用程序保留资源的一种标准，它定义在RFC 2205中。
随便要指出的一点的是，当人们谈论因特网资源时，通常是指链路带宽和路由器的缓存。为了使谈论的内容更集中，本章假设“资源”这个词就是带宽的同义词，而RSVP则代表带宽保留协议(Bandwidth Reservation Protocol)。
19.7.1 RSVP协议简介执行RTCP协议的软件可用来提供服务质量的反馈信息，但仅用这个协议还不够，还须要有其他协议来为收发两端之间的会话或者广播及时传送数据和保证服务质量。资源保留设置协议RSVP就是为保证服务质量而开发的一种协议。
RSVP协议允许应用程序为它们的数据流保留带宽。主机根据数据流的特性使用这个协议向网络请求保留一个特定量的带宽，路由器也使用RSVP协议转发带宽请求。为了执行RSVP协议，在接收端、发送端和路由器中都必需要有执行RSVP协议的软件。RSVP的两个主要特性是：
① 保留多目标广播树上的带宽，单目标广播是一个特殊情况。
② 接收端导向，也就是接收端启动和维护资源的保留。
这两个特性可用图19-16说明。该图表示的是一个多目标广播树(multicast tree)，它的数据流向是从树的顶部到6个主机。虽然数据源来自发送端，但保留消息(reservation message)则发自接收端。当路由器向上给发送端转发保留消息时，路由器可以合并来自下面的保留消息。
图19-16 RSVP的特性
须要指出，RSVP标准没有指定网络如何为数据流保留资源，这个协议仅是允许应用程序提出保留必要的链路带宽的一个协议 。一旦提出要求保留资源，实际上是因特网上的路由器来为数据流保留带宽，让路由器接口来维护途经这个接口的各种数据流信息包。
19.7.2 不同种类的接收器我们知道，接入因特网的用户是多种多样的，有的使用28.8 kb/s速率接收数据，有的使用128 kb/s速率接收数据，而有的使用10 Mb/s甚至更高的速率接收数据。这里就出现一个问题，向这些接收数据速率不同的用户广播时，发送端到底应该使用什么样的数据流速率对外广播，使用28.8 kb/s还是使用10 Mb/s？如果使用28.8 kb/s广播，使用10 Mb/s的用户就可能会嫌质量太低；如果使用10 Mb/s广播，使用28.8 kb/s的用户就接收不到广播。
解决这个问题的一种方案是对声音或电视进行分层编码，每层的声音或电视的数据速率各不相同，以此来满足各种不同用户的要求。在广播时，发送端并不一定要知道接收端的数据接收速率，而只需要知道这些用户中使用的最大数据接收速率即可。发送端对声音或电视进行分层编码，并且把它们发送到广播树上，用户就根据自己的实际速率接收不同质量的广播。
[例19.1] 多目标实况广播假设有一场体育比赛要在因特网上进行实况转播，多目标广播地址已经在因特网上事先发布，并且假设从发送端到接收端的多目标广播树已经确立，如图19-17所示。此外，每个接收端的数据接收速率已经在图19-17上表示出，而且电视数据是按照接收端数据接收速率进行分层编码的。
图19-17 多目标实况广播举例
RSVP的工作过程大致如下。每个接收端逆向发送一个资源保留消息到多目标广播树，这个消息说明了接收端接收广播源的数据速率。当保留消息到达一个路由器时，路由器就调整它的信息包调度程序来保留带宽，然后把这个消息送到上游路由器。路由器逆向保留的带宽数量是根据下流的保留带宽的数量来确定的。在本例中，接收端R1，R2，R3和R4分别保留20 kb/s,120 kb/s,3 Mb/s和3 Mb/s，因此路由器D下面的接收端请求的最大速率为3 Mb/s。路由器D把保留消息发送给路由器B，请求路由器B在这两个路由器之间的链路上保留3 Mb/s的带宽，因为R3和R4观看同一个广播，因此不需要保留6 Mb/s的带宽。依此类推，路由器C请求路由器B在路由器B和路由器C之间的链路上保留100 kb/s的带宽。分层编码的数据流保证接收端R1的20 kb/s的数据流包含在100 kb/s数据流中。一旦路由器B接收到来自下面的路由器的保留消息之后就递送给它的调度程序，然后把新的保留消息递送给上一层的路由器A。这个消息要求在从路由器A到路由器B的链路上保留3 Mb/s的带宽，这是接收端要求保留的最大带宽。
从上面的分析可以看到，RSVP是接收端导向(receiver-oriented)的协议，也就是由接收数据流的终端提出资源保留请求。我们也注意到，每个路由器接收到的消息依次是从多目标广播树上的下流链路上发送来的，而且只有一个带宽保留消息。
[例19.2] 4人电视会议假设每人在自己的计算机屏幕上开有3个窗口观看其他3人的情况，按照路由协议在4台计算机之间建立多目标广播树，他们都使用3 Mb/s的速率来接收电视，如图19-18所示。在这个多目标广播树上的每条链路上，RSVP就要在一个方向保留9 Mb/s的带宽，而在其他方向上保留3 Mb/s的带宽。在这个例子中，RSVP不合并保留带宽，因为每个人都想接收来自其他3台计算机的数据流。
图19-18 4人电视会议
19.7.3 接纳测试由于路由器在链路上保留的带宽的数量不能超过链路本身的能力，因此每当路由器接收一个新的保留消息时，它必需首先判断多目标广播树上的下流链路是否可以容纳，这个过程称为接纳测试(admission test)。如果接纳测试失败，路由器就拒绝保留带宽，并且给请求保留带宽的接收端发送一个错误消息。
RSVP不定义和执行容纳测试，而是由路由器来承担这种测试。
19.7.4 路径消息前面我们只讨论了RSVP的带宽保留消息，这是从接收端发出并向发送端递送的带宽保留消息。另一个重要的RSVP消息叫做路径消息(RSVP path messages )，它与RSVP保留消息(RSVP reservation messages)相反，是从发送端发出并向接收端发送的消息。
发送路径消息的主要目的是要让路由器知道在那些链路上应该转发保留消息，尤其是在多目标广播树中从路由器A到路由器B发出的路径消息，这个消息中包含有路由器A的单目标广播IP地址。路由器B把这个地址放在路径状态表(path-state table)中，当它从下流节点接收到保留消息时，它就访问这张路径状态表，从而得知它应该向路由器A发送一个带宽保留消息。
路径消息也包含发送端的交通特性，它定义发送端将要生成的数据流的特性，这个消息可以用来预防带宽保留过多。
练习与思考题什么叫做单目标广播(unicast)和多目标广播(multicast)？什么叫做网际多目标广播(IP Multicast)？
多目标广播使用哪类地址？
对有兴趣的读者，试阅读并比较下列两个协议：
① 1997年的RFC 2236：B,Fenner,"Internet Group Management Protocol,Version 2".
② 1989年的RFC 1112：S,Deering,"Host extensions for IP multicasting"
对有兴趣的读者，阅读声音-电视传输工作组(Audio-Video Transport Working Group)编写的实时传输协议RTP和实时传输控制协议RTCP文件：
RFC 1889：H,Schulzrinne,S,Casner,R,Frederick,V,Jacobson,"RTP,A Transport Protocol for Real-Time Applications",01/25/1996.
并写出摘要。
参考文献和站点
http://www.ipmulticast.com (浏览日期：1999.1)
① Vicki Johnson and Marjory Johnson，How IP Multicast Works，1997
② Vicki Johnson and Marjory Johnson，IP Multicast Backgrounder，1997
③ Vicki Johnson and Marjory Johnson，Higher Level Protocols used with IP Multicast，1997
RFC 2435：L,Berc,B,Fenner,R,Frederick,S,McCanne,P,Stewart,"RTP Payload Format for JPEG-compressed Video",10/15/1998,(Obsoletes RFC2035)
RFC 2432：K,Dubray,"Terminology for IP Multicast Benchmarking",10/12/1998
RFC 2375：S,Deering,B,Hinden,"IPv6 Multicast Address Assignments",07/20/1998
RFC 2365：D,Meyer,"Administratively Scoped IP Multicast",07/02/1998
RFC 2337：D,Farinacci,D,Meyer,Y,Rekhter,"Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM",05/01/1998
RFC 2327：M,Handley,V,Jacobson,"SDP,Session Description Protocol",04/14/1998
RFC 2326：R,Lanphier,A,Rao,H,Schulzrinne,"Real Time Streaming Protocol (RTSP)",04/14/1998
RFC 2326：R,Lanphier,A,Rao,H,Schulzrinne,"Real Time Streaming Protocol (RTSP)",04/14/1998
RFC 2236：B,Fenner,"Internet Group Management Protocol,Version 2",11/11/1997,(Updates RFC1112)
RFC 2205：B,Braden,L,Zhang,S,Berson,S,Herzog,S,Jamin,"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification",10/01/1997
RFC 2201：T,Ballardie,"Core Based Trees (CBT) Multicast Routing Architecture",09/25/1997
RFC 2189：T,Ballardie,"Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --",09/25/1997
RFC 2147：D,Borman,"TCP and UDP over IPv6 Jumbograms",05/23/1997,(Updates RFC1883)
RFC 2090：A,Emberson,"TFTP Multicast Option",02/04/1997
RFC 1890：H,Schulzrinne,"RTP Profile for Audio and Video Conferences with Minimal Control",01/25/1996
RFC 1889：H,Schulzrinne,S,Casner,R,Frederick,V,Jacobson,"RTP,A Transport Protocol for Real-Time Applications",01/25/1996
RFC 1700：J,Reynolds,J,Postel,"ASSIGNED NUMBERS",10/20/1994,(Obsoletes RFC1340) (STD 2)
RFC 1587：R,Coltun,V,Fuller,"The OSPF NSSA Option",03/24/1994
RFC 1585：J,Moy,"MOSPF,Analysis and Experience",03/24/1994
RFC 1584：J,Moy,"Multicast Extensions to OSPF",03/24/1994
RFC 1469：T,Pusateri,"IP Multicast over Token-Ring Local Area Networks",06/17/1993
RFC 1458：R,Braudes,"Requirements for Multicast Protocols",05/26/1993.
RFC 1323：D,Borman,B,Braden,V,Jacobson,"TCP Extensions for High Performance",05/13/1992,(Obsoletes RFC1072) (Obsoletes RFC1185)
RFC 1301：A,Freier,"Multicast Transport Protocol",02/19/1992
RFC 1112：S,Deering,"Host extensions for IP multicasting",08/01/1989,(Obsoletes RFC1054) (Obsoletes RFC988) (Updated by RFC2236) (STD 5)
RFC 1075：S,Deering,C,Partridge,D,Waitzman,"Distance Vector Multicast Routing Protocol",11/01/1988
RFC 791：J,Postel,"Internet Protocol",09/01/1981,(Obsoletes RFC760) (Obsoleted by RFC1060)
