[lmap] UDP Echo example

["STARK, BARBARA H" <[e-mail]>]

Getting away from ping, I'd like to use UDP Echo "Measurement Method" as an example to perhaps back into what would be needed in an LMAP information model and an IPPM registry to make UDP Echo usable in an LMAP context. I'm using it because there exists a data model related to the UDP Echo server function, and this modeled UDP Echo server is interesting in that it does *not* initiate the test, has input parameters, and reports collected information.

UDP Echo is defined (barely) in [RFC 862]. A UDP Echo server listens for UDP datagrams.  When a datagram is received, the data from it is sent back in an answering datagram. That's pretty much all that the RFC says.

BBF [TR-143] describes implementing a UDP Echo server in a piece of CPE and how to configure this via TR-069. It does not describe the UDP Echo client, other than to say that such a thing exists in an element in the ISP network and it sends the UDP packets (that the server is expected to listen for).

For mapping to LMAP/IPPM, let's call the CPE with the UDP Echo server function MA1, and the element sending UDP packets is MA2. UDP Echo is a Measurement Method. The UDP Echo server functionality on MA1 is a locally executable program.

If we look at the TR-069 data model in [TR-143], we see that MA1's UDP Echo server functionality has input parameters of (1) a port to listen on and (2) a source IP address (MA1 will only respond to UDP packets from this source IP address). In an LMAP world, I think these would be the information-model ma-task-options<0..*>. There is also an input of the network interface to listen on. [I see that while information-model lets the MA tell the Controller what its interfaces are, there's no current linkage to allow an interface to be specified for a ma-task-obj. I think this is probably just an oversight and needs to be added.] The functionality can be enabled. I think in information-model this would be represented by using a schedule to indicate when this function is supposed to be up and running. [TR-143] also describes some collected measurements (packets and bytes received, packets and bytes sent) that I would expect to be sent out in a report (ma-sched-report-obj).

[TR-143] doesn't describe the nebulous UDP Echo client configuration, but I think that some input parameters associated with such a configuration might be UDP packet size, destination IP address, time interval between UDP packets, and number of UDP packets. It could be scheduled to run. It could report on average/max elapsed time between a sent UDP packet and the response, jitter, etc. The main take-away from this is that the inputs and outputs are different than those of the UDP Echo server. Currently, there is no expectation for CPE that support UDP Echo server to also support the client, or for the network elements with the client to support the server, although there is nothing that precludes both of these from being supported on a single device. These are very distinct locally executable program capabilities.

Now I need to back into the registry (ma-task-registry). The registry entry is supposed to let the MA identify which locally executable program to run (the UDP Echo server). The Controller is also supposed to know, via the registry entry, what the allowed set of input parameters are. So there is no ambiguity, the registry therefore has to list a distinct set of inputs and outputs for UDPEcho.server and for UDPEcho.client, with a different urn for each of these roles. The Controller has to know which endpoint is performing which role, and how to appropriately configure that particular role. 

A registry entry that attempts to describe Measurement Method inputs and outputs as components of the holistic Measurement Method and not as components of specific roles is not very useful, except in cases where all MAs taking part in a Measurement Method are expected to have identical functionality and behavior, or where there is only a single MA involved.

Barbara

[TR-143] http://www.broadband-forum.org/technical/download/TR-143_Corrigendum-1.pdf
[RFC 862] http://www.ietf.org/rfc/rfc862.txt