Module 1 - Identify Customer Needs

Section 2 - Extract New Customer Requirements

Section Objectives

• Determine the customer's requirements for new applications, protocols, number of users, peak usage hours, security, and network management.

• Diagram the flow of information for new applications.

• Isolate the customer's criteria for accepting the performance of a network.

• List some tools that will help you characterize new network traffic.

• Predict the amount of traffic and the type of traffic caused by the applications, given charts that characterize typical network traffic.

Time Required to Complete This Section

Completing This Section

1. Study the reading assignment.
2. Click on any links that you see in the reading assignment and review the information that appears.
3. Review any tables and job aids that appear in the reading assignment.
4. Review the case studies at the end of this section.
5. Complete the questions in each case study.
6. Review the answers provided by our internetworking experts.

Resources Required to Complete This Section

• Access to the World Wide Web and Cisco's Web site
• A downloaded, printed copy of this section
• Paper and pencil
• Calculator (optional)

Reading Assignment

Steps for Determining a Customer's Network Requirements

Complete the following steps to determine the customer's network requirements:

1. Identify business constraints.
 
• Document the budget and resources available for this project.
 
• Document the time line for this project.
 
• Identify any staffing requirements such as hiring or training.

 
2. Identify security requirements.
 
• Appraise security risks and determine how much security will be needed and of what type.
 
• Determine requirements for outsiders to access data.
 
• Determine the authorization and authentication requirements for corporate branch offices, mobile users, and telecommuters.
 
• Identify any requirements for authenticating routes received from access routers or other routers.
 
• Identify any requirements for host security such as physical security of hosts, user accounts, dated software, access rights on data, and so on.

 
3. Identify manageability requirements.
 
• Isolate any requirements for fault management.
 
• Isolate any requirements for accounting management.
 
• Isolate any requirements for configuration management.
 
• Isolate any requirements for performance management.
 
• Isolate any requirements for security management.

 
4. Extract application requirements.
 
• Document the names and types of new applications.
 
• Document the names and types of new protocols.
 
• Document the number of users who will use new applications and protocols.
 
• Diagram the flow of information when new applications are introduced.
 
• Identify peak hours of usage of new applications.

 
5. Characterize new network traffic.
 
• Characterize traffic load.
 
•  Characterize traffic behavior including:
 
• Broadcast/multicast behavior
• Frame size(s) supported
• Windowing and flow control
• Error recovery mechanisms
 
• Use tools such as the Netsys Enterprise/Solver Performance Tools, which are described in the Network Management section of Cisco's Product Catalog and at Netsys Bayliner.
 
• Use other tools that we discussed in Section 1, including:
 
• Cisco's NetFlow switching traffic management.
• CiscoWorks, which is described in the Network Management section of your "Small and Medium Business Solution Guide" (included in your CCDS kit).
• Protocol analyzers such as Network Associate's Sniffer network analyzer.
• The Scion software package, which was developed by Merit Network, Inc.
 
6. Identify performance requirements.
 
• Response time: The amount of time to receive a response to a request for service from the network system.
 
• Accuracy: Percentage of useful traffic that is correctly transmitted on the system, relative to total traffic, including transmission errors.
 
• Availability: Amount of time the network is operational, sometimes expressed as MTBF.
 
• Maximum network utilization: Maximum percentage of the total capacity (bandwidth) of a network segment that can be used before the network is considered "saturated."
 
• Throughput: Quantity of data successfully transferred between nodes per unit of time, usually seconds.
 
• Efficiency: Measurement of how much effort is required to produce a certain amount of data throughput.
 
• Latency (or delay): Time between a frame being ready for transmission from a node and the completion of successful transmission.

 
7. Create a customer needs specification document (optional).
 
• Record the customer's requirements and constraints, and the characteristics of the existing network.

Characterizing Network Traffic

Broadcast Behavior

Layer 2 switches forward broadcasts and multicasts, which becomes a scalability issue as flat switched networks become larger.

The network interface cards in a network station pass broadcasts and relevant multicasts to the CPU of the station. (Some NICS pass all multicasts to the CPU, even when they are not relevant, because they do not sallow you to select broadcasts and multicasts.)

The CPUs on network stations can become overwhelmed by processing broadcasts and multicasts. When investigating the effect of broadcast "radiation," Cisco's technical marketing group discovered that:

• 100 broadcasts/multicasts per second used a noticeable 2 percent of the CPU power on a Pentium 120-MHz CPU with a 3Com Fast Etherlink PCI Ethernet adapter.

• 1300 broadcasts per second used 9 percent of the CPU power.

• 3000 broadcasts per second consumed 25 percent of the CPU power.

When provisioning hardware for an internetwork design, which we will discuss in depth in Section 2 of Module 2, be sure to take into consideration the broadcast behavior of the desktop protocols. The following table shows recommendations for limiting the number of stations on a single LAN based on the desktop protocol(s) in use. The table also applies to the number of stations in a VLAN.
 

Scalability Constraints for Flat (Switched and Bridged) Networks 

Protocol	Maximum Number of Workstations
IP	500
IPX	300
AppleTalk	200
NetBIOS	200
Mixed	200

 

The numbers shown are provided as a guide. Actual station limits depend on factors such as broadcast/multicast loads, IP addressing structure constraints, inter-VLAN routing requirements, management and fault isolation constraints, and traffic flow characteristics.

Frame Size

Avoid increasing the MTU to larger than the maximum supported for the media traversed by the frames in order to avoid fragmentation and reassembly of frames. When devices such as end nodes or routers need to fragment and reassemble frames, performance degrades.

For IP, use a protocol stack that supports MTU discovery. With MTU discovery, the software can dynamically discover and use the largest frame size that will traverse the network without requiring fragmentation. If your customers use IP implementations that support MTU discovery, make sure this feature is enabled. Some implementations default to a configuration with MTU discovery disabled.

The following table presents the importance of using maximum frame sizes.
 

802.3 Efficiency Depending on Frame Size 

Data Size in Bytes	Frame Size in Bytes	Overhead	Maximum Efficiency
1492	1518 (maximum)	2.5%	97.5%
974	1000	3.8%	96.2%
474	500	7.4%	92.6%
38 (no PAD)	64 bytes (minimum)	50.0%	50.0%
1 (plus 37 bytes of PAD)	64 bytes (minimum)	98.7%	1.3%

Source: Breyer and Riley, "Switched and Fast Ethernet: How It Works and How to Use It," Ziff-Davis Press, 1995.

Windowing and Flow Control

In the IP suite, Transmission Control Protocol (TCP) supports windowing and flow control. Applications that run on top of TCP include the following:

• File Transfer Protocol (FTP): port 20 (data) and port 21 (control)

• Telnet: port 23

• Simple Mail Transfer Protocol (SMTP): port 25

• Hypertext Transfer Protocol (HTTP): port 80

• Simple Network Management Protocol (SNMP): port 161

• Domain Name System (DNS): port 53

• Trivial File Transfer Protocol (TFTP): port 69

• Remote-procedure call (RPC): port 111

• Dynamic Host Configuration Protocol (DHCP) server: port 67

• DHCP client: port 68

Error Recovery

Connectionless protocols usually do not implement error recovery. Most data link-layer and network-layer protocols are connectionless. Some transport-layer protocols, such as UDP, are connectionless.

Error recovery mechanisms for connection-oriented protocols vary. A good TCP implementation, for example, should implement an adaptive retransmission algorithm, which means that the rate of retransmissions slows when the network is congested. Using a protocol analyzer, you can determine whether your customer's protocols implement effective error recovery. In some cases, you can configure retransmission and timeout timers.

Characterizing Traffic Loads and Behavior

While reviewing these tables, remember that the true engineering solution to most questions that characterize network traffic and performance is "it depends." The data in the following charts is approximate and does not take the place of a thorough analysis of the network in question.
 

Approximate Size in MB of "Objects" Transferred across Networks

Type of Object	Size in MB
E-mail message	0.01
Spreadsheet	0.1
Computer screen	0.5
Document	1
Still image	10
Multimedia object	100
Database	1000

Source: McDysan and Spohn, "ATM: Theory and Applications," McGraw-Hill, 1995.

Note: The size of a computer screen depends on the type of screen, the number of pixels, and the number of colors. A "dumb" terminal application transfers much less data. Telnet, for example, sends each character that the user types in one packet. Responses are also very small, depending on what the user is doing.

A 3270 terminal application transfers about 4000 bytes, including characters and "attribute" bytes that define color and style.

The following table illustrates the amount of traffic overhead associated with various protocols. Understanding the traffic overhead for protocols can be a factor when choosing the best protocol for your network design.
 

Traffic Overhead for Various Protocols 

Protocol	Notes	Total Bytes
Ethernet	Preamble = 8 bytes,  Header = 14 bytes,  CRC = 4 bytes,  Interframe gap (IFG) = 12 bytes	38
802.3 with 802.2	Preamble = 8 bytes,  header = 14 bytes,  LLC = 3 or 4 bytes,  SNAP (if present) = 5 bytes,  CRC = 4 bytes,  IFG = 12 bytes for 10 Mbps or 1.2 bytes for 100 Mbps	46
802.5 with 802.2	Starting delimiter = 1 byte, header = 14 bytes, LLC = 3 or 4 bytes, SNAP (if present) = 5 bytes, CRC = 4 bytes, ending delimiter = 1 byte, frame status = 1 byte	29
FDDI with 802.2	Preamble = 8 bytes,  starting delimiter = 1 byte,  header = 13 bytes,  LLC = 3 or 4 bytes,  SNAP (if present) = 5 bytes,  CRC = 4 bytes,  ending delimiter and frame status = about 2 bytes	36
HDLC	Flags = 2 bytes,  addresses = 2 bytes,  control = 1 or 2 bytes,  CRC = 4 bytes	10
IP	With no options	20
TCP	With no options	20
IPX	Does not include NCP	30
DDP	Phase 2 (long "extended" header)	13

Traffic Caused by Workstation Initialization

The first table shows the packets that a Novell NetWare client sends when it boots. The approximate packet size is also shown. On top of the packet size, add the data link-layer overhead, such as 802.3 with 802.2, 802.5 with 802.2, on FDDI with 802.2. Network-layer and transport-layer overhead are already included in these examples. Depending on the version of NetWare being run, the packets generated might be slightly different than the ones shown here.
 

Packets for NetWare Client Initialization 

Packet	Source	Destination	Packet Size in Bytes	Number of Packets	Total Bytes
GetNearestServer	Client	Broadcast	34	1	34
GetNearestServer response	Server or router	Client	66	Depends on number of servers	66 if 1 server
Find network number	Client	Broadcast	40	1	40
Find network number response	Router	Client	40	1	40
Create connection	Client	Server	37	1	37
Create connection response	Server	Client	38	1	38
Negotiate buffer size	Client	Server	39	1	39
Negotiate buffer size response	Server	Client	40	1	40
Log out old connections	Client	Server	37	1	37
Log out response	Server	Client	38	1	38
Get server's clock	Client	Server	37	1	37
Get server's clock response	Server	Client	38	1	38
Download login.exe requests	Client	Server	50	Hundreds, depending on buffer size	Depends
Download login.exe responses	Server	Client	Depends on buffer size	Hundreds, depending on buffer size	Depends
Login	Client	Server	37	1	37
Login response	Server	Client	38	1	38

 

The following table shows the packets that an AppleTalk station sends when it boots. The approximate packet size is also shown. On top of the packet size, add data link-layer overhead. Depending on the version of Macintosh system software, the packets generated might be slightly different than the ones shown here.
 

Packets for AppleTalk Client Initialization 

Packet	Source	Destination	Packet Size in Bytes	Number of Packets	Total Bytes
AARP for ID	Client	Multicast	28	10	280
ZIPGetNetInfo	Client	Multicast	15	1	15
GetNetInfo response	Router(s)	Client	About 44	All routers respond	44 if one router
NBP broadcast request to check uniqueness of name	Client	Router	About 65	3	195
NBP forward request	Router	Other routers	Same	Same	Same
NBP lookup	Router	Multicast	Same	Same	Same
If Chooser started:
GetZoneList	Client	Router	12	1	12
GetZoneList reply	Router	Client	Depends on number and names of zones	1	Depends
NBP broadcast request for servers in zone	Client	Router	About 65	Once a second if Chooser still open; decays after 45 seconds	About 3000 if Chooser closed after 45 seconds
NBP forward request	Router	Other routers	About 65	Same	Same
NBP lookup	Router	Multicast	About 65	Same	Same
NBP reply	Server(s)	Client	About 65	Depends on number of servers	Depends
ASP open session and AFP login	Client	Server	Depends	4	About 130
ASP and AFP replies	Server	Client	Depends	2	About 90

 

Note: An AppleTalk station that has already been on a network remembers its previous network number and node ID and tries 10 times to verify that the network.node combination is unique. If the AppleTalk station has never been on a network or has moved, it sends 20 multicasts: 10 multicasts with a provisional network number and 10 multicasts with a network number supplied by a router that responded to the ZIPGetNetInfo request.

The following table shows the packets that a NetBIOS station sends when it boots. The approximate packet size is also shown. On top of the packet size, add data link-layer overhead. Depending on the version of NetBIOS, the packets might be slightly different than the ones shown here.
 

Packets for NetBIOS Client Initialization 

Packet	Source	Destination	Packet Size in Bytes	Number of Packets	Total Bytes
Check name (make sure own name is unique)	Client	Broadcast	44	6	264
Find name for each server	Client	Broadcast	44	Depends on number of servers	44 if 1 server
Find name response	Server(s)	Client	44	Depends	44 if 1 server
Session initialize for each server	Client	Server	14	Depends	14 if 1 server
Session confirm	Server	Client	14	Depends	14 if 1 server

 

The following table shows the packets that a TCP/IP station not running DHCP sends when it boots. The approximate packet size is also shown. On top of the packet size, add data link-layer overhead. Depending on the implementation of TCP/IP, the packets might be slightly different than the ones shown here.
 

Packets for Traditional TCP/IP Client Initialization 

Packet	Source	Destination	Packet Size in Bytes	Number of Packets	Total Bytes
ARP to make sure its own address is unique (optional)	Client	Broadcast	28	1	28
ARP for any servers	Client	Broadcast	28	Depends on number of servers	Depends
ARP for router	Client	Broadcast	28	1	28
ARP response	Server(s) or router	Client	28	1	28

 

The following table shows the packets that a TCP/IP station running DHCP sends when it boots. Although a DHCP client sends more packets when initializing, DHCP is still recommended. The benefits of dynamic configuration far outweigh the disadvantages of the extra traffic and extra broadcast packets. (The client and server use broadcast packets until they know each other's IP addresses.)

The approximate packet size is also shown. On top of the packet size, add data link-layer overhead. Depending on the implementation of DHCP, the packets might be slightly different than the ones shown here.
 

Packets for DHCP Client Initialization 

Packet	Source	Destination	Packet Size in Bytes	Number of Packets	Total Bytes
DHCP discover	Client	Broadcast	576	Once every few seconds until client hears from a DHCP server	Depends
DHCP offer	Server	Broadcast	328	1	328
DHCP request	Client	Broadcast	576	1	576
DHCP ACK	Server	Broadcast	328	1	328
ARP to make sure its own address is unique	Client	Broadcast	28	3	84
ARP for client	Server	Broadcast	28	1	1
ARP response	Client	Server	28	1	28
DHCP request	Client	Server	576	1	576
DHCP ACK	Server	Client	328	1	328

Case Studies

In this section, you will complete our analysis of the customer's requirements and business constraints.

Read each case study and complete the questions that follow. Keep in mind that there are potentially several correct answers to each question.

When you complete each question, you can refer to the solutions provided by our internetworking experts. The case studies and solutions will help prepare you for the Sylvan exam following the course.

In this section, you will review the following case studies:

1. CareTaker Publications, a publishing company
2. PH Network Services Corporation, a health care company
3. Pretty Paper Ltd., a European wall covering company
4. Jones, Jones, & Jones, an international law firm

Case Study: CareTaker Publications

Now that you are familiar with CareTaker Publications' requirements, answer the following questions. Refer to the readings in this section to help you characterize the network requirements.
 
     1. On a separate sheet of paper, diagram the packet flow of information for the new e-mail system.
         In the following space write down any open issues or follow-up questions regarding the e-mail system.

Case Study: PH Network Services Corporation

Now that you are familiar with PH Network Services' requirements, answer the following questions. Refer to the readings in this section to help you characterize the network requirements.
 
     1. On a separate sheet of paper, diagram the packet flow for the referral approval process.
 
     2. Identify the customer’s performance requirements.

Case Study: Pretty Paper Ltd.

Now that you are familiar with Pretty Paper Ltd.'s requirements, answer the following questions. Refer to the readings in this section to help you characterize the network requirements.
 
     1. On a separate sheet of paper, diagram the packet flow of client/server traffic for the new business
         software and traffic for the pattern design documents for film production based on the requirements
         as you understand them.

     2. Identify the customer’s performance requirements.

Case Study: Jones, Jones, & Jones

Now that you are familiar with Jones, Jones, & Jones' requirements, answer the following questions. Refer to the readings in this section to help you characterize the network requirements.
 
     1. On a separate sheet of paper, diagram the packet flow of information for the e-mail application.
 
     2. On a separate sheet of paper, diagram the packet flow of information for the CD-ROM Library
         Pack application.
 
     3. Identify the customer’s performance requirements.

If you are done with this section, click here to advance to Module 2.