Download
1 / 25
260 likes | 445 Views
Network Software. Overview. Protocol Hierarchies Design Issues for the Layers Connection-Oriented and Connectionless Services. Protocol Hierarchies - layer.
E N D
Overview • Protocol Hierarchies • Design Issues for the Layers • Connection-Oriented and Connectionless Services
Protocol Hierarchies - layer • To reduce their design complexity, most networks are organized as series of layers or levels, each one built upon the one below it. • The number of layers, the name of each layer, the contents of each layer, and the function of each layer differ from network to network. • However, in all networks, the purpose of each layer is to offer certain services to the higher layers, shielding those layers from the details of how the offered services are actually implemented.
Protocol Hierarchies - protocol • Layer n on one machine carries on a conversation with layer n on another machine. • The rules and conventions used in this conversation are collectively known as the layer nprotocol. • Basically, a protocol is an agreement between the communicating parties on how communication is to proceed. • As an analogy, when a woman is introduced to a man, she may choose to stick out her hand. He, in turn, may decide to either shake it or kiss it, depending, for example, on whether she is an American lawyer at a business meeting or a European princess at a formal ball. Violating the protocol will make communication more difficult, if not impossible.
Protocol Hierarchies - peers • A five-layer network is illustrated in Fig. 1. The entities comprising the corresponding layers on different machines are called peers. In other words, it is the peers that communicate using the protocol. Fig. 1. Layers, protocols, and interfaces
Protocol Hierarchies • In reality, no data are actually transferred from layer n on one machine to layer n on another machine. Instead, each layer passes data and control information to the layer immediately below it, until the lowest layer is reached. • Below layer 1 is the physical medium through which actual communication occurs. In Fig. 1. virtual communication is shown by dotted lines and physical communication by solid lines.
Protocol Hierarchies - interface • Between each pair of adjacent layers there is an interface. • The interface defines which primitive operations and services the lower layer offers to the upper one. • When network designers decide how many layers to include in a network and what each one should do, one of the most important considerations is defining clean interfaces between the layers. (each layer performs a specific collection of well-understood functions) • In addition, clean-cut interfaces also make it simpler to replace the implementation of one layer with a completely different implementation without disrupting the rest of the layers. (ex. all the telephone lines are replaced by satellite channels) as all that is required of the implementation is that it offers the exact same set of services to its upstairs neighbor layer as the old implementation did.
Protocol Hierarchies • A set of layers and protocols is called a network architecture. • The specification of an architecture must contain enough information to allow an implementer to write the program (or build the hardware) for each layer so that it will correctly obey the appropriate protocol. • Neither the details of the implementation nor the specification for the interfaces are part of the architecture because these are hidden away inside the machines and not visible from outside. • It is not even necessary that the interfaces on all machines in a network be the same, provided that each machine can correctly used the protocols. • A list of protocols used by a certain system, one protocol per layer, is called a protocol stack.
Protocol Hierarchies - analogy • An analogy may help explain the idea of multilayer communication. • Imagine … two philosophers (peer processes in layer 3), one of whom speaks Urdu and English and one of whom speaks Chinese and French. • Since they have no common language, they each engage a translator (peer processes in layer 2), each of whom in turn contacts a secretary (peer processes in layer 1). • Philosopher 1 wishes to convey his affection to oryctolagus cuniculus to his peer. To do so, he passes a message (in English) across the 2/3 interface, to his translator, saying “I like rabbits.” as illustrated on Fig. 2.
Protocol Hierarchies - analogy • The translators have agreed on a neutral language, Dutch, so the message is converted to “Ik hou van konijenen.” The choice of language (the layer 2 protocol) is up to the layer 2 peer processes. • The translator then gives the message to a secretary for transmission, by for example, fax (the layer 1 protocol). When the message arrives, it is translated to French and passed across the 2/3 interface to philosopher 2. • * Note, that each protocol is completely independent of the other ones as long as the interfaces are not changed. So, the translators can switch from Dutch to say, Finnish, at will, provided that they both agree, and neither changes his interface with layer 1 or layer 3. Similarly, the secretaries can switch from fax to email, or telephone without disturbing (or even informing) the other layers. • Each process may add some information intended for only its peer. This information is not passed upward to the layer above.
Protocol Hierarchies - Example • Now, consider a more technical example: how to provide communication to the top layer of the five-layer network in Fig. 3. • A message, M, is produced by an application process running in layer 5 and given to layer 4 for transmission. • Layer 4 puts a header in front of the message to identify the message and passes the result to layer 3. The header includes control information, such as sequence numbers, to allow layer 4 on the destination machine to deliver messages in the right order if the lower layers do not maintain sequence. In some layers, headers also contain sizes, times, and other control fields.
Protocol Hierarchies - Example Fig. 3. Example information flow supporting virtual communication in layer 5
Protocol Hierarchies - Example • In many networks, there is no limit to the size of messages transmitted in the layer 4 protocol, but there is nearly always a limit imposed by the layer 3 protocol. • Consequently, layer 3 must break up the incoming messages into smaller units, packets, prepending a layer 3 header to each packet. In this example, M is split into two parts M1 and M2. • Layer 3 decides which of the outgoing lines to use and passes the packets to layer 2. Layer 2 adds not only a header to each piece, but also a trailer, and gives the resulting unit to layer 1 for physical transmission. • At the receiving machine, the message moves upward, from layer to layer, with headers being stripped off as it progresses. (i.e. none of the headers for layers below n are passed up to layer n.)
Protocol Hierarchies - Example • The important thing to understand about Fig. 3. Is the relation between the virtual and actual communication and the difference between protocols and interfaces. • The peer processes in layer 4, for example, conceptually think of their communication as being “horizontal”, using the layer 4 protocol. Each one is likely to have a procedure called something like SendToOtherSide and GetFromOtherSide , even though these procedures actually communicate with lower layers across the 3/4 interface, not with the other side. • The peer process abstraction is crucial to all network design. Using it, the unmanageable task of designing the complete network can be broken into several smaller, manageable, design problems, namely the design of the individual levels. • Lower layers of a protocol hierarchy are frequently implemented in hardware (completely or partially). The rest is software.
Design Issues for the Layers • Some of the key design issues that occur in computer networking are present in several layers. Next, we will briefly mention some of the important ones. • Every layer, needs a mechanism for identifying senders and receivers. Since a network normally has many computers, some of which have multiple processes, a means is needed for a process on one machine to specify with whom it wants to talk. As a consequence of having multiple destinations, some form of addressing is needed in order to specify a particular destination.
Design Issues for the Layers • Another set of design decisions concerns the rules for data transfer. In some systems, data only travel in one direction (simplex communication). In others they can travel in either direction, but not simultaneously (half-duplex communication). In still others they travel in both directions at once (full-duplex communication). The protocol must also determine how many logical channels the connection corresponds to, and what their priorities are. Many networks provide at least two logical channels per connection, one for normal data and one for urgent data. • Error control is an important issue because physical communication circuits are not perfect. Many error-detecting and error-correcting codes are known, but both ends of the connection must agree on which one is being used. In addition, the receiver must have some way of telling the sender which messages have been correctly received and which have not.
Design Issues for the Layers • Not all communication channels preserve the order of messages sent on them. To deal with a possible loss of sequencing, the protocol must make explicit provision for the receiver to allow the pieces to be put back together properly. An obvious solution is to number the pieces, but this solution still leaves open the question of what should be done with pieces that arrive out of order. • Congestion control - an issue that occurs at every level is how to keep a fast sender from swamping a slow receiver with data. Various solutions have been proposed. Some of them involve some kind of feedback from the receiver to the sender, either directly or indirectly, about the receiver’s current situation. Others limit the sender to an agreed upon transmission rate.
Design Issues for the Layers • Another problem that must be solved at several levels is the inability of all processes to accept arbitrary long messages. This property leads to mechanisms for disassembling, transmitting, and then reassembling messages. A related issue is what to do when processes insist upon transmitting data in units that are so small that sending each one separately is inefficient. Here the solution is to gather together several small messages heading toward a common destination into a single large message and dismember the large message at the other side. • When it is inconvenient or expensive to set up a separate connection for each pair of communicating processes, the underlying layer may decide to use the same connection for multiple, unrelated conversations. As long as this multiplexing and demultiplexing is done transparently, it can be used by any layer. Multiplexing is needed in the physical layer, for example, where all the traffic for all connections has to be sent over at most a few physical circuits.
Design Issues for the Layers • Finally, when there are multiple paths between source and destination, a route must be chosen. Sometimes this decision must be split over two or more layers. For example, to send data from London to Rome, a high-level decision might have to made to go via France or Germany based on their respective privacy laws, and a low-level decision might have to be made to choose one of the many available circuits based on the current traffic load.
Connection-Oriented and Connectionless Services • Layers can offer two different types of service to the layers above them: connection-oriented and connectionless. • Connection-oriented service is modeled after the telephone system. To talk to someone, you pick up the phone, dial the number, talk and then hang up. Similarly, to use a connection-oriented network service, the service user first establishes a connection, uses the connection, and then releases the connection. The essential aspect of a connection is that it acts like a tube: the sender pushes objects (bits) in at one end, and the receiver takes them out in the same order at the other end. • In contrast, connectionless service is modeled after the postal system. Each message (letter) carries the full destination address, and each one is routed through the system independently of all the others. Normally, when two messages are sent to the same destination, the first one sent will be the first one to arrive. However, it is possible that the first one sent can be delayed so that the second one arrives first. With a connection-oriented service this is impossible.
Connection-Oriented and Connectionless Services • Each service can be characterized by a quality of service. Some services are reliable in a sense that they never lose data. Usually, a reliable service is implemented by having the receiver acknowledge the receipt of each message, so the sender is sure it arrived. The acknowledgement process introduces overhead and delays, which are often worth it but sometimes are undesirable. • A typical situation in which reliable connection-oriented service is appropriate is file transfer. (the owner of the file wants to be sure that all the bits arrive correctly and in the same order they were sent). Few users would prefer a service that occasionally scrambles of loses a few bits, even if it much faster.
Connection-Oriented and Connectionless Services • As mentioned above, for some applications the delays introduced by acknowledgments are unacceptable. One such application is digitized voice traffic. In it preferable for telephone users to hear a bit of noise on the line or a garbled word from time to time than to introduce a delay to wait for acknowledgment. Similarly, when transmitting a video film, having a few pixels wrong is no problem, but having the film jerk along as the flow stops to correct errors is very irritating. • Not all applications require connections. For example, the junk email sender probably does not want to go to the trouble of setting up a connection and later tearing it down just to send one item. Nor is 100% reliable delivery essential, especially if it costs more. All that is needed is a way to send a single message that has a high probability of arrival, but not guarantee. • Unreliable (meaning not acknowledged) connectionless service is often called datagram service, in analogy to telegram service, which also does not provide an acknowledgement back to the sender.
Connection-Oriented and Connectionless Services • In other situations, the convenience of not having to establish a connection to send one short message is desired, but reliability is essential. The acknowledged datagram service can be provided for these applications. It is like sending a registered letter a requesting a return receipt. • Another service is the request-reply service. In this service, the sender transmits a single datagram containing a request; the reply contains the answer. Used in client-server applications with 1 request and 1 response. (no connection needed)
