Two-Way Active Measurement Protocol
(TWAMP) Data ModelCiena Corporation307 Legget DriveKanataONK2K 3C8Canadagcivil@ciena.comwww.ciena.comAT&T Labs200 Laurel Avenue SouthMiddletown,NJ07748USA+1 732 420 1571acmorton@att.comCisco Systems2000 Innovation DriveKanataONK2K 3E8Canadarrahman@cisco.comXoriant Corporation1248 Reamswood DriveSunnyvaleCA94089USAmjethanandani@gmail.comTravelpingSiemensdamm 5013629BerlinGermanyk.pentikousis@travelping.com
Transport
IPPM WGThis document specifies a data model for client and server
implementations of the Two-Way Active Measurement Protocol (TWAMP). The
document defines the TWAMP data model through Unified Modeling Language
(UML) class diagrams and formally specifies it using a NDMA-compliant
YANG model.IntroductionThe Two-Way Active Measurement Protocol
(TWAMP) is used to measure network performance parameters such
as latency, bandwidth, and packet loss by sending probe packets and
measuring their experience in the network. To date, TWAMP
implementations do not come with a standard management framework, and,
as such, implementers have no choice except to provide a proprietary
mechanism. This document addresses this gap by defining the model using
UML class diagrams, and formally specifying a
NMDA-complaint TWAMP data model using
YANG 1.1 .MotivationIn current TWAMP deployments the lack of a standardized data model
limits the flexibility to dynamically instantiate TWAMP-based
measurements across equipment from different vendors. In large,
virtualized, and dynamically instantiated infrastructures where
network functions are placed according to orchestration algorithms,
proprietary mechanisms for managing TWAMP measurements pose severe
limitations with respect to programmability.Two major trends call for standardizing TWAMP management aspects.
First, it is expected that in the coming years large-scale and
multi-vendor TWAMP deployments will become the norm. From an
operations perspective, using several vendor-specific TWAMP
configuration mechanisms when one standard mechanism could provide an
alternative is expensive and inefficient. Second, the increasingly
software-defined and virtualized nature of network infrastructures,
based on dynamic service chains and programmable
control and management planes Software-Defined
Networking (SDN): Layers and Architecture Terminology requires
a well-defined data model for TWAMP implementations. This document
defines such a TWAMP data model and specifies it formally using the
YANG 1.1 data modeling language.Note to RFC Editor:Please replace the date 2018-07-02 in Section 5.2 of the draft with
the date of publication of this draft as a RFC. Also, replace
reference to RFC XXXX, and draft-ietf-ippm-port-twamp-test with the
RFC numbers assigned to the drafts.TerminologyThe 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.Document OrganizationThe rest of this document is organized as follows. presents the scope and applicability of this
document. provides a high-level overview of
the TWAMP data model. details the
configuration parameters of the data model and
specifies in YANG the TWAMP data model.
lists illustrative examples which conform to the YANG data model
specified in this document. elaborates
these examples further.Scope, Model, and ApplicabilityThe purpose of this document is the specification of a
vendor-independent data model for TWAMP implementations. illustrates a redrawn version of the TWAMP
logical model found in Section 1.2 of TWAMP
. The figure is annotated with pointers to the UML diagrams provided in this document and
associated with the data model of the four logical entities in a TWAMP
deployment, namely the TWAMP Control-Client, Server, Session-Sender and
Session-Reflector. A UML Notation Guide is
available in Section 5 of the said document.As per TWAMP , unlabeled links in are left unspecified and may be proprietary
protocols.Annotated TWAMP logical model | Server |
+----------------+ +--------+
^ ^
| |
V V
+----------------+ +-------------------+
| Session-Sender | <-- TWAMP-Test --> | Session-Reflector |
+----------------+ +-------------------+
[Fig. 5] [Fig. 6]
]]>As per TWAMP , a TWAMP implementation
may follow a simplified logical model, in which the same node acts both
as Control-Client and Session-Sender, while another node acts at the
same time as TWAMP Server and Session-Reflector. illustrates this simplified logical model and
indicates the interaction between the TWAMP configuration client and
server using, for instance, NETCONF or
RESTCONF .Simplified TWAMP model and protocols | Server |
| | | |
| Session-Sender | <-- TWAMP-Test --> | Session-Reflector |
+-------------------+ +-------------------+
]]>The data model defined in this document is orthogonal to the specific
protocol used between the Config client and Config server to communicate
the TWAMP configuration parameters.Operational actions such as how TWAMP-Test sessions are started and
stopped, how performance measurement results are retrieved, or how
stored results are cleared, and so on, are not addressed by the
configuration model defined in this document. As noted above, such
operational actions are not part of the TWAMP specification TWAMP and hence are out of scope of this
document. See also . In addition,
for operational state, current work in Registry for Performance
Metrics, can be used to develop an independent model for the
performance metrics that need to be captured and retrieved.Data Model OverviewThe TWAMP data model includes four categories of configuration
items.First, global configuration items relate to parameters that are set
on a per device level. For example, the administrative status of the
device with respect to whether it allows TWAMP sessions and, if so, in
what capacity (e.g. Control-Client, Server or both), is a typical
instance of a global configuration item.A second category includes attributes that can be configured on a per
TWAMP-Control connection basis, such as the Server IP address.A third category includes attributes related to per TWAMP-Test
session attributes, for instance setting different values in the
Differentiated Services Code Point (DSCP) field.Finally, the data model includes attributes that relate to the
operational state of the TWAMP implementation.As the TWAMP data model is described in the remaining sections of
this document, readers should keep in mind the functional entity
grouping illustrated in .Control-ClientA TWAMP Control-Client has an administrative status field set at
the device level that indicates whether the node is enabled to
function as such.Each TWAMP Control-Client is associated with zero or more
TWAMP-Control connections. The main configuration parameters of each
control connection are:
A name which can be used to uniquely identify at the
Control-Client a particular control connection. This name is
necessary for programmability reasons because at the time of
creation of a TWAMP-Control connection not all IP and TCP port
number information needed to uniquely identify the connection is
available.
The IP address of the interface the Control-Client will use for
connections.
The IP address of the remote TWAMP Server.
Authentication and encryption attributes such as KeyID, Token
and the Client Initialization Vector (Client-IV); see also Section
3.1 in OWAMP and Randomness Requirements for Security .
Each TWAMP-Control connection, in turn, is associated with zero or
more TWAMP-Test sessions. For each test session, the following
configuration items should be noted:
The test session name uniquely identifies a particular test
session at the Control-Client and Session-Sender. Similar to the
control connections above, this unique test session name is needed
because at the time of creation of a TWAMP-Test session, for
example, the source UDP port number is not known to uniquely
identify the test session.
The IP address and UDP port number of the Session-Sender on the
path under test by TWAMP.
The IP address and UDP port number of the Session-Reflector on
said path.
Information pertaining to the test packet stream, such as the
test starting time, which performance metric is to be used, as
defined in Registry
for Performance Metrics , or whether the test should be
repeated.
ServerEach TWAMP Server has an administrative status field set at the
device level to indicate whether the node is enabled to function as a
TWAMP Server.Each Server is associated with zero or more TWAMP-Control
connections. Each control connection is uniquely identified by the
4-tuple {Control-Client IP address, Control-Client TCP port number,
Server IP address, Server TCP port}. Control connection configuration
items on a TWAMP Server are read-only.Session-SenderA TWAMP Session-Sender has an administrative status field set at
the device level that indicates whether the node is enabled to
function as such.There is one Session-Sender instance for each TWAMP-Test session
that is initiated from the sending device. Primary configuration
fields include:
The test session name MUST be identical to the corresponding
test session name on the TWAMP Control-Client ().
The control connection name, which along with the test session
name uniquely identify the TWAMP Session-Sender instance.
Information pertaining to the test packet stream, such as, the
number of test packets and the packet distribution to be employed;
see also Network performance measurement
with periodic streams .
Session-ReflectorEach TWAMP Session-Reflector has an administrative status field set
at the device level to indicate whether the node is enabled to
function as such.Each Session-Reflector is associated with zero or more TWAMP-Test
sessions. For each test session, the REFWAIT timeout parameter, which
determines whether to discontinue the session if no packets have been
received (TWAMP , Section 4.2), can be
configured.Read-only access to other data model parameters, such as the Sender
IP address, is foreseen. Each test session can be uniquely identified
by the 4-tuple mentioned in .Data Model ParametersThis section defines the TWAMP data model using UML and introduces selected parameters associated
with the four TWAMP logical entities. The complete TWAMP data model
specification is provided in the YANG module presented in .Control-ClientThe client container (see ) holds
items that are related to the configuration of the TWAMP
Control-Client logical entity (recall ).The client container includes an administrative configuration
parameter (client/admin-state) that indicates whether the device is
allowed to initiate TWAMP-Control connections.TWAMP Control-Client UML class diagram----------------------| mode-preference-chain |
| | +-----------------------+
| | 1..* +------------+ | priority |
| |<>-----| key-chain | | mode |
+-------------+ +------------+ +-----------------------+
^ | key-id |
V | secret-key |
| +------------+
| 0..*
+------------------------+
| ctrl-connection |
+------------------------+
| name |
| client-ip |
| server-ip |
| server-tcp-port | 0..* +----------------------+
| control-packet-dscp |<>-------| test-session-request |
| key-id | +----------------------+
| max-count | | name |
| client-tcp-port {ro} | | sender-ip |
| server-start-time {ro} | | sender-udp-port |
| state {ro} | | reflector-ip |
| selected-mode {ro} | | reflector-udp-port |
| token {ro} | | timeout |
| client-iv {ro} | | padding-length |
+------------------------+ | test-packet-dscp |
| start-time |
+-------------+ 1 | repeat |
| pm-reg-list |------<>| repeat-interval |
+-------------+ | state {ro} |
| pm-index | | sid {ro} |
+-------------+ +----------------------+
]]>The client container holds a list (mode-preference-chain) which
specifies the Mode values according to their preferred order of use by
the operator of this Control-Client, including the authentication and
encryption Modes. Specifically, mode-preference-chain lists the mode
and its corresponding priority, as a 16-bit unsigned integer. Values
for the priority start with zero, the highest priority, and decreasing
priority value is indicated by every increase in value by one.Depending on the Modes available in the Server Greeting, the
Control-Client MUST choose the highest priority Mode from the
configured mode-preference-chain list.Note that the list of preferred Modes may set multiple bit
positions independently, such as when referring to the extended TWAMP
features in Mixed Security Mode for TWAMP
, Individual Session Control Feature for
TWAMP , TWAMP Reflect Octets and
Symmetrical Size Features , and IKEv2-Derived Shared Secret Key for OWAMP and TWAMP
. If the Control-Client cannot determine an acceptable Mode, or
when the bit combinations do not make sense, e.g., both authenticated
and unauthenticated bit are set, it MUST respond with zero Mode bits
set in the Set-up Response message, indicating it will not continue
with the control connection.In addition, the client container holds a list named key-chain
which relates key-id with the respective secret-key. Both the Server
and the Control-Client use the same mappings from key-id to secret-key
(in ); in order for this to work
properly, key-id must be unique across all systems in the
administrative domain. The Server, being prepared to conduct sessions
with more than one Control-Client, uses key-id to choose the
appropriate secret-key; a Control-Client would typically have
different secret keys for different Servers. The secret-key is the
shared secret, of type binary and the length SHOULD contain at least
128 bits of entropy. The key-id and secret-key encoding SHOULD follow
Section 9.8 of YANG . The derived key
length (dkLen in PKCS #5: Password-Based
Cryptography Specification Version 2.1 ) MUST be 16 octets for
the AES Session-key used for encryption and 32 octets for the
HMAC-SHA1 Session-key used for authentication; see also Section 6.10
of OWAMP .Each client container also holds a list of control connections,
where each item in the list describes a TWAMP control connection
initiated by this Control-Client. There SHALL be one ctrl-connection
per TWAMP-Control (TCP) connection that is to be initiated from this
device.In turn, each ctrl-connection holds a test-session-request list.
Each test-session-request holds information associated with the
Control-Client for this test session. This includes information
associated with the Request-TW-Session/Accept-Session message exchange
(see Section 3.5 of TWAMP ).There SHALL be one instance of test-session-request for each
TWAMP-Test session that is to be negotiated by this TWAMP-Control
connection via a Request-TW-Session/Accept-Session exchange.The Control-Client is also responsible for scheduling TWAMP-Test
sessions, therefore test-session-request holds information related to
these actions (e.g. pm-index, repeat-interval).ServerThe server container (see ) holds
items that are related to the configuration of the TWAMP Server
logical entity (recall ).The server container includes an administrative configuration
parameter (server/admin-state) that indicates whether the device is
allowed to receive TWAMP-Control connections.A device operating in the Server role cannot configure attributes
on a per TWAMP-Control connection basis, as it has no foreknowledge of
the incoming TWAMP-Control connections to be received. Consequently,
any parameter that the Server might want to apply to an incoming
control connection must be configured at the overall Server level and
applied to all incoming TWAMP-Control connections.TWAMP Server UML class diagram------| key-chain |
| servwait | +------------+
| control-packet-dscp | | key-id |
| count | | secret-key |
| max-count | +------------+
| modes |
| | 0..* +--------------------------+
| |<>------| ctrl-connection |
+---------------------+ +--------------------------+
| client-ip {ro} |
| client-tcp-port {ro} |
| server-ip {ro} |
| server-tcp-port {ro} |
| state {ro} |
| control-packet-dscp {ro} |
| selected-mode {ro} |
| key-id {ro} |
| count {ro} |
| max-count {ro} |
| salt {ro} |
| server-iv {ro} |
| challenge {ro} |
+--------------------------+
]]>Each server container holds a list named key-chain which relates
key-id with the respective secret-key. As mentioned in , both the Server and the Control-Client use
the same mapping from key-id to shared secret-key; in order for this
to work properly, key-id must be unique across all the systems in the
administrative domain. The Server, being prepared to conduct sessions
with more than one Control-Client, uses key-id to choose the
appropriate secret-key; a Control-Client would typically have
different secret keys for different Servers. The key-id tells the
Server which shared secret-key the Control-Client wishes to use for
authentication or encryption.Each incoming control connection active on the Server is
represented by a ctrl-connection. There SHALL be one ctrl-connection
per incoming TWAMP-Control (TCP) connection that is received and
active on the Server. Each ctrl-connection can be uniquely identified
by the 4-tuple {client-ip, client-tcp-port, server-ip,
server-tcp-port}. All items in the ctrl-connection list are
read-only.Session-SenderThe session-sender container, illustrated in , holds items that are related to the
configuration of the TWAMP Session-Sender logical entity.The session-sender container includes an administrative parameter
(session-sender/admin-state) that controls whether the device is
allowed to initiate TWAMP-Test sessions.TWAMP Session-Sender UML class diagram-----| test-session |
+----------------+ +---------------------------+
| name |
| ctrl-connection-name {ro} |
| fill-mode |
| number-of-packets |
| state {ro} |
| sent-packets {ro} |
| rcv-packets {ro} |
| last-sent-seq {ro} |
| last-rcv-seq {ro} |
+---------------------------+
^
V
| 1
+---------------------+
| packet-distribution |
+---------------------+
| periodic / poisson |
+---------------------+
| |
+-------------------+ |
| periodic-interval | |
+-------------------+ |
|
+--------------+
| lambda |
| max-interval |
+--------------+
]]>Each TWAMP-Test session initiated by the Session-Sender will be
represented by an instance of a test-session object. There SHALL be
one instance of test-session for each TWAMP-Test session for which
packets are being sent.Session-ReflectorThe session-reflector container, illustrated in , holds items that are related to the
configuration of the TWAMP Session-Reflector logical entity.The session-reflector container includes an administrative
parameter (session-reflector/admin-state) that controls whether the
device is allowed to respond to incoming TWAMP-Test sessions.A device operating in the Session-Reflector role cannot configure
attributes on a per-session basis, as it has no foreknowledge of what
incoming sessions it will receive. As such, any parameter that the
Session-Reflector might want to apply to an incoming TWAMP-Test
session must be configured at the overall Session-Reflector level and
are applied to all incoming sessions.TWAMP Session-Reflector UML class diagramEach incoming TWAMP-Test session that is active on the
Session-Reflector SHALL be represented by an instance of a
test-session object. All items in the test-session object are
read-only.Instances of test-session are indexed by a session identifier
(sid). This value is auto-allocated by the TWAMP Server as test
session requests are received, and communicated back to the
Control-Client in the SID field of the Accept-Session message; see
Section 4.3 of TWAMP Reflect Octets and
Symmetrical Size Features .When attempting to retrieve operational data for active test
sessions from a Session-Reflector device, the user will not know what
sessions are currently active on that device, or what SIDs have been
auto-allocated for these test sessions. If the user has network access
to the Control-Client device, then it is possible to read the data for
this session under client/ctrl-connection/test-session-request/sid and
obtain the SID (see ). The user may
then use this SID value as an index to retrieve an individual
session-reflector/test-session instance on the Session-Reflector
device.If the user has no network access to the Control-Client device,
then the only option is to retrieve all test-session instances from
the Session-Reflector device, and then pick out specific test-session
instances of interest to the user. This could be problematic if a
large number of test sessions are currently active on that device.Each Session-Reflector TWAMP-Test session contains the following
4-tuple: {parent-connection-client-ip,
parent-connection-client-tcp-port, parent-connection-server-ip,
parent-connection-server-tcp-port}. This 4-tuple MUST correspond to
the equivalent 4-tuple {client-ip, client-tcp-port, server-ip,
server-tcp-port} in server/ctrl-connection. This 4-tuple allows the
user to trace back from the TWAMP-Test session to the (parent)
TWAMP-Control connection that negotiated this test session.Data ModelThis section formally specifies the TWAMP data model using YANG.YANG Tree DiagramThis section presents a simplified graphical representation of the
TWAMP data model using a YANG tree diagram. Readers should keep in
mind that the limit of 72 characters per line forces us to introduce
artificial line breaks in some tree diagram nodes. Tree diagrams used
in this document follow the notation defined in YANG Tree Diagrams.YANG Tree Diagram.YANG ModuleThis section presents the YANG module for the TWAMP data model
defined in this document. The module imports definitions from Common YANG Data Types, and references NTPv4 Specification, Framework for IP Performance Metrics, Randomness Requirements for Security, OWAMP, TWAMP,
More Features for TWAMP, Individual Session Control Feature, TWAMP Reflect Octets and Symmetrical Size
Features, Advances Stream and Sampling
Framework, IKEv2-Derived Shared Secret
Key for OWAMP and TWAMP, and OWAMP and TWAMP Well-Known Port
Assignments.Data Model ExamplesThis section presents a simple but complete example of configuring
all four entities in , based on the YANG
module specified in . The example is illustrative
in nature, but aims to be self-contained, i.e. were it to be executed in
a real TWAMP implementation it would lead to a correctly configured test
session. For completeness, examples are provided for both IPv4 and
IPv6.A more elaborated example, which also includes authentication
parameters, is provided in .Control-Client shows a configuration example for a
Control-Client with client/admin-state enabled. In a real
implementation following this would permit
the initiation of TWAMP-Control connections and TWAMP-Test
sessions.XML instance enabling Control-Client operation.true
]]>The following example shows a Control-Client with two instances of
client/ctrl-connection, one called "RouterA" and another called
"RouterB". Each TWAMP-Control connection is to a different Server. The
control connection named "RouterA" has two test session requests. The
TWAMP-Control connection named "RouterB" has no TWAMP-Test session
requests.trueRouterA203.0.113.1203.0.113.2Test1203.0.113.354001203.0.113.4500010Test2203.0.113.154001203.0.113.2500010RouterB203.0.113.1203.0.113.3trueRouterA2001:DB8:203:0:113::12001:DB8:203:0:113::2Test12001:DB8:203:1:113::3540002001:DB8:203:1:113::4550000Test22001:DB8:203:0:113::1540012001:DB8:203:0:113::2550010RouterB2001:DB8:203:0:113::12001:DB8:203:0:113::3
]]>Server shows a configuration example for a
Server with server/admin-state enabled, which permits a device
following to respond to TWAMP-Control
connections and TWAMP-Test sessions.XML instance enabling Server operation.true
]]>The following example presents a Server with the TWAMP-Control
connection corresponding to the control connection name
(client/ctrl-connection/name) "RouterA" presented in .true203.0.113.116341203.0.113.2862activetrue2001:DB8:203:0:113::1163412001:DB8:203:0:113::2862active
]]>Session-Sender shows a configuration example for a
Session-Sender with session-sender/admin-state enabled, which permits
a device following to initiate TWAMP-Test
sessions.XML instance enabling Session-Sender operation.true
]]>The following configuration example shows a Session-Sender with the
two TWAMP-Test sessions presented in .trueTest1RouterA9001Test2RouterA90012
]]>Session-ReflectorThis configuration example shows a Session-Reflector with
session-reflector/admin-state enabled, which permits a device
following to respond to TWAMP-Test
sessions.XML instance enabling Session-Reflector operation.true
]]>The following example shows the two Session-Reflector TWAMP-Test
sessions corresponding to the test sessions presented in .true203.0.113.354000203.0.113.4500011232203.0.113.1
16341
203.0.113.2
862
2211203.0.113.154001192.0.2.250001178943203.0.113.1
16341
203.0.113.2
862
21212020
[note: '\' line wrapping is for formatting only]
true203.0.113.354000203.0.113.4540011232203.0.113.1
16341
203.0.113.2
862
2211203.0.113.154001192.0.2.255001178943203.0.113.1
16341
203.0.113.2
862
21212020
]]>Security ConsiderationsVirtually all existing measurement systems using TWAMP are administered by the same network
operator. Attacks on the measurement infrastructure could be launched by
third-parties to commandeer the packet generation capability, corrupt
the measurements, or other examples of nefarious acts.The YANG module specified in of 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 Module
(NACM) 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 nodes defined in this YANG module which are
writeable. These data nodes may be considered sensitive and vulnerable
to attacks in some network environments. Ability to write into these
nodes without proper protection can have a negative effect on the
devices that support this feature.If written, the 'admin-state' node can cause unintended test sessions
to be created. If the node 'number-of-packets' that dictates how many
packets are sent in any particular test session is written with a large
value, it can cause a test session to run longer than expected. Nodes
that are particularly vulnerable include several timeout values put in
the protocol to protect against sessions that are not active but are
consuming resources. These are the REFWAIT timeout parameter which
determine whether to discontinue the session if no packets are received,
and nodes 'count' and 'max-count-exponent' which can cause a long
time to be spent on PBKDF2 iterations. In addition, 'dscp' node
marked with different DSCP markings, can cause the test traffic on the
network to be skewed, and the result manipulated. Finally, nodes within
'mode-preference-chain' which specify the 'mode' and 'priority' values
and indicate the preferred order of use by an operator, can be
manipulated to send unauthenticated or non-encrypted traffic, enabling a
MITM attack. Limiting access to these nodes will limit the ability to
launch an attack in network environments.The 'token' node defined in the model, containing a
concatenation of a Challenge, AES Session-key used for encryption, and
HMAC-SHA1 Session-key used for authentication, is sensitive from a
privacy perspective, and can be used to disrupt a test session. The
ability to read the field should be limited to the administrator of the
test network.IANA ConsiderationsThis document registers a URI in the IETF XML
registry . Following the format in IETF
XML Registry , the following registration is requested to be
made.URI: urn:ietf:params:xml:ns:yang:ietf-twampRegistrant Contact: The IESG.XML: N/A, the requested URI is an XML namespace.This document registers a YANG module in the YANG Module Names
registry YANG .name: ietf-twampnamespace: urn:ietf:params:xml:ns:yang:ietf-twampprefix: twampreference: RFC XXXXAcknowledgementsWe thank Fred Baker, Kevin D'Souza, Gregory Mirsky, Brian Trammell,
Robert Sherman, and Marius Georgescu for their thorough and constructive
reviews, comments and text suggestions.Haoxing Shen contributed to the definition of the YANG module in
.Jan Lindblad and Ladislav Lhokta did thorough reviews of the YANG
module and the examples in .Kostas Pentikousis was partially supported by FP7 UNIFY
(http://fp7-unify.eu), a research project partially funded by the
European Community under the Seventh Framework Program (grant agreement
no. 619609). The views expressed here are those of the authors only. The
European Commission is not liable for any use that may be made of the
information in this document.ContributorsLianshu Zheng.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Network performance measurement with periodic streamsThis memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS-TRACK]The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Randomness Requirements for SecuritySecurity systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.A One-way Active Measurement Protocol (OWAMP)The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]A Two-Way Active Measurement Protocol (TWAMP)The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]Network Time Protocol Version 4: Protocol and Algorithms SpecificationThe Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size FeaturesThis memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)The One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP. If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management.The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.OWAMP and TWAMP Well-Known Port AssignmentsThis memo explains the motivation and describes the re-assignment of well-known ports for the One-way Active Measurement Protocol and Two- way Active Measurement Protocol (OWAMP and TWAMP) protocols for control and measurement, and clarifies the meaning and composition of these standards track protocol names for the industry. The memo updates RFC 4656 and RFC 5357, in terms of the UDP well- known port assignments, and clarifies the complete OWAMP and TWAMP protocol composition for the industry.Registry for Performance MetricsThis document defines the format for the IANA Performance Metrics Registry. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers.Information technology - Open Distributed Processing -
Unified Modeling LanguageISO/IECInformative ReferencesFramework for IP Performance MetricsThe purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)This memo describes a simple extension to TWAMP (the Two-Way Active Measurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. [STANDARDS-TRACK]Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.Software-Defined Networking (SDN): Layers and Architecture TerminologySoftware-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.PKCS #5: Password-Based Cryptography Specification Version 2.1This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques.This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.This document also obsoletes RFC 2898.RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).YANG Tree DiagramsThis document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.Network Configuration Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536.Network Management Datastore Architecture (NMDA)Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.Research directions in network service chainingJohn, W., Pentikousis, K., et al.Detailed Data Model ExamplesThis appendix extends the example presented in by configuring more fields such as authentication
parameters, DSCP values and so on.Control-Clienttrue0authenticated1unauthenticatedKeyClient1ToRouterAc2VjcmV0MQ==KeyForRouterBc2VjcmV0Mg0KRouterA203.0.113.1203.0.113.232KeyClient1ToRouterATest1203.0.113.354000203.0.113.455000640Test2203.0.113.154001203.0.113.2550011280true0authenticated1unauthenticatedKeyClient1ToRouterAc2VjcmV0MQ==KeyForRouterBc2VjcmV0Mg0KRouterA2001:DB8:203:0:113::12001:DB8:203:0:113::232KeyClient1ToRouterATest12001:DB8:10:1:1::1540002001:DB8:10:1:1::255000640Test22001:DB8:203:0:113::1540012001:DB8:203:0:113::2550011280
]]>Servertrue180032authenticated unauthenticated15KeyClient1ToRouterAc2VjcmV0MQ==KeyClient10ToRouterAc2VjcmV0MTANCg==203.0.113.116341203.0.113.286232unauthenticatedKeyClient1ToRouterA15true180032authenticated unauthenticated15KeyClient1ToRouterAc2VjcmV0MQ==KeyClient10ToRouterAc2VjcmV0MTANCg==2001:DB8:203:0:113::1163412001:DB8:203:0:113::286232unauthenticatedKeyClient1ToRouterA15
]]>Session-SendertrueTest1RouterAzero90012211Test2RouterArandom9001221212020
]]>Session-Reflectortrue203.0.113.354000203.0.113.4550001232203.0.113.1
16341
203.0.113.2
862
322211203.0.113.154001192.0.2.255001178943203.0.113.1
16341
203.0.113.2
862
3221212020
[note: '\' line wrapping is for formatting only]
true2001:DB8:10:1:1::1540002001:DB8:10:1:1::25500012322001:DB8:203:0:113::1
16341
2001:DB8:203:0:113::2
862
3222112001:DB8:203:0:113::1540012001:DB8:192:68::2550011789432001:DB8:203:0:113::1
16341
2001:DB8:203:0:113::2
862
3221212020
]]>TWAMP Operational CommandsTWAMP operational commands could be performed programmatically or
manually, e.g. using a command-line interface (CLI).With respect to programmability, YANG can be used to define NETCONF
Remote Procedure Calls (RPC), therefore it would be, in principle,
possible to define TWAMP RPC operations for actions such as starting or
stopping control connections or test sessions or groups of sessions;
retrieving results; clearing stored results, and so on.However, TWAMP does not attempt to
describe such operational actions. Refer also to
and the unlabeled links in . In actual
deployments different TWAMP implementations may support different sets
of operational commands, with different restrictions. Therefore, this
document considers it the responsibility of the individual
implementation to define its corresponding TWAMP operational commands
data model.