可靠传输协议（RTP，Reliable Transport Protocol）负责管理ElGRP数据包的发送和接收。可靠传输意味着传输是有保障的，并且数据包会被按顺序发送。这种传输效果是依靠Cisco发明的名为可靠组播的算法实现的。使用可靠传输的数据包类型包括更新包、 查询包、响应包、SIA查询包和SIA响应包，这与发送这些数据包的形式（单播或组播）无关（当然了，SIA查询包、响应包和SIA响应包只会以单播形式发送）。这些数据包的头部都会携带一个非零的序列号。这个序列号是一个全局值，由路由器上的每个EIGRP进程进行维护；每当这个ElGRP进程发出一个这种数据包，无论这个数据包将会从哪个启用了 EIGRP的接口发送出去，序列号都会增加。接收到更新包、查询包、响应包、SIA查询包或 SIA响应包的邻居都需要发回一个ACK包，并将ACK包中的确认号设置为之前收到的数据包的序列号。邻居还可以用另一种方式确认可靠数据包，就是在自己的可靠数据包（如果有要发往相同路由器的可靠数据包）中确认对方发来的可靠数据包，只需在数据包头部正确设置确认号就可以了，详见前文“确认包”小节。如果在特定时间段内没有收到确认信息， EIGRP就会以单播的形式向未响应邻居重传未确认的数据包。
对于那些不使用可靠传输的数据包类型（Hello包和ACK包）．它们的序列号字段设置 为0．并且这个全局序列号并不会增长。
在使用这个单纯的可靠组播时，组播消息的每一个接收方都必须对发送方做出确认， 才能促使发送方继续传输下一个消息。如果有一些接收方没有进行消息确认，发送方就会 延缓下一步组播发送行为，而是以单播形式向未确认的接收方重传丢失的消息，直到接收方成功确认它收到了该消息为止。很显然，只要有一个行为不当、超载或连接性很差的接收方，就会对整个可靠组播的传输造成不良影响。一个直观的解决方案是在继续发送组播数据包的同时，以单播形式按顺序向那个“滞后”的接收方发送未确认的消息以及后续延缓发送的数据包，让它最终能够跟上大家的进度。不过这样做会带来一个问题：滞后的那个邻居也仍然是组播组中的成员，如果它在收到前一个数据包之前．恰好先收到了后一个 数据包．那它对于信息流的处理顺序就错乱了。
为了解决这个问题.RTP使用了一个与众不同的特性.称为条件接收（Conditional Receive)。通过使用这个特性.EIGRP可以把一个多访问接口上的所有邻居分为两个组：一个行为得当组.这个组中的邻居能够按时确认所有组播消息；另一个“滞后”组.这个组中的邻居至少有一次没有按时确认EIGRP的可靠数据包.EIGRP必须对这些邻居进行单独处理。如果EIGRP希望一边发送组播数据包.一边以单播形式向滞后路由器重传未确认的数据包.它就必须在按顺序传输的组播数据包中打上一个特殊的标记.表示“这个数据包只发给那些到目前为止.收到了所有组播数据包的路由器”。
上述解决方案是这样实现的：发送方首先发送一个Hello包.其中包含两个特殊的 TLV:序列TLV和下一个组播序列TLV.这个数据包通常被称为序列Hello包。下一个组播序列TLV中包含接下来要发送的下一个可靠组播消息的序列号。序列TLV中列出了所有滞后邻居的IP地址.向所有接收方表明：“如果谁在这个列表中找到了自己的IP地址.就忽略拥有这个序列号的下一个组播消息”。邻居在收到这个序列Hello包后.如果没有在序列TLV 的列表中找到自己的IP地址.那它就知道自己可以接收接下来的组播数据包.并且它会把自己置为CR模式（条件接收模式）。邻居在收到这个序列Hello包后.如果在序列TLV的列表中找到了自己的IP地址.或者邻居干脆就没有收到这个序列Hello包.它就不会把自己置为CR模式。在此之后.发送方路由器会在下一个组播数据包的标记字段中.设置CR标记。置为CR模式的路由器会如常处理这个数据包.然后退出CR模式；未被置为CR模式的路由器则会忽略这个数据包。这样一来.发送方路由器既能够一直以组播形式向那些没有接收障碍且能够按时确认的路由器发送消息.同时也能够确保那些滞后邻居不会处理这些组播消息.直到它们能够赶上大家的进度。没能够确认一个或多个组播数据包的邻居就会成为滞后邻居.每个滞后邻居都会按顺序.以单播形式收到它们没能确认的信息。
路由器会按照组播流计时器中定义的时间来等待ACK包.在计时器超时后.它才会将相应的邻居认定为滞后邻居.并转换为使用单播形式向其发送信息。后续单播数据包的发送间隔是由RT0 (重传超时）定义的。这两个计时器（组播流计时器和RT0)是根据每个邻 居的SRTT (平滑往返时间）计算出来的。SRTT是一个以毫杪为单位的平均用时.测量的是向邻居发送可靠数据包与从邻居收到确认包之间所经过的时间。具体用来汁算SRTT、RT0 和组播流计时器的公式超出了本书范围。