draft-ietf-ippm-twamp-yang-08.txt   draft-ietf-ippm-twamp-yang-09.txt 
IPPM WG R. Civil IPPM WG R. Civil
Internet-Draft Ciena Corporation Internet-Draft Ciena Corporation
Intended status: Standards Track A. Morton Intended status: Standards Track A. Morton
Expires: October 16, 2018 AT&T Labs Expires: October 22, 2018 AT&T Labs
R. Rahman R. Rahman
Cisco Systems Cisco Systems
M. Jethanandani M. Jethanandani
K. Pentikousis, Ed. K. Pentikousis, Ed.
Travelping Travelping
April 14, 2018 April 20, 2018
Two-Way Active Measurement Protocol (TWAMP) Data Model Two-Way Active Measurement Protocol (TWAMP) Data Model
draft-ietf-ippm-twamp-yang-08 draft-ietf-ippm-twamp-yang-09
Abstract Abstract
This document specifies a data model for client and server This document specifies a data model for client and server
implementations of the Two-Way Active Measurement Protocol (TWAMP). implementations of the Two-Way Active Measurement Protocol (TWAMP).
We define the TWAMP data model through Unified Modeling Language The document defines the TWAMP data model through Unified Modeling
(UML) class diagrams and formally specify it using YANG. Language (UML) class diagrams and formally specifies it using YANG.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 16, 2018. This Internet-Draft will expire on October 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48 6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48
6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51 6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51
6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52 6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52
7. Security Considerations . . . . . . . . . . . . . . . . . . . 55 7. Security Considerations . . . . . . . . . . . . . . . . . . . 55
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.1. Normative References . . . . . . . . . . . . . . . . . . 57 11.1. Normative References . . . . . . . . . . . . . . . . . . 57
11.2. Informative References . . . . . . . . . . . . . . . . . 58 11.2. Informative References . . . . . . . . . . . . . . . . . 59
Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60 Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60
A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60 A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 63 A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 64
A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 64 A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 64
Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67 Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction 1. Introduction
The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to
measure network performance parameters such as latency, bandwidth, measure network performance parameters such as latency, bandwidth,
and packet loss by sending probe packets and measuring their and packet loss by sending probe packets and measuring their
experience in the network. To date, TWAMP implementations do not experience in the network. To date, TWAMP implementations do not
skipping to change at page 3, line 24 skipping to change at page 3, line 24
model using YANG [RFC7950]. model using YANG [RFC7950].
1.1. Motivation 1.1. Motivation
In current TWAMP deployments the lack of a standardized data model In current TWAMP deployments the lack of a standardized data model
limits the flexibility to dynamically instantiate TWAMP-based limits the flexibility to dynamically instantiate TWAMP-based
measurements across equipment from different vendors. In large, measurements across equipment from different vendors. In large,
virtualized, and dynamically instantiated infrastructures where virtualized, and dynamically instantiated infrastructures where
network functions are placed according to orchestration algorithms as network functions are placed according to orchestration algorithms as
discussed in Unifying Carrier and Cloud Networks: Problem Statement discussed in Unifying Carrier and Cloud Networks: Problem Statement
and Challenges [I-D.unify-nfvrg-challenges]DevOps For Software- and Challenges [I-D.unify-nfvrg-challenges], and DevOps For Software-
Defined Telecom Infrastructures [I-D.unify-nfvrg-devops], proprietary Defined Telecom Infrastructures [I-D.unify-nfvrg-devops], proprietary
mechanisms for managing TWAMP measurements pose severe limitations mechanisms for managing TWAMP measurements pose severe limitations
with respect to programmability. with respect to programmability.
Two major trends call for standardizing TWAMP management aspects. Two major trends call for standardizing TWAMP management aspects.
First, we expect that in the coming years large-scale and multi- First, it is expected that in the coming years large-scale and multi-
vendor TWAMP deployments will become the norm. From an operations vendor TWAMP deployments will become the norm. From an operations
perspective, using several vendor-specific TWAMP configuration perspective, using several vendor-specific TWAMP configuration
mechanisms when one standard mechanism could provide an alternative mechanisms when one standard mechanism could provide an alternative
is expensive and inefficient. Second, the increasingly software- is expensive and inefficient. Second, the increasingly software-
defined and virtualized nature of network infrastructures, based on defined and virtualized nature of network infrastructures, based on
dynamic service chains [NSC] and programmable control and management dynamic service chains [NSC] and programmable control and management
planes Software-Defined Networking (SDN): Layers and Architecture planes Software-Defined Networking (SDN): Layers and Architecture
Terminology [RFC7426] requires a well-defined data model for TWAMP Terminology [RFC7426] requires a well-defined data model for TWAMP
implementations. This document defines such a TWAMP data model and implementations. This document defines such a TWAMP data model and
specifies it formally using the YANG [RFC7950] data modeling specifies it formally using the YANG [RFC7950] data modeling
language. language.
Note to RFC Editor: Note to RFC Editor:
Please replace the date 2018-04-16 in Section 5.2 of the draft with Please replace the date 2018-04-19 in Section 5.2 of the draft with
the date of publication of this draft as a RFC. Also, replace the date of publication of this draft as a RFC. Also, replace
reference to RFC XXXX, and draft-ietf-port-twamp-test with the RFC reference to RFC XXXX, and draft-ietf-port-twamp-test with the RFC
numbers assigned to the drafts. numbers assigned to the drafts.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at page 5, line 38 skipping to change at page 5, line 38
Figure 2: Simplified TWAMP model and protocols Figure 2: Simplified TWAMP model and protocols
The data model defined in this document is orthogonal to the specific The data model defined in this document is orthogonal to the specific
protocol used between the Config client and Config server to protocol used between the Config client and Config server to
communicate the TWAMP configuration parameters. communicate the TWAMP configuration parameters.
Operational actions such as how TWAMP-Test sessions are started and Operational actions such as how TWAMP-Test sessions are started and
stopped, how performance measurement results are retrieved, or how stopped, how performance measurement results are retrieved, or how
stored results are cleared, and so on, are not addressed by the stored results are cleared, and so on, are not addressed by the
configuration model defined in this document. As noted above, such configuration model defined in this document. As noted above, such
operational actions are not part of the TWAMP specification TWAMP operational actions are not part of the TWAMP [RFC5357]
[RFC5357] and hence are out of scope of this document. See also specification, and hence are out of scope of this document. See also
Appendix B. Appendix B.
3. Data Model Overview 3. Data Model Overview
The TWAMP data model includes four categories of configuration items. The TWAMP data model includes four categories of configuration items.
First, global configuration items relate to parameters that are set First, global configuration items relate to parameters that are set
on a per device level. For example, the administrative status of the on a per device level. For example, the administrative status of the
device with respect to whether it allows TWAMP sessions and, if so, 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 in what capacity (e.g. Control-Client, Server or both), is a typical
skipping to change at page 6, line 15 skipping to change at page 6, line 15
A second category includes attributes that can be configured on a per A second category includes attributes that can be configured on a per
TWAMP-Control connection basis, such as the Server IP address. TWAMP-Control connection basis, such as the Server IP address.
A third category includes attributes related to per TWAMP-Test A third category includes attributes related to per TWAMP-Test
session attributes, for instance setting different values in the session attributes, for instance setting different values in the
Differentiated Services Code Point (DSCP) field. Differentiated Services Code Point (DSCP) field.
Finally, the data model includes attributes that relate to the Finally, the data model includes attributes that relate to the
operational state of the TWAMP implementation. operational state of the TWAMP implementation.
As we describe the TWAMP data model in the remaining sections of this As the TWAMP data model is described in the remaining sections of
document, readers should keep in mind the functional entity grouping this document, readers should keep in mind the functional entity
illustrated in Figure 1. grouping illustrated in Figure 1.
3.1. Control-Client 3.1. Control-Client
A TWAMP Control-Client has an administrative status field set at the A TWAMP Control-Client has an administrative status field set at the
device level that indicates whether the node is enabled to function device level that indicates whether the node is enabled to function
as such. as such.
Each TWAMP Control-Client is associated with zero or more TWAMP- Each TWAMP Control-Client is associated with zero or more TWAMP-
Control connections. The main configuration parameters of each Control connections. The main configuration parameters of each
control connection are: control connection are:
skipping to change at page 6, line 47 skipping to change at page 6, line 47
connections. connections.
o The IP address of the remote TWAMP Server. o The IP address of the remote TWAMP Server.
o Authentication and encryption attributes such as KeyID, Token and o Authentication and encryption attributes such as KeyID, Token and
the Client Initialization Vector (Client-IV); see also the last the Client Initialization Vector (Client-IV); see also the last
paragraph of Section 6 in OWAMP [RFC4656] and Randomness paragraph of Section 6 in OWAMP [RFC4656] and Randomness
Requirements for Security [RFC4086]. Requirements for Security [RFC4086].
Each TWAMP-Control connection, in turn, is associated with zero or Each TWAMP-Control connection, in turn, is associated with zero or
more TWAMP-Test sessions. For each test session we note the more TWAMP-Test sessions. For each test session, the following
following configuration items: configuration items should be noted:
o The test session name that uniquely identifies a particular test o The test session name that uniquely identifies a particular test
session at the Control-Client and Session-Sender. Similarly to session at the Control-Client and Session-Sender. Similarly to
the control connections above, this unique test session name is the control connections above, this unique test session name is
needed because at the time of creation of a TWAMP-Test session, needed because at the time of creation of a TWAMP-Test session,
for example, the source UDP port number is not known to uniquely for example, the source UDP port number is not known to uniquely
identify the test session. identify the test session.
o The IP address and UDP port number of the Session-Sender on the o The IP address and UDP port number of the Session-Sender on the
path under test by TWAMP. path under test by TWAMP.
skipping to change at page 9, line 48 skipping to change at page 9, line 48
| pm-index | | sid {ro} | | pm-index | | sid {ro} |
+-------------+ +----------------------+ +-------------+ +----------------------+
Figure 3: TWAMP Control-Client UML class diagram Figure 3: TWAMP Control-Client UML class diagram
The client container holds a list (mode-preference-chain) which The client container holds a list (mode-preference-chain) which
specifies the Mode values according to their preferred order of use specifies the Mode values according to their preferred order of use
by the operator of this Control-Client, including the authentication by the operator of this Control-Client, including the authentication
and encryption Modes. Specifically, mode-preference-chain lists the and encryption Modes. Specifically, mode-preference-chain lists the
mode and its corresponding priority, expressed as a 16-bit unsigned mode and its corresponding priority, expressed as a 16-bit unsigned
integer, where zero is the highest priority and subsequent values are integer, where zero is the highest priority and subsequent integers
monotonically increasing. increase by one.
Depending on the Modes available in the Server Greeting, the Control- Depending on the Modes available in the Server Greeting, the Control-
Client MUST choose the highest priority Mode from the configured Client MUST choose the highest priority Mode from the configured
mode-preference-chain list. mode-preference-chain list.
Note that the list of preferred Modes may set bit position Note that the list of preferred Modes may set bit position
combinations when necessary, such as when referring to the extended combinations when necessary, such as when referring to the extended
TWAMP features in Mixed Security Mode for TWAMP [RFC5618], Individual TWAMP features in Mixed Security Mode for TWAMP [RFC5618], Individual
Session Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and Session Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and
Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret
skipping to change at page 17, line 4 skipping to change at page 17, line 4
| +--rw key-chain* [key-id] | +--rw key-chain* [key-id]
| | +--rw key-id string | | +--rw key-id string
| | +--rw secret-key? string | | +--rw secret-key? string
| +--rw ctrl-connection* [name] | +--rw ctrl-connection* [name]
| +--rw name string | +--rw name string
| +--rw client-ip? inet:ip-address | +--rw client-ip? inet:ip-address
| +--rw server-ip inet:ip-address | +--rw server-ip inet:ip-address
| +--rw server-tcp-port? inet:port-number | +--rw server-tcp-port? inet:port-number
| +--rw control-packet-dscp? inet:dscp | +--rw control-packet-dscp? inet:dscp
| +--rw key-id? string | +--rw key-id? string
| +--rw max-count? uint8 | +--rw max-count-exponent? uint8
| +--ro client-tcp-port? inet:port-number | +--ro client-tcp-port? inet:port-number
| +--ro server-start-time? uint64 | +--ro server-start-time? uint64
| +--ro repeat-count? uint64 | +--ro repeat-count? uint64
| +--ro state? | +--ro state?
| | control-client-connection-state | | control-client-connection-state
| +--ro selected-mode? twamp-modes | +--ro selected-mode? twamp-modes
| +--ro token? binary | +--ro token? binary
| +--ro client-iv? binary | +--ro client-iv? binary
| +--rw test-session-request* [name] | +--rw test-session-request* [name]
| +--rw name string | +--rw name string
skipping to change at page 17, line 35 skipping to change at page 17, line 35
| +--rw pm-reg-list* [pm-index] | +--rw pm-reg-list* [pm-index]
| | +--rw pm-index uint16 | | +--rw pm-index uint16
| +--ro state? test-session-state | +--ro state? test-session-state
| +--ro sid? string | +--ro sid? string
+--rw server {server}? +--rw server {server}?
| +--rw admin-state? boolean | +--rw admin-state? boolean
| +--rw server-tcp-port? inet:port-number | +--rw server-tcp-port? inet:port-number
| +--rw servwait? uint32 | +--rw servwait? uint32
| +--rw control-packet-dscp? inet:dscp | +--rw control-packet-dscp? inet:dscp
| +--rw count? uint8 | +--rw count? uint8
| +--rw max-count? uint8 | +--rw max-count-exponent? uint8
| +--rw modes? twamp-modes | +--rw modes? twamp-modes
| +--rw key-chain* [key-id] | +--rw key-chain* [key-id]
| | +--rw key-id string | | +--rw key-id string
| | +--rw secret-key? string | | +--rw secret-key? string
| +--ro ctrl-connection* | +--ro ctrl-connection*
| [client-ip client-tcp-port server-ip server-tcp-port] | [client-ip client-tcp-port server-ip server-tcp-port]
| +--ro client-ip inet:ip-address | +--ro client-ip inet:ip-address
| +--ro client-tcp-port inet:port-number | +--ro client-tcp-port inet:port-number
| +--ro server-ip inet:ip-address | +--ro server-ip inet:ip-address
| +--ro server-tcp-port inet:port-number | +--ro server-tcp-port inet:port-number
| +--ro state? server-ctrl-connection-state | +--ro state? server-ctrl-connection-state
| +--ro control-packet-dscp? inet:dscp | +--ro control-packet-dscp? inet:dscp
| +--ro selected-mode? twamp-modes | +--ro selected-mode? twamp-modes
| +--ro key-id? string | +--ro key-id? string
| +--ro count? uint8 | +--ro count? uint8
| +--ro max-count? uint8 | +--ro max-count-exponent? uint8
| +--ro salt? binary | +--ro salt? binary
| +--ro server-iv? binary | +--ro server-iv? binary
| +--ro challenge? binary | +--ro challenge? binary
+--rw session-sender {session-sender}? +--rw session-sender {session-sender}?
| +--rw admin-state? boolean | +--rw admin-state? boolean
| +--rw test-session* [name] | +--rw test-session* [name]
| +--rw name string | +--rw name string
| +--ro ctrl-connection-name? string | +--ro ctrl-connection-name? string
| +--rw fill-mode? padding-fill-mode | +--rw fill-mode? padding-fill-mode
| +--rw number-of-packets uint32 | +--rw number-of-packets uint32
skipping to change at page 19, line 8 skipping to change at page 19, line 8
+--ro sent-packets? uint32 +--ro sent-packets? uint32
+--ro rcv-packets? uint32 +--ro rcv-packets? uint32
+--ro last-sent-seq? uint32 +--ro last-sent-seq? uint32
+--ro last-rcv-seq? uint32 +--ro last-rcv-seq? uint32
Figure 7: YANG Tree Diagram. Figure 7: YANG Tree Diagram.
5.2. YANG Module 5.2. YANG Module
This section presents the YANG module for the TWAMP data model This section presents the YANG module for the TWAMP data model
defined in this document. The module imports definitions from NTPv3 defined in this document. The module imports definitions from Common
Specification [RFC1305], Randomness Requirements for Security YANG Data Types [RFC6991], and references NTPv3 Specification
[RFC4086], OWAMP [RFC4656], TWAMP [RFC5357], More Features for TWAMP [RFC1305], Framework for IP Performance Metrics [RFC2330], Randomness
[RFC5618], Individual Session Control Feature [RFC5938], TWAMP Requirements for Security [RFC4086], OWAMP [RFC4656], TWAMP
Reflect Octets and Symmetrical Size Features [RFC6038], Common YANG [RFC5357], More Features for TWAMP [RFC5618], Individual Session
Data Types [RFC6991], Advances Stream and Sampling Framework Control Feature [RFC5938], TWAMP Reflect Octets and Symmetrical Size
[RFC7312], IKEv2-Derived Shared Secret Key for OWAMP and TWAMP Features [RFC6038], Advances Stream and Sampling Framework [RFC7312],
[RFC7717], and OWAMP and TWAMP Well-Known Port Assignments IKEv2-Derived Shared Secret Key for OWAMP and TWAMP [RFC7717], and
OWAMP and TWAMP Well-Known Port Assignments
[I-D.ietf-ippm-port-twamp-test]. [I-D.ietf-ippm-port-twamp-test].
<CODE BEGINS> file "ietf-twamp@2018-04-16.yang" <CODE BEGINS> file "ietf-twamp@2018-04-19.yang"
module ietf-twamp { module ietf-twamp {
yang-version 1.1; yang-version 1.1;
namespace urn:ietf:params:xml:ns:yang:ietf-twamp; namespace urn:ietf:params:xml:ns:yang:ietf-twamp;
prefix ietf-twamp; prefix ietf-twamp;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Types."; "RFC 6991: Common YANG Types.";
skipping to change at page 20, line 25 skipping to change at page 20, line 26
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2018-04-16 { revision 2018-04-19 {
description description
"Initial Revision. "Initial Revision.
Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and
draft-ietf-ippm-metric-registry"; draft-ietf-ippm-metric-registry";
reference reference
"RFC XXXX: TWAMP YANG Data Model."; "RFC XXXX: TWAMP YANG Data Model.";
} }
skipping to change at page 27, line 31 skipping to change at page 27, line 32
by providing said power. For example, configuring 15 here by providing said power. For example, configuring 15 here
means count 2^15 = 32768. The default is 10, means count 2^15 = 32768. The default is 10,
meaning 2^10 = 1024."; meaning 2^10 = 1024.";
} }
description description
"Reusable data structure for count, which is used both in the "Reusable data structure for count, which is used both in the
Server and the Control-Client."; Server and the Control-Client.";
} }
grouping max-count-exponent { grouping max-count-exponent {
leaf max-count { leaf max-count-exponent {
type uint8 { type uint8 {
range 10..31; range 10..31;
} }
default 15; default 15;
description description
"This parameter limits the maximum Count value, which MUST "This parameter limits the maximum Count value, which MUST
be a power of 2 and at least 1024 as per RFC 5357. It is be a power of 2 and at least 1024 as per RFC 5357. It is
configured by providing said power. For example, configured by providing said power. For example,
configuring 10 here means max count 2^10 = 1024. configuring 10 here means max count 2^10 = 1024.
The default is 15, meaning 2^15 = 32768. The default is 15, meaning 2^15 = 32768.
skipping to change at page 28, line 12 skipping to change at page 28, line 14
Further, note that according to Section 6 of RFC 5357: Further, note that according to Section 6 of RFC 5357:
'If an attacking system sets the maximum value in 'If an attacking system sets the maximum value in
Count (2**32), then the system under attack would stall Count (2**32), then the system under attack would stall
for a significant period of time while it attempts to for a significant period of time while it attempts to
generate keys. generate keys.
TWAMP-compliant systems SHOULD have a configuration TWAMP-compliant systems SHOULD have a configuration
control to limit the maximum count value. The default control to limit the maximum count value. The default
max-count value SHOULD be 32768.' max-count-exponent value SHOULD be 15 which corresponds
to a maximum value of 2**15 or 32768.'
RFC 5357 does not qualify 'significant period' in terms of RFC 5357 does not qualify 'significant period' in terms of
time, but it is clear that this depends on the processing time, but it is clear that this depends on the processing
capacity available and operators need to pay attention to capacity available and operators need to pay attention to
this security consideration."; this security consideration.";
} }
description description
"Reusable data structure for max-count which is used both at "Reusable data structure for max-count which is used both at
the Control-Client and the Server containers."; the Control-Client and the Server containers.";
} }
skipping to change at page 57, line 9 skipping to change at page 57, line 9
may be made of the information in this document. may be made of the information in this document.
10. Contributors 10. Contributors
Lianshu Zheng. Lianshu Zheng.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ippm-metric-registry]
Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", draft-ietf-
ippm-metric-registry-14 (work in progress), March 2018.
[I-D.ietf-ippm-port-twamp-test] [I-D.ietf-ippm-port-twamp-test]
Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port
Assignments", draft-ietf-ippm-port-twamp-test-01 (work in Assignments", draft-ietf-ippm-port-twamp-test-01 (work in
progress), March 2018. progress), March 2018.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305, Specification, Implementation and Analysis", RFC 1305,
DOI 10.17487/RFC1305, March 1992, DOI 10.17487/RFC1305, March 1992,
<https://www.rfc-editor.org/info/rfc1305>. <https://www.rfc-editor.org/info/rfc1305>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
DOI 10.17487/RFC3432, November 2002, DOI 10.17487/RFC3432, November 2002,
<https://www.rfc-editor.org/info/rfc3432>. <https://www.rfc-editor.org/info/rfc3432>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>. <https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008, RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>. <https://www.rfc-editor.org/info/rfc5357>.
skipping to change at page 58, line 25 skipping to change at page 58, line 40
"IKEv2-Derived Shared Secret Key for the One-Way Active "IKEv2-Derived Shared Secret Key for the One-Way Active
Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)", RFC 7717, Measurement Protocol (TWAMP)", RFC 7717,
DOI 10.17487/RFC7717, December 2015, DOI 10.17487/RFC7717, December 2015,
<https://www.rfc-editor.org/info/rfc7717>. <https://www.rfc-editor.org/info/rfc7717>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
Password-Based Cryptography Specification Version 2.1",
RFC 8018, DOI 10.17487/RFC8018, January 2017,
<https://www.rfc-editor.org/info/rfc8018>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-ippm-metric-registry]
Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", draft-ietf-
ippm-metric-registry-14 (work in progress), March 2018.
[I-D.unify-nfvrg-challenges] [I-D.unify-nfvrg-challenges]
Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino, Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino,
D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud
Networks: Problem Statement and Challenges", draft-unify- Networks: Problem Statement and Challenges", draft-unify-
nfvrg-challenges-04 (work in progress), July 2016. nfvrg-challenges-04 (work in progress), July 2016.
[I-D.unify-nfvrg-devops] [I-D.unify-nfvrg-devops]
Meirosu, C., Manzalini, A., Steinert, R., Marchetto, G., Meirosu, C., Manzalini, A., Steinert, R., Marchetto, G.,
Pentikousis, K., Wright, S., Lynch, P., and W. John, Pentikousis, K., Wright, S., Lynch, P., and W. John,
"DevOps for Software-Defined Telecom Infrastructures", "DevOps for Software-Defined Telecom Infrastructures",
draft-unify-nfvrg-devops-06 (work in progress), July 2016. draft-unify-nfvrg-devops-06 (work in progress), July 2016.
[NSC] John, W., Pentikousis, K., et al., "Research directions in [NSC] John, W., Pentikousis, K., et al., "Research directions in
network service chaining", Proc. SDN for Future Networks network service chaining", Proc. SDN for Future Networks
and Services (SDN4FNS), Trento, Italy IEEE, November 2013. and Services (SDN4FNS), Trento, Italy IEEE, November 2013.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the
Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
DOI 10.17487/RFC5618, August 2009, DOI 10.17487/RFC5618, August 2009,
<https://www.rfc-editor.org/info/rfc5618>. <https://www.rfc-editor.org/info/rfc5618>.
skipping to change at page 59, line 40 skipping to change at page 60, line 5
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
Password-Based Cryptography Specification Version 2.1",
RFC 8018, DOI 10.17487/RFC8018, January 2017,
<https://www.rfc-editor.org/info/rfc8018>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
 End of changes. 29 change blocks. 
50 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/