RTP in EIGRP
By stretch | Saturday, January 17, 2009 at 12:49 a.m. UTC
I want to clear up something that has somewhat bothered me for a while now: "RTP" in EIGRP. RTP as referenced by EIGRP refers to Cisco's proprietary Reliable Transport Protocol, not the much more commonly discussed Real-time Transport Protocol characteristic of VoIP communications. This is an unfortunate collision of acronyms.
Reliable Transport Protocol (unlike VoIP's RTP) is not a wire-level protocol; rather, it simply provides sequencing and acknowledgment for EIGRP packets between neighbors. You can see Reliable Transport Protocol in action when observing any EIGRP adjacency (here's an example packet capture).
Sequence and acknowledgment numbers are used to provide ordering similar to TCP, but without any fancy windowing or congestion control (only one packet can be sent at a time). Additionally, hellos and explicit acknowledgments aren't transmitted reliably (they have no sequence number).
Posted in Routing
Comments
January 17, 2009 at 1:03 p.m. UTC
Another interesting detail about EIGRP RTP, is the ability to use piggyback acknowledgements instead of an explicit ACK. When a router has to acknowledge a packet from it's neighbor, he can just put the according ack number in any unicast packet destined to the other neighbor. I read about this behaviour the first time in "EIGRP Network Design Solutions". It can be observed in packets 15 and 16. 10.0.0.2 sends a routing updated and also acknowledges packet 15 from 10.0.0.1 in one packet.
January 18, 2009 at 3:22 a.m. UTC
Nice! This was always something that bothered me too. It really annoyed me how Cisco never really talked about how the two acronyms are not the same protocol either.
January 18, 2009 at 10:22 a.m. UTC
And this is what Cisco writes about RTP in the Internetwork Technologie Handbook:
"Reliable Transport Protocol (RTP) is responsible for guaranteed, ordered delivery of EIGRP packets to all neighbors. It supports intermixed transmission of multicast or unicast packets. For efficiency, only certain EIGRP packets are transmitted reliably. On a multiaccess network that has multicast capabilities, such as Ethernet, it is not necessary to send hello packets reliably to all neighbors individually. For that reason, EIGRP sends a single multicast hello packet containing an indicator that informs the receivers that the packet need not be acknowledged. Other types of packets, such as updates, indicate in the packet that acknowledgment is required. RTP contains a provision for sending multicast packets quickly when unacknowledged packets are pending, which helps ensure that convergence time remains low in the presence of varying speed links."
So, it is really documented.
January 18, 2009 at 10:24 a.m. UTC
But the problem with this "collision" is also with other acronyms like ASA: "Adaptive Security Algorithm" or "Adaptive Security Appliance". It's even worse in the official course-material of Cisco where POP in a provider-network was explained with "Post Office Protocol", HTTP Post in the Application-layer Firewall with "Power on Selftest" and the check of AV-DAT-Files through NAC with "Digital Audio Tape".
September 9, 2009 at 7:43 p.m. UTC
Cool post. I took a look at the packet capture and it answers another one of my questions. Namely, since RTP allows both unicast and multicast, how does it keep the routers from being confused from the skipped sequence numbers?
It looks like the answer is the "Next Multicast Sequence" TLV, which shows up in one of the Hello packets in this capture. This is sent out after it is done with the initial adjacency setup, which was unicast.
This also shows a little bit of another feature, which is called "conditional receive" mode. From what I could find online, it uses the "Sequence" TLV to list neighbors which are in unicast mode (either due to timeout or initialization), so they will know to ignore the following multicast packets. Then it sends the next multicast packets with the conditional receive flag set, so those neighbors will know to ignore the packets. Still not too clear on that one, but I think this is as good as it gets without any documentation from Cisco.
June 4, 2010 at 8:17 a.m. UTC
The latest version of the ICND2 text does give an explanation as to the potential mix up:
"NOTE The acronym RTP also refers to a different protocol, Real-time Transport Protocol (RTP), which is used to transmit voice and video IP packets." (ICND2 Official Exam Ceer Guide, CH10 EIGRP)
Maybe one day we will run out of acronyms and be forced to speak English
November 24, 2011 at 3:26 p.m. UTC
Great article, but I have still one question. Reliable Transport Protocol (RTP) is, as the name implies, a protocol. So, it should "lay" in some layer of the OSI model or, better (i.e., not so theoretical), of the TCP/IP Protocol Stack.
Since it seems that it has pretty-much the same functionallity with TCP (with some differences that you have pointed out) when it operates in a "reliable mode" (e.g., when the router sends update, query, and reply packets, that is, packets sent reliably and requiring an acknowledgment)and with UDP when it operates in a "unreliable mode" (e.g., when the routers sends hello or ACK packets), it makes sense that it is an OSI Layer 4 (Transport layer) protocol, as its name also suggests.
However, in the literature or in the web, I have not found so far in which OSI layer RTP fits. I think this is important because a Transport layer protocol is not actually a delivery mechanism. It is used only to guarantee a reliable end-to-end communication via sequencing, acknowledgements, etc. On the other hand, if RTP is just a part of EIGRP, then it may be a Network layer (Layer 3) protocol, and in that case it would be the delivery mechanism of EIGRP (or at least, the first delivery mechanism of EIGRP packets, because after that the EIGRP packet is encapsulated inside a Layer 3 packet, being an IP packet or an IPX packet or whatever, depending on the Protocol-Dependent Module (PDM)).
If someone knows, please help ... Thank you!
February 3, 2012 at 11:05 a.m. UTC
I'd say that RTP is not a protocol. It is a feature (or mechanism) of the EIGRP. If it was a protocol you could seperate this from EIGRP somehow - which you can't.
February 3, 2012 at 1:21 p.m. UTC
@Samba: A protocol is any set of rules which govern some action or communication; a networking protocol doesn't necessarily have to exist as a distinct header in a packet capture.
September 16, 2012 at 5:28 a.m. UTC
excellent post! very nice explanation. This thing bothered me too.