YD/T 3308-2017
基本信息
标准号： YD/T 3308-2017
中文名称：IP 组播 Ping 与路径探测协议
标准类别：通信行业标准(YD)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：37243257
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 3308-2017 IP.The ping and traceroute protocols for IP multicast.
1范围
YD/T 3308规定了在IP组播网络中，如何支持组播Ping协议实现对组播转发路径可达性的检查，以及如何支持组播路由探测协议，实现对组播转发路径的追踪。组播Ping与组播路径探测的布署有利于提高组播网络的运维和管理能力。
YD/T 3308适用于支持IP组播业务的网络和设备。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
IETF RFC 768 用户数据报协议(User Datagram Protocol)
IETF RFC 792 互联网控制报文协议(Internet Control Message Protocol)
IETF RFC 1075 距离向量组播路由协议(Distance Vector Multicast Routing Protocol)
IETF RFC 1305 网络时间协议版本3:规范，实现和分析(Network Time Protocol (Version 3)Specification, Implementation and Analysis)
IETF RFC 2113 IP路由器告警选项(IP Router Alert Option)
IETF RFC2711IPv6路由器告警选项(IPv6 Router Alert Option)
IETF RFC 2858边界网络协议版本4的多协议扩展(Multiprotocol Extensions for BGP-4)
IETF RFC 2863接口组管理信息库规范(The Interfaces Group MIB)
IETF RFC 3973协议无关组播密集模式协议(Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised))
1范围
YD/T 3308规定了在IP组播网络中，如何支持组播Ping协议实现对组播转发路径可达性的检查，以及如何支持组播路由探测协议，实现对组播转发路径的追踪。组播Ping与组播路径探测的布署有利于提高组播网络的运维和管理能力。
YD/T 3308适用于支持IP组播业务的网络和设备。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
IETF RFC 768 用户数据报协议(User Datagram Protocol)
IETF RFC 792 互联网控制报文协议(Internet Control Message Protocol)
IETF RFC 1075 距离向量组播路由协议(Distance Vector Multicast Routing Protocol)
IETF RFC 1305 网络时间协议版本3:规范，实现和分析(Network Time Protocol (Version 3)Specification, Implementation and Analysis)
IETF RFC 2113 IP路由器告警选项(IP Router Alert Option)
IETF RFC2711IPv6路由器告警选项(IPv6 Router Alert Option)
IETF RFC 2858边界网络协议版本4的多协议扩展(Multiprotocol Extensions for BGP-4)
IETF RFC 2863接口组管理信息库规范(The Interfaces Group MIB)
IETF RFC 3973协议无关组播密集模式协议(Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised))
标准图片预览
标准内容
ICS33.040.40
中华人民共和国通信行业标准
YD/T33082017
IP组播Ping与路径探测协议
The ping and traceroute protocols for IP multicast2017-11-07发布
中华人民共和国工业和信息化部2018-01-01实施
1范围
规范性引用文件
3缩略语.
4组播Ping...
协议概述
协议操作规程
4.3客户端行为.
4.4服务器行为..
实现考虑.
4.6IANA考虑.
4.7安全考虑...
5组播路由探测.
报文格式.
5.3路由器行为..
5.4客户端行为.
5.5组播协议相关处理
5.6问题分析与故障定位
5.7IANA考虑
5.8安全考虑.
参考文献
YD/T3308—2017
YD/T3308-—2017
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国标准化协会提出并归口。本标准起草单位：华为技术有限公司、中国信息通信研究院、中国电信集团公司、中国移动通信集团公司、中兴通讯股份有限公司、上海贝尔股份有限公司、成都迈普产业集团有限公司、杭州华三通信技术有限公司。
本标准主要起草人：刘晖、杜宗鹏、陈端。1范围
IP组播Ping与路径探测协议
YD/T3308—2017
本标准规定了在IP组播网络中，如何支持组播Ping协议实现对组播转发路径可达性的检查，以及如何支持组播路由探测协议，实现对组播转发路径的追踪。组播Ping与组播路径探测的布署有利于提高组播网络的运维和管理能力。本标准适用于支持IP组播业务的网络和设备。2规范性引用文件
下列文件对手本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC768
IETFRFC792
IETFRFC1075
IETFRFC1305
用户数据报协议（UserDatagramProtocol）互联网控制报文协议（InternetControlMessageProtocol）距离向量组播路由协议（DistanceVectorMulticastRoutingProtocol）网络时间协议版本3：规范，实现和分析（NetworkTimeProtocol（Version3）Specification,ImplementationandAnalysisIETFRFC2113
IETFRFC2711
IETFRFC2858
IETFRFC2863
ETFRFC3973
IP路由器告警选项（IPRouterAlertOption）IPv6路由器告警选项（IPv6RouterAlertOption）边界网络协议版本4的多协议扩展（MultiprotocolExtensionsforBGP-4）接口组管理信息库规范（TheInterfacesGroupMIB）协议无关组播密集模式协议（ProtocolIndependentMulticast-DenseMode(PIM-DM)ProtocolSpecification(Revised))IETFRFC4601
协议无关组播稀疏模式协议（ProtocolIndependentMulticast-SparseMode(PIM-SM)：ProtocolSpecification(Revised))IETFRFC4605
基于互连网组管理协议/组播监听者发现协议的组播转发一IGMP/MLD代理协议(InternetGroupManagementProtocol(IGMP)/Multicast ListenerDiscovery(MLD)-BasedMulticastForwarding（“IGMP/MLDProxying”））
IETFRFC4607
IP源特定组播（Source-SpecificMulticastforIP）IETFRFC5132
ETFRFC5405
Designers）
IETFRFC6450
IP组播管理信息库（IPMulticastMIB）应用设计者使用单播UDP的实现原则(UnicastUDPUsageGuidelinesforApplication组播Ping协议（MulticastPingProtocol）I
YD/T33082017
IETFRFC7450
3缩略语
自动组播隧道（AutomaticMulticastTunneling）以下缩略语适用于本文件。
PIM-SM
自动组播隧道
任意源组播
指定转发者
拒绝服务
距离向量组播路由协议
组播组
互联网网络号分配机构
互联网控制报文协议
互连网组管理协议
网际协议（第四版）
网际协议（第六版）
多协议边界网关协议
必为0值
管理信息库
组播监听发现协议
最大传输单元
网络时间协议
协议无关组播稀疏模式
汇集点
汇集点地址
汇集点链路
往返时间
组播源
源特定组播
类型长度值
生存期
用户数据报协议
单一码转换格式-8
Automatic Multicast Tunnel
Any Source Multicast
Designated Forwarder
Denial of Service
DistanceVectorMulticastRoutingProtocolGroup
InternetAssignedNumbers AuthorityInternetControl MessageProtocolIdentification
InternetGroupManagementProtocolInternetProtocolVersion4
InternetProtocolVersion6
Multiprotocol BorderGatewayProtocolMustBeZero
ManagementInformationBase
Multicast Listener DiscoveryMaximum Transmission Unit
Network Time Protocol
Protocol Independent MulticastforSparseModeRendezvous Point
Rendezvous Point Address
Rendezvous Point Link
Round Trip Time
Source
Source Specific Multicast
Time-Length-Value
TimeToLive
UserDatagram Protocol
UnicodeTransformationFormat84组播Ping
4.1协议概述
YD/T3308—2017
组播Ping可用来检查组播可达性（见ETFRFC6450)。除了检查源特定组播组（SSM）（见IETFRFC4607)或任意源组播组（ASM）（见IETFRFC4601)的接收，还可搜集其他相关的组播信息，如组播树构建时间，报文传递的跳数，以及报文延迟和丢失等。组播Ping与单播Ping所采用的ICMP(见IETFRFC792)响应请求/应答（EchoRequest/Reply）机制是类似的，不同之处是需要使用UDP(见IETFRFC768）协议承载并要求客户端和服务器实现该协议。过渡路由器不要求支持该协议，只需采用通常的方式转发协议消息。
本协议是基于当前已经实现的ssmping和asmping工具描述的，这两个工具已经被互连网社团广泛使用以进行组播连通性测试。典型的协议使用方式为：服务器连续运行以响应客户端的请求，客户端通过某种方式了解到服务器的单播地址并测试从服务器的组播接收。客户端应用发送单播消息到服务器请求使用的组，可选地，用户可以选择一个特定的组或一个组的范围。服务器响应使用的组，或者如果无可用的组则响应一个错误信息。对于ASM客户端加入一个ASM组G(Group），而对于SSM加入一个SSM组通道（S,G)（（Source，Group）），其中G为服务器限定的组播组地址，而S为服务器的单播地址。在加入组G或通道(S,G)后，客户端向服务器单播发送组播Ping请求。请求发送时将UDP目的端口号设为组播Ping的专用端口号，请求周期性地发送（如每秒发送一次）。这些请求包含一个序列号，或典型地可包含一个时标请求由服务器响应，服务器在响应时可增加一些新的选项。对于每个请求，服务器发送两个应答：一个应答以请求客户端的源IP地址和源UDP端口号为目的地址和目的端口号单播发送，另一个应答以请求组地址和请求客户端的源端口号为目的地址和目的端口号组播发送。两个应答所采用的目的端口号与接收到的请求的源端口号相同。服务器单播或组播发送的中应答通过一个TTL选项限定TTL值（IPv4TTL或IPv6跳数，推荐设为64），使得客户端可以计算跳数。客户在完成测量时应离开先前加入的组G或通道(S,G)。通过使用本协议，客户端（或客户端的一个使用者）可以获得组播交付的若干特性。首先，通过接收单播应答，客户端可确证服务器接收到了单播请求，它正在运行着并能够响应客户端的请求。因而，假定客户端接收到单播响应，而如果此时不能够接收到组播响应，表明存在着组播转发问题或组播管理限制。如果能够接收组播响应，客户端不仅可以知道它可以接收组播流量，还可以估计建立组播树需要花费的时间，确定是否存在着报文丢失，测量环回时间（RTT）的大小和变化等。对于单播而言，RTT为从发送单播请求到接收单播应答所消耗的时间，组播RTT为发送单播请求到接收组播应答所花费的时间。通过限定应答的TTL值，客户端可以确定距离源的路由器跳数。主机可通过比较单播和组播的结果，检查单播与组播的跳数和RTT的差异。组播跳数和跳数随时间的变化反映了组播树和组播树变化的细节。假定服务器同时发送单播和组播应答，客户端可以测量从服务器到客户端的单播和组播路径上的单向延时，以及单播和组播延时的差值。服务器也为单播和组播分别限定一个时标，这是因为单播和组播不能够同时发送，发送的延时取决于主机的操作系统和当前的处理负荷。3
YD/T3308—2017
4.2协议操作规程
4.2.1概述
组播Ping共使用四种报文类型：响应请求（EchoRequest），响应应答（EchoReply），初始消息（Init），和服务器响应（ServerResonse）消息。响应请求和响应应答消息用于实际的报文测量。初始消息用于初始化一个组播Ping会话和协商所要使用的组。服务器发送服务器响应消息用来响应初始消息。初始消息应以网络字节顺序表示，并且应使用UDP校验和。所有的消息都采用相同的报文格式：一个字节表示消息类型，后面跟着几个TLV（类型，长度，值）选项格式，以使协议更易于扩展。消息类型0～191的范围预留给IANA分配，范围192～255未在IANA注册，可预留为实验使用。
初始消息通常包含一些前缀选项，以便请求服务器从这些前缴中选择一个Ping使用的组播组。服务器发送一个服务器响应消息包含选定的组地址，或包含描述服务器可提供的组播组前缴选项。客户端在响应请求中通常会包含一组选项，服务器可做一个简单的应答（通过只改变报文类型）而不检查任何它不支持的选项，这对应于简单的组播Ping场景。但通常情况下，服务器应该增加一个TTL选项和其他可支持的选项，如响应客户端对特定请求的应答。响应应答（一个单播和一个组播）应首先包含响应请求中携带的相同选项（除会话ID选项之外），选项顺序与响应请求相同，然后在后面添加服务器希望添加的选项。服务器必不能处理未知的选项，但这些选项应包含在响应应答中。客户端应忽略未知的选项。
协议消息的大小通常小于路径MTU，因而没必要考虑分片。然而对于路径MTU特别小的情况或者客户端发送特别大的请求以验证它能够接收分片组播数据报的情况下，是可能产生分片的。文档中不限定路径MTU发现一定得到执行，这时可定义新的扩展选项使得客户端请求发现路径MTU，并从服务器接收当前的路径MTU。文档中定义了几种不同的选项，一些选项不要求服务器处理，服务器可以不加处理地返回。另一些是服务器关注的客户端选项和客户端请求的服务器选项，需要服务器进行特别的处理。除非特别限定，选项必不可以可在相同的消息中使用多次。4.2.2选项格式与定义
所有选项的格式如图1所示。
01234567890123456789012345678901类型
图1中。
类型（2字节）：选项的类型：
图1选项格式
长度（2字节）：值的长度，取决于选项类型，取值范围可为0～65535；一值（可变）：相关选项内容。如果长度为0，则不应包括值的字段。YD/T3308—2017
文档定义了下列选项：版本（0），客户端ID（1），序列号（2），客户端时标（3），组播组（4），选项请求选项（5），服务器信息（6），TTL（9），组播前缴（10），会话ID（11）和服务器时标（12），值7和值8是预留的，范围0～49151的选项类型预留给IANA机构分配。49152～65535范围内的数值尚未注册可用于实验。各选项的详细定义如下。a）版本，类型0：长度应为1字节。所有的消息中都应包含该选项。对于本协议该版本值设为2。请注意该协议的早期实现只是部分地遵循该标准。它们可被认定为版本1并且不使用该选项。如果服务器接收到版本大于2或无版本的消息，服务器（除非支持特殊版本）发送服务器响应消息的时候，将版本置为2。这时如果该消息中存在客户端D和序列号选项则需原样返回，服务器不应包含其他任何选项。接收到版本号大于2的客户端应中止发送请求到服务器（除非它支持特殊的版本）。b）客户端ID，类型1：长度应为非0。客户端应在所有消息的选项中包含该选项（无论初始消息还是响应请求）。客户端可使用任何值用以检测应答是是否是针对初始/响应请求消息。服务器应把该选项看成透明数据，并且如果在请求中存在则需在应答中原样返回该选项。该选项值可以是一个处理ID，也可以是一个与IP地址组合的处理ID，以区分来自其他客户端的消息。客户端的实现者决定如何使用该选项。
c）序列号，类型2：长度为4字节。客户端应在响应请求消息中包含这个选项但不能够在初始消息中包含它。对响应请求消息进行应答的服务器应将它拷贝到响应应答中，或者在发生错误时将其拷贝到服务器响应消息中。该选项数值可以典型地从1开始，对每个顺序的响应请求逐1递增。d）客户端时标，类型3：长度应为8字节。客户端在响应请求应包含此选项，但必不能在初始消息中包含该选项。对响应请求消息进行应答的服务器应将其拷贝到响应应答中。该选项可设为响应请求消息发送的时间，前4个字节限定了从初始历元（Epoch，1970年1月1日，UTC0000）计算的以秒数表示的时间。下4个字节限定从前4个字节的开始的毫秒数。e）组播组，类型4：长度应大于2字节；可以用于服务器响应消息中告诉客户端在后面的响应请求消息中使用哪个组。它应包含在响应请求中告诉服务器应响应哪个组地址（通常该组地址可以从前面服务器响应消息中获得）。它应在响应应答消息中使用（从响应请求消息中拷贝）。但不能在初始消息中使用。选项值的格式如图2所示。0123456789012345678901234567890地质族
图2组播组选项
组播组地址
地址族由IANA设定，值的范围为065535，后面跟着组地址，选项值的长度对于IPv4为6字节，对于IPv6为18字节。
f）选项请求选项，类型5。
YD/3308—2017
一长度应大于1字节。该选项可以在客户端发送的消息（初始和响应请求消息）中使用。服务器必不能发送这个选项，除非该选项出现在响应请求消息中，服务器应在响应应答消息中将该选项原样返回。该选项包含客户端向服务器请求的一个选项类型的列表，对该选项的支持对客户端和服务器都是可选的。选项的长度为一个非0的偶数字节数，因为它包含一个或多个两字节长的选项类型。选项值的格式如图3所示。0123456789012345678901
选项类型
图3选项请求选项
567890
选项类型
一、该选项可以被客户端用来请求服务器包含时标或服务器信息等选项。客户端可以在初始消息中请求服务器信息选项：它必不能在其他的消息中请求该选项。客户端可以在响应请求消息中请求时标选项，它必不能在其他消息中请求该选项。受上述限制的制约，支持选项请求选项的服务器，应该在对包含特定的选项请求选项的响应请求消息进行响应应答时包含该特定的选项。
服务器可以根据实现或本地配置，不必包含所有客户端请求的选项，可以只包含一个选项。任何被请求的选项都被附加在其他原样返回的选项后面。g）服务器信息，类型6：长度应为非0，可用在服务器响应消息中，但必不能在其他消息中使用。对该选项的支持是可选的。支持该选项的服务器只有当客户端请求时才在服务器响应消息中添加该选项。选项只为UTF-8字符串，可以包含服务器的设备商或版本信息，也可以包含服务器支持的选项信息。交互式客户端可以支持该选项，也应当允许用户请求该字符串并显示它。h）预留，类型7：该选项曾为早期版本使用。客户端必不能使用该选项，服务器应把它看成是未知的选项（接收到不处理）。但如果在响应请求中接收到，则服务器应在响应应答消息中原样返回。i）预留，类型8：该选项曾为早期版本使用。客户端必不能使用该选项，服务器应把它看成是未知的选项（接收到不处理）。但如果在响应请求中接收到，则服务器应在响应应答消息中原样返回j）TTL，类型9。长度必须为1字节。该选项包含单一字节，限定一个响应应答消息的TTL值。每次服务器发送单播或组播响应应答消息，都应该包含此限定TTL的选项。该选项可被客户端使用用来确定消息传递的跳数。它必不能在其他消息中使用。如果服务器知道响应应答的TTL值，则服务器应该选定这个选项。通常情况下服务器可以将该TTL值设定到主机栈中。请注意TTL不一定对于单播和组播是相同的。也需注意即使客户端不请求这个选项，它也应被包含在响应应答中。k）组播前缀，类型10。
长度应大于2字节，如图4所示。可以在初始消息中请求前缀表示的组，也可在服务器响应消息中使用，以告诉客户端它可以使用哪些组。它必不能在响应请求和响应应答消息中使用。需注意该选项也可包含多次用于限定多个前缴。6
01234567890123456789012345678901地质族
前缓长度
图4组播前缀
部分地址
YD/T3308—2017
一地址族取值范围为0～65535，由IANA设定。前缀长度取值范围对于IPv4为4比特～32比特，对于IPv6为8比特～128比特，当取值为0时表示通配符。报文的最后是组地址。对任何组地址族，前缀长度0意味者该地址族的任意组播地址都是可以接收的，因而叫做通配符。组地址仅需包含覆盖前缀长度比特的足够的字节（例如，如果前缀长度为12比特～24比特，组地址应为3字节；而在前缀长度为0，即通配符情况下，则无需携带组地址）。任何超出前缀长度的比特必须被忽略。对于IPv4，选项值长度为4字节～7字节，而对于IPv6，选项值长度为4字节～19字节，而对于通配符，选项值长度为3字节。L）会话ID，类型11：长度应为非0字节数。服务器应在服务器响应消息中包含该选项。如果客户端接收到该选项，客户端应在接下来的响应请求消息中包含相同的会话ID选项。会话ID应被设为伪随机数，使得其值难于预测。会话ID可用来预防在响应请求消息中进行源地址欺骗。m）服务器时标，类型12：长度必8字节。如果客户端请求，则支持该选项的服务器需要在响应应答消息中包含它。时标限定为发送响应应答消息的时间。前4个字节限定了从初始历元（Epoch，1970年1月1日，UTC0000）计算的以秒数表示的时间，其后4个字节限定了秒数后面的毫秒数。4.2.3消息格式及定义bzxZ.net
所有的消息都是由一个字节的消息类型加上可变长度的选项构成，如图5所示。0123456789012345678901234567890类型
图5消息格式
选项…
共定义了四种类型的消息。类型81（ASCI码的字符Q）表示响应请求；类型65（ASCI码的字符A）表示响应应答：类型73（ASCI码的字符I）表示初始消息：类型83（ASCII码的字符S）表示服务器响应消息。选项立即跟随着类型字节并不以任何方式对齐，即选项可以在任何字符边界开始。选项格式如4.4.2节所示。
每种消息中包含的选项种类如下所示。a）初始消息，类型73：该消息由客户端发向服务器以请求特定的信息。它主要用于请求一个组播组地址，也可用于检查服务器提供哪些组前缀。它应包含一个版本选项，也应该包含一个客户端ID选项。它可包含选项请求选项和组播前缀选项。只有包含组前缀选项时才可用来请求一个组地址。如果包含多个前缀选项，则前缀应以优先级顺序排列，服务器将根据限定的优先级顺序考虑前缀，如果找到了对应于一个前缀的组，它将只返回这个组，而不考虑其余的前缀。7
YD/T3308—2017
b）服务器响应消息，类型83：该消息由服务器发送，或者是初始消息的一个响应，或者是响应请求的一个响应。当作为初始消息的响应时，它可以向客户端提供一个组播组（如果为客户端所请求），或者提供其他的服务器信息。当作为响应请求的响应，可以告诉客户端停止发送响应请求。该消息中总是包含版本选项。客户端ID选项和序列号选项如果在客户端消息中出现，将在该响应中被原样返回。当向客户端提供一个组时，消息中需包含组播组选项，如果被请求也可包含服务器信息和前缀选项。c）响应请求，类型81：该消息由客户端发送，请求服务器发送单播和组播响应应答。它应包含版本、序列号和组播组选项。如果客户端在前面的服务器响应消息中接收到会话ID，则应包含会话ID。此外它应该包含客户端ID和客户端时标选项，可以包含选项请求选项。d）响应应答，类型65：该消息由服务器发送，作为响应请求的响应。此消息总是成对出现，一个单播发送，一个组播发送，两个消息的内容大致相同。服务器总是原样返回响应请求中的所有选项（会话ID除外）。响应请求中任何服务器不支持的选项，也将被原样返回。两个响应应答消息总是包含TTL选项（单播和组播设定的值可能不同）。两个响应应答消息当被请求时也应包含服务器时标选项（单播和组播可设定不同的数值）。
4.2.4速率限制
客户端应默认每秒发送至多一个响应请求，服务器应默认执行限速，以防止该协议被利用来实行DoS攻击。服务器应默认对于一个给定的客户端，平均每秒至多对一个响应请求消息进行应答。服务器实现也应提供配置选项以允许特定的客户端以更快速的发送响应请求。如果特定的客户端IP地址允许更高的速率，则应使用初始消息和会话ID选项以防止欺骗的发生。该协议和应用的实现者应考虑UDP的使用规则（见IETFRFC5405），特别是当客户端发送和服务器接收的速率超过每秒1个的情况下。4.3客户端行为
客户端仅要求用户限定服务器的单播地址，然后即可发送携带前缀选项（包含组地址选项和零前缀长度）的初始消息。然后，服务器决定应在该地址族上返回哪个组。客户端可允许用户限定组地址或前缀（对于IPv6，用户可以仅要求限定一个范围或一个RP地址，客户端可构建所需的前缀，如嵌入式RP）。客户端在初始消息中可限定一个或多个前缀选项以告诉服务器它希望使用的地址。如果用户限定了一个组地址，组地址可以采用最大前缀长度编码（例如IPv4为32比特）。前缀选项以优先级顺序排列，将优先级最高的前缀放在最前面。如果客户端接收到包含组地址的服务器响应消息时，它可发送响应请求消息。如果没有组地址选项！客户端将典型的错误退出。服务器可能在服务器响应消息中包含某些前缀选项，客户端使用前缀选项向用户提供可用的前缀或可用的前缀范围。假定客户端在服务器响应消息中获得一个组地址，在让用户知道该组播组将被使用后，可启动组播Ping。通常，客户端应每秒钟至多发送一个响应请求。当发送响应请求时，客户端应总是包含组选项。如果服务器响应消息中包含会话ID，则响应请求中应包含取值完全相同的同一选项。如果客户端发送响应请求后接收到服务器响应消息（即，服务器响8
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国通信行业标准
YD/T33082017
IP组播Ping与路径探测协议
The ping and traceroute protocols for IP multicast2017-11-07发布
中华人民共和国工业和信息化部2018-01-01实施
1范围
规范性引用文件
3缩略语.
4组播Ping...
协议概述
协议操作规程
4.3客户端行为.
4.4服务器行为..
实现考虑.
4.6IANA考虑.
4.7安全考虑...
5组播路由探测.
报文格式.
5.3路由器行为..
5.4客户端行为.
5.5组播协议相关处理
5.6问题分析与故障定位
5.7IANA考虑
5.8安全考虑.
参考文献
YD/T3308—2017
YD/T3308-—2017
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国标准化协会提出并归口。本标准起草单位：华为技术有限公司、中国信息通信研究院、中国电信集团公司、中国移动通信集团公司、中兴通讯股份有限公司、上海贝尔股份有限公司、成都迈普产业集团有限公司、杭州华三通信技术有限公司。
本标准主要起草人：刘晖、杜宗鹏、陈端。1范围
IP组播Ping与路径探测协议
YD/T3308—2017
本标准规定了在IP组播网络中，如何支持组播Ping协议实现对组播转发路径可达性的检查，以及如何支持组播路由探测协议，实现对组播转发路径的追踪。组播Ping与组播路径探测的布署有利于提高组播网络的运维和管理能力。本标准适用于支持IP组播业务的网络和设备。2规范性引用文件
下列文件对手本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC768
IETFRFC792
IETFRFC1075
IETFRFC1305
用户数据报协议（UserDatagramProtocol）互联网控制报文协议（InternetControlMessageProtocol）距离向量组播路由协议（DistanceVectorMulticastRoutingProtocol）网络时间协议版本3：规范，实现和分析（NetworkTimeProtocol（Version3）Specification,ImplementationandAnalysisIETFRFC2113
IETFRFC2711
IETFRFC2858
IETFRFC2863
ETFRFC3973
IP路由器告警选项（IPRouterAlertOption）IPv6路由器告警选项（IPv6RouterAlertOption）边界网络协议版本4的多协议扩展（MultiprotocolExtensionsforBGP-4）接口组管理信息库规范（TheInterfacesGroupMIB）协议无关组播密集模式协议（ProtocolIndependentMulticast-DenseMode(PIM-DM)ProtocolSpecification(Revised))IETFRFC4601
协议无关组播稀疏模式协议（ProtocolIndependentMulticast-SparseMode(PIM-SM)：ProtocolSpecification(Revised))IETFRFC4605
基于互连网组管理协议/组播监听者发现协议的组播转发一IGMP/MLD代理协议(InternetGroupManagementProtocol(IGMP)/Multicast ListenerDiscovery(MLD)-BasedMulticastForwarding（“IGMP/MLDProxying”））
IETFRFC4607
IP源特定组播（Source-SpecificMulticastforIP）IETFRFC5132
ETFRFC5405
Designers）
IETFRFC6450
IP组播管理信息库（IPMulticastMIB）应用设计者使用单播UDP的实现原则(UnicastUDPUsageGuidelinesforApplication组播Ping协议（MulticastPingProtocol）I
YD/T33082017
IETFRFC7450
3缩略语
自动组播隧道（AutomaticMulticastTunneling）以下缩略语适用于本文件。
PIM-SM
自动组播隧道
任意源组播
指定转发者
拒绝服务
距离向量组播路由协议
组播组
互联网网络号分配机构
互联网控制报文协议
互连网组管理协议
网际协议（第四版）
网际协议（第六版）
多协议边界网关协议
必为0值
管理信息库
组播监听发现协议
最大传输单元
网络时间协议
协议无关组播稀疏模式
汇集点
汇集点地址
汇集点链路
往返时间
组播源
源特定组播
类型长度值
生存期
用户数据报协议
单一码转换格式-8
Automatic Multicast Tunnel
Any Source Multicast
Designated Forwarder
Denial of Service
DistanceVectorMulticastRoutingProtocolGroup
InternetAssignedNumbers AuthorityInternetControl MessageProtocolIdentification
InternetGroupManagementProtocolInternetProtocolVersion4
InternetProtocolVersion6
Multiprotocol BorderGatewayProtocolMustBeZero
ManagementInformationBase
Multicast Listener DiscoveryMaximum Transmission Unit
Network Time Protocol
Protocol Independent MulticastforSparseModeRendezvous Point
Rendezvous Point Address
Rendezvous Point Link
Round Trip Time
Source
Source Specific Multicast
Time-Length-Value
TimeToLive
UserDatagram Protocol
UnicodeTransformationFormat84组播Ping
4.1协议概述
YD/T3308—2017
组播Ping可用来检查组播可达性（见ETFRFC6450)。除了检查源特定组播组（SSM）（见IETFRFC4607)或任意源组播组（ASM）（见IETFRFC4601)的接收，还可搜集其他相关的组播信息，如组播树构建时间，报文传递的跳数，以及报文延迟和丢失等。组播Ping与单播Ping所采用的ICMP(见IETFRFC792)响应请求/应答（EchoRequest/Reply）机制是类似的，不同之处是需要使用UDP(见IETFRFC768）协议承载并要求客户端和服务器实现该协议。过渡路由器不要求支持该协议，只需采用通常的方式转发协议消息。
本协议是基于当前已经实现的ssmping和asmping工具描述的，这两个工具已经被互连网社团广泛使用以进行组播连通性测试。典型的协议使用方式为：服务器连续运行以响应客户端的请求，客户端通过某种方式了解到服务器的单播地址并测试从服务器的组播接收。客户端应用发送单播消息到服务器请求使用的组，可选地，用户可以选择一个特定的组或一个组的范围。服务器响应使用的组，或者如果无可用的组则响应一个错误信息。对于ASM客户端加入一个ASM组G(Group），而对于SSM加入一个SSM组通道（S,G)（（Source，Group）），其中G为服务器限定的组播组地址，而S为服务器的单播地址。在加入组G或通道(S,G)后，客户端向服务器单播发送组播Ping请求。请求发送时将UDP目的端口号设为组播Ping的专用端口号，请求周期性地发送（如每秒发送一次）。这些请求包含一个序列号，或典型地可包含一个时标请求由服务器响应，服务器在响应时可增加一些新的选项。对于每个请求，服务器发送两个应答：一个应答以请求客户端的源IP地址和源UDP端口号为目的地址和目的端口号单播发送，另一个应答以请求组地址和请求客户端的源端口号为目的地址和目的端口号组播发送。两个应答所采用的目的端口号与接收到的请求的源端口号相同。服务器单播或组播发送的中应答通过一个TTL选项限定TTL值（IPv4TTL或IPv6跳数，推荐设为64），使得客户端可以计算跳数。客户在完成测量时应离开先前加入的组G或通道(S,G)。通过使用本协议，客户端（或客户端的一个使用者）可以获得组播交付的若干特性。首先，通过接收单播应答，客户端可确证服务器接收到了单播请求，它正在运行着并能够响应客户端的请求。因而，假定客户端接收到单播响应，而如果此时不能够接收到组播响应，表明存在着组播转发问题或组播管理限制。如果能够接收组播响应，客户端不仅可以知道它可以接收组播流量，还可以估计建立组播树需要花费的时间，确定是否存在着报文丢失，测量环回时间（RTT）的大小和变化等。对于单播而言，RTT为从发送单播请求到接收单播应答所消耗的时间，组播RTT为发送单播请求到接收组播应答所花费的时间。通过限定应答的TTL值，客户端可以确定距离源的路由器跳数。主机可通过比较单播和组播的结果，检查单播与组播的跳数和RTT的差异。组播跳数和跳数随时间的变化反映了组播树和组播树变化的细节。假定服务器同时发送单播和组播应答，客户端可以测量从服务器到客户端的单播和组播路径上的单向延时，以及单播和组播延时的差值。服务器也为单播和组播分别限定一个时标，这是因为单播和组播不能够同时发送，发送的延时取决于主机的操作系统和当前的处理负荷。3
YD/T3308—2017
4.2协议操作规程
4.2.1概述
组播Ping共使用四种报文类型：响应请求（EchoRequest），响应应答（EchoReply），初始消息（Init），和服务器响应（ServerResonse）消息。响应请求和响应应答消息用于实际的报文测量。初始消息用于初始化一个组播Ping会话和协商所要使用的组。服务器发送服务器响应消息用来响应初始消息。初始消息应以网络字节顺序表示，并且应使用UDP校验和。所有的消息都采用相同的报文格式：一个字节表示消息类型，后面跟着几个TLV（类型，长度，值）选项格式，以使协议更易于扩展。消息类型0～191的范围预留给IANA分配，范围192～255未在IANA注册，可预留为实验使用。
初始消息通常包含一些前缀选项，以便请求服务器从这些前缴中选择一个Ping使用的组播组。服务器发送一个服务器响应消息包含选定的组地址，或包含描述服务器可提供的组播组前缴选项。客户端在响应请求中通常会包含一组选项，服务器可做一个简单的应答（通过只改变报文类型）而不检查任何它不支持的选项，这对应于简单的组播Ping场景。但通常情况下，服务器应该增加一个TTL选项和其他可支持的选项，如响应客户端对特定请求的应答。响应应答（一个单播和一个组播）应首先包含响应请求中携带的相同选项（除会话ID选项之外），选项顺序与响应请求相同，然后在后面添加服务器希望添加的选项。服务器必不能处理未知的选项，但这些选项应包含在响应应答中。客户端应忽略未知的选项。
协议消息的大小通常小于路径MTU，因而没必要考虑分片。然而对于路径MTU特别小的情况或者客户端发送特别大的请求以验证它能够接收分片组播数据报的情况下，是可能产生分片的。文档中不限定路径MTU发现一定得到执行，这时可定义新的扩展选项使得客户端请求发现路径MTU，并从服务器接收当前的路径MTU。文档中定义了几种不同的选项，一些选项不要求服务器处理，服务器可以不加处理地返回。另一些是服务器关注的客户端选项和客户端请求的服务器选项，需要服务器进行特别的处理。除非特别限定，选项必不可以可在相同的消息中使用多次。4.2.2选项格式与定义
所有选项的格式如图1所示。
01234567890123456789012345678901类型
图1中。
类型（2字节）：选项的类型：
图1选项格式
长度（2字节）：值的长度，取决于选项类型，取值范围可为0～65535；一值（可变）：相关选项内容。如果长度为0，则不应包括值的字段。YD/T3308—2017
文档定义了下列选项：版本（0），客户端ID（1），序列号（2），客户端时标（3），组播组（4），选项请求选项（5），服务器信息（6），TTL（9），组播前缴（10），会话ID（11）和服务器时标（12），值7和值8是预留的，范围0～49151的选项类型预留给IANA机构分配。49152～65535范围内的数值尚未注册可用于实验。各选项的详细定义如下。a）版本，类型0：长度应为1字节。所有的消息中都应包含该选项。对于本协议该版本值设为2。请注意该协议的早期实现只是部分地遵循该标准。它们可被认定为版本1并且不使用该选项。如果服务器接收到版本大于2或无版本的消息，服务器（除非支持特殊版本）发送服务器响应消息的时候，将版本置为2。这时如果该消息中存在客户端D和序列号选项则需原样返回，服务器不应包含其他任何选项。接收到版本号大于2的客户端应中止发送请求到服务器（除非它支持特殊的版本）。b）客户端ID，类型1：长度应为非0。客户端应在所有消息的选项中包含该选项（无论初始消息还是响应请求）。客户端可使用任何值用以检测应答是是否是针对初始/响应请求消息。服务器应把该选项看成透明数据，并且如果在请求中存在则需在应答中原样返回该选项。该选项值可以是一个处理ID，也可以是一个与IP地址组合的处理ID，以区分来自其他客户端的消息。客户端的实现者决定如何使用该选项。
c）序列号，类型2：长度为4字节。客户端应在响应请求消息中包含这个选项但不能够在初始消息中包含它。对响应请求消息进行应答的服务器应将它拷贝到响应应答中，或者在发生错误时将其拷贝到服务器响应消息中。该选项数值可以典型地从1开始，对每个顺序的响应请求逐1递增。d）客户端时标，类型3：长度应为8字节。客户端在响应请求应包含此选项，但必不能在初始消息中包含该选项。对响应请求消息进行应答的服务器应将其拷贝到响应应答中。该选项可设为响应请求消息发送的时间，前4个字节限定了从初始历元（Epoch，1970年1月1日，UTC0000）计算的以秒数表示的时间。下4个字节限定从前4个字节的开始的毫秒数。e）组播组，类型4：长度应大于2字节；可以用于服务器响应消息中告诉客户端在后面的响应请求消息中使用哪个组。它应包含在响应请求中告诉服务器应响应哪个组地址（通常该组地址可以从前面服务器响应消息中获得）。它应在响应应答消息中使用（从响应请求消息中拷贝）。但不能在初始消息中使用。选项值的格式如图2所示。0123456789012345678901234567890地质族
图2组播组选项
组播组地址
地址族由IANA设定，值的范围为065535，后面跟着组地址，选项值的长度对于IPv4为6字节，对于IPv6为18字节。
f）选项请求选项，类型5。
YD/3308—2017
一长度应大于1字节。该选项可以在客户端发送的消息（初始和响应请求消息）中使用。服务器必不能发送这个选项，除非该选项出现在响应请求消息中，服务器应在响应应答消息中将该选项原样返回。该选项包含客户端向服务器请求的一个选项类型的列表，对该选项的支持对客户端和服务器都是可选的。选项的长度为一个非0的偶数字节数，因为它包含一个或多个两字节长的选项类型。选项值的格式如图3所示。0123456789012345678901
选项类型
图3选项请求选项
567890
选项类型
一、该选项可以被客户端用来请求服务器包含时标或服务器信息等选项。客户端可以在初始消息中请求服务器信息选项：它必不能在其他的消息中请求该选项。客户端可以在响应请求消息中请求时标选项，它必不能在其他消息中请求该选项。受上述限制的制约，支持选项请求选项的服务器，应该在对包含特定的选项请求选项的响应请求消息进行响应应答时包含该特定的选项。
服务器可以根据实现或本地配置，不必包含所有客户端请求的选项，可以只包含一个选项。任何被请求的选项都被附加在其他原样返回的选项后面。g）服务器信息，类型6：长度应为非0，可用在服务器响应消息中，但必不能在其他消息中使用。对该选项的支持是可选的。支持该选项的服务器只有当客户端请求时才在服务器响应消息中添加该选项。选项只为UTF-8字符串，可以包含服务器的设备商或版本信息，也可以包含服务器支持的选项信息。交互式客户端可以支持该选项，也应当允许用户请求该字符串并显示它。h）预留，类型7：该选项曾为早期版本使用。客户端必不能使用该选项，服务器应把它看成是未知的选项（接收到不处理）。但如果在响应请求中接收到，则服务器应在响应应答消息中原样返回。i）预留，类型8：该选项曾为早期版本使用。客户端必不能使用该选项，服务器应把它看成是未知的选项（接收到不处理）。但如果在响应请求中接收到，则服务器应在响应应答消息中原样返回j）TTL，类型9。长度必须为1字节。该选项包含单一字节，限定一个响应应答消息的TTL值。每次服务器发送单播或组播响应应答消息，都应该包含此限定TTL的选项。该选项可被客户端使用用来确定消息传递的跳数。它必不能在其他消息中使用。如果服务器知道响应应答的TTL值，则服务器应该选定这个选项。通常情况下服务器可以将该TTL值设定到主机栈中。请注意TTL不一定对于单播和组播是相同的。也需注意即使客户端不请求这个选项，它也应被包含在响应应答中。k）组播前缀，类型10。
长度应大于2字节，如图4所示。可以在初始消息中请求前缀表示的组，也可在服务器响应消息中使用，以告诉客户端它可以使用哪些组。它必不能在响应请求和响应应答消息中使用。需注意该选项也可包含多次用于限定多个前缴。6
01234567890123456789012345678901地质族
前缓长度
图4组播前缀
部分地址
YD/T3308—2017
一地址族取值范围为0～65535，由IANA设定。前缀长度取值范围对于IPv4为4比特～32比特，对于IPv6为8比特～128比特，当取值为0时表示通配符。报文的最后是组地址。对任何组地址族，前缀长度0意味者该地址族的任意组播地址都是可以接收的，因而叫做通配符。组地址仅需包含覆盖前缀长度比特的足够的字节（例如，如果前缀长度为12比特～24比特，组地址应为3字节；而在前缀长度为0，即通配符情况下，则无需携带组地址）。任何超出前缀长度的比特必须被忽略。对于IPv4，选项值长度为4字节～7字节，而对于IPv6，选项值长度为4字节～19字节，而对于通配符，选项值长度为3字节。L）会话ID，类型11：长度应为非0字节数。服务器应在服务器响应消息中包含该选项。如果客户端接收到该选项，客户端应在接下来的响应请求消息中包含相同的会话ID选项。会话ID应被设为伪随机数，使得其值难于预测。会话ID可用来预防在响应请求消息中进行源地址欺骗。m）服务器时标，类型12：长度必8字节。如果客户端请求，则支持该选项的服务器需要在响应应答消息中包含它。时标限定为发送响应应答消息的时间。前4个字节限定了从初始历元（Epoch，1970年1月1日，UTC0000）计算的以秒数表示的时间，其后4个字节限定了秒数后面的毫秒数。4.2.3消息格式及定义bzxZ.net
所有的消息都是由一个字节的消息类型加上可变长度的选项构成，如图5所示。0123456789012345678901234567890类型
图5消息格式
选项…
共定义了四种类型的消息。类型81（ASCI码的字符Q）表示响应请求；类型65（ASCI码的字符A）表示响应应答：类型73（ASCI码的字符I）表示初始消息：类型83（ASCII码的字符S）表示服务器响应消息。选项立即跟随着类型字节并不以任何方式对齐，即选项可以在任何字符边界开始。选项格式如4.4.2节所示。
每种消息中包含的选项种类如下所示。a）初始消息，类型73：该消息由客户端发向服务器以请求特定的信息。它主要用于请求一个组播组地址，也可用于检查服务器提供哪些组前缀。它应包含一个版本选项，也应该包含一个客户端ID选项。它可包含选项请求选项和组播前缀选项。只有包含组前缀选项时才可用来请求一个组地址。如果包含多个前缀选项，则前缀应以优先级顺序排列，服务器将根据限定的优先级顺序考虑前缀，如果找到了对应于一个前缀的组，它将只返回这个组，而不考虑其余的前缀。7
YD/T3308—2017
b）服务器响应消息，类型83：该消息由服务器发送，或者是初始消息的一个响应，或者是响应请求的一个响应。当作为初始消息的响应时，它可以向客户端提供一个组播组（如果为客户端所请求），或者提供其他的服务器信息。当作为响应请求的响应，可以告诉客户端停止发送响应请求。该消息中总是包含版本选项。客户端ID选项和序列号选项如果在客户端消息中出现，将在该响应中被原样返回。当向客户端提供一个组时，消息中需包含组播组选项，如果被请求也可包含服务器信息和前缀选项。c）响应请求，类型81：该消息由客户端发送，请求服务器发送单播和组播响应应答。它应包含版本、序列号和组播组选项。如果客户端在前面的服务器响应消息中接收到会话ID，则应包含会话ID。此外它应该包含客户端ID和客户端时标选项，可以包含选项请求选项。d）响应应答，类型65：该消息由服务器发送，作为响应请求的响应。此消息总是成对出现，一个单播发送，一个组播发送，两个消息的内容大致相同。服务器总是原样返回响应请求中的所有选项（会话ID除外）。响应请求中任何服务器不支持的选项，也将被原样返回。两个响应应答消息总是包含TTL选项（单播和组播设定的值可能不同）。两个响应应答消息当被请求时也应包含服务器时标选项（单播和组播可设定不同的数值）。
4.2.4速率限制
客户端应默认每秒发送至多一个响应请求，服务器应默认执行限速，以防止该协议被利用来实行DoS攻击。服务器应默认对于一个给定的客户端，平均每秒至多对一个响应请求消息进行应答。服务器实现也应提供配置选项以允许特定的客户端以更快速的发送响应请求。如果特定的客户端IP地址允许更高的速率，则应使用初始消息和会话ID选项以防止欺骗的发生。该协议和应用的实现者应考虑UDP的使用规则（见IETFRFC5405），特别是当客户端发送和服务器接收的速率超过每秒1个的情况下。4.3客户端行为
客户端仅要求用户限定服务器的单播地址，然后即可发送携带前缀选项（包含组地址选项和零前缀长度）的初始消息。然后，服务器决定应在该地址族上返回哪个组。客户端可允许用户限定组地址或前缀（对于IPv6，用户可以仅要求限定一个范围或一个RP地址，客户端可构建所需的前缀，如嵌入式RP）。客户端在初始消息中可限定一个或多个前缀选项以告诉服务器它希望使用的地址。如果用户限定了一个组地址，组地址可以采用最大前缀长度编码（例如IPv4为32比特）。前缀选项以优先级顺序排列，将优先级最高的前缀放在最前面。如果客户端接收到包含组地址的服务器响应消息时，它可发送响应请求消息。如果没有组地址选项！客户端将典型的错误退出。服务器可能在服务器响应消息中包含某些前缀选项，客户端使用前缀选项向用户提供可用的前缀或可用的前缀范围。假定客户端在服务器响应消息中获得一个组地址，在让用户知道该组播组将被使用后，可启动组播Ping。通常，客户端应每秒钟至多发送一个响应请求。当发送响应请求时，客户端应总是包含组选项。如果服务器响应消息中包含会话ID，则响应请求中应包含取值完全相同的同一选项。如果客户端发送响应请求后接收到服务器响应消息（即，服务器响8
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。