Looking at Broadcast Protocols

Select Certification Bootcamp :
MCSE MCSE+Security CCNA CCNP RHCE Register Course Fees Home

Leading MCSE, CCNA, CCNP Certification boot camp training provider in India, USA, UK.

Looking at Broadcast Protocols

Before you can fully appreciate TCP/IP, you need to understand how each protocol in the suite works together. To gain this understanding, you need to spend some time looking at how broadcast protocols work. This section uses NetBEUI as an example protocol on a standard ethernet network. From this review of broadcast protocols, or non-routeable protocols, the discussion extends to the function of protocols that are point-to-point, or routeable protocols. You may be surprised to discover that although there are some significant differences between broadcast and point-to-point protocols, there are probably more similarities than differences.

A great deal of discussion on the networking model has focused up to this point on how each layer of the networking model on a sending machine needs to be able to communicate with its corresponding layer on the receiving machine. For instance, the Application layer knows how to communicate with the Application layer of another machine and the Session layer knows how to communicate with the Session layer of another machine.

This function is fundamental to network architecture. At the bottom of the networking model is the Network Interface layer, and it necessarily follows that the Network Interface layer needs to communicate with the Network Interface layer, just as with each of the other layers. Part of the Network Interface layer includes the physical address of a machine, the 6-byte (48-bit) unique hexadecimal address assigned to a network card by the manufacturer.

NetBEUI is a broadcast protocol, but complies with the standard rules for networking in that NetBEUI’s first task when trying to establish communication with another machine is to discover the physical address of the destination machine. With NetBEUI, each machine is uniquely identified by a name, called the NetBIOS name. This is the name of the machine given to it during installation of any Windows operating system using the NetBIOS interface. Even if the NetBEUI protocol is not loaded, the name is still a NetBIOS name and any protocol installed will have to support the NetBIOS interface. This is why Microsoft includes the NetBT (NetBIOS over TCP/IP) API in the protocol suite.

But back to NetBEUI; observe Figure 5.7. This figure shows two machines in the state in which they would exist if they had never communicated with each other and the application on machine B wanted to communicate with machine A. The real conceptual bridge to cross here is that even though these machines may be sitting next to each other on the same piece of wire, they may not have a clue about how to communicate with each other. Remember that each layer of the networking model must be able to communicate or the whole process breaks down. So, even if the application layer of machine B knows it wants to speak to machine A, the lower layers may have no idea what the application layer is talking about.

At this point, the lower layers have a choice. They can either report that they don’t have a clue, or they can go out on the network and try find a machine with the appropriate name. In this case, machine B initiates a broadcast on the network using an ethernet frame in which the destination address is represented by 6 bytes of all FFs, as in Figure 5.1. Recall that a broadcast utilizing all FFs indicates to every network interface card that it must pass this data up to the higher layers of the networking model. But, just as someone screaming incoherently does not tend to facilitate communication, it would behoove machine B to broadcast a mean-ingful question to those higher layers. In this case, the question is put very simply: “If you are machine A, what is your physical address?” This question also contains information about the sending machine, including the NetBIOS name and physical address. With NetBEUI, this question is sent all the way up to the Session layer of every machine on this network before the question is understood and possibly responded to. After a machine interprets the question and decides the message was intended for it, it sends back a directed message indicating its physical address.

After these two machines have figured out each other’s physical addresses, they can communicate with directed packets, meaning that they no longer need to use broadcasts that every machine listens to; they can place the physical addresses in the frames just as with a point-to-point protocol. Figure 5.8 illustrates the communication process between two machines using a broadcast protocol.

This is true any time a machine using a broadcast protocol attempts to communicate with another machine on the network. Part of the response given to any broadcast message is the destination machine’s physical address. After a reply is sent, including the destination machine’s physical address, broadcasts between the two machines are no longer necessary, and the actual physical address is placed in its appropriate location during data transfer.

So, if this is the case, what’s the problem with NetBEUI? Why can’t you use it on the Internet, too? In order to answer this question you need to look much further into the conceptual barriers imposed by this protocol. After you have uncovered and dissected the barriers, it should be fairly clear when NetBEUI is, and is not, useful as a protocol in the networking world.

First, NetBEUI was originally designed to be used on local area networks. This means that NetBEUI doesn’t use an individual addressing scheme based on the important assumption that there is more than one network to worry about. This basic and fundamental design assumption lead to simple choices.

For instance, as Chapter 2 discussed, it’s important to be able to uniquely identify machines on a network. When using NetBEUI, a machine’s uniqueness is defined by its physical address and its unique NetBIOS name, the name it received during installation of the operating system. Since its inception as a protocol, NetBEUI never had to worry about whether there was more than one network; it was not designed to worry about how to uniquely identify one network over another or how to move packets from one network to another, because it assumes there is only one network. That is why the question it asks during the broadcast for a physical address is somewhat simple: “If you’re machine X, what is your physical address?”

Notice the hidden assumption. Nowhere in the question does it ask what network the machine is on, because to NetBEUI, that is a meaningless question; of course we’re all on the same network. Without the additional overhead of worrying about having to route packets, it has the advantage of being quick and efficient. It is not, however, routeable because it has no way to identify different networks, and requires each machine on the network segment to dedicate more resources due to its broadcast nature. Consider how far up the networking model a machine has to pass a random frame on the network before determining whether the frame was destined for it, during a broadcast. Figure 5.9 illustrates that process.

Using a broadcast protocol such as NetBEUI, the only fundamental restrictions in terms of networking are that multiple networks don’t exist (remember, to a protocol such as NetBEUI, there’s only one network, or LAN), and the functional number of computers you can put on that network is limited.

If you use the TCP/IP protocol, however, the destination for this data could be identified by the physical address assigned to the network card of that machine or the IP address given to that machine. As Chapter 3 indicated, the IP address has a lot of information. Not only does it contain the unique network identifier for that machine on a network, but it also has the unique host identifier as well.

The capability to uniquely identify different network IDs is what makes TCP/IP a wide area network protocol, and is what separates it from broadcast protocols. Because IP recognizes the difference between unique machines and unique networks, the protocol had to be written with the capability to move data from one network to another by “routing” them from one network to another. This function is built into the IP protocol. In the case of a routed protocol, machines do not have to pass frames as high up in the networking model to determine if the packet is directed at them. Figure 5.10 illustrates the difference between a broadcast protocol and a directed, or routed, protocol.

Because the network interface layer is responsible for checking the destination of frames, the determination of whether the data is for that machine occurs at a much lower layer on the networking model. TCP/IP was designed for use on a WAN in which multiple network segments are connected through devices called routers. Because TCP/IP uses several addressing schemes—IP addresses and physical addresses—it has the additional overhead of sorting through these and requires the administrator to have more knowledge of the protocol to implement it. However, this added overhead allows TCP/IP to be extraordinarily robust, routeable, and flexible. Figure 5.11 illustrates the addressing levels that TCP/IP uses, including physical address, IP address, and host naming conventions.

How did the source machine get the destination IP address in the first place? Recall from Chapter 2, that ARP (the detective) is the protocol responsible for going out and finding physical addresses of machines based on the IP address. ARP uses a small broadcast of its own on the network, somewhat similar to what NetBEUI does, except the packet is smaller. The ARP request frame is shown in Figure 5.12.

So you can see that even TCP/IP must use some sort of a broadcast to gain physical addresses, much like NetBEUI. These broadcasts just occur in a separate stage of communication. After ARP has negotiated the physical address between the two machines, it passes the physical address to IP so that it can create the directed frame necessary for communication. You can configure the TCP/IP suite with manual entries in the ARP cache so that ARP does not use broadcasts, but this adds a substantial amount of maintenance overhead on the administrator’s part.

Refer to Figure 5.10. Notice that each machine on the network in these examples still receives the initial frame and has to check it. Both examples in figures 5.9 and 5.10 use a standard ethernet network design using CSMA/CA, but they use a different protocol. Does this mean that a network has to be concerned with bandwidth issues regardless of which protocol is being used? Unfortunately, the answer is yes. Both examples indicate that on an ethernet network, frames (voltage) are applied to the wire segment that these machines are on, regardless of which protocol is being used. In fact, at this layer, the network cards have no idea which protocol is being used. All the network cards know at this level is that they listen and pass broadcasts up to the next layer and drop any packets that aren’t broadcasts or aren’t specifically addressed to them.

Now that the essential differences between broadcast and directed protocols has been covered, a more formal discussion of TCP/IP routing can be undertaken. The next section discusses what routing is, what a router is, and the routing process as a whole.

Vibrant Advantage :

No Prestudy
Longest Duration Camp
Chalk Talk Training
Highest Passing Rate
Bootcamp since 1999
Guaranteed Certification ...

Testimonials :

MCSE Certification boot camp

The instructor taught real world experience and did not just teach us to pass the test. He knew the subject well and was encouraging. His lectures were very well delivered....

Colver Dennis, USA