[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/