NetRule 4.2 provides more detailed modeling of ATM Quality of Service (QOS). NetRule now includes
The release also enhances the modeling of Frame Relay and includes significant improvements to the data model and user interface.
PVCs are now represented by links, rather than by jobs. This lets you define the performance and routing metrics for a PVC, and it sends the actual traffic over the physical lines that carry the PVC. You can easily assign static routes to PVCs, and the display of PVC links on the diagram can be toggled on or off. New reports show how PVCs are routed and the PVC allocations to each physical link.
The Link object has been redesigned so that it connects directly between devices without the need for surrogates to convey the connection across different subnets. This makes it easier to draw the models and see the connectivity. The line width and color is set by the link protocol, and the link results are now reported separately from the node results.
The new Node Profile object supports more detailed definition of routers, switches, and gateways. This includes the number of processors, the forwarding rate per processor, the number of busses or switch bars, and the backplane bandwidth. Also, message traffic can now be originated and terminated by nodes as well as by computers. The link protocol is no longer used to define nodes.
A new Interface object replaces the “routing” object. The interface defines the routing metrics and queuing that occurs at the nodes at each end of a link. An interface can also define a PVC or an ELAN node. Remember that the interfaces are stored with the link, not with the node (except in the case of ELAN).
Some of the other major improvements to the user interface include:
The main differences are with connecting devices, and with PVCs.
In previous releases, you could connect two devices directly, without a link. If you used a link, you had to place the link and connect it to each device. You could also connect links to links, or have more or less than two connections to a link. The concept of “A” and “B” connections was used to keep track of multiple connections.
Now, all connections are by links, and each link connects exactly two devices. To enforce this, links are only created as you connect two devices, and they always remain connected to two devices. This is explained in help/index/connectingYou should read this and try everything it mentions.
In previous releases, an ATM network was bounded by “SAR” nodes, and the PVC bandwidth was allocated by JobsIn this release, all links that carry ATM PVCs or ELAN traffic are set as “ATM” links, and PVCs are defined as links of type “ATM PVC.” So, instead of defining a job that generates T1 traffic, you connect an ATM PVC link between the devices that terminate the T1 PVC, and configure the PVC link for the appropriate rate and QoS. Defining a PVC does not cause any traffic to actually flow over the links, but the PVC allocations are reported by linkSee atm.net for an example, and read help/index/pvc.
In previous releases, ATM ELAN traffic was defined as jobs that found their way thru the ATM network. In this release, you can attach an ELAN Interface to any node, and NetRule will route IP traffic thru the ATM network between the ELAN interfacesThe actual traffic is still defined via jobs.
When you define an ATM link protocol, fields are added for the CBR, VBR, and UBR routing metricsWhen you define an ATM PVC link protocol, fields are added for the Sustainable Cell Rate, Peak Cell Rate, and burst tolerance.
A Frame Relay network is defined along the same lines as the ATM network, described above, except that the Frame Relay links use only one routing metric, the PVCs use Committed Information Rate, Committed Burst, and Excess Burst, and there is no ELAN.
Files from NetRule 4.0 and 4.1 (i.e., file formats v8 and v9) are automatically converted upon opening by 4.2 (file format v10). Here are some special cases that require explanation or your action:
PVCs - If your model included PVCs, you will be warned to manually edit the model to reflect the new representation.
Link Count - Release 4.2 automatically sets the count of a link to be the maximum count of its ends. For example, if a computer with a count of 20 is connected to a switch with a count of 1, the connection is assumed to be via 20 links. Therefore, if the link count in a previous version does not equal the maximum count of its ends, you will be warned that the link count changed in the new model. If you want to retain the old count, such as a case of 3 T1 links between two routers, you will have to edit the model to replicate the links.
Links in Subnets - Release 4.2 places links only in subnets necessary to complete the connection between the terminating devices. So, if a link is in a subnet and is connected to devices outside the subnet, the link will be moved out of the subnet during conversion, possibly leaving the subnet empty.
Item Position - Previous versions recorded the position of the upper left corner of each iconRelease 4.2 uses the center of the icon, so icons will shift position slightly during import.
Link (was Node) Results “Delay/Relay” - Release 4.2 includes the delay from the node that the link is fromPrevious releases did not, so this value will be different.
Node Results “Delay/Relay” - Release 4.2 shows the average delay for all packetsPrevious releases showed the average delay for the first packet in a message.
Job Costs - Release 4.2 includes the user cost in the computer profile, not the user profile (which has been eliminated). If your old model included computers that used the same computer profile but user profiles with different costs, the new computer profile will only include one of the user costs.
Link Protocol “Adj Packet OH” - If the link Protocol was on a node, this field is not included in the Node Profile, so if the value is nonzero you must edit your model so the “Adj Packet OH” value is used via a link.
Background jobs on Nodes - In Release 4.2 a node is assigned background load via its attached linksIf you convert an older version that has a node background job, the job will not cause any load.
There are still cases where a panel will fail to refresh, and will remain partially drawnIf this occurs, use the window controls provided by your operating system to force the window to change size.
Java 1.2 and 1.3 still have some problems with printing. Text prints ok, but on some printers, in some cases, the images do not drawTo work around this problem, try a different printer or use a screen snapshot utility to capture the window or panel of interest, and print from that.
Do
not use Java 1.4. It handles some of
the same GUI events differently. NetRule has not yet been tested to identify and adjust for the
differences in behavior, so some of the displays are not updated as needed.
NetRule | About Us | Other Products | Services | Contact Us