< draft-ietf-ippm-twamp-yang-01.txt   draft-ietf-ippm-twamp-yang-02.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: January 9, 2017 AT&T Labs Expires: June 26, 2017 AT&T Labs
R. Rahman R. Rahman
M. Jethanandani M. Jethanandani
Cisco Systems Cisco Systems
K. Pentikousis, Ed. K. Pentikousis, Ed.
Travelping Travelping
L. Zheng L. Zheng
Huawei Technologies Huawei Technologies
July 8, 2016 December 23, 2016
Two-Way Active Measurement Protocol (TWAMP) Data Model Two-Way Active Measurement Protocol (TWAMP) Data Model
draft-ietf-ippm-twamp-yang-01 draft-ietf-ippm-twamp-yang-02
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 We define the TWAMP data model through Unified Modeling Language
(UML) class diagrams and formally specify it using YANG. (UML) class diagrams and formally specify it using YANG.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 9, 2017. This Internet-Draft will expire on June 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 7, line 24 skipping to change at page 7, line 24
TWAMP Server. TWAMP Server.
Each Server is associated with zero or more TWAMP-Control Each Server is associated with zero or more TWAMP-Control
connections. Each control connection is uniquely identified by the connections. Each control connection is uniquely identified by the
4-tuple {Control-Client IP address, Control-Client TCP port number, 4-tuple {Control-Client IP address, Control-Client TCP port number,
Server IP address, Server TCP port}. Control connection configuration Server IP address, Server TCP port}. Control connection configuration
items on a TWAMP Server are read-only. items on a TWAMP Server are read-only.
3.3. Session-Sender 3.3. Session-Sender
A 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 There is one Session-Sender instance for each TWAMP-Test session that
is initiated from the sending device. Primary configuration fields is initiated from the sending device. Primary configuration fields
include: include:
o The test session name that MUST be identical with the o The test session name that MUST be identical with the
corresponding test session name on the TWAMP Control-Client corresponding test session name on the TWAMP Control-Client
(Section 3.1) (Section 3.1)
o The control connection name, which along with the test session o The control connection name, which along with the test session
name uniquely identify the TWAMP Session-Sender instance name uniquely identify the TWAMP Session-Sender instance
o Information pertaining to the test packet stream, such as, for o Information pertaining to the test packet stream, such as, for
example, the number of test packets and the packet distribution to example, the number of test packets and the packet distribution to
be employed; see also [RFC3432]. be employed; see also [RFC3432].
3.4. Session-Reflector 3.4. Session-Reflector
Each 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 Each Session-Reflector is associated with zero or more TWAMP-Test
sessions. For each test session, the REFWAIT parameter (Section 4.2 sessions. For each test session, the REFWAIT parameter (Section 4.2
of [RFC5357] can be configured. of [RFC5357] can be configured.
Read-only access to other data model parameters, such as the Sender Read-only access to other data model parameters, such as the Sender
IP address is foreseen. Each test session can be uniquely identified IP address is foreseen. Each test session can be uniquely identified
by the 4-tuple mentioned in Section 3.2. by the 4-tuple mentioned in Section 3.2.
4. Data Model Parameters 4. Data Model Parameters
skipping to change at page 10, line 37 skipping to change at page 10, line 37
[RFC2898]) MUST be 128-bits for the AES Session-key used for [RFC2898]) MUST be 128-bits for the AES Session-key used for
encryption and a 256-bit HMAC-SHA1 Session-key used for encryption and a 256-bit HMAC-SHA1 Session-key used for
authentication (see Section 6.10 of [RFC4656]). authentication (see Section 6.10 of [RFC4656]).
Each client container also holds a list of ctrl-connections, where Each client container also holds a list of ctrl-connections, where
each item in the list describes a TWAMP control connection that will each item in the list describes a TWAMP control connection that will
be initiated by this Control-Client. There SHALL be one instance of be initiated by this Control-Client. There SHALL be one instance of
ctrl-connection per TWAMP-Control (TCP) connection that is to be ctrl-connection per TWAMP-Control (TCP) connection that is to be
initiated from this device. initiated from this device.
Each ctrl-connection holds a list of test-session-request. test- In turn, each ctrl-connection holds a list of test-session-request.
session-request holds information associated with the Control-Client test-session-request holds information associated with the Control-
for this test session. This includes information that is associated Client for this test session. This includes information that is
with the Request-TW-Session/Accept-Session message exchange (see associated with the Request-TW-Session/Accept-Session message
Section 3.5 of [RFC5357]). exchange (see Section 3.5 of [RFC5357]).
There SHALL be one instance of test-session-request for each TWAMP- There SHALL be one instance of test-session-request for each TWAMP-
Test session that is to be negotiated by this TWAMP-Control Test session that is to be negotiated by this TWAMP-Control
connection via a Request-TW-Session/Accept-Session exchange. connection via a Request-TW-Session/Accept-Session exchange.
The Control-Client is also responsible for scheduling and results The Control-Client is also responsible for scheduling TWAMP-Test
collection for TWAMP-Test sessions, so test-session-request will also sessions and collecting the respective results, so test-session-
hold information related to these actions (e.g. pm-index, repeat- request holds information related to these actions (e.g. pm-index,
interval). repeat-interval).
4.2. Server 4.2. Server
The server container (see Figure 4) holds items that are related to The server container (see Figure 4) holds items that are related to
the configuration of the TWAMP Server logical entity (recall the configuration of the TWAMP Server logical entity (recall
Figure 1). Figure 1).
The server container includes an administrative configuration The server container includes an administrative configuration
parameter (server/admin-state) that indicates whether the device is parameter (server/admin-state) that indicates whether the device is
allowed to receive TWAMP-Control connections. allowed to receive TWAMP-Control connections.
A device operating in the Server role cannot configure attributes on A device operating in the Server role cannot configure attributes on
a per TWAMP-Control connection basis, as it has no foreknowledge of a per TWAMP-Control connection basis, as it has no foreknowledge of
the incoming TWAMP-Control connections to be received. As such, any the incoming TWAMP-Control connections to be received. Consequently,
parameter that the Server might want to apply to an incoming control any parameter that the Server might want to apply to an incoming
connection must be configured at the overall Server level, and will control connection must be configured at the overall Server level and
then be applied to all incoming TWAMP-Control connections. are applied to all incoming TWAMP-Control connections.
+---------------------+ +---------------------+
| server | | server |
+---------------------+ +---------------------+
| admin-state | 1..* +------------+ | admin-state | 1..* +------------+
| server-tcp-port |<>------| key-chain | | server-tcp-port |<>------| key-chain |
| servwait | +------------+ | servwait | +------------+
| control-packet-dscp | | key-id | | control-packet-dscp | | key-id |
| count | | secret-key | | count | | secret-key |
| max-count | +------------+ | max-count | +------------+
skipping to change at page 14, line 7 skipping to change at page 14, line 7
packets are being sent. packets are being sent.
4.4. Session-Reflector 4.4. Session-Reflector
The session-reflector container, illustrated in Figure 6, holds items The session-reflector container, illustrated in Figure 6, holds items
that are related to the configuration of the TWAMP Session-Reflector that are related to the configuration of the TWAMP Session-Reflector
logical entity. logical entity.
The session-reflector container includes an administrative parameter The session-reflector container includes an administrative parameter
(session-reflector/admin-state) that controls whether the device is (session-reflector/admin-state) that controls whether the device is
allowed to respond to incoming TWAMP test sessions. allowed to respond to incoming TWAMP-Test sessions.
A device operating in the Session-Reflector role cannot configure A device operating in the Session-Reflector role cannot configure
attributes on a per-session basis, as it has no foreknowledge of what attributes on a per-session basis, as it has no foreknowledge of what
incoming sessions it will receive. As such, any parameter that the incoming sessions it will receive. As such, any parameter that the
Session-Reflector might want to apply to an incoming TWAMP-Test Session-Reflector might want to apply to an incoming TWAMP-Test
session must be configured at the overall Session-Reflector level, session must be configured at the overall Session-Reflector level and
and will then be applied to all incoming sessions. are applied to all incoming sessions.
+----=--------------+ +----=--------------+
| session-reflector | | session-reflector |
+-------------------+ +-------------------+
| admin-state | | admin-state |
| refwait | | refwait |
+-------------------+ +-------------------+
^ ^
V V
| |
skipping to change at page 18, line 20 skipping to change at page 18, line 20
+--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
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. defined in this document.
<CODE BEGINS> file "ietf-twamp@2016-07-07.yang" <CODE BEGINS> file "2016-12-23"
module ietf-twamp { module ietf-twamp {
//namespace need to be assigned by IANA //namespace need to be assigned by IANA
namespace namespace
urn:ietf:params:xml:ns:yang:ietf-twamp; urn:ietf:params:xml:ns:yang:ietf-twamp;
prefix prefix
ietf-twamp; ietf-twamp;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
skipping to change at page 19, line 23 skipping to change at page 19, line 23
/* /*
* Typedefs * Typedefs
*/ */
typedef twamp-modes { typedef twamp-modes {
type bits { type bits {
bit unauthenticated { bit unauthenticated {
position 0; position 0;
description description
"Unauthenticated mode. See RFC 7717 Section 7."; "Unauthenticated mode, in which no encryption or
authentication is applied. See RFC 7717 Section 7.";
} }
bit authenticated { bit authenticated {
position 1; position 1;
description description
"Authenticated mode. See RFC 7717 Section 7."; "Authenticated mode. See RFC 7717 Section 7
and RFC 4656 Section 6.";
} }
bit encrypted { bit encrypted {
position 2; position 2;
description description
"Encrypted mode. See RFC 7717 Section 7."; "Encrypted mode. See RFC 7717 Section 7 and
RFC 4656 Section 6.";
} }
bit unauth-test-encrpyt-control { bit unauth-test-encrpyt-control {
position 3; position 3;
description description
"Mixed Security Mode: TWAMP-Test protocol security "Mixed Security Mode: TWAMP-Test protocol security
mode in Unauthenticated mode, TWAMP-Control protocol mode in Unauthenticated mode, TWAMP-Control protocol
in Encrypted mode."; in Encrypted mode.";
reference reference
"RFC 5618: Mixed Security Mode for the Two-Way Active "RFC 5618: Mixed Security Mode for the Two-Way Active
Measurement Protocol (TWAMP)"; Measurement Protocol (TWAMP)";
skipping to change at page 53, line 27 skipping to change at page 53, line 27
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,
<http://www.rfc-editor.org/info/rfc7717>. <http://www.rfc-editor.org/info/rfc7717>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ippm-metric-registry] [I-D.ietf-ippm-metric-registry]
Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", draft-ietf- Akhter, "Registry for Performance Metrics", draft-ietf-
ippm-metric-registry-06 (work in progress), March 2016. ippm-metric-registry-10 (work in progress), November 2016.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-15 (work in Protocol", draft-ietf-netconf-restconf-18 (work in
progress), July 2016. progress), October 2016.
[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-03 (work in progress), January 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.,
Papafili, I., Pentikousis, K., and S. Wright, "DevOps for Pentikousis, K., Wright, S., Lynch, P., and W. John,
Software-Defined Telecom Infrastructures", draft-unify- "DevOps for Software-Defined Telecom Infrastructures",
nfvrg-devops-04 (work in progress), March 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.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, Specification Version 2.0", RFC 2898,
DOI 10.17487/RFC2898, September 2000, DOI 10.17487/RFC2898, September 2000,
<http://www.rfc-editor.org/info/rfc2898>. <http://www.rfc-editor.org/info/rfc2898>.
 End of changes. 19 change blocks. 
31 lines changed or deleted 42 lines changed or added

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