Internet Engineering Task Force (IETF) A. Morton Request for Comments: 5938 AT&T Labs Updates: 5357 M. Chiba Category: Standards Track Cisco Systems ISSN: 2070-1721 August 2010 Individual Session Control Feature
销售客服for the Two-Way Active Measurement Protocol (TWAMP)
Abstract
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 ssions using Session Identifiers. The ba capability of the TWAMP protocol
requires all test ssions that were previously requested and
accepted to start and stop at the same time.
Status of This Memo
公务员法实施细则This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It reprents the connsus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
www.rfc-editor/info/rfc5938.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights rerved.
This document is subject to BCP 78 and the IETF Trust’s Legal
Provisions Relating to IETF Documents
(trustee.ietf/licen-info) in effect on the date of
publication of this document. Plea review the documents
carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD Licen text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD Licen.
Morton & Chiba Standards Track [Page 1]
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate licen from the person(s) controlling the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format儿童书
it for publication as an RFC or to translate it into languages other than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Purpo and Scope . . . . . . . . . . . . . . . . . . . . . . 4
3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 4 3.1. Connection Setup with Individual Session Control . . . . . 5 3.2. Start-N-Sessions Command with Individual Session
Control . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Start-N-Ack Command with Individual Session Control . . . 7 3.4. Stop-N-Sessions Command with Individual Session Control . 9 3.5. Stop-N-Ack Command with Individual Session Control . . . . 10 3.6. SERVWAIT Timeout Operation . . . . . . . . . . . . . . . . 12
3.7. Additional Considerations . . . . . . . . . . . . . . . . 12
4. TWAMP Test with Individual Session Control . . . . . . . . . . 13 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 13
4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 14 6.2. Registry Management . . . . . . . . . . . . . . . . . . . 14 6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 15
6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Morton & Chiba Standards Track [Page 2]
1. Introduction
The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol [RFC5357]. TWAMP is an
extension of the One-way Active Measurement Protocol, OWAMP
[RFC4656]. The TWAMP specification gathered wide review as it
approached completion, and the by-products were veral
recommendations for new features in TWAMP. There are a growing
number of TWAMP implementations at prent, and widespread usage is
expected. There are even devices that are designed to test
implementations for protocol compliance.
This memo describes an OPTIONAL feature for TWAMP. [RFC5357] TWAMP
(and OWAMP) start all previously requested and accepted test ssions at once. This feature allows the Control-Client to control
individual test ssions on the basis of their Session Identifier
(SID). This feature permits a short-duration TWAMP test to start
城南旧事好词
(and/or stop) during a longer test. This feature permits a specific diagnostic test to begin if intermediate results indicate that the
test is warranted, for example.
This feature requires a Modes field bit position assignment and the
u of two new TWAMP command numbers (for the augmented Start and
Stop commands). This feature also specifies the u of a new Stop-N- ACK Server respon, to complete the symmetry of the ssion-stopping process in the same way as the Start-ACK (Start-N-ACK when ud with this feature) respon.
The Individual Session Control feature gives the Control-Client new
flexibility to manage any number of test ssions once they are
established. However, [RFC5357] test ssions are established in
rial order and the total establishment time grows with the number
of ssions and the round-trip time. Therefore, implementers of this feature may also wish to implement the "Reflect Octets" feature,
described in [REFLECT]. This feature allows a Control-Client to
distinguish between parallel Request-TW-Session commands becau a
participating Server can return octets (e.g., the Control-Client’s
local index) in its reply to the request. Thus, the Reflect Octets
feature supports the efficient establishment of many simultaneous
test ssions that the Individual Session Control feature can then
manage (start/stop).
This memo is an update to the TWAMP core protocol specified in
[RFC5357]. Measurement systems are not required to implement the
feature described in this memo to claim compliance with [RFC5357]. Morton & Chiba Standards Track [Page 3]
Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be t to zero by nders and MUST be ignored by receivers. Also, the HMAC (Hashed Message Authentication Code) MUST be calculated as defined in Section 3.2 of [RFC4656].
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
2. Purpo and Scope
The purpo of this memo is to describe an additional OPTIONAL
function and feature for TWAMP [RFC5357].
The scope of the memo is limited to specifications of the following
features:
痛苦的近义词
1. extension of the modes of operation through assignment of a new
我看教案value in the Modes field to communicate feature capability and
u,
2. the definitions of augmented start ssion and stop ssion
commands (with corresponding acknowledgements), and
3. the definition of related procedures for TWAMP entities.
The motivation for this feature is the ability to start and stop
individual test ssions at will, using a single TWAMP-Control
connection.
When the Server and Control-Client have agreed to u the Individual Session Control mode during control connection tup, then the
Control-Client, the Server, the Session-Sender, and the Session-
Reflector MUST all conform to the requirements of that mode, as
identified below. The original TWAMP-Control Start and Stop commands MUST NOT be ud.
3. TWAMP Control Extensions
The TWAMP-Control protocol is a derivative of the OWAMP-Control
protocol, and provides two-way measurement capability. TWAMP
[RFC5357] us the Modes field to identify and lect specific
communication capabilities, and this field is a recognized extension mechanism. The following ctions describe one such extension. Morton & Chiba Standards Track [Page 4]
3.1. Connection Setup with Individual Session Control
TWAMP-Control connection establishment follows the procedure defined in Section 3.1 of [RFC4656] OWAMP. The Individual Session Control
mode requires one new bit position (and value) to identify the
飞机设计图ability of the Server/Session-Reflector to start and stop specific
ssions (according to their Session Identifier, or SID). This new
feature requires an additional TWAMP mode bit assignment as follows: Value Description Reference/Explanation
0 Rerved
1 Unauthenticated RFC 4656, Section 3.1
2 Authenticated RFC 4656, Section 3.1
4 Encrypted RFC 4656, Section 3.1
8 Unauth. TEST protocol, RFC 5618, Section 3.1
Encrypted CONTROL
--------------------------------------------------------
16 Individual Session RFC 5938, bit position 4
Control
In the original OWAMP Modes field, tting bit positions 0, 1, or 2
indicated the curity mode of the Control protocol, and the Test
protocol inherited the same mode (e Section 4 of [RFC4656]). In
the [RFC5618] memo, bit position (3) allows a different curity mode in the Test protocol and us the unauthenticated test packet format. If the Server ts the new bit position (bit position 4) in the
Server Greeting message to indicate its capabilities, then the Server and Session-Reflector MUST comply with the requirements of this memo to control ssions on an individual basis if desired.
If the Control-Client intends to control ssions on an individual
basis (according to the requirements in this memo), it MUST t the
普通话的由来mode bit (4, corresponding to the new mode) in the Setup Respon
message. This means that:
1. The Control-Client and the Server MUST u the start and stop
commands intended for individual ssion control and the
corresponding acknowledgements, as defined in the ctions that
follow.
2. The Control-Client and the Server MUST NOT u the start and stop commands (2 and 3) and the acknowledgement defined in [RFC5357]. The Control-Client MUST also t one mode bit to indicate the chon curity mode (currently bits 0, 1, 2, or 3), consistent with the
modes offered by the Server. The Control-Client MAY also t Modes Morton & Chiba Standards Track [Page 5]
