Note to protocol model implementers: Strive to decouple evolution of the "standard" part of a protocol model from the "nonstandard" parts. Allow the core protocol logic to reflect the RFCs, without getting bogged down in implementation details that are guaranteed to change. Build strong internal interfaces to separate the logical expression of the protocol (which can be verified and reused) from the dirty mechanical details of internal services (for instance, link state database access in OSPF).

It is very important that all model components interpret the time ticks in the same units. Therefore, when writing a protocol or network element model, use absolute time units (seconds), and translate into ticks at model instatiation.

Never hard-code time in ticks in DML nor in model code, like this (wrong!):

// Java config code fragment TCP_SLOW_INTERVAL = 500; // default, in ticks. WRONG!

but use instead this technique:

# DML fragment TCP_SLOW_INTERVAL 0.5 # default, in seconds

// Java config code fragment TCP_SLOW_INTERVAL = SSF.Net.Net.seconds(0.5);

Why? Because a user may choose another attribute value for Net.frequency then you thought.

See the DML Reference Manual for an explanation of the DML schema syntax, and the SSFNet 1.1 DML Reference for examples.

Divide DML attributes into groups:

• Attributes specific to protocol implementation, but not to a host instance, should be in the protocol's DML tuple, and read by a protocol's config() method.

  Example: TCP_SLOW_INTERVAL for SSF.OS.TCP

  Use dictionaries if there are several cases of parameter choices.

• Attributes specific for a host/router instance, that are modeler's to define, or cannot be dynamically computed at runtime, should be in host's or router's DML attributes.

Avoid using DML when it is not necessary: Use SSF.Net.Net configuration stage, and/or init() method of hosts, routers and protocols, to compute derived parameters that need not be stored in DML, such as BGP router id (min of it's interfaces IP addresses); or OSPF router type (ABR, IR, ASBR) that can be computed by examining the neighbor routers.