Internetwork protocol: Difference between revisions
Content deleted Content added
m correct minus sign in superscript |
m Bot: Fixing double redirect to Communication protocol |
||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
#REDIRECT [[Communication protocol]] |
|||
{{mergeto|network protocol|date=January 2015}} |
|||
In [[computer network|networking]], a '''[[communications protocol]]''' or '''network protocol''' is the specification of a set of rules for a particular type of [[communication]]. |
|||
{{Redirect category shell|1= |
|||
Multiple [[Protocol (computing)|protocols]] often describe different aspects of a single communication. A group of protocols designed to work together are known as a protocol suite; when implemented in software they are a [[protocol stack]]. The terms are often intermingled; people may use the term "protocol" to refer to a software implementation, or use "protocol stack" to refer to the specification. |
|||
{{R from merge}} |
|||
}} |
|||
Most recent protocols are assigned by the [[IETF]] for [[Internet]] communications, and the [[IEEE]], or the [[International Organization for Standardization|ISO]] organizations for other types. The [[ITU-T]] handles telecommunications protocols and formats for the [[PSTN]]. As the PSTN and Internet converge, the two sets of standards are also being driven towards convergence. |
|||
== Network protocol design principles == |
|||
[[Systems engineering]] principles have been applied to create a set of common [[network protocol design principles]]. |
|||
=== Protocol layering === |
|||
In modern protocol design, [[network protocol|protocols]] are "layered". Layering is a design principle which divides the protocol design into a number of smaller parts, each of which accomplishes a particular sub-task, and interacts with the other parts of the protocol only in a small number of well-defined ways. |
|||
For example, one layer might describe how to encode text (with [[ASCII]], say), while another describes how to inquire for messages (with the Internet's [[simple mail transfer protocol]], for example), while another may detect and retry errors (with the Internet's [[transmission control protocol]]), another handles addressing (say with IP, the [[Internet Protocol]]), another handles the encapsulation of that data into a stream of bits (for example, with the [[point-to-point protocol]]), and another handles the electrical encoding of the bits, (with a V.42 [[modem]], for example). |
|||
Layering allows the parts of a protocol to be designed and tested without a [[combinatorial explosion]] of cases, keeping each design relatively simple. Layering also permits familiar protocols to be adapted to unusual circumstances. For example, the mail protocol above can be adapted to send messages to aircraft. Just change the [[V.42]] modem protocol to the INMARS LAPD data protocol used by the international marine radio satellites. |
|||
The reference model usually used for layering is the [[OSI seven layer model]], which can be applied to any protocol, not just the OSI protocols. In particular, the Internet Protocol can be analysed using the [[OSI model]]. |
|||
=== [[Error detection]] and [[error correction|correction]] === |
|||
It is a [[truism]] that communication media are always faulty. The conventional measure of quality is the number of failed bits per bit transmitted. This has the wonderful feature of being a dimensionless figure of merit that can be compared across any speed or type of communication media. |
|||
In [[telephony]], failure rates of 10<sup>−4</sup> [[bit per bit]] are faulty (they interfere with [[telephone]] conversations), while 10<sup>−5</sup> bit per bit or more should be dealt with by routine maintenance (they can be heard). |
|||
Communication systems correct errors by selectively resending bad parts of a [[message]]. For example, in TCP (the internet's Transmission Control Protocol), messages are divided into [[packet (information technology)|packet]]s, each of which has a checksum. When a [[checksum]] is bad (meaning the checksum on the receiver does not match the checksum on the sender), the packet is discarded. When a packet is lost, the receiver acknowledges all of the packets up to, but not including the failed packet. Eventually, the sender sees that too much time has elapsed without an acknowledgement, so it resends all of the packets that have not been acknowledged. At the same time, the sender backs off its rate of sending, in case the packet loss was caused by saturation of the path between sender and receiver. (Note: this is an oversimplification: see [[Transmission Control Protocol|TCP]] and [[congestion collapse]] for more detail) |
|||
In general, the performance of TCP is severely degraded in conditions of high packet loss (more than 0.1%), due to the need to resend packets repeatedly. For this reason, [[TCP/IP]] connections are typically either run on highly reliable fiber networks, or over a lower-level protocol with added error-detection and correction features (such as modem links with [[Automatic repeat request|ARQ]]). These connections typically have uncorrected bit error rates of 10<sup>−9</sup> to 10<sup>−12</sup>, ensuring high TCP/IP performance. |
|||
=== Resiliency === |
|||
Another form of network failure is topological failure, in which a communications link is cut, or degrades below usable quality. Most modern communication protocols periodically send messages to test a link. In phones, a framing bit is sent every 24 bits on [[T-carrier system|T1]] lines. In phone systems, when "sync is lost", fail-safe mechanisms reroute the signals around the failing equipment. |
|||
In [[packet switched]] networks, the equivalent functions are performed using [[Router (computing)|router]] update messages to detect loss of connectivity. |
|||
== Protocol families == |
|||
Various [[protocol stack]]s or families: |
|||
* [[PARC Universal Packet|PUP]] |
|||
* [[Internet protocol suite]] |
|||
* [[AppleTalk]] |
|||
* [[DECnet]] |
|||
* [[IPX/SPX]] |
|||
* [[Open Systems Interconnection]] (OSI) |
|||
* [[Systems Network Architecture]] (SNA) |
|||
== See also == |
|||
* [[Protocol (computing)]] |
|||
* [[List of network protocols]] |
|||
* [[Network architecture]] |
|||
* [[Congestion collapse]] |
|||
* [[Tunneling protocol]] |
|||
== Further reading == |
|||
* [[Radia Perlman]], ''Interconnections: Bridges, Routers, Switches, and Internetworking Protocols (2nd Edition)''. Addison-Wesley 1999. ISBN 0-201-63448-1. In particular Ch. 18 on "network design folklore". |
|||
* [[Gerard J. Holzmann]], ''Design and Validation of Computer Protocols''. Prentice Hall, 1991. ISBN 0-13-539925-4. Also available online at http://spinroot.com/spin/Doc/Book91.html |
|||
== External links == |
|||
* [http://www.javvin.com/protocolsuite.html Javvin's Protocol Dictionary] |
|||
[[Category:Network protocols|*]] |
|||
[[da:Datanetprotokol]] |
|||
[[de:Netzwerkprotokoll]] |
|||
[[es:Protocolo de red]] |
|||
[[eo:Protokolo]] |
|||
[[fr:Protocole de communication]] |
|||
[[ja:通信プロトコル]] |
|||
[[pl:Protokoły komunikacyjne]] |
|||
[[ru:Сетевой протокол]] |
|||
[[zh:网络传输协议]] |
|||
Latest revision as of 11:08, 2 December 2017
Redirect to:
This page is a redirect. The following categories are used to track and monitor this redirect:
|