draft-ietf-ippm-twamp-time-format-01.txt | draft-ietf-ippm-twamp-time-format-02.txt | |||
---|---|---|---|---|
Network Working Group G. Mirsky | Network Working Group G. Mirsky | |||
Internet-Draft | Internet-Draft | |||
Intended status: Standards Track I. Meilik | Intended status: Standards Track I. Meilik | |||
Expires: May 9, 2017 Broadcom | Expires: August 29, 2017 Broadcom | |||
November 8, 2016 | February 25, 2017 | |||
Support of IEEE-1588 time stamp format in Two-Way Active Measurement | Support of IEEE-1588 time stamp format in Two-Way Active Measurement | |||
Protocol (TWAMP) | Protocol (TWAMP) | |||
draft-ietf-ippm-twamp-time-format-01 | draft-ietf-ippm-twamp-time-format-02 | |||
Abstract | Abstract | |||
This document describes an OPTIONAL feature for active performance | This document describes an OPTIONAL feature for active performance | |||
measurement protocols allowing use of time stamp format defined in | measurement protocols allowing use of the Precision Time Protocol | |||
IEEE-1588v2-2008. | time stamp format defined in IEEE-1588v2-2008, as an alternative to | |||
the Network Time Protocol that is currently used. | ||||
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 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 May 6, 2017. | This Internet-Draft will expire on August 29, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 48 ¶ | skipping to change at page 2, line 50 ¶ | |||
NTP domain or via interprocess communication in multiprocessor | NTP domain or via interprocess communication in multiprocessor | |||
distributed system. And of mentioned solutions will be subject to | distributed system. And of mentioned solutions will be subject to | |||
additional queuing delays that negatively affect data plane clock | additional queuing delays that negatively affect data plane clock | |||
accuracy. | accuracy. | |||
Precision Time Protocol (PTP) [IEEE.1588.2008] has gained wide | Precision Time Protocol (PTP) [IEEE.1588.2008] has gained wide | |||
support since the development of OWAMP and TWAMP. PTP, using on-path | support since the development of OWAMP and TWAMP. PTP, using on-path | |||
support and other mechanisms, allows sub-microsecond clock accuracy. | support and other mechanisms, allows sub-microsecond clock accuracy. | |||
PTP is now supported in multiple implementations of fast forwarding | PTP is now supported in multiple implementations of fast forwarding | |||
engines and thus accuracy achieved by PTP is the accuracy of clock in | engines and thus accuracy achieved by PTP is the accuracy of clock in | |||
data plane. Thus, providing option to use more accurate clock as | data plane. An option to use a more accurate clock as a source of | |||
source of time stamps for IP performance measurement is one of | time stamps for IP performance measurements is one of this proposal?s | |||
advantages this proposal helps to achieve. Another advantage realized | advantages. Another advantage is realized by simplification of | |||
by simplification of hardware in data plane. To support OWAMP or | hardware in data plane. To support OWAMP or TWAMP test protocol time | |||
TWAMP test protocol time stamps must be converted from PTP to NTP. | stamps must be converted from PTP to NTP. That requires resources, | |||
use of micro-code or additional processing elements, that are always | ||||
That requires resources, use of micro-code or additional processing | limited. To address this, this document proposes optional extensions | |||
elements, that are always limited. To address this, this document | to Control and Test protocols to support use of IEEE-1588v2 time | |||
proposes optional extensions to Control and Test protocols to support | stamp format as optional alternative to the NTP time stamp format. | |||
use of IEEE-1588v2 time stamp format as optional alternative to the | ||||
NTP time stamp format. | ||||
One of the goals of this proposal is not only allow end-points of a | One of the goals of this proposal is not only to allow end-points of | |||
test session to use other than NTP timestamp but to support backwards | a test session to use timestamp format other than NTP but to support | |||
compatibility with nodes that do not yet support this extension. | backwards compatibility with nodes that do not yet support this | |||
extension. | ||||
1.1. Conventions used in this document | 1.1. Conventions used in this document | |||
1.1.1. Terminology | 1.1.1. Terminology | |||
IPPM: IP Performance Measurement | IPPM: IP Performance Measurement | |||
NTP: Network Time Protocol | NTP: Network Time Protocol | |||
PTP: Precision Time Protocol | PTP: Precision Time Protocol | |||
skipping to change at page 3, line 42 ¶ | skipping to change at page 3, line 44 ¶ | |||
"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 | "OPTIONAL" in this document are to be interpreted as described in | |||
[RFC2119]. | [RFC2119]. | |||
2. OWAMP and TWAMP Extensions | 2. OWAMP and TWAMP Extensions | |||
OWAMP connection establishment follows the procedure defined in | OWAMP connection establishment follows the procedure defined in | |||
Section 3.1 of [RFC4656] and additional steps in TWAMP described in | Section 3.1 of [RFC4656] and additional steps in TWAMP described in | |||
Section 3.1 of [RFC5357]. In these procedures, the Modes field been | Section 3.1 of [RFC5357]. In these procedures, the Modes field been | |||
used to identify and select specific communication capabilities. At | used to identify and select specific communication capabilities. At | |||
the same time the Modes field been recognized and used as extension | the same time the Modes field has been recognized and used as | |||
mechanism [RFC6038]. The new feature requires one bit position for | extension mechanism [RFC6038]. The new feature requires one bit | |||
Server and Control-Client to negotiate which timestamp format can be | position for Server and Control-Client to negotiate which timestamp | |||
used in some or all test sessions invoked with this control | format can be used in some or all test sessions invoked with this | |||
connection. The end-point of the test session, Session-Sender and | control connection. The end-point of the test session, Session- | |||
Session-Receiver or Session-Reflector, that supports this extension | Sender and Session-Receiver or Session-Reflector, that supports this | |||
MUST be capable to interpret NTP and PTPv2 timestamp formats. If the | extension MUST be capable to interpret NTP and PTPv2 timestamp | |||
end-point does not support this extension, then the value of PTPv2 | formats. If the end-point does not support this extension, then the | |||
Timestamp flag MUST be 0 because it is in Must Be Zero field. If | value of PTPv2 Timestamp flag MUST be 0 because it is in Must Be Zero | |||
value of PTPv2 Timestamp flags is 0, then the advertising node can | field. If the value of PTPv2 Timestamp flags is 0, then the | |||
use and interpret only NTP timestamp format. | advertising node can use and interpret only NTP timestamp format. | |||
Use of PTPv2 Timestamp flags discussed in the following sub-sections. | Use of PTPv2 Timestamp flags is discussed in the following sub- | |||
For details on the assigned values and bit positions see the | sections. For details on the assigned values and bit positions see | |||
Section 3. | the Section 3. | |||
2.1. Timestamp Format Negotiation in Setting Up Connection in OWAMP | 2.1. Timestamp Format Negotiation in Setting Up Connection in OWAMP | |||
In OWAMP-Test [RFC4656] it is the Session-Receiver and/or Fetch- | In OWAMP-Test [RFC4656] the Session-Receiver and/or Fetch-Client | |||
Client that are interpreting collected timestamps. Thus, announced by | interpret collected timestamps. Thus, the Server uses the Modes | |||
a Server in the Modes field timestamp format indicates which formats | field timestamp format to indicate which formats the Session-Receiver | |||
the Session-Receiver is capable to interpret. The Control-Client | is capable to interpret. The Control-Client inspects values set by | |||
inspects values set by the Server for timestamp formats and sets | the Server for timestamp formats and sets values in the Modes field | |||
values in the Modes field of the Set-Up-Response message per | of the Set-Up-Response message according to timestamp formats | |||
timestamp formats Session-Sender can use. The rules of setting | Session-Sender can use. The rules of setting timestamp flags in | |||
timestamp flags in Modes field in server greeting and Set-Up- | Modes field in server greeting and Set-Up-Response messages and | |||
Response messages and interpreting them are as follows: | interpreting them are as follows: | |||
o The Server that establishes test sessions for Session-Receiver | o The Server that establishes test sessions for Session-Receiver | |||
that supports this extension MUST set PTPv2 Timestamp flag to 1 in | that supports this extension MUST set PTPv2 Timestamp flag to 1 in | |||
the server greeting message per the requirement listed in | the server greeting message per the requirement listed in | |||
Section 2. | Section 2. | |||
o If PTPv2 Timestamp flag of the server greeting message that the | o If PTPv2 Timestamp flag of the server greeting message that the | |||
Control-Client receives has value 0, then the Session-Sender MUST | Control-Client receives has value 0, then the Session-Sender MUST | |||
use NTP format for timestamp in the test session and Control- | use NTP format for timestamp in the test session and Control- | |||
Client SHOULD set PTPv2 Timestamp flag to 0 in accordance with | Client SHOULD set PTPv2 Timestamp flag to 0 in accordance with | |||
[RFC4656]. If the Session-Sender cannot use NTP timestamps, then | [RFC4656]. If the Session-Sender cannot use NTP timestamps, then | |||
the Control-Client SHOULD close the TCP connection associated with | the Control-Client SHOULD close the TCP connection associated with | |||
the OWAMP-Control session. | the OWAMP-Control session. | |||
o If the Session-Sender can set timestamp in PTPv2 format, then the | o If the Session-Sender can set timestamp in PTPv2 format, then the | |||
Control-Client MUST set the PTPv2 Timestamp flag to 1in Modes | Control-Client MUST set the PTPv2 Timestamp flag to 1 in Modes | |||
field in the Set-Up-Response message and the Session-Sender MUST | field in the Set-Up-Response message and the Session-Sender MUST | |||
set timestamp in PTPv2 timestamp format. Otherwise the Control- | set timestamp in PTPv2 timestamp format. Otherwise the Control- | |||
Client MUST set the PTPv2 Timestamp flag in the Set-Up-Response | Client MUST set the PTPv2 Timestamp flag in the Set-Up-Response | |||
message to 0. | message to 0. | |||
o Otherwise, if the Session-Sender can set timestamp in NTP format, | o Otherwise, if the Session-Sender can set timestamp in NTP format, | |||
then the Session-Sender MUST set timestamp in NTP timestamp | then the Session-Sender MUST set timestamp in NTP timestamp | |||
format. Otherwise the Control-Client SHOULD close the TCP | format. Otherwise the Control-Client MUST close the TCP | |||
connection associated with the OWAMP-Control session. | connection associated with the OWAMP-Control session. | |||
If values of both NTP and PTPv2 Timestamp flags in the Set-Up- | If values of both NTP and PTPv2 Timestamp flags in the Set-Up- | |||
Response message are equal to 0, then that indicates that the | Response message are equal to 0, then that indicates that the | |||
Control-Client can set timestamp only in NTP format. | Control-Client can set timestamp only in NTP format. | |||
If OWAMP-Control uses Fetch-Session commands, then selection and use | If OWAMP-Control uses Fetch-Session commands, then selection and use | |||
of one or another timestamp format is local decision for both | of one or another timestamp format is local decision for both | |||
Session-Sender and Session-Receiver. | Session-Sender and Session-Receiver. | |||
2.2. Timestamp Format Negotiation in Setting Up Connection in TWAMP | 2.2. Timestamp Format Negotiation in Setting Up Connection in TWAMP | |||
In TWAMP-Test [RFC5357] it is the Session-Sender that is interpreting | In TWAMP-Test [RFC5357] the Session-Sender interprets collected | |||
collected timestamps. Hence, in the Modes field a Server advertises | timestamps. Hence, in the Modes field a Server advertises timestamp | |||
timestamp formats that the Session-Reflector can use in TWAMP-Test | formats that the Session-Reflector can use in TWAMP-Test message. | |||
message. The choice of the timestamp format to be used by the | The choice of the timestamp format to be used by the Session-Sender | |||
Session-Sender is a local decision. The Control-Client inspects the | is a local decision. The Control-Client inspects the Modes field and | |||
Modes field and sets timestamp flags values to indicate which format | sets timestamp flags values to indicate which format will be used by | |||
will be used by the Session-Reflector. The rules of setting and | the Session-Reflector. The rules of setting and interpreting flag | |||
interpreting flag values are as follows: | values are as follows: | |||
o Server MUST set to 1 value of PTPv2 Timestamp flag in its greeting | o Server MUST set to 1 value of PTPv2 Timestamp flag in its greeting | |||
message if Session-Reflector can set timestamp in PTPv2 format. | message if Session-Reflector can set timestamp in PTPv2 format. | |||
Otherwise the PTPv2 Timestamp flag MUST be set to 0. | Otherwise the PTPv2 Timestamp flag MUST be set to 0. | |||
o If value of the PTPv2 Timestamp flag in received server greeting | o If value of the PTPv2 Timestamp flag in received server greeting | |||
message equals 0, then Session-Reflector does not support this | message equals 0, then Session-Reflector does not support this | |||
extension and will use NTP timestamp format. Control-Client | extension and will use NTP timestamp format. Control-Client | |||
SHOULD set PTPv2 Timestamp flag to 0 in Set-Up-Response message in | SHOULD set PTPv2 Timestamp flag to 0 in Set-Up-Response message in | |||
accordance with [RFC5357]. | accordance with [RFC5357]. | |||
o Control-Client MUST set PTPv2 Timestamp flag value to 1 in Modes | o Control-Client MUST set PTPv2 Timestamp flag value to 1 in Modes | |||
field in the Set-Up-Response message if Server advertised ability | field in the Set-Up-Response message if Server advertised ability | |||
of the Session-Reflector to use PTPv2 format for timestamps. | of the Session-Reflector to use PTPv2 format for timestamps. | |||
Otherwise the flag MUST be set to 0. | Otherwise the flag MUST be set to 0. | |||
o If the values of PTPv2 Timestamp flag in the Set-Up-Response | o If the values of PTPv2 Timestamp flag in the Set-Up-Response | |||
message equals 0, then that means that Session-Sender can only | message equals 0, then that means that Session-Sender can only | |||
interpret NTP timestamp format. Then the Session-Reflector MUST | interpret NTP timestamp format. Then the Session-Reflector MUST | |||
use NTP timestamp format. If the Session-Reflector does not | use NTP timestamp format. If the Session-Reflector does not | |||
support NTP format for timestamps then Server and SHOULD close the | support NTP format then Server and MUST close the TCP connection | |||
TCP connection associated with the TWAMP-Control session. | associated with the TWAMP-Control session. | |||
2.3. OWAMP-Test and TWAMP-Test Update | 2.3. OWAMP-Test and TWAMP-Test Update | |||
Participants of a test session need to indicate which timestamp | Participants of a test session need to indicate which timestamp | |||
format being used. The proposal is to use Z field in Error Estimate | format being used. The proposal is to use Z field in Error Estimate | |||
defined in Section 4.1.2 of [RFC4656]. The new interpretation of the | defined in Section 4.1.2 of [RFC4656]. The new interpretation of the | |||
Error Estimate is in addition to it specifying error estimate and | Error Estimate is in addition to it specifying error estimate and | |||
synchronization, Error Estimate indicates format of a collected | synchronization, Error Estimate indicates format of a collected | |||
timestamp. And this proposal changes the semantics of the Z bit | timestamp. And this proposal changes the semantics of the Z bit | |||
field, the one between S and Scale fields, to be referred as | field, the one between S and Scale fields, to be referred as | |||
End of changes. 14 change blocks. | ||||
56 lines changed or deleted | 56 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |