draft-ietf-ippm-stamp-08.txt   draft-ietf-ippm-stamp-09.txt 
Network Working Group G. Mirsky Network Working Group G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Intended status: Standards Track G. Jun Intended status: Standards Track G. Jun
Expires: March 27, 2020 ZTE Corporation Expires: April 20, 2020 ZTE Corporation
H. Nydell H. Nydell
Accedian Networks Accedian Networks
R. Foote R. Foote
Nokia Nokia
September 24, 2019 October 18, 2019
Simple Two-way Active Measurement Protocol Simple Two-way Active Measurement Protocol
draft-ietf-ippm-stamp-08 draft-ietf-ippm-stamp-09
Abstract Abstract
This document describes a Simple Two-way Active Measurement Protocol This document describes a Simple Two-way Active Measurement Protocol
which enables the measurement of both one-way and round-trip which enables the measurement of both one-way and round-trip
performance metrics like delay, delay variation, and packet loss. performance metrics like delay, delay variation, and packet loss.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 March 27, 2020. This Internet-Draft will expire on April 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Operation and Management of Performance Measurement Based on 3. Operation and Management of Performance Measurement Based on
STAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 STAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
4.1. Session-Sender Behavior and Packet Format . . . . . . . . 5 4.1. UDP Port Numbers in STAMP Testing . . . . . . . . . . . . 5
4.1.1. Session-Sender Packet Format in Unauthenticated Mode 5 4.2. Session-Sender Behavior and Packet Format . . . . . . . . 5
4.1.2. Session-Sender Packet Format in Authenticated Mode . 6 4.2.1. Session-Sender Packet Format in Unauthenticated Mode 5
4.2. Session-Reflector Behavior and Packet Format . . . . . . 7 4.2.2. Session-Sender Packet Format in Authenticated Mode . 7
4.2.1. Session-Reflector Packet Format in Unauthenticated 4.3. Session-Reflector Behavior and Packet Format . . . . . . 8
Mode . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Session-Reflector Packet Format in Unauthenticated
4.2.2. Session-Reflector Packet Format in Authenticated Mode 9 Mode . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Integrity Protection in STAMP . . . . . . . . . . . . . . 10 4.3.2. Session-Reflector Packet Format in Authenticated Mode 10
4.4. Confidentiality Protection in STAMP . . . . . . . . . . . 11 4.4. Integrity Protection in STAMP . . . . . . . . . . . . . . 11
4.5. Interoperability with TWAMP Light . . . . . . . . . . . . 11 4.5. Confidentiality Protection in STAMP . . . . . . . . . . . 12
5. Operational Considerations . . . . . . . . . . . . . . . . . 12 4.6. Interoperability with TWAMP Light . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Operational Considerations . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Development and deployment of Two-Way Active Measurement Protocol Development and deployment of the Two-Way Active Measurement Protocol
(TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined (TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined
Symmetrical Size for TWAMP provided invaluable experience. Several Symmetrical Size for TWAMP, provided invaluable experience. Several
independent implementations of both TWAMP and TWAMP Light exist, have independent implementations of both TWAMP and TWAMP Light exist, have
been deployed, and provide important operational performance been deployed, and provide important operational performance
measurements. measurements.
At the same time, there has been noticeable interest in using a more At the same time, there has been noticeable interest in using a more
straightforward mechanism for active performance monitoring that can straightforward mechanism for active performance monitoring that can
provide deterministic behavior and inherit separation of control provide deterministic behavior and inherent separation of control
(vendor-specific configuration or orchestration) and test functions. (vendor-specific configuration or orchestration) and test functions.
Recent work on IP Edge to Customer Equipment using TWAMP Light from Recent work on IP Edge to Customer Equipment using TWAMP Light from
Broadband Forum [BBF.TR-390] demonstrated that interoperability among Broadband Forum [BBF.TR-390] demonstrated that interoperability among
implementations of TWAMP Light is challenged because the composition implementations of TWAMP Light is difficult because the composition
and operation of TWAMP Light were not sufficiently specified in and operation of TWAMP Light were not sufficiently specified in
[RFC5357]. According to [RFC8545], TWAMP Light includes sub-set of [RFC5357]. According to [RFC8545], TWAMP Light includes a sub-set of
TWAMP-Test functions to provide comprehensive solution requires TWAMP-Test functions. Thus, to have a comprehensive tool to measure
support by other applications that provide, for example, control and packet loss and delay requires support by other applications that
security. provide, for example, control and security.
This document defines an active performance measurement test This document defines an active performance measurement test
protocol, Simple Two-way Active Measurement Protocol (STAMP), that protocol, Simple Two-way Active Measurement Protocol (STAMP), that
enables measurement of both one-way and round-trip performance enables measurement of both one-way and round-trip performance
metrics like delay, delay variation, and packet loss. Some TWAMP metrics like delay, delay variation, and packet loss. Some TWAMP
extensions, e.g., [RFC7750] are supported by the extensions to STAMP extensions, e.g., [RFC7750] are supported by the extensions to STAMP
base specification in [I-D.ietf-ippm-stamp-option-tlv]. base specification in [I-D.ietf-ippm-stamp-option-tlv].
2. Conventions used in this document 2. Conventions used in this document
skipping to change at page 3, line 33 skipping to change at page 3, line 34
NTP - Network Time Protocol NTP - Network Time Protocol
PTP - Precision Time Protocol PTP - Precision Time Protocol
HMAC Hashed Message Authentication Code HMAC Hashed Message Authentication Code
OWAMP One-Way Active Measurement Protocol OWAMP One-Way Active Measurement Protocol
TWAMP Two-Way Active Measurement Protocol TWAMP Two-Way Active Measurement Protocol
MBZ May be Zero MBZ Must be Zero
2.2. Requirements Language 2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Operation and Management of Performance Measurement Based on STAMP 3. Operation and Management of Performance Measurement Based on STAMP
Figure 1 presents the Simple Two-way Active Measurement Protocol Figure 1 presents the Simple Two-way Active Measurement Protocol
(STAMP) Session-Sender, and Session-Reflector with a measurement (STAMP) Session-Sender, and Session-Reflector with a measurement
session. In this document, a measurement session also referred to as session. In this document, a measurement session also referred to as
STAMP session, is the bi-directional packet flow between one specific STAMP session, is the bi-directional packet flow between one specific
Session-Sender and one particular Session-Reflector for a time Session-Sender and one particular Session-Reflector for a time
duration. The configuration and management of the STAMP Session- duration. The configuration and management of the STAMP Session-
Sender, Session-Reflector, and management of the STAMP sessions can Sender, Session-Reflector, and management of the STAMP sessions are
be achieved through various means. Command Line Interface, OSS/BSS outside the scope of this document and can be achieved through
(operations support system/business support system as a combination various means. A few examples are: Command Line Interface,
of two systems used to support a range of telecommunication services) telecommunication services' OSS/BSS systems, SNMP, and Netconf/YANG-
using SNMP or controllers in Software-Defined Networking using based SDN controllers.
Netconf/YANG are but a few examples.
o----------------------------------------------------------o o----------------------------------------------------------o
| Configuration and | | Configuration and |
| Management | | Management |
o----------------------------------------------------------o o----------------------------------------------------------o
|| || || ||
|| || || ||
|| || || ||
+----------------------+ +-------------------------+ +----------------------+ +-------------------------+
| STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector | | STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector |
+----------------------+ +-------------------------+ +----------------------+ +-------------------------+
Figure 1: STAMP Reference Model Figure 1: STAMP Reference Model
4. Theory of Operation 4. Theory of Operation
STAMP Session-Sender transmits test packets over UDP transport toward STAMP Session-Sender transmits test packets over UDP transport toward
STAMP Session-Reflector. A STAMP Session-Sender MUST use UDP port STAMP Session-Reflector. STAMP Session-Reflector receives Session-
862 (TWAMP-Test Receiver Port) as the default destination UDP port Sender's packet and acts according to the configuration. Two modes
number. A STAMP implementation of Session-Sender MUST be able to use of STAMP Session-Reflector characterize the expected behavior and,
UDP port numbers from User, a.k.a. Registered, Ports and Dynamic, consequently, performance metrics that can be measured:
a.k.a. Private or Ephemeral, Ports ranges defined in [RFC6335].
Before using numbers from the User Ports range, the possible impact
on the network MUST be carefully studied and agreed by all users of
the network domain where the test has been planned.
STAMP Session-Reflector receives Session-Sender's packet and acts o Stateless - STAMP Session-Reflector does not maintain test state
according to the configuration and optional control information and will use the value in the Sequence Number field in the
communicated in the Session-Sender's test packet. An implementation received packet as the value for the Sequence Number field in the
of STAMP Session-Reflector by default MUST use receive STAMP test reflected packet. As a result, values in Sequence Number and
packets on UDP port 862. An implementation of Session-Reflector that Session-Sender Sequence Number fields are the same, and only
supports this specification MUST be able to define the port number to round-trip packet loss can be calculated while the reflector is
receive STAMP test packets from User Ports and Dynamic Ports ranges operating in stateless mode.
that are defined in [RFC6335]. STAMP defines two different test
packet formats, one for packets transmitted by the STAMP-Session-
Sender and one for packets transmitted by the STAMP-Session-
Reflector.
STAMP supports two modes: unauthenticated and authenticated. o Stateful - STAMP Session-Reflector maintains test state thus
Unauthenticated STAMP test packets, defined in Section 4.1.1 and enabling the ability to determine forward loss, gaps recognized in
Section 4.2.1, ensure interworking between STAMP and TWAMP Light as the received sequence number. As a result, both near-end
described in Section 4.5 packet formats. (forward) and far-end (backward) packet loss can be computed.
That implies that the STAMP Session-Reflector MUST keep a state
for each configured STAMP-test session, uniquely identifying
STAMP-test packets to one such session instance, and enabling
adding a sequence number in the test reply that is individually
incremented on a per-session basis.
STAMP supports two authentication modes: unauthenticated and
authenticated. Unauthenticated STAMP test packets, defined in
Section 4.2.1 and Section 4.3.1, ensure interworking between STAMP
and TWAMP Light as described in Section 4.6 packet formats.
By default, STAMP uses symmetrical packets, i.e., size of the packet By default, STAMP uses symmetrical packets, i.e., size of the packet
transmitted by Session-Reflector equals the size of the packet transmitted by Session-Reflector equals the size of the packet
received by the Session-Reflector. received by the Session-Reflector.
4.1. Session-Sender Behavior and Packet Format 4.1. UDP Port Numbers in STAMP Testing
STAMP supports symmetrical test packets. The base STAMP Session- A STAMP Session-Sender MUST use UDP port 862 (TWAMP-Test Receiver
Sender packet has a minimum size of 44 octets in unauthenticated Port) as the default destination UDP port number. A STAMP
mode, see Figure 2, and 112 octets in the authenticated mode, see implementation of Session-Sender MUST be able to use as the
Figure 4. The variable length of a test packet in STAMP is supported destination UDP port numbers from User, a.k.a. Registered, Ports and
by using Extra Padding TLV defined in Dynamic, a.k.a. Private or Ephemeral, Ports ranges defined in
[I-D.ietf-ippm-stamp-option-tlv]. [RFC6335]. Before using numbers from the User Ports range, the
possible impact on the network MUST be carefully studied and agreed
by all users of the network domain where the test has been planned.
4.1.1. Session-Sender Packet Format in Unauthenticated Mode An implementation of STAMP Session-Reflector by default MUST receive
STAMP test packets on UDP port 862. An implementation of Session-
Reflector that supports this specification MUST be able to define the
port number to receive STAMP test packets from User Ports and Dynamic
Ports ranges that are defined in [RFC6335]. STAMP defines two
different test packet formats, one for packets transmitted by the
STAMP-Session-Sender and one for packets transmitted by the STAMP-
Session-Reflector.
4.2. Session-Sender Behavior and Packet Format
A STAMP Session-Reflector supports the symmetrical size of test
packets [RFC6038] as the default behavior. A reflected test packet
includes more information and thus is larger. Because of that, the
base STAMP Session-Sender packet is padded to match the size of a
reflected STAMP test packet. Hence, the base STAMP Session-Sender
packet has a minimum size of 44 octets in unauthenticated mode, see
Figure 2, and 112 octets in the authenticated mode, see Figure 4.
The variable length of a test packet in STAMP is supported by using
Extra Padding TLV defined in [I-D.ietf-ippm-stamp-option-tlv].
4.2.1. Session-Sender Packet Format in Unauthenticated Mode
STAMP Session-Sender packet format in unauthenticated mode: STAMP Session-Sender packet format in unauthenticated mode:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
| | | |
| MBZ (30 octets) | | Reserved (30 octets) |
| | | |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: STAMP Session-Sender test packet format in unauthenticated Figure 2: STAMP Session-Sender test packet format in unauthenticated
mode mode
where fields are defined as the following: where fields are defined as the following:
o Sequence Number is four octets long field. For each new session o Sequence Number is four octets long field. For each new session
its value starts at zero and is incremented with each transmitted its value starts at zero and is incremented with each transmitted
packet. packet.
o Timestamp is eight octets long field. STAMP node MUST support o Timestamp is eight octets long field. STAMP node MUST support
Network Time Protocol (NTP) version 4 64-bit timestamp format Network Time Protocol (NTP) version 4 64-bit timestamp format
[RFC5905], the format used in [RFC5357]. STAMP node MAY support [RFC5905], the format used in [RFC5357]. STAMP node MAY support
IEEE 1588v2 Precision Time Protocol truncated 64-bit timestamp IEEE 1588v2 Precision Time Protocol (PTP) truncated 64-bit
format [IEEE.1588.2008], the format used in [RFC8186]. timestamp format [IEEE.1588.2008], the format used in [RFC8186].
The use of the specific format, NTP or PTP, is part of
configuration of the Session-Sender or the particular test
session.
o Error Estimate is two octets long field with format displayed in o Error Estimate is two octets long field with format displayed in
Figure 3 Figure 3
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z| Scale | Multiplier | |S|Z| Scale | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Error Estimate Format Figure 3: Error Estimate Format
where S, Scale, and Multiplier fields are interpreted as they have where S, Scale, and Multiplier fields are interpreted as they have
been defined in section 4.1.2 [RFC4656]; and Z flag - as has been been defined in section 4.1.2 [RFC4656]; and Z field - as has been
defined in section 2.3 [RFC8186]: defined in section 2.3 [RFC8186]:
* 0 - NTP 64 bit format of a timestamp; * 0 - NTP 64 bit format of a timestamp;
* 1 - PTPv2 truncated format of a timestamp. * 1 - PTPv2 truncated format of a timestamp.
The STAMP Session-Sender and Session-Reflector MUST use a Z field The default behavior of the STAMP Session-Sender and Session-
value of 0, (NTP 64 bit format of a timestamp) as the default. Reflector is to use the NTP 64-bit timestamp format (Z field value
The STAMP Session-Sender and Session-Reflector MAY optionally set of 0) An operator, using configuration/management function, MAY
the Z field to a value of 1 (PTPv2 truncated format of a configure STAMP Session-Sender and Session-Reflector to using the
timestamp). PTPv2 truncated format of a timestamp (Z field value of 1). Note,
that an implementation of a Session-Sender that supports this
specification MAY be configured to use PTPv2 format of a timestamp
even though the Session-Reflector is configured to use NTP format.
o May-be-Zero (MBZ) field in the session-sender unauthenticated o Reserved field in the Session-Sender unauthenticated packet is 30
packet is 30 octets long. It MAY be all zeroed on the octets long. It MUST be all zeroed on the transmission and MUST
transmission and MUST be ignored on receipt. be ignored on receipt.
4.1.2. Session-Sender Packet Format in Authenticated Mode 4.2.2. Session-Sender Packet Format in Authenticated Mode
STAMP Session-Sender packet format in authenticated mode: STAMP Session-Sender packet format in authenticated mode:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MBZ (12 octets) | | MBZ (12 octets) |
skipping to change at page 7, line 33 skipping to change at page 8, line 33
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: STAMP Session-Sender test packet format in authenticated Figure 4: STAMP Session-Sender test packet format in authenticated
mode mode
The field definitions are the same as the unauthenticated mode, The field definitions are the same as the unauthenticated mode,
listed in Section 4.1.1. Also, MBZ fields are used to align the listed in Section 4.2.1. Also, Must-Be-Zero (MBZ) fields are used to
packet on 16 octets boundary. The value of the field MAY be zeroed to make the packet length a multiple of 16 octets. The value of the
on transmission and MUST be ignored on receipt. Also, the packet field MUST be zeroed on transmission and MUST be ignored on receipt.
includes a key-hashed message authentication code (HMAC) ([RFC2104]) Note, that the MBZ field is used to calculate a key-hashed message
hash at the end of the PDU. The detailed use of the HMAC field is authentication code (HMAC) ([RFC2104]) hash. Also, the packet
described in Section 4.3. includes HMAC hash at the end of the PDU. The detailed use of the
HMAC field is described in Section 4.4.
4.2. Session-Reflector Behavior and Packet Format
The Session-Reflector receives the STAMP test packet, verifies it,
prepares and transmits the reflected test packet.
Two modes of STAMP Session-Reflector characterize the expected
behavior and, consequently, performance metrics that can be measured:
o Stateless - STAMP Session-Reflector does not maintain test state 4.3. Session-Reflector Behavior and Packet Format
and will use the value in the Sequence Number field in the
recieved packet as the value for the Sequence Number field in the
reflected packet. As a result, values in Sequence Number and
Session-Sender Sequence Number fields are the same, and only
round-trip packet loss can be calculated while the reflector is
operating in stateless mode.
o Stateful - STAMP Session-Reflector maintains test state thus The Session-Reflector receives the STAMP test packet and verifies it.
enabling the ability to determine forward loss, gaps recognized in If the base STAMP test packet validated, the Session-Reflector, that
the received sequence number. As a result, both near-end supports this specification, prepares and transmits the reflected
(forward) and far-end (backward) packet loss can be computed. test packet symmetric to the packet received from the Session-Sender
That implies that the STAMP Session-Reflector MUST keep a state copying the content beyond the size of the base STAMP packet (see
for each accepted STAMP-test session, uniquely identifying STAMP- Section 4.2).
test packets to one such session instance, and enabling adding a
sequence number in the test reply that is individually incremented
on a per-session basis.
4.2.1. Session-Reflector Packet Format in Unauthenticated Mode 4.3.1. Session-Reflector Packet Format in Unauthenticated Mode
For unauthenticated mode: For unauthenticated mode:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
skipping to change at page 8, line 41 skipping to change at page 9, line 29
| Receive Timestamp | | Receive Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Sequence Number | | Session-Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Timestamp | | Session-Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate | MBZ | | Session-Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL | MBZ | |Ses-Sender TTL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: STAMP Session-Reflector test packet format in Figure 5: STAMP Session-Reflector test packet format in
unauthenticated mode unauthenticated mode
where fields are defined as the following: where fields are defined as the following:
o Sequence Number is four octets long field. The value of the o Sequence Number is four octets long field. The value of the
Sequence Number field is set according to the mode of the STAMP Sequence Number field is set according to the mode of the STAMP
Session-Reflector: Session-Reflector:
* in the stateless mode the Session-Reflector copies the value * in the stateless mode, the Session-Reflector copies the value
from the received STAMP test packet's Sequence Number field; from the received STAMP test packet's Sequence Number field;
* in the stateful mode the Session-Reflector counts the received * in the stateful mode, the Session-Reflector counts the
STAMP test packets in each test session and uses that counter transmitted STAMP test packets. It starts with zero and is
to set the value of the Sequence Number field. incremented by one for each subsequent packet for each test
session. The Session-Reflector uses that counter to set the
value of the Sequence Number field.
o Timestamp and Receiver Timestamp fields are each eight octets o Timestamp and Receive Timestamp fields are each eight octets long.
long. The format of these fields, NTP or PTPv2, indicated by the The format of these fields, NTP or PTPv2, indicated by the Z field
Z flag of the Error Estimate field as described in Section 4.1. of the Error Estimate field as described in Section 4.2. Receive
Timestamp is the time the test packet was received by the Session-
Reflector. Timestamp - the time taken by the Session-Reflector at
the start of transmitting the test packet.
o Error Estimate has the same size and interpretation as described o Error Estimate has the same size and interpretation as described
in Section 4.1. in Section 4.2. It is applicable to both Timestamp and Receive
Timestamp.
o Session-Sender Sequence Number, Session-Sender Timestamp, and o Session-Sender Sequence Number, Session-Sender Timestamp, and
Session-Sender Error Estimate are copies of the corresponding Session-Sender Error Estimate are copies of the corresponding
fields in the STAMP test packet sent by the Session-Sender. fields in the STAMP test packet sent by the Session-Sender.
o Session-Sender TTL is one octet long field, and its value is the o Session-Sender TTL is one octet long field, and its value is the
copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the
received STAMP test packet. received STAMP test packet.
o MBZ is used to achieve alignment on a four octets boundary. The o MBZ is used to achieve alignment of fields within the packet on a
value of the field MAY be zeroed on transmission and MUST be four octets boundary. The value of the field MUST be zeroed on
ignored on receipt. transmission and MUST be ignored on receipt.
4.2.2. Session-Reflector Packet Format in Authenticated Mode o Reserved field in the Session-Reflector unauthenticated packet is
three octets long. It MUST be all zeroed on the transmission and
MUST be ignored on receipt.
4.3.2. Session-Reflector Packet Format in Authenticated Mode
For the authenticated mode: For the authenticated mode:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
skipping to change at page 10, line 37 skipping to change at page 11, line 35
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: STAMP Session-Reflector test packet format in authenticated Figure 6: STAMP Session-Reflector test packet format in authenticated
mode mode
The field definitions are the same as the unauthenticated mode, The field definitions are the same as the unauthenticated mode,
listed in Section 4.2.1. Additionally, the MBZ field is used to listed in Section 4.3.1. Additionally, the MBZ field is used to to
align the packet on 16 octets boundary. The value of the field MAY make the packet length a multiple of 16 octets. The value of the
be zeroed on transmission and MUST be ignored on receipt. Also, field MUST be zeroed on transmission and MUST be ignored on receipt.
Note, that the MBZ field is used to calculate HMAC hash value. Also,
STAMP Session-Reflector test packet format in authenticated mode STAMP Session-Reflector test packet format in authenticated mode
includes a key (HMAC) ([RFC2104]) hash at the end of the PDU. The includes HMAC ([RFC2104]) hash at the end of the PDU. The detailed
detailed use of the HMAC field is in Section 4.3. use of the HMAC field is in Section 4.4.
4.3. Integrity Protection in STAMP 4.4. Integrity Protection in STAMP
To provide integrity protection, each STAMP message is being Authenticated mode provides integrity protection to each STAMP
authenticated by adding Hashed Message Authentication Code (HMAC). message by adding Hashed Message Authentication Code (HMAC). STAMP
STAMP uses HMAC-SHA-256 truncated to 128 bits (similarly to the use uses HMAC-SHA-256 truncated to 128 bits (similarly to the use of it
of it in IPSec defined in [RFC4868]); hence the length of the HMAC in IPSec defined in [RFC4868]); hence the length of the HMAC field is
field is 16 octets. HMAC uses its own key, and the definition of the 16 octets. In the Authenticated mode, HMAC covers the first six
mechanism to distribute the HMAC key is outside the scope of this blocks (96 octets). HMAC uses its own key that may be unique for
specification. One example is to use an orchestrator to configure each STAMP test session; key management and the mechanisms to
HMAC key based on STAMP YANG data model [I-D.ietf-ippm-stamp-yang]. distribute the HMAC key are outside the scope of this specification.
HMAC MUST be verified as early as possible to avoid using or One example is to use an orchestrator to configure HMAC key based on
propagating corrupted data. STAMP YANG data model [I-D.ietf-ippm-stamp-yang]. HMAC MUST be
verified as early as possible to avoid using or propagating corrupted
data.
4.4. Confidentiality Protection in STAMP Future specifications may define the use of other, more advanced
cryptographic algorithms, possibly providing an update to the STAMP
YANG data model [I-D.ietf-ippm-stamp-yang].
4.5. Confidentiality Protection in STAMP
If confidentiality protection for STAMP is required, a STAMP test If confidentiality protection for STAMP is required, a STAMP test
session MUST use a secured transport. For example, STAMP packets session MUST use a secured transport. For example, STAMP packets
could be transmitted in the dedicated IPsec tunnel or share the IPsec could be transmitted in the dedicated IPsec tunnel or share the IPsec
tunnel with the monitored flow. Also, Datagram Transport Layer tunnel with the monitored flow. Also, Datagram Transport Layer
Security protocol would provide the desired confidentiality Security protocol would provide the desired confidentiality
protection. protection.
4.5. Interoperability with TWAMP Light 4.6. Interoperability with TWAMP Light
One of the essential requirements to STAMP is the ability to One of the essential requirements to STAMP is the ability to
interwork with a TWAMP Light device. There are two possible interwork with a TWAMP Light device. Because STAMP and TWAMP use
combinations for such use case: different algorithms in Authenticated mode (HMAC-SHA-256 vs. HMAC-
SHA-1), interoperability is only considered for Unauthenticated mode.
There are two possible combinations for such use case:
o STAMP Session-Sender with TWAMP Light Session-Reflector; o STAMP Session-Sender with TWAMP Light Session-Reflector;
o TWAMP Light Session-Sender with STAMP Session-Reflector. o TWAMP Light Session-Sender with STAMP Session-Reflector.
In the former case, the Session-Sender MAY not be aware that its In the former case, the Session-Sender might not be aware that its
Session-Reflector does not support STAMP. For example, a TWAMP Light Session-Reflector does not support STAMP. For example, a TWAMP Light
Session-Reflector may not support the use of UDP port 862 as defined Session-Reflector may not support the use of UDP port 862 as
in [RFC8545]. Thus STAMP Session-Sender MAY use port numbers as specified in [RFC8545]. Thus Section 4. permits a STAMP Session-
defined in Section 4. If any of STAMP extensions are used, the TWAMP Sender to use alternative ports. If any of STAMP extensions are
Light Session-Reflector will view them as Packet Padding field. used, the TWAMP Light Session-Reflector will view them as Packet
Padding field.
In the latter scenario, if a TWAMP Light Session-Sender does not In the latter scenario, if a TWAMP Light Session-Sender does not
support the use of UDP port 862, the test management system MUST set support the use of UDP port 862, the test management system MUST set
STAMP Session-Reflector to use UDP port number as defined in STAMP Session-Reflector to use UDP port number, as permitted by
Section 4. If the TWAMP Light Session-Sender includes Packet Padding Section 4. The Session-Reflector MUST be set to use the default
field in its transmitted packet, the STAMP Session-Reflector will format for its timestamps, NTP.
return the reflected packet of the symmetrical size if the size of
the received test packet is larger than the size of the STAMP base
packet. The Session-Reflector MUST be set to use the default format
for its timestamps, NTP.
STAMP does not support the Reflect Octets capability defined in A STAMP Session-Reflector that supports this specification would
transmit the base packet (Figure 5) regardless of the size of the
Padding field in the packet received from TWAMP Session-Sender.
Also, STAMP does not support the Reflect Octets capability defined in
[RFC6038]. If the Server Octets field is present in the TWAMP [RFC6038]. If the Server Octets field is present in the TWAMP
Session-Sender packet, STAMP Session-Reflector will not copy the Session-Sender packet, STAMP Session-Reflector will not copy the
content starting from the Server Octets field but will transmit the content starting from the Server Octets field and will transmit the
reflected packet of equal size. reflected packet, as displayed in Figure 5.
5. Operational Considerations 5. Operational Considerations
STAMP is intended to be used on production networks to enable the STAMP is intended to be used on production networks to enable the
operator to assess service level agreements based on packet delay, operator to assess service level agreements based on packet delay,
delay variation, and loss. When using STAMP over the Internet, delay variation, and loss. When using STAMP over the Internet,
especially when STAMP test packets are transmitted with the especially when STAMP test packets are transmitted with the
destination UDP port number from the User Ports range, the possible destination UDP port number from the User Ports range, the possible
impact of the STAMP test packets MUST be thoroughly analyzed. The impact of the STAMP test packets MUST be thoroughly analyzed. The
use of STAMP for each case MUST be agreed by users of nodes hosting use of STAMP for each case MUST be agreed by users of nodes hosting
skipping to change at page 12, line 34 skipping to change at page 13, line 40
This document doesn't have any IANA action. This section may be This document doesn't have any IANA action. This section may be
removed before the publication. removed before the publication.
7. Security Considerations 7. Security Considerations
[RFC5357] does not identify security considerations specific to [RFC5357] does not identify security considerations specific to
TWAMP-Test but refers to security considerations identified for OWAMP TWAMP-Test but refers to security considerations identified for OWAMP
in [RFC4656]. Since both OWAMP and TWAMP include control plane and in [RFC4656]. Since both OWAMP and TWAMP include control plane and
data plane components, only security considerations related to OWAMP- data plane components, only security considerations related to OWAMP-
Test, discussed in Sections 6.2, 6.3[RFC4656] apply to STAMP. Test, discussed in Sections 6.2, 6.3 [RFC4656] apply to STAMP.
STAMP uses the well-known UDP port number allocated for the OWAMP- STAMP uses the well-known UDP port number allocated for the OWAMP-
Test/TWAMP-Test Receiver port. Thus the security considerations and Test/TWAMP-Test Receiver port. Thus the security considerations and
measures to mitigate the risk of the attack using the registered port measures to mitigate the risk of the attack using the registered port
number documented in Section 6 [RFC8545] equally apply to STAMP. number documented in Section 6 [RFC8545] equally apply to STAMP.
Because of the control and management of a STAMP test being outside Because of the control and management of a STAMP test being outside
the scope of this specification only the more general requirement is the scope of this specification only the more general requirement is
set: set:
To mitigate the possible attack vector, the control, and To mitigate the possible attack vector, the control, and
management of a STAMP test session MUST use the secured transport. management of a STAMP test session MUST use the secured transport.
Load of STAMP test packets offered to a network MUST be carefully The load of the STAMP test packets offered to a network MUST be
estimated, and the possible impact on the existing services MUST carefully estimated, and the possible impact on the existing
be thoroughly analyzed before launching the test session. services MUST be thoroughly analyzed before launching the test
[RFC8085] section 3.1.5 provides guidance on handling network load session. [RFC8085] section 3.1.5 provides guidance on handling
for UDP-based protocol. While the characteristic of test traffic network load for UDP-based protocol. While the characteristic of
depends on the test objective, it is highly recommended to stay in test traffic depends on the test objective, it is highly
the limits as provided in [RFC8085]. recommended to stay in the limits as provided in [RFC8085].
Use of HMAC-SHA-256 in the authenticated mode protects the data Use of HMAC-SHA-256 in the authenticated mode protects the data
integrity of the STAMP test packets. integrity of the STAMP test packets.
8. Acknowledgments 8. Acknowledgments
Authors express their appreciation to Jose Ignacio Alvarez-Hamelin Authors express their appreciation to Jose Ignacio Alvarez-Hamelin
and Brian Weis for their great insights into the security and and Brian Weis for their great insights into the security and
identity protection, and the most helpful and practical suggestions. identity protection, and the most helpful and practical suggestions.
Also, our sincere thanks to David Ball and Rakesh Gandhi or their Also, our sincere thanks to David Ball and Rakesh Gandhi or their
skipping to change at page 13, line 33 skipping to change at page 14, line 39
Mirsky, G., Xiao, M., Jun, G., Nydell, H., Foote, R., and Mirsky, G., Xiao, M., Jun, G., Nydell, H., Foote, R., and
A. Masputra, "Simple Two-way Active Measurement Protocol A. Masputra, "Simple Two-way Active Measurement Protocol
Optional Extensions", draft-ietf-ippm-stamp-option-tlv-01 Optional Extensions", draft-ietf-ippm-stamp-option-tlv-01
(work in progress), September 2019. (work in progress), September 2019.
[IEEE.1588.2008] [IEEE.1588.2008]
"Standard for a Precision Clock Synchronization Protocol "Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", for Networked Measurement and Control Systems",
IEEE Standard 1588, March 2008. IEEE Standard 1588, March 2008.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>. <https://www.rfc-editor.org/info/rfc4656>.
skipping to change at page 14, line 43 skipping to change at page 16, line 5
[BBF.TR-390] [BBF.TR-390]
"Performance Measurement from IP Edge to Customer "Performance Measurement from IP Edge to Customer
Equipment using TWAMP Light", BBF TR-390, May 2017. Equipment using TWAMP Light", BBF TR-390, May 2017.
[I-D.ietf-ippm-stamp-yang] [I-D.ietf-ippm-stamp-yang]
Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active
Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- Measurement Protocol (STAMP) Data Model", draft-ietf-ippm-
stamp-yang-04 (work in progress), September 2019. stamp-yang-04 (work in progress), September 2019.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[RFC7750] Hedin, J., Mirsky, G., and S. Baillargeon, "Differentiated [RFC7750] Hedin, J., Mirsky, G., and S. Baillargeon, "Differentiated
Service Code Point and Explicit Congestion Notification Service Code Point and Explicit Congestion Notification
Monitoring in the Two-Way Active Measurement Protocol Monitoring in the Two-Way Active Measurement Protocol
(TWAMP)", RFC 7750, DOI 10.17487/RFC7750, February 2016, (TWAMP)", RFC 7750, DOI 10.17487/RFC7750, February 2016,
<https://www.rfc-editor.org/info/rfc7750>. <https://www.rfc-editor.org/info/rfc7750>.
 End of changes. 51 change blocks. 
173 lines changed or deleted 207 lines changed or added

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