Networking 101 (Part Two)

By Patrick Hunter

When last we met, we discussed the nature of IP communication and walked through several steps of the encapsulation process in the Open Systems Interconnect (OSI) reference model of communication. We covered the roles and responsibilities of various network components, like the computer, routers, switches, and the cable modem (remember, it’s just a specialized Ethernet. Read part one here.

So, let’s dig in a little deeper into this connectivity through the cable modem. From the perspective of the customer’s Internet service, the cable modem doesn’t have an IP address and does not route IP packets. But we do know that the cable modem has a NIC to which the customer’s computer is connected. So, if it has a NIC, then it has a MAC address as well! But remember, when we discussed the fact that the customer’s computer would have the MAC address of the default gateway as the destination MAC address, we also noted that this would be on the CMTS, not the cable modem. So, when the cable modem receives an Ethernet frame with a destination MAC address that is not its own, what is the modem supposed to do with that frame? Based on the rules of Ethernet (the protocol), it will simply switch the frame out its other physical interface, which happens to be the connection to the cable plant, headed back toward the headend. Aha! For me, this was a “lightbulb” moment. The cable plant, all the actives, passives, and fiber optic node and cabling; those things are all just like a segment of Cat5 cable! So really, the cable plant itself is the most sophisticated, living, breathing Ethernet cable in the world, especially when you bring in the latest DOCSIS standards and all of the incredibly advanced features that function at this layer. At least, that’s my take on it.

OK, so we’ve taken our “Hello,” encapsulated it into a TCP or UDP segment, further encapsulated it into an IP packet, yet further encapsulated it into an Ethernet frame, and dropped all of the bits (ones and zeros) onto the wire to arrive at the next network location. As we discussed, the frame arrives at the cable modem, the modem looks at the destination MAC address and forwards the frame onto the cable plant, and it arrives at the CMTS. When the CMTS receives the Ethernet frame, it identifies that the destination MAC is indeed its own MAC address on that interface (the one connected to the cable plant), and now has work to do. For the CMTS, de-encapsulating (or decapsulating, if you like) the frame is one of the first steps. Now the CMTS handles the IP packet by examining the destination IP address and making a routing decision. Remember, this is Layer 3 routing, and the router (CMTS) is not concerned with the entire path for the conversation, just the best direction to route the packet. Once the CMTS determines the best next Layer 3 hop (the next router headed toward the final destination), it re-encapsulates the packet as an Ethernet frame with its own MAC address as the source and the next-hop router’s MAC address as the destination and drops all those ones and zeros on the wire. This process continues over and over, Layer 3 hop by hop until it reaches the destination computer that was originally targeted when the conversation began.

This is another lightbulb moment, in my opinion. It took quite a while for this to sink in for me, but I realized that along the end-to-end path, an IP packet always keeps the same source and destination IP addresses, but the source and destination MAC addresses change constantly as each Layer 3 router is crossed.

So again, neither the source nor destination computer ever really knows each other’s MAC addresses typically, just the IP addresses. The IP addresses are global, whereas the MAC addresses are very much local. If this is your first pass reading this article, don’t worry at all if it is very confusing. It can be a bit bewildering at first when you begin to digest the details.

I can say with complete confidence that my first few times trying to absorb these concepts I was really very lost.

Now, let’s finish up the overall transmission of our “Hello” upon arrival at the remote computer. That Ethernet frame arrives on the wire at the NIC of the remote computer (the one receiving the “Hello”) and if everything works like it should, the destination MAC address is in fact the MAC address of that NIC. The NIC de-encapsulates the Ethernet frame and passes the IP packet up to the network process of the computer. The network layer process identifies that the destination IP address is indeed this computer’s IP address, further de-encapsulates the IP packet and passes that TCP or UDP segment to the transport layer process of the computer. The transport process takes note that a conversation has begun from another computer and records that fact. It then further de-encapsulates the segment and passes that original payload up to the higher-layer processes in the computer. Now the application that is running on that computer is able to receive and display to the user the original “Hello.” Mission accomplished! When everything works perfectly, it seems like a sound process. But what about when things don’t work so well? What about when there are bit errors caused by various system impairments? How does this process work?

There are a few places in the OSI protocol stack that check for, and sometimes attempt to correct, errors. The first layer that gets involved is the data link layer. Ethernet frames have many different pieces of information contained in the header, including those source and destination MAC addresses.

But the Layer 2 encapsulation also includes a “footer,” which contains error-checking information. The frame check sequence (FCS) information at the tail-end of the Ethernet frame is specifically for checking to make sure that no physical issues have caused errors in the construction and transmission of the Ethernet frame. Every NIC that receives an Ethernet frame must compare the contents of the frame against the FCS to ensure that everything checks out. Based on the contents of the frame, when it is first constructed, a cyclic redundancy check is done to calculate the value for the FCS. When the frame is received, a similar calculation is done to validate that none of the information was corrupted. In the event that the frame doesn’t check out successfully, the frame is dropped by the NIC. Notice that at Layer 2, no form of error recovery takes place. No message indicating that the frame was dropped is sent back to the original sender. It is simply dropped. It is up to the other protocols to determine if something was missed and if any correction or resending of the information is required. If the frame checks out, then its payload is passed onto the Layer 3 processes for routing.

Assuming the information doesn’t arrive at the far end successfully, whether or not error checking or correction is done depends on the Layer 4 or transport layer protocol at work. TCP requires that every segment be acknowledged by sending a segment back to the original sender validating that it was received successfully. If something comes up missing, TCP accounts for and attempts to correct it by retransmission if necessary.

UDP on the other hand, does not attempt to seek acknowledgement and correct for any lost information. Depending on the nature of the data being transmitted, UDP may be preferable to TCP. In those cases, the upper layer protocols may attempt to account for errors and correct them.

CableLabs’ Data-Over-Cable Service Interface Specifications (DOCSIS) 3.0 MAC and Upper Layer Protocols Interface Specification notes that the physical link between the CMTS and the cable modem is typically between 10-15 miles in length at maximum. But, it also notes that a maximum distance could be about 100 miles (the spec actually says 0.8 ms one-way transit delay). This is a testament to the power of the HFC architecture to deliver data services to our customers.

Ensuring quality service delivery at the Layer 1 level comes back to old fashioned sound installation and service practices. There is still no substitute for following industry and engineering standards with respect to connector and cable installation. Although many algorithms exist to compensate for some errors in data transmission, the goal as technicians should be to reduce the reliance on error-correcting mechanisms as much as possible. This means religiously checking for proper connector tightness and appropriate bend radii for all cables installed. It means that when a freshly-installed cable is two feet too short, a new cable should be run if possible, rather than adding an unnecessary splice to a brand new installation. It certainly means that using every tool available for ensuring effective radio frequency (RF) propagation across the physical media is as important as ever. Great tools for the job are still signal level meters, leakage detectors, and sweep equipment. Modulation error ratio (MER) and bit error ratio (BER) detection systems are great as well. Test equipment that functions as a cable modem certainly help to tell the full story about how the transmission of information reacts to the cable plant and other devices in the path. Ensuring that the data transmitted arrives as error-free as possible ensures that when error-correcting mechanisms are needed, they have plenty of headroom to work with, which gives the plant the most flexibility possible. It is well known that levels can vary over time across an HFC link.

Properly engineered and installed connectors are not limited to coaxial cable by any means. It is just as important to properly connectorize twisted-pair Cat5 cable as well. This cable is just as important in the transport of data as the coax. The proper connector should be used for the type of twisted-pair to be installed. Technicians may most often find themselves using pre-made twisted-pair “jumpers” to connect a cable modem to a device, but circumstances may exist that require a technician to competently prepare and connectorize Cat5 cable. Category 5 (and Cat5e, and others) has 4 pairs of wires. They are color-coded, and the conductor itself is either solid-copper or stranded-copper. The 8P8C connector, often mistakenly referred to as an RJ-45 connector, can be made to connect solid-copper or stranded-copper specifically, so be certain of the type of cable in use to prevent possible connectivity issues upon installation.

Understanding the nature of TCP/IP/Ethernet communication is a valuable tool to have in a professional toolkit for cable telecommunications. Understanding the principles of RF propagation, and how to optimize and troubleshoot it is also a valuable tool to have. But the technician or engineer who possesses deep knowledge of both is armed with the tools to succeed in this field for a very long time to come. In my current role managing teams of network engineers, I have seen countless times the value of professionals who have chosen to grow their knowledge base in both HFC and IP. They nearly always top the list of candidates for my teams. I am proud to say that we have a unique field of engineering in this industry and those hungry to learn as much as they can year after year prove to be successful in the long run.

Patrick Hunter — “Hunter”

Director, IT Enterprise Network and Telecom,
Charter Communications
hunter.hunter@charter.com

Hunter has been employed with Charter since 2000 and has held numerous positions, from Installer, System Technician, Technical Operations management, Sales Engineer, and Network Engineer. His responsibilities include providing IP connectivity to all users in Charter’s approximately 4,000 facilities, including executive and regional offices, technical centers, call centers, stores, headends, hubsites, and data centers. Mr. Hunter has served on the SCTE Gateway Chapter Board of Directors since 2005. He spends his spare time mentoring, teaching, and speaking on IP and Ethernet networks as well as careers in the network field.

Credit: Shutterstock
Credit: Cartoonstock.com