[NTDP] Introduction to NTDP

["Craig Brown \(crbrown\)" <[e-mail]>]

Reposting to this new alias.

1.  Introduction

   This initiative is to create a protocol for the automatic control of
   devices that generate and analyze traffic and/or emulate network
   protocols for the testing of a network or a specific network device.
   To perform either network or a network device specific testing, a
   tester will use a product to generate traffic, emulate routing
   protocols and emulate network end points, such as a network host or
   HTTP client.  This product is referred to as a network testing device
   (NTD).  The term network testing device should not be confused with
   the term device under test (DUT).  In fact, the network testing
   device will most likely support the generation and analysis of
   traffic to validate the performance, scalability, etc of a device
   under test.

   Traffic generation can be defined as the sending of stateless
   traffic, traffic analysis can be defined as the analysis of received
   packets for some set of measurements, and protocol emulation can be
   defined as the emulation of one/many devices/applications.  This
   might include, for example, emulation of a router for sending and
   receiving of routing protocol updates, emulation of a user generating
   HTTP traffic or making a IP call, or emulation of a device generating
   security breaches such as malicious attacks.  Automatic control is
   defined as the unattended operation of a test device in a specific
   manner such that particular traffic is generated/analyzed and
   particular protocols are emulated.

   Consider the example of a testbed that is testing network protocols,
   generating some typical layer 4-7 traffic, placing a call and sending
   voice traffic, and injecting malicious attacks for security testing.
   For this example, there is potentially one device for generating the
   routing protocol traffic, several devices for the emulating clients/
   server traffic, one device for the emulating voice traffic, and one
   device for the generating security testing.  Today, the tester must
   learn the scripting commands for each generation/emulation device,
   develop separate scripts to manage each those devices, and combine
   the results of the various tools into one view.

   This protocol is not intended for the management of the devices
   within the network.  Specifications such as NETCONF, for device
   configurations are already focused on that area.

   The purpose of this alias is to discuss the current issues that
   need resolving and propose a general direction that a new Working
   Group would move towards.  The intention is not to produce an overall
   solution and explain the intricacies of a design.  Some areas will be
   intentionally left unexplained because that will be the purpose of
   the proposed Working Group to resolve.

1.1.  Existing API specification

   The history behind what started the creation of this alias is that
   approximately four years ago, Cisco and several vendors started
   developing a specification that defined a common API.  The purpose of
   this API was to provide the tester with the ability to control
   various network testing devices using a standard set of commands.
   This project has been relatively successful but because of legal
   constraints, distribution of the API has been limited.  The
   experience has shown us that the concept works but also showed
   several pitfalls that would be avoided with an improved architectural
   design.

   The specification consists of several groupings: session, traffic,
   and routing protocol APIs.  Each protocol has the actions of config,
   control, info, and stats and to shorten the list below these names
   have been replaced by one listing with the term action.

   * Session APIs

      connect

      interface_action

      alarms

      cleanup_session

   * Traffic APIs

      traffic_control

   * Routing Protocol APIs

      bgp_action

      dhcp_action

      igmp_action

      isis_action

      ldp_action

      l2tp_action

      mld_action

      msdp_action

      multicast_action

      ospf_action

      pim_action

      ppp_action

      pppox_action

      rip_action

      rsvp_action

      rsvpte_action

   There is a group working to develop the command sets for layer 4 to 7
   starting with the protocols HTTP, FTP, and Telnet.

   The issues that we found in developing this API and would like to
   avoid in the creation of a protocol are:

      A software abstraction layer was required about the API because
      the variances in implementation by each vendor.  The variances
      occurred because the API was developed on top of the vendor's
      existing API and therefore there was an additional level of
      translation from the common API to the proprietary API.

      Every parameter that was offered by the vendors was placed into
      the specification.  This created a large document which, as it
      continues to grow, becomes daunting for the tester to interpret.
      Also, as each vendor does not implement all the parameters, the
      tester is required to be knowledgeable about each vendor's
      implementation.  The software abstraction layer helps resolve some
      of this problem - but not completely.  Having the ability to learn
      the capabilities of the device would greatly assist in this
      problem.

      Implementation time of the common API lagged behind the
      implementation of a feature.  Testers were able to use the
      vendor's libraries and GUI when a new feature was available but
      had to wait for the API specification and for the vendor
      implementation of that specification.  This reduced the incentive
      for the testers to use the common API and then increased the
      issues of script portability.

      The specification was not originally designed for performance and
      scalability and therefore created testing issues.  The eventual
      design for this specification will include the objective of
      performance and scalability and with the ability to scale downward
      to smaller functional testing requirements.

1.1.1.  Coding Example

   This example shows some basic commands used to connect to a device,
   configure the interface, configure a routing protocol, configure
traffic,
   and disconnect from the device.

   # Connect to Vendor A
   vendorA::connect -device 10.1.1.1 -username Craig -port_list {104/1
104/2}

   # Port handles are returned from the connect command and used for
subsequent referencing.
   # In this example, the port handle is the same as the port name

   # Configure the port interface
   vendorA::interface_config -port_handle 104/1 -mode config
-intf_ip_addr 10.10.10.2 \
      -intf_mode ethernet -netmask 255.255.255.0 -gateway 10.10.10.1

    # Create the DHCP emulation port
   set dhcp_ret [vendorA::emulation_dhcp_config -port_handle 1 -mode
create -outstanding_sessions 1]
   if { [keylget dhcp_ret status] != 1 } {error "Failed to config
handle"}

   set dhcpgrp_ret  [vendorA:emulation_dhcp_group_config -handle
dhcp_ret \
            -mode create -encap ethernet_ii_qinq \
            -num_sessions 5 -mac_addr 00.10.95.11.12 -mac_addr_step
0.0.0.0.0.1 \
            -vlan_id_outer 1 -vlan_id_step_outer 1
-vlan_id_counter_outer 2 \
            -vlan_id 10 -vlan_id_step 1 -vlan_id_count 1 ]
   if { [keylget dhcpgrp_ret status ] != 1 } {error -Failed to configure
DHCP group?}

   # Control of the dhcp group, bind all configured groups on the
dhcp_ret port handle
   set dhcpctrl_ret [vendorA::emulation_dhcp_control -port_handle
dhcp_ret -action bind]
   if { [keylget dhcpctrl_ret status] != 1 } { error -Failed to bind
DHCP?}

   # Traffic config using DHCP resolved address information in "normal"
mode
   vendorA::traffic_control -port_handle 1 -mode create -l2_encap
ethernet_ii_qinq \
       -traffic_src_no 1 \
       -dhcp_link 1 \
       -dhcp_link_groups 1 \
       -mac_src_mode dhcp_emulation \
       -mac_dst 00.10.95.22.11.09 \
       -l3_protocol ipv4 \
       -ip_dst_addr 192.162.2.1 \
       -ip_dst_step 0.0.0.1 \
       -ip_dst_count 2

   # Disconnect from the device
   vendorA::cleanup_session -port_handle {104/1 104/2}

2.  Technology Overview

   There appears to be some overlap with other standards in the areas of
   communicating with the test device.  To illustrate how NTDP may work,
   we will use the NETCONF Architecture as a baseline.

                    Layer                      Example
               +-------------+      +-----------------------------+
               |   Content   |      |       Data Structures       |
               +-------------+      +-----------------------------+
                      |                           |
               +-------------+      +-----------------------------+
               | Operations  |      | <config>, <control> <query> |
               +-------------+      +-----------------------------+
                      |                           |
               +-------------+      +-----------------------------+
               |     RPC     |      |    <rpc>, <rpc-reply>       |
               +-------------+      +-----------------------------+
                      |                           |
               +-------------+      +-----------------------------+
               | Application |      |   BEEP, SSH, SSL, console   |
               |   Protocol  |      |                             |
               +-------------+      +-----------------------------+

   Similar to NETCONF, we propose a similar transport layer with perhaps
   a different set of operations commands.  The data structures would be
   divided in categories based on the technologies.  For example, the
   data structure for configuring HTTP will be different from SIP, as
   would the routing protocols.

As we progress in this discussion the topics will include areas such as:

- protocols (there's a number of these...)
- traffic generation and analysis
- infrastructure (chassis connection, alarms, capture buffer, etc.)
- syntax rules (general syntactical structure of the protocol, transport
layer or transport layer independence, etc.)

I hope this begins to clarify the intent and look forward to many
discussions.
 
Regards,
Craig

_______________________________________________
NTDP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ntdp