diff options
Diffstat (limited to 'doc/rfc/rfc5938.txt')
| -rw-r--r-- | doc/rfc/rfc5938.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5938.txt b/doc/rfc/rfc5938.txt new file mode 100644 index 0000000..102ff84 --- /dev/null +++ b/doc/rfc/rfc5938.txt @@ -0,0 +1,955 @@ + + + + + + +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 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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus 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 + http://www.rfc-editor.org/info/rfc5938. + +Copyright Notice + + Copyright (c) 2010 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 + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Morton & Chiba Standards Track [Page 1] + +RFC 5938 TWAMP Session Control August 2010 + + + 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 license 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. Purpose 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] + +RFC 5938 TWAMP Session Control August 2010 + + +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 several + recommendations for new features in TWAMP. There are a growing + number of TWAMP implementations at present, 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 sessions + at once. This feature allows the Control-Client to control + individual test sessions 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 + use of two new TWAMP command numbers (for the augmented Start and + Stop commands). This feature also specifies the use of a new Stop-N- + ACK Server response, to complete the symmetry of the session-stopping + process in the same way as the Start-ACK (Start-N-ACK when used with + this feature) response. + + The Individual Session Control feature gives the Control-Client new + flexibility to manage any number of test sessions once they are + established. However, [RFC5357] test sessions are established in + serial order and the total establishment time grows with the number + of sessions 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 because 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 sessions 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] + +RFC 5938 TWAMP Session Control August 2010 + + + Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set + to zero by senders 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. Purpose and Scope + + The purpose 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 + use, + + 2. the definitions of augmented start session and stop session + 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 sessions at will, using a single TWAMP-Control + connection. + + When the Server and Control-Client have agreed to use the Individual + Session Control mode during control connection setup, 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 used. + +3. TWAMP Control Extensions + + The TWAMP-Control protocol is a derivative of the OWAMP-Control + protocol, and provides two-way measurement capability. TWAMP + [RFC5357] uses the Modes field to identify and select specific + communication capabilities, and this field is a recognized extension + mechanism. The following sections describe one such extension. + + + + + +Morton & Chiba Standards Track [Page 4] + +RFC 5938 TWAMP Session Control August 2010 + + +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 + sessions (according to their Session Identifier, or SID). This new + feature requires an additional TWAMP mode bit assignment as follows: + + Value Description Reference/Explanation + 0 Reserved + 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, setting bit positions 0, 1, or 2 + indicated the security mode of the Control protocol, and the Test + protocol inherited the same mode (see Section 4 of [RFC4656]). In + the [RFC5618] memo, bit position (3) allows a different security mode + in the Test protocol and uses the unauthenticated test packet format. + + If the Server sets 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 sessions on an individual basis if desired. + + If the Control-Client intends to control sessions on an individual + basis (according to the requirements in this memo), it MUST set the + mode bit (4, corresponding to the new mode) in the Setup Response + message. This means that: + + 1. The Control-Client and the Server MUST use the start and stop + commands intended for individual session control and the + corresponding acknowledgements, as defined in the sections that + follow. + + 2. The Control-Client and the Server MUST NOT use the start and stop + commands (2 and 3) and the acknowledgement defined in [RFC5357]. + + The Control-Client MUST also set one mode bit to indicate the chosen + security mode (currently bits 0, 1, 2, or 3), consistent with the + modes offered by the Server. The Control-Client MAY also set Modes + + + + +Morton & Chiba Standards Track [Page 5] + +RFC 5938 TWAMP Session Control August 2010 + + + field bit 4 with other features and bit positions (such as the + reflect octets feature). + +3.2. Start-N-Sessions Command with Individual Session Control + + Having + + o initiated Individual Session Control mode in the Setup Response, + + o requested one or more test sessions, and + + o received affirmative Accept-Session response(s), + + a TWAMP Client MAY start the execution of one or more test sessions + by sending a Start-N-Sessions message to the Server (note that "N" + indicates that this command is applicable to one or more sessions, + and does not change with the number of sessions identified in the + command). + + The format of the Start-N-Sessions message is as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | 7 | | + +-+-+-+-+-+-+-+-+ + + | MBZ (11 octets) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of Sessions | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + | First SID (16 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + . remaining SIDs (16 octets each) . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + | HMAC (16 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + + Note: In figures, "B" indicates the boundary of a 16-octet word. + + + +Morton & Chiba Standards Track [Page 6] + +RFC 5938 TWAMP Session Control August 2010 + + + The Command Number value of 7 indicates that this is a Start-N- + Sessions command. The Control-Client MUST compose this command, and + the Server MUST interpret this command, according to the field + descriptions below. + + The Number of Sessions field indicates the count of sessions that + this Start command applies to, and MUST be one or greater. The + number of SID fields that follow MUST be equal to the value in the + Number of Sessions field (otherwise, the command MUST NOT be affirmed + with a zero Accept field in the Start-N-Ack response). + + All SID fields are constructed as defined in the last paragraph of + Section 3.5 of OWAMP [RFC4656] (and referenced in TWAMP). Note that + the SID is assigned by the Server during the session request + exchange. + + The message is terminated with a single block HMAC, as illustrated + above. + + The Server MUST respond with one or more Start-N-Ack messages (which + SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL + have the format defined in the next session. + + When using Individual Session Control mode and its Start-N-Ack + command as described in the next section, multiple Start-N-Sessions + commands MAY be sent without waiting for acknowledgement, and the + Start-N-sessions commands MAY arrive in any order. + +3.3. Start-N-Ack Command with Individual Session Control + + The Server responds to the Start-N-Sessions command (for one or more + specific sessions referenced by their SIDs) with one or more Start-N- + Ack commands with Accept fields corresponding to one or more of the + SIDs. This allows for the possibility that a Server cannot + immediately start one or more of the sessions referenced in a + particular Start-N-Sessions command, but can start one or more of the + sessions. + + + + + + + + + + + + + + +Morton & Chiba Standards Track [Page 7] + +RFC 5938 TWAMP Session Control August 2010 + + + The format of the message is as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | 8 | Accept | MBZ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ (8 octets) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of Sessions | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + | First SID (16 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + . remaining SIDs (16 octets each) . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + | HMAC (16 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Command Number value of 8 indicates that this is a Start-N-Ack + message. The Server MUST compose this command, and the Control- + Client MUST interpret this command, according to the field + descriptions below. + + The Accept field values are defined in Section 3.3 of OWAMP + [RFC4656]. + + The Number of Sessions field indicates the count of sessions that + this Start-N-Ack command applies to, and MUST be one or greater. The + number of SID fields that follow MUST be equal to the value in the + Number of Sessions field. + + All SID fields are constructed as defined in the last paragraph of + Section 3.5 of OWAMP [RFC4656] (and referenced in TWAMP). Note that + the SID is assigned by the Server during the session request + exchange. + + The message is terminated with a single block HMAC, as illustrated + above. + + + +Morton & Chiba Standards Track [Page 8] + +RFC 5938 TWAMP Session Control August 2010 + + + Note that the SIDs for all Sessions with the same 'Accept' code can + be acknowledged using the same Start-N-Ack message. + + For example, say that the Server receives a Start-N-Sessions command + for SIDs 1, 2, 3, and 4. The Server determines that the resources + for SID=3 are temporarily unavailable. The Server responds with two + Start-N-Ack commands with fields as follows: + + Accept = 0 Number of Sessions = 3 SIDs 1, 2, 4 + + Accept = 5 Number of Sessions = 1 SID 3 + +3.4. Stop-N-Sessions Command with Individual Session Control + + The Stop-N-Sessions command can only be issued by the Control-Client. + The command MUST contain at least one SID. + + The TWAMP Stop-N-Sessions command for use in Individual Session + Control mode is formatted as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | 9 | | + +-+-+-+-+-+-+-+-+ + + | MBZ (11 octets) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of Sessions | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + | First SID (16 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + . remaining SIDs (16 octets each) . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + | HMAC (16 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + + + + + + +Morton & Chiba Standards Track [Page 9] + +RFC 5938 TWAMP Session Control August 2010 + + + The Command Number value of 9 indicates that this is a Stop-N- + Sessions command. The Control-Client MUST compose this command, and + the Server MUST interpret this command, according to the field + descriptions below. + + The Number of Sessions field indicates the count of sessions to which + this Stop-N-Sessions command applies. The SID is as defined in + Section 3.5 of OWAMP [RFC4656] (and TWAMP), and the value MUST be one + or greater. The number of SID fields that follow MUST be equal to + the value in the Number of Sessions field. + + The message is terminated with a single block HMAC, as illustrated + above. + + The Server MUST respond with one or more Stop-N-Ack messages (which + SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL + have the format defined in the next session. + +3.5. Stop-N-Ack Command with Individual Session Control + + In response to the Stop-N-Sessions command (for one or more specific + sessions referenced by their SIDs), the Server MUST reply with one or + more Stop-N-Ack commands with Accept fields corresponding to one or + more of the SIDs. This allows for the possibility that a Server + cannot immediately stop one or more of the sessions referenced in a + particular Stop-N-Sessions command, but can stop one or more of the + sessions. + + + + + + + + + + + + + + + + + + + + + + + + +Morton & Chiba Standards Track [Page 10] + +RFC 5938 TWAMP Session Control August 2010 + + + The format for the Stop-N-Ack command is as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | 10 | Accept | MBZ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ (8 octets) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of Sessions | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + | First SID (16 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + . remaining SIDs (16 octets each) . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B + | | + | HMAC (16 octets) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Command Number value of 10 indicates that this is a Stop-N-Ack + message. The Server MUST compose this command, and the Control- + Client MUST interpret this command, according to the field + descriptions below. + + The Accept Field values are defined in Section 3.3 of OWAMP + [RFC4656]. + + The Number of Sessions field indicates the count of sessions that + this Stop-N-Ack command applies to, and MUST be one or greater. The + number of SID fields that follow MUST be equal to the value in the + Number of Sessions field. + + All SID fields are constructed as defined in the last paragraph of + Section 3.5 of OWAMP [RFC4656] (and referenced in TWAMP). Note that + the SID is assigned by the Server during the session request + exchange. + + The message is terminated with a single block HMAC, as illustrated + above. + + + +Morton & Chiba Standards Track [Page 11] + +RFC 5938 TWAMP Session Control August 2010 + + + Note that the SIDs for all Sessions with the same 'Accept' code can + be acknowledged using the same Stop-N-Ack message. + +3.6. SERVWAIT Timeout Operation + + Section 3.1 of [RFC5357] describes the operation of the optional + SERVWAIT timer. In normal TWAMP operation, the Server suspends + monitoring the SERVWAIT timer while test sessions are in progress. + When the Individual Session Control feature is utilized, this + suspension is extended to cover the time when ANY test session is in + progress. + + Thus, the Server SHALL suspend monitoring control connection activity + after receiving any Start-N-Sessions command, and after receiving a + Stop-N-Sessions command for all corresponding SIDs (and no test + sessions are in progress), OR when REFWAIT expires on ALL test + sessions initiated by a TWAMP-Control connection, then the SERVWAIT + monitoring SHALL resume (as though a Stop-N-Sessions command had been + received). An implementation that supports the SERVWAIT timeout + option SHOULD also implement the REFWAIT timeout option. + + The diagram below illustrates the operation of timers SERVWAIT and + REFWAIT. + + SERVWAIT REFWAIT SERVWAIT + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ + (no sessions + in progress) + +-+-+-+-+-+-+-+-+-+-+-+ + SID="1" + + +-+-+-+-+ + SID="2" + + +-+-+-+-+-+-+-+-+ + SID="3" + + >>>>>>>>>> Time >>>>>>>>>>>>>>>>>>> Time >>>>>>>>>>>>>>>> Time >>>>> + +3.7. Additional Considerations + + The value of the Modes field sent by the Server (in the Server + Greeting message) is the bit-wise OR of the mode values that it is + willing to support during this session. + + With the publication of this feature, bit positions 0 through 4 of + the 32-bit Modes field are used. A Control-Client MAY ignore bit + positions greater than 2 in the Modes field, or it MAY support + + + +Morton & Chiba Standards Track [Page 12] + +RFC 5938 TWAMP Session Control August 2010 + + + OPTIONAL features that are communicated in bit positions 3 and + higher. (The unassigned bits are available for future protocol + extensions.) + + Other ways in which TWAMP extends OWAMP are described in [RFC5357]. + +4. TWAMP Test with Individual Session Control + + The TWAMP test protocol is similar to the OWAMP [RFC4656] test + protocol with the exception that the Session-Reflector transmits test + packets to the Session-Sender in response to each test packet it + receives. TWAMP [RFC5357] defines two different test packet formats, + one for packets transmitted by the Session-Sender and one for packets + transmitted by the Session-Reflector. As with the OWAMP-Test + protocol, there are three security modes: unauthenticated, + authenticated, and encrypted. The unauthenticated mode has one test + packet format, while the authenticated and encrypted modes use + another (common) format. + +4.1. Sender Behavior + + The individual session control feature requires that the sender MUST + manage test sessions according to their SID. Otherwise, the sender + behavior is as described in Section 4.1 of [RFC5357]. + +4.2. Reflector Behavior + + The TWAMP Reflector follows the procedures and guidelines in Section + 4.2 of [RFC5357], with the following additional functions required by + this feature: + + o The Session-Reflector MUST manage all test sessions accepted + according to their SID. + + o Upon receipt of a TWAMP-Control Stop-N-Sessions command + referencing a specific session/SID, the Session-Reflector MUST + ignore TWAMP-Test packets (in the same session/SID) that arrive at + the current time plus the Timeout (in the Request-TW-Session + command and assuming subsequent acknowledgement). The Session- + Reflector MUST NOT generate a test packet to the Session-Sender + for packets that are ignored. (Note: The Request-TW-Session + command includes sender address + port and receiver address + + port, and this is usually sufficient to distinguish sessions.) + + o If the REFWAIT timer is implemented, it SHOULD be enforced when + any test session is in progress (started and not stopped). + + + + + +Morton & Chiba Standards Track [Page 13] + +RFC 5938 TWAMP Session Control August 2010 + + +5. Security Considerations + + The security considerations that apply to any active measurement of + live networks are relevant here as well. See the security + considerations in [RFC4656] and [RFC5357]. + +6. IANA Considerations + + As a result of this document, IANA has assigned one mode bit + position/value for a mode in the IANA registry for the TWAMP Modes + field, and this memo describes the behavior when the new mode is + used. This field is a recognized extension mechanism for TWAMP. + + As a result of this document, IANA has assigned four command numbers + in the "TWAMP-Control Command Numbers" registry, and this memo + describes the use of the new commands. The command number field is a + recognized extension mechanism for TWAMP. + +6.1. Registry Specification + + IANA has created a "TWAMP-Modes" registry (as requested in + [RFC5618]). TWAMP-Modes are specified in TWAMP Server Greeting + messages and Set-Up-Response messages, as described in Section 3.1 of + [RFC5357], consistent with Section 3.1 of [RFC4656], and extended by + this memo. Modes are indicated by setting bits in the 32-bit Modes + field that correspond to values in the "TWAMP-Modes" registry. For + the "TWAMP-Modes" registry, we expect that new features will be + assigned increasing registry values that correspond to single bit + positions, unless there is a good reason to do otherwise (more + complex encoding than single bit positions may be used in the future + to access the 2^32 value space). + + IANA has also created the "TWAMP-Control Command Numbers" registry. + TWAMP-Control commands are specified by the first octet in TWAMP- + Control messages as specified in Section 3.5 of [RFC5357], and + augmented by this memo. This registry may contain 256 possible + values. + +6.2. Registry Management + + Because the "TWAMP-Control Command Numbers" registry can contain only + 256 values and "TWAMP-Modes" are based on only 32 bit positions with + a maximum of 2^32 values, and because TWAMP is an IETF protocol, + these registries must be updated only by "IETF Consensus" as + specified in [RFC5226] (an RFC that documents registry use and is + approved by the IESG). Management of these registries is described + in Section 8.2 of [RFC5357] and [RFC5618]. + + + + +Morton & Chiba Standards Track [Page 14] + +RFC 5938 TWAMP Session Control August 2010 + + + The values 7, 8, 9, and 10 have been assigned in the "TWAMP-Control + Command Numbers" Registry. The value 16 corresponding to the next + available bit position (4) (as described in Sections 3.1 and 3.7) has + been assigned in the "TWAMP-Modes" registry. + +6.3. Experimental Numbers + + One experimental value has been assigned in the "TWAMP-Control + Command Numbers" registry. + + No additional experimental values are assigned in the TWAMP-Modes + registry. + +6.4. Registry Contents + + TWAMP-Control Command Numbers Registry + + Value Description Semantics Definition + 0 Reserved + 1 Forbidden + 2 Start-Sessions RFC 4656, Section 3.7 + 3 Stop-Sessions RFC 4656, Section 3.8 + 4 Reserved + 5 Request-TW-Session RFC 5357, Section 3.5 + 6 Experimentation RFC 5357, Section 8.3 + ------------------------------------------------------------------ + 7 Start-N-Sessions RFC 5938, Section 3.2 + 8 Start-N-Ack RFC 5938, Section 3.3 + 9 Stop-N-Sessions RFC 5938, Section 3.4 + 10 Stop-N-Ack RFC 5938, Section 3.5 + + + TWAMP-Modes Registry + + Value Description Reference/Explanation + 0 Reserved + 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, Section 3.1 + Control bit position 4 + + + + + + + +Morton & Chiba Standards Track [Page 15] + +RFC 5938 TWAMP Session Control August 2010 + + +7. Acknowledgements + + The authors thank everyone who provided comments on this feature, + especially Lars Eggert, Adrian Farrel, and Alexey Melnikov. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. + Zekauskas, "A One-way Active Measurement Protocol + (OWAMP)", RFC 4656, September 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. + Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", + RFC 5357, October 2008. + + [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the + Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, + August 2009. + +8.2. Informative References + + [REFLECT] Morton, A. and L. Ciavattone, "TWAMP Reflect Octets and + Symmetrical Size Features", Work in Progress, June 2010. + + + + + + + + + + + + + + + + + + + +Morton & Chiba Standards Track [Page 16] + +RFC 5938 TWAMP Session Control August 2010 + + +Authors' Addresses + + Al Morton + AT&T Labs + 200 Laurel Avenue South + Middletown, NJ 07748 + USA + + Phone: +1 732 420 1571 + Fax: +1 732 368 1192 + EMail: acmorton@att.com + URI: http://home.comcast.net/~acmacm/ + + + Murtaza Chiba + Cisco Systems + 170 W. Tasman Drive + San Jose, CA 95134 + USA + + Phone: +1 800 553 NETS + EMail: mchiba@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morton & Chiba Standards Track [Page 17] + |