Network Design and Implementation EEB_7_876 For MSc TeCNE and EDS

Methods of Teaching and Learning : Lectures and Workshops Website: http://eent3.lsbu.ac.uk/staff/baoyb/NDI http://www.lsbu.ac.uk/bb/ Methods of Teaching and Learning : Lectures and Workshops Assessment of the Module : 2-hour written examination -- 50% Two laboratory work reports -- 50% Lecturer: Ya Bao and Perry Xiao.

Top-Down Network Design, 3rd Edition Designing and Supporting Computer Networks (CCNA) Priscilla Oppenheimer

Background Reading Networking Systems Design and Development

Teaching calendar Network Programming (Week 1 – 6) Network Design (Week 7 – 12) Week 7, 8 Identifying Your Customer’s Needs and Goals Week 8, 9 Logical Network Design Week 10 Physical Network Design Week 11 Testing, Optimizing and Documenting Week 12 Review Christmas vacation (3 weeks) Revision (week 13) Examination (week 14-15)

Part 1 Identifying Your Customer’s Needs and Goals Analyzing Business Goals and Constraints Analyzing Technical Goals and Tradeoffs Characterizing the Existing Internetwork Characterizing Network Traffic

Chapter One Analyzing Business Goals and Constraints Systematic, Top-down network design methodology Analysing your customer’s business objectives Analysing the business constrains; budgets, timeframes, workplace politics.

Network Design Good network design must recognizes customer’s requirements. Network design choices and tradeoffs must be made when designing the logic network before any physical devices are selected.

Structured Network Design Four fundamental network design goals: Scalability Availability Security Manageability Graphic: 1.1.1.2

Network requirements: How a Structured Network Design Creates a Stable, Reliable, Scalable Network Network requirements: Ease of management Fast recovery Application response time Fast troubleshooting Graphic: 1.1.1.1

Structured Network Design Core Layer: connects Distribution Layer devices Distribution Layer: interconnects smaller LANs Access Layer: provides connections for hosts and end devices Graphic: 1.1.2.1—run to end to show the three layers

Structured Network Design Steps in network design projects: Identify the network requirements Characterize the existing network (for network upgrading only) Design the network topology and solutions Testing, optimizing and documenting Graphic: 1.1.3.1

Start from the Top Application Presentation Session Transport Network Data Link Physical Layer 1 Layer 7 Layer 6 Layer 5 Layer 4 Layer 3 Layer 2

Graphic: 2.5.1.1

Systems Development Life Cycles (SDLC) Typical systems are developed and continue to exist over a period of time, often called a systems development life cycle (SDLC).

Top-Down Network Design Steps systems development life cycle (SDLC). Analyze requirements Monitor and optimize network performance Develop logical design Develop physical design Implement and test network Typical systems are developed and continue to exist over a period of time, often called a systems development life cycle (SDLC). Test, optimize, and document design

The PDIOO Network Life Cycle Plan Design Implement Operate Optimize Plan Design Retire Optimize Implement Operate

Network Design Steps Phase 1 – Analyze Requirements Today’s topic Analyze business goals and constraints Analyze technical goals and tradeoffs Characterize the existing network Characterize network traffic

Network Design Steps Phase 2 – Logical Network Design Design a network topology Design models for addressing and naming Select switching and routing protocols Develop network security strategies Develop network management strategies

Network Design Steps Phase 3 – Physical Network Design Select technologies and devices for campus networks Select technologies and devices for enterprise networks

Network Design Steps Phase 4 – Testing, Optimizing, and Documenting the Network Design Test the network design Optimize the network design Document the network design

Business Goals Increase revenue Reduce operating costs Improve communications Shorten product development cycle Expand into worldwide markets Build partnerships with other companies Offer better customer support or new customer services

Recent Business Priorities Mobility Security Resiliency (fault tolerance) Business continuity after a disaster Network projects must be prioritized based on fiscal goals Networks must offer the low delay required for real-time applications such as VoIP Resiliency means how much stress a network can handle and how quickly the network can rebound from problems, including security breaches, natural and unnatural disasters, human error, and catastrophic software or hardware failures. Some experts, including Howard Berkowitz, have a mild dislike of the word “resiliency” as it sounds too much like a stretched rubber band or a trampoline. As Berkowitz says in his excellent book, WAN Survival Guide (Wiley 2001), “I avoid designing networks that stretch too far, bounce up and down, or oscillate between normal and backup states.” So he likes “fault tolerance,” but he points out that it does not mean “immune to any conceivable threat.” Berkowitz states that, “A sufficient quantity of explosives can overcome the tolerance of any network.” :-) fiscal [ˈfɪsk(ə)l] adjective of or relating to government revenue, especially taxes

Business Constraints Budget Staffing Schedule Politics and policies

Collect Information Before the First Meeting Before meeting with the client, whether internal or external, collect some basic business-related information Such as Products produced/Services supplied Financial viability Customers, suppliers, competitors Competitive advantage

Meet With the Customer Try to get A concise statement of the goals of the project What problem are they trying to solve? How will new technology help them be more successful in their business? What must happen for the project to succeed?

Meet With the Customer Get a copy of the organization chart This will show the general structure of the organization It will suggest users to account for It will suggest geographical locations to account for

Meet With the Customer Get a copy of the security policy How does the policy affect the new design? How does the new design affect the policy? Is the policy so strict that you (the network designer) won’t be able to do your job? Start cataloging network assets that security should protect Hardware, software, applications, and data Less obvious, but still important, intellectual property, trade secrets, and a company's reputation

The Scope of the Design Project Small in scope? Allow sales people to access network via a VPN Large in scope? An entire redesign of an enterprise network Use the OSI model to clarify the scope New financial reporting application versus new routing protocol versus new data link (wireless, for example) Does the scope fit the budget, capabilities of staff and consultants, schedule?

Gather More Detailed Information Applications Now and after the project is completed Include both productivity applications and system management applications User communities Data stores Protocols Current logical and physical architecture Current performance User communities, data stores, protocols, and the current architecture and performance will be discussed in the next few chapters. This chapter focuses on business needs and applications, which should be the first area of research in a top-down network design project. Network design is iterative, however, so many topics are addressed more than once as the designer gathers more detailed information and conducts more precise planning. So, gaining a general understanding of the size and location of user communities, for example, might be appropriate at this stage of the design project, but user communities should be investigated again when characterizing network traffic.

Summary Systematic approach Focus first on business requirements and constraints, and applications Gain an understanding of the customer’s corporate structure Gain an understanding of the customer’s business style

Review Questions What are the main phases of network design per the top-down network design approach? What are the main phases of network design per the PDIOO approach? Why is it important to understand your customer’s business style? What are some typical business goals for organizations today?

Chapter Two Analyzing Technical Goals and Tradeoffs Copyright 2010 Cisco Press & Priscilla Oppenheimer

Technical Goals Scalability Availability Performance Security Manageability Usability Adaptability Affordability Your lab report should reflect some of these goals of your own designed network. Scalability: How much growth a network design must support. Availability: The amount of time a network is available to users, often expressed as a percent uptime, or as a mean time between failure (MTBF) and mean time to repair (MTTR). Availability goals can also document any monetary cost associated with network downtime. Security: Goals for protecting the organization's ability to conduct business without interference from intruders inappropriately accessing or damaging equipment, data, or operations. Specific security risks should be documented. Manageability: Goals for fault, configuration, accounting, performance, and security (FCAPS) management Usability: Goals regarding the ease with which network users can access the network and its services, including goals for simplifying user tasks related to network addressing, naming, and resource discovery. Adaptability: The ease with which a network design and implementation can adapt to network faults, changing traffic patterns, additional business or technical requirements, new business practices, and other changes. Affordability: The importance of containing the costs associated with purchasing and operating network equipment and services.

Scalability Scalability refers to the ability to grow Some technologies are more scalable Flat network designs, for example, don’t scale well Try to learn Number of sites to be added What will be needed at each of these sites How many users will be added How many more servers will be added

Availability Availability can be expressed as a percent uptime per year, month, week, day, or hour, compared to the total time in that period For example: 24/7 operation Network is up for 165 hours in the 168-hour week Availability is 98.21% Different applications may require different levels Some enterprises may want 99.999% or “Five Nines” availability

Availability Availability can also be expressed as a mean time between failure (MTBF) and mean time to repair (MTTR) Availability = MTBF/(MTBF + MTTR) For example: The network should not fail more than once every 4,000 hours (166 days) and it should be fixed within one hour 4,000/4,001 = 99.98% availability

Availability Downtime in Minutes Per Hour Per Day Per Week Per Year 99.999% .0006 .01 .10 5 99.98% .012 .29 2 105 99.95% .03 .72 5 263 99.70% availability sounds pretty good, but it could mean that the network is down for 0.18 minutes every hour. This is 11 seconds. If those 11 seconds were spread out over the hour, nobody would notice possibly. But if there were some bug, for example, that caused the network to fail for 11 seconds every hour on the hour, people would notice. Users these days are very impatient. Notice that 99.70% availability also could mean one catastrophic problem caused the network to be down for 1577 minutes all at once. That’s 26 hours. If it were on a Saturday and the network was never down for the rest of the year, that might actually be OK. So, you have to consider time frames with percent availability numbers. Consider the holy grail: 99.999% availability. That’s 5 minutes downtime per year! Be sure to explain to the customer that scheduled maintenance and upgrades don’t count! Either that or plan for a network with triple redundancy (that could be extremely expensive to implement and operate). 99.90% .06 1.44 10 526 99.70% .18 4.32 30 1577(26 H)

99.999% Availability May Require Triple Redundancy ISP 1 ISP 2 ISP 3 Enterprise In the event of failure of the primary router, the secondary becomes the primary and still has a backup. Fix the previous primary and have it become the tertiary. This helps with maintenance too. Pull out the tertiary and upgrade it. The primary still has a backup. After extensive testing, put the tertiary back in as the primary. Pull out the original primary and upgrade it. Put it back as the secondary. Finally pull out the original secondary and upgrade it. Of course, the picture brings up all sorts of other questions because it uses an ISP example. Does the customer have provider independent addressing? Does the customer have an autonomous system number? Are the ISPs really independent? Is there true circuit diversity? Are the speeds the same on the three links to the ISPs so that performance degradation is minimized during upgrades or failures? Can load balancing be used when all three routers are operational? What are the routing protocols inside the enterprise network? Can traffic really get to all three routers, regardless of failures inside the enterprise network? Can the routing protocols adjust to changes? Will traffic flow out the “closest” router? Will traffic come in from the Internet via the “closest” entry? Instructor note: The slide is not meant to be a design recommendation! It’s just a slide to get a discussion going on the ramifications of 99.999% availability. Can the customer afford this?

Server Farms Many enterprise networks provide users with Internet-accessible services, such as email and e-commerce. The availability and security of these services are crucial to the success of a business. Managing and securing numerous distributed servers at various locations within a business network is difficult. Recommended practice centralised servers in server farms. Server farms are typically located in computer rooms and data centres.

Benefits of creating a server farm Network traffic enters and leaves the server farm at a defined point. This arrangement makes it easier to secure, filter and prioritise traffic. Redundant, high-capacity links can be installed to the servers and between the server farm network and the main LAN. This configuration is more cost-effective than attempting to provide a similar level of connectivity to servers distributed throughout the network. Load balancing and failover can be provided between servers and between networking devices. The number of high-capacity switches and security devices is reduced, helping to lower the cost of providing services.

Network Performance Common performance factors include Bandwidth Throughput Bandwidth utilization Offered load Accuracy Efficiency Delay (latency) and delay variation Response time

Bandwidth Vs. Throughput Bandwidth and throughput are not the same Bandwidth is the data carrying capacity of a circuit, fixed. Usually specified in bits per second-bps Throughput is the quantity of error free data transmitted per unit of time Measured in bps, Bps, or packets per second (pps) Depend on offered load, access method and error rate Throughput < Bandwidth

Bandwidth, Throughput, Load 100 % of Capacity Throughput Actual Ideal 100 % of Capacity Offered Load

Other Factors that Affect Throughput The size of packets Inter-frame gaps between packets Packets-per-second ratings of devices that forward packets Client speed (CPU, memory, and HD access speeds) Server speed (CPU, memory, and HD access speeds) Network design MAC Protocols (ALOHA 18.4%) Distance Errors Time of day, etc., etc., etc.

Throughput Vs. Goodput Are you referring to bytes per second, regardless of whether the bytes are user data bytes or packet header bytes Or are you concerned with application-layer throughput of user bytes, sometimes called “goodput” In that case, you have to consider that bandwidth is being “wasted” by the headers in every packet

Performance (continued) Efficiency How much overhead is required to deliver an amount of data? How large can packets be? Larger better for efficiency (and goodput) But too large means too much data is lost if a packet is damaged How many packets can be sent in one bunch without an acknowledgment?

Efficiency Small Frames (Less Efficient) Large Frames (More Efficient)

Delay from the User’s Point of View Response Time A function of the application and the equipment the application is running on, not just the network Most users expect to see something on the screen in 100 to 200 milliseconds

Delay from the Engineer’s Point of View Propagation delay A signal travels in a cable at about 2/3 the speed of light in a vacuum (3×108 m/s) Transmission delay (also known as serialization delay) Time to put digital data onto a transmission line For example, it takes about 5 ms to output a 1,024 byte packet on a 1.544 Mbps T1 line Packet-switching delay Queuing delay

Queuing Delay and Bandwidth Utilization Number of packets in a queue increases exponentially as utilization increases Queue depth = utilization/(1- utilization)

Example A packet switch has 5 users, each offering packets at a rate of 10 packets per second The average length of the packets is 1,024 bits The packet switch needs to transmit this data over a 56-Kbps WAN circuit Load = 5 x 10 x 1,024 = 51,200 bps Utilization = 51,200/56,000 = 91.4% Average number of packets in queue = (0.914)/(1-0.914) = 10.63 packets

Security Focus on requirements first Detailed security planning later (Chapter 8) Identify network assets Including their value and the expected cost associated with losing them due to a security problem Analyze security risks

Manageability Fault management Configuration management Accounting management Performance management Security management

Usability Usability: the ease of use with which network users can access the network and services Networks should make users’ jobs easier Some design decisions will have a negative affect on usability: Strict security, for example

Adaptability Avoid incorporating any design elements that would make it hard to implement new technologies in the future Change can come in the form of new protocols, new business practices, new fiscal goals, new legislation A flexible design can adapt to changing traffic patterns and Quality of Service (QoS) requirements

Affordability A network should carry the maximum amount of traffic possible for a given financial cost Affordability is especially important in campus network designs WANs are expected to cost more, but costs can be reduced with the proper use of technology Quiet routing protocols, for example

Making Tradeoffs (example) Scalability 20 Availability 30 Network performance 15 Security 5 Manageability 5 Usability 5 Adaptability 5 Affordability 15 Total (must add up to 100) 100

Summary Continue to use a systematic, top-down approach Don’t select products until you understand goals for scalability, availability, performance, security, manageability, usability, adaptability, and affordability Tradeoffs are almost always necessary

Review Questions What are some typical technical goals for organizations today? How do bandwidth and throughput differ? How can one improve network efficiency? What tradeoffs may be necessary in order to improve network efficiency?

Chapter Three Characterizing the Existing Internetwork Copyright 2010 Cisco Press & Priscilla Oppenheimer

What’s the Starting Point? According to Abraham Lincoln: “If we could first know where we are and whither we are tending, we could better judge what to do and how to do it.” whither interrogative adverb to what place

Where Are We? Characterize the exiting internetwork in terms of: Its infrastructure Logical structure (modularity, hierarchy, topology) Physical structure Addressing and naming Wiring and media Architectural and environmental constraints Health

Diagram a Physical Network and Document the Existing Network Network documentation: Logical and physical diagrams Floor plans Complete lists for equipments and applications Current network configuration files inventory [ˈɪnv(ə)nt(ə)ri] (pl. -ies) a complete list of items such as property, goods in stock, or the contents of a building

Get a Network Map (physical) Medford Fast Ethernet 50 users Roseburg Fast Ethernet 30 users Frame Relay CIR = 56 Kbps DLCI = 5 Frame Relay CIR = 56 Kbps DLCI = 4 Gigabit Ethernet Grants Pass HQ Gigabit Ethernet Grants Pass HQ Fast Ethernet 75 users FEP (Front End Processor) IBM Mainframe T1 Web/FTP server Eugene Ethernet 20 users T1 Internet

Diagram a Physical Network and Document the Existing Network Identify and document the strengths and weaknesses of the existing network Focus on finding ways to overcome weaknesses Stateful firewall From Wikipedia, the free encyclopedia Jump to: navigation, search In computing, a stateful firewall (any firewall that performs stateful packet inspection (SPI) or stateful inspection) is a firewall that keeps track of the state of network connections (such as TCP streams, UDP communication) traveling across it. The firewall is programmed to distinguish legitimate packets for different types of connections. Only packets matching a known active connection will be allowed by the firewall; others will be rejected.

Characterize Addressing and Naming IP addressing for major devices, client networks, server networks, and so on Any addressing oddities, such as discontiguous subnets? Any strategies for addressing and naming? For example, sites may be named using airport codes San Francisco = SFO, Oakland = OAK In LSBU, T-tower block; K-keyworth building; B-Borough road building; L- london road building

Discontinuous Subnets – make problems for some routing protocols Area 0 Network 192.168.49.0 Router A Router B Area 1 Subnets 10.108.16.0 - 10.108.31.0 Area 2 Subnets 10.108.32.0 - 10.108.47.0

Characterize the Wiring and Media Single-mode fiber Multi-mode fiber Shielded twisted pair (STP) copper Unshielded-twisted-pair (UTP) copper Coaxial cable Microwave Laser Radio Infra-red

Architectural Constraints Make sure the following are sufficient Air conditioning Heating Ventilation Power Protection from electromagnetic interference Doors that can lock

Architectural Constraints Make sure there’s space for: Cabling conduits Patch panels Equipment racks Work areas for technicians installing and troubleshooting equipment

Check the Health of the Existing Internetwork Performance Availability Bandwidth utilization Accuracy Efficiency Response time Status of major routers, switches, and firewalls

Characterize Availability Cause of Last Major Downtime Date and Duration of Last Major Downtime Fix for Last Major Downtime MTBF MTTR Enterprise Segment 1 Segment 2 Segment n Mean time between failures (MTBF) Mean time to recovery (MTTR)

Network Utilization in Minute Intervals

Network Utilization in Hour Intervals

Bandwidth Utilization by Protocol Relative Network Utilization Absolute Network Utilization Broadcast Rate Multicast Rate Protocol 1 Protocol 2 Protocol 3 Protocol n Relative usage specifies how much bandwidth is used by the protocol in comparison to the total bandwidth currently in use on the segment. Absolute usage specifies how much bandwidth is used by the protocol in comparison to the total capacity of the segment (for example, in comparison to 100 Mbps on Fast Ethernet).

Characterize Packet Sizes

Characterize Response Time Node A Node B Node C Node D Node A Node B Node C Node D X X X X

Check the Status of Major Routers, Switches, and Firewalls show buffers show environment show interfaces show memory show processes show running-config show version Use Cisco IOS show command

Tools Protocol analyzers Multi Router Traffic Grapher (MRTG) Remote monitoring (RMON) probes Cisco Discovery Protocol (CDP) Cisco IOS NetFlow technology CiscoWorks

Summary Characterize the exiting internetwork before designing enhancements Helps you verify that a customer’s design goals are realistic Helps you locate where new equipment will go Helps you cover yourself if the new network has problems due to unresolved problems in the old network

Review Questions What factors will help you decide if the existing internetwork is in good enough shape to support new enhancements? When considering protocol behavior, what is the difference between relative network utilization and absolute network utilization? Why should you characterize the logical structure of an internetwork and not just the physical structure? What architectural and environmental factors should you consider for a new wireless installation?

Chapter Four Characterizing Network Traffic Copyright 2010 Cisco Press & Priscilla Oppenheimer

Network Traffic Factors Traffic flow Location of traffic sources and data stores Traffic load Traffic behavior Quality of Service (QoS) requirements

User Communities, a set of worker who use a particular application or set of applications. User Community Name Size of Community (Number of Users) Location(s) of Community Application(s) Used by Community

Data Stores (sinks), an area in a network where application layer data resides. Server, or any device where large quantities of data are stored. Data Store Location Application(s) Used by User Community(or Communities)

Traffic Flow, involves identifying and characterizing individual traffic flows between traffic source and stores. Destination 1 Destination 2 Destination 3 Destination MB/sec MB/sec MB/sec MB/sec Source 1 Source 2 Source 3 Source n

Library and Computing Center Business and Social Sciences Traffic Flow Example 10-Mbps Metro Ethernet to Internet 30 Library Patrons (PCs) 30 Macs and 60 PCs in Computing Center App 1 108 Kbps App 2 60 Kbps App 3 192 Kbps App 4 48 Kbps App 7 400 Kbps Total 808 Kbps Server Farm App 2 20 Kbps App 3 96 Kbps App 4 24 Kbps App 9 80 Kbps Total 220 Kbps 25 Macs 50 PCs 50 PCs Arts and Humanities Administration App 1 30 Kbps App 2 20 Kbps App 3 60 Kbps App 4 16 Kbps Total 126 Kbps App 1 48 Kbps App 2 32 Kbps App 3 96 Kbps App 4 24 Kbps App 5 300 Kbps App 6 200 Kbps App 8 1200 Kbps Total 1900 Kbps Math and Sciences 30 PCs 50 PCs Business and Social Sciences

Types of Traffic Flow Terminal/host Client/server Thin client Peer-to-peer Server/server Distributed computing

Traffic Flow for Voice over IP The flow associated with transmitting the audio voice is separate from the flows associated with call setup and teardown. The flow for transmitting the digital voice is essentially peer-to-peer. Call setup and teardown is a client/server flow A phone needs to talk to a server or phone switch that understands phone numbers, IP addresses, capabilities negotiation, and so on.

Identifying Application Impacts on Network Design File transfer and email applications: Unpredictable bandwidth usage Large packet size Centralization of file and mail servers in a secure location Redundancy to ensure reliable service Graphic: 4.2.3.2

Identifying Application Impacts on Network Design HTTP and web traffic: Network media Redundancy Security Graphic: 4.2.4.2

Network Applications Traffic Characteristics Name of Application Type of Traffic Flow Protocol(s) Used by Application User Communities That Use the Application Data Stores (Servers, Hosts, and so on) Approximate Bandwidth Requirements QoS Requirements

Traffic Load To calculate whether capacity is sufficient, you should know: The number of stations The average time that a station is idle between sending frames The time required to transmit a message once medium access is gained That level of detailed information can be hard to gather, however

Size of Objects on Networks Terminal screen: 4 Kbytes Simple e-mail: 10 Kbytes Simple web page: 50 Kbytes High-quality image: 50Mbytes Database backup: 1Gbytes or more

Traffic Behavior Broadcasts Multicasts All ones data-link layer destination address FF: FF: FF: FF: FF: FF Doesn’t necessarily use huge amounts of bandwidth But does disturb every CPU in the broadcast domain Multicasts First bit sent is a one 01:00:0C:CC:CC:CC (Cisco Discovery Protocol) Should just disturb NICs that have registered to receive it Requires multicast routing protocol on internetworks

Network Efficiency Frame size Protocol interaction Windowing and flow control Error-recovery mechanisms

QoS Requirements ATM service specifications Constant bit rate (CBR) Realtime variable bit rate (rt-VBR) Non-realtime variable bit rate (nrt-VBR) Unspecified bit rate (UBR) Available bit rate (ABR) Guaranteed frame rate (GFR)

QoS Requirements per IETF (Internet Engineering Task Force, develops and promotes Internet standards, It is an open standards organization, with no formal membership or membership requirements.) IETF integrated services working group specifications Controlled load service Provides client data flow with a QoS closely approximating the QoS that same flow would receive on an unloaded network Guaranteed service Provides firm (mathematically provable) bounds on end-to-end packet-queuing delays Internet Engineering Task Force The Internet Engineering Task Force (IETF) develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standards bodies and dealing in particular with standards of the TCP/IP and Internet protocol suite. It is an open standards organization, with no formal membership or membership requirements.

QoS Requirements per IETF IETF differentiated services working group specifications RFC 2475 IP packets can be marked with a differentiated services codepoint (DSCP) to influence queuing and packet-dropping decisions for IP datagrams on an output interface of a router

How Quality of Service is Implemented on the LAN/WAN Where QoS can be implemented to affect traffic flow: Layer 2 devices Layer 3 devices Graphic: 4.3.4.1

Document the Network Requirements of Specific Categories of Applications Estimate the volume of application traffic during the initial design phase. Document projected applications and associated hardware in a network diagram. Graphic: 4.5.1.2

Summary Continue to use a systematic, top-down approach Don’t select products until you understand network traffic in terms of: Flow Load Behavior QoS requirements

Review Questions List and describe six different types of traffic flows. What makes traffic flow in voice over IP networks challenging to characterize and plan for? Why should you be concerned about broadcast traffic? How do ATM and IETF specifications for QoS differ?

of Part 1