Chapter 21 Backbone Network Design:

1
Chapter 21Backbone Network Design

• This chapter focuses on designing the backbone to
  interconnect the access network to the backbone.
  The topology and style of the backbone must be
  designed to be consistent with the backbone
  service and technology chosen.

2
Backbone Requirements

• Backbones provide many efficiencies not
  achievable from a meshed-access network
• Traffic consolidation
• High-bandwidth switched-services
• Rerouting, redundancy and self-healing
  architecture
• Economies of scale
• Intelligent routing and dynamic bandwidth
  resource allocation
• Flexible technologies and styles of design
• Distributed or centralized network management

pg804
3
Backbone Requirements

• As LAN interconnectivity grows in size, it is
  called an Enterprise Network.
• The Enterprise Network will either keep a matrix
  structure (SNA type of networks) or will begin to
  evolve into heirarchical subnetworks.
• As the number of point to point access trunks
  increases, the necessity for designing a backbone
  grows.
• The next slide shows the simplification of
  network design through the implementation of a
  backbone architecture.

4
Backbone Requirements
pg805
5
Backbone Requirements

• Interfaces The primary design for interfaces
  will either be access circuits or direct-user
  access.
• Primary speeds for backbone access today are
  currently
• 56 kbps
• FT1 (increments of 64 kbps)
• DS1 (1.544 Mbps)
• DS3 (44.736 Mbps)
• 100 Mbps
• 155 Mbps
• OC-3 (51.84 Mbps)
• OC-12 (155.52 Mbps)
• OC-48 (622.08 Mbps)

pg804
6
Backbone Requirements

• Protocols
• Many of the user Protocols will be transparent to
  the backbone but the backbone design may still
  have an impact upon them.
• The backbone design must be flexible enough to
  support multiple protocols and operating systems
  simultaneously.
• Backbone designs are now moving towards exerting
  more intelligence over the network and less in
  traffic handling.
• The exception to this design move is ATM and QoS.

Pg805
7
Backbone Requirements

• Protocols
• TCP/IP remains the most common backbone network
  and internetwork protocol.
• ATM encapsulates TCP/IP within its own protocol.
• The designer needs to determine whether the
  protocols in the backbone layer can be routed or
  not.
• The designer needs to know whether the protocols
  are operating at full or half-duplex.
  (Half-duplex generates more overhead)

Pg806
8
Backbone Requirements

• Protocols
• Many routing protocols such as RIP will generate
  additional overhead on the WAN while other
  protocols such as OSPF add only a marginal amount
  of overhead.
• It is important to minimizing and localizing
  routing tables in each router to reduce the
  effects of additional overhead.
• Where possible, use standard protocols for WANs.

Pg806
9
Backbone Requirements

• Architecture and Technology
• Usually, the backbone design uses the same
  technology or is further advanced than the access
  network technology.
• Backbone design should always be faster than the
  access devices.
• Historically, until recently, this has been
  reversed.
• Long-term planning is easier with the backbone
  layer than with the access layer, because of the
  possibility of migration into the network in
  layers.

Pg806
10
Backbone Requirements

• Architecture and Technology
• It is usually easier to perform capacity
  additions and technology changes at the backbone
  layer.
• Many businesses are focusing upon the design of
  their access networks and out-sourcing backbone
  services.
• Many businesses are relying more and more upon
  public-switched data services for backbone access
  to avoid costly capital investments in backbone
  equipment.

Pg807
11
Backbone Requirements

• Architecture and Technology
• One reason for this is the rapid acceleration of
  technological changes which make it financially
  unfeasible to invest heavily in any single
  backbone technology.
• The picture on the next slide illustrates this
  where the access network and backbone network
  layers are moving closer to the user as
  technology advances.

Pg807
12
Backbone Requirements
Pg807
13
Backbone Requirements

• Architecture and Technology
• Another consideration in designing backbones is
  whether to build a connection-oriented or
  connectionless service.
• A primary concern is in optimizing the packet,
  frame, or cell size to minimize the amount of
  overhead generated to guarantee the required
  quality of service

Pg808
14
Backbone Network Capacity Requirements

• Backbone capacity is typically measured by the
  amount of bandwidth going into and leaving the
  backbone, bandwidth between switches, processing
  power and port density of each switch.
• Node type is chosen based upon the amount of
  local, remote and pass-through traffic processed
  along with the service type.
• Capacity is measured by the required amount of
  ports for all access devices, trunks to
  backbones, and bandwidth on those trunk lines.

15
Backbone Network Capacity Requirements

• Backbone nodes are designed similar to access
  node design covered in the last chapter.
• Once access loading is determined, total backbone
  capacity can be determined.
• It is up to the designer to ensure the loading
  can handle both normal and single (or multiple)
  link failures.

16
Backbone Network Capacity Requirements

• Backbone Node Selection
• First, you need to determine the percentage of
  traffic that will remain on the access network
  versus passed to the backbone.
• Then determine what percentage of traffic passed
  to each backbone node goes in and back out of the
  same node.
• Finally, determine how much traffic enters a
  backbone node and leaves to go to another
  backbone node.

17
Backbone Network Capacity Requirements

• Backbone Node Selection
• The next slide illustrates a sample traffic
  pattern for a 12 node network with single trunk
  access nodes.
• 40 of user traffic remains local.
• 30 of traffic remains within the same backbone
  node.
• 30 of traffic leaves the backbone node.

18
Backbone Network Capacity Requirements
19
Backbone Network Capacity Requirements

• Backbone Node Selection
• The next slide illustrates a sample traffic
  pattern for a 12 node network with dual trunk
  access nodes.
• The same amount of traffic accesses each access
  or backbone node, however
• Only 15 of traffic transits the backbone links
  and allows for a design of fewer links to be used.

20
Backbone Network Capacity Requirements
21
Backbone Network Capacity Requirements

• Utilization, Loading Factors, and Anticipating
  Failures
• The same calculations from the last chapter can
  be utilized to calculate node and link
  utilization loading.
• Calculations for trunks into the backbone are the
  same as user ports in the last chapter.
• Calculations between backbone nodes are the same
  as trunk in the last chapter.
• Calculations will be more accurate at this layer.

22
Backbone Network Capacity Requirements

• Utilization, Loading Factors, and Anticipating
  Failures
• Loading factors should be expressed in the same
  units of measure as in the access layer packets,
  frames, or cells per second.
• A good design will accommodate easier changes to
  the utilization and loading of the backbone as
  required.
• It is also easier to increase the bandwidth or
  number of circuits at the backbone layer than at
  the access layer.

23
Backbone Network Capacity Requirements

• Utilization, Loading Factors, and Anticipating
  Failures
• Response times should not degrade over time.
• Some styles of backbone design will also provide
  for a high level or reliability during failure or
  overload conditions, providing excess capacity at
  each network node.
• Practical (and typical) design is within 125 to
  140 percent above normal load conditions.
• Anything more would be overkill and costly.

24
Backbone Network Capacity Requirements

• Total Backbone Capacity
• Total backbone capacity can be calculated in one
  of two ways.
• It can be calculated as the total capacity of the
  backbone network with a chosen number of nodes,
  or,
• It can be calculated by the total number of
  backbone nodes required, given the capacity
  requirements.
• The following slides show the 4 major types of
  traffic patterns

25
Backbone Network Capacity Requirements

• 1. Most or all traffic that enters a node leaves
  the same node and does not transit any other
  backbone node.
• T Backbone total capacity, N Number of nodes,
  c Capacity of each node
• The formula is T (N)(c)
• The next slide shows a network with 4 backbone
  nodes, 12 access nodes, each with a capacity of
  50 units per second.
• T (4)(50) 200 UPS

26
Backbone Network Capacity Requirements
27
Backbone Network Capacity Requirements

• 2. Traffic originating on a backbone node is
  transmitted symmetrically to every other backbone
  node.
• Public or broadcast networks
• T (N1)(c)/2
• The next slide shows a 4 node backbone with 12
  access nodes with a capacity of 50 units per
  second.
• T (41)(50)/2 125 UPS

28
Backbone Network Capacity Requirements
29
Backbone Network Capacity Requirements

• 3. All traffic patterns are asymmetrical and are
  divided into user classes such as
  terminal-to-host and LAN-to-LAN (IP)
  communications.
• Backbones are primarily used for switching or
  routing and link usage varies.
• T (N2)(c)/(2N-1) (refer to the previous slide)
• T (42)(50)/((2)(4)-1) 114 UPS

30
Backbone Network Capacity Requirements

• 4. Users never talk to nodes on the same backbone
  (this is a multiple backbone scenario with
  backbone nodes connected via WAN links).
• Public access type of networks.
• T (N)(c)/2
• See the next slide.
• T (4)(50)/2 100 UPS

31
Backbone Network Capacity Requirements
32
Backbone Network Capacity Requirements

• As can be seen by the previous examples, as
  traffic patterns become more distributed, the
  network capacity decreases.
• This is a result of there being more options for
  traffic to use the limited bandwidth resources.
• This represents a design challenge to the network
  designer.
• Remember to use a good network design tool to
  confirm all calculations!

33
Backbone Network Capacity Requirements

• Route Determination
• In IP , the exact route of traffic is dynamic and
  not predetermined (for the most part).
• In Frame Relay, these routes are either static or
  dynamic, and either preprogrammed (PVCs) or
  assigned dynamically (SVCs).
• The choice of routing is accomplished
  node-to-node, hop-by-hop, and is based on a
  variety of variables (hop count, cost, bandwidth,
  priority and quality of line, to name a few).

34
Backbone Network Capacity Requirements

• Route Determination
• Once route definitions have been determined,
  these should be documented and consistency should
  be maintained.
• For example, traffic prioritization.
• Most devices (and some protocols) offer some form
  of traffic prioritization by transmission
  facilities, physical paths, or options within the
  protocol.

35
Backbone Network Capacity Requirements

• Route Determination
• Do not let users control the routing on the
  backbone design. This could result in a loss of
  network control.
• Some technologies allow for routing of traffic
  around congestion such as TCP/IP.
• Other technologies like Frame Relay use FECN and
  BECN bits to notify users of congestion.
• Other technologies like ATM can route around link
  failures.

36
Backbone Network Capacity Requirements

• Future Capacity
• User requirements for bandwidth can increase
  anywhere from 25 to 150 on average per annum.
• Designers should design extra capacity into the
  backbone to support this growth.
• When adding new services, make sure this extra
  capacity is built-in and available.

37
Backbone Network Capacity Requirements

• Future Capacity
• If you design a backbone network using a higher
  level technology than at the access layer and
  with large enough pipes, the design will prove
  effective.
• One possible example of the integration and
  complexities of future network designs is
  illustrated on the next slide.

38
Backbone Network Capacity Requirements
39
Styles of Topologies

• Styles
• Network topologies can be divided into two
  distinct styles
• Those that are planned.
• Those that just grow.
• Private networks tend to take on an asymmetrical
  shape, with definable communities of users of
  interest, especially those that grow into MANs
  and WANs.
• Public networks tend to respond to user needs and
  are often designed according to good network
  design practices, such as in this book.

40
Styles of Topologies

• Styles
• It is easier to plan a backbone design and then
  build the network than it is to try to modify an
  existing meshed (messed-up) WAN network.
• Either way, the backbone network should be a
  function of the user applications, the
  access-network topology, traffic volume, and
  range and profile of connectivity (local to
  global).
• Do not restrict yourself to a single network
  technology or protocol suite.

41
Styles of Topologies

• Star
• The Star design is also known as the
  hub-and-spoke.
• There is a central node serving as the hub and
  all other nodes are connected via point-to-point
  circuits to the central node.
• All communications pass through the central hub.
• Question Is the network in the classroom of a
  Star design???

42
Styles of Topologies

• Star
• A minimum of N-1 links are required to connect
  all nodes.
• This topology is often used in a LAN hub or ATM
  switch/hub network.
• The central hub is often a multiport, scalable
  device that can handle large amounts of
  concentration, bridging, switching or routing.

43
Styles of Topologies

• Star
• This network often is limited to two hops and is
  susceptible to critical link failures when a hub
  node fails.
• A special version of the star topology is a
  distributed star. This is typically used in LANs
  that use hubs as concentrators and tie the hubs
  together.
• The next slide shows a star network while the 2nd
  slide shows a distributed star, sometimes called
  a star-wired hub.

44
Styles of Topologies
45
Styles of Topologies
46
Styles of Topologies

• Loop
• The loop backbone design is similar to the loop
  or ring topology.
• Each network node is connected to the next
  network node.
• A minimum of N links are required for N nodes.
• Often used in distributed networks where nodes
  primarily talk to local nodes or point-to-point
  communications are required over short distances.

47
Styles of Topologies
48
Styles of Topologies

• Loop
• There is (supposedly) no maximum number of hops
  across this network, but is only reliable up to a
  maximum of two link failures (and often limited
  to only one link failure).
• Capacity planning is difficult with loop
  topologies.
• Upgrades are also difficult if the traffic
  patterns are not symmetric and consistent across
  the different access nodes.
• The DQDB loop configuration is one example of
  this topology.

49
Styles of Topologies

• Meshed and Fully-Meshed (see page 150 for a
  detailed explanation)
• The number of links required for a fully meshed
  design is
• N(N-1)/2.
• The number of links drastically increases as the
  number of nodes increases.
• A fully meshed network is often highly desirable
  but very cost prohibitive and rarely required.

50
Styles of Topologies

• Daisy-Chained Access Nodes
• All network-access devices are dual-homed to two
  high-capacity backbone switches.
• This provides for high availability but wastes
  bandwidth if the processing is regional or
  distributed.
• Figure 14a shows an example of a Daisy-Chained
  network while figure 14b shows an alternative
  where each access device also acts as a switch
  through the daisy chain.
• Question What are the advantages/disadvantages
  of each?

51
Styles of Topologies

• Daisy-Chained Access Nodes
• The second design reduces the hardware
  requirements and number of links while
  maintaining the connectivity requirements.
• The distance (and delay) between nodes is reduced
  but there are potential drawbacks to this design
  such as loss of multiple node connectivity as a
  result of a single link failure.
• Careful cost, traffic and failure analysis should
  be performed before using this design due to
  added complexity and reduced reliability.

52
Styles of Topologies

• Backbone within Backbones
• There are many network designs that employ
  backbone within backbone designs in a
  hierarchical nature.
• This design has both advantages and
  disadvantages.
• The next slide shows access nodes and backbone
  nodes interconnecting between each LATA. A more
  complex but reliable configuration

53
Styles of Topologies

• Backbone within Backbones
• The next slide shows access nodes connecting to
  the level 1 backbone in each LATA and the
  backbone node connecting to the level 2 backbone.
• This is a simpler design with less hardware
  requirements but is less reliable due to the
  probability of a critical single link failure
  between the level 1 and level 2 backbone link.

54
Backbone Topology Strategies

• Structure
• There are two styles of connecting local LANs
• Hierarchical
• Ubiquitous (flat)
• WAN bottlenecks typically occur in the access
  facilities.
• Services like IP, FR, SMDS and ATM offer more
  efficient utilization of access bandwidth and
  topology alternatives not found in many private
  networks.

55
Backbone Topology Strategies

• Requirements Drive the Topology
• Always review all technologies and routing
  algorithms available and do not confine yourself
  to a single transport technology or protocol
  during the design process.
• One method is to add links that are absolutely
  required first.
• Then proceed to add more links until all possible
  links until all links are added where capacity is
  required for data flow.

56
Backbone Topology Strategies

• Requirements Drive the Topology
• Then analyze traffic flow and eliminate links and
  combine traffic over remaining links based on
  many factors such as shortest path, link cost,
  and quality facilities.
• You can use a design tool to do this.
• This is referred to shortest path.

57
Backbone Topology Strategies

• Requirements Drive the Topology (sample design
  process)
• Figure 17a shows 6 links that have been added in
  the order of the largest flow required to the
  smallest flow required.
• Figure 17b shows the selection of 1 through 5 are
  kept and 6 is deleted because it was too
  expensive not to route traffic through node B
  rather than directly from node A to D and vice
  versa.
• Figure 17c shows the final iteration where link 2
  was eliminated due to it being an analog line and
  link 5 was eliminated due to excessive distance.

58
Backbone Topology Strategies
59
Backbone Topology Strategies

• Requirements Drive the Topology
• Never loose sight of the original requirements
  during the backbone design.
• The user needs to fully understand the carriers
  access and backbone design and its potential
  effect upon user applications.
• Many networks are beginning to employ a hybrid
  technology, combining the advantages of different
  topologies but, be aware of multiple
  encapsulation schemes and their added overhead.

60
Network Management

• Network Management
• Network Management is easier to administer at the
  network level than at the access concentrator or
  user-device level.
• Network management will be discussed further in
  chapter 23.
• Some other issues involved in Network Management
  which will be discussed now include
• Network Timing
• Network Tuning

61
Network Management

• Total Network Timing
• Timing is an important aspect of each design and
  is also important between the CPE and
  network-access devices.
• External timing should be used where possible
  because internal network timing sources may not
  be synchronized between all network elements.
• The higher the transmission speed, the more
  critical timing becomes.

62
Network Management

• Total Network Timing
• Timing problems can cause line interference, data
  unit slips, data loss, interruption of service
  and general decrease in reliability of
  transmissions.
• Clock sources for timing are rated in Stratum
  levels from 1 to 5.
• Stratum 1 is the most reliable while Stratum 5 is
  the least reliable.
• Always use clock sources as reliable as possible.

63
Network Management

• Total Network Timing
• You should analyze timing sources on a regular
  basis and look for timing loops (a device that
  provides a clock source and receives back its own
  signal as a source).
• Stratum 1 examples include Basic Synchronous
  Reference Frequency (BSRF) and the DoD Loran-C
  (GPS).
• Stratum 1 assures no more than one slip per day.

64
Network Management

• Timing Levels Defined
• Timing Precision of Frame Slips
• Global Positioning System 1 x 10-12 .2 per year
• Loran-C 5 x 10-12 1.25 per year
• Stratum 1 1 x 10-11 5 per year
• Stratum 2 1.6 x 10-8 11 per day
• Stratum 3 4.6 x 10-6 132 per hour
• Stratum 4 3.2 x 10-6 15.4 per minute

65
Network Management

• Tuning the Network
• Network Tuning is one of the major issues in
  network design and should be performed at the
  same time you are designing the backbone network
  design.
• Network Tuning should continue at specific
  intervals throughout the lifetime of the network
  to ensure optimal operating efficiency.
• This includes optimizing packet, frame, and cell
  size, limiting segmentation by lower layer
  protocols, decreasing overall port-to-port
  transfer delay, and using windows for congestion.

66
Network Management

• Optimizing Packet/Frame/Cell Size
• There is a trade off between choosing large or
  small packet sizes for transmission.
• When small packet sizes are used, there is an
  increase in overhead and data throughput degrades
  but have the advantage of better response times
  and less data corruption, reducing
  retransmissions.

67
Network Management

• Optimizing Packet/Frame/Cell Size
• When large packet sizes are used, a higher
  throughput can be achieved but increases the
  probabilities of retransmissions due to delays,
  packet errors, or buffering.
• The figure on the next slide shows a bell shaped
  curve which depicts the phenomenon of small
  versus large packet size and the throughput
  achieved by selecting the ideal packet size.

68
Network Management
69
Network Management

• Optimizing Packet/Frame/Cell Size
• Packet size tuning is a balancing act (and an
  art).
• Additional factors influencing the size include
• How ling it takes to read in a packet
• Time to forward packets to the next device or
  destination
• Buffer space taken by held packets
• Packets per second dropped
• Mix of protocols to bridge/route
• The best method to achieve this is to use trend
  analysis or design tools for accuracy

70
Network Management

• Limiting Protocol Segmentation
• Try to reduce the amount of segmentation at both
  the user file-transfer level and at the access
  and backbone-technology transport level.
• When many layers of encapsulation are encountered
  across the network, packets may have to be broken
  down at each new protocol level and will decrease
  throughput.

71
Network Management

• Port to Port Data Transfer Delay
• Much of this delay and overhead depends internal
  architecture and software handling of the device.
• Many devices implement multiple ports per
  interface card, reducing this effect.
• The higher the bus speed, the faster the data
  rate between the interface board and the central
  (or distribute) processor(s).
• Most new equipment have very low port-to-port
  transfer delays.

72
Network Management

• Window Sizes
• Window sizes can be tuned at each level of some
  protocols such as X.25 packet-switched networks
  providing transmission-flow control.
• Increased window sizes provide increased
  throughput, but require more memory and buffers
  in the network hardware and software.
• This can cause more problems than it solves if
  adjusted incorrectly which can be detected
  through network analysis.

73
Network Management

• Bursting
• Most protocols are designed to allow applications
  to burst traffic above a predefined traffic
  parameter setting.
• Statistical multiplexers allow a form of
  bursting.
• Frame relay was designed to allow for multiple
  variable-bit rate users. When users are
  transmitting, they are bursting traffic across
  the line. At other times, utilization would
  remain low.
• This allows for multiplexing multiple users onto
  a single line.

74
Network Management
75
Chapter Summary

• This chapter reviewed the requirements and
  considerations that go into designing backbone
  networks. Backbone style and topology, capacity
  and future capacity as well as calculations for
  determining traffic utilization rates and traffic
  rates along specific links were discussed.