Communications protocolFrom Wikipedia, the free encyclopedia Jump to: navigation, search This article may be too long

to read and navigate c omfortably. Please consider splitting content into sub-articles and/or condensin g it. (April 2011) For other uses, see Protocol (disambiguation). A communications protocol is a system of digital message formats and rules for e xchanging those messages in or between computing systems and in telecommunicatio ns. A protocol may have a formal description. Protocols may include signaling, a uthentication and error detection and correction capabilities. Communicating systems use well-defined formats for exchanging messages. Each mes sage has an exact meaning intended to provoke a particular response of the recei ver. Thus, a protocol must define the syntax, semantics, and synchronization of communication; the specified behavior is typically independent of how it is to b e implemented. A protocol can therefore be implemented as hardware, software, or both. Communications protocols have to be agreed upon by the parties involved.[ 1] To reach agreement a protocol may be developed into a technical standard. A p rogramming language describes the same for computations, so there is a close ana logy between protocols and programming languages: protocols are to communication s as programming languages are to computations.[2] Contents [hide] 1 Communicating systems 2 Basic requirements of protocols 2.1 Formal specification 3 Protocols and programming languages 4 Universal protocols 5 Protocol design 5.1 Concurrent programming 5.2 A basis for protocol design 5.3 Layering 5.3.1 Protocol layering 5.3.2 Software layering 5.3.3 Strict layering 6 Protocol development 6.1 The need for protocol standards 6.2 Standards organizations 6.3 The standardization process 6.4 Future of standardization (OSI) 7 Taxonomies 8 Common types of protocols 9 Notes 10 References 11 External links Communicating systems[edit]The information exchanged between devices through a net work, or other media is governed by rules and conventions that can be set out in a technical specifications called a communication protocol standards. The nature of the communication, the actual data exchanged and any state-dependent behavior s, is defined by it's specification. In digital computing systems, the rules can be expressed by algorithms and data structures. Expressing the algorithms in a portable programming language makes t he protocol software operating system independent. Operating systems usually consist of a set of cooperating processes that manipul ate a shared data to communicate with each other. This communication is governed by well-understood protocols, which can be embedded in the process code itself.

[3][4] In contrast, because there is no common memory, communicating systems have to co mmunicate with each other using a shared transmission medium. Transmission is no t necessarily reliable, and individual systems may use different hardware and/or operating systems. To implement a networking protocol, the protocol software modules are interfaced with a framework implemented on the machine's operating system. This framework implements the networking functionality of the operating system.[5] The best kno wn frameworks are the TCP/IP model and the OSI model. At the time the Internet was developed, layering had proven to be a successful d esign approach for both compiler and operating system design and, given the simi larities between programming languages and communication protocols, layering was applied to the protocols as well.[6] This gave rise to the concept of layered p rotocols which nowadays forms the basis of protocol design.[7] Systems typically do not use a single protocol to handle a transmission. Instead they use a set of cooperating protocols, sometimes called a protocol family or protocol suite.[8] Some of the best known protocol suites include: IPX/SPX, X.25 , AX.25, AppleTalk and TCP/IP. The protocols can be arranged based on functionality in groups, for instance the re is a group of transport protocols. The functionalities are mapped onto the la yers, each layer solving a distinct class of problems relating to, for instance: application-, transport-, internet- and network interface-functions.[9] To tran smit a message, a protocol has to be selected from each layer, so some sort of m ultiplexing/demultiplexing takes place. The selection of the next protocol is ac complished by extending the message with a protocol selector for each layer.[10] Basic requirements of protocols[edit]Messages are sent and received on communica ting systems to establish communications. Protocols should therefore specify rul es governing the transmission. In general, much of the following should be addre ssed:[11] Data formats for data exchange. Digital message bitstrings are exchanged. The bi tstrings are divided in fields and each field carries information relevant to th e protocol. Conceptually the bitstring is divided into two parts called the head er area and the data area. The actual message is stored in the data area, so the header area contains the fields with more relevance to the protocol. Bitstrings longer than the maximum transmission unit (MTU) are divided in pieces of approp riate size.[12] Address formats for data exchange. Addresses are used to identify both the sende r and the intended receiver(s). The addresses are stored in the header area of t he bitstrings, allowing the receivers to determine whether the bitstrings are in tended for themselves and should be processed or should be ignored. A connection between a sender and a receiver can be identified using an address pair (sender address, receiver address). Usually some address values have special meanings. An all-1s address could be taken to mean an addressing of all stations on the ne twork, so sending to this address would result in a broadcast on the local netwo rk. The rules describing the meanings of the address value are collectively call ed an addressing scheme.[13] Address mapping. Sometimes protocols need to map addresses of one scheme on addr esses of another scheme. For instance to translate a logical IP address specifie d by the application to an Ethernet hardware address. This is referred to as add ress mapping.[14] Routing. When systems are not directly connected, intermediary systems along the route to the intended receiver(s) need to forward messages on behalf of the sen der. On the Internet, the networks are connected using routers. This way of conn

ecting networks is called internetworking. Detection of transmission errors is necessary on networks which cannot guarantee error-free operation. In a common approach, CRCs of the data area are added to the end of packets, making it possible for the receiver to detect differences ca used by errors. The receiver rejects the packets on CRC differences and arranges somehow for retransmission.[15] Acknowledgements of correct reception of packets is required for connection-orie nted communication. Acknowledgements are sent from receivers back to their respe ctive senders.[16] Loss of information - timeouts and retries. Packets may be lost on the network o r suffer from long delays. To cope with this, under some protocols, a sender may expect an acknowledgement of correct reception from the receiver within a certa in amount of time. On timeouts, the sender must assume the packet was not receiv ed and retransmit it. In case of a permanently broken link, the retransmission h as no effect so the number of retransmissions is limited. Exceeding the retry li mit is considered an error.[17] Direction of information flow needs to be addressed if transmissions can only oc cur in one direction at a time as on half-duplex links. This is known as Media A ccess Control. Arrangements have to be made to accommodate the case when two par ties want to gain control at the same time.[18] Sequence control. We have seen that long bitstrings are divided in pieces, and t hen sent on the network individually. The pieces may get lost or delayed or take different routes to their destination on some types of networks. As a result pi eces may arrive out of sequence. Retransmissions can result duplicate pieces. By marking the pieces with sequence information at the sender, the receiver can de termine what was lost or duplicated, ask for necessary retransmissions and reass emble the original message.[19] Flow control is needed when the sender transmits faster than the receiver or int ermediate network equipment can process the transmissions. Flow control can be i mplemented by messaging from receiver to sender.[20] Getting the data across a network is only part of the problem for a protocol. Th e data received has to be evaluated in the context of the progress of the conver sation, so a protocol has to specify rules describing the context. These kind of rules are said to express the syntax of the communications. Other rules determi ne whether the data is meaningful for the context in which the exchange takes pl ace. These kind of rules are said to express the semantics of the communications . Formal specification[edit]Formal ways for describing the syntax of the communica tions are Abstract Syntax Notation One (an ISO standard) or Augmented Backus-Nau r form (an IETF standard). Finite state machine models[21][22] and communicating finite-state machines[23] are used to formally describe the possible interactions of the protocol. Protocols and programming languages[edit]Protocols are to communications what al gorithms or programming languages are to computations.[24][2] This analogy has important consequences for both the design and the development of protocols. One has to consider the fact that algorithms, programs and protoco ls are just different ways of describing expected behaviour of interacting objec ts. A familiar example of a protocolling language is the HTML language used to d escribe web pages which are the actual web protocols. In programming languages the association of identifiers to a value is termed a d efinition. Program text is structured using block constructs and definitions can be local to a block. The localized association of an identifier to a value esta blished by a definition is termed a binding and the region of program text in wh ich a binding is effective is known as its scope.[25] The computational state is kept using two components: the environment, used as a record of identifier bind ings, and the store, which is used as a record of the effects of assignments.[26

] In communications, message values are transferred using transmission media. By a nalogy, the equivalent of a store would be a collection of transmission media, i nstead of a collection of memory locations. A valid assignment in a protocol (as an analog of programming language) could be Ethernet:='message' , meaning a mes sage is to be broadcast on the local ethernet. On a transmission medium there can be many receivers. For instance a mac-address identifies an ether network card on the transmission medium (the 'ether'). In o ur imaginary protocol, the assignment ethernet[mac-address]:=message value could therefore make sense.[27] By extending the assignment statement of an existing programming language with t he semantics described, a protocolling language could easily be imagined. Operating systems provide reliable communication and synchronization facilities for communicating objects confined to the same system by means of system librari es. A programmer using a general purpose programming language (like C or ADA) ca n use the routines in the libraries to implement a protocol, instead of using a dedicated protocolling language. Universal protocols[edit]The nice thing about standards is that you have so many to choose from. Andrew S. Tanenbaum in Computer Networks[28] Despite their numbers, networking protocols show little variety, because all net working protocols use the same underlying principles and concepts, in the same w ay. So, the use of a general purpose programming language would yield a large nu mber of applications only differing in the details.[29] A suitably defined (dedi cated) protocolling language would therefore have little syntax, perhaps just en ough to specify some parameters or optional modes of operation, because its virt ual machine would have incorporated all possible principles and concepts making the virtual machine itself a universal protocol. The protocolling language would have some syntax and a lot of semantics describing this universal protocol and would therefore in effect be a protocol, hardly differing from this universal ne tworking protocol. In this (networking) context a protocol is a language. The notion of a universal networking protocol provides a rationale for standardi zation of networking protocols; assuming the existence of a universal networking protocol, development of protocol standards using a consensus model (the agreem ent of a group of experts) might be a viable way to coordinate protocol design e fforts. Networking protocols operate in very heterogeneous environments consisting of ve ry different network technologies and a (possibly) very rich set of applications , so a single universal protocol would be very hard to design and implement corr ectly. Instead, the IETF decided to reduce complexity by assuming a relatively s imple network architecture allowing decomposition of the single universal networ king protocol into two generic protocols, TCP and IP, and two classes of specifi c protocols, one dealing with the low-level network details and one dealing with the high-level details of common network applications (remote login, file trans fer, email and web browsing). ISO choose a similar but more general path, allowi ng other network architectures, to standardize protocols. Protocol design[edit]Communicating systems operate in parallel. The programming tools and techniques for dealing with parallel processes are collectively called concurrent programming. Concurrent programming only deals with the synchronizat ion of communication. The syntax and semantics of the communication governed by a low-level protocol usually have modest complexity, so they can be coded with r elative ease. High-level protocols with relatively large complexity could howeve

r merit the implementation of language interpreters. An example of the latter ca se is the HTML language. Concurrent programming has traditionally been a topic in operating systems theor y texts.[30] Formal verification seems indispensable, because concurrent program s are notorious for the hidden and sophisticated bugs they contain.[31] A mathem atical approach to the study of concurrency and communication is referred to as Communicating Sequential Processes (CSP).[32] Concurrency can also be modelled u sing finite state machines like Mealy and Moore machines. Mealy and Moore machin es are in use as design tools in digital electronics systems, which we encounter in the form of hardware used in telecommunications or electronic devices in gen eral.[33] This kind of design tant to keep things rospect, this meant n of protocols into can be a bit of a challenge to say the least, so it is impor simple. For the Internet protocols, in particular and in ret a basis for protocol design was needed to allow decompositio much simpler, cooperating protocols.

Concurrent programming[edit]A concurrent program is an abstraction of cooperatin g processes suitable for formal treatment and study. The goal of the abstraction is to prove correctness of the program assuming the existence of some basic syn chronization or data exchange mechanisms provided by the operating system (or ot her software) or hardware. The mechanisms are complex, so more convenient higher level primitives are implemented with these mechanisms. The primitives are used to construct the concurrent program. The basic primitive for synchronization is the semaphore. All other primitives (locks, reentrant mutexes, monitors, messag e passing, tuple space) can be defined using semaphores. The semaphore is suffic iently elementary to be successfully studied by formal methods.[34] In order to synchronize or exchange data the processes must communicate by means of either a shared memory, used to store data or access-restricted procedures, or the sending/receiving of signals (message passing) using a shared transmissio n medium. Most third generation operating systems implement separate processes t hat use special instructions to ensure only one process can execute the restrict ed procedures. On distributed systems there is no common central memory so the c ommunications are always by means of message passing. In this case the processes simply have to wait for each other (synchronization by rendezvous) before excha nging data.[3] Conceptually, the concurrent program consists of several sequential processes wh ose execution sequences are interleaved. The execution sequences are divided int o sections. A section manipulating shared resources is called a critical section . The interleaving scheme makes no timing assumptions other than that no process halts in its critical section and that ready processes are eventually scheduled for execution. For correct operation of the program, the critical sections of t he processes need to be properly sequenced and synchronized. This is achieved us ing small code fragments (protocols) at the start and the end of the critical se ctions. The code fragments determine whether the critical sections of two commun icating processes should execute in parallel (rendezvous of processes) or should be executed sequentially (mutual exclusion of processes). A concurrent program is correct if it does not violate some safety property such as mutual exclusion or rendezvous of critical sections and does not suffer of l iveness properties such as deadlock or lockout. Correctness of the concurrent pr ogram can only be shown using a mathematical argument. Specifications of concurr ent programs can be formulated using formal logics (like CSP) which make it poss ible to prove properties of the programs. Incorrectness can be shown using execu tion scenarios.[4] Mutual exclusion is extensively studied in the mutual exclusion problem. The ren dezvous is studied in the producer-consumer problem in which a producer process only produces data if and only if the consumer process is ready to consume the d

ata. Although both problems only involve two processes, their solutions require rather complex algorithms (Dekker's algorithm, Lamport's bakery algorithm). The readers-writers problem is a generalization of the mutual exclusion problem. The dining philosophers problem is a classical problem sufficiently difficult to ex pose many of the potential pitfalls of newly proposed primitives.[35] A basis for protocol design[edit]Systems do not use a single protocol to handle a transmission. Instead they use a set of cooperating protocols, sometimes calle d a protocol family or protocol suite.[8] To cooperate the protocols have to com municate with each other, so some kind of conceptual framework is needed to make this communication possible. Also note that software is needed to implement bot h the 'xfer-mechanism' and a protocol (no protocol, no communication). In literature there are numerous references to the analogies between computer co mmunication and programming. By analogy we could say that the aforementioned 'xf er-mechanism' is comparable to a cpu; a 'xfer-mechanism' performs communications and a cpu performs computations and the 'framework' introduces something that a llows the protocols to be designed independent of one and another by providing s eparate execution environments for the protocols. Furthermore, it is repeatedly stated that protocols are to computer communication what programming languages a re to computation.[36][37] Layering[edit] Figure 2. The TCP/IP model or Internet layering scheme and its relation to some common protocols.The communications protocols in use on the Internet are designe d to function in very complex and diverse settings. To ease design, communicatio ns protocols are structured using a layering scheme as a basis. Instead of using a single universal protocol to handle all transmission tasks, a set of cooperat ing protocols fitting the layering scheme is used.[38] The layering scheme in us e on the Internet is called the TCP/IP model. The actual protocols are collectiv ely called the Internet protocol suite. The group responsible for this design is called the Internet Engineering Task Force (IETF). Typically, a hardware delivery mechanism layer is used to build a connectionless packet delivery system on top of which a reliable transport layer is built, on top of which is the application software. Layers below and above these can be de fined, and protocols are very often stacked to give tunnelling, for example the internet protocol can be tunnelled across an ATM network protocol to provide con nectivity by layering the internet protocol on top of the ATM protocol transport layer. The number of layers of a layering scheme and the way the layers are defined can have a drastic impact on the protocols involved. This is where the analogies co me into play for the TCP/IP model, because the designers of TCP/IP employed the same techniques used to conquer the complexity of programming language compilers (design by analogy) in the implementation of its protocols and its layering sch eme.[39] Protocol layering[edit] Figure 3. Message flows using a protocol suite.Protocol layering now forms the b asis of protocol design.[7] It allows the decomposition of single, complex proto cols into simpler, cooperating protocols, but it is also a functional decomposit ion, because each protocol belongs to a functional class, called a protocol laye r.[38] The protocol layers each solve a distinct class of communications problem s. The Internet protocol suite consists of the following layers: application-, t ransport-, internet- and network interface-functions.[9] Together, the layers ma ke up a layering scheme or model. In computations, we have algorithms and data, and in communications, we have pro tocols and messages, so the analog of a data flow diagram would be some kind of

message flow diagram.[24] To visualize protocol layering and protocol suites, a diagram of the message flows in and between two systems, A and B, is shown in fi gure 3. The systems both make use of the same protocol suite. The vertical flows (and pr otocols) are in system and the horizontal message flows (and protocols) are betw een systems. The message flows are governed by rules, and dataformats specified by protocols. The blue lines therefore mark the boundaries of the (horizontal) p rotocol layers. The vertical protocols are not layered because they don't obey the protocol laye ring principle which states that a layered protocol is designed so that layer n at the destination receives exactly the same object sent by layer n at the sourc e. The horizontal protocols are layered protocols and all belong to the protocol suite. Layered protocols allow the protocol designer to concentrate on one laye r at a time, without worrying about how other layers perform.[37] The vertical protocols neednot be the same protocols on both systems, but they h ave to satisfy some minimal assumptions to ensure the protocol layering principl e holds for the layered protocols. This can be achieved using a technique called Encapsulation.[40] Usually, a message or a stream of data is divided into small pieces, called mess ages or streams, packets, IP datagrams or network frames depending on the layer in which the pieces are to be transmitted. The pieces contain a header area and a data area. The data in the header area identifies the source and the destinati on on the network of the packet, the protocol, and other data meaningful to the protocol like CRC's of the data to be sent, data length, and a timestamp.[41][42 ] The rule enforced by the vertical protocols is that the pieces for transmission are to be encapsulated in the data area of all lower protocols on the sending si de and the reverse is to happen on the receiving side. The result is that at the lowest level the piece looks like this: 'Header1,Header2,Header3,data' and in t he layer directly above it: 'Header2,Header3,data' and in the top layer: 'Header 3,data', both on the sending and receiving side. This rule therefore ensures tha t the protocol layering principle holds and effectively virtualizes all but the lowest transmission lines, so for this reason some message flows are coloured re d in figure 3. To ensure both sides use the same protocol, the pieces also carry data identifyi ng the protocol in their header. The design of the protocol layering and the network (or Internet) architecture a re interrelated, so one cannot be designed without the other.[43] Some of the mo re important features in this respect of the Internet architecture and the netwo rk services it provides are described next. The Internet offers universal interconnection, which means that any pair of comp uters connected to the Internet is allowed to communicate. Each computer is iden tified by an address on the Internet. All the interconnected physical networks a ppear to the user as a single large network. This interconnection scheme is call ed an internetwork or internet.[44] Conceptually, an Internet addresses consists of a netid and a hostid. The netid identifies a network and the hostid identifies a host. The term host is misleadi ng in that an individual computer can have multiple network interfaces each havi ng its own Internet address. An Internet Address identifies a connection to the network, not an individual computer.[45] The netid is used by routers to decide where to send a packet.[46] Network technology independence is achieved using the low-level address resoluti

on protocol (ARP) which is used to map Internet addresses to physical addresses. The mapping is called address resolution. This way physical addresses are only used by the protocols of the network interface layer.[47] The TCP/IP protocols c an make use of almost any underlying communication technology.[48] Figure 4. Message flows in the presence of a routerPhysical networks are interco nnected by routers. Routers forward packets between interconnected networks maki ng it possible for hosts to reach hosts on other physical networks. The message flows between two communicating system A and B in the presence of a router R are illustrated in figure 4. Datagrams are passed from router to router until a rou ter is reached that can deliver the datagram on a physically attached network (c alled direct delivery).[49] To decide whether a datagram is to be delivered dire ctly or is to be sent to a router closer to the destination, a table called the IP routing table is consulted. The table consists of pairs of networkids and the paths to be taken to reach known networks. The path can be an indication that t he datagram should be delivered directly or it can be the address of a router kn own to be closer to the destination.[50] A special entry can specify that a defa ult router is chosen when there are no known paths.[51] All networks are treated equal. A LAN, a WAN or a point-to-point link between tw o computers are all considered as one network.[52] A Connectionless packet delivery (or packet-switched) system (or service) is off ered by the Internet, because it adapts well to different hardware, including be st-effort delivery mechanisms like the ethernet. Connectionless delivery means t hat the messages or streams are divided in pieces that are multiplexed separatel y on the high speed intermachine connections allowing the connections to be used concurrently. Each piece carries information identifying the destination. The d elivery of packets is said to be unreliable, because packets may be lost, duplic ated, delayed or delivered out of order without notice to the sender or receiver . Unreliability arises only when resources are exhausted or underlying networks fail.[53] The unreliable connectionless delivery system is defined by the Intern et Protocol (IP). The protocol also specifies the routing function, which choose s a path over which data will be sent.[54] It is also possible to use TCP/IP pro tocols on connection oriented systems. Connection oriented systems build up virt ual circuits (paths for exclusive use) between senders and receivers. Once built up the IP datagrams are sent as if they were data through the virtual circuits and forwarded (as data) to the IP protocol modules. This technique, called tunne ling, can be used on X.25 networks and ATM networks.[55] A reliable stream transport service using the unreliable connectionless packet d elivery service is defined by the transmission control protocol (TCP). The servi ces are layered as well and the application programs residing in the layer above it, called the application services, can make use of TCP.[56] Programs wishing to interact with the packet delivery system itself can do so using the user data gram protocol (UDP).[57] Software layering[edit]Having established the protocol layering and the protocol s, the protocol designer can now resume with the software design. The software h as a layered organization and its relationship with protocol layering is visuali zed in figure 5. Figure 5: Protocol and software layeringThe software modules implementing the pr otocols are represented by cubes. The information flow between the modules is re presented by arrows. The (top two horizontal) red arrows are virtual. The blue l ines mark the layer boundaries. To send a message on system A, the top module interacts with the module directly below it and hands over the message to be encapsulated. This module reacts by e ncapsulating the message in its own data area and filling in its header data in accordance with the protocol it implements and interacts with the module below i t by handing over this newly formed message whenever appropriate. The bottom mod ule directly interacts with the bottom module of system B, so the message is sen

t across. On the receiving system B the reverse happens, so ultimately (and assu ming there were no transmission errors or protocol violations etc.) the message gets delivered in its original form to the topmodule of system B.[58] On protocol errors, a receiving module discards the piece it has received and re ports back the error condition to the original source of the piece on the same l ayer by handing the error message down or in case of the bottom module sending i t across.[59] The division of the message or stream of data into pieces and the subsequent rea ssembly are handled in the layer that introduced the division/reassembly. The re assembly is done at the destination (i.e. not on any intermediate routers).[60] TCP/IP software is organized in four layers.[61] Application layer. At the highest layer, the services available across a TCP/IP internet are accessed by application programs. The application chooses the style of transport to be used which can be a sequence of individual messages or a con tinuous stream of bytes. The application program passes data to the transport la yer for delivery. Transport layer. The transport layer provides communication from one application to another. The transport layer may regulate flow of information and provide re liable transport, ensuring that data arrives without error and in sequence. To d o so, the receiving side sends back acknowledgments and the sending side retrans mits lost pieces called packets. The stream of data is divided into packets by t he module and each packet is passed along with a destination address to the next layer for transmission. The layer must accept data from many applications concu rrently and therefore also includes codes in the packet header to identify the s ending and receiving application program. Internet layer. The Internet layer handles the communication between machines. P ackets to be sent are accepted from the transport layer along with an identifica tion of the receiving machine. The packets are encapsulated in IP datagrams and the datagram headers are filled. A routing algorithm is used to determine if the datagram should be delivered directly or sent to a router. The datagram is pass ed to the appropriate network interface for transmission. Incoming datagrams are checked for validity and the routing algorithm is used to decide whether the da tagram should be processed locally or forwarded. If the datagram is addressed to the local machine, the datagram header is deleted and the appropriate transport protocol for the packet is chosen. ICMP error and control messages are handled as well in this layer. Network interface layer. The network interface layer is responsible for acceptin g IP datagrams and transmitting them over a specific network. A network interfac e may consist of a device driver or a complex subsystem that uses its own data l ink protocol. Program translation has been divided into four subproblems: compiler, assembler, link editor, and loader. As a result, the translation software is layered as we ll, allowing the software layers to be designed independently. Noting that the w ays to conquer the complexity of program translation could readily be applied to protocols because of the analogy between programming languages and protocols, t he designers of the TCP/IP protocol suite were keen on imposing the same layerin g on the software framework. This can be seen in the TCP/IP layering by consider ing the translation of a pascal program (message) that is compiled (function of the application layer) into an assembler program that is assembled (function of the transport layer) to object code (pieces) that is linked (function of the Int ernet layer) together with library object code (routing table) by the link edito r, producing relocatable machine code (datagram) that is passed to the loader wh ich fills in the memory locations (ethernet addresses) to produce executeable co de (network frame) to be loaded (function of the network interface layer) into p hysical memory (transmission medium). To show just how closely the analogy fits, the terms between parentheses in the previous sentence denote the relevant anal ogs and the terms written cursively denote data representations. Program transla tion forms a linear sequence, because each layer's output is passed as input to

the next layer. Furthermore, the translation process involves multiple data repr esentations. We see the same thing happening in protocol software where multiple protocols define the data representations of the data passed between the softwa re modules.[39] The network interface layer uses physical addresses and all the other layers onl y use IP addresses. The boundary between network interface layer and Internet la yer is called the high-level protocol address boundary.[62] The modules below th e application layer are generally considered part of the operating system. Passi ng data between these modules is much less expensive than passing data between a n application program and the transport layer. The boundary between application layer and transport layer is called the operating system boundary.[63] Strict layering[edit]Strictly adhering to a layered model, a practice known as s trict layering, is not always the best approach to networking.[64] Strict layeri ng, can have a serious impact on the performance of the implementation, so there is at least a trade-off between simplicity and performance.[65] Another, perhap s more important point can be shown by considering the fact that some of the pro tocols in the Internet Protocol Suite cannot be expressed using the TCP/IP model , in other words some of the protocols behave in ways not described by the model .[66] To improve on the model, an offending protocol could, perhaps be split up into two protocols, at the cost of one or two extra layers, but there is a hidde n caveat, because the model is also used to provide a conceptual view on the sui te for the intended users. There is a trade-off to be made here between precisen ess for the designer and clarity for the intended user.[67] Protocol development[edit]For communication to take place, protocols have to be agreed upon. Recall that in digital computing systems, the rules can be expresse d by algorithms and datastructures, raising the opportunity of hardware independ ence. Expressing the algorithms in a portable programming language, makes the pr otocolsoftware operating system independent. The sourcecode could be considered a protocol specification. This form of specification, however is not suitable fo r the parties involved. For one thing, this would enforce a source on all parties and for another, propr ietary software producers would not accept this. By describing the software inte rfaces of the modules on paper and agreeing on the interfaces, implementers are free to do it their way. This is referred to as source independence. By specifyi ng the algorithms on paper and detailing hardware dependencies in an unambiguous way, a paper draft is created, that when adhered to and published, ensures inte roperability between software and hardware. Such a paper draft can be developed into a protocol standard by getting the appr oval of a standards organization. To get the approval the paper draft needs to e nter and successfully complete the standardization process. This activity is ref erred to as protocol development. The members of the standards organization agre e to adhere to the standard on a voluntary basis. Often the members are in contr ol of large market-shares relevant to the protocol and in many cases, standards are enforced by law or the government, because they are thought to serve an impo rtant public interest, so getting approval can be very important for the protoco l. It should be noted though that in some cases protocol standards are not sufficie nt to gain widespread acceptance i.e. sometimes the sourcecode needs to be discl osed enforced by law or the government in the interest of the public. The need for protocol standards[edit]The need for protocol standards can be show n by looking at what happened to the bi-sync protocol (BSC) invented by IBM. BSC is an early link-level protocol used to connect two separate nodes. It was orig inally not intended to be used in a multinode network, but doing so revealed sev

eral deficiencies of the protocol. In the absence of standardization, manufactur ers and organizations felt free to 'enhance' the protocol, creating incompatible versions on their networks. In some cases, this was deliberately done to discou rage users from using equipment from other manufacturers. There are more than 50 variants of the original bi-sync protocol. One can assume, that a standard woul d have prevented at least some of this from happening.[5] In some cases, protocols gain market dominance without going through a standardi zation process. Such protocols are referred to as de facto standards. De facto s tandards are common on emerging markets, niche markets, or markets that are mono polized (or oligopolized). They can hold a market in a very negative grip, espec ially when used to scare away competition. From a historical perspective, standa rdization should be seen as a measure to counteract the ill-effects of de facto standards. Positive exceptions exist; a 'de facto standard' operating system lik e GNU/Linux does not have this negative grip on its market, because the sources are published and maintained in an open way, thus inviting competition. Standard ization is therefore not the only solution for open systems interconnection. Standards organizations[edit]Some of the standards organizations of relevance fo r communications protocols are the International Organization for Standardizatio n (ISO), the International Telecommunications Union (ITU), the Institute of Elec trical and Electronics Engineers (IEEE), and the Internet Engineering Task Force (IETF). The IETF maintains the protocols in use on the Internet. The IEEE contr ols many software and hardware protocols in the electronics industry for commerc ial and consumer devices. The ITU is an umbrella organization of telecommunicati ons engineers designing the public switched telephone network (PSTN), as well as many radio communication systems. For marine electronics the NMEA standards are used. The World Wide Web Consortium (W3C) produces protocols and standards for Web technologies. International standards organizations are supposed to be more impartial than loc al organizations with a national or commercial self-interest to consider. Standa rds organizations also do research and development for standards of the future. In practice, the standards organizations mentioned, cooperate closely with each other.[68] The standardization process[edit]The standardization process starts off with ISO commissioning a sub-committee workgroup. The workgroup issues working drafts an d discussion documents to interested parties (including other standards bodies) in order to provoke discussion and comments. This will generate a lot of questio ns, much discussion and usually some disagreement on what the standard should pr ovide and if it can satisfy all needs (usually not). All conflicting views shoul d be taken into account, often by way of compromise, to progress to a draft prop osal of the working group. The draft proposal is discussed by the member countries' standard bodies and oth er organizations within each country. Comments and suggestions are collated and national views will be formulated, before the members of ISO vote on the proposa l. If rejected, the draft proposal has to consider the objections and counter-pr oposals to create a new draft proposal for another vote. After a lot of feedback , modification, and compromise the proposal reaches the status of a draft intern ational standard, and ultimately an international standard. The process normally takes several years to complete. The original paper draft c reated by the designer will differ substantially from the standard, and will con tain some of the following 'features': Various optional modes of operation, for example to allow for setup of different packet sizes at startup time, because the parties could not reach consensus on the optimum packet size.

Parameters that are left undefined or allowed to take on values of a defined set at the discretion of the implementor. This often reflects conflicting views of some of the members. Parameters reserved for future use, reflecting that the members agreed the facil ity should be provided, but could not reach agreement on how this should be done in the available time. Various inconsistencies and ambiguities will inevitably be found when implementi ng the standard. International standards are reissued periodically to handle the deficiencies and reflect changing views on the subject.[69] Future of standardization (OSI)[edit]A lesson learned from ARPANET (the predeces sor of the Internet) is that standardization of protocols is not enough, because protocols also need a framework to operate. It is therefore important to develo p a general-purpose, future-proof framework suitable for structured protocols (s uch as layered protocols) and their standardization. This would prevent protocol standards with overlapping functionality and would allow clear definition of th e responsibilities of a protocol at the different levels (layers).[70] This gave rise to the ISO Open Systems Interconnection reference model (RM/OSI), which is used as a framework for the design of standard protocols and services conformin g to the various layer specifications.[71] In the OSI model, communicating systems are assumed to be connected by an underl ying physical medium providing a basic (and unspecified) transmission mechanism. The layers above it are numbered (from one to seven); the nth layer is referred to as (n)-layer. Each layer provides service to the layer above it (or at the t op to the application process) using the services of the layer immediately below it. The layers communicate with each other by means of an interface, called a s ervice access point. Corresponding layers at each system are called peer entitie s. To communicate, two peer entities at a given layer use a (n)-protocol, which is implemented by using services of the (n-1)-layer. When systems are not direct ly connected, intermediate peer entities (called relays) are used. An address un iquely identifies a service access point. The address naming domains need not be restricted to one layer, so it is possible to use just one naming domain for al l layers.[72] For each layer there are two types of standards: protocol standard s defining how peer entities at a given layer communicate, and service standards defining how a given layer communicates with the layer above it. In the original version of RM/OSI, the layers and their functionality are (from highest to lowest layer): The application layer may provide the following services to the application proc esses: identification of the intended communication partners, establishment of t he necessary authority to communicate, determination of availability and authent ication of the partners, agreement on privacy mechanisms for the communication, agreement on responsibility for error recovery and procedures for ensuring data integrity, synchronization between cooperating application processes, identifica tion of any constraints on syntax (e.g. character sets and data structures), det ermination of cost and acceptable quality of service, selection of the dialogue discipline, including required logon and logoff procedures.[73] The presentation layer may provide the following services to the application lay er: a request for the establishment of a session, data transfer, negotiation of the syntax to be used between the application layers, any necessary syntax trans formations, formatting and special purpose transformations (e.g. data compressio n and data encryption).[74] The session layer may provide the following services to the presentation layer: establishment and release of session connections, normal and expedited data exch ange, a quarantine service which allows the sending presentation entity to instr uct the receiving session entity not to release data to its presentation entity without permission, interaction management so presentation entities can control

whose turn it is to perform certain control functions, resynchronization of a se ssion connection, reporting of unrecoverable exceptions to the presentation enti ty.[75] The transport layer provides reliable and transparent data transfer in a cost ef fective way as required by the selected quality of service. It may support the m ultiplexing of several transport connections on to one network connection or spl it one transport connection into several network connections.[76] The network layer does the setup, maintenance and release of network paths betwe en transport peer entities. When relays are needed, routing and relay functions are provided by this layer. The quality of service is negotiated between network and transport entities at the time the connection is set up. This layer is also responsible for (network) congestion control.[77] The data link layer does the setup, maintenance and release of data link connect ions. Errors occurring in the physical layer are detected and may be corrected. Errors are reported to the network layer. The exchange of data link units (inclu ding flow control) is defined by this layer.[78] The physical layer describes details like the electrical characteristics of the physical connection, the transmission techniques used, and the setup, maintenanc e and clearing of physical connections.[79] In contrast to the TCP/IP layering scheme, which assumes a connectionless networ k, RM/OSI assumed a connection-oriented network. Connection-oriented networks ar e more suitable for wide area networks and connectionless networks are more suit able for local area networks. Using connections to communicate implies some form of session and (virtual) circuits, hence the (in the TCP/IP model lacking) sess ion layer. The constituent members of ISO were mostly concerned with wide area n etworks, so development of RM/OSI concentrated on connection oriented networks a nd connectionless networks were only mentioned in an addendum to RM/OSI.[80] At the time, the IETF had to cope with this and the fact that the Internet needed p rotocols which simply were not there. As a result the IETF developed its own sta ndardization process based on "rough consensus and running code".[81] The standardization process is described by RFC2026. Nowadays, the IETF has become a standards organization for the protocols in use on the Internet. RM/OSI has extended its model to include connectionless service s and because of this, both TCP and IP could be developed into international sta ndards. Taxonomies[edit]Classification schemes for protocols usually focus on domain of use and function. As an example of domain of use, connection-oriented protocols and connectionless protocols are used on connection-oriented networks and connec tionless networks respectively. For an example of function consider a tunneling protocol, which is used to encapsulate packets in a high-level protocol, so the packets can be passed across a transport system using the high-level protocol. A layering scheme combines both function and domain of use. The dominant layerin g schemes are the ones proposed by the IETF and by ISO. Despite the fact that th e underlying assumptions of the layering schemes are different enough to warrant distinguishing the two, it is a common practice to compare the two by relating common protocols to the layers of the two schemes.[82] For an example of this pr actice see: List of network protocols. The layering scheme from the IETF is called Internet layering or TCP/IP layering . The functionality of the layers has been described in the section on software layering and an overview of protocols using this scheme is given in the article on Internet protocols. The layering scheme from ISO is called the OSI model or ISO layering. The functi onality of the layers has been described in the section on the future of standar dization and an overview of protocols using this scheme is given in the article

on OSI protocols. Common types of protocols[edit]Main article: List of network protocols The Internet Protocol is used in concert with other protocols within the Interne t Protocol Suite. Prominent members of which include: Transmission Control Protocol (TCP) User Datagram Protocol (UDP) Internet Control Message Protocol (ICMP) Hypertext Transfer Protocol (HTTP) Post Office Protocol (POP3) File Transfer Protocol (FTP) Internet Message Access Protocol (IMAP) Other instances of high level interaction protocols are: IIOP RMI DCOM DDE SOAP Notes[edit]1.^ Protocol, Encyclopedia Britannica, retrieved 2012-09-24 2.^ a b Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, "They (protocols) are to communication what programming languages are to computation" 3.^ a b Ben-Ari 1982, chapter 2 - The concurrent programming abstraction, p. 1819, states the same. 4.^ a b Ben-Ari 1982, Section 2.7 - Summary, p. 27, summarizes the concurrent pr ogramming abstraction. 5.^ a b Marsden 1986, Section 6.1 - Why are standards necessary?, p. 64-65, uses BSC as an example to show the need for both standard protocols and a standard f ramework. 6.^ Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, explains t his by drawing analogies between computer communication and programming language s. 7.^ a b Sect. 11.10 - The Disadvantage Of Layering, p. 192, states: layering for ms the basis for protocol design. 8.^ a b Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, states the same. 9.^ a b Comer 2000, Sect. 11.3 - The Conceptual Layers Of Protocol Software, p. 178, "Each layer takes responsibility for handling one part of the problem." 10.^ Comer 2000, Sect. 11.11 - The Basic Idea Behind Multiplexing And Demultiple xing, p. 192, states the same. 11.^ Marsden 1986, Chapter 3 - Fundamental protocol concepts and problem areas, p. 26-42, explains much of the following. 12.^ Comer 2000, Sect. 7.7.4 - Datagram Size, Network MTU, and Fragmentation, p. 104, Explains fragmentation and the effect on the header of the fragments. 13.^ Comer 2000, Chapter 4 - Classful Internet Addresses, p. 64-67;71. 14.^ Marsden 1986, Section 14.3 - Layering concepts and general definitions, p. 187, explains address mapping. 15.^ Marsden 1986, Section 3.2 - Detection and transmission errors, p. 27, expla ins the advantages of backward error correction. 16.^ Marsden 1986, Section 3.3 - Acknowledgement, p. 28-33, explains the advanta ges of positive only acknowledgement and mentions datagram protocols as exceptio ns. 17.^ Marsden 1986, Section 3.4 - Loss of information - timeouts and retries, p. 33-34. 18.^ Marsden 1986, Section 3.5 - Direction of information flow, p. 34-35, explai ns master/slave and the negotiations to gain control. 19.^ Marsden 1986, Section 3.6 - Sequence control, p. 35-36, explains how packet s get lost and how sequencing solves this. 20.^ Marsden 1986, Section 3.7 - Flow control, p. 36-38.

21.^ Bochmann, G. (1978). "Finite state description of communication protocols". Computer Networks (1976) 2 (4 5): 361 201. doi:10.1016/0376-5075(78)90015-6. edit 22.^ Comer 2000, Glossary of Internetworking Terms and Abbreviations, p. 704, te rm protocol. 23.^ Brand, D.; Zafiropulo, P. (1983). "On Communicating Finite-State Machines". Journal of the ACM 30 (2): 323. doi:10.1145/322374.322380. edit 24.^ a b Comer 2000, Sect. 1.3 - Internet Services, p. 3, "Protocols are to comm unication what algorithms are to computation" 25.^ Tennent 1981, Section 2.3.1 - Definitions, p.15, defines scope and binding. 26.^ Tennent 1981, Section 2.3.2 Environments and stores, p.16, the semantics of blocks and definitions are described using environments and stores. 27.^ Hoare (1985), Ch. 4 - Communication, p. 133, In the introduction: a communi cation is an event described by a pair c.v where c is the name of the communicat ion channel and v is the value of the message. 28.^ Tanenbaum, Andrew S. (2003). Computer networks. Prentice Hall Professional. p. 235. ISBN 978-0-13-066102-9. Retrieved 22 June 2011. 29.^ Comer 2000,Foreword To The First Edition By The Late Jon Postel, xxv, "The principles of architecture, layering, multiplexing, encapsulation, addressing an d address mapping, routing, and naming are quite similar in any protocol suite, though of course, different in detail.". 30.^ Ben-Ari 1982, in his preface, p. xiii. 31.^ Ben-Ari 1982, in his preface, p. xiv. 32.^ Hoare 1985, Chapter 4 - Communication, p. 133, deals with communication. 33.^ S. Srinivasan, NPTEL courses:::: Electronics & Communication Engineering :: Digital Circuits and Systems, available online: http://nptel.iitm.ac.in/video.p hp?courseId=1005&p=3 34.^ Ben-Ari 1982, Section 1.7 - An overview of the book, p. 12, states the same . 35.^ Ben-Ari 1982, Section 4.3 - The producer-consumer problem, p. 56, explains the rendezvous variant in the absence of common memory. 36.^ Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, states mo re or less the same, using other analogies. 37.^ a b Comer 2000, Sect. 11.7 - The Protocol Layering Principle, p. 187, expla ins layered protocols. 38.^ a b Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, intro duces the decomposition in layers. 39.^ a b Comer 2000, Sect. 11.2 - The need for multiple protocols, p. 178, expla ins similarities protocol software and compiler, assembler, linker, loader. 40.^ Comer 2000, Glossary of Internetworking terms, p.686: term encapsulation. 41.^ Comer 2000, Sect. 11.5.1 - The TCP/IP 5-Layer Reference Model, p. 184, Desc ribes the transformations of messages or streams that can be observed in the pro tocol layers. 42.^ Comer 2000, Sect. 2.4.10 - Ethernet Frame Format, p. 30, Ethernet frames ar e used as an example for administrative data for the protocol itself. 43.^ Comer 2000, Sect. 11.4 - Functionality Of The Layers, p. 181, states the sa me about the software organization. 44.^ Comer 2000, Sect. 3.3 - Network-Level Interconnection, p. 55, explains univ ersal interconnection and internetworking. 45.^ Comer 2000, Sect. 4.4 - Addresses Specify Network Connections, p. 86, expla ins this. 46.^ Comer 2000, Sect. 4.3 - The Original Classful Addressing Scheme, p. 64, exp lains the address scheme, netid and routing. 47.^ Comer 2000, Sect. 5.13 - Summary, p. 86, explains ARP. 48.^ Comer 2000, Sect. 2.11 - Other Technologies Over Which TCP/IP Has Been Used , p. 46, states the same. 49.^ Comer 2000, Sect. 8.3.2 - Indirect Delivery, p. 118, states the same. 50.^ Comer 2000, Sect. 8.5 - Next-Hop Routing, p. 120, gives details on the rout ing table. 51.^ Comer 2000, Sect. 8.6 - Default Routes, p. 121, explains default routing an d its use.

52.^ Comer 2000, Sect. 3.8 - All Networks Are Equal, p. 59, states the same. 53.^ Comer 2000, Sect. 7.5 - Connectionless Delivery System, p. 97, explains the delivery system. 54.^ Comer 2000, Sect. 7.6 - Purposes Of The Internet Protocol, p. 97, states th e same. 55.^ Comer 2000, Sect. 2.11.1 - X25NET And Tunnels, p. 46-47, explains tunneling X.25 and mentions ATM. 56.^ Comer 2000, Sect. 13.1 - Introduction, p. 209, introduces TCP. 57.^ Comer 2000, Sect. 12.10 - Summary, p. 206, explains UDP. 58.^ Comer 2000, Sect. 11.3 - The Conceptual Layers Of Protocol Software, p. 179 , the first two paragraphs describe the sending of a message through successive layers. 59.^ Comer 2000, Sect. 9.3 - Error Reporting vs. Error Correction, p. 131, descr ibes the ICMP protocol that is used to handle datagram errors. 60.^ Comer 2000, Sect. 7.7.5 - Reassembly Of Fragments, p. 104, describes reasse mbly of datagrams. 61.^ Comer 2000, Sect. 11.5.1 - The TCP/IP 5-Layer Reference Model, p. 184, expl ains functionality of the layers. 62.^ Comer 2000, Sect. 11.9.1 - High-Level Protocol Boundary, p. 191, describes the boundary. 63.^ Comer 2000, Sect. 11.9.1 - Operating System Boundary, p. 192, describes the operating system boundary. 64.^ IETF 1989, Sect 1.3.1 - Organization, p. 15, 2nd paragraph: many design cho ices involve creative "breaking" of strict layering. 65.^ Comer 2000, Sect. 11.10 - The Disadvantage Of Layering, p. 192, explains wh y "strict layering can be extremely inefficient" giving examples of optimization s. 66.^ IETF 1989, Sect 1.3.1 - Organization, p. 15, 2nd paragraph, explaining why "strict layering is an imperfect model" 67.^ IETF 1989, Sect 1.3.1 - Organization, p. 15, states: This layerist organiza tion was chosen for simplicity and clarity. 68.^ Marsden 1986, Section 6.3 - Advantages of standardisation, p. 66-67, states the same. 69.^ Marsden 1986, Section 6.4 - Some problems with standardisation, p. 67, foll ows HDLC to illustrate the process. 70.^ Marsden 1986, Section 6.1 - Why are standards necessary?, p. 65, explains l essons learned from ARPANET. 71.^ Marsden 1986, Section 14.1 - Introduction, p. 181, introduces OSI. 72.^ Marsden 1986, Section 14.3 - Layering concepts and general definitions, p. 183-185, explains terminology. 73.^ Marsden 1986, Section 14.4 - The application layer, p. 188, explains this. 74.^ Marsden 1986, Section 14.5 - The presentation layer, p. 189, explains this. 75.^ Marsden 1986, Section 14.6 - The session layer, p. 190, explains this. 76.^ Marsden 1986, Section 14.7 - The transport layer, p. 191, explains this. 77.^ Marsden 1986, Section 14.8 - The network layer, p. 192, explains this. 78.^ Marsden 1986, Section 14.9 - The data link layer, p. 194, explains this. 79.^ Marsden 1986, Section 14.10 - The physical layer, p. 195, explains this. 80.^ Marsden 1986, Section 14.11 - Connectionless mode and RM/OSI, p. 195, menti ons this. 81.^ Comer 2000, Section 1.9 - Internet Protocols And Standardization, p. 12, ex plains why the IETF did not use existing protocols. 82.^ Comer 2000, Sect. 11.5.1 - The TCP/IP 5-Layer Reference Model, p. 183, stat es the same. References[edit]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", which is also available onl ine at http://www.informit.com/articles/article.aspx?p=20482 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

Douglas E. Comer (2000). Internetworking with TCP/IP - Principles, Protocols and Architecture (4th ed.). Prentice Hall. ISBN 0-13-018380-6. In particular Ch.11 Protocol layering. Also has a RFC guide and a Glossary of Internetworking Terms and Abbreviations. Internet Engineering Task Force abbr. IETF (1989): RFC1122, Requirements for Int ernet Hosts -- Communication Layers, R.Braden (ed.), Available online at http:// tools.ietf.org/html/rfc1122. Describes TCP/IP to the implementors of protocolsof tware. In particular the introduction gives an overview of the design goals of t he suite. M. Ben-Ari (1982): Principles of concurrent programming 10th Print. Prentice Hal l International, ISBN 0-13-701078-8. C.A.R. Hoare (1985): Communicating sequential processes 10th Print. Prentice Hal l International, ISBN 0-13-153271-5. Available online via http://www.usingcsp.co m R.D. Tennent (1981): Principles of programming languages 10th Print. Prentice Ha ll International, ISBN 0-13-709873-1. Brian W Marsden (1986): Communication network protocols 2nd Edition. Chartwell B ratt, ISBN 0-86238-106-1. Andrew S. Tanenbaum (1984): Structured computer organization 10th Print. Prentic e Hall International, ISBN 0-13-854605-3. External links[edit]Javvin's Protocol Dictionary Overview of protocols in telecontrol field with OSI Reference Model List of Data Communication Protocols PDF-Chart showing the Protocols and the OSI reference layer [show]v t eTelecommunications

History Beacon Broadcasting Communications satellite Computer network Drums Electrica l telegraph Fax Heliographs Hydraulic telegraph Internet Mass media Mobile phone Optic l telecommunication Optical telegraphy Photophone Prepaid mobile phone Radio Radiotel ephone Satellite communications Smoke signals Telecommunications history Telegraphy T elephone The Telephone Cases Television Timeline of communication technology Underse a telegraph line Videoconferencing Videophone Videotelephony Pioneers Edwin Howard Lee Jagadish Chandra ald Fessenden Elisha pp Reis Nikola Tesla Zworykin Armstrong John Logie Baird Alexander Graham Bell Tim BernersBose Vint Cerf Claude Chappe Lee De Forest Philo Farnsworth Regin Gray Guglielmo Marconi Alexander Stepanovich Popov Johann Phili Camille Papin Tissot Alfred Vail Charles Wheatstone Vladimir K.

Network topology links nodes terminal node Transmission media Coaxial cable Free-space optical Optical fiber Radio waves Telephone lines Terr estrial microwave Switching Circuit switching Packet switching Telephone exchange Network switch Multiplexing space-division multiplexing Frequency-division multiplexing Time-divi sion multiplexing Polarization-division multiplexing Orbital angular momentum mult iplexing Code division multiplexing

Networks ARPANET BITNET Ethernet FidoNet Internet ISDN LAN Mobile NGN Public Switche ephone Radio Telecommunications equipment Television Telex WAN Wireless World Wide Web Geographic [show]v t eTelecommunications in Africa

Sovereign states Algeria Angola Benin Botswana Burkina Faso Burundi Cameroon Cape Verd Central African Republic Chad Comoros Democratic Republic of the Congo Republic of t he Congo Djibouti Egypt Equatorial Guinea Eritrea Ethiopia Gabon The Gambia Ghana Gu

uinea-Bissau Ivory Coast (Cte d'Ivoire) Kenya Lesotho Liberia Libya Madagascar Malawi i Mauritania Mauritius Morocco Mozambique Namibia Niger Nigeria Rwanda So Tom and egal Seychelles Sierra Leone Somalia South Africa South Sudan Sudan Swaziland Tanzani go Tunisia Uganda Zambia Zimbabwe States with limited recognition Sahrawi Arab Democratic Republic Somaliland Dependencies and other territories Canary Islands / Ceuta / Melilla / Plazas de soberana (Spain) Ma deira (Portugal) Mayotte / Runion (France) Saint Helena / Ascension Island / Trista n da Cunha (United Kingdom) Western Sahara [show]v t eTelecommunications in Asia

Sovereign states Afghanistan Armenia Azerbaijan Bahrain Bangladesh Bhutan Brunei Burma (Myanmar) ambodia People's Republic of China Cyprus East Timor (Timor-Leste) Egypt Georgia India Indonesia Iran Iraq Israel Japan Jordan Kazakhstan North Korea South Korea Kuwait an Laos Lebanon Malaysia Maldives Mongolia Nepal Oman Pakistan Philippines Qatar R i Arabia Singapore Sri Lanka Syria Tajikistan Thailand Turkey Turkmenistan United Ara mirates Uzbekistan Vietnam Yemen States with limited recognition Abkhazia Nagorno-Karabakh Northern Cyprus Palestine South Ossetia Taiwan Dependencies and other territories British Indian Ocean Territory Christmas Island Cocos (Keeling) Islands Hong Kong Macau [show]v t eTelecommunications in Europe

Sovereign states Albania Andorra Armenia Austria Azerbaijan Belarus Belgium Bosnia and Herzegovina Bulgaria Croatia Cyprus Czech Republic Denmark Estonia Finland France Ge Germany Greece Hungary Iceland Ireland Italy Kazakhstan Latvia Liechtenstein Lithu embourg Macedonia Malta Moldova Monaco Montenegro Netherlands Norway Poland Portugal ia Russia San Marino Serbia Slovakia Slovenia Spain Sweden Switzerland Turkey Ukrai d Kingdom States with limited recognition Abkhazia Kosovo Nagorno-Karabakh Northern Cyprus South Ossetia Transnistr ia Dependencies and other territories land Faroe Islands Gibraltar Guernsey Jersey Isle of Man Svalbard Other entities European Union [show]v t eTelecommunications in North America

Sovereign states Antigua and Barbuda Bahamas Barbados Belize Canada Costa Rica Cuba Do inica Dominican Republic El Salvador Grenada Guatemala Haiti Honduras Jamaica Mexico ragua Panama Saint Kitts and Nevis Saint Lucia Saint Vincent and the Grenadines Trini dad and Tobago United States

Dependencies and other territories Anguilla Aruba Bermuda Bonaire British Virgin Islands Cayman Island s Curaao Greenland Guadeloupe Martinique Montserrat Navassa Island Puerto Rico Saint hlemy Saint Martin Saint Pierre and Miquelon Saba Sint Eustatius Sint Maarten Turks an Caicos Islands United States Virgin Islands [show]v t eTelecommunications in Oceania Sovereign states Australia East Timor (Timor-Leste) Fiji Indonesia Kiribati Marshall

Islands Federated States of Micronesia Nauru New Zealand Palau Papua New Guinea Samoa olomon Islands Tonga Tuvalu Vanuatu

Dependencies and other territories American Samoa Christmas Island Cocos (Keeling) Islands Cook Isla nds Easter Island French Polynesia Guam Hawaii New Caledonia Niue Norfolk Island Nort n Mariana Islands Pitcairn Islands Tokelau Wallis and Futuna [show]v t eTelecommunications in South America

Sovereign states Argentina Bolivia Brazil Chile Colombia Ecuador Guyana Paraguay Peru iname Trinidad and Tobago Uruguay Venezuela Dependencies and other territories Aruba Bonaire Curaao Falkland Islands French Guiana South Georgia an d the South Sandwich Islands Retrieved from "http://en.wikipedia.org/w/index.php?title=Communications_protoco l&oldid=558045538" Categories: Network protocolsData transmissionProtocolsHidden categories: Articl es that may be too long from April 2011Navigation menuPersonal tools Create accountLog inNamespaces ArticleTalkVariantsViews ReadEditView historyActions Search Navigation Main page Contents Featured content Current events Random article Donate to Wikipedia InteractionHelp About Wikipedia Community portal Recent changes Contact Wikipedia ToolboxWhat links hereRelated changesUpload fileSpecial pagesPermanent linkPage informationCite this page Print/exportCreate a bookDownload as PDFPrintable version Languages??????? Az?rbaycanca ?????????? ?????????? (???????????)? ????????? Bosanski Brezhoneg Catal Cesky Dansk Deutsch ???????? Espaol Esperanto Euskara ????? Franais ??? ?????? Hrvatski

Bahasa Indonesia Italiano ????? ??????? ??????? Latgalu Ltzebuergesch Magyar ?????????? ?????? Bahasa Melayu Nederlands ??? Norsk bokml Norsk nynorsk ???? ????? ???? Polski Portugus Romna ??????? Simple English Slovencina Sloven cina ????? ?????? / srpski Suomi Svenska ????? ??? Trke ?????????? ???? Ti?ng Vi?t ?? Edit links This page was last modified on 2 June 2013 at 23:14. Text is available under the Creative Commons Attribution-ShareAlike License; add itional terms may apply. By using this site, you agree to the Terms of Use and P rivacy Policy. Wikipedia is a registered trademark of the Wikimedia Foundation, Inc., a non-prof it organization. Privacy policyAbout WikipediaDisclaimersContact WikipediaMobile view