Network Working Group
Internet Draft T. Nadeau
Cisco Systems, Inc.
Category: Informational Y(J) Stein
Rad Data Communications
March 2006
Pseudowire Performance and Timing Measurement
draft-nadeau-pwe3-perf-timing-measure-00.txt
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
To-date, no intrinsic mechanisms exist for pseudowires
that allow operators to measure the performance of
a pseudowire. Only the existing Virtual Circuit Connectivity
Verification protocol allows for the verification of
connectivity of a pseudowire.
This document defines the problems that must be solved in
this space, and provides discussion points around the issues of
Nadeau & Stein Expires August 2006 [Page 1]
draft-nadeau-pwe3-perf-time-measure-00 March 1, 2006
pseudowire performance measurement, including timing synchronization
and packet loss detection.
Table of Contents
1. Introduction ....................................................3
3. Terminology .....................................................3
4. Discussion Points .. ............................................4
5. Security Considerations ........................................76
6. Contributors ...................................................77
7. Acknowledgements ...............................................77
8. IANA Considerations ............................................77
9. References .....................................................77
9.1. Normative References ......................................77
9.2. Informative References ....................................78
10. Authors' Addresses ............................................79
1. Introduction
Current work is under way in the IETF's PWE3 working
group to specify a suite of protocols to be used to transport
various types of layer-2 data across public service transport
networks such as MPLS and IP (L2TPv3).
This document defines the problems that must be solved in
this space, and provides discussion points around the issues of
pseudowire performance measurement, including timing synchronization
and packet loss detection.
Some pseudowires carry data that requires strict timing
to prevent jitter. For example, Time Division Multiplexing
pseudowires that carry mobile phone transmissions have
stringent timing parameters. Also, some deployments
also require that packet loss detection be also possible.
This document provides discussion points around the issues of
pseudowire timing and packet loss, as well as potential extensions
to the existing pseudowire control channel for detection and
possible correction of timing issues.
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].
3. Terminology
Nadeau & Stein Expires August 2006 [Page 2]
draft-nadeau-pwe3-perf-time-measure-00 March 1, 2006
This document uses terminology from the pseudowire architecutre
specification [RFC3985].
4. Discussion Points
4.1 Current Limitations
VCCV presently provides only connectivity verification
full PW OAM should also provide measurements of
one way and round trip delay. Currently no mechanisms
exist natively in PWE3 protocols to accomplish the
following:
PDV (+ distribution? spectrum?)
Packet loss ratio or actual packet loss
Delay measurement
Jitter measurement
With regard to the above, detecting PL is straight
forward if the PW is TDM, but for other PW types, you
may need an OAM stream that has high enough rate to
give you the statistics you need, and is guaranteed
to follow the same path as the user data. This implies
the use of VCCV to carry this control information.
For PWs it is also useful to monitor performance
characterists in order to trigger backup PWs for fast
switch-over.
Maintain clock synchronization for multiple PWs.
Issue with clock synchronization information in
control channel is that in some implementations this is
handled via the "slow" forwarding path. In particular
the problem with cellular applications is that they want
very tight timing, which can not always be guaranteed over
PSNs. Are there are better ways of doing this than using
the PW control channel?
Tim Frost proposed NTP over PW in one of the NTP WG meetings
and Ron Cohen proposed extending 1588 to MPLS recently.
We should compare 1588 to adaptive methods. The current thinking
is that 1588 doesn't really help unless there are "boundary
clocks" - which require HW upgrades to switches.
Nadeau & Stein Expires August 2006 [Page 3]
draft-nadeau-pwe3-perf-time-measure-00 March 1, 2006
Do we really need to providing NTP-level wall-clocks for PWs?
Do we need to provide a PRC-like frequency standard?
Do we need to provide timing for 2G cellular sites or
3G cellular sites?
4.2 CW format use PWACH
What should the time format be?
- RTP style 32 bit based on N*8KHz
- NTP style seconds expressed as 32 bit integer
+ 32 bit fraction
- ICMP style 32 bit milliseconds
- IEEE 1588 style 32 bit seconds + 32 bit nanoseconds
How many timestamps should packet format support?
1. for approximate round-trip
2. for approximate one-way
3. for round-trip with D t
4. for ICMP-like timestamps
N. More than 4 for IEEE 1588-like timestamps
4.3 How do we handle loop-back requests?
4.4 Current Proposals to Move Forward
Define new control channel types for performance
measurement and timing.
10. Security Considerations
TBD.
11. Contributors
Thomas D. Nadeau
Cisco Systems, Inc.
300 Beaver Brook Road
Boxboro, MA 01719
Phone: +1-978-936-1470
EMail: tnadeau@cisco.com
Nadeau & Stein Expires August 2006 [Page 4]
draft-nadeau-pwe3-perf-time-measure-00 March 1, 2006
Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Phone: +972 3 645-5389
Email: yaakov_s@rad.com
12. Acknowledgements
TBD.
13. IANA Considerations
TBD.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
[RFC3985]
[VCCV] Nadeau, T. D., Aggarwal, R., "Pseudo Wire Virtual
Circuit Connectivity Verification (VCCV)",
draft-ietf-pwe3-vccv-08.txt, March 2006
14.2. Informative References
15. Authors' Addresses
Thomas D. Nadeau
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
EMail: tnadeau@cisco.com
Full Copyright Statement
Nadeau & Stein Expires August 2006 [Page 5]
draft-nadeau-pwe3-perf-time-measure-00 March 1, 2006
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nadeau & Stein Expires August 2006 [Page 6]