MIMIC® Online Documentation

<< Previous Section    Next Section >>

MIMIC Cable Modem Simulator

  1. Table of Contents

    2. Cable Modems

  2. Overview

    3. MIMIC Cable Modem Simulator is designed to simulate cable modem installations from an OSS standpoint which are DOCSIS (Data-over-Cable Service Interface Specification) compliant and optionally support PacketCable specifications from CableLabs.

    A DOCSIS compliant cable modem is ready for data communications between an end-user and the service-provider. The DOCSIS standards define a set of standard protocols for startup initialialization as well as for steady state monitoring of the cable modem. These standards consists of various IP based protocol components which are needed to interact with the Operations Support System (OSS) at the service-provider's end. The following components can be simulated using MIMIC to approximate a cable modem end device :

    1. SNMP agent [see SP-OSSIv1.1-I02-000714 : Section 2]: cable modem units are required to support version 1 and 3 of this widely popular network management protocol in accordance with RFC-1157 and RFC-2570ff. SNMP is used for variety of things like usage and performance monitoring, billing, fault detection and analysis, etc.

    2. DHCP client [see SP-RFIv1.1-I05-000714 : Section 9.2.6, Appendix D ]: cable modems are required to dynamically obtain their IP Address from the service-provider's OSS center in accordance with RFC-2131. MIMIC can also act as a DHCP relay.

    3. TFTP client [see SP-RFIv1.1-I05-000714 : Section 9.2.8, Appendix C & D ]: cable modems are required to dynamically download their configuration information from the service-provider's OSS center in accordance with RFC-1350 and RFC-2349.

    4. ToD client [see SP-RFIv1.1-I05-000714 : Section 9.2.7 ]: cable modems are required to get the current Time of the day from the service-provider's OSS center in accordance with RFC-868.
    Back to Top

  3. Implementation

    4. Depending on the user's requirements, there are two basic implementation strategies for creating CM and CMTS simulations with MIMIC. In the first case, the devices are running in a steady-state and need only to respond to SNMP stimulus from a manager or managers. This is the simpler of the cases; a recording of a live device can be used as is. The only configuration which should be necessary will consist of setting up the SNMP access if SNMPv3 is in use. In the case of some DOCSIS 1.0 devices, even this will not be necessary, assuming the default community string access is acceptable.

    In the second case, the CM startup sequence is of interest. This will include receiving an IP address via DHCP, downloading one or more configuration files via TFTP, and syncing the device time through use of the ToD protocol, and sending traps or informs to signal successful device initialization. Additionally, implementation-dependent factors may require SNMPv3 initialization via Diffie-Hellman (DH) key exchange, Kerberos ticketing, or other steps. These considerations are examined in more detail below.

    In either case, the first required step is to create a device simulation. The methods used to do this are outlined in the MIMIC Quick Start Guide. The basic choices are either to record a live device that is attached to the network using the MIMIC Recorder, to create a simulation from an SNMP walkfile using Simulation->Record File..., or to build the simulation using the MIMIC Simulation Wizard. The Simulation Wizard allows the user to specify which MIBs the device will contain, optionally to load some object values by including a walkfile, and either to enter the rest manually or to use default values. Users can alternatively use a preconfigured MIMIC simulation provided by Gambit or a colleague who uses MIMIC. A sample generic DOCSIS 1.0 CM simulation with the associated scripts is available upon request.

    After a simulation has been created, it may be added to the simulation in the GUI as an agent instance using the MIMICView Edit->Add->Agent menu option. For the first case, the agent is now ready for use. If SNMPv3 is to be utilized, this can be specified during the add agent dialog by checking the associated checkbox on the tool's Advanced tab. Other desired configuration parameters for SNMPv3 may include edits to the configuration files v3usm.conf and v3vacm.conf to enter desired access modifications. These files are contained in the config directory of the MIMIC installation area. The comments in the file give usage information.

    This document provides an overview of the process of creating and running CableModem simulations in MIMIC. Simulations of CMTSs are similar, but do not require the same initialization as CM's do to be authentic in detail. Many of the same device MIBs are used. Consideration of many detailed subjects, such as providing unique hardware addresses for use in the DHCP request have been omitted in the interest of conciseness. Customers with support agreements are invited to direct further questions to support@gambitcomm.com.

    Back to Top

  4. Installation

    5. A specific MIMIC licensing option, the Cable Modem license, allows access to the protocol modules required to simulate a DOCSIS-compliant or PacketCable-compliant cable modem or CMTS. They are currently

    Protocol module installation is required prior to first-time use of the cable modem features. This consists in copying the dynamic library from the bin/dynamic/optional directory to the bin/dynamic directory. Please consult the Installation section of each of the Protocol Module Guides for details.

    The protocol-specific modules for DHCP, TOD, and TFTP can be enabled for an agent simulation via check boxes found on the Advanced tab of the Edit->Configure dialog.

    For the protocol-specific modules to work, appropriately configured servers (DHCP server, TFTP server, ToD server) to support these functions are assumed. For example, the DHCP offers returned from the DHCP server are required to contain properly formatted information required for device initialization.

    Back to Top

  5. MIBs

    6. MIMIC ships with the DOCSIS RFC mibs pre-compiled. Other MIBs, for example the MCNS and BPIPLUS mibs, have not yet attained RFC status, and are not shipped. These can be downloaded from the IETF draft standards page and compiled as needed.

    Back to Top

  6. Actions

    7. For the simulation to initialize properly according to DOCSIS specifications, an agent startup action script must be created and copied into the simulation directory for the agent. This script should be written to accomplish tasks related to device initialization which are required at startup.

    One task will be to parse the DHCP offer for TFTP server and initialization file.

    This data will then be used to launch a TFTP session. Other implementation-specific requirements can also be addressed.

    Additionally, a TFTP completion script is required parse the configuration file downloaded, set the appropriate mib values, and to send configuration informs/traps once the simulation has completed initialization. This can be copied into the scripts directly and launched from the start.mtcl script.

    Back to Top

  7. Key Exchange

    8. MIMIC implements a set of commands for Diffie-Helman key generation and PBKDF2 to support Diffie-Helman Key Ignition and DH Key Change.

    This is made available in the form of MIMIC commands to be used in action scripts, so that the TFTP completion script can generate the authentication key and privacy key.

    Back to Top

    Diffie-Helman key generation commands

    This function generates a random private key and computes the public based on that and returns both the private and the public keys. 

    mimic crypt DH_generate_keys OAKLEY1 | OAKLEY2
    or 
    mimic crypt DH_generate_keys prime generator

    Example: 

    set key [mimic crypt DH_generate_keys OAKLEY2]
set priv_key [lindex $key 0]
set pub_key  [lindex $key 1]
    Back to Top

    Diffie-Helman shared key compute commands

    This function takes the agent's private key, manger's public key and either OAKLEY1 or OAKLEY2 or DH Prime and DH generator as input and returns back the shared key. 

    mimic crypt DH_compute_shared_key local-private-key remote-public-key OAKLEY1 | OAKLEY2
or			
mimic crypt DH_compute_shared_key local-private-key remote-public-key prime generator

    Example: 

    set shared_key [mimic crypt DH_compute_shared_key [list $priv_key] [list $remote_public_key] OAKLEY2
    Back to Top

    PBKDF2 key generation command

    This function takes shared key generated by the previous command as input and generates both the privacy and authentication key. 

    mimic crypt PBKDF2_generate_keys shared-key

    Example: 

    set pass [mimic crypt PBKDF2_generate_keys [list $shared_key]]
set privacy  [lindex pass 0]
set auth_key [lindex pass 1]
    Back to Top

    USM key generation command

    This command generates the private key and the public key for the agent then computes the shared based on the mangers public key passed in as parameter. Then it uses the shared key to generate both the privacy and authentication key. This command takes manager public key and either OAKLEY1 or OAKLEY2 or dh prime and dh generator as input. The output are privacy, authentication, private and public keys. 

    mimic crypt USM_generate_keys remote-public-key OAKLEY1 | OAKLEY2
    or 
    mimic crypt USM_generate_keys remote-public-key prime generator

    Example: 

    set pass [mimic crypt usm_generate_keys [list $remote_public_key] OAKLEY2
set privacy  [lindex pass 0]
set auth_key [lindex pass 1]
set priv_key [lindex pass 2]
set pub_key  [lindex pass 3]
    Back to Top

    Licensing information

    This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit with the following copyrights.

    Back to Top
    << Previous Section    Next Section >>