Simple Two-way Active Measurement Protocol (STAMP) Data ModelZTE Corp.gregimirsky@gmail.comZTE Corp.xiao.min2@zte.com.cnEricssonwei.s.luo@ericsson.com
Transport
Network Working GroupInternet-DraftIPPMSTAMP YANG
This document specifies the data model for implementations of Session-Sender and Session-Reflector
for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG.
The Simple Two-way Active Measurement Protocol (STAMP) can be used
to measure performance parameters of IP networks such as latency, jitter,
and packet loss by sending test packets and monitoring their
experience in the network. The STAMP protocol [Editor:ref to STAMP draft] in unauthenticated mode is on-wire compatible
with STAMP Light, discussed in Appendix I . The STAMP Light is known to have many implementations
though no common management framework being defined, thus leaving some aspects of test packet
processing to interpretation. As one of goals of STAMP is to support these variations, this document presents their analysis;
describes common STAMP and STAMP model while allowing for STAMP extensions in the future. This document defines the STAMP data model
and specifies it formally using the YANG data modeling language .
This version of the interfaces data model confirms to the Network
Management Datastore Architecture (NMDA) defined in .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
The scope of this document includes model of the STAMP as defined in
[Editor:ref to STAMP draft].
This section describes all the parameters of the the stamp data model.
The stamp-session-sender container holds items that are related
to the configuration of the stamp Session-Sender logical entity.
The stamp-session-sender-state container holds information about
the state of the particular STAMP test session.
RPCs stamp-sender-start and stamp-sender-stop respectively start and stop
the referenced by session-id STAMP test session.
The data model supports several scenarios for a STAMP Session-Sender to execute test sessions and calculate
performance metrics:
The test mode in which the test packets are sent unbound in time at defined by
the parameter 'interval' in the stamp-session-sender container frequency is referred as continuous
mode. Performance metrics in the continuous mode are calculated at period defined by the
parameter 'measurement-interval'.
The test mode that has specific number of the test packets configured for the test session in the
'number-of-packets' parameter is referred as periodic mode. The test session may be repeated by the
STAMP-Sender with the same parameters. The 'repeat' parameter defines number of tests and the
'repeat-interval' - the interval between the consecutive tests. The performance metrics are calculated
after each test session when the interval defined by the 'session-timeout' expires.
The stamp-session-reflector container holds
items that are related to the configuration of the STAMP
Session-Reflector logical entity.
The stamp-session-refl-state container holds Session-Reflector
state data for the particular STAMP test session.
Creating STAMP data model presents number of challenges and among them
is identification of a test-session at Session-Reflector. A Session-Reflector MAY require
only as little as its IP and UDP port number in received STAMP-Test packet to spawn new
test session. More so, to test processing of Class-of-Service along the same route in
Equal Cost Multi-Path environment Session-Sender may run STAMP test sessions
concurrently using the same source IP address, source UDP port number, destination
IP address, and destination UDP port number. Thus the only parameter that can be used to
differentiate these test sessions would be DSCP value. The DSCP field may get re-marked
along the path and without use of that will go undetected,
but by using five-tuple instead of four-tuple as a key we can ensure that STAMP test packets that
are considered as different test sessions follow the same path even in ECMP environments.
This document registers a URI in the IETF XML registry .
Following the format in , the following registration is
requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-stamp
Registrant Contact: The IPPM WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the YANG Module Names
registry .
name: ietf-stamp
namespace: urn:ietf:params:xml:ns:yang:ietf-stamp
prefix: stamp
reference: RFC XXXX
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF or RESTCONF .
The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) . The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
.
The NETCONF access control model provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
TBD
Unauthorized access to any data node of these subtrees can adversely
affect the routing subsystem of both the local device and the
network. This may lead to corruption of the measurement that may result in
false corrective action, e.g. false negative or false positive. That could be, for
example, prolonged and undetected deterioration of quality of service or
actions to improve the quality unwarranted by the real network conditions.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
/ietf-vrrp:stampTBD
Unauthorized access to any data node of these subtrees can disclose
the operational state information of VRRP on this device.
Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus important
to control access to these operations. These are the operations and their sensitivity/vulnerability:
TBD
Authors recognize and appreciate valuable comments provided by Adrian Pan.
shows a configuration example for a STAMP-Sender.