draft-ietf-ippm-twamp-reflect-octets-03.txt   draft-ietf-ippm-twamp-reflect-octets-04.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft L. Ciavattone Internet-Draft L. Ciavattone
Intended status: Standards Track AT&T Labs Updates: 5357 (if approved) AT&T Labs
Expires: April 25, 2010 October 22, 2009 Intended status: Standards Track February 28, 2010
Expires: September 1, 2010
TWAMP Reflect Octets and Symmetrical Size Features TWAMP Reflect Octets and Symmetrical Size Features
draft-ietf-ippm-twamp-reflect-octets-03 draft-ietf-ippm-twamp-reflect-octets-04
Abstract
The IETF has completed its work on the core specification of TWAMP -
the Two-Way Active Measurement Protocol. This memo describes two
closely-related features for TWAMP: an optional capability where the
responder host returns some of the command octets or padding octets
to the controller, and an optional sender packet format that ensures
equal test packet sizes are used in both directions.
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].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2010. This Internet-Draft will expire on September 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The IETF has completed its work on the core specification of TWAMP - described in the BSD License.
the Two-Way Active Measurement Protocol. This memo describes two
closely-related features for TWAMP: an optional capability where the
responder host returns some of the command octets or padding octets
to the controller, a new sender packet format that ensures equal test
packet sizes are used in both directions.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document may contain material from IETF Documents or IETF
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Contributions published or made publicly available before November
document are to be interpreted as described in RFC 2119 [RFC2119]. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 5 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 4
3.1. Connection Setup with New Features . . . . . . . . . . . . 5 3.1. Connection Setup with New Features . . . . . . . . . . . . 4
3.2. Reflect Octets: Request-TW-Session Packet Format . . . . . 6 3.2. Reflect Octets: Request-TW-Session Packet Format . . . . . 5
3.3. Reflect Octets: Accept Session Packet Format . . . . . . . 8 3.3. Reflect Octets: Accept Session Packet Format . . . . . . . 7
3.4. Additional considerations . . . . . . . . . . . . . . . . 9 3.4. Additional considerations . . . . . . . . . . . . . . . . 8
4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 10 4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 9
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Reflect Octets: Packet Formats and Contents . . . . . 10 4.1.2. Reflect Octets: Packet Formats and Contents . . . . . 9
4.1.3. Reflect Octets: Interaction with Padding Truncation . 12 4.1.3. Reflect Octets: Interaction with Padding Truncation . 11
4.1.4. Symmetrical Size: Session-Sender Packet Format . . . . 13 4.1.4. Symmetrical Size: Session-Sender Packet Format . . . . 12
4.1.5. Symmetrical Size AND Reflect Octets: 4.1.5. Symmetrical Size AND Reflect Octets:
Session-Sender Packet Format . . . . . . . . . . . . . 13 Session-Sender Packet Format . . . . . . . . . . . . . 12
4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 14 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Reflect Octets: Session-Reflector Packet Format 4.2.1. Reflect Octets: Session-Reflector Packet Format
and Contents . . . . . . . . . . . . . . . . . . . . . 15 and Contents . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Symmetrical Size: Session-Reflector Packet Format . . 16 4.2.2. Symmetrical Size: Session-Reflector Packet Format . . 15
4.2.3. Symmetrical Size AND Reflect Octets: 4.2.3. Symmetrical Size AND Reflect Octets:
Session-Sender Packet Format . . . . . . . . . . . . . 16 Session-Sender Packet Format . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Registry Specification . . . . . . . . . . . . . . . . . . 17 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 16
6.2. Registry Management . . . . . . . . . . . . . . . . . . . 17 6.2. Registry Management . . . . . . . . . . . . . . . . . . . 16
6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 17 6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 16
6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 17 6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The IETF has completed its work on the core specification of TWAMP - The IETF has completed its work on the core specification of TWAMP -
the Two-Way Active Measurement Protocol [RFC5357]. TWAMP is an the Two-Way Active Measurement Protocol [RFC5357]. TWAMP is an
extension of the One-way Active Measurement Protocol, OWAMP extension of the One-way Active Measurement Protocol, OWAMP
[RFC4656]. The TWAMP specification gathered wide review as it [RFC4656]. The TWAMP specification gathered wide review as it
approached completion, and the by-products were several approached completion, and the by-products were several
recommendations for new features in TWAMP. There are a growing recommendations for new features in TWAMP. There are a growing
number TWAMP implementations at present, and wide-spread usage is number TWAMP implementations at present, and wide-spread usage is
skipping to change at page 4, line 32 skipping to change at page 4, line 32
or Session-Sender can embed octets of information it deems useful and or Session-Sender can embed octets of information it deems useful and
have the assurance that the corresponding reply/test packet will have the assurance that the corresponding reply/test packet will
contain that information when it is reflected and returned (by the contain that information when it is reflected and returned (by the
Server or Session-Reflector. Server or Session-Reflector.
The memo also adds an OPTIONAL capability to assure that reflected The memo also adds an OPTIONAL capability to assure that reflected
test packets are the same size in both directions of transmission. test packets are the same size in both directions of transmission.
This is accomplished by specifying a new TWAMP-Test Session-Sender This is accomplished by specifying a new TWAMP-Test Session-Sender
packet format. packet format.
The relationship between this memo and TWAMP is intended to be an This memo and TWAMP is intended to be an update to [RFC5357] when
update to [RFC5357] when published. published. It is not required to implement the features described in
this memo to claim compliance with [RFC5357].
2. Purpose and Scope 2. Purpose and Scope
The purpose of this memo is to define two new closely-related The purpose of this memo is to define two OPTIONAL closely-related
features for TWAMP [RFC5357]. The features enhance the TWAMP features for TWAMP [RFC5357]. The features enhance the TWAMP
responder's capabilities to perform simple operations on control and responder's capabilities to perform simple operations on control and
test packets: the reflection of octets or padding and symmetrical test packets: the reflection of octets or padding and symmetrical
sizes of fields in the TWAMP-Test packets. Motivations include sizes of fields in the TWAMP-Test packets. Motivations include
permitting the controller host to tag packets with an index for permitting the controller host to tag packets with an index for
simplified identification, and/or assert that the same size test simplified identification, and/or assert that the same size test
packets will be used in each direction. packets will be used in each direction.
The scope of the memo is currently limited to specifications of the The scope of the memo is currently limited to specifications of the
following features: following features:
o Reflect Octets: the capability of the Server/Session-Reflector to o Reflect Octets: the capability of the Server/Session-Reflector to
reflect specific octets back to the Client/Session-Sender. reflect specific octets back to the Client/Session-Sender.
o Symmetrical Size: the capability to ensure that TWAMP-Test o Symmetrical Size: the capability to ensure that TWAMP-Test
protocol uses the same packet size in both directions through protocol uses the same packet size in both directions through
support of a new TWAMP-Test Session-Sender test packet format in support of a new TWAMP-Test Session-Sender test packet format in
both the Session-Sender and the Session-Reflector. both the Session-Sender and the Session-Reflector. Only the
Session-Sender test packet format is new.
Extension of the modes of operation through assignment of two new Extension of the modes of operation through assignment of two new
values in the Mode Field (see section 3.1 of[RFC4656] for the format values in the Mode Field (see section 3.1 of[RFC4656] for the format
of the Server Greeting message), while retaining backward of the Server Greeting message), while retaining backward
compatibility with the core TWAMP [RFC5357] implementations. The two compatibility with the core TWAMP [RFC5357] implementations. The two
new values correspond to the two features defined in this memo. new values correspond to the two features defined in this memo.
When the Server and Control-Client have agreed to use the Reflect When the Server and Control-Client have agreed to use the Reflect
Octets mode during control connection setup, then the Control-Client, Octets mode during control connection setup, then the Control-Client,
the Server, the Session-Sender, and the Session-Reflector MUST all the Server, the Session-Sender, and the Session-Reflector MUST all
skipping to change at page 6, line 12 skipping to change at page 6, line 12
feature, the complete set of TWAMP Modes Field bit positions and feature, the complete set of TWAMP Modes Field bit positions and
values would be as follows: values would be as follows:
Value Description Reference/Explanation Value Description Reference/Explanation
0 Reserved 0 Reserved
1 Unauthenticated RFC4656, Section 3.1 1 Unauthenticated RFC4656, Section 3.1
2 Authenticated RFC4656, Section 3.1 2 Authenticated RFC4656, Section 3.1
4 Encrypted RFC4656, Section 3.1 4 Encrypted RFC4656, Section 3.1
8 Unauth. TEST protocol, RFC5681, Section 3.1 8 Unauth. TEST protocol, RFC5681, Section 3.1
Encrypted CONTROL Encrypted CONTROL
zzz Individual Session RFC????, Section 3.1
Control
-------------------------------------------------------- --------------------------------------------------------
xxx Reflect Octets new bit position (X) xxx Reflect Octets new bit position (X)
Capability Capability
yyy Symmetrical Size new bit position (Y) yyy Symmetrical Size new bit position (Y)
Sender Test Packet Format Sender Test Packet Format
In the original OWAMP Modes Field, setting bit positions 0, 1 or 2 In the original OWAMP Modes Field, setting bit positions 0, 1 or 2
indicated the security mode of the Control protocol, and the Test indicated the security mode of the Control protocol, and the Test
protocol inherited the same mode (see section 4 of [RFC4656]). In protocol inherited the same mode (see section 4 of [RFC4656]). In
[RFC5618], bit position 3 allows unauthenticated TWAMP Test protocol [RFC5618], bit position 3 allows unauthenticated TWAMP Test protocol
skipping to change at page 9, line 48 skipping to change at page 9, line 48
there are insufficient octets supplied to produce equal-length there are insufficient octets supplied to produce equal-length
Session-Sender and Session-Reflector test packets, then the Accept Session-Sender and Session-Reflector test packets, then the Accept
Field MUST be set to 3 = some aspect of the request is not supported. Field MUST be set to 3 = some aspect of the request is not supported.
3.4. Additional considerations 3.4. Additional considerations
The value of the Modes Field sent by the Server in the Server 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 Greeting message is the bit-wise OR of the mode values that it is
willing to support during this session. willing to support during this session.
Thus, the last six bits of the Modes 32-bit Field are used. A client With the publication of this memo as an RFC, the last 7 bit positions
conforming to this extension of [RFC5357] MAY ignore the values in of the Modes 32-bit Field are used. A Control-Client conforming to
the first 24 bits of the Modes Field, or it MAY support other this extension of [RFC5357] MAY ignore the values in the higher bits
features that are communicated in these bit positions. (The first 24 of the Modes Field, or it MAY support other features that are
bits are available for future protocol extensions.) communicated in those bit positions. The other bits are available
for future protocol extensions.
4. Extended TWAMP Test 4. Extended TWAMP Test
The TWAMP test protocol is similar to the OWAMP [RFC4656] test The TWAMP test protocol is similar to the OWAMP [RFC4656] test
protocol with the exception that the Session-Reflector transmits test protocol with the exception that the Session-Reflector transmits test
packets to the Session-Sender in response to each test packet it packets to the Session-Sender in response to each test packet it
receives. TWAMP section 4[RFC5357] defines two additional test receives. TWAMP section 4[RFC5357] defines two additional test
packet formats for packets transmitted by the Session-Reflector. The packet formats for packets transmitted by the Session-Reflector. The
appropriate format depends on the security mode chosen. The new appropriate format depends on the security mode chosen. The new
modes specified here utilize some of the padding octets within each modes specified here utilize some of the padding octets within each
skipping to change at page 13, line 41 skipping to change at page 13, line 41
| | | |
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
. . . .
. Packet Padding . . Packet Padding .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This feature REQUIRES only a new Session-Sender test packet format,
the Session-Reflector test packet format is unchanged.
4.1.5. Symmetrical Size AND Reflect Octets: Session-Sender Packet 4.1.5. Symmetrical Size AND Reflect Octets: Session-Sender Packet
Format Format
When BOTH the Symmetrical Size mode and the Reflect Octets mode are When BOTH the Symmetrical Size mode and the Reflect Octets mode are
selected, the Session-Sender SHALL use the following TWAMP-Test selected, the Session-Sender SHALL use the following TWAMP-Test
Packet Format in Unauthenticated mode: Packet Format in Unauthenticated mode:
Unauthenticated Mode 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
skipping to change at page 16, line 18 skipping to change at page 16, line 18
octets in Authenticated and Encrypted modes. octets in Authenticated and Encrypted modes.
The Session-Reflector MAY re-use the Sender's Packet Padding (since The Session-Reflector MAY re-use the Sender's Packet Padding (since
the requirements for padding generation are the same for each). the requirements for padding generation are the same for each).
4.2.2. Symmetrical Size: Session-Reflector Packet Format 4.2.2. Symmetrical Size: Session-Reflector Packet Format
When Symmetrical Size mode is selected, the Session-Sender packet When Symmetrical Size mode is selected, the Session-Sender packet
formats for unauthenticated and authenticated/encrypted modes are formats for unauthenticated and authenticated/encrypted modes are
identical to the core TWAMP specification, section 4.2.1 of identical to the core TWAMP specification, section 4.2.1 of
[RFC5357]. [RFC5357]. Thus, the Session-Reflector test packet format is
unchanged.
The Session-Reflector MUST construct its test packet using the The Session-Reflector MUST construct its test packet using the
information in the Session-Sender's test packet. The length of the information in the Session-Sender's test packet. The length of the
Session-Reflector's test packet SHALL equal the length of the Session-Reflector's test packet SHALL equal the length of the
Session-Sender's test packet. Session-Sender's test packet.
4.2.3. Symmetrical Size AND Reflect Octets: Session-Sender Packet 4.2.3. Symmetrical Size AND Reflect Octets: Session-Sender Packet
Format Format
When BOTH the Symmetrical Size mode and the Reflect Octets mode are When BOTH the Symmetrical Size mode and the Reflect Octets mode are
skipping to change at page 17, line 18 skipping to change at page 17, line 19
IANA has created a TWAMP-Modes registry (as requested in [RFC5618]). IANA has created a TWAMP-Modes registry (as requested in [RFC5618]).
TWAMP-Modes are specified in TWAMP Server Greeting messages and TWAMP-Modes are specified in TWAMP Server Greeting messages and
Set-up Response messages, as described in section 3.1 of [RFC5357], Set-up Response messages, as described in section 3.1 of [RFC5357],
consistent with section 3.1 of [RFC4656], and extended by this memo. consistent with section 3.1 of [RFC4656], and extended by this memo.
Modes are indicated by setting bits in the 32-bit Modes field. Thus, Modes are indicated by setting bits in the 32-bit Modes field. Thus,
this registry can contain a total of 32 possible values. this registry can contain a total of 32 possible values.
6.2. Registry Management 6.2. Registry Management
This registry must be updated only by "IETF Consensus" as specified This registry must be updated only by "IETF Consensus" as specified
in [RFC2434](an RFC documenting registry use that is approved by the in [RFC5226](an RFC documenting registry use that is approved by the
IESG). IESG).
6.3. Experimental Numbers 6.3. Experimental Numbers
No experimental values are currently assigned for the Modes Registry. No experimental values are currently assigned for the Modes Registry.
6.4. Registry Contents 6.4. Registry Contents
TWAMP Modes Registry is recommended to be augmented as follows: TWAMP Modes Registry is recommended to be augmented as follows:
skipping to change at page 17, line 49 skipping to change at page 18, line 4
Auth. CONTROL Auth. CONTROL
-------------------------------------------------------- --------------------------------------------------------
xxx Reflect Octets this memo, section 3.1 xxx Reflect Octets this memo, section 3.1
Capability new bit position (X) Capability new bit position (X)
yyy Symmetrical Size this memo, section 3.1 yyy Symmetrical Size this memo, section 3.1
Sender Test Packet Format new bit position (Y) Sender Test Packet Format new bit position (Y)
The suggested values are The suggested values are
X=5, xxx=32 X=5, xxx=32
Y=6, yyy=64 Y=6, yyy=64
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Walt Steverson for helpful review and The authors would like to thank Walt Steverson and Stina Ross for
comments. helpful review and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[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, September 2006. (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. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008. RFC 5357, October 2008.
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the
Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
August 2009. August 2009.
8.2. Informative References 8.2. Informative References
[x] "".
Authors' Addresses Authors' Addresses
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown,, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192 Fax: +1 732 368 1192
 End of changes. 24 change blocks. 
83 lines changed or deleted 96 lines changed or added

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