Computer networking end-to-end protocols: Difference between revisions
imported>Howard C. Berkowitz |
mNo edit summary |
||
(6 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{subpages}} | {{PropDel}}<br><br>{{subpages}} | ||
'''End-to-end protocols''' are responsible for the transfer of data from a source to one or more network endpoints. "End-to-end" is the Internet architectural term, while the | '''End-to-end protocols''' are responsible for the transfer of data from a source to one or more network endpoints. "End-to-end" is the Internet architectural term, while the Open Systems Interconnection Reference Model|Open Systems Interconnection Reference Model puts the function into its Open Systems Interconnection Reference Model#Layer 4 (Transport)| transport layer. | ||
A broader definition, however, lets the idea of this layer include tunneling: the endpoint that encapsulates a packet is logically at the transport layer, even though it is not the true application endpoint. | A broader definition, however, lets the idea of this layer include tunneling: the endpoint that encapsulates a packet is logically at the transport layer, even though it is not the true application endpoint. | ||
The basic end-to-end protocols send information between two true endpoints, or to a '''midbox''' that acts as a '''proxy''' for an endpoint host. There are also related protocols that set up end-to-end paths with a specific | The basic end-to-end protocols send information between two true endpoints, or to a '''midbox''' that acts as a '''proxy''' for an endpoint host. There are also related protocols that set up end-to-end paths with a specific quality of service. Yet another type, '''tunneling protocol''' takes the of a packet from a '''payload protocol''', and wraps it in a '''delivery protocol''' to pass it across a network that might not be compatible with the format of the payload packet. Closely related are protocols that set up a security association between two points and apply some type of encryption, for purposes such as data integrity, data authentication, or data confidentiality function. | ||
Proxy midboxes, such as tunneling devices, firewalls, and | Proxy midboxes, such as tunneling devices, firewalls, and network address translators terminate the end-to-end stream and convey an independent end-to-end stream either to the true host or to another midbox. They manipulate the received packet in one or more useful ways, such as stripping the delivery protocol from a tunneled packet, terminate a high-overhead security function. | ||
==End-to-end protocols for the Internet Protocol Suite== | ==End-to-end protocols for the Internet Protocol Suite== | ||
"Two and a half" protocols provide a classic end-to-end service: | "Two and a half" protocols provide a classic end-to-end service: | ||
:*''' | :*'''User Datagram Protocol'''<ref name=RFC0768>{{citation | ||
| url = http://www.ietf.org.rfc/rfc0768.txt | | url = http://www.ietf.org.rfc/rfc0768.txt | ||
| title = User Datagram Protocol | | title = User Datagram Protocol | ||
Line 18: | Line 18: | ||
| publisher = Internet Engineering Task Force | | publisher = Internet Engineering Task Force | ||
}}</ref> | }}</ref> | ||
:*''' | :*'''Transmission Control Protocol''' <ref name=RFC0793>{{citation | ||
| url = http://www.ietf.org.rfc/rfc0793.txt | | url = http://www.ietf.org.rfc/rfc0793.txt | ||
| title = Transmission Control Protocol | | title = Transmission Control Protocol | ||
Line 26: | Line 26: | ||
| publisher = Internet Engineering Task Force | | publisher = Internet Engineering Task Force | ||
}}</ref> There have been a number of modifications and guidelines for use, which help improve performance. These are discussed in the TCP article. | }}</ref> There have been a number of modifications and guidelines for use, which help improve performance. These are discussed in the TCP article. | ||
:*''' | :*'''Real Time Transport Protocol''' is the "half" protocol, as its segments run over UDP.<ref name=RFC3550>{{citation | ||
| id = RFC3550 | | id = RFC3550 | ||
| url = http://www.ietf.org.rfc/rfc3550.txt | | url = http://www.ietf.org.rfc/rfc3550.txt | ||
Line 33: | Line 33: | ||
| date = July 2003 | | date = July 2003 | ||
| publisher = Internet Engineering Task Force | | publisher = Internet Engineering Task Force | ||
}}</ref> (RTP) is different in that its packets ride on top of UDP packets, but is usually considered an end-to-end protocol for one-way transfer, perhaps of a one-to-many | }}</ref> (RTP) is different in that its packets ride on top of UDP packets, but is usually considered an end-to-end protocol for one-way transfer, perhaps of a one-to-many multicast for distribution of real-time information such as voice over IP or streaming video. There are a number of specifications for the different payloads that RTP can carry; see the RTP article. | ||
Rather than getting feedback in the form of RTP packets, the individual recipients send control information back to the transmitting endpoint, using the ''' | Rather than getting feedback in the form of RTP packets, the individual recipients send control information back to the transmitting endpoint, using the '''Real Time Transport Control Protocol''' (RTCP), which is documented in the RTCP specification. RTCP, as an abbreviation, is somewhat unfortunate since it has nothing to do with TCP, the Transmission Control Protocol. | ||
The ''' | The '''Reliable Stream Transfer Protocol''' (RSTP) is an application-level protocol that helps a real-time application select the appropriate end-to-end protocol for the data to be transmitted. <ref name=RFC2326>{{citation | ||
| url = http://www.ietf.org.rfc/rfc2326.txt | | url = http://www.ietf.org.rfc/rfc2326.txt | ||
| id = RFC2326 | | id = RFC2326 | ||
Line 93: | Line 93: | ||
==Resource Reservation Protocol== | ==Resource Reservation Protocol== | ||
The | The Resource Reservation Protocol does not actually transfer data, but it sets up quasi-connections with a guarantee of latency and loss probability. <ref name=RFC2208>{{citation | ||
| url = http://www.ietf.org.rfc/rfc2208.txt | | url = http://www.ietf.org.rfc/rfc2208.txt | ||
| id = RFC2208 | | id = RFC2208 | ||
Line 100: | Line 100: | ||
| date = September 1997. | | date = September 1997. | ||
| publisher = Internet Engineering Task Force | | publisher = Internet Engineering Task Force | ||
}}</ref>. Once these channels are set up, usually for | }}</ref>. Once these channels are set up, usually for Voice over Internet Protocol (VoIP) or similar delay-sensitive traffic, regular end-to-end protocols, usually RTP over UDP, are used to send information through the channel. | ||
==Tunneling protocols== | ==Tunneling protocols== | ||
Tunneling protocols are usually needed, in the Internet, when an IP payload packet has addresses incompatible with those of the delivery network. | Tunneling protocols are usually needed, in the Internet, when an IP payload packet has addresses incompatible with those of the delivery network. | ||
Line 106: | Line 106: | ||
|IP header for delivery|Tunneling protocol header|Payload protocol| | |IP header for delivery|Tunneling protocol header|Payload protocol| | ||
+----------------------+-------------------------+----------------+ | +----------------------+-------------------------+----------------+ | ||
The simplest network layer tunneling protocol is | The simplest network layer tunneling protocol is IP in IP tunnelinf, which can carry a single IP packet inside another IP packet over a single tunnel. .<ref name=RFC1853>{{citation | ||
| id = RFC 1853 | | id = RFC 1853 | ||
| title = IP in IP Tunneling | | title = IP in IP Tunneling | ||
| author = W. Simpson | | author = W. Simpson | ||
| date=October 1995 | | date=October 1995 | ||
| url = http://www.ietf.org/rfc/rfc1853.txt}}</ref> | | url = http://www.ietf.org/rfc/rfc1853.txt}}</ref> Generic Routing Encapsulation (GRE) has somewhat more overhead, but can carry multiple IPv4 streams, IPv6, or other protocols; GRE conceptually could run over non-IP protocols, unlikely in today's networks.<ref name=RFC1701>{{citation | ||
| id = RFC 1701 | | id = RFC 1701 | ||
| title = Generic Routing Encapsulation (GRE) | | title = Generic Routing Encapsulation (GRE) | ||
Line 123: | Line 123: | ||
| url = http://www.ietf.org/rfc/2.txt}}</ref> A number of historic tunneling protocols carried fundamentally different delivery protocols, such as Novell IPX, over an Internet Protocol delivery network. | | url = http://www.ietf.org/rfc/2.txt}}</ref> A number of historic tunneling protocols carried fundamentally different delivery protocols, such as Novell IPX, over an Internet Protocol delivery network. | ||
While one can get lost in philosophical discissions if | While one can get lost in philosophical discissions if multiprotocol label switching (MPLS) is properly a protocol that tunnels through an IP network, the reality is that it is protocol independent as is GRE. | ||
Even with MPLS, one can reasonably think of the tunneling protocol as carrying packets. | Even with MPLS, one can reasonably think of the tunneling protocol as carrying packets. Layer 2 Tunneling Protocol (L2TP) runs layer 2 frames over UDP in an IP network. Those PPP frames, of course, can carry IP packets. | ||
==Cryptographic mechanisms with attributes of end-to-end protocols== | ==Cryptographic mechanisms with attributes of end-to-end protocols== | ||
Line 138: | Line 138: | ||
==Performance issues== | ==Performance issues== | ||
Transmission Control Protocol (TCP) has Transmission Control Protocol#TCP over paths with specific performance characteristics| mechanisms for dealing with links that have high bandwidth and long latency. User Datagram Protocol (UDP) has a method for working with application protocols that User Datagram Protocol#Use with applications that can use damaged data| tolerate errors in data more than it can tolerate data loss. | |||
==Historic non-Internet== | |||
Historic end-to-end protocols include OSI Transport Protocol (Classes 0-4), Novell SPX, AppleTalk Transaction Protocol, DECnet Network Service Protocol, and, in Xerox Network Services, the Sequenced Packet Protocol and Packet Exchange Protocol. | |||
==References== | ==References== | ||
{{reflist|2}} | {{reflist|2}}[[Category:Suggestion Bot Tag]] |
Latest revision as of 16:00, 31 July 2024
This article may be deleted soon. | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
End-to-end protocols are responsible for the transfer of data from a source to one or more network endpoints. "End-to-end" is the Internet architectural term, while the Open Systems Interconnection Reference Model|Open Systems Interconnection Reference Model puts the function into its Open Systems Interconnection Reference Model#Layer 4 (Transport)| transport layer. A broader definition, however, lets the idea of this layer include tunneling: the endpoint that encapsulates a packet is logically at the transport layer, even though it is not the true application endpoint. The basic end-to-end protocols send information between two true endpoints, or to a midbox that acts as a proxy for an endpoint host. There are also related protocols that set up end-to-end paths with a specific quality of service. Yet another type, tunneling protocol takes the of a packet from a payload protocol, and wraps it in a delivery protocol to pass it across a network that might not be compatible with the format of the payload packet. Closely related are protocols that set up a security association between two points and apply some type of encryption, for purposes such as data integrity, data authentication, or data confidentiality function. Proxy midboxes, such as tunneling devices, firewalls, and network address translators terminate the end-to-end stream and convey an independent end-to-end stream either to the true host or to another midbox. They manipulate the received packet in one or more useful ways, such as stripping the delivery protocol from a tunneled packet, terminate a high-overhead security function. End-to-end protocols for the Internet Protocol Suite"Two and a half" protocols provide a classic end-to-end service:
Rather than getting feedback in the form of RTP packets, the individual recipients send control information back to the transmitting endpoint, using the Real Time Transport Control Protocol (RTCP), which is documented in the RTCP specification. RTCP, as an abbreviation, is somewhat unfortunate since it has nothing to do with TCP, the Transmission Control Protocol. The Reliable Stream Transfer Protocol (RSTP) is an application-level protocol that helps a real-time application select the appropriate end-to-end protocol for the data to be transmitted. [4] Features of these three protocols is summarized below.
Resource Reservation ProtocolThe Resource Reservation Protocol does not actually transfer data, but it sets up quasi-connections with a guarantee of latency and loss probability. [5]. Once these channels are set up, usually for Voice over Internet Protocol (VoIP) or similar delay-sensitive traffic, regular end-to-end protocols, usually RTP over UDP, are used to send information through the channel. Tunneling protocolsTunneling protocols are usually needed, in the Internet, when an IP payload packet has addresses incompatible with those of the delivery network. +----------------------+-------------------------+----------------+ |
Tunneling protocol header|Payload protocol|
+----------------------+-------------------------+----------------+ The simplest network layer tunneling protocol is IP in IP tunnelinf, which can carry a single IP packet inside another IP packet over a single tunnel. .[6] Generic Routing Encapsulation (GRE) has somewhat more overhead, but can carry multiple IPv4 streams, IPv6, or other protocols; GRE conceptually could run over non-IP protocols, unlikely in today's networks.[7].[8] A number of historic tunneling protocols carried fundamentally different delivery protocols, such as Novell IPX, over an Internet Protocol delivery network. While one can get lost in philosophical discissions if multiprotocol label switching (MPLS) is properly a protocol that tunnels through an IP network, the reality is that it is protocol independent as is GRE. Even with MPLS, one can reasonably think of the tunneling protocol as carrying packets. Layer 2 Tunneling Protocol (L2TP) runs layer 2 frames over UDP in an IP network. Those PPP frames, of course, can carry IP packets. Cryptographic mechanisms with attributes of end-to-end protocolsIPSec Authentication HeaderIPSec Encapsulating Security Payload HeaderIPSec Transport ModeIPSec Tunnel ModePerformance issuesTransmission Control Protocol (TCP) has Transmission Control Protocol#TCP over paths with specific performance characteristics| mechanisms for dealing with links that have high bandwidth and long latency. User Datagram Protocol (UDP) has a method for working with application protocols that User Datagram Protocol#Use with applications that can use damaged data| tolerate errors in data more than it can tolerate data loss. Historic non-InternetHistoric end-to-end protocols include OSI Transport Protocol (Classes 0-4), Novell SPX, AppleTalk Transaction Protocol, DECnet Network Service Protocol, and, in Xerox Network Services, the Sequenced Packet Protocol and Packet Exchange Protocol. References
|