[NTDP] Introduction to NTDP

"Craig Brown \(crbrown\)" <crbrown@cisco.com> Sat, 17 June 2006 02:30 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrQZd-0007wD-LF; Fri, 16 Jun 2006 22:30:09 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrQZc-0007w8-Ji for ntdp@ietf.org; Fri, 16 Jun 2006 22:30:08 -0400
Received: from ind-iport-1.cisco.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrQZZ-00020J-4r for ntdp@ietf.org; Fri, 16 Jun 2006 22:30:08 -0400
Received: from hkg-core-1.cisco.com ([]) by ind-iport-1.cisco.com with ESMTP; 17 Jun 2006 08:23:14 -0700
X-IronPort-AV: i="4.06,144,1149490800"; d="scan'208"; a="69202768:sNHT35001040"
Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com []) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5H2Rp6D007542 for <ntdp@ietf.org>; Sat, 17 Jun 2006 10:27:52 +0800 (CST)
Received: from xmb-hkg-411.apac.cisco.com ([]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 17 Jun 2006 10:30:00 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 17 Jun 2006 10:29:59 +0800
Message-ID: <B4B37A0BBB6A0F43B07F12F1056472D6013BF7E8@xmb-hkg-411.apac.cisco.com>
Thread-Topic: Introduction to NTDP
Thread-Index: AcaRte36dyWIWuAvQwORo8a6Vv3Yiw==
From: "Craig Brown \(crbrown\)" <crbrown@cisco.com>
To: <ntdp@ietf.org>
X-OriginalArrivalTime: 17 Jun 2006 02:30:00.0921 (UTC) FILETIME=[EEDD0C90:01C691B5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451
Subject: [NTDP] Introduction to NTDP
X-BeenThere: ntdp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: define standards for the purpose of scripting of network testing equipment <ntdp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ntdp>, <mailto:ntdp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ntdp>
List-Post: <mailto:ntdp@ietf.org>
List-Help: <mailto:ntdp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ntdp>, <mailto:ntdp-request@ietf.org?subject=subscribe>
Errors-To: ntdp-bounces@ietf.org

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

   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





   * Traffic APIs


   * Routing Protocol APIs

















   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

      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
   and disconnect from the device.

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

   # 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 \
      -intf_mode ethernet -netmask -gateway

    # 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

   set dhcpgrp_ret  [vendorA:emulation_dhcp_group_config -handle
dhcp_ret \
            -mode create -encap ethernet_ii_qinq \
            -num_sessions 5 -mac_addr -mac_addr_step \
            -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

   # Traffic config using DHCP resolved address information in "normal"
   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 \
       -l3_protocol ipv4 \
       -ip_dst_addr \
       -ip_dst_step \
       -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

NTDP mailing list