idnits 2.17.1 draft-nadeau-pwe3-perf-timing-measure-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 279. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 6616 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2434' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'VCCV' is defined on line 226, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-vccv-08 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft T. Nadeau 3 Cisco Systems, Inc. 5 Category: Informational Y(J) Stein 6 Rad Data Communications 8 March 2006 10 Pseudowire Performance and Timing Measurement 12 draft-nadeau-pwe3-perf-timing-measure-00.txt 14 Status of This Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 To-date, no intrinsic mechanisms exist for pseudowires 44 that allow operators to measure the performance of 45 a pseudowire. Only the existing Virtual Circuit Connectivity 46 Verification protocol allows for the verification of 47 connectivity of a pseudowire. 49 This document defines the problems that must be solved in 50 this space, and provides discussion points around the issues of 51 draft-nadeau-pwe3-perf-time-measure-00 March 1, 2006 53 pseudowire performance measurement, including timing synchronization 54 and packet loss detection. 56 Table of Contents 58 1. Introduction ....................................................3 59 3. Terminology .....................................................3 60 4. Discussion Points .. ............................................4 61 5. Security Considerations ........................................76 62 6. Contributors ...................................................77 63 7. Acknowledgements ...............................................77 64 8. IANA Considerations ............................................77 65 9. References .....................................................77 66 9.1. Normative References ......................................77 67 9.2. Informative References ....................................78 68 10. Authors' Addresses ............................................79 70 1. Introduction 72 Current work is under way in the IETF's PWE3 working 73 group to specify a suite of protocols to be used to transport 74 various types of layer-2 data across public service transport 75 networks such as MPLS and IP (L2TPv3). 77 This document defines the problems that must be solved in 78 this space, and provides discussion points around the issues of 79 pseudowire performance measurement, including timing synchronization 80 and packet loss detection. 82 Some pseudowires carry data that requires strict timing 83 to prevent jitter. For example, Time Division Multiplexing 84 pseudowires that carry mobile phone transmissions have 85 stringent timing parameters. Also, some deployments 86 also require that packet loss detection be also possible. 88 This document provides discussion points around the issues of 89 pseudowire timing and packet loss, as well as potential extensions 90 to the existing pseudowire control channel for detection and 91 possible correction of timing issues. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 3. Terminology 98 draft-nadeau-pwe3-perf-time-measure-00 March 1, 2006 100 This document uses terminology from the pseudowire architecutre 101 specification [RFC3985]. 103 4. Discussion Points 105 4.1 Current Limitations 107 VCCV presently provides only connectivity verification 108 full PW OAM should also provide measurements of 109 one way and round trip delay. Currently no mechanisms 110 exist natively in PWE3 protocols to accomplish the 111 following: 113 PDV (+ distribution? spectrum?) 115 Packet loss ratio or actual packet loss 117 Delay measurement 119 Jitter measurement 121 With regard to the above, detecting PL is straight 122 forward if the PW is TDM, but for other PW types, you 123 may need an OAM stream that has high enough rate to 124 give you the statistics you need, and is guaranteed 125 to follow the same path as the user data. This implies 126 the use of VCCV to carry this control information. 128 For PWs it is also useful to monitor performance 129 characterists in order to trigger backup PWs for fast 130 switch-over. 132 Maintain clock synchronization for multiple PWs. 133 Issue with clock synchronization information in 134 control channel is that in some implementations this is 135 handled via the "slow" forwarding path. In particular 136 the problem with cellular applications is that they want 137 very tight timing, which can not always be guaranteed over 138 PSNs. Are there are better ways of doing this than using 139 the PW control channel? 141 Tim Frost proposed NTP over PW in one of the NTP WG meetings 142 and Ron Cohen proposed extending 1588 to MPLS recently. 143 We should compare 1588 to adaptive methods. The current thinking 144 is that 1588 doesn't really help unless there are "boundary 145 clocks" - which require HW upgrades to switches. 147 draft-nadeau-pwe3-perf-time-measure-00 March 1, 2006 149 Do we really need to providing NTP-level wall-clocks for PWs? 151 Do we need to provide a PRC-like frequency standard? 153 Do we need to provide timing for 2G cellular sites or 154 3G cellular sites? 156 4.2 CW format use PWACH 158 What should the time format be? 160 - RTP style 32 bit based on N*8KHz 161 - NTP style seconds expressed as 32 bit integer 162 + 32 bit fraction 163 - ICMP style 32 bit milliseconds 164 - IEEE 1588 style 32 bit seconds + 32 bit nanoseconds 166 How many timestamps should packet format support? 168 1. for approximate round-trip 169 2. for approximate one-way 170 3. for round-trip with D t 171 4. for ICMP-like timestamps 172 N. More than 4 for IEEE 1588-like timestamps 174 4.3 How do we handle loop-back requests? 176 4.4 Current Proposals to Move Forward 178 Define new control channel types for performance 179 measurement and timing. 181 10. Security Considerations 183 TBD. 185 11. Contributors 187 Thomas D. Nadeau 188 Cisco Systems, Inc. 189 300 Beaver Brook Road 190 Boxboro, MA 01719 192 Phone: +1-978-936-1470 193 EMail: tnadeau@cisco.com 194 draft-nadeau-pwe3-perf-time-measure-00 March 1, 2006 196 Yaakov (Jonathan) Stein 197 RAD Data Communications 198 24 Raoul Wallenberg St., Bldg C 199 Tel Aviv 69719 200 ISRAEL 202 Phone: +972 3 645-5389 203 Email: yaakov_s@rad.com 205 12. Acknowledgements 207 TBD. 209 13. IANA Considerations 211 TBD. 213 14. References 215 14.1. Normative References 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 221 an IANA Considerations Section in RFCs", BCP 26, RFC 222 2434, October 1998. 224 [RFC3985] 226 [VCCV] Nadeau, T. D., Aggarwal, R., "Pseudo Wire Virtual 227 Circuit Connectivity Verification (VCCV)", 228 draft-ietf-pwe3-vccv-08.txt, March 2006 230 14.2. Informative References 232 15. Authors' Addresses 234 Thomas D. Nadeau 235 Cisco Systems, Inc. 236 1414 Massachusetts Ave. 237 Boxborough, MA 01719 238 EMail: tnadeau@cisco.com 240 Full Copyright Statement 241 draft-nadeau-pwe3-perf-time-measure-00 March 1, 2006 243 Copyright (C) The Internet Society (2006). 245 This document is subject to the rights, licenses and restrictions 246 contained in BCP 78, and except as set forth therein, the authors 247 retain all their rights. 249 This document and the information contained herein are provided on an 250 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 251 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 252 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 253 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 254 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 255 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 257 Intellectual Property 259 The IETF takes no position regarding the validity or scope of any 260 Intellectual Property Rights or other rights that might be claimed to 261 pertain to the implementation or use of the technology described in 262 this document or the extent to which any license under such rights 263 might or might not be available; nor does it represent that it has 264 made any independent effort to identify any such rights. Information 265 on the procedures with respect to rights in RFC documents can be 266 found in BCP 78 and BCP 79. 268 Copies of IPR disclosures made to the IETF Secretariat and any 269 assurances of licenses to be made available, or the result of an 270 attempt made to obtain a general license or permission for the use of 271 such proprietary rights by implementers or users of this 272 specification can be obtained from the IETF on-line IPR repository at 273 http://www.ietf.org/ipr. 275 The IETF invites any interested party to bring to its attention any 276 copyrights, patents or patent applications, or other proprietary 277 rights that may cover technology that may be required to implement 278 this standard. Please address the information to the IETF at 279 ietf-ipr@ietf.org. 281 Acknowledgement 283 Funding for the RFC Editor function is provided by the IETF 284 Administrative Support Activity (IASA).