--- 1/draft-ietf-ippm-twamp-yang-01.txt 2016-12-23 08:13:13.995611497 -0800 +++ 2/draft-ietf-ippm-twamp-yang-02.txt 2016-12-23 08:13:14.107613875 -0800 @@ -1,26 +1,26 @@ IPPM WG R. Civil Internet-Draft Ciena Corporation Intended status: Standards Track A. Morton -Expires: January 9, 2017 AT&T Labs +Expires: June 26, 2017 AT&T Labs R. Rahman M. Jethanandani Cisco Systems K. Pentikousis, Ed. Travelping L. Zheng Huawei Technologies - July 8, 2016 + December 23, 2016 Two-Way Active Measurement Protocol (TWAMP) Data Model - draft-ietf-ippm-twamp-yang-01 + draft-ietf-ippm-twamp-yang-02 Abstract This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). We define the TWAMP data model through Unified Modeling Language (UML) class diagrams and formally specify it using YANG. Status of This Memo @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -287,37 +287,45 @@ 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. 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 is initiated from the sending device. Primary configuration fields include: o The test session name that MUST be identical with the corresponding test session name on the TWAMP Control-Client (Section 3.1) o The control connection name, which along with the test session name uniquely identify the TWAMP Session-Sender instance o Information pertaining to the test packet stream, such as, for example, the number of test packets and the packet distribution to be employed; see also [RFC3432]. 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 sessions. For each test session, the REFWAIT parameter (Section 4.2 of [RFC5357] 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 Section 3.2. 4. Data Model Parameters @@ -407,51 +415,51 @@ [RFC2898]) MUST be 128-bits for the AES Session-key used for encryption and a 256-bit HMAC-SHA1 Session-key used for authentication (see Section 6.10 of [RFC4656]). Each client container also holds a list of ctrl-connections, where each item in the list describes a TWAMP control connection that will be initiated by this Control-Client. There SHALL be one instance of ctrl-connection per TWAMP-Control (TCP) connection that is to be initiated from this device. - Each ctrl-connection holds a list of test-session-request. test- - session-request holds information associated with the Control-Client - for this test session. This includes information that is associated - with the Request-TW-Session/Accept-Session message exchange (see - Section 3.5 of [RFC5357]). + In turn, each ctrl-connection holds a list of test-session-request. + test-session-request holds information associated with the Control- + Client for this test session. This includes information that is + associated with the Request-TW-Session/Accept-Session message + exchange (see Section 3.5 of [RFC5357]). 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 and results - collection for TWAMP-Test sessions, so test-session-request will also - hold information related to these actions (e.g. pm-index, repeat- - interval). + The Control-Client is also responsible for scheduling TWAMP-Test + sessions and collecting the respective results, so test-session- + request holds information related to these actions (e.g. pm-index, + repeat-interval). 4.2. Server The server container (see Figure 4) holds items that are related to the configuration of the TWAMP Server logical entity (recall Figure 1). 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. As such, any - parameter that the Server might want to apply to an incoming control - connection must be configured at the overall Server level, and will - then be applied to all incoming TWAMP-Control connections. + 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 + are applied to all incoming TWAMP-Control connections. +---------------------+ | server | +---------------------+ | admin-state | 1..* +------------+ | server-tcp-port |<>------| key-chain | | servwait | +------------+ | control-packet-dscp | | key-id | | count | | secret-key | | max-count | +------------+ @@ -549,28 +557,28 @@ packets are being sent. 4.4. Session-Reflector The session-reflector container, illustrated in Figure 6, 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. + 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 will then be applied to all incoming sessions. + session must be configured at the overall Session-Reflector level and + are applied to all incoming sessions. +----=--------------+ | session-reflector | +-------------------+ | admin-state | | refwait | +-------------------+ ^ V | @@ -755,21 +763,21 @@ +--ro sent-packets? uint32 +--ro rcv-packets? uint32 +--ro last-sent-seq? uint32 +--ro last-rcv-seq? uint32 5.2. YANG Module This section presents the YANG module for the TWAMP data model defined in this document. - file "ietf-twamp@2016-07-07.yang" + file "2016-12-23" module ietf-twamp { //namespace need to be assigned by IANA namespace urn:ietf:params:xml:ns:yang:ietf-twamp; prefix ietf-twamp; import ietf-inet-types { prefix inet; @@ -804,31 +812,34 @@ /* * Typedefs */ typedef twamp-modes { type bits { bit unauthenticated { position 0; 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 { position 1; description - "Authenticated mode. See RFC 7717 Section 7."; + "Authenticated mode. See RFC 7717 Section 7 + and RFC 4656 Section 6."; } bit encrypted { position 2; 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 { position 3; description "Mixed Security Mode: TWAMP-Test protocol security mode in Unauthenticated mode, TWAMP-Control protocol in Encrypted mode."; reference "RFC 5618: Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)"; @@ -2421,38 +2431,38 @@ Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7717, DOI 10.17487/RFC7717, December 2015, . 10.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-06 (work in progress), March 2016. + ippm-metric-registry-10 (work in progress), November 2016. [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF - Protocol", draft-ietf-netconf-restconf-15 (work in - progress), July 2016. + Protocol", draft-ietf-netconf-restconf-18 (work in + progress), October 2016. [I-D.unify-nfvrg-challenges] Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino, D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud 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] Meirosu, C., Manzalini, A., Steinert, R., Marchetto, G., - Papafili, I., Pentikousis, K., and S. Wright, "DevOps for - Software-Defined Telecom Infrastructures", draft-unify- - nfvrg-devops-04 (work in progress), March 2016. + Pentikousis, K., Wright, S., Lynch, P., and W. John, + "DevOps for Software-Defined Telecom Infrastructures", + draft-unify-nfvrg-devops-06 (work in progress), July 2016. [NSC] John, W., Pentikousis, K., et al., "Research directions in network service chaining", Proc. SDN for Future Networks and Services (SDN4FNS), Trento, Italy IEEE, November 2013. [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, DOI 10.17487/RFC2898, September 2000, .