SNTP.docx

SNTP.docx

《SNTP.docx》由会员分享，可在线阅读，更多相关《SNTP.docx（31页珍藏版）》请在冰豆网上搜索。

SNTP

NetworkWorkingGroupD.Mills

RequestforComments:

2030UniversityofDelaware

Obsoletes:

1769October1996

Category:

Informational

SimpleNetworkTimeProtocol（SNTP）Version4

forIPv4,IPv6andOSI

StatusofthisMemo

ThismemoprovidesinformationfortheInternetcommunity.Thismemo

doesnotspecifyanInternetstandardofanykind.Distributionof

thismemoisunlimited.

Abstract

ThismemorandumdescribestheSimpleNetworkTimeProtocol（SNTP）

Version4,whichisanadaptationoftheNetworkTimeProtocol（NTP）

usedtosynchronizecomputerclocksintheInternet.SNTPcanbeused

whentheultimateperformanceofthefullNTPimplementation

describedinRFC-1305isnotneededorjustified.Whenoperatingwith

currentandpreviousNTPandSNTPversions,SNTPVersion4involves

nochangestotheNTPspecificationorknownimplementations,but

ratheraclarificationofcertaindesignfeaturesofNTPwhichallow

operationinasimple,statelessremote-procedurecall（RPC）mode

withaccuracyandreliabilityexpectationssimilartotheUDP/TIME

protocoldescribedinRFC-868.

TheonlysignificantprotocolchangeinSNTPVersion4overprevious

versionsofNTPandSNTPisamodifiedheaderinterpretationto

accommodateInternetProtocolVersion6（IPv6）[DEE96]andOSI

[COL94]addressing.However,SNTPVersion4includescertainoptional

extensionstothebasicVersion3model,includingananycastmode

andanauthenticationschemedesignedspecificallyformulticastand

anycastmodes.Whiletheanycastmodeextensionisdescribedinthis

document,theauthenticationschemeextensionwillbedescribedin

anotherdocumenttobepublishedlater.Untilsuchtimethata

definitivespecificationispublished,theseextensionsshouldbe

consideredprovisional.

ThismemorandumobsoletesRFC-1769,whichdescribesSNTPVersion3.

Itspurposeistocorrectcertaininconsistenciesintheprevious

documentandtoclarifyheaderformatsandprotocoloperationsfor

currentNTPVersion3（IPv4）andproposedNTPVersion4（IPv6and

OSI）,whicharealsousedforSNTP.AworkingknowledgeoftheNTP

Version3specificationRFC-1305isnotrequiredforan

implementationofSNTP.

MillsInformational[Page1]

RFC2030SNTPv4forIPv4,IPv6andOSIOctober1996

1.Introduction

TheNetworkTimeProtocol（NTP）Version3specifiedinRFC-1305

[MIL92]iswidelyusedtosynchronizecomputerclocksintheglobal

Internet.Itprovidescomprehensivemechanismstoaccessnational

timeandfrequencydisseminationservices,organizethetime-

synchronizationsubnetandadjustthelocalclockineach

participatingsubnetpeer.InmostplacesoftheInternetoftoday,

NTPprovidesaccuraciesof1-50ms,dependingonthecharacteristics

ofthesynchronizationsourceandnetworkpaths.

RFC-1305specifiestheNTPVersion3protocolmachineintermsof

events,states,transitionfunctionsandactionsand,inaddition,

engineeredalgorithmstoimprovethetimekeepingqualityandmitigate

amongseveralsynchronizationsources,someofwhichmaybefaulty.

Toachieveaccuraciesinthelowmillisecondsoverpathsspanning

majorportionsoftheInternetoftoday,theseintricatealgorithms,

ortheirfunctionalequivalents,arenecessary.However,inmany

casesaccuraciesintheorderofsignificantfractionsofasecond

areacceptable.Insuchcases,simplerprotocolssuchastheTime

Protocol[POS83],havebeenusedforthispurpose.Theseprotocols

usuallyinvolveanRPCexchangewheretheclientrequeststhetimeof

dayandtheserverreturnsitinsecondspastsomeknownreference

epoch.

NTPisdesignedforusebyclientsandserverswithawiderangeof

capabilitiesandoverawiderangeofnetworkdelaysandjitter

characteristics.MostusersoftheInternetNTPsynchronization

subnetoftodayuseasoftwarepackageincludingthefullsuiteof

NTPoptionsandalgorithms,whicharerelativelycomplex,real-time

applications（seehttp:

//www.eecis.udel.edu/~ntp）.Whilethesoftware

hasbeenportedtoawidevarietyofhardwareplatformsrangingfrom

personalcomputerstosupercomputers,itssheersizeandcomplexity

isnotappropriateformanyapplications.Accordingly,itisuseful

toexplorealternativeaccessstrategiesusingsimplersoftware

appropriateforlessstringentaccuracyexpectations.

ThisdocumentdescribestheSimpleNetworkTimeProtocol（SNTP）

Version4,whichisasimplifiedaccessstrategyforserversand

clientsusingNTPVersion3asnowspecifiedanddeployedinthe

Internet,aswellasNTPVersion4nowunderdevelopment.Theaccess

paradigmisidenticaltotheUDP/TIMEProtocoland,infact,it

shouldbeeasilypossibletoadaptaUDP/TIMEclientimplementation,

sayforapersonalcomputer,tooperateusingSNTP.Moreover,SNTPis

alsodesignedtooperateinadedicatedserverconfiguration

includinganintegratedradioclock.Withcarefuldesignandcontrol

ofthevariouslatenciesinthesystem,whichispracticalina

dedicateddesign,itispossibletodelivertimeaccuratetothe

MillsInformational[Page2]

RFC2030SNTPv4forIPv4,IPv6andOSIOctober1996

orderofmicroseconds.

SNTPVersion4isdesignedtocoexistwithexistingNTPandSNTP

Version3clientsandservers,aswellasproposedVersion4clients

andservers.WhenoperatingwithcurrentandpreviousversionsofNTP

andSNTP,SNTPVersion4requiresnochangestotheprotocolor

implementationsnowrunningorlikelytobeimplementedspecifically

forNTPirSNTPVersion4.ToaNTPorSNTPserver,NTPandSNTP

clientsareundistinguishable;toaNTPorSNTPclient,NTPandSNTP

serversareundistinguishable.LikeNTPserversoperatinginnon-

symmetricmodes,SNTPserversarestatelessandcansupportlarge

numbersofclients;however,unlikemostNTPclients,SNTPclients

normallyoperatewithonlyasingleserver.NTPandSNTPVersion3

serverscanoperateinunicastandmulticastmodes.Inaddition,SNTP

Version4clientsandserverscanimplementextensionstooperatein

anycastmode.

ItisstronglyrecommendedthatSNTPbeusedonlyattheextremities

ofthesynchronizationsubnet.SNTPclientsshouldoperateonlyat

theleaves（higheststratum）ofthesubnetandinconfigurations

wherenoNTPorSNTPclientisdependentonanotherSNTPclientfor

synchronization.SNTPserversshouldoperateonlyattheroot

（stratum1）ofthesubnetandthenonlyinconfigurationswhereno

othersourceofsynchronizationotherthanareliableradioormodem

timeserviceisavailable.Thefulldegreeofreliabilityordinarily

expectedofprimaryserversispossibleonlyusingtheredundant

sources,diversesubnetpathsandcraftedalgorithmsofafullNTP

implementation.Thisextendstotheprimarysourceofsynchronization

itselfintheformofmultipleradioormodemsourcesandbackup

pathstootherprimaryserversshouldallsourcesfailorthe

majoritydeliverincorrecttime.Therefore,theuseofSNTPrather

thanNTPinprimaryserversshouldbecarefullyconsidered.

Animportantprovisioninthisdocumentisthereinterpretationof

certainNTPVersino4headerfieldswhichprovideforIPv6andOSI

addressingandoptionalanycastextensionsdesignedspecificallyfor

multicastservice.Theseadditionsareinconjunctionwiththe

proposedNTPVersion4specification,whichwillappearasaseparate

document.TheonlydifferencebetweenthecurrentNTPVersion3and

proposedNTPVersion4headerformatsistheinterpretationofthe

four-octetReferenceIdentifierfield,whichisusedprimarilyto

detectandavoidsynchronizationloops.InVersion3andVersion4

primary（stratum-1）servers,thisfieldcontainsthefour-character

ASCIIreferenceidentifierdefinedlaterinthisdocument.InVersion

3secondaryserversandclients,itcontainsthe32-bitIPv4address

ofthesynchronizationsource.InVersion4secondaryserversand

clients,itcontainstheloworder32bitsofthelasttransmit

timestampreceivedfromthesynchronizationsource.

MillsInformational[Page3]

RFC2030SNTPv4forIPv4,IPv6andOSIOctober1996

InthecaseofOSI,theConnectionlessTransportService（CLTS）is

used[ISO86].EachSNTPpacketistransmittedasthtTS-Userdata

parameterofaT-UNITDATARequestprimitive.Alternately,theheader

canbeencapsulatedinaTPDUwhichitselfistransportedusingUDP

[DOB91].ItisnotadvisedthatNTPbeoperatedattheupperlayers

oftheOSIstack,suchasmightbeinferredfrom[FUR94],asthis

couldseriouslydegradeaccuracy.Withtheheaderformatsdefinedin

thisdocument,itisinprinciplepossibletointerworkbetween

serversandclientsofoneprotocolfamilyandanother,althoughthe

practicaldifficultiesmaymakethisinadvisable.

Inthefollowing,indentedparagraphssuchasthisonecontain

informationnotrequiredbytheformalprotocolspecification,but

consideredgoodpracticeinprotocolimplementations.

2.OperatingModesandAddressing

SNTPVersion4canoperateineitherunicast（pointtopoint）,

multicast（pointtomultipoint）oranycast（multipointtopoint）

modes.Aunicastclientsendsarequesttoadesignatedserveratits

unicastaddressandexpectsareplyfromwhichitcandeterminethe

timeand,optionally,theroundtripdelayandlocalclockoffset

relativetotheserver.Amulticastserverperiodicallysendsa

unsolicitedmessagetoadesignatedIPv4orIPv6localbroadcast

addressormulticastgroupaddressandordinarilyexpectsnorequests

fromclients.Amulticastclientlistensonthisaddressand

ordinarilysendsnorequests.Ananycastclientsendsarequesttoa

designatedIPv4orIPv6localb