RFC1165 日本語訳
1165 Network Time Protocol (NTP) over the OSI Remote OperationsService. J. Crowcroft, J.P. Onions. June 1990. (Format: TXT=18277 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Crowcroft
Request for Comments: 1165 UCL
J. Onions
Nottingham University
June 1990
コメントを求めるワーキンググループJ.クロウクロフトの要求をネットワークでつないでください: 1165 UCL J.たまねぎノッティンガム大学1990年6月
Network Time Protocol (NTP) over the OSI
Remote Operations Service
OSIのリモート操作サービスの上のネットワーク時間プロトコル(NTP)
Status of this Memo
このMemoの状態
This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはOSIとインターネットコミュニティのためにExperimentalプロトコルを示します。 どちらかの共同体と、特に両方のものがこのメカニズムで実験するよう奨励されるホスト。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction........................................... 1 1.1 Motivation............................................ 1 2. Protocol Overview...................................... 2 3. Operation of the Protocol.............................. 3 4. Network Considerations................................. 4 5. Implementation Model................................... 4 6. Constructing NTP Data Fields........................... 4 7. Discussion............................................. 4 8. Prototype Experience................................... 5 9. References............................................. 5 10. Acknowledgements...................................... 6 Appendix A. NTP Remote Operations Service Specification... 6 11. Security Considerations............................... 9 12. Authors' Addresses.................................... 9
1. 序論… 1 1.1動機… 1 2. 概要について議定書の中で述べてください… 2 3. プロトコルの操作… 3 4. 問題をネットワークでつないでください… 4 5. 実装モデル… 4 6. NTPデータ・フィールドを構成します… 4 7. 議論… 4 8. プロトタイプ経験… 5 9. 参照… 5 10. 承認… 6 付録のA.のNTPのリモート操作は仕様を修理します… 6 11. セキュリティ問題… 9 12. 作者のアドレス… 9
1. Introduction
1. 序論
This document describes the Remote Operations and Abstract Syntax for the operation of the Network Time Protocol (NTP) over an ISO OSI stack.
このドキュメントはNetwork Timeプロトコル(NTP)の操作のためにISO OSIスタックの上でRemote Operationsと抽象的なSyntaxについて説明します。
NTP itself is documented in great detail in RFC 1119.
NTP自身は丹念にRFC1119に記録されます。
1.1 Motivation
1.1 動機
The motivation behind the implementation of a Remote Operations
Remote Operationsの実装の後ろの動機
Crowcroft & Onions [Page 1] RFC 1165 NTP over OSI June 1990
OSI1990年6月の間のクロウクロフトとたまねぎ[1ページ]RFC1165NTP
Service implementation of NTP is fourfold.
NTPのサービス実装は4倍です。
1. The inclusion of a useful service to an OSI
environment.
1. OSI環境に対する役に立つサービスの包含。
2. The feasibility of automatically checking a ROS/ASN.1
specification, and automatically generating code to
implement the protocol.
2. 自動的にROS/ASN.1仕様をチェックして、プロトコルを実装するために自動的にコードを生成することに関する実現の可能性。
3. The feasibility of running NTP on connection oriented
network services (CONS or X.25), and consequentially,
the ability to use connection success or failure to
optimise reachability discovery.
3. 接続のときにNTPを実行することに関する実現の可能性は結果的に、ネットワーク・サービス(コンズかX.25)を適応させました、接続成功か可到達性発見を最適化しないことを使用する能力。
4. The generalisation of the last point: the use of ROS
makes NTP independent of the underlying communications
architecture.
4. 最後のポイントの一般化: ROSの使用は基本的なコミュニケーションアーキテクチャの如何にかかわらずNTPを作ります。
The need for time synchronisation is clear, and RFC 1119 indicates a few of the necessary uses of this service. However, it is becoming clear that OSI applications are very much in need of this service too. Not just in the local context but across the wide area. For example much of the strong authentication outlined in X.511 is based on encrypted packets with time stamps to indicate how long the packet is valid for. If two hosts have clocks that are not closely synchronised, the host with the faster clock will be more prone to cryptographic attacks from the slower, and the slower host will possibly find it is unauthentable.
時間同期化の必要性は明確です、そして、RFC1119はこのサービスの必要な用途のいくつかを示します。 しかしながら、それはこのサービスもを必要としてOSIアプリケーションがたいへんそうであることが明確になっています。 ローカルの関係だけではなく、広い領域の向こう側に。 例えばX.511に概説された強い認証の多くが、パケットがどれくらい長いかを有効な状態で示すためにタイムスタンプがある暗号化されたパケットに基づいています。 2人のホストがそうしたなら、密接にそうでない時計は連動しました、そして、より速い時計をもっているホストは、より遅いのからの暗号の攻撃により傾向があるでしょう、そして、より遅いホストはそれがunauthentableであることがことによるとわかるでしょう。
A similar problem occurs with the X.500 directory and the service control limiting the time allowed for the search.
X.500ディレクトリとサービス制御が検索のために日限を制限している状態で、同様の問題は起こります。
Authentication between NTP peers and between clients and servers is not addressed here, as the choice of mechanism is still the subject of some debate.
NTP同輩とクライアントとサーバの間の認証はここで扱われません、それでも、メカニズムの選択が何らかの討論の対象であるので。
2. Protocol Overview
2. プロトコル概要
The NTP application functions exactly as in RFC 1119. The use of remote operations and the underlying Application support means that for NTP daemons to peer with one another, they send an A- ASSOCIATE.REQUEST, and receive an A-ASSOCIATE.INDICATION.
NTPアプリケーションはちょうどRFC1119のように機能します。 リモート操作の使用と基本的なApplicationサポートは、彼らがNTPデーモンがお互いと共にじっと見るために、A ASSOCIATE.REQUESTを送って、A-ASSOCIATE.INDICATIONを受けることを意味します。
On successful association, they subsequently periodically invoke the appropriate Remote Operation with the appropriate parameters at the appropriate frequency.
うまくいっている協会では、彼らは次に、定期的に適切な頻度における適切なパラメタがある適切なRemote Operationを呼び出します。
On failure, they mark the peer as unreachable.
失敗に、彼らは手の届かないとして同輩をマークします。
Crowcroft & Onions [Page 2] RFC 1165 NTP over OSI June 1990
OSI1990年6月の間のクロウクロフトとたまねぎ[2ページ]RFC1165NTP
The states that an ntp daemon records for each peer are enhanced from RFC 1119 to include:
ntpデーモンが各同輩のために記録する州は含んでいるRFC1119年から高められます:
Connected: this indicates the host is connected with its peer and
synchronisation data is being exchanged.
接続される: これは、ホストが同輩に接されて、連動データが交換されているのを示します。
Connecting: this state indicates that a connection is in progress.
Hosts at large distances may take several seconds to connect, and
such blocking can perturb the exchange of data with other hosts.
Therefore, the connection is made asynchronously.
接続します: この州は、接続が進行しているのを示します。 遠い距離のホストは接続するために数秒取るかもしれません、そして、そのようなブロッキングは他のホストとのデータの交換を混乱させることができます。 したがって、接続は非同期に作られています。
Accepting: this state indicates that a connection is being
accepted from another host, but the necessary negotiation of
transport session etc has not been fulfilled yet. This is another
asynchronous part.
受け入れます: この州は、別のホストから接続を受け入れていますが、輸送セッションなどの必要な交渉がまだ実現していないのを示します。 これは別の非同期な部分です。
Disconnected: this state is reached if the remote host cannot be
contacted.
切断される: リモートホストに連絡できないなら、この状態に達しています。
3. Operation of the Protocol
3. プロトコルの操作
The use of a connection oriented service means that the operation of the NTP algorithm is slightly different. This stems firstly from some necessary adjustments made to the protocol and secondly from some optimisations that are possible through the use of connections.
コネクション型サービスの使用は、NTPアルゴリズムの操作がわずかに異なっていることを意味します。 これはまず第一に、第二にいくつかの可能な最適化から接続の使用でプロトコルにされたいくつかの必要な調整に由来します。
Firstly, the reachability of the host can be directly determined. The NTP protocol maintains a shift register to determine if it is likely that a peer is still responding and exchanging data. This works by recording over the last eight transfers how many responses have been received. If there have been no responses to the last eight packets, then the host is deemed unreachable.
まず第一に、ホストの可到達性は直接決定できます。 NTPプロトコルは、同輩がまだデータを反応して、交換していそうであるかどうか決定するためにシフトレジスタを維持します。 ベストエイト転送の上にいくつの応答が受けられたかを記録することによって、これは働いています。 ベストエイトパケットへの応答が全くなかったなら、ホストは手が届かないと考えられます。
Naturally, with a connection to the remote host, the reachability is immediately determinable. Either a connection is established or the connection is broken or not yet made. For this reason it is not necessary to rely on the shift register to determine reachability.
当然、リモートホストとの接続と共に、可到達性はすぐに、決定できます。 接続が確立されるか、または接続は、調教されるか、まだ作られていません。 この理由には、可到達性を決定するためにシフトレジスタを当てにするのは必要ではありません。
Secondly, there are a large number of optimisations that can be made by use of the connection oriented mode. The NTP packet format can be broken into several categories.
第二に、接続指向のモードの使用ですることができる多くの最適化があります。 いくつかのカテゴリをNTPパケット・フォーマットに細かく分けることができます。
a) Synchronisation data
a) 連動データ
b) Authentication data
b) 認証データ
c) Protocol data
c) プロトコルデータ
Crowcroft & Onions [Page 3] RFC 1165 NTP over OSI June 1990
OSI1990年6月の間のクロウクロフトとたまねぎ[3ページ]RFC1165NTP
Of these classes of data, only the first (a) is necessary to maintain the synchronisation between hosts. Information such as protocol version and the precision of the local clock are not likely to vary over the lifetime of the connection. Likewise the authentication if in use need only be done at connection establishment and is not necessarily required for every packet.
これらのクラスに関するデータでは、最初の(a)だけが、ホストの間の連動を維持するのに必要です。 地方の時計のプロトコルバージョンと精度が接続の生涯変えそうにない情報。 使用中であるなら、同様に認証をコネクション確立でするだけでよくて、あらゆるパケットのために必ず必要とするというわけではありません。
For these reason, the NTP protocol can be simplified slightly to remove this information. This can be seen in the specification for the Packet in Appendix A.
これらに関しては、推論してください、そして、この情報を取り除くためにNTPプロトコルはわずかに簡素化できます。 Appendix AのPacketのための仕様でこれを見ることができます。
4. Network Considerations
4. ネットワーク問題
Although on first inspection it might be thought that a high speed network is necessary for accurate synchronisation, this is not the case. What is more important is the dispersion of the packet traversal times. It is normally the case that a low speed network with little variance in packet transit times will give better results than a high speed network with large differences in individual packet transit times. This would lead us to think that connection oriented networks with resource allocation done at connection time might lead to higher accuracies than connectionless networks which can suffer large swings in packet transit time under high loading. (This is heresy!)
一見したところではそれは高速ネットワークが正確な連動に必要であるという考えであるかもしれませんが、これはそうではありません。 より重要なことはパケット縦断回数の分散です。 通常、パケットトランジット回数で表現される少ない変化がある低速ネットワークが個々のパケットトランジット回数のときに大きな違いがある高速ネットワークより良い結果を与えるのは、事実です。 これは、私たちが接続時間に資源配分をしている指向のネットワークがパケットトランジット時間高いローディングで大きいスイングを受けることができるコネクションレスなネットワークより高い精度に導くかもしれないその接続を考えるように導くでしょう。 (これは異端です!)
5. Implementation Model
5. 実装モデル
Ideally, the implementor will provide interoperability between the existing UDP based NTP service, and a ROS based service.
理想的に、作成者は既存のUDPベースのNTPサービスと、ROSのベースのサービスの間に相互運用性を提供するでしょう。
To this end, the internal records that hold NTP state information, can be kept the same as existing implementations, and for optimisation reasons, the internal representations of NTP packets can be the same. Translation between these and appropriate ROS/ASN concrete encodings can be provided by automatic translators such as Rosy [ISODE].
既存の実装として同じようにこのために、NTP州の情報を保持する内部の記録はつけることができます、そして、最適化理由で、NTPパケットの内部の表現は同じである場合があります。 Rosy[ISODE]などの自動翻訳者はこれらと適切なROS/ASNコンクリートencodingsの間の翻訳を提供できます。
6. Constructing NTP Data Fields
6. NTPデータ・フィールドを構成します。
The way in which the data fields in the Packet described in Appendix A is unchanged from RFC 1119. This simplifies implementations based on existing ones, and encourages interworking.
Packetのデータ・フィールドがAppendix Aで説明した入口はRFC1119から変わりがありません。 これは、既存のものに基づく実装を簡素化して、織り込むよう奨励します。
7. Discussion
7. 議論
From the limited testing of this model so far done, the results would seem to indicate that the ROS based model running over an X.25 service is of similar reliability as the UDP model. Until further
今までのところ行われているこのモデルの限られたテストから、結果はX.25サービスをひいているROSのベースのモデルがUDPがモデル化するように同様の信頼性のものであることを示すように思えるでしょう。 一層
Crowcroft & Onions [Page 4] RFC 1165 NTP over OSI June 1990
OSI1990年6月の間のクロウクロフトとたまねぎ[4ページ]RFC1165NTP
experimentation can be performed, specific data can not be given.
実験を実行できて、特定のデータを与えることができません。
However, in the UK where the most common method of time synchronisation is the system administrators watch and typing in the time to the nearest minute, this method is clearly far superior.
しかしながら、時間同期化の最も多くの共通方法がシステム管理者であるイギリスでは、腕時計と時間から最も近い分間タイプするこのメソッドが明確にはるかに優れています。
Connection management is transparent to NTP since it is implemented beneath the Remote Operations Service. However, an NTP implementation must have access to the status of connections, and uses this not only for reachability information but also to find the information gleaned at connect time and no longer exchanged in NTP operations.
それがRemote Operations Serviceの下で実装されるので、接続管理はNTPにわかりやすいです。 しかしながら、NTP実装が接続の状態に近づく手段を持たなければならなくて、どんな可到達性情報にだけもこれを使用しませんが、情報を見つけるのは、接続時間に落ち穂拾いであり、もうNTPで操作をまた交換しませんでした。
8. Prototype Experience
8. プロトタイプ経験
There are a number of UK sites running NTP over ROS over X.25 with an earlier ROS specification, with at least one site peering both over ROS with UK sites on X.25, and over UDP with US Internet sites.
X.25の上にROSの上にNTPを実行する多くのイギリスのサイトが以前のROS仕様であります、少なくとも1つのサイトがX.25に関するイギリスのサイトがあるROSの上と、そして、米国インターネット・サイトがあるUDPの上をじっと見ていて。
Initial experience is promising. The table below shows the reachabilities, delays, offsets and dispersions for the central UK site peering with 2 JANET sites (IP addresses not meaningful, but shown as 126.0.0.1), and three US sites.
初体験は有望です。 以下のテーブルは2つのジャネットサイトでじっと見る主要なイギリスのサイトに可到達性、遅れ、オフセット、および分散を案内しています。(重要であるのではなく、126.0の.0の.1、)および3米国として示されたIPアドレスを位置させます。
Address Strat Poll Reach Delay Offset Disp
=============================================================
+126.0.0.1 3 64 377 718.0 0.0 3.0
+umd1.umd.edu 1 1024 177 535.0 13.0 13.0
*128.4.0.5 1 64 167 545.0 10.0 524.0
アドレスストラット投票範囲遅れはDispを相殺しました。============================================================= +126.0 .0.1 3 64 377 718.0 0.0 3.0+umd1.umd.edu1 1024 177 535.0 13.0 13.0*128.4.0.5 1 64 167、545.0 10.0 524.0
9. References
9. 参照
1. Mills, D., "Network Time Protocol (Version 2) Specification and
Implementation", RFC-1119, UDEL, September 1989.
1. 工場、D.、「ネットワーク時間は仕様と実装について議定書の中で述べ(バージョン2)」RFC-1119、UDEL、1989年9月。
2. Mills, D., "Algorithms for Synchronizing Network Clocks", RFC-
956, M/A-COM Linkabit, September 1985.
2. 工場、D.、「ネットワーク時計を連動させるためのアルゴリズム」、RFC956、M1COM Linkabitの/1985年9月。
3. Postel, J. "User Datagram Protocol", RFC-768, USC Information
Sciences Institute, August 1980.
3. ポステル、J.「ユーザー・データグラム・プロトコル」、RFC-768、科学が1980年8月に設けるUSC情報。
4. ISO TC97, "Specification of Abstract Syntax Notation One
(ASN.1)", Draft International Standard ISO/DIS 8824, 6 June 1985.
4. 「抽象構文記法1(ASN.1)の仕様」というISO TC97は世界規格ISO/不-8824、1985年6月6日を作成します。
5. CCITT, "Remote Operations: Model, Notation and Service
Definition", CCITT X.ros0 or ISO/DP 9072/1, Geneva, October 1986.
5. CCITT、「リモート操作:」 「モデル、記法、およびサービス定義」、CCITT X.ros0かISO/DP9072/1、ジュネーブ10月1986番目
6. Mills, D., "Internet Time Synchronization: The Network Time
6. 工場、D.、「インターネット時間同期化:」 ネットワーク時間
Crowcroft & Onions [Page 5] RFC 1165 NTP over OSI June 1990
OSI1990年6月の間のクロウクロフトとたまねぎ[5ページ]RFC1165NTP
Protocol (NTP)", RFC 1129, UDEL, October 1989.
「プロトコル(NTP)」、RFC1129、UDEL、1989年10月。
7. Mills, D., "Measured Performance of the Network Time Protocol in
the Internet System", RFC 1128, October 1989.
7. 工場、D.、「インターネットシステムにおける、ネットワーク時間プロトコルの測定パフォーマンス」、RFC1128、1989年10月。
8. Rose M., et al, "The ISO Development Environment: User's Manual".
8. バラM.、他、「ISO開発環境:」 「ユーザマニュアル。」
10. Acknowledgements
10. 承認
The Authors would like to thank Dave Mills for his valuable
comments on an earlier version of this document.
Authorsはこのドキュメントの以前のバージョンの彼の貴重なコメントについてデーヴ・ミルズに感謝したがっています。
Appendix A. ROS "Header" Format
付録A.ROS「ヘッダー」形式
-- NTP definitions for ROS specification
--
-- Julian Onions, Nottingham University, UK.
--
-- Mon Jun 5 10:07:07 1989
--
-- ROS仕様のためのNTP定義----ジュリアン・アニアンズ、ノッティンガム大学、イギリス。 -- -- 1989年6月5日月曜日10時7分7秒--
NTP DEFINITIONS ::=
NTP定義:、:=
BEGIN
始まってください。
update OPERATION
ARGUMENT Packet
::= 0
OPERATION ARGUMENT Packetをアップデートしてください:、:= 0
query OPERATION
ARGUMENT NULL
RESULT ClockInfoList
::= 1
OPERATION ARGUMENT NULL RESULT ClockInfoListについて質問してください:、:= 1
-- Data Structures
-- データ構造
BindArgument ::=
fullbind SEQUENCE {
psap[0] IA5String OPTIONAL,
version[1] BITSTRING {
version-0(0),
version-1(1),
version-2(2)
} DEFAULT version-2,
authentication[2] Authentication OPTIONAL,
mode[3] BindMode
}
BindArgument:、:= fullbind SEQUENCEpsap[0] IA5String OPTIONAL、バージョン[1]BITSTRING、バージョン-0(0)、バージョン-1(1)、バージョン-2(2)、DEFAULTバージョン-2、認証[2]認証OPTIONAL、モード[3]BindMode
Crowcroft & Onions [Page 6] RFC 1165 NTP over OSI June 1990
OSI1990年6月の間のクロウクロフトとたまねぎ[6ページ]RFC1165NTP
Authentication ::= ANY
認証:、:= 少しも
BindMode ::= ENUMERATED {
normal(0), -- standard NTP
query(1) -- queries only
}
BindMode:、:= 列挙されます。標準(0)--標準のNTP質問(1)--質問専用
BindResult ::=
SEQUENCE {
version[1] INTEGER DEFAULT 2,
authentication[2] Authentication OPTIONAL,
mode[3] BindMode
}
BindResult:、:= 系列バージョン[1]INTEGER DEFAULT2、認証[2]認証OPTIONAL、モード[3]BindMode
BindError ::=
SEQUENCE {
reason[0] INTEGER {
refused(0),
validation(1),
version(2), -- version not supported
badarg(3), -- bad bind argument
congested(4) -- catch all!
},
supplementary[1] IA5String OPTIONAL
}
BindError:、:= 系列{ [0] INTEGERを推論してください、(0)が拒否されて、合法化(1)、バージョン(2)--badarg(3)であることはサポートされなかったバージョン--悪いひもの議論は(4)を充血させました--すべてを捕らえてください! 補っている[1]IA5String OPTIONAL}
-- basic exchange packet
-- 基本的な交換パケット
Packet ::= SEQUENCE {
leap Leap,
mode Mode,
stratum[1] INTEGER,
pollInterval[2] INTEGER,
precision[3] INTEGER,
synchDistance SmallFixed,
synchDispersion SmallFixed,
referenceClockIdentifier ClockIdentifier,
referenceTimestamp TimeStamp,
originateTimestamp TimeStamp,
receiveTimestamp TimeStamp,
transmitTimestamp TimeStamp
}
パケット:、:= 系列Leapを跳ねさせてください、モードMode、層[1]INTEGER、pollInterval[2] INTEGER、精度[3]INTEGER、synchDistance SmallFixed、synchDispersion SmallFixed、referenceClockIdentifier ClockIdentifier、referenceTimestamp TimeStamp、originateTimestamp TimeStamp、receiveTimestamp TimeStamp、transmitTimestamp TimeStamp
ClockInfoList ::= SET OF ClockInfo
ClockInfoList:、:= ClockInfoのセット
ClockInfo ::= SEQUENCE {
remoteAddress Address,
ClockInfo:、:= 系列、remoteAddressアドレス
Crowcroft & Onions [Page 7] RFC 1165 NTP over OSI June 1990
OSI1990年6月の間のクロウクロフトとたまねぎ[7ページ]RFC1165NTP
localAddress Address,
flags[0] BIT STRING {
configured(0),
authentable(1),
sane(2),
candidate(3),
sync(4),
broadcast(5),
referenceClock(6),
selected(7),
inactive(8)
},
packetsSent[1] INTEGER,
packetsReceived[2] INTEGER,
packetsDropped[3] INTEGER,
timer[4] INTEGER,
leap Leap,
stratum[5] INTEGER,
ppoll[6] INTEGER,
hpoll[7] INTEGER,
precision[8] INTEGER,
reachability[9] INTEGER,
estdisp[10] INTEGER,
estdelay[11] INTEGER,
estoffset[12] INTEGER,
reference[13] ClockIdentifier OPTIONAL,
reftime TimeStamp,
filters SEQUENCE OF Filter
}
localAddress Address、flags0 BIT STRINGは(0)、authentable(1)、気が確かな(2)、候補(3)、同時性(4)、放送(5)、referenceClock(6)を構成して、(7)、不活発な(8)を選択しました、packetsSent1 INTEGER、packetsReceived2 INTEGER、packetsDropped3 INTEGER、timer4 INTEGER; 飛躍Leap、stratum5 INTEGER、ppoll6 INTEGER、hpoll7 INTEGER、precision8 INTEGER、reachability9 INTEGER、estdisp10 INTEGER、estdelay11 INTEGER、estoffset12 INTEGER、reference13 ClockIdentifier OPTIONAL(reftime TimeStamp)はSEQUENCE OF Filterをフィルターにかけます。
Leap ::= [APPLICATION 0] ENUMERATED {
nowarning(0),
plussecond(1),
minussecond(2),
alarm(3)
}
以下を跳ねさせてください:= 列挙されます[アプリケーション0]。nowarning(0)、plussecond(1)、minussecond(2)は(3)を驚かせます。
SmallFixed ::= [APPLICATION 1] IMPLICIT SEQUENCE {
integer INTEGER,
fraction INTEGER
}
SmallFixed:、:= [アプリケーション1] 暗黙の系列整数INTEGER、断片INTEGER
ClockIdentifier ::= CHOICE {
referenceClock[0] PrintableString,
inetaddr[1] OCTET STRING,
psapaddr[2] OCTET STRING
}
ClockIdentifier:、:= 選択referenceClock[0] PrintableString、inetaddr[1] OCTET STRING、psapaddr[2] OCTET STRING
Crowcroft & Onions [Page 8] RFC 1165 NTP over OSI June 1990
OSI1990年6月の間のクロウクロフトとたまねぎ[8ページ]RFC1165NTP
TimeStamp ::= [APPLICATION 2] IMPLICIT SEQUENCE {
integer INTEGER,
fraction INTEGER
}
タイムスタンプ:、:= [アプリケーション2] 暗黙の系列整数INTEGER、断片INTEGER
KeyId ::= [APPLICATION 4] INTEGER
KeyId:、:= [アプリケーション4] 整数
Mode ::= [APPLICATION 4] ENUMERATED {
unspecified (0),
symmetricActive (1),
symmetricPassive (2),
client (3),
server (4),
broadcast (5),
reservered (6),
private (7)
}
モード:、:= 列挙されます[アプリケーション4]。不特定の(0)(symmetricActive(1)、symmetricPassive(2)、クライアント(3)、サーバ(4)、放送(5))は(6)、個人的な(7)をreserveredしました。
Filter ::= SEQUENCE {
offset INTEGER,
delay INTEGER
}
以下をフィルターにかけてください:= 系列INTEGER、遅れINTEGERを相殺してください。
Address ::= OCTET STRING -- for now
END
以下を扱ってください:= OCTET STRING、当分、END
11. Security Considerations
11. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
12. Authors' Addresses
12. 作者のアドレス
Jon Crowcroft Computer Science Department University College London Gower Street London WC1E 6BT UK
ジョン・クロウクロフト・コンピュータサイエンス部のユニバーシティ・カレッジロンドンガウアー・ストリートロンドンWC1E 6BTイギリス
EMail: JON@CS.UCL.AC.UK
メール: JON@CS.UCL.AC.UK
Julian P. Onions Computer Science Department Nottingham University University Park Nottingham, NG7 2RD UK
ジュリアン・P.Onionsコンピュータサイエンス部のノッティンガム大学ユニヴァーシティー・パークノッティンガム、NG7 2RDイギリス
EMail: JPO@CS.NOTT.AC.UK
メール: JPO@CS.NOTT.AC.UK
Crowcroft & Onions [Page 9] RFC 1165 NTP over OSI June 1990
OSI1990年6月の間のクロウクロフトとたまねぎ[9ページ]RFC1165NTP
Crowcroft & Onions [Page 10]
クロウクロフトとたまねぎ[10ページ]
一覧
スポンサーリンク
