IP Address Format
An IP address is a 32-bit number that can be represented in many formats. Routers and computers are designed to operate efficiently on binary numbers, so a binary representation is a natural way for them to store and manipulate IP addresses. A typical 32-bit IP address to a router would look something like this:
10011100000110100001111000111100
This may be a fine representation for routers, but for us it is not the most appealing method. So let’s take a look at the binary representation and see if we can find a way to represent these numbers using a method that may be a bit more palatable. One way is to simply represent the IP address as a decimal number. The binary number used in the example above has a decimal value of
2,618,957,372
This may be easier to read, but the size of the number makes it cumbersome to work with. Another representation scheme is to break up the binary number into pieces and represent each piece as a decimal number. A natural size for binary pieces is 8 bits, which is the familiar “byte” or not-as-familiar “octet” (octet is the telecommunication term, but the two words can be used interchangeably). So let’s take our binary number, write it using groups of 8 bits (four octets) and then represent each group as a decimal number.
10011100
00011010
00011110
00111100
156
26
30
60
Table 2-1: Range of IP Addresses
Low
High
Binary
0000000000000000000
0000000000000
11111111111111111111111111111111
Decimal
0
4,294,967,295
Dotted Decimal
0.0.0.0
255.255.255.255
We don’t need all that space between the numbers, so let’s use a period, or dot, as a separator. Now our IP address has the form
156.26.30.60
which is referred to as dotted decimal notation. How many IP addresses are there? The range of IP addresses in all our representation schemes is shown in Table 2-1.
Theoretically, there are 4,294,967,296 possible IP addresses, although we will discover in this chapter that the actual usable number of IP addresses is much smaller.
Overview IP
A complete understanding of unicast and multicast IP addressing is required in order to design and implement robust IP networks. Concepts such as subnetting and Variable Length Subnet Masks (VLSM) should be mastered so that IP addressing plans make efficient use of your assigned address space. The concept, operation, and configuration of IP unicast routing protocols, RIP, IGRP, EIGRP, and OSPF, also need to be mastered because most multicast routing protocols rely on the underlying unicast routing configuration.
Multicast Communication Model
Now the fun begins. The problem to solve here is the one-to-many communication scenario. If a host wants to send the same packet to more than one receiver, how can this be accomplished? We can try using the unicast communication model and would be successful, but problems occur. Assume host A wants to send a packet to five hosts using the unicast model. This implies that host A knows the IP address of each receiver. If this is the case, then host A would need to send the same packet to five different IP addresses, as shown in Figure 1-6.
As the number of receivers increases, the number of packets that needs to be sent increases linearly. In other words, for n receivers, the host would need to send n copies of each packet. If the host is sending a real-time audio or video presentation, this solution may be workable for very few receivers, but as the number of receivers increases, the load of replicating packets on the host would be such that the delay between distinct packets would be unacceptable. Also, the links on the source router, router E in Figure 1-6, would have the bandwidth severely depleted.
Another major problem with this scheme is the host not knowing where the receivers are. If the receivers that require the traffic don’t change, then they could be entered, but this would be extremely restrictive because new receivers could not dynamically join or leave the group. And what about the broadcast model? Certainly every host on the local subnet would receive the traffic and each packet would only have to be sent once. So what’s the problem? Two come to mind. The first is that only receivers on the same subnet receive the traffic, while receivers on other subnets cannot receive it because the router blocks broadcasts. This is probably a good thing because we don’t want a broadcast to be delivered to the whole world. Yes, some people would like to do this, but in general it is not a good idea.
The second problem with using a broadcast is that every host is required to process the ethernet broadcast in order to determine if the traffic is intended for the host. The IP packet would have to be extracted from the ethernet frame and, because the destination IP address is also a broadcast address, the UDP or TCP portion of the packet would need to be extracted and passed up the protocol stack. If there is a process expecting the data, it would be passed to the application layer. If there is not a process expecting the data, then the data would be discarded. For those hosts not expecting the data, this would be a waste of valuable processing time and a source of many user complaints. Looks like we need another model.
For the multicast communication model, we will need two new types of addresses, an IP multicast address and an ethernet multicast address. An IP multicast address identifies a group of receivers that want to receive traffic destined for the group. Because all IP packets are encapsulated in ethernet frames, a multicast ethernet address is also required. For the multicast model to function correctly, hosts should be able to receive both unicast and multicast traffic, which mandates that hosts need multiple IP and ethernet addresses. A unicast IP and ethernet address are used for unicast traffic and zero or more IP, and ethernet multicast addresses are used for multicast traffic. Zero multicast addresses are needed if the host will not be receiving multicast traffic. A pair of multicast addresses, IP and ethernet, are required for each multicast group that the receiver wishes to join. A major difference between the unicast and multicast addresses is that unicast addresses are unique on each host, while multicast addresses are not. If five hosts wish to receive multicast traffic destined for group A, for example, then the hosts would all listen for traffic destined for the same multicast address, both IP and ethernet. The amount of traffic from the unicast case would be greatly reduced, as shown in Figure 1-7.
As the number of receivers increases, the number of packets that needs to be sent increases linearly. In other words, for n receivers, the host would need to send n copies of each packet. If the host is sending a real-time audio or video presentation, this solution may be workable for very few receivers, but as the number of receivers increases, the load of replicating packets on the host would be such that the delay between distinct packets would be unacceptable. Also, the links on the source router, router E in Figure 1-6, would have the bandwidth severely depleted. Another major problem with this scheme is the host not knowing where the receivers are. If the receivers that require the traffic don’t change, then they could be entered, but this would be extremely restrictive because new receivers could not dynamically join or leave the group. And what about the broadcast model? Certainly every host on the local subnet would receive the traffic and each packet would only have to be sent once. So what’s the problem? Two come to mind. The first is that only receivers on the same subnet receive the traffic, while receivers on other subnets cannot receive it because the router blocks broadcasts. This is probably a good thing because we don’t want a broadcast to be delivered to the whole world. Yes, some people would like to do this, but in general it is not a good idea.
The second problem with using a broadcast is that every host is required to process the ethernet broadcast in order to determine if the traffic is intended for the host. The IP packet would have to be extracted from the ethernet frame and, because the destination IP address is also a broadcast address, the UDP or TCP portion of the packet would need to be extracted and passed up the protocol stack. If there is a process expecting the data, it would be passed to the application layer. If there is not a process expecting the data, then the data would be discarded. For those hosts not expecting the data, this would be a waste of valuable processing time and a source of many user complaints. Looks like we need another model.
For the multicast communication model, we will need two new types of addresses, an IP multicast address and an ethernet multicast address. An IP multicast address identifies a group of receivers that want to receive traffic destined for the group. Because all IP packets are encapsulated in ethernet frames, a multicast ethernet address is also required. For the multicast model to function correctly, hosts should be able to receive both unicast and multicast traffic, which mandates that hosts need multiple IP and ethernet addresses. A unicast IP and ethernet address are used for unicast traffic and zero or more IP, and ethernet multicast addresses are used for multicast traffic. Zero multicast addresses are needed if the host will not be receiving multicast traffic. A pair of multicast addresses, IP and ethernet, are required for each multicast group that the receiver wishes to join. A major difference between the unicast and multicast addresses is that unicast addresses are unique on each host, while multicast addresses are not. If five hosts wish to receive multicast traffic destined for group A, for example, then the hosts would all listen for traffic destined for the same multicast address, both IP and ethernet. The amount of traffic from the unicast case would be greatly reduced, as shown in Figure 1-7.
Broadcast Communication Model
The broadcast model is one in which a host sends to everyone on the subnet. ARP is not needed because the ethernet broadcast address is a well-known address with the value 0xFF FF FF FF FF FF (Broadcast IP addresses also exist and are covered in Chapter 2). In the unicast model, a host could send an IP packet to any host on any network (assuming we have a route to the destination host). In the broadcast model, the scope of the broadcast is the local subnet. Routers block broadcast traffic, so the scope of a broadcast is limited to the local subnet (see Figure 1-5).
Unicast IP Communication Model
Three models exist for communication between hosts on a network whether or not the network is an intranet or the Internet. The first model is the unicast model, which is one-to-one communication. In Figures 1-4a through 1-4c, one host desires to send traffic to another specific host on the same IP subnet (IP addressing and subnets are covered in detail in Chapter 2, “Internet Protocol (IP), Unicast, Broadcast and Multicast Addresses”). For the ethernet Local Area Network (LAN), the hosts must contend with two different address schemes. The first scheme is the ethernet address that is burned into the Network Interface Card (NIC). The ethernet address is a six-byte (48-bit) link layer address that is globally unique and cannot be changed. Because the ethernet address is burned into the NIC, the ethernet address of the host changes if the NIC is changed. We have seen that on an ethernet LAN all data traffic is encapsulated in frames. Even though the host is sending to an IP address, the IP packet must be encapsulated in an ethernet frame. To accomplish the encapsulation, the sending host must resolve the receiving host’s IP to ethernet address mapping. The mapping is accomplished using the Address Resolution Protocol (ARP).
In Figures 1-4a-c, host A wishes to send a packet to host B. Host A knows the IP address of host B but not the ethernet address of host B. The ARP process, illustrated in the figures, proceeds as follows:
1. Host A sends an ARP broadcast (see Figure 1-4a) that all hosts on the network receive, including the router.
2. Host B receives the ARP and recognizes that the IP address contained in the ARP request belongs to host B. Host B sends an ARP reply that contains the ethernet address for host B (see Figure 1-4b).
3. Host A can now encapsulate the IP packet in an ethernet frame and transmit the frame to host B (see Figure 1-4c).
a. Host A sends an ARP request for IP address 172.16.1.2.
b. Host B responds with its ethernet address.
c. Host A can now send to host B.
If host A wants to send a packet to a host on another IP subnet, then the packet must be sent to the router. Host A will have a default gateway configured that points to the router interface attached to the LAN containing host A. Because the destination IP address is on a different subnet, host A knows to send the frame to the router and will send an ARP for the router’s ethernet address. When the router receives the frame, the IP packet is extracted and the router determines from the destination IP address whether or not the destination is on a directly connected network. If it is on a directly connected network, the router sends an ARP onto that network to resolve the ethernet address of the destination. When the ARP reply is received from the destination, the router can build an ethernet frame containing the IP packet and then send the frame to the destination. If the destination is not on a directly connected network, the router consults the routing table and determines the next router where the frame should be sent. IP unicast routing protocols are not covered in this book, but references are listed at the end of the chapter for further study.
In Figures 1-4a-c, host A wishes to send a packet to host B. Host A knows the IP address of host B but not the ethernet address of host B. The ARP process, illustrated in the figures, proceeds as follows:
1. Host A sends an ARP broadcast (see Figure 1-4a) that all hosts on the network receive, including the router.
2. Host B receives the ARP and recognizes that the IP address contained in the ARP request belongs to host B. Host B sends an ARP reply that contains the ethernet address for host B (see Figure 1-4b).
3. Host A can now encapsulate the IP packet in an ethernet frame and transmit the frame to host B (see Figure 1-4c).
a. Host A sends an ARP request for IP address 172.16.1.2.
b. Host B responds with its ethernet address.
c. Host A can now send to host B.
If host A wants to send a packet to a host on another IP subnet, then the packet must be sent to the router. Host A will have a default gateway configured that points to the router interface attached to the LAN containing host A. Because the destination IP address is on a different subnet, host A knows to send the frame to the router and will send an ARP for the router’s ethernet address. When the router receives the frame, the IP packet is extracted and the router determines from the destination IP address whether or not the destination is on a directly connected network. If it is on a directly connected network, the router sends an ARP onto that network to resolve the ethernet address of the destination. When the ARP reply is received from the destination, the router can build an ethernet frame containing the IP packet and then send the frame to the destination. If the destination is not on a directly connected network, the router consults the routing table and determines the next router where the frame should be sent. IP unicast routing protocols are not covered in this book, but references are listed at the end of the chapter for further study.
Data encapsulations
When an application such as telnet wants to send data, the data is sent to the TCP module at the transport layer and TCP then assigns a number to the local and remote telnet session, allowing TCP to determine the session where the data is to be delivered. IP either receives or delivers data to the UDP or TCP module, depending on the type of application.
Finally, an ethernet frame contains an identifier that identifies the network layer protocol it received the data from or the network layer protocol to which it should deliver the data.
To illustrate the interaction between the different layers in the OSI model, we will follow the flow of data from one host to another (see Figure 1-3). Assume we are running a telnet session between two hosts. User data is generated at the application layer and is then passed down the protocol stack to the TCP module in the transport layer. The TCP layer uses an identifier for the session, which is contained in the TCP header, and passes the TCP segment to the IP module at the network layer. IP then tags the packet as a TCP or UDP packet. When the packet is received at the data link layer, an ethernet frame is constructed with an ethernet header and trailer. The header, among other things, contains a field tagging the frame as one that carries the IP data. Finally, the frame is passed to the physical layer for transmission onto the network media.
When the ethernet frame is received by the remote host, the data link ethernet module strips off the ethernet header and trailer after determining that this frame carries IP data and passes the data to the IP module in the network layer. IP determines if the packet is a TCP or UDP packet and passes it to the appropriate module at the transport layer. Finally, TCP extracts the user data and sends it to the proper user process.
Finally, an ethernet frame contains an identifier that identifies the network layer protocol it received the data from or the network layer protocol to which it should deliver the data.
To illustrate the interaction between the different layers in the OSI model, we will follow the flow of data from one host to another (see Figure 1-3). Assume we are running a telnet session between two hosts. User data is generated at the application layer and is then passed down the protocol stack to the TCP module in the transport layer. The TCP layer uses an identifier for the session, which is contained in the TCP header, and passes the TCP segment to the IP module at the network layer. IP then tags the packet as a TCP or UDP packet. When the packet is received at the data link layer, an ethernet frame is constructed with an ethernet header and trailer. The header, among other things, contains a field tagging the frame as one that carries the IP data. Finally, the frame is passed to the physical layer for transmission onto the network media.
When the ethernet frame is received by the remote host, the data link ethernet module strips off the ethernet header and trailer after determining that this frame carries IP data and passes the data to the IP module in the network layer. IP determines if the packet is a TCP or UDP packet and passes it to the appropriate module at the transport layer. Finally, TCP extracts the user data and sends it to the proper user process.
Multiplexing and demultiplexing in the TCP/IP model
The lowest layer of the OSI model is the physical layer. The physical layer deals with the electrical and mechanical specifications of a particular transport medium and associated interfaces. Physical layer examples are 10 and 100 Mbit ethernet, synchronous and asynchronous serial links, and ATM, to name a few. The physical layer is concerned with getting bits, in an electrical or optical form, from point A to point B. The physical layer does not care about the structure or format of the data that is being transmitted or received; it is only concerned with delivering ones and zeros from the source to the destination.
The next level in the OSI model above the physical layer is the data link layer. This layer is responsibile for creating frames that contain source and destination addresses, adding error detection and possibly correction fields to the frame, and, of course, incorporating a user’s data into the frame. Protocols at the data link layer are not routable, and examples of such layers are ethernet and token ring.
The layer where a network designer spends the most time is the network layer. This layer handles routing across the Internet and is the most important layer as far as multicasting is concerned. For a protocol to be routable, the addressing scheme must include a network and a host address. The last statement is true for “normal” IP traffic, but not for multicast traffic. As we will see, multicast addresses are not in the form of network/host but represent a group address. Although a network/host address pair is not present in a multicast address, multicast traffic is routable. Examples of routable protocols are IP, IPX, AppleTalk, and DECNet.
The transport layer is used to multiplex and demultiplex data streams between upper layer application processes as seen in Figure 1-2. The three upper layers of the OSI model, application, presentation, and session, have been combined in the application layer in the TCP/IP layered model. Typically, it is more difficult to determine where a particular upper layer application should be logically placed. Networks can be designed without knowing which applications the users are going to be employing. Therefore, the specific application is not important, just the protocol that the application will be using. In fact, we will only concern ourselves with the lower four layers of the OSI and TCP/IP models.
The next level in the OSI model above the physical layer is the data link layer. This layer is responsibile for creating frames that contain source and destination addresses, adding error detection and possibly correction fields to the frame, and, of course, incorporating a user’s data into the frame. Protocols at the data link layer are not routable, and examples of such layers are ethernet and token ring.
The layer where a network designer spends the most time is the network layer. This layer handles routing across the Internet and is the most important layer as far as multicasting is concerned. For a protocol to be routable, the addressing scheme must include a network and a host address. The last statement is true for “normal” IP traffic, but not for multicast traffic. As we will see, multicast addresses are not in the form of network/host but represent a group address. Although a network/host address pair is not present in a multicast address, multicast traffic is routable. Examples of routable protocols are IP, IPX, AppleTalk, and DECNet.
The transport layer is used to multiplex and demultiplex data streams between upper layer application processes as seen in Figure 1-2. The three upper layers of the OSI model, application, presentation, and session, have been combined in the application layer in the TCP/IP layered model. Typically, it is more difficult to determine where a particular upper layer application should be logically placed. Networks can be designed without knowing which applications the users are going to be employing. Therefore, the specific application is not important, just the protocol that the application will be using. In fact, we will only concern ourselves with the lower four layers of the OSI and TCP/IP models.
TCP/IP and OSI layered network models
Before we begin our exploration of IP multicasting and multicast routing protocols, we will examine the models of communication between two or more hosts in an intranet or over the Internet. Any book bearing resemblance to a networking book should include a review of the OSI layered communication model. The communication protocols that exist at the various levels in the OSI layered model interoperate extremely well because of the adherence to a layered protocol model. The original model was developed by the OSI to provide a logical separation between the various functions of a network. This model allows for the interaction of software modules from different vendors to coexist and operate properly as long as the published standards are followed.
Subscribe to:
Posts (Atom)