The Model Object

What is the model object?

The model object has two main functions:

  • It holds all the objects that represent the network (interfaces, nodes, demands, RSVPs, etc)
  • It controls the mechanics of how each object interacts with others

A network model requires these primitive objects to create a simulation and higher-level objects:

  • Interfaces
  • Nodes
  • Demands
  • RSVP LSPs (only required if network has RSVP LSPs)

From these primitives, the model can construct higher-level objects such as:

  • Circuits
  • Shared Risk Link Groups (SRLGs)
  • Paths for demands and LSPs
  • etc

The model produces a simulation of the network behavior by applying the traffic demand objects to the network topology, routing the traffic demands across the topology as a real network would. The model produces a simulation when its update_simulation() method is called.

Model Type Subclasses

There are two network model subclasses: FlexModel and PerformanceModel.

In general, the FlexModel can accommodate more topology variations, but at the price of a slightly longer convergence time while the PerformanceModel can only handle simpler network architectures, but with the benefit of better convergence time.

All model classes support:

  • IGP routing
  • RSVP LSPs carrying traffic demands that have matching source and destination as the RSVP LSPs
  • RSVP auto-bandwidth or fixed bandwidth
  • RSVP LSP manual metrics

The PerformanceModel class allows for:

  • Single circuits between 2 Nodes
  • Error messages if it detects use of IGP shortcuts or multiple Circuits between 2 Nodes

The FlexModel class allows for:

  • Multiple Circuits between 2 Nodes
  • RSVP LSP IGP shortcuts, whereby LSPs can carry traffic demands downstream, even if the demand does not have matching source and destination as the LSP

How do I know the simulations work correctly?

There are many safeguards in place to ensure the simulation’s mechanics are correct:

  • Multiple functional tests in the CI/CD pipeline check for the expected mechanics and results for each routing method (ECMP, single path, RSVP, RSVP resignaling, etc) and other features in various topology scenarios:
    • If any of these tests fail, the build will fail and the bad code will not make it into production
      • This helps ensure that functionality works as expected and that new features and fixes don’t break prior functionality
    • There are over 300 unit and functional tests in the pyNTM CI/CD pipeline
    • There are dozens of topology-specific functional tests in the pyNTM CI/CD pipeline that ensure the simulation works properly for different topologies, and more are added for each new feature
  • The model object has internal checks that happen automatically during the update_simulation() execution:
    • Flagging interfaces that are not part of a circuit
    • Flagging if an interface’s RSVP reserved bandwidth is greater than the interface’s capacity
    • Verifying that each interface’s RSVP reserved bandwidth matches the sum of the reserved bandwidth for the LSPs egressing the interface
    • Checks that the interface names on each node are unique
    • Validates that the capacities of each of the component interfaces in a circuit match
    • Validates that each node in an SRLG has the SRLG in the node’s srlgs set
    • No duplicate node names are present in the topology

The PerformanceModel subclass also verifies that

  • IGP shortcuts are not enabled for nodes
  • There is no more than a single circuit (edge) between any two nodes

Note that there are more checks involving RSVP than IGP/ECMP routing because there are more mechanics involved when RSVP is running, whereas the straight IGP/ECMP routing is much simpler.

If any of these checks fails, update_simulation() will throw an error with debug info.