Introductory Comments

Whereas the conventional LAN discussed in Chapter 11 provides data communication capabilities among a comparatively small and closed user group covering a very limited geographical area, a WAN not only has the potential of covering the entire world and outer space, but also has the capability of reaching an extremely large and diverse user group (e.g., the INTERNET). With these facts in mind, what are the really key essentials that we must understand that will make such a system provide us the capabilities we would expect? Let's brainstorm and prepare a short list of requirements for a data network to communicate data messages: We must first assume that a data message is made up of one or more data frames or packets. See Section 10.10.1 and Figure 10.25.

Fundamentals of Telecommunications, Second Edition, by Roger L. Freeman ISBN 0-471-71045-8 Copyright © 2005 by Roger L. Freeman

1. Data messages should have a high probability of reaching (a) recipient(s) intact and comparatively error-free.

2. There may be an issue of urgency. Here we mean how soon after transmission will a data message reach its recipient.

3. The recipient(s) must be prepared to receive the message and "understand" its contents.

12.1.1.1 A Data Message Must Reach the Recipient(s). How is a data message routed such that the indicated recipient(s) receive the message? With conventional telephony, signaling carries out this function. It sets up a circuit (Chapter 7), maintains the connectivity throughout the call, and then takes the circuit down when one or both subscribers go on-hook. With data communications these same functions must be carried out. One form of data connectivity is called connection-oriented, where indeed a circuit is set up, traffic is passed, and then the circuit is taken down. There is another form of data communications where a frame is launched by the originator, and that frame must find its own way to the destination. Isn't this what happens using the postal service? A letter is dropped in an outgoing box, and it finds its way (with the help of the postal service) to the destination. We, the originator, are completely unaware of the letter's routing; we don't really care. In the data world, this is called connectionless service. In the case of the postal service, the address on the envelope routed the letter.

For the data message case, it is the header that carries the routing information. In many situations, a data message may be made up of a number of frames. Each frame carries a field set aside for the recipient address. More often than not it is called the destination address. In many cases, a frame also carries the originator's address. In either case, these are 8-bit fields, often extendable in increments of 8 bits.

Three key questions come to mind. (1) What part of a frame's header can be easily identified as the originator and destination address fields? (2) What is the addressing capacity of an address field? Rephrased: How many distinct addresses can be accommodated in an 8-bit field? (3) Once a router, smart bridge, or data switch recognizes the boundaries of (a) destination address(es), how does it know how to route the frame?

1. A family of protocols governs the operation of a particular data network. Our interest here is in the network layer and data-link layer protocols. These protocols carefully lay out the data-link frame and the network layer frame (see Section 10.10). For example, in Section 10.7.2 we introduced synchronous transmission and the generic data-link layer frame (Figure 10.7). One thing a digital processor can do and do very well is count bits, and groups of 8 bits, which we call an octet (others call it a byte). A specific network utilizes a particular data-link layer protocol. Thus a processor knows a priori where field boundaries are, because it is designed to meet the requirements of a particular protocol. With some data-link protocols, however, there may be a variable length info field. It is obvious that if this is the case, that the processor must be informed of the length of a particular info field. When this is so, info field length information is often found in a subfield inside the control field (see Figures 10.7 and 10.25). So to answer question 1, the digital processor knows a priori exactly which 8 (or 16) bits consist the destination address field by simply counting down from the unique start-of-frame octet. It knows a priori because the router processor conforms to a particular protocol.

2. What is the addressing capacity of an address field? We will let each address consists of a distinct 8- or 16-bit binary sequence. For an 8-bit binary group, how many distinct

8-bit sequences are there? Remember, on developing code capacity (Section 10.4), that we can have 2" sequences where n is the number of bits in a particular sequence. In our sample case it is 8 bits. Thus, its addressing capacity is 28 or 256 distinct addresses. The addressing capacity can be increased by using extended addressing, namely where we use two octets for a destination address. Often the least significant bit of the first octet is reserved to tell the receiver processor to expect the next octet also to be dedicated to destination address. Now we have only 7 bits in the first octet left for addressing and all 8 bits in the second octet. Adding these two together, we get 15 bits for addressing. Thus, there is 215 or 32,768 distinct addresses, quite a respectable number.

3. How does a router or data switch know how to route to a particular address? Simply by consulting a look-up table. Now this look-up table may have fixed routing entries, or entries that can be updated manually or routing entries that are updated dynamically. Here we must recognize three possible conditions:

1. A node/router is added or dropped from the network.

2. New routing patterns may be established; other routing patterns may be discontinued.

3. There may be congestion, route/node degradation, and/or failure.

Read subsection 12.3 which describes the TCP/IP protocol family because IP has some very interesting means and methods to update routing/look-up tables as well as finding routes to "unknown" destination addresses.

Error detection and correction were discussed in Section 10.5.

12.1.1.2 There May Be an Issue of Urgency. There are several "families" of data messages that have limited or no real issue regarding urgency. For example, long accounting files, including payroll, may only require 24- or 48-hour delivery times. In this case why not use the postal service, Federal Express, or UPS? On the other hand, credit card verification has high urgency requirements. A customer is waiting (probably impatiently) to have her/his credit verified during the process of buying some item. Most transaction data messages are highly urgent.

Certain data protocols involve more latency than others. One reason for implementing frame relay is its low latency. Let's call latency the time it takes to complete a data message transaction. There are four causes for an increase in transaction time:

1. Propagation delay.

2. The number of message exchanges required to complete a transaction (e.g., handshakes, circuit setup, ARQ exchanges, and so on).

3. Processing time and processing requirements. For example, every effort has been made to reduce processing requirements in frame relay. There are virtually no message exchanges, such as ACK and NACK, with frame relay.

4. Secondarily, we must consider the quality of a circuit. If the circuit is noisy, many ARQ exchanges will occur increasing latency dramatically.

12.1.1.3 The Recipient Must Be Prepared to Receive and "Understand" a Data Message. This is simply a question of compatibility. The data message receiver must be compatible with the far-end transmitter and intermediate nodes. We cannot have one transmitting the ASCII code and the companion receiver only able to receive EBCDIC. Such compatibility MAY extend through all seven OSI layers. For example, frame relay is based ONLY on OSI layers 1 and 2. It is the responsibility of the frame relay user to provide the necessary compatibility of the upper OSI layers.

Was this article helpful?

0 0

Post a comment