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

Versions: 00

INTERNET-DRAFT                                              M. Ackermann
Intended Status: Informational                             BCBS Michigan
                                                               N. Elkins
                                                               W. Jouris
                                                         Inside Products
                                                              K. Haining
                                                               U.S. Bank
Expires: July 2014                                      January 24, 2014


           Usage of NTP for the PDM DOH IPv6 Extension Header
                  draft-ackermann-ntp-pdm-ntp-usage-00

Abstract

   The Performance and Diagnostic Metrics (PDM) Destination Options
   Header (DOH) for IPv6 defines metrics which are critical for timely
   end-to-end problem resolution, without impacting an operational
   production network. These metrics and their derivations can be used
   for network diagnostics. The base metrics are: packet sequence number
   and packet timestamp. The timestamp fields require time
   synchronization at the two end points. This document provides
   implementation guidelines for implementing Network Time Protocol
   (NTP) to provide such synchronization.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html









Ackermann                  Expires July, 2014                   [Page 1]


INTERNET DRAFT      -ackermann-ntp-pdm-ntp-usage-00         January 2014


Copyright and License Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Table of Contents

   1  Background  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1 General Implementation Guidelines  . . . . . . . . . . . . .  3
     1.2 NTP and IPPM . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3 Hierarchy  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.4 Architectural Principles . . . . . . . . . . . . . . . . . .  5
   2 NTP Architectures  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1 Generic NTP Architecture . . . . . . . . . . . . . . . . . .  6
     2.2 Recommended NTP Architecture . . . . . . . . . . . . . . . .  6
   3  Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   4  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  7
   5  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1  Normative References  . . . . . . . . . . . . . . . . . . .  7
     5.2 Informative References . . . . . . . . . . . . . . . . . . .  7
   6 Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  7
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7

















Ackermann                  Expires July, 2014                   [Page 2]


INTERNET DRAFT      -ackermann-ntp-pdm-ntp-usage-00         January 2014


1  Background

   The Performance and Diagnostic Metrics (PDM) Destination Options
   Header (DOH) for IPv6 [RFC2460] defines metrics which are critical
   for timely end-to-end problem resolution, without impacting an
   operational production network.  These metrics and their derivations
   can be used for network diagnostics.  The base metrics are: packet
   sequence number and packet timestamp. The timestamp fields require
   time synchronization at the two end points.

   This document provides implementation guidelines for implementing
   Network Time Protocol (NTP) [RFC5905] to provide such
   synchronization.  If these guidelines are followed, accuracies at a
   minimum of 100 milliseconds, or better, should be achievable
   throughout the network.

   For background, please see draft-elkins-6man-ipv6-pdm-dest-option-02
   [ELKPDM], draft-elkins-v6ops-ipv6-packet-sequence-needed-01 [ELKPSN],
   draft-elkins-v6ops-ipv6-pdm-recommended-usage-01 [ELKUSE], draft-
   elkins-v6ops-ipv6-end-to-end-rt-needed-01 [ELKRSP] and draft-elkins-
   ippm-pdm-metrics-00 [ELKIPPM]. These drafts are companions to this
   document.


1.1 General Implementation Guidelines

   This recommendation provides technical requirements, guidelines and
   parameters that, if followed, will enable organizations to implement
   a NTP environment successfully.  Each entity should choose and
   implement the products, architecture, protocols and configurations
   that best address their specific requirements and environment, while
   achieving the minimum requirements as outlined.

   In general, this will require a clocking hub with accuracies of 10
   milliseconds or better.  Where possible, subordinate servers and
   workstations should operate at stratum 4 or better (e.g., 3, 2 or 1).
   Servers should define at least three clock reference sources (if
   possible) at the same or better stratum for maximum availability,
   diversity and redundancy.

   Each clocking hub should include at least three stratum 1 (primary)
   or stratum 2 (secondary) servers as clock reference sources.  A
   primary server is synchronized to an external timing source (e.g., a
   GPS receiver, WWVB radio, NIST modem service).  A secondary server is
   synchronized to one or more primary servers (e.g., internal server,
   Internet server).

   Each primary and secondary server defined in the clocking hub should



Ackermann                  Expires July, 2014                   [Page 3]


INTERNET DRAFT      -ackermann-ntp-pdm-ntp-usage-00         January 2014


   have at least three timing paths to other servers with preference in
   order of:  (a) on the local intranet; (b) the Internet at large; or
   (c) on another entity network.  This order of preference is based on
   performance, stability and security.  At least one of these paths
   should be to a server outside the local network.  This will provide
   diversity and redundancy, which is critical in a successful NTP
   implementation.

   NTP implementations should be version 4 where possible, practical and
   supported by the pertinent platform vendor.  Version 3
   implementations are considered acceptable at this time.

   The preferred NTP operating software is the standard NTP code, which
   is publicly available.  The standard code is natively provided in
   most Unix operating systems (e.g., Solaris, AIX).  The Windows
   operating system natively provides proprietary NTP software, which
   operates acceptably, but the more effective method is to download the
   standard NTP code and install/operate it on the required Windows
   platform(s).  If a Windows platform is acting as a clocking hub for
   non-Windows devices, it is highly recommended that the standard NTP
   code be used on the Windows platform acting as the hub.

   By default, Windows servers and workstations will use proprietary
   protocols to receive clock from the controlling AD server.  If the
   controlling AD server is using NTP to clock to primary or secondary
   NTP servers, the overall configuration should be operating
   acceptably.  Therefore, a viable alternative at the present time is
   to use the current Windows synchronization architecture with the AD
   server(s), synchronizing to multiple primary or secondary NTP
   servers.  It should be recognized that the crafted mitigation
   algorithms used in NTP may not be available in native Windows
   software.

1.2 NTP and IPPM

   RFC2330, Framework for IP Performance Metrics, [RFC2330] discusses a
   number of issues with clocking and NTP including drift, skew,
   resolution, etc.  We will not repeat these here but will refer the
   reader to that RFC for background.

1.3 Hierarchy

   Each entity should have a clocking hub that receives its clock from a
   Stratum one or better source.  This received clock should then be
   made available to every platform in the network, either directly or
   indirectly. Indirectly involves multiple levels of the hierarchy as
   depicted in the generic NTP architecture diagram (2.1). The clock is
   transported via NTP sessions which are Client/Server in nature. Note



Ackermann                  Expires July, 2014                   [Page 4]


INTERNET DRAFT      -ackermann-ntp-pdm-ntp-usage-00         January 2014


   that for every additional hierarchal level, the received Stratum
   level (accuracy of the clock), is reduced, which means that the
   received clock is slightly less accurate.

   NTP Client/Server Sessions can be connected in three basic fashions:

   1. Broadcast,
   2. Server,
   3. Peer.

   Our recommendation is to utilize server connections in most cases.
   Broadcast is considered less stable, accurate and secure, but is
   still a viable option which requires less parameter definition at the
   client level. Peer sessions are a good solution when platforms are
   truly peer in the implemented hierarchy (e.g. dual Router Clocking
   Hubs).

1.4 Architectural Principles

   Most of the architectural principals and objectives are described in
   section 1.1. Several of the salient concepts include:

   - Servers should define at least three clock reference sources (if
   possible) at the same or better stratum for maximum availability,
   diversity and redundancy.- DNS should be used at all levels.  In some
   situations Round Robin to achieve load balancing and
   redundancy.Redundancy should be used at all levels if possible. This
   may not be necessary with workstations.- Sessions between NTP Clients
   and NTP Servers will usually be point to point but can also be
   broadcast.    The recommendation of this document is to utilize point
   to point, because it is more stable, accurate and more secure.  - NTP
   sessions between the Client and the Server can be defined to run in
   "Authenticated Mode".   Utilizing NTP in Authenticated Mode allows a
   connected entity to assure that the NTP Server that clock is being
   received from the intended NTP Server and not an IP imposter.
   "Shared Secret" keys, hashed using MD5, are used to authenticate the
   NTP sessions requested by NTP clients.














Ackermann                  Expires July, 2014                   [Page 5]


INTERNET DRAFT      -ackermann-ntp-pdm-ntp-usage-00         January 2014


2 NTP Architectures

   Following are sample diagrams of a generic NTP architecture and a
   suggested scheme which will achieve the required synchronization for
   the PDM.

2.1 Generic NTP Architecture

   The following is a sample generic NTP architecture:
        __________         ___________
       (          )       (  Internet )
       ( Internal )       (  Time     )
       ( Network  )       (  Sources  )
       (__________)       (___________)
            ^                   ^
            |                   |
            |                   |
       +-----------------------------+    +----------+
       |                             |    | Internal |
       |   Clocking Hub Router       |<---| Router   |
       |                             |    |          |
       +-----------------------------+    +----------+
            ^                  ^
            |                  |
            |                  |
        +--------+       +----------+
        | Unix   |       | Windows  |
        | Server |       | Server   |
        | Hub    |       | Hub      |
        +--------+       +----------+
            ^                  ^
            |                  |
            |                  |
       _____|_____      _______|_______
      (           )    (  Windows      )
      (  Unix     )    (  Servers &    )
      (  Servers  )    (  Workstations )
      (___________)    (_______________)


2.2 Recommended NTP Architecture

   This diagram represents an example of what a successful NTP
   implementation could look like, including the recommended levels of
   redundancy, diversity, load sharing, accuracy, and DNS usage.

3  Security Considerations




Ackermann                  Expires July, 2014                   [Page 6]


INTERNET DRAFT      -ackermann-ntp-pdm-ntp-usage-00         January 2014


   There are no security considerations.


4  IANA Considerations

   There are no IANA considerations.


5  References

5.1  Normative References

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
   "Framework for IP Performance Metrics", RFC 2330, May 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
   (IPv6) Specification", RFC 2460, December 1998.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
   "Network Time Protocol Version 4: Protocol and Algorithms
   Specification", RFC 5905, June 2010.

5.2 Informative References

   [ELKPDM]  Elkins, N., "draft-elkins-6man-ipv6-pdm-dest-option-02",
   Internet Draft, September 2013.

   [ELKPSN]  Elkins, N., "draft-elkins-v6ops-ipv6-packet-sequence-
   needed-01", Internet Draft, September 2013.

   [ELKRSP]  Elkins, N., "draft-elkins-v6ops-ipv6-end-to-end-rt-needed-
   01", Internet Draft, September 2013.

   [ELKUSE]  Elkins, N., "draft-elkins-v6ops-ipv6-pdm-recommended-usage-
   01", Internet Draft, September 2013

   [ELKIPPM] Elkins, N., "Draft-elkins-ippm-pdm-metrics-01", Internet
   Draft, September 2013.





6 Acknowledgments

   The authors would like to thank Al Morton for his assistance.

Authors' Addresses



Ackermann                  Expires July, 2014                   [Page 7]


INTERNET DRAFT      -ackermann-ntp-pdm-ntp-usage-00         January 2014


      Michael S. Ackermann
      Blue Cross Blue Shield of Michigan
      P.O. Box 2888
      Detroit, Michigan 48231
      United States
      Phone: +1 310 460 4080
      Email: mackermann@bcbsmi.com
      http://www.bcbsmi.com

      Nalini Elkins
      Inside Products, Inc.
      36A Upper Circle
      Carmel Valley, CA 93924
      United States
      Phone: +1 831 659 8360
      Email: nalini.elkins@insidethestack.com
      http://www.insidethestack.com

      Keven Haining
      US Bank
      16900 W Capitol Drive
      Brookfield, WI 53005
      United States
      Phone: +1 262 790 3551
      Email: keven.haining@usbank.com
      http://www.usbank.com

      William Jouris
      Inside Products, Inc.
      36A Upper Circle
      Carmel Valley, CA 93924
      United States
      Phone: +1 925 855 9512
      Email: bill.jouris@insidethestack.com
      http://www.insidethestack.com
















Ackermann                  Expires July, 2014                   [Page 8]


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