Computer networking end-to-end protocols: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
(Performance -- need to come up with better wording than the two-level link, and a generally accepted term for loss/error analogous to bw and latency)
imported>Howard C. Berkowitz
(Filled out RSVP)
Line 1: Line 1:
{{subpages}}
{{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 OSI Reference Model puts the function primarily into the [[transport layer]].  
'''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|OSI 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.
Line 92: Line 92:
:*Note 2: indirect, using the RTCP monitoring receiver
:*Note 2: indirect, using the RTCP monitoring receiver
==Resource Reservation Protocol==
==Resource Reservation Protocol==
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
| id = RFC2208
| title =  Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement: Some Guidelines on Deployment.
| authors = Mankin, A. ''et al.''
| date = September 1997.
| publisher = Internet Engineering Task Force
}}</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. A number of historic tunneling protocols carried fundamentally different delivery protocols, such as Novell IPX, over an Internet Protocol delivery network.
Tunneling protocols are usually needed, in the Internet, when an IP payload packet has addresses incompatible with those of the delivery network. A number of historic tunneling protocols carried fundamentally different delivery protocols, such as Novell IPX, over an Internet Protocol delivery network.
Line 109: Line 117:


==Performance issues==
==Performance issues==
See [[Transmission Control Protocol#TCP over paths with specific performance characteristics]] for issues concerned with high [[bandwidth]] and long [[latency]]. See [[User Datagram Protocol#Use with applications that can use damaged data]] for certain kinds of error tolerance.
[[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]].


==References==
==References==
{{reflist|2}}
{{reflist|2}}

Revision as of 09:10, 14 May 2008

This article is developing and not approved.
Main Article
Discussion
Definition [?]
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

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 OSI model puts the function into its 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

Three 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.

Feature TCP UDP RTP/RTCP
Connection orientation Yes No Yes[1]
Reliable delivery of ordered packets Yes No Yes
Reliable delivery but may reorder packets No No No
Data error detection Yes Yes Yes
Data error correction Yes No No
Flow and congestion control Yes No Yes[2]
Multiple data streams between endpoints No No Yes
  • Note 1: unidirectional data transfer
  • Note 2: indirect, using the RTCP monitoring receiver

Resource Reservation Protocol

The 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 protocols

Tunneling protocols are usually needed, in the Internet, when an IP payload packet has addresses incompatible with those of the delivery network. A number of historic tunneling protocols carried fundamentally different delivery protocols, such as Novell IPX, over an Internet Protocol delivery network.

Generic Route Encapsulation

IP in IP

Cryptographic mechanisms with attributes of end-to-end protocols

IPSec Authentication Header

IPSec Encapsulating Security Payload Header

IPSec Transport Mode

IPSec Tunnel Mode

Performance issues

Transmission Control Protocol (TCP) has 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 tolerate errors in data more than it can tolerate data loss.

References

  1. Postel, J. (August 1980), User Datagram Protocol, Internet Engineering Task Force, RFC0768
  2. Postel, J. (September 1981), Transmission Control Protocol, Internet Engineering Task Force, RFC0793
  3. Schulzrinne, H.; S. Casner & R. Frederick et al. (July 2003), RTP: A Transport Protocol for Real-Time Applications, Internet Engineering Task Force, RFC3550
  4. Schulzrinne, H.; A. Rao & R. Lanphier (April 1998), Real Time Streaming Protocol, Internet Engineering Task Force, RFC2326
  5. Mankin, A. et al. (September 1997.), Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement: Some Guidelines on Deployment., Internet Engineering Task Force, RFC2208