Well the first thing we need to note is that white papers have been with us for quite some time now. Some things about them have changed while others have not. Let us look at the major factor that they all have in common.

Reports

White papers have tended to be of the report format. The reason for this was that the report format served those white papers created specifically to provide information or advice to the reader. The type of information or advice served up in this manner has varied considerably over the years.

With this type of white paper, you generally find that the first heading after the title will usually be along the lines of “abstract”. The following passage(s) will outline a scenario and the rest of the document will continue to develop this theme and present the information that the creators of the white paper want to pass on to you.

Authoritative Reports

The type of white paper that I have just described is an authoritative report. One objective of an authoritative report is to educate. In the case of corporate produced white papers, this usually means to educate the company's customers. It also serves to collect leads for a company.

The manner in which it is structured means that the authoritative report can present a very powerful argument designed to help people make decisions. No prizes for guessing what decision the authors of this type of white paper want the reader to make. The decision wanted is for the reader to buy their products.

Some of the very early white papers were very informative. Many were “sponsored” by corporations that initially allowed the authors usually researchers, to provide most of the direction and input. This was not very different from the way things worked prior to the advent of the PC. Companies funded certain research projects and the findings became publicly available.

It was of most benefit if a company could entice a well-respected academic to do the research and produce a high quality acclaimed report. In order to avoid embarrassment many companies selected the projects and researchers based around topics, which they the corporate sponsor had absolutely no involvement. This way there was no possibility of the works they sponsored coming back to bite them.

Now we see the authoritative report style of white paper presented with a liberal dose of propaganda. This is counter-productive because most readers will simply tune out and move onto something else. No sale made here. A paper about storage devices sponsored by Hewlett Packard will tell us all about the wonders of some HP product. It will not tell us about the alternatives.

Something that these folk seem to have forgotten is that while their latest and greatest new storage server is a wonderful thing many of us would like some information about other types of storage. HP could tell us about their external storage array but no. only the $150,000 blade center gets a mention.

Organisation-Oriented White Papers

This class of white paper often focuses upon an organisation's internal issues. Organisational policy is the most common topic in this group of white papers. Sometimes this means procedural information, proposed action(s) or other material relevant to a specific topic of current concern.

White Paper Marketing Tools

There are no prizes for guessing what this category of white paper is intended to produce. The “spin” doctors have taken over and the term “white paper” has now changed to refer to documents that unashamedly highlight the benefits of specific technologies and products.

They really are promotional literature more or less in the same formats that we have come to know over the years. The difference is that now they carry the title white paper.

This form of white paper is nearly exclusively a form of marketing communications designed to promote a specific company's solutions or products as it relates to the issue or topic examined.

One should never lose sight of the fact that these documents will spotlight information that is favorable to the company authoring or sponsoring the white paper while minimizing (or omitting) information that may be negative in nature to the company, its products and/or technologies.

Masked White Paper Reports

Here we have another category of documentation that presents labeled either as a white paper or as an exclusive report. In reality, both are purely marketing hype. I think you may have seen the odd “exclusive secret report” or the “35 page report exposing the shocking truth” or maybe this one “underground secrets exposed”.

This group of supposed reports and white papers are nothing more than the painful marketing blurb that most of us can live without. I have checked a few of these ones out and have come to the conclusion that if the person producing the report had used 10 point font the entire 35 page report suddenly becomes a little over two pages. I find it hard to give this type of activity any credit what so ever.

See you next time. Until then enjoy!

We will now continue with a quick look at the primary types and “families” of protocols and some other basic terminology in preparation for a more detailed look into a range of “select” protocols.

Protocol Types

Basically protocols fall into either one of two types; open standard or proprietary standard.

Open Protocols

Open simply means that all of the nitty-gritty details, nuts and bolts are all laid out in a set of documents that is “openly” available to whoever may want to use them.

The biggest advantage of using an open protocol is that it ensures a greater degree of compatible interoperability between end-systems. It was for this very reason that the OSI Reference Model was developed in the first place.

Proprietary Protocols

Proprietary protocols; on the other hand, means that someone or something “owns” them. Think of them as being patented. The proprietor (owner) of a proprietary standard or protocol is under no obligation to disclose the details of “their” proprietary standards and proprietary protocols.

Furthermore; other parties are expressly prohibited from using a proprietary standard or protocol in any manner shape or form, without the prior, express consent of the proprietor (owner).

• Dead Bodies - Computer, network and communications technologies are littered with the dead or dying bodies of untold numbers of truly great protocols and technologies. In terms of their capabilities they outshone all of their peers and contemporaries. Yet they failed commercially. The reason was more often than not due to their proprietary nature.

For Example - Consider the two competing “hot swappable” device buses that have been with us for a few years now. I am talking about the open standard Universal Serial Bus (USB) and Apple® Computer's IEEE 1394 (FireWire™) standards.

• Open - USB being an open standard has meant that manufacturers wishing to make USB devices can refer to the open standards for the specifications that they need to comply with. If they do so and do make their product in compliance with these standards then their device will work in millions upon millions of USB enabled computer systems the world over.
• Proprietary - The scenario is totally different when it comes to Apple's® IEEE 1394 - FireWire™. Any manufacturer wishing to make a FireWire™ capable device must first approach Apple® computers and negotiate a royalties package before Apple® will even let them see the specifications data sheets.

With this royalty being very much like any other surcharge or tax the price of the products will undoubtedly be higher. This was and still is the case. FireWire™ devices are much dearer than their USB counterparts.

• Consumers have voted with their pocketbooks and so millions upon millions of USB devices are turned out every year and only a miniscule fraction of that in numbers of FireWire™ devices are produced annually.

Compound this with the economies of scale and mass production and it doesn't take a brave man to say that FireWire™ will never overtake USB end of story. Yes FireWire™ may hang around for a while yet but it is still doomed none-the-less.

Protocol Families (Stacks)

Protocols; particularly communications and networking protocols are not just one protocol rather they are a bunch of individual protocols that are interrelated. That is to say that each one can do its own job independently of the other protocols in the bunch. However; not much that we humans call worthwhile will ensue.

In order for this bunch of protocols to collectively take input, perform their own individual tasks and to collectively produce output that we humans can use or make use of the entire bunch of protocols needs to be orchestrated. That is they all need to do their jobs in a particular sequence.

Protocol Stack Processing

A protocol stack; or to be more accurate we should say protocol processing stack, is a layered set of protocols which work together to provide a set of network functions. [Source: RFC1392]

The really nice bit about using a protocol processing stack (layered model) is that each layer's output becomes the next layer's input. That is the output from one layer of a processing stack is the input of its immediately adjacent layers. It gets even better because the layers of a processing stack can function in both directions. In short:

• Transmission - When transmitting, each layer will take as input the complete output of its neighbour and treat that as a unit. It will then do its thing and wrap this unit into a new package which it passes onto to the next layer which does likewise in turn and so on the process goes.
• Reception - The opposite happens when the protocol stack is receiving. The protocol at each layer; unwraps the unit given to it by its neighbouring protocol, then passes the unwrapped unit to the next layer in the sequence, which does likewise and so on the process goes.

Open Standard Protocols

• Internet Protocol Suite (TCP/IP)
• Open Systems Interconnection (OSI)
• File Transfer Protocol (FTP)
• UPnP (Universal Plug and Play)
• iSCSI
• Network File System (protocol)

Proprietary Standard Protocols

• AppleTalk
• DECnet
• IPX/SPX (from Novell)
• Server Message Block (SMB) and CIFS
• Systems Network Architecture (SNA)
• Distributed Systems Architecture (DSA)
• Apple Filing Protocol (AFP)
• RSYNC
• Unison

In the next issue we will continue our discussion of protocols by examining some of their attributes standards and standards organisations along with the networking and communications aspects and considerations. Until then enjoy!

Protocol Implementation

• Hardware or Software - Protocols can be implemented in hardware, software or some combination of both.
• High-Level or Low-Level- They may also be high-level or low-level. High-Level and low-level are terms being used to refer to the protocol's relative position functionally on the seven layered OSI Reference Model.
  • OSI Low-Level Layers - The low-level layers are Layer One (the Physical Layer), Layer Two (the Data Link Layer) and Layer Three (the Network Layer).
  • OSI High-Level Layers - The high-level layers of the OSI Reference Model are: Layer Four (the Transport Layer), Layer Five (the Session Layer), Layer Six (the Presentation Layer) and Layer seven (the Application Layer).
• Open Systems Interconnect (OSI) Reference Model - The OSI Reference Model is a topic that I will cover in another article. So stay tuned.

Low-Level Protocol Implementations

At the lowest level the protocol will describe the low-level behaviour of a hardware connection including details of the machine-to-machine interfaces such as bit and byte order (the order in which bits and bytes are sent across a wire).

High-Level Protocol Implementations

With high-level implementations the protocol will be describing high-level exchanges such as those between allocation programs such as the way in which two programs transfer a file across the Internet.

Protocol Design Principles

In order to promote; greater consistency and more efficient build and design processes, in conjunction with a Rapid Application Design (RAD) philosophy the principles of systems engineering have been applied to network protocol design to achieve a set of common network protocol design principles.

These principles include: Effectiveness, Robustness, Reliability, and Resiliency.

Protocol Layering

Protocol layering facilitates protocol implementation by engineers and designers while satisfying requirements for routine usage by humans in human-machine systems.

• Napoleonic Tactics - The basic philosophy here; is one of, Divide and Conquer
• Sub-Division - A very intricate system is broken up into a number of smaller more easily defined and managed sub-units.

These sub-units will perform closely related sub-tasks while interacting with the other layers of the protocol in a limited number of precisely defined ways.

• Mix "N" Match - This makes for a “mix "n" match” approach to developing a network protocol processing stack possible.
• Benefits of the Layered Approach - I have discussed the benefits of using a layered approach to network protocol design in an earlier article entitled “Networking Protocols: Layering Benefits”
• More About the OSI Reference Model - Don't worry I will be getting to the Open Systems Interconnect (OSI) Reference Model in depth in another article soon.

Computing Protocols

A computing protocol is a set of rules, conventions and/or standards governing the communications between computers on a network as well as between various components within the machine.

These rules are designed to regulate various system and network characteristics, assets, services and support. They are heavily dependant upon the following factors:

1. The Physical Network Topologies Supported
   • Linear Bus, Tree, Star, Mesh, Hybrid etc
2. Transmission Media Supported
   • Supported Copper-Based Cable Types - STP, UTP, Coaxial etc
   • Support for Fiber-Optic Cable
   • Wireless Support
3. Hardware Supported
   • Network Interface Card (NIC) - Wired, Wireless
   • Chipset
   • Input/Output (I/O) - External expansion slots and adapter interfaces
   • Plug "N" Play - USB, IEEE 1394 (FireWire)
4. Data Transfer Parameters Supported - Data transfer speeds
5. Access Methods Supported
   • Password Power On - User must key-in the correct password before the BIOS will turn main system power on
   • Authentication - Local, Remote, Password Policies, Biometrics, Smart Cards etc
   • Wake-On-LAN (WOL)
   • Wake-On-Ring (WOR)
   • Real Time Clock (RTC) Power On - The machine will automatically startup at a pre-set specific time. Works very much like an alarm clock
   • Wireless Access Points (WAP)
   • Remote Access via ADSL, Telnet, PPP, PPTP, HTTP, HTTPS, FTP etc
6. Platform(s) Supported
   • Form Factor - AT, ATX, Server, Workstation, Desktop, Mobile, Laptop, Notebook, etc
   • CPU-Based - Intel, AMD, Multi-Core, Multi-Processor, 32-bit or 64-bit, Socket
   • Bus Specifications - AGP, ISA, EISA, PCI, PCI-Express, System Bus, USB
   • Memory Support - DRAM, SDRAM, DDR, Buffered, Non-Buffered
7. Operating System (OS) Supported - MS Windows, Mac OS, Linux, UNIX, OS2/Warp
8. Other Software Supported - Applications, Utilities, Tools, Widgets, Plug-in, Drivers etc

Some of the elements listed above may at first sight appear out of place. However; let me assure you, that this is not the case. For instance let us take a closer look at the humble Ethernet Network Interface Card (NIC).

Ethernet Network Interface Card (Ethernet NIC)

• Architecture - Ethernet is an architecture that describes everything at Layers one and two of the OSI Reference Model necessary for correct implementation including the types of cable and NIC that can be used
• When you buy a NIC; you bring it home, open the machine's case, plug the NIC into a spare expansion slot, and close the case. Now power up your computer. Your machine should boot.
• Once MS Windows® has loaded it (assuming you are running MS Windows®) should auto-detect the new hardware (the NIC that you just installed). A pop-up from the system tray will say something about Windows® has detected your new hardware and is installing the appropriate drivers.
• After a while another pop-up will appear informing you that your new hardware has been installed and is now ready for use
• All of the necessary protocol information required for the correct implementation and networking functionality of your new NIC is included with the firmware of your NIC
• The primary protocol that I am referring to here is the Carrier Sense Multiple Access with Collision Detection (CSMA/CD) protocol which is the protocol used by Ethernet

Token Ring Network Interface Card (NIC)

On the other hand; suppose you wanted to connect a machine to a Token Ring network.

• You would go out and buy a Token Ring NIC, return home, plug it in, power up and away you go
• Just like Ethernet the Token Ring NIC has all the necessary Token Ring network protocols already built into the firmware of the NIC

Incompatibility

It is important to realise that; even though the Ethernet NIC and the Token Ring NIC can both plug into the same expansion slot on your machine's motherboard, they are both incompatible with one another.

In the next issues of about protocols we will be discussing protocol stacks, protocol standards, protocol standards organisations and converging communications. Until then enjoy!!

They then wondered if it would be at all possible to reapply these same lessons and tactics with respect to:

• Computers, Networking, Internetworking and Interoperability
• Communications - Internal, External, Local, Global, Free, Concession, Tariff/Levied
• Data Transmission and Data Reception

The answer of course was; “Yes indeed!! Protocols can be used to govern the rules for the transmission and reception of information between computers and network end-points”. So let us begin by having a look at protocols from a generic perspective.

Protocols: Generic Perspective

In the most generic terms; a protocol is the formal description of a set of rules that describe, enable, govern and regulate various characteristics, aspects, attributes and properties of that which they are relevant and applicable to.

There are so many different protocols concerning such a large number of different or similar products, services, assets and events etc. that the people regulating the various protocols (standards organisations etc.) very quickly came to the conclusion that they were being swamped under the share volume of protocols coming their way. Something had to be done.

Surely; there just has to be a better way. And so the hunt was on. From all of the possibilities on offer a decision was made with respect to which one should be adopted.

The solution chosen was to break up the huge “pool” of protocols into a number of categories of protocols. These different “classes” of protocols continues to grow exponentially to this very day; as does the number of protocols within each class.

Well; when it came to mechanics of naming the various classes of protocols it was decided that it would be best to keep the whole process as simple as possible as you will soon see. Some of the classes of protocols that you will encounter out there in the “real world” today include:

• Physical Protocols - Describe the transmission media for example
• Application Protocols - Archiving, Encryption, Compression and Presentation Protocols
• Network and Internetworking Protocols - Including Helper Protocols such as ARP
• Communications Protocols - Perform such mission critical aspects such as synchronisation
• Security Protocols - Encryption, MD5, SHA, IPSec and Kerberos etc.
• Regulatory Protocols - In most cases compliance with regulatory protocols is not optional
• Computer Protocols - Computer Logic, Process, and Operating System Protocols

Telecommunications Protocols

The set of standard rules that need to be agreed upon by all parties to the communications process in order for the communication to be realistically effective. Hence; telecommunications protocols will describe the rules and standards for data representation, signaling, authentication and error detection that are required to send information over a communications channel.

Communications Protocols

From a telecommunications perspective a communications protocol is that set of standardised rules that are required in order to send information over a communications channel and include:

• Data Representation
• Signaling
• Authentication
• Error Detection

Digital Computer Network Communications Protocols

Incorporate a whole bunch of features that are meant to ensure that the reliable interchange of data can take place over an imperfect communication channel.

Common Protocol Properties

Because protocols cover such a vast array of structures, uses and applications it is very difficult to say that all protocols will do this or that they will contain that. There are however a number of things that they do tend to have in common (more or less). For example:

• They all have some sort of framework that allows them to be “fitted in” with other protocols
• They must be able to do their job without negatively impact other protocols

OSI Reference Model Objectives

In order to create and maintain stability, compatibility and all-round cohesiveness it was agreed that some sort of model needed to be developed. It was also agreed that it would be best if that model had a hierarchal structure since this tends to be the easiest form for the human mind to grasp and “order” structures and thought.

With this in mind the OSI Reference Model was developed. I will be discussing this in more detail later. For now however; the important thing about the OSI Reference Model for layered protocol design; also called a protocol processing stack for reasons that will become obvious as we go along, was that it did introduce commonality where there had been none.

Now; for the first time, we can draw parallels and relationships between the various different protocols. And even though it is still difficult to generalize about protocols; because they can vary so greatly in purpose and sophistication, as a result of using the OSI Reference Model we can identify some common properties including:

• Detection and awareness of the underlying physical connection (wired or wireless), or the existence of the other endpoint or node
• Handshaking
• Negotiation of various connection characteristics
• How to start the message
• How to end the message
• How a message should be formatted
• Error correction - What to do with corrupted or improperly formatted messages
• How to detect unexpected loss of the connection
• How to deal with an unexpected loss of connection
• Graceful Tear-Down - Termination of the session or connection

When About Protocols returns in part two we will discuss computing protocols, protocol design, protocol implementation at both the high-level and the low-level, protocol design and layering, protocol stacks and protocol processing. 

I am also making mention of them here because due to their very nature transparent bridging devices are all about no administration. Plug "n" Play they most certainly are. But what do/can you do when loops enter the picture? Well; in most instances, you certainly can't interface with the software that is running on most of these local workgroup transparent bridges and switches because there is none.

The answer is not to be found blowing in the wind but rather in the form of built-in protocols and algorithms that take care of all of these issues while the device stays true to its “no user input required” philosophy.

Loop Avoidance

Redundancy, Reliability, Robustness and Fail-Over

For reasons of redundancy and the resultant increase in reliability and robustness that it delivers network segments may by configured to be reachable via more than one port (even if in a round-a-bout manner).

Reasons for Creating Networking Loops

• The implementation of redundant fail-over solutions is a major player in the creation of networking loops
• For reasons such as the “safety-net” aspect of implementing multiple hot-swappable “just-in-case” “spare parts” devices
• The idea that if a mission-critical device were to fail then the already installed and powered-up “spare” device can immediately jump into action thereby reducing the system and network outages cause by device failures would be negated. Unfortunately this is another culprit when it comes to loop creation.

But what's all the fuss about?

• Loops cause great network chaos and all round confusion
• Devices such as transparent bridges that operate at the data link layer (2) are particularly hard hit by the negative effects of network loops
• Something had to be done to prevent them from totally crippling the network

This is why loop avoidance is important. Correct configuration and physical connectivity are essential but the moment we introduce redundant pathways loops will exist even in the most simple of networks.

In fact loops can occur in a network with as few as two switches.

The Spanning Tree Algorithm

The Spanning Tree Algorithm is used by switches in Spanning Tree Protocol (STP) mode to counteract the effect of loops and redundant pathways. STP mode has meant that network administrators can introduce redundant pathways and redundant switches into their networks without creating loop-hell.

• When in Spanning Tree Protocol (STP) mode; switch ports that create redundant links will be selectively shut and for as long as the primary (lowest cost path) port remains available they will stay that way.
• If the lowest cost port fails then the Spanning Tree Algorithm will be used to recalculate the network and the redundant pathway port will become active. The message will still get through.

Multi-Destination MAC Addresses

• Frames intended for multiple destinations (transmit once-receive many) such as; broadcasts and multicasts, are forwarded through multiple ports by the transparent bridge.
• Broadcasts will be flooded
• Multicasts will be sent through the appropriate ports

For Example:

• A multicast may be for two or three or however many different segments that need to be reached via more than one port of the transparent bridge or switch at a time
• Those ports that do not have destination nodes for which the multicast is intended do not receive the transmission

Transparent Bridging Implementations

The most common global implementation of transparent bridging today is in the form of integrated multiservice/multifunction devices such as ADSL broadband Modem Routers with built in switches. It is these devices that have enabled networks of all sizes to share their Internet connection among considerable numbers of hosts, nodes and users.

Benefits of Transparent Bridging Include

• Successful isolation of intra-segment traffic, thereby reducing the traffic seen on each individual segment. This is called filtering and occurs when the source and destination MAC addresses reside on the same bridge interface.
• Filtering usually improves network response times, as seen by the user. The extent to which traffic is reduced and response times are improved depends on the volume of intersegment traffic relative to the total traffic, as well as the volume of broadcast and multicast traffic

Learning, flooding and forwarding are all part of normal operation for a transparent bridge/switch and the decisions involved in carrying out these functions are accomplished through the building, maintenance and referencing of the associations of entries in the device's filter (forwarding) table.

Until next time, enjoy!

Transparent Bridging

This is a “no-brainer” technology that delivers plug "n" play capabilities to users and key networking components like workgroup switches.

Transparent Bridging Benefits In a Nutshell

Routers, Switches, and Bridges

While routers interconnect networks, switches and bridges interconnect network segments and devices. Cisco® refers to this as the access layer and that is exactly what these devices do. They give the user or device access to network resources including the infrastructure such as transmission media.

You have got to get on the cable, before you can get to the gateway/router, before you can “surf” the net. We are going to check out a “no-brainer” way of doing this. It's called transparent bridging.

Transparent Bridges

Transparent bridges (including modern switches) are so named because their presence and operations are transparent to network hosts and users alike.

Learning, Forwarding, and Filtering

Making Decisions

In order to fully understand how a transparent bridge decides whether or not it should forward a frame and selects the appropriate interface on which to place that frame we need to take a look at the primary functions of a transparent bridge: learning, forwarding, filtering and loop avoidance.

Loop Avoidance

Another role played by transparent switches is loop avoidance which is one of the topics that will be discussed in Magic of Transparent Bridging Part Two.

Out-of-the-Box

Because a new out-of-the-box transparent bridge has never been exposed to the network that it is about to be connected to I shall start by describing the learning process using a fresh out-of-the-box device first.

Learning

When transparent bridges are first powered on, they learn the network device locations (including workstations) by analysing the source Media Access Control (MAC) Address of all incoming frames from all attached networks.

Memory

Before anything can learn it needs to have the magic ingredient - MEMORY. Transparent bridging and the devices that use it are just like us in that their capacity to learn depends on:

• Writing to Memory - The ability to lay down memory in preparation for future recall
• Reading from Memory - The ability to recall that which is stored in memory
• Recall on Demand - The capacity to recall at will. It is this ability that allows you to randomly access the contents of memory or in computer lingo - Random Access Memory (RAM)
• Selective Recall - The ability to selectively recall preferred memories at will
• Application - The capacity to apply the contents of memory to the situation at hand
• Being Smart - The being smart part is all about selecting the most appropriate memory item to recall with regards to your current dilemma

The Filter Table

That part of memory that we are interested in here is the memory which the device (switch) uses in performing the process of transparent bridging. It is called a Filter Table. For reasons that will become obvious shortly the Filter Table is also known as:

• Forwarding Table
• Media Access Control (MAC) Address Table
• Hardware Address Table

Nomenclature and Misconceptions

The important thing here is that all of the above listed names are indeed correct alternate names (synonyms) for the Filter Table. Furthermore; they are more or less interchangeable, it is however most definitely wrong to use the term Routing Table in reference to a transparent bridging device's Filter Table.

Filter Table Building Example:

Here is a short example of how a device uses transparent bridging to build its Filter Table:

• The transparent bridging device sees a frame arrive on Port 1
• Examining the source address field of this frame the device learns that the transmission was from Host A
• It concludes that Host A can be reached through the segment connected to Port 1
• The transparent bridging device examines the contents of its Filter Table. Because this is a new device and this is the first network conversation that this transparent bridge has experienced there will be no entries in its Filter Table.
• The transparent bridging device will now create a new entry in its Filter (forwarding) Table listing Host A as reachable via Port 1
• Every time a frame arrives at the transparent bridging device this process is repeated
• It is in this way that a transparent bridge builds its Filter Table
  • This is what is Referred to as the LEARNING Process

Forwarding - Flooding

Transparent bridges/switches examine incoming frames to determine their intended destination Media Access Control (MAC) Address they will then:

• Look-Up Their Filter Table - In transparent bridging mode the bridge/switch will always refer to its Filter Table (forwarding) to check for any entries relating to this MAC Address. Who knows? There may already be an entry indicating through which port this destination can be reached.
• In our case we have a new transparent bridge. So; unless the frame is intended for Host A, the bridge will not have any entries corresponding to the intended destination MAC Address in its Filter Table
• Because the transparent bridge doesn't know anything about this MAC Address it can not make the decision to forward the frame exclusively out of the one correct specific port
• So; by default, whenever a transparent bridge encounters a frame with a destination MAC Address that it hasn't encountered before (the first time) it will “flood” the frame out of every port except the one on which it arrived.
• Our device is no different and that is exactly what it does. It sends copies of the frame out every port except the one which it arrived on.

Forwarding - Filtering

Filter Table Building

As more traffic transpires over time the transparent bridge will continue building its Filter Table.

• New entries are created for each new (learned) source MAC Address along with the corresponding port through which this address can be reached.

Known Source MAC Address and Port Entries

Eventually the transparent bridge will lookup the source MAC Address of an incoming frame in its Filter Table and it will find an existing entry.

• If; the known entry (previously recorded) in the transparent bridge's Filter Table and the current frame's source MAC address and port number match, the transparent bridge will not need to add this source MAC address to its Filter Table.

Known Destination MAC Address and Port Entries

• Now the transparent bridge examines the frame in order to determine the destination MAC address of the newly arrived frame
• It will then check its Filter Table for any entries pertinent to the intended destination MAC Address of the current frame
• This time it finds an entry that lists this particular destination MAC Address as being reachable via one of its (the bridge/switch) ports

Since the destination MAC Address of the current frame is known to be contactable via a specific port on the transparent bridge/switch the switch/bridge will now be able to selectively place the frame onto the correct network segment via the appropriate port.

Filtering

Now instead of 'flooding` this frame out of all ports; bare the one through which it arrived, the transparent bridge/switch will be bale to selectively and exclusively forward the frame only out of the port indicated by its Filter Table as being the port via which this destination MAC can be reached.

This is what is known as filtering.

Only the segment on which the destination MAC Address resides now receives the transmission thereby allowing all other devices located on all other ports to be free to transmit themselves.

Not Party To the Conversation

This means that devices can transmit or receive simultaneously while other network conversations; that they are not party to, are in progress. The importance of this cannot be underestimated as it results in considerable improvements to network performance.

There is still one proviso however; and that is that only one conversation at a time can take place on a segment. The network is a one conversation at a time/segment network.

Collision Domains - The Implications

Suppose a device that uses transparent bridging has six ports and each of these ports is used to connect different devices or network segments. The result would be that:

• The network will now be comprised of six independent segments
• All conversations between nodes on the same segment will remain confined to that segment. This is known as a collision domain.

Now suppose that nodes on two different segments are having a conversation then:

• The transmission will be contained within those two segments
• The other four segments are free to go about their own conversations

By segmenting collision domains transparent bridge greatly improve network efficiency, performance and the potential available effective bandwidth.

Improved Network Bandwidth and Efficiency

Thus a six port transparent bridge can cater for three different two segment conversations simultaneously. Whereas prior to network segmentation only one conversation at a time could take place over the entire network. This is a much greater improvement in both efficiency and bandwidth while reducing the potential for collisions.

Such technologies as loop avoidance, redundancy, the spanning tree algorithm and STP mode will all be discussed in The Magic of Transparent Bridging Part Two. Until then enjoy!!

Guess what?

Today's topic: internal switching methods, is one that you must know. This is not optional; rather it is mandatory, and you can bet your bottom dollar that there will be questions on the CCNA exam that are directly related to and based upon your knowledge and understanding of these internal switching methods and concepts.

Network Foundations

Internal switching methods are the foundation upon which modern networks are based. This includes: businesses; large and small, home networks, government and educational institutions to name but a few. What's more they apply equally to both the managed (Cisco®, Netgear® etc.) and the unmanaged (D-Link®, 3Com® etc.) varieties of modern switches.

New Class of Networking Devices and Technologies

If you head on over to Cisco's® website and check out Cisco's switching and routing products roadmaps you will see that a new type (class/category) of network, networking and internetworking devices are now in full production and have already been implemented into production environment networks.

These new types of networking devices are based on what Cisco® likes to call a “switch/switching fabric”. There is little doubt that in the not too distant future we will be seeing the Cisco® switching fabric being incorporated into nearly all; if not all members of Cisco's hardware products range. It has already been integrated into their new Catalyst™ and Catalyst Express™ series of switches.

Internal Switching Methods

The three main methods of internal switching used in production environment switches today are; in order of increasing latency:

1. Cut-Through (Fast Forward)
   • When in Cut-Through mode the switch waits for the destination Media Access Control (MAC) Address (also referred to as the hardware address) to be received
   • It then looks up the destination MAC Address in its MAC filter table
   • Once the switch knows which port to forward the frame through it does so (even before the entire frame has arrived)
   • Cisco® sometimes calls this the Fast Forward method
2. Fragment Free (Modified Cut-Through)
   • Fragment Free is the default mode used by Cisco® Catalyst® 1900 series switches
   • It is also referred to as modified cut-through
   • When in Fragment Free mode the switch will check the first 64 bytes of a frame for fragmentation. The vast bulk of errors occur within the first 64 bytes.
   • Frame fragments known as runts are created as a result of collisions
   • If a runt is detected the switch will drop the frame
   • If all is well and there is no fragmentation the switch will then look up the destination MAC Address in its MAC filter table
   • Once the switch knows which port it should forward the frame through it does so
3. Store-and-Forward
   • When in Store-and-Forward mode the switch will store the incoming data frame in its internal buffer
   • Once the complete frame has been received and stored to buffer the switch will run a Cyclic Redundancy Check (CRC) against the frame
   • If the CRC passes the switch will then look up the destination MAC Address in its MAC filter table
   • Once the switch knows which port to forward the frame through it does so

Runts and Other Frame Corruption

Runts are the by-products of collisions. Simply by checking the frame for fragmentation before forwarding it greatly reduces the number of runts being propagated throughout the network.

Remember that the vast majority of errors occur in the first 64 bytes of the frame. By checking this part of a frame (the first 64 bytes) will allow the switch to detect and drop the majority of corrupted frames while doing as little work as possible. This is known as working “smarter”.

Reducing the number of runts and frames with other errors that are placed on the network's transmission media can improve network performance considerably. This is simply because we are not transporting runts or other corrupted frames that will be automatically rejected immediately the corruption is detected by the intended recipient.

The recipient bases this decision to drop the frame on the grounds that errors have occurred and/or these frames (the runts) are incomplete and so untrustworthy. Thus the intended recipient will automatically drop these frames.

So: if only, for reasons of efficiency and improved network bandwidth we may as well just drop them at the switch level because their eventual dropping is inevitable. In some instances this is the end of the line.

Once the device that requested the information in the first place: becomes aware that the frame never got through, it will issue are request for the remote device to retransmit that frame.

On the other hand if the remote device does not receive an acknowledgement from the requesting machine informing the remote machine that all parts of the conversation were satisfactorily received the remote machine will assume that something happened to the frame in transit.

And so it will then automatically retransmit any frames for which it has not received an acknowledgement of receipt for. These transmissions, retransmission requests and transmission control are the realm of the Transmission Control Protocol (TCP) if we are using the TCP/IP protocol stack.

I will be covering TCP/IP in another article. So until we meet again in a future edition of The CCNA Summary Series enjoy!!!

These are all concepts that we need to understand before we can get into the nitty-gritty of exactly what a specific protocol does, why it does it, why it does it the way that it does it, how it does it and when it does what it does. We also need to be able to distinguish the commonalities and differences that exist between different protocols. So let's get at it.

Routing

Routing is the process of moving data from one network to another network

Routing Protocols

In short routing protocols are the software that sends and receives routing information packets to and from other routers and in so doing allows the router to:

• Dynamically Advertise Routes
• Dynamically Learn Routes
• Determine Possible Routes
• Determine Route Availability
• Determine Route Efficiency
• Determine Best Route to Destination
• Determine Alternative Routes

Here are some of the routing protocols currently in use today:

• RIP - Routing Information Protocol
• RIP II - Routing Information Protocol II
• OSPF - Open Shortest Path First
• IS-IS - Intermediate System to Intermediate System
• IGRP - Interior Gateway Routing Protocol
• EIGRP - Enhanced Interior Gateway Routing Protocol (Cisco proprietary protocol)
• BGP - Border Gateway Protocol

All you need to remember is that routing protocols convey routing information such as routing tables, network IDs, hop counts, administrative distance/cost, other metrics and autonomous numbers to neighbouring routers.

To illustrate this here is a simple version of what routing protocols get up to:

Router1: “Hey! Neighbour here is something really good it's my routing table. Check it out and see if there is anything in it that you don't know already.”

Router2: “Well thanks a lot. Here is mine. Do likewise.”

Routed (Routable) Protocols

A routed protocol is routable meaning that it can be routed by a router. This means that it can be forwarded from one router to another.

Routed protocols contain the data elements; such as IP Addresses, that are required in order for a packet to be sent outside of its host network or network segment.

IP (Internet Protocol) and IPX (Internet Packet Exchange) are examples of routed protocols.

Non-Routable Protocols

Non-routable protocols cannot survive being routed. In short non-routable protocols have a very narrow world view in that they assume that every computer that they will ever need to communicate with exists on the same network segment as them.

Today we find that those protocols that are not multi-segment aware are disappearing from use. The following are examples of non-routable protocols:

• NetBEUI
• DLC
• LAT
• DRP
• MOP

Interior Gateway Protocols (IGP)

Interior Gateway Protocols are used to communicate routing information between routers within an autonomous system. Because they transport (communicate) routing information they are routing protocols and not routed protocols as many people mistakenly believe.

Conclusion

Today the world is very Internet centric and so we find that those elements, protocols, systems etc. that can't get along with the Internet are doomed to fade rather rapidly into oblivion and non-routable protocols are among the first to go.

Well it's now time to go. So until we meet again in a future edition of The CCNA Summary Series enjoy!

The Hierarchal Approach to Network Protocol Development

The hierarchal or layered approach to networking produces what is known as a layered architecture. This is in contrast to the “flat” or “horizontal” approach. The benefits to layering networking protocol specifications are many including:

Interoperability - Layering promotes greater interoperability between devices from different manufacturers and even between different generations of the same type of device from the same manufacturer.

Greater Compatibility - One of the greatest of all of the benefits of using a hierarchal or layered approach to networking and communications protocols is the greater compatibility between devices, systems and networks that this delivers.

Better Flexibility - Layering and the greater compatibility that it delivers goes a long way to improving the flexibility; particularly in terms of options and choices, that network engineers and administrators alike crave so much.

Flexibility and Peace of Mind - Peace of mind in knowing that if worst comes to worst and a key core network device; suddenly and without prior warning decides to give up the ghost, you can rest assured that a replacement or temporary stand-by can be readily put to work with the highest degree of confidence that it will do the job.

Even though it may not be up to doing the job at the same speed it will still do it; at least, until a better, more permanent solution can be implemented. This is a state of affairs that is much more acceptable than for a lengthy cessation of network services or assets unavailability to occur. 80% is oh so much more pleasing than 0%.

Increased Life Expectancy - Increased product working life expectancies as backwards compatibility is made considerably easier. Devices from different technology generations can co-exist thus the older units do not get discarded immediately newer technologies are adopted.

Scalability - Experience has shown that a layered or hierarchal approach to networking protocol design and implementation scales better than the horizontal approach.

Mobility - Greater mobility is more readily delivered whenever we adopt the layered and segmented strategies into our architectural design

Value Added Features - It is far easier to incorporate and implement value added features into products or services when the entire system has been built on the use of a layered philosophy.

Cost Effective Quality - The layered approach has proven time and time again to be the most economical way of developing and implementing any system(s) be they small, simple, large or complex makes no difference.

This ease of development and implementation translates to greater efficiency and effectiveness which in turn translates into greater economic rationalisation and cheaper products while not compromising quality.

Modularity - I am sure that you have come across plug-ins and add-ons. These are common and classical examples of the benefits to be derived from the use of a hierarchal (layered) approach to design.

Innate Plasticity - Layering allows for innate plasticity to be built into devices at all levels and stages from the get-go, to implementation, on through optimisation and upgrade cycles throughout a component's entire useful working lifecycle thereafter.

The Graduated, Blended Approach to Migration - Compatibility enables technologies to co-exist side-by-side which results in quicker uptake of newer technologies as the older asset investments can still continue to be productive. Thus migration to newer technologies and standards can be undertaken in stages or phases over a period of time.

This is what is known as the graduated blended approach; which is the opposite of the sudden adoption approach.

Standardization and Certification - The layered approach to networking protocol specifications facilitates a more streamlined and simplified standardisation and certification process; particularly from an “industry” point of view. This is due to the clearer and more distinct definition and demarcation of what functions occur at each layer when the layered approach is taken.

Task Segmentation - Breaking a large complex system into smaller more manageable subcomponents allows for easier development and implementation of new technologies; as well as facilitating human comprehension of what may be very diverse and complex systems.

Portability - Layered networking protocols are much easier to port from one system or architecture to another.

Compartmentalisation of Functionality - The compartmentalisation or layering of processes, procedures and communications functions gives developers the freedom to concentrate on a specific layer or specific functions within that layer's realm of responsibility without the need for great concern or modification of any other layer.

Changes within one layer can be considered to be in self-contained isolation; functionally speaking, from the other layers. Modifications at one layer will not break or compound the other layers.

Side-Kicks - The development of “Helper” protocols or side-kicks is much easier when a layered approach to networking protocols is embraced. This is especially so when it comes to the development of “helper” protocols that are developed more or less as after-thoughts because the need arose.

Reduced Debugging Time - The time spent debugging can be greatly reduced as a direct result of taking the layered approach to developing network protocols because debugging is made easier and faster when using the layered approach as opposed to not using it.

Promotion of Multi-Vendor Development - Layering allows for a more precise identification and delineation of task, process and methodology. This permits a clearer definition of what needs to be done, where it needs to be done, when it needs to be done, how it needs to be done and what or who will do it.

It is these factors that promote multi-vendor development through the standardisation of networking components at both the hardware and software levels because of the clear and precise delineation of responsibilities that layering brings to the developers' table.

Easier Binding Implementation - The principle of binding is far easier to implement in layered, tiered, and hierarchal systems. Humans also tend to understand this form easier than the flat model.

Enhanced Troubleshooting and Fault Identification - Troubleshooting and fault identification are made considerably easier thus resolution times are greatly reduced. Layering allows for examination in isolation of subcomponents as well as the whole.

Enhanced Communications Flow and Support - Adopting the layered approach allows for improved flow and support for communication between diverse systems, networks, hardware, software, and protocols.

Support for Disparate Hosts - Communications between disparate hosts is supported more or less seamlessly thus Unix, PC, MAC & Linux to name but a few can freely interchange data.

Reduction of the Domino Effect - Another very important advantage of a layered protocol system is that it helps to prevent changes in one layer from affecting other layers. This helps to expedite technology development.

Rapid Application Development (RAD) - Work loads can be evenly distributed which means that multiple activities can be conducted in parallel thereby reducing the time taken to develop, debug, optimize and package new technologies ready for production implementation.

Conclusion

As you see the benefits of adopting the hierarchal approach to networking protocols are many. The reason that carries the most weight in any given situation will be situation dependent.

Well it's now time to go. So until we meet again in a future edition of The CCNA Summary Series enjoy!