RE: [NTDP] Goal clarification

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

JZee,

Your right that there will not be commonality across all technologies
and to use your term "the goal is to create a common "form" or syntax
for the configuration data across both services and devices".

There are two parts to this problem; first is the transport layer to
communicate with the device and the second is the appropriate data
structure/form/syntax to use. The transport layer shouldn't be that
difficult because there are already plenty of groups working on similar
tasks. The data structure becomes the challenge, and more so how the
application that is communicating to the device, using NTDP, interprets
what it sends and gets back. 

The thoughts behind the data structure section can be related to how we
view the device. To setup the traffic generation, my view is that I
(being the tester) am required to configure characteristics. For HTTP, I
would define a user's behavior such as the type of browser, whether
cookies are enabled, http version, etc. There may be several different
user profiles created. I would then associate how many of iterations of
userA will begin over period n. For routing protocols, the
characteristics of BGP would be whether to advertise routes, AS number,
etc and the associated load then defines how much that profile performs
functions such as link flapping, etc. And for voice, the characteristics
would be the type of phone SIP, Skinny, H.323, and the variety of
capabilities. The association is how many calls to place, put on hold,
etc.
This is a rough example of defining the characteristics and the
associated load generation. The point here is that if we can agree on
how the tester interacts with the devices, then the data models should
become clearer. 

Based off our previous experience with routing protocols, here is the
structure that we used including the HELLO message (which doesn't exist
in our API). This is provided as an example of how we currently group
our functions.

1. HELLO	-> contact the device
		<- receive device info including capabilities

2. INFO	-> request specific information regarding:
			i.   device hardware
			ii.  device software
			iii. Feature specific capabilities

3. CONFIGURE -> configuration details (Define the characteristics)
			i.   Device - interface
			ii.  Protocol
			iii. Client
			iv.  Network - L2 / L3

4. CONTROL	-> control the environment (Define the associations and
load)
			i.   Traffic
			ii.  Alarms
			iii. Protocols
			iv.  Clients

5. STATS	-> return statistics
			i.  Device - interface
			ii. Protocols

6. DISCONNECT

In this example the commonality is the structure and the data models
overlay it.

Let's assume the data model falls into place, the bigger issue is then
how the tester discovers what is implemented per device and how to
interpret extensions to the data model. We can use a HELLO message that
returns the device capabilities and features supported. And an INFO
requests the detailed capabilities of a supported feature, the arguments
supported, and also the details of any vendor extended arguments. 

But, let's say I send a HELLO message and receive that this device is
vendorA and supports BGP, OSPF, and DHCP. I send an INFO message for BGP
details and find that this device has version 1.2 of the specification
implemented and that the features supported are A, B, and C. My
application will then load the v1.2 data structure and understand if any
capabilities are missing. This device also returns a flag indicating a
vendor extension. 

How does the application understand what the extension provides?

What is meant by an application? In this situation, the term application
is being to used to define the program that sends and receives the NTDP
messages. This program may be existing vendor APIs, a tester's script,
appl. from the open source community, etc. I cannot imagine that a
tester would write a script to manage this environment but an tester's
company may. 

Today, some vendors provide APIs to control their devices and these APIs
could remain the same and use the new format behind the scenes. Because
the vendor knows what there extensions are then they can operate without
much confusion. This solves the immediate problem of an existing user
base but does not solve the problem that we are trying to achieve which
as you say is "to shorten the learning curve for the tester"; the reason
is that the tester still ends up using the proprietary API. This is
another problem that needs to be discussed further. 

Not sure if I answered your questions or just raised more of them ;)

Cheers,
Craig

________________________________

	From: John Zaharychuk [mailto:[e-mail]] 
	Sent: Friday, June 23, 2006 6:59 AM
	To: [e-mail]
	Subject: [NTDP] Goal clarification
	
	
	Morning,
	 
	I have read through the introductory details posted by Craig and
they raise a few points that I would like to discuss.
	 
	The example testbed described utilizes four different devices to
generate the combined test traffic required for the test. Each of these
devices generates a different type (or types) of traffic.  While I can
see a desire to have common commands and scripts across devices that
perform identical functions, I am less clear as to how commonality can
be achieved across different services. The configuration data for a
Voice Call and the collection of MOS metrics is different than the
configuration data for an FTP file transfer and the collection of
throughput metrics. These differences are independent of the fact that
different devices are being used. The same differences would exist if a
single superset device was used. Granted, each device that connects to
the network shares some common network configuration, but it is the
service configuration where the complexity lies. 
	 
	Maybe the goal is to create a common "form" or syntax for the
configuration data across both services and devices. It could shorten
the learning curve for the tester, but would not eliminate the need to
understand the different services and metrics.
	 
	I look forward to a better understanding and further
discussions.
	 
	JZee
	 

	"This e-mail and any files transmitted with it are confidential
and are for the use of the individual or entity to whom they are
addressed.  This communication may contain material protected by the
attorney-client privilege or by state or federal laws protecting trade
secrets and/or Company Confidential Proprietary information.  If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, be advised that you have received this
e-mailing error and that any use, dissemination, forwarding, printing,
or copying this e-mail is strictly prohibited.  If you have received
this e-mail in error, please immediately notify [e-mail]
via return e-mail."

	 

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