In an ip network, each router is given only one unique ip address so packets can be properly routed.

Address Resolution Protocol

The IP protocol is capable of routing an IP datagram within the same IP segment (network address), or else it would need a router to route the datagram to a different IP segment (network address). The IP protocol uses the IP address specified in the destination IP field and the subnet mask to extract the destination IP network address to which the datagram must be routed. The IP protocol looks up in its routing table to determine whether the destination network is directly accessible by the node or whether it needs the router to route the datagram to the destination network. The reader needs to be reminded that the Ethernet protocol on the host node needs the MAC address of the destination node to prepare the Ethernet frame. The host node has a routing table with IP addresses mapped to Ethernet addresses, known as ARP cache. If the ARP cache does not have the MAC address mapped to its corresponding IP address entry, an ARP request is generated by the host node to discover the MAC address corresponding to its IP address. If the destination node is on the same network, this is resolved by the destination node upon its ARP reply, and the destination MAC address corresponding to destination IP address is resolved. If the datagram needs to be routed out of the network address, the IP on the host node generates an ARP request to resolve the IP address to the MAC address of the Ethernet interface on the router to which the network segment connects. In such a case, the MAC address of the router interface is used as an intermediate MAC address. Once the IP address to the MAC address is resolved, the Ethernet protocol can build the Ethernet frame next and encapsulate the IP datagram. An ARP packet is directly encapsulated (bypassing IP datagram) into an Ethernet frame, as shown in Fig. e73.6.

The destination address in the Ethernet frame is all 1s, indicating that it is a broadcast address. Fig. e73.7 illustrates the ARP packet format. Each field is described as follows:

Hardware type: 16-bit field that defines the type of the network on which ARP is running. Ethernet is given type 1

Protocol type: 16-bit field defines the protocol. For IPv4, the value of this field is 0 × 800

Hardware length: 8-bit field that defines the length of the physical address, which is 6 bytes for the Ethernet address

Protocol length: 8-bit field that defines the length of the logical address, which is 4 bytes for the IPv4 protocol

Operation: 16-bit field defining the type of packet. Two packet types are ARP request (1) and ARP reply (2)

Sender hardware address: The physical address of the sender node

Sender protocol address: The logical address of the sender node

Target hardware address: A field set to all 0s for an ARP request

Target protocol address: A field set to the IP address of the target node

Fig. e73.8 is a screen capture of an Ethernet frame using a sniffer program. Ping is executed from a node with IP address 192.168.1.3 to a node with IP address 192.168.1.4. The screen capture is divided into three panels. The upper panel displays six columns of information. Packet 6 is highlighted in the upper panel, showing that an ARP request was generated with the source address 00,045AA29675 and destination address FFFFFFFFFFFF, which is a broadcast address. Under the description column in the upper panel, the node with IP address 192.168.1.3 is broadcasting on the network to find the MAC address corresponding to IP address 192.1681.4. The Ethernet frame in the lower-right panel shows a destination address of FFFFFFFFFFFF, which is a broadcast address.

Fig. e73.9 represents the contents of the Ethernet frame and the ARP packet it encapsulates. The contents of the ARP packet displays the IP and MAC addresses of the sender's node. The target hardware address is 16 zeros and the target IP address is 192.168.1.4.

Ethernet addresses

Ethernet source and destination addresses are 6 byte patterns uniquely allocated to each hardware node or workstation. This is an important number as it is the only way hardware connected to a network can recognise other devices. Ideally, every single Ethernet interface in the world will have a unique, differently allocated address number. Do not confuse Ethernet addresses with IP addresses. Ethernet addresses are allocated to the hardware, or network card used in a machine. IP addresses are allocated to the high-level application or user that may be operating the computer.

In a typical Ethernet card, the address is stored in a flash EPROM set alongside the controller chip. On power on, or board reset, the Ethernet controller will automatically download the contents of the flash EPROM to its own registers. Ethernet addresses are allocated to hardware manufacturers in blocks, who then proceed to initialize each and every network card sold with a different number. These unique numbers are sometimes known as organizational unique identifiers (OUI). Anybody can apply for a OUI number: to obtain an official MAC/Ethernet/OUI address, download the OUI application form and cover letter from: http://standards.ieee.org/regauth/oui/forms/index.html. Alternatively, contact the IEEE Registration Authority by e-mail or by phone on +1-732-562-3813 or fax +1-732-562-1571. The cost for an OUI allocation at the time of going to press is US$ 1650.00.

For development purposes, or when used within a close private LAN, any non-conflicting set of MAC address could be chosen. However, if the network is connected to the outside world, there is the possibility of a clash with a remote address of a similar number. Fortunately, the standards allow for non-OUI generic addresses to be used (see below). Many routers are programmed to ignore these type of addresses, and therefore provide some isolation from the outside world.

Figure 5-2 shows the 6 byte address format. The significance of the special bits in the sequence is as follows.

The first bit of the address (bit 47 in the MSB first sequence) is the individual/group (IG) bit. If the IG value is zero, the address designates an individual address. If the IG value is one, the address designates a group address, generally known as a multicast. A MAC address of all ones (FFFFFFhex) designates a broadcast address; frames containing this destination address are sent to all stations on the network. The next bit is the universal/local administration bit (UL). When UL is zero, the next 22 bits correspond to the unique vendor code allocated by the IEEE to each manufacturer. For example, 00AA00hex is Intel, and 08005Ahex is IBM. The last 24 bits are the numbers each vendor allocates locally to each adapter. If the UL bit is one, the full 46 bit address is locally administered, often by the software running on the networked device. It implies that the MAC address was not allocated by the IEEE. The routing bit in source addresses indicates whether MAC-level routing information is present. This is mainly relevant for other technologies such as token ring. The bit is usually zero.

IPv4 and IPv6 Notes

The presence of the IP source and destination address in an upper layer checksum computation strikes many as a violation of the concept of protocol layer independence. (The same concern applies to NAT, discussed in Chapter 27.) In fact, a lot of TCP/IP books mention that including packet level fields in the end-to-end checksum helps assure (when the checksum is correct at the receiver) that the message has not only made its way to right port, but to the correct system.

The presence of a pseudo-header also shows how late in the development process that TCP and UDP were separated from IP. Not only that, but the transport layer and network layer (or, to give them their more intuitive names, the end-to-end layer and routing layer) have always been tightly coupled in any working network.

The use of the UDP checksum is not required for IPv4, but highly recommended. It is required in IPv6, of course. In IPv4, servers that receive client datagrams with the checksum field set are supposed to reply using the checksum, but this is not always enforced. If the IPv4 checksum field is not used, it is set to all 0 bits (recall that all 0 checksums are sent as all-1s).

2.3 PROTOCOL

The protocol specifies how to write a destination address and how to transmit a message over the network. A message is sent to the destination node via the neighboring nodes (see Figure 2.4). There are one or more processes at each node. The message is sent to the destination process. To transmit information to the destination process, the following action is required: First, information is transmitted to the neighboring node. This is performed under a data-link-level protocol. Second, information is transmitted to the destination node. This can be done under a network-level protocol. Third, information is sent to the destination process. It is done through a transport-level protocol. To transmit the information to the destination, it is necessary to establish the connection between the source process and its destination process and to disconnect when communication is over. Furthermore, it is necessary to specify the transmission method, such as duplex transmission (i.e., transmission both ways) or half-duplex transmission. This is done via a session-level protocol. A presentation-level protocol provides the code conversion for the message. An application-level protocol provides the file transfer function, job transfer function, or telnet remote access function. These protocols have been standardized, and they are called OSI standard protocol. The TCP/IP protocol is used on the Internet. The IP protocol corresponds to the OSI network–level protocol. The TCP protocol corresponds to the OSI transport–level protocol. The TCP/IP protocol is shown in Figure 2.4. The OSI protocol is presented in Figures 2.4 and 2.5. Further details of the OSI and TCP/IP protocols are described in later chapters.

Reverse-Path Forwarding

Unicast forwarding decisions are typically based on the destination address of the packet arriving at a router. The unicast routing table is organized by destination subnet and mainly set up to forward the packet toward the destination.

In multicast, the router forwards the packet away from the source to make progress along the distribution tree and prevent routing loops. The router’s multicast forwarding state runs more logically by organizing tables based on the reverse path, from the receiver back to the root of the distribution tree. This process is known as reverse-path forwarding (RPF).

The router adds a branch to a distribution tree depending on whether the request for traffic from a multicast group passes the RPF check. Every multicast packet received must pass an RPF check before it is eligible to be replicated or forwarded on any interface.

The RPF check is essential for every router’s multicast implementation. When a multicast packet is received on an interface, the router interprets the source address in the multicast IP packet as the destination address for a unicast IP packet. The source multicast address is found in the unicast routing table, and the outgoing interface is determined. If the outgoing interface found in the unicast routing table is the same as the interface that the multicast packet was received on, the packet passes the RPF check. Multicast packets that fail the RPF check are dropped because the incoming interface is not on the shortest path back to the source.

Routers can build and maintain separate tables for RPF purposes. The router must have some way to determine its RPF interface for the group, which is the interface topologically closest to the root. The distribution tree should follow the shortest-path tree topology for efficiency. The RPF check helps to construct this tree.

Access List Operation

When a packet enters a router, the destination address in the packet is compared to the routing table, and the exit interface for the packet is determined. When using access lists, before the packet can enter or exit the router there is a “stack” of filters applied to the interface in which the packet must pass through. The stack we are referring to here would be the commands you entered on your router with the access-list global configuration command. Think of each line of your access list as a filter. The following example represents a user-defined access list with three filters. A complete description on the access list syntax is given in a later section.

access-list 1 permit 192.168.10.15

access-list 1 permit 192.168.10.16

access-list 1 deny 192.168.10.17

Assuming this list is applied in the outbound direction, the packet exiting the router will be tested against each condition until a match occurs. If no match occurs on the first line, the packet moves to the second line and the matching process happens again. When a match is established, a permit or deny action, which is specified on each filter statements, will be executed. What happens if the packet ends up at the end of the stack, or last line of our access list, and a match has never occurred? There is an implicit deny all command at the end of every access list. So any packet that passes through an access list with no match is automatically dropped.You will not see this line on any access list you build, just think of it as a default line that exists at the end of your access list. In Figure 4.2, we can see the direction of a packet as it flows through the access list.

In some cases, you may want to enter the last line of the access list as a permit any statement, as shown next:

access-list 1 deny 192.168.10.15

access-list 1 deny 192.168.10.16

access-list 1 permit any.

With this line in place all packets that don’t match the first two lines will be permitted by the third line and will never reach the implicit deny all.

2.1 IP Addressing

Each IP datagram contains a Source Address and a Destination Address. The Destination Address in a given IP datagram is used to route that datagram to its destination(s). IP supports both unicast (i.e. point-to-point) and multicast (i.e. one-to-many) transmissions. Because people find it inconvenient to remember IP addresses, the Internet developed a naming system, the Domain Name System, which can be used by applications to automatically map from easily remembered names (e.g. ftp.ietf.org) to the IP address(es) corresponding with that name. The Domain Name System (DNS) is discussed in a separate section later in this chapter.

The current Internet relies on EP version 4 (IPv4), which has 32-bit addresses [76]. The IETF is developing IPv6, which has 128-bit addresses, as a proposed replacement for IPv4 [26]. The Internet layer includes not only the Internet Protocol itself, but also the Internet Control Message Protocol (ICMP), which provides network control messages essential for proper operation of the global Internet [70].

Unicast applications that require end-to-end reliability use the Transmission Control Protocol (TCP) at the transport-layer [71]. Other applications, including multicast applications, typically use the User Datagram Protocol (UDP) at the transport layer [68]. UDP does not provide reliability, but is capable of working well with IP multicasting.

7.4.2 Multicycle Control

As in the single-cycle processor, the control unit computes the control signals based on the opcode and funct fields of the instruction, Instr31:26 and Instr5:0. Figure 7.27 shows the entire multicycle MIPS processor with the control unit attached to the datapath. The datapath is shown in black, and the control unit is shown in blue.

As in the single-cycle processor, the control unit is partitioned into a main controller and an ALU decoder, as shown in Figure 7.28. The ALU decoder is unchanged and follows the truth table of Table 7.2. Now, however, the main controller is an FSM that applies the proper control signals on the proper cycles or steps. The sequence of control signals depends on the instruction being executed. In the remainder of this section, we will develop the FSM state transition diagram for the main controller.

The main controller produces multiplexer select and register enable signals for the datapath. The select signals are MemtoReg, RegDst, IorD, PCSrc, ALUSrcB, and ALUSrcA. The enable signals are IRWrite, MemWrite, PCWrite, Branch, and RegWrite.

To keep the following state transition diagrams readable, only the relevant control signals are listed. Select signals are listed only when their value matters; otherwise, they are don't cares. Enable signals are listed only when they are asserted; otherwise, they are 0.

The first step for any instruction is to fetch the instruction from memory at the address held in the PC. The FSM enters this state on reset. To read memory, IorD = 0, so the address is taken from the PC. IRWrite is asserted to write the instruction into the instruction register, IR. Meanwhile, the PC should be incremented by 4 to point to the next instruction. Because the ALU is not being used for anything else, the processor can use it to compute PC + 4 at the same time that it fetches the instruction. ALUSrcA = 0, so SrcA comes from the PC. ALUSrcB = 01, so SrcB is the constant 4. ALUOp = 00, so the ALU decoder produces ALUControl = 010 to make the ALU add. To update the PC with this new value, PCSrc = 0, and PCWrite is asserted. These control signals are shown in Figure 7.29. The data flow on this step is shown in Figure 7.30, with the instruction fetch shown using the dashed blue line and the PC increment shown using the dashed gray line.

The next step is to read the register file and decode the instruction. The register file always reads the two sources specified by the rs and rt fields of the instruction. Meanwhile, the immediate is sign-extended. Decoding involves examining the opcode of the instruction to determine what to do next. No control signals are necessary to decode the instruction, but the FSM must wait 1 cycle for the reading and decoding to complete, as shown in Figure 7.31. The new state is highlighted in blue. The data flow is shown in Figure 7.32.

Now the FSM proceeds to one of several possible states, depending on the opcode. If the instruction is a memory load or store (lw or sw), the multicycle processor computes the address by adding the base address to the sign-extended immediate. This requires ALUSrcA = 1 to select register A and ALUSrcB = 10 to select SignImm. ALUOp = 00, so the ALU adds. The effective address is stored in the ALUOut register for use on the next step. This FSM step is shown in Figure 7.33, and the data flow is shown in Figure 7.34.

If the instruction is lw, the multicycle processor must next read data from memory and write it to the register file. These two steps are shown in Figure 7.35. To read from memory, IorD = 1 to select the memory address that was just computed and saved in ALUOut. This address in memory is read and saved in the Data register during step S3. On the next step, S4, Data is written to the register file. MemtoReg = 1 to select Data, and RegDst = 0 to pull the destination register from the rt field of the instruction. RegWrite is asserted to perform the write, completing the lw instruction. Finally, the FSM returns to the initial state, S0, to fetch the next instruction. For these and subsequent steps, try to visualize the data flow on your own.

From state S2, if the instruction is sw, the data read from the second port of the register file is simply written to memory. In state S3, IorD = 1 to select the address computed in S2 and saved in ALUOut. MemWrite is asserted to write the memory. Again, the FSM returns to S0 to fetch the next instruction. The added step is shown in Figure 7.36.

If the opcode indicates an R-type instruction, the multicycle processor must calculate the result using the ALU and write that result to the register file. Figure 7.37 shows these two steps. In S6, the instruction is executed by selecting the A and B registers (ALUSrcA = 1, ALUSrcB = 00) and performing the ALU operation indicated by the funct field of the instruction. ALUOp = 10 for all R-type instructions. The ALUResult is stored in ALUOut. In S7, ALUOut is written to the register file, RegDst = 1, because the destination register is specified in the rd field of the instruction. MemtoReg = 0 because the write data, WD3, comes from ALUOut. RegWrite is asserted to write the register file.

For a beq instruction, the processor must calculate the destination address and compare the two source registers to determine whether the branch should be taken. This requires two uses of the ALU and hence might seem to demand two new states. Notice, however, that the ALU was not used during S1 when the registers were being read. The processor might as well use the ALU at that time to compute the destination address by adding the incremented PC, PC + 4, to SignImm × 4, as shown in Figure 7.38 (see page 404). ALUSrcA = 0 to select the incremented PC, ALUSrcB = 11 to select SignImm × 4, and ALUOp = 00 to add. The destination address is stored in ALUOut. If the instruction is not beq, the computed address will not be used in subsequent cycles, but its computation was harmless. In S8, the processor compares the two registers by subtracting them and checking to determine whether the result is 0. If it is, the processor branches to the address that was just computed. ALUSrcA = 1 to select register A; ALUSrcB = 00 to select register B; ALUOp = 01 to subtract; PCSrc = 1 to take the destination address from ALUOut, and Branch = 1 to update the PC with this address if the ALU result is 0.2

Putting these steps together, Figure 7.39 shows the complete main controller state transition diagram for the multicycle processor (see page 405). Converting it to hardware is a straightforward but tedious task using the techniques of Chapter 3. Better yet, the FSM can be coded in an HDL and synthesized using the techniques of Chapter 4.

Destination IP and Destination Port

The translation used for ports is defined along with the destination address. When you must perform a one-to-many NAT, where the destination address is translated to different ports, you must link the VIP to a firewall rule.

// create destination NAT IP and port forwarding (VIP)

config firewall vip

 edit <name of vip>

  set type static-nat

  set portforward enable

  set extintf <inbound external interface name>

  set extip <inbound IP address>

  set mappedip <destination IP address>

  set extport <port number>

  set mappedport <port number>

  set protocol <tcp | udp | sctp>

 next

end

// tie VIP to firewall rule

config firewall policy

 edit <rule number>

  ….

  set dstaddr <name of vip>

  ….

 next

end

The following settings provide the destination port translation:

“set portforward enable” turns on the port forwarding for the VIP definition. Therefore, the following settings are also required:

“set extport <port number>” defines the destination port to be translated. Each port/extip address combination must be unique.

“set mappedport <port number>” defines the translated destination port. This port must also be unique in combination with the extip address.

“set protocol <tcp | udp | sctp>” defines the protocol used for the port mapping.