|
|
|
Chapter FiveFrame Relay Network DesignFrame relay is based on a packet-switched data network. The differential of frame relay to previous packet-switched networks like X.25 is that frame relay switches a frame versus a packet. Frame relay has considerable low overhead and its speed through the network is in part to not insuring delivery of data. Frame relay as a WAN network solution grew due to the low cost for acceptable performance as compared to leased-line WAN solutions. An optimal frame relay network design is based on the following:
Main concerns for implementing a frame relay design is the ability of the design to scale to not only topology growth but to traffic growth. Components for creating a scalable frame relay network designs are:
Meeting these guidelines results in providing a scalable, high-availability and low cost frame relay network design.
Frame relay design is based on permanent virtual connections (PVCs). A PVC is identified using a Data Connection Link Identifier (DLCI) number. Multiple PVCs are possible over a single physical communication link. Using this ability, a single link can communicate with multiple locations. This function is shown in Figure 5.1 where router R1 using two PVCs communicates with two other routers over the public frame relay network. A PVC can be assigned a bandwidth. The total bandwidth of all defined PVCs can equal the actual bandwidth of the physical communication link. In a sense, frame relay acts as a time-division multiplexer (TDM) over a public network. Due to the nature of frame relay services through PVCs, hierarchical designs are more logical than physical in definition. Each PVC may be guaranteed a bandwidth parameters called committed information rate (CIR) and excessive burst limits (Be). The CIR is an agreement with the frame relay provider for a minimum throughput for the PVC. The excessive burst limit is an agreement with the frame relay provider for the available for use by the PVC over and above the PVC bandwidth to the maximum available on the physical link. These two variables greatly influence the cost and therefore the design of the frame relay network. Scalability is achieved in frame relay network design through the implementation of a hierarchy. Using a hierarchy enables incremental growth. The hierarchical approach however, must follow the three layer routing model in order for meeting high-availability, acceptable performance and low-cost requirements. These requirements can be met through careful planning of actual performance requirements at remote locations, degree of high-availability service, and minimizing the complexity of the hierarchy. Managing a hierarchical network is minimized through the partitioning of the network into smaller elements. By simplifying the network into manageable modules, troubleshooting is eased. The partitioning also provides protection against broadcast storms and routing loops. A hierarchical design inherently provides a flexible network topology allowing the inclusion of other technologies into the network design. This leads to a hybrid approach for the overall network infrastructure. While hybrid network design may enable greater service, it does make network management a bit more complex. Finally, router management in hierarchical frame relay networks is reduced due to fewer network connections based on the hierarchy. Hierarchical network design lends itself to protecting networks form broadcast and multicast traffic issues. Regional hierarchy with smaller areas enables the frame relay network to maintain overall network performance requirements. Limiting the number of routers within an area or layer minimizes the chances of traffic bottlenecks due to broadcast traffic. The network topology design chosen for implementing frame relay networks is dependent on many variables. Among these are the types of protocols supported and the actual traffic characteristics and patterns generated by applications using the network. It is recommended that an optimal frame relay network design support anywhere form a maximum of 10 to 50 PVCs per physical interface. Consider the following factors in determining the number of PVCs to support:
The topology of a frame relay network is comprised of different design formats. Each format has its advantageous and disadvantageous. The network requirements along with the considerations outlined above on the number of PVCs required in a design need to be addressed in using the various topology layouts.
A frame relay star topology is depicted in Figure 5.2. The configuration is referred to as a star due to the single connection by all remote sites to a central location. Star topologies minimize the number of PVCs and result in a low cost design. However, due to its design bandwidth at the central site becomes an issue since it becomes limited due to the number of remote locations connecting over the physical connection. Likewise, high-availability through alternate paths and rerouting of data from the remote locations is non-existent since there is only one path from the remote location to the rest of the network. An advantage to a star topology is ease of management. However, the disadvantageous of the core or hub router as a single point of failure, performance impact to the backbone due to the single core router connection, and the inability of a star topology to scale make it a poor choice for basing a foundation for the network design. A fully meshed frame relay network provides a very high degree of availability. As shown in Figure 5.4 a fully meshed network uses PVCs connecting all frame relay points on the network. Disadvantageous to using a fully meshed network is the number of PVCs required. A PVC is required for logically connecting to each router on the network. A fully meshed topology requires [n(n-1)]/2 PVCs where n is the number of routers being connected to the frame relay network. For example, a fully meshed network of five routers requires [5(5-1)]/2 which equals 10 PVCs. Although frame relay networks are non-broadcast multiaccess (NBMA) networks a router sends a broadcast over each active PVC. This replication process leads to excessive CPU and bandwidth requirements for jut routing updates, spanning tree updates and SAP updates. In small frame relay networks, a fully meshed topology is a reasonable design. The issues that make a fully meshed network for large networks a poor design are:
Merging the ease of design and management using a star topology with the high availability feature provided by a fully meshed topology results in a requirements balanced partially meshed topology. Seen in Figure 5.5 a partially meshed topology is two star topologies being supported by the remote locations. Partially meshed topologies are ideal for regional implementation. The advantageous to partially meshed networks are:
Data must flow through one of the core routers for communication between locations of a partially meshed topology without a direct PVC.
Applying the fully meshed topology to an overall hierarchy for the three layers of the routing layer model results in a design that scales and localizes traffic due to the creation of manageable segments. The modularity of the design enables the network as a whole to scale well. As shown in Figure 5.6 the hierarchy is based on the strategic connections made across the routing layer model. Though again this topology provides high redundancy and modularity, it continues to have the packet/broadcast replication problem. The balance of service to cost is also lost due to the extra number of routers, physical links and PVCs required. Managing the balance between core backbone performance and maintaining a low-cost network design results in a hybrid hierarchical frame relay network. A hybrid hierarchical network, as depicted in Figure 5.7, uses private leased lines for creating a fully meshed backbone and partially or fully meshed frame relay networks for connection to the regional network. In Figure 5.7, we see the use of an ATM core backbone feeding a leased line distribution network. The distribution layer then provides network connectivity using a partially meshed topology. This topology high-availability, great bandwidth for the backbone, network segmentation and simplified router configuration management.
Broadcasts are typically used for routing protocols to update network devices on selecting the best path between two destination on the network. Many routing protocols update their neighbors or peers on a periodic basis. Routers replicate a broadcast on to every active PVC defined on the router for transmission to he partner node at the other end of the PVC. Figure 5.8 illustrates this point. In managing the broadcasts of routing protocols, it is important to understand the time requirement for topology changes. In stable networks, the timers that manage the broadcast updates for individual routing protocols may be extended which helps router and bandwidth overhead in supporting the routing protocol updates. Another alternative is to include in the design efficient routing protocols such as EIGRP, for reducing the routing protocol broadcast updates over the frame relay network. Managing the replication of broadcasts and packets is of paramount concern. Fully meshed networks actually increase the overall cost of a network and increase the overall load on the network. Table 5.1 lists the relative traffic levels as they relate to broadcast traffic generated by routing protocols.
There are several factors affecting performance of frame relay networks. We have already discussed the affect of broadcasts on the network. Broadcasts are the primary concern for designing the bandwidth and number of PVCs necessary to designing a viable frame relay network. During the planning stage of developing the frame relay network design the following must be considered:
The frame relay provider uses several metrics to determine the billing of the frame relay connections. Therefore, it is important to fully understand the bandwidth and number of PVCs required to meet business service levels. The metrics used for determining the frame relay network configuration are: Committed burst (Bc) - the number of bits committed to accept and transmit at the CIR Excess burst (Be) - the number of bits to attempt to transmit after reaching the Bc value Committed Information Rate (CIR) - the maximum permitted traffic level for each PVC Maximum data rate (MaxR) - calculated value measured in bits per second (Bc + Be)/Bc * CIR Determination of the CIR, Bc and Be is predicated on the actual speed of the physical line. The maximum values can not extend past the maximum speed of the link. In addition, the application profiles will influence the metrics based on the type of service, transport mechanisms and usage of each application using the PVCs. The CIR is the guaranteed bandwidth the frame relay service provides for each PVC on the physical link. For example, a CIR of 19.2 Kbps on a 128 Kbps physical link commits the frame relay network to provide 19.2 Kbps throughput for the PVC between source and destination. CIR is the metric most influencing the ability to meet the service levels for the applications. Failure to properly calculate the appropriate CIR level results in poor performance and failure to meet service levels. Under estimating the CIR results in discard eligible (DE) frames. The DE bit value is set to on by a frame relay switch when the bandwidth used on the PVC begins to exceed the CIR. Frame relay switches inspect the DE bit value within the frame. If the DE bit is on, the frame may be discarded based on the switches resource constraints, network congestion and available bandwidth. Frame relay institutes a congestion protocol to protect network resources from over utilization. This protocol is termed FECN/BECN. Forward Explicit Congestion Notification (FECN) is a frame relay message used to notify a receiving device that there is a congestion problem. Backward Explicit Congestion Notification (BECN) is a frame relay message used to notify a sending device that there is a congestion problem. These messages enable the network devices to throttle the traffic onto the network. Cisco routers support the use of FECN and BECN. Support for multiple protocols over frame relay connections requires some thought on traffic management. Cisco IOS enables the use of subinterfaces on physical interfaces. This ability, diagrammed in Figure 5.9, to create virtual interfaces enables a network designer to use all the tuning, reporting and management functions of the Cisco IOS interface commands for each individual PVC. Using this feature of virtual interfaces also creates unique buffers on the output queues for each PVC versus n output buffer queue for the entire physical connection. The result is better performance and management using virtual subinterfaces.
Cisco IOS supports the transport of IBM Systems Network Architecture (SNA) protocols over frame relay using the RFC 1490/FRF.3 specification. The specification describes the encapsulation technique for transporting the SNA protocols. Cisco has applied their own algorithms for supporting enhanced features such as local acknowledgement, dynamic rerouting, SNA prioritization and PVC prioritization. Cisco routers implementing RFC 1490/FRF.3 can connect LAN attached or SDLC attached SNA resources directly to the an IBM front end processor without the use of a data center based router or any other intermediate frame relay device. The IBM front-end processor must be using Network Control Program (NCP) V7.1 or higher Boundary Network Node (BNN) functions. Using a Cisco router at the remote location enables these SNA devices to maintain their current configuration while realizing the design benefits of a frame relay network. Figure 5.10 illustrates an SNA BNN connection to a mainframe front-end processor using Cisco routers at the remote location. Locations having multiple SNA physical units (PUs) requiring connectivity may use a single PVC. This is accomplished by implementing a Service Access Point (SAP) multiplexing feature. Each SNA PU is assigned a unique SAP address, which enables the Cisco router to support multiple SNA PUs over the single PVC. RFC1490/FRF.3 enhances frame relay connectivity directly to the FEP by including the IEEE 802.5 MAC header in every frame. This specification is called Boundary Access Node (BAN). Using BAN an unlimited number of SNA, devices are supported over a single frame relay PVC. BAN eliminates the need to use SAP addresses for multiplexing the SNA connections over a single frame relay PVC. Additionally, BAN supports duplicate DLCI-MAC address mappings on the front-end processors for load balancing and redundancy. Support for BAN on the IBM front-end processor requires NCP V7.3 or higher and the Cisco IOS must be using IOS 11.1 or greater. Figure 5.11 illustrates the use of BAN connectivity. The differences between BNN and BAN are:
Cisco IOS supports the RFC 1490/FRF.3 node function at the data center router using the Frame relay access support (FRAS) host function. As shown in Figure 5.12, instead of the frame relay PVC terminating at an IBM front end processor a Cisco router is used. The Cisco IOS SNA connectivity features for connecting to the mainframe using either SDLC, LAN or channel-attachment with a Channel interface processor (CIP) or channel port adapter (CPA) are then employed for completing the SNA connection.
|
||||||||||||||||||||||||||||||||||||||||||||||
|
With any suggestions or questions please feel free to contact us | ||||||||||||||||||||||||||||||||||||||||||||||||
