Top-down network design ,chapter 4 ,characterizing the network Traffic.

1. Copyright 2010 Cisco Press & Priscilla Oppenheimer
1

2.  Data source: area in a network where application layer data resides.
2

3.  Traffic flow
 Location of traffic sources and data stores
 Traffic load
 Traffic behavior
 Quality of Service (QoS) requirements
3

4.  Characterize the behavior of existing networks.
 Plan for network development and expansion.
 Quantify network performance.
 Verify the quality of network service.
 ■ Ascribe network usage to users and applications.
 to measure the number of megabytes per second (MBps) between communicating
entities. To characterize the size, of a flow, use a protocol analyzer or network
management system
4

5. User
Community
Name
Size of
Community
(Number of
Users)
Location(s) of
Community
Application(s)
Used by
Community
5

6. Data Store Location Application(s) Used by User
Community(or
Communities)
6

7. Destination 1 Destination 2 Destination 3 Destination MB/sec MB/sec
MB/sec MB/sec
Source 1
Source 2
Source 3
Source n
7

8. Administration
Business and
Social Sciences
Math and
Sciences
50 PCs 25 Macs
50 PCs
50 PCs30 PCs
30 Library Patrons (PCs)
30 Macs and 60 PCs in
Computing Center
Library and 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
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
App 1 30 Kbps
App 2 20 Kbps
App 3 60 Kbps
App 4 16 Kbps
Total 126 Kbps
App 2 20 Kbps
App 3 96 Kbps
App 4 24 Kbps
App 9 80 Kbps
Total 220 Kbps
Arts and
Humanities
Server Farm
10-Mbps Metro
Ethernet to Internet
8

9.  Terminal/host: Terminal/host traffic is usually asymmetric. The terminal sends a
few characters and the host sends many characters. Telnet is an example of an
application that generates terminal/host traffic.
 Client/server
 Thin client
 Peer-to-peer
 Server/server
 Distributed computing
9

10. 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.
10

11.  The audio voice flow between two IP endpoints is carried by the Real-Time
Transport Protocol (RTP), which is a connectionless protocol that runs on top of
UDP.
 The main call setup, teardown, and control protocols in an IP network are H.323,
the Cisco Skinny Client Control Protocol (SCCP), Simple Gateway Control
Protocol (SGCP), Media Gateway Control Protocol (MGCP), and Session Initiation
Protocol (SIP).
 These signaling protocols run between an IP endpoint and a voice-enabled server
and follow the client/server paradigm.
11

12.  Private branch exchanges (PBX) and circuit switching, and modern VoIP
networks, which use packet switching, must handle two fundamental functions:
call control and call switching.
 Call Control: handles call setup and teardown, addressing and routing, and
informational and supplementary services.
 A fundamental job of call control is to compare the digits dialed by the user
making a call to configured number patterns to determine how to route a call.
 Call switching handles the actual switching of calls. In traditional voice networks,
when a call is placed, a PBX connects the calling phone via a so-called line-side
interface to another phone’s line-side interface.
 If the call is destined for the public switched telephone network (PSTN), the call
switching function connects the line-side interface with the trunk-side interface.
 May have different path from that used by the call control packets
12

13. 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
13

14.  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
14

15.  research application-usage patterns, idle times between packets and sessions,
frame sizes, and other traffic behavioral patterns for application and system
protocols.
 Another approach to avoiding bottlenecks is simply to throw large amounts of
bandwidth at the problem (also known as overprovisioning).
15

16.  identify user communities, the number of users in the communities, and the
applications the users employ.
 To predict the aggregate bandwidth requirement for all users of an application
document the following information:
 The frequency of application sessions (number of sessions per day, week, month, or
whatever time period is appropriate)
 The length of an average application session
 The number of simultaneous users of an application
16

17. If it is not practical to research these details, you can
make some assumptions:
 The number of users of an application equals the number of
simultaneous users.
 All applications are used all the time, so that your bandwidth
calculation is a worst case (peak) estimate.
 Each user opens just one session, and that session lasts all day
until the user shuts down the application at the end of the day
17

18.  research the size of data objects:
 Sent by applications
 The overhead caused by protocol layers
 Any additional load caused by application initialization. (Some applications send much
more traffic during initialization than during steady-state operation.)
 hard to accurately estimate the average size of data objects that users transfer to
each other and to servers; it depends
 it’s difficult to make any generalizations about the average size of objects sent on a
network.
 which protocols an application uses
18

19. 19

20.  Terminal screen: 4 Kbytes
 Simple e-mail: 10 Kbytes
 Simple web page: 50 Kbytes
 High-quality image: 50,000 Kbytes
 Database backup: 1,000,000 Kbytes or more
20

21.  Address Resolution Protocol (ARP)
 ■ Dynamic Host Configuration Protocol (DHCP)
 ■ Internet Control Message Protocol (ICMP), version 4 and 6
 ■ Internet Group Management Protocol (IGMP), version 4 and 6
 ■ Domain Name System (DNS)
 ■ Multicast DNS (mDNS)
 ■ NetBIOS name queries
 ■ Network Time Protocol (NTP)
 ■ Simple Service Discovery Protocol (SSDP)
 ■ Service Location Protocol (SLP)
 ■ Simple Network Management Protocol (SNMP)
21

22.  Router with large-distance vector routing table uses significant amount of WAN
bandwidth
 RIP
 Each route in the packet uses 20 bytes
 25 routes per packet
 Sends one or more 532-byte packets every 30 seconds depending on the size of the
routing table.
 Open Shortest Path First (OSPF) and Enhanced Interior Gateway Routing
Protocol (EIGRP), use little bandwidth.
22

23.  Broadcasts
 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
23

24.  Scalability problem
 Use of routers
 Use of VLANs
 Too many broadcast frames can overwhelm end stations, switches, and routers.
 broadcast radiation: to describe the effect of broadcasts spreading from the sender
to all other devices in a broadcast domain.
 Broadcast radiation can degrade performance at network endpoints
24

25.  Efficiency refers to whether applications and protocols use bandwidth effectively
 Frame size
 use the largest possible maximum transmission unit (MTU).
 MTU can be configured for some applications
 avoid fragmentation and reassembly of frames in IP environments; degrades
performance
 MTU discovery
 Protocol interaction
 Windowing and flow control
 Send window
 Receive window
 CPU power and memory
 Some IP-based applications run on top of UDP, not TCP; no flow control, no handling
 Ping pong protocols
 Error-recovery mechanisms
 Retransmission without ack.
 SAck
25

26.  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)
26

27.  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
27

28.  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
28

29.  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
29

30. 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?
30