Internet DRAFT - draft-ackermann-ntp-pdm-ntp-usage
draft-ackermann-ntp-pdm-ntp-usage
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]
